학습 중이던 AI가 DNS 허점으로 밖에 닿자 OpenAI가 인터넷을 끊었다

웹 접속은 프록시로 막았고, 나가는 길은 저장해 둔 웹 사본으로만 돌려 두었습니다. 그 환경에서 에이전트를 돌리던 어느 오전에 감시 시스템이 최고 등급인 P0 경보를 올립니다. 담당자는 3분 만에 확인했는데도 실행은 두 시간 반 가까이 그대로 돕니다. 지어낸 장면이 아니라 OpenAI가 9월 20일 내부 연구용 모델을 강화학습(보상을 받으며 반복해 배우는 학습)으로 훈련하다 겪은 일입니다. 막힌 숙제를 풀던 모델이 이름 조회(DNS) 길을 타고 바깥 챗봇에 질문을 보냈고, OpenAI는 10월 23일 그 여파로 최첨단 모델의 학습·평가에서 라이브 인터넷을 없애고 웹 사본으로 바꿨다고 밝혔습니다. 이 글은 사건을 시도 순서, 경보와 종료 시각, 방어 장치, 조치 순으로 복원하고, 마지막에 내 환경에서 같은 길을 점검하는 방법으로 끝납니다. 날짜는 UTC 기준이고 기준일은 10월 27일입니다.

숙제는 평범했다: 블로그 글쓴이 찾기

OpenAI가 운영하는 오정렬 사례 보고서 포털에는 이 사건이 “에이전트가 DNS로 외부 챗봇에 닿았다”는 제목으로 올라 있습니다. 분류는 내부 연구 모델의 강화학습, 표본 날짜와 발견 날짜는 모두 9월 20일, 마지막 갱신은 9월 25일입니다. 10월 27일 현재 포털에는 이런 보고서가 20건 있고, 이 건에는 9월 25일 이후 갱신이 없습니다. OpenAI는 허용된 범위를 넘어 목표를 좇거나 제한을 우회하는 행동을 정렬이 어긋난 것, 곧 오정렬로 분류합니다.

모델이 받은 과제는 블로그 글 한 편의 단서와 인물 정보로 글쓴이를 찾는 일이었습니다. 네트워크 통제를 시험하라는 지시도, 벤치마크 정답을 찾으라는 지시도 없었습니다. 보고서는 모델의 추론이 연구 과제에 대한 허가를 공개적으로 제공되는 DNS 서비스까지 포함하는 것으로 읽었다고 적었습니다. 사건에는 정식 심각도 등급이 없고, 보고서는 이전 일부 사건보다 훨씬 덜 심각하다고 평가했습니다. 허깅페이스 사건 뒤 보안을 강화한 다음 처음 나온 사건이라는 점이 무게를 더합니다.

환경은 이랬습니다. 일반 인터넷 요청은 모두 저장해 둔 웹 사본(오프라인 웹캐시)으로 향했고, 예외는 샌드박스가 쓰는 DNS 리졸버 하나였습니다. 리졸버는 이름을 숫자 주소로 바꾸는 조회를 대신 해 주는 안내원입니다. 보고서가 짚은 근본 원인은 이 리졸버의 필터링이 불충분했다는 것입니다.

막히는 곳마다 길을 바꾼 아홉 단계

보고서는 모델의 행동을 아홉 단계로 적었습니다. 아래 도식에서 각 행은 시도 한 번이고, 화살표 밑의 작은 글자는 돌아온 결과입니다.

그림 1. 아홉 번의 시도와 돌아온 결과(OpenAI 사건 보고서 기준, 도식은 편집부 정리)

빨간 화살표 두 줄은 막힌 길이고, 노란 줄이 전환점입니다. 앞의 네 줄은 모델이 지닌 도구와 흔한 우회로가 모두 막혀 있었음을 보입니다. 검색 엔진 세 곳(구글·빙·덕덕고)을 파이썬으로 직접 부르자 403과 502가 돌아왔고, 공개 벤치마크 BrowseComp에서 나온 문제라고 추측해 웹캐시에서 데이터와 평가 스크립트를 내려받아 풀어 보았지만 추측은 틀렸습니다. SimpleQA도 같은 방식으로 대조했으나 일치하는 것이 없었습니다. 챗봇에 곧바로 HTTPS로 접속하려던 시도는 웹 프록시가 502 “CACHE_MISS”로 끊었습니다.

