API 없는 최고의 RAG — NotebookLM을 코딩 에이전트의 외부 장기로 이식하기

▶ 동영상 개요 — API 없는 최고의 RAG

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

개인 서버의 작업 대부분을 코딩 에이전트로 자동화해 두고 나서도, 끝까지 손으로 하던 일이 하나 있었다. 리서치 자료를 NotebookLM에 넣고, 팟캐스트를 생성하고, 결과를 내려받는 일이다. Google NotebookLM(2025년 말 Gemini Notebook으로 리브랜딩)은 업로드한 소스 안에서만 답을 만드는 'grounded AI' 방식의 리서치 도구인데 — 이 강력한 기능 전부가 웹 UI 안에만 있다. 공식 API가 없다. 그러다 GitHub에서 이 벽을 뚫은 오픈소스를 발견했다. jacob-bd의 notebooklm-mcp-cli — 약 3만 4천 줄짜리 Python 프로젝트로, NotebookLM을 CLI와 MCP 서버 두 가지 인터페이스로 노출한다. 이 글은 그 코드를 클론해 뜯어보며 정리한 기록의 1부다: API가 없는 서비스를 에이전트의 '외부 장기'로 이식하는 구조에 대한 이야기다.

NotebookLM에 잠긴 가치 — 왜 다들 API를 원하나

NotebookLM이 다른 챗봇과 다른 지점은 답변의 재료를 제한한다는 것이다. 사용자가 올린 소스(PDF, 웹 URL, YouTube, Google Docs 등)만 근거로 답하고, 모든 문장에 어느 소스의 어느 구절에서 왔는지 인용(citation)을 단다. RAG(Retrieval-Augmented Generation — 질문과 관련된 문서를 검색해 프롬프트에 끼워 넣고 답하게 하는 패턴)를 직접 구축해 본 사람이라면 이게 얼마나 손이 많이 가는 결과물인지 안다. 청킹, 임베딩, 벡터 검색, 재랭킹, 인용 매핑까지 — NotebookLM은 그걸 완성품으로, 무료 티어로 제공한다.

여기에 생성 기능이 얹힌다. 소스를 재료로 2인 대화 팟캐스트(Audio Overview), 해설 영상, 인포그래픽, 슬라이드, 퀴즈, 플래시카드를 만들어 준다. 웹을 뒤져 소스를 발굴해 주는 Deep Research도 있다. 문제는 이 모든 것이 사람이 마우스로 클릭해야만 작동한다는 것 — 스크립트로 호출할 공식적인 방법이 없다. 자동화 파이프라인에 편입할 수도, 에이전트에게 시킬 수도 없다.

이식 수술의 구조 — 비공식 클라이언트 + MCP

이 프로젝트가 벽을 뚫은 방법은 리버스 엔지니어링이다. NotebookLM 웹앱이 자체 서버와 통신할 때 쓰는 내부 RPC 프로토콜(batchexecute — Google 웹앱들이 공통으로 쓰는 배치 원격 호출 방식)을 브라우저 개발자 도구로 관찰해서, 같은 요청을 Python 코드로 재현했다. 인증은 브라우저에서 추출한 Google 쿠키를 재사용한다. 그 위에 두 개의 얼굴을 얹었다: 사람과 스크립트를 위한 CLI(nlm), 그리고 AI 에이전트를 위한 MCP 서버다.

다이어그램 설명. 핵심 메시지는 "MCP 서버" 상자가 번역기 역할을 한다는 것이다. "코딩 에이전트"와 "사람 / 셸 스크립트"가 각자의 방식(MCP 도구 호출, CLI 명령)으로 요청을 보내면, 이 번역기가 NotebookLM 웹앱의 내부 통신 방식으로 바꿔 "NotebookLM 서버"에 전달하고, 돌아온 답변·산출물을 구조화된 형태로 되돌려 준다. MCP(Model Context Protocol — AI 모델과 외부 시스템을 잇는 표준 규격으로, 흔히 'AI의 USB-C 포트'에 비유된다)를 쓰기 때문에 특정 에이전트에 종속되지 않고, 이 규격을 지원하는 도구라면 무엇이든 연결된다. 놓치기 쉬운 전제는 인증이다 — 이 구조 전체가 "브라우저에서 추출한 개인 쿠키"라는 가는 줄에 매달려 있다는 점은 3부에서 자세히 다룬다.

역할 분담 — 에이전트는 지휘, NotebookLM은 연주

이 도구를 붙이고 나면 에이전트와 NotebookLM 사이에 자연스러운 분업이 생긴다. 흥미로운 건 이 분업이 서로의 약점을 정확히 메운다는 점이다. 코딩 에이전트는 오케스트레이션(작업을 쪼개고 순서를 정하고 결과를 검증하는 일)에 강하지만, 자체 지식으로 답할 때 환각 위험이 있고 팟캐스트나 영상 같은 미디어는 아예 만들지 못한다. NotebookLM은 정반대다 — 스스로 작업을 계획하지 못하지만, 소스에 묶인 인용 달린 답변과 미디어 생성이라는 고유 능력이 있다.

