MemoryLake
모든 글로 돌아가기
Tutorial2026년 8월 28일·11 분 소요

Codex의 로컬 메모리를 켜고 보관할 내용을 제어하는 방법 (2026)

Codex에는 로컬 메모리 저장소가 있습니다. 이 저장소는 Codex 홈 디렉터리 아래에 일반 텍스트 파일로 기록되며, 한 채팅의 컨텍스트를 다음 채팅으로 전달합니다. 또한 대부분의 사람들이 한 번도 열어보지 않은 일련의 설정 키와 함께 제공됩니다.

이 기능은 기본적으로 꺼져(off) 있으며, 이것이 바로 수많은 Codex 사용자들이 이 기능이 존재하지 않는다고 확신하는 이유입니다.

이 한 가지 사실은 많은 불만을 설명해 줍니다. 만약 Codex가 모든 세션을 제로에서 시작한다고 결론을 내렸다면, 가장 먼저 확인해야 할 것은 AGENTS.md가 아니라 메모리가 활성화되어 있는지 여부입니다. 그리고 메모리가 켜지면, 기능이 고장 난 것으로 오해하기 쉬운 네 가지 동작 특성이 나타납니다. 쓰기가 지연되고, 사용 제한에 가까워지면 쓰기가 완전히 건너뛰어질 수 있으며, 기록되는 내용은 직접 수정하지 말아야 할 생성된 상태(generated state)이고, ChatGPT 웹 앱의 메모리 저장소는 Codex 클라이언트의 저장소와는 다른 시스템이라는 점입니다.

이 글에서는 이 기능을 켜는 방법, 각 설정 키가 실제로 제어하는 대상, 그리고 문서에서 유난히 직접적으로 설명하는 부분인 이 저장소에 보관해야 할 내용과 자동으로 건너뛸 수 없는 다른 곳에 보관해야 할 내용의 차이를 다룹니다.

이와 관련된 두 개의 다른 글이 이 주제와 겹치지만 여기에 미치지는 못합니다. Why Codex forgets your project context는 증상과 파일 기반 해결책을 다루며 문서화된 로컬 저장소가 나오기 전의 글입니다. 이 글을 "Codex가 스스로 기억할 수 있는가?"에 대한 현재의 답변으로 생각하시면 됩니다. 그리고 how to stop Codex silently skipping your AGENTS.md rules는 작동 방식과 실패 모드가 다른 지침 파일(instruction files)에 관한 글입니다.

Codex가 여전히 예상한 대로 기억하지 못하는 이유

메모리는 두 곳 중 하나에서 직접 켜기 전까지는 꺼져 있습니다

문서에 명확히 나와 있습니다: "로컬 Codex 메모리는 기본적으로 꺼져 있습니다."

이를 활성화하는 방법은 두 가지가 있습니다. ChatGPT 데스크톱 앱에서 Settings > Personalization을 열고 Enable memories를 켭니다. 설정 파일 기반으로 구성하려면 config.toml에 기능 플래그를 추가합니다:

[features]
memories = true

데스크톱 앱, CLI, IDE 확장에 걸쳐 Codex를 사용하는 경우, IDE 확장은 "연결된 Codex 호스트의 로컬 메모리 저장소를 사용"하며 자체 저장소를 유지하지 않는다는 점에 유의하세요. 호스트에서 활성화하면 확장 프로그램도 이를 따릅니다.

사람들이 헷갈려하는 또 다른 차이점은 웹 버전 ChatGPT는 별개의 시스템이라는 점입니다. "ChatGPT 웹은 ChatGPT 메모리를 사용하는 반면, 로컬 Codex 클라이언트는 별도의 로컬 메모리 저장소 및 제어 기능을 사용합니다." 그리고 ChatGPT Work는 "로컬 Codex 메모리 저장소나 로컬 메모리 제어 기능을 전혀 사용하지 않습니다." 하나를 켠다고 해서 다른 하나가 켜지는 것은 아닙니다.

