AlphaProof Code vs MathForm-8B: 동일한 Lean 파이프라인의 두 단계이지, 두 경쟁자가 아니다

AlphaProof Code 논문을 자세히 읽다 보면 발표문이 강조하지 않는 숫자 하나가 눈에 띈다. DeepMind의 다섯 연구자가 Signal을 검증하는 데 보낸 4주 중 자동화할 수 없었던 부분은 앞단이었다. 인간 전문가들이 여러 모델을 섞어 Signal의 보안 목표를 형식적인 Lean 명세로 옮기는 작업을 했고, 증명 작업이 시작되기 전에 전문가 한 명이 그 하나하나를 모두 검토했다. 바로 그 지점이 병목이다. 2026년 8월 14일 Hugging Face에 공개된 OpenBMB의 80억 파라미터 자동 형식화 모델 MathForm-8B는 바로 그 단계를 자동화하려는 직접적인 시도다. 즉 자연어 수학 명제를 받아들여 다른 누군가가 증명할 수 있는 Lean 4 정리문을 내놓는 것이다. 둘을 나란히 놓고 보면 두 제품을 비교하는 것이 아니다. 하나의 파이프라인에서 연속된 두 단계를 보는 것이며, 그 사이에는 수학과 프로토콜 보안 사이의 차이가 가로놓여 있다.

파이프라인, 작업이 진행되는 순서대로

실제 소프트웨어에 대한 형식 검증에는 세 가지 작업이 있다. 첫째, 무엇이 참이어야 하는지 결정하고 이를 형식 언어로 적는다. 둘째, 구현이 이를 만족함을 증명한다. 셋째, 증명을 기계적으로 검사한다. 잘못된 증명은 증명이 없는 것보다 더 나쁘기 때문이다.

MathForm-8B는 첫 번째 작업을 수행합니다. 대상은 좁은 입력 범주, 즉 교과서 스타일의 수학적 명제입니다. "모든 실수 x에 대해 x²는 음이 아니다"를 주면 Lean 4의 import, 타입, 정리 헤더를 반환합니다. 반환하지 않는 것은 증명이며, 저자들은 증명 탐색이 다른 사람의 문제라고 분명히 밝힙니다. 모두 벤더가 보고했고 재현되지 않은 이 모델의 보고 수치는 6개 벤치마크에서 구문 검사 기준 평균 Pass@8 88.06%, 더 엄격한 일관성 검사 기준 72.37%입니다. 두 수치 사이의 격차는 구문상 유효한 문장이 요청된 것과 다른 의미를 갖는 빈도를 정직하게 보여주는 척도입니다.

AlphaProof Code는 두 번째와 세 번째 작업을 수행하며, 여기에 MathForm-8B가 손댈 수 없었던 명세 단계도 더합니다. Signal의 보안 목표는 MathForm이 훈련된 의미의 수학적 주장이 아니라 프로토콜에 관한 진술입니다. 즉 기기가 일시적으로 침해되기 전과 후에도 메시지가 보호된다는 것, 개시자와 응답자가 자신이 주장하는 주체라는 것입니다. 그것들을 Lean으로 바꾸려면 어떤 8B autoformalizer도 갖지 못한 프로토콜 전문성이 필요했습니다. 일단 명세가 존재하자 증명 작업은 전적으로 에이전트에게 넘겨졌고, 검사는 Lean의 커널과 게이트키퍼 에이전트에게 맡겨졌으며, 게이트키퍼 에이전트는 비교기를 따로 보관해 둔 명세 사본과 대조하는 데 사용했습니다.

각각을 사용할 때 실제로 드는 비용

• 가중치 — MathForm-8B: 다운로드 가능, Apache 2.0, BF16 형식의 safetensors 샤드 4개, Qwen3-8B에서 미세 조정됨. AlphaProof Code: 없음. 이번 릴리스는 Lean 개발, AArch64 시맨틱스 및 libsignal 바인딩이며 github.com/google-deepmind/code-verification에 있습니다.

