OWASP Top 10 for LLM을 보다가 자연스럽게 생기는 의문이 있습니다. 왜 Prompt Injection은 1위이고, System Prompt Leakage는 7위일까요? 누가 어떤 통계와 계산식으로 정확히 열 개를 골랐을까요?
결론부터 말하면, 2025 목록은 한 회사가 비공개 사고 통계를 정렬하거나 하나의 점수 공식으로 자동 산출한 순위가 아닙니다. OWASP GenAI Security Project가 기존 항목 검토, 공개 후보 제안, 커뮤니티 투표, 항목 통합과 압축, 데이터 분석, 순위 투표, 항목 책임자의 문서 정리를 거쳐 만든 커뮤니티 합의형 위험 목록입니다.
다만 중요한 한계도 있습니다. 공식 자료에는 단계와 일정, 참여 방법, 후보와 투표 결과가 남아 있지만, 최종 1위부터 10위까지를 누구나 똑같이 재현할 수 있는 단일 가중치 공식은 공개되어 있지 않습니다. 따라서 이 목록은 정밀한 발생 확률표라기보다, 당시 커뮤니티가 LLM 애플리케이션에서 우선 살펴야 한다고 합의한 보안 인식·우선순위 가이드로 읽는 것이 정확합니다.

먼저 확인할 것: 현재 목록은 2025 버전이다
OWASP의 예전 프로젝트 페이지에는 2023~2024 버전 목록이 함께 남아 있어 검색 결과만 보면 버전을 혼동하기 쉽습니다. 현재 공식 GenAI Security Project가 안내하는 2025 Top 10 for LLMs and Gen AI Apps의 순서는 다음과 같습니다.
| 순위 | 2025 항목 | 핵심 의미 |
| LLM01 | Prompt Injection | 입력이나 외부 콘텐츠가 모델의 의도된 지시를 바꾸는 위험 |
| LLM02 | Sensitive Information Disclosure | 모델과 애플리케이션을 통한 민감정보 노출 |
| LLM03 | Supply Chain | 모델·데이터·플러그인·의존성 공급망의 취약점 |
| LLM04 | Data and Model Poisoning | 학습·미세조정·임베딩 데이터 또는 모델의 오염 |
| LLM05 | Improper Output Handling | 모델 출력을 검증·정제하지 않고 후속 시스템이 처리하는 위험 |
| LLM06 | Excessive Agency | 모델과 에이전트에 과도한 기능·권한·자율성을 부여하는 위험 |
| LLM07 | System Prompt Leakage | 시스템 프롬프트가 노출되거나 그 내용에 보안을 의존하는 문제 |
| LLM08 | Vector and Embedding Weaknesses | RAG와 벡터·임베딩 처리 계층의 권한·무결성 취약점 |
| LLM09 | Misinformation | 잘못되거나 오해를 부르는 출력을 신뢰해 발생하는 위험 |
| LLM10 | Unbounded Consumption | 제한 없는 추론 자원·토큰·API 사용으로 인한 비용과 가용성 위험 |
공식 2025 PDF의 프로젝트 리더 서문은 이번 개정이 브레인스토밍 세션, 투표, 현장 전문가의 실제 피드백을 결합했으며 이전보다 더 크고 다양한 글로벌 기여자 집단이 참여했다고 설명합니다. 즉 ‘Top’은 단순 사고 건수의 내림차순이 아니라 현장 경험, 새로 부상한 위협, 데이터와 전문가 판단을 합친 우선순위입니다.
실제 선정 과정은 일곱 단계로 볼 수 있다
2024년 4월 공개된 v2 업데이트와 GitHub Wiki의 로드맵을 합치면 2025 목록이 만들어진 과정을 다음과 같이 복원할 수 있습니다.

