블록체인 기초 개념

마지막 업데이트: 2026년 9월 12일

이 문서에서 다루는 것

• 일부 ledger가 검증을 복제하는 이유와 full-node·light-client·permissioned 모델의 차이
• 합의·머클 트리·P2P·파이널리티의 역할과, 각각이 인프라 운영에 만드는 제약
• 왜 블록체인 노드가 일반적인 상태 저장 서비스와 다르게 다뤄져야 하는가

문제 정의 — 신뢰할 수 있는 중재자 없이 합의하기

블록체인을 이해하는 출발점은 기술이 아니라 제약 조건입니다.

일반적인 분산 시스템, 예를 들어 Kubernetes의 etcd 클러스터를 생각해 보십시오. etcd도 여러 노드가 합의를 이루는 시스템이지만, 전제가 하나 있습니다 — 참여 노드들은 같은 조직이 운영하고, 고장은 나지만 거짓말은 하지 않는다는 전제입니다. 노드가 죽거나 네트워크가 끊기는 것(crash fault)은 다루지만, 노드가 의도적으로 다른 값을 주장하는 것은 상정하지 않습니다.

블록체인의 전제는 다릅니다.

항목	etcd (Raft)	블록체인
참여자	같은 조직, 알려진 멤버	서로 모르는 주체, 멤버 변동
가정하는 고장	crash fault (죽음, 네트워크 분단)	byzantine fault (거짓말, 담합, 공격)
참여 자격	운영자가 지정	퍼블릭 체인은 누구나
되돌릴 수 있는가	운영자가 개입 가능	프로토콜이 정한 것만

많은 공개 체인의 full node는 transaction과 consensus 규칙을 독립 검증합니다. Light client·pruned/snapshot-sync node·permissioned 설계의 검증/데이터 배포 방식은 다릅니다. Permissioned membership 자체가 consensus 알고리즘에 Byzantine fault tolerance를 부여하지는 않습니다.

여기서 블록체인의 근본적인 성질이 나옵니다.

블록체인은 처리량을 위해 설계된 시스템이 아닙니다. 검증 가능성과 변조 저항을 위해 의도적으로 중복을 감수하는 시스템입니다.

이것을 이해하면 뒤의 운영 특성이 전부 자연스럽게 따라옵니다.

블록과 체인 — 왜 "체인"인가

거래들을 묶은 것이 블록이고, 각 블록은 직전 블록의 해시를 담습니다.

블록 N-1                블록 N                  블록 N+1
┌──────────────┐       ┌──────────────┐        ┌──────────────┐
│ prev_hash:.. │       │ prev_hash: ──┼────────│ prev_hash: ──┤
│ merkle_root  │   ┌───│ merkle_root  │        │ merkle_root  │
│ 거래들...     │───┘   │ 거래들...     │        │ 거래들...     │
└──────────────┘       └──────────────┘        └──────────────┘
      해시 ─────────────────┘

이 구조가 주는 성질이 변조의 파급입니다. 블록 N의 거래 하나를 바꾸면 → 블록 N의 해시가 바뀌고 → 블록 N+1의 prev_hash가 안 맞고 → 그 뒤 전부가 무효가 됩니다.

PoW 체인의 이력 변경에는 충분히 수용되는 work를 다시 만들어야 하며 다른 체인은 다른 finality·governance 가정을 사용합니다. Hash 연결은 변조를 탐지하게 하지만 그 자체로 finality나 모든 체인의 경제적 불변성을 보장하지 않습니다.

머클 트리 — 왜 필요한가

블록의 거래들을 어떻게 요약할 것인가의 문제입니다. 단순히 전부 이어붙여 해시할 수도 있지만, 그러면 "이 거래가 이 블록에 있는가"를 확인하려면 블록 전체가 필요합니다.

