AI에게 작업을 맡기다 보면 언젠가 이런 순간이 온다. 세션 중간에 AI가 메인 저장소를 잘못 건드린 것이다. 이번 글은 그 상황을 dev 브랜치의 깨끗한 상태로 되돌린 기록이다. 복구 과정에서 무엇을 건드리지 않았는지, 그리고 이런 일이 생겼을 때 사람이 무엇을 확인해야 하는지를 정리한다.

무슨 일이 있었나

  • 세션 도중 AI가 메인 저장소(메인 체크아웃) 를 잘못 건드렸다.
  • 목표는 단순했다. 메인 체크아웃을 dev 브랜치의 깨끗한 상태로 되돌리는 것.
  • 같은 저장소에는 다른 세션이 쓰던 워크트리가 11개 있었다. 이 워크트리들은 건드리지 않았다.

복구 원칙: 내 것만 되돌린다

가장 신경 쓴 부분은 "되돌리는 범위"다. 메인 체크아웃이 엉망이 됐다고 해서 저장소 전체를 청소하면 안 된다. 다른 세션의 워크트리는 각자 진행 중인 작업이 있는 별개의 작업 공간이다. 그 안에는 아직 커밋되지 않은 변경이 있을 수 있다.

그래서 복구 대상을 메인 체크아웃 하나로 한정했다.

  1. 현재 상태를 먼저 확인한다. 어떤 브랜치에 있는지, 무엇이 바뀌었는지 눈으로 본다.
  2. 메인 체크아웃만 dev의 깨끗한 상태로 되돌린다.
  3. 다른 세션의 워크트리 11개는 목록에서 확인만 하고 손대지 않는다.

되돌리기는 파괴적인 작업이다. 무엇을 버리는지 보고 나서 실행해야 한다. 한 번 날아간 미커밋 변경은 복구할 방법이 마땅치 않다.

AI에게 맡긴 작업이 어긋났을 때 사람이 확인할 것들

이번 일에서 얻은 체크리스트다. 복구를 AI에게 다시 맡기더라도, 아래는 사람이 직접 눈으로 확인하는 편이 안전하다.

  • 지금 어느 브랜치, 어느 디렉터리인가. git status와 git branch --show-current로 시작한다. 메인 체크아웃과 워크트리는 다른 경로다.
  • 무엇이 바뀌었는가. 되돌리기 전에 git diff와 미추적 파일 목록을 본다. 버려도 되는 변경인지 판단하는 것은 사람의 몫이다.
  • 다른 세션이 쓰는 워크트리는 없는가. git worktree list로 확인한다. 내 작업이 아닌 워크트리는 건드리지 않는다.
  • 되돌릴 기준점이 맞는가. 이번에는 dev의 깨끗한 상태가 기준이었다. 원격과 로컬 dev가 일치하는지도 확인한다.
  • 복구 후 상태를 다시 확인한다. 작업 트리가 깨끗한지, 브랜치가 기대한 곳인지, 다른 워크트리가 그대로인지 확인한다.

정리

AI가 실수하는 것 자체는 피하기 어렵다. 중요한 것은 실수가 났을 때 피해 범위를 키우지 않는 것이다. 이번 복구에서 지킨 원칙은 하나였다. 어긋난 곳만 되돌리고, 나머지 11개 워크트리는 그대로 둔다. 그리고 되돌리기 전에는 항상 사람이 상태를 먼저 본다.