AI 에이전트 프로토콜, MCP와 A2A가 바꾸는 업무 구조

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

AI 챗봇이 답변만 생성하던 단계에서 벗어나 일정 확인, 문서 검색, 고객 응대, 결제 요청까지 수행하기 시작했습니다. 그런데 여러 업무 시스템과 AI 에이전트를 연결할 때마다 전용 연동 코드를 새로 만든다면 개발비와 보안 부담은 빠르게 커집니다. 지금 AI 에이전트 프로토콜이 주목받는 이유는 화려한 대화 능력보다 이런 연결 문제를 표준화하려는 움직임에 있습니다.

MCP, AI와 업무 도구 사이의 공용 연결부

모델 성능보다 연결 방식이 중요해진 배경

MCP(Model Context Protocol)는 AI 애플리케이션이 파일, 데이터베이스, 사내 검색, SaaS 기능 같은 외부 자원을 일정한 방식으로 발견하고 호출하도록 돕는 공개 프로토콜입니다. 이를 흔히 AI용 USB 규격에 비유하지만, 실제 도입에서는 단순한 연결 단자를 넘어 도구 목록, 입력 형식, 결과 구조와 권한 흐름을 합의하는 계약에 가깝습니다.

예를 들어 영업팀 에이전트가 고객 정보를 찾고 제안서 초안을 만들도록 구성한다고 가정해 보겠습니다. 기존에는 CRM API, 클라우드 저장소, 사내 지식검색 시스템마다 인증과 호출 코드를 따로 작성해야 했지만, MCP 서버가 중간 인터페이스를 제공하면 AI 호스트가 각 도구의 기능을 비교적 일관된 방식으로 사용할 수 있습니다. IT의 개념과 산업적 맥락을 함께 살펴보면 이러한 변화가 단일 제품 유행이 아니라 정보 처리 구조의 재편이라는 점을 이해하기 쉽습니다.

• 리소스: 문서, 스키마, 파일처럼 AI가 읽고 참고할 수 있는 맥락을 제공합니다.
• 도구: 검색, 등록, 수정, 계산처럼 실제 행동을 수행하는 함수를 노출합니다.
• 프롬프트: 반복 업무에 필요한 지시 형식과 입력 항목을 재사용할 수 있게 합니다.
• 권한 계층: 어떤 사용자와 에이전트가 어느 기능까지 호출할지 분리하는 기반이 됩니다.

대화창 안으로 들어오는 업무 화면

최근 흐름에서 눈에 띄는 변화는 MCP가 텍스트 결과 전달에 머물지 않고 상호작용 가능한 화면까지 품기 시작했다는 점입니다. 안정화된 MCP Apps 사양은 서버가 HTML 기반 UI 리소스를 제공하고, 호스트가 격리된 영역에서 이를 표시하며, 사용자가 표나 폼을 조작한 결과를 다시 도구 호출로 연결할 수 있도록 설계됐습니다. 앞으로는 “지난달 매출을 보여줘”라는 요청 뒤에 설명문만 나오는 것이 아니라 필터 가능한 표와 승인 버튼이 함께 나타나는 경험이 보편화될 가능성이 큽니다.

도입 효과는 연결한 도구의 개수가 아니라, 사용자가 대화창을 벗어나지 않고 안전하게 끝낼 수 있는 업무의 비율로 측정하는 편이 좋습니다.

1. 읽기 전용 검색으로 작은 업무를 먼저 연결합니다.
2. 검색 결과의 출처와 호출 로그가 남는지 확인합니다.
3. 수정이나 전송 기능에는 사용자 승인 단계를 추가합니다.
4. UI를 제공한다면 격리 실행, 콘텐츠 보안 정책과 외부 통신 범위를 점검합니다.

A2A, 서로 다른 에이전트가 협업하는 표준

MCP와 경쟁하는 기술이 아닌 이유

A2A(Agent2Agent)는 서로 다른 공급자와 환경에서 실행되는 AI 에이전트가 능력을 공개하고 작업을 주고받도록 만든 개방형 표준입니다. MCP가 한 에이전트와 도구·데이터의 연결에 초점을 둔다면, A2A는 독립된 에이전트 사이의 발견, 위임, 상태 공유와 결과 전달을 다룹니다. 두 기술은 대체재라기보다 서로 다른 층을 담당하는 조합에 가깝습니다.

출장 준비를 예로 들어보겠습니다. 총무 에이전트는 A2A를 통해 항공 예약 에이전트와 비용 심사 에이전트에 각각 업무를 맡길 수 있고, 각 에이전트는 MCP를 이용해 항공 시스템이나 사내 규정 데이터에 접근할 수 있습니다. 하나의 거대한 AI가 모든 계정과 데이터를 보유하는 구조보다 역할과 권한을 나누기 쉽지만, 작업이 여러 에이전트를 거치면서 오류 원인과 책임 경계가 흐려질 수 있다는 새로운 문제가 생깁니다.

스타트업이 먼저 설계해야 할 운영 장치

