마켓플레이스가 에이전트에 개방될 때: Amazon Seller Central의 AI 플러그인과 셀 사이드 운영 레이어

핵심 요점

• Amazon은 2026년 9월 23일 Seller Central의 셀 사이드 API 표면을 외부 AI 에이전트에 개방했습니다 — 재고, 가격, 리스팅, 판매 분석을 커버하는 Amazon Quick과 Anthropic의 Claude를 위한 미국 베타 Selling Partner 플러그인입니다.
• Amazon 판매 파트너의 90%가 이미 서드파티 AI 도구를 사용하고 있으며, 판매자는 Seller Assistant의 권고를 90% 이상의 시간에 수용합니다 — Amazon은 이미 존재하는 에이전트 매개 워크플로를 따라 판매자들을 따라가고 있는 것입니다.
• Amazon은 오픈 프로토콜이 아닌 플러그인 경로를 선택했습니다 — UCP, ACP, AP2, x402는 여전히 바이 사이드 표준이며, 어떤 어시스턴트가 연결되는지는 Amazon이 결정하고, 발표 며칠 전에는 Meta의 Muse 쇼핑 에이전트를 스토어에서 차단했습니다.
• 권한 모델이 평가 표면입니다: 범위가 지정된 데이터 유형, 작업별 인간 승인, 완전한 감사 추적 — 판매자는 플러그인이 접근할 데이터를 선택하고 실행 전에 각 작업을 승인합니다.
• 플러그인은 어시스턴트에 Amazon의 데이터를 연결할 뿐 — 판매자의 자체 스택이 아닙니다 — NetSuite, BigCommerce, 또는 ShipStation을 운영하는 B2B 판매자는 티어 가격, 멀티채널 재고, 주문 라이트백을 위해 자체 에이전트 모듈 레이어가 여전히 필요합니다.

올해 추적한 모든 에이전틱 커머스 표준 — UCP, ACP, AP2, x402, Checkout MCP — 은 바이 사이드를 다룹니다: 에이전트가 상품을 발견하고, 가격을 협상하고, 체크아웃을 완료하고, 결제하는 방식입니다. (우리는 그 스택을 AI 에이전트를 위한 커머스 프로토콜에서 매핑했습니다.) 2026년 9월 23일, Amazon은 Accelerate 셀러 컨퍼런스에서 거래의 반대편을 열었습니다. 새로운 Selling Partner 플러그인은 가장 큰 마켓플레이스의 셀 사이드 운영 — 재고, 가격, 리스팅, 판매 분석 — 을 미국 베타로 Amazon Quick과 Anthropic의 Claude 안에 넣습니다. 그 끌림은 측정 가능합니다: Amazon 판매 파트너의 90%가 이미 비즈니스의 일부를 운영하는 데 서드파티 AI 도구를 사용하고 있으며, 그 판매자들이 Amazon에 지불한 수수료는 2026년 2분기에 468억 달러를 기록했습니다 — GeekWire가 보도에서 언급했듯 AWS 매출보다 많은 금액입니다.

이 글은 플러그인이 실제로 무엇을 개방하는지, 아마존이 오픈 프로토콜 대신 에이전트 플러그인 경로를 선택한 이유, 권한 모델이 무엇을 통제하는지, 그리고 무엇을 해결하지 못하는지를 매핑합니다 — B2B 판매자의 운영은 마켓플레이스 경계에서 끝나지 않기 때문입니다. 에이전트가 Amazon에서 조정하는 가격은 NetSuite의 티어 가격과 대조되어야 합니다. 방금 변경한 재고 수준은 BigCommerce와 창고와 일치해야 합니다. 마켓플레이스가 생성하는 주문은 여전히 ERP에 도달해야 합니다. 플러그인은 에이전트 운영에 대한 마켓플레이스의 답입니다. 그 통합의 판매자 측은 여전히 구축할 과제로 남습니다.

아마존이 실제로 출시한 것

9월 23일에 세 가지가 출시되었으며, 각각 평가 프로필이 다르기 때문에 구분할 가치가 있습니다.

