Lean 증명 자동화가 도래했다. 어려운 부분은 이제 막 옮겨갔다

Lean 증명 자동화는 7월 26일 중요한 경계를 넘었다. Adam Langley가 대규모 언어 모델을 사용해 작동하는 Zstandard 디코더를 검증한 사례를 소개하면서다. 이는 벤치마크용 정리나 다듬어진 벤더 데모가 아니었다. 어려운 불변식, 생성된 증명, 그리고 잘못된 답을 거부할 수 있는 컴파일러를 갖춘 평범한 소프트웨어 프로젝트였다.

이 조합은 AI 신뢰성에 관한 통상적인 논의를 바꾼다. 언어 모델은 여전히 환각을 일으키거나, 요구사항을 오해하거나, 유효하지 않은 문법을 생성할 수 있다. 하지만 Lean은 작은 검증 커널을 통해 결과 증명을 검사하므로, 신뢰는 모델의 설명을 믿는 데 의존하지 않는다.

따라서 진짜 경쟁 구도는 AI 생성 코드와 사람이 작성한 코드 사이가 아니다. 검증되지 않은 생성과 기계 검증된 생성 사이의 경쟁이다. 지식 노동자에게 이 구분은 AI가 산출물을 만들고 결정론적 시스템이 중요한 주장을 검증하는 더 넓은 모델을 가리킨다.

Langley의 실험이 정형 검증이 저렴하고 쉬워졌거나 모든 프로덕션 시스템에 적용할 준비가 됐음을 입증하는 것은 아니다. 그는 디코더를 공개하지 않았고 성능 결과도 좋지 않았다. 다만 이 실험은 검증의 경제성이 바뀌고 있다는 구체적인 신호를 제공한다.

Zstandard 디코더는 증명 자동화 시험대가 됐다

Langley의 실험이 중요한 이유는 LLM이 고립된 수학 문제만이 아니라, 알아볼 수 있는 소프트웨어 구현 내부의 증명 의무를 처리했기 때문이다.

암호학과 인터넷 프로토콜 분야의 작업으로 알려진 저명한 보안 엔지니어 Langley는 Lean으로 Zstandard 압축 해제기를 만들었다. Lean은 함수형 프로그래밍 언어이면서 종속 타입 이론에 기반한 대화형 정리 증명기이기도 하다.

종속 타입을 사용하면 프로그램의 타입이 특정 값에 관한 사실을 표현할 수 있다. 예를 들어 함수는 타입에 정확한 길이가 기록된 배열을 반환할 수 있다. 또 다른 함수는 Lean이 접근을 허용하기 전에 인덱스가 배열 범위 안에 있음을 증명하도록 요구할 수 있다.

이러한 보장은 기존 소프트웨어가 흔히 주석, 테스트 또는 개발자의 기억에 남겨두는 가정을 인코딩할 수 있다. 공식 Lean reference는 다른 도구가 증명 항을 생성한 뒤 이를 검사하는 작은 커널을 설명한다. 생성과 검사의 이러한 분리가 이 이야기의 핵심이다.

Langley는 테스트 사례로 일반적으로 zstd라고 불리는 Zstandard를 선택했다. Zstd는 검증을 의미 있게 만들 만큼 내부 복잡성이 있는 무손실 압축 형식이다. LZ77 스타일 매칭과 Huffman 코딩, 그리고 유한 상태 엔트로피(Finite State Entropy), 즉 FSE를 함께 사용한다.

형식의 공개된 compression specification은 프레임, 블록, 엔트로피 테이블, 시퀀스 코드 및 디코딩 동작을 정의한다. FSE 절은 테이블 항목 간 전이가 가능한 입력 전반에서 여러 관계를 유지하도록 구성돼야 하는 상태 테이블을 설명한다.

일반적인 구현은 선택된 테이블을 알려진 출력과 비교해 테스트할 수 있다. Langley의 Lean 버전은 테이블 구성 함수에 관한 보편적 속성도 기술할 수 있었다. 이러한 속성에는 테이블의 필수 크기, 심볼 수, 그리고 테이블 항목에서의 전이 유효성이 포함됐다.

이 지점에서 LLM의 기여가 중요해졌다. Langley의 proof automation account에 따르면, 여러 모델이 약 20분 만에 관련 증명을 생성했다. 그는 이 작업이 일반적인 월간 구독 한도의 일부만 소모했다고 말한다.

