소프트웨어 형식 검증

정의

형식 검증은 프로그램의 수학적 모델이 명시된 명세를 만족함을 증명한다. 증명 검사기가 도출 과정을 검증하지만, 명세와 기계 의미론이 의도한 배포 환경을 기술하는지는 별도의 신뢰 요건으로 남는다. (source)

왜 중요한가

Anthropic과 Theorem은 기존 퍼즈 테스트 진입점으로 컴파일된 바이너리의 무충돌 명세를 정의한다. Agents (LLM Agents)에 검사 가능한 목표를 제공하면서, 성공한 증명이 무엇을 입증하는지에 대한 한계를 명시적으로 유지하는 방식이다. (source)

현재 수준 (2026-10-25)

10월 22일 보고서에 따르면 Claude는 버그를 수정하고 123개 OSS-Fuzz 라이브러리의 239개 진입점에서 무충돌 속성을 증명했으며, 약 180 million줄의 Rocq를 생성했다. 증명은 단일 스레드 정적 RISC-V Linux 바이너리, 고정 메모리 예산, 64 MB 미만 입력을 대상으로 한다. 라이브러리 전체나 일반적인 x86/ARM 배포 환경에 버그가 없음을 입증하지는 않는다. (source)

36개 소규모 검증 과제에서 Opus 5.5는 Opus 5보다 약 40% 적은 토큰으로 절반을 증명한다. 과제마다 5M-token 예산으로 독립적인 단일 에이전트 시도를 세 번 수행하며, 가장 먼저 완료된 시도로 성공을 판정한다. 증명 작업 공간을 공유하면 에이전트가 따로 작업할 때보다 17% 적은 토큰을 사용한다. 벤더가 보고한 실험이며 독립적인 재현 결과는 아니다. (source)

열린 문제

증명에 수억 토큰이 필요할 수 있다. 신뢰해야 하는 구성요소는 형식 의미론, 정리의 서술, Rocq 검사기와 그 기반 실행 스택이다. AddressSanitizer는 일부 메모리 오류를 놓치며, 이 연구는 모든 진입점이나 호출자의 오용을 다루지 않는다. 에이전트가 코드를 수정하도록 허용하면 명세를 자명하게 만족시키는 식의 변형도 가능하므로, 저자들은 패치에 벌점을 부과하고 보상 해킹 여부를 감사한다. (source)

주요 논문

• 10월 22일 기술 보고서는 증명의 일부와 RISC-V/Linux 의미론을 공개한다. 연결된 부록과 증명 저장소를 여기서 독립적으로 확인하지는 않았다. (source)

관련 개념

• AI for Mathematics — 기계로 검사 가능한 도출 과정이라는 공통점이 있지만, 소프트웨어 검증은 프로그램 명세와 기계 모델에도 의존한다. (source)
• Eval Harness Configuration — 통과 결과는 명세가 실제로 어디까지 다루는지에 달려 있다. (source)