[MCP-A2A ①] AI 실행력 확대 위한 통신 표준 ‘MCP’

[아이티데일리] 인공지능(AI)의 최종 목적지는 어디일까. 아마 많은 사람들은 그 해답을 영화에 등장하는 AI 슈퍼컴퓨터 ‘스카이넷(SKYNET)’, 혹은 가상 인격을 갖춘 개인 AI 비서 ‘자비스(JARVIS)’에서 찾을지 모르겠다. 인간의 개입이 가장 완벽하게 배제되고 자율적 사고를 실행으로까지 옮길 수 있는 영역이 아닐까 싶다.

이처럼 완전한 자율성과 실행력을 갖춘 AI를 현실화하기 위해서는 단순히 데이터를 학습해 답을 내놓는 수준을 넘어, 외부 시스템과의 연결 그리고 여러 AI 간의 협업이 필수적이다. AI가 의미 있는 작업을 수행하기 위해선 다양한 도구와 데이터를 활용하고, 다른 에이전트와 유기적으로 소통할 수 있어야 한다.

AI 에이전트 초입에 들어선 현재, 이러한 요구에 부응하는 두 가지 핵심 기술이 부상하고 있다. 바로 앤트로픽이 출시한 MCP(Model Context Protocol)와 구글이 공개한 A2A(Agent-to-Agent)다. 두 기술은 AI 에이전트가 자율적으로 실행과 협업을 구현하는 근간이 되고 있다. 총 4회에 걸쳐 AI 에이전트 새 지평 여는 ‘MCP’와 ‘A2A’를 상세히 조명해본다.

AI 에이전트 시대 개막

2025년 현재, ‘AI 에이전트’ 시대 초입에 있다. AI는 이제 챗봇 수준을 넘어 특정 목적을 달성하기 위해 AI 모델 스스로 계획하고 도구를 선택하며 일련의 행동을 자동으로 수행할 수 있는 AI 시스템을 뜻하는 AI 에이전트로 발전하고 있다. AI 에이전트는 거대언어모델(LLM)의 응답 수준을 넘어, 인간과 같이 능동적으로 ‘사고하고 행동할 수 있는’ AI를 의미한다.

AI 에이전트가 제대로 작동하기 위해서는 학습된 데이터로 답을 생성하는 능력만으로는 부족하다. 외부 시스템과 LLM이 연결돼 맥락을 유지하고, 다른 AI와 협력하는 등 복잡한 기술 요건들이 선행돼야 한다. AI가 의미 있는 작업을 하려면 API를 호출하고 문서를 분석하며 파일을 수정하고, 다른 AI나 툴과 통신할 수 있는 의사소통 능력이 필요하다.

최근 이러한 수요에 대응할 수 있는 핵심 기술이 IT 업계의 주목을 받고 있다. 바로 앤트로픽이 개발한 MCP(Model Context Protocol)와 구글이 제안한 A2A(Agent-to-Agent communication protocol)다. 이 두 프로토콜은 AI가 진정한 에이전트로 나아가는 데 절대적으로 필요한 ‘연결성’과 ‘협업성’이라는 중요한 축을 담당하고 있다.

AI 실행력 확대 위한 통신 표준 ‘MCP’

현존하는 대부분 LLM은 기본적으로 스테이트리스(stateless) 구조로, 문맥 유지와 외부 데이터 활용에 한계가 있다. 스테이트리스 구조는 각 요청이 이전의 맥락이나 상태 정보를 기억하지 않고 독립적으로 처리되는 시스템 아키텍처를 의미한다. 그렇기 때문에 기존 LLM은 이전에 어떤 요청이 있었는지 알 수 없으며 외부 도구를 사용할 수 없다.

사람의 사고나 작업 흐름과는 본질적으로 다른 방식이다. 사람은 기존의 사고와 문맥을 유지하고 필요한 정보를 찾고 외부 시스템을 다룰 수 있지만, LLM은 그렇지 못하다.

