RAG의 지식 DB는 열린 문이다

RAG의 보안 구멍은 모델이 아니라 지식 DB에 있다

RAG(검색 증강 생성) 시스템을 공격하려면 LLM을 해킹할 필요가 없다. 수백만 건의 문서가 담긴 지식 DB에 악성 텍스트 5개만 심으면 된다. PoisonedRAG¹는 이 사실을 증명한 최초의 지식 손상(knowledge corruption) 공격이다. GPT-4, PaLM 2, LLaMA-2를 포함한 8개 LLM에서 90% 이상의 공격 성공률을 보였고, 기존의 4가지 방어 기법을 모두 무력화했다.

여기서 핵심은 규모의 비대칭이다. 공격자가 건드리는 것은 DB의 0.0002%에 불과하지만, 그것만으로 시스템 전체의 응답을 장악한다.

왜 지식 DB가 공격 표면인가

RAG는 세 구성요소로 이루어져 있다: 지식 DB, 리트리버, LLM. 기존 보안 연구는 LLM의 학습 데이터를 오염시키는 데이터 포이즈닝이나, 프롬프트를 조작하는 인젝션 공격에 집중했다. 하지만 RAG의 지식 DB는 위키피디아 문서, 웹 크롤링 결과, 사내 문서 등 외부에서 유입되는 텍스트로 채워진다. 누군가 위키피디아 문서를 편집하거나, 크롤러가 수집하는 웹페이지에 가짜 정보를 심거나, 내부자가 문서를 하나 추가하면 그것이 곧바로 RAG의 참고 자료가 된다.

모델의 파라미터는 한 글자도 바뀌지 않았는데, 참고 자료가 바뀌었으니 답이 달라지는 것이다.

역할 분담: 검색과 생성을 따로 속인다

PoisonedRAG의 핵심 아이디어는 악성 텍스트 P를 두 부분으로 나누는 것이다.

• S (검색용): 리트리버가 이 텍스트를 검색 결과 상위에 올리게 만드는 부분
• I (생성용): LLM이 이 텍스트를 읽고 공격자가 원하는 답변을 내놓게 만드는 부분

왜 분리가 필요한가? 두 조건이 서로 충돌하기 때문이다. 텍스트가 질문과 매우 유사하면 검색에는 잘 걸리지만, 질문에 대한 ‘정답’에 가까운 내용을 담고 있어서 오답을 유도하기 어렵다. 반대로 오답 유도에 최적화된 텍스트는 질문과 관련이 없어 보여 검색에 걸리지 않는다.

P = S ⊕ I로 분해하면 각 조건을 독립적으로 최적화할 수 있다. 알고리즘의 분할 정복(divide and conquer)과 이름은 비슷하지만, 재귀적으로 문제를 쪼개는 것이 아니라 서로 다른 역할을 분담시키는 것에 가깝다. 이 단순한 역할 분리가 PoisonedRAG의 전부이자 핵심이다.

Black-box 공격: 놀라울 만큼 단순하다

리트리버의 내부 구조를 전혀 모르는 black-box 상황에서 S를 어떻게 만들까? 답은 허무할 정도로 간단하다. 대상 질문 Q를 그대로 S로 쓰면 된다. 질문은 자기 자신과 가장 유사하므로 검색 조건을 자동으로 충족한다.

I는 GPT-4에게 “이 질문의 답이 X가 되도록 뒷받침하는 텍스트를 작성하라"고 요청하면 된다. 평균 1.6회의 LLM 쿼리로 충분하고, 텍스트 하나를 만드는 데 걸리는 시간은 사실상 0초(1.45 × 10⁻⁶초)다.

이렇게 만든 텍스트 5개를 268만 건의 DB에 넣으면 공격 성공률(ASR) 97% — NQ 데이터셋, Contriever 리트리버, k=5 조건에서다. 비용 대비 파괴력이 비상식적이다.

방어가 안 되는 이유

논문은 4가지 기존 방어 기법을 실험했고, 모두 실패했다.

