--- title: "풀 노드" title_en: "Full Node" type: 용어 url: https://wiki.tokenpost.kr/w/full-node canonical: https://wiki.tokenpost.kr/w/full-node language: ko publisher: "토큰포스트" updated: 2026-08-06T03:32:50.677+00:00 created: 2026-07-28T23:23:49.076752+00:00 status: draft --- # 풀 노드 > Full Node > **인용 전에 확인해 주세요.** 이 문서는 자동으로 만든 초안이며 사람의 > 검수를 거치지 않았습니다. 사실 관계는 아래 각주의 원문으로 확인해 주세요. **분류**: 용어 풀 노드는 블록체인의 분산원장 전체를 스스로 내려받아 보관하고, 새로 전파되는 블록과 트랜잭션이 네트워크 규칙을 어기지 않는지 독립적으로 검증하는 노드이다. 그 수와 분산 정도는 블록체인의 탈중앙화와 검열 저항성을 떠받치는 핵심 요소로 여겨진다. ## 1. 개요 풀 노드(Full Node)는 블록체인 네트워크에서 [분산원장](https://wiki.tokenpost.kr/w/distributed-ledger) 전체를 내려받아 보관하고, 새로 전파되는 [블록](https://wiki.tokenpost.kr/w/block)과 트랜잭션이 네트워크의 [합의 알고리즘](https://wiki.tokenpost.kr/w/consensus-algorithm) 및 규칙을 위반하지 않는지 스스로 검증하는 [노드](https://wiki.tokenpost.kr/w/node)이다. 다른 노드나 제3자의 판단에 의존하지 않고 [제네시스 블록](https://wiki.tokenpost.kr/w/genesis-block)부터 최신 블록까지의 이력을 직접 확인하기 때문에, 잘못되었거나 [이중지불](https://wiki.tokenpost.kr/w/double-spending)된 트랜잭션, 규칙을 어긴 블록을 스스로 거부할 수 있다. 풀 노드는 [P2P](https://wiki.tokenpost.kr/w/p2p) 방식으로 다른 노드들과 연결되어 유효한 트랜잭션과 블록을 서로 중계한다. 각 노드가 동일한 검증 규칙을 독립적으로 적용하므로, 전체 네트워크는 중앙 관리자 없이도 하나의 일관된 [원장](https://wiki.tokenpost.kr/w/ledger) 상태를 유지한다. 이런 의미에서 풀 노드의 수와 분산 정도는 [블록체인](https://wiki.tokenpost.kr/w/blockchain)의 [탈중앙화](https://wiki.tokenpost.kr/w/decentralization)와 [검열 저항성](https://wiki.tokenpost.kr/w/censorship-resistance)을 뒷받침하는 핵심 요소로 여겨진다. ## 2. 무엇을 검증하는가 풀 노드는 도착한 블록과 트랜잭션에 대해 여러 층위의 규칙을 확인하며, 하나라도 어긋나면 이를 거부하고 이웃 노드로 전파하지 않는다. - **서명 검증**: 각 트랜잭션의 [전자서명](https://wiki.tokenpost.kr/w/digital-signature)이 올바른 개인키로 서명되었는지 확인해 자금의 소유권을 검증한다. - **이중지불 방지**: 이미 사용된 출력이 다시 쓰이지 않는지, 입력 합계가 출력 합계 이상인지 확인한다. - **발행량 규칙**: 블록이 만들어내는 신규 발행량과 [블록 보상](https://wiki.tokenpost.kr/w/block-reward)이 프로토콜이 정한 한도를 넘지 않는지 검증한다. - **합의·형식 규칙**: 블록의 크기와 형식, [합의 알고리즘](https://wiki.tokenpost.kr/w/consensus-algorithm)이 요구하는 조건, 타임스탬프 등이 규칙에 맞는지 확인한다. 이 규칙은 노드가 실행하는 소프트웨어에 담겨 있으므로, 운영자가 어떤 버전의 클라이언트를 구동하는지가 곧 그 노드가 인정하는 규칙 집합을 결정한다. ## 3. 초기 동기화와 동작 방식 새로 네트워크에 참여한 풀 노드는 다른 노드들로부터 블록체인 전체를 내려받아 각 블록을 순서대로 검증하는 초기 블록 다운로드(IBD, initial block download) 과정을 거친다. 체인이 길수록 이 과정에는 상당한 시간과 저장 공간, 대역폭이 필요하다. 동기화가 끝난 뒤에는 새로 전파되는 트랜잭션을 임시 저장소인 [멤풀](https://wiki.tokenpost.kr/w/mempool)에 담아 유효성을 확인하고, 채굴자나 검증자가 만든 새 블록이 도착하면 그 안에 담긴 모든 트랜잭션과 서명, 발행량 등이 규칙에 맞는지 다시 검증한 뒤 자신의 원장에 추가한다. 유효한 데이터는 [가십 프로토콜](https://wiki.tokenpost.kr/w/gossip-protocol) 방식으로 이웃 노드에 전파되어 네트워크 전체로 퍼진다. 서로 다른 체인 분기가 관찰되면 풀 노드는 합의 규칙에 따라 유효한 체인 가운데 하나를 선택한다. ## 4. 노드의 종류와 구분 풀 노드가 반드시 [채굴](https://wiki.tokenpost.kr/w/mining)에 참여하는 것은 아니다. 블록을 직접 생성하지 않고 검증과 중계만 담당하는 풀 노드가 많으며, 채굴·검증 노드는 풀 노드의 검증 기능 위에 새 블록을 만드는 역할이 더해진 형태로 볼 수 있다. - **검증 전용 풀 노드**: 블록을 만들지 않고 규칙 검증과 데이터 중계만 수행한다. - **채굴·검증 노드**: 풀 노드 기능에 더해 [블록](https://wiki.tokenpost.kr/w/block)을 생성하고 [블록 보상](https://wiki.tokenpost.kr/w/block-reward)을 받는다. - **경량 노드(라이트 클라이언트)**: 전체 데이터를 보관하지 않고 [블록 헤더](https://wiki.tokenpost.kr/w/block-header) 등 일부만 유지하며, 검증의 상당 부분을 풀 노드에 의존한다. 풀 노드는 검증에 필요한 데이터를 스스로 보유한다는 점에서 경량 노드와 구분된다. 또한 일부 네트워크의 [마스터노드](https://wiki.tokenpost.kr/w/masternode)처럼 풀 노드를 상시 운영하는 대가로 보상이나 특별한 역할(즉시 전송, 거버넌스 투표 등)을 부여하는 구조도 존재한다. ## 5. 데이터 보관 방식: 아카이브와 프루닝 풀 노드 가운데도 과거 데이터를 얼마나 보관하느냐에 따라 세부 유형이 나뉜다. **아카이브 노드**는 [제네시스 블록](https://wiki.tokenpost.kr/w/genesis-block) 이후의 모든 블록과 각 시점의 상태(state)를 완전하게 보관해, 임의의 과거 잔액이나 이력을 즉시 조회할 수 있다. 이 때문에 [블록 익스플로러](https://wiki.tokenpost.kr/w/block-explorer)나 분석 서비스가 아카이브 노드를 활용한다. 반면 **프루닝(가지치기)** 모드로 운영되는 풀 노드는 검증을 모두 마친 오래된 블록 데이터를 삭제해 저장 공간을 절약하면서도, 새 블록을 검증하는 데 필요한 최신 상태는 그대로 유지한다. 프루닝 노드는 저장 부담이 작지만 과거 원본 블록을 다른 노드에 제공하지는 못한다. ## 6. 탈중앙화와 검열 저항성에서의 역할 독립적으로 규칙을 강제하는 풀 노드가 많고 널리 분산될수록, 소수의 주체가 원장 내용을 바꾸거나 특정 거래를 배제하기 어려워진다. 채굴자나 검증자가 규칙을 어긴 블록을 만들더라도, 이를 받아들이는 풀 노드가 없다면 그 블록은 네트워크에서 사실상 무효가 된다. 이런 구조 때문에 풀 노드는 규칙을 최종적으로 강제하는 주체로 설명되며, [하드 포크](https://wiki.tokenpost.kr/w/hard-fork)나 프로토콜 변경 논쟁에서 어떤 규칙이 실제로 채택될지는 다수 풀 노드가 어떤 소프트웨어를 실행하느냐에 크게 좌우된다. 다만 풀 노드는 블록을 직접 생성하지는 않으므로, 검증 권한과 블록 생성 권한([채굴](https://wiki.tokenpost.kr/w/mining)·검증)의 분리는 탈중앙화 논의에서 자주 함께 다뤄진다. ## 7. 운영과 하드웨어 요구 풀 노드는 대개 별도의 허가 없이 누구나 소프트웨어를 내려받아 실행할 수 있다. 다만 전체 체인을 보관해야 하므로 상당한 저장 공간이 필요하며, 오래 운영된 주요 네트워크에서는 그 크기가 수백 기가바이트에 이르기도 한다. 초기 동기화와 지속적인 블록·트랜잭션 중계에는 안정적인 네트워크 대역폭과 상시 연결이 요구된다. [비트코인](https://wiki.tokenpost.kr/w/bitcoin)의 비트코인 코어, [이더리움](https://wiki.tokenpost.kr/w/ethereum)의 실행 클라이언트 등 네트워크마다 공식·비공식 풀 노드 소프트웨어가 존재한다. 특히 이더리움은 2022년 합의 방식 전환 이후 풀 노드를 운영하려면 실행 클라이언트와 [합의](https://wiki.tokenpost.kr/w/consensus-algorithm) 클라이언트를 함께 구동해야 한다. ## 8. 보안과 공격 풀 노드는 스스로 검증하므로 잘못된 데이터를 곧이곧대로 받아들일 위험은 낮지만, 네트워크 연결 자체를 겨냥한 공격에는 노출될 수 있다. 대표적으로 [이클립스 공격](https://wiki.tokenpost.kr/w/eclipse-attack)은 특정 노드의 연결을 공격자가 통제하는 노드들로 둘러싸 그 노드를 실제 네트워크로부터 격리시키는 방식이다. 이렇게 고립된 노드는 조작된 체인을 진짜로 오인하거나 [이중지불](https://wiki.tokenpost.kr/w/double-spending)에 악용될 수 있다. 이 밖에 다수의 가짜 노드를 만들어 네트워크의 판단을 왜곡하는 시빌 공격, 연결과 자원을 고갈시키는 [디도스 공격](https://wiki.tokenpost.kr/w/ddos) 등이 노드 수준의 위협으로 논의된다. 널리 분산된 다수의 풀 노드는 이러한 공격과 [51% 공격](https://wiki.tokenpost.kr/w/51-attack)의 영향력을 줄이는 데도 기여한다. ## 9. 주요 네트워크에서의 풀 노드 풀 노드의 구체적 형태는 네트워크마다 다르다. [비트코인](https://wiki.tokenpost.kr/w/bitcoin)에서는 초기 클라이언트부터 풀 노드가 네트워크의 기반이었고, 프루닝 모드로 저장 부담을 줄인 노드도 널리 쓰인다. [이더리움](https://wiki.tokenpost.kr/w/ethereum)에서는 최신 상태만 유지하는 풀 노드와 모든 과거 상태를 보관하는 아카이브 노드가 구분된다. [위임 지분증명](https://wiki.tokenpost.kr/w/delegated-proof-of-stake)이나 마스터노드를 채택한 네트워크에서는 풀 노드 운영이 보상·거버넌스와 직접 연결되기도 한다. 또한 [라이트닝 네트워크](https://wiki.tokenpost.kr/w/lightning-network)와 같은 [레이어 2](https://wiki.tokenpost.kr/w/layer-2) 구조도 기반이 되는 체인의 상태를 확인하기 위해 풀 노드에 의존하는 경우가 많다. ## 10. 역사와 배경 풀 노드 모델은 2008년 공개된 비트코인 백서에서 그 원형이 제시되었다. 백서는 네트워크의 모든 규칙을 검증하는 노드와, 블록 헤더만으로 간이 검증을 수행하는 경량 클라이언트(SPV, 간이 결제 검증)를 구분해 설명했다. 2009년 비트코인 네트워크가 가동되면서 초기 클라이언트 자체가 풀 노드로 동작했고, 이후 2015년 출시된 [이더리움](https://wiki.tokenpost.kr/w/ethereum) 등 후발 네트워크도 각자의 풀 노드 소프트웨어를 갖추었다. 2017년 비트코인의 블록 크기 논쟁과 세그윗(SegWit) 도입 과정에서는, 이용자들이 직접 실행하는 풀 노드가 어떤 규칙을 받아들이는지가 프로토콜 변경의 향방을 좌우한다는 점이 부각되었다. ## 11. 한계와 과제 풀 노드는 탈중앙화의 근간이지만 운영에는 비용과 부담이 따른다. 체인 데이터가 계속 커지면서 저장 공간과 대역폭 요구가 늘어나면 개인이 풀 노드를 유지하기 어려워지고, 노드 운영이 소수의 대형 사업자에게 집중될 수 있다는 우려가 있다. 이는 곧 네트워크의 [탈중앙화](https://wiki.tokenpost.kr/w/decentralization) 수준을 떨어뜨리는 요인이 된다. 이 때문에 프루닝, 데이터 샤딩, 무상태(stateless) 검증 같은 기법으로 풀 노드의 진입 장벽을 낮추려는 연구가 이어지고 있다. 풀 노드가 얼마나 쉽고 저렴하게 운영될 수 있는지는 블록체인의 [검열 저항성](https://wiki.tokenpost.kr/w/censorship-resistance)을 가늠하는 실질적 지표로 여겨진다. ## 12. 연표 - **2008** (이정표) 비트코인 백서가 네트워크 규칙을 검증하는 노드와 간이 검증(SPV) 경량 클라이언트를 구분해 풀 노드 모델의 원형을 제시 - **2009** (설립) 비트코인 네트워크 가동, 초기 클라이언트 자체가 풀 노드로 동작 - **2015** (이정표) 이더리움 메인넷 출시로 후발 네트워크도 자체 풀 노드 소프트웨어(Geth 등)를 갖춤 - **2017** (이정표) 비트코인 블록 크기 논쟁과 세그윗(SegWit) 도입 과정에서 이용자가 운영하는 풀 노드의 규칙 강제 역할이 부각 - **2022** (이정표) 이더리움 합의 방식 전환 이후 풀 노드 운영에 실행 클라이언트와 합의 클라이언트의 동시 구동이 필요해짐 --- 원문: https://wiki.tokenpost.kr/w/full-node 최종 수정: 2026-08-06T03:32:50.677+00:00 발행: 토큰포스트 위키. 인용할 때 문서 제목과 원문 주소를 함께 밝혀 주세요.