머클 트리는 거래들을 쌍쌍이 해시해 올라가는 이진 트리입니다.

                merkle_root
               /            \
         H(AB)                H(CD)
        /     \              /     \
     H(A)    H(B)         H(C)    H(D)
      |        |            |        |
     거래A    거래B        거래C    거래D

여기서 나오는 성질이 **머클 증명(Merkle proof)**입니다. 거래 C가 이 블록에 있음을 증명하려면 전체가 아니라 H(D)와 H(AB)만 주면 됩니다. 받는 쪽은 H(C)를 계산하고 → H(CD) → merkle_root를 계산해 대조합니다.

증명 크기가 거래 수 N에 대해 log N으로 자랍니다. 거래 100만 개 블록에서도 증명은 20개 해시 정도입니다.

실무적 의미: 이것이 경량 클라이언트(light client)를 가능하게 합니다. 전체 체인을 갖지 않고도 특정 거래의 포함 여부를 검증할 수 있습니다. 블록체인과 기존 시스템을 연동할 때 "전체 노드를 운영할 것인가, 경량 검증으로 충분한가"라는 선택지가 생기는 근거입니다.

합의 — 누가 다음 블록을 쓰는가

합의 알고리즘은 두 가지를 정합니다 — 누가 블록을 제안하는가, 그리고 충돌이 나면 어느 쪽이 정본인가.

주요 방식

방식	제안자 선정	비용의 실체	대표
PoW (Proof of Work)	계산 퍼즐을 먼저 푼 노드	전기·하드웨어	Bitcoin
PoS (Proof of Stake)	예치금(stake)에 비례한 확률로 선정	예치 자본 + 위반 시 몰수(slashing)	Ethereum
BFT 계열	정의한 Byzantine fault threshold 아래 투표	Membership/validator·quorum 가정	Tendermint; Fabric 3.x SmartBFT
CFT permissioned ordering	알려진 replica가 crash-fault-tolerant consensus 사용	임의 Byzantine ordering 동작을 견디지 못함	Fabric Raft

왜 비용이 필요한가

이 질문이 합의를 이해하는 핵심입니다. "블록 제안에 비용이 없으면 무한히 많은 후보를 만들어 네트워크를 마비시킬 수 있습니다." 익명 참여가 가능한 환경에서 정체성만으로는 이를 막을 수 없습니다(Sybil 공격 — 한 주체가 수많은 신원을 만드는 것).

PoW는 계산으로, PoS는 자본과 몰수 위험으로 비용을 만듭니다. BFT 계열은 애초에 참여자를 제한해서 이 문제를 회피합니다 — 그래서 컨소시엄 체인에 적합합니다.

퍼블릭과 프라이빗의 구분이 여기서 나옵니다

유형	참여	합의	처리량	주 용도
퍼블릭 (permissionless)	누구나	PoW/PoS	낮음	공개 자산, 상호운용
프라이빗/컨소시엄 (permissioned)	승인된 멤버	BFT/Raft	상대적으로 높음	기업 간 원장, 규제 환경

Permissioned 설계는 알려진 membership과 명시적 governance를 활용하며 실제 위협 모델에 따라 CFT/BFT를 선택합니다. 금융 앱은 서로 다른 제어 아래 permissioned 또는 public network를 사용할 수 있으며 membership이나 consensus 명칭만으로 규제 준수가 성립하지는 않습니다.

파이널리티 — 운영에서 가장 중요한 개념

Finality는 프로토콜의 보안 가정 아래 정산된 상태를 설명합니다. 모든 공격·governance 개입·앱의 보정 transaction에 대한 무조건적 보장은 아닙니다. 확률적 신뢰·경제적 finality·결정적 consensus 보장을 구분합니다.

확률적 파이널리티 vs 절대적 파이널리티

