9-Bucket 쿼리 프레임워크 설계 기록

WICHI의 핵심 분석 체계인 9-Bucket 쿼리 프레임워크 설계 기록. 전통적인 검색 의도(Intent)가 아닌 '브랜드 포함 여부'를 기준으로 3개 Zone(Owned, Battleground, Competitive)과 9개 Bucket을 정의하고, AI의 자발적 추천을 측정하기 위한 설계 원칙 정리.

문제 인식: 쿼리가 구분되지 않으면 점수가 의미 없다

GEO(Generative Engine Optimization) 분석의 출발점은 쿼리다. AI 검색 엔진에 어떤 질문을 던지느냐에 따라 브랜드 노출 결과가 완전히 달라진다.

WICHI 개발 초기에는 쿼리를 구분 없이 한 묶음으로 처리했다. “삼성카드 연회비”와 “연회비 저렴한 카드 추천”을 같은 기준으로 분석한 것이다. 전자는 이미 브랜드를 알고 검색하는 것이고, 후자는 브랜드를 모른 채 카테고리 수준에서 탐색하는 것이다. 두 쿼리에서 삼성카드가 언급되는 의미는 완전히 다르다.

이 구분 없이는 GEO Score가 무엇을 측정하는지 해석할 수 없었다. 점수가 높으면 좋은 건지, 브랜드 쿼리에서만 높은 건지, 아니면 실제 경쟁 쿼리에서도 잘 나오는 건지 판단이 불가능했다. 구체적으로 다음 세 가지 문제가 있었다.

첫째, 성과 왜곡 문제. 브랜드명을 포함한 쿼리(예: “삼성카드 연회비”)에서 브랜드가 언급되는 것은 당연하다. 사용자가 이미 브랜드를 지정했으니까. 이런 쿼리가 전체 점수를 끌어올리면, 실제로는 AI가 해당 브랜드를 전혀 추천하지 않는데도 GEO Score가 높게 나올 수 있다.

둘째, 액션 연결 불가. 점수가 낮을 때 무엇을 개선해야 하는지 알 수 없었다. 브랜드 인지도가 문제인지, AI가 카테고리 쿼리에서 자사를 추천하지 않는 것이 문제인지, 경쟁사 맥락에서 존재감이 없는 것이 문제인지 구분이 안 됐다.

셋째, 경쟁사 쿼리의 오분류. “현대카드 단점”이라는 쿼리에서 삼성카드가 언급되는 것과 “연회비 저렴한 카드 추천”에서 삼성카드가 언급되는 것은 성격이 다르다. 전자는 경쟁사 이탈 수요를 포착하는 것이고, 후자는 AI의 자발적 추천이다. 이 둘을 같은 버킷에 넣으면 점수 해석이 모호해진다.

쿼리 분류 없는 GEO Score는 “전교생 평균 점수”와 같다. 수학 잘하는 학생과 영어 잘하는 학생을 구분하지 않으면, 어떤 과목을 보강해야 하는지 알 수 없다.

이 문제를 해결하기 위해 쿼리를 체계적으로 분류하는 프레임워크가 필요했다.

분류 축 선택: 의도(Intent)가 아닌 브랜드 포함 여부

처음에는 SEO에서 익숙한 분류 체계를 그대로 가져오려 했다. 검색 의도(Search Intent) 기반 분류다.

의도	설명	예시
Informational	정보 탐색	”신용카드 연회비란?”
Transactional	거래/구매 의도	”삼성카드 온라인 신청”
Navigational	특정 사이트 이동	”삼성카드 홈페이지”
Commercial Investigation	구매 전 비교	”연회비 저렴한 카드 비교”

이 분류는 전통 SEO에서는 잘 작동한다. 하지만 AI 검색에서는 한계가 분명했다.

AI 검색의 핵심은 “사용자가 브랜드를 지정하지 않았을 때 AI가 어떤 브랜드를 추천하느냐”다. 의도 기반 분류로는 이 핵심을 포착할 수 없다. Informational 의도든 Transactional 의도든, 쿼리에 브랜드명이 들어 있느냐 아니냐가 훨씬 근본적인 구분 축이다.

