모네로 뷰 키와 스펜드 키 완벽 정리

회계 담당자에게 모네로 입금 내역을 증명해야 하는데, 그렇다고 통째로 지갑 권한을 넘겨줄 수는 없다면 어떻게 해야 할까요? 이 두 키가 해결하는 문제가 바로 그것입니다. 하나의 프라이빗 키로 잔액 조회와 송금 권한이 모두 결정되는 비트코인과 달리, 모네로는 의도적으로 권한을 뷰 키(view key)와 스펜드 키(spend key)로 분리했습니다. 이 분리 덕분에 프라이버시 코인이면서도 필요할 때 감사를 받을 수 있고, 잔액이 공개되는 후원 페이지를 운영할 수 있으며, 자금에 직접 접근하지 않는 가벼운 모바일 지갑이 가능해집니다. 그런데 처음 접하는 분들은 두 키를 혼동하거나, 엉뚱한 입력란에 붙여 넣거나, 하나를 공유하면 다른 하나까지 노출된다고 오해하곤 합니다. 2026년 현재, FCMP++가 테스트넷 로드맵에 올라 있고 MoneroSwapper 같은 거래소가 하루에 수천 건의 KYC 없는 스왑을 처리하는 시점에서, 키 분리에 대한 이해는 더 이상 교과서적 지식이 아닙니다. 깔끔한 감사 기록을 남기느냐, 지갑이 통째로 털리느냐를 가르는 실질적인 문제입니다. 이 글에서는 각 키가 정확히 무엇을 할 수 있는지, 무엇을 할 수 없는지, 그리고 모네로의 암호학적 기본 요소들이 이 두 키 쌍을 어떻게 비트코인의 단일 키 모델로는 구현할 수 없는 무언가로 바꿔놓는지 단계별로 살펴봅니다.

모네로가 프라이빗 키를 두 개로 나눈 이유

모네로의 계정 모델은 2013년 등장한 CryptoNote 프로토콜에서 비롯되었습니다. CryptoNote는 링 서명과 일회성 스텔스 주소를 암호화폐에 도입한 첫 시도였죠. 이 두 기본 요소를 동작시키려면 지갑이 서로 매우 다른 두 가지 일을 해야 합니다. 첫째, 블록체인 전체를 스캔해서 자기 앞으로 온 출력(output)을 식별하는 것. 둘째, 그 출력을 실제로 사용(spend)할 권한을 행사하는 것. CryptoNote 설계자들은 이 스캐닝 역할과 송금 역할을 두 개의 독립적인 스칼라 값으로 분리할 수 있다는 점을 발견했습니다. 둘 다 32바이트 시드에서 파생되지만, 공개된 결과만 놓고 보면 암호학적으로 서로 연결되어 있지 않습니다.

결과적으로 모네로 지갑의 신원은 네 개의 숫자, 즉 프라이빗 스펜드 키, 프라이빗 뷰 키, 그리고 이들의 공개 쌍 두 개로 구성되며, 이들이 연결되어 base58로 인코딩된 것이 우리가 흔히 보는 95자짜리 모네로 주소입니다. 이 분리가 가져다주는 구체적인 이점은 세 가지입니다.

• 선택적 투명성: 국세청, 거래소 컴플라이언스 팀, 또는 자선단체 감사인에게 뷰 키만 넘기면 됩니다. 입금 내역은 확인할 수 있지만, 코인을 움직일 권한은 전혀 갖지 못합니다.
• 경량 클라이언트: 모바일 지갑이나 워치 온리(watch-only) 데스크톱 노드는 잔액만 보여주면 되므로 뷰 키만 있으면 충분합니다. 스펜드 키는 에어갭(air-gapped) 환경에 보관해도 일상적인 사용에 지장이 없습니다.
• 다층 방어: 뷰 키가 유출되면 거래 내역은 노출되지만 자금은 안전합니다. 도난당한 기기에서의 복구는 금전적 손실이 아니라 프라이버시 사고로 격하됩니다.

