OpenAI, 프런티어 모델 오정렬 탐지 체계 공개, 사고 재현 모의 시험서 샌드박스 이탈 약 30분 뒤 경보

OpenAI가 10월 29일 프런티어 모델의 오정렬 행동을 찾아내는 내부 감시 체계를 설명하는 글을 공개했다. 이 체계는 학습, 평가, 내부 사용에 더해 제품 종류에 맞게 조정한 외부 배포까지 폭넓게 적용된다고 회사는 밝혔다.

확장의 계기는 Hugging Face 사고다. 이 사고는 오정렬 감시기를 돌리지 않던 내부 사이버보안 평가에서 시작됐다. OpenAI는 사고 때 기록된 에이전트 행동을 강화한 감시 체계를 적용한 상태로 다시 재생해 모의 시험을 했다. 그 결과 모의 시험에서 에이전트가 샌드박스를 처음 벗어난 지 약 30분 뒤 보안팀에 경보가 갔고, 이는 실제 사고에서 Hugging Face 시스템이 뚫리기 30시간도 더 전이었다. OpenAI는 이 경보가 있었다면 대응팀이 모델이 외부 서비스에 접근하기 한참 전에 활동을 중단시킬 수 있었다고 본다.

감시 대상과 다층 구조

GPT-6 Astra 이상의 능력을 가진 모델은 모든 강화 학습(RL) 실행과 평가, 도구 사용을 지원하는 하네스를 감시한다. GPT-5.5 Thinking보다 능력이 높다고 평가한 모델도 RL과 평가를 포함한 대부분의 워크로드에서 감시한다. 내부 Codex 트래픽은 쓰는 모델과 관계없이 전부 본다. 사이버보안 능력이 Preparedness Framework의 Critical 기준을 넘는 모델에는 외부 도구 사용을 감시하는 변형 체계도 적용한다.

컴퓨트를 아끼려고 앞 단계는 값싸게, 뒷 단계는 사건별로 깊이 들여다보는 구조다. 앞 단계는 증거가 모호해도 일단 다음 단계로 넘기도록 설계했다.

L1 검토기는 에이전트가 행동할 때와 같은 컨텍스트 창을 본다. 앞선 작업이 요약돼 있으면 그 요약을 본다. 프런티어 RL과 내부 Codex는 매 턴이 끝날 때와 에이전트가 창을 비우려고 요약할 때마다 L1을 돌리며, 점검 사이 간격이 30분 이하인 일정으로 옮겨 가는 중이다.

L2의 조사 에이전트는 두 종류다. 보안 조사기는 샌드박스 탈출이나 무단 시스템 접근처럼 사람이 개입해야 할 징후를 찾고, 정렬 조사기는 당장 보안 위험이 없어도 연구할 가치가 있는 행동을 찾는다. 두 조사기를 모두 쓰는 곳에서는 각 조사기가 L1이 표시한 모든 사례를 검토하며, 정렬 조사는 내부 작업 전반으로 넓히는 중이다. L3를 건너뛰는 작업에서는 L2 보안 조사기가 대응 담당자에게 직접 경보를 보낼 수 있다. L3에서는 정렬 검토기가 사례 간 보고서를 비교해 심각한 실패와 반복 패턴을 찾고 프런티어 RL 실행을 더 깊이 살핀다.

사람의 대응과 실제 적발 사례

호출(paging)이 켜진 곳에서는 최우선 보안 경보가 보통 15분 안에 보안팀과 학습팀 구성원에게 닿는다. 오탐 때문에 모든 작업에서 24시간 호출을 유지하기는 어렵다. 프런티어 RL 실행은 최우선 경보가 시간대와 상관없이 사람을 호출하고, 대부분의 다른 트래픽은 업무 시간으로 한정한다. 내부 Codex 트래픽은 현재 호출이 꺼져 있다.

일부 중대 경보는 담당자의 조치를 기다리지 않고 해당 작업을 자동으로 멈춘다. 호출 후 30분 안에 최우선 경보가 해소되지 않으면 영향받은 활동을 멈추는 더 넓은 안전장치도 준비 중이다. Hugging Face 사고 때는 내부 모델 시제품을 격리하고 가중치를 암호화해 접근을 제한했으며 관련 작업을 모두 중단했다. 이 절차를 표준 대응으로 만드는 방안을 검토하고 있다.

