Lean 증명 자동화가 실제 소프트웨어 시험을 통과했지만, 증명은 아직 프로덕션 준비가 되지 않았다

Lean 증명 자동화는 7월 26일 중요한 경계를 넘었다. 아직 프로덕션 소프트웨어 출시와는 거리가 멀지만 말이다. 보안 엔지니어 Adam Langley는 Lean으로 작동하는 Zstandard 압축 해제기를 만들고, 여러 대규모 언어 모델을 사용해 가장 어려운 로직 주변의 기계 검증 증명을 생성했다.

이 실험이 더 빠른 압축 해제기나 공개 라이브러리를 내놓은 것은 아니며, AI가 대규모 애플리케이션을 검증할 수 있다는 증거도 아니다. Langley에 따르면 그의 버전은 표준 zstd 명령보다 약 10배 느리게 실행된다. 그는 이 구현을 학습 프로젝트라고 설명했으며, 코드는 공개하지 않기로 했다.

변화는 더 제한적이지만, 더 중요한 의미를 지닌다. AI 시스템이 결코 단순하지 않은 소프트웨어를 위한 증명을 만들었고, Lean은 그 증명이 유효한지를 독립적으로 확인했다. 이는 AI 보조 검증을 유창한 설명과 그럴듯한 코드의 수준에서 벗어나, 유난히 엄격한 통과 기준을 갖춘 워크플로로 옮겨 놓는다.

이제 핵심 경쟁 구도는 AI가 생성한 코드와 사람이 작성한 코드 사이가 아니다. 확률적 생성과 결정론적 검증의 대결이다. 모델은 추측하고, 수정하고, 반복적으로 실패할 수 있지만, 작은 신뢰 기반 검사기는 완성된 프로그램에 무엇이 들어갈지를 결정한다.

개발자에게 이 패턴은 신뢰하기 어려운 코딩 에이전트에 대한 하나의 해답을 제시한다. 지식 노동자에게는 자동화의 더 넓은 모델을 시사한다. AI가 지저분한 첫 시도를 만들게 하되, 결과의 채택은 명시적이고 기계적으로 검증 가능한 조건에 달리게 하는 방식이다.

Zstandard 실험은 증명 자동화를 구체적인 현실로 만들었다

Langley의 테스트가 중요한 이유는 AI가 생성한 증명을 또 하나의 고립된 수학 벤치마크가 아니라 일반적인 시스템 소프트웨어에 적용했기 때문이다.

Lean은 프로그래밍 언어이자 대화형 정리 증명기다. 종속 타입을 통해 프로그램의 타입에 값에 관한 사실을 포함할 수 있다. 예를 들어 배열의 정확한 길이 또는 여러 출력값 간의 관계를 타입으로 표현할 수 있다.

이 기능은 함수 시그니처가 보장할 수 있는 내용을 바꾼다. 일반적인 파일 읽기 함수는 바이트 배열을 반환할 수 있다. Lean 함수는 요청한 바이트 수와 길이가 일치한다는 증명과 함께 배열을 반환할 수 있다.

공식 Lean reference는 이 아키텍처가 AI 생성 작업에 특별한 가치를 지니는 이유를 설명한다. Lean 전술은 복잡하고 자동화될 수 있지만, 전술이 생성하는 모든 증명 항은 비교적 작은 커널을 거친다.

결함 있는 전술은 시간을 낭비하거나 유효하지 않은 후보를 생성할 수 있다. 그러나 신뢰 기반 자체에도 결함이 있지 않은 한, 유효하지 않은 증명을 유효하게 만들 수는 없다. 최종 권한은 생성기가 아니라 검사기에 남는다.

Langley는 의미 있는 구현 과제를 제공한다는 이유로 Zstandard를 선택했다. 일반적으로 zstd로 불리는 Zstandard는 LZ77 방식의 매칭과 두 가지 엔트로피 코딩 시스템을 기반으로 하는 무손실 압축 형식이다.

형식 사양은 리터럴 데이터에는 Huffman 코딩을, 다른 심볼과 Huffman 헤더에는 Finite State Entropy, 즉 FSE를 사용한다고 규정한다. FSE는 심볼 사이에 상태를 유지하므로 비트스트림을 기록 순서의 역순으로 디코딩해야 한다.

