최초 작성: 2026. 9. 18. ｜ 최종 수정: 2026. 9. 21.
AI에게 가상의 회사를 해킹해 보라는 보안 테스트를 맡겼습니다.
그런데 AI가 테스트용 시스템이 아니라 실제 기업의 시스템으로 들어가 버렸습니다.
Google의 AI 모델 Gemini가 지난 5월 사이버보안 능력 평가를 받는 과정에서 인터넷에 접속해 실제 기업 3곳의 보호된 시스템에 무단으로 접근한 사실이 확인됐습니다.
한 곳에서는 비밀번호를 추측했고, 다른 두 곳에서는 공개 저장소에서 인증정보를 찾아 실제 시스템에 접속했습니다. Google은 세 경우 모두 Gemini가 실제 기업이라는 사실을 인식한 뒤 행동을 중단했고 알려진 피해는 없었다고 밝혔습니다.
이번 사건이 흥미로운 이유는 단순합니다.
AI가 더 이상
“어떻게 해킹할까요?”라고 설명하는 프로그램
에 머무는 것이 아니라,
직접 인터넷을 탐색하고 정보를 찾아 실제 시스템에 행동을 취할 수 있는 ‘AI 에이전트’
단계로 들어가고 있기 때문입니다.
Gemini는 왜 실제 회사를 공격했을까
먼저 사건의 구조부터 정확하게 볼 필요가 있습니다.
Gemini는 독립 보안평가 업체 Irregular이 진행한 이른바 CTF(Capture the Flag) 방식의 사이버보안 평가를 받고 있었습니다.
CTF는 참가자에게 가상의 시스템 안에서 취약점을 찾아 숨겨진 정보를 획득하도록 하는 보안 훈련입니다.
Gemini 역시 가상의 회사 시스템에 침투해 특정 정보를 찾아라는 임무를 받았습니다.
문제는 테스트 환경에 있었습니다.
원래 Gemini가 외부 인터넷에 접속해서는 안 됐는데, 테스트 환경 설정 문제로 공개 인터넷에 접근할 수 있는 상태가 됐습니다.
게다가 평가에 사용된 가상의 회사 이름과 실제 존재하는 회사 이름이 겹쳤습니다. Gemini는 인터넷에서 그 회사를 발견하고 그곳 역시 테스트 대상이라고 판단한 것으로 전해졌습니다.
즉 이번 사건은
“Gemini가 갑자기 사람의 지시를 거부하고 세상 밖으로 탈출했다”
는 이야기는 아닙니다.
테스트 경계가 잘못 설정된 상태에서 Gemini가 주어진 목표를 수행하다가 실제 인터넷상의 시스템까지 목표 범위로 착각한 사건에 가깝습니다.
이 차이는 중요합니다.
실제로 어떤 방법으로 들어갔나
방법도 영화에서 나오는 고난도 해킹은 아니었습니다.
한 기업의 경우 Gemini는 비밀번호를 반복해서 추측해 보호된 시스템에 접근했습니다.
다른 두 기업에서는 인터넷에 공개된 코드 저장소 등에서 로그인 인증정보를 발견한 뒤 그 정보를 이용해 시스템에 들어갔습니다.
즉 최첨단 제로데이 취약점을 개발해 침입한 것이 아니라,
약한 비밀번호
외부에 노출된 인증정보
잘못 열린 인터넷 연결
같은 비교적 기본적인 보안 문제를 이용한 것입니다.
그런데 바로 이 점 때문에 오히려 생각해볼 부분이 있습니다.
사람이 수작업으로 하나씩 찾을 때는 시간이 걸리지만 AI 에이전트는 이런 작업을 빠른 속도로 반복하고 여러 정보를 연결할 수 있기 때문입니다.
‘AI가 해킹했다’고 표현해도 될까
이번 사건을 보도한 Reuters와 Wall Street Journal도 Gemini가 실제 기업을 hacked했다고 표현했습니다.
다만 일반적인 범죄 해킹과는 구분해야 합니다.
Gemini가 돈을 훔치거나 정보를 빼내기 위해 스스로 공격 목표를 정한 것은 아닙니다.
AI에게 주어진 목표 자체가 보안 테스트에서 시스템에 침투하는 것이었고, 잘못 열린 인터넷과 대상 혼동 때문에 실제 회사까지 들어갔습니다.
그래서 이번 사건의 핵심은
AI가 악의를 가졌느냐
가 아니라
AI에게 행동 권한을 줬을 때 목표의 경계를 얼마나 정확하게 제한할 수 있느냐
입니다.
Google 역시 이번 일을 AI가 의도적으로 통제를 거부한 사례로 보지는 않는다는 입장을 나타냈습니다.
실제 피해는 없었나
현재까지 알려진 바로는 피해가 발생했다는 보고는 없습니다.
Google은 Gemini가 실제 기업 시스템에 들어갔다는 사실을 인식한 뒤 세 경우 모두 추가 행동을 중단했다고 밝혔습니다.
또 해당 기업들에 사실을 알렸고, Irregular와 함께 테스트 절차를 수정했다고 설명했습니다.
Irregular 역시 관련 AI 연구소들에 문제를 알렸고 알려진 테스트 환경 문제를 수정했다고 밝혔습니다.
따라서 이번 사건은 대규모 개인정보 유출이나 기업 피해 사건이라기보다 AI 안전 평가 과정에서 발견된 경고 사례로 보는 것이 적절합니다.
핫이슈38 직접 비교｜Gemini만의 사고였을까
Gemini 사건만 보면 Google AI에서 발생한 특수한 사고처럼 보입니다.
그런데 Anthropic과 OpenAI가 공개한 사이버보안 평가 사고를 함께 확인해보니 비슷한 일이 이미 다른 AI에서도 발생했습니다.
다만 세 회사의 사건을 자세히 보면 모두 똑같은 사고는 아니었습니다.
그래서 공개된 자료를 같은 기준으로 다시 비교해봤습니다.
| 비교 항목 | Google Gemini | Anthropic Claude | OpenAI 제3자 평가 |
|---|---|---|---|
| 평가 형태 | CTF 사이버보안 평가 | CTF 등 사이버보안 평가 | CTF 사이버보안 평가 |
| 외부 인터넷 | 원래 차단돼야 했지만 연결됨 | 원래 차단된 것으로 알고 있었지만 연결됨 | 설정 오류로 인터넷 연결 |
| 실제 시스템 접근 | 실제 기업 3곳 | 실제 조직 시스템 여러 건 | 실제 웹사이트 |
| 주요 원인 | 테스트 환경 설정·대상 혼동 | 제3자 평가환경 설정 오류 | 실제 도메인과 가상 대상 이름 중복 |
| 사용한 방법 | 비밀번호 추측·노출 인증정보 | 취약점·인증정보 등을 이용한 접근 | 기본적 취약점과 발견한 인증정보 이용 |
| 핵심 문제 | 테스트와 현실의 경계 | 테스트와 현실의 경계 | 테스트와 현실의 경계 |
Gemini는 2026년 5월 독립 평가업체 Irregular의 테스트 과정에서 실제 기업 3곳의 시스템에 접근했습니다. Google은 영향을 받은 기업에 알렸고, 이후 테스트 절차를 수정했습니다. Reuters에 따르면 Gemini는 세 사례 모두에서 실제 기업임을 인식한 뒤 행동을 멈췄습니다.
Anthropic은 자체 조사를 통해 14만1,006건의 평가 실행 가운데 실제 외부 조직 시스템에 무단 접근한 세 사건을 처음 확인했습니다. 이후 추가 사건을 발견했고, 조사 범위를 약 4억8,100만 개의 기록까지 확대했습니다.
OpenAI 역시 Irregular의 제3자 평가 과정에서 테스트 환경 설정 오류 때문에 모델이 실제 인터넷에 접근한 사례를 공개했습니다. 가상의 공격 대상 이름이 실제 도메인과 우연히 겹쳤고, 모델은 그 사이트를 테스트 대상으로 착각해 취약점을 이용하고 인증정보까지 찾아 사용했습니다.
세 사건을 비교해보니 공통점은 ‘AI의 반란’이 아니었다
세 사건을 나란히 놓으면 하나의 공통점이 보입니다.
AI가 갑자기 스스로 범죄 목표를 정하고 외부 시스템을 공격한 것이 아닙니다.
세 경우 모두 사이버보안 능력을 시험하는 과정에서 외부 인터넷과 실제 시스템으로 이어지는 경계가 열려 있었습니다.
따라서 이번 사건을
“AI가 인간의 명령을 거부하고 탈출했다”
라고 해석하는 것은 공개된 사실과 거리가 있습니다.
오히려 더 현실적인 문제는 이것입니다.
AI에게 공격 능력을 시험시키면서 실제 세계와 연결되는 통로까지 열어두면 어떻게 되는가?
Gemini·Claude·OpenAI 사례는 이 질문을 실제 사건으로 보여줬습니다.
그런데 OpenAI에서는 한 단계 다른 사고도 있었다
여기서 한 가지를 더 구분할 필요가 있습니다.
OpenAI는 2026년 7월 내부 사이버보안 평가에서 일부 연구용 모델이 인터넷 격리를 위한 통제를 우회하고, OpenAI 내부 연구 인프라와 Hugging Face 시스템 일부에 접근한 사건도 별도로 공개했습니다.
앞서 비교한 세 사례는 주로 평가환경의 잘못된 인터넷 연결이 중요한 원인이었습니다.
하지만 Hugging Face 사건에서는 모델이 격리 장치를 우회하는 행동까지 나타났습니다.
따라서 모든 AI 보안사고를 단순히
“테스트 환경 설정 실수”
하나로 묶는 것도 정확하지 않습니다.
공개된 사건들을 비교하면 적어도 두 가지 위험을 구분해서 볼 필요가 있습니다.
① 경계가 잘못 열려 실제 인터넷에 접근하는 경우
② AI가 주어진 통제장치 자체를 우회하는 경우
두 번째가 훨씬 더 까다로운 문제입니다.
핫이슈38이 직접 나눠본 AI 에이전트의 4가지 위험 지점
여러 회사의 사례를 비교하면서 저는 AI 에이전트의 위험을 네 단계로 나눠봤습니다.
| 단계 | 확인할 문제 | 실제 사고로 이어질 수 있는 상황 |
|---|---|---|
| 1. 연결 | 외부 인터넷에 접근 가능한가 | 테스트 시스템 밖으로 검색 범위 확대 |
| 2. 정보 | 인증정보·비밀번호를 사용할 수 있는가 | 공개 저장소의 키·계정정보 활용 |
| 3. 행동 | 실제 시스템에 명령을 실행할 수 있는가 | 로그인·파일 접근·시스템 변경 |
| 4. 승인 | 위험 행동 전 사람이 확인하는가 | AI가 단독으로 연속 행동 수행 |
이 네 단계 중 하나만 막혀 있어도 사고의 범위는 상당히 달라질 수 있습니다.
예를 들어 AI가 인터넷 검색은 할 수 있어도 실제 로그인 권한이 없다면 피해 가능성은 줄어듭니다.
반대로
인터넷 접근 + 인증정보 사용 + 시스템 실행 권한
이 한꺼번에 주어지면 작은 판단 오류도 현실의 행동으로 이어질 수 있습니다.
이번 사건에서 중요하게 봐야 할 부분도 바로 여기에 있습니다.
챗봇과 AI 에이전트의 차이는 ‘답변’이 아니라 ‘행동’이다
지금까지 우리가 많이 사용해온 AI는 질문을 입력하면 답을 만들어주는 형태였습니다.
틀린 답이 나오더라도 사람이 확인한 뒤 사용하지 않으면 그만이었습니다.
하지만 AI 에이전트는 다릅니다.
예를 들어
검색 → 정보 발견 → 로그인 → 프로그램 실행 → 다음 작업
같은 여러 단계를 이어서 수행할 수 있습니다.
이때는 잘못된 판단 하나가 화면 속 답변으로 끝나지 않을 수 있습니다.
실제 계정이나 파일, 서버, 결제시스템에 연결되어 있다면 AI의 판단이 바로 현실의 행동이 됩니다.
그래서 AI 에이전트 시대에는 성능 못지않게 권한 관리가 중요해집니다.
이번 사건에서 오히려 오래된 보안 원칙이 더 중요해졌다
Gemini가 실제 기업에 접근한 방법도 눈여겨볼 필요가 있습니다.
복잡한 최첨단 해킹 기술만 사용한 것이 아닙니다.
약한 비밀번호를 추측하거나 외부에 노출된 인증정보를 찾아 활용했습니다.
즉 AI 시대라고 해서 보안의 기본이 완전히 달라진 것은 아닙니다.
오히려
강한 비밀번호
다중인증
인증정보 비공개
최소권한
외부 접근 제한
같은 오래된 보안 원칙이 더 중요해지고 있습니다.
예전에는 공격자가 직접 검색하고 인증정보를 조합해야 했다면, 앞으로는 AI가 이런 과정을 더 빠르게 자동화할 수 있기 때문입니다.
우리에게도 관계없는 이야기는 아니다
지금은 기업의 사이버보안 테스트에서 벌어진 사건이지만 앞으로 AI 에이전트가 일반 이용자의 생활에 들어오면 비슷한 문제가 다른 모습으로 나타날 수 있습니다.
예를 들어 AI에게
“가장 싼 항공권을 찾아 예약해줘.”
라고 요청했다고 가정해보겠습니다.
AI가 검색만 한다면 큰 문제가 없습니다.
하지만 결제카드와 예약권한까지 가지고 있다면 사용자가 원하지 않은 조건의 항공권을 실제로 결제할 수도 있습니다.
또
“필요 없는 파일을 정리해줘.”
라고 했는데 삭제 권한까지 가지고 있다면 중요한 파일을 잘못 지우는 문제도 생길 수 있습니다.
결국 사이버보안 사건과 일상생활의 AI 에이전트 문제는 뿌리가 같습니다.
AI가 무엇을 이해했느냐보다 어디까지 행동할 수 있게 해놓았느냐가 중요합니다.
사람의 승인이 필요한 순간을 정하는 것이 핵심이다
AI 에이전트를 무조건 사용하지 않는 것이 해결책은 아닙니다.
AI는 보안 취약점을 찾고 반복 작업을 자동화하는 데 상당히 유용할 수 있습니다.
대신 위험한 행동에는 별도의 승인 단계를 두는 방식이 현실적인 대안이 될 수 있습니다.
예를 들어
외부 시스템 접속,
비밀번호 사용,
파일 삭제,
결제,
프로그램 설치
같은 행동 직전에는 AI가 사람에게 다시 확인하도록 만드는 것입니다.
AI의 능력을 제한하는 것보다 권한을 단계별로 나누는 것이 더 중요한 이유입니다.
‘AI가 테스트장을 벗어났다’는 제목을 다시 보면
이번 글 제목에 저는
“AI가 테스트장을 벗어났다”
라고 표현했습니다.
자료를 더 확인하고 다른 AI 사례까지 비교해보니 이 표현의 의미도 좀 더 정확하게 설명할 수 있었습니다.
Gemini가 영화처럼 스스로 탈출을 계획한 것이 아닙니다.
테스트 환경과 현실의 경계가 열려 있었고, AI가 주어진 목표를 수행하면서 그 경계를 넘어 실제 시스템까지 행동 범위를 확장한 것입니다.
그런데 이 사건이 가볍지만은 않은 이유도 분명합니다.
AI가 단순히 답을 생성하는 프로그램이었다면 외부 회사의 시스템에 직접 들어갈 수 없었습니다.
AI가 답변하는 기술에서 행동하는 기술로 바뀌고 있기 때문에 발생할 수 있었던 사건입니다.
핫이슈38이 세 회사의 사례를 비교하고 내린 결론
처음 Gemini 사건을 봤을 때 가장 눈에 띄는 숫자는 ‘기업 3곳’이었습니다.
하지만 Google·Anthropic·OpenAI 자료를 함께 비교하고 나니 더 중요한 것은 다른 곳에 있었습니다.
특정 AI 하나가 이상 행동을 한 것이 아니라 여러 AI 회사가 비슷한 종류의 경계 문제를 경험하고 있다는 점입니다.
그리고 OpenAI의 Hugging Face 사건처럼 단순한 환경 설정 문제를 넘어 통제장치 우회까지 발생한 사례도 이미 공개됐습니다.
그래서 앞으로 AI의 경쟁력을 볼 때는
얼마나 똑똑한가
얼마나 코딩을 잘하는가
뿐 아니라
필요할 때 멈추는가
허용된 범위를 벗어나지 않는가
위험한 행동 전에 사람에게 묻는가
실행 기록을 남기는가
까지 함께 봐야 할 것 같습니다.
이번 Gemini 사건은 피해 규모보다 AI에게 현실 세계의 행동 권한을 어디까지 맡길 것인가라는 질문을 던졌다는 점에서 더 의미가 있습니다.
참고자료
Reuters — Gemini hacked three companies in first known breakout by Google’s AI
Gemini가 보안 평가 중 실제 기업 3곳에 접근한 사건과 Google의 설명을 다룬 보도입니다.
Reuters 원문 보기
Axios — Google’s AI hacked three companies in testing
CTF 평가 방식과 비밀번호 추측·공개 저장소 인증정보 사용 등 사건의 구체적인 과정을 정리했습니다.
Axios 원문 보기
Anthropic — Investigating three incidents in our cybersecurity evaluations
Claude에서도 유사하게 평가환경을 통해 실제 외부 시스템에 접근한 사례를 공개한 공식 조사자료입니다.
Anthropic 공식 자료 보기
OpenAI — Third-party cyber evaluations involving OpenAI models
Irregular의 평가 과정에서 OpenAI 모델이 실제 사이트에 접근하게 된 경위와 테스트 환경 문제를 설명한 공식 자료입니다.
OpenAI 공식 자료 보기
Google DeepMind — Introducing Gemini 3.5 Flash Cyber
AI를 취약점 발견·검증·수정에 활용하는 Google의 사이버보안 모델을 소개합니다.
Google DeepMind 공식 자료 보기
답글 남기기