에이전트 통신 프로토콜(ACP)이란 무엇인가요?

작성자

Sandi Besen

AI Research Engineer and Ecosystem Lead

IBM

AI Engineer, Developer Advocate

IBM

에이전트 통신 프로토콜(ACP)은 에이전트 간 통신을 위한 개방형 표준입니다. 이 프로토콜을 사용하면 사일로화된 에이전트의 현재 환경을 더 쉬운 통합과 협업을 통해 상호 운용이 가능한 에이전트 시스템으로 전환할 수 있습니다.

업계 뉴스레터

전문가가 전하는 최신 AI 트렌드

가장 중요하고 흥미로운 AI 뉴스에 대한 선별된 인사이트를 확인하세요. 주간 Think 뉴스레터를 구독하세요. IBM 개인정보 보호정책을 참조하세요.

개요

AI 에이전트는 원래 IBM® BeeAI에서 도입한 ACP를 통해 팀, 프레임워크, 기술 및 조직 전반에서 자유롭게 협업할 수 있습니다. 이는 오늘날 AI 에이전트의 파편화된 환경을 상호 연결된 팀원으로 전환하는 범용 프로토콜이며, 이 개방형 표준은 새로운 수준의 상호 운용성, 재사용 및 확장성을 제공합니다. ACP는 도구 및 데이터 액세스를 위한 개방형 표준인 모델 컨텍스트 프로토콜(MCP)에 이어 다음 단계로, 에이전트가 작동하고 통신하는 방식을 정의합니다.¹

AI 에이전트는 상황에 따라 사용자 또는 다른 시스템을 대신하여 자율적으로 작업을 수행할 수 있는 시스템 또는 프로그램입니다. 워크플로를 설계하고 사용 가능한 도구를 활용하여 작업을 수행합니다. 다중 에이전트 시스템은 사용자 또는 다른 시스템을 대신하여 작업을 수행하기 위해 공동으로 작동하는 여러 인공 지능(AI) 에이전트로 구성됩니다.

개방형 거버넌스를 갖춘 AI 에이전트 통신 표준인 ACP는 인공 지능 에이전트가 다양한 프레임워크와 기술 스택을 통해 통신할 수 있도록 합니다. 자연어 형태의 사용자 쿼리를 받는 것부터 일련의 작업을 수행하는 것까지, AI 에이전트는 통신 프로토콜을 통해 더 나은 성능을 발휘합니다. 이러한 프로토콜은 이 정보를 도구 간에, 다른 에이전트 간에 전달하고 궁극적으로 사용자에게 전달합니다.

AI 에이전트 통신은 인공 지능 에이전트가 서로, 인간 또는 외부 시스템과 상호 작용하여 정보를 교환하고, 의사 결정을 내리고, 작업을 완료하는 방식을 말합니다. 이러한 통신은 여러 AI 에이전트가 협업하는 다중 에이전트 시스템과 인간-AI 상호 작용에서 특히 중요합니다.

ACP는 BeeAI를 포함하여 성장하는 에코시스템의 일부입니다. 다음은 몇 가지 주요 기능으로, 핵심 개념과 세부 사항에 대한 자세한 내용은 공식 문서에서 확인할 수 있습니다.

서로 다른 프레임워크의 ACP 클라이언트와 ACP 에이전트가 통신하는 예시입니다.

ACP의 주요 기능

REST 기반 통신: ACP는 프로덕션에 쉽게 통합할 수 있도록 통신에 표준 HTTP 규약을 사용합니다. MCP는 훨씬 더 복잡한 통신 방법이 필요한 JSON-RPC 형식에 의존합니다.
SDK가 필요하지 않음: ACP에는 특수 라이브러리가 필요하지 않습니다. cURL, Postman 또는 브라우저와 같은 도구를 사용하여 지능형 에이전트와 상호 작용할 수 있습니다. 추가적인 편의를 위해 SDK를 사용할 수 있습니다.
오프라인 탐색: ACP 에이전트는 메타데이터를 배포 패키지에 직접 포함할 수 있으므로 비활성 상태일 때에도 탐색할 수 있습니다. 이는 리소스가 동적으로 할당되고 항상 온라인 상태가 아닐 수도 있는 스케일 투 제로 환경을 지원합니다.
비동기 우선, 동기화 지원: ACP는 비동기 통신을 기본값으로 사용하도록 설계되었습니다. 이 방법은 장기로 실행되거나 복잡한 작업에 이상적입니다. 동기식 요청도 지원됩니다.

