지식센터 / 레퍼런스

🧠 비즈스프링 브랜드 인텔리전스 허브 전략 마스터 v2.0

# 비즈스프링 브랜드 인텔리전스 허브 전략 및 전술 마스터 문서

버전: v2.0 Opus 4.6 재구성판

원본 대화: https://claude.ai/chat/10f4ec08-1763-46a1-9f69-cbb27efd9e13

날짜: 2026년 2월 18일

목적: 여러 대화방(LN)을 통해 전략과 전술을 점진적으로 완성하기 위한 중심 문서

---

이 문서의 역할

이 문서는 단일 진실 공급원(Single Source of Truth)이다.

토큰 한계로 대화방이 분리될 수밖에 없으므로, 새 대화를 시작할 때마다 이 문서를 업로드하면 맥락이 유지된다.

Opus 4.6의 200K 컨텍스트 윈도우 안에서 이 문서 하나로 전체 전략 상태를 복원할 수 있도록 설계했다.

---

1부. 원본 대화 전개 요약

1-1. 출발점: 노트북LM 영상 분석

유튜브 영상(Nova AI, 2026-02-14)에서 다룬 핵심 개념은 다음과 같다.

AI 에이전트의 성능 저하 원인은 맥락 부족이다. 웹 검색으로 끌어온 불필요한 정보가 토큰을 낭비하고 정확도를 떨어뜨린다. 노트북LM을 CLI 및 MCP와 연동하면 에이전트의 영속적 외부 지식 베이스로 사용할 수 있다. 프로젝트별 노트북을 만들어 단일 진실 공급원으로 지정하고, 에이전트는 노트북LM의 RAG가 정제한 응답만 받는다.

리서치 분리 전략의 흐름은 다음과 같다. 리소스 수집 후 노트북LM에 업로드하고, 맥락을 초기화한 뒤, 필요할 때만 쿼리해서 핵심만 가져온다.

1-2. 비즈스프링 현실과의 대조

우리에게는 이미 KHub(Supabase 기반 RAG 지식 베이스)가 있다. 핵심 질문은 "노트북LM을 추가할 것인가, 기존 시스템을 강화할 것인가"였다.

결론은 둘 다 사용하되 역할을 분리하는 것이다.

• KHub (Supabase RAG): 내부 기술 지식 베이스. 대상은 비즈스프링 팀, n8n 워크플로우, Claude MCP.
• 노트북LM: 파트너사 대면 지식 허브. 대상은 고객사 담당자, 비개발자, 파트너 생태계.
• Claude (Opus 4.6): 전략 두뇌 겸 구현 엔진. 대상은 찰스(설계, 코드, 의사결정).

1-3. 전개 과정에서 생성된 문서들

1번 문서: notebooklm-second-brain.md (영상 요약 및 패턴 정리)

2번 문서: bizspring-khub-notebooklm-architecture.md (KHub 확장 아키텍처)

3번 문서: geocare-notebooklm-brand-hub-architecture.md (고객사별 브랜드 허브 구조)

4번 문서: claude-md-notebooklm-perplexity-grok-guide.md (즉시 실행 가이드)

5번 문서: geocare-multi-llm-final-architecture.md (멀티 LLM 역할 분담)

6번 문서: WF-GEOCARE-BRAND-INTEL-001.json (n8n 워크플로우 JSON)

7번 문서: WF-GEOCARE-BRAND-INTEL-001-setup-guide.md (워크플로우 설정 가이드)

8번 문서(핵심): bizspring-brand-intel-hub-strategy-master.md (최종 마스터 문서, 이 문서의 원본)

---

2부. 핵심 전략 (마스터 문서 기반)

2-1. 비즈니스 포지셔닝

비즈스프링은 두 개의 플랫폼을 운영한다.

growthplatform.ai는 데이터 엔지니어링과 ETL 백본 역할이다.