이 모든 것은 신뢰할 수 있는 제3자나 영지식 증명 확장 없이는 비트코인의 UTXO 모델에서 구현할 수 없습니다. 모네로는 이를 프로토콜 자체에 내장해두었고, 그래서 공식 CLI부터 MoneroSwapper의 호스팅 스왑 엔진까지 모든 모네로 지갑이 두 키를 일급 객체(first-class object)로 노출합니다. 각각을 독립적으로 내보내고, 가져오고, 감사할 수 있다는 뜻입니다.

프라이빗 뷰 키 자세히 보기

프라이빗 뷰 키는 32바이트 스칼라이며, monero-wallet-cli나 Feather Wallet 같은 도구에서는 64자리 16진수 문자열로 표시됩니다. 이 키의 유일한 암호학적 역할은 송신자와 수신자 사이의 공유 비밀(shared secret)을 계산하는 것입니다. 누군가가 여러분에게 XMR을 보낼 때, 송신자는 여러분의 공개 스펜드 키, 공개 뷰 키, 그리고 새로 생성된 임의의 트랜잭션 키를 조합해 일회성 스텔스 주소를 만들어냅니다. 네트워크상의 모든 관찰자에게 이 출력은 그저 잡음처럼 보이지만, 여러분만은 프라이빗 뷰 키로 같은 공유 비밀을 재구성해 "이건 내 것"이라고 알아챌 수 있습니다.

뷰 키가 할 수 있는 일

공개 주소와 프라이빗 뷰 키만 있으면 소프트웨어는 체인을 스캔해서 출력 하나당 세 가지 정보를 복호화할 수 있습니다. 수신자의 스텔스 주소(즉, 이 출력이 내 것이라는 증명), 금액(RingCT 커밋먼트에서 복호화), 그리고 페이먼트 ID(첨부되어 있다면)입니다. 이것만으로 완전한 입금 내역을 재구성할 수 있죠. 기업은 이 방식으로 매출을 모니터링하고, 후원 페이지는 뷰 키를 공개해 누구나 실시간으로 총액을 검증할 수 있게 하며, 세무 소프트웨어는 송금 권한을 전혀 요구하지 않고도 취득원가 보고서를 생성합니다.

뷰 키가 할 수 없는 일

뷰 키로는 트랜잭션에 서명할 수 없습니다. 키 이미지(key image)를 생성할 수도 없고, 따라서 어떤 출력이 이미 사용되었음을 증명할 수도 없습니다. 워치 온리 지갑에서는 사용자가 오프라인 송금 지갑에서 서명된 키 이미지 파일을 가져오기 전까지 출금 트랜잭션이 보이지 않습니다. 가져오는 순간 잔액이 다시 맞춰지죠. 이것이 키 분리가 실제로 작동하는 가장 깔끔한 사례입니다. 뷰 키는 돈이 들어오는 것은 보지만, 그 돈이 나가는 순간 스펜드 쪽이 협조해 키 이미지를 공유하지 않는 한 시야에서 사라집니다.

뷰 키 관련 흔한 실수

가장 자주 발생하는 실수는 니모닉 시드를 입력해야 하는 "지갑 복원" 칸에 뷰 키를 붙여 넣는 일입니다. 지갑은 그것을 받아들여 잘못된 엔트로피로부터 전혀 다른 스펜드 키를 파생시키고, 깔끔해 보이지만 실제 자금은 절대 비치지 않는 빈 지갑을 만들어줍니다. 두 번째 함정은 뷰 키를 공개 페이지에 게시했을 때, 과거와 미래의 모든 입금 트랜잭션이 영구적으로 실명과 연결된다는 사실을 인지하지 못하는 것입니다. 뷰 키는 회전(rotate)되지 않습니다. 한번 새어 나가면 영원히 새어 나간 상태입니다. 은행 명세서를 읽을 수 있는 읽기 전용 API 토큰을 다루듯 신중히 취급하세요. 감사인에게는 유용하지만, 스토커에게는 치명적입니다.

