1편에서 내가 하려던 주장은 단순했다. RAG 보안의 중심은 모델 자체가 아니다. 모델 앞단에 생기는 컨텍스트 레이어다.
그리고 이 레이어를 ‘질의 시점의 구성’만으로 보지 않으면 좋겠다. 수집/인덱싱 단계에서 생기는 산출물도 함께 본다. 임베딩, 인덱스, 캐시, 로그 같은 것들이다. 이렇게 라이프사이클로 보면 보안 논의의 중심도 자연스럽게 그쪽으로 이동한다.
많은 사람들과 대화를 나눌 때 거의 항상 나오는 질문이 있다.
“근데 어차피 LLM은 평문 보잖아?”
이 질문은 정직하고 중요하다. 하지만 이 질문 하나로 RAG 보안 전체를 재단하면 대화가 쉽게 꼬인다. 서로 다른 보안 타깃이 한 덩어리로 뭉개지기 때문이다. 그 혼선을 가장 직관적으로 드러내는 예시가 접근제어(ACL)이다.1
RAG 보안을 “한 축”으로만 보지 말고, 보안 타깃을 분리해서 보는 게 좋은 출발점이라고 생각한다.
“LLM은 평문을 본다”는 질문은 보통 기밀성 타깃을 찌른다. 특히 생성 단계의 경계 이야기다.
그런데 프로덕션에서 더 자주 부딪히는 건 인가다. 접근제어(ACL)가 그 인가를 가장 보편적인 형태로 드러낸다. 이건 기밀성과 결이 다르다.
RAG의 검색은 기본적으로 “관련성(relevance)”을 최적화한다. 하지만 프로덕션에서 컨텍스트는 관련성만으로 만들 수 없다.
컨텍스트는 ‘정답의 근거’이기 전에, 인가를 통과한 결과물이어야 한다.
이 문장을 받아들이는 순간 시스템이 달라진다. 검색이 top‑k를 뱉는다고 끝이 아니다. “보여줘도 되는가”가 같이 붙는다.
즉 검색은 여전히 중요하다. 다만 이제 검색은 인가 정책 엔진과 한 몸이 된다.
비유를 하나 들면 “도서관 검색 결과”와 “실제로 열람 가능한 책”은 다르다. 검색이 아무리 정확해도 열람 권한이 없으면 그 책은 컨텍스트로 들어갈 수 없다.
접근제어(ACL)는 디테일이 너무 많아서, 논점을 유지하기 위해 내가 자주 부딪히는 “구조적” 문제 세 가지만 살펴보자.
접근제어(ACL)를 적용하려면 결국 “필터링”을 해야 한다. 문제는 필터를 언제 하느냐가 시스템의 성격을 바꾸고 사고 경로(incident path)를 바꾼다는 점이다.
pre-filter(검색 전 필터): 애초에 접근 가능한 후보군에서만 검색
장점: 원천적으로 누출 여지를 줄이기 쉬움
단점: 후보군이 줄어 검색 품질/성능/인덱스 설계가 흔들릴 수 있음
post-filter(검색 후 필터): 일단 top‑k를 뽑고, 그 다음 인가 정책으로 걸러내기
장점: 검색 품질은 유지하기 쉬움
단점: 걸러내고 나면 top‑k가 비거나 품질이 요동칠 수 있음
그리고 무엇보다 “검색 결과/후보”라는 중간 신호가 운영/로그/캐시에 남기 쉬움
이건 구현 취향 문제가 아니다. 무엇을 우선 보안 타깃으로 두는지의 선택이다. 그리고 어떤 사고 경로를 감수할지도 같이 결정한다.
프로덕션 RAG는 관측 없이는 굴러가지 않는다. 하지만 접근제어(ACL)가 붙는 순간 관측 자체가 새로운 위험이 되기 쉽다.
예를 들어 이런 신호는 평문 정보 노출이 아니어도 꽤 강한 단서가 된다.
그래서 “관측 신호를 줄이자”는 말은 로그를 없애자는 뜻이 아니다. 운영에 필요한 관측이 인가 경계를 침식하지 않는 형태여야 바람직하다. 예를 들어 원문 그대로 남기지 않고 집계/요약으로 남기고, 테넌트 단위로 분리하고, 접근 권한과 보존 기간을 엄격히 두는 식이다. 로그에 민감정보가 남는 문제가 반복되는 것도 같은 맥락이다.3
접근제어는 종종 “문서별 ACL 테이블”로 단순화된다. 하지만 실제 운영에서 인가는 계속 변할 수 있다.
이 순간 벡터/인덱스/캐시/로그 같은 장기 자산은 단순 성능 문제가 아니라 정책 동기화 문제가 된다. “한 번 만들고 끝”이 아니라 접근 가능 여부가 바뀔 때마다 업데이트/폐기/재인덱싱이 따라온다.
여기서 나는 RAG 보안이 모델이나 검색 알고리즘만의 문제가 아니라고 더 강하게 느낀다. 운영되는 시스템의 정책과 수명주기 문제이기도 하다.
“LLM이 평문을 본다”는 질문은 중요하다. 하지만 그 질문은 보안 타깃 중 기밀성을 찌르는 질문이다.
여기서 다른 타깃은 인가다. 접근제어(ACL)가 그 인가를 현실로 만든다.
RAG 보안이 어려운 이유는 보통 여기서 나온다. 각자 다른 타깃을 보고 있다. 그런데도 같은 단어(“RAG 보안”)를 쓰니 논의가 엇갈린다.
그래서 내가 지금 유용하다고 느끼는 접근은 이거다.
“우리가 지금 풀려는 건 어느 타깃인가?”를 먼저 정렬하자.
그 다음에야 기술 선택(암호화/격리/필터/정책/관측 설계)이 의미를 가진다.
다음 글에서는 “인가를 통과한 컨텍스트”가 실제로 어디에 남는지부터 정리해보고 싶다. 캐시, 로그, 인덱스, 에이전트 산출물 같은 곳이다. 그런 장기 자산과 관측 신호가 어떻게 경계를 깎는지도 같이 보려 한다.
OWASP Top 10 2021 — A01: Broken Access Control: https://owasp.org/Top10/A01_2021-Broken_Access_Control/ ↩
UK NCSC — Prompt injection is not SQL injection (it may be worse): https://www.ncsc.gov.uk/blog-post/prompt-injection-is-not-sql-injection ↩
MITRE CWE-532 — Insertion of Sensitive Information into Log File: https://cwe.mitre.org/data/definitions/532.html ↩