ERC는 “Ethereum Request for Comment”의 약자로, 이더리움 생태계에서 스마트컨트랙트·토큰·지갑 같은 애플리케이션이 따를 표준 규약을 의미하며, 개발자들이 참고하는 일종의 공개 기술 명세서입니다. 인터넷 세계에서 RFC(Request for Comments)가 프로토콜 표준을 논의·정리하는 문서였던 것처럼, ERC는 이더리움에서 “이 기능을 이렇게 구현하자”는 합의를 담은 문서이고, 합의가 널리 받아들여지면 사실상의 표준이 됩니다.tech-talks.tistory+6
1. ERC의 기본 개념과 역할
ERC는 문자 그대로 번역하면 “이더리움에 대한 의견 요청”인데, 실제로는 개발자들이 새로운 기능이나 인터페이스를 제안하고, 커뮤니티가 이를 검토해 표준으로 채택하는 과정 전체를 담는 문서 형식입니다. 이 문서에는 특정 기능이 어떤 목적을 가지는지, 어떤 함수와 이벤트, 상태 변수가 필요한지, 구현 시 지켜야 할 규칙과 예외 처리는 무엇인지 같은 기술 스펙이 상세히 정의됩니다.log4day.tistory+5
ERC가 중요한 이유는, 이더리움 생태계가 탈중앙화돼 있어도 공통 언어가 없으면 지갑·거래소·DApp마다 서로 다른 방식으로 토큰·NFT·계약을 처리하게 되고, 사용성과 상호운용성이 크게 떨어지기 때문입니다. 예를 들어 A 프로젝트는 전송 함수를 send()로, B 프로젝트는 transferToken()으로 제각각 정의하면, 지갑 입장에서는 각각에 맞는 커스텀 코드를 따로 구현해야 해 비용과 복잡도가 폭증합니다. ERC는 이런 문제를 피하기 위해 “토큰은 transfer, approve, balanceOf 같은 함수 시그니처를 반드시 제공해야 한다”는 식으로 인터페이스를 표준화해, 누구나 그 규격만 따르면 어디서든 돌아가는 컴포저블한 모듈을 만들 수 있게 합니다.insengnewbie.tistory+4
개념적으로 ERC는 “문서”이지만, 현실에서는 그 문서에 번호를 붙인 이름 자체가 곧 표준처럼 쓰입니다. 그래서 사람들은 “ERC-20 토큰”, “ERC-721 NFT”라고 부를 때, 해당 번호의 문서에서 정의한 인터페이스를 이행하는 스마트컨트랙트를 가리키는 셈입니다.naver+6
2. ERC와 EIP의 관계
ERC를 이해할 때 빼놓을 수 없는 개념이 EIP(Ethereum Improvement Proposal)입니다. EIP는 이더리움 프로토콜 전체에 대한 개선 제안 문서로, 합의 알고리즘, 수수료 메커니즘, 네트워크 구조, EVM 동작 방식 등 저수준 프로토콜 레벨까지 모두 포괄하는 상위 개념입니다. 예를 들어 트랜잭션 수수료 구조를 바꾼 EIP-1559처럼, 체인 자체의 작동 원리를 바꾸는 내용도 모두 EIP의 형식을 따릅니다.velog+3
ERC는 이 EIP의 부분집합 혹은 하위 카테고리로, 주로 스마트컨트랙트 인터페이스·토큰 표준·지갑 포맷·이름 레지스트리 등 애플리케이션 층(Interface 계층)에 속하는 제안에 붙는 이름입니다. 쉽게 말해 “이더리움 네트워크 자체를 어떻게 바꿀까?”라는 질문은 EIP의 영역이고, “이더리움 위에서 토큰/앱을 어떻게 만들면 서로 잘 통할까?”라는 질문은 ERC의 영역인 셈입니다.naver+3
실무 흐름은 대략 다음과 같습니다.github+3
- 개발자가 새로운 토큰/애플리케이션 표준 아이디어를 문서화해 EIP 형식으로 제출합니다.
- 이 제안이 스마트컨트랙트 인터페이스·토큰 규격에 관한 것이라면, ERC 번호가 붙어 “ERC-XX” 형태로 불립니다.tech-talks.tistory+2
- 커뮤니티 리뷰와 수정, 테스트를 거친 뒤 널리 채택되면 사실상의 표준(디팩토 스탠더드)이 됩니다.insengnewbie.tistory+3
이 때문에 “EIP가 없는 ERC는 없다”고 정리하는 글도 있을 정도로, 두 개념은 절차적으로 긴밀하게 묶여 있습니다. GitHub의 ethereum/ERCs 저장소를 보면 이런 ERC 제안 문서들이 모여 있는 것을 확인할 수 있고, 개발자들은 여기서 최신 표준의 상태와 논의 과정을 추적합니다.velog+4
3. 대표적인 ERC 표준과 특징
ERC에는 수백 개의 번호가 존재하지만, 실제 생태계에서 가장 널리 알려진 것은 몇 가지입니다.proprogrammer.tistory+3
가장 대표적인 것이 ERC-20으로, 이더리움 블록체인에서 사용되는 **대체 가능 토큰(fungible token)**에 대한 표준입니다. ERC-20은 totalSupply, balanceOf, transfer, approve, transferFrom, allowance 등의 함수와 Transfer, Approval 이벤트를 요구하며, 이를 통해 토큰 발행·전송·위임 전송·잔고 조회 같은 기본 동작이 지갑·거래소·DApp에서 일관되게 처리됩니다. 오늘날 스테이블코인, 유틸리티 토큰, 거버넌스 토큰 상당수가 이 규격을 따르고 있기 때문에, ERC-20은 사실상 “이더리움 토큰의 기본 언어”라고 할 수 있습니다.upbitcare+4
ERC-721은 대체 불가능 토큰(Non‑Fungible Token), 즉 NFT를 정의하는 표준입니다. ERC-20이 “1 토큰과 다른 1 토큰이 완전히 동일하지”를 전제로 한다면, ERC-721은 각 토큰 ID가 고유한 메타데이터와 속성을 갖도록 설계돼 하나의 스마트컨트랙트 안에서 수많은 서로 다른 자산(그림, 캐릭터, 아이템 등)을 표현할 수 있습니다. 디지털 아트, PFP, 게임 아이템 등 대부분의 초기 NFT 프로젝트가 ERC-721을 채택하면서, 이 표준은 NFT 생태계의 기본 규격으로 자리 잡았습니다.naver+3
ERC-1155는 ERC-20과 ERC-721의 아이디어를 결합한 멀티 토큰(multi‑token) 표준입니다. 한 컨트랙트에서 여러 종류의 대체 가능·대체 불가능 토큰을 동시에 관리할 수 있도록 설계돼, 게임처럼 아이템 종류와 수량이 매우 많은 환경에서 가스 비용과 복잡도를 크게 줄여줍니다. 예를 들어 하나의 게임 컨트랙트 안에서 골드 코인(ERC-20 스타일), 고유 캐릭터(NFT), 소모형 아이템(부분적으로 대체 가능) 등을 모두 ERC-1155로 처리하면, 별도 컨트랙트를 여러 개 만들 필요 없이 하나의 표준 인터페이스로 일괄 관리할 수 있습니다.digitalstone.tistory+4
이 밖에도 인터페이스 검출용 ERC-165, 엔터프라이즈용 신원 표준 ERC-884 등 수많은 ERC가 있으며, 각각 특정 문제를 풀기 위해 정의된 기능적·법제도적 요구사항을 반영합니다. 중요한 것은 번호 자체보다, 해당 ERC 문서가 어떤 인터페이스·이벤트·행동 규칙을 정의하는지 이해하는 것입니다.naver+4
4. ERC가 만드는 상호운용성과 개발자 경험
ERC 표준의 가장 큰 효용은 **상호운용성(interoperability)**과 개발자 경험(DX) 향상입니다. ERC-20이 등장하기 전에는 각 프로젝트가 자기 방식대로 토큰을 구현했기 때문에, 거래소는 토큰마다 입출금 로직을 따로 작성해야 했고, 지갑도 토큰별로 커스텀 지원을 해야 했습니다. ERC-20이 보편화되면서 “이 인터페이스만 충족하면 어떤 토큰이든 동일한 방식으로 전송·조회가 가능하다”는 전제가 생겨, 거래소와 지갑은 토큰별 커스텀 코드 없이도 수백·수천 개의 토큰을 지원할 수 있게 됐습니다.byline+3
동일한 현상이 NFT 영역에서도 반복되었습니다. ERC-721 이전에는 각 DApp이 NFT를 각자 정의해, 마켓플레이스·지갑이 일일이 통합해야 했지만, ERC-721·ERC-1155가 나온 뒤로는 “NFT 지갑”이나 “NFT 마켓”이 표준 인터페이스만 지원하면 어떤 프로젝트의 NFT든 자동으로 인식·거래가 가능한 구조로 바뀌었습니다. 이는 곧 네트워크 효과로 이어져, 새 프로젝트가 표준을 따르는 것만으로 기존 인프라 생태계 전체에 접속할 수 있게 만들었습니다.academy.gopax+5
개발자 입장에서도 ERC는 “사전에 합의된 모범 답안” 역할을 하며, 프로젝트 초기 설계 단계에서 큰 비용을 줄여 줍니다. 예를 들어 새로 토큰을 설계할 때, 수많은 엣지 케이스를 일일이 발명할 필요 없이 ERC-20 또는 그 파생 표준을 따라가면, 이미 검증된 인터페이스와 호환성을 자동으로 확보할 수 있습니다. 또한 OpenZeppelin 같은 라이브러리는 ERC 표준을 구현한 안전한 컨트랙트 템플릿을 제공해, 개발자가 몇 줄의 코드만 추가하면 전체 토큰 로직을 빠르게 구성할 수 있도록 돕습니다.velog+5
이처럼 ERC는 기술적으로는 “스펙 문서”에 불과하지만, 경제적·생태계적 관점에서는 다양한 프로젝트와 서비스가 서로 연결되는 기반 규칙을 제공해, 이더리움 위에서 거대한 토큰화 경제와 DApp 생태계를 가능하게 한 핵심 메커니즘으로 평가됩니다.imioim+3
5. ERC의 한계와 진화 방향
물론 ERC가 만능은 아니며, 몇 가지 구조적인 한계도 논의됩니다. 첫째, 표준이 안정되기까지 시간이 걸리고, 이미 광범위하게 사용되는 표준(예: ERC-20)에 결함이나 비효율이 발견돼도, 하위호환성과 기존 인프라 때문에 근본적인 수정을 하기 어렵다는 문제가 있습니다. 이런 이유로 완전히 새로운 토큰 설계가 필요할 때는 기존 ERC를 확장하는 서브 표준이나, 전혀 다른 EIP/토큰 모델이 제안되기도 합니다.tech-talks.tistory+2
둘째, ERC는 인터페이스만 정의할 뿐, 구현의 품질·보안까지 보장하지는 않습니다. 즉, ERC-20을 따른다고 선언한 컨트랙트라도, 내부 구현이 취약하면 해킹이나 오동작이 발생할 수 있고, 표준을 부분적으로만 지키는 프로젝트도 존재합니다. 그래서 실제 현장에서는 ERC 준수 여부 외에도, 코드 감사(audit), 테스트 커버리지, 업그레이드 정책 등을 별도로 검토해야 합니다.upbitcare+2
이 한계를 보완하기 위해, 더 정교한 역할별 표준(예: 거버넌스, 수수료, 메타데이터 규격 등), 에이전트·신원·평판을 다루는 새로운 ERC류 표준, 그리고 L2·크로스체인을 고려한 확장형 규격 등이 계속 제안되고 있습니다. 표준의 범위도 단순 토큰을 넘어 지갑 포맷, ENS와 같은 이름 시스템, 패키지 포맷, 에이전트 레지스트리 등으로 넓어지면서, ERC는 점점 더 “이더리움 애플리케이션 계층 전체를 묶는 공통 언어”라는 성격을 강화하는 방향으로 진화하고 있습니다.naver+4