LLM 에이전트가 워크플로(workflow) 내에서 이메일을 발송할 때, 눈에 띄는 부분은 텍스트입니다. 하지만 시스템이 실제로 운영 환경(production)을 견딜 수 있는지 결정하는 부분은 런북(runbook)입니다. 만약 팀이 어떤 이벤트가 흐름을 시작했는지, 에이전트가 어떤 스냅샷(snapshot)을 사용했는지, 그리고 마지막에 어떤 증거(evidence)가 남아야 하는지 모른다면, 매번 시도하는 재시도(retry)는 도박처럼 느껴지기 시작합니다. 저는 이런 파이프라인들을 보아왔습니다. 데모에서는 우아해 보이지만, 세 번째 장애가 발생하면 무엇이 먼저 일어났고 무엇이 부작용(side effect)이었는지 아무도 이해하지 못하게 됩니다.

저의 규칙은 꽤 지루하며, 바로 그 점 때문에 효과가 있습니다. 이메일은 창의적인 출력물로 설계되는 것이 아니라, 명확한 경계를 가진 운영 프로세스로 설계됩니다. 모델은 그 경계 안에서 글을 작성하는 것이지, 경계를 스스로 만들어내는 것이 아닙니다. 이러한 차이는 자동화(automation), LLM, 그리고 승인 흐름(approval flows)을 동시에 검토해야 할 때 노이즈를 크게 줄여줍니다.

진짜 문제는 작문이 아니라 운영이다

많은 팀이 프롬프트(prompt)부터 시작하고 운영적인 부분은 나중으로 미룹니다. 단기적으로는 빠르게 느껴지지만, 이후 세 가지 매우 전형적인 오류가 나타납니다:

• 재시도(retry) 시 이벤트는 동일함에도 불구하고 새로운 데이터로 메시지를 다시 구성함
• 인간의 승인(human approval)이 이메일의 다른 버전에 대해 이루어짐
• 로그에는 "이메일 발송됨"이라고 적혀 있지만, 에이전트가 어떤 결정을 내렸는지는 명확하지 않음

저에게 이것은 런북(runbook)이 부족하고 즉흥성이 과하다는 신호입니다. 유용한 런북은 입력(inputs), 체크포인트(checkpoints), 그리고 관찰 가능한 출력(observable outputs)을 정의합니다. 만약 이를 1분 안에 말로 그려낼 수 없다면, 그 흐름은 여전히 너무 느슨한 상태입니다.

이 아이디어는 AI에만 국한되지 않습니다. SRE(Site Reliability Engineering)에서도 마찬가지입니다. 먼저 이벤트를 제한하고, 그다음 증거를 정의하며, 마지막으로 행동을 결정합니다. 그렇기에 저는 추적 가능성을 갖춘 핸드오프(handoff) 이메일 테스트 방식이 마음에 들었습니다. 좋은 이메일이란 단순히 도착하는 이메일이 아니라, 나중에 설명할 수 있는 이메일임을 명확히 해주기 때문입니다.

작은 런북이 더 나은 경계를 만든다

제가 에이전트에 의해 생성되는 이메일에 대해 통상적으로 요구하는 최소한의 런북은 다섯 가지 요소를 포함합니다:

1. 실행을 격리하기 위한 run_id.
2. 이메일을 트리거한 것이 무엇인지 나타내는 event_type.
3. 재시도 (retry) 시 민감한 데이터를 동결하기 위한 state_snapshot.
4. 시간대, 수신자 및 폴백 (fallback)을 정의하기 위한 delivery_policy.
5. 요청 (request), 최종 렌더링 (render) 및 결과를 저장하기 위한 evidence_bundle.

말로 풀어서 설명하자면, 다이어그램은 다음과 같은 형태가 될 것입니다: 오케스트레이터 (orchestrator)가 이벤트를 수신하고, 스냅샷을 동결하며, 매우 짧은 목표를 가지고 에이전트 (agent)를 호출합니다. 그 후 렌더러 (renderer)가 고정된 규칙을 적용하고, 그제야 실행기 (executor)가 이메일을 발송합니다. 만약 한 단계가 실패한다면, 동일한 번들 (bundle)이 어느 계층에서 문제가 발생했는지 설명할 수 있어야 합니다. 거대한 플랫폼이 필요한 것이 아닙니다. 각 계층이 조금 더 지루할 정도의 책임을 갖는 것이 필요할 뿐입니다.

작은 예시:

