Cloud Native Operations

한국어

English

한국어

English

Appearance

블록체인 개요 ​

마지막 업데이트: 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블록체인 기초 개념합의·머클 트리·P2P·파이널리티가 무엇이고, 왜 그 설계에서 이런 운영 특성이 나오는가
2EKS에서 블록체인 노드 운영StatefulSet·스토리지·P2P·동기화·업그레이드를 실제로 어떻게 다루는가
3Amazon Managed Blockchain관리형이 무엇을 대신해 주고 무엇을 못 하는가. AWS 원장 서비스의 변화가 시사하는 것
4금융권 관점컨소시엄·프라이버시·규제·기존 인프라 연계에서 무엇이 쟁점인가

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

정확성에 대한 안내 ​

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

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

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

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

관련 문서 ​