얼마 전에 속초로 훌쩍 다녀왔어요. 딱히 거창한 계획이 있었던 건 아니고요. 그냥 동해 바다 좀 보고, 조용한 카페에 앉아서 커피 마시고, 머리 좀 식히고 싶었거든요. 창가 자리에서 따뜻한 아메리카노 한 잔 시켜놓고 멍하니 파도 보고 있는데, 갑자기 슬랙이 울리더라고요. 아시죠. 개발자 휴식을 깨우는 그 특유의 불길한 알림음이요.
내용을 보니 운영 중인 레거시 시스템의 결제 모듈을 급하게 확인해야 하는 상황이었어요. 더 난감했던 건 관련 설계 문서가 제대로 정리된 게 아니라, 누가 언제 만들었는지도 가물가물한 300쪽짜리 PDF 하나가 전부였다는 겁니다. 예전 같았으면 바다를 등지고 노트북 화면만 노려보면서 한숨부터 쉬었을 거예요. 그런데 이번에는 제가 요즘 꽤 자주 쓰는 도구를 꺼냈습니다. 바로 Google의 NotebookLM이었죠.
솔직히 말하면, 이 도구 덕분에 그날 바다도 보고 일도 처리했습니다. 완벽한 휴가는 아니었지만, 예전처럼 휴가지에서 완전히 일에 잡아먹히지는 않았어요. 그래서 오늘은 제가 실제로 NotebookLM으로 레거시 문서를 다루는 방식을 조금 편하게 풀어보려고 합니다. 개발자 입장에서 써보니 좋았던 점, 조심해야 할 점, 그리고 바이브 코딩할 때 꽤 쓸 만했던 프롬프트까지 같이 이야기해볼게요.
NotebookLM에 문서를 넣기 전에, 저는 꼭 한 번 정리부터 합니다
사실 AI 도구가 아무리 좋아도, 엉망인 자료를 그대로 넣으면 결과도 어딘가 엉성하게 나옵니다. 이건 예전부터 개발자들이 입버릇처럼 말하던 GIGO, 그러니까 Garbage In, Garbage Out 그대로예요. 쓰레기를 넣으면 쓰레기가 나온다. 좀 냉정하지만 맞는 말입니다.
특히 오래된 사내 위키, 퇴사한 선배가 남긴 API 문서, 버전이 뒤섞인 PDF 같은 걸 그대로 올리면 NotebookLM도 가끔 이상한 결론을 냅니다. 문서 안에서는 v1 API 이야기를 하다가, 다음 장에서는 v2 기준으로 설명하고, 표에는 또 운영 환경과 다른 값이 들어가 있는 경우가 있거든요. 레거시 문서에서는 이런 일이 정말 흔합니다. 뭐랄까, 문서라기보다 고고학 발굴 현장에 가깝죠.
그래서 저는 NotebookLM에 문서를 바로 던지지 않습니다. 먼저 로컬에서 문서를 도메인별로 나누고, 민감한 정보는 지우고, 너무 낡은 파일은 따로 표시해 둡니다. 제가 실제로 쓰는 방식은 대충 이런 느낌이에요.
legacy-doc-vault/
├── 01_database_schema/
│ ├── old_users_table.sql
│ └── payment_history_ddl.txt
├── 02_api_specs/
│ ├── v1_deprecated_api.md
│ └── partner_integration_v2.pdf
└── 03_troubleshoot_logs/
└── memory_leak_issue_2023.txt
이렇게만 해도 나중에 질문할 때 훨씬 편해집니다. 예를 들어 “결제 API 기준으로 설명해줘”라고 묻는 것보다, “02_api_specs의 partner_integration_v2.pdf 기준으로 설명해줘”라고 묻는 게 훨씬 안정적이거든요. AI도 사람처럼 기준을 명확히 잡아줘야 덜 헤맵니다.
그리고 저는 문서를 올리기 전에 민감한 값은 간단한 스크립트로 한 번 걸러냅니다. 내부 IP, API 키, DB 접속 정보 같은 건 습관적으로 마스킹해요. “구글이 모델 학습에 안 쓴다는데 괜찮지 않나?”라고 생각할 수도 있는데, 저는 회사 데이터 다룰 때는 조금 보수적인 편이 낫다고 봅니다. 나중에 후회하는 것보다 처음에 5분 더 쓰는 게 낫더라고요.
import os
import re
def clean_sensitive_data(file_path):
with open(file_path, 'r', encoding='utf-8') as f:
content = f.read()
# 내부 IP 주소 패턴 마스킹 예시
ip_pattern = r'\b(?:192\.168|10\.\d{1,3})\.\d{1,3}\.\d{1,3}\b'
cleaned_content = re.sub(ip_pattern, '[MASKED_INTERNAL_IP]', content)
# API 키 패턴 마스킹 예시
api_key_pattern = r'(?i)api_key\s*=\s*["\'][a-zA-Z0-9_\-]{20,}["\']'
cleaned_content = re.sub(api_key_pattern, 'api_key = "MASKED_SECRET"', cleaned_content)
with open(file_path, 'w', encoding='utf-8') as f:
f.write(cleaned_content)
print(f"Processed: {file_path}")
for root, dirs, files in os.walk('./legacy-doc-vault'):
for file in files:
if file.endswith(('.txt', '.md', '.sql')):
clean_sensitive_data(os.path.join(root, file))
코드 자체는 별거 없습니다. 정교한 보안 도구도 아니고요. 그래도 이런 전처리 과정을 한 번 거친 뒤 NotebookLM에 넣으면 마음이 훨씬 편합니다. 그리고 이상하게도 답변 품질도 좋아져요. 불필요한 노이즈가 줄어들어서 그런지, 질문에 대한 답이 더 또렷하게 나옵니다.
저는 속초 카페에서도 이 과정을 했어요. 커피는 5천 원대였고, 바다 보이는 자리라 그런지 마음은 꽤 평화로웠는데, 터미널에서 스크립트 돌리는 제 모습은 별로 평화롭지 않았습니다. 그래도 한 번 정리해두니 그다음부터는 일이 빨라졌어요. 이게 은근히 큽니다.
ChatGPT나 Claude도 좋은데, 문서 분석은 NotebookLM이 편할 때가 있습니다
요즘 ChatGPT, Claude, Gemini 같은 도구들이 워낙 좋아졌잖아요. 저도 당연히 많이 씁니다. 코드 초안 잡을 때, 에러 메시지 분석할 때, 테스트 케이스 아이디어 뽑을 때는 정말 편해요. 그런데 오래된 문서나 사내 자료를 기반으로 뭔가를 확인해야 할 때는 NotebookLM이 유독 마음이 놓이는 순간이 있습니다.
가장 큰 차이는 출처입니다. 일반 LLM은 똑똑하긴 한데, 가끔 너무 자신 있게 말합니다. 문제는 그 자신감이 근거와 항상 같이 오지는 않는다는 거예요. 반면 NotebookLM은 제가 올린 자료를 중심으로 답을 만들고, 답변 옆에 원문 위치를 보여줍니다. 이게 실무에서는 엄청난 차이를 만듭니다.
| 비교 항목 | 일반 LLM, 예를 들면 ChatGPT나 Claude | Google NotebookLM |
|---|---|---|
| 답변의 기준 | 모델이 알고 있는 일반 지식과 사용자가 준 맥락이 섞여 나올 수 있음 | 업로드한 문서를 중심으로 답변해서 근거 확인이 쉬움 |
| 출처 확인 | 출처를 직접 다시 찾아야 하는 경우가 많음 | 답변마다 원문 위치를 클릭해서 바로 확인할 수 있음 |
| 대용량 문서 처리 | 대화가 길어지면 앞의 맥락이 흐려지는 느낌이 있음 | 노트북 단위로 여러 소스를 묶어두고 반복해서 질문하기 좋음 |
| 실무 설득력 | 답은 빠르지만 “그 근거가 어디야?”라는 질문에 약할 때가 있음 | 원문 근거를 바로 보여줄 수 있어서 리뷰나 보고에 유리함 |
제가 느끼기엔 일반 LLM은 다방면으로 말 잘하는 똑똑한 동료 같고, NotebookLM은 제가 건네준 자료만 조용히 파고드는 성실한 연구원 같습니다. 둘 다 좋지만 역할이 달라요. 특히 레거시 시스템처럼 “정답이 인터넷에 있는 게 아니라 우리 회사 문서 어딘가에 있는” 상황에서는 NotebookLM 쪽이 더 든든합니다.
실제로 그날 저는 결제 모듈 문서를 넣고 이렇게 물어봤습니다. “사용자가 결제를 요청한 뒤 payment_history 테이블의 status 값이 어떤 순서로 바뀌는지 문서 근거와 함께 알려줘.” 답변을 보니 승인 요청, 외부 PG 응답, 내부 상태 업데이트, 실패 재시도 흐름이 한눈에 정리됐고, 옆에 원문 위치가 붙어 있더라고요. 이게 참 좋았습니다. 나중에 팀 채널에 공유할 때도 “AI가 그랬어요”가 아니라 “문서 몇 페이지 기준으로 보면 이렇습니다”라고 말할 수 있으니까요.
제가 자주 쓰는 NotebookLM 프롬프트 방식입니다
NotebookLM에 그냥 “이 문서 설명해줘”라고 물어봐도 어느 정도 답은 나옵니다. 그런데 실무에서 정말 쓸 만한 답을 얻으려면 질문을 조금 더 구체적으로 던지는 게 좋아요. 저는 이걸 거창하게 프롬프트 엔지니어링이라고 부르기보다는, 그냥 “질문 예의 차리기” 정도로 생각합니다. 사람한테도 대충 물으면 대충 답하잖아요. AI도 비슷합니다.
아키텍처를 거꾸로 추적할 때 쓰는 질문
레거시 시스템은 보통 코드보다 문서가 늦고, 문서보다 운영 이력이 더 진실에 가까울 때가 많습니다. 그래서 저는 데이터베이스 스키마, API 문서, 장애 대응 로그를 같이 넣고 관계를 맞춰보는 식으로 질문합니다.
제시된 데이터베이스 스키마 01_database_schema와 결제 API 명세 02_api_specs를 함께 참고해서, 사용자가 결제를 요청했을 때 데이터베이스 테이블에서 발생하는 상태 변화 흐름을 순서대로 정리해줘. 문서에 명확히 쓰여 있지 않은 추정이나 누락된 단계가 있다면 반드시 '주의: 명세 미기재 사항'이라는 제목으로 따로 구분해줘. 답변에는 가능한 한 원문 근거를 함께 표시해줘.
이 프롬프트에서 중요한 건 “문서에 없는 내용은 없는 내용이라고 말해줘”라고 못 박는 겁니다. AI 도구는 빈칸을 채우려는 습관이 있습니다. 물론 그게 장점일 때도 있는데, 운영 시스템 분석에서는 위험할 때가 많아요. 모르는 건 모른다고 해야 합니다. 그래야 사람이 판단할 수 있거든요.
버전이 섞인 문서를 다룰 때 쓰는 질문
오래된 문서에는 v1, v2, hotfix, deprecated 같은 단어가 뒤섞여 있습니다. 심지어 파일명은 v2인데 내용 중간에는 v1 기준 설명이 남아 있는 경우도 있어요. 이런 문서를 넣고 질문할 때는 기준 버전을 아주 노골적으로 박아두는 게 좋습니다.
partner_integration_v2.pdf를 기준 문서로 삼아서 답변해줘. v1_deprecated_api.md와 충돌하는 내용이 있다면 v2 문서를 우선으로 보고, 충돌 지점은 표로 따로 정리해줘. 운영 반영 시 위험해 보이는 항목이 있으면 개발자 관점에서 체크리스트로 만들어줘.
이런 식으로 물어보면 답변이 훨씬 실무적으로 바뀝니다. 단순 설명이 아니라 “어디가 충돌하는지”, “뭘 조심해야 하는지”, “내가 지금 어떤 순서로 봐야 하는지”가 나와요. 저는 이걸 리뷰 회의 전에 많이 씁니다. 회의 들어가기 전에 쟁점을 미리 뽑아두면, 괜히 1시간씩 문서 읽는 침묵의 시간이 줄어들거든요.
장애 로그와 문서를 같이 볼 때 쓰는 질문
장애 대응할 때는 공식 문서만 보면 부족합니다. 운영 로그, 과거 장애 리포트, 배포 이력까지 같이 봐야 감이 잡힐 때가 많아요. 이럴 때 NotebookLM에 troubleshoot 로그를 같이 넣어두면 꽤 쓸 만합니다.
03_troubleshoot_logs의 장애 기록과 02_api_specs의 결제 API 문서를 비교해서, 과거에 반복된 장애 패턴을 찾아줘. 단순 요약이 아니라 원인 후보, 재현 조건, 임시 대응, 근본 해결책으로 나누어 정리해줘. 근거가 부족한 내용은 추정이라고 표시해줘.
이 질문은 제가 꽤 자주 씁니다. 특히 메모리 누수, 타임아웃, 외부 API 지연처럼 원인이 한 번에 딱 떨어지지 않는 문제를 볼 때 도움이 됩니다. 물론 NotebookLM이 장애를 대신 해결해주지는 않습니다. 그래도 흩어진 기록을 한눈에 모아주는 역할은 잘해요. 개발자가 문제의 냄새를 맡을 수 있게 도와준다고 할까요.
바이브 코딩할 때 NotebookLM을 더 잘 쓰는 작은 요령
요즘 바이브 코딩이라는 말을 많이 쓰잖아요. 저는 이 말을 조금 조심해서 받아들이는 편입니다. AI에게 맡기면 뭐든 뚝딱 된다는 느낌으로 쓰면 위험하고, 반대로 너무 경계해서 아예 안 쓰는 것도 아깝습니다. 제 기준에서는 AI를 옆자리 동료처럼 두고, 내가 방향과 검증을 책임지는 방식이 제일 현실적입니다.
NotebookLM은 코드 생성보다는 문맥 정리에 강합니다. 그래서 저는 보통 이런 흐름으로 씁니다.
- 문서 업로드: API 명세, DB 스키마, 장애 로그, 운영 가이드를 도메인별로 묶어 넣습니다.
- 흐름 파악: 요청부터 DB 변경, 외부 시스템 호출까지 순서도를 뽑아봅니다.
- 불확실한 지점 표시: 문서에 없는 내용, 버전 충돌, 추정 사항을 따로 분리합니다.
- 코드 작성은 별도 LLM 활용: ChatGPT나 Claude에 구현 초안을 맡기되, NotebookLM에서 얻은 근거를 같이 제공합니다.
- 사람이 검증: 테스트 코드, 로그, 실제 운영 환경 값을 기준으로 다시 확인합니다.
여기서 핵심은 NotebookLM을 “정답 생성기”로 쓰지 않는 겁니다. 저는 이 도구를 맥락 정리 도구로 봅니다. 레거시 문서를 읽고, 충돌 지점을 찾고, 근거 있는 설명을 뽑아내는 데 쓰는 거죠. 실제 코드를 바꿀 때는 여전히 사람이 책임져야 합니다. 특히 결제, 인증, 개인정보, 정산 같은 도메인은 더더욱 그렇고요.
오디오 오버뷰는 생각보다 쓸 만합니다
NotebookLM에서 제가 은근히 좋아하는 기능이 하나 더 있습니다. 바로 Audio Overview입니다. 두 명의 진행자가 대화하듯이 문서 내용을 설명해주는 기능인데요. 처음에는 “이걸 내가 왜 듣지?” 싶었어요. 그런데 몇 번 써보니 묘하게 편합니다.
특히 영문 기술 문서나 긴 아키텍처 문서를 넣어두고 오디오로 만들어놓으면, 출퇴근길이나 산책할 때 라디오처럼 들을 수 있습니다. 저는 여행지에서 운전할 때도 가끔 틀어둡니다. 물론 한국어 문서나 한국어 음성 지원은 상황에 따라 아쉬운 부분이 있을 수 있지만, 영문 문서 정리용으로는 꽤 괜찮았어요.
이게 집중해서 정독하는 것과는 다른 맛이 있습니다. 책상 앞에 앉아 밑줄 치며 보는 건 아니지만, 큰 흐름이 귀에 들어와요. 나중에 문서를 다시 보면 “아, 이 부분이 그 얘기였구나” 하고 연결됩니다. 40대가 되니까 이런 식의 반복 노출이 은근히 도움이 됩니다. 예전처럼 새벽까지 눈 부릅뜨고 문서만 파는 체력이 안 나오거든요. 인정할 건 인정해야죠.
실무에서 조심해야 할 부분도 분명히 있습니다
좋은 도구라고 해서 아무렇게나 쓰면 안 됩니다. 특히 회사 문서를 다루는 순간부터는 개인 생산성보다 보안과 책임이 먼저예요. 저는 NotebookLM을 쓰면서 아래 항목은 꽤 엄격하게 지키려고 합니다.
- 민감정보는 업로드 전에 제거합니다: 고객 개인정보, 운영 DB 접속 정보, API Key, Secret, 내부망 IP는 반드시 마스킹합니다.
- 버전 기준을 질문에 명시합니다: v1과 v2 문서를 같이 넣었다면 “v2 기준으로 답변해줘”처럼 범위를 좁힙니다.
- AI 답변을 그대로 운영 반영하지 않습니다: 답변은 출발점일 뿐이고, 실제 반영 전에는 코드와 로그, 테스트로 다시 확인합니다.
- 문서에 없는 내용은 추정으로 분리하게 합니다: “명시되지 않은 내용은 추정이라고 표시해줘”라는 문장을 자주 붙입니다.
- 팀 내 보안 정책을 먼저 확인합니다: 사내 규정상 외부 AI 도구에 문서 업로드가 금지된 경우도 있으니, 이 부분은 꼭 확인해야 합니다.
솔직히 이 부분은 조금 귀찮습니다. 그런데 귀찮다고 생략하면 나중에 더 큰 귀찮음이 옵니다. 특히 운영 시스템 문서에는 생각보다 많은 민감정보가 숨어 있어요. 예전에는 아무 생각 없이 문서에 적어둔 내부 IP, 임시 비밀번호, 테스트 계정이 몇 년 뒤까지 남아 있는 경우도 봤습니다. 레거시는 코드만 낡은 게 아니라 문서도 같이 낡아 있거든요.
제가 느낀 NotebookLM의 가장 큰 장점은 시간을 돌려준다는 겁니다
NotebookLM을 쓰면서 제일 크게 느낀 건, 이 도구가 개발자의 시간을 꽤 많이 아껴준다는 점입니다. 예전에는 300쪽짜리 PDF를 열고 Ctrl + F로 키워드 검색을 반복했어요. “payment”, “status”, “callback”, “retry”, “timeout” 같은 단어를 하나씩 검색하면서 문맥을 이어 붙였죠. 그렇게 한참 보다 보면 눈은 아프고, 머릿속에는 조각난 정보만 남습니다.
이제는 문서를 정리해서 올려두고, NotebookLM에 질문을 던집니다. “결제 실패 시 재시도 정책을 문서 근거와 함께 정리해줘.” “외부 PG callback이 중복으로 들어왔을 때 멱등성 처리가 문서에 있는지 확인해줘.” 이런 식으로요. 그러면 적어도 어디부터 봐야 하는지 감이 잡힙니다. 사람은 그다음에 중요한 판단을 하면 됩니다.
저는 이 변화가 꽤 크다고 봅니다. 개발자가 문서를 안 읽어도 된다는 뜻이 아닙니다. 오히려 반대에 가까워요. 문서를 더 잘 읽기 위해 AI를 쓰는 겁니다. 어디에 근거가 있고, 어디가 비어 있고, 어떤 부분을 의심해야 하는지 빠르게 잡아주는 도구로 쓰는 거죠.
이런 분들에게 특히 잘 맞을 것 같습니다
제가 써보니 NotebookLM은 모든 개발자에게 똑같이 필요한 도구는 아닐 수 있습니다. 하지만 아래 상황에 자주 놓이는 분이라면 한 번쯤 진지하게 써볼 만합니다.
- 수백 페이지짜리 오픈소스 문서나 사내 가이드를 빠르게 훑어야 하는 주니어 개발자와 미들 개발자
- 인수인계가 애매한 프로젝트를 떠안고 히스토리를 추적해야 하는 메인터너
- 레거시 시스템의 결제, 정산, 인증 흐름을 문서 기반으로 파악해야 하는 백엔드 개발자
- 회의 전에 기술 쟁점과 문서 근거를 빠르게 정리해야 하는 테크 리드
- 퇴근 후나 이동 중에도 기술 문서를 조금씩 소화하고 싶은 학구파 직장인 개발자
저는 이제 여행 갈 때도 예전처럼 무거운 노트북을 보며 불안해하지는 않습니다. 물론 개발자는 어디서든 호출될 수 있다는 슬픈 현실이 있긴 하지만요. 그래도 도구를 잘 써두면, 적어도 바다 앞에서 300쪽 문서를 처음부터 끝까지 읽는 일은 줄일 수 있습니다.
기술은 결국 사람 시간을 아껴주려고 있는 거라고 생각합니다. 아낀 시간을 또 다른 야근으로 채우면 조금 서글프고요. 가능하면 맛있는 거 먹고, 바람 좀 쐬고, 좋아하는 사람들과 더 오래 이야기하는 데 쓰면 좋겠습니다. NotebookLM은 그런 의미에서 제게 꽤 고마운 도구였습니다. 레거시 문서 때문에 머리 아픈 개발자라면, 한 번쯤 조용히 써보셔도 좋겠습니다.
👨💻
작성자: 20년 경력 IT 전문 아키텍트
실무 개발과 아키텍처 설계를 거쳐 현재는 AI 바이브 코딩과 개발 자동화를 연구하고 있습니다. 직접 삽질하며 깨달은 실전 꿀팁과 에러 극복 사례만 투명하게 공유합니다.
댓글
댓글 쓰기