Adam Langley는 Lean 증명 자동화가 도래했다고 말한다. 어려운 부분은 이제 다른 곳으로 옮겨갔다

Adam Langley는 여러 대규모 언어 모델이 약 20분 만에 어려운 소프트웨어 증명을 완성하면서 Lean 증명 자동화가 실용적인 임계점을 넘었다고 말한다. 다만 중요한 단서가 있다. AI가 증명을 생성했지만, Lean은 형식 명세에 따라 모든 단계를 검증했다.

이 차이는 이 실험을 AI가 그럴듯한 코드를 만들어냈다는 또 하나의 이야기와 구분한다. Langley는 Lean으로 Zstandard 압축 해제기를 만든 뒤, 모델들에게 엔트로피 디코딩 테이블의 보편적 속성을 증명해 달라고 요청했다. 보도에 따르면 모델들은 해결되지 않은 증명 공백 없이 작업을 마쳤지만, 구현의 일부도 변경했다.

이 실험은 소프트웨어 팀에 다른 형태의 거래를 제시한다. 개발자는 증명을 구성하는 데 쓰는 시간을 줄이고, 시스템이 정확히 무엇을 보장해야 하는지 결정하는 데 더 많은 시간을 쓸 수 있다. AI 코딩 도우미는 답을 생성한 뒤 사람이 오류를 찾도록 요구한다. Lean은 기계적으로 검증 가능한 명제를 충족하지 못하는 모든 답을 거부함으로써 이 관계를 뒤집는다.

이는 형식 검증이 저렴하고 쉬워졌거나 모든 애플리케이션에 적합해졌다는 증거는 아니다. Langley는 이 압축 해제기를 장난감이라고 설명했고, 소스는 공개하지 않았으며, 성능은 표준 zstd 명령의 10분의 1 수준이라고 측정했다. 독립 연구 역시 AI 증명기가 크고 낯선 리포지터리에 의존하는 증명에서는 어려움을 겪는다는 점을 보여준다.

그럼에도 더 방어 가능한 결론은 중요하다. AI는 이제 반복적인 증명 작업을 충분히 흡수해, 전통적 틈새 분야 밖에서도 검증을 시험해 볼 만하게 만들 수 있다. 지식 노동자에게 더 넓은 교훈은 소프트웨어를 넘어선다. 자동화는 수용 기준이 명시적이고 독립적으로 확인될 때 더 신뢰할 수 있다.

Zstandard 실험에서 Lean 증명 자동화가 작동했다

뉴스는 AI가 또 하나의 프로그램을 작성했다는 데 있지 않다. 논리 오류를 거부하도록 설계된 검증기를 AI 생성 작업이 통과했다는 데 있다.

암호학과 인터넷 인프라 분야의 작업으로 알려진 보안 엔지니어 Langley는 2026년 7월 26일 이 실험을 공개했다. 그의 증명 자동화 글은 Lean으로 Zstandard 압축 해제기를 만들고, 디코딩 테이블의 여러 속성을 형식화한 과정을 설명한다.

Lean은 함수형 프로그래밍 언어이자 증명 보조기다. 증명 보조기는 형식 논증이 정확히 명시된 명제를 성립시키는지 확인한다. Lean의 작은 커널은 결과 증명 항을 검증하므로, 사용자는 이를 생성한 모델을 신뢰할 필요가 없다.

시험은 Zstandard가 일부 값을 효율적으로 인코딩하는 데 사용하는 Finite State Entropy, 즉 FSE에 초점을 맞췄다. FSE는 확률에 따라 상태 테이블 전반에 심볼을 배치한다. 각 상태는 심볼, 읽어야 할 비트 수, 그리고 다음 상태를 계산하기 위한 기준값을 식별한다.

올바른 테이블은 여러 관계를 보존해야 한다. 예상되는 항목 수, 모든 심볼에 대한 올바른 할당, 가능한 모든 상태에 대한 유효한 전이가 필요하다. 확률이 0이 아닌 각 심볼은 모든 목표 상태로 향하는 경로를 정확히 하나씩 가져야 한다.

단위 테스트는 Zstandard 명세에서 선택한 예시를 확인할 수 있다. 하지만 이 속성들이 모든 유효한 입력에서 성립한다는 사실을 확립할 수는 없다. 대신 Langley는 전체 테이블 구성 함수를 포괄하는 하나의 정리를 작성했다.

