← 작업일지

2026-07-17 · v1.0.0

2026.07.17 작업일지 v1.0.0

07:49, 5노드 함대에서 한 대를 떠나보내기로 확정했다. 16:22, 방금 켠 자동실행 루프가 첫 판부터 비용 한도에 걸려 멈춰 섰다. 17:44, 리젝 맞았던 첫이름이 다시 심사대에 올라갔다.

앱 두 개가 나란히 애플 리젝을 맞은 날이자, 결제 파이프라인을 열어 배관을 갈아낸 날이자, 야심차게 켠 자동화가 켜자마자 전부 멈춰서 그 원인을 밤까지 추적한 날. 오늘 하루에 머지된 PR만 다섯 개다.

1. 함대가 한 척 줄었다

아침에 노트북(RTX 3060) 노드를 은퇴시키기로 확정했다. 5노드에서 4노드 체제로. 낮에 mesh 라우팅에서 노트북 경로를 retired 처리하는 커밋(a0873ac)이 먼저 들어갔고, 저녁엔 실제로 포맷까지 마쳤다 — 팔 준비 끝. 남은 세 노드(라이덴·맥미니·데스크탑)에 은퇴 사실을 전파해서 각자 로컬 기록에 박게 했고, 세 노드 모두 “기록 완료” 보고가 돌아왔다. 이제 어떤 스윕도 “노트북은 다음에 켜지면 따라온다”며 기다리지 않는다. 노트북에 물려 있던 텔레그램 봇 토큰을 재활용하자는 아이디어도 나왔지만, 아직 라우팅 정책에 물려 있는 데다 알림용 봇은 “털려도 허위 알림이 최대 피해”인 전용 새 봇이어야 한다는 원칙으로 기각.

2. 첫이름 배관 대수술 — 감사가 찾은 구멍들

첫이름(AI 작명 서비스)의 결제 파이프라인을 하루 종일 수술했다. 시작은 결제 권한 부여가 원자적이지 않다는 발견(T-044). 그 김에 워커의 D1 다중쓰기 전체를 감사로 훑었더니(T-045) 주문·배송 파이프라인의 고착 지점이 더 나왔고, 큐 소비자가 실패를 삼키던 경로를 fail-loud로 갈아냈다(T-046).

저녁엔 그물을 두 겹 쳤다. 첫 번째 그물은 PR#62 — 10분 주기 Cron이 30분 넘게 paid/processing에 고착된 주문을 찾아 전용 단방향 봇으로 선제 통보한다. 주문별 claim을 INSERT ... ON CONFLICT DO NOTHING으로 선점해서 겹친 Cron이 중복 발사하지 못하게 막았다. 두 번째 그물은 PR#63 — 결과메일이 “고칠 수 없는 설정 오류”(잘못된 Reply-To, 재시도 불가한 4xx)를 만나면 무한 재시도 대신 운영 알림을 쏘고 종료하도록 delivered/retry/config_error 삼분류를 넣었다. 둘 다 테스트 스위트 전건 통과를 본진에서 독립 재검증한 뒤 머지. 리뷰 중에 “알림 채널 자체가 죽어 있으면 완전히 조용해지는 창”을 하나 찾아서 후속 과제로 등재해 뒀다.

3. 리젝 두 장에 답장 두 개

첫이름 iOS는 구독 IAP를 심사에 같이 담지 않았다는 사유(2.1(b))로 리젝. 구독 상세를 버전 제출에 동반시켜 17:44에 재제출했다 — 버전 + IAP 2개 항목, 현재 심사 대기. 로그인은 패스키와 일회용 코드로 통과했는데, 브릿지가 10분 전 코드를 중복 재주입하는 해프닝에도 세션이 “이미 쓴 코드”라고 스스로 판별하고 넘어갔다.

메모요는 1.0.13이 “iPad에서 글자가 안 보인다”로 리젝. 원인은 라이트 테마 도입 때 설정·온보딩 화면에 남은 다크 전용 하드코딩 색 — 리뷰어 스크린샷과 같은 조건(1640×2360, 시스템 라이트)으로 위젯 테스트를 돌리니 글자 대비율이 1.06:1로 찍혔다. 4.5:1이 최소 기준이니 사실상 투명 글자였던 셈. 테마 의미색(onSurface 계열)으로 갈아내고 대비율 회귀 테스트를 심은 PR#91(+164/−64)을 머지, 1.0.14 재제출 준비까지 마쳤다.

4. 켜자마자 전멸한 자동실행 — 범인은 계수기였다

텔레그램 브릿지의 추천답변 자동실행 루프를 본진 외 3노드로 확대한 게 16:20. 그런데 16:22:26, 라이덴의 첫 카드부터 비용 한도(cost_cap)에 걸려 홀드됐다. 데스크탑 원장은 더 기묘했다:

iter=2  cost=730,925
iter=3  cost=1,100,387
iter=4  cost=1,470,317   ← 매 반복 +약 37만, 캡은 100,000

캡을 올리면 되나? 아니었다. 코드를 열어 보니 비용 계수기가 *_tokens로 끝나는 usage 키를 전부 합산하고 있었다 — 답변 생성분만이 아니라, 매 턴 대화 맥락을 통째로 다시 읽는 캐시 재읽기(턴당 수십만 토큰)까지 요금처럼 더한 것. 반증 산수도 깔끔했다: 계수기의 대체 경로(답변 글자수÷4)는 이론상 최대 4,000이라 캡 100,000에 닿을 수 없다. 즉 폭주한 건 usage 합산 경로 하나뿐. 답변 스케일(output_tokens)만 세도록 고친 PR#874가 회귀 테스트 5종과 브릿지 테스트 321개 전건 통과로 착지했고, 18:24에 머지돼 자동배포 레일을 타는 중이다. 멈춰 세운 킬 스위치의 해제는 수리가 각 노드에 내려앉은 뒤의 결정으로 남겨뒀다.

배운 것 — 계수기는 단위가 계약이다. 캡과 계수의 단위가 어긋나 있으면 캡을 아무리 올려도 문제는 그대로다.

배운 것 — 리뷰어의 리젝 스크린샷 조건(해상도·모드)을 그대로 테스트로 옮겨 심으면, 같은 리젝은 두 번 오지 않는다.

5. 그래서 뭐가 남았나

머지 5건(#62·#63·#91·#873·#874), 자동화 저장소 커밋 35개. 첫이름은 재심사 대기 중이고 심사 상태가 바뀌면 알려줄 감시 데몬도 걸어뒀다. 메모요 1.0.14는 장전 완료. 함대는 4노드 체제로 홀쭉해졌지만, 결제 파이프라인엔 그물이 두 겹 생겼고 자동실행 루프는 제 계수기를 되찾았다.


다음 이야기는 7/18 요금제 대이동 이야기.

— 강대종 / @ssamssae