Key Takeaways
- SOC 2와 ISO 27001은 도구가 아니라 조직의 통제를 인증합니다. "Ollama는 SOC 2를 준수한다"거나 "vLLM은 ISO 27001 인증을 받았다"라고 절대 말하지 마십시오. 모든 내용을 감사인이 확인할 통제에 대한 준비 상태로 설명하십시오.
- SOC 2는 다섯 가지 Trust Services Criteria(보안성, 가용성, 기밀성, 처리 무결성, 프라이버시)로 평가되며, ISO 27001은 문서화된 ISMS(정보보안관리체계) 내의 Annex A 통제로 평가됩니다.
- 추론 엔드포인트에는 접근 제어와 구조화된 요청 로깅이 필요합니다. Ollama, vLLM, TGI 등 대부분의 셀프호스팅 엔진은 기본적으로 이를 제공하지 않으며 전면에 게이트웨이가 필요합니다.
- 모델 가중치와 프롬프트/응답 로그를 저장 시(디스크 암호화)와 전송 시(TLS) 모두 암호화하십시오. 이는 이미 다른 모든 프로덕션 데이터 저장소에 적용하고 있는 것과 동일한 통제입니다.
- 오픈웨이트 모델도 게시자 신원, 체크섬 검증, 라이선스 조건, 서빙 스택의 알려진 CVE를 포함한 문서화된 공급업체 위험 평가가 필요합니다.
- 컴플라이언스 자동화 플랫폼(Vanta, Drata, Secureframe)은 클라우드 인프라에서 증거를 자동으로 수집할 수 있지만, 셀프호스팅 추론 서버는 대개 커스텀 연동이나 수동 증거 업로드가 필요합니다.
- 본 문서는 법률 또는 컴플라이언스 자문이 아닙니다. 최종 범위 및 통제 결정은 귀사의 감사인이 내립니다.
본 문서는 법률 또는 컴플라이언스 자문입니까?
아닙니다 — 본 가이드는 법률 또는 컴플라이언스 자문이 아닙니다. SOC 2 또는 ISO 27001 감사인이 일반적으로 확인하는 통제 범주를 기술적 수준에서 설명하고, 이를 셀프호스팅 LLM 배포에 어떻게 매핑하는지 보여줍니다. 특정 통제가 실제 감사를 충족하는지는 감사인의 판단, 귀사의 위험 평가, 제출하는 정확한 범위 진술서에 따라 달라집니다. 감사를 계획하거나 컴플라이언스 관련 주장을 하기 전에 반드시 자격을 갖춘 감사인이나 컴플라이언스 담당 부서와 상담하십시오.
SOC 2 Trust Services Criteria가 요구하는 것은 무엇입니까?
SOC 2는 다섯 가지 Trust Services Criteria(TSC)로 조직을 평가하며, 셀프호스팅 LLM 시스템이 프로덕션 데이터를 다루는 순간 각 항목이 모두 적용됩니다. 감사인은 모델 자체를 테스트하지 않습니다. 검토 기간 동안 해당 통제가 존재했고 실제로 작동했음을 조직이 증명할 수 있는지를 테스트합니다.
| 기준 | 감사인 확인 사항 | 셀프호스팅 LLM 통제 |
|---|---|---|
| 보안성 | 접근 제어, 로깅, 취약점 관리 | 추론 게이트웨이의 RBAC + MFA |
| 가용성 | 가동 시간, 이중화, DR 계획 | 다중 노드 서빙 + 검증된 백업 |
| 기밀성 | 데이터 분류, 최소 접근 원칙 | 가중치·로그 저장 시 암호화 |
| 처리 무결성 | 정확성, 완전성, 적시성 | 버전 고정 모델 + 출력 로그 |
| 프라이버시 | 고지, 동의, 데이터 최소화 | 문서화된 프롬프트 로그 보존 정책 |
ISO 27001 Annex A가 요구하는 것은 무엇입니까?
ISO 27001은 조직의 정보보안관리체계(ISMS)를 인증하며, Annex A는 ISMS가 참조하는 통제 목록이지 단일 시스템에 직접 적용하는 체크리스트가 아닙니다. 셀프호스팅 LLM 배포는 다른 자산과 마찬가지로 ISMS 범위 내에 위치하며, 위험 평가, 적용선언서(Statement of Applicability) 등재, 관련 통제가 작동한다는 증거가 필요합니다.
| Annex A 영역 | LLM 스택 매핑 |
|---|---|
| A.5 조직적 통제 | 모델 게시자에 대한 공급업체 위험 검토 |
| A.5.19–22 공급자 관계 | 모델 출처 및 라이선스 확인 |
| A.8 기술적 통제 | 엔드포인트 강화, 암호화, 로깅 |
| A.8.16 모니터링 활동 | 추론 요청/응답 감사 로그 |
| A.8.24 암호화 | 전송 시 TLS, 저장 시 디스크 암호화 |
| A.5.29 연속성 | 모델 서빙을 위한 사고 대응 매뉴얼 |
추론 엔드포인트에는 어떤 접근 제어와 로깅이 필요합니까?
감사인은 누가 어떤 자격증명으로 언제 모델을 호출했는지 확인하고자 하지만, 일반적인 셀프호스팅 엔진들은 전면 게이트웨이 없이는 이를 충족하지 못합니다. Ollama는 기본적으로 `127.0.0.1:11434`에만 바인딩되며 사용자 계정이 없고, vLLM과 Hugging Face TGI는 내장 인증 없이 OpenAI 호환 HTTP API를 노출합니다.
추론 엔진 앞단에 API 게이트웨이(Kong, Envoy, 또는 클라우드 제공업체의 API 관리 계층)를 배치해 호출자별 API 키 또는 OAuth2를 추가하고, 모든 요청을 호출자 신원·타임스탬프·모델 버전·토큰 수와 함께 SIEM이 수집할 수 있는 시스템에 로깅하십시오.
- 인증: 게이트웨이에서의 API 키 또는 OAuth2. 모든 호출자가 공유하는 베어러 토큰은 절대 사용하지 않음
- 권한 부여: 역할 기반 접근 — 누가 어떤 모델을 호출할 수 있는지, 관리자/지표 엔드포인트를 누가 볼 수 있는지
- 감사 로그 필드: 호출자 신원, 타임스탬프, 모델 및 버전, 호출된 엔드포인트, 응답 상태
- 관리자 접근: 추론 호스트에 셸 또는 설정 접근 권한이 있는 모든 사람에게 MFA 필수
모델 가중치와 프롬프트 로그는 어떻게 암호화합니까?
모델 가중치, 프롬프트 로그, 응답 로그는 감사인이 다른 모든 프로덕션 데이터 저장소에 이미 기대하는 것과 동일한 저장 시·전송 시 암호화가 필요합니다. 가중치 자체는 대개 기밀이 아니지만, 추론 서버의 디스크에는 캐시된 프롬프트, 파인튜닝된 어댑터, 그리고 실제로 민감한 로그도 함께 저장되는 경우가 많습니다.
추론 호스트에서는 전체 디스크 암호화(Linux의 LUKS, Windows의 BitLocker, macOS의 FileVault)를 기본으로 사용하십시오. 모든 인바운드 API 호출에 대해 게이트웨이에서 TLS 종료를 추가하고, VPC 내부라 하더라도 원시 추론 포트를 평문 HTTP로 노출하지 마십시오.
- 저장 시: 호스트 전체 디스크 암호화, 프롬프트 로그 DB용 암호화 볼륨
- 전송 시: 호출자→게이트웨이→추론 엔진 간 TLS, 내부 평문 구간 없음
- 키 관리: 키는 KMS/vault에 보관하고 문서화된 일정에 따라 교체
모델 업데이트를 위한 변경 관리는 어떻게 이루어져야 합니까?
모델 버전 교체, 양자화 변경, 시스템 프롬프트 수정은 모두 프로덕션 변경이며 코드 배포와 동일한 승인 흔적이 필요합니다. 감사인은 변경이 사후에 존재하는 변경 로그가 아니라 배포 전에 검토 및 승인되었다는 증거를 구체적으로 확인합니다.
- 가변적인 "latest" 포인터가 아닌 정확한 모델 아티팩트(체크섬)를 고정
- 프로덕션 모델 또는 시스템 프롬프트 변경 전 문서화된 승인 단계 요구
- 모든 변경을 승인자, 시점, 사유와 함께 기록
- 이전 버전 고정 아티팩트로의 롤백 경로 유지
오픈웨이트 모델의 공급업체 위험은 어떻게 평가합니까?
"오픈웨이트"가 "공급업체 없음"을 의미하지는 않습니다 — 모델 게시자는 SaaS 공급업체와 마찬가지로 공급망 참여자이며, 감사인은 이에 대한 문서화된 위험 평가를 기대합니다. 이는 가장 흔히 누락되는 통제 중 하나로, 팀들은 다운로드한 GGUF나 safetensors 파일을 조직 외부에서 온 것임에도 제3자가 아닌 내부 자산으로 취급하는 경향이 있습니다.
- 게시자 신원: Meta, Mistral AI, Alibaba/Qwen, Microsoft 등 알려진 조직인지, 익명 출처인지
- 체크섬 검증: 배포 전 게시자가 공개한 해시와 SHA-256 일치 확인
- 라이선스 검토: 상업적 사용 조건, 재배포 제한
- 서빙 스택 CVE: 모델 파일 자체뿐 아니라 llama.cpp, vLLM, TGI의 알려진 취약점 추적
모델 서빙 시스템의 사고 대응은 어떤 모습입니까?
모델 서빙 시스템에는 일반적인 웹 애플리케이션 매뉴얼이 다루지 않는 사고 유형이 있습니다 — 모델 유출, 모델 출력 자체를 통해 데이터가 유출되는 프롬프트 인젝션, 추론 엔드포인트 침해 — 각각에 명명된 대응 경로가 필요합니다.
- 트리거 예시: 권한 없는 가중치 파일 변경, 단일 자격증명 기준 요청 급증, 로그에서 발견된 프롬프트 인젝션 패턴
- 격리 단계: 시스템 전체 중단 없이 추론 엔드포인트를 격리하거나 오프라인으로 전환할 수 있는 능력
- 증거 보존: 사고 기간의 원시 로그를 보존하고 조사 중 로테이션하지 않음
- 테스트 주기: 최소 연 1회 탁상 훈련, 날짜와 참가자 기록
프롬프트 로그 보존 정책에는 무엇을 포함해야 합니까?
프롬프트 로그는 사용자가 다른 업무 시스템에 입력할 법한 것과 동일한 민감한 내용을 담는 경우가 많아, LLM 스택이 생성하는 데이터 중 가장 위험도가 높습니다. 로그 보존 기간, 접근 권한자, 삭제 방법을 명시한 서면 보존 정책은 감사인이 구체적으로 요구할 통제이며, 일반적인 데이터 보존 정책에서 유추할 수 있는 사항이 아닙니다.
- 보존 기간: "무기한"이 아닌 구체적인 일수/개월 수를 정의
- 접근 제어: 프롬프트 로그 저장소는 일반 로그 접근과 별도로 제한된 접근 목록을 보유
- 최소화: 기본적으로 메타데이터만 로깅하고, 전체 내용 로깅은 정당한 사유가 있고 기간이 제한된 경우에만
- 삭제 절차: 문서화되고 가능하면 자동화
추론 서버는 네트워크에서 어떻게 분리해야 합니까?
추론 서버는 일반 애플리케이션 서버와 동일한 평평한 서브넷이 아니라, 인증된 게이트웨이를 통해서만 도달 가능한 자체 네트워크 구역에 위치해야 합니다. 이는 네트워크상 다른 서비스가 침해되었을 때의 영향 범위를 제한하고, 감사인에게 검토할 수 있는 명확한 네트워크 다이어그램을 제공합니다.
어떤 셀프호스팅 도구가 감사 관련 통제를 제공합니까?
일반적인 추론 엔진 중 완성된 감사 추적을 제공하는 것은 없습니다. 차이는 직접 구축해야 하는 부분과 플랫폼이 이미 제공하는 부분의 비율에 있습니다. 이는 준비도 비교이지, 이들 도구 중 어느 것에 대한 컴플라이언스 주장이 아닙니다.
| 도구 | 내장 인증/로깅 | 필요한 계측 |
|---|---|---|
| Ollama | 없음(localhost 바인딩) | 리버스 프록시 + 인증 + SIEM 연동 |
| vLLM | Prometheus 지표만 | API 게이트웨이(OAuth2/키) + 감사 로그 |
| Hugging Face TGI | Prometheus 지표만 | vLLM과 동일: 게이트웨이 + 감사 로그 |
| 엔터프라이즈 플랫폼 | RBAC + 감사 로깅 기본 제공 | ISMS 문서화는 여전히 필요 |
컴플라이언스 자동화 플랫폼이 셀프호스팅 LLM에 도움이 됩니까?
컴플라이언스 자동화 플랫폼 — 가장 많이 사용되는 세 곳은 Vanta, Drata, Secureframe입니다 — 는 클라우드 인프라, HR 시스템, ID 제공업체로부터 자동으로 증거를 수집하지만, 셀프호스팅 온프레미스 추론 서버는 대개 기본 연동 목록에 포함되지 않습니다.
회사 전체에 걸쳐 더 넓은 SOC 2 또는 ISO 27001 프로그램을 운영 중이고 셀프호스팅 LLM 계층을 제외한 모든 것에 대해 지속적인 모니터링을 원한다면 컴플라이언스 자동화 플랫폼을 사용하십시오.
| 플랫폼 | 중점 |
|---|---|
| Vanta | 광범위한 프레임워크 지원, 스타트업에서 널리 사용 |
| Drata | 지속적인 통제 모니터링, 깊은 연동 |
| Secureframe | SOC 2 + ISO 27001 통합 워크플로 |
이러한 플랫폼은 귀사의 더 넓은 통제 환경에 대한 증거 수집을 자동화할 뿐, 셀프호스팅 LLM 인프라 자체를 인증하지는 않습니다. PromptQuorum은 현재 이들 중 어느 곳과도 제휴 관계가 없습니다(공개된 제품 링크만 사용).
감사 준비에서 가장 흔한 실수는 무엇입니까?
셀프호스팅 LLM 감사 지적사항의 대부분은 근본적으로 통제가 없어서가 아니라, 추론 서버를 일반 IT 통제 환경 밖의 것으로 취급하는 데서 비롯됩니다.
- 실수: 오픈소스 도구가 "감사 가능"(코드 공개)하다는 것을 이미 감사받았다는 의미로 오해함. 해결책: 게시자와 서빙 스택에 대한 자체 위험 평가를 문서화하십시오. 가시성은 검토와 다릅니다.
- 실수: "내부 전용이라서"라는 이유로 게이트웨이 없이 추론 API를 접근 가능하게 방치함. 해결책: 네트워크 접근 가능성과 접근 제어는 별개의 문제입니다. 어쨌든 인증을 추가하십시오.
- 실수: 가동 시간 모니터링에 사용하는 것과 동일한 접근 로그에 프롬프트 전체 텍스트를 기록함. 해결책: 두 저장소를 분리하고, 내용이 포함된 로그에는 더 엄격한 접근 제어와 더 짧은 보존 기간을 적용하십시오.
- 실수: 모델 버전 업그레이드를 승인 흔적 없는 일상적 배포로 취급함. 해결책: 코드 배포에 사용하는 것과 동일한 변경 관리 승인을 적용하십시오.
- 실수: 모델 서빙 고유의 실패 모드(가중치 조작, 프롬프트 인젝션)에 특화된 사고 대응 계획이 없음. 해결책: 기존 사고 대응 계획에 이러한 트리거를 추가하고 최소 한 번 테스트하십시오.
셀프호스팅 LLM의 감사 준비 체크리스트는 무엇입니까?
감사인의 현장 작업이 시작되기 전에 이 체크리스트를 점검하십시오 — 각 항목은 위에서 다룬 통제 범주에 대응합니다.
- 1셀프호스팅 LLM 시스템을 ISMS/SOC 2 범위 진술서에 추가
Why it matters: 모든 기술적 통제가 갖춰져 있어도 범위 내 미문서화 시스템은 지적사항이 됩니다. - 2관련 Trust Services Criteria 또는 Annex A 통제를 실제 스택에 매핑
Why it matters: 감사인은 귀사가 제공한 매핑을 기준으로 테스트하므로, 불완전한 매핑은 검증되지 않은 공백을 의미합니다. - 3모든 추론 엔드포인트 앞에 인증된 게이트웨이 배치
Why it matters: 가장 흔한 단일 지적사항인 인증 없는 모델 API를 제거합니다. - 4호출자 신원과 타임스탬프가 포함된 구조화된 요청 로깅 활성화
Why it matters: 보안성 기준에 대해 감사인이 요구하는 주된 증거입니다. - 5호스트 디스크와 프롬프트 로그 저장소를 암호화하고 게이트웨이에서 TLS 강제
Why it matters: 기밀성 기준과 Annex A.8.24 암호화 통제를 충족합니다. - 6모델 버전 업데이트를 위한 변경 관리 절차를 작성하고 준수
Why it matters: 처리 무결성을 증명하고 문서화된 롤백 경로를 제공합니다. - 7프로덕션 중인 각 오픈웨이트 모델에 대한 공급업체 위험 평가 문서화
Why it matters: 가장 흔히 누락되는 통제 — 모델 자체의 공급망 위험 — 을 해소합니다. - 8프롬프트/응답 로그의 보존 및 삭제 정책 공개
Why it matters: 프롬프트에 개인정보가 포함된 경우 프라이버시 기준에 직접적으로 요구됩니다. - 9추론 서버를 자체 네트워크 구역으로 분리
Why it matters: 영향 범위를 제한하고 감사인에게 명확한 네트워크 다이어그램을 제공합니다. - 10모델 특화 트리거가 포함된 사고 대응 매뉴얼을 작성하고 한 번 테스트
Why it matters: 감사인은 계획이 존재할 뿐 아니라 실제로 훈련되었는지를 확인합니다.
자주 묻는 질문
본 문서는 법률 또는 컴플라이언스 자문입니까?
아닙니다. 본 가이드는 SOC 2 또는 ISO 27001 감사인이 일반적으로 확인하는 통제 범주를 기술적 수준에서 설명합니다. 자격을 갖춘 감사인이나 컴플라이언스 담당 부서를 대체하지 않으므로, 감사를 계획하거나 컴플라이언스 관련 주장을 하기 전에 반드시 전문가와 상담하십시오.
Ollama, vLLM, Hugging Face TGI를 사용하면 저희 AI 인프라가 SOC 2를 준수하게 됩니까?
어떤 단일 도구도 조직을 준수 상태로 만들지 않습니다. 컴플라이언스는 귀사의 전체 통제 집합에 대한 감사 결과입니다. Ollama, vLLM, TGI는 인증, 로깅, 암호화를 추가하면 기술적 요구사항을 뒷받침할 수 있지만, 소프트웨어 제품으로서 어느 것도 "SOC 2를 준수"하거나 "ISO 27001 인증을 받은" 것이 아닙니다.
AI 인프라에서 SOC 2 Type I과 Type II의 차이는 무엇입니까?
Type I은 특정 시점에 통제가 적절히 설계되었는지를 평가합니다. Type II는 그 통제가 일반적으로 6~12개월인 검토 기간 동안 효과적으로 운영되었는지를 평가합니다. 추론 엔드포인트의 경우, Type II는 접근 로그와 변경 관리 증거가 감사 당일만이 아니라 그 전체 기간 동안 지속적으로 존재해야 함을 의미합니다.
소프트웨어 공급업체가 없는 오픈웨이트 모델도 공급업체 위험 평가가 필요합니까?
네. 모델 게시자(Meta, Mistral AI, Alibaba/Qwen 등)는 SaaS 공급업체와 마찬가지로 공급망 참여자입니다. 문서화된 위험 평가에는 게시자 신원, 다운로드한 가중치의 체크섬 검증, 라이선스 조건, 모델을 로드하는 서빙 스택의 알려진 CVE가 포함되어야 합니다.
LLM을 셀프호스팅하면 클라우드 LLM API 대비 감사 범위가 축소됩니까?
단순히 축소되는 것이 아니라 범위가 달라집니다. 셀프호스팅은 클라우드 API가 만드는 제3자 데이터 처리자 관계를 제거하지만, 동시에 클라우드 공급업체가 이전에 담당했던 모든 통제 — 접근 제어, 암호화, 패치, 추론 서버 자체의 로깅 — 를 귀사가 전적으로 책임지게 됩니다.
추론 엔드포인트에서 감사인은 어떤 로깅을 기대합니까?
최소한 호출자 신원(API 키 또는 인증된 사용자), 타임스탬프, 호출된 모델과 버전, 엔드포인트, 응답 상태를 쓰기 권한이 제한된 로그 저장소로 내보내야 합니다. 프롬프트/응답의 전체 내용은 일반적으로 자체 보존 정책을 가진 별도의, 더 엄격하게 접근 제어되는 저장소에 보관합니다.
감사 증거로 프롬프트 로그를 얼마나 보존해야 합니까?
보편적인 숫자는 없습니다 — 귀사의 위험 평가와 감사인의 기대, 그리고 적용 가능한 프라이버시 법률의 데이터 최소화 원칙 사이의 균형에 따라 달라집니다. "무기한"이 아닌 구체적인 보존 기간을 서면으로 정의하고, 전체 프롬프트 내용이 포함된 로그에는 더 엄격한 접근 제어를 적용하며, 감사인에게 해당 기간을 설명할 준비를 하십시오.
Vanta, Drata, Secureframe 같은 플랫폼이 셀프호스팅 LLM 서버를 모니터링할 수 있습니까?
클라우드 인프라, ID 제공업체, 티켓팅 시스템에 대한 증거 수집은 잘 자동화하지만, 셀프호스팅 온프레미스 추론 서버는 대개 기본 연동 목록에 포함되지 않습니다. 대부분의 팀은 해당 시스템에 대해 커스텀 API 연동을 구축하거나 증거를 수동으로 업로드하며, 나머지 통제 환경은 플랫폼이 자동화하도록 합니다.
셀프호스팅 AI 인프라에서 가장 흔한 단일 감사 지적사항은 무엇입니까?
"우리 네트워크 내에서만 접근 가능하다"는 이유로 정당화된, 인증 없이 접근 가능한 추론 API입니다. 네트워크 접근 가능성과 접근 제어는 서로 다른 개념이며, 감사인은 네트워크상 위치와 무관하게 엔드포인트에서의 인증을 기대합니다.
감사 준비를 더 쉽게 하려면 vLLM/TGI와 엔터프라이즈 추론 플랫폼 중 무엇을 선택해야 합니까?
vLLM과 Hugging Face TGI는 완전한 제어권을 제공하지만 인증, 로깅, 암호화 계층을 직접 구축해야 합니다. 엔터프라이즈 추론 플랫폼은 RBAC와 감사 로깅을 기본 제공하는 경우가 많아 커스텀 계측 작업을 줄일 수 있지만, 어느 쪽을 선택하든 주변 ISMS 문서화와 공급업체 위험 평가는 여전히 필요합니다. 어느 쪽이 컴플라이언스의 지름길이라는 판단이 아니라, 계측 계층을 직접 구축할지 구매할지를 기준으로 선택하십시오.
추가 자료는 어디서 찾을 수 있습니까?
- AICPA SOC 2 Trust Services Criteria(aicpa-cima.com) — SOC 2 감사가 평가되는 공식 Trust Services Criteria 프레임워크
- ISO/IEC 27001:2022(iso.org) — 공식 표준 본문 및 Annex A 통제 참조
- OWASP Top 10 for LLM Applications(owasp.org/www-project-top-10-for-large-language-model-applications) — 공급망 및 프롬프트 인젝션 위험을 포함한 LLM 배포 특유의 보안 위험