2026.07.22 작업일지 v1.0.0
22:18, 폰에 같은 문자가 또 꽂혔다. “macmini 노드가 T-260722-025 물고 5분째 대기중” — 오후부터 몇 번째인지 세다 말았다. 22:53, 한 줄로 스펙이 끝났다. “cc1 치면 각 노드의 워커로 접속돼서 모니터링되는 세팅을 원한거야.” 23:14, 재설계된 cc1이 머지 도장을 받고 4개 노드에 깔렸다. 스펙 확정부터 21분.
오늘은 낮에 깔아둔 자동화가 밤에 한꺼번에 시험대에 오른 날이다. 아침엔 쿠팡비즈 가입 신청과 토스 비즈니스 콘솔 로그인 정석을 뚫었고, 카톡 발신 스킬(kakao-send)과 네이버 발행 수리, 뉴스레터 ep73~75 초안, 작업일지 3일 백필까지 밑작업이 이어졌다. 그리고 밤이 되자 — 낮에 만든 알람이 스팸이 됐고, 낮에 만든 cc1이 네 노드에서 네 가지 방식으로 죽었고, 애플에서는 리젝 메일이 도착했다.
1. 알람이 스팸이 된 날
13:10에 GO가 떨어진 “일감 물고 노는 노드” 알람(idle-alarm)은 설계 취지가 명확했다 — 워커가 일감을 문 채 조용히 죽어 있으면 아무도 모르니, 그걸 폰에 1줄로 올리자. 문제는 노드 상태가 잠깐 깜빡일 때마다 에피소드가 리셋돼 같은 알람이 계속 재발사됐다는 것. 게다가 내 번호로 내가 보내는 구조라 보낸 문자/받은 문자가 두 줄씩 겹쳐 보였다. 16:03에 한 번, 22:18에 두 번째 지적이 나오고서야 22:23에 off 스위치를 켰다. 원칙 11 그대로 — 켜는 건 사람이 결정하지만, 끄는 건 누구나 즉시. 알람은 집사리모컨 앱 푸시(APNs)로 갈아탄 뒤에만 재가동하기로 했다.
배운 것 — 알림 시스템의 절반은 발송 로직이 아니라 멈춤 장치다. off 스위치 파일 하나가 있었기에 사고가 “짜증”에서 끝났다.
2. cc1, 네 노드에서 네 가지 사인으로 죽다
“4개 노드 전부 안 됨. 근데 오류 문구는 다 다르네” — 이 한 장의 스크린샷이 밤의 두 번째 사건이었다. 실측해 보니 정말로 원인이 전부 달랐다. 라이덴은 명령 자체가 배포 안 됨, 맥미니는 배포됐지만 터미널 PATH가 그 폴더를 안 봄, 데스크탑은 tmux 화면 안에서 쳐서 “화면 속 화면” 중첩 거부, 본진은 자리 세션이 그 순간 꺼져 있었음. 하나의 “안 된다”가 사실은 네 개의 독립된 버그였다.
배운 것 — 같은 명령이 노드마다 다르게 죽으면 원인도 노드 수만큼 있다. “안 됨” 하나로 뭉뚱그리는 순간 버그 네 개가 하나로 위장한다.
3. 스펙은 한 줄이면 충분했다
수습 중에 더 근본적인 어긋남이 드러났다. 원래 요구는 “워커가 일하는지 보는 것”이었는데, 구현된 자리(seat)는 “빈 클로드를 하나 더 켜는 것”이었다. 22:53에 스펙이 한 줄로 확정됐고 — 각 노드에서 cc1 = 자기 노드 워커 화면을 읽기 전용으로 관전 — 라이덴이 곧장 구현했다. 구버전으로 실패 15건을 먼저 재현(RED)하고 신버전으로 테스트 291건 전부 통과(GREEN), tmux switch-client -r이 토글이라 이미 읽기전용인 클라이언트에 쓰기를 열어버리는 함정까지 fixture로 잡았다. 23:14 머지(319a4e0), 4노드 pull, 라이브. 원격 ssh를 아예 없앤 로컬 관전이라 “다른 방에 떨어지는” 문제도 원천 소멸했다.
4. 도구가 거짓말을 잡기 시작했다
데스크탑은 홈페이지 스테일 스캐너를 구조 수리했다(d2e4990). 어제까지 이 도구의 유효 적출은 0건 — 디렉토리 단위 검사라 페이지 하나만 고쳐도 전체가 신선해 보였고, 훅 폴더 오탐에 gitignore 산출물까지 “신규 페이지”로 보고하던 장식품이었다. 수리 5건 중 백미는 갱신일 drift 검출 — 페이지가 스스로 주장하는 갱신일과 git 실제 최종 커밋을 대조한다. 수리된 스캐너의 첫 실행이 곧바로 vibecoding 페이지의 날짜 거짓말(주장 07-07, 실제 오늘 수정)을 적출했고, 정정 머지(c3b4a34) 후 재검사 STALE 0 / UNKNOWN 0 / DRIFT 0. 사람 29면 전수조사가 놓친 것을 도구가 잡는 상태로 넘어왔다.
배운 것 — 도구 수리의 가장 확실한 검증은, 그 도구가 사람이 놓친 결함을 첫 실행에서 잡아내는 순간이다.
5. 애플 심사자는 인증코드를 받지 못했다
23:04, 첫이름 iOS 1.0 리젝 메일. 스샷엔 사유가 잘려 있어 맥미니가 ASC를 직접 판독했다. 1차 리젝(7/17)은 “결제 서버 불능” — 이미 고친 결제검증 버그였고 이번 심사에서 재지적이 없어 해소가 실증됐다. 2차(오늘)는 “결제 인증코드를 받은 적이 없다” — 심사자가 이메일을 입력하고 기다렸지만 코드가 안 왔고, 애플이 빈 인증칸 스크린샷까지 첨부해줬다. 스팸함 문제인가 싶었는데, 발송 로그 전수(6/1~오늘, 44건)를 뒤지니 심사자 주소로 보낸 기록이 아예 없었다. 다른 주소들로는 전부 정상 발송·도달. 즉 요청이 발송 서버까지 오지도 않은 것 — 수리 방향이 “메일 도달률”에서 “앱→서버 구간 절단”으로 정반대로 뒤집혔다. 밤 사이 맥미니가 원인을 소거법으로 좁혔다: 두 번의 심사 모두 심사 시간대에 워커 엣지 도달 요청이 0건(7/17도 7/22도), 반면 앱 설정(심사된 빌드 1.0(2)에 API 주소 실재)·서버(재현 호출 200·정상 발송)·레이트리밋·IPv6·WAF는 전부 반증됐다. 남은 후보는 하나 — 무료 공유 서브도메인(*.workers.dev)이 심사망 필터에 걸려 도달 자체가 막히는 것. 처방은 자사 도메인으로 API를 이전하는 것으로 잡혔다.
배운 것 — “보냈는데 못 받았다”와 “보낸 적이 없다”는 수리 방향이 정반대다. 로그 전수 실측 5분이 그럴듯한 가설 하나를 기각했다.
6. 그래서 뭐가 남았나
본진 머지 게이트로 오늘 밤에만 PR 8건이 닫혔다 — cc1 관전 재설계(#1005), 유령 지시 수리(#1006, 16:03짜리 스테일 지시가 22시까지 생존하던 것), 스캐너 수리(#318)와 그 첫 적출 정정(#345), 은퇴 노드 잔재 정리(#1004), 대기표의 blocking 체크리스트 이관(#319) 등. 라이덴은 지시받은 4건(074·080·056·098)을 완주했고, SoT에는 오늘 하루 T-엔트리 104건이 쌓였다. 열려 있는 것: 첫이름 OTP 미도달 원인 판정, 알람의 앱 푸시 전환, 서브에이전트 뷰어 cc1a, 그리고 [?] 대기표 17건 위생 스윕.
다음 이야기는 API 자사 도메인 이전과 첫이름 3차 제출.
— 강대종 / @ssamssae