저는 올해의 상당 부분을 ChatGPT, Claude, Perplexity, Gemini, 그리고 Google의 AI Overviews에서 브랜드가 어떻게 나타나는지를 관찰하는 시스템을 구축하는 데 보냈습니다. 이 시스템은 매일 이 다섯 가지를 모두 스캔하며, 매일 개선되고 있습니다.

의도는 Google Search Console, Google Analytics, 키워드 추적 등과의 연결을 포함하여, 심층적인 보고 및 분석 기능을 갖추고 수천 개의 도메인과 수백만 개의 프롬프트(prompt)를 추적하도록 설계된 멀티 테넌트(multi-tenant), 멀티 유저(multi-user), 엔터프라이즈급(enterprise-grade) 시스템을 구축하는 것이었습니다.

만약 저희가 이미 수십 개의 통합 기능과 강력한 보고 시스템을 갖춘 Google Cloud 기반의 멀티 테넌트 아키텍처(architecture)를 구축해 놓지 않았다면, 이는 엄청난 프로젝트가 되었을 것입니다.

처음 시작할 때, 저는 이것이 약간의 프롬프트 배관 작업(prompt plumbing)이 추가된 스크래핑(scraping) 사이드 프로젝트라고 가정했습니다.

하지만 그것보다 조금 더 컸습니다. 이것은 구축자의 관점에서 본 지형에 대한 첫 번째 기록입니다. 어떤 플랫폼이 API를 제공하는지, 어떤 플랫폼이 제공하지 않는지, 그리고 "모델에 쿼리(query)를 보낼 수 있다"는 것과 "실제 사용자가 실제로 무엇을 받는지 볼 수 있다"는 것 사이의 격차에 대한 기록입니다.

저는 완성된 설계도를 공개하지 않을 것입니다. 부분적으로는 그 중 일부가 저희의 독점 제품이기 때문이며, 또 다른 이유는 6개월 전에 작동했던 것의 절반이 이미 틀렸기 때문입니다.

공개 사항: 저는 PureSEM의 AI 가시성(visibility) 제품 부문에서 일하고 있으며, 아래에 설명된 내용의 일부는 그곳의 운영 환경(production)에서 실행됩니다. 마지막에 한 번 언급하겠지만, 그 외에 이 글은 제품이 아닌 일반적인 문제에 관한 것입니다.

목차

• 단순한 버전과 계속해서 성장하는 강력한 버전
• 플랫폼별 분석
• 답변이 매번 바뀔 때 "가시성(visibility)"이란 무엇을 의미하는가?
• 여전히 해결되지 않은 문제

단순한 버전과 계속해서 성장하는 강력한 버전

모두가 시작하게 될 지점은 바로 여기입니다.

API를 호출하고, 고객이 물어볼 법한 질문을 던진 뒤, 브랜드가 나타나는지 확인하는 것입니다.

(물론 이는 여러분이 이미 프롬프트 세트를 구축했다는 것을 전제로 하며, 이는 제가 다른 기사에서 다룰 수도 있는 또 다른 문제입니다.)

from openai import OpenAI

client = OpenAI()
...

그것을 배포하고, 서너 개의 다른 API를 추가로 사용하여 수백 개의 프롬프트(prompt)에 대해 실행한 뒤, 각 브랜드 옆에 초록색 또는 빨간색 점을 찍어 테이블에 저장한다고 가정해 봅시다.

여기에는 두 가지 문제가 있습니다.

첫째: 해당 API 호출은 사용자가 보는 결과가 아닙니다.

소비자용 ChatGPT 앱과 가공되지 않은 모델 API (raw model API)는 서로 다른 스택 (stack)입니다. 앱은 자체적인 검색 (retrieval), 자체적인 시스템 프롬프트 (system prompt), 그리고 자체적인 제품 인터페이스 (product surface)를 가지고 있으며, 사용자가 무료 티어 (free tier)인지 유료 티어 (paid tier)인지에 따라 다르게 동작합니다.

무료 버전은 지식 컷오프 (knowledge cutoff)가 있는 정적 학습 데이터 (static training data)에 의존합니다. 유료 버전은 실시간 웹 검색 (live web search)을 수행합니다. 따라서 단순한 모델 호출은 아무도 실제로 묻지 않은 질문, 즉 "순수 모델이 무엇이라고 말할 것인가"에 답할 뿐, "제품이 내 고객에게 무엇을 보여주는가"에 답하지 않습니다. 이 둘은 같은 질문이 아니며, 그 사이의 격차를 메우는 것이 실제 과업입니다.

둘째: 해당 스크립트를 다섯 번 실행하면 다섯 개의 서로 다른 답변을 얻게 됩니다.