유형	의미	예
확률적 (probabilistic)	블록이 쌓일수록 되돌릴 확률이 지수적으로 감소. 완전한 0은 아님	Bitcoin의 PoW
경제적	Finalized checkpoint는 stake/slashing 가정으로 보호되며 변경이 물리적으로 불가능한 것은 아님	Ethereum PoS
즉시 (immediate)	합의 라운드 종료 시 확정	BFT 계열

왜 이것이 운영 문제인가

노드가 응답하는 데이터가 아직 확정되지 않은 것일 수 있습니다.

블록체인 노드에 "이 거래 결과를 알려달라"고 물으면, 노드는 자기가 아는 최신 체인 기준으로 답합니다. 그런데 그 최신 블록이 나중에 재조직(reorg)되면 답이 달라집니다.

이것이 만드는 실제 사고 패턴:

패턴	결과
최신 블록 기준으로 입금을 확인하고 처리	reorg로 입금이 사라지는데 이미 출금됨
헬스체크가 "노드 살아있음"만 확인	동기화가 뒤처진 노드가 오래된 데이터를 반환
로드밸런서가 여러 노드에 분산	노드별 체인 높이가 달라 같은 질문에 다른 답

따라서 애플리케이션 설계에 "몇 블록 확인 후 처리"(confirmation depth)가 반드시 들어가야 하고, 그 값은 체인의 파이널리티 특성에 따라 달라집니다. 이것은 인프라만으로 해결할 수 없고 애플리케이션과의 계약입니다.

인프라 쪽에서 할 수 있는 것:

• 동기화 상태를 헬스체크에 포함 — "살아있음"이 아니라 "체인 선두에서 N블록 이내"를 준비 상태로 정의
• 노드 간 체인 높이 편차 모니터링 — 편차가 커지면 로드밸런싱에서 제외
• reorg 발생을 메트릭으로 노출 — 애플리케이션이 대응할 수 있게

P2P 네트워킹 — 왜 일반 서비스와 다른가

블록체인 노드는 클라이언트-서버가 아니라 피어 간 통신을 합니다. 이것이 Kubernetes 네트워킹 모델과 마찰을 일으킵니다.

가십 프로토콜

새 블록이나 거래가 생기면 이웃 피어들에게 전파하고, 그들이 다시 자기 이웃에게 전파합니다. 전체가 알게 되는 방식입니다.

특성:

• 중앙 브로커가 없음 → 단일 장애점이 없음
• 같은 데이터가 여러 경로로 중복 도착 → 대역폭을 중복에 씁니다
• 전파에 시간이 걸림 → 노드마다 아는 최신 상태가 다름(위의 파이널리티 문제와 연결)

Kubernetes 환경에서의 마찰

블록체인 P2P의 요구	Kubernetes의 기본
안정적인 피어 신원 (노드 ID, 주소)	Pod IP는 재시작 시 변경
인바운드 연결 수용 — 다른 피어가 나에게 접속	Pod는 기본적으로 외부에서 직접 접근 불가
피어 목록의 지속성	Pod 교체 시 상태 소실
고정 포트로 광고	Service의 포트 매핑

그래서 블록체인 노드는 StatefulSet + Headless Service로 배치하는 것이 기본이 됩니다 — 안정적인 이름과 순서가 필요하기 때문입니다. 인바운드 P2P를 받으려면 추가 노출 설계가 필요합니다. 구체적인 방법은 EKS에서 블록체인 노드 운영에서 다룹니다.

상태와 스토리지 — 왜 재구축이 어려운가

블록체인 노드가 보관하는 것은 두 가지입니다.

데이터	성격	크기
블록 히스토리	추가만 되는 로그. 과거는 불변	계속 증가
현재 상태 (state)	잔액, 컨트랙트 저장소 등. 블록을 재생해 도출 가능	증가하되 히스토리보다 작음

핵심 성질: 상태는 히스토리에서 재생 가능하지만 그 재생에 오랜 시간이 걸립니다.

처음부터 모든 블록을 검증하며 재생하는 것(full sync)은 체인 나이에 비례해 시간이 듭니다. 그래서 대안 동기화 방식들이 존재합니다.

