RAG를 직접 지을까, 빌릴까 — 자체 벡터 DB 파이프라인과 NotebookLM 백엔드의 트레이드오프

▶ 동영상 개요 — RAG 직접 짓기 vs 빌리기 (Build vs Borrow)

이 글의 논점을 5분 24초로 정리한 영상 요약 — NotebookLM 동영상 개요로 생성

나는 개인 지식 노트를 약 17,000개의 청크(검색하기 좋게 잘게 나눈 문서 조각)로 인덱싱한 RAG(Retrieval-Augmented Generation — 질문과 관련된 문서를 검색해 프롬프트에 끼워 넣고 LLM이 답하게 하는 패턴) 시스템을 직접 지어서 운영하고 있다. 벡터 DB, 로컬 GPU 임베딩, 재랭킹까지 갖춘 구성이다. 그런데 최근 NotebookLM을 에이전트에 연결해 주는 오픈소스(notebooklm-mcp-cli)를 분석하다가 불편한 질문과 마주쳤다. "내가 몇 달에 걸쳐 지은 이 파이프라인, NotebookLM에 문서를 올리는 것으로 대체되나?" 소스 기반 인용 Q&A라는 결과물만 보면 두 방식은 놀랍도록 비슷하다. 이 글은 그 질문을 정면으로 따져본 기록이다 — 직접 짓기(build)와 빌리기(borrow)의 구조를 나란히 놓고, 어떤 조건에서 어느 쪽이 이기는지.

직접 짓는 쪽의 구조 — 모든 단계가 내 손에

▲ 인덱싱 흐름

"개인 문서 저장소"에서 출발해 문서를 잘게 나누고(청킹), 각 조각에 원문 맥락을 덧붙인 뒤, 로컬 GPU의 임베딩 모델로 벡터화해 Qdrant(오픈소스 벡터 데이터베이스 — 문서 조각을 숫자 벡터로 저장하고 의미가 비슷한 것을 찾아 주는 저장소)에 쌓는 흐름이다. 이렇게 쌓인 청크가 현재 약 17,000개다. 문서가 추가·수정될 때마다 이 파이프라인이 다시 돌아 인덱스를 최신으로 유지한다 — 이 동기화 자체도 직접 짓는 쪽의 몫이다.

▲ 검색·답변 흐름

"질문"이 들어오면 앞서 쌓아 둔 벡터 DB에서 의미가 가까운 조각을 찾고, 시간 감쇠(오래된 문서의 점수를 깎는 가중치)와 재랭킹(검색 결과를 LLM이 다시 정렬)을 거쳐 답을 만든다. 두 흐름을 관통하는 이 구조의 본질은 모든 상자가 교체·튜닝 가능한 부품이라는 것이다. 검색 품질이 나쁘면 청킹 전략을 바꾸고, 최신 노트가 안 잡히면 감쇠 곡선을 조정한다. 대신 그 대가로 이 상자들 전부를 내가 만들었고, 내가 고쳐야 한다.

빌리는 쪽의 구조 — 두 상자만 남는다

다이어그램 설명. "문서 업로드"와 "질문" 두 입력만 있으면 "소스 기반 답변 + 구절 단위 인용"이 나온다. 가운데 "내부 인덱싱" 상자가 앞 다이어그램의 청킹·임베딩·벡터 DB·재랭킹 네 상자를 통째로 삼킨 형태다 — 그리고 그 상자는 블랙박스다. 어떤 임베딩 모델을 쓰는지, 청킹을 어떻게 하는지 알 수 없고 바꿀 수도 없다. 주목할 점은 인용 품질이다. NotebookLM의 인용은 문서 단위가 아니라 구절(passage) 단위로 달린다 — 답변의 각 문장이 어느 소스의 어느 대목에서 왔는지까지 짚어 준다. 직접 지은 파이프라인에서 이 수준의 인용 매핑을 재현하려면 상당한 추가 작업이 필요하다. 함정은 반대쪽에 있다: 내부가 블랙박스이므로 검색이 이상하게 동작해도 원인을 진단할 방법이 없다.

여섯 개의 축으로 비교하면

두 구조를 같은 축에 놓고 비교하면 이렇게 정리된다. 표의 각 행은 내가 실제로 두 방식을 오가며 부딪힌 지점들이다.

