모델 서빙 보안

학습이 끝난 모델은 결국 추론 엔드포인트(inference endpoint) 형태로 외부 또는 내부 사용자에게 노출됩니다. 이 시점부터 모델은 “ML 아티팩트"가 아니라 “API 서비스"이며, 전통적인 API 보안 원칙(인증/인가, rate limiting, 입력 검증)이 그대로 적용됩니다. 동시에 모델 고유의 자산(가중치, 레지스트리)과 모델 고유의 위협(모델 추출, 모델 DoS)에 대한 추가 통제가 필요합니다.

    flowchart LR
    subgraph EDGE["진입 경계 통제"]
        G1["인증/인가\n(API 키, mTLS)"]
        G2["Rate Limiting\n(사용자/비용 단위)"]
        G3["API 게이트웨이\n(스키마 검증, 로깅)"]
    end

    subgraph CORE["서빙 코어 자산"]
        S1["모델 레지스트리\n(권한 분리, 불변성)"]
        S2["가중치 파일\n(암호화 + 서명 검증)"]
        S3["추론 엔드포인트\n(입출력 검증)"]
    end

    subgraph THREAT["대응 위협"]
        R1["모델 추출\n(무차별 질의)"]
        R2["미검증 모델\n프로덕션 승격"]
        R3["백도어 가중치\n(저장소/전송 변조)"]
        R4["모델 DoS\n(비용 폭탄, LLM04)"]
    end

    G1 --> G3
    G2 --> G3
    G3 --> S3
    S1 --> S2 --> S3

    G2 -.방어.- R1
    S1 -.방어.- R2
    S2 -.방어.- R3
    G2 -.방어.- R4
    G3 -.쿼터/타임아웃.- R4

    classDef edge fill:#e7f1ff,stroke:#3b82f6,color:#1e3a8a;
    classDef core fill:#e7f1ff,stroke:#3b82f6,color:#1e3a8a;
    classDef threat fill:#fff3cd,stroke:#d39e00,color:#664d03;
    class G1,G2,G3,S1,S2,S3 edge;
    class R1,R2,R3,R4 threat;

모델 서빙 엔드포인트 보호

인증 및 인가

API 키/토큰 기반 인증: 모든 추론 요청은 인증된 클라이언트로부터만 허용되어야 합니다. 익명 접근이 가능한 추론 엔드포인트는 모델 추출, 무차별 질의를 통한 정보 유출의 가장 흔한 진입점입니다.
세분화된 인가(Authorization): 동일한 모델이라도 사용자 그룹/플랜에 따라 호출 가능한 기능(예: 특정 파라미터, batch 추론, fine-tuned 버전 접근)을 다르게 제한해야 합니다.
서비스 간 인증(mTLS): 내부 마이크로서비스에서 모델 서빙 엔드포인트를 호출하는 경우에도 상호 TLS 인증을 적용해, 내부망 침투 시 모델 엔드포인트가 손쉬운 다음 단계 공격 표면이 되지 않도록 합니다.

Rate Limiting

사용자/키 단위 요청 제한: 짧은 시간 내 과도한 추론 요청은 모델 추출 공격(체계적인 질의-응답 수집을 통한 모델 복제)의 전형적인 패턴입니다. 모델 탈취 페이지에서 다루는 추출 공격은 대량의 질의를 필요로 하므로, rate limiting은 가장 비용 효율적인 1차 방어선입니다.
비용 기반 제한: 입력 토큰 수, 출력 길이, 모델 크기(대형 모델 호출 vs 경량 모델 호출)에 따라 가중치를 둔 quota를 적용해, 단순 요청 횟수 제한을 우회하는 대용량 단일 요청도 통제합니다.
점진적 차단(Progressive throttling): 의심스러운 패턴이 감지되면 즉시 차단하기보다, 응답 지연을 늘리거나 정확도를 낮춘 응답을 제공하는 등 단계적으로 대응해 공격자의 비용을 높이는 전략도 활용됩니다.

