📈 확정된 ERC 142개 중 16개에 보안 고려 사항 절이 없어요 — ERC-20·721·1155가 그 안에 있어요

「이 토큰은 ERC-20 표준을 따릅니다.」 거래소 공지에서도 프로젝트 소개에서도 흔히 보는 문장이에요. 그런데 그 말이 정확히 무엇을 보증하는 문장인지를 따져 본 적은 드물어요. 표준을 따른다는 것은 안전하다는 뜻일까요, 아니면 함수 이름을 맞췄다는 뜻일까요.

저희는 8월에 이더리움 표준 문서 저장소가 두 개로 갈린 구조를 세어 본 적이 있어요. 그때는 문서의 머리말만 읽었고, 그 글 끝에 「본문 내용은 읽지 않았다」고 유보를 적어 뒀어요. 이번에는 그 유보를 갚는 회차예요. 같은 저장소를 다시 받아서 이번엔 본문을 열었어요.

기준으로 삼은 것은 남의 잣대가 아니라 이더리움이 스스로 적어 둔 규칙이에요. 표준 문서를 어떻게 쓰는지 정해 둔 문서가 EIP-1 인데, 거기에 이런 문장이 있어요.

EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.

보안 고려 사항 절이 빠진 제출은 반려되고, 그 절의 논의가 리뷰어가 보기에 충분하지 않으면 확정 상태로 올라갈 수 없다는 뜻이에요. 그래서 그대로 시험해 봤어요. 확정 도장이 찍힌 문서를 전부 열어서 그 절이 있는지 센 거예요.

답부터 적을게요. 확정 상태인 ERC 142개 중 16개에는 그 절이 어떤 제목 수준으로도 없었어요. 그리고 그 16개 안에 ERC-20 과 ERC-721 과 ERC-1155 가 들어 있어요. 조회 시각은 2026년 9월 17일 오전 10시 40분부터 오전 11시 15분까지(한국 시각)이고, 가격이나 전망은 다루지 않아요.

무엇을 어떻게 셌는지 먼저 밝혀요

렌더링된 웹 페이지가 아니라 저장소 원본 파일을 받아서 셌어요. ethereum/ERCs 저장소를 커밋 5fc191d6 시점으로 통째로 내려받았고(47,323,010바이트), 규칙 문서를 확인하려고 ethereum/EIPs 도 커밋 c99b1c82 시점으로 받았어요(45,766,602바이트). 압축을 푼 뒤 ERCS/erc-숫자.md 형태의 파일 615개를 모두 열었어요.

절이 있는지는 모든 수준의 제목을 뽑아서 판정했어요. 처음에는 ## 만 세다가 곧 버렸는데, ERC-55 와 ERC-137 과 ERC-181 과 ERC-190 이 절 제목을 # 으로 쓰고 있어서 ## 만 보면 「Specification 절도 없다」는 엉뚱한 결과가 나왔거든요. 그래서 # 부터 ###### 까지 전부 모아 제목 문자열에 security consideration 이 들어 있는지를 봤어요. 두 방식으로 각각 세어 본 뒤 결과가 같은 16개임을 확인했어요.

상태값 분포부터 적으면 이래요.

여기서 이 글이 보는 자리는 Final 142개예요. 나머지는 아직 확정이 아니거나 멈춘 제안이라 「확정본이 규칙을 지키는가」라는 질문의 대상이 아니에요.

확정본 142개 중 16개에 그 절이 없었어요

상태별로 나란히 놓으면 이렇게 나와요.

눈에 먼저 들어오는 것은 Draft 와 Review 가 0건이라는 점이에요. 지금 파이프라인에 들어오는 문서는 예외 없이 그 절을 달고 들어와요. 이 대목은 뒤에서 따로 다룰게요. 먼저 확정본 쪽을 보죠.

절이 없는 16개는 이래요.

