Claude의 형식 검증, 무엇을 증명했나: 테스트에서 바이너리 증명까지

테스트를 더 돌리는 것과 무엇이 달라졌나

Anthropic의 10월 22일 발표는 Theorem과 함께 OSS-Fuzz 라이브러리 123개의 진입점 239개에 대해 조건부 무충돌 증명을 만들었다고 설명한다. 공급자가 보고한 연구 성과이며, 테크독해가 재현한 수치가 아니다. 연구는 단일 스레드의 정적 RISC-V 실행 파일, 모델링된 Linux 환경과 메모리 조건 등을 전제로 한다.

관심을 둘 변화는 증명 작성과 증명 검사를 분리한 개발 방식이다. 기존 퍼징은 여러 입력을 실제로 넣어 실패를 찾는다. 여기서는 테스트 진입점과 실행 파일을 수학적 명제로 표현하고, Claude가 그 명제를 만족한다는 증명을 작성한다. Rocq는 증명이 정해진 논리 규칙에 맞는지 검사한다. 모델의 자연어 설명이 설득력 있는지만 보고 통과시키는 구조가 아니다.

이 글은 2026년 10월 24일 공개 자료를 대조한 분석이다. 공개 증명 저장소는 98e995d4dace, Linux 프로세스 모델은 f1006fe81783 커밋을 기준으로 삼았다. 증명 생성, Rocq 재검사, 실제 서비스 배포는 실행하지 않았다. 아래 업무 상황은 원리를 적용하기 위한 가상 사례다.

AI가 쓰는 것은 증명, 사람이 정해야 하는 것은 질문

파일을 받아 JSON으로 읽는 작은 서비스가 있다고 하자. 팀이 원하는 것은 최소한 세 가지다. 잘못된 파일 때문에 메모리를 잘못 건드리지 않아야 하고, 올바른 파일에서는 올바른 값을 반환해야 하며, 요청이 끝나야 한다. 세 요구를 한꺼번에 “안전함”이라고 부르면 무엇을 검증했는지 사라진다.

요구	검사할 명제의 예	그 명제만으로 알 수 없는 것
무충돌	정한 입력·환경에서 금지된 오류에 도달하지 않음	결과가 요구한 값인지
기능 정확성	출력이 정의된 파싱 규칙과 일치함	제한 시간 안에 끝나는지
종료	허용 입력에서 실행이 반드시 끝남	서비스의 응답 시간 목표를 지키는지

이 표는 특정 도구의 보증 목록이 아니라 요구를 나누는 설명이다. 실제 명제에 더 많은 조건을 넣으면 함께 증명할 수도 있다. 반대로 필요한 조건을 빠뜨리면 아무리 정확한 검사기도 그 누락을 업무 오류라고 판단하지 않는다.

예를 들어 모든 입력에 빈 객체를 즉시 돌려주는 구현은 충돌하지 않고 종료할 수 있다. 하지만 고객이 보낸 {"total":1200}에서 금액을 읽어야 하는 서비스라면 틀렸다. 빈 객체 반환을 금지하는 조건이 명제에 없다면, 무충돌 증명이 성공해도 이 문제는 남는다. 무한 반복하는 구현은 또 다르다. 메모리 오류가 없어도 사용자에게 결과를 주지 못한다.

직접 그린 설명도. 제품 화면이나 증명 실행 결과가 아니다. 점선 영역은 별도 대조가 필요한 조건을 뜻한다.

연구 성과와 공개 증명은 분모가 다르다

공개 OSS Verify README는 라이브러리 25개, 진입점 60개의 증명을 수록했다고 설명한다. 앞의 123개·239개는 연구 전체, 이 수치는 해당 공개 릴리스다. 이를 나눠 공개율이나 검증 성공률을 계산하지 않는다. 발표도 전체 증명의 일부를 공개한다고 명시한다.

더 중요한 차이는 무엇을 증명했느냐다. 공개 묶음의 agreement 명제는 허용된 입력과 메모리 조건에서 일반 빌드와 sanitizer 빌드의 관측 가능한 동작이 일치하고 금지된 오류에 이르지 않는다는 형태다. Sanitizer는 실행 중 특정 오류를 드러내도록 검사를 추가한 빌드다. 보장은 그 도구가 검출하는 오류와 실제 명제의 범위에 묶인다.

