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

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

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

이 글은 우리의 블록체인 침투 테스트 시리즈를 시작합니다. 이 시리즈 전체에서 블록체인 침투 테스트와 web3 침투 테스트는 동일한 분야를 지칭합니다: 우리는 전자를 주된 용어로, 후자를 업계에서 흔히 쓰이는 동의어로 사용합니다. 이 글은 필요성에 대한 전반적이고 큰 그림의 논거를 제시하며, 이후 글들에서는 이 분야, 그 운영 범위, 그리고 기관 공격 표면을 자세히 정의합니다.

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

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

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

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

* Coldcard의 약 9천만 달러는 검증된 온체인 하한선(약 1,405 BTC)입니다. 비공개 추정치는 최대 약 1억 3천만 달러에 이릅니다.

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

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

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

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

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

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

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

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

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

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

2부: 규제 기관이 요구하는 것

요구사항은 관할권마다 다르며, 특정 기관 및 시스템에 대해 라이선싱, 지속적, 규제 기관 촉발 의무의 스펙트럼을 형성합니다.

이 예시들은 예시를 위한 것이며 법률 자문이 아닙니다. 기관은 자신의 상태, 예외, 시스템, 의무를 법률 자문가와 확인해야 합니다.

• 미국 뉴욕: 제한적 예외가 있는 명시적 요구사항. NYDFS 23 NYCRR Part 500 [12] 적용 대상 기관—DFS 라이선스를 받은 가상화폐 사업체 포함—은 위험 평가에 기반하여 최소 연 1회 정보 시스템을 내부와 외부에서 테스트해야 합니다. 적격한 내부 또는 외부 당사자가 테스트를 수행할 수 있습니다. 자격을 갖춘 소규모 기관은 이 테스트 조항에서 제한적 예외를 받지만 Part 500의 다른 적용 가능한 조항들의 대상으로 남습니다.

• 두바이: 연간 및 변경 촉발 요구사항. 라이선스를 받은 VASP는 최소 연 1회 및 새로운 시스템, 애플리케이션, 제품을 도입하기 전에 취약점 평가 및 침투 테스트를 실시해야 하며 [13], 적격하고 독립적인 제3자를 이용해야 합니다. 스마트 컨트랙트 감사는 VASP의 사업 및 활동과 관련이 있는 경우 적용됩니다. 위협 주도형 침투 테스트에는 보편적인 주기가 없습니다: VARA는 위험에 기반하여 필요하고 비례적인 경우 이를 요구할 수 있습니다.

• 홍콩: 잠정 승인 신청자에 대한 라이선스 조건 요구사항. 잠정 라이선스로 간주되는 가상자산 거래 플랫폼 신청자는 제한적 운영 이전에 만족스러운 결과와 함께 침투 테스트 및 취약점 평가를 완료해야 합니다 [14]. 신규 법인 신청자에게는 별도의 지침이 적용됩니다. 독립적인 제3자는 애플리케이션 및 네트워크 계층 전반에서 지정된 인프라와 애플리케이션을 다루어야 합니다. 제한적 운영 이전에, 경영진은 중간에서 높은 위험도 결과에 대한 모든 주요 및 중대한 시정 조치를 완료해야 합니다.

• 유럽연합: 비례적 프레임워크; 식별에 조건부인 TLPT. DORA는 암호화폐 자산 서비스 제공업체를 포함한 금융 기관을 대상으로 합니다 [15]. 이는 중요하거나 필수적인 기능을 지원하는 시스템에 대해 최소 연 1회 적절한 테스트—구체적으로 침투 테스트가 아님—를 요구합니다. 침투 테스트는 위험과 비례성에 따라 선택되는 방법 중 하나입니다. 위협 주도형 침투 테스트는 관할 당국이 식별한 기관에만 적용되며, 실제 운영 시스템에서 수행되고, 일반적으로 최소 3년마다 요구됩니다; 당국은 위험을 근거로 그 주기를 조정할 수 있습니다. DORA는 또한 테스터 독립성 조건을 부과합니다. 소기업은 테스트 프로그램 요구사항 대상에서 제외됩니다.

