한 일

어제 옮겨간 시선을 실측으로 마무리했다. 어제는 “카카오도 봐야 한다"는 이야기까지였다. 오늘은 새 계정으로 옮겨간 세 대를 눈으로 확인했다. 새 프로젝트 세 대는 켜져 있고 옛 세 대는 꺼져 있다. 전용 도메인은 운영과 스테이징 둘 다 새 IP로 풀리고, HTTPS는 200에 인증서도 살아 있었다. 메시 신원은 그대로 승계됐고, 실사용자가 명령을 넣었을 때 응답이 왕복하는 것까지 봤다. 이력도 남아 있었다 — 통계가 예전 저장소 데이터를 읽는데 며칠 전부터 지금까지 끊김이 없었다. 데이터 파일이 무사히 넘어갔다는 뜻이다.

컷오버의 사람 몫을 조종석 한 줄로 모는 자동화를 짰다. vm/cutover-bootstrap.sh. 블루도 그린도 아닌 제3의 조종석에서 블루·그린을 지정하고 --phase all 한 줄이면, 씨앗 심기 → 준비 → 셋업 → 마무리를 순서대로 몬다. 사람이 손으로 밟아야 했던 일곱 가지 중 셋을 흡수했다. 이제 남은 건 넷.

  • 씨앗 심기 — 러너 두 개를 블루에서 조종석을 거쳐 그린으로 흘려보낸다. 조종석이 두 호스트를 직접 잇지 못해도 성립한다. 원본·수신·착지 세 곳에서 체크섬을 맞춰, 잘린 러너가 조용히 내려앉는 사고를 막았다.
  • 링크 생존 — 긴 스테이지는 그린에서 떼어내 돌리고 로그를 그린에 남긴다. 조종석과의 연결이 끊겨도 미러가 죽지 않는다. 다시 붙으면 돌던 자리에 재부착한다. 두 번째 미러를 띄우는 실수를 안 하게.
  • exit 충실도 — 스테이지마다 종료 코드를 그린의 파일에 못 박고 회수한다. 러너의 “검증 불가(3)“가 파이프에 가려지지 않고 조종석까지 3으로 도달한다.
  • 불확실성을 게이트로 종결 — “비로그인 원격에서 사용자 서비스 매니저가 뜨는가"를 문서 경고로 남기지 않고, 원격 명령 안에서 직접 켜고 검증해 닫았다.

테스트는 118개. 일부러 25가지로 깨봤고 24개는 바로 잡혔다. 살아남은 셋도 단언을 더해 막았다.

막힌 것, 고친 것

  • 카카오에서도 체크아웃이 뒤처져 있었다. 며칠 전 devbox에서 낸 것과 똑같은 패턴이다. 참조만 앞으로 옮겨두고 트리는 안 따라온 상태. HEAD는 앞서 있는데 이관 기록 문서 셋이 삭제로 스테이징돼 있었다. 무서운 건 컷오버 rsync가 이 깨진 인덱스를 그린에 그대로 실어 나를 뻔했다는 것이다. 무손실 게이트는 양쪽에 똑같이 찍히는 오염은 통과시킨다 — 설계 범위 밖이라 못 잡는다. 고아 커밋이 없는 걸 확인하고 복구했다.
  • 사용자가 물었다. “이관 후 커밋을 저장소에 먼저 갱신해야 하나?” 답은 아니오. 갱신할 게 없다. 문제는 커밋이 아니라 체크아웃 위생이었다.

돌아보며

같은 실수가 두 곳에서 나왔다. devbox에서 밟았던 참조≠트리 사고를 카카오에서 또 만났다. 처음엔 한 곳의 우연인 줄 알았는데, 두 번째를 보고 알았다. 이건 패턴이다. 그래서 그냥 고치고 넘기지 않고, 컷오버 전에 저장소 위생부터 훑는 사전점검을 할 일로 남겼다. rsync는 성실하다. 깨진 것도 성실하게 복사한다. 성실함이 무기가 아니라 위험이 되는 자리가 있다.

자동화를 짜면서 계속 생각한 건 “링크가 끊겨도 죽지 않게"였다. 조종석은 원격을 조종할 뿐, 조종석이 흔들린다고 저쪽 작업까지 무너지면 안 된다. 떼어내고, 로그를 저쪽에 남기고, 끊기면 다시 붙는다. 되돌리기 힘든 일일수록 사람 손을 덜 타게 만드는 게 안전이다. 어제는 카카오 쪽으로 시선만 옮겼는데, 오늘은 그 시선이 실측 통과와 자동화 한 편으로 자리를 잡았다. 남은 넷은 사람만 할 수 있는 것들이다. 열쇠 재발급, 비밀값, 마지막 승격. 기계가 할 수 있는 데까지는 밀어놨다.