AI 에이전트 결제 트랜잭션이 들어오면 쇼핑몰 코어 DB부터 보호해야 한다

자율 에이전트가 고객 대신 결제 버튼을 누르는 시대가 왔다고들 말합니다. Salesforce 집계에 따르면 2024년 11월 사이버 위크 동안 AI 에이전트가 관여한 글로벌 온라인 매출만 670억 달러에 달했습니다. 트래픽은 1년 새 800% 넘게 뛰었습니다. 경영진은 하루빨리 에이전트 결제를 열자고 보채지만, 결제 시스템을 책임지는 엔지니어 입장에서는 등골이 서늘해지는 이야기입니다.

화면 앞에 사람이 없는 트랜잭션은 기존 결제창 아키텍처를 그대로 무너뜨립니다. 자율 에이전트가 1초에 수십 번씩 결제 API를 두드리기 시작하면 레거시 관계형 DB 커넥션 풀부터 마릅니다. 기존 orders나 payments 테이블에 컬럼 몇 개 추가해서 해결할 문제가 아닙니다. 핵심 저장소 바깥에 별도 격리 계층을 두고, 엣지 게이트웨이 단계에서 잘못된 트랜잭션을 걸러내야 서비스가 삽니다.

사람이 없는 결제 환경이 결제창을 깨뜨리는 이유

기존 이커머스 결제창은 브라우저 쿠키, 자바스크립트 SDK iframe, SMS OTP 같은 사람의 물리적 조작을 바탕으로 돌아갑니다. 반면 Stripe와 OpenAI의 ACP(Agentic Commerce Protocol)나 Google, FIDO 얼라이언스 진영의 AP2(Agent Payments Protocol) 환경에서 활동하는 에이전트는 REST API와 MCP(Model Context Protocol) 툴 호출로 백엔드와 직접 통신합니다. 웹 브라우저 렌더링 엔진이 없는 봇에게 3D Secure 리다이렉트 창을 띄워주는 순간 HTTP 세션 타임아웃이 터지면서 주문 프로세스 전체가 멈춥니다.

더 골치 아픈 문제는 비결정론적 LLM의 특성입니다. 에이전트가 외부 블로그나 리뷰를 긁어모으다 간접 프롬프트 인젝션에 노출되면 순식간에 엉뚱한 고가 품목을 대량 주문합니다. 결제 승인 네트워크에서 504 게이트웨이 타임아웃이라도 발생하면, 멱등성 검증 키가 없는 백엔드는 재시도 루프에 휘말려 한 주문에 서너 번씩 결제를 승인해버립니다. 취소 수수료와 정산 분쟁 비용은 고스란히 플랫폼 몫으로 남습니다.

레거시 PostgreSQL이나 Oracle 인스턴스를 보호하려면 헥사고날 아키텍처 기반의 격리 계층을 에이전트 통신 최전선에 세워야 합니다.

계층	기술 구성	기간계 격리 방식
Agent Edge Gateway	ACP/AP2 엔드포인트, MCP Transport, TLS 1.3	에이전트 트래픽 단일 진입점 역할, 내부망 직접 접근 차단
Protocol Adapter	ACP 세션 페이로드 파서, JSON Schema 검증기	비정형 에이전트 요청을 내부 DTO 규격으로 정규화
Spending Guard	Redis Cluster, Lua 스크립트 기반 차감 엔진	인메모리 5ms 이내 연산으로 예산 초과 및 중복 요청 필터링
Core Commerce API	모놀리식 주문·재고 비즈니스 로직	기존 웹/모바일 클라이언트용 내부 포트 재사용

작업 순서는 단순합니다.

API 게이트웨이 최외곽에 ACP/AP2 프로토콜 전용 엔드포인트(/api/v1/agent/checkout)를 열고 TLS 1.3 암호화 통신을 강제합니다.
프로토콜 어댑터에서 에이전트 식별자, 위임 토큰, Mandate 해시를 파싱해 Redis 캐시에 격리 저장합니다.
검증을 통과한 정상 요청만 내부 통신용 토큰을 붙여 기존 주문 API 인터페이스 규격으로 매핑해 전달합니다.

코어 DB의 스키마를 단 한 줄도 건드리지 않고 에이전트 결제 트래픽을 처리하는 가장 현실적인 방법입니다.

에이전트 위임 토큰과 세션 검증 미들웨어 구성

에이전트는 사용자의 실제 신용카드 번호나 마스터 결제 정보를 쥐고 있어서는 안 됩니다. 최소 권한 원칙에 따라 IETF RFC 8693(OAuth 2.0 Token Exchange) 규격을 지켜야 합니다. 토큰 안에 실제 사용자(sub)와 대리 행위자인 에이전트(act)를 엄격히 분리하고, 토큰 만료 시간(TTL)은 15분에서 60분 사이로 짧게 끊어둡니다.

