인사이트리포트

“어제 배포한 뒤 장애가 발생했다. 원인을 찾고, 필요하면 롤백 방안을 제시하라.”

이 요청을 받은 AI Agent는 정해진 명령만 실행하지 않는다. 메트릭과 로그를 확인하고, Kubernetes 이벤트와 Git 변경 내역을 대조해 다음 행동을 스스로 고른다. 기존 자동화가 개발자가 짜놓은 순서를 따랐다면, Agent는 상황에 따라 실행 경로를 바꾼다.

원인을 조사하는 동안에는 데이터를 읽기만 하지만, 롤백을 실행하는 순간 운영 환경이 달라진다. 이 경계를 안전하게 넘으려면 Agent가 무엇을 근거로 판단했고 어떤 도구를 호출했는지 추적할 수 있어야 하며, 변경 권한과 승인 절차도 호출 과정에서 실제로 작동해야 한다.

오픈소스 생태계도 이 경로를 중심으로 재편되고 있다. MCP는 Agent와 도구를, A2A는 Agent와 Agent를 잇는다. 그러나 연결 형식이 같아졌다고 해서 상대를 신뢰할 수 있는지, 호출을 허용해도 되는지, 문제가 생겼을 때 어디서 차단할지는 저절로 해결되지 않는다. AGNTCY와 Agent Gateway가 발견·신원·정책·관측 영역을 다루고, 관련 프로젝트가 Linux Foundation으로 모이는 이유가 여기에 있다.

Part 1에서 보안과 Kubernetes 운영 기반을 다뤘다면, Part 2에서는 Agent의 실행이 조직 안팎의 시스템으로 이어지는 과정을 따라간다. 각 기술이 해결한 문제와 기업이 직접 설계해야 할 영역을 구분하고, 읽기 작업에서 시작해 변경 권한까지 안전하게 넓혀가는 방법을 살펴본다.

1. Agent 연결에서 관측성과 거버넌스가 함께 필요한 이유

전통적인 자동화 시스템에서는 개발자가 호출할 API와 처리 순서를 코드로 정해 두었다. Agent는 사용자 요청을 해석하고, 검색 결과나 도구의 응답을 살펴 다음 동작을 정한다. 같은 요청도 선택한 도구와 호출 횟수에 따라 결과가 달라지며, 실행 비용이나 운영 위험도 커질 수 있다.

운영자는 Agent에 어제 배포한 뒤 발생한 장애의 원인을 조사하고, 복구가 어렵다면 롤백 안을 제시하도록 요청한다. Agent는 메트릭과 로그를 살펴보고 Kubernetes 이벤트, Git 변경 내역, 배포 및 작업 기록을 조회한다. 이 조사 과정은 운영 상태를 바꾸지 않는 읽기 작업이다. 조사 결과를 바탕으로 롤백을 하거나 설정을 변경하는 순간부터는 쓰기 작업이 시작된다. 롤백 같은 변경 작업에는 별도의 권한 확인과 승인이 필요하다. 감사 기록에는 요청 주체와 Agent가 사용한 근거, Tool 호출 내역, 운영 환경에 반영된 변경 사항이 연결돼 있어야 한다.

그림 1. 장애 조사와 롤백의 승인·실행 흐름

이와 같은 흐름을 실제로 구현한다면 세 계층으로 구분하는 편이 이해하기 쉽다.

그림 2. Agent 연결과 운영을 구성하는 세 영역

먼저 연결 규격으로 MCP는 Tool, Resource, Prompt를 통해 외부 기능과 데이터를 제공한다. A2A는 Message, Task, Artifact로 Agent 간 요청의 진행 상태와 결과를 표현한다.

발견(Discovery) 및 인증 단계의 Directory는 Agent Card나 OASF 레코드에 기록된 기능과 접속 정보를 검색한다. Identity는 상대의 식별자와 자격 증명을 검증한다. 검증된 상대에게 작업을 허용할지는 운영 정책에서 판단한다.

운영 및 관리 단계의 Gateway는 호출 권한과 승인 조건, 사용량 제한을 적용한다. Observability는 트레이스와 메트릭, 감사 로그를 수집해 실행 과정과 운영 상태를 확인하게 한다.

