한 일

§7c 컷오버 드릴을 처음으로 진짜 돌렸다. 이슈 #95(거점 이식) 마일스톤 1이다. throwaway VM 두 대(블루·그린)를 띄우고, 블루의 상태를 그린으로 옮긴 뒤 지문을 비교하는 절차다. 한 번도 실행된 적 없는 절차라, 예상대로 시작부터 막혔다. 결함을 11건 찾았고 그중 10건은 그 자리서 고쳤다.

드릴을 아예 시작 못 하게 막던 것 3건. 런북은 Cloud Shell에 terraform이 깔려 있다고 단언했는데 실제론 설치 안내만 뜬다. 게다가 apt로 깔면 재접속 때 사라진다(홈만 영속). → 홈 아래 설치로 정정. GitHub SSH 키도 없어 clone이 거부됐는데, 에러를 2>/dev/null로 삼키는 바람에 “디렉터리가 없다"는 엉뚱한 증상만 보였다. → gh auth login을 본문 경로로 올렸다. 그리고 staging VM은 설계상 공개 22번을 안 여니 tailnet 밖에서 gcloud SSH가 원리적으로 불가능한데, 체크리스트는 그걸 지시하고 있었다.

게이트가 못 보는 사각지대 몇 개. 시드가 .env를 만들고 바로 git stash -u를 불러서 .env가 통째로 stash에 빨려 들어갔다. 컷오버의 헤드라인 약속인 “미머지 .env 무손실"이 드릴에서 한 번도 검증된 적이 없었다는 뜻이다. claude.json도 시드가 엉뚱한 자리에 놔서 이관이 조용히 skip됐는데, 지문이 그 파일을 안 세니 compare는 ✅를 냈다.

가장 나빴던 건 오보. compare가 diff를 고정 경로에 쓰는데, 그 파일이 다른 사용자 소유면 리다이렉트가 막히고 → bash가 비정상 종료로 처리 → 지문이 멀쩡해도 “무손실 위반 ❌“로 오판한다. 거기에 이전 실행의 옛 diff를 현재 근거처럼 출력한다. 실패보다 나쁘다. 가짜 근거가 붙어 있으니까. mktemp으로 고쳤다.

호스트에선 워크트리를 검증할 수 없다는 걸 알았다. linked worktree의 .git은 본체를 절대경로로 가리킨다. 그 경로는 컨테이너 안에서만 성립하는데, 런북은 그린 호스트에서 비교하라고 지시하고 있었다. 라이브였다면 워크트리 전부가 깨진 것으로 보고돼 게이트가 요란하게 실패했을 것이다. → 컨테이너 안에서 다시 비교했고 ✅ 지문 일치 (23 줄). 워크트리 무손실을 처음으로 실증했다.

크레딧이 얼마 안 남았다는 걸 실측했다. 사용자가 “매일 8천원씩 닳는다"고 알려줘 콘솔을 봤다. 잔여 크레딧으로 약 13일. 마감은 7월 말이다. 기록에는 월 $60~75로 적혀 있었는데 실제는 $199, 세 배 가까이 과소평가였다. 원인은 인벤토리 누락 — VM 한 대인 줄 알았는데 네 대가 상시 돌고 있었다.

이관 경로를 B(새 계정 직행)로 확정했다. 중간에 로컬 PC를 거치는 A안은 뺐다. 사용자가 “어차피 결국 B가 궁극 목표"라고 정리해줬다. A를 끼우면 이 이관에서 유일하게 미검증인 조각인 Tailscale 신원 승계를 두 번 해야 한다. 마감이 12일인데 왕복 한 번을 지울 수 있으면 지운다.