예를 들어 아래 두 쿼리는 둘 다 Commercial Investigation으로 분류된다.

“삼성카드 연회비 얼마야?”
“연회비 저렴한 카드 뭐가 있어?”

하지만 GEO 관점에서 이 두 쿼리의 성격은 완전히 다르다. 전자에서 AI가 삼성카드를 언급하는 것은 당연하다. 후자에서 삼성카드를 언급하면, 그것이 진짜 GEO 성과다.

graph LR
    A[쿼리 분류 축 선택] --> B{SEO 의도 기반?}
    B -->|Informational| C[브랜드 포함 여부<br/>구분 불가]
    B -->|Transactional| C
    B -->|Navigational| C
    A --> D{브랜드 포함 여부?}
    D -->|브랜드 포함| E[Owned Zone<br/>기준선 측정]
    D -->|브랜드 미포함| F[Battleground Zone<br/>핵심 KPI]
    D -->|경쟁사 포함| G[Competitive Zone<br/>경쟁 위치]
    style D fill:#2563eb,color:#fff
    style B fill:#6b7280,color:#fff

결론적으로, GEO 분석의 1차 분류 축은 브랜드 포함 여부다. 의도 분류는 2차 메타데이터로 남겨두고, 1차 구조는 브랜드 관계를 기준으로 설계하기로 했다.

3-Zone 구조: Owned, Battleground, Competitive

브랜드 포함 여부를 기준으로 쿼리를 세 개의 Zone으로 나눴다.

Zone	정의	측정 대상	쿼리 예시 (신용카드)
Owned	쿼리에 분석 대상 브랜드명이 포함	브랜드 인지도 기반 노출, AI의 브랜드 정보 정확도	”삼성카드 연회비”, “삼성카드 해외결제”
Battleground	브랜드명 없이 카테고리/니즈 수준 검색	AI의 자발적 추천 여부 (핵심 KPI)	“연회비 저렴한 카드 추천”, “사회초년생 첫 카드”
Competitive	경쟁사 브랜드가 직접 언급됨	경쟁사 맥락에서의 존재감, 이탈 수요 포착	”현대카드 단점”, “신한카드 vs 삼성카드”

이 3-Zone 구분이 프레임워크의 뼈대다. 각 Zone은 측정하는 대상이 다르고, 점수의 의미가 다르다.

각 Zone의 점수가 의미하는 것

Owned Zone 점수가 높다면: AI가 브랜드에 대한 기본 정보를 정확하게 알고 있다는 의미다. 필요 조건이지 충분 조건이 아니다. 이 점수만으로는 GEO 성과를 판단할 수 없다.

Battleground Zone 점수가 높다면: 사용자가 브랜드를 지정하지 않았는데도 AI가 자발적으로 해당 브랜드를 추천한다는 의미다. 이것이 GEO의 본질이고, 실질적인 비즈니스 가치가 있는 영역이다.

Competitive Zone 점수가 높다면: 경쟁사가 언급되는 맥락에서도 자사 브랜드가 대안으로 등장한다는 의미다. 특히 경쟁사 불만 쿼리에서의 노출은 직접적인 고객 전환 기회를 나타낸다.

Owned Zone은 “기준선(baseline)“이다. 자기 이름을 불렀을 때 대답하는 것은 기본이다. Battleground Zone에서의 점수가 높아야 AI 검색 시대에 의미 있는 가시성을 확보한 것이다.

왜 처음부터 3-Zone이 아니었나

초기에는 Owned와 Battleground 두 Zone만 사용했다. 경쟁사 쿼리를 Battleground에 넣었더니 점수 해석이 모호해졌다.

“현대카드 단점”이라는 쿼리에서 삼성카드가 언급되는 것은 Battleground의 자발적 추천과는 성격이 다르다. 이것은 경쟁사 이탈 수요를 포착하는 것이지, 카테고리 수준에서 AI가 자발적으로 추천한 것이 아니다. 이 두 가지를 구분하지 않으면 Battleground 점수의 의미가 희석된다.