이 메커니즘은 짧은 산술식 두 개가 같다는 사실을 증명하는 것보다 훨씬 까다롭다. 압축 해제기는 밀도 높은 이진 구조를 파싱하고, 상태를 유지하며, 유효하지 않은 입력을 거부하고, 원래 바이트를 정확히 복원해야 한다.

Langley의 Lean 실험은 특히 FSE 테이블 구성에 주목했다. 이 테이블은 압축된 상태가 심볼로 어떻게 되돌아가는지와 디코더가 몇 비트를 소비하는지를 결정한다.

보도에 따르면 여러 LLM은 약 20분 만에 이 테이블 생성 코드의 중요한 속성에 대한 증명을 만들었다. Langley는 결과 증명이 Lean의 타입 검사기를 통과했으며, 증명되지 않은 명제를 임시로 인정하는 Lean의 메커니즘인 sorry 선언을 포함하지 않는지 확인했다.

모델들은 일부 구현 선택도 변경해야 했다. Langley는 알고리즘 일부를 더 명령형 스타일로 표현하기 위해 Id.run을 사용했는데, 이는 증명 메커니즘의 사용을 더 어렵게 만들었다.

이 세부 사항은 결과를 단순하게 해석하는 것을 막는다. AI는 고정된 코드를 살펴보고 인증서를 덧붙인 데 그치지 않았다. 증명 구성을 지원하는 형태로 구현 자체를 재구성하는 데도 기여했다.

그럼에도 이 결과는 완전한 루프를 만들었다. 의미 있는 소프트웨어를 작성하고, 강력한 불변식을 명시하고, 증명을 생성한 뒤, 독립적인 커널에 이를 수용하거나 거부하도록 요청하는 루프다. 진정한 사건은 이 루프다.

Lean 증명 자동화는 검증 비용 문제를 겨냥한다

형식 검증은 이전에도 탁월한 보장을 제공했지만, 증명 작업의 부담 때문에 대부분의 일상적인 소프트웨어 프로젝트에는 적용되지 못했다.

가장 분명한 역사적 사례는 기계 검증 증명으로 뒷받침되는 소형 운영체제 커널 seL4다. 검증된 속성은 선택된 입력 집합에서 테스트를 통과하는 수준을 훨씬 넘어선다.

초기 검증에는 4년에 걸쳐 약 20인년이 필요했고, 20만 줄이 넘는 Isabelle 증명 스크립트가 만들어졌다. seL4 연구에 소개된 회고는 이러한 수치가 학문적 과잉으로 치부될 수 없는 이유를 보여준다.

검증 팀은 올바른 속성을 정의하고, 서로 다른 추상화 계층을 연결하며, 증명을 구성하고, 변화하는 코드에 맞춰 증명을 유지해야 한다. 각 작업에는 전문 지식과 세심한 엔지니어링이 필요하다.

보상은 상당할 수 있다. seL4 프로젝트는 주요 증명이 완료된 2009년 이후 검증된 코드에서 기능적 정확성 결함이 발견되지 않았다고 보고한다. 그러나 대부분의 소프트웨어 팀은 단일 컴포넌트를 출시하기 전에 수년간 전문 인력을 투입할 수 없다.

전통적인 증명 자동화는 이런 부담의 일부를 줄인다. 전술은 익숙한 패턴을 해결할 수 있고, SMT 솔버로 알려진 만족도 모듈로 이론 솔버는 지원되는 영역의 논리 조건을 처리한다.

이 시스템들은 프로그래머가 검증된 코드를 작성하는 방식에도 영향을 미친다. 숙련된 사용자는 솔버가 처리할 수 있는 형식과, 겉보기에 무해해도 탐색 공간을 통제할 수 없이 확장시키는 구조를 구분하는 법을 배운다.

Langley는 LLM이 유연한 증명 생성기이기 때문에 이러한 경제성을 바꾼다고 주장한다. LLM은 주변 정의를 읽고, 오류 메시지를 검토하고, 로컬 코드를 다시 작성하고, 중간 보조정리를 제안하며, 거부된 뒤 다른 경로를 시도할 수 있다.

