Road to Web3 (8) 가스비의 실체: 가스 사용량 곱하기 가스 가격

이 글은 Ethereum 및 EVM 계열을 기준으로 설명합니다.

 

이번 편의 목표는 두 가지입니다.

• 가스비가 무엇을 계산하는 비용인지
• 왜 실패하는 트랜잭션도 비용이 드는지

 

제가 처음 가스비를 접할 때 했던 오해는 이렇습니다.

• 가스비는 수수료라는 이름의 별도 요금이다
• 실패하면 아무 일도 안 했으니 비용도 안 든다
• 가스비는 누가 마음대로 정한다

하지만 EVM에서 가스비는 훨씬 단순합니다.

• 가스는 연산과 저장 같은 실행 자원의 단위
• 가스비는 그 자원을 네트워크에서 빌려 쓰는 비용
• 실패해도 연산을 했다면 그 연산 비용은 이미 발생

한 줄로 잡으면 이렇습니다.

가스비 = 가스 사용량 곱하기 가스 가격

---

요약

항목	의미	실무 감각
gasLimit	최대 허용 연산량 상한	카드 결제의 한도처럼 상한선
gasUsed	실제로 쓴 연산량	실제 청구량
gasPrice	단위 가스 가격	네트워크 혼잡에 따라 변함
EIP-1559	baseFee + tip 모델	사용자가 지불 상한을 제시
실패 비용	연산은 했으니 지불	out of gas 는 최악 패턴

---

1) 가스는 무엇인가

가스는 EVM이 실행하는 작업의 비용을 계량화한 단위입니다.

• 연산 opcode 실행
• 스토리지 쓰기 SSTORE
• 로그 이벤트 emit
• 메모리 확장
• 컨트랙트 생성

이 모든 것은 노드가 CPU와 메모리와 디스크 I/O를 쓰는 행위입니다.
그래서 네트워크는 실행 자원 소비를 가스로 환산하고, 그만큼 비용을 청구합니다.

---

2) 가스비는 어떻게 계산되나

기본식은 변하지 않습니다.

• 비용 = gasUsed 곱하기 unitPrice

다만 EIP-1559 이후에는 unitPrice 가 하나의 값이 아니라 두 조각으로 나뉩니다.

• baseFeePerGas: 네트워크가 요구하는 최소 단가
• priorityFeePerGas: 내가 더 빨리 포함되길 원할 때 주는 팁
• maxFeePerGas: 내가 지불할 수 있는 단가 상한

EIP-1559 감각으로 정리

블록에 실제로 적용되는 단가는 보통 이렇게 생각하면 됩니다.

• effectiveGasPrice = min(maxFeePerGas, baseFeePerGas + priorityFeePerGas)

그리고 실제 비용은

• txFee = gasUsed 곱하기 effectiveGasPrice

여기서 baseFee 부분은 소각되고, priorityFee 부분은 블록 제안자 측으로 흘러갑니다.
실무적으로 중요한 건 소각 여부보다, 사용자가 상한을 제시한다는 점입니다.

---

3) 왜 실패가 돈이 드나

실패는 두 가지로 나뉩니다.

A. revert 기반 실패

컨트랙트 코드가 조건을 확인하고 되돌리는 경우입니다.

• require 조건 실패
• revert 호출
• assert 실패

이 경우 상태 변경은 롤백됩니다.
하지만 롤백은 공짜가 아닙니다. 조건을 확인하기 위해 이미 연산을 했고, 그 연산은 네트워크 자원을 소비했습니다.
그래서 소비된 가스만큼은 지불합니다.

다만 일부는 환급이 있고, 어떤 저장 작업이 실제로 반영되지 않으면 그 비용이 줄어드는 효과도 있습니다.
하지만 서비스 운영 감각에서는 이걸 세밀하게 기대하면 안 되고, 실패도 비용이라는 전제를 두는 편이 안전합니다.

B. out of gas 기반 실패

