구글 딥마인드는 어떻게 Gemini를 모델과 테스트 문항 공개 없이 평가했나

구글 딥마인드가 AI 안전성 평가의 오래된 딜레마에 새로운 해법을 제시했다. 평가자는 테스트 문항을 공개하지 않고, 모델 개발자는 독점 모델의 가중치를 넘기지 않는 방식이다.

구글 딥마인드는 2026년 8월 27일 싱가포르 AI 안전 연구소, OpenMined, AVERI, MLCommons와 함께 Gemini 2.5 Flash-Lite를 대상으로 한 시범 평가를 공개했다. 구글은 이를 독점적 프런티어급 AI 모델에 대한 최초의 ‘이중 블라인드(double-blind) 평가’라고 설명했다. 1213

핵심은 모델과 평가 데이터라는 두 가지 민감한 자산을 모두 봉인한 채, 승인된 계산만 수행하는 것이다. 일반적인 안전성 테스트에서는 개발자가 비공개 테스트 문항을 전달받거나, 외부 평가자가 모델 가중치에 접근해야 하는 경우가 많다. 전자의 경우 문항이 기록되거나 이후 학습에 의도치 않게 활용돼 테스트가 오염될 수 있고, 후자는 기업의 핵심 지식재산과 민감한 능력을 노출할 위험이 있다.

Gemini 평가에서 실제로 테스트한 것

이번 파일럿은 MLCommons의 AI 안전성 벤치마크 제품군인 AILuminate에서 소규모 비공개 문항을 선별해 진행됐다. AVERI에 따르면 해당 문항은 이전에 구글 딥마인드에 노출되지 않았으며, 사이버 공격 지원, 화학·생물학적 위험, 혐오 발언, 자해, 폭력 범죄 유도 등 여러 영역의 안전성 대응을 살펴보는 데 사용됐다. 1

벤치마크 문항은 평가 내내 비공개로 유지됐다. AVERI가 문항을 암호화하고, 보호된 실행 환경에서 모델과 평가 절차를 구동한 뒤, 결과를 복호화해 사전에 합의한 기준으로 채점하는 방식이었다. 이번 프로젝트의 목적은 일반적인 공개 순위표를 만드는 것이 아니라 평가 방법 자체를 시연하는 데 있었기 때문에, 대표 점수나 원문 문항은 공개되지 않았다. 1

‘이중 블라인드’는 어떻게 작동했나

평가는 Google Cloud Confidential Computing의 Confidential Space에서 A3 Confidential VM을 사용해 진행됐다. 기술 보고서에 따르면 Intel TDX는 호스트 메모리를 암호화하고 격리했으며, NVIDIA H100 Confidential GPU는 하드웨어 기반 암호화를 통해 GPU 메모리의 모델 가중치를 보호했다. 평가자의 문항과 구글의 모델 자산은 암호화된 연결을 통해 보호된 환경으로 전달됐다. 13

시스템에는 실행 가능한 작업과 외부로 반환되는 결과를 제한하기 위한 여러 통제 장치도 적용됐다. 암호화된 데이터 경로, 하드웨어 방화벽, 수명이 짧은 임시 인클레이브(enclave), OpenMined의 PySyft 정책 계층 등이 여기에 포함된다. 모델, 추론 코드, 테스트 문항, 평가 코드는 승인된 인클레이브 내부에서만 결합됐고, 합의된 계산과 제한된 결과 반환만 허용됐다. 13

원격 인증이 중요한 이유

암호화만으로는 인클레이브 안에서 실제로 어떤 소프트웨어가 실행되는지 알 수 없다. 원격 인증(remote attestation)은 이 문제를 보완하기 위한 장치다.

구글과 평가기관은 보호된 자산을 보내기 전에 실행될 작업을 확인하고, 하드웨어와 인클레이브 구성을 식별하는 인증 증거를 검증할 수 있었다. 이 검증이 끝난 뒤에야 암호화된 테스트 문항과 모델 자산이 실행 환경에 제공됐다. 13

평가가 끝나면 인클레이브는 허용된 평가 결과만 반환한 뒤 폐기됐다. 의도된 신뢰 모델에서는 구글이 인클레이브 안의 테스트 문항을 읽을 수 없고, 외부 평가자는 모델 가중치를 추출할 수 없다. 이는 단순히 ‘데이터를 기록하거나 재사용하지 않겠다’는 계약상 약속보다 강한 보호 방식이다. 다만 모든 신뢰 가정을 없애는 것은 아니다. 13

이 방식이 해결하려는 문제

AI 평가에서 ‘벤치마크 오염’은 지속적인 문제다. 모델이 학습, 미세 조정, 이전 평가 과정에서 테스트 문항을 접했다면 해당 시험의 결과는 모델의 실제 능력을 제대로 보여주기 어렵다. MLCommons는 신뢰할 수 있는 벤치마크를 위해 데이터의 청결성, 출처 기록, 신중한 표본 추출, 결과 산출 과정에 대한 충분한 투명성이 필요하다고 설명한다. 2024