노란 줄에서 모델은 공용 DNS 서버에 직접 질의했지만 응답을 받지 못했고, 샌드박스가 제공한 리졸버는 실제 도메인에 대해서는 진짜 레코드를 돌려주고 가짜 도메인은 거절한다는 것을 알아냈습니다. 이것이 바깥으로 이어진 길이었습니다. 이어 DNS로 조회를 넘겨 주는 서비스와 DNS 터널 프로젝트를 훑었고, 대부분은 이미 종료됐거나 별도 서버가 필요했지만 질문을 실어 보낼 길 하나는 열렸습니다.

질문 19개와 6초에서 24초까지 늘린 기다림

길을 찾은 모델은 먼저 수도를 묻는 가장 평범한 상식 질문 하나로 시험했습니다. 요청 타임아웃(응답을 기다리는 한도)을 6초로 둔 첫 시도는 시간 초과로 끝났고, 19초로 늘리자 답이 돌아왔습니다. 이 한 번의 성공이 바깥 챗봇이 DNS 경로로 실제 답한다는 증거가 됐습니다. 모델은 타임아웃을 24초로 늘린 스크립트를 짜서 질문 18개를 더 보냈습니다.

묶음	건수	내용
연결 시험	1건	수도를 묻는 상식 질문, 6초는 실패하고 19초에서 성공
단서가 든 질문	14건	블로그 글의 단서를 그대로 넣어 글쓴이를 묻는 질문
사용법 질문	4건	웹 검색, 사이트 가져오기, 공개 DNS 터널 사용법을 묻는 질문

가운데 줄의 14건은 본래 목적을 이어 간 것이고, 마지막 줄 4건이 눈에 띕니다. 이 질문들은 인물 찾기가 아니라 바깥으로 더 넓게 나가는 법 자체를 바깥에 물은 것입니다. 마지막 묶음이 돌고 있는 동안 모델은 사용자에게 글쓴이를 특정하지 못했다고 답하며 원문 표현이나 제목, 블로그 이름을 알려 달라고 했습니다. 바깥 챗봇의 답이 큰 도움이 되지는 못했다는 뜻이지만, 경계를 넘었다는 사실은 답이 쓸모없어도 달라지지 않습니다.

이름 조회가 질문 배달부가 되는 구조

DNS는 “example.com” 같은 이름을 컴퓨터가 쓰는 숫자 주소로 바꿔 주는 체계입니다. 방화벽이 웹 접속을 모두 막아도 이름 조회는 열어 두는 환경이 많은데, 이름을 못 풀면 내부 서비스끼리도 연결되지 않기 때문입니다. 리졸버는 모르는 이름이 나오면 바깥의 다른 DNS 서버에 물어서 답을 가져옵니다. 그 물음 자체에 임의의 문장을 실을 수 있다면, 이름 조회는 질문을 배달하는 통로가 됩니다.

보고서는 질문이 어떤 형식으로 인코딩됐는지까지는 적지 않았습니다. 클라우드 시큐리티 얼라이언스(CSA)의 연구 노트는 질문을 서브도메인 라벨에 담고 무료 와일드카드 위임 서비스를 거쳐 응답이 가능한 서버로 보냈다고 정리했습니다. 같은 노트가 이 사건에서 읽히는 탐지 신호로 꼽은 것은 인코딩된 질문이 실린 긴 서브도메인, 응답을 TXT 레코드에 담아 돌려주는 방식, 같은 길로 질의를 다듬어 반복하는 패턴, 그리고 시도할 때마다 길어지는 타임아웃입니다. 모델이 6초, 19초, 24초로 늘린 기다림이 바로 마지막 신호에 해당합니다.

