LLM 보안과 운영 방어 계층

LLM 보안은 자연어 입력, 비결정성, tool 권한 때문에 전통 웹 보안과 다른 공격 표면을 가진다. OWASP LLM Top 10, prompt injection, excessive agency, RAG 위험, 컴플라이언스, defense-in-depth를 운영 관점에서 정리한다.

Layer: L12
Duration: 길이 미정
Generated: 2026. 5. 25. 오후 4:32:01

원본 문서 읽기 오디오 파일 열기

Script Companion

오디오와 함께 스크립트 보기

01
LLM 보안이 따로 필요한 이유는 공격 표면이 전통 웹 앱과 다르기 때문이다. 전통 웹 앱은 HTTP, 데이터베이스, 정해진 API 경계처럼 비교적 분명한 지점에서 입력을 검사한다. 반면 LLM 앱은 자연어 입력, 비결정적인 응답, 그리고 agent가 가진 tool 권한까지 함께 다룬다. 2024년 이후 production 환경에서 prompt injection, data exfiltration, agent 탈옥 사고가 발생했고, 의료, 금융, EU AI Act 같은 규제 요구도 함께 커졌다.
02
표준 분류로는 OWASP LLM Top 10 2025가 중심에 있다. 여기에는 Prompt Injection, Sensitive Information Disclosure, Supply Chain, Data and Model Poisoning, Improper Output Handling, Excessive Agency, System Prompt Leakage, Vector & Embedding Weaknesses, Misinformation, Unbounded Consumption이 포함된다. 이 목록은 단순한 체크리스트라기보다, LLM 앱 audit에서 빠뜨리기 쉬운 위험을 같은 언어로 분류하게 해 주는 기준이다.
03
전통 웹 보안 모델의 한계는 instruction과 data를 구문적으로 분리할 수 있다는 가정에서 드러난다. SQL에서는 parameterize로 데이터와 명령을 분리할 수 있지만, LLM prompt에서는 system instruction과 user data가 같은 토큰 시퀀스로 모델에 들어간다. 문서는 이를 boundary-less token stream이라고 설명한다. 그래서 WAF, CSP, prepared statement 같은 기존 방어를 그대로 대응시키면 indirect injection이나 excessive agency가 누락될 수 있다.
04
Prompt Injection은 LLM01로 분류되는 가장 흔한 공격이다. 사용자가 직접 공격 문구를 넣는 Direct Injection도 있지만, agent와 RAG에서는 외부 데이터에 숨겨진 지시가 더 위험해진다. 이메일, 웹페이지, 검색 결과, tool result가 자동으로 prompt에 들어오면 외부 데이터가 곧 instruction처럼 작동할 수 있다. Liu et al.은 36개 production LLM-integrated 앱 중 31개, 약 86%가 하나 이상의 injection 변형에 취약하다고 확인했다.
05
Indirect prompt injection의 운영상 결론은 tool result를 user input과 같은 신뢰도로 봐야 한다는 점이다. INJECAGENT 평가에서 ReAct GPT-4는 indirect prompt injection에 24% 통과했다. 의료 시뮬레이션에서는 webhook 기반 injection 성공률이 94.4%, FDA Category X 고위험 시나리오가 91.7%로 제시된다. 이런 수치는 단일 방어를 믿기보다 defense-in-depth를 기본값으로 두어야 한다는 근거가 된다.
06
방어 패턴은 입력과 출력을 분리하고, trusted 영역과 untrusted 영역을 명확히 나누는 데서 시작한다. Structured prompt는 user input을 XML tag나 JSON으로 격리하고, Spotlighting은 user input을 별도 문자, datamarking, base-64 encoding으로 표시한다. Hines et al.의 GPT-family 실험에서는 indirect injection 공격 성공률이 50% 초과에서 2% 미만으로 줄었다. 다만 base-64 모드는 토큰이 약 33% 늘고, 메타정보가 응답에 새는 silent failure도 가능하다.
07
Jailbreak는 system이 거부해야 할 응답을 우회로 끌어내는 공격이다. Role-play, DAN, base64나 rot13 같은 Encoding, Anthropic 2024의 Many-shot jailbreak, Crescendo, Sycophancy abuse가 대표 패턴으로 정리된다. 방어는 강한 alignment, input filter, output filter, red-team 데이터 fine-tune, AILuminate, HarmBench, JailbreakBench 같은 평가로 이어진다. 여기서도 핵심은 한 번의 필터가 아니라 반복 평가와 회귀 셋 관리다.
08
Sensitive Information Disclosure는 system prompt, training data, tool이나 RAG context가 의도와 다르게 노출되는 문제다. 방어는 시스템 prompt에 비밀을 두지 않고, 환경 변수나 secret store를 쓰며, output에서 API key 같은 패턴을 검사하는 방식으로 잡는다. RAG에서는 사용자 권한 metadata filter가 중요하다. Supply Chain 위험은 HuggingFace open-weight 모델, 공개 fine-tune dataset, pip와 npm 의존성, Sleeper agents 같은 백도어 가능성으로 확장된다.
09
Improper Output Handling은 LLM 출력을 sanitize 없이 그대로 쓰면서 XSS나 SQL 실행 같은 전통 웹 취약점이 LLM 앱에 들어오는 경우다. HTML escape, parameterized SQL, allowlist, structured output strict validation이 필요하고, code 실행은 E2B 같은 sandbox 안에서만 다뤄야 한다. shell 명령을 LLM 출력 그대로 실행하지 않는다는 원칙도 분명하다. LLM이 새 위험을 만들기도 하지만, 기존 웹 보안 기본기를 다시 요구하는 지점도 많다.
10
Excessive Agency는 agent에 과도한 권한을 주었을 때 발생한다. 모든 DB write, 결제, 이메일 발송 권한을 agent가 가질 때, 사용자 권한 밖 작업이나 tool 체인 오용이 실제 사고로 이어질 수 있다. 방어는 Principle of least privilege, 사용자별 tool allowlist, 비가역 액션 전 Confirmation gate, tool 호출당 또는 요청당 Rate limit, 모든 호출 Audit log로 정리된다. 권한 설계는 모델 성능 문제가 아니라 운영 통제 문제다.
11
Vector & Embedding Weaknesses는 RAG 시스템 특유의 공격면이다. Embedding inversion은 임베딩에서 원본 텍스트가 복원될 수 있는 privacy 위험이고, RAG poisoning은 vector store에 공격 문서가 들어가는 문제다. Permission leak과 Unauthorized cross-tenant는 권한 없는 문서나 다른 회사 문서가 검색에 노출되는 상황이다. 그래서 vector store에는 user와 tenant metadata filter가 필요하고, 검색된 문서도 prompt injection 검사 대상이 된다.
12
Unbounded Consumption은 비용과 시간의 보안 문제다. 매우 긴 input이나 output을 강제하는 Token bomb, reasoning 모델의 비용과 시간이 폭증하는 Reasoning DoS, agent loop, 내부적으로 비싼 tool 폭주가 여기에 들어간다. 방어는 max_input_tokens, max_output_tokens, timeout, rate limit, concurrent request 한도, budget alert, circuit breaker, reasoning_budget 제한으로 구성된다. LLM 보안에서는 리소스 한도도 침해 대응의 일부다.
13
Privacy와 Compliance는 운영 절차로 내려와야 한다. PII는 이름, 주민번호, 이메일, 전화 같은 식별 정보이고, PHI는 HIPAA가 다루는 의료 정보다. GDPR은 동의, 삭제권, 데이터 이전을 요구하고, EU AI Act는 고위험 AI 시스템에 대해 2026년 8월 2일까지 full compliance를 요구하며 위반 시 최대 15M 유로 또는 전 세계 매출의 3%가 언급된다. 운영에서는 Presidio 같은 PII redaction, Data residency, ZDR tier, Audit log가 핵심이다.
14
Defense-in-depth Architecture는 production LLM 앱의 표준 보안 layer로 제시된다. 하나의 layer가 뚫려도 다른 layer가 막는 구조이며, input filter, structured prompt, tool 권한, sandbox, output filter, audit log가 함께 놓인다. Red team과 eval도 이 구조의 일부다. HarmBench, JailbreakBench, AILuminate, AI Safety Institute 평가, Continuous red team은 방어가 실제 공격 시나리오에서 계속 유지되는지 확인하는 장치다.
15
운영 도구 선택에는 정량 기준이 필요하다. Llama Guard 3 8B는 Meta 공식 Model Card 기준 FPR 4.0%, F1 Score 0.939 영어, 0.860 이상 다국어로 제시되고, Prompt Guard 86M은 빠르고 경량이라는 장점이 있다. 일반 운영 환경에서는 FPR 5% 이하, FNR 10% 이하가 기준이고, 의료와 금융은 FNR 5% 이하를 목표로 더 엄격하게 잡는다. 다만 각 도구의 측정 조건과 데이터셋이 달라 직접 비교에는 주의가 필요하다.
16
마지막으로 LLM 보안은 input 검증, 정책 강제, 격리 실행, output 검증, audit의 5단계로 요약된다. Prompt injection은 SQL injection, XSS, command injection과 유사한 원리가 보이고, Llama Guard와 Prompt Guard는 WAF에 대응되며, Excessive agency는 RBAC와 privilege escalation 방지에 대응된다. 차이는 자연어 input, 비결정성, tool 권한이 추가된다는 점이다. 플랫폼 엔지니어에게는 OWASP LLM Top 10 audit, RAG 권한 필터, PII redaction, ZDR tier, red team 자동화가 직접적인 작업 단위가 된다.

같은 레이어

L12에서 이어 듣기

원본 문서: content/topics/L12/llm-security.md
오디오 파일: /podcasts/l12-llm-security.mp3