AI 에이전트가 이메일을 보내기 시작할 때, 많은 사람들이 가장 먼저 프롬프트 (prompt)를 살펴봅니다. 저는 거의 그렇게 시작하지 않습니다. LLM (Large Language Models) 및 자동화 (automation)를 다루는 팀에서 취약한 지점은 대개 에이전트의 결정, 동작을 실행하는 도구, 그리고 결과를 검증하는 방식 사이의 계약 (contract)에 있습니다. 이 경계가 모호해지면, 시스템은 데모에서는 완벽해 보이지만 나중에 매우 우아하지 못한 방식으로 실패하게 됩니다.

저에게 가장 효과적인 패턴은 흐름을 말로 된 다이어그램처럼 생각하는 것입니다: 비즈니스 이벤트 (business event), 결정론적 컨텍스트 축소 (deterministic context reduction), 에이전트의 결정 (agent decision), 정규화된 명령 (normalized command), 이메일 발송, 그리고 최종 검증 (final verification). 별로 매력적으로 들리지는 않지만, 운영상의 고통을 상당히 줄여줍니다.

에이전트와 도구 사이의 계약이 핵심이다

흔한 실수는 에이전트가 어떤 이메일을 보내고 싶은지 자유롭게 기술하게 두고, 도구가 이를 "이해할" 것이라고 믿는 것입니다. 이러한 접근 방식은 취약한 통합 (fragile integrations)을 만들어냅니다. LLM은 합리적인 의도를 반환할 수 있지만, 인프라 (infrastructure)에는 구체적인 필드(fields)가 필요합니다: 템플릿 (template), 수신자 (recipient), 범위 (scope), 시간 창 (time window), 멱등성 (idempotency), 그리고 trace_id입니다.

저는 에이전트의 출력을 허용된 동작으로 제한하는 것을 선호합니다. 예를 들어 send_review_request 또는 send_retry_notice와 같은 방식입니다. 그 후, 결정론적 실행기 (deterministic executor)가 최종 명령을 구성합니다. 이 분리가 추가 단계처럼 보일 수 있지만, 시스템을 운영하기 훨씬 쉽게 만들고 테스트하기도 더 용이하게 만듭니다.

제가 보통 요구하는 최소한의 스키마 (schema)에는 다음이 포함됩니다:

• action_type
• recipient_scope
• template_version
• trace_id

이 필드 중 하나라도 누락되면 사후 조사가 이상해집니다. 실제로는 컨텍스트 (context)가 부족했거나 매핑 (mapping)이 제대로 되지 않았음에도 불구하고, 팀은 "모델이 실패했다"라고 논쟁하기 시작합니다.

AI가 트리거하는 이메일을 위한 검증 가능한 흐름

이 시스템의 가장 좋은 버전은 모든 것을 단일 계층에서 테스트하려고 하지 않습니다. 대신 다음과 같이 나눕니다:

1. 백엔드 (Backend)는 이벤트를 안전한 데이터로 축소합니다.
2. 에이전트 (Agent)는 고정된 스키마 (Schema) 내에서 동작을 선택합니다.
3. 도구 (Tool)는 권한과 필수 필드를 검증합니다.
4. 이메일 서비스는 동일한 trace_id와 함께 발송을 기록합니다.
5. 엔드 투 엔드 (End-to-end) 테스트는 격리된 편지함을 열어 콘텐츠, 수신자 및 최종 효과를 검증합니다.

이 설계는 SaaS에서 추천 이메일을 테스트하는 방법에서 얻은 유용한 아이디어를 계승합니다: 증거는 공용 편지함에 섞이지 않고 시나리오별로 분리되어 있어야 합니다. 두 흐름이 편지함을 공유하면 어설트 (Assert)가 느슨해지고 디버깅 (Debugging)이 매우 느려지게 됩니다.

실행 도구에서 코드는 상당히 짧을 수 있습니다:

def execute_agent_action(action, trace_id):
    if action["type"] != "send_review_request":
        return {"ok": False, "reason": "unsupported"}
...

중요한 것은 Python, Node 또는 Go가 아닙니다. 중요한 것은 이메일 인프라 (Infrastructure)를 건드리기 전에 최종 명령이 닫혀 있어야 한다는 점입니다. 그래야 테스트가 제공업체의 우연한 세부 사항이 아닌 계약 (Contract)을 기술하게 됩니다. 팀이 스테이징 (Staging) 환경에서 메시지를 확인하기 위해 임시 이메일 계정 생성기를 사용하더라도, 해당 구성 요소는 검증을 돕는 보조 수단이어야 하며 설계의 중심이 되어서는 안 됩니다.

