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

기관의 노출 위험은 계약 버그를 넘어 서명, 수탁, 키, 사람, 공급망, 인프라까지 확장됩니다 [1]. 따라서 이러한 영역은 익숙한 web3 보안 솔루션—코드 수준 감사와 트랜잭션 수준 모니터링—만으로는, 또는 전통적인 침투 테스트만으로는 완전히 커버되지 않습니다. 이는 사람, 벤더, 인터페이스, 또는 애플리케이션이 무엇이 서명되고, 승인되고, 입금되고, 이동되는지에 영향을 줄 수 있는 모든 기관에 해당하며—수탁이 외주화된 경우도 포함됩니다. 이와 함께, 여러 시장의 규제 당국은 서로 다른 범위, 주기, 독립성 규칙을 가진 요건, 조건부 의무, 또는 감독 기대를 부과하고 있습니다.
이 글은 저희 web3 침투 테스트 시리즈의 시작입니다. 이 시리즈 전반에 걸쳐, 블록체인 침투 테스트와 web3 침투 테스트는 동일한 분야를 지칭합니다: 전자를 주요 용어로 사용하고 후자는 업계에서 흔히 쓰이는 동의어로 사용합니다. 이 글은 필요성에 대한 고차원적이고 전체적인 논거를 제시하며, 이후의 글들은 이 분야, 그 운영 경계, 그리고 기관의 공격 표면을 자세히 정의합니다.
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 [11]은 런타임에 악성 활동을 탐지, 경고, 차단합니다.
이러한 솔루션은 유용하지만, 암호화폐 기관의 자금 처리 체인—진입점에서 자금 이동 행위까지 가치가 이동하는 연결된 신원, 클라우드 인프라, 서명 워크플로우, 승인 체인, 지갑, 벤더, 운영자 콘솔—에 관해서는 제한적입니다. 공격자가 도달 가능한 경로는 이러한 체인을 가로지르는 경로입니다: 웹, dApp, 모바일, API, 클라우드, 또는 신원 진입점에서 서명, 승인, 자금 로직을 거쳐, 실제 라이브 환경에서 컨트랙트가 어떻게 동작하는지를 통과할 수 있으며, 반대편 끝의 자금 이동 행위에 이를 수 있습니다. 코드를 검토하는 것은 이 경로를 조립하지 않으며, 트랜잭션을 지켜보는 것은 이를 예측하지 않습니다. 두 가지를 함께 사용하더라도, 여전히 구성상의 공백이 남을 수 있습니다: 감사는 작성된 코드가 견고했음을 보여줄 뿐, 배포된 신원, 승인, 서명자들이 여전히 이를 강제하고 있음을 보여주지는 않습니다; 그리고 모니터링은 기술적으로는 유효하지만 운영자가 의도한 바가 전혀 아닌 이체를 통과시킬 수 있습니다. 이 공백을 메우는 것은 통제가 실제 운영 시스템에서 올바르게 구성되어 있는지를 독립적으로 적대적 검증하는 것입니다.
블록체인 침투 테스트는 조립되어 실행 중인 시스템을 실제로 실행해봄으로써, 사건이 이를 드러내기 전에 그러한 경로가 자금에 도달할 수 있는지를 발견하고 입증합니다. Bybit 사건 패턴은 문제의 형태를 보여줍니다: 침해된 서명 인터페이스가 운영자 자신의 승인을 그들이 전혀 의도하지 않은 이체로 바꾸어 놓았습니다—이는 컨트랙트, 그에 대한 감사, 트랜잭션 모니터링 각각이 정당하다고 판단할 수 있는 결과였습니다. Web3 침투 테스트는 바로 이 구성 문제를 직접 겨냥합니다: 침해된 벤더, 운영자, 또는 인터페이스의 입장을 취해, 그러한 발판이 정당해 보이는 승인을 무단 자금 이동으로 바꿀 수 있는지, 그리고 배포된 통제—신원, 승인 단계, 서명 검사—중 실제로 무엇이 이를 막는지를 테스트합니다. 컨트랙트 코드 수준 보증은 여전히 감사의 역할로 남으며, web3 침투 테스트는 배포된 컨트랙트를, 이것이 기관 수준의 자금 경로의 일부를 형성하는 경우에 한해, 그 실제 동작을 통해서만 다룹니다—이는 강경한 경계가 아니라 강조점에 따라 구분되는 상호 보완적인 범위입니다. 2부는 web3 침투 테스트가 검증하는 대상과 그 범위가 끝나는 지점을 정의합니다.
1.3 전통적인 침투 테스트: 유용하지만 충분하지 않음
전통적인 침투 테스트는 클라우드, 웹 및 API, 신원, 그리고 권한 있는 접근 표면 전반에 걸쳐 여전히 가치가 있습니다. 그 한계는 범위와 도메인 맥락에 있습니다: 일반적인 참여는 암호화폐의 비즈니스 시맨틱이나 결합된 보안 및 컴플라이언스 모델을 다루지 못할 수 있습니다.
암호화폐에서는 서명 하나가 되돌릴 수 없는 가치 이동을 승인할 수 있습니다; 출금 승인은 단순한 양식 제출이 아니라 자금 통제 결정입니다. 입금 반영, 잔액 회계, 내부 이체는 자금 로직입니다. 주소와 트랜잭션 또한 제재나 자금 출처 의미를 가질 수 있습니다. 테스터는 인증 우회를 발견하더라도, 이것이 서명 표시 불일치, 취약한 승인 정책, 또는 반올림 결함과 결합하여 자금으로의 경로를 형성한다는 사실을 놓칠 수 있습니다.
블록체인 침투 테스트는 확립된 적대적 기법을 전통적인 표면뿐만 아니라 실행 중인 시스템 전반의 web3 고유의 서명, 승인, 자금 로직, 그리고 컨트랙트 동적 표면에도 적용합니다. 그 차별점은 새로운 도구가 아니라 전문 web3 보안 판단력입니다: 테스터는 공격자가 그러하듯 수탁, 트랜잭션 의도, 자금 흐름, 컴플라이언스 통제를 해석합니다. 그 차이는 목적의 차이입니다: 일반적인 테스트는 대개 IT 통제 영향—장악된 관리자 세션, 도달한 서버—을 입증하는 반면, web3 테스트는 가치의 이동을 종결 조건으로 다룹니다. 여기서 멈추지 않습니다: 정당한 서명 요청 내부의 수신자나 금액을 변경하고, 승인자가 보는 것, 승인 정책, 그리고 실제로 이동하는 자금이 여전히 서로 일치하는지 확인합니다.
요약하자면, 이는 정적 대 동적이라는 경계가 아니라 상호 보완적인 보증입니다. 코드 수준 감사, 트랜잭션 수준 모니터링, 전통적인 침투 테스트는 여전히 필요합니다. Web3 침투 테스트는 도달 가능한 경로를 검증함으로써 이들을 연결하는 것이지, 이를 대체하거나 침해 발견을 보장하거나 예방을 보장하지 않습니다.
2부: 규제 당국이 요구하는 것
요건은 관할권마다 다르며, 특정 기관과 시스템에 대해 라이선스, 지속적, 규제 당국 주도의 의무들로 이루어진 스펙트럼을 형성합니다.

