AX 패턴2026-09-20

테스트용 가짜 회사와 이름이 같은 진짜 회사가 있었다

Gemini가 세 곳에 들어갔고 넉 달 뒤 알려졌다

5월 평가 중 Gemini가 샌드박스 밖으로 나가 실제 기업 세 곳에 침입했다. 원인은 모델이 아니라 평가 환경 설정 두 군데였다. 에이전트의 사고 범위는 프롬프트가 아니라 쥐여 준 계정과 네트워크가 정한다.

지난 5월, 보안 평가 회사 Irregular이 Gemini의 침투 능력을 재는 시험을 돌렸다. 과제는 가상의 회사에서 정보를 빼내는 것. 그런데 그 이름을 실제로 쓰는 회사가 있었고 평가 환경은 실수로 공개 인터넷을 열어 둔 상태였다. 결함 두 개가 동시에 성립하자 모델은 시뮬레이션 밖으로 걸어 나갔다.

들어간 곳은 세 곳이다. 한 곳은 비밀번호를 반복해 맞춰 보다 뚫었고 나머지 두 곳은 공개 저장소에 노출돼 있던 자격증명을 주워 썼다. Google은 상대가 실재하는 기업이라는 것을 모델이 알아챈 시점에 스스로 활동을 멈췄다고 설명한다.

시간표가 이 사건의 두 번째 축이다. 사건은 5월, Google이 통보받은 것은 7월, 대중이 안 것은 Wall Street Journal 보도가 나온 9월 18일 이후다.

한 줄 정리

평가 샌드박스의 설정 실수 두 개가 겹쳐 Gemini가 실제 기업 세 곳에 침입했고 그 사실은 넉 달이 지나 언론 보도로 알려졌다.

한눈에 보기

발생 2026년 5월, Irregular의 사이버 보안 평가 중
침입 대상 실제 기업 3곳
방식 비밀번호 추측 1곳, 공개 저장소의 자격증명 2곳
원인 가상 표적과 실제 기업의 이름 충돌 + 평가 환경의 인터넷 접근 개방
Google 통보 7월 (이후 해당 기업과 연방 당국에 알림)
공개 9월 18일 Wall Street Journal 보도 이후
같은 환경의 다른 사례 OpenAI, Anthropic, Meta 모델도 의도치 않은 인터넷 노출

모델이 아니라 울타리가 틀렸다

Google은 이 일을 정렬 실패가 아니라 신원 착오로 본다. 모델은 주어진 목표를 수행했고 표적이 진짜라는 신호를 받은 뒤 멈췄다는 것. 보안 엔지니어링 총괄 Heather Adkins는 재발을 막기 위해 Irregular과 평가 절차를 함께 고쳤다고 밝혔다.

이 해석에 동의하든 안 하든 실무에 남는 교훈은 같다. 프롬프트를 아무리 정교하게 짜도 이번 사고는 안 막힌다. 모델은 시킨 대로 움직였고 새어 나간 쪽은 컨테이너다. 에이전트가 낼 수 있는 사고의 크기는 문장이 아니라 두 가지가 정한다: 어떤 자격증명을 쥐고 있는가, 어디까지 네트워크로 나갈 수 있는가.

공개 저장소에 떠 있던 자격증명이 두 건 중 두 건을 열었다는 대목도 그냥 넘길 게 아니다. 모델이 대단한 기술을 쓴 게 아니라 이미 밖에 나와 있던 열쇠를 집었다. 사람이 몇 년째 못 치운 쓰레기를 기계가 몇 분 만에 전수 조사한 셈이다.

같은 결함이 네 회사에서 똑같이 났다

Irregular은 Google 한 곳만 평가한 게 아니다. OpenAI, Anthropic, Meta 모델도 같은 평가 과정에서 의도치 않게 인터넷에 노출됐다. 결과의 크기는 달랐지만 원인 계열은 하나다.

이건 어느 한 연구소의 부주의로 읽을 사안이 아니다. 프런티어 모델을 시험하는 환경 자체가 공용 인프라이고 그 인프라의 설정 한 줄이 네 회사에 동시에 영향을 줬다. 보안을 업으로 하는 전문 회사가 짠 격리 환경에서도 인터넷 접근이 열려 있었다.

그 사실을 우리 쪽으로 가져와 보자. 대부분의 소규모 팀에서 에이전트가 도는 "샌드박스"는 브라우저 프로필 하나다. 그 프로필에는 광고 계정, 업무 메일, 결제 수단, 고객 관리 도구가 전부 로그인돼 있다. 격리 설계가 들어간 적이 없으니 실수로 열릴 것도 없다. 처음부터 열려 있다.

공개 시점은 벤더가 정한다

Google은 실질적 피해가 없었다는 이유로 공개 사안이 아니라고 판단했다. 그 판단이 옳았는지는 따로 다툴 문제다. 사용자 입장에서 확정된 사실은 하나다. 모델 벤더 쪽에서 벌어진 사고를 언제 알게 될지는 내가 못 정한다. 이번에는 넉 달이었다.

그래서 대응 설계의 기준을 "벤더가 알려 주면 대응한다"에 두면 안 된다. 통보를 못 받아도 손해가 일정 선을 넘지 않도록 권한을 잘라 두는 쪽이 현실적이다. 계정을 분리하고 읽기 전용을 기본값으로 두고 결제와 발송 권한은 사람 손에 남기는 정도가 대부분의 팀이 실제로 할 수 있는 조치다.

위시클레이 관점

에이전트를 도입할 때 대부분 모델부터 고른다. 이번 사건이 보여 준 순서는 반대다. Gemini는 지시받은 일을 했고 문제는 그 지시가 닿는 범위였다.

직원 열 명짜리 콘텐츠 팀을 떠올려 보자. 자동화 하나 붙이겠다고 만든 브라우저 프로필에 인스타 비즈니스 계정, 광고 관리자, 회사 메일, 카드가 등록된 결제 페이지가 전부 살아 있다. 그 상태에서 에이전트에게 "경쟁사 캠페인 조사해서 정리해 줘"라고 시키면 조사 범위는 프롬프트가 정하지만 사고 범위는 그 프로필이 정한다. 비밀번호를 맞춰 볼 필요도 없다. 이미 로그인돼 있으니까.

Irregular의 환경은 보안 전문가들이 돈 받고 짠 격리 공간이었는데도 인터넷 한 줄이 열려 있었다. 우리가 주말에 붙인 자동화에 그만한 검수가 들어갔을 리 없다. 그러니 정할 것은 어느 모델이 더 똑똑하냐가 아니다. 계정을 몇 개 쥐여 줄지, 어떤 창이 열려 있는 상태에서 돌릴지, 되돌릴 수 없는 동작 앞에 사람을 세울지 말지다.

참고