사고에서 규제까지: 암호화폐 기관에 블록체인 침투 테스트가 필요한 이유

암호화폐 기관 및 서비스 제공업체—암호화폐 거래소, 결제 회사, 디지털 자산 수탁 기관, 그리고 수탁형 및 비수탁형 지갑 제공업체 포함—에게 있어, 대상 범위에 해당하는 경우 블록체인 침투 테스트는 선택적 예방 조치가 아닙니다. 침해가 서명이나 자금에까지 도달할 수 있거나 적용 규정이 적대적 검증을 요구하는 경우, 이는 필수적인 보증 계층입니다. 이 논거는 두 가지 축에 기반합니다: 컨트랙트 코드를 넘어서는 위험의 출처, 그리고 적대적 검증에 대한 규제 요건 또는 기대.

Figure 1. The institutional assurance gap across the money-handling chain.

기관의 노출 영역은 컨트랙트 버그를 넘어 서명, 수탁, 키, 사람, 공급망, 인프라에까지 확장됩니다 [1]. 따라서 이 표면은 익숙한 web3 보안 솔루션—코드 수준 감사와 트랜잭션 수준 모니터링—또는 전통적인 침투 테스트만으로는 완전히 커버되지 않습니다. 이는 사람, 벤더, 인터페이스, 애플리케이션이 서명, 승인, 입금, 이동될 대상에 영향을 미칠 수 있는 모든 기관에 적용되며—수탁이 외주화된 경우도 포함됩니다. 동시에 여러 시장의 규제 당국은 범위, 주기, 독립성 규칙이 서로 다른 요건, 조건부 의무, 또는 감독상의 기대를 부과하고 있습니다.

이 글은 저희 블록체인 침투 테스트 시리즈의 시작입니다. 이 시리즈 전체에서 블록체인 침투 테스트(blockchain penetration testing)와 블록체인 펜테스트(blockchain penetration testing)는 동일한 분야를 지칭합니다: 저희는 전자를 주요 용어로 사용하고 후자를 업계에서 흔히 쓰이는 동의어로 사용합니다. 본 글은 필요성에 대한 고차원적이고 전체적인 그림의 논거를 제시하며; 이후 글들에서는 이 분야의 정의, 운영 경계, 기관 공격 표면을 상세히 다룹니다.

1부: 위험은 어디에서 오는가

1.1 스마트 컨트랙트를 넘어서는 위험

스마트 컨트랙트 취약점은 여전히 중요하지만, 최근 발생한 최대 규모의 손실 상당수는 다른 곳에서, 특히 키, 서명 시스템, 운영 인프라에서 비롯되었습니다. 2024년 공격자들은 지갑 소프트웨어 제공업체를 침해하고 정상적인 트랜잭션 요청을 조작하여 DMM Bitcoin에서 약 3억 500만 달러를 탈취했습니다 [2]. 2025년에는 공급망 침해가 서명 인터페이스를 조작하면서 Bybit가 약 15억 달러를 잃었고 [3], BtcTurk의 핫월렛 손실 역시 개인키 유출로 거슬러 올라갔습니다 [4]. 저희 조사도 같은 방향을 가리킵니다: 2026년에 저희가 추적한 10만 달러 이상 손실이 발생한 사건 중, 컨트랙트 외적 실패는 사건 건수로는 약 8건 중 1건에 불과했지만 전체 손실액의 4분의 3 이상을 차지했습니다. 2026년 8월 기준, 사기 및 기타 비해킹 항목을 제외한 rekt.news의 공개 리더보드 상위 10대 해킹 사건 중 7건이 컨트랙트 외적 침해였으며, 이는 사건 건수와 금액 기준 모두 약 70%를 차지했습니다 [5].

지갑과 수탁 시스템은 이러한 패턴을 구체적으로 보여주며, 지갑 보안은 최근 몇 년간 특히 활발한 사건 발생 영역으로 남아 있습니다. 저희 조사는 실패 유형을 키 관리, 트랜잭션 서명 파이프라인, 공급망 및 종속성, 민감 데이터 노출, 암호화 구현으로 분류합니다.

