Monero Pruned Node 설정 가이드: 2026년 디스크 60GB 절약하기

2026년 5월 현재 Monero 블록체인의 디스크 점유량은 약 215GB에 달합니다. 2025년 11월 하드포크로 FCMP++가 메인넷에 활성화되고, 그 직후 수 주 동안 일일 트랜잭션 수가 6만 건을 넘기면서 체인이 가파르게 성장한 결과입니다. 256GB SSD가 달린 노트북, 저가형 NVMe 햇을 단 Raspberry Pi 5, 혹은 트래픽 종량제 VPS에서 노드를 운영하는 사용자에게 풀 아카이브 동기화는 더 이상 가벼운 결정이 아닙니다. Pruned Node는 이 문제를 우아하게 해결합니다. 과거 링 서명 데이터의 약 3분의 2를 폐기하면서도 모든 블록 헤더, 모든 트랜잭션 출력, 그리고 전체 체인을 로컬에서 신뢰 없이 검증할 수 있는 능력은 고스란히 유지하기 때문입니다. 그 결과 215GB가 아니라 약 85~95GB만 차지하는 완전히 주권적인 Monero 데몬이 됩니다. 여전히 RPC를 통해 지갑에 서비스를 제공하고, 여전히 P2P 스웜에 참여하며, 여전히 Dandelion++를 통해 본인의 트랜잭션을 브로드캐스트합니다. 메타데이터를 낯선 사람의 원격 데몬에 흘리지 않으면서 말입니다. 본 가이드는 Linux, Windows, macOS, 그리고 헤드리스 Raspberry Pi에서 Pruned Node를 배포하는 방법을 정확하게 안내합니다. 재부팅에도 살아남는 systemd 유닛 파일, RPC 포트를 보호하는 방화벽 규칙, 그리고 언젠가 반드시 발생할 데이터 손상에 대비한 재동기화 복구 절차까지 모두 다룹니다. MoneroSwapper로 KYC 없는 스왑을 마친 뒤 이 글을 발견했든, 첫 독립 노드를 막 구축하려는 단계든 도착지는 동일합니다. 디스크는 덜 쓰되, 프라이버시는 한 치도 잃지 않는 것입니다.

왜 Remote Node 대신 Pruned Node를 운영해야 하는가

제약이 많은 장치에서는 노드 운영 자체를 건너뛰고 node.moneroworld.com 같은 커뮤니티 노드나 Monero 포럼에 게시된 .onion 엔드포인트로 지갑을 연결하고 싶은 유혹이 듭니다. 기술적으로는 가능합니다. 하지만 그 순간 해당 노드 운영자는 여러분 지갑이 어떤 트랜잭션을 스캔하는지, 몇 시에 온라인이 되는지, 그리고 트래픽 상관관계 분석을 통해 어떤 출력이 본인 것인지에 대한 합리적인 추정까지 모두 로그로 확보하게 됩니다. Remote Node는 view key나 spend key를 볼 수 없는 것이 맞습니다. 그러나 행동 패턴 기반의 핑거프린트는 충분히 만들어낼 수 있고, 2024년과 2025년에 발표된 여러 학술 논문들이 제3자 인프라에만 의존한 지갑에 대한 실제 정체 노출 공격을 시연한 바 있습니다.

Pruned Node는 추가로 1TB의 여유 공간을 마련하지 않고도 그 간극을 메워줍니다. 지갑 입장에서 보는 프라이버시 보장은 풀 노드와 정확히 동일합니다. 프루닝 로직이 폐기하는 것은 오직 잉여 링 서명 데이터뿐이며, 어떤 출력도, 어떤 key image도, 어떤 블록 헤더도 절대 폐기하지 않기 때문입니다. 지갑은 로컬에 보관된 데이터를 기준으로 체인을 스캔하고, 트랜잭션은 본인이 직접 맺은 피어 연결을 통해 멤풀에 진입하며, RPC 트래픽은 localhost 바깥으로 절대 나가지 않습니다.

• 어떤 원격 운영자도 지갑 활동을 보지 못합니다. 모든 새로고침, 모든 출력 스캔, 모든 수수료 추정이 본인의 머신에서만 일어납니다.
• 네트워크에 기여는 그대로 합니다. Pruned Node는 다른 피어들에게 과거 블록의 약 3분의 1을 제공하므로, 스웜 전체로 보면 모든 노드가 아카이브일 필요가 없어집니다.
• 하드웨어 요구치는 합리적입니다. RAM 4GB, 최신 쿼드코어 ARM 또는 x86 CPU, 여유 SSD 120GB면 보수적인 성장 가정을 적용해도 최소 2027년까지 무리 없이 동작합니다.
• 복구가 단순합니다. 데이터베이스가 손상되더라도 KT 기가 인터넷이나 SK 브로드밴드 일반 가정용 광 회선에서 처음부터 6~12시간 안에 재동기화가 끝납니다. 풀 아카이브 노드라면 18~30시간이 걸립니다.

