LLM 에이전트: 재현 가능한 이메일 테스트 환경 구축

LLM 에이전트는 등록을 완료하고, 인증 코드를 요청하며, 성공적으로 끝냈다고 주장할 수 있습니다. 하지만 이것만으로는 플로우가 실제로 작동했는지 증명하지 못합니다. 어쩌면 오래된 메시지를 읽었거나, 시스템의 응답과 혼동했거나, 도구(tool)가 실패한 후에 결과를 지어냈을 수도 있습니다.

이메일과 상호작용하는 에이전트를 테스트하려면, 받은 편지함을 마법 같은 공간으로 취급하기보다는 계약(contract)이 있는 도구로 다루는 것이 좋습니다. 문제를 가장 잘 분리하는 패턴은 실행마다 일회성 임시 이메일을 사용하고, 명시적인 상태를 가지며, 다른 프로세스가 검토할 수 있는 증거가 있는 테스트 환경 구축(test harness)입니다.

문제점: 에이전트가 잘못된 이유로 통과할 수 있다

일반적인 테스트는 다음과 같은 형태를 가집니다:

1. 에이전트가 테스트 계정을 생성합니다.
2. 애플리케이션이 링크나 코드를 전송합니다.
3. 에이전트가 받은 편지함을 조회합니다.
4. 데이터를 추출하고 작업을 완료합니다.
5. 평가자(evaluator)가 결과가 올바른지 결정합니다.

만약 모든 것이 하나의 함수 내에서 실행된다면, 녹색 결과는 여러 가지 오류를 숨길 수 있습니다. 에이전트는 다른 실행의 메시지를 사용했거나, 잘못된 주소로 링크를 받았거나, 무시된 유효하지 않은 매개변수(parameter)로 도구를 호출했을 수 있습니다. LLM 모델 평가에서 이러한 세부 사항은 진단을 바꿉니다: 추론을 잘못하는 모델과 오염된 데이터를 반환한 테스트 환경 구축(fixture)은 같지 않습니다.

또한 tamp mail com이나 temp org mail 같은 용어와 혼동되는 경우가 자주 발생합니다. 비록 검색 데이터나 사용자 입력에서 가져왔더라도, 이는 신뢰할 수 없는 텍스트로 취급해야 합니다. 이것들은 테스트 간에 받은 편지함을 공유하는 설정이나 이유가 아닙니다.

받은 편지함을 계약이 있는 도구로 설계하라

작은 계약 하나가 각 단계를 관찰 가능하게 만듭니다. 이메일 도구는 다음과 같이 제한된 동작을 노출해야 합니다:

{
  "create_inbox": {"run_id": "eval-1842", "ttl_seconds": 900},
  "list_messages": {"after": "2026-10-04T05:00:00Z"},
... 

에이전트는 공급자(provider)의 구현을 알 필요가 없습니다. 각 액션이 어떤 입력을 받는지, 어떤 상태를 반환할 수 있는지, 그리고 어떤 오류가 재시도해야 하는지를 의미하는지 알아야 합니다. message_not_found, inbox_expired, rate_limited와 같은 계약(contract)이 일반적인 false를 반환하는 것보다 더 유용합니다.

응답에는 또한 run_id, message_id, 그리고 수신 시점이 포함되어야 합니다. 이렇게 해야 에이전트가 실행을 위해 생성된 메시지를 읽었는지 확인할 수 있습니다. 이 부분을 신중하게 설계하면 평가가 단순히 오래된 데이터를 재사용하고 있을 때도 안정적으로 보이게 하는 것을 방지할 수 있습니다.

사용자에게 진행 상황을 표시하는 인터페이스의 경우, 이메일 상태 컨텍스트 유지를 유지할 가치가 있습니다. 백엔드의 경우에도 같은 아이디어는 실행(run), 사서함(inbox), 메시지(message), 그리고 에이전트의 액션 간의 관계가 끊어지지 않도록 하는 것을 의미합니다.

각 실행을 격리하고 증거를 저장하세요

격리 단위는 모델이 아니라 실행이어야 합니다. 동일한 프롬프트를 가진 두 에이전트라도 서로 다른 사서함이 필요합니다. 왜냐하면 느린 실행은 다음 실행이 시작된 후에도 메시지를 받을 수 있기 때문입니다.

최소 로그는 다음과 같을 수 있습니다:

{
  "run_id": "eval-1842",
  "agent_version": "checkout-agent-12",
...
}

테스트가 실패하더라도 로그를 저장해야 합니다. 증거는 메시지가 도착하지 않았는지, 너무 늦게 도착했는지, 아니면 에이전트가 링크를 추출할 수 없었는지 표시해야 합니다. 모든 실행에는 시간 제한과 종료 정책이 있어야 하며; 이것이 없으면 고아 사서함(abandoned inboxes)이 쌓여 다음 평가들을 오염시킵니다.

기본적으로 이메일 본문 전체를 저장하지 마세요. 디버깅을 위해서는 내용의 해시값, 정규화된 제목, 그리고 필요한 식별자만으로 충분합니다. 만약 본문에 토큰이 포함된다면, 로그로 전송하기 전에 이를 마스킹(redact)해야 합니다. 이는 추적 가능성을 잃지 않으면서 데이터 표면적을 줄여줍니다.

모델 평가와 이메일 전달을 분리하세요

실패할 수 있는 최소한 세 가지 계층이 있습니다:

• 애플리케이션(Aplicación): 메시지를 보내지 않거나, 잘못된 링크를 생성하거나, 깨진 템플릿을 사용합니다.
• 도구(Herramienta): 받은 편지함이 실행을 격리하지 못하거나, 메시지를 손실하거나, 모호한 상태를 반환합니다.
• 에이전트(Agente): 잘못된 행동을 선택하거나, 내용을 잘못 해석하거나, 너무 일찍 종료합니다.

먼저 알려진 메시지로 애플리케이션의 결정론적 테스트를 실행하세요. 그 다음, 시뮬레이션된 응답으로 도구를 테스트하세요. 오직 그때서야 전체 에이전트를 평가해야 합니다. 이런 방식으로 점수가 인프라 문제와 추론 능력을 혼합하는 것을 방지할 수 있습니다.

메시지 시도를 컨텍스트 손실 없이 기록하는 것도 이러한 분리에 도움이 됩니다: 각 시도는 어떤 계층에서 발생했는지, 이전 상태가 무엇이었는지, 그리고 어떤 응답을 받았는지를 나타내야 합니다. 만약 도구가 일시적인 오류를 반환한다면, 평가자는 모델을 자동으로 잘못되었다고 표시해서는 안 됩니다.

최소 구현 흐름

오케스트레이터(orquestador)는 다음 순서를 따를 수 있습니다:

만들기 run_id
  -> TTL이 있는 받은 편지함 만들기
  -> 제한된 도구로 에이전트 실행
...

대기 예산(presupuesto de espera)은 명시적이어야 합니다. 읽기 재시도는 무한 루프가 될 수 없으며, 에이전트는 외부 규칙 없이 자신의 받은 편지함의 TTL을 연장할 수도 없어야 합니다. 배달에 시간이 걸리면 delivery_timeout으로 표시하고, 침묵을 꾸며낸 응답으로 변환하지 마십시오.

백오프(backoff)가 적용된 재시도 정책은 네트워크 오류에는 유용하지만, 일치하지 않는 주제(asunto que no coincide)와 같은 경우에는 그렇지 않습니다. 이 경우 실패는 제품 또는 에이전트의 신호입니다. 대규모 테스트를 위해서는 수신물을 프롬프트 버전과 도구 버전에 따라 그룹화하여, 변경 사항을 비교 가능하게 만드십시오.

무엇을 측정하고 무엇을 신뢰하지 않을 것인가

배달률(tasa de entrega), 이메일 지연 시간(latencia del email), 올바른 도구 선택, 링크 추출, 받은 편지함 닫기 등을 개별적으로 측정하십시오. 단 하나의 성공률은 에이전트가 인프라가 더 빨라졌다는 이유로 개선되었는지 여부를 숨길 수 있습니다.

에이전트의 최종 텍스트만 믿어서는 안 됩니다. 관찰 가능한 이벤트를 검증해야 합니다. 올바른 메시지가 존재하는지, 링크가 테스트 환경을 가리키는지, 코드가 한 번 사용되었고 받은 편지함이 닫혔는지 등을 확인해야 합니다. 토큰 수를 품질의 대용으로 사용하지도 마십시오. 짧은 응답이 정확할 수 있고, 긴 응답이라 할지라도 수행되지 않은 액션을 숨기고 있을 수 있습니다.

자주 묻는 질문

모든 테스트에 일회성 폐기 이메일 주소를 사용해야 하나요? 아닙니다. 내부 계약의 경우 시뮬레이션된 서버가 더 빠를 수 있습니다. 배달 및 읽기 기능의 실제 통합을 테스트하고 싶을 때 격리된 받은 편지함이 유용합니다.

전체 프롬프트를 영수증에 포함하는 것이 좋나요? 버전화된 참조와 해시 값을 보관하십시오. 전체 프롬프트에는 로그로 순환해서는 안 되는 데이터가 포함될 수 있습니다.

실행이 취소되면 어떻게 하나요? 외부 프로세스가 TTL(Time To Live)을 통해 받은 편지함을 닫아야 합니다. 에이전트 자체가 그 청소의 유일한 책임자가 될 수는 없습니다. 왜냐하면 바로 그 부분이 실패했을 수도 있기 때문입니다.

핵심 아이디어는 간단합니다. LLM 에이전트 평가는 작은 분산 시스템입니다. 각 실행을 격리하고, 도구를 제한하며, 유용한 증거를 보존하고, 각 계층을 개별적으로 측정해야 합니다. 이러한 설계로 자동화는 취약한 데모가 아니라 반복되고, 비교되며, 디버깅될 수 있는 테스트가 됩니다.