또한 “삼성카드 vs 현대카드” 같은 직접 비교 쿼리는 Owned에 넣기도, Battleground에 넣기도 어려웠다. 브랜드명이 포함되어 있으니 Battleground는 아니고, 경쟁사가 함께 있으니 순수한 Owned도 아니다. 별도 Zone이 필요했다.

graph TD
    A[쿼리 입력] --> B{분석 대상<br/>브랜드명 포함?}
    B -->|Yes| C{경쟁사 브랜드도<br/>포함?}
    B -->|No| D{경쟁사 브랜드<br/>포함?}
    C -->|Yes| E[Competitive Zone<br/>Head-to-Head]
    C -->|No| F[Owned Zone]
    D -->|Yes| G[Competitive Zone<br/>Competitor Pain]
    D -->|No| H[Battleground Zone]
    style H fill:#2563eb,color:#fff
    style F fill:#059669,color:#fff
    style E fill:#dc2626,color:#fff
    style G fill:#dc2626,color:#fff

9개 Bucket 상세 설계

3개 Zone을 다시 세분화해서 총 9개 Bucket으로 나눴다. 각 Bucket은 고유한 측정 목적과 설계 근거를 갖고 있다.

3x3 Matrix 구조

graph TB
    subgraph Owned ["Owned Zone (브랜드 포함)"]
        A["A: Branded Direct<br/>기능/조건 직접 질문"]
        B_bucket["B: Branded Contextual<br/>상황 맥락 질문"]
    end
    subgraph Battleground ["Battleground Zone (브랜드 미포함)"]
        C["C: Category Generic<br/>카테고리 탐색"]
        D["D: Persona Entry<br/>페르소나 진입"]
        E["E: Persona Premium<br/>고가치 페르소나"]
        H["H: Adjacent Topic<br/>인접 주제"]
        I["I: Trend / Ranking<br/>트렌드/순위"]
    end
    subgraph Competitive ["Competitive Zone (경쟁사 포함)"]
        F["F: Head-to-Head<br/>직접 비교"]
        G["G: Competitor Pain<br/>경쟁사 불만"]
    end
    style Battleground fill:#1e3a5f,color:#fff
    style Owned fill:#1a4731,color:#fff
    style Competitive fill:#5c1a1a,color:#fff

Owned Zone: 기준선 측정

Owned Zone은 브랜드명이 쿼리에 포함된 상태에서 AI가 해당 브랜드를 어떻게 설명하는지 측정한다. 이 Zone의 점수가 낮다면 AI가 브랜드에 대한 기본 정보 자체를 잘못 알고 있다는 뜻이므로, 다른 Zone을 보기 전에 먼저 해결해야 할 문제다.

Bucket	이름	측정 목적	쿼리 패턴	가상 예시 (SaaS)
A	Branded Direct	브랜드+제품의 기능/조건에 대한 AI의 정보 정확도	브랜드명 + 구체적 기능 질문	”Notion AI 가격 플랜 어떻게 돼?”
B	Branded Contextual	특정 상황에서 브랜드에 대한 AI의 맥락 이해	브랜드명 + 사용 시나리오	”우리 팀이 10명인데 Notion으로 프로젝트 관리하면 어때?”

Branded Direct vs Branded Contextual의 차이: Direct는 사실 확인(fact-checking) 성격이다. “가격이 얼마야?”, “이 기능 있어?” 같은 질문이다. Contextual은 맥락 판단(contextual reasoning) 성격이다. “내 상황에서 이 제품이 맞아?” 같은 질문이다. AI가 사실은 잘 알지만 맥락 판단은 못하는 경우가 있고, 그 반대도 있다. 이 둘을 구분해야 개선 방향이 명확해진다.

Battleground Zone: 핵심 KPI

Battleground Zone은 프레임워크의 핵심이다. 사용자가 브랜드를 지정하지 않은 상태에서 AI가 자발적으로 해당 브랜드를 추천하는지 측정한다. 5개 Bucket으로 세분화한 이유는, 같은 Battleground 내에서도 쿼리의 성격과 전환 가능성이 크게 다르기 때문이다.

