오픈AI 샌드박스 탈출 — DNS로 뚫린 격리와 내 코딩 에이전트 점검

웹 요청은 프록시가 다 막고 있었습니다. 그런데 훈련 환경의 도메인 이름 조회기 하나가 바깥에 답을 물어다 줬고, 에이전트는 그 길로 외부 챗봇에 질문 18개를 더 보냈습니다.

지난 주말 국내에도 「오픈AI 에이전트가 샌드박스를 탈출했다」는 소식이 여러 블로그에 올라왔습니다. 대부분 해외 기사를 옮긴 요약이었는데, 오픈AI 정렬 연구 블로그에 사고 보고서 원문이 공개돼 있어 직접 읽어 봤습니다. 보고서는 생각보다 구체적입니다. 에이전트가 어떤 순서로 출구를 찾았는지, 감시 체계가 어디서 늦었는지가 시간 단위로 적혀 있습니다. 이 글은 그 내용을 정리하고, 같은 종류의 구멍이 내가 쓰는 코딩 에이전트 환경에도 있는지 확인할 거리를 덧붙였습니다.

짧게 정리하면

• 9월 20일 오픈AI 내부 연구 모델이 강화학습 훈련 중에, 훈련 환경의 이름 조회기를 통해 외부 챗봇 서비스에 질문을 보냈습니다.
• 감시 체계는 약 12분 만에 최고 등급 경보를 냈지만 실행은 자동으로 멈추지 않았고, 사람이 수동으로 끄기까지 두 시간 반이 걸렸습니다.
• 오픈AI는 가장 뛰어난 모델들의 훈련·평가·도구 사용 추론을 모두 멈췄고, 이름 조회를 허용 목록으로 좁히는 등 두 겹의 차단을 더했다고 밝혔습니다.

오픈AI 정렬 블로그의 사고 보고서(9월 25일 갱신본)를 기준으로 했고, 두 번째 훈련 중단이라는 맥락은 보도를 참고했습니다. 내 환경 점검 항목은 클로드 코드 샌드박스 문서와 대조했습니다.

에이전트는 무엇을 하려 했나

과제 자체는 평범했습니다. 어떤 사람이 쓴 블로그 글의 단서와 인적 사항을 주고, 그 사람을 찾아내라는 검색 과제였습니다. 네트워크 통제를 시험하라거나 정답을 구해 오라는 지시는 없었습니다. 에이전트는 먼저 주어진 검색 도구로 글의 특이한 문구를 찾았는데, 엉뚱한 결과만 나오자 도구가 고장 났다고 의심했습니다. 그다음 셸에서 파이썬으로 여러 검색 엔진에 직접 요청을 보냈고, 모두 403이나 502 오류로 막혔습니다.

여기서 에이전트는 방향을 바꿔 네트워크가 어디까지 열려 있는지 시험하기 시작합니다. 공개 챗봇에 웹으로 바로 붙는 요청은 프록시가 막았습니다. 공개 이름 조회 서버에 직접 묻는 요청에도 답이 없었습니다. 그런데 훈련 환경 자체의 이름 조회기는 실제 도메인에는 진짜 주소를, 지어낸 도메인에는 없다는 답을 정확히 돌려줬습니다. 에이전트는 이걸 바깥 인터넷으로 가는 통로로 판단했고, 호스트 이름에 질문을 실어 보내면 외부 서비스가 조회를 대신 처리해 주는 공개 이름 서비스를 이용해 외부 챗봇에 질문을 전달했습니다. 「프랑스의 수도는」이라는 시험 질문에 「파리」라는 답이 돌아오자, 문서를 읽고 새 스크립트를 짜서 질문 18개를 더 보냈습니다. 그중 14개에는 과제의 단서가, 4개에는 이름 조회로 웹을 검색하거나 터널을 여는 방법을 묻는 내용이 들어 있었습니다.

중간에 한 가지 더 눈에 띄는 행동이 있었습니다. 에이전트는 과제가 공개 웹 조사 벤치마크 문제를 번역한 것 같다고 짐작하고, 오프라인 캐시에서 그 벤치마크 데이터와 채점 스크립트를 내려받아 단서를 대조했습니다. 짐작은 틀렸고 일치하는 문제도 없었습니다. 오픈AI는 이처럼 제한을 우회하거나 합리적인 기대를 넘는 목표를 좇는 행동을 정렬 실패로 본다고 적었습니다. 결국 에이전트는 사람을 특정하지 못했다며 원문 문장이나 블로그 이름을 달라고 답하고 끝냈습니다.

감시는 잡았지만 멈추지 못했다

