AI 에이전트는 아직 결제할 수 없습니다. 그것이 바로 당신이 2026년에 준비를 갖춰야 하는 이유입니다.

2026년 3월, OpenAI는 Instant Checkout의 전원을 꺼버렸습니다. 실제로 연결된 Shopify 판매자는 30명도 채 되지 않았고, 재고 관리도, 판매세(sales tax) 처리도 없었습니다. 시작과 동시에 실패한 것이었습니다. 그리고 모든 이들은 이를 AI 에이전트를 통한 구매가 실체가 없는 환상(vapor)이라는 증거로 읽었습니다. 잘못된 신호입니다. 요약하자면(TLDR): 에이전트 결제는 아직 작동하지 않습니다. 모두가 이를 실패로 읽지만, 그것은 잘못된 신호입니다. 에이전트 기반의 탐색(discovery)은 이미 15배나 급증했습니다. 저는 올해 2개의 MCP 서버를 구축했고, 그 과정은 에이전트에게 물건을 팔고자 하는 이들을 기다리고 있는 것이 무엇인지 보여주었습니다. 첫 결제 단계에서 결제가 깨지는 것은 모순이 아닙니다. 그것은 기술의 아주 초기 단계임을 나타내는 특징입니다. 일부는 이미 활발히 작동하고 있습니다. 나머지는 임시방편(tape)으로 간신히 유지되고 있을 뿐입니다. 우리는 이 영화를 전에 본 적이 있습니다. 1996년에도 웹은 절반은 망가져 있었지만, 어쨌든 모든 것을 바꾸어 놓았습니다.

1996년에도 당신의 웹사이트는 제대로 작동하지 않았습니다. 1996년에는 웹이 작동하지 않았습니다. 저는 문자 그대로 그 말을 하는 것입니다. 페이지는 한 번에 한 줄의 픽셀씩 로드되었고, 집 안의 다른 누군가가 전화를 들면 연결이 끊겼습니다. 사이트의 절반은 오늘날 보면 눈물이 날 정도로 HTML로 수작업으로 만들어졌고, 나머지 절반은 Dreamweaver로 만든 협박 편지 같은 모습이었습니다. 온라인으로 무언가를 결제하는 것은, 마치 낯선 사람에게 지갑을 우편으로 돌려주겠다고 약속하며 건네주는 것처럼 무모하게 느껴졌습니다. 상황은 나빴습니다. 하지만 그것은 이미 선택이 아닌 필수였습니다. 그 난장판을 보고 "정말로 제대로 작동할 때 나를 불러줘"라고 말했던 기업들은 그 난장판에 대해서는 틀리지 않았습니다. 하지만 그 난장판이 무엇을 의미하는지에 대해서는 틀렸습니다. 그래서 그들은 기다렸습니다. 그들은 고객들이 아직 온라인에 있지 않으며, 기술이 준비되지 않았고, 진짜 버전은 몇 년 뒤에나 나올 것이라고 스스로에게 말했습니다. 그 증거는 2005년경에 다른 모든 이들의 이커머스(e-commerce) 스토어의 모습을 하고 나타나 그들의 시장을 잠식했고, 그때 그들은 이미 10년 뒤처져 있었으며 기본 수준을 따라잡기 위해 대행사(agencies)에 엄청난 돈을 지불해야 했습니다. 우리는 지금 정확히 그 지점에 서 있습니다.

웹사이트를 에이전트 기반 커머스 (agentic commerce)로 교체하려 해도 상황은 마찬가지입니다. 보기 흉하고, 절반만 작동하며, 더 잘 알아야 할 똑똑한 사람들이 이것이 진지할 수 없다고 말합니다.

모두가 잘못된 신호를 읽고 있습니다. 에이전트 기반 커머스 (agentic commerce)를 두고 논쟁하는 두 진영이 있는데, 두 진영 모두 잘못된 계기판을 보고 있습니다. 회의론자들은 인스턴트 체크아웃 (Instant Checkout)을 지목하며 사망 선고를 내립니다. 그들이 말하는 사실 자체가 틀린 것은 아닙니다. OpenAI는 2026년 3월에 이를 중단했으며, 당시 실제로 작동 중이었던 Shopify 판매자는 약 30명에 불과했고, 실제 재고 관리나 판매세 (sales tax) 로직도 없었습니다. eBay는 제3자 구매 대행 에이전트 (buy-for-me agents)를 전면 금지했습니다. 설문조사에 따르면 쇼핑객의 약 17%만이 AI가 실제로 구매를 완료하도록 허용하는 것에 편안함을 느낍니다. 만약 이것이 전체 그림이라면, 물론, 그대로 묻어버려도 좋습니다.