• 실행하기 — MathForm-8B: Transformers, vLLM 또는 SGLang을 사용하며, 모두 자체 하드웨어에서 OpenAI 호환 엔드포인트를 제공합니다. AlphaProof Code: 엔드포인트도, API도, 대기자 명단도, 가격도 없습니다. DeepMind가 확장되기 전에 "지속적인 연구"가 필요하다고 말하는 연구 프레임워크입니다.

• 입력 — MathForm-8B: 자연어로 된 수학 문장. AlphaProof Code: 형식 명세와, 그 명세에 대해 증명하려는 바이너리.

• 출력 — MathForm-8B: Lean 4 정리 진술, 증명되지 않음. AlphaProof Code: 기계 검증된 증명, 또는 코드가 깨졌을 때의 반박.

• 인간 검토 — MathForm-8B: 생성된 진술을 검토하게 되며, 일관성이 72.37%이므로 많은 진술을 검토하게 될 것입니다. AlphaProof Code: 전문가들은 증명 작업이 시작되기 전에 모든 명세를 검토하고, 그다음 에이전트가 코드베이스의 약 1%를 재검토 대상으로 표시합니다.

• 알려진 한계 — MathForm-8B: 수학적 진술만 처리하고 증명 생성은 지원하지 않으며, README에 링크된 코드 저장소는 출시 당시 여전히 플레이스홀더였습니다. AlphaProof Code: SPQR 힐링에 대한 포스트 양자 보장 없음, 페이로드 프라이버시 없음, 프로모션당 세션 하나, 그리고 단일 세션에서 메시지 약 25,000개 부근에서 공허해지는 MAC 위조 한계.

MathForm-8B가 메워야 할 격차

자동 형식화기가 Signal의 명세를 작성해 연구자들이 초반에 몰아서 써야 했던 몇 주를 절약할 수 있었다고 말하고 싶어지기 쉽다. 그러나 논문 자체의 설명은 다르며, 그 이유는 구체적이다. 프로토콜 명세는 주장을 다시 진술한 것이 아니라 적대자 모델에 관한 선택이다. Signal 연구에는 핸드셰이크 이후 Diffie–Hellman을 깨는 양자 공격자를 둔 Dolev–Yao의 기호적 트랙과, 고전적 적대자와 구체적인 경계를 둔 계산적 트랙이 있다. 이 두 트랙은 동일한 코드에 대해 서로 다른 정리를 진술하며, 둘 중 하나를 고르는 것은 보안상 결과를 수반하는 엔지니어링 결정이다. "x² ≥ 0임을 보여라"를 Lean으로 바꾸도록 훈련된 모델은 그런 결정을 내리지 못할 것이다.

오토포멀라이저가 그럴듯하게 할 수 있는 일은 그 작업의 기계적인 부분이다. 즉, 산문으로 된 보안 목표와 기존 Lean 정의 라이브러리가 주어지면, 전문가가 교정할 수 있도록 프로젝트 자체의 관용구로 된 명제의 초안을 만들어 내는 것이다. 그것은 실질적인 절감이지만, 헤드라인이 시사하는 것보다는 훨씬 작은 절감이다. 이 논문은 200개가 넘는 계산 항목과 약 35개의 기호 항목으로 이루어진 명세 이탈 목록을 보고하는데, 그중 15개는 Double Ratchet 분석의 공백이나 버그이며, 이는 인간 검토 단계에서 발견된 것이다. 명제 초안을 작성하는 모델은 수학 벤치마크에서의 Pass@8 점수가 아니라 그 목록을 기준으로 측정되어야 할 것이다.

두 숫자가 전혀 비교 가능하지 않은 경우

