RAG는 한 단어로 불리지만 구현은 제각각이다. 어떤 팀은 dense search로 시작하고, 어떤 팀은 hybrid를 쓰고, reranking·필터링·요약·프롬프트 템플릿을 얹는다. 더 나아가 그래프 기반으로 “어떤 근거를 언제 가져올지”를 설계하기도 한다.
그래서 보안을 얘기하려고 하면 이런 의문이 먼저 든다.
“이렇게 다양한데, ‘RAG’라는 공통 개념으로 보안 얘기를 해도 되나?”
나는 이 질문이 오히려 핵심을 찌른다고 본다. 구현이 다양해질수록, 공통분모를 못 잡으면 논의가 디테일 싸움으로 흩어지기 때문이다.
이 글은 내 생각을 정리하는 1편이다. 결론을 확정하려는 글이라기보다, RAG 보안을 어디서부터 잡아야 덜 흔들리는지 렌즈를 제안하려는 글에 가깝다.
여기서는 방어 기법을 열거하기보다, 컨텍스트 레이어가 만드는 신뢰 경계와 관측면적이 어디서부터 흔들리는지를 먼저 정리해보려 한다.
RAG를 구현 디테일로 정의하려고 하면 끝이 없다. 대신 RAG를 “패턴”으로 정의하면 정리가 된다.
질문 → (컨텍스트를 만든다) → LLM이 본다
dense/hybrid/rerank/graph/prompt engineering은 전부 괄호 안을 다르게 구현하는 방법이다. 즉, RAG는 ‘검색 기법의 이름’이라기보다 컨텍스트 구성(Context construction) 레이어를 시스템에 추가하는 방식을 말한다.
프로덕션에서는 이 레이어를 query-time 조립뿐 아니라 ingestion/indexing에서 만들어지는 임베딩·인덱스·메타데이터·로그 같은 장기 자산까지 포함하는 lifecycle 관점으로 보는 편이 더 정확하다.
여기서 내가 중요하다고 느끼는 지점은, 이 레이어가 단순히 “문서 몇 개를 가져오는 기능”이 아니라는 거다. 컨텍스트 레이어는 보통 이런 산출물들을 만든다.
그리고 이 산출물들은 캐시/로그/스토리지/메트릭 같은 운영 포인트를 동반한다.
그래서 나는 RAG를 이렇게 비유해보는 게 꽤 유용하다고 생각한다.
RAG는 ‘데이터를 더 넣어 답을 만든다’가 아니라, ‘무슨 데이터를 답의 근거로 삼을지’를 결정하는 컨트롤 플레인(control plane)을 시스템에 추가하는 일에 가깝다.
모델이 데이터 플레인(data plane)이라면, 컨텍스트 레이어는 모델의 행동을 간접적으로 조종하는 상위 레이어가 된다.
LLM 단독 사용에도 보안 이슈는 있다. 하지만 RAG가 붙는 순간, 논의의 중심은 “모델 자체”를 넘어 시스템의 신뢰 경계로 이동한다.
대략적으로, 레거시 검색/데이터 시스템에서는 경계가 주로 DB/스토리지 접근에 있었던 반면, RAG에서는 후보 선정·필터·리랭크·컨텍스트 조립·로그/캐시 같은 컨텍스트 구성 파이프라인으로 압력이 이동한다.
RAG를 붙인 시스템은 대체로 이렇게 된다.
여기서 핵심은 한 줄이다.
비신뢰 입력이 모델의 의사결정 경로로 들어온다.
이런 류의 위험은 업계에서 프롬프트 인젝션(prompt injection) 같은 이름으로 자주 논의된다[1][2].
나는 “컨텍스트”가 단순 데이터가 아니라, 모델 입장에선 사실상 ‘상황 정의’이자 ‘행동의 전제’가 되기 때문이라고 본다. 컨텍스트가 바뀌면 같은 모델도 다른 답을 하고, (툴을 쓰는 시스템이라면) 다른 도구를 호출하며, 다른 결정을 내린다. 컨텍스트가 ‘근거’가 되는 순간도 충분히 위험하지만, 툴이 붙으면 컨텍스트는 종종 행동의 트리거가 되기 때문에 신뢰 경계 설계가 더 예민해진다.
게다가 컨텍스트 레이어는 시간이 갈수록 복잡해지는 경향이 있다. 검색 하나로 끝나지 않고, 필터가 붙고, rerank가 붙고, 요약이 붙고, 룰이 붙고, 단계가 늘어난다.
단계가 늘면 보안 관점에서 대개 같은 일이 벌어진다.
그래서 나는 “RAG 보안”을 모델만으로 설명하면 어딘가 허술해진다고 느낀다. RAG는 애초에 모델 앞단 레이어를 추가하는 방식이기 때문이다.
보안 얘기를 하면 쉽게 “평문이 노출되냐”로 수렴한다. 물론 중요하다. 다만 RAG에서는 그보다 한 단계 위의 질문이 더 자주 결정적이다.
누가 무엇을 관측할 수 있나?
여기서 관측은 평문만 의미하지 않는다. RAG 시스템에는 ‘의미 있는 중간 신호’가 많다.
관측은 평문만의 문제가 아니다—파생 표현(예: 임베딩)도 시스템 조건에 따라 민감 신호가 될 수 있고, 그래서 ‘무엇이 남는가’가 더 중요해진다.
문제는 이 중간 신호를 “전부” 동일한 방식으로 보호하는 게 현실적으로 어렵다는 점이다. 어떤 프라이버시 강화 기술(PET)이든, 모든 경로에 일괄 적용하면 성능·비용·품질(정확도/재현성)에서 대가를 치르게 된다. 그래서 실제 설계는 보통 이렇게 수렴한다고 느낀다.
운영을 위해 관측은 필요하다. 다만 ‘무엇을 남길지’와 ‘누가 볼 수 있을지’를 더 엄격히 설계해서, 민감 신호가 관측을 통해 축적되는 부작용을 줄이자는 의미에 가깝다.
관측면적을 줄이되, ‘레버리지 큰 곳’부터 줄인다.
여기서 레버리지가 큰 곳은 대개 두 조건을 만족한다.
컨텍스트 레이어에서 이런 성격을 가장 자주 띠는 게 후보/결과 자체도 그렇지만, 더 근본적으로는 저장·검색을 위해 만들어지는 중간 표현(예: 임베딩, 인덱스, 캐시, 로그)다. 이것들은 시스템이 커질수록 더 축적되고, 더 오래 남고, 더 많은 쿼리에서 재사용된다.
그래서 컨텍스트 레이어 보안은 “무조건 trust boundary를 넓히자”가 아니라, 현실적으로는 오히려 이런 방향으로 수렴한다고 느낀다.
비신뢰 구간을 줄이고, 그 구간이 관측할 수 있는 신호를 최소화하자.
RAG 구현이 무엇이든, 보안 논의를 시작할 때 아래 세 질문을 잡으면 논리가 잘 안 무너진다고 느꼈다.
1) 자산(Asset): 무엇이 진짜로 지켜야 할 것인가?
2) 관측(Observability): 누가 무엇을 볼 수 있는가?
3) 확산(Propagation): 입력이 어디까지 영향을 미치는가?
이 질문들은 dense/hybrid/rerank/graph처럼 구현이 바뀌어도 그대로 유효하다. 오히려 구현이 복잡해질수록 더 중요해진다.
RAG의 본질을 “검색”으로만 보면, 보안 논의가 자꾸 모델 근처에서만 맴도는 느낌이 든다. 반대로 RAG를 컨텍스트 레이어의 추가로 보면, 신뢰 경계와 관측면적을 어디에서 줄여야 하는지가 더 선명해진다.
이건 기술 미학의 문제가 아니라, 감사·규제·협력사 운영 같은 현실에서 ‘어디까지를 신뢰할 수 있는지’를 설명 가능하게 만드는 문제이기도 하다.
다음 글에서는 사람들이 꼭 던지는 질문—
“근데 어차피 LLM은 평문 보잖아?”
—에 대해, 내가 지금까지 정리해온 답을 ‘보안 타깃을 분리하는 관점’에서 풀어보려 한다.
(참고로, OWASP 같은 프레임은 ‘권위’라기보다 팀/조직이 공통 언어로 위험을 정렬하는 데 도움이 된다고 생각한다. NIST AI RMF나 Google SAIF 같은 프레임도 같은 목적의 언어다[3][4]. 다만 1편에서는 나열 대신, 왜 컨텍스트 레이어가 중요해지는지에만 집중했다.)
업데이트(2025-12-19): 컨텍스트 레이어를 ingestion/indexing까지 포함하는 lifecycle 관점으로 보는 문장을 보강했습니다.
[1] OWASP Gen AI Security Project — OWASP Top 10 for Large Language Model Applications: https://genai.owasp.org/llm-top-10/
[2] UK National Cyber Security Centre (NCSC) — Prompt injection is not SQL injection (it may be worse): https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection
[3] NIST — Artificial Intelligence Risk Management Framework (AI RMF 1.0) (NIST AI 100-1, PDF): https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf
[4] Google — Secure AI Framework (SAIF): https://saif.google/