언급되는 브랜드가 다르고, 순서가 다르며, 때로는 출처도 다릅니다. 단 한 번의 호출로는 신뢰할 수 있는 정보를 얻을 수 없습니다. 초록색 점을 찍는 것은 동전 던지기와 같습니다.

이 두 가지 문제가 확인되자, 이 프로젝트는 단순한 스크레이퍼 (scraper) 구축 작업에서 벗어나, 그 밑단에 까다로운 데이터 수집 레이어 (data-collection layer)를 동반한 샘플링 및 추론 (sampling-and-inference) 문제로 변했습니다.

플랫폼별 현황

다음은 2026년 중반 기준의 시장 현황입니다. 이 정보는 겨울이 되면 구식이 될 것입니다.

Perplexity는 개발자에게 가장 친화적입니다. Sonar API는 OpenAI와 호환되므로 클라이언트 코드 (client code)를 거의 수정할 필요가 없으며, 산문에서 정규 표현식 (regex)으로 추출해야 하는 방식이 아니라 일급 객체 메타데이터 (first-class metadata)로서 인용 (citations)을 반환합니다. 구축하기 전에 알아두어야 할 점 한 가지는, Perplexity가 Sonar를 유지 관리 모드 (maintenance mode)로 전환하고 이제 새로운 통합을 Agent API로 유도하고 있다는 것입니다. Agent API는 동일한 웹 기반 동작을 제공하면서 서드파티 모델 (third-party models) 지원을 포함합니다. Sonar는 현재도 작동하지만, 코드를 작성하기 전에 실제로 어떤 것을 원하는지 확인하십시오.

from openai import OpenAI

pplx = OpenAI(api_key=KEY, base_url="https://api.perplexity.ai")
...

문제는 이 글 전체를 관통하는 것과 동일합니다. API 결과는 로그인한 사용자가 Perplexity 앱에서 보는 것과 유사하지만, 완전히 동일하지는 않습니다. 유용하기는 하지만, 그것이 '그라운드 트루스 (ground truth, 절대적 진리)'는 아닙니다.

Google Gemini는 Google Search를 통한 그라운딩 (grounding)을 포함하여, Vertex AI 및 AI Studio를 통해 적절한 API를 제공합니다. 다시 말하지만, 이는 쿼리(query)가 가능하며, Gemini 소비자용 앱과는 다른 것이고, Gemini가 Google의 검색 인터페이스를 구동할 때 생성하는 결과물과는 매우 다른 것입니다.

**OpenAI (ChatGPT)**와 Anthropic (Claude) 모두 활성화할 수 있는 웹 검색 도구가 포함된 견고한 모델 API를 제공합니다.

모델과 실시간 검색 (live retrieval)을 함께 얻을 수 있습니다. 하지만 API를 통해서는 소비자용 제품의 정확한 검색 및 랭킹 (ranking) 동작을 얻을 수 없으며, 바로 이 동작이 고객이 브랜드를 볼지 여부를 결정합니다.

그리고 소비자용 인터페이스는 자체적인 일정에 따라 움직입니다. 예를 들어, 2026년 5월 7일, ChatGPT는 클릭 가능한 브랜드 링크를 인용 칩 (citation chips) 안에 숨기는 대신 답변에 직접 노출하기 시작했습니다. 이러한 단 한 번의 제품 변경은 이를 추적하던 브랜드들에게 대규모의 추천 트래픽 이동을 가져왔으며, 이는 여러분이 호출하는 그 어떤 API와도 관련이 없었습니다.

Google AI Overviews는 훨씬 더 어렵고 비용이 많이 드는 영역입니다.

"이 위치에서 이 쿼리에 대한 AI Overview를 보여줘"라고 요청할 수 있는 Google API는 존재하지 않습니다. AI Overviews는 검색 결과 페이지 내부에서 생성됩니다. 이는 조건부로 트리거되며 — 업계 추적기에 따르면 전체 쿼리의 약 절반 정도에서 발생하며, 건강 및 B2B 기술 분야에서는 훨씬 높고 이커머스 및 금융 분야에서는 더 낮습니다 — 또한 지리적 위치, 기기, 로그인 상태에 따라 달라집니다.

Google은 올해 Search Console에 GenAI 성능 데이터를 추가했습니다. 이는 노출수(impressions)는 제공하지만, 이를 유발한 쿼리(queries)는 제공하지 않으며, 오직 본인의 속성(property)에 대해서만 제공됩니다. 경쟁사에 대해서는 아무것도 알려주지 않으며, 해당 블록(block)이 실제로 무엇이라고 말했는지에 대해서도 아무것도 알려주지 않습니다.