그림: OWASP LLM Top 10 2025 선정 절차 · v2 업데이트와 V2 Core List Roadmap을 바탕으로 재구성
1. 기존 열 개 항목을 먼저 재평가했다
첫 단계는 기존 2023~2024 목록을 그대로 유지하는 것이 아니라, 각 항목이 계속 중요한지 커뮤니티가 투표하는 과정이었습니다. 2024년 4월 15일부터 30일까지 기존 항목에 대한 투표를 받고, 5월 초에 결과를 취합·공개하는 일정이 제시됐습니다.
이 단계가 필요한 이유는 LLM 생태계의 변화 속도가 빠르기 때문입니다. 1년 사이에도 단순 챗봇에서 RAG, Tool Calling과 자율 에이전트로 중심이 이동하면 위협의 범위와 이름도 달라집니다.
2. 신규 위험 후보를 공개적으로 받았다
다음으로 5월 중순부터 6월 중순까지 새로운 항목을 제안받았습니다. Wiki의 신규 항목 제출 안내는 후보 디렉터리와 템플릿을 이용해 제안하도록 했고, Slack의 Top 10 채널에서도 브레인스토밍을 진행했습니다.
이 단계는 정해진 보기 중 하나를 고르는 폐쇄형 설문이 아니라, 기존 목록에 없던 위험을 자유롭게 제안하는 생성 단계였습니다. 당시 후보 논의에는 RAG 위험, Backdoor Attack, System Prompt Leakage, Insecure Design 같은 주제가 등장했고 일부는 최종 목록에서 독립 항목이 되거나 다른 항목에 통합됐습니다.
3. 신규 후보를 투표로 걸러냈다
제안된 모든 아이디어가 곧바로 Top 10이 되는 것은 아닙니다. 로드맵은 6월 16일부터 30일까지 신규 후보 투표, 7월 초 결과 취합·공개를 계획했습니다. 2024년 7월 프로젝트 뉴스레터도 후보와 투표 단계가 완료됐으며 Raw Candidate, Raw Results와 Collated Results가 공개됐다고 안내했습니다.
이 과정에서 커뮤니티의 관심이 어디로 이동했는지도 드러났습니다. 뉴스레터는 Prompt Injection이 계속 높은 우선순위를 유지했고, Agent, RAG, System Prompt Exploit 관련 관심이 커졌다고 요약했습니다.
4. 겹치는 항목을 합치고 열 개 후보로 압축했다
위험 이름은 달라도 원인과 대응이 겹칠 수 있습니다. 예를 들어 Model Denial of Service는 비용 폭증, 자원 고갈과 서비스 장애를 모두 포함하는 Unbounded Consumption으로 확장할 수 있습니다. Training Data Poisoning 역시 학습 데이터뿐 아니라 미세조정·임베딩과 모델 자체의 변조까지 포함하도록 Data and Model Poisoning으로 넓어졌습니다.
로드맵에는 7월 15일부터 8월 1일까지 기존 항목과 신규 항목을 합치고 Down-select하는 단계가 명시되어 있습니다. 이 작업은 단순 득표순으로 열 개를 자르는 것보다 중요합니다. 서로 중복되는 후보를 한 범주로 묶고, 원인·공격 경로·대응책이 독립된 항목으로 설명될 수 있는지 판단해야 하기 때문입니다.
5. 데이터 분석과 최종 순위 투표를 수행했다
8월에는 데이터 분석과 Ranking Vote가 예정됐습니다. OWASP 자료가 말하는 데이터에는 업계 보고서, 연구 논문, 공개 취약점과 실제 공격 사례, 커뮤니티와 파트너가 제공한 현장 정보가 포함됩니다. 후보의 영향, 악용 가능성, 확산 정도를 검토하고 전문가 피드백으로 보완하는 방향입니다.
하지만 여기서 조심해야 합니다. 현재 공개 자료만으로는 다음과 같은 산식을 확인할 수 없습니다.
최종 점수 = 발생 빈도 40% + 영향도 30% + 악용 가능성 30%
이런 고정 가중치와 컷오프가 2025 LLM Top 10에 적용됐다고 OWASP가 공식 명시한 자료는 찾기 어렵습니다. 공식 표현은 Data Analysis와 Ranking Vote이며, PDF 서문은 Brainstorming, Voting, Real-world Feedback을 강조합니다. 따라서 ‘데이터도 검토했다’와 ‘공개된 단일 산식으로 순위가 재현된다’는 서로 다른 주장입니다.
6. 항목 책임자가 설명과 대응책을 정리했다
순위가 정해진 뒤에는 9월 Entry Cleanup 단계가 이어졌습니다. 각 항목의 정의, 흔한 취약 사례, 예방·완화 전략과 참고 자료를 정리하고 중복 표현을 조정하는 과정입니다. GitHub Issue는 항목별 라벨을 사용하고, 중복 여부를 확인한 뒤 CODEOWNERS에 등록된 항목 책임자에게 배정하는 방식으로 수정 제안을 추적합니다.
Top 10은 항목명 열 개만 발표하는 투표 결과가 아닙니다. 실무자가 위험을 식별하고 통제를 설계할 수 있도록 각 항목의 경계와 사례를 문서화하는 편집·동료 검토 과정이 포함됩니다.
7. 레이아웃과 사전 안내를 거쳐 발행했다
로드맵은 9월 문서 정리와 레이아웃, 사전 안내를 거쳐 10월 발행을 목표로 했습니다. 실제 2025 PDF에는 2024년 11월 18일 릴리스 날짜가 표시되어 있습니다. 계획과 실제 발행일은 달라질 수 있으므로, 일정표는 ‘선정 절차의 설계’를 이해하는 근거로 보고 최종 버전과 날짜는 PDF에서 확인해야 합니다.
어디서 확인할 수 있나
선정 과정을 확인할 때는 요약 블로그보다 OWASP가 남긴 서로 다른 종류의 기록을 함께 봐야 합니다.

