Part 8: Agent 네트워크 배포하기: Anypoint CLI를 사용한 CI/CD

MuleSoft 기반 에이전트 변경 승인 MVP 구축의 10부 중 8부

Part 7에서는 증거(evidence)를 구축했습니다. 이번 파트에서는 이를 배포합니다. 에이전트 시스템은 일반적인 통합 릴리스보다 더 많은 구성 요소가 움직입니다: Mule 앱, 게이트웨이 정책, 프롬프트, 모델 선택 및 에이전트 네트워크 자체입니다. 이들이 환경을 거치며 함께 이동하지 않으면, 한 조합을 테스트하고 프로덕션에서는 다른 것을 실행하게 됩니다.

두 개의 파이프라인, 하나의 릴리스

우리는 두 개의 파이프라인을 운영하며, 이를 하나의 버전 번호로 함께 출시합니다:

1. Mule 파이프라인: MCP 서버 앱과 프로세스 및 시스템 API를 빌드하고 배포합니다. 이는 통합 팀이 이미 사용했던 Maven 기반의 파이프라인이며, Exchange에 게시(publishing)하고 CloudHub 2.0에 배포합니다.
2. 에이전트 네트워크 파이프라인: Anypoint CLI Agent Fabric 플러그인을 사용하여 에이전트와 브로커를 빌드하고 배포합니다.

에이전트 네트워크 파이프라인

Anypoint CLI의 Agent Fabric 플러그인은 몇 가지 명령어로 전체 라이프사이클을 다룹니다. agent-network:project:create로 생성된 프로젝트에는 네트워크를 설명하는 agent-network.yaml 파일이 포함되어 있습니다. CI 환경에서 단계는 다음과 같습니다:

# 대상 공간(target space)마다, 첫 배포 전에 한 번 실행
anypoint-cli-agent-fabric-plugin agent-network:setup:gateways

...

자격 증명(credentials)은 레포지토리에서가 아니라 CI 비밀 저장소(secret store)의 ANYPOINT_CLIENT_ID와 ANYPOINT_CLIENT_SECRET에서 가져옵니다. 환경은 --environment로 선택하며, 환경별로 다른 값들은 --property name:value를 사용하여 배포 시점에 전달합니다. 이 플러그인은 빌드 에이전트(build agent)에 Node 20+와 Java 17+가 필요합니다.

종속성 순서대로 배포하기

에이전트는 도구(tools)에 의존하고, 도구는 게이트웨이 정책(gateway policies)에 의존합니다. 따라서 각 환경 내의 순서는 고정되어 있습니다:

1. Mule 앱을 먼저 배포합니다. 프로세스 및 시스템 API를 먼저, 그 다음으로 도구를 가진 MCP 서버가 옵니다.
2. 게이트웨이 정책을 다음에 적용합니다. Part 5에서 가져온 허용 목록(allow-list) 및 ABAC 규칙을 동일한 리포지토리의 구성으로 적용합니다.
3. 에이전트 네트워크를 마지막에 배포합니다. 예상하는 모든 도구가 접근 가능하고 관리되는 상태가 된 후에만 진행할 수 있습니다.

도구를 만들기 전에 에이전트를 배포한다고 해서 명확하게 실패하지는 않습니다. 단순히 에이전트가 도구를 찾지 못하며, 첫 번째 증상은 테스트에서 혼란스러운 답변을 받는 것입니다.

동일한 것을 승격시키고 재구축하지 않기

모든 릴리스에는 하나의 버전이 있으며, 이 버전은 에셋 버전(GAV 좌표)으로 지정되어 에이전트 네트워크 프로젝트와 Mule 앱에 일치해야 합니다. Sandbox, 테스트, 프로덕션 환경 모두 동일하게 빌드된 아티팩트를 사용하며, 변경되는 것은 오직 환경과 그 속성뿐입니다.

환경 간의 게이트는 Part 7에서 설명한 계층 구조입니다:

• 테스트로 진입: Sandbox에서 MUnit 및 게이트웨이 정책 테스트가 통과해야 합니다.
• 프로덕션으로 진입: 그래프 시나리오(graph scenarios)가 통과하고, 골든 세트 점수(golden-set scores)는 현재 프로덕션 버전보다 나쁘지 않아야 하며, 비즈니스 오너가 UAT 기록에 서명해야 합니다.

프롬프트 변경이나 모델 변경은 코드 변경과 마찬가지로 새로운 버전을 의미합니다. 이 규칙이 우리에게 다른 어떤 것보다 더 많은 회귀(regressions)를 포착해 주었습니다.

시스템이 자체 변경 사항을 승인하다

이것은 변경 승인 시스템이기 때문에, 자체 프로덕션 릴리스도 변경 승인을 거쳐야 합니다. 프로덕션 배포 작업은 SAP 가져오기(import)가 approval_id를 기다리는 방식과 동일하게, 승인된 변경 기록을 기다립니다. 구축하기는 사소한 일이지만, 감사관이 가장 먼저 묻는 질문입니다.

에이전트 롤백하기

롤백은 프로덕션에서 편집하는 것이 아니라 이전 버전을 재배포(redeploy)하는 것입니다:

• Agent network: 이전 릴리스 태그를 확인하고 build 및 deploy를 다시 실행합니다. 새 버전이 충분히 안정화될 때까지는 이전 버전을 Exchange에 게시 상태로 유지하세요.
• Mule 앱: 이전 애플리케이션 버전을 재배포합니다.
• Teardown 순서가 중요합니다. 만약 어떤 버전을 제거한다면, 실행 중인 아무것도 삭제된 Exchange 자산을 가리키지 않도록 unpublish 전에 undeploy를 실행하세요.

모든 프로덕션 릴리스 전에는 테스트 환경에서 롤백을 연습합니다. 이 연습이 몇 분 이상 걸리면 릴리스가 대기하게 됩니다.

누가 무엇을 소유하는가

• 통합팀 (Integration team): Mule 파이프라인 및 도구 배포.
• Agent팀: agent network 프로젝트, 해당 버전, 그리고 golden-set 게이트.
• 플랫폼팀 (Platform team): 대상 공간(target spaces), 게이트웨이(gateways), CI 자격 증명(credentials) 및 정책 배포.
• 변경 위원회 (Change board): 다른 모든 변경 사항과 마찬가지로 프로덕션 승인.

다음 내용

Part 9에서는 프로덕션 환경에서 실행하는 방법에 대해 다룹니다: 관측 가능성(observability), 운영 매뉴얼(runbooks) 및 실제로 목격했던 장애 모드들입니다.

오늘 팀에서는 프롬프트를 어떻게 버전 관리하나요?

이 시리즈는 가상의 회사를 기반으로 구축된 레퍼런스 모델을 설명합니다. CLI 명령어는 2026년 10월 기준 Anypoint CLI Agent Fabric 플러그인 문서를 따르므로, 빌드하기 전에 최신 문서를 확인하세요.