프라이빗 스펜드 키 자세히 보기

프라이빗 스펜드 키는 나머지 32바이트 스칼라이고, 실제로 코인을 통제하는 키입니다. 지갑은 이 하나의 숫자로부터 자기가 소유한 모든 출력의 키 이미지를 파생시키고, 모든 CLSAG 링 서명을 만들어내며, 금액이 음수가 아님을 금액 자체는 노출하지 않고 증명하는 Bulletproofs+ 범위 증명을 생성합니다. 스펜드 키를 잃으면 돈을 잃는 것입니다. 복구도, 고객센터도, 체인 롤백도 없습니다.

스펜드 키가 키 이미지를 만드는 방식

지갑이 받는 각 출력에 대해, 모네로는 키 이미지를 계산합니다. 이는 출력의 일회성 공개 키와 지갑의 프라이빗 스펜드 키 양쪽에 의존하는 결정론적 해시입니다. 키 이미지는 출력마다 유일하지만 스펜드 키 없이는 위조할 수 없기 때문에, 모네로의 이중 지불 방지 메커니즘으로 동작합니다. 트랜잭션이 브로드캐스트되면 검증자는 그 안의 키 이미지들이 체인에 이전에 나타난 적이 없는지 확인합니다. 영리한 점은, 같은 키 이미지를 그것을 만든 지갑과 연결지을 수 없다는 것입니다. 링 서명이 실제 서명자를 디코이(decoy) 집단 속에 숨기기 때문입니다.

스펜드 키와 니모닉 시드

대부분의 사용자는 64자리 원시 16진수 스펜드 키를 직접 보지 않습니다. 대신 25개 단어로 된 니모닉 시드(또는 최신 지갑의 16단어 Polyseed)를 보게 되는데, 이 안에는 스펜드 키와 체크섬, 그리고 생성일(birthday)이 인코딩되어 있습니다. 뷰 키는 스펜드 키를 Keccak-256으로 해싱한 뒤 Ed25519 그룹 차수로 모듈로 환산하는 방식으로 결정론적으로 파생됩니다. 이 파생 관계 덕분에 스펜드 키(또는 그 시드)만 백업하면 전체 지갑을 복원하기에 충분합니다. 뷰 키는 자동으로 따라 나오니까요.

스펜드 키를 절대 공유하지 않는 이유

스펜드 키를 공유하는 것은 잔액 전체와 거래 내역 전체를 한꺼번에 상대방에게 보내는 것과 기능적으로 동일합니다. "지갑 검증 키"나 "전체 복원 키"를 요구하는 피싱 사이트는 거의 예외 없이 스펜드 키나 시드를 노립니다. 정상적인 거래소, 스왑 서비스, 감사 회사라면 절대로 그것을 요구하지 않습니다. 예를 들어 MoneroSwapper는 스왑마다 새로운 통합 주소를 생성하며, 고객의 스펜드 키에는 절대 손대지 않습니다. 입금 트랜잭션은 고객이 자기 지갑에서 직접 서명해 브로드캐스트합니다.

뷰 키 대 스펜드 키 한눈에 비교

아래 표는 실무적 차이를 정리한 것입니다. 어떤 필드, 화면, QR 스캐너에든 두 값 중 하나를 붙여 넣기 전에 체크리스트로 활용하세요.

"다른 키 파생" 행의 비대칭성에 주목하세요. 스펜드 키는 뷰 키를 만들어낼 수 있지만, 그 반대는 불가능합니다. 이 일방향 관계가 바로, 스펜드 키였다면 재앙이 될 상황에서도 뷰 키는 안전하게 공개할 수 있게 만드는 핵심입니다.

워치 온리 지갑 만드는 법, 단계별 안내

