솔라나 우선 수수료, 전송이 밀릴 때 SOL이 더 빠지는 이유

솔라나는 전송 수수료가 낮은 네트워크로 자주 소개됩니다. 그래서 지갑에서 SOL을 보내거나 토큰을 스왑할 때 수수료가 조금 더 커져 보이면 이상하게 느껴질 수 있습니다. 하지만 화면에 보이는 한 줄 수수료가 항상 같은 성격의 비용만 뜻하는 것은 아닙니다.

Solana 수수료는 크게 기본 수수료와 우선 수수료로 나눠 봐야 합니다. 기본 수수료는 거래에 서명이 붙는 데 드는 비용이고, 우선 수수료는 네트워크가 바쁠 때 거래가 더 빨리 처리되도록 지갑이나 앱이 추가할 수 있는 선택 비용입니다. 이 둘이 합쳐지면 “SOL 수수료가 왜 더 빠졌지?”라는 느낌이 생깁니다.

한 줄 수수료의 두 갈래

Solana의 Fee Structure 문서는 총 수수료를 base fee와 prioritization fee의 합으로 설명합니다. 여기서 base fee는 현재 서명 1개당 5,000 lamports로 계산됩니다. 1 SOL은 아주 많은 lamports로 쪼개지기 때문에 숫자만 보면 작아 보이지만, 지갑 안에서는 실제 SOL 잔고에서 빠지는 비용입니다.

중요한 점은 우선 수수료가 별도 층으로 붙을 수 있다는 것입니다. 기본 수수료는 거래가 서명되고 네트워크에 올라가는 데 필요한 바닥 비용에 가깝고, 우선 수수료는 현재 leader가 거래를 더 앞쪽에 배치하도록 유도하는 비용에 가깝습니다. 그래서 같은 전송이라도 지갑 설정, 앱의 기본값, 네트워크 혼잡도에 따라 보이는 총액이 달라질 수 있습니다.

빠른 전송에 붙는 값

우선 수수료는 “빠른 전송 버튼” 같은 말로 보이면 단순한 가속 옵션처럼 느껴집니다. 하지만 안쪽 계산은 조금 다릅니다. Solana 문서는 우선 수수료가 compute unit price와 compute unit limit를 곱한 뒤 lamports 단위로 바뀌는 구조라고 설명합니다. 쉽게 말하면, 거래가 쓸 수 있는 계산량 한도와 그 한도에 붙일 단가를 정해 두고 비용을 계산하는 방식입니다.

여기서 독자가 봐야 할 단어는 실제 사용량보다 요청한 한도입니다. Compute Budget 문서는 priority fee가 실제로 사용한 compute unit이 아니라 transaction에 요청된 compute unit limit 기준으로 정해진다고 설명합니다. 한도를 필요 이상으로 높게 잡으면 쓰지 않은 여유에도 비용을 낼 수 있다는 뜻입니다.

실패해도 사라지는 비용

전송이 실패했는데 SOL이 조금 줄어든 것처럼 보이면 더 억울하게 느껴집니다. 하지만 Solana 수수료는 실행 전에 fee payer에게서 차감될 수 있고, 실패한 거래도 수수료가 붙을 수 있습니다. 실패가 곧 무료 취소를 뜻하지 않는다는 점을 먼저 봐야 합니다.

예를 들어 토큰 스왑이 가격 조건이나 계정 상태 때문에 실패했더라도, 네트워크가 서명 확인과 실행 시도를 처리했다면 비용은 남을 수 있습니다. 이때 빠진 금액이 전송한 토큰이 아니라 SOL 수수료라면, 자산이 사라진 사고라기보다 실패한 transaction 비용일 가능성을 먼저 확인해야 합니다.

누가 수수료를 내는가

Solana 거래에는 fee payer가 있습니다. Transaction Structure 문서는 첫 번째 서명자가 수수료를 내는 계정이며, base fee와 prioritization fee를 감당할 lamports가 필요하다고 설명합니다. 그래서 지갑에 토큰은 있어도 SOL이 너무 적으면 거래가 막힐 수 있습니다.

이 구조는 스테이블코인이나 다른 SPL 토큰을 보낼 때도 중요합니다. 보내려는 자산이 USDC나 다른 토큰이어도, 네트워크 수수료를 낼 SOL이 필요할 수 있습니다. 지갑 화면에서 토큰 잔고만 넉넉하게 보이면 전송이 될 것 같지만, 실제로는 fee payer 계정의 SOL 여유가 먼저 확인됩니다.

지갑 화면에서 볼 순서

수수료가 예상보다 크게 보일 때는 숫자를 하나로 뭉쳐 보지 않는 편이 낫습니다. 먼저 기본 수수료와 우선 수수료가 나뉘는지 봅니다. 다음으로 지갑이나 앱이 빠른 처리 옵션을 자동으로 켰는지 확인합니다. 마지막으로 전송할 토큰 잔고가 아니라 SOL 잔고가 수수료까지 감당할 만큼 남아 있는지 봅니다.

짧게 정리하면 확인 순서는 이렇습니다.

• 지갑이 보여 주는 총 수수료 안에 우선 수수료가 붙었는지
• compute unit limit가 과하게 잡혀 있지는 않은지
• 실패한 거래 기록인지, 아직 pending 상태인지
• fee payer 계정에 남은 SOL이 다음 거래까지 버틸 만큼 있는지

이 네 가지를 나눠 보면 “수수료가 비싸졌다”는 말이 조금 선명해집니다. 네트워크 기본 비용이 오른 것인지, 앱이 우선 수수료를 붙인 것인지, 아니면 복잡한 스왑이나 프로그램 호출 때문에 계산 한도가 커진 것인지 구분할 수 있습니다.

스테이킹 숫자와 다른 잔고

SOL을 스테이킹하거나 보상률을 비교할 때도 수수료 잔고는 따로 남겨 봐야 합니다. 솔라나 스테이킹 데이터처럼 보상률을 볼 때는 APR 숫자가 먼저 보이지만, 실제 지갑 사용에서는 전송, 위임, 해제, 스왑에 필요한 SOL 수수료가 별도로 움직입니다.

이전의 솔라나 스테이킹 에폭 글은 보상과 출금 가능 시점이 epoch와 stake account 상태에 묶인다는 점을 다뤘습니다. 이번 수수료 문제는 다른 층입니다. SOL이 어디에 묶였는지와 별개로, 거래를 실행할 때 누가 수수료를 내고 우선 수수료가 붙었는지를 읽어야 합니다.

솔라나 우선 수수료는 겁낼 이름은 아니지만 무시할 숫자도 아닙니다. 전송이 급하지 않다면 지갑의 빠른 처리 옵션을 낮출 수 있는지 보고, 복잡한 거래라면 한 번에 큰 금액을 움직이기 전에 수수료와 실패 가능성을 먼저 확인하는 편이 좋습니다. SOL 잔고가 조금 줄어든 이유를 찾을 때는 가격보다 먼저 거래 기록, fee payer, 우선 수수료를 같이 보는 것이 출발점입니다.