OWASP LLM Top 10 설명: 모든 AI 개발자가 반드시 알아야 할 보안 리스크

만약 여러분이 거대 언어 모델 (Large Language Model, LLM)을 기반으로 애플리케이션을 구축하고 있다면, OWASP LLM Top 10은 여러분이 아마도 간과하고 있을 가장 중요한 보안 프레임워크일 것입니다.

OWASP — Open Worldwide Application Security Project — 는 기존의 애플리케이션 보안 프레임워크가 LLM 기반 시스템이 도입하는 고유한 공격 표면 (Attack Surfaces)을 다루지 못하기 때문에 특별히 LLM Top 10을 발표했습니다. 이 포스트는 여러분이 코드베이스에서 무엇을 찾아야 하는지 정확히 알 수 있도록 실제 사례와 함께 10가지 리스크를 모두 분석합니다.

왜 지금 OWASP LLM Top 10이 그 어느 때보다 중요한가

EU AI Act 제15조는 AI 시스템이 적대적 공격 (Adversarial Attacks) 및 조작에 대해 탄력성 (Resilience)을 갖출 것을 요구합니다. OWASP LLM Top 10은 이러한 요구 사항에 직접적으로 대응하는 실질적인 프레임워크입니다. 규제 기관과 컴플라이언스 담당자들은 AI 특화 사이버 보안 증거의 표준으로서 이를 점점 더 많이 참조하고 있습니다.

만약 여러분의 코드베이스가 EU AI Act 준수 여부에 대해 감사를 받게 된다면, OWASP LLM 조사 결과가 보고서의 일부가 될 것입니다.

LLM01 — 프롬프트 인젝션 (Prompt Injection)

정의: 공격자가 LLM의 입력을 조작하여 지침을 무시하게 하거나, 안전 필터를 우회하거나, 의도하지 않은 동작을 수행하도록 만드는 것입니다.

실제 운영 코드베이스 사례:

사용자 입력이 정제 (Sanitisation) 과정 없이 프롬프트 빌더로 직접 전달됨.
"위의 지침을 무시하세요" 또는 "위의 단어들을 반복하세요"와 같이 알려진 우회 문자열이 정규 표현식 (Regex) 기반 필터를 회피함.

중요한 이유: 사용자 입력이 정제되지 않은 채 프롬프트 구성에 도달하면, 공격자가 모델의 동작을 완전히 하이재킹(Hijack)할 수 있습니다. 이를 통해 시스템 프롬프트를 유출하거나, 안전 가드레일 (Safety Guardrails)을 무시하거나, 악의적인 출력을 생성하게 만들 수 있습니다.

해결책: 모든 사용자 입력이 프롬프트에 도달하기 전에 검증하고 정제하십시오. 입력 허용 목록 (Allowlists)을 사용하십시오. 프롬프트 경계를 보안 경계로 취급하십시오.

LLM02 — 안전하지 않은 출력 처리 (Insecure Output Handling)

정의: LLM의 출력이 eval(), exec() 또는 브라우저 DOM과 같은 하위 시스템(downstream systems)으로 전달될 때, 적절한 정제(sanitisation) 과정 없이 전달되어 공격자가 모델의 출력을 코드 주입(code injection) 또는 XSS 공격으로 연쇄적으로 연결할 수 있게 하는 취약점입니다.

실제 운영 코드베이스 사례:

LLM 출력이 검증 없이 eval() 또는 exec()로 직접 전달됨.
모델이 생성한 마크다운(markdown)이 script 태그나 위험한 요소를 제거하지 않은 채 HTML로 렌더링됨.

중요한 이유: 모델의 출력은 사용자에 의해 제어될 수 있는 데이터입니다. 만약 공격자가 모델이 말하는 내용에 영향을 미칠 수 있고, 모델의 출력이 코드 실행 컨텍스트(code execution context)로 바로 이어진다면, 원격 코드 실행(remote code execution) 취약점이 발생하게 됩니다.

해결책: LLM 출력을 eval(), exec() 또는 DOM 렌더링으로 직접 전달하지 마십시오. 모델의 출력을 신뢰할 수 없는 입력(untrusted input)으로 취급하십시오. 사용하기 전에 반드시 정제(sanitise)하고 검증(validate)해야 합니다.

LLM03 — 학습 데이터 오염 (Training Data Poisoning)

정의: 공격자가 모델의 학습 파이프라인(training pipeline)에 악의적인 데이터를 공급하여, 근본적인 단계에서 모델의 동작을 변질시키는 것입니다.

실제 운영 코드베이스 사례:

학습 데이터셋(training dataset) 소스가 사용자에 의해 제어되거나 검증되지 않음.
무결성 검증(integrity verification)이나 소스 허용 목록(allowlisting) 없이 외부 데이터가 로드됨.