모델은 개발 중 미완성 증명을 허용하는 Lean의 일반적인 임시 수단인 sorry를 남기지 않았다. Langley는 증명이 타입 검사에 통과했고 그러한 빈틈이 없음을 확인했다고 말한다.

그렇다고 디코더에 관한 모든 주장이 독립적으로 검증되는 것은 아니다. Langley는 소스 코드를 공개하지 않았기 때문에 외부 검토자가 프로젝트를 재현하거나 전체 명세를 살펴볼 수 없다. 그의 보고는 동료 심사를 받은 평가가 아니라 1인칭 실험에 남는다.

그럼에도 주장된 검증 단계는 일반적인 챗봇 답변과는 다른 지위를 갖는다. Lean의 커널이 올바르게 기술된 정리에 대한 증명을 받아들인다면, 모델의 내부 추론을 신뢰할 필요는 없다. 검사기는 결과로 나온 정형 객체를 평가한다.

이는 실무적 형태의 증명 무관성이다. 많은 명제에서 소프트웨어에 궁극적으로 필요한 것은 증명이 어떻게 발견됐는지에 관한 우아한 설명이 아니라 유효한 증명이다. 커널이 수용한다면 어색한 기계 생성 증명도 정리를 인증할 수 있다.

이 디코더는 프로그램을 증명하는 일과 좋은 제품을 만드는 일 사이의 경계도 드러냈다. Langley는 자신의 구현이 명령줄 zstd 구현보다 약 10배 느리게 실행됐다고 보고했다. 검증이 프로덕션 성능, 유지보수성 또는 완전한 형식 지원을 자동으로 제공한 것은 아니다.

가치 있는 결과는 더 제한적이다. 개발자가 범용 LLM을 사용해 사소하지 않은 프로그램 안의 어려운 증명 의무를 해결했다. 이 실험은 한때 지배적인 비용이었던 증명 노동이 점점 기계 생성 작업이 될 수 있음을 시사한다.

Lean 증명 자동화가 비용 방정식을 바꾸는 이유

Lean 증명 자동화는 정형 검증의 비용을 없애지는 않지만, 그 비용을 일반 소프트웨어 팀에 받아들일 수 없게 만든 노동 범주를 겨냥한다.

정형 검증은 오랫동안 테스트가 제공할 수 없는 것을 제시해 왔다. 테스트는 선택된 실행을 살펴보는 반면, 정형 증명은 모델이 포괄하는 모든 경우에 대해 명시된 속성을 확립할 수 있다.

이 차이는 고신뢰 시스템에서 주목할 만한 결과를 낳았다. seL4 마이크로커널은 지원되는 구성에서 명세와 검증된 구현을 연결하는 기계 검증 증명을 갖추고 있다. 프로젝트 문서는 2009년 해당 증명이 완성된 이후 검증된 코드에서 기능 정확성 결함이 없었다고 보고한다.

같은 seL4 evidence는 정형 기법이 왜 전문화된 영역에 머물렀는지도 보여준다. 검증 작업에는 방대한 명세, 증명 스크립트, 지원 도구 및 전문가 노동이 수반됐다. Langley는 증명 작업이 설계 및 구현 노력의 약 10배에 달했다는 회고적 추정을 인용한다.

그는 또한 증명 코드가 C 구현보다 20배 이상 길었다고 언급한다. 정확한 비율은 프로젝트와 검증 목표에 따라 다르다. 더 넓은 요점은 분명하다. 더 강한 보증은 역사적으로 대규모의 두 번째 기술 작업물을 요구했다.

이 작업은 전통적인 프로그래밍처럼 느껴지지 않는다. 엔지니어는 비정형 요구사항을 정확한 문장으로 옮기고, 어려운 목표를 관리 가능한 보조정리로 나누며, 누락된 단계를 거쳐 증명 시스템을 이끌어야 한다. 작은 코드 변경도 광범위한 증명 수정을 강제할 수 있다.

자동화된 솔버는 이러한 부담의 일부를 줄였다. F* 같은 시스템은 적합한 의무를 만족성 모듈로 이론(satisfiability-modulo-theories) 솔버에 보낼 수 있으며, 이 솔버들은 지원되는 논리 이론 안에서 증명을 탐색한다. 그러나 복잡한 목표에서는 솔버 동작을 예측하기 어려워질 수 있다.

