컨텍스트 손실 없이 Codex에서 Warp로 마이그레이션하는 방법 (2026)

파일명과 내용은 완전히 그대로 이전됩니다. Codex는 "작업을 수행하기 전에 AGENTS.md 파일을 읽습니다." Warp의 Project Rules는 "AGENTS.md 파일(또는 하위 호환성을 위한 WARP.md)"에 위치합니다. 동일한 파일명, 동일한 마크다운이므로 변환이 필요 없습니다.

파일명의 세부 사항 하나를 놓치면 곤란해질 수 있습니다. Warp 문서에는 다음과 같은 명시적인 경고가 있습니다. "Warp가 인식하려면 파일명이 반드시 대문자여야 합니다(예: AGENTS.md, agents.md나 Agents.md가 아님)." Codex 역시 다른 방식으로 엄격합니다. 대체 목록이 정확해야 하며, "이 목록에 없는 파일명은 지침 탐색에서 무시됩니다." 만약 project_doc_fallback_filenames를 통해 소문자나 사용자 정의 이름을 등록해 두었다면, Warp는 이를 인식하지 못합니다.

중첩(Nesting)은 작동하지만, 누적(Stacking)이 재정의(Overriding)를 대체합니다. 이것이 실질적인 변화입니다.

Codex의 모델: "프로젝트 루트(일반적으로 Git 루트)에서 시작하여 Codex는 현재 작업 디렉터리까지 내려갑니다... 경로상의 각 디렉터리에서 AGENTS.override.md, AGENTS.md, 그리고 project_doc_fallback_filenames에 정의된 대체 이름을 차례로 확인합니다. Codex는 디렉터리당 최대 하나의 파일만 포함합니다." 그런 다음 병합합니다: "Codex는 루트에서부터 아래로 파일을 연결합니다... 현재 디렉터리에 더 가까운 파일이 결합된 프롬프트에서 더 나중에 나타나므로 이전 지침을 재정의합니다."

Warp의 모델: "Warp는 루트와 현재 디렉터리에 있는 AGENTS.md(또는 WARP.md)를 자동으로 적용합니다." 그리고 "다른 하위 디렉터리의 파일을 편집하는 경우, Warp는 해당 하위 디렉터리의 규칙 파일도 포함하기 위해 최선의 노력을 다합니다." 충돌은 명시된 우선순위에 따라 해결됩니다: "1. 현재 하위 디렉터리의 프로젝트 규칙 파일에 있는 규칙 2. 루트 디렉터리의 프로젝트 규칙 파일에 있는 규칙 3. Global Rules."

결과적으로 두 도구 모두 일반적인 것보다 구체적인 것을 선호합니다. 차이점은 없애고 싶었던 지침에 어떤 일이 일어나는가입니다. Codex에서는 디렉터리에 AGENTS.override.md가 있으면 형제 파일인 AGENTS.md를 전혀 읽지 않으므로 완전히 대체할 수 있습니다. Warp에서는 우선순위가 충돌을 결정하지만, 루트 파일은 여전히 적용됩니다. 루트 파일에 명시되어 있고 하위 디렉터리에서 언급하지 않은 규칙은 그대로 유지됩니다.

따라서 재정의(override)를 사용하여 예외를 두었던 Codex 설정의 경우, 하위 디렉터리 파일에서 해당 예외를 단순히 생략하는 것이 아니라 명시적인 모순(반대 지침)으로 다시 기술해야 합니다.

바이트 제한이 사라지며, 이는 정말 다행스러운 일입니다. Codex는 "빈 파일을 건너뛰고, 결합된 크기가 project_doc_max_bytes(기본값 32 KiB)로 정의된 제한에 도달하면 파일 추가를 중단합니다." 해결책은 "제한을 늘리거나 제한에 도달했을 때 중첩된 디렉터리에 지침을 나누는 것"이었습니다. Warp의 규칙 문서에는 이와 동등한 제한이 명시되어 있지 않습니다. 32 KiB 미만을 유지하기 위해 파일을 쪼개왔다면 이제 그 제약은 사라졌습니다. 다만 "할 수 있으니까"라는 이유만으로 다시 합치는 것은 권장하지 않습니다.

글로벌 스코프가 파일에서 UI로 변경됩니다. Codex는 글로벌 지침을 ~/.codex/AGENTS.md(또는 AGENTS.override.md, "Codex는 이 수준에서 비어 있지 않은 첫 번째 파일만 사용하므로")에 보관하며, CODEX_HOME으로 위치를 변경할 수 있습니다. Warp의 Global Rules는 "모든 프로젝트와 컨텍스트에 적용"되며 Warp Drive Rules 창에서 관리됩니다. 여기서 각 규칙은 이름과 "설명(규칙의 역할 및 적용 시기)"을 가질 수 있습니다.

