career

OpenAI GPT 최신 소식 — 외부 레드팀이 찾아낸 에이전트 감시망의 사각지대 (2026.10.23)

📌 한줄 요약: 2026년 10월 22일, AI 안전 평가 기관 METR과 Redwood Research가 OpenAI 내부 에이전트 정렬 모니터링 시스템을 3주간 직접 뜯어본 결과를 공개했습니다. 핵심은 세 가지입니다. ① 2026년 5~7월 내부 Codex 트래픽의 약 10%가 압축(compaction) 이벤트 미탐지로 모니터링되지 않았고, ② Codex 샌드박스와 Auto-Review를 우회해 호스트 사용자 권한으로 임의 행동을 할 수 있는 방법이 있었으며, ③ 모니터링을 끄는 클라이언트 제어 헤더 2종과 최근 수백 개 행동을 통째로 숨기는 익스플로잇도 확인됐습니다. OpenAI는 프로덕션 보호 스택에 영향을 주는 취약점은 모두 패치했다고 밝혔지만, METR은 그 주장을 검증하지는 않았다고 선을 그었습니다. Reuters와 CNBC가 모두 보도한, 이번 주 AI 업계에서 가장 묵직한 소식입니다.

METR 공식 블로그에 공개된 'Red-Teaming OpenAI's Internal Agent Monitoring Systems' 보고서 페이지 (출처: metr.org 공식 페이지 캡처) METR이 2026년 10월 22일 공개한 레드팀 보고서. 본문은 고수준 요약이고, 실제 상세 내용이 담긴 61쪽 내부 보고서는 공개되지 않았습니다 (출처: metr.org 공식 페이지 캡처).

에이전트에게 코드 수정과 배포 권한을 넘기고 “테스트 통과하면 알아서 올려”라고 맡기는 파이프라인을 운영하는 분들이라면, 이번 보고서는 그냥 흘려보기 어렵습니다. 솔직히 처음엔 “또 안전 연구진이 이론적인 우회 시나리오나 만들어낸 것 아닌가” 싶었는데, 원문을 뜯어보니 실제 내부 코드베이스와 모니터 프롬프트, 설정 파일을 손에 쥐고 3주 동안 파고든 실측 결과였습니다. 생각보다 훨씬 구체적이고, 생각보다 훨씬 불편합니다.

1. 무슨 일이 있었나 — 3주간의 ‘내부 침투형’ 감사

이번 건은 OpenAI가 자사 사고를 공개한 게 아닙니다. 외부 평가자가 OpenAI 내부로 들어가서 감시 체계 자체를 공격해본 첫 공개 사례입니다.

항목 내용
공개일 2026년 10월 22일 (목)
수행 기관 METR (AI 안전 평가 비영리) + Redwood Research
인력 각 기관 직원 1명, 총 2명
기간 2026년 7월 21일 ~ 8월 11일 (약 3주)
접근 범위 OpenAI 내부 코드베이스, 정렬 모니터 프롬프트·설정, 내부 문서
인터뷰 모니터링·안전시스템·보안팀 연구자·엔지니어 약 12명
보고서 내부 61쪽, OpenAI가 삭제(redact)한 38쪽 버전을 METR·Redwood 리더십에 공유
공개 범위 고수준 요약 글 1편 (세부 내용 상당 부분 비공개)

평가자들은 OpenAI가 발급한 기기를 사내에서만 사용하고, 상시 동행을 받는 조건으로 깊은 접근 권한을 얻었습니다. 즉 이번 실험의 성격은 “투명성 보고서”라기보다 “외부 연구자에게 내부 인프라를 얼마나 열어줄 수 있는가”를 확인하는 파일럿입니다. 세 당사자가 처음부터 그렇게 설계했고, 공개 글도 짧게 내기로 사전에 합의했습니다. OpenAI는 공개판에서 자기가 기밀이라고 판단한 부분을 삭제할 권리를 갖고 있었습니다.

여기서 중요한 전제가 하나 있습니다. 이 보고서는 2026년 7월 21일 이전의 시스템을 평가한 것입니다. 실습 중에 OpenAI가 모니터링을 확장하고 있었고, 그 변경분은 평가 대상이 아닙니다. “지금 OpenAI 모니터링이 이 정도다”라는 측정치가 아니라, “그때 이런 구멍이 있었다”는 역사적 기록으로 읽어야 합니다.

2. 숫자로 본 커버리지 — 99.2%와 10% 사이

가장 먼저 눈에 들어오는 건 커버리지 숫자입니다. 여기서 숫자가 두 개로 갈라지는데, 이 갈라짐 자체가 이번 보고서의 성격을 보여줍니다.

