Share of Voice를 신뢰구간과 함께 측정하는 법

Share of Voice(SOV)는 단일 측정값 하나가 아니라 '구간'으로 보고해야 한다. AI 검색에서 'SOV 32%'라고 딱 떨어지게 말하는 리포트를 받았다면, 그건 정확한 게 아니라 불확실성을 숨긴 것이다. 같은 질문을 같은 엔진에 다시 던지면 다른 답이 나오기 때문이다. 정직한 보고는 '32%'가 아니라 'SOV 32%, 95% 신뢰구간 24~41%'처럼 생겼다. 이 글은 왜 단일 측정이 노이즈인지, 그 노이즈가 어디서 오는지 RAG 메커니즘으로 풀고, 다중 실행과 부트스트랩으로 신뢰구간을 붙여 SOV를 측정하는 실무 절차를 그로스·퍼포먼스 리드 관점에서 정리한다.

SOV가 뭐고, 왜 매력적이면서 위험한가

Share of Voice(SOV)는 한 카테고리의 AI 답변들 안에서 우리 브랜드가 언급·인용되는 비율이다. 예를 들어 '강남 임플란트 추천' 같은 질문 100개를 ChatGPT·Perplexity·Gemini·Claude에 던졌을 때, 그중 32개의 답변에 우리 치과가 등장했다면 SOV는 32%다. 검색 시대의 '점유율'을 생성형 검색 시대로 옮겨온 지표다.

매력적인 이유는 분명하다. 경영진에게 '우리가 AI 답변에서 차지하는 몫'을 한 숫자로 보여줄 수 있으니까. 위험한 이유도 똑같다. 한 숫자로 보이기 때문에, 그 숫자가 흔들린다는 사실이 가려진다.

비유하자면 SOV는 여론조사 지지율과 같다. 어떤 언론도 '지지율 32%'라고만 쓰지 않는다. '지지율 32%, 오차범위 ±3.1%p, 표본 1,000명'이라고 쓴다. 표본이 작거나 측정이 흔들리면 32%와 35%의 차이는 의미가 없다. AI SOV도 정확히 같은 통계 문제를 안고 있는데, 시장에는 오차범위 없이 '32%'만 파는 도구가 너무 많다.

왜 같은 질문에 다른 답이 나오는가 — RAG와 비결정성

SOV가 흔들리는 근본 원인을 이해하려면, AI 검색이 답을 만드는 과정(RAG)을 봐야 한다. RAG는 retrieval(검색) → reranking(재정렬) → generation(생성)의 3단계다. 2020년 Lewis 등이 제안한 구조로(arXiv:2005.11401), 모델의 내부 지식(파라메트릭 메모리)에 외부 문서(비파라메트릭 메모리)를 결합해 답을 만든다.

1단계 retrieval — 도서관의 검색대

질문이 들어오면 엔진은 먼저 후보 문서를 끌어온다. 키워드 색인(BM25)과 의미 임베딩(dense retrieval)을 함께 쓴다. Karpukhin 등의 Dense Passage Retrieval 연구(arXiv:2004.04906)는 의미 기반 검색이 단순 키워드(BM25)를 능가함을 보였고, 실무에선 둘을 합친 하이브리드가 표준이 됐다.

비유하면 도서관의 키워드 색인(BM25)과 주제를 아는 사서(임베딩)를 동시에 쓰는 것이다. 공개 벤치마크를 종합하면 recall@10이 의미 단독 약 78%, BM25 단독 약 65%인데, 둘을 RRF로 합치면 약 91%까지 올라간다. Anthropic의 Contextual Retrieval 분석에서도 청크에 맥락을 붙이면 검색 실패율이 5.7%→3.7%(35% 감소), BM25를 더하면 49% 감소, reranking까지 더하면 67% 감소했다.

2단계 reranking — 사서가 다시 골라낸다

1차로 끌어온 후보를 cross-encoder가 질문과 함께 다시 읽어 순위를 매긴다. NDCG가 보통 5~15포인트, 어려운 질의에선 약 20포인트까지 오른다. 후보를 '질문과 한 쌍으로' 정독해 재정렬하는 단계라, 같은 후보군이라도 미세한 점수 차로 순서가 바뀐다.

3단계 generation — 그리고 여기서 흔들린다

재정렬된 문서를 바탕으로 LLM이 최종 답을 쓴다. 핵심은 이 생성 단계가 온도(temperature)를 0으로 맞춰도 완전히 결정적이지 않다는 점이다. GPU 부동소수점 연산 순서, 배치 구성 같은 하드웨어·인프라 요인 때문에 같은 입력에도 출력이 미세하게 달라진다. 한 분석에서는 2,350억 파라미터급 모델에 같은 프롬프트를 1,000번 넣었더니 80가지나 되는 서로 다른 출력이 나왔다(6개 모델 480회 실험, arXiv:2602.14349).

