시스템이 멈춘 뒤에도 고객의 권리와 사고 증거, 담당자의 책임은 확인할 수 있어야 한다. KCBCA Signals 2호 편집글은 이런 관점에서 사이버 복원력을 다룬다. 첫 과제는 양자내성암호(PQC, Post-Quantum Cryptography) 전환이다.
양자컴퓨터가 암호를 깰 시점은 불확실하지만, 전환 준비는 그보다 앞서야 한다.
토큰화에서도 스마트 계약의 정상 작동만으로는 금융 인프라의 안전성을 판단하기 어렵다. '운영자가 사라진 다음 날'에도 수탁 자산이 분리되고, 도산 시 권리와 원장 간 결제 완결성이 보장되는지 확인해야 한다.
편집글은 기고 13편의 공통 과제를 짚는 서문이다. 세부 기준이나 수치를 정하지는 않는다. 이 글에서는 그 과제를 정리하고, 실무에서 남길 점검 기록을 살펴본다.
다섯 과제와 전환·대응의 부담
편집글이 다루는 과제는 다섯 가지다. 양자내성암호 전환, 공격과 방어의 자동화, 암호문 수집 공격(HNDL, Harvest Now Decrypt Later)에 대한 책임, 토큰화의 인프라 조건, 기술 변화에 맞춘 거버넌스다. 공통점은 기존의 보안 가정이 깨질 때도 보호와 책임이 이어져야 한다는 것이다.
먼저 전환에 따르는 부담을 봐야 한다. NIST 표준 알고리즘인 ML-KEM·ML-DSA·SLH-DSA나 한국의 KpqC로 옮기는 일은 단순한 소프트웨어 업데이트보다 복잡하다. 키와 서명이 커지면 지연, 패킷 분할, 블록체인 수수료 부담이 따른다.
엔드포인트 장악과 서명 암호 해독도 서로 다른 공격 경로로 구분해야 한다.
공격과 대응의 속도 차이도 문제다. 생성형 AI는 정찰·사칭·사회공학을 가속하고, AI 보조 테스트는 성숙한 소프트웨어에서도 약점을 찾아낸다. 취약점을 찾는 비용이 줄어들수록 개발·운영 팀이 처리해야 할 일은 늘어난다.
우선순위를 정하고 수정·검증할 역량이 없으면 발견 건수가 늘어도 실익은 적다.
장기 보관 정보와 토큰화 자산의 점검
HNDL은 지금 암호화된 통신을 모아 두었다가 나중에 해독을 시도하는 위협이다. 현재 시스템을 언제까지 쓸지만 봐서는 부족하다. 지식재산·임상 기록·기관 정보는 그보다 오래 비밀로 유지해야 할 수 있다.
편집글은 이런 정보의 전환 계획과 책임 소재를 분명히 하고, 실제 보험 약관도 검토할 것을 제안한다.
Mosca의 관계식(X + Y > Z)은 정보 보호 기간과 암호 전환 기간의 합을 양자 능력 도래까지 남은 시간과 비교해 보호 공백을 살피는 계획 모델이다. 양자컴퓨터의 등장 시점을 정확히 예측하거나 이미 기록이 해독됐음을 보여 주는 식은 아니다.
토큰화에서는 운영 중단 상황을 가정해 본다. 편집글이 제안하는 훈련은 '운영자가 사라진 다음 날'이다. 자본을 투입하기 전에 수탁 자산 분리, UNIDROIT 원칙에 따른 도산 시 권리, 원장 간 결제 완결성을 확인한다.
변경 때마다 남겨야 할 근거와 책임 기록
마지막 과제는 규제보다 빠른 기술 변화에 거버넌스가 어떻게 대응할지다. 기고자들은 다음과 같이 제안한다. 고객 자산 보호·책임·구제의 핵심 의무는 기본 법률에, 기술 기준은 유연하게 바꿀 수 있는 장치에 둔다.
정기 감사에만 기대지 않고 스마트 계약 업그레이드, 신규 토큰 상장, 비정상적인 체인 간 자금 흐름이 발생하면 다시 평가한다. 자동화된 결정에는 이해할 수 있는 설명과 검증 가능한 공정성 증거, 이의제기 경로를 마련한다.
점검 결과에 '이상 없음'만 적어서는 근거가 남지 않는다. 누가 무엇을 언제 확인했는지, 어떤 사건 때문에 다시 평가했는지 기록해야 한다. 그래야 다음 사고에서 당시의 판단과 책임을 확인할 수 있다.
사고 원인을 기록할 때도 확인된 사실과 추정을 구분해야 한다. 원문은 10월 29일 한 대형 거래소 사고에 관한 회사의 잠정 발표와 보안 업체의 독립 분석을 구분한다. 공통 쟁점은 출금 권한의 취약성이다.
블록체인 암호가 깨졌다는 증거는 아니다. 양자 능력의 도래 시점과 필요한 자원도 아직 불확실하다.
사이버 복원력 점검 기록 예시 — KCBCA 편집 구성
| 확인 항목 | 남길 기록 | 담당·확인 경로 | 점검 초점 |
|---|---|---|---|
| 취약점 발견 뒤 조치 | 건별 우선순위·수정·검증 결과 | 보안·개발 팀 조치 대기열 | 대응 역량 |
| 장기 보관 정보의 보호 기간 | 정보별 보호 기간·전환 계획·보험 약관 검토 결과 | 정보보호 책임자, 이사회 보고 | HNDL |
| 운영 중단 대비 | 수탁 자산 분리·도산 시 권리·결제 완결성 확인 결과 | '운영자가 사라진 다음 날' 훈련 | 토큰화 |
| 사건 발생에 따른 재평가 | 재평가 계기와 결과 | 변경 관리, 감독 보고 | 변경 대응 |
| 자동화된 결정 | 설명 자료·공정성 증거·이의제기 처리 기록 | 이용자 이의제기 창구 | 판단 근거 |
실무에서 구분할 사항
사고 예방과 사고 이후의 책임
사고가 없었다는 사실만으로 복원력을 판단하기는 어렵다. 시스템이 바뀌거나 무너졌을 때도 권리를 확인하고, 증거를 보존하며, 책임을 따질 수 있어야 한다. 복원력 점검에는 사고 이후의 보호와 구제도 포함된다.
정기 점검과 변경에 따른 재평가
이전 점검의 전제가 지금도 유효한지 확인해야 한다. 스마트 계약을 업그레이드하거나 신규 토큰을 상장했다면 그 변경을 계기로 다시 평가한다. 시스템이 달라졌는데 과거의 판단을 그대로 적용해서는 새로운 위험을 놓칠 수 있다.
개인·실무자의 기본 확인 절차
편집글은 별도 경로로 요청을 확인하고, 서명 전에 거래를 시뮬레이션하며, 서비스 계정과 개인 계정을 분리할 것을 제안한다. 영상 통화에서 익숙한 목소리와 얼굴을 봤더라도 실시간 딥페이크일 가능성을 고려해야 한다.
점검에서 남길 것
- 사고 뒤에도 확인할 수 있는 권리·증거·책임
- 정보 보호 기간을 고려한 암호 전환 계획
- 운영 중단 시 자산과 결제의 처리 조건
- 점검 담당자·확인 근거·재평가 계기
무료 전문 열람: https://signals.kcbca.ca/
편집글 바로 읽기: https://signals.kcbca.ca/signals/read/#page=5
참고 KCBCA Signals Vol.1 Issue 2 · JJ Park 편집글 「Trust That Survives Failure」, p.5–8
