엔터프라이즈 도입 전략

도입은 기술 연결보다 조직 설계에 가깝다

엔터프라이즈에서 A2A를 도입한다는 것은 새 통신 프로토콜 하나를 추가하는 일이 아니다. 조직 안팎의 에이전트가 어떤 방식으로 발견되고, 누구의 책임 아래 운영되며, 어떤 기준으로 업무를 맡고 결과를 남길지 정하는 아키텍처 결정이다.

여기서 엔터프라이즈는 여러 부서, 보안 정책, 데이터 소유권, 벤더 계약, 운영 책임이 얽힌 조직을 뜻한다. 작은 팀에서는 에이전트 하나를 빠르게 만들고 호출하면 충분할 수 있다. 하지만 큰 조직에서는 "누가 이 에이전트를 운영하는가", "장애가 나면 어디로 연락하는가", "민감한 데이터를 보낼 수 있는가", "비용은 어느 부서가 부담하는가" 같은 질문이 먼저 해결되어야 한다.

A2A는 이 문제를 해결하기 위한 공통 언어를 제공한다. 공식적으로 A2A는 서로 다른 프레임워크와 벤더로 만든 에이전트가 협업할 수 있도록 하는 공개 표준을 지향한다.¹ 또한 Google이 제안한 뒤 Linux Foundation 기반 프로젝트로 옮겨지면서, 특정 회사의 전용 인터페이스가 아니라 중립적이고 장기적으로 관리되는 생태계를 목표로 한다는 점이 강조되었다.²

따라서 도입의 핵심 질문은 "A2A를 쓸 것인가"가 아니다. 더 정확한 질문은 "우리 조직의 에이전트 협업 경계를 어떻게 표준화할 것인가"이다.

AI 생성 이미지

기존 자산을 버리지 않고 연결하기

대부분의 조직은 빈 땅에서 시작하지 않는다. 이미 사내 챗봇, 분석 자동화, RPA, 레거시 API, SaaS 연동, 벤더가 제공하는 AI 기능을 갖고 있다. A2A 도입은 이 자산을 한 번에 교체하는 방식이 아니라, 표준 인터페이스로 점진적으로 감싸는 방식이 현실적이다.

첫 번째 대상은 기존 사내 에이전트다. 예를 들어 고객 지원 요약 에이전트, 보안 로그 분석 에이전트, 계약서 검토 에이전트가 이미 부서별로 운영 중일 수 있다. 이들을 모두 같은 프레임워크로 다시 만들 필요는 없다. 내부 구현은 유지하되 외부에는 Agent Card, Task, Message, Artifact를 갖춘 A2A 인터페이스를 제공하면 된다. 이는 기존 시스템에 "표준 접수 창구"를 붙이는 것과 비슷하다.

두 번째 대상은 외부 벤더 에이전트다. 벤더 에이전트는 조직이 내부를 통제할 수 없다. 그래서 더더욱 표준 경계가 필요하다. 클라이언트 에이전트는 벤더의 Agent Card를 읽고 지원 기능, 인증 방식, 입력·출력 형식, SLA, 데이터 처리 조건을 확인해야 한다. 벤더 호출은 직접 흩어져 있으면 안 된다. 보안 게이트웨이, 정책 엔진, 감사 로그를 거치는 공통 경로를 두는 편이 안전하다.

세 번째 대상은 레거시 API다. 모든 API를 A2A 에이전트로 바꾸는 것은 좋은 전략이 아니다. 단순 조회, 저장, 계산처럼 입력과 출력이 명확한 기능은 API나 MCP 도구로 남겨도 된다. A2A 에이전트로 공개할 대상은 "업무를 이해하고 판단하며 상태를 가진 작업을 수행하는 단위"여야 한다. 예를 들어 고객 정보 조회 API는 도구에 가깝지만, 고객 이탈 위험 분석 에이전트는 여러 데이터를 읽고 판단한 뒤 설명 가능한 Artifact를 만드는 업무 주체에 가깝다.

점진적 연결 전략은 다음 순서가 좋다.

1. 인벤토리 작성: 현재 운영 중인 에이전트, 자동화, API, 데이터 소스를 목록화한다.

2. A2A 후보 분류: 단순 도구, 도메인 에이전트, 외부 벤더 에이전트, 폐기 대상 시스템을 나눈다.

3. 래퍼 적용: 내부 구현은 유지하고 A2A 서버 또는 어댑터를 붙인다.

4. 카탈로그 등록: Agent Card와 운영 메타데이터를 중앙 또는 도메인 카탈로그에 등록한다.

5. 정책 경유 호출: 인증, 권한, 감사, 비용 추적을 거치는 표준 호출 경로를 만든다.