{
  "run_id": "job_7842",
  "event_type": "approval_request",
...

이 JSON은 회사 전체를 설명하려고 시도하지 않습니다. 단지 재시도 (retry) 시 너무 많은 즉흥적 행동을 하지 않도록 흐름을 충분히 폐쇄적으로 유지할 뿐입니다. 에이전트가 포함된 시스템에서는 이 디테일이 매우 중요합니다. 왜냐하면 문제는 대개 모델이 이상하게 글을 쓰는 것이 아니라, 시스템이 고정되어 있어야 할 것들을 변경할 수 있도록 허용하는 데서 발생하기 때문입니다.

신뢰할 수 있는 흐름을 위한 말로 된 다이어그램

만약 아키텍처 리뷰에서 이를 설명해야 한다면, 다음과 같이 말하겠습니다:

1. 이벤트 생성자가 이메일이 자동화될 가치가 있는지 결정합니다.
2. 오케스트레이터가 run_id와 불변 (immutable) 스냅샷을 생성합니다.
3. 에이전트는 승인된 컨텍스트 (context)만 사용하여 초안을 작성합니다.
4. 검증기 (validator)가 제목, CTA, 수신자 및 비즈니스 규칙을 확인합니다.
5. 실행기가 전달을 완료하고 조회 가능한 증거를 저장합니다.

핵심은 결정과 실행을 분리하는 것입니다. 에이전트가 누구에게 보낼지, 얼마나 기다릴지, 그리고 확인이 오지 않을 경우 무엇을 할지까지 결정하게 되면 흐름은 매우 불투명해집니다. 저는 런북 (runbook)이 이러한 트레이드오프 (tradeoffs)를 상위 단계에 남겨두어, 가시적이고 검토 가능하게 만드는 것을 선호합니다.

이러한 패턴은 프론트엔드 (frontend)에서도 나타납니다. 예를 들어 팀이 마찰이 적은 재검증 전송 (reenvios de verificacion con menos friccion) 작업을 수행할 때, 사용자는 클릭할 때마다 새로운 우주가 열리는 듯한 느낌을 받아서는 안 됩니다. 에이전트 (agents)가 포함된 백엔드 (backends)에서도 마찬가지입니다. 만약 각 재시도 (retry)가 별개의 작업처럼 느껴진다면, 설계가 너무 많은 복잡성을 노출하고 있는 것입니다.

시스템의 중심이 되지 않으면서 임시 인박스 (inbox)를 배치하는 방법

여기서부터 실무적인 부분이 등장합니다. 때로는 실제 인박스 (inboxes)를 건드리지 않고 렌더링, 링크 또는 승인을 검증하기 위해 generate throwaway email (일회용 이메일 생성)이 필요할 때가 있습니다. 이는 합리적이라고 생각하지만, 한 가지 조건이 있습니다. 임시 인박스 (inbox)는 증거를 위한 도구여야 하며, 설계의 핵심이 되어서는 안 된다는 점입니다.

저는 이를 에이전트 (agent)의 로직이 아닌 실행 계층 (execution layer)에 배치하겠습니다. 에이전트 (agent)는 어떤 메시지가 존재해야 하는지를 결정하고, 임시 이메일 도구 (tool)는 격리, 읽기 및 만료 기능만을 제공합니다. 이 단계에서 프로바이더 (provider)가 필요하다면, free temp email과 같은 서비스가 샌드박스 (sandbox) 구성 요소로 유용할 수 있습니다. 중요한 것은 브랜딩 (branding)이 아니라, 쿼리가 결정론적 (deterministic)이어야 하고, 정리가 예측 가능해야 하며, 실행 (runs) 간에 증거가 섞이지 않는 것입니다.

또한 팀의 언어를 관리하는 것도 중요합니다. 티켓 (tickets)이나 스크립트 (scripts)에 tamp mail com과 같은 이상한 변형이 나타날 때, 저는 거의 항상 다른 부채 (debt)의 신호들을 발견합니다. 느슨한 명명 규칙, 모호한 소유권 (ownership), 또는 아무도 문서화하고 싶어 하지 않는 수동 단계들이 그것입니다. 이것이 주요 오류는 아니지만, 보통 다른 문제들과 동반되는 경우가 많습니다.

여기서의 실제 트레이드오프 (tradeoff)는 비용 대 명확성입니다:

• 더 많은 메타데이터 (metadata)와 TTL (Time To Live)은 구현 비용을 다소 증가시킵니다.
• 즉흥성을 줄이면 디버깅 (debugging) 시간을 상당히 단축할 수 있습니다.
• 더 엄격한 도구 (tool)는 빠른 데모 (demos)를 제한하지만, 일상적인 운영을 개선합니다.

State of DevOps 보고서에 따르면, 피드백 루프 (feedback loops)가 더 뛰어나고 안정적인 딜리버리 (delivery)를 갖춘 팀은 운영 마찰 (operational friction)을 줄이면서 변경 사항을 해결합니다 source. 물론 이것이 이메일에 특화된 통계는 아니지만, 다음과 같은 결정과 잘 맞닿아 있습니다: 유용한 피드백는 유용한 증거 (evidence)에 달려 있습니다.

추가 자동화 전 체크포인트 (Checkpoints)

이러한 워크플로우 (workflow)를 배포하기 전에, 저는 다음 체크리스트를 검토합니다:

1. 에이전트 (agent)가 고정된 스냅샷 (snapshot)을 수신하며, 상태를 자유롭게 조회하지 않는가?
2. 실행기 (executor)가 필수 필드가 누락된 경우 전송을 거부할 수 있는가?
3. 증거 (evidence)를 통해 시스템 전체를 다시 읽지 않고도 최종 결정을 재구성할 수 있는가?
4. 재시도 (retries) 시 컨텍스트 (context)를 새로 만드는 대신 필요한 경우 재사용하는가?
5. 임시 인박스 (inbox)에 TTL (Time To Live), 격리 (isolation), 명확한 네이밍 (naming)이 적용되어 있는가?

만약 두 개 이상의 항목에