Git과 worktree로 안전하게 앱 만들기

AI가 빠를수록 Git은 더 중요해진다

Codex를 처음 쓰면 가장 먼저 놀라는 지점이 있다. "생각보다 빨리 바꾼다"는 점이다. 버튼 하나를 추가하는 정도는 물론이고, 파일 여러 개를 열어 컴포넌트를 나누고, 테스트를 만들고, 설정 파일까지 손보는 일을 순식간에 해낸다. 문제는 바로 그 속도다. 사람이 천천히 고친 코드는 어느 파일을 왜 만졌는지 기억하기 쉽지만, AI가 2분 만에 12개 파일을 바꿔 놓으면 초보자는 금방 길을 잃는다.

이때 Git은 선택 도구가 아니라 안전벨트다. 자동차가 빨라질수록 안전벨트가 더 중요해지는 것처럼, Codex가 코드를 빠르게 바꿀수록 Git의 역할은 더 커진다. Git을 잘 쓰면 Codex에게 마음 놓고 일을 맡길 수 있다. 실패해도 되돌릴 수 있고, 마음에 드는 부분만 남길 수 있으며, 여러 시도를 동시에 진행해도 서로의 코드를 덮어쓰지 않게 만들 수 있다.

이번 장의 목표는 Git 고수가 되는 것이 아니다. Codex가 만든 변경을 안전하게 추적하고, 검토하고, 되돌리고, 병합하는 실전 습관을 만드는 것이다. 명령어를 많이 외우기보다 "언제 어떤 버튼을 눌러야 안전한가"를 몸에 익히는 데 집중하자.

Codex에게 맡기기 전, 출발선을 깨끗하게 만들기

Codex에게 작업을 맡기기 전에 가장 먼저 할 일은 현재 프로젝트가 깨끗한 상태인지 확인하는 것이다. 터미널에서 프로젝트 폴더로 이동한 뒤 다음 명령을 실행한다.

git status

여기서 가장 이상적인 문장은 다음과 같다.

nothing to commit, working tree clean

이 말은 "현재 폴더에 아직 기록하지 않은 변경이 없다"는 뜻이다. 즉, 지금부터 Codex가 바꾸는 내용은 거의 전부 Codex 작업의 결과라고 볼 수 있다. 반대로 modified, untracked, Changes not staged 같은 문장이 보인다면 이미 사람이 바꿔 놓은 파일이 섞여 있다는 뜻이다.

초보자가 가장 자주 겪는 사고는 이렇다. 어제 직접 고치던 로그인 코드를 커밋하지 않은 상태에서 Codex에게 "UI를 개선해줘"라고 시킨다. Codex가 여러 파일을 수정한다. 나중에 결과가 마음에 들지 않아 되돌리려는데, Codex 변경과 내가 어제 직접 고친 변경이 한 덩어리로 섞여 버린다. 결국 무엇을 지워야 할지 몰라 파일을 하나씩 열어 수동으로 복구하게 된다.

이 사고를 막는 가장 쉬운 방법은 작업 전 출발점을 커밋으로 남기는 것이다.

git status
git add .
git commit -m "chore: save current working state"

물론 아무 변경도 없다면 커밋할 필요가 없다. 하지만 이미 내가 수정한 내용이 있다면, Codex에게 맡기기 전에 먼저 저장해 두는 것이 좋다. 커밋은 단순한 기록이 아니라 "여기로 돌아올 수 있는 체크포인트"다.

특히 의존성 설치나 자동 포맷팅처럼 변경 범위가 커질 수 있는 작업은 반드시 별도 커밋으로 분리하자. 예를 들어 npm install을 실행하면 package-lock.json이나 pnpm-lock.yaml이 크게 바뀔 수 있다. prettier를 전체 적용하면 수십 개 파일의 줄바꿈이 한꺼번에 바뀔 수도 있다. 이런 변경이 기능 구현과 섞이면 리뷰가 어려워진다.

좋은 흐름은 다음과 같다.