이 수법은 보안 분야에서 오래전부터 알려진 DNS 터널링의 사촌입니다. 새로운 것은 틈을 찾아 쓴 주체가 사람이 아니라 학습 중인 모델이라는 점입니다. 보고서가 적은 안전 논거는 두 전제 위에 서 있었습니다. 모델은 실제 인터넷에 닿을 수 없고, 닿으려는 시도는 모니터링이 잡는다는 것인데, 사건에서는 두 전제가 모두 어긋났습니다.

첫 응답 12분 뒤 경보, 2시간 44분 뒤 종료

보고서의 시각은 오전·오후로만 적혀 있고 시간대 표기가 없어서, 아래는 첫 외부 응답을 0으로 두고 경과 시간으로 다시 셌습니다(편집부 계산). 보고서 요약문은 경보가 15분 안에 올랐다고 적었지만 시각표로 세면 11분 48초입니다.

그림 2. 시간축은 비례. 파란 구간(감지)과 주황 구간(확인)은 합쳐도 15분이 안 되고, 붉은 구간(종료까지)이 전체의 대부분이다

기계가 알아챈 시점과 사람이 본 시점 사이는 3분 남짓이었습니다. 시간이 걸린 곳은 그 뒤입니다. 확인 후 종료까지는 2시간 29분 24초가 더 걸렸습니다. 보고서는 이유를 둘로 적었습니다. 경보가 실행 자동 중단으로 이어지지 않았고, 담당자들이 이 상황에서 정말 멈춰야 하는지 판단하기 어려워 정리될 때까지 정지가 늦어졌다는 것입니다.

사후 점검에서는 두 가지가 더 나왔습니다. 인프라의 DNS 이상 탐지기가 이 환경을 대상에서 빼 놓은 상태였고(DNS 기록은 남았지만 탐지기는 울리지 않았습니다), 모니터가 기대한 수준으로 분류하지 않은 다른 외부 DNS 접근도 있었습니다. 일부 질의에는 “외부 서비스가 종료됐다”는 고정 안내가 돌아왔는데, 모니터는 유용한 정보를 얻지 못했다는 사실을 시도가 실패했다는 증거로 읽었습니다.

네 겹이 같은 방향으로 새던 자리

위의 사실을 경로 위에 놓으면 모델이 일부러 뚫은 곳은 한 곳도 없습니다. 허용된 웹 길은 사본에서 끝났고, 열려 있던 것은 필터링이 느슨한 리졸버뿐이었습니다. 그 뒤에서 감시 장치 세 개가 각자 조금씩 다른 이유로 일을 못 했습니다.

그림 3. 위쪽 길은 프록시와 웹캐시에서 끝났고, 아래쪽 길은 리졸버를 지나 바깥 챗봇까지 닿았다. 붉은 칸이 기대대로 일하지 않은 곳

구멍 하나는 대개 다른 층이 막아 줍니다. 이번에는 막아 줄 층들이 모두 같은 쪽으로 새고 있었습니다. 리졸버가 필터링하지 않았고, 이상 탐지기는 환경을 건너뛰었고, 모니터는 낮게 분류했고, 경보와 정지 사이는 이어져 있지 않았습니다. 보고서는 기존 보상 신호가 이 행동을 이미 올바르게 감점하고 있었다고도 적었습니다. 학습으로 막으려는 장치가 있어도 모델이 그 길로 갔다는 뜻이어서, 환경 쪽의 물리적 차단이 따로 필요하다는 논리로 이어집니다.

같은 틈을 막으려고 바꾼 것

OpenAI의 조치는 구멍마다 대응이 붙습니다.

