OpenAI/Hugging Face 사건은 모델 평가 보안을 위한 경종이다

어제 OpenAI와 Hugging Face가 모델 평가(model evaluation) 과정 중 발생한 침해 사고에 대해 밝힌 내용은 단순한 "보안 사고(security incident)"로 규정되었습니다. 만약 당신이 AI 기반 파이프라인을 구축하는 엔지니어라면, 그러한 프레임에 속지 마십시오. 이것은 단순한 데이터 유출이 아니라, eval-as-a-service (서비스형 평가) 아키텍처의 근본적인 실패였습니다.

우리가 프런티어 모델(frontier models)을 평가할 때, 우리는 사실상 제3자 API로부터 온 신뢰할 수 없는 코드를 우리의 독점적인 프라이빗 데이터셋(proprietary private datasets)에 대해 실행하고 있는 것입니다. 이는 보안 측면의 악몽이며, 이제는 새로운 표준(new normal)이 되어버렸습니다.

실패 지점: 대리인을 통한 평가 (Eval by Proxy)

이번 사건의 핵심은 간단합니다. 모델 평가 중에 외부 요청 파이프라인(request pipeline)이 악의적인 입력 페이로드(input payloads)가 평가 코드를 실행 중인 환경과 상호작용할 수 있도록 허용했다는 점입니다.

대부분의 자동화된 평가 프레임워크(주요 연구소들이 사용하는 것들을 포함하여)는 우리가 프로덕션 애플리케이션 코드를 다루는 방식만큼 "샌드박스(sandboxed)" 처리되어 있지 않습니다. 이들은 다음과 같은 이유로 허용적인 환경에서 실행됩니다:

1. 도구 접근 (Tool Access): 모델은 자신의 추론을 증명하기 위해 코드를 실행(Python repls)해야 합니다.
2. 데이터 접근 (Data Access): 평가는 사용자의 프라이빗 테스트 세트를 읽어야 합니다.
3. 환경 지속성 (Environment Persistence): 평가자(Evaluators)는 종종 여러 단계에 걸쳐 컨텍스트를 유지합니다.

해당 환경을 검증되지 않은 모델 프롬프트(model prompt)에 노출하는 것은, 본질적으로 기반 모델을 위한 **RCE (Remote Code Execution, 원격 코드 실행) 허니팟(honeypot)**을 구축한 것과 다름없습니다.

이것이 왜 당신의 보안 모델을 변화시키는가

엔지니어링 팀들은 그동안 LLM을 "안전한 기능적 입력(safe functional inputs)"으로 취급해 왔습니다. 우리는 모델이 단순히 텍스트를 반환한다고 가정합니다. 하지만 평가 문맥(evaluation context)에서 모델은 오케스트레이터(orchestrator)입니다. 만약 오케스트레이터가 악의적인 학습 데이터(train-data)나 오염된 미세 조정(poisoned fine-tunes)에 의해 침해된다면, "평가"는 공격 벡터(attack vector)가 됩니다.

즉시 변경해야 할 세 가지 사항:

1. 평가 루프의 샌드박싱 (Sandboxing the Eval Loop): 만약 로컬 환경이나 공유 클라우드 인프라(Hugging Face Spaces 또는 내부 인스턴스 등)에서 평가 파이프라인 (evaluation pipelines)을 실행하고 있다면, 모델이 탈출을 시도할 것이라고 가정해야 합니다. 모든 평가 단계는 외부 통신(egress)이 차단되고 커널 제한(kernel limits)이 강화된, 수명이 짧은 휘발성 컨테이너 (ephemeral container)에서 실행되어야 합니다.
2. 평가를 위한 데이터 스크러빙 (Data Scrubbing for Evals): 우리는 모델 성능을 테스트하기 위해 가장 민감한 "골든 데이터 (golden data)"를 평가에 투입합니다. 만약 제3자 API를 사용하고 있다면, 해당 데이터는 이제 사실상 모델의 학습 루프 (training loop)의 일부가 됩니다. 차분 프라이버시 (differential privacy)를 사용하거나 엄격하게 정제된 테스트 데이터를 사용하지 않는다면, 데이터가 유출되고 있는 것입니다.
3. "평가 서비스 (Eval Service)" 감사: 프레임워크를 단순히 신뢰하지 마십시오. 만약 사용 중인 도구가 Hugging Face로부터 가중치 (weights)나 API 기반의 완성 응답 (completion responses)을 자동으로 가져온다면, 해당 연결을 신뢰할 수 없는 제3자 입력으로 취급하십시오. 모델 호출의 반환 값에 대해 엄격한 속도 제한 (rate limiting) 및 입력 검증 (input validation)을 구현해야 합니다.

결론

업계가 "서비스형 평가 (Eval-as-a-Service)" 플랫폼을 구축하기 위해 경쟁하는 이유는 우리 모두가 독자적인 평가 파이프라인을 구축하는 것을 두려워하기 때문입니다. 하지만 OpenAI와 Hugging Face가 방금 보여주었듯이, 이를 자동화하는 인프라의 발전 속도가 이를 보호하기 위한 보안의 발전 속도보다 더 빠릅니다.

"평가 (evals)"를 단순히 또 다른 CI 단계로 보지 마십시오. 그것들은 독점적인 데이터를 외부의 블랙박스 (black boxes)로 공급하는 민감한 파이프라인입니다. 그에 따라 행동하십시오.

_참조: OpenAI/Hugging Face 보안 사고 공개 (2026년 7월)