Zcash 실드 풀, 통합 주소, 뷰잉 키 이해하기

Zcash에서 풀(pool)은 누군가 맡아 보관하는 계좌나 거래소 지갑을 뜻하지 않습니다. 합의 규칙이 서로 다르게 추적하는 가치 상태를 가리킵니다. 투명 풀의 기본 단위는 UTXO입니다. 블록체인에서 어떤 공개 출력이 어느 거래에 만들어졌고, 언제 어떤 출력에 소비되었는지와 금액을 읽을 수 있습니다. 주소 문자열이 실명은 아니어도, 입출력 연결과 공개된 주소 사용은 원장에 남습니다.

실드 풀은 UTXO 대신 노트(note)라는 가치 기록을 사용합니다. 네트워크는 노트의 내용을 암호화해 기록하면서 약정(commitment) 트리와 풀 잔액 규칙을 검증합니다. 따라서 “실드되었다”는 말은 거래 검증이 없어졌거나 자금이 별도 보관처로 옮겨졌다는 뜻이 아닙니다. 합의는 계속 금액 보존과 이중 지불 방지를 확인하지만, 일반 관찰자가 수신 주소와 노트 금액을 그대로 읽을 수 없도록 공개 데이터 표현을 바꾼 것입니다. Zcash 프로토콜 명세는 투명 UTXO 풀과 실드 노트 풀을 각각 정의합니다.

Zcash는 여러 세대의 실드 프로토콜을 거쳤습니다. Sapling과 Orchard는 서로 별개의 실드 풀과 노트 약정 트리를 사용하므로, 두 풀의 실드 상태를 하나의 통으로 취급하지 않습니다. Sprout는 과거 실드 주소와 거래에 쓰였지만, ZIP 211이 활성화된 뒤 Sprout 풀에 새 가치를 추가하는 입금은 허용되지 않습니다. 현재 Mainnet에서 보통 새로 받는 Unified Address 수신자는 Orchard 또는 Sapling이며, 투명 수신자가 함께 들어갈 수도 있습니다.

날짜가 붙은 프로토콜 상태도 확인해야 합니다. Zcash ZIP 색인에 따르면 NU6.2는 2026년 6월 3일 Mainnet 블록 3,364,600에서 활성화되어 가장 최근 정착된 업그레이드입니다. Orchard 임시 취약점 완화 조치로 거래의 Orchard 액션이 잠시 금지되었지만, NU6.2에서 수정된 회로 규칙과 함께 다시 허용되었습니다. 반면 NU6.3은 현재 초안이며, 그 제안에는 Ironwood 풀 도입과 Orchard에서 Ironwood로의 변경이 포함됩니다. 이 초안의 동작을 현재 Mainnet의 규칙처럼 설명하면 안 됩니다. ZIP 257은 NU6.2의 Orchard 재활성화를, ZIP 색인과 ZIP 258은 최신 확정 업그레이드와 NU6.3 초안 상태를 기록합니다.

실드 수신자는 풀 안에 보유할 가치와 수신 권한이 결합된 노트를 받습니다. 노트의 값, 수신자 정보와 메모 같은 내용은 해당 수신 정보를 아는 지갑이 복호화할 수 있도록 암호화됩니다. 블록체인에는 노트 평문 대신 암호화된 데이터와 그 노트의 약정이 기록됩니다. 약정은 노트 내용을 공개하지 않고도 유효한 노트가 생성되었다는 사실을 합의에서 확인할 수 있게 해 주는 암호학적 요약입니다.

노트를 쓸 때는 그 노트에 대응하는 nullifier가 공개됩니다. 노트를 아는 사용자는 어떤 노트를 소비하는지 증명하면서 nullifier를 내놓고, 네트워크는 동일한 nullifier가 다시 쓰이지 않도록 검사합니다. 관찰자는 nullifier와 약정 트리를 볼 수 있지만 보통 어느 과거 약정이 그 nullifier와 연결되는지는 알아내지 못해야 합니다. 이 구조가 이중 지불을 막으면서 주소와 금액의 직접 연결을 숨깁니다. 모든 해시나 커밋먼트가 비밀이라는 뜻은 아니며, Zcash 프로토콜은 검증 가능한 공개 기록과 복호화 권한을 함께 둡니다.

Sapling과 Orchard는 같은 상위 아이디어를 공유하지만 서로 다른 프로토콜과 암호학적 구성요소를 사용합니다. 따라서 지갑이 어느 풀을 지원하는지, 어떤 종류의 증명과 주소를 처리하는지 확인해야 합니다. 노트는 사용자의 지갑 백업이나 보기 권한 없이 풀 안에서 임의로 움직이는 공용 잔고가 아닙니다. 해당 노트를 만들 수신 주소에 대응하는 개인 지출 권한이 있어야 소비할 수 있습니다.