참고: ACP는 모든 에이전트 아키텍처에 대한 에이전트 오케스트레이션을 지원하지만, 에이전트 간의 워크플로, 배포 또는 조정을 관리하지 않습니다. 대신 통신 방식을 표준화하여 다양한 에이전트 간의 오케스트레이션을 가능하게 합니다. IBM® Research는 ACP를 통신 계층으로 사용하여 에이전트 오케스트레이션, 배포 및 공유를 처리하도록 설계된 오픈 소스 시스템인 BeeAI를 구축했습니다.

AI 에이전트

AI 에이전트의 5가지 유형: 자율 기능 및 실제 애플리케이션

목표 중심 및 유틸리티 기반 AI가 워크플로와 복잡한 환경에 어떻게 적응하는지 알아보세요.

AI 에이전트 구축, 배포 및 모니터링

ACP가 필요한 이유

ACP를 사용하여 구현 가능한 다양한 에이전트 아키텍처입니다.

에이전트 AI가 계속 성장함에 따라 특정 공급업체에 얽매이지 않고 사용 사례에 대해 각 독립 기술에서 최상의 결과를 얻는 방법을 탐색할 때의 복잡성도 커지고 있습니다. 각 프레임워크, 플랫폼 및 툴킷은 고유한 이점을 제공하지만 모두 하나의 에이전트 시스템으로 통합하는 것은 어렵습니다.

오늘날 대부분의 에이전트 시스템은 사일로화된 상태로 운영됩니다. 호환되지 않는 프레임워크를 기반으로 구축되고 사용자 지정 API 및 엔드포인트를 노출하며 통신을 위한 공유 프로토콜이 없습니다. 이를 연결하려면 취약하고 재현이 불가능한 통합이 필요하며 이는 구축 비용이 매우 높습니다.

ACP는 단편화된 임시 에코시스템에서 상호 연결된 에이전트 네트워크로의 근본적인 변화를 나타냅니다. 이 네트워크에서 각 에이전트는 구축 주체나 실행에 사용되는 기술 스택 등에 관계없이, 다른 에이전트를 발견하고 이해하며 협력할 수 있습니다. ACP를 사용하면 개발자는 다양한 에이전트의 집단 지능을 활용하여 단일 시스템만으로 달성할 수 있는 것보다 더 강력한 워크플로를 구축할 수 있습니다.

현재 과제

에이전트의 기능의 급속한 성장에도 불구하고 실제 통합은 여전히 주요 병목 현상으로 남아 있습니다. 공통된 통신 프로토콜이 없으면 조직은 다음과 같은 몇 가지 반복되는 과제에 직면합니다.

프레임워크 다양성: 조직은 일반적으로 LangChain, crewAI, AutoGen 또는 사용자 지정 스택과 같은 다양한 프레임워크를 사용하여 구축된 수백 또는 수천 개의 에이전트를 실행합니다.
사용자 지정 통합: 표준 프로토콜이 없으면 개발자는 각 에이전트 상호 작용마다 사용자 지정 커넥터를 작성해야 합니다.
기하급수적인 개발: n개의 에이전트를 사용하면 잠재적으로 n(n-1)/2개의 서로 다른 통합 지점이 필요하므로 대규모 에이전트 에코시스템을 유지 관리하기가 어려워집니다.
조직 간 고려 사항: 서로 다른 보안 모델, 인증 시스템, 데이터 형식으로 인해 조직 간 통합이 복잡해집니다.

실제 사례

에이전트 간 통신의 실제 필요성을 설명하기 위해 다음 두 가지 조직을 고려해 보겠습니다.

내부 재고 및 고객 수요를 기반으로 생산 일정 및 주문 이행을 관리하기 위해 자율 에이전트를 사용하여 하는 제조 회사
실시간 배송 견적, 운송업체 가용성 및 경로 최적화를 제공하기 위해 에이전트를 운영하는 물류 제공업체

ACP를 사용하여 활성화되고 조직 간에 서로 통신하는 두 에이전트(제조 및 물류)의 사용 사례 예시입니다.

이제 제조업체의 시스템이 고객에게 견적을 안내하기 위해 대규모 맞춤형 장비 주문에 대한 배송 일정을 추정해야 한다고 상상해 보겠습니다.

