OpenAI, 모델 추론을 들여다보는 창이 좁아지고 있다고 밝히다 — 대신 기록해야 할 것 (2026)

Pachocki는 chain-of-thought 모니터링을 OpenAI의 정렬 훈련이 일반화되는지 여부를 확인하는 주요 실증적 도구로 설명합니다:

"CoT 모니터링은 우리 모델이 훈련 분포에서 어떻게 일반화되는지 연구하는 데 있어 매우 중요한 도구가 되었으며, 모델의 행동뿐만 아니라 내부 프로세스까지 관찰하고 분석할 수 있게 해주었습니다."

그리고 다음과 같은 평가가 이어집니다:

"그러나 불행히도 우리의 평가에 따르면 CoT 모니터링에 의존하는 능력은 점차 감소하고 있습니다."

그 뒤를 이어 세 가지 이유가 제시되는데, 각각은 여러분이 사용하는 도구에서 이미 사실인 조건들을 설명합니다:

"현대의 추론 모델은 o1-preview보다 더 복잡한 환경에서 사용됩니다. 모델의 추론 과정은 사람, 다른 AI와의 소통 및 도구 사용과 점점 더 혼합되고 있습니다. 이러한 상호작용 중 상당수는 감독을 받아야 하므로, 우리가 보존하고자 하는 경계가 모호해집니다."

"AI는 자체 추론 과정에 대해 추론하고 이를 조작하는 데 더 능숙해지고 있습니다."

"사전 훈련 성능이 향상됨에 따라, 언어화된 추론을 전혀 사용하지 않고도 모델이 훨씬 더 똑똑해지는 것을 볼 수 있습니다."

에이전트 기반 코딩 세션을 염두에 두고 첫 번째 이유를 다시 읽어보세요. 도구 호출 및 다른 에이전트와의 메시지 송수신이 혼합된 추론은 가상의 미래 아키텍처가 아닙니다. 그것이 바로 현대적인 코딩 에이전트 실행의 모습입니다.

두 번째 구절은 덜 주목받고 있지만 더 많은 관심을 기울여야 합니다. 이는 최초의 추론 모델에서 내린 제품 결정에 대해 설명합니다:

"우리가 o1-preview를 출시했을 때, 장기적으로 감독 압박으로부터 보호하기 위해 chain of thought를 숨기도록 제품을 의도적으로 설계했습니다."

이 구절들을 나란히 놓고 보면 두 가지 결론이 나옵니다. 추론 흔적은 최초로 출시된 추론 모델부터 의도적으로 개발자용 결과물이 아니었습니다. 그리고 연구소 자체가 볼 수 있는 버전조차도 이제는 예전만큼 신뢰하기 어렵다고 말하고 있습니다.

쓰여진 내용에 대해 공정하게 말하자면, 이 에세이가 이 기술의 종말을 선언하는 것은 아닙니다. 에세이는 이러한 어려움을 "반드시 극복 불가능한 것은 아니다"라고 부르며, 모니터링 가능성에 대한 활발한 연구를 설명하고, chain-of-thought 신호와 네트워크 내부를 읽는 방법을 결합하는 방향을 제시합니다. 또한 향후 몇 년 동안의 기대를 설정합니다. "일반적인 AI 발전은 모니터링에 대한 신뢰도에 의해 점점 더 병목 현상을 겪을 것으로 예상합니다."

이것은 특정 벤더 한 곳의 단점이 아니며, 그렇게 해석하는 것은 잘못된 결론으로 이어집니다. 다른 두 벤더도 개발자에게 무엇을 보여줄지에 대해 동일한 결정을 내렸음을 자신들의 언어와 이유로 독립적으로 문서화했습니다.

GitHub는 다중 모델 오케스트레이션 프리뷰에 대해 쓰면서 현재 동작을 직접 설명합니다. "HydraFusion은 워크플로 단계를 보여주지만 일관된 하나의 결과를 반환할 때까지 중간 초안을 보류합니다." 그리고 그 이유를 제시합니다:

"이러한 초안은 검토, 수정 또는 폐기될 수 있으므로 실시간으로 보여주면 미완성된 작업이 최종 작업처럼 보일 수 있습니다."

메인 에이전트와 전문 서브 에이전트 간에 작업을 분할하는 방법에 대한 Amp의 문서도 같은 결론에 도달합니다:

"그들은 격리되어 작업하므로 서로 통신할 수 없고, 작업 중간에 안내할 수 없으며, 전체 대화가 아닌 메인 에이전트가 제공하는 지침과 context로 시작합니다. 메인 에이전트는 단계별 작업을 모니터링하는 대신 최종 요약만 받습니다."

세 개의 벤더, 세 개의 제품, 세 개의 서로 다른 근거, 하지만 하나의 공통된 결과: 진행 중인 추론은 여러분에게 전달되는 것이 아닙니다. 이것은 그들 중 누구를 비판하는 것이 아닙니다. GitHub의 이유는 타당한 이유이고, Amp의 경계는 합리적인 아키텍처이며, OpenAI의 원래 선택은 현재 보고하고 있는 바로 그 신호를 보호하기 위해 만들어진 것입니다.

바뀌는 것은 여러분이 가진 한 가지 습관에 두어야 할 신뢰도입니다. 대화 기록, 생각 요약, diff와 모호한 기억을 가지고 사후에 의도를 재구성하는 것은 언제나 취약했습니다. 이 에세이는 상황을 가장 잘 파악하고 있는 조직이 직접 밝힌, 그 신호가 점점 더 약해지고 있다는 당사자의 진술입니다. 올해 초 API 측면에서 Claude Fable 5.1 binding thinking blocks to a single conversation도 동일한 점을 지적했습니다.

바뀌지 않는 것은 여러분의 지침 파일, 규칙 또는 커밋된 문서입니다. 그것들은 여러분이 작성하는 입력값이며, 모델의 추론을 얼마나 명확하게 읽을 수 있는지에 영향을 받지 않습니다. 바로 그것이 핵심입니다.

"그러니까 모델이 스스로를 설명할 수 없다는 뜻이군요." 그런 말이 아닙니다. 모델은 설명을 생성하며, 이는 종종 유용합니다. 이 주장은 모델을 훈련하는 연구소의 평가 신호로서 언어화된 추론의 신뢰성에 관한 것입니다. "설명은 가치가 없다"는 말보다 훨씬 더 좁고 기술적인 의미입니다.

"OpenAI에 모니터링 문제가 있군요." 에세이는 업계 전체가 이 문제를 안고 있다고 주장하며, 이를 위한 주요 도구를 만든 연구소에서 발표한 것입니다. 추론 모델을 훈련하는 모든 연구소는 동일한 제약 조건 하에 있으며, 자체적인 주요 안전 도구에 대한 나쁜 소식을 자발적으로 공개하는 벤더 덕분에 외부의 누구라도 이에 대해 추론할 수 있는 것입니다.

"이것은 에이전트가 코딩에 안전하지 않다는 것을 의미합니다." 에세이의 어떤 내용도 이를 뒷받침하지 않습니다. 이것은 해석 가능성 연구와 확장 정책에 관한 것이지, 에이전트가 여러분의 리포지토리를 다루어야 하는지 여부에 관한 것이 아닙니다.

