x402 isn’t good (yet) — Jan Curn, Apify

한 줄 핵심

x402는 에이전트 결제를 위한 유망한 표준이지만, 아직은 402/401 충돌과 이중 지출 문제 같은 설계적 거칠음 때문에 실무 적용에 우회책이 필요하다는 주장이다.

시간별 요약

1. 0:00
   "MCP는 아직 좋지 않다"에 대한 응답 MCP가 초기에는 거칠었지만 결국 널리 채택된 사례를 들어, x402도 흥미롭지만 아직 완성형은 아니라고 본다. Apify는 x402를 통해 에이전트가 도구를 구매하는 방식의 표준화를 실험하고 있다.
2. 2:02
   Apify의 45,000개 도구와 x402 카탈로그 10배 확대 Apify는 약 45,000개의 actor를 가진 도구 마켓플레이스이며, 커뮤니티 판매 수익도 월 100만 달러를 넘는다. Coinbase와의 통합으로 x402 기반 시장에 20,000개 도구를 추가해 에이전트 결제 가능한 카탈로그를 크게 확장했다.
3. 4:47
   L402부터 Agent Pay까지 표준이 겹쳐지는 상황 L402, x402, Agent Pay, ACP, UCP 등 여러 결제 표준이 한꺼번에 등장하며 경쟁이 과열되고 있다. 에이전트 상거래가 커질수록 금융·결제 플레이어들이 각자 표준을 밀어붙이는 구도가 형성되고 있다.
4. 5:39
   암호화폐가 에이전트 결제에 잘 맞는 이유, 분쟁 포함 신용카드나 PayPal 같은 전통 결제수단은 미세결제에 비효율적이고, 에이전트 거래에서는 상대방 신원도 불분명해 분쟁형 결제를 허용하기 어렵다. 그래서 암호화폐처럼 비중앙화되고 일방향 정산이 가능한 수단이 에이전트 결제에 더 적합하다고 본다.
5. 8:25
   30년 된 상태 코드가 마침내 쓰이기 시작하다 x402는 HTTP의 402 payment required 상태 코드를 기반으로 하며, 서버는 첫 응답으로 반드시 402를 반환해야 한다. 클라이언트는 서명과 예산 할당을 보내고, facilitator가 이를 검증한 뒤 결제를 진행하는 흐름으로 동작한다.
6. 9:19
   x402 흐름과 이중 지출의 시간창 정산이 블록체인에 기록되기 전까지는 같은 지갑 자금으로 다른 요청을 보낼 수 있어 이중 지출 가능성이 남는다. 즉, 작업을 먼저 하고 나중에 정산하면 제공자가 비용을 떠안을 위험이 생긴다.
7. 11:10
   x402는 402를 원하고 MCP는 401을 원할 때 x402는 402를 요구하지만 MCP는 401을 요구해, 하나의 엔드포인트로 두 표준을 동시에 만족시키기 어렵다. 현재는 결제용 호스트를 따로 분리하는 경우가 많지만, 이는 비효율적인 중복 구조로 보인다.
8. 12:59
   정확한 결제에서 "최대 금액"까지, 그러나 해결되지 않은 문제 처음에는 고정 금액 exact 결제로 시작했고, 이후 최대 $5처럼 상한만 정하는 up to 결제가 추가됐지만 이중 지출 문제는 그대로 남아 있다. Apify처럼 실행 시간과 비용이 가변적인 작업에는 여전히 메터드 과금이 더 자연스럽다.
9. 13:55
   전액 결제 후 환불, 그리고 배치 정산 임시 해법으로는 먼저 전액을 청구하고 작업 후 남은 금액을 환불하는 방식이 가능하지만, 블록체인 거래가 두 번 발생해 느리고 번거롭다. 이후 등장한 batch settlement는 예치금과 오프체인 마이크로결제를 묶어 정산하는 방식으로, 더 현실적인 대안으로 제시된다.
10. 16:38
    AGI, 에이전트용 일반 인터페이스 Apify는 기존 API를 자주 바꾸지 않기 위해 agent general interface인 AGI를 따로 만들었다. 에이전트는 이 웹페이지에서 선불 토큰을 구매한 뒤 기존 API나 MCP를 통해 서비스를 이용할 수 있다.
11. 19:26
    지금 실제로 규모가 나는 곳 현재 x402 생태계는 아직 월 100만 달러 수준으로 작고 매우 초기 단계다. 하지만 토큰 보조금 시대가 끝나고 실제 비용을 지불해야 하는 순간이 오면, 외부 서비스를 구매하는 경제성이 커지면서 에이전트 상거래가 크게 성장할 것으로 본다.

실무 인사이트

• 에이전트 결제는 표준 채택보다 먼저 이중 지출 방지, 정산 지연, 가변 과금 같은 운영 문제를 해결해야 실무에 들어갈 수 있다.
• 기존 API를 직접 개조하기보다 에이전트 전용 진입점(예: AGI)과 기존 서비스 계층을 분리하면 표준 변화에 덜 흔들린다.
• 에이전트 상거래는 기술 데모보다도 결제 분쟁 처리, 정산 비용, 신뢰 모델을 먼저 설계해야 확장 가능하다.