서론

RAG(Retrieval-Augmented Generation／검색 증강 생성)는 LLM의 할루시네이션(Hallucination) 대책으로서 널리 사용되게 되었습니다. 사내 문서나 FAQ를 지식 베이스로 갖추고, LLM이 그곳에서 정보를 끌어와 답변하는——많은 AI 애플리케이션이 이 메커니즘을 채택하고 있습니다.

그런데, 이런 생각을 해본 적 없으신가요?

"그 지식 베이스에 몰래 거짓 정보를 심어두면 어떻게 될까?"

이것이 바로 RAG 포이즈닝(RAG Poisoning) 입니다. AI가 참조하는 "신뢰할 수 있는 정보원" 그 자체를 오염시키는 공격으로, 지난번 MCP 기사와 마찬가지로 "신뢰할 수 없는 입력을 어떻게 다룰 것인가"라는 근본적인 문제와 연결되어 있습니다.

이 기사에서는 RAG 포이즈닝의 메커니즘과 공격 수법, 왜 탐지가 어려운지, 그리고 대책에 대한 사고방식을 초보자용으로 정리합니다.

LLM의 취약성 기본 정보는 이쪽👇

RAG란? (가볍게 복습)

RAG(Retrieval-Augmented Generation／검색 증강 생성) 는 LLM이 답변을 생성하기 전에, 외부의 지식 베이스로부터 관련 정보를 검색하여 가져오는 메커니즘입니다.

LLM은 학습한 시점의 지식만을 가지고 있습니다. RAG를 사용하면 사내 문서나 최신 정보 등, 학습에 포함되지 않은 정보도 답변에 반영할 수 있습니다. 할루시네이션(그럴듯한 거짓말)을 줄이는 수단으로서도 중용되고 있습니다.

포인트는 문서를 임베딩(embedding)이라는 수치 벡터로 변환하여 벡터 DB에 저장하고, 질문과 의미적으로 가까운 문서를 검색한다는 점입니다. 이 "지식 베이스"가 RAG 포이즈닝의 표적이 됩니다.

참고: RAG란? | AWS

RAG 포이즈닝이란

RAG 포이즈닝은 RAG의 지식 베이스(벡터 DB)에 악의적인 정보(=독, poisoned을 어떻게 번역할지 고민되는 부분이네요. 웃음)를 주입하여, LLM의 답변을 공격자의 의도대로 조작하는 공격입니다.

왜 이 공격이 성립하는가. 많은 RAG 시스템이 외부의 편집 가능한 소스(Wikipedia, Reddit, GitHub의 README 등)로부터 자동으로 데이터를 가져오고 있기 때문입니다. 공격자는 이러한 소스에 악의적인 정보를 심어두는 것만으로 지식 베이스를 오염시킬 수 있습니다.

통상적인 프롬프트 인젝션(Prompt Injection)이 "사용자의 입력"을 통해 LLM을 속이는 것에 반해, RAG 포이즈닝은 "LLM이 신뢰하고 있는 지식 베이스" 그 자체를 오염시킨다는 점이 특징입니다. 사용자는 정상적인 질문을 하고 있음에도 돌아오는 답이 조작되어 있다는, 탐지하기 어려운 구도가 됩니다.

대표적인 공격 수법

RAG 포이즈닝은 활발하게 검증되고 있으며, 다양한 수법이 보고되고 있습니다.

PoisonedRAG

지식 베이스에 대한 오염 텍스트 주입을 최적화 문제로 정식화한 대표적인 수법입니다. 공격자가 노린 쿼리에 대해 LLM이 공격자가 선택한 답변을 생성하도록 오염된 텍스트를 설계합니다.

CorruptRAG

2026년 1월에 보고된, 보다 실용적인 수법입니다. 기존의 공격이 "여러 개의 오염된 문서를 주입할 수 있다"라는 비현실적인 전제에 서 있었던 것에 반해, CorruptRAG는 단 하나의 문서만을 주입해도 성립합니다. 액세스 제한, 감사 로그, 모니터링과 같은 현실적인 제약이 있는 환경에서도 단일 문서로 더 높은 성공률을 달성할 수 있다고 여겨지며, 공격의 실현 가능성과 스텔스성(Stealthiness)을 크게 높였습니다.

Wikipedia Edit 익스플로잇

지식 베이스가 외부 소스를 정기적으로 스크레이핑(Scraping)하는 성질을 악용하는 수법입니다.

• 공격자가 Wikipedia 기사나 GitHub의 README를 일시적으로 오염된 내용으로 편집한다
• RAG 시스템의 정기 스크레이퍼가 업데이트 시 해당 내용을 가져온다
• 커뮤니티 모더레이터가 편집을 되돌려도, 오염된 버전은 기업의 벡터 DB 내에 계속 남는다
• 다음 완전한 재인덱싱(Re-indexing) 시점까지(수 주~수개월 뒤의 일일 수도 있음), 잘못된 정보가 계속 제공된다

