
Retrieval-Augmented Generation(RAG)은 생성형 AI의 기본적인 한계를 극복하는 중요한 기술입니다. 순수 생성형 AI는 학습 데이터 기준으로만 답변을 생성하므로 최신 정보가 없거나 부정확한 정보를 제시할 수 있습니다. RAG 시스템은 질문을 받으면 먼저 기업의 문서 데이터베이스에서 관련 정보를 검색한 후 그 정보를 기반으로 답변을 생성하는 방식으로 이 문제를 해결합니다.
금융기관, 법률사무소, 의료기관 같은 정확성이 극도로 중요한 조직들이 RAG 시스템을 빠르게 도입하고 있습니다. 그러나 RAG 시스템이 기업의 핵심 문서에 접근하게 되면서 새로운 보안 위협이 등장했습니다. 조직의 기밀 정보, 고객 데이터, 법률 검토 의견 같은 민감한 정보가 RAG 시스템을 통해 부정당하게 유출될 위험이 있습니다.
RAG 시스템의 보안은 단순한 IT 문제가 아니라 조직 전체의 정보 보안 정책의 일부입니다. 기업이 RAG 시스템을 안전하게 구축하고 운영하려면 데이터 접근 제어부터 감시 로깅까지 다층적인 보안 체계를 설계해야 합니다.
RAG 시스템이 외부 데이터베이스와 생성형 AI 모델 사이를 연결하는 구조이므로 여러 단계에서 공격이 가능합니다.
문서 데이터베이스의 접근 제어 우회는 가장 직접적인 위협입니다. 공격자가 RAG 시스템의 검색 쿼리를 조작하여 본래 접근할 수 없는 문서까지 검색되도록 할 수 있습니다. 예를 들어 "재무 정보를 포함한 모든 문서 검색" 같은 조작된 쿼리를 통해 접근 제한된 정보를 꺼낼 수 있습니다.
정보 유출 공격도 RAG의 특성상 발생합니다. 생성형 AI가 검색한 문서의 내용을 직접 노출하거나 암시적으로 유출할 수 있습니다. 사용자가 악의적 질문을 통해 특정 고객의 정보나 거래 기록을 추출하도록 유도할 수 있다는 의미입니다.
소스 확인 실패는 생성형 AI의 본질적 한계입니다. AI가 어떤 문서에서 정보를 가져왔는지를 정확히 기록하지 않거나 거짓 출처를 제시할 수 있으므로 사용자가 정보의 신뢰성을 판단하기 어렵습니다.

RAG 시스템의 보안에서 가장 중요한 것은 사용자의 권한에 맞춰 접근 가능한 문서를 제한하는 것입니다.
▲ 역할 기반 접근 제어(RBAC)의 구현 - 조직의 각 사용자에게 역할을 부여하고 그 역할에 맞는 문서에만 접근을 허락합니다. 예를 들어 일반 직원은 공개 정책 문서만 접근 가능하지만 재무팀 직원은 추가로 재무 보고서도 접근할 수 있습니다. 이러한 역할은 조직의 직급, 부서, 직책에 따라 자동으로 할당될 수 있습니다.
▲ 속성 기반 접근 제어(ABAC)의 고도화 - RBAC보다 더 세밀한 제어가 필요한 경우 속성 기반 방식을 사용합니다. 문서마다 "기밀 등급", "지역", "프로젝트"라는 속성을 부여하고 사용자의 속성과 매칭하여 접근을 결정합니다. 예를 들어 "프로젝트 A" 속성을 가진 사용자만 관련 문서에 접근하도록 제한할 수 있습니다.
필터링 메커니즘의 통합도 중요합니다. RAG 시스템이 쿼리 결과를 반환하기 전에 사용자의 권한에 맞춰 문서를 필터링해야 합니다. 이는 데이터베이스 수준과 애플리케이션 수준에서 동시에 적용되어야 보안이 강화됩니다.

기업의 모든 문서를 동등하게 취급하면 안 되며 문서의 민감도에 따라 분류해야 합니다.
조직은 먼저 문서 분류 정책을 수립합니다. 공개 정보, 내부 정보, 기밀 정보, 극비 정보 같은 여러 수준의 분류 체계를 정의하고 모든 문서에 적용합니다. 이러한 분류는 문서 생성 시점부터 자동으로 이루어질 수 있습니다. 예를 들어 "고객 개인정보"라는 키워드가 포함되면 자동으로 "기밀" 등급으로 분류됩니다.
메타데이터 관리는 문서에 대한 상세한 정보를 저장합니다. 작성자, 생성 날짜, 수정 이력, 접근 권한자 목록, 만료일 같은 정보가 문서와 함께 관리됩니다. 이를 통해 특정 문서에 누가 접근했는지를 추적할 수 있고 만료된 정보는 자동으로 접근 금지할 수 있습니다.
자동 데이터 민감도 탐지 시스템을 도입하면 문서의 실제 내용을 분석하여 민감한 정보의 존재 여부를 판단합니다. 신용카드 번호, 주민등록번호, 직원 급여 정보 같은 패턴을 인식하여 자동으로 높은 보안 등급을 할당합니다.

