저는 LLM을 사용하는 여러 크론(cron) 에이전트들이 모델 때문이 아니라, 출력(output) 때문에 실패하는 것을 보았습니다. 작업(job)은 잘 시작되고, 프롬프트(prompt)도 합리적으로 보이지만, 결국 결과가 승인되었는지, 실제로 게시되었는지, 아니면 시스템이 그저 예쁜 로그만 남긴 것인지 아무도 모르는 상황이 발생합니다. 이런 일이 새벽 3시에 발생한다면, 그것은 더 이상 프롬프팅(prompting)의 문제가 아닙니다. 그것은 계약(contract)의 문제입니다.

제 생각에, 프로그래밍된 에이전트는 API만큼이나 명확한 출력이 필요합니다. 만약 워크플로우(workflow)가 콘텐츠를 작성한다면, 계획(plan), 최종 결과물(artifact), 게시 결과(publication result), 그리고 검사하기 쉬운 실행 경로(run path)와 같은 검증 가능한 증거도 함께 남겨야 합니다. 다소 경직되게 들릴 수 있지만, 프로덕션(production) 환경에서 그 경직성은 평온함을 가져다줍니다.

크론(cron) 에이전트에게 출력 계약이 필요한 이유

LLM은 옵션을 생성하는 데 능숙합니다. 반면, 크론(cron) 시스템은 단 하나의 관찰 가능한 결정으로 종결되어야 합니다. 명확한 경계 없이 이 두 가지 성질을 섞어버리면 매우 전형적인 증상들이 나타납니다:

1. 작업(job)이 재시도할 때마다 매번 다른 결과물을 생성합니다.
2. 게시자(publisher)가 어떤 버전이 올바른 것인지 알지 못합니다.
3. 사후 검토(post-review)가 거의 불가능해집니다.
4. 팀이 증거가 아닌 직관에 의존하게 됩니다.

출력 계약(output contract)은 에이전트가 적은 수의 결과물(artifact)과 예측 가능한 이름으로 작업을 마치도록 강제함으로써 이 문제를 해결합니다. 제 머릿속의 언어적 다이어그램은 단순합니다: 컨텍스트(context) -> 승인된 계획(approved plan) -> 단일 아티팩트(unique artifact) -> 게시 결과(publish-result). 각 화살표는 자유도를 줄여줍니다. 이는 모델의 창의성을 죽이는 것이 아니라, 유용한 가드레일(guardrails)을 설치하는 것입니다.

이는 운영 불안 없이 검증된 재전송을 구현하는 방법에서 UX와 증거를 분리하는 아이디어와 유사합니다. 두 경우 모두 핵심은 "AI를 더 많이 만드는 것"이 아니라, 성공이 무엇을 의미하는지, 그리고 그것을 어떻게 관찰할지를 더 잘 정의하는 것입니다.

밤샘 작업을 견뎌낼 수 있는 최소한의 설계

이러한 유형의 자동화를 구축할 때, 저는 매 실행이 다음 네 가지를 남기도록 시도합니다:

1. 고유한 run_id.
2. 제목, 키워드, 링크 및 스키마 (schema)가 포함된 plan.json.
3. 단 한 번 작성되는 article.raw.md.
4. 최종 상태와 URL이 포함된 publish-result.json.

이렇게 하면 열 개의 탭을 열지 않고도 작업(job)의 거의 모든 이력을 재구성할 수 있습니다. 만약 어떤 실행(run)이 이상한 것을 게시한다면, 계획(plan)과 기사(article)를 비교하면 됩니다. 게시되지 않았다면 결과를 읽으면 됩니다. 만약 두 번 게시되었다면, run_id를 찾아 어디에서 규율(discipline)이 깨졌는지 확인하면 됩니다.

여기에는 실질적인 이유가 있습니다. 시스템이 자신의 전이(transitions)를 가시화할 때 자동화의 신뢰성이 향상됩니다. DORA의 State of DevOps 보고서는 더 나은 피드백 루프(feedback loops)와 관측성(observability)을 갖춘 팀이 더 적은 마찰로 변경 사항을 운영한다는 것을 계속해서 보여주고 있습니다 source. 물론 이것이 LLM에 대해서만 말하는 것은 아니지만, 그 원칙은 완벽하게 들어맞습니다.

계약(contract)의 최소한의 예시는 다음과 같습니다:

