LLM 에이전트가 티켓을 열거나, 승인을 트리거하거나, 이메일로 요약본을 보내기 시작하면 문제는 더 이상 "프롬프트 (prompt)가 작동하는가"에만 국한되지 않습니다. 전체 시스템은 결정 (decision), 실행 (execution), 검증 (verification)이라는 세 가지 별개의 계층에 의존하게 됩니다. 만약 이 계층들이 서로 뒤섞여 버린다면, 팀은 받은 편지함을 바라보며 에이전트가 실제로 무엇을 했는지 추측해야 하는 상황에 처하게 됩니다.

이러한 패턴은 자동화 (Automation) 워크플로에서 자주 나타납니다. 이메일이 마지막 단계처럼 보이지만, 실제로는 오류가 가장 먼저 드러나는 지점이기 때문입니다. 에이전트가 요청을 잘 분류하더라도 수신자에게 잘못된 메시지를 보내거나, 전송을 반복하거나, 만료된 링크를 사용할 수 있습니다. 바로 이 지점에서 프롬프트뿐만 아니라 테스트와 추적 (trace)을 격리해야 할 필요성이 생겨납니다.

또한 매우 인간적인 요소도 영향을 미칩니다. 팀원 누군가가 임시 메일 (temp mail)이나 일회용 메일 주소 (disposable mail address)를 찾는다면, 그것은 거의 항상 "성장 (growth)" 도구를 찾는 것이 아닙니다. 시스템을 관찰하기 위한 깨끗한 환경을 찾는 것입니다. 이전 메시지들의 노이즈 없이 에이전트가 무엇을 생성했는지 확인하고 싶은 것이며, 이는 매우 합리적인 요구입니다.

LLM이 이메일을 다룰 때 이 문제가 발생하는 이유

전형적인 흐름에서는 API가 이벤트를 수신하여 큐 (queue)로 전달하면 워커 (worker)가 이메일을 발송합니다. 그 사이에 LLM이 개입하면 또 다른 단계가 나타납니다. 바로 제목, 우선순위, 템플릿 (template), 또는 이메일 발송 여부까지 변경할 수 있는 확률론적 결정 (probabilistic decision) 단계입니다. 이 단계 자체가 나쁜 것은 아니지만, 책임을 더 세심하게 분리할 것을 요구합니다.

저는 이를 말로 설명하는 다이어그램처럼 생각하곤 합니다:

1. 비즈니스 이벤트가 유입됩니다.
2. 결정론적 (deterministic) 구성 요소가 컨텍스트 (context)와 규칙을 준비합니다.
3. LLM이 명확한 제한 범위 내에서 결정하거나 초안을 작성합니다.
4. 실행기 (executor)가 해당 출력을 검증 가능한 명령으로 변환합니다.
5. 이메일 시스템이 메시지를 전달합니다.
6. 테스트가 콘텐츠, 수신자 및 최종 효과를 확인합니다.

만약 이러한 단계를 하나의 테스트에 섞으면, 실패가 불투명해집니다. 오류가 모델 때문인지, 도구 정책 때문인지, 워커(worker) 때문인지, 아니면 검증에 사용된 사서함 때문인지 알 수 없습니다. 그래서 저는 초기 이벤트부터 최종 클릭까지 공유되는 trace_id를 사용하여 흐름의 모든 경계를 측정하는 것을 선호합니다.

결정, 전송 및 검증을 분리한 플로우 설계

가장 안정적인 설계는 한 번에 '지능'을 테스트하려고 하지 않습니다. 시스템을 작은 계약(contracts)들로 나눕니다:

• 입력 계약: 에이전트가 사용할 수 있는 데이터와 요청할 수 있는 권한 있는 동작.
• 실행 계약: 해당 동작이 구체적인 이메일 전송으로 어떻게 변환되는지.
• 관측 가능성(Observability) 계약: 로그, 수신된 메시지 및 시스템의 최종 상태를 연결하는 방법.

이 지점에서 FastAPI에서 트랜잭션 이메일을 테스트하는 방법 같은 근처 가이드의 모범 사례를 복사하는 것이 큰 도움이 됩니다. 스택은 바뀔 수 있지만, 근본적인 아이디어는 같습니다. 시나리오당 하나의 사서함, 테스트당 하나의 의도(intention), 그리고 순서를 재구성할 간단한 방법이 필요합니다.

LLM 에이전트의 경우, 이메일을 프롬프트 자유 영역 밖에 두어야 합니다. 모델은 send_followup_email을 제안할 수 있지만, 헤더, 대체 수신자 또는 재시도 정책을 직접 결정해서는 안 됩니다. 이러한 변환은 결정론적(deterministic) 코드에 존재해야 합니다. 덜 '마법적'하게 들리지만, 실제로는 운영 위험을 상당히 낮춥니다.

최소 구현은 다음과 같을 수 있습니다:

def handle_agent_action(action, trace_id):
    if action["type"] != "send_followup_email":
        return {"ok": False, "reason": "unsupported_action"}
...

이것이 모든 것을 해결하지는 않지만, 명확한 경계를 만듭니다: LLM은 제안하고, 시스템이 검증하며, 실행기가 전송합니다. 이 작은 세부 사항이 나중에 혼란스러운 디버깅을 많이 방지해 줍니다.

에이전트의 실패를 이메일의 실패와 혼동하지 않기 위해 관찰해야 할 것들

여기서 유용한 관찰성 (Observability)은 거창한 것이 아닙니다. 단지 올바른 지점들을 연결하기만 하면 됩니다. 저는 다음 네 가지 신호를 검토할 것입니다:

