EIP-55 체크섬 주소: 대소문자 이더리움 주소가 검증하는 것

이더리움 주소의 영문 한 글자가 대문자인지 소문자인지에 따라 지갑이 오타를 경고할 수 있어요. 그렇다고 대소문자가 수신자의 신원을 증명하는 것은 아닙니다. **EIP-55 체크섬 주소(Checksum Address)**는 익숙한 0x 주소의 20바이트 값을 바꾸지 않고 오류 감지 신호를 더해요. 이 경계까지 이해해야 크립토 지갑 보안 절차에 제대로 활용할 수 있습니다.

EIP-55 체크섬 주소란 무엇인가요?

이더리움 주소는 보통 0x 뒤에 40개의 16진수 문자로 표시해요. 16진수의 영문 a부터 f는 대문자든 소문자든 같은 값이므로, 표기만 바뀌어도 기초 주소 값은 같습니다.

ERC-55(기존 명칭 EIP-55) 공식 명세는 원래 비어 있던 대소문자 차이에 검사용 비트를 담습니다. 올바른 체크섬 주소는 소문자 주소의 해시(Hash)에 따라 일부 영문을 대문자로 써요. 소프트웨어는 이 패턴을 다시 계산하고, 입력된 혼합 대소문자가 맞지 않으면 거부할 수 있습니다.

주소 자체에 가벼운 맞춤법 검사 무늬를 접어 넣는다고 생각해 보세요. 영문 대소문자가 계정을 바꾸지는 않아요. 대신 문자열이 예상한 모습으로 복사됐는지 판단할 추가 단서를 소프트웨어에 줍니다.

이 형식은 혼합 대소문자를 허용하는 기존 16진수 파서(Parser)와 호환되고 주소 길이도 늘리지 않아요. 최종 상태인 ERC-55 명세는 주소당 평균 약 15개의 체크 비트를 제공하고, 무작위 오타가 우연히 검사를 통과할 확률을 0.0247%로 제시합니다. 유용한 오류 감지 수치지만 절대적인 보증은 아니에요.

혼합 대소문자 패턴은 어떻게 계산할까요?

암호학자가 아니어도 흐름은 따라갈 수 있어요.

1. 0x 접두사를 떼고 40개의 16진수 문자를 모두 소문자로 바꿉니다.
2. 소문자 ASCII 문자열을 Keccak-256으로 해시해요.
3. 주소 문자를 처음부터 하나씩 확인합니다.
4. 숫자 0부터 9는 그대로 둬요.
5. 영문 a부터 f는 대응하는 해시 니블(Nibble)이 8 이상이면 대문자, 아니면 소문자로 씁니다.
6. 결과 앞에 0x를 다시 붙여요.

해시는 매번 똑같이 만들어지는 대문자 스텐실 역할을 합니다. 주소 문자 하나가 바뀌면 기대하는 패턴도 달라져요. 혼합 대소문자 입력이 새 패턴과 맞지 않으면 검증 라이브러리가 서명 전에 흐름을 멈출 수 있습니다.

ERC-55 페이지에는 참조 구현과 테스트 벡터(Test Vector)가 들어 있습니다. 실제 서비스에서는 알고리즘을 새로 작성하기보다 유지보수되는 라이브러리를 쓰고, 공식 테스트 벡터로 동작을 점검하는 편이 안전해요.

소문자·대문자·체크섬 주소의 차이

다음 표기들은 같은 20바이트 목적지를 가리킬 수 있습니다.

여기서 자주 생기는 오해가 있어요. 소문자 입력은 형식상 유효할 수 있지만, 입력 자체에는 EIP-55 대소문자 검사가 없습니다. 도구가 소문자 주소를 받은 뒤 체크섬 형태로 돌려줬다면 **정규화(Normalization)**한 거예요. 원본에 오타가 없었다고 증명한 것은 아닙니다.

현재 ethers v6 주소 문서의 getAddress는 소문자 입력에 체크섬을 붙이고, 유효한 체크섬 입력은 허용하며, 이미 혼합 대소문자인데 패턴이 틀리면 오류를 냅니다. 마지막 경우가 실제 검증 신호예요.