쓰기는 지연되며, 건너뛰어질 수 있습니다

메모리를 켜더라도 채팅이 끝나는 즉시 아무것도 나타나지 않습니다. "채팅이 끝났을 때 메모리가 바로 업데이트되지 않을 수 있습니다. Codex는 아직 진행 중인 작업을 요약하지 않도록 채팅이 충분히 유휴 상태가 될 때까지 기다립니다." 또한 Codex는 "활발하거나 수명이 짧은 세션은 건너뜁니다."

이는 합리적인 설계이지만 첫날에는 혼란을 줄 수 있습니다. 기능을 활성화하고, 세션을 마치고, 메모리를 찾아보았지만 아무것도 발견하지 못하는 상황이 발생하기 때문입니다.

더 중요한 문제는 조용히 발생합니다. "남은 Codex 속도 제한(rate-limit) 비율이 설정된 임계값 미만일 때 메모리 생성 백그라운드 패스를 건너뛸 수 있으므로, 제한에 가까워졌을 때 Codex가 할당량을 소모하지 않도록 합니다."

이 기능이 실행되는 시점을 생각해 보세요. 건너뛰어질 가능성이 가장 높은 세션은 고된 하루의 끝에 진행된 길고, 밀도 높고, 어려운 세션들입니다. 즉, 가장 기억할 가치가 있는 세션들입니다. 이 임계값은 memories.min_rate_limit_remaining_percent를 통해 설정할 수 있지만, 기본 동작은 가장 바쁜 작업이 기록될 가능성이 가장 낮다는 것입니다.

기록되는 내용은 생성된 상태이며, 편집하지 말라는 권고를 받습니다

저장소는 기본적으로 Codex 홈 디렉터리인 ~/.codex 아래에 위치하며, "주요 메모리 파일은 ~/.codex/memories/ 아래에 저장되며 이전 채팅의 요약, 영구 항목, 최근 입력 및 지원 증거를 포함합니다."

그리고 이 기능의 전체적인 역할을 정의하는 지침이 나옵니다: "이 파일들을 생성된 상태(generated state)로 취급하세요. 문제를 해결하거나 Codex 홈 디렉터리를 공유하기 전에 검사할 수는 있지만, 직접 손으로 편집하는 것을 기본 제어 수단으로 삼지 마세요."

따라서 검사는 가능하지만 직접 작성하는 것은 아닙니다. Codex가 왜 그렇게 믿고 있는지 알아보기 위해 읽을 수는 있지만, 프로젝트가 어떻게 작동하는지에 대한 공식적인 기록으로 유지 관리할 수는 없습니다. 이는 의도적인 경계이며, 문서에서 몇 줄 뒤에 다시 한 번 긋는 경계이기도 합니다.

외부 컨텍스트는 메모리 생성에서 완전히 제외될 수 있습니다

이것은 이 설정 세트에서 가장 흥미로운 키입니다. memories.disable_on_external_context는 "true로 설정하면 MCP 도구 호출, 웹 검색 또는 도구 검색과 같은 외부 컨텍스트를 사용한 채팅을 메모리 생성에서 제외합니다." 이전 키인 memories.no_memories_if_mcp_or_web_search도 여전히 별칭으로 허용됩니다.

공급업체가 외부의 영향을 받은 세션을 메모리 저장소에서 제외하는 스위치를 제공한다는 것은 이러한 시스템이 어떻게 실패하는지에 대한 중요한 신호입니다. 에이전트가 다른 곳에서 가져온 콘텐츠는 영구 메모리로 유입될 수 있는 그럴듯한 경로이며, OpenAI는 이를 차단할 수 있는 방법을 제공한 것입니다.

