문서를 어디에도 올리지 않고 AI로 검색하기 — 스코프드 RAG

업무용 드라이브에 파일이 수천 개 있습니다. 계약서, 회의록, 스프레드시트, 십 년치 초안. 그걸 전부 읽은 동료에게 묻듯이 질문하고 싶습니다. 보통의 방법은 어딘가에 올리는 것입니다. 지식베이스가 붙은 챗 서비스, AI 탭이 생긴 노트 앱, 벤더의 문서 워크스페이스. 그 방법은 실제로 동작하고, 대신 그 파일들에 대해 애초에 협상 대상이 아니었던 한 가지를 가져갑니다. 파일이 밖으로 나갑니다.

훨씬 덜 이야기되는 두 번째 방법이 있고, 그건 프라이버시를 위해 성능을 포기하는 선택이 아닙니다. 파일은 있던 자리에 그대로 두고, 대신 검색이 지금 어디를 보고 있는지를 알게 만드는 것입니다. Filer가 하는 일이 이것이고, 이 글은 그 구조에 대한 이야기입니다. 무엇인지, 왜 모델보다 범위 좁히기가 더 중요한지, 그리고 그 한계가 정확히 어디인지.

RAG가 실제로 하는 일

RAG(retrieval-augmented generation)는 약어에 싸여 있을 뿐 단순한 아이디어입니다. 언어 모델은 여러분의 파일을 기억하지 못합니다. 그래서 답하기 전에, 무언가가 먼저 문서에서 질문과 관련 있어 보이는 몇 문단을 찾아 오고, 질문과 함께 그것만 모델에 건넵니다. 모델은 건네받은 것으로 답합니다. 찾기가 먼저, 생성이 나중. 전체 구조는 이게 다입니다.

찾는 단계는 글자가 아니라 의미로 동작합니다. 각 문서의 각 문단은 숫자 목록 — 임베딩 — 으로 바뀌어 "무엇에 관한 글인지"에 따라 배치됩니다. 그래서 "갱신 기한"을 묻는 질문이 "본 계약은 다음 일자로 만료된다"라고만 적힌 문단을 찾아낼 수 있습니다. Filer는 파일을 기억(memorize)시킬 때 이 임베딩을 만들고, 그 폴더 자신의 인덱스에 보관합니다. 기억은 파일 단위든 폴더 단위든 여러분이 직접 시키는 동작입니다. 디스크에 있다는 이유만으로 인덱스에 들어가는 파일은 없습니다.

왜 큰 인덱스보다 좁은 범위가 이기는가

여기서 대부분 의외라고 느낍니다. 검색 품질은 문서를 넣을수록 좋아지지 않습니다. 나빠집니다. 문서를 하나 더 넣을 때마다, 아무 상관 없는 질문에도 그럴듯한 점수를 받을 수 있는 후보가 하나 늘어납니다. 작년 버전의 같은 계약서, 어휘가 통째로 겹치는 템플릿, 그 주제를 한 번 스쳐 언급한 주간보고. 정답 문단이 나빠진 게 아닙니다. 비슷비슷한 것들이 쌓인 더미에서 그걸 집어내기가 어려워졌을 뿐입니다.

AI 문서 서비스들이 한 워크스페이스에 넣을 수 있는 양을 몇십 개, 한 프로젝트 식으로 제한하는 이유가 이것이고, 그 제한이 사실은 품질 관리인데 기능 부족처럼 읽히는 이유이기도 합니다. 희소한 자원은 용량이 아니라 정확도입니다.

그러면 자연스럽게 다른 해법이 보입니다. 얼마나 보관할 수 있는지를 제한하는 대신, 질문 하나가 볼 수 있는 범위를 좁히는 것입니다. 어떤 질문이 project-alpha/design/ 안의 파일 11개로만 답해질 수 있다면, 나머지 4천 개는 그 답을 두고 경쟁하지 못합니다. 순위에서 밀려서가 아니라, 애초에 후보가 아니었기 때문입니다.

문제는 그 범위를 누군가 정해줘야 한다는 것이고, 사람에게 범위를 정의하라고 요구하는 건 정리를 두 번 시키는 일입니다.

지금 서 있는 폴더가 곧 범위입니다

그런데 그 정리는 이미 해두셨습니다. 폴더 트리가 곧 범위 계층입니다. 여러분이 몇 년에 걸쳐 손으로, 본인이 실제로 일을 생각하는 방식대로 만들어 둔 계층입니다. Filer는 그걸 그대로 읽습니다. 지금 열려 있는 폴더가 검색 범위이고, 그 아래에서 기억시킨 것이 질문이 닿을 수 있는 전부입니다.

D:/work/                    ← 넓게 — 전체 프로젝트
  ├── project-alpha/        ← 좁게 — 이 프로젝트만
  │   ├── design/           ← 정확히 — 설계 문서만
  │   └── reports/          ← 정확히 — 보고서만
  └── project-beta/

work/에서 물으면 질문이 전체에 닿고, 같은 질문을 project-alpha/design/에서 물으면 파일 11개에 닿습니다. 범위를 설정하지도, 컬렉션 이름을 짓지도, 태그를 달지도 않았습니다. 파일을 열 때와 똑같이 이동했을 뿐이고 검색이 따라 좁아졌습니다. 위로 올라가면 다시 넓어집니다.

