암호화폐 업계는 오래전부터 보안 악몽이 항상 똑같을 거라고 생각했다. 도둑들이 콜드 스토리지 금고를 뚫고, 수십억 달러 규모 자산을 풀어주는 디지털 열쇠를 훔치는 일. 그 공포가 10년을 지배했다. 그런데 지금 근본적인 변화가 일어났고, 그 결과는 누구도 예상한 것보다 훨씬 심각하다.
문제는 더 이상 하드웨어 지갑에 자고 있는 키가 아니다. 실행 리스크—밀리초 단위로 움직이는 라이브 트레이딩 인프라에 내재된 취약점—가 대규모 암호화폐 해킹의 최고 공격 경로가 됐다. 개인키 도난과 달리, 실행 리스크는 대부분 조직에게 거의 보이지 않는다. 아무도 강화할 생각을 안 하는 운영 시스템 속에 숨어 있기 때문이다.
아무도 예상하지 못한 변화
예전에 자산 관리(Custody)는 한 가지만 의미했다. 개인키를 지키는 것. 끝. 업계는 이 좁은 문제만 중심으로 보안 아키텍처 전체를 세웠다—콜드 스토리지, 네트워크 단절 시스템, 다중당사자 서명(MPC). 이 방어선들은 먹혀 들어갔고, 지금도 작동한다. 근데 점점 무의미해지고 있다.
뭐가 바뀌었나. 현대 암호화폐 운영팀은 더 이상 한 거래소에서만 거래하지 않는다. 중규모 트레이딩 펌이라면 요즘 수십 개 거래소를 동시에 굴린다—중앙화 거래소, 탈중앙화 프로토콜, 스테이킹 플랫폼, 유동성 공급자, 인프라 서비스. 각 연결마다 인증정보가 필요하다. API 키, 검증인 키, 배포 시크릿, 시스템 레벨 접근 토큰. 각각이 하나의 공격 경로가 된다.
자산 관리 리스크가 블록체인에 있는 휴지 상태의 키에서, 자본이 밀리초 단위로 움직이는 라이브 실행층으로 완전히 옮겨갔다.
이건 이론 얘기가 아니다. Bybit 해킹. 주요 자산 관리사들의 최근 인증정보 침해. 이런 것들은 블록체인 보안 메커니즘의 패배가 아니었다. 그들은 활성화된 트레이딩 시스템 안에 있는 온-체인 외부 시크릿—API 키, 서버 인증정보, 배포 토큰—의 침해였다.
여기서 놓치기 쉬운 아키텍처 문제가 있다. 이런 인증정보 중 많은 것이 시크릿 매니저에 저장되어 있는데, 인증된 모든 프로세스에 ‘전체 키’를 돌려준다. 설계상 그렇다. 개발자 입장에선 편하지만, 보안 입장에선 재앙이다. 공격자가 실행 환경을 침해하면—악의적 종속성, 강박당한 직원, 아니면 어떤 외부 침해를 통해—자본 이동에 대한 완전한 접근 권한을 얻는다.
왜 트레이딩 펌은 스스로 이 취약점을 만들었나
이건 우연이 아니었다. 속도가 트레이딩의 비즈니스 모델이기 때문이다.
마켓 메이커들은 마이크로초 단위에서 산다. 10밀리초의 지연은 수천 달러의 손실을 의미한다. 그래서 시간이 지나면서 펌들은 가장 빠른 실행을 위해 최적화했다. API 키와 인증정보를 트레이딩 인프라 깊숙이 집어넣었다. 인증정보가 항상 대기 상태에 있다. 거래는 즉시 승인된다. 악수, 왕복, 마찰이 없다.
교환 조건은 당시엔 분명했고 합리적으로 보였다. 네트워크 보안, 접근 제어, 직원 심사로 키를 보호하고 있잖아. 실행 환경 자체는 충분히 안전해야 한다고 생각했다.
그런데 절대 그렇지 않다. 그리고 일방적 권한의 집중—단 하나의 침해된 인증정보가 수백만 달러를 움직일 수 있다는 사실—이 실행층을 현대 금융에서 가장 예측 가능한 공격 경로로 만든다. 자본이 빨리 움직이는 게 문제가 아니다. 권한이 정확히 공격이 일어나는 곳에 집중돼 있다는 게 문제다.
왜 지금의 보안 도구들은 여기서 거의 쓸모없나
큰 규모의 자산 관리사와 트레이딩 펌들은 강력한 보안 정책을 가지고 있다. 문제는 조율이다.
40개 거래소를 유지해 본다. 각각 다른 API 표준, 다른 접근 제어 모델, 다른 감시 요구사항을 가지고 있다. 수동으로 한다. 개발팀, 운영팀, 트레이딩 데스크, 리스크 관리 그룹에 걸쳐 사일로 형태로 한다. 설정 이탈이나 인적 오류를 도입하지 않으면서 한다.
거의 불가능하다. 그리고 단편화된 시스템에 걸쳐 수동으로 할 때, 단 하나의 실수—평문으로 저장된 인증정보 하나, 1년 된 접근 정책 하나—가 8자리 규모의 자본을 위험에 빠뜨릴 수 있다.
기존 도구들이 이걸 못 푸는 이유는 이전 버전의 문제를 중심으로 만들어졌기 때문이다. 키를 보호한다. 키 사용에 정책 레이어를 추가한다. 하지만 현대 암호화폐 운영이 실제로 의존하는 인증정보의 전체 영역에 제로 노출 원칙을 확장하지 않는다. API 키와 배포 시크릿을 개인키처럼 편집증적으로 다루지 않는다.
피할 수 없는 다음 단계
자산 관리 보안은 단순 저장을 넘어설 때 진화를 멈추지 않았다. 단계별로 성숙했다. 먼저 키 보호. 그 다음 키 사용에 정책과 다중당사자 통제 임베딩. 다음 단계는 뒤돌아보면 명백하다. 같은 제로 노출, 정책 기반 규율을 ‘모든’ 인증정보에 적용하는 것.
이제 선택이 아니다. 공격 표면이 너무 넓어져서 실행 리스크를 무시하는 건 2014년 이전 업계가 개인키 보안을 무시했던 것과 똑같다.
자산 운용사, 트레이딩 펌, 자산 관리사들에겐 이건 인증정보가 시스템을 흐르는 방식을 다시 생각하는 것을 의미한다. API 키를 온-체인 키를 보호하는 것과 같은 제도적 편집증으로 다루는 것. 전체 키 가용성이 절대 필요하지 않은 시스템을 구축하는 것—인증정보가 조각으로 나뉘고, 각 요청이 정책에 대해 평가되고, 단 하나의 침해도 왕국 전체를 풀지 못하는 시스템.
일부 펌은 이걸 9자리 손실 전에 파악할 것이다. 나머지는 못할 것이다. 그리고 준비된 조직과 준비 안 된 조직 사이의 그 격차—그곳이 다음 세대 해킹이 일어날 장소다.
🧬 관련 인사이트
자주 묻는 질문
암호화폐에서 자산 관리 리스크와 실행 리스크의 차이가 뭔가?
자산 관리 리스크는 역사적으로 저장소의 휴지 상태 키를 보호하는 것. 실행 리스크는 인증정보가 활발히 자본을 움직이는 라이브 시스템—트레이딩 시스템, 스마트 계약 배포 환경, 스테이킹 인프라. 활성화된 시스템의 손상된 인증정보는 밀리초 단위로 자금을 빼갈 수 있다.
왜 트레이딩 펌들은 API 키를 트레이딩 시스템 안에 저장하나?
속도. 마켓 메이킹은 마이크로초 단위로 작동하고, 모든 왕복이 지연 비용을 더한다. 인증정보를 실행 환경 안에 저장하면 악수 지연을 없애고, 거래를 비기적으로 더 빠르게 한다. 실행 환경이 격리돼 있는 것처럼 보일 때 그 보안 도박이 말이 됐다. 이제는 그렇지 않다.
MPC와 콜드 스토리지가 실행 리스크 해킹을 막을 수 있나?
직접적으로는 아니다. 콜드 스토리지와 MPC는 휴지 상태의 키를 보호한다. 하지만 활성 트레이딩 시스템의 인증정보가 침해되면, 그 보호들은 상관없다. 같은 원칙—일방적 권한 없음, 정책 기반 접근, 분산된 신뢰—을 라이브 실행층 자체로 확장해야 한다.