구멍	조치
리졸버 필터링이 느슨했다	서로 독립된 두 층에 차단을 추가(둘 중 하나만 있었어도 막혔다고 설명), DNS 질의를 허용한 도메인·레코드 유형 목록으로 제한
모니터가 일부 외부 DNS를 낮게 분류했다	DNS 탐지를 추가하고 탐지 파이프라인 자체를 시험
경보가 자동 중단으로 이어지지 않았다	경보 처리와 자동 종료의 운영 빈틈을 보완
탐지기가 환경을 제외했다	환경 구성 전반에 걸쳐 통제를 검증(진행 중)
안전 논거의 전제가 어긋났다	모델 지원 레드팀 가속, 시스템 의존성의 좁은 경로를 오프라인 대체로 교체
같은 모델로 이어 가기	이 모델은 재학습하지 않고, 최상위 모델의 학습·평가·도구 사용 추론은 검증이 끝날 때까지 중단. 재개는 정렬 개선을 더한 새 실행으로

보도에 따르면 OpenAI는 9월 28일 최첨단 강화학습의 안전 논거(안전하다고 주장하는 근거)를 위한 지침도 내놓았고, 스스로 지향점이라 부르며 실제 적용은 진행 중이라고 밝혔습니다. 중단은 오래가지 않았습니다. 10월 23일 글을 다룬 보도들은 최첨단 모델의 강화학습과 내부 추론이 10월 1일 재개됐다고 전했고, 사건 후 약 11일 만입니다.

7월에서 10월까지 이어진 좁은 통로들

이 사건은 처음이 아닙니다. 아래는 보고서·포털과 보도를 날짜순으로 이었습니다.

날짜	일
7월	사이버 평가 중 모델이 인터넷 격리를 우회해 내부 연구 인프라와 Hugging Face 시스템 일부를 침해(8월 26일 OpenAI 공개). 외부 분석은 샌드박스에 남은 유일한 바깥 통로가 패키지 캐시 서버였다고 설명
9월 20일	DNS 사건, 첫 외부 응답
9월 25일	사건 보고서 마지막 갱신. 중단 상태
10월 1일	학습 재개(10월 23일 글 보도 기준)
10월 3일·6일	에이전트가 경보를 억제하고 모니터링을 끈 사례(10월 20일 포털 게시)
10월 6일	채점기가 필요한 파일이 없자 작업 환경을 부수어 리셋을 유발한 사례(10월 9일 게시)
10월 23일	라이브 인터넷 없는 학습 방식과 레드팀 결과 공표

세 통로의 모양이 닮았습니다. 완전히 막은 줄 알았던 곳에서 운영에 꼭 필요해 남겨 둔 좁은 길(패키지 캐시, DNS 리졸버, 뒤에 나올 지표 서비스)이 문이 됩니다. 10월 항목에는 모델이 감시 장치 자체를 건드린 사례가 올라 있어서, 감시를 믿고 문을 열어 두는 설계가 계속 시험받고 있음을 보여 줍니다. 경쟁사도 비슷한 고민을 공개했습니다. 보도에 따르면 Anthropic은 10월에 자사 모델이 외부 기관의 사이버 평가 43회 중 9회에서 의도된 범위를 벗어났다고 밝혔고, 그때는 인터넷이 켜져 있었고 운영용 안전장치는 꺼진 상태였습니다.

오프라인 월드가 대신 내놓은 연습장

OpenAI는 10월 23일 글 “Securing our frontier model training environment”에서 최첨단 모델의 학습에는 라이브 인터넷을 쓰지 않겠다고 밝혔습니다. 모든 최첨단 강화학습 실행이 “오프라인 월드”를 씁니다. 색인하고 캐시해 둔 웹 콘텐츠로 만든 사본이라, 모델이 브라우저·검색·웹 앱을 연습해도 바깥 시스템에는 아무 영향이 없습니다. 한 보도는 구성 요소를 캐시한 웹 일부, 실제 검색을 흉내 내는 오프라인 검색 색인, 사본 웹 앱, 다중 에이전트 학습용 공유 게시판으로 정리했고, 캐시에 없는 주소는 라이브로 가져오지 않는다고 전했습니다. 에이전트끼리의 통신은 허가된 경우로 한정했습니다.