이것은 다른 형태의 결과물입니다. 글로벌 파일은 하나의 문서가 아니라 개별적으로 설명된 규칙 세트가 되며, 어딘가에 복사본을 보관하지 않는 한 더 이상 버전 관리 시스템에 포함되지 않습니다.

검증 도구가 변경되며, 둘 다 훌륭합니다. Codex는 codex --ask-for-approval never "Summarize the current instructions." 명령과 중첩 동작을 위한 --cd subdir 변형, 그리고 codex -c log_dir=./.codex-log를 통한 일반 텍스트 TUI 로그로 전체 감사를 제공합니다. 또한 캐시와 싸울 필요가 없습니다. "Codex는 실행할 때마다(그리고 각 TUI 세션이 시작될 때마다) 지침 체인을 다시 빌드하므로 수동으로 지울 캐시가 없습니다."

Warp에서는 적용 중인 규칙이 대화에 나타납니다. "상호작용에 사용된 규칙은 대화의 References 아래에 표시되거나 특정 규칙에서 파생된 것으로 표시됩니다." 메커니즘은 다르지만 목적은 같으며, 그냥 잘 되겠거니 짐작하기보다는 첫 주에 적극적으로 확인해 볼 가치가 있습니다.

코드베이스 인덱싱이 새로 추가되었으며, 이는 로컬에서 수행됩니다. Codex는 필요할 때 파일을 읽습니다. Warp는 인덱스를 유지합니다. "Warp는 Git으로 추적되는 코드베이스를 인덱싱하여 에이전트가 코드를 이해하고 정확하며 컨텍스트를 인식하는 답변을 생성하도록 돕습니다. 코드는 Warp 서버에 저장되지 않습니다." 동기화됨(Synced), 파일 탐색 중(Discovering files), 실패함(Failed), 코드베이스가 너무 큼(Codebase too large) 등의 상태를 확인할 수 있으며, 제어를 위한 .warpindexingignore가 제공되고, 모든 요금제에서 "코드베이스당 최소 5,000개의 파일"을 지원합니다.

여기서 마이그레이션할 것은 없습니다. 이는 새로 얻게 되는 기능이며, 이제 동기화에 대해 신경 써야 합니다. "많은 파일이 변경되었거나 네트워크가 느린 경우, 에이전트가 컨텍스트에 액세스하려고 시도하기 전에 동기화가 완료되지 않을 수 있습니다."

Agent Memory는 큰 장점이지만, 세 가지 조건이 있습니다. Warp의 Agent Memory는 "Warp 에이전트, Claude Code, Codex를 포함하여 지원되는 하네스 전반에서 Warp 에이전트에게 영구 메모리를 제공합니다." 이는 개인, 에이전트, 팀 저장소, "새로운 지식이 기존 메모리와 병합되거나 충돌 시 대체되는" 자동 추출, 저장소별 지침이 포함된 읽기 전용 또는 읽기/쓰기 권한, "각 메모리가 어디서 왔는지 기록하는" 추적성, "메모리에 대한 모든 변경 사항이 기록되는" 감사 가능성을 갖춘 본격적인 시스템입니다.

이제 세 가지 조건입니다. 세 가지 모두 문서화되어 있으며 모두 중요합니다. 이 기능은 "리서치 프리뷰(research preview) 상태이며 디자인 파트너를 위해 팀별로 활성화"되고 대기자 명단이 있습니다. 서드파티 하네스 지원은 클라우드 에이전트로 실행될 때 적용됩니다. "리서치 프리뷰 기간 동안 서드파티 하네스를 로컬에서 실행하는 것은 지원되지 않습니다." 그리고 이는 Warp에 상주합니다. "메모리는 읽거나 쓰는 하네스에 관계없이 소유자(사용자, 에이전트 또는 팀)에게 귀속된 상태로 유지됩니다."

따라서 솔직히 말해서, 귀하의 팀이 디자인 파트너이고 Codex를 Warp 클라우드 에이전트로 실행하는 경우 호스팅된 메모리 레이어를 얻게 됩니다. 그렇지 않거나 자체 터미널에서 로컬로 Codex를 실행하는 경우에는 얻지 못하며, 기본적으로 비활성화되어 있고 turning on Codex's local memories에서 다루는 Codex 자체의 로컬 메모리는 사용자의 컴퓨터에 그대로 남게 됩니다.

1단계: 파일을 이동한 다음, 모든 재정의(override)를 모순(반대 지침)으로 다시 기술하기