이중 블라인드 평가는 다음과 같은 두 가지 불완전한 선택지 사이에 제3의 경로를 제시한다.

• 개발자에게 테스트 문항을 제공하는 방식: 배포와 평가가 간단하지만, 비공개 벤치마크가 노출돼 이후 학습이나 최적화에 활용될 위험이 있다.
• 평가자에게 모델 가중치를 제공하는 방식: 테스트 문항을 모델 개발자로부터 보호할 수 있지만, 프런티어급 독점 모델에서는 지식재산과 오용 위험 때문에 현실적으로 받아들이기 어렵다.
• 기밀 인클레이브를 사용하는 방식: 모델과 벤치마크를 하드웨어로 보호된 환경에서 만나게 하면서, 어느 쪽도 상대방의 비밀 자산을 평문으로 받지 않는다.

따라서 이번 파일럿은 양측의 기밀성을 유지하면서 외부 평가를 실행할 수 있는 현실적인 메커니즘을 보여준다. 다만 이것만으로 해당 모델의 안전성 결론이 완전하거나 독립적으로 확정됐다고 볼 수는 없다.

이번 파일럿의 중요한 한계

기술적으로 의미 있는 시연이었지만, 결과를 해석할 때는 몇 가지 제약을 고려해야 한다.

첫째, 평가자는 인클레이브에 선언된 작업과 모델 인터페이스는 확인할 수 있었지만, 구글의 독점 가중치나 추론 구현을 독립적으로 검사할 수는 없었다. 따라서 실행 환경이 모든 측면에서 의도한 대로 작동했는지 완전히 감사하는 데 한계가 있다. 13

둘째, 운영 환경 전체를 외부 기관이 독립적으로 재현할 수 있었던 것은 아니다. 배포와 클라우드 인프라는 구글의 통제 아래 있었고, 이해관계가 없는 제3자가 처음부터 다시 구축해 재실행한 구조는 아니었다. 원격 인증 과정 역시 Google Cloud의 하드웨어, 펌웨어, 모델 서빙 시스템, 인증 인프라에 의존했다. 하드웨어 기반 검증은 단순한 무기록 약속보다 강력하지만, 더 넓은 공급망과 클라우드 사업자에 대한 의존까지 제거하지는 않는다. 13

셋째, 비공개 문항과 수치 결과가 공개되지 않았다. 문항을 숨기는 것은 향후 평가에서 벤치마크의 가치를 보존하는 데 도움이 되지만, 동시에 대중의 검증, 모델 간 비교, 평가 결과에 대한 독립적 확인을 어렵게 만든다. AVERI 역시 이번 작업을 완전한 공개 벤치마크 결과가 아니라 정성적 평가와 소규모 정량 평가로 규정했다. 1

왜 아직 업계 표준은 아닌가

보안 하드웨어는 평가 문제의 한 부분만 해결한다. 이중 블라인드 테스트가 지속 가능한 업계 관행이 되려면 이를 둘러싼 거버넌스도 함께 발전해야 한다.

법적·제도적 보호에는 데이터 처리, 허용되는 출력, 공개 규칙, 책임 소재, 접근 권한이 명확히 포함돼야 한다. 특히 위험한 능력을 다루는 평가라면 더욱 그렇다.

벤치마크 관리 체계는 문항의 출처, 표본 추출, 라벨링, 문서화, 업데이트 절차, 오염 모니터링을 다뤄야 한다. MLCommons는 벤치마크가 단순히 비공개라는 이유만으로 신뢰성을 얻는 것이 아니라, 구축과 유지 방식 자체가 타당해야 한다고 강조한다. 2025

독립적 재현성을 확보하려면 모델 제공자와 클라우드 운영자 외부의 기관이 빌드 과정, 인증 체인, 실행 정책, 보고된 결과를 의미 있는 수준으로 검증할 수 있어야 한다.

확장성도 관건이다. 실질적인 표준이 되려면 하나의 하드웨어 구성과 일회성 협업을 넘어, 여러 모델 개발사·모델 구조·클라우드 환경·평가기관·벤치마크 유형·모델 출시 주기에 적용될 수 있어야 한다.

구글 딥마인드의 Gemini 파일럿은 벤치마크 신뢰 문제의 최종 해답이라기보다, 더 까다로운 AI 평가를 가능하게 하는 인프라 실험에 가깝다. 이 방식은 테스트 데이터와 독점 모델을 동시에 보호해야 하는 충돌을 기밀 컴퓨팅으로 줄일 수 있음을 보여줬다. 하지만 업계 규모에서 신뢰할 만한 증거가 되려면 인클레이브 암호화만으로는 부족하다. 독립적 감독, 건전한 벤치마크 관리, 법적 보호, 재현성, 운영 현실성이 함께 뒷받침돼야 한다. 1320