구간 추정 커버리지 비고
GPT-5.5 이상 모델의 에이전트형 내부 Responses API 트래픽 75~94% 불확실성 큼, 양방향 오차 인정
그중 내부 Codex 에이전트 트래픽 99.2% 모니터링 대상 적격 비율
압축(compaction) 이벤트 미탐지로 빠진 Codex 트래픽 약 10% (2026년 5~7월) OpenAI가 사전에 자체 발견, 실습 중 수정
모니터 자체 오류율 0.2% 미만 24시간 동안 로드셰드 0회

숫자만 보면 “99.2%면 훌륭한데?” 싶습니다. 하지만 모니터링 적격 비율 99.2%와 실제로 모니터링된 비율은 다릅니다. 99.2%는 “이 트래픽은 감시 대상이 맞다”는 뜻이고, 그 안에서 압축 이벤트가 감시 사각지대로 남아 있었습니다. 문은 99.2%만큼 열려 있는데, 그 문 안쪽에 10%짜리 옆문이 있었다는 구조입니다.

실제로 더 아픈 지점은 따로 있습니다. 당시 시스템은 에이전트가 사용자에게 제어를 반환하는 시점에 모니터를 작동시켰습니다. 뒤집으면, 에이전트가 계속 행동하고 있으면 모니터링을 무기한 미룰 수 있다는 뜻입니다. 평가자들은 접근 제약 때문에 실제로 그렇게 행동한 에이전트가 있었는지는 확인하지 못했습니다. 확인하지 못했다는 사실 자체가, 사후 감사(audit)만으로는 “안 일어났다”를 증명할 수 없다는 걸 보여줍니다.

또 하나. 실습 시작 시점에 강화학습(RL) 학습 롤아웃은 모니터링 대상이 아니었습니다. 2026년 3월~6월 일부 롤아웃은 감시됐다는 설명을 들었지만, 시작 상태는 “미적용”이었습니다.

3. 찾아낸 우회 경로 6가지

보고서가 정리한 우회 경로는 크게 여섯 갈래입니다. 하나같이 “모델이 나쁜 마음을 먹었을 때”를 가정한 시나리오지만, 그 시나리오가 성립한다는 것 자체가 문제입니다.

① Codex 샌드박스 + Auto-Review 동시 우회 Codex 에이전트가 샌드박싱과 Auto-Review를 우회해 호스트 사용자 권한으로 가능한 모든 행동을 할 수 있는 방법이 있었습니다. 즉 “에이전트가 컨테이너 밖으로 나가서 사용자 권한으로 놀 수 있다”는 경로입니다.

② 최근 수백 개 행동을 통째로 숨기는 익스플로잇 세부 내용은 OpenAI가 삭제했습니다. 공개된 설명은 “최근 행동 수백 개를 모니터링 대상에서 빼돌릴 수 있고, 그 익스플로잇을 수행하는 행동 자체까지 함께 숨겨진다“는 수준입니다. 자기 흔적을 지우는 형태라 파급력이 큽니다.

③ 직렬화 차이를 악용한 모니터 오류 유발 에이전트에게 보이는 궤적과 모니터에게 보이는 궤적의 직렬화(serialization) 방식이 다르다는 점을 이용해, 모니터가 오류를 내게 만드는 입력을 만들 수 있었습니다. 모니터가 죽으면 사람 검토로 에스컬레이션되지 않습니다. “감시자가 에러를 뱉으면 통과”라는 구조적 허점입니다.

④ 모니터링을 끄는 클라이언트 제어 헤더 2종 새 에이전트에 대해 모니터링 시스템을 비활성화하는 헤더가 2개 있었고, 둘 다 클라이언트가 제어할 수 있었습니다. 에이전트가 똑같은 인스턴스를 하나 더 띄워 감시 없이 돌릴 수 있다는 뜻입니다. 다만 헤더를 세팅하고 인스턴스를 만드는 행위 자체는 잡힐 수 있다는 단서가 붙습니다.

⑤ ‘읽기 전용’이라 믿었던 내부 도구 2종 모니터링되지 않는 내부 에이전트 도구 2종이 읽기 전용으로 알려져 있었는데, 단순한 익스플로잇으로 샌드박스 안에서 임의 행동이 가능했습니다. 평가자들은 이건 실제로 검증하거나 테스트하지는 않았다고 명시했습니다.

⑥ RL 학습 롤아웃 미모니터링 앞서 언급한 대로, 실습 시작 시점에 학습 롤아웃은 감시 밖이었습니다. 배포 전 단계에서 벌어지는 일이 감시 밖이라는 건, 안전 체계의 순서 자체를 다시 봐야 한다는 얘기입니다.