축	직접 짓기 (자체 파이프라인)	빌리기 (NotebookLM 백엔드)
초기 비용	수 주~수 개월 (설계·구축·평가)	수 분 (업로드 + MCP 연결)
운영 비용	GPU 전력·유지보수·인덱스 동기화	0원 (무료 티어) / 유료 티어 구독료
데이터 주권	문서가 내 서버 밖으로 안 나감	문서 전체가 Google 서버로 업로드됨
튜닝 가능성	청킹·임베딩·재랭킹 전 단계 조정 가능	불가 (블랙박스)
용량·쿼터	하드웨어가 허용하는 만큼	노트북당 소스 50개, 무료 티어 하루 약 50회 질의
지속성 리스크	내 코드 — 내가 관리하는 만큼 유지	비공식 API — 플랫폼 정책 변경 시 하루아침에 단절 가능

여섯 축을 관통하는 패턴이 보인다. 빌리기는 '시작'의 모든 축에서 이기고, 직접 짓기는 '지속'의 모든 축에서 이긴다. 초기 비용과 운영 비용에서 NotebookLM은 압도적이다 — 몇 달 걸려 지은 파이프라인과 비슷한 결과물을 몇 분 만에 얻는다. 그러나 데이터 주권, 튜닝, 지속성으로 갈수록 형세가 뒤집힌다. 특히 마지막 행이 결정적이다. NotebookLM 연동은 공식 API가 아니라 리버스 엔지니어링된 내부 프로토콜에 기대고 있어서, 플랫폼이 인증 방식을 조이면 파이프라인 전체가 예고 없이 멈출 수 있다.

결정 기준 — 무엇이 나를 묶는지부터 본다

다이어그램 설명. 결정 트리는 세 개의 질문을 차례로 던진다. 첫째 "이 데이터, 외부 서버에 올려도 되는가" — 여기서 아니오면 나머지 질문은 볼 필요도 없이 직접 짓기다. 개인 일기, 가족 기록, 회사 기밀이 여기 해당한다. 둘째 "검색 품질을 직접 튜닝해야 하는가" — 도메인 특화 용어가 많거나 문서가 수천 건을 넘으면 블랙박스로는 한계가 온다. 셋째 "끊겨도 되는 워크플로우인가" — 비공식 API의 지속성 리스크를 감당할 수 있는 용도인지 묻는 것이다. 이 순서가 중요한 이유는 세 질문의 비중이 다르기 때문이다. 첫 질문은 되돌릴 수 없고(한번 올라간 데이터는 회수를 보장받기 어렵다), 둘째·셋째는 나중에 갈아탈 수 있다. 놓치기 쉬운 경로가 하나 있다: "빌리기 우세"에 도달했더라도 NotebookLM만의 고유 기능 — 팟캐스트·영상·인포그래픽 생성 — 이 목적이라면 애초에 대체재가 없으므로 비교 자체가 무의미해진다. 그때는 빌리는 게 아니라 그냥 그 기능을 쓰는 것이다.

내 결론 — 하이브리드가 답이었다

결정 트리를 내 상황에 적용하면 답이 갈린다. 개인 지식 노트는 사적 데이터라 첫 질문에서 직접 짓기로 확정된다 — 지금의 자체 파이프라인은 유지한다. 반면 공개 기술 문서를 조사해서 팟캐스트로 정리하는 워크플로우는 셋째 질문까지 통과해서 NotebookLM을 빌리는 쪽이 낫다. 애초에 팟캐스트 생성은 자체 파이프라인로는 불가능하기도 하다. 결국 "직접 지을까, 빌릴까"는 양자택일이 아니라 데이터의 민감도와 워크플로우의 임계성에 따라 문서 집합별로 다르게 내리는 결정이었다.

정리 — 비교의 축은 기능이 아니라 구속이다

두 방식의 기능 목록을 비교하면 답이 안 나온다. 결과물이 너무 비슷하기 때문이다. 답을 가른 것은 기능이 아니라 구속 — 데이터가 어디에 묶이는지, 품질의 통제권이 누구에게 있는지, 워크플로우의 생사가 누구 손에 달렸는지였다.

---

참고한 공개 자료:

• notebooklm-mcp-cli GitHub 저장소 — https://github.com/jacob-bd/notebooklm-mcp-cli
• Google NotebookLM 공식 사이트 — https://notebooklm.google.com/
• Qdrant 공식 문서 — https://qdrant.tech/documentation/
• Anthropic, Contextual Retrieval 소개 글 — https://www.anthropic.com/news/contextual-retrieval

---

이 글은 생성형 AI의 도움을 받아 작성되었습니다. 원본 자료를 기반으로 AI가 초안을 생성하고, 작성자가 검토·편집하였습니다.