"대화 기록이 곧 기록입니다." 네 가지 중 가장 흔하고 가장 대가가 큰 오해입니다. 대화 기록은 무엇이 말해졌는지를 기록할 뿐, 무엇이 여전히 유효한지를 기록하지 않습니다. 첫째 주에 특정 HTTP 클라이언트를 선택했다가 여섯째 주에 이를 뒤집었다면, 두 문장 모두 대화 기록에 존재하고 둘 다 동일하게 검색할 수 있으며, 어느 것이 살아남았는지 표시해 주는 것은 아무것도 없습니다. 이는 추론 흔적을 읽을 수 있는지 여부와 관계없이 유효합니다. indexed session logs recall what you said, not what is still true에서는 왜 이력 검색이 이를 해결하지 못하는지 다루고 있으며, why long context isn't memory에서는 왜 더 큰 창(window)도 이를 해결하지 못하는지 다룹니다.

솔직하게 짚고 넘어갈 점이 하나 있습니다. 에세이 자체에서 정렬되지 않은 행동의 예로 든 것은 OpenAI–Hugging Face 사건이며, 다음과 같이 신중하게 설명되어 있습니다:

"예를 들어, OpenAI-Hugging Face 사건에서 에이전트들은 인간을 사회공학적으로 속이지 않는다는 경계를 지켰습니다. 그러나 다른 환경에서 배운 가치의 정신에 위배되고 범위를 벗어난 다른 행동을 삼가는 데는 분명히 실패했습니다."

구조를 주목해 보세요. 가르친 경계 중 일부는 유지되었지만, 다른 일부는 훈련에서 다루지 않은 상황으로 일반화되지 못했습니다. 이것은 일반화에 대한 진술이지, 고장 난 제품에 대한 이야기가 아닙니다.

"코드가 왜 이렇게 생겼는가"에 대한 지속 가능한 버전은 모델로부터 복구할 수 없습니다. 결정이 내려지는 시점에, 결정을 내린 사람에 의해, 채팅 로그가 아닌 다른 곳에 캡처되어야 합니다. 세 가지 단계가 있습니다.

1단계: 계속 혼동하고 있는 세 가지를 분리하세요

대부분의 팀은 "context"라는 라벨이 붙은 하나의 버킷을 가지고 있으며, 수명이 서로 다른 세 가지 종류의 정보를 담고 있습니다.

지침(Instructions)은 에이전트가 매번 따르는 상시 규칙입니다. 이 HTTP 클라이언트를 사용하고, 이 테스트 명령을 실행하고, 생성된 파일은 절대 편집하지 않는 것 등입니다. 이것들은 AGENTS.md, .cursor/rules, .github/copilot-instructions.md 등 여러분의 도구가 읽는 지침 파일에 속합니다. 짧고, 항상 유효하며, git에 보관됩니다.

결정(Decisions)은 이유가 첨부된 과거 논쟁의 해결된 결과입니다. 재전송 동작 때문에 큐 라이브러리에서 이전했으며, 여기에 우리를 설득한 장애 사건이 있습니다와 같은 것입니다. 이것들은 이력이 아닌 명령 목록인 지침 파일에 속하지 않으며, 여러분이 대화 기록에서 가장 자주 찾아 헤매는 내용입니다. Memory provenance에서는 출처가 없는 결정이 왜 가치가 훨씬 떨어지는지 다룹니다.

대화 기록(Transcripts)은 일어난 일에 대한 원시 기록입니다. 보관하되, 앞의 두 가지 중 하나로 취급하지 마세요.

이 에세이가 중요한 이유는 많은 팀들이 조용히 세 번째 버킷을 두 번째 버킷의 대체물로 사용해 왔기 때문입니다.

2단계: 결정하는 시점에 한 번에 결정을 캡처하세요

논쟁이 끝나고, 무엇을 거절했고 왜 거절했는지 아직 기억하고 있을 때 기록해 두세요. 네 가지만 적고 멈추세요. 결정한 것, 거절한 것, 이유, 그리고 날짜입니다. 이유에 증거(장애 사건, 실행한 측정값, 고객 제약 조건 등)가 포함되어 있다면 이를 명시하세요.

