한 가지 규칙이 저의 예약 발행 작업(scheduled publishing jobs)을 훨씬 더 신뢰할 수 있게 만들었습니다. 일단 초안(draft)이 실행을 위해 승인되면, 재시도(retries) 과정에서 새로운 페이로드(payload)를 만들어내서는 안 됩니다. 동일한 발행을 다시 시도할 수는 있지만, 제목, 링크, 태그 또는 본문을 조용히 다시 선택해서는 안 됩니다. 이러한 경계는 엄격하고 어쩌면 조금 지루하게 들릴 수도 있지만, 재시도 경로(retry path)에서 제가 정확히 원하는 것은 바로 그 지루함입니다.

저는 몇몇 크론 워크플로(cron workflows)가 최악의 방식으로 실패한 후에 이를 배웠습니다. 소란스럽게 실패한 것이 아니라, 그저 일관성 없이 실패했습니다. 첫 번째 시도는 합리적인 초안을 생성했지만, 재시도가 콘텐츠의 일부를 재생성함으로써 "도움"을 주려 했습니다. 게시물이 라이브(live) 상태가 되었을 때, 실행 이력(run history)은 더 이상 플래너(planner)가 승인한 내용과 일치하지 않았습니다. 나중에 이를 디버깅(debugging)하는 것은 매우 고통스러웠는데, 작업 로그(job logs)는 충분히 성공적인 것처럼 보였지만 페이로드가 드리프트(drift, 변질)되었기 때문입니다.

콘텐츠 자동화에서 재시도가 위험해지는 이유

콘텐츠 자동화에서 위험한 부분은 발행 클릭 그 자체인 경우가 드뭅니다. 위험은 시스템이 이미 좋은 계획을 세운 후에 발생하는 숨겨진 의사결정에서 비롯됩니다.

전형적인 드리프트(drift) 양상은 다음과 같습니다:

• 재시도 로직(retry logic)이 최신 것이 더 낫다고 판단하여 새로운 제목을 가져옴
• 두 번째 통과 시 태그(tags)가 다르게 정규화(normalized)됨
• 셀렉터(selector)나 휴리스틱(heuristic)이 다시 실행되어 내부 링크가 변경됨
• 한 브랜치에서는 본문이 다듬어지지만 다른 브랜치에서는 그렇지 않음

이것이 단순한 발행 재시도가 두 번째 집필 세션으로 변질되는 방식입니다. 만약 당신의 시스템이 그렇게 작동한다면, 그것은 진정한 의미의 재시도가 아닙니다. 그것은 압박 속에서 다시 저술(re-authoring)하는 것이며, 바로 그 지점에서 많은 기이한 버그들이 몰래 숨어듭니다.

빌더(builder) 중심의 자동화 및 개발자 도구(Developer Tools) 워크플로를 위해, 저는 이제 명시적인 핸드오프 아티팩트(handoff artifact)를 선호합니다. 플래너(planner)는 한 번 선택합니다. 라이터(writer)는 한 번 씁니다. 퍼블리셔(publisher)는 오직 사이드 이펙트(side effects, 부수 효과)만을 실행합니다. 이 분리 과정을 생략하면, 저는 거의 항상 일주일 후에 후회하게 됩니다.

발행 시작 전 페이로드를 동결(Freeze)하기

가장 쉬운 패턴은 첫 번째 발행 시도 전에 승인된 페이로드를 파일에 동결(freeze)하는 것입니다:

• 계정, 제목, 태그, 키워드 및 링크 결정 사항이 포함된 plan.json
• 실제로 게시되어야 할 정확한 본문이 담긴 article.raw.md
• 실행이 완료된 후에만 작성되는 publish-result.json

이렇게 하면 실행 과정에 중심점(center of gravity)이 생깁니다. 인증(auth)이 만료되었거나 브라우저에 일시적인 오류(hiccup)가 발생하여 첫 번째 시도가 실패하더라도, 두 번째 시도에서는 무엇이 "최신(latest)"인지 논쟁할 필요 없이 동일한 페이로드(payload)를 재사용할 수 있습니다. 또한 리뷰 과정도 가벼워집니다. 사람은 동결된 계획을 검토함으로써 실행기(executor)가 나중에 멋대로 행동(freelancing)하지 않을 것임을 알 수 있습니다.

제가 사용하는 사고 모델(mental model)은 다음과 같습니다:

한 번 계획하기 -> 한 번 쓰기 -> 필요하다면 여러 번 발행하기

작은 규칙이지만, 큰 이점이 있습니다.

이는 제가 이메일 워크플로(workflow) 주변의 스모크 테스트(smoke checks)를 생각하는 방식과 유사합니다. 유용한 부분은 재시도 그 자체가 아니라, 그 주변에 유지되는 안정적인 증거입니다. 만약 이메일 템플릿 변경을 위한 스모크 테스트(smoke tests for email template changes)를 구축해 본 적이 있다면, 여기서도 동일한 직관이 적용됩니다. 테스트하려는 변수를 격리한 다음, 나머지 시스템이 동시에 변하는 것을 막는 것입니다.

불변 실행 폴더(immutable run folder)에 포함되어야 할 내용

저는 모든 아티팩트(artifact)를 한곳에 모아둘 수 있도록 실행 ID(run id)당 하나의 폴더를 사용하는 것을 선호합니다. 대부분의 가치를 얻기 위해 거창한 데이터베이스가 필요하지는 않습니다. 그저 미래의 졸린 당신이 명확한 질문에 빠르게 답할 수 있도록 도와주는 레이아웃만 있으면 됩니다.

