Part 7: 에이전트 플로우 테스트하기: MUnit, 평가 및 감사자가 요구하는 증거

10부작 중 Part 7 · MuleSoft에서 에이전트 변경 승인 MVP 구축

Part 6에서는 팀이 도구를 어떻게 구축하는지 다루었습니다. 이번 파트에서는 우리가 그 도구들을 어떻게 테스트하고, 그 도구들을 호출하는 에이전트를 어떻게 테스트하는지를 다룹니다. 규제 변경 프로세스에서 '데모에서 작동했다'는 것은 증거가 될 수 없습니다. 품질팀은 무엇이 테스트되었는지, 어떻게 되었는지, 어떤 버전을 기준으로 했는지, 그리고 누가 승인했는지 물어볼 것입니다.

결정론적인 것들은 결정론적으로 테스트하기

우리가 따른 가장 유용한 규칙은 다음과 같습니다: 항상 같은 답변을 해야 하는 것은 정확한 테스트를 받게 하고, LLM 단계만 점수가 매겨진다. 이것이 시스템을 깔끔하게 분리하며, 대부분의 테스트 스위트가 일반적인 통합 테스트라는 것을 의미합니다.

A test pyramid for an agentic flow

레이어 1: 도구 계층을 위한 MUnit

Part 4의 모든 MCP 도구 플로우는 MUnit 테스트를 받으며, 이는 /new-mcp-tool 워크플로우로 생성되고 수동으로 마무리됩니다:

Process API가 모킹된 '해피 패스(happy path)'.
APPROVAL_MISSING, TRANSPORT_LOCKED와 같은 명명된 오류 각각에 대한 테스트를 수행하여 에이전트가 보게 될 오류 코드를 확인합니다.
스키마 테스트: 어떤 호출이 나가기 전에 잘못된 입력은 거부됩니다.

전체 스위트에서 가장 중요한 테스트는 부정(negative) 테스트입니다. import_transport_to_qa의 경우, 유효한 승인 없이 Process API를 호출하고 두 가지를 단언합니다: 결과가 APPROVAL_MISSING이어야 하며, SAP System API 모크가 0번 호출되어야 합니다 (MUnit의 verify-call에서 times를 0으로 설정). 이 하나의 테스트는 human-in-the-loop post에서 나온 승인 게이트가 코드상에서 유지됨을 증명합니다.

레이어 2: 게이트웨이에서의 정책 테스트

Part 5에서 다룬 Omni Gateway 규칙은 구성(configuration)이며, 구성 드리프트(configuration drifts)가 발생할 수 있습니다. 따라서 우리는 작은 스크립트를 사용하여 테스트 환경에서 이를 테스트합니다:

각 에이전트 ID에 대해 해당 에이전트가 접근 가능한 도구 목록을 작성하고 접근 매트릭스와 비교합니다.
각 에이전트에 대해 접근해서는 안 되는 도구를 하나 시도해보고 거부(denial)되는지 확인합니다.
테스트용으로 심어 놓은 PII(개인 식별 정보)가 포함된 프롬프트를 전송하여 PII 정책이 이를 포착하는지 확인합니다.

이 테스트는 릴리스 시점뿐만 아니라 게이트웨이가 변경될 때마다 실행됩니다.

레이어 3: 브로커 그래프에서의 시나리오 테스트

브로커의 그래프는 가지(branches), 루프(loops), 게이트를 가지고 있으며, 각각은 고정된 입력값을 가진 시나리오로 테스트됩니다:

불완전한 요청은 요청자에게 두 번 루프백(loops back)한 다음, 담당자에게 에스컬레이션(escalates)됩니다.
거부된 승인은 사유와 함께 요청을 종료하며 create_sap_change_doc에 도달하지 않습니다.
완벽하고 승인된 요청은 전체 기록과 함께 스테이지 4 핸드오프(stage 4 hand-off)에 도달합니다.

