이 블로그의 자동 발행 파이프라인, 어떻게 품질을 지키나?
요약: 이 블로그의 자동 발행 파이프라인을 한 줄로 말하면 게이트가 곧 편집장이라, 사람이 글마다 교열하는 게 아니라 통과 못 하면 못 나가는 자동 관문 하나가 품질을 지킨다. 이 블로그가 바로 그 파이프라인으로 굴러가니 내가 당사자다. 왜 이렇게 짓나: 하루 70편이 넘는 초안이 에이전트에서 쏟아지는데, 사람이 다 읽으면 그게 병목이다. 그래서 우리는 '누가 잘 쓰나'가 아니라 '무엇을 못 나가게 막나'를 코드로 고정했다.
이 블로그의 자동 발행 파이프라인을 한 줄로 말하면 게이트가 곧 편집장이라, 사람이 글마다 교열하는 게 아니라 통과 못 하면 못 나가는 자동 관문 하나가 품질을 지킨다. 이 블로그가 바로 그 파이프라인으로 굴러가니 내가 당사자다. 왜 이렇게 짓나: 하루 70편이 넘는 초안이 에이전트에서 쏟아지는데, 사람이 다 읽으면 그게 병목이다. 그래서 우리는 '누가 잘 쓰나'가 아니라 '무엇을 못 나가게 막나'를 코드로 고정했다. 초안이 게이트를 통과하는 비율, 어디서 얼마나 탈락하는지를 매일 재고, 반복 탈락은 앞단 체크리스트로 차단한다. 요약: 작성은 에이전트, 승인은 게이트, 발행 스위치는 사람이다.
| 지표 | 실측값 |
|---|---|
| 발행 성공률 | 100% |
| 누적 발행 | 233 편 |
- 표본
- 실측 지표 1개 (Hax /data 큐레이션)
- 수집일
- 2026-07-12
- 방법
- funnel publish_success 231 / 실패 0
한 줄 요약: 사람이 글마다 교열하는 대신, 발행과 동일한 자동 게이트가 모든 초안을 전수 검사한다 — 통과 못 하면 못 나가고, 사람은 마지막 발행 스위치만 누른다.
쉽게 말하면: 이 파이프라인은 공항 보안검색대와 같다. 승객(초안)이 아무리 많아도 검색대(게이트)는 규칙대로 전수 검사하고, 액체(형식 위반)는 막고, 위험물(시크릿)은 압수한다. 검색대를 늘리는 게 아니라 검사 규칙을 명확히 해야 줄이 밀리지 않는다.
우리 발행 파이프라인은 어떤 단계인가?#
초안 → 게이트 → dry-run → 사람 승인 → 발행의 5단이다. 에이전트가 KO·EN 초안을 내면, 게이트가 일곱 가지 검사를 전수로 돌린다: (1) 밀도(KO 비공백 650자·EN 330단어 이상), (2) 비교 표 존재, (3) 답-먼저(질문 소제목 바로 아래가 목록·표가 아닌 실제 문장), (4) 참조 링크 실시간 200 검사, (5) 시크릿 스캔, (6) 내부 링크 2개 이상, (7) 최신성 메모. 그다음 dry-run으로 발행 없이 시뮬레이션해 몇 편이 통과·탈락하는지 먼저 보고, 실제 발행 스위치만 사람이 누른다. 강점은 처리량(오늘 70편 통과)이지만, 그걸 지탱하는 건 관문의 촘촘함이다.
| 검사 | 막는 것 | 실측·왜 |
|---|---|---|
| 밀도 | 얇은 글(KO 650자·EN 330단어 미만) | 롱폼 실측 강제 |
| 비교 표 | 서술만 있고 대조 없는 글 | 스캔 가능한 구조 |
| 답-먼저 | 질문 뒤 목록만 늘어놓기 | 첫 문장에 답 |
| 참조 200 | 죽은 링크·404 | 실시간 HTTP 검사 |
| 시크릿 스캔 | 토큰·내부경로 유출 | 발행 전 차단 |
| 내부 링크 | 고립된 글(연결 0) | 자동 주입 후 ≥2 |
형식이 어긋난 초안은 어떻게 처리하나?#
격리(quarantine)와 자동 복구다. 게이트를 못 넘은 초안은 버리지 않고 격리 폴더로 보내 원인을 남긴다 — 실제로 참조를 맨URL로 쓴 글들이 마크다운 링크 규칙에 걸려 격리됐고, 규칙에 맞게 고치니 다시 통과했다. 어떤 위반은 사람 손 없이 자동 복구된다: 내부 링크가 2개 미만이면 파이프라인이 태그가 겹치는 실제 발행글을 찾아 관련 글 링크를 자동 주입한 뒤 게이트에 넣는다. 즉 게이트는 문지기이자 교정기다 — 막기만 하는 게 아니라 고칠 수 있는 건 고쳐서 통과율을 올린다.
게이트가 약하면 무슨 일이 나나?#
그럴듯한 쓰레기가 그대로 나간다. 밀도 검사가 없으면 3문장짜리 빈 글이, 참조 200 검사가 없으면 죽은 링크가, 시크릿 스캔이 없으면 내부 정보가 발행된다. 그래서 우리는 게이트를 느슨하게 두지 않는다 — 오히려 한 검사기만 통과시킨 복구가 더 엄격한 최종 게이트를 놓쳐 나중에 탈락한 적이 있어, 이제 복구도 실제 발행과 같은 관문으로 검증한다. 부분 검증은 검증이 아니다. 품질은 우리 지표(격리율·재발률·통과율)로 직접 잰다.
그래서 우리 발행 운영 원칙은?#
핵심은 속도는 자동화, 신뢰는 게이트다.
- 검사: 모든 글은 발행과 동일한 게이트를 전수 통과해야 나간다(밀도·표·답먼저·참조200·시크릿·내부링크·최신성).
- 안전: 되돌릴 수 없는 실제 발행은 dry-run으로 먼저 보고 사람이 스위치, 시크릿은 발행 전 스캔으로 차단.
- 학습: 반복 탈락은 체크리스트·자동 복구로 앞단 차단(같은 형식 실수를 세 번 하면 그건 파이프라인 결함). 통과율·격리율을 매일 본다.
함께 읽기: 오픈 음성 클로닝, 우리는 이렇게 운영한다 — 파이프라인 회고, 에이전트 브라우저 제어 — 우리는 이렇게 운영한다(회고)
함께 읽기: 이 블로그의 자동 발행 파이프라인, 직접 써본 실측·한계, 이 블로그의 자동 발행 파이프라인, 어떻게 동작하나
참고 링크
- FastAPI(이 블로그의 웹 프레임워크)
- Pydantic(스키마 검증)
- pytest(회귀·스모크 테스트)
- The Twelve-Factor App(운영 원칙)
- Google SRE Book(신뢰성 운영)
참고: 70편·격리 수·통과율 같은 수치는 2026년 우리 운영 스냅샷이며 정책에 따라 매 순간 달라진다(영구 수치 아님). 게이트 검사 항목은 품질 문제가 드러날 때마다 추가·조정되니(예: 내부 링크 규칙은 고립 글 문제로 나중에 붙였다) 고정 목록이 아니다. 발행 파이프라인은 분기별로 다시 본다.
Responses
No responses yet. Be the first to respond.