여러 LLM이 약 20분 만에 증명을 생성한 것으로 전해진다. Langley는 Lean이 결과를 받아들였고, 파일에 Lean 개발자들이 누락된 증명의 자리표시자로 사용하는 sorry 선언이 없음을 확인했다.

모델들은 고립된 빈칸만 채운 것이 아니었다. Langley가 지나치게 명령형 스타일의 구조를 사용했기 때문에 테이블 생성 코드를 변경했다. 그런 구조는 증명 도구가 분석하기 더 어려웠다.

이 세부 사항은 매력과 비용을 모두 드러내기 때문에 중요하다. AI가 증명 구성을 처리했지만, 구현은 여전히 추론을 뒷받침하는 형태여야 했다. 검증은 임의의 코드에 적용하는 최종 품질 관리 버튼으로 등장한 것이 아니다.

Langley 역시 이 프로젝트를 프로덕션 증거로 제시하지 않았다. 코드는 여전히 공개되지 않았고, 디코더는 범위가 제한된 실험만 다뤘으며, 성능은 확립된 구현보다 뒤처졌다. 그의 주장은 이 특정 압축 해제기의 준비 상태가 아니라 증명 자동화의 가용성에 관한 것이다.

관련 프로젝트는 더 넓은 기준점을 제공한다. Lean 제작자 Leonardo de Moura는 테스트를 통과하고 모든 압축 수준에서 왕복 정확성을 증명한 AI 보조 zlib 구현을 소개했다. 이 사례들은 함께 AI 증명을 일반적인 시스템 코드에 더 가깝게 옮겨 놓는다.

그렇다고 인상적인 산출물과 반복 가능한 엔지니어링 프로세스 사이의 간극이 사라진 것은 아니다. 이 간극을 메우는 일이 Lean 증명 자동화가 일반적인 개발 도구가 될지, 전문가의 시연에 머물지를 결정할 것이다.

기존 장벽은 증명 검사가 아니라 증명 작업이었다

형식 검증은 이미 강력한 보장을 제공했다. 경제적 문제는 이를 명시하고 유지하는 데 필요한 인간의 노력이었다.

일반적인 테스트는 실행된 예시에서 소프트웨어가 올바르게 동작했는지 묻는다. 형식 검증은 수학적 모델이 그 모델 안의 모든 입력에 대해 명시된 속성을 만족하는지 묻는다. 이 더 큰 약속은 훨씬 더 큰 작업량을 만든다.

seL4 마이크로커널은 가장 분명한 역사적 사례 중 하나로 남아 있다. 검증 팀은 커널의 구현과 형식 명세를 연결하는 기계 검증 증명을 만들었다. 이 프로젝트는 고신뢰성의 프로덕션 규모 소프트웨어를 검증할 수 있음을 보여줬다.

비용도 기록했다. 팀의 프로젝트 회고에 따르면, 검증에는 C 코드 설계와 구현에 든 노력의 약 10배가 필요했다. 증명 자료의 분량은 구현 코드 줄 수의 20배를 넘었다.

이 수치가 모든 검증 프로젝트가 같은 비율을 따른다는 뜻은 아니다. seL4는 상당한 운영체제 커널 전반에 걸쳐 유난히 광범위한 보장을 추구했다. 하지만 대부분의 소프트웨어 조직이 대신 테스트, 검토, 정적 분석, 운영 모니터링을 선택한 이유를 설명해 준다.

전통적 자동화는 이 부담의 일부를 줄였다. 논리 제약의 해를 찾는 SMT 솔버 같은 도구는 일상적인 증명 의무를 처리할 수 있다. 문제의 형태가 솔버가 지원하는 이론과 예상된 구조에 맞을 때 잘 작동한다.

목표가 이 편안한 영역 밖에 놓이면 경험은 덜 예측 가능해진다. 개발자는 솔버에 더 시간이 필요한지, 아니면 영원히 끝나지 않을지 모른 채 기다릴 수 있다. 팀은 솔버가 동작하도록 만드는 구현 패턴도 익혀야 하며, 이는 또 다른 전문 엔지니어링 분야를 만든다.

