주문은 들어오는데, 쇼핑몰을 둘러보는 손님은 없다. 밤새 골라 올린 대표 사진도, 돈을 들여 마련한 배너도 아무도 보지 않는다. 손님 대신 찾아온 AI가 가격과 배송 조건을 확인하고, 물건만 사간다.

2026년 6월 24일, 쇼피파이는 AI가 사용하는 기존 장바구니 도구 두 개의 지원 종료를 예고했다. 대신 UCP라는 공통 거래 규격에 맞춘 도구로 옮기라고 안내했다. 기존 도구의 유지 기한은 8월 31일까지였다. 나는 장바구니 도구를 바꾼다는 이 작은 공지에서, 그런 쇼핑몰을 떠올렸다.

이 변화가 무엇을 뜻하는지 보려면 MCP와 UCP의 차이부터 이해할 필요가 있다.

MCP는 AI가 외부 서비스의 도구를 사용하는 공통 방식이다. 상점이 ‘상품 찾기’나 ‘장바구니 수정하기’ 같은 기능을 제공하면, AI는 사용법을 읽고 실행할 수 있다. 같은 방식으로 일정을 확인하거나 회사 문서를 찾을 수도 있다. 서비스마다 연결 방법을 처음부터 따로 개발해야 하는 수고를 줄여준다.

하지만 연결 방식이 같다고 거래 규칙까지 같은 것은 아니다. 가령 A상점에 ‘수량 2’를 보내면 상품 두 개가 추가되고, B상점에서는 장바구니에 담긴 수량이 두 개로 바뀐다고 하자. 둘 다 MCP를 쓸 수 있지만, AI는 각 상점의 설명을 읽고 차이를 처리해야 한다. 배송비를 언제 더하는지, 어느 단계에서 주문이 확정되는지도 따로 알아야 한다.

UCP는 이 거래 규칙을 맞추려는 약속이다. 상품 정보와 장바구니, 결제 절차와 주문 상태를 공통된 형식으로 주고받자는 것이다. 모든 상점의 기능을 똑같이 만들겠다는 뜻은 아니다. 기본 규칙을 공유하면서, 각자 지원하는 기능과 버전을 확인해 가능한 범위에서 거래한다. 상점 고유의 기능도 덧붙일 수 있다.

쉽게 말해 MCP가 ‘도구를 어떻게 불러 쓸 것인가’를 정한다면, UCP는 ‘거래 정보를 어떤 뜻으로 주고받고, 어떤 순서로 처리할 것인가’를 정한다. 그래서 UCP는 MCP의 다음 버전이 아니다. 둘은 함께 쓸 수 있다. 쇼피파이의 ‘UCP Cart MCP’에 두 이름이 나란히 붙은 이유다.

이제 사용자가 AI에게 이렇게 부탁한다고 해보자.

“금요일까지 도착하는 검은색 운동화 찾아줘. 사이즈는 270, 배송비 포함해서 15만 원 안에서. 결제하기 전에는 꼭 물어봐.”

이런 요청은 MCP만으로도 처리할 수 있다. 다만 상품을 장바구니에 담고, 배송지를 입력하고, 최종 금액을 확인하는 방법을 상점마다 따로 맞춰야 할 수 있다. 상점들이 필요한 UCP 기능을 지원한다면, 에이전트가 이 과정을 공통된 방식으로 처리하기 쉬워진다.

A상점은 가격이 싸지만 토요일에 도착하므로 탈락한다. B상점은 금요일에 도착하고 예산에도 맞는다. AI는 B상점의 최종 조건을 사용자에게 보여주고 승인을 기다린다.

물론 장바구니를 만들었다고 결제가 끝난 것은 아니다. 쇼피파이도 준비한 장바구니를 별도의 결제 도구로 넘긴다. 사용자의 허락과 필요한 결제 인증은 따로 거쳐야 한다. 거래 규칙이 통일됐다고 해서 AI에게 돈을 쓸 권한까지 생기는 것은 아니다.

그런데 이 구매 과정에는 우리가 익숙한 장면이 빠져 있다. 상세페이지를 읽다가 마음이 흔들리는 순간도, 나가려는 고객에게 쿠폰을 내미는 순간도 없다. AI가 조건을 비교하는 동안 A상점은 이미 후보에서 사라졌다.

A상점은 고객에게 거절당할 기회조차 얻지 못했다.

지금까지 쇼핑몰은 고객의 클릭을 얻기 위해 경쟁했다. 하지만 에이전트가 구매 후보를 추리는 환경에서는 클릭하기 전에 승부가 날 수 있다. 배송이 빨라도 언제 도착하는지 AI가 확인할 수 없다면 비교에서 밀릴 수 있다. 가격이 싸도 배송비를 더한 최종 금액을 알 수 없다면 마찬가지다. 좋은 조건을 제공하는 능력만큼, 그 조건을 기계가 읽고 확인할 수 있게 만드는 능력이 중요해진다.

이 변화가 마냥 반갑지는 않다. A상점이 배송일 때문에 빠졌는지, 에이전트 운영사에 수수료를 덜 냈기 때문에 빠졌는지 사용자는 모를 수 있다. 광고는 적어도 눈앞에 나타난다. 하지만 후보에서 빠진 상품은 존재했는지조차 알기 어렵다. 거래 규격이 열려 있어도 선택 과정까지 투명해지는 것은 아니다. 무엇을 보여줄지 결정하는 회사가 새로운 문지기가 될 수 있다.

