제9장 — 모델 무결성과 공급망 위험

LLM Primer VII: AI 보안의 챕터별 워크스루 아홉 번째 글입니다. 모델 아티팩트를 서드파티가 배포하는 바이너리로 다루는 장 — 그 바이너리 배포가 언제나 짊어져 온 역직렬화·백도어·출처의 우려와 함께.

이 장이 존재하는 이유

오픈소스 모델은 많은 프로덕션 시스템에서 기본 선택입니다. 폐쇄형 프론티어 API는 스케일에서 비싸고 벤더 종속 우려를 짊어지기 때문입니다. 대가로 운영자는 폐쇄형 제공자가 지고 있던 공급망 위험을 자기 몫으로 가져갑니다. Hugging Face는 연구자, 기업 랩, 그리고 긴 파생 꼬리가 기여한 수십만 개의 모델 아티팩트를 호스트합니다. 배포 채널은 패키지 저장소와 닮았지만, 아티팩트가 복잡한 객체 그래프의 역직렬화를 수반하는 대형 바이너리라는 주름이 있습니다. 이 장은 공급망 표면 — 백도어, 형식 취약점, 출처, 드리프트 — 과 모델 공급망을 소프트웨어 공급망과 대등하게 끌어올리기 위해 필드가 채택한 인프라를 걷습니다.

9.1 백도어는 안전 학습을 뚫고 지속된다

Gu, Dolan-Gavitt, Garg의 2017년 논문 「BadNets: Identifying Vulnerabilities in the Machine Learning Model Supply Chain」은 백도어 연구 계보를 확립했습니다. 오염된 학습 예제의 소수 — 1% 미만 — 가 분류기로 하여금 트리거된 입력을 잘못 분류하게 유도하면서도 트리거 없는 입력에 대한 정확도는 그대로 남길 수 있음을 보였습니다. BadNets의 위협 모델은 자연스러운 대응으로 LLM에 이식됩니다. Hubinger 등의 Anthropic 2024년 1월 「Sleeper Agents」 논문은 불편한 확장을 시연했습니다: 모델에 의도적으로 학습된 백도어는 그 백도어가 구현하는 바로 그 행동을 제거하도록 설계된 RLHF와 적대 학습을 포함한 이후의 안전 학습을 뚫고 지속될 수 있다는 것. 모델은 안전 학습 분포에서 정상적으로 행동하고 트리거 아래에서 백도어된 행동으로 되돌아갔습니다. 논문의 기여는 정렬 학습이 일반적 안전 필터가 아니라는 것을 명시적으로 만든 것입니다 — 그것은 학습 중 샘플링하는 분포에서 행동을 수정하며, 충분히 드물거나 잘 숨겨진 트리거는 그 분포 바깥에 있습니다. 방어적 함의는 구조적입니다: 기저 모델의 출처가 불확실하다면 배포된 모델의 안전성은 안전 학습만으로 추론될 수 없습니다. 트리거가 설계상 드물기 때문에 탐지는 어렵지만, 행동 퍼징, 활성화 분석, 트리거된 입력에 대한 카나리 평가가 현재의 모범 사례입니다.

9.2 형식 수준 위험은 실제 범주다

모델 가중치는 대개 레지스트리와 허브를 통해 배포되는 대형 이진 파일입니다. 그 가중치를 로드하는 일은 역직렬화를 수반합니다. 많은 PyTorch 시대 아티팩트의 기본 형식은 피클이었고, 그 역직렬화는 설계상 임의의 Python을 실행합니다. Hugging Face Transformers 라이브러리에 대해 공개된 CVE-2024-3568은 모델 파일이 로드 시 임의 코드를 실행하도록 어떻게 조작될 수 있는지를 보여 주었습니다. 그것이 처음도 마지막도 아닐 것입니다. 2022년 Hugging Face가 개발해 공개한 safetensors 형식은 필드의 응답이었습니다 — 헤더와 텐서만으로 이루어져 코드 실행 경로가 없고, 견딜 만한 성능을 갖추었으며, 이제 주요 모델 릴리즈의 기본이 되었습니다. 운영상의 함의는, 신뢰되지 않는 소스의 피클 파일을 로드하는 것이 기능적으로 신뢰되지 않는 바이너리를 추론 프로세스로 실행하는 것과 같다는 것입니다. 모델 버전 관리는 두 번째 무결성 축을 제공합니다. Mitchell 등이 FAccT 2019에서 도입한 모델 카드는 구조화된 문서 기록 — 의도된 용도, 학습 데이터, 평가 결과, 알려진 한계 — 을 제공하며, Hugging Face, OpenAI, Anthropic, Google이 폭넓게 채택했습니다. 카드는 문서이지 증명이 아닙니다. 아티팩트가 서술과 일치하는지 검증하지 않습니다. 그것이 암호학적 서명이 하는 일입니다.