LLM은 이 작업에 다르게 접근한다. 정의, 오류 메시지, 인접한 보조정리, 비형식적 설명을 읽을 수 있다. 중간 결과를 제안하고, 실패한 전술을 수정하며, 현재 표현이 진행을 막을 때 코드를 재구성할 수 있다.

이 유연성은 증명 생성을 언어 모델의 자연스러운 대상으로 만든다. 모델은 최종 권위자로 신뢰받을 필요가 없다. 증명 커널이 수용하는 산출물을 만들어내기만 하면 된다.

이는 많은 사무 자동화 작업보다 더 잘 맞는다. 생성된 전략 메모에는 진실성, 관련성, 판단을 모두 검사할 완전한 검증기가 없다. Lean 증명에는 소프트웨어가 결정론적으로 평가할 수 있는 좁은 수용 조건이 있다.

그 결과 예상되는 노동 분담이 바뀐다. 인간은 속성을 명세하고, 가정을 선택하며, 모델이 현실을 표현하는지 판단한다. AI는 증명을 탐색하고, Lean은 제안된 결과를 검증한다.

그렇다고 인간의 작업이 사라지는 것은 아니다. 노력은 명세, 아키텍처, 검토 쪽으로 이동한다. 어떤 결과가 중요한지 결정해야 하므로, 이러한 활동은 자동화하기 더 어렵다.

지식 노동자에게 이것이 더 깊은 생산성 이야기다. 가장 강력한 자동화는 단지 더 많은 자료를 생산하는 데 그치지 않는다. 생성된 자료를 결과의 수용 가능 여부를 결정하는 명시적 조건과 연결한다.

이 원칙은 연구와 운영 업무에도 적용된다. 개인 지식 베이스를 사용하는 팀은 답을 생성하기 전에 근거를 검색할 수 있다. 그래도 결과에는 출처 품질, 범위, 최신성을 포괄하는 기준이 필요하다.

Lean은 이런 기준을 유난히 엄격하게 만든다. 그 교훈은 모든 작업에 정리 증명기가 필요하다는 것이 아니다. 조직이 검증 가능한 계약을 정의할 수 있을 때 자동화가 더 신뢰할 만해진다는 점이다.

AI는 증명의 비용을 바꾸지만, 정확성의 의미를 바꾸지는 않는다

Lean 증명 자동화는 코드가 명세를 충족하는지 검증할 수 있지만, 그 명세가 올바른 문제를 포착하는지는 결정할 수 없다.

이것이 Langley의 실험에서 나타난 핵심적인 역전이다. 모델의 불확실한 추론은 Lean이 최종 출력을 검사하기 때문에 자동으로 증명을 훼손하지 않는다. 하지만 같은 검증기도 잘못된 요구 사항을 형식화한 정리를 구할 수는 없다.

예를 들어 압축 해제기 정리가 생성된 모든 상태 전이가 테이블 내부에 머문다는 사실을 증명한다고 하자. 이는 가치가 있지만, 모든 Zstandard 파일과의 호환성을 확립하지는 않는다. 서비스 거부 동작, 메모리 제한, 사이드 채널, 구현 성능에 대해서도 아무것도 말하지 않는다.

각각의 추가 보장에는 그에 대응하는 명제와 실제 프로그램에 대한 연결이 필요하다. 그 연결에서 가정 하나라도 빠지면, Lean은 형식 명제를 증명할 수 있지만 배포된 시스템은 여전히 취약할 수 있다.

이 문제는 잘못된 거래를 규율하는 잘 작성된 계약과 닮았다. 완벽한 내부 일관성은 빠진 의무를 고칠 수 없다. 검증은 사람이 정의한 경계 안에서의 신뢰를 높인다.

Langley의 FSE 정리는 더 나은 사례를 보여준다. 이 속성들은 최적화된 디코딩 루프에 필요한 가정과 직접 연결된다. 테이블 크기, 심볼 할당, 유효한 전이, 고유한 도달 가능성은 품질에 관한 광범위한 주장보다 구체적인 불변식이다.

이 불변식이 존재하면 컴파일러와 커널은 프로그램 전반에서 이를 강제할 수 있다. 그중 하나를 위반하는 향후 수정은 구현 또는 증명이 변경될 때까지 타입 검사를 통과하지 못한다.

