# 금융권 관점

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

## 이 문서에서 다루는 것

- 금융권에서 블록체인을 검토할 때 퍼블릭이 아니라 컨소시엄으로 가는 이유와, 그 선택이 실제로 무엇을 남기는가
- 프라이버시 요구가 "모두가 같은 원장을 본다"는 전제와 충돌하는 지점과 해법들
- 키 관리·규제·기존 인프라 연계에서 실제로 심의 쟁점이 되는 항목들

## 먼저: 블록체인이 답이 아닌 경우를 걸러내기

금융권 블록체인 검토에서 가장 자주 생기는 문제는 **기술이 문제에 맞지 않는데 진행되는 것**입니다. 이 문서는 그 판별부터 시작합니다.

[기초 개념](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/01-fundamentals.md)에서 본 대로 블록체인의 본질은 **"신뢰할 수 있는 중재자 없이 합의하기"**입니다. 그 대가로 처리량과 복잡도를 냅니다. 따라서:

| 상황 | 블록체인이 맞는가 |
|---|---|
| 한 조직이 데이터를 소유·제어 | 일반적으로 database/audit-log 대안부터 시작하되 구체적인 검증·governance 요구 비교 |
| 중재자가 있고 모두가 그를 신뢰 | **아니오** — 중재자의 DB로 충분합니다 |
| 변조 감지만 필요 | **대개 아니오** — 해시 체인, 서명 로그, WORM 스토리지로 충분 |
| 서로 신뢰하지 않는 복수 기관이 **공유 상태**를 갱신 | **검토 가치 있음** |
| 제3자가 **독립적으로 검증**할 수 있어야 함 | **검토 가치 있음** |
| 기관 간 대조(reconciliation) 비용이 실제로 큼 | **검토 가치 있음** |

**"변조 감지만 필요"가 특히 흔한 오해**입니다. 감사 추적이나 무결성 증명이 목적이면 블록체인 없이도 됩니다 — 서명된 append-only 로그, 해시 체인, 객체 스토리지의 WORM(Write Once Read Many) 기능으로 달성할 수 있고 운영이 훨씬 단순합니다.

여기서 [Amazon QLDB의 사례](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/03-managed-blockchain.md)가 시사적입니다. QLDB는 정확히 "중앙 신뢰 주체가 있지만 암호학적으로 검증 가능한 원장"을 제공했고, **그것으로 충분한 문제가 많다**는 전제의 서비스였습니다. 서비스는 종료되었지만 그 문제 정의 자체는 유효합니다 — 많은 요구가 완전한 탈중앙 합의를 필요로 하지 않습니다.

**실무 권고**: "이 문제에 중재자가 없어야 하는 이유"를 한 문장으로 쓸 수 없으면, 블록체인이 아닌 대안을 먼저 비교하십시오.

## 왜 컨소시엄인가

일부 금융 앱은 membership·governance·데이터 배치 제어를 위해 permissioned network를 선택하고, 다른 앱은 추가 제어와 함께 public network를 사용합니다. **Network 선택만으로 KYC/AML·개인정보·기타 규제 준수가 성립하지는 않습니다.** 실제 관할·활동·참여자·데이터 흐름을 평가합니다.

| 제약 | 퍼블릭 체인에서의 문제 | 컨소시엄에서 |
|---|---|---|
| **참여자 식별(KYC/AML)** | Public address만으로 법적 거래 상대가 식별되지는 않으며 활동별 앱 제어 필요 | Membership 제어가 도움이 되지만 그 자체로 규제 준수는 아님 |
| **데이터 주권·위치** | 데이터가 전 세계 노드에 복제 | 참여 기관이 통제하는 노드에만 |
| **처리량·지연** | 프로토콜별 처리량과 확률적/경제적 finality | Consensus·workload별로 다르며 permissioning 자체가 성능 보장은 아님 |
| **거버넌스** | 프로토콜 변경을 통제할 수 없음 | 컨소시엄이 결정 |
| **요금 모델** | Network fee와 운영/연계 비용 | Network별 fee·governance·인프라 비용. 자동으로 인프라 비용만 남는 것은 아님 |
| **오류 대응** | 잘못된 거래를 되돌릴 수 없음 | 거버넌스 절차로 대응 가능 |

