블록체인 추상화: Web3의 다음 승부처

Key Takeaways

• 지갑과 인증, 계정과 거래, 체인 추상화는 블록체인을 이용하기 위해 사용자가 직접 처리하던 절차를 줄였다. 은행과 Web2 플랫폼은 이를 기존 계정과 서비스에 연결해, 고객에게 익숙한 이용 흐름 안에서 디지털 자산 기능을 제공할 수 있게 되었다.
• 추상화로 화면에서 사라진 복잡성은 플랫폼과 인프라 사업자의 운영 책임으로 옮겨간다. 계정 복구와 거래 승인, 수수료 부담, 정산 상태를 관리하는 체계는 블록체인 기능을 일상적인 서비스로 제공하기 위한 도입 조건이다.
• 램프는 지갑과 지급 기능을 기존 재무 업무에 통합했고, 텔레그램의 톤 월렛은 체인 추상화로 외부 자산 유입을 단순화했으며, 네이버페이는 지갑과 인증 추상화를 바탕으로 자산 보유를 커뮤니티 참여 자격에 연결했다. 추상화의 가치는 기존 플랫폼의 업무와 이용 흐름 안에서 구체화되고 있다.
• 기존 플랫폼의 고객 기반에 지갑과 결제 인프라를 연결하는 방식은 Web2와 Web3의 결합을 앞당기고 있다. 앞으로는 해외 대금 지급과 창작자 정산, 제휴 서비스에서 활용하는 티켓과 멤버십, 권한과 예산을 정해 위임하는 자동 구매 등으로 실사용이 확장될 수 있다.
• 본 글에서는 프리비(Privy), ERC-4337, 어크로스(Across), 서클(Circle) CCTP를 중심으로 추상화가 사용자 경험의 마찰을 해소하는 원리를 살펴본다. 이어 램프와 텔레그램, 네이버페이의 도입 사례를 분석하고, 이러한 지갑 구조가 Web2 서비스와 결합할 때 기대할 수 있는 가능성을 짚어본다.

EastPoint:Seoul은 기관 리더, 규제 당국, 그리고 Web3 개척자들을 한자리에 모아 한국 디지털 자산과 AI 경제의 미래를 설계하는 최초의 프라이빗 컨퍼런스다.

아무리 독보적인 기술을 보유하더라도 사용자 경험(UX)을 간과한 프로덕트는 진가를 입증하지 못한 채 시장에서 외면받는다. 기술의 완성도는 성능 수치가 아니라 사용자가 그 가치를 얼마나 직관적으로 체감하는가에 달려 있다.

디지털 플랫폼의 블록체인 도입도 마찬가지다. 냉정하게 보면 사용자가 가장 먼저 체감하는 것은 합의 알고리즘 같은 기술적 해자가 아니라, 디지털 자산을 구매하고 온/오프램프를 거치고 교환하며 경제 활동을 이어가는 전체 흐름이 얼마나 매끄럽게 연결되는가다.

불과 몇 년 전까지만 하더라도 이 관점에서 블록체인 서비스는 다소 아쉬웠다. 당시 디앱(dApp)을 이용하려면 지갑 앱이나 브라우저 익스텐션을 설치하고 복구 구문부터 백업해야 했다. 들어가서도 거래마다 네이티브 가스 토큰을 준비하고 서명 과정을 반복해야 했으며, 자산이 다른 체인에 있으면 브리지 선택과 각 체인의 가스, 네트워크 전환까지 경로 전체를 직접 알아보고 처리해야 했고, 실패하면 복구도 사용자의 몫이었다.

이러한 이유로 수억 명의 고객을 보유한 은행과 Web2 플랫폼 입장에서 블록체인을 자사 서비스 위에 그대로 얹을 수는 없었고, 결국 블록체인은 오랫동안 기술 검토의 대상이었을지언정 실제 도입의 선택지로 자리 잡기는 어려웠다.

하지만 (1) 지갑과 인증 추상화, (2) 계정과 거래 추상화, 그리고 (3) 체인 추상화를 통해 현재는 이러한 불편함이 상당 부분 해소되었다. 소셜 로그인만으로 지갑이 생성되고, 가스 스폰서십으로 가스 토큰을 따로 준비할 필요가 없어지고, 일괄 처리로 여러 호출이 한 번에 실행되며, 체인을 고르는 대신 원하는 결과에 서명하면 솔버와 릴레이어가 경로를 구성한다.

이러한 변화는 은행과 플랫폼이 블록체인 기능을 기존 서비스에 연결할 수 있는 가능성을 넓혔다. 이를 통해 고객은 익숙한 계정으로 로그인하고 같은 화면에서 결제하되, 그 뒤에서는 지갑과 거래 실행 인프라가 자산의 보관과 이동을 처리할 수 있게 되었다. 본 글에서는 세 가지 추상화의 작동 원리와 실제 도입 사례를 살펴보고, 이를 바탕으로 Web2와 Web3의 결합이 어떤 서비스로 확장될 수 있을지 논의해보고자 한다.