import { getAddress } from 'ethers';
 
const normalized = getAddress('0x8ba1f109551bd432803012645ac136ddd64dba72');
 
console.log(normalized);
// 0x8ba1f109551bD432803012645Ac136ddd64DBA72

틀린 혼합형 주소를 억지로 소문자로 바꿔 오류를 없애지 마세요. 경고의 원인을 확인하는 대신 안전장치를 우회하는 행동입니다.

개발자를 위한 더 안전한 검증 절차

주소 검증은 서로 다른 질문을 나눠서 답해야 해요. 하나의 참·거짓 값으로 모든 보안 판단을 끝내는 설계가 흔한 실수입니다.

1. 형식과 체크섬을 검증하세요

앱이 지원하는 형식에서 정확히 20바이트인지 확인해요. 사용자가 혼합 대소문자를 입력했다면 체크섬 불일치를 거부합니다. 검증된 입력은 이후 비교를 위해 하나의 표준 표시 형태로 정규화하세요.

viem의 getAddress 문서도 체크섬 주소를 반환한다고 설명해요. 체인을 반영하는 선택 기능도 있지만, 일반 EIP-55를 기대하는 앱이나 도구와 호환되지 않을 수 있다고 경고합니다.

2. 주소를 얻은 맥락을 보존하세요

연결된 지갑, 검증된 허용 목록(Allowlist), ENS 조회, 붙여넣은 텍스트, 거래 내역 중 어디에서 주소가 왔는지 구분하세요. 두 문자열을 정규화해 같은 주소임을 확인해도, 그 주소가 의도한 사람의 것인지는 증명되지 않습니다.

3. 네트워크는 따로 확인하세요

일반 EIP-55에는 체인 ID(Chain ID)가 들어 있지 않아요. 동일한 20바이트 문자열이 이더리움 메인넷과 여러 EVM 호환 네트워크에 존재할 수 있고, 잔액·코드·의미는 서로 다를 수 있습니다. 이더리움 공식 네트워크 문서도 한 계정을 여러 네트워크에서 쓸 수 있지만 잔액과 거래 내역은 따라가지 않는다고 설명해요.

ERC-1191은 체크섬 계산에 체인 ID를 더하는 방식을 제안합니다. 별도 제안이며 생태계 지원이 보편적이지 않아요. 일반 EIP-55 대소문자만 보고 네트워크를 판단하면 안 됩니다.

4. 결정하는 화면에서 목적지를 보여 주세요

인가 직전에 정규화한 주소, 선택 네트워크, 자산, 금액, 행동을 함께 표시하세요. 하드웨어 지갑이라면 신뢰하는 기기 화면도 대조합니다. 사용자가 확인할 수 없는 이름표 뒤에 실제 목적지를 숨기면 안 돼요.

5. 증거가 충돌하면 중단하세요

체크섬이 틀리거나, ENS 조회 결과가 예상과 다르거나, 네트워크가 바뀌거나, 서명 기기에 다른 목적지가 보이면 멈추세요. 가치가 이동하는 작업에서 '무시하고 계속'을 눈에 띄는 기본 경로로 두지 않는 편이 좋습니다.

EIP-55가 막을 수 없는 위험

체크섬은 우발적인 문자 변경 일부를 잡습니다. 신원 인증서나 안전 인증서가 아니에요.

• 주소 포이즈닝(Address Poisoning): 공격자는 자기 주소에도 완전히 유효한 체크섬을 만들 수 있어요. 화면에 줄여 보이는 앞뒤가 닮으면 여전히 속을 수 있습니다.
• 잘못된 수신자: 공격자의 주소를 정확히 복사했다면 체크섬도 정확해요.
• 잘못된 네트워크: 일반 EIP-55에는 메인넷, L2, 테스트넷 식별자가 없습니다.
• 오염된 출처: 악성코드는 클립보드 주소를 바꾸고 교체 주소의 유효한 체크섬까지 제공할 수 있어요.
• 위험한 컨트랙트: 체크섬은 컨트랙트 코드, 프록시 업그레이드, 권한, 토큰 동작을 검사하지 않습니다.
• 의도 실수: 네트워크는 서명된 목적지를 실행할 뿐, 사용자가 누구에게 보내려 했는지 알지 못해요.

