PayChain 0 to 1 (1) — 빨라진 결제, 남겨진 정산

지난 10년간 블록체인 업계는 결제의 문제들을 하나씩 지워왔다. 블록 생성은 초 단위로 빨라졌고, 수수료는 무시해도 되는 수준까지 내려왔으며, 스테이블코인은 자산 가격 변동에 따른 부담을 크게 낮췄다. 오늘 어떤 기업이 해외 파트너에게 스테이블코인으로 대금을 보낸다면 그 돈은 몇 초 안에 도착하고, 기존 지급망보다 낮은 비용으로 처리할 수 있다. 돈을 보내는 일은 이제 정말로 쉬워졌다.

그런데 이렇게 쉬워진 결제를 실제 사업에 도입하는 과정은 여전히 단순하지 않다. 제도가 정비되는 중이기도 하지만, 규제와 별개로 남는 운영 문제가 있다. 돈을 보내는 일은 쉬워졌어도 그 결과를 정산하고 증빙하는 일은 기업이 별도로 해결해야 한다.

이 글은 페이프로토콜이 구축 중인 온체인 금융 인프라, PayChain을 설명하는 첫 번째 글이다. 블록체인 결제가 10년간 풀지 못한 “정산 문제”로 시작한다.

결제와 정산 사이의 간극

한 플랫폼에서 사용자가 스테이블코인으로 상품을 결제하고, 플랫폼이 수수료를 제외한 대금을 해외 판매자에게 정산하는 장면을 따라가 보자. 트랜잭션은 몇 초 만에 컨펌되고, 익스플로러에는 Success가 찍힌다. 블록체인의 관점에서 이 거래는 완결됐다. 자산이 이동했고, 기록이 남았고, 해당 네트워크에서 확정된 거래로 기록된다.

그러나 재무팀의 업무는 이 지점에서 시작된다. 사용자 결제는 어떤 주문과 연결되는가. 판매자 정산액과 플랫폼 수수료는 어떻게 계산되는가. 부분 환불이나 분쟁이 발생하면 원거래와 어떻게 연결할 것인가. 회계 시스템에는 어떤 계정으로 반영하고, 6개월 뒤 감사에는 무엇을 제출할 것인가.

익스플로러는 이 질문들 중 어느 것에도 답하지 못한다. 트랜잭션 해시는 자산 이동의 결과를 보여줄 뿐, 그 이동이 어떤 금융 행위였는지 설명해주지 않는다. 블록체인은 자산 이동의 결과를 기록하지만, 그 움직임의 의미는 기록하지 않는다.

결제는 블록체인이 처리했지만, 정산은 여전히 기업이 별도의 시스템과 운영 절차로 해결해야 하는 것이다.

블록체인에는 없는 것

이 차이를 이해하려면 결제와 정산이 어떻게 다른지부터 봐야 한다. 이미 수십 년간 다듬어진 카드 결제의 절차를 따라가 보면 그 차이가 분명하게 드러난다.

편의점에서 카드를 긁는 순간, 사용자에게 결제는 1초짜리 사건이다. 그러나 그 1초에 일어난 일은 승인(Authorization)뿐이다. 발급사가 이용 가능 한도를 확인하고 거래를 승인했을 뿐, 돈은 아직 어디로도 움직이지 않았다. 실제 절차는 여기서 시작된다. 가맹점이 승인 건을 확정해 배치로 묶어 보내면(Capture), 카드 네트워크를 통해 발급사와 매입사 사이에서 거래 내역과 수수료가 맞춰지고(Clearing), 그다음에야 기관 사이에 자금이 오간다(Settlement). 가맹점 계좌에 실제로 돈이 들어오는 지급(Funding)은 또 그 이후다. 업계에서 통상 T+1, T+2라고 부르는 며칠의 시차가 여기서 발생한다.

여기서 중요한 것은 이 단어들이 서로 다른 단계를 가리킨다는 점이다. 승인은 돈의 이동이 아니고, 정산은 가맹점 입금과 같은 말이 아니다. 그 사이에 부분 취소나 환불이 끼어들 수 있고, 고객이 이의를 제기하면 분쟁 처리 절차가 붙으며, 정기적으로 서로의 장부를 맞추는 대사 작업이 이어진다.

