x402에는 ‘중앙화된 책임’이 필요하다.

크립토슬레이트(CryptoSlate)의 Akiba(@akibablade)는 “x402의 31개 신규 취약점으로 인해 x402 암호화폐 결제의 99%가 자산 도난 및 공짜 쇼핑 위험에 노출됨(31 newly discovered vulnerabilities expose 99% of x402 crypto payments to asset theft and free shopping)”이라는 아티클을 게시하였다.

Source: 「When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments」

해당 기사는 USENIX Security 2026에 채택된 논문 「When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments」을 바탕으로 한다.

논문은 x402가 결제 증명 검증과 온체인 정산을 제3자 퍼실리테이터(Facilitator)에 위임하면서, 여러 독립 머천트가 사용하는 공유 결제 인프라에 신뢰와 검증 로직이 집중되는 구조를 문제 삼는다. 퍼실리테이터 하나의 결함이 다수 서비스로 확산될 수 있기 때문이다.

Source: 「When HTTP 402 Meets the Blockchain: Risks on Emerging x402 Payments」

연구진은 또한 퍼실리테이터가 지켜야 할 8개의 보안 규칙을 도출하고, 규칙 위반에서 Free Shopping, Asset Theft, Service Denial, Gas Abuse라는 네 가지 공격 유형을 찾아냈다. 이를 기반으로 주요 퍼실리테이터 15곳을 평가한 결과, 49건의 규칙 위반과 31건의 신규 취약점이 발견되었다. 이를 해당 운영사에 비공개로 전달한 결과, 현재 일부는 조치가 완료되었으며 나머지는 대응 중에 있다.

이러한 연구가 가능했던 배경에는 x402가 처음부터 개방형 프로토콜로 개발되었기 때문이다. 프로토콜 스펙과 레퍼런스 SDK가 공개돼 있었기에 연구진은 결제 흐름에서 지켜야 할 보안 규칙을 도출하고, 오픈소스 SDK와 직접 구축한 테스트용 머천트를 활용해 연구를 진행할 수 있었다.

물론 오픈소스가 취약점 자체를 완전히 없애주지는 않는다. 다만 외부에서 발견한 취약점을 공통 보안 기준으로 환원할 수 있는 경로를 제공한다. x402 프로토콜은 지난 4월 2일 리눅스 재단에 이관됐으며, x402 재단은 7월 14일 40개 회원사와 함께 정식 운영을 시작했다. 이에 따라 검증 결과를 개별 벤더의 수정에 그치지 않고 스펙과 레퍼런스 구현 차원에서 논의할 공식 통로가 마련됐다.

연구진 역시 취약점 공개를 넘어 민감한 공격 코드를 제거한 x402scope 공개 버전을 배포했다. 현재 코인베이스등 주요 생태계 참여자들과 해당 규칙 검사를 개발 및 배포 전 검증 워크플로에 통합하는 방안을 논의하고 있다.

프로토콜의 성숙도에 대한 이야기는 이쯤에서 마무리하겠다. 필자는 이 연구 결과에서 한 가지 더 근본적인 질문을 제기하고자 한다.

x402 자체를 중앙화하자는 것이 아니라, 누구나 참여할 수 있는 개방형 프로토콜 위에 검증 기준을 강제하고 정산 비용과 사고 손실을 부담하는 중앙화된 책임 계층이 필요하지 않은가?

중앙화가 보안을 자동으로 보장하지는 않지만, 결제에서는 권한을 행사하는 주체와 실패의 비용을 부담하는 주체가 일치해야 한다고 생각한다.

생각해보자, x402는 누구나 서버와 퍼실리테이터가 될 수 있도록 설계됐다. 그러나 완전히 무신뢰(trustless)적인 시스템은 아니다. 논문도 퍼실리테이터를 ‘신뢰를 부담하는 중개자(Trust-bearing intermediary)’로 정의한다. 검증과 정산을 위임받는 순간 퍼실리테이터에는 이미 상당한 신뢰가 요구된다.

문제는 신뢰는 집중됐지만 프로토콜 차원에서 그에 상응하는 자본, 책임과 지급 확실성을 요구하지 않는다는 점이다. 이 공백은 세 가지 설계에서 드러난다.

Source: Coinbase

• 첫째, verify는 카드의 승인(Authorization)보다 현재 시점의 정산 가능성을 확인하는 예측에 가깝다. 서명, 잔액, nonce와 만료 시각을 검사하지만 자금을 묶거나 nonce를 소비하지 않는다.
• 둘째, 소비자와 머천트를 모두 보호하기 위해 verify → business logic → settle이 분리됐다. 그러나 프로토콜에는 검증과 정산을 상태로 묶는 장치가 없어, 퍼실리테이터의 검증 결과를 믿고 실행한 작업의 손실은 온전히 머천트가 떠안는다.
• 셋째, 많은 퍼실리테이터가 온체인 정산 비용을 후원한다. 이 경우 공격자가 조작한 실행 경로가 퍼실리테이터의 가스 비용으로 이어질 수 있으며, 솔라나에서는 퍼실리테이터가 공격자 소유 계정의 rent까지 부담하도록 유도될 수 있다.

카드 결제에도 승인과 매입(Authorization and Capture)의 분리가 존재한다. 차이는 issuer가 승인 단계에서 이용 한도나 자금을 묶고, 네트워크 규칙에 따라 머천트에게 일정 수준의 지급 확실성을 제공한다는 점이다. 문제가 생기면 승인 취소, 차지백, 가맹점 제재와 분쟁 처리 절차도 작동한다.