이러한 기능은 작업이 진행되는 동안 계속 사용된다. 업무 Agent가 A2A로 전문 Agent에 작업을 맡기기 전에는 Agent Card와 자격 증명을 확인한다. 작업 중에는 권한 정책을 적용하고 Task 상태를 추적한다. 작업이 끝나면 결과와 호출 기록을 보관한다.

MCP와 A2A는 기능과 메시지를 교환하는 방식을 통일한다. 호출 권한과 감사 기록, 장애 복구 절차는 별도로 설계해야 한다. 연결 표준을 결정하는 단계에서 Directory와 자격 증명(Identity), 게이트웨이(Gateway), 정책(Policy), 가시성(Observability)와 같은 운영 방식까지 정해 두어야 한다.

2. MCP: Agent와 업무 도구를 연결하는 표준

Agent가 업무를 처리하다 보면 자체 실행 환경에 없는 문서나 데이터가 필요하고, 데이터베이스나 외부 API를 호출해야 할 때도 있다. 연결 규격이 제각각이면 시스템마다 기능 조회와 호출, 오류 처리, 자격 증명 관리를 따로 구현해야 한다. MCP는 AI 애플리케이션을 외부 데이터 소스와 도구, 워크플로에 연결하는 공개 표준이다[1].

MCP 메시지는 JSON-RPC 2.0 형식을 따른다. 로컬 서버와는 stdio로, 원격 서버와는 주로 Streamable HTTP로 통신한다[2]. MCP 서버는 다음 세 항목을 제공할 수 있다[3].

• Tools: API 호출, 데이터베이스 조회, 파일 변경 등의 실행 기능
• Resources: 파일이나 문서, 데이터베이스 레코드처럼 클라이언트가 읽어 모델에 제공할 수 있는 데이터
• Prompts: 특정 작업의 지침과 입력을 미리 구성한 재사용 가능한 템플릿

Agent 개발자는 서버가 공개한 기능 목록과 입력 스키마를 표준 메서드로 조회하고 같은 형식으로 Tool을 호출한다. 도구 제공자는 기존 API와 데이터를 MCP 서버의 Tool이나 Resource로 노출한다. MCP Client를 지원하는 애플리케이션은 프레임워크별 전용 연동 모듈 없이 이 서버에 연결할 수 있다.

MCP 호출의 인증과 권한 관리

연결 규격을 통일해도 과도한 권한이나 잘못된 Tool 호출, 결과 데이터 유출 같은 위험은 따로 통제해야 한다. 상태 조회는 시스템을 변경하지 않지만 배포는 실행 중인 서비스에 영향을 준다. 같은 Tool도 사용자의 직무와 대상 시스템에 따라 허용 여부가 달라질 수 있다.

Tool 목록은 사용자와 세션에 필요한 범위만 공개하고, 실행 전에 호출 권한을 확인해야 한다. 실행 결과도 비밀정보나 불필요한 데이터가 모델에 전달되지 않도록 검사한다.

HTTP 기반 MCP에서 권한 부여를 지원한다면 OAuth 2.1 흐름을 따른다. MCP 서버는 Protected Resource Metadata로 권한 서버의 위치를 알리고, 클라이언트는 resource 매개변수로 토큰을 사용할 대상 서버를 지정한다[4]. 2026년 6월에는 조직의 IdP를 통해 MCP 서버 접근을 중앙에서 관리하는 Enterprise-Managed Authorization(EMA) 확장이 안정 버전으로 공개됐다[5]. 관리자는 IdP의 그룹과 역할에 따라 접근 권한을 정한다. 인사 이동이나 퇴사로 계정 정보가 바뀌면 기존의 조직 계정 관리 절차를 통해 MCP 서버 권한도 함께 조정할 수 있다.

3. A2A: 서로 다른 Agent가 협업하는 표준