Pruned Node와 Full Node의 실제 차이

v0.15에서 도입되어 2025년 v0.18.4까지 꾸준히 다듬어진 Monero 프루닝 알고리즘은 체인을 8개의 "pruning stripe"로 나누며, 각 스트라이프는 4096블록으로 구성됩니다. Pruned Node는 그중 단 하나의 스트라이프 전체 데이터(노드 초기화 시 피어별로 의사난수로 선택됨)와 가장 최근 5500블록 전체를 보관하고, 나머지 블록에 대해서는 헤더, key image, 출력 금액, 마이너 데이터를 그대로 유지합니다. 디스크 용량의 대부분을 차지하는 링 서명 데이터는 노드가 호스팅하지 않는 7개 스트라이프에 대해 폐기됩니다.

모든 노드가 서로 다른 스트라이프를 호스팅하기 때문에, 모든 노드가 프루닝을 한다 해도 스웜 전체는 과거 블록체인 전부를 그대로 보존하게 됩니다. 신선 동기화 중인 지갑이 오래된 블록의 링 서명 데이터를 필요로 할 때는 마침 그 스트라이프를 호스팅하는 Pruned 피어에서 투명하게 다운로드받을 뿐이며, 사용자 개입은 일절 필요 없습니다. 검증 관점에서 잃는 것은 없습니다. 각 Pruned Node는 최초 동기화 시 체인 전체를 검증하고, 이후에도 도착하는 모든 새 블록을 계속 검증합니다.

Pruned Node가 감수해야 하는 의미 있는 트레이드오프는 단 하나입니다. 블록 익스플로러나 과거 링 서명 전체를 필요로 하는 학술 체인 분석 도구의 데이터 소스 역할은 할 수 없다는 점입니다. 이런 용도가 로드맵에 없다면, 그리고 셀프 호스팅 사용자 대다수에게는 없습니다, 제약이 있는 머신에서 프루닝은 아카이브 대비 일방적으로 더 나은 선택입니다.

2026년 기준 하드웨어 및 시스템 요구사항

FCMP++ 활성화 이후 쾌적한 Pruned Monero Node를 위한 하드웨어 바닥선이 살짝 올라갔습니다. 들어오는 블록에 대한 멤버십 증명 검증이 포크 이전의 CLSAG 검증보다 CPU 부담이 약 18% 더 무겁기 때문입니다. 다행스러운 점은 대략 2021년 이후 출시된 장비라면 무난하게 처리한다는 사실입니다. 안타까운 점은 RAM 2GB짜리 초기 Raspberry Pi 4나 저전력 Atom 기반 미니PC 같은 구형 단일 보드 컴퓨터는 트랜잭션이 몰리는 날에 체인 팁을 따라잡는 데 어려움을 겪는다는 점입니다.

권장 기준

• CPU: 쿼드코어 ARM Cortex-A76 (Raspberry Pi 5) 또는 AES-NI 지원 최신 x86-64. 32비트 호스트는 절대 피하십시오. LMDB 성능이 저하되고 일부 지갑 RPC가 오작동합니다.
• RAM: 최소 4GB, 쾌적함은 8GB. LMDB 메모리 맵은 여유 공간이 있을수록 이득이며, RAM이 빠듯하면 monerod는 동작은 하되 블록 검증이 눈에 띄게 느려집니다.
• 저장장치: SSD 혹은 NVMe에 여유 120GB. HDD도 기술적으로는 작동하지만, 6시간이면 끝날 동기화가 36시간짜리 고문으로 변합니다. LMDB의 랜덤 액세스 패턴이 플래터에는 잔인합니다.
• 네트워크: 정상 운영에는 25Mbps 대칭이면 충분합니다. 한국의 일반 가정용 1Gbps 광 회선이면 차고 넘칩니다. 최초 동기화는 가용 대역폭을 모두 빨아들이며, Pruned 부트스트랩으로 약 90~110GB 다운로드를 예상하십시오.
• 운영체제: Ubuntu 24.04 LTS, Debian 12, Fedora 41, macOS 14 이상, Windows 11. NixOS 사용자는 유지보수되는 서비스 모듈이, Arch 사용자는 AUR에 monero-bin이 있습니다.