GEOcare.AI는 GEO 분석 SaaS로, growthplatform 위에서 구동된다.

브랜드 인텔리전스 허브는 GEOcare.AI의 서비스 확장이며 파트너사에게 세 가지를 제공한다.

첫째, SoM(Share of Model) 분석이다. 4개 LLM에서 브랜드가 얼마나 언급되는지 측정한다.

둘째, EEAT 브랜드 허브이다. AI 검색 최적화된 브랜드 서브사이트를 자동 생성한다.

셋째, 지식 축적 생태계이다. 파트너 데이터가 쌓일수록 서비스 품질이 향상되는 Lock-in 구조다.

2-2. 전략의 3축

축 1은 데이터 파이프라인이다. n8n 오케스트레이션, Edge Function 병렬처리, Supabase Realtime, 멀티 LLM 호출을 포함한다.

축 2는 지식 생태계이다. KHub(내부 기술), 노트북LM(파트너), Drive 동기화, NLM Prompts를 포함한다.

축 3은 파생 서비스이다. 브랜드 허브 자동 배포, 콘텐츠 자동 제작, GEO 모니터링 SaaS를 포함한다.

2-3. 멀티 LLM 역할 분담

하나의 LLM에 의존하지 않는 것이 아키텍처의 핵심 차별점이다.

• Claude (Opus 4.6): 전략 두뇌 역할. 아키텍처 설계, EEAT 콘텐츠 생성, 복잡한 분석 담당.
• ChatGPT (GPT-4o): 품질 게이트 역할. 데이터 정규화, 중복 제거, Action Rules 추출 담당.
• Perplexity (Sonar): 실시간 검색 역할. SoM 분석, 최신 웹 컨텍스트 담당.
• Gemini (2.0 Flash): 대량 처리 역할. 배치 파싱, 비용 효율 작업 담당.
• 노트북LM: 파트너 지식 허브 역할. 비개발자용 인터페이스, 음성 브리핑 담당.

2-4. 기술 아키텍처

프론트엔드는 Lovable이 담당한다. 온보딩 UI, SoM 프로그레스, 브랜드 허브 미리보기를 포함한다. Supabase Realtime으로 실시간 데이터를 수신한다.

백엔드는 Supabase가 담당한다. Auth, PostgreSQL(gp_geoex_ 계열 테이블), Edge Functions(som-benchmark, brandhub-generate, brandhub-deploy)를 포함한다. Realtime이 활성화되어 프론트엔드에 변경 사항을 즉시 전달한다.

외부 API 계층은 Claude API, ChatGPT API, Perplexity API, Gemini API, Netlify Deploy API를 포함한다.

오케스트레이션은 n8n Cloud가 담당한다. 온보딩 워크플로우, SoM 오케스트레이션(배치 분할), 모니터링 워크플로우를 포함한다.

2-5. SoM 병렬처리 핵심 성능 개선

기존 방식은 n8n 순차 처리로, 50개 질의 곱하기 4개 LLM 곱하기 약 7초로 총 23분이 소요되었다.

개선 방식은 Edge Function에서 Promise.all()로 병렬 처리하여 약 50초로 단축한다. 28배 빠르다.

흐름은 다음과 같다. n8n이 50개 질의를 5개씩 배치로 분할한다. 각 배치마다 Edge Function som-benchmark를 호출한다. Edge Function 내부에서 4개 LLM을 동시 호출(Promise.all)한다. 결과를 즉시 Supabase에 INSERT한다. Realtime을 통해 프론트엔드에 실시간 프로그레스가 표시된다. 완료 후 다음 배치로 넘어간다.

핵심 인사이트: 병목은 코드 실행 속도가 아니라 LLM API 응답 대기 시간이다. 순차를 병렬로 바꾸는 것만으로 대폭 단축된다.

---

3부. 비용 구조

3-1. LLM 호출 비용 (파트너 1곳당 SoM 분석 1회)

질의문 50개에 LLM 4개로 총 200회 호출한다.