gasLimit 을 너무 낮게 줘서 실행 중에 가스가 바닥나는 경우입니다.

• 상태 변경은 롤백
• 남은 가스가 없으므로 복구 로직도 못 돈다
• 이미 쓴 가스는 지불

이 패턴이 최악인 이유는 실패했는데도 거의 전액에 가까운 비용이 나갈 수 있기 때문입니다.

---

4) 누가 수수료를 정하나

이 질문을 web2로 번역하면 이런 느낌입니다.

• 결제 수수료를 누가 정하나
• 네트워크 혼잡에 따라 빠른 처리를 위해 추가 요금을 낼 수 있나

EVM에서는

• baseFee 는 프로토콜 규칙으로 블록 단위로 조정됩니다
• priorityFee 와 maxFee 는 사용자가 제시합니다
• 블록 제안자와 빌더는 수익이 더 좋은 트랜잭션을 우선 포함할 유인이 있습니다

즉, 수수료는 한 주체가 고정 가격표를 내는 것이 아니라

• 프로토콜의 최저 단가
• 사용자 제시 가격
• 블록 공간 경매에 가까운 선택

이 합성 결과입니다.

---

5) gasLimit 은 한도이자 보호 장치다

gasLimit 은 사용자가 지불할 의사가 있는 최대 연산량 상한입니다.

• 너무 높게 잡으면 악성 컨트랙트에 의해 비싼 실행을 허용할 위험이 늘고
• 너무 낮게 잡으면 out of gas 로 실패할 위험이 늘고

실무에서는 보통

• estimateGas 로 예측하고
• 여유 버퍼를 조금 붙이고
• 실패하면 재시도하거나 사용자에게 재승인을 받는

패턴으로 갑니다.

---

6) web2 결제 비유

가스비를 결제 시스템으로 비유하면

• gasUsed: 실제로 수행된 작업량
• gasPrice: 혼잡 시간대의 처리 단가
• priorityFee: 빠른 처리 요청 수수료
• gasLimit: 이 이상은 결제하지 않겠다는 상한

그리고 실패 비용은 이런 상황과 닮았습니다.

• 카드 승인 과정에서 승인 실패가 나도, 가맹점 또는 PG 측 비용이 0이 아닌 경우
• 외부 API 호출이 실패해도 인프라 비용과 시도 비용이 드는 경우

블록체인은 이 비용을 프로토콜 차원에서 사용자가 지불하도록 노출합니다.
그래서 왜 실패가 돈이 되나라는 질문은, 왜 실패한 실행에도 인프라 비용이 드나로 번역됩니다.

---

7) 체크리스트

1) 포함 정책과 확정 정책을 먼저 정의한다 included confirmed finalized
2) 실패 비용을 정상 비용으로 취급하고 제품 UX 를 설계한다
3) out of gas 실패를 최우선으로 줄인다 estimateGas 와 버퍼
4) maxFeePerGas 와 priorityFeePerGas 를 분리해서 설정한다
5) 혼잡 시에는 수수료 자동 조정 또는 재시도 정책을 둔다
6) 토큰 전송이라도 네이티브 코인으로 수수료를 낸다는 점을 사용자에게 노출한다
7) 시뮬레이션 eth_call 로 실패 이유를 사전 탐지할 수 있는 곳은 탐지한다
8) 컨트랙트 호출은 상태에 따라 가스가 달라진다는 점을 전제로 한다
9) 이벤트와 영수증으로 실제 gasUsed 와 effectiveGasPrice 를 기록한다
10) 결제 시스템처럼 상태 머신으로 처리하고 idempotency key 로 중복 처리를 막는다

---

결론

• 가스비는 실행 자원의 비용이고, 가스 사용량 곱하기 가스 가격으로 계산된다
• 실패해도 연산을 했다면 비용이 든다
• out of gas 는 실패 비용이 커질 수 있어 운영상 위험하다
• 수수료는 프로토콜 규칙과 사용자 제시 가격이 합성되는 시장형 구조다