npm install axios
git status
git add package.json package-lock.json
git commit -m "chore: add axios dependency"

npm run format
git add .
git commit -m "style: format existing files"

그다음 Codex에게 실제 기능 작업을 맡긴다. 이렇게 해두면 나중에 diff를 볼 때 "의존성 추가", "기존 포맷 정리", "Codex가 구현한 기능"이 분리되어 보인다. 초보자에게 이 차이는 매우 크다. 변경 이유가 분리되면 검토가 쉬워지고, 검토가 쉬우면 실수도 줄어든다.

Codex 변경은 바로 커밋하지 않는다

Codex가 작업을 마치면 마음이 급해진다. 화면도 그럴듯하고, 테스트도 통과했다고 하니 바로 커밋하고 싶어진다. 하지만 여기서 한 번 멈춰야 한다. Codex가 만든 변경은 "완성품"이 아니라 "검토해야 할 제안"이다.

Codex App에서는 diff pane을 통해 현재 로컬 프로젝트나 worktree의 Git diff를 확인할 수 있고, 파일 전체 또는 특정 chunk 단위로 stage하거나 revert할 수 있다.¹ IDE 확장에서도 비슷하게 변경 전후를 비교하는 화면이 제공된다. CLI를 쓰고 있다면 가장 기본은 다음 명령이다.

git diff

파일 목록부터 보고 싶다면 이렇게 확인한다.

git status

특정 파일만 자세히 보고 싶다면 파일 경로를 붙인다.

git diff src/components/TodoList.tsx

여기서 핵심은 "파일별로", 가능하면 "chunk별로" 보는 것이다. chunk는 diff에서 하나의 변경 묶음을 뜻한다. 예를 들어 같은 파일 안에서도 첫 번째 chunk는 버튼 문구 변경이고, 두 번째 chunk는 상태 관리 로직 변경일 수 있다. 두 변경이 모두 마음에 들 필요는 없다. 버튼 문구만 받고 로직 변경은 버릴 수도 있다.

터미널에서는 다음 명령으로 변경을 조각 단위로 stage할 수 있다.

git add -p

처음 보면 화면이 낯설 수 있다. Git이 "이 변경 조각을 stage할까요?"라고 물어보면 y는 yes, n은 no다. 일단 초보자는 모든 단축키를 외우려 하지 말고 y, n, q 정도만 기억해도 충분하다. q는 중단이다.

예를 들어 Codex에게 다음처럼 요청했다고 해보자.

할 일 목록 화면에서 완료된 항목은 흐리게 보이도록 수정해줘.
단, 데이터 구조와 API 호출 코드는 건드리지 마.

작업이 끝난 뒤 git diff를 봤더니 다음 세 파일이 바뀌었다.

modified: src/components/TodoItem.tsx
modified: src/styles/todo.css
modified: src/api/todos.ts

이때 src/api/todos.ts가 바뀐 것은 수상하다. 프롬프트에서 API 호출 코드는 건드리지 말라고 했기 때문이다. 이 파일의 diff를 확인하고, 불필요한 변경이라면 stage하지 않는다. 필요한 두 파일만 커밋한다.

git add src/components/TodoItem.tsx src/styles/todo.css
git commit -m "feat: dim completed todo items"

커밋 메시지는 길고 화려할 필요가 없다. 대신 "무엇을 왜 바꿨는지"가 보여야 한다. fix, feat, refactor, test, docs, chore 같은 접두사를 쓰면 나중에 히스토리를 읽기 쉽다.

좋은 커밋 메시지 예시는 다음과 같다.

git commit -m "fix: prevent empty todo submission"
git commit -m "test: add todo filter behavior tests"
git commit -m "refactor: split todo form into separate component"

반대로 다음 메시지는 나중에 도움이 되지 않는다.

git commit -m "update"
git commit -m "codex changes"
git commit -m "fix stuff"

