지난 5년 동안 "트랜잭션을 위한 SOL 부족(insufficient SOL for transaction)"은 솔라나에서 가장 비용이 많이 드는 오류 메시지였습니다. 비암호화폐 사용자를 대상으로 한 모든 소비자용 앱은 바로 그 지점, 즉 첫 번째 토큰을 사용하기 위해 사용자가 두 번째 토큰을 획득해야 하는 결제 단계에서 상당수의 사용자를 잃었습니다. 2026년 4월, 솔라나 재단은 마침내 그 해답을 내놓았습니다. 바로 dApp이 기본적으로 트랜잭션을 대납하고, 모든 SPL 토큰으로 수수료를 지불하며, 서명을 TEE 또는 KMS 기반 금고에 아웃소싱할 수 있게 해주는 수수료 릴레이어이자 서명 노드인 Kora 입니다. 이는 화려한 출시는 아니지만, 기반 시설의 업그레이드입니다. 그리고 이러한 기반 시설 업그레이드는 Base와 Abstract가 지난 12개월 동안 소비자 온보딩 시장을 조용히 점유할 수 있었던 비결이기도 합니다.
이제 질문은 솔라나가 EVM 소비자 체인의 가스리스(gasless) UX를 따라잡을 수 있느냐가 아닙니다. Kora는 그 부분을 아주 사소한 문제로 만들었습니다. 진짜 질문은 이 라스트 마일의 간극을 메우는 것이 이미 다른 곳에서 개발을 진행한 개발자들을 다시 불러오기에 충분한가 하는 점입니다.
Kora의 실제 기능
마케팅 수사를 걷어내면 Kora는 트랜잭션 릴레이어, 원격 서명기(remote signer), 정책 엔진이라는 세 가지 요소가 결합된 것입니다. dApp이 트랜잭션을 생성하고 Kora 노드를 수수료 지불자(fee payer)로 설정하면, 사용자는 임베디드 지갑에서 페이로드를 서명하고, Kora 운영자가 공동 서명(co-sign)하여 네트워크에 전송합니다. 검증인은 여전히 SOL로 보상을 받지만, 사용자는 SOL을 전혀 보유할 필요가 없습니다.
흥미로운 부분은 검증 레이어입니다. Kora 노드는 사용자가 전달하는 모든 것을 맹목적으로 전달하지 않습니다. 서명하기 전에 다음 세 가지 검사를 수행합니다:
- 관련 솔라나 프로그램에 대한 명령어 검증(Instruction validation) 을 통해 잘못 형성되거나 악의적인 명령어가 리더에게 도달하기 전에 거부됩니다.
- 현재 SOL 가격과 운영자 마진을 비교하는 오라클 기반 수수료 적정성 검사 를 통해 릴레이어가 손실을 보고 운영되지 않도록 합니다.
- 프로그램 및 토큰 수준의 허용 목록(Allowlist) 및 차단 목록(Blocklist) 강제 적용 을 통해 특정 dApp을 위해 Kora 노드를 운영하는 운영자가 실수로 감사되지 않은 무작위 컨트랙트를 대상으로 하는 트랜잭션을 대납하지 않도록 합니다.
서명 경로는 아키텍처가 야심 차게 설계된 부분입니다. Kora는 Turnkey 및 AWS KMS를 통한 원격 서명을 기본적으로 지원하므로, 수수료를 지불하는 개인 키가 릴레이어의 디스크에 절대 저장되지 않습니다. 솔라나 기반 핀테크 기업의 경우, 이는 "자체적으로 페이마스터를 만들고 잘 작동하길 빌었다"는 것과 "우리의 키 수탁 체계가 SOC 2 감사를 통과했다"는 수준의 차이를 의미합니다.
이 모든 과정은 Runtime Verification에 의해 감사 및 차등 퍼즈 테스트(differentially fuzz-tested)를 거쳤으며, 이는 기관들이 항목을 검토할 때나 언급될 법한 세부 사항입니다.
왜 여기서는 "네이티브"가 "스마트 컨트랙트"보다 나은가
Kora를 ERC-4337과 비교하며 솔라나가 추격하고 있다고 생각하기 쉽습니다. 하지만 두 아키텍처는 서로 다른 방식으로 작동하며, 그 차이가 중요합니다.
ERC-4337은 계정 추상화(account abstraction)를 이더리움 상단에 병렬 시스템으로 구현한 것입니다. 이는 별도의 멤풀(mempool), UserOperation 객체, 번들러(bundler) 역할, 그리고 EntryPoint 컨트랙트를 도입하는데, 이들 중 어느 것도 기본 프로토콜이 네이티브하게 이해하는 것은 아닙니다. 번들러가 사용자 작업을 패키징하고, 페이마스터가 수수료를 대납하며, 온체인 컨트랙트가 검증을 강제합니다. 이는 작동하며 이더리움 메인넷과 주요 L2에 배포되었지만, 프로토콜이 전혀 예상하지 못했던 UX 기능을 소급 적용하기 위한 6년짜리 건설 프로젝트와 같습니다.
솔라나의 설 계는 수년 전 프로토콜 레이어에서 이러한 복잡성을 이미 해결했습니다. 모든 트랜잭션에는 이미 feePayer 필드가 존재합니다. 부분 서명(Partial signatures)은 네이티브 기능입니다. 프로그램은 임의의 명령어를 검증할 수 있습니다. Kora는 번들러-페이마스터 구조가 아니라, feePayer 슬롯을 채우고 프로토콜이 이미 수용하는 부분 서명 중 하나로 서명하는 노드 운영자입니다.
실제적인 결과는 지연 시간(latency)과 개발자 접점 영역에서 나타납니다. ERC-4337 트랜잭션은 자체 정렬 규칙과 전파 지연이 있는 별도의 멤풀을 거칩니다. 반면 Kora 트랜잭션은 다른 모든 솔라나 트랜잭션과 동일한 경로를 거치며 400ms 미만의 동일한 파이널리티(finality)를 가집니다. 고려해야 할 번들러 차익 거래 시장도, 추적해야 할 EntryPoint 컨트랙트 버전도, 디버깅해야 할 UserOperation 가스 추정치도 없습니다.
이를 통해 솔라나 개발자가 얻는 것은 "수수료 지불자 필드를 설정하고 dApp을 출시하는" 것에 가까운 단순함입니다. 반면 잃는 것은 다중 키 인증, 배치 호출, 온체인 세션 정책 등 EVM 스마트 계정이 기본적으로 제공하는 일부 선택권입니다. 하지만 이러한 기능 중 상당수는 PDA 및 프로그램 제어 계정을 통해 솔라나에서 별도로 구축되고 있습니다.
솔라나에 실제로 존재했던 라스트 마일 간극
2025년과 2026년 솔라나의 개발자 모멘텀에 대한 많은 이야기에도 불구하고, 소비자 지갑 레이어는 뒤처진 부분이었습니다. 인프라 스택은 빠르게 성숙했습니다. Pump.fun의 DEX 거래량은 2026년 1분기에 20억 달러를 돌파했고, Jito와 Marinade는 유동 스테이킹을 장악했으며, Tensor는 NFT 거래를 전문 터미널 수준으로 끌어올렸습니다. 하지만 이 모든 제품은 "사용자에게 SOL이 없다"는 문제에 대해 각자의 답을 내놓아야 했습니다.
우회 방법들은 창의적이었습니다. Pump.fun은 초기 토큰 획득을 임베디드 온램프(onramp)를 통해 라우팅했습니다. Jito는 사용자 계정에 소액(dust)을 미리 채워두었습니다. Tensor는 사용자가 매수 호가창에 도달하기 전 Phantom이나 Backpack이 SOL 획득 단계를 처리하도록 의존했습니다. 이들 각각은 개별적으로 작동했지만 서로 호환되지는 않았습니다. Pump.fun의 흐름을 통해 온보딩된 사용자가 수수료를 지불할 수 있는 잔액을 가진 상태로 Tensor에 도착하는 것은 아니었습니다.
그동안 Base는 Coinbase Smart Wallet의 패스키(passkey) 흐름, Coinbase Developer Platform을 통한 무료 가스 대납, 그리고 이메일 로그인 뒤에 개인 키의 개념 전체를 숨기는 개발자 SDK를 출시했습니다. Abstract는 웹2 앱처럼 느껴지는 임베디드 지갑으로 같은 아이디어를 더 발전시켰습니다. 2025년 소비자 앱 개발자에게 전달된 결합된 메시지는 이렇습니다. "Base에서 빌드하세요. 사용자들은 자신이 온체인에 있다는 사실조차 모를 것이며, 여러분이 확장하는 동안 우리가 수수료를 지불하겠습니다."
Kora는 그 메시지를 그대로 복제하는 것이 아닙니다. Kora가 하는 일은 솔라나 dApp이 동일한 메시지를 던지지 못하게 만들었던 아키텍처적 원인을 제거하는 것입니다. 이제 Kora를 통해 솔라나 팀은 다음을 제공할 수 있습니다:
- Privy, Turnkey 또는 Coinbase Embedded Wallets를 통한 이메일 또는 패스키 가입.
- 트랜잭션에 SOL 잔액이 전혀 필요 없음.
- USDC, BONK 또는 dApp의 네이티브 토큰(있는 경우)으로 수수료 지불.
- 경로에 번들러가 없는 1초 미만의 파이널리티.
구성 요소들은 이전에도 존재했습니다. Octane은 오픈 소스 조상격이었고, Circle의 Gas Station, Openfort, Portal, Gelato, Biconomy 및 기타 여러 벤더가 수수료 릴레이 서비스를 제공했습니다. Kora가 바꾸는 점은 이제 솔라나 재단이 직접 표준화되고 감사를 마친 KMS 호환 레퍼런스 구현체를 출시한다는 것입니다. 이를 통해 이전까지 자체적으로 구축하거나 벤더 비용을 지불해야 했던 모든 팀의 의사 결정 과정에서 "어떤 제3자 페이마스터를 신뢰해야 하는가"라는 고민이 사라지게 됩니다.
Kora 상위의 벤더 레이어
흥미로운 점은 Kora가 메운 간극을 중심으로 이미 구축된 임베디드 지갑 벤더들에게 어떤 일이 일어나는가 하는 점입니다.
2025년 6월 Stripe에 인수된 Privy는 이메일 로그인을 원하는 Solana dApp들이 선호하는 컨슈머 앱 지갑이었습니다. Solana는 공식적으로 Privy의 보조 체인이며(주요 깊이는 EVM에 있음), 임베디드 지갑 흐름은 Solana까지 확장되며 Privy는 이미 앱이 관리하는 수수료 지불자(fee payer) 지갑 설정을 지원합니다. Kora는 Privy를 대체 하는 것이 아니라, 각 고객이 자체 페이마스터 서비스를 운영하는 대신 Privy가 연결할 수 있는 표준화된 백엔드를 제공합니다.
Turnkey는 Kora의 원격 서명 API와 자연스럽게 어울리는 보안 우선 임베디드 서명기(signer)입니다. Turnkey는 페이마스터 인프라를 명시적으로 포함하지 않으므로, 하드웨어 격리 키와 가스리스 UX를 원하는 Solana 팀들은 두 벤더를 억지로 결합해야 했습니다. Kora는 이러한 통합의 번거로움을 없애줍니다.
2025년 Fireblocks에 인수된 Dynamic은 기관 팀에 멀티체인 인증을 제공합니다. Fireblocks의 지원을 받는 포지셔닝 덕분에 Dynamic은 기업 수준의 규정 준수와 함께 Solana 및 EVM 지원이 모두 필요한 핀테크 기업들에게 자연스러운 선택지가 됩니다. Kora는 Dynamic에 Fireblocks가 경쟁 페이마스터를 출시할 필요가 없는 깔끔한 Solana 수수료 추상화 모델을 제공합니다.
Coinbase Developer Platform은 다소 애매한 위치에 있습니다. Coinbase는 Coinbase Smart Wallet, 무료 Base 가스비, 임베디드 지갑 SDK를 통해 Base를 기본 컨슈머 체인으로 만드는 데 집중 투자해 왔습니다. Kora는 특히 Solana가 이미 규모의 경제 우위를 점하고 있는 USDC 네이티브 흐름을 원하는 앱들에게 Base가 내세우던 차별화 요소를 좁힙니다.
가능성 높은 결과는 Kora가 페이마스터 서비스를 직접 운영하고 싶지 않은 모든 임베디드 지갑 벤더의 기본 Solana 백엔드가 되는 것입니다. 벤더들은 인증 UX, 키 관리, 정책 제어 분야에서 경쟁하고, Kora는 그 아래에서 수수료 릴레이를 처리합니다. 이는 모든 컨슈머 Solana dApp이 독립적으로 벤더를 결정하고 각 후보의 자체 제작 릴레이어 보안을 평가해야 했던 이전 상태보다 생태계 전체에 더 건전한 방식입니다.
이것이 해결하는 문제와 해결하지 못하는 문제
Kora는 특정 간극을 확실히 메우지만 다른 여러 문제는 해결하지 않은 채로 둡니다. 각각을 정확히 구분할 필요가 있습니다.
Kora가 해결하는 문제:
- 다른 토큰으로 수수료를 보조하려는 dApp에 있어 "사용자가 반드시 SOL을 보유해야 함"이라는 UX 장벽을 제거합니다.
- 운영 부담과 벤더 종속(lock-in) 사이에서 고민해야 했던 팀들의 "페이마스터 직접 구축 vs 구매" 결정을 해결합니다.
- 감사(audit) 및 KMS 지원을 통해 규제 대상 기관이 직접 솔루션을 구축하지 않고도 Kora 노드를 운영할 수 있게 함으로써 기관의 수용 가능성 격차를 해소합니다.
Kora가 해결하지 못하는 문제:
- 지갑 획득 자체 — 사용자는 여전히 Phantom, Privy, Turnkey, Coinbase 등 어딘가에서 임베디드 지갑을 가져와야 합니다.
- 배치 호출(batched calls) 및 세션 키와 같은 계정 추상화 프리미티브 — 이들은 여전히 PDA 및 기타 프로그램 수준 패턴을 통해 Solana에서 별도로 조립되고 있습니다.
- Kora 운영자가 선지불하는 SOL 비용을 누가 지불할 것인가라는 경제적 문제. 토큰 수익이나 스테이블코인 유동성이 있는 dApp의 경우 이는 괜찮지만, 무료 제품의 경우 가스비 후원은 단순한 고객 획득 비용(CAC)입니다.
- 크로스체인 UX — 사용자는 여전히 LayerZero, Wormhole, Across와 같은 브릿지나 체인 추상화 레이어와 상호작용해야 합니다.
"프로토콜 프리미티브로서의 가스리스 인프라"라는 논제는 양날의 검입니다. 이제 Solana는 주요 체인 중 가장 깔끔한 네이티브 수수료 추상화 모델을 갖게 되었습니다. 이는 차별화 요소가 지갑 UX, 복구 흐름, 그리고 EVM이 수년간 앞서나간 계정 추상화 기능과 같은 상위 스택으로 이동함을 의미합니다.
빌더를 위한 전략적 해석
2026년 중반에 체인을 선택하는 팀에게 계산법이 바뀌었습니다. 12개월 전만 해도 컨슈머 온보딩에 대한 답은 Base, Abstract 또는 새로운 EVM 컨슈머 체인 중 하나였습니다. Solana는 개발자들의 관심과 인프라 모멘텀은 있었지만, SOL 획득 단계에서 일반 사용자들을 놓쳤습니다. 이제는 더 이상 그렇지 않습니다.
오늘 Solana에서 프론트엔드에 Privy나 Turnkey를, 백엔드에 Kora를 사용하여 출시하는 컨슈머 dApp은 기능적으로 Base의 동일한 스택과 동일한 UX 환경을 갖습니다. 이메일 로그인, 가스리스 트랜잭션, USDC 수수료 지불, 1초 미만의 완결성. 남은 차이점은 런타임 모델, 툴링 생태계, 그리고 가용 유동성뿐입니다. Solana의 처리량과 DEX 깊이를 원하는 앱에 있어 EVM을 선택해야 할 UX 측면의 논거는 상당히 약해졌습니다.
이미 Base에서 서비스를 운영 중인 팀들에게 Kora가 즉각적인 결정을 바꾸지는 않습니다. 하지만 장기적인 경쟁 압력은 변화시킵니다. 새로운 인프라 덕분에 통합에 대한 걱정이 줄어들어 가장 깔끔한 UX를 가진 컨슈머 dApp들이 Solana에서 나타나기 시작한다면, Base의 컨슈머 온보딩 해자를 중심으로 형성된 중력은 이동하기 시작할 것입니다.
솔직하게 평가하자면 Kora는 필요조건이지 충분조건은 아닙니다. 개발자들이 컨슈머 앱을 위해 Solana를 선택하지 않았던 특정 이유를 제거할 뿐입니다. Kora 자체가 Solana를 선택해야 할 새로운 이유를 만들어내지는 않습니다. 앞으로 두 분기 동안 임베디드 지갑 벤더들이 실제로 Kora를 기본값으로 채택하는지, 새로운 컨슈머 dApp들이 체인 선택의 이유로 Kora를 언급하는지, 그리고 기존 EVM 컨슈머 체인들이 자체 인프라를 개선하며 대응하는지 지켜봐야 할 것입니다.
어느 쪽이든, "거래 전 사용자가 SOL을 반드시 획득해야 함"은 이제 현재의 문제가 아니라 과거의 유산이 되었습니다. 그것만으로도 출시할 가치가 충분합니다.
BlockEden.xyz는 컨슈머 dApp, 결제망, 트레이딩 시스템을 구축하는 팀들을 위해 프로덕션 등급의 Solana RPC 인프라를 운영합니다. 가스리스 흐름을 통합하거나 Solana 제품을 확장하고 있다면, 차세대 컨슈머 크립토를 위해 설계된 저지연 엔드포인트를 저희 API 마켓플레이스에서 확인해 보세요.