낙관론 진영은 그 반대의 모습을 보입니다. 그들은 조 단위의 숫자가 인쇄된 분석가들의 보고서 (analyst decks)를 흔들며 마치 미래가 이미 배송된 것처럼 행동합니다. 두 진영 모두 체크아웃 (checkout) 단계만을 응시하고 있습니다. 신호는 체크아웃에 있지 않습니다. 신호는 탐색 (discovery) 단계에 있으며, 탐색은 슬라이드에 담긴 예측치가 아니라 이미 대시보드 위에 나타나 있습니다. Shopify는 2025년 1월 이후 AI 검색을 통해 들어오는 주문이 15배 급증했다고 밝혔습니다. Adobe는 미국 소매업으로 향하는 생성형 AI (generative-AI) 트래픽이 전년 대비 4700% 증가했음을 기록했습니다. 이것은 당신이 믿어야만 하는 예측이 아닙니다. 이것은 쇼핑객들이 이미 AI 내부에서 구매를 시작한 다음, 어딘가에서 완료하고 있다는 사실입니다. 퍼널 (funnel)의 앞부분이 이동했습니다. 그것은 이미 작년에 이동했습니다.

두 진영이 모두 간과하는 점은 간단합니다. 무언가가 고장 났다고 해서 그것이 나쁜 아이디어인 것은 아닙니다. 인스턴트 체크아웃 (Instant Checkout)이 실패한 이유는 에이전트가 물건을 사는 것이 멍청한 개념이기 때문이 아닙니다. 그것을 뒷받침할 배관 (plumbing)이 구축되지 않았기 때문에 실패한 것입니다. Forrester는 이를 명확하게 표현했습니다. 병목 현상이 결제 (payments)에서 제품 데이터 (product data)로 이동했다는 것입니다. 동일한 중단 사태를 바라본 The Drum은 이를 개념적 실패가 아닌 실행의 실패 (execution failure)라고 불렀습니다. 심지어 Google과 OpenAI에서 실제로 이를 구축하고 있는 사람들과 대화한 Fast Company조차, (상용화까지는) 년 단위가 아닌 월 단위의 시간이 걸릴 것이라고 답했습니다.

따라서 "망가졌다"는 말은 "지금이 바로 그 순간이다"의 반대말이 아닙니다. 그것은 같은 관찰을 두 번 말한 것과 같습니다. 이제 이 주제가 마땅히 치러야 할 정직성 비용 (honesty tax)을 말씀드리겠습니다. 저는 현재 2개의 MCP 서버를 운영하고 있으며, 두 서버 모두 내부 도구, 즉 가맹점 측 (merchant-side) 유형입니다. 이 서버들은 제가 저만의 에이전트 (agent)를 통해 저의 백오피스 (back office)를 직접 제어할 수 있게 해줍니다. 하지만 둘 중 어느 것도 낯선 사람의 쇼핑 에이전트가 들어와서 물건을 구매할 수 있는 storefront (상점 인터페이스)는 아닙니다. 따라서 저는 에이전트 커머스 (agentic-commerce)의 골드러시 내부에서 이 이야기를 하는 것이 아닙니다. 저는 그곳으로 이어지는 구축 경로 (build path)에서 이 이야기를 하고 있습니다. 제가 이 이야기를 할 가치가 있는 유일한 이유는, 그 구축 경로가 에이전트에게 물건을 팔고자 하는 이들에게 무엇이 닥칠 것인지를 이미 구체적인 세부 사항으로 보여주었기 때문입니다. 이것이 이 글이 존재하는 유일한 이유이며, 제가 작동하는 에이전트 storefront를 가지고 있지 않음에도 불구하고 있는 척하지 않는 이유이기도 합니다.