이러한 한계를 극복하고자 앤트로픽은 LLM의 실행력을 확대할 수 있는 프로토콜인 ‘MCP(Model Context Protocol)’를 공개했다. 앤트로픽이 공개한 MCP는 단순히 외부 API를 호출하는 기능을 넘어, AI가 자율적으로 외부 도구를 인식하고 사용하며 상태를 추적하고 계획을 조정할 수 있게 하는 ‘실행 프레임워크’다.

MCP와 관련해 올거나이즈 신기빈 CAIO는 “AI 에이전트를 구동하는 엔진은 LLM이다. 하지만 LLM만으로는 좋은 결과를 낼 수 없다. 가령 사용자가 ‘식당을 예약해줘’라고 아무리 입력해도 LLM은 외부와 통신을 하지 않기 때문에 작업을 완결할 수 없다. 따라서 외부와 LLM 사이에 상호작용하는 부분이 필요하다. 이를 구현하는 기능이 ‘펑션 콜링(Function Calling)’ 혹은 ‘툴 콜링(Tool Calling)’이다. LLM에게 자신이 활용할 수 있는 도구를 알려주고 필요할 때마다 도구의 결과를 요청하도록 만든다. 에이전트 AI의 구동부는 도구를 호출하고 결과를 다시 LLM에게 알려줘 계속 LLM이 작업을 이어갈 수 있게 만든다”면서 “이러한 도구 활용과 LLM 간 통신 방식을 정의한 것이 MCP다. MCP는 지난해 처음 공개됐으며, 커서(Cursor)가 MCP를 지원하면서 활용처를 늘린 것이 MCP의 제작자와 사용자를 폭발적으로 늘린 계기가 됐다”고 설명했다.

MCP는 앤트로픽이 SW 개발에서 널리 쓰이는 LSP(Language Server Protocol)라는 표준 통신 방식에서 영감을 받아 개발한 것으로 알려진다. LSP가 개발자 도구와 언어 서버를 연결하는 표준이었다면, MCP는 AI와 외부 도구를 연결하는 표준이다.

MCP도 LSP와 유사하게 JSON-RPC 방식을 따른다. JSON-RPC는 데이터를 주고받을 때 “이런 작업을 해줘”라고 요청하는 명령(프로시저 명)을 메시지 안에 직접 써서 송출하는 방식이다. 가령 “이 문서 요약해”라는 요청을 메시지에 담아 MCP 서버로 보내는 식이다.

MCP는 기능 목록도 교환한다. MCP 서버가 처음 연결될 때 “이런 도구를 제공할 수 있어”라는 식으로 목록을 알려준다. 이를 통해 AI는 어떤 도구(기능)를 쓸 수 있는지 미리 파악할 수 있다.

이러한 구조 때문에 MCP는 다양한 서버와 클라이언트를 서로 쉽게 연동할 수 있다. 새로운 도구나 기능이 추가돼도 복잡한 설정 없이 즉시 연동이 가능하다.

세 가지 물리적·논리적 계층으로 구성

MCP의 물리적인 시스템은 크게 △외부 LLM △MCP 에이전트 △MCP 서버 등 세가지로 구성된다. MCP 에이전트는 등록된 MCP 서버의 목록을 가지고 있고, 성능 파악 과정을 통해서 각 서버가 제공하는 도구의 목록과 스펙을 획득한다. 그리고 사용자의 요구사항을 LLM으로 해석한다. 이 과정에서 LLM으로 하여금 어떤 도구를 사용해야 원하는 목적을 달성할 수 있는지를 파악·결정하며, 요청 달성을 위한 전체적인 흐름을 통제한다.

