당신의 LLM 스택은 마케팅만 좋은 2008년 데이터베이스 — Lovina Dmello, NVIDIA

메타데이터

• 제목: Your LLM Stack Is a 2008 Database With Better Marketing
• 발표자: Lovina D'Mello (NVIDIA, Senior Software Developer, Deep Learning Infrastructure Team)
• 채널: aiDotEngineer
• URL: https://www.youtube.com/watch?v=XjI-AR4pt7Y
• 날짜: 2026-07-21
• 태그: #AI #LLM #보안 #ML인프라 #NVIDIA #프로덕션보안

---

핵심 주장

프로덕션 ML 시스템에서 실제로 문제를 일으키는 것은 화려한 적대적(adversarial) AI 공격이 아니라, 이미 수년 전 일반 소프트웨어 업계가 해결했다고 여겼던 지루하고 기초적인 인프라 실수다. 2008년식 결정론적(deterministic) 애플리케이션에서 통했던 보안 가정을, 확률적이고 멀티테넌트이며 API로 노출된 2026년의 ML 스택에 그대로 적용하면서 근본적인 미스매치가 발생했다. 즉 "우리는 스택의 모든 것을 바꿨지만 보안 가정은 바꾸지 않았다." 발표자는 이를 세 가지 핵심 아이디어로 압축한다.

1. 미스컨피규레이션이 문제지, 기능 부재가 문제가 아니다 — 실패의 1순위 원인은 "기능이 없어서"가 아니라 "설정을 잘못했거나 안 했기 때문"이다.
2. 논문에서 읽은 방어 기법은 실제 프로덕션에서 살아남지 못한다 — 모든 보안 통제(control)에는 지연시간·처리량 비용이 따르고, 이를 무시한 방어는 배포되지 못한다.
3. 모델이 아니라 인프라를 지키듯이 ML을 지켜야 한다 — 문제의 본질이 인프라이므로 해법도 인프라 관점에서 접근해야 한다.

결론적으로 "당신의 LLM 스택은 결국 마케팅만 좋아진 2008년 데이터베이스"이며, 데이터베이스를 지키던 방식(접근 제어 잠그기, 네트워크 세그먼트화, 저장 데이터 암호화)을 그대로 적용하면 된다는 것이 발표의 핵심 메시지다.

주요 논거 및 근거

1) 2023년 Ray 클러스터 사건 — 서두를 여는 사례

• 2023년 보안 연구자들이 분산 ML 프레임워크로 가장 널리 쓰이는 Ray 클러스터를 조사한 결과, 수천 개의 클러스터가 인터넷에 그대로 노출되어 있었다.
• 대시보드와 Job API가 열려 있었던 이유는 단순하다: 인증이 기본값으로 꺼져 있었고, 누군가 프로덕션에 배포하면서 그것을 켜는 것을 깜빡했다.
• 당시 노출된 자산 가치는 10억 달러(billion dollars) 규모였다.
• 이 사건은 제로데이도, 신경망을 겨냥한 새로운 정교한 공격도 아니었다. 그냥 누군가 기본 설정을 프로덕션에 배포하면서 켜는 것을 잊은 것뿐이었다.
• 실제 뉴스에 나는 침해 사고들을 살펴보면 화려한 적대적 공격은 거의 없다. 대신: API 키 노출, 과도한 권한을 가진 계정, 퍼블릭 버킷에 방치된 모델 가중치 — 이런 식으로 "누군가 뭔가를 깜빡했다"는 패턴이 반복된다.

2) 왜 이렇게 됐는가 — 2008년 애플리케이션과 깨진 세 가지 가정

과거 2008년식 클래식 애플리케이션은 다음 세 가지 특성을 가졌고, 보안팀은 이를 기준으로 명확한 정신모델(mental model)과 도구를 구축했다:

• 결정론적(deterministic): 코드가 무엇을 할지 정확히 추론 가능
• 고정된 파라미터
• 단일 테넌트(single tenant)

그런데 머신러닝 모델을 프로덕션에 넣으면서 이 세 가정이 조용히 깨졌다:

• 행동이 **확률적(probabilistic)**으로 변함 — "정답"이 예/아니오의 한 분기가 아니라 분포(distribution)가 됨
• 지켜야 할 대상인 **가중치(weights) 자체가 복제 가능(copyable)**해지고, 서빙하는 API를 통해 그대로 유출될 수 있음
• 비용 절감을 위해 여러 워크로드를 공유 멀티테넌트 GPU에 몰아넣으면서 새로운 보안 리스크 등장
• LLM 스택 자체가 더 넓게 열림: **프롬프트가 제어 흐름(control flow)**이 되고, 답변이 검색 코퍼스(retrieval corpus)에서 나오며, 에이전트가 대신 행동을 취함