각 AGENTS.md를 동일한 경로로 복사합니다. 내용에는 변화가 없습니다.

그 다음 판단이 필요한 부분인 재정의(override)를 처리합니다. 트리 내의 모든 AGENTS.override.md에 대해, 그것이 무엇을 억제하고 있었는지 자문해 보십시오. 루트 규칙을 대체하기 위해 존재했다면(예: "npm test 대신 make test-payments 사용"), 해당 디렉터리의 AGENTS.md에 명시적인 지침으로 다시 기술하십시오. Warp에서는 루트 규칙이 여전히 적용되며, 우선순위는 두 규칙이 직접 충돌하는 경우에만 도움이 되기 때문입니다. 대체안을 제공하지 않고 루트 규칙을 억제하기만 하기 위해 존재했다면, 침묵은 더 이상 아무것도 억제하지 못하므로 이를 평이한 문장으로 명시해야 합니다.

이 작업을 하는 김에 글로벌 파일도 확인하십시오. ~/.codex/AGENTS.md를 설명이 포함된 개별 Global Rules로 나누고, 변경 사항을 검토하고 싶다면 버전 관리 시스템에 복사본을 보관하십시오. Warp Drive 창은 훌륭한 편집 화면이지만 git 히스토리는 아닙니다.

만약 저장소에서 project_doc_fallback_filenames를 통해 사용자 정의 파일명을 사용했다면, 해당 경로에서 이름을 AGENTS.md(대문자)로 변경하십시오. Warp의 /init은 기존의 외부 규칙 파일을 연결할 수도 있으며, 문서화된 목록은 구체적입니다: "CLAUDE.md, .cursorrules, AGENT.md, GEMINI.md, .clinerules, .windsurfrules, .github/copilot-instructions.md." 이 목록에서 단수형인 AGENT.md에 유의하십시오. 복수형인 AGENTS.md는 기본적으로 읽힙니다.

2단계: Agent Memory에 대해 솔직하게 결정한 다음, 인덱싱 및 검증하기

Agent Memory를 중심으로 계획을 세우기 전에 두 가지 질문에 답해 보십시오. 귀하의 팀이 리서치 프리뷰에 활성화되어 있습니까? 그리고 Codex를 로컬이 아닌 Warp 클라우드 에이전트로 실행할 예정입니까? 둘 중 하나라도 '아니오'라면 Agent Memory를 미래의 기능으로 취급하고 현재는 없는 것처럼 설계하십시오.

이는 해당 기능에 대한 비판이 아닙니다. 문서에 명시된 내용이며, 등록되지 않은 리서치 프리뷰를 기반으로 워크플로우를 구축하면 결국 3주 후에나 발견하게 될 컨텍스트 공백이 발생하기 때문입니다.

그런 다음 확실히 얻을 수 있는 것을 설정하십시오. 인덱싱이 시작되도록 Warp에서 저장소를 열고, Settings > Code > Indexing and projects에서 상태가 동기화됨(Synced)으로 표시될 때까지 확인하십시오. 저장소가 크다면 .warpindexingignore를 추가하십시오. 그런 다음 에이전트 대화를 한 번 실행하고 References 섹션을 확인하여 실제로 어떤 규칙이 반영되었는지 확인하십시오. 이는 Codex의 지침 요약 명령을 실행하는 것과 같은 직관이며, why agents ignore your instruction files의 원인은 대개 이해력 문제라기보다는 탐색(discovery) 문제입니다.

파일 마이그레이션은 복사와 재정의(override) 감사로 이루어집니다. 이번 이동을 통해 드러난 점은, 지속되어야 할 프로젝트 지식이 특정 도구(한 컴퓨터의 Codex 로컬 메모리 또는 클라우드에서 실행 중이고 등록된 경우 Warp의 Agent Memory)에 의존하고 있었다는 사실입니다.

둘 다 유용한 기능입니다. 하지만 등록 상태, 컴퓨터, 또는 에이전트가 실행되는 위치에 관계없이 필요한 지식을 보관하기에는 적절하지 않습니다. 해당 레이어는 하네스의 속성이 되어서는 안 됩니다.

이를 외부에 두면 계산이 단순해집니다. 규칙을 마이그레이션하고, 코드베이스 인덱싱을 얻으며, 에이전트가 필요한 사실들은 첫 실행 시 이미 그곳에 존재하게 됩니다. MemoryLake는 세 단계로 설정할 수 있습니다.

1단계: API 키 생성