• GPT-4o-mini: 200회, 약 0.12달러
• Perplexity: 50회, 약 0.25달러
• Gemini: 50회, 약 0.05달러
• Claude: 50회, 약 0.15달러
• 합계: 약 0.57달러 (약 800원)

3-2. 인프라 비용

현재 규모(월 10에서 50 파트너)에서의 월간 비용은 다음과 같다.

• Supabase Pro: 25달러
• n8n Cloud Starter: 24달러
• LLM API: 30에서 50달러
• Netlify Free: 0달러
• 합계: 약 80에서 100달러

성장 시(월 200개 이상 파트너)에는 약 300에서 600달러이며, 이 시점에는 파트너 매출로 커버 가능하다.

3-3. 비용 승인 체계 (Human-in-the-Loop)

n8n이 비용을 예측한다. 5달러 이상이면 Slack 승인 요청을 보내고 승인 후 실행한다. 5달러 이하면 즉시 실행한다.

---

4부. 구현 로드맵

Phase S-0: 전략 정렬 (현재 단계)

완료 항목:

• 노트북LM 영상 분석 완료
• KHub 대 노트북LM 역할 분리 결정
• 멀티 LLM 아키텍처 설계
• SoM 병렬처리 아키텍처 설계
• 브랜드 허브 파이프라인 설계
• 마스터 전략 문서 v1.0 작성
• Opus 4.6 기반 마스터 문서 v2.0 재구성 (이 문서)

Phase S-1: 파일럿 (2주, 개발 없음)

• 파트너사 1곳 선정
• 노트북LM 노트북 수동 생성 (Drive 동기화)
• 크롤링 결과와 SoM 데이터 업로드
• NLM Prompts (추천 질문 세트) 제공
• 파트너 피드백 수집
• "쓸 만한가?" 판단

Phase 1: SoM 병렬화 (1에서 2주)

• Edge Function som-benchmark 개발
• gp_geoex_som_results 테이블에 Realtime 활성화
• n8n 워크플로우를 Edge Function 호출 방식으로 전환
• Lovable에서 실시간 프로그레스 UI 개발

Phase 2: 브랜드 허브 MVP (2에서 3주)

• HTML 템플릿 제작 (Lovable 바이브코딩)
• Edge Function brandhub-generate 개발 (Claude EEAT 콘텐츠)
• Edge Function brandhub-deploy 개발 (Netlify Deploy API)
• 첫 번째 파트너 브랜드 허브 배포 후 시연

Phase 3: 온보딩 자동화 (2에서 3주)

• Phase0 status 불일치 해결
• crawl-watcher 구현
• 벤치마크 자동 실행
• 플랜 변경 이벤트를 Webhook으로 n8n 자동 트리거

Phase 4: 파생 서비스 (이후)

• 콘텐츠 자동 제작 (블로그, SNS, 유튜브 대본)
• GEO 모니터링 SaaS (SoM 정기 추적과 월간 리포트)
• 파트너 KHub 생태계 확장

---

5부. 미결 의사결정 항목

이 항목들이 답해져야 개발을 시작할 수 있다.

D-1. 노트북LM 활용 범위: 파트너 전용 대 내부 겸용. 현재 파트너 전용 방향.

D-2. 브랜드 허브 호스팅: Netlify 대 Vercel 대 자체. Netlify 유력(무료 100사이트).

D-3. 과금 모델: 월정액 대 건당 대 하이브리드. 미결정.

D-4. 첫 파일럿 대상: 어떤 파트너, 어떤 도메인. 미결정.

D-5. 노트북LM 대 Open Notebook: 구글 종속 대 오픈소스. 검토 중.

D-6. LLM 비용 부담 주체: 비즈스프링 부담 대 파트너 전가. 미결정.

D-7. EEAT 콘텐츠 품질 기준: 자동 생성만 대 사람 검수 병행. 미결정.

