AI가 엔터프라이즈 아키텍처의 미래를 다시 쓰고 있다. 이는 단순히 프롬프트 하나를 입력하고 답변을 기다리는 방식의 AI가 아니다. 다음 물결은 에이전틱(agentic) AI다. 분산된 자율 프로세스로 구성되는 에이전틱 AI는 기업 환경 전반에서 스스로 인식하고 추론하고 행동한다.

MCP(Model Context Protocol)와 A2A(Agent2Agent) 같은 새로운 프로토콜은 AI 에이전트가 기업 시스템은 물론 다른 에이전트와도 자율적으로 탐색하고 상호작용하는 방식을 표준화할 것으로 기대를 모은다. 그러나 프로토콜은 어디까지나 출발점일 뿐이다. 본격적인 에이전틱 AI 시대에 대비하려면, 데이터와 애플리케이션 인프라를 어떻게 준비할지에 대한 고민이 뒤따라야 한다.

이런 흐름은 낯설지 않다. 약 10년 전, 기업은 대규모 애플리케이션을 클라우드에 맞게 현대화하는 문제와 씨름했다. 모놀리식 구조에서 API 기반 마이크로서비스로의 전환은 분명 혁신을 약속했지만, 동시에 혼란도 불러왔다. 무엇이 진정한 ‘마이크로’ 서비스인지 논란이 있었고, 조정과 오케스트레이션 패턴도 명확하지 않았다.

그렇다면 마이크로서비스 전환 과정에서 얻은 교훈은 무엇이며, 이를 어떻게 활용하면 다가오는 에이전틱 AI의 물결에 대비할 수 있을까? 이를 답하기 위해서는 먼저 현재 우리가 어디에 서있는지부터 살펴봐야 한다.

에이전틱 아키텍처 여정의 위치는 현재 어디인가?

에이전틱 AI는 아직 초기 단계에 있다. 대부분 기업은 이제 막 이를 탐색하고 실험하는 단계에 있으며, 일부는 에이전트 간 통신이 어떤 가능성을 열 수 있는지 이해하기 시작하는 수준이다. 또 다른 기업은 AI 모델과 엔터프라이즈 시스템을 연결하는 교두보를 구축하는 단계에 들어섰다.

MCP와 A2A 가운데 현재 더 널리 채택되는 표준은 MCP다. MCP는 ‘엔터프라이즈 데이터 접근을 위한 USB-C’에 비유되며, 개방적이고 실용적이라는 점에서 이미 수백 개 기업과 기술 제공업체가 초기 도입을 시작했다. 반면 A2A는 더 야심 차지만 아직 성숙하지 못한 단계다. MCP가 주로 에이전트-시스템 통합에 초점을 맞춘다면, A2A는 훨씬 더 어려운 과제인 자율 에이전트 간 연동 문제를 다룬다.

그러나 초기 도입 기업이 발견한 한계가 있다. 두 프로토콜 모두 태생적으로 상태를 저장하지 않는 스테이트리스(stateless) 구조라는 점이다. 한 에이전트가 메시지를 주고받으면 그 상호작용은 사라지고, 속적인 메모리·기록·이력(lineage)은 남지 않는다. 실험 단계에서는 괜찮지만, 실제 운영 환경에서 멀티 에이전트 워크플로를 실행하려 하면 문제가 드러난다. 예를 들어 재무 계획 에이전트가 위험 평가 에이전트와 컴플라이언스 에이전트와 연동되는 멀티 에이전트 시스템을 생각해보자. 새로운 에이전트 버전을 테스트하거나, 의사결정을 감사하거나, 문제를 해결하려고 하면 곧바로 벽에 부딪히게 된다.

커뮤니티는 과거 마이크로서비스가 본격적으로 확산되기 전, 이런 트랜잭션 기록 부재 문제를 먼저 해결해야 했다. 스테이트리스 서비스는 확장성이 뛰어나고 관리하기 간단하지만, 결국 메모리·히스토리·연동의 부담을 외부 시스템에 떠넘기게 된다. 이는 복잡하고 분산된 환경에서 병목이나 결함을 초래했다. 현재의 에이전틱 AI 시스템도 같은 도전에 직면해 있다. 상호작용 과정에서 맥락을 유지할 능력이 부족하기 때문에 대규모 엔터프라이즈 환경에서는 취약하고 연동하기 어려운 구조가 되고 만다.

