Codex가 프로젝트 컨텍스트를 잊어버리는 이유
현재 Codex의 컨텍스트 처리 방식
Codex는 파일을 읽고, 의존성을 추적하고, 컨텍스트 창에 코드베이스의 작동 모델을 구축하는 탐색 작업으로 세션을 시작합니다. 이 모델이 바로 세션 상태(session state)입니다. 대화가 길어질수록 공간을 확보하기 위해 오래된 콘텐츠는 압축(요약 및 삭제)됩니다. 이러한 이해는 어디에도 저장되지 않으며, 세션이 종료되거나 창이 가득 차면 증발해 버립니다. 그리고 다음 작업이 시작되면 탐색을 처음부터 다시 시작해야 합니다.
컨텍스트가 유지되지 않는 기술적 이유
압축은 설계상 손실이 발생할 수밖에 없으며, 사용자가 중요하게 생각하는 정보를 고려하지 않습니다. Codex 리포지토리의 한 GitHub 이슈에 따르면, 작업 중간에 압축으로 인해 AGENTS.md 규칙이 누락되어 에이전트가 따르던 요구사항을 잃어버리는 바람에 진행률이 97%에서 42%로 급락한 사례가 문서화되어 있습니다. 또 다른 이슈는 세션 중간에 모델을 전환할 때 컨텍스트가 손실되는 현상을 다룹니다. 게다가 기본 입력 창이 약 4분의 1로 줄어들면서, 이러한 압축 이벤트가 이전보다 작업 초기에 발생하게 되었습니다. AGENTS.md가 시작 시 읽히므로 도움이 되기는 하지만, 이는 수동으로 관리하는 정적 파일일 뿐이며 다른 콘텐츠와 마찬가지로 활성 창에서 압축되어 사라질 수 있습니다.
이로 인해 발생하는 비용
모든 세션은 아키텍처, 주요 파일, 의존성, 이미 내린 결정 사항 등을 다시 발견하는 과정으로 시작됩니다. 개발자들은 OpenAI 자체 포럼에서 대규모 코드베이스에서 Codex 세션 간에 프로젝트 컨텍스트를 보존하는 방법을 질문하며 정확히 이 문제를 토로하고 있습니다. 또한 작업 중간에 실패하는 모드도 있습니다. 80% 완료된 시점에서 요구사항을 잊어버린 에이전트는 사용자가 한 줄씩 검토해야 하는 결과물을 만들어내며, 컨텍스트 창이 작아질수록 이러한 일이 발생할 확률은 줄어들지 않고 오히려 늘어납니다.
Codex의 내장 해결책 (그리고 한계)
AGENTS.md
규칙, 명령어, 제약 조건 등 안정적인 지침을 보관하기에 가장 적합한 곳입니다. 하지만 두 가지 한계가 있습니다. 수동으로 관리되기 때문에 결정된 사항, 거부된 접근 방식, 해결된 버그와 같은 동적 지식은 반영되지 않습니다. 또한 압축으로부터 안전하지 않으며, 이는 앞서 언급한 97%에서 42%로의 진행률 퇴보 사례가 잘 보여줍니다.
압축 및 재읽기
압축은 긴 세션이 완전히 실패하지 않고 계속 유지되도록 도와주므로 실제로 유용합니다. 하지만 공간을 확보하기 위해 세부 정보를 희생합니다. 정확한 명령어, 특정 요구사항, 이전의 결정 사항 등이 요약되어 사라집니다. 그런 다음 에이전트는 손실된 정보를 복구하기 위해 파일을 다시 읽으며, 이미 알고 있던 내용을 재구축하는 데 토큰을 낭비하게 됩니다.
새 세션 시작하기
성능이 저하된 세션을 해결하는 일반적인 방법은 세션을 재시작하는 것입니다. 이는 세션이 학습한 모든 내용을 버림으로써 창 공간을 복구합니다. 즉, 컨텍스트를 대가로 지불하고 명확성을 얻는 것입니다.
공통적인 한계: 이 중 어느 것도 세션 경계나 컨텍스트 창 변경 시에도 유지되는, 프로젝트 지식에 대한 영구적이고 쿼리 가능한 저장소가 아닙니다. 이는 Claude Code가 프로젝트 컨텍스트를 잊어버리는 이유의 이면에 있는 근본적인 공백과 동일합니다.
해결책: Codex에 영구적인 프로젝트 메모리 부여하기
영구적인 해결책은 압축 과정에서 계속 버려지는 아키텍처, 결정 사항, 제약 조건, 해결된 이슈 등을 세션 외부의 메모리 레이어에 보관하는 것입니다. MemoryLake는 이러한 정보를 한 번 저장하면 검색이 가능하고, Git 스타일로 버전이 관리되어 결정이 언제 변경되었는지 추적할 수 있으며, 종단간 암호화(end-to-end encrypted)를 통해 코드와 인프라 세부 정보를 안전하게 보호합니다. 지식이 컨텍스트 창 외부에 존재하므로, 컨텍스트 창이 작아지더라도 메모리가 줄어들지 않습니다.
1단계: API 키 생성하기
MemoryLake에 로그인하고 키를 생성한 후 첫 번째 요청을 보내세요. 약 30초 정도 소요됩니다.
2단계: 첫 번째 메모리 업로드하기
세션이 계속해서 다시 탐색해야 하는 프로젝트 지식(아키텍처 노트, 의사결정 기록, API 및 데이터 흐름 문서, 긴 작업에서 절대 놓쳐서는 안 될 요구사항 등)을 업로드하세요. 문서, 이미지 및 기타 파일 모두 지원됩니다. 세션에서 보관할 가치가 있는 내용이 결정되면 이를 한 줄짜리 메모리로 기록해 두세요.
3단계: AI 및 에이전트 연결하기
API 키를 사용하여 MCP를 통해 MemoryLake를 Codex에 추가하세요. 그러면 에이전트가 압축되는 창에 정보를 유지하는 대신, 필요할 때마다 요구사항과 과거의 결정 사항을 검색해 옵니다. 동일한 메모리를 MCP 또는 API를 통해 Claude, OpenClaw 및 기타 에이전트에서도 사용할 수 있으므로, 코딩에 사용하는 모든 도구에서 하나의 프로젝트 메모리를 공유할 수 있습니다.
재탐색과 압축이 실제로 초래하는 비용
줄어드는 컨텍스트 창의 대가
기본 창이 작아지면 단순히 더 일찍 잘리는 것에 그치지 않습니다. 에이전트가 압축으로 인해 누락된 내용을 복구하기 위해 더 자주 다시 읽어야 하므로, 모든 재읽기 과정에서 작업을 수행하는 대신 이미 알고 있는 컨텍스트를 재구축하는 데 토큰이 소모됩니다. 대규모 코드베이스에서 이러한 재탐색은 세션에서 가장 비용이 많이 드는 부분이며, 이제 그 시점이 더 빨라졌습니다.
재요약 대신 검색 활용하기
영구 레이어를 사용하면 Codex는 전체 프로젝트를 담을 수 없는 창에 억지로 유지하려 하는 대신, 작업에 필요한 특정 결정이나 요구사항을 가져옵니다. 압축 압박이 줄어들고, 작업 중간의 퇴보 현상이 감소하며, 비용이 절감됩니다. MemoryLake의 토큰 절약 계산기(Token Saving Calculator)를 통해 실제 사용량에 따른 효과를 예측해 볼 수 있습니다.
Codex 프로젝트 메모리 구축을 위한 모범 사례
압축이 닿지 않는 곳에 요구사항 보관하기
요구사항이 긴 작업 과정에서도 유지되어야 한다면, 프롬프트나 AGENTS.md에만 둘 것이 아니라 검색 가능한 메모리에 보관해야 합니다. 이것이 작업을 완수하는 에이전트와 80% 단계에서 퇴보하는 에이전트의 차이입니다.
결정이 내려지는 순간 기록하기
날짜가 기록된 한 줄(결정 사항, 이유, 거부된 대안)이 나중에 결코 실행되지 않을 사후 정리보다 훨씬 낫습니다. 또한 에이전트가 이미 배제한 방안을 다시 제안하는 것을 방지합니다.
리포지토리별로 범위 지정하기
리포지토리별로 하나의 메모리 범위를 지정하면 검색의 정확성이 유지되고, 각 프로젝트의 Codex 세션이 해당 프로젝트에 적용되는 정보만 가져올 수 있습니다.
결론
Codex가 갑자기 더 잘 잊어버리게 된 것은 우연이 아닙니다. 기본 창이 작아졌다는 것은 압축이 더 빨리 발생한다는 것을 의미하며, 압축은 언제나 요구사항과 결정 사항이 소리 없이 사라지는 원인이었습니다. AGENTS.md는 동적인 지식을 담을 수 없고, 세션을 재시작하는 것은 단지 명확성을 위해 컨텍스트를 희생하는 것뿐입니다. 프로젝트의 실제 메모리를 컨텍스트 창 외부에 두면, 창 크기가 에이전트의 지식 수준을 결정하지 않게 됩니다. 컨텍스트는 줄어들 수 있지만, 메모리까지 줄어들 필요는 없습니다.