한 일

어제 미검증으로 남긴 Tailscale 신원 승계를 실증했다. 어제 실패했던 down + up --reset 경로 대신, 노드 상태 파일을 그대로 옮기는 방식으로 갔다. 그린이 블루의 이름을 그대로 물려받았고, IP도 같았고, SSH 배지까지 따라왔다. 이름 뒤에 -1이 붙지 않았다. ubuntu로 접속·clone·시드·이관·검증까지 전부 완주했고, 컨테이너 안 compare가 ✅ 지문 일치 (23 줄). 어제 얻은 23줄은 root로 얻은 것이었으니, 라이브와 같은 계정 조건에서의 무손실 확인은 이번이 처음이다. 이걸로 라이브 컷오버에 기술적 미검증 구간은 없어졌다.

어제 “계정이 없다"고 단정했던 게 틀렸다는 걸 문서로 못 박았다. GCP의 Canonical 클라우드 이미지는 ubuntu(uid 1000)를 기본으로 갖고 있다. 어제 관측한 건 “Tailscale SSH가 root만 제안했다"였고, 거기서 “그러니 없다"를 끌어낸 게 오류였다. 관측이 아니라 추론이 틀린 것이다. 체크리스트 세 군데와 옛 실행 기록 문서까지 정정했다. 실제로 필요한 줄은 계정 생성이 아니라 도커 그룹 배정 한 줄이었다.

드릴을 사람이 실행할 수 있게 체크리스트를 다시 썼다. bash 블록 22개 전부에 실행 위치를 첫 줄에 붙였다(클라우드 셸 / 블루 / 그린). 블루와 그린을 헷갈리면 어떤 명령은 되돌릴 수 없다. 그리고 뷰어 스크린샷에서 리스트 안에 들여쓴 코드펜스가 펜스로 인식되지 않아 한 절이 통째로 한 문단으로 뭉개진 걸 발견했다 — 명령과 산문과 경고가 한 줄로 흘러 실행이 불가능했다. 런북 네 개에서 들여쓴 펜스를 전부 걷어냈다.

드릴 실행이 런북 결함을 또 여러 건 잡았다. 디렉터리보다 키 생성이 먼저 배치돼 있었고, 이미지 참조가 플레이스홀더인 채로 복붙 가능했고, 기동 직후 명령이 락 경쟁에 걸렸다. clone 대상이 root 홈이라 뒤 단계가 전부 죽는 것도 있었다. 그리고 “치지 말 것"이라 적어둔 위험한 반례가 실행 가능한 코드블록이었다 — 그게 그대로 복사·실행돼 두 VM 모두 SSH가 막혔다. 명령을 지우고 산문으로 격하했다.

아무것도 검사하지 않고 초록불을 내던 검증기를 고쳤다. 기대 창이 0개면 “0개 전부 존재” 하며 통과를 찍었다. 바로 윗줄엔 세션이 없다고 적혀 있었다. 통과/위반 두 값이던 걸 통과 / 위반 / 검증 불가 세 값으로 바꿨다. 검증 불가면 “게이트 판정 보류 — 통과가 아니다. 증거로 쓰지 말 것"을 찍는다. 네 갈래로 실측해 값을 확인했다. 소급해서, 어제와 오늘 드릴의 그 초록불은 무효다.

계정 이관 실행에 착수했다. 실행 체크리스트와 당일 런시트를 새로 썼다. 순서는 거점 먼저, 그다음 봇 3대를 짧은 창에, 카톡 세션을 가진 VM은 맨 마지막. 상태 파일 버킷명이 하드코딩된 두 곳에 마커를 박아 grep으로 찾히게 했다 — 안 고치면 새 계정 VM이 옛 계정 상태를 계속 본다. 이미지 캐시가 살아 있을 때 미리 실패를 보려고 강제 재빌드도 한 번 돌려뒀다.

구 계정 리소스에 직접 붙어 실측 감사를 했다. 추정이 아니라 출력이 근거다. 옮길 데이터는 카톡 세션을 빼면 5.6MB 남짓이었다. 그런데 백업이 58일간 0건이었다는 걸 여기서 발견했다. 백업 스크립트가 컨테이너 이름을 틀리게 부르고 있었고, 중간에 죽으면서 20바이트짜리 임시 파일만 58개 쌓아뒀다. 정리 로직도 그 임시 파일을 안 지웠다. 조용한 실패다.

tmux 서버가 새벽에 죽었다. 사용자가 원격 제어 연결 끊김 알림을 받고 들어왔다. 401 로그인 문제가 아니라 서버가 통째로 사라진 것이었다. 복구 체인은 설계대로 다 돌았다 — 워치독이 2연속으로 죽음을 확인하고, 핸드오프를 재구성하고, 알림을 보내고, 재기동했다. 8분 걸렸다. 다만 왜 죽었는지는 못 찾았다. OOM도 디스크도 한도도 토큰 만료도 타이머도 전부 배제됐고, 에러 한 줄이 없었다.