Raspberry Pi 5에 배포한다면 Pimoroni의 공식 NVMe Base 혹은 동등한 M.2 햇을 사용하십시오. SD 카드 슬롯은 OS용으로는 받아들일 만하지만 블록체인을 절대 그곳에 두지 마십시오. SD 카드는 쓰기 패턴 탓에 수개월 안에 사망하며, I/O 지연이 너무 커서 데몬이 완전히 동기화된 상태에서도 영원히 팁에 못 미친 것처럼 보입니다.

Linux에서의 단계별 설정

기준 경로를 Linux로 잡은 이유는 재현이 가장 쉽고, 가장 흔한 프로덕션 타겟이며, 무인 운영에 가장 적합하기 때문입니다. macOS와 Windows를 위한 변형은 글 말미에 정리합니다.

1. 전용 사용자와 디렉터리 생성. root 권한으로 useradd -r -s /bin/false monero를 실행한 다음 mkdir -p /var/lib/monero/blockchain /var/log/monero, 마지막으로 chown -R monero:monero /var/lib/monero /var/log/monero를 실행합니다. 로그인 계정이 아니라 서비스 계정으로 monerod를 구동하는 것은 비용이 거의 들지 않으면서도 가장 큰 보안 강화 효과를 주는 한 수입니다.
2. 공식 바이너리 다운로드. getmonero.org/downloads에 접속해 Linux 64bit 타볼을 받으십시오. 작성 시점 기준 최신 릴리스는 v0.18.4.2입니다. 결정적으로, 대응되는 hashes.txt도 함께 받아 shasum -a 256 monero-linux-x64-v0.18.4.2.tar.bz2로 SHA256을 검증하고, binaryFate의 PGP 키로 gpg --verify hashes.txt를 통해 hashes.txt의 서명을 확인하십시오. 검증을 건너뛰는 것이 바로 본인 머신에 멀웨어가 들어오는 경로입니다.
3. 압축 해제 및 설치. tar xjf monero-linux-x64-v0.18.4.2.tar.bz2로 풀고, install -m 755 monero-x86_64-linux-gnu-v0.18.4.2/monero* /usr/local/bin/으로 바이너리를 이동시킵니다. 이렇게 하면 monerod, monero-wallet-cli, monero-wallet-rpc가 PATH에 등록됩니다.
4. 설정 파일 작성. /etc/monero/monerod.conf를 생성하고 최소한 다음 내용을 포함하십시오. data-dir=/var/lib/monero/blockchain, log-file=/var/log/monero/monerod.log, log-level=0, prune-blockchain=1, sync-pruned-blocks=1, rpc-bind-ip=127.0.0.1, rpc-bind-port=18081, p2p-bind-port=18080, out-peers=32, in-peers=64, limit-rate-up=1048576, no-igd=1, enable-dns-blocklist=1. sync-pruned-blocks=1 플래그는 결정적입니다. 이게 없으면 monerod는 풀 체인을 받아온 뒤 로컬에서 프루닝하므로, 대역폭과 시간 모두를 낭비하게 됩니다.
5. systemd 유닛 생성. 다음을 /etc/systemd/system/monerod.service로 저장하십시오. [Unit] 블록에 Description=Monero Full Node (pruned)와 After=network-online.target, [Service] 블록에 User=monero, Group=monero, Type=simple, ExecStart=/usr/local/bin/monerod --config-file=/etc/monero/monerod.conf --non-interactive, Restart=on-failure, RestartSec=30, MemoryHigh=3G, MemoryMax=5G, 마지막으로 [Install] 블록에 WantedBy=multi-user.target이 들어갑니다.
6. 서비스 활성화 및 시작. systemctl daemon-reload를 실행한 다음 systemctl enable --now monerod를 실행합니다. 진행 상황은 journalctl -u monerod -f로 모니터링하거나 로그 파일을 직접 tail 하십시오. 1Gbps 가정용 광 회선에서 Pruned Node 최초 동기화는 보통 6~10시간 안에 끝납니다. NVMe를 단 Pi 5라면 14~20시간을 잡으십시오. 다운로드가 아니라 검증이 병목이기 때문입니다.
7. RPC 포트가 아니라 P2P 포트를 여십시오. 인바운드 피어 연결을 받고 싶다면(네트워크에도 도움이 되고 본인 피어 다양성도 좋아집니다) 공유기나 방화벽에서 TCP 18080을 여십시오. 18081은 공용 인터넷에 절대 노출하지 마십시오. 그 포트는 지갑의 RPC 엔드포인트이며 localhost에만 바인딩되어 있어야 합니다. 원격 지갑 접근이 필요하다면 SSH나 Tor로 터널링하십시오. 절대 단순 포트 포워딩으로 노출하지 마십시오.
8. 지갑을 로컬 데몬에 연결. 공식 GUI 지갑이라면 "Connect to a local node"를 선택하고 127.0.0.1:18081을 입력합니다. CLI에서는 monero-wallet-cli에 --daemon-address=127.0.0.1:18081을 전달합니다. Feather Wallet에서는 Settings → Node에 로컬 노드 토글이 있고, 데스크톱 Cake Wallet에서는 Settings → Privacy → Custom node 경로로 지원됩니다.