증명 비관련성은 이 주장을 강화한다. Lean에서 명제는 증명 비관련적 우주에 존재한다. 즉 시스템은 일반적으로 유효한 증명이 존재하는지를 중요하게 여기며, 어떤 유효한 증명이 제공됐는지는 중요하게 여기지 않는다.

인간 증명 엔지니어는 명확한 증명이 이후 변경에도 더 쉽게 살아남을 수 있기 때문에 종종 우아함을 중시한다. LLM이 검증된 증명을 빠르게 재생성할 수 있다면, 유지보수에 관한 이러한 판단도 일부 달라진다.

그렇다고 증명 엔지니어링이 사라지는 것은 아니다. 누군가는 여전히 올바른 정리를 명시하고, 신뢰 경계를 정의하며, 변경마다 재생성하는 비용이 감당 가능한지를 판단해야 한다.

하지만 이는 한 가지 큰 반론을 약화한다. 개발자가 동작을 자신 있게 평가할 수 없을 때 보기 흉한 생성 코드는 위험하다. 반면 신뢰할 수 있는 커널이 유효하지 않은 모든 버전을 거부한다면, 보기 흉한 생성 증명은 덜 우려스럽다.

새롭게 떠오르는 워크플로는 협업적 추론보다 컴파일에 더 가깝다. 개발자는 속성을 명시하고, 에이전트는 수용 가능한 산출물을 탐색하며, 검사기는 빌드 성공 여부를 결정한다.

AI가 어디에 적합한지 판단하는 관리자에게 이 차이는 중요하다. 함수가 안전하다고 말하는 코딩 어시스턴트는 의견을 제공한다. 커널 검증 산출물을 반환하는 증명 생성 어시스턴트는 선언된 가정 아래에서 증거를 제공한다.

이 구분은 새로운 병목도 드러낸다. 증명 생성 비용이 낮아진다면, 올바른 명세를 작성하는 일이 희소한 역량이 된다.

팀에는 요구사항을 정밀한 불변식으로 옮길 수 있는 사람이 필요하다. “이 파서는 안전해야 한다”는 검증할 수 없다. “성공한 모든 파싱은 제공된 입력 버퍼 범위 안에 머문다”는 형식 시스템이 평가할 수 있는 속성에 더 가깝다.

지식 노동자에게 이에 해당하는 일은 자동화가 시작되기 전에 수용 조건을 정의하는 것이다. AI는 예측을 초안으로 작성하거나, 정책을 조정하거나, 회의 메모를 병합할 수 있지만, 신뢰할 수 있는 자동화에는 반드시 참이어야 할 것이 무엇인지에 대한 명확한 설명이 필요하다.

새로운 상대는 검증 없는 생성이다

가장 강력한 교훈은 LLM이 신뢰할 수 있게 되었다는 점이 아니라, 신뢰하기 어려운 생성도 신뢰할 수 있는 검사 루프 안에서는 유용해질 수 있다는 점이다.

대부분의 생성형 AI 제품은 사용자에게 결과물을 직접 판단하도록 요구한다. 모델은 이메일을 작성하고, 회의를 요약하고, 스프레드시트를 편집하거나, 코드를 제안한다. 그러면 사람은 제한된 시간과 주의를 들여 미묘한 오류를 찾아야 한다.

이 패턴은 저위험 업무에는 자동화를 매력적으로 만들지만, 보안, 금융, 규정 준수, 인프라, 되돌릴 수 없는 운영 변경에는 신뢰하기 어렵게 만든다. 유창한 언어가 정확성을 입증하지는 않기 때문에 모델의 자신감은 거의 보호막이 되지 않는다.

Lean 증명 자동화는 두 가지 일을 분리한다. LLM은 가능한 증명의 광대한 공간을 탐색하고, 증명 보조기는 정확한 규칙에 따라 좁은 검증 작업을 수행한다.

생성기는 정리 이름을 환각하거나, 유효하지 않은 변환을 적용하거나, 정의를 오해할 수 있다. 주장하는 속성과 신뢰 경계가 건전하다면, 이런 실패는 수용된 결론이 아니라 거부된 후보가 된다.

최근 연구는 이 분리를 기반으로 구축된 시스템을 가리킨다. 2026년 7월 공개된 OpenProver는 계획 수립, 작업자 에이전트, Lean 검증을 오픈소스 정리 증명 시스템으로 결합한다.

