형식적 검증 도구인 Isabelle/HOL을 사용하는 개발자들은 최근 대규모 언어 모델(LLM)의 도움을 받아 증명을 작성하거나 보완하는 시도를 하고 있습니다. 그러나 여기서 직면하는 가장 큰 문제는 LLM이 요청된 부분 외에도 기존 이론에서 허용되지 않은 변경을 가할 가능성이 있다는 점입니다. 단순히 빌드가 성공했다는 사실만으로는 LLM이 개발자가 의도한 범위 내에서만 작업했음을 보장할 수 없습니다. 이러한 불확실성을 해소하기 위해 등장한 것이 CAPRI(Contract-Aware Proof Repair)입니다. 이 글은 CAPRI가 제시하는 계약 기반 수정 워크플로우의 기술적 구조와, 실제 개발 환경에서 이를 적용할 때 고려해야 할 제한 사항 및 검증 기준을 다룹니다.
LLM 기반 증명 보조의 근본적 취약점
Isabelle과 같은 정리 증명기(Proof Assistant)는 수학적으로 엄밀한 논리를 요구합니다. LLM이 이러한 환경에서 작동할 때, 모델은 문맥을 이해하고 코드나 증명을 생성하지만, 그 과정이 완전히 결정론적이지는 않습니다. 특히 기존 이론 파일에 대한 수정 작업에서 LLM은 전체 파일을 다시 생성하거나, 의도치 않게 의존성 관계를 깨뜨리는 변경을 포함할 수 있습니다. arXiv CS.AI RSS 요약에 따르면, CAPRI는 LLM을 사용하여 Isabelle 증명을 발견하는 과정에서 발생하는 이러한 문제를 다루고 있습니다(출처: arXiv CS.AI RSS 요약). 핵심 쟁점은 '빌드 성공'과 '수정 범위 적법성'의 괴리입니다. 빌드 도구는 최종 이론이 일관성을 가지는지 확인하지만, LLM이 원래 개발자가 승인하지 않은 부분을 고쳤는지 추적하지는 않습니다. 이는 형식적 검증의 신뢰성을 해칠 수 있는 치명적인 결함입니다.
CAPRI의 계약 기반 수정 워크플로우
CAPRI는 이 문제를 해결하기 위해 '계약(Aware)'이라는 개념을 도입합니다. 여기서 계약이란 개발자가 명시적으로 허용한 변경 사항과 그 범위를 정의하는 규칙을 의미합니다. CAPRI 워크플로우는 크게 두 단계로 나뉩니다. 첫 번째 단계는 Isabelle이 생성된 증명의 타당성을 검증하는 과정입니다. 두 번째 단계는 독립적인 체크어(Independent Checker)가 LLM의 변경 내역을 사전에 정의된 계약과 비교하는 과정입니다. 이 구조는 LLM의 출력을 맹목적으로 신뢰하지 않고, 추가적인 검증 레이어를 통해 변경의 투명성을 확보하려 합니다. 즉, 증명이 수학적으로 맞는지(Isabelle의 역할)와, 그 변경이 허용된 범위 내에 있는지(체크어의 역할)를 분리하여 판단합니다. 이러한 이중 검증 메커니즘은 LLM의 블랙박스 특성을 보완하는 실용적인 접근법입니다.
독립적 체크어의 검증 논리
독립적인 체크어는 CAPRI 시스템의 핵심 구성 요소입니다. 이 체크어는 LLM이 제출한 패치나 수정된 이론 파일을 분석하여, 개발자가 지정하지 않은 부분의 변경 여부를 식별합니다. 예를 들어, 개발자가 '증명 단계 A만 수정하라'고 지시했는데 LLM이 '정의 B'의 타입 서명을 변경했다면, 체크어는 이를 거부합니다. 이러한 검증은 단순한 텍스트 비교를 넘어, 구문 분석(Syntax Analysis)과 의미를 고려한 구조적 비교가 필요할 수 있습니다. RSS 요약에서는 구체적인 알고리즘을 명시하지 않지만, '계약 기반'이라는 키워드는 변경 사항을 명시적 허용 목록과 일치시키기 위한 패턴 매칭이나 AST(Abstract Syntax Tree) 기반 비교가 사용됨을 시사합니다. 이는 LLM의 생성물이 형식적으로 유효하더라도, 엔지니어링 관점에서 제어 불가능한 사이드 이펙트를 방지하는 데 필수적입니다.
실패 조건과 검증의 한계
CAPRI 워크플로우가 모든 문제를 해결하는 것은 아닙니다. 첫 번째 실패 조건은 계약의 정의가 모호하거나 과도하게 제한적일 때 발생합니다. 개발자가 허용할 변경 범위를 정확히 예측하기 어렵다면, 체크어가 유용한 수정을 거부할 수 있습니다. 두 번째로, LLM이 매우 복잡한 대규모 변경을 시도할 경우, 체크어의 분석 비용이 증가하거나 오검출(False Negative)이 발생할 가능성이 있습니다. 또한, Isabelle 빌드 시스템과의 통합 과정에서 추가적인 지연 시간이 발생할 수 있습니다. 형식적 검증 자체가 시간이 많이 소요되는 작업인데, 여기에 LLM 생성 및 계약 검증 단계를 추가하면 전체 피드백 루프가 느려질 수 있습니다. 이는 개발자의 생산성에 직접적인 영향을 미칠 수 있는 요소로, 실시간 편집 환경보다는 배치 처리나 주기적인 통합 테스트 시나리오에 더 적합할 수 있습니다.
운영 및 보안 관점에서의 고려사항
보안 관점에서 CAPRI는 LLM 기반 도구 도입 시 발생할 수 있는 '프롬프트 인젝션'이나 '의도치 않은 코드 삽입' 위험을 완화하는 방안으로 볼 수 있습니다. 독립적인 체크어는 제3자의 검증자 역할을 수행하므로, LLM 제공사의 모델 업데이트나 파인튜닝 변화에 따른 출력 불안정성으로부터 개발 환경을 격리합니다. 그러나 이 시스템의 보안 강도는 체크어 자체의 구현 품질에 달려 있습니다. 만약 체크어에 결함이 있거나 우회 방법이 발견된다면, 시스템의 신뢰도는 무너집니다. 따라서 체크어 자체의 종단 간 테스트와 정적 분석이 필수적입니다. 또한, LLM이 접근하는 데이터의 기밀성을 고려할 때, 온프레미스에서 독립 체크어를 운영하는 것이 외부 API 의존성을 줄이고 보안성을 높이는 전략이 될 수 있습니다.
실무 적용 경계와 도입 판단 기준
개발 팀이 CAPRI 또는 유사한 계약 기반 워크플로우를 도입할지 결정할 때는 몇 가지 기준을 고려해야 합니다. 첫째, 프로젝트의 형식적 검증 요구 수준입니다. 안전 임계형(Safety-Critical) 시스템이나 암호화 라이브러리 개발처럼 오류가 치명적인 분야에서는 CAPRI의 오버헤드를 감수할 가치가 있습니다. 둘째, 팀 내 LLM 리터러시와 형식적 검증 도구 숙련도입니다. 계약 정의를 올바르게 작성하고 체크어의 오류 메시지를 해석할 수 있는 인력이 필요합니다. 셋째, 기존 CI/CD 파이프라인과의 통합 용이성입니다. Isabelle 빌드 시스템이 CAPRI의 독립 체크어와 원활하게 통신할 수 있도록 인터페이스가 준비되어 있어야 합니다. 만약 이러한 조건이 충족되지 않는다면, LLM 보조 기능을 제한적으로 사용하거나, 더 간단한 코드 자동 완성 수준에서 활용하는 것이 현실적일 수 있습니다.
결론: 검증 가능한 자동화의 방향
CAPRI는 LLM이 형식적 검증 도구에 통합될 때 발생할 수 있는 신뢰성 문제를 해결하기 위한 하나의 모델입니다. 단순히 '동작하는 코드'를 생성하는 것을 넘어, '허용된 범위 내에서 변경된 코드'를 보장함으로써 개발자의 통제권을 유지하려는 시도입니다. 이 접근법은 AI 생성물의 불확실성을 기술적 제약을 통해 관리할 수 있음을 보여줍니다. 향후 이러한 계약 기반 검증 메커니즘이 더 다양한 프로그래밍 언어와 검증 도구로 확장된다면, AI 보조 개발의 신뢰성은 크게 향상될 것입니다. 개발자들은 CAPRI에서 제시하는 '독립적 검증'과 '범위 통제' 개념을 참고하여, 자신들의 프로젝트에 맞는 검증 워크플로우를 설계하는 것이 중요합니다. 기술의 진보는 단순히 성능 향상이 아닌, 예측 가능성과 통제 가능성의 확보에 있음을 잊지 말아야 합니다.
참고: arXiv CS.AI