{
  "iss": "https://auth.ecommerce-platform.com",
  "sub": "usr_9981a2f4c0",
  "aud": "https://api.ecommerce-platform.com/checkout",
  "exp": 1774934400,
  "nbf": 1774930800,
  "iat": 1774930800,
  "jti": "tok_delegation_8f7b2c4e1a",
  "act": {
    "sub": "agent_gpt_shopping_v4",
    "agent_provider": "openai",
    "client_id": "app_agent_091823"
  },
  "scope": "agent:checkout:create agent:checkout:complete",
  "authorization_constraints": {
    "currency": "KRW",
    "max_amount": 150000,
    "allowed_categories": ["electronics", "books"],
    "merchant_id": "mrc_kr_company_01",
    "mandate_id": "man_ap2_7719abcef",
    "mandate_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
  }
}

LLM이 뱉어내는 JSON은 믿을 수 없습니다. 필드가 빠지거나 엉뚱한 타입이 들어오는 일이 다반사입니다. Ajv 엔진에 JSON Schema(Draft 2020-12) 규격을 물리고 additionalProperties: false 설정을 걸어 사전에 정의하지 않은 공격 필드 주입을 막아냅니다.

import { Request, Response, NextFunction } from 'express';
import jwt from 'jsonwebtoken';
import Ajv from 'ajv/dist/2020';
import addFormats from 'ajv-formats';

const ajv = new Ajv({ allErrors: true, strict: true });
addFormats(ajv);

const checkoutSchema = {
  type: "object",
  required: ["session_id", "idempotency_key", "currency", "total_amount", "line_items"],
  additionalProperties: false,
  properties: {
    session_id: { type: "string", pattern: "^cs_[a-zA-Z0-9]{24,32}$" },
    idempotency_key: { type: "string", format: "uuid" },
    currency: { type: "string", enum: ["KRW", "USD"] },
    total_amount: { type: "integer", minimum: 100 },
    line_items: {
      type: "array",
      minItems: 1,
      maxItems: 50,
      items: {
        type: "object",
        required: ["item_id", "category_code", "quantity", "unit_price"],
        additionalProperties: false,
        properties: {
          item_id: { type: "string", pattern: "^itm_[a-zA-Z0-9]+$" },
          category_code: { type: "string", maxLength: 32 },
          quantity: { type: "integer", minimum: 1, maximum: 99 },
          unit_price: { type: "integer", minimum: 0 }
        }
      }
    }
  }
};
const validatePayload = ajv.compile(checkoutSchema);
const PLATFORM_PUBLIC_KEY = process.env.JWT_PUBLIC_KEY!;

export function agentAuthenticationMiddleware(req: Request, res: Response, next: NextFunction) {
  const authHeader = req.headers.authorization;
  if (!authHeader?.startsWith('Bearer ')) {
    return res.status(401).json({ status: 401, detail: 'Bearer delegation token is strictly required.' });
  }

  try {
    const token = authHeader.substring(7);
    const decoded = jwt.verify(token, PLATFORM_PUBLIC_KEY, { algorithms: ['RS256', 'ES256'] }) as any;

    if (!decoded.act || !decoded.authorization_constraints) {
      return res.status(403).json({ status: 403, detail: 'RFC 8693 delegation claims missing.' });
    }

    if (!validatePayload(req.body)) {
      return res.status(400).json({ status: 400, errors: validatePayload.errors });
    }

    const { max_amount, allowed_categories, currency } = decoded.authorization_constraints;
    const { total_amount, line_items } = req.body;

    if (req.body.currency !== currency || total_amount > max_amount) {
      return res.status(403).json({ status: 403, detail: 'Currency mismatch or authorized amount exceeded.' });
    }

    const hasUnauthorizedCategory = line_items.some(
      (item: any) => !allowed_categories.includes(item.category_code)
    );
    if (hasUnauthorizedCategory) {
      return res.status(403).json({ status: 403, detail: 'Cart contains unauthorized categories.' });
    }

    req.agentContext = { userId: decoded.sub, agentId: decoded.act.sub };
    next();
  } catch (error: any) {
    return res.status(401).json({ status: 401, detail: error.message });
  }
}

이 미들웨어를 실무 시스템에 올릴 때는 다음 흐름을 따릅니다.

사내 IdP 인증 서버의 JWKS 엔드포인트에서 공개키를 받아 로컬 메모리에 캐싱하고 1시간 주기로 갱신합니다.
결제 라우터 맨 앞에 agentAuthenticationMiddleware를 붙여 요청을 동기식으로 먼저 검사합니다.
스키마 규격이나 허용 카테고리를 벗어난 요청은 즉시 HTTP 400 또는 403을 뱉고 연결을 끊어버립니다.

무단 결제 시도와 기형적인 페이로드를 1ms 안에 차단하므로 불필요한 결제 연산 비용을 줄일 수 있습니다.