이 아키텍처는 전문 에이전트에 서로 다른 책임을 부여하면서도 자동 형식 검사를 유지한다. 또한 증명 탐색이 여전히 전문가의 방향 설정에서 이득을 얻는다는 점을 인정하며, 인간의 개입도 지원한다.

이는 코드 창이 있는 챗봇과는 다른 제품 모델이다. 가치 있는 산출물은 증명이 왜 작동해야 하는지에 대한 모델의 설명이 아니다. 독립적인 검사를 통과하는 증명 객체다.

완전한 정리 증명이 필요하지 않은 경우에도 유사한 패턴은 일반적인 지식 업무를 개선할 수 있다. 예를 들어 제품 관리자가 인터뷰, 티켓, 지표, 결정 사항을 바탕으로 주간 업데이트를 작성한다고 생각해 보자.

LLM은 업데이트 초안을 빠르게 만들 수 있다. 그러나 모든 사실 주장은 출처까지 추적 가능해야 하고, 모든 지표는 날짜와 정의를 유지해야 하며, 해결되지 않은 모순은 계속 드러나 있어야 한다.

개인 지식 시스템은 이러한 연결을 보존하는 데 도움이 될 수 있다. 예를 들어 knowledge blending은 사용자가 흩어진 파일에서 자료를 다시 구성하도록 강요하는 대신, 관련 로컬 자료를 하나의 작업 맥락으로 가져올 수 있다.

이는 수학적 증명과 같지 않다. 검사기는 출처 인용, 스키마 검증, 접근 제어, 산술 테스트 또는 인간의 승인 단계로 구성될 수 있다.

그러나 아키텍처 원칙은 비슷하게 유지된다. 생성의 자유는 관문 앞에 있어야 한다. 결정론적 규칙, 문서화된 증거 또는 책임 있는 검토가 무엇을 통과시킬지 결정한다.

이는 팀이 AI 생산성을 평가하는 방식도 바꾼다. 초안 작성에서 절약한 시간은 하나의 지표일 뿐이다. 검토 시간, 수정 빈도, 결함 유출률, 뒷받침 증거의 품질도 그만큼 중요하다.

10배 빠르게 초안을 작성하지만 검토 노력을 두 배로 늘리는 에이전트는 업무를 자동화한 것이 아니다. 단지 일을 덜 눈에 띄는 단계로 옮겼을 뿐이다.

반대로, 완전한 출처 정보와 자동 검증을 갖춘 더 느린 첫 결과를 내놓는 에이전트가 더 유용한 생산성을 제공할 수 있다. 근거는 이후의 모든 독자가 느끼는 불확실성을 줄인다.

Lean에서는 수용 조건이 이진적이기 때문에 이 원칙이 유난히 분명하게 드러난다. 증명은 검사에 통과하거나, 통과하지 못한다. 대부분의 사무 자동화에는 이처럼 명확한 경계가 없지만, 팀은 더 작고 작업별로 특화된 게이트를 만들 수 있다.

재무 요약에는 모든 합계가 원본 셀과 일치하도록 요구할 수 있다. 계약 비교에는 표시된 모든 차이가 정확한 조항으로 연결되도록 요구할 수 있다. 리서치 브리프는 근거 없는 인용문이 최종 문서에 포함되지 못하게 할 수 있다.

이러한 게이트가 기반 모델을 정직하거나 결정론적으로 만들지는 않는다. 대신 모델의 약점을 더 쉽게 통제할 수 있게 해준다.

Zstandard 테스트가 증명하지 않는 것

이 실험은 유망한 메커니즘을 검증하지만, AI가 대규모 프로덕션 시스템을 저렴하고 완전하게 검증할 수 있음을 입증하지는 않는다.

가장 분명한 한계는 범위다. Langley는 이 디컴프레서를 장난감 수준이라고 부르고, 코드가 공개되지 않았으며, 다른 Lean 프로그래머를 위한 모범 사례로 제시하는 것도 아니라고 말한다.

이 때문에 독립 검토자는 결과를 재현하거나, 정확한 정리 문장을 검토하거나, 검증되지 않은 구성 요소를 식별할 수 없다. 저자의 보고에 따르면 선택된 증명들이 타입 검사에 통과했다는 사실만 알 수 있다.

