구글 서치 콘솔 데이터로 벡터 데이터베이스를 만들었을 때 배운 점: SQL과 벡터DB의 역할

핵심

저자가 구글 서치 콘솔 데이터를 로컬 벡터 데이터베이스(ChromaDB)로 구축한 결과, SQL과 벡터DB가 상보적인 역할을 한다는 점을 발견했다. 이 도구는 오픈 클로(OpenClaw) AI 에이전트의 분석 계층으로 작동한다.

배경: 왜 이 도구를 만들었나

• 문제: OpenClaw는 저자의 지시를 따르는 실행 계층이지만, 저자가 병목이었다. 수동으로 서치 콘솔 차트를 파헤쳐 하락하는 쿼리를 찾고, 콘텐츠 카니벌라이제이션(중복) 문제를 파악하고, 경쟁사 콘텐츠와 비교한 후 OpenClaw에 지시해야 했다.
• 해결책: 16개월의 서치 콘솔 데이터를 구조화 문서로 처리하고 벡터 데이터베이스에 임베딩한 뒤, AI 에이전트가 자연어로 쿼리하도록 자동화했다. 또한 Parallel.ai를 연동해 자신과 경쟁사 페이지를 크롤링할 수 있게 했다.

데이터 처리 파이프라인

1. 데이터 수집: GSC API에서 16개월치 데이터를 다운로드. 실제 트래픽이 있는 사이트라면 수백만 행.
2. 집계 및 트렌드 감지 (가장 핵심 요소)
   • 원본: 같은 쿼리-페이지 조합마다 50개 이상의 일일 행
   • 처리 후: 예를 들어 "/blog/seo-audit/"의 "seo audit checklist" → 하나의 문서로 통합
   • 내용: 16개월간 4,200 클릭, 평균 순위 3.2, CTR 4.8%, 최근 4주가 이전 12주보다 악화된 하락 추세
   • 트렌드 분류가 전체 프로젝트에서 가장 유용한 기능
3. 임베딩: 768차원의 Gemini 임베딩 모델을 사용하여 문서를 ChromaDB에 저장
4. 쿼리 및 분석
   • 영문으로 질문 입력 → 벡터DB가 관련 문서 검색 → LLM이 SEO 전문가 시스템 프롬프트로 분석
   • 모델 옵션: Gemini Flash(빠르고 무료), Grok 4.1(200만 토큰 컨텍스트로 50개 대신 400개 문서 처리 가능), Claude Opus(전략적 추천 제공)
5. 경쟁사 분석: Parallel.ai가 실제 웹 페이지를 스크래핑하여 지표뿐 아니라 실제 콘텐츠를 비교 ("CTR이 낮다" → "경쟁사는 비교 테이블, FAQ, 원본 데이터를 보유하고 있다")

벡터DB vs SQL: 각각의 강점

벡터DB의 약점 — 수치 쿼리에는 부적합

• 문제: 구조화된 데이터(클릭, 노출수, CTR, 순위 등)는 숫자로 이루어져 있는데, 벡터DB는 산술을 수행하지 않는다. "높은 노출수이지만 낮은 CTR"이라는 문장을 벡터로 변환하고 가까운 문서를 찾을 뿐이다.
• 결과: 임베딩 공간의 언어 패턴 매칭이므로 근사치일 뿐이다.
  • 50,000 노출수인 쿼리를 놓칠 수 있다(텍스트 임베딩이 충분히 가깝지 않음)
  • 200 노출수인 쿼리를 포함할 수 있다(단어 설명이 우연히 일치)
• 대안: WHERE impressions > 1000 AND ctr < 0.03 ORDER BY impressions DESC 같은 SQL 쿼리가 수학적으로 정확하다.

벡터DB의 강점 — 의미 기반 탐색