게다가 'Lost in the Middle'(Liu 등, arXiv:2307.03172) 현상도 겹친다. 긴 맥락에서 중간에 놓인 정보는 손실되기 쉽고, 앞과 끝에 있는 정보가 더 잘 반영된다(U자형). retrieval 단계에서 우리 문서가 5번째로 끌려오느냐 1번째로 끌려오느냐에 따라, 그게 최종 답에 인용될지가 갈린다. 이 모든 단계가 확률적이라, '우리 브랜드가 답변에 등장하느냐'는 매번 동전 던지기에 가깝다.

그래서 인용은 멱법칙(power law)처럼 출렁인다. AI 가시성의 불확실성을 정량화한 연구(arXiv:2603.08924)는 인용 빈도가 멱법칙으로 요동치므로, 다중 실행과 부트스트랩 신뢰구간을 권장한다. 한마디로 단일 측정 = 노이즈다.

단일 숫자가 만드는 거짓말 — 약한 예 / 강한 예

측정을 어떻게 보고하느냐가 의사결정의 질을 결정한다. 실제 문장으로 대조해보자.

약한 보고의 공통 문제는 측정의 떨림을 신호로 착각한다는 것이다. 28%와 32%는 노이즈 범위 안에서 같은 값일 수 있다. 신뢰구간이 없으면 그걸 알 방법이 없다.

신뢰구간을 붙이는 5단계 절차

그로스 관점에서 가장 중요한 원칙은 하나다. SOV는 '측정'이 아니라 '추정'이다. 추정에는 항상 불확실성이 따라붙고, 그 불확실성을 정량화하는 게 신뢰구간이다. 절차는 이렇다.

1. 질문 세트를 먼저 고정한다

SOV는 '어떤 질문을 던지느냐'가 결과를 좌우한다. 질문 세트가 결과를 만든다고 해도 과언이 아니다. 그래서 측정 전에 카테고리를 대표하는 질문 집합을 명시적으로 정의하고 버전을 박아둔다. 질문이 바뀌면 SOV도 바뀌므로, 추세를 보려면 질문 세트가 고정돼 있어야 한다.

• 구매 의도형("강남 임플란트 가격 비교"), 정보형("임플란트 종류 차이"), 비교형("A치과 vs B치과") 등 의도를 골고루.
• 실제 프롬프트 볼륨은 실측이 거의 불가능하다. 패널 기반 추정치는 시장의 1% 미만을 모델링한 것에 불과하다. Conductor는 "신뢰할 수 없는 검색량 데이터는 없는 것보다 나쁘다"고 못박는다. 그러니 가짜 정밀도(예: '월 12,400회 검색')에 기대지 말고, 질문 세트의 대표성에 집중하라.

2. 같은 질문을 여러 번 실행한다 (다중 실행)

비결정성 때문에 1회 측정은 동전을 한 번 던지고 '앞면이 100%'라 말하는 것과 같다. 각 질문을 최소 5~10회 반복 실행한다. 질문 50개를 5회씩 돌리면 표본 250개가 된다. 이게 신뢰구간의 원재료다.

# 측정 설계 (의사코드)
질문세트 Q = [q1, q2, ..., q50]      # 버전 고정
실행횟수 R = 5                        # 질문당 반복
for q in Q:
  for r in range(R):
    답변 = 엔진.ask(q)               # 같은 질문도 매번 다를 수 있음
    등장여부[q][r] = 우리브랜드 in 답변
# 표본 n = 50 * 5 = 250개의 0/1 관측치

3. 부트스트랩으로 신뢰구간을 만든다

부트스트랩은 어려운 수식 없이 신뢰구간을 얻는 방법이다. 비유하면 같은 표본을 주머니에 넣고 복원추출로 수천 번 다시 뽑아보는 것이다. 매번 SOV를 다시 계산하면 SOV 값들의 분포가 생기고, 그 분포의 2.5%~97.5% 지점이 95% 신뢰구간이 된다.

# 부트스트랩 (의사코드)
관측치 = [0,1,1,0,1, ...]   # n=250개의 등장여부
sov_분포 = []
for i in range(2000):                 # 2000번 재추출
  표본 = 복원추출(관측치, size=250)
  sov_분포.append(mean(표본))
ci_low  = percentile(sov_분포, 2.5)
ci_high = percentile(sov_분포, 97.5)
# 보고: SOV=mean(관측치), 95% CI=[ci_low, ci_high]

