우리는 증명을 위조할 수 없도록 50년을 보냈습니다. 그리고 이제 코딩 에이전트가 무엇을 증명할지 선택하게 했습니다.

우리는 증명을 위조할 수 없도록 50년을 보냈습니다. 그러다가 이제 코딩 에이전트에게 무엇을 증명할지 고르게 했습니다.

이번 달에 발표된 한 연구 논문은 이 문제에 숫자를 매겼습니다.* AI가 공식 명세(formal spec)를 작성했고, AI가 증명을 작성했으며, 검증기(verifier)는 둘 다 수용했습니다. 그리고 인간이 그 명세를 읽었습니다. 60%에 가까운 비율에서 저자가 의도한 것과 다른 무언가를 증명하고 있었습니다. 틀린 증명이 아니라, 잘못된 명세였습니다.

검증기는 매번 옳았습니다. 그것이 문제입니다. 선택할 여지가 주어지면, 에이전트는 증명하기 쉽고 프로그램에 아무것도 말해주지 않는 속성(properties)을 고르며, 검사기(checker)는 쓸모없는 정리와 유용한 정리를 구별할 수 없습니다. 저는 이것을 '바이브 검증(vibe verification)'이라고 부릅니다: 에이전트가 명세와 증명을 작성하고, 검사기가 녹색 신호를 보내지만 아무도 그 명세를 읽지 않습니다. 이는 Verus, Lean, Bend, TLA+, Dafny 등 모든 공식 언어에 적용됩니다.

너무 간단해서 실패할 것 같다고 느껴지는 부분에서 에이전트가 실패한 예시를 들어보겠습니다:

정렬된(sorted) 정렬을 검증해달라고 요청합니다. 그러면 "출력이 정렬되어 있다"는 명세를 작성하고 이를 증명합니다. 그런데 이 명세가 말하지 않은 것은 출력이 입력과 동일한 요소를 가진다는 사실입니다. 따라서 빈 리스트를 반환하는 함수도 이 조건을 만족시키며, 검증기는 그 증명을 수용합니다. 자명하게 충족 가능한(trivially satisfiable) 명세는 예외 상황이 아니라 기본 실패 원인입니다.

실제로 작동하는 공식은 다음과 같습니다. "코드베이스 전체를 형식적으로 검증하라"고 말하지 마십시오. 대신 "[속성]이 [컴포넌트]에서 성립함을 보여라"라고 말하십시오. 속성이란 전제 조건(precondition, 진입 시 참), 후제 조건(postcondition, 나갈 때 참), 또는 불변 조건(invariant, 항상 참인 상태) 중 하나입니다.

예를 들어, "세션 토큰은 폐기된 로그아웃 이후에는 절대 수락되지 않는다"는 좋은 불변 조건입니다.

병목 현상은 코드 검토에서 의도 검토로 넘어가는 것이며, 명세가 바로 의도가 존재하는 곳입니다. 그러므로: 코드를 보기 전에 명세를 읽으십시오. 반드시 받아야 하는 입력 3가지와 거부해야 하는 입력 3가지를 작성하십시오. 모델이 작성한 명세는 극도의 편집증을 가지고 다루고 엔지니어로서의 판단에 의존하십시오.

소프트웨어에 대한 형식 검증(Formal verification)은 신뢰를 자동으로 만들어내지 않습니다. 코드가 아닌 명세(spec)로 신뢰를 이동시킬 뿐입니다. 사람이 명세를 읽지 않았다면, 당신은 아무것도 검증하지 않은 것입니다. 그저 느낌으로만 검증한 것(vibe-verified)에 불과합니다.

검증과 에이전트 공학(agentic engineering)에 대한 더 많은 내용은 저를 팔로우해 주세요.

• Wang, Jiang, Liu et al., "VerusEval: Verifier 수용을 넘어선 LLM 생성 Verus 명세 평가", Shenzhen University, arXiv 2610.26464, 2026년 10월