VPS에서 Bitcoin 풀 노드를 운영하는 방법

풀 노드는 무엇이 진실인지 다른 누군가에게 묻지 않고 Bitcoin을 사용할 수 있는 유일한 방법이다. 그 밖의 모든 선택지 — 블록 탐색기, 공개 서버와 통신하는 라이트 지갑, 거래소에 남아 있는 잔액 — 는 결국 자신의 거래 내역을 제3자에게 맡기고 그 과정에서 프라이버시까지 넘겨준다는 뜻이다. Bitcoin Core 자체는 설치에 10분 정도면 충분하다. 정작 그 노드가 쓸모 있는지를 좌우하는 것은 그 밑에 놓인 머신이다 — 얼마나 넉넉한 디스크를 주었는지, 업로드가 종량제인지, 그리고 호스트가 무엇을 볼 수 있는지가 그것이다.

풀 노드가 하는 일 — 그리고 하지 않는 일

풀 노드는 모든 블록을 내려받아 모든 서명과 모든 합의 규칙을 스스로 검증하고, 현재 사용 가능한 코인 집합의 자체 사본을 유지한다. 그것은 검증자다. 채굴자가 아니며, 그 자체만으로는 지갑도 아니다.

• 독립적으로 검증한다 — 탐색기도, 거래소도, 라이트 지갑 서버도 무엇이 유효한지, 잔액이 얼마인지를 대신 알려줄 권한이 없다.
• 지갑이 동기화될 때마다 낯선 서버에 주소를 흘리는 일을 막아준다 — 이는 대부분의 Bitcoin 이용자가 겪는 가장 큰 프라이버시 유출이다.
• 블록과 거래를 다른 곳으로 중계한다 — 이 부분이 바로 당신 한 사람이 아니라 네트워크 전체를 돕는 부분이다.
• 아무 수익도 내지 않고, 아무것에도 투표하지 않으며, 키 관리가 이미 허술하다면 코인을 더 안전하게 만들어주지도 않는다.

아카이브, 프루닝, 인덱싱: 서로 전혀 다른 세 가지 디스크 용량

이 결정 하나가 필요한 플랜을 좌우하므로, 무엇이든 주문하기 전에 먼저 정해야 한다. 세 가지 방식 모두 체인을 검증하는 방법은 완전히 동일하다 — 차이는 오직 검증이 끝난 뒤 그중 얼마나 많은 양이 디스크에 남는가에 있을 뿐이다.

• 프루닝(Pruned) — Core는 모든 것을 내려받고 검증한 다음, 오래된 블록 파일을 버리고 최근 파일만 남긴다. prune=5000으로 설정하면 블록 데이터는 약 5 GB 선을 유지하며, 여기에 UTXO 세트와 운영체제를 더하면 총합은 25 GB 근처가 된다.
• 아카이브(Archival) — 모든 블록을 영구히 보관한다. 현재 기준으로 블록 데이터만 이미 750 GB를 넘으며 매달 약 7 GB씩 늘어나고, 여기에 UTXO 세트까지 더해진다. 다른 피어에게 과거 블록을 제공하거나, 나중에 체인을 다시 내려받지 않고 재인덱싱하려면 이 방식이 필요하다.
• 인덱싱(Indexed) — 아카이브에 txindex=1을 더한 방식으로, ID로 어떤 거래든 조회할 수 있게 해 주며 블록 탐색기와 일부 서버 소프트웨어가 요구하는 방식이다. 수십 기가바이트가 추가되며, 프루닝과는 함께 사용할 수 없다.

Bitcoin 노드용 VPS 고르기: 디스크, RAM, 그리고 무제한 포트

Bitcoin Core는 CPU에는 여유롭지만 디스크에는 까다롭다. UTXO 데이터베이스에 대한 무작위 읽기·쓰기가 동기화 속도를 좌우하는 요소이며, 그래서 코어 개수보다 NVMe가 훨씬 더 중요하다. 오프쇼어 VPS 라인의 모든 플랜은 Gen4 NVMe를 RAID-10 구성으로 제공하고 대역폭도 무제한이므로, 실질적인 선택 기준은 용량이다.