Codex를 많이 쓸수록 커밋 메시지는 더 중요해진다. 나중에 문제가 생겼을 때 "어느 AI 작업이 문제였는지"를 찾는 단서가 되기 때문이다.

잘못된 AI 변경을 되돌리는 세 가지 상황

Codex가 만든 변경이 마음에 들지 않을 때 초보자는 파일을 열고 직접 삭제하려는 경우가 많다. 물론 작은 문구 하나라면 그래도 된다. 하지만 여러 파일이 얽힌 변경이라면 수동 삭제는 위험하다. 빠뜨리는 파일이 생기고, 포맷이 어긋나고, 더 큰 오류를 만들 수 있다.

되돌리기는 상황별로 다르게 해야 한다. 아직 커밋하지 않은 변경을 취소하는 것과, 이미 커밋한 변경을 취소하는 것은 완전히 다른 문제다. git reset은 과거 시점으로 브랜치 상태를 이동시키는 방식이고, git revert는 기존 커밋을 취소하는 새 커밋을 만드는 방식이다. 협업 브랜치처럼 이미 공유된 기록을 되돌릴 때는 보통 히스토리를 지우지 않는 revert가 더 안전하다.²

아직 커밋하지 않은 파일 변경 취소하기

Codex가 파일을 고쳤지만 아직 커밋하지 않았다면 git restore를 쓴다.

git restore src/api/todos.ts

이 명령은 해당 파일을 마지막 커밋 상태로 되돌린다. 즉, Codex가 그 파일에 만든 변경이 사라진다. 여러 파일을 한꺼번에 되돌릴 수도 있다.

git restore src/api/todos.ts src/utils/date.ts

전체 변경을 전부 버리고 싶다면 다음 명령도 가능하다.

git restore .

하지만 이 명령은 현재 폴더의 추적 중인 파일 변경을 모두 버린다. 내가 직접 고친 내용이 섞여 있다면 함께 사라질 수 있다. 그래서 앞에서 말한 clean state가 중요하다. 출발선이 깨끗했다면 git restore .는 "이번 Codex 작업 전체 취소"라는 의미가 된다.

이미 stage한 파일을 다시 stage 해제하고 싶다면 다음 명령을 쓴다.

git restore --staged src/api/todos.ts

이 명령은 파일 내용을 되돌리는 것이 아니라 "커밋 후보에서 빼는 것"이다. 파일의 변경은 그대로 남아 있다. 초보자는 이 차이를 꼭 기억하자.

파일의 일부 변경만 되돌리기

한 파일 안에 마음에 드는 변경과 마음에 들지 않는 변경이 섞여 있을 수 있다. 예를 들어 Codex가 TodoItem.tsx에서 접근성 개선은 잘했지만, 스타일 클래스 이름은 마음에 들지 않게 바꿨다고 해보자. 이럴 때 파일 전체를 되돌리면 좋은 변경까지 사라진다.

터미널에서는 다음처럼 patch 모드로 되돌릴 수 있다.

git restore -p src/components/TodoItem.tsx

Git이 변경 조각을 하나씩 보여주고 "이 조각을 되돌릴까요?"라고 묻는다. Codex App의 diff pane에서도 특정 chunk만 revert할 수 있으므로, 초보자라면 시각적인 화면에서 먼저 연습하는 편이 쉽다.¹

이 방식은 매우 유용하다. Codex에게 큰 작업을 맡긴 뒤에도 사람이 원하는 부분만 고를 수 있기 때문이다. AI에게 코드를 맡긴다는 것은 모든 결과를 통째로 받아들인다는 뜻이 아니다. 좋은 부분을 선택하고, 애매한 부분은 버리고, 필요한 부분은 다시 요청하는 과정이다.

이미 커밋한 변경 취소하기

이미 커밋했지만 아직 원격 저장소에 push하지 않았고 혼자 작업하는 브랜치라면 git reset을 사용할 수 있다. 예를 들어 방금 만든 커밋을 취소하되 변경 내용은 작업 폴더에 남기고 싶다면 다음처럼 한다.