즉 하나의 결제는 성공 또는 실패라는 두 가지 상태로 끝나지 않는다. 승인됐지만 확정 전인 상태, 배치에 묶였지만 자금 이동 전인 상태, 부분 환불이 걸린 상태, 분쟁 중인 상태를 거치며 최종 확정을 향해 이동한다. 결제는 사용자에게 보이는 한 순간의 이벤트지만, 정산은 그 뒤에서 여러 날에 걸쳐 진행된다.

기존 금융 시스템이 이 시차를 감당할 수 있는 이유는 각 단계마다 누가 무엇을 책임지고 어떤 기록을 남기는지가 규칙으로 정해져 있기 때문이다. 거래가 지금 어느 단계에 있는지, 누가 그 상태를 바꿀 수 있는지, 문제가 생기면 어느 지점으로 돌아가야 하는지를 시스템이 설명할 수 있다.

블록체인에서 일반적인 토큰 전송에는 이런 상거래 상태 모델이 기본으로 포함되어 있지 않다. 그런데 이것은 블록체인이 무언가를 빠뜨렸기 때문이 아니다. 애초에 다른 문제를 풀도록 설계됐기 때문이다.

블록체인의 송금은 개인 간 자산 이동에 최적화되어 있다. 지갑에서 지갑으로 자산이 옮겨가고, 트랜잭션이 확정되는 순간 자금 이동도 함께 끝난다. 승인과 자금 이동이 분리되어 있지 않으니 그 사이를 관리할 단계도 필요 없고, 거래 당사자가 둘뿐이니 수수료를 나누거나 정산 주기를 맞출 일도 없다. 중개자 없이 최종성을 확보하는 것, 그것이 블록체인이 처음부터 풀려던 문제였고 그 문제는 훌륭하게 해결됐다.

문제는 이 구조를 결제 서비스에 가져올 때 생긴다. 사업의 결제는 개인 간 송금과 다르다. 구매자와 판매자 사이에 플랫폼과 정산 대행사가 끼고, 한 번의 거래가 여러 참여자에게 나뉘어 배분되며, 환불과 분쟁이 발생하고, 회계 기준에 맞춰 장부에 반영되어야 한다. P2P 송금에서는 필요 없던 것들이 결제 서비스에서는 전부 필요해진다.

그래서 온체인 결제를 도입한 기업들은 결국 이 역할을 스스로 떠안게 된다. 트랜잭션을 인덱싱해 내부 주문과 연결하고, 수수료 배분을 계산하고, 환불을 원거래와 짝지어 기록하고, 감사에 대비해 증빙을 따로 보관한다. 블록체인이 남긴 것은 자산이 이동했다는 사실이고, 그 이동이 어떤 거래의 어느 단계였는지를 설명하는 일은 각 기업의 몫으로 남는다. 결제는 해결됐지만, 정산은 아직이다.

결제 인프라는 정산 체계에서 만들어진다

정산 체계의 필요성은 기존 결제 산업이 이미 보여주고 있다. 오늘날 결제 인프라라고 불리는 회사들은 예외 없이 이를 제품으로 만들면서 자리를 잡았다.

비자가 공개한 2025 회계연도 실적을 보면 연간 결제 규모는 약 14조 달러, 처리된 거래는 약 2,580억 건에 이른다. 이 규모가 가능한 이유는 카드를 긁는 기술이 뛰어나서가 아니다. 발급사와 매입사, 가맹점과 소비자가 서로 정해진 규칙하에 거래할 수 있도록 네트워크를 구축했기 때문이다. 언제 정산하고, 분쟁은 어떻게 처리하며, 손실은 누가 부담하는지가 규칙으로 정리되어 있으니 참여자들은 상대를 따지지 않고 거래에 참여할 수 있다. 카드 네트워크의 핵심은 결제 수단 자체가 아니라 네트워크 규칙에 있었다.

