계정 없이 암호화폐 지갑으로 도메인 결제하기

“AI 에이전트가 대신 도메인을 살 수 있다”는 설명은 결국 모두 같은 벽에 부딪힙니다. 에이전트가 실제로 결제하는 방법은 무엇일까요? 신용카드는 사람이 직접 양식에 숫자를 입력하고, 부정 사용 검사를 통과하고, 휴대전화로 전송된 일회용 코드를 확인한다고 가정합니다. AI 에이전트는 그 어느 것도 할 수 없습니다. Namefi의 해법은 카드도, 저장된 결제 수단도, Namefi 계정도 전혀 필요 없는 결제 경로입니다. 그 자리에서 결제에 서명하는 암호화폐 지갑만 있으면 됩니다. 이 글에서는 이 흐름이 실제로 어떻게 작동하는지, 서명 체계가 에이전트에게 허용하는 일과 허용하지 않는 일은 무엇인지, 언제 API 키 결제를 선택해야 하는지 자세히 살펴봅니다.

에이전트 상거래에서 결제가 가장 어려운 이유

에이전트가 무언가를 구매하게 할 때 검색과 가격 확인은 결코 어려운 부분이 아니었습니다. 둘 다 읽기 전용 호출이므로 승인이 필요하지 않고, 에이전트가 잘못 처리해도 금전적 손실이 없습니다. 결제는 다릅니다. 실수하면 실제 돈을 잃는 유일한 단계이며, 오늘날 널리 쓰이는 모든 결제 시스템은 사람이 결제를 승인한다고 가정하기 때문입니다.

저장된 카드가 가장 분명한 예입니다. 카드 저장 결제는 결제 시점에 카드 소유자가 다시 승인하지 않아도 가맹점의 요청만으로 나중에 다시 청구할 수 있는 토큰을 결제 처리업체에 넘기는 방식입니다. 신뢰하는 구독 서비스가 매월 요금을 청구하는 데는 적합합니다. 하지만 자율 프로세스에는 잘 맞지 않습니다. 저장된 카드 토큰을 가진 주체는 누구든 청구할 수 있고, 실질적인 방어책은 소프트웨어가 이를 악용하지 않으리라 믿거나 나중에 명세서에서 악용 사실을 발견하는 것뿐입니다. 에이전트에게 도메인 등록에만, 그것도 최대 $50까지만 결제할 수 있는 저장 카드를 줄 방법은 없습니다. 카드는 자신이 어떤 용도로 사용되는지 알지 못합니다.

에이전트 네이티브 도메인 등록대행자란?에서는 API가 있다는 사실만으로는 부족하며, 결제가 에이전트가 서비스를 사용할 수 있게 하는 핵심 기반 요소 중 하나라고 폭넓게 설명합니다. Namefi의 암호화폐 지갑 결제는 이 요구에 대한 구체적인 해답입니다. 서비스가 원할 때마다 청구할 수 있는 저장된 자격 증명 대신, 지갑은 각 결제마다 오직 해당 거래와 해당 가격에만 유효한 서명을 생성합니다.

Namefi의 해법: 계정 생성 없는 지갑 서명 결제

Namefi에서 일반적으로 도메인을 등록할 때는 API 키를 사용하고, 충전된 NFSC(Namefi Service Credit) 잔액에서 비용이 차감됩니다. 자세한 내용은 Namefi에서 AI 에이전트로 도메인을 등록하는 방법에서 다룹니다. 이 경로에는 계정이 필요합니다. 누군가 지갑으로 API 키를 생성하고 NFSC 잔액을 충전하면, 등록할 때마다 해당 API 키를 통해 잔액이 차감됩니다.

지갑 서명 경로는 이 모든 과정을 건너뜁니다. Namefi가 공개한 지갑 결제용 기계 판독 문서에 따르면, 에이전트의 지갑은 Namefi 계정을 만들거나 API 키를 어디에도 보관하지 않고 USDC로 직접 결제할 수 있습니다. 구매자의 지갑이 결제 승인에 서명하고, 서명이 도착하면 등록이 처리됩니다. 미리 생성할 것도 없고 나중에 악용될 수 있는 상시 권한도 없습니다. 지갑은 서명하는 순간에만 작동합니다.

