AI 에이전트는 챗GPT의 기본 Q&A 모드처럼 하나의 프롬프트에 응답하는 기존 AI 모델과 달리 다양한 툴과 데이터 소스, API, 그리고 다른 에이전트와 상호작용하면서 여러 단계의 작업을 계획, 추론, 실행한다.

추상적으로 들릴 수 있다. 실제로도 그렇다. 에이전트 AI가 할 수 있는 일에 대한 이 같은 정의나 기대에는 대부분 사람이 동의하겠지만 아직은 너무 이론적인 이야기로, 현재 사용 가능한 많은 AI 에이전트는 이 같은 정의 수준에 이르지 못한다.

필자의 동료 션 팔코너가 최근 언급했듯이 AI 에이전트는 현재 “표준화 전 단계”에 있다. AI 에이전트가 무엇을 해야 하고 무엇을 할 수 있는지에 대해서는 대체로 동의가 이뤄졌지만 현재의 AI 에이전트에는 단순한 작업이 아닌 실제로 중요한 작업을 수행하기 위해 필요한 상호운용성이 부족하다.

세일즈포스, 위키 페이지 또는 기타 CRM 등 사용자 자신이나 애플리케이션이 일상적으로 액세스해야 하는 데이터 시스템이 얼마나 많은지 생각해 보자. 이런 여러 시스템이 현재 통합돼 있지 않거나 호환되는 데이터 모델이 없다면 일이 더 늘어날 뿐이다. AI 에이전트를 위한 표준화된 통신 수단이 없다면 또 다른 유형의 데이터 사일로를 구축하게 될 뿐이다.

AI 리서치가 가진 잠재력을 프로덕션 시스템과 비즈니스 결과로 전환할 수 있는 전문성을 갖추면 업계가 앞으로 어떻게 변화하든 관계없이 경쟁력을 확보할 수 있다. 이 글에서는 에이전트 생태계에서 부상하고 있는 3가지 개방형 프로토콜을 살펴보면서 이런 프로토콜이 유용한 AI 에이전트, 즉 복잡한 현실 세계의 문제에 적용할 수 있는 지속 가능한 솔루션을 구축하는 데 어떻게 도움이 되는지 설명한다.

AI 에이전트 개발 현황

AI 프로토콜로 들어가기 전에 실무적인 예를 들어서, 비즈니스 수익에 대해 더 자세히 알아보려는 경우를 가정해 보자. 다음과 같은 프롬프트를 사용해 에이전트에 간단한 질문을 할 수 있다.

우리 클라우드 제품의 Q3 수익을 예측해줘.

소프트웨어 엔지니어링 관점에서 에이전트 프로그램은 AI 모델을 사용해 이 입력을 해석하고 원하는 목표를 달성하기 위한 실행 계획을 자율적으로 수립한다. 이 목표를 어떻게 달성하는지는 전적으로 에이전트가 액세스할 수 있는 툴에 따라 달라진다.

에이전트는 활성화되면 먼저 /tools 디렉토리에서 툴을 검색한다. 이 디렉토리에는 에이전트가 무엇을 할 수 있는지를 평가하기 위한 가이드 파일이 있다. 예를 들면 다음과 같다.

• /tools/list
• /Planner
• /GenSQL
• /ExecSQL
• /Judge

다음 다이어그램을 기준으로 봐도 된다.

Confluent

프롬프트를 받는 주 에이전트는 컨트롤러 역할을 한다. 컨트롤러는 검색과 관리 기능이 있으며 툴,그리고 다른 에이전트와 직접 통신한다. 이 과정은 다음의 기본 5단계로 구성된다.

1. 컨트롤러가 계획 에이전트를 호출한다.
2. 계획 에이전트가 실행 계획을 반환한다.
3. 평가자가 실행 계획을 검토한다.
4. 컨트롤러가 젠SQL(GenSQL)과 이젝SQL(ExecSQL)을 활용해 계획을 실행한다.
5. 평가자가 최종 계획을 검토하고, 계획을 수정하고 다시 실행해야 하는지 여부를 결정하기 위한 피드백을 제공한다.

위 과정을 보면 알 수 있듯이 컨트롤러와 나머지 에이전트 사이에 여러 이벤트와 메시지가 오가는데, 이를 AI 에이전트 통신이라고 한다.

AI 에이전트 통신을 위한 떠오르는 프로토콜

업계에서는 에이전트 통신을 표준화할 방법을 두고 논쟁이 뜨겁다. AI 에이전트가 더 쉽게 툴이나 데이터에 액세스하고 다른 에이전트와 통신하거나 상호작용을 처리할 수 있도록 할 방법은 무엇일까?