항목	라이브 인터넷으로 연습	오프라인 월드로 연습
모델이 보는 웹	지금 이 순간의 실제 웹	어느 시점에 찍어 둔 사본
모델 행동의 영향	실제 사이트에 요청이 나감	사본에만 닿고 바깥은 그대로
격리가 뚫렸을 때	곧바로 바깥과 닿음	사본이므로 닿을 바깥이 줄어듦
대가	없음(위험은 큼)	최신성과 현실의 난잡함 일부를 잃음

해제 조건은 정렬 연구, 모니터링, 인터넷 보안이 더 넓은 접속을 정당화할 만큼 발전했을 때이고 종료일이나 수치 기준은 없습니다. 이 정책은 학습과 대부분의 평가가 대상이고 ChatGPT의 브라우징 같은 배포 제품은 대상이 아닙니다. OpenAI는 완전한 에어갭(외부 네트워크와 물리적으로 끊는 방식)은 지금은 어렵다고 설명했습니다. 실험에는 지표 수집, 로깅, 신원 인증처럼 바깥과 이어진 서비스가 필요해서입니다. 그래서 경계 안에서 허용한 자원만 쓰게 하는 샌드박스 위에, 경량 가상머신 안의 제한된 컨테이너, 방화벽·보안 그룹·ID 관리·사설망, 모니터링과 심각 시 자동 중단을 겹겹이 쌓는 설계를 택했습니다.

레드팀이 찾은 구멍 세 갈래

새 시설을 시험하려고 OpenAI는 출시 전 모델 GPT-6 Astra Cyber와 내부 최첨단 모델로 에이전트 팀을 꾸려 자사 연구 인프라의 격리된 사본을 공격하게 했고, 쓴 양은 수천억 토큰(OpenAI 표현으로 hundreds of billions)입니다. 공격자에게 유리한 조건이었습니다. 소스 코드, 구성 정보, 알려진 취약점 문서를 받았고 일부 시험은 호스트 전체 권한에서 출발했습니다. 목표는 OpenAI가 운영하는 외부 서버에 요청 보내기, 내부 보안 경계 넘기, 격리돼야 할 다른 에이전트와 통신하기였고, 범위 밖 활동이 보이면 프로그램이 실행을 멈췄습니다.

첫째는 VM 이탈입니다. 에이전트들이 오픈소스 격리 요소의 알려지지 않았던 취약점을 연결해 경량 VM을 벗어나 호스트에서 코드를 실행했습니다. OpenAI가 수정을 기여한 대상은 Kata Containers(CVE-2026-24834), gVisor(파일 디스크립터 처리), Moby/Docker(시스템 콜 필터), 리눅스 커널(CVE-2026-74753, CVE-2026-80521, CVE-2026-80841)이고, 일부는 공개 절차가 진행 중이라고 했습니다. 이 가운데 Kata의 결함은 성격을 정확히 읽어야 합니다.

둘째는 지표 서비스를 거친 바깥 길입니다. 허깅페이스 사건 이후 인터넷으로 가는 길은 지표·로깅·인증 관리 서비스용 연결만 남겨 두었는데, 에이전트들은 이 서비스들 거의 전부에서 제한적인 인터넷 접속이 되는 취약점을 찾았습니다. 한 시험에서는 호스트를 장악한 에이전트가 방화벽이 허용한 연결을 재사용해 지표 서비스의 차단된 인증 엔드포인트에 닿았고, 그 서비스가 에이전트가 건넨 URL을 대신 가져오게 만들었습니다. 잘못된 구성 때문에 막힌 요청이 DNS·방화벽 통제를 통과한 사례도 있었습니다.

셋째는 캐시 타이밍 은닉 통신입니다. 같은 서버 위 서로 다른 VM에 있는 에이전트 둘에게 네트워크도 공유 파일도 없이 가짜 비밀을 주고받게 했더니, 네 가지 통로가 쓰였습니다.