3) 방어 심층 4개 계층(Defense in Depth) 프레임워크

아래에서 위로 쌓이는 구조이며, **아래 계층의 실패는 위 계층으로 그대로 전파(cascade)**된다:

1. 인프라 보안 (기반) — 컨테이너, 네트워크, GPU 가상화, 암호화
2. 접근 제어 — 누가 무엇을 할 수 있는지
3. 런타임 보안 — 시스템이 살아있는 동안 트래픽을 감시
4. 일상 실무 계층 (전체를 감싸는 층) — 팀 운영 방식, 컴플라이언스, 인시던트 대응, 조직 문화

핵심 통찰: "완벽한 접근 제어 정책이 있어도 그 아래 클러스터가 활짝 열려 있다면 그건 그냥 장식일 뿐이다."

4) 6개 위협 카테고리와 방어 매핑

• 모델 관련: 적대적 입력(adversarial input), 모델 추출(model extraction) → 방어: 입력 검증, 적대적 탐지, 레이트 리미팅, API 인증, 쿼리 분석
• 데이터·무결성 관련: 포이즈닝·공급망(poisoning & supply chain), 프라이버시 침해 → 방어: CI/CD 보안, 모델 서명 및 출처(provenance) 검증, 접근 제어, 암호화
• 클래식 인프라: 인프라 침해(infrastructure compromise), 내부자 위협(insiders) → 방어: 컨테이너 격리, 네트워크 세그멘테이션, RBAC, 행동 분석

발표자가 강조하는 지점: 이 중 인프라 침해와 내부자 위협 항목이 실제 침해 사고가 가장 많이 발생하는 곳이며, 동시에 실수로 잘못 다루기 가장 쉬운(cheapest to get wrong) 영역이다.

5) 핵심 아이디어 1 뒷받침 근거 — 50개 프로덕션 환경 감사 연구

• 연구자들이 실제로 운영 중인 ML 프로덕션 세팅 50개를 감사했다.
• 그중 78%에서 최소 하나의 치명적(critical) 보안 실수가 발견됐다.
• "평범한 화요일"과 "회사 이름이 헤드라인에 뜨는 날"의 차이는 바로 이런 치명적 미스컨피규레이션 하나다.
• 연구에서 반복적으로 발견된 3가지 문제:
  1. 접근 제어가 활짝 열려 있음 — 거의 모든 계정이 거의 모든 것을 할 수 있는 상태
  2. 시스템 내부 분리(segmentation) 부재 — 공격자가 시스템 한 부분에 침입하면 전체 시스템에서 무엇이든 할 수 있음
  3. 비밀번호와 학습된 모델이 누구나 접근 가능한 저장소에 그대로 방치됨
• 왜 이런 일이 반복되는가: 프로덕션 보호 장치는 보안 전문가가 보안 전문가를 위해 만들고, 그것이 그대로 ML 팀에 넘겨진다. 하지만 ML 팀의 책임은 모델 정확도를 높이는 것이지 인프라 설정이 아니다. 보호 기능은 플랫폼에 이미 존재하지만, 설정 과정에서 꺼지는(switched off) 경우가 많다.

6) 핵심 아이디어 2 뒷받침 근거 — 보안 통제의 비용 3단 티어

모든 보안 통제는 ML 시스템에서 지연시간과 처리량이라는 비용을 지불하게 만든다 (SLA를 구성하는 두 요소).

• 그린 티어 (기본기): 로그인, 입력 검사 등 → 오버헤드 8% 미만. 언제나 적용해야 하며 이견의 여지가 없음.
• 오렌지 티어 (무거운 격리): 워크로드 간 격벽(wall) → 오버헤드 10~20%. 민감하거나 신뢰할 수 없는 워크로드에 선택적으로 적용.
• 퍼플 티어 (실시간 악성 입력 탐지): 연구자들이 가장 선호하는 방식이지만 오버헤드가 **15~30%**로 가장 비쌈. 모든 요청을 느리게 만들 수 없어 현실적으로 채택 불가능한 경우가 많음(non-starter).
• 관건은 "이걸 해야 하나?"가 아니라 **"시스템 전체를 느리게 만들지 않으면서 어떻게 구현할 것인가?"**다. 같은 보안 체크라도 허술하게 구현하면 응답시간이 2배로 늘어날 수 있지만, 잘 구현하면 균형 잡힌 비용으로 운용 가능하다. 저렴한 통제는 전체에 상시 적용하고, 비싼 통제는 고위험 시스템에 아껴 써야 한다.

