블로그 자동화 시스템을 구축하면서 제가 마주한 가장 큰 딜레마는 '완전 자동화'의 위험성이었습니다. 스크립트가 스스로 원고를 작성하고 이미지를 생성한 뒤 곧바로 라이브 서버에 발행(Publish)하도록 놔두었더니, 잘못된 내용이나 깨진 이미지가 그대로 독자들에게 노출되는 대형 사고가 빈번하게 발생했습니다.
자동화의 편리함을 누리면서도 품질을 통제할 수 있는 중간 점검 단계가 절실했습니다. 이를 해결하기 위해 파이썬(Python) 기반의 상태 관리 로직과 JSON 리포트 시스템을 도입한 과정을 공유합니다.
Dry-run: 발행 전 모의 실행 단계의 도입
가장 먼저 취한 조치는 스크립트 실행 모드를 두 가지로 분리하는 것이었습니다. 실제 티스토리 서버에 반영하는 publish 모드와, 모든 유효성을 검증하고 임시 보고서만 생성하는 dry-run 모드입니다.
[삽입 이유] 실제 라이브 서버 반영 전 모든 유효성을 사전 검증하는 JSON 상태 관리 로직의 산출물들이 폴더 내에 어떻게 적재되는지 그 트리 구조를 명확히 보여주기 위함입니다.
[이미지 해설] 검증 단계별로 생성된 01~06번 JSON 상태 파일들이 outputs/reports/state_files/ 폴더에 순차적으로 기록되어 있는 실제 로그 내용을 기반으로 만든 터미널 형식 이미지입니다.
dry-run 모드가 실행되면 파이썬 스크립트는 다음과 같은 검증을 순차적으로 수행합니다. 1. 마크다운(blog.md) 파일의 프론트매터 및 카테고리 유효성 검사 2. GitHub 퍼블릭 저장소에 업로드된 이미지 URL의 HTTP 200 정상 응답 여부 3. 본문 내 금지어(예: 내부 테스트 용어나 부적절한 표현) 포함 여부 스캔
JSON을 활용한 Workflow 상태 기록
이 검증 과정의 핵심은 각 단계의 통과 여부를 workflow_state.json 파일에 기록하는 것입니다. 파이썬 딕셔너리를 활용해 6개의 주요 검문소가 모두 PASS 판정을 받았을 때만 can_publish: True 플래그를 활성화하도록 코드를 짰습니다.
workflow_data = {
"01_planner_pass": True,
"02_writer_pass": True,
"03_seo_pass": True,
"04_image_pass": True,
"05_qa_pass": True,
"06_cto_pass": True
}
# 모든 값이 True일 경우에만 발행 가능
can_publish = all(workflow_data.values())
이 로직이 적용된 이후, 자동화 스크립트는 혼자 폭주하며 쓰레기 글을 발행하지 못하게 되었습니다.
안전한 발행 파이프라인의 완성
이제 새로운 글을 작성할 때마다 저는 가장 먼저 dry-run 명령어를 실행합니다. 콘솔 화면에 모든 항목이 PASS로 뜨고, 최종 리포트에 can_publish: True가 찍히는 것을 확인한 뒤에야 안심하고 publish 명령어를 입력합니다.
[삽입 이유] 엄격한 모의 실행 검증을 통과하여 시스템이 자체적으로 발행을 허가하는 최종 상태값을 실제 로그 텍스트 기반 이미지로 증명하기 위함입니다.
[이미지 해설] dry-run 명령어를 실행하여 모든 안전성 검증을 통과한 뒤, can_publish: True 플래그가 최종 확정되어 출력된 실제 로그 텍스트 기반 이미지입니다.
자동화와 인간 개입의 완벽한 밸런스
블로그 자동화를 처음 구축할 때는 '버튼 하나만 누르면 모든 것이 끝나는 마법'을 꿈꿉니다. 그러나 실제 운영 환경은 호락호락하지 않습니다. API 서버가 순간적으로 응답하지 않거나, 예상치 못한 특수 문자로 인해 마크다운 파싱이 깨지는 등 수많은 변수가 존재합니다.
제가 도입한 파이썬 상태 관리 로직은 이러한 변수들을 통제하는 강력한 브레이크 역할을 합니다. dry-run 모드를 통해 사전에 철저히 검증된 데이터만이 다음 단계로 넘어갈 수 있는 권한을 얻게 됩니다. 특히 JSON 파일에 기록된 각 단계별 PASS / FAIL 상태값은 문제가 발생했을 때 어느 구간에서 오류가 났는지 즉각적으로 파악할 수 있는 훌륭한 디버깅 지표가 되기도 합니다.
결과적으로, 이 시스템은 100% 무인 자동화가 가지는 불안감을 해소해 주었습니다. 기계가 처리할 수 있는 반복적이고 소모적인 검증 작업은 파이썬 코드가 알아서 수행하게 둔 뒤, 최종적으로 can_publish: True가 떨어진 완벽한 상태의 원고만을 확인하고 승인하는 것이야말로 1인 개발자가 추구해야 할 진정한 의미의 '스마트한 자동화'라고 생각합니다.
파이썬 상태 관리 로직 덕분에 블로그 품질 통제력을 완벽하게 되찾았습니다. 코드가 혼자 달리지 않도록 '확인(Validation)'이라는 브레이크를 달아주는 것. 그것이 진정으로 견고한 자동화 파이프라인을 만드는 첫걸음이었습니다. 앞으로도 더 정교하고 안전한 파이프라인을 구축하기 위한 연구는 계속될 것입니다.
이러한 모의 실행(Dry-run) 아키텍처는 비단 블로그 자동화뿐만 아니라, 다양한 데이터 파이프라인이나 서버 배포 자동화(CI/CD) 과정에서도 동일하게 적용될 수 있는 매우 유용하고 범용적인 패턴입니다. 무조건적인 실행보다는 철저한 사전 검증을 통해 시스템의 신뢰성을 높이는 것이야말로 훌륭한 엔지니어링의 기본임을 다시 한번 상기하게 됩니다.
'AI 콘텐츠 자동화' 카테고리의 다른 글
| 백그라운드 무인 스케줄러 제어 불능 사태와 태스크 종료 실전 가이드 (0) | 2026.06.20 |
|---|---|
| AI 검수 로직을 붙였더니 오히려 작업이 멈춘 이유 (0) | 2026.06.17 |
| ElevenLabs 한국어 음성이 어색하게 들렸던 이유와 튜닝 기준 (0) | 2026.06.16 |
| 마크다운 이미지가 엑스박스로 깨진 이유와 GitHub 이미지 호스팅 실험 (0) | 2026.06.15 |
| AI 100% 자동화 콘텐츠의 한계: 결국 인간의 터치가 다시 필요해진 이유 (0) | 2026.06.10 |