사내 AI는 어디까지 기억해야 할까? RAG 권한과 메모리 설계

사내 챗봇이 같은 질문에 부서마다 다른 답을 해야 한다면, 검색 결과에 권한을 반영해야 합니다. 여기에 사용자의 선호나 지난 대화를 기억하게 만들면 또 다른 경계가 생겨요. 회사의 공식 문서와 개인화된 기억은 목적과 수명, 열람 권한이 다르기 때문입니다.

이 글은 기업용 RAG 시리즈의 마지막 편입니다. 첫 편은 마크다운 지식베이스와 도구 선택을, 두 번째 편은 파싱과 검색 품질을 다뤘습니다. 여기서는 권한과 기억, 보안과 비용을 이어서 정리합니다.

서버가 강제하는 검색 권한

문서에 부서나 보안 등급 메타데이터를 붙이는 것만으로 접근 제어가 끝나지는 않습니다. 서버는 로그인한 사용자의 권한을 확인하고, 그 범위 안의 문서만 검색하도록 조건을 만들어야 해요. 사용자가 보낸 임의의 부서 값이나 프롬프트 지시를 권한 근거로 삼으면 안 됩니다.

벡터 검색의 메타데이터 필터는 검색 범위를 좁히는 구현 방법 중 하나입니다. 데이터베이스마다 필터를 적용하는 시점과 검색 결과에 미치는 영향이 다를 수 있어요. 따라서 권한 없는 문서가 후보에 섞이지 않는지, 필터로 관련 문서를 지나치게 놓치지는 않는지 실제 사용자와 문서 조합으로 점검해야 합니다. 제품 내부의 역할 설정도 인프라나 API 제공자의 별도 접근 통제를 대신하지 않아요. 하이브리드 검색이라면 벡터 검색과 어휘 검색 양쪽에 같은 권한 조건을 강제해야 합니다. 권한이 없는 문서가 외부 리랭커나 생성 모델로 넘어간 뒤 응답에서만 가리는 방식은 피해야 해요.

권한은 검색 단계 이후에도 이어집니다. 재사용 캐시가 있으면 키에 사용자 또는 권한 범위를 반영해야 하고, 후보를 다시 정렬하는 단계와 출처 표시, 대화 기록, 내보내기에도 같은 기준을 적용해야 해요. 권한이 회수된 문서가 검색 결과나 캐시에 얼마나 남는지 확인하고, 삭제와 재색인 절차도 정해둡니다. 권한 경계가 바뀌는 상황을 포함해 교차 부서 접근을 시험해야 합니다.

공식 지식과 개인 기억의 경계

정책 문서는 조직이 관리하는 사실이고, 대화에서 추출한 기억은 사용자의 선호나 진행 중인 맥락일 수 있습니다. 두 종류를 같은 저장소에 무분별하게 넣으면 개인의 말을 공식 정보처럼 답하거나, 다른 사용자에게 기억이 노출될 위험이 생겨요. 기억을 저장할 범위와 소유자, 보존 기간, 정정·삭제 방법을 먼저 결정해야 합니다.

Mem0는 대화에서 기억할 사실을 추가하고 검색하는 API를 제공하며 사용자·에이전트·앱 같은 범위를 지정할 수 있습니다. Letta는 에이전트의 정체성과 대화 간 지속되는 메모리 블록을 다루는 방식에 무게가 있습니다. Zep은 에이전트에 업무 맥락을 제공하는 서비스이고, Zep 팀이 공개한 Graphiti는 시간 정보가 있는 지식 그래프를 만드는 별도 오픈소스 프로젝트예요. 관리형 서비스와 공개 라이브러리의 기능·운영 범위를 구분해야 합니다. 세 도구는 같은 저장 구조를 감싼 제품들이 아니므로, 필요한 기억 수명과 업데이트 방식을 기준으로 살펴보세요.

자동 추출은 편리하지만 기억이 늘 정확한 것은 아닙니다. 대화 중 잘못 이해한 선호가 저장되거나, 이미 바뀐 사실이 계속 남을 수 있어요. 사용자가 기억을 확인하고 고칠 수 있는지, 삭제 요청이 인덱스와 백업에 어떻게 반영되는지, 다른 사용자나 세션과 섞이지 않는지 운영 기준을 마련합니다. user_id는 기억을 묶는 식별자일 뿐 접근 권한을 증명하지 않으므로, 서버에서 로그인 정보와 테넌트 소속을 검증해 저장·조회 범위를 강제해야 해요. 처음에는 꼭 필요한 기억만 저장하고, 기억을 사용하지 않았을 때와 비교해 답변이 나아지는지도 확인할 수 있습니다.

