금융기관이 블록체인을 도입하면 취약점 평가에서 막힌다
법은 막지 않는데 평가 체계가 막는다
금융기관에 블록체인 인프라를 납품하려는 쪽에서든, 도입을 검토하는 금융기관 쪽에서든, 가장 먼저 부딪히는 질문이 있다. “기술적으로 되는가”가 아니다. ”현행 취약점 평가를 통과할 수 있는가”다.
2026년 전자금융기반시설 보안 취약점 평가기준 안내서에는 정보보호 관리체계 항목만 175개가 있다. 이 중에서 블록체인 인프라를 넣는 순간 답을 못 하게 되는 항목이 여럿 있다. 그런데 가상자산 거래소 대상 평가기준에는 블록체인 22개, 월렛 25개, 스마트컨트랙트 15개 항목이 이미 있다. 노드 분산 배치, 포크 발생 시 이중지불 방지, 51% 공격 대응, 멀티시그 적용 같은 것들이다.
금융기관용 평가기준에는 이런 항목이 하나도 없다.
거래소에는 블록체인 전용 평가 체계가 있고, 금융기관에는 없다. 이 공백이 금융기관의 블록체인 도입을 막는 가장 실질적인 병목이다. 기술이 안 돼서가 아니라, 평가 기준이 어디서 오는지가 정해져 있지 않기 때문이다.
구체적으로 어디서 막히는가
금융기관이 블록체인을 도입할 때 기존 감독규정과 충돌하는 지점은 크게 세 가지다.
1. 온체인 원장에서 오류가 발생하면 어떻게 수정하는가
감독규정 제27조(전산원장 통제)는 원장의 변경 대상과 방법, 변경 권한자 지정, 변경 전후 내용의 자동기록과 보존, 변경 내용의 제3자 확인을 요구한다. 평가 항목이 8개다.
대차대조표 등 중요자료 계상액과 각종 보조부/거래기록/전산원장파일의 계상액에 대한 상호일치여부에 대한 전산시스템을 통한 주기적인 확인 여부
— 평가항목 #102전산원장 불일치 원인과 조치 내용을 전산자료형태로 5년간 보존 여부
— 평가항목 #103중요원장의 조회, 수정, 삭제, 삽입한 작업자와 작업내용 기록 및 5년간 보존 여부
— 평가항목 #104
블록체인 원장은 기본적으로 변경이 안 된다. 그러면 “변경 통제절차”를 적용할 수 없다. 오류가 발생했을 때 어떻게 수정하는가?
현실적으로 두 가지 방향이 있다.
A안: 보정 트랜잭션 방식.
온체인 원장을 직접 수정하지 않고, 원본 트랜잭션을 참조하는 보정(correction) 트랜잭션을 발행한다. 변경 전후 상태를 메타데이터로 기록하고, 보정 권한자의 서명을 온체인에 남긴다. 감독규정이 요구하는 “변경 전후 내용의 자동기록”과 “변경 권한자 지정”을 온체인 레벨에서 충족시킬 수 있다. 다만 원장의 최종 잔액 산출 로직이 복잡해지고, 보정 트랜잭션 자체의 유효성 검증 체계를 별도로 설계해야 한다.
B안: 오프체인 reconciliation 레이어.
온체인 원장은 원본 그대로 유지하고, 금융기관 내부 DB에서 보정 처리를 수행한다. 온체인 원장과 내부 원장 사이의 대조(reconciliation) 기록을 별도로 보존하고, 불일치 원인과 조치 내용을 5년간 보관한다. 기존 금융기관 시스템과의 통합이 상대적으로 쉽지만, 온체인 원장이 “보조 원장” 역할로 격하되면서 블록체인 도입의 실질적 의미가 줄어든다.
현행 규정은 이 두 방향 중 어느 것이 요건을 충족하는지에 대해 아무 말이 없다.
2. 블록체인 프라이빗 키를 기존 키 관리 체계에 어떻게 넣는가
감독규정 제19조(암호프로그램 및 키 관리 통제)는 암호 및 인증시스템에 적용되는 키에 대해 주입, 운용, 갱신, 폐기의 절차와 방법을 마련할 것을 요구한다.
암호 및 인증시스템에 적용되는 키에 대하여 주입/운용/갱신/폐기에 대한 절차 및 방법 마련 여부
— 평가항목 #80
블록체인 프라이빗 키는 기존 금융기관의 암호키와 성격이 다르다. 기존 키는 세션 암호화나 전자서명용이고, HSM 안에서 생성-운용-갱신-폐기 생명주기가 관리된다. 블록체인 프라이빗 키는 자산 통제 권한 그 자체이고, 키가 유출되면 자산이 직접 이동한다.
A안: HSM 기반 키 래핑.
기존 금융기관 키 관리 인프라(HSM)에 블록체인 프라이빗 키를 통합한다. HSM 내부에서 키 생성, 서명 연산을 수행하고, 키가 HSM 외부에 노출되지 않는 구조다. 기존 감독규정의 “주입/운용/갱신/폐기” 절차에 자연스럽게 매핑된다. 다만 블록체인 네트워크별 서명 알고리즘(secp256k1, ed25519 등)을 HSM이 지원해야 하고, 키 갱신(rotation) 시 온체인 주소가 바뀌는 문제를 처리해야 한다.
B안: MPC 기반 분산 서명.
프라이빗 키를 여러 파티에 분산시켜 단일 장소에 키가 존재하지 않는 구조다. 키 유출 리스크를 구조적으로 줄일 수 있지만, 현행 규정의 “키 주입” 개념과 맞지 않는다. 키가 한 번도 한 장소에 모이지 않는데 “주입”이란 무엇인가? “폐기” 절차는 각 파티의 키 조각을 개별 폐기하는 것으로 충분한가? 현행 규정 체계에서 이 질문에 대한 답이 없다.
멀티시그도 대안이지만, 이건 키 관리 방식이 아니라 승인 구조의 문제이므로 감독규정 제19조와는 다른 층위의 논의다.
3. 노드가 이미 분산되어 있으면 재해복구센터를 어떻게 적용하는가
감독규정 제23조(비상대책 등의 수립·운용)는 주전산센터와 일정 거리 이상 떨어진 안전장소에 재해복구센터를 구축하고 운영할 것을 요구한다.
주전산센터와 일정거리 이상 떨어진 안전장소에 재해복구센터 구축 및 운영 여부
— 평가항목 #123
블록체인 노드는 설계상 여러 지역에 분산 배치된다. 분산 자체가 장애 복원력을 제공한다. 그러면 별도의 재해복구센터라는 개념을 어떻게 적용하는가?
A안: 노드 분산 자체를 재해복구로 인정받는 논리 구성. 블록체인 네트워크의 지리적 분산, 합의 알고리즘에 의한 데이터 복제, 노드 장애 시 자동 복구 메커니즘이 전통적 DR센터의 기능을 구조적으로 대체한다는 논리다. 이 논리가 받아들여지려면 “어떤 수준의 분산이 감독규정의 재해복구 요건을 충족하는가”에 대한 기준이 필요하다. 현재는 없다.
B안: 기존 DR센터 구조를 유지하면서 블록체인 노드를 그 안에 배치. 물리적 DR센터를 구축하고, 그 안에 블록체인 풀노드와 관련 미들웨어를 운용한다. 감독규정 형식을 확실히 충족하지만, 블록체인의 분산 아키텍처와 중복되는 인프라 비용이 발생하고, 분산 네트워크의 장점을 상당 부분 포기하게 된다.
왜 이렇게 되었는가
한국 금융 IT 규제는 세 개의 층으로 되어 있다. 첫 번째 층은 법률이다. 전자금융거래법, 자본시장법, 전자증권법. “무엇을 해야 한다”를 선언하는 수준이고 기술적 디테일은 없다. 두 번째 층은 감독규정이다. 전자금융감독규정(금융위원회 고시)과 시행세칙(금융감독원)이 “어떻게 해야 하는지”를 구체화한다. 세 번째 층은 금융보안원이 매년 발행하는 보안 취약점 평가기준 안내서다. 금융기관은 연 1회 이상 이 기준에 따라 취약점 분석·평가를 받아야 한다.
법률 자체는 기술 중립성을 명시하고 있다.
금융위원회는 제2항의 기준을 정할 때 특정 기술 또는 서비스의 사용을 강제하여서는 아니 되며, 보안기술과 인증기술의 공정한 경쟁이 촉진되도록 노력하여야 한다.
— 전자금융거래법 제21조(안전성의 확보의무) 제3항
기술 중립성을 선언했지만, 그 아래의 감독규정과 평가기준이 “전산원장 변경 통제”, “재해복구센터 구축”, “전용회선 사용” 같은 전통 인프라 전제 위에 설계되어 있다. 법은 블록체인을 막지 않는데, 평가 체계가 블록체인을 전제하지 않는다.
블록체인 업계에서 “규제가 문제다”라고 할 때, 대부분 첫 번째 층인 법률만 이야기한다. 실무에서 실제로 걸리는 건 두 번째, 세 번째 층이다.
독일이 다르게 접근한 이유
독일은 2021년에 전자증권법(eWpG)을 제정하면서 블록체인 기반 증권을 “암호증권(Kryptowertpapiere)”이라는 별도 카테고리로 규율하는 체계를 만들었다. 기존 법에 블록체인을 끼워넣는 게 아니라, 블록체인 원장의 특성에 맞는 별도 통제 체계를 설계한 것이다.
여기서 뽑을 수 있는 원칙은 하나다. 불변성과 분산성을 가진 원장에 “변경 통제”와 “중앙 복구센터”를 적용하려면, 기존 규정을 그대로 적용하는 게 아니라 동등한 수준의 보호를 다른 방식으로 달성하는 별도 기준이 필요하다는 것이다.
한국은 이와 반대 방향이다. 기존 법체계를 유지한 채 “블록체인 기술을 쓸 수 있다”만 허용했다. 그래서 금융기관의 기존 원장이 주(主) 원장이어야 하고, 블록체인 원장은 보조적 역할로 제한되는 구조가 자연스럽게 형성된다.
이 상태에서 블록체인을 도입하려면 현실적으로 필요한 것이 있다. 온체인 원장 위에 기존 감독규정의 통제 요건을 충족시키는 오프체인 compliance layer다. 보정 처리 절차, 키 생명주기 관리, reconciliation 체계, 감사 추적 기록을 기존 평가 항목에 매핑할 수 있는 설계가 그 안에 들어가야 한다. 규정이 바뀌기를 기다리는 것은 전략이 아니다. 현행 규정 체계 안에서 평가를 통과할 수 있는 설계를 먼저 만드는 것이 출발점이다.
B-Harvest가 하고 있는 작업
B-Harvest는 금융기관에 블록체인 인프라를 제공하기 위해 이 갭을 어떤 설계로 메울 수 있는지 탐색하고 있다. 위에서 제시한 A안/B안은 아직 규정이 확정하지 않은 영역이고, 어떤 방식이 평가를 통과할 수 있는지는 규제기관과의 대화 없이는 확정할 수 없다. 그 대화의 출발점이 되는 것이 이 글의 목적이다.
참고 자료
전자금융거래법 전문 (법제처)
전자금융감독규정 전문 (법제처)
독일 전자증권법(eWpG) 해설 (BaFin)
독일 eWpG 개요 (Library of Congress)