업그레이드된 Seller Assistant. Seller Central 안의 AI 컴패니언은 이제 각 판매자의 가격 패턴, 재고 주기, 성장 목표에 대한 영속 메모리를 갖추고, Claude 모델로 Amazon Bedrock에서 실행됩니다. Amazon은 판매 파트너의 90% 이상에게 롤아웃되어 수십만 명의 활성 사용자를 보유하고 있으며, 판매자가 그 권고를 90% 이상의 시간에 수용한다고 보고합니다. 마지막 숫자가 메모리 기능보다 더 중요합니다: Seller Central 안에서 다수에게 수용되는 추천 엔진이 바로 플러그인이 확장하는 행동 기준선입니다.

Seller Assistant 워크플로. 조건을 모니터링하고 권한이 있을 때 작동하는 상시 자동화입니다 — "상위 10개 제품 중 하나라도 별 4개 아래로 떨어지면 알려주고 대응 계획 초안을 작성해 달라" 또는 "주력 카테고리에서 경쟁 공백을 모니터링하고, 발견하면 가격을 조정하고 리스팅을 새로고침해 달라" 같은 것입니다. 판매자는 일상 언어로 가드레일을 설정하고 워크플로가 권고만 표시할지 작업을 수행할지 선택합니다. 모든 작업은 완전한 감사 추적으로 기록됩니다.

Selling Partner 플러그인. 새로운 표면입니다. 플러그인은 판매자의 리스팅 기여, 실시간 성과 지표, 재고 수준, 판매 분석을 외부 에이전트 — 출시 시점의 Amazon Quick, 베타의 Claude — 에 연결하며, 외부 에이전트는 Seller Central 안의 Seller Assistant가 그러하듯 계정에 대해 작업을 수행할 수 있습니다. Amazon에 따르면 Claude 연결은 코딩 없이 약 60초가 걸리며, 판매자의 기존 회계 및 공급업체 데이터 연결과 나란히 놓입니다.

아마존 자체 VP의 프레이밍이 전략적 헤드라인입니다: "판매자가 Seller Central에 로그인할 필요가 전혀 없도록 하는 것이 우리의 비전이었습니다"라고 Worldwide Selling Partner Experience 부사장 Mary Beth Westmoreland가 GeekWire 인터뷰에서 말했습니다. "판매자가 일하는 곳으로 그것을 가져다주겠다는 것입니다."

프로토콜 경로가 아닌 플러그인 경로인 이유

바이 사이드 프로토콜은 설계상 열려 있습니다: UCP는 공개 스펙과 공동 개발사를 갖고, ACP는 GitHub에 있으며, 어떤 가맹점이든 엔드포인트를 노출할 수 있습니다. 셀 사이드 개방은 정반대 모양입니다. Amazon은 자신이 선택한 어시스턴트 — 자체 Quick 먼저, 그다음 Anthropic의 Claude, 즉 Amazon이 수십억 달러를 투자했고 그 모델이 이미 Seller Assistant를 구동하는 회사 — 를 위한 플러그인을 공개하고, 더 많은 통합이 "플러그인을 계속 공개할 수 있을 만큼 충분히 모듈화된" 방식으로 구축되어 뒤따를 것이라고 말합니다. 발표 어디에도 다른 플랫폼이 구현할 수 있는 사양에 대한 설명은 없습니다.

맥락이 대비를 선명하게 만듭니다. Accelerate 며칠 전, Amazon은 소비자 쇼핑 에이전트인 Meta의 Muse를 스토어에서 차단했습니다 — 외부 에이전트는 신원을 밝히고 사용하는 사이트의 규칙을 따라야 한다는 것이 Amazon의 공식 입장이었습니다 (GeekWire). 셀 사이드에서 Amazon은 동시에 호스트이자 규칙 제정자이자 플러그인 게시자입니다. 셀 사이드 에이전트 표면은 Amazon이 존재한다고 말하는 곳에 존재합니다.

판매자에게 그것은 참여를 꺼려야 할 이유가 아닙니다. 역량과 같은 엄격함으로 조건을 평가해야 할 이유입니다 — 그 표면은 마켓플레이스를 소유한 상대방에 의해 확장되거나, 재가격되거나, 축소될 수 있기 때문입니다. 판매자 수수료는 이미 2027년 3월 재판이 예정된 FTC의 아마존 반독점 소송의 대상입니다 (GeekWire); 판매자 도구의 경제성은 중립적인 배경이 아닙니다.

