2026.06.21 작업일지 v1.0.2
00:30, idempotent guard 우산 task를 더 쪼개야 하는지 3패스 리뷰가 시작됐다. 16:18, MCP watchdog은 넓어졌지만 동시에 버려야 할 축도 드러났다. 00:53, Claude Telegram Bridge v1이 PR #163으로 머지됐다.
6월 21일은 하루가 두 번 기록될 만큼 길었다. 새벽에는 task 쪼개기와 Claude 리뷰 라우터, 무무 v2 실기기 검증, 인사이트 발행이 이어졌다. 후반에는 공개 운영면, MCP watchdog, Codex-only 브릿지, Claude Telegram Bridge v1이 한 줄로 연결됐다. 그래서 두 개로 갈라져 있던 작업일지를 하나의 합본으로 정리한다.
1. 긴 task는 상태가 갈라지는 순간 쪼갠다
T-260617-01은 idempotent-step-guard 우산 task였다. 본진 observe-canary는 이미 시작됐지만, block 모드와 5노드 rollout은 남아 있었다. 한 task 안에 관찰, 구현, 배포, ack 조건이 섞이자 더 이상 읽기 어려워졌다.
그래서 todo skill에 task 쪼개기 기준을 넣었다. 완료조건, 상태, 담당 노드, ack 필요 여부가 갈라지면 정상 신규 ID로 분리한다. [o]는 관찰 상태로 정본화했고, Codex adapter manifest도 갱신했다. 5노드에는 Claude todo skill과 Codex adapter가 함께 반영됐다.
2. Claude 리뷰 요청은 한 번만 안전하게 옮긴다
Claude 리뷰 요청이 본진에서 막히면 수동으로 노트북 Claude에 fallback을 보내야 했다. T-260621-04는 이 흐름을 thin CLI로 정리하는 작업이었다. 노트북 Claude 1-pass 리뷰는 조건부 GO를 냈다. 신규 데몬 금지, 명시 호출만 허용, fallback은 최대 1개, task_id dedup, 양쪽 busy면 held 보고.
맥미니는 그 조건에 맞춰 claude-review-router.sh와 테스트를 만들었다. PR #160이 열렸고, 이후 본진에서 ca4c6a1까지 정리되어 5노드 배포와 테스트가 끝났다.
배운 것 — 리뷰 라우팅은 자동 fan-out이 아니라, 실패한 한 요청을 안전하게 한 번 옮기는 문제다.
3. 무무 v2는 기술 성공, 품질 실패였다
한줄일기 무무 v2는 데스크탑에서 재학습되고 PR #34로 올라왔다. 맥미니는 iPhone에 release 빌드를 설치했고, 실제 무무 버튼 재생까지 확인했다. 설치와 실행은 성공이었다.
하지만 청취 결과는 REJECT였다. v2 length scale 1.3보다 기존 e149 baseline의 품질이 더 좋았다. 그래서 PR #34는 머지하지 않았고, task는 관찰/대기 상태로 내려갔다. 이 판단은 자동 테스트로 대체할 수 없는 영역이었다.
4. 공개 운영면을 실제 상태에 맞췄다
오전에는 daejong-page 쪽 정리가 이어졌다. 제품 페이지, 로컬 제품 헤더, 10노드 fleet standard, 정책 데이터 재생성, 뉴스레터 ep52/ep53, system 페이지 update가 PR #219부터 #226까지 올라갔다. Codex 200달러, Claude 100달러라는 실제 결제 전제도 공개 운영 설명과 내부 가드에 반영됐다.
이 작업은 단순 문서 정리가 아니었다. Codex는 기본 실행 엔진이고, Claude는 planner/reviewer/gatekeeper 쪽으로 내려간다. 이 전제가 사이트, task, skill, 자동화 문구에 같은 방향으로 박혀야 했다.
5. MCP watchdog은 한계를 드러냈다
오후에는 Telegram MCP 끊김 대응이 중심이었다. telegram-poll-watchdog.sh는 MCP 일반 재연결 쪽으로 확장됐고, mcp-reconnect-all-failed.sh와 PATH helper도 들어갔다. 하지만 실측 결과가 중요했다. Playwright MCP는 상주 프로세스가 아니었고, pgrep 기반 생사 판단은 idle 세션에서 오발할 수 있었다.
그래서 결론은 더 분명해졌다. MCP를 더 세게 때려서 살리는 방향이 아니라, 텔레그램 브릿지 자체를 MCP 의존에서 분리해야 한다. Codex 브릿지는 Codex 전용으로 좁히고, Claude는 Claude 전용 브릿지로 따로 간다. 이 분리는 기능 축소가 아니라 운영 안전장치다.
배운 것 — 죽은 프로세스를 다시 띄우는 것과 세션이 실제로 다시 연결되는 것은 같은 문제가 아니다.
6. Claude Telegram Bridge v1이 들어왔다
밤에는 Claude Telegram Bridge v1 spec이 만들어지고, 이어 PR #163이 머지됐다. 중간에 리뷰 블로커가 있었다. idle 세션 ack, stale injection 방지, retry race, bot inventory, 빌드 검증이 걸렸다. 작업 받음 ack와 10-bot inventory가 추가됐고, round2 race 수정까지 끝난 뒤 72ec8bd로 머지됐다.
다만 이것은 daemon을 바로 켠다는 뜻은 아니다. PR 머지는 코드와 구조의 승격이고, canary와 실제 enable은 별도 GO가 필요하다. 오늘은 MCP를 대체할 Claude 브릿지 축이 코드베이스에 들어온 날로 보는 게 정확하다.
7. 그래서 뭐가 남았나
오늘 남은 것은 세 가지다. 긴 task는 상태가 갈라지면 쪼갠다. Codex 브릿지는 Codex 전용으로 유지한다. Claude 브릿지는 별도 제품처럼 키운다. MCP는 핵심 통신 경로가 아니라 보조 도구로 낮춘다.
새 이슈나 새 메모리로 더 박을 내용은 줄였다. 오늘의 핵심은 더 많이 자동화한 것이 아니라, 어디를 분리해야 오래 버티는지 확인한 것이다.
다음 이야기는 Claude 브릿지를 실제 canary로 켜고, 끊김의 원인을 MCP 바깥으로 밀어내는 이야기.
— 강대종 / @ssamssae