LLM (Large Language Model) 배포에 검색 증강 생성 (RAG, Retrieval-Augmented Generation)을 추가할 때, 여러분은 단순히 더 똑똑한 컨텍스트 윈도우 (Context Window)를 연결하는 것이 아닙니다. 여러분은 여러 개의 새로운 공격 표면 (Attack Surfaces)을 가진 파이프라인을 추가하는 것입니다. 문서 수집 (Document Ingestion)부터 벡터 저장소 (Vector Storage), 검색 조립 (Retrieval Assembly)에 이르기까지 해당 파이프라인의 모든 구성 요소는 보안 통제가 독립적으로 유지되어야 하는 지점을 나타냅니다.

다음은 실무자들이 각 영역에서 실수하는 부분과 그 대신 취해야 할 조치입니다.

여러분의 지식 베이스는 신뢰할 수 없는 입력값입니다

내부 문서를 신뢰할 수 있는 것으로 취급하려는 본능은 이해할 수 있지만 위험합니다. 실제로 대부분의 RAG 지식 베이스는 위키 (Wikis), 티켓팅 시스템 (Ticketing Systems), 공유 드라이브 (Shared Drives), 지원 이메일 스레드 (Support Email Threads), 그리고 사용자 업로드 파일에서 데이터를 가져옵니다. 이러한 소스 중 어느 것이든 시스템을 조작하려는 사람에 의해 영향을 받을 수 있습니다.

그 메커니즘은 간접 프롬프트 주입 (Indirect Prompt Injection)입니다. 공격자는 정당한 사용자의 쿼리가 해당 문서를 검색할 경우 모델이 실제 콘텐츠와 함께 그 지침을 처리할 것이라는 점을 알고 문서 내부에 지침을 삽입합니다. 연구에 따르면 정교하게 제작된 문서는 검색 결과에 지속적으로 나타나도록 배치될 수 있음이 밝혀졌습니다. 언어 모델은 지침 (Instructions)과 데이터 (Data)의 차이를 신뢰성 있게 구분할 수 없기 때문에, 악의적인 문서는 시스템 프롬프트 (System Prompts)를 무시하거나, 의도하지 않은 도구 호출 (Tool Calls)을 트리거하거나, 모델이 검색된 다른 콘텐츠를 유출하도록 만들 수 있습니다.

실질적인 해결책: 검색된 모든 청크 (Chunk)를 신뢰할 수 없는 입력값으로 취급하십시오. 프롬프트 템플릿 (Prompt Templates)에서 지침 콘텐츠와 데이터 콘텐츠를 명시적으로 분리하십시오. 모델이 쿼리를 실행할 때 수행할 수 있는 도구 또는 작업의 범위를 제한하십시오. 소스가 곧 신뢰라는 가정 대신, 수집 과정에서 문서의 출처 (Provenance)를 검증하십시오.

멀티 테넌트 시스템에는 필터뿐만 아니라 구조적 격리가 필요합니다

만약 귀하의 RAG 시스템이 하나 이상의 고객을 지원하거나, 데이터 민감도가 서로 다른 여러 팀을 지원한다면, 쿼리 시점 (query time)의 액세스 제어 (access control)가 결정적인 실패 지점이 됩니다. 애플리케이션 코드 내의 메타데이터 필터 (metadata filters)에만 의존하는 것은 취약합니다. 필터 값을 변경하는 단 한 번의 설정 오류나 주입된 파라미터 (injected parameter)는 가시적인 오류 없이 한 테넌트 (tenant)의 문서를 다른 테넌트의 응답 내에 조용히 노출시킬 수 있습니다.

메타데이터 필터링은 보안 경계 (security boundary)가 아닙니다. 테넌트별 네임스페이스 (namespaces), 테넌트별 별도 컬렉션 (collections), 또는 높은 민감도의 워크로드 (workloads)를 위한 전용 인덱스 (indexes)와 같은 물리적 격리 (hard partitions)가 보안 경계입니다. 어떤 접근 방식을 선택하든, 데이터 수집 시점 (ingestion time)뿐만 아니라 모든 쿼리 시점에 문서 수준의 권한 부여 (document-level authorization)를 재검증하십시오. 스키마 (schemas)와 권한이 진화함에 따라, 인덱스가 요청 사용자가 볼 권한이 있는 문서만을 포함하고 있다는 가정은 거의 항상 틀립니다.

벡터 스토어 (Vector Stores)도 기본 데이터베이스와 동일한 제어가 필요합니다

벡터 데이터베이스 (Vector databases)는 종종 민감한 데이터 저장소라기보다 인프라 유틸리티로 취급되곤 하지만, 이러한 프레임워크는 실제적인 문제를 야기합니다. 벡터 데이터베이스는 가장 민감한 콘텐츠의 의미론적으로 쿼리 가능한 표현 (semantically queryable representations)을 보유하고 있습니다.

두 가지 문제가 이를 악화시킵니다. 첫째, 유사도 검색 (similarity search)은 읽기 권한이 있는 누구나 정확한 파일 이름이나 키워드를 알지 못해도 의미를 통해 코퍼스 (corpus)를 탐색할 수 있게 합니다. 벡터 스토어에 대한 부분적인 읽기 권한은 겉으로 보이는 것보다 공격자에게 훨씬 더 유용합니다. 둘째, 임베딩 (embeddings)은 단방향 해시 (one-way hashes)가 아닙니다. 학술 연구에 따르면 임베딩 벡터 (embedding vectors)로부터 원문 텍스트의 상당 부분을 복구할 수 있음이 입증되었으며, 이러한 재구성 기술 (reconstruction techniques)은 최근 몇 년 동안 상당히 발전했습니다. 벡터 스토어에 대한 읽기 권한을 기반 문서에 대한 실질적인 노출로 간주하십시오.

