회복 이야기 . 이더리움 사전 판매

1,000 ETH, 프리세일 지갑 하나, 그리고 “작동했어야 할” 비밀번호

주인은 비밀번호가 맞다고 확신했다. 하지만 지갑은 여전히 열리지 않았다. 진짜 문제는 비밀번호 자체가 아니라, 10년 전에 그 비밀번호를 어떻게 저장해 두었는지에 있었다.

2026년 7월 업데이트 · KeychainX — 2017년부터 지갑 복구 서비스 제공

우리가 열어본 가장 가치 있는 지갑 중 일부는 2014년 초기 프리세일 당시 — ETH 가격이 약 30센트였던 시절 — 이더를 구매한 사람들의 것입니다. 이번 사례도 그중 하나입니다. ethereum_backup_wallet.json 파일에 약 1,000 ETH가 잠겨 있었고, 소유자는 비밀번호를 기억하고 있었지만 지갑에 접속할 수 없었습니다. 세부 정보는 익명 처리되었지만, 기술적인 경위는 정확히 이대로 진행되었습니다.

상황

이 소유자는 프리세일에 참여하여 지갑 JSON 파일을 다운로드한 뒤, 비밀번호를 꼼꼼히 적어 두었습니다. 몇 년이 지나 ETH 가격이 프리세일 당시보다 수천 배나 치솟았을 때, 이 파일을 열어보려 했으나 일반적인 프리세일 도구에서 비밀번호를 인식하지 못했습니다. 생각나는 대로 대소문자 조합과 다양한 변형을 모두 시도해 보았지만, 당연히 아무것도 통하지 않았습니다. 결국 저희에게 연락을 해왔을 때쯤에는 파일 자체가 손상되었다고 확신하고 있었습니다.

무엇이 힘들게 했는지

프리세일 지갑 형식은 PBKDF2-HMAC-SHA256 및 AES-128-CBC를 사용하여 시드를 암호화합니다. 이 방식은 용서가 없습니다. 비밀번호로 바이트 단위로 완벽하게 일치하는 복호화 결과가 나오지 않으면 완전히 실패하며, ‘거의 비슷하다’는 식의 예외는 없습니다. 소유자의 비밀번호에는 비-ASCII 문자가 포함되어 있었는데, 바로 그게 문제의 전부였습니다. 10년 전, 지갑이 생성된 컴퓨터에서는 해당 문자가 1바이트 인코딩으로 저장되었습니다. 오늘날 최신 키보드와 운영 체제에서 다시 입력했을 때, 다른 바이트가 생성되었습니다. 화면상으로는 두 문자가 똑같이 보였지만, 입력된 내용은 같지 않았습니다. 비밀번호는 맞았지만, 인코딩이 잘못된 것이었습니다.

우리가 어떻게 해결했는지

우리는 소유자의 정확한 비밀번호를 확보한 후, 이에 대한 모든 가능한 인코딩 및 정규화 형태를 생성했습니다. 여기에는 UTF-8 대 Latin-1, 합성된 유니코드 형태 대 분해된 유니코드 형태, 그리고 키보드와 운영 체제에 따라 특정 문자가 가질 수 있는 구체적인 대체 형태 등이 포함됩니다. 각 변형은 당사의 GPU 하드웨어에서 프리세일 해시 모드를 사용하여 암호화된 파일을 대상으로 오프라인 테스트를 거쳤습니다. 그 단 하나의 ‘알려진’ 비밀번호로 구축된 후보 집합 내에서, 한 가지 인코딩 방식이 지갑을 완벽하게 복호화하고 올바른 주소를 재현해 냈습니다. 비밀번호는 처음부터 정확했던 것입니다.

결과

지갑이 열리고, 개인 키가 추출된 후, 소유자는 약 1,000 ETH를 자신이 직접 관리하는 최신 지갑으로 이체했습니다. 당사는 해당 자금을 한 번도 보관한 적이 없습니다. 수수료는 회수된 금액의 일정 비율이었으며, 작업이 성공적으로 완료되었기 때문에 지급된 것입니다. 훼손되어 무가치해 보였던 그 파일은 사실 처음부터 엄청난 재산이었으나, 눈에 보이지 않는 인코딩 차이로 인해 접근이 차단되어 있었던 것이었습니다.

이 일이 실제로 얼마나 흔한 걸까요?