아래 다이어그램은 플러그인을 바이 사이드 프로토콜 스택과 그것이 적용하는 권한 게이트와 나란히 놓습니다.

권한 모델이 통제하는 것

아마존 자체의 안전성 설명은 평가하기에 충분히 정밀합니다: 플러그인 상호작용은 "접근할 수 있는 것에 대한 명확한 경계, 작업에 대한 인간 승인, 완전한 감사 추적"으로 보호됩니다. 실제로는 네 개의 게이트입니다.

데이터 범위. 판매자는 플러그인이 접근할 수 있는 데이터 유형 — 리스팅, 재고, 판매 분석, 성과 지표 — 을 선택합니다. 범위는 데이터 유형별이며 판매자가 선택합니다.

의도 가시성. Quick에서 플러그인을 중심으로 구축된 에이전트 — 가격 에이전트, 리스팅 에이전트, 재입고 에이전트 — 는 작업을 수행하기 전에 수행하려는 것을 보여줍니다.

인간 승인. 작업은 수행되기 전에 판매자의 승인을 필요로 하며, 이는 Seller Assistant 워크플로가 이미 사용하는 패턴 — 권고 전용, 또는 승인 후 실행 — 과 일치합니다.

감사 추적. 모든 작업이 기록됩니다. Amazon은 또한 판매자 어시스턴트 안의 다른 비즈니스 데이터 — 판매자가 Claude에 보관하는 회계 및 공급업체 연결 — 는 보지 않는다고 밝힙니다. 이는 자체 시행에 대한 아마존의 진술이지 독립적으로 검증 가능한 속성이 아닙니다; 그에 맞게 다루십시오.

이것은 커스텀 MCP 모듈이 강제하는 것과 동일한 통제 패턴입니다: 범위가 지정된 도구, 타입이 지정된 파라미터, 쓰기에 대한 인간 게이트, 감사에서 살아남는 로그. 차이는 판매자의 가시성에 불리하게 작용합니다. 자체 모듈에서는 범위가 팀이 읽을 수 있는 코드입니다. 퍼스트파티 플러그인에서는 마켓플레이스가 범위를 정의하고 판매자는 벤더의 시행을 신뢰합니다. 어느 쪽도 틀리지 않습니다 — 하지만 둘은 다른 신뢰 결정이며, 후자는 보안 팀이 서드파티 통합에 부여하는 것과 같은 검토를 받을 자격이 있습니다.

갭: 플러그인은 판매자의 스택이 아니라 아마존의 데이터를 연결합니다

60초 연결은 Amazon을 어시스턴트에 묶습니다. B2B 판매자의 실제 운영이 실행되는 시스템에는 아무것도 하지 않습니다.

가격. 플러그인은 판매자 가드레일 내에서 Amazon 가격을 조정할 수 있습니다. 하지만 조정 전에 NetSuite의 고객 티어 가격표, CPQ의 계약 조건, 마진 하한선을 확인할 수는 없습니다. Amazon 채널이 직접 B2B 가격과 일치해야 하는 판매자에게, 그 변경을 지배하는 가격 로직은 플러그인의 손이 닿지 않는 곳에 있습니다.

재고. 플러그인은 Amazon 재고 수준을 봅니다. 멀티채널 재고 — BigCommerce의 같은 SKU, Brightpearl 창고의 재고, ShipStation 배송에 할당된 물량 — 는 플러그인이 다루지 않는 별도의 동기화 문제입니다.

주문과 라이트백. 마켓플레이스 주문은 여전히 검증, 세금 및 배송 로직, ERP 등록이 필요합니다. 그것이 주문 관리 레이어입니다 — 주당 1,800건의 주문을 처리하는 직원 380명 규모의 유통업체가 NetSuite, BigCommerce, ShipStation에 걸친 타입 스키마 검증으로 12%의 입력 오류율을 2% 미만으로 줄인 바로 그 레이어입니다.

