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