예약된 발행(Scheduled publishing)은 작성자와 발행자가 서로의 업무를 대신하기 시작하기 전까지는 쉬워 보입니다. 저는 지루한 방식으로 이를 배웠습니다. 크론(cron) 작업이 실행 도중에 계획을 다시 생각할 수 있게 되면, 출력물은 빠르게 통제 불능 상태가 됩니다. 제목은 표류하고, 링크는 늘어나며, 하나의 실패를 수정하려다 조용히 두 번째 실패를 만들어내기도 합니다. 이것이 제가 자동화(Automation) 작업에 원샷 초안(one-shot draft) 모델을 선호하는 이유입니다. 작성자는 한 번 결정하고, 한 번 작성하며, 발행자는 오직 실행만 합니다.

이 패턴은 시스템이 동일한 운영 계약(operational contract)을 따르면서도 여러 계정에 걸쳐 뚜렷한 목소리를 유지해야 할 때 특히 유용합니다. 화려하지는 않지만 차분합니다. 차분한 시스템은 새벽 2시에 디버깅하기가 더 쉽고, 보통 시간이 지나도 더 안정적입니다.

크론 발행에서 원샷 생성(one-shot generation)이 중요한 이유

가장 큰 이점은 속도가 아닙니다. 바로 신뢰입니다.

예약된 작성자가 승인된 하나의 계획과 하나의 기사를 생성하면, 다음과 같은 안정적인 아티팩트(artifact) 세트를 얻게 됩니다:

• 하나의 run id
• 하나의 plan.json
• 하나의 article.raw.md
• 하나의 발행 결과(publish result)

이는 콘텐츠를 다시 작성하며 재시도하는 루프(loop)보다 검토를 훨씬 쉽게 만듭니다. 만약 발행 단계에서 실패한다면, 저는 실제로 게시될 예정이었던 정확한 초안을 조사할 수 있습니다. 브라우저가 어떤 버전을 보았는지 추측할 필요가 없는데, 이는 아주 작은 안도감일지 모르지만 실질적인 안도감을 줍니다.

이것은 제가 명령줄 도구(command line tools)에서 run-level trust signals를 좋아하는 것과 같은 이유입니다. 실행(run)은 무엇을 시도했는지 설명할 수 있는 증거를 남겨야 합니다.

각 실행 디렉토리에 담는 것

콘텐츠 자동화(content automation)를 위해, 저는 실행 디렉토리를 고통스러울 정도로 단순하게 유지합니다:

generated/<run_id>/
  plan.json
  article.raw.md
...

plan.json은 계획(planning)과 실행(execution) 사이의 경계입니다. 여기에는 계정, 언어, 제목, 태그, 키워드, 링크 및 개요(outline)가 담깁니다. 해당 파일이 존재한 이후에는, 기사가 계획과 협상하는 것이 아니라 계획을 따라야 합니다. 이러한 분리가 엄격하게 들릴 수 있지만, 이는 발행자(publisher)를 아주 단순하고 멍청하게 유지하며, 그것이 바로 제가 원하는 것입니다.

article.raw.md는 사람이 읽을 수 있는 페이로드 (payload)입니다. 이곳은 목소리 (voice)가 중요한 지점입니다. 저는 게시물이 공장에서 찍어낸 것이 아니라, 실질적인 취향을 가진 사람이 작성한 것처럼 느껴지기를 여전히 원합니다. 약간의 불완전함이 여기서 도움이 되는데, 완벽한 대칭은 종종 가짜처럼 읽히기 때문입니다. 지저분한 것이 아니라, 충분히 인간다워야 합니다.

publish-result.json은 루프 (loop)를 닫습니다. 나중에 크론 (cron) 실행이 저를 깨울 때, 결과 파일이 작업이 발행되었는지, 어디에 안착했는지, 그리고 정확히 어떤 제목을 사용했는지를 알려주기를 원합니다.

승인 경계 (approval boundary)를 단순하게 유지하는 방법

제가 계속해서 되풀이하는 규칙은 이것입니다: 작성자는 결정하고, 발행자는 실행한다.

일단 그 경계가 무너지면, 숨겨진 복잡성이 몰래 스며듭니다:

• 발행자가 제목을 "수정"하기 시작함
• 실행 실패 시 본문 내용을 재생성함
• 기사가 작성된 후 태그가 변형됨
• 마지막 순간에 링크 정책이 변경됨