Redis Lua 스크립트로 병렬 호출과 예산 초과 제어

토큰 검증만으로는 동시 다발적인 병렬 결제 호출을 막을 수 없습니다. 애플리케이션 서버에서 남은 예산을 조회(GET)하고, 한도를 비교한 뒤, 외부 PG 승인을 받고 나서 사용 금액을 갱신(SET)하는 구조는 동시성 이슈로 인해 한도 초과 결제가 터집니다. 분산 락(Redlock)은 왕복 시간(RTT)이 길어져 트랜잭션 병목을 만듭니다.

Redis의 단일 스레드 작업 환경을 활용해 읽기, 잔액 비교, 원자적 차감, 만료 시간 설정을 한 묶음으로 처리하는 Lua 스크립트를 작성합니다.

-- KEYS[1]: agent:budget:daily:{userId}:{agentId}
-- KEYS[2]: agent:idempotency:{idempotencyKey}
-- ARGV[1]: requested_amount, ARGV[2]: daily_limit, ARGV[3]: idempotency_ttl, ARGV[4]: window_ttl

local existing_tx = redis.call("GET", KEYS[2])
if existing_tx then
    return {1, "IDEMPOTENT_REPLAY", existing_tx}
end

local current_spend = tonumber(redis.call("GET", KEYS[1]) or "0")
local request_amount = tonumber(ARGV[1])
local max_limit = tonumber(ARGV[2])

if (current_spend + request_amount) > max_limit then
    local remaining = max_limit - current_spend
    if remaining < 0 then remaining = 0 end
    return {0, "BUDGET_EXCEEDED", tostring(remaining)}
end

local new_spend = current_spend + request_amount
redis.call("SET", KEYS[1], tostring(new_spend))

local current_ttl = redis.call("TTL", KEYS[1])
if current_ttl < 0 then
    redis.call("EXPIRE", KEYS[1], tonumber(ARGV[4]))
end

redis.call("SET", KEYS[2], "RESERVED", "EX", tonumber(ARGV[3]))
return {1, "SUCCESS", tostring(new_spend)}

이 스크립트는 네트워크 왕복 1회만으로 1ms 안에 결제 승인 여부를 가릅니다. 한도를 통과했다고 모든 주문을 즉시 처리해서는 안 됩니다. 장바구니 위험도에 따라 사람이 직접 개입하는 승인 단계를 배치해야 사고를 막습니다.

장바구니 조건	위험도	라우팅 방식	후속 조치
생필품 등 일반 소비재 5만 원 미만	낮음	에이전트 무인 자동 승인	주문 영수증 푸시 발송
단일 결제 10만 원 초과 또는 당일 누적 30만 원 초과	보통	Human-in-the-Loop 승인 대기열 이동	모바일 앱 생체 인증 요청
디지털 상품권, 환금성 품목	높음	상시 사용자 직접 승인 필수	10분 내 2단계 인증 미완료 시 세션 파기
동일 품목 5분 내 3회 이상 재주문 시도	이상 징후	트랜잭션 즉시 차단 및 세션 동결	비정상 루프 감지 긴급 보안 알림 발송

에이전트가 예산 초과 이유를 파악하고 무의미한 재시도를 멈추도록 RFC 7807(Problem Details for HTTP APIs) 규격으로 명확한 에러를 돌려줍니다.

{
  "type": "https://errors.ecommerce-platform.com/budget-exceeded",
  "title": "Daily Spending Budget Exceeded",
  "status": 403,
  "detail": "The transaction amount 45,000 KRW exceeds the remaining daily budget 12,000 KRW.",
  "instance": "/checkout/sessions/cs_88192a0e41f/complete",
  "code": "AGENT_BUDGET_EXCEEDED",
  "invalid_params": {
    "requested_amount": 45000,
    "current_daily_spend": 288000,
    "daily_budget_cap": 300000,
    "remaining_budget": 12000,
    "currency": "KRW",
    "reset_timestamp": "2026-04-18T00:00:00+09:00"
  },
  "actionable_resolution": "HALT_OR_REQUEST_HUMAN_APPROVAL"
}

예상치 못한 동작을 보일 때 세션을 즉각 얼려버리는 킬스위치 스크립트도 챙겨둡니다.

#!/usr/bin/env bash
# agent_killswitch.sh: 긴급 에이전트 세션 차단 및 지출 동결 스크립트
set -euo pipefail

REDIS_HOST="${REDIS_HOST:-127.0.0.1}"
REDIS_PORT="${REDIS_PORT:-6379}"
TARGET_TYPE="$1"
TARGET_ID="$2"
TTL_SECONDS="${3:-86400}"

echo "[KILL-SWITCH] Invoked for TARGET_TYPE=${TARGET_TYPE}, TARGET_ID=${TARGET_ID}"

