일부 블록체인은 왜 서명 내용을 숨길까요?

하드웨어 지갑에서 암호화폐 거래를 승인할 때, 두 가지 중 하나를 하게 돼요. 하나는 어떤 일이 일어날지 명확하게 설명된 화면을 읽고 승인하는 것이고, 다른 하나는 의미를 알 수 없는 16진수 코드에 서명하며 믿고 넘어가는 거예요. '블라인드 서명'이란 사람이 읽을 수 있는 정보 없이 디지털 거래를 승인하는 행위를 말해요.
 

2025년 2월, 블라인드 서명은 $1.5 billion Bybit hack 사태의 주요 원인이 됐어요. 이는 역사상 최대 암호화폐 도난 사건이었죠. 공격자들은 암호 기술을 뚫은 것이 아니라, 사용자가 평범한 이체와 악의적인 컨트랙트 업그레이드를 구분하지 못한다는 점을 악용했어요.
 

지갑이 서명 전에 명확하고 읽기 쉬운 요약을 보여줄 수 있는지는 소프트웨어 품질 문제가 아니라, 각 블록체인이 프로토콜 수준에서 어떻게 설계됐는지에 달려 있어요. 어떤 체인은 거래 자체가 내용을 설명하도록 설계됐고, 다른 체인은 중요한 정보를 외부 데이터 없이는 해독할 수 없는 바이너리 형태로 숨겨요. 이 글에서는 이런 설계 차이가 주요 블록체인별로 어떻게 나타나는지와, 이것이 보안에 어떤 의미를 가지는지 설명해요.

3단계 프레임워크

명확한 서명(Clear Signing)이란, 승인 전에 하드웨어 지갑의 안전한 화면에서 거래 내용을 사람이 읽을 수 있는 형태로 모두 확인할 수 있게 해주는 보안 절차예요. 

13개의 주요 블록체인 생태계에서 명확한 서명 지원은 프로토콜 구조에 따라 3가지 단계로 나뉘어요. 이 구분은 체인의 우열이 아니라, 보안에 대한 이해가 충분하지 않았던 시절에 내린 설계 선택의 결과예요.

Tier 1: 투명성을 위해 설계된 체인

이 단계의 블록체인은 서명이 자연스럽게 설계 구조에서 파생돼요. 핵심 이유는, 모든 필드에 이름·타입·스키마가 명확히 정의된 한정된 거래 구조를 사용하기 때문이에요. 하드웨어 지갑은 외부 정보 없이도 거래 내용을 해석할 수 있고, 거래 자체가 무엇인지 알려줘요.

The XRP Ledger 는 주요 체인 중에서도 가장 명확한 서명 구조를 제공합니다. 바이너리 포맷에 TransactionType 필드가 포함되어 있어 50개 이상의 거래 유형(Payment, OfferCreate, TrustSet, EscrowCreate 등)을 판별할 수 있어요. 모든 필드가 명확한 스키마를 가지므로, 하드웨어 지갑에서 수신자, 금액, 수수료, 메모, 각 거래별 특수 파라미터까지 외부 조회 없이 모두 표시할 수 있습니다. 현재 메인넷 거래의 거의 100%가 완전히 명확하게 서명될 수 있어요.

Polkadot은 런타임 메타데이터 시스템(MetadataV14/V15)으로 업계에서 가장 기술적으로 진보된 명확한 서명 솔루션을 개발했어요. 모든 거래는 팔레트와 호출 인덱스를 참조하고, 메타데이터가 해당 인덱스의 의미와 파라미터 해석 방법을 알려줍니다. 단, 전체 메타데이터가 200KB를 넘어 하드웨어 지갑 메모리로는 부담이 돼요. 

해결책으로 RFC-0078 (Merkleized Metadata)가 도입됐어요. 메타데이터를 암호화 트리로 구성해 필요한 부분만 전송하고, 온체인에서 포함 증명을 검증합니다. 이 덕분에 하나의 Ledger 앱으로 모든 Polkadot 패러체인에서 별도 업데이트 없이 작동할 수 있어요.
 

Cosmos는 타입이 명확한 메시지 구조와 SIGN_MODE_TEXTUAL 표준(ADR-050)을 사용해, 작은 화면에서도 사람이 읽을 수 있도록 거래를 표시해요. 코인 금액도 "2 ATOM"처럼 직관적으로 보여줍니다. NEAR Protocol은 사람이 읽을 수 있는 계정명과 JSON 직렬화 함수 파라미터를 통해, 지갑에서 거래 내용을 텍스트로 쉽게 확인할 수 있게 했어요.
 

Tier 2: 기본은 명확, 복잡해지면 불투명

이 단계의 6개 생태계는 기본 거래에서는 명확한 서명을 제공하지만, 스마트 컨트랙트가 도입되면 불투명성이 크게 증가해요. 대표적으로 Bitcoin은 UTXO 모델 특성상 원시 거래에 입력 금액 정보가 없어, 하드웨어 지갑이 수수료 계산을 위해 이전 출력 정보를 추가로 받아야 해요. PSBT (BIP 174)가 표준 이체에는 이 문제를 해결해 전체 거래의 약 90%를 커버하지만, Taproot 스크립트 경로 지출이나 복잡한 멀티시그에서는 여전히 불투명성이 남아요.
 

