{
  "id": "3e54a39c-cbc0-4d1d-8de6-4cca83e51fd0",
  "slug": "ref/khub/premium-geo-eeat-부스터-오케스트레이션-설계서-v1-0",
  "doc_type": "ref",
  "title": "⚙️ EEAT 부스터 오케스트레이션 설계서 v1.0",
  "title_en": null,
  "one_liner": "# EEAT 부스터 오케스트레이션 설계서 버전: v1.0 설계 초안 날짜: 2026년 2월 19일 상태: 설계 논의 중 (구현 전) 참고: bmp.ai/demo (삼성서울병원 심장내과 사례) --- ## 이 문서의 목적 bmp.ai/demo에서 시연된 EEAT Agen",
  "summary_bullets": [],
  "body_md": "# EEAT 부스터 오케스트레이션 설계서\n\n버전: v1.0 설계 초안  \n날짜: 2026년 2월 19일  \n상태: 설계 논의 중 (구현 전)  \n참고: bmp.ai/demo (삼성서울병원 심장내과 사례)\n\n---\n\n## 이 문서의 목적\n\nbmp.ai/demo에서 시연된 EEAT Agentic API의 구조를 기반으로, 실제 n8n 오케스트레이션으로 구현 가능한 기술 설계를 전개한다. 구현 코드는 다루지 않는다. Claude가 최종 제어탑 역할을 하면서 각 LLM이 자기 영역에서 자율적으로 JSON을 생성하는 구조를 설계한다.\n\n---\n\n## 1. bmp.ai/demo가 보여주는 것과 우리가 만들 것\n\n### bmp.ai/demo 현재 구조\n\nbmp.ai/demo는 단일 API 호출로 다음을 반환한다.\n\n- EEAT 점수 (Experience 3, Expertise 4, Authoritativeness 4, Trustworthiness 3, 총점 70)\n- gaps: 각 EEAT 축별로 부족한 부분 (예: 환자 후기 없음, 전문 의료진 자격 정보 부족)\n- suggested_faqs: 만들어야 할 FAQ 목록 (키워드와 답변 방향 포함)\n- content_brief: 콘텐츠 제작 가이드 (톤, 권장 단어수, H2 구성)\n- schema_recommendations: 적용해야 할 Schema.org 타입 (FAQPage, MedicalOrganization 등)\n\n이것은 \"진단\"이다. 우리가 만들 것은 진단 이후의 \"자동 치료\"까지 포함하는 전체 파이프라인이다.\n\n### 우리의 확장 범위\n\n진단(bmp.ai/demo가 하는 것)에서 끝나지 않고, 진단 결과를 기반으로 각 LLM이 자율적으로 콘텐츠를 생성하고, 그 결과물이 JSON-LD로 조립되어 실제 배포까지 이어지는 흐름이다.\n\n---\n\n## 2. 전체 오케스트레이션 흐름\n\n### 2-1. 5단계 파이프라인\n\n1단계 진단: 사이트를 크롤링하고 현재 EEAT 상태를 분석한다.\n2단계 처방: 업종별 YMYL 가이드라인을 적용하여 무엇을 보강해야 하는지 결정한다.\n3단계 생성: 각 LLM이 자기 전문 영역에서 JSON 데이터를 자율 생성한다.\n4단계 조립: Claude가 모든 JSON을 검증하고 JSON-LD로 통합 조립한다.\n5단계 배치: 목적에 맞게 JSON-LD를 사이트에 배치한다.\n\n### 2-2. 단계별 상세\n\n1단계 진단 (입력: 도메인 URL)\n\nn8n이 크롤링을 실행한다. Firecrawl 또는 BrightData로 사이트 HTML을 수집한다. 기존 JSON-LD가 있는지, meta 태그는 어떤지, 콘텐츠 양은 얼마인지, FAQ가 있는지 등을 파싱한다. 결과를 Supabase gp_geoex_kpi_analysis 테이블에 저장한다.\n\n이 단계의 출력은 bmp.ai/demo와 동일한 구조의 JSON이다. EEAT 점수, gaps, suggested_faqs, content_brief, schema_recommendations.\n\n2단계 처방 (입력: 진단 결과 + 업종 코드)\n\n업종별 YMYL 가이드라인을 적용한다. 이 부분이 핵심 차별점이다. 같은 EEAT 부족이라도 의료업종과 쇼핑몰은 보강 방법이 완전히 다르다. Claude가 진단 결과와 업종 가이드라인을 읽고, 어떤 LLM에게 어떤 작업을 할당할지 \"작업 지시서\"를 생성한다.\n\n3단계 생성 (입력: 작업 지시서)\n\n각 LLM이 자기 전문 영역에서 JSON을 독립적으로 생성한다. n8n이 Edge Function을 통해 병렬 호출하고, 각 LLM의 결과가 개별 JSON 파일로 Supabase에 저장된다.\n\n4단계 조립 (입력: 개별 JSON 파일들)\n\nClaude가 모든 결과를 검증한다. 중복 제거, 일관성 확인, Schema.org 규격 검증을 수행한다. 최종적으로 하나의 통합 JSON-LD 패키지를 생성한다.\n\n5단계 배치 (입력: JSON-LD 패키지 + 배치 전략)\n\n목적에 따라 JSON-LD를 배치한다. GTM 태그로 동적 삽입하거나, Brand Hub HTML에 직접 삽입하거나, SSR 서버에서 렌더링하는 등 여러 방식이 가능하다.\n\n---\n\n## 3. 업종별 YMYL 가이드라인 체계\n\n### 3-1. YMYL이란\n\nYMYL은 Your Money or Your Life의 약자로, 구글이 사람의 건강, 안전, 재정에 영향을 미치는 콘텐츠에 더 높은 품질 기준을 적용하는 정책이다. 이 업종들은 EEAT 기준이 일반 업종보다 훨씬 엄격하다.\n\n### 3-2. 업종 분류 체계\n\nTier A (엄격한 YMYL): 의료/건강, 금융/보험, 법률, 뉴스/시사\nTier B (중간 YMYL): 교육, 부동산, 정부/공공, B2B SaaS\nTier C (일반): 이커머스/쇼핑, 요식/외식, 여행/레저, 엔터테인먼트\n\n### 3-3. 업종별 가이드라인이 결정하는 것\n\n각 업종 가이드라인은 JSON 파일로 관리되며, 다음을 정의한다.\n\n필수 Schema.org 타입: 의료는 MedicalOrganization과 MedicalWebPage, 금융은 FinancialProduct와 BankOrCreditUnion, 쇼핑은 Product와 Offer와 AggregateRating 등.\n\nEEAT 보강 우선순위: 의료는 Expertise와 Trustworthiness가 최우선(의사 자격증, 임상 데이터), 쇼핑은 Experience가 최우선(구매 후기, 사용 사례).\n\n콘텐츠 필수 섹션: 의료는 전문 의료진 소개, 인증 및 수상 내역, 치료 성과, 환자 후기 등. 쇼핑은 상품 상세, 구매자 리뷰, 비교 정보, 반품/교환 정책 등.\n\n금지 사항: 의료는 미검증 치료법 주장 금지, 금융은 수익률 보장 표현 금지 등.\n\nFAQ 생성 방향: 업종별로 사람들이 가장 많이 묻는 질문 유형이 다르다. 의료는 증상과 치료법 중심, 쇼핑은 가격과 배송 중심.\n\n### 3-4. 가이드라인 저장 위치\n\nSupabase에 gp_eeat_ymyl_guidelines 테이블로 관리한다. industry_code(의료, 금융, 쇼핑 등), ymyl_tier(A/B/C), required_schemas, eeat_priorities, content_requirements, prohibited_patterns, faq_templates 필드를 갖는다.\n\nClaude가 2단계 처방에서 이 테이블을 조회하여 해당 업종의 가이드라인을 참조한다.\n\n---\n\n## 4. 각 LLM의 역할과 자율 JSON 생성\n\n### 4-1. 핵심 원칙\n\n각 LLM은 자기가 잘하는 영역에서 독립적으로 JSON을 생성한다. n8n이 작업을 분배하고, 각 LLM은 정해진 JSON 스키마에 맞춰 결과를 반환한다. Claude가 최종적으로 모든 결과를 검증하고 조립한다.\n\n### 4-2. LLM별 역할 분담\n\nClaude (Opus 4.6) - 총괄 제어 및 핵심 콘텐츠\n\n역할: 오케스트레이션 두뇌. 작업 지시서 생성, 결과 검증, JSON-LD 최종 조립.\n자율 생성 영역: EEAT 핵심 콘텐츠 (Organization 소개, Expertise 섹션, Trust 신호), content_brief 기반 본문 텍스트, Schema.org JSON-LD 통합 패키지.\n출력 JSON: eeat_core.json (Organization, expertise_content, trust_signals, schema_package)\n\nPerplexity (Sonar) - 실시간 웹 검증 및 인용\n\n역할: 현재 웹에서 브랜드가 어떻게 언급되고 있는지 실시간 검증.\n자율 생성 영역: SoM 분석 (4개 LLM 응답에서 브랜드 멘션 비율), 경쟁사 대비 포지셔닝, 최신 뉴스와 리뷰 요약, 인용 가능한 외부 소스 목록.\n출력 JSON: web_intelligence.json (som_scores, competitor_positioning, recent_mentions, citable_sources)\n\nGemini (2.0 Flash) - 대량 구조화 데이터 처리\n\n역할: 비용 효율적인 대량 데이터 처리.\n자율 생성 영역: 상품 카탈로그 파싱 (Product/Offer Schema 대량 생성), FAQ 초안 대량 생성 (업종별 템플릿 기반), Breadcrumb와 SiteNavigationElement 자동 생성.\n출력 JSON: structured_data_bulk.json (products, faqs_draft, navigation, breadcrumbs)\n\nChatGPT (GPT-4o) - 품질 정규화 및 Action Rules\n\n역할: 다른 LLM 결과물의 품질 게이트.\n자율 생성 영역: 콘텐츠 톤/스타일 정규화, 중복 및 모순 감지, 실행 가능한 Action Rules 추출 (자동화 가능한 개선 항목 목록).\n출력 JSON: quality_gate.json (normalized_content, duplicates_removed, action_rules)\n\n유튜브 특화 (YouTube Data API + Gemini)\n\n역할: 유튜브 채널 및 영상 데이터 수집과 구조화.\n자율 생성 영역: 채널 정보 (VideoObject Schema), 인기 영상 요약, 유튜브 댓글에서 FAQ 후보 추출, 영상 트랜스크립트 기반 콘텐츠 생성.\n출력 JSON: youtube_data.json (channel_schema, video_objects, comment_faqs, transcript_content)\n\n소셜/커뮤니티 특화 (BrightData + GPT-4o-mini)\n\n역할: 네이버 블로그, 카페, 인스타그램 등 소셜 채널 데이터.\n자율 생성 영역: 브랜드 멘션 수집, 사용자 후기/리뷰 요약, 소셜 증거(Social Proof) 데이터, 커뮤니티 FAQ 추출.\n출력 JSON: social_data.json (brand_mentions, review_summary, social_proof, community_faqs)\n\n### 4-3. JSON 출력 규격 통일\n\n모든 LLM의 출력은 다음 공통 메타데이터를 포함한다.\n\n- source_llm: 어떤 LLM이 생성했는지\n- generated_at: 생성 시각\n- confidence: 신뢰도 점수 (0에서 1)\n- site_domain: 대상 도메인\n- industry_code: 업종 코드\n\n이 공통 메타데이터가 있어야 Claude가 4단계에서 결과를 취합하고 검증할 수 있다.\n\n---\n\n## 5. n8n 오케스트레이션 설계\n\n### 5-1. 워크플로우 구조\n\n전체를 하나의 거대 워크플로우로 만들지 않는다. 단계별로 분리하고 n8n 서브워크플로우 체이닝으로 연결한다.\n\nWF-EEAT-DIAG-001: 진단 워크플로우\n\n트리거: Webhook (온보딩 완료 시) 또는 스케줄 (정기 재진단)\n내용: 크롤링 실행, 기존 JSON-LD 파싱, EEAT 점수 산출, gaps 분석\n출력: gp_eeat_diagnosis 테이블에 진단 결과 저장\n다음: WF-EEAT-PRESC-001 호출\n\nWF-EEAT-PRESC-001: 처방 워크플로우\n\n트리거: 서브워크플로우 호출 (진단 완료 시)\n내용: 업종 가이드라인 조회, Claude API로 작업 지시서 생성, 각 LLM에 할당할 작업 목록 확정\n출력: gp_eeat_prescriptions 테이블에 작업 지시서 저장\n다음: WF-EEAT-GEN-001 호출\n\nWF-EEAT-GEN-001: 생성 워크플로우 (핵심)\n\n트리거: 서브워크플로우 호출 (처방 완료 시)\n내용: Edge Function을 통해 각 LLM 병렬 호출. 작업 지시서에 따라 필요한 LLM만 호출한다. 예를 들어 유튜브 채널이 없는 파트너는 유튜브 LLM을 건너뛴다.\n출력: gp_eeat_generated_jsons 테이블에 각 LLM의 결과 JSON 저장\n다음: WF-EEAT-ASSEMBLE-001 호출\n\nWF-EEAT-ASSEMBLE-001: 조립 워크플로우\n\n트리거: 서브워크플로우 호출 (생성 완료 시)\n내용: Claude API로 모든 JSON 검증 및 통합. Schema.org 규격 준수 확인, 중복 제거, 최종 JSON-LD 패키지 생성.\n출력: gp_eeat_jsonld_packages 테이블에 최종 패키지 저장\n다음: WF-EEAT-DEPLOY-001 호출\n\nWF-EEAT-DEPLOY-001: 배치 워크플로우\n\n트리거: 서브워크플로우 호출 (조립 완료 시)\n내용: 목적에 따라 배치. Brand Hub 페이지 생성 및 배포, GTM 태그 업데이트, 또는 고객에게 가이드 이메일 발송.\n출력: 배포 완료 상태 업데이트, 알림 발송\n\n### 5-2. Edge Function 역할\n\nn8n이 5개 LLM을 순차로 호출하면 느리다. Edge Function som-benchmark 패턴을 확장하여, eeat-generate라는 새 Edge Function이 작업 지시서를 받아 해당 LLM들을 Promise.allSettled()로 병렬 호출한다.\n\nEdge Function이 받는 입력: 작업 지시서 JSON (어떤 LLM에게 어떤 프롬프트로 호출할지)\nEdge Function이 하는 일: 각 LLM API 병렬 호출, 개별 결과를 즉시 Supabase INSERT, 성공/실패 집계 후 n8n에 응답\nn8n이 하는 일: 배치 분할, Edge Function 호출, 에러 시 재시도, 다음 단계 트리거\n\n### 5-3. Claude의 제어 지점\n\nClaude는 두 곳에서 개입한다.\n\n처방 단계(WF-EEAT-PRESC-001): 진단 결과와 업종 가이드라인을 분석하여 작업 지시서를 생성한다. 이것이 전체 파이프라인의 방향을 결정하는 가장 중요한 단계다.\n\n조립 단계(WF-EEAT-ASSEMBLE-001): 각 LLM이 생성한 JSON들을 검증하고 최종 JSON-LD로 통합한다. 여기서 품질 관리가 이루어진다.\n\n나머지 단계(진단, 생성, 배치)에서 Claude는 직접 개입하지 않는다. n8n과 Edge Function이 자동으로 처리한다.\n\n---\n\n## 6. JSON-LD 배치 전략\n\n### 6-1. 목적별 배치 방식\n\n배치는 단순히 JSON-LD를 사이트에 넣는 게 아니다. 목적에 따라 배치 방식이 달라진다.\n\n방식 1: Brand Hub 직접 삽입 (우리가 사이트를 생성하는 경우)\n\nBrand Hub HTML의 head에 JSON-LD를 직접 삽입한다. LLM 크롤러가 JavaScript 없이도 읽을 수 있는 가장 확실한 방법이다. 파트너 자체 사이트가 없거나 수정 권한이 없는 경우에 사용한다.\n\n방식 2: GTM 동적 삽입 (파트너가 GTM을 사용하는 경우)\n\n파트너 사이트의 GTM 컨테이너에 커스텀 HTML 태그를 추가한다. Supabase에서 해당 도메인의 JSON-LD를 실시간 조회하여 삽입한다. 태깅 대행사 모델에 적합하다. 다만 LLM 크롤러 중 JavaScript를 실행하지 않는 경우 인식되지 않는다.\n\n방식 3: SSR 삽입 (파트너가 자체 개발팀이 있는 경우)\n\n파트너 서버에서 페이지 렌더링 시 Supabase API를 호출하여 JSON-LD를 서버 사이드에서 삽입한다. 가장 이상적이지만 파트너 개발팀의 협조가 필요하다.\n\n방식 4: 하이브리드 (권장)\n\n핵심 데이터(Organization, 핵심 Product, 상위 5개 FAQ)는 Brand Hub에 직접 삽입하고, 변동성 높은 데이터(리뷰, 가격, 재고)는 GTM으로 동적 삽입한다. 이전 대화에서 이미 결론 내린 전략과 동일하다.\n\n### 6-2. JSON-LD 패키지 구성\n\n최종 조립된 JSON-LD 패키지는 다음 구조를 갖는다.\n\nOrganization JSON-LD: 기업/브랜드 기본 정보, sameAs 링크, contactPoint\nProduct/Service JSON-LD: 상품 또는 서비스 상세, Offer, AggregateRating\nFAQPage JSON-LD: 업종별 맞춤 FAQ (suggested_faqs + 소셜/커뮤니티에서 추출한 실제 질문)\nArticle/BlogPosting JSON-LD: 콘텐츠 브리프 기반 생성 글\nVideoObject JSON-LD: 유튜브 영상 구조화 데이터\n업종 특화 JSON-LD: MedicalOrganization(의료), FinancialProduct(금융), LocalBusiness(로컬) 등\n\n---\n\n## 7. 데이터 흐름 요약\n\n입력: 파트너 도메인 URL + 업종 코드\n\n1단계 진단 결과: EEAT 점수, gaps, schema_recommendations (Supabase 저장)\n2단계 처방 결과: 작업 지시서 JSON (어떤 LLM에게 무엇을 시킬지) (Supabase 저장)\n3단계 생성 결과: LLM별 개별 JSON (eeat_core, web_intelligence, structured_data_bulk, quality_gate, youtube_data, social_data) (Supabase 저장)\n4단계 조립 결과: 통합 JSON-LD 패키지 (Supabase 저장)\n5단계 배치 결과: 배포 완료 URL 또는 GTM 태그 ID (Supabase 저장)\n\n모든 중간 결과가 Supabase에 저장되므로, 어느 단계에서 실패하더라도 해당 단계부터 재실행할 수 있다.\n\n---\n\n## 8. 이전 대화에서 확정된 사항과의 연결\n\nSoM 병렬처리 아키텍처: 3단계 생성에서 동일한 Edge Function 병렬 패턴을 사용한다.\n\n멀티 LLM 역할 분담: 이 문서의 4-2항이 이전 마스터 문서의 2-3항을 구체화한 것이다.\n\nHuman-in-the-Loop 비용 승인: 3단계에서 LLM 호출 비용이 임계값을 초과하면 Slack 승인을 요청한다.\n\nBrand Hub 자동 배포: 5단계가 이전 마스터 문서의 Phase 2(Brand Hub MVP)를 실현하는 구체적 흐름이다.\n\n---\n\n## 9. 미결 설계 항목 (다음 대화에서 논의)\n\nS-1. 업종 가이드라인 초안: Tier A(의료), Tier C(쇼핑) 각 1개씩 실제 가이드라인 JSON을 만들어 구조를 검증해야 한다.\n\nS-2. LLM 프롬프트 설계: 각 LLM에게 보낼 시스템 프롬프트와 출력 JSON 스키마를 구체적으로 정의해야 한다.\n\nS-3. Edge Function eeat-generate 상세 설계: som-benchmark 패턴을 확장하되, LLM 종류와 개수가 동적으로 변하는 구조를 어떻게 처리할지 결정해야 한다.\n\nS-4. 기존 GEOcare 파이프라인과의 통합 지점: Phase0 온보딩, Phase1 크롤링, Phase2 KPI 분석과 이 EEAT 파이프라인이 어디서 합류하는지 명확히 해야 한다.\n\nS-5. 유튜브/소셜 LLM의 구체적 선택: \"유튜브 특화 LLM\"이 실제로는 YouTube Data API + Gemini 조합인지, 아니면 다른 서비스를 쓸지 결정해야 한다.\n\nS-6. 배치 후 효과 측정: JSON-LD 배치 전후로 SoM 점수가 실제로 변하는지 A/B 테스트 방법을 설계해야 한다.\n\n---\n\n## 10. 다음 대화(LN)에서 다룰 순서\n\nLN-A: 업종 가이드라인 JSON 초안 (의료 1개, 쇼핑 1개 실제 작성)\nLN-B: LLM별 프롬프트 및 출력 스키마 정의\nLN-C: Edge Function eeat-generate 상세 설계\nLN-D: GEOcare 기존 파이프라인과의 통합 설계\nLN-E: 효과 측정 및 A/B 테스트 설계\n\n---\n\n문서 상태: 설계 논의 중  \n다음 업데이트: LN-A (업종 가이드라인 초안) 완료 후\n",
  "related_slugs": [],
  "faq": [],
  "jsonld": null,
  "keywords": [],
  "source_id": "fd217235-cff5-4c97-91bb-cb36f64dd593",
  "video_url": null,
  "duration_sec": null,
  "thumbnail_url": null,
  "image_url": null,
  "caption": null,
  "solution_slug": null,
  "captured_at": null,
  "width": null,
  "height": null,
  "created_at": "2026-08-24T11:53:45.101247+00:00",
  "updated_at": "2026-08-24T11:53:45.101247+00:00",
  "visibility": "public",
  "source_stage": "1",
  "anonymized": true,
  "source_key": "legacy-khub",
  "origin": "ingest",
  "locked": false,
  "locked_by": null,
  "locked_at": null,
  "gate_state": {
    "g1": {
      "hits": [],
      "pass": true
    },
    "g2": {
      "pass": true,
      "total": 45,
      "issues": [
        "숫자·규격 같은 검증 가능한 구체가 부족합니다",
        "핵심 요약 불릿이 3개 미만입니다",
        "Q&A 쌍이 3개 미만입니다"
      ],
      "applies": true
    },
    "g3": {
      "pass": true,
      "required": false
    },
    "stage": "1",
    "decided_at": "2026-08-24T11:53:44.334Z"
  },
  "raw_id": "af54a311-d185-4485-bad7-855734c01199",
  "search_text": "⚙️ EEAT 부스터 오케스트레이션 설계서 v1.0  # EEAT 부스터 오케스트레이션 설계서 버전: v1.0 설계 초안 날짜: 2026년 2월 19일 상태: 설계 논의 중 (구현 전) 참고: bmp.ai/demo (삼성서울병원 심장내과 사례) --- ## 이 문서의 목적 bmp.ai/demo에서 시연된 EEAT Agen  # EEAT 부스터 오케스트레이션 설계서\n\n버전: v1.0 설계 초안  \n날짜: 2026년 2월 19일  \n상태: 설계 논의 중 (구현 전)  \n참고: bmp.ai/demo (삼성서울병원 심장내과 사례)\n\n---\n\n## 이 문서의 목적\n\nbmp.ai/demo에서 시연된 EEAT Agentic API의 구조를 기반으로, 실제 n8n 오케스트레이션으로 구현 가능한 기술 설계를 전개한다. 구현 코드는 다루지 않는다. Claude가 최종 제어탑 역할을 하면서 각 LLM이 자기 영역에서 자율적으로 JSON을 생성하는 구조를 설계한다.\n\n---\n\n## 1. bmp.ai/demo가 보여주는 것과 우리가 만들 것\n\n### bmp.ai/demo 현재 구조\n\nbmp.ai/demo는 단일 API 호출로 다음을 반환한다.\n\n- EEAT 점수 (Experience 3, Expertise 4, Authoritativeness 4, Trustworthiness 3, 총점 70)\n- gaps: 각 EEAT 축별로 부족한 부분 (예: 환자 후기 없음, 전문 의료진 자격 정보 부족)\n- suggested_faqs: 만들어야 할 FAQ 목록 (키워드와 답변 방향 포함)\n- content_brief: 콘텐츠 제작 가이드 (톤, 권장 단어수, H2 구성)\n- schema_recommendations: 적용해야 할 Schema.org 타입 (FAQPage, MedicalOrganization 등)\n\n이것은 \"진단\"이다. 우리가 만들 것은 진단 이후의 \"자동 치료\"까지 포함하는 전체 파이프라인이다.\n\n### 우리의 확장 범위\n\n진단(bmp.ai/demo가 하는 것)에서 끝나지 않고, 진단 결과를 기반으로 각 LLM이 자율적으로 콘텐츠를 생성하고, 그 결과물이 JSON-LD로 조립되어 실제 배포까지 이어지는 흐름이다.\n\n---\n\n## 2. 전체 오케스트레이션 흐름\n\n### 2-1. 5단계 파이프라인\n\n1단계 진단: 사이트를 크롤링하고 현재 EEAT 상태를 분석한다.\n2단계 처방: 업종별 YMYL 가이드라인을 적용하여 무엇을 보강해야 하는지 결정한다.\n3단계 생성: 각 LLM이 자기 전문 영역에서 JSON 데이터를 자율 생성한다.\n4단계 조립: Claude가 모든 JSON을 검증하고 JSON-LD로 통합 조립한다.\n5단계 배치: 목적에 맞게 JSON-LD를 사이트에 배치한다.\n\n### 2-2. 단계별 상세\n\n1단계 진단 (입력: 도메인 URL)\n\nn8n이 크롤링을 실행한다. Firecrawl 또는 BrightData로 사이트 HTML을 수집한다. 기존 JSON-LD가 있는지, meta 태그는 어떤지, 콘텐츠 양은 얼마인지, FAQ가 있는지 등을 파싱한다. 결과를 Supabase gp_geoex_kpi_analysis 테이블에 저장한다.\n\n이 단계의 출력은 bmp.ai/demo와 동일한 구조의 JSON이다. EEAT 점수, gaps, suggested_faqs, content_brief, schema_recommendations.\n\n2단계 처방 (입력: 진단 결과 + 업종 코드)\n\n업종별 YMYL 가이드라인을 적용한다. 이 부분이 핵심 차별점이다. 같은 EEAT 부족이라도 의료업종과 쇼핑몰은 보강 방법이 완전히 다르다. Claude가 진단 결과와 업종 가이드라인을 읽고, 어떤 LLM에게 어떤 작업을 할당할지 \"작업 지시서\"를 생성한다.\n\n3단계 생성 (입력: 작업 지시서)\n\n각 LLM이 자기 전문 영역에서 JSON을 독립적으로 생성한다. n8n이 Edge Function을 통해 병렬 호출하고, 각 LLM의 결과가 개별 JSON 파일로 Supabase에 저장된다.\n\n4단계 조립 (입력: 개별 JSON 파일들)\n\nClaude가 모든 결과를 검증한다. 중복 제거, 일관성 확인, Schema.org 규격 검증을 수행한다. 최종적으로 하나의 통합 JSON-LD 패키지를 생성한다.\n\n5단계 배치 (입력: JSON-LD 패키지 + 배치 전략)\n\n목적에 따라 JSON-LD를 배치한다. GTM 태그로 동적 삽입하거나, Brand Hub HTML에 직접 삽입하거나, SSR 서버에서 렌더링하는 등 여러 방식이 가능하다.\n\n---\n\n## 3. 업종별 YMYL 가이드라인 체계\n\n### 3-1. YMYL이란\n\nYMYL은 Your Money or Your Life의 약자로, 구글이 사람의 건강, 안전, 재정에 영향을 미치는 콘텐츠에 더 높은 품질 기준을 적용하는 정책이다. 이 업종들은 EEAT 기준이 일반 업종보다 훨씬 엄격하다.\n\n### 3-2. 업종 분류 체계\n\nTier A (엄격한 YMYL): 의료/건강, 금융/보험, 법률, 뉴스/시사\nTier B (중간 YMYL): 교육, 부동산, 정부/공공, B2B SaaS\nTier C (일반): 이커머스/쇼핑, 요식/외식, 여행/레저, 엔터테인먼트\n\n### 3-3. 업종별 가이드라인이 결정하는 것\n\n각 업종 가이드라인은 JSON 파일로 관리되며, 다음을 정의한다.\n\n필수 Schema.org 타입: 의료는 MedicalOrganization과 MedicalWebPage, 금융은 FinancialProduct와 BankOrCreditUnion, 쇼핑은 Product와 Offer와 AggregateRating 등.\n\nEEAT 보강 우선순위: 의료는 Expertise와 Trustworthiness가 최우선(의사 자격증, 임상 데이터), 쇼핑은 Experience가 최우선(구매 후기, 사용 사례).\n\n콘텐츠 필수 섹션: 의료는 전문 의료진 소개, 인증 및 수상 내역, 치료 성과, 환자 후기 등. 쇼핑은 상품 상세, 구매자 리뷰, 비교 정보, 반품/교환 정책 등.\n\n금지 사항: 의료는 미검증 치료법 주장 금지, 금융은 수익률 보장 표현 금지 등.\n\nFAQ 생성 방향: 업종별로 사람들이 가장 많이 묻는 질문 유형이 다르다. 의료는 증상과 치료법 중심, 쇼핑은 가격과 배송 중심.\n\n### 3-4. 가이드라인 저장 위치\n\nSupabase에 gp_eeat_ymyl_guidelines 테이블로 관리한다. industry_code(의료, 금융, 쇼핑 등), ymyl_tier(A/B/C), required_schemas, eeat_priorities, content_requirements, prohibited_patterns, faq_templates 필드를 갖는다.\n\nClaude가 2단계 처방에서 이 테이블을 조회하여 해당 업종의 가이드라인을 참조한다.\n\n---\n\n## 4. 각 LLM의 역할과 자율 JSON 생성\n\n### 4-1. 핵심 원칙\n\n각 LLM은 자기가 잘하는 영역에서 독립적으로 JSON을 생성한다. n8n이 작업을 분배하고, 각 LLM은 정해진 JSON 스키마에 맞춰 결과를 반환한다. Claude가 최종적으로 모든 결과를 검증하고 조립한다.\n\n### 4-2. LLM별 역할 분담\n\nClaude (Opus 4.6) - 총괄 제어 및 핵심 콘텐츠\n\n역할: 오케스트레이션 두뇌. 작업 지시서 생성, 결과 검증, JSON-LD 최종 조립.\n자율 생성 영역: EEAT 핵심 콘텐츠 (Organization 소개, Expertise 섹션, Trust 신호), content_brief 기반 본문 텍스트, Schema.org JSON-LD 통합 패키지.\n출력 JSON: eeat_core.json (Organization, expertise_content, trust_signals, schema_package)\n\nPerplexity (Sonar) - 실시간 웹 검증 및 인용\n\n역할: 현재 웹에서 브랜드가 어떻게 언급되고 있는지 실시간 검증.\n자율 생성 영역: SoM 분석 (4개 LLM 응답에서 브랜드 멘션 비율), 경쟁사 대비 포지셔닝, 최신 뉴스와 리뷰 요약, 인용 가능한 외부 소스 목록.\n출력 JSON: web_intelligence.json (som_scores, competitor_positioning, recent_mentions, citable_sources)\n\nGemini (2.0 Flash) - 대량 구조화 데이터 처리\n\n역할: 비용 효율적인 대량 데이터 처리.\n자율 생성 영역: 상품 카탈로그 파싱 (Product/Offer Schema 대량 생성), FAQ 초안 대량 생성 (업종별 템플릿 기반), Breadcrumb와 SiteNavigationElement 자동 생성.\n출력 JSON: structured_data_bulk.json (products, faqs_draft, navigation, breadcrumbs)\n\nChatGPT (GPT-4o) - 품질 정규화 및 Action Rules\n\n역할: 다른 LLM 결과물의 품질 게이트.\n자율 생성 영역: 콘텐츠 톤/스타일 정규화, 중복 및 모순 감지, 실행 가능한 Action Rules 추출 (자동화 가능한 개선 항목 목록).\n출력 JSON: quality_gate.json (normalized_content, duplicates_removed, action_rules)\n\n유튜브 특화 (YouTube Data API + Gemini)\n\n역할: 유튜브 채널 및 영상 데이터 수집과 구조화.\n자율 생성 영역: 채널 정보 (VideoObject Schema), 인기 영상 요약, 유튜브 댓글에서 FAQ 후보 추출, 영상 트랜스크립트 기반 콘텐츠 생성.\n출력 JSON: youtube_data.json (channel_schema, video_objects, comment_faqs, transcript_content)\n\n소셜/커뮤니티 특화 (BrightData + GPT-4o-mini)\n\n역할: 네이버 블로그, 카페, 인스타그램 등 소셜 채널 데이터.\n자율 생성 영역: 브랜드 멘션 수집, 사용자 후기/리뷰 요약, 소셜 증거(Social Proof) 데이터, 커뮤니티 FAQ 추출.\n출력 JSON: social_data.json (brand_mentions, review_summary, social_proof, community_faqs)\n\n### 4-3. JSON 출력 규격 통일\n\n모든 LLM의 출력은 다음 공통 메타데이터를 포함한다.\n\n- source_llm: 어떤 LLM이 생성했는지\n- generated_at: 생성 시각\n- confidence: 신뢰도 점수 (0에서 1)\n- site_domain: 대상 도메인\n- industry_code: 업종 코드\n\n이 공통 메타데이터가 있어야 Claude가 4단계에서 결과를 취합하고 검증할 수 있다.\n\n---\n\n## 5. n8n 오케스트레이션 설계\n\n### 5-1. 워크플로우 구조\n\n전체를 하나의 거대 워크플로우로 만들지 않는다. 단계별로 분리하고 n8n 서브워크플로우 체이닝으로 연결한다.\n\nWF-EEAT-DIAG-001: 진단 워크플로우\n\n트리거: Webhook (온보딩 완료 시) 또는 스케줄 (정기 재진단)\n내용: 크롤링 실행, 기존 JSON-LD 파싱, EEAT 점수 산출, gaps 분석\n출력: gp_eeat_diagnosis 테이블에 진단 결과 저장\n다음: WF-EEAT-PRESC-001 호출\n\nWF-EEAT-PRESC-001: 처방 워크플로우\n\n트리거: 서브워크플로우 호출 (진단 완료 시)\n내용: 업종 가이드라인 조회, Claude API로 작업 지시서 생성, 각 LLM에 할당할 작업 목록 확정\n출력: gp_eeat_prescriptions 테이블에 작업 지시서 저장\n다음: WF-EEAT-GEN-001 호출\n\nWF-EEAT-GEN-001: 생성 워크플로우 (핵심)\n\n트리거: 서브워크플로우 호출 (처방 완료 시)\n내용: Edge Function을 통해 각 LLM 병렬 호출. 작업 지시서에 따라 필요한 LLM만 호출한다. 예를 들어 유튜브 채널이 없는 파트너는 유튜브 LLM을 건너뛴다.\n출력: gp_eeat_generated_jsons 테이블에 각 LLM의 결과 JSON 저장\n다음: WF-EEAT-ASSEMBLE-001 호출\n\nWF-EEAT-ASSEMBLE-001: 조립 워크플로우\n\n트리거: 서브워크플로우 호출 (생성 완료 시)\n내용: Claude API로 모든 JSON 검증 및 통합. Schema.org 규격 준수 확인, 중복 제거, 최종 JSON-LD 패키지 생성.\n출력: gp_eeat_jsonld_packages 테이블에 최종 패키지 저장\n다음: WF-EEAT-DEPLOY-001 호출\n\nWF-EEAT-DEPLOY-001: 배치 워크플로우\n\n트리거: 서브워크플로우 호출 (조립 완료 시)\n내용: 목적에 따라 배치. Brand Hub 페이지 생성 및 배포, GTM 태그 업데이트, 또는 고객에게 가이드 이메일 발송.\n출력: 배포 완료 상태 업데이트, 알림 발송\n\n### 5-2. Edge Function 역할\n\nn8n이 5개 LLM을 순차로 호출하면 느리다. Edge Function som-benchmark 패턴을 확장하여, eeat-generate라는 새 Edge Function이 작업 지시서를 받아 해당 LLM들을 Promise.allSettled()로 병렬 호출한다.\n\nEdge Function이 받는 입력: 작업 지시서 JSON (어떤 LLM에게 어떤 프롬프트로 호출할지)\nEdge Function이 하는 일: 각 LLM API 병렬 호출, 개별 결과를 즉시 Supabase INSERT, 성공/실패 집계 후 n8n에 응답\nn8n이 하는 일: 배치 분할, Edge Function 호출, 에러 시 재시도, 다음 단계 트리거\n\n### 5-3. Claude의 제어 지점\n\nClaude는 두 곳에서 개입한다.\n\n처방 단계(WF-EEAT-PRESC-001): 진단 결과와 업종 가이드라인을 분석하여 작업 지시서를 생성한다. 이것이 전체 파이프라인의 방향을 결정하는 가장 중요한 단계다.\n\n조립 단계(WF-EEAT-ASSEMBLE-001): 각 LLM이 생성한 JSON들을 검증하고 최종 JSON-LD로 통합한다. 여기서 품질 관리가 이루어진다.\n\n나머지 단계(진단, 생성, 배치)에서 Claude는 직접 개입하지 않는다. n8n과 Edge Function이 자동으로 처리한다.\n\n---\n\n## 6. JSON-LD 배치 전략\n\n### 6-1. 목적별 배치 방식\n\n배치는 단순히 JSON-LD를 사이트에 넣는 게 아니다. 목적에 따라 배치 방식이 달라진다.\n\n방식 1: Brand Hub 직접 삽입 (우리가 사이트를 생성하는 경우)\n\nBrand Hub HTML의 head에 JSON-LD를 직접 삽입한다. LLM 크롤러가 JavaScript 없이도 읽을 수 있는 가장 확실한 방법이다. 파트너 자체 사이트가 없거나 수정 권한이 없는 경우에 사용한다.\n\n방식 2: GTM 동적 삽입 (파트너가 GTM을 사용하는 경우)\n\n파트너 사이트의 GTM 컨테이너에 커스텀 HTML 태그를 추가한다. Supabase에서 해당 도메인의 JSON-LD를 실시간 조회하여 삽입한다. 태깅 대행사 모델에 적합하다. 다만 LLM 크롤러 중 JavaScript를 실행하지 않는 경우 인식되지 않는다.\n\n방식 3: SSR 삽입 (파트너가 자체 개발팀이 있는 경우)\n\n파트너 서버에서 페이지 렌더링 시 Supabase API를 호출하여 JSON-LD를 서버 사이드에서 삽입한다. 가장 이상적이지만 파트너 개발팀의 협조가 필요하다.\n\n방식 4: 하이브리드 (권장)\n\n핵심 데이터(Organization, 핵심 Product, 상위 5개 FAQ)는 Brand Hub에 직접 삽입하고, 변동성 높은 데이터(리뷰, 가격, 재고)는 GTM으로 동적 삽입한다. 이전 대화에서 이미 결론 내린 전략과 동일하다.\n\n### 6-2. JSON-LD 패키지 구성\n\n최종 조립된 JSON-LD 패키지는 다음 구조를 갖는다.\n\nOrganization JSON-LD: 기업/브랜드 기본 정보, sameAs 링크, contactPoint\nProduct/Service JSON-LD: 상품 또는 서비스 상세, Offer, AggregateRating\nFAQPage JSON-LD: 업종별 맞춤 FAQ (suggested_faqs + 소셜/커뮤니티에서 추출한 실제 질문)\nArticle/BlogPosting JSON-LD: 콘텐츠 브리프 기반 생성 글\nVideoObject JSON-LD: 유튜브 영상 구조화 데이터\n업종 특화 JSON-LD: MedicalOrganization(의료), FinancialProduct(금융), LocalBusiness(로컬) 등\n\n---\n\n## 7. 데이터 흐름 요약\n\n입력: 파트너 도메인 URL + 업종 코드\n\n1단계 진단 결과: EEAT 점수, gaps, schema_recommendations (Supabase 저장)\n2단계 처방 결과: 작업 지시서 JSON (어떤 LLM에게 무엇을 시킬지) (Supabase 저장)\n3단계 생성 결과: LLM별 개별 JSON (eeat_core, web_intelligence, structured_data_bulk, quality_gate, youtube_data, social_data) (Supabase 저장)\n4단계 조립 결과: 통합 JSON-LD 패키지 (Supabase 저장)\n5단계 배치 결과: 배포 완료 URL 또는 GTM 태그 ID (Supabase 저장)\n\n모든 중간 결과가 Supabase에 저장되므로, 어느 단계에서 실패하더라도 해당 단계부터 재실행할 수 있다.\n\n---\n\n## 8. 이전 대화에서 확정된 사항과의 연결\n\nSoM 병렬처리 아키텍처: 3단계 생성에서 동일한 Edge Function 병렬 패턴을 사용한다.\n\n멀티 LLM 역할 분담: 이 문서의 4-2항이 이전 마스터 문서의 2-3항을 구체화한 것이다.\n\nHuman-in-the-Loop 비용 승인: 3단계에서 LLM 호출 비용이 임계값을 초과하면 Slack 승인을 요청한다.\n\nBrand Hub 자동 배포: 5단계가 이전 마스터 문서의 Phase 2(Brand Hub MVP)를 실현하는 구체적 흐름이다.\n\n---\n\n## 9. 미결 설계 항목 (다음 대화에서 논의)\n\nS-1. 업종 가이드라인 초안: Tier A(의료), Tier C(쇼핑) 각 1개씩 실제 가이드라인 JSON을 만들어 구조를 검증해야 한다.\n\nS-2. LLM 프롬프트 설계: 각 LLM에게 보낼 시스템 프롬프트와 출력 JSON 스키마를 구체적으로 정의해야 한다.\n\nS-3. Edge Function eeat-generate 상세 설계: som-benchmark 패턴을 확장하되, LLM 종류와 개수가 동적으로 변하는 구조를 어떻게 처리할지 결정해야 한다.\n\nS-4. 기존 GEOcare 파이프라인과의 통합 지점: Phase0 온보딩, Phase1 크롤링, Phase2 KPI 분석과 이 EEAT 파이프라인이 어디서 합류하는지 명확히 해야 한다.\n\nS-5. 유튜브/소셜 LLM의 구체적 선택: \"유튜브 특화 LLM\"이 실제로는 YouTube Data API + Gemini 조합인지, 아니면 다른 서비스를 쓸지 결정해야 한다.\n\nS-6. 배치 후 효과 측정: JSON-LD 배치 전후로 SoM 점수가 실제로 변하는지 A/B 테스트 방법을 설계해야 한다.\n\n---\n\n## 10. 다음 대화(LN)에서 다룰 순서\n\nLN-A: 업종 가이드라인 JSON 초안 (의료 1개, 쇼핑 1개 실제 작성)\nLN-B: LLM별 프롬프트 및 출력 스키마 정의\nLN-C: Edge Function eeat-generate 상세 설계\nLN-D: GEOcare 기존 파이프라인과의 통합 설계\nLN-E: 효과 측정 및 A/B 테스트 설계\n\n---\n\n문서 상태: 설계 논의 중  \n다음 업데이트: LN-A (업종 가이드라인 초안) 완료 후\n",
  "embedding": null,
  "embedded_at": null,
  "embedding_hash": null,
  "backlinks": [],
  "html_url": "https://bizspring.ai/kb/ref/khub/premium-geo-eeat-부스터-오케스트레이션-설계서-v1-0",
  "markdown_url": "https://bizspring.ai/kb/ref/khub/premium-geo-eeat-부스터-오케스트레이션-설계서-v1-0.md"
}