이는 다른 검토 표면을 만든다. 엔지니어는 생성된 수천 개의 증명 단계를 똑같은 주의로 검토할 필요가 없다. 정리와 그 가정, 그리고 코드와 모델의 연결을 감사해야 한다.

희소한 전문성은 바로 그곳으로 옮겨간다. 한때 전술을 이끄는 데 며칠을 쓰던 시니어 엔지니어는, 이제 그 시간을 형식 계약을 다듬는 데 쓸 수 있다. AI는 기계적인 탐색 대부분을 처리하고, 인간 검토자는 그 계약이 신뢰할 가치가 있는지 평가한다.

이 접근 방식은 의견 불일치를 더 생산적으로 만들 수도 있다. 제품, 보안, 엔지니어링 팀은 “유효하다” 같은 같은 단어를 쓰면서도 서로 다른 정의를 갖는 경우가 많다. 형식 명세는 이러한 정의를 눈에 보이는 조건으로 강제한다.

지식 업무도 같은 숨은 불변식 문제를 겪는다. 시장 분석에는 최신 출처, 정의된 지역, 고정된 보고 기간이 필요할 수 있다. 팀은 종종 이런 제약을 댓글, 회의 메모, 또는 한 직원의 기억에 남겨 둔다.

AI는 세련된 보고서를 생성하면서도 이런 제약 조건을 하나라도 조용히 위반할 수 있다. 더 나은 워크플로는 생성이 시작되기 전에 중요한 제약을 표현한다. 일부 조건은 자동화된 검사로 전환할 수 있고, 다른 조건은 명시적인 검토 질문으로 남는다.

이것이 AI 보조 업무에서 knowledge blending이 중요한 이유다. 생성된 결과물은 관련 기록, 결정, 증거와 연결된 상태를 유지할 때 평가하기가 더 쉬워진다. 검사는 Lean의 커널만큼 절대적이지는 않지만, 작동 원리는 비슷하다.

따라서 조직은 증명 자동화를 가장 단순하게 해석하려는 유혹을 경계해야 한다. 이점은 AI 결과물을 더 이상 검토하지 않아도 된다는 허가가 아니다. 더 가치 있는 계층에서 검토할 기회다.

증명 생성 비용은 낮아진다. 정확성을 정의하는 일은 더 중심적인 과제가 된다. 요구사항에 합의할 수 없는 팀은 Lean이나 AI 증명기를 추가해도 강력한 보장을 얻지 못할 것이다.

Lean 형식 검증이 이제 테스트만 의존하는 워크플로에 압박을 가한다

당장의 압박은 여전히 테스트를 자신들이 확보할 수 있는 최고 수준의 보증으로 여기는, 보안에 민감한 코드를 만드는 팀에 가해진다.

테스트는 실제 실행, 통합, 성능, 환경 동작을 평가하기 때문에 여전히 필수적이다. 형식 검증은 다른 질문을 다룬다. 증명이 포괄하는 모든 경우에서 모델이 특정 속성을 만족하는지 확인한다.

어느 한 방법이 다른 방법을 포괄하지는 않는다. Langley는 테이블 생성기의 더 넓은 속성을 증명하는 동시에 Zstandard 테스트 벡터를 일반적인 단위 테스트로 사용했다. 테스트는 호환성 사례를 확인했고, 정리는 보편적인 구조적 불변식을 다뤘다.

변화의 핵심은 경제성이다. 이전에는 형식 검증에 상당한 전문 인력이 필요했기 때문에 많은 팀이 그 이점을 평가하기도 전에 이를 배제할 수 있었다. AI가 증명 구성 시간을 줄인다면, 그런 자동적인 배제는 정당화하기가 더 어려워진다.

암호화 소프트웨어는 초기 검증 무대를 제공한다. 작은 산술 오류도 더 큰 보안 시스템을 무력화할 수 있으며, 많은 중요한 함수는 이미 수학적 명세를 갖고 있다. 보편적 보장의 가치는 특히 분명하다.

2026년 5월 경험 보고서는 프로덕션 암호화 코드를 Lean으로 변환하는 Rust 검증 파이프라인을 설명했다. 이 파이프라인은 Rust 추출 도구, 형식 명세 라이브러리, Aristotle 및 Aleph 같은 AI 증명기를 결합한다.

