29편 쓰고 148일 멈췄다 — 발행은 자동이었는데 글감이 없었다

결과부터 — 29편 쓰고 148일 멈췄다, 뒷단은 이미 자동이었다

이 블로그는 2026년 1월 22일부터 3월 27일까지 29편을 올리고, 그다음 148일 동안 한 편도 올리지 않았습니다. 8월 22일에 다른 프로젝트의 세션이 "블로그가 148일째 조용하다"를 짚어 초안 4편을 만들었고, 그걸 제가 손으로 예약했어요. 오늘 기준으로 공개 30편, 예약 3편(9월 6일·10일·13일, KST 기준)입니다.

멈춰 있던 148일 동안에도 발행 뒷단은 살아 있었습니다. 예약한 날짜가 되면 글을 공개하는 크론(정해진 시각에 저절로 도는 작업)은 3월 25일에, 새로 공개된 글을 구독자에게 메일로 알리는 파이프라인(순서대로 이어 붙인 자동 처리 흐름)은 8월 5일에 만들어져 있었어요. 기계는 있었습니다. 없었던 건 기계에 넣을 글이었습니다.

그래서 오늘 발행 앞단에 그래프를 뒀습니다. 에이전트가 맡는 노드 10개(초기화 제외), 기계 게이트 17종, 사람 체크포인트 2곳 — 일상어로 하면 단계 10개, 기계 검사 17종, 사람이 답해야 넘어가는 지점 2곳입니다. 코드 개발에는 두지 않았습니다. 이 글은 왜 그렇게 나눴는지, 그리고 마지막 발행을 왜 사람에게 남기고 그걸 왜 코드로 강제했는지에 대한 기록입니다.

끊긴 건 기계가 아니라 글감이었다

이 블로그에는 "있는 것처럼 보이는데 비어 있는" 습관이 있었습니다. 6월 29일 일지를 보면, 뉴스레터 구독 폼 컴포넌트는 있는데 사이트 어디에도 배치돼 있지 않았고, 구독 API는 이메일을 받아서 버리고 "성공"만 돌려주는 스텁(껍데기 코드)이었어요. 헤더의 "구독" 버튼은 눌러도 아무 데도 가지 않는 링크였습니다. 그날 저장·배치·관리자 조회까지 한 번에 연결했지만, 그 전까지는 겉만 있었던 겁니다.

블로그 발행도 같은 모양이었습니다. 8월 22일의 진단은 이랬어요 — 예약 발행 기능은 이미 다 만들어져 있고, 문제는 "올리는 기계"가 아니라 "올릴 글감"이 끊긴 것. 1~3월에 29편을 몰아 쓴 건 파이프라인이 아니라 의욕이었고, 의욕이 다른 프로젝트로 옮겨가자 생산도 같이 멈췄습니다. 몰아쓰고 멈추는 패턴은 생산이 사람의 기분에 매달려 있을 때 나옵니다.

글감이 없었던 것도 아닙니다. 3월에 쓴 글은 전부 형제 프로젝트 개발기였고, 그 프로젝트들은 148일 동안 계속 작업일지를 쓰고 있었어요. 프로젝트 기록 저장소의 글감 목록에는 이 블로그를 타깃으로 적어 둔 후보가 36건, 전부 "대기" 상태로 쌓여 있었습니다. 소재는 밖이 아니라 안에 있었고, 그걸 초안까지 끌어오는 손이 없었던 겁니다.

자동화를 어디에 둘 것인가 — 코드엔 안 두고 글 발행에만

먼저 용어 세 개만 풀겠습니다. 그래프는 작업을 정거장처럼 늘어놓고 선으로 이은 지도, 노드는 그 정거장 하나, 게이트는 다음 정거장으로 넘어가도 되는지 기계가 판정하는 문입니다. 게이트가 실패하면 고치는 담당이 정해져 있고, 정해진 횟수 안에 못 고치면 멈추고 사람을 부릅니다.

이 사이트의 코드 개발에는 그래프를 두지 않았습니다. 기능 하나, 코드 정리(리팩터) 하나, 디자인 수정 하나가 전부 다른 작업이라 노드·게이트·수정 루프가 과잉이에요. 코드 쪽은 저장·커밋 때 자동으로 끼어드는 검사(훅) 몇 개면 충분했고, 이미 있었습니다. 건드리면 안 되는 경로를 막고 문법(lint)을 확인하는 것들이에요. 반면 글 발행은 반복 생산입니다. 글감을 고르고, 브리프를 쓰고, 초안을 쓰고, 사실을 대조하고, 검토하고, DB에 넣고, 예약하는 순서가 매번 같아요. 같은 순서를 매번 밟는 일에만 그래프를 뒀습니다.