컨트랙트 외적 실패	대표 사례	대략적 손실액 (보고 기준)
키 관리	BtcTurk [4], SwissBorg [6]	약 5,170만 달러 (BtcTurk), 약 4,150만 달러 (SwissBorg)
트랜잭션 서명 파이프라인	Bybit [3]	약 15억 달러
공급망 및 종속성	TrustWallet [7]	약 850만 달러
민감 데이터 노출	Slope [8]	약 410만 달러
암호화 구현	Wintermute [9], Coldcard [10]	약 1억 6,000만 달러 (Wintermute), 약 9,000만 달러 (Coldcard)*

* Coldcard의 약 9,000만 달러는 온체인상 확인된 최소치(약 1,405 BTC)입니다; 비공개 추정치는 최대 약 1억 3,000만 달러에 이릅니다.

이러한 사례들이 침투 테스트와 연결되는 이유는 단순히 그것들이 컨트랙트 범위 밖에 있어서가 아니라, 이들이 악용 가능한지 여부가 종종 배포된 구성 요소들—신원, 종속성, 서명 통제, 승인, 자금 로직—이 공격자가 진입점에서 자금까지 끝에서 끝으로 걸어갈 수 있는 경로로 어떻게 정렬되는지에 달려 있기 때문입니다.

1.2 코드 수준 감사와 트랜잭션 수준 모니터링: 필수적이지만 제한적

기존의 잘 알려진 web3 보안 솔루션들은 각각 특정 수준에서 작동합니다. 코드 수준 감사는 코드를 검사합니다(코드 감사)—컨트랙트, 지갑, 서비스 로직을요. 트랜잭션 수준 모니터링(모니터링)은 체인에 도달하는 시점의 트랜잭션을 검사합니다; 예를 들어 Phalcon Security [11]은 런타임에 악의적 활동을 탐지, 경고, 차단합니다.

이러한 솔루션들은 유용하지만, 암호화폐 기관의 자금 처리 체인—가치가 진입점에서 자금 이동 행위로 이동하는 연결된 신원, 클라우드 인프라, 서명 워크플로우, 승인 체인, 지갑, 벤더, 운영자 콘솔—에 관해서는 제한적입니다. 공격자가 도달 가능한 경로는 이 체인을 가로지르는 경로입니다: 웹, dApp, 모바일, API, 클라우드, 또는 신원 진입점에서 시작하여 서명, 승인, 자금 로직을 거치며, 실제 운영 환경에서 컨트랙트가 어떻게 동작하는지를 통과하여, 반대편 끝의 자금 이동 행위에 도달할 수 있습니다. 코드를 검토하는 것만으로는 그 경로가 조립되지 않으며, 트랜잭션을 지켜보는 것만으로는 그것을 예측할 수 없습니다. 두 가지를 함께 사용하더라도 여전히 구성상의 공백이 남을 수 있습니다: 감사는 코드가 작성된 그대로는 안전했음을 보여줄 뿐, 배포된 신원, 승인, 서명자가 여전히 그것을 강제하고 있는지는 보여주지 못합니다; 그리고 모니터링은 기술적으로는 유효하지만 운영자가 결코 의도하지 않았던 이체를 통과시킬 수 있습니다. 이 공백을 메우는 것은 실행 중인 시스템에서 통제들이 올바르게 구성되어 작동하는지에 대한 독립적인 적대적 검증입니다.

