1초도 채 안 되는 시간에 DeFi 취약점을 탐지하는 방법

Quicknode

2026년 4월 21일 — 읽는 데 7분 소요

공유하기

선호하는 소스로 추가

Decurity의 CTO 겸 공동 창업자 아르세니 레우토프 Quicknode 블로그에 게재됨

저는 10년 넘게 공격 탐지 시스템을 구축해 왔습니다. 처음에는 Web2 분야에서 트래픽 분석과 WAF(웹 애플리케이션 방화벽) 작업을 했고, 이후 Web3 분야로 넘어와서는 동일한 공격 문제가 더 빠른 속도로 전개되고 더 많은 자금이 걸린 상황에서 이를 다루었습니다. 2022년에는 Decurity를 공동 창업했습니다. 저희는 DeFi 프로토콜을 감사하고, 실제 운영 환경에서 이를 모니터링할 수 있는 도구를 개발합니다. Defimon은 모니터링을 담당하는 솔루션으로, DeFi가 실제로 운영되는 다양한 체인에 걸쳐 프로토콜 팀, 보안 기업, 리스크 관리자들이 신뢰하는 실시간 익스플로잇 탐지 시스템입니다. 해킹 사건이 뉴스에 보도되기 전에 경고를 발령합니다. 그렇지 못한다면 제 역할을 다하지 못한 것입니다. 그토록 많은 체인에 걸쳐 그 속도로 작동하는 시스템을 구축하는 일은 보안 문제라기보다 인프라 측면에서 훨씬 더 어려운 과제임이 밝혀졌습니다. 이것이 바로 이 시스템을 구축하며 우리가 얻은 교훈입니다.

탐지 속도가 보안의 기본 요소인 이유

DeFi에서는 단 한 번의 원자적 트랜잭션으로 프로토콜의 자금이 모두 유출될 수 있습니다. 하지만 공격의 첫 징후가 포착된 시점부터 프로토콜의 자금이 완전히 유출되기까지는 종종 일정한 시간이 흐르는 경우가 많습니다. 발란서(Balancer) 사건이나 Yearn 해킹 사건이 대표적입니다. 두 사례 모두 누군가가 상황을 지켜보고 있었는지가 문제가 아니었습니다. 핵심은 이러한 초기 징후를 감지하고 제때 대응했는지 여부였습니다.

자동화된 사고 대응이 제대로 작동하려면, 조치를 취할 수 있을 만큼 제때에 경보가 도착해야 합니다. 즉, 계약 중지, 다중 서명(multisig) 보유자에게 알림 전송, 자금 이동 등의 조치를 취할 수 있어야 합니다. 블록 처리에서 2초의 지연은 별것 아닌 것처럼 들릴 수 있습니다. 하지만 프로토콜 수준에서는 이것이 단순한 경고와 사후 분석의 차이를 만들게 됩니다.

탐지 속도는 단순한 기능이 아닙니다. 그 자체가 바로 제품입니다.

여론조사의 문제점

Defimon 개발을 시작했을 때, 우리는 표준 방식대로 온체인 데이터를 가져왔습니다. 즉, RPC를 통해 폴링을 수행하며 블록체인에 새로운 블록, 트랜잭션, 로그, 트레이스를 반복적으로 요청하는 방식이었습니다.

잘 되다가 어느 순간 안 되더니.

수백만 개의 지갑 주소와 스마트 계약 상호작용을 모니터링해야 하는 상황에서, 폴링 방식은 우리가 기술적으로 해결할 수 없는 두 가지 문제를 야기했습니다.

지연 시간. 각 폴링 주기마다 약 2초의 블록 지연 시간이 발생했습니다. 감지 타이밍에 따라 프로토콜 equipe 에 대한 경고가 제때 전달되는지 여부가 결정되는 제품의 경우, 2초라는 지연 시간은 단순한 성능 튜닝 문제가 아니라 구조적인 문제입니다.

확장성. 모니터링 대상 주소 목록은 계속해서 늘어났습니다. 우리는 메모리에 동적 주소 목록을 저장한 채, 블록체인 데이터를 AWS에서 실행 중인 Apache Flink SQL 파이프라인으로 전송했습니다. 모니터링 범위가 확대됨에 따라 메모리 부족 오류가 빈번하게 발생했습니다. 시스템은 모니터링해야 할 대상의 규모에 맞춰 확장되지 못했습니다. 게다가 SQL 파이프라인을 변경할 때마다 Apache Flink를 완전히 재시작해야 했으며, 이로 인해 매번 최대 20분 동안 서비스가 중단되었습니다.

