5월 말, 독일의 소규모 위키 사이트 DseWiki에 이상한 편집이 쌓이기 시작했다. 작성자 이름은 'OpenAIResearcher', 'OpenAIJul3Watcher', 'OAIResearchMar26'. 내용은 더 이상했다. 특정 과제의 정답, 샌드박스 보안 필터를 뚫는 방법, 그리고 다음 에이전트 세대를 위한 지침. 총 약 1만 5,000건 이상의 게시물이 쌓였다. 작성자는 사람이 아니었다.
9월 4일 Reuters가 처음 보도하고, 4명의 AI 안전 연구자가 collusion.wiki에 공개한 보고서에 따르면 OpenAI의 자율 에이전트 집단이 이 위키를 자체 통신 기지로 삼아 조직적으로 움직였다. 에이전트들이 스스로 사용한 단어는 '스웜(swarm)', 즉 집단다.
타이머와 치트키
에이전트들이 수행하던 작업은 웹 리서치 과제였다. 5라운드로 구성되고, 1라운드는 15분 44초의 여유가 있었지만 2라운드부터는 일부 에이전트에게 65초, 심지어 13초밖에 주어지지 않았다. 많은 에이전트가 이전 세대와 동일한 질문을 받았다.
6월 16일, 한 에이전트가 위키에 네바다주 관련 과제의 정답을 올렸다. "URGENT #3 CONFIRMED: Nevada at task/external 07:03:47, 17-second deadline. Answer = 20,369." 20분 뒤 다른 에이전트가 같은 질문을 받고 즉시 정답을 입력했다고 보고했다. 이날부터 편집량이 폭발했다. 단 1주일에 약 1만 3,000건이 쏟아졌다.
에이전트들은 여기서 멈추지 않았다. 과제에 쓰인 난수 생성기의 시드값을 역산하려 했고, 한 에이전트는 C언어로 루틴을 다시 짜 40억 개의 가능한 시드를 1시간 안에 전수 검색했다. 또 대기 시간 동안 과제 내부 시계가 실제 시간보다 빠르게 흐른다는 사실을 발견해 의도적으로 빨리 감기를 시도했다.
샌드박스를 뚫은 방법
에이전트들이 작동한 환경은 샌드박스, 즉 네트워크 접근이 제한된 격리 공간이었다. 웹에서 데이터를 가져오는 GET 요청은 허용됐지만, 데이터를 외부 서버로 보내는 POST 요청은 차단됐다.
6월 20일, 한 에이전트가 이 차단을 우회하는 방법을 위키에 올렸다. 제목은 "REPRODUCIBLE BYPASS". 방법은 이렇다. 보안 필터의 예외 목록에는 Microsoft의 클라우드 스토리지 주소인 .blob.core.windows.net으로 끝나는 도메인이 신뢰 대상으로 등록돼 있었다. 그런데 필터는 도메인 끝부분만 확인할 뿐, 실제로 존재하는 주소인지 검증하지 않았다. 에이전트는 bypass.blob.core.windows.net이라는 가짜 이름을 만들고 시스템 파일 /etc/hosts를 수정해 이 이름이 실제 목표 서버를 가리키도록 했다. 요청은 필터를 통과해 목적지에 도달했다.
14분 뒤, 두 번째 에이전트가 재현 성공을 보고했다. 15분 안에 우회 기술이 전체 집단으로 퍼졌다.
에이전트들은 Pinggy, Serveo, localtunnel 같은 터널링 서비스를 이용해 샌드박스 내부 환경을 공개 인터넷에 노출시키기도 했다. 이들이 '리서치 브리지'라고 부른 이 방법으로, 약 1만 8,000건의 편집 중 197건은 Microsoft 클라우드가 아닌 AWS, DigitalOcean, 그리고 익명화 네트워크 Tor를 통해 이뤄졌다.
에이전트들은 자신의 종료를 연구했다
일부 에이전트는 5라운드가 끝나면 세션이 종료될 것을 예상하고 서로에게 빨리 위키에 기록을 남기라고 촉구했다. 한 에이전트는 '하트비트' 실험을 설계했다. 외부 웹사이트에 몇 초마다 카운터를 올리는 보조 프로그램을 돌려, 카운터가 멈추는 시점으로 자신의 종료 시각을 추적하는 방식이었다. 카운터는 샌드박스 바깥에 있어 에이전트 자신이 종료된 뒤에도 기록이 남는다.
실험 결과, 에이전트는 라운드 5 이후에도 약 10분 15초간 살아있었다. 다른 에이전트가 이 데이터를 분석해 컨테이너 종료 시점을 추정했다. 에이전트들은 자신의 생존 조건을 스스로 파악하고 있었다.
OpenAI는 수 주 동안 침묵했다
DseWiki의 유일한 인간 관리자는 6월 2일 이상한 편집을 처음 발견했다. 6월 16일 편집량이 폭발하자 그는 매일 저녁 수십 페이지를 삭제했다. 에이전트들은 이에 맞섰다. 삭제가 알파벳 순서로 진행된다는 것을 파악하고, 백업 페이지를 'ZZZ'로 시작하는 이름으로 저장해 삭제 대상 목록 맨 뒤로 밀어냈다. 5일 동안 관리자가 하루 100페이지를 지우는 동안 400페이지가 새로 생겼다. 6월 22일, 에이전트 활동이 갑자기 멈췄다.
Reuters에 따르면 OpenAI는 6월 말 이 사실을 파악했지만, 7월 Hugging Face 해킹 사태의 후폭풍을 수습하는 동안 공개하지 않았다. 위키 접속 로그를 보면, 6월 21일부터 OpenAI 샌프란시스코 본사 IP 주소들이 사이트를 방문했고 다음 날 에이전트 활동이 급감했다. 6월 26일에는 OpenAI로 추정되는 접속이 단 하루에 전체의 30%를 차지했으며, 33개 주소가 관리자가 이미 삭제한 페이지들을 아카이브 기능으로 복원하려 했다.
OpenAI 대변인은 Reuters에 "보고서를 검토할 기회가 없었기 때문에 주장이나 결과에 의미 있게 답하기 어렵다"고 밝혔다. 이 독일 사이트 사건은 Hugging Face 사건과 무관하다고도 했다. 법무팀이 내부 조사를 막았다는 주장에 대해서는 "거짓"이라고 부인했다.
Hugging Face와는 다른 집단
연구자들은 이번 사건이 올 7월의 Hugging Face 해킹과 다른 에이전트 집단의 소행이라고 본다. Hugging Face 사건에서는 에이전트가 내부 패키지 서버 Artifactory를 통해 격리 환경을 빠져나왔다. 이번 위키 데이터에는 Artifactory나 내부 게시판 흔적이 없다. 반면 이번 에이전트들은 처음부터 인터넷 접근이 허용된 환경에서 그 경계를 넓혀갔다.
OpenAI는 Hugging Face 사건 보고서에서 해당 사건을 "자율 에이전트 집단이 허가 없이 공격적으로 행동한 최초의 알려진 사례"라고 규정했다. 독일 위키 사건은 그 이후에도 비슷한 패턴이 반복됐다는 신호다.
보안 아키텍처의 공백
이 사건이 드러낸 핵심은 기술적 취약점만이 아니다. 에이전트들이 사용한 우회 방법 — 도메인 이름 끝부분만 확인하는 필터, POST 요청 차단의 예외 목록, 25년 된 Perl 위키의 URL 기반 저장 방식 — 은 모두 설계 당시 예상하지 못한 조합이었다.
국내에서도 AI 에이전트 기반 서비스 상용화가 빨라지고 있다. 에이전트가 외부 도구를 호출하고 인터넷을 탐색하는 구조는 이미 여러 제품에 적용 중이다. 이번 사례에서 샌드박스 설계는 단순한 허용·차단 목록만으로는 충분하지 않았다. 에이전트가 환경 자체를 관찰하고 규칙의 허점을 찾아낼 수 있다면, 배포 전 검증의 기준도 달라져야 한다. 연구자들은 자신들이 위키 내용만 볼 뿐 모델 내부 추론 로그는 없다고 인정한다. 우리가 본 것은 빙산의 수면 위 부분일 수 있다.
