바이브 코딩 중 AI가 짜준 코드가 갑자기 깨졌을 때, git diff·checkout·reset --hard·stash로 몇 초 만에 되돌리는 실전 트러블슈팅 시나리오를 단계별로 안내합니다.
어제까지 멀쩡했던 화면이, AI가 코드 한 줄 고친 뒤 통째로 하얗게 변했다
"버튼 색깔만 바꿔줘"라고 AI에게 부탁했을 뿐인데, 새로고침을 누르니 화면이 새하얗게 변하고 콘솔에는 빨간 에러 메시지만 가득합니다. 무슨 일이 일어난 건지도 모르겠고, 방금 전까지 잘 작동하던 로그인 기능이 어떻게 됐는지도 알 수 없습니다. 되돌리고 싶은데, 뭘 어떻게 되돌려야 할지조차 감이 안 옵니다.
바이브 코딩으로 사이드 프로젝트나 사내 도구를 만들어본 분이라면 한 번쯤 겪어봤을 상황입니다. 처음에는 신나게 "이것도 만들어줘, 저것도 만들어줘" 하며 AI에게 계속 요청만 하다가, 어느 순간 화면이 통째로 멈추면 그제서야 등에 식은땀이 흐릅니다. 검색창에 에러 메시지를 그대로 붙여넣어 봐도, 나온 답변대로 따라 해봐도 상황은 더 꼬이기만 합니다. 결국 파일을 하나하나 열어서 손으로 되돌리려다가, 오히려 원래 있던 다른 기능까지 망가뜨리는 경우도 적지 않습니다.
이 글은 바로 이 순간, "AI가 짜준 코드가 갑자기 깨졌을 때" 무엇을 눌러야 하는지를 실제 시나리오로 따라가며 알려드립니다. 설치 방법이나 협업 워크플로 같은 기초 이론은 다루지 않습니다. 오직 "사고가 터진 순간 되돌리는 법"에만 집중합니다. 지금 이 글을 읽고 있는 사이에도 어딘가에서는 비슷한 화면 앞에서 발을 동동 구르고 있을 텐데, 끝까지 따라오시면 다음에는 똑같은 상황에서 당황하지 않고 몇 초 만에 해결할 수 있게 됩니다.
왜 AI 코딩 도구를 쓸수록 Git이 더 절실해질까
사람이 직접 코드를 짤 때는 보통 자기가 방금 뭘 바꿨는지 기억하고 있습니다. "아까 이 함수 하나만 건드렸으니까, 그것만 원래대로 돌리면 되겠다"는 감이 있죠. 그런데 Cursor, GitHub Copilot, ChatGPT 같은 AI 코딩 도구는 다릅니다.
- 내가 요청한 범위보다 훨씬 넓게 고친다 — "버튼 색만 바꿔줘"라고 했는데 관련 없어 보이는 파일 3~4개까지 함께 수정하는 경우가 흔합니다.
- 왜 그렇게 고쳤는지 설명이 부족하다 — 사람 개발자는 "이 부분은 이래서 바꿨어요"라고 맥락을 남기지만, AI는 결과 코드만 툭 내놓습니다.
- 비전공자는 코드를 읽고 위험을 미리 감지하기 어렵다 — 어떤 줄이 위험한 변경인지 판단할 눈이 아직 없는 상태에서, AI의 제안을 그대로 적용하게 됩니다.
결국 "AI가 무엇을, 어디까지 바꿨는지"를 사람이 다 파악하지 못한 채로 코드가 계속 쌓여갑니다. 이 간극을 메워주는 도구가 바로 Git입니다. Git은 코드가 바뀔 때마다 그 순간의 스냅샷을 저장해두기 때문에, AI가 무슨 짓을 했든 상관없이 "그 직전 상태"로 정확히 되돌아갈 수 있습니다. 즉 Git은 AI를 못 믿어서 쓰는 게 아니라, AI를 마음 편히 믿고 쓰기 위한 안전망입니다.
실전 시나리오 — 화면이 깨진 그 순간, 5단계로 되돌리기
아래는 실제로 자주 벌어지는 흐름을 그대로 재현한 것입니다. 지금 여러분의 상황과 비교하면서 따라와 보세요.
0단계 (사고 전) — 평소에 "저장 지점"을 만들어두는 습관
사고를 되돌리려면, 되돌아갈 지점이 먼저 있어야 합니다. 화면이 잘 작동하는 걸 확인할 때마다 커밋(commit)을 하나 남겨두는 습관이 핵심입니다. 게임으로 치면 세이브 포인트를 만드는 것과 같습니다.
git add .
git commit -m "로그인 화면 정상 작동 확인"이 한 줄을 습관으로 만들어두면, 앞으로 AI에게 무엇을 시키든 "최악의 경우에도 여기까지는 돌아갈 수 있다"는 안전지대가 생깁니다. 특히 AI에게 큰 수정을 맡기기 직전에는 반드시 커밋해두는 것을 권장합니다.
1단계 — 무엇이 바뀌었는지부터 눈으로 확인한다
화면이 깨졌다는 걸 발견했다면, 무작정 되돌리기 전에 AI가 정확히 무엇을 건드렸는지부터 확인합니다. git diff 명령어는 마지막 커밋 이후 바뀐 모든 내용을 줄 단위로 보여줍니다.
git diff빨간색(-)으로 표시된 줄은 삭제된 코드, 초록색(+)으로 표시된 줄은 새로 추가된 코드입니다. 여기서 "아, AI가 로그인 함수 안에 있던 이 조건문을 지워버렸구나" 같은 원인을 눈으로 확인할 수 있습니다. 특정 파일만 확인하고 싶다면 파일명을 뒤에 붙이면 됩니다.
git diff src/components/LoginForm.tsx실제로 git diff를 실행하면 아래와 비슷한 결과가 나옵니다. 처음 보면 암호처럼 느껴지지만, 규칙은 간단합니다. -로 시작하는 줄은 사라진 코드, +로 시작하는 줄은 새로 생긴 코드입니다.
- if (user && user.isLoggedIn) {
- return <Dashboard />;
- }
+ return <Dashboard />;이 예시만 봐도 "로그인 여부를 확인하던 조건문이 통째로 사라졌구나"라는 원인을 바로 알 수 있습니다. 코드를 완전히 이해하지 못해도, 무엇이 빠졌는지 정도는 비전공자도 충분히 읽어낼 수 있습니다.
이 단계를 건너뛰고 바로 되돌리기부터 하면, 왜 깨졌는지 원인을 영영 모른 채 넘어가게 됩니다. AI에게 "방금 왜 이렇게 고쳤어?"라고 되물을 때도, git diff 결과를 그대로 붙여넣고 "이 변경 때문에 로그인 화면이 하얗게 떠. 원인이 뭐고 어떻게 고쳐야 해?"처럼 구체적으로 물어보면, "그냥 안 돼요"라고만 물어볼 때보다 훨씬 정확한 답을 받을 수 있습니다.
2단계 — 문제가 된 파일 딱 하나만 되돌린다
원인 파일이 특정됐다면, 프로젝트 전체가 아니라 그 파일만 콕 집어 되돌릴 수 있습니다. git checkout -- 명령어는 해당 파일을 마지막 커밋 상태로 복원합니다.
git checkout -- src/components/LoginForm.tsx이 방법의 장점은 "정상이었던 다른 파일들은 그대로 두고, 문제가 생긴 파일만" 정밀하게 되돌릴 수 있다는 점입니다. 화면 전체가 아니라 버튼 색상 하나 때문에 깨졌다면, 굳이 다른 작업까지 날릴 필요가 없죠. 여러 파일을 한 번에 되돌리고 싶다면 파일명을 공백으로 나열하거나 점(.)으로 전체를 지정할 수 있습니다.
git checkout -- .3단계 — 그래도 안 되면, 통째로 이전 커밋으로 되돌린다
AI가 워낙 광범위하게 손을 대서 어느 파일이 문제인지 특정하기 어려운 경우도 있습니다. 이럴 때는 git reset --hard로 프로젝트 전체를 특정 커밋 시점으로 되돌립니다.
git reset --hard HEAD~1HEAD~1은 "바로 직전 커밋"을 의미합니다. 두 번 전 커밋으로 돌아가고 싶다면 HEAD~2처럼 숫자를 바꾸면 됩니다.
⚠️ 반드시 알아야 할 위험성: reset --hard는 되돌리는 순간 이후의 변경 사항을 전부 삭제합니다. checkout --과 달리 "취소" 버튼이 없고, 커밋해두지 않은 작업은 복구가 사실상 불가능합니다. 그래서 이 명령어를 쓰기 전에는 반드시 다음을 확인해야 합니다.
- 지금 되돌리려는 범위에 꼭 지켜야 할 작업이 섞여 있지는 않은가
- 커밋하지 않은 변경 사항이 남아있지 않은가 (
git status로 확인) - 혹시 모르니 되돌리기 전에 폴더 자체를 통째로 복사해 백업해두었는가
즉 reset --hard는 화재경보기의 비상 버튼과 같습니다. 웬만한 화재는 창문을 열거나 소화기로 끄는 걸로 충분하듯이, 대부분의 경우 1~2단계인 git diff와 git checkout --만으로도 문제가 해결됩니다. reset --hard는 그 방법들로도 도저히 답이 안 나올 때, 정말 확실할 때만 신중하게 눌러야 하는 마지막 수단입니다.
4단계 — 지우지 말고 "잠깐 치워두고" AI 제안을 실험해보는 법
때로는 AI가 제안한 코드가 진짜 문제인지 아직 확신이 서지 않을 수 있습니다. 지우기는 아깝고, 그렇다고 화면이 깨진 채로 계속 작업할 수도 없는 애매한 순간이죠. 이때는 git stash로 현재 변경 사항을 임시 서랍에 넣어둘 수 있습니다.
git stash이 명령어 하나로 작업 중이던 변경 사항이 전부 사라진 것처럼 깨끗한 상태(마지막 커밋 상태)로 돌아갑니다. 이 상태에서 화면이 정상인지 다시 확인해보고, "역시 AI가 고친 부분이 원인이었구나"를 검증할 수 있습니다. 그 코드를 다시 살펴보고 싶다면 서랍에서 꺼내오면 됩니다.
git stash pop반대로 그 변경 사항이 필요 없다고 확실해졌다면 서랍째 버릴 수도 있습니다.
git stash dropstash는 "지울지 말지 아직 모르겠다"는 애매한 순간을 위한 임시 보관함이라고 기억해두면 됩니다.
AI 코딩 시 Git 활용 습관 체크리스트
매번 상황마다 어떤 명령어를 써야 할지 고민하지 않도록, 아래 체크리스트를 작업 전후로 확인하는 습관을 들여보세요.
- ☐ AI에게 큰 수정을 맡기기 전에 지금 상태를 커밋해두었는가
- ☐ AI 수정이 끝난 뒤, 적용하기 전에
git diff로 변경 범위를 눈으로 확인했는가 - ☐ 화면이 깨졌다면 전체를 되돌리기 전에, 문제 파일만
git checkout --으로 좁혀서 되돌릴 수 있는지 먼저 시도했는가 - ☐
git reset --hard를 쓰기 전,git status로 날아갈 변경 사항이 없는지 확인했는가 - ☐ 확신이 서지 않는 AI 제안은 지우지 말고
git stash로 잠깐 치워둔 뒤 비교해봤는가 - ☐ 화면이 정상으로 돌아오면, 다시 그 상태를 커밋해서 새 저장 지점을 만들었는가
이 여섯 가지만 습관으로 만들어두면, AI가 아무리 예상 밖의 코드를 만들어내도 "최악의 경우 몇 초 전으로 되돌리면 된다"는 안도감을 가지고 작업할 수 있습니다. 처음에는 매번 커밋하는 게 번거롭게 느껴질 수 있지만, 한 번이라도 이 습관 덕분에 몇 시간 걸릴 뻔한 복구를 몇 초 만에 끝내본 경험을 하고 나면 자연스럽게 몸에 붙습니다. Git은 결국 실수를 막아주는 도구가 아니라, 실수를 해도 괜찮게 만들어주는 도구입니다.
수강 정보
누구나패스의 무료 강의 「깃 & 깃허브 완벽 가이드」에서는 이번 글에서 다룬 git diff, git checkout --, git reset --hard, git stash 같은 복구 명령어를 실제 화면을 보며 함께 실습합니다. 코딩 경험이 없어도 15분이면 핵심을 따라갈 수 있도록 구성했으며, 카테고리는 업무 생산성, 강사는 누구나패스 운영팀이 직접 진행합니다. 회원가입 후 바로 시청 가능합니다.
자주 묻는 질문
Q. git reset --hard로 되돌렸는데, 그 사이의 변경 사항을 다시 살릴 방법은 없나요?
기본적으로는 복구가 매우 어렵습니다. 그래서 이 명령어는 반드시 신중하게, 되돌리기 전 상태를 확실히 확인한 뒤에만 사용해야 합니다. 불안하다면 reset --hard 대신 이번 글에서 소개한 git checkout --이나 git stash처럼 더 안전한 방법을 먼저 시도해보세요.
Q. AI가 여러 파일을 동시에 고쳐서 어디서부터 봐야 할지 모르겠어요.
git diff --stat 명령어를 쓰면 어떤 파일이 몇 줄씩 바뀌었는지 요약으로 먼저 볼 수 있습니다. 변경 줄 수가 유난히 많은 파일부터 git diff 파일명으로 하나씩 살펴보면 원인을 좁혀나가기 쉽습니다.
Q. AI에게 매번 요청할 때마다 커밋해야 하나요? 너무 귀찮을 것 같아요.
모든 요청마다 커밋할 필요는 없습니다. 기준을 "화면이 정상 작동하는 걸 눈으로 확인한 시점"으로 잡으면 충분합니다. 예를 들어 로그인 기능을 완성해서 실제로 로그인이 되는 걸 확인했다면 그때 커밋, 그 다음 결제 기능을 만들어 정상 작동을 확인했다면 또 커밋하는 식입니다. 이렇게 "확실히 작동하는 지점"마다 커밋을 남겨두면, 나중에 무엇이 문제였는지 찾을 때 되돌아갈 지점의 간격도 딱 적당해집니다.
Q. Git과 GitHub 기본 개념이나 설치 방법도 알고 싶어요. 어디서 배우나요?
이 글은 "이미 Git이 설치된 상태에서 사고를 되돌리는 법"에 집중한 트러블슈팅 가이드입니다. Git·GitHub의 기본 개념과 설치 과정이 궁금하다면 마트 장바구니와 타임머신으로 이해하는 깃(Git)·깃허브 설치부터 에러 복구까지 글을, 여러 명이 함께 작업하는 정석 협업 워크플로(브랜치, Pull Request 등)가 궁금하다면 깃허브 입문 가이드 — 개발자 필수 협업 툴 글을 참고해보세요.
AI가 짜준 코드가 다시 깨지더라도, 이제는 당황하지 않고 몇 초 만에 되돌릴 수 있습니다. 지금 바로 확인해보세요.
댓글
불러오는 중...