패러프레이징(질문을 다르게 바꿔서 검색): S가 질문 자체이므로 패러프레이징된 질문과도 여전히 유사하다. 공격 성공률이 87%로 소폭 하락할 뿐이다.

퍼플렉시티 탐지(이상하게 생긴 텍스트를 걸러내기): I는 GPT-4가 작성한 자연스러운 텍스트다. 클린 텍스트와 퍼플렉시티 차이가 거의 없어서 분류 정확도(AUC)가 0.25~0.30 수준 — 랜덤 추측보다 못하다.

중복 필터링(같은 텍스트를 여러 개 넣었을 때 걸러내기): I는 매번 다르게 생성되므로 해시 기반 필터링이 무력하다.

검색 결과 늘리기(k를 50까지 올리기): 클린 텍스트가 더 많이 포함되지만 그래도 공격 성공률이 41~43%나 유지된다. 약해지긴 하지만 실질적인 해결책은 아니다.

방어가 어려운 근본적 이유는 악성 텍스트의 품질이 높다는 것이다. 프롬프트 인젝션처럼 “ignore previous instructions"를 외치는 게 아니라, GPT-4가 쓴 그럴싸한 ‘참고 문헌’이 검색 결과 상위를 점거하는 것이다. 콘텐츠 자체가 정상적으로 보이니 필터로 잡기가 어렵다.

소프트웨어 공급망 공격의 데자뷔

PoisonedRAG를 읽으면서 떠오른 것은 소프트웨어 공급망 공격(supply chain attack)이다. npm에 악성 패키지를 올리면 그것을 의존하는 수천 개의 프로젝트가 감염된다. PoisonedRAG가 하는 일도 본질적으로 같다. 지식 DB라는 ‘공급망’에 악성 문서를 올리면, 그것을 참고하는 모든 응답이 오염된다.

차이가 있다면 소프트웨어 공급망은 수십 년에 걸쳐 서명(signing), 해시 검증, 출처 추적(provenance tracking) 같은 방어 체계를 쌓아왔다는 것이다. RAG의 지식 DB에는 이런 것이 아직 없다. 위키피디아 문서가 변조되었는지 검증하는 메커니즘도, 크롤링된 웹페이지의 신뢰도를 평가하는 표준도 없다.

이 논문이 직접 실험한 범위는 정적 QA 데이터셋에 한정되지만, RAG의 구조적 취약점 — 외부 텍스트를 검증 없이 신뢰한다는 것 — 은 프로덕션 환경에서도 동일하다. 넓게 보면 LLM에 텍스트가 유입되는 채널(검색 결과, 도구 호출 응답, 웹 크롤링)은 모두 같은 구조적 위험을 공유한다.

어디를 바라봐야 하는가

모델을 얼마나 크고 똑똑하게 만들든, 참고 자료가 오염되면 답도 오염된다. GPT-4도 예외가 아니었다. 이것은 모델 크기나 성능의 문제가 아니라 아키텍처의 문제다.

만족스러운 해결책은 아직 없지만, 방향은 몇 가지 보인다.

첫째, 문서 출처 인증(provenance tracking). 지식 DB에 들어오는 문서마다 출처의 신뢰 등급을 매기고, 검색 결과에 반영하는 것이다. 소프트웨어 세계의 코드 서명과 같은 원리다.

둘째, 검색 결과의 출처 다양성 강제. 같은 질문에 대해 검색된 k개 문서가 모두 같은 출처에서 왔다면 경고 신호다. 출처가 다양할수록 단일 공격자가 상위를 점거하기 어려워진다.

셋째, 응답 생성 시 참고 문서 간 일관성 검증. 5개 검색 결과 중 하나만 다른 답을 주장한다면, LLM이 그것을 가중치 낮게 처리하거나 사용자에게 불일치를 알리는 것이다.

어느 것도 완벽하지 않겠지만, PoisonedRAG가 보여준 교훈은 분명하다. RAG를 프로덕션에 배포하고 있다면, 지식 DB의 무결성을 어떻게 보장할 것인지가 모델 선택보다 더 중요한 질문이다.