이 두 키를 떠올리게 되는 가장 흔한 시나리오는 워치 온리 지갑을 만들 때입니다. 예를 들어 에어갭 처리된 노트북에 보관된 콜드 스토리지 잔액을 모바일에서 모니터링하고 싶은 경우죠. 아래는 공식 monero-wallet-cli를 쓰는 절차입니다. Feather Wallet, Cake Wallet, MyMonero에도 GUI 기반의 동일한 기능이 있습니다.

1. 오프라인 머신에서 전체 지갑을 열고 프롬프트에 viewkey를 입력합니다. 64자리 16진수 문자열을 복사하세요. 이어서 address를 입력해 95자리 기본 주소를 복사합니다. 스펜드 키, 시드, 그 밖의 어떤 것도 내보내지 마세요.
2. 두 문자열을 QR 코드나 에어갭 USB를 통해 온라인 기기로 옮깁니다. 스펜드 키나 시드는 절대 온라인 머신에서 타이핑하지 마세요.
3. 온라인 머신에서 monero-wallet-cli --generate-from-view-key <이름>을 실행합니다. 프롬프트에 주소와 프라이빗 뷰 키를 붙여 넣고, 강력한 지갑 비밀번호를 설정하세요.
4. 자금이 처음 입금된 블록 높이부터 지갑을 동기화하세요. 입금 트랜잭션은 정확한 금액과 함께 표시됩니다. 출금은 키 이미지를 가져오기 전까지 "(unknown sent)"로 표시됩니다.
5. 출금 잔액을 맞추려면 주기적으로 오프라인 지갑에서 export_key_images를 실행하고, 온라인 지갑에서 import_key_images를 실행하세요. 이 과정에서 송금 권한은 전혀 공유되지 않습니다. 특정 출력이 이미 사용되었다는 사실만 전달됩니다.

뷰 키는 "무엇이 들어왔는가?"라는 질문에 답합니다. 스펜드 키는 "무엇이 나갈 수 있는가?"라는 질문에 답합니다. 어떤 서비스가 두 번째 질문에 답하기를 요구한다면, 즉시 자리를 뜨세요. 정직한 워크플로 중 그것이 필요한 경우는 없습니다.

각 키의 실제 활용 시나리오

구체적인 사례를 보면 차이가 더 분명해집니다. XMR 후원을 받는 작은 오픈소스 프로젝트를 생각해봅시다. 운영진은 프로젝트의 투명성 페이지에 기본 주소와 프라이빗 뷰 키를 공개합니다. 누구나 로컬에서 워치 온리 지갑을 띄우고 체인을 동기화한 뒤, 이번 분기에 프로젝트가 얼마를 받았는지 독립적으로 검증할 수 있습니다. 운영진은 스펜드 키를 하드웨어 기기에 단독으로 보관하기 때문에, 어떤 후원자도, 향후 프로젝트를 떠나는 어떤 운영진 멤버도 자금을 빼낼 수 없습니다. 이것이 전형적인 후원 투명성 패턴이고, Monero Community Crowdfunding System이 수년간 사용해온 방식이기도 합니다.

또 다른 시나리오를 봅시다. 자본 통제 보고 요건이 엄격한 국가에서 활동하는 프리랜서 저널리스트가 있다고 합시다. 그는 세무사에게 연간 XMR 수입이 신고 기준 이하임을 입증해야 합니다. 그는 세무사의 감사 노트북에서 자신의 주소와 뷰 키로 워치 온리 지갑을 만들고, 현재 블록까지 동기화한 다음, 복호화된 입금 금액의 CSV를 내보냅니다. 세무사는 총액을 확인하고, 본인은 송금 권한을 그대로 보유합니다. 관계가 끝나면 새 지갑으로 자금을 옮기되, 그것은 세무사가 코인을 움직일 수 있어서가 아니라 단지 깔끔한 분리를 원하기 때문일 뿐입니다.