연구진은 이 파이프라인을 Plonky3와 RISC Zero의 구성 요소에 적용했다. 대상에는 필드 산술, Merkle 포함 검증, 다항식 평가, 영지식 시스템에서 사용되는 FRI 연산이 포함됐다. 제출된 모든 증명은 여전히 Lean의 커널을 통과했다.

논문은 엔지니어링 마찰도 기록한다. 툴체인 버전은 달라졌고, 변환 도구는 Rust의 일부만 지원했으며, 누락된 보조정리가 자동화를 가로막았다. AI 증명기는 일부 증명 의무를 해결했지만, 다른 일부는 여전히 수작업을 필요로 했다.

이 증거는 신중한 전망을 뒷받침한다. 검증은 전체 비즈니스 애플리케이션이 아니라 좁은 범위의 고가치 구성 요소를 통해 프로덕션에 들어갈 가능성이 크다. 팀은 파서, 권한 부여 규칙, 암호화 연산, 상태 전이 로직부터 시작할 수 있다.

이 구성 요소들은 세 가지 유용한 특성을 지닌다. 동작을 대체로 정확하게 명세할 수 있고, 실패 비용이 높으며, 현재 도구가 이해할 수 있을 만큼 경계가 작다.

압박은 AI 코딩 시스템을 판매하는 공급업체에도 미칠 것이다. 더 많은 코드를 생성하는 일은 점점 차별점이 되지 못하고 있다. 독립적으로 검증 가능한 속성을 지닌 코드를 생산하는 것은 더 강력한 주장을 만든다.

코딩 에이전트는 언젠가 서로 연결된 세 가지 산출물을 반환할 수 있다. 구현, 필요한 동작에 대한 형식적 명제, 그리고 커널이 검증한 증명이다. 검토자는 해당 명제가 제품 요구사항과 일치하는지에 집중할 수 있다.

테스트 중심 플랫폼은 사라지기보다 대응할 것이다. 퍼징, 속성 기반 테스트, 기호 실행, 증명의 결합이 더 강해질 것으로 예상된다. 생성된 테스트는 형식 모델과 복잡한 배포 환경 사이의 불일치를 계속 찾아낼 것이다.

형식 검증 공급업체도 압박을 받는다. 이들의 전통적 우위에는 희소한 증명 구성 전문성이 포함된다. AI는 반복적인 전술 작업의 가치를 낮추는 한편, 명세 설계, 통합, 보증 아키텍처에 대한 수요를 늘린다.

관리자는 이 변화를 즉각적인 채용 축소로 해석해서는 안 된다. 초기 도입은 대개 유지보수 업무를 없애기 전에 통합 업무를 만든다. 팀에는 애플리케이션 도메인과 증명 경계를 모두 이해하는 사람이 필요할 것이다.

따라서 유용한 질문은 Lean이 기존 프로그래밍을 대체하는지 여부가 아니다. 어떤 비용 큰 가정을 이제 주석과 검토 체크리스트에서 기계가 강제하는 계약으로 옮길 수 있는지가 핵심이다.

Zstandard 결과가 증명하지 못하는 것

공개되지 않은 단일 토이 디코더만으로는 현재 AI 증명기가 프로덕션 리포지터리, 빈번한 변경, 명세가 부실한 시스템 전반에서 확장 가능하다는 점을 입증할 수 없다.

Langley는 이런 한계를 직접 밝혔다. 그의 디코더는 자신의 머신에서 zstd 명령보다 약 10배 느리게 실행됐다. 또한 수정된 가정이 파생 타입 전체로 전파되기 때문에 강한 타입이 변경의 영향을 증폭할 수 있다고 경고했다.

그러한 전파는 이점이 될 수 있다. 주의가 필요한 모든 종속 구성 요소를 드러내기 때문이다. 하지만 작은 제품 변경도 대규모 증명 유지보수 프로젝트로 바꿀 수 있다.

성능은 또 다른 절충을 만든다. Lean은 객체에 참조가 하나만 있을 때 제자리 업데이트를 할 수 있다. 따라서 다른 참조를 유지하는 사소한 코드 변경도 기능적 정확성은 바꾸지 않은 채 성능을 저하시킬 수 있다.

증명 자동화는 이런 회귀를 자동으로 감지하지 않는다. 정리에 적절한 성능 모델을 포함하거나, 다른 벤치마크가 이를 포착해야 한다. 정확성과 효율성은 여전히 별개의 엔지니어링 주장이다.