이 목록을 지갑 쓰는 사람 눈으로 다시 읽어 보면 성격이 분명해져요. ERC-20 은 원화로 산 토큰 대부분이 따르는 규격이고, ERC-721 과 ERC-1155 는 NFT 규격이에요. ERC-55 는 주소를 대소문자 섞어 적어 오타를 잡아 주는 체크섬 규격이라 지갑에 주소를 붙여 넣을 때마다 쓰여요. ERC-191 은 지갑에서 서명 창이 떴을 때 그 메시지를 어떻게 감싸는지를 정한 규격이고, ERC-600 과 ERC-601 은 시드 문구에서 주소를 뽑는 지갑 파생 경로를 정한 문서예요.

즉 이 16개는 변방의 실험적 제안이 아니라 지갑이 매일 통과하는 길목이에요.

🔴 여기서 한 번 끊고 가야 할 게 있어요. 절이 없다는 것은 그 표준이 위험하다는 뜻이 아니에요. 저희가 잰 것은 문서의 형식이고, 코드 감사 결과가 아니에요. ERC-20 이나 ERC-721 의 구현이 안전한지 아닌지는 이 조사로 전혀 알 수 없어요. 이 글이 말하는 것은 딱 하나예요. 「확정됐다」는 표시가 「보안 논의를 거쳤다」는 표시와 같은 뜻이 아니라는 것이요.

규칙이 나중에 생겼어요 — 다만 그걸로 전부 설명되지는 않아요

왜 이런 일이 생겼는지는 규칙 문서의 이력을 열면 나와요. EIP-1 의 커밋을 오래된 순으로 세우고 각 시점의 파일에 그 문장이 있는지를 이분 탐색했더니, 처음 들어온 커밋이 나왔어요.