• 에이전트가 생성한 결정과 그 결정을 만들어낸 컨텍스트 (Context).
• 이메일 실행기 (Email executor)에게 전달된 최종 명령.
• 격리된 편지함 (Isolated inbox)에 수신된 메시지.
• 링크를 클릭하거나 동작을 확인한 후의 최종 효과.

이러한 요소 중 하나라도 누락되면, 팀은 설명을 지어내기 시작합니다. "분명 모델 문제였을 거야.", "분명 제공업체 문제였을 거야."라고 말이죠. 때로는 맞는 말일 수도 있지만, 많은 경우 레이스 컨디션 (Race condition)이나 공유 편지함 때문인 경우가 많습니다. 업그레이드, 갱신 또는 트라이얼 (Trial)과 같은 여러 고부하 흐름이 존재하는 환경에서 발생하는 노이즈는 SaaS 온보딩 테스트에서 언급되는 내용과 매우 유사합니다. 즉, 하나의 편지함이 여러 시나리오의 메시지를 받게 되면 테스트의 신뢰도는 급격히 떨어집니다.

또한 팀이 티켓이나 런북 (Runbook)에서 사용하는 용어와 약어를 기록해 두는 것도 좋습니다. 저는 tepm mail com이나 temp mailid와 같이 즉흥적으로 작성된 메모들을 본 적이 있습니다. 심각한 문제는 아니지만, 이는 일상적인 운영이 반복 가능한 절차보다는 비공식적인 기억에 더 많이 의존하고 있음을 나타냅니다. 시스템이 커지면 이는 결국 대가를 치르게 됩니다.

더 강력한 검증을 원한다면, 에이전트가 요청한 동작과 실제로 실행된 동작을 비교하는 단계를 추가하십시오. 만약 모델이 "결제 리마인더"를 제안했는데 결과적으로 "환영 메시지"가 발송되었다면, 10개의 대시보드를 확인하지 않고도 실패 지점을 찾아낸 것입니다.

프로덕션 투입 전 트레이드오프 (Tradeoffs) 및 체크리스트

계약을 분리하는 것은 약간의 마찰을 발생시킵니다. 더 많은 로그, 더 많은 ID, 그리고 약간 더 많은 통합 작업이 필요합니다. 하지만 그 비용은 매우 가치 있는 것을 삽니다. 바로 이메일이 왜 발송되었는지, 왜 발송되지 않았는지, 혹은 왜 잘못 발송되었는지를 설명할 수 있는 능력입니다. LLM 기반 시스템에서 이러한 설명 가능성 (Explainability)은 때로는 드러나지 않더라도 제품의 거의 필수적인 부분입니다.

워크플로를 배포하기 전에 저는 다음과 같은 트레이드오프를 평가할 것입니다:

• 결정론적 (Deterministic) 제어가 높을수록 에이전트의 자유도는 줄어들지만, 감사 (Auditing) 능력은 향상됩니다.
• 시나리오별로 격리된 편지함 (Isolated inboxes)은 운영 비용이 약간 더 발생하지만, 오탐 (False positives)을 줄여줍니다.
• 자동 재시도 (Automatic retries)는 전달에 도움이 되지만, 멱등성 (Idempotency)이 보장되지 않으면 중복 발생을 숨길 수 있습니다.
• 엔드 투 엔드 (End-to-end) 테스트는 더 느리지만, 모의 객체 (Mock)로는 절대 발견할 수 없는 오류를 찾아냅니다.

짧은 체크리스트:

• 각 실행은 고유한 trace_id를 가집니다.
• LLM은 유효한 스키마 (Schema) 내에서만 액션을 요청할 수 있습니다.
• 이메일 실행기 (Email executor)는 수신자, 템플릿, 컨텍스트를 다시 검증합니다.
• 테스트 편지함은 단일 시나리오에만 속합니다.
• 최종 클릭은 예상된 상태 변경을 확인합니다.
• 로그를 통해 과도한 추측 없이 사례를 추적할 수 있습니다.

첫날부터 완벽함을 추구할 필요는 없습니다. 중요한 것은 팀이 내일도 이 흐름을 반복할 수 있고, 무슨 일이 일어났는지 이해하며, 큰 문제 없이 수정할 수 있어야 한다는 점입니다. 이 지점은 단순해 보일 수 있지만, 보기 좋은 실험과 유용한 자동화를 가르는 기준이 됩니다.

자주 묻는 질문 (FAQ)

LLM이 이메일 본문 전체를 작성하도록 두어야 하나요?

위험도에 따라 다릅니다. 민감한 이메일의 경우, 모델이 제한된 블록만 채우고 주요 템플릿은 코드나 제어된 CMS 내에 유지하는 방식을 선호합니다.

에이전트가 "모든 것을 잘 수행했음에도" 사용자가 예상한 내용을 받지 못했다면 무엇을 먼저 테스트해야 하나요?

먼저 제안된 액션과 실제로 실행된 명령을 비교하겠습니다. 그다음 격리된 편지함과 최종 링크를 검토할 것입니다. 많은 경우 문제는 그 중간 단계의 변환 과정에서 발생합니다.

프롬프트와 워커 (Worker)에 대한 유닛 테스트 (Unit tests)가 이미 있다면 실제 테스트가 필요한가요?

네, 필요합니다. 유닛 테스트도 유용하지만, 결정, 전송, 검증 사이의 전체 체인을 완전히 포착하지는 못합니다. LLM이 포함된 시스템에서는 컴포넌트 사이의 바로 그 경계에서 여러 희귀한 오류들이 숨어 있습니다.