리포지터리 규모는 가장 중요한 과제다. Langley의 사례는 집중된 구현과 인접 정의에 연결된 정리를 갖고 있었다. 프로덕션 시스템은 패키지, 생성 코드, 빌드 구성, 데이터베이스, 외부 서비스에 걸쳐 의미가 분산된다.

2026년 VeriSoftBench 연구는 23개 오픈 소스 Lean 리포지터리의 증명 의무 500개를 사용해 이 문제를 테스트했다. 이 연구의 리포지터리 벤치마크는 프로젝트별 정의와 파일 간 종속성을 보존했다.

연구진은 수학 중심 Lean 작업으로 학습된 증명기가 리포지터리 중심 소프트웨어 검증으로는 제대로 전이되지 않는다는 사실을 발견했다. 증명이 더 길고 여러 단계로 이어진 로컬 정의 체인에 의존할수록 성능은 저하됐다.

신중하게 선택한 컨텍스트를 제공하면 전체 리포지터리를 노출하는 방식보다 결과가 개선됐다. 그러나 여전히 상당한 개선 여지가 남았다. 컨텍스트 검색은 도움이 됐지만 추론 문제를 해결하지는 못했다.

이 발견은 Langley의 주장을 가장 강하게 해석하는 데 직접적인 한계를 둔다. LLM은 오늘날 의미 있는 소프트웨어 증명을 생성할 수 있다. 그러나 프로젝트가 Lean을 사용한다는 이유만으로 모든 증명 의무를 처리할 수 있는 것은 아직 아니다.

공개된 실험에는 검증 공백도 있다. 독자는 Langley의 설명, 정리 명제, 주의 사항을 검토할 수 있다. 하지만 그가 디코더나 증명 파일을 공개하지 않았기 때문에 완전한 결과를 재현할 수는 없다.

sorry 선언이 남아 있지 않았다는 그의 확인은 유용한 1차 증거다. 그러나 고정된 리포지터리에서 독립적으로 빌드한 결과와 같지는 않다. 이 결과는 벤치마크가 아니라 신뢰할 만한 엔지니어링 보고서로 다뤄야 한다.

보안 팀은 신뢰 컴퓨팅 기반도 검토해야 한다. Lean의 커널은 의도적으로 작게 설계됐고, 독립적인 커널 구현체로 결과를 비교할 수 있다. 하지만 배포 환경은 여전히 컴파일러, 런타임 동작, 하드웨어, 그리고 모든 외부 모델의 정확성에 의존한다.

시스템은 Lean 함수가 Lean 명세를 충족한다는 점을 증명할 수 있다. 최적화된 네이티브 코드가 그 의미론을 보존한다는 점을 보이려면 추가 작업이 필요하다. Langley는 검증된 어셈블리를 하나의 가능한 방향으로 제시했다.

이 한계들이 결과를 무효화하지는 않는다. 그 위치를 규정할 뿐이다. Lean 증명 자동화는 속성을 정확하게 명시할 수 있고 종속성이 사용 가능한 컨텍스트 안에 들어오는 제한된 구성 요소에서 유용해 보인다.

이는 형식 증명이 항상 전문가가 모든 단계를 수작업으로 만들어야 한다는 오래된 가정보다 이미 더 실용적이다. 그러나 생성된 소프트웨어를 위한 범용 “검증” 버튼과는 아직 거리가 멀다.

증명 자동화가 실제로 도래했는지를 보여줄 세 가지 신호

다음 단계는 재현성, 리포지터리 규모의 유지보수, 그리고 일반적인 엔지니어링 워크플로 내 도입에 달려 있다.

첫 번째 신호는 Langley의 패턴과 일치하는 공개적이고 재현 가능한 구현이다. 여기에는 소스 코드, 정리 명제, 생성된 증명, 고정된 종속성, 그리고 해결되지 않은 구멍을 거부하는 자동화된 빌드가 포함돼야 한다.

공개 산출물은 독립 팀이 증명 시간, 모델 의존성, 유지보수 비용을 측정하게 해 줄 것이다. 또한 초기 구현과 승인된 증명 사이에 사람의 개입이 얼마나 있었는지도 드러낼 것이다.