에이전트는 마케팅이 아닌 구조를 읽습니다. 잠시 다른 모든 것을 걷어내 봅시다. AI 에이전트가 당신의 비즈니스에 도달했을 때, 그것은 실제로 무엇을 인지할까요? 에이전트는 당신의 랜딩 페이지 (landing page)를 보지 않습니다. 40번이나 A/B 테스트를 거친 헤드라인이나, 브랜드 색상, 고객 후기 캐러셀 (testimonial carousel), 또는 소개 페이지의 창업자 사진을 보지 않습니다. 에이전트는 마케팅을 읽지 않습니다. 에이전트는 구조 (structure)를 읽습니다. 에이전트는 엔드포인트 (endpoint)에 접속하여 깨끗한 기계 판독 가능 데이터 (machine-readable data)를 받거나, 혹은 사용할 수 있는 것이 아무것도 받지 못합니다. 이것이 전체 메커니즘이며, 이 사실은 문제 전체를 재정의합니다. 에이전트 커머스에 대비하는 것은 마케팅의 문제가 아니라 배관 (plumbing)의 문제입니다. 핵심 작업은 기계가 읽을 수 있는 형태로 데이터를 노출하는 것입니다. 당신의 아름다운 제품 페이지는 인간을 위해 아름답게 유지될 수 있습니다. 에이전트에게는 엔드포인트 뒤에 구조화된 데이터 (structured data)로 존재하는 동일한 사실들(가격, 옵션, 재고 수량, 배송 규칙)이 필요합니다. 만약 그 엔드포인트가 존재하지 않는다면, 에이전트가 최종 후보 명단 (shortlist)을 작성할 때 당신은 그 자리에 아예 없는 것이나 마찬가지입니다. 구축 이야기와 두 가지 경로를 포함한 이 글의 나머지 모든 내용은 바로 그 지점에서 비롯되었습니다. 여기에는 두 가지 유형이 있으며, 이 둘은 혼동하기 쉽습니다.

Consumer-side MCP는 다른 누군가의 쇼핑 에이전트(shopping agent)가 외부에서 당신의 스토어 범위 내에 있는 카탈로그를 호출하는 경우를 의미합니다. Merchant-side MCP는 운영자인 당신이 당신만의 에이전트를 통해 자신의 비즈니스를 직접 구동하는 경우입니다. 저는 Merchant-side 유형을 구축했습니다. Consumer-side 유형은 골드러시(gold rush)가 뒤따르는 유형이며, 여전히 대부분 비어 있는 부동산과 같습니다. 또한 알아둘 가치가 있는 점은, MCP는 발견(discovery) 및 도구 호출(tool-calling) 레이어(layer)로서 에이전트가 당신을 찾아내고 당신의 정보를 읽을 수 있게 해주는 부분이라는 것입니다. 실제 결제 핸드셰이크(payment handshake)는 그 위에 쌓인 다른 프로토콜들을 통해 이루어지며, 그 레이어는 진정으로 여전히 주도권 다툼이 벌어지고 있는 영역입니다. 이제, 일반 독자들은 제가 모순되는 말을 하고 있다고 느낄 수도 있습니다. 제 가장 많이 읽힌 글에서는 당신 자신의 에이전트 도구(tooling)를 연결하기 위해서는 MCP를 건너뛰고 대신 일반적인 CLI(Command Line Interface)를 사용해야 한다고 주장했습니다. 그런데 지금 저는 MCP가 핵심이라고 말하고 있습니다. 두 가지 모두 사실입니다. 왜냐하면 이들은 서로 다른 질문에 답하고 있기 때문입니다. 당신의 에이전트가 당신을 위해 일을 수행하는 것은, 외부 세계의 에이전트들이 당신을 찾아내고 읽는 것과는 다른 문제입니다. 내부적인 작업이 왜 반대의 방향으로 가야 하는지에 대한 긴 버전을 원하신다면, 저는 MCP보다 CLI를 선호하는 이유에 대해 전체 논거를 정리해 두었습니다. storefront(매장 전면) 작업의 경우, 지루하고 구조화된 방식이 승리합니다.

나의 MCP 서버를 만드는 데 실제로 시간이 얼마나 걸렸나

모호한 손짓(vague hand-waving)은 하이프 캠프(hype camp)의 전형적인 수법이기에, 저는 차라리 '테이프로 겨우 붙여놓은 듯한(held together with tape)' 구체적인 모습을 보여드리고자 합니다. 올해 2월 25일. 저는 저만의 MCP 서버를 온라인에 올리고 있습니다. 스택은 Next.js와 Convex이며, Vercel에 배포되었습니다. 서류상으로는 1시간짜리 작업입니다. 하지만 1시간짜리 작업이 아니었습니다. 우선, 서버리스(serverless) 문제입니다. Vercel 함수는 상태가 없고(stateless) 수명이 짧기 때문에, 세션이 유지된다고 가정하고 작성했던 모든 코드를 뜯어내어 상태가 없는(stateless) 방식으로 다시 구축해야 했습니다. 그다음으로는 동적 경로(dynamic route)가 Vercel에서 그냥 깨져버렸습니다. 첫 번째 요청은 괜찮았지만, 그 이후의 모든 요청은 깔끔한 404 에러가 발생했습니다. 이는 자신의 로컬 환경에서는 완벽하게 작동하기 때문에 디버깅하기 아주 재미있는(골치 아픈) 유형입니다. 그다음은 커넥터(connector) 자체였습니다.

