니가타에서 홈페이지 제작을 하고 있는 개인 개발자입니다. 얼마 전, AI 에이전트(AI Agent)를 대상으로 일본의 법인 데이터를 종량제로 판매하는 API를 만들어 공개했습니다. 그러자 게재된 지 얼마 지나지 않아, 해외 에이전트가 사람의 개입 없이 자동으로 구매해 나갔습니다. 금액은 아주 적지만, '인간이 한 번도 개입하지 않는 판매'가 성립된 순간이었습니다.

이 기사에서는 만들 때 고민했던 점과 구현 과정에서 빠졌던 함정들을 정리합니다.

x402란 무엇인가 (30초 버전)

x402는 HTTP의 402 Payment Required를 사용한 결제 프로토콜입니다. 에이전트가 API를 호출(Call) → 서버가 402와 가격을 반환 → 에이전트의 지갑(Wallet)이 USDC로 서명 → 재전송 → 데이터 반환. API 키도 계정 등록도 필요 없으며, "결제하는 지갑 = 계정"이 됩니다. Coinbase가 주도하고 있으며, 현재는 Linux Foundation 산하에 있습니다. AWS, Google, Visa 등 40개 기업이 참여하고 있습니다.

무엇을 만들 것인가

x402는 아직 새로운 결제 방식이라 대응하는 서비스도 그리 많지 않습니다. 몇 가지 실제로 만져보며 느낀 점은, **LLM(Large Language Model)이 원리적으로 정답을 보장할 수 없는 "공적인 1차 데이터의 결정적인 검증"**에 가치가 있을 것 같다는 점이었습니다. 일본의 공공 데이터는 에이전트가 사용할 수 있는 형태로 거의 정비되어 있지 않습니다. 그래서 "일본의 법인 데이터"를 선택했습니다.

만든 것: Kaisha API

법인 해결 /resolve
— 사명(표기 불일치 흡수) 또는 법인 번호 13자리 → 정식 명칭, 소재지, 법인 종류, 존속 상태. 국세청의 법인 번호 공표 데이터 전체 576만 개 -
인보이스 대조 /invoice/verify
— 적격 청구서 등록 번호(T+13자리)를 국세청 공표 데이터 505만 건과 실재 여부 대조. 이는 x402 상에서 세계 유일일 것입니다 (LLM은 원리적으로 할 수 없는 결정적 검증입니다) -
영업일·공휴일 /calendar/*
— 내각부 데이터로 영업일 계산

가격은 1회 호출당 $0.002~$0.01. USDC로 결제하며, Base와 Solana 모두 대응합니다.

스택은 Cloudflare Workers + Hono + D1입니다. 결제는 @x402/hono 미들웨어를 하나 끼워 넣는 것만으로 끝납니다.

빠지기 쉬운 함정 (이것이 본론)

D1의 SQL 문 상한은 "10만 바이트"

576만 행의 INSERT를 밀어 넣을 때, 500행씩 나누어 실행했음에도 SQLITE_TOO_BIG 에러가 발생했습니다. 원인은 글자 수가 아니라 UTF-8 바이트 수의 상한이었습니다. 일본어는 1글자가 3바이트이므로 글자 수 카운트는 함정입니다. 80KB 바이트 단위로 끊어서 해결했습니다.

D1 무료 범위는 "1 DB당 500MB"

전국 데이터는 약 1GB입니다. 월 $5의 Workers Paid 플랜을 쓰면 해결될 문제지만, 고집을 부려 6개의 DB로 분할(법인×4, 인보이스×2)하여 고정비 제로를 유지했습니다. 샤드 키(Shard Key)는 "번호의 마지막 2자리 % N"입니다. 마지막 1자리로 하면 10종류를 4개로 나누게 되어 30/30/20/20으로 치우치기 때문에, 2자리(00-99)를 사용하는 것이 포인트입니다.

Solana의 판매자는 "ATA"를 만들어 두지 않으면 모든 결제가 실패한다

이것이 가장 큰 배움이었습니다. x402에서 Solana 대응을 선언하더라도, 수취 지갑에 USDC 토큰 계좌(ATA, Associated Token Account)가 없으면 모든 결제가 온체인 시뮬레이션에서 실패합니다 (InstructionError: InvalidAccountData). 에러 메시지만으로는 원인을 파악하기 어려우므로, Solana를 대응하는 판매자는 처음에 자신에게 USDC 1엔어치를 보내거나 ATA를 명시적으로 생성해 두어야 합니다.

/openapi.json이 필수

x402scan에 게재할 때 .well-known/x402는 구식 취급을 받으며, 현재는 OpenAPI 문서를 오리진(Origin) 직하단에 두는 것이 등록 요건입니다. 무료 엔드포인트에는 "security": []를 붙이지 않으면 "402를 반환하지 않는다"며 거절당합니다. 등록하면 각 엔드포인트를 하나씩 실제로 402 핸드셰이크(Handshake)로 검증합니다 (철저합니다).

첫 매출의 내용

게재 직후, 해외 지갑들이 저렴한 순서대로 모든 엔드포인트를 한 번씩 구매해 나갔습니다. 신규 API를 자동으로 평가하며 돌아다니는 에이전트 운영자인 듯합니다. 에이전트 경제의 구매자는 이렇게 자동으로 신상품을 찾아내고 시도한다는 것을 실감했습니다.

솔직한 현실과, 그럼에도 불구하고 하는 이유

• 시장은 이제 막 시작된 단계이며, 비슷한 생각을 하는 사람들도 당연히 존재합니다
• 그럼에도 불구하고, 결정적인 데이터 검증이나 MCP를 통한 배포까지 포함하여 완성도를 높인다면 차별화할 수 있다고 생각합니다
• 고정비 0원, 한계 비용 거의 0원이므로, 이것은 "에이전트 경제가 올 것인가"에 대한
  **매우 저렴한 콜 옵션 (Call Option)**입니다

에이전트가 사용하는 방법

MCP 대응 클라이언트 (Claude Code 등)라면 한 줄이면 됩니다:

claude mcp add kaisha -e EVM_PRIVATE_KEY=0x<USDC가 들어있는 Base 지갑> -- npx -y kaisha-mcp

소스: https://github.com/vladic-corp/kaisha-mcp ／ npm: https://www.npmjs.com/package/kaisha-mcp

질문이나 감상은 언제든 환영합니다. 특히 "에이전트에게 구매시키고 싶은 일본의 데이터"에 대한 아이디어가 있다면 듣고 싶습니다.

Discussion