Query fan-out 분석은 실행 로그에서 실제로 관측된 확장 질의를 원 질문·엔진·관측일과 연결해 정리하고, 기존 글 보강·지원 글 작성·추가 관측 중 무엇을 할지 판단하는 방식입니다. 관측값과 사람이 만든 아이디어를 분리해야 반복되지 않은 검색어를 콘텐츠 수요로 과장하지 않을 수 있습니다.
원 질문만 보면 놓치는 질문이 생깁니다
예를 들어 “AI 검색 가시성을 어떻게 측정하나요?”라는 질문에는 측정 지표, 엔진별 차이, 관측 주기, 대시보드 해석처럼 서로 다른 과업이 숨어 있을 수 있습니다. 원 질문만 보고 한 문서로 모두 답하려 하면 글이 넓어지고 얕아집니다. 반대로 하위 질문마다 새 글을 만들면 같은 의도를 여러 페이지가 나눠 갖게 됩니다.
Query fan-out은 이런 중간 지점을 찾기 위한 관찰 도구입니다. Google은 AI Overviews와 AI Mode가 여러 하위 주제와 데이터 소스에 걸쳐 관련 검색을 수행하는 query fan-out 기법을 사용할 수 있다고 설명합니다. GEOMIX(지오믹스)는 이 표현을 더 좁게 사용합니다. 실행 로그의 search_queries에서 실제로 확인된 질의만 관측값으로 기록하고, 사람이 떠올린 연관어는 아이디어로 따로 관리합니다.
관측값과 아이디어를 같은 목록에 넣지 않는 이유
둘은 모두 콘텐츠 기획에 도움이 되지만, 증거의 강도가 다릅니다. 관측 질의는 언제·어떤 엔진·어떤 원 프롬프트에서 나왔는지 되짚을 수 있습니다. 가설 질의는 아직 검증되지 않았지만 독자 인터뷰나 영업 현장에서 발견한 문제를 담을 수 있습니다. 둘을 합산하면 “많이 관측됐다”는 잘못된 결론이 만들어집니다.
| 구분 | 무엇을 뜻하나 | 콘텐츠 판단에서의 위치 |
|---|---|---|
| 관측 fan-out | 실행 로그에 실제 남은 확장 질의 | 반복성·분포를 계산하는 근거 |
| 정규화 변형 | 공백·대소문자·기호 차이만 정리한 같은 질의 | 비교용 키로 묶되 원문은 보존 |
| 의도 클러스터 | 해결하려는 과업이 비슷한 질의 묶음 | 기존 글과의 겹침을 판단 |
| 가설 질의 | 사람이 만든 연관 질문 또는 추정어 | 별도 아이디어 큐에서 검증 |
정규화는 문장을 예쁘게 고치는 과정이 아닙니다. 의미가 같은 표기 차이만 묶고, 단어를 임의로 빼거나 넓은 개념으로 바꾸지 않는 것이 원칙입니다. ‘AI 검색 가시성 측정’과 ‘AI 검색 가시성 측정 방법’은 가까워 보여도, 실제로는 사용자가 원하는 답의 깊이가 다를 수 있습니다.
로그에서 콘텐츠 판단까지 이어지는 과정
관측된 질의를 바로 키워드 목록으로 공개하지 않습니다. 원문을 보존한 뒤, 비교를 위해서만 정규화하고, 부모 프롬프트와 엔진·관측일을 다시 연결합니다. 그 다음에야 같은 과업을 묻는지, 기존 페이지가 이미 답하는지, 자사 페이지가 답변 근거로 선택됐는지를 순서대로 살핍니다.
관측 질의는 새 글 제목이 아니라 판단 재료입니다. 반복성과 기존 페이지의 답변 적합도를 확인한 뒤에야 콘텐츠 작업으로 바뀝니다.
- 완료된 응답에서 원 프롬프트, 엔진, 실행 시각,
search_queries, 인용 URL을 함께 읽습니다. - 같은 실행 안의 완전 동일 질의는 한 번만 세고, 다른 날짜나 다른 엔진에서 다시 나온 관측은 유지합니다.
- 질의별로 반복 수뿐 아니라 부모 프롬프트 수, 관측일 수, 엔진 수를 따로 계산합니다.
- 기존 글이 그 질문에 직접 답하는지 검토하고, 부족한 근거인지 새로운 과업인지 구분합니다.
- 보강·지원 글·보류 중 하나를 선택하고, 이후 AI 검색 가시성 측정 방법론의 같은 패널로 변화를 다시 확인합니다.
반복 횟수보다 중요한 네 가지 판단 기준
한 질의가 여러 번 나왔다고 해도 한 프롬프트의 표현 습관일 수 있습니다. 반대로 횟수는 적어도 서로 다른 질문과 엔진에서 반복된다면 더 넓은 과업을 가리킬 수 있습니다. 그래서 우선순위는 빈도 하나가 아니라 아래 신호를 함께 읽어야 합니다.
| 판단 기준 | 확인할 질문 | 놓치기 쉬운 함정 |
|---|---|---|
| 부모 프롬프트 다양성 | 서로 다른 원 질문에서도 나왔는가 | 한 질문의 세부 표현일 수 있습니다 |
| 시간·엔진 분포 | 여러 관측일·엔진에 걸쳐 보이는가 | 하루치 결과를 일반화할 수 있습니다 |
| 기존 페이지 적합도 | 현재 페이지가 그 질문에 바로 답하는가 | 주제는 같아도 사용자의 과업이 다를 수 있습니다 |
| 자사 인용 연결 | 그 질문의 답변에서 자사 원문이 선택되는가 | 인용이 없다고 새 글이 정답은 아닙니다 |
이 기준은 점수표를 자동 생성하기 위한 것이 아닙니다. 콘텐츠 팀이 왜 어떤 작업을 먼저 했는지 나중에 설명할 수 있게 만드는 질문 목록입니다. 신호가 약하면 제목을 확장하는 대신 관측을 더 쌓는 편이 낫습니다.
새 글보다 기존 글 보강이 먼저인 경우
같은 질문을 다루는 페이지가 이미 있다면, 먼저 그 페이지가 답을 시작하는 방식부터 확인합니다. 제목만 맞고 첫 문단이 정의에 머물러 있거나, 비교표와 근거가 빠졌거나, 사용자가 다음에 궁금해할 조건이 없으면 새 페이지를 만들기보다 기존 글을 깊게 만드는 편이 좋습니다.
반대로 원 질문은 비슷해도 결정하려는 일이 다르면 지원 글이 필요합니다. 예를 들어 “측정 방법”을 설명하는 글과 “엔진별 수치가 왜 다른지”를 해석하는 글은 서로 연결되지만 같은 글로 합치면 독자가 필요한 부분을 찾기 어려워집니다. 이때는 각 글이 어떤 질문을 끝까지 답하는지 분명히 하고, 문맥 안에서 서로 연결합니다.
| 상황 | 우선 작업 | 이유 |
|---|---|---|
| 기존 글이 질문은 맞지만 근거·예시가 부족함 | 기존 글 보강 | 같은 의도의 중복 페이지를 피합니다 |
| 사용자의 결정 과업이 다름 | 지원 글 작성 | 한 글에 서로 다른 답을 억지로 넣지 않습니다 |
| 비슷한 글이 여러 개 있음 | 통합·내부 링크 정리 | 신호와 권한이 여러 페이지로 흩어지는 것을 줄입니다 |
| 한 번만 보이거나 재현이 약함 | 보류 후 추가 관측 | 우연한 표현을 수요로 오해하지 않습니다 |
관측 결과를 과장하지 않기 위한 선
관측 fan-out은 AI 시스템의 내부 추론을 공개하는 창이 아닙니다. 로그에 질의가 보였다고 해서 그 질의가 인용을 보장하지는 않으며, 로그에 없다고 해서 시스템이 관련 탐색을 하지 않았다고 단정할 수도 없습니다. 빈도와 인용이 함께 움직여도 인과관계라고 말할 수 없는 이유입니다.
그래서 공개 글에서는 관측된 질의 자체를 무더기로 나열하기보다, 어떤 기준으로 정리했고 어떤 상황에서 콘텐츠 작업으로 바꾸는지를 설명하는 편이 낫습니다. 특정 고객의 질문, 비공개 실행 로그, 인증 정보는 공개하지 않고, 관측 사실과 분석가의 가설을 표기와 운영 기록에서 분리해야 합니다.
자주 묻는 질문
Query fan-out이 많으면 새 글을 많이 만들어야 하나요?
아닙니다. fan-out은 질문이 갈라지는 신호일 뿐입니다. 기존 페이지가 그 질문에 직접 답할 수 있다면 보강이 새 글보다 먼저입니다.
사람이 만든 연관 질문도 분석에 쓸 수 있나요?
쓸 수 있지만 관측값과 합산하지 않는 편이 안전합니다. 가설 질의는 별도 큐에 두고, 실제 관측이나 독자 조사로 다시 확인해야 합니다.
한 엔진에서만 관측된 질의는 버려야 하나요?
버릴 필요는 없지만 성과 주장이나 즉시 발행의 근거로 쓰기에는 약합니다. 엔진·날짜·부모 프롬프트를 넓혀 추가 관측한 뒤 판단하는 편이 좋습니다.