컨텍스트 손실 없이 Cursor Rules를 Codex로 마이그레이션하는 방법 (2026)

Cursor와 Codex는 둘 다 Markdown 지침을 읽습니다. 하지만 이러한 유사성 뒤에는 중요한 차이점이 숨어 있습니다.

규칙 내용은 그대로 전송됩니다. .mdc 파일의 Markdown 본문은 모델에 전달되는 지침일 뿐입니다. 텍스트 내용을 다시 작성할 필요는 없습니다.

규칙 활성화 방식은 전송되지 않습니다. Codex에는 활성화 모델이 없기 때문입니다. Cursor의 프로젝트 규칙은 .cursor/rules에 description, globs, alwaysApply와 같은 frontmatter를 가진 .mdc 파일로 저장되며, 그 위에 4가지 모드가 구축되어 있습니다:

• Always Apply (항상 적용) — 모든 채팅 세션에 적용됨
• Apply Intelligently (지능적 적용) — 에이전트가 설명을 바탕으로 관련이 있다고 판단할 때 적용됨
• Apply to Specific Files (특정 파일에 적용) — 파일이 지정된 패턴과 일치할 때 적용됨
• Apply Manually (수동 적용) — 채팅에서 @-mention으로 호출될 때 적용됨

Codex는 단 하나의 메커니즘인 AGENTS.md를 사용합니다. 이는 Codex 홈 디렉토리(~/.codex/AGENTS.md 또는 $CODEX_HOME)에서 시작하여 리포지토리 루트 및 중간 디렉토리를 거쳐 작업 디렉토리까지 계층적으로 해석되며, 상위에서 하위로 결합되되 더 가까운 파일이 우선순위를 갖습니다. 범위(Scope)는 glob이나 설명이 아니라 파일이 위치한 곳에 의해 결정됩니다. '에이전트가 관련 여부를 판단하는' 단계는 존재하지 않습니다.

이것이 마이그레이션 문제의 핵심입니다. 4가지 조건부 모드를 하나의 위치 기반 메커니즘으로 평탄화(flatten)해야 합니다.

`AGENTS.md`는 직접 전송되며, 이미 가지고 계실 수도 있습니다. Cursor는 .cursor/rules 대신 프로젝트 루트에서 AGENTS.md를 지원하며, 하위 디렉토리의 중첩된 파일도 지원합니다. 규칙이 이미 여기에 있다면, Codex가 원하는 형태와 정확히 일치하므로 마이그레이션 작업이 거의 필요 없습니다.

User Rules(사용자 규칙)는 글로벌 파일로 전송됩니다. Cursor의 User Rules는 모든 프로젝트에 적용되는 Customize → Rules에 정의된 글로벌 설정입니다. 이에 상응하는 Codex 파일은 ~/.codex/AGENTS.md입니다. 의도는 동일하고 위치만 다르므로 복사-붙여넣기 외에 별도의 변환이 필요하지 않습니다.

MCP 서버, 설정, 플러그인, 슬래시 명령어, 최근 세션은 가져오기 도구(importer)를 통해 전송됩니다. /import는 6가지 영역을 처리합니다: config.toml로 변환되는 settings.json, 두 가지 JSON 방식을 모두 지원하는 MCP 서버, 플러그인, 지난 30일 동안의 최근 세션 최대 50개, 커스텀 슬래시 명령어, 프로젝트 범위의 메모리입니다.

일부 항목은 가져올 수 없습니다. Cursor 웹 인터페이스의 채팅 기록은 가져올 수 없으며, 로컬 세션 데이터만 가져올 수 있습니다. 가져오기는 단방향으로 작동하므로 Codex에서 변경한 내용은 Cursor로 다시 전달되지 않습니다. 또한 메모리 정확도가 보장되지 않습니다. Cursor의 composer 기록과 같이 도구 전용 기능을 참조하는 메모리는 Codex의 작동 모델에 매핑되지 않으므로, 가져온 후 /memories list로 2분 동안 검토해 볼 가치가 있습니다.

