AI 수정 전 Git stash로 작업 보관하는 방법

AI에게 "이 오류 고쳐 줘"라고 맡기기 직전, 이미 수정하던 파일이 여러 개라면 먼저 멈춥니다. AI가 만든 변경과 내가 하던 변경이 섞이면 어떤 줄이 원래 작업이고 어떤 줄이 새 수정인지 구분하기 어렵습니다. 이때 필요한 것은 더 긴 프롬프트가 아니라 되돌아갈 지점을 먼저 만드는 Git 순서입니다.

git-scm.com의 git stash 문서는 stash를 작업 디렉터리와 index의 현재 상태를 저장하고, 작업 트리를 깨끗한 상태로 돌리고 싶을 때 쓰는 명령으로 설명합니다. 즉 stash는 "문제를 해결하는 명령"이 아니라 AI가 건드리기 전 현재 변경분을 잠시 옆에 빼 두는 안전장치입니다.

AI 수정 전 git status, stash, AI 수정, 검토, 복구 순서로 이어지는 작업 흐름

먼저 git status로 섞이면 안 되는 파일을 나눕니다

AI에게 맡기기 전 첫 명령은 stash가 아니라 상태 확인입니다.

git status --short

git status 공식 문서는 짧은 형식에서 각 경로 앞에 두 글자 상태 코드가 붙는다고 설명합니다. 초보자는 이 글자를 전부 외울 필요는 없습니다. 지금은 세 가지만 보면 됩니다.

보이는 상태	지금 의미	다음 행동
`M` 파일	이미 수정한 파일	내가 하던 작업인지 확인
`A` 파일	새로 추가된 파일	AI가 건드리면 안 되는 초안인지 확인
물음표 두 개가 붙은 파일	아직 Git이 추적하지 않는 파일	stash에 포함할지 따로 결정

여기서 중요한 기준은 파일 개수가 아닙니다. "내가 하던 작업"과 "AI에게 맡길 오류 수정"이 같은 파일에 들어갈 가능성입니다. 예를 들어 app/page.tsx를 내가 편집 중인데 AI에게 같은 화면 오류를 고치라고 하면 섞일 가능성이 큽니다. 이때는 먼저 보관해야 합니다. 반대로 README 오타 수정과 React 버튼 오류처럼 파일이 완전히 다르면 stash 없이 diff만 확인하고 진행할 수도 있습니다.

push 전에 .env를 빼는 Git 점검 순서를 이미 해 본 독자라면 같은 감각으로 보면 됩니다. push 전에는 비밀값을 분리하고, AI 수정 전에는 내 작업과 AI 작업을 분리합니다.

임시 보관은 메시지를 붙여 stash push로 만듭니다

상태를 봤고 지금 변경분을 잠시 빼 두기로 했다면 메시지를 붙여 저장합니다.

git stash push -m "before-ai-fix-login-button"

메시지를 붙이는 이유는 간단합니다. 나중에 stash@{0}만 보이면 무엇을 넣어 두었는지 기억하기 어렵습니다. "before-ai-fix-login-button"처럼 어떤 요청 전이었는지 남기면 복구할 때 실수가 줄어듭니다.

아직 Git이 추적하지 않는 파일까지 같이 보관해야 한다면 -u를 붙입니다.

git stash push -u -m "before-ai-fix-login-button"

이 선택은 조심해야 합니다. 물음표 두 개가 붙어 보이는 파일 중에는 새 컴포넌트 초안도 있지만, .env.local처럼 stash에 넣기보다 Git 밖에서 관리해야 할 파일도 있습니다. 민감한 파일이 보이면 먼저 비밀값 점검을 끝내고, 필요한 파일만 Git 관리 대상으로 둘지 판단합니다.

status 결과에서 수정 파일, 새 파일, 민감 파일을 나누고 stash 여부를 고르는 체크리스트

저장됐는지 확인한 뒤 AI에게 수정 범위를 줍니다

stash를 만들었다면 바로 AI에게 맡기지 말고 저장 여부를 확인합니다.

git stash list
git status --short

git stash list에서 방금 남긴 메시지가 보여야 합니다. git status --short는 비어 있거나, AI 수정과 무관한 파일만 남아 있어야 합니다. 이 상태가 되면 AI에게 줄 요청도 짧아집니다.

현재 작업은 stash에 보관해 두었습니다.

요청:
- 로그인 버튼이 클릭되지 않는 문제만 고쳐 주세요.
- 새 라이브러리를 추가하지 마세요.
- 수정 파일 목록과 이유를 먼저 요약해 주세요.
- 마지막에 실행할 확인 명령을 제안해 주세요.