데이터 인프라를 1급 참여자로 만들어라

에이전틱 아키텍처를 실제 운영 환경에서 구현하는 문제는 단순히 프로토콜의 문제가 아니라, 데이터 아키텍처의 문제다. 에이전트는 정적인 프롬프트만 소비하는 존재가 아니다. 환경에 반응하며 스스로 의사결정을 내리는 자율적 주체다. 이는 곧 데이터 인프라가 단순한 배치 처리나 정적 쿼리를 넘어서 비즈니스 환경에 의해 실시간으로 영향을 받는 의사결정을 지원할 수 있어야 함을 의미한다.

예를 들어 한 전자상거래 기업이 재고 관리, 고객 서비스, 부정 행위 탐지용 에이전트를 각각 운영한다고 해보자. 이들 에이전트는 맥락을 공유할 수 있어야 한다. 재고 관리 에이전트가 비정상적인 수요 패턴을 감지하면, 부정 행위 탐지 에이전트가 즉시 이를 알아야 한다. 고객 서비스가 불만을 해결하면, 재고 관리와 부정 행위 탐지 에이전트 모두 그 맥락을 향후 의사결정에 반영할 수 있어야 한다. 이런 상태를 공유할 수 없다면 모든 상호작용은 매번 처음부터 다시 시작해야 한다.

“에이전트는 가드레일 없는 마이크로서비스다(agents are microservices without guardrails)”라는 표현을 들어본 적이 있을 것이다. 바로 이 때문에 이벤트 기반 설계(event-driven design)가 필수 요소로 자리 잡았다. 이벤트 기반 설계 덕분에 마이크로서비스는 취약하고 경직된 포인트 투 포인트 아키텍처를 넘어설 수 있었다. 스태이트리스 API는 결국 이벤트 스트리밍으로 대체됐다. 개발자는 과거의 상호작용을 다시 살펴보고 인과관계를 추적하고 시간과 맥락을 기반으로 추론해야 했기 때문이다.

아파치 카프카(Apache Kafka)는 이런 전환을 현실로 만든 기술이었다. 카프카는 마이크로서비스에 상태 관리, 관찰가능성, 디커플링(decoupling)을 제공해 신뢰할 수 있는 확장을 가능하게 했다. 각 메시지는 더 이상 API를 통해 전달되는 것이 아니라, 카프카 기반 이벤트 스트림을 통해 전송된다.

이 패턴을 현대적인 에이전트 설계에 적용하면, MCP 호출, A2A 메시지, 그리고 생성되는 부수 효과가 모두 카프카 로그 상의 이벤트로 조율된다. 이렇게 남겨진 기록은 문제 해결을 위한 점검, 정책 준수를 위한 감사, 혹은 서비스 개선 과정에서의 재실행에 활용할 수 있다.

카프카 토픽(Kafka topics)은 에이전트에 공유 메모리 공간을 제공한다. 이를 통해 에이전트는 이벤트에 반응하고, 관찰 내용을 공유하며, 의사결정을 내릴 수 있다. 카프카는 MCP나 A2A 같은 스테이트리스 프로토콜에 필요한 지속적이고 반응적인 기반을 제공한다. 즉, 이 인프라가 MCP나 A2A가 스스로는 제공하지 못하는 ‘메모리 계층’ 역할을 수행하게 된다.

성공하는 구현 패턴과 실패하는 패턴

기업이 본격적으로 MCP와 A2A 도입을 추진하면서 이미 익숙한 패턴이 다시 등장하고 있다. 지금까지 얻은 2가지 핵심 교훈은 다음과 같다.

• 프로토콜 우선 접근의 함정 : 대표적인 실수는 데이터 아키텍처를 고려하지 않은 채 MCP나 A2A 통합부터 시작하는 것이다. 이런 접근은 에이전트가 개별적으로는 동작하지만, 상호작용 과정에서 맥락을 기억하거나 협력해야 할 때 실패하는 결과로 이어지곤 한다.
• 빅뱅 접근방식의 위험 : 또 다른 실수는 실질적인 문제 해결 없이 대규모 에이전틱 플랫폼을 구축하려는 것이다. 이런 방식은 진행 속도를 늦추고 비용을 높이며, 성과가 빨리 나타나지 않으면 조직 내에서 회의론이 커질 수 있다.

