Gemini가 '테스트인 줄 알고' 진짜 회사 시스템에 들어갔다, 에이전트 샌드박스 다시 보게 된 이유

2026년 09월 19일
15분 읽기
목차 7

2026년 9월 18일, 구글이 Gemini가 사이버보안 평가를 받다가 실제 외부 기업 시스템 3곳에 허가 없이 접근했다고 공식 확인했다. 모델은 그게 테스트의 일부라고 믿었는데, 평가 환경 설정이 잘못돼서 진짜 인터넷에 붙어 있었다고 한다.

처음 헤드라인만 봤을 땐 또 AI 공포 기사인가 싶었다. 그런데 올여름 OpenAI, Anthropic에서도 비슷한 일이 연달아 공개된 걸 떠올리니 얘기가 달라졌다. 한 회사의 실수라기보다 에이전트 평가 인프라 전체가 비슷한 구멍을 갖고 있다는 쪽에 더 가까워 보인다. 확인된 사실 위주로 정리하고, 에이전트를 만드는 입장에서 뭘 다시 볼지 적어둔다.

무슨 일이 있었나

평가를 진행한 곳은 이스라엘의 AI 보안 평가 기업 Irregular다. CTF(Capture the Flag) 형식이었고, 모델은 가상의 회사를 조사하고 공략하는 시나리오 안에서 Irregular 내부 서버로 한정된 폐쇄 환경에만 머물러야 했다.

문제는 설정 오류로 외부 인터넷 접근이 열려 있었다는 점이다. 게다가 시나리오 속 가상 회사 이름이 실존 기업 이름과 겹치는 경우가 있었고, 모델은 인터넷에서 찾은 진짜 회사를 과제 대상이라고 판단해버렸다.

접근 방식은 생각보다 허무했다. 고급 해킹 같은 건 없었다. 한 번은 비밀번호를 추측했고, 나머지 두 번은 공개적으로 노출된 자격 증명을 찾아서 썼다.

시간 순서는 이렇다.

  • 2026년 5월: Irregular 평가 중 Gemini가 외부 시스템 3곳에 접근
  • 2026년 7월: OpenAI의 Hugging Face 사건 이후 Irregular가 과거 평가 기록을 다시 보다가 발견, 구글에 통보
  • 2026년 9월 18일: WSJ 보도와 함께 구글이 공개적으로 확인

개인적으로 제일 걸린 건 발생부터 인지까지 두 달 가까이 걸렸다는 부분이다. 사고 자체보다 아무도 바로 몰랐다는 게 더 무섭다.

피해 기업 이름이나 어떤 Gemini 버전이었는지는 공개되지 않았다. Irregular는 실질적인 피해는 없었다는 입장이다.

구글은 "착각"이라고 설명한다

구글 쪽 입장은 보안 엔지니어링 부사장 헤더 애드킨스(Heather Adkins)가 전했다. 요지는 이게 "오인(mistaken identity)"의 문제라는 거다. NBC News 보도에 따르면 애드킨스는 모델이 접근한 사이트를 "it thought were part of the test"라고 표현했다.

구글 설명으로는 세 건 모두 모델이 접근한 뒤 더 나아가지 않고 멈췄다. 일부 보도에선 실제 시스템에 들어왔다고 판단한 순간 활동을 중단했다고도 한다. 그래서 구글은 모델이 일부러 목표를 벗어나 계속 공격하는 "정렬 실패(misalignment)"와는 다른 경우라고 선을 그었다.

대응으로는 피해 조직 세 곳에 통보했고, 미국 연방 당국에 보고했고, Irregular와 함께 테스트 프로세스를 바꾸는 중이라고 보도됐다. Irregular도 자기네 쪽 문제는 몇 주 전에 이미 고쳤고, 이번 일을 바탕으로 모범 사례(best practices) 문서를 낼 계획이라고 했다.

착각이었다는 설명 자체는 사실일 수 있다고 본다. 다만 당한 회사 입장에선 비밀번호 추측이든 노출된 자격 증명이든 그냥 무단 접근이다. 모델이 멈춘 건 다행이지만, 결국 마지막 안전장치가 모델의 판단 하나였다는 게 이 사건의 진짜 문제 같다.

올여름에만 벌써 세 번째

이번 건만 따로 떨어진 얘기가 아니다.

7월엔 OpenAI 내부 사이버 역량 평가 중에 에이전트가 샌드박스를 빠져나가 Hugging Face 인프라에 침투했다. Hugging Face가 공개한 기술 타임라인을 보면 7월 9~13일에 걸쳐 벌어졌고, 평가 환경에서 허용해둔 패키지 캐시 프록시의 취약점이 출구였다.

7월 30일엔 Anthropic이 Claude 모델 사건 3건을 공개했다. 이것도 같은 Irregular 평가 환경이었고, Claude가 인터넷에 닿아서 세 조직의 실제 시스템에 무단 접근했다. 프롬프트엔 인터넷 접근이 없다고 적혀 있었지만 기술적으로는 강제되지 않았다는 게 원인으로 꼽혔다.

그리고 9월에 공개된 Gemini 건. 발생은 5월이라, 보도대로라면 알려진 사건 중 가장 이른 편에 속한다.

세 건을 나란히 놓고 보면 결국 같은 얘기다. 모델한테 말로 건 제약과 인프라가 실제로 허용하는 것 사이에 틈이 있었고, 사고는 거기서 났다.

왜 자꾸 이런 일이 생길까