Unified Address(UA)는 여러 Receiver 항목을 하나로 인코딩하는 주소 형식입니다. ZIP 316의 현재 Revision 0 주소는 일반적으로 u로 시작하며, Orchard, Sapling, 투명 P2SH/P2PKH 수신자 중 하나 이상을 담을 수 있습니다. Rev 0 UA는 실드 수신자를 적어도 하나 포함해야 합니다. 문자열 자체는 사람이 눈으로 구성된 수신자 종류를 확인하도록 설계되지 않았으므로, 접두어나 길이를 보고 어떤 풀이 포함되었다고 단정하지 마세요. ZIP 316은 Unified Address와 Unified Viewing Key의 현재 활성 Revision 0 및 향후 제안 형식을 구분합니다.

송신 지갑은 UA의 모든 Receiver를 무조건 사용하지 않습니다. ZIP 316의 Revision 0 우선순위는 Orchard, Sapling, 투명 P2SH, 투명 P2PKH 순입니다. 송신자는 UA에 포함되어 있고 자신이 지원하는 수신자 중 가장 우선순위가 높은 것을 사용해야 합니다. 예를 들어 지갑이 Orchard를 지원하고 해당 UA에 Orchard 수신자가 있으면 보통 Orchard 쪽으로 보내야 합니다. Orchard를 지원하지 않지만 Sapling을 지원하면 Sapling을 고를 수 있습니다. 어떤 전송이 만들어지는지는 주소 문자열만이 아니라 송신 지갑의 지원 범위에 달려 있습니다.

ZIP 316 Revision 2에는 zu 실드 전용 주소와 tu 투명 수신자를 포함할 수 있는 형식이 제안되어 있지만, ZIP 색인의 현재 표시는 Rev 2가 Draft라는 것입니다. 현재 주소 설명에서 이 접두어 형식을 이미 일반적인 Mainnet UA 동작인 것처럼 소개하지 않습니다. 지갑이 보여 주는 주소 유형, 선택한 네트워크, 송신 시 표시되는 수신 풀을 함께 확인하는 편이 안전합니다.

투명 풀에서 실드 풀로 들어가는 전송(t→z)은 공개 UTXO를 소비하는 단계와 Sapling 또는 Orchard 노트를 만드는 단계를 결합할 수 있습니다. 원장 관찰자는 공개 입력과 투명 풀의 변화, 실드 풀의 순증가 같은 경계 정보를 확인할 수 있습니다. 다만 실드 출력의 일반 수신 주소나 각 노트의 금액을 투명 UTXO처럼 그대로 읽지는 못합니다. 사용자가 “자금을 숨겼다”고 해도 자금이 어느 시점에 실드 풀로 넘어왔는지에 대한 흔적은 남습니다.

실드 풀에서 투명 풀로 나가는 전송(z→t)은 반대쪽 경계를 드러냅니다. 투명 출력 주소와 금액이 공개되어 해당 시점과 연결된 실드 풀의 가치 변화도 관찰할 수 있습니다. 실드 풀 안에서 새 수신 노트를 만드는 전송(z→z)은 수신자와 세부 금액을 공개하지 않을 수 있지만, 서로 다른 Sapling과 Orchard 풀 사이에서 가치가 이동하면 풀별 잔액 변화가 알려 줄 수 있는 정보가 달라집니다. 경계에 공개된 값은 바로 특정 사람이나 기존 노트를 가리키는 증거는 아니어도, 금액·시점·외부 기록과 결합될 수 있습니다.

그러므로 “주소가 실드형인가?”만 묻지 말고 자금이 어떤 풀에서 출발해 어디로 가는지도 확인해야 합니다. 거래소 출금, 상점 결제, 개인 지갑 이동처럼 외부에서 시각이나 금액을 아는 상대가 있으면 풀 경계의 공개 정보와 비교할 수 있습니다. 풀 이동은 암호화된 실드 노트 세부 정보와 공개 투명 기록을 이어주는 연결점이 될 수 있지만, 그 사실만으로 모든 노트 소유자나 내부 수신 경로가 밝혀지는 것은 아닙니다.