Namefi는 지갑이 서명을 생성하는 세 가지 방식을 문서화했으며, 아래에서 단계별로 설명합니다. 기본 경로이자 이 글에서 중점적으로 다루는 x402 프로토콜, Machine Payable Protocol(MPP)의 챌린지-응답 방식, 그리고 두 단축 경로를 모두 사용하지 않는 지갑을 위한 수동 EIP-712 서명 경로입니다.

x402 흐름 단계별 살펴보기

x402는 Cloudflare, AWS, Stripe 등의 기업이 지원하는 개방형 표준입니다. 오랫동안 쓰이지 않던 HTTP 402 Payment Required 상태 코드를 되살려, 별도의 결제 페이지로 리디렉션하는 대신 일반 요청 안에서 온체인 결제를 구조적으로 요구할 수 있게 합니다. Namefi는 이를 도메인 등록 엔드포인트에 구현했습니다.

결제 없는 요청. 에이전트는 Namefi의 /x402/domain/{domainName} 엔드포인트에 일반 GET 요청을 보냅니다. 아직 가격을 모르므로 결제는 첨부하지 않습니다.
가격이 포함된 HTTP 402. Namefi는 402 Payment Required로 응답하고 응답 본문에 네트워크, 허용 자산(USDC), 금액 등 결제 옵션을 포함합니다. 이 점에서 x402는 일반 오류와 다릅니다. 단순히 “안 된다”고 알리는 대신, 402 상태가 유효한 결제를 구성하는 데 클라이언트가 필요한 모든 정보를 전달합니다.
지갑이 EIP-3009 transferWithAuthorization에 서명. 별도의 블록체인 트랜잭션을 보내고 확정을 기다리는 대신, 지갑은 서명으로 승인된 토큰 전송을 위해 특별히 설계된 Ethereum 표준인 EIP-3009에 따라 서명을 생성합니다. EIP-3009의 transferWithAuthorization 함수는 토큰 보유자가 특정 금액을 특정 수신자에게 전송하도록 승인하는 메시지에 서명할 수 있게 합니다. 이 승인은 정해진 시간 범위(validAfter / validBefore) 안에서만 유효하며, 제삼자가 이를 온체인에 제출할 수 있습니다. Namefi 문서는 이 단계 전에 Namefi 계정이나 EIP-712 서명이 필요하지 않다고 명확히 밝힙니다. 지갑은 독립된 USDC 전송 승인에 서명할 뿐입니다.
결제 헤더와 함께 요청 재전송. 에이전트는 이번에는 서명된 승인이 담긴 X-PAYMENT 헤더를 추가해 원래 요청을 다시 보냅니다.
검증, 정산, 등록. Namefi는 서명을 검증하고 도메인 등록 워크플로를 시작한 뒤 결제를 정산합니다. USDC가 구매자의 지갑에서 이동하고, 등록은 API 키 경로와 같은 방식으로 진행됩니다. 여기에는 기본적으로 도메인을 NFT, 즉 토큰화 도메인으로 발행하여 결제한 바로 그 지갑에 귀속시키는 과정도 포함됩니다.

이 과정 어디에서도 에이전트가 Namefi 계정을 만들거나, Namefi가 별도 승인 없이 재사용할 수 있는 자격 증명을 저장하거나, 실제 결제 순간 전에 자금에 대한 통제권을 넘길 필요가 없습니다. 서명은 지갑이 이 특정 금액의 특정 USDC 전송을 제한된 시간 범위 안에서 승인했다는 사실만 증명합니다.

MPP 챌린지-응답 방식

x402가 기본 경로지만, Namefi는 다른 결제 패턴을 사용하는 지갑이나 에이전트 프레임워크를 위한 두 번째 경로도 문서화했습니다. Machine Payable Protocol(MPP)입니다. 구조적으로는 x402를 뒤집은 모습으로, 단순한 402 응답 대신 챌린지-응답을 사용합니다.

보호된 엔드포인트에 보낸 첫 요청은 다시 402 Payment Required를 반환하지만, 이번에는 단순 가격 견적 대신 서명된 챌린지를 전달합니다.
클라이언트는 결제 지갑으로 챌린지에 서명합니다. 일반적으로 이 서명 단계를 처리하도록 특별히 만들어진 Namefi의 mppx 명령줄 도구를 사용합니다.
클라이언트는 생성된 서명을 Authorization 헤더에 첨부해 원래 요청을 다시 보냅니다.

