AI‑commerce의 전체 그림과 OpenAI의 역할

1. AI‑commerce란 무엇인가

전통적인 e‑commerce가 “사이트에 들어가서 — 카탈로그를 열고 — 장바구니에 담고 — 세 가지 양식을 통과하는” 흐름이라면, AI‑commerce는 대화가 ChatGPT와의 핵심 인터페이스가 되는 세계입니다. 사용자는 자연어로 과제를 제시하고, ChatGPT 내부의 에이전트가 상담원, 머천다이저, 때로는 프로덕트 매니저 역할까지 수행합니다.

요청은 “category=양말&price_max=20”처럼 보이지 않고, “너무 오글거리지는 않지만 웃긴 선물을 동료에게 보낼 수 있게, 20달러 이하로 이메일로 전송 가능하게 골라줘”처럼 나타납니다. 에이전트는 과제를 해석하고, 필요한 질문을 던지고, 상품 카탈로그를 조회하며, 각 옵션의 장단점을 설명한 뒤 사용자를 구매까지 이끕니다. 이 모든 과정에서 사용자가 별도의 “장바구니” 페이지를 볼 필요는 없습니다.

아키텍처 관점에서 이 순간 ChatGPT App은 “똑똑한 선물 카탈로그”에서 커머스 애플리케이션으로 변모하며 다음을 수행할 수 있게 됩니다:

1. 사용자의 의도와 제약(예산, 선물 유형, 국가, 디지털/실물 상품)을 이해한다.
2. product feed에서 특정 SKU를 고르고 선택 이유를 설명한다.
3. 표준화된 프로토콜 ACP(Agentic Commerce Protocol)를 통해 구매 절차를 시작한다.

AI‑commerce의 핵심은 “catalog + checkout”이 별도의 사이트가 아니라 이미 GPT와 진행 중인 대화의 논리적 연속이 된다는 데 있습니다.

2. 전통적 e‑commerce vs AI‑commerce

차이를 더 잘 느끼려면 두 접근을 나란히 놓고 보는 것이 좋습니다. 아래는 단순화된 표로, 모든 것을 포괄하지는 않지만 패러다임 전환을 잘 드러냅니다.

실무적 결과로, AI‑commerce에서는 “카탈로그와 장바구니”의 비주얼 디자인보다 데이터의 구조와 품질, 그리고 ChatGPT, 여러분의 백엔드, 결제 제공자 간 형식적 프로토콜이 더 중요해집니다. Product feed와 ACP 엔드포인트는 위젯 자체만큼 중요한 “UI”가 됩니다.

전통적 쇼핑몰에서는 브라우저에서 일부 UX를 손볼 수 있지만, AI‑commerce에서는 모델이 여러분이 제공한 데이터와 스키마—상품 설명부터 체크아웃 세션 상태까지—에 거의 전적으로 의존합니다.

3. OpenAI Commerce의 구성 블록

OpenAI는 모든 것을 알아서 처리하는 “마법의 결제 시스템 GPTPay”를 제공하지 않습니다. 그 대신, 기존 머천트와 결제 제공자를 ChatGPT 세계에 올바르게 연결하는 방법을 설명하는 사양과 가이드 모음이 있습니다. 이 문서들 가운데 특히 중요한 네 가지 벽돌이 있습니다.

첫째, Product Feed Specification입니다. 이는 판매자가 상품 카탈로그를 기술하는 공식 형식으로, id, title, description, 가격, 통화, 재고, 이미지 등으로 구성됩니다. 피드는 OpenAI가 검증하고 인덱싱하며, ChatGPT 내부에서 검색, 랭킹, 체크아웃에 사용하는 구조화된 source of truth 역할을 합니다.

둘째, Agentic Checkout Specification입니다. 이는 checkout_session 엔티티로 작업하기 위한 REST 계약입니다. 이 API는 결제 세션을 생성하고(예: 주소나 배송 옵션 변경 시) 업데이트하며 완료하는 방법, 그리고 백엔드가 반환해야 할 필드(합계, 세금, 이행(fulfillment) 옵션, 환불 정책 링크 등)를 정의합니다.