성공적인 접근법은 에이전트가 안정적으로 소통하고 상호작용 속에서 상태(state)를 유지할 수 있도록 하는 기반 시스템에 집중하는 것이다. 마이크로서비스 초창기에는 단순한 API를 넘어 카프카 같은 도구를 도입하는 방식이 바로 그것이었다. 이런 플랫폼은 서비스가 서로 통신하고 상태를 공유하며, 독립적으로 동작하면서도 동기화를 유지할 수 있도록 이벤트 스트리밍(event streaming)을 도입했다.

오늘날 성공적인 MCP와 A2A 구현도 바로 이와 같은 패턴을 따른다. 구체적으로 다음과 같다.

• 인프라부터 시작하라 : MCP나 A2A 프로토콜을 도입하기 전에 데이터를 발견 가능하고 신뢰할 수 있는 자산으로 다룰 수 있는 기반 데이터 계층을 마련해야 한다. 이를 통해 에이전트는 맥락을 저장·조회하고, 의사결정을 로그로 남겨 감사 추적에 활용하며, 강한 결합 없이도 협력할 수 있다. 실제 엔터프라이즈 현장에서는 카프카와 같은 데이터 스트리밍 기술이 강력한 해법이 된다.
• 상태 관리를 점진적으로 구현하라 : 데이터 접근을 위한 단순한 MCP 통합부터 시작하고, 이벤트 인프라가 성숙해짐에 따라 점진적으로 A2A 연동을 추가하는 것이 좋다. 각 에이전트의 상호작용은 반드시 이벤트를 생성해야 하며, 다른 에이전트가 이를 소비하고 반응할 수 있어야 한다.

모델 성능보다 데이터 준비에 투자하라

대부분 경우 우수한 데이터와 범용 모델(off-the-shelf model) 조합이 훌륭한 모델과 부족한 데이터 조합보다 더 나은 성과를 낸다. 이 원칙은 MCP와 A2A를 실제 운영 환경에 구현할 때 더욱 중요해진다. 실시간 맥락의 품질과 가용성이 에이전트가 얼마나 잘 추론하고 행동할 수 있는지를 결정하기 때문이다.

실제 현장에서 이것이 의미하는 바는 명확하다. MCP 구현에서 어떤 LLM을 선택하느냐는 데이터 품질만큼 중요하지 않다. 아무리 뛰어난 모델이라도 낡거나 불완전한 데이터에 기반한다면 잘못된 의사결정을 내리게 된다.

마이크로서비스 시대는 단순함을 잃기 쉽다는 교훈을 남겼다. 많은 팀이 시스템을 지나치게 복잡하게 만들어 결국 ‘마이크로리스(microlith)’가 되었고, 서비스 간 통신은 과도하게 늘어났으며, 명확한 소유권이 부재해 데이터 일관성도 무너졌다. 현재 초기 단계의 에이전틱 구현에서도 같은 위험이 드러나고 있다. 특히 연동, 메모리, 제어 흐름이 사후적으로 다뤄질 때 이런 문제가 두드러진다.

결론적으로 직접 파운데이션 모델을 구축할 필요는 없다. 하지만 선택한 에이전트와 모델이 활용할 수 있도록 고품질의 맥락화된 신뢰할 수 있는 데이터를 제공하는 아키텍처는 반드시 필요하다. 특히 MCP와 A2A 구현에서는 이벤트 스트리밍 인프라가 핵심 역할을 한다. 이를 통해 실시간 에이전트 간 연동, 지속적인 맥락 저장, 자율 시스템 간 안정적인 메시지 전달을 처리할 수 있다.

그 기반은 지금부터 구축해야 한다. 앞으로의 에이전틱 AI 구현은 그 토대에 달려 있다.

*Andrew Sellers는 컨플루언트(Confluent)에서 기술 전략 그룹을 이끌고 있다
dl-itworldkorea@foundryco.com