6. 워크플로 확장: 검증된 에이전트를 순차형, 병렬형, 승인형 워크플로에 연결한다.

이 접근은 교체보다 느려 보일 수 있다. 하지만 엔터프라이즈에서는 속도보다 되돌릴 수 있는 변화가 중요하다.

도메인 에이전트는 서비스처럼 운영해야 한다

도메인 에이전트는 특정 업무 영역의 전문가 역할을 하는 에이전트다. 재무 리스크 분석 에이전트, 조달 계약 검토 에이전트, 의료 청구 검증 에이전트처럼 부서 지식과 데이터 접근 권한을 가진다. 이런 에이전트를 A2A로 공개하면 다른 부서나 오케스트레이터가 쉽게 호출할 수 있다. 동시에 책임도 커진다.

가장 먼저 정해야 할 것은 소유권이다. 에이전트마다 최소한 다음 책임자가 필요하다.

다음은 SLA다. SLA는 "얼마나 똑똑한가"가 아니라 "어떤 조건에서 어느 수준으로 동작한다고 약속하는가"에 가깝다. A2A 에이전트의 SLA에는 일반 API보다 몇 가지 항목이 더 필요하다.

• 지원하는 스킬과 입력 형식

• 평균 응답 시간과 최대 처리 시간

• 장기 Task의 상태 업데이트 주기

• 스트리밍 또는 푸시 알림 지원 여부

• 실패, 취소, input-required 상태 처리 방식

• Artifact의 형식, 보존 기간, 재생성 가능성

• 장애 시 대체 경로와 연락 채널

마지막은 변경 관리다. Agent Card는 단순 소개 문서가 아니라 호출자와의 계약에 가깝다. 스킬 이름, 입력 스키마, Artifact 형식, 인증 요구사항이 바뀌면 기존 오케스트레이터가 깨질 수 있다. 따라서 변경은 세 단계로 나누어 관리해야 한다.

• 호환 변경: 설명 추가, 새 스킬 추가, 선택 필드 추가

• 주의 변경: 기본 모델 변경, 비용 정책 변경, 응답 품질 특성 변화

• 비호환 변경: 필수 입력 변경, 기존 스킬 제거, Artifact 스키마 변경

비호환 변경은 새 버전의 Agent Card로 분리하고, 기존 버전에 대한 종료 일정을 공지해야 한다. A2A 생태계는 SDK, 사양, 도구가 계속 발전하므로 조직은 프로토콜 사양과 SDK 의존성을 별도로 추적해야 한다. 공식 저장소에서도 여러 언어 SDK와 향후 개선 항목이 함께 다루어진다.³

운영 거버넌스의 네 가지 축

전사 도입에서 가장 중요한 운영 장치는 에이전트 카탈로그다. 카탈로그는 단순 목록이 아니다. 조직 안의 에이전트를 찾고, 승인하고, 호출하고, 감시하는 관제판이다.

카탈로그에는 Agent Card에 담긴 공개 정보 외에도 운영 정보가 함께 있어야 한다.

• 에이전트 이름, 설명, 버전, 제공 부서

• 업무 소유자와 기술 담당자

• 지원 스킬과 입출력 형식

• 허용되는 데이터 등급

• 호출 가능한 클라이언트와 권한 범위

• 인증 방식과 토큰 발급 정책

• SLA, 배포 환경, 장애 연락처

• 최근 테스트 결과와 호환성 검증 상태

• 비용 단가, 예산 코드, 사용량 한도

두 번째 축은 접근 정책이다. "Agent Card를 볼 수 있다"와 "실제로 호출할 수 있다"는 다르다. 어떤 에이전트는 전체 조직에 공개할 수 있지만, 특정 스킬은 재무팀만 호출할 수 있다. 어떤 Artifact는 생성은 가능하지만 외부 벤더 에이전트에는 전달하면 안 된다. 접근 정책은 에이전트 단위, 스킬 단위, 데이터 등급 단위, 사용자 또는 서비스 계정 단위로 나누어야 한다.

세 번째 축은 감사 로그다. 감사 로그는 문제가 생긴 뒤 책임을 묻기 위한 장치만이 아니다. 시스템을 개선하기 위한 학습 자료이기도 하다. 로그에는 최소한 호출자, 원격 에이전트, 스킬, Task ID, 상태 전환, 정책 판단, 오류 유형, Artifact 메타데이터, 비용 정보가 남아야 한다. 다만 원문 메시지나 민감 데이터는 그대로 기록하지 않는 것이 원칙이다.