숙련된 사용자는 자동화가 성공하도록 정의를 표현하는 방법을 익히는 경우가 많다. 이 전문성은 여전히 가치 있지만, 노력을 솔버에 맞추는 방향으로 옮긴다. 작은 모델링 선택 하나가 빠른 결과를 상당한 시간을 소모하는 탐색으로 바꿀 수 있다.

LLM은 다른 형태의 자동화를 제공한다. 로컬 정의를 읽고, 컴파일러 오류를 해석하고, 보조정리를 제안하고, 코드를 재작성하고, 다른 증명 전략을 시도할 수 있다. 모든 의무가 고정된 결정 절차에 들어맞아야 하는 것은 아니다.

연구는 이미 생성과 정형 검사기를 결합하는 것이 중요함을 보여준다. APOLLO paper에 설명된 한 컴파일러 유도 시스템은 Lean 피드백을 사용해 생성된 증명을 수정하고 실패한 하위 문제를 분리한다. 보고된 결과는 반복적 검증이 안내 없는 샘플링보다 더 나은 성과를 낼 수 있음을 보여준다.

Langley의 프로젝트는 이 패턴을 일상적인 소프트웨어 엔지니어링에 더 가깝게 가져온다. 모델은 벤치마크를 위해 선택된 정리만 푸는 것이 아니다. 바이트를 파싱하고, 디코딩 테이블을 만들며, 배열 경계를 강제하는 과정에서 생긴 증명 의무를 마주한다.

이 차이는 도입에 중요하다. 대부분의 조직은 경시대회 문제를 증명할 수학자를 고용하지 않는다. 대신 파서, 권한 부여 규칙, 재무 계산, 동기화 로직 및 데이터 변환을 유지하는 엔지니어를 고용한다.

이러한 시스템에는 팀이 이미 불변식으로 취급하는 수많은 문장이 담겨 있다. 요청은 인증된 계정에 속한다. 청구서의 항목 합계는 총액과 일치한다. 파서는 버퍼 범위를 넘어 읽지 않는다. 워크플로는 자체적으로 제한된 작업을 승인할 수 없다.

현재 팀은 타입, 테스트, 검토, 모니터링 및 운영 통제를 조합해 이러한 문장을 보호한다. 각 방법은 중요한 실패를 포착하지만, 모두 빈틈을 남긴다. 요구사항이 바뀌면 가정도 흔들린다.

Lean 증명 자동화는 선택된 가정을 실행 가능하고 검증 가능하게 만드는 경로를 제공한다. LLM은 번역 및 증명 노동의 일부를 흡수한다. Lean은 정형 명세를 충족하지 못하는 산출물을 차단한다.

이 구성은 AI 신뢰도의 역할도 바꾼다. 기존 코딩 보조 도구는 제한된 컨텍스트 창을 검토한 뒤 파서가 안전하다고 말할 수 있다. 증명을 생성하는 보조 도구는 명시적인 주장에 대해 Lean이 수용하는 산출물을 제공해야 한다.

수용 관문이 결정론적이기 때문에 모델은 확률적으로 남아 있어도 된다. 이 아키텍처는 개별 모델의 벤치마크 점수보다 더 중요하다. 더 나은 모델은 속도와 적용 범위를 개선하고, 검사기는 신뢰 경계를 보존한다.

조직에 경제적 질문은 더 구체적으로 바뀐다. 팀은 모든 엔지니어가 증명 전문가가 돼야 하는지 묻지 않아도 된다. 대신 어떤 고비용 실패가 정형 문장과 AI 보조 증명을 정당화하는지 물을 수 있다.

이처럼 더 좁은 도입 경로는 정적 타입, 자동화 테스트 및 지속적 통합이 확산된 방식과 닮았다. 이러한 관행은 결함을 없애지 않았다. 다만 특정 검사를 예외적인 감사가 아니라 일상 개발 중 실행할 수 있을 만큼 저렴하게 만들었다.

새로운 상대는 검증되지 않은 생성이다