거래 상대 식별과 고객 데이터 처리는 구체적 활동·관할에 맞춰 설계해야 합니다. Public address가 법적 익명성을 자동으로 뜻하지 않고 consortium membership도 신원·데이터 위치 의무를 자동 충족하지 않습니다. 규제/법률 담당자와 검토합니다.

### 컨소시엄 선택이 실제로 남기는 것

여기서 정직해야 할 부분이 있습니다. 컨소시엄으로 가면 **블록체인의 원래 가치 명제 상당 부분이 사라집니다.**

| 퍼블릭의 가치 | 컨소시엄에서 |
|---|---|
| 검열 저항 | ✗ 멤버십 통제 주체가 존재 |
| 무허가 참여 | ✗ 승인 필요 |
| 중재자 불필요 | △ **컨소시엄 운영체가 사실상 중재자** |
| 변조 저항 | △ 멤버 다수가 담합하면 가능 |
| 독립 검증 | ○ 멤버 간에는 유효 |
| **기관 간 대조 비용 절감** | **○ 남음** |
| **공유 상태의 단일 버전** | **○ 남음** |

즉 컨소시엄 체인의 실질적 가치는 **"기관 간에 같은 데이터를 보게 만들어 대조 작업을 없애는 것"**으로 좁혀집니다. 이것은 실재하는 가치이지만, "탈중앙"이나 "신뢰 불필요"와는 다른 이야기입니다.

**심의에서 이 구분이 중요합니다.** 제안서에 "탈중앙화로 신뢰 없이 운영"이라고 쓰면 심의에서 "그럼 멤버십은 누가 통제하는가"라는 질문을 받고, 답이 "컨소시엄 사무국"이면 논리가 무너집니다. **처음부터 "기관 간 대조 비용 절감"으로 가치를 정의하는 것이 방어 가능합니다.**

## 프라이버시 — 가장 어려운 문제

### 근본적 긴장

블록체인의 전제는 **"모두가 같은 원장을 보고 각자 검증한다"**입니다. 금융 거래의 요구는 **"거래 상대가 아닌 제3자는 내 거래를 볼 수 없어야 한다"**입니다.

**이 둘은 직접 충돌합니다.** 검증하려면 봐야 하고, 프라이버시를 지키려면 보이면 안 됩니다.

이 긴장을 푸는 방법들이 있고, 각각 다른 대가를 냅니다.

### 해법과 트레이드오프

| 방법 | 원리 | 대가 |
|---|---|---|
| **채널 분리** (Fabric) | 거래 그룹별로 별도 원장. 채널 멤버만 데이터 보유 | 채널 수만큼 운영 복잡도. **채널 간 원자적 거래가 어려움** |
| **Private Data Collection** (Fabric) | 원장에는 해시만, 실제 데이터는 승인된 peer에만 | 데이터 배포·수명 관리 부담 |
| **영지식 증명 (ZKP)** | 내용을 공개하지 않고 **명제의 참을 증명** | 계산 비용, 회로 설계 난도, 검증 가능성 심의 |
| **오프체인 저장** | 민감 데이터는 체인 밖, 체인에는 해시·포인터만 | 오프체인 저장소의 가용성·무결성이 새 의존성 |
| **암호화 저장** | 체인에 암호문 저장 | **키 관리가 곧 접근 제어** — 키 유출 시 과거 전부 노출 |

### 어느 것을 고를 것인가

**채널 분리가 가장 흔한 출발점**입니다. 개념이 단순하고 Fabric이 기본 제공하며, "누가 무엇을 볼 수 있는가"가 명확해 심의에서 설명하기 쉽습니다.

한계는 **채널을 넘는 거래**입니다. A-B 채널과 B-C 채널이 있을 때 A→C로 가치가 흐르는 거래를 원자적으로 처리하기 어렵습니다. 비즈니스 흐름이 이런 형태라면 설계를 다시 봐야 합니다.

Append-only/public ledger의 암호문은 이력 사본에 남을 수 있으며 이후 재암호화가 사본을 지우지는 않습니다. 키가 유출되면 해당 키로 암호화한 record가 노출될 수 있습니다. Permissioned private-data purge는 의미가 다르므로 모든 blockchain이 모든 데이터를 삭제할 수 없다고 단정하지 말고 실제 보존·키 모델을 검증합니다.