현재 사용되는 프로토콜은 모델 컨텍스트 프로토콜(Model Context Protocol, MCP), 에이전트2에이전트(Agent2Agent, A2A) 프로토콜, 그리고 에이전트 통신 프로토콜(Agent Communication Protocol, ACP)이다. 각 AI 에이전트 통신 프로토콜이 어떻게 작동하는지 살펴보자.

MCP

앤트로픽이 개발한 MCP는 AI 에이전트와 모델이 작업과 툴, 다단계 추론에서 컨텍스트를 관리, 공유하고 활용하는 방법을 표준화하기 위해 설계됐다. 클라이언트-서버 아키텍처에서는 AI 애플리케이션을 서버(외부 리소스에 대한 액세스 제공)에 정보를 요청하는 클라이언트로 취급한다.

예를 들어 모든 데이터가 아파치 카프카 토픽에 저장돼 있다고 가정하면 전용 카프카 MCP 서버를 구축할 수 있다. 여기서 앤트로픽의 AI 모델인 클로드는 MCP 클라이언트 역할을 할 수 있다.

아타반 카나풀리가 만든 깃허브의 이 예제를 보면, 아칸은 클로드에 카프카 브로커에 연결해서 브로커에 포함된 모든 토픽을 나열하도록 요청한다. MCP를 사용하면 아칸의 클라이언트 애플리케이션은 카프카 브로커에 액세스하는 방법을 알 필요가 없다. 클라이언트가 알아서 서버로 요청을 보내고, 서버는 요청을 변환해서 관련 카프카 함수를 실행하기 때문이다.

아칸의 경우 사용 가능한 토픽이 없었다. 클라이언트는 아칸에게 전용으로 사용할 파티션과 복제 수가 지정된 토픽을 생성할지 여부를 묻는다. 아칸의 첫 번째 요청과 마찬가지로, 클라이언트는 카프카 토픽과 파티션을 생성하거나 구성하는 방법을 찾아볼 필요가 없다. 아칸은 에이전트에 “countries” 토픽을 생성하고 나중에 해당 카프카 토픽을 설명하도록 요청한다.

이를 위해서는 서버가 무엇을 할 수 있는지 정의해야 한다. 아타반 카나풀리의 아칸 프로젝트에서 이 코드는 handler.go 파일에 있다. 이 파일에는 서버가 처리하고 실행할 수 있는 기능 목록이 포함돼 있다. CreateTopic 예제는 다음과 같다.

// CreateTopic creates a new Kafka topic// Optional parameters that can be passed via FuncArgs are:// - NumPartitions: number of partitions for the topic// - ReplicationFactor: replication factor for the topicfunc (k *KafkaHandler) CreateTopic(ctx context.Context, req Request) (*mcp_golang.ToolResponse, error) {	if err := ctx.Err(); err != nil {		return nil, err	}	if err := k.Client.CreateTopic(req.Topic, req.NumPartitions, req.ReplicationFactor); err != nil {		return nil, err	}	return mcp_golang.NewToolResponse(mcp_golang.NewTextContent(fmt.Sprintf("Topic %s is created", req.Topic))), nil}

이 예제는 광범위하게 도입된 오픈소스 기술인 아파치 카프카를 사용하지만 앤트로픽은 이 방법을 일반화해서 호스트를 정의한다. 호스트는 연결을 시작하는 LLM 애플리케이션이다. 앤트로픽의 MCP 아키텍처 다이어그램에 나와 있듯이 모든 호스트는 여러 개의 클라이언트를 가질 수 있다.

Anthropic

데이터베이스를 위한 MCP 서버는 모든 데이터베이스 기능을 유사한 핸들러를 통해 노출한다. 그러나 더 정교하게 구현하려면 해당 서비스에 특화된 기존 프롬프트 템플릿을 정의할 수도 있다.

예를 들어 의료 데이터베이스라면 환자 건강 데이터를 위한 전용 기능을 둘 수 있다. 이를 통해 사용자 경험을 간소화하고, 정확한 결과를 보장하면서 민감하고 개인적인 환자 정보를 보호하는 프롬프트 가드레일을 제공할 수 있다. 그 외에도 배울 만한 내용이 많은데, 여기에서 MCP에 대해 자세히 알아볼 수 있다.

A2A 프로토콜

구글이 A2A 프로토콜은 AI 에이전트가 프레임워크나 업체 종속 없이 서로 직접 통신, 협업, 조율해 복잡한 작업을 해결할 수 있게 해준다. A2A는 구글의 에이전트 개발 키트(Agent Development Kit, ADK)와 관계는 있지만 별개의 구성요소이며 ADK 패키지에 포함되지 않는다.

