빠른 흐름

git status
git add <related-files>
git commit -m "checkpoint before codex task"

# Codex 작업 후
git diff
git status

정리 흐름

체크포인트가 없으면 Codex의 변경과 기존 변경을 구분할 수 없다

OpenAI의 Quickstart와 보안 가이드는 Codex 작업 전후에 Git 체크포인트를 남기라고 반복해서 권합니다. 시작 시점이 분명해야 Codex가 만든 변경만 git diff로 바로 읽을 수 있고, 문제가 생기면 비교와 롤백도 쉬워집니다. 체크포인트 없이 시작하면 나중에 "어디까지가 내 수정이고 어디서부터 Codex가 바꿨는가"를 추적하기 매우 어렵습니다. 특히 Codex가 넓게 수정하는 리팩터링이나 마이그레이션 작업에서 이 문제는 더 심해집니다.

어수선한 작업 트리가 검토 비용을 크게 올리는 이유

작업 트리가 이미 어수선하면 Codex가 새로 만든 변경과 기존 수동 수정이 섞여 git diff 결과를 읽기가 어렵습니다. 어떤 변경이 Codex에서 나왔는지, 어떤 것이 직접 수정한 것인지 일일이 추적해야 하므로 검토 비용이 크게 올라갑니다. 이 이유만으로도 Codex를 실행하기 전에 현재 변경을 정리하거나 임시 커밋으로 체크포인트를 만드는 습관이 필요합니다.

권장 흐름
1. 현재 변경을 정리하거나 임시 커밋으로 체크포인트를 만든다.
2. Codex에게 수정 범위와 검증 조건을 준다.
3. 결과는 git diff와 최소 테스트로 확인한다.
4. 만족스럽지 않으면 체크포인트와 비교해 되돌리거나 다시 분기한다.

Worktree가 체크포인트의 대안이 아니라 보완 수단인 이유

현재 브랜치를 건드리고 싶지 않다면 Worktree를 써서 실험용 체크아웃을 분리하는 편이 안전합니다. 하지만 Worktree는 체크포인트를 대체하지 않습니다. Worktree 안에서도 시작 시점의 커밋이 있어야 작업 후 diff 검토가 쉬워집니다. 두 방식을 조합하면 "본 작업은 보호되고, Worktree 안에서도 진행 상황을 명확히 추적한다"는 이중 안전망이 생깁니다.

반복 작업일수록 체크포인트 습관이 전체 신뢰도를 높인다

버그 수정, 리팩터링, 문서 갱신처럼 작업이 길어질수록 "작업 전 커밋 → Codex 실행 → diff 검토 → 테스트" 순서가 안정적입니다. 이 루프가 반복될수록 각 단계의 변경 범위가 좁아지고, 실패했을 때 되돌릴 위치도 명확해집니다. 처음에는 번거로워 보이지만, 큰 작업에서 문제가 생겼을 때 체크포인트가 있고 없고의 차이는 매우 큽니다.

체크포인트와 Worktree를 고르는 기준
- 현재 브랜치에서 바로 진행해도 될 때: 체크포인트 커밋
- 기존 미커밋 작업을 건드리면 안 될 때: Worktree 분리
- 병렬 실험이 필요할 때: Worktree + 그 안에서 다시 체크포인트

언제 남길까

주의할 점

실패 예시
- 로컬에 수동 수정이 잔뜩 남은 상태에서 Codex 리팩터링을 바로 시작함
- 결과: git diff 에 기존 수동 수정과 Codex 변경이 섞여 rollback 지점도 모호해짐
- 대응: 임시 체크포인트를 찍거나 Worktree 를 분리한 뒤 Codex 작업을 시작한다