README는 이 릴리스에 종료를 보장하는 halts 증명이 없다고 명시한다. 따라서 발표의 정상 종료 설명만으로 공개 증명이 무한 실행도 배제한다고 결론 내릴 수 없다. 저장소에는 증명된 결과 외에 아직 풀지 않은 명제도 있다. 명제가 파일에 존재한다는 것과 그 명제의 증명이 승인됐다는 것은 다르다.

독자가 보고서를 받을 때도 같은 구분이 필요하다. “우리 라이브러리를 검증했다”는 답변에서 멈추지 말고, 증명된 명제의 이름과 상태를 요청한다. 서비스가 멈추는 것이 문제라면 무충돌 항목에 체크하는 대신 종료 명제와 응답 시간 시험을 각각 확인해야 한다.

검사기가 확인하는 연결을 따라가 보자

공식 검사 절차의 oft check는 실행 파일의 SHA-256을 확인하고, ELF의 메모리 이미지와 명제를 만든 뒤 증명을 컴파일한다. 이어 검사기 쪽에서 만든 래퍼로 증명의 타입이 지정된 명제와 맞는지 확인한다. 마지막으로 Print Assumptions 출력이 허용한 가정 목록 안에 있는지 검사한다. 증명자가 다른 문제를 풀어 제출하거나 원하는 결론을 가정으로 넣는 일을 제한하는 구성이다.

이 절차를 문서 승인에 비유하면 서명이 맞는지만 보는 대신, 그 서명이 지금 승인받으려는 문서에 붙어 있는지까지 확인하는 셈이다. 증명 파일이 많거나 길다는 사실은 이 연결을 대신하지 않는다.

다만 검사기만 정확하면 모든 일이 끝나는 것은 아니다. 신뢰 범위 문서는 Rocq 커널과 허용 공리 외에도 Linux 프로세스 모델, ELF를 메모리 이미지로 옮기는 도구, 검사 래퍼와 가정 해석, 명제 본문 등을 신뢰해야 한다고 설명한다. 컴파일러가 원본 소스를 정확하게 번역했다는 관계는 이 보장의 대상이 아니다. 증명이 가리키는 것은 해시로 식별한 바이너리다.

이것은 실무적으로 중요한 선택이다. 소스를 수정하지 않았더라도 다른 옵션이나 라이브러리로 다시 빌드한 파일이면, 기존 증명에 이름만 붙여 승계할 수 없다. 새 파일에 같은 명제가 성립한다는 연결이 필요하다. 반대로 증명한 바로 그 파일을 배포한다면 파일 해시 대조가 그 연결의 한 부분이 된다. 어느 경우든 실행 환경과 호출 방식까지 같다는 뜻은 아니다.

파싱 서비스에 적용하면 결론이 갈리는 세 경우

아래는 특정 라이브러리에서 발견한 결함이 아니라, 증명 자료를 받은 팀의 가상 도입 검토다.

A팀은 검증된 진입점과 같은 바이트 처리 함수를 별도 작업자에서 쓴다. 먼저 요청을 그 진입점의 입력으로 바꾸는 어댑터가 조건을 보존하는지 확인한다. 증명된 바이너리·입력 범위·메모리 전제가 맞으면 해당 오류를 배제하는 근거로 사용할 수 있다. 파일 업로드 인증, 작업 대기열, 결과 저장은 별도 서비스 경로이므로 그에 맞는 시험을 유지한다.

B팀은 같은 소스를 ARM 서버용으로 빌드한다. 라이브러리 이름과 버전은 같아도 이번 RISC-V 바이너리의 증명을 ARM 실행 파일에 직접 적용할 수 없다. 이 팀은 공개 증명을 설계 참고 자료로 활용하면서 ARM 빌드에 필요한 검증을 따로 확보해야 한다. “소스가 같으니 같을 것”은 호환성 가설이지 증명 결과가 아니다.