블록체인 침투 테스트는 조립되어 실행 중인 시스템을 실제로 가동해봄으로써, 사고가 그것을 드러내기 전에 그러한 경로가 자금에 도달할 수 있는지를 발견하고 입증합니다. Bybit 사례는 이 문제의 형태를 보여줍니다: 침해된 서명 인터페이스가 운영자 본인의 승인을 그들이 결코 의도하지 않은 이체로 변질시켰습니다—이는 컨트랙트, 그에 대한 감사, 트랜잭션 모니터링 모두가 정당한 것으로 판독할 수 있었던 결과입니다. 블록체인 침투 테스트는 바로 이러한 구성을 직접 겨냥합니다: 침해된 벤더, 운영자, 인터페이스의 입장을 취하여, 그러한 발판이 정상적으로 보이는 승인을 무단 자금 이동으로 바꿀 수 있는지, 그리고 배포된 통제—신원, 승인 단계, 서명 검증—중 실제로 이를 막는 것이 무엇인지 테스트합니다. 컨트랙트 코드 수준의 보증은 여전히 감사의 몫으로 남으며; 블록체인 침투 테스트는 배포된 컨트랙트가 기관 수준의 자금 도달 경로의 일부를 형성하는 경우에 한해, 그 실시간 동작을 통해서만 관여합니다—이는 강한 경계가 아니라 강조점으로 구분되는 상호보완적 범위입니다. 2부에서는 블록체인 침투 테스트가 무엇을 검증하고 그 범위가 어디에서 끝나는지 정의합니다.

1.3 전통적인 침투 테스트: 유용하지만 충분하지 않음

전통적인 침투 테스트는 클라우드, 웹 및 API, 신원, 특권 접근 표면에 걸쳐 여전히 가치가 있습니다. 그 한계는 범위와 도메인 맥락에 있습니다: 전통적인 참여는 암호화폐의 비즈니스 시맨틱이나 결합된 보안 및 컴플라이언스 모델을 반영하지 못할 수 있습니다.

암호화폐에서는 서명 하나가 되돌릴 수 없는 가치 이동을 승인할 수 있습니다; 출금 승인은 단순한 양식 제출이 아니라 자금 통제 결정입니다. 입금 반영, 잔액 회계, 내부 이체는 자금 로직입니다. 주소와 트랜잭션 역시 제재 또는 자금 출처와 관련된 의미를 지닐 수 있습니다. 테스터가 인증 우회를 발견하더라도, 그것이 서명 표시 불일치, 취약한 승인 정책, 반올림 결함과 결합하여 자금에 이르는 경로를 형성하는 방식은 놓칠 수 있습니다.

블록체인 침투 테스트는 확립된 적대적 기법을 전통적인 표면뿐 아니라 실행 중인 시스템 전반에 걸친 web3 특유의 서명, 승인, 자금 로직, 컨트랙트 동적 표면에 적용합니다. 이것의 차별점은 새로운 도구가 아니라 전문적인 web3 보안 판단력입니다: 테스터들은 공격자처럼 수탁, 트랜잭션 의도, 자금 흐름, 컴플라이언스 통제를 해석합니다. 그 차이는 목적의 차이입니다: 전통적인 테스트는 일반적으로 IT 통제 영향—장악된 관리자 세션, 도달한 서버—을 입증하는 데 그치지만, 블록체인 테스트는 가치의 이동을 최종 조건으로 삼습니다. 여기서 멈추지 않습니다: 정당한 서명 요청 내부의 수신자나 금액을 변경하고, 승인자가 보는 것, 승인 정책, 실제로 이동하는 자금이 여전히 서로 일치하는지 확인합니다.

요약하자면, 이는 정적 대 동적의 벽이 아니라 상호보완적인 보증입니다. 코드 수준 감사, 트랜잭션 수준 모니터링, 전통적인 침투 테스트는 여전히 필요합니다. 블록체인 침투 테스트는 도달 가능한 경로를 검증함으로써 이들을 연결합니다; 이는 이들을 대체하지 않으며, 침해 발견을 보장하지도, 예방을 보장하지도 않습니다.

2부: 규제 당국이 요구하는 것

요건은 관할권에 따라 다르며, 특정 주체와 시스템에 대해 라이선스, 상시, 규제 당국 촉발형 의무의 스펙트럼을 형성합니다.