그림: OWASP LLM Top 10 선정 근거를 확인하는 경로 · OWASP 공식 PDF, 프로젝트 사이트와 GitHub 기록을 바탕으로 재구성
| 확인하려는 것 | 가장 직접적인 공식 자료 | 여기서 확인되는 내용 |
| 최종 2025 목록과 개정 취지 | OWASP Top 10 for LLMs 2025 PDF | 최종 순위, 항목 정의, 리더 서문, 참여자, 릴리스 날짜 |
| 전체 선정 단계와 예정 일정 | V2 업데이트 | 기존 항목 투표부터 신규 공모, 통합, 분석·순위 투표, 발행까지 |
| 담당 주체가 표시된 작업표 | V2 Core List Roadmap | 단계별 기간과 커뮤니티·Core Team·Entry Lead의 역할 |
| 신규 항목 제안 방식 | V2 New Entry Submissions | 공개 후보 제출, 템플릿, 브레인스토밍과 후보 흔적 |
| 후보·투표 결과가 공개됐다는 당시 기록 | 2024년 7월 프로젝트 뉴스레터 | 후보·투표 단계 완료와 Raw·Collated Results 안내 |
| 최종 문서가 어떻게 수정되는가 | GitHub Issues와 Feedback Wiki | 항목별 오류·개선 제안, 라벨, 중복 확인과 책임자 검토 |
| 누가 참여하고 어떻게 의견을 내는가 | Contribute와 Project Governance | Slack, 회의, Working Group, 합의와 투표의 일반 원칙 |
가장 실용적인 확인 순서는 최종 PDF → v2 업데이트 → GitHub Wiki 로드맵 → 당시 뉴스레터 → Issue와 Commit History입니다. PDF만 보면 최종 결과는 알 수 있지만 선정 과정은 짧게 요약돼 있고, Wiki만 보면 계획은 보이지만 실제 발행본과 차이가 있을 수 있습니다.
공개되어 있는 것과 공개되지 않은 것을 구분해야 한다
공개된 것
- 기존 항목 투표, 신규 항목 공모와 투표, 통합·압축, 데이터 분석과 순위 투표라는 큰 단계
- 각 단계의 예정 기간과 Core Team, Data Gathering Team, Entry Lead, 전체 커뮤니티의 역할
- 신규 후보의 일부 흔적과 최종 항목의 변경 내용
- 최종 PDF의 기여자와 항목별 설명
- 발행 뒤 오류·개선 제안을 추적하는 GitHub Issue, Pull Request와 Commit History
현재 자료만으로 명확히 재현하기 어려운 것
- 후보별 최종 점수를 계산한 하나의 공식 수식과 고정 가중치
- 각 투표의 전체 유권자 모집단, 응답자 구성과 표본 편향을 평가할 상세 통계
- Down-select 과정에서 후보를 합치거나 제외한 모든 회의의 완전한 의사결정 로그
- 2024년 뉴스레터가 가리킨 Raw·Collated Results의 장기 보존 상태
GitHub Wiki에는 Data Gathering Methodology 문서도 존재하지만 편집 이력이 계속 바뀌고 일부 페이지 내용이 불완전합니다. 또한 그 문서의 일반적인 데이터 수집 설명을 2025 순위에 적용된 확정 산식으로 곧바로 간주해서는 안 됩니다. 2025 선정의 가장 확실한 근거는 당시의 v2 로드맵, 업데이트 글, 뉴스레터와 최종 PDF를 서로 교차 확인하는 것입니다.
이 구분은 OWASP를 불신하자는 이야기가 아닙니다. 공개 프로젝트의 신뢰성을 평가할 때 프로세스가 공개됐는지와 결과를 원자료로 완전히 재현할 수 있는지는 서로 다른 투명성 수준이라는 뜻입니다.
일반 OWASP Web Top 10과 같은 방식인가
같지 않습니다. OWASP라는 이름이 같아도 프로젝트와 데이터 환경이 다릅니다.
| 비교 항목 | OWASP Web Top 10:2021 | OWASP Top 10 for LLM:2025 |
| 주된 입력 | 조직이 제공한 대규모 애플리케이션 취약점 데이터, CWE·CVE·CVSS, 커뮤니티 설문 | 기존 항목 검토, 신규 후보 제안, 커뮤니티 투표, 업계·연구·실제 사례 데이터와 현장 피드백 |
| 열 개 선택 방식 | 8개는 기여 데이터, 2개는 커뮤니티 설문에서 선택한다고 명시 | 후보 투표, 통합·Down-select, 데이터 분석과 Ranking Vote를 결합 |
| 공개 산식 수준 | Incidence Rate, Coverage, Exploit와 Impact 등 데이터 요소와 계산 절차를 비교적 상세히 공개 | 큰 절차는 공개됐지만 최종 순위를 재현하는 단일 수식·가중치표는 명확하지 않음 |
| 데이터 성숙도 | 수년간 축적된 웹 취약점 분류와 50만 개 이상 애플리케이션 기여 데이터 | 빠르게 변하는 LLM·RAG·Agent 환경, 표준화된 사고·취약점 데이터가 아직 제한적 |
| 올바른 해석 | 데이터와 설문을 결합한 웹 애플리케이션 위험 인식 목록 | 당시 전문가 커뮤니티의 합의와 현장 신호를 반영한 LLM 애플리케이션 우선 점검 목록 |
Web Top 10:2021 공식 방법론은 8개 범주를 기여 데이터에서, 2개를 커뮤니티 설문에서 골랐다고 분명히 설명합니다. 또한 발생 빈도 대신 한 애플리케이션에 해당 CWE가 한 번 이상 발견된 비율인 Incidence Rate를 사용합니다.
반면 LLM 분야는 공통 CWE나 사고 데이터가 웹 취약점만큼 오래 축적되지 않았고, 프롬프트·모델·RAG·도구·권한이 결합된 시스템 위험이 빠르게 변합니다. 그래서 공개 후보와 전문가 판단, 현장 피드백의 비중이 더 큽니다. Web Top 10의 수치를 LLM 목록에도 그대로 적용했다고 설명하면 잘못입니다.
그렇다면 ‘1위’는 발생 건수가 가장 많다는 뜻인가
아닙니다. Prompt Injection이 LLM01이라는 사실만으로 전 세계 침해 사고의 정확히 몇 퍼센트를 차지한다고 말할 수 없습니다. 공개된 모집단과 사고 건수만을 이용해 계산한 보험 통계 같은 순위가 아니기 때문입니다.
LLM01은 다음을 종합한 우선순위로 이해해야 합니다.
- 다양한 LLM 애플리케이션 구조에서 반복적으로 나타나는가
- 영향 범위가 데이터 유출, 권한 오용과 후속 시스템 침해로 이어질 수 있는가
- 실무자가 현재 중요하게 관찰하는가
- 다른 위험의 공격 경로 또는 촉발점이 되는가
- 독립된 범주로 설명하고 대응 지침을 제공할 가치가 있는가
따라서 LLM07이 LLM03보다 덜 중요하다거나, LLM10만 해결하면 앞의 아홉 개보다 안전하다는 식으로 읽어서는 안 됩니다. 번호는 점검 순서를 잡는 데 도움을 주지만 실제 위험도는 조직의 데이터, 기능, 권한과 배포 구조에 따라 달라집니다.
기업에서는 어떻게 활용해야 하나
Top 10을 그대로 규정 준수 체크리스트로 복사하기보다 위협 모델링의 출발점으로 사용해야 합니다.
1. 시스템 구성요소에 위험을 매핑한다
사용자 입력 → Prompt Injection
모델·데이터 공급망 → Supply Chain, Data and Model Poisoning
RAG 검색 → Vector and Embedding Weaknesses
출력 후속 처리 → Improper Output Handling
도구 호출과 권한 → Excessive Agency
로그·응답·학습 데이터 → Sensitive Information Disclosure
토큰·GPU·API 비용 → Unbounded Consumption
2. 조직의 영향과 노출도를 다시 평가한다
사내 지식 검색 챗봇과 결제·계정 변경이 가능한 에이전트의 우선순위는 다릅니다. 각 항목에 대해 데이터 민감도, 외부 입력 노출, 모델이 가진 권한, 자동 실행 범위, 탐지 가능성과 피해 복구 비용을 평가해야 합니다.
3. Top 10 밖의 위험도 유지한다
열 개는 경계이지 전체 우주가 아닙니다. 모델 탈취, 개인정보 규제, 편향, 저작권, 가용성, 모델 업데이트와 공급자 종속처럼 조직에 중요한 위험이 현재 목록의 독립 항목이 아닐 수 있습니다. OWASP AI Security and Privacy Guide, MITRE ATLAS, NIST AI RMF와 내부 위협 모델을 함께 사용해야 합니다.
4. 버전과 출처를 문서에 기록한다
정책이나 점검표에는 ‘OWASP LLM Top 10’이라고만 쓰지 말고 OWASP Top 10 for LLM Applications 2025처럼 버전을 명시해야 합니다. 이전 버전에서는 Insecure Plugin Design, Model Theft와 Overreliance가 독립 항목이었지만 2025에는 이름과 범위가 재편됐습니다.
한계까지 이해해야 제대로 쓸 수 있다
커뮤니티 합의 방식은 새 위험을 빠르게 반영하고 한 회사의 제품 이해관계에 종속되지 않는 장점이 있습니다. 반대로 참여자 구성과 투표 시점에 따라 우선순위가 달라질 수 있고, 공개 사고가 적은 영역은 전문가 판단의 비중이 커집니다. 후보의 이름과 범위를 어떻게 합치는지도 순위에 영향을 줍니다.
그러므로 다음 두 문장은 모두 피하는 것이 좋습니다.
“OWASP가 통계적으로 증명했으니 이 열 개가 전 세계 LLM 사고의 정확한 순서다.”
“투표로 만들었으니 근거 없는 인기 순위일 뿐이다.”
실제 과정은 그 중간에 있습니다. 공개 후보 제안과 커뮤니티 투표가 있었고, 데이터와 실제 현장 피드백을 검토했으며, 책임자와 기여자들이 항목을 정리했습니다. 동시에 최종 순위를 완전히 재현할 수 있는 상세 계량 모델은 공개 자료에서 확인하기 어렵습니다.
마무리
OWASP Top 10 for LLM 2025는 기존 목록 검토 → 신규 후보 공모 → 후보 투표 → 항목 통합과 압축 → 데이터 분석과 순위 투표 → 전문가 문서 정리 → 공개 검토를 거쳐 만들어졌습니다. 누가 임의로 정한 비공개 목록도 아니고, 단일 사고 통계만 정렬한 순위도 아닙니다.
어디서 확인하느냐는 질문에는 다음 네 가지가 핵심 답입니다.
- 최종 목록과 개정 취지는 2025 PDF에서 확인한다.
- 선정 단계와 일정은 v2 업데이트와 GitHub Wiki 로드맵에서 확인한다.
- 후보와 당시 투표 흔적은 신규 제출 Wiki와 2024년 7월 뉴스레터에서 확인한다.
- 발행 이후 변경과 논의는 GitHub Issues, Pull Requests와 Commit History에서 확인한다.
그리고 가장 중요한 해석은 이것입니다.
OWASP Top 10 for LLM은 발생 건수만으로 확정된 절대 순위가 아니라, 빠르게 변하는 LLM 보안 환경에서 커뮤니티의 투표·데이터·현장 경험을 결합해 만든 우선 점검 목록이다.
이 목록을 보안의 끝으로 사용하지 말고, 우리 시스템의 데이터와 권한, RAG와 Agent 구조에 맞는 위협 모델링을 시작하는 공통 언어로 사용하는 것이 가장 올바른 활용법입니다.
참고 자료
- OWASP Top 10 for LLMs and Gen AI Apps 2025
- OWASP Top 10 for LLMs 2025 PDF
- Updates on the OWASP Top 10 for LLM Applications Project v2
- V2 Core List Roadmap
- V2 New Entry Submissions
- OWASP Top 10 for LLM Applications Newsletter — July 2024
- OWASP LLM Top 10 Feedback Wiki
- OWASP GenAI Security Project Governance
- OWASP Top 10:2021 Methodology
'일반IT > IT보안' 카테고리의 다른 글
| OWASP LLM Top 10 2025 한눈에 보기 — 위험이 생기는 10개 경계와 대응 원칙 (0) | 2026.08.04 |
|---|---|
| 패스키는 비밀번호를 어떻게 없앨까 — WebAuthn과 FIDO2의 동작 원리 (1) | 2026.07.31 |
| LLM에서 개인정보를 어떻게 필터링할까 — 입력부터 RAG·출력·로그까지 4단계 설계 (0) | 2026.07.30 |
| 생성형 AI·LLM을 위한 안전한 망 분리 설계 — AWS 계정부터 VPC, DLP, N2SF까지 (0) | 2026.07.30 |
| OpenAI 에이전트는 어떻게 허깅페이스를 침해했나 — 2026년 7월 AI 보안 사고 정리 (0) | 2026.07.29 |