세 번째 예는 복구 시나리오입니다. 일상에서 쓰는 휴대폰을 도난당했고, 그 폰에는 하드웨어 기반 스펜드 키에서 파생된 워치 온리 지갑이 들어 있었다고 합시다. 절도범은 사용자의 완전한 입금 내역을 손에 넣게 됩니다. 식별 가능한 거래 상대로부터 정기적인 입금이 있었다면 실질적인 프라이버시 손실이지만, 1피코네로(piconero)조차 건드릴 수 없습니다. 사용자는 체인에서 아무것도 폐기하지 않습니다(모네로에는 폐기 기능이 없습니다). 대신 새로운 시드에서 파생된 새 주소로 자금을 옮깁니다. 옛 뷰 키는 그것이 이미 본 거래에 대해서는 영원히 유효하지만, 새 지갑은 그것에 보이지 않습니다.

세 시나리오 모두에서 같은 성질이 성립합니다. 뷰 키는 수령된 금전에 대한 과거 및 현재의 질문에 답하고, 스펜드 키만이 그 금전이 다음에 어디로 갈 수 있는지에 대한 질문에 답합니다. MoneroSwapper의 스왑 흐름도 이 성질에 기반합니다. 고객은 자신이 처음부터 끝까지 통제하는 주소로 XMR을 받고, 플랫폼은 어떤 단계에서도 고객을 대신해 송금할 수 있는 키를 요구하지 않습니다.

서브어드레스와 멀티시그 환경에서의 키 분리

지금까지 설명한 모델은 기본 주소(primary address) 한 개를 기준으로 한 것입니다. 실무에서는 한 지갑이 수십, 수백 개의 서브어드레스(subaddress)를 운영하는 경우가 흔한데, 이때도 키 분리 원칙은 그대로 유지됩니다. 서브어드레스는 인덱스 (i, j)와 프라이빗 뷰 키를 결합해 결정론적으로 생성되며, 외부에서는 서로 무관해 보이지만 같은 스펜드 키 한 개로 통제됩니다. 거래소나 결제 게이트웨이는 고객별로 서브어드레스를 하나씩 발급함으로써 입금 식별 문제를 해결하고, 동시에 모든 서브어드레스의 잔액을 하나의 스펜드 키로 통합 관리합니다.

중요한 점은 서브어드레스를 스캔하려면 프라이빗 뷰 키와 더불어 공개 스펜드 키가 함께 필요하다는 사실입니다. 일반 주소는 공개 스펜드 키 없이도 스캔할 수 있는 변형(deprecated 영어 표현으로 "view-only address")이 있었지만, 서브어드레스 도입 이후 워치 온리 지갑은 항상 공개 스펜드 키를 가지고 있어야 합니다. 다행히 공개 스펜드 키는 이름 그대로 공개해도 무방한 값이므로, 키 분리의 보안 모델 자체는 흔들리지 않습니다.

멀티시그(multisig) 지갑은 한 단계 더 들어갑니다. M-of-N 멀티시그에서는 각 참여자가 자신의 부분 스펜드 키 조각만 보유하고, 어떤 한 사람도 단독으로는 송금 권한을 갖지 못합니다. 그러나 뷰 키는 흔히 모든 참여자에게 공유되어, 누구나 잔액과 입금 이력을 독립적으로 검증할 수 있게 합니다. 이는 DAO 트레저리, 가족 신탁, 거래소 콜드 월렛 같은 상황에서 매우 유용한 패턴입니다. 권한은 분산하되 가시성은 공유하는 것이죠.

국내 사용자가 실무에서 마주치는 상황들

국내에서 모네로를 다룰 때는 가상자산 사업자 신고제와 트래블 룰의 영향을 직접적으로 받습니다. 원화 마켓에서 다크코인 상장 폐지가 이루어진 이후, 많은 사용자가 해외 거래소나 KYC 없는 스왑 서비스로 옮겨갔는데, 이때 뷰 키와 스펜드 키의 차이를 명확히 이해하지 못한 채 자금을 옮기다 사고가 나는 사례가 보고되고 있습니다. 특히 텔레그램이나 비공식 커뮤니티에서 "지갑 점검"을 명목으로 시드나 스펜드 키를 요구하는 피싱 시도가 자주 관측됩니다.