C팀은 하나의 프로세스에서 여러 요청을 동시에 처리한다. 공개 모델의 범위는 단일 스레드를 전제로 하며 스케줄러를 포함하지 않는다. 신호 처리기와 파일 시스템에도 제한이 있다. 따라서 공유 상태의 경쟁이나 권한·심볼릭 링크 문제를 이 증명으로 해결했다고 볼 수 없다. 쓰레드 간 상태를 없애는 설계가 도움이 될 수는 있지만, 그것만으로 모델 일치가 자동 성립하지는 않는다.

이렇게 보면 도입 판단의 단위는 “검증된 라이브러리”보다 작고 구체적이다. 어떤 입력을 어떤 진입점에 넣고, 어떤 실행 파일을 어떤 조건에서 돌리는가가 단위다. 이 연결이 분명한 기능부터 적용 범위를 넓히는 편이 검토 가능한 결정을 만든다.

증명하기 쉽게 고친 코드가 기능을 잃지는 않았나

앞서 모든 입력에 빈 객체를 반환하는 반례를 떠올려 보자. 충돌을 없애려는 목표만 주면 필요한 기능을 지워도 목표를 만족할 수 있다. 그래서 코드 수정과 증명 성공을 함께 볼 때에는 바뀐 동작을 확인해야 한다.

증명 생성 경위 문서는 일부 증명이 이전 빌드에서 작성됐고, 현재 릴리스의 바이너리와 모델 버전에 맞게 조정한 뒤 다시 검사됐다고 설명한다. 독자가 내려받아 검사할 수 있는 결과물과 동일한 비용으로 새 증명을 생성하는 능력은 별개의 조건이다.

실무에서는 패치 전후 입력·출력을 비교하고, 의도적으로 거절하게 바뀐 입력과 계속 처리해야 하는 입력을 나눈 기록이 필요하다. “이제 오류가 없다”는 문장 아래 정상 입력을 전부 거절하게 만든 변경이 숨어 있지 않은지 확인하는 것이다. 이 대조는 증명 검사기를 대체하지 않는다. 어떤 기능을 보장할 것인지 정하는 단계에 필요한 자료다.

첫 도입 검토는 이 다섯 칸에서 시작한다

전체 서비스의 증명부터 요구하기보다, 외부 입력을 처리하는 작은 기능 하나를 정해 다음 표를 채울 수 있다. 이것은 편집 분석에서 만든 검토 양식이며 제품의 공식 인증 절차가 아니다.

남길 항목	구체적으로 적을 내용	빈칸이면 다음 행동
대상	진입점, 바이너리 해시, 빌드 기록	사용 중인 파일과 증명 대상 대조
명제	무충돌·기능 규칙·종료 중 증명한 것	명제 본문과 증명 상태 요청
조건	입력, 메모리, OS·CPU, 스레드·호출 전제	우리 환경과 다른 조건 표시
재검사	검사기·모델 버전, 실행 로그와 허용 가정	재검사할 환경과 자원 확보
남은 기능	정확한 출력, 응답 시간, 권한, 패치 후 변화	별도 테스트·리뷰 범위 지정

빈 검토 양식 내려받기. 글의 저장 기능으로 다시 찾고, 후속 설명은 소프트웨어 주제 모음에서 이어 볼 수 있다.

첫 파일럿의 성공 기준도 구체적으로 정하는 편이 좋다. “AI가 안전하다고 했다” 대신, 선택한 명제의 재검사를 마치고 우리 실행 경로와 다른 조건을 설명할 수 있는지를 본다. 이후 변경 때 증명을 다시 만들거나 확인하는 비용까지 기록해야 지속 가능한지 판단할 수 있다. 이번 자료 대조만으로 비용 절감률이나 보안 사고 감소를 말할 수는 없다.

배포물에서 코드와 관계를 찾아내는 단계는 REA 분석, 파일의 출처와 릴리스 동일성을 확인하는 단계는 SBOM·출처 증명과 연결된다. 각각 답하는 질문을 유지하면서 함께 사용하면, 찾은 코드에서 배포 판단까지 어떤 근거가 더 필요한지 명확해진다.