A2A는 에이전트 애플리케이션 간의 불투명한 통신으로 이어진다. 불투명하다는 말은 상호작용하는 에이전트들이 정보를 교환하기 위해 각자의 내부 아키텍처나 로직을 노출하거나 조율할 필요가 없다는 의미다. 따라서 다양한 팀과 조직이 새로운 제약 조건을 더하지 않으면서 자유롭게 에이전트를 구축하고 연결할 수 있다.

실제로 A2A가 동작하기 위해서는 에이전트 카드라고 하는 ID 파일에 메타데이터 형식으로 에이전트가 기술돼 있어야 한다. A2A 클라이언트는 구조화된 메시지 형식으로 A2A 서버에 요청을 전송하며, 장시간 실행되는 작업에 대해 실시간 업데이트를 받는다. 구글의 A2A 깃허브 리포지토리에서 이 핵심 개념에 대해 살펴볼 수 있다.

A2A의 유용한 예제로는 의료 사용례가 있다. 이 사례에서는 업체의 에이전트가 A2A 프로토콜을 사용해 다른 지역의 다른 업체와 통신한다. 에이전트는 카프카를 통해 데이터 암호화, 인증(OAuth/JWT), 그리고 구조화된 건강 데이터의 비동기 전송을 보장해야 한다.

마찬가지로 A2A 깃허브 리포지토리에서 더 자세히 알아볼 수 있다.

ACP

IBM에서 개발한 ACP는 AI 에이전트와 애플리케이션, 인간 간의 통신을 위한 개방형 프로토콜이다. IBM은 다음과 같이 설명한다.

ACP에서 에이전트는 소프트웨어 서비스로, 주로 자연어를 기반으로 하는 멀티모달 메시지를 통해 통신한다. 이 프로토콜은 에이전트의 내부 작동 방식을 가리지 않으며 원활한 상호운용성을 위해 필요한 최소한의 전제 조건만 명시한다.

ACP 깃허브 리포에 정의돼 있는 핵심 개념을 살펴보면 ACP와 A2A가 비슷하다는 것을 알 수 있다. 두 프로토콜 모두 에이전트 벤더 종속을 없애고 개발 속도를 높이고 커뮤니티에서 제작한 에이전트를 세부적인 구현 방식과 관계없이 메타데이터를 사용해 쉽게 검색할 수 있도록 설계됐다. 다만 한 가지 중요한 차이점이 있다. ACP는 IBM의 비AI(BeeAI) 오픈소스 프레임워크를 활용해 에이전트 간 통신을 가능하게 하는 반면 A2A는 서로 다른 프레임워크의 에이전트들이 통신할 수 있도록 한다는 점이다.

비AI 프레임워크의 종속성을 이해하기 위해 자세히 살펴보자. 현재 비AI 프로젝트를 구성하는 3가지 핵심 요소는 다음과 같다.

• 비AI 플랫폼 – AI 에이전트 검색, 실행, 구성
• 비AI 프레임워크 – 파이썬 또는 타입스크립트로 에이전트 구축
• ACP – 에이전트 간 통신

에이전틱 AI의 미래

높은 수준에서 보면 이 세 가지 통신 프로토콜은 자율 AI 에이전트 구축을 목표로 하되 서로 해결하는 과제는 조금씩 다르다.

• 앤트로픽의 MCP는 에이전트를 툴과 데이터에 연결한다.
• 구글 A2A는 에이전트 간 협업을 표준화한다.
• IBM의 ACP는 비AI 에이전트 협업에 초점을 맞춘다.

MCP가 실제로 작동하는 모습이 궁금하다면 자연어로 카프카 토픽을 질의하는 이 데모를 보면 된다. 구글과 IBM은 앤트로픽의 MCP 프로젝트가 성공하자 그에 대응하기 위해 최근에야 각자의 에이전트 통신 프로토콜을 출시했다. 필자는 이런 새로운 기술이 앞으로 어떻게 도입되고 발전해 나가는지 여러분과 함께 계속 배우면서 지켜보고자 한다.

에이전틱 AI의 세계가 계속 확장되는 지금, 시간과 노력을 절약해 주는 프로토콜, 툴, 접근 방식을 우선적으로 배우고 도입할 것을 권한다. AI 에이전트의 적응력과 지속가능성이 높을수록 개발자는 실제 문제를 해결하도록 에이전트를 개선하는 데 더 집중할 수 있다.
dl-itworldkorea@foundryco.com