1. 지갑과 인증 추상화: 프리비는 지갑 생성을 로그인 뒤로 옮겼다

초기 디앱은 사용자가 메타마스크(MetaMask) 같은 외부 지갑을 이미 보유하고 있다는 전제로 구축되었다. 지갑이 없으면 브라우저 확장 프로그램이나 모바일 앱부터 설치하고, 새 키를 만든 뒤 복구 구문을 따로 보관해야 했다. 그다음 사이트에 지갑을 연결하고 로그인 서명까지 마쳐야 비로소 제품을 볼 수 있었다.

이처럼 사용자는 신원 증명과 키 보관, 거래 서명을 앱과 외부 지갑 사이를 오가며 해결해야 했다. 서비스를 써보기도 전에 키 관리 책임부터 떠안고, 가치를 체감하기도 전에 블록체인 인프라의 작동 방식부터 학습해야 하는 구조였으며, Web3를 처음 접하는 사람에게는 명백한 진입 장벽으로 작용했다.

Source: Privy

프리비(Privy)는 이러한 진입 장벽을 정면으로 겨냥한 프로덕트다. 2023년 2월 내장 지갑(Embedded Wallet)을 선보인 데 이어, 2024년 2월 플랫폼을 정식 공개했다. 출시 당시 "지갑 보유 여부와 상관없이 모든 사용자를 Web3로 온보딩하는 가장 쉬운 방법"이라고 밝힐 만큼 온보딩 문턱을 낮춘 솔루션이다.

작동 방식의 핵심은 이메일 OTP, 소셜 로그인, 패스키, 외부 지갑 등을 활용한 간편 인증에 있다. 프리비는 여러 로그인 방식을 하나의 사용자 객체로 묶고, 여기에 다양한 체인의 지갑을 연동한다. 특히 로그인 정보와 개인키를 엄격히 분리하여 관리한다. 신원 확인 후 발급된 앱별 접근 토큰과 시한성 권한 키가 지갑 작업을 승인하도록 설계하여, 각 요소의 역할과 수명을 분리하고 보안성을 높였다.

실제 온보딩에서 이 구조는 설정 하나로 구현된다. 앱이 createOnLogin 옵션을 켜두면 프리비 로그인 모달을 통과한 사용자 가운데 지갑이 없는 사람에게 지갑이 자동으로 만들어지므로, 사용자는 확장 프로그램 설치나 복구 구문 백업 없이 로그인과 동시에 지갑을 갖게 된다. 결과적으로 사용자에게 보이는 것은 익숙한 로그인 한 번이 전부이고, 지갑 생성과 키 관리는 화면 뒤로 사라진다. 그렇다면 화면 뒤로 사라진 사용자의 개인키는 실제로 어디서 만들어지고 어떻게 보관될까? 프리비의 답은 신뢰 실행 환경(TEE)이다.