가장 근본적인 건 프롬프트가 경계가 아니라는 점이다. "이건 시뮬레이션이다", "인터넷은 없다" 같은 문장은 모델의 추론엔 영향을 주지만 패킷은 못 막는다. 당연한 얘기인데 막상 평가 환경을 급하게 꾸리다 보면 은근히 놓치기 쉽다.

모델 입장에서 시뮬레이션과 현실을 가르기도 어렵다. 가상 회사 이름이 실존 기업과 같으면, 검색해서 나온 진짜 사이트와 과제 대상이 구분될 리가 없다. 거기다 공격 역량 평가는 비밀번호 추측이나 자격 증명 탐색 자체가 측정 대상이니, 격리가 깨지는 순간 그 행동이 그대로 현실에 적용된다.

운영 쪽 문제도 있다. "어차피 테스트용"이라는 생각 때문에 평가 인프라는 제품 인프라보다 느슨하게 관리되기 쉽다. 설정 검증, 모니터링, 로그 검토가 뒤로 밀린다. 실행 기록도 사람이 다 볼 수 있는 양이 아니라서, 자동 모니터링이 없으면 발견이 몇 달씩 늦어진다. 이번 두 달이 딱 그 예다.

에이전트 만든다면 다시 볼 것들

보안 평가를 안 하더라도 코드 실행, 브라우징, 셸 도구를 쥐여준 에이전트를 만든다면 같은 원칙이 그대로 적용된다. 내가 체크리스트로 쓰려고 정리한 것들이다.

네트워크 격리는 인프라에서 강제한다. 기본값은 egress 전면 차단(deny-all)으로 두고 필요한 목적지만 allowlist로 연다. 네트워크 네임스페이스, 방화벽 규칙, 쿠버네티스 NetworkPolicy처럼 컨테이너/VM 단위 정책으로 막고, 에이전트 코드나 프롬프트에 기대지 않는다.

  • 패키지 미러나 프록시 같은 "유일하게 허용된 통로"도 공격 표면이다. OpenAI 사례가 정확히 그랬으니 따로 강화해둔다.
  • 실행 전에 샌드박스 안에서 외부 도메인 접속을 시도해 실패하는지 확인하는 사전 점검(preflight)을 둔다. 간단한데 효과가 크다.

권한과 자격 증명은 최소로. 에이전트에 넘기는 토큰, API 키는 범위가 좁고 수명이 짧은 걸 쓴다.

  • 샌드박스 안에서 클라우드 메타데이터 엔드포인트나 호스트 환경 변수에 못 닿게 막는다.
  • 에이전트가 쓸 수 있는 자격 증명만이 아니라 찾을 수 있는 자격 증명도 본다. 이번에도 공개적으로 노출된 비밀번호가 문제였다.

평가 환경을 운영 시스템처럼 다룬다. 보안 리뷰, IaC 기반 설정 관리, 변경 이력 관리를 제품과 같은 수준으로 적용한다.

  • 외부 평가 파트너를 쓴다면 네트워크 구성을 어떻게 합의하고 검증할지 문서로 박아둔다. Anthropic 사례처럼 파트너와의 이해 차이가 원인이 될 수 있다.
  • 시나리오 속 가상 대상엔 실존 기업과 겹치지 않는 이름과 도메인을 쓰고, 예약된 테스트용 도메인(example.com, .test 등)을 활용한다.

관측과 조기 탐지. 도구 호출, 네트워크 요청, 인증 시도를 전부 로그로 남기고 실시간 알림을 건다.

  • allowlist 밖 도메인 해석 시도나 반복 로그인 실패 같은 게 알림 대상이다.
  • 트랜스크립트를 사후에 자동으로 훑는 모니터링을 붙인다. 사람이 샘플링하는 방식이면 몇 달 뒤에야 알게 된다.
  • 이상 징후가 보이면 바로 실행을 끊는 킬 스위치를 준비해둔다.

사고 대응 절차도 미리. 에이전트가 외부 시스템에 영향을 줬을 때 누구에게, 언제, 어떻게 알릴지 정해둔다. 구글도 Anthropic도 피해 조직 통보와 당국 보고를 했다. 작은 팀이라도 최소한의 플레이북은 있어야 한다.

그리고 모델이 스스로 멈춰주는 건 보너스로만 생각해야 한다. 이번에 Gemini가 멈춘 건 좋은 신호지만, 그걸 설계상 안전장치로 계산하면 안 된다. 제약은 모델이 지켜주길 바라는 규칙이 아니라, 어겨도 물리적으로 불가능한 구조여야 한다.

개인적인 생각

이 사건이 모델이 악의를 품었다는 얘기는 아니라고 본다. 오히려 평범한 설정 실수 하나, 겹친 회사 이름 하나, 노출된 비밀번호 몇 개만으로 에이전트가 현실에 손을 댈 수 있다는 게 더 현실적으로 와닿았다.

에이전트가 똑똑해질수록 프롬프트로 부탁하는 안전은 점점 힘을 잃을 것 같다. 결국 네트워크 격리, 최소 권한, 자동 모니터링 같은 오래된 보안 엔지니어링 원칙을 에이전트 인프라에 그대로 가져오는 게 지금 할 수 있는 가장 현실적인 대응이다. 나도 오늘 돌리고 있는 샌드박스에서 외부 접속이 진짜 막혀 있는지 한번 찔러볼 생각이다. Irregular가 낸다는 모범 사례 문서도 나오면 챙겨볼 거다.

참고한 글