**ZKP는 강력하지만 심의 난도가 높습니다.** "내용을 안 보여주고 참임을 증명한다"는 것을 심의 담당자에게 설명하고, 구현의 정확성을 보증하는 것이 별개 과제입니다. 신뢰 설정(trusted setup)이 필요한 방식이면 그 설정의 신뢰성도 쟁점이 됩니다.

### 잊혀질 권리와의 충돌

개인정보 규제의 삭제 요구와 블록체인의 불변성이 충돌합니다.

**일반적인 대응은 "개인정보를 체인에 넣지 않는 것"**입니다 — 체인에는 식별자나 해시만 두고, 개인정보는 오프체인에 두어 삭제 가능하게 합니다. 다만 해시도 원본을 아는 상태에서는 조회 가능(rainbow table 공격)하므로, 솔트나 키를 삭제해 사실상 복원 불가하게 만드는 방식(crypto-shredding)을 함께 씁니다.

::: warning 확인 필요
개인정보보호 규제(국내 개인정보보호법, GDPR 등)의 **삭제 요구와 블록체인 불변성의 법적 해석은 관할과 사안에 따라 다르며, 이 문서는 법률 자문이 아닙니다.**

해시·암호문이 개인정보에 해당하는지, crypto-shredding이 삭제 의무를 충족하는지는 **법무·컴플라이언스 부서와 규제 당국 해석을 통해 확인**해야 합니다. 기술적 설계보다 이 확인이 먼저입니다.
:::

## 키 관리 — 금융권에서 가장 무거운 항목

[기초 개념](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/01-fundamentals.md)에서 "키가 곧 권한이고 잃으면 끝"이라고 했습니다. 금융권에서 이것이 왜 특별히 무거운지 봅니다.

### 요구의 모순

| 요구 | 상충하는 요구 |
|---|---|
| 거래 서명에 키가 **온라인**에 있어야 함 | 키는 **격리**되어야 함 |
| 가용성 — 서명이 지연되면 서비스 중단 | 다중 승인 — 단일 주체가 서명할 수 없어야 함 |
| 백업 필수 — 잃으면 영구 손실 | 백업이 유출 경로 |
| 감사 가능 — 누가 서명했는지 | 키 자체는 노출 불가 |

이 모순이 금융권 블록체인에서 **가장 설계가 어려운 부분**입니다.

### 대응 수단

| 수단 | 제공하는 것 | 한계 |
|---|---|---|
| **HSM** (CloudHSM, on-premises HSM) | Hardware 기반 서명과 설정 가능한 키 보호 | 선택한 module의 algorithm·extractability/wrapping·backup 정책 확인 |
| **AWS KMS** | 관리형 키, IAM 통합, CloudTrail 감사 | 블록체인이 요구하는 서명 알고리즘 지원 여부 확인 필요 |
| **MPC** (Multi-Party Computation) | 키를 **분산 보관**하고 조각을 모아 서명 — 완전한 키가 어디에도 없음 | 구현 복잡도, 벤더 의존 |
| **멀티시그** | 프로토콜 수준에서 N-of-M 서명 요구 | 체인·컨트랙트 지원 필요. 거래 비용 증가 |
| **콜드/핫 분리** | 대량은 오프라인, 소량만 온라인 | 운영 절차 부담 |

### 곡선별 지원 현황 — 계층에 따라 갈립니다

**이것이 키 관리 설계에서 가장 자주 무너지는 가정입니다.** "KMS를 쓴다"는 계획이 알고리즘 미지원으로 깨지는데, 중요한 점은 **Ethereum의 두 계층이 서로 다른 곡선을 쓴다**는 것입니다.

| 계층 | 곡선 | 용도 | AWS KMS / CloudHSM |
|---|---|---|---|
| **실행 계층** (계정·거래) | **secp256k1** | 거래 서명, EOA 계정 | **✅ 지원** — KMS 키 스펙 `ECC_SECG_P256K1`, 용도는 `SIGN_VERIFY` 전용 |
| **컨센서스 계층** (검증자) | **BLS12-381** | 블록 제안·증명 서명 | **❌ 미지원** |