if [ "${TARGET_TYPE}" == "agent" ]; then
    redis-cli -h "${REDIS_HOST}" -p "${REDIS_PORT}" \
        SET "killswitch:agent:${TARGET_ID}" "REVOKED" EX "${TTL_SECONDS}"
    redis-cli -h "${REDIS_HOST}" -p "${REDIS_PORT}" --scan --pattern "agent:session:*:${TARGET_ID}" | \
        xargs -r redis-cli -h "${REDIS_HOST}" -p "${REDIS_PORT}" DEL
    echo "[KILL-SWITCH] Agent ${TARGET_ID} successfully halted and sessions purged."
elif [ "${TARGET_TYPE}" == "global" ]; then
    redis-cli -h "${REDIS_HOST}" -p "${REDIS_PORT}" \
        SET "killswitch:global:commerce" "HALTED" EX 3600
    echo "[CRITICAL ALERT] All agent commerce payments globally halted for 1 hour."
else
    echo "Usage: $0 {agent|user|global} {ID} [TTL_SECONDS]"
    exit 1
fi

운영 환경 연동은 다음 단계로 진행합니다.

Redis 클러스터에 Lua 스크립트를 SCRIPT LOAD로 등록하고 반환된 SHA 해시를 백엔드 메모리에 캐싱합니다.
결제 API 서버의 트랜잭션 진입부에서 EVALSHA로 실행해 인메모리에서 예산 한도를 평가합니다.
운영 서버 콘솔에 스크립트 실행 권한을 주고, 장애 발생 시 ./agent_killswitch.sh agent agent_gpt_shopping_v4 명령어로 해당 에이전트 세션을 즉시 날립니다.

이 방어 계층을 두면 병렬 트래픽 폭주 상황에서도 예산 한도 초과율을 0%로 통제할 수 있습니다.

Prometheus와 Alertmanager를 이용한 비정상 행동 관측

사람이 개입하지 않는 자동 거래 환경에서는 월말 정산서가 나오고 나서야 결제 사고를 발견하는 참사가 벌어집니다. Prometheus와 Grafana를 연결해 에이전트의 호출 패턴과 실패율을 실시간으로 추적해야 합니다.

# metrics_collector.py
from prometheus_client import Counter, Histogram

AGENT_CHECKOUT_REQUESTS_TOTAL = Counter(
    'agent_checkout_requests_total',
    'Total count of agent checkout requests received',
    ['agent_provider', 'status', 'error_code']
)

AGENT_CHECKOUT_DURATION_SECONDS = Histogram(
    'agent_checkout_duration_seconds',
    'End-to-end latency of agent checkout execution',
    ['agent_provider', 'payment_method'],
    buckets=(0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0)
)

AGENT_BUDGET_SPEND_AMOUNT = Counter(
    'agent_budget_spend_amount_total',
    'Cumulative currency amount spent by agents',
    ['agent_id', 'currency', 'category_code']
)

AGENT_RETRY_LOOP_EVENTS_TOTAL = Counter(
    'agent_retry_loop_events_total',
    'Detected rapid retry attempts from the same agent session',
    ['agent_id', 'session_id']
)

Grafana 대시보드에 걸어둘 4가지 PromQL 쿼리입니다.

최근 5분간 결제 실패율을 계산해 서비스 장애를 감지합니다.

sum(rate(agent_checkout_requests_total{status="failure"}[5m])) by (agent_provider)
/
sum(rate(agent_checkout_requests_total[5m])) by (agent_provider) * 100

타임아웃으로 인한 무한 재시도를 잡기 위해 응답 지연 99 백분위수(p99)를 측정합니다.

histogram_quantile(0.99, sum(rate(agent_checkout_duration_seconds_bucket[5m])) by (le, agent_provider))

초당 비정상 재시도 발생 횟수를 추적해 오작동 에이전트를 가려냅니다.

sum(rate(agent_retry_loop_events_total[1m])) by (agent_id)

시간당 예산 소진 속도를 모니터링해 특정 카테고리에서의 급격한 자금 누수를 포착합니다.

sum(increase(agent_budget_spend_amount_total[1h])) by (category_code, currency)

Alertmanager를 사내 Slack 채널에 연동해 긴급 상황 시 온콜 엔지니어를 깨웁니다.

# alertmanager.yaml
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'agent_id', 'severity']
  group_wait: 10s
  group_interval: 1m
  repeat_interval: 1h
  receiver: 'slack-payment-ops'
  routes:
  - match:
      severity: critical
    receiver: 'slack-critical-security'

receivers:
- name: 'slack-payment-ops'
  slack_configs:
  - channel: '#ecom-agent-ops'
    api_url: 'https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX'
    send_resolved: true
    title: '{{ template "slack.default.title" . }}'
    text: >-
      *Alert:* {{ .CommonAnnotations.summary }}
      *Severity:* {{ .CommonLabels.severity }}
      *Details:* {{ .CommonAnnotations.description }}