네 번째 축은 비용 추적이다. 멀티 에이전트 시스템에서는 하나의 사용자 요청이 여러 모델 호출, 외부 검색, 파일 처리, 벤더 에이전트 호출로 번질 수 있다. 비용을 태스크 단위로 묶어 추적하지 않으면 "편리하지만 통제 불가능한 자동화"가 된다. 예산 한도, 호출량 제한, 부서별 차지백, 고비용 에이전트 경고를 초기에 설계해야 한다.

파일럿에서 전사 확산으로 넘어가는 법

좋은 파일럿은 작지만 실제 업무와 연결되어 있다. 단순 데모처럼 "질문하면 답하는 에이전트"보다, 명확한 입력과 결과, 승인 기준, 측정 가능한 시간을 가진 업무가 좋다. 예를 들어 영업 제안서 초안 생성, 보안 이벤트 1차 분류, 공급업체 리스크 요약처럼 범위가 분명한 작업이 적합하다.

파일럿의 성공 기준은 모델 응답이 그럴듯한지가 아니다. 다음 질문에 답할 수 있어야 한다.

• Agent Card만 보고 다른 팀이 이 에이전트를 이해할 수 있는가?

• Task 상태와 Artifact가 감사 가능한 형태로 남는가?

• 실패와 취소, 추가 입력 요청이 정상 흐름으로 처리되는가?

• 민감 데이터가 정책에 맞게 제한되는가?

• 비용과 지연 시간이 업무 가치에 비해 납득 가능한가?

• 운영팀이 장애를 재현하고 설명할 수 있는가?

파일럿 이후에는 공통 플랫폼 요소를 먼저 만들고, 그 위에 도메인 에이전트를 올리는 방식이 좋다. 공통 플랫폼 요소란 에이전트 카탈로그, 인증·인가, 정책 검사, 로그·추적, 테스트 도구, 배포 템플릿, 비용 대시보드 같은 기반 기능이다. Google Cloud의 A2A 관련 도구와 로드맵에서도 호환성 검사, 평가, 배포 경로, 기업용 거버넌스 기능이 함께 언급된다.⁴ 이는 전사 확산에서 프로토콜 구현만큼 검증과 운영 장치가 중요하다는 신호다.

중앙집중화와 에이전트 증식 사이에서 균형 잡기

전사 도입에서 흔한 실패는 두 극단으로 나타난다.

첫 번째 극단은 과도한 중앙집중화다. 모든 에이전트를 중앙 AI 플랫폼팀이 직접 설계하고 승인하고 운영하려 하면 속도가 급격히 떨어진다. 도메인 지식은 현업 부서에 있는데, 구현 권한은 중앙에만 있으면 병목이 생긴다. 결국 부서들은 비공식 자동화와 우회 경로를 만들게 된다.

두 번째 극단은 무분별한 에이전트 증식이다. 누구나 에이전트를 만들고 아무 카탈로그에도 등록하지 않으며, 소유자와 SLA 없이 운영하면 조직은 곧 혼란에 빠진다. 비슷한 기능의 에이전트가 중복되고, 비용은 추적되지 않으며, 오래된 Agent Card가 남아 잘못된 호출을 유도한다. 보안팀은 어떤 데이터가 어디로 갔는지 설명하기 어려워진다.

현실적인 해법은 연합형 거버넌스다. 중앙 플랫폼팀은 표준, 보안 기준, 카탈로그, 공통 런타임, 관측성, 테스트 체계를 제공한다. 각 도메인 팀은 자기 업무 에이전트의 품질, 데이터 정책, SLA, 변경 관리를 책임진다. 중앙은 길을 만들고, 도메인은 그 길 위에서 서비스를 운영하는 구조다.

A2A는 이 균형을 가능하게 하는 좋은 경계가 된다. 내부 구현은 각 팀이 선택할 수 있다. Python SDK, JavaScript SDK, ADK, LangGraph, 사내 프레임워크 중 무엇을 쓰든 상관없다. 다만 외부 협업 경계에서는 Agent Card, Task, Message, Artifact, 인증, 감사, 비용 추적이라는 공통 규칙을 따라야 한다.

엔터프라이즈에서 A2A의 가치는 "모든 에이전트를 하나로 통일하는 것"이 아니다. 서로 다른 에이전트가 조직의 책임 체계 안에서 안전하게 협업하도록 만드는 것이다. 기술 표준은 출발점이다. 지속 가능한 도입은 소유권, 정책, 운영, 비용, 변경 관리가 함께 설계될 때 가능해진다.

참고

¹A2A Protocol

²Google Cloud donates A2A to Linux Foundation

³Agent2Agent A2A GitHub Repository

⁴Announcing a complete developer toolkit for scaling A2A agents on Google Cloud