From the Kelp DAO Incident to Verifiable UI: Why "Verifiable Interfaces" Could Be the New Decentralized Security Baseline?

상위 DeFi 세계에서 또 한 번 억 달러 규모의 보안 사고가 발생했습니다.

4월 18일, 공격자는 Kelp DAO의 LayerZero 라우팅에 있는 1-of-1 DVN 설정과 선택적 검증자(optional verifiers)가 없는 구성을 악용하여 크로스체인 메시지를 위조하고, 계약이 116,500개의 rsETH를 잘못 해제하도록 만들었습니다. 이로 인해 다양한 손실 분담 시나리오에서 Aave가 직면한 잠재적 부실 채권 규모는 약 1억 2,370만 달러에서 2억 3,010만 달러에 이를 것으로 추산됩니다.

객관적으로 볼 때, 이는 2026년 이후 현재까지 가장 큰 규모의 DeFi 보안 사건일 뿐만 아니라, 더 중요하게는 업계 전체가 이전에 묵시적으로 수용해 왔던 아키텍처 가정, 즉 효율성, 유동성 및 수익을 위해 점점 더 많은 보안을 소수의 묵시적으로 신뢰되는 미들웨어 계층에 조용히 맡기는 관행을 무너뜨렸다는 점입니다.

1. Kelp DAO 사건 이면의 탈중앙화 메커니즘 붕괴

Kelp DAO 사건을 단순한 체인상 보안 사고로만 이해한다면, 이것이 전체 DeFi 구조적 위험에 대해 시사하는 바를 과소평가하기 쉽습니다.

Kelp DAO는 이더리움 생태계 내 유동성 재스테이킹(Liquid Restaking) 프로토콜로서, 이론적으로 사용자는 ETH를 예치하기만 하면 rsETH를 증표로 받을 수 있습니다. 이 증표는 메인넷에서 유통될 뿐만 아니라, LayerZero의 OFT 표준으로 래핑되어 Base, Arbitrum, Linea, Blast, Mantle, Scroll 등 20개 이상의 체인에 배포됩니다.

즉, 이더리움 메인넷 쪽의 크로스체인 계약은 모든 ETH 준비금을 보유하고 있는 반면, 다른 체인의 rsETH는 본질적으로 '메인넷 준비금에 대한 인출 증서'일 뿐입니다. 이는 이 시스템이 성립하기 위한 전제 조건이 '메인넷 락업 수량이 항상 L2 체인 발행 수량보다 크거나 같다'는 앵커링 관계가 파괴되지 않아야 한다는 것을 의미합니다.

그리고 공격자가 뚫은 것은 바로 이 단순해 보이지만 매우 중요한 기본 제약 조건이었습니다. 그는 직접 '합법적인' LayerZero 크로스체인 메시지를 위조하여 메인넷 브리지 계약이 다른 체인에서 온 적법한 지급 명령이라고 믿게 만든 다음, 116,500개의 rsETH를 방출하도록 허용한 것입니다.

문제의 핵심은 LayerZero의 검증 구성에 있습니다. Kelp DAO는 1/1 DVN(탈중앙화 검증자 네트워크) 구성을 채택하여 단 하나의 검증 노드 서명만으로 크로스체인 메시지를 통과시킬 수 있었습니다! LayerZero 공식에서는 실제로 2/2 이상의 다중 검증자 중복을 권장하며, 이러한 1/1 구성의 위험성은 2025년 1월에 이미 보안 연구원에 의해 공개적으로 지적되었음에도 불구하고 15개월 동안 수정되지 않았습니다!

이번 사건을 단순히 '브리지 해킹' 또는 '특정 프로토콜의 위험 관리 부족'으로 분류하기 어려운 이유도 여기에 있습니다. 이 사건은 실제로 두 가지 중첩된 단일 장애 지점 위험을 드러냈기 때문입니다.

• 첫 번째는 검증 단일 장애 지점입니다: DVN은 이론적으로 다양한 보안 요구 사항을 충족하기 위해 다중 독립 검증을 지원하는 조합 가능한 X-of-Y-of-N 보안 모델로 설계되었습니다. 그러나 Kelp DAO의 전체 메시지 적법성은 '하나의 검증 노드에 문제가 없어야 한다'는 단일 가정으로 축소되었습니다.
• 두 번째는 준비금 단일 장애 지점입니다: 일단 이 메인넷 준비금 풀이 뚫리면, 다른 체인의 rsETH는 더 이상 크로스체인 자산이 아니며, 단일 메인넷 앵커에 기반한 IOU(차용 증서)에 불과하다는 본질이 드러납니다.

검증 단일 장애 지점과 준비금 단일 장애 지점이 겹치면, 위험은 더 이상 단일 프로토콜 내부에 머무르지 않고 DeFi의 조합 가능성을 따라 외부로 확산됩니다.

