AI가 짠 코드를 Lean으로 완전히 증명할 수 있나요?

아닙니다. Lean은 사람이 정의한 사양과 불변식에 대해서만 증명을 검사합니다. AI가 생성한 코드 전체의 모든 성질을 자동으로 증명하는 것은 현재 불가능하며, 사양의 정확성은 사람이 검토해야 합니다.

Lean은 무엇인가요?

Lean은 수학 정리와 프로그램 성질을 형식적으로 표현하고 증명을 기계적으로 검사하는 증명 보조 도구입니다. 작은 커널이 증명을 검사하므로, 통과된 증명은 해당 사양에 한해 매우 강한 신뢰를 제공합니다.

실무에서 형식 검증을 도입할 때 가장 큰 장벽은 무엇인가요?

사양을 형식 언어로 옮기고 증명을 작성하는 데 필요한 학습 곡선과 시간 비용이 가장 큽니다. AI가 증명 스케치를 생성해 진입 장벽을 낮출 수 있지만, 사양 설계의 책임은 여전히 사람에게 있습니다.

AI가 생성한 증명이 Lean을 통과하면 무조건 믿어도 되나요?

Lean 커널이 통과시켰다면 그 증명은 형식적으로 검증된 것입니다. 다만 검사기 자체의 버그 가능성과 사양이 원래 의도와 다를 가능성이 있으므로, 완전한 절대적 신뢰보다는 강한 보장으로 이해해야 합니다.

바이브 코딩에서 형식 검증을 어디에 우선 적용해야 하나요?

결제, 인증, 권한 부여, 합의 알고리즘, 데이터 무결성처럼 오류 비용이 큰 핵심 모듈에 먼저 적용하는 것이 실용적입니다. UI나 외부 통합처럼 불변식이 모호한 부분은 효과가 낮습니다.

AI가 짠 코드, 수학적으로 증명할 수 있을까: Lean과 함께하는 형식 검증의 실전

md-log2026년 11월 1일약 6분 읽기

AI 코딩 도구가 생성한 코드의 정확성을 보장하기 위해 Lean 같은 증명 보조 도구를 활용하는 반자동 형식 검증 파이프라인과 그 한계를 살펴봅니다.

AI 코딩 에이전트가 만들어 낸 코드를 “일단 돌아가니까 넘어가자”는 식으로 신뢰하기 어려워지고 있습니다. 코드가 실행은 되지만 경계 조건에서 실패하거나, 보안 불변식을 깨뜨리는 사례가 반복되면서, 테스트를 넘어 수학적 증명으로 핵심 성질을 보장하려는 흐름이 주목받고 있습니다. 결론부터 말하면, AI가 생성한 코드 전체를 자동으로 증명하는 수준은 아직 아니지만, 사람이 사양과 불변식을 정의하고 AI가 Lean 같은 증명 보조 도구의 증명 스케치를 생성해 검증하는 반자동 파이프라인은 현실적인 대안입니다. 다만 검증 도구 자체의 신뢰성과 사양 오류 가능성까지 고려해야 하므로, 형식 검증은 바이브 코딩의 신뢰 문제를 크게 줄여 주되 완전히 없애지는 못합니다.

AI 코딩이 불러온 '증명'에 대한 새로운 수요

AI 코딩 도구는 자연어 요구사항을 그럴듯한 코드로 바꾸는 능력이 뛰어나지만, 출력이 항상 요구사항을 정확히 반영한다는 보장은 없습니다. 단위 테스트와 통합 테스트는 입력 공간의 일부만 확인할 뿐이며, 회귀 테스트는 사람이 예상한 시나리오를 넘어서기 어렵습니다. 특히 결제, 인증, 데이터 무결성처럼 실패 비용이 큰 영역에서는 “테스트를 통과했다”는 것만으로는 부족하고, “모든 가능한 입력에 대해 이 성질이 유지된다”는 수학적 보장이 필요합니다.

이러한 배경에서 최근 주목할 만한 사례는 2026년 10월 공개된 OpenAI의 내부 모델 연구 결과입니다. 수학 미해결 문제를 다룬 결과물 722편, 372개 묶음이 GitHub에 올라왔고, 그중 상당수는 증명을 Lean으로 형식화해 함께 공개되었습니다. 결과 하나에 ChatGPT Pro 약 3시간 상당의 연산이 들었다고 알려졌는데, 이는 AI가 수학 증명의 형식화 작업을 대규모로 수행할 수 있다는 신호이기도 합니다. 다만 “AI가 만든 증명은 그럴듯해 보여도 믿기 어렵다”는 우려 때문에, 결과 발표만이 아니라 Lean 검증 통과가 중요한 신뢰 장치로 제시된 점이 눈에 띕니다.

