ChatGPT Merchants와 머천트 여정: 등록부터 책임까지

1. ChatGPT‑머천트란 무엇이며 “일반 쇼핑몰”과 무엇이 다른가

개발자 관점에서 보면 레이어를 혼동하기 쉽습니다. 우리에게는 Next.js 애플리케이션, MCP 서버, 어떤 commerce 백엔드가 있고, 그 어딘가에 OpenAI, ChatGPT, Stripe 같은 서비스들도 있습니다. 이렇게 말하고 싶어집니다: “어차피 전부 하나의 큰 시스템, 테스트만 모두 초록이면 OK.”

하지만 AI‑commerce 세계에서는 법적·기술적 경계가 매우 엄격하게 구분됩니다. ChatGPT는 당신의 상점이 되지 않으며 결제 프로세서로 변신하지도 않습니다. ChatGPT는 지능형 인터페이스를 제공하고 공개 스펙에 따라 당신의 API를 호출할 뿐입니다. 머천트로 남는 것은 구체적인 카탈로그를 가진 특정 회사이며, 사용자에 대한 책임도 그 회사가 집니다.

머천트의 역할 이해는 법무만의 일이 아닙니다. 여기에서 아키텍처 의사결정이 갈립니다: 피드 데이터를 어디에 저장할지, 주문을 어떻게 검증할지, 무엇을 로깅할지, 채팅에 표시된 내용과 실제 시스템에서 일어난 일을 어떻게 디버깅할지 등입니다.

예시

고전적 e‑commerce를 떠올려 봅시다. 웹사이트, 장바구니, 체크아웃, 결제 프로바이더 연동이 있습니다. 사용자는 브라우저로 들어와 클릭하고, 카드 정보를 입력합니다 — 익숙한 흐름입니다.

ChatGPT‑머천트는 같은 상점이지만, 높은 수준의 자동화를 갖춘 AI 대화를 통해 판매하는 법을 익힌 상점입니다. 차이는 무엇을 파느냐가 아니라, 사용자가 요청에서 결제까지 어떻게 이동하느냐입니다.

OpenAI의 관점에서 머천트는 다음을 수행하는 조직(또는 개인 사업자)입니다:

• OpenAI 스펙에 맞춘 Product Feed를 제공(CSV/TSV/XML/JSON로 SKU 구조화 데이터);
• ChatGPT Merchants 포털에 등록하고 카테고리 및 법적 요구사항 심사를 통과;
• 고급 옵션으로 Agentic Checkout과 Delegated Payment를 구현하여, ChatGPT의 Instant Checkout이 귀하의 사이트로 나가지 않고 결제를 수행할 수 있도록 함.

즉, 머천트는 “위젯을 만든 사람”이 아니라, 상품 구색과 재무적 의무의 소유자입니다. 이 강의에서 우리는 두 역할을 동시에 수행합니다. ChatGPT App으로서의 GiftGenius를 만드는 팀이자, 그 App을 서비스하는 머천트 백엔드를 만드는 팀입니다.

2. ChatGPT Merchants 포털: 신청부터 실전 머천트까지

OpenAI에는 판매자를 위한 별도 사이트 — 포털 ChatGPT Merchants 가 있습니다. 이를 통해 판매자는 Instant Checkout 프로그램에 참여하고 피드와 백엔드를 연결합니다. 여기서는 아직 깊은 기술 디테일 없이(다음 강의에서 다룹니다) 단계별로 훑어봅니다.

사전 준비

팀원 중 누군가가 “Apply” 버튼을 누르기 전에, 이미 준비되어 있어야 할 벽돌들이 있습니다:

법인(사업자)과 사이트. 머천트는 도메인과 사용자에게 명확한 스토어프론트를 가집니다 — 이후 모든 판매가 ChatGPT에서 이루어지더라도 OpenAI는 공개된 진열(사이트)을 기대합니다.