• 프루닝 노드: 월 $7.49의 VPS-4 — 2 vCPU EPYC, 4 GB DDR5 ECC, 60 GB NVMe로 prune=5000과 로그까지 여유롭게 담긴다. 더 세게 프루닝한다면 월 $3.99의 VPS-2로도 충분하다.
• 빠르게 동기화하는 프루닝 노드: 월 $13.99의 VPS-8 — 4 vCPU와 8 GB 덕분에 Core에 dbcache를 몇 기가바이트씩 내줄 수 있으며, 이것이 동기화 시간을 좌우하는 가장 강력한 지렛대다.
• 아카이브 노드: 월 $89.99의 VPS-64는 프루닝하지 않은 체인이 겨우 들어맞는 800 GB NVMe를 갖춘 유일한 VPS 등급이다 — 다만 오늘 기준 크기로는 1년 남짓의 여유밖에 남지 않는다.

아카이브 노드나 인덱스 노드라면, 반사적으로 가장 큰 VPS를 사기보다 계산을 정직하게 해 보아야 한다: 월 $64부터 시작하는 전용 서버는 64 GB 메모리와 2 × 1 TB NVMe를 갖추고 있어, 가장 큰 VPS 등급보다 오히려 더 저렴하면서 공간도 훨씬 넉넉하다. 체인을 몇 년간 유지할 생각이거나 그 옆에 Electrum 서버와 KYC 없이 호스팅한 사이트를 함께 쌓을 생각이라면, 두 번 업그레이드하지 말고 처음부터 그쪽에서 시작하라.

단계별 안내: 암호화폐 충전부터 동기화된 노드까지

1. 01일회용 이메일로 계정 만들기이메일과 비밀번호만 있으면 된다. 이름도, 전화번호도, 신분증도 필요 없다 — 저희 쪽에는 노드를 당신과 연결할 만한 정보가 전혀 남지 않는다.
2. 02암호화폐로 잔액 충전하기Bitcoin, Monero를 비롯한 8종의 코인 중 무엇으로든 선불 잔액을 충전할 수 있다. 잔액은 만료되지도, 동결되지도 않는다.
3. 03VPS 배포하기플랜과 리전, Debian 또는 Ubuntu 이미지를 선택한다. 평균적으로 약 1분이면 root 접속이 가능해진다.
4. 04Bitcoin Core 설치하고 다운로드 검증하기Bitcoin Core 프로젝트에서 릴리스를 받은 다음, 압축을 풀기 전에 서명부터 검증하라. 이 단계를 건너뛰는 것이야말로 남이 만든 바이너리를 그대로 실행하게 되는 지름길이다.
5. 05systemd 아래에서 전용 사용자로 실행하기전용 bitcoin 사용자와 그 사용자가 소유하는 데이터 디렉터리, 그리고 재부팅 후에도 노드가 스스로 돌아오게 해 주는 유닛 파일을 갖춘다.
6. 06bitcoin.conf 작성하고 시작한 뒤 로그 지켜보기prune 수준과 dbcache, 네트워크 옵션을 설정하고 서비스를 시작한 다음, 검증 진행률이 1에 도달할 때까지 로그를 지켜보라.

정작 중요한 bitcoin.conf 설정 줄들

Core는 합리적인 기본값을 갖추고 있어, 좋은 설정은 대개 예닐곱 줄이면 충분하다. 다음은 포럼 글을 그대로 베끼기보다 제대로 이해해 둘 가치가 있는 항목들이다.

