사이버보안은 깊고 계속 진화하는 분야라 모든 위험을 다룰 순 없다. 이번 편은 RAG에 고유한 보안 과제에 집중한다 — 핵심은 knowledge base의 정보를 지키는 것이다. RAG를 만드는 흔한 이유가 비공개·독점 정보를 갖고 있어서인데(그래서 공개 웹에 없고 LLM이 학습하지 못한 정보), 시스템 구축 후에도 그 데이터를 계속 비공개로 유지하고 싶다.

그림 1. RAG 보안의 초점 — knowledge base의 비공개 정보에 대한 접근을 이해하고 통제하기.

 

 

 

1. 프롬프트를 통한 유출 — 인증

정보가 유출되는 한 방식은 사용자가 프롬프트로 직접 요청하는 것이다. 잘 짜인 프롬프트는 LLM이 검색된 chunk의 정보를 그대로 인용하도록 설득할 수 있다. 보호 장치가 있어도, 사용자가 최소한 간접적으로는 knowledge base 내용에 접근할 수 있다고 가정하는 게 합리적이다. 직관적 해법은 정보에 맞는 방식으로 사용자를 인증하는 것 — 회사 private data라면 로그인한 직원만 프롬프트를 보낼 수 있게 하는 것이 좋은 시작이다.

그림 2. 프롬프트 유출 — 교묘한 프롬프트가 chunk를 인용시킬 수 있다. 접근 권한에 맞는  인증 이 기본.

 

 

 

2. 데이터 tenant 분리 (RBAC)

두 번째로, role 기반 접근(RBAC)에 따라 데이터를 여러 tenant로 나눠 저장한다. 사용자 프롬프트가 검색으로 이어지면, 이론상 사용자는 자기 role·권한에 허용된 문서만 접근해야 한다. 모든 문서를 한 tenant에 두고 metadata 필터로 접근을 통제할 수도 있지만, 실제로는 실패에 너무 취약하다. metadata 필터링은 개인화에는 적합하나 보안엔 부적합하다 — 보안에는 tenant를 별도로 저장하는 방식이 훨씬 신뢰할 만하다.

그림 3. tenant 분리 — 보안엔  별도 tenant 저장 이 안전. 단일 DB + metadata 필터는 개인화용(보안엔 부적합).

 

 

 

3. LLM provider로의 유출 — on-premises

또 다른 유출 경로는 completion 생성을 위해 프롬프트를 LLM provider로 전송할 때다. 보내는 augmented prompt엔 knowledge base에서 검색된 문서·chunk가 들어 있어, 그 순간 보안 통제권을 잃는다. 정보의 보안 수준에 따라 이는 허용 못 할 위험일 수 있다. 이럴 땐 RAG 전체를 로컬 on-premises에서 — 즉 LLM과 벡터 DB를 자체 하드웨어에 — 운영할 수 있다. 복잡성·비용은 늘지만, 파이프라인 전반에서 knowledge base 내용의 통제권을 갖게 된다.

그림 4. LLM provider 전송 — 검색 문서가 외부로 나가 통제권을 잃는다. 높은 보안엔 on-prem 운영이 답.

 

 

 

4. 직접 해킹과 암호화

knowledge base가 직접 해킹될 수도 있다(전통적 DB처럼). 전통 DB는 내용 암호화로 방어해, 해커가 접근해도 암호화된 정보엔 쉽게 못 닿는다. 벡터 DB는 여기서 고유한 과제가 있다 — ANN이 작동하려면 dense vector는 복호화된 상태로 메모리에 있어야 한다. 대신 chunk의 텍스트는 암호화 상태로 저장·검색했다가 augmented prompt를 만들 때 복호화할 수 있다. 일부 벡터 DB가 이 서비스를 제공하거나, 직접 암복호화할 수도 있다 — 복잡성·약간의 latency를 더하는 대신 보안이 는다.

그림 5. 직접 해킹 — chunk 텍스트는 암호화해 보호. 단, ANN용 dense vector는 복호화 상태로 남아야 한다.

 

 

 

5. 벡터 재구성 위험

암호화되지 않은 채 남는 dense vector 자체가 위험이 될 수 있다. 최근 연구는 dense vector로부터 원본 텍스트를 재구성할 가능성을 보였다 — 즉 chunk를 암호화해도 해커가 암호화되지 않은 벡터에서 chunk를 복원할 수 있다. 이를 막으려는 기법이 연구 중이다 — 벡터에 noise 추가, 변환(transformation) 적용, 거리는 보존하되 의미를 흐리게 차원 축소 등. 다만 각 기법은 retriever를 복잡하게 하고 성능을 낮추는 경향이 있다. 이 공격은 DB 직접 접근 + 실험적 재구성 기법을 모두 요구하지만, 알아둘 가치가 있는 우려다.

그림 6. 벡터 재구성 — dense vector에서 원문 복원 가능. noise·변환·거리보존 차원축소로 완화(성능 저하 감수).

 

핵심. knowledge base엔 비공개 정보가 있을 가능성이 높다는 점, 그리고 그 정보가 어떻게 접근되는지 이해·통제해야 한다는 점을 기억한다. 이 기법들을 더 넓은 사이버보안 대비책과 결합하면 production RAG의 보안을 높일 수 있다.

 

다음 글은 Module 5의 마지막 — 텍스트를 넘어 이미지·PDF·슬라이드를 다루는 멀티모달 RAG(Multimodal RAG)다.

'AI > RAG' 카테고리의 다른 글

멀티모달 RAG (Multimodal RAG)  (0) 2026.07.04
지연(Latency) vs 응답 품질  (0) 2026.07.04
비용 vs 응답 품질  (0) 2026.07.04
커스텀 평가 데이터셋  (0) 2026.07.03
로깅·모니터링·관측성  (0) 2026.07.03

+ Recent posts