Claude Code에서 하던 작업을 Codex로 이어 가면 앞의 대화를 기억하고 있을까요? 실제로 두 도구는 서로의 채팅 기억을 공유하지 않습니다. 저는 긴 프롬프트를 매번 복사하는 방식보다, 프로젝트의 구조와 판단을 로컬 파일에 남겨 두 도구가 같은 근거를 다시 읽게 하는 방식을 골랐습니다. 이 글은 Git 저장소 하나를 두 코딩 에이전트가 함께 읽는 워크스페이스로 만드는 방법을 정리합니다.
공유하는 것은 기억이 아니라 파일입니다
여기서 에이전트는 파일을 읽고 명령을 실행하며 수정안을 만드는 AI 작업 도구를 뜻합니다. Claude Code와 Codex는 대화 기록과 내부 상태가 서로 다르지만, 같은 저장소 안의 README와 지침, 코드, 실험 기록은 함께 읽을 수 있습니다. 따라서 “AI가 기억해 주겠지”라는 가정은 버리고, 다음 세션이 읽어야 할 사실을 파일로 만드는 편이 안전했습니다. Git은 그 파일들의 버전과 컴퓨터 간 이동을 맡습니다.
사람의 목표와 판단
↓
README / Theory / handoff 기록
↓
로컬 Git 워크스페이스
↙ ↘
Claude Code Codex
↘ ↙
코드·노트 수정 → 검증 → Git 이력
1. 먼저 Git 저장소를 로컬에 준비했습니다
두 도구가 같은 폴더를 보게 하려면 출발점은 특별한 클라우드 서비스가 아니라 로컬 Git 저장소입니다. 새 PC에서는 원격 저장소를 복제하고, 기존 PC에서는 작업 전에 최신 변경을 가져왔습니다. 저장소 주소와 사용자 경로는 각자 다르므로 글에는 실제 비공개 주소 대신 자리표시자를 씁니다. Git과 Obsidian 설치가 먼저 필요하다면 앞의 워크스페이스 기록 원칙 글과 별도의 설치 가이드를 참고하면 됩니다.
<repository-url>은 접근 가능한 원격 저장소 주소로, <repository-folder>는 복제된 폴더 이름으로 바꾸세요. 꺾쇠괄호는 실제 명령에 포함하지 않습니다. 이미 복제한 저장소가 있다면 해당 폴더를 열고 git status로 상태를 확인하면 됩니다.
git clone <repository-url>
cd <repository-folder>
git status
2. Claude Code는 저장소 루트에서 시작했습니다
Windows에서 Claude Code를 쓰는 방법은 설치 시점의 공식 지원 방식에 따라 달라질 수 있습니다. 저는 Anthropic의 Claude Code 설치 안내에서 Windows 요구사항을 확인하고, Git for Windows를 갖춘 환경에서 설치·인증 상태를 먼저 점검했습니다. 그다음 저장소 루트로 이동해 claude를 실행했습니다. 다른 폴더에서 시작하면 프로젝트 지침과 Git 경계를 잘못 읽을 수 있어 루트를 고정했습니다.
cd C:\path\to\workspace
claude
# 설치 상태 점검이 필요할 때
claude doctor
Claude Code에는 저장소에서 지켜야 할 규칙을 담은 CLAUDE.md를 두었습니다. 파일에는 프로젝트의 목표, 주요 폴더, 반드시 먼저 읽을 문서, 실행과 검증 방법을 적었습니다. 비밀번호나 API 키, 개인 계정 정보는 이 파일에 넣지 않았습니다. 지침은 AI에게 모든 답을 주는 문서가 아니라, 어떤 근거를 먼저 읽고 무엇을 함부로 바꾸지 말아야 하는지 알려 주는 경계입니다.
3. Codex도 같은 저장소 루트에서 열었습니다
Codex 역시 저장소 루트를 작업 폴더로 열고, 프로젝트 지침은 AGENTS.md에 기록했습니다. OpenAI의 Codex 문서에서 설명하는 것처럼 AGENTS 파일은 코드베이스에서 따라야 할 관례와 명령을 가까운 범위에 둘 수 있게 합니다. 저는 CLAUDE.md와 AGENTS.md의 핵심 구조를 맞추되, 도구별 사용법까지 억지로 하나의 파일에 섞지는 않았습니다. 공통 사실은 같은 문서를 가리키고, 도구별 실행 규칙만 각 지침에 남겼습니다.
workspace/
├─ README.md # 사람과 에이전트의 진입점
├─ CLAUDE.md # Claude Code 작업 규칙
├─ AGENTS.md # Codex 작업 규칙
├─ Theory.md # 현재 구조와 판단의 정본
├─ ENVIRONMENTS.md # PC 사이의 인수인계
└─ ...
4. 대화 대신 이어지는 기록을 만들었습니다
긴 작업은 코드만 커밋해도 다음 사람이 왜 그렇게 바꿨는지 알기 어렵습니다. 그래서 구조적 판단은 Theory 문서에, 컴퓨터를 옮길 때의 미완료 작업은 환경 인수인계 문서에 남겼습니다. 한 PC에서 작업을 끝낼 때 이 기록까지 커밋하고 푸시한 뒤, 다른 PC에서는 pull 직후 인수인계를 먼저 읽습니다. Claude에서 Codex로 바꿀 때도 같은 흐름을 따르므로 채팅을 복사하지 않아도 현재 상태를 복원할 수 있었습니다.
작업 종료
├─ 무엇을 바꿨는가
├─ 왜 바꿨는가
├─ 무엇을 검증했는가
└─ 다음에 무엇을 해야 하는가
↓ commit + push
다른 PC 또는 다른 에이전트
↓ pull + 지침/인수인계 읽기
같은 근거에서 작업 재개
5. 권한과 비밀 정보는 로컬 경계로 남겼습니다
에이전트가 파일과 터미널을 다룰 수 있다고 해서 모든 권한을 허용할 필요는 없습니다. 삭제, 외부 공개, 결제, 대규모 학습처럼 되돌리기 어렵거나 비용이 드는 행동은 사용자 확인이 필요하다고 지침에 적었습니다. API 키와 WordPress 비밀번호 같은 값은 환경 변수나 Git에서 제외된 로컬 파일에 저장했습니다. 이 구분 덕분에 저장소를 다른 PC로 옮겨도 비밀 정보까지 따라 올라가는 일을 막을 수 있었습니다.
정말 같은 워크스페이스를 읽는지 검증했습니다
설정 파일을 만들었다고 끝내지 않고 두 도구에 같은 읽기 전용 질문을 했습니다. “프로젝트의 목표는 무엇인가”, “먼저 읽어야 할 문서는 무엇인가”, “대용량 파일은 어디에 두는가”를 물어 답이 저장소 내용과 일치하는지 확인했습니다. 다음에는 작은 문서 수정과 테스트만 맡기고 Git diff를 직접 검토했습니다. 이 검증을 통과한 뒤에야 실제 구현 작업을 맡겼습니다.
완성된 구조가 해결한 것과 해결하지 못한 것
이 구조는 Claude Code와 Codex에게 같은 장기 기억을 만들어 주는 마법이 아닙니다. 두 도구는 여전히 파일을 잘못 해석하거나 오래된 지침을 따를 수 있어 사람이 diff와 실행 결과를 확인해야 합니다. 대신 프로젝트의 현재 구조와 이전 판단이 채팅창 안에서 사라지지 않고, 노트북과 데스크톱에서 같은 출발점을 제공합니다. 오늘의 한 줄 요약은 “에이전트 사이의 연속성은 대화가 아니라 버전 관리된 근거에서 나온다”는 것입니다.