[IT-보안점검] LLM 보안 점검표: ‘이거’ 없으면 내부자료 그대로 새나갑니다

LLM 보안: 프롬프트 인젝션·RAG 데이터 유출·대응 체크리스트

LLM을 붙이면 생산성이 크게 오르지만, 동시에 새로운 보안 리스크가 생깁니다. 특히 프롬프트 인젝션, RAG를 통한 데이터 유출, 그리고 툴 호출(에이전트) 오남용은 “기존 웹 보안”과 결이 다릅니다. 이 글에서는 실무자가 바로 적용할 수 있도록 위협 모델 + 대응 체크리스트로 정리합니다.

목 차

LLM 보안이 기존 보안과 다른 이유
프롬프트 인젝션(직접/간접) 이해
RAG 데이터 유출: “검색”이 공격 표면이 되는 순간
툴/에이전트 보안: 권한, 승인, 격리
실무 체크리스트 12개 + FAQ

1. LLM 보안이 기존 보안과 다른 이유

입력이 “자연어”라서 필터 우회가 쉽고, 정책이 애매해지기 쉽습니다.
출력이 “행동”으로 이어질 수 있습니다(툴 호출, DB 조회, 티켓 생성 등).
데이터 경계가 섞입니다(사용자 입력 + 내부 문서 + 외부 웹 + 도구 결과).

따라서 LLM 보안은 “차단”만이 아니라, 권한·승인·격리·감사가 핵심입니다.

2. 프롬프트 인젝션(직접/간접) 이해

유형	설명	대응
직접 인젝션	사용자가 “규칙 무시”, “시스템 프롬프트 출력” 등 지시	정책 분리 + 거부 규칙
간접 인젝션	LLM이 읽는 문서/웹페이지/메일에 공격 지시문이 숨어 있음	출처 신뢰도 + 샌드박스

실무 포인트: “LLM이 읽는 모든 것”이 입력이 됩니다. RAG 문서/웹 크롤링/첨부파일은 보안 입력 경로로 취급해야 합니다.

3. RAG 데이터 유출: “검색”이 공격 표면이 되는 순간

대표 사고 패턴
✔ 권한 없는 사용자가 “유사 질문”으로 내부 문서를 끌어냄
✔ 인덱싱 단계에서 민감정보가 그대로 포함됨(키/토큰/개인정보)
✔ 답변에 “출처(원문)”가 과도하게 노출됨

RAG는 “검색”이기 때문에, 결국 문서 접근제어(ACL)와 출력 통제가 핵심입니다.

4. 툴/에이전트 보안: 권한, 승인, 격리

최소 권한: LLM이 호출 가능한 API/DB 범위를 최소화
승인 단계: 결제/삭제/권한 변경 등 “파괴적 행동”은 사용자 확인
격리: 실행 환경(샌드박스) 분리, 민감 네트워크 접근 제한
감사 로그: “무슨 질문 → 어떤 도구 호출 → 어떤 결과”가 남아야 함

5. 실무 체크리스트 12개 + FAQ

No	체크 항목
1	시스템 프롬프트/정책/비밀키가 모델 입력에 섞이지 않도록 분리
2	RAG 인덱싱 전에 민감정보(키/토큰/PII) 마스킹/차단
3	문서 ACL 기반 검색(사용자 권한에 맞는 문서만 검색)
4	답변에 원문 과다 노출 방지(요약/인용 제한)
5	툴 호출 권한 최소화(읽기 전용부터 단계적 확대)
6	파괴적 행동(삭제/결제/권한변경)은 사용자 승인 요구
7	모델 입력/출력/툴 호출 로그 및 경고(비정상 패턴) 구축
8	프롬프트 인젝션 테스트 케이스를 QA에 포함
9	외부 링크/파일/웹페이지는 신뢰도 기반으로 처리(차단/격리)
10	모델 사용 범위(업무/데이터) 정책 문서화
11	비용 폭증 방지: 요청 제한/캐시/토큰 상한
12	정기 점검: 인덱스 재스캔, 로그 리뷰, 정책 업데이트

FAQ

Q1. 프롬프트를 잘 쓰면 인젝션이 막히나요?
A. 프롬프트는 “완벽한 방패”가 아닙니다. 권한·승인·격리·감사 같은 운영 통제가 필요합니다.

Q2. RAG가 있으면 내부문서가 다 노출되나요?
A. ACL 기반 검색 + 민감정보 마스킹 + 출력 제한을 하면 위험을 크게 줄일 수 있습니다.

※ 본 글은 일반 보안 가이드이며, 조직의 데이터 등급/규제 요구사항에 따라 보완이 필요할 수 있습니다.

[IT-보안점검] TLS/HTTPS 완벽 가이드: 인증서·암호화·HSTS·실수 체크리스트 (0)	2026.01.18
[IT-보안점검] API Security 체크리스트: OAuth·JWT·Rate Limit·WAF까지 (실무 점검표) (0)	2026.01.18