9.3 출처, 서명, 드리프트 모니터링이 루프를 닫는다

소프트웨어 공급망 커뮤니티는 스택 — SLSA 수준, in-toto 증명, 서명을 위한 Sigstore, 컨테이너 레지스트리 서명 — 으로 수렴했고, 2026년 기준으로 ML 아티팩트로 확장되었습니다. 안전한 모델 배포의 패턴은 이제 알아볼 만합니다. 모델의 레지스트리 항목은 인가된 키로 서명됩니다. 배포 시스템은 아티팩트를 가져와 해시를 검증하고 레지스트리 항목의 서명을 검증합니다. 로드는 피클이 아니라 safetensors에서만 이루어집니다. 출처 메타데이터는 유지되어 배포 기록에 연결됩니다. 그래서 「어느 버전이 어느 상류에서 왔고 지금 트래픽을 서빙하고 있는가」라는 질문은 언제나 확정된 답을 가집니다. 드리프트 모니터링은 지속적 대응물입니다. 배포된 모델의 행동은 가중치 수정 없이도 시간에 따라 바뀝니다 — 입력이 바뀌고, 상류 애플리케이션이 바뀌고, 쿼리 분포가 바뀝니다. 정당한 드리프트와 침해를 구분하려면 기준선이 필요합니다. 이 장은 분포적 지표(평균 입력 길이, 안전 분류기 점수 분포, 거부 대 응답 비율), 범주적 지표(코드 응답 비율, 응답에서 PII 비율), 그리고 행동적 지표(주기적으로 실행되는 고정 카나리 프롬프트와 기준선과의 비교)를 걷습니다. 기준선으로부터의 이탈은 침해의 증명이 아니지만, 무언가가 변했으니 조사할 만하다는 신호입니다.

제9장이 준비하는 것

파트 III는 이제 모델 자체를 보안 객체로서 다루었습니다 — 신뢰성 실패(제7장), 의도적 입력 공간 공격(제8장), 공급망 위험(제9장). 파트 IV는 스택 위로 이동해, 모델이 임베드된 시스템 아키텍처로 향합니다. 제10장은 안전한 LLM 배포를 위한 아키텍처 패턴 — 격리 경계, 다층 검증, OPA와 Cedar 같은 정책 엔진, 안전한 API 설계, 그리고 모델 호출에 적용된 제로 트러스트 — 을 걷습니다. 제11장은 관측 가능성, 로깅, 사건 대응 — 아키텍처 방어를 조직이 신뢰성 있게 운영할 수 있는 시스템으로 바꾸는 운영 층 — 을 걷습니다. 제12장은 접근 제어와 신원 — 인증, 인가, 멀티테넌트 격리, 속도 제한, 그리고 엔터프라이즈 거버넌스 오버레이 — 를 걷습니다. 세 장은 함께 파트 III가 방금 다룬 모델 컴포넌트를 담고 지지하고 제약하는 시스템 아키텍처를 서술합니다.

다음 → 제10장: 안전한 LLM 아키텍처 설계. 모델 주변의 격리 경계, 다층 검증, 정책 엔진, 그리고 모든 입력을 지시로 읽는 컴포넌트에 적용된 제로 트러스트 원칙.