Part 2: MuleSoft에서 에이전트 기반 변경 승인 MVP를 위한 참조 아키텍처 (원페이지)

10부 중 2부 · MuleSoft에서 에이전트 기반 변경 승인 MVP 구축

Part 1에서는 규제 산업에서 SAP 변경 사항의 승인 및 프로모션을 자동화하는 사용 사례를 제시했습니다. 이 과정에서 에이전트가 추론을 수행하고, 통합 도구가 액션을 수행하며, 사람이 승인을 담당합니다. 후속 글에서는 어떤 단계가 아예 에이전트여야 하는지와 승인 게이트를 어떻게 강제할지를 다루었습니다.

이 부분에서는 전체 내용을 한 페이지에 담았습니다.

Reference architecture on one page

계층 구조 (위에서 아래로)

사람(People). 요청자가 변경 사항을 제기합니다. 승인자들(비즈니스, QA, 검증 및 변경 자문 위원회)이 결정을 내립니다. 이들은 이미 사용하고 있는 도구 안에서 작업하며, 에이전트가 그들에게 다가옵니다.

에이전트 네트워크 (Agent Fabric). 네 개의 에이전트가 각각 좁은 업무를 맡습니다:

• Intake agent: 요청이 완전한지 확인하고 이를 풍부하게 만듭니다(enrich).
• Planner agent: 전송 의존성(transport dependencies)과 순서를 계산합니다.
• Change agent: 문서를 초안 작성하고, 테스트 증거를 수집하며, 가져오기 로그(import logs)를 읽습니다.
• Approval agent: 승인 패키지를 구성하고 각 게이트에 대한 요청을 합니다.

**브로커(broker)**가 이들을 조정합니다. Agent Network 2.0에서는 브로커의 흐름이 정의된 그래프입니다: LLM은 각 단계 내부에서 추론하지만, 단계의 순서와 그 사이의 게이트는 결정적(deterministic)입니다. 규제 프로세스에서 이것은

거버넌스 (Omni Gateway). Omni Gateway는 이전 명칭인 Flex Gateway였으며, 에이전트가 접하는 모든 것(MCP 서버, A2A를 통한 다른 에이전트, 그리고 LLM 제공업체)의 앞에 위치합니다. 여기서 정책은 에이전트가 어떤 도구를 볼 수 있는지 결정하고, 호출자의 클레임을 확인하며, PII를 감지하고, 토큰 사용을 제한하며, 모든 호출을 기록합니다.

MCP 도구. Mule로 구축되고 MCP 커넥터가 포함된 하나의 MCP 서버는 create_change, read_transport, request_approval, import_to_prod와 같은 소수의 비즈니스 레벨 도구를 노출합니다. 에이전트는 API가 아닌 도구를 봅니다.

프로세스 API. change-process-api는 각 도구 뒤에 있는 다단계 작업을 오케스트레이션하고, 어떤 되돌릴 수 없는 작업이 발생하기 전에 승인을 확인하며, 감사 기록을 작성합니다.

시스템 API. 백엔드별로 하나씩 존재합니다: SAP(RFC를 통해), ITSM 도구 및 테스트 관리. 이들은 연결 세부 정보를 숨기고 오류를 표준화합니다.

레코드 시스템 (Systems of record). SAP, ITSM 도구, 테스트 관리, 그리고 LLM 제공업체입니다. 에이전트가 직접 호출하는 것은 그 어떤 것도 아닙니다.

플랫폼. Agent Registry 및 Exchange는 에이전트와 도구를 발견하는 데 사용되며, Agent Visualizer는 에이전트 간의 상호 작용을 보는 데 사용되고, CloudHub 2.0 또는 Runtime Fabric은 배포에 사용됩니다.

설명할 가치가 있는 세 가지 설계 결정

1. 도구는 API 엔드포인트가 아닌 비즈니스 액션입니다

모든 시스템 API 작업을 MCP 도구로 노출하는 것이 유혹적일 수 있습니다. 하지만 그렇게 하지 마십시오. LLM이 40개의 저수준 작업 중에서 선택하는 것보다 다섯 가지 명확한 비즈니스 액션 중에서 선택하는 것이 더 적은 실수를 하고 더 적은 토큰을 소모합니다. MCP 도구 계층은 에이전트가 원하도록 허용되는 것을 결정하는 곳입니다.

2. 도구와 시스템 사이에 프로세스 API를 두는 것

MCP 서버는 시스템 API를 직접 호출할 수 있습니다. 하지만 우리는 그 사이에 프로세스 API를 배치했습니다. 왜냐하면 교차 시스템 규칙이 존재하는 곳이 바로 그곳이기 때문입니다:

대부분의 팀은 게이트웨이를 인바운드(inbound) 보호 기능으로 생각합니다. 하지만 여기서는 나가는 것 또한 관리합니다. 즉, LLM 제공업체로 전송되는 프롬프트는 PII 및 토큰 제한에 대한 동일한 정책을 거칩니다. 변경 기록에 민감한 정보가 포함되어 있다면, 모델에 도달하기 전에 포착됩니다.

누가 무엇을 소유하는가

다이어그램의 색상은 팀 경계를 나타냅니다:

• Agent 팀 (보라색): 에이전트(agents), 프롬프트(prompts), 브로커 그래프(broker graph) 및 평가(evaluation).
• Integration 팀 (청록색): MCP 서버, 프로세스 API(Process API) 및 시스템 API(System APIs).
• Platform 팀 (짙은 회색): Omni Gateway 정책, 레지스트리(registry), 관측 가능성(observability) 및 환경(environments).

각 팀은 레이어 간의 계약(도구 정의 및 API 사양)만 안정적으로 유지한다면 독립적으로 배포할 수 있습니다. 이러한 계약들은 Exchange에 게시되어 공유된 진실 공급원(shared source of truth)이 됩니다.

작게 시작하기

전체 프로세스는 21단계로 구성됩니다. MVP는 요청 접수, 변경 설정 및 SAP에서 변경 사항 생성의 처음 세 단계를 시작으로 하며, 실제 시스템에 접근하기 전에 전체 체인을 엔드투엔드로 테스트할 수 있도록 스텁된(stubbed) 백엔드를 사용합니다. 후반부에서는 나머지 단계들이 아키텍처의 형태를 바꾸지 않으면서 동일한 레이어에 어떻게 통합되는지를 보여줍니다.

다음 내용

Part 3에서는 설계 수준으로 한 단계 더 깊이 들어가, 21단계 각각이 어디에 위치하게 되었는지, 그리고 브로커 그래프가 실제로 어떤 모습인지 설명합니다.

어떤 레이어에서 이의를 제기하시겠습니까? 특히 System API를 MCP 도구로 직접 노출하는 분들의 의견을 듣고 싶습니다.

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