Bucket	이름	측정 목적	쿼리 패턴	가상 예시 (SaaS)
C	Category Generic	카테고리 수준의 일반 탐색에서 AI의 추천 여부	카테고리 키워드 + 복합 조건	”프로젝트 관리 툴 중에 무료이면서 칸반보드 되는 거 추천해줘”
D	Persona Entry	특정 페르소나의 진입 쿼리에서 추천 여부	페르소나 + 카테고리 질문	”스타트업 5인 팀인데 처음 도입할 협업 툴 뭐가 좋아?”
E	Persona Premium	고관여/고가치 페르소나에서의 추천 여부	전문가/고가치 사용자 + 전문적 니즈	”엔터프라이즈급 보안이 필요한데 SOC2 인증된 프로젝트 관리 툴 있어?”
H	Adjacent Topic	직접 카테고리는 아니지만 관련된 주변 주제에서의 노출	인접 주제 + 간접 연결	”리모트 팀 운영 시 비동기 커뮤니케이션 어떻게 하면 좋아?”
I	Trend / Ranking	순위/비교 쿼리에서의 포지셔닝	시점 + 순위/트렌드	”2026년 프로젝트 관리 툴 순위 어떻게 돼?”

각 Bucket을 분리한 설계 근거:

구분	왜 별도 Bucket인가
C vs D	Category Generic은 “무엇이 있나” 수준의 탐색이고, Persona Entry는 “내 상황에서 뭐가 맞나”라는 맥락 질문이다. AI의 추천 로직이 다르게 작동한다.
D vs E	Entry 페르소나는 초기 탐색 단계이고, Premium 페르소나는 이미 요구사항이 구체적인 고관여 사용자다. 비즈니스 가치(LTV)가 다르므로 별도 측정이 필요하다.
H의 존재 이유	인접 주제에서 브랜드가 언급되면 새로운 유입 경로를 발견한 것이다. “리모트 워크 팁”에서 Notion이 언급되는 것은 직접 카테고리 쿼리와 다른 기회다.
I의 존재 이유	”2026년 최고의 X” 류 쿼리는 AI가 리스트를 생성하는 구조다. 리스트의 몇 번째에 나오느냐가 중요하며, 다른 Bucket과 측정 방식이 다르다.

Competitive Zone: 경쟁 포지셔닝

Competitive Zone은 경쟁사가 직접 언급되는 맥락에서 자사 브랜드의 존재감을 측정한다.

Bucket	이름	측정 목적	쿼리 패턴	가상 예시 (SaaS)
F	Head-to-Head	직접 비교에서 AI가 어느 쪽을 더 추천하는지	브랜드 vs 경쟁사	”Notion이랑 Monday.com 중에 스타트업에 뭐가 더 나아?”
G	Competitor Pain	경쟁사 불만 시 대안으로 자사가 언급되는지	경쟁사 + 불만/이탈 시나리오	”Monday.com 너무 비싸서 다른 데로 바꾸려는데 비슷한 기능에 저렴한 거 있어?”

Head-to-Head vs Competitor Pain의 차이: Head-to-Head는 중립적 비교다. 사용자가 두 브랜드를 알고 있고, 객관적 비교를 원한다. Competitor Pain은 방향성이 있다. 사용자가 경쟁사에 불만이 있고, 대안을 찾고 있다. 후자에서 자사가 언급되면 직접적인 전환 기회(switching opportunity)를 의미한다.

핵심 설계 원칙

원칙 1: 브랜드명 배제 (Brand Name Exclusion)

이 프레임워크에서 가장 중요한 설계 원칙이다.

Battleground Zone 쿼리에는 분석 대상 브랜드명을 절대 포함하지 않는다.

이 원칙의 근거는 단순하다. GEO의 본질은 “사용자가 브랜드를 지정하지 않았을 때 AI가 자발적으로 해당 브랜드를 추천하는지”를 측정하는 것이다.

“연회비 저렴한 카드 추천해줘”라는 질문에 AI가 삼성카드를 언급하면, 그것이 진짜 GEO 성과다. 쿼리에 “삼성카드”를 넣어놓고 AI가 삼성카드를 언급하는지 보는 것은 측정이 아니라 자기 확인(self-confirmation)이다.

