Codex, 요약 대신 새 컨텍스트 창으로 전환

openai/codex 저장소 메인 브랜치에 이미 병합된 풀 리퀘스트 3건이 Codex의 컨텍스트 창 관리를 다시 짜는 방향을 보여줬다. 세션이 창 크기를 넘어서면 시스템은 더 이상 히스토리를 압축하는 요약을 생성하지 않는다. 대신 완전히 새로운 창을 열고 작업을 이어간다. 이 기능은 Feature::TokenBudget이라는 기능 플래그 뒤에 묶여 있으며 아직 정식으로 출시되지 않았다.

지금 방식은 요약 기반 압축이다. 창이 거의 가득 차면 시스템은 백엔드에 이전 대화를 하나의 요약으로 압축해 달라고 요청하고, 이를 원본 히스토리 대신 채워 넣는다. 이 방식에는 항상 두 가지 고정 비용이 따른다. 요약을 생성하는 것 자체가 토큰을 소모한다는 점, 그리고 압축이 손실을 동반한다는 점이다. API 규약, 파일 경로, 몇 턴 전에 정한 결정 사항이 압축 과정에서 뭉개질 수 있다. Codex로 장시간 작업을 돌려본 사람이라면 이런 실패 유형이 낯설지 않을 것이다. 모델은 두 시간 전에 합의한 규칙을 잊어버리고도 자신 있게 답을 내놓는다.

모델이 스스로 새 페이지를 요청하게 하다

첫 단계는 6월 11일 병합된 #27488로, 제목은 'Add new context window tool'이다. 모델에만 열려 있는 new_context 도구를 추가했으며, 작성자는 설명에서 이를 현재 창이 더 이상 쓸모없어졌을 때의 '이스케이프 해치(escape hatch)'라고 불렀다.

요청은 AutoCompactWindow에 기록되고 샘플링 후 소비된다. 같은 턴에서 바로 이어지는 다음 요청은 새 창에 들어간다. 새 창의 시작점은 요약이 없는 압축 체크포인트로, 초기 컨텍스트만 유지하고 이전 대화 히스토리는 넘어오지 않는다.

수동 정리도 같은 경로를 탄다

두 번째 단계는 6월 23일 병합된 #29743이다. 수동 압축과 자동 압축을 compact_token_budget이라는 하나의 라이프사이클로 통합했다. 토큰 버짓이 켜져 있으면 압축은 더 이상 백엔드에 요약을 요청하지 않고, 로컬에서 완전히 새로운 초기 컨텍스트를 곧바로 불러온다.

이 단계의 엔지니어링에는 절제가 숨어 있다. 외부에서 보이는 동작은 그대로 유지된다. compact 훅은 평소처럼 호출되고, ContextCompaction 라이프사이클 이벤트도 평소처럼 발생한다. 즉 이런 이벤트에 의존하는 클라이언트는 아무것도 바꿀 필요가 없고, 내부 구현만 바뀐 것이다.

되찾아오는 부분은 히스토리와 노트에 맡긴다

앞의 두 단계는 '버리는' 문제만 해결했다. '되찾아오는' 부분을 채운 것이 8월 21일 병합된 #39827이다. 이 PR 설명은 직설적이다. 토큰 버짓 세션에는 이전 대화 컨텍스트를 복구하고 창 전환 사이에 작업 상태를 유지할 방법이 필요하다고 적혀 있다.

여기에는 두 종류의 도구가 추가됐다. 히스토리 도구는 창과 항목 목록을 보여주고, 특정 항목을 읽고, 세션 내용을 검색한다. 노트 도구는 나열, 읽기, 검색, 추가, 영구 노트 작성을 담당한다. 호출은 Codex 백엔드를 거치며 OpenAI 프로바이더와 백엔드 인증이 필요하고, 이 역시 features.token_budget.use_history_notes_history라는 별도의 기능 플래그 뒤에 있다.

엔지니어링 차원에서 몇 가지 제한도 걸었다. 출력은 잘림을 인식하는 방식으로 처리되고, 요청 파라미터에는 한도가 있다. 자동 리뷰 의견은 평문 결과의 1만 토큰 상한, 노트 조작의 파라미터 바인딩 제한, 그리고 단계적 롤아웃을 권고하는 내용에 집중됐다.

결국 무엇이 바뀌는가

요약 압축과 새 창+검색은 결국 서로 다른 두 가지 기억 전략이다. 전자는 암묵적인 손실 압축으로, 모델은 자신이 무엇을 잃었는지 모르고 되찾을 방법도 없다. 후자는 명시적이고 상태를 갖지 않는 재시작으로, 모델은 예전 내용이 어딘가에 여전히 존재한다는 것을 알고 필요할 때 찾아간다.

비용은 자리만 옮긴 셈이다. 손실 압축의 실패는 조용히 일어난다. 창 전환의 실패는 '찾아봐야 할 때 찾아보지 않았다' 혹은 '찾아봤지만 정확한 걸 찾지 못했다'는 형태로 나타난다. 전자는 디버깅이 어렵고, 후자는 적어도 로그에는 남는다. 장시간 작업을 수행하는 에이전트에게는 눈에 보이는 실패가 조용한 실패보다 다루기 쉽다.

절약되는 비용은 또 다른 이점이다. 요약을 만들려면 모델 호출이 한 번 필요하고, 긴 세션에서는 이 지출이 계속 반복된다. 창 전환은 이 호출을 발생시키지 않고, 검색도 실제로 필요한 항목만 가져온다. 매일 한도를 꽉 채워 쓰는 헤비 유저에게는 실질적인 비용 절감이다.

짚고 넘어가야 할 것은 속도다. PR 병합이 곧 기능 출시를 뜻하지는 않는다. 세 가지 변경 모두 여전히 기능 플래그 뒤에 있고, 자동 리뷰도 여전히 단계적 롤아웃을 권고하고 있다. 6월의 첫 도구 버전부터 8월의 히스토리·노트 기능 완성까지, OpenAI는 이 방향에 두 달 넘게 공을 들였다. 플래그를 언제, 누구에게 열어줄지는 저장소 기록에 답이 없다.

참고 출처: openai/codex 저장소의 병합된 풀 리퀘스트 3건, CocoLoop, GitHub 자동 리뷰 의견. 도구 이름, 기능 플래그 이름, 병합 상태는 저장소 기록과 하나하나 대조했다.