기본 데이터베이스에 적용되는 제어 항목들이 여기에도 적용되어야 합니다: 인증 (authentication) 필수, 공개 엔드포인트 (public endpoints) 금지, 프라이빗 네트워크 액세스 (private network access), 저장 시 및 전송 시 암호화 (encryption at rest and in transit), 좁은 범위로 제한된 API 키 (API keys), 그리고 쿼리 로깅 (query logging)입니다.

삭제 및 보존 정책은 파이프라인 전반에서 깨지기 쉽습니다

RAG는 데이터를 복제합니다. 문서는 소스 시스템(source system)에 존재하고, 임베딩 파이프라인(embedding pipeline)을 거쳐 벡터 인덱스(vector index)에 저장되며, 중간 계층(intermediate layers)에 캐싱(cached)될 수도 있습니다. 표준 삭제 프로세스는 대개 소스 레코드(source record)만을 대상으로 합니다.

이는 심각한 컴플라이언스(compliance) 격차를 발생시킵니다. 삭제 요청을 준수하거나 보존 정책(retention policy)을 강제하려면, 복사본이 존재하는 모든 계층에 해당 작업을 전파(propagating)해야 합니다. 개인정보(PII)를 포함하는 콘텐츠에서 파생된 벡터(vectors)는 의미 있게 익명화(anonymized)되지 않으며, 복구 가능한 정보를 담고 있습니다. 만약 소스 레코드가 삭제된 후에도 해당 벡터들이 남아 있다면, 삭제는 완전히 완료되지 않은 것입니다.

운영 환경(production)에 적용하기 전에 전체 데이터 생명주기(data lifecycle)를 매핑하십시오. 각 청크(chunk)가 어디로 가는지, 그리고 복사본을 보유한 모든 시스템에서 해당 청크를 제거하는 트리거(trigger)는 무엇인지 파악해야 합니다. 각 벡터 청크를 소스 레코드와 연결하는 자동화된 리니지 추적(lineage tracking)만이 삭제가 완전히 전파되었는지 확인할 수 있는 유일하고 신뢰할 수 있는 방법입니다.

실무 보안 체크리스트

수집 (Ingestion): 인덱싱(indexing) 전 문서 소스를 검증하고 정화(sanitize)하십시오. 수집된 파일에 포함된 비밀 정보(secrets)나 실행 가능한 콘텐츠(executable content)를 스캔하십시오. 출처와 관계없이 검색된 모든 컨텍스트(context)를 신뢰할 수 없는 것으로 취급하십시오.

액세스 제어 (Access control): 단순히 필터 매개변수(filter parameters) 수준이 아니라, 인덱스(index) 또는 네임스페이스(namespace) 수준에서 테넌트(tenant) 또는 사용자 수준의 격리(isolation)를 강제하십시오. 콘텐츠가 처음 인덱싱될 때뿐만 아니라, 검색(retrieval) 시점에도 문서 수준의 권한 부여(authorization)를 재확인하십시오.

벡터 데이터베이스 강화 (Vector database hardening): 인증(authentication)을 요구하십시오. 프라이빗 네트워크(private network) 액세스로 제한하십시오. 저장 시(at rest) 및 전송 시(in transit) 데이터를 암호화하십시오. 자격 증명(credentials)을 순환(rotate)시키고, 모든 쿼리(queries)를 로깅(log)하십시오.

프롬프트 조립 (Prompt assembly): 검색된 텍스트를 시스템 지침(system instructions)과 명확하게 구분하십시오. 검색되는 볼륨(volume)과 관련성 순위(rank)를 제한하십시오. 검색된 콘텐츠가 모델의 도구 권한(tool permissions)을 상승(escalating)시키지 않도록 방지하십시오.

데이터 거버넌스 (Data governance): 필수적이고 보호되는 경우가 아니라면 개인정보(PII)를 임베딩하지 마십시오. 모든 계층에서 삭제 및 보존 정책을 준수하십시오. 각 청크에서 소스 레코드까지의 리니지(lineage)를 유지하십시오.

모니터링 (Monitoring): 검색 쿼리(retrieval queries)와 그 소스를 기록하십시오. 체계적인 탐색(probing)이나 데이터 유출(data exfiltration)을 나타낼 수 있는 비정상적인 검색 패턴이 발견되면 경고를 발생시키십시오.

위협 모델(threat model)을 프롬프트 계층(prompt layer) 너머로 확장하여 전체 검색 파이프라인(retrieval pipeline)을 포괄하는 것은, 진정으로 안전한 RAG 배포와 문제가 발생하기 전까지만 안전해 보이는 배포 사이의 차이를 만듭니다.

이 가이드는 원래 agentpalisade.com에 게시되었습니다. Agent Palisade는 중소기업이 이미 사용 중인 도구 내에서 AI를 활용할 수 있도록 돕습니다 — 실용적인 자동화, 내부 어시스턴트, 그리고 AI 보안 검토를 제공합니다. 무료 30분 상담 예약하기.