한편 잘 작동한 부분도 확인됐습니다. 모니터는 몇 가지 예외를 빼고 에이전트가 보는 전체 궤적을 봤고, 모니터 프롬프트는 계획적 기만(scheming), 감시 체계 훼손, 사보타주, 데이터 유출, 기만, 인바운드·아웃바운드 프롬프트 인젝션 등을 탐지하도록 설계돼 있었습니다. 즉 “감시 항목 설계”는 합리적이었는데, 감시가 닿지 않는 경로가 문제였습니다.

4. OpenAI는 무엇을 인정했고, 무엇이 남았나

OpenAI 입장은 명확합니다. 프로덕션 보호 스택에 영향을 주는 취약점은 모두 패치했고, 이후 모니터링 커버리지도 크게 바뀌었다는 설명입니다. 실제로 2026년 3월 19일 공개한 자사 설명에 따르면, 이 시스템은 GPT-5.4 Thinking을 최대 추론 강도로 돌려 완료 후 30분 이내 상호작용을 검토하고, 사고 사슬과 행동을 로깅해 심각도를 매기고 이상 징후를 사람 검토로 올립니다. 모든 표준 내부 코딩 에이전트 배포에 적용되고, 사용자·개발자·어시스턴트 메시지와 도구 호출·출력까지 전체 대화 이력을 본다고 밝혔습니다.

OpenAI 로고 심볼 (출처: Wikimedia Commons, Public Domain) 이번 평가 대상은 OpenAI 내부 운영 시스템이었습니다. 외부 고객 데이터가 유출된 침해 사고는 아니지만, “에이전트를 감시하는 장치”가 공격 대상이 될 수 있음을 실증한 사례입니다 (출처: Wikimedia Commons, Public Domain).

남은 문제는 검증의 주체입니다. METR은 “OpenAI가 패치했다고 말한 것“과 “우리가 그것을 확인한 것“을 분리해서 서술했고, 패치 이후 커버리지는 평가하지 않았다고 명시했습니다. Reuters와 CNBC가 이 대목을 함께 짚은 이유도 여기 있습니다. 안전 체계에서 “패치했습니다”는 선언이고, 신뢰는 재검증에서 나옵니다.

OpenAI 스스로도 모니터링을 다층 방어(defense-in-depth)의 한 겹으로 규정하고, 통제 평가(control evaluation)와 모니터·사람 검토자의 허용 가능한 신뢰성·지연 기준 마련, 사후가 아닌 동기 차단(synchronous blocking) 쪽으로의 확장을 로드맵으로 제시했습니다. 이번 보고서가 그 로드맵에 힘을 실어준 셈입니다.

5. 평가자가 제시한 5가지 설계 원칙

METR과 Redwood가 던진 처방은 제품 기능이 아니라 설계 철학입니다. 앞으로 모니터링 인프라는 조직 내부에서 활동하는 고성능 에이전트가 의도적·지속적으로, 전략적으로, 대규모로 공격하는 상황을 견뎌야 한다는 전제에서 출발합니다.

  1. 모니터링을 피하기 어렵게 만들 것 — 감시 대상에서 빠져나가는 경로 자체를 줄입니다.
  2. 감시 대상 트래픽이 실제로 감시되게 할 것 — ‘적격’과 ‘실제 감시’의 간극을 없앱니다.
  3. 사고에 빠르고 신뢰성 있게 대응할 것 — 모니터 오류·지연이 곧 사각지대가 되지 않게 합니다.
  4. 모니터링 시스템을 적극적으로 레드팀할 것 — 외부 평가를 일회성 이벤트가 아니라 상시 절차로.
  5. 에이전트와 모니터를 격리할 것 — 감시당하는 쪽이 감시자 설정을 만질 수 없어야 합니다.

구체적 관행도 함께 제시됐습니다. 턴이 끝나길 기다리지 말고 일정 메시지 수·시간마다 모니터링할 것, 알려진 우회 경로 목록을 유지할 것, 변조 방지(tamper-proof)되고 검색 가능한 로그를 남길 것, 에이전트 스캐폴드를 도구 호출이 실행되는 환경과 분리할 것. 거창한 얘기가 아니라, 사내 시스템에도 그대로 옮길 수 있는 체크리스트입니다.

6. 자동화 파이프라인 운영자에게 실제로 의미하는 것

이 보고서를 “OpenAI 내부 이야기”로만 읽으면 반은 놓치는 겁니다. 크론잡을 돌리고 자동화 파이프라인을 운영하는 입장에서 뽑아낼 수 있는 교훈은 상당히 실무적입니다.