Stellar는 26가지의 고전적 오퍼레이션(Payment, ManageSellOffer, ChangeTrust 등)이 고정된 스키마로 명확히 표시되지만, 2024년 도입된 Soroban 스마트 컨트랙트에서는 EVM과 유사한 불투명성이 다시 등장해요. 파라미터가 바이너리로 인코딩되어, 컨트랙트별 해석이 필요하고, 고전 오퍼레이션은 약 95%까지 명확하게 표시되지만 Soroban 거래는 거의 불투명하게 처리됩니다. Algorand, Cardano, Aptos, Tezos도 기본 거래는 명확하지만 복잡한 프로그래밍 로직에서는 불투명성이 커요.
 

Tier 3: 구조적으로 불투명한 체인

이 단계의 3개 생태계는 설계상 명확한 서명이 매우 어렵게 되어 있어요. 그래서 대부분의 DeFi 인터페이스에서 블라인드 서명 경고가 항상 표시되는 이유이기도 해요.
 

Ethereum 및 모든 EVM 호환 체인의 핵심 문제는 ABI 인코딩이 자기 기술적(self-describing)이 아니라는 점이에요. 스마트 컨트랙트와 상호작용할 때, 거래 데이터 필드는 함수 이름의 해시 앞 4바이트(function selector)와 32바이트 단위로 인코딩된 파라미터만 담고 있어요. 컨트랙트의 ABI JSON이 없으면, 이 정보는 단순한 16진수 노이즈에 불과합니다. 이 ABI는 온체인에 저장되지 않고, 하드웨어 지갑은 0xa9059cbb...가 "0xABC...에게 1,000 USDC 전송"을 의미하는지 외부 메타데이터 없이는 알 수 없어요.
프록시 컨트랙트는 실행을 구현 컨트랙트로 라우팅하며, 주소가 바뀔 수 있어 문제를 더욱 복잡하게 만드는데, Bybit 해킹도 바로 이 방식을 이용했어요.
 

업계의 대응책은 ERC-7730 메타데이터 표준이에요. 2024년에 만들어진 이 표준은 하드웨어 지갑이 특정 스마트 컨트랙트 상호작용을 해석하고 표시할 수 있도록 JSON 파일로 정보를 제공합니다. 하지만, 모든 컨트랙트에 대해 누군가가 이 메타데이터를 작성·관리해야 하므로, 근본적으로 투명성을 염두에 두고 설계된 구조가 아니라, 임시방편에 가까워요.
 

Solana는 오히려 더 어렵다고 볼 수 있어요. 거래 명령에는 프로그램 ID와 표준화되지 않은 바이트 배열이 포함되고, 각 프로그램이 자체 직렬화 포맷을 정의해요. Anchor 프레임워크는 8바이트 구분자를 활용해 반쯤 표준화된 방식을 제공하지만, 많은 프로그램이 Anchor를 사용하지 않거나 인터페이스 정의를 공개하지 않아요. DeFi 거래의 대부분은 블라인드 서명이 필요합니다. 

TON은 비동기 실행 구조로 복잡성이 더해져요. 최초 메시지에만 서명하고, 이후 여러 블록에 걸쳐 일어나는 모든 일은 서명 시점에 보이지 않아요.

 핵심 요약

실용적 결론은, DeFi에서 하드웨어 지갑을 쓸 때 자신이 사용하는 체인이 어느 단계에 속하는지 반드시 확인해야 한다는 점이에요. Tier 1 체인은 명확한 서명이 정상적으로 작동합니다. Tier 2는 단순 이체는 안전하게 서명할 수 있지만, 복잡한 스마트 컨트랙트 상호작용은 반드시 추가 확인이 필요해요. Tier 3는 DeFi 프로토콜에서 모든 거래를 더욱 신중하게 검토하고, dApp과 지갑이 ERC-7730 메타데이터를 지원하는지 반드시 확인해야 해요.
 

하드웨어 지갑 제조사들도 이 문제를 적극적으로 개선하고 있어요. Ledger의 Generic Parser는 ERC-7730 메타데이터 파일을 읽어, 거래 정보를 안전한 화면에 표시할 수 있게 했어요. 

Polkadot의 Merkleized Metadata 방식은 업계에서 가장 우아한 솔루션으로 평가받아요. 신뢰할 필요 없는(trustless) 암호 검증과 프로토콜 내장 구조 덕분이에요. 업계는 더 나은 표준으로 나아가고 있지만, Tier 3 체인의 근본적인 프로토콜 한계는 당분간 사라지지 않을 거예요.
 

가장 간단한 원칙: 지갑이 해시값이나 16진수 데이터만 보여주고 서명을 요구한다면, 반드시 경계해야 해요.

참고 자료 및 추가 읽을거리

아래 자료에서는 본문에서 다룬 프로토콜과 표준에 대한 기술적 내용을 더 깊이 확인할 수 있어요.