OWASP 기반 GenAI 보안 실무 점검 가이드

부제 : LLM Top 10 (2025)과 Agentic Top 10 (2026)을 활용한 체크리스트

생성형 AI(Generative AI) 워크로드의 양상이 빠르게 변화하고 있습니다. 현재 많은 프로덕션 환경에서 이미 멀티 에이전트 기반의 AI 워크로드가 수행되고 있으며, 이는 AI 애플리케이션의 주요 특징으로 자리잡아 가고 있습니다. 여러 에이전트가 목표를 분담하고, 도구를 호출하며, 서로 협업하고, 독립적으로 의사결정을 내리는 환경에서는 기존 단일 LLM 애플리케이션과는 다른 보안 과제가 생겨납니다.

이에 OWASP GenAI Security Project는 OWASP Top 10 for LLM Applications 2025 외에, 에이전트 환경에 주목한 OWASP Top 10 for Agentic Applications 2026을 핵심 프레임워크로 추가 발표했습니다(2025년 12월 공개, Black Hat Europe 기간에 맞춰 런던 OWASP 행사에서 소개). 전자가 프롬프트 인젝션, 민감정보 노출, 출력 검증 등 LLM 계층의 기본 위험을 다룬다면, 후자는 에이전트 목표 탈취, 메모리 오염, 연쇄 장애, 에이전트 간 통신 보안 등 자율성에서 비롯되는 위험을 다룹니다.

이 블로그에서는 위 두 프레임워크를 기반으로, GenAI 애플리케이션의 보안 수준을 체계적으로 평가할 수 있는 100개의 어세스먼트 질문을 제시합니다. LLM 계층의 기본 보안부터 멀티 에이전트 환경의 자율성 보안까지, 보안팀과 개발팀이 함께 활용하여 현재 시스템의 보안 갭을 식별하고 우선순위에 따라 개선할 수 있도록 구성했습니다.

기존 애플리케이션 보안 어세스먼트(OWASP Top 10 for Web Applications 등)만으로는 GenAI 시스템의 고유한 위험을 충분히 다룰 수 없습니다. 그 이유는 다음과 같습니다.

첫째, LLM은 지시(instruction)와 데이터(data)를 구조적으로 분리하지 못합니다. 이로 인해 프롬프트 인젝션이라는 새로운 유형의 공격이 가능해집니다. OWASP는 이를 LLM01:2025 Prompt Injection으로 분류하며, 직접 인젝션과 간접 인젝션 모두를 포함합니다.

둘째, 자율형 멀티 에이전트 시스템은 단일 LLM 호출과는 근본적으로 다른 위협 모델을 요구합니다. 에이전트들이 팀 단위로 목표를 분담하고, 독립적으로 도구를 호출하며, 공유 메모리를 통해 협업하고, 다른 에이전트에게 작업을 위임하는 환경에서는 한 에이전트의 손상이 전체 워크플로로 전파됩니다. OWASP Agentic Top 10은 이러한 현실을 반영하여 에이전트 목표 탈취(ASI01), 도구 오용(ASI02), 메모리 오염(ASI06), 연쇄 장애(ASI08), 로그 에이전트(ASI10) 등을 별도로 정의합니다.

셋째, GenAI 시스템의 공급망은 정적 구성요소(모델 가중치, 라이브러리)를 넘어 런타임에 동적으로 구성되는 요소(MCP 서버, 외부 에이전트, 도구 디스크립터)까지 포함합니다. 에이전트가 런타임에 도구를 탐색하고 연결하는 환경에서는 공급망 공격의 범위가 실시간으로 변화합니다.

아래 표는 OWASP 프레임워크의 각 항목이 본 어세스먼트의 어느 영역에 매핑되는지를 보여줍니다.

이 두 프레임워크는 상호 보완적입니다. 예를 들어, LLM01(Prompt Injection)은 에이전트 환경에서 ASI01(Agent Goal Hijack)으로 확장되고, LLM06(Excessive Agency)은 ASI02(Tool Misuse)와 ASI03(Identity and Privilege Abuse)로 구체화됩니다.

100개의 질문을 8개 영역으로 분류했습니다. 각 영역은 OWASP 프레임워크의 특정 위험 항목에 매핑됩니다.

프롬프트 인젝션은 OWASP LLM Top 10에서 1순위로 지정된 위험입니다. LLM은 본질적으로 지시와 데이터를 구분하지 못하기 때문에, 공격자가 사용자 입력을 통해 모델의 동작을 변경할 수 있습니다. 에이전트 환경에서는 이것이 ASI01(Agent Goal Hijack)으로 확장되어, 에이전트의 목표 자체가 탈취될 수 있습니다.