로그인한 후 대시보드에서 API 키를 생성합니다. 이는 리서치 프리뷰 등록 여부나 에이전트가 로컬에서 실행되는지 클라우드 에이전트로 실행되는지 여부에 의존하지 않으며, 이는 정확히 이번 마이그레이션이 야기하는 모호함을 해결해 줍니다.

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

규칙 파일이나 인덱스가 제공할 수 없는 것들을 입력하십시오. 아키텍처 결정과 그 배경 이유, 더 이상 사용되지 않는(deprecated) 서비스가 여전히 존재하는 이유, 도메인 어휘, 소유권, 이유가 수반된 제약 조건 등이 이에 해당합니다.

동작 관련 지침은 AGENTS.md에 유지하되, 이제 싸워야 할 32 KiB 한계가 없어졌습니다. 이는 억지로가 아니라 의도적으로 파일을 짧게 유지할 수 있는 좋은 이유가 됩니다.

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

Warp를 해당 저장소로 지정하고, 두 도구를 모두 실행하는 동안 Codex도 동일하게 지정하십시오. 단계별 마이그레이션이야말로 공유 레이어가 제 역할을 톡톡히 하는 때입니다. 그렇지 않으면 두 도구가 각각 불완전한 그림을 가지게 되기 때문입니다. 이에 대한 내용은 sharing one memory across tools에서 다루고 있습니다.

첫 번째 변화는 재정의(override) 감사가 반복되는 예기치 못한 문제가 아니라 일회성 비용이 된다는 점입니다. 예외 사항이 암시되는 대신 명시되면, 다음 도구로 전환하더라도 그대로 유지됩니다.

두 번째는 바이트 제한이 사라졌다고 해서 규율을 잃어서는 안 된다는 점입니다. 32 KiB는 임의적인 한계였을 뿐이며, 짧은 지침 파일이 긴 파일보다 여전히 더 잘 준수됩니다. 이전에는 그 예산을 두고 경쟁해야 했던 사실들은 이제 다른 곳에 존재합니다.

세 번째는 Agent Memory가 의존성이 아닌 보너스가 된다는 점입니다. 팀이 등록되면 이미 가지고 있는 것 위에 추적 및 감사가 가능하고 팀이 공유하는 메모리가 추가됩니다. 등록되지 않더라도 설정 중 어느 것도 이에 의존하지 않으므로 문제가 없습니다. 이것이 바로 keeping team AI context independent of any one tool에서 강조하는 핵심입니다.

• 파일명은 반드시 대문자로 유지하십시오. Warp는 대문자를 요구하며, Codex에 등록된 소문자 및 사용자 정의 이름은 인식되지 않습니다.
• 모든 AGENTS.override.md를 감사하십시오. Warp는 루트와 현재 디렉터리를 함께 적용하므로, 파일의 부재가 더 이상 규칙을 억제하지 않습니다.
• 억제하려는 내용을 명시적으로 다시 기술하십시오. 없애고 싶은 규칙은 생략하는 것이 아니라 문장으로 명시해야 합니다.
• 글로벌 파일을 설명이 포함된 규칙들로 나누십시오. 그리고 변경 이력을 원한다면 버전 관리되는 복사본을 보관하십시오.
• 품질을 판단하기 전에 인덱싱이 완료되도록 하십시오. 동기화됨(Synced) 상태를 확인하고, 대규모 저장소에서는 .warpindexingignore를 사용하십시오.
• References 섹션을 확인하십시오. 이는 Codex의 지침 요약 명령에 대한 Warp의 대답입니다.
• 등록되지 않은 경우 Agent Memory를 전제로 계획을 세우지 마십시오. 리서치 프리뷰 단계이며, 디자인 파트너를 위한 팀별 제공 및 프리뷰 기간 동안에는 클라우드 에이전트만 지원됩니다.
• 그럼에도 불구하고 지침 파일은 짧게 유지하십시오. 32 KiB 제한은 사라졌지만, 간결해야 하는 이유는 사라지지 않았습니다.

이번 마이그레이션에서 파일 부분은 복사만 하면 되며, 코드베이스 인덱싱과 바이트 제한 해제라는 두 가지 실질적인 이점은 아무런 작업 없이도 제공됩니다.

의도적으로 처리해야 할 두 가지는 마이그레이션 후 유지되지 않는 재정의(override) 의미론과, 훌륭하지만 문서화된 세 가지 조건이 따르는 Agent Memory입니다. 예외 사항을 다시 기술하고, 지속되어야 할 사실들을 두 도구 모두 소유하지 않는 레이어에 보관하십시오. 그러면 전환 비용은 에이전트가 이전에 알고 있던 내용을 다시 알아내기 위해 한 분기를 허비하는 대신 단 하루 오후 정도의 시간만 소요될 것입니다.