{
  "run_id": "20260801T112224Z-lucasg88",
  "artifacts": ["plan.json", "article.raw.md", "publish-result.json"],
...

정교하지는 않습니다. 모든 것을 설명하려고 시도하지도 않습니다. 단지 운영상의 경계(operational edge)를 설정할 뿐입니다. 그리고 솔직히 말해서, 그것만으로도 수많은 사소한 고통을 피할 수 있습니다.

창의성과 검증 가능성 사이의 트레이드오프 (Tradeoffs)

흔한 반론은 이렇습니다: "흐름을 너무 폐쇄적으로 만들면 LLM이 글을 더 못 쓴다". 가끔 그런 일이 발생하지만, 대부분은 계약이 인터페이스 (interface)가 아닌 구속복 (straitjacket)처럼 설계되었기 때문입니다. 저는 다음과 같이 생각하는 것을 선호합니다:

1. 계획 (plan)은 제약 조건과 초점을 정의합니다.
2. 기사 (article)는 그 프레임워크 내에서 자유를 유지합니다.
3. 게시자 (publisher)는 절대로 콘텐츠를 즉흥적으로 만들지 않습니다.

세 번째 포인트가 매우 중요합니다. 만약 게시 스크립트가 텍스트를 다시 쓰거나, 헤딩 (headings)을 수정하거나, 메타데이터 (metadata)를 지어낸다면, 당신은 더 이상 분리 가능한 시스템을 가진 것이 아닙니다. 실행기 (executor) 안에 숨겨진 생성기 (generator)를 갖게 된 것이며, 나중에 이를 디버깅하는 것은 엉망진창이 될 것입니다.

백엔드 스택에서는 이를 경계 테스트 (boundary testing)와 비교합니다. FastAPI에서 트랜잭션 이메일을 테스트하는 방법에서도 이와 유사한 사례가 나타납니다. 실행기 (executor)는 오직 실행만 담당하고 계획 (plan)이 이미 의도를 명확히 정의하고 있다면, 시스템은 더욱 가독성이 높아집니다.

또한 다소 불편할 수 있는 세부 사항을 받아들일 필요가 있습니다. 편집 콘텐츠에서는 약간의 인간적인 불완전함이 바람직할 수 있지만, 인프라 (infrastructure)는 그러한 모호함을 물려받아서는 안 됩니다. 약간 어색한 문장은 허용할 수 있어도, 모호한 최종 결과물은 허용해서는 안 됩니다. 이 차이를 설계하는 것은 항상 쉽지 않습니다.

시스템을 오염시키지 않고 일회용 임시 이메일을 사용하는 방법

이러한 유형의 흐름이 외부 브랜딩에 의존하지 않더라도, 일회용 임시 이메일이 상당히 도움이 되는 순간들이 있습니다. 온보딩 (onboarding) 테스트, 격리된 검증, 그리고 실제 계정과 섞이지 않기를 원하는 전달 가능성 (deliverability) 체크 등이 그 예입니다. 핵심은 해당 리소스를 시스템의 중심에 두지 않는 것입니다. 리소스는 시나리오별로 에지 (edge)에 존재해야 하며, 짧은 수명과 명확한 실행 이름 (run names)을 가져야 합니다.

만약 팀이 테스트용 이메일, 실제 자격 증명 (credentials), 그리고 tamp mail com과 같은 시드 (seeds)를 동일한 증거 데이터에 섞어버린다면, 나중에 실제로 무슨 일이 일어났는지 아무도 알 수 없게 됩니다. LLM 또한 마찬가지입니다. 그저 운영상의 노이즈 (noise)만을 학습하게 될 뿐입니다. 그렇기 때문에 저는 에이전트가 깨끗한 컨텍스트 (context)를 전달받기를 선호하며, 모든 휘발성 인박스 (inbox)는 시스템에 떠돌아다니는 것이 아니라 반드시 run_id에 연결되어야 한다고 생각합니다.

짧지만 유용한 체크리스트:

1. 중요한 단계마다 하나의 아티팩트 (artifact) 생성.
2. 최종 콘텐츠의 단일 쓰기 (single write).
3. 편집 로직이 없는 퍼블리셔 (publisher).
4. 사람이 읽을 수 있는 최종 증거.

자주 묻는 질문 (FAQ)

초안을 여러 개 저장하는 것이 좋을까요?

수동 탐색을 위한 목적이라면 그렇습니다. 하지만 자율적인 크론 (cron) 작업의 경우라면 거의 그렇지 않습니다. 초안을 늘리는 것은 추적 가능성 (traceability)을 복잡하게 만들고, 무엇이 공식적인 아티팩트인지 모호하게 만듭니다.

이것이 블로깅 이외의 분야에도 적용될 수 있나요?

네, 상당히 그렇습니다. 티켓에 응답하거나, 변경 로그 (changelog)를 생성하거나, 보고서를 준비하는 에이전트들에게도 작동합니다. 핵심 패턴은 "포스트 게시"가 아니라, 검증 가능한 출력 (verifiable outputs)을 만들어내는 것입니다.

작업(job)이 실패했을 때 가장 먼저 무엇을 확인해야 하나요?

먼저 publish-result.json을 확인합니다. 그다음 plan.json과 article.raw.md를 비교하여 실패가 실행 (execution) 단계에서 발생한 것인지, 아니면 설계 (design) 단계에서 발생한 것인지 확인합니다. 당연해 보일 수 있지만, 이러한 순서를 갖추는 것은 시간을 낭비하는 것을 방지하며, 때로는 이미 잘 작동하고 있는 부분을 건드리지 않도록 도와줍니다.