토큰 표준(ERC-20 등) — 토큰은 어떻게 규격화되는가?
서두 — 표준의 필요성
블록체인 생태계에는 수많은 토큰이 공존한다. 각기 다른 프로젝트의 토큰이 지갑에 안전하게 보관되고, 거래소와 DApp에서 문제없이 작동하려면 공통된 인터페이스가 필수다. 토큰 표준은 호환성, 개발 효율성, 보안 관행을 제공해 생태계 확장을 돕는다. 표준 덕분에 월렛 개발자·거래소·스마트컨트랙트 개발자가 동일한 규칙으로 토큰을 처리할 수 있다.
주요 토큰 표준 및 비교
- ERC-20 (이더리움): 대체 가능(fungible) 토큰 표준. 대부분의 스테이블코인, 유틸리티 토큰, 거버넌스 토큰(일부 제외)이 채택. ERC-20은 잔액·전송·승인 관련 기본 함수와 이벤트를 정의해 모든 서비스가 토큰 흐름을 신뢰성 있게 추적할 수 있게 한다.
- ERC-721: 비대체(non-fungible) 표준. 각 토큰에 고유 ID가 있어 디지털 아트, 소유권 증명, 게임 아이템 등에 적합. ERC-721은 소유권 이전 로직과 토큰별 메타데이터 표준을 정의한다.
- ERC-1155: 멀티토큰 표준. 동일 계약에서 대체 가능·비대체 토큰을 동시에 다룰 수 있어 게임·마켓플레이스에서 가스비·스토리지 효율이 높다. 배치 전송(batch transfer)을 지원한다.
- BEP-20: 바이낸스 스마트 체인(BSC) 표준. ERC-20과 유사하지만 BSC 환경 및 생태계 툴과의 호환성에 맞춰 사용된다.
ERC-20의 내부 동작과 실무 이해
핵심 함수와 이벤트는 이미 설명한 대로지만, 실제로 어떻게 상호작용하는지 몇 가지 시나리오로 보면 이해하기 쉽다.
- 일반 전송: Alice가 Bob에게 transfer()를 호출하면 블록체인에 Transfer 이벤트가 남고, 월렛은 이를 읽어 잔액을 업데이트한다.
- 허가와 대리이체: Alice가 DEX에 토큰을 예치하려면 먼저 approve(DEX, amount)를 호출해 DEX가 transferFrom으로 토큰을 이동시키도록 허용해야 한다. 이 패턴 때문에 approve/transferFrom 로직은 자동화된 거래에서 매우 중요하다.
- 실패 처리: ERC-20 표준은 함수가 성공 여부를 bool로 반환하도록 권장하지만 일부 오래된 토큰은 반환값을 누락하거나 예외를 던지지 않는 구현이 있어 자동화된 계약과 충돌할 수 있다(예: transfer가 실패해도 트랜잭션은 성공으로 처리되는 경우). 이런 변종 때문에 스마트컨트랙트 개발자는 안전 래퍼(library)를 사용해 호환성 문제를 해결한다(OpenZeppelin의 SafeERC20 등).
보안·설계 취약점과 실제 사례
- approve 레이스 컨디션: 기존 승인량을 0으로 먼저 바꾸지 않고 새로운 승인량을 덮어쓸 경우 공격자가 중간에 transferFrom을 수행해 토큰을 빼갈 수 있다. 이를 막기 위해 approve를 변경할 때 0으로 초기화하거나 increaseAllowance/decreaseAllowance 같은 안전 함수를 사용한다.
- 멀티 신뢰(Owner) 위험: 토큰 컨트랙트에 관리자 권한(민팅·소각·블랙리스트)이 과도하게 집중되어 있으면 팀의 권한 남용 또는 해킹 시 대규모 발행·동결이 가능하다. 소유권 포기(renounceOwnership)나 시간 지연(Timelock)으로 리스크를 완화할 수 있다.
- 미검증 코드 배포: 소스가 검증되지 않은 컨트랙트는 내부에 악성 로직(예: 백도어 민팅)을 숨길 수 있으므로 Etherscan의 Verified 소스와 외부 보안감사 보고서가 매우 중요하다.
실무 체크리스트(투자자/개발자용 확장판)
- 컨트랙트 주소로 검증: 심볼·이름은 위조 가능. 반드시 컨트랙트 주소와 프로젝트 공식 채널(웹사이트·트위터·깃허브) 기입 주소가 일치하는지 확인.
- 소스 코드 검증(Verified): Etherscan의 Verified 여부와 컴파일러 버전, 최적화 옵션까지 확인.
- 감사(Audit) 보고서 확인: 취약점 고정·수정 기록과 중요도(Critical/High/Medium/Low) 항목 확인.
- 토큰 경제(Tokenomics): 총공급량, 팀/프라이빗 할당 락업(lockup) 기간, 민팅/소각 정책 등을 검토. 불투명한 공급 조정은 시세 조작 위험.
- 권한 분산: Owner·Minter 권한이 누구에게 있는지, 다중서명(Multi-sig) 또는 거버넌스 계약으로 관리되는지 점검.
- 이벤트 및 표준 준수: Transfer·Approval 이벤트 발생 여부, ERC-20 표준 함수의 정상 동작 여부 테스트(소량 전송 실험).
- 호환성 테스트: 지갑(메타마스크), DEX(유니스왑), 브리지 등 주요 서비스에서 정상 동작하는지 확인.
- 토큰 심볼 충돌과 피싱: 유명 토큰과 유사한 심볼(예: USDTt)로 사기성 토큰을 만들 수 있으니 주소 직접 확인 권장.
- 가스·승인 UX: approve 반복 문제를 피하기 위해 permit(EIP-2612) 같은 서명 기반 승인 기능을 지원하는지 확인하면 UX·보안 개선.
- 커뮤니티·거래량·유동성: 거래량이 얕으면 큰 주문으로 가격이 쉽게 변동. 유동성 풀의 커버리지와 보유자 분포(whale concentration)도 확인.
개발 관점의 베스트 프랙티스
- OpenZeppelin 라이브러리 사용: 표준 구현·검증된 코드를 재사용해 보안 리스크 감소.
- 테스트 커버리지: 단위테스트·통합테스트로 transfer/approve 경로를 모두 검증.
- 업그레이드 패턴 주의: 프록시 패턴은 편리하지만 스토리지 충돌·관리권 문제를 야기할 수 있으므로 신중한 설계와 투명한 거버넌스 필요.
- 자동화된 보안 도구: 슬로프(슬루프?) 등 정적 분석 도구와 펑크스캔, 포맷 검증을 통한 배포 전 검사 권장.
자주 묻는 질문(FAQ) — 빠른 답변
Q. 토큰 심볼이 같으면 같은 토큰인가?
A. 아니오. 심볼은 중복 가능. 반드시 컨트랙트 주소로 식별해야 한다.
Q. ERC-20과 ERC-777 차이는?
A. ERC-777은 더 진보된 인터페이스와 수신자 후킹(hooks)을 제공하지만 복잡성과 호환성 문제가 있어 아직 보편화되지 않았다.
Q. 토큰이 transfer 실패했는데 가스만 소비되면 어떻게 하나?
A. 토큰 구현 방식 때문에 실패를 boolean으로 반환만 하고 revert를 하지 않는 경우가 있다. 안전 래퍼(SafeERC20)로 호출하거나 소량으로 먼저 테스트 전송을 권장한다.
결론 — 표준 준수는 신뢰의 시작
토큰 표준은 단순한 규격이 아니라 블록체인 상호운용성과 신뢰를 만드는 기반이다. 투자자는 표준 준수·컨트랙트 검증·감사 여부를 통해 리스크를 낮출 수 있고, 개발자는 표준을 따르면 사용자 경험과 에코시스템 통합이 쉬워진다. 다음 글에서는 스마트컨트랙트 배포 기본(로컬 환경 세팅, 컴파일, 배포, 가스비 최적화, 간단한 ERC-20 배포 예제)을 단계별로 다룹니다.
댓글
댓글 쓰기