LLM (Large Language Models)을 활용한 워크플로우가 이메일을 보내고 읽기 시작할 때, 첫 번째 병목 현상은 모델인 경우가 거의 없습니다. 거의 항상 문제는 그 주변의 큐(Queue)입니다: 문맥(Context)이 없는 메시지, 상태를 덮어쓰는 재시도(Retries), 그리고 늦게 도착하는 인간의 승인 등이 그것입니다. 저는 팀들이 프롬프트(Prompt)를 수정하는 데 수 시간을 허비하는 것을 보았지만, 실제 문제는 더 단순했습니다. 시스템이 어떤 메시지가 어떤 실행(Run)에 속하는지 설명할 수 없었던 것입니다. 만약 LLM 자동화를 설계하고 있다면, 그러한 가시성(Visibility)은 프롬프트에 대한 또 다른 미세 조정(Fine-tuning)보다 더 가치 있습니다.

LLM 에이전트가 모델보다 먼저 이메일 큐를 망가뜨리는 이유

요약본을 보내거나, 승인을 요청하거나, 이메일 응답을 소비하는 에이전트는 비동기적(Asynchronous)이고 느리며 노이즈가 많은 채널에서 작동합니다. 이는 아키텍처를 상당히 변화시킵니다. 동기식(Synchronous) API에서는 로컬 문맥(Local context)을 가정할 수 있지만, 이메일에서는 각 메시지가 워크플로우 계약(Contract)의 일부를 담고 있어야 합니다.

저의 실무적인 규칙은 이렇습니다: 만약 인간이나 워커(Worker)가 제목, 몇몇 헤더(Headers), 그리고 run_id만 보고 실행(Run)을 식별할 수 없다면, 그 설계는 이미 취약한 것입니다. 전형적인 실패는 극적이지 않습니다. 오히려 작은 문제들의 합에 가깝습니다:

• 재시도(Retry)가 오래된 요청을 다시 보냄;
• 인간의 응답이 올바른 편지함에는 도착했지만 잘못된 실행(Run)에 할당됨;
• 필터가 너무 광범위하여 에이전트가 이전 메시지를 다시 읽음.

이는 운영 메일을 위한 명확한 런북(Runbooks)에서 나타나는 운영 문제와 매우 유사합니다: 단순히 신호를 받는 것만으로는 부족하며, 모호함 없이 결정을 라우팅(Routing)할 수 있어야 합니다. LLM 시스템에서는 모델이 합리적으로 보이는 어떤 문맥(Context)이라도 따라가려는 경향이 있기 때문에, 이러한 모호함이 더 강력한 타격을 줍니다.

각 메시지에서 가시화하는 최소한의 계약

거대한 계약을 말하는 것이 아닙니다. 워크플로우를 관찰 가능(Observable)하게 만드는 최소한의 것을 말합니다:

• 실행당 짧고 안정적인 run_id.
• step_id 또는 단계 이름 (예: approval, fallback, digest).
• 예상되는 actor: 인간, 에이전트(Agent) 또는 워커(Worker).
• 응답이 여전히 유효한지 확인하기 위한 expires_at.

이 계약은 제목(Subject), 내부 메타데이터(Metadata), 그리고 로그(Logs)라는 세 곳에 동시에 존재해야 합니다. 만약 데이터베이스에만 존재한다면, 디버깅(Debug) 시점에 이미 늦게 됩니다. 만약 이메일에만 존재한다면, 워커(Worker)들은 눈먼 상태가 됩니다. 핵심 아이디어는 운영자가 이상한 고고학적 조사를 하지 않고도 히스토리를 재구성할 수 있도록 하는 것입니다.

단순화된 페이로드(Payload)는 다음과 같이 보일 수 있습니다:

{
  "run_id": "a41f9c",
  "step_id": "approval",
...

화려하지는 않지만, 효과적입니다. 또한

그래서 저는 이메일 폴백 (fallback)을 즉흥적인 출력 (output)이 아닌 명시적인 계층 (explicit layer)으로 설계하는 것을 선호합니다. 이 아이디어는 운영 혼란 없는 이메일 폴백 (fallbacks de correo sin caos operativo) 개념과 매우 잘 연결됩니다. 폴백에 계약 (contract)이 있으면 시스템은 질서 있게 성능을 저하시키지만(degrade), 계약이 없으면 그저 노이즈만 추가할 뿐입니다.

또 다른 유용한 세부 사항은 인간의 응답이 오지 않을 경우 에이전트 (agent)가 무엇을 할 수 있는지 처음부터 결정하는 것입니다:

• 지원용 인박스 (inbox)로 에스컬레이션 (escalate);
• timeout 상태로 실행 (run) 종료;
• 보수적인 경로로 계속 진행;
• 요약된 컨텍스트 (context)와 함께 새로운 승인 요청.

모든 결정을 "만약을 대비해서" 열어두어서는 안 됩니다. 그런 종류의 유연성은 똑똑해 보일 수 있지만, 추적 가능성 (traceability)을 복잡하게 만들고 자동화 (Automation)에 대한 신뢰를 떨어뜨립니다.

실행 흐름(run)을 섞이지 않게 하기 위한 구현 체크리스트

이러한 시스템을 검토할 때, 저는 짧은 목록을 사용합니다:

• 각 이메일은 데이터베이스 외부에서도 확인할 수 있는 run_id를 가집니다.
• 응답 검색 시 발신자뿐만 아니라 실행 (run) 및 단계 (stage)별로 필터링합니다.
• 재시도 (retries)는 멱등성 (idempotency)을 가지며 오래된 승인을 다시 활성화하지 않습니다.
• 타임아웃 (timeouts)은 흐름의 상태를 명시적으로 변경합니다.
• 로그 (logs)는 메시지, 결정, 워커 (worker) 사이의 관계를 저장합니다.
• 에이전트 (agent)는 무작정 전체 스레드를 복사하는 대신, 재전송 전에 컨텍스트 (context)를 요약합니다.

이 중 하나라도 빠지면 시스템은 계속 작동하는 것처럼 보일 수 있습니다... 실제 동시성 (concurrency)이 발생할 때까지는 말이죠. 그때가 되면 항상 발생하지는 않지만, 오후 전체를 잡아먹는 지저분한 버그 (bugs)들이 나타나기 시작합니다.

Q&A

이것은 복잡한 에이전트 (agents)에만 적용되나요?

아니요. 승인, 일일 요약, 확인 또는 온보딩 (onboarding) 흐름과 같은 간단한 자동화에도 적용됩니다. 비동기 이메일 (asynchronous email)이 있고 두 개 이상의 실행 (run)이 존재하는 한, 관찰 가능한 계약 (observable contract)은 이미 그 비용을 지불하고도 남습니다.

전용 큐 (dedicated queue)가 필요한가요?

반드시 그렇지는 않습니다. 이미 존재하는 큐를 사용하거나 심지어 백엔드(backend)의 잡(jobs)으로 시작할 수도 있습니다. 중요한 것은 정확한 도구가 아니라, 전달(delivery), 대기(waiting), 그리고 결정(decision) 사이의 분리입니다.

LLM이 전체 스레드(thread)를 볼 필요가 있나요?

거의 없습니다. 저는 구조화된 요약(structured summary)과 현재 상태(current state)를 전달하는 것을 선호합니다. 전체 히스토리(history)를 넣으면 컨텍스트(context)는 제공되지만, 노이즈(noise)도 함께 유입되어 에이전트(agent)가 왜 특정 방식으로 행동했는지 설명하기 더 어렵게 만듭니다.

만약 당신의 에이전트가 결정 회로(decision circuit)의 일부로 이메일을 사용한다면, 프롬프트(prompt)를 고민하기 전에 관찰 가능한 계약(observable contract)을 먼저 생각하십시오. 덜 흥미롭게 들릴 수도 있지만, 대개 이것이 더 많은 장애(incident)를 방지하는 변화가 됩니다.