이것이 바로 Aave가 사고 후 여러 체인의 rsETH/wrsETH 시장을 긴급 동결하고, WETH 금리 모델을 조정하며, 추가로 여러 WETH 시장을 동결하여 압력이 더 많은 자산으로 확산되는 것을 막은 이유입니다. Aave 자체가 해킹된 것은 아니지만, 담보 가치 왜곡, 청산 지연, 차용자 건강 상태 한계 도달 등으로 인해 결국 프로토콜은 실질적인 부실 채권 위험을 감수해야 했습니다.

시야를 좀 더 높이면, '보안을 단일 지점에 아웃소싱'하는 이러한 논리가 브리지와 검증자에만 존재하는 것이 아니라, 사용자가 매일 마주하지만 거의 정면으로 논의되지 않는 곳, 즉 인터페이스에도 잠재되어 있음을 알 수 있습니다.

2. '자산 자체 보관'에서 '상호작용 검증 가능성'으로: 가장 간과하기 쉬운 단일 지점 신뢰

Web3 커뮤니티에는 오래된 격언이 있습니다: Don't trust, Verify.

이더리움 재단이 노드를 소개할 때 이 말에 대해 설명하는 방식은 매우 직설적입니다. 자신의 노드를 운영한다는 것은 다른 사람이 알려주는 결과를 믿을 필요가 없다는 뜻입니다. 네트워크의 진실에 대한 판단을 중앙화된 데이터 제공자에게 아웃소싱하지 않고, 직접 데이터를 검증할 수 있기 때문입니다.

이 원칙은 지갑과 DeFi 간의 상호작용에도 동일하게 적용됩니다.

imToken과 같은 비수탁형 지갑은 본질적으로 사용자가 계정에 접근하는 도구이며, '자산을 보고, 거래를 전송하고, 애플리케이션에 로그인'하는 창구입니다. 지갑 자체는 사용자의 자금을 수탁하지 않으며, 개인 키도 플랫폼이 보유하지 않습니다. 지난 몇 년 동안 업계는 점차 '자산 자체 보관'의 중요성을 받아들였고, 점점 더 많은 사람들이 진정한 탈중앙화는 단순히 코인을 체인에 두는 것이 아니라 자산 통제권을 사용자 자신에게 되돌려주는 것임을 이해하기 시작했습니다.

하지만 문제는 자산 측면에서는 '자체 보관'을 점점 더 강조하지만, 상호작용 측면에서는 여전히 더 교묘한 형태의 아웃소싱, 즉 거래 의미에 대한 이해, 호출 결과에 대한 판단, 인터페이스의 진위성에 대한 신뢰를 눈앞의 프런트엔드 해석에 맡기는 관행이 널리 퍼져 있다는 점입니다.

이것이 바로 오늘날 DeFi에서 가장 간과되기 쉬운 위험 계층입니다: 사용자가 서명한 것이 정말로 자신이 서명했다고 생각하는 그 거래일까요?

일상적인 체인 상호작용에서 사용자는 거의 항상 체인 자체와 마주하는 것이 아니라, 여러 계층으로 포장된 인터페이스(예: DApp 웹 프런트엔드, 지갑 팝업, 애그리게이터가 제시하는 경로 설명, 그리고 미래에는 Agent가 자동 생성하는 호출 및 결과 확인)와 마주한다고 해도 과언이 아닙니다. 이러한 인터페이스는 사용자에게 '지금 100 ETH를 특정 전략에 예치하고 있습니다', '특정 연간 수익률을 얻게 됩니다', '단지 일반적인 승인을 하고 있을 뿐입니다'라고 알려줍니다.

하지만 실제로 서명되고, 브로드캐스트되며, 체인에서 실행되는 calldata가 정확히 무엇인지, 프런트엔드 설명과 하위 실행이 엄격히 일치하는지 여부를 대다수의 사용자가 독립적으로 확인할 능력은 없습니다.

이것이 바로 역사적으로 반복적으로 발생한 프런트엔드 하이재킹, 주소 변조, 악의적인 승인 위장 사고가 표면적으로는 다른 유형의 보안 사고처럼 보이지만, 그 근본 원인은 모두 동일한 문제, 즉 사용자가 서명한 것이 자신이 서명했다고 생각하는 거래와 항상 일치하지는 않는다는 점을 가리키는 이유입니다.

이러한 관점에서 볼 때, Kelp DAO 사건이 드러낸 것은 브리징 경로의 단일 지점 검증 문제만이 아닙니다. 또한 업계 전체에 오랫동안 과소평가되어 온 또 다른 사실, 즉 많은 체인 상호작용에서 인터페이스 자체가 기본적으로 신뢰되지만 거의 검증되지 않는 단일 지점이라는 점을 상기시켜 줍니다. '확인'을 클릭하는 순간, 사용자는 해당 호출의 정확성을 '인터페이스가 거짓말을 하지 않는다'는 사실에 걸고 있는 셈입니다.

이것이 바로 'Verifiable UI' 개념으로 이어집니다.

소위 'Verifiable UI'는 직역하면 '검증 가능한 인터페이스'입니다. 그 핵심은 프런트엔드를 더 예쁘게 만들거나 서명 팝업을 더 이해하기 쉽게 작성하는 것이 아니라, 인터페이스가 제시하는 내용과 체인에서 실제로 실행되는 호출 사이에 사용자가 확인하고, 지갑이 검증하며, 사후에 추적할 수 있는 연결 고리를 구축하려는 시도입니다.

