# 블록체인 기초 개념

> **마지막 업데이트**: 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를 부여하지는 않습니다.

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

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

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

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

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

```text
블록 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나 모든 체인의 경제적 불변성을 보장하지 않습니다.

### 머클 트리 — 왜 필요한가

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

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

```text
                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에서 블록체인 노드 운영](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/02-nodes-on-eks.md)에서 다룹니다.

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

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

| 데이터 | 성격 | 크기 |
|---|---|---|
| **블록 히스토리** | 추가만 되는 로그. 과거는 불변 | 계속 증가 |
| **현재 상태** (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)는 **키가 온라인에 있어야 서명할 수 있으면서 동시에 유출되면 안 되는** 모순된 요구를 갖습니다. [금융권 관점](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/04-financial-services.md)에서 이 문제를 다룹니다.

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

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

| 블록체인의 설계 | 파생되는 운영 특성 | 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에서 블록체인 노드 운영](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/02-nodes-on-eks.md)에서 이 특성들을 실제 구성으로 옮깁니다.

## 참고 자료

- [Ethereum Developer Documentation](https://ethereum.org/developers/docs/) — 합의, 노드, 클라이언트
- [Ethereum — Proof of Stake](https://ethereum.org/developers/docs/consensus-mechanisms/pos/)
- [Hyperledger Fabric Documentation](https://hyperledger-fabric.readthedocs.io/) — permissioned 체인의 구조
- [Bitcoin Developer Guide](https://developer.bitcoin.org/devguide/) — PoW와 머클 트리
- [클러스터 아키텍처 — etcd와 Raft](https://www.atomai.click/kubernetes-docs/llms/ko/core/01-cluster-architecture.md) — crash fault 합의와의 비교


- [Fabric ordering service](https://hyperledger-fabric.readthedocs.io/en/latest/orderer/ordering_service.html) — CFT Raft와 SmartBFT 구분