KMS `ECC_SECG_P256K1`의 `SIGN_VERIFY`는 **Ethereum ECDSA 형식에 맞춘 서명 흐름**에 사용할 수 있습니다. Curve 지원만으로는 부족하며 digest 처리·DER의 chain signature 변환·low-S/recovery 요구·정확한 transaction 형식을 검증해야 합니다. Bitcoin 서명 방식도 다르므로 secp256k1 지원이 모든 Schnorr/Taproot 흐름 지원을 뜻하지 않습니다. 실제 자금 없이 시험합니다.

**컨센서스 계층이 문제입니다.** BLS12-381은 KMS의 키 스펙에 없고 CloudHSM도 지원하지 않습니다. **즉 검증자 서명 키를 KMS/HSM에 넣는 설계는 성립하지 않습니다.**

AWS가 제시하는 대안은 **Nitro Enclaves**입니다 — 격리된 실행 환경 안에서 Web3Signer 같은 서명기를 돌려, 키가 엔클레이브를 떠나지 않게 하는 구조입니다. 키 생성(EIP-2335 형식 BLS12-381 키스토어) 역시 별도 방식이 필요합니다.

**설계 함의**: 앞서 다룬 검증자 키의 모순(온라인 상시 + 격리 + 이중 서명 금지)에 **"HSM으로 키를 보호한다"는 표준 답이 통하지 않는다**는 제약이 하나 더 붙습니다. 검증자 운영을 검토한다면 이것이 KMS 기반 설계와 갈리는 첫 분기점입니다.

::: warning 확인 필요
위 지원 현황은 조사 시점 기준이며, **BLS12-381의 HSM 지원은 업계에서 오래 논의되어 온 주제라 향후 달라질 수 있습니다.** 또한 Ethereum 외 프로토콜(Ed25519를 쓰는 체인 등)의 곡선별 지원은 별도 확인이 필요합니다.

**설계 전에 [KMS 키 스펙 참조 문서](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-choose-key-spec.html)에서 현재 지원 목록을 확인하고, 실제 서명이 대상 체인에서 검증되는지 PoC로 반드시 검증**하십시오.
:::

### 검증자 키의 특수성

PoS 검증자를 운영하는 경우 추가 문제가 있습니다.

- **서명 키가 상시 온라인**이어야 합니다 — 매 슬롯에 서명 기회가 오므로
- **같은 validator의 충돌하는 서명은 slashing 대상이 될 수 있습니다.** 조정되지 않은 signer/키 복제본이 위험을 만들며 동일 서명 중복이 항상 자동 slashing인 것은 아닙니다.
- 즉 **"고가용성을 위한 이중화"가 오히려 위험**을 만드는 구조입니다

일반 배포는 활성 signer 하나와 fencing된 failover, 보존된 slashing-protection 이력을 사용합니다. Active-active/distributed signer에는 검증된 공통 slashing-protection 설계가 필요합니다. 가용성을 높인다는 이유로 운영 validator 키를 복사해 두 번째 signer를 시작하지 않습니다.

## 규제와 심의 쟁점

금융권 심의에서 실제로 나오는 질문들을 정리하면 이렇습니다.

| 쟁점 | 질문 | 준비할 답 |
|---|---|---|
| **필요성** | 왜 일반 DB가 아닌가 | "중재자가 없어야 하는 이유"를 한 문장으로 |
| **참여자 통제** | 멤버십은 누가 어떻게 통제하는가 | 거버넌스 구조와 가입·탈퇴 절차 |
| **데이터 소재** | 데이터가 어디에 복제되는가 | 노드 위치와 리전 통제 방안 |
| **접근 통제** | 누가 무엇을 볼 수 있는가 | 채널·PDC 설계, 암호화 정책 |
| **삭제 요구** | 개인정보 삭제 요구에 어떻게 대응하는가 | 개인정보를 체인에 두지 않는 설계 |
| **키 관리** | 키가 어디 있고 누가 접근하는가 | HSM/KMS/MPC 구조와 권한 분리 |
| **오류 정정** | 잘못된 거래를 어떻게 되돌리는가 | 거버넌스 절차. **기술이 아니라 절차로 답해야 함** |
| **가용성** | 노드·컨소시엄 장애 시 | 장애 도메인, 멤버별 독립 운영 |
| **감사** | 감사인이 무엇을 어떻게 확인하는가 | 감사 접근 방법, 로그 |
| **업그레이드** | 프로토콜 변경을 누가 결정하는가 | 컨소시엄 거버넌스 |
| **종료 계획** | 서비스를 종료하면 데이터는 | **exit 전략** |
| **벤더·서비스 종속** | 관리형 서비스가 종료되면 | 표준 프로토콜, 추상화 계층 ([AMB 문서](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/03-managed-blockchain.md)) |

