Claude 상거래 에이전트 설계도가 공개됐다…결제 완제품은 아니다
Anthropic이 2026년 9월 2일 구매자용 쇼핑 에이전트와 판매자용 에이전트를 구축할 수 있는 Claude Commerce Agents 설계도와 실행 코드를 공개했다. Anthropic의 공식 발표 는 소매·여행·통신·티켓 분야의 참조 구현과 자체 시스템에 연결하는 개발 구조를 공개 범위로 제시했다.
이번 공개물은 내려받아 실행할 수 있는 코드이지만, Anthropic이 운영하는 결제 서비스나 즉시 영업에 투입할 쇼핑 완제품은 아니다. 로이터 보도 도 이를 쇼핑·판매자 에이전트를 만들기 위한 청사진으로 규정하며, 구매자를 대신해 결제를 완료하는 제품은 아니라고 전했다.
실행 코드는 들어 있지만 거래 시스템은 비어 있다
공개 저장소에는 Python 패키지, 설치 스크립트, 테스트, 웹 데모가 포함돼 있다. 개발자는 쇼핑 화면이나 판매자 포털을 로컬에서 실행하고, Messages API·Claude Agent SDK·Managed Agents 가운데 사용할 실행 환경에 맞춰 에이전트 구조를 살펴볼 수 있다.
다만 데모에 등장하는 회사·브랜드·상품·인물은 가상 데이터다. Anthropic의 공개 저장소 는 checkout이 장바구니를 호스트 애플리케이션에 표시할 뿐 주문을 넣거나 카드를 청구하지 않으며, 판매자 측 변경도 사람이 승인하기 전까지 실제 목록에 적용되지 않는다고 명시한다.
Apache 2.0 라이선스가 적용돼 코드를 복제하고 수정할 수 있다는 점과 운영 가능한 상거래 서비스가 제공된다는 점은 구분해야 한다. 저장소는 에이전트의 대화 흐름과 도구 계약, 안전장치, 예제 백엔드를 제공하지만 실제 상품 원장이나 고객 계정, 결제 대행 계약, 주문 처리 시설까지 포함하지 않는다.
구매자용과 판매자용은 권한부터 다르다
쇼핑 에이전트는 고객이 상품을 검색하고 비교하도록 돕고, 조건에 맞는 선택지를 정리해 장바구니를 구성한다. 주문이나 정책에 관한 질문을 처리하고 고객이 대화에서 밝힌 선호를 기억하는 흐름도 마련돼 있다. 실제 배포에서는 StorefrontBackend를 기업의 카탈로그, 장바구니, 주문 기록, 정책 데이터에 연결해야 한다.
판매자용 에이전트는 매장 운영자를 위한 별도 구조다. 판매 실적을 설명하고 상품 목록을 관리하며, 재고와 주문 경보를 살피고 가격 조정·프로모션·마케팅 캠페인 변경안을 작성한다. 이를 사용하려면 MerchantBackend가 기업의 분석, 카탈로그, 재고, 가격, 캠페인 시스템에서 권한에 맞는 데이터를 가져와야 한다.
역할을 분리한 이유는 두 에이전트가 일으킬 수 있는 손실의 성격이 다르기 때문이다. 쇼핑 에이전트가 틀린 가격이나 재고를 제시하는 위험과 판매자용 에이전트가 실제 가격·재고를 바꾸는 위험은 같은 통제로 처리하기 어렵다. 공개 구조에서는 모델이 변경을 제안하더라도 호스트 시스템이 승인 여부와 적용 시점을 결정한다.
네 산업 예제와 Claude Code 플러그인이 출발점을 만든다
실행 예제는 소매, 여행, 통신, 엔터테인먼트의 네 분야로 나뉜다. 소매는 상품 검색·비교·장바구니, 여행은 날짜가 있는 재고와 일정, 통신은 요금제와 계정 맥락, 엔터테인먼트는 좌석 보류와 대기 명단 같은 서로 다른 거래 단위를 다룬다.
각 예제는 공통 에이전트 라이브러리 위에 업종별 데이터 구조와 표시 도구를 얹는다. 이는 네 업종이 완제품 형태로 지원된다는 뜻이 아니라, 같은 에이전트 골격을 서로 다른 카탈로그와 업무 규칙에 맞춰 바꾸는 방법을 보여 주는 것이다. 실제 기업의 상품 식별자, 가격 규칙, 회원 인증 정보는 자동으로 채워지지 않는다.
함께 공개된 Claude Code용 commerce-builder 플러그인은 새 프로젝트의 골격을 만들고 업무 흐름과 평가 항목을 추가하거나 기존 에이전트 구성을 검토하는 명령을 제공한다. 플러그인 역시 기업의 백엔드를 대신 구축하지 않는다. 어떤 API를 어떤 권한으로 호출할지 정하고 그 연결을 구현할 개발 작업은 그대로 남는다.
결제·환불·재고 변경은 호스트가 통제한다
가장 분명한 경계는 결제다. 쇼핑 에이전트가 checkout을 호출하면 에이전트의 역할은 장바구니를 표시하는 단계에서 끝난다. 자체 앱의 결제 경로나 외부 사업자가 호스팅하는 결제 페이지로 고객을 넘기는 방식은 기업이 구현해야 하며, 카드 정보가 모델의 대화 경로를 통과하도록 설계되지 않았다.
따라서 결제수단 저장, 본인 확인, 거래 승인, 실패 처리, 취소는 별도 결제 인프라의 책임이다. Claude가 상품 선택과 장바구니 구성을 도왔다고 해서 결제 주체나 거래 기록의 관리자가 되는 것은 아니다. 제목의 ‘결제 완제품은 아니다’라는 제한은 바로 이 구조에서 나온다.
판매자 측 쓰기 작업도 곧바로 실행되지 않는다. 가격, 재고, 프로모션, 캠페인 변경은 먼저 임시 상태로 만들어지고 승인된 변경 식별자만 적용 단계로 넘어간다. 적용 시점에는 현재 정책과 한도를 다시 검사하도록 구성돼 있어, 모델의 제안과 사업 시스템의 최종 실행 사이에 별도의 통제 지점이 남는다.
환불 역시 모델에 포괄적 권한을 주는 기능으로 제공되지 않는다. 자동 처리 한도, 담당자 등급, 예외 발생 시 사람에게 넘기는 조건은 배포 기업이 정책과 코드로 정해야 한다. 한국에서 사용할 경우 국내 결제 절차와 개인정보 처리, 전자상거래 관련 의무를 어떻게 반영할지도 공개 예제가 대신 결정하지 않는다.
공개된 것은 권한 경계를 드러낸 참조 구현이다
이번 자료의 실질적 가치는 상거래 에이전트가 어떤 대화를 할 수 있는지 보여 주는 데만 있지 않다. 모델이 판단하는 영역, 기존 시스템이 제공해야 하는 데이터, 사람이 승인해야 하는 변경을 코드 구조 안에서 분리했다는 점이 핵심이다. Claude는 이 구조의 지능 계층이지만 카탈로그, 공급망, 결제망을 소유하거나 대체하지 않는다.
따라서 도입 범위는 저장소를 실행하는 순간이 아니라 실제 백엔드를 연결하는 순간에 결정된다. 고객과 운영자의 신원을 세션에 묶는 방식, 에이전트가 읽을 수 있는 주문 정보, 변경 가능한 가격과 재고의 범위, 결제와 환불의 승인 규칙을 기업별로 설계해야 한다.
현재 확인된 공개물은 쇼핑·판매자 에이전트 코드, 네 산업의 실행 예제, Claude Code 플러그인을 갖춘 개발용 청사진이다. 아직 공개 자료만으로는 실제 기업 환경에서의 운영 성과나 한국 결제·인증 체계와의 구체적인 연결 방식까지 알 수 없다. 후속 구현에서 확인할 쟁점은 어떤 시스템을 연결했는지보다, Claude에 어디까지 읽기·제안 권한을 주고 최종 거래 권한을 어디에 남겼는지가 될 전망이다.
함께 읽기:
뉴스레터 구독
최신 Web3, AI, 암호화폐 뉴스를 이메일로 받아보세요.