여러 팀이 파서나 압축 라이브러리에서 이 워크플로를 재현한다면 Langley의 결론은 더 강해진다. 결과가 광범위한 비공개 프롬프팅이나 수작업 재구성에 의존한다면, 현재의 생산성 주장은 약화된다.

두 번째 신호는 변화하는 리포지터리에서의 성능이다. 유용한 시스템은 일반적인 리팩터링, 종속성 업데이트, 변경된 요구사항 이후에도 증명을 복구해야 한다. 정리를 한 번 푸는 것보다 릴리스 전반에 걸쳐 계속 해결된 상태로 유지하는 일이 더 가치 있다.

따라서 리포지터리 규모 벤치마크에는 종단적 과제를 추가해야 한다. AI 증명기는 연속된 커밋을 받아 원래 명세를 보존하면서 영향을 받은 증명을 복구할 수 있다. 팀은 승인된 복구, 경과 시간, 컴퓨팅 사용량, 사람의 편집을 추적해야 한다.

밀집된 로컬 종속성에서의 개선은 VeriSoftBench가 확인한 약점을 해소할 것이다. 지속적인 실패는 AI 증명을 신중하게 선별된 컨텍스트를 갖춘 작은 모듈에 한정할 것이다.

세 번째 신호는 주류 코딩 에이전트와 지속적 통합 시스템으로의 통합이다. 풀 리퀘스트가 필요한 불변식을 명시하고, 증명을 생성하며, Lean이 이를 자동으로 검증할 수 있을 때 증명 자동화는 운영 단계에 진입한다.

이 과정에는 투명한 실패 모드도 필요하다. 증명을 찾지 못하는 모델은 컨텍스트 부족, 어려운 정리, 호환되지 않는 코드, 거짓 명제 중 무엇이 원인인지 구분해야 한다. 그렇지 않으면 팀은 또 하나의 불투명한 실패 빌드를 받게 된다.

도입은 조직이 이미 정확한 요구사항을 작성하는 분야에서 시작될 가능성이 크다. 암호학, 프로토콜 구현, 컴파일러, 금융 통제, 접근 제어 시스템이 이에 해당한다. 더 광범위한 비즈니스 소프트웨어는 더 느리게 움직일 것이다.

지식 노동자도 자신이 사용하는 도구에서 같은 패턴을 지켜봐야 한다. 신뢰할 수 있는 자동화에는 명시적인 입력, 수용 규칙, 추적 가능한 증거, 그리고 결과를 거부할 권한을 가진 검사기가 필요하다.

대부분의 사무 업무는 수학적 확실성에 도달할 수 없다. 그래도 더 좁은 게이트를 도입할 수는 있다. 연구 브리프는 날짜가 명시된 출처를 요구할 수 있다. 영업 분석은 모든 계정 주장이 고객 기록에 매핑되도록 요구할 수 있다. 프로젝트 업데이트는 최근 업무로 뒷받침되지 않는 진술에 플래그를 지정할 수 있다.

이러한 변화는 AI를 검증되지 않은 작성자에서 통제된 프로세스 안에서 작동하는 후보 생성기로 바꾼다. 사람은 경계를 정의하고 검사가 포괄하지 못하는 부분을 검토할 책임을 유지한다.

Lean 증명 자동화는 검사기가 정확하기 때문에 그 미래를 가장 명확하게 보여준다. 모델은 탐색 중에 일관성이 없거나, 장황하거나, 반복해서 틀릴 수 있다. 유효한 증명만이 프로그램에 도달한다.

앞으로 몇 달간의 질문은 LLM이 형식 증명을 하나라도 생성할 수 있는지가 아니다. 이미 가능하다. 질문은 팀이 과거의 10배 노동 부담을 되살리지 않고도 실제 요구사항을 유지보수 가능한 기계 검증 소프트웨어로 반복해서 전환할 수 있는지다.

워크플로에서 비용이 많이 드는 가정 하나를 골라, 그것이 검증 가능하게 참이 되기 위해 필요한 조건을 적어보세요. 그 조건을 확인할 수 있다면, 더 많은 결과물을 자동화하기 전에 그 확인 과정을 자동화하세요. 이것이 Langley의 실험이 주는 실질적인 교훈이며, 이제 자동화가 충족해야 할 기준입니다.