x402에는 자금을 묶고 지급을 보증하는 issuer가 없다. 따라서 verify로 결제 가능성을 확인하고 비즈니스 로직을 실행한 뒤 settle을 진행한다. 문제는 두 엔드포인트가 상태를 공유하지 않아, 검증 이후 잔액, nonce, 유효기간이 바뀔 수 있다는 점이다. 서버가 정산 전에 되돌릴 수 없는 작업을 실행하면 머천트가 손실을 보고, 퍼실리테이터가 조작된 트랜잭션을 제출하면 가스나 보유 자산을 잃을 수 있다.

카드 네트워크는 이러한 신뢰의 비용을 issuer의 자본과 위험 관리 조직으로 부담하고 수수료로 회수한다. x402는 그 주체를 제거했지만 비용까지 없애지는 못했다.

따라서 현실적인 경로는 개방형 프로토콜 위에 책임 계층을 두는 것이 아닐까?

여기서 말하는 중앙화는 x402 전체를 하나의 사업자가 통제하는 구조가 아니다. 각 결제 경로에서는 책임 주체를 명확히 하되, 여러 사업자가 동일한 개방형 규격 위에서 경쟁하고 사용자가 다른 퍼실리테이터로 이동할 수 있어야 한다. 운영 책임은 집중하되 프로토콜의 개방성과 사업자 간 경쟁은 유지하는 구조이다.

클라우드플레어의 Monetization Gateway처럼 x402의 프로그래머블한 결제 형식은 유지하되, 결제 정책과 검증, 접근 제어를 하나의 통제 계층에서 처리하는 방식을 예로 들 수 있다. 전문 퍼실리테이터가 SLA, 가스 한도, 정산 전 재검증과 장애 대응을 제공하는 경로도 가능하다.

물론 ERC-8004와 평판 시스템을 대안으로 이야기할 수 있다. 그러나 평판은 위험을 판단하는 보조 신호일 뿐, 자금 예약이나 지급 보증을 직접 제공하지는 않는다. 필자는 이것만으로 책임의 공백을 메우기는 쉽지 않다고 생각한다.

또한 이러한 관점에서 디스커버리 레이어의 역할과 구조도 다시 생각해볼 필요가 있다. 단순히 이용 가능한 서비스를 보여주는 데서 그치지 않고, 어떤 리소스와 퍼실리테이터가 보안 기준을 충족하는지 선별하는 신뢰 및 라우팅 계층으로 확장될 수 있다. 지급 보증이 필요하다면 이를 명시적으로 제공하는 중앙화된 사업자와 결제 경로를 구분해 보여주는 방식이다. 이러한 관점에서 두 키플레이어의 방향성이 떠오른다:

• Agentic Wallet, CDP Facilitator와 Bazaar를 결합해 지갑, 결제, 컴플라이언스 및 디스커버리를 하나의 스택으로 제공하는 CDP(@CoinbaseDev)의 통합 전략
• 서비스 탐색, API key pooling, 응답 정규화와 과금을 하나의 계정, 잔액, 청구서로 통합하고 credits·x402·MPP를 함께 지원함으로써, 여러 공급자와 결제수단을 관리하는 복잡성을 중앙 게이트웨이 내부로 옮긴 Orthogonal(@orthogonal_sh)의 통합 전략.

물론 두 전략이 곧 지급 보증이나 손실 부담을 의미하는 것은 아니다. 다만 분산된 지갑, 검증, 과금과 디스커버리를 하나의 운영 주체 아래 모은다는 점에서 중앙화된 책임 계층으로 발전할 기반을 보여준다.

필자는 중앙화된 책임 계층이 확산되면 결제 구조 또한 일부 변형될 수 있다고 생각한다. 예로 들어, verify → business logic → settle이 아닌 verify → settle → business logic으로 진행하는 구조를 생각해 볼 수 있다.

기존 순서가 정산이 되돌릴 수 없다는 전제 위에서 컨슈머를 보호하기 위한 것이었다면, 사업자가 환불과 분쟁 처리를 책임지는 순간 그 전제 자체가 사라진다. 정산을 먼저 확정해 머천트가 떠안던 미수 위험을 없애고, 실행이 실패하면 사업자가 컨슈머에게 되돌려주는 것이다. 대신 사업자는 최종 정산 전까지 유동성과 정산 의무를 부담하며, 그만큼 자본과 책임 체계가 중요해진다.

이는 현재 x402의 건별 정산 흐름을 그대로 따르는 모델은 아니다. x402는 결제 조건과 승인 정보를 전달하는 개방형 인터페이스로 남고, 실제 자금 이동은 사업자가 집계한 뒤 온체인에서 최종 정산하는 방향으로 변형되는 것이다. 개별 결제 기록은 사업자의 내부 원장에, 집계된 최종 정산 결과는 블록체인에 남는다. 내부 원장은 되돌릴 수 있으므로 앞서 지적한 비가역성 문제가 완화되고, 사업자는 카드의 issuer처럼 환불과 분쟁 처리를 수행할 수 있다. 그러면 누군가는 이렇게 반문할 수도 있다.

결국 블록체인을 공유 결제 DB로 사용하는 것 아닌가?

그렇다.

더 정확히는 개별 결제를 처리하는 데이터베이스가 아니라, 사업자 간 최종 잔액을 기록하는 공유 정산 원장이다. 적어도 이 시장에서는 그 역할만 안정적으로 수행해도 충분하다. 그 위에서 낮은 정산 비용과 프로그래머블 머니의 이점을 활용할 수 있기 때문이다.