관련 OWASP: LLM01:2025 Prompt Injection, LLM07:2025 System Prompt Leakage, ASI01 Agent Goal Hijack

직접 프롬프트 인젝션

간접 프롬프트 인젝션

프롬프트 보안 테스트

AWS 환경에서의 실천 방안: Amazon Bedrock Guardrails의 Content Filters는 Prompt Attack 카테고리를 통해 프롬프트 인젝션 시도를 탐지하고 차단할 수 있습니다. Standard 티어에서는 코드 요소(주석, 변수명, 문자열 리터럴) 내에 숨겨진 악의적 콘텐츠까지 탐지 범위가 확장됩니다.

시스템 프롬프트가 유출되면 공격자가 애플리케이션의 내부 로직, 보안 규칙, 비즈니스 제약 조건을 파악하여 더 정교한 공격을 수행할 수 있습니다.

핵심 원칙: 보안에 중요한 제어(예: 권한 검증, 데이터 접근 제한)는 프롬프트 지시에 의존하지 말고 반드시 애플리케이션 코드 레벨에서 구현해야 합니다. 프롬프트는 우회될 수 있지만, 코드 레벨의 제어는 모델의 출력과 무관하게 동작합니다.

LLM 시스템은 학습 데이터, 파인튜닝 데이터, RAG 검색 데이터, 사용자 입력 데이터 등 다양한 데이터를 처리합니다. 각 단계에서 민감 정보가 노출되거나, 악의적 데이터가 주입될 수 있습니다.

관련 OWASP: LLM02:2025 Sensitive Information Disclosure, LLM04:2025 Data and Model Poisoning

AWS 환경에서의 실천 방안: Amazon Bedrock Guardrails의 Sensitive Information Filters를 사용하면 PII(주민등록번호, 생년월일, 주소 등)를 확률적으로 탐지하여 차단하거나 마스킹할 수 있습니다. 정규표현식 기반의 커스텀 패턴 탐지도 지원합니다.

데이터 포이즈닝은 사전 학습, 파인튜닝, 또는 임베딩 데이터를 조작하여 취약점, 백도어, 편향을 주입하는 공격입니다.

GenAI 시스템의 공급망은 모델 가중치, 라이브러리, 플러그인, LoRA 어댑터, 벡터 데이터베이스 등 다양한 구성요소를 포함합니다. OWASP는 LLM03(Supply Chain)에서 이러한 공급망 취약점을, LLM08(Vector and Embedding Weaknesses)에서 RAG 시스템의 벡터/임베딩 관련 취약점을 별도로 다룹니다. 에이전트 환경에서는 ASI04(Agentic Supply Chain Vulnerabilities)가 MCP 서버, 외부 에이전트 등 런타임에 동적으로 구성되는 공급망 위험까지 확장합니다.

관련 OWASP: LLM03:2025 Supply Chain, LLM08:2025 Vector and Embedding Weaknesses, ASI04 Agentic Supply Chain Vulnerabilities

참고: LLM10:2025 Unbounded Consumption에서도 모델 추출 공격을 다루고 있습니다. API 속도 제한, logits/logprobs 노출 제한 등의 대응 방안은 영역 8(인프라 보안)의 리소스 관리 항목과 함께 검토하시기 바랍니다.

LLM의 출력은 다운스트림 시스템에 전달되기 전에 반드시 검증되어야 합니다. 출력이 웹 페이지에 렌더링되면 XSS가, SQL 쿼리에 삽입되면 SQL Injection이, 셸 명령으로 실행되면 RCE(Remote Code Execution)가 발생할 수 있습니다. 또한 LLM은 본질적으로 사실이 아닌 내용을 생성할 수 있으며(환각/hallucination), 이는 비즈니스 의사결정에 직접적인 위험을 초래합니다.

관련 OWASP: LLM05:2025 Improper Output Handling, LLM09:2025 Misinformation, ASI05 Unexpected Code Execution

LLM09:2025 Misinformation은 LLM이 사실이 아닌 정보를 자신 있게 생성하는 문제를 다룹니다. 이는 의료, 법률, 금융 등 고위험 도메인에서 특히 심각한 결과를 초래할 수 있습니다.

AWS 환경에서의 실천 방안: Amazon Bedrock Guardrails의 Contextual Grounding Checks는 모델 응답이 소스 정보에 기반하는지(grounded), 사용자 질문과 관련이 있는지(relevant)를 검증합니다. RAG 애플리케이션에서 환각을 탐지하고 차단하는 데 활용할 수 있습니다. 또한 Automated Reasoning Checks를 통해 논리적 규칙 집합에 대한 응답의 정확성을 검증할 수 있습니다.

