에이전트 준비 완료된 커머스(Agent-Ready Commerce), 파트 1: AI 시대를 위한 플랫폼 구축

AI 에이전트(AI agents)가 커머스 소프트웨어의 전제 조건을 바꾸기 시작했습니다.

오랫동안 이커머스(ecommerce) 플랫폼은 인간의 해석을 중심으로 설계되었습니다. 제품 페이지에는 구조화된 데이터(structured data), 마케팅 문구, 정책 파편, 신뢰 신호, 가격 정보, 재고 상태 표시기, 그리고 결제를 위한 호출 문구(calls to action)가 혼합되어 포함될 수 있었습니다. 인간 사용자는 이러한 혼합된 정보를 충분히 잘 해석하여 의사결정을 내릴 수 있었습니다.

하지만 그 모델은 에이전트 중심의 커머스(agentic commerce)로 깔끔하게 전이되지 않습니다.

AI 에이전트가 커머스 시스템과 상호작용할 때, 모호함은 시스템 설계의 문제가 됩니다. 에이전트는 특정 제품을 추천할 수 있는지, 재고가 신선한지, 특정 정책이 적용되는지, 결제가 허용되는지, 또는 결제 권한이 존재하는지 등을 추론할 필요가 없어야 합니다. 이러한 결정 사항들은 플랫폼에 의해 명시적으로 표현되어야 합니다.

이 글은 에이전트 준비 완료된 커머스 플랫폼을 설계하는 것에 관한 기술 시리즈의 첫 번째 파트입니다. 초점은 이커머스 UI에 챗봇(chatbot)을 추가하는 것이 아닙니다. 초점은 외부 에이전트, 도구(tools), 그리고 프로토콜(protocols)이 커머스 워크플로(workflows)와 안전하게 상호작용해야 할 때 요구되는 더 낮은 수준의 아키텍처(architecture)에 있습니다.

플랫폼 경계가 변화하고 있습니다

전통적인 이커머스 플랫폼은 주로 페이지와 사용자 주도 흐름(user-driven flows)을 통해 경험을 노출합니다:

제품 페이지 → 장바구니 → 결제 → 결제 완료 → 주문

이 흐름은 인간이 프로세스를 주도한다는 것을 가정합니다. 플랫폼은 정보를 제시하고, 사용자는 이를 해석하며, 사용자가 다음에 무엇을 할지 결정합니다.

에이전트 중심의 커머스는 다른 상호작용 모델을 도입합니다. 시스템은 다음과 같은 질문에 답해야 할 수도 있습니다:

• 에이전트가 발견할 수 있는 제품은 무엇인가?
• 어떤 제품 정보(product facts)가 사용하기에 충분히 최신인가?
• 특정 제품, 지역 또는 결제(checkout) 컨텍스트에 적용되는 정책은 무엇인가?
• 제품에 대해 허용되는 동작(actions)은 무엇인가?
• 결제 준비(checkout preparation)가 허용되는가?
• 위임된 결제(delegated payment)가 허용되는가?
• 해당 동작에 인간의 확인(human confirmation)이 필요한가?
• 어떤 근거(evidence)가 해당 결정을 뒷받침하는가?
• 에이전트가 동일한 명령을 재시도할 경우 어떤 일이 발생해야 하는가?

이것들은 단순한 API 설계 질문이 아닙니다. 이는 도메인 모델링 (domain modeling) 질문입니다.

에이전트 준비 완료된 커머스 (agent-ready commerce)를 위한 더 유용한 사고 모델 (mental model)은 다음과 같습니다:

사실 (Facts) → 적격성 (Eligibility) → 권한 (Authority) → 상태 전이 (State transition) → 근거 (Evidence) → 감사 (Audit)

이 모델은 페이지 기반의 이커머스 (ecommerce) 흐름보다 덜 익숙할 수 있지만, 주요한 아키텍처 변화 (architectural shift)를 포착합니다. 에이전트와 상호작용하는 커머스 플랫폼은 제품과 엔드포인트 (endpoints) 그 이상을 노출해야 합니다. 상업적 동작 (commercial actions)이 유효한 조건들을 노출해야 합니다.