프로토콜을 채택했다고 상호운용성이 자동으로 완성되는 것은 아닙니다. 동일한 기능도 서버마다 이름과 반환 형식이 다를 수 있고, 장시간 작업이 중단됐을 때 어느 지점부터 재시도할지 별도 정책이 필요합니다. 정보기술의 기본 정의처럼 기술은 정보의 수집과 처리 전반을 포함하므로, 연결 성공 여부만 보지 말고 데이터가 생성·전달·보관되는 전 과정을 살펴야 합니다.

• 에이전트 신원: 호출 주체, 사용자 대리 범위와 서비스 계정을 구분합니다.
• 최소 권한: 조회와 변경 도구를 분리하고 필요한 기간에만 권한을 부여합니다.
• 추적 식별자: 최초 요청부터 하위 에이전트 호출까지 같은 작업 ID로 연결합니다.
• 실패 계약: 시간 초과, 부분 성공, 중복 실행 때의 응답과 보상 절차를 정의합니다.
• 비용 한도: 모델 호출 횟수, 외부 API 비용과 최대 위임 단계를 제한합니다.

에이전트에게 업무를 위임하기 전에 사람이 같은 업무를 처리할 때 필요한 승인자, 증빙 자료와 예외 규칙을 먼저 문서화해야 합니다. 자동화는 존재하지 않던 통제를 만들어 주지 않습니다.

프로토콜 경쟁보다 빨리 바뀔 도입 기준

작은 팀을 위한 90일 실험 설계

스타트업이라면 처음부터 다중 에이전트 플랫폼을 구축하기보다 가치가 분명하고 되돌리기 쉬운 흐름을 고르는 편이 현실적입니다. 문의 분류, 기술 문서 검색, 장애 티켓 초안처럼 사람이 최종 확인할 수 있는 업무가 좋은 출발점입니다. 고객 환불, 계약 체결, 운영 서버 변경처럼 금전이나 서비스 가용성에 직접 영향을 주는 행동은 충분한 관측성과 승인 장치가 갖춰진 뒤로 미뤄야 합니다.

첫 30일에는 한 개의 MCP 서버와 읽기 전용 도구를 연결해 기준 성능을 기록합니다. 다음 30일에는 실패 유형과 권한 문제를 보완하고, 마지막 30일에는 제한된 A2A 위임이나 대화형 UI를 추가해 단일 에이전트 방식과 비교합니다. 디지털 전환의 의미가 궁금하다면 디지털 관련 개념 설명을 참고할 수 있지만, 현장에서는 기술 도입 자체보다 업무 흐름이 실제로 얼마나 단축됐는지가 더 중요한 판단 기준입니다.

1. 기준선 기록: 자동화 전 처리 시간, 오류율, 담당자의 개입 횟수를 측정합니다.
2. 제한된 실험: 비식별 데이터와 읽기 전용 권한으로 시작해 피해 반경을 줄입니다.
3. 품질 평가: 정답률뿐 아니라 출처 제시, 재현성, 실패 감지 능력을 확인합니다.
4. 비용 평가: 호출당 모델 비용과 인프라 비용을 사람이 절약한 시간과 비교합니다.
5. 중단 기준: 권한 위반, 반복 실행 또는 비용 초과가 발생하면 자동으로 작업을 멈춥니다.

사양 버전과 생태계 변화에 대응하는 법

2026년 현재 에이전트 생태계는 프로토콜 기능, 확장 사양과 거버넌스가 함께 빠르게 변하는 구간에 있습니다. 지금 지원되는 기능이라도 클라이언트마다 구현 범위가 다를 수 있으며, 실험 단계의 확장이 안정 사양으로 이동하거나 폐기될 가능성도 있습니다. 따라서 제품 이름에 종속된 설계보다 어댑터 계층을 두고 프로토콜 버전, 서버 기능과 권한 범위를 설정값으로 관리하는 방식이 유리합니다.

구매나 개발 결정을 내릴 때는 “MCP 지원” 같은 한 줄 문구보다 실제 호환 버전, 인증 방식, 원격 서버 연결, 감사 로그와 데이터 보관 위치를 확인해야 합니다. 분기마다 지원 사양과 위협 모델을 다시 검토하고, 핵심 업무에는 기존 API 경로나 수동 처리 절차를 남겨 두세요. 표준은 연결 비용을 낮추지만 운영 책임까지 대신하지는 않으며, 시간이 지나 가장 크게 달라질 부분은 어떤 프로토콜이 살아남느냐보다 각 구현체가 제공하는 보안·관측성·복구 수준일 가능성이 큽니다.

• 프로토콜 버전과 사용 중인 확장 기능을 자산 목록에 기록합니다.
• 서버 업데이트 전 테스트 환경에서 도구 스키마 변경과 권한 확대 여부를 비교합니다.
• 특정 모델이나 호스트 없이도 핵심 업무를 복구할 수 있는 대체 경로를 유지합니다.
• 월별 비용과 성공률 외에 사용자 승인 취소율, 중복 실행률도 함께 관찰합니다.
• 공식 사양의 안정 상태와 폐기 일정을 분기 단위로 확인해 전환 시간을 확보합니다.