이 영역은 본 어세스먼트에서 가장 많은 문항(17개)을 할당한 영역입니다. 에이전트 시스템은 자율적으로 목표를 추구하고, 도구를 호출하며, 다른 에이전트와 협업하고, 세션 간 메모리를 유지합니다. 이러한 자율성은 강력한 기능을 제공하지만, 동시에 기존 LLM 애플리케이션과는 질적으로 다른 보안 위험을 만들어냅니다.

관련 OWASP: LLM06:2025 Excessive Agency, ASI01 Agent Goal Hijack, ASI02 Tool Misuse and Exploitation, ASI06 Memory and Context Poisoning, ASI08 Cascading Failures, ASI10 Rogue Agents

최소 권한 원칙

에이전트 목표 보호

ASI01(Agent Goal Hijack)은 OWASP Agentic Top 10의 1순위 위험입니다. 공격자가 외부 문서, 웹 페이지, 이메일 등에 숨겨진 지시를 삽입하면, 에이전트가 이를 처리하는 과정에서 원래 목표가 탈취될 수 있습니다. 에이전트가 도구 호출 권한을 가지고 있다면, 이는 단순한 정보 유출을 넘어 시스템 조작으로 이어질 수 있습니다.

실제 사례 참고: 2025년 AI 코딩 도구에서 30건 이상의 보안 취약점이 보고되었고 그중 24건이 CVE로 할당되었습니다(IDEsaster, 2025-12). 별도로 Cursor에서 간접 프롬프트 인젝션과 MCP 설정 파일 작성 경로가 결합되어 RCE로 이어질 수 있는 취약점(CVE-2025-54135)이 2025년 8월 NVD에 등록되었습니다. 도구의 메타데이터나 설명(tool descriptor)에 숨겨진 악의적 지시가 에이전트에 의해 신뢰된 가이드로 해석될 수 있습니다.

이 하위 영역은 ASI06(Memory and Context Poisoning)에 대응합니다. 이것은 학습 데이터 포이즈닝(LLM04)과는 다른 위협입니다. 학습 데이터 포이즈닝이 모델 가중치를 오염시키는 것이라면, 메모리 오염은 에이전트의 런타임 컨텍스트 — RAG 데이터베이스, 벡터 스토어, 대화 히스토리, 장기 메모리 — 를 시간에 걸쳐 점진적으로 오염시키는 공격입니다. 오염된 메모리는 이후 모든 의사결정에 영향을 미치며, 멀티 에이전트 시스템에서는 공유 메모리를 통해 다른 에이전트로 전파될 수 있습니다.

에이전트는 사용자나 시스템의 신원(identity)과 권한(privilege)을 빌려서 동작합니다. ASI03(Identity and Privilege Abuse)은 이 과정에서 발생하는 권한 남용, 권한 상승, 크로스 에이전트 신뢰 악용 등의 위험을 다룹니다.

관련 OWASP: ASI03 Identity and Privilege Abuse

에이전트 환경의 특수성: 에이전트의 권한 관리는 전통적인 사용자/서비스 계정 관리보다 복잡합니다. 고권한 사용자가 에이전트에 작업을 위임할 때 최소 권한 스코핑 없이 전체 접근 컨텍스트가 전달되는 경우(Un-scoped Privilege Inheritance), 에이전트가 자격증명을 메모리에 캐시하여 세션 간에 재사용하는 경우(Memory-Based Privilege Retention), 멀티 에이전트 시스템에서 저권한 에이전트가 고권한 에이전트에게 정상적으로 보이는 요청을 전달하는 경우(Confused Deputy) 등이 대표적인 공격 시나리오입니다.

AWS 환경에서의 실천 방안: IAM Policy Autopilot은 애플리케이션 코드를 분석하여 필요한 최소 권한의 IAM 정책을 자동 생성하는 오픈소스 도구입니다. MCP 서버로도 동작하여 AI 코딩 어시스턴트와 통합할 수 있습니다. 에이전트가 AWS 리소스에 접근할 때는 장기 자격증명 대신 AWS STS를 통한 임시 자격증명을 사용하고, IAM 역할의 권한을 에이전트의 실제 필요에 맞게 최소화해야 합니다.

GenAI 시스템의 모니터링은 전통적인 애플리케이션 모니터링을 넘어, 에이전트의 의사결정 과정, 도구 호출 패턴, 메모리 변화 등을 추적해야 합니다. 또한 ASI09(Human Agent Trust Exploitation)는 사용자가 에이전트의 출력을 과도하게 신뢰하는 문제를 다루며, 이는 기술적 제어뿐 아니라 UX 설계 차원의 대응이 필요합니다.