- name: 'slack-critical-security'
  slack_configs:
  - channel: '#ecom-security-firefight'
    api_url: 'https://hooks.slack.com/services/T00000000/B00000000/YYYYYYYYYYYYYYYYYYYYYYYY'
    send_resolved: true
    title: 'CRITICAL AGENT ANOMALY: {{ .CommonAnnotations.summary }}'
    text: >-
      <!channel> EMERGENCY SHUTDOWN REQUIRED
      *Agent:* `{{ .CommonLabels.agent_id }}`
      *Reason:* {{ .CommonAnnotations.description }}
      *Automated Action:* Run `./agent_killswitch.sh agent {{ .CommonLabels.agent_id }}`

관측 파이프라인 구축 단계입니다.

결제 API 서버의 트랜잭션 핸들러 앞뒤로 수집 코드를 넣고 /metrics 엔드포인트를 사내망에 오픈합니다.
Prometheus 수집 주기를 15초로 맞추고 위의 PromQL 패널을 Grafana에 등록합니다.
Alertmanager에 Slack 웹훅을 연결하고 초당 재시도 5회 초과 시 알림이 제때 오는지 테스트합니다.

에이전트 결제 실패율이 10%를 넘거나 무한 재시도 루프가 돌기 시작했을 때 1분 안에 상황을 파악하고 대응할 수 있습니다.

AI 에이전트 결제 트랜잭션이 들어오면 쇼핑몰 코어 DB부터 보호해야 한다

사람이 없는 결제 환경이 결제창을 깨뜨리는 이유

레거시 PostgreSQL이나 Oracle 인스턴스를 보호하려면 헥사고날 아키텍처 기반의 격리 계층을 에이전트 통신 최전선에 세워야 합니다.

계층	기술 구성	기간계 격리 방식
Agent Edge Gateway	ACP/AP2 엔드포인트, MCP Transport, TLS 1.3	에이전트 트래픽 단일 진입점 역할, 내부망 직접 접근 차단
Protocol Adapter	ACP 세션 페이로드 파서, JSON Schema 검증기	비정형 에이전트 요청을 내부 DTO 규격으로 정규화
Spending Guard	Redis Cluster, Lua 스크립트 기반 차감 엔진	인메모리 5ms 이내 연산으로 예산 초과 및 중복 요청 필터링
Core Commerce API	모놀리식 주문·재고 비즈니스 로직	기존 웹/모바일 클라이언트용 내부 포트 재사용

작업 순서는 단순합니다.

API 게이트웨이 최외곽에 ACP/AP2 프로토콜 전용 엔드포인트(/api/v1/agent/checkout)를 열고 TLS 1.3 암호화 통신을 강제합니다.
프로토콜 어댑터에서 에이전트 식별자, 위임 토큰, Mandate 해시를 파싱해 Redis 캐시에 격리 저장합니다.
검증을 통과한 정상 요청만 내부 통신용 토큰을 붙여 기존 주문 API 인터페이스 규격으로 매핑해 전달합니다.

코어 DB의 스키마를 단 한 줄도 건드리지 않고 에이전트 결제 트래픽을 처리하는 가장 현실적인 방법입니다.

에이전트 위임 토큰과 세션 검증 미들웨어 구성

{
  "iss": "https://auth.ecommerce-platform.com",
  "sub": "usr_9981a2f4c0",
  "aud": "https://api.ecommerce-platform.com/checkout",
  "exp": 1774934400,
  "nbf": 1774930800,
  "iat": 1774930800,
  "jti": "tok_delegation_8f7b2c4e1a",
  "act": {
    "sub": "agent_gpt_shopping_v4",
    "agent_provider": "openai",
    "client_id": "app_agent_091823"
  },
  "scope": "agent:checkout:create agent:checkout:complete",
  "authorization_constraints": {
    "currency": "KRW",
    "max_amount": 150000,
    "allowed_categories": ["electronics", "books"],
    "merchant_id": "mrc_kr_company_01",
    "mandate_id": "man_ap2_7719abcef",
    "mandate_hash": "e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855"
  }
}

import { Request, Response, NextFunction } from 'express';
import jwt from 'jsonwebtoken';
import Ajv from 'ajv/dist/2020';
import addFormats from 'ajv-formats';

const ajv = new Ajv({ allErrors: true, strict: true });
addFormats(ajv);