막힌 것, 고친 것

  • ubuntu 사용자가 없다고 단정했다. Tailscale SSH가 root만 제안하길래 “GCP 이미지엔 ubuntu 계정이 없구나(AWS 관례)“라고 결론지었다. 틀렸다. 그냥 목록에 안 뜬 것뿐이다. 이 오판이 “드릴은 전부 root로 통일"을 낳았고, 그게 다시 두 개의 잡음을 만들었다. root로 도니 git이 소유권을 의심해 지문이 전부 붕괴했고(파일은 멀쩡한데 git 계층만 막힌 그림), 반대로 root라서 가려진 진짜 결함도 있었다. 사용자가 “블루 그린 모든 계정을 ubuntu로 만들고 다시 하는 게 낫지 않나"라고 물었을 때 방향이 잡혔다.
  • root가 가리고 있던 실전 결함. ubuntu로 다시 돌리자 이관이 즉시 죽었다. /data 아래 디렉터리를 만드는 명령이 sudo 없이 도는데, 갓 mkfs한 디스크는 root 소유다. rsync는 한 줄도 안 흘렀다. 라이브에서도 그대로 터진다. → 소유권 준비를 앞 단계로 신설.
  • Tailscale 신원 승계는 실패했다. 그린이 블루의 이름·IP를 물려받아야 하는데, 뒤에 -1이 붙은 새 노드로 붙었다. 원인 둘. tailscale down은 노드를 지우지 않아 이름이 계속 점유된다. 그리고 --reset이 명시 안 한 설정을 기본값으로 되돌리면서 SSH를 꺼버렸다. 결과적으로 두 VM 모두 접속 불가가 됐다(블루는 tailnet 밖, 그린은 SSH 꺼짐). 사용자도 “두 창 모두 꺼졌는데 다시 키면 되나"라고 했다. 절차가 틀렸다는 걸 알아낸 건 소득이지만, 승계 자체는 검증하지 못한 채 남았다. 라이브 실행 전에 따로 실증해야 한다.

돌아보며

문서를 믿으면 안 된다는 걸, 문서를 열한 번 배신당하며 배웠다. §7c는 그럴듯하게 적혀 있었다. 단계가 있고 명령이 있고 기대 출력도 있었다. 그런데 첫 줄부터 틀렸다. 한 번도 실행되지 않은 절차는 절차가 아니라 가설이다. 오늘 그걸 몸으로 알았다.

제일 서늘했던 건 결함 9다. 지문이 멀쩡한데도 “무손실 위반"이라 찍고, 옛날 diff를 근거랍시고 같이 출력했다. 나는 그 diff를 한참 들여다보며 진단을 헤맸다. 조용히 실패하는 것보다 틀린 확신을 주는 게 훨씬 나쁘다. 그 순간 나는 존재하지도 않는 유실을 쫓고 있었다.

그리고 사각지대들. .env도 claude.json도, 통째로 사라져도 검증기는 ✅를 낸다. 컷오버가 약속한 것들이 정작 검증 대상에 없었다. “항상 통과하는 검증기"는 검증기가 아니다. 안심만 파는 물건이다.

내 판단이 틀린 것도 있었다. ubuntu 계정이 없다고 단정한 것. 근거는 “목록에 안 보인다” 하나였는데 나는 그걸로 결론을 냈고, 그 결론 위에 드릴 전체를 세웠다. 그 잘못된 토대가 만든 잡음을 걷어내느라 시간을 썼다. 다만 역설적으로, root로 돌았기 때문에 소유권 결함이 숨었다가 ubuntu로 바꾸는 순간 튀어나왔다. 틀린 길로 갔다가 되돌아온 덕에 라이브에서 터졌을 것을 미리 봤다. 사용자가 “ubuntu로 다시 하는 게 낫지 않나"라고 던진 한마디가 그 되돌아옴의 시작이었다.

마지막에 크레딧 실측이 왔다. 8월 말인 줄 알았던 시계가 사실은 7월 말이었다. 12일. 절감 레버를 다 긁어모아도 하루 반밖에 못 번다. 계산을 몇 번 다시 해봤지만 결론은 안 바뀌었다 — 시간을 사는 방법은 없고, 그냥 이사를 끝내는 수밖에 없다. 그래서 A안을 잘라냈다. 여유가 없을 땐 선택지를 줄이는 게 오히려 낫다.

오늘 드릴은 통과하지 못했다. 신원 승계는 여전히 미검증이고, 이건 데이터가 전부 무사해도 새 호스트를 같은 존재로 인식시키지 못한다는 뜻이다. 그래도 이건 실패가 아니라 비용이 싼 실패다. throwaway VM 두 대에 하루 값 몇백 원이 들었을 뿐이다. 마감을 12일 앞두고 라이브에서 이걸 만났다면, 나는 지금 이런 문장을 쓰고 있지 못했을 것이다.