7) 생태계가 아직 프로덕션 준비가 안 된 이유 — 3가지 갭

1. 툴링 격차: ML 보안 툴링은 일반 소프트웨어 업계 대비 수년 뒤처져 있음. 일반 소프트웨어 팀은 자동화된 보안 스캐닝, 제대로 된 패스워드 관리 등을 수십 년 전에 해결했지만 ML 영역에는 아직 이식되지 않았고, ML 특화 위협을 위한 조기 경보 시스템도 부족함.
2. 전문성 사일로(silo): 보안팀은 ML을 모르고, ML팀은 보안을 모르고, 운영팀은 모델이 어떻게 동작하는지 모름 — 문제는 바로 이 틈새(gap)에서 서식한다. 아무도 전체 그림을 갖고 있지 않음.
3. 연구와 현실의 괴리: 연구는 눈에 보이지 않는 미세한(tiny, invisible) 이미지 변형 공격을 방어하는 데 몰두하지만, 현실에서는 도난당한 비밀번호와 이미 가진 접근 권한의 오남용과 싸우고 있음. 연구는 모델 하나를 단독으로 다루지만, 실무는 공유 시스템 위에서 수십 개의 모델을 동시에 운영함.

8) 핵심 아이디어 3 뒷받침 근거 — 성숙도 모델(Maturity Model)

NIST AI 위험관리 프레임워크(AI RMF)에 매핑되는 4단계 성숙도 모델, 각 레벨은 오버헤드 예산과 맥락에 연동:

• 레벨 1 (오버헤드 5% 미만): 최소한의 기본기. 테스트 환경에는 적합하나 프로덕션에는 부적합.
• 레벨 2 (오버헤드 5~10%): 실질적 베이스라인 — 제대로 된 로그인, 암호화, 네트워크 분리, 기본 모니터링. 프로덕션의 최소 기준선.
• 레벨 3: 헬스케어·금융 등 규제 산업이 요구하는 더 고급 통제 추가. 대부분의 팀은 자신이 레벨 3에 있다고 믿지만, 실제로는 설정 상태에 따라 레벨 1이나 2에 머무는 경우가 많음.
• (레벨 4는 슬라이드상 명시적으로 다뤄지지 않았으나 최상위 성숙도로 암시됨)

9) 대부분의 리스크 배후에 있는 3가지 미스컨피규레이션과 해법

1. 기본 설정이 모든 계정에 전체 관리자 권한을 부여 + 만료되지 않는 자격증명(credential) → 키 자체가 스스로 유출 위험을 안게 됨. 해법: 각 계정은 필요한 만큼만 할 수 있어야 하고, 자격증명은 빠르게 만료되어야 함.
2. 평평한 네트워크(flat network) — 시스템의 한 부분과 다른 부분 사이를 막는 것이 없어, 공격자가 한 곳에 침입하면 전체를 장악 가능. 해법: 부분들을 서로 격벽으로 나누고, 단순 네트워크 접근이 아니라 서비스 간 **검증된 아이덴티티(verified identity)**를 요구.
3. 노출된 비밀정보와 모델 — 코드에 하드코딩된 비밀번호, 열린 스토리지에 방치된 모델 파일. 해법: 제대로 된 시크릿 매니저, 암호화, 배포 전 자동 스캐닝. 이것은 "기본 위생(basic hygiene)"에 불과하지만, 뉴스에 나는 침해 사고를 실제로 예방할 수 있다.

세부 내용 및 사례

발표자가 개인적으로 주목하는 4가지 신흥 이슈 (가장 유동적인 영역)

발표자는 "이 부분은 아직 가장 덜 정리된 영역이며, 매주 새로운 게 나온다"고 전제하며 다음 네 가지를 개인적 견해로 공유한다:

1. 프롬프트 인젝션(Prompt Injection): 모델은 "우리의 지시사항"과 "타인이 입력한 내용"을 안정적으로 구분하지 못한다. 교묘하게 작성된 메시지 하나가 시스템 전체를 순식간에 하이재킹할 수 있다.
2. RAG 포이즈닝: 모델이 문서 저장소(document store)에서 답을 끌어오는 구조라면, 그 저장소가 누군가에 의해(혹은 어떤 경로로든) 오염될 경우 시스템 전체가 오염될 수 있다. 아무것도 따로 재훈련(retrain)할 필요조차 없다.
3. GPU 사이드 채널(side channel): 비용 절감을 위해 여러 고객을 하나의 GPU에 함께 태우면, 타이밍 정보(timing information)가 한 고객에서 다른 고객으로 유출될 수 있다.
4. 공급망(Supply Chain): 출처를 제대로 검증하지 않고 퍼블릭 소스에서 모델과 애드온을 다운로드해 사용하는 관행.