양방향 모두 전송되지 않는 한 가지는 바로 규칙 뒤에 숨겨진 추론(reasoning)입니다. Cursor의 자체 문서에서는 규칙이 존재하는 이유에 대해 다음과 같이 직설적으로 설명합니다. "대규모 언어 모델은 완료(completion) 간에 메모리를 유지하지 않습니다. 규칙은 프롬프트 수준에서 지속적이고 재사용 가능한 컨텍스트를 제공합니다." 규칙은 임시방편일 뿐이며, 여러분이 직접 작성해 둔 내용만 담을 수 있는 한계가 있습니다.

1단계: 활성화 방식에 따라 규칙 분류하기

명령어를 실행하기 전에 각 .mdc 파일을 열고 frontmatter를 기준으로 분류하세요. 활성화 모드에 따라 대상 위치가 결정되기 때문입니다.

`alwaysApply: true` → 이 규칙들은 실제 범위에 맞는 수준의 AGENTS.md로 바로 이동합니다. 규칙이 작업 전반에 걸쳐 진정으로 글로벌하게 적용된다면 ~/.codex/AGENTS.md에 위치해야 합니다. 이 리포지토리에만 해당된다면 리포지토리 루트에 둡니다. 별도의 고민 없이 바로 매핑할 수 있습니다.

`globs`가 있는 규칙 → 이 규칙들은 변환이 아니라 '배치'가 필요합니다. src/api/** 범위로 지정된 규칙은 src/api/ 내부의 AGENTS.md가 되며, Codex는 해당 디렉토리에서 작업할 때 이를 감지합니다. 이 변환은 노력할 만한 가치가 있습니다. 제대로 수행하면 범위 지정 동작을 유지할 수 있지만, 게으르게 루트 파일에 모두 쏟아부으면 API 전용 규칙이 CSS 작업에도 적용되는 결과를 초래합니다.

glob이 디렉토리에 깔끔하게 매핑되지 않는 경우(예: 트리 전체에 흩어져 있는 **/*.test.ts), 두 가지 현실적인 옵션이 있습니다. 가장 가까운 AGENTS.md 내부에 텍스트로 조건을 명시하거나("테스트 파일을 편집할 때, ..."), 항상 로드되는 것을 감수하는 것입니다. 텍스트 조건은 glob 매칭보다 약합니다(모델이 조건이 적용되는지 직접 인지해야 함). 따라서 규칙 적용을 놓쳐도 큰 문제가 없는 경우에만 텍스트 조건을 사용하세요.

Apply Intelligently를 사용하는 규칙 → 가장 신중하게 고민해야 할 부분입니다. Cursor는 런타임에 description을 기반으로 규칙의 관련성 여부를 결정했습니다. 하지만 Codex는 그렇게 하지 않습니다. 각 규칙은 항상 켜져 있거나(매 요청마다 컨텍스트 비용 발생) 사실상 사라지게 됩니다. 중요도가 높은 규칙은 파일에 넣고, 있으면 좋은 수준의 규칙은 과감히 제외하세요. 모든 규칙을 루트 파일로 마이그레이션하지 마십시오. 이는 흔히 저지르는 실수이며, 결국 모두가 후회하는 비대해진 지침 파일로 이어집니다.

Apply Manually 규칙 → 이 규칙들은 사용자가 의도적으로 가져온 참조 문서였습니다. 이 파일들은 리포지토리 내의 문서(예: docs/ 디렉토리)로 유지하고, AGENTS.md에 해당 작업 시 관련 파일을 읽으라는 지침을 한 줄 추가하세요. 인라인으로 직접 넣지 마십시오.

이 작업을 수행하는 동안 새 환경에서도 Cursor의 크기 관련 권장 사항을 적용하세요. 규칙을 500행 미만으로 유지하고, 더 큰 규칙은 조합 가능한 조각으로 나누십시오. 이는 Cursor에서도 좋은 지침이었지만, 범위 내의 모든 항목이 매 작업마다 로드되는 Codex에서는 더욱 유용한 지침입니다.

2단계: /import 실행 후 매핑되지 않은 부분 수정하기

