Human-in-the-loop는 설계 기능입니다: MuleSoft에서 AI 에이전트의 승인 게이트를 강제하는 방법

Part 1에 대한 보충 자료 · MuleSoft에서 에이전트 기반 변경 승인 MVP 구축하기

사람들이 에이전트 시스템을 시연할 때, 인간의 승인 단계는 종종 민망한 부분으로 취급됩니다. 나중에 자동화로 제거해 버릴 부분이 되는 것이죠.

규제가 적용되는 프로세스에서는 그 반대입니다. 이 승인 자체가 제품입니다. 감사자(Auditors), 품질 팀, 그리고 변경 자문 위원회(change advisory board)가 이것에 의존합니다. 문제는 어떻게 제거할지 하는 것이 아니라, 어떻게 설계해야 빠르고 우회하기 어려우며 완전히 추적 가능한지가 문제입니다.

이 글에서는 SAP 변경 사항을 프로덕션으로 승격시키는 데 사용하는 패턴을 소개합니다. (배경: Part 1 및 자동화할 것을 결정하기 위한 2x2.)

1. 에이전트가 승인 패키지를 구축합니다. 변경 요약(change summary), 전송 내용물(transport contents), 테스트 증거(test evidence) 및 위험 요약(risk summary)을 한 곳에 모읍니다.
2. request_approval 도구를 호출합니다. 이는 Mule API를 기반으로 하는 MCP 도구로, ITSM 시스템에 승인 작업(approval task)을 생성합니다. 에이전트 자체로는 아무것도 승인할 수 없습니다.
3. 사람이 검토하고 승인합니다. 그 사람의 신원과 타임스탬프가 ITSM 시스템에 기록되며, 이 시스템은 approval_id를 발급합니다.
4. 에이전트는 변경 ID와 승인 ID를 포함하여 import_to_prod를 호출합니다.
5. Omni Gateway가 정책을 먼저 적용합니다. MCP 도구의 allow-list는 에이전트가 해당 도구를 볼 수 있는지 여부를 결정하고, 속성 기반 접근 제어(attribute-based access control)가 호출자의 클레임(claims)을 확인합니다.
6. Mule API가 승인을 검증합니다. 승인 ID가 존재하는지, 이 변경 사항과 일치하는지, 그리고 만료되지 않았고 사용되지 않았는지 확인합니다. 그래야만 SAP에 전송물을 가져오는(import) 작업을 호출합니다.
7. 감사 기록이 작성됩니다. 누가 승인했는지, 무엇을 보았는지, 그리고 무엇이 실행되었는지를 기록합니다.

어떤 검증이라도 실패하면, 도구는 명확한 오류와 함께 거부하며 SAP에는 아무것도 영향을 미치지 않습니다.

세 가지 설계 규칙

1. 지시하지 말고 강제하라 (Enforce, don't instruct)

시스템 프롬프트에

모든 게이트는 사후에 다음 질문에 답해야 합니다: 누가 승인했는지, 언제 했는지, 무엇을 보여주었는지, 그리고 그 결과 어떤 것이 실행되었는지. 이것이 에이전트 워크플로우를 '흥미로운' 것에서 검증된 환경이 실제로 수용할 수 있는 무언가로 바꿉니다.

누가 무엇을 소유하는가

이 패턴은 팀별로 깔끔하게 분리됩니다:

• Agent팀: 패키지를 구축하고 거절(refusals)을 우아하게 처리합니다.
• Integration팀: request_approval 및 import_to_prod 도구, 승인 검증 및 감사 기록을 담당합니다.
• Platform팀: 게이트웨이 정책, ID(identities), 환경을 관리합니다.

다음 내용

Part 2에서는 전체 레퍼런스 아키텍처: Agent Fabric, Omni Gateway, MCP 도구 및 SAP와 ITSM 백엔드를 한 페이지에 담아 설명하겠습니다.

현재 여러분의 에이전트 워크플로우에서 승인을 어떻게 강제하고 계십니까? 프롬프트(Prompt), API, 게이트웨이, 아니면 다른 방식입니까?

본 시리즈는 가상의 회사를 기반으로 구축된 레퍼런스 모델을 설명합니다. 제품 기능은 2026년 9월 기준 MuleSoft 문서를 기반으로 합니다.