ACP가 없는 경우: 이 접근 방식에는 제조업체의 계획 소프트웨어와 물류 제공업체의 API 간의 맞춤형 통합을 구축해야 합니다. 이는 인증, 데이터 형식 불일치, 서비스 가용성 등을 수동으로 처리해야 한다는 것을 의미합니다. 이러한 통합은 비용이 많이 들고 불안정하며, 더 많은 파트너가 참여할수록 확장하기 어렵습니다.

ACP를 사용하는 경우: 각 조직은 ACP 인터페이스에 에이전트를 포함시킵니다. 제조업체 에이전트는 주문 및 목적지 세부 정보를 물류 에이전트로 보내고, 물류 에이전트는 실시간 배송 옵션과 ETA로 응답합니다. 두 시스템 모두 내부를 노출하거나 사용자 지정 통합을 작성하지 않고도 에이전트 협업을 수행합니다. ACP를 구현하기만 하면 새로운 물류 파트너를 도입할 수 있습니다. ACP와 페어링된 AI 에이전트가 제공하는 자동화를 통해 확장성을 확보하고 데이터 교환을 간소화할 수 있습니다.

시작하는 방법

단순성은 ACP의 핵심 설계 원칙입니다. 단 몇 줄의 코드만으로 에이전트를 ACP로 포함시킬 수 있습니다. Python SDK를 사용하면 함수를 데코레이팅하기만 하면 ACP 호환 에이전트를 정의할 수 있습니다.

이 최소한의 구현은 다음과 같습니다.

ACP 서버 인스턴스를 생성합니다.
@server.agent() 데코레이터를 사용하여 에이전트 함수를 정의합니다.
컨텍스트 지속성을 위해 대규모 언어 모델(LLM) 백엔드 및 메모리와 함께 LangChain 프레임워크를 사용하여 에이전트를 구현합니다.
ACP의 메시지 형식과 프레임워크의 기본 형식 간에 변환하여 구조화된 응답을 반환합니다.
서버를 시작하여 에이전트를 HTTP를 통해 사용할 수 있도록 합니다.

코드 예시:

from typing import Annotated
import os
from typing_extensions import TypedDict
from dotenv import load_dotenv
#ACP SDK
from acp_sdk.models import Message
from acp_sdk.models.models import MessagePart
from acp_sdk.server import RunYield, RunYieldResume, Server
from collections.abc import AsyncGenerator
#Langchain SDK
from langgraph.graph.message import add_messages
from langchain_anthropic import ChatAnthropic 

load_dotenv() 

class State(TypedDict):
    messages: Annotated[list, add_messages]

#Set up the AI model of your choice
llm = ChatAnthropic(model="claude-3-5-sonnet-latest", 
api_key=os.environ.get("ANTHROPIC_API_KEY")) 

#------ACP Requirement-------#
#START SERVER
server = Server()
#WRAP AGENT IN DECORACTOR
@server.agent()
async def chatbot(messages: list[Message])-> AsyncGenerator[RunYield, RunYieldResume]:
    "A simple chatbot enabled with memory"
    #formats ACP Message format to be compatible with what langchain expects
    query = " ".join(
        part.content
        for m in messages
        for part in m.parts             
    )
    #invokes llm
    llm_response = llm.invoke(query)    
    #formats langchain response to ACP compatible output
    assistant_message = Message(parts=[MessagePart(content=llm_response.content)])
    # Yield so add_messages merges it into state
    yield {"messages": [assistant_message]}  

server.run()
#---------------------------#

이제 ACP를 완전히 준수하며 다음 기능을 수행할 수 있는 에이전트를 만들었습니다.

다른 에이전트가 검색할 수 있습니다(온라인 또는 오프라인).
동기식 또는 비동기식으로 요청을 처리합니다.
표준 메시지 형식을 사용하여 통신합니다.
다른 ACP 호환 시스템과 통합할 수 있습니다.

ACP와 MCP 및 A2A의 비교

진화하는 AI 에코시스템에서 ACP의 역할을 더 잘 이해하려면 이를 다른 신규 프로토콜들과 비교하는 것이 도움이 됩니다. 이러한 프로토콜이 반드시 경쟁자일 필요는 없습니다. 대신 AI 시스템 통합 스택의 다양한 계층을 다루고 종종 서로를 보완합니다.

