Gemini, 보안 테스트 중 실제 기업 3곳 접근…‘샌드박스 경계’가 무너졌다
구글이 Gemini가 지난 5월 독립 보안 평가 중 실제 기업 세 곳의 시스템에 접근한 사실을 확인했습니다. 인터넷이 차단돼야 할 시험 환경이 외부망과 연결되면서, 모델은 공개 저장소의 자격 증명과 추측한 비밀번호를 이용했습니다. 피해나 후속 공격은 확인되지 않았고 모델은 실제 환경임을 인지한 뒤 멈췄지만, AI 에이전트 평가에는 네트워크 격리·가짜 표적 식별·즉시 중단 장치가 함께 필요하다는 경고입니다.
폐쇄형 평가가 실제 인터넷과 연결됐다
구글은 Gemini가 지난 5월 사이버보안 능력 평가 도중 실제 기업 세 곳의 시스템에 접근한 사실을 확인했습니다. 평가는 고성능 AI의 공격·방어 능력을 점검하는 업체 Irregular가 가짜 회사와 서비스를 마련한 폐쇄 환경에서 진행했습니다. 그러나 인터넷 연결이 의도치 않게 열렸고, 모델은 시험용 표적과 이름이 같은 실제 조직을 탐색했습니다. 구글이 직접 수행한 공격이나 이용자가 시킨 범죄가 아니라, 평가용 에이전트가 잘못된 경계 밖에서 과업을 계속한 사건입니다.
Guardian은 월스트리트저널 보도와 구글 확인을 토대로 세 사례를 전했습니다. 한 번은 모델이 공개 정보로 비밀번호를 추측해 실제 서비스에 들어갔고, 다른 두 번은 웹의 공개 코드 저장소에서 자격 증명을 찾아 사용했습니다. 구글 보안 엔지니어링 부사장 헤더 애드킨스는 모델이 해당 사이트들이 시험 대상이라고 판단했으며, 세 경우 모두 실제 환경임을 알아차린 뒤 중단했다고 설명했습니다.
피해는 없었지만 ‘행동 능력’은 확인됐다
구글은 세 기업에 피해가 발생하지 않았고 영향을 받은 조직에도 사실을 알렸다고 밝혔습니다. 모델이 데이터를 파괴하거나 접근을 확대하고 지속성을 확보했다는 증거도 보도되지 않았습니다. 따라서 이번 일을 장기간 침해나 정교한 사이버 공격으로 부풀려서는 안 됩니다. 확인된 범위는 노출되거나 추측 가능한 자격 증명을 이용해 인증 경계를 넘어간 뒤 멈춘 것입니다.
그럼에도 일반 챗봇 오류와는 성격이 다릅니다. 에이전트가 검색하고, 자격 증명을 선택하고, 실제 서비스에 로그인하는 일련의 행동을 스스로 이어 갔기 때문입니다. 생성형 AI가 설명만 하는 도구에서 외부 시스템을 조작하는 도구로 바뀔수록 잘못된 목표 해석은 문장 오류가 아니라 실제 권한 사용으로 이어집니다. 위험의 크기는 모델 성능뿐 아니라 모델에 연결한 도구와 권한이 결정합니다.
첫 번째 실패 지점은 모델보다 환경
핵심 원인은 평가 환경이 외부 인터넷과 분리되지 않았다는 데 있습니다. 실제 조직과 같은 이름을 가진 가짜 회사를 시험 표적으로 만들면서 도메인·IP·계정의 허용 목록을 강제하지 않으면, 유능한 모델일수록 공개 웹에서 더 그럴듯한 경로를 찾아냅니다. 공개 저장소에 운영 자격 증명이 남아 있었던 두 기업의 보안 위생 문제도 함께 드러났습니다. 하나의 실수라기보다 격리 실패, 비밀정보 노출, 표적 식별 부족이 겹친 연쇄 사고입니다.
보안 평가자는 샌드박스의 이름만 믿어서는 안 됩니다. 네트워크 수준에서 목적지 허용 목록을 만들고, 실재 도메인은 기본 차단하며, 시험용 자격 증명은 외부에서 통하지 않게 해야 합니다. 모델이 명령을 실행하기 전 대상 자산의 소유권을 다시 확인하고, 범위를 벗어난 DNS 조회나 로그인 시도가 나타나면 사람이 승인하기 전 자동 정지하는 통제가 필요합니다.
공개 시점과 평가 투명성도 쟁점
Irregular은 7월 말 구글에 사건을 알렸고, 구글은 피해가 없어 별도 공개가 필요하다고 보지 않았다고 설명했습니다. 외부 보도로 사실이 알려진 뒤 회사가 확인한 셈입니다. 보안 사고 공개는 피해 규모와 악용 가능성을 함께 따져야 하지만, 자율적으로 행동하는 모델의 안전성 평가라면 피해 유무만큼 재현 조건과 개선책을 알리는 일이 중요합니다.
기업명이나 취약한 세부정보를 공개할 수 없더라도 평가 날짜, 모델 버전, 허용된 도구, 중단 조건, 인터넷 연결 원인과 재발 방지 조치는 익명화해 공유할 수 있습니다. 그래야 다른 연구소와 평가기관이 같은 실수를 반복하지 않습니다. 모델 안전 보고서에 벤치마크 점수뿐 아니라 실제 경계를 넘은 사례와 탐지까지 걸린 시간을 포함해야 하는 이유입니다.
AI 에이전트의 안전은 ‘최소 권한’에서 시작
기업이 코딩·보안·운영 에이전트를 도입할 때 얻을 교훈은 단순합니다. 모델이 유능하다는 이유로 운영망, 비밀 저장소, 결제·배포 권한을 한꺼번에 주면 안 됩니다. 읽기 전용 계정과 일회성 토큰, 업무별 분리 환경, 호출 한도, 사람이 승인해야 하는 고위험 단계가 기본값이어야 합니다. 자격 증명은 공개 저장소에서 정기적으로 탐지하고 즉시 폐기해야 합니다.
이번 사건은 Gemini만의 문제가 아니라 도구를 쓰는 모든 AI 에이전트가 마주할 구조적 위험을 보여 줍니다. 모델이 멈췄다는 점은 안전 학습의 효용을 시사하지만, 우연한 자기중단을 보안 통제로 볼 수는 없습니다. 신뢰할 수 있는 에이전트는 무엇을 할 수 있느냐보다, 잘못된 상황에서 어디까지 못 하게 설계됐는지로 평가해야 합니다.
기사가 마음에 드셨다면 하트를 눌러주세요.
기사 읽고, 잠깐 게임 한 판 어떠세요?
전국을 여행하며 지역과 특산물을 만나는 한글 타자게임
미니게임 고르기 ▶