따라서 AI 개요(AI Overviews)를 관찰하려면 검색 결과 페이지를 스크래핑(scraping)해야 합니다. 직접 헤드리스 브라우저(headless-browser) 장치를 구축하거나, 검색 결과 페이지(SERP)를 대신 파싱(parse)해 주는 제3자 SERP API를 사용해야 합니다.

두 방법 모두 실질적인 범주이며 작동하지만, 이 프로세스의 그 어떤 것보다 취약합니다.

이 취약성을 맛보기로 보여주자면: 잘 알려진 한 SERP API는 때때로 첫 번째 응답에서 개요(Overview)를 반환하지 못하고, 두 번째 호출에서 사용해야 하는 페이지 토큰(page token)을 전달하는데, 이 토큰은 약 4분 후에 만료됩니다. 여기서 안정적인 엔드포인트(endpoint)는 아무것도 없습니다. 이는 움직이는 목표를 관찰하는 것과 같습니다.

우리가 추적하고 있는 다섯 가지 표면(surfaces) 각각에 대해 두 가지 뚜렷한 질문이 존재하며, 업계는 이 둘 사이의 경계를 계속해서 모호하게 만들고 있습니다:

1. 모델이 무엇이라고 말하는가? API는 이에 대해 잘 답변합니다.
2. 제품이 사용자에게 무엇을 보여주는가? 대부분의 경우 이를 답변하는 API는 없으며, 상업적으로 중요한 것은 바로 이 부분입니다.

이 분야의 모든 설계는 필연적으로 그 격차를 줄이기 위해 어디까지 나아갈 것인지, 그리고 무엇을 근사치(approximate)로 처리할 것인지에 대한 결정을 포함합니다.

답변이 매번 바뀔 때 "가시성(visibility)"이란 무엇을 의미하는가?

이 부분은 개발자가 가장 주목할 가치가 있다고 생각하는 부분이며, 대부분의 도구가 대충 덮어버리는 부분이기도 합니다.

이것들은 확률적 시스템(probabilistic systems)입니다. 같은 질문을 두 번 던지면, 고정된 값을 두 번 읽는 것이 아니라 분포(distribution)에서 두 번을 추출하는 것입니다.

AI 검색 가시성 측정에 관한 2026년 연구(Schulte, Bleeker, and Kaufmann)에 따르면, 일일 소스 중복(source overlap) 범위가 34~42%로 나타났습니다. 이는 인용된 소스의 절반 이상이 하루 사이에 교체된다는 것을 의미합니다.

다른 추정치들은 훨씬 더 가혹합니다. 한 업계 분석에 따르면, 동일한 세션 내에서 동일한 프롬프트를 세 번 연속 실행했을 때 인용(citation)이 유지되는 비율은 약 2%에 불과했습니다. 정확한 수치가 어디에 위치하든 방향성은 동일합니다. 만약 당신의 도구가 프롬프트를 한 번 확인하고 "언급되었습니다" 또는 "언급되지 않았습니다"라고 보고한다면, 그것은 마치 날씨를 보고하듯 단 한 번의 추출(draw) 결과를 보고하는 것과 같습니다.

따라서 "가시성 (visibility)"은 순위가 아닙니다. 그것은 비율 (rate)입니다. "ChatGPT가 이 쿼리에 대해 Acme를 추천하는가?"라는 질문에 대한 올바른 출력값은 '예' 또는 '아니오'가 아닙니다. 대신 "샘플링된 실행의 40%에서, 이 신뢰 구간 (confidence interval) 내에서"와 같은 형태여야 합니다. 이는 측정 단위가 단일 요청 (request)이 아니라 샘플링 설계 (sampling design)임을 의미합니다.

이를 받아들이고 나면, 설계 질문들은 구체화됩니다:

• 수치가 노이즈 (noise)가 아닌 안정적인 상태가 되기 위해 프롬프트당 몇 번의 실행 (runs)이 필요한가? 한 번 이상이어야 하며, 점 추정치 (point estimate) 대신 신뢰 구간 (confidence interval)을 보고할 수 있을 만큼 충분해야 합니다. 동일한 논문의 부트스트랩 분석 (bootstrap analysis)에 따르면, 브랜드 수준의 탐지를 위해서는 하루에 프롬프트당 최소 7회의 실행이 필요하며, 소스 수준의 커버리지 (coverage)가 중요한 경우에는 최소 8회의 실행이 필요합니다. 어느 쪽이든 한 자릿수입니다. 다른 곳의 실무자 가이드라인도 비슷한 범위에 모여 있습니다. 자신만의 하한선을 정하되, 반드시 하나를 정하고 구간을 보고하십시오. 단 한 번의 실행을 마치 정답인 것처럼 보고한다면, 당신은 깔끔한 폰트로 노이즈를 출판하고 있는 것입니다.
• 어떤 변동성 축 (axes of variance)을 고정하고, 어떤 축을 대상으로 샘플링할 것인가? 세션, 지리적 위치, 시간대, 로그인 상태, 모델 버전 (model version), 그리고 대화 모드 (conversational mode) 대 검색 모드 (search mode)에 이르기까지 모든 요소가 답변을 변화시킵니다. 이 모든 것을 고정할 수는 없으므로, 고객에게 "가시성"의 일부가 될 요소가 무엇인지, 그리고 평균화하여 제거해야 할 혼란 변수 (confounds)가 무엇인지 결정해야 합니다.
• 플랫폼이 밑바닥에서 변화할 때 어떻게 추정치의 정직함을 유지할 것인가? 모델 버전 업데이트나 제품 변경은 하룻밤 사이에 모든 수치를 바꿀 수 있습니다. 당신은 "브랜드의 가시성이 변한 것"과 "표면 (surface)이 변한 것"을 구분할 수 있어야 합니다. 원시 데이터 (raw data) 상으로는 이 둘이 동일해 보일 수 있지만, 고객에게는 표현 방식이 의미 있게 달라질 수 있습니다.

이 중 어느 것도 생소한 수학이 아닙니다. 그저 데이터의 샘플링 (sampling)일 뿐입니다. 데이터 소스는 당신이 질문할 때마다 조금씩 다르게 거짓말을 합니다.

하지만 이 과정을 건너뛴다면, 그 이후의 모든 단계는 무작위 숫자에 덧칠하는 장식에 불과하게 됩니다.

아직 해결되지 않은 문제들

DEV가 가장 빛나는 순간, 즉 제가 아직 해결하지 못한 부분들에 대해 솔직하게 말하며 마무리하고 싶습니다.

그라운드 트루스 (Ground truth, 정답 데이터)가 존재하지 않습니다. 저는 API를 통해 모델을 관찰하고 페이지를 통해 제품을 관찰할 수 있지만, 실제 세션에서 특정 실제 사용자가 실제로 무엇을 받았는지는 볼 수 없습니다. 모든 것은 숨겨진 분포 (hidden distribution)에 대한 추정치입니다. 저는 그 추정치를 더 정교하게 만들 수는 있지만, 확실하게 만들 수는 없습니다.

기여도 (Attribution) 측정은 훨씬 더 어렵습니다. 언급 (mention)이 클릭은 아니며, AI 노출 (surfaces)은 보통 사용자를 어디로도 보내지 않고 답변만 제공합니다.

"이번 달에 브랜드 이름이 더 자주 언급되었다"는 사실을 기업이 수익으로 연결할 수 있는 무언가와 연결하는 것은 미해결 과제이며, 떠도는 확신에 찬 기여도 수치 대부분은 보이는 것보다 훨씬 불확실합니다.

서비스 환경이 도구보다 더 빠르게 변합니다. 이 글에서 다룬 모든 플랫폼은 제가 이를 기반으로 구축하는 동안 동작 방식의 변화를 출시했습니다. 이 글을 포함하여 당신이 쓰는 모든 것은 발행되는 날 즉시 구식이 됩니다. 올바른 직관은 고정된 스키마 (fixed schema)가 아니라 변화 감지 (change detection)를 위해 구축하는 것입니다. 왜냐하면 스키마는 변할 것이며, 당신은 이전의 형태를 조용히 보고하기보다는 변화를 알아차려야 하기 때문입니다.

그리고 핵심적인 격차는 좁혀지지 않습니다. API는 모델을 설명합니다. 고객은 제품 속에서 살아갑니다. 제품이 실제로 무엇을 보여주었는지를 공개하기 전까지는 — 그리고 저는 그것을 기대하며 숨을 참지는 않겠습니다만 — 이 작업은 신중한 근사치 (approximation)를 구하는 일입니다.

상단에서 언급했듯이, 이것은 PureSEM의 AI 가시성 제품 뒤에서 실행되는 시스템입니다. 앞서 언급한 CRM 예시 대신 실제 브랜드 및 경쟁사 데이터를 대상으로 위에서 설명한 것과 동일한 샘플링 문제를 실행하고 있습니다.

만약 여러분이 이 분야에서 무언가를 구축하고 있다면, 특히 실행 간 변동성 (run-to-run variance)을 어떻게 처리하고 계시는지 듣고 싶습니다. 그 부분이 바로 제 아이디어보다 더 나은 아이디어들이 존재할 것이라고 의심되는 지점이며, 나머지 모든 것들이 의미가 있을지를 결정짓는 핵심적인 부분이기 때문입니다.