사내 AI 검색이 만든 새로운 사고 유형
사내 문서를 학습·검색하는 AI 어시스턴트를 도입한 조직에서 공통적으로 나타나는 사고가 있습니다. 데이터가 외부로 유출된 것이 아니라, 원본 문서에는 접근 권한이 없는 직원이 AI 답변을 통해 그 내용을 읽게 되는 상황입니다. "우리 회사 임원 연봉 테이블 알려줘"라는 질문에 AI가 요약을 내놓거나, 진행 중인 인수 검토 문건의 핵심 조건이 일반 직원의 채팅창에 등장하는 식입니다.
이 문제의 근본 원인은 AI가 아니라 그 이전에 있습니다. 대부분의 조직은 공유 드라이브를 수년간 운영하면서 "일단 전사 공개로 올리고 나중에 정리하자"를 반복해 왔습니다. 실제 점검을 해 보면 전사 공개 폴더에 인사평가 초안, 급여 밴드, 계약서 사본이 섞여 있는 경우가 드물지 않습니다. 사람이 검색할 때는 정확한 파일명을 모르면 찾을 수 없어 사실상 가려져 있었지만, 의미 기반 검색을 하는 AI는 이 암묵적 은폐(security by obscurity)를 한순간에 무너뜨립니다.
성격도 까다롭습니다. 외부 유출이 아니라 '내부 과다 노출(oversharing)'이기 때문에 기존 DLP 규칙에 걸리지 않고, 침해 사고 신고 대상인지도 애매하며, 직원 입장에서는 "AI가 알려준 것"이라 신고 동기도 약합니다. 그 결과 발견 시점이 사고 발생보다 몇 달 늦어집니다.
왜 기존 RAG 구조에서는 막기 어려운가
전형적인 RAG 파이프라인은 문서를 청크로 쪼개 임베딩한 뒤 벡터 DB에 넣습니다. 이때 원본 문서가 지니고 있던 ACL(접근제어목록)은 대부분 버려집니다. 벡터 인덱스에는 텍스트와 임베딩만 남고, "이 문단은 인사팀만 볼 수 있다"는 정보는 사라집니다. 검색 단계에서 권한을 판단할 근거 자체가 없는 구조입니다.
이를 뒤늦게 보완하려고 흔히 쓰는 방식이 후처리 필터링입니다. 답변을 생성한 뒤 인용된 문서의 권한을 확인해 차단하는 방식인데, 세 가지 문제가 있습니다.
요약·인용 과정에서 경계가 흐려지는 것도 문제입니다. 공개 문서 A와 기밀 문서 B를 함께 참조해 종합 답변을 만들면, 결과물에는 B의 정보가 섞였는데도 출처는 A만 표시되는 일이 생깁니다. 이렇게 되면 로그를 봐도 무엇이 노출됐는지 재구성하기 어렵습니다.
권한 인지형 RAG의 설계 원칙
핵심은 차단 지점을 답변 이후가 아니라 검색 이전으로 옮기는 것입니다.
도입 전 반드시 해야 할 준비 작업
AI를 붙이기 전에 공유 권한 실태 점검이 선행되어야 합니다. 전사 공개로 설정된 폴더, 링크만 알면 열리는 파일, 만료되지 않은 외부 게스트 계정을 목록화하는 작업입니다. 이 단계에서 정리 대상이 전체 문서의 상당 비율로 나오는 것은 이상한 일이 아니며, 오히려 점검 없이 넘어가는 편이 위험합니다.
문서 분류 체계가 아예 없는 조직이라면 완벽한 등급표를 만들려 하지 말고 3단계(공개 / 사내 일반 / 제한)로 시작하는 편이 현실적입니다. 제한 등급만 명확히 정의하고 나머지는 기본값으로 두면, 전수 분류 없이도 위험의 대부분을 덮을 수 있습니다. 여기에 파일 경로·소유 부서·문서 유형 기반 자동 태깅을 얹어 초기 커버리지를 확보합니다.
마지막으로 사후 검증 가능성을 확보해야 합니다. 누가 무엇을 질문했고, 어떤 청크가 검색됐으며, 어떤 문서가 근거로 쓰였는지를 답변 단위로 남겨야 합니다. 이 기록이 없으면 문제가 발생했을 때 노출 범위를 특정할 수 없어 대응이 전면 중단으로 갈 수밖에 없습니다.
운영 단계의 점검 체계
권한 설계는 한 번 만들고 끝나는 것이 아니라 계속 검증해야 하는 대상입니다.
POLYGLOTSOFT는 기업용 AI 어시스턴트를 구축할 때 권한 인지형 검색을 기본 구성으로 설계합니다. 기존 그룹웨어·문서 시스템의 ACL을 인덱스에 연동하고, 사용자 신원 전파와 청크 단위 마스킹, 답변 근거 로깅까지 포함해 구축해 드립니다. 도입 전 공유 권한 실태 점검과 3단계 분류 체계 수립도 함께 지원하니, 사내 AI 도입을 검토 중이시라면 부담 없이 문의해 주시기 바랍니다.