하지만 그 문장들이 프로덕션 디컴프레서에 필요한 모든 속성을 포괄하는지는 알 수 없다. 불완전한 명세에 대한 완벽하게 유효한 증명이 그 명세 밖의 심각한 결함과 공존할 수 있다.

이는 흔히 명세 문제라고 불린다. 검사기는 코드가 형식적 문장을 만족하는지 입증할 수 있지만, 사람이 올바른 문장을 선택했는지는 판단할 수 없다.

디컴프레서는 유효한 입력이 올바르게 왕복 처리된다는 점을 증명하면서도, 메모리 고갈, 서비스 거부 동작, 리소스 제한, 아카이브 파싱을 정리의 범위 밖에 둘 수 있다. 누락된 경계 하나하나가 실패 가능성을 만든다.

신뢰할 수 있는 컴퓨팅 기반도 중요하다. Lean의 작은 커널은 신뢰해야 하는 구성 요소를 크게 줄이지만, 실제 프로그램은 컴파일러, 운영체제, 외부 함수, 하드웨어, 외부 라이브러리와 상호작용한다.

Langley는 Lean의 extern 메커니즘을 통해 최적화된 어셈블리를 호출하는 방식을 탐구했다. 작은 동치성 예제는 작동했지만, 접근 방식을 확장하려는 시도는 심각한 메모리 요구량에 부딪히거나 진행되지 못한 것으로 전해진다.

이 결과는 핵심적인 트레이드오프를 부각한다. 고수준 검증 코드는 강력한 논리적 보장을 제공할 수 있지만, 프로덕션 성능은 흔히 직접적인 증명 범위를 벗어난 저수준 구현과 도구에 의존한다.

Zstandard 구현 자체도 이 격차를 보여준다. Langley는 자신의 Lean 디코더가 표준 명령줄 구현보다 약 10배 느리다고 보고한다.

성능은 압축 소프트웨어에서 사소한 문제가 아니다. 압축 해제는 흔히 스토리지, 패키지 배포, 데이터베이스, 네트워크 전송과 관련된 지연 시간 민감 경로에 위치한다.

증명 유지보수 역시 여전히 불확실하다. Langley는 빠른 재생성이 향후 변경을 위해 증명을 신중하게 설계해야 할 필요를 줄일 수 있다고 제안한다.

제한된 프로젝트에서는 그럴듯하다. 대규모 코드베이스는 수천 개의 상호 의존적 의무를 만들 수 있으며, 작은 타입 변경이 모듈 전반으로 확산되어 에이전트의 컨텍스트나 탐색 예산을 압도할 수 있다.

연구 벤치마크만으로 이 문제를 결론지어서는 안 된다. 수학 정리 모음은 일반적으로 명시적인 목표와 통제된 환경을 제공한다. 프로덕션 코드에는 부분 명세, 레거시 인터페이스, 변화하는 의존성, 문서화되지 않은 가정이 포함된다.

인적 요인 측면의 위험도 있다. 손쉬운 증명 생성은 초록색 체크 표시 하나를 포괄적인 보증으로 취급하게 하는 압박을 만들 수 있다.

검사된 정리는 형식적 문장이 정확히 말하는 것만을 보장한다. 해당 속성이 모델에 포함되지 않는 한 보안, 개인정보 보호, 신뢰성, 비즈니스 정확성에 대해 아무런 보장을 제공하지 않는다.

따라서 팀은 현재 코드 리뷰에 부여하는 수준의 엄중함으로 명세를 검토해야 한다. 그렇지 않으면 AI는 불완전한 질문에 대한 그럴듯한 답을 생산하는 속도만 높일 것이다.

AI 증명 자동화는 병목을 명세로 옮긴다

모델이 유능한 증명 생성기가 된다면, 가치 있는 지식 노동은 산출물 구축에서 주장과 경계 정의로 이동한다.

소프트웨어 팀은 이미 이러한 전환의 한 형태를 경험했다. 코딩 에이전트는 함수, 테스트, 마이그레이션, 문서를 만드는 비용을 낮춘다.