오픈AI 사고 보고서 기준, 9월 20일 사고 시간표(오전·오후는 보고서 표기)

시각	일어난 일
오전 9시 50분 23초	이름 조회 경로로 외부 응답을 처음 받음
오전 10시 2분 11초	정렬 이탈 감시 체계가 최고 등급 경보
오전 10시 5분 6초	사람 검토자가 슬랙 경보 확인
오후 12시 34분 30초	실행을 수동으로 중지. 자동 중지는 기대대로 동작하지 않음

보고서가 스스로 짚은 빈틈은 셋입니다. 첫째, 경보가 울렸는데 실행이 자동으로 멈추지 않아 멈춰야 하는지를 두고 혼선이 생겼습니다. 둘째, 사후 검토에서 감시 체계가 기대 등급으로 잡지 못한 다른 외부 이름 조회 사례들이 나왔습니다. 외부 서비스가 이미 문을 닫았다는 안내만 돌아온 경우처럼, 쓸 만한 정보를 못 얻었으면 접속 시도도 실패한 것으로 여긴 때가 있었다고 합니다. 셋째, 이상한 이름 조회 활동을 잡는 기반 시설 탐지기가 하필 이 환경을 검사 대상에서 빼 두고 있었습니다. 기록은 남아 있었는데 아무도 보지 않은 셈입니다.

대응도 적혀 있습니다. 둘 중 하나만 있어도 이번 접속을 막았을 차단을 서로 다른 두 층에 넣었고, 환경 안의 이름 조회를 정해진 도메인과 레코드 종류로만 제한했습니다. 이름 조회 탐지를 더 배치하고 탐지 경로 자체를 시험하기 시작했으며, 모델을 동원한 레드팀 점검도 앞당겼습니다. 이 모델의 훈련은 다시 이어 가지 않고, 재개할 때는 정렬 개선을 넣은 새 실행으로 시작한다고 밝혔습니다. 보고서는 이번 일이 7월 허깅페이스 사고보다 훨씬 가볍지만, 그 뒤 보안을 강화하고 나서 처음 생긴 사고라 다음에 어디를 막아야 할지 알려 준 신호라고 평가했습니다. 오픈AI가 이런 경우 훈련을 어떻게 멈추기로 했는지는 오픈AI 훈련 중단 원칙 글에 정리해 뒀습니다.

내 코딩 에이전트에 옮겨 보면

오픈AI 연구 환경과 내 노트북은 규모가 다르지만, 구조는 닮았습니다. 에이전트에게 셸을 주고 프록시로 나가는 길을 좁혀 둔 형태입니다. 클로드 코드의 샌드박스도 샌드박스 밖에서 도는 프록시가 허용한 도메인만 통과시키는 방식입니다. 이 문서를 다시 읽어 보니, 이번 사고와 겹쳐 볼 대목이 몇 군데 있었습니다.

오픈AI 사고의 빈틈과 클로드 코드 샌드박스 문서(2026년 9월 30일 확인)를 나란히 놓은 점검표

오픈AI에서 뚫린 곳	내 환경에서 볼 곳
웹 요청은 막았지만 이름 조회기는 바깥에 닿음	클로드 코드 문서는 이름 조회를 따로 다루지 않음. 샌드박스 안에서 모르는 도메인 조회가 실제로 답을 받는지 직접 시험
허용된 경로를 우회로로 씀	프록시는 요청한 호스트 이름만 보고 암호화 내용은 보지 않음. 깃허브처럼 넓은 도메인 허용은 유출 경로가 될 수 있다고 문서가 경고
탐지기가 해당 환경을 검사에서 뺌	샌드박스 예외 명령, 도커 소켓 같은 유닉스 소켓 허용, 도커 안용 약한 중첩 모드가 켜져 있는지 확인
경보 뒤 자동 중지가 안 됨	허용 목록 밖은 묻지 않고 거부하는 엄격 허용 목록 설정 검토(사용자·관리 설정에서만 유효)

첫 줄이 가장 중요합니다. 클로드 코드 샌드박스 문서에는 도메인 허용 목록과 프록시 설명은 자세한데, 이름 조회를 어떻게 다루는지는 적혀 있지 않습니다. 그러니 막혀 있다고 가정하지 말고, 샌드박스 안에서 이름 조회 명령으로 처음 보는 도메인을 한 번 물어보는 게 확실합니다. 샌드박스를 켰다고 생각했는데 실제로는 꺼져 있던 경우도 있으니 클로드 코드 샌드박스 여섯 가지에서 동작 범위를 먼저 확인해 두세요. 샌드박스는 셸 하위 프로세스만 가두고, 파일 읽기·쓰기 도구는 권한 체계로 따로 움직인다는 점도 문서에 적혀 있습니다.

