MCP 서버에 x402 결제를 추가하는 방법: 에이전트 결제를 위한 빌더 가이드
작성자 Alchemy

대부분의 API는 먼저 가입을 시켜야 요금을 부과할 수 있습니다: 계정을 만들고, 키를 발급받고, 나중에 청구서를 받는 식입니다. x402는 이 과정을 전부 생략합니다. 서버가 요청 단위로 요금을 부과할 수 있으며, 가입도 키도 인보이스도 필요 없습니다. 그리고 이미 프로덕션에서 사용되고 있습니다: Coinbase는 2025년 5월에 이를 출시했고, Cloudflare는 이를 자사 Agents SDK에 연결했으며, 우리의 에이전트 게이트웨이는 이를 사용해 에이전트에게 RPC 및 데이터 접근 요금을 부과합니다.
이 가이드는 이 거래의 양쪽 모두를 구축하는 분들을 위한 것입니다: 호출당 요금을 부과하려는 MCP 서버나 API, 또는 요금을 지불해야 하는 에이전트. 요청-응답 루프를 살펴본 다음, 도구 호출에 대한 과금, 호출당 USDC 계측 및 정산, 에이전트에게 지불용 지갑을 부여하는 방법, 그리고 AP2 같은 다른 결제 프로토콜이 어디에 들어맞는지에 대한 실제 코드를 보여드리겠습니다.
x402는 실제로 무엇을 하나요?
HTTP 402 Payment Required는 1990년대부터 HTTP 스펙에 존재했지만 한 번도 구현된 적이 없었습니다. x402는 마침내 이를 사용하는 프로토콜입니다:
- 서버는 결제되지 않은 요청에 대해 상태 코드 402와 기계가 읽을 수 있는 가격으로 응답합니다
- 클라이언트는 서명된 결제 정보를 첨부하여 재시도합니다
- 서버는 검증하고, 정산하고, 같은 교환 과정에서 리소스를 반환합니다
세션도, 저장된 카드 정보도, 대시보드도 없으며, 지갑 자체가 계정입니다. x402 v2에서는 관련 정보가 HTTP 헤더에 저장됩니다:
이 세 헤더는 변하지 않습니다. 변하는 것은 PAYMENT-REQUIRED이 담고 있는 JSON 내부의 scheme 필드로, 이 특정 호출이 어떤 과금 모델을 사용하는지 클라이언트에게 알려줍니다. 어떤 스킴이든 검증과 자금 이동은 동일한 제3자가 수행합니다: facilitator는 클라이언트의 서명된 결제를 검증하고 온체인 정산을 제출하는 서비스로, 판매자와 클라이언트 어느 쪽도 이 작업을 직접 할 필요가 없게 해줍니다. 스킴마다 달라지는 것은 facilitator가 무엇을 확인하고 언제 정산하는지뿐입니다.
대부분의 호출은 exact를 사용합니다: 가격이 고정되어 있고 사전에 알려져 있으므로, 클라이언트는 정확히 그 금액에 서명하고 정확히 그 금액으로 정산됩니다. 페이로드는 중요한 필드만 남기면 다음과 같은 형태입니다. amount는 10,000 atomic unit로, 이는 $0.01 USDC입니다:
{
"accepts": [{
"scheme": "exact",
"amount": "10000",
"asset": "0x036C...F7e",
"payTo": "0x2096...87C"
}]
}일부 호출은 작업이 끝난 후에야 알 수 있는 가변 금액이 드는데, 예를 들어 생성된 토큰 수로 과금되는 LLM 출력이 그렇습니다. 이런 경우 서버는 upto를 사용합니다. 페이로드는 거의 동일해 보이지만, 이제 amount는 가격이 아니라 클라이언트가 동의하는 상한선을 의미합니다. 여기서 그 상한선은 $5.00입니다:
{
"accepts": [{
"scheme": "upto",
"amount": "5000000",
"asset": "0x036C...F7e",
"payTo": "0x2096...87C"
}]
}클라이언트는 그 상한선에 대해 한 번 서명합니다. 서버가 작업을 마친 후, facilitator는 실제 금액(예: 실제 사용량 $1.20)을 정산하고, 자금을 이동시키기 전에 그 금액이 서명된 상한선 이하인지 확인합니다. 클라이언트는 두 번 서명하지 않으며, 정산 단계에서만 실제 숫자가 채워집니다.
세 번째 스킴인 batch-settlement은 호출마다 가스비를 내는 것이 호출 자체보다 더 비쌀 정도로 빈번하고 소액인 과금을 위한 것입니다. x402 스킴에서는 구매자가 에스크로 컨트랙트에 한 번 예치하고, 요청마다 오프체인 바우처에 서명하며, 판매자는 온체인에서 이를 배치로 상환합니다. Circle Gateway는 같은 목적으로 관련된 나노페이먼트 패턴을 사용합니다.
facilitator는 스스로 자금을 보유하지 않으며, 서명된 지시를 확인하고 실행할 뿐입니다. x402.org는 개발 및 테스트넷 전용의 무료 공개 facilitator를 운영합니다, 그리고 Coinbase의 CDP는 컴플라이언스 심사를 포함한 프로덕션용 호스팅 facilitator를 운영합니다. 코드에서 둘 중 하나를 가리키도록 설정할 수 있습니다.
x402 요청-응답 루프는 어떻게 동작하나요?
핸드셰이크는 아홉 단계로 이루어집니다:
- 클라이언트가 결제 없이 리소스를 요청합니다.
- 서버는 가격, 대상 주소, 허용하는 결제 스킴과 함께
402 Payment Required로 응답합니다. - 클라이언트는 허용된 스킴 중 하나에 대해 결제를 서명하고, 서명을 첨부해 요청을 재시도합니다.
- 서버는 facilitator에게 서명된 결제가 명시된 요구 사항을 충족하는지 검증을 요청합니다.
- facilitator는 검증 결과를 반환합니다.
- 서버는 작업을 수행합니다(쿼리 실행, 모델 호출, 보고서 생성 등).
- 서버는 facilitator에게 결제를 온체인에서 정산하도록 요청합니다.
- facilitator는 정산 결과를 반환합니다.
- 서버는 정산 영수증과 함께 리소스를 반환합니다.
HTTP에서는 이 루프가 HTTP 헤더(PAYMENT-REQUIRED, PAYMENT-SIGNATURE, PAYMENT-RESPONSE)를 통해 실행됩니다. MCP에서는 같은 아홉 단계가 대신 JSON을 통해 실행됩니다:
- 결제 없이 이루어진 호출은
isError: true과PaymentRequired페이로드를 담은 결과를 반환합니다(PAYMENT-REQUIRED에 해당) - 클라이언트는
_meta["x402/payment"]에 서명된 결제를 첨부해 같은 호출을 재시도합니다(PAYMENT-SIGNATURE에 해당) - 서버는
_meta["x402/payment-response"]에 정산 정보와 함께 실제 결과를 반환합니다(PAYMENT-RESPONSE에 해당)
MCP 서버에 x402 결제를 추가하려면 어떻게 하나요?
이 예제는 흔한 실제 사례를 반영합니다: 무료 및 유료 도구가 섞여 있는 MCP 서버로, 예를 들어 기본 조회는 무료로 제공하지만 심층 생성 보고서에는 요금을 부과하는 리서치 또는 데이터 서버가 그렇습니다.
이 예제에서 generate_report은 호출당 $0.01의 요금이 부과되고 ping는 무료로 유지되며, 오픈소스인 x402 Foundation SDKs(facilitator에 종속되지 않으므로 무료 공개 facilitator로 시작한 후 나중에 상용 facilitator로 교체할 수 있음) 위에 구축되고, 결제를 수신하는 주소로 Wallet APIs 스마트 계정을 사용합니다.
먼저 결제를 받을 지갑을 프로비저닝합니다. @alchemy/wallet-apis(v5)은 서버에서 개인 키를 다루지 않고도 스마트 계정 주소를 제공합니다:
// wallet.ts
import { createServerSigner } from "@account-kit/signer";
import { createSmartWalletClient, alchemyWalletTransport } from "@alchemy/wallet-apis";
import { baseSepolia } from "viem/chains";
const signer = await createServerSigner({
auth: { accessKey: process.env.ALCHEMY_ACCESS_KEY! },
connection: { apiKey: process.env.ALCHEMY_API_KEY! },
});
const walletClient = createSmartWalletClient({
transport: alchemyWalletTransport({ apiKey: process.env.ALCHEMY_API_KEY! }),
chain: baseSepolia,
signer,
});
export const receiverAccount = await walletClient.requestAccount();
// receiverAccount.address is the payTo address for every quote you issue below이제 그 주소를 x402로 보호된 MCP 도구에 연결합니다. @x402/core은 결제 요구 사항을 구성하고 검증하며, @x402/evm는 EVM 체인용 exact 스킴을 구현하고, @x402/mcp는 도구 핸들러를 감싸서 일반 함수를 유료 함수로 만듭니다:
// server.ts
import { createServer } from "node:http";
import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StreamableHTTPServerTransport } from "@modelcontextprotocol/sdk/server/streamableHttp.js";
import { x402ResourceServer } from "@x402/core/server";
import { HTTPFacilitatorClient } from "@x402/core/facilitator";
import { createPaymentWrapper } from "@x402/mcp";
import { ExactEvmScheme } from "@x402/evm/exact/server";
import { z } from "zod";
import { receiverAccount } from "./wallet";
// Base Sepolia for testing; swap to eip155:8453 for Base mainnet
const NETWORK = "eip155:84532";
// Start against the free public facilitator, then swap the url for a
// commercial facilitator (compliance screening, higher throughput, an
// SLA) for production.
const facilitator = new HTTPFacilitatorClient({
url: "https://x402.org/facilitator",
});
const resourceServer = new x402ResourceServer(facilitator);
resourceServer.register(NETWORK, new ExactEvmScheme());
await resourceServer.initialize();
const accepts = await resourceServer.buildPaymentRequirements({
scheme: "exact",
network: NETWORK,
payTo: receiverAccount.address,
price: "$0.01",
});
const paid = createPaymentWrapper(resourceServer, { accepts });
const server = new McpServer({
name: "paid-report-server",
version: "1.0.0",
});
server.tool(
"generate_report",
"Generate a research report on a topic. Costs $0.01 in USDC.",
{ topic: z.string() },
paid(async ({ topic }) => ({
content: [
{
type: "text",
text: "Report on " + topic + ": trending up, no anomalies.",
},
],
})),
);
server.tool("ping", "Free health check", {}, async () => ({
content: [{ type: "text", text: "pong" }],
}));
const transport = new StreamableHTTPServerTransport({
sessionIdGenerator: undefined,
});
await server.connect(transport);
createServer((req, res) => {
const path = new URL(req.url ?? "/", "http://localhost").pathname;
if (path === "/mcp") {
void transport.handleRequest(req, res);
return;
}
res.writeHead(404).end();
}).listen(3000);server.connect(transport)는 프로토콜을 트랜스포트에 연결하기만 합니다. 실제로 포트 3000을 열고 /mcp을 transport.handleRequest(...)로 전달하는 것은 Node HTTP 리스너이며, 이것이 아래 클라이언트가 호출하는 엔드포인트입니다.
paid(...)로 감싸지 않은 모든 것은 무료로 유지되므로, 같은 서버에서 유료 도구와 무료 도구를 섞어 사용할 수 있습니다. 먼저 결제 없이 curl나 다른 MCP 클라이언트로 테스트해 보세요: 보고서 대신 결제 필요 결과를 받게 되며, 이는 유료 클라이언트를 연결하기 전에 게이트가 작동하고 있는지 확인해줍니다.
facilitator 관계를 직접 운영하고 싶지 않고, x402를 다른 신흥 에이전트 결제 프로토콜과 함께 특정 하나를 고르지 않고 지원하고 싶다면, 그것이 AgentPay가 존재하는 이유입니다: 기존 엔드포인트를 가리키기만 하면 하나의 통합으로 x402, ACP, MPP, AP2 간의 프로토콜 변환을 처리해줍니다.
에이전트에게 호출당 요금을 계측하고 부과하려면 어떻게 하나요?
호출당 균일 요금이 기본 사례입니다. 프로덕션 서버는 누가 얼마를 지불했는지도 추적해야 하며, 자금이 실제로 이동했다는 유일한 증거로 facilitator의 정산 보고서에만 의존해서는 안 됩니다. 검증하려면 다음을 추적하세요:
- 가격 책정 형태. 균일한 호출당 가격에는
exact을, 위 패턴을 사용하세요. 호출마다 비용이 달라지는 경우(긴 보고서가 짧은 것보다 토큰이 더 많이 듦) 상한선을 사전에 승인하되 실제 사용량으로 정산하려면upto을 사용하세요. 호출이 빈번하고 저렴해서 각각을 개별적으로 온체인에서 정산하는 것이 호출 자체보다 더 비쌀 경우batch-settlement를 사용하세요. - 귀속 및 원장 관리. 클라이언트가 서명하는 결제 페이로드에는 지불 주소가 포함됩니다. 매 호출이 정산될 때마다 도구 이름, 가격, 정산 결과와 함께 이를 기록하면, 별도의 작업 없이 에이전트별 사용 원장이 생깁니다:
const paid = createPaymentWrapper(resourceServer, {
accepts,
hooks: {
onAfterSettlement: async ({ toolName, settlement }) => {
await usageLedger.record({
payer: settlement.payer,
tool: toolName,
amountUsd: 0.01,
txHash: settlement.transaction,
settledAt: new Date(),
});
},
},
});정산 응답을 유일한 신호로 신뢰하는 데 그치지 마세요. facilitator는 요청이 여전히 비-200 상태를 반환하는데도 settled: true을 보고할 수 있고, 그 반대도 가능합니다. 매출을 집계하기 전에 둘 다 확인하세요. 주기적인 대조 작업을 위해, 우리의 Transfers API는 실제로 수신 주소에 도착한 것을 독립적으로 확인할 수 있게 해주며, 이는 facilitator의 정산 보고서와 온체인 현실이 서로 어긋나는 드문 경우를 포착합니다:
const res = await fetch("https://base-sepolia.g.alchemy.com/v2/" + apiKey, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
jsonrpc: "2.0",
method: "alchemy_getAssetTransfers",
params: [{
toAddress: receiverAccount.address,
category: ["erc20"],
contractAddresses: [USDC_ADDRESS],
withMetadata: true,
}],
id: 1,
}),
});
const { result } = await res.json();
// result.transfers is the ground truth for what actually arrived onchain,
// independent of what any single facilitator reported settling에이전트에게 지불용 USDC 지갑을 부여하려면 어떻게 하나요?
유료화된 엔드포인트(자신의 것이든 다른 누군가의 것이든)에 결제해야 하는 에이전트에게는 자금이 있는 지갑과, 402를 받았을 때 결제에 서명할 수 있는 코드(또는 CLI)가 필요합니다.
사람이 직접 운영하거나 로컬에서 테스트하는 에이전트라면 Alchemy CLI가 가장 빠른 경로입니다. 이는 개인 키를 전혀 다루지 않고도 에이전트가 사용할 수 있는 범위가 제한된 지갑 세션을 생성합니다:
npm i -g "@alchemy/cli@latest"
alchemy auth
alchemy wallet connect --mode session --instance-name "my-agent"
# decode a quote without paying anything, useful for a first look at an unfamiliar endpoint
alchemy x402 request "https://api.example.com/report" --estimate
# pay it for real, with a hard spend cap; required for any non-interactive run
alchemy --json --no-interactive x402 request "https://api.example.com/report" --max-payment 0.01--max-payment는 CLI가 지불할 수 있는 최대 금액을 설정하며, 서버가 무엇을 돌려보내든 이 숫자를 넘어서게 할 수 없습니다. 승인할 사람 없이 명령을 실행하고(--no-interactive) --max-payment 설정을 잊어버리면, CLI는 지불하는 대신 그냥 멈춥니다. 402 응답의 가격은 여러분이 제어하지 않는 서버에서 오는 것이므로, 여러분의 한도가 먼저 확인하지 않는 한 아무것도 지불되어서는 안 되기 때문입니다. 전체 명령어 목록은 x402 payments CLI 문서를 참고하세요.
사람이 매 세션마다 승인하지 않고 지불해야 하는 완전 자율 백엔드 에이전트의 경우, fetch(또는 MCP 클라이언트)을 서명자가 뒷받침하는 결제 핸들러로 감싸세요. 에이전트가 유료 HTTP 엔드포인트를 호출하는 경우 @x402/fetch을 사용하세요:
import { x402Client } from "@x402/core/client";
import { wrapFetchWithPayment } from "@x402/fetch";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";
const signer = privateKeyToAccount(process.env.AGENT_WALLET_KEY as `0x${string}`);
const client = new x402Client();
registerExactEvmScheme(client, { signer });
const fetchWithPayment = wrapFetchWithPayment(fetch, client);
const response = await fetchWithPayment("https://api.example.com/report");에이전트가 일반 HTTP 엔드포인트 대신 MCP 서버의 유료 도구를 호출하는 경우, fetch 대신 같은 방식으로 MCP 클라이언트를 감싸세요. CDP는 MCP 구매자를 위한 동일한 패턴을 문서화하고 있습니다:
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";
import { x402Client } from "@x402/core/client";
import { wrapMCPClientWithPayment } from "@x402/mcp";
import { registerExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";
const signer = privateKeyToAccount(
process.env.AGENT_WALLET_KEY as `0x${string}`,
);
const paymentClient = new x402Client();
registerExactEvmScheme(paymentClient, { signer });
const mcp = wrapMCPClientWithPayment(
new Client(
{ name: "my-agent", version: "1.0.0" },
{ capabilities: {} },
),
paymentClient,
{ autoPayment: true },
);
await mcp.connect(
new StreamableHTTPClientTransport(
new URL("http://localhost:3000/mcp"),
),
);
const report = await mcp.callTool({
name: "generate_report",
arguments: { topic: "USDC on Base" },
});환경 변수에 있는 원시 개인 키는 테스트넷에서의 첫 테스트에는 괜찮을 수 있지만, 프로덕션에서는 용인될 수 없습니다. 프로덕션 에이전트의 경우, 같은 서명자 인터페이스 뒤에 Wallet APIs 스마트 계정이나 Agent Wallet 세션을 두어, 에이전트가 개인 키를 직접 보유하지 않고도 여러분이 설정한 규칙에 따라 서명할 수 있게 하세요.
에이전트에게 가스를 보유시키지 않고 USDC로 정산하려면 어떻게 하나요?
모든 온체인 트랜잭션에는 가스가 필요합니다: 트랜잭션을 보내는 쪽이 네트워크가 이를 처리하도록 지불하는 ETH 같은 네이티브 토큰입니다. 이는 API 호출당 결제하는 에이전트에게는 문제가 됩니다. 매번 $0.01를 지불하기 전에 멈춰서 가스 토큰을 확보할 수는 없고, 만약을 위해 비축분을 보유하는 것도 자동화된 흐름의 취지를 무색하게 만듭니다.
USDC 정산은 EIP-3009(transferWithAuthorization)로 이 문제를 우회합니다: 에이전트는 트랜잭션을 직접 제출하거나 가스 토큰을 보유하지 않고도 전송에 서명할 수 있습니다. 에이전트는 서명만 하고, 그 트랜잭션을 온체인에 제출하고 가스를 지불하는 쪽은 facilitator입니다. exact과 upto 정산은 일반적으로 USDC에는 EIP-3009를, EIP-3009를 지원하지 않는 다른 ERC-20에는 Permit2를 사용합니다. batch-settlement은 여전히 요청마다 에이전트가 서명하도록 하지만, 판매자는 각 호출을 개별적으로 정산하는 대신 나중에 온체인에서 배치로 상환합니다. Circle Gateway는 같은 고빈도 사례를 위해 관련된 나노페이먼트 패턴을 사용합니다. USDC가 달러로 가격이 매겨진다는 점도 이를 단순하게 만듭니다: 양쪽 모두 $0.01 청구에 대해 환율 계산을 할 필요가 없습니다.
여기까지가 결제 자체에 관한 내용입니다. 수신 주소가 단순한 외부 소유 지갑이라면, 그게 전부입니다: 배포 단계 없이 그냥 USDC를 받습니다. 이 가이드 앞부분에서 구축한 것과 같은 스마트 계정이라면, x402 흐름 바깥의 두 시점에서 여전히 가스가 관여됩니다: 처음 자금을 받을 때 온체인에 배포되는 시점, 그리고 모은 USDC를 트레저리 지갑으로 인출할 때입니다. 우리의 Gas Manager는 이 두 시점의 가스를 후원할 수 있습니다. 어느 쪽이든, facilitator가 이미 이를 처리하므로 Gas Manager가 x402 결제 자체를 정산하는 데 관여하지는 않습니다.
Base는 대부분의 툴링에서 기본 네트워크입니다. 원래의 레퍼런스 facilitator가 그곳에서 실행되고 대부분의 기존 x402 통합이 이미 거기에 있기 때문이지만, x402 v2가 Base에만 국한된 것은 아닙니다. 이는 어떤 EVM 체인(Ethereum mainnet과 Polygon 포함)뿐 아니라 Solana, TON, Algorand, Stellar, Aptos, Hedera, Keeta, NEAR, Concordium, XRPL도 다루며, facilitator들이 지원을 추가함에 따라 더 많은 체인이 추가될 것으로 예상됩니다. "Ethereum에서 USDC로 결제"가 오늘 실제로 여러분에게 작동하는지는 프로토콜 자체가 아니라 선택한 facilitator가 해당 네트워크를 구현했는지에 달려 있습니다.
x402는 더 넓은 에이전트 결제 스택에서 어디에 위치하나요?
x402는 빠르게 변화하는 분야의 한 프로토콜이며, 유일한 것은 아닙니다.
- Stripe와 Tempo는 MPP를 만들었습니다, 이는 스테이블코인에 국한되지 않는 동일한 402 패턴의 버전으로, 판매자가 같은 흐름에서 카드나 스테이블코인을 받을 수 있습니다(그리고 MPP는 x402의
exact흐름과 하위 호환되므로, 한쪽을 위해 만들어진 클라이언트가 대개 다른 쪽을 위해 만들어진 서버와 통신할 수 있습니다). - OpenAI와 Stripe의 ACP는 다른 영역을 다룹니다: 요청당 API 결제가 아니라 AI 기반 쇼핑을 위한 체크아웃입니다.
- Google의 AP2는 완전히 다른 문제를 다룹니다: 결제 수단이 카드든, 계좌 이체든, 스테이블코인이든 관계없이, 서명된 Checkout 및 Payment mandate를 사용해 사용자가 에이전트에게 지출을 승인했음을 증명하는 것입니다. AP2는 경쟁 관계의 정산 레일이 아니며, AP2 흐름이 스테이블코인으로 정산해야 할 때는 Google이 Coinbase, Ethereum Foundation, MetaMask와 함께 만든 A2A x402 확장을 통해 이루어지므로, x402는 그 대안이 아니라 그 아래에 있는 크립토 레일입니다.
프로토콜 환경이 계속 진화함에 따라, AgentPay는 판매자가 한 번 통합해 이들 모두를 지원할 수 있도록 돕는 프로토콜 독립적인 프록시로 존재합니다.
특정 빌드에서 x402와 MPP 중 선택하는 중이라면, x402 vs MPP 비교를 참고하세요. 인프라 제공업체를 선택하는 중이라면, Alchemy, Coinbase's Developer Platform, Circle, Crossmint, Privy, Turnkey를 비교한 지갑, 가스, 데이터 계층 비교를 참고하세요.
흔히 저지르는 실수
- 직접 확인하지 않은 견적에는 절대 서명하지 마세요. 402 응답은 여러분이 제어하지 않는 서버가 보낸 숫자일 뿐입니다. Alchemy CLI가 서명하기 전에 로컬에서 견적을 확인하는 것과 같은 방식으로, 서명하기 전에 네트워크, 자산, 금액을 확인하세요.
- 200 응답을 결제 증명으로 취급하거나, facilitator의
settled: true를 유일하게 필요한 증거로 취급하지 마세요. 정산 영수증 자체를 확인하고, 위에서 보여드린 것처럼 우리의 Transfers API를 사용해 주기적으로 온체인 현실과 대조하세요. - 자율 에이전트의 지출 한도를 생략하지 마세요.
--max-payment에 해당하는 것이 무엇이든, 작업을 완수할 수 있는 최소 값으로 설정하세요. 이것이 여러분의 에이전트와 부풀린 견적을 반환하는 서버 사이를 막는 유일한 장치이기 때문입니다. - 서명 검증, 트랜잭션 심사, 대규모 온체인 정산 제출이 실제로 여러분의 제품이 아니라면 직접 facilitator를 만들지 마세요. 호스팅된 것을 가리키고 엔지니어링 시간을 실제 서비스에 쓰세요.
- "x402를 지원한다"는 것이 "모든 네트워크와 스킴을 지원한다"는 뜻이라고 가정하지 마세요. 배포하기 전에 여러분의 특정 facilitator와 상대방이 실제로 어떤 스킴(
exact,upto,batch-settlement)과 어떤 체인을 구현하고 있는지 확인하세요. 네트워크 및 토큰 지원 페이지가 신뢰할 수 있는 출처입니다.
자주 묻는 질문
MCP 서버에 x402 결제를 추가하려면 어떻게 하나요?
x402 Foundation의 @x402/mcp 패키지에서 제공하는 결제 래퍼로, 요금을 부과하고 싶은 도구 핸들러를 감싸세요. 단, 이 서버는 facilitator에 등록되어 있고 어떤 지갑 주소가 결제를 받아야 하는지 알고 있어야 합니다. 전체 작동 예제는 위에 있습니다. 서버의 다른 모든 것은 여러분이 감싸지 않는 한 무료로 유지됩니다.
AI 에이전트가 x402를 통해 스테이블코인으로 API에 대한 요금을 지불하려면 어떤 인프라가 필요한가요?
세 가지가 필요합니다: USDC를 보유하고 서명할 수 있는 지갑, x402 핸드셰이크를 구사할 수 있는 서명된 결제 라이브러리 또는 CLI, 그리고 검증과 정산을 위한 판매자 측의 facilitator입니다. 직접 블록체인 노드를 운영하거나 가스 토큰을 보유할 필요는 없습니다. facilitator가 정산 가스를 부담합니다.
AI 에이전트에게 Ethereum에서 USDC 결제를 보낼 수 있는 기능을 부여하는 가장 좋은 방법은 무엇인가요?
Alchemy Agent Wallet 같은 범위가 제한된 세션이나 우리의 Wallet APIs를 통한 프로그래밍 방식 스마트 계정처럼 직접 서명할 수 있는 지갑을 부여하고, 이를 @x402/fetch 같은 x402 클라이언트 라이브러리나 Alchemy CLI의 x402 request 명령과 짝지으세요. 먼저 대상 facilitator가 실제로 해당 네트워크를 지원하는지 확인하세요. x402 v2는 Ethereum을 다루지만, 지원 여부는 프로토콜이 아니라 facilitator에 달려 있습니다.
온체인 결제를 위해 AI 에이전트에게 USDC 지갑을 부여하려면 어떻게 하나요?
테스트나 사람이 감독하는 에이전트의 경우, alchemy wallet connect --mode session(Alchemy CLI의 일부)은 에이전트에게 개인 키를 전혀 노출하지 않고 몇 분 만에 범위가 제한된 취소 가능한 지갑 세션을 생성합니다. 완전 자율 백엔드 에이전트의 경우, @alchemy/wallet-apis나 CDP 관리 지갑을 통해 스마트 계정을 프로비저닝하고 그 서명자를 x402 클라이언트 라이브러리에 넘기세요.
에이전트는 x402를 사용해 API 접근에 대해 어떻게 결제하나요?
에이전트는 API를 호출하고, 가격과 대상 주소가 담긴 402를 받고, 서버가 허용하는 스킴에 대해 결제에 서명하고, 서명된 결제를 첨부해 같은 요청을 재시도합니다. 서버는 facilitator를 통해 검증하고 정산한 다음, 같은 왕복 과정에서 리소스를 반환합니다.
크립토 결제로 AI 에이전트의 API 사용량을 계측하고 요금을 부과하려면 어떻게 하나요?
호출당 균일 요금에는 exact 스킴을, 사용량에 따라 비용이 달라질 때는 upto을 사용하고, 정산된 각 결제의 지불자 주소를 그것이 지불한 도구나 엔드포인트와 함께 기록하세요. 단일 정산 보고서를 신뢰하기보다, 우리의 Transfers API 같은 것을 사용해 그 원장을 온체인 전송 내역과 주기적으로 대조하세요.
에이전트 기반 크립토 결제와 온체인 커머스에 가장 좋은 인프라는 무엇인가요?
스택의 얼마나 많은 부분(지갑 커스터디, 결제 레일, 가스, 온체인 데이터)을 하나의 제공업체에서 원하는지, 아니면 여러 곳에서 조립하고 싶은지에 달려 있습니다. 정확히 그 스택을 기준으로 Alchemy, Coinbase's Developer Platform, Circle, Crossmint, Privy, Turnkey를 비교한 전체 내용은 우리의 인프라 비교 페이지에 있습니다.
AP2는 무엇이고 x402와 어떤 관계인가요?
AP2는 서명된 Checkout 및 Payment mandate를 사용해 사용자가 에이전트의 지출을 승인했음을 증명하는 Google의 결제 수단 독립적 프레임워크입니다. 이는 x402를 대체하는 것이 아니라 그 위에 위치합니다: AP2 흐름이 스테이블코인으로 정산해야 할 때는 Google이 Coinbase, Ethereum Foundation, MetaMask와 함께 만든 A2A x402 확장을 통해 이루어집니다.
에이전트 커머스란 무엇이고 어떤 인프라가 필요한가요?
에이전트 커머스란 AI 에이전트가 매번 사람이 체크아웃을 클릭하지 않고도 상품, 서비스, API 접근을 발견하고, 결제하고, 대가로 결제를 받는 것을 말합니다. 이를 위해서는 자금이 있는 지갑, 요청 단위로 가치를 이동시키는 x402나 MPP 같은 결제 레일, 에이전트가 네이티브 토큰을 필요로 하지 않도록 하는 가스 처리, 그리고 에이전트가 무엇에 지불할지 결정하고 그것이 도착했는지 확인할 수 있는 충분한 온체인 또는 카탈로그 데이터가 필요합니다.
에이전트가 유료화된 온체인 서비스에 접근할 수 있도록 x402 결제 프로토콜을 구현하려면 어떻게 하나요?
클라이언트 측에서는 x402 클라이언트 라이브러리(@x402/fetch, @x402/axios, 또는 MCP 클라이언트 래퍼)를 설치하고, 지갑 서명자와 함께 결제 스킴을 등록한 다음, 기존 HTTP 클라이언트나 MCP 클라이언트를 이것으로 감싸세요. 그러면 402에 대한 결제가 그 이후로 자동화됩니다. 위의 구매자 측 코드는 HTTP와 MCP 두 경우를 모두 다룹니다.
AI 에이전트는 어떻게 온체인으로 결제를 받나요?
다른 x402 판매자와 같은 메커니즘입니다: 에이전트가 운영하는 서비스는 x402로 자신의 엔드포인트나 MCP 도구에 가격을 매기고, 자신 또는 운영자가 제어하는 지갑으로 결제를 받고, 이 가이드 앞부분에서 구축한 MCP 서버와 정확히 같은 방식으로 facilitator를 통해 정산합니다. 결제를 받는 것과 지불하는 것은 요청의 반대 방향에서 본 같은 프로토콜입니다.
유료 MCP 도구 구축 시작하기
Alchemy CLI로 에이전트에게 범위가 제한된 지갑을 부여하고, x402로 도구를 보호하고, 우리의 Transfers API로 정산을 확인하세요. 아니면 facilitator 연결을 건너뛰고 AgentPay를 통해 에이전트 결제를 받으세요. 더 넓은 스택(커스터디, 레일, 가스, 데이터)에 대해서는 에이전트 결제를 위한 최고의 인프라부터 시작하세요.
관련 개요
금융2026년 7월 7일
에이전트 결제를 위한 최고의 인프라: 2026년 비교
에이전트 결제를 위한 최고의 인프라를 비교합니다: Alchemy, Coinbase CDP, Circle, Crossmint, Privy, Turnkey가 에이전트 지갑, x402, 가스를 어떻게 처리하는지 살펴봅니다.
금융2026년 3월 18일
x402 vs MPP: 에이전트 결제 프로토콜 비교
x402와 MPP는 모두 AI 에이전트가 HTTP를 통해 API 호출에 대한 비용을 지불할 수 있게 하지만, 결제 레일, 세션 지원, 프로토콜 수준의 프리미티브에서 차이가 있습니다. 두 프로토콜을 비교해봅니다.
금융2026년 6월 24일
에이전트 결제란? AI 에이전트가 API, 데이터, 컴퓨팅 비용을 지불하는 방법
에이전트 결제를 통해 AI 에이전트는 API, 데이터, 컴퓨팅 등 필요한 항목의 비용을 제한된 범위 내에서 자율적으로 지불할 수 있습니다. 작동 방식과 실제 에이전트 워크플로우에서 중요한 이유를 알아보세요.

블록체인 매직을 만드세요
Alchemy는 가장 강력한 Web3 개발자 제품 및 도구를 리소스, 커뮤니티, 그리고 전설적인 지원과 결합합니다.