하지만 트레이드오프는 확실합니다. 이 기능을 켜면 연구가 많이 필요한 세션(가장 진정으로 새로운 정보가 많은 세션)이 기여하는 것을 멈춥니다. 이 기능을 끄면 에이전트가 읽은 모든 내용이 기억하는 내용에 영향을 미칠 수 있습니다.

나머지 키들에 대한 간단한 설명

알아둘 가치가 있는 네 가지 키가 더 있습니다. memories.generate_memories는 "새로 생성된 채팅을 메모리 생성 입력으로 저장할 수 있는지 여부를 제어합니다." memories.use_memories는 "Codex가 기존 메모리를 향후 세션에 주입할지 여부를 제어합니다." 이 두 방향은 분리되어 있으므로 쓰지 않고 읽거나, 읽지 않고 쓸 수 있습니다. 그리고 memories.extract_modelmemories.consolidation_model은 각각 채팅별 추출 및 글로벌 통합에 사용되는 모델을 재정의합니다.

채팅별로는 데스크톱 앱과 Codex TUI의 /memories가 해당 채팅이 기존 메모리를 사용할 수 있는지, 향후 메모리에 반영할 수 있는지를 제어합니다. "채팅 수준의 선택은 글로벌 메모리 설정을 변경하지 않습니다."

사람들이 시도하는 것들

Codex에 메모리가 없다고 결론 내리기. 이해할 만한 일이며, 저장소가 기본적으로 꺼져 있기 때문에 가장 흔히 저지르는 실수입니다. 먼저 Settings > Personalization을 확인하세요.

모든 것을 AGENTS.md에 작성하기. 이 방법은 작동하며, 문서에서도 특정 범주에 대해 적극 권장합니다. 하지만 늘어나는 지침 파일은 모든 요청에서 컨텍스트 경쟁을 유발하며, 추론을 위한 올바른 형태가 아닙니다.

~/.codex/memories/ 직접 편집하기. 명시적으로 권장되지 않습니다. 이 파일들은 생성된 파일이며, Codex의 통합 패스가 이를 유지 관리합니다. 사용자의 편집이 제어 수단이 아닙니다.

메모리를 활성화하고 이제 다 해결되었다고 가정하기. 지연된 쓰기와 속도 제한 건너뛰기 때문에 설계상 보장 범위가 불완전합니다. 특정 세션이 흔적을 남겼다고 보장할 수 없습니다.

disable_on_external_context를 켜고 잊어버리기. 안전한 기본값이지만 정보가 가장 밀집된 세션을 조용히 제외합니다.

모든 세션 시작 시 컨텍스트 붙여넣기. 확실하고 수동적인 방법이지만, 잊어버리는 날에는 작동하지 않습니다.

해결책: 반드시 유지해야 할 것과 기억하면 좋은 것을 분리하기

문서에서는 이 분리 기준을 제시하고 있으며, 공급업체가 이에 대해 발표한 가장 명확한 성명이므로 전문을 인용할 가치가 있습니다:

"필요한 팀 가이드는 AGENTS.md나 체크인된 문서에 보관하세요. 메모리는 항상 적용되어야 하는 규칙의 유일한 원천이 아니라, 도움이 되는 회상 레이어로 취급하세요."

따라서 세 가지 계층이 존재합니다. 매번 유지되어야 하는 규칙은 AGENTS.md나 체크인된 문서에 들어갑니다. 편의를 위한 회상(사용자 선호도, 출력 형태 등)은 로컬 저장소의 몫이며, 이를 자동으로 작동하게 하는 것이 핵심입니다. 그 사이에는 지침도 아니고 있으면 좋은 것도 아닌, 영구적인 모든 것이 위치합니다. 즉, 결정과 그 이유, 배제된 접근 방식, 명백한 답을 오답으로 만드는 제약 조건 등입니다. 이 계층은 속도 제한에 가까워졌을 때 패스를 건너뛰는 저장소에 둘 수 없으며, 모든 요청마다 로드되는 지침 파일에 두어서도 안 됩니다.