결과는 x402와 같습니다. 저장된 자격 증명 없이 요청마다 지갑이 서명하는 결제이며, 402 응답에 가격만 담는 대신 서명된 챌린지를 주고받는 핸드셰이크로 구성됩니다. 어떤 경로를 사용할지는 에이전트의 결제 도구가 이미 지원하는 방식에 따라 달라집니다. Namefi의 엔드포인트는 두 방식 모두를 처리합니다.

수동 EIP-712 경로

두 단축 경로를 모두 사용하지 않는 지갑이나 스크립트를 위해 Namefi는 더 낮은 수준의 완전 수동 서명 경로를 제공합니다. 이 경로는 EIP-3009 자체의 기반이기도 한 EIP-712 타입이 지정된 구조화 데이터(typed structured data) 서명을 사용합니다. 이 방식으로 서명한 요청에는 세 가지 헤더가 포함됩니다. x-namefi-signer(서명 지갑 주소), x-namefi-signature(16진수(hex)로 인코딩된 서명), x-namefi-eip712-type(서명을 생성할 때 사용한 타입 데이터 스키마)입니다. 페이로드는 payloadType, payload 자체, timestamp, nonce가 들어 있는 엔벌로프 구조로 감쌉니다.

안전을 위해 중요한 세부 사항은 두 가지입니다. 서명은 300초 후 만료되며 nonce는 한 번만 사용할 수 있습니다. 전송 중 가로챈 서명이나 나중에 재전송한 요청은 작동하지 않습니다. 이미 서명이 만료되었거나 nonce가 사용되었기 때문입니다. 또한 Namefi 문서에는 서명이 일치해야 하는 정확한 스키마가 변경될 수 있으므로, 현재 사용 중인 EIP-712 타입 정의를 통합 코드에 하드코딩하지 말고 요청 시점에 /v-next/eip712/ 엔드포인트에서 가져와야 한다고 명시되어 있습니다.

Namefi는 스마트 컨트랙트 지갑의 서명 방식도 문서화했습니다. 승인된 외부 소유 계정(EOA)은 ERC-1271 또는 더 새로운 EIP-7702에 따라 컨트랙트 지갑을 대신해 서명할 수 있습니다. 단, 컨트랙트는 API가 검증할 수 있는 approvedSigners(address) 확인 기능을 구현해야 합니다.

보안 모델: 에이전트가 할 수 있는 일과 할 수 없는 일

이 서명 체계가 실제로 제한하는 범위를 정확히 이해해야 합니다. 메커니즘이 제공하는 것보다 더 강한 보장을 제공한다고 설명해서는 안 됩니다.

제한하는 것. 위 세 방식 모두에서 각 결제는 하나의 특정 거래에 연결된 새로운 서명을 사용합니다. 특정 금액을 Namefi가 지정한 주소로 보내는 거래이며 짧은 시간 범위 안에서만 유효합니다. EIP-712 경로에서는 재전송할 수 없는 일회용 nonce가 사용됩니다. 지갑은 Namefi에 향후 결제를 자체적으로 시작할 수 있는 상시 권한을 절대 넘기지 않습니다. 저장된 카드와 비교해 보세요. 가맹점이 카드 토큰을 가지고 나면, 토큰 자체에는 다음 달에 청구할 금액을 제한하거나 침해된 시스템이 이를 재사용하지 못하게 하는 기능이 없습니다. 어느 경로에서도 지갑의 개인 키는 지갑 밖으로 나가지 않습니다. 에이전트가 지갑에 특정 요청 하나를 위한 서명을 생성해 달라고 요청하며, 그 범위를 넘어서는 일은 일어나지 않습니다.

