커스텀 가스 토큰: 트랜잭션 수수료에 ERC-20 토큰을 사용하는 방법
작성자 Usman Asim

역사적으로 범용 블록체인(Ethereum, Solana 등)은 트랜잭션 수수료에 사용되는 네이티브 토큰을 지정해 왔습니다. 앱체인과 rollups의 등장으로, Custom Gas Token(CGT)을 통해 블록체인 운영자가 자체 네이티브 토큰을 설정할 수 있게 되었습니다.
이 기능은 토큰 유틸리티 강화, 사용자 경험 개선, 생태계 경제에 대한 더 큰 통제력 등의 이점을 제공합니다. 다만 구현 시 기술적 접근 방식(Native vs. Account Abstraction)과 그에 따른 경제적 트레이드오프를 신중히 고려해야 합니다.
Custom Gas Token이란?
Custom Gas Token(CGT)은 체인 빌더가 트랜잭션 비용 지불을 위해 설정하는 대체 토큰(주로 ERC-20)입니다. 이를 통해 블록체인 인프라에 대한 사고방식이 바뀌며, 프로토콜 개발자는 네트워크 수수료가 생태계 자체 통화로 지불되는 독립적인 경제 시스템을 만들 수 있습니다.
이 기능은 애플리케이션 전용 체인, 게이밍 생태계, 그리고 매끄러운 사용자 경험을 만들고자 하는 DeFi 프로토콜에 특히 유용합니다.
체인 운영자와 애플리케이션 개발자를 위한 주요 이점