방식	하는 일	트레이드오프
full sync	제네시스부터 전부 검증·재생	가장 신뢰도 높음, 가장 느림
snap/fast sync	수용한 state root로 검증하는 proof와 함께 state를 얻음. 이력 검증은 client/mode별로 다름	더 빠르지만 consensus/checkpoint·구현 신뢰 가정을 확인하며 임의 peer를 무조건 믿는 것은 아님
checkpoint sync	신뢰하는 체크포인트에서 시작	가장 빠름, 체크포인트 출처를 신뢰
스냅샷 복원	운영자가 보관한 데이터 디렉터리 복원	빠름, 스냅샷 최신성·정합성 관리 필요

운영상 결론: Pod를 교체할 때 상태를 잃으면 안 됩니다. 잃으면 동기화에 시간이 걸리고 그 동안 그 노드는 서비스할 수 없습니다. 이것이 블록체인 노드에서 영구 볼륨이 선택이 아니라 필수인 이유입니다.

아카이브 노드 — 별도로 다뤄야 하는 존재

"과거 임의 시점의 상태"를 조회할 수 있는 노드를 아카이브 노드라고 합니다. 모든 중간 상태를 보관하므로 일반 노드보다 훨씬 큰 스토리지가 필요합니다.

설계 판단이 필요한 지점: 아카이브 기능이 정말 필요한지 먼저 확인하십시오. 대부분의 애플리케이션은 최근 상태만 필요하고, 과거 조회가 필요하면 인덱싱 서비스나 데이터 웨어하우스로 별도 처리하는 것이 비용 효율적입니다.

키 관리 — 잃으면 끝

블록체인에서 신원과 권한은 개인키입니다. 이것이 기존 시스템과 결정적으로 다른 점을 만듭니다.

기존 시스템	블록체인
비밀번호를 잊으면 재설정	키를 잃으면 자산·권한 영구 상실
계정 탈취 시 관리자가 동결	되돌릴 주체가 없음 (프로토콜이 허용하지 않으면)
감사 로그로 사후 추적	서명된 거래는 확정되면 되돌릴 수 없음

그래서 백업 전략의 성격이 다릅니다. 체인 데이터는 네트워크에서 다시 받을 수 있으므로 백업의 가치가 낮습니다. 반면 키는 백업이 절대적이고, 동시에 백업 자체가 유출 위험입니다.

이것이 HSM(Hardware Security Module)과 AWS KMS/CloudHSM이 블록체인 인프라에서 중요한 이유입니다. 특히 검증자(validator)는 키가 온라인에 있어야 서명할 수 있으면서 동시에 유출되면 안 되는 모순된 요구를 갖습니다. 금융권 관점에서 이 문제를 다룹니다.

운영 특성 정리 — 여기서 무엇이 파생되는가

지금까지의 개념이 만드는 운영 특성을 모으면 이렇습니다.

블록체인의 설계	파생되는 운영 특성	Kubernetes에서의 함의
복제된 full-node 검증	Replica 추가 자체가 base-chain 쓰기 용량을 늘리지는 않음	전체 RPC/read 용량과 가용성은 늘릴 수 있음
상태는 로컬에 누적	Pod 교체 비용이 매우 큼	StatefulSet + 영구 볼륨 필수, 노드 어피니티 고려
체인 동기화에 지연	"살아있음"과 "서비스 가능"이 다름	readiness에 동기화 상태 포함
파이널리티가 즉시가 아님	최신 데이터가 확정 데이터가 아님	confirmation depth를 애플리케이션 계약으로
P2P 가십	인바운드 연결과 안정적 신원 필요	Headless Service, 추가 노출 설계
Hard fork가 정해진 시점에 규칙 활성화	활성화 전에 호환 binary 업그레이드	사전 canary·rolling upgrade로 fleet 준비 가능
키가 곧 권한	키 유실 = 영구 손실	KMS/HSM, 키와 데이터의 백업 전략 분리
검증 중복이 본질	CPU·IOPS를 꾸준히 씀	버스트형 리소스 설정과 맞지 않음