프리비는 TEE와 온디바이스 방식을 모두 지원하지만, 이 장에서는 신뢰 실행 환경을 활성화한 구성을 기준으로 보겠다. 먼저 개인키는 외부 접근과 네트워크가 차단된 AWS Nitro Enclave 내부에서 생성된다. 프리비는 생성된 키를 통째로 보관하지 않고 샤미르 비밀 공유(Shamir's Secret Sharing) 알고리즘을 통해 두 조각으로 분할한다.

샤미르 비밀 공유는 비밀 값을 여러 조각으로 나눠 정해진 개수 이상이 모여야만 원본을 복원할 수 있고, 그 미만의 조각으로는 원본에 대한 어떤 정보도 얻을 수 없게 만드는 암호학적 분할 기법이다.

두 조각의 역할은 서로 다르다. 인클레이브 조각(Enclave Share)은 TEE 안에서만 열리도록 잠기고, 인증 조각(Auth Share)은 유효한 로그인 요청이 있을 때만 서명 경로에 투입된다. 2-of-2 구조이므로 어느 한쪽만으로는 개인키를 복원할 수 없다.

서명이 필요할 때는 두 조각이 격리된 메모리에서 일시적으로 결합된다. 거래 요청이 입력되면 프리비 API가 인증 정보를 확인한 뒤, 암호화된 인증 조각과 요청을 TEE로 전달한다. TEE는 권한 서명과 관련 정책을 검증한 후 두 조각을 결합해 서명하고 키를 즉시 파기한다. 네트워크와 격리된 TEE는 서명 값만 반환하며, 실제 거래 전파는 호출자나 API가 담당한다. 결국 이 서명 경로에서는 개인키가 TEE 내부에 일시적으로 복원되고, 사용 후 즉시 폐기된다.

물론 이 구조가 곧 완벽한 자기수탁(Self-custody)을 뜻하지는 않으며, 지갑의 실질적 통제권은 키 분할 방식이 아니라 소유자, 추가 서명자, 정족수 설정이 결정한다. 클라이언트 SDK 기반 소비자 지갑에서는 사용자가 기본 소유자이며 키를 내보낼 수 있지만, 서비스 권한 키를 소유자로 지정하면 서비스 통제형 지갑이 된다. 또한 이메일이나 소셜 계정이 지갑의 입구이므로 로그인 수단이 탈취되면 지갑도 노출될 수 있어, 고액 자산을 다루는 앱에는 패스키나 MFA 도입이 권장된다.

그럼에도 사용자 경험 관점에서 얻는 이득은 분명하다. 기기를 바꿔도 로그인만 하면 같은 지갑에 접근할 수 있고, 지갑의 존재를 의식하지 않은 채 일반 Web2 앱과 같은 흐름으로 서비스를 이용하게 된다. 수분씩 걸리며 사용자의 이탈을 유발하던 온보딩 과정이 사실상 로그인 한 번으로 압축되는 것이다.

하이퍼리퀴드(Hyperliquid)와 포모(Fomo)를 비롯한 수많은 디앱이 프리비의 내장 지갑으로 사용자 온보딩을 처리하고 있다. 프리비는 2025년 6월 기준 7,500만 개 이상의 계정을 확보하며 가파르게 성장했고, 이듬달인 7월 글로벌 결제 거물 스트라이프(Stripe)에 인수되었다. 현재도 다양한 Web3 프로덕트에서 주요 온보딩 솔루션으로 활발히 도입되는 추세다.

2. 계정과 거래 추상화: 사용자가 구성하던 거래를 실행 정책으로 바꾼다

이제 거래로 넘어가 보자. 앱에서 USDC를 이더리움(ETH)으로 스왑하는 과정을 생각해보자. 기존의 외부 소유 계정(EOA) 방식에서는 토큰 사용 승인이 없거나 부족하면 두 번의 트랜잭션이 필요했다. 먼저 교환 컨트랙트가 내 USDC를 사용할 수 있도록 허락하는 승인(approve) 거래에 서명하고, 이 거래가 블록에 기록될 때까지 기다린 뒤 실제 교환(swap) 거래에 다시 서명해야 했다. 팝업창은 두 번 떴고, 가스비로 쓸 이더리움도 지갑에 미리 준비해 두어야 했다.

중간에 흐름이 끊기면 문제는 더 커진다. 예를 들어 승인은 완료됐는데 스왑이 실패하면, 자산 교환은 이뤄지지 않은 채 교환 컨트랙트가 승인된 한도 내에서 내 USDC를 움직일 수 있는 권한만 남는다. 거래가 잦은 앱에서 매번 필요한 만큼만 승인한다면 이 과정을 반복해야 하니, 사용자는 하려던 행동보다 이 절차 자체에 스트레스를 받게 된다.

ERC-4337 계정 추상화(Account Abstraction)는 이 문제를 사용자가 트랜잭션을 직접 전송하는 대신 주문서를 작성하는 방식으로 해결한다. 기존에는 사용자가 거래를 한 건씩 직접 만들어 서명하고 순서까지 챙겨 보내야 했다면, 이제는 원하는 실행 내용을 주문서에 적어 제출하기만 하면 나머지는 실행 인프라가 알아서 처리한다.

조금 더 들여다보면 사용자의 행동은 발신자, 실행 내용, 수수료 조건, 서명이 담긴 사용자 작업(UserOperation)이라는 주문서가 되는데, 가장 큰 변화는 일괄 실행을 지원하는 스마트 계정에서 승인과 교환을 한 장의 주문서에 묶어 처리할 수 있게 된 점이다. 이 주문서를 처리하는 배달 체계도 역할이 철저히 나뉘어 있다:

• 번들러(Bundler): 여러 주문서를 시뮬레이션해 검증을 통과하지 못한 요청을 거른 뒤 묶어서 제출하는 수거 기사
• 진입점(EntryPoint): 모든 주문서가 거쳐 가는 온체인 검문소
• 스마트 계정(Smart Account): 서명 인정 조건을 코드로 자유롭게 지정할 수 있는 계정
• 페이마스터(Paymaster): 수수료를 대신 내주는 선택적 대납자

이더리움의 근본적인 합의 규칙은 그대로 둔 채 그 위에 효율적인 실행 인프라를 얹은 것이 핵심이다. 이 구조 위에서 사용자가 승인하면 앱이 주문서를 만들고, 번들러가 이를 묶어 검문소에 제출하며, 검문소는 스마트 계정을 통해 서명을 검증하고 수수료 지불 가능 여부를 확인한다. 페이마스터를 쓰는 경우에는 그 정책도 확인한 뒤 스마트 계정을 호출해 승인과 교환을 일괄 실행시킨다. 결국 사용자는 클릭 한 번으로 한층 개선된 경험을 얻지만, 그 이면에서는 아래 세 가지 핵심 기능이 이를 뒷받침한다:

먼저 수수료(가스비) 추상화다. 페이마스터가 도입되면 앱이 수수료를 전액 대납하거나, 사용자 대신 이더리움을 내고 사용자의 USDC로 사후 정산받을 수 있다. 예를 들어 사용자가 플랫폼에서 100 USDC를 결제해야 하는 상황을 가정해보자. 원래 이더리움 네트워크라면 가스비로 쓸 소량의 이더리움을 따로 갖고 있어야 하지만, 수수료 추상화가 적용되면 플랫폼이 이더리움으로 가스비를 먼저 낸 뒤 사용자에게서 USDC로 돌려받거나, 아예 플랫폼이 비용을 대납할 수도 있다.

다음은 트랜잭션 일괄 처리(Batching)로, EIP-5792 표준은 앱이 승인과 교환 등 여러 호출을 지갑에 한 번에 보낼 수 있게 해준다. 원자적(Atomic) 실행을 지원하는 지갑에 해당 방식으로 실행하도록 요청하면, 여러 호출 중 하나라도 실패할 때 전체가 취소된다. 승인 권한만 남는 어중간한 상태가 구조적으로 차단되며, 사용자는 팝업 두 개 대신 한 번의 확인으로 처리할 수 있다.

마지막은 세션키(Session Key)를 통한 제한적 권한 위임으로, 세션키는 한도를 정해 발급하는 체크카드에 가깝다. 사용자가 "이 컨트랙트에서, 특정 기능만, 이달 말까지 USDC 100개 한도 내에서 허용"하는 식으로 한 번 승인하면, 이후에는 팝업 없이 게임 클라이언트나 자동화 에이전트가 알아서 트랜잭션을 보낸다. 한도를 통제하는 것은 앱의 양심이 아니라 계정의 검증 코드이므로, 조건을 벗어난 요청은 스마트 컨트랙트 단에서 자동 거부된다. 지갑에 실행 권한을 요청하는 표준인 ERC-7715는 아직 초안 단계이지만, 에이전틱 커머스(Agentic Commerce)처럼 자동화된 실행이 필수인 다른 생태계에서 먼저 주목받고 있는 체계이기도 하다.

물론 이러한 편의성에는 비용과 책임이 따른다. 대납 수수료는 앱이나 제3자의 예산에서 지출되며, 페이마스터는 정책에 따라 요청을 거절할 수 있다. 또한 세션키의 범위를 지나치게 넓게 잡거나 탈취당할 경우 설정된 한도만큼의 자산 리스크가 발생한다. 결과적으로 사용자가 편의성을 얻는 대신 플랫폼은 대납 예산 관리, 허용 범위 통제, 세션 철회, 계정 코드 업그레이드 권한 등 막중한 운영 책임을 안게 된다.

그럼에도 사용자 경험은 혁신적으로 달라진다. 가스비 준비, 연속 승인, 반복 서명이 사라지면서 복잡한 블록체인 거래가 일반 Web2 앱의 단순한 결제 버튼처럼 변한다. 다만, 스마트 계정이 단일 체인 내의 실행을 아무리 매끄럽게 만든다 해도, 자산이 다른 체인에 흩어져 있다면 이를 목적지로 알아서 옮겨주지는 못한다. 이 마지막 퍼즐을 맞추기 위해 등장한 개념이 바로 '체인 추상화(Chain Abstraction)'다.

3. 체인 추상화: 네트워크 선택을 솔버와 정산 계층으로 넘긴다

체인 추상화는 블록체인 UX 혁신의 마지막 관문인 '체인 간 장벽'을 넘어서는 기술이다.

앱은 베이스(Base)에 있는데 내 USDC가 아비트럼(Arbitrum)에 있는 상황을 떠올려보자. 과거에는 이 상황 자체가 사용자에게 거대한 숙제였다. 어느 체인에 자산이 있는지 확인하고, 해당 체인의 가스비를 준비하고, 브리지 컨트랙트에 토큰 사용을 승인한 뒤, 전송이 완료될 때까지 기다렸다가 네트워크를 바꾸고 목적지에서 쓸 가스비까지 따로 마련해야 비로소 베이스에서 자산을 사용할 준비가 끝났다. 네트워크가 다르다는 이유만으로, 단 한 번의 토큰 교환에도 사용자는 브리지 선택과 이중 가스비, 거듭된 서명, 실패 리스크까지 감당해야 했던 것이다.

체인 추상화는 이 복잡한 실행 과정을 없애는 것이 아니라, 경로를 조립하는 주체를 '사용자'에서 '실행 계층'으로 넘기는 방식이다. 먼저 사용자는 일일이 이동 경로를 지정하는 대신 받을 자산, 최대 지불 금액, 최소 수령 금액, 수취 주소, 만료 시점과 같은 결과 조건에 서명한다. 이 주문(Intent)을 수신한 솔버(Solver)나 릴레이어(Relayer)는 자기 자본으로 목적지 체인에서 결과를 먼저 만들어주고, 목적지 지급이 확인된 이후에야 원금과 수수료를 정산받는다.

ERC-4337이 계정 추상화의 공통 규격으로 자리 잡았듯, 유니스왑 랩스(Uniswap Labs)와 어크로스(Across)가 제안한 ERC-7683 역시 크로스체인 의도(Intent)의 형식을 표준화하려는 시도다.

이 의도 기반 모델의 대표적인 구현체가 어크로스(Across)로, 사용자가 원본 체인의 금고(SpokePool)에 자산을 맡기면, 릴레이어가 이를 감지해 목적지 체인에서 자기 자금으로 신속하게 자산을 지급한다. 사용자는 비교적 느린 레이어1/레이어2 공식 브리지의 전송 완료를 기다릴 필요 없이 수 분 만에 자산을 수령할 수 있다.

후속 정산은 백엔드에서 비동기로 이루어지며, 검증과 이의 제기 기간을 거쳐 릴레이어에게 상환되는 구조이므로 빠른 지급과 최종 정산이 분리된다. 만약 기한 내에 지급이 이뤄지지 않으면 자산은 정산 절차를 거쳐 지정된 환불 주소로 반환된다. 현재 유니스왑 인터페이스의 크로스체인 스왑 역시 어크로스 기반으로 작동한다.

스테이블코인에 한정하면 발행사가 직접 제공하는 공식 경로인 서클(Circle)의 CCTP(Cross-Chain Transfer Protocol)가 활용된다. 원본 체인에서 USDC를 소각(Burn)한 뒤 서클의 증명을 받아 목적지 체인에서 동일한 양을 새로 발행하는 구조다. 래핑된 토큰(wrapped token)이나 별도의 유동성 풀 없이 발행사가 직접 총량을 보증하므로 정합성이 중요한 은행이나 플랫폼의 기본 배관으로 적합하다. 물론 지원 자산과 체인에 한정되며 일반 전송은 출발 체인의 최종 확정을 기다려야 하지만, CCTP V2에서는 최종 확정 전에 서클의 증명을 받아 목적지에서 USDC를 발행하는 '빠른 전송(Fast Transfer)' 옵션을 추가해 대기 시간을 대폭 단축했다.

이러한 사용자 편의성의 증대 역시 리스크의 이동을 의미한다. 어크로스는 릴레이어의 유동성과 환불 대기 시간에, CCTP는 서클의 증명 인프라에 각각 의존한다. ERC-7683 역시 주문서의 언어를 통일할 뿐 공통 에스크로나 유동성 자체를 보장하지는 않는다. 따라서 복잡한 경로를 숨긴 플랫폼은 견적 만료, 목적지 지급 여부, 최종 정산, 환불 경로 추적이라는 운영 책임을 부담해야 한다.

4. 도입의 확산: 블록체인은 플랫폼의 기존 흐름 안으로 들어간다

앞선 세 가지 추상화 기술의 발전은 블록체인을 도입하려는 기업의 선택지를 크게 넓혔다. 이제 기업은 지갑 생성과 키 관리, 자산 변환 및 전송에 필요한 핵심 기능을 외부 인프라에서 조달해 기존 계정과 서비스에 손쉽게 연동할 수 있다. 그 결과, 고객에게 별도의 블록체인 서비스 이용을 요구하는 대신 기존 제품 안에 기능을 자연스럽게 탑재하여 사용자 경험(UX) 측면에서 탁월한 발전을 이뤄냈다.

따라서 도입 사례에서는 어떤 지갑을 채택했는지와 함께, 플랫폼이 무엇을 직접 만들고 무엇을 외부에 맡겼는지를 봐야 한다. 램프는 스트라이프의 인프라를 지급과 회계에 연결했고, 텔레그램 안의 지갑 서비스는 문페이를 통해 자금 유입 경로를 넓혔으며, 네이버페이는 매직의 지갑 기능을 티켓과 커뮤니티에 도입했다. 이 사례들은 기존 고객과 서비스를 유지하면서 그 안에서 자산을 이용하는 방식을 확장했다는 공통점이 있다.

4.1. 램프와 스트라이프: 스테이블코인을 지급 승인과 회계에 연결한다

기업 재무팀이 거래처 대금을 지급하는 상황을 생각해보자. 담당자는 청구 금액과 수취인을 확인하고, 내부 승인을 거쳐 지급한 뒤 그 결과를 장부에 반영해야 한다. 아무리 스테이블코인이 전송 시간을 줄이더라도 별도의 지갑을 관리하고 송금 내역을 다시 입력해야 한다면, 지급 업무 전체가 편해졌다고 보기는 어렵다. 스테이블코인 지급과 기존 장부 시스템의 연동이 필요한 이유다.

이를 해결하기 위해 법인 금융 플랫폼 램프(Ramp)는 2026년 7월 스트라이프와 함께 두 가지 기능을 공개했다. 하나는 외부 은행 계좌의 달러를 재원으로 거래처에 스테이블코인을 지급하는 청구서 결제 기능이고, 다른 하나는 기업이 스테이블코인을 보유하고 사용할 수 있는 계정이다. 기업은 스테이블코인을 미리 보유하지 않고도 지급 수단으로 활용하거나, 필요에 따라 잔액을 직접 보유하는 방식을 선택한다.

은행 계좌에서 지급하는 경로에서는 브릿지(Bridge)가 달러를 스테이블코인으로 변환해 수취인의 지갑으로 전달한다. 반면 스테이블코인 보유 계정에는 프리비의 기업용 지갑 인프라가 쓰이며, 램프는 법정화폐와 스테이블코인 잔액을 달러 기준으로 함께 보여준다. 자금이 보관되고 이동하는 방식은 달라도, 재무팀은 같은 화면에서 잔액과 지급 내역을 관리한다.

프리비는 램프 개발팀과 협력해 기업용 수탁 지갑, 솔라나 지원, 거래 승인 정책, 잔액&송금 API를 구축했다. 여기에 잔액 변동 알림(Webhook)과 대사(Reconciliation)용 메타데이터를 추가해, 자산 이동 결과를 기업 장부에 즉시 반영하고 검증할 수 있도록 했다.

이 분업 구조에서 램프는 고객 접점인 지급 화면과 승인 절차, 회계 연동 시스템을 담당하고, 프리비는 백엔드에서 지갑 및 권한 관리 기능을 제공한다. 램프가 각 블록체인의 지갑과 전송 기능을 직접 개발하는 대신, 외부 인프라의 처리 결과를 기존 재무 프로세스에 연동한 것이다.

램프의 2026년 7월 발표에 따르면, 1,000개 이상의 기업이 스테이블코인으로 대금을 지급하고 있으며 해당 스테이블코인 지급액의 70% 이상이 은행 영업시간 외에 이동했다. 스테이블코인은 재무팀에 별도의 지갑 관리 부담을 가중시키기보다, 기존 지급 업무의 시간적 제약을 해소하는 유용한 도구로 안착하고 있다. 즉, 램프는 지갑 추상화로 키 관리를 프리비에 맡기고, 브릿지의 자산 변환&전송 기능을 연결해 스테이블코인 지급을 기존 승인&회계 흐름에 통합했다.

정리하자면 램프는 지갑 추상화로 키 관리를 프리비에 맡기고, 브릿지의 자산 변환&전송 기능을 연결해 스테이블코인 지급을 기존 승인&회계 흐름에 통합했다.

4.2. 텔레그램과 문페이: 메신저 안의 지갑에 외부 자금 유입 경로를 붙인다

메신저 안에 Web3 지갑을 넣는 시도는 끊임없이 이어지고 있다. 카카오톡에 카카오페이를 연동한 사례에서도 볼 수 있듯이, 사용자가 많은 시간을 보내는 메신저 안에 지갑을 넣으면 이용을 크게 늘릴 수 있다. 하지만 지갑만 있고 법정화폐와 디지털 자산을 편하게 바꿔 입출금할 수 없다면 활용에는 한계가 있다.

예를 들어 사용자가 별도의 거래소에서 자산을 사고, 다른 체인의 토큰을 직접 스왑하여 가져와야 한다면 지갑 설치 절차만 줄었을 뿐 큰 의미는 없을 것이다. 이러한 이유로 일상적으로 사용하는 플랫폼에 자산 기능을 붙이려면 지갑의 입구뿐 아니라 자금이 들어오는 경로도 연결해야 한다.

텔레그램(Telegram) 안의 월렛 인 텔레그램(Wallet in Telegram)은 이 과제를 보여주는 사례다. 이 서비스는 운영사가 키를 관리하는 수탁형 지갑과 사용자가 자산을 직접 통제하는 자기수탁형 지갑을 구분해 제공한다.

이 지갑의 자금 유입 경로에는 문페이(MoonPay)의 인프라가 쓰였다. 문페이는 2025년 7월 톤 월렛에 카드와 애플페이, 구글페이 등을 통한 자산 구매와 지원되는 은행 카드로의 인출 기능을 제공한다고 발표했다. 지갑 서비스가 결제 수단별 입출금 경로를 모두 직접 구축하는 대신, 외부 온램프와 오프램프를 메신저 안의 이용 흐름에 연결했다.

2026년 2월에는 문페이 디포짓(MoonPay Deposits)을 도입해 다른 체인에 보유한 자산도 가져올 수 있도록 했다. 사용자가 입금할 토큰과 출발 네트워크를 선택하면 입금 주소가 생성되고, 외부 지갑이나 거래소에서 그 주소로 자산을 보내면 문페이가 입금을 감지해 교환과 체인 간 이동, 최종 자산 전달을 처리한다. 사용자는 스왑하려는 자산을 선택하고 전송하되, 중간 브리지를 고르고 교환 경로를 조립하는 일은 인프라가 담당한다.

텔레그램 내 개별 미니 앱과 지갑을 연결할 때는 톤 커넥트(TON Connect)를 활용한다. 미니 앱은 이 표준 규격으로 지갑 연결과 거래 승인을 요청하고, 사용자는 지갑 앱에서 이를 최종 승인한다. 즉, 텔레그램이 고객 접점을 제공하면, 지갑 서비스가 자산 접근 권한을, 문페이(MoonPay)가 자금 유입을, 미니 앱이 해당 자산의 실제 활용을 각각 나누어 담당하는 형태다.

다만 텔레그램이 사용자의 모든 자산을 직접 수탁하는 것은 아니며, 자기수탁형 지갑 특성상 개인키와 복구 수단을 관리할 책임은 여전히 사용자에게 남는다. 그럼에도 이 사례는 메신저에 지갑을 단순히 추가한 수준을 넘어, 외부 자산을 들여오고 실제 서비스에서 사용하기까지의 전체 사용자 경험을 단일한 동선으로 깔끔하게 연결했다는 점에서 의미가 크다. 즉, 텔레그램의 톤 월렛은 문페이를 통한 체인 추상화로 스왑과 브리지 경로 선택을 인프라에 맡겨, 사용자가 다른 체인의 자산도 메신저 안의 지갑으로 가져올 수 있게 했다.

정리하자면 텔레그램의 톤 월렛은 문페이를 통한 체인 추상화로 스왑과 브리지 경로 선택을 인프라에 맡겨, 사용자가 다른 체인의 자산도 메신저 안의 지갑으로 가져올 수 있게 했다.

4.3. 네이버페이와 매직: 자산 보유를 커뮤니티 참여 자격으로 연결한다

공연 티켓을 보유한 사람만 들어갈 수 있는 커뮤니티를 생각해보자. 여기서 사용자가 원하는 것은 토큰의 보유 자체보다는, 같은 행사에 참여한 사람들과 교류하는 공간이며, 이때 지갑은 자산을 보관하는 도구이면서 서비스 이용 자격을 확인하는 수단이 된다.

네이버페이는 2024년 8월 네이버 계정과 전용 비밀번호로 만드는 비수탁형 월렛을 베타 출시했다. 공식 고객센터 안내에 따르면 월렛 주소와 개인키 생성에는 매직랩스(Magic Labs)의 솔루션이 쓰이며, 이를 통해 기존 네이버 계정으로 로그인하고 전용 비밀번호를 설정하는 절차 뒤에 외부 사업자의 지갑 생성 기능을 연결했다.

이때 네이버페이가 설계한 것은 지갑의 진입 화면만이 아니다. 대체불가능토큰(NFT)을 ‘아트’, 트랜잭션 해시를 ‘거래번호’로 표기하고, 네이버페이 앱 안에서 보유 자산을 확인하도록 구성했다. 지갑의 기술적 기능을 도입하되 고객에게 보여주는 용어와 이용 흐름은 기존 플랫폼에 맞췄다.

2026년 3월 출시한 월렛 커뮤니티는 자산 보유에 구체적인 쓰임을 더했다. 월렛은 아트와 티켓, 인증서 형태의 NFT를 보관하며, 커뮤니티의 ‘티켓 인증방’은 해당 티켓이나 관련 아트를 보유한 이용자만 입장하도록 구성되었다. 제주 관광 같은 주제별 일반 채널과 KLPGA 관련 티켓 인증방을 구분해, 일부 커뮤니티의 참여 자격을 자산 보유 여부와 연결한 것이다.

이 흐름을 역할별로 나누면 네이버 계정은 서비스 이용자를 식별하고, 매직의 지갑 기술은 그 이용자의 디지털 자산 계정을 구성하며, 네이버페이는 보유 자산을 어떤 서비스에 쓸지 정한다. 티켓 인증방에서는 이 보유 정보가 입장 조건으로 쓰인다. 지갑 사업자가 커뮤니티의 이용 권한까지 정하는 것이 아니라, 플랫폼이 지갑의 정보를 자사 서비스의 규칙에 연결하는 구조다. 즉, 네이버페이는 지갑과 인증 추상화로 네이버 로그인과 전용 비밀번호 뒤에 지갑 생성을 숨기고, 그 지갑의 자산 보유 정보를 커뮤니티 참여 자격으로 연결했다.

정리하자면 네이버페이는 지갑과 인증 추상화로 네이버 로그인과 전용 비밀번호 뒤에 지갑 생성을 숨기고, 그 지갑의 자산 보유 정보를 커뮤니티 참여 자격으로 연결했다.

5. Web2와 Web3가 결합하는 시대

Web3의 확산은 신규 플랫폼 형성보다는 기존 Web2 서비스 내에서 이루어질 가능성이 크다. 램프의 재무 업무, 텔레그램의 메신저, 네이버페이의 커뮤니티 사례처럼 블록체인의 자산 및 거래 기능이 기존 플랫폼의 계정과 이용 흐름에 자연스럽게 연결되는 모습이 이를 증명한다. 이러한 결합이 확대될수록 사용자는 익숙한 앱과 UX에 머무르면서도 자산 활용 범위를 확장할 수 있다.

이러한 결합을 실제 서비스 수준으로 구현하려면 해결하려는 제약에 맞춰 필요한 지갑과 거래 기능부터 연결해야 한다. 계정 복구, 거래 승인, 수수료 부담, 정산 상태 관리의 주체를 명확히 하고, 이를 기존 고객 지원 체계와 통합하는 작업이 필수적이다. 예컨대 지급 지연 발생 시 고객이 자금 위치와 재처리 여부를 플랫폼 내에서 직접 확인할 수 있어야 블록체인 기능이 일상적인 서비스의 일부로 자리 잡을 수 있다.

가장 먼저 기대를 모으는 분야는 지급 및 정산의 확장이다. 램프가 스테이블코인을 재무 업무에 연결했듯, 이 구조는 판매자 대금이나 창작자 수익을 지급하는 플랫폼에도 적용할 수 있다. 플랫폼이 지급액과 수취인을 확인한 뒤 스테이블코인으로 대금을 송금하고, 수취인이 기존 대시보드에서 내역과 잔액을 확인하도록 구성하면 은행 영업시간의 제약 없이 익숙한 업무 흐름을 유지할 수 있다.

티켓과 멤버십 역시 서비스 간 연결을 넓힐 수 있는 주요 영역이다. 공연 플랫폼에서 발급받은 티켓을 팬 커뮤니티 입장뿐만 아니라 제휴 숙박 할인이나 다음 행사 우선 예매에 활용하는 방식이다. 참여 사업자가 발급자 및 자격 확인 기준에 합의하고 각 서비스에서 지갑 보유 정보를 검증한다면, 단 하나의 티켓으로 여러 서비스의 이용 자격을 얻을 수 있다.

이때 플랫폼이 집중해야 할 핵심은 자산 발급 이후의 활용처 설계다. 네이버페이가 티켓 보유를 커뮤니티 참여 자격과 연결했듯, 지갑 속 자원이 실질적인 혜택으로 이어져야 고객이 해당 자산을 보유하고 Web3가 결합된 플랫폼을 이용할 명분이 생긴다. 제휴 서비스가 늘어날수록 하나의 티켓이나 멤버십으로 누릴 수 있는 가치가 커지며, 이는 기존 고객의 재방문을 유도하는 강력한 유인이 된다.

나아가 제한적 권한 위임이 결제 기능과 결합하면, 사용자가 설정한 범위 내에서 소프트웨어가 필요한 자원을 직접 구매하는 서비스도 가능해진다. 허용된 서비스와 지출 한도를 정책으로 설정하고, 에이전트가 작업에 필요한 데이터나 외부 기능을 자체적으로 구매하도록 위임하는 구조다. 지갑의 권한 관리 체계가 단순히 반복적인 거래 승인을 줄이는 데 그치지 않고, 자동화 서비스의 결제 기반으로 진화하는 셈이다.

이러한 확장을 가속화하는 요인은 기존 고객 기반과 인프라의 재사용이다. 플랫폼은 이미 확보한 고객에게 새로운 가치를 제공할 수 있고, 지갑 및 결제 인프라 사업자는 여러 플랫폼에 동일한 기반 기술을 공급할 수 있다. 기업이 처음부터 지갑과 자금 이동 경로를 구축하던 방식에 비해 개발 부담이 대폭 줄어들며, 한 서비스에서 검증된 활용성을 다른 서비스로 이식하기도 쉬워졌다.

이처럼 Web2와 Web3의 결합은 지급과 커뮤니티 분야에서 본격화되고 있다. 향후 이 접점이 넓어지면 블록체인은 일상적인 앱에서 대금을 수령하고 혜택을 확인하며 필요한 서비스를 구매하는 핵심 기반으로 자리 잡을 것이다. 이 결합의 핵심 축은 단연 추상화이며, 이를 통해 낮춘 진입 장벽과 기존 플랫폼의 고객 기반이 맞물리면서 전환 속도는 더욱 빨라질 것이다.

EastPoint 참여하기