저는 curl에서는 아주 잘 작동하던 커스텀 Bearer 토큰 인증을 사용하고 있었는데, Claude.ai 커넥터는 이를 단호하게 인식하기를 거부했습니다. 그래서 저는 OAuth 2.1을 처음부터 직접 구축해야 했습니다. 셀프 호스팅(Self-hosted) 방식의 서명된 JWTs (JSON Web Tokens)를 사용했고, 데이터베이스는 추가하지 않았습니다. 단일 사용자 도구를 위한 세션 유지를 위해 데이터베이스를 추가하는 것은 그 자체로 일종의 광기이기 때문입니다. 작업 중간에 JWT 라이브러리인 jose가 Vercel의 번들러(bundler)를 충돌시켰습니다. 빌드 자체를 거부해 버린 것입니다. (Vercel의 로그도 jose를 지목하지 않습니다. 다시 작동할 때까지 이것저것 지워보면서 직접 찾아내야 합니다.) 그것은 유용한 작은 굴욕이었으며, 생태계 전체가 블로그 포스트에서 말하는 것보다 훨씬 더 젊다는 사실을 상기시켜 주는 종류의 경험이었습니다. 그리고 결승선에 도달했을 때: 제 액세스 토큰(access tokens)이 계속 만료되었고, Claude.ai는 24시간마다 연결을 끊어버렸습니다. 그래서 저는 토큰 만료 시간을 100년으로 설정했습니다. 추합니다. 하지만 괜찮습니다. 왜냐하면 이 도구의 사용자는 정확히 1명이고, 그 이름은 바로 저이기 때문입니다. (올바른 해결책은 리프레시 토큰(refresh-token) 댄스입니다. 네, 저도 압니다. 하지만 하지 않았습니다. 지난 3개월 동안 저를 괴롭히지 않았거든요.) 여러분이 패닉에 빠지기 전에 솔직한 주의 사항을 하나 말씀드리겠습니다. 이 모든 난장판은 저의 스택(stack)에서 일어난 일입니다. Next.js, Convex, Vercel, 그리고 클라이언트로서의 Claude.ai 말입니다. 다른 스택을 선택하거나, 누군가가 이미 운영 중인 호스팅된 MCP 서버에 연결한다면, 완전히 다른 종류의 벽에 부딪히거나 혹은 거의 아무런 벽도 마주하지 않을 것입니다. 저의 전쟁 이야기는 특수한 상황에서의 경험이지, 유일한 정답이 아닙니다. 이것을 '너무 어렵다'는 증거가 아니라, 실제 마찰(friction)의 형태로서 읽어주세요. 왜냐하면 훨씬 더 짧은 경로들이 존재하기 때문입니다. 이 중 그 어떤 것도 공상 과학이 아니었습니다. 그것은 마찰이었습니다. 짜증 나고, 시대에 뒤떨어진 마찰, 즉 Stack Overflow에 답변이 아직 존재하지 않는 그런 종류의 마찰 말입니다. 지금은 2026년이고, 이런 것들은 여전히 테이프로 겨우 붙여져 있습니다. 그것이 기다려야 할 이유는 아닙니다. 그 테이프가 바로 핵심입니다.

지금 바로 시작하는 방법
그렇다면 실제로 어디서부터 시작해야 할까요? 여기에는 두 개의 문이 있습니다. 그리고 제목에서 제가 '처음부터 구축(build from scratch)'하는 것이 아니라 '연결(wire up)'하라고 의도적으로 말한 이유가 있습니다. 두 문 모두 정당한 방법입니다.