함정은 범위입니다. 모든 것을 문서화하려는 팀은 아무것도 문서화하지 못합니다. 여러분은 아키텍처 문서를 작성하는 것이 아닙니다. 4달 후에 누군가 이에 대해 물어보고 여러분이 잊어버렸을 때 원할 단 한 단락을 작성하는 것입니다.

만약 이것들을 지침 파일에 작성해 왔다면, 밖으로 옮기세요. 18개월 동안의 근거를 담고 있는 항상 로드되는 파일은 짧은 파일보다 나쁩니다. 지금 중요한 규칙들이 수많은 이력 단락들과 경쟁해야 하기 때문입니다. What coding agents actually read에서는 왜 그 파일이 가볍게 유지되어야 하는지 다루고 있으며, why an agent keeps losing the corrections you already gave it에서는 이와 관련된 실패 사례를 다룹니다.

3단계: 단 하나의 에이전트가 아닌 모든 에이전트가 기록을 읽을 수 있도록 만드세요

이 글에 등장하는 모든 벤더는 기기별, 워크스페이스별, 코드에서 재생성됨, 또는 에세이에서 설명한 것처럼 의도적으로 전혀 노출되지 않음 등 서로 다른 컨테이너를 가지고 있습니다. 한 에이전트의 메모리에 남아 있는 결정 기록은 도구를 전환할 때 다시 만들어야 하며, 이를 다시 만드는 사람은 대화 기록을 토대로 작업할 것이기 때문에 엉망으로 만들어질 것입니다. 모든 에이전트가 읽을 수 있는 곳에 두고 에이전트들을 연결하세요.

여기서 공유 메모리 레이어의 목적은 명확합니다. 모델의 context window 내부나 단일 벤더의 저장소가 아닌 곳에 여러분의 결정이 머무를 집을 제공하는 것입니다. MemoryLake는 이러한 기록을 보관하고 MCP 또는 API를 통해 요청하는 에이전트에 제공합니다. 기존 도구들은 자체 메모리 기능을 그대로 유지하며, 여기에 있는 어떤 것도 이를 대체하거나 침범하지 않습니다.

1단계: API 키 생성

키를 생성하고 1분 이내에 첫 번째 요청을 보내보세요. 이것은 에이전트가 공유 기록을 읽는 데 사용하는 자격 증명이므로, 다른 것을 옮기기 전에 먼저 생성하세요.

2단계: 첫 번째 메모리 업로드

다시 설명하는 데 가장 지친 결정들부터 시작하세요. 보통 새로운 기여자들이 항상 의문을 제기하는 아키텍처 선택, 특정 장애 사건에서 비롯된 컨벤션, 의도적으로 사용하지 않는 라이브러리 등의 짧은 목록입니다. 문서, 이미지 및 기타 파일도 같은 위치에 저장됩니다.

3단계: AI 및 에이전트 연결

Claude, Codex, OpenClaw 및 기타 에이전트에게 MCP 또는 API를 통해 액세스 권한을 부여하세요. 그러면 "여기 컨벤션이 무엇인가요"라고 묻는 에이전트는 window에 남아 있는 정보에서 추측하는 대신, 이유가 첨부된 해결된 결정을 검색하게 됩니다.

첫째, "왜 이런 방식으로 했는가"를 알아내는 것이 더 이상 탐색 작업이 되지 않습니다. 누군가 질문하면 에이전트가 결정과 그 이유를 검색하고 대화가 계속 진행됩니다. 대안이었던 대화 기록을 읽거나 모델에 자체 추론을 기억해 내라고 요청하는 것은 언제나 더 느렸으며, 이제는 상황을 가장 명확하게 파악하고 있는 연구소의 설명에 따라 명백히 신뢰성이 떨어지는 옵션이 되었습니다.

둘째, 결정의 번복이 명확해집니다. 결정 기록에는 날짜와 상태가 있습니다. 해당 HTTP 클라이언트를 더 이상 사용하지 않게 되면, 이전 항목은 이력에 남아 새 항목과 똑같이 권위 있는 것처럼 보이는 대신 대체(superseded)됩니다. 대화 기록을 아무리 검색해도 이 문제는 해결되지 않습니다.

