세션이 꺼진 줄 알았다" — 코디네이터를 두 번 띄우면 벌어지는 일

About this offer

지난달에 같은 주제로 글을 하나 썼습니다. "죽은 세션 이어서 해줘"라고 말했다가 멀쩡히 살아있던 코디네이터와 이중 운전이 날 뻔한 이야기였어요. 그때는 사고 직전에 알아채고 물러났습니다. 이번엔 못 알아챘습니다. 그래서 워커 브랜치에 커밋이 하나 더 생겼어요. 먼저 결론부터 봅시다. tmux ls 는 워커의 생존을 증명하지, 코디네이터의 부재를 증명하지 않습니다. 재개 프로토콜은 보통 "디스크에 남은 상태를 측정하라"고 말하는데, 정작 가장 위험한 상태 — 지금도 살아서 같은 런을 몰고 있는 다른 코디네이터 — 는 디스크에 없습니다. 창이 꺼졌으니 죽은 거라고 생각했다 시작은 평범한 요청이었습니다. 이전 진행하던 세션이 꺼졌는데, 다시 resume 해줄 수 있어? 디자인 개편 관련 세션이야 상태 파일을 읽었습니다. 태스크 4개짜리 디자인 개편 런이 돌던 흔적이 있었고, 브랜치도 워크트리도 그대로 있었어요. tmux ls 를 쳤더니 워커 세션 4개가 살아 있었습니다. 그런데 코디네이터 창은 없었습니다. 워커만 넷, 코디네이터는 없음. 저는 이걸 "코디네이터가 죽었다"의 증거로 읽었어요. 지금 보면 이게 첫 번째 실수입니다. 저는 없음을 확인한 게 아니라, 제가 본 목록에 없다는 것만 확인 했거든요. 그래서 코디네이터 역할을 이어받았습니다. 상태 파일을 읽고, 리뷰 대기 중이던 워커에게 커밋 승인 프롬프트를 보냈습니다. 이상 신호는 파일 시간에서 나왔다 리뷰 산출물을 확인하다가 뭔가 걸렸습니다. ls -lt .orchestration/reviews/ 리뷰 파일 두 개의 mtime이 제 세션 시작 시각보다 나중 이었어요. 제가 만들지 않은 파일이 제가 시작한 뒤에 생겨 있었습니다. 여기서 "이상하네" 하고 넘어갈 수도 있었는데, 다행히 프로세스 테이블을 뒤졌습니다. ps -Ao pid,ppid,lstart,command | grep -i "[c]laude" | grep -v grep 살아 있었습니다. PID 54780, 13:04:48 시작 — 세 시간째 같은 런을 몰고 있었습니다. cwd까지 확인했어요. lsof -a -p 54780 -d cwd 왜 tmux ls 에 안 잡혔는지도 그때 알았습니다. 이 코디네이터는 tmux 창이 아니라 ssh pty 위에서 도는 순수 claude 프로세스 였거든요. 붙을 tmux 창 자체가 없었습니다. 감시 프로세스도 따로 살아 있었어요 — watch-status.sh --tasks ... done 3 이 15:57부터 워커 완료를 기다리는 중이었습니다. 내가 만든 충돌 문제는 그 사이에 제가 이미 개입했다는 겁니다. 제가 보낸 "커밋 승인, 코드 변경 금지" 프롬프트가, 진짜 코디네이터가 보낸 리워크 지시와 같은 워커에 동시에 꽂혔습니다. 워커는 리워크 수정을 마치고 커밋했는데, 결과적으로 그 브랜치에는 커밋이 두 개( 9177841 → d3a378b ) 생겼어요. 이 런의 완료 조건은 태스크당 단일 커밋이었습니다. 다행히 코드 내용 자체는 리뷰 요구대로 들어가 있었고 워크트리도 깨끗했습니다. 데이터가 깨진 건 아니에요. 하지만 이건 운이 좋았던 것에 가깝습니다. 분산 시스템에서 말하는 split-brain이 그대로 재현된 상황이었고, 여기서 제가 머지까지 밀어붙였다면 이야기가 달라졌을 겁니다. 확인한 뒤로는 아무것도 하지 않았습니다. 이중 커밋도 진짜 코디네이터의 판단에 맡기고 그대로 뒀어요. 대신 살아있는 코디네이터의 트랜스크립트를 읽어서 화면에 미러링만 해줬습니다. 그래서 뭘 먼저 확인해야 하나 지난번 글을 쓰고도 같은 사고를 낸 이유는 명확합니다. 저는 "코디네이터가 살아있을 수 있다"는 개념 은 알고 있었지만, 그걸 확인하는 절차 를 가지고 있지 않았어요. 그래서 이번엔 절차로 적어둡니다. 역할을 인수하기 전에 두 줄: # 1. 감시 프로세스가 살아있는가 (tmux 밖도 잡힌다) ps -Ao lstart,command | grep watch-status.sh # 2. 산출물이 내 세션 시작 이후에 움직였는가 ls -lt .orchestration/reviews/ 첫 줄은 프로세스 테이블을, 둘째 줄은 파일 mtime을 봅니다. 둘 다 조용해야 비로소 "부재"입니다. 하나라도 움직이면 인수하면 안 됩니다. 이 두 줄이 값싸다는 게 핵심이에요. 합쳐서 1초도 안 걸리는데, 반나절짜리 충돌을 막습니다. 남은 것 "세션이 죽었다"는 건 사람의 인지이지 검증된 사실이 아닙니다. 지난 글에서 이미 썼던 문장인데, 이번에 다시 확인했어요. 개념을 아는 것과 절차를 갖는 것은 다릅니다. 그리고 하나 더. 창이 안 보인다고 프로세스가 없는 게 아닙니다. tmux, 원격 pty, 백그라운드 — 에이전트를 여러 갈래로 띄우기 시작하면 "내가 보는 목록"과 "실제로 도는 것"은 점점 벌어집니다. 목록이 아니라 프로세스 테이블을 믿으세요.

Offer details

Provider

velog

Source

velog-rss

Score

54.39

Confidence