이 프롬프트의 핵심은 AI를 믿지 않는 태도가 아닙니다. AI가 고칠 수 있는 범위를 좁히는 것입니다. AI가 파일을 너무 많이 고칠 때 막는 프롬프트와 같은 원리입니다. 현재 작업을 stash로 분리하고, AI에게는 지금 오류 하나만 맡깁니다.

AI 수정이 끝나면 stash를 바로 pop하지 않습니다

AI가 수정한 뒤에는 먼저 새 변경분을 봅니다.

git status --short
git diff
npm run test

테스트 명령은 프로젝트마다 다를 수 있습니다. 테스트가 없다면 npm run build, npm run lint, 화면 확인 중 하나라도 실행합니다. 여기서 AI 수정이 마음에 들지 않으면 먼저 AI가 만든 변경을 버릴지, 일부만 남길지 결정해야 합니다.

git restore path/to/file.tsx

git restore 공식 문서는 작업 트리 파일을 지정한 소스의 내용으로 복원하는 명령이라고 설명합니다. 초보자에게는 이 명령이 위험하게 느껴질 수 있습니다. 그래서 전체 폴더에 바로 쓰지 말고, git diff로 버릴 파일을 확인한 뒤 파일 단위로 쓰는 편이 안전합니다.

AI 수정이 괜찮고, 예전 작업을 다시 가져와야 한다면 pop보다 apply를 먼저 고려합니다.

git stash apply stash@{0}

apply는 stash를 적용해도 stash 목록에 항목이 남아 있습니다. 충돌이 나거나 결과가 이상하면 다시 확인할 여지가 있습니다. 모든 것이 맞는 것을 확인한 뒤에만 지웁니다.

git stash drop stash@{0}

pop은 적용과 삭제를 한 번에 진행하는 흐름이라 빠르지만, 초보자가 AI 수정과 기존 작업을 합치는 순간에는 너무 빠를 수 있습니다. 오늘 기준은 단순합니다. 처음 합칠 때는 apply, 확인 뒤 drop입니다.

복구 기준은 파일 이름보다 목적입니다

stash를 다시 적용했는데 충돌이 나면 당황하기 쉽습니다. 이때도 기준은 파일 이름이 아니라 목적입니다.

상황	먼저 남길 쪽	이유
AI가 오류를 고친 파일과 내 초안이 충돌	실행되는 최소 수정	오류 해결 확인이 우선
내 화면 문구와 AI 구조 변경이 충돌	내 문구, AI 구조 일부	사용자에게 보이는 내용은 의도 유지
새 라이브러리 추가와 기존 코드 수정이 충돌	기존 코드 수정	의존성 변경은 검증 비용이 큼

충돌 표시가 보이면 파일 전체를 새로 만들라고 하지 말고, 충돌 구간과 남길 의도를 AI에게 줍니다. 이미 Git 충돌 표시를 AI에게 설명하는 방식을 알고 있다면 같은 순서로 처리하면 됩니다.

마지막 확인은 아래 네 줄이면 충분합니다.

git status --short
git diff
npm run test
git stash list

git status --short로 남은 파일을 보고, git diff로 의도하지 않은 변경을 확인합니다. 테스트나 빌드가 통과하면 AI 수정은 검토 가능한 상태입니다. git stash list에 더 이상 필요 없는 항목이 남아 있다면 삭제할지 보관할지 정합니다.

AI 코딩에서 stash는 매번 써야 하는 의식이 아닙니다. 하지만 이미 하던 작업이 있고, AI가 같은 파일을 고칠 가능성이 있다면 먼저 현재 작업을 분리해야 합니다. 오늘 기억할 기준은 하나입니다. AI에게 수정 요청을 보내기 전, 되돌릴 수 있는 상태인지 먼저 확인합니다.

자주 묻는 질문

질문	답
git stash를 쓰면 작업 파일이 삭제되나요?	보통은 변경분을 stash에 저장하고 작업 트리를 깨끗하게 돌립니다. 중요한 작업이면 `git stash list`와 `git stash show`로 저장 여부를 확인한 뒤 다음 명령을 실행합니다.
stash와 commit 중 무엇을 먼저 써야 하나요?	공유할 만한 의미 있는 단위면 commit이 낫고, 아직 정리 전이거나 AI 수정 전 임시 보관이면 stash가 더 가볍습니다.
AI 수정이 실패하면 바로 stash pop을 해도 되나요?	먼저 현재 AI 수정 diff를 확인하고 필요하면 별도 보관하거나 버린 뒤 `apply`를 쓰는 편이 안전합니다.

참고 출처

Git Documentation, git stash: https://git-scm.com/docs/git-stash
Git Documentation, git status: https://git-scm.com/docs/git-status
Git Documentation, git restore: https://git-scm.com/docs/git-restore

AI 수정 전에 Git stash로 작업 보관하기