git reset --mixed HEAD~1

커밋은 사라지지만 파일 변경은 남아 있다. 다시 검토해서 일부만 커밋할 수 있다. 변경 내용까지 완전히 버리고 싶다면 --hard를 쓸 수 있지만, 초보자는 매우 조심해야 한다.

git reset --hard HEAD~1

이 명령은 마지막 커밋과 그 변경 내용을 모두 되돌린다. 복구가 어려울 수 있으므로, 확신이 없다면 먼저 브랜치를 하나 만들어 백업해 두자.

git branch backup-before-reset

반면 이미 main 브랜치에 merge했거나, 팀원과 공유한 커밋을 취소해야 한다면 git revert를 우선 생각한다.

git revert <commit-hash>

revert는 기존 커밋을 지우지 않는다. 대신 "그 커밋의 변경을 취소하는 새 커밋"을 만든다. 그래서 협업 중인 브랜치에서 더 안전하다. main에 들어간 Codex 변경이 배포 후 문제를 일으켰다면, 당황해서 reset으로 역사를 지우기보다 revert 커밋을 만들어 되돌리는 것이 보통 더 낫다.

worktree는 AI 작업용 별도 작업실이다

이제 본격적으로 worktree를 보자. 이름은 어렵지만 개념은 단순하다. Git worktree는 같은 저장소에서 여러 작업 디렉터리를 만들어 쓰는 기능이다. 하나의 프로젝트에 작업실을 여러 개 만드는 것과 비슷하다.

예를 들어 내 기본 프로젝트 폴더가 my-todo-app이라고 하자. 여기에 UI 개선 작업을 위한 별도 폴더를 만들 수 있다.

git worktree add ../todo-ui-redesign -b codex/ui-redesign main

그러면 폴더 구조는 대략 이렇게 된다.

projects/
  my-todo-app/          # 내가 평소 쓰는 기본 작업 폴더
  todo-ui-redesign/     # Codex에게 UI 개선을 맡길 별도 작업 폴더

두 폴더는 같은 Git 저장소의 히스토리를 공유하지만, 실제 파일 작업 공간은 분리되어 있다. todo-ui-redesign에서 Codex가 src/App.tsx를 고쳐도 my-todo-app 폴더의 src/App.tsx는 그대로다. 이 차이가 중요하다.

Codex App은 worktree를 중요한 병렬 작업 방식으로 다룬다. 공식 문서에서도 Codex가 thread를 local checkout과 worktree 사이에서 안전하게 이동하는 Git 절차를 처리하며, 각 thread가 시간이 지나도 같은 worktree와 연결된다고 설명한다.³ 즉, Codex App에서 worktree를 선택하면 "이 작업은 내 현재 폴더를 직접 건드리지 말고 별도 작업실에서 해줘"라고 말하는 것과 같다.

worktree 목록은 다음 명령으로 볼 수 있다.

git worktree list

작업이 끝난 worktree는 제거할 수 있다.

git worktree remove ../todo-ui-redesign

단, 커밋하지 않은 변경이 남아 있으면 Git이 삭제를 막을 수 있다. 이는 실수를 막기 위한 보호 장치다. 정말 버려도 되는 변경이라면 --force를 사용할 수 있지만, 초보자는 먼저 git status로 내용을 확인한 뒤 결정하자.

cd ../todo-ui-redesign
git status

언제 Local을 쓰고, 언제 worktree를 쓸까

Codex App이나 CLI, IDE에서 작업할 때 항상 worktree가 필요한 것은 아니다. 오타 수정, 주석 추가, 작은 문구 변경처럼 범위가 아주 작고 내가 바로 확인할 수 있는 작업은 Local에서 해도 괜찮다. 하지만 다음 상황에서는 worktree를 기본값처럼 생각하는 것이 좋다.

• Codex가 여러 파일을 수정할 가능성이 있는 작업

• 내가 로컬에서 다른 개발을 계속해야 하는 동안 AI에게 병렬 작업을 맡기는 경우

