여러 파일을 한 번에 고치는 세션 중간에 방향을 잘못 잡은 걸 뒤늦게 알아차리는 경우가 있습니다. 이미 절반은 맞는 방향으로 고쳐뒀고 나머지 절반만 잘못됐다면, git checkout .으로 전체를 되돌리면 맞게 고친 부분까지 같이 날아갑니다. Claude Code의 체크포인트(Rewind) 기능으로 잘못된 부분만 골라 되돌린 과정을 정리합니다.

어떤 작업이었나

공유 모듈의 리포지토리 계층에서 콜백 기반 API를 코루틴 suspend 함수로 바꾸는 작업이었습니다. 인터페이스, 구현체, 호출하는 ViewModel까지 열 개 남짓한 파일을 순서대로 고치고 있었는데, 일곱 번째 파일쯤에서 호출부 하나를 suspend fun이 아니라 기존 콜백 시그니처를 유지한 채로 감싸는 방식으로 잘못 고쳐버렸습니다. 문제는 그 이후로도 Claude Code가 "이미 콜백을 유지하는 전제"로 다음 파일 세 개를 이어서 고쳤다는 점이었습니다. 앞의 여섯 파일은 의도한 대로 잘 바뀌어 있었고, 뒤의 네 파일만 엉뚱한 전제로 진행된 상태였습니다.

AI를 어떻게 활용했나

먼저 Esc를 두 번 눌러 체크포인트 목록을 열었습니다. Claude Code는 파일을 수정하는 도구 호출 하나마다 자동으로 체크포인트를 남기는데, 목록에는 각 체크포인트 시점의 대화 요약과 그때까지 바뀐 파일 목록이 함께 나왔습니다.

> (Esc Esc)

Rewind to checkpoint
❯ 지금 (변경 없음)
  ItemRepositoryImpl.kt 수정 직후 — "suspend 함수로 전환"
  ItemDetailViewModel.kt 수정 직후 — "콜백 호출부를 suspend 호출로 교체"
  ItemListViewModel.kt 수정 직후 — "콜백 유지한 채로 래핑"  <- 여기서부터 잘못됨
  ...

잘못된 방향으로 틀어지기 직전, 즉 ItemDetailViewModel.kt까지만 고쳐져 있던 체크포인트를 선택했습니다. 이때 되돌릴 범위를 "대화만", "코드만", "대화와 코드 모두" 중에서 고를 수 있었는데, 여기서는 "코드와 대화 모두"를 선택했습니다. 실수의 원인이 된 지시(그 시점에 제가 잘못 준 프롬프트)까지 같이 되돌려야 같은 실수가 반복되지 않을 것 같았습니다.

되돌린 뒤 다시 요청:
ItemListViewModel부터 나머지 파일까지, 콜백을 유지하지 말고
전부 suspend 함수 호출로 바꿔줘. 콜백 래핑은 하지 마.

이번에는 "콜백 래핑 금지"라는 조건을 명시적으로 넣었습니다. 되돌리기 전 프롬프트에는 이 조건이 없었는데, Claude Code가 임의로 콜백을 유지하는 쪽을 "더 안전한 선택"으로 판단해서 래핑한 것으로 보였습니다.

결과와 얻은 팁

  • 체크포인트는 Claude Code가 파일을 수정한 시점마다 자동으로 쌓여서, 언제 무엇이 바뀌었는지 goal을 따로 기록하지 않아도 목록에서 바로 찾을 수 있었습니다. git log처럼 커밋 단위로 남기는 게 아니라 도구 호출 단위라 더 세밀하게 되돌릴 지점을 고를 수 있었습니다.
  • "코드만" 되돌리면 대화 맥락은 그대로 남아서, 같은 프롬프트를 다시 보내면 잘못된 결과가 반복될 위험이 있었습니다. 실수의 원인이 프롬프트 자체에 있었다면 "대화와 코드 모두"를 되돌려서 지시부터 고쳐 다시 보내는 편이 안전했습니다.
  • 체크포인트는 세션 안에서 Claude Code가 도구로 수정한 파일만 추적합니다. 같은 시간에 터미널이나 IDE에서 직접 고친 파일은 체크포인트 대상이 아니라서, 되돌리기 전에 세션 밖에서 수동으로 건드린 파일이 있었는지 먼저 확인해야 했습니다.
  • git 커밋을 아직 하지 않은 작업 중간 단계에서 부분적으로만 되돌리고 싶을 때 유용했습니다. git stash나 git reset은 파일 단위로 전체를 되돌리지만, 체크포인트는 세션 안에서 "이 지시부터 잘못됐다"는 지점을 정확히 짚어 그 이후 변경만 걷어낼 수 있었습니다.