Codex v0.145 이상 버전을 사용 중인지 확인하고, 프로젝트 루트에서 새로운 Codex TUI 세션을 시작한 뒤 /import를 실행합니다. 소스로 Cursor를 선택하고 원하는 카테고리를 지정합니다. /import는 로컬 임베디드 TUI 세션이 필요하며, 원격 세션이나 작업이 진행 중인 동안에는 실행할 수 없습니다.

그 다음, 가져오기 도구가 대신해 줄 수 없는 검토 작업을 직접 수행합니다:

1. 생성된 `AGENTS.md`를 읽어보세요. composer 기록, @-mention 워크플로우, Cursor 전용 도구 이름 등 Cursor에 특화된 개념으로 표현된 내용은 모두 다시 작성하거나 삭제해야 합니다. 그렇지 않으면 Codex에 존재하지 않는 기능을 사용하라는 지침이 그대로 남아있게 됩니다.
2. glob 범위의 규칙들을 1단계에 따라 하위 디렉토리의 AGENTS.md 파일에 배치하세요. 가져오기 도구는 콘텐츠만 이동시킬 뿐, frontmatter를 기반으로 디렉토리 구조를 유추하지 않습니다.
3. `/memories list`를 실행하여 어떤 내용이 넘어왔는지 확인하세요. Cursor의 메커니즘을 참조하는 가져온 메모리는 기껏해야 노이즈에 불과합니다.
4. MCP 서버가 실제로 시작되는지 확인하세요. 두 JSON 방식 모두 변환되지만, 변환된 설정도 결국 설정일 뿐입니다. Cursor에서 환경 변수가 필요했던 서버는 Codex에서도 동일하게 환경 변수가 필요합니다.

그 다음, 지침과는 별개인 Codex 자체 메모리 기능의 사용 여부를 결정합니다. 로컬 Codex 메모리는 기본적으로 비활성화되어 있습니다. 데스크톱 앱의 Settings → Personalization에서 "Enable memories"를 활성화하거나, ~/.codex/config.toml의 [features] 섹션에서 memories = true로 설정하세요. EEA, 영국, 스위스에서는 활성화한 후에만 Codex가 메모리를 사용하거나 생성합니다. 두 가지 설정을 개별적으로 제어할 수도 있습니다:

```toml [features] memories = true

[memories] generate_memories = true # 새 세션에서 메모리 추출 use_memories = true # 향후 세션에 메모리 주입 ```

활성화하면 Codex는 스레드 간에 일관된 선호도, 반복되는 워크플로우, 기술 스택, 프로젝트 컨벤션, 알려진 함정 등을 유지하며, 요약, 영구 항목, 최근 입력 및 지원 증거를 ~/.codex/memories/ 아래에 저장합니다.

활성화할 가치가 충분합니다. 또한 공식 주의 사항도 읽어볼 필요가 있습니다. 메모리 생성은 활성 상태이거나 수명이 짧은 세션을 건너뛰고, 남은 속도 제한(rate-limit) 비율이 설정된 임계값 미만으로 떨어지면 일시 중지되며, 채팅이 종료된 직후에 바로 업데이트되지 않을 수 있습니다. 생성된 파일은 직접 편집해서는 안 되는 생성된 상태 파일입니다. 비밀 정보는 생성된 메모리 필드에서 마스킹되지만, 공유하기 전에 검토하는 것이 좋습니다. 그리고 이 저장소는 프로젝트별이 아닌 글로벌 단위이며 해당 기기에 로컬로 저장됩니다. 즉, 동기화되지 않으며 한 리포지토리의 메모리가 다른 리포지토리에서 나타날 수 있습니다.

1단계는 흥미로운 작업이었지만, 그 본질을 생각해보면 한 도구의 활성화 모델을 다른 도구의 디렉토리 레이아웃으로 번역하는 작업이었습니다. 이러한 노력은 재사용 가능한 결과를 낳지 못합니다. 다음 에디터로 바꿀 때 이 짓을 또 해야 합니다.

