기획자를 내 개발 루프에서 빼버렸다
NotebookLM MCP로 연결하면 Claude가 정책을 직접 읽는다. 슬랙 기다리던 반나절이 30분으로 줄었다.
새 기능 개발이 시작되면 항상 같은 패턴이 반복됐다.
기획서를 받는다. 읽는다. 처음엔 이해한 것 같다. 그런데 조금 더 들어가면 모호한 부분이 생긴다. 이 정책이 저 케이스에서는 어떻게 적용되는지, 이 예외 처리는 어떤 의도인지, 관련 문서가 또 어딘가에 있는 건지. 결국 기획자한테 슬랙을 보낸다. 기획자가 답이 오기를 기다린다. 답이 오면 다시 기획서를 읽는다.
이 루프가 개발 시작 전에 서너 번은 반복됐다.
기획자는 바쁘다
기획자에게 물어보는 게 나쁜 건 아니다. 오히려 확인하지 않고 진행하다 방향이 어긋나는 게 더 나쁘다. 그런데 현실적으로, 기획자도 동시에 여러 개의 스프린트를 관리하고 있다. 내 질문이 최우선이 아닐 때가 많다.
게다가 내 질문이 엄밀하지 않으면 답도 엄밀하지 않다. "이 케이스에서 어떻게 해요?"라고 물으면 "그건 기존 정책 따라가면 돼요"라는 답이 오기도 한다. 기존 정책을 또 찾아야 한다.
결국 개발 시작까지 걸리는 시간이 늘어난다. 정보를 모으는 데 시간이 가고, 정보 조각들을 연결하는 데 또 시간이 간다.
NotebookLM을 알게 됐다
Google NotebookLM은 문서를 소스로 업로드하면, 그 문서를 기반으로 질문에 답해주는 AI다. PDF, 구글 독스, 텍스트 파일 등을 올리면 된다. 일반적인 LLM과 다른 점은 자기가 학습한 데이터가 아니라, 내가 올린 문서에 근거해서 답한다는 것이다. 환각이 줄고, 출처도 보여준다.
처음 써봤을 때는 단순히 "문서 읽어주는 AI" 정도로 생각했다. 그런데 써보니 용도가 달랐다.
기획서, 정책 문서, API 스펙, 팀 위키를 NotebookLM 노트북에 올려두면 그게 살아있는 지식 베이스가 된다. 모르는 게 생기면 기획자한테 슬랙 보내는 대신 NotebookLM한테 물어볼 수 있다.
Q: 사용자가 탈퇴한 경우 해당 사용자가 작성한 댓글은 어떻게 처리되나요?
A: [기획서 3페이지 정책 섹션 기반] 탈퇴 사용자의 댓글은 즉시 삭제되지 않고
"알 수 없는 사용자"로 표시됩니다. 단, 운영자가 개인정보 삭제 요청을 처리하면
댓글 내용도 마스킹됩니다. (출처: 정책 정의서 v2.3 - 3.2 탈퇴 처리)
기획자에게 물어봤을 때보다 답이 더 구체적이고 빠르다. 기획자도 결국 같은 문서를 다시 찾아보고 답하기 때문이다.
MCP로 연결하면 차원이 달라진다
여기서 한 단계 더 나아갔다. NotebookLM에는 MCP(Model Context Protocol) 서버가 있다. Claude Code에 연결하면, 내가 개발 작업을 하면서 Claude가 직접 NotebookLM에 질문하는 것이 가능해진다.
기존 흐름은 이랬다.
나: 기획서 읽기
나: 모르는 거 발견
나: 기획자 슬랙
나: 기다림
나: 답 수신
나: 다시 기획서로
나: 개발 시작
MCP 연결 후 흐름은 이렇다.
나: Claude Code에 작업 지시
Claude: NotebookLM에 관련 정책 질의 (자동)
Claude: 정책 기반으로 플래닝
Claude: 구현 시작
내가 루프에서 빠진다. Claude가 모르는 게 생기면 NotebookLM에 직접 물어보고, 그 답을 컨텍스트로 삼아 더 정확하게 작업한다.
실제로 어떻게 쓰고 있나
작업을 시작할 때 프롬프트에 이런 식으로 지시한다.
댓글 신고 기능을 구현해야 해.
작업 전에 NotebookLM 노트북에서 다음을 먼저 확인해줘:
- 신고 처리 정책 (임계값, 자동 블라인드 조건)
- 신고한 사용자에게 돌아가는 피드백 정책
- 중복 신고 처리 방식
그 내용을 바탕으로 구현 계획을 먼저 세우고, 내가 확인하면 개발해줘.
Claude는 NotebookLM에 질의하고, 정책 내용을 실제로 읽어온 다음 이런 식으로 돌아온다.
NotebookLM 확인 결과:
1. 신고 처리 정책
- 동일 콘텐츠 신고 3회 이상: 자동 블라인드
- 신고 유형: 스팸/혐오/허위정보/기타 (정책서 4.1절)
2. 신고자 피드백
- 신고 접수 즉시 "신고가 접수되었습니다" 표시
- 처리 결과는 알림 없음 (4.3절 - 프라이버시 보호 이유)
3. 중복 신고
- 동일 사용자가 동일 콘텐츠를 다시 신고하면 무시 처리
- 횟수에 포함 안 됨 (4.2절)
---
구현 계획:
- ReportService.createReport(): 중복 체크 → 횟수 증가 → 임계값 초과 시 블라인드 트리거
- 블라인드 처리는 별도 ContentModerationService로 분리 권장
(정책 변경 시 신고 로직 건드리지 않게)
...
기획서를 다시 뒤지거나, 기획자한테 물어볼 필요가 없다. 이미 정책을 읽고 온 Claude와 대화하면 된다.
탄탄한 정책 기반 위에서 플래닝
이게 중요하다. Claude는 기본적으로 코드를 잘 짠다. 하지만 비즈니스 정책을 모르면 틀린 방향으로 잘 짠다.
중복 신고를 횟수에 포함시켜버린다거나, 신고자한테 처리 결과 알림을 보내버린다거나. 코드 자체는 문제가 없는데, 정책이 틀렸다. 그러면 QA에서 걸리거나, 최악의 경우 배포 후에 발견된다.
NotebookLM을 통해 정책을 먼저 읽고 시작하면, 이런 실수가 거의 없어진다. Claude가 구현 계획을 세울 때 이미 정책을 알고 있으니까.
QA 사이클이 줄고, 수정 비용이 줄고, 기획자와의 핑퐁이 줄어든다.
지식 베이스 세팅이 핵심이다
이 워크플로우가 잘 돌아가려면 NotebookLM 노트북이 잘 세팅되어 있어야 한다. 내가 올려두는 문서들은 이렇다.
| 문서 유형 | 용도 |
|---|---|
| 기능 기획서 | 정책, 예외 케이스, 비즈니스 로직 |
| API 스펙 문서 | 외부 연동 시 규격 확인 |
최소한 기획서와 API 스펙만 올려도 충분히 돌아간다. 나머지는 쌓이면서 노트북이 점점 두꺼워지는 것들이다.
정리
기획서를 읽으면서 모르는 게 생기는 건 자연스러운 일이다. 문서가 아무리 잘 쓰여도, 개발자 입장에서 생기는 엣지 케이스 질문까지 모두 커버하긴 어렵다.
차이는 그 질문을 어디서 해결하느냐다.
기획자 슬랙 → 대기 → 답변 루프를 NotebookLM으로 단락시킬 수 있다. 더 나아가 MCP로 Claude에 연결하면, Claude가 직접 정책을 읽고 더 정확하게 구현 계획을 세운다. 정책을 이미 알고 짜는 코드와, 정책을 모르고 짜는 코드는 품질이 다르다.
업무 흐름이 10배 빨라진다는 말이 과장처럼 들릴 수 있다. 하지만 실제로 정보를 모으는 데 쓰던 시간을 계산해보면 과장이 아니다. 개발 시작 전 기획 이해에 반나절이 걸리던 게 30분으로 줄었다.
세팅 한 번 해두면, 그다음부터는 그냥 돌아간다.