ERC-20 vs ERC-721: 잔액 모델과 소유권 모델은 무엇이 다른가
잔액 기반 ERC-20과 토큰ID 기반 ERC-721의 데이터 모델·권한 위임·전송 안전성 차이를 mint·transfer·burn 절차로 비교한다
2026-08-12 · 최초 발행 2025-12-09
이더리움에서 "토큰"이라고 부르는 것들은 사실 서로 다른 데이터 모델 위에 서 있다. ERC-20은 주소마다 잔액을 들고 있는 장부이고, ERC-721은 토큰ID마다 소유자를 매핑해두는 등기부다. 이 차이 하나가 권한 위임 방식, 전송 안전성, 메타데이터 구조, 심지어 이벤트 로깅 방식까지 갈라놓는다. 대체 가능성(Fungibility)과 고유성(Non-Fungibility)에 따라 두 표준이 실무에서 어떻게 갈리는지를 mint·transfer·burn 절차 중심으로 짚는다.
잔액을 옮기는가, 소유자를 바꾸는가
ERC-20은 이더리움의 대체 가능 토큰(Fungible Token) 사양이다. 잔액 기반 수량 모델(balance model)로 상태를 관리하고 transfer/approve/transferFrom 인터페이스를 제공한다. 주소별 잔액과 총발행량(totalSupply)이 핵심 상태이고, 이 둘이 항상 일치해야 수량 보존성이 지켜진다.
ERC-721은 대체 불가능 토큰(Non-Fungible Token) 사양이다. 토큰ID 기반 소유권 모델(ownerOf, tokenId)을 쓰고 안전 전송(safeTransferFrom), 개별 승인·운영자 승인(approve/setApprovalForAll)을 제공한다. 각 토큰ID의 유일성과 소유자 매핑이 핵심이라, 같은 수량이라도 서로 교환할 수 없는 개별 자산 취급을 받는다.
이 차이는 곧바로 속성 관리로 이어진다. ERC-20은 동일 수량이 완전히 교환 가능하다는 전제 위에서 잔액 맵과 allowance로 상태를 관리하면 끝이지만, ERC-721은 각 토큰ID가 고유 자산이라 ownerOf·tokenURI 같은 개별 메타데이터 연계가 따라붙는다. 메타데이터 확장 사양도 갈린다. ERC-20은 이름·심볼·소수점, EIP-2612 Permit 정도로 단일 메타데이터에 초점을 맞추는 반면 ERC-721은 ERC-721 Metadata·Enumerable 확장으로 토큰별 URI와 인덱싱을 지원해 갤러리·마켓 연동에 유리하다.
위임하는 방식이 다르면 쓰이는 곳도 갈린다
ERC-20의 권한 위임은 approve/allowance로 특정 스펜더에게 한도를 넘겨주는 방식이라 DeFi 프로토콜과의 호환성이 높다. ERC-721은 토큰 단위 approve와 컬렉션 전체에 대한 setApprovalForAll을 함께 제공해서 마켓플레이스 거래 흐름에 맞춰져 있다.
전송 안전성에서는 더 뚜렷하게 갈린다. ERC-20의 transfer/transferFrom은 수신 컨트랙트가 이 토큰을 받을 준비가 됐는지 확인하는 절차가 표준에 없다. 반면 ERC-721의 safeTransferFrom은 수신 컨트랙트가 onERC721Received를 구현했는지 검증해서 잘못된 전송을 막는다. 이벤트 로깅도 공통으로는 Transfer/Approval을 쓰지만, ERC-20은 수량(amount) 중심으로, ERC-721은 토큰ID(tokenId) 중심으로 기록된다는 점이 다르다.
Mint·Transfer·Burn, 같은 이름 다른 절차
ERC-20의 발행은 주소와 발행량을 입력받아 검증 후 수신 주소 잔액과 총발행량을 함께 늘리고 Transfer(address(0), to, amount) 이벤트를 남긴다. ERC-721의 발행은 받는 주소와 토큰ID를 입력받아 권한을 검증하고 토큰ID의 고유성을 확인한 뒤 소유자 매핑을 설정하고 Transfer(address(0), to, tokenId)를 기록한다.
전송에서는 ERC-20이 보내는/받는 주소와 수량을 입력받아 잔액을 검증한 뒤 직접 전송하거나 위임 전송이면 allowance를 확인·차감하고 잔액을 옮긴다. ERC-721은 보내는/받는 주소와 토큰ID를 입력받아 owner·approved·operator 중 어떤 권한으로 요청됐는지 처리한 뒤 ownerOf[tokenId]=to로 소유자를 바꾸고, safeTransfer라면 수신 컨트랙트 콜백까지 검증한다.
소각에서는 ERC-20이 주소와 소각량을 검증해 잔액과 총발행량을 함께 줄이고 Transfer(from, address(0), amount)를 남긴다. ERC-721은 토큰ID를 입력받아 권한을 처리한 뒤 소유자 정보를 삭제하고 해당 토큰ID를 소각하며 Transfer(owner, address(0), tokenId)를 기록한다. 두 표준 모두 각 함수 호출은 원자적으로 실행되어 중간에 실패하면 전체가 revert되고, ERC-721의 safeTransferFrom은 수신 컨트랙트 콜백 검증으로 잘못된 락인을 막으며 재진입 방지에는 체크-이펙트-인터랙션 패턴이 권장된다.
지표로 정리하면
| 항목 | ERC-20 | ERC-721 |
|---|---|---|
| 성능 | 전송 가스비 낮음, 페이먼트·대량 전송 유리(네트워크·구현별 편차 존재) | 추가 검증(safeTransfer)으로 가스비 상대적으로 높음 |
| 확장성 | 잔액 합산 구조로 집계·정산 용이, 배치 처리 간단 | 토큰ID 단위 처리, 대량 이전 시 루프·배치 설계 필요 |
| 일관성 | 수량 보존성 명확, 소수점 지원 | 고유성·희소성 보장, 메타데이터 무결성 중요 |
| 안정성 | 수신 컨트랙트 호환성 검증 부재 → 운영 가이드 필요 | safeTransfer로 수신 검증, 오발송 리스크 감소 |
| 운영 편의 | 지갑·거래소·DeFi 광범위 지원, 툴링 성숙 | 마켓플레이스·컬렉션 툴 강점, 인덱싱 요구 높음 |
무엇을 고를 것인가
ERC-20은 결제·포인트·유틸리티 토큰, 유동성 지분(LP 토큰)·보상 분배·거버넌스 투표권 같은 금융 파생·DeFi 영역에 쓰인다. ERC-721은 아트워크·컬렉터블·게임 아이템 같은 디지털 자산과, 소유권 증빙·접근 권한 토큰화·출입권 관리 같은 실물 연계(RWA)·티켓팅·신원 증명에 맞는다. 둘을 섞는 설계도 흔하다 — ERC-721 멤버십 보유자에게 ERC-20 보상을 에어드랍하거나 스테이킹 보상을 지급하는 식으로, ERC-20의 보상 체계와 ERC-721의 자산 소유권을 결합한다.
선택 기준은 결국 단순하다. 동일 가치의 수량 이전과 정산이 중심이면 ERC-20을, 고유 자산의 소유권과 메타데이터 관리가 핵심이면 ERC-721을 채택한다. 어느 쪽을 고르든 권한·위임 메커니즘(approve/allowance vs setApprovalForAll) 테스트를 강화하고, 이벤트 기반 인덱싱과 revert·콜백 실패에 대한 에러 핸들링을 정교하게 설계하며, 체크-이펙트-인터랙션·재진입 방지·안전 전송 패턴 같은 보안 모범사례를 지켜야 한다는 원칙은 같다.