공용 인터페이스에서 monerod를 절대 --restricted-rpc=0로 실행하지 마십시오. Shodan에 인덱싱된 지 48시간 안에, 제한 없는 RPC 엔드포인트는 마이닝 풀 스크레이퍼, 지갑 스캐닝 봇, 그리고 더 나쁜 것들에게 두들겨 맞기 시작합니다. localhost 전용 바인딩이 기본값인 데에는 이유가 있습니다.

다른 플랫폼용 설정 응용

Raspberry Pi 5와 NVMe

위의 설정은 Pi 5에서도 거의 그대로 동작합니다. 손볼 가치가 있는 두 가지는 다음과 같습니다. 첫째, NVMe의 쓰기 증폭을 줄이기 위해 monerod.conf에 db-sync-mode=fast:async:250000000을 추가하십시오(기본값은 안전하지만 더 느립니다). 둘째, 지속적인 업로드에 스로틀이 걸리는 가정용 회선을 쓴다면 out-peers를 16으로, in-peers를 32로 낮추는 것을 고려하십시오. Pi 5의 쿼드 Cortex-A76은 최신 데스크톱의 약 0.6배 속도로 블록을 검증하므로 최초 동기화에 더 오래 걸리지만, 정상 운영 단계에서는 체인 팁을 무리 없이 따라잡습니다.

macOS

Homebrew로 brew install monero를 실행해 설치합니다. Apple Silicon에서는 monerod가 /opt/homebrew/bin/monerod에 놓입니다. systemd 대신 ~/Library/LaunchAgents/io.getmonero.monerod.plist에 launchd plist를 사용하십시오. 설정 파일 내용은 동일하게 적용되며, data-dir만 홈 디렉터리 아래 어딘가, 예를 들어 ~/Library/Application Support/monero로 지정하면 됩니다. macOS 방화벽 프롬프트가 최초 실행 시 뜨는데, 피어에 서비스를 제공하고 싶다면 P2P 포트의 인바운드를 허용하십시오.

Windows 11

getmonero.org에서 Windows 64bit 인스톨러를 받아 실행하고, 데이터 디렉터리를 C:\ProgramData\bitmonero 아래 생성하도록 두십시오. monerod를 포그라운드 프로세스가 아니라 서비스로 구동하려면 NSSM (Non-Sucking Service Manager)을 사용해 동일한 --config-file 인자와 함께 monerod.exe를 가리키게 하십시오. Windows Defender가 가끔 monerod를 "coin mining"으로 플래그합니다. 마이닝을 하는 게 아니지만 휴리스틱이 둔하기 때문에, 바이너리 디렉터리를 예외 처리에 추가하십시오.

유지보수, 모니터링, 복구

제대로 설정된 Pruned Node는 거의 set-and-forget에 가깝지만, 세 가지 운영 습관이 통증의 90%를 막아줍니다.

첫째, 디스크 공간을 매월 확인하십시오. 현재 트랜잭션 볼륨 기준으로 Pruned 체인은 월 약 4~6GB씩 자라며, 갑작스러운 디스크 풀은 LMDB를 보기 흉한 방식으로 손상시킬 수 있습니다. /var/lib/monero의 여유 공간이 15GB 아래로 떨어지면 알람을 보내는 monit 스크립트나 systemd 타이머를 설정하십시오.

둘째, monerod를 최신으로 유지하십시오. 네트워크 업그레이드(하드포크)는 대략 6~9개월마다 발생하며, 이전 프로토콜 버전을 돌리는 노드는 포크가 활성화되는 순간 블록 수용을 멈춥니다. Monero 릴리스 일정은 GitHub releases 페이지에 게시되며, r/Monero와 공식 메일링 리스트에 보통 4~6주 전에 공지됩니다. 여유를 두기 위해 포크 높이로부터 최소 2주 전에는 업데이트하십시오.

