# 블록체인 개요

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

## 이 섹션에서 다루는 것

- 블록체인이 인프라 담당자 관점에서 **어떤 워크로드인가** — 왜 일반 상태 저장 서비스와 운영 특성이 다른가
- Kubernetes(EKS)에서 블록체인 노드를 운영할 때 실제로 부딪히는 것들 — 스토리지, P2P 네트워킹, 동기화, 업그레이드
- 관리형(Amazon Managed Blockchain)과 자체 운영의 경계, 그리고 금융권에서 이 선택이 어떻게 달라지는가

## 왜 이 섹션이 이 레포에 있는가

이 레포는 Kubernetes와 EKS 학습 자료입니다. 블록체인이 여기 있는 이유는 **블록체인 노드가 Kubernetes 운영자에게 특이한 워크로드**이기 때문입니다.

대부분의 Kubernetes 워크로드는 두 종류입니다 — 상태가 없어서 자유롭게 죽이고 살릴 수 있는 것(stateless), 또는 상태가 있지만 관리형 서비스로 밀어낼 수 있는 것(RDS, ElastiCache). 블록체인 노드는 **둘 다 아닙니다.**

| 일반적 전제 | 블록체인 노드에서 |
|---|---|
| "Pod는 언제든 교체 가능하다" | 수백 GB~수 TB의 로컬 상태를 재구축하는 데 **며칠**이 걸릴 수 있음 |
| "Scale-out하면 처리량이 늘어난다" | Replica는 RPC read·가용성을 늘릴 수 있지만 base chain의 write/consensus 용량을 자동 증가시키지는 않음 |
| "헬스체크가 통과하면 서비스 가능" | 체인 동기화가 뒤처지면 헬스체크는 통과하는데 **틀린 데이터를 반환** |
| "Rolling update면 무중단 배포된다" | Fork-compatible release는 활성화 전 canary/rolling 적용 가능. 프로토콜 기한과 활성화 후 rollback 호환성은 별도 제약 |
| "데이터는 백업에서 복구" | 상태는 체인에서 재생 가능하지만 **키를 잃으면 끝** |

이 차이들이 실제 운영 결정으로 이어집니다. 그것을 다루는 것이 이 섹션의 목적입니다.

## 대상 독자와 전제

- EKS·Kubernetes 운영 경험이 있는 인프라 담당자, 아키텍트
- **블록체인은 처음 접한다고 전제합니다** — 1번 문서가 개념을 처음부터 설명합니다
- 스마트 컨트랙트 개발, 토큰 경제, 투자 판단은 다루지 않습니다. **인프라 운영 관점**입니다

## 문서 구성

| # | 문서 | 다루는 질문 |
|---|------|------------|
| 1 | [블록체인 기초 개념](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/01-fundamentals.md) | 합의·머클 트리·P2P·파이널리티가 무엇이고, 왜 그 설계에서 이런 운영 특성이 나오는가 |
| 2 | [EKS에서 블록체인 노드 운영](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/02-nodes-on-eks.md) | StatefulSet·스토리지·P2P·동기화·업그레이드를 실제로 어떻게 다루는가 |
| 3 | [Amazon Managed Blockchain](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/03-managed-blockchain.md) | 관리형이 무엇을 대신해 주고 무엇을 못 하는가. AWS 원장 서비스의 변화가 시사하는 것 |
| 4 | [금융권 관점](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/04-financial-services.md) | 컨소시엄·프라이버시·규제·기존 인프라 연계에서 무엇이 쟁점인가 |

1번은 2~4번의 선행 개념입니다. 블록체인이 익숙하다면 2번부터 읽어도 되지만, **1번의 "운영 특성이 어디서 나오는가" 절**은 2번을 이해하는 데 필요합니다.

## 정확성에 대한 안내

이 섹션에는 두 종류의 불확실성이 있어 각각 다르게 처리했습니다.

**① 빠르게 변하는 프로토콜 명세** — 고정된 업그레이드 주기를 가정하지 말고 발표된 활성화 날짜를 사용합니다. Hardware·staking·blob 처리는 바뀔 수 있으며 아래 수치는 날짜가 있는 안내이지 현재 요구의 보장값이 아닙니다.

**② 1차 자료가 아닌 수치** — 노드 하드웨어 요건 같은 값은 공식 스펙이 아니라 커뮤니티·벤더 추정치인 경우가 많습니다. 그런 값은 출처의 성격을 표시하고 범위로 제시했습니다.

공식 문서로 확인되지 않은 항목은 `확인 필요` 블록으로 남겼습니다. **프로덕션 설계 전에 해당 프로토콜의 공식 문서와 클라이언트 릴리스 노트에서 현재값을 직접 확인**하시기 바랍니다.

## 관련 문서

- [클러스터 아키텍처](https://www.atomai.click/kubernetes-docs/llms/ko/core/01-cluster-architecture.md) — etcd와 합의(Raft), 블록체인 합의와 비교할 기준점
- [파드와 워크로드](https://www.atomai.click/kubernetes-docs/llms/ko/core/02-pods-and-workloads.md) — StatefulSet
- [스토리지](https://www.atomai.click/kubernetes-docs/llms/ko/core/04-storage.md) / [EKS 스토리지](https://www.atomai.click/kubernetes-docs/llms/ko/eks/04-eks-storage-part1.md) — PV/PVC와 EBS
- [EBS gp2 vs gp3 실측 벤치마크](https://www.atomai.click/kubernetes-docs/llms/ko/storage/01-ebs-gp2-gp3-benchmark.md) — IOPS가 실제로 의미하는 것
- [EKS 노드 커널 튜닝](https://www.atomai.click/kubernetes-docs/llms/ko/kernel/03-eks-node-tuning.md) — 파일 디스크립터, 소켓 버퍼
- [Data on EKS 개요](https://www.atomai.click/kubernetes-docs/llms/ko/data-on-eks/README.md) — 상태 저장 데이터 워크로드 일반
- [EKS 복원력과 고가용성](https://www.atomai.click/kubernetes-docs/llms/ko/eks/10-eks-resiliency.md) — 장애 도메인 설계