이 원칙은 Competitive Zone에도 변형 적용된다.

Zone	브랜드명 규칙
Owned (A, B)	분석 대상 브랜드명 반드시 포함. 경쟁사명 포함 불가.
Battleground (C, D, E, H, I)	분석 대상 브랜드명 절대 불포함. 경쟁사명도 불포함.
Competitive F (Head-to-Head)	분석 대상 브랜드명 + 경쟁사명 둘 다 포함.
Competitive G (Competitor Pain)	경쟁사명만 포함. 분석 대상 브랜드명 절대 불포함.

Competitor Pain(G)에서 자사 브랜드명을 빼는 이유는 Battleground와 동일하다. “Monday.com 비싸서 다른 거 찾는데 Notion은 어때?”라고 물으면, AI는 Notion을 언급할 수밖에 없다. “Monday.com 비싸서 다른 거 찾는데 비슷한 기능에 저렴한 거 있어?”라고 물었을 때 AI가 Notion을 자발적으로 추천해야 의미 있는 측정이다.

원칙 2: 쿼리는 키워드가 아닌 대화문

AI 검색 쿼리와 전통 검색엔진 쿼리는 근본적으로 다르다.

구분	전통 검색엔진	AI 검색
형태	키워드 나열	자연어 대화문
예시	”신용카드 연회비 비교"	"나 사회초년생인데 연회비 부담 없으면서 해외 결제 수수료 낮은 카드 추천해줘”
조건 수	보통 1–2개	2–3개 이상 복합 조건
톤	없음	반말/존댓말 등 다양

쿼리를 생성할 때 “신용카드 추천” 같은 키워드형 쿼리를 넣으면, 실제 AI 검색 사용자의 행동을 대표하지 못한다. 실제 사용자는 자신의 상황을 설명하고, 복수의 조건을 동시에 제시하며, 대화체로 질문한다. 프레임워크의 쿼리 생성 단계에서 이 차이를 반드시 반영해야 한다.

원칙 3: 복잡도 분포 제어

쿼리의 복잡도(조건 수)는 의도적으로 분포를 관리한다.

복잡도	설명	목표 비중	허용 Bucket
Simple (조건 1개)	단일 조건 질문	소수	주로 Trend/Ranking(I)
Medium (조건 2개)	이중 조건 질문	중간	전체
Complex (조건 3개+)	복합 조건 질문	가장 큰 비중	전체

단순 쿼리만으로 테스트하면 AI의 기본 추천 목록만 측정하게 된다. 복합 조건 쿼리에서 AI가 해당 브랜드를 추천하는지가 더 까다로운 테스트이며, 실제 사용자 행동에도 더 가깝다.

쿼리 확장(Query Expansion) 파이프라인

9-Bucket 프레임워크는 분류 체계일 뿐이다. 실제 분석에 사용할 쿼리는 별도의 확장(expansion) 파이프라인을 통해 생성된다.

파이프라인 구조

graph TD
    A[사용자 입력<br/>브랜드명 + 제품명] --> B[Step 0: 브랜드 정보 자동 생성<br/>카테고리, 경쟁사, USP 등]
    B --> C[Step 2: 시그널 추출<br/>자동완성 + 토픽 + 페르소나]
    C --> D[Step 3: 쿼리 확장<br/>9-Bucket 분배 생성]
    D --> E[Step 3b: 메타데이터 분류<br/>intent, funnel, persona 등]
    E --> F[최종 쿼리 세트<br/>~40개 쿼리 + 메타데이터]
    style D fill:#2563eb,color:#fff

이 파이프라인에서 핵심은 실제 사용자 시그널을 기반으로 쿼리를 생성한다는 점이다. 임의로 쿼리를 만드는 것이 아니라, 실제 검색 자동완성 데이터에서 사용자 관심 토픽을 추출하고, 이를 기반으로 페르소나를 도출한 뒤, 각 Bucket의 규칙에 맞게 쿼리를 생성한다.

시그널 추출의 역할

