아키텍처

에이전틱 커머스 아키텍처: 하나의 MCP 기능 계층으로 네 가지 AI 채널을 지원하기

글쓴이: IdeaBosque최종 업데이트: 2026年10月3日

핵심 요점

네 가지 AI 접근 채널(자체 포털, OpenAI ACP, Meta Muse, 외부 A2A 에이전트)은 하나의 MCP 기능 계층을 공유할 수 있습니다. 동일한 커머스 로직을 네 번 따로 구현할 필요가 없습니다.
판단 규칙은 한 줄입니다. 외부 프로토콜이 MCP와 다를 때에만 프로토콜 어댑터를 추가합니다. OpenAI의 Agentic Commerce Protocol에는 ACP→MCP 어댑터가 필요하지만, 이미 MCP를 사용하는 커넥터에는 필요하지 않습니다.
Magento / Adobe Commerce는 계속 권위 있는 시스템 오브 레코드입니다. ACP, MCP, A2A는 가격, 재고, 세금, 주문 로직을 재현하지 않고 호출만 합니다.
쓰기 도구는 도구 경계에서 영향도에 따라 통제합니다. catalog.search_products 같은 읽기는 자유롭게 흐르지만, order.submit과 payment.authorize 같은 민감한 쓰기에는 사람의 승인과 멱등성이 필요합니다.

커머스 카탈로그를 ChatGPT, Meta Muse, 파트너 회사의 에이전트에 연결하면, 단순한 설계에서는 가격, 재고, 결제 로직을 플랫폼마다 한 번씩, 네 번 다시 구현하게 됩니다. 각 AI 접점은 서로 다른 프로토콜을 사용합니다. OpenAI는 Agentic Commerce Protocol(ACP, Stripe와 공동 개발)을 내놓았고, 에이전트는 Model Context Protocol(MCP)로 도구와 통신하며, 에이전트끼리는 A2A로 작업을 위임합니다. 플랫폼마다 연동 스택을 하나씩 만드는 것이 반사적인 대응이지만, 바로 그 반사가 값비싼 실수입니다.

이 글은 에이전틱 커머스를 위한 공급자 중립적 아키텍처를 제시합니다. 사우스바운드에는 엔터프라이즈 MCP 기능 계층 하나, 노스바운드에는 여러 AI 접근 채널을 두는 구조입니다. 커머스 시스템 오브 레코드의 실제 사례로 Magento / Adobe Commerce를 사용하지만, 이 패턴은 어떤 ERP, OMS, 카탈로그에도 적용됩니다. 핵심 결과는 하나의 판단 규칙, 즉 외부 플랫폼의 프로토콜을 MCP로 변환해야 할 때에만 어댑터를 추가한다는 것입니다. 이 규칙은 연동 코드가 어디에 있어야 하는지, 그리고 더 유용하게는 어디에 있지 않아야 하는지를 정확히 알려 줍니다.

함정: 네 개의 플랫폼, 네 번의 재구현

모든 AI 커머스 접점이 원하는 기본 작업은 같습니다. 카탈로그 검색, 재고 확인, 가격 조회, 장바구니 구성, 주문 제출입니다. 단순한 아키텍처에서는 각 접점을 자체 로직으로 커머스 플랫폼에 직접 연결합니다.

자체 웹사이트 → 맞춤 Magento 호출
OpenAI / ChatGPT → 또 다른 Magento 호출
Meta Muse → 다시 또 다른 Magento 호출
파트너 에이전트 → 또 하나의 별도 세트

이렇게 되면 가격 규칙 변경, 새로운 과세 관할 추가, 재고 예약 수정이 있을 때마다 네 곳에서 수정하고 테스트해야 합니다. 비즈니스 로직이 복사되었고, 복사본은 서로 어긋나기 마련입니다. 이는 어떤 규모에서든 지점 간 연동의 비용을 높이는 커넥터 난립과 같은 문제가, SaaS 엔드포인트가 아닌 AI 채널에서 나타난 것일 뿐입니다.

해법은 네 개의 사우스바운드 구현을 하나로 합치는 것입니다. 모든 채널은 동일한 엔터프라이즈 기능 계층에 도달합니다. 이 계층은 MCP로 노출되고, 표준 커머스 서비스가 뒷받침하며, 최종적으로 상품, 가격, 재고, 장바구니, 세금, 주문의 유일한 신뢰 원천인 Magento로 이어집니다. 커머스 로직은 계속 Magento가 소유하고, AI 채널은 그것을 호출할 뿐입니다.