사람들이 생각하는 것보다 훨씬 흔한 일입니다. 2014년 사전 판매용 지갑은 유난히 취약한 것으로 악명이 높으며, 지난 몇 년간 우리는 “올바른” 비밀번호로도 지갑을 열 수 없는 거의 20가지의 서로 다른 원인을 정리해 왔습니다. 여기에는 인코딩 불일치, 유니코드 정규화 차이, 공백 및 키보드 레이아웃의 특이점, 그리고 초기 개발 도구에 기인한 몇 가지 명백한 소프트웨어 버그 등이 포함됩니다. 이번 사례의 인코딩 문제는 그중에서도 가장 빈번하게 발생하는 것일 뿐입니다. 그렇기 때문에 우리는 “비밀번호는 맞는데 열리지 않는다”는 상황을 막다른 골목이 아니라 진단으로 간주합니다. 이는 대개 비밀번호 자체는 문제없고, 그 주변의 어떤 요인을 재현해 봐야 한다는 뜻이기 때문입니다. 포기하는 사람들은 파일이 손상되었다고 가정하는 반면, 복구하는 사람들은 인코딩 문제를 의심하고 이를 테스트해 봅니다.

이걸 직접 해보실 수 있나요?

원칙적으로는 그렇습니다. 프리세일 형식은 공개되어 있으며, 이를 기준으로 비밀번호를 검사하는 공개 도구들이 있습니다. 실제로 어려운 점은 도구를 실행하는 것이 아니라, 올바른 후보를 생성하는 것입니다. 즉, 특정 문자가 어떤 운영 체제에서 어떤 인코딩과 정규화 형태를 취할 수 있는지 파악하고, 이를 수동으로 변형을 입력하는 대신 검색어로 표현해야 합니다. “알고 있는” 비밀번호로 직접 시도해 봤는데 이미 실패했다면, 그 실패 자체가 단서가 됩니다. 이는 수동으로 일일이 열거하기에는 지루하지만 체계적으로 검색하면 빠르게 찾을 수 있는 변환 방식을 정확히 가리키기 때문입니다.

프리세일 사례를 성공적으로 진행하기 위한 방법

프리세일 지갑을 검토해 드릴 경우, 다음 세 가지 요소가 결정적인 역할을 합니다. 바로 ‘ethereum_backup_wallet.json’ 파일 자체, 사용자가 정확하다고 생각하는 비밀번호(기억나는 대로 최대한 정확하게 입력해 주세요), 그리고 지갑이 생성된 환경에 대한 세부 정보(운영 체제, 키보드 언어, 대략적인 연도 등)입니다. 이러한 맥락 정보를 통해 당시는 어떤 인코딩 방식과 정규화 형식이 적용되었는지 재구성할 수 있습니다. 심지어 “오래된 Windows 노트북에서 독일어 키보드를 사용했다”는 사실조차도 사건의 향방을 결정짓는 중요한 단서가 될 수 있습니다.

이 사례가 사전 판매 지갑에 대해 시사하는 점

2014년 사전 판매된 ETH 중 한 번도 이동된 적이 없는 엄청난 양이 존재합니다. 그중 상당 부분은 소유자가 보유하기로 선택했기 때문이 아니라, 더 이상 접근할 수 없기 때문입니다. 이와 같은 사례는 해당 자산의 상당 부분이 실제로 손실된 것이 아니라, 방금 설명한 것과 같은 해결 가능한 기술적 문제에 의해 차단되어 있을 뿐임을 보여줍니다. 영원히 잠겨 있는 지갑들은 대개 소유자가 최악의 상황을 가정하고 더 이상 시도하지 않은 경우입니다. 다시 복구되는 지갑은 소유자가 파일을 보관해 두고, 비밀번호를 대략 기억하고 있으며, 누군가가 지갑이 생성되었던 당시의 조건을 재현할 수 있게 한 경우입니다. 이미 포기한 프리세일 지갑을 보유하고 있다면 다시 한 번 살펴볼 가치가 있습니다. 지난 10년간의 가격 상승으로 인해, 비록 소액이라 할지라도 프리세일 지분은 그 노력을 기울일 만한 가치가 충분합니다.

이 글에서 얻을 수 있는 점

프리세일 지갑과 확실한 비밀번호가 있는데도 지갑이 열리지 않는다면, 파일이 손상되었다고 단정하지 마세요. 특히 비밀번호에 악센트, 움라우트 또는 기타 비-ASCII 문자가 포함된 경우에는 더욱 그렇습니다. 이것이 “올바른” 프리세일 비밀번호가 작동하지 않는 가장 흔한 이유이며, 바로 해결할 수 있는 문제입니다. 자세한 내용은 이더리움 프리세일 복구 페이지를 참고하세요.

자주 묻는 질문