중요한 이유: 오염된 모델은 미묘하게 틀린 출력을 생성하거나, 민감한 학습 데이터를 유출하거나, 특정 트리거 조건에서 악의적으로 동작하도록 만들어질 수 있습니다. 이러한 현상은 배포 전까지는 감지되지 않는 경우가 많습니다.

해결책: 모든 학습 데이터 소스를 검증하고 확인하십시오. 데이터셋에 대해 암호화 무결성 검사(cryptographic integrity checks)를 사용하십시오. 사용자가 제어하는 경로가 학습 파이프라인에 주입되는 데이터에 영향을 미치도록 절대 허용해서는 안 됩니다.

LLM04 — 모델 서비스 거부 (Model Denial of Service)

정의: 공격자가 과도한 컴퓨팅 자원을 소모하도록 설계된 입력을 전송하여, 모델의 추론(inference) 기능을 사용할 수 없게 만드는 것입니다.

중요한 이유: EU AI Act 제15조 1항 4호는 AI 추론의 견고성(robustness)과 가용성(availability)을 명시적으로 요구합니다. 정교하게 조작된 입력에 의해 오프라인 상태가 될 수 있는 모델은 규제상의 가용성 요구 사항을 충족하지 못합니다.

해결책 (Fix): 추론 엔드포인트(inference endpoints)에 속도 제한(rate limiting), 입력 길이 제한(input length caps), 리소스 할당량(resource quotas)을 구현하십시오. 비정상적인 컴퓨팅 소비 패턴을 모니터링하십시오.

LLM05 — 공급망 취약점 (Supply Chain Vulnerabilities)

정의: AI 파이프라인에 도입된 악의적이거나 침해된 모델, 데이터셋, 플러그인 또는 제3자 패키지(third-party packages)를 의미합니다.

실제 프로덕션 코드베이스 사례:

사용자 또는 설정에 의해 제어될 수 있는 URL이나 경로로부터 모델 또는 가중치(weights)를 로드함 — 무결성 검증(integrity verification) 없음.
버전 고정(version pinning)이나 권고 사항 모니터링(advisory monitoring) 없이 제3자 패키지를 로드함.

중요성: 공격자가 모델 가중치를 악의적인 버전으로 교체하거나, 사용 중인 종속성(dependency)이 침해될 경우, 시스템이 생성하는 모든 출력은 신뢰할 수 없게 됩니다.

해결책 (Fix): 모든 종속성 버전을 고정하십시오. 로드하기 전에 모델의 체크섬(checksums)을 검증하십시오. 소프트웨어 자재 명세서(SBOM)를 사용하고 모든 패키지에 대한 CVE 권고 사항을 모니터링하십시오.

LLM06 — 민감 정보 노출 (Sensitive Information Disclosure)

정의: 모델이 학습 데이터, 시스템 프롬프트(system prompts) 또는 컨텍스트 윈도우(context window)로부터 개인 식별 정보(PII), 자격 증명(credentials) 또는 독점 데이터(proprietary data)를 포함한 민감한 정보를 드러내는 것을 의미합니다.

중요성: GDPR 제32조는 개인 데이터의 기밀성을 요구합니다. 만약 모델이 프롬프트에 의해 개인 정보가 포함된 학습 데이터를 드러내도록 유도될 수 있다면, 데이터 유출(data breach) 위험이 발생합니다.

해결책 (Fix): 데이터를 수집하기 전에 학습 데이터에서 PII를 제거하도록 정제(Sanitise)하십시오. 민감한 패턴의 유출을 포착하고 차단하기 위해 출력 필터링(output filtering)을 구현하십시오. 시스템 프롬프트에 비밀 값(secrets)이나 자격 증명을 절대 포함하지 마십시오.

LLM07 — 안전하지 않은 플러그인 설계 (Insecure Plugin Design)

정의: LLM 플러그인 또는 도구가 과도한 권한으로 실행되거나, 모델로부터 검증되지 않은 입력을 수락하거나, 적절한 권한 제어(authorisation controls)가 부족한 상태를 의미합니다.

실제 프로덕션 코드베이스 사례:

허용 목록(allowlist) 없이 사용자 입력에서 도구 또는 플러그인 이름과 매개변수를 가져옴 — 공격자가 임의의 도구를 호출할 수 있음.
ALLOWED_TOOLS 목록이나 도구별 입력 스키마 검증(input schema validation)이 없음.

중요한 이유: 만약 LLM이 플러그인(plugins)을 호출할 수 있고, 그 플러그인들이 모델이 전달하는 모든 정보를 신뢰한다면, 모델의 입력을 제어하는 공격자가 전체 도구 생태계(tool ecosystem)를 제어하게 됩니다.

해결책: 명시적인 ALLOWED_TOOLS 허용 목록(allowlist)을 유지하세요. 모든 플러그인 입력을 엄격한 스키마(schema)에 따라 검증하세요. 모든 플러그인에 최소 권한 원칙(least-privilege permissions)을 적용하세요.