- 토큰 유틸리티 강화: 토큰을 투기성 자산이나 거버넌스 자산에서 필수 인프라로 전환시킵니다. 모든 트랜잭션에 토큰이 필요하므로, 투기가 아닌 근본적인 유틸리티를 통해 가치 축적을 이끄는 지속적이고 실질적인 수요가 발생합니다.
- 경제적 가치의 내재화: 트랜잭션 수수료가 ETH나 다른 외부 토큰으로 유출되지 않고 생태계 내부에 남습니다. 이를 통해 커뮤니티가 네트워크 활동으로 발생한 가치를 직접 포착하는 더 지속 가능한 경제 모델이 만들어집니다.
- 통합된 브랜드 경험: 사용자가 전적으로 자체 네이티브 토큰으로 상호작용하도록 함으로써 생태계의 정체성을 강화합니다. 브랜드 일관성과 사용자 경험 차별화가 중요한 게이밍 체인, 소셜 플랫폼, 또는 특화된 DeFi 생태계에 특히 유용합니다.
- 사용자 경험 개선: 사용자가 여러 토큰을 계속 관리해야 하는 "가스 토큰 셔플"을 없앱니다. Custom Gas Token을 사용하면 사용자는 생태계 내 모든 필요를 위해 단 하나의 토큰만 보유하면 되므로 온보딩 마찰이 크게 줄어듭니다.
구현 방식: Native vs. Account Abstraction
Native 구현
Native 방식은 프로토콜 수준에서 모든 가스 지불에 특정 ERC-20 토큰을 사용하도록 제네시스 시점에 체인을 구성합니다.
지원 체인:
- ✅ Arbitrum Orbit (동적 가격 오라클을 포함한 완전 지원)
- ✅ zkSync Era (지속 지원 중)
- ✅ Avalanche L1s
- ❌ OP Stack (2024년 5월부로 지원 중단)
주요 특징:
- 모든 트랜잭션이 지정된 토큰을 사용해야 함
- 기존 개발자 도구 및 인프라와 직접 통합
- 제네시스 배포 후 설정이 불변으로 고정됨
- EVM 수준에서 결정론적 가스 계산 제공
주요 고려사항:
- 여러 토큰을 지원하거나 배포 후 토큰을 변경할 유연성이 없음
- 사용자가 지정된 토큰을 확보해야 하므로 온보딩이 복잡해질 수 있음
- 프로토콜 수준에서 예측 가능한 가스 비용으로 트랜잭션 흐름이 단순화됨
- 네이티브 ETH나 다른 토큰을 기대하는 애플리케이션과의 호환성이 제한될 수 있음
- 지정된 토큰이 체인 전체에서 채택되어야 하므로 생태계 다양성에 영향을 미침
Account Abstraction 구현
Account Abstraction 방식은 ERC-4337 표준을 활용해 체인의 핵심 프로토콜을 수정하지 않고도 paymaster 아키텍처를 통해 모든 ERC-20 토큰으로 가스를 지불할 수 있게 합니다.
지원 체인:
- ✅ ERC-4337을 준수하는 모든 체인과 호환
- ✅ OP Stack 지원 중단 이후의 업계 트렌드에 부합
- ❌ paymaster 인프라가 필요하며 체인마다 다를 수 있음
- ❌ 프로토콜 수준에서 강제되지 않아 보편적 채택이 제한됨
주요 특징:
- 여러 토큰을 지원하거나 프로토콜 업그레이드 없이 토큰을 변경할 수 있는 최대한의 유연성 제공
- 애플리케이션이 서로 다른 가스 토큰을 지정할 수 있는 세분화된 제어 가능
- ERC-20 토큰을 받아 내부적으로 전환을 처리함으로써 매도 압력 회피
- ERC-4337 표준에 부합하는 미래지향적 아키텍처 제공
주요 고려사항:
- 추가 인프라(paymaster, bundler, entry point)로 인해 복잡성 증가
- 개발자와 사용자 모두에게 가스 예측과 트랜잭션 흐름이 복잡해짐
- 토큰 브리징을 없애 다양한 토큰 사용에 대한 사용자 경험을 단순화
- 토큰 사용이 애플리케이션 수준에서 강제되므로 일관되지 않은 채택 위험 존재
- 블록 익스플로러, 인덱서 등 다운스트림 도구에 대한 맞춤 구성 필요
경제적 고려사항
상위 체인 수수료 문제
L2가 Custom Gas Token을 사용하더라도 Ethereum(L1)의 데이터 가용성 비용을 위해 여전히 ETH가 필요합니다. 마찬가지로 L3는 자신의 L2의 네이티브 토큰이 필요합니다. 이는 중요한 경제적 역학을 만듭니다:
- 수집 단계: 체인이 사용자로부터 CustomToken을 가스 수수료로 축적
- 전환 필요성: 체인이 데이터 게시 비용을 위해 ETH/상위 토큰이 필요
- 시장 운영: 체인이 CustomToken → 상위 토큰 스왑을 실행해야 함
- 가격 영향: CustomToken에 대한 체계적인 매도 압력 발생
토큰 경제 관리
체인 운영자는 다음을 고려하는 정교한 경제 모델을 구현해야 합니다:
- 수집 예측: 가스 토큰 축적 비율에 대한 통계 모델
- 환율 변동성: 토큰 가격 변동에 대한 헤징 전략
- 유동성 요구사항: 전환에 충분한 시장 깊이 확보
- 준비금 관리: 가격 충격에 대비한 운영 버퍼 유지
위험 시나리오: 토큰 가격이 50% 하락하면 수집된 가스 수수료로는 상위 체인 비용을 충당하기에 부족해져, 블록마다 누적되는 운영 적자가 발생할 수 있습니다.
기술 요구사항 및 사양
일반적인 ERC-20 토큰 준수 요구사항
토큰 구현은 일반적으로 다음의 기술적 제약을 충족해야 합니다:
- 표준 ERC-20 인터페이스 구현
- 정확히 18자리 소수점(컨트랙트 수준에서 강제)
- 리베이싱하지 않는 토큰 공급 메커니즘
- 전송 수수료나 세금 메커니즘 없음
- 콜백 훅 없음(ERC-777 기능 없음)
name\(\)및symbol\(\)반환값 ≤ 32바이트- 전송을 위한 단일 진입점(업그레이드 가능한 프록시 패턴 없음)
핵심 프로토콜 인터페이스
solidity
interface IGasToken {
/// @notice Returns the gas token address and decimals/// @return token The ERC20 token address (or 0xEeee...eEEeE for ETH)/// @return decimals Always 18 for valid gas tokens
function gasPayingToken() external view returns (address token, uint8 decimals);
/// @notice Returns the gas token name
function gasPayingTokenName() external view returns (string memory);
/// @notice Returns the gas token symbol
function gasPayingTokenSymbol() external view returns (string memory);
/// @notice Indicates if a custom gas token is active
function isCustomGasToken() external view returns (bool);
}ETH를 사용하는 체인의 경우, gasPayingToken\(\)는 다음을 반환해야 합니다: \(0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE, 18\)
Account Abstraction 트랜잭션 흐름
AA 가스 지불 흐름은 다음 순서로 작동합니다:
- User Operation 제출: 사용자가 custom token 가스 지불 의도로 operation에 서명
- Paymaster 검증: 토큰 수락 여부를 검증하고 필요한 금액을 계산
- 토큰 수집: paymaster가
transferFrom를 통해 사용자로부터 custom token을 가져옴 - 가스 지불: paymaster가 실제 실행 비용을 위해 bundler에게 ETH를 지불
- 정산: paymaster가 토큰 → ETH 전환을 비동기적으로 처리
이 아키텍처는 보안 보장을 유지하면서 최종 사용자로부터 가스 복잡성을 추상화합니다.
프로덕션 구현 사례
성공적인 배포 사례
Degen Chain (Base 위의 Arbitrum Orbit L3)
- 첫 주 1,400만 건 이상의 트랜잭션
- 77만 개 이상의 활성 주소
- 6,000만 달러 이상의 총 브릿지 가치
- 네이티브 커뮤니티 토큰으로 강력한 제품-시장 적합성 입증
DeFi Kingdoms (Avalanche Subnet)
- CRYSTAL을 custom gas token으로 구현
- 스테이킹 기반의 새로운 분배 메커니즘
- 경제적 전환 과정에서도 사용자 참여 유지
인프라 제공업체 고려사항
RaaS 제공업체와 인프라 팀은 Custom Gas Token을 활용해 자동화된 토큰 검증, 가격 오라클 통합, 유동성 관리 솔루션 등 차별화된 서비스를 제공할 수 있습니다. 이는 rollup 생태계에서 부가가치 서비스에 대한 새로운 기회를 창출합니다.
Optimism의 지원 중단에서 얻는 교훈
2024년 5월 Optimism이 네이티브 Custom Gas Token 지원을 중단한 사례는 중요한 시사점을 제공합니다:
- L1 portal 컨트랙트 수정에 따른 보안 우려
- 프로토콜 업그레이드에 대한 아키텍처적 경직성
- Account Abstraction 패턴을 통한 더 나은 사용자 경험
마이그레이션 및 업그레이드 고려사항
⚠️ 중요 경고: 배포 후 가스 토큰을 마이그레이션하거나 변경하는 것은 상당한 기술적 어려움을 수반합니다.
마이그레이션의 복잡성에는 다음이 포함됩니다:
- 상태 마이그레이션을 포함한 브릿지 컨트랙트 업그레이드
- 자금 조정을 위한 체인 전체 일시 정지
- 사용자 잔액 매핑 및 검증
- 생태계 전체에 걸친 조율된 전환
- 마이그레이션 중 자금 손실의 위험이 0이 아님
모범 사례: 철저한 경제 모델링을 수행하고, 제네시스 시점에 구현 아키텍처를 신중하게 선택하십시오. 확신이 서지 않는다면, 선택지를 열어두기 위해 Account Abstraction을 선택하십시오.
구현 결정 프레임워크
다음의 경우 사용하십시오:
- 실질적인 유틸리티와 유동성을 갖춘 강력한 토큰이 있는 경우
- 사용자가 이미 해당 토큰을 보유하고 적극적으로 사용하는 경우
- 체인의 경제에 대한 완전한 통제권을 원하는 경우
- 폐쇄형 생태계(게이밍, 소셜)를 구축하는 경우
- 유동성 관리를 위한 자원을 보유한 경우
다음의 경우 사용하지 마십시오:
- 다른 체인과의 최대한의 상호운용성이 필요한 경우
- 토큰이 변동성이 크거나 유동성이 낮은 경우
- "최대한 ETH에 정렬"되기를 원하는 경우
- 운영 복잡성을 감당할 자원이 부족한 경우
- 관할 지역에 규제 우려가 있는 경우
업계 동향 및 향후 전망
생태계는 Custom Gas Token 인프라를 향한 뚜렷한 흐름을 보여주고 있습니다:
- Optimism: Native 구현 완전 중단
- Arbitrum: 이중 지원과 함께 AA 채택 증가
- zkSync: Native 지원 유지 및 AA 로드맵 진행
- Avalanche: 두 방식을 모두 지원하는 프로토콜 중립적 접근
- 업계 표준: L2 전반에서 ERC-4337 채택 가속화
기술적 요점
- 경제적 지속가능성에는 정교한 관리가 필요합니다: 적절한 유동성 공급, 가격 헤징, 준비금 관리는 운영 성공을 위해 타협할 수 없는 요소입니다
- 사용자 경험이 채택을 이끕니다: 가스 토큰 마찰을 없애면 전환율이 수십 배 향상될 수 있습니다
- 선택지 확보에는 정량화 가능한 가치가 있습니다: 배포 후 가스 토큰 전략을 수정할 수 있는 능력은 AA의 추가적인 복잡성을 정당화합니다
자주 묻는 질문
Q: Custom Gas Token(CGT)이 정확히 무엇인가요?
A: Custom Gas Token은 프로토콜 또는 애플리케이션 계층에서 ETH나 체인의 네이티브 토큰 대신, 어떤 ERC-20 토큰이든 블록체인의 트랜잭션 수수료 지불에 사용할 수 있게 합니다.
Q: 배포 후에 가스 토큰을 변경할 수 있나요?
A: Native 구현은 제네시스 이후 불변입니다. Account Abstraction 구현은 프로토콜 변경 없이 런타임 수정을 지원합니다.
Q: 현재 어떤 체인이 Custom Gas Token을 지원하나요?
A: Arbitrum Orbit, zkSync Era, Avalanche L1s가 Native 지원을 제공합니다. 모든 EVM 체인은 ERC-4337을 통해 AA 기반 구현을 지원합니다.
Q: 운영 비용은 어느 정도인가요?
A: Native 구현에서는 유동성 관리, 가격 슬리피지, 운영 버퍼를 위해 10-20%의 오버헤드를 예상해야 합니다. AA는 트랜잭션당 약 21,000 가스를 추가로 소모하지만 유동성 관리 오버헤드는 없앱니다.
결론
Custom Gas Token은 블록체인 아키텍처의 근본적인 구성 요소로서, 생태계 경제, 사용자 채택, 장기적 지속가능성에 영향을 미치는 전략적 선택입니다. 성공하려면 기술적 구현 세부사항과 경제적 함의를 모두 이해해야 합니다.
블록체인 인프라가 계속 성숙해짐에 따라 Custom Gas Token은 차별화 요소에서 표준 기능으로 전환될 것입니다. 승자는 사용자 경험을 최우선에 두고 신중한 토큰 경제 시스템을 설계하는 이들이 될 것입니다. 블록체인의 미래는 Custom Gas Token이 가능케 하는, 독자적인 통화 정책을 가진 생태계들을 점점 더 지향하고 있습니다.
Alchemy Rollups로 Custom Gas Token을 배포하거나 언제든 저희 팀에 문의하십시오. 도움을 드리겠습니다.
관련 개요
인프라2026년 9월 2일
온체인 AI 에이전트 아키텍처: 다섯 가지 빌드 패턴
온체인 AI 에이전트를 위한 다섯 가지 빌드 패턴과 각각의 예제: 지갑 감시자, 이벤트 기반 리액터, 포트폴리오 리밸런서, 감지 후 실행 방식의 멀티 에이전트 분할, 안전한 메인넷 이전 테스트.
인프라2026년 8월 21일
개발자를 위한 토큰화 주식 설명: xStocks, Dinari, Robinhood Chain의 작동 방식
개발자를 위한 토큰화 주식 설명: xStocks, Dinari dShares, Robinhood 주식 토큰을 뒷받침하는 것, 각각의 온체인 작동 방식, 그리고 주의할 점.
인프라2026년 8월 20일
AI 코딩 에이전트가 블록체인 인프라를 선택하는 방식
AI 코딩 에이전트는 작성하는 코드에서 RPC 제공자를 직접 선택합니다. Cursor, Replit, Claude Code가 블록체인 인프라를 선택하는 방식과 이를 유도하는 방법을 알아봅니다.

블록체인 매직을 만드세요
Alchemy는 가장 강력한 Web3 개발자 제품 및 도구를 리소스, 커뮤니티, 그리고 전설적인 지원과 결합합니다.