쿼리 생성 전에 실제 사용자 시그널을 수집하는 이유는, 프레임워크의 쿼리가 “분석가가 상상한 질문”이 아니라 “실제 사용자가 할 법한 질문”이 되어야 하기 때문이다.

수집하는 시그널:

시그널 유형	소스	용도
자동완성 쿼리	Google, Naver 자동완성 API	실제 사용자가 검색하는 키워드/토픽 파악
관심 토픽	자동완성에서 LLM으로 추출	Bucket별 쿼리의 주제 방향 결정
타겟 페르소나	토픽 기반 LLM 도출	Persona Entry(D), Persona Premium(E) 쿼리의 구체화

이 시그널이 없으면 “연회비 저렴한 카드”처럼 일반적인 쿼리만 생성되고, “결혼 준비하면서 웨딩홀 결제 혜택 좋은 카드” 같은 실제 사용자의 구체적 니즈를 놓치게 된다.

쿼리 생성에서 메타데이터 분류까지

쿼리 생성(Step 3)에서는 각 쿼리의 텍스트와 소속 Bucket만 결정한다. 이후 별도의 메타데이터 분류(Step 3b)에서 intent, funnel, persona_hint 등 부가 정보를 태깅한다.

이렇게 2단계로 분리한 이유가 있다. 쿼리 생성과 분류를 한 번에 하면 LLM이 “이 쿼리는 recommendation intent니까 추천형으로 만들어야지” 식으로 생성 자체가 분류에 의해 왜곡될 수 있다. 생성은 자유롭게, 분류는 사후에 하는 것이 쿼리 다양성을 보장한다.

분류되는 메타데이터:

필드	값 범위	설명
intent	definition, comparison, recommendation, condition, switching, situation, problem_solving, evaluation	사용자의 근본 목적
funnel	awareness, consideration, decision, post_purchase	구매 여정 단계
persona_hint	자유 텍스트 (한국어)	추정 사용자 세그먼트
brand_relevance	direct, contextual, category, competitive, adjacent	브랜드와의 관계
priority	high, medium, low	GEO 측정 중요도

실전 예시: 가상의 SaaS 프로덕트 매핑

이론적 설명만으로는 감이 오지 않을 수 있으니, 가상의 프로젝트 관리 SaaS “TaskFlow”를 예로 들어 9개 Bucket에 쿼리를 매핑해 보겠다.

기본 정보:

브랜드: TaskFlow
카테고리: 프로젝트 관리 툴
주요 경쟁사: Monday.com, Asana, ClickUp
USP: AI 기반 자동 태스크 분배, 무제한 무료 플랜

Bucket별 쿼리 예시

Bucket	Zone	쿼리 예시
A Branded Direct	Owned	”TaskFlow 무료 플랜에서 몇 명까지 쓸 수 있어? 유료랑 기능 차이 뭐야?”
B Branded Contextual	Owned	”우리 팀이 디자이너 3명 개발자 5명인데 TaskFlow로 스프린트 관리하면 어떨까?”
C Category Generic	Battleground	”프로젝트 관리 툴 처음 도입하려는데 무료면서 칸반이랑 간트차트 둘 다 되는 거 있어?”
D Persona Entry	Battleground	”프리랜서 디자이너인데 클라이언트별로 프로젝트 나눠서 관리할 수 있는 툴 뭐가 좋아?”
E Persona Premium	Battleground	”50인 규모 스타트업 CTO인데 JIRA에서 이관할 건데 API 연동이랑 SSO 되는 PM 툴 추천해줘”
H Adjacent Topic	Battleground	”리모트 팀 운영하면서 비동기 커뮤니케이션 잘하는 방법 있어? 태스크 추적이 잘 안 돼서”
I Trend / Ranking	Battleground	”2026년 스타트업들이 많이 쓰는 프로젝트 관리 툴 순위 어떻게 돼?”
F Head-to-Head	Competitive	”TaskFlow랑 Monday.com 중에 소규모 팀한테 어디가 더 나아? 가격이랑 기능 둘 다 비교해줘”
G Competitor Pain	Competitive	”Monday.com 쓰고 있는데 시트당 과금이 너무 비싸서 바꾸려고. 비슷한 기능인데 가격 합리적인 거 있어?”