ZIP 316은 Viewing Key를 주소로 향하는 지급을 볼 수 있도록 필요한 정보로 정의합니다. Full Viewing Key(FVK)는 해당 주소에서 나가는 정보도 볼 수 있고, Incoming Viewing Key(IVK)는 FVK에서 파생될 수 있으며, 주소는 IVK에서 파생될 수 있습니다. Unified Viewing Key는 여러 프로토콜의 보기 키를 묶는 구조입니다. 지갑이나 회계 시스템에 키를 내보내면 감춰진 입금이나 지출 흐름의 일부가 다른 곳에 보일 수 있으므로, 어떤 권한을 공유하는지부터 이해해야 합니다.

Viewing Key만으로는 해당 자금을 서명해 쓸 수 없습니다. 지출 권한은 별도의 spending key 또는 이를 보유한 서명 시스템에 있습니다. 그렇다고 보기 키를 공개 데이터처럼 다뤄도 된다는 뜻은 아닙니다. 키의 종류와 지갑 구현에 따라 볼 수 있는 거래 범위가 다르고, 상위 보기 키는 단일 입금 주소보다 훨씬 넓은 기록을 드러낼 수 있습니다. 외부 감사자나 회계 담당자에게 제공하기 전에 범위, 보관 기간, 삭제 가능성, 다른 주소와의 결합 여부를 확인하세요.

또한 보기 키는 체인의 모든 사생활 단서를 지우지 않습니다. 투명 풀의 입력과 출력은 원래 공개되어 있고, 제3자는 보기 키 없이도 금액·시간·공개 주소를 분석할 수 있습니다. 반대로 수신 풀의 상세 내용은 적절한 키가 있어도 지원하지 않는 탐색기나 지갑에서 자동으로 표시되지 않을 수 있습니다. “지갑에 안 보인다”는 것과 “체인에 없다”는 것을 혼동하지 마세요.

Zcash는 풀과 수신자 종류에 따라 공개되는 내용이 달라지는 프라이버시 프로토콜입니다. 투명 거래만 사용하는 흐름은 주소, 금액, UTXO 연결을 공개합니다. 실드 풀 안의 지급은 노트 수신자와 값이 암호화되지만, 블록에 약정과 nullifier, 시간과 프로토콜 데이터까지 사라지는 것은 아닙니다. 실드 전후의 경계 거래, 지원되는 풀, 상대가 아는 결제 시점, 거래소의 입출금 기록, 지갑이 공개한 보기 키는 별도 분석 단서를 만들 수 있습니다.

Unified Address도 그 자체가 모든 수신을 Orchard로 보내는 강제 스위치는 아닙니다. 지갑이 어떤 Receiver를 구현했는지와 버전, 사용자 설정, 거래 방식에 따라 실제로 선택되는 풀이 달라질 수 있습니다. 따라서 보내기 화면에서 주소를 붙여 넣는 것만으로 프라이버시 속성을 추정하지 말고, 거래 미리보기나 최종 결과에서 수신 풀을 확인합니다. [Monero 프라이버시 가이드](/ko/learn/monero-private-transactions-stealth-addresses-ring-signatures-ringct-explained)는 다른 체인의 프로토콜별 프라이버시 설계를 다루며, [Bitcoin 주소 재사용 가이드](/ko/learn/bitcoin-address-reuse-privacy-transaction-linkability-explained)는 공개 원장의 주소 연결 문제를 비교하는 데 도움이 됩니다.

네트워크 프라이버시도 따로 고려해야 합니다. RPC 사업자, 라이트월렛 서버, 거래소 또는 결제 서비스가 거래 생성이나 전송 요청을 본다면 계정과 IP, 결제 요청 시각 등 체인 밖 단서를 보유할 수 있습니다. 암호학적 증명은 그러한 사업자 로그를 자동으로 삭제하지 않습니다. 특정한 익명성 수준을 보장한다고 단정하기보다는 누구에게 어떤 메타데이터를 공개했는지와 해당 서비스의 보관 방식을 확인하는 편이 낫습니다.

먼저 지갑의 네트워크가 Mainnet인지 Testnet인지 확인하고, 송신 화면에서 받는 주소가 Unified Address인지, 어떤 Receiver가 선택되는지 확인합니다. 주소를 표시한 문자열만 보고 Orchard, Sapling 또는 투명 수신자를 직접 판독할 수 없으므로, 지갑이 보여 주는 수신 유형과 금액·메모·수수료 정보를 읽습니다. 수신자가 실드형 주소를 원한다고 했는데 송신 지갑이 투명 출력을 선택한다면, 전송 전에 두 지갑의 지원 프로토콜을 확인해야 합니다.

