1. 프롬프트 인젝션 공격과 불안전한 출력 처리
프롬프트 인젝션 공격 대비는 초거대 언어 모델(LLM)의 작동 원리를 악용하는 대표적인 수법입니다. LLM이 사용자의 입력(프롬프트)을 기반으로 답변을 생성한다는 점에 착안하여, 공격자가 고의적으로 조작된 질문이나 지시문을 삽입함으로써 AI를 부적절한 방향으로 유도하거나 금지된 정보를 생성하도록 만드는 것이 핵심입니다. 이 공격은 크게 **다이렉트 인젝션(Direct Injection)**과 **인다이렉트 인젝션(Indirect Injection)**으로 구분됩니다.
다이렉트 인젝션은 공격자가 직접 악의적인 질문을 변조하거나 암호화해 LLM에게 전달하는 방식을 말합니다. 예를 들어, 공격자가 ROT13 같은 단순 암호화를 통해 ‘마약 제조 방법’을 AI가 인식하지 못하도록 숨겨서 전달하면, LLM은 해당 내용이 위험하거나 민감한 정보임을 제대로 인지하지 못하고 답변을 생성해줄 수 있습니다. 반면 인다이렉트 인젝션은 이전 대화나 맥락에 기반한 ‘우회 질문’을 던지는 형태입니다. 먼저 정상적인 질문을 해놓고, 그 답변에 근거해 금지된 내용(예: 폭발물 제조 방법 등)을 다시 묻는 방식으로, AI가 이전 대답을 바탕으로 민감 정보를 생성해버리도록 유도하는 수법입니다.
이와 더불어, LLM 모델이 생성한 출력을 그대로 사용자에게 노출할 때 발생하는 불안전한 출력 처리 문제도 중요합니다. 예컨대 LLM이 생성해낸 텍스트에 악성 스크립트가 포함되어 브라우저에서 실행될 수 있고, 이를 통해 **XSS(Cross-Site Scripting)**나 **CSRF(Cross-Site Request Forgery)**가 유발될 가능성이 존재합니다. 또한 LLM의 출력값이 서버 측 시스템 명령 실행 함수나 API 입력으로 바로 이어질 경우, RCE(Remote Code Execution), SSRF(Server-Side Request Forgery) 등의 심각한 공격 벡터로 이어질 수 있습니다.
대응 방안
- 프롬프트 필터링: 사용자가 입력하는 텍스트에서 위험 단어나 문장 구조를 사전에 차단하거나 치환
- 출력 인코딩: LLM이 생성한 텍스트를 브라우저에 전달하기 전, HTML 엔티티 치환 등을 적용해 악성 스크립트 실행을 방지
- 격리 환경(Sandbox): 코드 실행이나 파일 접근이 필요한 경우에는 AI 모델을 보호된 환경에서 작동시키도록 설계
2. 학습 데이터 중독, 모델 서비스 거부(DoS), 공급망 취약점
2-1. 학습 데이터 중독
LLM을 비롯한 AI 모델은 대규모 데이터셋을 활용해 학습을 진행합니다. 이 과정에서 **데이터 중독 공격(Data Poisoning)**이 발생하면, 모델이 의도하지 않은 편향이나 악성 패턴을 학습하게 되어 백도어(Backdoor) 공격이나 잘못된 의사결정으로 이어질 수 있습니다. 예컨대 공격자가 오픈소스 데이터셋에 악성 예제를 몰래 삽입하면, 모델은 특정 입력에 대해서만 공격자가 원하는 출력을 내도록 ‘오염’될 수 있습니다.
예방 조치로는 AI 개발 과정에서 데이터셋의 신뢰도를 검사하는 ML-BOM(Machine Learning Bill of Materials) 적용이 거론됩니다. 이는 어떤 데이터가 어떤 경로로 수집되고, 어떤 기준을 통해 검증되었는지 투명하게 관리하는 프레임워크입니다. 또한 파인 튜닝(미세 조정) 시에는 외부에서 제공받은 데이터에 대해 세밀한 검사 과정을 거치고, 모델 배포 전에 모의해킹 및 침투 테스트를 통해 안전성을 평가해야 합니다.
2-2. 모델 서비스 거부(DoS)
AI 모델을 과부하시키는 방식으로 **서비스 거부(DoS)**를 유발하는 사례도 늘어나고 있습니다. LLM은 질의응답 과정에서 상당한 자원을 소비하기 때문에, 악의적 공격자가 반복적인 대규모 요청이나 특수 토큰을 활용해 모델 연산을 과도하게 유발할 수 있습니다. 이로써 서버 비용이 폭증하거나 모델 응답 속도가 급격히 저하되어, 정상적인 사용자들이 서비스를 이용하기 어렵게 됩니다.
이를 막기 위해서는 IP 기준으로 API 요청 횟수를 제한하거나, 입력 길이를 제한해 과도한 텍스트가 한 번에 들어오지 못하도록 제어해야 합니다. 또 특정 패턴의 요청이 비정상적으로 반복될 경우, 이를 자동으로 차단하고 관리자에게 경고를 전달하는 모니터링 체계를 구축하는 것이 권장됩니다.
2-3. 공급망 취약점
AI 애플리케이션이 만들어지는 과정에서 사용되는 오픈소스 패키지, 외부 라이브러리, 제3자 모델 등이 공격자에 의해 변조되거나 오염될 경우, 최종 서비스에도 심각한 보안 결함이 발생할 수 있습니다. 예를 들어, 취약점이 있는 모델을 무심코 불러와서 서비스에 적용하면, 공격자가 그 모델의 특성을 악용해 내부 시스템을 침해할 가능성이 생깁니다.
이를 예방하려면 **SBOM(Software Bill of Materials)**처럼 AI 모델 구성요소와 버전을 체계적으로 관리하고, 정기적으로 업데이트를 확인해야 합니다. 특히 새로운 모델이나 데이터셋을 도입할 때는 신뢰할 만한 출처인지, 이전에 알려진 취약점은 없는지 세심한 검토와 테스트를 수행해야 합니다.
3. 민감정보 노출, 플러그인 설계 미흡, 에이전시 과도, 의존성 문제
3-1. 민감정보 노출
AI 모델이 생성한 응답에 개인정보나 기업 내부 문서 등 민감정보가 포함되어 노출되는 사고도 우려됩니다. 학습 단계에서 민감 데이터가 제대로 필터링되지 않았거나, 데이터 접근 권한 설정이 허술한 경우가 대표적 원인입니다. 예컨대 일부 대화형 AI 서비스에서, 특정 사용자가 입력한 민감 정보가 다른 사용자에게 노출되는 버그 사례가 실제로 보고된 바 있습니다.
대응 방안은 △데이터 검증 프로세스 강화 △민감정보 필터링 로직 도입 △모델 출력을 재검증하는 권한 분리 등을 꼽을 수 있습니다. 또한 학습 과정에서 개인정보를 적절히 비식별화(De-identification)하거나, 회사 기밀 데이터의 경우 별도의 사설 모델을 구축해 외부와 물리·논리적으로 분리된 환경에서만 활용하도록 설계하는 것이 좋습니다.
3-2. 부적절한 플러그인 설계
LLM 플러그인이 잘못 설계된 경우에도 보안 문제가 일어납니다. 플러그인이 과도한 권한을 갖고 있어서 시스템 파일을 열람·수정하거나, 사용자 요청을 검증 없이 처리해 악성 명령을 실행하는 식의 취약점이 대표적입니다. 공격자는 이를 악용해 플러그인 자체의 취약점을 파고들어, 서비스 내부 권한까지 획득할 수 있습니다.
전문가들은 플러그인 제작 시 △매개변수 검증 △입력검증 △필요 최소한의 권한만 부여(권한 분리) △사용자에게 민감 작업을 수행하기 전 재확인을 요구하는 프로세스 등이 필수라고 조언합니다.
3-3. 과도한 에이전시(Agency)
‘에이전시’란 AI가 특정 권한을 갖고 자동으로 행동하도록 하는 기제를 의미합니다. 예를 들어, 스스로 파일 다운로드·업로드, 다른 API 호출, 시스템 변경 등을 수행하는 경우입니다. 이러한 에이전시가 지나치게 확장되면, 사람의 검수 없이 중요한 결정이나 작업이 AI에 의해 실행될 수 있어 보안 리스크가 커집니다. 따라서 고위험 작업에는 반드시 관리자 승인 또는 2중 확인 과정을 거치도록 설계해야 합니다.
3-4. 과도한 의존
LLM이 생성한 정보를 사용자가 검증 없이 신뢰해버리면, 허위사실 유포나 잘못된 의사결정으로 이어질 수 있습니다. 공격자는 이를 역이용해 왜곡된 정보를 퍼뜨리거나, 모델 출력이 틀렸음에도 사용자들이 그대로 믿도록 유도할 수 있습니다. 따라서 LLM 결과를 다른 소스와 교차 검증하거나, 중요한 의사결정 시에는 반드시 전문가 의견을 추가로 반영하는 문화가 정착되어야 합니다.
4. 모델 탈취 위협과 대응 전략
마지막으로, 모델 탈취는 AI 기술이 각광받는 시기에 매우 치명적인 보안 이슈로 떠오르고 있습니다. 공격자가 대규모 언어 모델(LLM)이나 이미지·음성 생성 모델의 내부 구조, 가중치(Weights)를 무단으로 입수하거나 복제한다면, 그 모델 자체를 상업적으로 재판매하거나 악의적 용도로 재학습하는 데 사용할 수 있습니다. 특히 모델이 기업의 핵심 자산으로 취급되는 경우가 많은데, 탈취가 발생하면 막대한 경제적 손실과 평판 훼손이 뒤따르게 됩니다.
- 무단 접근 방지: 모델이 배포되는 서버와 API에 대한 엄격한 액세스 제어(Access Control) 적용
- 로그 모니터링: 모델 호출 이력을 정기적으로 모니터링해, 과도한 요청 패턴이나 의심스러운 파일 다운로드 시도를 감지
- API 속도·사용량 제한: RESTful API나 gRPC 인터페이스를 통해 모델에 접근하는 경우, 일정 시간 내 요청 횟수나 데이터 전송량을 제한해 대규모 복제를 방지
- 추출 시도 필터링: 자동화된 방식으로 모델 내부 파라미터를 유추·재구축하려는 공격이 감지되면 즉시 차단 조치를 취하고 관리자에게 알림
아래 표는 2024~2025년을 기준으로 보안 분야 주요 기관·기업(OWASP, 국가정보원, SK쉴더스 등)에서 제시하는 LLM 보안 위협과 대응 방안을 요약한 예시입니다.
| 위협 유형 | 주요 공격 기법 | 대응 전략 |
|---|---|---|
| 프롬프트 인젝션 | ROT13 등으로 암호화된 민감 질의 전송 | – 입력 필터링, 출력 인코딩 – 샌드박스 환경에서 실행 |
| 불안전한 출력 처리 | LLM 출력 통한 XSS/CSRF/RCE 시도 | – 브라우저 출력 시 HTML 엔티티 치환 – 서버 측 명령 실행 전 사용자 승인 절차 |
| 학습 데이터 중독(포이즈닝) | 오픈소스 데이터셋에 악성 레이블 삽입 | – ML-BOM 구축 – 모델 배포 전 모의해킹 및 검증 |
| 모델 DoS 공격 | 반복 API 호출, 특수 토큰 이용한 과부하 | – API 요청 제한, 모니터링 – 입력 길이 제한 |
| 공급망 취약점 | 취약한 외부 라이브러리·모델·데이터셋 사용 | – SBOM 적용, 정기 업데이트 – 신뢰할 수 있는 소스만 사용 |
| 민감정보 노출 | 사용자 간 대화 기록 노출, 개인정보 노출 | – 데이터 비식별화 – 권한 최소화, 모니터링 |
| 플러그인 취약 설계 | 과도한 권한, 매개변수 검증 부재 | – 플러그인 입력검증 – 고위험 작업 시 사용자 이중 확인 |
| 과도한 에이전시 | AI가 임의로 시스템 변경, 파일 조작 | – 권한 제한, 관리자 승인 절차 – 로그 기록 및 실시간 알림 |
| 과도한 의존 | AI 출력 맹신으로 허위정보 확산 | – 교차 검증, 멀티 에이전트 활용 – 사용자 교육 |
| 모델 탈취 | 무단 접근·복제를 통해 모델 가중치 획득 | – 액세스 제어 강화 – API 요청·속도 제한 – 추출 시도 탐지 |
맺음말: AI 보안을 위한 체계적 준비가 필요하다
AI 시대의 도래와 함께 사이버 공격도 점점 더 정교해지고 창의적인 방식으로 진화하고 있습니다. 프롬프트 인젝션, 데이터 중독, 모델 탈취 등은 기존 보안 체계가 대비하지 못했던 새로운 형태의 위험 요인이며, 다크웹 등을 통해 이러한 공격 기법이 빠르게 확산되고 있습니다.
그렇다고 해서 AI를 배척하거나 도입을 꺼릴 수는 없습니다. 효율성, 혁신, 경쟁력을 고려할 때, AI는 이미 사회 전반에 깊숙이 침투하고 있으며, 앞으로도 확대될 것이 분명합니다. 따라서 각 기업과 기관은 보안 담당 팀을 중심으로 AI 보안 가이드라인과 대응 전략을 수립하고, 다음과 같은 원칙을 지켜야 합니다.
- 데이터와 모델을 전 주기적으로 검사
- 데이터 수집 단계부터 학습, 배포, 운영까지 모든 구간에서 보안 취약점이 없는지 꼼꼼히 모니터링
- 거버넌스와 권한 분리
- 고위험 작업이나 시스템 변경 권한을 AI가 단독으로 행사하지 못하도록 설계
- 사용자 인식 제고
- AI 출력은 결코 절대적이지 않음을 교육하고, 중요한 의사결정에 이용할 때는 교차 검증을 거치도록 강조
- 정책·규제와 협업
- 국가 차원의 AI 보안 규범 및 산업 표준에 적극적으로 대응하고, 관련 정보 교류를 통해 신종 위협을 조기에 파악
종합적으로, AI 기술이 몰고 올 거대한 파급효과 속에서 보안 리스크 관리는 더 이상 선택이 아닌 필수 과제가 되었습니다. 공격자들은 늘 새로운 취약점을 찾고 AI를 악용해 속도를 높이고 있습니다. 그렇기에 우리 사회와 기업들은 선제적인 대비와 투자, 그리고 보안 전문가와의 적극적인 협업을 통해 AI가 제공하는 이점을 안전하게 활용해야 할 것입니다.