구글 딥마인드 · 2026년 11월 10일 연구 공개
AlphaProof Code, Signal 핵심 암호 코드 검증에서 사람과 AI의 역할을 나눴습니다
구글 딥마인드는 Signal의 핵심 암호 구현을 4주 동안 형식 검증한 연구를 공개했습니다. AI가 증명을 만들고 Lean이 검사하지만 명세·가정·검증 범위를 판단하는 일은 사람에게 남습니다.
이 글에서 다룰 내용
검증 대상과 연구 공개 범위, 형식 검증과 테스트, 사람·AI·Lean의 역할, 기간과 증명 규모, 과거 버그 실험, 가정과 한계
공개된 것은 앱이 아니라 암호 코드 검증 연구입니다
알파프루프 코드는 AI가 만든 증명을 기계적으로 검사합니다. 구글 딥마인드는 2026년 11월 10일 AlphaProof Code 연구를 공개했습니다. 새 소비자 앱이나 상용 API를 정식 출시한 발표는 아닙니다.
연구팀은 AI 에이전트를 안내해 Signal 프로토콜의 핵심 암호 구현이 사람이 정한 보안 성질을 만족하는지 검증했습니다. 공식 기술 문서의 실제 대상은 libsignal 참조 구현을 수정하지 않고 일반 Rust 컴파일러로 컴파일한 AArch64 Linux 기계코드입니다.
“Signal 전체가 검증됐다”는 해석은 범위를 벗어납니다. 앱 화면, 계정 관리, 서버, 운영체제와 하드웨어까지 모두 안전하다고 확인한 연구는 아닙니다.
형식 검증은 테스트와 무엇이 다를까요?
테스트는 입력을 넣고 예상한 결과가 나오는지 확인합니다. 사례를 잘 설계하면 오류를 찾는 데 도움이 되지만 통과한 사례만으로 모든 상황의 안전을 입증하기는 어렵습니다.
형식 검증은 원하는 성질을 수학적 명세로 적고 그 명세가 성립한다는 증명을 검사하는 방식입니다. 여기서 명세는 “이 코드는 안전해야 한다”는 막연한 문장이 아니라, 어떤 조건에서 무엇을 보장할지 구체적으로 표현한 약속에 가깝습니다.
다만 증명이 통과했다고 현실의 모든 문제가 사라지는 것은 아닙니다. 처음 정한 약속이 실제로 필요한 보안 요구를 담았는지, 빠뜨린 조건은 없는지도 따져야 합니다.
사람은 명세를 검토하고, AI는 증명을 만듭니다
이 연구에서는 사람과 여러 모델이 보안 목표를 Lean 명세로 작성하고 전문가가 모든 명세를 검토합니다. Gemini Carbon 기반 에이전트들은 증명을 생성하며 Lean 커널이 그 증명을 검사합니다.
기술 문서의 gatekeeper는 제출된 증명이 정확히 승인된 명세를 증명했는지도 대조합니다. 다른 문제를 풀어 놓고 성공으로 처리하지 않도록 확인하는 역할입니다.
AI가 그럴듯한 보안 설명을 쓰는 것과 Lean이 명세에 맞는 증명을 검사하는 것은 다릅니다. 그러나 검사기가 증명을 받아들였다는 사실만으로 명세와 가정 자체의 적절성까지 자동으로 확인되는 것은 아닙니다. 이 부분에는 여전히 사람의 판단이 필요합니다.
4주와 600만 줄 이상은 어떻게 읽어야 할까요?
공식 블로그는 4주 동안 600만 줄 이상의 Lean 증명 코드를 만들었다고 발표했습니다. 기술 문서는 약 650만 줄이라고 표현합니다. 이는 제품 기능을 구현한 코드의 분량이 아니라 검증을 위한 증명 코드의 규모입니다.
큰 검증 작업에서 AI 에이전트가 증명 생성을 맡았다는 데 의미가 있습니다. 다만 이 수치를 사람이 전혀 개입하지 않은 완전 자동화 성과로 해석해서는 안 됩니다.
기존에는 수년이 걸렸다는 비교도 같은 시스템과 동일한 팀으로 진행한 대조실험 결과는 아닙니다. 모든 소프트웨어를 4주 안에 검증할 수 있다는 보장이나, 일반적인 개발 생산성 수치로 바꿔 말할 근거도 없습니다.
버그 두 개는 새 취약점 발견이 아닙니다
연구팀은 과거에 이미 수정된 실제 버그 두 개를 격리된 버전에 다시 넣는 실험도 진행했습니다. 그 결과 해당 버전이 안전하지 않다는 기계 검사 증명을 얻었습니다.
이는 안전한 경우의 증명뿐 아니라, 의도적으로 되살린 문제를 검증 과정에서 다룰 수 있는지 살펴본 실험입니다. “현재 Signal에서 미공개 취약점 두 개를 새로 찾았다”는 뜻은 아닙니다.
연구 검증 산출물은 오픈소스로 공개한다는 것이 공식 발표입니다. 여기서 설명하는 결과는 그 발표와 기술 문서에 따른 것이며 이 글에서 직접 증명을 실행해 재현한 결과는 아닙니다.
보안 보장은 가정과 범위 안에서 성립합니다
검증한 성질에는 전방 비밀성, 인증, 침해 후 보안 등이 포함됩니다. 범위는 일대일 세션과 PQXDH 핸드셰이크, Triple Ratchet에 해당합니다.
쉽게 말해 전방 비밀성은 나중의 키 유출이 과거 메시지에 미치는 영향을, 침해 후 보안은 침해 이후 보안을 회복하는 성질을 다룹니다. 하지만 어떤 키가 유출돼도 모든 상황에서 메시지가 안전하다는 뜻은 아닙니다.
보안 성질은 구체적인 위협 모델, 명세, 암호 기본 연산에 대한 가정과 실행 환경에 의존합니다. 사이드채널이나 그룹 메시지, 모든 플랫폼까지 포괄하지 않으며 양자컴퓨터로부터 모든 메시지를 영구히 보호한다고 단정할 수도 없습니다.
의료기기나 전력망에 적용하는 이야기도 미래 연구의 확장 가능성입니다. 실제 배치 성과가 아니며 별도 보안 프로그램인 CodeMender의 기능을 AlphaProof Code의 기능으로 합쳐 읽어서도 안 됩니다.
AI 코딩에서도 무엇을 보장할지 먼저 정해야 합니다
AI 코딩에서도 검증 목표를 먼저 정해야 합니다. 코드를 얼마나 빨리 만드는지와 함께, 무엇을 보장하고 어떤 증거로 확인할지를 정해야 합니다.
일반적인 실무 권고로 옮기면 중요한 코드부터 실패하면 안 되는 조건을 문서화하고 그 조건에 맞는 검증 방법을 선택할 수 있습니다. 이는 연구에서 제공하는 공식 도입 기능이 아니라, 연구의 의미를 업무에 적용해 보는 관점입니다.
테스트와 코드 리뷰를 전부 폐기할 이유는 없습니다. 형식 검증이 다루는 범위와 실제 서비스 운영에서 확인해야 할 문제를 구분하며 함께 사용하는 편이 적절합니다.
한 줄 요약: AlphaProof Code의 의미는 Signal 전체의 안전 선언이 아니라, 사람이 정한 보안 명세를 AI가 생성한 증명과 Lean 검사로 확인한 데 있습니다.
참고 출처
2026년 11월 10일 Google DeepMind 공식 발표와 기술 문서를 확인했습니다. 검증 기간·코드 규모는 연구팀 발표 기준이며 직접 재현한 결과는 아닙니다. Google News RSS로 공식 출처명과 발행일을 교차 확인했습니다.