### 특히 준비가 부족한 두 항목

**① 오류 정정 — "되돌릴 수 없다"가 심의에서 약점이 됩니다.**

블록체인의 장점으로 홍보되는 불변성이 금융 운영에서는 **문제**입니다. 잘못된 거래, 착오 송금, 시스템 오류가 실제로 발생하고 금융기관은 이를 정정할 의무와 절차를 갖고 있습니다.

**답은 기술이 아니라 절차입니다.** "체인을 되돌린다"가 아니라 "**보정 거래(compensating transaction)를 발행한다**"가 표준 접근입니다 — 원 거래는 남고 상계 거래를 추가해 결과를 정정합니다. 회계의 역분개와 같은 개념입니다. 심의에는 이 절차와 승인 권한을 문서화해 제시해야 합니다.

**② exit 전략 — 거의 항상 준비가 안 되어 있습니다.**

컨소시엄이 해산하거나 특정 기관이 탈퇴할 때, 또는 시스템을 종료할 때 데이터와 의무는 어떻게 되는가. 금융 데이터는 보존 기간 의무가 있으므로 **"체인을 껐다"로 끝나지 않습니다.**

준비할 것: 원장 데이터의 내보내기 형식, 보존 주체, 탈퇴 멤버의 데이터 처리, 기록 접근 방법. **컨소시엄 협약에 이것이 명시되어 있어야** 하고, 기술 설계가 이를 지원해야 합니다.

## 기존 금융 인프라와의 연계

블록체인이 기존 시스템을 대체하는 것이 아니라 **옆에 붙는** 것이 현실입니다. 연계 지점에서 실무 문제가 생깁니다.

| 연계 문제 | 내용 |
|---|---|
| **파이널리티 불일치** | 기존 시스템은 DB 커밋이 곧 확정. 체인은 confirmation depth 필요 → **경계에서 상태 관리** 필요 |
| **원자성 부재** | 기존 DB 트랜잭션과 체인 거래를 **하나의 원자적 단위로 묶을 수 없음** |
| **처리량 격차** | 기존 시스템이 훨씬 빠름 → 체인이 병목. 큐잉·배치 필요 |
| **가역성 차이** | 기존은 롤백 가능, 체인은 불가 → 실패 시나리오 설계가 비대칭 |
| **시각 동기** | 체인의 블록 시각과 기존 시스템 시각의 정합 |

**"원자성 부재"가 가장 실질적인 문제**입니다. DB에 기록하고 체인에 거래를 보내는 두 작업 사이에 장애가 나면 불일치가 생깁니다. 분산 트랜잭션으로 묶을 수 없으므로 **Saga 패턴이나 outbox 패턴** 같은 최종 일관성 접근이 필요하고, **보정 거래 절차**(위의 오류 정정)와 연결됩니다.

이것은 아키텍처 결정이므로 **설계 초기에 다뤄야** 합니다. 나중에 붙이려 하면 데이터 정합성 문제가 운영 중에 나타납니다.

## 현실적인 도입 경로

| 단계 | 내용 |
|---|---|
| **1. 문제 검증** | 블록체인이 필요한 문제인지 확인. 대안(일반 DB, 서명 로그, WORM)과 비교 |
| **2. 참여 기관 확보** | 참여할 기관과 역할을 합의하고, 보편적인 최소 기관 수를 가정하는 대신 공유 원장·검증·governance 이점을 더 단순한 대안과 비교해 정당화 |
| **3. 거버넌스 합의** | 기술보다 먼저. 멤버십, 의사결정, 분쟁, exit |
| **4. 프라이버시 설계** | 채널·PDC 구조. 심의 담당자와 함께 |
| **5. 법무·컴플라이언스 확인** | 삭제 요구, 데이터 소재, 감사 요건 |
| **6. PoC** | 기술 검증 + **성능·운영 부담 실측** |
| **7. 파일럿** | 제한된 범위의 실거래 |
| **8. 운영 체계** | [노드 운영](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/02-nodes-on-eks.md), 모니터링, 인증서 갱신, 하드포크/업그레이드 |