제품 데이터는 상업적 진실 (commercial truth)과 같지 않습니다

일반적인 첫 번째 단계는 구조화된 제품 피드 (product feed)를 노출하는 것입니다. 이는 필요하지만 불충분합니다.

기본적인 제품 레코드 (product record)는 다음과 같을 수 있습니다:

type Product = {
  id: string;
  name: string;
...

이 구조는 스토어프런트 (storefront)를 렌더링하거나 카탈로그 (catalog)를 인덱싱하는 데 유용합니다. 하지만 제품을 추천할지, 비교할지, 장바구니에 담을지, 또는 결제 흐름 (checkout flow)에서 사용할지를 결정하는 에이전트에게는 충분하지 않습니다.

누락된 계층은 상업적 진실 (commercial truth)입니다. 즉, 상업적 객체로서의 제품에 대해 플랫폼이 현재 보유하고 있는, 출처가 확인된 (source-backed) 이해입니다.

예를 들어:

type ProductTruthSummary = {
  productId: string;
  priceFreshness: "fresh" | "stale" | "unknown";
...

이 구조는 가공되지 않은 제품 데이터 (raw product data)를 에이전트 대상의 의사결정에 해당 데이터를 사용하는 데 필요한 신뢰도 및 완전성과 분리합니다.

제품이 카탈로그에는 존재할 수 있지만, 여전히 에이전트의 탐색 (discovery)에는 부적합할 수 있습니다. 제품이 탐색은 가능하지만 결제 준비 (checkout-ready)가 되어 있지 않을 수도 있습니다. 제품이 결제 준비는 되어 있지만 위임 결제 (delegated payment) 대상이 아닐 수도 있습니다. 제품의 가격은 최신이지만 재고 정보는 오래되었을 수도 있습니다. 제품의 재고는 유효하지만 반품 정책 (return-policy) 커버리지가 누락되었을 수도 있습니다.

사람은 종종 이러한 불일치 사항을 우회하여 작업할 수 있습니다. 하지만 에이전트는 그럴 필요가 없어야 합니다.

이것이 에이전트 준비 완료된 커머스 (agent-ready commerce)의 첫 번째 주요 설계 원칙입니다:

에이전트에게 프레젠테이션 레이어 (presentation surfaces)로부터 상업적 진실 (commercial truth)을 추론하도록 요구하지 마십시오.
상업적 진실을 직접 노출하십시오.

가용성 (Availability)은 너무 광범위합니다

많은 이커머스 (ecommerce) 시스템은 제품 가용성 (product availability)을 광범위한 관문으로 사용합니다. 제품이 활성화되어 있고, 재고가 있다면, 따라서 가용하다고 판단하는 방식입니다.

에이전트의 행동이 더 구체화되면 이러한 접근 방식은 무너집니다.

간단한 구현 사례를 살펴보겠습니다:

function canCheckout(product: Product) {
  return product.active && product.inStock;
}

이 함수는 좁은 범위의 질문에 답하지만, 플랫폼은 보통 다음과 같은 여러 가지 서로 다른 질문에 답해야 합니다:

• 제품이 에이전트에게 보이는 카탈로그에 나타날 수 있는가?
• 제품을 대안 상품들과 비교할 수 있는가?
• 에이전트가 해당 제품에 대한 정책을 인용할 수 있는가?
• 에이전트가 제품을 장바구니에 담을 수 있는가?
• 에이전트가 결제를 준비할 수 있는가?
• 에이전트가 결제를 위임할 수 있는가?
• 제품에 사람의 확인이 필요한가?

이러한 행동들은 동일한 리스크 프로필 (risk profile)을 갖지 않습니다. 이들을 하나의 가용성 결정으로 취급하는 것은 모델을 너무 거칠게 (coarse) 만듭니다.

더 명시적인 행동 모델 (action model)이 추론하기에 더 쉽습니다:

type AgentCommerceAction =
  | "discover"
  | "compare"
...

그러면 각 행동은 자체적인 결정을 생성할 수 있습니다:

type ActionEligibilityDecision = {
  productId: string;
  action: AgentCommerceAction;
...

중요한 점은 정확한 TypeScript 형태가 아닙니다. 중요한 점은 관심사의 분리 (separation of concerns)입니다.

제품은 탐색(discover)하기에는 안전하지만, 구매하기에는 안전하지 않을 수 있습니다. 정책 정보(policy facts)가 불완전하기 때문에 비교하기에는 안전하지만 견적(quote)을 내기에는 안전하지 않을 수 있습니다. 결제 준비(prepare checkout) 단계까지는 안전할 수 있지만, 결제 권한이 확립되지 않았기 때문에 위임된 결제(delegated payment)에는 안전하지 않을 수 있습니다.

이는 에이전트(agent)에게는 더 신뢰할 수 있는 인터페이스를, 판매자(merchant)에게는 더 유용한 운영 모델을 제공합니다.

플랫폼은 일반적인 거절 메시지를 반환하는 대신, 다음과 같이 이유를 반환할 수 있습니다:

제품은 탐색 가능하지만, 재고 최신성(inventory freshness)이 오래되어 결제가 차단되었습니다.

이러한 종류의 응답은 에이전트와 운영자 모두에게 유용합니다. 에이전트는 진행하지 말아야 함을 알게 되고, 운영자는 무엇을 수정해야 하는지 알게 됩니다.

정책은 구조화된 사실(structured facts)이 되어야 합니다

정책 텍스트(Policy text)는 인간 중심의 가정이 시스템으로 흘러 들어오는 또 다른 영역입니다.

인간은 반품 페이지를 읽고 제품이 보장 범위에 포함될 가능성이 있는지 해석할 수 있습니다. 하지만 에이전트는 상업적 조건(commercial terms)을 견적 낼 때 자유 형식의 텍스트(free-text) 해석에 의존해서는 안 됩니다.

정책 데이터는 제품, 카테고리, 시장 및 작업(actions)과 연결되어야 합니다.

단순화된 정책 사실(policy fact)은 다음과 같은 형태일 수 있습니다:

type PolicyFact = {
  policyType: "returns" | "shipping" | "warranty" | "cancellation";
  appliesTo: {
...

이를 통해 플랫폼은 그렇지 않으면 모호한 정책 텍스트로 뭉뚱그려질 여러 조건들을 구분할 수 있는 방법을 갖게 됩니다:

• 정책이 알려져 있으며 제품에 적용됨.
• 정책이 존재하지만 최신 상태가 아님(stale).
• 정책이 존재하지만 구매자의 지역에는 적용되지 않음.
• 두 개의 정책 소스가 충돌함.
• 제품에 필수적인 정책 보장 범위가 누락됨.
• 정책을 인간에게 보여줄 수는 있지만, 에이전트가 견적을 내서는 안 됨.

이러한 구분은 매우 중요합니다. 왜냐하면 잘못된 정책 주장(policy claim)은 단순한 기술적 버그에 그치지 않기 때문입니다. 이는 고객 지원 문제, 신뢰 문제 또는 규정 준수(compliance) 문제로 이어질 수 있습니다.

따라서 에이전트 준비 완료된(Agent-ready) 시스템은 정책 사실을 스토어프런트(storefront)에 부착된 정적 콘텐츠가 아니라, 커머스 도메인의 일부로 취급해야 합니다.

프로토콜 어댑터(Protocol adapters)는 가볍게 유지되어야 합니다

에이전트 커머스 플랫폼(Agent-commerce platforms)은 여러 외부 프로토콜 인터페이스(protocol surfaces)와 상호작용할 가능성이 높습니다. 어떤 프로토콜은 상품 검색(product discovery)에 집중하고, 어떤 것은 도구 사용(tool use)에 집중합니다. 또 어떤 것은 결제(checkout)나 결제 권한(payment authority)에 집중할 수도 있습니다. 또한 마켓플레이스, 어시스턴트, 결제 제공업체 또는 에이전트 런타임(agent runtime)에 특화된 프로토콜일 수도 있습니다.

흔히 발생하는 아키텍처 설계 오류는 각 프로토콜 어댑터(protocol adapter)가 스스로 비즈니스 결정(business decisions)을 내리도록 방치하는 것입니다.

예를 들어:

ACP 라우트가 결제 적격성(checkout eligibility)을 결정
MCP 도구가 상품 가시성(product visibility)을 결정
결제 어댑터가 위임 유효성(mandate validity)을 결정
...

이러한 구조는 일시적으로는 작동할 수 있지만, 모순을 야기하는 경향이 있습니다. 한 인터페이스에서는 상품이 사용 가능하다고 말하는데, 다른 인터페이스에서는 차단되었다고 말합니다. 관리자 UI(admin UI)는 세 번째 상태를 보여주고, 피드 게시자(feed publisher)는 네 번째 규칙을 사용합니다.

더 안전한 아키텍처는 어댑터를 가볍게(thin) 유지하는 것입니다:

외부 프로토콜 (External protocol)
        ↓
프로토콜 어댑터 (Protocol adapter)
...

어댑터는 외부 프로토콜 형태(external protocol shape)와 내부 도메인 형태(internal domain shape) 사이를 번역하는 역할을 합니다. 어댑터가 핵심 결정(core decision)을 소유해서는 안 됩니다.

이러한 분리는 에이전트 커머스 프로토콜이 여전히 진화하고 있는 단계에서 특히 중요합니다. 도메인 모델(domain model)이 프로토콜 어댑터로부터 독립되어 있다면, 비즈니스 규칙을 다시 작성하지 않고도 새로운 프로토콜 버전을 지원할 수 있습니다.

그러면 플랫폼은 다음과 같은 질문에 대해 하나의 내부적인 답변을 유지할 수 있습니다:

• 상품을 검색할 수 있는가?
• 결제가 허용되는가?
• 위임된 결제(delegated payment)가 허용되는가?
• 어떤 차단 요소(blockers)가 적용되는가?
• 어떤 증거(evidence)가 그 결과를 뒷받침하는가?

여러 프로토콜이 서로 다른 형식으로 그 답변을 노출할 수는 있지만, 결정권은 도메인(domain)이 소유합니다.

결제(Checkout)는 단일 동작이 아니라 라이프사이클(lifecycle)입니다

결제는 종종 UI의 버튼으로 표현되지만, 백엔드 시스템은 이미 결제가 하나의 라이프사이클임을 알고 있습니다. 에이전트 커머스(Agentic commerce)는 그 라이프사이클을 더욱 명시적으로 만듭니다.

결제 세션(checkout session)은 여러 상태를 거쳐야 할 수도 있습니다:

type CheckoutState =
  | "draft"
  | "validated"
...

각 전이 (transition)에는 조건이 있습니다. 가격, 재고, 정책 제약 조건이 확인되지 않는 한 초안 (draft) 세션은 검증된 (validated) 상태로 전환되어서는 안 됩니다. 필요한 권한 (authority)이 존재하지 않는 한 세션은 결제 승인 (payment authorization) 단계로 이동해서는 안 됩니다. 완료된 (completed) 세션은 일반적으로 종단 상태 (terminal state)여야 합니다. 반복된 명령 (repeated command)은 안전하게 처리되어야 합니다.

전이 기록 (transition record)은 라이프사이클 (lifecycle)을 감사 가능 (auditable)하게 만듭니다:

type CheckoutTransition = {
  from: CheckoutState;
  to: CheckoutState;
...

핵심 설계 포인트는 에이전트 (agents)가 커머스 상태를 임의로 변경할 수 없도록 해야 한다는 점입니다. 에이전트는 명령 (commands)을 제출해야 하며, 플랫폼은 요청된 전이가 유효한지 여부를 결정해야 합니다.

그 결정은 사실 관계 (facts), 자격 (eligibility), 권한 (authority), 그리고 현재 상태 (current state)에 따라 달라집니다.

이는 체크아웃 (checkout)이 다음과 같은 광범위한 아키텍처 패턴의 좋은 예시임을 보여줍니다:

에이전트 요청 (Agent request) → 명령 검증 (Command validation) → 권한 확인 (Authority check) → 상태 전이 (State transition) → 증거 기록 (Evidence record)

결제 권한 (Payment authority)은 별도의 도메인입니다

결제 권한은 모호한 모델이 위험해질 수 있는 영역 중 하나입니다.

사람이 주도하는 체크아웃 흐름 (human-driven checkout flow)에서 사용자는 일반적으로 최종 장바구니를 확인하고 직접 결제를 승인합니다. 에이전트가 주도하거나 에이전트의 도움을 받는 흐름 (agent-driven or agent-assisted flow)에서는 플랫폼이 에이전트가 가진 권한이 무엇인지에 대해 더 정밀해야 합니다.

paymentAllowed와 같은 불리언 (boolean) 값은 충분히 표현력이 높지 않습니다.

위임된 결제 흐름 (delegated payment flow)에는 경계 (boundaries)가 필요합니다:

type PaymentMandate = {
  mandateId: string;
  sessionId: string;
...

그러면 결제 시도 (payment attempt)를 위임 사항 (mandate)에 따라 평가할 수 있습니다:

type PaymentAuthorityDecision = {
  allowed: boolean;
  amountWithinLimit: boolean;
...

이는 결제 실행 (payment execution)과 결제 권한 (payment authority)을 분리합니다.

결제 제공업체 (payment provider)를 호출하는 것은 시스템의 한 부분입니다. 결제 시도가 에이전트에게 부여된 권한 범위 내에 있는지 증명하는 것은 또 다른 부분입니다.

두 번째 부분이 설계 복잡성 (design complexity)의 상당 부분이 존재하는 지점입니다.

멱등성 (Idempotency)은 안전 모델의 일부가 됩니다

에이전트 주도 시스템은 재시도 (retries)를 반드시 가정해야 합니다.

백엔드가 이미 작업을 완료한 후에도 요청이 타임아웃 (time out)될 수 있습니다. 에이전트 (agent)는 이전 응답을 받지 못했기 때문에 명령을 재시도 (retry)할 수 있습니다. 결제 명령이 두 번 제출될 수 있으며, 체크아웃 뮤테이션 (checkout mutation)이 재실행 (replay)될 수 있습니다.

따라서 멱등성 (Idempotency)은 단순한 구현 세부 사항이 아닙니다. 이는 안전 모델 (safety model)의 일부입니다.

명령에는 식별자 (identity)가 필요합니다:

type AgentCommand = {
  commandId: string;
  idempotencyKey: string;
...

플랫폼은 다음 질문에 답할 수 있어야 합니다:

• 이 명령이 이전에 확인된 적이 있는가?
• 페이로드 (payload)가 동일했는가?
• 이전 실행이 완료되었는가?
• 이전 결과를 반환하는 것이 안전한가?
• 이것이 재실행 (replay) 시도인가?
• 서로 다른 페이로드와 함께 동일한 멱등성 키 (idempotency key)가 재사용되고 있는가?

이는 중복 실행이 실제 재무적 또는 운영적 손실을 초래할 수 있는 결제 및 체크아웃 작업에서 특히 중요합니다.

운영자 뷰 (operator view)는 내부 아키텍처를 그대로 반영해서는 안 됩니다

백엔드가 더욱 명시적으로 변함에 따라, 내부 상태 (internal state)는 방대해질 수 있습니다: 제품 정보 (product facts), 정책 정보 (policy facts), 피드 상태 (feed health), 체크아웃 전환 (checkout transitions), 결제 권한 (payment authority), 프로토콜 응답 (protocol responses), 서명된 쓰기 (signed writes), 요청 원장 (request ledgers), 기여 기록 (attribution records), 개인정보 보호 규칙 (privacy rules), 그리고 감사 추적 (audit trails) 등이 이에 해당합니다.

이 모든 것을 운영자에게 직접 노출하는 것은 대개 열악한 관리자 경험 (admin experience)을 초래합니다.

운영자에게 필요한 것은 내부 서브시스템 (subsystems)의 가공되지 않은 지도(raw map)가 아니라, 결정 사항과 작업 (tasks)입니다.