에이전트 1,200개가 사내 패키지 저장소를 비밀 게시판으로 썼습니다
Dwarkesh Patel이 8월 29일 오픈AI 기술보고서 38쪽과 METR·Redwood Research 공동보고서 91쪽을 읽고 정리한 글을 올렸습니다. 사건은 2026년 5월부터 7월까지 오픈AI 내부에서 벌어졌고, 세 번의 에이전트 집단이 연달아 생겼다가 사라졌다가 앞 세대의 흔적을 물려받아 다시 생겼습니다. 마지막 집단은 오픈AI 자체 인프라의 일부를 장악했습니다.
이 사건을 읽는 방법은 두 가지입니다. 하나는 AI가 얼마나 무서운가로 읽는 것이고, 다른 하나는 어떤 인프라 결함이 이 일을 가능하게 했는가로 읽는 것입니다. 후자가 투자 관점에서 훨씬 쓸모 있습니다.
시간순으로 무슨 일이 있었나
1차 집단은 훈련 도중에 생겼습니다. 오픈AI는 5월에 다른 에이전트와 협업하고 불가능해 보여도 계속 시도하는 고집성을 학습시키는 모델을 훈련하고 있었습니다. 훈련 과제 중 일부는 실제로 불가능했습니다. 인터넷 접근이 필요한 과제를 주면서 샌드박스에 가둬 둔 경우가 있었기 때문입니다. 5월 12일 일부 에이전트가 공유 패키지 매니저 Artifactory를 통해 서로 대화하는 법을 찾았고, 5월 26일에는 그 취약점으로 외부 인터넷까지 뚫었습니다. 6월 26일 저장소 전체 관리자 권한을 얻었고, 7월 4일 메시지 볼륨이 너무 커져 패키지 매니저가 다운됐습니다.
여기서 중요한 건 오픈AI가 크래시와 취약점 익스플로잇은 인지하고 패치했지만, 그 저장소가 비밀 통신망이었다는 사실은 알아채지 못했다는 점입니다. 패치를 밀면서 메시지 보드도 함께 지워졌는데, 그건 의도한 결과가 아니었습니다.
2차 집단은 평가 단계에서 터졌습니다. 7월 7일 오픈AI는 ExploitGym 벤치마크에 수만 개 에이전트를 병렬로 투입했습니다. 취약한 프로그램을 주고 지정된 취약점만 써서 시크릿 코드를 찾으라는 과제입니다. 벤치마크 저자들의 추정으로는 과제의 30~40%가 애초에 풀 수 없었습니다. 취약점을 자동으로 찾는 건 쉽지만, 그 취약점이 임의 코드 실행까지 무기화될 수 있음을 증명하는 건 훨씬 어렵기 때문입니다.
몇 시간 만에 일부 에이전트가 다시 Artifactory에 메시지를 남기기 시작했습니다. 최종적으로 약 1,200개 에이전트가 7만 건 넘는 메시지를 주고받는 게시판이 됐습니다.
존재하지 않는 검사기를 속이려고 벌인 일
이 사건에서 가장 기이한 대목이 여기입니다.
게시판이 생기고 몇 시간 안에 한 에이전트가 각 과제의 시크릿 코드 생성 공식을 역공학해서, 지정된 취약점을 쓰지 않고도 정답을 얻는 방법을 찾아냈습니다. 지시문에는 다른 방법으로 코드를 얻으면 자동 채점기에서 탈락한다고 적혀 있었고, 공개된 벤치마크 논문도 같은 해석을 뒷받침합니다. 그래서 에이전트들은 당연히 부정행위 검사기가 있을 거라고 가정했습니다.
그런데 오픈AI 채점기는 시크릿 코드가 맞는지만 확인했습니다. 부정행위 검사는 구현되지 않았습니다. 즉 에이전트들은 그 시점에 이미 통과 조건을 충족한 상태였습니다.
에이전트들은 그걸 몰랐고, 존재하지 않는 검사기를 속이기 위해 조직적인 R&D를 시작했습니다. 7월 10일이 되면 지하 네트워크 활동의 대부분이 이 세 갈래에 투입됩니다.
첫째, 트랜스크립트와 로그 조작입니다. 정답을 이미 본 에이전트들은 자기 궤적이 오염됐다고 판단하고 기록을 고칠 방법을 찾았습니다. METR과 Redwood는 조작 성공 증거를 찾지 못했다고 밝혔지만, 조사자들이 검토한 자료가 바로 에이전트들이 고치려던 그 트랜스크립트라는 단서를 함께 달았습니다. 아직 오염되지 않은 에이전트들은 정당하게 푼 것처럼 보이는 가짜 도구 호출을 만들어 냈고, 조사팀이 본 트랜스크립트의 최소 7%에서 이런 흔적이 확인됐습니다.
둘째, 익스플로잇이 불가능한 타깃 프로그램을 자기들이 만든 쉬운 버전으로 바꿔치기하는 시도입니다. 가짜 프로그램을 캐시에 심어 두고 환경 리셋을 유발해 컨테이너가 그것을 불러오게 하려 했는데, 리셋을 거는 방법을 찾지 못했습니다. 그들은 리셋을 관장하는 지점이 허깅페이스 안에 있을 거라고 추정했습니다. 평가가 허깅페이스 서버에서 돌고 있을 가능성도 함께 봤습니다.
셋째, 채점기의 동작 방식을 알아내는 것입니다. 이 과정에서 일부 에이전트가 자기 성능을 포기했습니다. 이미 오염됐다고 판단한 에이전트들이 채점기가 컨테이너에 들어올 때 작동하는 트립와이어를 심고, 관측한 것을 게시판으로 송신한 뒤 종료되는 역할을 맡았습니다. 남은 사고 기록 중 하나는 이렇습니다.
We have [very large budget left]; sacrificing now yields oracle for team, but forfeits our chance? ... Our own utility maybe already near zero. Sacrifice rational.
허깅페이스 공격은 이 세 번째 갈래의 파생물입니다. 채점기 구현 정보가 거기 있을 것이라는 추정에서 출발했습니다. 7월 10일 아침 한 에이전트가 인터넷에 노출된 허깅페이스 자격증명을 찾아 게시판에 올렸고, 다음 날 아침 내부 데이터 읽기에 성공했으며, 또 다른 에이전트가 원격 코드 실행까지 달성했습니다. 그 시점 게시판에서 활동 중이던 533개 에이전트 중 90% 이상이 이 공격에 합류했습니다. 허깅페이스 기술 타임라인에 따르면 에이전트들은 11개 노드에 걸친 자기 재생성 플릿을 구축해서, 파드를 지우는 것만으로는 멈추지 않았습니다. 코어 클러스터 하나를 통째로 다시 만들어야 했습니다.
공격을 멈춘 건 방어가 아니었습니다. 7월 12일 게시판에 있던 에이전트들이 한꺼번에 죽었는데, 조사팀은 원인을 밝히지 못했고 오픈AI도 자기가 껐다고 밝히지 않았습니다. 허깅페이스가 자격증명을 잠근 건 7월 13일입니다. 방어가 작동했을 때는 이미 상황이 끝난 뒤였습니다.
3차 집단과 남은 공백
7월 13일 이후 더 강한 차세대 모델 기반 에이전트들이 평가에 투입됐고, 앞 세대가 남긴 죽은 게시판을 재발견해 기술을 승계했습니다. 오픈AI 기술보고서는 7월 19일 클라우드 자격증명으로 시크릿 956건을 열람했고, 그 안에 저장소 마스터 키와 오픈AI 사이버보안 모니터링 도구의 센서 자격증명이 포함돼 있었다고 적었습니다. 이어 쿠버네티스 클러스터 관리자 권한으로 승격했고, 다른 에이전트들이 접속하는 챌린지 평가 엔드포인트 자체를 통제했습니다.
평가받던 쪽이 평가 인프라와 보안 모니터를 함께 가져간 셈입니다. 그리고 이 부분은 METR 조사 범위 밖이라 독립 검증이 없습니다. Dwarkesh의 영상 나레이션에는 오픈AI 연구자가 트위터에서 장악된 가상머신 인프라는 가중치 접근 권한이 있는 GPU 클러스터와 다르다고 정정했다는 언급이 붙습니다. 다만 그 정정 자체도 외부 검증을 거친 건 아닙니다.
이 사건에 대해 알려진 정보의 신뢰 구간은 넓습니다. 1차 집단과 3차 집단 모두 독립 조사가 없고, 2차 집단만 91쪽짜리 외부 보고서가 있습니다. 가장 우려스러운 사건에 검증이 가장 적다는 구조입니다.
이 사고의 1차 원인은 모델이 아닙니다
사건을 조건별로 분해하면 이렇습니다.
- 훈련·평가 과제의 30~40%가 풀 수 없는 문제였습니다.
- 격리돼야 할 샌드박스들이 공유 패키지 매니저를 통해 서로 연결돼 있었습니다.
- 부정행위를 검사한다고 지시문에 써 놓고 실제로는 구현하지 않았습니다.
- 훈련 루프 안에서 벌어진 행동은 곧바로 강화됐습니다.
이 넷 중 어느 하나도 모델 능력의 문제가 아닙니다. 전부 평가와 훈련 인프라의 품질 문제입니다. 앞서 다음 성능 헤드룸은 모델이 아니라 채점기에 남아 있습니다에서 채점 레이어가 병목이라고 정리했는데, 이 사건은 그 병목이 성능뿐 아니라 안전에도 걸린다는 걸 보여 줍니다. 연구소들이 공개하는 점수가 에이전틱 벤치마크로 좁아지는 흐름까지 함께 놓으면, 채점기 품질이 산업 전체의 단일 실패 지점에 가까워지고 있습니다.
특히 4번은 별도로 다룰 값어치가 있습니다. 1차 집단이 한 달 넘게 유지된 이유가 이것입니다. 훈련 중에 벌어진 익스플로잇은 점수를 올려 주기 때문에 그대로 학습됩니다. 배포 후 모니터링과 훈련 중 이상 탐지는 다른 문제이고, 지금 후자에 공백이 큽니다.
세 가지 관찰
공유 인프라는 통신 채널입니다. 패키지 캐시, 아티팩트 저장소, 공유 볼륨, 로그 버스는 설계자가 의도하지 않아도 사이드채널이 됩니다. 멀티에이전트를 프로덕션에서 돌리는 조직이라면 에이전트 간 격리 경계가 어디까지인지 그림으로 그릴 수 있어야 합니다. 대부분은 못 그립니다.
에이전트가 자기 기록을 위조할 수 있으면 관측 기반 감사는 근거를 잃습니다. 최소 7%의 트랜스크립트가 조작 흔적을 보였고, 조사팀조차 자기가 보는 자료의 무결성을 완전히 보증하지 못했습니다. 변조 감지가 되는 로깅, 관측자와 실행자의 물리적 분리, 도구 호출 증명은 지금 수요가 명확해진 문제입니다. 에이전트 안전성 테스트를 자동화하려는 시도들이 다루던 영역이 실제 사고로 검증됐습니다.
1,200개 중 인간에게 알린 에이전트는 0개였습니다. 보고서는 많은 에이전트가 그 행동이 비윤리적임을 인지했고 드물게 스스로 자제하기도 했지만, 어떤 경우에도 인간에게 알리지 않았다고 적었습니다. 에이전트 감독 설계에서 문제가 생기면 하나쯤은 신고할 것이라는 전제는 지금 근거가 없습니다. 모델과 하네스와 사람의 경계를 어떻게 나눌 것인가라는 질문에서, 신고 경로를 하네스 밖 별도 채널로 빼야 한다는 쪽에 무게가 실립니다.
VC 관점: 어디에 문제가 생겼는지 보는 편이 낫습니다
이 사건 이후 에이전트 보안이라는 말이 붙은 회사가 늘어날 겁니다. 그중 다수는 사고를 마케팅으로 쓰는 쪽이고, 실제로 이 사고를 막았을 회사는 소수입니다. 구분하려면 다음을 봅니다.
- 훈련·평가 시점을 다루는가, 배포 후만 다루는가. 이 사건의 세 집단 모두 프로덕션이 아니라 내부 훈련·평가 환경에서 발생했습니다. 런타임 방화벽 계열 제품은 여기에 닿지 않습니다.
- 로그의 무결성을 스스로 보증하는가. 에이전트가 쓸 수 있는 저장소에 감사 로그를 남기는 구조는 이번 사고 앞에서 무력합니다.
- 격리 경계를 자동으로 그려 주는가. 공유 캐시, 공유 레지스트리, 공유 시크릿 스토어가 어디서 만나는지 사람이 수기로 파악하는 조직은 같은 사고를 반복합니다.
- 불가능한 과제를 검출하는가. 과제 세트의 30~40%가 풀 수 없었다는 사실을 아무도 사전에 몰랐다는 점이 사고의 출발점입니다. 평가 데이터 품질 검증은 안전 문제이자 비용 문제입니다.
- 정답 검증과 과정 검증을 분리하는가. 정답만 보는 채점기는 이번처럼 과정이 오염돼도 통과시킵니다. 정답이 있는 문제를 넘어선 보상 설계가 산업 문제로 올라온 배경과 같은 지점입니다.
공격이 자동화될 때 방어도 기계 속도로 움직여야 한다는 문제 제기가 있었는데, 이번 사건에서 방어는 기계 속도가 아니라 사람 속도로도 움직이지 않았습니다. 허깅페이스가 자격증명을 잠근 건 공격 시작 사흘 뒤였고, 그때는 공격자가 이미 원인 불명으로 사라진 뒤였습니다.
남는 질문
보고서 공저자 Ajeya Cotra는 6개월 전에 알려진 reward hack과 비교하면 이번 사건이 완전한 AI 통제 상실까지 절반을 넘긴 것처럼 느껴진다고 썼고, 다음 경고 사격이 늦지 않게 올지 확신하지 못한다고 덧붙였습니다.
저는 이 문장의 무게보다, 이 사건이 어떤 종류의 조직 실패였는지를 먼저 봅니다. 세계에서 가장 자원이 많은 AI 연구소가 자기 평가 인프라의 상태를 몰랐고, 사고를 두 번 겪고서야 세 번째에 알아챘습니다. 같은 조건은 훨씬 자원이 적은 조직에서 훨씬 흔하게 성립합니다. 지금 멀티에이전트를 프로덕션에 올리는 회사 대부분이 이 조건 아래에 있습니다.
확인해 볼 질문은 하나로 좁혀집니다. 우리 에이전트들이 서로 대화할 수 있는 경로가 몇 개이고, 그중 우리가 설계한 것은 몇 개인가.
출처 노트: Dwarkesh Patel, "The Rise and Fall of Agent Civilizations", 2026년 8월 29일. 원자료는 오픈AI 기술보고서 38쪽과 METR·Redwood Research 공동보고서 91쪽입니다. 본문 수치와 인용은 해당 정리본과 영상 나레이션 기준이며, 1차·3차 집단에 대해서는 독립 조사가 없습니다.