const checkoutSchema = {
  type: "object",
  required: ["session_id", "idempotency_key", "currency", "total_amount", "line_items"],
  additionalProperties: false,
  properties: {
    session_id: { type: "string", pattern: "^cs_[a-zA-Z0-9]{24,32}$" },
    idempotency_key: { type: "string", format: "uuid" },
    currency: { type: "string", enum: ["KRW", "USD"] },
    total_amount: { type: "integer", minimum: 100 },
    line_items: {
      type: "array",
      minItems: 1,
      maxItems: 50,
      items: {
        type: "object",
        required: ["item_id", "category_code", "quantity", "unit_price"],
        additionalProperties: false,
        properties: {
          item_id: { type: "string", pattern: "^itm_[a-zA-Z0-9]+$" },
          category_code: { type: "string", maxLength: 32 },
          quantity: { type: "integer", minimum: 1, maximum: 99 },
          unit_price: { type: "integer", minimum: 0 }
        }
      }
    }
  }
};
const validatePayload = ajv.compile(checkoutSchema);
const PLATFORM_PUBLIC_KEY = process.env.JWT_PUBLIC_KEY!;

export function agentAuthenticationMiddleware(req: Request, res: Response, next: NextFunction) {
  const authHeader = req.headers.authorization;
  if (!authHeader?.startsWith('Bearer ')) {
    return res.status(401).json({ status: 401, detail: 'Bearer delegation token is strictly required.' });
  }

  try {
    const token = authHeader.substring(7);
    const decoded = jwt.verify(token, PLATFORM_PUBLIC_KEY, { algorithms: ['RS256', 'ES256'] }) as any;

    if (!decoded.act || !decoded.authorization_constraints) {
      return res.status(403).json({ status: 403, detail: 'RFC 8693 delegation claims missing.' });
    }

    if (!validatePayload(req.body)) {
      return res.status(400).json({ status: 400, errors: validatePayload.errors });
    }

    const { max_amount, allowed_categories, currency } = decoded.authorization_constraints;
    const { total_amount, line_items } = req.body;

    if (req.body.currency !== currency || total_amount > max_amount) {
      return res.status(403).json({ status: 403, detail: 'Currency mismatch or authorized amount exceeded.' });
    }

    const hasUnauthorizedCategory = line_items.some(
      (item: any) => !allowed_categories.includes(item.category_code)
    );
    if (hasUnauthorizedCategory) {
      return res.status(403).json({ status: 403, detail: 'Cart contains unauthorized categories.' });
    }

    req.agentContext = { userId: decoded.sub, agentId: decoded.act.sub };
    next();
  } catch (error: any) {
    return res.status(401).json({ status: 401, detail: error.message });
  }
}

이 미들웨어를 실무 시스템에 올릴 때는 다음 흐름을 따릅니다.

사내 IdP 인증 서버의 JWKS 엔드포인트에서 공개키를 받아 로컬 메모리에 캐싱하고 1시간 주기로 갱신합니다.
결제 라우터 맨 앞에 agentAuthenticationMiddleware를 붙여 요청을 동기식으로 먼저 검사합니다.
스키마 규격이나 허용 카테고리를 벗어난 요청은 즉시 HTTP 400 또는 403을 뱉고 연결을 끊어버립니다.

무단 결제 시도와 기형적인 페이로드를 1ms 안에 차단하므로 불필요한 결제 연산 비용을 줄일 수 있습니다.

Redis Lua 스크립트로 병렬 호출과 예산 초과 제어

Redis의 단일 스레드 작업 환경을 활용해 읽기, 잔액 비교, 원자적 차감, 만료 시간 설정을 한 묶음으로 처리하는 Lua 스크립트를 작성합니다.

-- KEYS[1]: agent:budget:daily:{userId}:{agentId}
-- KEYS[2]: agent:idempotency:{idempotencyKey}
-- ARGV[1]: requested_amount, ARGV[2]: daily_limit, ARGV[3]: idempotency_ttl, ARGV[4]: window_ttl

local existing_tx = redis.call("GET", KEYS[2])
if existing_tx then
    return {1, "IDEMPOTENT_REPLAY", existing_tx}
end

local current_spend = tonumber(redis.call("GET", KEYS[1]) or "0")
local request_amount = tonumber(ARGV[1])
local max_limit = tonumber(ARGV[2])

if (current_spend + request_amount) > max_limit then
    local remaining = max_limit - current_spend
    if remaining < 0 then remaining = 0 end
    return {0, "BUDGET_EXCEEDED", tostring(remaining)}
end

local new_spend = current_spend + request_amount
redis.call("SET", KEYS[1], tostring(new_spend))

local current_ttl = redis.call("TTL", KEYS[1])
if current_ttl < 0 then
    redis.call("EXPIRE", KEYS[1], tonumber(ARGV[4]))
end

redis.call("SET", KEYS[2], "RESERVED", "EX", tonumber(ARGV[3]))
return {1, "SUCCESS", tostring(new_spend)}