셋째, 재동기화 방법을 숙지하십시오. LMDB가 "MDB_CORRUPTED"를 던지거나 정전 이후 데몬이 시작을 거부한다면, 복구는 잔인하지만 확실합니다. 서비스를 중지하고, /var/lib/monero/blockchain의 내용을 삭제한 뒤 재시작하십시오. 노드는 6~12시간 만에 처음부터 재동기화합니다. 증분 복구 도구는 없습니다. LMDB가 그런 걸 제공하지 않기 때문입니다. 클린 재동기화가 정석 해결책이며 2017년부터 변함없이 통하는 방법입니다.

실제 사례 하나를 들겠습니다. MoneroSwapper 백엔드의 한 기여자는 세 나라에 걸쳐 7개의 Pruned Node로 구성된 플릿을 운영하여, 익명 스왑 서비스를 위한 다양화된 데몬 엔드포인트를 제공합니다. 각 노드는 동일하게 프로비저닝됩니다. Debian 12, 위에서 보인 systemd 유닛, NVMe 저장장치, 그리고 P2P 포트의 Tor hidden service 노출입니다. 플릿 전체 누적 가동 시간 38개월 동안 필요했던 개입은 예정에 없던 데이터센터 재부팅 이후의 세 번의 재동기화, 그리고 표준적인 포크일 바이너리 교체뿐이었습니다. 제대로 강화된 배포에서 기대해야 할 정상 상태가 바로 이것입니다.

FAQ

기존 Full Node를 재동기화 없이 Pruned Node로 전환할 수 있습니까?

가능합니다. monerod를 중지하고, 서비스가 아닌 일회성 명령으로 monerod --prune-blockchain을 실행한 뒤 기다리십시오. 프루닝 작업은 디스크 속도에 따라 30~90분 정도 걸리며 데이터베이스를 제자리에서 다시 쓰는 방식입니다. 완료되면 Pruned 설정으로 서비스를 재시작하십시오. 데이터 손실도, 재동기화도 없지만 예방 차원에서 지갑 키 백업은 반드시 먼저 해 두십시오. 블록체인 자체는 어떤 피어에서든 복원 가능하므로 백업할 필요가 없습니다.

Pruned Node가 채굴이나 Monero 머천트 게이트웨이 운영에 쓰일 수 있습니까?

솔로 채굴이나 풀 채굴이라면 가능합니다. 채굴자는 체인 팁만 필요하며 과거 링 서명은 필요하지 않습니다. P2Pool 역시 Pruned Node와 잘 작동하며, 사실 2023년부터는 셀프 소버린 솔로 스타일 채굴에 권장되는 조합입니다. monero-wallet-rpc를 통해 입금을 처리하는 머천트 게이트웨이의 경우에도 Pruned Node로 충분합니다. 아카이브 노드가 반드시 필요한 역할은 블록 익스플로러와 학술 체인 분석 도구뿐입니다.

Pruned Node가 본인 지갑의 프라이버시를 해칩니까?

해치지 않습니다. 지갑 스캔은 출력 인덱스와 key image 데이터베이스를 사용하는데, 둘 다 Pruned Node에서 풀로 보존됩니다. 폐기되는 데이터, 즉 과거 링 서명은 지갑의 view key 스캐닝에도, 새 트랜잭션 구성 시 지갑이 수행하는 디코이 선택에도 영향을 주지 않습니다. 지갑 관점에서 로컬 데몬은 아카이브 데몬과 구별이 불가능하며, 원격 운영자가 얼마나 신뢰할 만하다고 주장하든 그 어떤 Remote Node보다도 압도적으로 더 사적입니다.

멤버십 증명이 라이브 상태인 지금, 프루닝과 FCMP++는 어떻게 상호작용합니까?

2025년 11월 하드포크는 기존 링 서명 방식과 함께 full chain membership proof를 도입했고, 프루닝은 둘을 일관되게 다룹니다. 체인 검증에 필요한 모든 증명과 모든 key image는 보존하고, 옛 트랜잭션들이 아직도 끌고 다니는 잉여 링 서명 페이로드 바이트만 폐기합니다. FCMP++ 이후의 트랜잭션은 레거시 CLSAG 트랜잭션보다 약간 더 작기 때문에, 프루닝 비율은 사실 과거 블록보다 최근 블록에서 미세하게 더 유리해집니다.

