생성형 AI 보안 위협, 기술 취약점부터 국내 규제까지 총정리

생성형 AI 보안 위협, 기술 취약점부터 국내 규제까지 총정리

생성형 AI가 업무 곳곳에 들어오면서 보안 위협도 그만큼 늘었다. 문서를 검색하고 이메일을 보내고 데이터베이스까지 조작하는 에이전트가 늘자 사고 유형도 다양해졌다. OWASP가 정리한 기술적 취약점부터 MITRE의 공격 기법 데이터베이스, NIST와 CSA의 조직 관리 기준, 올해 1월 시행된 국내 AI기본법까지 — 생성형 AI를 도입하는 조직이 챙겨야 할 보안 이슈를 한데 모아 정리해 봤다.

flowchart TD
    ROOT["생성형 AI 보안"] --> L1["기술 위험
OWASP"]
    ROOT --> L2["공격 기법
MITRE ATLAS"]
    ROOT --> L3["조직 관리 체계
NIST · CSA · NCSC · SAIF"]
    ROOT --> L4["국내 규제
AI기본법 · KISA · 개인정보위"]

기술 계층 — 무엇이 뚫리는가

가장 세밀한 지도를 그린 건 OWASP다. 지난 8월 4일 발표한 생성형 AI·거대언어모델(LLM) 보안 위험 순위는 3년 만에 처음으로 전문가 투표뿐 아니라 실제 사고 기록을 근거로 삼았다. 투표 비중을 75%로 낮추고, 나머지 25%는 공개 취약점 데이터베이스와 AI 피해 사례 저장소에서 모은 실제 사고로 채웠다. ¹²

그 결과 프롬프트 인젝션과 민감정보 노출은 1·2위를 그대로 지켰지만, 그 아래 순위는 크게 흔들렸다. 모델에게 셸 명령 실행이나 데이터베이스 조작, 이메일 발송 같은 실제 권한을 넘긴 뒤 사고가 난 '과잉 자율성'이 3위로 올라섰다. 챗봇을 넘어 업무를 대신 처리하는 에이전트형 서비스가 늘면서 실제 사고도 함께 늘었다는 뜻이다. ²

LLM이 뚫리는 근본 원인은 하나로 모인다. 지시문과 데이터를 구조적으로 구분하지 못한다는 점이다. 시스템 프롬프트든 사용자 입력이든 검색해 온 문서든, 모델 입장에서는 전부 같은 토큰 나열일 뿐이다. SQL 인젝션을 막는 파라미터화 쿼리 같은 깔끔한 해법이 LLM에는 없는 이유다. 프롬프트 인젝션을 완벽히 막을 신뢰할 만한 방법은 지금 존재하지 않는다는 게 NIST와 영국 NCSC, OWASP가 공통으로 내리는 결론이다. ²⁶

그래서 방어의 초점이 달라진다. 입력을 막는 데만 힘을 쏟기보다, 모델이 뚫렸을 때 실제로 할 수 있는 일 자체를 좁혀두는 쪽이다. 에이전트가 신뢰할 수 없는 입력을 받고, 민감한 데이터에 접근하고, 외부와 통신까지 할 수 있는 세 조건을 동시에 지녔을 때 사고 위험이 가장 크다는 지적이 대표적이다(개발자 사이먼 윌리슨이 이 조합을 'lethal trifecta'라 이름 붙였다). 메타는 이 중 두 가지 이상을 동시에 가진 에이전트라면 중요한 작업마다 사람이 직접 승인하도록 하는 내부 기준을 쓴다. ²

OWASP가 10개 위험을 순위로 나열한다면, 실무에서는 그 위험들을 조금 다르게 다룬다. 데이터가 시스템 안으로 들어와 실제 행동으로 바뀌기까지 거치는 구간을 다섯 개로 나눠 놓고, 그 사이사이를 전부 신뢰하지 않는 경계로 그어두는 쪽이다.

flowchart LR
    A["사용자 · 외부 데이터
입력창 · 문서 · 웹페이지"] --> B["LLM 컨텍스트
프롬프트에 쌓인 모든 내용"]
    B --> C["LLM 자체
추론과 텍스트 생성"]
    C --> D["도구 · 에이전트
셸 · DB · 이메일 · API"]
    D --> E["실제 시스템
파일 · 메일함 · 고객 데이터"]
    B -. RAG 사용 시 .-> F["지식창고 (벡터DB)"]
    C -. 에이전트 사용 시 .-> G["기억 (memory)"]
    D -. MCP 사용 시 .-> H["MCP 서버"]

이 다섯 구간을 나누는 이유는 하나다. 사용자가 직접 친 명령이든, 검색해 온 문서든, 도구가 돌려준 결과든 — 다음 구간으로 넘어가기 전까지는 전부 의심 대상으로 다뤄야 한다는 뜻이다. LLM이 뭐라고 답했든, 그 답을 실제 권한으로 옮길지 말지는 LLM이 아니라 정해진 규칙대로만 움직이는 애플리케이션 코드가 판단해야 한다. ²

10개 위험을 한눈에 정리하면 아래와 같다.

프롬프트 인젝션은 사용자가 직접 입력하는 명령보다 모델이 읽어들이는 외부 콘텐츠에 숨긴 명령이 더 흔하다. 웹페이지·이메일·문서·이미지·음성 어디에도 심을 수 있고, 사용자는 아무것도 못 느낀다. 2024년 마이크로소프트 365 코파일럿에서는 화면에 안 보이는 유니코드 문자에 명령을 숨겨 슬랙 2단계 인증 코드를 빼내는 방법이 실제로 시연됐다. OWASP는 방어를 이렇게 요약한다 — 입력을 막을 수 없다는 전제 아래, 권한을 애플리케이션 코드가 쥐고 있게 하고 최소한으로만 부여하며, 중요하거나 되돌릴 수 없는 작업은 반드시 사람이 승인하게 하라는 것이다. ²

민감정보 노출은 최종 답변에만 있지 않다. 도구 호출에 넘기는 인자, 모델의 추론 과정, 로그, 응답 속도 차이까지 전부 유출 통로가 될 수 있다. 2023년 챗GPT의 레디스 버그로 유료 구독자 1.2%의 결제 정보가 새어 나갔다. 같은 해 한 연구팀은 'poem'이라는 단어를 반복시키는 방법만으로 200달러어치 질의로 GPT-3.5가 학습 데이터를 만 건 넘게 그대로 뱉어내게 만들었다. RAG를 쓴다면 검색 전에 문서·청크 단위로 권한을 확인해야 한다 — 일단 모델에게 전달된 내용은 사후 필터링으로 되돌릴 수 없기 때문이다. ²

과잉 자율성은 에이전트에게 필요 이상의 권한을 주는 데서 시작한다. 이메일을 요약하는 에이전트에게 필요한 권한은 '읽기'뿐인데, 실제로는 '삭제'와 '발송' 권한까지 딸려 있는 경우가 흔하다. OWASP는 원인을 세 갈래로 정리한다 — 필요 이상의 기능, 필요 이상의 권한, 사람 확인 없이 스스로 판단하는 자율성. 대응도 같은 세 갈래다. 쓰지 않는 도구와 기능은 아예 빼고, 데이터베이스 접근 권한은 딱 필요한 작업만큼만 주고, 되돌리기 어려운 작업은 자동 승인하지 않는다. ²

공급망 위험은 이제 pip나 npm 패키지만의 문제가 아니다. 허깅페이스 같은 곳에서 내려받는 기반 모델·데이터셋·경량 미세조정 모듈(LoRA 어댑터)이 전부 공급망이다. 원본 모델은 정상으로 평가되는데 실제 배포되는 압축(양자화) 모델만 공격자가 의도한 대로 동작하도록 조작하는 방법까지 연구로 확인됐다. 검증되지 않은 출처의 모델은 쓰지 않고, 서명과 해시로 무결성을 확인하며, 사용 중인 모델·데이터셋·어댑터 목록을 소프트웨어 구성명세서(SBOM)처럼 관리하는 게 기본 대응이다. ²

데이터·모델 오염은 학습이 끝난 뒤가 아니라 학습이 진행되는 과정 자체를 노린다. 문서 250건만 심어도 매개변수 6억 개에서 130억 개 규모 모델까지 오염시킬 수 있다는 연구 결과가 나왔다. 데이터셋 전체 크기와 무관하게 통하는 공격이다. 사내 RAG 지식창고에 최적화된 문서 한 건만 끼워 넣어도, 정확한 원본 내용을 밀어내고 그 문서가 먼저 검색되게 만들 수 있다. 데이터 출처를 추적하고, 학습·검색 데이터를 들여올 때 이상 여부를 점검하는 절차가 필요하다. ²

무제한 소비는 겉보기엔 평범한 짧은 질문 하나로도 시작된다. '추론형' 모델을 끝나지 않는 사고 루프에 빠뜨려 막대한 토큰을 소모시키는 방식인데, 입력 크기를 아무리 제한해도 걸러지지 않는다. 공격자에게는 거의 공짜지만, 서비스 제공자에게는 감당하기 힘든 비용 청구서로 돌아온다. 요청 수 하나만 세는 한도로는 부족하다 — 토큰량, 도구 호출 횟수, 에이전트가 반복하는 단계 수, 걸리는 시간, 실제 과금액까지 다섯 갈래를 각각 따로 재고 막아야 한다. 한도를 넘으면 경고가 아니라 실제로 멈추는 장치를 둬야 한다. ²

허위정보는 환각 자체보다 그 결과를 누군가 그대로 믿고 실행하는 순간 문제가 된다. 에이전트 시스템에서는 특정 조건이 충족됐다고 모델이 착각하는 순간, 의도치 않은 작업이 곧바로 실행되는 식으로 나타난다. 모델의 답을 곧장 행동으로 옮기지 않고, 답이 나온 근거부터 확인하고 정책에 어긋나지 않는지 검증한 다음에야 실행하는 순서를 강제하는 구조가 핵심 대응이다. ²

숨겨진 컨텍스트 노출은 시스템 프롬프트뿐 아니라 내부 정책, 도구 목록과 사용 조건, 응답 형식 규칙까지 전부 포함한다. 시스템 프롬프트는 비밀금고가 아니라는 게 OWASP의 결론이다. 언젠가 드러난다고 가정하고, 자격증명이나 권한 판단처럼 정말 중요한 건 모델이 아니라 애플리케이션 코드 쪽에서 독립적으로 처리해야 한다. ²

벡터·임베딩 취약점은 RAG를 쓰는 조직이라면 특히 눈여겨봐야 한다. 임베딩은 원문을 상당 부분 그대로 복원할 수 있어서, 짧은 문장은 92%까지 정확하게 되돌릴 수 있다는 연구도 있다. '임베딩만 유출됐다'도 원본 문서가 유출된 것과 같은 무게로 다뤄야 한다는 뜻이다. 벡터DB 두 곳(Milvus, RAGFlow)에서는 인증을 통째로 우회하는 치명적 취약점이 지난해 실제로 발견됐다. 여러 고객사 데이터를 한 인덱스에 섞지 않고, 검색 전 단계에서부터 권한을 확인하는 구조가 필요하다. ²

부적절한 출력 처리는 모델이 만든 코드·SQL·HTML을 검증 없이 그대로 실행하다 벌어지는 사고다. 최근엔 터미널이 해석하는 제어문자를 이용해 클립보드 내용을 가로채거나, 챗봇이 자동으로 불러오는 이미지 링크에 대화 내용을 몰래 실어 보내는 방식까지 보고됐다. 모델도 사용자 입력과 똑같이 취급해, 출력을 쓰는 위치에 맞게 검증하고 인코딩하는 절차를 거쳐야 한다. ²

이번 개정은 LLM 애플리케이션 자체에 집중한다. OWASP는 별도로 에이전트가 도구를 호출하고 기억을 유지하며 서로 통신하는 구조에서 벌어지는 사고만 따로 모은 목록도 냈고, 학습 데이터부터 프롬프트·출력까지 데이터 계층 전체를 다루는 문서도 따로 있다. MCP 서버를 직접 만드는 조직이라면 인증과 세션 격리를 다루는 실무 가이드도 참고할 만하다. ⁴⁵¹⁰

공격은 실제로 어떤 순서로 벌어지는가

OWASP의 목록이 '어떤 취약점이 있는가'를 정리한다면, MITRE ATLAS는 '공격자가 그 취약점을 실제로 어떤 순서와 기법으로 이용하는가'를 다룬다. 사이버보안 업계가 오래 써온 MITRE ATT&CK 프레임워크를 AI 시스템에 맞게 확장한 것으로, 84개 공격 기법을 정찰·초기 접근·지속성 확보·영향 같은 전술 단계별로 분류해 계속 갱신되는 지식베이스다. 지난해 10월에는 에이전트형 AI를 겨냥한 공격 기법도 새로 추가됐다.

적지 않은 기업 보안팀이 이미 MITRE ATT&CK로 일반 IT 인프라 공격을 추적하고 있다. ATLAS를 함께 쓰면 이 둘을 하나의 위협 모델로 묶을 수 있다는 이점이 있다 — 탈취한 API 키로 모델 접근 권한까지 넘어가는 경우처럼, 일반 인프라 침해와 AI 특화 공격이 서로 이어지는 지점을 놓치지 않는다는 뜻이다. AI 레드팀이나 이런 통합 관점이 필요한 보안 운영팀에서 특히 유용하다. ⁷

OWASP 목록이 취약점 카탈로그라면, ATLAS는 그 취약점들이 실전에서 어떻게 이어져 하나의 침해로 완성되는지 보여준다. RAG 지식창고 오염(LLM05·LLM09) 하나만 따로 보면 사소해 보이지만, 실제 침해는 보통 이런 순서로 진행된다.

flowchart LR
    R["정찰
대상 조직의 RAG · 벡터DB 구조 파악"] --> IA["초기 접근
조작한 문서를 지식창고에 삽입 (LLM05)"]
    IA --> P["지속성 확보
임베딩 유사도 조작으로 계속 상위 노출 (LLM09)"]
    P --> IM["영향
에이전트가 오염된 근거로 도구를 호출 (LLM03 · LLM10)"]

공격자는 먼저 대상 조직이 어떤 RAG 파이프라인과 벡터DB를 쓰는지 정찰한다. 이어 조작한 문서 한 건을 지식창고에 끼워 넣어 초기 접근을 확보하고, 이 문서가 검색에서 계속 상위에 노출되도록 임베딩 유사도를 조작해 지속성을 만든다 — 여기까지는 데이터 계층 안에서만 벌어지는 조용한 단계다. 마지막으로 에이전트가 이 오염된 문서를 근거로 실제 도구를 호출하는 순간, 조용했던 침해가 눈에 보이는 피해로 바뀐다. 앞서 다룬 10개 위험이 각각 따로 노는 항목이 아니라 하나의 공격 사슬로 이어진다는 걸 이 순서가 보여준다.

조직은 무엇을 챙겨야 하는가

기술적 취약점을 안다고 안전이 저절로 보장되진 않는다. 같은 위험을 두고도 조직 차원에서 답해야 할 질문은 넷으로 나뉜다.

미국 NIST의 AI 위험관리체계(AI RMF)는 "위험을 어떻게 찾아내고 관리할 것인가"에 답한다. 거버넌스 → 위험 식별 → 측정 → 관리로 이어지는 절차를 조직 프로세스 안에 넣는 방법을 다루고, 산하의 생성형 AI 프로파일이 이를 생성형 AI 서비스에 맞게 구체화한다. ⁸

클라우드보안연합(CSA)의 AI 통제 매트릭스(AICM)는 한발 더 나아가 "그래서 실제로 어떤 통제를 두고 있는가"에 답한다. OWASP가 위험이 무엇인지 짚는다면, CSA는 그 위험에 대응할 실제 통제 항목을 18개 영역 247개로 나눠 감사에 바로 쓸 수 있게 만들었다. 프롬프트 인젝션·모델 오염·모델 가중치 보호 같은 AI 특화 통제까지 포함한다. ⁹

영국 NCSC는 "개발 생애주기 전체에서 무엇을 지켜야 하는가"를 다룬다. 설계 → 개발 → 배포 → 운영·유지보수 네 단계로 나눠, 위협 모델링부터 공급망 점검, 로깅·모니터링까지 개발 과정 전체를 관통하는 보안 원칙을 제시한다. 구글의 SAIF는 여기에 에이전트 보안까지 포함한 실무자용 구현 프레임워크를 더한다. ⁶¹¹

네 자료 모두 취약점 목록이 아니라 "조직이 어떤 절차와 책임 체계를 갖고 있어야 하는가"를 다룬다는 공통점이 있다.

이런 표준들이 다 다루지 못하는 조직 내부 위험도 있다. 사용하는 AI 서비스가 입력한 데이터를 모델 학습에 다시 쓰는지, 그 데이터의 권리 관계는 어떻게 되는지는 계약서를 직접 읽어보지 않으면 알 수 없는 경우가 많다. 직원들이 회사가 승인하지 않은 AI 도구에 사내 문서나 고객정보를 붙여넣는 이른바 '섀도우 AI'는 앞서 다룬 민감정보 노출 위험을 조직 내부에서부터 만들어낸다. 모델의 답을 검증 없이 그대로 받아들이는 습관이 쌓이면, 정작 사람이 확인해야 할 순간에 확인하지 않는 자동화 편향으로 이어진다.

한국의 규제 — AI기본법과 국내 가이드

한국은 규제 하나로 그치지 않는다. 올해 1월 22일부터 시행된 AI기본법은 생성형 AI 서비스를 제공하는 기업에 새로운 의무를 지웠다. 결과물이 AI로 생성됐다는 사실을 로고나 문구로 눈에 보이게 표시하거나, 워터마크나 메타데이터로 눈에 보이지 않게라도 표시해야 하는 생성물 표시 의무가 핵심이다. 의료기기·에너지 공급·채용·대출심사·형사수사처럼 생명·안전·기본권에 영향을 미치는 '고영향 AI'로 분류되면 위험관리계획 수립, 설명 가능성 확보, 사람이 즉시 개입할 수 있는 비상정지 기능까지 추가로 마련해야 한다. 표시 의무를 어기면 최대 3천만 원의 과태료가 부과된다. ³

AI기본법이 법적 의무를 정한다면, 실제로 어떻게 지킬지는 실무 안내서 몫이다. KISA는 AI 개발사·서비스 제공자·이용자별로 지켜야 할 보안 요구사항 113개를 정리한 안내서를 냈고, 개인정보보호위원회는 생성형 AI를 개발·운영하는 단계마다 개인정보를 어떻게 다뤄야 하는지 별도 안내서로 정리해 뒀다. 국내에서 서비스를 운영한다면 법 조문만이 아니라 이 두 실무 안내서까지 함께 챙겨야 한다. ¹²¹³

결국 무엇을 해야 하는가

flowchart TD
    subgraph GOV["거버넌스 — 어떤 절차를 두고 있는가"]
        N["NIST AI RMF
+ GenAI 프로파일"]
        CSA["CSA AICM"]
    end
    subgraph THR["위협 · 공격 기법 — 무엇이 취약하고 어떻게 뚫리는가"]
        O1["OWASP LLM Top 10"]
        O2["OWASP Agentic Top 10"]
        O3["OWASP GenAI Data Security"]
        MA["MITRE ATLAS"]
    end
    subgraph ENG["엔지니어링 — 개발 단계에서 무엇을 지키는가"]
        NC["NCSC Secure AI SDLC"]
        SAIF["Google SAIF"]
        MCP["OWASP MCP 서버 가이드"]
    end
    GOV --> APP["애플리케이션 표면"]
    THR --> APP
    ENG --> APP
    APP --> P1["프롬프트 · 인젝션"]
    APP --> P2["RAG · 벡터 · 임베딩"]
    APP --> P3["에이전트 · 과잉 자율성"]
    APP --> P4["MCP · 도구 · 신원"]
    APP --> P5["데이터 · 개인정보"]
    APP --> KR["국내 적용
AI기본법 · KISA · 개인정보보호위원회"]

지금까지 다룬 표준과 가이드를 한 장으로 겹쳐보면 이렇게 정리된다. 위쪽 세 기둥은 서로 다른 질문에 답한다. 거버넌스는 조직이 어떤 절차와 책임 체계를 갖고 있어야 하는지, 위협·공격 기법은 무엇이 취약하고 공격자가 그걸 실제로 어떻게 쓰는지, 엔지니어링은 개발 단계에서 무엇을 지켜야 하는지를 다룬다. 이 세 기둥이 맞닿는 지점이 바로 실제 서비스가 뚫리는 자리 — 프롬프트·RAG·에이전트·MCP·데이터라는 다섯 개의 표면이다.

더 읽어볼 자료를 정리하면 아래와 같다.

생성형 AI 보안은 한 문서로 끝나지 않는다. 기술적 취약점은 OWASP가, 공격이 실제로 벌어지는 방식은 MITRE가, 조직 관리 절차는 NIST와 CSA가, 국내 규제는 AI기본법과 KISA·개인정보보호위원회가 각각 다룬다. 이걸 다 챙긴 조직과 기술 위험 목록 하나만 읽고 넘어간 조직의 차이는, 사고가 나고서야 드러난다.