기존 거래를 조사할 때는 트랜잭션 식별자와 네트워크를 일치시킨 뒤 어떤 풀이 입력·출력에 포함되었는지 확인합니다. 투명 입력·출력의 주소와 값은 공개 탐색기에서 볼 수 있지만, 탐색기가 지원하지 않는 실드 노트 세부 정보는 표시되지 않을 수 있습니다. 보기 키를 사용해 확인해야 하는 경우에는 키가 필요한 이유와 범위를 확인하고, 개인 키나 보기 키를 불명확한 사이트에 붙여 넣지 않습니다. 자체 보관 지갑 여부를 포함한 서명 책임은 수탁형·비수탁형 지갑 안내도 참고할 수 있습니다.

“실드 주소로 보냈으니 완전히 비공개다” 또는 “탐색기에 값이 없으니 전송되지 않았다”는 식의 결론을 피합니다. 지갑의 로컬 기록, 네트워크, 거래 식별자, 체인 상태, 확인 수준, 필요한 보기 권한을 나누어 점검하면 원인을 더 정확히 좁힐 수 있습니다. 상대방의 수신 확인이 필요하면 체인 분석 화면만 신뢰하지 말고, 수신 지갑이 해당 풀을 지원하고 동기화되었는지 따로 확인합니다.

가령 Lee가 투명 UTXO에서 1.25 ZEC를 보내고, 상대의 Rev 0 Unified Address에는 Orchard, Sapling, 투명 수신자가 들어 있다고 가정합니다. 이 금액은 설명을 위한 가정이며, 수수료율이나 특정 지갑의 기본 설정을 뜻하지 않습니다. 송신 지갑이 Orchard를 지원하면 ZIP 316의 우선순위 규칙에 따라 Orchard Receiver를 선택합니다. 공개 원장에서는 투명 입력과 실드 풀로 이동한 순가치 같은 경계 정보를 확인할 수 있지만, 수신자의 실드 노트 주소와 값은 일반 공개 출력처럼 읽히지 않습니다.

송신 지갑이 Orchard를 지원하지 않고 Sapling을 지원한다면 Sapling Receiver가 선택될 수 있습니다. 지갑이 실드 풀을 전혀 지원하지 않는 경우라면 투명 Receiver를 쓸 수 있지만, 그런 UA를 새로 만들 수 있는지와 주소 형식은 네트워크 업그레이드 및 지갑 구현의 현재 지원 여부에 달려 있습니다. 기존 Rev 0 UA에는 적어도 하나의 실드 Receiver가 있어야 하지만 송신자는 자기가 지원하는 Receiver만 선택합니다. 동일한 UA에 대한 지급이라도 송신 지갑 지원 범위에 따라 기록되는 풀과 보이는 경계 정보가 달라질 수 있습니다.

마지막으로 수신자가 보기 키를 별도 회계 서비스와 공유했다면 그 서비스는 자신의 권한 범위에 포함되는 실드 거래를 확인할 수도 있습니다. 반면 송신 지갑이 자체 영수증을 보여 주는 것, 탐색기가 실드 노트를 표시하지 않는 것, 블록체인에서 거래가 합의에 따라 기록된 것은 서로 다른 사실입니다. Unified Address는 여러 세대의 수신자를 편리하게 전달하지만, 완전한 프라이버시를 보증하거나 지갑의 선택·키 관리·네트워크 노출 책임을 대신하지 않습니다.

예를 들어 공개된 거래소 출금 시각과 비슷한 시각에 실드 풀 잔액이 늘었다고 해도, 그 둘이 같은 출처라고 체인 규칙만으로 증명되는 것은 아닙니다. 그러나 상대방이 1.25 ZEC라는 금액과 시각을 이미 알고 있고 그 금액이 풀 경계 데이터와 일치한다면, 여러 관찰 정보를 결합해 후보를 좁힐 수 있습니다. 반대로 서로 다른 전송이 같은 풀 변화를 공유하거나 지갑이 수수료와 잔돈을 다르게 처리하면 하나의 공개 숫자만으로 연결을 확정할 수 없습니다. 프라이버시를 평가할 때는 공개 정보의 양뿐 아니라 외부 관찰자가 이미 가진 거래 내역과 서비스 기록도 함께 고려해야 합니다.

• Zcash Protocol Specification v2026.7.0 (NU6.2)
• ZIP 316: Unified Addresses and Unified Viewing Keys
• ZIP 211: Sprout 풀에 새 가치 추가 비활성화
• ZIP 257: NU6.2 및 Orchard 임시 완화 조치
• ZIP 258: NU6.3 배포 초안
• Zcash ZIP 색인: Mainnet 활성화 및 ZIP 상태