파트 10: 배포 가능한 에이전트 승인 흐름을 위한 교훈과 청사진

Part 10 of 10 · MuleSoft에서 Agentic 변경 승인 MVP 구축하기

이것이 마지막 부분입니다. 지난 아홉 개의 게시물을 통해 우리는 SAP의 개발 환경에서 운영 환경으로 변경 사항을 배포하는 고통스러운 프로세스 하나를 가져와, MuleSoft 위에서 이를 위한 agentic MVP(최소 기능 제품)를 구축했습니다. 이 과정은 21단계 프로세스와 자동화할 부분을 결정하는 2x2 매트릭스를 거쳐, 아키텍처, 에이전트 네트워크, MCP 도구, 게이트웨이 정책, Vibes, 테스트, CI/CD 그리고 운영 지원에 이르기까지의 여정을 담고 있습니다.

이 파트에서는 전체 내용을 종합합니다: 무엇이 잘 작동했는지, 무엇을 변경할지, 그리고 여러분 자신의 프로세스에 재사용할 수 있는 청사진입니다.

효과적이었던 다섯 가지 사항

1. 에이전트가 아닌 프로세스로 시작하기. 우리는 단 하나의 프롬프트를 작성하기 전에 21단계를 모두 매핑했고, 각 단계를 규칙(rules), 에이전트(agent) 또는 사람(person) 중 하나로 분류했습니다. 이 지도가 프로젝트에서 여전히 가장 유용한 결과물입니다.

2. 코드에 인간의 게이트(human gates) 강제 적용하기. 모든 승인은 SAP에 어떤 것이 닿기 전에 Process API를 통해 확인됩니다. 인간 참여 루프 후처리 과정 (human-in-the-loop post)에서 볼 수 있듯이 말이죠. 에이전트는 아무리 프롬프트가 조정되어도 게이트를 건너뛸 수 없습니다. 왜냐하면 그 게이트는 프롬프트 안에 존재하지 않기 때문입니다.

3. Process API를 시스템 API(System APIs)가 아닌 도구(tools)로 노출하기. 통합 팀이 이미 구축했던 비즈니스 규칙들이 에이전트의 안전 계층 역할을 했습니다. 우리는 직접 작성한 것보다 훨씬 더 많은 것을 재사용했습니다.

4. 결정론적 검사(deterministic checks)에 맡기기. AI가 패키지, 위험 등급, 운송 오더를 제안합니다. 스키마(Schemas), Process API, 게이트웨이 정책(gateway policies), 그리고 사람이 그것이 진행될지 여부를 결정합니다. 이는 AI 개발자에게 적용되는 것과 동일한 규칙입니다: Vibes는 코드를 제안하고, 훅(hooks)과 CI가 결정합니다.

5. 가능한 모든 곳에서 테스트하기. LLM 단계만 점수가 매겨집니다. 나머지 모든 것은 정확한 테스트를 거쳤으며, 이는 테스트 스위트를 일반적이고 빠르며 신뢰할 수 있게 유지했습니다.

다르게 할 다섯 가지 것들

1. 도구 설명과 명명된 오류(named errors)부터 작성하기. 우리가 디버깅했던 에이전트 문제 대부분, 루프를 포함하여, 언제 사용할지 또는 오류 발생 후 무엇을 해야 하는지 알려주지 않은 도구들에서 비롯되었습니다. 다음번에는 어떤 에이전트 프롬프트보다 먼저 이것들을 작성할 것입니다.

2. 첫 번째 에이전트 이전에 골든 세트(golden set) 구축하기. 우리는 첫 버전이 작동한 후에 그것을 구축했습니다. 처음부터 가지고 있었다면, 모든 초기 프롬프트 변경 사항을 판단적 결정(judgement call)이 아닌 측정 가능한 것으로 만들 수 있었을 것입니다.