또한 이름을 잘 짓는 것도 중요합니다. 여러 팀에서 티켓, 시드 (Seeds) 또는 변수에서 dummy e mail과 같은 레거시 (Legacy) 텍text를 보았습니다. 심각한 문제는 아니지만, 흐름이 패치(Patch)로 인해 성장했음을 나타냅니다. 이런 일이 발생할 때 이름과 계약을 검토하는 것은 로드맵 (Roadmap)에서 가장 눈에 띄는 부분은 아닐지라도 꽤 실질적인 개선을 가져다줍니다.

이메일 발송 실패 시 측정해야 할 것

테스트가 실패하면, 저는 다음 네 가지 증거를 순서대로 찾습니다:

• 에이전트의 원래 결정.
• 도구가 생성한 정규화된 (Normalized) 명령.
• 격리된 편지함에 도착한 메시지.
• 링크를 열거나 동작을 수락한 후의 최종 효과.

만약 이 네 가지 요소 중 하나라도 없다면, 팀은 추측을 시작하게 됩니다. 그리고 자동화 (Automation)에서 추측은 비용이 많이 듭니다. 작고 읽기 쉬운 상태 (States)를 기록하는 것도 큰 도움이 됩니다. 이는 FastAPI에서 이메일 재시도 디버깅하기와 매우 유사합니다. "동작 수락됨", "이메일 발송됨", "메시지 수신됨", "링크 검증됨"과 같은 짧은 시퀀스를 볼 수 있다면 수천 줄의 로그가 필요하지 않습니다.

이러한 규율을 정당화할 유용한 데이터가 있습니다. Accelerate 2024 보고서에 따르면, 팀이 모호한 핸드오프 (Handoffs)를 줄이고 단순한 릴리스 속도뿐만 아니라 흐름의 관측 가능성 (Observability)을 높일 때 전달 품질이 향상된다는 것을 발견했습니다 source. 이 보고서가 이메일 에이전트를 구체적으로 다루지는 않지만, 그 원칙은 매우 잘 들어맞습니다.

소규모 팀을 위한 트레이드오프 (Tradeoffs)

이 접근 방식은 구조를 추가합니다. ID, 검증, 상태, 그리고 에이전트와 발송 사이에 추가적인 계층이 존재합니다. 그 대가로 매우 가치 있는 것을 얻게 됩니다. 즉, 왜 이메일이 발송되었는지, 왜 발송되지 않았는지, 그리고 어떤 컴포넌트가 각 결정을 내렸는지를 설명할 수 있게 됩니다. 소규모 팀에게 이러한 명확성은 인상적인 데모보다 훨씬 더 가치가 있습니다.

제가 주로 보는 트레이드오프는 다음과 같습니다:

• 에이전트의 자유도는 낮아지지만, 감사 가능성 (Auditability)은 향상됨.
• 통합 단계는 늘어나지만, 기이한 디버깅 (Debugging) 상황은 줄어듦.
• 테스트는 약간 느려지지만, 신호 (Signal)는 훨씬 좋아짐.
• "마법"은 줄어들지만, 실제로 유지보수가 가능한 시스템이 됨.

저의 짧은 체크리스트입니다:

• 각 실행은 고유한 trace_id를 가짐.
• 에이전트는 유효한 스키마 (Schema) 내의 동작만 요청함.
• 도구는 수신자, 템플릿 및 컨텍스트를 재검증함.
• 각 시나리오는 고유한 편지함을 사용함.
• 최종 어설션 (Assert)은 단순히 "이메일 발송됨"이 아니라 비즈니스 효과를 확인함.

거대한 플랫폼이 필요한 것은 아닙니다. 계약(Contract)에 대한 규율과, 확률적 지능 (Probabilistic Intelligence)을 지루해야 할 부분과 섞지 않으려는 약간의 인내심이 필요할 뿐입니다. 단순하게 들리겠지만, 때로는 바로 그것이 엉망인 한 주를 구해내기도 합니다.

자주 묻는 질문 (FAQ)

LLM이 이메일 전체를 작성하게 두어야 하나요?

리스크가 낮은 경우에만 그렇습니다. 민감한 메시지의 경우, 통제된 템플릿 (Template)을 사용하고 모델이 제한된 필드나 블록을 채우도록 하는 방식을 선호합니다.

사용자가 잘못된 이메일을 받았다면 무엇을 가장 먼저 확인해야 하나요?

에이전트 (Agent)가 제안한 작업과 실행기 (Executor)의 최종 명령을 비교하십시오. 그 사이의 도약(Jump) 단계에서 수많은 침묵하는 오류 (Silent Errors)가 집중됩니다.

에이전트에 대한 유닛 테스트 (Unit Test)가 이미 있다면 실제 테스트가 필요한가요?

네. 유닛 테스트는 로컬 로직이 올바르게 보이는지 알려줍니다. 하지만 시스템 전체가 받은 편지함 (Inbox)과 최종 상태까지 계약 (Contract)을 유지하는지는 알려주지 않습니다.