또한 애초에 규칙 파일에 없었기 때문에 이번 마이그레이션에 전혀 포함되지 않는 지식 부류도 있습니다. 재시도 로직이 왜 잘못되어 보이지만 실제로는 맞는지, 지난 3월에 클라이언트가 거절한 사항은 무엇인지, 금요일 오후 6시에 발견한 제약 조건은 무엇인지 등입니다. 규칙은 여러분이 마음먹고 작성해 둔 내용만 담고 있을 뿐이며, 나머지는 내보내기(export) 시 사라지는 대화 스레드 속에 묻혀 있습니다.

이 레이어를 에디터 외부에 유지하면 두 가지 문제 모두를 해결할 수 있습니다. MemoryLake는 도구들이 읽어오는 메모리 레이어입니다. 의사 결정, 문서, 누적된 컨텍스트를 하나의 저장소에 담아 MCP를 통해 Codex 및 Cursor에서 접근할 수 있고, API를 통해 다른 모든 도구에서도 접근할 수 있습니다. 이렇게 하면 다음 마이그레이션은 변환 프로젝트가 아니라 단순한 설정 항목 추가가 됩니다.

공정하게 말하자면, .cursor/rules와 AGENTS.md에도 확실한 장점이 있습니다. 평문 텍스트이고, 리포지토리에 저장되며, 풀 리퀘스트(PR)에서 검토할 수 있고, 팀원들이 별도의 작업 없이도 그대로 물려받을 수 있습니다. 상시 적용되는 규칙은 이 파일들에 유지하세요. 그것이 이 파일들의 강점이며, Codex도 이를 기본적으로 읽을 수 있습니다. 반면 메모리 레이어는 매번 로드하기에는 너무 길거나, 공개하기에는 너무 구체적이거나, 누군가 기록해 두는 것을 잊어버려 유실되기 쉬운 정보를 보관하는 데 제격입니다.

1단계: API 키 생성하기

키를 생성하고 약 30초 만에 첫 번째 요청을 보낼 수 있습니다. 설정 파일 대신 환경 변수나 시크릿 관리자에 키를 보관하세요. 설정 파일은 바로 이러한 마이그레이션 과정에서 복사되기 쉬운 대상이기 때문입니다.

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

규칙이 담지 못했던 컨텍스트가 포함된 문서, 이미지, 파일을 업로드하세요. 아키텍처 결정 사항과 그 이유, 이상한 재시도 로직을 설명하는 장애 보고서, 클라이언트의 제약 조건 등이 이에 해당합니다. 가능한 한 요약본보다는 원본 소스를 업로드하는 것이 좋습니다.

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

Claude, Codex, OpenClaw 및 기타 AI 에이전트가 MCP 또는 API를 통해 메모리에 액세스할 수 있도록 허용합니다. Codex는 MCP 서버를 지원하며, 가져오기 도구가 이미 기존 MCP 설정을 변환했으므로 서버 항목을 하나만 더 추가하면 됩니다. 이렇게 하면 Cursor를 계속 사용하더라도 동일한 저장소를 읽을 수 있으며, API를 기반으로 구축하는 모든 도구에서도 접근할 수 있습니다.

첫 번째 차이점은 규칙 마이그레이션 시 정보 손실이 없어진다는 것입니다. 지금은 활성화 로직과 기록되지 않은 지식을 잃게 되지만, 이 방식을 사용하면 순수하게 파일 형태인 부분만 변환하면 됩니다.

두 번째는 두 에디터를 동시에 사용하는 것이 자연스러워진다는 점입니다. 많은 사람들이 편집용으로는 Cursor를 유지하고, 더 긴 에이전트 실행 작업에는 Codex를 사용합니다. 현재로서는 두 가지 형식으로 동일한 컨벤션의 복사본 두 개를 유지 관리해야 하며, 이들이 서로 어긋나는 것을 지켜봐야 합니다. 두 에디터가 모두 읽을 수 있는 단일 저장소를 사용하면 이러한 중복이 제거됩니다. 이는 MCP를 통해 공유 메모리를 연결하는 작업을 도구별로 매번 하는 대신 한 번만 해둘 가치가 있는 이유와 같습니다.