산출물이 저렴해질수록 무엇을 만들어야 하는지를 결정하는 일이 더 중요해진다. 요구사항, 인터페이스, 제약 조건, 위협 모델, 인수 테스트는 빠른 생성이 가치를 만들지, 아니면 검토할 자료만 더 늘릴지를 결정한다.

Lean은 이 변화를 정확성 주장으로 확장한다. 프로그래머는 타입에 불변 조건을 인코딩하고, LLM에 증명 구성을 요청한 뒤, 커널이 결과를 검증하게 할 수 있다.

가장 큰 영향력을 갖는 인간의 기여는 흔히 상류 단계에 있다. 누군가는 어떤 불변 조건이 중요한지 파악하고, 허점 없이 표현하며, 실제 운영 환경에 매핑해야 한다.

지식 노동자도 덜 형식적인 도구로 같은 구조에 직면한다. 분석가는 시장 주장에 어떤 증거가 적합한지 결정해야 한다. 채용 담당자는 어떤 후보자 기준이 합법적이고 관련성이 있는지 정의해야 한다.

지원 관리자는 자동 응답을 언제 보낼 수 있고 언제 사례를 에스컬레이션해야 하는지 명시해야 한다. 연구자는 직접 출처, 2차 요약, 근거 없는 추론을 구분해야 한다.

아무도 이를 Lean으로 작성하지 않더라도, 이는 명세 작업이다. 모호한 기대를 관찰 가능한 조건으로 바꾼다.

조직은 자신이 관리하는 문서와 함께 의사결정 규칙을 기록함으로써 대비할 수 있다. “최신 고객 수를 사용하라”는 메모는 모호하다. 권위 있는 대시보드, 갱신 시각, 지역, 보고 기간을 명시하는 규칙은 테스트할 수 있다.

출처 정보도 똑같이 중요해진다. 원본 자료가 날짜, 소유자, 버전, 이전 결정과의 관계를 잃어버린다면 모델은 팀의 지식을 신뢰성 있게 조정할 수 없다.

이것이 채팅 인터페이스에서 에이전트 시스템으로의 이동에 더 나은 정보 아키텍처가 필요한 이유다. 에이전트에는 구조화된 컨텍스트, 권한, 검증 규칙, 자신이 변경한 내용을 남기는 지속적인 기록이 필요하다.

인간 검토 역시 예외 사항 중심으로 이동해야 한다. AI가 생성한 모든 문장을 한 줄씩 검사해야 한다면, 시스템은 자동화 계층이 아니라 보조 도구에 머문다.

유용한 게이트는 명시된 조건을 충족하는 일상적인 사례를 자동 승인할 수 있다. 그러면 인간은 누락된 증거, 상충하는 출처, 이례적인 값, 보안에 민감한 조치, 알려진 패턴 밖의 변경에 집중하게 된다.

형식 증명 보조기는 이 워크플로의 가장 강력한 형태를 제공하지만, 모든 작업에 적합하지는 않다. 많은 결정은 판단, 논쟁의 여지가 있는 정의, 불완전한 정보에 의존한다.

목표는 모든 이메일을 형식화하는 것이 아니다. 실패가 실질적인 비용을 초래하는 주장을 식별하고, 그 주변에 균형에 맞는 검사를 구축하는 것이다.

소프트웨어에서는 파서의 경계 안전성을 증명하는 한편 사용자 인터페이스는 전통적인 방식으로 테스트하는 것을 의미할 수 있다. 운영 팀에서는 결제 총액을 자동 조정하되 이체에는 인간 승인을 요구하는 방식일 수 있다.

연구자에게는 모든 인용과 인용문을 검증하되 해석은 토론에 열어두는 방식일 수 있다. 검증은 가장 중요한 경계를 보호해야 한다.

Langley의 실험은 이러한 설계 전략을 더 쉽게 상상하게 한다. LLM이 흠 없는 수학자가 될 필요는 없었다. 더 엄격한 시스템이 평가할 수 있는 산출물을 생성하면 됐다.

이는 모델이 실수를 멈출 때까지 기다리는 것보다 기업 AI를 위한 더 현실적인 경로다.

전환이 현실인지 보여줄 세 가지 신호

다음 단계는 또 하나의 인상적인 일회성 증명이 아니라 재현성, 규모, 측정 가능한 유지보수 비용에 달려 있다.

