EIP-6963 지갑 탐색: 여러 브라우저 월렛을 구분하는 원리

지갑 연결을 눌렀는데 엉뚱한 브라우저 확장 프로그램이 열리거나, 설치한 지갑 여러 개 중 하나만 보인 적이 있나요? 개인키 문제가 아니라 프로바이더 탐색(Provider Discovery)의 충돌일 수 있어요. EIP-6963 지갑 탐색은 호환 디앱(dApp)이 여러 주입형 지갑을 찾고 사용자가 직접 고르게 하는 표준입니다. 의도한 지갑을 선택하는 일은 계정 요청이나 서명 전 첫 관문이므로 크립토 지갑 보안의 일부로 알아둘 만해요.

투자 조언이 아닙니다(NFA). EIP-6963은 지갑을 찾는 과정을 개선할 뿐, 지갑·디앱·트랜잭션·토큰의 안전을 검증하지 않아요. 사이트와 확장 프로그램을 직접 확인하고, 모든 요청을 읽으며, 잃어도 되는 금액만 사용하고 스스로 조사하세요(DYOR).

EIP-6963이 해결하는 문제

브라우저 지갑은 프로바이더라는 자바스크립트 인터페이스를 노출해요. 디앱은 이를 통해 계정을 요청하고, 체인 상태를 읽거나 서명을 요청합니다. EIP-1193은 공통 이더리움 프로바이더 API를 정의해요. 예전 방식에서는 여러 확장 지갑이 window.ethereum이라는 하나의 공유 출입구를 두고 경쟁했습니다.

택배 회사가 여러 곳 입주한 건물에 이름표 없는 호출 벨이 하나뿐이라고 생각해 보세요. 마지막으로 벨을 연결한 회사가 모든 호출을 받을 수 있고, 방문자는 원한 회사를 안정적으로 고르기 어렵습니다. 확장 프로그램의 로드 순서를 예측할 수 없으면 디앱도 의도하지 않은 지갑과 대화할 수 있어요.

EIP-6963은 브라우저 윈도 이벤트(Window Event)로 이 문제를 푸는 최종(Final) 상태의 표준 트랙 인터페이스예요. 호환 지갑마다 자신을 따로 알리고, 디앱은 발표를 모아 지갑 선택창을 만들 수 있습니다. 하나의 바뀔 수 있는 전역 객체만 정답으로 취급하지 않는 거예요.

이 표준이 EIP-1193을 대체하는 것은 아닙니다. EIP-1193 프로바이더를 찾는 방법이에요. 기존 window.ethereum도 즉시 사라지는 게 아니며, 명세는 호환성을 위한 대체 경로(Fallback)를 권고합니다.

요청과 발표 이벤트는 어떻게 작동할까요?

핵심 이벤트는 두 개예요.

1. 디앱이 eip6963:announceProvider 이벤트를 들을 리스너(Listener)를 먼저 등록해요.
2. 준비가 끝나면 eip6963:requestProvider 이벤트를 보냅니다.
3. 호환 지갑은 요청을 듣고 각자의 프로바이더 정보를 발표해요.
4. 디앱은 서로 다른 정보를 모아 사용 가능한 지갑 선택지를 보여줍니다.
5. 사용자가 하나를 고르면 디앱은 그 지갑의 EIP-1193 프로바이더로 후속 요청을 보내요.

지갑은 확장 코드가 로드될 때도 자신을 발표하고, 나중에 들어오는 요청 이벤트도 계속 듣습니다. 그래서 디앱이 먼저 준비되든 지갑이 먼저 준비되든 다시 만날 수 있어요.

출석 확인과 비슷합니다. 진행자가 출석부를 먼저 펼친 뒤 참석자에게 이름을 말해 달라고 요청해요. 먼저 도착해 이미 인사했던 사람도 다시 답하므로, 출석부가 생기기 전 발표를 놓쳐도 괜찮습니다.

여기서 중요한 경계가 있어요. 탐색은 연결이 아닙니다. 프로바이더 발표만으로 계정 주소가 공개되거나 디앱 접근이 승인되거나 서명이 만들어져서는 안 돼요. 이후 계정 접근 요청과 각각의 서명은 별도의 지갑 결정입니다.

지갑이 발표하는 정보