셋째, Delegated Payment Specification입니다. 이는 에이전트 플랫폼(ChatGPT)이 결제 제공자(예: Stripe Shared Payment Token)로부터 위임된 결제 토큰을 받고 실제 결제 정보는 노출하지 않은 채 여러분의 백엔드로 전달하는 프로토콜입니다. 토큰은 금액 한도, 수명 등으로 제한되며, 여러분의 백엔드가 PSP에서 실제 결제를 생성할 때 사용됩니다.

마지막으로, ChatGPT의 Instant Checkout은 위 사양 위에 올라가는 UX 레이어입니다. 채팅 안에 컴팩트한 체크아웃 인터페이스(선택한 상품, 가격, 주소, 결제 수단)가 나타납니다. 내부적으로는 Product Feed를 기반으로 하고, Agentic Checkout Spec에 따라 여러분의 /checkout_sessions를 호출하며, PSP에서 거래를 처리하기 위해 Delegated Payment를 사용합니다.

좋은 소식은 이 모든 것이 “ChatGPT의 비밀 API”가 아니라 ACP(Agentic Commerce Protocol)라는 공개 사양이라는 점입니다. 즉, 동일한 백엔드는 ACP를 지원하는 다른 AI 플랫폼과도 이론적으로 호환될 수 있습니다.

4. 역할과 책임 범위

이제 진짜 흥미로운 부분입니다. 시스템에 돈이 흐르기 시작하면 규제 기관과 법무팀이 갑자기 최고의 친구가 됩니다. 혼선을 피하려면 역할을 명확히 구분하는 것이 중요합니다.

가장 중요한 역할은 에이전트 플랫폼, 즉 여기서는 ChatGPT입니다. 플랫폼은 사용자 경험—채팅, 위젯, Instant Checkout UI—을 소유합니다. 플랫폼은 커머스 플로우를 시작하고, Product Feed에서 상품을 선택하며, 여러분의 ACP 엔드포인트를 호출해 결과를 사용자에게 보여줍니다. 하지만 ChatGPT는 상품의 소유자도, 결제 제공자도 아니며, 여러분의 product 데이터를 “자기 카탈로그”로 저장하지도 않습니다. 여러분이 제공한 피드를 그대로 사용합니다.

두 번째 역할은 머천트(seller, merchant‑of‑record)입니다. 상품 또는 서비스의 소유자이며, product feed(구조, 품질, 가격과 재고의 최신성), ACP 엔드포인트(/checkout_sessions, webhooks)의 올바른 구현, 주문 생성과 보관, 배송, 지원, 환불을 책임집니다. ACP 문서는 법적 의미에서 판매자 기록(merchant of record)은 에이전트 플랫폼이 아니라 머천트임을 강조합니다.

세 번째 역할은 결제 제공자(PSP)입니다. 예로 Stripe가 있습니다. PSP는 결제 처리, PCI DSS 등 요건 준수, 결제 정보 보관, 사기 방지 및 차지백 대응을 책임집니다. Delegated Payment 컨텍스트에서 PSP는 에이전트 플랫폼에 특수 토큰(SPT)을 발급하고, 이 토큰은 여러분의 서버에서 실제 결제(예: Stripe의 PaymentIntent)를 생성하는 데 사용됩니다.

네 번째이자 가장 중요한 역할은 사용자입니다. 사용자는 과제를 정의하고, 최종적으로 구매를 결정하며, 결제에 동의하고, 이상적으로는 여러분이 체크아웃 UI에서 성실히 보여주는 약관/개인정보처리방침을 읽습니다. Product feed에는 이러한 문서와 환불 정책에 대한 링크를 포함할 수 있어 신뢰와 투명성을 높일 수 있습니다.

편의를 위해 작은 표로 정리해 봅시다:

책임 분리는 법무뿐 아니라 아키텍처에도 중요합니다. 예를 들어 내일 두 번째 PSP를 연결하더라도 ChatGPT App을 다시 작성할 필요는 없습니다. 여러분의 백엔드에서 Delegated Payment 레이어만 적응시키면 됩니다. ACP를 이해하는 두 번째 AI 플랫폼이 등장한다면, product feed와 체크아웃 엔드포인트도 재사용할 수 있습니다.

5. “모두 대화 안에서” 진행되는 구매 시나리오는 어떻게 보이나요

이제 모든 것을 합쳐, 아키텍처 관점에서 ChatGPT에서 디지털 선물을 구매하는 end‑to‑end 시나리오를 살펴보겠습니다. 단순화한 버전이지만 핵심을 반영합니다.

sequenceDiagram
  participant U as 사용자
  participant C as ChatGPT
  participant G as GiftGenius App
  participant B as 머천트 백엔드
  participant P as PSP (Stripe)

  U->>C: "50달러 이하 디지털 선물을 사줘"
  C->>G: callTool(find_gifts, budget<=50)
  G->>B: GET /catalog?budget_lte=50
  B-->>G: 적합한 SKU 목록
  G-->>C: 선물 옵션 + 메타데이터
  C-->>U: 선정 이유 설명, 옵션 제안
  U->>C: "이걸로 살게"
  C->>B: POST /checkout_sessions (sku, price...)
  C->>P: 결제 토큰(SPT) 요청
  C->>B: POST /checkout_sessions/{id}/complete (token)
  B->>P: 결제 실행
  B-->>C: 주문 생성 webhook
  C-->>U: 구매 확인

ACP 관점에서 요약하면 다음과 같습니다:

1. 에이전트가 Product Feed(여러분의 백엔드를 통해)를 사용해 적합한 SKU를 고릅니다.
2. “구매하자”로 결정되면 ChatGPT가 Agentic Checkout Spec에 따라 여러분의 /checkout_sessions를 통해 checkout_session을 생성합니다.
3. Instant Checkout 동안 ChatGPT는 PSP에 특정 금액과 머천트에 대한 위임 결제 토큰을 요청합니다.
4. 이 토큰은 POST /checkout_sessions/{id}/complete로 전달되며, 여러분의 백엔드는 PSP에서 결제를 생성하고 주문을 만듭니다.
5. 주문이 준비되면 여러분의 서버가 webhook으로 OpenAI에 알리고, 이후 사용자는 최종 확인을 보게 됩니다.

이 강의에서 중요한 것은 엔드포인트 이름을 외우는 게 아니라 구조를 파악하는 것입니다: 피드 → SKU 선택 → checkout_session → 결제 → 주문 → webhook. 다음 강의들에서는 피드 필드, 체크아웃 세션 필드, 위임 결제 형식을 포함해 각 부분을 개별적으로 다룰 예정입니다.

6. GiftGenius: 우리 App은 AI‑commerce에서 어디에 맞물리나

지금까지 GiftGenius는 “선물 추천 어시스턴트” 역할을 해왔습니다. 할 수 있었던 일은:

• 사용자에게 누구에게, 어떤 이유로 선물이 필요한지 물어보기;
• MCP 도구로 자체 카탈로그를 검색하기;
• 위젯에서 카드 형태로 옵션을 보여주고 팔로업 버튼을 채팅에 보내기.

커머스 관점에서 이는 실제 구매 없이 “똑똑한 디스커버리”였습니다. OpenAI 커머스 세계에서 이 모드는 다음과 같은 피드에 대응합니다: enable_search = true, 하지만 enable_checkout = false: 상품은 찾고 논의할 수 있지만 Instant Checkout은 비활성화된 상태입니다.

AI‑commerce 모듈에서는 GiftGenius를 점차 완전 통합 머천트로 전환할 것입니다:

• OpenAI 사양에 맞춘 구조화된 Product Feed를 추가하고,
• checkout_sessions로 동작하는 ACP 백엔드를 설계하며,
• Stripe Shared Payment Token을 통한 Delegated Payment를 연결하고,
• 사용자에게 채팅 안에서 추천뿐 아니라 바로 구매까지 가능함을 알리도록 App을 개선합니다.

이 모든 것이 “블랙 매직”처럼 보이지 않도록, 커머스 플로우의 역할과 단계를 명시적으로 모델링하는 작은 기술 레이어를 코드에 추가해 봅시다. 이는 로그와 내부 테스트에 모두 유용합니다.

// app/commerce/types.ts
export type CommerceRole = "user" | "chatgpt" | "merchant" | "psp";

export interface CommerceStep {
  id: string;
  role: CommerceRole;
  description: string;
}

이 타입들은 TypeScript 수준에서도 “누가 무엇을 하는지”를 머릿속에서 분리하는 데 도움을 줍니다. 예를 들어 테스트나 위젯 내부의 디버그 UI에서 사용할 수 있습니다.

“50달러 이하 디지털 선물” 시나리오를 위한 작은 단계 배열 예시:

// app/commerce/exampleFlow.ts
import type { CommerceStep } from "./types";

export const digitalGiftFlow: CommerceStep[] = [
  { id: "intent", role: "user", description: "요청과 예산을 정한다" },
  { id: "search", role: "chatgpt", description: "Product Feed에서 SKU를 고른다" },
  { id: "checkout", role: "merchant", description: "checkout_session을 생성한다" },
  { id: "payment", role: "psp", description: "토큰으로 결제를 수행한다" }
];

이 코드는 아직 네트워크와 통신하지 않지만, 다음 강의에서 실제 ACP 코드를 확장해 갈 “좌표축”을 유용하게 만들어 줍니다.

7. 미니 과제: “50달러 이하 디지털 선물을 사줘” 플로우를 분해해 보세요

강의 말미에는 방금 다룬 내용을 직접 손으로 정리해 보는 것이 좋습니다. 사용자 요청:

“50달러 이하 디지털 선물을 나에게 사줘”.

과제 — 이후에 일어나는 일을 3–5개의 논리적 단계로 기술하고, 각 단계가 누가 수행하는지( ChatGPT, 여러분의 머천트 백엔드, 결제 제공자, 사용자 )를 지정하세요. 위의 다이어그램이나 digitalGiftFlow 배열을 참고해도 되지만, 반드시 1:1로 일치할 필요는 없습니다.

예를 들어 ChatGPT가 요청을 해석하고 사용자에게 세부 정보를 확인하는 단계(디지털 기프트카드, 수신자 지역, 선물 대상)를 시작으로, 여러분의 백엔드가 Product Feed로 적합한 SKU를 찾는 단계, 이어서 checkout_session 생성, PSP로부터 결제 토큰 수령, 구매 완료 단계로 이어질 수 있습니다.

원한다면, 이걸 코드를 통해 바로 표현해 digitalGiftFlow에 몇 가지 단계를 더 추가하고, 위젯의 작은 디버그 컴포넌트에서 렌더링해도 됩니다. 이런 연습은 “코드”뿐 아니라 프로토콜 속 역할까지 함께 사고하는 습관을 길러 줍니다.

아래는 그런 “플로우 계획”을 받아 로깅하는(아직 실제 커머스는 없는) 간단한 API 엔드포인트 예시입니다:

// app/api/commerce/flow/route.ts
import { NextRequest, NextResponse } from "next/server";
import type { CommerceStep } from "@/app/commerce/types";

export async function POST(req: NextRequest) {
  const steps = (await req.json()) as CommerceStep[];
  console.log("Planned AI-commerce flow:", steps);
  return NextResponse.json({ ok: true, stepsCount: steps.length });
}

실제 환경에서는 console.log 대신 구조화 로그를 쓰고, 이러한 시나리오를 문서나 테스트의 일부로 보관할 수도 있습니다. 하지만 이런 작은 예시만으로도 추상적 아키텍처를 여러분의 Next.js 애플리케이션의 구체적인 TypeScript 코드와 연결하는 데 도움을 줍니다.