이것이 바로 MemoryLake가 보관하는 레이어입니다. 도구가 의도적으로 쿼리하는 영구적인 프로젝트 지식이므로 AGENTS.md는 짧게 유지되고 로컬 저장소는 편의 기능으로 남습니다. 설정은 세 단계로 진행됩니다.

1단계: API 키 생성

로그인하고 API 키를 생성합니다. 연결하는 도구 전반에 걸쳐 하나의 자격 증명을 사용합니다.

Codex의 로컬 메모리와 함께 MemoryLake API 키 생성하기
Codex의 로컬 메모리와 함께 MemoryLake API 키 생성하기

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

각각 하나의 주장만 담긴 짧은 항목들입니다. 유용한 테스트 기준은 이를 잃어버렸을 때 키 입력 한 번이 아니라 논쟁에서 손해를 보게 되는지 여부입니다:

생성된 상태 대신 MemoryLake에 항상 적용되어야 하는 규칙 작성하기
생성된 상태 대신 MemoryLake에 항상 적용되어야 하는 규칙 작성하기

결정과 그 이유. "연결 풀이 동시 연결 200개에서 포화 상태가 되므로 쓰기를 일괄 처리합니다." 규칙은 AGENTS.md에 들어갈 수 있지만, 다음 분기에 이 규칙이 번복되지 않도록 막아주는 것은 그 이유입니다.

이미 배제된 접근 방식. 지침 파일이나 커밋 메시지에는 나타나지 않지만, 새로운 세션마다 계속해서 다시 제안되는 범주입니다.

아무도 알려주지 않는 환경적 사실. 문서화되지 않은 속도 제한, 순서 의존성, CI에서만 실패하는 테스트 등입니다.

건너뛴 패스로 인해 잃고 싶지 않은 모든 것. 그것이 중요하고 로컬 저장소의 보장 범위가 최선 노력(best-effort) 수준이라면, 최선 노력에 의존하지 마세요.

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

사용하는 도구를 연결합니다. MemoryLake는 MCP 및 API를 통해 액세스할 수 있으며, Codex는 MCP 서버를 지원합니다. memories.disable_on_external_contexttrue로 설정해 두면 MCP 도구를 사용하는 세션이 Codex 자체 로컬 메모리에 기여하는 것을 멈춘다는 점에 유의하세요. 이는 어떤 저장소에 무엇을 보관할지 신중하게 결정해야 하는 이유이지, 둘 중 하나를 피해야 할 이유는 아닙니다.

MCP 및 API를 통해 Codex 및 기타 에이전트를 MemoryLake에 연결하기
MCP 및 API를 통해 Codex 및 기타 에이전트를 MemoryLake에 연결하기

세 가지 솔직한 한계가 있습니다. MemoryLake는 ~/.codex/memories/를 읽거나 쓰거나 삭제하지 않습니다. 이는 OpenAI가 유지 관리하는 생성된 상태이며, 어떤 외부 도구도 이를 편집해서는 안 됩니다. MemoryLake는 AGENTS.md를 작성하지 않으며, 이는 여전히 사용자가 Codex를 조종하는 수단으로 남습니다. 그리고 사용자나 에이전트가 직접 넣지 않는 한 메모리에 아무것도 저장되지 않으므로, 2단계는 의도적으로 수행되어야 합니다.

실제 적용 시 변화되는 점

"Does Codex remember?"에 대한 진짜 답변을 얻게 됩니다. 예, 활성화되면 기억하며, 파일이 어디에 있는지 알게 됩니다.

건너뛴 백그라운드 패스로 인해 중요한 것을 잃지 않게 됩니다. 영구 계층은 패스를 건너뛰는 저장소에 있지 않습니다.

AGENTS.md가 더 이상 늘어나지 않습니다. 지침은 지침으로 남고, 추론은 외부로 이동합니다.