EIP-6963 발표에는 EIP-1193 프로바이더와 네 가지 필수 필드로 된 info 객체가 들어 있어요.

필드	역할	꼭 알아둘 한계
uuid	페이지가 열린 동안 프로바이더 세션을 구분	지갑의 보안 인증서가 아니에요
name	선택창에 표시할 사람이 읽는 지갑 이름	표시 이름은 흉내 낼 수 있어요
icon	데이터 URI 형식의 지갑 아이콘 제공	신뢰하지 않은 SVG는 이미지 요소로 안전하게 렌더링해야 해요
rdns	역방향 도메인 형식의 지갑 식별자 제공	자기 선언값이며 신원 증명이 아니에요

UUID는 UUIDv4 형식을 따라야 하므로 다른 정보가 같아도 페이지 수명 동안 두 발표를 구분할 수 있어요. 반면 역방향 도메인(RDNS) 값은 세션이 바뀌어도 안정적인 식별자를 지향합니다. 둘의 역할이 달라요.

공식 명세는 rdns, 이름, 아이콘이 잘못되거나 모방될 수 있다고 명시합니다. 연결창의 지갑 항목이 그럴듯해 보여도 진품 인증을 뜻하지 않아요.

사용자에게 무엇이 달라질까요?

호환 사이트에서는 개선점이 단순해요. 여러 주입형 지갑을 설치해도 연결 버튼 하나를 차지하기 위해 경쟁하지 않고, 사용 가능한 프로바이더 목록에서 의도한 지갑을 고를 수 있습니다.

선택권이 생겨도 다음 순서로 검증하세요.

1. 디앱 출처를 확인하세요. 신뢰하는 북마크나 독립적으로 검증한 공식 도메인으로 접속합니다.
2. 확장 프로그램을 확인하세요. 공식 배포자와 브라우저 스토어 등록 정보를 대조해요.
3. 의도적으로 선택하세요. 이름과 아이콘을 확인하되, 그것만 신뢰하지는 마세요.
4. 활성 계정과 네트워크를 확인하세요. 선택 뒤 디앱과 지갑 양쪽의 주소와 체인을 대조합니다.
5. 다음 요청을 읽으세요. 탐색 표준은 계정 요청, 로그인, 승인, 트랜잭션을 안전하게 만들지 않아요.

그래도 다른 지갑이 열린다면 디앱이 구형 방식을 쓰거나, 어떤 확장 프로그램이 표준을 지원하지 않거나, 남아 있는 사이트 권한이 흐름에 영향을 줄 수 있어요. 연결을 억지로 만들려고 지갑 보호 기능을 끄지는 마세요. 요청을 닫고 사이트를 다시 확인한 뒤 연결된 사이트 권한과 해당 지갑의 공식 문제 해결 문서를 살펴보는 편이 안전합니다.

보안과 프라이버시 한계

지갑 모방은 여전히 가능해요

EIP-6963은 발표를 정리하지만 지갑 브랜드의 인증 레지스트리를 만들지는 않아요. 악성 확장 프로그램이 다른 지갑의 이름, 아이콘, 역방향 도메인 값을 흉내 낼 수 있습니다. 디앱은 수상한 중복과 잘못된 발표를 방어적으로 처리해야 하고, 사용자는 확장 프로그램 설치를 별도의 신뢰 결정으로 봐야 해요.

프로바이더 객체는 신뢰할 수 없는 페이지에 놓여요

EIP-1193은 프로바이더 객체가 적대적 환경에 노출된 것처럼 취급하라고 안내합니다. EIP-6963은 예상치 못한 변경을 줄이기 위해 탐색 세부 정보를 동결(Freeze)하길 권하지만, 프로바이더를 수정하는 페이지나 도구와의 호환성 절충도 언급해요. 표준 인터페이스 자체가 보안 샌드박스는 아닙니다.

아이콘도 신뢰하지 않은 입력이에요

아이콘은 데이터 URI로 전달돼요. SVG에는 자바스크립트가 들어갈 수 있으므로, 명세는 SVG 마크업을 페이지에 직접 삽입하지 말고 <img> 요소로 렌더링하도록 요구합니다. 개발자는 프로바이더 메타데이터를 계속 주의해서 검증하고 표시해야 해요.

지갑 탐색이 브라우저 지문이 될 수 있어요