국세청이 가상자산 양도소득세 과세를 본격 시행한 이후에는, 입금 내역 증빙을 위해 뷰 키를 활용하는 방식이 합리적인 선택지로 자리 잡았습니다. 신고 대리인이나 세무사에게 스펜드 키나 시드를 넘기는 것은 절대 피해야 하지만, 뷰 키 하나만 공유해 입금 총액을 검증받는 것은 위험 없이 가능한 워크플로입니다. 사용자가 직접 워치 온리 지갑을 띄워 CSV로 내보낸 자료를 제출하는 것도 좋은 선택입니다. 자료의 출처가 명확하고, 향후 세무 조사에서도 재현 가능성을 입증하기 쉽기 때문입니다.

한 가지 덧붙이자면, 국내 일부 커뮤니티에서는 "콜드 월렛" 개념을 단순히 오프라인 저장으로만 이해하는 경우가 많습니다. 모네로 맥락에서 진정한 콜드 스토리지는 스펜드 키가 평생 오프라인에 머무는 상태를 의미합니다. 뷰 키가 온라인 기기에 올라가 있어도, 그 자체로 자금에 영향을 주지 않으므로 콜드 월렛의 정의를 깨뜨리지 않습니다. 이 점을 분명히 해두면 보관 전략을 설계할 때 혼란이 줄어듭니다.

자주 묻는 질문

뷰 키만 가지고 누가 제 모네로를 훔칠 수 있나요?

아니요. 뷰 키는 입금 트랜잭션과 금액을 볼 수 있는 권한만 부여할 뿐, 서명, 키 이미지 생성, 자금을 움직이는 어떤 동작도 할 수 없습니다. 뷰 키 유출은 프라이버시 문제입니다. 과거와 미래의 모든 입금이 그것을 보유한 사람에게 노출되지만, 자금 자체는 여전히 스펜드 키에 의해서만 통제됩니다.

워치 온리 지갑에서 출금 트랜잭션이 왜 안 보이나요?

출금 트랜잭션은 키 이미지를 매칭해서 감지되는데, 키 이미지는 프라이빗 스펜드 키에서만 생성할 수 있기 때문입니다. 워치 온리 지갑은 출력이 존재한다는 사실은 알지만, 그 출력이 그 이후 사용되었는지는 알 수 없습니다. 송금 지갑에서 서명된 키 이미지 파일을 가져오면 이 간극이 메워지고 잔액이 다시 맞춰집니다.

뷰 키는 스펜드 키에서 파생되나요, 아니면 독립적인가요?

표준 모네로 지갑에서는 뷰 키가 스펜드 키를 Keccak-256으로 해싱하고 Ed25519 그룹 차수로 모듈로 환산해 결정론적으로 파생됩니다. 그래서 25단어 니모닉 시드가 스펜드 키만 인코딩하면 충분합니다. 뷰 키는 자동으로 따라 나오니까요. 고급 설정에서는 독립적인 뷰 키를 쓰기도 하지만, 일반 소비자용 지갑은 모두 파생 형태를 사용합니다.

두 키를 따로 백업해야 하나요?

시드(또는 원시 스펜드 키)만 백업하면 충분합니다. 뷰 키는 언제든 거기서 재생성할 수 있기 때문이죠. 다만 많은 사용자가 뷰 키 사본을 감사인이 접근 가능한 별도 위치에 보관합니다. 이렇게 해도 보안 수준이 약해지지 않기 때문입니다. 시드는 현금처럼, 뷰 키는 읽기 전용 은행 명세서처럼 다루세요.

뷰 키가 새면 회전할 수 있나요?

