마키나 파이낸스는 플래시론 및 오라클 조작 공격으로 약 1,299 ETH, 즉 약 413만 달러의 손실을 입었습니다.
공격자는 프로토콜의 자금을 고갈시키고 해당 거래를 이더리움의 공개 멤풀에 전송했으며, 검증자들은 이를 포착하여 다음 블록에 포함시켰어야 했습니다.
대신, 주소 0xa6c2로 식별된 MEV 빌더가 자금 유출 거래를 선점하여 해커가 자금을 오프체인으로 이동시키기 전에 대부분의 자금을 빌더가 관리하는 수탁 기관으로 이체했습니다.
해커의 거래는 실패했습니다. 자금은 MEV 빌더와 관련된 두 개의 주소로 입금되었습니다.
당장 눈에 띄는 점은 마키나 이용자들이 완전한 손실을 면했다는 것입니다. 더 중요한 것은 누가 그 돈을 보유하게 되었는지, 그리고 그것이 암호화폐의 새로운 비상 대응 체계에 어떤 의미를 갖는지입니다.
이 이야기에서 가장 중요한 주체는 공격자나 프로토콜이 아니라, 취약점을 차단하고 이제 사용자들이 자금을 돌려받을 수 있는지 여부, 조건, 그리고 속도를 좌우하는 블록 생성 공급망입니다.
MEV 봇과 빌더는 의도적인 설계가 아닌 구조적 위치 때문에 암호화폐의 최후의 방어선이 되어가고 있습니다. 이는 문제가 되는데, 구제 능력이 불분명한 책임 소재를 가진 채 이익 극대화를 추구하는 중개자들의 손에 집중되어 있기 때문입니다.
MEV를 안전장치로 사용하는 것은 이미 일반적인 패턴입니다.
마키나 사건은 일회성 사건이 아닙니다. 체인애널리시스는 2023년 커브와 바이퍼 해킹 사건 당시에도 유사한 양상을 보였다고 분석하며, 화이트 해커와 MEV 봇 운영자들이 자금 복구를 도왔고, 그 결과 실제 손실액이 초기 예상치보다 줄어들었다고 지적했습니다.
이러한 패턴은 기계적입니다. 공격이나 복구 시도가 공개 거래 채널에 드러나는 한, 정교한 탐색자와 개발자는 거래 순서를 바꾸기 위해 경쟁할 수 있습니다.
때로는 자금을 절약하기도 하고, 때로는 확보하기도 합니다. 어떤 경우든, 그들은 사실상의 비상 대응 체계 역할을 하고 있는 것입니다.
악용 거래가 공개 메모리 풀에 들어가면 MEV 검색기는 수익성 있는 기회를 포착하기 위해 이를 모니터링합니다. 해커가 프로토콜의 메모리를 모두 소진하고 해당 거래를 공개적으로 브로드캐스트하는 경우, 검색기는 먼저 실행되는 경쟁 거래를 구성하여 자금을 다른 주소로 이체할 수 있습니다.
검색자는 거래를 묶어서 블록 생성자에게 제출하고, 블록 생성자는 수익이 경쟁 입찰가를 초과하면 해당 거래를 블록에 포함시킵니다. 블록 생성자가 만든 블록이 검증자에 의해 선택되면 검색자의 거래는 실행되고 해커의 거래는 실패합니다.
이는 순수한 이타주의라기보다는 이로운 부수적 효과를 동반한 이익 추출에 가깝습니다. 하지만 동시에, 프로토콜 수준의 차단 장치나 거버넌스 개입에 의존하는 대신 거래 순서 계층에서 작동하기 때문에 실시간으로 악용 사례를 차단하는 데 있어 암호화폐가 개발한 가장 신뢰할 수 있는 메커니즘이기도 합니다.
전기차 제조업체에 대한 의존이 불편한 이유
MEV 기반 구조의 문제점은 응급 대응 역량이 고도로 중간화된 경로에 집중된다는 것입니다.
이더리움에서는 MEV-Boost가 블록 생성의 대부분을 차지합니다. Rated의 릴레이 지형 분석에 따르면 최근 블록의 약 93.5%가 MEV-Boost를 통해 전송된 반면, 일반 블록 생성 방식을 사용한 경우는 약 6%에 불과합니다.
MEV-Boost 내에서 릴레이 시장 점유율은 더욱 집중되어 있습니다. Ultra Sound Money가 릴레이 트래픽의 약 29.84%를 차지하고 Titan이 약 24.24%를 차지하여, 이 두 대형 릴레이가 전체 블록 생성량의 54% 이상을 처리하고 있습니다.
대부분의 블록이 MEV-Boost를 통해 흐르고 대부분의 MEV-Boost 트래픽이 두 개의 릴레이를 통해 흐른다면, 복구 계층은 구조적으로 소수의 중간자에 의존하게 됩니다. 이는 거버넌스 문제를 빠르게 야기합니다.
만약 건설업자가 구제 자금을 보유하게 된다면, 누가 그 자금의 보관을 승인하는가? 누가 현상금을 정하는가? 갈취나 몸값 요구를 막는 방법은 무엇인가? 건설업자가 해외에 있거나, 신원이 밝혀지지 않았거나, 법 집행이 미약한 관할 지역에서 활동하는 경우는 어떻게 되는가?
마키나 사례는 이러한 문제를 잘 보여줍니다. 자금은 건설업체의 관리하에 있지만, 공개된 서비스 수준 계약(SLA), 사전에 정해진 보상금, 또는 마키나나 그 사용자에게 자금을 반환하는 명확한 메커니즘이 없습니다.
건설업자는 자발적으로 자금을 반환하거나, 보상금을 협상하거나, 업계 표준보다 높은 수수료를 요구하거나, 아예 자금 반환을 거부할 수 있습니다.
프라이빗 라우팅은 문제를 더욱 악화시킵니다.
2025년에 발표된 "샌드위치와 침묵"이라는 제목의 학술 논문은 거래의 광범위한 비공개 라우팅을 기록했으며, 많은 피해자들이 MEV 봇에 의해 샌드위치된 후 비공개 채널로 이동하는 것을 발견했습니다.
하지만 프라이빗 라우팅은 MEV를 완전히 제거하는 것이 아니라, 공용 멤풀에서 빌더와 릴레이가 제어하는 프라이빗 주문 흐름 채널로 MEV를 이동시키는 것일 뿐입니다.
프로토콜 측면에서 이는 익스플로잇 트랜잭션이 점점 더 소수의 빌더만 접근할 수 있는 비공개 채널을 통해 라우팅되기 때문에 공개 멤풀 복구의 신뢰성이 떨어진다는 것을 의미합니다.
혼돈을 문명화하려는 시도
세이프 하버(Safe Harbor)는 SEAL이 개발한 프레임워크로, "MEV 제작자가 우연히 관리자 역할을 하는" 모델을 권한 있는 대응자, 명확한 서비스 수준 계약(SLA), 그리고 제한된 인센티브로 대체하는 것을 목표로 합니다.
SEAL은 세이프 하버(Safe Harbor)를 화이트 해커가 실제 공격 중에 개입할 수 있도록 프로토콜을 통해 사전 승인을 제공하는 법적 및 기술적 프레임워크라고 설명합니다.
핵심 운영 규칙은 구조된 자금을 사전에 정해진 강제력 있는 보상금과 함께 72시간 이내에 공식 복구 주소로 보내야 한다는 것입니다.
SEAL은 세이프 하버(Safe Harbor)가 노마드(Nomad) 해킹 사건에서 영감을 받았다고 밝혔습니다. 당시 화이트 해커들은 도움을 주고 싶어했지만, 자금을 반환하는 행위가 무단 컴퓨터 접근으로 기소될 수 있는지에 대한 법적 모호성 때문에 제약을 받았다는 것입니다.
세이프 하버(Safe Harbor)는 프로토콜이 개입을 사전 승인하고 명확한 조건을 설정할 수 있도록 함으로써 이러한 모호성을 제거합니다. SEAL은 세이프 하버가 유니스왑, 펜들, 팬케이크스왑, 밸런서, zkSync 등 주요 프로토콜에서 이미 160억 달러 이상을 보호하고 있다고 주장합니다.
버그 바운티 플랫폼인 Immunefi는 더욱 엄격한 조건을 적용하여 세이프 하버(Safe Harbor)를 시행하고 있습니다.
Immunefi는 Safe Harbor를 SEAL이 개발한 프레임워크로, 자금을 Immunefi 플랫폼의 프로토콜 제어 금고로 이체한다고 설명합니다. Immunefi의 Safe Harbor 프로그램 페이지에는 "자금을 다시 이체할 수 있는 시간은 6시간입니다."라는 약관이 명시되어 있습니다.
6시간이라는 기한을 지키지 못하는 것은 중대한 규정 위반입니다. 이는 SEAL의 기본 요건인 72시간보다 4배나 빠른 속도입니다.
세이프 하버는 MEV 인프라에 대한 의존성을 완전히 없애는 것이 아니라, 단지 이를 공식화하려는 시도입니다.
만약 개발자가 취약점을 선제적으로 차단하고 프로토콜이 세이프 하버(Safe Harbor) 조항을 채택했다면, 개발자는 해당 개입을 승인된 것으로 간주하고 서비스 수준 계약(SLA) 내에 프로토콜이 지정한 복구 주소로 자금을 이체해야 합니다.
하지만 이는 건설업체가 안전항 등록부를 모니터링하고, 약관을 준수하며, 이익보다 규정 준수를 우선시한다는 전제하에 가능한 이야기입니다.
시나리오 범위
공격 발생 시 예상 사용자 복구율은 다음과 같이 모델링할 수 있습니다. 예상 복구율은 개입 확률에 1에서 현상금 비율을 뺀 값을 곱하고, 다시 1에서 실패 또는 유출 비율을 뺀 값을 곱한 것과 같습니다.
세이프 하버(Safe Harbor)는 법적 모호성을 줄이고 현상금 비율을 사전에 제한함으로써 개입 가능성을 높이는 것을 목표로 합니다.
기본 시나리오에서는 향후 12개월 동안 세이프 하버(Safe Harbor) 채택이 증가합니다. 더 많은 프로토콜이 거버넌스 프레임워크에 세이프 하버 조항을 추가하고 있으며, 더 많은 화이트 해커들이 공인 응답자로 등록하고 있습니다.
대응자들이 법적 명확성과 고정된 보상 조건을 갖게 되면 개입 확률이 높아집니다. 특히 이뮤네피의 6시간 대응 시간처럼 엄격한 서비스 수준 계약(SLA)을 채택한 프로토콜의 경우, 복구율이 향상됩니다.
강세장에서는 구조 계층이 전문화됩니다. 프로토콜은 견고한 금고 주소를 구축하고, SLA를 한 자릿수 시간으로 단축하며, 잘 알려진 화이트 해커 팀과 현상금 지급 일정을 사전 협상합니다.
건설업체는 안전 항구 등록부를 거래 순서 알고리즘에 통합하여 수동 개입 없이 구조된 자금을 지정된 주소로 자동으로 송금합니다.
비관적인 시나리오에서는 빌더 의존도가 심화됩니다. 개인 주문 흐름과 중계 집중으로 인해 구조조정이 불투명해지고 과점화 현상이 심화됩니다. 세이프 하버(Safe Harbor)를 채택하지 않은 프로토콜은 명확한 협상력이나 서비스 수준 계약(SLA) 없이 사후에 빌더와 협상하게 됩니다.
지배구조는 자금을 보유하고 일방적으로 조건을 설정하는 중개자에 의존하게 됩니다.
| 정권 | 누가 개입할 수 있나요? | 자금이 흘러가는 곳 | SLA | 현상금 조건 | 책임 | 고장 모드 |
|---|---|---|---|---|---|---|
| 임시 MEV 구조 (안전지대 없음) | 해당 취약점을 발견하고 명령을 획득할 수 있는 모든 MEV 검색/구축/중계 행위자 | 대개 건설업자/검색자가 관리하는 보관소 (또는 기타 제3자 주소)에 보관됩니다. | 없음 | 협상 중/불명확함 (즉흥적인 "돈 내놔" 식의 협상으로 이어질 수 있음) | 불투명함 (사전 승인 없음, 공식적인 의무 없음) | 몸값 요구/갈취 위험 , 자금 반환 거부, 장기적인 불확실성, 관할권 집행 문제 |
| 안전 항구(SEAL 기준선) | 활성 공격 중 사전 승인된 화이트햇 (프로토콜에 의해 명시적으로 승인된) 사용자 | 프로토콜에서 지정한 복구 주소 (공식 복구 대상) | 72시간 | 사전 정의됨/강제 시행 가능 (프로토콜에 의해 미리 설정됨) | 규칙 기반 (범위 제한 권한 + 사전 설정 조건) | 기한 내에 자금이 반환되지 않을 경우 계약 위반으로 간주되며 , 임의적인 협상보다 명확한 문제 해결 절차가 마련되어 있습니다. |
| 세이프 하버(Immunefi 프로그램) | Immunefi의 안전 항구 절차(SEAL 기반)에 따라 사전 승인된 대응자 | Immunefi의 프로토콜 제어형 금고 (구조화된 보관 흐름) | 6시간 | 사전에 정의된 보상/현상금 구조(프로그램 내 프로젝트에서 설정) | 보다 공식적인 방식 (플랫폼 약관 + 기한 내 준수) | 6시간 이내에 반환되지 않으면 중대한 계약 위반으로 간주됩니다 . 더욱 강화된 SLA는 불확실성을 줄여주지만 실행 압력을 높입니다. |
무엇을 볼까요?
중요한 지표는 도입 속도, 운영 SLA 및 중앙 집중화 압력입니다.
채택 주기란 얼마나 많은 프로토콜이 세이프 하버 거버넌스 제안을 추가하고 SEAL의 채택자 목록에 등록하는지를 추적하는 것을 의미합니다.
운영 SLA는 시장이 대응 시간을 단축하는지 여부를 주시하는 것을 의미합니다. SEAL의 72시간 기준치와 Immunefi의 6시간 프로그램은 더욱 엄격한 SLA가 경쟁 우위 요소가 되고 있음을 보여줍니다.
중앙집중화 압력은 시장 점유율이 여전히 집중되어 있는지 여부를 모니터링하는 것을 의미합니다.
MEV 봇은 암호화폐 생태계가 원하든 원하지 않든 간에 암호화폐의 비상 대응 체계로 자리 잡고 있습니다. 세이프 하버는 이러한 MEV 봇을 예측 가능하고 책임감 있는 시스템으로 전환하려는 시도입니다.
하지만 이는 건설업체가 사전 승인된 조건을 준수하고, 관련 규정이 프레임워크를 충분히 빠르게 채택하며, 블록 건설 파이프라인의 집중화가 구제 금융의 공정성이나 접근성을 저해하지 않을 것이라는 가정에 기반한 것이기도 합니다.
마키나 사례는 그러한 가정이 성립하지 않을 때 어떤 일이 발생하는지 보여줍니다. 자금이 건설업체의 관리 하에 묶여 사용자에게 다시 돌아갈 명확한 경로가 없는 것입니다.
