Claude Code와 Codex를 병렬로 활용하기: 작은 Git worktree 실험

Claude Code에 문구 수정을 맡기고 Codex에 내보내기 버그 수정을 맡기려면, 먼저 작업마다 별도의 디렉터리를 준비하세요.

두 대화가 같은 디렉터리를 가리키면 한 에이전트가 수정한 파일이 다른 에이전트의 입력이 됩니다. “테스트 통과”라는 결과를 봐도 어느 변경 사항을 검증한 것인지 구분하기 어려워질 수 있습니다.

설정 설명을 수정하면서 빈 날짜 내보내기 문제를 고치는 상황을 예로 들어 보겠습니다. 병렬로 진행하고 따로 검토할 수 있는 두 작업입니다. 이 재현 가능한 실험에서는 디렉터리를 나누고, 작업을 배정하고, 합친 결과를 테스트합니다. 실험은 스크립트로 수행했으며, 요청 문구는 각자의 프로젝트에 맞게 바꿔 쓸 수 있는 예시입니다.

먼저 각 작업의 범위와 완료 기준을 정하세요

예제 프로젝트에는 설정 문구 파일과 타임스탬프를 내보내기용 날짜로 바꾸는 함수가 있습니다.

문구 작업은 settings.zh-CN.json만 수정합니다. “管理设备”의 설명을 “查看已登录设备，并撤销不再使用的设备访问”으로 바꿉니다. 날짜 작업은 값이 없을 때의 동작만 수정하고, 유효한 타임스탬프를 UTC 날짜로 내보내는 기존 규칙은 유지합니다.

실험을 그대로 재현할 수 있도록 예제의 중국어 간체 문자열은 유지합니다. “管理设备”는 “기기 관리”, 새 설명은 “로그인된 기기를 확인하고 더 이상 사용하지 않는 기기의 접근 권한을 철회하세요”라는 뜻입니다.

기존 날짜 함수의 처리는 한 줄입니다.

export function exportDate(value) {
  return new Date(value).toISOString().slice(0, 10);
}

null을 받으면 1970-01-01을 반환하고, 빈 문자열을 받으면 예외를 던집니다. 둘 다 날짜가 없으면 빈 값으로 남겨야 한다는 요구 사항에 맞지 않습니다.

먼저 네 가지 테스트를 실행합니다. 값이 없는 두 사례는 실패하고, UTC 타임스탬프와 시간대가 포함된 타임스탬프 사례는 통과합니다. 이 기준 상태가 중요합니다. 날짜 작업은 앞의 두 사례를 고치면서 뒤의 두 사례는 기존 동작을 유지해야 합니다.

같은 커밋에서 작업 디렉터리 두 개를 만드세요

main 브랜치가 있는 저장소에서 시작 커밋을 먼저 확인하세요. 아래 명령은 새 브랜치 이름과 대상 디렉터리가 아직 사용되지 않는다는 전제입니다.

git worktree add -b feature/settings-copy ../project-settings-copy main
git worktree add -b fix/export-dates ../project-export-dates main
git worktree list

각 worktree에는 별도의 체크아웃 디렉터리와 인덱스, 즉 스테이징 영역이 있으므로 서로 다른 브랜치에서 변경 사항을 관리할 수 있습니다. 다만 같은 Git 저장소에 속합니다. 새 디렉터리는 지정한 커밋에서 시작하며, 원래 디렉터리의 미커밋 변경 사항을 자동으로 가져오지 않습니다. 프로젝트에 맞게 의존성과 로컬 설정을 준비하세요. 자세한 내용은 공식 Git worktree 문서를 참고하세요.

생성한 두 작업의 디렉터리와 브랜치는 다음과 같습니다.

작업마다 디렉터리를 주면 두 작업 사본을 동시에 유지할 수 있습니다. 하나의 디렉터리에서 브랜치만 전환하는 것으로는 이렇게 분리할 수 없습니다.

Tactic Remote에서 대화마다 올바른 디렉터리를 선택하세요

개발용 컴퓨터에 연결하고 새 대화에서 프로젝트 선택을 여세요. 필요하면 다른 폴더 선택을 사용해 해당 worktree의 실제 경로를 지정한 뒤 에이전트를 선택하세요.

저장소의 worktree를 이미 만들었다면 해당 디렉터리를 바로 선택하면 됩니다. 독립 작업 공간을 새로 만든다고 그 저장소나 브랜치 관계가 자동으로 포함되지는 않습니다.

Claude Code에는 다음처럼 첫 요청을 보낼 수 있습니다.

settings.zh-CN.json의 기기 설명만 수정해 줘. 로그인된 기기를 확인하고 접근 권한을 철회할 수 있다는 점이 명확해야 해. 먼저 현재 디렉터리와 브랜치를 확인해 줘. 날짜 내보내기 로직은 변경하지 마. 끝나면 문구 변경 내용을 보여 주고 JSON이 유효한지 확인해 줘.