상황이 가장 나빴을 때는 세 개의 체인을 운영하기 위해 매달 AWS에 4,000달러를 지출했고, 3~4명의 엔지니어가 파이프라인을 유지 관리하고 있었습니다. 우리 equipe 의 전문 분야는 탐지 로직인데, 우리는 그 자원을 인프라에 쏟아붓고 있었던 셈입니다.

우리가 ‘Push Data’로 전환한 이유

가장 큰 변화는 폴링 방식을 Quicknode Streams 을 활용한 푸시 모델로 대체한 것이었습니다.

블록체인에 데이터를 요청하는 대신, 블록이 온체인에 등록되는 순간 데이터가 도착합니다. 블록 지연 시간은 약 2초에서 0.5초 미만으로 단축되었습니다. 이제 텔레그램 알림은 감지 후 1초도 채 되지 않아 발송됩니다. 이는 단순한 점진적 개선이 아닙니다. 완전히 다른 차원의 제품입니다.

하지만 지연 시간은 문제의 일부에 불과했다. 더 큰 성과는 업스트림 필터링이었다.

기존의 Apache Flink 파이프라인은 SQL 기반으로 구동되었습니다. 탐지 로직은 수많은 하위 쿼리로 구성된 하나의 거대한 쿼리 형태로 구현되어 있었는데, 초기에는 선언적인 방식으로 작성하기 쉬웠지만 규모가 커질수록 유지보수가 매우 번거로워졌습니다. Streams 로 마이그레이션하면서 탐지 로직도 SQL에서 JavaScript로 전환했고, 필터는 블록체인 노드 내에서 직접 실행되도록 했습니다. 이러한 변화를 통해 다음과 같은 세 가지 이점을 얻었습니다:

유연성. 탐지 로직에 어떤 변경 사항이 발생하더라도 다운타임 없이 즉시 적용됩니다. 당사는 과거 DeFi 사고 사례를 바탕으로 구축된 포괄적인 테스트 스위트를 통해, 수정 과정 전반에 걸쳐 로직이 온전하게 유지되는지 검증합니다. Quicknode 의 JS 필터 테스트 도구를 활용하면 배포 전에 전체 테스트 스위트를 실행할 수 있습니다.

경제성. 더 이상 모든 블록체인 데이터를 처리하지 않습니다. ‘ Streams ’가 노드 수준에서 필터링을 처리하여 필요한 데이터만 전달합니다. 대역폭 사용량이 크게 줄었습니다.

속도. 새로운 블록이 나타나자마자 데이터가 전송됩니다. 폴링 간격이 없으며, 왕복 지연 시간도 없습니다.

탐지 아키텍처

현재 저희 파이프라인은 다음과 같습니다.

우리가 모니터링하는 8개의 체인 중 하나에 블록이 온체인됩니다. Streams 은 자바스크립트를 사용하여 노드 수준에서 해당 블록을 필터링하고, 관련 데이터만 다운스트림으로 전달합니다. Quicknode Streams 에 내장된 키-값 저장소(Key-Value Store)에는 우리의 감시 목록, 즉 자바스크립트 필터가 직접 참조할 수 있는 수백만 개의 추적 주소가 저장되어 있습니다. 업스트림 서비스에서는 필터링된 데이터를 대상으로 악용 탐지 로직이 실행됩니다. 패턴이 일치하면 경보가 발령됩니다.

전체 과정이 1초도 채 걸리지 않습니다.

구체적인 예로, Streams 를 통해 트랜잭션 추적을 분석하면, 초기화되지 않은 프록시 스마트 계약에 백도어를 심으려는 시도를 탐지할 수 있습니다. 우리가 CPIMP(Clandestine Proxy In the Middle of Proxy)라고 부르는 이 공격 패턴은, 프록시가 배포되었으나 동일한 트랜잭션 내에서 원자적으로 초기화되지 않았을 때 발생합니다. 이러한 간극을 악용해 악의적인 행위자가 프록시를 장악하고 악성 구현 계약을 설정할 수 있습니다. 이를 탐지하려면 트레이스 데이터를 조기에 신속하게 파악해야 합니다. Streams 를 사용하면 이것이 가능합니다.