• 커밋 d318362e9e669e4133558b23a065bbe9bbb1dbd2
• committer date 2019년 12월 21일 02:04:06 UTC
• 메시지 Adding mandatory "Security Considerations" to EIP-1 (#1963)

그 커밋이 추가한 줄 가운데 지금 EIP-1 에 그대로 남아 있는 것이 위에 인용한 문장이에요(남지 않은 줄도 있는데, 그 이야기는 뒤에서 할게요). 그러니까 보안 고려 사항은 2019년 말에 새로 생긴 의무이고, 위의 16개는 전부 2015년 11월부터 2019년 3월 사이에 작성된 문서예요. 작성 시점에는 그런 요구 자체가 없었어요.

그런데 여기서 한 걸음 더 들어가면 이야기가 조금 달라져요. 문서가 만들어진 시점과 확정으로 올라간 시점은 다르거든요. 규칙은 확정 승격을 막는 조항이니, 물어야 할 것은 작성일이 아니라 승격일이에요. 그래서 16개 각각에 대해 EIPS/eip-번호.md 의 커밋을 전부 받아 상태값이 처음 Final 이 되는 커밋을 찾아봤어요.

시점을 확인한 12개 중 9개는 규칙보다 앞서 확정됐고, 3개는 규칙이 생긴 뒤에 확정됐어요. ERC-600 과 ERC-601 을 확정으로 옮긴 커밋의 메시지는 각각 「1년 넘게 손대지 않았으니 확정으로 옮긴다」와 「최종 검토 기간이 1년 넘게 지났으니 확정으로 옮긴다」예요. 즉 새 심사를 통과해서가 아니라 오래 방치돼서 옮겨진 쪽에 가까워요. 그리고 이 셋은 지금도 그 절 없이 확정 상태예요.

세 가지는 정확히 적어 둘게요.

첫째, ERC-137 과 ERC-162 와 ERC-181 과 ERC-190 은 정확한 날짜를 모릅니다. 이분 탐색이 멈춘 커밋은 2018년 3월 21일의 「프론트매터 키를 전부 소문자로」 커밋인데, 그 직전 파일은 키가 Status: 라 소문자만 읽던 첫 스크립트가 값을 못 읽었어요. 다시 읽으면 실제 승격은 그보다 앞이에요. 상한만 알고 있으니 날짜를 단정하지 않을게요.

둘째, ERC-820 과 ERC-1155 와 ERC-1167 과 ERC-1820 은 재지 못했어요. 깃허브 API 가 비인증 호출 한도 때문에 HTTP 403 을 돌려줘서 커밋 목록 자체를 받지 못했어요. 첫 실행 로그에는 「해당 경로에 커밋이 없다」처럼 보이는 줄이 찍혔는데, 응답 코드를 찍어 다시 확인하니 없는 게 아니라 묻지 못한 것이었어요. 그래서 이 넷은 「없다」가 아니라 「못 쟀다」로 적어요.

셋째, 중간에 한 번 크게 틀렸던 것도 적어 둘게요. 처음 짠 스크립트는 16개 전부에 대해 2023년 10월 25일 15시 11분 14초(UTC) 라는 똑같은 값을 냈어요. 열여섯 문서의 승격 시각이 초 단위까지 같을 리 없죠. 원인은 ERC 문서들이 2023년에 ethereum/ERCs 로 분리되면서 ethereum/EIPs 쪽 파일이 이사 안내 스텁으로 바뀐 것이었어요. 스크립트가 「EIPs 쪽 최신 상태가 Final 이 아니다」를 보고 ERCs 저장소로 넘어갔고, 거기서는 파일의 이력이 분리 커밋에서 시작하니 전부 그 날짜가 나온 거예요. 그 값은 승격일이 아니라 분리일이에요.

절이 있다고 내용이 있는 건 아니에요

이제 절이 있는 126개 쪽을 봐요. EIP-1 은 그냥 절이 있으면 된다고 하지 않고 리뷰어가 보기에 충분한 논의를 요구해요. 그래서 절 본문의 길이를 재 봤어요. 제목 줄을 빼고 공백을 정리한 뒤 센 글자 수예요.

제일 짧은 것은 ERC-5615 의 다섯 글자예요. 마침표까지 포함해서 None. 이 전부예요. 반대쪽 끝에는 8,641글자짜리 ERC-7893 이 있고, 126개의 중앙값은 569글자예요. 같은 이름의 절인데 편차가 1,700배가 넘어요.

그래서 실용적인 결론은 이렇게 돼요. 절의 유무는 신호로 쓰기에 너무 거칠어요. 어떤 표준을 검토한다면 목차에 그 항목이 있는지가 아니라 그 안에 무엇이 적혀 있는지를 열어 봐야 해요. 다섯 글자와 8,641글자가 같은 표시를 달고 있으니까요.

🔴 오해를 막기 위해 덧붙여요. None. 이라고 적은 것이 곧 부실이라는 뜻은 아니에요. 정말로 추가 위험이 없다고 판단해서 그렇게 적었을 수 있어요. 여기서 말하는 것은 그 판단의 옳고 그름이 아니라, 겉에서 보이는 표시로는 그 둘을 구분할 수 없다는 사실이에요.

그래서 이 규칙은 지금 작동하고 있나요

작동하고 있어요. 앞의 상태별 표를 다시 보면 Draft 221개와 Review 65개는 절 없음이 0건이에요. 지금 저장소로 들어오는 제안은 예외 없이 그 절을 달고 들어와요. 이 규칙이 새 문서에 대해서는 빈틈없이 걸리고 있다는 뜻이에요.

경계는 두 군데에 보여요. 하나는 Last Call 16개 중 딱 하나, ERC-1191 이에요. 주소 체크섬에 체인 아이디를 섞는 제안인데 최종 검토 단계까지 와 있으면서 그 절이 없어요. 다른 하나는 Stagnant 161개 중 68개예요. 정체 상태는 일정 기간 갱신이 없으면 자동으로 붙는 표시라, 규칙이 생기기 전에 들어와 그대로 멈춘 문서들이 여기에 쌓여 있어요. 확정본의 16개와 성격이 같은 무리예요.

그리고 저희 8월 글과 이어 붙일 수 있는 값이 하나 있어요. 그때 ERCs 저장소 파일은 612개였고 확정은 141개였는데, 이번에는 615개에 확정 142개예요. EIPs 쪽 확정 138개는 그대로라서 양쪽 합은 279개에서 280개가 됐어요. 3주 사이에 문서 셋이 늘고 확정 하나가 늘어난 셈이에요. 다만 이건 8월 스냅숏을 다시 받아 대조한 게 아니라 그때 저희가 적어 둔 값과 비교한 것이에요.

대문자 MUST 가 늘 같은 무게는 아니에요

표준 문서를 읽다 보면 MUST 나 SHOULD 가 대문자로 나와요. 인터넷 규격에서 이 대문자 낱말들은 RFC 2119 와 RFC 8174 가 뜻을 정해 둔 약속된 용어예요. 그런데 EIP-1 이 이걸 어떻게 다루는지 보면 뜻밖이에요.

EIPs are encouraged to follow RFC 2119 and RFC 8174 for terminology and to insert the following at the beginning of the Specification section

encouraged, 그러니까 권장이에요. 의무가 아니에요. 같은 절 끝에는 「Specification 절 바깥에서는 대문자 키워드를 쓰지 말라」는 문장도 붙어 있어요.

그래서 확정본 142개에 대해, 문서 안에 RFC 2119 나 RFC 8174 를 언급하는 문장이 있는지와 대문자 키워드를 실제로 쓰는지를 따로 셌어요. 코드 블록과 인라인 코드를 지운 산문 기준이에요.

선언 없이 대문자 키워드를 쓰는 25개 중에는 최근 것도 많아요.

ERC-4626 은 MUST 계열을 73회 쓰면서 그 낱말의 해석 기준을 문서 안에 적어 두지 않았어요. 반대로 ERC-721 과 ERC-1155 는 선언을 넣어 뒀어요. 같은 대문자가 문서마다 근거가 다른 셈이에요.

반대쪽 극단도 있어요. 대문자 키워드가 한 번도 나오지 않는 확정본이 25개인데, 여기에 지갑에서 승인 서명으로 자주 쓰이는 ERC-2612(Permit)와 인터페이스 탐지 규격인 ERC-165, 프록시 규격인 ERC-1167 이 들어 있어요. 이 문서들은 의무와 권장을 대문자로 구분하는 방식 자체를 쓰지 않고 서술형으로 적어 뒀어요.

이더리움 토큰 표준 원문은 실제로 뭐라고 적혀 있을까요

이왕 원문을 열었으니 ERC-20 에서 지갑 쓰는 사람에게 바로 닿는 문장 몇 개를 그대로 옮길게요. 통설로 도는 요약 말고 파일에 적힌 문장이에요.

첫째, 토큰 이름과 기호와 소수점은 선택 사항이에요.

name … OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present.

같은 문장이 symbol 과 decimals 에도 붙어 있어요. 즉 원문은 이 셋을 있으면 좋은 것으로 두고, 다른 계약이 그 값의 존재를 전제하면 안 된다고 못 박아요. 저희가 메인넷 토큰 399개에 소수점 자리를 직접 물어본 기록에서 자릿수가 한 값이 아니라 여덟 가지로 갈렸던 것도 이 구조와 이어져요. 표준이 18을 정한 적이 없어요.

둘째, 전송 실패를 예외가 아니라 값으로 돌려줄 수 있어요.

Callers MUST handle false from returns (bool success). Callers MUST NOT assume that false is never returned!

느낌표까지 원문 그대로예요. 그만큼 자주 어긋나는 자리라는 뜻이겠죠. 그런데 바로 아래 잔액 부족 시의 동작은 SHOULD throw, 즉 권장이에요. 의무와 권장이 한 화면 안에서 갈려요.

셋째, 승인 한도를 바꿀 때 먼저 0으로 내리라는 문장은 지갑 쪽 권장이에요.

clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value for the same spender.

주어가 clients, 그러니까 지갑이나 앱이에요. 그리고 바로 뒤에 「계약 자체가 이를 강제해서는 안 된다」는 문장이 붙어요. 승인 한도를 바꿀 때 지갑이 0으로 내리는 단계를 한 번 더 요구하는 걸 본 적 있다면, 그 동작의 근거가 여기예요. 계약이 막아 주는 게 아니라 지갑이 권장을 따르는 것이라서, 지갑에 따라 동작이 다를 수 있어요.

마지막으로, 규칙 문서 자신은 어떨까요

EIP-1 을 열어 보면 그 문서에도 보안 고려 사항 절이 없어요. 다만 이건 놀릴 일이 아니라 분류의 문제예요. EIP-1 은 type: Meta, status: Living 인 절차 문서라서 기술 제안과 성격이 달라요. 그래도 그 문서에 적힌 문장이 「All EIPs must contain a section」이라는 것은 사실이니, 문서 세계의 규칙도 사람이 쓰는 글이라 빈틈이 있다는 정도로 읽으면 될 것 같아요.

한 가지 더. EIP-1 은 두 저장소에 사본이 하나씩 있는데 두 파일은 바이트 단위로 같지 않아요(각각 34,612바이트와 35,989바이트). 이 글에서 인용한 두 문장은 양쪽 모두에 같은 문자열로 들어 있는 것을 확인하고 옮겼어요. 그리고 규칙 도입 커밋의 패치에는 「2019년 12월 4일에 보안 고려 사항 절이 도입됐다」는 변경 이력 줄도 함께 들어 있었는데, 지금 EIP-1 본문에는 그 줄이 없어요. 현재 History 절은 BIP-0001 과 PEP-0001 에서 유래했다는 내용만 담고 있어요. 그래서 이 글은 날짜를 EIP-1 본문이 아니라 커밋 시각으로 인용했어요.

이 조사가 하지 않은 것

• 코드를 보지 않았어요. 문서의 형식만 봤어요. 그러니 「절이 없다」를 「구현이 위험하다」로 옮기면 안 돼요.
• 절 유무는 제목 문자열 기준이에요. 절 제목 없이 본문에 보안 논의가 섞여 있으면 이 방식으로는 잡히지 않아요.
• RFC 2119 선언 판정도 문자열 기준이에요. 다른 표현으로 용어를 정의한 문서가 있을 수 있어요. 또 EIP-1 이 요구한 것은 Specification 절 첫머리에 넣으라는 것인데, 위치까지는 재지 않았어요.
• 네 문서의 확정 승격 시점은 못 쟀어요(ERC-820 · 1155 · 1167 · 1820). API 호출 한도 때문이에요.
• 상태값은 문서가 스스로 적은 값이에요. 실제로 얼마나 쓰이는지와는 무관해요.

정리

• 이더리움의 규칙 문서 EIP-1 은 보안 고려 사항 절 없이는 확정 상태로 갈 수 없다고 적어 뒀어요.
• 그런데 2026년 9월 17일 기준으로 확정 상태인 ERC 142개 중 16개에 그 절이 없어요. 그 안에 ERC-20 과 ERC-721 과 ERC-1155 와 ERC-55 와 ERC-191 이 들어 있어요.
• 그 규칙은 커밋 d318362e 로 2019년 12월 21일(UTC)에 생겼어요. 16개는 전부 그보다 먼저 작성된 문서예요.
• 다만 승격 시점을 확인한 12개 중 3개(ERC-600 · ERC-601 · ERC-191)는 규칙이 생긴 뒤에 확정됐어요. 넷은 API 한도로 재지 못했어요.
• 절이 있는 126개도 편차가 커요. 제일 짧은 것은 다섯 글자(None.)이고 중앙값은 569글자, 제일 긴 것은 8,641글자예요.
• 대문자 MUST 의 무게도 문서마다 달라요. 확정본 142개 중 50개는 RFC 2119 를 한 번도 언급하지 않고, 그중 25개는 그러면서 대문자 키워드를 써요. EIP-1 이 그 규격을 권장으로만 두고 있기 때문이에요.
• 그러니 번호만 보지 말고 상태값과 절 목록과 RFC 2119 선언 여부를 같이 보세요. 셋 다 문서 한 장 안에서 확인돼요.
• 마지막으로 다시 적어요. 이 글이 잰 것은 문서의 형식이지 코드의 안전성이 아니에요.

이 글은 매매 권유가 아닌 정보 제공 글입니다. 가상자산은 변동성이 크고 원금 손실 위험이 있으며, 투자 판단과 그 결과에 대한 책임은 본인에게 있습니다.