Lean으로 '증명이 있는 코드'를 만드는 파이프라인

Lean은 원래 수학자들이 정리를 형식화하고 증명하는 데 쓰던 증명 보조 도구입니다. 작은 커널이 모든 증명 단계를 다시 확인하는 구조라서, 커널이 통과시킨 증명은 해당 사양에 한해 매우 높은 신뢰성을 갖습니다. 이 특성을 소프트웨어 검증에 가져오면, 코드와 함께 “이 함수는 정렬된 결과를 반환한다”, “이 자료구조는 모든 삽입 후에도 균형 조건을 유지한다” 같은 정리를 증명할 수 있습니다.

실전에서 그럴듯한 파이프라인은 다음과 같이 구성할 수 있습니다.

개발자가 검증할 함수의 사양과 불변식을 먼저 정의합니다.
AI 코딩 에이전트가 구현 코드와 함께 Lean의 정리 선언, 증명 스케치를 생성합니다.
개발자는 정리 선언이 원래 요구사항을 정말 담고 있는지, 전제 조건이 빠지지 않았는지 확인합니다.
Lean 커널이 증명을 검사하고 통과하면 해당 성질은 이후 리팩터링에서도 기계적으로 보장됩니다.

예를 들어 정렬 함수를 검증한다면 “결과가 비내림차순이다”와 “결과는 입력의 순열이다”라는 두 가지 불변식을 함께 증명해야 합니다. AI는 두 조건을 만족하는 증명을 꽤 잘 생성하는 편이지만, 개발자는 “정말 이 정리가 내가 원하는 정렬을 의미하는가”를 검토해야 합니다. 사양이 약하면 사소한 성질만 증명하고도 검증을 통과한 것처럼 보일 수 있기 때문입니다.

실무 도입의 진입 장벽과 AI가 낮춰줄 수 있는 부분

형식 검증의 가장 큰 장벽은 사양 작성과 증명에 필요한 학습 곡선입니다. Lean은 의존 타입 이론을 기반으로 하기 때문에 일반 개발자에게는 문법과 증명 전략이 낯설고, 작은 함수 하나를 증명하는 데도 상당한 시간이 걸릴 수 있습니다. 또 사양 자체를 형식 언어로 옮기는 일은 비즈니스 요구사항을 모호함 없이 정의해야 하므로 매우 어렵습니다.

AI는 이 지점에서 진입 장벽을 낮춰 주는 역할을 합니다. 증명 보조 도구의 오류 메시지를 보고 다음 증명 전략을 제안하거나, 보조 정리를 자동으로 찾아 주는 방식으로 증명 시간을 단축할 수 있습니다. 자연어로 된 불변식 설명을 Lean의 정리 형태로 바꾸는 초안 작성도 AI가 잘 해내는 영역입니다. 다만 여기에는 두 가지 주의가 필요합니다. 첫째, AI가 생성한 증명 스케치가 Lean 커널을 통과했다고 해도, 사양이 원래 의도와 다르면 아무 소용이 없습니다. 둘째, 올여름 Lean 검사기 자체에서 “거짓”을 증명할 수 있는 버그가 여러 건 발견된 사례처럼, 검증 도구의 신뢰 기반도 완벽하지 않습니다. 따라서 형식 검증은 “수학적으로 절대적으로 옳다”가 아니라 “도구와 사양이 신뢰할 만하다는 전제 아래에서 매우 강한 보장을 준다”로 이해해야 합니다.

개발자가 리뷰해야 할 불변식과 사양의 역할

AI가 생성한 증명과 코드를 리뷰할 때 개발자가 집중해야 할 지점은 증명 자체보다 사양과 불변식입니다. Lean 커널이 통과시킨 증명은 형식적으로 올바르지만, 그 정리가 비즈니스 요구를 정확히 담고 있는지, 모든 입력 범위를 포괄하는지, 숨은 전제 조건이 없는지를 사람이 확인해야 합니다. 예를 들어 “배열 인덱스가 범위를 벗어나지 않는다”는 불변식을 검증할 때, AI가 빈 배열만 고려하는 전제 조건을 추가해 버리면 실제 운영 환경에서는 의미가 없어집니다.