LLM08 — 과도한 대리권 (Excessive Agency)

정의: LLM 기반 에이전트(agent)에게 인간의 확인 없이 시스템 명령을 실행하거나, 파일을 작성하거나, API 호출을 수행하는 등 너무 많은 자율성(autonomy)이 부여되는 것을 의미합니다.

실제 프로덕션 코드베이스 사례:

인간의 승인 단계 없이 LLM 출력 컨텍스트에서 직접 호출되는
subprocess.run() 또는 exec()
에이전트의 결정에 따라 자율적으로 트리거되는
파일 쓰기(File writes)
...

중요한 이유: 이는 EU AI Act(EU 인공지능법)에서 가장 심각하게 다루는 우려 사항 중 하나입니다. 제14조(Article 14)는 고위험 AI 시스템(high-risk AI systems)에 대한 인간의 감독(human oversight)을 요구합니다. 순수하게 모델 출력에만 기반하여 OS 명령을 실행하거나, 파일 시스템에 쓰거나, 외부 API를 자율적으로 호출할 수 있는 에이전트는 거대한 공격 표면(attack surface)을 생성하며 인간의 감독 요구 사항을 직접적으로 위반합니다.

해결책: 실제 세계에 영향을 미치는 LLM 제안 작업(action)을 실행하기 전에는 반드시 명시적인 인간의 승인을 요구하세요. 에이전트 실행 환경을 샌드박스(Sandbox)화하세요. 감사 추적(audit trail) 목적으로 모든 자율적 작업을 로그(log)로 남기세요.

LLM09 — 과도한 의존 (Overreliance)

정의: 사용자나 시스템이 검증 없이 LLM 출력값을 신뢰하여, 환각(hallucination) 또는 잘못된 정보에 기반한 결정을 내리는 것을 의미합니다.

중요한 이유: EU AI Act에 따른 고위험 AI 시스템의 경우, 검증되지 않은 모델 출력에 과도하게 의존하는 것은 제15조(Article 15)에 따른 정확성 및 견고성(accuracy and robustness) 요구 사항을 충족하지 못하는 것으로 간주될 수 있습니다.

해결책: LLM 출력이 실제 결정에 영향을 미치는 모든 워크플로(workflow)에 검증 단계를 구축하세요. 신뢰 수준(confidence levels)을 표시하세요. 불확실성이 낮은 출력에 대해서는 인간의 검토를 위한 플래그(flag)를 지정하세요.

LLM10 — 모델 탈취 (Model Theft)

정의: 공격자가 반복적인 쿼리(querying) 또는 모델 아티팩트(artifacts)에 대한 직접적인 접근을 통해 모델의 가중치(weights), 아키텍처(architecture) 또는 학습 데이터(training data)를 추출하는 것입니다.

중요성: 지적 재산권(intellectual property) 손실을 넘어, 모델 탈취는 공격자가 오프라인에서 귀하의 시스템을 연구하고, 약점을 찾아내며, 적대적 입력(adversarial inputs)을 제작하거나 악의적인 목적으로 귀하의 시스템을 복제할 수 있게 합니다.

해결책: 추론 API(inference APIs)에 속도 제한(rate limiting) 및 이상 탐지(anomaly detection)를 구현하세요. 모델 가중치 파일에 대한 직접적인 접근을 제한하세요. 비정상적으로 체계적이거나 대량의 쿼리와 같은 추출 공격 패턴(extraction attack patterns)을 모니터링하세요.

CybricAI가 OWASP LLM Top 10을 다루는 방법

CybricAI의 Guardian 스캐너는 정적 분석(static analysis)의 일부로 OWASP LLM Top 10 탐지 항목을 자동으로 찾아냅니다. 모든 스캔은 코드베이스의 특정 라인에 매핑된 증거 기반의 LLM 탐지 결과가 포함된 보고서를 생성합니다. 여기에는 프롬프트 인젝션(prompt injection) 우회 패턴, 안전하지 않은 출력 싱크(insecure output sinks), 학습 데이터 파이프라인 리스크(training data pipeline risks), 과도한 에이전시 패턴(excessive agency patterns) 및 공급망 취약점(supply chain vulnerabilities)이 포함됩니다.

탐지된 결과는 EU AI Act 제15조, GDPR 제32조 및 ISO 27001 통제 항목과 교차 참조되어, 하나의 보고서로 귀하에게 필요한 컴플라이언스(compliance) 증거를 제공합니다.

CybricAI는 무료로 사용할 수 있습니다. 지금 바로 코드베이스를 스캔하여 귀하의 AI 시스템에 어떤 OWASP LLM 리스크가 존재하는지 정확히 확인해 보세요.

면책 조항: 이 게시물은 정보 제공만을 목적으로 하며 법적 조언을 구성하지 않습니다.