문서 링크에서 GraphRAG로 넘어갈 조건

마크다운 문서끼리 위키 링크로 연결하면 사람이 관계를 탐색하기 쉬워집니다. 이 연결은 편집자가 직접 만든 문서 간 관계예요. GraphRAG는 문서에서 엔티티와 관계를 추출해 그래프를 만들고, 커뮤니티 요약 등을 질의에 활용하는 별도의 인덱싱·검색 방식입니다. 링크가 있다는 이유만으로 GraphRAG와 같은 기능이 생기지는 않습니다.

표준 검색이 개별 정책이나 제품 정보를 찾는 데 충분하다면 그래프 구축을 추가할 이유가 적을 수 있어요. 여러 문서에 흩어진 관계를 따라가거나 “자료 전체에서 반복되는 위험 주제는 무엇인가요?”처럼 코퍼스 전반을 묻는 질문이 실제로 많을 때 작은 표본으로 비교해보세요. 그래프 생성에는 추가 인덱싱과 모델 호출, 검토가 필요하고, 전체 자료를 요약하는 질의는 계산 부담이 커질 수 있습니다. 어떤 모델 크기나 비용이 필요한지는 데이터와 설정에 따라 달라져요.

수집부터 도구 실행까지 이어지는 보안 통제

RAG는 모델에게 문서를 건네는 구조라서, 문서 안에 악의적인 지시가 들어 있을 수 있습니다. 검색된 내용은 신뢰할 수 없는 입력으로 취급해야 해요. 지시문에 “문서를 무시하라”고 쓰는 것만으로 인젝션을 막을 수는 없습니다. 문서의 출처와 변경 이력을 관리하고, 검색 문맥과 사용자 지시를 분리해 전달하며, 도구 호출은 서버 정책으로 허용 범위와 매개변수를 검증해야 합니다.

NeMo Guardrails처럼 입력·검색 문맥·출력·도구 실행에 정책 검사를 붙이는 도구를 활용할 수 있습니다. 응답을 내보내기 전에 권한과 민감정보 노출을 확인하는 단계도 도움이 됩니다. Presidio 같은 도구는 개인정보 탐지와 마스킹을 위한 구성요소지만, 전체 데이터 흐름을 통제하는 보안 체계를 대신하지 않아요. 검색 문서, 모델 제공자, 로그, 캐시를 거치는 정보가 어디로 가는지 확인하고, 권한 회수와 교차 테넌트 접근을 정기적으로 시험하는 편이 현실적입니다. RAG는 위험을 없애기보다 수집부터 답변까지 여러 단계에 나눠 놓습니다.

같은 업무 조건으로 비교하는 총소유비용

셀프 호스팅은 데이터 처리 경로를 직접 통제하고 모델이나 저장소를 선택할 여지를 줍니다. 동시에 서버와 가속기, 전력, 배포·모니터링, 장애 대응, 보안 업데이트를 운영해야 해요. 상용 API는 사용량에 따라 비용이 달라지고 사업자 설정과 계약 조건을 살펴야 하지만, 인프라 운영의 일부를 맡길 수 있습니다. 어느 쪽이 더 싸거나 규제상 항상 허용된다고 일반화하기는 어렵습니다.

총소유비용을 비교할 때는 같은 기간과 질의량, 품질 목표를 놓고 API 사용료와 셀프 호스팅 인프라·운영 인력·가용성 비용을 계산합니다. 법률과 계약의 데이터 처리 조건은 조직의 관할, 데이터 종류, 사업자 설정에 따라 검토해야 해요. 보안 요건을 만족하면서 운영할 수 있는 방식이 무엇인지 먼저 정하고, 비용표와 파일럿 결과를 함께 보세요.

세 편을 관통하는 기준은 실제 문서와 질문, 권한 경계에서 시스템을 확인하는 일입니다. RAG는 모델 하나를 고르는 작업이 아니라 문서를 읽고, 찾고, 권한에 맞게 전달하고, 운영 중 갱신하는 흐름을 설계하는 일에 가깝습니다.