핵심 갈등은 인간과 모델 중 누가 더 나은 코드를 작성하는지가 아니다. 생성된 작업이 신뢰할 수 있는 수용 테스트를 거치는지의 문제다.

대부분의 생성형 AI 도구는 검증이 약한 영역에서 작동한다. 모델은 보고서를 작성하고, 회의를 요약하고, 예측을 제안하거나 정책을 편집한다. 출력물은 정확한지 알기도 전에 그럴듯해 보이는 경우가 많다.

여전히 기본 방어선은 사람의 검토다. 하지만 검토자도 자동화를 도입하게 만든 동일한 시간 압박을 받는다. 유창한 초안은 누락된 출처, 뒤집힌 조건 또는 근거 없는 결론을 숨길 수 있다.

소프트웨어는 대부분의 지식 노동보다 자동화된 피드백을 더 많이 제공한다. 컴파일러는 문법 및 타입 오류를 거부한다. 테스트 모음은 알려진 사례를 실행한다. 린터는 선택된 패턴을 식별한다. 프로덕션 모니터링은 이전 관문을 빠져나간 실패를 드러낸다.

이러한 메커니즘 중 어느 것도 일반적으로 폭넓은 의미론적 주장을 증명하지는 않는다. 테스트 통과만으로 모든 유효한 압축 스트림이 배열 경계 안에 머문다는 사실을 확립할 수는 없다. 관련 관계가 타입 시스템에 나타나지 않는 한 타입 검사기도 그 속성을 강제할 수 없다.

Lean은 계약을 바꾼다. 개발자는 프로그램의 타입 안에서 또는 정리로 주장을 표현할 수 있다. 그러면 커널은 제공된 증명이 수용된 가정에서 정확히 그 주장을 확립하는지 검사한다.

LLM은 권위자가 아니라 후보 증명을 생성하는 역할을 맡는다. 최종 보증의 강도는 모델이 거듭 실패하더라도 약해지지 않는다. 실패한 후보는 신뢰할 수 있는 산출물에 들어가기 전에 거부된다.

이 패턴은 정리 증명을 넘어 폭넓은 지식 노동자에게도 흥미로울 만하다. 많은 전문적 산출물에는 이미 구조화된 근거로 검증할 수 있는 주장이 포함돼 있다. 과제는 그러한 주장과 여전히 맥락에 좌우되는 판단을 분리하는 데 있다.

주간 업데이트를 준비하는 제품 관리자를 생각해 보자. AI 어시스턴트는 검색 가능한 지식 기반을 통해 프로젝트 노트, 의사결정, 고객 피드백, 납품 지표를 수집할 수 있다. 사람이 한 주의 일을 재구성하는 것보다 더 빠르게 서사를 초안으로 만들 수도 있다.

하지만 조직에는 여전히 관문이 필요하다. 인용된 모든 고객 발언은 녹화본이나 노트와 연결돼야 한다. 출시된 모든 기능은 승인된 릴리스 기록과 연결돼야 한다. 모든 지표에는 정의와 보고 기간이 따라야 한다.

현재 형태로는 정리 증명 작업이 아니다. 그러나 같은 아키텍처를 공유한다. 생성은 산출물을 제안하고, 별도 시스템은 명시적 규칙과 근거를 바탕으로 주장을 점검한다.

금융 분석가는 생성된 메모의 모든 수치가 공시 자료나 승인된 데이터세트까지 추적되도록 요구할 수 있다. 연구자는 모든 인용이 해당 문장을 실제로 뒷받침하도록 요구할 수 있다. 컴플라이언스 팀은 정책 조건을 기계 검증 가능한 워크플로로 인코딩할 수 있다.

형식 언어는 이러한 검증의 상한을 높인다. 단순 검증 스크립트로는 깔끔하게 표현하기 어려운 관계를 나타낼 수 있기 때문이다. 그러면 LLM은 사용자가 명세를 작성하고, 형식을 연결하며, 필요한 근거를 구성하도록 돕는다.

이는 신뢰할 수 있는 AI에 대한 더 유용한 정의를 만든다. 신뢰는 모델에게 신중하라고 요구해서 생기지 않는다. 뒷받침되지 않은 작업이 중요한 경계를 넘을 수 없도록 프로세스를 설계할 때 생긴다.