하나의 Agent가 모든 업무 지식을 갖추고 필요한 도구를 직접 다루도록 만들면 개발과 운영 부담이 커진다. 고객 대응 Agent는 계약 검토를 법무 Agent에 맡길 수 있고, 구매 Agent는 외부 공급업체 Agent에 견적을 요청할 수 있다. 이처럼 전문 영역이나 조직 경계를 넘는 업무는 여러 Agent가 나눠 처리하게 된다. A2A는 서로 다른 Agent가 메시지를 교환하고 작업의 상태와 결과를 공유하는 방식을 정의한다.

MCP와 A2A는 서로 다른 연결을 다루며 한 작업 안에서 함께 쓰일 수 있다. MCP는 Agent가 도구와 데이터에 접근하는 인터페이스를 제공한다. A2A는 서로 다른 Agent 시스템이 작업을 주고받는 방식을 정의한다[6]. Agent는 내부에서 사용하는 모델이나 도구를 공개하지 않고도 A2A로 작업을 받을 수 있다. 외부에는 Agent Card로 기능과 엔드포인트, 인증 요구사항을 알리고, 작업에 필요한 문서나 API는 내부에서 MCP를 통해 이용한다.

MCP와 A2A가 하나의 업무 흐름 안에서 각각 어느 구간을 맡는지 정리하면 아래 그림과 같다.

그림 3. Agent 사용 환경에서 MCP와 A2A

도구 호출과 Agent 협업은 성격이 다르다. 조회 API는 입력과 출력이 비교적 명확하고 한 번의 요청으로 끝나는 경우가 많다. 반면 Agent 작업은 시간이 오래 걸릴 수 있고, 중간에 추가 정보나 승인이 필요하며, 진행 상태와 최종 산출물을 나눠 전달해야 할 수도 있다. A2A는 이를 위해 다음 개념을 정의한다[7][8].

구매 Agent는 공급업체 Agent가 내부에서 어떤 모델과 도구를 사용하는지 몰라도 된다. 호출 전에는 Agent Card에서 기능과 엔드포인트, 인증 요구사항을 확인한다. 작업을 보낸 뒤에는 Task 상태와 반환된 Artifact를 추적한다. 아래 그림은 구매 Agent가 견적을 요청하고 결과를 받기까지의 Task 생명주기를 보여준다.

그림 4. A2A 구조의 예시 사례

taskId는 개별 작업을 식별하고, contextId는 서로 관련된 Message와 Task를 같은 대화 맥락으로 묶는다. 상태가 input-required로 바뀌면 구매 Agent는 같은 taskId와 contextId를 담은 새 Message로 승인 결과를 보낸다. 승인이 확인되면 공급업체 Agent는 견적서를 Artifact로 반환하고 Task를 completed 상태로 마친다. Task 상태와 Artifact 업데이트는 폴링, 스트리밍 또는 푸시 알림으로 받을 수 있다.

4. AGNTCY와 Agent Gateway: Agent를 찾고 연결을 통제하는 운영 기반

MCP와 A2A로 연결 방법을 통일해도 Agent 수가 늘면 새로운 운영 문제가 생긴다. 어떤 Agent가 존재하는지, 누가 관리하는지, 신뢰할 수 있는지, 어느 네트워크 경로로 연결해야 하는지 등을 알아야 한다. 동시에 호출마다 인증과 권한을 적용하고, Tool Call과 Task를 추적할 공통 지점도 필요하다. AGNTCY와 Agent Gateway는 서로 다른 관점에서 이 문제를 해결한다.

AGNTCY: Agent 발견과 신원 관리

AGNTCY는 Agent를 정의하고, 찾을 수 있도록 하며, 신원을 확인하고 메시지를 전달하는 데 필요한 구성요소를 제공한다[9]. 각 구성요소의 역할은 다음과 같다.

그림 5. AGNTCY 구성요소와 관계도

그림 위쪽은 Agent 정보를 등록하고 검색하는 절차를, 아래쪽은 검색한 Agent와 실제 작업을 주고받는 과정을 나타낸다. Agent 운영자는 기능과 메타데이터를 OASF 레코드에 기술하고, 지원 프로토콜과 엔드포인트 같은 접속 정보도 함께 등록한다. Agent Directory는 등록된 레코드를 저장하고 검색 요청을 처리한다.