세 번째는 기기 독립성입니다. Codex 메모리는 설계상 로컬에 저장되므로, 완벽하게 마이그레이션을 마쳤더라도 두 번째 노트북에서는 빈 상태로 시작하게 됩니다. 하지만 메모리 레이어는 이러한 제약이 없습니다.

또한 지침 파일의 크기가 작아집니다. 이는 Cursor보다 Codex에서 더 중요한데, 범위 내의 모든 항목이 매 작업마다 로드되기 때문입니다. 따라서 Codex가 프로젝트 컨텍스트 없이 각 세션을 시작하는 현상은 더 긴 루트 파일을 작성하는 방식이 아니라, 검색(retrieval)을 통해 해결해야 하는 문제입니다.

파일 단위가 아닌 활성화 모드 단위로 변환하기

직관적으로는 파일별로 마이그레이션하고 싶어집니다. 하지만 그 대신 frontmatter(alwaysApply, globs, 설명 기반, 수동)를 기준으로 정렬하세요. 각 모드마다 대상 위치가 다르고, 그중 하나(Apply Intelligently)는 갈 곳이 없기 때문입니다. 파일별로 마이그레이션하면 결국 모든 내용이 루트 AGENTS.md에 들어가게 됩니다.

범위가 지정된 규칙은 해당 디렉토리에 배치하기

API 레이어에 대한 규칙은 API 디렉토리 내부의 AGENTS.md에 있어야 합니다. 이는 전체 마이그레이션에서 가장 가치 있는 습관입니다. 유실될 수 있는 범위 지정을 보존하고 루트 파일을 짧게 유지할 수 있습니다. 또한 새로운 팀원이 코드가 있는 위치에서 해당 규칙을 바로 발견할 수 있게 해줍니다.

가져오기 결과를 맹신하지 말고 검토하기

/import는 훌륭한 도구이지만 번역기는 아닙니다. 출력 결과를 읽고, Cursor 전용 표현을 삭제하고, /memories list를 실행하고, MCP 서버가 시작되는지 확인하세요. 여기서 15분을 투자하면 에이전트가 다른 도구용으로 작성된 지침을 따르느라 몇 달 동안 헤매는 일을 방지할 수 있습니다.

실제로 항상 켜두어야 할 규칙 결정하기

범위 내의 모든 항목은 앞으로 모든 요청마다 컨텍스트 비용을 발생시킵니다. 이전에 조건부였던 규칙을 항상 켜짐 상태로 승격하기 전에, 모든 작업마다 그 비용을 지불할 가치가 있는지 자문해 보세요. 대부분의 Apply Intelligently 규칙은 이 테스트를 통과하지 못하며, 이를 과감히 삭제하는 것이 그대로 가져가는 것보다 더 나은 결과를 낳습니다.

기계적인 부분은 이제 간단합니다. Codex v0.145는 명령어 하나로 Cursor 설정, MCP 서버, 플러그인, 세션, 슬래시 명령어, 프로젝트 범위 메모리를 가져옵니다. 여러분의 판단이 필요한 부분은 Cursor의 4가지 활성화 모드가 Codex의 단일 위치 기반 메커니즘으로 축소된다는 점입니다. 따라서 alwaysApply 규칙은 바로 이동하고, glob 범위 규칙은 하위 디렉토리의 AGENTS.md 파일이 되며, 설명 트리거 규칙은 의도적으로 승격하거나 제외해야 하고, 수동 규칙은 참조할 문서로 남겨두어야 합니다.

그리고 애초에 파일에 없었기 때문에 이번 마이그레이션이 전혀 건드리지 못하는 레이어가 있습니다. 두 에디터가 모두 읽을 수 있는 저장소에 이를 보관하는 것은 단순히 규칙을 마이그레이션하는 것과 '지식'을 마이그레이션하는 것의 차이입니다. 그리고 이것이 바로 다음 도구 전환 시 또 다른 오후 시간을 허비하지 않도록 막아주는 핵심 열쇠입니다.