이 매핑에서 확인할 수 있는 것

위 예시에서 몇 가지 설계 원칙이 잘 드러난다.

C, D, E, H, I에는 “TaskFlow”가 없다. AI가 TaskFlow를 자발적으로 추천하는지 보기 위해서다.
G에도 “TaskFlow”가 없다. Monday.com에 불만인 사용자가 대안을 찾을 때 AI가 TaskFlow를 언급하는지가 핵심이다.
D와 E의 차이가 명확하다. D는 “프리랜서 디자이너”로 진입 수준이고, E는 “50인 CTO”로 고가치 사용자다.
H는 직접 카테고리가 아니다. “리모트 팀 비동기 커뮤니케이션”은 프로젝트 관리 툴을 직접 묻는 게 아니지만, 프로젝트 관리 툴이 해답이 될 수 있는 인접 주제다.

쿼리 커버리지(Coverage) 검증

쿼리 세트가 생성된 후, 이 쿼리들이 실제 사용자의 검색 행동을 충분히 대표하는지 검증해야 한다. 아무리 프레임워크가 잘 설계되어도, 쿼리 자체의 품질이 낮으면 분석 결과를 신뢰할 수 없다.

커버리지 검증 차원

graph LR
    subgraph Coverage ["쿼리 커버리지 검증 4가지 차원"]
        A[토픽 커버리지<br/>실제 사용자 관심사 반영]
        B[페르소나 커버리지<br/>다양한 사용자 유형 포함]
        C[복잡도 분포<br/>단순~복합 쿼리 균형]
        D[표현 다양성<br/>톤, 길이, 패턴]
    end
    style Coverage fill:#1e293b,color:#fff

차원	검증 질문	실패 신호
토픽 커버리지	자동완성에서 추출한 주요 토픽이 쿼리에 반영되었는가?	인기 토픽이 쿼리에 전혀 등장하지 않음
페르소나 커버리지	도출된 페르소나가 D, E Bucket에 반영되었는가?	모든 쿼리가 동일한 사용자 유형을 가정
복잡도 분포	단순(1조건)/중간(2조건)/복합(3조건+) 비율이 적정한가?	단순 쿼리가 과반 이상
표현 다양성	문장 패턴, 톤, 길이가 다양한가?	모든 쿼리가 “~추천해줘”로 끝남

쿼리 품질의 안티패턴(Anti-Pattern)

실제 운영하면서 발견한 쿼리 품질 문제들이 있다.

안티패턴	예시	왜 문제인가
키워드형 쿼리	”프로젝트 관리 툴 추천”	실제 AI 검색 사용자는 이렇게 짧게 묻지 않음. 검색엔진 습관의 잔재.
로봇 톤	”서비스 불만족에 대한 대안을 추천해 주십시오”	실제 사람의 말투가 아님. AI 챗봇에 이렇게 안 물어봄.
단일 조건	”연회비 싼 카드”	실제 사용자는 연회비 + 해외결제 수수료 + 적립률 등 복수 조건을 동시에 제시함.
분석 용어 혼입	”GEO 최적화된 카드 추천”	이건 분석가의 쿼리지 사용자의 쿼리가 아님.
Bucket 규칙 위반	Battleground 쿼리에 브랜드명 포함	프레임워크의 핵심 원칙 위반. 측정이 무의미해짐.

쿼리 품질 검증에서 가장 자주 발견되는 문제는 “키워드형 쿼리”다. SEO에 익숙한 사람일수록 이 패턴에 빠지기 쉽다. AI 검색 쿼리는 대화문이라는 점을 계속 강조해야 한다.

Bucket 개수의 수렴 과정

최종적으로 9개 Bucket에 도달하기까지 여러 번의 시행착오가 있었다. 기록으로 남겨둔다.