이 표가 이 섹션의 핵심입니다. 2번 문서의 모든 구체적 권고가 이 표에서 나옵니다.

하드포크 — Kubernetes 운영 모델과 가장 크게 충돌하는 지점

프로토콜 변경이 하위 호환되지 않으면 하드포크입니다. 정해진 블록 높이나 시각에 네트워크 전체가 새 규칙으로 전환하며, 전환하지 않은 노드는 다른 체인에 남습니다.

Kubernetes 운영 상식과 충돌하는 지점:

Kubernetes 상식	하드포크에서
Rolling update로 점진 전환	활성화 전 가능하되 기한까지 필요한 모든 node가 새 규칙을 지원해야 함
일부 node canary	활성화 전에 fork-compatible binary를 시험하고 해당 testnet/mainnet 단계에서 동작 비교
문제 있으면 롤백	롤백하면 그 노드만 구 체인에 남음
업그레이드는 운영팀 일정	일정이 외부에서 정해짐

실무 권고: 하드포크는 배포가 아니라 기한이 있는 마이그레이션으로 다루십시오. 클라이언트 릴리스 노트를 구독하고, 포크 예정일 전에 충분한 여유를 두고 업그레이드하고, 테스트넷에서 먼저 검증합니다.

Ethereum은 2025년에 Pectra·Fusaka를 적용하고 더 잦은 업그레이드를 추진했습니다. 유지보수는 보장된 연 2회 일정이 아니라 공개된 활성화 날짜와 client release note를 기준으로 계획합니다.

정리

• 선택한 consensus·신뢰 모델을 비교합니다. etcd/Raft는 crash-fault tolerant이고 일부 blockchain은 BFT를 사용하며 permissioned Fabric은 CFT Raft 또는 SmartBFT를 사용할 수 있습니다. Blockchain이라는 명칭 자체가 Byzantine fault tolerance를 뜻하지는 않습니다.
• 많은 full-node 설계는 검증을 복제하지만 light-client·permissioned 모델은 다르며 RPC/read 용량은 base-chain 쓰기와 별도로 확장할 수 있습니다.
• 블록의 prev_hash 연쇄가 변조를 파급시키고, 머클 트리가 log N 크기의 포함 증명을 가능하게 합니다(경량 클라이언트의 근거).
• 합의에 비용이 필요한 이유는 Sybil 방어입니다. 참여자를 제한하면(컨소시엄) 그 비용이 불필요해져 BFT로 갈 수 있고, 처리량과 파이널리티가 개선되는 대신 탈중앙성을 포기합니다.
• 파이널리티가 운영에서 가장 중요한 개념입니다. 최신 데이터가 확정 데이터가 아니므로, 동기화 상태를 readiness에 넣고 confirmation depth를 애플리케이션 계약으로 정해야 합니다.
• 상태는 재생 가능하지만 재생에 오랜 시간이 걸립니다. 그래서 영구 볼륨이 필수입니다.
• Hard fork에는 외부에서 조정한 활성화 시점이 있으므로 호환 client를 미리 준비하고 활성화 후 rollback을 별도 평가합니다.

다음: EKS에서 블록체인 노드 운영에서 이 특성들을 실제 구성으로 옮깁니다.

참고 자료

• Ethereum Developer Documentation — 합의, 노드, 클라이언트

• Ethereum — Proof of Stake

• Hyperledger Fabric Documentation — permissioned 체인의 구조

• Bitcoin Developer Guide — PoW와 머클 트리

• 클러스터 아키텍처 — etcd와 Raft — crash fault 합의와의 비교

• Fabric ordering service — CFT Raft와 SmartBFT 구분