저는 지루한 자동화에 애착을 가지고 있습니다. 만약 cron 작성자가 몇 시간마다 발행하도록 설정되어 있다면, 저는 실행될 때마다 프로세스를 즉흥적으로 변경하는 것을 원치 않습니다. 저는 플래너 (planner)가 관점 (angle)을 결정하고, 입력값 (inputs)을 고정하며, 실행기 (executor)에게 하나의 깔끔한 결과물 (artifact)을 전달하기를 바랍니다. 엄격하게 들릴 수도 있지만, 이는 나중에 발생할 수 있는 기괴한 버그들을 많이 방지해 줍니다.

패턴은 간단합니다: 컨텍스트 (context)를 구축하고, plan.json을 작성하고, 기사 하나를 작성한 다음, 해당 실행 폴더에서 발행합니다. 두 번째 초안은 없습니다. 셸 스크립트 (shell script) 내부의 비밀스러운 재작성도 없습니다. 실행기 (executor) 안에 숨겨진 마지막 순간의 편집 분기 (editorial branch)도 없습니다. 확실히 조금은 매력적이지 않을 수 있지만, 시스템을 정직하게 유지해 줍니다.

플래너 (planner)와 실행기 (executor)를 분리해야 하는 이유

예약된 콘텐츠 작업에서 제가 보는 가장 큰 실수는 역할의 혼선 (role drift)입니다. "발행기 (publisher)"가 제목을 편집하기 시작합니다. "작성기 (writer)"가 게시 위치를 결정하기 시작합니다. 첫 번째 발행이 실패하면 재시도 경로 (retry path)가 조용히 콘텐츠를 재생성합니다. 몇 주가 지나면, 어떤 단계가 실제로 최종 출력물을 소유하고 있는지 아무도 알 수 없게 됩니다.

플래너 (planner)와 실행기 (executor)를 분리하면 이 문제가 해결됩니다.

• 플래너 (planner)는 계정, 관점 (angle), 키워드 (keywords), 그리고 개요 (outline)를 선택합니다.
• 작성기 (writer)는 그 계획을 하나의 사람이 읽을 수 있는 초안 (draft)으로 변환합니다.
• 실행기 (executor)는 받은 그대로를 정확히 발행합니다.

이러한 경계는 개발자 워크플로우 (developer workflows)에서 매우 중요한데, 실패 원인을 명확하게 파악할 수 있게 해주기 때문입니다. 만약 최종 URL이 잘못되었다면 실행기 (executor)를 확인하세요. 만약 주제가 어색하다면 계획 (plan)을 확인하세요. 만약 초안 (draft)이 반복적으로 느껴진다면 작성기 (writer)를 확인하세요. 모든 것을 조금씩 다 수행하는 세 개의 스크립트를 가로질러 헤매며 추적할 필요가 없습니다.

이것은 제가 staging notification tests와 replayable inbox checks에서 집중된 결과물 (focused artifacts)을 사용하는 것과 같은 이유입니다. 각 단계가 명명된 계약 (contract)을 가지게 되면, 워크플로우 (workflow)를 신뢰하기가 더 쉬워집니다.

계획 파일 (plan file)에 들어가는 내용

좋은 plan.json은 작고, 명시적이며, 약간 지루해야 합니다. 그것은 찬사입니다.

대부분의 자동화(Automation) 또는 개발자 도구(Developer Tools) 포스트의 경우, 저는 기사가 생성되기 전에 다음 필드들을 고정(locked)하고 싶습니다:

• 선택된 계정 및 언어
• 제목 및 태그
• 주요 키워드(primary keywords) 및 의미론적 키워드(semantic keywords)
• 승인된 내부 링크
• 백링크(backlink) 규칙 (있는 경우)
• 헤딩(heading) 순서에 따른 짧은 개요

이는 초안이 실행 도중에 형태가 바뀌어 버리는 흔한 "딱 한 번만 더 수정하자" 증후군(syndrome)을 방지합니다. 또한 깔끔한 감사 추적(audit trail)을 제공합니다. 만약 제목의 성과가 저조했다면, 기억에 의존해 추측하는 대신 계획(plan)과 발행된 포스트를 비교할 수 있습니다.