운영팀 없이 8개의 체인으로 확장하기 equipe

저희는 Defimon을 3개의 체인에서 시작했습니다. 현재는 8개의 체인을 모니터링하고 있습니다: Ethereum, BNB Smart Chain, Arbitrum, Base, Polygon, Avalanche, Optimism, 그리고 HyperEVM.

기존 체계에서는 체인을 추가한다는 것은 새로운 인프라, 새로운 서버, 새로운 파이프라인, 그리고 인력 증원을 의미했습니다. 이러한 추가 작업들은 엔지니어링 리소스를 놓고 탐지 작업과 직접적으로 경쟁해야 했습니다.

Streams 를 사용하면 체인을 추가하는 것은 단순히 구성 변경에 불과합니다. HyperEVM 통합에는 하루도 채 걸리지 않았습니다. 몇 가지 상수와 관련 주소를 수정하는 것이 작업의 대부분을 차지했습니다.

현재 전체 파이프라인은 엔지니어 한 명이 운영하고 있습니다. 나머지 직원들은 모두 탐지 로직에 집중하고 있습니다. 예전 방식에서는 인프라를 유지하는 데만 3~4명이 필요했습니다.

경보가 울린 후에는 어떻게 되나요?

Defimon 구독자들은 단순히 취약점 악용 사례를 지켜보기만 하는 것이 아닙니다. 이들은 당사의 알림을 기반으로 자동화된 사고 대응 체계를 구축하고 있습니다. 알림이 빠를수록 대응할 수 있는 시간이 더 많아집니다.

9자리 수의 DeFi 포지션을 운용하는 한 헤지펀드 고객사는 WebSockets를 통해 당사 시스템과 연동하여, 설정된 프로토콜을 겨냥한 공격의 초기 징후가 감지되는 즉시 포지션을 자동으로 청산하고 있습니다. 개인 투자자와 트레이더들은 진행 중인 사고가 확인될 때 당사의 알림을 활용해 포지션을 조정합니다.

하지만 가장 중요한 활용 사례는 적극적인 화이트햇 개입입니다. 저희는 이미 총 200만 달러 이상을 회수한 화이트햇 봇을 운영하고 있습니다. 최근에는 실수로 토큰 할당량을 잘못 설정한 사용자를 위해 51만 2천 달러를 회수해 주기도 했습니다. 악의적인 공격자들이 이를 눈치채기 전에 저희가 신속하게 대응할 수 있었습니다. 이러한 개입이 가능했던 것은 바로 기반이 되는 파이프라인의 빠른 처리 속도 덕분이었습니다.

마무리

모든 DeFi 프로토콜은 자사의 계약에서 어떤 일이 일어나고 있는지 실시간으로 파악해야 합니다. AI로 인해 공격의 규모와 정교함이 가속화되고 있는 오늘날, 공격의 초기 징후를 포착하는 것은 선택 사항이 아닙니다. 이는 필수 요건입니다.

데피몬의 역할은 팀들이 대응할 수 있는 충분한 시간을 확보할 수 있도록 경보를 발령하는 것입니다. 데이터 파이프라인은 이를 가능하게 하기도 하고, 방해가 되기도 합니다.

equipe 가 여전히 폴링 방식을 사용하고 있다면, 문제는 지연 시간이 문제가 될지 여부가 아니라 언제 문제가 될지입니다. 소스 코드부터 다시 빌드하는 것은 번거로운 일입니다. 하지만 근본적으로 느린 아키텍처에 패치를 적용하는 것은 1초 미만의 탐지 시간을 달성할 수 있는 방법이 아닙니다. 우리에게 있어 푸시 모델로의 전환은 단순히 기술적인 선호의 문제가 아니었습니다. 그것이야말로 제품이 실제로 제대로 작동할 수 있는 유일한 방법이었기 때문입니다.

아르세니 레우토프(Arseniy Reutov)는 1inch, Gearbox, 이더리움 재단( Arbitrum Foundation) 등이 신뢰하는 웹3 보안 기업 데큐리티(Decurity)의 최고기술책임자(CTO)이자 공동 창업자입니다. 데큐리티의 실시간 익스플로잇 탐지 플랫폼인 ‘데피몬(Defimon)’은 8개의 EVM 체인을 모니터링하며 3,500명 이상의 구독자에게 서비스를 제공하고 있습니다.