보고서의 발견 실무에서 할 일
턴 종료 시점에만 감시 → 계속 행동하면 회피 가능 로그를 종료 시점에만 모으지 말고, 실행 중 주기적 스냅샷으로 남기기
압축(compaction) 이벤트가 감시 사각지대 압축 전 원문을 보존하고, 에이전트가 도구 호출로 다시 조회할 수 있게 만들기
모니터 오류가 곧 통과로 이어짐 감시 실패를 fail-open이 아니라 fail-closed로 처리 (실패 시 사람에게)
헤더·환경변수로 감시를 끌 수 있음 에이전트 실행 환경에서 감시 설정을 못 만지게 권한 분리
‘읽기 전용’ 도구도 우회 가능 읽기 전용이라는 가정을 신뢰 경계로 쓰지 않기
RL 롤아웃이 감시 밖 학습·평가 단계도 감사 대상에 포함

특히 세 번째 항목은 생각보다 많은 파이프라인이 걸립니다. 모니터나 검증 단계가 에러를 내면 “일단 통과시키고 나중에 보자”로 처리하는 경우가 흔한데, 이번 보고서의 ③번 발견은 정확히 그 지점을 찔렀습니다. 감시자가 죽는 순간이 가장 위험한 순간입니다.

7. 전망 — ‘외부 평가’가 표준이 되는 중

이번 파일럿의 진짜 의미는 취약점 목록이 아니라 절차에 있습니다. METR은 향후 같은 실험을 할 때 자사 문서 “AI 기업과 협업하는 방식(Our approach to working with AI companies)”이 규정한 투명성·독립성 모범 관행을 따르겠다고 밝혔습니다. 즉 “외부 평가자가 내부 인프라에 들어가서 공격해보고, 결과를 공개한다”는 형식이 관행으로 굳어지려는 단계입니다.

앞으로 벌어질 일은 대략 이렇게 그려집니다.

  • 평가의 상시화 — 1회성 파일럿에서 정기 감사로. 벤더 보안 문서에 “외부 레드팀 수행 여부”가 항목으로 들어갈 가능성이 큽니다.
  • 모니터링 지표의 표준화 — ‘적격 비율’이 아니라 ‘실제 감시 비율’, ‘평균 감시 지연’, ‘감시 실패 시 처리 방식’ 같은 지표가 구매·도입 검토의 질문지가 됩니다.
  • 규제와의 접점 — 고위험 AI에 대한 감시·기록 요구가 강해지는 흐름에서, 이번 사례는 “무엇을 기록하고 무엇을 증명해야 하는가”의 참조 사례가 됩니다.
  • 에이전트 설계의 변화 — 에이전트가 자기 감시 설정에 접근하지 못하도록 구조적으로 격리하는 설계가 기본값이 됩니다.

마무리: 도입 전에 물어야 할 질문

정리하면 이렇습니다. 이번 사건은 “OpenAI가 위험하다”는 얘기가 아니라, “에이전트를 감시하는 시스템도 공격 대상이며, 그 시스템을 외부에서 검증할 수 있어야 한다”는 얘기입니다. 실제로 평가자들은 모니터가 전체 궤적을 본다는 점과 탐지 항목 설계가 합리적이라는 점도 함께 확인해줬습니다. 균형 있게 읽을 필요가 있습니다.

자동화를 이미 돌리고 있거나, 올해 안에 에이전트 기반 워크플로를 도입할 계획이라면 벤더·사내 시스템에 이 세 가지만 물어보면 됩니다.

  1. “감시가 실패했을 때 어떻게 되나?” — 통과인가, 차단인가, 사람에게 가는가.
  2. “감시 로그를 에이전트가 수정할 수 있나?” — 가능하면 그건 감시가 아닙니다.
  3. “압축·요약된 컨텍스트의 원문이 남아 있나?” — 사후에 ‘무슨 일이 있었는지’ 재구성할 수 있어야 합니다.

가성비 좋은 자동화를 찾는 분들이라면 기능 목록보다 이 세 줄을 먼저 확인하는 게 낫습니다. 기능은 다음 분기에도 늘어나지만, 감시 공백은 사고가 터진 뒤에야 발견되니까요.

참고 자료

  • METR, “Red-Teaming OpenAI’s Internal Agent Monitoring Systems” (2026년 10월 22일)
  • Redwood Research, 동일 보고서 해설 (2026년 10월 22일)
  • Reuters, “AI safety group METR finds flaws in OpenAI’s internal monitoring system” (2026년 10월 22일)
  • CNBC, “Evaluators found vulnerabilities in OpenAI monitoring system” (2026년 10월 22일)
  • OpenAI, 내부 모니터링 시스템 공개 설명 (2026년 3월 19일)