편집 없이 검사할 수 있습니다. ~/.codex/memories/를 읽어 믿음의 근거를 이해하고, 영구 계층을 변경하여 이를 수정합니다.

연구가 많이 필요한 세션을 안전하게 실행할 수 있습니다. 중요한 결론을 의도적으로 기록해 두면 Codex 자체 저장소에서 외부 컨텍스트를 제외하더라도 손실이 줄어듭니다.

Codex 로컬 메모리를 위한 모범 사례

명시적으로 켜고, 실제로 사용하는 인터페이스를 확인하세요. 기본적으로 꺼져 있으며, IDE 확장은 호스트를 따르고, ChatGPT 웹은 별개의 시스템입니다.

disable_on_external_context를 신중하게 결정하세요. 이는 메모리로 유입되는 실제 경로를 차단하는 동시에 정보가 가장 밀집된 세션을 제외합니다. 알고 선택하세요.

메모리에 비밀 정보를 넣지 마세요. 문서에서 직접적으로 경고합니다: "메모리에 비밀 정보를 저장하지 마세요." Codex는 생성된 필드에서 비밀 정보를 편집(redact)하지만, Codex 홈 디렉터리를 공유하기 전에 파일을 검토하세요.

기능이 잘못되었다고 결론 내리기 전에 파일을 읽어보세요. 검사는 지원되지만, 직접 손으로 편집하는 것은 제어 수단으로 지원되지 않습니다.

필요한 가이드는 AGENTS.md에 보관하세요. 공급업체 자체의 조언이며, 로컬 저장소는 이를 대체할 수 없습니다.

읽기와 쓰기를 분리하세요. use_memoriesgenerate_memories는 독립적인 키이므로, 공유 작업이나 민감한 작업에서 유용합니다.

누적된 내용을 주기적으로 감사하세요. 일반적인 방법은 how to audit what your AI remembers에 설명되어 있습니다.

영구 계층을 작게 유지하세요. 항목이 많다고 좋은 것은 아닙니다. 이에 대한 논거는 why agent memory should keep less에 있습니다.

결론

Codex는 대부분의 사용자가 생각하는 것보다 더 많이 기억하고, "메모리"라는 단어가 암시하는 것보다는 적게 기억합니다. ~/.codex/memories/에는 요약, 영구 항목, 최근 입력 및 지원 증거를 보관하는 문서화된 로컬 저장소가 있습니다. 이 저장소는 기본적으로 꺼져 있으며, Settings > Personalization 또는 config.toml 기능 플래그에서 활성화할 수 있고, /memories를 통한 채팅별 제어와 그 뒤에 있는 반 더즌(6개) 정도의 설정 키를 제공합니다.

이 저장소의 보장 범위는 의도적으로 최선 노력(best-effort) 수준입니다. 쓰기는 채팅이 유휴 상태가 될 때까지 대기하고, 짧은 세션은 건너뛰며, 남은 속도 제한이 설정된 임계값 미만일 때는 백그라운드 패스를 완전히 건너뛸 수 있습니다. 이 파일들은 검사하되 직접 편집하지 말아야 할 생성된 상태입니다. 그리고 disable_on_external_context는 MCP나 웹 검색을 접한 모든 세션을 메모리 생성에서 완전히 제외하므로, 이는 진정으로 훌륭한 제어 수단이자 진정으로 큰 제외 범위입니다.

이 중 어느 것도 결함이 아니며, 단지 범위(scope)일 뿐입니다. 문서 자체에서 이 범위를 명시하고 있습니다: 필요한 팀 가이드는 AGENTS.md나 체크인된 문서에 보관하고, 메모리는 항상 적용되어야 하는 규칙의 유일한 원천이 아니라 도움이 되는 회상 레이어로 취급하라는 것입니다. 저장소를 켜고 편의 기능을 처리하게 하되, 바쁠 때 패스를 건너뛰지 않는 무언가에 논쟁의 여지가 있는 결정들을 보관하세요. 컨텍스트만으로는 이 문제를 해결할 수 없는 더 넓은 이유는 why long context isn't memory에서 다룹니다.