자체적으로 제한하지 않는 것. Namefi 문서에는 프로토콜 자체가 집행하는 거래당 달러 지출 상한이 내장되어 있다고 설명되어 있지 않습니다. 여기서 보안은 서명 만료와 nonce의 일회 사용에서 나오며, 서명된 요청 하나가 승인할 수 있는 금액의 상한에서 나오지 않습니다. 실제로 에이전트의 지출 규칙은 이 메커니즘 외부에서 정해집니다. 지갑에 얼마나 많은 USDC를 넣는지, 그리고 에이전트와 지갑의 개인 키 사이에 어떤 정책 계층을 두는지에 달려 있습니다. 정책 계층의 예로는 두 번째 승인을 요구하는 멀티시그 지갑이나 에이전트가 서명하기 전에 반드시 거치게 하는 사람의 확인 단계가 있습니다. 에이전트 네이티브 도메인 등록대행자란?과 Namefi에서 AI 에이전트로 도메인을 등록하는 방법에서도 같은 내용을 안전장치의 관점에서 다룹니다. 무인 프로세스가 사용해도 감당할 수 있는 만큼만 지갑에 넣고, 어느 단계에서 사람의 승인이 필요한지 미리 결정해야 합니다.

상시 자격 증명이 없고, 거래별 승인이 제한되어 있으며, 충전 금액이 실질적인 지출 한도가 된다는 조합은 저장된 카드와는 근본적으로 다른 형태의 위험을 만듭니다. 같은 구조에 암호화폐만 입힌 것이 아닙니다. 유출된 카드 번호나 침해된 결제 토큰은 누군가 알아차리고 취소할 때까지 반복해서 청구될 수 있습니다. 수동 EIP-712 서명은 발급 후 300초가 지났거나 nonce가 이미 사용되면 재사용할 수 없습니다. x402의 EIP-3009 승인은 validAfter/validBefore 시간 범위를 벗어나면 효력을 잃습니다. MPP 서명의 만료 및 재사용 방지 조건은 해당 챌린지 규격에 따라 별도로 확인해야 합니다.

API 키 또는 NFSC 결제를 대신 사용해야 할 때

지갑 서명 경로는 구매 전에 계정이 전혀 존재하지 않아야 한다는 점이 핵심일 때 적합합니다. 완전 자율 스크립트, 공유 로그인 자격 증명 없이 다른 사람을 대신해 작동하는 에이전트, 또는 암호화폐 네이티브 지갑만을 유일한 신원으로 유지하려는 경우가 여기에 해당합니다. 그렇다고 모든 상황에서 자동으로 올바른 선택이 되는 것은 아닙니다.

Namefi에서 AI 에이전트로 도메인을 등록하는 방법에서 자세히 설명하듯, 충전된 NFSC 잔액을 사용하는 API 키 결제는 다음 경우에 더 적합합니다. 에이전트가 도메인을 반복해서 등록해 매번 새로운 결제에 서명하는 것보다 상시 확인 가능한 잔액이 유리할 때, 온체인 전송 내역을 다시 조합하는 대신 운영자가 단일 대시보드에서 지출을 보고 싶을 때, 또는 클라이언트가 헤더 값을 안전하게 저장할 수 있지만 개인 키를 보관하고 서명하기는 어려울 때입니다. 결제가 정산된 후 두 경로는 동일한 등록 및 DNS 작업으로 이어집니다. 선택의 차이는 승인 방식이지, 이후 등록하거나 관리할 수 있는 대상이 아닙니다.

자주 묻는 질문

암호화폐 지갑으로 결제하려면 Namefi 계정이 필요한가요?

아니요. x402와 MPP 흐름은 모두 미리 Namefi 계정을 만들거나 API 키를 생성하지 않고도 지갑 서명 결제로 도메인 등록을 정산합니다. API 키는 NFSC 잔액 결제 경로에만 필요합니다.

Namefi는 지갑 결제에 어떤 암호화폐를 받나요?

USDC입니다. Namefi의 x402 엔드포인트는 USDC로 가격을 제시하고 결제를 정산합니다. 따라서 가격 제시 시점과 결제 정산 시점 사이에 ETH 같은 변동성 자산에서 발생할 수 있는 가격 변동을 피할 수 있습니다.

지갑 결제에 서명하는 것은 에이전트에게 개인 키를 주는 것과 같나요?

아닙니다. 지갑은 개인 키 자체를 노출하지 않고 서명을 생성합니다. 에이전트 또는 에이전트가 호출하는 도구는 지갑에 구체적이고 범위가 제한된 승인에 서명해 달라고 요청하며, 개인 키는 전체 과정 동안 지갑 안에 남습니다.