이 접근 방식은 인간의 판단이 여전히 필수적인 지점도 분명히 한다. Lean은 누군가 작성한 정리를 검증한다. 그 정리가 사용자의 실제 요구사항이나 조직의 전체 위험을 제대로 포착하는지는 판단하지 않는다.

완벽하게 증명된 명세도 잘못된 동작을 명세할 수 있다. 배열 경계에 관한 정리는 디코더가 프로덕션 서비스에 필요한 모든 기능을 처리한다는 사실을 입증하지 않는다. 보안 증명은 현실적인 공격자 역량을 누락할 수 있다.

따라서 AI 지원 검증은 인간의 노력을 명세로 이동시킨다. 사람은 어떤 속성이 중요한지, 어떤 가정이 허용되는지, 증명이 어느 시스템 경계를 포괄하는지를 결정해야 한다.

이 변화는 스프레드시트가 회계에 미친 영향과 닮았다. 자동화는 산술 작업을 줄이지만, 올바른 모델과 입력을 선택하는 일의 중요성은 높인다. 오류 없는 계산도 잘못된 비즈니스 질문에 답할 수 있다.

가장 강한 팀은 생성된 증명을 장식물로 취급하지 않을 것이다. 오늘날 아키텍처와 보안 경계에 기울이는 것과 같은 주의로 정리문, 가정, 인터페이스를 검토할 것이다.

Zstandard 실험이 입증하지 않는 것

검증된 증명은 유효할 수 있지만, 주변 소프트웨어가 느리거나 불완전하거나, 명세가 부실하거나, 프로덕션에 부적합한 상태로 남을 수 있다.

가장 직접적인 한계는 재현성이다. Langley는 자신의 구현을 참조용 디코더가 아닌 학습 프로젝트로 봤기 때문에 공개하지 않았다. 이 선택은 코드, 증명 구조, 모델 워크플로에 대한 독립적인 테스트를 막는다.

따라서 독자는 보고된 20분 증명 생성 결과를 경험 보고로 받아들여야 한다. 이는 한 명의 숙련된 엔지니어가 하나의 프로젝트에서 해당 워크플로를 성공적으로 사용했다는 근거다. 일반적인 성능 측정은 아니다.

모델은 증명을 찾는 과정에서 일부 구현 코드도 변경했다. Langley는 지역적으로 명령형 계산을 표현할 수 있는 Lean 메커니즘인 Id.run을 사용해 왔다. 그는 이 방식이 증명 도구가 코드를 분석하기 더 어렵게 만들었다고 보고한다.

이 세부 사항은 깔끔한 성공담보다 더 많은 것을 보여준다. AI 증명 자동화는 임의의 구현을 단순히 인증한 것이 아니다. 프로그램을 형식적으로 추론하기 쉽게 만드는 변경을 유도했다.

이러한 변경은 구조를 개선할 수 있지만, 엔지니어링 우선순위를 왜곡할 수도 있다. 개발자는 현재의 증명 도구가 어려워하는 효율적인 표현을 피할 수 있다. 더 빠른 검증을 얻기 위해 더 느린 코드를 받아들일 수도 있다.

Langley의 디코더는 기존 명령줄 구현보다 약 10배 느리게 실행된 것으로 알려졌다. 이 격차가 증명을 무효화하는 것은 아니다. 정확성, 범위, 성능이 여전히 별개의 차원임을 보여준다.

증명 엔지니어링도 사라지지 않았다. 대규모 프로젝트는 코드 변경에도 증명이 유지되도록 보조정리와 추상화를 구성한다. LLM이 증명을 저렴하게 재생성할 수 있다면 일부 유지보수 전략의 중요성은 줄어들 수 있다. 하지만 증명 탐색 자체가 비용이 많이 들 수 있으므로 다른 전략은 여전히 필요하다.

증명 상태 스냅샷에 관한 최근 연구는 이러한 인프라 문제를 보여준다. 저자들은 반복적인 상태 재구성이 자동화된 Lean 탐색의 지배적 비용이 될 수 있다고 보고한다. 제안한 재사용 메커니즘은 선택된 벤치마크 전반에서 상당한 속도 향상을 냈다.

이는 증명 자동화가 모델 지능 이상의 요소에 의존한다는 점을 상기시킨다. 빠른 컴파일러 피드백, 의존성 관리, 관련 보조정리 검색, 통제된 탐색, 재현 가능한 환경이 필요하다.

