LLM 스택 보안 가이드: AI 공격보다 인프라 설정 실수가 더 위험한 이유와 대응법 정리

핵심 메시지

• 프로덕션 ML 보안 사고의 대부분은 신종 AI 공격이 아니라 수년 전에 이미 해결책이 나온 평범한 인프라 설정 실수에서 비롯된다.
• 실패의 1순위 원인은 '기능 부재'가 아니라 '잘못된 설정(misconfiguration)'이며, 접근 제어가 열려 있거나 네트워크가 분리되지 않은 경우가 반복된다.
• 논문에서 읽는 방어책은 지연시간·처리량 비용 때문에 실제 프로덕션까지 살아남지 못하는 경우가 많다.
• ML 보안은 모델이 아니라 인프라처럼 다뤄야 한다 — 접근 통제를 잠그고, 네트워크를 분리하고, 저장 데이터를 보호하는 기본이 핵심이다.

쉽게 이해하기

엔비디아 딥러닝 인프라 팀의 러비나 드멜로는 AI Engineer 콘퍼런스 발표에서 도발적인 주장을 내놓는다. 프로덕션 환경에서 터지는 머신러닝 보안 사고의 거의 대부분은 신경망을 노린 이색적인 AI 공격이 아니라, 우리가 오래전에 고쳤다고 믿었던 지루한 인프라 실수라는 것이다.

대표 사례로 2023년 분산 ML 프레임워크 Ray 클러스터 사건을 든다. 수천 개의 클러스터가 대시보드와 작업 API를 열어 둔 채 인터넷에 노출돼 있었고, 원인은 단지 인증이 기본값으로 꺼져 있었는데 프로덕션에 올리며 아무도 켜지 않았기 때문이었다. 제로데이도, 신경망을 겨냥한 영리한 공격도 아니라 그저 설정 하나를 놓친 결과였고 그 노출 규모는 10억 달러를 넘었다.

그는 이 문제를 세 가지 핵심 아이디어로 압축한다. 첫째, 1순위 실패 원인은 부족한 기능이 아니라 잘못된 설정이다. 둘째, 논문에서 접하는 방어책은 지연시간과 처리량이라는 비용 때문에 실제 서비스에서는 살아남지 못한다. 셋째, 그러므로 ML은 모델이 아니라 인프라처럼 지켜야 한다. 실제로 50개 프로덕션 ML 환경을 감사한 연구에서 78%가 최소 하나의 치명적 보안 실수를 안고 있었고, 열린 접근 제어·분리되지 않은 시스템·아무나 닿는 저장소에 놓인 비밀번호와 모델이 반복해서 등장했다.

방어는 4층 구조로 제시된다. 맨 아래 인프라 보안(컨테이너·네트워크·GPU 가상화·암호화)이 토대가 되고, 그 위에 접근 제어, 다시 그 위에 실행 중 트래픽을 감시하는 런타임 보안이 쌓이며, 이 모두를 일상 관행·규정 준수·사고 대응·조직 문화가 감싼다. 토대가 뚫리면 위로 연쇄되기 때문에, 완벽한 접근 제어도 아래 클러스터가 활짝 열려 있으면 장식에 불과하다.

비용 관점도 현실적이다. 로그인·입력 검증 같은 기본 통제는 약 8% 이하의 오버헤드로 항상 켜 둬야 하고, 무거운 격리는 10~20%로 민감한 워크로드에 선별 적용하며, 실시간 악성 입력 탐지는 15~30%로 가장 비싸 모든 요청에 걸 수는 없다. 결국 '이걸 할까'가 아니라 '어떻게 느려지지 않게 잘 구현할까'가 관건이다.

주요 인사이트

• 가장 흔한 세 가지 설정 실수: 모든 계정에 기본으로 부여된 관리자 권한과 만료되지 않는 자격증명, 어디로든 옆으로 이동할 수 있는 평평한(flat) 네트워크, 코드에 박히거나 열린 저장소에 놓인 비밀과 모델 파일.
• 각각의 처방은 명확하다 — 최소 권한과 짧은 수명의 자격증명, 구간 분리와 서비스 간 검증된 신원 요구, 시크릿 매니저·암호화·배포 전 자동 스캔이라는 기본 위생.
• 보안팀은 ML을 모르고 ML팀은 보안을 모르며 운영팀은 모델 동작을 모른다. 문제는 아무도 전체 그림을 못 보는 이 전문성 사일로의 '틈'에서 자란다.
• 연구는 눈에 안 보이는 미세한 적대적 변형을 방어하는 데 몰두하지만, 현실의 싸움은 훔친 비밀번호와 이미 가진 권한의 오남용이다. 연구와 현실 사이의 간극이 크다.
• 앞으로 주시할 미해결 위협으로 프롬프트 인젝션, RAG 문서 저장소 오염, 멀티테넌트 GPU의 사이드채널 정보 유출, 출처 미검증 모델을 받아 쓰는 공급망 위험을 꼽는다.

자주 묻는 질문

관련 AI 소식