판단 규칙: 프로토콜이 불일치할 때만 어댑터

아키텍처 관점에서 의미 있는 채널 간 차이는 정확히 하나, 어떤 프로토콜을 사용하는가입니다. 이 한 가지 사실이 채널에 변환 어댑터가 필요한지, MCP에 바로 연결할 수 있는지를 결정합니다. 세 프로토콜은 경쟁 관계가 아니며, 각기 다른 질문에 답합니다.

기술	정의	답하는 질문
HTTP / REST / JSON	전송, API 스타일, 데이터 형식	바이트가 어떻게 이동하는가
ACP	AI 커머스 상호운용성(OpenAI + Stripe)	AI 커머스 플랫폼과 판매자가 어떻게 거래하는가
MCP	에이전트/앱과 도구 간 상호운용성	에이전트나 애플리케이션이 어떤 도구를 호출할 수 있는가
A2A	에이전트 간 상호운용성	한 에이전트가 다른 에이전트에게 작업을 어떻게 위임하는가

ACP와 MCP는 서로 다른 문제를 해결하므로 ACP 어댑터는 실제로 필요합니다. ACP의 커머스 의미 체계(체크아웃 세션, 주문 상태, 피드 형식)를 MCP 도구 호출로 변환합니다. A2A 역시 별개입니다. 외부 에이전트가 A2A로 작업을 위임하면 게이트웨이가 이를 Agent Core로 라우팅하고, Agent Core가 MCP를 호출합니다. 반면 커넥터 모델이 이미 MCP를 사용하는 플랫폼에는 어댑터가 전혀 필요하지 않습니다. 기능 계층에 바로 도달합니다.

여기가 통념과 반대되는 부분입니다. 직관은 "새로운 AI 플랫폼에는 새로운 어댑터"이지만, 이 규칙은 반대로 말합니다. 플랫폼의 프로토콜이 MCP가 아닐 때에만 어댑터를 만듭니다. 그러면 네 채널은 네 개의 연동이 아니라 네 개의 접근 경로로 정리됩니다.

자체 포털 → Agent Core → MCP
OpenAI / ChatGPT → ACP → ACP 어댑터 → MCP
Meta Muse → Muse 커넥터 → MCP (어댑터 없음. 커넥터가 MCP를 사용하기 때문)
외부 에이전트 → A2A → A2A 게이트웨이 → Agent Core → MCP

모든 것이 MCP에서 수렴합니다. 이 수렴이 설계의 전부입니다.

아키텍처를 한눈에 보면 다음과 같습니다.

MCP 커머스 서버는 재사용 가능한 경계다

기능 계층은 작고 안정적인 커머스 도구 집합, 즉 catalog.search_products, pricing.get_price, inventory.check, cart.create, cart.add_item, order.submit, order.get_status를 노출하는 MCP 서버입니다. 모든 채널이 같은 도구를 사용합니다. 자체 포털의 Agent Core, ACP 어댑터, Muse 커넥터, A2A로 들어오는 외부 에이전트 모두 catalog.search_products를 호출하며, 각자 상품 검색을 구현하지 않습니다.

중요한 점은 MCP가 기능 인터페이스이지 비즈니스 데이터 모델이 아니라는 것입니다. 도구 뒤에는 Product, Variant, Price, Inventory, Cart, Order로 이루어진 프로토콜 독립적 모델인 표준 커머스 서비스와, 그 표준 모델을 Adobe Commerce의 API에 매핑하는 Magento 어댑터가 있습니다. OpenAI의 상품 피드 형식이나 ACP의 체크아웃 스키마가 바뀌면 ACP 어댑터만 바뀝니다. Magento의 API가 바뀌면 Magento 어댑터만 바뀝니다. 중간의 도구는 안정적으로 유지됩니다. 이는 거버넌스가 적용된 MCP 모듈과 같은 구조적 규율, 즉 타입이 지정된 도구, 안정적인 계약, 가장자리에 격리된 벤더 고유의 특성과 같습니다.

