막히거나 잘못 갈 때

바이브 코딩이 늘 매끄럽지는 않다. 에이전트가 엉뚱한 방향으로 가거나, 버그가 누적되거나, 대화가 길어져 맥락이 흐려질 때가 있다. 중요한 건 이때 당황하지 않고 깔끔하게 되돌리고 방향을 다시 잡는 절차를 아는 것이다.

학습 목표

• Claude Code 안에서 즉시 멈추고 이전 지점으로 되감을 수 있다.
• git으로 잘못된 변경을 안전하게 되돌릴 수 있다.
• 방향이 틀렸을 때 명확히 수정을 요청할 수 있다.
• 버그를 재현·원인·수정의 흐름으로 맡길 수 있다.
• 맥락이 흐려졌을 때 정리하고 다시 시작할 수 있다.

먼저: 멈추고 되감기

방향이 잘못됐다는 걸 알아챘다면, git을 꺼내기 전에 Claude Code 안에서 바로 대응할 수 있다.

• Esc — 작업 중인 에이전트를 즉시 멈춘다. 엉뚱한 일을 하고 있을 때 가장 먼저 누른다.
• Esc 두 번 — 대화를 이전 지점으로 되감아(rewind), 그 시점부터 다른 방향으로 다시 시도한다. git 커밋을 거치지 않고 세션 안에서 빠르게 되돌리는 방법이다.

세션 안 되감기는 빠른 반면, 이미 디스크에 쌓인 변경을 확실히 정리하려면 아래 git 방식이 안전하다. 둘을 상황에 맞게 함께 쓴다.

git으로 되돌리기

4강에서 단계마다 커밋한 이유가 여기서 빛난다. 변경이 잘못됐다면 마지막 정상 커밋으로 돌아간다.

# 아직 커밋 안 한 변경을 전부 버리고 마지막 커밋 상태로
git restore .

# 특정 파일만 되돌리기
git restore src/components/Comment.tsx

# 변경 내역을 먼저 확인
git status
git diff

이미 커밋했지만 그 커밋이 통째로 잘못됐다면, 새 작업 브랜치에서라면 한 단계 되돌릴 수 있다.

git log --oneline   # 돌아갈 지점 확인
git reset --hard <정상_커밋_해시>

reset --hard는 변경을 영구히 버리므로, 커밋 안 한 소중한 작업이 없는지 먼저 확인한다. 커밋을 자주 해 둘수록 이 선택이 안전해진다.

방향 수정 요청하기

코드를 버리지 않고도 말로 방향을 바로잡을 수 있는 경우가 많다. 무엇이 틀렸고 무엇을 원하는지 구체적으로 말한다.

> 지금 방향이 아니야. 전역 상태 라이브러리를 새로 도입했는데,
> 그건 과해. 되돌리고 useState만으로 다시 해줘.

> 절반은 맞아. 목록 렌더는 그대로 두고,
> 삭제 로직만 id 기반으로 다시 작성해줘.

"전부 다시"보다 "무엇을 유지하고 무엇을 바꿀지"를 짚으면 멀쩡한 부분까지 날리는 일을 막을 수 있다.

버그를 맡기기: 재현 → 원인 → 수정

버그를 만나면 "고쳐줘"라고만 하지 말고, 재현 방법과 증상을 정확히 전달한다. 그래야 에이전트가 추측 대신 원인을 짚을 수 있다.

> 버그가 있어. 재현: 할 일 2개를 추가하고 첫 번째를 삭제하면,
> 두 번째까지 함께 사라져.
> 기대: 첫 번째만 삭제되어야 함.
> 먼저 원인을 설명하고, 그다음에 수정해줘.

원인 설명을 먼저 요청하면, 엉뚱한 곳을 고치는 것을 막고 같은 실수가 반복되는지 알 수 있다. 에러 메시지나 콘솔 로그가 있으면 그대로 붙여넣는다.

> 콘솔에 이 에러가 떠: "Cannot read properties of undefined (reading 'id')"
> 어느 코드에서 나는지 찾아서 원인과 수정안을 알려줘.

같은 자리를 맴돌 때

에이전트가 고친다고 했는데 같은 문제가 반복되면, 접근을 바꾼다.

• 더 작게: 문제 부분만 떼어내 최소 예제로 재현하게 한다.
• 로그 추가: "어디서 값이 잘못되는지 로그를 찍어 확인하자."
• 가정 점검: 내가 준 정보가 틀렸을 수도 있다. 실제 동작을 다시 확인한다.
• 직접 개입: 한두 줄이면 내가 고치는 게 빠를 때도 있다(7강).

맥락 초기화

대화가 아주 길어지면 에이전트가 오래된 맥락에 얽매여 헤맬 수 있다. 이럴 땐 깔끔히 새로 시작하는 편이 낫다.

• 현재 코드 상태를 커밋해 안전하게 만든다.
• 새 대화(또는 /clear)로 시작하고, 지금 상태와 목표만 간결히 다시 설명한다.
• 길게 쌓인 시행착오 대신, 현재 코드와 다음 목표에 집중한다.

코드는 파일에 남아 있으므로, 대화 맥락을 비워도 작업은 사라지지 않는다. 흐려진 맥락보다 깨끗한 출발이 나을 때가 많다.

요약

잘못 갈 때를 위한 도구는 분명하다. 커밋해 둔 지점으로 git이 되돌려 주고, 무엇을 유지·변경할지 짚어 방향을 수정하며, 버그는 재현·원인·수정의 순서로 맡긴다. 같은 자리를 맴돌면 더 작게 쪼개거나 직접 개입하고, 맥락이 흐려지면 커밋 후 깨끗이 다시 시작한다. 자주 커밋하는 습관이 이 모든 회복을 가능하게 한다.