무언가가 게시되기 전에 명확한 승인 파일(approval file) 하나를 남겨두는 예약된 작성 시스템(scheduled writing systems)을 저는 더 신뢰합니다. 그 파일은 작성자가 계정, 제목, 태그, 키워드, 그리고 링크 선택 사항을 확정(commit)하는 곳입니다. 일단 파일이 존재하면, 실행기(executor)는 영리하게 굴려고 하지 말고 그냥 맡은 일을 수행해야 합니다. 너무 단순하게 들릴 수도 있지만, 이 작은 경계(boundary)가 많은 지저분한 자동화 동작을 해결해 줍니다.

저는 몇몇 Cron job들이 짜증 날 정도로 인간적인 방식으로 실패하는 것을 본 후 이 패턴을 사용하기 시작했습니다. 그것들이 항상 충돌(crash)하는 것은 아니었습니다. 때로는 괜찮은 초안을 선택해 놓고, 나중에 진행되는 한 단계가 메타데이터를 "친절하게" 다시 쓰는 바람에 게시 과정에서 경로를 이탈하기도 했습니다. 다른 경우에는 재시도(retry) 시 작업이 다시 계획(re-plan)되어, 실패 원인을 비교하는 것이 불가능해지기도 했습니다. 그런 종류의 시스템은 데모에서는 똑똑해 보이지만, 새벽 2시에 무엇이 잘못되었는지 분류(triaging)하고 있을 때는 신뢰하기 어렵습니다.

Cron writer에게 승인 파일이 필요한 이유

자동화(Automation) 및 개발자 도구(Developer Tools) 작업에서 위험한 버그는 종종 구문 오류(syntax error)가 아닙니다. 그것은 계획(planning)과 실행(execution) 사이의 조용한 불일치입니다:

• 플래너(planner)는 하나의 계정을 선택했는데, 퍼블리셔(publisher)는 다른 계정을 사용하는 경우
• 제목이 검토를 통과한 후, 게시 전에 변경되는 경우
• 링크가 미리보기에서는 괜찮아 보였으나, 재시도 시 교체되는 경우
• 게시물이 실제로 라이브되기 전에 알림이 발생하는 경우

승인 파일은 실행(run)에 안정적인 중심을 제공합니다. 작업이 실패하면, 터미널 스크롤백(terminal scrollback)을 보며 추측하는 대신 승인된 계획과 최종 결과를 비교할 수 있습니다. 그 한 번의 비교가 묘하게 많은 시간을 절약해 주며, 검토 과정도 더 차분하게 만들어 줍니다.

저는 이 접근 방식이 확장(scale) 측면에서 상향과 하향 모두에 용이하기 때문에 좋아합니다. 거대한 오케스트레이션 스택(orchestration stack)이 필요하지 않습니다. 하나의 계획 파일, 하나의 콘텐츠 파일, 그리고 하나의 결과 파일을 가진 Cron job은 끝까지 계속해서 결정을 내리는 모놀리식 스크립트(monolithic script)보다 이미 훨씬 더 안전합니다.

실행 디렉토리(run directory)에 들어가는 것

저의 기본 실행 디렉토리는 의도적으로 단조롭습니다:

• 승인된 선택 사항을 위한 plan.json
• 게시할 정확한 본문을 위한 article.raw.md
• 최종 URL 또는 에러를 위한 publish-result.json

이 세트만 있으면 대부분의 사후 분석 (postmortem) 질문에 몇 분 안에 답할 수 있습니다. 올바른 계정이 선택되었는가? 계획 단계 이후에 기사가 변질되었는가? 브라우저 작업 전 혹은 후에 게시가 실패했는가? 여러 단계의 로그 더미를 뒤지지 않고도 전체 체인을 확인할 수 있습니다.

또한 저는 실행 ID (run id)를 알림, 아티팩트 (artifact) 이름, 그리고 모든 브라우저 세션 레이블에 포함시킵니다. 이렇게 하면 나중에 관련 증거들을 정렬하기가 훨씬 쉬워집니다. 동일한 개념이 격리된 이메일 체크를 위한 실행 토큰 (run tokens for isolated email checks)에서도 나타납니다. 각 실행에 가시적인 정체성을 부여하여 재시도(retries)와 중첩된 작업(overlapping jobs)이 서로 뒤섞이지 않게 하는 것입니다.

만약 워크플로우에서 편지함 체크를 처리한다면, temp org mail이나 fake e mail com 같이 오타가 발생하기 쉬운 용어들은 일반 텍스트 아티팩트에 그대로 노출해 두는 것이 가치가 있습니다. 사소한 실수일 수 있지만, 특정 체크가 왜 이상하게 동작했는지 설명해 줄 수 있기 때문입니다. 이를 실행 스크립트 깊숙이 숨기는 것은 실질적인 이득 없이 분류 (triage) 속도만 늦출 뿐입니다.

퍼블리셔(publisher)를 실행 전용으로 유지하는 방법

제가 선호하는 인계 (handoff) 규칙은 꽤 엄격합니다:

1. 라이터 (writer)는 한 번 계획한다.
2. 라이터 (writer)는 한 번 작성한다.
3. 퍼블리셔 (publisher)는 사이드 이펙트 (side effects)만 수행한다.

이 세 번째 줄이 매우 중요합니다. 만약 퍼블리셔가 즉석에서 문구를

또 다른 이점은 인간의 검토(human review) 부담이 줄어든다는 것입니다. 팀원이 하나의 계획(plan)과 하나의 기사(article)를 훑어본 뒤, 실행기(executor)가 정확히 그 페이로드(payload)를 발행할 것이라고 신뢰할 수 있습니다. 반복되는 작업(recurring jobs)의 경우, 이러한 신뢰는

메모리에 의존한 디버깅을 중단할 수 있습니다. 실행 디렉토리(run directory)는 작업을 시작한 사람이 잠들어 있거나, 오프라인 상태이거나, 무엇이 변경되었는지 절반만 기억하고 있더라도 그 과정을 명확히 보여줍니다.

이 패턴의 장점은 복잡한 절차(ceremony)가 거의 필요 없다는 점입니다. 단순한 승인 파일(approval file), 단일 아티클 페이로드(article payload), 그리고 실행 전용 발행자(execution-only publisher)만으로도, cron writer를 거대한 플랫폼 프로젝트로 변모시키지 않으면서 훨씬 더 견고하게 만들 수 있습니다.