Your LLM Stack Is a 2008 Database With Better Marketing — Lovina Dmello, NVIDIA

한 줄 핵심

LLM 보안의 대부분은 새로운 AI 공격이 아니라 과권한, 평탄한 네트워크, 노출된 비밀 같은 오래된 인프라 실수에서 터지므로, 모델이 아니라 인프라처럼 보안해야 한다.

시간별 요약

1. 0:01
   생산 ML 보안에서 터지는 문제의 핵심은 정교한 AI 공격이 아니라 예전부터 알던 인프라 실수다. Ray 클러스터의 기본 인증 미설정처럼, 배포 환경의 기본값을 바꾸지 않아 대규모 노출이 발생한다.
2. 3:01
   클래식한 2008년식 애플리케이션과 달리 ML 시스템은 동작이 확률적이고, 보호해야 할 대상이 모델 가중치와 API, 공유 GPU, 검색 코퍼스, 에이전트의 행동으로 넓어진다. 기존 보안 가정은 유지되지 않으므로 스택 전체를 다시 봐야 한다.
3. 6:02
   보안은 인프라 보안, 접근 제어, 런타임 보안, 운영·컴플라이언스로 나뉘는 다층 구조로 봐야 한다. 실제 방어 대상은 적대적 입력, 모델 추출, 데이터 오염, 공급망 문제, 인프라 침해와 내부자 위협이며, 실제 침해는 주로 가장 기본적인 인프라 구멍에서 발생한다.
4. 10:01
   대부분의 사고는 새로운 기능 부족이 아니라 잘못된 기본 설정에서 나온다. 과권한 계정, 분리되지 않은 네트워크, 노출된 비밀과 모델 파일이 반복적으로 발견되며, 이를 막으려면 역할별 권한, 네트워크 분리, secret manager, 암호화, 배포 전 자동 스캔이 필요하다.
5. 14:00
   현실적인 대응은 NIST AI risk management framework에 맞춘 성숙도 모델로 현재 수준을 측정하고, 생산 환경에 맞는 통제만 선택적으로 배치하는 것이다. 프롬프트 인젝션, RAG 오염, GPU 사이드 채널, 공급망 위험은 빠르게 변하지만, 결론은 동일하게 기존 보안 원칙을 ML 스택에 실제로 적용하는 데 있다.

실무 인사이트

• 생산 LLM 보안 점검은 모델 품질보다 먼저 인증, 권한, 네트워크 분리, 비밀 관리부터 확인하는 것이 비용 대비 효과가 크다.
• 고비용 런타임 방어는 전면 적용보다 민감한 워크로드에만 선택적으로 넣고, 기본 위생 조치는 모든 환경에 강제하는 방식이 현실적이다.
• 조직 차원에서는 ML 팀과 보안 팀의 책임 경계를 메우기 위해 성숙도 기준과 배포 전 체크리스트를 함께 운영해야 한다.