장바구니 조건	위험도	라우팅 방식	후속 조치
생필품 등 일반 소비재 5만 원 미만	낮음	에이전트 무인 자동 승인	주문 영수증 푸시 발송
단일 결제 10만 원 초과 또는 당일 누적 30만 원 초과	보통	Human-in-the-Loop 승인 대기열 이동	모바일 앱 생체 인증 요청
디지털 상품권, 환금성 품목	높음	상시 사용자 직접 승인 필수	10분 내 2단계 인증 미완료 시 세션 파기
동일 품목 5분 내 3회 이상 재주문 시도	이상 징후	트랜잭션 즉시 차단 및 세션 동결	비정상 루프 감지 긴급 보안 알림 발송

에이전트가 예산 초과 이유를 파악하고 무의미한 재시도를 멈추도록 RFC 7807(Problem Details for HTTP APIs) 규격으로 명확한 에러를 돌려줍니다.

{
  "type": "https://errors.ecommerce-platform.com/budget-exceeded",
  "title": "Daily Spending Budget Exceeded",
  "status": 403,
  "detail": "The transaction amount 45,000 KRW exceeds the remaining daily budget 12,000 KRW.",
  "instance": "/checkout/sessions/cs_88192a0e41f/complete",
  "code": "AGENT_BUDGET_EXCEEDED",
  "invalid_params": {
    "requested_amount": 45000,
    "current_daily_spend": 288000,
    "daily_budget_cap": 300000,
    "remaining_budget": 12000,
    "currency": "KRW",
    "reset_timestamp": "2026-04-18T00:00:00+09:00"
  },
  "actionable_resolution": "HALT_OR_REQUEST_HUMAN_APPROVAL"
}

예상치 못한 동작을 보일 때 세션을 즉각 얼려버리는 킬스위치 스크립트도 챙겨둡니다.

#!/usr/bin/env bash
# agent_killswitch.sh: 긴급 에이전트 세션 차단 및 지출 동결 스크립트
set -euo pipefail

REDIS_HOST="${REDIS_HOST:-127.0.0.1}"
REDIS_PORT="${REDIS_PORT:-6379}"
TARGET_TYPE="$1"
TARGET_ID="$2"
TTL_SECONDS="${3:-86400}"

echo "[KILL-SWITCH] Invoked for TARGET_TYPE=${TARGET_TYPE}, TARGET_ID=${TARGET_ID}"

if [ "${TARGET_TYPE}" == "agent" ]; then
    redis-cli -h "${REDIS_HOST}" -p "${REDIS_PORT}" \
        SET "killswitch:agent:${TARGET_ID}" "REVOKED" EX "${TTL_SECONDS}"
    redis-cli -h "${REDIS_HOST}" -p "${REDIS_PORT}" --scan --pattern "agent:session:*:${TARGET_ID}" | \
        xargs -r redis-cli -h "${REDIS_HOST}" -p "${REDIS_PORT}" DEL
    echo "[KILL-SWITCH] Agent ${TARGET_ID} successfully halted and sessions purged."
elif [ "${TARGET_TYPE}" == "global" ]; then
    redis-cli -h "${REDIS_HOST}" -p "${REDIS_PORT}" \
        SET "killswitch:global:commerce" "HALTED" EX 3600
    echo "[CRITICAL ALERT] All agent commerce payments globally halted for 1 hour."
else
    echo "Usage: $0 {agent|user|global} {ID} [TTL_SECONDS]"
    exit 1
fi

운영 환경 연동은 다음 단계로 진행합니다.

Redis 클러스터에 Lua 스크립트를 SCRIPT LOAD로 등록하고 반환된 SHA 해시를 백엔드 메모리에 캐싱합니다.
결제 API 서버의 트랜잭션 진입부에서 EVALSHA로 실행해 인메모리에서 예산 한도를 평가합니다.
운영 서버 콘솔에 스크립트 실행 권한을 주고, 장애 발생 시 ./agent_killswitch.sh agent agent_gpt_shopping_v4 명령어로 해당 에이전트 세션을 즉시 날립니다.

이 방어 계층을 두면 병렬 트래픽 폭주 상황에서도 예산 한도 초과율을 0%로 통제할 수 있습니다.

Prometheus와 Alertmanager를 이용한 비정상 행동 관측

# metrics_collector.py
from prometheus_client import Counter, Histogram

AGENT_CHECKOUT_REQUESTS_TOTAL = Counter(
    'agent_checkout_requests_total',
    'Total count of agent checkout requests received',
    ['agent_provider', 'status', 'error_code']
)

AGENT_CHECKOUT_DURATION_SECONDS = Histogram(
    'agent_checkout_duration_seconds',
    'End-to-end latency of agent checkout execution',
    ['agent_provider', 'payment_method'],
    buckets=(0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0, 10.0)
)

AGENT_BUDGET_SPEND_AMOUNT = Counter(
    'agent_budget_spend_amount_total',
    'Cumulative currency amount spent by agents',
    ['agent_id', 'currency', 'category_code']
)

AGENT_RETRY_LOOP_EVENTS_TOTAL = Counter(
    'agent_retry_loop_events_total',
    'Detected rapid retry attempts from the same agent session',
    ['agent_id', 'session_id']
)

