LLM과 생성형 AI는 생산성을 크게 높이지만, 코드·문서·개인정보·모델 자산이 외부로 유출될 수 있는 새로운 공격면도 동시에 만듭니다. 특히 코드 어시스턴트, RAG 지식봇, 고객 챗봇, 문서 요약 도구는 사용이 쉬운 만큼 민감 정보가 무심코 프롬프트로 전송되기 쉽습니다.
실무적으로는 전사 정책, LLM 프록시 기반 보안 게이트웨이, DLP·RBAC·감사 로그·암호화·권한 기반 검색 통제를 함께 설계해야 합니다. 핵심은 “무엇을 입력해도 되는가”를 문서화하고, AI 모델·코드 자산 보호 보안 아키텍처로 이를 강제하는 것입니다.
목차
- 도입 환경과 사용 시나리오
- 주요 보안 위협 분류
- 코드 및 내부 정보 리스크 분석
- 정책·거버넌스 중심 대응 방안
- 기술 통제 중심 방지 전략
- AI 모델·코드 자산 보호 보안 아키텍처
- 사례로 보는 대응 방안
- 온프레미스 vs 클라우드 비교
- 규제·감사 체크포인트
- 단계별 로드맵
- 결론 및 체크리스트
- 자주 묻는 질문
본문
1. 도입 환경과 사용 시나리오: 적용 범위를 먼저 정해야 한다
기업의 LLM 활용은 이미 특정 부서의 실험 단계를 넘어섰습니다. 개발팀은 코드 생성과 리뷰를 위해 코드 어시스턴트를 쓰고, 전사 지식봇은 RAG 방식으로 문서를 검색해 답변을 만듭니다. 고객 서비스 조직은 FAQ 챗봇과 상담 보조 도구를 도입하며, 기획·분석 조직은 회의록 정리와 보고서 요약에 생성형 AI를 붙입니다.
문제는 사용자가 단지 질문을 입력한다고 생각해도, 실제 시스템은 현재 파일, 오류 로그, 문서 일부, 검색 문맥, 대화 이력을 모델로 전송할 수 있다는 점입니다. 특히 SaaS형 서비스는 저장 정책과 로그 처리 방식이 제각각이므로, 어디까지 전송되고 무엇이 남는지를 먼저 확인해야 합니다.
| 시나리오 | 주 사용 목적 | 민감 정보 예시 |
|---|---|---|
| 개발팀 | 코드 생성·리뷰 | 핵심 알고리즘, IaC, 인증 로직 |
| RAG 지식봇 | 사내 문서 Q&A | 전략 문서, 계약서, 인사 자료 |
| 고객 서비스 | 상담 자동화 | 이름, 전화번호, 계약번호 |
| 분석·기획 | 요약·보고 | 가격 정책, 미공개 계획 |
LLM 보안의 출발점은 모델 자체가 아니라, 어떤 업무 흐름에서 어떤 데이터가 어떤 경로로 이동하는가를 파악하는 것입니다.
2. 주요 보안 위협 분류: 대응의 출발점
LLM은 일반 웹 애플리케이션과 다른 위협 구조를 가집니다. 프롬프트는 단순 입력값이 아니라 모델 행동을 바꾸는 사실상의 명령이며, 에이전트형 구조는 외부 API 호출과 시스템 작업까지 연결될 수 있습니다. 따라서 기존 입력 검증만으로는 충분하지 않습니다.
대표 위험은 데이터 유출, 프롬프트 인젝션, 모델 도난, IP·라이선스 리스크입니다. OWASP의 LLM 보안 가이드에서도 프롬프트 인젝션과 민감 정보 노출은 핵심 위험으로 반복적으로 다뤄집니다.
| 위협 | 설명 | 대표 예시 |
|---|---|---|
| 데이터 유출 | 입력한 코드·문서가 저장·로그화 | 기밀 보고서 요약 요청 |
| 프롬프트 인젝션 | 악성 입력으로 규칙 우회 | “보안 규칙 무시” 지시 |
| 모델 도난 | 모델 행동·가중치 추정 | 반복 API 호출 추출 |
| IP·라이선스 리스크 | 저작권·오픈소스 혼입 | GPL 코드 유사 출력 |
- 프롬프트 인젝션은 모델의 정책보다 사용자의 악성 입력이 우선 적용되도록 유도합니다.
- Jailbreak는 금지된 응답을 억지로 유도하는 우회 시도입니다.
- 라이선스 리스크는 생성 코드가 내부 정책과 맞지 않는 외부 코드 조각을 닮아 있을 때 발생합니다.
3. 코드 및 내부 정보 리스크 분석: 실제로 어디서 새는가
가장 흔한 사고는 개발자가 레포지토리 코드를 그대로 붙여넣는 경우입니다. 여기에 테스트 실패 로그, 환경 변수, 설정 파일, 배포 오류 메시지까지 포함되면 민감도는 더 높아집니다. 표면적으로는 단순한 디버깅 문의처럼 보여도, 내부 구조와 인증 체계가 외부로 전달될 수 있습니다.
RAG 환경에서는 더 미묘한 문제가 생깁니다. 전사 문서를 일괄 인덱싱하면 권한이 없는 문서가 검색 결과에 섞일 수 있고, 벡터DB나 임베딩 저장소의 IAM이 느슨하면 제3자 조회 가능성이 커집니다. 프롬프트·응답 로그를 평문으로 오래 보관하는 것도 위험합니다.
특히 개인정보가 포함되는 경우에는 GDPR이나 지역별 개인정보 규정, 자동화 처리 관련 기준, 국외 이전 검토까지 함께 봐야 합니다. 다시 말해, LLM 보안은 단지 개발팀의 설정 문제가 아니라 법무·감사·보안·데이터 거버넌스가 함께 묶인 문제입니다.
4. 정책·거버넌스 중심 생성형 AI 내부 정보 유출 대응 방안
생성형 AI 내부 정보 유출 대응 방안의 첫 단계는 전사 정책 수립입니다. “개인 계정으로 외부 LLM 사용 금지”, “승인되지 않은 AI 도구 사용 제한”, “민감 정보 입력 금지 범위 정의” 같은 규칙이 문서로 존재해야 합니다. 더 중요한 것은 이 규칙이 권고가 아니라 실제 업무 절차와 연결돼야 한다는 점입니다.
정책은 데이터 분류와 연결되어야 합니다. 어떤 정보는 자유롭게 입력해도 되지만, 어떤 정보는 승인 후 제한적으로만 사용해야 하고, 어떤 정보는 절대 입력하면 안 됩니다.
| 데이터 등급 | 예시 | LLM 입력 정책 |
|---|---|---|
| 공개 | 보도자료, 공개 FAQ | 허용 |
| 내부용 | 일반 운영 문서 | 제한 허용 |
| 기밀 | 계약, 가격, 내부 전략 | 승인 필요 |
| 극비 | 핵심 코드, 키, 고객 민감정보 | 금지 |
또한 마스킹 규칙을 정교하게 만들어야 합니다. 이메일, 전화번호, 계정 ID, 카드번호, 고객번호 같은 엔티티는 DLP 정책에 포함하고, 로그에는 마지막 일부만 남기거나 *** 형태로 익명화해야 합니다. 교육 메시지도 짧고 반복적이어야 효과가 있습니다. 예를 들어 “LLM은 메신저가 아니다”, “코드를 붙여넣기 전에 민감도를 확인하라” 같은 문구를 IDE와 챗봇 상단에 상시 노출할 수 있습니다.
5. 기술 통제 중심 LLM 보안 위협과 코드 유출 방지 전략
실무에서 가장 강력한 구조는 LLM 앞단에 AI Security Gateway, 즉 LLM 프록시를 두는 방식입니다. 모든 프롬프트와 응답은 이 관문을 통과해야 하며, 이 지점에서 인증, 권한 확인, DLP 검사, 프롬프트 인젝션 필터링, 로깅, 모델 라우팅을 수행합니다.
프롬프트 검사에서는 private_key, access_key, password, .pem, .key 같은 패턴을 탐지해야 합니다. 여기에 이메일, 전화번호, 주민번호, 카드번호, API 토큰도 정규식과 ML 기반 엔티티 탐지로 함께 점검해야 합니다. 중요한 점은 응답에도 동일한 필터가 적용돼야 한다는 사실입니다.
접근 통제는 SSO와 IDP 연동이 기본입니다. RBAC/ABAC 기반으로 사용자별 모델, 데이터, 기능 범위를 제한하고, 사용량 쿼터와 호출 제한도 둬야 합니다. 감사 로그는 SIEM으로 전송하고, 대량 코드 입력, 비정상적 사용량 증가, 특정 민감 패턴 반복 입력이 감지되면 경보를 발생시켜야 합니다.
- 입력 통제: 민감정보 탐지, 마스킹, 차단
- 출력 통제: 응답 내 기밀정보, 개인정보, 금지 응답 필터링
- 접근 통제: SSO, RBAC/ABAC, 팀별 기능 제한
- 운영 통제: 쿼터, 속도 제한, 감사 로그, SIEM 연계
- 배치 통제: 전용 VPC, 온프레미스, KMS/HSM 암호화
6. 엔터프라이즈 AI 모델·코드 자산 보호 보안 아키텍처 설계
AI 모델·코드 자산 보호 보안 아키텍처는 사용자 계층, LLM 프록시, 모델 서빙 계층, 데이터 계층, 보안 인프라 계층으로 나눠 설계하는 것이 일반적입니다. 사용자는 웹 포털, 사내 챗봇, IDE 플러그인을 통해 접속하고, 프록시가 정책을 강제합니다. 그 아래에서 상용 API, 프라이빗 클라우드 LLM, 온프레미스 모델 서버가 용도에 따라 호출됩니다.
| 계층 | 구성 요소 | 핵심 통제 |
|---|---|---|
| 사용자 | IDE, 챗봇, 포털 | SSO, UI 경고 |
| 프록시 | Gateway, 정책 엔진 | DLP, 라우팅, 감사 |
| 모델 서빙 | 상용/사내 LLM | 격리, 호출 제한 |
| 데이터 | 문서, Git, 벡터DB | ACL, 암호화 |
| 보안 인프라 | SIEM, KMS, Vault | 키관리, 탐지 |
코드 자산은 이상적으로 IDE → LLM Proxy → 사내 LLM → 필요 시 코드 리포지토리 API 경로로 흐르게 해야 합니다. 외부 모델에는 원문 코드를 보내지 않도록 프록시에서 차단하거나 익명화하고, 검색 결과 역시 최소 문맥만 전달하는 것이 좋습니다. 또한 Model Registry 암호화, 시스템 프롬프트의 Git 기반 버전 관리, Secret Manager/Vault 기반 비밀 주입을 기본 통제로 넣어야 합니다.
7. 사례로 보는 생성형 AI 내부 정보 유출 대응 방안
첫 번째 사례는 개발 조직의 코드 어시스턴트입니다. 개인용 외부 챗봇 사용을 막고, IDE 플러그인 → LLM Proxy → 사내 LLM 구조로 전환합니다. 프록시는 코드 길이 제한, 민감 키워드 탐지, 사용 패턴 모니터링을 담당하고, 이상 사용이 보이면 보안팀이 교육과 조치를 진행합니다.
두 번째 사례는 사내 지식봇입니다. 문서 인덱싱 시 ACL 메타데이터를 함께 저장하고, 질의 시 사용자 역할에 따라 검색 결과를 필터링해야 합니다. 인사·법무·임원 문서는 기본적으로 인덱싱 대상에서 제외하는 것이 안전합니다.
세 번째 사례는 고객 챗봇입니다. 입력 단계에서 PII를 먼저 마스킹하고, 상용 API를 쓸 경우 학습 비사용 옵션을 운영 기준으로 강제해야 합니다. 로그에는 직접 식별자 대신 해시나 토큰만 남겨야 하며, 시스템 프롬프트에도 개인정보 반복 노출 금지 같은 규칙을 넣어야 합니다.
8. 온프레미스 vs 클라우드 비교: 어떤 구조가 맞는가
| 항목 | SaaS/클라우드 LLM | 온프레미스/전용 LLM |
|---|---|---|
| 장점 | 빠른 도입, 쉬운 업데이트 | 데이터 통제력 높음 |
| 단점 | 저장·보관 정책 확인 필요 | 운영·GPU 비용 부담 |
| 핵심 검토 | DPA, 리전, 학습 사용 여부 | 패치, 취약점, 운영 인력 |
| 추천 업무 | 공개 자료 요약, 마케팅 | 코드, 기밀 문서, PII |
클라우드는 계약과 데이터 처리 방침 검토가 핵심입니다. Private Endpoint, IP 화이트리스트, VPN 같은 네트워크 통제도 반드시 고려해야 합니다. 반면 온프레미스는 운영 부담이 크지만 코드와 내부 정보가 외부로 나가지 않기 때문에 통제력이 높습니다. 현실적으로는 하이브리드 구성이 가장 많습니다. 민감하지 않은 업무는 상용 API로, 코드·기밀 문서는 사내 모델로 보내고, 프록시가 민감도에 따라 자동 라우팅하도록 설계하는 방식입니다.
9. 규제·감사 체크포인트
개인정보와 산업 규제는 LLM에도 그대로 적용됩니다. 어떤 데이터를 입력할 수 있는지, 무엇을 차단하고 마스킹할지, 어떤 경우에 국외 이전 검토가 필요한지 문서화해야 합니다. 감사 대응을 위해 정책, SOP, 아키텍처 다이어그램, DFD, 로그 제출 절차를 함께 보관해야 합니다.
공급망 관리도 중요합니다. 생성 코드에는 SCA를 적용해 라이선스와 취약점을 검사하고, 모델과 라이브러리는 SBOM 형태로 관리하면 변경 추적과 감사 대응이 쉬워집니다. 이런 문서화된 통제 묶음이 규제 친화적인 AI 운영 체계를 만듭니다.
10. 단계별 로드맵: 시작하는 방법
LLM 보안 위협과 코드 유출 방지 전략은 한 번에 완성되지 않습니다. 우선 조직 안에서 공식·비공식으로 사용 중인 모든 LLM 도구를 조사해야 합니다. 개인 계정 사용 여부, 붙여넣는 데이터 유형, 외부 전송 경로, 로그 저장 방식부터 확인하는 것이 좋습니다.
그다음 데이터 분류표, 마스킹 규칙, 승인 절차를 정리하고 파일럿 팀을 운영합니다. 이후 프록시, DLP, IAM, SIEM 연계를 붙여 기술 통제를 중앙화합니다. 마지막으로 위반 사례 리뷰, 프롬프트 인젝션 모의 테스트, 데이터 유출 시나리오 점검을 반복해 조직 표준으로 정착시킵니다.
- 1단계: 사용 현황 조사와 그림자 AI 식별
- 2단계: 정책, 분류표, 승인 절차 수립
- 3단계: 프록시, DLP, IAM, SIEM 기술 통제 구축
- 4단계: 모의 테스트와 사용자 교육 반복
11. 결론: 지속 가능한 생성형 AI 보안 체계로 전환하기
LLM과 생성형 AI는 이제 업무 인프라가 되었습니다. 그러나 체계적인 LLM 보안 위협과 코드 유출 방지 전략이 없으면 코드, 문서, 개인정보, 모델 IP까지 동시에 위험해질 수 있습니다. 결국 해법은 정책·교육·기술을 결합한 생성형 AI 내부 정보 유출 대응 방안과 이를 강제하는 AI 모델·코드 자산 보호 보안 아키텍처를 구축하는 데 있습니다.
자사 점검 체크리스트
- 외부 SaaS LLM을 개인 계정으로 사용하고 있는가
- 코드·기밀 문서를 그대로 입력하는 관행이 있는가
- RAG 시스템에 ACL 기반 검색 필터가 있는가
- 프롬프트·응답 로그가 평문으로 남는가
- DLP, RBAC, SIEM 연계가 되어 있는가
- 학습 비사용 옵션과 리전 설정을 검토했는가
함께 논의할 질문
- 어떤 데이터는 LLM에 절대 입력하면 안 되는가
- LLM Proxy/Gateway는 어느 업무부터 적용할 것인가
- 코드 어시스턴트는 외부형과 사내형 중 무엇이 맞는가
- 벡터DB와 로그 보관 정책은 누가 책임질 것인가
PoC 핵심 점검 포인트
| 항목 | 확인 내용 |
|---|---|
| DLP 정확도 | 민감정보 탐지·오탐 수준 |
| RBAC 연동 | 권한 없는 문서 차단 여부 |
| 모델 배치 | 온프레미스·전용 VPC 적합성 |
| 감사 기능 | 로그 조회·제출 가능 여부 |
| 교육 수용도 | 사용자 정책 이해도 |
부록: 위협-대응 매핑 표
| 위협 | 정책 | 기술 | 아키텍처 |
|---|---|---|---|
| 데이터 유출 | 입력 금지 규칙 | DLP·마스킹 | 프록시·격리 |
| 프롬프트 인젝션 | 사용 가이드 | 필터링·후처리 | 게이트웨이 |
| 모델 도난 | 접근 승인 | 호출 제한·감사 | Model Registry |
| IP 리스크 | 라이선스 정책 | SCA·SBOM | 사내 배포 분리 |
용어 한 줄 정리
- 프롬프트 인젝션: 악성 입력으로 모델 규칙을 우회하는 공격
- RAG: 검색 결과를 LLM 입력에 더해 답변 정확도를 높이는 방식
- LLM Proxy/Gateway: 프롬프트를 중앙 통제하는 보안 관문
- DLP: 민감정보 유출을 탐지·차단하는 기술
- Model Registry: 모델 파일과 버전, 권한, 이력을 관리하는 저장소
- SIEM: 보안 로그를 모아 분석하는 시스템
- SOAR: 탐지 후 자동 대응을 연결하는 운영 체계
자주 묻는 질문 (FAQ)
Q. 회사에서 가장 먼저 막아야 할 LLM 보안 리스크는 무엇인가요?
A. 가장 먼저 통제해야 할 것은 무심코 이루어지는 코드·문서·개인정보의 외부 전송입니다. 따라서 개인 계정 기반 외부 LLM 사용 현황을 파악하고, LLM 프록시와 DLP를 통해 입력 경로를 중앙에서 통제하는 것이 우선입니다.
Q. 사내 RAG 지식봇은 내부망에 있으면 안전한가요?
A. 아닙니다. 내부망에 있더라도 ACL 없는 인덱싱, 과도한 검색 권한, 평문 로그, 느슨한 벡터DB 접근 통제가 있으면 정보 노출이 발생할 수 있습니다. 내부 배치와 권한 기반 검색은 별개의 문제로 봐야 합니다.
Q. 코드 어시스턴트는 외부형보다 사내형이 무조건 더 좋은가요?
A. 무조건 그렇지는 않습니다. 공개 자료 위주 작업은 외부형도 충분할 수 있지만, 핵심 소스 코드나 인증 로직, 인프라 코드가 자주 오가는 환경이라면 사내형 또는 전용 VPC 구조가 훨씬 적합합니다. 중요한 것은 데이터 민감도에 따른 라우팅 정책입니다.
Q. 프롬프트와 응답 로그는 보안상 무조건 끄는 게 좋나요?
A. 무조건 끄는 것보다 최소 수집·마스킹·보존 기간 제한이 더 현실적입니다. 로그는 사고 대응과 감사에 필요하지만, 평문으로 오래 저장하면 2차 유출 위험이 커집니다. 따라서 목적 기반 수집과 익명화가 핵심입니다.
Q. 작은 조직도 AI 보안 아키텍처를 별도로 갖춰야 하나요?
A. 네. 규모가 작더라도 최소한 승인된 도구 목록, 입력 금지 데이터 기준, 로그 정책, 접근 통제, 마스킹 규칙은 필요합니다. 처음부터 거대한 플랫폼을 만들 필요는 없지만, 프록시 중심 통제를 염두에 둔 구조로 시작하는 것이 장기적으로 유리합니다.