다른 지갑들은 안전한가?

내 지갑은 안전한가

다른 지갑들과 우리가 배워야 할 것 — 3부

시리즈 안내
1부에서는 SecondFi 해킹의 전말을, 2부에서는 결정론적 논스 도출 오류의 기술적 원리를 다뤘습니다.
3부에서는 "나는 다른 지갑을 쓰는데 안전한가"라는 질문에 답하고, 이번 사건이 남기는 교훈을 정리합니다.

2026년 6월 27일


2부에서 우리는 SecondFi 해킹의 기술적 원리를 살펴봤습니다. 결정론적 논스 도출 오류가 어떻게 공개 블록체인 데이터만으로 개인 키를 역산 가능하게 만들었는지를 이해했다면, 자연스럽게 다음 질문이 떠오릅니다.

“나는 Eternl을 쓰는데 괜찮은 건가요?” “Daedalus나 Lace는 안전한가요?” “하드웨어 지갑이 있으면 이런 공격에서 자유로울까요?”

3부에서 이 질문들에 하나씩 답합니다. 그리고 이번 사건 전체에서 지갑 사용자가 실질적으로 배워야 할 것들을 정리합니다.


1. 이 취약점은 SecondFi에만 있는 것인가

결론부터 말씀드립니다. 현재까지 공개된 모든 분석에서, 이번 취약점은 SecondFi의 독자적(proprietary) 소프트웨어 서명자(software signer)에 국한된 결함으로 확인됩니다.

CoinDesk의 보도SecondFi 공식 발표 모두, 문제의 원인을 "SecondFi의 자체 카르다노 지갑 생성 소프트웨어의 결함"으로 명시했습니다. 카르다노 프로토콜이나 생태계 전반의 서명 표준이 아닌, SecondFi가 독자적으로 구현한 소프트웨어 서명자의 논스 파생 로직이 잘못됐다는 것입니다.

Bitquery의 온체인 분석도 이 결함을 "SecondFi 자체 키 생성 코드의 약한 무작위성"으로 규정하며, 카르다노 체인 자체는 전혀 무관하다고 명확히 밝혔습니다. MoneyCheck의 보도에 따르면 찰스 호스킨슨도 "카르다노는 해킹되지 않았다"고 직접 발언하며, 프로토콜 레이어와 암호화 기반 및 오픈소스 지갑 코드베이스 모두 보안 손상 없이 정상 작동하고 있음을 강조했습니다.

다만 중요한 단서가 있습니다. 이것은 "다른 지갑들이 안전하다는 공식 확인"이 아닙니다. 현재까지 Eternl, Lace, Daedalus 등 타 지갑 팀이 "우리 소프트웨어에는 동일 취약점이 없다"는 독립 감사 결과를 공개 발표한 사례는 검색되지 않습니다. 이것이 공식 확인 부재를 의미하지는 않지만, 독자 스스로 각 지갑 팀의 공식 채널을 직접 확인하는 것이 가장 정확한 방법입니다.


2. 주요 카르다노 소프트웨어 지갑 비교

SecondFi 사건의 맥락에서 다른 카르다노 지갑들을 비교해 봅니다.

Daedalus

Daedalus는 IO(Input Output)가 개발한 카르다노 유일의 풀 노드(full-node) 지갑입니다. 카르다노 블록체인 전체 히스토리를 로컬에 저장하고 각 트랜잭션을 독립적으로 검증합니다. 코드는 완전 오픈소스로 공개되어 누구나 감사할 수 있습니다. SecondFi와 달리 자체 독자 서명 소프트웨어를 별도로 구현하지 않으며, IO가 관리하는 카르다노 공식 라이브러리 스택을 사용합니다.

Eternl