Figure 2. Regulatory treatment of penetration testing across five jurisdictions.

이러한 예시들은 참고용이며 법률 자문이 아닙니다. 기관은 자신의 상태, 면제 여부, 시스템, 의무를 법률 자문가와 함께 확인해야 합니다.

미국, 뉴욕: 제한적 면제가 있는 명시적 요건. DFS 라이선스를 받은 가상화폐 사업체를 포함하여 NYDFS 23 NYCRR Part 500 [12]의 적용 대상 기업은 위험 평가에 기반하여 최소 연 1회 내부 및 외부 정보 시스템을 테스트해야 합니다. 자격을 갖춘 내부 또는 외부 당사자가 테스트를 수행할 수 있습니다. 요건을 충족하는 소규모 기업은 이 테스트 조항에서 제한적 면제를 받지만, Part 500의 다른 적용 조항에는 여전히 구속됩니다.
두바이: 연간 및 변경 시 촉발되는 요건. 라이선스를 받은 VASP는 자격을 갖춘 독립적인 제3자를 이용하여 최소 연 1회 및 신규 시스템, 애플리케이션, 제품 도입 전에 취약점 평가와 침투 테스트를 수행해야 합니다 [13]. 스마트 컨트랙트 감사는 VASP의 사업 및 활동과 관련이 있는 경우에 적용됩니다. 위협 기반 침투 테스트(Threat-led penetration testing)에는 보편적인 주기가 없습니다: VARA는 위험도에 따라 필요하고 비례적이라고 판단될 경우 이를 요구할 수 있습니다.
홍콩: 간주 신청자에 대한 라이선스 조건 요건. 라이선스를 받은 것으로 간주되는 가상자산 거래 플랫폼 신청자는 제한적 운영 이전에 만족스러운 결과와 함께 침투 테스트 및 취약점 평가를 완료해야 합니다 [14]. 신규 법인 신청자에게는 별도의 지침이 적용됩니다. 독립적인 제3자가 애플리케이션 계층과 네트워크 계층 전반에 걸쳐 지정된 인프라와 애플리케이션을 다루어야 합니다. 제한적 운영 이전에 경영진은 중간 내지 높은 위험도로 판정된 발견 사항에 대한 모든 주요 및 중대 시정 조치를 완료해야 합니다.
유럽연합: 비례적 프레임워크; 식별 여부에 따라 조건부인 TLPT. DORA는 암호자산 서비스 제공업체를 포함한 금융 기관을 대상으로 합니다 [15]. 이는 중요하거나 필수적인 기능을 지원하는 시스템에 대해 특정하게 침투 테스트가 아니라 적절한 테스트를 최소 연 1회 요구합니다. 침투 테스트는 위험과 비례성에 따라 선택되는 방법 중 하나입니다. 위협 기반 침투 테스트는 관할 당국이 지정한 기관에만 적용되며, 실제 운영 시스템에서 수행되고, 일반적으로 최소 3년마다 요구됩니다; 당국은 위험도를 근거로 그 주기를 조정할 수 있습니다. DORA는 또한 테스터 독립성 조건을 부과합니다. 소기업은 테스트 프로그램 요건에서 제외됩니다.
싱가포르: 구속력 없는 감독상의 기대. MAS 기술위험관리지침(Technology Risk Management Guidelines)은 금융 기관이 침투 테스트를 수행해야 하며 인터넷 접근 가능한 시스템은 최소 연 1회 또는 주요 변경 및 업데이트 이후 테스트되어야 한다고 명시합니다 [16]. 이는 구속력 없는 감독 지침이며 독립적인 제3자를 요구하지 않습니다. 구속력이 있는 은행 대상 사이버 위생 공지(Cyber Hygiene Notice)는 침투 테스트를 구체적으로 명시하지 않습니다. 구속력이 있는 결제 또는 디지털 결제 토큰 공지는 이 글의 범위를 벗어납니다.