• 싱가포르: 구속력 없는 감독 기대치. MAS 기술 위험 관리 가이드라인은 금융 기관이 침투 테스트를 수행해야 하며 인터넷에 접근 가능한 시스템이 최소 연 1회 또는 주요 변경이나 업데이트 후에 테스트되기를 기대한다고 명시합니다 [16]. 이는 구속력 없는 감독 지침이며 독립적인 제3자를 요구하지 않습니다. 구속력이 있는, 은행 대상의 사이버 위생 공지는 침투 테스트를 명시하지 않습니다. 구속력이 있는 결제 또는 디지털 결제 토큰 공지는 이 글의 범위를 벗어납니다.

종합해 보면, 이러한 체제들은 침투 테스트를 요구하거나 기대합니다—브랜드화된 "web3" 범주가 아닙니다. web3 전문가 버전은 대상 범위의 시스템에서 비롯됩니다: 이러한 시스템이 암호화폐 가치를 인가, 서명, 커스터디, 또는 회계 처리하는 경우, 이를 제대로 테스트하려면 1부에서 설명한 것과 같은 서명 및 자금 흐름 유창성이 필요합니다.

결론은 정확합니다: 특정 관할권의 상당한 수의 라이선스 기관들이 이미 요구사항이나 감독 기대치를 마주하고 있습니다—모든 시장에서 동일한 의무는 아닙니다. 이러한 차이는 범위, 주기, 테스터 독립성, 시정, 증거, 그리고 테스트가 라이선싱, 지속적인 컴플라이언스, 또는 규제 기관 촉발 활동을 지원하는지 여부를 결정합니다.

결론: 두 근거가 수렴하다

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

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

• 2부: 블록체인 침투 테스트란 무엇인가? 정의와 범위

• 3부: 기관용 블록체인 침투 테스트를 위한 교전 규칙 및 프로덕션 안전성

• 4부: Web3 공격 표면: 침투 테스트 개요

이 시리즈에서 곧 발행될 예정인 글:

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

BlockSec은 기관이 이 계층을 정확하게 배치하도록 돕습니다: 자산, 자금 흐름, 신뢰 경계, 기존 보증을 매핑하고; 법률 자문가가 적용된다고 말하는 의무를 확인하고; 그런 다음 테스트 목표, 범위, 액세스, 프로덕션 안전장치, 시정 증거, 재테스트 계획을 정의합니다. 귀사의 보증 격차를 파악하려면, 우리의 블록체인 침투 테스트 팀에 문의하세요; 참여 범위와 가격은 요청 시 제공됩니다. 자금이 이동하는 곳에서 시작하세요.

참고 문헌

처음 등장한 순서대로 번호가 지정되었습니다.

1. BlockSec, Crypto Payment Security Playbook.
2. 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).
3. BlockSec, Bybit $1.5B Hack: In-Depth Analysis of the Malicious Safe{Wallet} Upgrade Attack.
4. rekt.news, BtcTurk — Rekt.
5. rekt.news, Leaderboard.
6. SwissBorg, SwissBorg Security Update: Kiln Breach.
7. BlockSec, TrustWallet Incident: A Stolen API Key Turns the Official Update Channel into a Backdoor.
8. Slope, Slope Wallet Sentry Vulnerability: Digital Forensics and Incident Response Report.
9. BlockSec, Our Short Analysis of the Profanity Tool Vulnerability.
10. BlockSec, Coldcard Entropy Failure and Seed Recovery.
11. BlockSec, Phalcon Security.
12. New York State Department of Financial Services, 23 NYCRR Part 500 — Cybersecurity Requirements for Financial Services Companies.
13. Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook, Part I, Section E.
14. Hong Kong Securities and Futures Commission, Circular 24EC65 (18 December 2024, PDF).
15. European Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA), Articles 24–27.
16. Monetary Authority of Singapore, Technology Risk Management Guidelines (January 2021), Sections 2 and 13; Notice FSM-N06: Notice on Cyber Hygiene (2024).