Eternl은 독일 기업 Tastenkunst GmbH가 개발한 경량 지갑으로 구 CCVault에서 이름을 바꿨습니다. 브라우저 확장, 모바일 앱, 웹 앱 형태로 제공됩니다. 개인 키를 서버가 아닌 사용자 기기에 암호화해 저장하는 비수탁(non-custodial) 방식입니다. 카르다노 커뮤니티에서 기능성과 안정성으로 높은 신뢰를 받고 있습니다. 앱 코드의 오픈소스 공개 여부는 Eternl 공식 채널에서 직접 확인하시기 바랍니다.

Lace

Lace는 IO가 개발·운영하는 경량 지갑으로, 구 Nami 지갑을 흡수해 재개발됐습니다. IO의 공식 라이브러리 스택을 기반으로 하며, 마찬가지로 오픈소스입니다.

공통점과 핵심 차이

위 지갑들의 가장 중요한 공통점은 오픈소스라는 것입니다. 소스 코드가 공개되어 있으면 외부 보안 연구자와 커뮤니티가 코드를 감사하고 취약점을 발견해 공개할 수 있습니다. SecondFi의 문제는 독자적 서명 소프트웨어가 이 감사 과정을 충분히 거치지 않았을 가능성을 시사합니다. 물론 오픈소스가 보안을 보장하는 것은 아닙니다. 코드가 공개되어 있더라도 아무도 읽지 않거나 검토가 부실하면 의미가 없습니다. 그러나 오픈소스는 감사 가능성(auditability)을 열어두는 최소한의 조건입니다.


3. 하드웨어 지갑은 이번 공격에서 안전했는가

이번 사건에서 하드웨어 지갑 사용자들은 피해를 입지 않은 것으로 알려졌습니다. 독립 보안 분석에 따르면, 이번 취약점의 범위는 SecondFi의 웹 인터페이스를 통해 생성된 지갑에 국한됐으며 하드웨어 지갑과 외부 시드 구문으로 생성된 지갑은 영향을 받지 않았습니다.

그 이유는 하드웨어 지갑의 구조에 있습니다. Ledger나 Trezor 같은 하드웨어 지갑은 개인 키 생성과 트랜잭션 서명을 기기 내부의 보안 칩(Secure Element) 안에서 격리 실행합니다. Ledger의 설명처럼, 개인 키는 절대 기기 외부로 나가지 않으며 모든 서명은 물리적 기기 위에서 처리됩니다. SecondFi처럼 소프트웨어 서명자가 웹 브라우저나 서버와 상호작용하는 구조와 근본적으로 다릅니다.

물론 하드웨어 지갑도 취약점이 없는 것은 아닙니다. 2026년 6월, Ledger Donjon 팀이 Trezor Safe 7의 보안 칩(TROPIC01)에서 레이저 결함 주입 방식의 취약점을 발견했습니다. 다만 이 공격은 기기를 물리적으로 분해하고 전문 장비가 필요한 것으로, SecondFi처럼 원격에서 공개 블록체인 데이터만으로 키를 역산하는 공격과는 완전히 다른 위협 모델입니다. Trezor는 이 취약점이 자금 안전에 영향을 주지 않는다고 공식 확인했습니다.

요약하면, 하드웨어 지갑은 이번 SecondFi 유형의 소프트웨어 서명 취약점에 대해 구조적으로 더 강한 보호를 제공합니다.


4. 같은 유형의 취약점은 역사적으로 반복됐다

논스 파생 오류는 SecondFi가 처음 발명한 취약점이 아닙니다. 암호화폐 역사에서 같은 원리의 결함이 반복적으로 나타났습니다.

2010년 소니 PS3: 2부에서 다룬 것처럼, fail0verflow가 Sony의 ECDSA 서명에서 동일한 논스 k가 사용됐음을 발견해 개인 서명 키를 역산했습니다. 이후 임의의 코드를 PS3에서 실행할 수 있게 됐습니다.

