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

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

기관의 위험 노출은 컨트랙트 버그를 넘어 서명, 커스터디, 키, 인력, 공급망, 인프라까지 확장됩니다 [1]. 따라서 이 표면은 익숙한 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].

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

* Coldcard의 ~$90M은 검증된 온체인 하한값(약 1,405 BTC)입니다. 비공개 추정치는 최대 ~$130M에 달합니다.

이러한 사건들을 침투 테스트와 연결짓는 것은 단순히 이들이 컨트랙트 범위 밖에 있다는 사실이 아니라, 이들이 악용될 수 있는지 여부가 종종 배포된 구성요소들—신원, 종속성, 서명 통제, 승인, 자금 로직—이 공격자가 진입점에서 자금까지 끝에서 끝까지 걸어갈 수 있는 경로로 정렬되는 방식에 좌우된다는 점입니다.

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).