다시 말해, 해결하려는 문제는 '정보가 표시되었는지 여부'가 아니라 '표시된 내용이 체인에서 곧 발생할 일과 실제로 일치하는지 여부'입니다. 이는 다음을 의미합니다.

• 지갑은 서명 전에 사용자에게 단지 16진수 데이터 문자열만 보여주거나 프런트엔드에서 일방적으로 생성한 설명 텍스트를 전달하는 데 그쳐서는 안 되며, calldata를 사람이 읽을 수 있고 의미가 명확한 작업 의도로 최대한 복원해야 합니다.
• 인터페이스가 설명하는 각 단계는 체인에서 검증 가능한 증거에 매핑될 수 있어야 하며, '사용자가 믿으면 성립하는' 설명 논리에 머물러서는 안 됩니다.
• 그래야만 '사용자가 자신이 하고 있다고 생각하는 일'과 '체인에서 실제로 일어나는 일' 사이에 더 이상 넘기 어려운 인식 격차가 존재하지 않게 됩니다.

이것이 가능해지면, 인터페이스는 더 이상 사용자가 묵시적으로 믿을 수밖에 없고 독립적으로 확인할 수 없는 유리창이 아니라, 사용자가 직접 확인하고 나중에 추적할 수 있는 실행 설명서와 같아집니다.

오늘날의 DeFi만 놓고 보면, 인터페이스 검증 가능성은 여전히 심각하게 과소평가된 주제입니다. 하지만 시간 축을 조금만 늘려 보면, 이는 곧 '논의할 가치가 있는 보안 최적화'에서 '더 이상 미룰 수 없는 기본 역량'으로 바뀔 것입니다. 이더리움 상호작용 경로에서 조용하지만 의미심장한 변화가 일어나고 있기 때문입니다.

3. Verifiable UI가 새로운 보안 경계가 되어야 하는 이유

Kelp DAO 사건이 구세대 DeFi 아키텍처에 이미 수년간 존재해 온 단일 지점 신뢰 문제를 드러냈다면, 'Verifiable UI'는 이미 도래하기 시작한 새로운 단계에 대응합니다.

ETHUX라는 이더리움 UX 맵은 오늘날 체인 상호작용의 핵심 문제점을 이미 매우 명확하게 정리했습니다. 거래 명확성(Transaction Clarity), 크로스체인 흐름(Cross-chain Flow), 안전 및 보안(Safety & Security)은 항상 가장 핵심적인痛点(痛点) 범주였으며, 블라인드 서명(blind signing), 서명 피로(signing fatigue), 브리징 어려움(bridging pain), 자산 파편화(asset fragmentation) 같은 문제는 거의 모든 노련한 사용자에게 익숙합니다.

이것이 시사하는 바는 '사용자 교육이 여전히 부족하다'는 것이 아니라, 더 본질적인 사실, 즉 체인 세계에서 UX와 보안은 결코 별개의 문제가 아니라는 점입니다.

다시 말해, 많은 경우 이해하지 못하는 것 자체가 가장 큰 보안 위험입니다.

그리고 상호작용 패러다임이 '사용자가 DApp 프런트엔드에서 단계별로 클릭하는 방식'에서 '사용자가 의도를 표현하면 시스템이 자동으로 실행을 완료하는 방식'으로 전환됨에 따라, 이 문제는 약화되지 않고 오히려 더욱 증폭될 것입니다.

전통적인 DApp 프런트엔드 시대에는 사용자가 적어도 버튼, 페이지, 승인 팝업을 볼 수 있었고, 완전히 이해하지는 못하더라도 '지금 여러 단계의 작업을 수행 중이다', '이것은 승인인가 전송인가', '크로스체인 중인가 예금 중인가'를 어렴풋이 인지할 수 있었습니다.

하지만 Agent 시대에 접어들면, 이러한 가시적인 프로세스 감각은 크게 압축될 것입니다. 사용자는 더 이상 Router, Bridge, Vault, Lending Market을 하나하나 열어 각 호출을 확인하지 않을 것입니다. 대신 AI 지갑에 "내 ETH를 더 안정적인 수익 전략으로 바꿔줘", "Base로 크로스체인하고 최대 슬리피지는 제어해줘", "이 Agent가 24시간 동안 100 USDT만 사용하도록 허용해줘"라고 말한 다음 '완료' 결과만 기다리는 경우가 더 많을 것입니다.

이는 물론 효율성의 획기적인 향상을 의미하지만, 중간의 경로, 매개변수, 승인, 실행 순서가 점점 더 사용자의 시야 밖으로 접힐 위험이 있음을 의미하기도 합니다. 이러한 맥락에서 imToken은 두 가지 병행 방향을 제시한 바 있습니다. 하나는 사용자가 '무엇을 원하는지'만 표현하면 시스템이 경로를 찾고 실행을 완료하는 의도 기반(intent-based) 상호작용 경로를 계속 탐색하는 것이고