왜 코드는 사양에 따라 검증할 수 있는데, 사양 자체는 검증할 수 없는 걸까요?
기회
스마트 계약에 대한 형식 검증은 코드가 문서화된 사양을 충족함을 입증하지만, 해당 사양이 실제로 계약의 의도된 동작을 정확히 반영하고 있는지 여부는 판단할 수 없습니다. 최첨단 자동 감사 도구를 대상으로 한 2025년 MDPI 설문조사에 따르면, 이러한 도구들은 실제 운영 환경에서 발견되는 악용 가능한 버그 중 8~20%만 탐지하는 반면, 저수준 구문 패턴에 대해서는 90% 이상의 커버리지를 보고하는 것으로 나타났습니다. 이러한 격차는 사양에 기인합니다. 논리적 오류, 자산 잠금 조건, 오라클 가정 등은 악용 사례가 발생하여 그 필요성이 입증되기 전까지는 엔지니어들이 이를 모두 열거하는 방법을 알지 못하기 때문에 사양에 거의 나타나지 않습니다. NDSS 2025 PropertyGPT 논문은 효과적인 형식적 검증을 위한 포괄적인 속성의 자동 생성 기능이 커뮤니티에 여전히 부족하다고 직접적으로 밝히고 있습니다. 불완전한 사양에 따라 계약을 승인하는 모든 감사는 안전성을 보장하기보다는 잘못된 신뢰의 기준을 만들어낼 뿐입니다.
왜 중요한가
계약 코드, 비즈니스 컨텍스트, 과거 익스플로잇 데이터베이스를 바탕으로 후보 불변식을 생성하는 도구가 있다면, 형식 검증은 단순한 정확성 검증을 넘어 실질적인 보안 보장이 될 것입니다.
기회 평가 방식
기회 점수는 측정값이 아닌 제 주관적 평가입니다. 얼마나 불편한지, 얼마나 자주 발생하는지, 현재 해결책이 얼마나 부족한지를 반영합니다. 점수가 높을수록 만들 가치가 더 높다고 생각합니다.
발생했을 때 얼마나 큰 불편을 초래하는지.
실제로 얼마나 자주 접하게 되는지.
현재 이를 해결할 만한 도구가 얼마나 부족한지.