물어볼 수 있는 두 곳 모두 이렇게 동작합니다. 탐색기의 채팅 패널은 지금 보고 있는 폴더로 범위가 잡히고, AI Search 화면은 검색창 위에 범위를 보여주며 직접 고쳐 쓸 수도 있습니다. 서 있는 곳이 아닌 다른 곳을 찾고 싶을 때를 위한 것입니다. 밑에서 도는 구조는 같습니다. 폴더 경로가 어떤 문단이 후보가 될지 결정합니다.

기본값은 어디까지나 경험칙이고, 그건 분명히 말해두는 편이 낫습니다. 질문이 닿지 않는 자리에 파일을 정리해 두셨다면 폴더 범위 검색은 그걸 놓칩니다. 설정이 전혀 필요 없는 기본값의 대가이고, 해법은 트리에서 한 칸 위로 올라가는 것입니다. 일부러 전체를 보고 싶을 때 — "이것에 관해 쓴 게 어느 폴더엔가 있었나?" — 는 루트에서 묻는 것이 정확히 그 동작입니다.

임베딩은 실제로 어디서 도는가

이 글의 제목이 "어디에도 올리지 않고"라고 말하고 있으니, 그게 무엇을 뜻하고 무엇을 뜻하지 않는지 정확히 적어야 합니다.

Filer는 모델을 함께 배포하지 않고 구독을 요구하지도 않습니다. 추론이 어디서 일어날지는 설정 → AI에서 여러분이 고릅니다.

• 로컬 모델. 임베딩도 채팅도 이 기기에서 돕니다. 문서는 디스크에서 읽히고, 같은 기기에서 임베딩으로 바뀌고, 파일 옆 그 폴더의 인덱스에 저장됩니다. 내용에 관한 어떤 것도 네트워크로 나가지 않습니다. 제목이 글자 그대로 참이 되는 구성이 이것입니다.
• 본인의 클라우드 API 키. 이미 쓰고 계신 제공자에 여러분의 키로 연결합니다.
• 회사가 이미 돌리는 서버. GPUStack, Ollama, vLLM, 그 밖의 OpenAI 호환 엔드포인트라면 무엇이든 — 같은 방식의 연결을, 밖이 아니라 사내망 안쪽으로 향하게 하는 것뿐입니다.

두 번째와 세 번째 경우에는, 질문을 위해 찾아온 문단이 그 엔드포인트로 갑니다. 답하는 모델이 거기 있기 때문입니다. 폴더 범위는 어떤 문단이 갈지를 바꾸지, 가느냐 마느냐를 바꾸지 않습니다. 그래도 의미 있는 감소입니다. 하위 폴더 하나에서 답한 질문은 라이브러리 전체가 아니라 문단 몇 개만 보내고, 파일 자체는 어디로도 업로드되거나 복사되지 않습니다. 다만 그건 "이 기기 밖으로 아무것도 나가지 않는다"와 같은 주장은 아니며, 그 강한 주장을 참으로 만드는 것은 로컬 선택지뿐입니다.

회사에서 일하는 대부분의 경우 흥미로운 건 세 번째입니다. 그 엔드포인트는 이미 회사가 신경 쓰는 경계 안쪽에 있기 때문입니다. 그 이야기는 따로 있습니다. 회사 AI 서버를 내 자리에서 쓰는 법.

매일 쓰면 이렇게 보입니다

실제로 쓰다 보면 범위 좁히기는 의식하는 기능이 아니라 반사에 가까워집니다. 파일을 어디서 찾을지에 대해 이미 갖고 계신 그 반사와 같은 것입니다.

• 프로젝트 폴더에 서서 그 프로젝트를 묻기. 지금 그 일을 하고 있으니 project-alpha/에 있고, 질문이 그 맥락을 물려받습니다. 어느 프로젝트 이야기인지 앞에 설명을 달 필요가 없습니다.
• 잡음을 줄이려 한 칸 더 들어가기. 설계 결정을 원했는데 답이 reports/ 쪽 내용을 끌어왔다면, design/으로 들어가 다시 물으면 됩니다. 범위 좁히기는 설정 변경이 아니라 이동입니다.
• 정말 넓게 봐야 할 때 위로 올라가기. "이것에 관해 전에 쓴 적 있나?"는 루트에서 물어야 하는 질문이고, 루트에서 묻는 것이 그 방법입니다.

유스케이스 세 개가 전체 흐름을 보여줍니다. 폴더를 검색 가능한 인덱스로 만들기가 시작이고, 데이터 파일에 질문하기는 같은 검색을 스프레드시트와 내보내기 파일에 적용한 것이며, 예전에 쓴 내 초안 찾기는 어디에 뒀는지 기억나지 않아 일부러 넓히는 경우입니다.

이 중 무엇도 모델을 더 똑똑하게 만들지 않습니다. 질문을 더 쉽게 만들 뿐입니다. 그리고 수천 개 중 문서 하나를 찾는 일에서는, 망가져 있던 쪽이 사실 그 절반이었습니다.

블로그 글 더 보기