Bing·Copilot에서 인용되려면, 먼저 bingbot이 당신의 페이지를 색인하고, Copilot의 검색 단계가 그 페이지를 '질문에 답하는 근거'로 골라낼 수 있어야 한다. Copilot은 Microsoft의 Bing 검색 인덱스를 근거 창고로 쓰고, OpenAI 계열 생성 모델로 답을 쓰는 것으로 알려진 시스템이다. 즉 '구글에 노출되면 끝'이 아니라, Bing이라는 별도 색인에 들어가 있고, 그 안에서 RAG(검색→재정렬→생성)의 각 관문을 통과하는 글만 답변에 인용된다. 이 글은 그 관문이 정확히 무엇이고, 왜 어떤 글은 인용되고 어떤 글은 색인은 됐는데도 끝내 답변에 못 들어가는지를 메커니즘으로 설명한다.
먼저: Copilot은 어떻게 답을 만드는가 (RAG의 3단계)
생성형 검색 답변의 뼈대는 거의 모두 RAG다. RAG는 Lewis 등이 2020년에 제안한 구조로(arXiv:2005.11401), 모델이 외운 지식(파라메트릭 메모리)에만 의존하지 않고 외부 문서를 실시간으로 끌어와(비파라메트릭 메모리) 답을 쓰는 방식이다. 이걸 이해하면 'Bing·Copilot 최적화'가 결국 무엇을 손봐야 하는 일인지가 또렷해진다.
일상 비유로 풀면 이렇다. Copilot은 시험을 보는 똑똑한 학생이고, Bing 인덱스는 그 학생이 들고 들어가는 오픈북(참고 자료실)이다. 학생이 아무리 똑똑해도, 자료실에 당신 책이 꽂혀 있지 않으면(=색인 안 됨) 인용할 수 없다. 꽂혀 있어도 사서가 그 책을 '이 질문에 맞는 책'으로 뽑아주지 않으면(=검색에서 탈락) 펼쳐보지 못한다. 펼쳤어도 정작 인용하기 좋은 문장이 없으면(=생성 단계 탈락) 결국 다른 책을 베껴 쓴다.
| 단계 | 하는 일 | 탈락하면 | 당신이 손봐야 할 것 |
|---|---|---|---|
| ① 색인(Index) | bingbot이 페이지를 크롤링·저장 | 아예 후보에 못 든다 | 크롤 허용·발견 가능성·기술 SEO |
| ② 검색·재정렬(Retrieve+Rerank) | 질문과 의미가 가까운 문서를 뽑아 순위화 | 색인은 됐는데 안 불려 나옴 | 의미 일치·청크 품질·하이브리드 매칭 |
| ③ 생성(Generate) | 뽑힌 문서로 답을 쓰고 출처를 단다 | 읽혔는데 인용 안 됨 | 인용하기 좋은 문장·수치·구조 |
핵심 통찰: 대부분의 '인용 안 됨'은 ②와 ③에서 발생한다. 사람들은 ①(색인)만 끝내고 "왜 인용 안 되지?"라고 묻지만, 진짜 병목은 그 다음에 있다.
① 색인 관문: bingbot에게 보여야 후보가 된다
구글 SEO만 해온 팀이 가장 자주 놓치는 사실이 있다. Copilot의 근거 창고는 구글이 아니라 Bing 인덱스다. 구글에 잘 노출돼도 Bing에서 색인 누락이면 Copilot은 당신을 인용할 재료 자체가 없다. 그래서 첫 단추는 'Bing이 나를 보고 있는가'다.
크롤러는 robots.txt로 통제된다. 생성형 AI 시대에는 검색 크롤러와 'AI 학습/검색용' 크롤러가 갈라지고 있다는 점을 기억해야 한다. OpenAI는 GPTBot(학습)·OAI-SearchBot(검색 답변), Anthropic은 ClaudeBot·anthropic-ai, 구글은 Google-Extended를 쓴다. Microsoft 진영의 전통적 색인 크롤러는 bingbot이다. 이 크롤러들을 robots.txt에서 차단하면, 그 엔진의 답변 후보군에서 통째로 빠진다.
# robots.txt — AI 검색 후보 진입을 막지 않도록 점검
User-agent: bingbot
Allow: /
User-agent: OAI-SearchBot
Allow: /
User-agent: PerplexityBot
Allow: /
# 의도치 않은 전체 차단이 가장 흔한 사고
# User-agent: *
# Disallow: / ← 이 한 줄이 당신을 모든 후보에서 지운다네이버 사례가 이 원리를 극적으로 보여준다. 네이버는 외부 크롤러를 막기 때문에, 글로벌 AI들은 네이버 본문을 직접 읽지 못하고 나무위키·위키백과·티스토리 같은 크롤 가능한 우회 경로로 한국어 지식을 채운다. 크롤 허용 여부가 곧 '인용 가능 여부'라는 것을, 차단된 쪽이 증명하는 셈이다.
색인 관문 체크리스트:
- Bing Webmaster Tools에 사이트 등록·사이트맵 제출 (Bing 색인은 별도 관리 대상)
- robots.txt에서 bingbot·OAI-SearchBot이 막히지 않았는지 확인
- 핵심 콘텐츠가 JS 렌더링에만 의존하지 않고 HTML에 존재하는지(크롤러가 본문을 실제로 읽는지)
- HTTPS·정상 응답·중복 캐노니컬 정리 등 기본 기술 위생
② 검색·재정렬 관문: 의미가 맞아야 불려 나온다
색인이 됐다고 인용되는 게 아니다. 질문이 들어오면 시스템은 수많은 색인 문서 중 '이 질문에 답하는' 소수만 끌어온다. 여기서 두 가지 검색이 동시에 돈다.
키워드 검색 vs 의미 검색, 그리고 하이브리드
전통적 검색은 BM25 같은 키워드 일치다(도서관의 단어 색인 카드). 반면 Dense Passage Retrieval(Karpukhin 등 2020, arXiv:2004.04906)은 문장을 임베딩 벡터로 바꿔 의미가 가까운 것을 찾는다. "AI 검색에 안 잡혀요"와 "생성형 엔진 가시성이 낮다"는 단어는 다르지만 의미는 같다 — 의미 검색은 이걸 같은 것으로 본다. DPR 논문은 의미 검색이 BM25를 능가할 수 있음을 보였다.
비유하면, 키워드 색인은 카드 목록이고 의미 검색은 주제를 아는 사서다. 둘을 합친 게 하이브리드 검색이다. 공개 벤치마크들을 종합하면 recall@10 기준 의미 단독 약 78%, BM25 단독 약 65%인데, 둘을 RRF로 합치면 약 91%까지 오른다. 어느 한쪽만으로는 놓치는 문서를 서로 보완하기 때문이다.
| 검색 방식 | recall@10(종합) | 강점 | 약점 |
|---|---|---|---|
| BM25(키워드) | ~65% | 정확한 용어·고유명사 | 같은 뜻 다른 표현 놓침 |
| 의미(임베딩) | ~78% | 의도·동의어 포착 | 정확한 키워드 약함 |
| 하이브리드(RRF) | ~91% | 둘의 장점 결합 | 구현 복잡 |
실무 함의: 당신 글에 사용자가 실제 쓰는 키워드(BM25용)와 그 개념의 의미적 설명(임베딩용)이 둘 다 있어야 양쪽 검색에 다 걸린다. 전문 용어만 나열하거나, 반대로 두루뭉술한 비유만 있으면 한쪽 검색에서 탈락한다.
청크 단위로 평가된다 — 그래서 '맥락 있는 조각'이 이긴다
RAG는 글 전체가 아니라 잘게 나눈 조각(청크) 단위로 검색한다. 그래서 한 문단이 앞뒤 맥락 없이 떼어져도 스스로 말이 되는지가 결정적이다. Anthropic의 Contextual Retrieval(2024) 실험은 이 지점을 정량화했다: 각 청크 앞에 그 청크가 무슨 맥락인지 설명을 덧붙였더니 검색 실패율이 35% 감소(5.7%→3.7%)했고, BM25를 결합하니 49%, 재정렬(reranking)까지 더하니 67% 감소했다. 같은 연구는 상위 후보를 넓게(top-20) 보는 것을 권한다.
이게 글쓰기에 주는 교훈은 명확하다. 대명사와 "위에서 말했듯"으로 이어진 문단은 청크로 떼어지면 미아가 된다.
❌ 약한 예 (맥락 의존 청크): "이 방법은 그래서 더 효과적이다. 앞 절에서 본 것처럼 비용도 낮다."
✅ 강한 예 (자족 청크): "하이브리드 검색은 키워드와 의미 검색을 결합하기 때문에 단독 방식보다 재현율이 높다. 공개 벤치마크 종합에서 하이브리드는 recall@10 약 91%로, 의미 단독 78%·BM25 단독 65%를 웃돈다."
강한 예는 떼어내도 '무엇에 대한, 어떤 근거의' 문단인지 스스로 설명한다. 그래서 검색에 더 잘 걸리고, 재정렬 단계에서 질문과의 관련성도 높게 매겨진다.
재정렬(reranking): 1차 후보를 질문과 함께 다시 읽는다
1차 검색이 후보 수십 개를 던지면, cross-encoder 기반 재정렬기가 '질문+문서'를 함께 읽어 진짜 답이 되는 순서로 다시 줄 세운다. 재정렬은 NDCG를 보통 5~15포인트, 난도 높은 질의에선 약 20까지 끌어올린다고 보고된다. 1·2위에 들어야 생성 단계에서 실제로 인용될 확률이 급등하므로, '대충 관련 있는 글'과 '질문에 정확히 답하는 글'의 운명은 여기서 갈린다.
③ 생성 관문: 인용하기 좋게 써야 베껴 쓴다
읽혔다고 인용되는 것도 아니다. 마지막으로 모델이 답을 '쓸 때', 여러 후보 문서 중 인용하기 편한 문장을 고른다. 이 단계를 직접 겨눈 연구가 GEO(Generative Engine Optimization, Aggarwal 등 2023, arXiv:2311.09735, KDD 2024)다. GEO 실험은 본문에 통계 수치·출처 인용·전문가 직접 인용문을 추가하면 생성 엔진에서의 가시성이 특정 조건에서 최대 약 40% 상승함을 보였다. 키워드를 쑤셔 넣는 식의 전통 SEO 트릭은 오히려 효과가 약했다.
왜 그럴까? 생성 모델은 '주장의 근거가 분명한 문장'을 선호한다. 출처와 숫자가 붙은 문장은 모델이 '이건 인용해도 안전하다'고 판단하기 쉽다. 반대로 형용사만 가득한 마케팅 문장은 근거가 없어 베껴 쓰기 위험하다.
❌ 약한 예: "우리 솔루션은 업계 최고 수준의 압도적인 성능을 자랑합니다."
✅ 강한 예: "한 공개 벤치마크 종합에서 하이브리드 검색은 recall@10 약 91%를 기록해, 의미 검색 단독(78%)보다 13포인트 높았다."
약한 예는 검증 불가능한 자랑이라 어떤 엔진도 인용하지 않는다. 강한 예는 숫자·비교·맥락이 있어 그대로 답변에 옮겨도 안전하다. 'AI에게 인용당하기'는 결국 모델이 다루고 옮길 수 있는 문장을 미리 써두는 일이다.
Lost in the Middle: 핵심은 앞과 끝에
모델이 여러 문서를 한 번에 읽을 때, 긴 맥락의 중간에 있는 정보를 놓치는 U자형 경향이 있다(Liu 등 2023, arXiv:2307.03172). 입력 맨 앞과 맨 끝의 정보는 잘 쓰고 가운데는 흘린다. 그래서 핵심 결론·정의·수치는 문서 맨 앞(직답)과 단락 첫 문장에 배치해야 한다. 이 글이 첫 문장에 결론을 박은 것도 같은 이유다.
실무 규칙:
- 각 H2/H3 바로 아래 첫 문장에 그 섹션의 핵심 답을 둔다(역피라미드).
- 중요한 정의·수치를 문단 중간에 파묻지 말고 앞으로 끌어올린다.
- 표·리스트로 정보를 구조화하면 모델이 항목을 잃지 않고 집어 든다.
Bing·Copilot 특유의 결: GPT 성향 + Bing 인덱스
Copilot은 OpenAI 계열 모델로 답을 쓰고 Bing의 검색 결과를 근거로 삼는 것으로 알려져 있다. 그래서 두 가지 성향이 겹친다. 풀에 없는 Bing·Copilot 전용 인용 통계는 단정하지 않되, 공개된 인용 패턴 분석에서 끌어낼 수 있는 정성적 결은 다음과 같다.
- GPT 계열의 출처 취향: 대규모 인용 분석에서 ChatGPT는 위키백과(약 47.9%)·커뮤니티성 출처를 자주 인용하는 경향이 관찰됐다. Copilot도 같은 모델 계열인 만큼, 잘 정리되고 권위가 명확한 백과사전형·구조화된 출처가 유리할 개연성이 크다. (단, Copilot 전용 수치는 공개 풀에 없어 단정하지 않는다.)
- Bing 인덱스 의존: 구글에만 최적화된 콘텐츠는 Bing 색인에서 누락되거나 순위가 다를 수 있다. Bing Webmaster Tools 등록이 사실상 입장권이다.
- 인용은 엔진마다 다르다: 같은 분석에서 인용 출처의 약 90%가 엔진마다 달랐고, ChatGPT와 Perplexity의 도메인 중복은 약 11%에 불과했다. 즉 한 엔진에서 인용된다고 다른 엔진에서도 되는 게 아니다 — Copilot을 노린다면 Bing 색인+GPT 성향을 따로 점검해야 한다.
한 줄 요약: Copilot 최적화 = (구글이 아니라) Bing에 확실히 색인 + GPT가 인용하기 좋은 근거형 글쓰기.
인용되는 글의 신뢰도: faithfulness라는 잣대
생성 답변 품질을 재는 지표 중 RAGAS의 faithfulness가 있다. 이는 답변의 각 주장이 출처 문서에서 실제로 추적되는 정도를 뜻한다. 실무서들에서 흔히 0.9 이상이면 안정적, 0.7 미만이면 위험으로 본다(팀마다 기준은 다르다). 엔진 입장에서, 당신 글을 인용했을 때 그 주장이 본문에서 그대로 확인되면 faithfulness가 높아진다. 즉 본문에서 검증 가능한 주장을 쓰는 글은 엔진이 안심하고 인용한다. 모호한 과장은 인용해봐야 엔진의 답변 신뢰도만 떨어뜨리므로 회피된다.
측정의 함정: 한 번 본 인용은 노이즈다
"Copilot에 우리가 인용됐다/안 됐다"를 한 번 보고 판단하면 안 된다. LLM은 temperature=0에서도 GPU 연산·배치 처리 특성 때문에 출력이 흔들린다. 한 분석에서는 2,350억 파라미터급 모델이 같은 입력 1,000회에 80가지 출력을 냈다. AI 가시성의 불확실성을 정량화한 연구는 인용이 멱법칙처럼 출렁이므로 다중 실행 + 부트스트랩 신뢰구간으로 봐야 한다고 권한다. 단일 측정은 노이즈, 추세가 신호다.
또 하나, 'AI에서 우리 브랜드가 몇 번 검색되나'(프롬프트 볼륨)는 실측이 사실상 불가능하다. 시장의 1% 미만 패널로 모델링한 추정치일 뿐이다. Conductor의 표현처럼 "신뢰할 수 없는 검색량 데이터는 없는 것보다 나쁘다". 그래서 측정은 SOV(Share of Voice, 카테고리 AI 답변 중 우리 브랜드가 언급된 비율)를 다회 측정해 추세로 보는 게 정직하다. 질문 세트를 어떻게 짜느냐가 결과를 좌우하므로, 질문 설계의 투명성도 함께 봐야 한다.
실전 체크리스트: Copilot 인용을 부르는 글
| 관문 | 해야 할 것 | 피할 것 |
|---|---|---|
| 색인 | Bing Webmaster 등록, bingbot 허용, HTML 본문 노출 | 구글만 신경, robots 전체 차단, JS 의존 본문 |
| 검색 | 실사용 키워드 + 의미 설명 병기, 자족적 청크 | 맥락 의존 대명사, 키워드만/비유만 |
| 재정렬 | 질문에 정면으로 답하는 문단, 명확한 H2/H3 | 두루뭉술 관련 언급 |
| 생성 | 수치·출처·직접 인용문, 검증 가능한 주장 | 형용사 자랑, 근거 없는 단정 |
| 배치 | 핵심을 앞·끝에(직답), 표·리스트 구조화 | 핵심을 중간에 파묻기 |
| 측정 | SOV 다회 측정·추세, 신뢰구간 | 단발 확인, 프롬프트 볼륨 맹신 |
Citeon은 이 원리를 제품에 담았다
위에서 본 4관문(색인→검색→재정렬→생성)은 점검하려면 흩어진 데이터를 모아야 한다. Citeon은 이걸 한 흐름으로 묶었다.
- 4엔진 인용 측정(SOV): ChatGPT·Gemini·Perplexity·Claude에서 카테고리 질문에 대해 당신 브랜드가 얼마나 인용되는지를 측정한다. Copilot은 OpenAI 모델 계열이라 ChatGPT 측정 결과가 생성 단계 성향을 읽는 가장 가까운 대리 지표가 된다(엔진별 인용이 다르므로 절대치가 아니라 추세로 본다).
- 사이트 진단엔진: URL을 넣으면 색인·구조·근거형 글쓰기 관점에서 SEO/AEO/GEO 점수와 한국어 처방을 돌려준다 — 위 ①~③ 관문의 약점을 짚어준다.
- 경쟁사 역추적: 같은 카테고리에서 어떤 경쟁 도메인이 인용을 가져가는지 되짚어, 그들이 통과한 관문을 벤치마킹하게 한다.
- 주간 모니터 추이: 단발 측정의 노이즈 문제를 추세로 푼다 — 인용은 출렁이므로 한 주의 점이 아니라 곡선을 본다.
지금 내 사이트가 어느 관문에서 막히는지 궁금하다면 무료진단(₩0)으로 시작하면 된다. → citeon.cloud에서 무료 AI 가시성 진단 받기
자주 묻는 질문
구글 SEO를 잘해두면 Bing·Copilot도 자동으로 잡히나요?
아닙니다. Copilot의 근거 창고는 구글이 아니라 Bing 인덱스로 알려져 있습니다. 구글에 잘 노출돼도 Bing에서 색인이 누락되면 Copilot은 인용할 재료가 없습니다. Bing Webmaster Tools 등록·사이트맵 제출·bingbot 크롤 허용을 별도로 점검해야 합니다.
Copilot에 인용되려면 가장 효과가 큰 한 가지는 무엇인가요?
근거형 글쓰기입니다. GEO 연구(Aggarwal 등 2023)는 통계·출처·전문가 직접 인용문을 본문에 더하면 생성 엔진 가시성이 특정 조건에서 최대 약 40%까지 올랐다고 보고했습니다. 키워드 반복 같은 전통 트릭보다, 검증 가능한 숫자와 출처가 붙은 문장이 모델이 안심하고 옮길 수 있어 더 잘 인용됩니다.
왜 우리 글이 색인은 됐는데 답변에 안 나올까요?
병목이 검색·재정렬·생성 단계에 있을 가능성이 큽니다. 청크로 떼어지면 맥락이 사라지는 문단(대명사·"위에서 말했듯" 의존)은 검색에 안 걸리고, 두루뭉술한 문장은 재정렬에서 밀립니다. 각 문단을 자족적으로 쓰고 핵심을 앞에 배치하면 통과율이 올라갑니다. Anthropic 실험에서도 청크에 맥락을 더하자 검색 실패율이 35% 감소했습니다.
Copilot에 인용됐는지 한 번 확인했는데 그걸 믿어도 되나요?
단일 측정은 노이즈로 보는 게 안전합니다. LLM은 temperature=0에서도 출력이 흔들리고, 인용은 멱법칙처럼 출렁입니다. 여러 번 측정해 추세(SOV)와 신뢰구간으로 판단해야 합니다. 한 시점의 인용/미인용으로 콘텐츠 전략을 뒤집지 마세요.
핵심 정보를 글 어디에 둬야 하나요?
맨 앞과 각 문단 첫 문장에 두세요. 모델은 긴 맥락의 중간 정보를 놓치는 U자형 경향이 있습니다(Liu 등 2023, Lost in the Middle). 결론·정의·수치를 중간에 파묻지 말고 직답으로 앞세우고, 표·리스트로 구조화하면 모델이 항목을 잃지 않고 집어 듭니다.
참고자료
- Lewis et al. 2020 — Retrieval-Augmented Generation (RAG 원전)
- Karpukhin et al. 2020 — Dense Passage Retrieval
- Liu et al. 2023 — Lost in the Middle
- Aggarwal et al. 2023 — GEO: Generative Engine Optimization (KDD 2024)
- Anthropic 2024 — Contextual Retrieval
- Conductor — Debunking AI Prompt Volume
- Citeon — AI 가시성 무료진단