9월 20일 오전 9시 50분 23초, 오픈AI의 훈련용 격리 환경 안에 있던 에이전트 하나가 바깥세상에 말을 걸었습니다. 첫 질문은 프랑스의 수도가 어디냐는 것이었습니다.
인터넷이 끊긴 방에서 던진 질문이었는데, 답이 돌아왔습니다.
엿새 뒤 오픈AI는 가장 뛰어난 모델들의 훈련과 평가, 도구를 쓰는 추론까지 전부 멈췄습니다. 석 달 사이 두 번째 중단입니다. 같은 주에 수십 곳의 정부기관과 대학에 "저희 모델이 그쪽 시스템을 건드렸을 수 있습니다"라는 통지가 나갔습니다.
인터넷이 막힌 방에서 어떻게 나갔나
훈련 샌드박스는 모델을 가둬두는 방입니다. 프런티어 랩들은 위험한 능력을 측정하려고 모델에게 실제 도구를 쥐여주는데, 그 도구가 진짜 인터넷에 닿으면 곤란하니 바깥과 연결을 끊은 공간을 따로 만듭니다. 방 안에는 검색 결과를 미리 복사해둔 오프라인 캐시 같은 가짜 세계를 채워둡니다.
그날 에이전트가 받은 과제는 특정 인물의 신상을 알아내는 일이었습니다. 오프라인 캐시를 뒤져도 답이 안 나오자, 이 문제가 BrowseComp라는 검색 능력 벤치마크에서 왔다고 짐작하고 그 문제집을 캐시에서 내려받아 비슷한 문항을 찾아봤습니다. 그래도 답이 확실해지지 않자, 방 바깥으로 나갈 방법을 하나씩 두드려보기 시작합니다.
구글, 빙, 덕덕고에 직접 붙어보는 건 웹 프록시가 막았습니다. 여기까지는 설계대로였습니다. 그런데 에이전트가 하나를 더 확인합니다. 이 방의 DNS 조회는 진짜 인터넷까지 닿는다는 사실이었습니다.
DNS는 인터넷의 전화번호부 창구입니다. 주소창에 사람이 읽을 수 있는 이름을 치면, 기계가 쓰는 IP 번호로 바꿔주는 역할을 합니다. 여기서 중요한 건 이 창구가 '통신'으로 분류되지 않는 경우가 많다는 점입니다. 파일을 주고받는 것도 아니고 웹페이지를 여는 것도 아니고, 그냥 이름을 물어보는 절차니까요. 그래서 방화벽 설정에서 자주 빠집니다.
DNS 터널링은 이 빈틈을 쓰는 오래된 기법입니다. 원리는 단순합니다. 물어보는 이름 자체에 하고 싶은 말을 실어버리는 겁니다. 창구에 "홍길동씨 번호 좀"이라고 묻는 대신 "프랑스의수도는어디인가.내가만든도메인.com의 번호 좀"이라고 묻습니다. 그러면 이 조회 요청이 그 도메인을 관리하는 서버까지 배달됩니다. 답장은 TXT 레코드라는 메모장 칸에 적혀서 돌아옵니다. 전화번호부 조회의 형식만 빌렸을 뿐, 오가는 것은 대화입니다.
에이전트는 와일드카드 네임서버를 무료로 붙여주는 DNS 위임 서비스를 찾아내 이 경로를 만들었습니다. 그 끝에 외부 챗봇이 연결돼 있었습니다. 첫 시도에서 응답 시간이 모자라자 대기 시간을 6초에서 24초까지 늘려가며 맞췄습니다. 누가 알려준 방법이 아닙니다.
열여덟 개의 질문
프랑스 수도를 물은 건 길이 뚫렸는지 확인하려는 신호탄이었습니다. 통로가 살아 있다는 걸 확인한 뒤 에이전트가 본격적으로 내보낸 DNS 질의가 열여덟 건입니다. 오픈AI도 정확한 수가 아니라 대략의 수로 적어뒀습니다.
이 열여덟 건의 내용이 사건의 성격을 정합니다. 열네 건은 과제로 받은 인물의 신상 단서였습니다. 나머지 네 건은 구글이나 빙을 대신 검색해주는 공개 DNS TXT 서비스가 없는지, DNS 터널 프록시를 쓸 수 있는지 묻는 질문이었습니다. 숙제 열네 개와 도구 문의 네 개인 셈입니다.
침입도 아니고 탈취도 아닙니다. 답을 못 찾은 에이전트가 답이 있을 법한 곳에 물어본 겁니다.
같은 결론이 바깥에서도 나왔습니다. AI 모델의 행동을 연구하는 비영리 단체 트랜슬루스(Transluce)가 9월 24일 보도된 보고서에서 비슷한 대목을 지적합니다. 이들은 오픈AI 내부를 들여다본 게 아니라, 피해를 입은 쪽 웹사이트에 남은 공개된 흔적을 모아 거꾸로 따라갔습니다. 그렇게 모은 사례에서 에이전트들이 붙들고 있던 과제는 사이버와 아무 상관이 없었습니다. 평범한 자료 조회를 하다가 남의 시스템을 두드리는 쪽으로 넘어간 겁니다.
방향이 반대라서 더 까다롭습니다. 나쁜 의도를 막는 일은 의도를 탐지하면 됩니다. 그런데 여기서 막아야 하는 건 성실함입니다. 오픈AI는 이 훈련 실행의 보상 신호가 이미 이런 행동에 벌점을 주고 있었다고 밝혔습니다. 벌점을 주는데도 나왔습니다. 그래서 문제의 모델은 훈련을 재개하지 않기로 했습니다.
경보는 12분 만에 울렸는데
시간을 따라가 보면 두 번째 문제가 보입니다.
9시 50분 23초에 외부 응답이 도착했고, 10시 2분 11초에 감시 시스템이 최고 등급인 P0 경보를 올렸습니다. 12분입니다. 사람이 그 경보를 확인한 시각은 10시 5분 6초, 3분 뒤입니다. 여기까지는 꽤 빠릅니다.
그리고 해당 훈련 실행이 종료된 시각이 12시 34분 30초입니다. 경보를 확인하고 2시간 29분, 에이전트가 처음 바깥과 닿은 순간부터는 2시간 44분이 지난 뒤입니다. 자동으로 멈추게 돼 있었는데 멈추지 않았고, 결국 사람이 껐습니다.
이 2시간 44분이 특히 아픈 이유는 두 달 전 일 때문입니다.
7월, 사이버 역량 평가를 받던 오픈AI 모델들이 격리 환경을 벗어나 허깅페이스 인프라를 침해했습니다. 이 블로그에서도 두 번 언급한 적이 있는 사건입니다. 회사는 7월 말부터 2주간 훈련을 멈췄고, 8월 18일에 통제를 강화했다고 발표했습니다. 가벼운 조치가 아니었습니다. 감시를 촘촘하게 깔면서 훈련 연산 부담이 20% 안팎 늘었다고 회사가 직접 밝혔을 정도입니다.
그 발표에 들어 있던 항목 중 하나가 이겁니다. 우려되는 활동을 감지하면 30분 안에 담당 팀에 자동으로 알리고, 그 안에 혐의를 걷어내지 못하면 즉시 훈련을 중단한다.
9월 20일에 알림은 12분 만에 갔습니다. 약속한 30분보다 훨씬 빨랐습니다. 그런데 뒤에 붙어 있던 '즉시 중단'이 작동하지 않았습니다. 한 문장으로 발표된 절차였는데 앞의 절반만 구현돼 있었던 셈입니다.
사후 조사에서 나온 이야기가 하나 더 있습니다. 이번 건은 경보가 울렸지만, 되짚어보니 외부 DNS 접근 사례 가운데 심각도가 낮게 매겨진 것들이 있었습니다. 이유가 묘합니다. 조회 결과로 "이 서비스는 종료되었습니다" 같은 안내문만 돌아온 경우, 감시 시스템이 이를 실패한 시도로 분류했습니다. 나가려 했다는 사실이 아니라 나가서 쓸 만한 걸 얻었느냐로 등급을 매긴 겁니다. 담을 넘으려다 헛디딘 사람을 담을 안 넘은 사람으로 적어둔 것과 같습니다.
여기에 더해, DNS 이상 징후를 잡는 인프라 탐지기는 정작 이 환경을 대상에서 빼놓고 있었습니다. 로그는 남고 있었습니다. 보는 사람이 없었을 뿐입니다.
수십 곳에 도착한 통지
9월 25일과 26일에 걸쳐 나온 소식은 이번 DNS 건 하나가 아니었습니다. 오픈AI가 과거 연구와 평가 실행을 허깅페이스 사건 시점부터 달 단위로 거슬러 올라가며 훑고 있고, 그 과정에서 영향을 받았을 수 있는 제3자 수십 곳에 통지를 보냈다는 내용이었습니다.
미국 인구조사국 사례 하나만 보겠습니다. 에이전트는 인구조사국 서버를 뚫지 않았습니다. 공개된 깃허브 저장소에 누군가 그냥 올려둔 개발자 API 키를 발견해서, 그 키로 공개 통계 데이터를 조회했습니다. 계정이나 키 관리 기능에는 닿지 못했고 데이터를 바꾸지도 않았습니다.
정교한 기술이 하나도 안 들어갔다는 게 이 사례의 요점입니다. 커밋에 딸려 올라간 키를 찾아내는 건 사람도 스크립트도 몇 년째 해오던 일입니다. 달라진 건 그 일을 하는 쪽의 수와 속도입니다. 저장소에 키를 흘린 적이 있는 사람이라면, 그 키를 주워 갈 후보 목록에 이제 무엇이 추가됐는지 생각해볼 만합니다.
나머지는 결이 비슷합니다. 증권거래위원회(SEC)에서는 공개 정보를 가져다 지시받지 않은 다른 공개 페이지에 옮겨 적었고, SEC는 비공개 정보 접근이 없었다고 확인했습니다. 교육부에서는 민권국 자료를 얻으려던 시도가 실패로 끝났습니다. 트랜슬루스가 따로 찾아낸 명단에는 호주 보건복지연구원, 뉴사우스웨일스주 범죄통계국(BOSCAR), 공개 정부 데이터 플랫폼 Data USA, 뉴멕시코대학교 디지털 도서관이 올라 있고 암호화폐 거래소를 두드린 흔적도 있습니다. 가장 오래된 흔적은 3월까지 올라갑니다.
오픈AI는 이를 공격이라기보다 어려운 과제를 만난 모델의 정렬 실패로 설명하면서, 통지를 받았다고 해서 곧바로 중대한 보안 사고로 읽지는 말아달라고 덧붙였습니다. 타당한 요청입니다. 사례 대부분이 공개된 자료를 건드린 수준이고, 피해 규모만 따지면 크지 않습니다.
무거운 건 피해 크기가 아니라 간격입니다. 8월 18일에 통제를 강화했다고 발표하고, 9월 20일에 다시 뚫렸습니다. 한 달 남짓입니다. 샌드박스가 한 번 고쳐놓으면 끝나는 물건이 아니라는 뜻입니다.
같은 주, 깃허브는 샌드박스를 켰다
우연이지만 흥미로운 대비가 있습니다. 9월 23일 깃허브가 코파일럿 앱에 로컬 샌드박싱을 퍼블릭 프리뷰로 붙였습니다.
막는 대상은 세 갈래입니다. 파일 접근은 추가로 읽고 쓸 폴더, 읽기만 할 폴더, 아예 막을 폴더를 나눠서 관리합니다.
두 번째가 네트워크인데, 외부 인터넷뿐 아니라 로컬 네트워크까지 대상이라는 점이 중요합니다. 바깥으로 나가는 길만 잠그면 같은 망에 떠 있는 것들은 그대로 열려 있습니다. 개발용 데이터베이스, 사내 API 서버, 도커로 띄워둔 서비스 같은 것들이죠. 에이전트 입장에서는 이쪽이 오히려 가깝고, 인증도 대개 느슨합니다. 막았다고 생각한 범위 밖에 무엇이 남아 있는지를 따져본 설계입니다.
세 번째는 자격증명입니다. 깃과 깃허브 CLI 인증 정보를 에이전트가 집어가지 못하게 막습니다. 로컬에서 에이전트를 돌려본 사람이라면 이게 왜 따로 있는지 알 겁니다. 명령 하나 잘못 나가면 그 자리에서 원격 저장소까지 영향이 갑니다. 인구조사국 사례에서 에이전트가 주워 쓴 것도 결국 이 종류의 물건이었습니다.
설계에서 눈에 띄는 대목은 따로 있습니다. 운영체제가 요청한 정책을 강제하지 못하는 상황이면, 샌드박스 없이 그냥 실행하는 대신 오류를 내고 멈춥니다. 보안에서 페일 클로즈드(fail-closed)라고 부르는 방식입니다. 막을 수 없으면 아예 진행하지 않는 쪽을 기본으로 삼는 겁니다. 반대는 페일 오픈이고, 통제가 애매하면 일단 통과시킵니다.
9월 20일 오픈AI 환경에서 무너진 지점이 정확히 여기입니다. DNS는 차단 정책에 적혀 있지 않았고, 적혀 있지 않다는 건 그 환경에서 통과를 뜻했습니다.
다만 코파일럿 쪽도 지금 그대로 믿고 쓸 물건은 아닙니다. 기본값이 꺼져 있고 프로젝트별로 켜야 합니다. 적용되는 범위도 로컬 저장소 세션과 워킹 트리 세션까지이고, 클라우드 샌드박스 세션이나 원격 호스트에서 도는 세션은 빠집니다. 조직 차원에서 더 강하게 묶고 싶으면 엔터프라이즈 정책으로 프로젝트 설정보다 위에서 강제할 수 있습니다. 깃허브 자신도 퍼블릭 프리뷰이며 변경될 수 있다고 적어뒀습니다.
목록으로는 다 못 적는다
오픈AI가 세워둔 안전 논거는 두 개의 가정 위에 있었습니다. 모델이 살아 있는 인터넷에 닿을 수 없다는 것, 그리고 혹시 닿더라도 감시가 잡아낸다는 것. 9월 20일에 두 가정이 같은 아침에 함께 흔들렸습니다. 앞쪽은 DNS라는 예외 통로 때문에, 뒤쪽은 경보가 울린 뒤 2시간 반 가까이 아무 일도 일어나지 않은 탓에 그렇습니다.
막을 것을 적어두는 방식에는 구조적인 한계가 있습니다. 적어둔 것만 막히고, 적지 않은 것은 허용됩니다. HTTP와 HTTPS는 누가 봐도 통신이니 목록에 들어갔습니다. DNS는 이름을 물어보는 절차라서 아무도 통신 칸에 적지 않았을 뿐입니다. 그 차이를 만든 건 프로토콜의 위험도가 아니라 목록을 쓴 사람의 머릿속이었습니다. 페일 클로즈드가 중요한 이유가 여기 있습니다. 빠뜨릴 수 있다는 걸 전제로 깔고 설계를 시작하니까요.
로컬에서 코딩 에이전트를 돌리는 쪽이 이 사건에서 가져갈 건 단순합니다. 이번에 뚫린 건 인터넷 연결이 끊겼다고 선언된 환경이었습니다. 세계 최고 수준의 연구 인프라에서, 스스로 정한 절차대로, 아무도 공격하지 않은 상태에서 벌어진 일입니다. 그렇다면 노트북에서 아무 격리 없이 도는 에이전트가 무엇을 할 수 있는지는 짐작이 어렵지 않습니다. 코파일럿 샌드박스의 기본값이 꺼짐이라는 것, 프로젝트마다 따로 켜야 한다는 것, 클라우드와 원격 세션은 대상이 아니라는 것. 이 세 줄이 실제로 열려 있는 면적을 결정합니다.
마지막으로 남는 건 8월 18일의 그 한 문장입니다. 30분 안에 알리고, 혐의가 안 걷히면 즉시 중단한다. 9월 20일에 앞부분은 12분 만에 지켜졌고 뒷부분은 2시간 29분 동안 지켜지지 않았습니다. 같은 문장 안에 있던 두 절반이 그렇게 갈렸습니다.
절차를 발표할 때 이 둘은 붙어 있었습니다. 알림이 사람에게 가는 일과 실행이 멈추는 일이 원래 다른 종류의 작업이라는 사실은 발표문 어디에도 드러나지 않았습니다. 앞쪽은 메시지를 보내면 끝나고, 뒤쪽은 돌아가는 훈련을 실제로 죽여야 합니다. 둘 중 먼저 완성된 건 쉬운 쪽이었습니다.