**2번과 3번이 기술보다 먼저**라는 점이 이 표의 요지입니다. 기술 검증이 성공해도 참여 기관이 없거나 거버넌스가 합의되지 않으면 진행되지 않습니다. 실제로 많은 금융권 블록체인 프로젝트가 이 단계에서 멈췄습니다.

## 정리

- **블록체인이 답이 아닌 경우를 먼저 걸러내십시오.** "중재자가 없어야 하는 이유"를 한 문장으로 못 쓰면 대안을 먼저 비교해야 합니다. 변조 감지만 필요하면 서명 로그나 WORM으로 충분합니다.
- 금융권이 컨소시엄으로 가는 결정적 이유는 **KYC/AML 의무와 데이터 주권**입니다. 처리량과 거버넌스는 부수적 이점입니다.
- 컨소시엄 선택으로 **블록체인의 원래 가치 상당 부분이 사라집니다.** 남는 실질 가치는 **"기관 간 대조 비용 절감"**이고, 심의에는 이것으로 가치를 정의하는 것이 방어 가능합니다.
- 실제 데이터 모델에 맞게 privacy 수단을 선택합니다. 과거 암호문 사본은 key rotation 후에도 남을 수 있으므로 보존·private-data purge·법적 의무를 명시 검증합니다.
- 키 관리는 격리와 서명 가용성의 균형이 필요합니다. PoS validator에서는 조정되지 않은 signer가 **충돌하는 slashable 메시지**를 만들 수 있지만 동일 서명의 중복이 자동으로 slashing 대상이 되는 것은 아닙니다. Slashing 이력을 보존한 fencing failover 또는 검증된 조정 방식의 분산 서명 설계를 사용합니다.
- 심의에서 준비가 가장 부족한 두 항목은 **오류 정정**(답은 기술이 아니라 보정 거래 절차)과 **exit 전략**(보존 의무가 있어 "껐다"로 끝나지 않음)입니다.
- 기존 인프라 연계의 핵심 난점은 **원자성 부재**입니다. Saga/outbox 같은 최종 일관성 접근을 설계 초기에 넣어야 합니다.
- 도입 경로에서 **참여 기관 확보와 거버넌스 합의가 기술보다 먼저**입니다.

## 참고 자료

- [Hyperledger Fabric — Private data](https://hyperledger-fabric.readthedocs.io/en/latest/private-data/private-data.html)
- [Hyperledger Fabric — Channels](https://hyperledger-fabric.readthedocs.io/en/latest/channels.html)
- [AWS CloudHSM 문서](https://docs.aws.amazon.com/cloudhsm/) / [AWS KMS 문서](https://docs.aws.amazon.com/kms/)
- [AWS KMS 키 스펙 참조](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-choose-key-spec.html) — `ECC_SECG_P256K1` 포함
- [Use AWS KMS to securely manage Ethereum accounts (AWS Web3 Blog)](https://aws.amazon.com/blogs/web3/use-key-management-service-aws-kms-to-securely-manage-ethereum-accounts-part-1/)
- [AWS Nitro Enclaves for running Ethereum validators (AWS Web3 Blog)](https://aws.amazon.com/blogs/web3/aws-nitro-enclaves-for-running-ethereum-validators-part-1/) — BLS12-381 미지원에 대한 대안
- [Amazon Managed Blockchain](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/03-managed-blockchain.md) — 서비스 종료 위험과 완화
- [블록체인 기초 개념](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/01-fundamentals.md) — 합의와 파이널리티
- [EKS에서 블록체인 노드 운영](https://www.atomai.click/kubernetes-docs/llms/ko/blockchain/02-nodes-on-eks.md) — 운영 체계
- [EKS 보안](https://www.atomai.click/kubernetes-docs/llms/ko/eks/05-eks-security.md) / [보안](https://www.atomai.click/kubernetes-docs/llms/ko/core/06-security.md) — 일반 보안 통제