Pruned Node를 전부 Tor 위에서 운영할 수 있습니까?

가능하며, 디스크 효율과 네트워크 수준 프라이버시 둘 다를 원하는 사용자들에게 흔한 배포 방식입니다. monerod.conf에 tx-proxy=tor,127.0.0.1:9050,32와 anonymous-inbound=YOURONIONADDRESS.onion,127.0.0.1:18083,16을 추가하고, /etc/tor/torrc에 대응되는 hidden service를 구성하십시오. Tor를 통한 최초 동기화는 6~12시간이 아니라 24~48시간으로 더 느리지만, 정상 운영 단계에서는 무리가 없고, 본인의 트랜잭션이나 지갑 스캔이 클리어넷을 한 번도 거치지 않는다는 추가 속성을 얻게 됩니다.

한국 사용자를 위한 추가 고려사항

한국 가정용 인터넷 환경은 Pruned Node 운영에 거의 이상적입니다. KT, SK 브로드밴드, LG U+가 제공하는 기본 1Gbps 광 회선은 최초 동기화를 6시간 이내로 단축시키고, 정상 운영 중에는 가용 대역폭의 극히 일부만 점유합니다. 다만 가정용 인터넷 약관에는 서버 운영 제한 조항이 있을 수 있으므로, 인바운드 P2P 포트를 공개적으로 노출하기 전 가입 약관을 한 번 확인하는 편이 안전합니다. 실무상으로는 TCP 18080의 P2P 트래픽이 ISP 측에서 문제로 표시된 사례는 거의 보고되지 않았지만, 약관에 종속되는 부분이므로 보수적으로 접근하십시오.

VPS를 통해 노드를 운영하는 선택지도 활발합니다. 국내 클라우드 사업자(NHN Cloud, KT Cloud, Naver Cloud Platform)와 해외 사업자(Hetzner, OVH, Vultr) 모두 NVMe 기반 인스턴스를 제공하며, 월 2~3만 원대의 사양으로도 Pruned Node를 충분히 돌릴 수 있습니다. 트래픽 종량제 요금이 적용되는 인스턴스라면 limit-rate-up과 out-peers를 보수적으로 설정해 월 트래픽이 무한정 증가하지 않도록 통제하십시오. 일반적으로 1Mbps 업로드 제한이면 월 약 320GB의 업로드를 발생시키며, 이는 대부분의 무제한 요금제 안에 들어옵니다.

국세청은 가상자산 관련 신고 의무를 단계적으로 강화하고 있지만, 본인 노드를 운영하는 행위 자체는 어떠한 신고 의무도 발생시키지 않습니다. 노드는 트랜잭션 처리 인프라일 뿐 자산 보유나 양도가 아니기 때문입니다. 다만 해당 노드와 연결된 지갑에서 일어나는 매수, 매도, 스왑은 일반적인 가상자산 과세 원칙의 적용을 받으므로, 본인의 트랜잭션 기록은 따로 보관하시기를 권장합니다. 셀프 호스팅이 회계 의무를 줄여주는 것은 아니지만, 적어도 본인의 거래 데이터가 제3자 노드 운영자에게 흘러들어가지 않는다는 점에서 프라이버시 측면의 이점은 명확합니다.

결론

Pruned Monero Node는 아카이브 노드의 프라이버시 및 검증 보장을 그대로 유지하면서 디스크 점유량은 약 40% 수준으로 줄여줍니다. 이는 "이 정도 용량은 노트북에 도저히 못 들어간다"와 "이 정도면 다른 것들과 같이 편안하게 돌아간다"의 차이입니다. 셋업은 최신 머신이라면 하룻저녁이면 끝나는 프로젝트이고, 유지보수 부담은 대략 6개월에 한 시간 정도이며, 결과물은 앞으로 보낼 모든 Monero 트랜잭션, 받을 모든 Monero 트랜잭션의 셀프 소버린 토대입니다. 로컬 Pruned Node를 MoneroSwapper 같은 KYC 없는 스왑 서비스와 결합하면 풀스택이 완성됩니다. RingCT와 FCMP++를 통한 프로토콜 레이어 프라이버시, 본인 데몬을 통한 네트워크 레이어 프라이버시, 그리고 본인의 신원을 한 번도 보지 않는 고정 환율 atomic swap을 통한 온램프 프라이버시까지 말입니다. 절약되는 디스크 공간은 부수적인 보너스에 불과합니다. 진짜 이득은 운영의 독립성입니다.