• UI 개선, 버그 수정, 테스트 보강처럼 서로 다른 시도를 동시에 비교하고 싶은 경우

• 실패해도 부담 없는 실험을 해보고 싶은 경우

예를 들어 할 일 관리 앱을 만들고 있다고 하자. 지금 main 폴더에서는 내가 로그인 버그를 직접 확인하고 있다. 그런데 동시에 Codex에게 "모바일 화면에서 카드 레이아웃을 개선해줘"라고 맡기고 싶다. Local에서 실행하면 내 작업과 Codex 작업이 섞일 수 있다. 이때 worktree를 만든다.

git worktree add ../todo-mobile-ui -b codex/mobile-ui main
cd ../todo-mobile-ui

그리고 이 폴더에서 Codex CLI를 실행하거나, Codex App에서 해당 worktree thread를 사용한다.

모바일 화면에서 할 일 카드가 너무 좁아 보입니다.
범위: src/components/TodoCard.tsx, src/styles/todo.css만 수정하세요.
완료 기준: npm test 통과, 390px 폭에서 카드 여백이 자연스럽게 보이도록 개선하세요.

이렇게 하면 내 기본 폴더에서는 로그인 버그를 계속 볼 수 있고, Codex는 별도 폴더에서 UI 개선을 진행한다. 두 작업이 같은 파일을 건드리지 않는다면 나중에 각각 검토해 병합하면 된다.

병렬 Codex 작업을 안전하게 나누는 법

worktree가 있다고 해서 모든 충돌이 사라지는 것은 아니다. worktree는 작업 중 파일을 서로 덮어쓰지 않게 해주지만, 나중에 합칠 때 같은 줄을 바꿨다면 충돌이 생길 수 있다. 따라서 병렬 작업은 처음부터 잘 나누어야 한다.

가장 쉬운 기준은 "파일 범위"다. Codex에게 작업을 맡길 때 수정해도 되는 파일과 수정하면 안 되는 파일을 명확히 적는다.