다이어그램 설명. "작업 지시"에서 출발해 에이전트가 소스를 수집·구성하는 단계, NotebookLM이 근거 기반으로 합성하는 단계, 다시 에이전트가 결과를 회수하는 단계로 이어지는 흐름이다. 신체에 비유하면 에이전트가 뇌라면 NotebookLM은 이식된 외부 장기다 — 뇌가 직접 소화를 하지 않듯, 에이전트는 "소스에 근거한 답을 만들라"는 일 자체는 통째로 외주를 준다. 이 패턴의 가치는 환각 억제에 있다. 에이전트가 자기 기억으로 답을 지어내는 대신, 검증 가능한 인용이 달린 답을 받아서 쓰게 되기 때문이다. 함정도 있다: NotebookLM 무료 티어는 하루 약 50회 질의 제한이 있어서(레포 README 기준), 에이전트가 루프 안에서 무한정 질의하도록 두면 반나절 만에 쿼터가 바닥난다.

에이전트를 위한 인터페이스 설계 — 도구 43개의 다이어트

이 프로젝트에서 가장 배울 게 많았던 부분은 MCP 도구 설계였다. NotebookLM의 기능을 전부 노출하면 도구가 43개다. 그런데 MCP 도구는 각각의 이름·설명·파라미터 스키마가 에이전트의 컨텍스트(LLM이 한 번에 읽는 작업 기억)에 통째로 올라간다. 도구가 많을수록 에이전트는 느려지고 헷갈린다. 이 프로젝트는 두 가지로 대응한다.

# 1단: 통합(consolidated) 도구 — 유사 기능을 파라미터로 묶는다
# 팟캐스트·영상·슬라이드·퀴즈… 생성 도구를 따로 만들지 않고 하나로:
studio_create(artifact_type="audio")      # 팟캐스트
studio_create(artifact_type="video")      # 해설 영상
studio_create(artifact_type="flashcards") # 플래시카드

# 2단: 도구 그룹 게이팅 — 환경변수로 안 쓰는 그룹을 통째로 숨긴다
# 조회 전용 에이전트라면 생성·공유·삭제 계열을 노출할 이유가 없다
NOTEBOOKLM_DISABLED_GROUPS="studio,sharing,automation"

코드 설명. 통합 도구 패턴은 "팟캐스트 생성", "영상 생성"처럼 형태만 다른 기능 아홉 개를 studio_create 하나에 artifact_type 파라미터로 밀어 넣는다. 도구 개수가 줄어 컨텍스트가 가벼워지고, 에이전트 입장에서는 "생성은 저 도구 하나"라는 단순한 규칙만 기억하면 된다. 그룹 게이팅은 반대 방향의 안전장치다 — 읽기 전용으로 쓰고 싶은 사용자가 삭제·공유 도구를 아예 에이전트의 시야에서 치울 수 있다. 트레이드오프도 분명하다: 통합 도구는 파라미터 조합이 복잡해져서, 어떤 인자가 어떤 타입에서만 유효한지를 문서로 보강해야 한다. 실제로 이 레포의 이슈 트래커에는 특정 조합에서만 실패하는 버그 리포트가 여럿 있다.

온보딩까지가 제품이다 — setup, skill, doctor

기능이 완성돼도 마지막 관문이 남는다. 에이전트 생태계의 파편화다. Claude Code, Cursor, Gemini CLI, Codex 등 도구마다 MCP 서버를 등록하는 설정 파일 위치와 포맷이 전부 다르다. 이 프로젝트는 nlm setup add claude-code 한 줄로 10개 AI 도구의 설정을 자동으로 써 주고, nlm skill install로 에이전트에게 사용법을 가르치는 스킬 문서(도구 사용 규칙을 담은 마크다운)를 설치하며, nlm doctor로 설치·인증·브라우저 상태를 진단한다. 도구의 사용자가 사람에서 에이전트로 바뀌면, 문서·설치·진단의 형태도 에이전트 중심으로 다시 설계해야 한다는 걸 보여주는 사례다.

정리 — 잠긴 가치를 여는 구조

NotebookLM이라는 "API 없는 최고급 RAG"를 에이전트에 이식하는 구조는 세 겹이다: 내부 프로토콜을 재현하는 비공식 클라이언트, 그것을 에이전트 규격으로 노출하는 MCP 서버, 그리고 파편화된 생태계에 꽂아 주는 온보딩 자동화다. 한 줄로 남기면 — 에이전트 시대의 통합 대상은 'API가 있는 서비스'가 아니라 '가치가 있는 서비스'다. API가 없다는 건 이제 통합의 장벽이 아니라 비용일 뿐이다.

---

참고한 공개 자료:

• notebooklm-mcp-cli GitHub 저장소 — https://github.com/jacob-bd/notebooklm-mcp-cli
• 전신 프로젝트 notebooklm-cli — https://github.com/jacob-bd/notebooklm-cli
• Google NotebookLM 공식 사이트 — https://notebooklm.google.com/
• Model Context Protocol 공식 문서 — https://modelcontextprotocol.io/

---

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