D-8. Schema.org 적용 범위: 필수 4종만 대 산업별 확장. 필수 4종 시작.

---

6부. 개발 준비 완료 기준 (게이트)

아래 항목이 모두 완료되어야 개발을 시작할 수 있다.

• 비즈니스 모델 확정 (과금, 타겟)
• MVP 범위 확정 (무엇을 먼저 만들 것인가)
• 기술 아키텍처 확정 (이 문서의 2부 2-4항)
• 테이블 스키마 확정
• 파트너사 1곳 이상 실제 피드백 완료 (Phase S-1)
• 비용 구조 실측 완료

---

7부. 용어 정의

• EEAT: 구글 검색 품질 기준. Experience(경험), Expertise(전문성), Authoritativeness(권위성), Trustworthiness(신뢰성).
• 브랜드 인텔리전스 허브: 고객사 도메인에 대해 수집하고 정제하고 분석한 모든 지식의 저장소.
• KHub: 비즈스프링 내부 지식 베이스 허브. Supabase RAG 기반.
• SoM: Share of Model. LLM 응답에서 특정 브랜드가 언급되는 비율.
• Quality Gate: ChatGPT가 담당하는 데이터 정규화 및 중복 제거 레이어.
• Action Rules: ChatGPT가 Claude 리포트에서 추출한 자동 실행 가능한 JSON 룰.
• NLM Prompts: 노트북LM에서 파트너 유형별로 물어볼 추천 질문 세트.
• Lock-in: 고객사 데이터가 쌓일수록 서비스 이탈 비용이 높아지는 구조.
• Drive 동기화: Google Drive 폴더에 파일 저장 시 노트북LM이 자동으로 소스를 추가하는 기능.

---

8부. 다음 대화방(LN)에서 다룰 항목

이 문서를 기반으로 후속 대화에서 점진적으로 완성할 영역들이다.

LN-01: Phase S-1 파일럿 상세 설계. 대상 파트너 선정 기준, 노트북LM 노트북 구조 설계, NLM Prompts 초안을 다룬다.

LN-02: Edge Function 개발. som-benchmark 코드 작성, brandhub-generate 코드 작성, A/B 테스트(Opus 대 GPT) 프레임워크를 다룬다.

LN-03: 과금 모델 검토. 경쟁사 벤치마킹, 원가 기반 가격 산출, 파트너 유형별 티어링을 다룬다.

LN-04: 브랜드 허브 템플릿. Lovable 바이브코딩으로 HTML 표준 템플릿 제작, Schema.org JSON-LD 마크업, Netlify Deploy 자동화를 다룬다.

LN-05: 노트북LM 대 Open Notebook 비교 검증. 기능 비교표, 비용 구조 분석, 구글 종속 리스크 평가를 다룬다.

---

부록: 이 문서의 사용법

새 대화방을 시작할 때 이 md 파일을 첨부한다. 그리고 "이전 마스터 문서 기반으로 LN-XX 작업을 진행하자"라고 요청한다. Claude Opus 4.6이 문서를 읽고 맥락을 복원한다. 작업 완료 후 변경사항을 이 문서에 반영한다.

업데이트 규칙은 다음과 같다. 미결 항목이 해결되면 5부에서 상태를 업데이트한다. 새로운 의사결정이 필요하면 D-N 번호를 추가한다. Phase가 진행되면 4부 체크리스트를 업데이트한다. 새 LN이 완료되면 8부에 결과 요약을 추가한다.

---

문서 상태: 전략 및 전술 검토 중, 개발 전 단계

버전: v2.0 Opus 4.6 재구성판, 2026년 2월 18일

원본: v1.0 (2026년 2월 17일, 이전 대화방)

다음 업데이트: Phase S-1 파일럿 설계 완료 후

관련 문서

이 문서를 참조하는 문서 (역링크)

• 없음

다른 표현: Markdown · JSON · 최종 갱신 2026-08-24