페이지가 설치된 지갑 종류를 알면 브라우저 환경을 구분하는 신호 하나가 더 생깁니다. 명세는 프라이버시를 고려한 방식으로 명시적인 프로바이더 요청을 기다렸다가, 발표 전에 동의를 묻는 흐름도 논의해요. 지원과 동작은 지갑마다 다를 수 있으니 탐색이 보이지 않는다고 가정하면 안 됩니다.

올바른 지갑 선택이 안전한 서명을 뜻하지 않아요

원한 지갑을 골랐어도 악성 디앱은 위험한 승인이나 기만적인 서명을 요청할 수 있어요. 클리어 사이닝 점검법으로 컨트랙트와 지출 권한자를 확인하고, 결과를 설명할 수 없는 요청은 거절하세요.

지갑 탐색·연결·로그인은 서로 달라요

한 번에 이어지는 것처럼 보여도 각 단계가 답하는 질문은 다릅니다.

단계	답하는 질문	증명하지 않는 것
프로바이더 탐색	어떤 호환 지갑을 사용할 수 있나?	지갑이나 사이트가 믿을 만한가?
계정 연결	디앱이 어떤 주소에 접근해도 되나?	서버 로그인 세션의 소유권 증명
SIWE 로그인	이 주소가 이 로그인 요청에 동의했나?	토큰 지출 권한
트랜잭션·메시지 서명	계정이 이 특정 데이터에 권한을 부여했나?	요청 결과가 유리하거나 안전한지

경계를 구분하면 “올바른 지갑을 골랐으니 다음 요청도 괜찮겠지”라는 지름길을 피할 수 있어요. 모든 요청을 따로 검토해야 합니다.

자주 묻는 질문(FAQ)

EIP-6963은 최종 표준인가요?

네. 공식 EIP 저장소는 EIP-6963을 최종(Final) 상태의 표준 트랙 인터페이스로 표시해요. 다만 이는 명세 상태이며 모든 지갑과 디앱이 구현했다는 뜻은 아닙니다.

window.ethereum을 대체하나요?

아니요. EIP-1193 프로바이더를 찾는 대안 방식이에요. 명세는 다중 지갑 탐색에 EIP-6963을 권하면서 호환성 전환 기간에는 기존 방식도 대체 경로로 남기길 권합니다.

지갑 탐색만으로 주소가 노출되나요?

프로바이더 발표에는 프로바이더 메타데이터와 인터페이스가 담기며 계정 목록은 담기지 않아요. 계정 접근은 별도 요청입니다. 다만 설치된 지갑 조합 자체는 브라우저 지문 신호가 될 수 있어요.

선택창의 지갑 이름과 아이콘을 믿어도 되나요?

진품 증명으로 믿으면 안 돼요. 해당 메타데이터는 프로바이더가 제공하고 모방할 수 있습니다. 확장 프로그램 출처, 디앱 도메인, 선택 계정과 모든 후속 요청을 따로 검증하세요.

메타마스크 전용 표준인가요?

아니요. 여러 주입형 프로바이더를 위한 이더리움 인터페이스 표준이에요. 메타마스크 개발 문서도 EIP-6963과 EIP-1193을 브라우저 확장 지갑 탐색 표준으로 설명하지만, 인터페이스 자체는 특정 브랜드 전용이 아닙니다.

마무리

EIP-6963은 이름표 없는 벨 하나를 출석 확인으로 바꿔요. 호환 지갑이 각자의 프로바이더를 발표하고, 디앱은 사용자가 직접 고르게 할 수 있습니다. 연결 흐름의 첫 단계를 정돈하는 의미 있는 상호운용성 개선이에요.

하지만 첫 단계일 뿐입니다. 사이트와 확장 프로그램을 검증하고, 계정과 네트워크를 확인하며, 로그인·승인·메시지·트랜잭션을 각각 읽으세요. 이 글은 정보 제공 목적이며 투자 조언이 아닙니다. 크립토와 셀프 커스터디에는 원금 전액 손실 가능성이 있으므로 잃어도 되는 금액만 사용하고 DYOR을 실천하세요.

출처

• EIP-6963: Multi Injected Provider Discovery
• EIP-1193: Ethereum Provider JavaScript API
• MetaMask Connect 개발자 문서