생성형 AI 보안 가이드라인
1. 개요
가. 생성형 AI의 개념
생성형 AI(Generative AI) 는 LLM(대규모 언어모델)·확산모델(Diffusion) 등으로 학습 데이터의 통계적 패턴을 익혀 텍스트·이미지·음성·코드 등 새로운 콘텐츠를 스스로 생성하는 AI다. 국가정보원 산하 국가사이버안보센터(NCSC)는 2023년 「챗GPT 등 생성형 AI 활용 보안 가이드라인」을 발간해 공공·기업의 안전한 활용 원칙을 제시했다.
생성형 AI가 기존 IT 시스템과 근본적으로 다른 점은 행위의 예측 불가능성에 있다. 전통적 소프트웨어는 정해진 로직에 따라 결정론적으로 동작하므로 입력·출력의 경계가 명확하고, 방화벽·접근통제 같은 경계 기반 통제가 잘 들어맞았다. 그러나 생성형 AI는 확률적으로 다음 토큰을 예측해 출력을 만들기 때문에 같은 입력에도 다른 답을 내며, 무엇을 "잘못된 출력"으로 볼지 자체가 모호하다. 즉 입력의 자연어가 곧 명령이자 데이터이고, 출력의 정확성을 사전에 보장할 수 없다는 이중의 불확실성이 새로운 공격면을 만든다.
또한 사용자가 자연어로 입력한 내용이 그대로 모델 학습·로그·캐시로 흘러갈 수 있다는 점이 정보보안 관점에서 치명적이다. 전통적 시스템에서 "입력"은 폼 검증을 거친 정형 데이터였지만, 생성형 AI에서는 개발자가 붙여넣은 소스코드 한 덩어리, 상담원이 옮긴 고객 민원 전문이 모두 프롬프트가 된다. 결과적으로 입력·모델·출력 전 구간에 걸쳐 새로운 위협이 발생하므로, 경계 방어 중심의 기존 통제만으로는 부족하고 생성형 AI 특유의 위협 모델에 맞춘 별도 가이드라인이 필요하다.
나. 등장 배경 및 필요성
가이드라인이 요구되는 근본 배경은 AI 도입 속도가 보안 체계 정비 속도를 앞질렀다는 데 있다. 2022년 말 ChatGPT 공개 이후 불과 몇 달 만에 사무·개발·상담 현장에 생성형 AI가 침투했으나, 대부분의 조직은 "무엇을 입력해도 되는가", "출력을 어디까지 신뢰할 것인가"에 대한 정책이 없는 상태에서 이를 사용했다. 통제 없는 자율 도입(Shadow AI)은 곧 기밀 유출·저작권 침해·오정보 반영 같은 사고로 이어졌다.
두 번째 배경은 규제와 책임의 구체화다. EU AI Act, 국내 AI 기본법 등이 고위험 AI에 대한 투명성·위험관리 의무를 규정하면서, 생성형 AI 활용은 더 이상 편의의 문제가 아니라 법적 준수(Compliance)의 문제가 되었다. 조직은 "누가·무엇을·어떤 통제 하에 사용했는지"를 증빙해야 하며, 이를 위해 표준화된 활용·보안 지침이 선행되어야 한다.
다. 활용 서비스 사례
가이드라인이 실제로 필요한 이유는 생성형 AI가 이미 광범위하게 업무에 쓰이고 있고, 그만큼 기밀정보가 노출될 접점이 늘었기 때문이다. 아래 분야는 각각 서로 다른 위협 프로파일을 가진다. 예컨대 개발 영역은 소스코드 유출이, 고객 접점은 개인정보 유출과 프롬프트 인젝션이 핵심 위험이다.
| 분야 | 사례 | 주된 위험 |
|---|---|---|
| 업무 생산성 | 문서 요약·작성, 번역, 회의록 정리 | 영업비밀·미공개 정보 입력 |
| 개발 | 코드 생성·리뷰, 테스트 자동화 | 소스코드·인증정보(Secret) 유출 |
| 고객 접점 | 챗봇 상담, FAQ 자동응답 | 개인정보 유출, 프롬프트 인젝션 |
| 창작·마케팅 | 이미지·디자인·카피 생성 | 저작권 침해, 딥페이크 악용 |
이처럼 분야마다 위험의 성격이 달라, 획일적인 "전면 금지" 또는 "전면 허용" 정책은 모두 부적절하다. 전면 금지는 Shadow AI(음성적 사용)를 오히려 조장하고, 전면 허용은 통제 공백을 낳는다. 따라서 업무 영역별 위험도를 평가해 허용 범위와 통제 강도를 차등화하는 위험 기반 접근이 가이드라인의 출발점이 된다.
2. 생성형 AI 보안 위협의 전체 구조
생성형 AI의 위협은 데이터 흐름의 세 지점(입력·모델/서비스·출력) 과 이를 둘러싼 거버넌스 계층의 관점으로 정리하면 체계적으로 이해된다. 아래 구조도는 위협이 어느 지점에서 발생하는지를 한눈에 보여준다.
flowchart LR
subgraph GOV["거버넌스(정책·교육·감사)"]
subgraph FLOW["데이터 흐름"]
I["입력단(프롬프트)"] --> P["모델/서비스단"]
P --> O["출력단(생성물)"]
end
end
I -.민감정보 입력.-> R1["정보 유출"]
I -.악의적 지시.-> R2["프롬프트 인젝션"]
P -.학습·RAG 변조.-> R3["데이터 오염"]
P -.반복 질의·API 노출.-> R5["모델 탈취·역추론"]
O -.사실성 한계.-> R4["환각"]
O -.생성능력 악용.-> R6["악성콘텐츠 생성"]
입력단에서는 사용자가 기밀·개인정보를 프롬프트에 넣으면 그 내용이 학습·로그에 저장되어 재현·유출될 수 있고(정보 유출), 신뢰되지 않은 입력이 시스템 지침을 덮어써 통제를 우회하는 프롬프트 인젝션이 일어난다. 특히 인젝션은 문서·웹페이지에 숨겨둔 지시가 RAG를 통해 유입되는 간접(Indirect) 프롬프트 인젝션으로 진화하고 있어, 사용자가 직접 악의적 입력을 하지 않아도 공격이 성립한다.
모델/서비스단에서는 학습·RAG 데이터가 변조되면 편향·백도어가 심어지는 데이터 오염(Poisoning) 이 발생하고, API를 반복 질의해 모델을 복제하거나 학습 데이터를 추론하는 모델 탈취·멤버십 추론이 문제가 된다. 이는 조직의 지적재산과 학습에 쓰인 개인정보를 동시에 위협한다.
출력단에서는 통계적 생성의 본질적 한계인 환각(Hallucination) 으로 존재하지 않는 사실이 그럴듯하게 제시되어 의사결정을 오도하며, 생성 능력을 악용한 악성코드·피싱 메일·딥페이크가 만들어진다. 환각은 버그가 아니라 확률적 생성의 부산물이므로 완전 제거가 불가능하고, 근거 제시·검증으로 관리해야 한다는 점이 특징이다.
| 위협 | 주요 원인 | 발생 가능 보안위협 |
|---|---|---|
| 정보 유출 | 기밀·개인정보를 프롬프트에 입력 → 학습·로그 저장 | 영업비밀·개인정보 노출, 재현 유출 |
| 프롬프트 인젝션 | 신뢰되지 않은 입력·문서가 시스템 지침을 덮어씀 | 지침 우회, 권한 탈취, 데이터 유출 |
| 데이터 오염(Poisoning) | 학습·RAG 데이터 변조 | 편향·백도어, 오답 유도 |
| 환각(Hallucination) | 통계적 생성의 사실성 한계 | 오정보의 업무 반영, 의사결정 오류 |
| 악용(Misuse) | 생성 능력의 오용 | 악성코드·피싱·딥페이크 생성 |
| 모델 탈취·역추론 | API 노출·질의 반복 | 모델 복제, 학습데이터·멤버십 추론 |
예를 들어 2023년 한 글로벌 제조기업에서 개발자가 사내 소스코드를 챗봇에 붙여넣어 검토를 맡겼다가 기밀 코드가 외부 모델 서비스에 유입된 사고가 알려지면서, 입력단 정보 유출이 가장 현실적인 위협임이 부각되었다. 이후 해당 기업은 생성형 AI 사내 사용을 한때 전면 금지했다가, 폐쇄형 자체 모델을 구축한 뒤 제한적으로 재허용하는 방향으로 정책을 전환했다.
3. 개발·활용 시 보안 고려사항과 계층별 대응
대응 전략의 핵심은 위협이 발생하는 지점에 맞춰 입력·모델·출력·거버넌스의 계층별 통제(Defense in Depth) 를 짜는 것이다. 아래 아키텍처는 사용자 요청이 여러 통제 관문을 통과하며 안전하게 처리되는 과정을 보여준다.
sequenceDiagram
participant U as 사용자
participant F as 입력 필터(DLP·마스킹)
participant G as AI 게이트웨이(인증·로깅)
participant M as LLM/RAG
participant V as 출력 검수(필터·근거검증)
U->>F: 프롬프트 입력
F->>F: 민감정보 탐지·마스킹
F->>G: 정제된 요청
G->>M: 인증·격리된 요청 전달
M->>M: 시스템/사용자 프롬프트 분리
M->>V: 생성 결과
V->>V: 유해·환각 검증, 워터마킹
V->>U: 안전한 응답
가. 입력단 통제. 가장 우선순위가 높은 방어선이다. 민감정보가 애초에 모델로 유입되지 못하도록 DLP(데이터 유출 방지) 와 정규식·NER 기반 탐지로 주민등록번호·카드번호·API 키 등을 마스킹한다. 조직 차원에서는 "무엇을 입력해서는 안 되는가"를 명시한 입력 금지 정책과 승인 절차를 두어, 기술 통제를 우회하는 예외를 최소화한다. 입력단 통제는 사고를 사후에 수습하는 것이 아니라 원천 차단한다는 점에서 비용 대비 효과가 가장 크다.
나. 모델/서비스단 통제. 프롬프트 인젝션을 막으려면 시스템 프롬프트와 사용자 입력을 명확히 격리하고, 사용자 입력을 신뢰하지 않는다는 전제로 지시와 데이터를 구분 처리한다. RAG를 쓴다면 인덱싱 전에 문서 출처와 무결성을 검증해 간접 인젝션·오염을 차단한다. 또한 모델 탈취를 막기 위해 API에 인증·Rate Limiting을 걸고 모든 질의를 로깅해 이상 질의 패턴을 탐지한다.
다. 출력단 통제. 생성 결과를 그대로 신뢰하지 않고 필터·검수 계층을 둔다. 유해·차별·개인정보 포함 여부를 검사하고, 사실성이 중요한 업무에서는 근거(출처) 제시를 강제해 환각을 사람이 검증할 수 있게 한다. 생성물에는 워터마킹·출처표시(C2PA 등)를 넣어 딥페이크 악용을 추적한다. 출력단은 "사람의 최종 검토(Human-in-the-loop)"와 결합할 때 가장 효과적이다.
라. 거버넌스 계층. 위 기술 통제 전체를 조직의 정책·교육·감사가 감싼다. 이용정책·승인 절차, 정기 임직원 교육, 민감 업무를 위한 프라이빗 모델·망분리, 그리고 활용 이력에 대한 감사가 여기에 속한다. 대부분의 정보 유출이 악의보다 부주의에서 비롯되므로, 거버넌스는 기술로 막지 못하는 "사람의 실수"를 줄이는 마지막 안전망이다.
계층별 통제를 설계할 때 유의할 점은, 각 계층이 독립적으로 작동해야 한다는 것이다. 입력 필터가 뚫려도 모델단 격리가 인젝션을 걸러내고, 그마저 실패해도 출력 검수가 민감정보 유출을 막는 식으로 다중 방어선(Defense in Depth) 을 구성해야 단일 통제 실패가 곧 사고로 이어지지 않는다. 특히 생성형 AI는 신규 위협이 계속 등장하므로, 특정 통제 한 겹에 의존하는 설계는 위험하다.
| 구분 | 보안 고려사항 | 대응 방안 |
|---|---|---|
| 입력 | 민감정보 유입 차단 | 입력 필터링·마스킹, DLP, 민감정보 입력 금지 정책 |
| 모델/서비스 | 인젝션·오염·탈취 방지 | 프롬프트 격리(시스템/사용자 분리), 입력 검증, 접근통제·로깅, RAG 데이터 검증, Rate Limiting |
| 출력 | 유해·부정확 결과 통제 | 출력 필터·검수, 근거 제시, 워터마킹, 환각 검증, Human-in-the-loop |
| 거버넌스 | 조직 차원 통제 | 이용정책·승인 절차, 임직원 교육, 프라이빗 모델·망분리, 감사 |
4. 기존 정보보안과의 비교 및 사례
생성형 AI 보안이 기존 정보보안과 다른 지점을 이해하면 왜 별도 통제가 필요한지가 분명해진다. 전통 보안은 "신뢰 경계"를 그어 내부를 보호하는 방식이었으나, 생성형 AI에서는 입력 자연어 자체가 잠재적 명령이므로 경계 안에서도 공격이 성립한다. 또 전통 보안은 무결성·기밀성·가용성(CIA)을 다뤘지만, 생성형 AI는 여기에 사실성(정확성)과 편향 이라는 새로운 축을 더한다.
| 관점 | 기존 정보보안 | 생성형 AI 보안 |
|---|---|---|
| 위협 대상 | 데이터·시스템(정형) | 데이터 + 모델 + 출력(비정형) |
| 공격 벡터 | 코드 취약점·네트워크 | 자연어 프롬프트·학습데이터 |
| 핵심 속성 | 기밀·무결·가용(CIA) | CIA + 사실성·편향·설명가능성 |
| 통제 방식 | 경계·서명 기반 | 계층·검증·거버넌스 기반 |
이 표에서 특히 주목할 차이는 공격 벡터다. 기존 보안에서 공격자는 코드 취약점이나 네트워크 경로를 노렸지만, 생성형 AI에서는 정상적인 사용 경로인 "자연어 입력" 자체가 공격 수단이 된다. 방화벽을 통과한 정상 트래픽 안에 악의적 지시가 담겨 있을 수 있으므로, 트래픽의 정오(正誤)를 네트워크 계층에서 판단하기 어렵다. 이 때문에 통제의 무게중심이 네트워크 경계에서 애플리케이션·데이터·출력 검증 계층으로 이동한다.
구체 사례로, 공공기관에서 민원 답변 초안을 생성형 AI로 만들면서 존재하지 않는 법령 조항을 인용한 환각 사례가 보고되었고, 이는 출력 검증(근거 제시) 없이 결과를 신뢰하면 안 된다는 교훈을 남겼다. 반대로 금융권은 폐쇄형 LLM을 사내에 구축하고 모든 질의를 로깅·감사하는 방식으로, 생산성 이익은 취하면서 데이터 유출 위험을 통제한 모범 사례를 만들어가고 있다.
또 다른 사례로, 개발 생산성 도구가 사내에 확산되면서 개발자가 코드 자동완성에 API 키·DB 접속정보 같은 비밀정보(Secret) 를 무심코 포함해 요청하는 문제가 드러났다. 이에 대응해 일부 기업은 IDE 플러그인 단계에서 Secret 패턴을 탐지·차단하는 입력 필터를 도입했는데, 이는 "위협이 발생하는 지점(입력단)에 가장 가까운 곳에서 막는다"는 계층 방어 원칙을 잘 보여준다. 세 사례의 공통 교훈은, 생성형 AI 보안은 특정 한 지점의 통제로 완결되지 않으며 입력 차단·출력 검증·조직 정책이 함께 작동할 때 비로소 실효를 갖는다는 것이다.
5. 심화: 국제·국내 표준과 최신 동향
생성형 AI 보안은 개별 기업의 노력을 넘어 표준화·규제 프레임워크로 빠르게 수렴하고 있다. 기술사 관점에서는 아래 프레임워크를 연계해 위험 기반 관리 체계를 설계할 수 있어야 한다.
- OWASP Top 10 for LLM Applications: LLM 애플리케이션 특유의 위협을 정리한 사실상 표준으로, 프롬프트 인젝션·민감정보 노출·공급망·데이터 오염·과도한 대리권(Excessive Agency) 등을 다룬다. AI 에이전트가 도구를 자율 호출하는 시대가 되면서 "과도한 권한 위임" 위협의 비중이 커지고 있다.
- NIST AI RMF(AI 위험관리 프레임워크) 1.0: Govern·Map·Measure·Manage의 4대 기능으로 AI 위험을 관리하며, 2024년 생성형 AI 프로파일(NIST AI 600-1)을 별도로 추가해 생성형 AI 고유 위험에 대한 통제 항목을 제시했다.
- ISO/IEC 42001: AI 경영시스템(AIMS) 국제표준으로, ISMS(27001)처럼 조직이 AI 위험을 지속 관리하는 체계를 인증 형태로 요구한다.
- 규제: EU AI Act는 위험 기반(금지·고위험·제한적·최소) 접근으로 투명성·문서화 의무를 부과하며 단계적으로 시행된다. 국내 AI 기본법(인공지능 발전과 신뢰 기반 조성 등에 관한 기본법)은 고영향 AI·생성형 AI의 투명성(생성물 표시) 의무 등을 규정한다. 다만 세부 시행령·기준은 계속 정비되는 단계이므로 최신 고시를 확인해야 한다.
이처럼 표준은 "무엇을 막을 것인가(OWASP)"에서 "조직이 어떻게 지속 관리할 것인가(NIST·ISO)", "국가가 무엇을 강제할 것인가(규제)"로 계층화되어 있으며, 실무는 이 셋을 매핑해 자사 통제로 구현하는 방향으로 나아간다.
최신 동향으로 주목할 것은 위협의 무게 중심이 단일 프롬프트 공격에서 자율 에이전트·멀티모달로 확장되고 있다는 점이다. 도구를 호출하고 여러 단계를 자율 수행하는 AI 에이전트는 한 번의 인젝션이 실제 시스템 조작(파일 삭제, 결제 등)으로 이어질 수 있어 위험의 파급이 크다. 또 이미지·음성까지 다루는 멀티모달 모델은 이미지 속에 숨긴 지시로 인젝션을 시도하는 새로운 공격면을 만든다. 따라서 방어 체계도 텍스트 중심에서 벗어나 에이전트의 행위 승인·멀티모달 입력 검증으로 확장되어야 한다.
6. 고려사항 및 시사점
- 기술·정책·인적 통제의 3축 병행: DLP·프롬프트 격리 같은 기술 통제만으로는 부족하다. 이용정책과 임직원 교육이 함께 가야 실질적 방어가 된다. 대부분의 정보 유출은 악의보다 부주의에서 비롯되므로, 사람에 대한 투자가 곧 보안 투자다.
- 데이터 주권과 배포 모델 선택의 트레이드오프: 민감 업무는 외부 상용 API 대신 폐쇄형·온프레미스 LLM과 RAG로 구성해 데이터가 조직 밖으로 나가지 않게 한다. 다만 자체 구축은 GPU·운영 비용이 크므로, 데이터 민감도에 따라 상용 API·프라이빗 인스턴스·온프레미스를 차등 적용하는 하이브리드 전략이 현실적이다.
- 규제·거버넌스 연계: EU AI Act, 국내 AI 기본법, ISO/IEC 42001 등을 연계해 위험 기반 관리 체계를 갖추고, 생성물 표시·설명가능성 등 신뢰성 요건을 사전에 설계에 반영(Security/Compliance by Design)한다.
- AI 에이전트 시대의 권한 최소화: 도구를 자율 호출하는 에이전트는 "과도한 대리권"이 새로운 위협이 된다. 에이전트에 부여하는 권한을 최소화하고, 위험 행위에는 사람의 승인을 두는 통제가 필요하다.
- 공방의 상시화(지속적 레드팀): 적대적 프롬프트·탈옥(Jailbreak) 기법은 계속 진화하므로, 일회성 점검이 아니라 레드팀·모니터링을 상시 운영해 방어를 지속 갱신해야 한다.
- 투명성·설명가능성 확보: 규제가 요구하는 생성물 표시(워터마킹)·의사결정 근거 제시는 사후 대응이 아니라 서비스 설계 시점에 반영해야 하며, 이는 사용자 신뢰와 법적 책임 소명 양쪽에 기여한다.
참고자료
- 국가정보원 국가사이버안보센터, 「챗GPT 등 생성형 AI 활용 보안 가이드라인」 — https://www.ncsc.go.kr
- OWASP Top 10 for LLM Applications — https://owasp.org/www-project-top-10-for-large-language-model-applications/
- NIST, AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework
- EU Artificial Intelligence Act — https://artificialintelligenceact.eu/
한 줄 요약: 생성형 AI 보안은 정보유출·프롬프트 인젝션·데이터 오염·환각·악용·모델 탈취 위협을 입력(DLP)·모델(격리·검증)·출력(필터·근거·워터마킹)·거버넌스(정책·교육·감사)의 계층별로 통제하며, 기술·정책·교육의 3축 병행과 데이터 주권 확보, OWASP·NIST·EU AI Act 등 표준·규제 연계를 핵심으로 한다.