종합적으로 보면, 이러한 규제 체제들은 브랜드화된 "web3" 범주가 아니라 침투 테스트 자체를 요구하거나 기대합니다. web3 전문가 버전은 대상 시스템에서 비롯됩니다: 이들이 암호화폐 가치를 승인, 서명, 수탁, 또는 회계 처리하는 경우, 이를 제대로 테스트하려면 1부에서 설명한 것과 동일한 서명 및 자금 흐름에 대한 숙련도가 필요합니다.

결론은 정확합니다: 특정 관할권의 상당수 라이선스 기관이 이미 요건이나 감독상의 기대에 직면해 있으며—모든 시장에서 동일한 의무는 아닙니다. 그 차이는 범위, 주기, 테스터 독립성, 시정 조치, 증거, 그리고 테스트가 라이선스, 상시 컴플라이언스, 또는 규제 당국 촉발형 활동을 뒷받침하는지 여부를 결정합니다.

결론: 두 축의 수렴

위험의 출처와 규제 요건 또는 기대는 동일한 결론을 가리킵니다: 대상 범위에 해당하는 기관에게 블록체인 침투 테스트는 필수적인 보증 계층입니다. 이는 접근, 승인, 서명, 자금에 걸친 도달 가능한 경로를 검증하면서 기존 통제를 보완합니다. 이는 예방을 보장할 수 없으며, 과거 특정 사건을 막았을 것임을 증명할 수도 없고, 악용 가능한 모든 경로를 찾아낼 수도 없습니다. 그 목표는 일회성 보고서가 아니라 출시, 운영, 탐지, 대응, 규제 증거 전반에 걸친 지속적인 보증입니다.

시리즈를 계속 읽어보세요:

이 시리즈의 다음 편도 곧 발행됩니다:

5부: 인가 및 서명 보안: 웹, dApps, 그리고
6부: 클라우드 및 CI/CD 보안: 자동화된 운영 공격 표면
7부: 트레저리 통제 평면 보안: 서명 및 출금 승인
8부: 거래소 원장 보안: 도난 경로와 데이터 평면 로직

BlockSec는 기관이 이 계층을 정확히 배치하도록 지원합니다: 자산, 자금 흐름, 신뢰 경계, 기존 보증을 매핑하고; 법률 자문가가 적용된다고 밝힌 의무를 확인한 다음; 테스트 목표, 범위, 접근, 프로덕션 안전장치, 시정 조치 증거, 재테스트 계획을 정의합니다. 귀사의 보증 공백을 파악하려면 저희 블록체인 침투 테스트 팀에 문의하세요; 참여 범위와 가격은 요청 시 제공됩니다. 자금이 이동하는 지점에서부터 시작하세요.

참고 문헌

처음 등장한 순서대로 번호가 매겨져 있습니다.

참고 문헌

처음 등장한 순서대로 번호가 매겨져 있습니다.

BlockSec, Crypto Payment Security Playbook.
U.S. Federal Bureau of Investigation, DC3, and Japan National Police Agency, Identification of North Korean Cyber Actors (TraderTraitor) Responsible for Theft of $308 Million from Bitcoin.DMM.com (December 2024).
BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack.
rekt.news, BtcTurk — Rekt.
rekt.news, Leaderboard.
SwissBorg, SwissBorg Security Update: Kiln Breach.
BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor.
Slope, Slope Wallet Sentry Vulnerability: Digital Forensics and Incident Response Report.
BlockSec, Our Short Analysis of the Profanity Tool Vulnerability.
BlockSec, Coldcard Entropy Failure and Seed Recovery.
BlockSec, Phalcon Security.
New York State Department of Financial Services, 23 NYCRR Part 500 — Cybersecurity Requirements for Financial Services Companies.
Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook, Part I, Section E.
Hong Kong Securities and Futures Commission, Circular 24EC65 (18 December 2024, PDF).
European Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Articles 24–27.
Monetary Authority of Singapore, Technology Risk Management Guidelines (January 2021), Sections 2 and 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).