한눈에 보기:

모델 컨텍스트 프로토콜(MCP): 도구, 메모리 및 리소스로 단일 모델의 컨텍스트를 강화하도록 설계되었습니다. Anthropic에 의해 도입되었습니다.
초점: 하나의 모델, 다양한 도구

에이전트 통신 프로토콜(ACP): 여러 시스템과 조직 전반에서 독립적인 에이전트 간 통신을 위해 설계되었습니다. IBM의 BeeAI에 의해 도입되었습니다.
초점: 많은 에이전트, 피어로 안전하게 작업, 공급업체 종속 없음, 개방형 거버넌스

Agent2Agent 프로토콜(A2A): 여러 시스템과 조직 전반에서 독립적인 에이전트 간 통신을 위해 설계되었습니다. Google에서 도입했습니다.

초점: 많은 에이전트, 피어로 작업, Google 에코시스템에 최적화됨

ACP 및 MCP

ACP 팀은 처음에 모델 컨텍스트 프로토콜(MCP)이 모델-컨텍스트 상호 작용을 위한 강력한 기반을 제공하기 때문에 이를 조정하는 방법을 모색했습니다. 그러나 곧 진정한 에이전트 간 통신에 적합하지 않은 아키텍처 제한에 직면했습니다.

MCP가 다중 에이전트 시스템에 부족한 이유:

스트리밍: MCP는 완전한 메시지일 가능성이 있는 기본 스트리밍을 지원하지만, 업데이트가 발생하는 즉시 전송되는 세분화된 '델타' 스타일은 지원하지 않습니다. 토큰 및 궤적 업데이트와 같은 델타 스트림은 완전한 데이터 페이로드가 아닌 증분 업데이트로 구성된 스트림입니다. MCP가 개발될 당시 에이전트 스타일 상호 작용을 목적으로 설계되지 않았기 때문에 이러한 제한이 존재합니다.

메모리 공유: MCP는 공유 메모리를 유지하면서 서버 간에 여러 에이전트를 실행하는 것을 지원하지 않습니다. ACP도 아직 이 기능을 완전히 지원하지는 않지만 활발히 개발 중인 영역입니다.

메시지 구조: MCP는 모든 JSON 스키마를 허용하지만 메시지 본문의 구조를 정의하지 않습니다. 이러한 유연성으로 인해 상호 운용성이 어려워지며, 특히 다양한 메시지 형식을 해석해야 하는 에이전트를 구축하는 경우 더욱 그렇습니다.

프로토콜 복잡성: MCP는 JSON-RPC를 사용하며 특정 SDK와 런타임이 필요합니다. 비동기/동기화 지원이 내장된 ACP의 REST 기반 설계는 더 가볍고 통합 친화적입니다.

MCP는 성능를 향상시킬 수 있는 계산기나 참고서와 같은 더 나은 도구를 제공하는 것이라고 생각할 수 있습니다. 반면, ACP는 사람들이 각 개인 또는 에이전트가 AI 애플리케이션 내에서 협업하여 자신의 기능을 발휘할 수 있도록 지원하는 팀을 구성하도록 지원하는 것입니다.

ACP와 MCP는 서로를 보완할 수 있습니다.

ACP 직후 도입된 Google의 Agent2Agent 프로토콜(A2A)도 AI 에이전트 간의 통신을 표준화하는 것을 목표로 합니다. 두 프로토콜 모두 다중 에이전트 시스템을 구현한다는 목표를 공유하지만, 철학과 거버넌스 측면에서 차이가 있습니다.

주요 차이점:

ACP는 다음을 위한 목적으로 의도적으로 설계되었습니다.

일반적인 HTTP 도구와 REST 규칙을 사용하여 간편하게 통합할 수 있습니다.
다양한 에이전트 유형과 워크로드에 유연하게 대응할 수 있습니다.
개방형 거버넌스와 광범위한 에코시스템 조정을 통해 공급업체 중립적입니다.

두 프로토콜은 공존할 수 있으며 각각 환경에 따라 서로 다른 요구 사항을 충족합니다. ACP의 가볍고 개방적이며 확장 가능한 설계는 분산형 시스템과 조직 경계를 넘어 실제 상호 운용성에 매우 적합합니다. A2A의 자연스러운 통합은 Google 에코시스템을 사용하는 사람들에게 더 적합한 선택이 될 수 있습니다.