Codex CLI import 마이그레이션: Cursor·Claude Code 설정 옮길 때 확인할 체크리스트

요약: Codex CLI 0.145.0에서 /import가 Cursor와 Claude Code 설정, MCP 서버, 플러그인, 세션, 명령, 프로젝트 범위 메모리까지 가져올 수 있게 확장됐습니다. 마이그레이션 자체는 편해졌지만, 그대로 옮기면 개인 환경의 습관과 권한까지 팀 환경에 섞일 수 있습니다. 안전하게 옮기려면 “무엇을 가져올지”보다 “무엇을 가져오지 않을지”를 먼저 정해야 합니다.

/import 확장이 의미하는 것

AI 코딩 도구를 여러 개 쓰는 개발자는 이미 많습니다. Cursor에는 프로젝트별 규칙이 있고, Claude Code에는 명령과 MCP 연결이 있으며, Codex에는 별도 세션과 메모리가 있습니다. 도구를 바꿀 때마다 같은 설정을 다시 만드는 것은 낭비입니다.

OpenAI Codex CLI 0.145.0의 /import 확장은 이 문제를 줄입니다. Cursor와 Claude Code의 settings, MCP servers, plugins, sessions, commands, project-scoped memories를 Codex 쪽으로 옮길 수 있습니다. 개발자 입장에서는 진입 장벽이 낮아집니다. 팀 입장에서는 표준화 기회가 생깁니다.

하지만 마이그레이션은 복사 작업이 아닙니다. 특히 AI 도구 설정에는 일반 IDE 설정보다 민감한 정보가 더 많이 들어갑니다. 외부 도구 권한, 로컬 경로, 개인 명령, 승인 규칙, 프로젝트 메모리가 섞여 있기 때문입니다.

가져오면 안 되는 항목

먼저 제외 목록부터 정해야 합니다.

첫째, 개인 로컬 경로입니다. 예를 들어 /Users/alice/work/private-client 같은 경로가 프로젝트 명령에 박혀 있으면 다른 개발자 환경에서 깨질 뿐 아니라 개인 작업 구조도 노출됩니다.

둘째, 인증 정보나 토큰에 가까운 값입니다. MCP 서버 설정에 API key가 직접 들어가 있거나, command가 특정 credential file을 참조할 수 있습니다. 이런 값은 절대 그대로 옮기면 안 됩니다. 환경변수나 secret manager를 통해 재연결해야 합니다.

셋째, 개인 승인 규칙입니다. “항상 허용” 규칙은 편하지만, 개인 레포에서 허용한 명령이 팀 레포에 맞는다는 보장은 없습니다. 특히 shell command, file write, network access 관련 규칙은 재검토해야 합니다.

넷째, 오래된 프로젝트 메모리입니다. 예전 아키텍처, 폐기된 API, 임시 우회책이 memory에 남아 있을 수 있습니다. 코딩 에이전트는 이런 메모리를 진실처럼 참조할 수 있으므로 정리 없이 가져오면 위험합니다.

안전한 마이그레이션 절차

실무에서는 다음 순서를 추천합니다.

1. 개인 환경에서 /import를 먼저 실행합니다.
2. 가져온 항목을 settings, commands, MCP, memory, sessions로 분류합니다.
3. 팀 공용으로 쓸 항목과 개인 전용으로 남길 항목을 나눕니다.
4. MCP 서버는 읽기 전용 권한부터 다시 연결합니다.
5. command는 dry-run 가능한 형태로 바꿉니다.
6. memory는 최신 아키텍처, 테스트 명령, 금지 사항만 남깁니다.
7. 표준 설정을 레포 문서에 남기고, 자동 적용은 나중에 합니다.

이 절차의 핵심은 import 결과를 곧바로 신뢰하지 않는 것입니다. import는 초안 생성 도구로 보고, 운영 설정은 리뷰를 거쳐야 합니다.

MCP 서버 점검 기준

MCP 설정은 가장 중요합니다. 도구 호출은 실제 외부 시스템에 닿기 때문입니다. 다음 질문에 답할 수 있어야 합니다.

• 이 MCP 서버는 읽기만 하는가, 쓰기도 하는가?
• 어떤 계정 권한으로 호출되는가?
• 호출 로그가 남는가?
• 실패 시 재시도 정책이 있는가?
• rate limit에 걸리면 사용자에게 어떻게 보이는가?
• 로컬 파일 시스템 접근이 필요한가?
• 팀원이 같은 설정을 써도 안전한가?

특히 GitHub, Jira, Slack, Notion, 데이터베이스 MCP는 쓰기 권한이 섞이기 쉽습니다. 처음에는 읽기 전용으로 시작하고, 쓰기 도구는 명시적인 승인 규칙과 audit log가 준비된 뒤에 켜는 편이 안전합니다.

명령어와 메모리 정리법

가져온 command는 실행 전에 이름부터 바꾸는 것이 좋습니다. “deploy”, “fix”, “cleanup” 같은 넓은 이름은 위험합니다. 대신 “staging-deploy-dry-run”, “lint-and-typecheck”, “collect-pr-context”처럼 행동 범위가 보이는 이름을 씁니다.

메모리는 더 엄격해야 합니다. 좋은 메모리는 짧고 검증 가능합니다.

좋은 예:

• 기본 브랜치는 develop이다.
• API 테스트는 npm run test:api로 실행한다.
• 결제 관련 파일 수정 후에는 환불 e2e 테스트를 반드시 실행한다.

나쁜 예:

• 이 프로젝트는 대충 Next.js 앱이다.
• 배포는 보통 알아서 하면 된다.
• 예전에 인증 버그가 있었던 것 같다.

메모리는 에이전트의 판단에 직접 영향을 줍니다. 애매한 문장은 없는 편이 낫습니다.

팀 표준으로 만들 때의 기준

개인 import가 안정적이었다고 바로 팀 표준으로 만들면 안 됩니다. 최소 1주일 정도는 파일 변경, 명령 실행, MCP 호출 로그를 보며 문제가 없는지 확인해야 합니다. 그 다음 팀 표준 문서에 반영합니다.

표준 문서에는 다음을 포함하세요.

• 지원하는 AI 코딩 도구 목록
• 공용 MCP 서버와 권한 범위
• 허용 command 목록
• 금지 command 목록
• 메모리 작성 규칙
• import 후 리뷰 절차
• 문제가 생겼을 때 되돌리는 방법

이 정도가 있어야 도구가 늘어도 팀 운영이 흔들리지 않습니다.

실행 체크리스트

• /import 실행 전 현재 설정을 백업한다.
• 가져온 설정에서 로컬 경로와 secret 참조를 찾는다.
• MCP 서버는 읽기, 쓰기, 위험 작업으로 분류한다.
• “항상 허용” 권한 규칙은 모두 재검토한다.
• command 이름을 행동 범위가 드러나게 바꾼다.
• project memory는 최신 사실만 남기고 추측성 문장은 제거한다.
• 팀 공용 설정은 PR 리뷰를 거쳐 반영한다.
• 첫 적용 후 1주일간 도구 호출 로그와 실패 패턴을 확인한다.

Codex CLI import는 도구 전환 비용을 줄이는 좋은 기능입니다. 하지만 설정을 옮기는 순간 권한, 습관, 오래된 맥락도 함께 이동합니다. 개발 생산성을 얻으려면 import를 자동 복사가 아니라 설정 리뷰의 시작점으로 사용해야 합니다.