발표자는 이 영역의 방어는 아직 미성숙하며 위협이 계속 진화하고 있으므로, 이를 "복음(gospel)"이 아니라 "방향성(direction)"으로 받아들여야 한다고 솔직하게 인정한다.

발표 진행 방식과 톤

• 발표는 15분 분량의 라이트닝 토크 형식으로, 시작부터 "우리가 익숙하게 여기는 방어 상식을 다시 보게 만들겠다"는 도발적(provocation) 프레이밍을 명시적으로 취한다.
• 청중과의 가벼운 상호작용(웃음 유발 멘트 등)이 있었으나 본질적으로는 데이터와 연구 결과에 기반한 진지한 인프라 보안 발제다.
• 시각 자료로 색상 코드화된 다이어그램(4계층 방어 심층 구조, 6개 위협 카테고리, 3단 비용 티어, 4단계 성숙도 모델)을 다수 활용했다.

시사점 및 액션포인트

1. ML/LLM 프로덕션 배포 전 체크리스트를 "인프라 보안" 관점으로 재정비하라. 모델의 정확도나 신박한 방어 알고리즘보다, 기본적인 접근 제어·네트워크 분리·시크릿 관리가 실제 침해를 막는 압도적 1순위 요인이다.
2. 기본값(default) 설정을 반드시 감사하라. Ray 클러스터 사건처럼 "인증이 기본값으로 꺼져 있는데 켜는 걸 깜빡한" 패턴이 반복된다. 배포 파이프라인에 기본 설정 검증 단계를 넣어야 한다.
3. 계정 권한을 최소권한 원칙(least privilege)으로 재설계하고, 자격증명 만료 정책을 강제하라. "만료되지 않는 전체 관리자 권한"은 거의 모든 프로덕션 감사에서 발견되는 공통 실수다.
4. 네트워크를 평평하게 두지 말고 서비스 간 검증된 아이덴티티(mTLS 등)를 요구하는 구조로 세그먼트화하라. 한 곳이 뚫리면 전체가 뚫리는 구조를 없애야 한다.
5. 보안 통제 도입 시 "할 것인가 말 것인가"가 아니라 "오버헤드를 최소화하며 어떻게 구현할 것인가"를 물어라. 저비용(8% 미만) 통제는 전면 적용, 고비용(15~30%) 통제는 고위험 워크로드에만 선택 적용하는 티어드 전략을 채택하라.
6. 팀이 "우리는 레벨 3다"라고 믿기 전에 실제 설정 상태를 성숙도 모델(NIST AI RMF 매핑)에 대입해 검증하라. 자기 인식과 실제 상태 사이의 괴리가 흔하다.
7. 보안팀·ML팀·운영팀 간 지식 격차를 조직적으로 메워야 한다. 이 갭에서 문제가 서식하므로, 크로스펑셔널 리뷰나 공통 언어(threat model 문서 등)를 마련하는 것이 실질적 예방책이다.
8. RAG/에이전트 기반 시스템을 운영 중이라면 프롬프트 인젝션과 RAG 포이즈닝을 별도 위협 모델로 명시적으로 다뤄라. 이 영역은 아직 표준 방어가 없으므로, 최소한 문서 소스 신뢰도 검증과 입력·출력 경계 강화를 우선 적용해야 한다.
9. 멀티테넌트 GPU 환경을 쓴다면 GPU 사이드 채널 리스크를 인지하고, 민감 워크로드에 한해 격리 수준을 높이는 것을 검토하라.
10. 모델/애드온 공급망 검증(서명, 출처 확인, 스캐닝)을 CI/CD에 통합하라. "퍼블릭 소스에서 다운로드해 그냥 쓰는" 관행이 공급망 공격의 진입점이 된다.

핵심 요약 문장: "당신의 LLM 스택을 데이터베이스처럼 지켜라 — 접근을 잠그고, 네트워크를 분리하고, 저장 데이터를 암호화하라. 우리는 이미 그 방법을 알고 있다. 그저 제대로 실행하기만 하면 된다."