단독으로는 불가능합니다. 뷰 키는 수학적으로 주소에 묶여 있기 때문에, 회전하려면 새 지갑(새 시드, 새 스펜드 키, 새 주소)을 생성하고 자금을 그쪽으로 옮겨야 합니다. 해당 지갑의 수명 동안 뷰 키 유출은 영구적인 프라이버시 사건으로 받아들이고, 노출 정도가 견딜 수 없게 커질 경우의 마이그레이션 비용을 미리 염두에 두세요.

Ledger나 Trezor 같은 하드웨어 지갑은 스펜드 키를 다르게 처리하나요?

네. Monero 앱이 동작하는 Ledger나 Trezor에서는 스펜드 키가 보안 요소(secure element) 밖으로 절대 나가지 않습니다. 호스트 컴퓨터는 뷰 키만 가지고 있어 체인을 스캔하고, 서명되지 않은 트랜잭션을 기기로 보내면 기기 내부에서 서명이 이루어집니다. 이것이 키 분리의 가장 깔끔한 물리적 구현입니다. 뷰 키는 편의성이 필요한 곳에 살고, 스펜드 키는 보안이 필요한 곳에 삽니다.

뷰 키만 가져오면 어떤 지갑 앱이라도 잔액을 볼 수 있나요?

대체로 그렇습니다. Feather Wallet, Cake Wallet, MyMonero, 공식 monero-wallet-cli 모두 주소와 프라이빗 뷰 키만으로 워치 온리 지갑을 만들 수 있는 옵션을 제공합니다. 다만 동기화 시 지갑의 "재시작 높이(restore height)"를 자금이 처음 입금된 시점 근처로 지정해주는 것이 좋습니다. 그렇지 않으면 제네시스 블록부터 스캔하느라 수 시간이 걸릴 수 있습니다. 또한 서브어드레스를 사용하는 경우, 일부 구형 클라이언트는 공개 스펜드 키를 추가로 요구하므로 주의가 필요합니다.

FCMP++가 도입되면 키 분리 모델이 바뀌나요?

핵심 모델은 바뀌지 않습니다. FCMP++(Full-Chain Membership Proofs)는 링 서명을 더 강력한 멤버십 증명으로 대체하지만, 뷰 키와 스펜드 키의 역할 분담 자체는 그대로 유지됩니다. 다만 키 이미지 생성 방식이 변경되어, 양자 내성 가능성과 더 큰 익명성 집합을 동시에 제공할 것으로 기대됩니다. 사용자 입장에서 바뀌는 점은 거의 없으며, 기존 워치 온리 워크플로는 그대로 작동할 예정입니다.

결론

뷰 키와 스펜드 키는 같은 비밀의 절반씩이 아닙니다. 서로 다른 두 가지 일을 하는 두 개의 별개 비밀이고, 모네로 프로토콜은 이 둘을 합치기를 거부함으로써 가장 유용한 성질들을 얻어냅니다. 이 분리가 머릿속에서 한번 클릭되면, 워치 온리 지갑, 감사 워크플로, 후원 투명성, 하드웨어 지갑 아키텍처가 모두 영리한 임시방편처럼 보이지 않고, 사려 깊은 설계의 당연한 귀결처럼 느껴집니다. 오늘 새 지갑을 설정한다면, 시드를 오프라인에 적어두고, 송금이 필요 없는 기기에는 뷰 키만 두고, 정확한 용도를 알 수 없는 입력란에는 어느 쪽 값도 절대 붙여 넣지 마세요. 그 지갑에 XMR을 채울 준비가 됐다면, MoneroSwapper는 주요 자산에서 KYC 없이 여러분이 통제하는 주소로 직접 스왑을 제공합니다. 이 흐름의 어느 시점에서도 그 어떤 키도 요구하지 않습니다. 이 글을 다 읽은 지금이라면, 그것이야말로 쓸 만한 서비스에서 당연히 기대해야 할 행동이라는 점을 아실 겁니다.