PG사는 잊어라, 스테이블코인 결제 시스템 아키텍처 비교 분석

여는 글

하나은행-두나무, 토스-빗썸 제휴 뉴스를 보며 동료 개발자와 이런 대화를 나눈 적이 있다. “결국 스테이블코인 결제도 그냥 수단 하나 늘어나는 거 아냐? 카카오페이 붙이듯이.”

비즈니스적으로는 그럴지 몰라도, 엔지니어링 관점에서는 완전히 다른 이야기다. 단순한 API 연동이 아니라 금융의 ‘청산 및 결제(Clearing & Settlement)’ 프로세스가 코드 레벨에서 통합되는 거대한 패러다임의 변화이기 때문이다.

기존 레거시 PG 시스템과 원화 스테이블코인 결제가 기술적으로 어떻게 다른지 아키텍처 관점에서 비교해 보았다.

기존 카드 결제의 흐름은 의외로 길다.

사용자 → 가맹점 → PG → VAN → 카드사 → (매입/정산) → 가맹점 입금(정산주기에 맞춰)

우리가 payment.request()를 호출해서 success를 받아도, 그건 “승인”일 뿐 실제 돈이 들어온 게 아니다. 정산은 D+2, 길게는 D+7일까지 걸린다. 반면 스테이블코인은 구조가 단순하다.

사용자 지갑 → (Smart Contract) → 가맹점 지갑

트랜잭션이 블록에 담기는 순간 결제와 정산이 동시에 끝난다. 이를 Atomic Settlement(원자적 결제)라고 부른다. ‘실시간 정산’이라는 서비스를 제공하는 곳이 많지만, 말이 ‘실시간 정산’이지 시스템 구조상 ‘즉시’ 꽂히는 것은 아니다.

기존 PG 연동은 HTTP 요청을 보내고 응답을 받으면 끝이다.

블록체인 결제는 “요청”과 “확인”이 분리되어야 한다. 트랜잭션을 전송(send)하는 것과 채굴되어 확정(mined)되는 것은 시차(Block Time)가 있기 때문이다.

사용자에게 “결제하려면 ETH를 충전하세요”라고 하는 순간 서비스는 망한다. 그래서 가스비 대납(Gas Relayer) 혹은 계정 추상화(Account Abstraction) 기술이 필수적일 것으로 예상된다.

최근 ERC-4337(Account Abstraction)이 도입되면서 Paymaster를 통해 이 과정이 더 표준화되고 있다. 개발자는 이제 Solidity 레벨의 가스 최적화까지 고민해야 할지도 모른다.

당분간은 Fiat(원화)와 Crypto가 공존할 수밖에 없다. 개발팀에게 닥칠 가장 큰 현실적인 문제는 대사(Reconciliation)다.

PG사는 엑셀 파일을 주지만 블록체인은 우리가 직접 인덱싱(Indexing)해야 한다. 데이터 정합성을 맞추는 난이도가 훨씬 높다.

솔직히 아직 원화 스테이블코인이 언제 나올지, 어떤 블록체인 위에서 돌아갈지도 모른다.

근데 방향성은 명확한 것 같다. 결제 인프라가 블록체인 쪽으로 움직이고 있고, 은행들이 직접 뛰어들고 있다.

PG 연동만 해봤던 나 같은 개발자 입장에서는 새로운 기술 스택을 배워야 한다는 부담이 있다. Web3, 스마트 컨트랙트, 이벤트 리스닝… 익숙하지 않은 것들이다.

근데 반대로 생각하면 기회이기도 하다. 이쪽을 미리 공부해둔 사람이 많지 않을 테니까.

요즘 테스트넷에서 이것저것 실험해보고 있는데, 생각보다 재밌다. 트랜잭션 보내고 블록 익스플로러에서 확인하는 게 뭔가 새롭다.

스테이블코인 결제가 기존 PG를 완전히 대체할지는 모르겠다. 당분간은 공존할 것 같다.

근데 확실한 건, 결제 시스템 개발자로서 블록체인 기반 결제를 모르면 점점 불리해질 거라는 점이다.

원화 스테이블코인이 실제로 나오면, “이거 연동해주세요”라는 요청이 올 거다. 그때 “아 그거 해본 적 없는데요”라고 하는 것보다는, 적어도 개념은 알고 있는 게 낫지 않을까.