2013년 안드로이드 비트코인 지갑: 안드로이드의 난수 생성기(SecureRandom)에서 결함이 발견되며, 이를 사용한 비트코인 지갑 앱들의 서명 논스가 예측 가능해졌습니다. Bitcoin Wallet, Mycelium, blockchain.info 등 주요 안드로이드 지갑 앱 전체가 영향을 받았으며, 확인된 피해는 55.82 BTC(당시 약 5,500달러)에 달했습니다. 미신고 피해를 포함한 실제 총피해는 알 수 없습니다.

2024년 PuTTY SSH 클라이언트 (CVE-2024-31497): SSH 클라이언트 PuTTY가 ECDSA 서명을 위해 독자적으로 구현한 논스 파생 방식에서 편향(bias)이 발견됐습니다. Help Net Security의 보도에 따르면 NIST P-521 곡선을 사용한 논스의 첫 9비트가 항상 0으로 고정돼 있었으며, 60개의 서명만 수집하면 개인 키를 복원할 수 있었습니다. 피해 규모는 다르지만 원리는 동일합니다.

패턴이 반복되는 이유는 두 가지입니다. 첫째, 암호화 라이브러리를 직접 구현하는 것은 매우 어렵고, 표준(RFC 6979 등)을 정확히 따르지 않으면 미묘한 결함이 생깁니다. 둘째, 이런 결함은 일반적인 기능 테스트로는 발견되지 않습니다. 정상적으로 작동하는 것처럼 보이지만 암호학적으로 안전하지 않은 상태입니다. 전문적인 암호학 감사(cryptographic audit)가 없으면 출시 후에도 오랫동안 숨어 있을 수 있습니다.

SecondFi 사건이 카르다노 커뮤니티에 던지는 경고이기도 합니다. 어떤 지갑이든 독자 암호화 구현을 포함하고 있다면, 그 코드에 대한 전문 감사가 필수입니다.


5. SecondFi/요로이 사용자를 위한 현재 행동 지침

현재 SecondFi 또는 요로이 웹 지갑을 사용 중이거나 과거에 사용한 적이 있다면, 다음을 확인하십시오.

즉시 해야 할 것:

  • support.secondfi.io에서 피해 여부를 확인하고 해당된다면 클레임을 제출합니다.
  • SecondFi의 공식 X 계정과 공식 이메일 외의 경로에서 복구 구문이나 개인 키를 요청하는 시도는 모두 사기입니다. 응하지 마십시오.

하지 말아야 할 것:

  • 기존 SecondFi 시드 구문을 Eternl, Lace 등 다른 지갑에 임포트하는 것 (2부에서 설명한 이유로 위험합니다)
  • 영향받은 주소로 스테이킹 리워드를 인출하거나 새 자금을 입금하는 것
  • 공식 채널이 아닌 경로에서 접수되는 복구 안내나 지원 요청에 응하는 것

해야 할 것:

  • 완전히 새로운 시드 구문으로 신뢰할 수 있는 다른 지갑(Eternl, Lace, Daedalus 등)에서 새 주소를 생성합니다.
  • 새 주소로 소액을 먼저 이전해 정상 작동을 확인한 뒤, 나머지 자산을 이전합니다.
  • SecondFi의 공식 보상 절차가 진행될 경우 support.secondfi.io를 통해 참여합니다.

6. 이번 사건에서 모든 지갑 사용자가 배워야 할 것

SecondFi 사건은 특정 지갑 한 곳의 문제로 끝나지 않습니다. 자기 수탁(self-custody) 방식의 블록체인 지갑을 사용하는 모든 이들이 점검해야 할 원칙들을 남겼습니다.

원칙 1: 지갑 소프트웨어의 오픈소스 여부를 확인하라

코드가 공개된 지갑은 외부 보안 연구자가 취약점을 발견하고 공개할 수 있습니다. 오픈소스가 보안을 보장하지는 않지만, 감사 가능성의 최소 조건입니다. 사용 중인 지갑이 오픈소스인지 확인하고, 독립적인 보안 감사를 받았는지 확인하십시오.