이에 관해 디노티시아 한병전 상무는 “MCP는 MCP 에이전트와 MCP 서버가 통신할 수 있는 채널만 오픈되면 기술적으로 타 시스템과의 통신이 가능하다. 일반적으로 MCP 에이전트가 MCP 서버 프로세스를 통째로 복사하면서 만들어지는 파이프를 통해 STDIO(STDIN/STDOUT) 통신하거나, 네트워크 기반 통신을 통해 웹 환경에서 데이터를 받아올 때 실시간 스트리밍이 가능한 SSE(Server Sent Event) 방식을 사용할 수 있다”면서 “같은 컴퓨터 내에서 연결하는 STDIO 방식은 에이전트가 MCP 서버 프로그램을 내부적으로 새로 실행한다는 의미다. 이때 에이전트와 MCP 서버는 파이프를 통해 데이터를 주고받는다. 이 파이프는 운영체제의 표준 입력(STDIN)과 표준 출력(STDOUT)을 사용한다. 에이전트가 MCP 서버에 요청을 보내면, 해당 내용이 STDIN을 통해 서버로 전달되고 서버는 결과를 STDOUT으로 에이전트에 돌려주는 구조다”라고 설명했다.

이어 한 상무는 “MCP 서버는 LLM이나 AI 에이전트가 필요한 정보를 제공하는 외부 데이터 소스(컨텍스트 제공자)와 MCP 에이전트 사이에서 ‘중간 통역사’ 역할을 하는 API 래퍼 계층이다. 이 구조 덕분에 MCP가 LLM 모델 및 외부 도구와 쉽게 통신할 수 있다”고 설명했다.

외부 시스템이나 서비스(API)는 사용법, 데이터 형식, 인증 방식이 모두 다른데, API 래퍼 계층은 이런 복잡한 API를 LLM이나 에이전트가 일관된 방식으로 쉽게 사용할 수 있도록 감싸준다. 즉 MCP 서버는 MCP 에이전트와 LLM이 필요한 데이터나 기능을 가진 컨텍스트 제공자를 연결하는 중개자 역할을 한다는 것이다.

아울러 MCP는 △컨텍스트 메모리 계층(Contextual Memory Layer) △도구 호출 인터페이스(Tool Abstraction Interface) △계획자 및 실행자 아키텍처(Planner Executor Architecture) 등 세 가지 논리적 계층(아키텍처 레이어)으로 구성된다.

컨텍스트 메모리 계층은 기존 LLM이 제공하는 일회성 문맥 유지에서 나아가, 장기적 상태(state)와 중간 결과를 기억할 수 있는 구조를 제공한다. 이를 통해 에이전트는 “지금까지 어떤 일을 해왔는지”를 파악하고, 후속 작업을 조정할 수 있다. 이 계층은 단순 캐시가 아니라, 작업 히스토리와 학습된 맥락을 유기적으로 결합해 상황 인식 능력을 높인다.

도구 호출 인터페이스는 AI가 단순히 “이 API를 호출해”라는 명령을 따르게끔 하는 것이 아닌, 작업 목적에 따라 어떤 도구가 필요한지 판단하고 호출 방식까지 스스로 결정할 수 있도록 한다. MCP는 도구의 기능과 사양을 메타데이터 기반으로 등록하고, AI는 이를 이해한 뒤 자동으로 결합해 사용한다. 이를 통해 완전한 비지도 툴 활용이 가능해진다.

계획자 및 실행자 구조는 인간의 문제 해결 방식인 목표, 계획, 실행, 점검, 재계획의 루프를 모방했다. 복잡한 요청에 대해 AI는 먼저 세부 작업 단위(task)를 자동 분해한 후, 단계마다 어떤 도구를 어떤 순서로 사용할지 계획하고 실행 결과를 평가해 다음 행동을 조정한다. 이처럼 MCP는 단순한 LLM을 하나의 작업 단위 수행 주체(Task Executor)로 탈바꿈시킨다. 이는 AI가 실제 문제 해결을 위해 외부 시스템과 유기적으로 연결되는 구조다.

디노티시아 한병전 상무는 “둘 이상의 MCP 서버를 조합하면 재미있는 결과를 얻을 수도 있다. 예를 들어서 ERP에 있는 데이터를 조회하는 MCP 서버를 만들고 자사 벡터 DB와 결합한다면, 벡터 DB에 있는 고객사의 소개자료를 토대로 ERP에서 관리 중인 상품의 정보와 조합해 재고파악, 마케팅 방안 추천 등을 좀 더 구체적인 데이터를 토대로 수행할 수 있다”고 부연했다.