코드 버그를 수학으로 잡는다: Mistral의 형식 검증 AI, Leanstral 1.5 (mistral.ai)

한줄 요약

형식 검증 AI Leanstral 1.5가 코드 버그를 자동으로 찾아내는 실용적 수준에 도달했다.

---

형식 검증(Formal Verification)이란 코드나 알고리즘의 정확성을 수학적 증명으로 확인하는 기법이다. 오랫동안 항공·방산·반도체 같은 극히 일부 영역의 전유물로 여겨졌지만, Mistral이 공개한 Leanstral 1.5는 이 기술을 일반 개발 현장으로 끌어내리려는 시도의 결과물이다. Apache-2.0 라이선스로 완전 무료 공개되었으며, Hugging Face와 무료 API를 통해 바로 사용할 수 있다.

무엇이 달라지나?

Leanstral 1.5의 구조부터 살펴보면, 총 119B 파라미터지만 실제 추론 시 활성화되는 파라미터는 6B에 불과하다. 이 설계 덕분에 성능 대비 운영 비용이 극적으로 낮다.

벤치마크 결과가 인상적이다. 수학 형식 증명 분야의 대표적 테스트셋인 miniF2F를 검증·테스트 셋 모두 100% 달성하며 포화시켰다. 대학원 수준의 추상 대수학 벤치마크인 FATE-H에서는 87%, 박사 수준인 FATE-X에서는 34%로 현재 기준 최고 성능을 기록했다. Putnam 수학경시대회 672문제 중 587개를 풀었는데, 여기서 주목할 지점은 비용이다. 문제당 약 $4 수준으로, 경쟁 모델인 Seed-Prover 1.5의 고성능 설정 추정 비용인 $300 이상과 비교하면 약 75분의 1 수준이다.

훈련 방식도 주목할 만하다. 중간 훈련(Mid-training), 지도 미세조정(SFT), 그리고 CISPO 방식의 강화학습(RL)을 순차 적용한 3단계 파이프라인을 거쳤다. 특히 두 가지 RL 환경이 핵심인데, 하나는 멀티턴 환경으로 Lean 컴파일러 피드백을 받아 증명을 반복 수정하는 루프이고, 다른 하나는 코드 에이전트 환경으로 실제 파일 시스템에서 파일 편집, bash 명령 실행, Lean 언어 서버 활용을 직접 수행한다. 두 번째 환경이 실무 적용 가능성을 높이는 핵심 요소다.

테스트 타임 스케일링 특성도 눈에 띈다. 토큰 예산을 25k에서 4M까지 늘릴수록 PutnamBench 해결 문제 수가 단조 증가했다. 50k 토큰에서 44문제, 200k에서 244문제, 1M에서 493문제, 4M에서 587문제로 계속 올라갔다. 예산을 더 쓸수록 성과가 선형에 가깝게 늘어난다는 의미다.

실무에서 어떤 의미인가?

수학 증명 벤치마크보다 실무 개발자에게 더 중요한 건 코드 검증 사례다.

첫 번째 사례는 AVL 트리 시간복잡도 증명이다. O(log n) 보장을 이론이 아닌 실제 구현 코드에 대해 형식적으로 증명했다. 2.7백만 토큰, 22회 컴팩션에 걸쳐 시간 추적 모나드를 단계별로 풀어내며 삽입과 삭제 모두 O(log n)임을 완전히 검증해냈다.

두 번째 사례는 버그 자동 탐지다. 파이프라인 구조는 이렇다. Aeneas 툴이 Rust 코드를 Lean으로 변환하고, Leanstral이 코드의 의도를 추론해 정확성 속성을 생성한다. 이를 4회 시도로 증명하고, 실패 시 부정을 증명하는 방식으로 버그를 탐지한다. 57개 오픈소스 저장소를 대상으로 돌린 결과, 47개의 위반 속성이 발견되었고 그 중 11개가 실제 버그였으며, 5개는 GitHub에 이전에 보고된 적 없는 신규 버그였다.

구체적 예시로 datrs/varinteger 라이브러리의 zigzag 디코딩용 부호 함수에서 발견된 버그가 있다. Std.U64.MAX 입력 시 (value + 1) 연산에서 오버플로우가 발생해 디버그 모드에서는 크래시, 릴리스 모드에서는 조용한 데이터 오염을 유발했다. 일반적인 테스트와 퍼징으로는 잡기 어려운 경계값 버그였다.

외주 개발이나 소프트웨어 납품 품질 관리에 관심 있는 팀이라면 이 지점을 주목할 필요가 있다. 코드 리뷰와 테스트가 놓치는 엣지 케이스를 형식 검증이 체계적으로 탐지할 수 있다는 가능성이 실제로 입증되기 시작했다.

도입 전 체크포인트

Leanstral 1.5가 인상적이지만, 실제 프로젝트에 적용하기 전에 현실적으로 점검해야 할 항목이 있다.

Lean 4 생태계 진입 비용: 형식 검증은 Lean 4 언어 자체를 학습해야 한다. 모델이 자동화해주는 부분이 늘었어도, 검증 대상 속성을 정의하고 결과를 해석하는 역량은 팀 내에 필요하다.

Rust → Lean 변환 의존성: 현재 코드 검증 파이프라인은 Aeneas를 통한 Rust 변환에 의존한다. Rust 이외의 언어로 작성된 코드베이스에는 직접 적용이 어렵다.

검증 범위 설정: 57개 저장소 테스트에서 47개 위반 속성 중 실제 버그는 11개였다. 오탐율이 존재하므로, 파이프라인 결과를 자동으로 신뢰하지 말고 검토 프로세스를 함께 설계해야 한다.

토큰 비용 관리: 테스트 타임 스케일링이 강력하지만, 4M 토큰 예산은 복잡한 문제에만 선택적으로 투입하는 전략이 현실적이다.

형식 검증이 일부 연구소의 이론에서 실용 도구로 이동하는 변곡점에 Leanstral 1.5가 있다. 모든 프로젝트에 즉시 적용할 수 있는 솔루션은 아니지만, 고신뢰 코드 품질이 필요한 개발 현장에서 검토할 가치가 충분하다.