저의 체크리스트는 보통 다음과 같습니다:

• 플래너(planner), 라이터(writer), 퍼블리셔(publisher)가 공유하는 하나의 실행 ID
• 하나의 승인된 메타데이터 파일
• 하나의 아티클 페이로드 파일
• URL 또는 에러가 포함된 하나의 최종 결과 파일

이렇게 갖춰두면 사후 분석(postmortems)이 훨씬 단순해집니다. 재시도 시 동일한 제목을 재사용했는가? 라이터가 시도 사이에 링크를 바꿨는가? 잘못된 계정이 선택되었는가? 이러한 답변들은 터미널 스크롤백(scrollback) 속에 머물지 않고, diff를 통해 비교할 수 있는 파일 속에 존재하게 됩니다.

또한 검증(validation)에 중요한 경우, 오타가 발생하기 쉬운 검색어들을 일반 텍스트(plain text)로 보이게 유지하는 것도 선호합니다. tepm mail com이나 fake e mail com 같은 용어들은 보기 좋지는 않지만, 실제 환경에서 나타날 수 있으며 체크 문구의 표현 방식이나 디버깅(debugging) 방식에 영향을 줄 수 있습니다. 이러한 용어들은 앵커(anchor)나 메타데이터(metadata)에는 포함되지 않아야 하지만, 콘텐츠 노트(content notes)나 테스트 컨텍스트(test context)에 보이도록 유지하면 나중에 시간을 절약할 수 있습니다.

또 다른 좋은 부수 효과는 관련 내부 참조(internal references)를 자연스럽게 배치하기가 더 쉬워진다는 점입니다. 예를 들어, 운영용 이메일 체크에 컨텍스트(context)가 필요하다는 점을 상기시키고 싶을 때, 재시도 로직(retry logic)이 그 주변의 전체 구조를 다시 계산하게 만들지 않고도 restore-aware email checks for ops를 가리킬 수 있습니다.

인박스(inbox) 및 이메일 체크가 여전히 적합한 위치

기사 페이로드(payload)를 동결(freezing)한다고 해서 주변의 모든 체크가 무용지물이 된다는 뜻은 아닙니다. 단지 해당 체크들이 각자의 역할(lane)을 유지해야 한다는 의미입니다.

추가적인 체크의 좋은 활용 사례:

• 발행(publish) 단계가 시작되기 전에 인증(auth)이 존재하는지 확인
• 발행 단계가 종료된 후 최종 URL이 캡처되었는지 확인
• 알림 텍스트가 동결된 제목(frozen title) 및 실행 ID(run id)와 일치하는지 검증

좋지 않은 활용 사례:

• 설명(description)이 너무 길게 느껴진다는 이유로 발행 중에 내용을 재작성하는 것
• 더 "나은" 후보가 나타났다는 이유로 링크를 교체하는 것
• 첫 번째 시도가 시간 초과(timeout)되었다는 이유로 단락을 재생성하는 것

마지막 사례는 많은 자동화 시스템이 신뢰를 잃게 되는 지점입니다. 시스템은 회복 탄력성(resilience)을 갖추려 노력하지만, 정결성(determinism)이 가장 중요한 곳에서 결국 창의성을 발휘하고 맙니다. 저는 아무도 완전히 재구성할 수 없는 페이로드로 성공하는 것보다, 차라리 명확하게 실패한 뒤 동일한 페이로드로 재시도하는 쪽을 택하겠습니다.

만약 당신의 워크플로우가 인박스 검증 (inbox verification)에도 의존한다면, 이를 좁은 범위의 지원 단계로만 유지하십시오. create temp mail 흐름이나 작은 temp mail generator 체크는 격리된 상태에서 알림을 검증하는 데 도움이 될 수 있지만, 이러한 도구들이 발행 아키텍처 (publish architecture)의 핵심이 되어서는 안 됩니다. 핵심은 여전히 작성자 (writer)와 실행자 (executor) 사이의 불변하는 핸드오프 (immutable handoff)여야 합니다.

Q&A

작은 크론 잡 (cron job)에 과한 설정인가요?

그렇지 않습니다. 아주 작은 예약된 작업이라도 인증 (auth), 브라우저 상태 (browser state), 그리고 외부 API (external APIs)를 가로질러 재시도하기 시작하면 논리적으로 파악하기 어려워집니다. 몇 개의 일반 파일 (plain files)을 사용하는 것은 저렴한 안전장치 (guardrail)가 됩니다.

재시도 시에 데이터를 재생성해야 할까요?

의도적으로 완전히 새로운 실행 (run)을 시작하는 경우에만 그렇습니다. 만약 동일한 실행 ID (run id) 내에 있다면, 승인된 페이로드 (approved payload)를 변경하지 마십시오.

실제 얻는 이득은 무엇인가요?

더 차분하게 디버깅 (debugging)을 할 수 있습니다. 발행이 실패했을 때, 폴더 하나만 조사하면 무엇이 일어나기로 되어 있었는지, 실제로 무엇이 일어났는지, 그리고 재시도가 정직하게 유지되었는지를 알 수 있습니다.

가장 좋은 점은 이 패턴이 전혀 화려하지 않다는 것입니다. 마법 같은 오케스트레이션 레이어 (orchestration layer)도, 추측에 기반한 재작성 (speculative rewrite) 단계도, 발행기 (publisher) 내부의 숨겨진 플래너 (planner)도 없습니다. 그저 페이로드를 동결하고, 재시도를 정직하게 유지하며, 실행자가 정확히 한 가지 일만 수행하도록 두는 것입니다.