Codex에는 다음처럼 요청할 수 있습니다.

export-date.mjs를 수정해 줘. null과 빈 문자열은 빈 문자열을 반환하고, 유효한 타임스탬프는 계속 UTC 날짜로 내보내야 해. 먼저 현재 디렉터리와 브랜치를 확인하고, 기존 테스트 네 개를 실행해 문제를 재현한 뒤 최소한으로 수정해 줘. 설정 문구는 변경하지 마. 수정 전후의 결과를 알려 줘.

프롬프트에서 파일 범위를 제한하면 나중에 검토하기 쉽지만, 보안 샌드박스가 되는 것은 아닙니다. 에이전트가 실제로 읽고 쓸 수 있는 파일은 컴퓨터에서 부여된 권한에 따라 결정됩니다.

각각 검증하고, 무엇을 통과했는지 구분하세요

예제의 최소 수정은 날짜를 변환하기 전에 값이 없는지 확인하는 것입니다.

export function exportDate(value) {
  if (value === null || value === undefined || value === '') return '';
  return new Date(value).toISOString().slice(0, 10);
}

이 코드는 합의한 누락 값만 처리합니다. 그 밖의 잘못된 날짜 문자열은 별도로 동작을 정해야 합니다. 유효한 타임스탬프는 계속 UTC 날짜로 내보냅니다.

각 작업 디렉터리에서 다음 명령을 실행하세요.

git status --short
git diff --name-only
git diff

이번 실험에서는 문구 디렉터리의 settings.zh-CN.json만 바뀌었고, 날짜 디렉터리에서는 export-date.mjs만 바뀌었습니다. 파일 내용도 직접 확인해 문구 디렉터리에는 기존 날짜 함수가, 날짜 디렉터리에는 기존 문구가 남아 있음을 확인했습니다.

검증 결과는 다음과 같습니다.

문구 브랜치는 JSON 검사를 통과했지만, 이미 알고 있던 날짜 테스트 실패 두 개는 그대로 남아 있습니다. 검증 범위와 기준 상태를 함께 기록해야 결과가 무엇을 확인해 주는지 분명해집니다.

마지막에는 명확한 통합 브랜치에서 합치세요

각 변경을 검토하고 커밋한 뒤, 예제 저장소의 원래 디렉터리에서 통합 브랜치를 만드세요.

git switch -c review/combine main
git merge --ff-only feature/settings-copy
git merge fix/export-dates
node --test export-date.test.mjs

이 절차는 원래 디렉터리에 미처리 변경 사항이 없고 두 작업 브랜치가 모두 커밋되어 있다는 전제입니다. 실제 프로젝트에서는 기존 PR 및 병합 절차를 따르세요. 충돌이 생기면 양쪽 변경의 의도를 먼저 이해한 뒤 합친 결과를 검증하세요.

각 브랜치가 개별 검증을 통과해도 함께 적용하면 서로 영향을 줄 수 있으므로, 병합 결과를 테스트해야 합니다. 작업 디렉터리를 분리해도 공용 설정, 의존성, 데이터베이스, 서버 포트는 조율이 필요합니다.

변경 사항이 보존되었고 작업 트리가 깨끗하며 디렉터리를 더 이상 사용하지 않는지 확인한 뒤 일반적인 git worktree remove로 제거하세요. Git이 변경 사항 때문에 제거를 거부하면 메시지에 표시된 미커밋 내용을 먼저 처리하세요.

휴대전화로 돌아왔을 때는 작업과 검증 결과부터 확인하세요

휴대전화에서 병렬 작업을 확인할 때는 컴퓨터, 프로젝트, 대화를 먼저 확인하세요. 최신 결과를 읽고 결정이 필요한 부분을 찾으면 됩니다.

문구 작업에서는 용어 하나만 결정하면 될 수 있습니다. 날짜 작업에서는 UTC와 현지 시간 중 어떤 기준으로 내보낼지 정해야 할 수 있습니다. 나중에 검토할 때 이유를 확인할 수 있도록 해당 대화에 결정을 남기세요.

이 방식은 두 작업부터 적용할 수 있습니다. 작업마다 디렉터리, 명확한 요청, 검증 결과를 두고, 마지막에 함께 적용한 동작을 확인하세요. 작업이 늘어나도 각 디렉터리와 요청, 테스트 결과를 구분할 수 있도록 유지하면 됩니다.

이 실험은 에이전트를 호출하지 않고 임시 로컬 Git 저장소에서 수행했습니다. 재현 스크립트와 원본 결과에서 각 단계를 확인할 수 있습니다.