자주 묻는 질문

Codex에 메모리 기능이 있나요?

예, 하지만 기본적으로 꺼져 있습니다. Codex 클라이언트는 ~/.codex/memories/ 아래에 "이전 채팅의 요약, 영구 항목, 최근 입력 및 지원 증거"를 포함하는 파일이 있는 로컬 메모리 저장소를 사용합니다. ChatGPT 데스크톱 앱의 Settings > Personalization > Enable memories에서 활성화하거나, config.toml 파일의 [features] 아래에 memories = true를 추가하여 활성화할 수 있습니다.

Codex가 왜 지난 세션의 메모리를 저장하지 않았나요?

문서화된 세 가지 이유가 있습니다. 첫째, 쓰기가 지연됩니다. "Codex는 아직 진행 중인 작업을 요약하지 않도록 채팅이 충분히 유휴 상태가 될 때까지 기다립니다." 둘째, 짧거나 여전히 활성화되어 있는 세션은 건너뜁니다. 셋째, memories.min_rate_limit_remaining_percent로 제어되는 "남은 Codex 속도 제한 비율이 설정된 임계값 미만"일 때 백그라운드 패스를 건너뛸 수 있습니다.

Codex의 메모리 파일은 어디에 있으며, 편집할 수 있나요?

기본적으로 Codex 홈 디렉터리인 ~/.codex 아래의 ~/.codex/memories/에 있습니다. 이 파일들을 읽을 수는 있습니다. 문서에서는 "문제를 해결하거나 Codex 홈 디렉터리를 공유하기 전에" 검사할 것을 권장합니다. 하지만 "직접 손으로 편집하는 것을 기본 제어 수단으로 삼지 마세요"라고 덧붙입니다. 이 파일들은 Codex 자체의 통합 패스에 의해 유지 관리되는 생성된 상태이기 때문입니다.

Is ChatGPT's memory the same as Codex's memory?

아닙니다. "ChatGPT 웹은 ChatGPT 메모리를 사용하는 반면, 로컬 Codex 클라이언트는 별도의 로컬 메모리 저장소 및 제어 기능을 사용합니다." 또한 ChatGPT Work는 "로컬 Codex 메모리 저장소나 로컬 메모리 제어 기능을 전혀 사용하지 않습니다." 반대로 IDE 확장은 예외적으로 자체 저장소 대신 연결된 Codex 호스트의 저장소를 사용합니다. 기존 ChatGPT 메모리를 이전하는 방법은 how to migrate your ChatGPT memory to Codex에서 다룹니다.

What does memories.disable_on_external_context do?

true로 설정하면 "MCP 도구 호출, 웹 검색 또는 도구 검색과 같은 외부 컨텍스트를 사용한 채팅을 메모리 생성에서 제외"합니다. 이전의 memories.no_memories_if_mcp_or_web_search 키도 여전히 별칭으로 허용됩니다. 이는 에이전트가 다른 곳에서 가져온 콘텐츠가 영구 메모리에 저장될 수 있는 경로를 차단하지만, 연구가 많이 필요한 세션이 메모리에 기여하지 못하게 제외하는 비용이 따릅니다.

메모리가 켜져 있어도 AGENTS.md를 작성해야 하나요?

예, 문서에서도 직접 그렇게 명시하고 있습니다: "필요한 팀 가이드는 AGENTS.md나 체크인된 문서에 보관하세요. 메모리는 항상 적용되어야 하는 규칙의 유일한 원천이 아니라, 도움이 되는 회상 레이어로 취급하세요." 지침 파일과 메모리는 서로 다른 문제를 해결하며, 지침 파일에는 고유한 실패 모드가 있습니다. 이에 대한 내용은 why agents ignore the instruction files you wrote에서 다룹니다.