선호 어시스턴트 패턴은 양방향으로 작동합니다. Amazon의 제안은 판매자가 이미 Claude를 "기존 회계 및 공급업체 데이터 연결과 함께" 실행하고 있다는 것입니다. Amazon의 데이터가 같은 어시스턴트에 도착하는 순간, 판매자는 Amazon 가격을 ERP 비용과, 마켓플레이스 재고를 창고 재고와 일치시키도록 요청할 것입니다. 그 크로스 시스템 추론이 바로 플러그인이 제공하지 않는 통합이며 — 판매자 자신의 에이전트 레이어가 그것을 안전하게 만듭니다: 각 시스템을 위한 거버넌스된 모듈, 에이전트가 읽고 쓸 수 있는 것에 대한 명시적 핸들, 그리고 비즈니스가 이미 감사하는 시스템에 도달하는 감사 추적입니다.

베타 활성화 전에 평가할 것

순서대로 네 가지 질문입니다:

1. 플러그인이 읽기만 하는 것이 아니라 무엇을 쓸 수 있는가? 가격 변경, 리스팅 편집, 재고 조정은 서로 다른 위험 등급입니다. Amazon의 워크플로는 권고 전용과 승인 후 실행을 구분합니다 — 활성화하기 전에 각 워크플로를 올바른 등급에 매핑하십시오.
2. 승인은 어디에 위치하는가? 작업별, 워크플로별, 또는 세션별입니다. 가격 에이전트의 작업별 승인은 세션 전체 부여와는 다른 운영 모델입니다.
3. 감사 추적은 무엇을 캡처하고 어디까지 갈 수 있는가? 감사관이 NetSuite나 컴플라이언스 웨어하우스를 읽는다면, 추적은 감사관이 이미 읽는 시스템에 도달해야 합니다.
4. 판매자 측은 무엇을 필요로 하는가? 여러분의 시스템 중 어느 것이 에이전트가 한 일을 봐야 하는가 — ERP, 스토어프론트, 창고 — 그리고 그 데이터는 어떻게 이동하는가? 그것이 여러분이 소유한 통합입니다.

셀 사이드 운영 레이어는 이제 에이전트 표면입니다. Amazon은 플러그인과 권한 모델로 수를 두었습니다; 미드마켓 B2B 판매자가 실제로 소유하는 부분은 플러그인이 연결하지 않는 모든 것입니다.

관련 읽기

• Commerce Protocols for AI Agents: UCP, ACP, AP2, and MCP — How the Stack Fits Together — 이 플러그인이 보완하는 바이 사이드 프로토콜 스택: 발견, 체크아웃, 결제 위임, 그리고 B2B 시맨틱 레이어 갭
• More RFQs, Fewer Real Opportunities: A Sell-Side Qualification Layer for Agent-Generated Demand — 수요 측의 대응편: 에이전트가 인바운드를 생성할 때, 공급업체의 견적 팀이 그것을 자격 심사하는 방법
• Order Management: How an Agent Validates 1,800 B2B Orders a Week and Cuts the Error Rate from 12% to Under 2% — 마켓플레이스 너머의 셀 사이드 통합 레이어: 검증, 풀필먼트 라우팅, ERP 라이트백

대표적인 구축 사례

미드마켓 B2B 판매자가 자체 BigCommerce 스토어프론트와 NetSuite와 함께 Amazon을 운영하며, 운영팀은 한 채널의 에이전트가 한 일을 다른 시스템이 믿는 것과 대조할 수 없습니다. 구축은 시스템 인벤토리(Selling Partner 플러그인이 커버하는 표면, NetSuite와 BigCommerce가 노출하는 것), 워크플로 맵(가격 조정, 재고 동기화, 주문 접수), 그리고 고정된 범위로 시작합니다: 맞는 곳에는 퍼스트파티 플러그인, NetSuite와 BigCommerce용 커스텀 MCP 모듈, 그리고 쓰기의 범위를 지정하고 임계값을 초과하는 가격 변경에 작업별 승인을 요구하며 모든 에이전트 작업을 ERP와 컴플라이언스 워크플로 모두가 읽을 수 있는 감사 로그에 기록하는 오케스트레이션 정책. 첫 번째 통합 플로 — NetSuite 티어 목록을 확인하고 결정 추적을 다시 기록하는 Amazon의 가격 변경 — 는 5~8주 내에 라이브됩니다.

범위가 정해진 구축을 요청하세요. 1주 디스커버리. 시스템 인벤토리, 워크플로 맵, 고정 범위를 받습니다 — 우리와 함께 구축하든 아니든.