그래서 주소 포이즈닝 대응 가이드는 독립적으로 검증한 출처와 전체 목적지를 대조하라고 권합니다. 체크섬은 이 절차를 강화하지만 대체하지 않아요.

송금 전 실전 체크 순서

새 목적지나 실수의 영향이 큰 송금에는 다음 순서를 적용해 보세요.

1. 최근 거래 내역이 아니라 독립적으로 신뢰하는 출처에서 주소를 가져옵니다.
2. 신뢰할 수 있는 지갑이나 라이브러리로 EIP-55 형식을 검증하고 표시해요.
3. 앞뒤 네 글자만 보지 말고 전체 주소를 비교합니다.
4. 수신자와 선택한 체인, 토큰을 따로 확인하세요.
5. 서명 기기에서 목적지, 금액, 네트워크를 다시 검증합니다.
6. 송금 성격에 맞다면 소액 테스트를 고려하고, 수신 확인 후 처음 검증한 같은 목적지를 사용해요.

트랜잭션 미리보기는 자산 이동과 컨트랙트 효과를 파악하는 데 도움이 되지만 다른 문제를 풀어요. 크립토 트랜잭션 시뮬레이션은 엉뚱한 사람에게 가는 송금도 정확히 미리 보여줄 수 있습니다. 신원과 의도는 별도로 검증해야 해요.

자주 묻는 질문(FAQ)

대소문자를 바꾸면 이더리움 주소가 바뀌나요?

아니요. 16진수 주소 값은 대소문자를 구분하지 않습니다. EIP-55는 같은 20바이트 값의 표시 계층에 검사 정보를 담아요.

모두 소문자인 이더리움 주소는 무효인가요?

아니요. 여러 라이브러리가 40자리 소문자 16진수 주소를 허용하고 EIP-55 형태로 변환합니다. 다만 소문자 입력 그 자체에는 혼합 대소문자 체크섬 신호가 없어요.

유효한 체크섬이면 안전한 주소인가요?

아니요. 대소문자 패턴과 주소 문자가 맞는다는 뜻입니다. 소유자, 네트워크, 컨트랙트, 웹사이트, 사용 목적을 인증하지 않아요.

EIP-55로 주소 포이즈닝을 막을 수 있나요?

단독으로는 어렵습니다. 유사 공격 주소도 유효한 체크섬을 가질 수 있어요. 신뢰하는 주소 출처를 쓰고, 모든 문자를 비교하고, 서명 기기에서 검증하며, 중요한 목적지는 두 번째 채널로 확인하세요.

앱은 체크섬 주소를 저장해야 하나요?

기초 주소 값을 일관된 방식으로 저장하고, 기술 스택이 지원하면 표준 체크섬 형태로 표시하세요. 동일성 비교는 정규화한 값으로 하고, 감사 기록에는 주소를 얻은 출처와 네트워크 맥락도 보존하는 편이 좋습니다.

체크섬을 하나의 보안 계층으로 사용하세요

EIP-55는 문자를 추가하지 않으면서 기존 이더리움 16진수 형식의 우발적 오류 감지 능력을 높입니다. 영리한 점이 곧 한계이기도 해요. 대소문자는 문자열을 검사하지만 누가 통제하는지, 어느 네트워크에서 써야 하는지는 알려주지 않습니다.

혼합 대소문자 입력을 검증하고, 출처 맥락을 남기고, 네트워크와 전체 목적지를 확인하며, 불일치하면 중단하세요. 이 글은 교육 목적이며 투자 조언이 아닙니다. 크립토 거래는 전액 손실로 이어질 수 있으므로 최신 도구를 확인하고, 잃어도 되는 금액만 사용하며 스스로 조사하세요(DYOR).

주요 출처

• ERC-55: 혼합 대소문자 체크섬 주소 인코딩
• Ethereum.org: 이더리움 계정
• Ethereum.org: 네트워크
• ethers v6: Addresses
• viem: getAddress
• ERC-1191: 체인 ID를 반영한 혼합 대소문자 체크섬