• dbcache — UTXO 데이터베이스용 메모리로, 기본값은 450 MB다. 초기 동기화 동안 수천 단위로 올려주는 것이 가장 값싸게 속도를 높이는 방법이며, 이후에는 다시 낮추면 된다.
• prune — 블록 저장 공간의 상한을 MB 단위로 지정하며, 최솟값은 550이다. 나중에 프루닝에서 아카이브로 바꾸려면 체인을 처음부터 다시 내려받아야 하므로, 첫 시작 전에 결정해 두어야 한다.
• txindex=1 — 전체 거래 인덱스를 구축한다. 실제로 사용하는 도구가 이를 요구할 때만 설정하라 — 나중에 추가하면 강제로 재인덱싱해야 한다.
• listen=1과 개방된 8333 포트 — 다른 피어가 접속할 수 있는 리스닝 노드로 만들어준다. 네트워크를 사용하기만 하는 것과 네트워크에 기여하는 것의 차이가 바로 여기서 갈린다.
• maxuploadtarget — 발신 트래픽에 대한 일일 소프트 상한이며, 전송량을 종량제로 매기는 호스트라면 어디서든 설정해 둘 가치가 있다.
• blocksonly=1 — 미확정 개별 거래의 중계를 중단시킨다. 대역폭을 크게 줄여주지만, 그 대가로 쓸모 있는 mempool과 전파 기여를 포기하게 된다.

초기 블록 다운로드: 실제로 무엇이 느리게 만드는가

최초 동기화만이 이 작업에서 진짜로 무거운 부분이다. Core는 전체 체인을 처음부터 재생하며, 기본적으로 하드코딩된 최근 블록 이전 구간의 스크립트 검사는 건너뛰지만, 그럼에도 UTXO 세트 전체를 처음부터 다시 구축한다 — 그래서 작업의 병목은 회선이 아니라 무작위 디스크 I/O와 해싱이다. dbcache를 넉넉히 준 Gen4 NVMe에서는 전체 동기화가 보통 하루가 채 걸리지 않는다. 같은 작업이 회전식 디스크에서는 일주일씩 걸릴 수 있다. 코어 개수보다 메모리를 더 주고, 조급한 마음에 재시작하고 싶은 유혹은 참아야 한다 — 진행 상황은 주기적으로 디스크에 기록되지만, 플러시 도중 재시작하면 그동안 대가를 치르며 쌓아온 캐시를 잃게 된다.

노드를 Tor로 운영하기

리스닝 노드는 자신을 피어들에게 알린다. 클리어넷 주소로 알리면 그 공지는 공개되며, 결국 당신의 서버를 가리키게 된다. Core는 Tor를 정식으로 지원한다: 로컬 Tor SOCKS 프록시와 Tor 컨트롤 포트에 대한 접근 권한만 주면, 자신만의 오니언 서비스를 게시하고 그곳으로 들어오는 연결을 받아들인다. onlynet=onion을 추가하면 클리어넷과는 아예 통신하지 않는다.

이는 타인의 트래픽을 실어 나르며 의도적으로 공개되는 Tor 릴레이를 운영하는 것과는 다른 일이다. 여기서 Tor는 그저 당신의 노드가 피어에게 닿는 경로일 뿐이며, 그 대가는 소소하다: 오니언 전용 노드는 동기화가 다소 느리고 피어 풀도 더 작지만, 계속 켜 두는 머신에게는 좀처럼 문제가 되지 않는다.

대역폭: 아무도 예산에 넣지 않는 비용

리스닝 노드는 다운로드보다 업로드가 훨씬 많다. 각자 초기 동기화를 진행하는 피어마다 당신에게서 수백 기가바이트를 끌어갈 수 있고, 연결이 좋은 아카이브 노드는 내버려 두면 한 달에 몇 테라바이트씩도 기꺼이 제공한다. 종량제 호스트에서는 이것이 곧 초과 요금 청구서가 된다 — 이는 정확히 '무제한' 호스팅 플랜이 애초부터 배제하도록 설계된 바로 그 트래픽 패턴이다. 여기서는 전 라인에 걸쳐 무제한 전송이 기본이며, 다른 사람들을 위해 체인을 적극적으로 시딩하고 싶다면 월 $34.99부터 시작하는 10 Gbps Unmetered 라인이 전용 포트를 제공한다. 작게 유지하고 싶다면, 운에 맡기지 말고 maxuploadtarget으로 직접 상한을 정하라.

지갑, Electrum 서버, 또는 BTCPay 연결하기

