금융권 관점
마지막 업데이트: 2026년 9월 13일
이 문서에서 다루는 것
- 금융권에서 블록체인을 검토할 때 퍼블릭이 아니라 컨소시엄으로 가는 이유와, 그 선택이 실제로 무엇을 남기는가
- 프라이버시 요구가 "모두가 같은 원장을 본다"는 전제와 충돌하는 지점과 해법들
- 키 관리·규제·기존 인프라 연계에서 실제로 심의 쟁점이 되는 항목들
먼저: 블록체인이 답이 아닌 경우를 걸러내기
금융권 블록체인 검토에서 가장 자주 생기는 문제는 기술이 문제에 맞지 않는데 진행되는 것입니다. 이 문서는 그 판별부터 시작합니다.
기초 개념에서 본 대로 블록체인의 본질은 **"신뢰할 수 있는 중재자 없이 합의하기"**입니다. 그 대가로 처리량과 복잡도를 냅니다. 따라서:
| 상황 | 블록체인이 맞는가 |
|---|---|
| 한 조직이 데이터를 소유·제어 | 일반적으로 database/audit-log 대안부터 시작하되 구체적인 검증·governance 요구 비교 |
| 중재자가 있고 모두가 그를 신뢰 | 아니오 — 중재자의 DB로 충분합니다 |
| 변조 감지만 필요 | 대개 아니오 — 해시 체인, 서명 로그, WORM 스토리지로 충분 |
| 서로 신뢰하지 않는 복수 기관이 공유 상태를 갱신 | 검토 가치 있음 |
| 제3자가 독립적으로 검증할 수 있어야 함 | 검토 가치 있음 |
| 기관 간 대조(reconciliation) 비용이 실제로 큼 | 검토 가치 있음 |
"변조 감지만 필요"가 특히 흔한 오해입니다. 감사 추적이나 무결성 증명이 목적이면 블록체인 없이도 됩니다 — 서명된 append-only 로그, 해시 체인, 객체 스토리지의 WORM(Write Once Read Many) 기능으로 달성할 수 있고 운영이 훨씬 단순합니다.
여기서 Amazon QLDB의 사례가 시사적입니다. 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)을 함께 씁니다.
확인 필요
개인정보보호 규제(국내 개인정보보호법, GDPR 등)의 삭제 요구와 블록체인 불변성의 법적 해석은 관할과 사안에 따라 다르며, 이 문서는 법률 자문이 아닙니다.
해시·암호문이 개인정보에 해당하는지, crypto-shredding이 삭제 의무를 충족하는지는 법무·컴플라이언스 부서와 규제 당국 해석을 통해 확인해야 합니다. 기술적 설계보다 이 확인이 먼저입니다.
키 관리 — 금융권에서 가장 무거운 항목
기초 개념에서 "키가 곧 권한이고 잃으면 끝"이라고 했습니다. 금융권에서 이것이 왜 특별히 무거운지 봅니다.
요구의 모순
| 요구 | 상충하는 요구 |
|---|---|
| 거래 서명에 키가 온라인에 있어야 함 | 키는 격리되어야 함 |
| 가용성 — 서명이 지연되면 서비스 중단 | 다중 승인 — 단일 주체가 서명할 수 없어야 함 |
| 백업 필수 — 잃으면 영구 손실 | 백업이 유출 경로 |
| 감사 가능 — 누가 서명했는지 | 키 자체는 노출 불가 |
이 모순이 금융권 블록체인에서 가장 설계가 어려운 부분입니다.
대응 수단
| 수단 | 제공하는 것 | 한계 |
|---|---|---|
| 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 기반 설계와 갈리는 첫 분기점입니다.
확인 필요
위 지원 현황은 조사 시점 기준이며, BLS12-381의 HSM 지원은 업계에서 오래 논의되어 온 주제라 향후 달라질 수 있습니다. 또한 Ethereum 외 프로토콜(Ed25519를 쓰는 체인 등)의 곡선별 지원은 별도 확인이 필요합니다.
설계 전에 KMS 키 스펙 참조 문서에서 현재 지원 목록을 확인하고, 실제 서명이 대상 체인에서 검증되는지 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 문서) |
특히 준비가 부족한 두 항목
① 오류 정정 — "되돌릴 수 없다"가 심의에서 약점이 됩니다.
블록체인의 장점으로 홍보되는 불변성이 금융 운영에서는 문제입니다. 잘못된 거래, 착오 송금, 시스템 오류가 실제로 발생하고 금융기관은 이를 정정할 의무와 절차를 갖고 있습니다.
답은 기술이 아니라 절차입니다. "체인을 되돌린다"가 아니라 "보정 거래(compensating transaction)를 발행한다"가 표준 접근입니다 — 원 거래는 남고 상계 거래를 추가해 결과를 정정합니다. 회계의 역분개와 같은 개념입니다. 심의에는 이 절차와 승인 권한을 문서화해 제시해야 합니다.
② exit 전략 — 거의 항상 준비가 안 되어 있습니다.
컨소시엄이 해산하거나 특정 기관이 탈퇴할 때, 또는 시스템을 종료할 때 데이터와 의무는 어떻게 되는가. 금융 데이터는 보존 기간 의무가 있으므로 "체인을 껐다"로 끝나지 않습니다.
준비할 것: 원장 데이터의 내보내기 형식, 보존 주체, 탈퇴 멤버의 데이터 처리, 기록 접근 방법. 컨소시엄 협약에 이것이 명시되어 있어야 하고, 기술 설계가 이를 지원해야 합니다.
기존 금융 인프라와의 연계
블록체인이 기존 시스템을 대체하는 것이 아니라 옆에 붙는 것이 현실입니다. 연계 지점에서 실무 문제가 생깁니다.
| 연계 문제 | 내용 |
|---|---|
| 파이널리티 불일치 | 기존 시스템은 DB 커밋이 곧 확정. 체인은 confirmation depth 필요 → 경계에서 상태 관리 필요 |
| 원자성 부재 | 기존 DB 트랜잭션과 체인 거래를 하나의 원자적 단위로 묶을 수 없음 |
| 처리량 격차 | 기존 시스템이 훨씬 빠름 → 체인이 병목. 큐잉·배치 필요 |
| 가역성 차이 | 기존은 롤백 가능, 체인은 불가 → 실패 시나리오 설계가 비대칭 |
| 시각 동기 | 체인의 블록 시각과 기존 시스템 시각의 정합 |
"원자성 부재"가 가장 실질적인 문제입니다. DB에 기록하고 체인에 거래를 보내는 두 작업 사이에 장애가 나면 불일치가 생깁니다. 분산 트랜잭션으로 묶을 수 없으므로 Saga 패턴이나 outbox 패턴 같은 최종 일관성 접근이 필요하고, 보정 거래 절차(위의 오류 정정)와 연결됩니다.
이것은 아키텍처 결정이므로 설계 초기에 다뤄야 합니다. 나중에 붙이려 하면 데이터 정합성 문제가 운영 중에 나타납니다.
현실적인 도입 경로
| 단계 | 내용 |
|---|---|
| 1. 문제 검증 | 블록체인이 필요한 문제인지 확인. 대안(일반 DB, 서명 로그, WORM)과 비교 |
| 2. 참여 기관 확보 | 참여할 기관과 역할을 합의하고, 보편적인 최소 기관 수를 가정하는 대신 공유 원장·검증·governance 이점을 더 단순한 대안과 비교해 정당화 |
| 3. 거버넌스 합의 | 기술보다 먼저. 멤버십, 의사결정, 분쟁, exit |
| 4. 프라이버시 설계 | 채널·PDC 구조. 심의 담당자와 함께 |
| 5. 법무·컴플라이언스 확인 | 삭제 요구, 데이터 소재, 감사 요건 |
| 6. PoC | 기술 검증 + 성능·운영 부담 실측 |
| 7. 파일럿 | 제한된 범위의 실거래 |
| 8. 운영 체계 | 노드 운영, 모니터링, 인증서 갱신, 하드포크/업그레이드 |
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
- Hyperledger Fabric — Channels
- AWS CloudHSM 문서 / AWS KMS 문서
- AWS KMS 키 스펙 참조 —
ECC_SECG_P256K1포함 - Use AWS KMS to securely manage Ethereum accounts (AWS Web3 Blog)
- AWS Nitro Enclaves for running Ethereum validators (AWS Web3 Blog) — BLS12-381 미지원에 대한 대안
- Amazon Managed Blockchain — 서비스 종료 위험과 완화
- 블록체인 기초 개념 — 합의와 파이널리티
- EKS에서 블록체인 노드 운영 — 운영 체계
- EKS 보안 / 보안 — 일반 보안 통제