2026. 7. 10.
AI 수정이 원래 작업과 섞일 때, 별도 폴더에서 diff와 test로 확인하는 순서
AI가 고칠 파일이 늘어나면 진행 중 작업과 섞이기 쉽습니다. Git worktree로 별도 브랜치와 폴더를 만들고, AI 수정은 그곳에서 test와 diff로 검증하는 순서를 안내합니다.
AI에게 오류를 고치라고 했는데 수정 파일이 계속 늘어나면, 지금 하던 작업과 AI 수정이 한 폴더에서 섞이기 시작합니다. 이때는 프롬프트를 더 길게 쓰기보다 AI가 실험할 폴더를 따로 만드는 것이 먼저입니다. 별도 worktree에서 수정한 파일은 git diff로 읽고, 프로젝트의 test 명령이 통과한 뒤에만 원래 작업에 남길지 결정합니다.
Git 공식 git worktree 문서는 하나의 저장소에 여러 작업 트리를 연결해 서로 다른 브랜치를 동시에 checkout할 수 있다고 설명합니다. 즉 새 저장소를 복제하지 않아도, 현재 작업은 그대로 둔 채 AI 수정만 별도 폴더에서 시험할 수 있습니다. 현재 폴더가 진행 중 작업이라면, AI 수정은 같은 폴더에서 시작하지 않습니다.
worktree가 필요한 순간부터 먼저 가릅니다
모든 AI 수정에 worktree가 필요한 것은 아닙니다. README 오타처럼 파일 하나가 분명하고 바로 확인할 수 있는 변경은 현재 브랜치에서도 검토할 수 있습니다. 반대로 아래 중 하나라면 폴더를 나누는 편이 낫습니다.
| 지금 상황 | 같은 폴더에서 생길 문제 | worktree로 바꿀 이유 |
|---|---|---|
| 기능 작업을 이미 진행 중 | 내 변경과 AI 변경의 출처가 섞임 | 원래 작업을 그대로 둠 |
| AI가 여러 파일을 고치려 함 | 수정 범위를 통제하기 어려움 | 새 브랜치에서 diff를 읽음 |
| 오류 수정과 실험을 반복해야 함 | 되돌릴 때 현재 작업까지 흔들림 | 실험 폴더만 정리 가능 |
먼저 현재 저장소에 연결된 작업 폴더를 봅니다.
git worktree list
출력에 현재 프로젝트 폴더와 브랜치가 보이면 준비가 된 것입니다. 이 명령은 작업을 바꾸지 않고, 연결된 worktree와 각 브랜치를 보여 줍니다. 새 폴더를 만들기 전에 현재 브랜치 이름과 수정 중인 파일을 한 번 확인하면 실수가 줄어듭니다.
git status --short
git branch --show-current
현재 변경을 잠깐 치우는 것이 목적이라면 AI 수정 전에 Git stash로 작업 보관하기가 더 간단합니다. 이 글의 목적은 stash와 다릅니다. 원래 작업을 계속 열어 둔 채 AI 수정과 테스트를 별도 공간에서 이어 가는 것입니다.
새 브랜치와 실험 폴더를 한 번에 만듭니다
프로젝트 폴더 안이 아니라, 프로젝트와 나란한 위치에 실험 폴더를 두면 구분하기 쉽습니다. 아래 예시는 현재 저장소에서 ai/login-button-fix 브랜치를 만들고 ../my-app-ai-fix 폴더에 연결합니다.
git worktree add -b ai/login-button-fix ../my-app-ai-fix
-b는 새 브랜치를 만들고 그 브랜치를 새 worktree에 checkout하라는 뜻입니다. 폴더 이름과 브랜치 이름은 프로젝트에 맞게 바꾸면 됩니다. 명령이 끝난 뒤에는 새 폴더로 이동해 현재 브랜치를 확인합니다.
cd ../my-app-ai-fix
git branch --show-current
git status --short
여기서 확인할 결과는 두 가지입니다.
ai/login-button-fix처럼 방금 만든 브랜치가 보인다.git status --short에 내가 원래 폴더에서 하던 미완성 작업이 섞여 있지 않다.
AI에게는 한 가지 증상과 검증 명령만 맡깁니다
별도 폴더를 만들었다고 AI에게 전체 재작성을 맡기면 검토 비용은 그대로입니다. 오류 하나와 확인 방법 하나를 붙여 요청합니다.
이 폴더는 AI 수정 실험용 Git worktree입니다.
요청:
- 로그인 버튼이 클릭되지 않는 원인 후보를 먼저 3개 이하로 좁혀 주세요.
- 관련 파일만 수정하고 새 라이브러리는 추가하지 마세요.
- 수정 전후 파일 목록과 바꾼 이유를 적어 주세요.
- 마지막에 `npm run test` 또는 이 프로젝트에서 가능한 확인 명령을 실행해 주세요.
이렇게 요청하면 AI의 답도 원인 → 최소 수정 → 검증 결과 순서로 읽을 수 있습니다. 같은 폴더에서 여러 파일을 건드리게 두는 것보다, 새 브랜치에서 한 증상만 시험하는 편이 git diff를 읽기 쉽습니다. 수정 범위를 더 좁히는 문장 자체가 필요하면 AI가 파일을 너무 많이 고칠 때 막는 프롬프트도 함께 사용하세요.
test와 diff가 끝난 뒤에만 남기거나 정리합니다
AI가 수정을 끝냈다고 말해도 바로 원래 폴더로 돌아가 합치지 않습니다. 실험 폴더에서 먼저 이 순서를 실행합니다.
git status --short
git diff
npm run test
프로젝트에 test 스크립트가 없다면 npm run build, npm run lint, 또는 재현했던 화면 확인 중 하나를 선택합니다. 중요한 것은 특정 명령 이름이 아니라, AI가 고쳤다는 말과 실제 확인 결과를 분리하는 것입니다.
| 확인 결과 | 다음 행동 |
|---|---|
| 증상이 사라지고 diff가 의도와 맞음 | worktree 안에서 커밋한 뒤 원래 브랜치에 반영할 방법을 선택 |
| 증상은 남았지만 원인이 좁혀짐 | 같은 실험 브랜치에서 요청을 한 번 더 좁힘 |
| 수정이 엉뚱하거나 필요 없음 | 실험 폴더에서 변경을 검토하고, 남길 것이 없으면 정리 |
정리할 때는 원래 프로젝트 폴더에서 다음처럼 합니다.
git worktree remove ../my-app-ai-fix
git worktree list
Git 공식 문서에 따르면 git worktree remove는 기본적으로 수정되었거나 추적되지 않은 파일이 남은 worktree를 제거하지 않습니다. 이 보호 장치를 건너뛰는 --force는 이 글의 실험 흐름에 필요하지 않습니다. 먼저 실험 폴더를 깨끗하게 만들거나 필요한 변경을 커밋한 뒤에만 remove하세요.
오늘 남길 결과물은 폴더 하나와 확인 기록입니다
worktree의 핵심은 Git 고급 기능을 외우는 데 있지 않습니다. AI가 만지는 공간과 내가 진행하던 공간을 나누고, 무엇을 시험했는지 남기는 데 있습니다.
오늘은 아래 네 가지가 남으면 충분합니다.
[ ] git worktree list에서 원래 폴더와 실험 폴더를 확인했다.
[ ] AI 수정은 새 브랜치에서 한 증상만 대상으로 요청했다.
[ ] git diff와 test 또는 build 결과를 확인했다.
[ ] 필요한 변경만 커밋하거나, 깨끗한 실험 폴더만 remove했다.
원본 작업을 보호한 채 AI 수정의 가치를 보려면, 다음 요청부터 git worktree list로 시작해 보세요. 분리한 폴더에서 검증이 끝나기 전에는 원래 작업에 합치지 않는 것이 가장 쉬운 안전장치입니다.
자주 묻는 질문
| 질문 | 답 |
|---|---|
| git worktree는 저장소를 다시 복제하나요? | 아닙니다. 하나의 저장소에 여러 작업 트리를 연결해 다른 브랜치를 동시에 checkout할 수 있습니다. |
| AI 수정에는 stash와 worktree 중 무엇이 더 맞나요? | 현재 변경을 잠깐 비우는 목적이면 stash가 가볍고, 현재 작업을 유지한 채 별도 브랜치에서 AI 수정과 테스트를 계속할 목적이면 worktree가 더 잘 맞습니다. |
| worktree를 지우기 전에 무엇을 확인하나요? | 그 폴더에서 test와 git diff를 확인하고 필요한 커밋이 남아 있는지 봅니다. 일반 remove는 깨끗하지 않은 worktree를 기본적으로 거부합니다. |
이 글은 AI 코딩과 개발 학습의 일반 정보 제공 목적입니다. 도구, 모델, 커리큘럼, 요금은 버전과 시점에 따라 달라질 수 있으므로 실습이나 도입 전 공식 문서와 최신 릴리스 노트를 확인하세요.
참고 출처
다음으로 읽을 기사
같은 흐름으로 이어 읽기 좋은 기사만 추려 보여줍니다.
첫 번째 댓글을 남겨보세요
여러분의 생각이 다른 독자에게 도움이 됩니다.
댓글 0
이 글을 읽은 독자들의 생각을 나눠보세요.