홈
블로그-자동화

구글 NotebookLM의 한계와 Antigravity 블로그 포스팅 자동화 구축기

Antigravity 블로그 포스팅 자동화 워크플로우 대표 이미지

IT 기술 관련 작업을 하면서 가장 번거로운 순간 중 하나는 다름 아닌 '문서화 작업'입니다. 작업을 진행하는 동안에는 구글링을 거쳐 직접 원인을 파악하고 문제 해결을 완료하지만, 막상 그 내용을 글로 정리하려고 하면 이전에 파악했던 자료들을 다시 뒤적여야 하는 비효율이 발생하곤 합니다.

특히 개발 도구나 라이브러리 설치 가이드의 경우, 이미 한 번 설치를 마치고 나면 시스템을 완전히 초기화하기 어렵기 때문에 설치 단계별 진행 상태나 에러 발생 시점을 사후에 재검증하기가 매우 까다롭습니다.

이러한 문제를 근본적으로 해결하기 위해, 리서치 단계에서부터 기록 검증, 그리고 블로그 발행에 이르는 전 과정을 자동화하는 시스템을 구상하게 되었습니다.

이번 포스팅에서는 초기 설계 단계에서 겪었던 시행착오와 구글 NotebookLM의 한계를 짚어보고, 이를 극복하기 위해 Antigravity 에이전트를 중심으로 구축한 최종적인 블로그 포스팅 자동화 워크플로우를 소개하고자 합니다.

시행착오: 구글 NotebookLM의 명확한 한계

처음에는 시스템 설계를 비교적 단순하게 접근했습니다. "자료 수집과 기초 문서 작성은 문서 요약 기능을 가진 구글 NotebookLM에 맡기고, Antigravity는 완성된 텍스트를 HTML 코드로 변환하는 역할만 수행하게 하자"는 구상이었습니다. NotebookLM의 소스 분석을 믿었던 안일한 생각이었습니다.

NotebookLM의 한계와 에이전트 통합 구조 비교 다이어그램

실제 이 분리형 구조를 테스트해 본 결과, 다음과 같은 심각한 문제점들이 연이어 발생했습니다.

  • 프롬프트 지시 불이행: 저장 포맷이나 정보 추출 형식에 대해 엄격한 프롬프트 지침을 주었음에도 불구하고, NotebookLM은 임의의 포맷으로 문서를 출력했습니다.
  • 잘못된 출처 및 기사 수집: 특정 기술 키워드를 수집하라고 지시했으나, 문맥을 잘못 짚어 전혀 엉뚱한 기술 문서나 구버전 정보를 긁어와 신뢰도를 훼손시켰습니다.
  • 자동화 파이프라인의 단절: 웹 검색이나 로컬 파일 시스템에 직접 접근할 수 없는 닫힌 환경(Closed-box)의 특성상, 정보의 정합성을 스스로 교차 검증하고 수정하는 능력이 전무했습니다.

결국 요약 및 정리의 편의성 뒤에 가려진 품질 제어의 한계를 뼈저리게 실감하였고, 수집 단계부터 에이전트가 직접 제어할 수 있는 도구 중심의 통합형 아키텍처로 방향을 완전히 선회하게 되었습니다.

검증 기반 글쓰기를 실현하는 4단계 통합 워크플로우

이러한 한계를 딛고 재설계된 시스템은 Antigravity 에이전트가 단독으로 리서치, 추출, 로컬 파일 저장, HTML 변환까지 전체 루프를 직접 통제하는 방식입니다. 이 워크플로우의 핵심은 글을 쓰기 전에 먼저 팩트를 검증하는 '검증 기반 글쓰기(Verified-driven Writing)'에 있습니다. 구체적인 동작 방식은 다음과 같습니다.

  1. 1단계: 지식 수집 및 로컬 문서화 (Knowledge Manager)
    사용자가 주제를 던지면 Antigravity가 웹 검색(공식 문서 우선)을 실행하고 신뢰도 등급(★ 갯수)에 따라 FACT/OPINION/CONFLICT 정보를 분류합니다. 그 결과물을 로컬의 특정 마크다운 파일로 저장하고 중앙 인덱스에 등록합니다. 이때 최초 상태는 무조건 Experimental로 지정됩니다.
  2. 2단계: 실시간 테스트 및 피드백 반영 (Feedback Manager)
    사용자는 생성된 Experimental 가이드를 따라 직접 실제 설정을 세팅하고 실행해 봅니다. 테스트 과정에서 발견된 오류나 개선점을 피드백으로 전달하면 에이전트가 지식 문서를 갱신하고 상태를 Verified로 승격시킵니다.
  3. 3단계: 블로그 HTML 초안 작성 (Blog Harness)
    검증이 완료된 지식 문서를 바탕으로 블로그 포스팅 작성을 지시합니다. 에이전트는 미리 지정된 블로그 페르소나 스타일(어조, 말투, 금지 표현 등)을 준수하고, HTML 생성 전 SEO 분석 결과(키워드 및 메타 설명)를 먼저 제안하여 최종 승인을 받은 뒤 테마 네이티브 컴포넌트가 적용된 HTML 소스를 생성합니다.
  4. 4단계: 발행 완료 및 최종 상태 동기화
    사용자가 블로그스팟에 소스를 복사해 붙여넣고 이미지를 입혀 발행한 후 에이전트에게 "발행 완료"를 알리면, 지식 파일 내의 blog_published 상태가 true로 변경되어 전체 관리가 마무리됩니다.

작업 과정에서 깨달은 실전 운영 팁

실제로 본 자동화 시스템을 한동안 테스트하고 적용해 보며 알게 된 유용한 실전 팁을 공유해 드리고자 합니다.

💡 팁: '기록-작업 병행 프로세스'의 가치
어떤 작업이나 설정을 마친 다음 머릿속 기억에 의존해 나중에 문서를 쓰려 하면, 작업 과정에서 겪었던 수많은 마이너 에러들과 대처법을 잊어버리는 일이 다반사입니다. 먼저 에이전트가 리서치해 준 지식 파일(Experimental)을 켜두고 눈앞에서 한 단계씩 설치해가며 피드백을 기록하는 것이 결과물의 정합성을 극도로 높이는 유일한 지름길입니다.
⚠️ 주의: AI의 자동 생성 글에 대한 맹신 금지
블로그 포스팅 자동화라고 해서 AI에게 처음부터 끝까지 완전한 글 작성을 일임해서는 안 됩니다. 데이터의 원천이 되는 지식 문서(Knowledge Base)의 상태가 반드시 Verified 등급을 달성한 이후에만 블로그 드래프트 파일이 작성되도록 절차적 제동 장치(Harness)를 걸어두는 설계 방식이 필수적으로 요구됩니다.

마무리하며

이번 시스템 구축을 통해 매번 기술 문서를 쓸 때마다 겪었던 재연구의 시간 낭비를 상당 부분 덜어낼 수 있게 되었습니다. 단순히 편해 보이는 특정 AI 브랜드(NotebookLM 등)의 이름값만 믿기보다, 우리 작업장 환경에 맞는 에이전트 도구와 검증 루프를 밀착 설계하는 방식의 중요성을 다시금 깨닫는 기회였습니다.

설치 중 막히는 부분이 있거나 더 효율적인 세팅법을 아신다면 댓글로 공유 부탁드립니다. 다음 글에서는 이처럼 블로그 포스팅을 이용한 지식 축적이 아닌, Obsidian을 MCP를 통해 Antigravity에 연결하고 보다 AI 친화적인 Markdown으로 된 지식 데이터베이스 구축에 대해 다룰 예정입니다.