초안 생성 다음에는 무엇이 필요할까: Blog Studio의 구조

AI가 글을 만들어 주는 것과 그 글을 꾸준히 발행하는 것은 다른 문제였습니다. 원고 다음에는 출처 확인, 이미지 검사, 게시 상태 확인이 남습니다. 연결이 끊겼다면 같은 글을 한 번 더 만들지 않고 이어갈 방법도 필요합니다.

Blog Studio는 이 작업들을 한곳에서 관리하기 위한 시스템입니다. 이 글은 2026년 9월 20일 코드와 로컬 검증을 기준으로 한 첫 구조 기록입니다.

코드 구현, 로컬 검증, 실제 운영 성공은 구분합니다. 이번 분석에서 운영 계정으로 신규 글을 발행하지는 않았습니다.

작업을 세 영역으로 나눴습니다

서버는 작업과 상태를 관리하고, 별도 실행기는 원고·이미지 생성과 검수를 수행합니다. WordPress에는 발행을 담당하는 도우미가 있습니다. 생성 모델에 WordPress 비밀번호를 직접 주는 구조는 아닙니다.

후보와 근거
  → 작업 큐
  → 원고·이미지 생성
  → 서버 규칙 검사
  → 별도 AI 검수
  → WordPress 등록
  → 원격 상태 확인

API와 대시보드는 FastAPI, 작업 저장소는 SQLite입니다. 낮은 발행량에서 상태를 확인하고 복구하는 단순한 구성을 먼저 택했습니다. 실행기는 구독형 CLI 도구를 사용하며, 서비스 서버와 별도로 가동해야 합니다.

원고가 통과해야 하는 것들

검사는 HTML 형식만 보지 않습니다. 출처와 인용, 내부 검수 표시, 이미지 파일, 글의 구조를 확인합니다. 별도의 AI 검수 작업도 거칩니다. 다만 인용 문장이 원문에 존재한다는 사실만으로 해석까지 옳다고 증명되지는 않습니다.

본문 템플릿에는 요약, 출처, 투자 글 고지와 같은 부품을 넣었습니다. 목차는 WordPress 플러그인과 중복되지 않도록 선택할 수 있습니다. 앞으로는 설명형 글과 짧은 브리핑을 같은 형식에 억지로 넣지 않도록 유형별로 나눌 필요가 있습니다.

발행은 한 번의 요청으로 끝나지 않습니다

원격 서버가 글을 만들었는데 응답을 받지 못할 수 있습니다. 이때 요청을 그대로 반복하면 중복 글이 생길 수 있습니다. 작업 식별자와 원격 상태 확인은 이런 상황에서 필요합니다.

비공개 우선 등록은 실제 테마에서 원고를 확인하는 방법으로 사용할 수 있습니다. 정상 신규 글을 매번 사람이 승인해야 한다는 영구 정책과는 다릅니다. 자동 공개 범위는 품질과 복구 검증을 바탕으로 결정할 일입니다.

확인한 범위와 남은 일

분석 기준 코드에서 전체 테스트는 537건 통과, 33건 건너뛰기였고 대시보드 브라우저 테스트는 23건 통과했습니다. 하지만 추가 시나리오에서는 취소 작업 재시도, 예약 한도, 장전 기사 마감과 관련된 결함도 재현했습니다. 테스트 수가 많다는 것만으로 자동 운영 준비가 끝났다고 볼 수 없었습니다.

다음 보강 대상은 작업 상태 전이, 날짜별 예약 한도, 마감 시각, 실행기와 워커 상태 표시입니다. 원고 일부만 고치고 비교하는 편집 흐름도 필요합니다.

Lab에는 해결 전의 문제와 검증 범위를 함께 남기려 합니다. 다음 기록은 발행 응답을 놓쳤을 때의 확인 순서입니다.