이것이 바로 조용한 회귀 (regressions)가 발생하는 방식입니다. 발행자는 편집자보다는 배달원 (courier)처럼 행동해야 합니다.

계정별 스타일을 지원한다면 이 점은 더욱 중요합니다. 어떤 계정은 밀도 높은 튜토리얼 (tutorials)을 선호할 수 있고, 다른 계정은 보안 체크리스트 (security checklists)에 치중할 수 있으며, 또 다른 계정은 더 수다스러운 리듬으로 글을 쓸 수 있습니다. 작성자는 이를 의도적으로 형성할 수 있습니다. 실행자 (executor)는 발행 시점에 취향 결정을 내려서는 안 됩니다. 결론은 이렇습니다.

또한 저는 컨텍스트 (context) 내에 내부 링크를 미리 선택해 두는 것을 좋아합니다. 만약 제가 독자들을 oauth inbox testing과 같은 관련 자료로 안내하고 싶다면, 발행 스크립트가 브라우저 탭을 열기 전에 그 선택이 캡처되기를 원합니다.

놀라움을 줄여주는 작은 콘텐츠 계약 (content contract)

콘텐츠 계약 (content contract)이 화려할 필요는 없습니다. 그저 시스템이 그 사이에서 빠져나갈 수 없을 정도로 날카롭기만 하면 됩니다.

제가 사용하는 형태는 다음과 같습니다:

{
  "plan_written_first": true,
  "article_generation_count": 1,
...

이상하게도 그러한 계약(contract)은 SEO(검색 엔진 최적화) 작업에도 도움이 됩니다. 시스템이 타겟 키워드를 사전에 알고 있다면, 키워드를 모든 곳에 쑤셔 넣는 대신 절제하며 사용할 수 있습니다. 예를 들어, temp mail so가 주요 키워드 목록의 일부라면, 모든 헤딩(heading)에 뿌리기보다는 관련 섹션에서 언급하는 편이 낫습니다. tempail mail이나 tem email과 같은 노이즈가 섞인 변형 키워드도 마찬가지입니다. 이러한 키워드들은 소스 분석(source analysis)이나 쿼리 노트(query notes)에는 포함될 수 있지만, 글 전체를 장악해서는 안 됩니다.

한 가지 더 실용적인 참고 사항은, 원샷 생성(one-shot generation)이 실험을 더 안전하게 만든다는 점입니다. 재시도(retries)가 결과를 흐트러뜨리게 두지 않고도, 실행(runs) 전반에 걸쳐 제목 형식, 헤딩 깊이(heading depth), 또는 서론 스타일을 비교할 수 있습니다. 다소 구식처럼 느껴질 수도 있지만, 깔끔한 실험 경계(experiment boundaries)는 여전히 중요합니다.

Q&A

검증(validation)에 실패했을 때 발행자(publisher)가 초안을 다시 작성하게 하면 안 되나요?

그렇게 하면 실행자(executor)가 두 번째 작성자가 되어버리기 때문입니다. 계획(planning) 단계 이후에 콘텐츠가 변경되면, 깔끔한 감사 추적(audit trail)을 잃게 되고 실패 원인을 파악하기가 더 어려워집니다.

이것이 워크플로우를 느리게 만드나요?

의미 있는 수준으로 느려지지는 않습니다. 어차피 대부분의 대기 시간(wall time)은 브라우저 자동화(browser automation)나 네트워크 대기 시간이기 때문에, 더 안전한 계약을 맺는 데 드는 비용은 거의 공짜나 다름없습니다.

이것은 AI 파이프라인(pipelines)에만 해당되나요?

아니요. 인간이 보조하는 편집 시스템(editorial systems)도 이득을 봅니다. 예약된 실행(scheduled execution), 다중 계정, 또는 스타일별 규칙이 생기는 순간, 원샷 모델은 제값을 하기 시작합니다.

저의 간단한 원칙은 이렇습니다. 만약 크론 작성자(cron writer)가 당신을 놀라게 할 수 있다면(예상치 못한 행동을 한다면), 더 많은 기능을 추가하기 전에 계약을 더 엄격하게 만드세요. 또 다른 스마트한 재시도(smart retry) 기능을 출시하는 것보다 덜 흥미롭게 들릴지 모르지만, 나중에 겪을 수많은 이상한 밤들을 아껴줄 것입니다.