스트라이프는 같은 일을 개발자를 위해 했다. 스트라이프가 공개한 연례 서한에 따르면 2025년 처리한 결제 규모는 1조 9,000억 달러로 전 세계 GDP의 약 1.6%에 해당한다. 스트라이프의 제품 구성을 보면 결제 그 자체보다 그 이후를 다루는 것이 더 많다. 플랫폼이 여러 판매자에게 대금을 나눠 보내는 기능, 구독과 인보이스 처리, 세금 계산, 회계 기준에 맞춘 매출 인식 리포트까지 결제 이후에 벌어지는 업무들이 하나씩 제품이 되어 있다. 개발자가 스트라이프를 선택하는 이유는 결제창을 붙이기 쉬워서도 있지만, 결제 이후에 따라오는 필수 업무들을 제품으로 제공하기 때문이다.

두 회사가 다루는 방식은 다르지만 결론은 같다. 결제 사업이 인프라가 되는 지점은 자금을 보내는 순간보다, 그 이후의 단계들을 구축하기 시작할 때다.

온체인 자산 전송만으로는 이 역할까지 제공되지 않는다. 자산을 옮기는 레일은 이미 충분히 좋아졌지만, 그 위에서 벌어지는 정산과 증빙은 여전히 각 기업이 알아서 해결해야 할 문제로 남아 있다. 크립토 결제가 실험을 넘어 실제 사업의 결제 수단이 되려면, 카드 산업이 수십 년에 걸쳐 만들어온 그 역할을 온체인에서 맡아줄 체계가 필요하다.

PayChain이 정산에서 시작하는 이유

그동안 블록체인의 발전은 다른 축에서 이뤄져 왔다. TPS도 수수료도 파이널리티도 자산을 얼마나 잘 옮기는가에 대한 지표였고, 정산은 그 축 위에 없었다. 그래서 초당 수만 건을 처리하는 체인 위에서도 환불은 원거래와 연결되지 않은 별개의 전송일 뿐이고, 수수료 배분과 부분 정산은 각 기업의 백엔드에서 계산되며, 감사에 제출할 증빙은 어딘가의 데이터베이스에서 만들어진다. 속도는 결제의 지표이지 정산의 지표가 아니다.

기업이 블록체인 결제를 도입할 때 정산 체계를 처음부터 직접 만들지 않아도 되게 하는 것이 PayChain의 설계 목적이다.

PayChain은 결제가 실행되는 순간부터 정산이 확정되는 순간까지, 모든 상태 변화를 검증 가능한 기록으로 남기는 온체인 금융 인프라다. 블록체인에서 발생한 실행 이벤트를 Receipt와 검증 기록으로 구성하고, 기업의 기존 정산·회계 시스템과 연결할 수 있는 기반을 제공한다.

특히 이미 결제 사업을 하고 있는 곳에는 연결 방식이 중요하다. PG를 예로 들면, 이들에게는 이미 오랫동안 운영해온 정산 시스템이 있다. 여기에 블록체인 결제를 새로 얹는다는 것은 지갑 관리부터 거래 추적, 정산 데이터 생성까지 익숙하지 않은 영역을 통째로 떠안는 일이 된다. PayChain은 이 부분을 대신 처리하고, 그 결과를 각 사가 쓰던 정산·회계 시스템에서 그대로 활용할 수 있는 형태로 내보낸다. 기존 정산 체계를 바꾸는 것이 아니라, 블록체인 결제라는 새로운 수단을 그 체계에 붙일 수 있게 만드는 일이다.

PayChain은 갑자기 등장한 프로젝트가 아니다. 페이프로토콜의 출발점은 결제였다. 하이퍼레저 기반 결제망 위에서 수년간 실제 결제 서비스를 운영하며, 결제 인프라에 요구되는 안정성과 규제 대응, 그리고 결제 이후의 운영이 얼마나 복잡한지를 현장에서 확인해왔다. 결제 사업자가 무엇을 필요로 하는지를 사업자의 자리에서 겪어봤다는 것이 PayChain의 출발점이다.

구조의 중심에는 Receipt가 있다. PayChain의 Settlement OS로 접수되는 결제와 정산 이벤트는 Receipt 단위로 기록되고, 승인부터 최종 확정까지의 모든 상태 변화가 이 전표를 따라 남는다. 이때 온체인에 기록되는 것은 검증에 필요한 증거뿐이다. 상세한 거래 내역은 권한을 가진 참여자만 접근할 수 있다. 블록체인의 검증 가능성과 금융이 요구하는 프라이버시를 동시에 다루는 것, 이것이 PayChain 설계의 첫 번째 원칙이다.