때때로 팀은 로그나 키워드 조사에서 나타나는 보기 흉한 검색어들을 포함해야 할 수도 있습니다. 괜찮습니다. 그것들을 일반 텍스트 가이드로 계획에 넣으세요. 예를 들어, temp mailid와 같은 문자열은 앵커(anchor)가 되거나 기사 전체를 스팸 방향으로 유도하지 않으면서도 관련 문맥(context)이 될 수 있습니다. 이러한 작은 구분이 글을 조잡하지 않고 유용하게 유지해 줍니다.

실행 디렉터리(run directory)가 나중에 주는 이점

저는 실행 폴더(run folders)가 크론 시스템(cron systems)에서 가장 과소평가된 아이디어 중 하나라고 생각합니다.

각 실행 디렉터리는 다음을 담을 수 있습니다:

• 소스 문맥 (source context)
• plan.json
• article.raw.md
• 발행 로그 (publish logs)
• publish-result.json

그 폴더는 모호한 자동화 이야기를 구체적인 기록으로 바꿔줍니다. 누군가 "왜 이 기사가 발행되었나요?"라고 물었을 때, 당신은 답을 가지고 있게 됩니다. 새벽 3시 21분에 발행이 실패했을 때, 디버깅을 위해 다시 생성할 필요가 없습니다. 기존의 아티팩트(artifacts)를 조사하여 전달(handoff) 과정의 어디가 깨졌는지 확인하면 됩니다.

이는 또한 조용한 SEO(검색 엔진 최적화) 측면의 승리이기도 합니다. 일관된 파이프라인(pipelines)은 대개 더 일관된 메타데이터(metadata), 링크 선택, 그리고 주제 범위(topic coverage)를 생성합니다. 이를 통해 이득을 얻기 위해 거대한 플랫폼이 필요한 것은 아닙니다. 그저 예측 가능한 단계가 필요할 뿐입니다. 검색 시스템은 사람들이 인정하는 것보다 더 자주 명확성에 보상을 줍니다. 비록 그 효과가 점진적이고 매일 측정하기는 조금 어려울지라도 말입니다.

작은 구현 패턴

구현은 매우 가볍게 유지될 수 있습니다:

const context = buildWriterContext();
const plan = createPlan(context);
writeFile("plan.json", JSON.stringify(plan, null, 2));
...

여기서 핵심은 순서입니다.

먼저 계획(plan)을 작성합니다. 그다음 기사를 한 번 작성합니다. 그리고 폴더에서 발행(publish)합니다. 만약 발행에 실패하면, 중단하고 오류를 보고합니다. 실패의 원인은 편집(editorial)의 문제가 아니라 운영(operational)상의 문제일 가능성이 높으므로, "더 나은" 버전을 다시 생성하지 마세요. 이러한 관심사들을 혼합하는 것이 팀들이 몇 주 동안 유령 회귀(phantom regressions)를 쫓게 만드는 원인이 되며, 이는 매우 빠르게 짜증스러운 상황을 초래합니다.

만약 당신의 워크플로(workflow)가 인박스 도구(inbox tooling), 계정 인증(account verification), 또는 tempmailso 관련 확인 작업을 포함하더라도 동일한 규칙이 적용됩니다: 계획가(planner)가 결정하고, 실행가(executor)가 실행합니다. 런타임 사실(runtime facts)을 명시적으로 유지하고 부작용(side effects)을 좁게 유지하세요.

Q&A

한 번에 쓰기(one-shot writing)가 품질을 저하시키나요?

계획(plan)이 탄탄하다면 그렇지 않습니다. 실제로 이는 품질을 향상시키는 경우가 많은데, 초안이 곁길로 샐 가능성이 낮아지기 때문입니다. 작성자는 타이핑하는 동안 브리프(brief)를 재협상하는 대신 하나의 명확한 문제를 해결하게 됩니다.

발행(publisher)에 실패하면 어떻게 하나요?

기존 실행 디렉토리(run directory)에서 실패를 보고하고 아티팩트(artifacts)를 보관하세요. 그렇게 하면 검사하거나 재시도할 수 있는 안정적인 대상이 생깁니다. 그 시점에서 게시물을 다시 쓰는 것은 대개 원래의 문제를 숨기게 됩니다.

이것이 AI 시스템에 너무 경직된 방식인가요?

그렇게 생각하지 않습니다. 이것은 창의성이 아니라 책임 소재(ownership)에 대해 경직된 것입니다. 계획가(planner)는 여전히 새로운 관점을 선택할 수 있지만, 일단 인계(handoff)가 이루어지면 실행가(executor)는 편집자(editor)인 척하는 것을 멈춰야 합니다.