3. 시작부터 토큰 예산(token budgets) 설정하기. 프롬프트 변경으로 인해 토큰 사용량이 늘어나자 LLM 속도 제한 정책(rate-limit policy)을 추가했습니다. 처음부터 에이전트당 예산을 책정하는 것은 저렴하고 즉시 문제를 포착할 수 있습니다.

4. 에이전트를 작게 유지하기. 우리의 첫 번째 에이전트 중 하나는 너무 많은 도구를 가지고 있었고, 그들 사이에서 잘못된 선택을 했습니다. 이를 각각 몇 개의 도구만 가진 두 개의 에이전트로 분리한 것이 어떤 프롬프트 재작성보다도 더 효과적이었습니다.

5. 출시 전 계획 지원(Plan support before go-live). 파트 9에서 다룬 상관관계 ID(correlation ID), 대시보드, 운영 매뉴얼(runbooks), 일시 중지 스위치(pause switch) 모두 너무 늦게 나왔습니다. 이들은 첫 번째 사고가 아니라 첫 번째 출시 단계부터 포함되어야 합니다.

A reusable blueprint for agentic approval flows

청사진(The blueprint)

이것을 자체 프로세스에 적용하고 싶다면, 우리가 따를 순서는 다음과 같습니다:

1. 프로세스 매핑(Map the process). 모든 단계를 나열하고 각각 규칙(rules), 에이전트(agent) 또는 사람(person)별로 분류합니다.
2. 게이트 찾기(Find the gates). 승인 절차를 프롬프트(prompt)가 아닌 프로세스 API(Process API)에서 강제화합니다.
3. 도구 노출(Expose tools). MCP 도구를 프로세스 API를 통해 노출하고, 에이전트를 위해 설명(descriptions)을 작성하며 오류 이름(named errors)을 지정합니다.
4. 네트워크 설계(Design the network). 각자 몇 개의 도구를 가진 작은 에이전트와 루프 제한 및 사람에게의 에스컬레이션(escalation)이 있는 브로커 그래프(broker graph)를 만듭니다.
5. 트래픽 거버넌스(Govern traffic). Omni Gateway에서 도구 허용 목록(Tool allow-lists), PII 탐지, 토큰 예산(token budgets)을 관리합니다.
6. 표준으로 구축(Build with standards). Vibes에서 AI 개발자를 위한 스킬(Skills), 규칙, 워크플로우를 만들고, 결과를 확인하기 위한 후크(hooks)와 CI(Continuous Integration)를 적용합니다.
7. 테스트, 배포 및 실행(Test, ship and run). 정확한 테스트에 골든 세트(golden set)를 추가하고, Mule 앱과 에이전트 네트워크 각각에 대해 버전 관리된 출시(versioned release)와 모든 실패 모드에 대한 운영 매뉴얼을 준비합니다.

1단계와 2단계는 팀들이 건너뛰고 싶어 하는 부분이지만, 나머지 부분을 안전하게 만드는 핵심 요소입니다.

다른 적용 분야(Where else it fits)

청사진의 내용은 SAP에 국한된 것이 아닙니다. 사람의 승인과 시스템의 실행이 필요한 모든 다단계 프로세스에 동일한 형태가 적용될 수 있습니다. 예를 들어, 접근 요청, 공급업체 온보딩, Salesforce 또는 Workday에서의 구성 승진(configuration promotion), 또는 일반적인 릴리스 관리 등이 해당됩니다. 만약 귀하의 프로세스가 체크리스트, 몇 명의 승인자, 그리고 최종 기록 시스템(system of record)을 가지고 있다면, 이는 후보가 될 수 있습니다.

감사 인사(Thank you)

읽어주셔서 감사합니다. 댓글을 달고 질문해 주신 모든 분들께도 감사를 전합니다. 열 개의 파트는 시리즈에서 함께 볼 수 있습니다.

이 청사진을 가장 먼저 적용할 조직의 프로세스는 무엇인가요? 그리고 다음 시리즈는 어떤 내용을 다루어야 할까요?

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