작업: 할 일 필터 버튼 UI를 개선하세요.
수정 가능: src/components/TodoFilter.tsx, src/styles/filter.css
수정 금지: src/api/*, src/store/*, package.json
완료 기준: npm test 통과, 기존 필터 동작 유지

동시에 다른 worktree에서는 테스트 보강을 맡길 수 있다.

작업: 할 일 추가/완료/삭제 흐름의 테스트를 보강하세요.
수정 가능: src/__tests__/*, src/test-utils/*
수정 금지: src/components/*의 구현 코드
완료 기준: npm test 통과, 실패하는 테스트를 억지로 수정하지 말고 원인을 설명

또 다른 worktree에서는 문서 정리를 맡긴다.

작업: README의 실행 방법과 환경 변수 설명을 초보자도 따라 할 수 있게 정리하세요.
수정 가능: README.md, docs/*
수정 금지: src/*
완료 기준: npm install부터 npm run dev까지 순서대로 설명

이 세 작업은 서로 다른 파일을 주로 다루므로 병렬로 진행하기 좋다. 반대로 다음 조합은 위험하다.

Agent A: TodoList 컴포넌트 구조를 리팩터링
Agent B: TodoList 컴포넌트에 드래그 앤 드롭 추가
Agent C: TodoList 컴포넌트 스타일 전체 정리

세 작업이 모두 같은 컴포넌트를 건드릴 가능성이 높다. worktree를 써도 병합 시 충돌이 날 확률이 크다. 이런 경우에는 순서를 정해야 한다. 먼저 구조 리팩터링을 끝내고 main에 병합한 뒤, 그 최신 상태에서 드래그 앤 드롭을 시작하는 식이다.

worktree마다 실행 명령과 테스트 결과를 분리하기

worktree는 파일만 분리하는 것이 아니다. 각 worktree에서 개발 서버, 테스트, 빌드 명령을 따로 실행할 수 있다. 다만 주의할 점이 있다. 새 worktree에는 Git이 추적하는 파일만 체크아웃된다. node_modules, .env, 빌드 산출물처럼 .gitignore에 들어간 파일은 자동으로 따라오지 않는다. Codex 관련 worktree 자료에서도 의존성 설치나 환경 준비를 위해 setup script를 두는 방식을 권장한다.⁴

새 worktree에서 다음 명령을 실행했는데 오류가 날 수 있다.

npm test

오류 메시지가 node_modules가 없다는 내용이라면 당황할 필요 없다. 의존성을 설치하면 된다.

npm install
npm test

팀 프로젝트라면 worktree를 만들 때마다 반복할 명령을 문서화해 두는 것이 좋다. 예를 들어 다음 내용을 AGENTS.md나 프로젝트 문서에 적어둔다.

## Worktree setup

새 worktree를 만든 뒤 다음 명령을 실행한다.

```bash
npm install
cp ../my-todo-app/.env.local .env.local
npm test

Codex에게도 이 규칙을 알려준다.

```text
새 worktree에서 작업할 때는 먼저 npm install을 실행하고,
테스트 전에는 npm test를 사용하세요.
.env.local은 직접 수정하지 말고 필요한 값이 없으면 사용자에게 요청하세요.

각 worktree의 테스트 결과도 섞지 말고 따로 확인해야 한다. UI 개선 worktree에서 npm test가 통과했다고 해서 테스트 보강 worktree의 코드가 안전하다는 뜻은 아니다. 각 작업실은 독립된 상태이므로, 병합 전에는 해당 worktree에서 직접 테스트를 실행해야 한다.

실전에서는 다음처럼 기록해 두면 좋다.

codex/mobile-ui
- 변경: TodoCard 모바일 스타일 개선
- 확인: npm test 통과
- 추가 확인: 390px 화면에서 카드 여백 확인 필요

codex/todo-tests
- 변경: TodoList 테스트 5개 추가
- 확인: npm test 통과
- 주의: 테스트 유틸의 mock 데이터 이름 변경됨

Codex App의 thread 메모나 PR 설명에 이런 내용을 남기면 나중에 병합할 때 훨씬 편하다.

worktree 결과를 main에 합치는 기본 흐름

이제 worktree에서 만든 변경을 main에 합쳐보자. 가장 단순한 흐름은 브랜치를 만들고, 커밋하고, main에서 merge하는 것이다.

먼저 worktree 폴더에서 변경을 검토한다.

cd ../todo-mobile-ui
git status
git diff
npm test

마음에 드는 변경만 stage하고 커밋한다.

git add src/components/TodoCard.tsx src/styles/todo.css
git commit -m "feat: improve mobile todo card layout"

이제 기본 프로젝트 폴더로 돌아간다.

cd ../my-todo-app
git status

main이 깨끗한지 확인한 뒤 최신 상태로 맞춘다.

git switch main
git pull

그다음 worktree 브랜치를 병합한다.

git merge codex/mobile-ui
npm test

테스트가 통과하면 push한다.

git push

팀 프로젝트라면 main에 직접 merge하기보다 GitHub PR을 만드는 편이 좋다.

git push -u origin codex/mobile-ui

그리고 PR에서 diff와 테스트 결과를 다시 확인한다. Codex가 만든 코드라 해도 main에 들어가는 순간부터는 팀의 코드다. 마지막 승인자는 사람이어야 한다.

Codex App에서는 worktree에서 계속 작업할지, local checkout으로 동기화할지 선택하는 흐름이 제공된다. worktree 안에서 검증이 가능하면 그곳에서 브랜치를 만들고 커밋한 뒤 PR로 보내면 된다. 반대로 내 로컬 환경에서만 실행 가능한 서버나 인증 설정이 있다면 local로 가져와 검토할 수 있다. 중요한 것은 어느 쪽이든 "검토 없이 main에 넣지 않는다"는 원칙이다.

충돌이 났을 때 Codex에게 시킬 일과 사람이 해야 할 일

병합 중 충돌이 나면 초보자는 겁이 난다. 화면에는 낯선 표시가 나온다.

<<<<<<< HEAD
현재 main 브랜치의 코드
=======
병합하려는 브랜치의 코드
>>>>>>> codex/mobile-ui

이 표시는 Git이 "두 쪽이 같은 부분을 다르게 바꿨는데, 어느 쪽이 맞는지 모르겠다"고 말하는 것이다. 여기서 Codex에게 "그냥 해결해줘"라고만 맡기면 위험하다. Codex는 문법적으로 그럴듯한 중간 결과를 만들 수 있지만, 양쪽 변경의 의도까지 정확히 이해하지 못할 수 있다.

충돌이 나면 먼저 사람이 세 가지를 확인해야 한다.

• main 쪽 변경은 어떤 문제를 해결하려고 들어왔는가

• Codex 브랜치 쪽 변경은 어떤 기능을 위해 필요한가

• 둘 중 삭제되면 안 되는 코드나 테스트가 있는가

그다음 Codex에게는 해결 자체보다 검토 보조를 맡기는 것이 좋다.

이 파일의 Git 충돌 영역을 설명해줘.
HEAD 쪽 변경의 목적과 codex/mobile-ui 쪽 변경의 목적을 나눠서 정리하고,
둘 다 살리는 해결안 2가지를 제안해줘.
아직 파일은 수정하지 마.

이 프롬프트의 핵심은 "아직 파일은 수정하지 마"다. 먼저 설명을 듣고, 사람이 방향을 정한다. 방향이 정해진 뒤에야 Codex에게 수정하게 한다.

1번 해결안으로 충돌을 정리해줘.
단, 기존 접근성 속성 aria-pressed는 유지하고,
모바일 스타일 클래스는 codex/mobile-ui 브랜치의 것을 사용해.
수정 후 관련 테스트를 실행해줘.

충돌 해결 후에는 반드시 상태를 확인한다.

git status
npm test

수습이 너무 어려우면 병합을 중단할 수도 있다.

git merge --abort

이 명령은 진행 중인 merge를 취소하고 병합 전 상태로 돌아가려는 명령이다. 충돌 해결이 꼬였을 때는 억지로 이어가기보다 중단하고, 작업 범위를 다시 나누는 편이 안전하다.

실전 예제: 세 명의 Codex에게 각자 다른 일을 맡기기

이제 하나의 작은 앱에서 병렬 작업을 해보자. 앱은 my-todo-app이고, main 브랜치는 깨끗한 상태라고 가정한다.

cd my-todo-app
git status

결과가 깨끗하다면 세 개의 worktree를 만든다.

git worktree add ../todo-ui -b codex/ui-polish main
git worktree add ../todo-bugfix -b codex/empty-submit-fix main
git worktree add ../todo-tests -b codex/todo-tests main

첫 번째 worktree에서는 UI 개선을 맡긴다.

cd ../todo-ui

Codex에게 이렇게 요청한다.

할 일 목록의 시각적 완성도를 높여줘.
범위: src/components/TodoList.tsx, src/components/TodoItem.tsx, src/styles/todo.css
제약: 데이터 구조, API 호출, 테스트 파일은 수정하지 마.
완료 기준: npm test 통과, 완료된 항목은 흐리게 표시, hover 상태가 자연스럽게 보이도록 개선.

두 번째 worktree에서는 버그 수정을 맡긴다.

cd ../todo-bugfix

빈 문자열이나 공백만 있는 할 일이 추가되지 않도록 수정해줘.
범위: src/components/TodoForm.tsx
제약: 스타일 파일은 수정하지 마.
완료 기준: 입력값 trim 처리, 빈 값 제출 시 목록이 변경되지 않음, npm test 통과.

세 번째 worktree에서는 테스트 보강을 맡긴다.

cd ../todo-tests

TodoForm과 TodoList의 기본 동작 테스트를 추가해줘.
범위: src/__tests__/*, src/test-utils/*
제약: 구현 코드는 수정하지 마. 테스트가 실패하면 원인만 설명하고 구현 코드는 건드리지 마.
완료 기준: npm test 통과, 할 일 추가/완료/삭제 테스트 포함.

각 작업이 끝나면 해당 worktree에서 다음 순서로 확인한다.

git status
git diff
npm test

마음에 드는 변경만 커밋한다.

git add .
git commit -m "feat: polish todo list UI"

세 worktree를 모두 검토했다면 main에서 하나씩 병합한다.

cd ../my-todo-app
git switch main
git pull

git merge codex/empty-submit-fix
npm test

git merge codex/todo-tests
npm test

git merge codex/ui-polish
npm test

순서도 중요하다. 보통 버그 수정처럼 작고 명확한 변경을 먼저 병합하고, 테스트 보강을 그다음, UI처럼 충돌 가능성이 있는 변경을 나중에 병합하면 검토하기 쉽다. 만약 테스트 보강 브랜치가 구현 코드 변경을 전제로 한다면 순서를 바꿔야 한다. 중요한 것은 "완료된 순서대로 무조건 합치기"가 아니라 "위험이 낮고 의존성이 적은 것부터 합치기"다.

모든 병합이 끝나고 테스트가 통과하면 임시 worktree를 정리한다.

git worktree remove ../todo-ui
git worktree remove ../todo-bugfix
git worktree remove ../todo-tests

브랜치까지 정리하려면 병합 여부를 확인한 뒤 삭제한다.

git branch -d codex/ui-polish
git branch -d codex/empty-submit-fix
git branch -d codex/todo-tests

초보자가 꼭 기억해야 할 Git 안전 습관

Codex와 함께 개발할 때 Git을 어렵게 느끼지 않으려면 몇 가지 습관만 지키면 된다. 첫째, 작업 전 git status를 확인한다. 둘째, 큰 변경 전에는 커밋으로 출발점을 만든다. 셋째, Codex 결과는 바로 커밋하지 않고 diff로 검토한다. 넷째, 마음에 드는 부분만 stage한다. 다섯째, 여러 AI 작업은 worktree로 분리한다.

이 다섯 가지가 익숙해지면 Codex를 훨씬 과감하게 쓸 수 있다. "망치면 어떡하지?"라는 걱정이 줄어들기 때문이다. 사실 AI 개발에서 중요한 능력은 AI가 한 번에 완벽한 코드를 만들게 하는 능력이 아니다. AI가 빠르게 만든 결과를 안전하게 검토하고, 좋은 부분만 남기고, 나쁜 부분은 되돌리는 능력이다.

마지막으로, Codex에게 일을 맡기기 전 아래 체크리스트를 습관처럼 확인하자.

• git status가 깨끗한가

• 의존성 설치, 포맷팅, 대량 파일 변경이 별도 커밋으로 분리되어 있는가

• Codex가 수정해도 되는 파일 범위를 프롬프트에 적었는가

• 작업이 여러 파일 또는 장시간 작업이라면 worktree를 사용할 것인가

• 병합 전 사람이 diff와 테스트 결과를 확인할 계획이 있는가

이 체크리스트는 느려 보이지만 실제로는 시간을 아껴준다. 되돌릴 수 없는 것처럼 보이는 엉킨 변경을 밤새 수습하는 것보다, 시작 전에 1분 동안 안전벨트를 매는 편이 훨씬 빠르다.

다음 장에서는 이 안전한 작업 흐름을 한 단계 더 발전시켜, 프로젝트의 규칙과 기억을 AGENTS.md에 담는 방법을 다룬다. Git이 코드 변경의 안전벨트라면, AGENTS.md는 Codex가 프로젝트 안에서 길을 잃지 않게 해주는 지도다.

참고

¹Features - Codex app | OpenAI Developers

²[Git] reset과 revert 알고 사용하기

³Worktrees - Codex app | OpenAI Developers

⁴Git Worktree Parallel Development | Developer Toolkit