규모는 또 다른 불확실성을 만든다. 압축 디코더는 제약된 명세와 알아보기 쉬운 알고리즘을 가진다. 엔터프라이즈 시스템은 데이터베이스, 네트워크, 사용자 인터페이스, 외부 서비스, 변경 가능한 권한, 불완전한 비즈니스 규칙을 혼합한다.

이러한 경계를 형식화하는 비용은 지역 함수의 증명 비용보다 더 클 수 있다. 권한 부여 규칙에 관한 정리는 신원 데이터, 서비스 동작, 배포 구성이 모델의 가정과 일치할 때만 도움이 된다.

매우 강한 타입은 변경을 프로그램 전체로 확산시킬 수도 있다. 하나의 데이터 구조에 새로운 불변 조건이 추가되면, 이를 생성하거나 변환하는 모든 함수가 더 강한 요구사항을 충족해야 한다. 이러한 전파는 가치 있지만 마이그레이션 비용을 높일 수 있다.

LLM은 영향을 받은 증명을 복구할 수 있지만, 코드만으로 제품 의도를 항상 추론할 수는 없다. 재생성된 증명은 비즈니스에 실제로 새로운 명세가 필요한 상황에서도 어제의 명제를 유지할 수 있다. 자동화는 낡은 정확성을 더 쉽게 유지하게 만든다.

도구 체인에는 보안 우려도 있다. Lean 커널은 신뢰할 수 있는 컴퓨팅 기반, 즉 증명을 신뢰하기 위해 올바르게 동작해야 하는 소프트웨어의 범위를 줄인다. 그러나 빌드 시스템, 파서, 컴파일러, 배포 파이프라인은 여전히 커널을 둘러싸고 있다.

증명은 명시된 가정과 공리에도 의존한다. 팀에는 미완성 플레이스홀더, 예상치 못한 공리, 잘못된 의존성 버전을 기준으로 생성된 증명을 거부하는 정책이 필요하다. 편집기의 녹색 표시만으로는 충분한 거버넌스가 될 수 없다.

비기술 의사결정자에게는 “증명”이라는 단어를 과도하게 해석할 위험이 있다. 형식 검증은 정의된 가정 아래 정의된 속성을 확립한다. 일반적인 품질, 윤리적 행동, 사용성, 법규 준수, 비즈니스 가치를 인증하지는 않는다.

이러한 정확성은 강점으로 다뤄져야 한다. 팀은 정확히 무엇이 증명됐고 무엇이 경계 밖에 남았는지를 살펴볼 수 있다. 대안은 종종 산재한 테스트와 자신감 있는 문구로 뒷받침된 광범위한 보증 주장이다.

그러므로 Langley의 결과는 방향성 신호로서 가장 강력하다. LLM은 형식 증명 구축의 노동 집약도를 낮출 수 있다. 남은 병목은 명세, 시스템 경계, 성능, 통합 쪽으로 이동한다.

증명 자동화의 확산 여부를 보여줄 세 가지 신호

다음 단계는 재현 가능한 소프트웨어 사례, 증명을 인식하는 개발 도구, 그리고 실제 변경 이후에도 검증된 시스템이 유지보수 가능하다는 근거에 달려 있다.

첫 번째 신호는 AI 생성 Lean 증명을 중심으로 구축된 완전한 일반 소프트웨어 프로젝트의 공개다. 벤치마크는 여전히 유용하지만, 변화하는 요구사항, 의존성 업그레이드, 성능 튜닝, 프로덕션 디버깅을 포착하지는 못한다.

설득력 있는 프로젝트라면 소스, 정리문, 프롬프트 또는 에이전트 워크플로, 모델 버전, 증명 검증 명령, 한계를 공개해야 한다. 독립 팀은 호스팅된 모델을 신뢰하지 않고도 승인된 증명을 재현할 수 있어야 한다.

파서, 암호화 코드, 금융 로직, 프로토콜 구현 전반에서 여러 프로젝트가 등장한다면 Langley의 결론은 힘을 얻는다. 사례가 작거나 미공개 상태에 머문다면 일상적 도입의 근거는 약해진다.