이 강의에서 정리한 역할의 큰 그림을 머릿속에 두면, 이후 기술 세부—Product Feed 필드, 체크아웃 세션 스키마, 위임 결제 구조—도 “전능한 GPT”라는 불필요한 로망 없이 훨씬 수월하게 받아들일 수 있을 것입니다.

8. AI‑commerce와 역할에 대한 흔한 오해

오류 1: “ChatGPT가 알아서 다 해줄 것”이라고 생각하기.
일부 개발자는 “Stripe만 연결하고 모델에 API 접근을 주면” GPT가 알아서 처리할 것이라 생각합니다. 실제로 ChatGPT를 둘러싼 AI‑commerce는 Product Feed, Agentic Checkout, Delegated Payment라는 형식적 사양에 의존합니다. 상품을 구조화된 피드로 기술하지 않고, /checkout_sessions를 구현하지 않았으며, Delegated Payment를 구성하지 않았다면 어떤 모델도 이를 대신 만들어 주지 않습니다.

오류 2: ChatGPT와 머천트의 역할을 혼동하기.
또 다른 흔한 혼동은 ChatGPT가 “상점”이 되고 여러분은 “카탈로그만 연결”한다고 여기는 것입니다. 실제는 정반대입니다. 여러분이 머천트로 남고, product feed를 보관하며, 주문을 생성·처리하고, 환불을 담당합니다. ChatGPT는 오직 대화 UX와 여러분의 ACP 엔드포인트를 올바르게 호출하는 일만 책임집니다. 시스템을 “GPT가 구독을 나눠 주고 상품을 직접 보내 준다”는 전제로 설계하면, 결국 법적·기술적 막다른 길에 다다르게 됩니다.

오류 3: 결제 제공자를 별도 엔터티로 보지 않기.
때로 PSP를 백엔드 내부에 “숨겨” 놓고 일반 REST‑API처럼 다루고 싶어집니다. 하지만 결제 레이어는 PCI, 사기 방지, 차지백, 한도 등 고유한 규칙으로 움직입니다. ACP 접근에서 Delegated Payment Spec이 따로 존재하는 데에는 이유가 있습니다. 에이전트 플랫폼은 PSP와 자신의 레벨에서 통신해 SPT 토큰을 받고 이를 여러분에게 전달하며, 여러분이 결제를 생성합니다. 이 스킴을 우회해 App에서 카드 정보를 직접 받으려 하면, 컴플라이언스 요구사항으로 곧바로 발목을 잡히게 됩니다.

오류 4: product feed를 “마케팅 설정”으로만 보고 LLM을 위한 API로 보지 않기.
Google Shopping 배경을 가진 분들은 피드를 광고 계정보다 코드와 덜 관련된 것으로 보는 경향이 있습니다. AI‑commerce 세계에서 피드는 사실상 모델을 위한 여러분의 어셋 지식 베이스입니다. 이미지 링크가 깨져 있거나, 속성이 일관되지 않거나, 단위가 제각각이거나, 사실 대신 마케팅 과장이 들어가 있으면, 모델은 원치 않는 제안을 하고 전환율은 떨어집니다.

오류 5: Instant Checkout을 “원샷”으로 도입하려 하기.
유혹은 큽니다. “enable_checkout만 바로 켜서 사용자가 채팅에서 구매하게 하자.” 하지만 좋은 디스커버리(양질의 피드), 견고한 체크아웃 백엔드, 신중한 PSP 통합 없이 밀어붙이면, 주문의 절반이 중간에 멈추는 취약한 시스템을 얻게 됩니다. OpenAI가 제안하는 단계별 접근—먼저 양질의 Product Feed, 다음으로 ACP 엔드포인트 디버깅, 그다음 Delegated Payment, 마지막으로 프로덕션에서 Instant Checkout 활성화—을 따르는 것이 훨씬 합리적입니다.