AI 코딩·소프트웨어 보안
AI가 코드를 검사하는 데서 증명을 쓰는 단계로 나아갑니다
앤트로픽과 Theorem은 클로드로 123개 오픈소스 라이브러리의 239개 진입점을 검증했다고 발표했습니다. 보장은 정해진 입력과 실행 환경·명세 안에 한정됩니다.
이 글에서 다룰 내용
발표의 핵심 수치, 퍼징과 형식 검증의 차이, 증명의 조건과 남는 버그, 개발팀이 확인할 것
123개 라이브러리에서 무엇을 증명했을까요
클로드가 오픈소스 라이브러리를 검증했다는 소식에서 먼저 구분할 것은 ‘특정 속성의 증명’과 ‘버그 없는 소프트웨어’입니다. 이번 발표는 전자이며 라이브러리 전체가 완벽하다는 선언은 아닙니다.
앤트로픽은 2026년 10월 22일 Theorem과의 공동 연구를 공개했습니다. 구글의 오픈소스 퍼징 프로젝트 OSS-Fuzz에 포함된 123개 라이브러리에서 239개 진입점을 대상으로 수주 동안 버그를 패치한 뒤 정해진 조건에서 충돌하지 않는다는 속성을 증명했습니다.
진입점은 테스트 입력이 코드로 들어가는 입구입니다. 따라서 123개 라이브러리를 다뤘다는 숫자와 모든 코드를 검증했다는 주장은 다릅니다.
퍼징은 사례를 시험하고, 형식 검증은 범위를 증명합니다
퍼징은 자동으로 만들거나 변형한 입력을 반복해서 넣으며 프로그램이 충돌하는지 살펴보는 방법입니다. 많이 실행할수록 다양한 문제를 찾을 수 있지만 시험하지 않은 입력까지 안전하다고 보장하지는 못합니다.
이번 형식 검증은 기존 퍼징 테스트를 ‘이 조건에서는 충돌하지 않는다’는 수학적 명세로 바꿨습니다. 명세는 검증할 규칙을 정확하게 적은 것으로, 여기서는 지정된 범위의 모든 입력에 대해 no-crash, 즉 충돌하지 않는 속성을 증명하는 기준입니다.
많은 입력에서 문제가 없었다는 관찰과, 정해진 범위 전체에서 문제가 없다는 증명은 다릅니다. 다만 그 범위를 벗어난 환경이나 명세에 담지 않은 문제까지 해결되는 것은 아닙니다.
클로드가 작성하고 Rocq가 검산합니다
클로드는 증명 코드를 작성하고 Rocq의 증명 검사기는 그 증명이 명세를 만족하는지 검산합니다. 연구에서 생성된 Rocq 증명 코드는 약 1억8000만 줄로, AI의 설명을 그대로 믿는 대신 별도 검사기로 논리를 확인하는 구조입니다.
여기서 소프트웨어 검증의 핵심은 증명 코드의 분량보다 역할 분담입니다. AI 코딩으로 증명을 만들어도 검사기가 확인하는 것은 주어진 명세와의 일치이지, 명세 자체가 현실을 빠짐없이 담았는지는 아닙니다.
보장이 성립하는 실행 조건이 있습니다
주 실험의 대상은 Linux에서 실행되는 RISC-V CPU용 단일 스레드 정적 바이너리입니다. RISC-V는 CPU의 명령어 체계이며, 정적 바이너리는 필요한 라이브러리 코드를 실행 파일에 포함한 형태입니다.
검증에는 고정된 메모리 예산과 64MB 미만의 입력이라는 조건도 붙습니다. 운영체제의 응답과 메모리 배치 역시 연구에서 모델링한 범위에 해당하므로, 실제 장비에서 일어날 모든 상황을 제한 없이 보장한다고 읽으면 안 됩니다.
실제 배포와의 차이도 중요합니다. 검증 대상은 musl과 연결된 정적 RISC-V 바이너리지만, 실제 서비스에서 쓰는 x86·ARM 및 동적 glibc 환경에는 차이가 있습니다.
공식 글에는 x86 바이너리를 다룬 별도의 zlib 사례도 등장합니다. 그러나 이를 주 실험과 합쳐 123개 라이브러리가 실제 x86 배포 환경에서도 모두 검증됐다고 해석해서는 안 됩니다.
충돌하지 않는다고 모든 보안 문제가 사라지지는 않습니다
이번 연구는 각 라이브러리의 모든 진입점을 검증하지 않았습니다. 모든 진입점을 다뤘더라도 실행되지 않는 코드 등을 포함한 라이브러리 전체의 무결성과 곧바로 같아지는 것은 아닙니다.
메모리 오류를 실행 중 탐지하는 AddressSanitizer, 즉 ASan도 모든 메모리 오류를 잡지는 못합니다. 라이브러리를 호출하는 프로그램이 사용 규칙을 어겨 발생시키는 문제 역시 별도로 살펴야 합니다.
그래서 오픈소스 보안을 평가할 때는 ‘검증 완료’라는 표현보다 무엇을 증명했는지 먼저 확인하는 편이 좋습니다. 충돌 여부와 기능의 올바른 동작, 호출자의 안전한 사용은 구분해서 질문해야 합니다.
증명을 시도하는 과정에서도 버그를 찾았습니다
공식 글은 증명 시도 과정에서 수백 개의 버그를 발견했다고 설명합니다. 버그를 고친 뒤 바뀐 코드에 맞춰 명세를 다시 만들고 증명을 이어갔다는 점에서, 패치 전 코드가 처음부터 안전했다는 의미는 아닙니다.
일부 증명과 RISC-V·운영체제 의미론, Claude skill은 공개됐습니다. 의미론은 명령어와 운영체제 동작을 수학적으로 정의한 규칙이며 미패치 버그를 드러낼 수 있는 증명은 공개하지 않습니다.
그럼에도 명세, RISC-V·Linux 모델, Rocq 자체에 대한 신뢰는 남습니다. 증명이 통과했다는 결과와 검증의 바탕까지 완벽하다는 주장은 구분해야 합니다.
개발팀은 검증 범위를 먼저 확인하면 됩니다
다음은 공식 발표의 성과와 구분되는 일반적인 검토 권고입니다. 개발팀이라면 적용 전에 대상 버전과 패치, 검증한 진입점, 입력 제한, 메모리 예산, CPU와 라이브러리 연결 방식을 확인하는 것이 좋습니다.
이번 발표는 전면적인 제품 출시나 모든 보안 문제의 해결 선언이 아닙니다. AI가 증명을 작성하고 검사기가 확인하는 연구 성과로 받아들이되 실제 서비스에 적용할 때는 증명의 전제와 배포 환경을 나란히 놓고 판단해야 합니다.
한 줄 요약: 클로드의 성과는 ‘버그 없는 소프트웨어’가 아니라, 명시한 조건과 범위에서 특정 보안 속성을 증명한 것입니다.
참고 출처
2026년 10월 22일 앤트로픽과 Theorem의 공식 연구 발표를 기준으로 정리했습니다. 수치와 성과는 해당 연구의 조건에 한정됩니다. Google News RSS에서 공식 출처명·정확 제목·발행 시각도 교차 확인했습니다.