두 번째 신호는 주류 개발 워크플로로의 통합이다. 증명 자동화는 연구 환경이라기보다 코드 리뷰, 지속적 통합, 편집기의 타입 검사기처럼 느껴져야 한다.

중요한 기능에는 로컬 라이브러리에서의 신뢰할 수 있는 검색, 짧은 피드백 루프, 설명 가능한 실패, 미완성 가정의 엄격한 탐지가 포함될 것이다. 팀에는 코드 변경과 함께 검토할 수 있는 버전 관리된 증명 산출물도 필요하다.

도구는 증명 본문뿐 아니라 증명 대상 명제의 변경도 강조해야 한다. 정리를 조용히 약화시키는 모델은 어려운 실패를 오해를 부르는 성공으로 바꿀 수 있다. 검토 인터페이스는 그러한 변경을 분명하게 드러내야 한다.

조직은 공급업체가 비형식적 요구사항을 형식 명제와 어떻게 연결하는지도 지켜봐야 한다. 증명을 생성하는 것은 워크플로의 절반에 불과하다. 시스템은 인간의 결정에서 기계 검증된 속성까지의 추적 가능성을 보존해야 한다.

여기서 지식 관리는 운영 인프라가 된다. 어시스턴트가 책임 있게 형식화하려면 요구사항, 의사결정, 예외, 출처 근거에 대한 지속적인 맥락이 먼저 필요하다. 개인 지식 시스템은 이러한 맥락을 지원할 수 있지만, 형식적 승인을 위해서는 여전히 전용 검증 도구가 필요하다.

세 번째 신호는 상당한 변경 이후의 유지보수 비용이다. 일회성 증명은 검토자를 감탄시킬 수 있지만, 다음 릴리스에서는 부담이 될 수 있다. 더 관련성 높은 지표는 동작을 수정한 뒤 팀이 검증된 상태를 얼마나 빨리 복원하는가다.

연구자와 엔지니어링 팀은 변경 중심의 평가를 공개해야 한다. 데이터 구조를 바꾸고, 명세를 강화하며, 알고리즘을 교체하고, 의존성을 업그레이드해야 한다. 그런 다음 인간의 노력, 모델 시도 횟수, 검증 시간, 성능 회귀를 측정해야 한다.

AI가 명확하게 검토된 명제를 보존하면서 증명을 복구할 수 있다면, 형식 기법은 반복적 소프트웨어 개발과 더 잘 양립하게 된다. 변경마다 통제되지 않은 탐색이나 광범위한 재작성이 발생한다면, 도입은 높은 보증이 필요한 틈새 분야에 계속 집중될 것이다.

지식 노동자도 자신의 AI 시스템에서 같은 패턴을 지켜봐야 한다. 지속적인 이점은 더 많은 초안을 생산하는 데서 나오지 않는다. 문서, 정책, 데이터, 팀이 바뀌어도 신뢰성을 유지하는 승인 관문을 구축하는 데서 나온다.

Lean 증명 자동화는 생성과 검증이 분리된 역할을 차지하기 때문에 유난히 명확한 사례를 제공한다. LLM은 창의적이고, 일관성이 없으며, 때로는 틀릴 수 있다. 커널은 여전히 유효한 형식 산출물을 요구한다.

이 설계가 AI 생성 작업을 둘러싼 모든 문제를 해결하는 것은 아니다. 다만 더 나은 기본 원칙을 제시한다. 모델이 제안하게 하고, 명시적 시스템이 검증하게 하며, 사람이 명세를 책임지게 하라.

다음으로 실질적으로 던져야 할 질문은 모든 직장이 Lean을 도입해야 하는지가 아니다. 자신감 있는 한 문단이나 일회성 테스트보다 더 강한 검증이 필요한 반복적 주장들이 무엇인지가 핵심이다. 비용이 큰 가정 하나를 찾아 그 근거와 연결한 뒤, 실행 전에 어떤 결정론적 게이트로 이를 점검할 수 있을지 물어보라. 이 과정을 통해 AI가 안전하게 업무를 가속할 수 있는 지점과 여전히 인간의 검토가 전적인 부담을 짊어져야 하는 지점이 드러난다. Lean 증명 자동화는 목적지를 더 선명하게 보여주었지만, 조직은 여전히 무엇을 증명할 가치가 있는 주장으로 볼지 선택해야 한다.