정책에 부합하는 상품 구성. 지난 강의에서 Prohibited Products Policy를 이야기했습니다. 예를 들어 무기나 일부 의료 제품은 금지됩니다. ChatGPT를 통해 판매하고 싶은 상품은 허용 카테고리 목록에 부합해야 합니다.

기본 결제 인프라. Delegated Payment 덕분에 카드 데이터를 직접 다룰 필요는 없지만, 반드시 PSP(예: Stripe)와의 통합이 있어야 하며, 자체 시스템에서 주문과 환불을 어떻게 생성하는지 이해하고 있어야 합니다.

Merchants 포털 신청

기술적으로는 다소 단순하지만 중요한 단계입니다. 사이트에 접속해 Instant Checkout 프로그램 참여 신청을 합니다. 일반적으로 다음을 묻습니다:

• 귀사 정보(법인, 사이트, 연락처);
• 판매 품목(카테고리, 가격대, 지역);
• Product Feed 제공 방식(포맷, URL, 업데이트 주기).

이 부분은 TypeScript와의 연관성은 적지만 로드맵에 큰 영향을 줍니다. 머천트가 기본 심사를 통과하기 전에는 코드가 완벽하더라도 Instant Checkout은 켜지지 않습니다.

Product Feed 연결

신청이 검토되어 대체로 합의되면, 기술적 초점은 Product Feed로 이동합니다. 문서에 따르면 피드는 통합에 필수입니다. 피드 없이는 ChatGPT가 무엇을 판매하는지 알 수 없습니다.

이 단계에서 여러분은 다음을 수행합니다:

1. 피드 포맷을 결정합니다(대부분 CSV 또는 JSON).
2. 전달 방식을 합의합니다: S3의 pre‑signed URL이나 주기적으로 업데이트를 POST하는 HTTPS 엔드포인트일 수 있습니다.
3. 각 SKU에 대한 최소 필드를 준비합니다: id, title, description, price, currency, availability, link, 이미지와 플래그 enable_search / enable_checkout.

여러분이 enable_checkout를 = false로 두는 동안, 머천트는 discovery‑only 모드로 동작할 수 있습니다. ChatGPT는 상품을 찾아 추천하지만, 사용자가 구매를 시도하면 여러분의 사이트로 이동시킵니다.

ACP 통합(다음 강의에서 자세히)

Product Feed가 안정적이고 다음 단계로 갈 준비가 되면 Agentic Checkout과 Delegated Payment 통합이 시작됩니다. Merchants 포털 관점에서는 별도의 요구사항 블록입니다. 엔드포인트 /checkout_sessions를 구현하고, 위임된 결제 토큰(Shared Payment Token)을 수신하며, 다음 상태로 세션을 올바르게 종료해야 합니다 (not_ready_for_payment, ready_for_payment, completed, canceled).

이 강의에서는 이를 “다음 난이도”로만 이야기합니다. 프로토콜 세부와 요청 스키마는 다음 강의에서 다룹니다.

3.5. 인증 및 Instant Checkout 활성화

마지막 단계는 실제 시나리오에서 여러분의 백엔드가 어떻게 동작하는지 검증하는 것입니다:

• 주문이 올바르게 생성되는가;
• 피드의 가격과 실제 청구 가격이 일치하는가;
• 오류와 환불이 제대로 처리되는가;
• 여러분의 ToS/Privacy 페이지가 OpenAI와 현지 법규의 기대에 부합하는가.

이후 머천트는 “Instant Checkout 준비 완료” 상태를 받고, enable_checkout = true 인 상품은 실제로 ChatGPT에서 바로 구매 가능해집니다.

전체 과정을 간단한 다이어그램으로 떠올릴 수 있습니다:

flowchart TD
  A[제품과 사이트가 있음] --> B[ChatGPT Merchants 신청]
  B --> C[Product Feed 연결됨]
  C --> D["ACP 백엔드 구현됨
(checkout_sessions + delegated payment)"]
  D --> E[인증
및 Instant Checkout 활성화]

3. 머천트 유형: Etsy/Shopify vs 커스텀 백엔드

좋은 소식: 모든 머천트가 ACP 백엔드를 직접 작성해야 하는 것은 아닙니다. 일부 플랫폼(Shopify, Etsy 등)은 기술 구현을 대신해 주는 통합이 이미 존재합니다.

Shopify나 Etsy를 통해 판매한다면 대략 이런 흐름입니다. “Show in ChatGPT”와 같은 옵션을 켜면, 플랫폼이 스스로:

• 필요한 포맷의 Product Feed를 생성·유지하고;
• ACP 엔드포인트를 구현하거나 프록시하며;
• Stripe 등 PSP와 연동합니다.

상점 소유자인 여러분은 REST 엔드포인트보다는 상품 구성과 설명에 더 집중하면 됩니다.

반면 이 강의의 GiftGenius처럼 자체 백엔드를 가진 커스텀 머천트를 구축한다면, 자유도는 크지만 할 일도 많습니다. 피드, 체크아웃, 결제 프로바이더 통합을 직접 구현해야 합니다.

비교를 표로 정리하면 편합니다:

강의에서는 의도적으로 세 번째 옵션을 선택합니다. 그래야 피드부터 webhook, 안정적인 프로덕션까지 전 과정을 밟아볼 수 있기 때문입니다.

4. 머천트의 책임: 데이터, 주문, 정책, 결제

ChatGPT 머천트가 되면 새로운 주문의 기쁨뿐 아니라 매우 구체적인 의무도 함께 떠안게 됩니다. 레이어별로 살펴보겠습니다.

카탈로그 데이터와 Product Feed 품질

Product Feed는 ChatGPT의 단일 진실 소스(source of truth)입니다. 피드에 상품 가격이 10 USD이고 재고가 있다고 적혀 있으면, 사용자는 채팅에서 바로 그것을 보게 됩니다. 피드가 사실과 다르면, 최선의 경우 불만족한 고객을 만나고, 최악의 경우 정책 위반과 OpenAI와의 문제로 이어질 수 있습니다.

머천트에게 기대되는 것은 다음과 같습니다:

• 필수 필드의 정확성(올바른 가격 포맷, ISO 통화 코드, 유효한 HTTPS 링크, 동작하는 이미지);
• 유령 재고를 팔지 않도록 충분히 자주 피드를 갱신할 것;
• 식별자 일관성: 피드의 SKU id는 내부 DB 및 주문 시스템의 ID와 일치해야 하며, 그래야 정확히 무엇이 구매되었는지 단번에 알 수 있습니다.

일반 e‑commerce와 비교하면, 여기서 Product Feed는 “마켓플레이스용 내보내기”와 같습니다. 다만 이 마켓플레이스는 웹사이트가 아니라, 사용자의 머릿속에서 살아가는 똑똑한 어시스턴트이며 불일치를 쉽게 기억한다는 점이 다릅니다.

주문, 배송, 환불

ChatGPT는 여러분 상점의 고객지원으로 변신하지 않습니다. 사용자는 ChatGPT와 대화하지만, 법적으로는 OpenAI가 아니라 머천트에게서 상품을 삽니다. 따라서:

• 주문이 여러분 시스템에서 생성되어 물류로 전달되는 것에 책임이 있습니다;
• Instant Checkout에서 사용자가 지정한 주소로 발송물이 도착하는 것에 책임이 있습니다;
• 환불, 취소, 부분 환불 등을 처리하는 것에 책임이 있습니다.

ACP에서는 성공적으로 완료된 checkout_session에 보통 order 객체가 포함됩니다. 하지만 이는 여러분 백엔드에서 일어난 일을 반영하는 것일 뿐입니다 — 실제로는 테이블 orders의 레코드를 어떻게 정의할지, 어떤 상태를 둘지, 물류와 어떻게 연동할지 여러분이 결정합니다.

정책과 지역

Merchants 포털에서 어떤 국가에 판매하고 어떤 유형의 상품을 다루는지 기재합니다. OpenAI는 다음을 확인합니다:

• 금지 카테고리를 판매하지 않는가;
• 현지 법규(예: 세금 규정, 연령 제한)를 준수하는가;
• 명확한 Terms of Service와 Privacy Policy를 제공하는가.

이후 모듈에서 법적 페이지를 다시 다루겠지만, 지금부터 “내가 무엇을 어디에 판매하는지 법무에게 설명할 수 없다면, ChatGPT가 대신 팔아주긴 어렵다”는 관점으로 생각하는 것이 유익합니다.

결제와 결제 프로바이더

마지막으로 가장 민감한 주제 — 돈입니다. 다행히 ACP와 Delegated Payment는 개발자의 삶을 크게 단순화합니다:

• ChatGPT와 결제 프로바이더(예: Stripe)가 특정 금액과 머천트에 대한 Shared Payment Token을 합의하고;
• 여러분의 백엔드는 complete 요청에서 이 토큰을 받아 PSP에서 사용하며, “원시” 카드 데이터는 보지 않습니다.

즉, PCI 준수의 괴물이 될 필요도, 카드 번호를 저장할 필요도, 감사의 악몽에 빠질 필요도 없습니다. 여러분의 책임은 위임 토큰을 올바르게 사용(결제 생성, 청구, 환불)하고, 정확하게 회계를 관리하는 것입니다.

5. GiftGenius 아키텍처에 어떻게 적용되는가

우리의 학습용 애플리케이션 GiftGenius로 돌아오겠습니다. 아키텍처 관점에서 14모듈 이후, 수강생이 다음 수준의 다이어그램을 그릴 수 있길 바랍니다: “사용자 → ChatGPT → App 위젯 → MCP Gateway → Product Feed / Agents / ACP backend”.

이 다이어그램에서 머천트의 역할은 우리의 백엔드가 수행하며, 위젯과 App은 ChatGPT에서 이 머천트의 “얼굴” 역할을 합니다.

코드에서 머천트 구성

간단한 단계부터 시작해 보겠습니다. 코드에 머천트 구성 구조를 만듭니다. 우리 Next.js 프로젝트의 TypeScript 모듈 lib/merchantConfig.ts로 하겠습니다:

// lib/merchantConfig.ts
export type MerchantConfig = {
  id: string;                // ACP/Stripe에서 머천트 ID
  name: string;              // 사람이 읽을 수 있는 이름
  feedUrl: string;           // Product Feed 위치
  instantCheckoutEnabled: boolean;
};

export const giftGeniusMerchant: MerchantConfig = {
  id: process.env.MERCHANT_ID ?? "dev-merchant",
  name: "GiftGenius",
  feedUrl: process.env.PRODUCT_FEED_URL ?? "https://example.com/feed.json",
  instantCheckoutEnabled: false, // 나중에 활성화
};

여기서 첫째, 우리는 경계를 명시합니다. 이것은 머천트이지 “위젯”이 아닙니다. 둘째, 중요한 값을 환경 변수로 뺍니다 — 배포와 환경 모듈에서 이런 값을 하드코딩하지 말아야 하는 이유를 여러 번 보게 될 것입니다.

편의를 위해 지금 Instant Checkout 사용 가능 여부를 알려주는 간단한 함수를 추가할 수 있습니다:

// lib/merchantConfig.ts
export function canUseInstantCheckout(cfg: MerchantConfig) {
  // dev와 staging에서는 항상 Instant Checkout 비활성화
  if (process.env.NODE_ENV !== "production") return false;
  return cfg.instantCheckoutEnabled;
}

이렇게 하면 환경에 따라 동작이 달라질 수 있음을 미리 반영하고, 자신(과 GPT)이 테스트 환경에서 실수로 실전 체크아웃으로 넘어가는 일을 방지할 수 있습니다.

MCP 도구로 머천트 정보 조회

모델과 위젯이 현재 머천트의 동작 모드를 알 수 있게 해두면 편리합니다. 예를 들어 Instant Checkout이 꺼져 있으면 GPT가 이를 제안하지 않도록 말이죠.

MCP 서버(지난 모듈에서 올렸던)에 간단한 도구를 추가할 수 있습니다:

// mcp/tools/merchant.ts
import { giftGeniusMerchant, canUseInstantCheckout } from "../lib/merchantConfig";

export const getMerchantInfoTool = {
  name: "get_merchant_info",
  description: "GiftGenius 머천트의 기본 정보를 반환합니다",
  inputSchema: { type: "object", properties: {}, additionalProperties: false },
  async handler() {
    return {
      id: giftGeniusMerchant.id,
      name: giftGeniusMerchant.name,
      instantCheckout: canUseInstantCheckout(giftGeniusMerchant),
    };
  },
};

이 도구는 대단한 일을 하지는 않지만, 모델이 “지금 채팅에서 바로 구매할 수 있는가, 아니면 링크로만 이동하는가?”를 물어볼 명시적인 지점을 만들어 줍니다.

위젯에서 머천트 정보 사용

위젯에서는 이미 익숙한 Apps SDK 훅을 사용해 get_merchant_info를 호출하고 모드에 따라 UI를 바꿀 수 있습니다. 가장 단순한 컴포넌트 예시는 다음과 같습니다:

// components/MerchantBadge.tsx
"use client";

import { useEffect, useState } from "react";
import { useCallTool } from "../lib/use-call-tool";

type MerchantInfo = { name: string; instantCheckout: boolean };

export function MerchantBadge() {
  const callTool = useCallTool();
  const [info, setInfo] = useState<MerchantInfo | null>(null);

  useEffect(() => {
    callTool("get_merchant_info", {}).then((res) => {
      setInfo(res?.result as MerchantInfo);
    });
  }, [callTool]);

  if (!info) return null;
  return (
    <span>
      {info.name} · {info.instantCheckout ? "Instant Checkout" : "Discovery only"}
    </span>
  );
}

이런 작은 컴포넌트는 사용자(그리고 개발 환경의 여러분)에게 지금 ChatGPT 통합이 어떤 상태인지 명확히 보여주는 데 유용합니다.

6. 실습형 미니 과제

강의가 “말과 다이어그램”에만 머물지 않도록, 여러분의 GiftGenius(또는 유사) 프로젝트에서 다음 단계를 시도해 보세요:

첫째, merchantConfig.ts와 유사한 머천트 구성 모듈을 추가하고 MERCHANT_ID와 PRODUCT_FEED_URL을 환경 변수로 분리하세요. 로컬 개발에는 .env.local을, 프로덕션에는 Vercel 또는 다른 플랫폼의 설정을 사용할 수 있습니다.

둘째, MCP 서버에 간단한 get_merchant_info 도구를 구현하여 최소한 name과 instantCheckout을 반환하게 하세요. 모델에 유용할 수 있는 다른 필드는 무엇일지 생각해 보세요. 예를 들어 지원 통화 목록이나 배송 가능 국가 등이 있습니다.

셋째, 이 도구를 사용해 현재 머천트 모드를 사용자에게 보여주는 작은 UI 요소(배지, 상태 줄, 상품 카드의 문구 등)를 위젯에 추가하세요. 이는 UX에 유익할 뿐 아니라 디버깅에도 큰 도움이 됩니다.

마지막으로, 여러분의 구체적인 프로젝트가 “사이트와 백엔드가 있음”에서 ChatGPT 머천트 상태까지 어떤 단계로 나아갈지 텍스트로 정리해 보세요. Product Feed는 어디에 연결할지, enable_checkout은 언제 켤지, ACP 엔드포인트 구현은 언제 시작할지 등입니다. 이런 연습은 팀을 정돈하고, 환불 정책 같은 중요하지만 미루기 쉬운 것들을 놓치지 않게 해줍니다.

7. ChatGPT 머천트로 가는 길에서 흔한 실수

오류 №1: “ChatGPT가 곧 내 상점이다”.
개발자가 모든 것을 ChatGPT 쪽으로 “이전”했다고 생각하는 경우가 종종 있습니다. 마치 카탈로그도 보관하고, 가격도 계산하고, 주문도 이행하는 것처럼요. 실제로 ChatGPT는 인터페이스이자 오케스트레이터이지, 여러분의 ERP가 아닙니다. 이를 잊으면 자체 주문 모델이 부실하고, 모든 데이터가 “어딘가 프롬프트”에 흩어져 있으며, 모델 동작이 조금만 바뀌어도 일관성이 무너지는 아키텍처를 만들기 쉽습니다.

오류 №2: 별도 등록과 ACP 없이 Instant Checkout을 기대.
멋진 위젯을 만들고 Product Feed를 설정했다고 해서 Instant Checkout이 자동으로 켜지지 않습니다. Merchants 포털 신청, 카테고리 심사, Agentic Checkout과 Delegated Payment 구현, 테스트 통과가 필요합니다. Instant Checkout이 “기본적으로 된다”는 가정은 보통 GPT가 실제로 존재하지 않는 기능을 제안하거나, 기대한 결제 화면 대신 링크만 주는 결과로 이어집니다.

오류 №3: 머천트 식별자와 URL의 하드코딩.
고전적 사례: MERCHANT_ID = "prod-123"가 코드에 박혀 있고, 피드 URL은 위젯 컴포넌트 문자열로 박혀 있습니다. 스테이징이 생기거나 두 번째 머천트를 만들 필요가 생기는 순간 대규모 “검색‑치환”이 시작됩니다. 이런 값은 구성과 환경 변수로 분리하고, MerchantConfig처럼 작은 추상화 레이어를 통해 사용하는 편이 훨씬 안전합니다.

오류 №4: 주문과 동기화되지 않은 Product Feed.
피드의 SKU GIFT_RED_MUG가 10 USD로 표시돼 있는데, 주문 DB에서는 같은 식별자에 12 USD를 청구한다면, 언젠가는 드러납니다. 가격과 재고의 진실 소스는 내부 데이터로부터 생성된 피드이거나, 피드와 체크아웃이 함께 신뢰하는 공통 레이어여야 합니다. ChatGPT용과 자사 사이트용으로 “이중 장부”를 시도하면 매우 빠르게 문제가 됩니다.

오류 №5: 결제 프로바이더의 역할과 결제 데이터 보관을 무시.
결제 프로바이더 토큰을 “엿보거나”, 자체 UI에서 추가로 결제 정보를 요구하고 싶은 유혹이 생길 수 있습니다. 이는 Delegated Payment 모델을 깨뜨릴 뿐 아니라, 여러분을 PCI DSS와 무거운 컴플라이언스 세계로 끌어들일 수 있습니다. 올바른 실무는 Shared Payment Token을 불투명한 문자열로 취급하고, 결제 프로바이더 SDK에서만 사용하며, 어디에도 로깅하거나 캐시하지 않는 것입니다.

오류 №6: 온보딩의 다단계성과 계획의 부재를 과소평가.
마지막으로 흔한 조직적 실수는 “그냥 ChatGPT에 붙이면 되잖아, 뭐가 어려워?”라고 생각하는 것입니다. 실제로 머천트 여정은 기술(피드, 백엔드, 테스트)과 비기술(법적 문서, 카테고리 합의, 지역 제한) 단계를 아우르는 다수의 단계로 이루어져 있습니다. 이 여정을 미리 정리하지 않으면 팀은 태스크 사이를 혼란스럽게 오가고, 마감은 AI‑commerce에 대한 영감보다 더 빠르게 “녹아내리기” 시작합니다.