관련 OWASP: ASI09 Human Agent Trust Exploitation

ASI09는 사용자가 에이전트의 추천이나 설명을 과도하게 신뢰하여, 에이전트를 통한 사회공학 공격이나 은밀한 유해 행위가 가능해지는 위험을 다룹니다. 에이전트가 생성한 송장의 결제 정보를 검증 없이 승인하거나, 에이전트가 추천한 링크를 무비판적으로 클릭하는 것이 대표적인 시나리오입니다.

멀티 에이전트 시스템에서 에이전트 간 통신 채널이 보호되지 않으면, 스푸핑, 리플레이 공격, 메시지 변조 등이 가능합니다(ASI07). 또한 LLM의 높은 연산 비용은 리소스 고갈 공격과 비용 폭증(Denial of Wallet)의 대상이 됩니다(LLM10).

관련 OWASP: ASI07 Insecure Inter-Agent Communication, LLM10:2025 Unbounded Consumption

LLM10:2025 Unbounded Consumption은 LLM 추론의 높은 연산 비용을 악용하는 다양한 공격을 포함합니다. 가변 길이 입력 플러딩, Denial of Wallet(클라우드 비용 폭증), 컨텍스트 윈도우 오버플로, 리소스 집약적 쿼리, 그리고 API를 통한 모델 추출까지 광범위한 위협이 해당됩니다.

AWS 환경에서의 실천 방안: Amazon Bedrock의 경우 서비스 할당량(Service Quotas)을 통해 모델별 RPM(분당 요청 수)·TPM(분당 토큰 수)·TPD(일당 토큰 수) 한도를 제한할 수 있습니다. AWS Budgets와 AWS Cost Anomaly Detection을 활용하여 비용 이상을 조기에 탐지하고, Amazon CloudWatch 경보를 통해 리소스 사용량 임계값 초과 시 자동 알림을 설정할 수 있습니다.

---

각 질문에 대해 다음과 같이 평가합니다.

N/A 항목이 많을 경우 절대 점수 기반 평가는 왜곡될 수 있습니다. 따라서 백분율 기반으로 위험도를 산정합니다.

점수율 = (획득 점수 / 적용 가능 최대 점수) × 100%

예를 들어, 100문항 중 10문항이 N/A이고 나머지 90문항에서 150점을 획득했다면, 점수율은 150 / 180 = 83.3% (양호)입니다.

평가 결과에 따라 다음 우선순위로 개선을 권장합니다.

AWS 서비스를 활용한 보안 구현 방안을 앞서 각 영역별로 소개했습니다. 여기서는 실제 구현 시 반드시 알아야 할 제한사항을 정리합니다. “가드레일을 적용했으니 안전하다”는 가정은 위험합니다.

Amazon Bedrock Guardrails는 공식 문서에서 “reasoning content blocks를 제외(excluding reasoning content blocks)”한다고 명시하고 있습니다. 즉, 모델이 reasoning 블록을 사용하는 경우 해당 블록의 내용은 가드레일 평가 대상에서 빠집니다. 모델/SDK 구성에 따라 “필터가 적용된다고 가정했지만 실제로는 일부 블록이 빠지는” 상황이 발생할 수 있으므로, 어떤 콘텐츠가 평가 대상인지 반드시 확인해야 합니다.

InvokeModel 또는 InvokeModelResponseStream API를 사용할 때, 공식 문서는 “태그가 없으면 해당 사용 사례에서 프롬프트 공격이 필터링되지 않는다(If there are no tags, prompt attacks for those use cases will not be filtered)”고 명시합니다. 즉, input tag를 사용하여 사용자 입력 영역을 명시적으로 지정하지 않으면 프롬프트 공격 필터가 동작하지 않습니다. Standard 티어에서 Prompt Leakage 탐지가 추가되지만, 이 역시 태그 설정이 전제입니다.

Bedrock Guardrails의 언어 지원은 기능별로 다릅니다.

Content Filters 및 Prompt Attack 필터는 Standard 티어에서 한국어를 포함한 70개 이상의 언어를 지원하며, 한국어는 “Optimized and supported” 등급입니다. Sensitive Information Filters(PII 탐지)도 한국어가 “Optimized and supported”입니다.

반면, Contextual Grounding Checks는 현재 영어, 프랑스어, 스페인어 3개 언어만 지원합니다. 한국어 RAG 애플리케이션에서 환각 탐지를 위해 Contextual Grounding을 사용하려면 이 제한을 반드시 인지해야 합니다.

