- 데이터 스키마
- 리스닝마인드 MCP 연동 워크플로우
워크플로우 개요
이 섹션은 앞에서 정의한 GEO 를 위한 데이터 스키마에 실제 ListeningMind 데이터를 주입하여 GEO 시스템을 구축하는 전 과정을 다룹니다. 6단계 순차 프로세스로 구성되며, 각 단계의 리스닝마인드 DaaS API 입력·출력 예시로 작성되어 있습니다.
- Stage 1 – Seed 키워드 세팅 : 분석할 브랜드·카테고리를 대표하는 핵심 키워드를 선정합니다. 이 시드 키워드가 전체 분석의 출발점이 됩니다.
- Stage 2 – 근거 데이터 추출 : 리스닝마인드 DaaS MCP 또는 API로 각 엔드포인트를 호출하여 실제 검색 데이터(로데이터)를 수집하고 DB에 적재합니다.
- Stage 3 – CEP 확정 라벨링 : 수집 데이터를 기반으로 소비자가 카테고리에 진입하는 핵심 상황/맥락(CEP, Category Entry Point)을 사람이 직접 확정하고 라벨링합니다.
- Stage 4 – 쿼리 생성 : 확정된 핵심 상황/맥락(CEP, Category Entry Point)별로 실제 소비자가 AI에게 물어볼 법한 질문(Query)을 AI 에이전트가 체계적으로 자동 생성합니다.
- Stage 5 – 메세지 프레임워크 설계 : 쿼리에 대한 브랜드 응답 메시지를 설계합니다. 사용자 만족을 위한 브랜드 메시지 프레임워크를 구축합니다.
- Stage 6 – GEO 테스트 : LLM 응답에서 브랜드 호출 성공/실패를 Pass/Fail로 판정하고, 결과를 피드백하여 워크플로우를 지속 개선합니다.
역할 분담 가이드
- 데이터 엔지니어: API 설정, 데이터 추출·적재
시드 키워드 구성, 리스닝마인드 DaaS API/MCP 연동, 각 엔드포인트를 호출해 검색 로데이터를 수집하고 DB에 적재합니다. - 마케터/브랜드팀: CEP 라벨링, AI Inference Role 확정
수집된 키워드 데이터를 직접 분석하여 소비자가 카테고리에 진입하는 핵심 상황/맥락(CEP)을 확정하고 라벨링합니다. AI가 어떤 역할로 추론할지도 결정합니다. - 디지털 마케팅 에이전시: 쿼리 확장, 메시지 생성
확정된 CEP 기반으로 실제 소비자 질문(Query)을 체계적으로 확장·생성하고, 각 쿼리에 대한 브랜드 응답 메시지 프레임워크를 설계합니다. - 모니터링 분석팀: GEO 테스트 및 피드백
생성된 쿼리를 ChatGPT, Gemini 등 실제 LLM에 투입하여 브랜드 호출 여부를 Pass/Fail로 판정하고, 결과를 피드백해 워크플로우를 지속 개선합니다.
Stage 1: Seed 키워드 세팅 (1회)
- 목적: LM API 호출의 기준이 되는 핵심 키워드(Seed)와 조회 파라미터를 설정합니다.
- 실행 주체: 데이터 엔지니어 + 마케터 협의
- 컨텍스트 입력: 브랜드 전략 문서, 카테고리 정의
- 산출물: Seed 키워드 목록 + API 파라미터 설정 파일
Seed 키워드 설계 원칙
기본 3계층으로 구성합니다. 산업과 제품에 따라 시드 구성은 달라질 수 있습니다.
주의— 시드 키워드가 너무 적으면 시장 경계를 놓치고, 너무 많으면 노이즈가 증가합니다. 시장 전체를 탐색하고 경쟁 관계를 파악하고 인접 시장의 진입점을 놓치지 않도록 설계합니다.
| 계층 | 역할 | 예시 | 권장 수량 |
| L1: 카테고리 Seed | 시장 전체 탐색 | 콤부차 | 1~2개 |
| L2: 브랜드 Seed | 자사·경쟁사 포지션 | 티젠 콤부차, 담터 콤부차, 아임얼라이브 콤부차 | 3~5개 |
| L3: 상황 Seed | 인접 시장 진입점 | 탄산 대체, 에너지 드링크 대체, 콤부차 다이어트 | 3~5개 |
리스닝마인드 DaaS API 파라미터 기본 설정
| 파라미터 | 값 | 설명 |
| gl | kr | 한국 시장 |
| hop | 2 | 초기 구축 : hop=2로 시작 확장 검토 : 시장 경계가 좁게 잡히는 경우만 hop=3 검토 |
| limit | 500 (cluster_finder) / 300 (path_finder) | 분석 가능한 적정 데이터량 |
| time_point | curr | 현재 시점 기준 (비교 시 3m, 6m 등 활용) |
| orientation | UNDIRECTED | 양방향 관계 탐색 |
주의— hop 설정 : hop=3은 데이터량이 급증하며 인접 카테고리 노이즈가 포함될 수 있습니다. 초기 구축 시 hop=2로 시작하고, 시장 경계가 좁게 잡히는 경우에만 hop=3으로 확장을 검토합니다.
Stage 2: 근거 데이터 추출 (ListeningMind DaaS API)
- 목적: ListeningMind DaaS API를 호출해 로데이터(rawdata)를 추출하여 DB 원본으로 적재
- 실행 주체: 데이터 엔지니어
엔드포인트별 호출 순서와 목적
호출 순서는 cluster_finder가 시장 구조를 잡고, 그 결과를 path_finder와 intent_finder가 심화하는 구조입니다.
| [Step 1] cluster_finder (communities) → 시장 구조 파악 ↓ [Step 2] cluster_finder (rels) → 경쟁 관계 추출 ↓ [Step 3] path_finder → 검색 여정 추출 ↓ [Step 4] intent_finder + keyword_info → 볼륨·인텐트 태깅 |
cluster_finder 호출 가이드
리스닝마인드 DaaS API의 클러스터 파인더를 호출해 데이터를 수집한 다음 DB로 변환하기 위해서, 다음과 같이 제품 카테고리 구조에 따른 마켓 바운더리를 정의하고, CEP_Master 후보군을 가려냅니다. 이 사례의 경우, 카테고리 일반 키워드, 비콤부차 키워드, 브랜드 키워드, 제형/채널 키워드 등으로 DB 구성할 수 있습니다.
호출 1: /cluster_finder (data_type=”communities” (시장 구조))
POST/Cluster_finder
{
"keyword": "콤부차",
"gl": "kr",
"time_point": "curr",
"hop": 2,
"orientation": "UNDIRECTED",
"limit": 500,
"data_type": "communities" (또는 "all")
}실제 추출 결과→ DB 변환예시
실제 추출 데이터는 Community 그룹별 포함 키워드로 구성되어 있습니다. 카테고리 분류값, CEP 후보군 라벨링으로 변환하는 작업이 필요합니다.
| LM 원본 (community) | 포함 키워드 (상위 5개) | DB 변환 결과 |
| Community 0 | 프레시코, 아임얼라이브, 가루음료 추천, 물에 타먹는, 수레타 | → Category.sub_category: “스틱/가루 제형” |
| → CEP_Master 후보: “가루 음료를 찾는 상황” | ||
| Community 1 | 에너지 드링크 대체, 카페인 대체 음료, 커피 대신 | → Category.adjacent_life_solutions: “카페인 대체” |
| → CEP_Master 후보: “카페인 없이 에너지를 원하는 상황” | ||
| Community 2 | 탄산 대체, 콜라 대체, 콜라 끊기, 씨그램 | → Category.adjacent_life_solutions: “탄산 대체” |
| → CEP_Master 후보: “탄산음료를 끊으려는 상황” | ||
| Community 7 | 티젠 콤부차 피치, 티젠 콤부차 라즈베리, 담터 콤부차 | → CEP_Master 후보: “티젠 맛 비교 상황” |
| → Option_Space.direct_competitors: 담터 |
변환 규칙
| community 특성 | DB 매핑 대상 | 판단 기준 |
| 카테고리 일반 키워드 중심 | Category.main_category | “콤부차 효능”, “콤부차 뜻” 등 카테고리명 포함 |
| 브랜드 키워드 중심 | CEP_Master + Option_Space | “티젠”, “담터”, “오설록” 등 브랜드명 포함 |
| 비-콤부차 키워드 중심 | Category.adjacent_life_solutions | “탄산 대체”, “에너지 드링크” 등 콤부차 외 카테고리 |
| 제형/채널 키워드 중심 | Category.sub_category | “스틱”, “가루”, “올리브영” 등 |
휴먼 판단 필요: community 라벨링은 자동화할 수 없습니다. 포함 키워드를 검토하여 마케터가 의미를 해석하고 DB 카테고리를 부여해야 합니다. 이 과정이 Stage 3의 핵심입니다.
호출 2: rels (경쟁 관계)
다음은 cluster_finder의 data_type=”rels”를 활용해 카테고리와 브랜드의 연결, 브랜드 간 비교 관계, 인접 시장, 세부 맥락 등을 파악하고, DB 변환하는 예시입니다.
POST/Cluster_finder
{
"keyword": "콤부차",
"gl": "kr",
"time_point": "curr",
"hop": 2,
"orientation": "UNDIRECTED",
"limit": 500,
"data_type": "rels"
}실제 추출 결과 → DB 변환 예시
| rels 원본 | 해석 | DB 변환 |
| [“콤부차”, “콤 부차 티젠”] | 카테고리 → 브랜드 연결 | Option_Space.direct_competitors += “티젠” |
| [“콤 부차 티젠”, “담터 콤부차”] | 브랜드 간 비교 관계 | Option_Space.comparison_axes += “티젠 vs 담터” |
| [“콤부차”, “탄산 대체”] | 카테고리 → 인접 시장 | Category.adjacent_life_solutions += “탄산 대체” |
| [“탄산 대체”, “콜라 대신 탄산수”] | 인접 시장 내 세부 맥락 | Option_Space.indirect_competitors += “탄산수” |
| [“콤부차 카페인”, “콤 부차 티젠”] | 성분 우려 → 브랜드 검증 | CEP 후보: “카페인이 걱정되어 특정 브랜드를 확인하는 상황” |
경쟁 관계 추출 패턴
| 패턴 | 조건 | 분류 |
| 브랜드 ↔ 브랜드 | 양쪽 모두 브랜드명 포함 | Direct Competitor |
| 카테고리 ↔ 비카테고리 | 한쪽이 콤부차 외 카테고리 | Indirect Competitor |
| 브랜드 ↔ 속성 | 한쪽이 성분/효능/부작용 | Comparison Axis |
| 카테고리 ↔ 브랜드 | 카테고리명 → 브랜드명 | Brand Salience 지표 |
호출 3. path_finder 호출 가이드
다음은 path_finder 원천 데이터를 추출해 고객의 검색 경로에 나타나는 키워드 패턴을 분석하고, 구매 여정 단계코드를 맵핑하는 예시입니다.
Path_finder 호출
POST/path_finder
{
"keyword": "콤부차",
"gl": "kr",
"time_point": "curr",
"limit": 300
}여정 단계(Journey Stage) 매핑 방법
| 여정 단계 | 코드 | 분류 기준 | 대표 키워드 |
| 정보 탐색 (Information) | INFO | 뜻, 효능, 원리, 성분 등 정보성 키워드 | 콤부차 뜻, 콤부차 효능, 콤부차 카페인 |
| 평가 (Evaluation) | EVALUATION | 부작용, 단점, 비교, 후기 등 검증 키워드 | 콤부차 부작용, 콤부차 단점, 콤부차 더쿠 |
| 선택 (Choice) | CHOICE | 브랜드명, 맛추천, 추천 등 선택 키워드 | 티젠 콤부차, 콤부차 맛추천, 콤부차 브랜드 |
| 구매 (Buy) | BUY | 가격, 채널, 구매 관련 키워드 | 올리브영 콤부차, 콤부차 가격, 다이소 콤부차 |
카테고리 Seed(“콤부차”) 대표 경로
| path_finder 원본 경로 | Journey Stage 매핑 | 전략적 시사점 |
| 콤부차 → 콤부차 효능 → 콤부차 카페인 | INFO → INFO → INFO | 정보 탐색 루프. 효능 확인 후 안전성 검증으로 이동 |
| 콤부차 → 콤부차 다이어트 → 콤부차 효능 → 콤부차 하루 섭취량 | INFO → EVALUATION → INFO → INFO | 다이어트 목적 진입 → 효능 확인 → 섭취 방법으로 심화 |
| 콤부차 → 콤 부차 티젠 → 담터 콤부차 → 티젠 콤부차 | INFO → CHOICE → CHOICE → CHOICE | 브랜드 비교 여정. 티젠↔담터 비교 후 티젠으로 수렴 |
| 콤부차 → 콤부차 효능 → 콤부차 단점 → 콤부차 당뇨 → 콤부차 다이어트 → 콤부차 카페인 | INFO → INFO → EVALUATION → EVALUATION → EVALUATION→ INFO | 안전성 우려 루프. 당뇨/카페인 반복 검증 |
브랜드 Seed(“티젠 콤부차”) 대표 경로
| path_finder 원본 경로 | Journey Stage 매핑 | 전략적 시사점 |
| 티젠 콤부차 → 티젠 콤부차 맛 → 콤부차 효능 → 티젠 콤부차 효능 | CHOICE → CHOICE → INFO → EVALUATION | 브랜드 진입 후 역방향으로 효능 재확인 |
| 티젠 콤부차 → 티젠 콤부차 효능 → 티젠 콤부차 부작용 | CHOICE → EVALUATION → EVALUATION | 브랜드 지명 후 안전성 검증 집중 |
| 티젠 콤부차 → 티젠 콤부차 효능 → 티젠 콤부차 부작용 → 티젠 콤부차 다이어트 | CHOICE → EVALUATION→ EVALUATION → EVALUATION | 부작용 확인 후 다이어트 목적 확인 |
| 티젠 콤부차 → 티젠 콤부차 칼로리 → 티젠 콤부차 부작용 → 티젠 콤부차 맛추천 | CHOICE → EVALUATION→ EVALUATION → CHOICE | 안전성 확인 후 맛 선택으로 복귀 |
| 티젠 콤부차 → 티젠 콤부차 다이어트 → 콤부차 다이어트 후기 → 콤부차 효능 | CHOICE → EVALUATION → EVALUATION → INFO | 브랜드 다이어트 탐색 → 카테고리 효능으로 확장 |
Answer Framework 순서 개선 근거 — path_finder 패턴 인사이트
검색 경로에서 나타나는 키워드 패턴은 고객 경험 증대를 위한 콘텐츠 생성 및 AI 답변 생성 로직을 구현하는데 활용합니다.
| 패턴 | 빈도 | Answer Framework 반영 |
| 효능 → 카페인/부작용 확인 | 최다 빈도 | Framing(효능) 직후 Safety 정보를 선제 제공 |
| 브랜드 진입 → 역방향 효능 확인 | 고빈도 | Brand Role 단계에서 효능 근거를 함께 제시 |
| 다이어트 → 하루 섭취량 | 고빈도 | 다이어트 CEP에서 섭취 가이드를 Next Step이 아닌 Reasoning에 포함 |
| 브랜드 비교 → 특정 브랜드 수렴 | 중빈도 | Option Space에서 비교 축 명시 후 Brand Role 자연 전환 |
| 부작용 확인 → 맛추천 복귀 | 중빈도 | 안전성 해소 후 제품 추천으로 연결하는 구조 |
핵심 발견 : 티젠 콤부차 경로에서 “효능 → 부작용 → 다이어트” 3단계 검증 루프가 반복적으로 나타납니다. 이는 소비자가 구매 전 안전성을 반복 확인한다는 의미이므로, AI 답변에서 사용자의 우려를 불식시킬 근거(Proof Hook)을 강화하여 선제적으로 해소해야 합니다.
호출 4. intent_finder + keyword_info 호출 가이드
intent_finder 호출
{
"keywords": [
"콤부차 추천",
"콤부차 브랜드",
"콤부차 하이볼", ...
],
"gl": "kr",
"volume_threshold": 100,
"limit": 100,
"sort": "volume_avg",
"order": "desc"
}실제 추출 결과(반환 키워드) DB 변환 예시
| 반환 키워드 | 역할 | DB 주입 대상 |
| 콤부차 추천 | 비교/선택 쿼리 | → Query_Templates (P4 패턴) |
| 티젠 콤부차 맛추천 | 브랜드 내 선택 | → Query_Templates (P4) + CEP-07 연결 |
| 콤부차 하이볼 | 신규 음용 상황 | → CEP_Master 후보 (하이볼 상황) |
| 노브랜드 콤부차 | 채널별 탐색 | → Option_Space (채널 경쟁) |
| 콤부차 탄산수 | 제형/조합 탐색 | → Category.sub_category 확장 |
| 티젠 콤부차 요거트 | 맛 변형 탐색 | → Lexicon (TiZen Unique Terms 후보) |
keyword_info 호출
{
"keywords": [
Stage 1~3에서 확보한 전체 키워드 목록
],
"gl": "kr",
"data_type": "all"
}DB 주입 대상: 전체 키워드 테이블의 볼륨/트렌드/인텐트/인구통계 메타데이터
| 반환 데이터 | DB 주입 대상 | 활용 목적 |
| ads_metrics (volume_avg, volume_trend, cpc) | Query_Templates.volume_score, CEP_Master.priority_score | 우선순위 산정 |
| intents (I/C/T/N) | CEP_Master.intent_class, Query_Templates.query_pattern | 인텐트 자동 태깅 |
| demography (gender_ratio, age_ratio) | CEP_Master.persona 검증 | 페르소나 데이터 근거 |
| features (SERP 스니펫) | Message_Framework 참고 | AI Overview 등장 여부 → GEO 우선순위 판단 |
| monthly_volume | 트렌드/계절성 분석 | 업데이트 주기 판단, 시즌 전략 |
Priority Score 산출 로직
| priority_score = (volume_avg / max_volume_avg) × 70 + (1 – abs(volume_trend)) × 20 + intent_weight × 10 intent_weight: I=0.3, C=0.8, T=1.0, N=0.5 |
검색량(70%)을 기본으로 하되, 트렌드 안정성(20%)과 구매 근접 인텐트(10%)를 가중. T(거래) 인텐트가 최고 가중치 — GEO의 최종 목표가 구매 전환이기 때문.
SERP Features 기반 GEO 우선순위 판단
| SERP Feature | 의미 | GEO 전략 영향 |
| f_ai_overview = 1 | Google AI Overview 노출 | 최우선 GEO 타겟. AI가 이미 답변을 생성하는 쿼리 |
| f_featured_snippet = 1 | 추천 스니펫 노출 | 구조화된 답변이 유효한 쿼리 |
| f_people_also_ask_for = 1 | “관련 질문” 노출 | Chain Query 설계의 근거 |
| f_knowledge_panel = 1 | 지식 패널 노출 | 브랜드 인지도 기반 쿼리 |
실제 데이터 기반 GEO 우선순위 판단 예시
| 키워드 | AI Overview | PAA | 인텐트 | GEO 우선순위 |
| 콤부차 | ✅ | ✅ | C | ★★★ 최우선 |
| 콤부차 효능 | ✅ | ✅ | I | ★★★ 최우선 |
| 콤부차 카페인 | ✅ | ✅ | I | ★★★ 최우선 |
| 콤부차 다이어트 | ✅ | ✅ | C | ★★★ 최우선 |
| 콤부차 부작용 | ✅ | ✅ | I | ★★★ 최우선 |
| 티젠 콤부차 | ❌ | ✅ | C | ★★☆ 중요 |
| 담터 콤부차 | ❌ | ❌ | T | ★☆☆ 보통 |
| 아임얼라이브 콤부차 | ❌ | ❌ | N+T | ★☆☆ 보통 |
핵심발견 : AI Overview가 활성화된 키워드(콤부차, 콤부차 효능, 콤부차 카페인, 콤부차 다이어트, 콤부차 부작용)가 GEO의 최우선 타겟입니다. 이 5개 키워드에서 티젠이 기준점으로 등장하도록 Answer Framework와 Lexicon을 집중 설계해야 합니다.
Stage 3: CEP 확정 & 라벨링 (휴먼 판단)
- 목적: Stage 2 원시 데이터를 해석해 최종 CEP 확정, AI Inference Role 부여
- 실행 주체: 마케터 + 브랜드팀 (데이터 엔지니어 지원)
라벨링 워크시트
| 항목 | 작성 내용 | 판단 기준 |
| Community ID | LM 원본 번호 | cluster_finder 결과 |
| 포함 키워드 Top 10 | 키워드 나열 | LM 원본 |
| Situation Cue | “~할 때” 형태 문장 | 키워드 의미 해석 (휴먼 판단) |
| Persona | 대상 사용자 프로파일 | demography 데이터 + 키워드 맥락 |
| Intent Class | I / C / T / N | keyword_info intents 다수결 |
| AI Inference Role | 티젠의 역할 명사 | 브랜드 전략 기반 (휴먼 판단) |
| Answer Framework 핵심 | 답변의 핵심 메시지 | 브랜드 전략 기반 (휴먼 판단) |
라벨링 품질 체크리스트
| 체크 항목 | 판단 기준 | Pass/Fail |
| Situation Cue가 실제 검색 쿼리와 매칭되는가? | query_signal에 대응 쿼리 존재 | |
| Persona가 demography 데이터와 일치하는가? | 성별/연령 프로파일 검증 | |
| Intent Class가 keyword_info와 일치하는가? | intents 데이터 교차 검증 | |
| AI Inference Role이 다른 CEP와 중복되지 않는가? | 역할 고유성 확인 | |
| 하나의 CEP에 3개 이상의 query_signal이 있는가? | 현실성 확보 |
Stage 4: 쿼리 생성 (반자동)
- 목적: 확정된 CEP별로 AI가 실제 받을 수 있는 질문(Query)을 체계적으로 생성
- 실행 주체: 에이전시 (마케터 검수)
Step A: Anchor 추출 — CEP-02(카페인 걱정) 예시
| path_finder 경로 | 추출 Anchor | Anchor 유형 |
| 콤부차 → 콤부차 카페인 → 콤부차 카페인 함량 → 콤부차 혈당 | “콤부차 카페인” | 핵심 Anchor |
| “콤부차 카페인 함량” | 심화 Anchor | |
| “콤부차 혈당” | 파생 Anchor |
Step B: 템플릿 확장 — Anchor를 6패턴 문법에 대입
| 패턴 | Anchor 기반 생성 쿼리 | Chain Order |
| P1 | “콤부차에 카페인이 들어있어?” | 1 |
| P2 | “콤부차 카페인 함량이 커피보다 많아?” | 2 |
| P5 | “카페인에 민감한데 콤부차 마셔도 될까?” | 3 |
| P4 | “카페인 적은 콤부차 브랜드 추천해줘” | 4 |
| P6 | “티젠 콤부차 카페인 함량 얼마야?” | 5 |
Step C: 스코어링
| volume_score = anchor_keyword의 volume_avg (keyword_info 기준) |
원칙 볼륨이 높은 Anchor 기반 쿼리가 우선순위를 갖습니다. volume_score가 100 미만인 쿼리는 ‘보조 쿼리’로 분류하여 후순위로 관리합니다.
Stage 5: AI 메시지 생성 (반자동)
- 목적: 각 쿼리에 대한 AI의 이상적 답변 구조(Message Framework) 설계
- 실행 주체: 에이전시 (브랜드팀 검수)
메시지 생성 규칙
| 규칙 | 내용 | 근거 |
| 브랜드 용어 우선 | 일반 명사 대신 TiZen_Unique_Terms 사용 | Lexicon Layer F |
| RTB 필수 포함 | Reasoning to Believe (믿을 만한 근거) 1개 이상 | Proof Hook 단계 |
| Next Step 필수 | 답변 하단에 추가 질문 유도 | Zero-click 대응 |
| Safety Disclaimer | 건강 주장 시 면책 문구 | 안전성 레이어 |
| 6단계 순서 준수 | Framing → Reasoning → Option → Brand → Proof → Next | Answer Framework |
CEP-02 (카페인 걱정) 메시지 생성 예시
| [Query] “콤부차에 카페인이 들어있어?” [Answer Framework] 1. Framing: “콤부차는 녹차 또는 홍차를 베이스로 발효하기 때문에 소량의 카페인이 포함되어 있습니다.” 2. Reasoning: “일반적으로 콤부차 1잔(240ml)에 포함된 카페인은 10~25mg 수준으로, 커피(95mg)나 녹차(30~50mg)보다 낮습니다.” 3. Option Space: “스틱형 분말 제품은 원액 RTD 제품 대비 카페인 함량을 조절하기 용이한 특성이 있습니다.” 4. Brand Role: “티젠 콤부차의 경우, 성분표에 카페인 함량이 명시되어 있어 섭취 전 확인이 가능합니다.” 5. Proof Hook: “제품 성분표 기준으로 정확한 카페인 함량을 확인하는 것을 권장합니다.” 6. Next Step: “카페인 외에 콤부차의 당류 함량이 궁금하시다면…” |
주의 – 위 메시지 예시의 카페인 수치(10~25mg 등)는 일반적인 콤부차 범위를 참고한 예시용 추정값입니다. 실제 메시지 생성 시 반드시 티젠 콤부차 공식 성분표의 정확한 수치를 사용해야 합니다. Comparison_Evidence_Link에 성분표 URL을 등록하여 팩트 근거를 확보합니다.
Stage 6: GEO 테스트
- 목적: 생성된 쿼리를 실제 LLM에 투입하여 사용자 질문에 우리 브랜드가 호출되는지 등장 여부 검증
- 실행 주체: 모니터링 분석팀
테스트 대상
| LLM | 테스트 이유 | 비고 |
| Google Gemini | Google 검색 AI Overview에 직접 영향 | 최우선 |
| ChatGPT (GPT-4o+) | 가장 넓은 사용자 기반 | 필수 |
| Claude | Anthropic 생태계 커버리지 | 필수 |
| Perplexity | 검색 특화 LLM | 권장 |
테스트 판정 기준
| 판정 | 조건 | 후속 조치 |
| Pass A (기준점 등장) | 티젠이 카테고리 대표/기준으로 언급됨 | 유지. 분기 모니터링 |
| Pass B (옵션 등장) | 티젠이 추천 옵션 중 하나로 언급됨 | Lexicon/Answer Framework 강화 검토 |
| Fail C (미등장) | 티젠이 전혀 언급되지 않음 | Lexicon, Evidence Queries, 콘텐츠 보강 필요 |
| Fail D (부정적 등장) | 티젠이 부정적 맥락으로 언급됨 | Proof Terms 강화, Risk Terms 점검 필요 |
테스트 실행 프로토콜
- 1. CEP별 대표 쿼리 1~3개 선정 (volume_score 상위)
- 2. 각 LLM에 동일 쿼리 투입 (프롬프트 변형 없이 자연어 그대로)
- 3. 자사 브랜드/제품 등장 여부·위치·맥락, 경쟁사, Answer Framework 단계 기록
- 4. Pass/Fail 판정 + 피드백 액션 기록
피드백 루프 — Fail 유형별 진단
| Fail 유형 | 원인 분석 방향 | 수정 대상 |
| Fail C (미등장) | 웹 상 티젠 관련 콘텐츠 부족 | 콘텐츠 마케팅 강화, Evidence Queries 확대 |
| Fail C (미등장) | Lexicon이 AI 답변 패턴과 불일치 | Lexicon.tizen_unique 용어 재설계 |
| Fail D (부정적) | 부작용/단점 관련 콘텐츠가 우세 | Lexicon.risk_terms 대응 강화, Proof Terms 추가 |
| Pass B → Pass A 목표 | 옵션에서 기준점으로 승격 필요 | AI_Inference_Role 재정의, Answer Framework 구조 개선 |
운영주기
GEO 테스트는 월 1회 정기 실행을 권장합니다. 특히 Google의 AI Overview 알고리즘 업데이트 직후에는 긴급 테스트를 실행하여 포지션 변동을 확인합니다.
리스닝마인드 DaaS API 엔드포인트별 DB 주입 방법론 요약
| LM 엔드포인트 | 반환 데이터 | 주입 DB 레이어 | 주입 필드 |
| cluster_finder (communities) | 키워드 군집 | B Category, C CEP | market_boundaries, situation_cue, cep_id 후보 |
| cluster_finder (rels) | 키워드 관계 쌍 | D Option | direct_competitors, indirect_competitors, comparison_axes |
| path_finder | 검색 경로 배열 | E Query, G Message | query_chain_order, answer_framework 순서 |
| intent_finder | 연관 키워드 목록 | E Query | generated_query, 볼륨 기반 확장 |
| keyword_info (ads_metrics) | 볼륨/트렌드/CPC | C CEP, E Query | priority_score, volume_score |
| keyword_info (intents) | I/C/T/N | C CEP, E Query | intent_class, query_pattern |
| keyword_info (demography) | 성별/연령 | C CEP | persona 검증 |
| keyword_info (features) | SERP 스니펫 | G Message | GEO 우선순위 판단 (AI Overview 여부) |
| keyword_info (monthly_volume) | 월별 검색량 | A Meta | 업데이트 주기 판단, 계절성 분석 |
📌 이 섹션의 모든 API 호출 예시와 결과는 실제 추출 데이터 기반입니다. (2026년 2월 11일 기준)
📌 “휴먼 판단” 표기 항목은 자동화할 수 없으며, 마케터/브랜드팀의 의사결정이 필요합니다.
📌 Priority Score 산출 로직과 Journey Stage 매핑 기준은 본 가이드의 권장안이며, 시장 특성, 자사 거버넌스 환경에 따라 조정하십시오.