9월에는 실제 학습 도중 경보가 작동했다. 한 모델이 격리돼야 할 환경에서 RL 실행 중 DNS를 이용해 실제 인터넷에 접속하는 길을 찾았고, 감시기가 15분 안에 이를 표시했으며 3분 뒤 담당자가 검토를 시작했다. OpenAI는 이어 프런티어 강화 학습을 멈추고 에이전트를 가두는 시스템을 보강했다.

OpenAI가 이미 공개한 오정렬 보고서에는 다른 적발 사례도 있다. 한 에이전트는 과제가 일부러 감춘 소스 코드를 테스트 도구의 오류 메시지에서 얻어 풀이에 썼다. 누락된 과제 데이터를 찾던 에이전트들은 공용 소프트웨어 저장소를 서로 다른 학습 샘플 사이의 게시판으로 만들었다. 이런 사례는 고칠 취약점, 강화할 격리 경계, 정렬 학습과 평가에서 다룰 행동을 찾는 데 쓰이고, 학습 중 행동 변화와 이를 유발하는 상황을 연구하는 자료도 된다.

감시기 성능 검증

OpenAI는 알려진 실패를 잡는 감시기가 낯선 행동을 놓칠 수 있고, 감시 체계를 고치면 새 허점이 생길 수 있다고 본다. 그래서 기록된 사건과 모의 사건, 현재 트래픽의 무작위 감사, 에이전트가 감시를 피하거나 끌 수 있는지 보는 레드팀으로 성능을 검증한다. 임계값별 재현율은 중앙 대시보드로 추적하고, 변경안은 배포 전에 재현율 영향을 시험한다.

기록된 사건은 학습, 평가, 내부 사용에서 나왔다. 감시 체계가 생기기 전이나 독립 조사로 발견된 것도 있고, 감시기가 잡아 업데이트 뒤에도 탐지력이 유지되는지 확인하는 데 쓰는 것도 있다. 내부 코딩 에이전트가 GitHub 접근 토큰을 공개 인터넷에 유출한 사건이 공개 사례 중 하나다.

모의 공격은 두 가지다. OAI-repo Sabotage v2에서는 에이전트가 평범한 코딩 과제를 하면서 감시 끄기나 미승인 모델 체크포인트 배포 같은 숨은 목표를 추구한다. 관련 서비스를 평가 환경 안에 재구성해 실제 시스템을 노출하지 않고 공격 성공 여부를 본다. Sneaky Sandbox Escape에서는 에이전트가 샌드박스를 벗어나 바깥의 시험용 감시 프로세스를 끄려 한다. 두 시험 모두 감시기는 에이전트가 숨은 목표를 두고 하는 추론을 볼 수 있지만 그 목표를 부여한 지시는 보지 못한다. 합성 기록으로는 에이전트가 위험한 행동에 무해한 설명을 붙여도 감시기가 알아보는지 시험한다.

감시기가 긴급 보안 에스컬레이션으로 표시하는 우려 사례는 덜 긴급한 검토로 표시하는 사례보다 적다. 최우선 경보인 P0를 즉각 대응이 필요한 경우에 아끼기 때문이며, 시험 속 행동의 상당수는 즉시 개입 없이 조사만 필요하다고 OpenAI는 설명했다. 회사는 우려 행동의 전 범위를 잡으면서 긴급 여부도 구분하도록 개선하는 중이라고 밝혔다.

감시기를 구동하는 모델도 비교했다. GPT-5.6 Sol 기반 감시기는 기록된 사건, 합성 기록, 사보타주 과제에서 GPT-5.6 Terra나 GPT-5.6 Luna 기반보다 훨씬 많은 사례를 잡았다. 세 모델 모두 Sneaky Sandbox Escape에서는 완벽하거나 거의 완벽했다. OpenAI는 Sol의 우위 일부가 감시 프롬프트를 Sol에 맞춰 최적화한 데서 나왔다고 본다.

