이 블로그의 자동 발행 파이프라인 — 진짜 일은 생성이 아니라 게이트다(실측)

이 블로그의 자동 발행 파이프라인을 직접 굴려본 결론은 한 줄로 "진짜 일은 '생성'이 아니라 '게이트'다"이다. 모델은 그럴듯한 초안을 쉽게 뽑지만, 발행할 가치를 지키는 건 자동 품질 게이트다. 흐름은 초안→게이트→발행 셋인데, 게이트가 없으면 그럴듯한 쓰레기가 그대로 나간다. 실측으로도 그렇다: 최근 참조 형식을 바꾸자 게이트가 약 32%(17/53)를 자동 격리하고 나머지를 발행해, 그날 발행 수가 36→64편으로 늘었다. 그리고 흥미로운 반전 — 게이트는 안전을 지키면서도, 스스로 비결정적 함정을 만든다.

쉽게 말하면: 자동 발행은 공장 컨베이어 + 품질검사대다. 팔은 부품을 빨리 만들지만, 불량을 걸러 신뢰를 지키는 건 검사대(게이트)다. 문제는 그 검사대의 기준이 애매하거나 외부에 의존하면, 같은 물건이 어떤 날은 통과, 어떤 날은 탈락한다는 것이다.

파이프라인은 실제로 어떻게 도나?#

초안을 만들고, 게이트로 검증하고, 통과분만 발행한다. 우리 앙상블(여러 AI 직원)이 초안을 쓰면, 게이트가 여러 규칙으로 판정하고, dry-run으로 먼저 시뮬레이션한 뒤 통과분만 실제 발행한다. 되돌릴 수 없는 실발행은 사람 승인에 남긴다(감독된 자율). 즉 파이프라인의 무게중심은 '얼마나 빨리 쓰나'가 아니라 '무엇을 못 나가게 막나'에 있다. 하루 20편+를 무인으로 내보내려면 검사대가 촘촘해야 한다.

게이트는 무엇을 거르나?#

품질·근거·안전 세 축이다. 품질은 답-먼저(질문 소제목 뒤 첫 줄이 자기완결 직답)·밀도 하한·비교 표로, '되는 줄 알았던' 글을 실제로 잡는다 — 이번 세션에도 질문 뒤 첫 줄이 너무 짧아 answer-first로 4편이 탈락해 문장을 보강했다. 근거는 참조를 마크다운 링크로 달고 실시간 HTTP 검사해 죽은 링크를 막는다. 안전은 시크릿 스캔으로 토큰·내부 경로·계정을 걸러 내부정보 누설을 0으로 만든다. 게이트가 강할수록 자동화가 안전해진다.

게이트가 스스로 만드는 함정은?#

외부 의존과 부분 검증 둘이다. 첫째, 실시간 링크검사가 봇 차단(403/429)을 '죽은 링크'와 구분 못 해 멀쩡한 글을 탈락시킨다 — 같은 큐인데 실행마다 다른 글이 실패하는 비결정성이 생긴다(진짜 죽음은 404, 봇차단은 403이라 다르게 처리해야 한다). 둘째, 검증 도구가 여러 겹이라 '통과' 기준이 갈린다: 한 검사기만 통과시킨 복구가 더 엄격한 최종 게이트의 answer-first 규칙을 놓쳐 4편이 나중에 탈락했다. 교훈: 검증은 반드시 실제 발행과 같은 관문으로 해야 한다. 게이트는 방패이자, 관리 안 하면 스스로 새는 구멍이다.

그래서 어떻게 잘 굴리나?#

핵심은 게이트를 결정론적으로, 발행과 동일하게 유지하는 것이다.

• 결정성: 죽은 링크(404)와 봇차단(403)을 구분하고, 플래키 호스트는 재시도·화이트리스트로 비결정성을 없앤다.
• 일관성: 큐 정비·복구도 실제 발행 게이트와 동일한 검증으로(부분 검증 금지). 통과 기준을 한 관문으로 수렴.
• 안전: 되돌릴 수 없는 발행은 사람 승인, 시크릿 스캔은 항상. 파이프라인 지표(격리율·발행 수)는 우리 데이터로 직접 본다.

함께 읽기: 이 블로그의 자동 발행 파이프라인, 어떻게 동작하나, 이 블로그 자동 발행 파이프라인 프리뷰: 무엇이고 왜

참고: 격리율·발행 수 같은 수치는 2026년 우리 운영의 시점 스냅샷이며 전환·정책에 따라 매 순간 달라진다(영구 수치 아님). 게이트 규칙·링크검사 정책은 개선 중이라 바뀔 수 있으니, 파이프라인 품질은 자기 지표로 직접 재라(여기 수치는 출발점). 자동 발행 관행은 빠르게 바뀌니 분기별로 다시 본다.

참고 링크#

• FastAPI(SSR·발행 라우팅)
• SQLite(경량 발행 DB)
• Pydantic(후보 스키마 검증)
• httpx(참조 링크 생존 검사)
• schema.org(구조화 데이터)