API 게이트웨이를 통한 통합 통제

모델 서빙 인스턴스 앞단에 API 게이트웨이를 두면, 인증, rate limiting, 로깅, WAF 규칙, 요청/응답 크기 제한 등을 모델별 코드 수정 없이 일관되게 적용할 수 있습니다.
게이트웨이 계층에서 요청 스키마 검증(허용된 파라미터, 타입, 범위)을 수행해, 모델 서빙 코드에 도달하기 전에 명백히 잘못된 형식의 요청을 걸러냅니다.
게이트웨이 로그는 추론 트래픽에 대한 가시성을 제공하여, 이상 탐지(anomaly detection) 시스템의 입력 데이터로 활용됩니다.

이러한 게이트웨이/네트워크 경계 통제의 기본 원리는 기반 지식 → 네트워크 보안 기초에서 다룬 제로트러스트, 방화벽/IDS·IPS 개념과 동일하며, 모델 서빙 환경은 이 원칙이 적용되어야 할 또 하나의 자산일 뿐입니다.

모델 레지스트리(Model Registry) 권한 분리

모델 레지스트리는 학습된 모델 가중치, 버전 메타데이터, 스테이지(stage: 개발/스테이징/프로덕션) 정보를 관리하는 중앙 저장소입니다. 소스코드 저장소와 유사하게 취급해야 합니다.

읽기/쓰기/승격(promote) 권한 분리:
- 데이터 과학자: 자신의 실험에서 새 모델 버전을 등록(register)할 수 있음
- ML 엔지니어/배포 승인자: 모델을 “스테이징 → 프로덕션"으로 승격할 수 있음
- 서빙 인프라(서비스 계정): 프로덕션 스테이지의 모델을 “읽기"만 가능
이 세 권한을 동일 계정에 부여하면, 계정 하나가 탈취될 경우 검증되지 않은 모델이 즉시 프로덕션에 배포될 수 있습니다.
버전 불변성(Immutability): 한 번 등록된 모델 버전(특정 버전 번호에 매핑된 아티팩트)은 덮어쓰기가 불가능해야 합니다. 같은 버전 번호의 내용이 바뀔 수 있다면, “어떤 모델이 실제로 배포되어 있는지"를 신뢰할 수 없게 됩니다.
승인 이력 기록: 누가, 언제, 어떤 평가 결과를 근거로 모델을 승격했는지에 대한 기록을 레지스트리 메타데이터에 남깁니다.

모델 파일 접근 제어 및 무결성 검증(서명)

모델 가중치 파일은 단순한 바이너리가 아니라, 학습에 투입된 비용·데이터·지적 재산이 응축된 핵심 자산입니다.

저장소 접근 제어: 가중치 파일이 저장된 객체 스토리지(S3, GCS 등)에 대한 IAM 정책을 최소화하고, 서빙 인프라의 서비스 계정에는 읽기 전용 권한만 부여합니다.
암호화: 저장 시 암호화(encryption at rest)는 물론, 가중치를 다운로드해 서빙 노드로 전송하는 과정도 암호화된 채널을 사용합니다.
디지털 서명을 통한 무결성 검증: 모델 아티팩트에 디지털 서명을 적용하고, 서빙 인프라가 모델을 로드하기 전에 서명을 검증하도록 합니다. 이를 통해 다음을 방지할 수 있습니다.
- 저장소 침해를 통해 가중치 파일이 악성 버전(예: 백도어가 삽입된 가중치)으로 교체되는 공격
- 전송 과정에서의 변조
- 검증되지 않은 출처의 모델 파일이 실수로 서빙 환경에 로드되는 사고
서명/검증의 암호학적 원리는 기반 지식 → 암호학 기초의 전자서명 개념을 그대로 활용합니다.
역직렬화 방식 점검: 모델 파일 형식에 따라 로드 과정에서 임의 코드 실행이 가능한 경우가 있습니다(자세한 내용은 공급망 보안에서 다룹니다). 서빙 환경은 신뢰할 수 있는 형식과 검증된 로더만 사용해야 합니다.

