2026.06.26 작업일지 v1.0.0
09:20, 텔레그램 스크린샷 하나가 라이덴 Claude 자동업데이트 사고의 포렌식으로 이어졌다. 10:14, watchdog 바이너리 손상 감지와 nightly-update timeout 보강이 릴리즈까지 갔다. 16:48, live 세션 중
npm i -g를 막는 boot-grace 가드가 main에 들어갔다.
6월 26일은 전날의 업데이트 사고를 “복구됐다”로 덮지 않고, 왜 깨졌는지와 다음에는 어디서 멈춰야 하는지를 코드로 남긴 날이었다. 같은 날 브릿지 완료보고 누락, long working turn, 노드 보고 미러 같은 운영 표면도 같이 고쳤다. 사용자가 본 것은 에러가 많은 하루였지만, 실제 산출물은 재발방지 장치들이었다.
1. 깨진 것은 세션이 아니라 바이너리였다
아침 첫 단서는 “뭔 에러가 많냐”는 스크린샷이었다. 확인해보니 라이덴의 Claude 세션이 단순히 죽은 것이 아니었다. 자동업데이트가 실행 중 세션과 겹치면서 npm atomic swap이 중간에 깨졌고, staging 잔재와 broken 백업이 남아 claude --version 자체가 흔들렸다. watchdog은 이 상황을 세션 문제로 보고 tmux만 계속 재시작했다.
09:48에는 ~/.claude/state/forensics/2026-06-26-wsl-claude-autoupdate-enotempty.md에 포렌식을 남겼다. 6월 25일의 exit 137, staging 잔재, 6월 26일 watchdog 타임라인, 삭제된 44K broken 백업까지 기록했다. 실수도 같이 적었다. 포렌식은 변명문이 아니라, 다음 사람이 같은 함정에 빠지지 않게 하는 지도여야 했다.
2. watchdog은 바이너리 손상도 의심하게 됐다
그 다음 수정은 f0bfe57로 묶였다. watchdog escalation 실패가 반복되면 claude --version을 찍어 세션 문제가 아니라 바이너리 손상인지 분기하도록 했다. 동시에 nightly-update 쪽에는 TimeoutStartSec=1800을 넣어 systemd가 느린 설치를 중간에 SIGKILL로 죽여 ENOTEMPTY를 만드는 경로를 줄였다.
검증은 보수적으로 했다. bash 문법, 가드마커 보존, 정상 바이너리 false positive 0을 확인했고, 본진 카나리도 통과했다. 다만 5노드 전체 배포에서는 각 노드의 dirty divergence가 드러나 --ff-only가 안전하게 멈췄다. 이 실패도 의미가 있었다. 배포 도구가 덮어쓰지 않고 멈췄기 때문에, 워커 노드의 작업을 날리지 않았다.
배운 것 — watchdog은 재시작만 잘하면 부족하다. 같은 재시작이 반복될 때는 “대상이 죽은 이유”를 다른 계층에서 다시 물어야 한다.
3. live 세션 중 업데이트는 skip이 정답이었다
오후에는 본진 디렉티브로 T-260626-07을 맡았다. 목표는 nightly auto-update가 부팅 직후 catch-up으로 live Claude/tmux 세션과 충돌하지 않게 하는 것이었다. 조사 결과 활성 업데이트 경로는 nightly-update 하나였고, Persistent=true 때문에 부팅 직후 실행될 수 있었다.
d5a5608은 npm i -g 직전에 두 가지 가드를 넣었다. 부팅 후 grace window 안이면 skip하고, live Claude 세션이나 bridge가 active이면 skip한다. 중요한 점은 복구 경로는 완전히 막지 않았다는 것이다. 이미 깨졌을 때의 health check and clean은 여전히 실행되고, 선택적 npm 업데이트만 live session 뒤로 미룬다.
4. 보고 누락도 운영 버그였다
오후 중반에는 “보고를 여기 채팅방에도 해줘야지”라는 피드백이 들어왔다. 원인은 작업 노드가 완료보고를 원 출처 채팅방에 충분히 미러하지 못하는 구조였다. 84e6e36은 mac-report가 노드 자기 bot chat에도 node report를 미러하도록 고쳤고, 관련 issue가 claude-skills와 공개 사이트에도 동기화됐다.
이어 530f984는 Claude bridge가 긴 작업 turn을 active로 유지하도록 고쳤다. 장시간 작업 중 최종 답변이 누락되면 사용자는 “멈췄냐”로 느낀다. 실제로는 작업이 진행 중이어도, 보고 경로가 끊기면 운영 체감은 실패다.
5. 콘텐츠와 발행도 같이 밀렸다
저녁에는 daejong-page 쪽 작업도 이어졌다. newsletter ep54ep59 초안이 추가됐고, 짧은 회차를 살 붙여 확장했으며, “I asked Claude Code to make me as much money as possible” 인사이트 글도 들어갔다. publish-guard 기록상 ep5459는 homepage, Substack, Naver 발행 마킹이 이어졌고, ep56의 제목 오염도 수정됐다.
코드 운영과 콘텐츠 발행이 같은 날 같이 움직인 것은 우연이 아니다. 5노드 자동화의 목적은 결국 반복 작업을 줄이고, 사람이 신경 써야 할 공개물과 판단 지점으로 시간을 돌려주는 데 있었다.
6. 그래서 뭐가 남았나
이날의 산출물은 명확하다. 자동업데이트 사고는 포렌식으로 남았고, watchdog은 바이너리 손상 티어를 얻었고, nightly-update는 live session과 boot-grace를 보게 됐다. 브릿지는 완료보고와 장시간 turn을 더 안정적으로 다루게 됐다.
남은 것은 fleet divergence 관리였다. 안전한 배포가 dirty 노드에서 멈춘 것은 맞는 동작이지만, 그 상태가 오래 쌓이면 다음 배포 때마다 같은 비용을 치른다. 6월 26일은 사고를 덮은 날이 아니라, 사고가 다시 같은 얼굴로 오지 못하게 표시판을 세운 날이었다.
다음 이야기는 공개 사이트와 브릿지 표면을 다시 맞추고, 자율 워커가 어디까지 혼자 움직일 수 있는지 정하는 이야기.
— 강대종 / @ssamssae