흐름은 한 줄입니다. 글감 후보 → 브리프(본문을 쓰기 전에 잠그는 계약) → 초안 + 사실 주장 목록 → Codex(다른 회사의 AI 코딩 도구) 교차 사실 대조 / 검토 → DB 초안 → 예약 → 발행. 노드마다 산출물이 파일로 남고, 게이트 17종이 그걸 봅니다. 게이트는 에이전트의 "넣었다"는 보고를 믿지 않아요 — DB를 봐야 하는 게이트는 DB를 직접 두드립니다. 그리고 만드는 에이전트와 검증하는 에이전트를 나눴습니다. 검토자에게는 파일 편집 도구(Write·Edit)를 주지 않았어요. 고치는 건 항상 쓴 쪽입니다.

트리거는 달력이 아니라 신호입니다. 매일 한 번 도는 관측 스크립트가 글 테이블을 읽어, 마지막 발행이 21일을 넘었는데 예약이 0이면 경고를 내고, 초안·예약 편수를 정보로 냅니다. 예약이 2편 아래로 떨어지면 그 신호를 보고 제가 그래프를 돌려요. 예약 2편이면 주 3회(월·수·금) 리듬에서 일주일치도 안 남은 거니까요. 관측 쪽 얘기는 메티스(매일 프로젝트 상태를 훑는 관측 스크립트)를 소개한 지난 글에 따로 적었으니 여기서는 이 한 문단으로 끝냅니다.

마지막 한 번은 사람 — 그리고 그걸 코드로 강제한 이유

8월 22일에 "자동화할까?"를 물었을 때 내린 결정은 '완전 자동 발행은 하지 않는다'였습니다. 이유는 한 줄이에요 — '이 블로그(huns-dev.kr)는 실명을 걸고 신뢰를 쌓는 곳이다.' 초안까지는 기계가 만들어도 되지만, 이 이름으로 내보내는 마지막 결정은 사람이 집니다.

그래서 사람 체크포인트(기계가 멈추고 사람의 답을 기다리는 지점)를 두 곳에 뒀습니다. 글감 선택과 발행 직전. 무엇을 쓸지는 브랜드 결정이라 기계에 맡기지 않고, 공개는 되돌리기 어려우니 마지막에 사람이 봅니다. 초안 승인은 두지 않았어요. 초안 품질은 사실 대조와 검토 게이트가 기계로 판정하고, 대신 발행 직전에 편집기 링크로 전문을 볼 수 있습니다.

- id: schedule
  title: 발행 슬롯 제안 + 최종 승인
  agent: blog-publisher
  needs: [build]
  gate:
    checks: [artifacts-exist, slot-proposal, no-secrets]
    human: true          # 사람 승인 없이는 다음 노드로 못 간다

그런데 처음 만든 그래프에서 이 결정은 절차였습니다. 위처럼 "이 노드는 사람 승인 필요"라고 적혀 있고, 러너(그래프를 읽고 실행하는 Claude)가 그걸 지키기로 돼 있을 뿐이었어요. 같은 날 아침 Codex에게 이 그래프에 대한 주장 14건을 반증시켰더니, 그중 하나가 이거였습니다 — 발행 도구가 사람 승인을 검사하지 않는다. 러너가 게을러지거나 착각하면 사람 없이 발행될 수 있다는 뜻이에요.

고친 방식은 이렇습니다. 발행 도구의 --publish 옵션은 실행 상태 파일(state.json)에 사람 승인 기록이 있고, 거기 적힌 승인한 발행 날짜(슬롯)가 --date로 넘긴 날짜와 정확히 같을 때만 DB를 씁니다. 기록이 없으면 멈추고, 날짜가 다르면 "사람이 본 것과 다른 날짜로 쓰지 않는다"며 멈춰요. 승인 기록은 러너가 사람의 답을 받은 뒤에 씁니다. 절차가 아니라 데이터가 문입니다. 이 글은 그 그래프로 쓴 첫 글들 중 하나입니다.

자동화는 잘 돌아가는 곳이 아니라 끊긴 곳에 둬야 합니다. 그리고 실명으로 내보내는 마지막 한 번은 사람에게 남기되, "사람이 봐야 한다"는 절차가 아니라 승인 기록이 없으면 코드가 쓰지 못하도록 데이터로 강제해야 합니다.