읽기 전용 지갑이란? 잔액 조회와 서명 권한의 차이

읽기 전용 지갑은 주소·스크립트 또는 확장 공개키를 가져와 잔액과 거래를 추적하지만, 해당 코인을 지출할 개인키는 보관하지 않는 구성입니다. 그래서 거래 초안을 만들 수 있어도 서명은 별도 서명 장치가 해야 합니다. 다만 자금 이동 권한이 없다는 사실이 개인정보까지 안전하다는 뜻은 아닙니다.

볼 수 있는 정보와 쓸 수 있는 권한을 분리한다

읽기 전용 지갑은 블록체인의 주소와 거래를 찾아 잔액을 계산하지만 그 출력의 잠금 조건을 풀 개인키는 가지고 있지 않습니다. 회계 담당자가 거래 흐름을 확인하거나, 인터넷에 연결된 컴퓨터에서 수신 주소와 잔액을 관리하면서 서명 키는 하드웨어 지갑에 둘 때 유용합니다. 기기를 잃거나 악성 코드가 실행돼도 읽기 전용 데이터만 있었다면 그 정보만으로 즉시 정상 서명을 만들 수는 없습니다.

'읽기 전용'은 앱 화면의 기능 제한만을 뜻해서는 안 됩니다. 가져온 데이터가 주소 한 개의 공개 정보인지, 여러 주소를 파생할 수 있는 확장 공개키인지, 지출 조건을 설명하는 디스크립터인지 확인해야 합니다. 개인키가 포함된 디스크립터를 잘못 가져오면 이름은 감시용이어도 실제 지출 키가 온라인 기기에 존재할 수 있습니다. 가져오기 전에는 키 자료의 범위를 확인하고 백업본과 화면 캡처에 개인 정보가 남지 않게 관리합니다.

주소 하나와 확장 공개키는 노출 범위가 다르다

주소 하나를 감시 목록에 넣으면 일반적으로 그 주소와 관련된 거래만 추적합니다. 반면 확장 공개키는 파생 경로에 따라 많은 하위 공개키와 주소를 계산할 수 있습니다. BIP 32는 확장 공개키로 비 hardened 하위 공개키를 파생할 수 있는 구조를 정의합니다. 상점 서버가 주문마다 새 수신 주소를 만들면서도 지출 키를 가지지 않는 구성이 가능한 이유입니다.

이 편리함은 개인정보 비용을 동반합니다. 확장 공개키를 아는 서비스는 관련 주소를 묶어 잔액과 거래 패턴을 관찰할 수 있습니다. 비밀번호처럼 코인을 직접 훔치는 비밀은 아니지만 공개 게시하거나 출처 불명의 포트폴리오 앱에 넣어도 되는 값은 아닙니다. 계정별 xpub을 공유할 때도 어느 계정과 체인까지 드러나는지 확인합니다.

지출 권한이 없다는 말은 거래 프라이버시까지 보호된다는 뜻이 아니다.

JOBCOIN 해설

디스크립터는 무엇을 감시할지 더 정확히 표현한다

출력 디스크립터는 공개키만이 아니라 어떤 스크립트 형태로 주소와 출력을 만들지 함께 설명합니다. 예를 들어 같은 키 자료라도 전통 주소, 네이티브 세그윗, 멀티시그처럼 감시해야 할 출력 조건이 다릅니다. Bitcoin Core의 getaddressinfo는 주소가 watch-only인지, 지갑이 해당 주소를 solvable로 아는지 같은 정보를 제공하고 디스크립터 표현도 반환할 수 있습니다.

solvable은 지갑이 필요한 스크립트 구조를 알고 거래 구성에 활용할 수 있다는 뜻이지 개인키를 보유해 서명할 수 있다는 뜻은 아닙니다. spendable, iswatchonly, solvable 같은 상태를 분리해서 읽어야 합니다. 읽기 전용 지갑이 거래 초안을 만들 수 있어도 최종 서명은 키를 보유한 장치에서 이뤄져야 하며, 장치 화면에서 받는 주소와 금액을 다시 확인해야 합니다.

• 가져올 자료에 개인키가 포함됐는지 확인한다.
• 주소 유형과 파생 경로가 원래 지갑과 같은지 확인한다.
• watch-only와 spendable 상태를 구분한다.
• 서명 장치 화면에서 수취 주소·금액·수수료를 대조한다.

잔액이 보이지 않을 때 점검할 순서

읽기 전용 지갑에 자료를 가져왔는데 잔액이 0이라면 먼저 네트워크를 확인합니다. 메인넷 자료를 테스트넷에서 보면 같은 결과를 기대할 수 없습니다. 다음으로 주소 유형과 파생 경로, 계정 번호, 외부·거스름돈 체인을 확인합니다. 과거 거래보다 늦은 시점부터 스캔하도록 설정했다면 생성 시간 또는 재검색 시작 높이도 조정해야 할 수 있습니다.

주소 몇 개를 직접 대조하는 방법이 가장 명확합니다. 원래 지갑에서 과거에 사용한 수신 주소와 읽기 전용 지갑이 처음 파생한 주소가 일치하는지 봅니다. 일치하지 않는다면 블록 동기화 문제로 단정하지 말고 키 출처와 경로부터 수정합니다. 일치하지만 거래가 보이지 않는다면 노드의 동기화 상태, 프루닝 범위, 탐색 서버 연결 상태를 확인합니다.

오프라인 서명 흐름에서도 검증이 필요하다

일반적인 흐름은 온라인 읽기 전용 지갑에서 입력·출력·수수료가 담긴 거래 초안을 만들고, 이를 QR 코드나 파일로 서명 장치에 옮긴 뒤, 서명된 거래를 온라인 기기로 되돌려 방송하는 방식입니다. PSBT 같은 형식은 이 역할 분리를 지원합니다. 그러나 오프라인 장치가 서명한다고 해서 온라인 화면이 제시한 수취 주소가 자동으로 신뢰되는 것은 아닙니다.

서명 장치는 신뢰할 수 있는 자체 화면에서 최종 수취 주소와 금액, 수수료를 보여 줘야 합니다. 변경 출력도 본인 지갑으로 돌아오는지 확인할 수 있어야 합니다. 온라인 기기의 악성 코드가 거래 초안을 바꿨다면 별도 화면 대조가 마지막 방어선입니다. QR 코드가 크거나 여러 조각으로 나뉘어도 내용을 생략한 채 승인하지 않습니다.

읽기 전용 자료도 백업과 폐기 기준을 세운다

읽기 전용 지갑 파일은 개인키 지갑보다 위험도가 낮지만 자산 규모와 거래 상대를 드러낼 수 있습니다. 클라우드 동기화, 분석 서비스, 브라우저 확장 프로그램에 자료를 중복 저장하면 노출 지점이 늘어납니다. 누가 어떤 목적으로 감시 자료를 보유하는지 기록하고, 더 이상 쓰지 않는 기기에서는 앱의 안전한 제거 절차와 운영체제 저장소를 확인합니다.

백업에는 주소 유형, 디스크립터 체크섬, 파생 범위, 생성 시점 같은 복구 정보도 포함하는 것이 좋습니다. 다만 공개키 백업만으로는 자금을 지출할 수 없으므로 개인키 또는 시드의 독립 백업을 대체하지 않습니다. 조회 체계와 서명 체계가 각각 복구 가능한지 따로 시험해야 읽기 전용 구조가 실제 장애 상황에서도 작동합니다.

자주 묻는 질문