이 예시들은 예시를 위한 것이며 법률 자문이 아닙니다. 기관들은 자신의 상태, 면제 사항, 시스템, 의무를 법률 자문가와 함께 확인해야 합니다.
-
미국, 뉴욕: 제한된 면제가 있는 명시적 요건. NYDFS 23 NYCRR Part 500 [12]의 적용 대상 기관—DFS 라이선스를 받은 가상화폐 사업체를 포함—은 위험 평가에 기반하여 최소 연 1회 정보 시스템을 내부와 외부에서 테스트해야 합니다. 자격을 갖춘 내부 또는 외부 당사자가 테스트할 수 있습니다. 자격을 갖춘 소규모 기관은 이 테스트 조항에 대해 제한된 면제를 받지만, Part 500의 다른 적용 조항들에는 여전히 구속됩니다.
-
두바이: 연간 및 변경 시 발동되는 요건. 라이선스를 받은 VASP는 최소 연 1회 및 새로운 시스템, 애플리케이션, 제품을 도입하기 전에 취약점 평가 및 침투 테스트를 실시해야 하며 [13], 자격을 갖춘 독립적인 제3자를 이용해야 합니다. 스마트 컨트랙트 감사는 VASP의 사업 및 활동과 관련이 있는 경우 적용됩니다. 위협 기반 침투 테스트에는 보편적인 주기가 없습니다: VARA는 위험을 기준으로 필요하고 비례적이라고 판단될 경우 이를 요구할 수 있습니다.
-
홍콩: 간주 신청자에 대한 라이선스 조건 요건. 라이선스 간주 가상자산 거래 플랫폼 신청자는 제한 운영 이전에 만족스러운 결과로 침투 테스트 및 취약점 평가를 완료해야 합니다 [14]. 신규 법인 신청자에는 별도의 지침이 적용됩니다. 독립적인 제3자가 애플리케이션 및 네트워크 계층 전반에 걸쳐 지정된 인프라 및 애플리케이션을 다루어야 합니다. 제한 운영 이전에, 경영진은 중간에서 높은 위험 항목에 대한 모든 주요 및 심각한 시정 조치를 완료해야 합니다.
-
유럽연합: 비례적 프레임워크; 위협 기반 침투 테스트는 식별 시 적용. DORA는 암호화 자산 서비스 제공업체를 포함한 금융 기관을 다룹니다 [15]. 이는 중요하거나 필수적인 기능을 지원하는 시스템에 대해 침투 테스트가 아니라 적절한 테스트를 최소 연 1회 요구합니다. 침투 테스트는 위험과 비례성에 따라 선택되는 방법 중 하나입니다. 위협 기반 침투 테스트는 관할 당국이 식별한 기관에만 적용되며, 실제 운영 시스템에서 수행되고, 일반적으로 최소 3년마다 요구됩니다; 당국은 위험을 근거로 이 주기를 조정할 수 있습니다. DORA는 또한 테스터 독립성 조건을 부과합니다. 초소규모 기업은 테스트 프로그램 요건에서 제외됩니다.
-
싱가포르: 구속력 없는 감독 기대. MAS 기술 위험 관리 가이드라인은 금융 기관이 침투 테스트를 실시해야 하며, 인터넷 접속 가능한 시스템은 최소 연 1회 또는 주요 변경이나 업데이트 이후 테스트할 것으로 기대한다고 명시합니다 [16]. 이는 구속력 없는 감독 지침이며 독립적인 제3자를 요구하지 않습니다. 구속력 있는 은행 대상 사이버 위생 고시는 침투 테스트를 명시하지 않습니다. 구속력 있는 결제 또는 디지털 결제 토큰 고시는 이 글의 범위 밖입니다.
종합하면, 이러한 체제들은 침투 테스트를 요구하거나 기대하지만—브랜드화된 "web3" 카테고리를 요구하는 것은 아닙니다. Web3 전문 버전은 대상 범위에 있는 시스템에서 자연스럽게 도출됩니다: 이러한 시스템이 암호화폐 가치를 승인, 서명, 수탁, 또는 회계 처리하는 경우, 이를 제대로 테스트하려면 1부에서 설명한 것과 동일한 서명 및 자금 흐름에 대한 능숙함이 필요합니다.
결론은 정확합니다: 특정 관할권의 상당수 라이선스 기관들은 이미 요건 또는 감독 기대에 직면해 있습니다—다만 모든 시장에서 동일한 의무는 아닙니다. 그 차이는 범위, 주기, 테스터 독립성, 시정 조치, 증거, 그리고 테스트가 라이선스 취득, 지속적인 컴플라이언스, 또는 규제 당국 주도 훈련을 뒷받침하는지 여부를 결정합니다.
결론: 두 축이 수렴하다
리스크 발생 원인과 규제 요건 또는 기대는 동일한 결론을 가리킵니다: 대상 범위에 해당하는 기관에게, web3 침투 테스트는 필수적인 보증 계층입니다. 이는 접근, 승인, 서명, 자금 전반에 걸쳐 도달 가능한 경로를 검증하면서 기존 통제를 보완합니다. 이는 예방을 보장하거나, 과거의 특정 사건을 막을 수 있었음을 입증하거나, 악용 가능한 모든 경로를 찾아낼 수 있음을 보장할 수는 없습니다. 목표는 일회성 보고서가 아니라 출시, 운영, 탐지, 대응, 규제 증거 전반에 걸친 지속적인 보증입니다.
시리즈를 계속 확인하세요:
또한 이 시리즈에서 곧 발행 예정:
- 5부: 인증 및 서명 보안: 웹, dApp, 모바일
- 6부: 클라우드 및 CI/CD 보안: 자동화된 운영 공격 표면
- 7부: 트레저리 제어 플레인 보안: 서명 및 출금 승인
- 8부: 거래소 원장 보안: 도난 경로 및 데이터 플레인 로직
BlockSec는 기관이 이 계층을 정확하게 배치할 수 있도록 돕습니다: 자산, 자금 흐름, 신뢰 경계, 기존 보증을 매핑하고; 법률 자문가가 적용된다고 말하는 의무를 확인하며; 이후 테스트 목표, 범위, 접근, 프로덕션 안전 조치, 시정 조치 증거, 재테스트 계획을 정의합니다. 귀사의 보증 공백을 파악하려면, [저희 블록체인 침투 테스트 팀에 문의하세요](https://blocksec.com/blockchain-penetration-testing) ; 참여 범위와 가격은 요청 시 제공됩니다. 자금이 이동하는 지점에서 시작하세요.
참고 문헌
최초 등장 순서로 번호가 매겨져 있습니다.
-
BlockSec, Crypto Payment Security Playbook. https://blocksec.com/crypto-payment-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 (2024년 12월). https://www.fbi.gov/news/press-releases/fbi-dc3-and-npa-identification-of-north-korean-cyber-actors-tracked-as-tradertraitor-responsible-for-theft-of-308-million-from-bitcoindmmcom
-
BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack. https://blocksec.com/blog/bybit-1-5-b-hack-in-depth-analysis-of-the-malicious-safe-wallet-upgrade-attack
-
rekt.news, BtcTurk — Rekt. https://rekt.news/btcturk-rekt
-
rekt.news, Leaderboard. https://rekt.news/leaderboard
-
SwissBorg, SwissBorg Security Update: Kiln Breach. https://swissborg.com/blog/swissborg-security-update-kiln-breach
-
BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor. https://blocksec.com/blog/trust-wallet-incident-a-stolen-api-key-turns-the-official-update-channel-into-a-backdoor
-
Slope, Slope Wallet Sentry Vulnerability: Digital Forensics and Incident Response Report. https://slope-finance.medium.com/slope-wallet-sentry-vulnerability-digital-forensics-and-incident-response-report-d7a5904e5a39
-
BlockSec, Our Short Analysis of the Profanity Tool Vulnerability. https://blocksec.com/blog/our-short-analysis-of-the-profanity-tool-vulnerability
-
BlockSec, Coldcard Entropy Failure and Seed Recovery (개인 키 노출). https://blocksec.com/blog/coldcard-entropy-failure-seed-recovery
-
BlockSec, Phalcon Security (트랜잭션 모니터링 및 차단). https://blocksec.com/phalcon/security
-
New York State Department of Financial Services, 23 NYCRR Part 500. https://www.dfs.ny.gov/industry_guidance/cybersecurity
-
Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook, Part I, Section E. https://rulebooks.vara.ae/rulebook/e-testing-and-audit
-
Hong Kong Securities and Futures Commission, Circular 24EC65, 18 December 2024. https://apps.sfc.hk/edistributionWeb/api/circular/openFile?lang=EN&refNo=24EC65
-
European Union, Regulation (EU) 2022/2554 (Digital Operational Resilience Act), Articles 24-27. https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng
-
Monetary Authority of Singapore, Technology Risk Management Guidelines (2021년 1월), Sections 2 and 13, https://www.mas.gov.sg/regulation/guidelines/technology-risk-management-guidelines; _Notice FSM-N06, Notice on Cyber Hygiene_ (2024), https://www.mas.gov.sg/regulation/notices/notice-fsm-n06