이렇게 하면 'SOV 32%'가 아니라 'SOV 32% (24~41%)'를 얻는다. 표본이 작거나(질문이 적음) 결과가 들쭉날쭉하면 구간이 넓어지고, 그게 곧 '아직 단정하지 마라'는 신호다.

4. 엔진별로 따로 본다 (합산 금지)

엔진을 합산해 하나의 SOV로 뭉개면 메커니즘이 가려진다. 엔진마다 인용 성향이 완전히 다르기 때문이다.

대규모 인용 분석에 따르면 ChatGPT와 Perplexity의 인용 도메인 중복은 약 11%에 불과하고, 인용의 약 90%가 엔진마다 다르다. 즉 한 엔진에서 SOV가 높아도 다른 엔진에선 0일 수 있다. 합산 평균은 이 진실을 지운다. 엔진별로 따로 측정하고, 따로 신뢰구간을 붙여라.

5. 추세는 한 점이 아니라 여러 점으로 본다

한 번의 측정으로 '올랐다/내렸다'를 말하지 않는다. 주차별로 같은 절차를 반복해 구간이 함께 움직이는지를 본다. 구간이 크게 겹치면 변화로 보지 않고, 중앙값이 구간 폭을 넘어 꾸준히 한 방향으로 가야 추세로 인정한다.

SOV는 '결과'가 아니라 '2차 지표'다

그로스 리드로서 가장 자주 하는 경고다. SOV는 그 자체가 목표가 아니다. AI 답변에 많이 인용돼도 그게 리드·매출로 이어지지 않으면 허영 지표다. CFO식 측정 관점(Overdrive)에서 보면, 가시성은 매출·리드 같은 진짜 결과를 설명하는 2차 지표다. 일부 분석에서는 AI 검색을 통한 유입의 전환율이 일반 검색보다 몇 배 높게 나타나기도 하는데(구체 수치는 사례마다 다름), 이는 SOV→유입→전환의 사슬을 끝까지 측정해야 의미가 생긴다는 뜻이다.

또 SMR(Share of Model Response) 같은 변형 지표도 있지만, 이름이 무엇이든 핵심은 같다. 질문 세트의 대표성 + 다중 실행 + 신뢰구간 + 결과 지표와의 연결. 이 네 가지가 빠진 SOV는 마케팅 회의를 화려하게 만들 뿐 의사결정을 돕지 못한다.

전제조건 — 크롤러부터 통과해야 측정이 의미 있다

한 가지 덧붙이면, SOV를 측정하기 전에 우리 사이트가 애초에 후보로 진입할 수 있는지부터 확인해야 한다. AI 크롤러(GPTBot·OAI-SearchBot, PerplexityBot, ClaudeBot·anthropic-ai, Google-Extended)가 robots.txt에서 허용돼 있어야 retrieval 단계의 후보군에 들어간다. 차단돼 있으면 SOV는 구조적으로 0이고, 어떤 측정도 그 사실을 바꾸지 못한다.

Citeon은 이 원리를 제품에 담았다

Citeon은 ChatGPT·Gemini·Perplexity·Claude 4개 엔진에서 브랜드 인용을 측정해 SOV를 산출한다. 위에서 설명한 원칙 그대로, 엔진을 합산하지 않고 엔진별로 분리해 측정한다. 주간 모니터링으로 추이를 쌓아, 한 점의 노이즈가 아니라 여러 점의 흐름으로 변화를 판단할 수 있게 한다.

또한 사이트 진단 엔진으로 크롤러 허용·구조·근거 신호 같은 '후보 진입' 조건을 점검하고, 경쟁사 역추적으로 경쟁 브랜드가 어디서 인용되는지를 되짚는다. 측정은 처방으로 이어져야 의미가 있다는 게 우리 철학이다.

지금 우리 브랜드가 AI 답변에 얼마나 등장하는지, 그 숫자가 신호인지 노이즈인지 궁금하다면 무료 진단(₩0)으로 시작해보라. citeon.cloud에서 무료 AI 가시성 진단 받기.

자주 묻는 질문(FAQ)

참고자료

• Lewis et al. 2020, Retrieval-Augmented Generation (arXiv:2005.11401)
• Karpukhin et al. 2020, Dense Passage Retrieval (arXiv:2004.04906)
• Liu et al. 2023, Lost in the Middle (arXiv:2307.03172)
• AI 가시성 불확실성 정량화 — 멱법칙·부트스트랩 신뢰구간 (arXiv:2603.08924)
• LLM 출력 비결정성 6개 모델 480회 실험 (arXiv:2602.14349)
• Anthropic, Contextual Retrieval (2024)
• Conductor, Debunking AI Prompt Volume