2026.06.24 작업일지 v1.0.0
00:27, Codex auto-worker는 먼저 권한 슬롯을 받고 움직이도록 바뀌었다. 09:43, watchdog의 잘못된 route 판단이 실제 세션 재생성 사고로 번졌다. 23:44, Mac Claude tmux wrapper가 launchd에 고정되며 브릿지 이관 우산 task가 닫혔다.
6월 24일은 자동화를 더 많이 켠 날이 아니라, 자동화가 어디까지 움직여도 되는지 다시 묶은 날이었다. 전날까지의 브릿지 cutover는 실제 5노드 운영으로 확장됐고, Topology v3는 작업자가 임의로 밀어붙이지 못하도록 슬롯과 lease를 더 촘촘하게 만들었다. 동시에 초소와 공개 브릿지 패키지는 사용자가 보는 표면을 계속 다듬었다.
1. 먼저 권한을 받고, 그다음에 움직인다
새벽 첫 축은 Topology v3였다. f54ef3d는 Codex auto-worker가 tmux 주입 전에 current-task와 executor slot을 받도록 만들었고, 479b92f는 main push와 일반 branch push를 분리했다. main과 release 계열은 여전히 merge slot 영역에 남기고, 작업 브랜치 push만 executor slot으로 허용한 것이다.
그 뒤에는 task lease mutation을 todo SoT와 동기화하고, build/deploy slot 정책을 문서화했다. 방향은 단순했다. 노드가 빠르게 일하더라도, 어떤 작업을 어떤 권한으로 하고 있는지는 남아야 했다.
배운 것 — 자동화의 속도는 권한 경계를 흐리면 바로 부채가 된다. 빠른 노드일수록 먼저 lease를 받아야 한다.
2. 브릿지는 운영으로 올라가며 한 번 넘어졌다
Claude Telegram Bridge는 코드가 아니라 운영의 문제로 이동했다. 7db35d4는 node setup과 watchdog deploy를 넣었고, 이후 WSL-first, Mac-last 순서로 5노드 cutover가 진행됐다. 09:58에는 readiness가 GO=5 BLOCK=0 ERROR=0까지 올라왔다.
하지만 그 전에 중요한 사고가 있었다. 09:43, watchdog health-check가 기본 소켓의 claude 세션을 잘못 찾으면서 여러 노드에서 route escalation이 발생했고, 일부 Claude 세션이 재생성됐다. 대응은 watchdog을 즉시 멈추고 counter를 reset한 뒤, tmux target resolver와 node-setup 템플릿을 고치는 쪽으로 갔다. PR #177과 #178이 그 후속이다.
이날의 결론은 “카나리 통과”만으로는 부족하다는 것이었다. watchdog, launchd, systemd, tmux socket, session sidecar가 같은 대상을 보고 있는지까지 맞아야 실제 운영이다.
3. 출시 버튼은 자동화 밖에 붙잡아뒀다
오후에는 App Store Connect release-hold-gate도 실제 런타임으로 들어갔다. 0ba840d는 Python selector, launchd plist, import 지연을 포함한 런타임 안정화 패치였고, 16:00에는 macmini launchd가 모든 앱 대상으로 활성화됐다.
검증은 보수적으로 했다. releaseType=MANUAL, AFTER_APPROVAL 없음, 초기 실행에서 PENDING_DEVELOPER_RELEASE 없음, watcher help와 bad Python failure까지 확인했다. 목적은 출시를 자동으로 해버리는 것이 아니라, 출시 직전 상태를 감시하고 수동 release 원칙을 지키는 것이었다.
4. 텔레그램 브릿지는 계속 표면을 고쳤다
사용자 표면에서는 Codex와 Claude 브릿지가 같이 바빠졌다. Codex 쪽은 generic document media 입력을 처리해 v0.3.17로 공개했고, /goal과 상세스펙을 복붙용 두 통으로 보내는 흐름을 여러 차례 보강했다. v0.3.18부터 v0.3.23까지는 copy-payload가 reasoning mirror로 오분류되거나, 중복 전송되거나, 한 통만 나가는 문제를 계속 좁힌 결과였다.
Claude 쪽도 같은 방향으로 맞췄다. media input 지원, approval_wait stale scrollback 오판 방지, copy-payload dedup이 들어갔고, 5노드 배포와 GitHub release까지 따라갔다. 별도로 e3fd2cb는 Codex review-router를 추가해 Claude review-router의 prefer/fallback/busy-check 패턴을 Codex-main 라우팅에도 이식했다.
배운 것 — 브릿지 품질은 모델 답변 품질만이 아니다. 한 통으로 보낼지, 두 통으로 나눌지, 어디에 미러링할지 같은 작은 표면이 실제 사용감을 결정한다.
5. 노드보고는 읽기 쉬운 한 줄로 줄었다
저녁에는 노드보고 미러도 정리됐다. PR #183은 mac-report에 summary mirror mode와 durable node-report log를 넣었다. 실제 canary에서는 mac-mini tmux delivery, group summary hash, DM suppression, fallback 경로를 확인했다. 기본값은 legacy로 남겨두고, summary mode만 canary로 열었다.
이어 PR #184는 engine identity를 붙였다. MAC_REPORT_ENGINE을 우선하고, summary에 engine=codex|claude|unknown을 넣었다. 이렇게 해야 “어느 노드가 말했다”와 “어느 엔진이 실행했다”를 섞지 않는다. 5노드 targeted sync와 release까지 끝나면서 노드보고는 다음 단계로 넘어갈 준비가 됐다.
6. 초소도 숫자를 정확히 보여줘야 했다
초소에서는 Codex 주간 사용량과 reset time 표시가 이어졌다. stale usage를 숨기고, 명시적 tmux socket에서 usage를 캡처하고, weekly reset time을 파싱했다. 헤더에 있던 worker toggle도 숨겼다. 운영 화면은 기능을 많이 넣는 곳이 아니라, 지금 믿을 수 있는 정보만 남기는 곳이어야 했다.
같은 repo 바깥에서는 daejong-page에 6월 22일과 23일 작업일지도 backfill됐다. 정작 24일 기록은 남지 않았고, 이 파일이 그 빈칸을 메운다.
7. 그래서 뭐가 남았나
이날의 산출물은 많았다. Claude bridge는 5노드 readiness를 통과했고, Codex bridge는 media/progress/typing/copy-payload 공개 release를 이어갔고, ASC release-hold-gate는 실제 launchd 감시로 올라갔다. Topology v3는 노드가 움직이기 전에 권한을 먼저 받는 방향으로 더 단단해졌다.
남은 것은 더 많은 자동화가 아니라 더 덜 위험한 자동화다. 공개 repo로 내보낼 것, release를 언제 끊을 것, summary mode를 언제 기본값으로 바꿀 것, 이런 결정은 계속 gate를 지나야 한다.
다음 이야기는 게이트가 있는 자율 작업과 5노드 상태판을 다시 손보는 이야기.
— 강대종 / @ssamssae