검색 결과로 호출 후보를 골랐다면 실제 연결에 앞서 상대의 신원을 검증해야 한다. Identity는 레코드에 담긴 Agent ID를 해석하고, 이에 연결된 자격 증명과 서명을 검증한다. 어떤 작업까지 허용할지는 이 검증 결과를 바탕으로 별도의 정책 집행 지점에서 판단한다.

신원 검증을 마치면 두 Agent의 메시지는 SLIM을 통해 전달된다. 구성에 따라 발행·구독(Pub/Sub)이나 스트리밍(Streaming) 방식을 사용할 수 있으며, SLIM의 세션 계층은 MLS 기반 종단 간 암호화를 지원한다. Observability는 Agent와 Task, 메시지의 흐름을 트레이스(Trace)와 메트릭(Metrics)으로 기록한다. Evaluation은 이 데이터를 이용해 실행 성능과 결과 품질을 평가한다. OASF와 Directory가 호출 후보를 찾고 Identity가 신원을 검증한다면, SLIM은 검증 이후의 통신을 맡는다. Observability and Evaluation은 이 전 과정을 추적하고 평가한다.

A2A는 Agent들이 Message와 Task, Artifact를 교환하는 공통 형식을 정의한다. AGNTCY는 여기에 Directory와 Identity, 보안 전송, 관측 기능을 더해 여러 조직에 걸친 협업을 운영할 수 있도록 한다. Directory 검색은 호출 후보를 고르는 과정이고, Identity 검증은 그 후보가 누구인지 확인하는 과정이다. 해당 Agent에 실제 작업을 허용하는 권한 판단은 그 다음에 이뤄진다. Gateway는 앞 단계에서 확인한 신원과 호출 정보를 바탕으로 요청마다 권한 정책을 적용하고 그 결과를 기록한다.

Agent Gateway: 인증·정책·관측의 공통 지점

Agent가 MCP 서버와 모델, 다른 Agent에 직접 연결하면 인증 정보와 호출 로그가 여러 곳에 흩어진다. Agent Gateway는 이 트래픽을 공통 경로로 모아 운영 정책을 일관되게 적용한다. 핵심 역할은 다음과 같다.

• 사용자·Agent·MCP 서버의 신원과 권한 확인
• Agent와 Tool 단위의 허용 목록, 호출 제한, 승인 정책 적용
• Tool Call, A2A Task, 모델 호출을 연결한 추적과 감사
• 타임아웃, 재시도, 비용 한도와 같은 운영 기준 관리

Linux Foundation의 agentgateway는 MCP, A2A, LLM 트래픽을 다루는 오픈소스 Agent 프록시다. MCP 서버의 Tool을 통합하고, OAuth와 CEL 기반 정책, OpenTelemetry 관측, A2A 라우팅 등을 제공한다[10]. Solo.io는 이 프로젝트를 Linux Foundation에 기여했으며 별도의 상용 배포판과 지원 서비스를 제공한다[12].

운영 Agent가 배포 상태를 조회하는 과정

운영 Agent가 payment-api의 배포 상태를 조회한다고 하자. 읽기 전용 MCP Tool인 get_deployment_status에 네임스페이스와 Deployment 이름을 입력하면 복제본 수와 컨테이너 이미지, 연결된 Service와 Pod의 상태가 반환된다. 아래 결과는 복제본 3개로 배포된 payment-api의 상태를 agentgateway를 거쳐 조회한 것이다[11].

그림 6. agentgateway로 Kubernetes 배포를 조회한 예시

이 과정에서 Agent가 Kubernetes API의 리소스 구조와 호출 방법을 일일이 다룰 필요는 없다. 배포 상태 조회에 맞춰 정의된 Tool을 호출하면 된다. 그러나 상태 조회와 재시작은 같은 Deployment를 대상으로 해도 위험 수준은 다르다. 조회는 리소스를 바꾸지 않지만, 재시작은 실행 중인 워크로드에 영향을 준다. 초기에는 get_deployment_status 같은 읽기 전용 Tool만 허용해 실제 업무에 도움이 되는지 살펴보고, 권한 경계와 감사 로그가 의도대로 작동하는지 점검한다. 배포나 롤백처럼 리소스를 변경하는 Tool은 승인 통제와 복구 절차를 검증한 뒤 추가한다.