• SQL의 한계: "AI 관련 콘텐츠는 어떻게 성과하나?" 질문은 WHERE 절이 필요하다. WHERE query LIKE '%AI%' OR query LIKE '%artificial intelligence%' OR query LIKE '%machine learning%' 등으로 모든 변형을 나열해야 한다. "transformer architecture explained"나 "neural network tutorial"처럼 키워드를 포함하지 않은 관련 쿼리는 누락된다.
• 벡터DB의 해결책: 임베딩 모델이 이 개념들이 관련 있다는 것을 알고 있다. 동의어와 하위 주제를 일일이 나열할 필요 없이 자동으로 반환한다.
• 탐색적 질문에도 강함: "기술 SEO 콘텐츠에서 뭔가 일어나고 있나?"라는 개방형 질문도 벡터DB는 자연스럽게 처리한다. SQL에서는 사전에 어느 페이지가 기술 SEO 관련인지 알아야 필터링할 수 있다.
• 실제 가치: 스프레드시트를 한참 들여다봐도 찾지 못했을 패턴을 수면 위로 올린다.

아키텍처 선택지와 이상적인 조합

검토했던 세 가지 접근법

1. 벡터 데이터베이스 (선택한 방식): 탐색 분석에 최고의 가치
2. GSC MCP 서버 (AI 에이전트용 실시간 API 접근)
   • 빠른 조회에는 적합하지만 16개월 대규모 분석 불가
   • 모든 질문이 API 호출 → 레이트 제한 빠르게 도달
   • 경쟁사 페이지 크롤링 불가
3. 순수 SQL 데이터베이스: 정확한 수치 리포트 필요 시 우수

이상적인 아키텍처

• SQL과 벡터DB 결합 + LLM 라우팅 계층
• LLM이 질문을 분석해 어느 백엔드를 호출할지 결정
• 저자는 탐색 분석의 가치를 가장 크게 평가했으므로 순수 벡터DB로 구축했지만, 클라이언트가 정확한 메트릭 리포트를 필요로 한다면 ChromaDB 옆에 DuckDB를 추가했을 것

실제 워크플로우

• 주간 갱신: python main.py refresh 크론 잡으로 벡터 데이터베이스 최신화
• 전략 수립: python main.py ask "which topic clusters are declining?" --grok → 16개월 데이터 기반 분석
• 페이지 감사: python main.py audit "https://metehan.ai/some-page/" --grok → 경쟁사 비교 포함 콘텐츠 갭 리포트
• 통합: 보고서를 OpenClaw에 다시 피드백 → OpenClaw가 실행

역할 분담:

• OpenClaw: 상태 유지(세션 간 컨텍스트 기억), 행동 지향(작성, 발행, 이메일 전송)
• 벡터DB: 분석, 16개월 히스토리 파악, 패턴 도출
• 두 도구는 상보적이다. 벡터DB가 "뭘 해야 할까?"를 답하면 OpenClaw가 "해내기"를 담당한다.

CLI 명령을 OpenClaw 스킬로 래핑하면

워크플로우 중 검색 데이터를 직접 쿼리할 수 있다. 모든 것이 로컬에서 실행되므로 아키텍처는 단순하다.

재설계 시 개선점

저자가 지금이라면 다르게 구축할 방식:

1. 구조화된 메트릭은 DuckDB에 저장, 의미론적 콘텐츠(쿼리 텍스트, 페이지 주제, 콘텐츠 설명)만 벡터DB에 사용
2. LLM이 SQL에서 정확한 숫자, ChromaDB에서 의미 컨텍스트를 받도록 구분
3. 임베딩 문서 형식 개선
   • 현재: "Clicks: 150" 같은 수치를 텍스트에 포함 → 벡터 공간에서 의미 없음
   • 개선: 수치를 메타데이터로 분리하여 검색 후 첨부 → 검색 품질 향상

최종 평가

이 도구는 패턴 발견, 기회 발굴, 데이터 기반 콘텐츠 추천에 충분히 잘 작동한다. 범용 SEO 조언 대신 실제 데이터로 뒷받침된 조언을 얻는다.

• 오픈소스, MIT 라이선스: github.com/metehan777/vectordb-gsc