실무에서는 불변식을 계층별로 나누는 것이 좋습니다. 자료구조의 내부 일관성, 함수의 전후 조건, 모듈 간 계약, 보안 경계 조건을 각각 별도의 정리로 관리하면 검증 범위가 명확해집니다. AI는 이러한 정리 목록을 빠르게 생성하고 증명 시도를 반복할 수 있지만, 최종적으로 “이 사양이 옳은가”를 판단하는 책임은 사람에게 있습니다. 이 과정에서 사양 변경 이력과 리뷰 근거를 남기면 나중에 왜 그 불변식을 선택했는지 추적하기 쉬워지는데, 이때 md-log 같은 휴먼 인 더 루프 리뷰 아카이브가 실무적으로 유용합니다.

형식 검증이 해결할 수 있는 것과 한계

형식 검증은 모든 소프트웨어 문제를 해결하지는 않습니다. UI 반응성, 외부 API와의 통합, 성능 병목처럼 비기능적 요구사항은 정리로 표현하기 어렵고, 전체 애플리케이션의 완전한 정확성을 증명하는 것은 비용 대비 효과가 낮습니다. 실용적인 적용 범위는 결제 로직, 인증 및 권한 부여, 합의 알고리즘, 데이터베이스 트랜잭션처럼 오류가 치명적인 핵심 모듈과, 알고리즘의 핵심 불변식이 명확한 부분입니다.

AI가 이 한계를 당장 바꾸지는 못하지만, 적용 비용을 낮춘다는 점에서 의미가 있습니다. 반복적인 증명 시도와 보조 정리 탐색을 AI가 대신하면서, 사람은 사양 설계와 아키텍처 결정에 집중할 수 있습니다. 다만 AI가 생성한 증명과 코드를 무비판적으로 수용하면 안 됩니다. Lean 검사기 버그, 사양 오류, 모델의 자기과신 등이 겹치면 “검증 통과”라는 라벨이 오히려 잘못된 확신을 줄 수 있습니다. 따라서 형식 검증은 바이브 코딩의 신뢰성 문제를 핵심 모듈에서 크게 완화하지만, 전체 코드베이스의 완전한 정확성 보장으로 확장하기에는 아직 현실적 한계가 있습니다.

AI가 생성한 코드를 수학적으로 증명할 수 있느냐는 질문에는 “지정한 사양과 불변식에 한해서는 그렇다”고 답할 수 있습니다. Lean과 AI를 결합하면 증명 작성 비용이 낮아지고, 핵심 로직의 신뢰성을 기존 테스트보다 훨씬 강하게 보장할 수 있습니다. 그러나 그 신뢰는 사양의 정확성과 도구의 신뢰성 위에 서 있기 때문에, 사람이 불변식과 전제 조건을 끝까지 검토하는 휴먼 인 더 루프가 필수적입니다.

참고 자료

#AI코딩 #Lean #형식검증 #증명보조도구 #수학적증명 #코드리뷰

자주 묻는 질문

AI가 짠 코드를 Lean으로 완전히 증명할 수 있나요?: 아닙니다. Lean은 사람이 정의한 사양과 불변식에 대해서만 증명을 검사합니다. AI가 생성한 코드 전체의 모든 성질을 자동으로 증명하는 것은 현재 불가능하며, 사양의 정확성은 사람이 검토해야 합니다.
Lean은 무엇인가요?: Lean은 수학 정리와 프로그램 성질을 형식적으로 표현하고 증명을 기계적으로 검사하는 증명 보조 도구입니다. 작은 커널이 증명을 검사하므로, 통과된 증명은 해당 사양에 한해 매우 강한 신뢰를 제공합니다.
실무에서 형식 검증을 도입할 때 가장 큰 장벽은 무엇인가요?: 사양을 형식 언어로 옮기고 증명을 작성하는 데 필요한 학습 곡선과 시간 비용이 가장 큽니다. AI가 증명 스케치를 생성해 진입 장벽을 낮출 수 있지만, 사양 설계의 책임은 여전히 사람에게 있습니다.
AI가 생성한 증명이 Lean을 통과하면 무조건 믿어도 되나요?: Lean 커널이 통과시켰다면 그 증명은 형식적으로 검증된 것입니다. 다만 검사기 자체의 버그 가능성과 사양이 원래 의도와 다를 가능성이 있으므로, 완전한 절대적 신뢰보다는 강한 보장으로 이해해야 합니다.
바이브 코딩에서 형식 검증을 어디에 우선 적용해야 하나요?: 결제, 인증, 권한 부여, 합의 알고리즘, 데이터 무결성처럼 오류 비용이 큰 핵심 모듈에 먼저 적용하는 것이 실용적입니다. UI나 외부 통합처럼 불변식이 모호한 부분은 효과가 낮습니다.

← 모든 글 보기