이전에 만든 결제 서명을 다른 사람이 재사용할 수 있나요?

수동 EIP-712 경로에서는 불가능합니다. 서명은 300초 후 만료되고 각 nonce는 한 번만 사용할 수 있습니다. x402 흐름의 EIP-3009 승인도 validAfter/validBefore 시간 범위로 제한됩니다. 따라서 가로챈 서명은 저장된 카드 토큰처럼 무기한 유지되지 않고 짧고 한정된 수명만 갖습니다.

이 방식으로 결제하면 도메인이 자동으로 토큰화되나요?

기본적으로 그렇습니다. 다른 수신 지갑을 지정하지 않는 한, 등록된 도메인은 결제한 지갑과 같은 지갑에 NFT로 발행됩니다. API 키 경로와 동일한 토큰화 방식입니다. 지갑 네이티브 결제나 토큰화 소유권을 전혀 제공하지 않는 등록대행자와 어떻게 다른지는 Cloudflare vs Name.com vs Namefi: 에이전트 네이티브 등록대행자에서 확인할 수 있습니다.

지갑 결제가 저장된 카드 결제보다 더 안전한가요?

위험을 완전히 없애는 것이 아니라 서로 다른 종류의 위험을 제한합니다. 침해된 시스템이 무기한 재사용할 수 있는 상시 자격 증명은 없으며, 각 경로의 서명은 요청별로 새로 생성됩니다. 수동 EIP-712는 300초 만료와 일회용 nonce를, x402의 EIP-3009 승인은 validAfter/validBefore 시간 범위와 nonce를 사용합니다. MPP의 만료 및 재사용 방지 조건은 해당 챌린지 규격에 따릅니다. 하지만 프로토콜 자체는 서명된 요청 하나가 승인할 수 있는 금액을 제한하지 않습니다. 따라서 에이전트가 지출할 수 있는 실질적인 상한은 지갑에 넣은 금액과 그 앞에 둔 추가 승인 정책(예: 멀티시그)에 따라 결정됩니다.

Namefi에서 지갑으로 도메인 구매하기

에이전트를 사용하는 목적이 에이전트와 구매 사이에 사람의 계정이 끼어들지 않게 하는 것이라면, Namefi의 지갑 서명 결제는 바로 그 목적에 맞게 만들어졌습니다. ICANN 공인 도메인 등록을 한 번의 서명된 USDC 승인으로 결제하고, 토큰화 소유권은 결제한 지갑에 들어옵니다. 전체 작동 방식은 namefi.io/web3/llms.txt에서 확인할 수 있으며, 더 폭넓은 설정부터 시작하려면 Namefi에서 AI 에이전트로 도메인을 등록하는 방법을 참고하세요.

Namefi에서 도메인을 검색하고 등록하세요.

출처 및 추가 자료

Namefi — namefi.io/web3/llms.txt (x402 흐름, MPP 챌린지-응답 방식, 수동 EIP-712 서명 경로, 서명 만료 및 nonce 일회 사용 규칙, ERC-1271/EIP-7702 스마트 컨트랙트 지갑 서명에 관한 1차 출처)
Namefi — namefi.io/llms.txt (NFSC/API 키 결제 경로와 위 지갑 결제 참고 자료 안내)
x402.org — x402: 인터넷 네이티브 결제 표준 (Namefi 흐름이 구현하는 HTTP 402 기반 개방형 결제 프로토콜)
Ethereum — EIP-3009: 승인을 통한 전송 (transferWithAuthorization 단계의 기반이 되는 서명 표준, validAfter/validBefore 시간 제한, 일회용 무작위 nonce)
Ethereum — EIP-721: 대체 불가능 토큰 표준 (토큰화 도메인 소유권의 기반이 되는 NFT 표준)
Namefi — Namefi에서 AI 에이전트로 도메인을 등록하는 방법 (API 키/NFSC 결제 경로와 폭넓은 안전장치 안내)
Namefi — Cloudflare vs Name.com vs Namefi: 에이전트 네이티브 등록대행자 (에이전트용 등록대행자 세 곳의 지갑 네이티브 결제 비교)