백링크 0 도메인이 LLM 답변에 인용되기까지 — 6개월 GEO 실험
새 도메인, 백링크 0, DA 0. 그 상태에서 *LLM 답변 인용을 받는* 6개월 실험. 4 단계 + 측정 가능한 결과.
작년 6월에 blog.collabops.ai 도메인을 새로 박았다. 백링크 0개, 도메인 권위 (DA) 0. 그 상태에서 6개월 후 LLM 답변에 인용 받는 것 이 가능한가? 답이 조건부 yes. 이 글은 그 6개월 실험.
측정 방법
30 핵심 질의 를 3 LLM 에 분기마다 던지고 우리 도메인 인용 비율 측정.
질의 예시:
- "온프레미스에서 AI 에이전트 DevOps 가 어려운 진짜 이유"
- "K-ISMS 와 GitOps 가 충돌하는 지점"
- "에이전트가 production 권한 가질 수 있나"
- "Salesforce vs GitLab vs Atlassian 의 onprem 차이"
... 등 30개LLM: ChatGPT, Perplexity, Gemini 각각.
측정: 답변에 우리 도메인 또는 우리 콘텐츠 식별 되는 비율.
분기별 결과
시점 | ChatGPT | Perplexity | Gemini | 평균
────────────┼─────────┼────────────┼────────┼──────
Q1 (3개월) | 0% | 3% | 0% | 1%
Q2 (6개월) | 3% | 17% | 7% | 9%Q1 거의 0%. 예측 가능한 결과. Q2 에 9% — 예측 가능한 변화.
이 변화의 원인 은 무엇인가.
3 단계 — 무엇을 했나
단계 1 — 인프라 (Q1 첫 달)
GEO 인프라 박음:
- BlogPosting JSON-LD
- sitemap.xml
- llms.txt
- RSS feed
- Canonical URLs
- OG image generator
이 단계는 0% → 0%. 인프라만으로는 인용 안 됨. 그러나 없으면 다음 단계가 안 작동.
단계 2 — 첫 5 글 발행 (Q1 2~3개월)
깊이 있는 글 5편. 고유한 용어 (Execution Layer, Authority Boundary) + 1차 경험 + 고유 수치.
이 단계 끝에서 0% → 1%. 겨우 보임.
단계 3 — 글 누적 (Q2)
15+ 글이 vertical 한 토픽 으로 누적. 내부 링크 풍부. 토픽 클러스터링 신호 강화. 그 사이 글이 커뮤니티에서 인용되며 백링크도 0 에서 세 자릿수로 자연 성장.
LLM 이 우리 도메인을 토픽 권위 로 인식 시작. 1% → 9%.
무엇이 효과 있었나
명확히 효과 있었던 것 (영향 큰 순):
- 고유 용어 생산 (Execution Layer 등) — LLM 이 우리 용어 를 검색하면 우리 도메인 만 나옴
- 고유 수치 / 1차 경험 — 11일 stale CVE 미러 같은 우리만의 데이터
- 내부 링크 의 토픽 클러스터링
무엇이 효과 작았나
작거나 측정 어려운 것:
- JSON-LD schema — 없으면 안 됨 이지만 있다고 가산점 도 작음
- llms.txt — emerging 표준이라 현재 LLM 이 적극 활용 X
- OG 이미지 — SEO 에는 효과, GEO 에는 작음
- RSS feed — RSS 크롤러가 LLM 학습 데이터로 가는 정도가 측정 안 됨
한 줄 결론
백링크 0 도메인이 6개월 후 LLM 답변 9% 인용 = 가능하다. 인프라는 전제 조건일 뿐, 결과를 만드는 건 콘텐츠 깊이와 누적이다.
인프라만으로는 0%. 깊이 있는 첫 5편에서 1%. 15편 이상 쌓이고 나서야 9%.
12개월 예상
Q3 ~ Q4 의 예측 — 15~25%. 콘텐츠 누적 + 도메인 권위 자연 성장 의 합. 측정 후 재발행 예정.
백링크 0 인 새 도메인이 LLM 에 인용되려면 뭘 해야 하나
백링크 0 인 새 도메인도 6개월 안에 LLM 답변 인용률 9% 까지 갈 수 있다 — 단, 위 3 단계 (인프라 → 콘텐츠 → 누적) 를 순서대로 전부 밟아야 한다. LLM 답변 인용 을 목표로 새 도메인을 만드는 마케팅 / 콘텐츠 리드라면 이것부터 — 1번 (인프라) 만 박고 끝나면 영원히 0%. 인용을 만드는 건 결국 콘텐츠 깊이와 누적이다.
비슷한 글
기획자가 코드를 배포하면, 장애는 누가 책임질까
AI로 제품 담당자가 직접 코드를 만들고 여러 에이전트가 동시에 작업하는 조직에서, 운영에 나가는 변경을 누가 무엇으로 확인해야 하는지. NIST SSDF, SLSA provenance, Google SRE 포스트모템 문화를 근거로 작성자와 분리된 검증·승인·복구의 역할 설계를 정리했다.
백재민
에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다
Mylyn 이 2000년대에 풀려던 문제와 지금 에이전트 컨텍스트 문제는 같습니다. 달라진 건 그 컨텍스트를 읽는 쪽에 사람만 있는 게 아니라는 점입니다.
김영상
에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가
코드 작성 비용이 무너진 뒤 개발자의 시간은 판단과 승인으로 옮겨갔습니다. 그 일들이 왜 에디터 밖에 있으면 안 되는지, VS Code 확장을 만들며 내린 선택들.
이승백