5. Linux Foundation: Agent 표준을 위한 중립적인 거버넌스

2025년에는 에이전트 생태계의 주요 프로젝트들이 잇달아 Linux Foundation으로 이관됐다.

Linux Foundation은 같은 해 12월 Agentic AI Foundation(AAIF)을 출범시켰다. 이때 Anthropic은 MCP를, Block은 goose를, OpenAI는 AGENTS.md를 창립 프로젝트로 기여했다[10]. MCP의 관리 주체도 Anthropic에서 AAIF로 옮겨졌다. 앞으로는 여러 참여자가 공개된 절차에 따라 개발 방향을 논의한다. 앞서 A2A와 AGNTCY, agentgateway도 6월부터 8월 사이 차례로 Linux Foundation에 합류했다. A2A는 프로토콜과 SDK를, AGNTCY는 발견·신원·메시징 인프라를, agentgateway는 보안과 관측 기능을 갖춘 게이트웨이를 공개적으로 개발하고 있다.

관리 권한이 특정 기업에 집중되지 않으면 도입 기업도 한 공급자의 결정에 덜 얽매인다. 공개 규격이 안정적으로 유지되면 모델이나 플랫폼을 교체할 때 연동 방식을 처음부터 다시 설계해야 하는 부담도 줄어든다. 서로 경쟁하는 기업도 사양과 SDK, 호환성 시험 도구는 공동으로 개발할 수 있다. 이로써 제품과 서비스의 경쟁은 그대로 이어진다. 기업들은 연결 규격과 개발 도구를 함께 만들고, 모델 성능과 제품 기능, 운영 역량으로 경쟁하게 된다.

마치며

Agent는 조직의 데이터와 도구를 사용하고, 필요한 일을 다른 Agent에 맡길 수 있어야 실제 업무에서 효용성이 있다. 하지만 연결이 늘수록 편의만 커지는 것은 아니다. Agent의 행동 반경이 넓어지는 만큼 데이터 이동 경로는 복잡해지고, 장애가 퍼질 가능성도 커진다.

MCP는 Agent와 데이터·도구 사이의 접점을 표준화하고, AGNTCY는 Agent 검색과 신원·역량 검증을 맡는다. Agent Gateway는 호출 경로에 인증과 정책을 적용하고 실행 과정을 기록한다. Linux Foundation 산하 AAIF는 여러 기업이 관련 오픈소스 기술을 공동으로 개발하고 관리할 장을 제공한다. 다루는 영역은 서로 다르지만, 실제 환경에서는 같은 운영 체계 안에서 함께 작동한다.

Agent를 안전하게 운용하려면 보안과 운영 체계가 먼저 갖춰져야 한다. 이를 조직 업무에 투입하려면 관측성, 연동, 거버넌스까지 필요하다. 연결 규격만 도입해서는 충분하지 않다. 허용할 행동의 범위를 정하고 실행 내역을 추적해야 하며, 사고에 대비해 책임 주체와 복구 절차도 명확히 해두어야 한다.

기업이 지금 해야 할 일은 수많은 자산과 API, Agent를 모두 연결하는 것이 아니다. 우선 연결할 자산과 접근 경계를 파악한 뒤, 읽기 전용 작업부터 적용해 효과와 통제 수준을 검증해야 한다. 검증 결과에 따라 Agent Gateway와 A2A, 발견(Discovery)·신원 체계를 차례로 도입하면 기술 변화에 대응하면서도 운영 안정성과 보안을 지킬 수 있다.

에스코어는 오픈소스 선정과 도입뿐 아니라 아키텍처 설계, 거버넌스, 시스템 구축, 기술 지원을 연결해 오픈소스 전환을 운영과 인프라 전반에 걸쳐 지원할 수 있다. 앞으로 기업에서 중요한 것은 더 많은 AI LLM 프로젝트를 도입하는 일이 아니라, 조직의 업무와 책임 구조에 맞는 연결 기준을 세우고 안정적으로 운영하는 일이다.