빠른 문: 인프라를 빌려 쓰세요. 만약 인증 (auth) 레이어를 직접 작성하고 싶지 않다면, 좋은 소식은 대부분 그럴 필요가 없다는 것입니다. 결제 (money) 레이어는 이미 출시되었습니다. Stripe는 mcp.stripe.com에서 호스팅된 MCP 서버를 운영하고 있으며, 여기에 연결하는 것은 몇 초 만에 끝나는 OAuth 클릭 한 번이면 충분합니다. 모든 Shopify 스토어는 이미 공개 카탈로그 작업을 위해 /api/mcp 엔드포인트를 노출하고 있으며, 읽기 측면에서는 인증이 필요하지 않습니다. PayPal도 자체적인 것을 출시했습니다. WooCommerce는 현재 퍼블릭 베타로 제공 중입니다. 패턴은 어디나 동일합니다: 누군가가 이미 서버를 운영하고 있고, 당신은 거기에 연결하기만 하면 되며, 당신의 데이터는 몇 분 만에 에이전트 (agent)가 읽을 수 있는 형태가 됩니다. 이 글을 읽는 대부분의 사람들에게 이것이 이동의 전부입니다. 당신이 아무것도 구축하지 않았다고 해서 뒤처진 것이 아닙니다. 당신의 카탈로그, 가격, 그리고 재고 현황이 오직 눈이 있는 인간만이 파싱 (parse)할 수 있는 형식으로 놓여 있다면, 그때가 바로 뒤처진 것입니다. 저는 아이들이 2미터 옆에서 다이빙을 하고 있는 수영장 가에 앉아 처음으로 Stripe 서버를 연결해 보았는데, 그냥 바로 작동했습니다. OAuth 클릭, 끝이었습니다. 제가 직접 서버를 구축하기 위해 한 달 동안 쏟아부었던 노력에 비하면, 너무나 허무하게 느껴져서 거의 짜증이 날 정도였던 기억이 납니다. 아이들은 그런 것에 전혀 관심이 없었습니다. 아이들은 제가 다이빙 점수를 매겨주길 원했고, 그래서 저는 다이빙 점수를 매겼습니다.

제어 문: 직접 운영하세요. AI 에이전트 (AI Agent) 개발을 위한 두 가지 인프라 경로. 다른 문은 제가 통과했던 문이며, 당신은 이미 그것이 어떤 비용을 치르는지 읽었습니다. 당신이 직접 서버를 구축하고 운영하는 것입니다. 장점은 확실합니다: 완전한 제어권, 그리고 일반적인 카탈로그 엔드포인트가 다루지 못하는 로직, 즉 당신만의 독특한 가격 규칙, 번들 계산, 파트너 전용 피드 등을 노출할 수 있는 능력입니다. 제가 쉬운 문으로 당신을 밀어넣기 위해 겁을 주는 것이 아닙니다. Stripe나 Shopify가 미리 잘라놓은 형태에 맞지 않는 비즈니스를 운영하는 누구에게나 이것은 정당한 선택입니다. 다만 그 대가는 '고생담 (war story)'이 될 뿐입니다. 그리고 라벨에는 아무도 인쇄하지 않는 비용이 있습니다: 에이전트 지연 시간 (agentic latency). 사람들은 그것을 그렇게 부르며, 이름 그대로의 의미를 갖습니다.

만약 호스팅된 서버가 느리다면, 그것을 호출하는 에이전트 (agent) 또한 느려지며, 느린 에이전트는 작업을 수행하던 도중에 중단되는 결과를 초래합니다. '빠른 문 (fast door)'은 제어권 (control)을 타인의 가동 시간 (uptime)과 맞바꾸는 것입니다. '제어 문 (control door)'은 의도적으로 속도를 높일 수 있는 능력을 얻기 위해 당신의 저녁 시간을 맞바꾸는 것입니다. 당신이 실제로 감당할 수 있는 거래를 선택하십시오. 개발자가 아닌 대중을 대상으로 하는 이 글에서는, '빠른 문'부터 시작할 것을 권합니다. 기존 인프라를 연결한 다음, 에이전트가 실제로 당신의 데이터를 읽고 있는지, 혹은 해당 엔드포인트 (endpoints)에 실제로 요청이 도달하고 있는지 확인하십시오. 내부화 (internalize)는 나중에, 정말로 필요할 때 하셔도 됩니다. 그리고 저는 조심스럽게 예측하건대, 직접 운영하는 경로 (run-your-own path)는 조용히 파트타임 업무로 변질되지 않고서는 1인 운영자를 넘어 확장하기 어려울 것이라고 확신합니다. 혼자라면 괜찮습니다. 하지만 팀을 위해서라면, 그것이 버텨낼 수 있다고 약속하기 전에 한동안 운영되는 모습을 지켜보고 싶습니다. 만약 그 전체 경로를 단계별로 상세히 알고 싶다면, 제가 쓴 데모에서 라이브 앱으로 넘어가는 법에 관한 책에 정리해 두었습니다. 그리고 만약