DeFi 보안 가이드: AI 시대에 해커 공격을 효과적으로 방어하는 방법은?
작성: sysls
번역: AididiaoJP, Foresight News
서론
수많은 DeFi 프로토콜 해킹 사건을 분석하면서 나는 ‘국가 행위자(nation-state actor)’에 대한 공포를 느꼈다. 그들은 기술적으로 정교하고 자원이 풍부하며 극도로 장기적인 게임을 한다. 이러한 초강력 악당들은 당신의 프로토콜과 인프라 전반의 사소한 구석구석까지 철저히 검토하며 취약점을 찾아내는 데 집중하는 반면, 일반적인 프로토콜 팀은 여섯 개에서 일곱 개에 이르는 다양한 업무 방향에 주의가 분산되어 있다.
나는 보안 전문가라고 자처하지 않지만, 고위험 환경(군대 및 대규모 자금이 오가는 금융 분야 등)에서 팀을 이끈 경험이 있으며, 위기 대응 계획 수립 및 사고 대응 전략 수립 측면에서 풍부한 실무 경험을 보유하고 있다.
나는 진심으로 믿는다. 생존할 수 있는 자는 편집증적인 자뿐이라는 것을. 아무 팀도 처음부터 ‘보안에 무성의하고 형식만 갖추려 한다’고 생각하지는 않는다. 그러나 그럼에도 불구하고 해킹은 계속 발생한다. 우리는 더 나아져야 한다.
AI는 이번엔 정말 다르다
（출처: https://defillama.com/hacks）
해킹은 드문 일이 아니지만, 그 빈도는 명백히 증가하고 있다. 2026년 1분기는 지금까지 기록된 바에 따르면 DeFi 해킹 건수가 가장 많았던 분기이며, 2분기는 막 시작되었음에도 불구하고 이미 지난 분기 기록을 갈아치울 가능성이 높다.
내 핵심 가정은 다음과 같다: AI는 취약점 탐지 비용을 크게 낮추었으며, 공격 면적(attack surface)을 극단적으로 확장시켰다. 인간은 100개의 프로토콜 설정을 검토해 오류를 찾는 데 몇 주가 걸리지만, 최신 베이스 모델은 단 몇 시간 만에 이를 완료할 수 있다.
이는 우리가 해킹을 생각하고 대응하는 방식을 근본적으로 바꿔야 함을 의미한다. AI가 강력해지기 이전의 보안 관행에 익숙해진 기존 프로토콜들은 점차 ‘순식간에 제거되는(rapidly one-shot)’ 위험에 노출되고 있다.
표면과 계층으로 사고하기
（출처: https://defillama.com/hacks）
해킹 공격의 표면적(surface area)은 사실상 다음 세 가지로 요약된다: 프로토콜 팀, 스마트 컨트랙트 및 인프라, 사용자 신뢰 경계(DSN, 소셜미디어 등).
이러한 표면을 식별한 후에는 각각에 대해 방어 계층을 중첩시켜야 한다:
- 예방(prevention): 엄격히 실행될 경우 공격 가능성 자체를 최대한 낮출 수 있는 절차.
- 완화(mitigation): 예방이 실패했을 때 피해 규모를 제한하는 조치.
- 일시 중단(pause): 극도의 압박 상황에서는 누구도 최선의 결정을 내릴 수 없다. 공격이 확인되면 즉시 ‘총괄 중단 킬 스위치(kill switch)’를 작동시켜야 한다. 동결은 추가 손실을 차단하고, 사고 분석 및 대응 계획 수립을 위한 사고 공간을 확보한다…
- 탈환(reclaim): 유독성 또는 침해된 구성요소에 대한 통제력을 상실했을 경우, 해당 요소를 과감히 폐기하고 교체해야 한다.
- 복구(recovery): 잃어버린 자산 및 기능을 되찾는 단계. 자금 동결, 거래 취소, 조사 협조 등을 지원해 줄 기관 파트너와의 사전 협약 및 연락망을 미리 구축해 두어야 한다.
원칙
이 원칙들은 각 방어 계층을 구체적으로 실행하는 데 지침을 제공한다.
선두 AI 기술의 적극적 활용
최신형 AI 기반 모델을 적극적으로 활용하여 코드베이스 및 설정 파일을 스캔하고, 광범위한 표면 전체에 걸쳐 레드팀 테스트를 수행하라: 프론트엔드에서 취약점을 찾아 그것이 백엔드로 전파될 수 있는지를 확인하라. 공격자들이 그렇게 할 것이다. 당신이 방어적 스캔을 통해 발견할 수 있는 모든 취약점은, 공격자의 공격적 스캔에 의해 이미 먼저 발견되었을 가능성이 매우 높다.
pashov, nemesis 등의 도구 및 Cantina(Apex), Zellic(V12) 같은 AI 기반 플랫폼을 활용해, 정식 감사를 진행하기 전에 코드베이스를 신속하게 스캔하라.
시간과 마찰은 좋은 방어 수단이다
잠재적 피해를 유발할 수 있는 모든 작업에 대해 다단계 절차 및 타임록(time lock)을 도입하라. 이상 징후가 포착되었을 때 개입하고 동결 조치를 취할 수 있도록 충분한 시간을 확보해야 한다.
과거에는 타임록 및 다단계 절차 도입을 반대하는 이유가 프로토콜 팀에게 불필요한 마찰을 유발한다는 것이었다. 그러나 이제는 이를 우려할 필요가 없다. AI는 이러한 마찰을 백그라운드에서 자동으로 처리할 수 있기 때문이다.
불변량(Invariant)
스마트 컨트랙트는 변경되지 않는 ‘사실(fact)’을 코드에 명시함으로써 방어적으로 설계될 수 있다: 이러한 사실이 위반될 경우, 전체 프로토콜 로직이 즉시 중단된다.
보통 불변량은 소수에 불과하다. 이를 코드 수준으로 승격시키는 것은 신중해야 하며, 모든 함수에서 여러 불변량을 강제 적용하면 관리가 매우 어려워질 수 있다.
권한 분산(Balance of Power)
많은 해킹은 침해된 월렛에서 비롯된다. 따라서 다중 서명 지갑이 침해되더라도 피해를 신속히 억제하고, 프로토콜을 거버넌스가 의사결정 가능한 상태로 복귀시킬 수 있는 구성이 필요하다.
이는 ‘거버넌스(모든 사항을 결정함)’와 ‘구조(거버넌스 자체를 대체하거나 무효화하지는 않되, 거버넌스가 재개될 수 있는 안정성을 회복하는 능력)’ 사이의 균형을 요구한다.
언제든 문제가 생길 수 있다
처음부터 이렇게 가정하라: 당신이 얼마나 똑똑하든, 반드시 해킹당할 것이다. 당신의 스마트 컨트랙트나 의존성(dependency)이 실패할 수 있다. 사회공학 공격을 당할 수도 있고, 새로운 업그레이드가 예상치 못한 취약점을 도입할 수도 있다.
이렇게 사고할 때, 피해 규모를 제한하는 ‘속도 제한(rate limiting)’ 및 프로토콜을 일시 중단시키는 ‘서킷 브레이커(circuit breaker)’가 당신의 최고의 동반자가 된다. 피해를 5–10%로 제한한 후 동결하고, 이후 대응 계획을 수립하라. 누군가가 총알이 날아다니는 상황에서 최선의 결정을 내릴 수는 없다.
가장 최적의 계획 시점은 바로 지금이다
해킹이 발생하기 전에 이미 대응 계획을 수립하라. 가능한 한 많은 절차를 코드로 자동화하고, 팀원들과 함께 실제 시뮬레이션 훈련을 반복하라. 그래야 충격이 닥쳤을 때 패닉에 빠지지 않는다. AI 시대에는, 대량의 정보를 가능한 한 빠르게 수집·정리하여 핵심 관계자들에게 요약본과 장문 보고서 형태로 공유할 수 있는 기술 및 알고리즘을 갖추는 것을 의미한다.
완벽할 필요는 없다. 다만 살아남아야 한다. 어떤 시스템도 첫날부터 완전히 불침불패하지는 않으며, 반복적인 개선과 교훈을 통해 ‘반취약성(antifragility)’을 획득하게 된다.
‘해킹당하지 않았다’는 증거는, ‘해킹당하지 않을 것’이라는 보장이 아니다. 최대 편안함이 오히려 최대 위험의 지점일 수 있다.
예방 조치
스마트 컨트랙트 설계
불변량을 식별한 후, 이를 실행 시점(runtime) 검사로 승격시켜야 한다. 실제로 강제 실행할 가치가 있는 불변량을 신중히 선별해야 한다.
이것이 바로 FREI-PI(Function Requirements, Effects, Interactions, Protocol Invariants) 패턴이다: 가치 이동과 관련된 모든 함수 종료 시점에서, 해당 함수가 유지해야 할 ‘왕관 불변량(crown invariant)’을 다시 검증한다. CEI(Checks-Effects-Interactions) 패턴을 통과했음에도 성공한 대부분의 ‘배럴 드레인 공격(barrel drain attack)’—예: 플래시론 삼명치(Flash loan sandwich), 오라클 기반 청산 악용(griefing), 크로스-펑션 상환 능력 배럴 드레인(cross-function solvency drain)—은 함수 종료 시점의 불변량 검사로 포착될 수 있다.
충실한 테스트
상태 기반 퍼징(Stateful fuzzing)은 프로토콜의 전체 공개 인터페이스에 대해 무작위 호출 시퀀스를 생성하고, 각 단계에서 불변량을 검증한다. 대부분의 실서비스 환경에서 발견되는 취약점은 여러 트랜잭션에 걸친 복합적 경로를 통해 발생하는데, 상태 기반 퍼징은 공격자가 이를 발견하기 전에 사전에 식별할 수 있는 거의 유일하게 신뢰할 수 있는 방법이다.
불변량 테스트를 사용해 퍼저가 생성할 수 있는 모든 호출 시퀀스에 대해 특정 속성이 항상 성립함을 검증하라. 이를 형식적 검증(formal verification)과 병행하면, 모든 도달 가능한 상태에서 해당 속성이 성립함을 수학적으로 증명할 수 있다. 당신의 ‘왕관 불변량’은 반드시 이 수준의 검증을 받아야 한다.
오라클 및 외부 의존성
복잡성은 보안의 적이다. 모든 외부 의존성은 공격 면적을 확장시킨다. 원시(primitive)를 설계할 때는 ‘누구를 신뢰할 것인지’, ‘무엇을 신뢰할 것인지’에 대한 선택권을 사용자에게 직접 부여해야 한다. 의존성을 제거할 수 없다면, 이를 다각화하여 단일 장애 지점(single point of failure)이 프로토콜 전체를 붕괴시키지 않도록 해야 한다.
오라클 및 외부 의존성의 실패 시나리오를 모의 감사 범위에 포함시키고, 실패 시 초래될 재앙적 영향을 제한하기 위해 속도 제한(rate limiting)을 적용하라.
최근 KelpDAO 취약점이 바로 그런 사례다: 그들은 LayerZero의 기본 설정 requiredDVNCount=1을 그대로 상속받았는데, 이 설정은 감사 범위 밖에 있었다. 결국 공격 대상이 된 것은 감사 범위 밖의 오프체인 인프라였다.
표면 공격(Surface Attack)
DeFi에서 발생 가능한 대부분의 표면 공격 유형은 이미 잘 알려져 있다. 각 유형을 하나씩 점검해 보고, 그것이 당신의 프로토콜에 적용 가능한지 판단한 후, 해당 공격 벡터에 특화된 통제 수단을 도입하라. 팀 내 레드팀 역량을 육성하고, AI 에이전트를 활용해 프로토콜 내부에서 능동적으로 취약점을 탐색하도록 해야 한다. 이는 현재 시점에서 기본적인 요구사항이다.
내재적 구조 역량 확보
투표 기반 거버넌스에서는 권한이 초기에 팀의 다중 서명 지갑에 집중되어 있으며, 시간이 지나야 분산된다. 토큰이 광범위하게 분포되어 있더라도, 위임은 종종 소수의 월렛(때로는 n=1)에 권한을 집중시킨다. 이러한 월렛이 침해되면 게임은 끝난다.
‘가디언 월렛(Guardian Wallet)’을 배포하라. 이 월렛은 매우 좁은 권한만 부여받으며, >=4/7의 임계치에서만 프로토콜을 일시 중단할 수 있고, 극단적인 상황에서는 손상된 위임자를 사전에 정의된 대체 월렛으로 교체할 수 있다. 그러나 가디언은 절대 거버넌스 제안을 실행할 수 없다.
이렇게 하면, 거버넌스를 전복시키지 않으면서도 언제든지 거버넌스 가능성을 회복할 수 있는 구조 계층을 확보하게 된다. >=4/7의 가디언을 동시에 잃을 최악의 사태는 (보유자 다양성 고려 시) 극도로 낮은 확률이며, 거버넌스가 성숙하고 분산되면 이 계층은 점진적으로 퇴출될 수 있다.
월렛 및 키 토폴로지
다중 서명 지갑은 필수 조건이며, 최소 구성은 4/7이다. 단일 개인이 7개의 키를 모두 통제해서는 안 된다. 서명자들을 주기적으로 교체하되, 외부에 노출되지 않도록 조용히 수행해야 한다.
키는 절대 일상용 기기와 상호작용해서는 안 된다. 서명용 기기로 인터넷을 탐색하거나 이메일을 수신·발송하거나 Slack을 열면, 해당 서명자는 이미 침해되었다고 간주해야 한다.
목적별로 여러 개의 별도 다중 서명 지갑을 운영하라. 적어도 하나의 완전한 다중 서명 지갑은 침해될 것이라고 전제하고, 이를 바탕으로 계획을 수립하라. 어떤 상황(납치, 고문 등 극단적 상황 포함)에서도 단일 개인이 프로토콜 전체를 침해할 수 있는 충분한 통제 권한을 가져서는 안 된다.
버그 바운티 고려
자원이 충분하다면, 프로토콜의 TVL에 비례한 고액 버그 바운티를 설정하는 것이 매우 가치 있다. 비교적 작은 규모의 프로토콜이라도, 버그 바운티는 가능한 한 관대하게 설정해야 한다(예: 최소 7~8자리 금액).
국가 행위자 공격을 받고 있다면, 그들과 협상은 어려울 수 있지만, ‘화이트햇 안전 항구(white hat safe harbor)’ 프로그램에 참여해 화이트햇이 자금 보호를 위해 당신을 대신해 행동하도록 허가하고, 발견된 버그에 대한 보상의 일부를 수수료로 지급받을 수 있다(실제로는 예치자들이 부담하는 보상금).
우수한 감사 전문가 확보
나는 이전에 대규모 언어 모델(LLM)이 더욱 정교해짐에 따라 감사 전문가를 고용하는 한계 효용이 감소할 것이라고 썼다. 나는 여전히 이 입장을 견지하지만, 관점이 다소 변화했다.
첫째, 우수한 감사 전문가는 시장의 흐름보다 앞서 나간다. 당신이 새로 개발하는 기능이나 코드, 그리고 그에 따른 취약점이 아직 훈련 데이터에 포함되지 않았을 가능성이 높다. 단순히 토큰 수를 늘리는 것으로는 신규 유형의 취약점을 효과적으로 발견할 수 없음이 입증되지 않았다. 당신은 독특한 취약점의 첫 번째 사례가 되고 싶지 않을 것이다.
둘째, 간과되기 쉬운 이점은, 감사 전문가를 고용함으로써 그들의 평판을 담보로 삼는다는 점이다. 만약 그들이 서명을 통해 승인했는데도 해킹이 발생한다면, 그들은 당신을 도울 강한 동기를 갖게 된다. 보안 분야의 전문가들과 관계를 구축하는 것은 매우 큰 이점이다.
운영 보안(OPSEC) 실천
운영 보안을 성공 지표로 삼아야 한다. 피싱 훈련을 정기적으로 실시하고, (신뢰할 수 있는) 레드팀을 고용해 팀원을 대상으로 사회공학 공격을 시도해 보라. 긴급 상황 시 즉시 전체 다중 서명을 교체할 수 있도록 예비 하드웨어 월렛 및 장비를 준비해 두어야 한다. D-Day에 급하게 구매하려고 하지 말라.
완화 조치
탈출 경로 = 손실 상한선
프로토콜 외부로 가치를 이동시키는 모든 경로에 대해 설정된 상한 크기는, 해당 경로가 취약점으로 악용되었을 때 발생 가능한 최대 이론적 손실을 의미한다. 쉽게 말해, 블록당 상한이 없는 민팅 함수는 무한 민팅 취약점에 대해 ‘빈 수표(blank check)’를 발행하는 것이며, 주간 상한이 없는 환매 함수는 자산 잔고 손상에 대해 ‘빈 수표’를 발행하는 것이다.
당신의 탈출 경로에 대한 명확한 수치를 신중히 고민하라. 이 수치는 당신이 감수할 수 있는 최대 피해와 사용자의 극단적인 UX 요구 사이에서 균형을 맞춰야 한다. 문제가 발생했을 때, 이것이 당신을 완전한 파멸로부터 구해줄 유일한 수단이다.
화이트리스트(및 블랙리스트)
대부분의 프로토콜은 호출·거래·수신이 허용되는 목록과 사용자가 절대 해서는 안 되는 목록을 갖는다. 명시적이지 않더라도, 이러한 목록은 사실상 신뢰 경계이며, 반드시 공식화되어야 한다.
이를 공식화함으로써 ‘2단계 설정자(two-stage setter)’를 도입해 의미 있는 마찰을 만들 수 있다. 공격자는 먼저 화이트리스트에 등록(또는 블랙리스트에서 제외)되어야 하고, 그 후에야 행동할 수 있다. 양쪽 모두를 갖춘다는 것은, 공격자가 새 공격 벡터를 은밀히 도입할 때 시장 통합/상장 승인과 보안 심사 통과라는 두 가지 프로세스를 동시에 우회해야 한다는 것을 의미한다.
탈환
알고리즘 기반 모니터링
누가 모니터링하지 않으면, 킬 스위치는 무의미하다. 오프체인 모니터링 시스템은 불변량을 지속적으로 감시하고, 문제가 발생하면 즉시 자동으로 경고 수준을 상향 조정해야 한다. 최종 경로는 인간 가디언 다중 서명으로 연결되어야 하며, 분석 및 결정을 몇 분 이내에 내릴 수 있도록 충분한 맥락 정보를 제공해야 한다.
일시 정지 후 재교정
당신이 총에 맞았다면, 먼저 피를 멈춰야지, 카운트다운 속에서 결정을 내려서는 안 된다. 프로토콜 입장에서는 바로 이 킬 스위치(UI에도 반드시 반영)다: 한 번의 트랜잭션으로 모든 가치 이동 경로를 일시 중단시킬 수 있는 버튼. ‘모든 기능 중단’ 보조 스크립트를 준비해 두고, 모든 일시 중단 가능한 구성요소를 열거하고 원자적으로 중단할 수 있도록 해야 한다.
중단 해제는 오직 거버넌스에 의해서만 가능해야 하므로, 킬 스위치는 거버넌스 컨트랙트 자체를 중단시켜서는 안 된다. 만약 가디언 계층이 거버넌스 컨트랙트를 중단시킬 수 있다면, 침해된 가디언 계층이 복구 프로세스를 영구적으로 봉쇄할 수 있다.
전쟁 상황실(War Room) 가동
동결, 응급 처치 후, 당신이 신뢰하는 모든 사람(미리 합의된 소규모 핵심 인원)을 하나의 커뮤니케이션 채널로 모아라. 정보 유출을 막기 위해 표면을 작게 유지해야 한다 — 공격자, 일반 대중, 악의적 아비트리지어에게 정보가 유출되지 않도록 해야 한다.
팀 구성원의 역할을 사전에 정의하고 시뮬레이션 훈련을 실시하라: 의사결정자, 방어 스크립트 및 중단 명령 실행 전문가, 취약점 재구성 및 근본 원인 분석 전문가, 핵심 이해관계자와의 소통 담당자, 관측 사항·사건·의사결정 시점 기록 담당자 등.
모든 구성원이 자신의 역할을 알고 훈련을 마쳤을 때, 최악의 순간에도 패닉 없이 절차에 따라 신속히 대응할 수 있다.
연쇄 반응 고려
당신의 공격자가 매우 숙련되었다고 가정하라. 첫 번째 취약점은 단순한 유인물(bait)일 수도 있고, 후속 공격을 위한 씨앗일 수도 있다. 공격은 당신으로 하여금 완전히 잘못된 결정을 내리게 유도하여, 진짜 취약점을 발동시키려는 목적일 수 있다.
중단 조치는 반드시 충분히 연구된 결과에 기반해 완전히 통제 가능해야 하며, 중단 조치 자체가 공격 벡터가 되어서는 안 된다. 중단은 프로토콜 전체 동결이어야 한다: 특정 구성요소만 중단하라는 유도에 넘어가, 다른 구성요소가 열리게 되는 상황을 피해야 한다. 근본 원인과 공격 벡터를 식별한 후, 인접한 노출 면적 및 연쇄 반응을 탐색하고, 이를 한 번에 모두 해결해야 한다.
사전 약정된 후계자 교체
후계자를 사전에 알고 있어야만 교체는 안전하다. 나는 ‘사전 약정된 후계자 등록부(pre-committed successor registry)’ 개념을 좋아한다: 이는 건강한 가디언/거버넌스 월렛이 침해된 월렛으로 교체되는 것을 공격자에게 더 어렵게 만든다. 이는 ‘화이트리스트/블랙리스트’ 개념과 일맥상통한다.
중요한 모든 역할에 대해 후계자 주소를 등록하라. 응급 계층이 실행할 수 있는 유일한 교체 원시(primitive)는 ‘역할 X를 그 후계자로 교체’라는 동작이다. 또한 평시에 후계자를 평가할 수 있게 된다: 천천히 진행하고, 디퓨 듀 데일리(due diligence)를 수행하며, 요청자와 직접 만나는 것도 가능하다.
업그레이드 전 신중한 테스트
근본 원인과 영향 범위를 식별한 후, 업그레이드를 배포해야 한다. 이것은 당신이 배포할 가장 위험한 코드일 수 있다: 압박 상황에서 작성되었고, 이미 당신의 프로토콜을 충분히 이해하고 취약점을 찾아낸 공격자를 상대로 배포되는 것이다.
충분한 테스트 없이는 배포를 지연시켜야 한다. 감사 시간이 없다면, 화이트햇 관계를 활용하거나, 배포 전 48시간의 경쟁 기간을 설정해 신선한 대응적 검토(adversarial review)를 확보하라.
복구
신속한 조치
도난된 자금은 반감기(half-life)가 있다. 취약점이 공개된 후, 자금은 빠르게 자금세탁 파이프라인으로 유입된다. Chainalysis 등 체인상 분석 서비스 제공업체와 사전 협약을 맺어, 공격자 주소 클러스터를 실시간으로 식별하고, 크로스체인 이동 시 거래소에 알리고 추적하도록 해야 한다.
중앙화 거래소의 컴플라이언스 부서, 크로스체인 브리지 관리자, 커스터디안 관리자 및 크로스체인 메시지 또는 특정 진행 중인 입금을 동결할 수 있는 관리 권한을 보유한 기타 제3자 명단을 미리 준비해 두어야 한다.
협상
네, 매우 불쾌하지만, 여전히 공격자와의 대화를 시도해야 한다. 현실 세계의 많은 문제는 협상을 통해 해결된다. 기한이 정해진 화이트햇 보상금을 제안하고, 마감일 전에 자금을 전액 반환할 경우 법적 조치를 취하지 않겠다고 공개 선언하라.
국가 행위자와 대峙한다면 성공 확률은 낮겠지만, 덜 숙련된 공격자일 가능성도 있다. 그들은 단지 당신의 프로토콜을 이용하는 방법을 우연히 발견했을 뿐이며, 저비용으로 사태를 종결하려는 의도일 수 있다.
이러한 조치를 취하기 전에는 반드시 법률 자문을 받도록 하라.
결론
해킹은 멈추지 않을 것이며, AI가 더욱 정교해질수록 공격은 더욱 증가할 것이다. 단순히 방어자들이 ‘더 날카롭게’ 되는 것만으로는 부족하다. 우리는 공격자가 사용하는 동일한 도구를 사용해 우리 프로토콜을 레드팀 테스트하고, 지속적인 모니터링을 실시하며, 피해에 대해 단단한 상한을 설정해야 한다. 그래야 최악의 상황에서도 생존할 수 있다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@systematicls
