Sui Prover 오픈 소스화: 형식 검증이 스마트 컨트랙트 보안의 빠진 고리인 이유
2025년, 대부분의 공격받은 프로토콜이 감사를 받았음에도 불구하고 (일부는 여러 번), DeFi는 스마트 컨트랙트 취약점으로 인해 33억 달러의 손실을 입었습니다. 2월의 15억 달러 규모 Bybit 침해, 4200만 달러 규모의 GMX 익스플로잇, 그리고 수많은 재진입 공격은 불편한 진실을 증명했습니다. 바로 전통적인 보안 감사는 필요하지만 충분하지 않다는 것입니다. 수학적 정밀도가 중요할 때, 예외 사례 (edge cases)를 테스트하는 것만으로는 부족합니다. 그것들을 증명해야 합니다.
이것이 Sui Prover의 오픈 소스 전환이 단순한 GitHub 릴리스 그 이상의 의미를 갖는 이유입니다. Asymptotic에 의해 개발되어 이제 Sui 개발자 커뮤니티에 무료로 제공되는 Sui Prover는 항공 제어 시스템과 프로세서 설계가 실패하지 않도록 보장하는 것과 동일한 수학적 기법인 형식 검증 (formal verification)을 일상적인 스마트 컨트랙트 개발에 도입합니다. 단 하나의 간과된 예외 사례가 수억 달러를 유출 시킬 수 있는 환경에서, 코드가 올바르게 작동함을 수학적으로 증명하는 능력은 더 이상 사치가 아닙니다. 그것은 필수 요소가 되고 있습니다.
감사의 역설: "안전함"이 충분히 안전하지 않을 때
2025년 블록체인 보안 환경은 우려스러운 패턴을 드러냈습니다. Halborn의 Top 100 DeFi Hacks 보고서에 따르면, 엄격한 감사를 통과한 프로토콜들도 여전히 익스플로잇의 희생양이 되었습니다. 원인은 공급망 취약점, 액세스 제어 결함, 경제 모델의 미묘한 수학적 오류 등 다양했습니다. 하지만 공통된 실타래는 수동 검토든 자동 스캐닝이든 전통적인 코드 분석이 가능한 모든 실패 모드를 포착할 수 없었다는 점입니다.
Yearn yETH 버그와 Balancer 라운딩 오류 익스플로잇을 생각해 보십시오. 이것들은 아마추어의 실수가 아니었습니다. 수천 개의 잠재적 실행 경로에서 라운딩 정밀도를 무기화한 미묘한 수학적 오류였습니다. 감사자는 코드를 검토하는 데 수주를 보낼 수 있지만, 치명적인 동작을 유발하는 단 하나의 입력 조합을 여전히 놓칠 수 있습니다.
GMX 익스플로잇은 문제의 또 다른 차원을 보여주었습니다. 취약점은 핵심 거래 로직에 존재하지 않았습니다. 오라클이 증거금 계산과 만나고 청산 로직이 브리지 인프라와 상호작용하는 구성 요소 간의 경계에서 발생했습니다. 상호작용에서 실패가 발생할 때 개별 구성 요소를 테스트하는 것만으로는 충분하지 않았습니다.
이 지점에서 형식 검증은 전통적인 보안 접근 방식과 근본적으로 다릅니다. 특정 테스트 케이스를 확인하는 대신, 형식 검증은 가능한 모든 입력과 실행 경로에서 특정 속성이 유지됨을 수학적으로 증명합니다. 어떤 상황에서도 금고 (vault)가 비워질 수 없음을 증명할 수 있다면, 테스트에서 놓친 모호한 예외 사례에 대해 걱정할 필요가 없습니다.
형식 검증이 실제로 하는 일
형식 검증은 코드를 수학적 문장으로 변환한 다음, 이 문장들이 의도된 동작에 대한 형식 명세 (formal specification)와 일치하는지 증명합니다. 프로세스는 다음과 같이 진행됩니다.
먼저, 개발자는 코드가 무엇을 해야 하는지 설명하는 명세를 작성합니다. 프로그래밍 언어가 아니라 수학적 속성을 표현하기 위해 설계된 특수 명세 언어를 사용합니다. 스마트 컨트랙트의 경우, 이러한 명세에는 "민트 (mint) 또는 번 (burn)이 호출되지 않는 한 토큰의 총 공급량은 절대 변하지 않는다" 또는 "사용자 잔액은 사용자의 명시적 승인이 있어야만 감소할 수 있다"와 같은 문장이 포함될 수 있습니다.
그다음, Boogie 검증 엔진과 Z3 SMT 솔버를 기반으로 구축된 Sui Prover와 같은 프로버 도구가 코드가 가능한 모든 입력에 대해 이러한 명세를 충족하는지 철저하게 확인합니다. 특정 값을 확인하는 테스트와 달 리, 프로버는 수학적 추론을 통해 동시에 모든 가능한 입력을 평가합니다.
검증에 성공하면 지정된 속성이 유지된다는 수학적 증거를 갖게 됩니다. 실패하면 프로버는 일반적으로 반례 (counterexample), 즉 명세를 위반하는 특정 입력을 제공하며, 이는 종종 테스트가 놓쳤을 버그를 드러냅니다.
Sui와 Aptos에서 모두 사용되는 Move 프로그래밍 언어는 처음부터 형식 검증을 염두에 두고 설계되었습니다. 자원 지향 모델 (resource-oriented model)과 강력한 정적 타이핑은 형식 검증을 Solidity와 같은 언어보다 더 실용적으로 만드는 토대를 제공합니다. Move Specification Language (MSL)를 통해 개발자는 세 가지 범주의 속성을 표현할 수 있습니다.
- 구조체 불변성 (Struct Invariants): 구조체가 수명 동안 유지해야 하는 상태
- 함수 명세 (Function Specifications): 각 함수에 대한 사전 조건, 사후 조건 및 동작 보장
- 전역 상태 명세 (Global State Specifications): 모든 상태 전환에서 유지되어야 하는 시스템 전체의 속성
Sui Prover: 내부 도구에서 커뮤니티 자원으로
Asymptotic은 처음에 Sui에서 구축되는 프로토콜들에 대한 감사 작업을 지원하기 위해 Sui Prover를 개발했습니다. Sui의 유일한 형식 검증 제공업체로서, 그들은 수동 검토를 넘어 클라이언트 코드베이스의 고위험 영역 을 수학적으로 검증할 수 있는 도구가 필요했습니다.
이 도구를 오픈 소스로 전환하기로 한 결정은 형식 검증 기술의 성숙도와 보안이 공공재라는 인식을 모두 반영합니다. 더 많은 개발자가 형식 검증에 접근할 수 있게 되면 전체 생태계가 더 안전해지며, 이는 더 높은 수준의 문제에 집중할 수 있는 보안 감사자를 포함한 모든 사람에게 이익이 됩니다.
Sui Prover는 GitHub에서 사용할 수 있으며 Homebrew (brew install asymptotic-code/sui-prover/sui-prover)를 통해 설치할 수 있습니다. 2026년 1월에 열린 최근 이슈들을 통해 지속적인 개선이 이루어지며 활발한 개발이 계속되고 있습니다.
Sui Prover를 특히 가치 있게 만드는 것은 Sui Move의 기존 개발 워크플로우와의 통합입니다. 개발자는 기존 코드에 점진적으로 명세를 추가하여, 범위를 점차 확장하는 동안 중요한 함수를 먼저 검증할 수 있습니다. 명세는 안전 점검과 문서화라는 두 가지 역할을 수행합니다. 컨트랙트를 검토하거나 통합하는 사람은 누구나 명세를 읽고 보장된 동작을 이해할 수 있습니다.
증명 가능한 실질적인 속성들
형식 검증의 힘은 증명 가능한 구체적인 속성들을 고려할 때 더욱 구체화됩니다:
자산 유출 방지 볼트 (Non-Drainable Vaults): 사용자 자금을 보유하는 DeFi 프로토콜의 경우, 적절한 권한 없이는 어떤 작업 시퀀스로도 볼트의 자산을 유출할 수 없음을 증명함으로써 전체 공격 범주를 제거할 수 있습니다. 이는 "많은 공격 벡터를 테스트했다"는 수준이 아니라, 자산 유출이 불가능하다는 수학적 확실성을 의미합니다.
지분 가격의 비감소성 (Non-Decreasing Share Prices): 수익 볼트(Yield Vaults)와 유동성 풀은 종종 지분 가격이 예상치 못하게(예상된 슬리피지 범위를 벗어나서) 감소하지 않는다는 것을 보장해야 합니다. 형식 검증은 시장 상황이나 사용자 작업에 관계없이 이 속성이 유지됨을 증명할 수 있습니다.
정확한 잔액 보존 (Exact Balance Preservation): 토큰 컨트랙트는 모든 작업에서 총 공급량이 일정하게 유지되고, 전송 시 지정된 금액만큼만 정확히 이동하며, 지정된 기능 외에는 어떤 토큰도 생성되거나 소멸되지 않음을 증명할 수 있습니다.
액세스 제어 보장 (Access Control Guarantees): 컨트랙트의 상태나 이전 작업의 시퀀스에 관계없이 승인된 주소만 권한이 있는 기능을 호출할 수 있음을 증명합니다.
경제적 불변성 (Economic Invariants): 복잡한 DeFi 프로토콜은 유동성 제약 조건 준수, 담보 비율 유지, 아비트라지 루프를 통한 무한한 가치 추출 불가능성 등 경제 모델에 대한 속성을 증명할 수 있습니다.
이러한 예시는 이론적인 것에 그치지 않습니다. Sui 생태계의 개발자들은 이미 AMM 및 레버리지 일드 파밍 시스템을 포함한 DeFi 컨트랙트를 검증하기 위해 형식 사양(Formal specifications)을 적용하고 있습니다. 이러한 속성들이 추정이 아닌 증명의 대상이 될 때, 보안 태세는 근본적으로 변화합니다.
더 나은 도구를 요구하는 보안 환경
2025년의 통계는 형식 검증의 필요성을 더욱 강력하게 뒷받침합니다. 보안 연구원들에 따르면, 2024년 발생한 공격의 56.5%와 손실된 자금의 80.5%가 오프체인 사고로 인해 발생했지만, 스마트 컨트랙트 취약점은 여전히 악용될 경우 파괴적인 결과를 초래합니다. 2024년 한 해 동안 문서화된 액세스 제어 취약점으로 인한 피해액만 9억 5,320만 달러에 달합니다.
2025년 OWASP 스마트 컨트랙트 Top 10에 따르면 탈중앙화 생태계 전체에서 총 14억 2,000만 달러 이상의 손실이 기록되었습니다. 심볼릭 실행을 위한 Mythril, 속성 기반 퍼징(Property-based fuzzing)을 위한 Echidna, 그리고 OtterSec, Halborn, MoveBit과 같은 기업의 수동 감사 등 전통적인 보안 도구들은 문제의 다양한 측면을 다룹니다. 하지만 프로토콜이 더 복잡해지고 더 많은 가치를 처리하게 됨에 따라, 이러한 접근 방식 사이의 간극은 더욱 위험해지고 있습니다.
CertiK은 형식 검증 기술을 활용하여 스마트 컨트랙트를 수학적으로 검증했으며, 보고서에 따르면 3,000억 달러 이상의 자산을 보호하고 있습니다. 이러한 규모는 수학적 보안 보장에 대한 수요와 블록체인 시스템에 형식 방법론(Formal methods)을 적용하는 것이 실현 가능하다는 것을 모두 보여줍니다.
보안 연구원들 사이에서 형성되고 있는 합의는 감사, 버그 바운티, 모니터링, 점진적 출시, 그리고 형식 방법론이 방어 계층으로서 함께 작동해야 한다는 것입니다. 고가치 시스템의 경우, 핵심 불변성(Critical invariants)에 대한 형식 검증은 예외적인 엄격함이 아니라 표준 관행이 되어가고 있습니다.
왜 Move가 형식 검증을 실용적으로 만드는가
모든 프로그래밍 언어가 형식 검증에 똑같이 적합한 것은 아닙니다. Solidity의 유연성과 EVM의 복잡성은 형식 검증을 어렵게 만듭니다. 가능은 하지만 상당한 도구 오버헤드와 전문 지식이 필요합니다.
Move는 다르게 설계되었습니다. 리소스 지향 모델은 자산이 암시적으로 복제되거나 삭제될 수 없는 선형 타입 (Linear types)을 가짐을 의미합니다. 타입 시스템은 다른 언어에서 런타임 체크가 필요한 수많은 범주의 버그를 컴파일 타임에 잡아냅니다. Move Prover는 언어와 함께 개발되어 언어 기능과 검증 기능 간의 긴밀한 통합을 보장합니다.
이러한 설계 유산 덕분에 Move 표준 라이브러리 자체도 형식 검증을 거쳤습니다. Sui나 Aptos 위에서 빌드할 때, 여러분은 수학적으로 정확성이 증명된 토대 위에서 빌드하는 것이며, 여러분의 검증된 코드가 그 위에 쌓이면서 이러한 증명들은 더욱 견고해집니다.
실질적인 함의는 다음과 같습니다: Move에서의 형식 검증은 다른 플랫폼보다 전문 지식이 덜 필요합니다. Sui Prover의 문서, 예시, 그리고 표준 개발 워크플로우와의 통합 덕분에 형식 방법론 전문가가 아닌 개발자도 접근할 수 있습니다. 간단한 함수 컨트랙트부터 시작하여 이해도가 깊어짐에 따라 복잡한 불변성으로 점진적으로 사양 작성을 배워나갈 수 있습니다.
Sui 개발자들에게 주는 의미
Sui에서 빌딩하는 개발자들에게 오픈 소스 Sui Prover는 새로운 가능성을 열어줍니다:
보안 차별화: 경쟁이 치열한 DeFi 환경에서 보안 속성을 증명하는 것은 단순한 위험 완화가 아니라 경쟁 우위입니다. 사용자와 감사자는 주장을 맹신하는 대신 프로토콜의 안전성에 대한 주장을 직접 검증할 수 있습니다.
감사 비용 절감: 핵심 기능에 형식 증명이 있으면 감사자는 모든 에지 케이스를 철저히 테스트하는 대신 더 높은 수준의 아키텍처 문제에 집중할 수 있습니다. 이는 실제 보안 결과물을 개선하면서 감사의 범위와 비용을 줄일 수 있습니다.
문서화 품질: 형식 사양은 낡지 않는 정밀한 문서입니다. 사양에서 특정 함수가 특정 불변성을 유지한다고 명시하면, 그것은 증명 가능한 사실이거나 Prover가 위반 사항을 표시하게 됩니다.
점진적 도입: 모든 것을 형식 검증할 필요는 없습니다. 출금, 담보 또는 권한이 있는 작업을 처리하는 가장 위험도가 높은 기능부터 시작하여 점차 범위를 확장해 나가면 됩니다.
Sui 생태계에는 이미 MoveBit (Move 형식 검증의 선구자), Certora, OtterSec, Zellic을 포함한 여러 숙련된 감사 기업들이 포진해 있습니다. Sui Prover는 개발자가 모든 검증 작업에 외부 감사자를 고용하지 않고도 직접 사용할 수 있는 도구를 추가해 줍니다.
더 넓은 궤적
Sui Prover 의 오픈 소스화는 블록체인 산업 전반의 보안 도구 성숙이라는 더 넓은 패턴과 일치합니다 . 형식 검증 ( Formal verification ) 은 학술 연구 단계에서 프로덕션 인프라로 , 전문 컨설팅에서 개발자가 접근 가능한 도구로 이동하고 있습니다 .
이러한 궤적이 중요한 이유는 스마트 컨트랙트에 의해 보호되는 가치의 규모가 계속 커지고 있기 때문입니다 . DeFi 프로토콜은 총 수천억 달러의 자산을 관리합니다 . 주요 프로토콜의 단 하나의 버그가 기존 소프트웨어 기업이 평생 직면하는 수준을 넘어서는 손실을 초래할 수 있습니다 .
전통적인 소프트웨어 산업은 항공 공학 , 의료 기기 , 금융 시스템과 같이 안전이 중요한 시스템을 위해 결국 형식적 방법론을 채택했습니다 . " 코드가 곧 법 ( code is law ) " 이며 버그가 되돌릴 수 없는 경우가 많은 블록체인 산업은 수학적 검증을 수용해야 할 훨씬 더 강력한 이유가 있습니다 .
Sui Prover 는 이러한 방향을 향한 한 걸음입니다 : 형식 검증을 아무도 읽지 않는 보안을 위한 보여주기식 문서로 치부하는 것이 아니라 , 개발자가 실제로 사용할 수 있을 만큼 충분히 접근 가능하게 만드는 것입니다 .
시작하기
Sui 에서 형식 검증을 탐구하는 데 관심이 있는 개발자를 위해 :
- Sui Prover 설치 :
brew install asymptotic-code/sui-prover/sui-prover - 작게 시작하기 : 단일 핵심 함수에 사양 ( Specification ) 을 추가하고 검증을 통과하는지 확인하세요
- 사양 언어 배우기 : Move Specification Language 는 일반적인 속성을 표현하기 위한 훌륭한 문서를 제공합니다
- 반복 : 자신감이 쌓임에 따라 더 많은 함수와 복잡한 불변성 ( invariants ) 으로 범위를 확장하세요
형식 사양을 학습하는 데 드는 투자는 복리 이자처럼 돌아옵니다 . 하위 수준 모듈이 올바르다는 것을 확인하고 나면 , 해당 토대가 수학적으로 증명되었다는 확신을 가지고 상위 수준 로직을 구축할 수 있습니다 .
2025 년에 예방 가능한 버그로 수십억 달러를 잃은 산업에서 형식 검증이 노력할 가치가 있는지 여부는 질문의 대상이 아닙니다 . 문제는 생태계가 얼마나 빨리 이를 채택할 수 있느냐입니다 . Sui Prover 의 오픈 소스 릴리스는 하나의 장벽을 제거했습니다 . 이제 지식과 실천이 뒤따라야 합니다 .
Sui 에서 안전한 애플리케이션을 구축하려면 프로토콜의 보안 표준에 부합하는 신뢰할 수 있는 인프라가 필요합니다 . BlockEden.xyz 는 Sui , Aptos 및 20 개 이상의 체인에 대해 프로덕션 애플리케이션이 요구하는 업타임과 신뢰성을 갖춘 엔터프라이즈급 RPC 엔드포인트를 제공합니다 . API 마켓플레이스를 탐색 하여 형식 검증된 스마트 컨트랙트에 힘을 실어주세요 .