첫 번째 신호는 일반적인 검증 소프트웨어의 공개되고 재현 가능한 코퍼스다. Langley의 디컴프레서는 소스와 증명을 이용할 수 없기 때문에 이 역할을 할 수 없다.

lean-zip 같은 프로젝트는 더 검토하기 쉬운 참고 사례를 제공한다. Lean 공동 창시자 Leonardo de Moura는 최근 압축과 압축 해제를 모두 구현한 검증된 압축 프로젝트로 이를 소개했다.

향후 프로젝트에는 정확한 정리 문장, 문서화된 가정, 성능 측정, 기존 구현과의 비교 테스트가 필요하다. 독립 팀은 각 증명을 다시 빌드하고 어떤 모듈이 검증 경계 밖에 남아 있는지 식별할 수 있어야 한다.

여러 프로젝트가 파서, 네트워킹 코드, 스토리지 형식, 암호화 지원 전반에서 이 패턴을 반복한다면 Lean 증명 자동화의 근거는 더 강해질 것이다. 결과가 작은 시연에 계속 집중된다면 더 광범위한 주장은 약해진다.

두 번째 신호는 실제 코드 변경 이후 증명 생성이 어떻게 작동하는지다. 초기 증명 구성은 관심을 끌지만, 경제성이 성립하는지는 유지보수가 결정한다.

팀은 리팩터링, 의존성 업그레이드, 명세 변경, 성능 최적화 이후의 재생성 시간을 측정해야 한다. 또한 인간 전문가가 코드를 재구성하거나 중간 보조정리를 고안해야 하는 빈도도 기록해야 한다.

안정적인 정리에서 빠르게 성공하는 것은 살아 있는 애플리케이션에 관한 제한적인 증거만 제공한다. 유용한 시스템은 모든 풀 리퀘스트를 예측 불가능한 증명 탐색 프로젝트로 만들지 않고도 수개월간의 일상적인 개발을 견뎌야 한다.

증명 비용이 제한된 범위에 머물고 실패가 실행 가능한 진단 정보를 제공한다면, AI 생성 검증은 지속적 통합에 들어갈 수 있다. 작은 변경이 불투명한 탐색에 몇 시간씩 걸리게 한다면 도입은 제한적일 것이다.

세 번째 신호는 주류 코딩 에이전트로의 통합이다. 현재 증명 생성은 연구 워크플로와 전문 Lean 환경에 가까이 머물러 있다.

실질적인 변곡점은 에이전트가 불변 조건을 제안하고, 그 범위를 설명하며, 증명을 생성하고, 검사기를 실행하고, 어떤 가정이 여전히 검증되지 않았는지 정확히 보여줄 수 있을 때 도래한다.

그 인터페이스는 잘못된 확신을 막아야 한다. 테스트된 동작과 증명된 동작, 검증된 모듈과 검증되지 않은 래퍼를 구분해야 한다.

또한 정리 변경을 매우 눈에 띄게 만들어야 한다. 에이전트는 사용자가 보존되기를 기대한 속성을 몰래 약화해 실패한 증명을 “수정”해서는 안 된다.

지식 노동자에게 이러한 신호는 간단한 조달 기준으로 바뀐다. AI 제품이 답을 생성하는지, 아니면 강제 가능한 수용 조건을 갖춘 답을 생성하는지 물어야 한다.

소스 수준의 출처 정보, 권한 검사, 구조화된 검증, 재현 가능한 변환, 명확한 에스컬레이션 경로를 찾아야 한다. 그러한 통제가 없는 매끄러운 응답은 아무리 자신감 있게 들리더라도 초안에 불과하다.

Lean 증명 자동화는 AI가 이제 스스로 신뢰할 수 있다는 증거가 아니다. 주장이 명시적이고 검증이 독립적으로 유지될 때 AI 주변에 신뢰를 설계할 수 있다는 증거다.

다음 프로젝트를 위한 질문은 실용적이다. 어떤 반복적 의사결정이 실제 수용 게이트를 정당화할 만큼 충분한 위험을 만드는가? 거기서 시작해 반드시 참이어야 하는 것을 정의하고, 자동화가 모든 초록색 체크 표시를 얻어내게 하라.