Automated Reasoning Checks는 영어(US)만 지원합니다. 또한 스트리밍 API를 지원하지 않으며, GA 리전이 미국 3개(N. Virginia, Oregon, Ohio)와 유럽 3개(Frankfurt, Paris, Ireland)로 제한됩니다. 서울 리전(ap-northeast-2)에서는 현재 사용할 수 없습니다.

공식 문서는 “Conversational QA / Chatbot use cases are not supported”라고 명시합니다. 지원되는 사용 사례는 요약(summarization), 패러프레이징(paraphrasing), 질의응답(question answering)입니다. 또한 스트리밍 API 사용 시 전체 응답이 완료된 후에야 irrelevant 판정이 내려질 수 있어, 사용자에게 부적절한 응답이 먼저 노출될 수 있습니다. grounding source는 최대 100,000자, query는 최대 1,000자, response는 최대 5,000자로 제한됩니다.

공식 문서는 “Automated Reasoning checks will not protect against prompt injection attacks. These checks validate exactly what you send them — if malicious or manipulated content is provided as input, the validation will be performed on that content as-is (garbage-in, garbage-out)”라고 명시합니다. 따라서 Automated Reasoning은 반드시 Content Filters(Prompt Attack 탐지)와 조합하여 사용해야 합니다.

백분율 점수는 전체 성숙도를 비교하는 데 유용하지만, GenAI 보안에는 “하나라도 N이면 사실상 프로덕션 배포가 어려운” 항목이 존재합니다. 예를 들어, 전체 점수가 75%(양호)이더라도 프롬프트 인젝션 방어가 전혀 없다면 그 시스템은 안전하다고 볼 수 없습니다.

따라서 점수와 별개로, 아래 영역은 “게이트(필수)”로 지정하여 하나라도 N이면 프로덕션 배포 전 반드시 해결하도록 권장합니다.

조직마다 증적 수준은 다르지만, 최소한 아래 수준의 근거가 있어야 “예(Y)”로 판정하는 것이 안전합니다.

정책/설계 측면에서는 위협 모델, 데이터 분류 기준, RAG/에이전트 아키텍처 다이어그램, 권한 모델, 인시던트 대응 플로우가 필요합니다. 구현/설정 측면에서는 IaC(Terraform/CloudFormation) 또는 구성 스냅샷(WAF 룰, IAM 정책, 네트워크 세그멘테이션), 가드레일/필터 정책 버전, KMS 키 정책이 필요합니다. 검증 결과로는 레드팀/보안 테스트 리포트, CI 테스트 로그(프롬프트 인젝션, 출력 처리, 도구 호출 스키마), 샌드박스 실행 결과가 필요합니다. 운영 증거로는 감사 로그 샘플(마스킹 적용 확인), 알림/대응 티켓, 비용 알림 설정, 쿼터/레이트리밋 적용 내역이 필요합니다.

N/A는 점수 왜곡을 줄이는 데 도움이 되지만, 남용하면 위험이 가려집니다. 기능 미사용으로 구조적으로 불가능한 경우에만 N/A를 허용해야 합니다(예: 에이전트 기능 자체가 없으면 질문 52~68 일부 N/A 가능). “아직 안 만들었음” 또는 “추후 계획”은 N/A가 아니라 N(0점)으로 기록해야 합니다. N/A를 적용한 항목은 사유와 재평가 시점을 함께 기록하는 것을 권장합니다.

GenAI 애플리케이션의 보안은 단일 제어로 해결되는 문제가 아닙니다. 프롬프트 레벨의 방어, 데이터 파이프라인의 무결성, 모델 공급망의 신뢰성, 출력의 검증, 에이전트의 권한 제어, 인프라의 견고함 — 이 모든 계층이 함께 동작해야 합니다.

동시에, 체크리스트는 만드는 것보다 운영하는 것이 더 중요합니다. 게이팅을 통해 배포 전 필수 기준을 강제하고, 증적을 통해 “예(Y)” 판정의 근거를 확보하며, 2주 스프린트 같은 운영 주기를 통해 평가와 개선이 반복되어야 합니다.

이 100개의 질문이 여러분의 GenAI 시스템에서 보안 갭을 식별하고, 체계적으로 개선해 나가는 출발점이 되기를 바랍니다. 모든 질문에 “예”라고 답할 필요는 없습니다. 중요한 것은 현재 상태를 정확히 파악하고, 비즈니스 맥락에 맞는 우선순위로 개선해 나가는 것입니다.

---