MathForm-8B의 88.06%와 AlphaProof Code의 650만 줄은 서로 다른 것을 측정하므로 결코 같은 열에 놓아서는 안 됩니다. 하나는 저자들이 구축한 벤치마크 모음에 대한 적중률이고, 다른 하나는 한 대상에 대해 생성된 증명의 양입니다. 공급업체는 88.06%가 구문 검사를 사용한다고 솔직히 인정하는데, 이는 약한 기준입니다 — 명제는 컴파일될 수 있으면서도 잘못된 주장을 형식화할 수 있으며, 이것이 일관성 수치가 16포인트 더 낮은 이유입니다.

비슷한 결을 지닌 AlphaProof Code의 사례는 검증 작업이다. 이전에 수정된 두 가지 Signal 버그, 즉 weak-state 버그와 small-subgroup 버그가 격리된 복사본에 다시 도입되었고, 두 경우 모두 시스템은 버그가 있는 버전이 보안 정리를 충족하지 못한다는 기계 검증된 증명을 생성했다. 그것은 부정 테스트이며, 부정 테스트야말로 자동 형식화기 벤치마크에 완전히 빠져 있는 것이다. MathForm-8B는 "의도적으로 잘못된 진술이 주어졌을 때 모델이 그렇다고 말했다"는 형태의 결과를 보고하지 않는다.

실제로 이들을 함께 사용하는 방법

구체적으로 말하면, 그리고 이것이 단기적 경로가 있는 비교의 유일한 부분인데: 초안을 작성하는 데는 자동 정형화기를, 초안을 비판하는 데는 강력한 범용 모델을, 증명을 시도하는 데는 증명 에이전트를 사용하십시오. 각 단계는 서로 다른 실패 모드를 가지며, 세 가지 모두를 하나의 키로 라우팅하는 것이 실용적인 편의입니다. OrcaRouter에서는 단일 API를 통해 200개가 넘는 모델을 제공업체 정가에 0% 마크업으로 이용할 수 있습니다, 따라서 동일한 명제를 두 모델에 보내고 각자의 Lean 결과를 비교하는 사양 초안 작성 루프는 세 개의 계약과 세 개의 SDK가 아니라 라우팅 DSL 호출입니다. 자동 장애 조치는 선택한 모델이 좋지 않은 오후를 보내고 있는 상황을 처리합니다.

그 어느 것도 제공하지 못하는 것은 바로 보장이다. MathForm-8B는 명제를 내놓고, 모델들은 비평을 제시하지만, 여전히 무언가가 그것을 증명해야 한다. 현재 실제 배포된 코드에서 그 고리를 닫는 유일한 공개 시스템은 AlphaProof Code이며, 그것은 판매되지 않는다.

승자를 가리는 대신 두 논문을 모두 읽어야 하는 이유

MathForm-8B는 좁은 용도의 작업에 유용한 산출물이며, 실제로 측정된 정확도 상한이 있습니다. AlphaProof Code는 워크플로 시연으로, 가장 널리 적용할 수 있는 통찰은 증명 분량이 아니라 분업입니다. 명세 작업에는 인간과 강력한 범용 모델이 필요하고, 증명 작업에는 에이전트 팀과 커널이 필요하며, 그 사이의 경계에 모든 어려움이 존재합니다. 검증 파이프라인을 구축하는 사람이라면 누구나 이 분업을 진지하게 받아들여야 하며, 자동 형식화를 첫 단계의 비용을 줄여 주는 요소로 다뤄야 하고 그것을 대체하는 요소로 다뤄서는 안 됩니다.

이번 달 무엇을 다운로드할지 결정하는 팀을 위한 솔직한 요약: MathForm-8B는 Lean을 다루고 초안 작성 보조 도구를 원한다면 추천한다. AlphaProof Code는 아티팩트 저장소와 명세 편차 카탈로그를 읽어라. 그 카탈로그가 어떤 발표보다도 프로덕션 코드의 형식 검증이 아직 닿지 못하는 부분에 대해 더 많이 알려주기 때문이다.