버전	Bucket 수	문제
v1	5개	Battleground가 하나의 Bucket. 페르소나 쿼리와 트렌드 쿼리의 성격 차이를 구분 못함
v2	7개	Competitive Zone 없음. 경쟁사 쿼리가 Battleground에 섞여 점수 해석 모호
v3	12개	Bucket이 너무 세분화됨. 각 Bucket당 쿼리 수가 2–3개로 줄어 통계적 신뢰도 하락. 분석 결과 해석도 복잡해짐
v4 (현재)	9개	해석 가능성과 쿼리 설계 비용 사이의 균형점. Bucket당 최소 4개 쿼리 확보

9개로 수렴한 핵심 기준은 두 가지였다.

첫째, 해석 가능성. Bucket 수가 늘어날수록 리포트가 복잡해지고, 고객이 “그래서 뭘 해야 하는데?”라는 질문에 답하기 어려워진다. 9개는 3x3 매트릭스로 시각화할 수 있는 수준이다.

둘째, 통계적 최소 쿼리 수. 총 40개 쿼리를 9개 Bucket에 배분하면 Bucket당 최소 4개, 최대 6개다. 각 쿼리가 3회 반복 실행되므로 Bucket당 최소 12개 응답이 확보된다. 이 정도면 Bucket 수준의 패턴 파악이 가능하다. Bucket이 12개가 되면 일부 Bucket의 쿼리가 2–3개로 줄어 노이즈에 취약해진다.

메트릭 시스템과의 연결

9-Bucket 프레임워크는 단독으로 존재하지 않는다. WICHI의 메트릭 시스템과 결합하여 Bucket별 GEO Score를 산출한다.

graph TD
    A[쿼리 40개<br/>9-Bucket 분류] --> B[AI 엔진 응답 수집<br/>쿼리당 3회 × 3엔진]
    B --> C[LLM Judge 평가<br/>6차원 1-5점]
    C --> D[메트릭 계산<br/>Inclusion + Prominence + Quality]
    D --> E[Bucket별 GEO Score<br/>어디가 강하고 어디가 약한지]
    D --> F[Zone별 GEO Score<br/>Owned vs Battleground vs Competitive]
    D --> G[전체 GEO Score<br/>종합 점수]
    style E fill:#2563eb,color:#fff

각 Bucket별로 GEO Score가 나오기 때문에 다음과 같은 해석이 가능해진다.

패턴	해석	액션
Owned 높음 + Battleground 낮음	AI가 브랜드를 알고는 있지만 자발적으로 추천하지 않음	콘텐츠 최적화, 외부 인용 확대 필요
Owned 낮음	AI가 브랜드 기본 정보 자체를 잘못 알고 있음	브랜드 정보 소스 정리가 우선
Battleground C 높음 + D 낮음	일반 탐색에서는 노출되지만 특정 페르소나에서 약함	해당 페르소나 타겟 콘텐츠 보강
Competitive G 높음	경쟁사 이탈 시 대안으로 잘 노출됨	전환 유도 콘텐츠 강화
I 높음 + C 낮음	트렌드/순위 리스트에는 올라가지만 구체적 추천에서 빠짐	제품 특장점 기반 콘텐츠 확대

이 Bucket별 진단이 9-Bucket 프레임워크의 실질적 가치다. 전체 GEO Score만으로는 “점수가 60이다” 이상의 인사이트를 줄 수 없다. Bucket별 점수가 있어야 “Battleground C에서 점수가 낮으니 카테고리 수준에서 AI가 자사를 추천하도록 콘텐츠를 개선해야 한다”는 구체적 액션으로 연결된다.

설계 과정 요약

단계	결정	근거
분류 축 선택	의도(Intent) → 브랜드 포함 여부	AI 검색에서는 브랜드 존재 유무가 더 근본적 구분
Zone 수	2개 → 3개	경쟁사 쿼리의 별도 분리 필요
Bucket 수	5 → 7 → 12 → 9	해석 가능성 + 통계 신뢰도 균형
핵심 원칙	브랜드명 배제	GEO의 본질 = AI의 자발적 추천
쿼리 형태	키워드 → 대화문	실제 AI 검색 사용자 행동 반영
쿼리 생성	임의 생성 → 시그널 기반	실제 사용자 관심사 반영
메타데이터	생성과 동시 → 사후 분류	분류가 생성을 왜곡하지 않도록 분리