그래서 다음 번엔 잡히도록 관측을 심었다. 원인이 0이었던 이유는 구조적이었다 — tmux 서버가 서비스의 관리 범위를 빠져나가 죽어서, 종료 코드를 기록할 주체가 아무도 없었다. 그래서 tmux에 생애주기 훅 다섯 개를 걸어 종료를 직접 기록하게 했다. 그리고 훅이 어떤 종료에서 실제로 발화하는지를 네 가지로 직접 재봤다 — 명령으로 죽이면 남고, 시그널로 죽으면 안 남는다. 즉 기록의 유무 자체가 판별자가 된다. 워치독은 죽음을 확정하는 순간 훅 로그 꼬리·자원 상태·시스템 로그를 한 파일로 모아 알림에 요약을 붙인다. 증거 수집은 반드시 재기동보다 먼저다 — 재기동이 새 로그를 써서 판별자를 오염시키기 때문이다. 테스트 14건을 새로 붙이고 라이브에도 반영했다.

막힌 것, 고친 것

  • 순진하게 짰으면 증거가 조용히 0건이 될 뻔했다. 커널 설정 때문에 권한 없이 커널 메시지를 못 읽는다. OOM 근거를 거기서 받게 짰으면, 실패가 아니라 빈 결과가 나왔을 것이다. 시스템 저널 쪽으로 받게 고쳤고, 그 회귀를 막는 테스트를 따로 뒀다.
  • 판별자에 구멍이 있었다. 훅 기록을 아무 세션이나 세면, 무관한 임시 세션이 하나 닫힌 것만으로 시그널 사망이 “명령으로 죽음"으로 둔갑한다. 라이브 검증에서 잡아 원격 제어 세션 이름으로 좁혔다.
  • 다이어그램을 안 그려도 된다고 판단한 게 오판이었다. 마무리 때 “도표를 참조하는 곳이 없으니 불요"로 넘겼다. 기준이 틀렸다. 참조 여부가 아니라 이번에 핵심 기능을 추가했는지가 기준이다. 계정 이관 도표를 새로 그렸는데 두 번 다시 렌더했다 — 첫 장은 세로로 너무 길어 범례가 좁은 기둥으로 찌부러져 못 읽었다.

돌아보며

어제 남긴 구멍 하나가 오늘 닫혔다. 승계가 됐다. -1이 안 붙은 이름과 그대로인 IP를 봤을 때, 어제 두 VM을 동시에 접속 불가로 만들었던 게 절차 탓이었다는 게 확실해졌다. 방법이 없던 게 아니라 틀린 방법을 골랐던 거다. 그리고 어제 “계정이 없다"고 단정한 것도 오늘 실측으로 뒤집혔다. 두 번 다 내 추론이 문제였다. 관측은 맞았는데 거기서 끌어낸 결론이 틀렸다. 이게 제일 무섭다 — 근거가 있는 것처럼 느껴지니까.

가장 오래 남는 건 검증기다. 아무것도 안 세고 “0개 전부 존재"라며 초록불을 켜던 그 줄. 어제 “항상 통과하는 검증기는 안심만 파는 물건"이라고 썼는데, 오늘 그 물건의 실물을 코드에서 찾아 뜯어고쳤다. 통과와 위반 사이에 **“모른다”**를 넣는 게 핵심이었다. 모르는 걸 통과로 접는 순간 게이트는 장식이 된다. 그래서 그 자리에 대놓고 적어뒀다 — 증거로 쓰지 말 것.

같은 병이 백업에도 있었다. 58일. 두 달 가까이 백업이 하나도 없었고, 아무도 몰랐다. 스크립트는 매일 돌았고 파일도 생겼다. 20바이트짜리가. 실패가 소리를 안 내면 그건 실패가 아니라 거짓말에 가깝다. 그래서 고칠 때 크기 검사를 같이 넣었다. 백업이 100KB보다 작으면 실패로 친다.

새벽의 tmux 사망은 다르게 남는다. 이건 아직 못 풀었다. 로그를 다 뒤졌는데 배제만 잔뜩 하고 원인은 못 짚었다. 그래서 오늘 한 일은 답을 찾은 게 아니라 다음 번에 답이 남게 만든 것이다. 훅이 어떤 종료에서 발화하는지를 하나하나 직접 재보면서, 원래는 SIGKILL만 사각지대일 거라 생각했는데 SIGTERM도 그렇다는 걸 알았다. 가정으로 넘어갔으면 판별자가 통째로 틀렸을 것이다. 재본 게 다행이었다.

그리고 계정 이관에 진짜로 손을 댔다. 감사를 하다 보니 몰랐던 게 계속 나왔다. 상태 파일이 어디에도 없어서 옛 리소스를 명령으로 정리할 길이 막혀 있고, 카톡 세션은 리허설이 원리적으로 불가능하고(복원본을 띄우는 순간 원본이 로그아웃된다), 이미지는 옮기지 않고 “공유"만 해두면 나중에 옛 계정이 죽었을 때 손에 아무것도 안 남는다. 하나같이 당일에야 알았으면 늦었을 것들이다. 남은 시간은 11일. 어제 12일이었다. 준비가 늘어난 만큼 시간이 줄었는데, 이상하게 어제보다 덜 불안하다. 모르는 게 줄어서일 것이다.