"원문 소스는 수정되었는데, AI만 계속 옛날 거짓말을 하는" 까다로운 상태가 발생합니다.

임베딩 레벨의 인젝션

문서의 겉모습이 아니라, 임베딩 벡터의 공간을 노리는 고도의 수법도 연구되고 있습니다. 벡터 DB에는 수백만 개의 임베딩이 저장되어 있으며, 그중 아주 일부에 장치된 오염 벡터를 섞어 넣음으로써 검색 결과를 조작합니다.

왜 탐지가 어려운가

RAG 포이즈닝이 까다로운 이유는 탐지가 극히 어렵다는 점입니다.

하나는 비율의 문제입니다. 벡터 DB(Vector DB)에는 수백만 개의 임베딩 (Embedding)이 저장되어 있는 경우도 있어, 주입된 악의적인 정보는 극히 적은 비율에 불과합니다. 방대한 정상 데이터 중에서 아주 소수의 "독"을 찾아내는 것은 어렵습니다.

또 다른 하나는 지속성의 문제입니다. 원본 소스 (Wikipedia 등)가 수정되더라도, 이미 포함된 오염된 데이터는 벡터 DB 내에 계속 남아 있습니다. 재인덱싱 (Re-indexing)이 수행될 때까지 오염은 해소되지 않습니다.

나아가, 사용자 입장에서는 공격의 흔적이 보이기 어렵다는 점도 꼽을 수 있습니다. 사용자는 정상적인 질문을 하고 그럴듯한 답변을 받을 뿐입니다. 그 답변이 조작된 것이라고 눈치챌 계기가 없습니다.

대책의 방향성

RAG 포이즈닝에 대한 대책은 "지식 베이스에 들어오는 데이터도 신뢰하지 않는다"라는 제로 트러스트 (Zero Trust) 사고방식이 기본입니다.

구체적인 포인트는 다음과 같습니다.

수집하는 소스를 큐레이션한다 — 누구나 편집할 수 있는 외부 소스를 무조건적으로 가져오지 않습니다. 신뢰할 수 있는 소스로 한정하거나, 수집 전에 리뷰 프로세스를 거칩니다.

인덱스를 정기적으로 업데이트한다 — 2026년 시점에는 동적인 데이터를 다루는 시스템에서 일간 인덱스 업데이트가 표준이 되어가고 있습니다. 재인덱싱 빈도를 높임으로써 "독"이 계속 남아 있는 기간을 단축할 수 있습니다.

검색 결과를 검증한다 — LLM이 참조한 문서의 출처를 답변에 명시하거나, 여러 소스를 대조하여 모순을 검출하는 등 검색 결과를 그대로 믿지 않는 메커니즘을 마련합니다.

이상 탐지를 도입한다 — 임베딩 공간에서의 수상한 패턴이나 검색 결과의 편향을 감시하는 연구도 진행되고 있습니다. 운영 단계에서의 모니터링을 포함하는 것이 유효합니다.

RAG 포이즈닝도 결국 "입력을 신뢰하지 않는다"라는 보안의 기본 원칙을 응용한 것입니다. RAG의 경우, 그 "입력"이 지식 베이스에 포함되는 모든 데이터로 확장된다는 점을 의식하는 것이 중요합니다.

요약

RAG 포이즈닝 = RAG의 지식 베이스(벡터 DB)에 "독(악의적인 정보)"을 주입하여 LLM의 답변을 조작하는 공격
성립하는 이유 = 많은 RAG가 외부의 편집 가능한 소스(Wikipedia, GitHub 등)를 자동으로 가져오기 때문
주요 수법 = PoisonedRAG(최적화), CorruptRAG(단일 문서로 성립·2026년), Wikipedia Edit 익스플로잇(Exploit), 임베딩 레벨의 인젝션(Injection)
탐지가 어려운 이유 = "독"은 방대한 데이터의 극히 일부임, 원본 소스 수정 후에도 잔존함, 사용자에게 흔적이 보이지 않음
대책 = 소스 큐레이션, 정기적인 재인덱싱, 검색 결과 검증, 이상 탐지

RAG를 구축할 때, 수집하는 소스가 신뢰할 수 있는가?를 항상 생각해야 합니다. 그렇다고 대규모 시스템이 되면 일일이 확인하기는 어렵고, 문서 자체에 프롬프트 인젝션 (Prompt Injection)이 심어져 있을지도 모르고... 고려해야 할 점이 많아 쉽지 않네요.

위협과 리스크를 알고 필요한 대책을 세웁시다!

관련 기사

AI 보안 시리즈의 다른 기사는 이쪽에서 확인하세요.

Discussion