AI에게 작은 수정을 하나 맡겼는데 생각보다 여러 파일이 바뀌는 경우가 있습니다. 이어서 다른 작업까지 부탁하면 첫 번째 변경과 두 번째 변경이 같은 폴더 안에 놓입니다.
결과가 마음에 들지 않을 때 문제가 생깁니다. 무엇이 방금 바뀐 것인지, 어느 작업의 변경인지, 어디까지 되돌려야 하는지 사람이 판단해야 합니다.
Git과 워크트리는 이때 필요합니다. 개발자처럼 모든 명령어를 외우기 위해서가 아닙니다. AI가 바꾼 내용을 확인하고, 돌아갈 지점을 남기고, 서로 다른 작업을 섞지 않기 위해서입니다.
왜 필요한가 — AI가 빨라질수록 사람이 확인할 자리가 필요합니다
AI가 파일을 고치는 동안 사용자는 매 줄을 지켜보지 않습니다. 그래서 작업이 끝난 뒤 다음 세 가지를 확인할 방법이 필요합니다.
- 어떤 파일이 바뀌었는가
- 실제로 무엇이 달라졌는가
- 문제가 생기면 어느 기록을 기준으로 비교할 것인가
Git은 바뀐 파일 목록과 실제 줄 변경을 확인할 수 있게 해 줍니다. 확인이 끝난 변경은 커밋으로 기록할 수 있습니다. 이 기록이 있으면 나중에 현재 상태와 비교할 기준이 생깁니다.
여기에 작업이 하나 더 생기면 워크트리가 필요해질 수 있습니다. 기존 작업을 그대로 둔 채 별도의 폴더에서 다른 작업을 진행하게 해 주기 때문입니다.
Git은 작업 기록과 돌아갈 기준을 맡고, 워크트리(Worktree)는 작업이 섞이지 않도록 공간을 나눕니다.
어떤 역할을 하는가 — 네 단어만 구분하면 됩니다
| 이름 | 쉬운 뜻 | 언제 필요한가 |
|---|---|---|
| Git | 변경을 확인하고 기록하는 전체 체계 | AI에게 파일 작업을 맡길 때 |
| 커밋(Commit) | 확인한 변경을 남긴 체크포인트 | 한 작업을 남길 상태로 정리했을 때 |
| 브랜치(Branch) | 작업 기록을 갈래별로 나누는 이름표 | 기존 기록과 새 작업을 구분할 때 |
| 워크트리(Worktree) | 다른 브랜치의 파일을 펼쳐두는 별도 폴더 | 두 작업을 동시에 열어둘 때 |
Git이 자동으로 모든 수정 내용을 안전한 기록으로 남기는 것은 아닙니다. 사람이 남길 변경을 고른 뒤 커밋해야 돌아가거나 비교할 기준이 생깁니다. Git 공식 설명도 수정한 내용을 선택한 뒤 커밋하는 순서로 설명합니다.
워크트리는 프로젝트를 통째로 복사해 별개의 프로젝트를 만드는 기능이 아닙니다. 하나의 Git 저장소에 별도 작업 폴더를 연결합니다. 작업 기록은 함께 쓰지만, 각 폴더에는 서로 다른 브랜치의 파일을 열어둘 수 있습니다.
한 프로젝트에서 한 작업만 하고 있다면 워크트리부터 만들 필요는 없습니다. 먼저 Git으로 변경을 확인하고 커밋을 남기는 흐름이면 충분합니다. 두 번째 작업을 동시에 열고 싶을 때 워크트리를 추가하면 됩니다.
사용자가 꼭 알아야 할 것과 활용법 — AI에게 세 가지를 요청하세요
비개발자가 먼저 익힐 것은 Git 명령어가 아니라 작업의 확인 순서입니다. AI에게 다음 세 가지를 요청하면 됩니다.
1. 시작하기 전에 현재 상태를 확인합니다
작업을 시작하기 전에 현재 브랜치와 이미 변경되어 있는 파일 목록을 확인해서 알려줘. 기존 변경은 덮어쓰지 마.
이 요청은 새 작업을 시작하기 전에 이전 작업이 남아 있는지 확인하는 단계입니다. Git의 status 명령은 현재 브랜치와 변경된 파일을 보여 줍니다.
2. 다른 작업과 섞이면 안 되면 공간을 나눕니다
이번 작업은 기존 작업과 섞이면 안 돼. 별도 브랜치와 워크트리에서 진행하고, 어느 폴더에서 작업하는지 알려줘.
한 에이전트가 긴 작업을 하는 동안 다른 작업을 시작하거나, 두 에이전트에게 서로 다른 일을 맡길 때 유용합니다. 다만 같은 파일을 두 에이전트가 동시에 고치게 해서는 안 됩니다. 작업 폴더가 달라도 나중에 같은 부분을 합칠 때 충돌할 수 있습니다.
3. 끝난 뒤에는 바뀐 범위를 확인합니다
작업이 끝나면 바뀐 파일 목록과 중요한 변경을 요약해줘. 내가 확인하기 전에는 다른 브랜치에 합치거나 배포하지 마.
Git의 diff 명령은 파일 안에서 실제로 바뀐 줄을 보여 줍니다. 사용자는 AI가 만든 모든 세부 코드를 이해하지 못하더라도, 요청한 파일만 바뀌었는지와 어떤 기능이 달라졌는지는 확인할 수 있습니다.
이 세 단계의 순서는 단순합니다.
작업 전 상태 확인 → 필요하면 공간 분리 → 작업 후 변경 확인
그 외 알아두면 좋은 것
브랜치와 워크트리는 같은 것이 아닙니다
브랜치는 작업 기록을 구분하는 이름표이고, 워크트리는 그 기록의 파일을 실제로 펼쳐둔 폴더입니다.
보통 한 프로젝트 폴더에서 브랜치를 바꾸면 폴더 안의 파일도 함께 바뀝니다. 커밋하지 않은 변경과 새 브랜치의 파일이 부딪히면 Git이 전환을 막을 수 있습니다. 워크트리를 쓰면 원래 폴더를 그대로 둔 채 다른 브랜치의 파일을 별도 폴더에 열 수 있습니다.
워크트리는 충돌을 없애거나 백업을 대신하지 않습니다
서로 다른 워크트리에서 같은 파일의 같은 부분을 다르게 고치면, 나중에 두 작업을 합칠 때 충돌이 생길 수 있습니다. Git의 병합 설명에서도 이 경우에는 자동으로 합치지 않고 사람이 확인하도록 멈춥니다.
워크트리 폴더가 여러 개여도 모두 같은 Git 저장소에 연결되어 있습니다. 폴더 수가 안전을 만드는 것은 아닙니다. 변경을 확인하고 커밋으로 기록을 남기는 것이 먼저입니다.
이 프로젝트에서도 독립된 큰 작업은 별도 브랜치와 워크트리로 나눕니다. 사이트 포맷을 정리했을 때는 변경 전 버전을 임시 워크트리에서 따로 빌드해 현재 결과와 비교했습니다. 기존 작업을 건드리지 않고 비교할 기준을 옆에 펼쳐둘 수 있다는 점이 실제로 유용했습니다.
직접 확인하고 싶을 때 쓰는 명령어
AI가 알려 준 내용을 터미널에서 직접 확인하고 싶다면 다음 세 명령부터 보면 됩니다.
git status --short --branch # 현재 브랜치와 변경 파일
git diff # 파일 안에서 바뀐 내용
git worktree list # 현재 연결된 작업 폴더새 브랜치와 워크트리를 직접 만들 때는 다음처럼 실행합니다. 폴더와 브랜치 이름은 예시입니다.
git worktree add -b content/git-worktree ../project-git-worktree main작업을 끝낸 뒤에는 변경이 남아 있지 않은지 먼저 확인하고 정리합니다.
git status --short --branch
git worktree remove ../project-git-worktreeGit은 수정되거나 새로 생긴 파일이 남은 워크트리를 --force 없이 제거하지 않습니다. 삭제가 막히면 강제로 지우기보다 git status로 남은 작업부터 확인하는 편이 안전합니다.
터미널 안에서 AI 에이전트의 조작이 왜 다르게 느껴지는지도 궁금하다면 Claude Code·Codex 단축키가 헷갈리는 진짜 이유에서 이어서 볼 수 있습니다.
확인 기준과 출처
이 글은 Windows의 Git 2.55.0.windows.3에서 예시 명령을 확인했고, 핵심 동작은 2026년 8월 19일 Git 공식 문서와 이 프로젝트의 작업 기록을 대조했습니다.