사용자의 쿼리가 의도적으로 또는 무의식적으로 보안 정책을 위반할 수 있으므로 검증이 필요합니다.
쿼리 의도 분석은 사용자가 입력한 질문이 정말 정상적인 업무 목적인지를 판단합니다. "모든 고객 목록을 가져와"라는 쿼리는 정상적인 업무에 필요한가, 아니면 데이터를 대량 수집하려는 악의적 의도는 없는가를 분석합니다. 이를 통해 비정상적인 패턴을 조기에 발견할 수 있습니다.
입력 검증과 정제는 쿼리에서 잠재적으로 위험한 명령어나 문법을 제거합니다. SQL 인젝션 같은 공격 기법이 RAG 시스템에도 적용될 수 있으므로 이를 사전에 방어합니다.
결과 내용 필터링도 필수적입니다. 검색 결과가 반환되기 전에 사용자의 접근 권한을 다시 한 번 확인하고 권한 범위를 벗어나는 내용은 삭제하거나 마스킹합니다.
생성형 AI 모델이 검색한 문서의 내용을 그대로 노출하는지 아니면 의도적으로 왜곡하는지를 감시해야 합니다.
출력 내용 검토 메커니즘은 모델이 생성한 답변에 민감한 정보가 포함되었는지를 자동으로 확인합니다. 신용카드 번호, 개인정보, 기밀 프로젝트명 같은 민감한 정보가 감지되면 마스킹하거나 답변을 차단합니다.
출처 명시의 강제는 모델이 반드시 정보를 어느 문서에서 가져왔는지를 명확히 기록하도록 합니다. 이를 통해 사용자가 정보의 신뢰성을 평가할 수 있고 조직이 사실 여부를 검증할 수 있습니다.
주기적인 출력 감사를 통해 모델의 행동이 정책을 벗어나고 있지 않은지를 확인합니다. 무작위로 선택된 수백 개의 RAG 응답을 검토하여 정책 위반을 발견할 수 있습니다.

모든 RAG 시스템의 활동을 기록하고 보관해야 보안 사고 발생 시 원인 파악과 책임 추적이 가능합니다.
접근 로깅: 누가 언제 어떤 문서를 검색했는지를 기록합니다. 만약 민감한 정보가 부정당하게 유출되었다면 이 로그를 통해 누가 그 정보에 접근했는지를 추적할 수 있습니다.
쿼리 로깅: 사용자들이 어떤 질문을 했는지를 저장합니다. 악의적인 쿼리 패턴이 반복된다면 이를 통해 공격을 감지할 수 있습니다.
모델 응답 로깅: 생성형 AI가 어떤 답변을 제공했는지를 기록합니다. 나중에 문제가 발생했을 때 모델의 행동이 정책을 따랐는지를 검증할 수 있습니다.
장기 보관과 분석도 중요합니다. 이 로그들은 최소 몇 년간 보관되어야 하며 주기적인 분석을 통해 새로운 위협 패턴을 발견할 수 있습니다.
RAG 시스템이 개인정보를 다룰 때는 GDPR, 개인정보보호법 같은 규제를 반드시 준수해야 합니다. 개인정보의 식별과 태깅은 저장소의 문서에서 고객 이름, 이메일, 전화번호 같은 개인정보를 자동으로 찾아 태깅합니다. 이를 통해 어떤 문서에 개인정보가 포함되는지를 파악할 수 있습니다.
데이터 주체의 권리 보장도 보안의 일부입니다. 고객이 "나에 대한 모든 정보를 삭제해달라"고 요청하면 조직은 저장소에서 그 정보를 찾아 삭제해야 합니다. RAG 시스템은 이러한 삭제 작업을 추적할 수 있어야 합니다.
규제 감사 대비도 준비되어야 합니다. 규제 당국이 RAG 시스템의 개인정보 처리 과정을 조사할 때 조직은 명확한 기록과 정책을 제시할 수 있어야 합니다.