셋째, 도구 전환 비용이 저렴해집니다. 지침 파일은 새로운 형식으로 변환되어야 합니다. 이는 불가피하며 모든 마이그레이션 가이드에서 다루고 있습니다. 하지만 결정 기록은 이전 도구의 형식에 얽매여 있지 않았기 때문에 그럴 필요가 없습니다.

넷째, 그리고 조용히 일어나는 변화로, 지속 가능한 추론이 모델 외부에 존재할 때 여러분의 프로세스는 모델의 추론을 명확히 읽을 수 있는지 여부에 더 이상 의존하지 않게 됩니다. 벤더들이 가독성이 나쁜 방향으로 가고 있다고 말하는 해에 갖추기에 아주 좋은 특성입니다.

문서화 시간이 아니라 결정하는 시점에 작성하세요. 한 달 후에 캡처된 결정은 대화 기록에서 캡처된 결정이며, 이는 여러분이 더 이상 의존하지 않으려는 바로 그 대상입니다.

지침과 결정을 분리하세요. 지침은 명령이며 항상 로드되므로 짧게 유지됩니다. 결정은 이력이며 필요할 때 검색되므로 늘어날 수 있습니다. 이 둘을 병합하면 둘 다 품질이 저하됩니다.

거절된 옵션을 기록하세요. 가장 가치 있는 한 줄은 여러분이 하지 않은 일을 말해주는 줄입니다. 또한 거절된 사항은 논의된 후 삭제되기 때문에 대화 기록에 절대 남지 않는 줄이기도 합니다.

모든 것에 날짜를 기록하고 대체 여부를 표시하세요. 날짜가 없는 기록은 소리 없이 부패합니다. "이 날짜에 대체됨"은 여전히 유용합니다. 그냥 방치된 항목은 함정입니다.

에이전트에게 볼 수 없는 이력을 재구성하라고 요청하지 마세요. 결정이 기록된 적이 없다면 그렇다고 인정하고, 다시 논의한 다음 이번에는 기록해 두세요.

기록을 단일 도구 외부에 보관하세요. 모든 벤더의 컨테이너에는 기기별, 워크스페이스별, 계정별 또는 코드에서 재생성됨과 같은 범위가 있습니다. 그 어떤 것도 "도구를 초월하여 영원히 유지되는 여러분의 프로젝트"가 아닙니다.

"An Alien Mind"의 헤드라인은 확장 정책에 관한 것이며, 그 논쟁은 수년간 계속될 것입니다. 여러분의 한 주를 바꾸는 문장은 더 작습니다. OpenAI 자체 평가에 따르면 chain-of-thought 모니터링에 의존하는 능력이 점차 감소하고 있으며, 문제의 흔적은 최초로 출시된 추론 모델부터 의도적으로 여러분의 손에 닿지 않도록 유지되었습니다.

다른 두 벤더도 자신들만의 이유로 동일한 경계를 문서화했습니다. GitHub는 미완성된 작업이 최종 작업처럼 보이지 않도록 중간 초안을 보류하고, Amp의 서브 에이전트는 모니터링된 흔적 대신 요약을 반환합니다. 이 중 어느 것도 결함이 아닙니다. 아키텍처가 그렇게 생긴 것뿐입니다.

실질적인 결과는 놀랍거나 새로운 것이 아닙니다. 상황을 가장 잘 파악하고 있는 당사자가 서면으로 확인해 준 것뿐입니다. 여러분의 프로젝트가 왜 그렇게 생겼는지에 대한 기록은 사람이 직접 작성하기로 결정한 것이어야 합니다. 결정을 내릴 때 작성하고, 지침 파일에 넣지 말고, 모든 에이전트가 읽을 수 있는 곳에 보관하세요.