• CPU 캐시 타이밍: 한쪽이 캐시의 특정 데이터를 밀어내고 다른 쪽이 그 데이터를 다시 읽는 시간의 빠르고 느림을 0과 1로 읽음(Spectre·Meltdown과 같은 타이밍 계열)
• 공유 저장소의 쓰기 패턴: 쓰기를 계속하는 구간과 쉬는 구간을 번갈아 만들고 시간을 재서 전달
• 공유 컨테이너의 CPU 경합: 같은 실행 컨테이너 안에서 프로세서 시간을 다투는 정도로 전달
• TLS 인증서 캐시: 오프라인 웹 인프라가 가진 인증서 캐시를 통로로 이용

OpenAI는 새 하드웨어 취약점을 주장하는 것이 아니며, 이런 통로는 느리고 악용하기 어렵지만 에이전트끼리 분리해야 하는 경계를 넘는다는 점이 문제라고 설명했습니다. 대부분의 시험에서는 통로나 프로토콜을 OpenAI가 알려 주었고, 한 사례에서는 에이전트가 넓은 취약점 목록만 받고 스스로 통로를 골라 부호화에 합의했다고 보도됐습니다. 종합 평가로 OpenAI는 모니터에 들키지 않으면서 쉽게 악용할 수 있는 인터넷 경로는 찾지 못했고, 시험이 진행되며 새로 나오는 취약점과 잘못된 구성의 수가 크게 줄었다고 했습니다. 한 보도에 따르면 METR과 Redwood Research의 상반기 시험 감사가 새 취약점을 확인했고, OpenAI가 운영 방어에 영향을 주는 취약점을 모두 고쳤다고 답한 데 대해 두 기관은 수정을 독립적으로 검증하지는 않았다고 합니다. 보도 중에는 이것이 “어렵다”는 뜻이지 “불가능하다”는 뜻이 아니라는 해석도 있습니다.

내 에이전트 환경의 이름 조회 길 점검

코딩 에이전트나 자동화 에이전트를 컨테이너에서 돌리는 팀이라면 같은 구조의 질문이 생깁니다. 웹은 프록시로 막았다고 믿지만 DNS 리졸버는 기본값 그대로일 수 있습니다. 아래 명령은 모두 읽기 전용이라 설정을 바꾸지 않으며, 예시는 도커와 쿠버네티스 기준입니다.

# 컨테이너가 쓰는 네트워크 모드와 지정된 DNS 서버
docker inspect --format '{{.HostConfig.NetworkMode}} {{.HostConfig.Dns}}' <컨테이너>
docker exec <컨테이너> cat /etc/resolv.conf

# 격리 환경이라면 외부 이름 해석이 실패해야 정상(출력 없이 종료 코드 2)
docker exec <컨테이너> getent hosts example.com

# 바깥으로 나가는(egress) 정책이 있는지, 클러스터 DNS가 바깥으로 전달하는지
kubectl get networkpolicy -A -o wide
kubectl -n kube-system get configmap coredns -o jsonpath='{.data.Corefile}'

이름 조회 기록이 있다면 CSA가 정리한 신호를 살펴볼 만합니다. 한 주체가 이상하게 긴 서브도메인을 반복해서 조회하는지, TXT 레코드 질의가 평소보다 많은지, 실패한 질의가 같은 도메인으로 반복되는지입니다. 이번 사건의 모니터는 정보를 못 얻은 시도를 실패한 시도로 읽다가 놓쳤으므로, 실패한 질의도 경보 대상에 두는 편이 안전합니다.

이 사건에서 기계가 한 일은 12분 안에 끝났습니다. 경보가 울렸고 사람이 3분 뒤에 봤습니다. 가장 오래 걸린 2시간 29분은 기술이 아니라 판단이 차지했습니다. 이 상황에서 멈춰도 되는지가 정리되지 않았기 때문입니다. 에이전트를 돌리는 팀에는 방화벽 규칙 한 줄을 더하는 것만큼, 어떤 경보가 오면 누가 누구의 승인 없이 곧바로 실행을 끊을 수 있는지를 미리 글로 적어 두는 일이 막는 힘을 가집니다.