팀이 이메일 워크플로우에 LLM을 도입할 때, 대화는 보통 모델, 프롬프트(Prompt) 또는 지연 시간(Latency)에서 시작됩니다. 저는 거의 항상 다른 곳, 즉 승인 경로(Approval route)에서 시작합니다. 만약 그 경로가 메시지의 컨텍스트(Context)를 제대로 고정하지 않는다면, 매 재시도(Retry)마다 약간씩 다른 버전이 생성될 수 있으며, 시스템은 결국 실제로 전송될 내용과 일치하지 않는 내용을 승인하게 됩니다. 항상 문제가 터지는 것은 아니지만, 문제가 발생할 때는 꽤 지저분한 흔적을 남깁니다.

실질적인 아이디어는 승인을 파이프라인(Pipeline) 끝에 있는 버튼이 아니라, 아키텍처 계약(Architecture contract)으로 취급하는 것입니다. 이메일이 작성되면 스냅샷(Snapshot)을 동결하고, 검토하고, 서명한 후에야 비로소 해제합니다. 처음에는 많은 사람들이 원하는 것보다 더 격식 있게 느껴질 수 있지만, 큐(Queue), 워커(Worker), 그리고 중간에 개입하는 인간이 있을 때 발생하는 수많은 혼란을 방지해 줍니다.

진짜 문제는 모델이 아니다

이메일의 첫 번째 렌더링(Rendering)은 잘 나오지만, 두 번째 시도에서 티켓 이름, 케이스 상태, 만료 날짜 또는 심지어 다른 CTA(Call to Action)와 같은 실시간 데이터를 다시 조회하는 파이프라인을 본 적이 있습니다. 여기서 드리프트(Drift, 편차)가 발생합니다. 승인자는 한 가지를 보았지만, 최종 사용자는 다른 것을 받게 됩니다. 지원(Support) 또는 컴플라이언스(Compliance) 환경에서 이 디테일은 더 이상 작은 문제가 아니라 사고의 원인이 됩니다.

저에게 가장 잘 작동하는 아키텍처는 세 가지 요소를 분리합니다:

1. 최소한의 메타데이터(Metadata)를 포함한 초안 생성
2. 승인된 콘텐츠의 불변 스냅샷(Immutable snapshot)
3. 서명된 아티팩트(Artifact)만 소비하는 전달 큐(Delivery queue)

말로 설명하자면, 다이어그램은 다음과 같습니다: LLM 에이전트가 run_id, message_type, policy_version을 포함한 초안을 생성합니다. 검토 레이어(Revision layer)가 해당 초안의 생존 여부를 결정합니다. 그 다음 안정적인 큐(Stable queue)가 정확히 그 페이로드(Payload)를 가져가며, 모델에게 더 이상 아무것도 묻지 않습니다. 나중에 전송을 다시 해야 할 경우, 스냅샷을 재사용하며 전체 생성을 반복하지 않습니다. 화려하지는 않지만 매우 유용합니다.

스냅샷과 안정적인 큐를 이용한 승인 경로

이러한 유형의 워크플로우를 위해 저는 짧은 계약을 선호합니다:

{
  "run_id": "appr_2048",
  "message_type": "approval_request",
...

이 계약은 두 가지를 수행합니다. 첫째, 승인이 정확한 아티팩트 (artifact)를 가리키도록 강제합니다. 둘째, 이메일이 이미 검증되었을 때 큐 (queue)가 다시 활성 상태 (live state)를 건드리는 것을 방지합니다. 만약 당신의 파이프라인 (pipeline)이 접근 가능한 상태를 이용한 React 이메일 테스트와 유사한 개념을 공유한다면, 아마 이 원칙을 이미 알고 있을 것입니다: 사람이 보는 상태는 시스템이 실제로 실행하는 내용과 일치해야 합니다.

또한 어떤 필드를 재수화 (rehydrate)할 수 있고 어떤 필드를 할 수 없는지 결정하는 것이 좋습니다. 저는 보통 재계산 가능한 만료 날짜나 마지막에 생성된 트래킹 URL (tracking URL)과 같은 운영 값 (operational values)만 허용합니다. 제목, 승인된 본문, 그리고 실제 수신자는 스냅샷 (snapshot)에서 가져와야 합니다. 이러한 경계를 설정하지 않으면 워커 (worker)가 소스를 혼합하기 시작하고, 검토 (review)는 매우 빠르게 의미를 잃게 됩니다.

재시도 시 드리프트 (drift)가 발생하는 지점

드리프트 (drift)는 거의 영웅적인 거대한 버그를 통해 발생하지 않습니다. 세 가지 흔한 지름길을 통해 발생합니다:

• 워커 (worker)가 전송 전에 케이스 상태를 다시 조회함
• 승인이 구체적인 내용이 아닌 불리언 (boolean) 값을 저장함
• 재시도 (retry) 시 "더 쉽다"는 이유로 초안을 다시 생성함

마지막 지점이 가장 많은 문제를 일으킵니다. 자동화 팀에서는 모든 것을 재생성하려는 유혹이 강한데, 그것이 단순해 보이기 때문입니다. 하지만 표면적으로 단순한 아키텍처 (architecture)는 나중에 더 큰 비용을 치를 수 있습니다. 만약 실행 (run)이 브랜치 (branch), 템플릿 (template), 또는 비즈니스 규칙 (business rule)을 변경하게 되면, 서로 엇갈린 증거들을 마주하게 됩니다. 이는 FastAPI에서 트랜잭션 이메일을 테스트하는 방법에서 발생하는 현상과 매우 유사합니다: 편지함 (inbox), 이벤트 (event), 그리고 컨텍스트 (context)를 격리하지 않으면 진단 (diagnosis)이 느려지고 불공정해질 수 있습니다.

스테이징 (staging) 환경에서 일부 사람들은 실제 편지함(mailbox)을 건드리지 않고 출력을 관찰하기 위해 임시 이메일 생성 도구를 사용하기도 합니다. 물론 그것도 도움이 될 수 있습니다. 누군가 흐름을 빠르게 문서화할 때 'tempail'과 같은 단어가 포함된 내부 노트를 본 적도 있습니다. 하지만 진정한 가치는 일회용 편지함에 있는 것이 아니라, 파이프라인 (pipeline)이 어떤 버전의 메시지가 승인되었는지, 어떤 해시 (hash)가 전송되었는지, 그리고 재시도 (retry) 시 어떤 스냅샷 (snapshot)을 재사용했는지를 지루할 정도로 명확하게 설명할 수 있는지에 있습니다. 그러한 명확함이 수 시간의 조사 시간을 아껴줍니다.

가치 있는 체크포인트 (Checkpoints)

기존 시스템을 완전히 새로 만들지 않고 강화해야 한다면, 저는 다음 체크포인트 (checkpoints)부터 시작하겠습니다:

1. 인간 또는 자동 검토 전 draft_hash 저장.
2. 최종 본문을 가리키는 approved_snapshot_id 유지.
3. 큐 (queue)가 프롬프트 (prompt)가 아닌 스냅샷 (snapshot)을 소비하도록 설정.
4. approved_at과 sent_at을 별도로 기록.
5. 승인된 해시 (hash)를 변경하려는 재시도 (retry) 차단.

트레이드오프 (tradeoff)는 상당히 정직합니다. 저장 공간 (storage), 약간의 규율, 그리고 몇 가지 추가 검증이 필요합니다. 그 대가로 추적 가능성 (traceability)을 얻고, 예상치 못한 상황을 줄이며, 사용자가 검토된 내용과 다른 텍스트를 받은 이유를 누군가 물었을 때 훨씬 더 깔끔한 설명을 제공할 수 있습니다. LLM과 자동화가 포함된 제품에서, 저에게 이 교환은 이미 충분한 가치가 있습니다.

Q&A

모든 경우에 인간의 승인이 필요한가요?

아니요. 일상적인 알림이나 내부 메시지의 경우, 규칙 기반의 자동 승인만으로도 충분할 수 있습니다. 중요한 것은 추상적인 약속이 아니라 구체적인 스냅샷 (snapshot)을 계속 승인하는 것입니다.

승인 후에 이메일을 변경해야 한다면 어떻게 하나요?

그렇다면 다른 스냅샷 (snapshot)을 만들고 다른 승인을 받으세요. 조금 더 번거롭긴 하지만, 나중에 아무도 제대로 감사 (audit)할 수 없는 전형적인 "딱 한 줄만 수정했어요" 식의 연쇄 반응을 방지할 수 있습니다.

tempmail은 어디에 해당하나요?

배송이나 테스트를 검토하기 위한 운영 지원으로서의 역할이며, 설계의 중심은 아닙니다. 설계의 중심은 LLM, 승인된 스냅샷 (approved snapshot), 그리고 멱등성 큐 (idempotent queue) 사이의 관계여야 합니다.