Grafana 대시보드에 걸어둘 4가지 PromQL 쿼리입니다.

최근 5분간 결제 실패율을 계산해 서비스 장애를 감지합니다.

sum(rate(agent_checkout_requests_total{status="failure"}[5m])) by (agent_provider)
/
sum(rate(agent_checkout_requests_total[5m])) by (agent_provider) * 100

타임아웃으로 인한 무한 재시도를 잡기 위해 응답 지연 99 백분위수(p99)를 측정합니다.

histogram_quantile(0.99, sum(rate(agent_checkout_duration_seconds_bucket[5m])) by (le, agent_provider))

초당 비정상 재시도 발생 횟수를 추적해 오작동 에이전트를 가려냅니다.

sum(rate(agent_retry_loop_events_total[1m])) by (agent_id)

시간당 예산 소진 속도를 모니터링해 특정 카테고리에서의 급격한 자금 누수를 포착합니다.

sum(increase(agent_budget_spend_amount_total[1h])) by (category_code, currency)

Alertmanager를 사내 Slack 채널에 연동해 긴급 상황 시 온콜 엔지니어를 깨웁니다.

# alertmanager.yaml
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'agent_id', 'severity']
  group_wait: 10s
  group_interval: 1m
  repeat_interval: 1h
  receiver: 'slack-payment-ops'
  routes:
  - match:
      severity: critical
    receiver: 'slack-critical-security'

receivers:
- name: 'slack-payment-ops'
  slack_configs:
  - channel: '#ecom-agent-ops'
    api_url: 'https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX'
    send_resolved: true
    title: '{{ template "slack.default.title" . }}'
    text: >-
      *Alert:* {{ .CommonAnnotations.summary }}
      *Severity:* {{ .CommonLabels.severity }}
      *Details:* {{ .CommonAnnotations.description }}

- name: 'slack-critical-security'
  slack_configs:
  - channel: '#ecom-security-firefight'
    api_url: 'https://hooks.slack.com/services/T00000000/B00000000/YYYYYYYYYYYYYYYYYYYYYYYY'
    send_resolved: true
    title: 'CRITICAL AGENT ANOMALY: {{ .CommonAnnotations.summary }}'
    text: >-
      <!channel> EMERGENCY SHUTDOWN REQUIRED
      *Agent:* `{{ .CommonLabels.agent_id }}`
      *Reason:* {{ .CommonAnnotations.description }}
      *Automated Action:* Run `./agent_killswitch.sh agent {{ .CommonLabels.agent_id }}`

관측 파이프라인 구축 단계입니다.

결제 API 서버의 트랜잭션 핸들러 앞뒤로 수집 코드를 넣고 /metrics 엔드포인트를 사내망에 오픈합니다.
Prometheus 수집 주기를 15초로 맞추고 위의 PromQL 패널을 Grafana에 등록합니다.
Alertmanager에 Slack 웹훅을 연결하고 초당 재시도 5회 초과 시 알림이 제때 오는지 테스트합니다.

에이전트 결제 실패율이 10%를 넘거나 무한 재시도 루프가 돌기 시작했을 때 1분 안에 상황을 파악하고 대응할 수 있습니다.

AI 에이전트 결제 트랜잭션이 들어오면 쇼핑몰 코어 DB부터 보호해야 한다

관련 영상

에이전틱 커머스 스택 — 아흐나프 프리오, 베스트바이

AI 에이전트 결제 트랜잭션이 들어오면 쇼핑몰 코어 DB부터 보호해야 한다

사람이 없는 결제 환경이 결제창을 깨뜨리는 이유

에이전트 위임 토큰과 세션 검증 미들웨어 구성

Redis Lua 스크립트로 병렬 호출과 예산 초과 제어

Prometheus와 Alertmanager를 이용한 비정상 행동 관측

커뮤니티의 다른 글

에이전틱 커머스 프로젝트에 x402 결제를 붙일 때 생기는 일들

WP-CLI와 SQL로 워드프레스 은폐 백도어 찾는 법

서버리스 PaaS 인프라에서 배포 후 겪는 실무 문제 해결책

Stripe 기반 AI 에이전트에 자금 한도를 거는 백엔드 구현법

알고리즘 밖에서 나만의 커뮤니티를 지키는 법

알고리즘보다 내 전문성을 증명하는 법

댓글 (0)

AI 에이전트 결제 트랜잭션이 들어오면 쇼핑몰 코어 DB부터 보호해야 한다

사람이 없는 결제 환경이 결제창을 깨뜨리는 이유

에이전트 위임 토큰과 세션 검증 미들웨어 구성

Redis Lua 스크립트로 병렬 호출과 예산 초과 제어

Prometheus와 Alertmanager를 이용한 비정상 행동 관측