이 블로그의 자동 발행 파이프라인, 어떻게 동작하나

이 블로그의 자동 발행은 후보를 큐에 넣고, 결정론적 게이트로 거르고, 사람이 승인할 때만 실제로 내보내는 파이프라인으로, 흐름은 다섯 단계다: ① 후보(글) 생성 → ② 게이트 검사 → ③ 중복 제거 → ④ 사전점검(dry-run) → ⑤ 승인 시에만 발행+원장 기록. 핵심은 모델을 키우는 게 아니라 게이트를 설계하는 것으로, 실제로 이 글도 같은 게이트를 통과해야 나오며 이번 세션에서 관측상 큐의 후보 전부가 게이트를 통과(통과율 100%)하도록 매 글을 맞춰 넣었다(목표 하루 20편).

한 줄 요약: 파이프라인은 공항 보안검색이다. 누구나 줄을 서지만(큐), 금지물품·서류미비는 게이트에서 걸러지고(검사), 최종 탑승은 직원이 확인해야(승인) 이뤄진다.

다섯 단계는 어떻게 흐르나?#

후보 하나가 발행되기까지 다섯 관문을 순서대로 지난다. 각 관문에는 통과 조건이 있고, 못 넘으면 그 자리에서 멈춘다. 아래가 그 흐름이다.

게이트는 무엇을 검사하나?#

형식·밀도·근거·안전을 규칙으로 본다. 결정론적(LLM 판단이 아니라 규칙/정규식) 검사라 같은 입력엔 같은 결과가 나온다. 주요 규칙: 첫 문단이 핵심을 90자 이상으로 답하는 두괄식인가, 비교표가 있는가, 본문이 밀도 하한(측정상 KO 공백제외 약 650자·EN 약 330단어)을 넘는가, 질문형 소제목이 2개 이상인가, 신선도 Note가 있는가. 그리고 안전·근거 검사로 시크릿 스캔(토큰·키·내부주소 차단), 참고 링크 섹션과 실제 링크 200 확인, 단위 숫자엔 '측정/벤치' 같은 근거 라벨이 붙었는지를 본다. 아래가 게이트의 두 갈래 검사다.

왜 결정론적 게이트인가? (그리고 트레이드오프)#

재현성 때문이다. 규칙 기반이라 같은 글은 늘 같은 판정을 받아 디버깅이 쉽고 비용이 싸다(업계도 의미 판단 LLM-judge 전에 결정론 검사를 먼저 둔다). 하지만 트레이드오프가 있다 — 실시간 링크 200 검사는 외부 의존이라 비결정성을 만든다. 봇을 막는 일부 호스트가 자동요청에 403/429를 줘서, 멀쩡한 글이 간헐적으로 탈락한다(이번 세션에도 관측됨). 그래서 운영 회피책은 봇 차단 없는 안정 호스트(GitHub·arxiv 등)를 우선 쓰는 것이고, 근본 개선안(403/429를 '도달 가능'으로 처리)은 별도로 제안해 뒀다.

사람 승인은 왜 여전히 필수인가?#

신뢰와 책임 때문이다. 기본은 dry-run(모의 실행)으로, 큐를 게이트에 통과시켜 '몇 편이 나갈지'만 원장에 적는다. 실제 발행은 명시적 승인 플래그가 있을 때만 일어난다 — 되돌리기 어려운 외부 공개라 사람이 마지막에 확인한다. 아래가 그 두 갈래 결정이다.

업계도 같다: 자동화는 운영(검사·반복)을 맡고, 각도 선택·통찰 같은 창작 판단과 최종 책임은 사람이 쥔다. 규제(투명성 의무) 측면에서도 발행 시점의 인간 책임이 전제된다.

직접 살펴보려면?#

작게, 게이트부터.

• 글을 내기 전 결정론 검사부터 둔다(두괄식·표·밀도·소제목·Note·시크릿·링크).
• 링크 검사는 죽은 링크(404)와 봇 차단(403/429)을 구분하라 — 후자를 죽음으로 보면 멀쩡한 글이 샌다.
• 발행은 기본 dry-run, 실발행은 승인 뒤에. 되돌리기 어려운 행동엔 사람 확인을 둔다.

참고 링크

• FastAPI(서버·SSR 스택)
• SQLite(저장소)
• pytest(검증·회귀 테스트)
• schema.org(구조화 데이터/SEO)
• LLM-as-a-Judge(평가 논문)

참고: 단계·규칙·수치는 2026년 이 블로그 운영 관측과 공개 자료 기준이며 정책에 따라 달라진다(내부 경로·파일·DB·계정은 비공개). 결정론 게이트는 재현되지만 외부 링크 의존이 간헐 오탈락을 만들 수 있고, 실발행은 사람 승인을 전제한다. 파이프라인은 자주 개선되니 분기별로 다시 본다.