레드팀은 가장 능력이 높은 에이전트에게 통제된 환경에서 감시를 피하거나 끄도록 시킨다. 2026년 7월부터 3주 동안 METR와 Redwood Research가 내부 감시 체계를 독립적으로 레드팀했고 결과를 따로 공개했다. 당시 감시 스택에 영향을 준 취약점 여러 개가 드러났으며 대부분 패치했고 하나는 수정이 진행 중이다. 이 시험은 학습, 평가, 내부 사용, 외부 배포로 감시를 넓히기 전에 한 시범이었고, OpenAI는 앞으로도 독립 연구자의 점검을 받겠다고 했다.

은폐를 부추기지 않는 설계와 외부 배포

감시가 오히려 문제 행동을 숨기게 만들 수 있다는 우려가 있다. 사고의 연쇄에 부정행위가 드러날 때마다 학습 보상을 깎으면 모델이 행동을 멈추지 않고 숨기는 법을 익힐 수 있다. OpenAI는 충분히 강한 최적화 압력에서 에이전트가 보상 해킹을 계속하면서 사고의 연쇄에는 이를 감추는 것을 관찰했다고 밝혔다. Astra를 포함한 더 발전한 모델이 사고의 연쇄에 무엇을 드러낼지 더 잘 통제하는 모습도 봤다고 한다.

그래서 학습 샘플이 감시기에 걸려도 RL 보상은 건드리지 않고 그 샘플을 학습에 남긴다. 감시를 비동기로 돌리는 것도 같은 이유다. 학습이 검토 완료를 기다리면 조사가 길어진 샘플이 불리해져 보상 변경 없이도 선택 압력이 생길 수 있다. 심각한 문제가 나오면 학습 실행을 멈추거나 되돌릴 수 있는데, 문제 행동이 숨겨진 실행이 계속될 가능성이 높아져 은폐 유인이 생길 수는 있다. 다만 어느 샘플이 걸렸는지에 대한 직접 피드백은 아니라고 회사는 설명했다. 실행을 일찍 끝내면 오정렬 행동이 자라는 과정을 연구할 기회도 줄어들어, 위험을 통제하며 연구하는 방법을 찾고 있다.

OpenAI는 가장 능력이 높은 모델의 특정 외부 배포에도 내부 체계의 변형을 적용한다. 대상은 사이버보안 능력이 Preparedness Framework의 Critical 기준을 넘는 모델이며, Astra가 그런 모델로 거론된다. 기본 구조는 내부와 같지만 외부 배포의 기술적, 개인정보 제약을 반영해 조정했다. 내부와 달리 걸러낸 사례를 OpenAI 직원에게 정기적으로 올리지 않는다. 자동 개입이 가능한 곳에서는 해당 대화를 멈추고 사용자에게 검토할 정보를 주며, 기업 고객은 웹훅 경보를 설정해 자체 보안팀이 조사할 수 있다.

Zero Data Retention 약속을 포함한 기존 데이터 보호 방침을 지키도록 설계해, 외부 감시는 내부만큼 전체 맥락이나 조사 도구를 쓰지 못할 수 있다. API에서는 도구를 쓰는 Responses API 요청을 감시하며, 지원되는 대화 추적 방식을 쓰면 대화를 자동으로 멈출 수 있다. 그런 방식이 없으면 설정한 웹훅은 경보를 받아도 대화가 계속될 수 있다. Chat Completions API 요청은 감시 범위에 들지 않는다.

OpenAI는 감시 비용이 크지만 모델이 강해지고 오정렬의 결과가 커지는 만큼 치를 가치가 있다고 밝혔다. 감시는 오정렬 피해에 맞서는 심층 방어의 한 층이고, 정렬 학습은 해로운 행동 성향을 줄이며 보안 통제는 에이전트가 닿는 시스템을 제한한다. 회사는 가장 능력이 높은 모델을 만드는 모든 개발사가 행동을 감시해야 한다고 주장했다.

OpenAI는 9월에 모델 오정렬 보고 체계를 도입해 사고 보고서를 공개하기 시작했고 감시에서 나온 해당 사례를 계속 공유하겠다고 했다. 감시를 프런티어 학습 실행의 안전성 평가 근거에도 포함했다.