그래도 사용자는 편리함에 익숙해질 것이다. 처음에는 운동화 하나를 맡기고, 다음에는 생필품과 여행 준비를 맡긴다. 사용자의 허락을 받아 일정과 구매 이력까지 살펴보는 에이전트라면, 언젠가는 먼저 이렇게 물을 수 있다.

“지난번 신발은 오래 걸으면 아프다고 했죠. 다음 주 여행에는 다른 걸 준비할까요?”

검색어를 입력하기도 전에 쇼핑이 시작된다. 내 생활을 먼저 이해하는 회사가 다음 구매의 출발점까지 차지한다. 쇼핑몰은 내가 여행을 간다는 사실도 모르는데, 에이전트는 이미 어떤 신발을 제외해야 할지 알고 있다.

한국 이커머스를 이 장면에 놓으면, 더 앞에서 막히는 문제가 보인다. 공통 거래 규격을 논하기 전에 먼저 물어야 한다. 고객이 보낸 AI가 상품을 조회하고 주문할 수 있는 통로부터 열려 있는가.

그 통로가 API다. 외부 프로그램이 서비스의 기능을 이용할 수 있게 해주는 접점이다. 하지만 API가 있다는 답만으로는 부족하다. 제휴 심사를 통과한 사업자에게만 열려 있다면 개인이 데려온 에이전트는 쓸 수 없다. 판매자가 상품을 등록하고 주문을 관리하는 API가 있다고 해서, 구매자를 대신해 물건을 사는 API도 있다는 뜻은 아니다. 사람이 보는 웹사이트가 공개돼 있다는 것과 프로그램이 거래할 수 있는 통로가 열려 있다는 것도 다른 이야기다.

사람은 회원가입을 하고 물건을 살 수 있다. 그런데 그 사람이 보낸 AI에는 제휴 계약을 요구한다. 사용자는 구매를 맡겼는데, 플랫폼은 그 대리인을 받아들이지 않는 셈이다.

나는 한국 플랫폼의 약점이 이 지점에서 드러날 수 있다고 본다. ‘고객이 우리 앱에 들어와야 장사가 시작된다’는 전제다. 고객을 불러들이고, 오래 머물게 하고, 그 사이 광고와 추천을 보여주는 방식에 익숙하다. 외부 에이전트가 주문만 가져오면 매출은 생겨도 광고를 보여줄 기회는 줄어든다. 기술적으로 열 수 있어도 사업적으로는 열고 싶지 않을 수 있다.

그렇다고 문을 닫아두면 고객이 계속 앱을 열어줄까. 아니면 자기 비서가 이용할 수 있는 다른 상점으로 갈까.

배송이 빠르고 물건이 좋아도 구매를 끝낼 수 없다면 에이전트는 다른 후보를 찾을 것이다. 국내 플랫폼끼리 누가 고객을 더 단단히 묶어두는지 경쟁하는 동안, 고객은 그 묶음을 풀어주는 비서에게 익숙해질 수 있다. 에이전트에게 멤버십 혜택은 충성심의 이유가 아니라, 최종 가격을 계산할 때 넣는 조건 하나일 뿐이다.

뒤늦게 외부 에이전트에 문을 여는 것만으로는 충분하지 않을 수 있다. 그때는 이미 다른 회사가 고객의 취향과 구매 이유를 쌓아두고, 다음에 어떤 제안을 보여줄지 정하고 있을 수 있기 때문이다. 그렇게 되면 국내 플랫폼은 주문을 받아 포장하고 배송하지만, 고객이 왜 샀는지와 다음에는 무엇을 살지는 에이전트 운영사가 더 잘 알게 된다.

창고는 바쁘고 배송차도 계속 나간다. 그래서 위기를 늦게 알아차릴 수 있다. 물건은 우리가 보내는데, 단골은 남의 것이 돼 있다.

국내 업계가 지금 시험해봐야 할 것은 분명하다. 제휴하지 않은 개발자가 만든 에이전트도 고객의 명시적 동의 아래 가격과 혜택을 확인하고, 주문과 취소까지 처리할 수 있는가. 할 수 없다면 어디서 막히는가. 그 장벽은 정말 고객을 보호하기 위한 것인가, 아니면 고객이 앱을 떠나지 못하게 붙잡기 위한 것인가.

UCP가 최종 표준이 될지는 모른다. 하지만 어떤 규격이 남더라도, 고객이 보낸 대리인을 맞을 준비는 필요하다. 새로운 거래 규칙을 함께 정할 역량도 갖춰야 한다. 남이 만든 규칙이 굳어진 뒤에야 입점 신청서를 쓰는 처지로 밀려나서는 안 된다.

한국 이커머스가 두려워해야 할 것은 쇼핑 AI를 조금 늦게 만드는 일이 아니다. 고객이 보낸 AI를 거절하는 동안, 고객을 이해하고 다음 구매를 제안할 기회까지 다른 회사에 넘기는 일이다.

손님을 붙잡겠다며 문을 잠그다가는, 어느 날 문밖에서 쇼핑이 전부 끝나 있을 것이다.