노드 하나만으로는 절반의 구성일 뿐이다 — 핵심은 낯선 사람의 서버가 아니라 자신의 소프트웨어가 그 노드와 대화하게 만드는 것이다. Sparrow나 Specter 같은 지갑은 터널을 통해 Core의 RPC에 곧바로 연결된다. Electrum 프로토콜 지갑은 중간에 서버가 하나 더 필요하다 — electrs나 Fulcrum이 원본 블록 파일로부터 자체 인덱스를 구축해 주며, 이것이 바로 프루닝하지 않고 남겨 두어야 할 구체적인 이유 중 하나다. 그리고 직접 결제를 받고 싶다면, 자신의 노드를 대상으로 실행하는 BTCPay Server가 결제 처리업체를 통째로 없애준다 — KYC 없이 웹사이트를 올리는 것과 같은 셀프 호스팅 논리다.

어떤 스택을 쓰든 원칙은 하나다: 노드는 검증만 하고, 키는 다른 곳에 둔다. 하드웨어 지갑이나 오프라인 서명기를 사용하고, 대여한 머신에는 오직 검증 역할만 맡겨라. 물리적으로 소유하지 않은 박스는 의미 있는 자금이 머물 곳이 아니다.

직접 소유하지 않은 노드의 솔직한 프라이버시 트레이드오프

VPS 위의 노드는 자기 책상 밑의 노드와 완전히 같지 않으며, 그 이유를 정확히 짚어볼 가치가 있다. 이는 가장 크고 가장 흔한 유출 — 어떤 주소를 조회했는지 그대로 기록하는 공개 탐색기와 서드파티 Electrum 서버에 질의하는 것 — 을 없애준다. 다만 없앨 수 없는 것이 하나 있다: 바로 호스트다. 머신에 물리적으로 접근할 수 있는 사람은 원칙적으로 그 디스크와 메모리를 읽을 수 있으며, 원격 서버의 전체 디스크 암호화는 도난당한 드라이브는 지켜주지만 가동 중인 드라이브는 지켜주지 못한다.

그러니 정작 중요한 질문은 '호스트가 볼 수 있는가'가 아니라 '호스트가 내가 누구인지 아는가'다. No-KYC 호스팅은 바로 그 질문에 답한다: 이메일과 비밀번호뿐, 본인 확인도 없고, 유출되거나 소환될 만한 기록도 남지 않는다. 암호화폐 잔액으로 결제하면 은행이라는 요소도 사라진다. 결제 쪽을 어디까지 신경 쓸지는 위협 모델의 문제다 — Bitcoin은 익명이 아니라 가명(pseudonymous)일 뿐이므로, 인증된 거래소까지 추적된 코인은 결국 어딘가로 이어지는 반면, Monero로 충전하면 프로토콜 수준에서 그 간극을 메울 수 있다. 같은 논리가 Monero 노드를 운영하는 것에도 적용되며, 그곳에서 지키는 것은 지갑과 노드 사이의 연결 고리다.

노드를 멈추게, 놀게, 혹은 노출되게 만드는 실수들

• 프루닝 여부를 사후에 결정하는 바람에 동기화 도중 디스크가 가득 차는 경우 — 도중이 아니라 첫 시작 전에 미리 정해 두어야 한다.
• 방화벽에서 8333 포트를 막아 둔 채 방치하는 경우 — 노드가 발신 연결만 할 뿐 단 하나의 피어에게도 서비스를 제공하지 못한다.
• '테스트 삼아 잠깐만'이라며 RPC를 0.0.0.0에 바인딩하는 경우 — 공인 IP에서는 몇 시간 안에 발견된다.
• 작은 디스크에서 반사적으로 txindex를 활성화하는 경우 — 나중에 이를 제거하려면 전체 재인덱싱이 필요하다는 사실을 뒤늦게 알게 된다.
• systemd 유닛도 없이 홈 디렉터리에서 root로 노드를 실행하는 경우 — 재부팅 한 번이면 조용히 실험이 끝나버린다.

이 중 어느 것도 특이한 실패가 아니다. 가격만 보고 머신을 고르고 세부 사항은 나중으로 미룰 때 벌어지는 일들일 뿐이다. 실제로 원하는 방식에 맞는 디스크를 고르고, 피어 포트는 열어 두고 RPC는 닫아 두면, Bitcoin 노드는 몇 년이고 그냥 켜 둘 수 있는 가장 손이 덜 가는 것 중 하나가 된다.