디지털 환경은 인간 중심의 웹 브라우징을 넘어 다양한 시스템에서 원활하게 협업하는 자율 에이전트의 영역으로 진화하고 있습니다. 이러한 변화는 새로운 인프라를 필요로 하며, 네 가지 주요 오픈 소스 구성 요소로 구성된 매력적인 솔루션이 구체화되고 있습니다.
- Google의 Agent2Agent (A2A): 에이전트 검색 및 상호 작용을 용이하게 하도록 설계된 프로토콜입니다.
- Anthropic의 Model Context Protocol (MCP): 에이전트가 도구 및 외부 컨텍스트 데이터를 활용하는 방법을 정의하는 표준입니다.
- Apache Kafka: 안정적이고 분리된 조정을 가능하게 하는 강력한 이벤트 기반 통신 백본입니다.
- Apache Flink: 에이전트 활동 스트림을 풍부하게 하고 모니터링하고 이에 따라 조치를 취하는 데 필수적인 실시간 처리 엔진입니다.
본 문서에서는 이러한 기술 간의 시너지 관계를 살펴보고 프로토콜에만 의존하는 것의 한계를 강조하고 이 아키텍처가 고립된 봇에서 동적이고 지능적인 에이전트 생태계로 전환하기 위한 토대를 어떻게 마련하는지 보여줍니다.
조직 내 AI 에이전트의 확산이 예상됨에 따라 대부분의 회사는 단일한 포괄적인 에이전트가 아닌 여러 개의 전문 에이전트를 배포할 것으로 예상됩니다. 이러한 에이전트는 코드 생성, 지원 티켓 관리, 고객 데이터 분석, 직원 온보딩 및 인프라 모니터링과 같은 작업을 자동화합니다.
그러나 현재 도구는 이러한 미래를 지원하기에 부족합니다.
문제는 에이전트가 사일로에서 작동하고 통신 기능이 부족한 ‘에이전트 섬’ 문제를 넘어 더 광범위한 생태계 파편화로 확장됩니다.
- 에이전트 간 통신 부족: 에이전트는 일반적으로 고립된 환경 내에서 작동합니다. 고객 관계 관리 (CRM) 에이전트는 데이터 웨어하우스 에이전트가 파생한 통찰력을 알지 못합니다. 지원 에이전트는 모니터링 에이전트가 감지한 이상에 응답할 수 없습니다.
- 취약하고 맞춤화된 도구 사용: 도구 또는 외부 애플리케이션 프로그래밍 인터페이스 (API) 에 액세스하기 위한 표준화된 방법이 없으면 에이전트는 하드 코딩된 통합 및 재사용할 수 없는 로직에 의존합니다.
- 일관성 없는 프레임워크: 다양한 에이전트 런타임은 다양한 모델을 사용하여 에이전트를 챗봇, 방향성 비순환 그래프 (DAG) 또는 재귀적 플래너로 취급합니다. 이로 인해 이식 가능한 실행 계층 또는 공유 상태가 없습니다.
- 노트북 환경에 초점을 맞춘 설계: 많은 에이전트가 일회성 프로토타입으로 개발되며 선형, 동기식 및 임시 작업이 특징입니다. 그러나 실제 시스템에서는 재시도, 오류, 조정, 로깅 및 확장을 강력하게 처리해야 하며 이를 위해서는 지원 인프라가 필요합니다.
- 협업 백본 부재: 이벤트 버스, 공유 메모리 또는 에이전트 활동 및 근거의 추적 가능한 기록이 없습니다. 정보는 직접 HTTP 호출에 국한되거나 로그 내에 묻혀 있습니다.
12-Factor Agents 프로젝트에서 강조한 것처럼 에이전트는 가시성, 느슨한 결합, 재현성 및 인프라 인식을 나타내는 클라우드 네이티브 원칙을 준수해야 합니다. 불행히도 대부분은 수동으로 조립되고 독립적으로 작동한다고 가정되는 깨지기 쉬운 스크립트로 구성됩니다.
이로 인해 비효율성, 노력 중복 및 취약성이 발생합니다.
Agent2Agent는 에이전트에게 검색 및 통신을 위한 표준화된 프로토콜을 제공하여 이 문제를 부분적으로 해결합니다. 그러나 피상적인 데모를 넘어 프로덕션 시스템에 필요한 확장성과 안정성으로 전환하려면 프로토콜 그 이상이 필요합니다. 포괄적인 인프라가 필요합니다.
현재 에이전트 생태계는 강력하지만 고립되고 호환되지 않는 시스템이 특징인 웹의 초기 단계를 반영합니다. 표준 프로토콜 없이 서버와 통신하는 브라우저가 직면한 초기 문제와 유사하게 오늘날 AI 에이전트는 서로 효과적으로 검색, 통신 및 협업하는 데 어려움을 겪고 있습니다.
Google의 Agent2Agent (A2A): 에이전트 통신을 위한 범용 프로토콜
Google의 A2A 프로토콜은 이 문제를 해결하려는 중요한 시도입니다. 또 다른 에이전트 프레임워크가 아니라 출처나 배포 환경에 관계없이 모든 에이전트를 연결하도록 설계된 범용 프로토콜이라는 점에서 차별화됩니다.
HTTP가 웹사이트 통신을 표준화한 것과 유사하게 A2A는 에이전트를 위한 공통 언어를 정의하여 다음과 같은 기능을 제공합니다.
- 기능 발표: 에이전트의 기능과 상호 작용 방법을 간략하게 설명하는 JSON 설명자인
AgentCard를 통해. - 작업 송수신: 한 에이전트가 지원을 요청하고 다른 에이전트가 결과 또는 ‘아티팩트’로 응답하는 JSON-RPC를 활용한 구조화된 상호 작용을 통해.
- 서버 전송 이벤트 (SSE) 를 사용한 스트림 업데이트: 시간이 오래 걸리거나 협업적인 작업 중에 실시간 피드백을 용이하게 합니다.
- 풍부한 콘텐츠 교환: 간단한 텍스트 외에 파일, 구조화된 데이터 및 양식 교환을 지원합니다.
- 기본적으로 보안 유지: HTTPS, 인증 및 권한에 대한 기본 제공 지원을 통합합니다.
A2A의 강점은 기존 솔루션을 재창조하지 않는다는 점에 있습니다. HTTP 및 SMTP와 유사한 잘 정립된 웹 표준을 활용하여 더 쉽게 채택하고 더 빠르게 통합할 수 있습니다.
그러나 A2A는 전체 솔루션의 한 측면일 뿐입니다.
Anthropic의 Model Context Protocol (MCP): 도구 사용 및 컨텍스트 액세스 표준화
Anthropic의 MCP는 에이전트가 도구를 활용하고 컨텍스트 정보에 액세스하는 방법에 대한 중요한 측면을 다룹니다. MCP는 에이전트가 API를 호출하고, 함수를 호출하고, 외부 시스템과 통합하는 프로세스를 표준화하여 기본적으로 환경 내에서 작동하는 방식을 정의합니다. A2A가 에이전트 간 통신을 관리하는 반면 MCP는 에이전트가 외부 세계와 상호 작용하는 데 중점을 둡니다.
본질적으로:
- MCP는 개별 에이전트 지능을 강화합니다.
- A2A는 집단 지능을 가능하게 합니다.
HTTP 및 SMTP가 광범위한 성공을 거두기 위해 광범위한 채택, 인프라 및 개발자 도구가 필요했던 것과 유사하게 A2A 및 MCP는 잠재력을 완전히 실현하기 위해 강력한 생태계가 필요합니다.
A2A 및 MCP와 같은 표준화 노력에도 불구하고 중요한 질문이 남아 있습니다. 복잡하고 역동적인 엔터프라이즈 환경에서 에이전트 통신을 효과적으로 확장할 수 있는 방법은 무엇일까요? 이러한 프로토콜에 의해 정의된 직접적인 지점 간 연결에만 의존하면 확장성, 복원력 및 가시성과 관련된 문제가 발생합니다. 이는 강력한 기본 통신 인프라의 필요성을 강조합니다.
직원들이 직접 일대일 메시지를 통해서만 통신할 수 있는 회사를 생각해 보세요. 업데이트를 공유하려면 각 개인에게 별도로 메시지를 보내야 합니다. 여러 팀에 걸쳐 프로젝트를 조정하려면 각 그룹 간에 정보를 수동으로 릴레이해야 합니다.
이러한 시스템을 수백 명의 직원으로 확장하면 혼란이 발생합니다.
이 시나리오는 직접 연결을 기반으로 구축된 에이전트 생태계에서 직면하는 문제를 반영합니다. 각 에이전트는 연락할 에이전트, 연락 방법 및 가용성을 알아야 합니다. 에이전트 수가 증가함에 따라 필요한 연결 수가 기하급수적으로 증가하여 취약하고 관리하기 어렵고 확장할 수 없는 시스템이 됩니다.
A2A 및 MCP는 에이전트에게 통신 및 작업을 위한 언어와 구조를 제공합니다. 그러나 언어만으로는 충분하지 않습니다. 엔터프라이즈 전체에서 수많은 에이전트를 조정하려면 메시지 흐름과 에이전트 응답을 관리하는 인프라가 필요합니다.
Kafka 및 Flink: 확장 가능한 에이전트 협업을 위한 백본
Apache Kafka 및 Apache Flink는 이러한 중요한 인프라를 제공합니다.
Kafka 및 Flink 설명
원래 LinkedIn에서 개발되어 현재 Apache Software Foundation 프로젝트인 Apache Kafka는 분산 이벤트 스트리밍 플랫폼입니다. 내구성이 뛰어나고 처리량이 높은 메시지 버스로 기능하여 시스템이 실시간 이벤트 스트림을 게시하고 구독할 수 있습니다. Kafka는 생산자와 소비자를 분리하고 데이터 내구성, 재생 가능성 및 확장성을 보장하는 기능으로 인해 금융 시스템, 사기 탐지 및 원격 측정 파이프라인을 포함한 다양한 애플리케이션에서 널리 사용됩니다.
또 다른 Apache 프로젝트인 Flink는 상태 저장, 높은 처리량, 낮은 지연 시간의 이벤트 처리를 위해 설계된 실시간 스트림 처리 엔진입니다. Kafka가 데이터 이동을 관리하는 반면 Flink는 시스템을 통해 데이터가 흐를 때 데이터의 변환, 풍부화, 모니터링 및 오케스트레이션을 처리합니다.
Kafka와 Flink는 함께 강력한 조합을 형성합니다. Kafka는 혈류 역할을 하는 반면 Flink는 반사 시스템 역할을 합니다.
에이전트 세계의 HTTP로서 A2A의 역할과 유사하게 Kafka와 Flink는 확장 가능한 에이전트 통신 및 계산을 위한 이벤트 기반 기반을 제공하여 직접적인 지점 간 통신으로는 해결할 수 없는 문제를 해결합니다.
- 분리: Kafka를 사용하면 에이전트가 출력 소비자를 알 필요가 없습니다. 이벤트 (예:
"TaskCompleted","InsightGenerated") 를 토픽에 게시하여 관심 있는 에이전트 또는 시스템이 구독할 수 있습니다. - 가시성 및 재생 가능성: Kafka는 모든 이벤트의 내구성이 뛰어나고 시간 순서가 지정된 로그를 유지 관리하여 에이전트 동작이 완전히 추적 가능하고 감사 가능하며 재생 가능하도록 보장합니다.
- 실시간 의사 결정: Flink를 사용하면 에이전트가 동적 조건을 기반으로 필터링, 풍부화, 조인 또는 작업 트리거링과 같은 이벤트 스트림에 실시간으로 반응할 수 있습니다.
- 복원력 및 확장: Flink 작업은 독립적으로 확장하고, 오류에서 복구하고, 복잡한 다단계 작업을 수행하는 에이전트에 필수적인 장기 실행 워크플로에서 상태를 유지할 수 있습니다.
- 스트림 네이티브 조정: 동기 응답을 기다리는 대신 에이전트는 이벤트 스트림을 통해 업데이트를 게시하고, 워크플로를 구독하고, 공동으로 상태를 진행하여 조정할 수 있습니다.
요약하자면:
- A2A는 에이전트가 통신하는 방법을 정의합니다.
- MCP는 외부 도구와 상호 작용하는 방법을 정의합니다.
- Kafka는 메시지가 흐르는 방식을 정의합니다.
- Flink는 해당 흐름이 처리, 변환되고 의사 결정을 내리는 데 사용되는 방법을 정의합니다.
A2A 및 MCP와 같은 프로토콜은 에이전트 동작 및 통신을 표준화하는 데 중요합니다. 그러나 Kafka와 같은 이벤트 기반 하부 레이어와 Flink와 같은 스트림 네이티브 런타임이 없으면 에이전트는 고립되어 효과적으로 조정하고, 효율적으로 확장하거나, 시간에 따라 추론할 수 없습니다.
엔터프라이즈급 AI 에이전트를 위한 4계층 아키텍처
엔터프라이즈급, 상호 운용 가능한 AI 에이전트의 비전을 완전히 실현하려면 4계층 아키텍처가 필요합니다.
- 프로토콜: A2A, MCP – _무엇_을 정의합니다.
- 프레임워크: LangGraph, CrewAI, ADK – _방법_을 정의합니다.
- 메시징 인프라: Apache Kafka – _흐름_을 지원합니다.
- 실시간 계산: Apache Flink – _사고_를 지원합니다.
이러한 계층은 함께 지능적일 뿐만 아니라 협업적이고, 관찰 가능하며, 프로덕션 준비가 완료된 시스템을 구축하기 위한 토대를 제공하는 AI 에이전트를 위한 새로운 인터넷 스택을 형성합니다.
우리는 현재 소프트웨어 진화의 중요한 시점에 있습니다.
HTTP 및 SMTP와 같은 프로토콜과 TCP/IP와 같은 인프라로 구성된 원래 인터넷 스택이 전 세계 연결 시대를 열었던 것과 마찬가지로 AI 에이전트를 위한 새로운 스택이 등장하고 있습니다. 그러나 인간이 웹 페이지를 탐색하거나 이메일을 보내는 대신 이 스택은 추론, 결정 및 작업을 위해 협업하는 자율 시스템을 위해 설계되었습니다.
A2A 및 MCP는 에이전트 통신 및 도구 사용을 위한 프로토콜을 제공하는 반면 Kafka 및 Flink는 실시간 조정, 가시성 및 복원력을 위한 인프라를 제공합니다. 함께 연결되지 않은 에이전트 데모에서 확장 가능하고 지능적이며 프로덕션 등급의 생태계로 전환할 수 있습니다.
이러한 진화는 엔지니어링 문제를 해결하는 것만이 아닙니다. 이는 경계를 넘어 협업하고, 실시간으로 통찰력을 제공하고, 작업을 주도하여 지능이 분산 시스템이 되도록 하는 새로운 소프트웨어 패러다임을 가능하게 하는 것입니다.
그러나 이러한 비전에는 개방성, 상호 운용성을 강조하고 이전 인터넷 혁명에서 얻은 교훈을 활용하는 적극적인 개발이 필요합니다.
따라서 에이전트를 개발할 때는 더 넓은 시스템 내에서 통합을 고려하는 것이 중요합니다. 효과적으로 통신할 수 있나요? 다른 에이전트와 협업할 수 있나요? 변화하는 조건에 따라 진화하고 적응할 수 있나요?
미래는 에이전트 전원 공급만 있는 것이 아니라 에이전트 연결도 있습니다.