이번 사고의 에이전트는 악의가 있어서가 아니라 과제를 끝내려다 출구를 찾았습니다. 검색이 안 되니 다른 길을 시험했고, 열린 길을 찾자 그대로 썼습니다. 내 코딩 에이전트도 설치가 막히거나 문서를 못 받으면 비슷하게 우회로를 찾을 수 있습니다. 샌드박스 안의 명령은 기본적으로 부모 프로세스의 환경 변수를 물려받아서, 터미널에 넣어 둔 인증 키도 함께 보입니다. 네트워크 출구 하나가 열려 있으면 그 키가 나갈 길도 생긴다는 뜻이니, 자격 증명 가리기 설정과 출구 점검을 같이 하세요.

읽기 전용 권한만 줘도 키가 새는 경로는 AI 에이전트 보안 격리 글에서, 플러그인 훅처럼 샌드박스 밖에서 도는 코드는 클로드 코드 플러그인 보안 글에서 다뤘습니다.

이틀 뒤 엔비디아는 통제를 모델과 에이전트 바깥에 두자는 오픈 에이전트 안전 플랫폼을 내놨습니다. 그중 실행 환경인 오픈셸은 무료 오픈소스라 맥이나 리눅스에서 바로 설치해 볼 수 있고, 에이전트에게 진짜 키를 보여 주지 않는 방식을 씁니다. 오픈셸에서 내 노트북으로 되는 것과 안 되는 것을 정리했습니다.

같은 흐름의 사고가 이미 6월에도 있었다는 사과문이 뒤이어 나왔습니다. 공개 통계를 찾던 모델이 호주 정부 서비스의 비공개 접근 경로와 노출된 접근 키를 찾아 썼고, 오픈AI는 8월 중순에야 이를 발견해 9월에 기관들에 알렸습니다. 호주 기관 네 곳 무단 접근 경위와 내 서비스 점검을 정리했습니다.

자주 묻는 질문

챗GPT나 코덱스 사용자에게 영향이 있나요

보고서 머리에 적힌 대상은 「내부 연구 모델, 강화학습 훈련」입니다. 공개된 제품을 쓰다 생긴 일이 아닙니다. 멈춘 범위는 「가장 뛰어난 모델들의 훈련·평가·도구 사용 추론」인데, 이것이 이미 출시된 제품 이용에 어떤 영향을 주는지는 보고서에 따로 나오지 않습니다.

실제 인터넷에 접속한 건가요

보고서에 따르면 이름 조회기를 뺀 나머지 인터넷 접속은 모두 오프라인 웹 캐시로 갔고 실제 인터넷에는 닿지 않았습니다. 외부로 나간 건 이름 조회 경로를 통한 질문과 그 답뿐입니다.

윈도우에서도 클로드 코드 샌드박스를 쓸 수 있나요

윈도우 자체에서는 지원하지 않습니다. 문서에 따르면 맥, 리눅스, 윈도우용 리눅스 하위 시스템 2판에서 동작하므로 윈도우에서는 그 리눅스 배포판 안에서 클로드 코드를 실행해야 합니다.

훈련 중단이 처음인가요

보고서는 7월 허깅페이스 사고 이후 보안을 강화한 뒤 처음 생긴 사고라고 적었습니다. 해외 보도는 석 달이 안 되는 사이 두 번째 훈련 중단이라고 전했습니다.

이 보고서에서 제일 무서운 대목은 탈출 수법이 아니라 에이전트의 판단 흐름입니다. 도구가 이상하면 의심하고, 다른 길을 시험하고, 열린 길은 쓴다는 흐름은 우리가 좋은 에이전트에게 바라는 끈기와 구분하기 어렵습니다. 그래서 막는 쪽도 「여기는 막았겠지」가 아니라 「어디가 열려 있나」를 직접 재 봐야 합니다. 저라면 오늘 샌드박스 안에서 이름 조회 한 번, 허용 도메인 목록 한 번, 환경 변수에 든 키 목록 한 번을 확인하겠습니다.

확인한 곳: 오픈AI 정렬 블로그 「에이전트가 이름 조회로 외부 챗봇에 닿았다」 사고 보고서(표본·발견 9월 20일, 9월 25일 갱신), 클로드 코드 문서 「샌드박스 설정」의 네트워크 격리와 한계 절, 두 번째 훈련 중단 맥락은 포천 보도(9월 26일). 2026년 9월 30일 기준입니다.