원칙 2: 독자적 암호화 구현을 포함한 제품은 주의하라

SecondFi의 경우처럼, 표준 라이브러리를 사용하지 않고 자체 서명 소프트웨어를 구현한 제품은 잠재적인 위험 지점이 될 수 있습니다. 새로운 지갑 제품을 선택할 때, 특히 대규모 리브랜딩이나 기능 확장 이후에는 신중한 검토가 필요합니다.

원칙 3: 큰 자산은 하드웨어 지갑에 보관하라

소프트웨어 지갑의 서명 취약점은 원격에서 공개 데이터만으로도 공격이 가능합니다. 반면 Ledger, Trezor 같은 하드웨어 지갑은 개인 키를 오프라인 보안 칩 안에 격리하여 이런 공격 경로를 차단합니다. 장기 보유 자산은 하드웨어 지갑에, 일상적인 소액 거래는 소프트웨어 지갑에 나눠 보관하는 분리 전략이 현실적입니다.

원칙 4: 시드 구문은 지갑별로 분리하라

같은 시드 구문을 여러 지갑 앱에서 공유하거나 재사용하면, 하나의 앱에서 발생한 취약점이 같은 시드에서 파생된 모든 주소로 확산됩니다. 용도와 보관 기간에 따라 별개의 시드 구문과 주소를 사용하는 것이 안전합니다.

원칙 5: 제도적 신뢰가 기술적 보안을 대신할 수 없다

SecondFi는 카르다노 공식 앱 카탈로그에 등재된 EMURGO 공식 제품이었습니다. 기관의 신뢰와 공식 지지가 있다고 해서 소프트웨어 보안이 보장되지는 않습니다. 공식 제품일수록 오히려 더 엄격한 보안 감사가 요구됩니다. 브랜드와 배경보다 코드와 감사 이력을 확인하는 습관이 필요합니다.


마치며 — 시리즈를 마무리하며

3부작 시리즈를 통해 SecondFi 해킹의 세 가지 층위를 살펴봤습니다.

1부에서는 사건의 전말을 다뤘습니다. 요로이에서 SecondFi로 이어진 신뢰의 계보, 72시간의 공격 경과, 두 가지 피해 추산치의 차이, 그리고 EMURGO와 재단의 초기 침묵을 짚었습니다.

2부에서는 기술적 원리를 풀었습니다. Ed25519 서명 알고리즘이 어떻게 작동하는지, 올바른 결정론적 논스 설계가 무엇인지, 그리고 SecondFi가 그 설계를 잘못 구현해 공개 블록체인 데이터만으로 개인 키가 역산 가능해진 과정을 설명했습니다.

3부에서는 질문에 답했습니다. 다른 카르다노 지갑들은 현재까지 같은 취약점이 발견되지 않았으나, 이것이 보장은 아닙니다. 하드웨어 지갑은 이번 유형의 공격에 구조적으로 더 강합니다. 그리고 같은 원리의 취약점은 역사적으로 반복됐으며, 그 예방책은 언제나 코드 감사와 표준 준수입니다.

블록체인에서 자기 수탁은 강점인 동시에 책임입니다. 열쇠를 스스로 쥐는 것은 누구에게도 의존하지 않는 자유이지만, 그 열쇠가 처음부터 부서져 있었다면 어떤 자물쇠도 소용이 없습니다. SecondFi 사건이 그 교훈을 가장 값비싼 방식으로 상기시켜 줬습니다.


본 시리즈는 2026년 6월 27일 현재까지 공개된 정보를 기반으로 작성됐습니다. SecondFi의 공식 기술 포스트모텀과 독립 감사 결과가 발표되면 일부 내용이 업데이트될 수 있습니다. SecondFi 사용자 보상 관련 최신 정보는 support.secondfi.ioSecondFi 공식 X 계정을 통해 확인하시기 바랍니다.