추론 시 입출력 검증

입력 검증: 추론 요청의 입력 크기, 형식, 타입을 서버 측에서 강제합니다. 예상보다 훨씬 큰 입력(매우 긴 시퀀스, 고해상도 이미지 등)은 거부하거나 별도 큐로 분리합니다.
출력 검증/필터링: 모델 출력이 그대로 다음 시스템(다른 서비스, 사용자 UI)에 전달되기 전에, 민감정보 유출이나 비정상 패턴(예: 학습 데이터의 verbatim 재현)이 없는지 점검하는 계층을 둘 수 있습니다.
신뢰 경계 명시: 모델 서빙 레이어는 “입력은 신뢰할 수 없고, 출력도 신뢰할 수 없다"는 가정 위에서 설계되어야 합니다. 이는 기반 지식 → 웹 보안 기초에서 다루는 “모든 입력은 검증되어야 한다"는 원칙의 AI 버전입니다.

DoS/리소스 소모 공격 방어 (모델 DoS — OWASP LLM04)

대형 모델, 특히 LLM은 입력 크기나 생성 토큰 수에 따라 연산 비용이 크게 달라지기 때문에, 적은 수의 요청으로도 막대한 컴퓨팅 자원을 소모시키는 공격이 가능합니다. OWASP LLM Top 10의 LLM04(Model Denial of Service)가 다루는 영역입니다.

대표적인 공격 패턴:

과도하게 긴 입력/컨텍스트: 컨텍스트 윈도우를 가득 채우는 입력을 반복적으로 보내 GPU 메모리와 연산 시간을 소모시킵니다.
재귀적/반복적 생성 유도: 모델이 끝없이 긴 출력을 생성하도록 유도하는 프롬프트(예: 무한 루프성 지시)는 단일 요청만으로도 서빙 인스턴스를 장시간 점유합니다.
복잡한 질의의 동시 다발 전송: 개별 요청은 정상 범위 내에 있지만, 동시에 대량으로 전송되어 큐가 적체되고 정상 사용자의 응답 지연이 발생합니다.

방어 방안:

리소스 쿼터 설정: 사용자/세션 단위로 최대 입력 토큰 수, 최대 출력 토큰 수, 동시 요청 수에 대한 하드 리밋을 둡니다.
타임아웃 및 조기 종료: 생성 작업이 임계값을 초과하면 강제로 종료하는 타임아웃 정책을 적용합니다.
큐 기반 아키텍처와 백프레셔(backpressure): 서빙 인프라가 과부하 상태일 때 새 요청을 즉시 거부하거나 대기열에 적재해, 전체 시스템의 가용성을 보호합니다.
자원 사용량 모니터링과 자동 스케일링의 한계 설정: 자동 스케일링이 무제한으로 동작하면 공격이 비용 폭증(financial DoS)으로 직결될 수 있으므로, 스케일링 상한선을 명시적으로 설정합니다.

모델 DoS는 가용성 문제이자 비용 문제입니다. 클라우드 기반 추론 인프라에서는 공격으로 인한 과도한 연산 사용이 곧바로 비용 폭증으로 이어지므로, 보안팀과 인프라/재무 담당자가 함께 모니터링 대시보드와 알림 임계값을 설계해야 합니다.

정리

모델 서빙 계층은 “ML 모델"과 “API 서비스"의 교집합입니다. 인증/인가, rate limiting, API 게이트웨이, 입출력 검증 같은 전통적인 API 보안 통제는 그대로 필요하며, 여기에 모델 레지스트리 권한 분리, 가중치 파일의 무결성 서명, 모델 DoS 방어라는 AI 고유의 통제가 추가됩니다. 다음 페이지에서는 이러한 모델과 데이터가 어디에서 왔는지 — 즉 공급망 차원의 리스크를 다룹니다.

MLOps 파이프라인 보안 공급망 보안 (Supply Chain Risk)