지난 글에서는 Synology NAS를 이용해 비트코인 풀노드와 Electrum 서버를 운영하는 전체 구조를 정리해보았습니다.
당시 전체 구조는 아래와 같았습니다.
이번 글에서는 이 구조의 가장 기본이 되는 Bitcoin Core 설치 과정을 정리해보려고 합니다.
처음에는 “NAS에서 비트코인 노드를 운영한다”는 말 자체가 굉장히 어렵게 느껴졌습니다.
특히
- Docker
- 컨테이너(Container)
- RPC
- txindex
- host 네트워크
- peer
- mempool
같은 용어들이 꽤 낯설었습니다.
하지만 실제로 하나씩 설치하고 구조를 이해하면서, 비트코인 노드가 어떻게 동작하는지 조금씩 감이 오기 시작했습니다.
이번 글에서는 단순 설치 방법만 정리하는 것이 아니라
- 실제 설치 과정
- 설정한 이유
- 구조 이해
- 로그 해석
- 운영하면서 느낀 점
까지 함께 정리해보려고 합니다.
Bitcoin Core란 무엇일까
Bitcoin Core는 비트코인 네트워크에서 가장 널리 사용되는 풀노드 프로그램입니다.
쉽게 말하면 다음과 같은 역할을 합니다.
- 블록체인(Blockchain) 다운로드
- 블록 검증
- 거래(Transaction) 검증
- 비트코인 네트워크 참여
즉, Bitcoin Core가 있어야 내 NAS가 단순 저장장치가 아니라 비트코인 네트워크에 직접 참여하는 노드로 동작할 수 있습니다.
많은 사람들이 처음에는
“비트코인은 앱 안에 저장되는 것 아닌가?”
라고 생각하기 쉽습니다.
저도 처음에는 비트코인 지갑 앱이 모든 것을 처리하는 줄 알았습니다.
하지만 실제로는 전 세계 수많은 노드(Node)가 같은 블록체인 데이터를 공유하고, 각자 직접 검증하는 구조입니다.
Bitcoin Core는 이 블록체인 데이터를 직접 다운로드하고 검증하는 역할을 합니다.
즉, 단순한 지갑 앱과는 역할이 다릅니다.
왜 Bitcoin Core부터 설치할까
Fulcrum 같은 Electrum 서버는 단독으로 동작하지 않습니다.
반드시 Bitcoin Core와 연결되어야 합니다.
구조를 단순하게 보면 다음과 같습니다.
Bitcoin Core → 실제 블록체인 저장 및 검증
Fulcrum → Electrum 지갑이 빠르게 조회할 수 있도록 인덱싱
즉, Fulcrum은 Bitcoin Core의 데이터를 활용하는 구조입니다.
그래서 가장 먼저 안정적으로 설치해야 하는 것이 Bitcoin Core입니다.
Bitcoin Core가 정상적으로 동기화되고 RPC 연결이 가능해야 그다음 단계인 Fulcrum 설치와 Electrum 지갑 연결로 넘어갈 수 있습니다.
이번 설치 환경
이번 설치는 아래 환경에서 진행했습니다.
- Synology NAS
- DSM Container Manager
- Docker 기반 Bitcoin Core 실행
- kylemanna/bitcoind Docker 이미지
- host 네트워크 모드
- Bitcoin Mainnet 운영
RAM은 기본 2GB에서 추가 16GB를 업그레이드 했고, 블록체인 데이터는 NAS의 HDD 저장소에 저장했습니다.
다만 이 글의 설정값은 제 환경에서 사용한 예시입니다.
NAS 모델, 메모리, 저장장치 구성, 네트워크 환경에 따라 적절한 값은 달라질 수 있습니다.
kylemanna/bitcoind 이미지를 사용한 이유
이번 설치에서는 Docker 이미지로 kylemanna/bitcoind를 사용했습니다.
처음에는 Docker 이미지 종류가 많아서 어떤 것을 선택해야 할지 꽤 헷갈렸습니다.
Bitcoin Core는 공식 프로그램이지만, Docker 환경에서는 여러 커뮤니티 이미지가 존재합니다.
그중 kylemanna/bitcoind는 Bitcoin Core 서버 프로그램인 bitcoind를 Docker 환경에서 실행하기 쉽게 구성한 커뮤니티 Docker 이미지로 이해하면 좋습니다.
즉, Bitcoin Core 자체를 새로 만든 프로그램이라기보다, Bitcoin Core를 컨테이너 환경에서 실행할 수 있게 구성한 이미지라고 보는 것이 자연스럽습니다.
이 이미지의 특징
이 이미지의 장점은 비교적 단순했습니다.
- Bitcoin Core를 Docker 컨테이너로 실행 가능
- 데이터 저장 위치를 NAS 폴더와 분리 가능
- DSM Container Manager에서 관리 가능
- 로그 확인이 쉬움
- 컨테이너 재시작과 관리가 비교적 단순함
쉽게 말하면
“NAS 안에 독립된 Bitcoin Core 실행 환경을 만드는 구조”
라고 이해하면 편했습니다.
다만 장기 운영 환경에서는 Docker 이미지의 출처, 업데이트 방식, 버전 관리도 함께 고려하는 것이 좋습니다.
설치 전에 준비한 것들
1. 저장 공간 확인
Bitcoin 블록체인은 계속 증가합니다.
특히 아래 데이터들이 상당한 저장 공간을 사용합니다.
- blocks
- chainstate
- txindex
처음에는 단순히 “블록체인 파일 하나” 정도로 생각했는데, 실제로는 역할이 서로 다른 여러 데이터가 함께 저장되는 구조였습니다.
blocks
blocks 폴더는 실제 비트코인 블록 데이터(Block Data)를 저장하는 공간입니다.
쉽게 말하면 비트코인 네트워크가 2009년부터 지금까지 기록한 모든 블록과 거래 데이터가 저장되는 곳입니다.
예를 들어
- 누가 누구에게 BTC를 보냈는지
- 어떤 거래가 어떤 블록에 포함되었는지
- 채굴자가 어떤 블록을 생성했는지
같은 기록이 모두 들어 있습니다.
실제 파일은 아래와 비슷한 형태로 저장됩니다.
blk00000.dat
blk00001.dat
blk00002.dat
이런 파일들이 시간이 지나면서 계속 증가합니다.
즉, blocks는 Bitcoin Core가 보관하는 원본 블록체인 기록 저장소에 가까운 개념입니다.
chainstate
chainstate는 현재 UTXO(Unspent Transaction Output) 상태를 저장하는 데이터입니다.
처음에는 이 개념이 꽤 어렵게 느껴졌습니다.
쉽게 말하면
“지금 실제로 사용 가능한 비트코인 상태”
를 빠르게 확인하기 위한 데이터입니다.
예를 들어
- 어떤 비트코인이 아직 사용 가능한 상태인지
- 이미 사용된 거래인지
- 새로운 거래가 유효한지
같은 정보를 검증할 때 사용됩니다.
만약 Bitcoin Core가 매번 전체 블록체인을 처음부터 다시 계산해야 한다면 속도가 매우 느려질 것입니다.
그래서 현재 상태를 빠르게 확인할 수 있도록 chainstate 데이터베이스를 별도로 유지합니다.
정리하면 이렇게 이해하면 편했습니다.
blocks → 과거 전체 기록
chainstate → 현재 사용 가능한 상태 요약
이렇게 구분하고 나니 조금 더 쉽게 이해할 수 있었습니다.
txindex
txindex는 전체 트랜잭션(Transaction) 인덱스를 저장하는 기능입니다.
기본 Bitcoin Core는 모든 거래를 빠르게 검색할 수 있도록 전체 거래 인덱스를 항상 만들어두지는 않습니다.
하지만 txindex=1을 활성화하면 다음과 같은 작업에 도움이 됩니다.
- 과거 전체 거래 검색
- 특정 txid 조회
- Electrum 서버 연동 구조 구성
즉, 블록체인의 거래를 빠르게 찾을 수 있도록 색인을 만드는 과정이라고 이해하면 편했습니다.
다만 단점도 있습니다.
- 저장 공간 증가
- 초기 인덱싱 시간 증가
- 디스크 사용량 증가
실제로 처음에는 왜 시간이 오래 걸리는지 잘 몰랐는데, 나중에 보니 Bitcoin Core가 단순히 블록만 저장하는 것이 아니라, 거래를 정리하고 인덱싱하는 과정도 함께 수행하고 있었습니다.
Fulcrum 같은 Electrum 서버와 연동하려면 전체 거래 조회와 인덱싱 구조가 중요하기 때문에, 제 구성에서는 처음부터 txindex=1을 활성화했습니다.
실제 저장 공간 사용량
초기에는 “비트코인 노드가 어느 정도 공간을 사용할까?” 감이 잘 오지 않았습니다.
하지만 실제 운영해보니 생각보다 저장 공간 증가 속도가 꽤 빠르게 느껴졌습니다.
제가 확인한 시점의 Bitcoin Core 데이터 폴더는 약 863GB 정도를 사용하고 있었습니다.
파일 수도 13만 개 이상으로 확인되었습니다.
이 안에는 다음과 같은 데이터가 함께 포함됩니다.
- blocks
- chainstate
- txindex
- mempool 관련 데이터
다만 이 용량은 제가 확인한 시점과 제 설정 기준입니다.
블록체인 데이터는 계속 증가하고, txindex 사용 여부나 운영 시점에 따라 실제 사용량은 달라질 수 있습니다.
처음에는 “몇십 GB 정도면 충분하지 않을까?”라고 생각했지만, 실제로는 블록체인 데이터와 인덱스가 계속 증가하기 때문에 여유 저장 공간을 충분히 확보하는 것이 중요하다고 느꼈습니다.
특히 NAS 환경에서는
- HDD 용량
- SSD 캐시 여부
- RAID 구성
- 향후 증가량
- 백업 정책
도 함께 고려하는 편이 좋다고 느꼈습니다.
2. Container Manager 설치
DSM에서는 Docker가 현재 Container Manager라는 이름으로 제공됩니다.
이번 설치는 Container Manager를 이용했습니다.
처음에는 일반 프로그램처럼 설치되는 줄 알았지만, 실제로는 컨테이너(Container)라는 독립 실행 환경을 사용하는 구조였습니다.
3. 안정적인 네트워크
초기 동기화(Initial Sync) 과정에서는 상당한 양의 데이터를 다운로드합니다.
그래서 안정적인 인터넷 환경이 중요하다고 느꼈습니다.
특히 초기 동기화 중에는
- 블록 다운로드
- 블록 검증
- txindex 생성
이 동시에 진행되기 때문에 네트워크뿐 아니라 디스크 접근량도 상당히 많았습니다.
Docker 컨테이너를 간단히 이해하기
Docker는 처음 접하면 꽤 어렵게 느껴질 수 있습니다.
저 역시 처음에는
- 이미지(Image)
- 컨테이너(Container)
- 볼륨(Volume)
같은 용어가 헷갈렸습니다.
하지만 실제로는 이렇게 이해하니 조금 편했습니다.
이미지(Image) → 설치 파일 또는 실행 준비 패키지 개념
컨테이너(Container) → 실제 실행 중인 프로그램 환경
볼륨(Volume) → 컨테이너 밖에 데이터를 저장하기 위한 연결 폴더
즉, Docker는 NAS 안에서 독립된 작은 Linux 실행 환경을 띄우는 느낌에 가까웠습니다.
Bitcoin Core 설치 과정 한눈에 보기
이제 실제 Bitcoin Core 컨테이너를 만드는 과정을 정리해보겠습니다.
처음에는 설정 항목이 많아 복잡하게 느껴졌지만, 전체 흐름을 나누어 보면 크게 아래 순서로 진행됩니다.
- Docker 이미지 다운로드
- 컨테이너 이름 설정
- 볼륨 설정
- 환경 변수 설정
- 네트워크 설정
- 실행 명령 설정
- bitcoin.conf 설정
앞부분에서 저장 공간과 Docker 개념을 먼저 살펴본 이유는, 이 설치 과정에서 볼륨과 네트워크 설정을 이해하는 데 필요했기 때문입니다.
특히 Bitcoin Core는 일반 앱처럼 설치만 하고 끝나는 프로그램이 아니라, 블록체인 데이터를 계속 저장하고 검증하는 서버 프로그램에 가깝습니다.
그래서 설치 전에 데이터가 어디에 저장되는지, 컨테이너가 어떻게 실행되는지, RPC 통신은 어떻게 제한할지 정도는 먼저 이해해두는 것이 좋다고 느꼈습니다.
이제 위 순서에 따라 실제 설정 과정을 하나씩 정리해보겠습니다.
1단계. Docker 이미지 다운로드
Container Manager에서 레지스트리(Registry) 메뉴로 이동합니다.
그다음 아래 이미지를 검색했습니다.
kylemanna/bitcoind
이미지를 다운로드한 뒤 컨테이너 생성 작업을 진행했습니다.
처음에는 latest 태그를 사용했습니다.
다만 장기 운영 환경에서는 latest 태그 사용에 주의할 필요가 있습니다.
latest는 업데이트 시점에 따라 실제 버전이 바뀔 수 있기 때문에, 운영 환경에서는 검토한 특정 버전 태그를 사용하는 편이 예측 가능성이 더 좋을 수 있습니다.
처음 테스트하거나 학습할 때는 latest가 편할 수 있지만, 안정적인 장기 운영을 생각한다면 버전 고정도 함께 고려하는 것이 좋다고 느꼈습니다.
2단계. 컨테이너 이름 설정
컨테이너 이름은 다음처럼 지정했습니다.
bitcoin-node
컨테이너 이름은 기능을 바로 알아볼 수 있게 정하는 것이 좋습니다.
Bitcoin Core 외에도 여러 컨테이너를 함께 운영하다 보면, 나중에 로그 확인이나 재시작, 상태 점검을 할 때 이름만 보고도 어떤 서비스인지 구분할 수 있어야 하기 때문입니다.
아래 화면처럼 컨테이너 이름은 기능을 바로 알아볼 수 있도록 bitcoin-node로 지정했습니다.
3단계. 볼륨(Volume) 설정
이번 설치에서 가장 중요하다고 느꼈던 부분입니다.
예시 설정은 다음과 같습니다.
NAS 실제 저장 경로
/volume1/docker/bitcoin
컨테이너 내부 경로
/bitcoin/.bitcoin
권한
읽기/쓰기(rw)
위 경로는 제 환경에서 사용한 예시입니다.
공개 블로그나 문서에서는 실제 내부 경로를 그대로 노출하기보다는, 이런 식으로 예시 경로로 설명하는 편이 좋습니다.
아래 화면처럼 NAS의 Docker 데이터 폴더를 컨테이너 내부의 Bitcoin Core 데이터 경로와 연결했습니다.
이 설정 덕분에 컨테이너를 다시 만들어도 블록체인 데이터는 NAS 저장소에 남게 됩니다.
볼륨이 왜 중요할까
Bitcoin Core는 블록체인 데이터를 계속 저장합니다.
즉,
- blocks
- chainstate
- indexes
- mempool.dat
같은 데이터가 계속 증가합니다.
처음에는 “컨테이너 안에 저장되는 것 아닌가?”라고 생각했는데, 실제로는 NAS 폴더와 컨테이너 내부 경로를 연결하는 구조였습니다.
쉽게 말하면 다음과 같습니다.
NAS 폴더 → 실제 데이터 저장 장소
컨테이너 내부 경로 → Bitcoin Core가 데이터를 읽고 쓰는 작업 공간
이렇게 해두면 컨테이너를 삭제하거나 다시 만들어도 블록체인 데이터는 NAS 폴더에 남아 있습니다.
실제로 운영하면서 느낀 가장 중요한 개념 중 하나가 바로 이것이었습니다.
컨테이너보다 블록체인 데이터 폴더가 더 중요하다.
컨테이너는 다시 만들 수 있지만, 수백 GB 이상 동기화한 블록체인 데이터는 다시 받으려면 시간이 오래 걸리기 때문입니다.
4단계. 환경 변수 설정
스크린샷 기준 환경 변수는 아래와 비슷했습니다.
- PATH
- HOME=/bitcoin
- BITCOIN_NETWORK=mainnet
PATH
Linux 환경에서 실행 명령어를 찾는 기본 경로입니다.
기본값 그대로 사용했습니다.
HOME=/bitcoin
컨테이너 내부 기본 작업 디렉터리입니다.
Bitcoin 관련 파일들이 /bitcoin 기준으로 동작하도록 구성되어 있었습니다.
BITCOIN_NETWORK=mainnet
이 설정은 어떤 비트코인 네트워크에 연결할지 결정합니다.
mainnet은 실제 비트코인 네트워크를 의미합니다.
즉, 테스트 네트워크가 아니라 실제 BTC 네트워크에 참여하는 설정입니다.
5단계. 네트워크는 host 모드로 설정
이번 구성에서는 Docker bridge 대신 host 모드를 사용했습니다.
처음에는 Docker 네트워크 개념도 꽤 헷갈렸습니다.
특히
- bridge
- host
- port mapping
- localhost
- 127.0.0.1
같은 개념이 익숙하지 않았습니다.
처음에는 bridge 방식도 고려했지만, 이후 Fulcrum과 Bitcoin Core RPC 연결 과정에서 네트워크 구조가 조금 복잡하게 느껴졌습니다.
특히 127.0.0.1이
- NAS 자체를 의미하는지
- Docker 컨테이너 내부를 의미하는지
처음에는 이해하기가 쉽지 않았습니다.
반면 host 모드로 변경한 뒤에는 구조가 훨씬 단순해졌습니다.
실제 구성은 아래처럼 정리되었습니다.
Bitcoin Core RPC → 127.0.0.1:8332
Fulcrum → 127.0.0.1:8332로 연결
즉, 같은 NAS 내부에서 직접 통신하는 구조입니다.
이 방식은 다음과 같은 장점이 있었습니다.
- 설정이 단순함
- RPC 연결 이해가 쉬움
- Docker 내부 네트워크를 별도로 신경 쓰지 않아도 됨
다만 host 모드가 항상 정답이라는 뜻은 아닙니다.
Docker bridge 모드와 포트 매핑으로도 구성할 수 있으며, 각 방식은 네트워크 구조와 보안 정책에 따라 선택하면 됩니다.
host 모드는 NAS와 동일한 네트워크 공간을 사용하기 때문에 포트 충돌과 보안 설정은 특히 주의해야 합니다.
아래 화면처럼 네트워크는 host 모드로 설정했고, 실행 명령은 bitcoind로 지정했습니다.
이 구성에서는 이후 Fulcrum과 Bitcoin Core RPC 연결 구조를 이해하기가 조금 더 단순했습니다.
6단계. 실행 명령(Command)
설정값은 다음과 같았습니다.
Entrypoint
docker-entrypoint.sh
실행 명령
bitcoind
이 설정은 컨테이너 시작 시 어떤 프로그램을 실행할지 결정합니다.
docker-entrypoint.sh → 시작 전 준비 작업
bitcoind → 실제 Bitcoin Core 서버 실행
즉, 컨테이너가 시작되면 NAS 안에서 Bitcoin Core 풀노드가 동작하게 됩니다.
7단계. bitcoin.conf 설정
Bitcoin Core 설치 후에는 bitcoin.conf 파일로 주요 설정을 관리했습니다.
처음에는 설정 항목이 많아 어렵게 느껴졌지만, 실제로는 핵심 설정만 이해해도 전체 구조를 파악하는 데 큰 도움이 되었습니다.
제가 실제로 사용한 설정은 아래와 비슷했습니다.
server=1
daemon=0
printtoconsole=1
disablewallet=1
txindex=1
rpcbind=127.0.0.1:8332
rpcallowip=127.0.0.1
rpcuser=사용자이름
rpcpassword=강력한비밀번호
dbcache=4096
par=4
maxconnections=80
maxmempool=300
mempoolexpiry=24
위 설정은 예시입니다.
실제 운영 환경에서는 NAS 성능, 메모리, 디스크 상태, 보안 정책에 따라 조정해야 합니다.
특히 RPC 계정 정보는 절대 공개하면 안 됩니다.
server=1
RPC 서버 기능을 활성화하는 설정입니다.
Fulcrum이 Bitcoin Core와 통신하기 위해 필요했습니다.
쉽게 말하면
“외부 프로그램이 Bitcoin Core와 대화할 수 있도록 허용”
하는 기능입니다.
다만 여기서 말하는 외부 프로그램은 공용 인터넷 사용자가 아니라, 같은 NAS 내부에서 동작하는 Fulcrum 같은 프로그램을 의미합니다.
daemon=0
Docker 환경에서는 foreground 실행이 로그 확인에 더 편했습니다.
그래서 daemon=0으로 설정했습니다.
컨테이너 환경에서는 프로세스가 앞에서 실행되고, 로그가 Container Manager에서 보이는 구조가 관리하기 더 쉬웠습니다.
printtoconsole=1
로그를 Docker 콘솔로 출력하는 설정입니다.
이 덕분에 다음과 같은 내용을 쉽게 확인할 수 있었습니다.
- 블록 다운로드
- peer 연결
- UpdateTip
- 동기화 진행률
처음에는 로그를 보는 것이 어렵게 느껴졌지만, 시간이 지나면서 로그가 가장 중요한 상태 확인 도구라는 생각이 들었습니다.
disablewallet=1
Bitcoin Core 내부 지갑 기능을 비활성화하는 설정입니다.
이번 구성에서는 Bitcoin Core를 ‘노드 서버’ 역할로만 사용했고, 실제 비트코인 보관과 서명은 별도 지갑(Keystone, BlueWallet 등)에서 처리하는 구조로 구성했습니다.
Bitcoin Core → 블록 검증 및 RPC 역할
BlueWallet / Keystone 등 → 실제 지갑 역할
그래서 Bitcoin Core 내부 지갑 기능은 사용하지 않았습니다.
저처럼 Bitcoin Core를 풀노드와 RPC 서버 용도로만 사용할 계획이라면, `disablewallet=1`로 구성하는 것도 하나의 방법이라고 느꼈습니다.
txindex=1
전체 트랜잭션 인덱스를 생성하는 설정입니다.
Fulcrum 같은 Electrum 서버와 연동하려면 전체 거래 조회와 인덱싱 구조가 중요하기 때문에, 제 구성에서는 처음부터 txindex=1을 활성화했습니다.
다만 이 설정은 장점과 단점이 있습니다.
장점
- 전체 거래 조회 가능
- txid 기반 조회에 유리
- Electrum 서버 연동 구조에 도움
단점
- 저장 공간 증가
- 초기 인덱싱 시간 증가
- 디스크 사용량 증가
Fulcrum 연동을 계획하고 있다면 txindex 설정은 초기 단계에서 함께 고려하는 것이 좋습니다.
나중에 켜면 다시 인덱싱 시간이 필요할 수 있기 때문입니다.
rpcbind / rpcallowip
예시 설정은 아래와 같습니다.
rpcbind=127.0.0.1:8332
rpcallowip=127.0.0.1
이 부분은 보안상 매우 중요하다고 느꼈습니다.
RPC는 Bitcoin Core를 제어할 수 있는 관리 인터페이스에 가깝습니다.
즉,
- 블록 조회
- 거래 조회
- 노드 상태 확인
- 설정에 따른 제어 작업
등이 가능합니다.
따라서 RPC를 외부 인터넷에 공개하면 안 됩니다.
이번 구성에서는 RPC를 로컬 환경에서만 사용하도록 제한했고, 외부 포트로 열지 않는 방향으로 구성했습니다.
구조는 아래처럼 이해하면 됩니다.
즉, NAS 내부에서만 통신하도록 제한한 것입니다.
이 부분은 설정 실수 시 보안 문제가 될 수 있으므로 특히 조심해야 한다고 느꼈습니다.
rpcuser / rpcpassword
RPC 인증 계정입니다.
Fulcrum이 Bitcoin Core와 연결할 때 사용합니다.
예시는 아래처럼 적을 수 있습니다.
- rpcuser=사용자이름
- rpcpassword=강력한비밀번호
다만 실제 블로그나 공개 문서에는 RPC 사용자명과 비밀번호를 절대 그대로 노출하면 안 됩니다.
이 글에서는 구조 이해를 위해 단순 예시 형태로만 정리했습니다.
초보자 입장에서는 rpcuser와 rpcpassword 형태가 이해하기 쉽지만, 장기 운영에서는 rpcauth 방식도 고려할 수 있습니다.
rpcauth는 평문 비밀번호를 그대로 설정하는 방식보다 운영 환경에서 더 적절할 수 있으므로, 실제 운영 시에는 별도로 확인해보는 것이 좋습니다.
dbcache=4096
Bitcoin Core 블록 검증 캐시 메모리 설정입니다.
메모리를 조금 더 사용하는 대신 초기 동기화 성능 향상에 도움이 될 수 있습니다.
제 환경은 RAM을 업그레이드한 NAS였기 때문에 4096MB 정도로 설정해 운영했습니다.
다만 이 값은 모든 환경에 그대로 적용할 값은 아닙니다.
메모리가 부족한 환경에서 dbcache를 너무 크게 잡으면 swap이 발생해 오히려 느려질 수 있습니다.
따라서 NAS의 전체 메모리, 동시에 실행 중인 다른 서비스, Docker 컨테이너 수 등을 고려해서 조정하는 것이 좋습니다.
par=4
병렬 검증 thread 수 설정입니다.
CPU 코어를 활용해 블록 검증을 수행합니다.
NAS의 CPU 성능과 동시에 실행 중인 서비스에 따라 적절한 값은 달라질 수 있습니다.
maxconnections=80
동시에 연결 가능한 peer 수입니다.
값이 너무 높으면 네트워크와 시스템 리소스 사용량이 증가할 수 있습니다.
개인 NAS 환경에서는 무조건 크게 잡기보다, 안정적으로 운영 가능한 수준을 찾는 것이 좋다고 느꼈습니다.
maxmempool=300
mempool 최대 메모리 사용량 설정입니다.
mempool은 아직 블록에 포함되지 않은 거래를 임시 저장하는 공간입니다.
이 값 역시 메모리 사용량과 관련이 있으므로, NAS 환경에 맞춰 조정할 수 있습니다.
mempoolexpiry=24
오랫동안 처리되지 않은 거래를 mempool에서 제거하는 시간 설정입니다.
설정값에 따라 mempool에 남아 있는 거래의 유지 시간이 달라질 수 있습니다.
초기 동기화(Initial Sync)
설치 후 가장 오래 걸렸던 과정은 초기 동기화였습니다.
처음에는
“설치가 끝났는데 왜 바로 사용이 안 되지?”
라는 생각도 들었습니다.
하지만 실제로는 다음 과정이 필요했습니다.
- 전체 블록 다운로드
- 블록 검증
- txindex 생성
특히 HDD 기반 NAS 환경에서는 진행 속도가 생각보다 느리게 느껴졌고, 처음에는 정상 동작 중인지 판단하기 쉽지 않았습니다.
제 경우에는 NAS 환경에서 Bitcoin Core 동기화와 txindex 생성까지 꽤 긴 시간이 필요했습니다.
이후 Fulcrum 인덱싱까지 포함하면 며칠에 걸쳐 진행 상황을 계속 확인하게 되었습니다.
동기화 중에는 HDD 접근량이 꽤 많았고, NAS 반응 속도도 평소보다 느려지는 느낌이 있었습니다.
다만 이 과정은 환경에 따라 크게 달라질 수 있습니다.
- 저장장치가 HDD인지 SSD인지
- CPU 성능
- 메모리 크기
- 네트워크 상태
- txindex 사용 여부
에 따라 체감 시간이 달라질 수 있습니다.
컨테이너가 정상적으로 실행되면 Container Manager에서 실행 상태와 이미지 이름, 볼륨, 환경 변수, 네트워크 설정 등을 한눈에 확인할 수 있습니다.
로그를 보기 전까지는 상태를 판단하기 어려웠다
처음에는 화면상 변화가 거의 없어 정상 여부를 판단하기 어려웠습니다.
하지만 Container Manager 로그를 보기 시작하면서 조금씩 상태를 이해할 수 있었습니다.
특히 아래와 같은 로그들이 계속 보이는 것을 보고 정상적으로 동작 중이라는 것을 확인할 수 있었습니다.
실제 로그를 블로그에 올릴 때는 peer IP, 내부 경로, 계정명, 민감한 값이 포함되어 있지 않은지 확인하고 일부는 마스킹하는 편이 좋습니다.
Peer 연결 로그
New outbound-full-relay v2 peer connected
이 로그는 다른 비트코인 노드(peer)와 정상적으로 연결되었다는 의미입니다.
즉, 내 NAS가 실제 비트코인 네트워크에 참여하기 시작했다는 뜻입니다.
처음에는 peer가 하나씩 늘어나는 것을 보면서 실제로 네트워크 연결이 진행 중이라는 것을 확인할 수 있었습니다.
UpdateTip 로그
UpdateTip: new best=000000000000000000…
height=950361
progress=1.000000
이 로그는 새로운 블록을 받아 현재 체인 상태가 업데이트되었다는 의미입니다.
특히
height → 현재 동기화된 블록 높이
progress → 전체 동기화 진행률
을 확인할 수 있었습니다.
처음에는 숫자가 너무 길어 복잡하게 느껴졌지만, 실제로는 블록 높이와 진행률을 보는 것이 중요했습니다.
stale tip 로그
Potential stale tip detected, will try using extra outbound peer
처음에는 오류처럼 보였지만, 실제로는 최근 블록 업데이트가 없어 Bitcoin Core가 추가 peer 연결을 시도하는 정상 동작 중 하나였습니다.
즉,
“최근 블록 업데이트가 없으니 다른 노드와 더 연결해보자”
정도로 이해하면 편했습니다.
Initial Block Download 종료 로그
Leaving InitialBlockDownload (latching to false)
이 로그가 보이면 초기 블록 다운로드(IBD)가 거의 완료된 상태라고 볼 수 있습니다.
즉,
- 블록 다운로드
- 블록 검증
- 기본 동기화
가 대부분 완료되었다는 의미입니다.
이 로그를 처음 봤을 때는 꽤 반가웠습니다.
txindex 활성화 로그
txindex is enabled at height 937186
이 로그는 txindex=1 설정에 따라 전체 거래 인덱스가 활성화되었다는 의미입니다.
Fulcrum을 연결하려면 중요한 단계 중 하나였습니다.
실제 운영하면서 느낀 점
처음에는 단순히 “설치만 해보자” 정도로 시작했습니다.
하지만 실제로 운영해보니 NAS가 단순 저장장치가 아니라 작은 서버처럼 느껴졌습니다.
특히
- 블록 검증
- 거래 검증
- 네트워크 참여
를 직접 수행한다는 점이 꽤 흥미롭게 느껴졌습니다.
반면 현실적인 부분도 분명히 있었습니다.
- 저장 공간 증가
- 디스크 접근 증가
- 초기 동기화 시간
- 설정 관리
- 백업 고려
- 보안 설정 확인
이런 부분을 함께 신경 써야 했습니다.
또한 단순히 앱을 사용하는 것과 직접 노드를 운영하는 것은 느낌이 꽤 달랐습니다.
실제로 블록체인을 다운로드하고 검증하면서 비트코인 네트워크 구조를 더 깊게 이해하게 된 느낌이 있었습니다.
마무리
이번 글에서는 Synology NAS에서 Docker를 이용해 Bitcoin Core를 설치하고, 초기 동기화를 시작하는 과정을 정리했습니다.
핵심을 다시 정리하면 다음과 같습니다.
- Bitcoin Core는 비트코인 블록체인을 직접 다운로드하고 검증하는 풀노드입니다.
- Synology NAS에서는 Docker를 이용해 Bitcoin Core를 컨테이너 형태로 운영할 수 있습니다.
- Bitcoin Core 데이터는 계속 증가하므로 충분한 저장공간을 확보하는 것이 중요합니다.
- RPC 설정은 Fulcrum과 연결하기 위한 내부 통로이며, 외부 인터넷에 공개하지 않는 것이 좋습니다.
이번 글이 Bitcoin Core를 설치하고 동기화를 시작하는 단계였다면, 다음 글에서는 실제로 Fulcrum을 설치하고 Bitcoin Core RPC와 연결하는 과정을 정리했습니다.
NAS로 비트코인 풀노드 구축하기 3편: Fulcrum 설치와 Bitcoin Core RPC 연결하기
참고로 주의할 점
Bitcoin Core를 NAS에서 운영하는 것은 단순한 앱 설치와는 다릅니다.
특히 아래 사항은 미리 확인하는 것이 좋습니다.
- 충분한 저장 공간
- 장시간 동작 가능한 네트워크 환경
- NAS의 디스크 상태
- 다른 서비스에 미치는 영향
- RPC 보안 설정
- 중요한 데이터 백업
저처럼 처음 시작하는 경우라면, 한 번에 모든 구조를 완성하려고 하기보다 Bitcoin Core 설치와 동기화부터 차근차근 확인하는 것이 좋다고 느꼈습니다.
이 글은 개인적인 설치 경험과 학습 내용을 바탕으로 정리한 참고용 글입니다.
NAS 환경, 저장 공간, 네트워크 구성에 따라 실제 성능과 운영 방식은 달라질 수 있으며, 중요한 데이터는 반드시 별도로 백업 후 진행하시기 바랍니다.