도구는 영향도로 분류되며, 거버넌스는 이 분류에 있습니다. 읽기(catalog.search, pricing.get, inventory.check)는 위험이 낮아 자유롭게 흐릅니다. 쓰기(cart.add_item)는 상태를 바꾸지만 되돌릴 수 있습니다. 민감한 쓰기(order.submit, payment.authorize, refund.create)는 돈을 움직이거나 의무를 발생시키므로 사람의 승인, 중복 주문을 막는 멱등성 키, 감사 로그가 필요하며, 어느 채널이 호출했는지와 무관하게 도구 경계에서 강제됩니다. 커넥터 자체의 거버넌스 계층(인증, 사용자 권한, 사람의 승인 게이트)은 MCP 서버를 대체하는 것이 아니라 그 앞에 놓입니다.

Meta Muse에는 어댑터가 필요 없고 ACP에는 필요한 이유

판단 규칙을 가장 선명하게 보여 주는 것은 두 외부 AI 플랫폼의 대비입니다. OpenAI의 ACP와 MCP는 서로 다른 프로토콜이므로, ACP 경로에는 ACP 커머스 의미 체계를 MCP 도구 호출로 변환하는 어댑터가 있습니다. 반면 연동을 MCP 엔드포인트로 제출하는 커넥터 모델은 기능 계층을 직접 사용합니다. 거버넌스 경계는 커넥터의 심사와 권한 모델이지만, 구축하고 유지해야 할 두 번째 변환 계층은 없습니다. "Muse는 다른 플랫폼이니까"라는 이유로 어댑터를 추가하면 기능 없는 연동 부채만 늘어납니다.

같은 점검이 앞으로의 모든 AI 접점에도 적용됩니다. 질문은 하나입니다. 이 플랫폼이 MCP를 직접 사용할 수 있는가? 그렇다면 기존 서버에 연결해 모든 도구를 재사용합니다. 그렇지 않다면 프로토콜 어댑터를 정확히 하나만 추가하고, 그 외에는 아무것도 더하지 않습니다. 이렇게 해야 네 개의 채널(그리고 다섯 번째, 여섯 번째)이 계속 저렴하게 유지됩니다.

커머스를 넘어: 같은 계층이 엔터프라이즈 에이전트 플랫폼이 된다

커머스는 MCP 도메인 중 하나일 뿐입니다. 같은 Agent Core가 커머스 MCP 서버, CRM MCP 서버, ERP MCP 서버를 호출하여 "이 고객의 이전 구매와 호환되는 상품 중 500달러 이하이고 재고가 있는 것을 찾아 추천안을 준비하라" 같은 요청을 커머스와 CRM에 걸친 하나의 계획으로 구성할 수 있습니다. 외부 위임에는 A2A를 사용합니다. A2A는 첫 해에 150개 이상의 조직으로 확산되었고, 파트너 회사의 구매 에이전트가 귀사의 영업 에이전트에게 위임하고 그 에이전트가 MCP 계층을 호출하도록 하되, 파트너에게 내부 시스템에 대한 직접 접근 권한을 주지 않을 수 있게 합니다. 커머스 아키텍처와 더 넓은 MCP + A2A 엔터프라이즈 스택은 범위만 다른 동일한 아키텍처입니다.

대표적인 구축 사례

Adobe Commerce를 사용하는 중견 판매자가 플랫폼 팀 없이 ChatGPT와 Meta Muse 안에서 판매하기를 원했습니다. 저희는 먼저 표준 커머스 서비스와 Magento 어댑터를 구축하고, 여섯 개의 MCP 커머스 도구를 노출한 뒤, 자체 포털의 Agent Core를 그 위에 올렸습니다. 다음은 OpenAI였습니다. ACP 어댑터와 상품 피드 변환기를 추가했으며, 그 아래에서는 동일한 도구를 그대로 재사용했습니다. Meta Muse는 가장 저렴한 채널이었습니다. 기존 MCP 커머스 서버를 문서화(엔드포인트, 인증, 도구, 읽기/쓰기 분류, 민감한 쓰기의 승인)하여 커넥터 심사에 제출했을 뿐, 전용 어댑터는 작성하지 않았습니다. 기능 계층은 하나였고, 새 채널은 재구축이 아니라 접근 경로 추가였습니다.