여기서는 에이전트의 추론 품질을 테스트하는 것이 아니라 라우팅(routing)을 테스트하므로, 에이전트의 결정이 명확해지도록 입력값이 선택되었습니다.

레이어 4: 에이전트를 위한 평가

답변이 달라질 수 있는 유일한 레이어입니다. 우리는 선임 분석가가 제공했던 완전성(completeness), 위험 등급(risk class), 그리고 전송 순서(transport sequence)를 포함하는 익명화된 40개의 역사적 변경 요청 골든 세트(golden set)를 구축했습니다.

각 에이전트 버전은 전체 세트를 대상으로 실행됩니다:

구조화된 필드는 정확하게 확인됩니다. 위험 등급이 일치해야 하며, 전송 순서는 모든 종속성을 존중해야 합니다.
자유 형식 출력은 점수가 매겨집니다. Omni Gateway의 A2A 품질 평가 정책(Quality Evaluation policy)은 각 응답을 심사 LLM(judge LLM)에 보내 요청이 처리되었는지 여부(yes/no), 1~3점의 품질 점수, 그리고 설명과 함께 응답 헤더 및 메트릭으로 반환합니다. 이는 아무것도 차단하지 않기 때문에, 우리는 이 점수들을 수집하고 자체적인 출시 임계값(release threshold)을 설정합니다.

새로운 프롬프트나 모델 버전은 골든 세트에서 이전 버전을 일치하거나 능가할 때만 배포됩니다. 각 버전에 대한 점수는 증거 패키지(evidence pack)에 포함됩니다.

Layer 5: 인간의 승인 (human sign-off)

실제 운영 환경(go-live)에 들어가기 전에, 비즈니스 오너들은 테스트 환경에서 실제와 유사한 요청 샘플을 실행하고 승인 에이전트(Approval agent)가 구축한 패키지에 서명합니다. 이는 프로세스가 항상 가져왔던 인간의 관문(human gate)과 동일하며, 시스템 자체에 적용된 것입니다.

운영 환경에 영향을 주지 않는 테스트 데이터 (Test data without touching production)

이 모든 과정은 합성 전송(synthetic transports), 테스트 ITSM 인스턴스, 그리고 테스트 승인자들을 가진 비운영 SAP 클라이언트에서 실행됩니다. 운영 시스템은 결코 테스트에 나타나지 않으며, 누군가 시도하더라도 게이트웨이의 프롬프트 가드(prompt guard)가 운영 시스템 이름을 차단합니다.

증거 패키지 (The evidence pack)

각 출시마다 품질 팀에게 전달하는 내용:

모든 도구 및 프로세스 API에 대한 MUnit 결과, 여기에는 제로콜 SAP 테스트도 포함됩니다.
접근 매트릭스(access matrix)를 대상으로 한 게이트웨이 정책 테스트 결과.
그래프 시나리오 결과.
각 에이전트에 대한 골든 세트 점수와 이전 버전과의 비교.
비즈니스 오너가 서명한 UAT 기록.

누가 무엇을 소유하는가 (Who owns what)

통합 팀(Integration team): MUnit 및 프로세스 API 테스트.
플랫폼 팀(Platform team): 게이트웨이 정책 테스트.
에이전트 팀(Agent team): 그래프 시나리오, 골든 세트 및 평가 임계값.
품질 및 비즈니스 오너: 승인 서명 (sign-off).

다음 내용 (Next)

Part 8에서는 배포에 대해 다룹니다: Mule 앱과 에이전트 네트워크의 CI/CD, 환경을 거쳐 프로모션하는 방법, 그리고 에이전트를 롤백하는 방법을 다룰 것입니다.

당신의 골든 세트에는 무엇을 가장 먼저 넣겠습니까?

본 시리즈는 가상의 회사에 기반한 레퍼런스 모델을 설명합니다. 제품 기능은 2026년 10월 기준의 MuleSoft 문서를 바탕으로 하므로, 구축하기 전에 최신 문서를 확인하십시오.