
TRM은 90일 만에 ChatGPT 추천 트래픽을 8,337% 성장시켰습니다. 저는 그들의 4가지 LLMO 기둥을 3개의 인디 사이트에 적용해
요약
SEO 에이전시 TRM의 LLMO(Large Language Model Optimization) 전략을 3개의 인디 사이트에 직접 적용한 실험 결과입니다. ChatGPT 추천 트래픽을 높이기 위한 4가지 기둥 중 실제 효과가 있었던 핵심 요소를 분석합니다.
핵심 포인트
- AI 검색 유입 사용자의 평균 체류 시간은 5분 41초로 매우 높음
- TRM의 4가지 LLMO 기둥 중 실제 성과를 낸 것은 'Pillar 3: Author Schema'임
- 단순 트래픽 수치보다 AI 검색 엔진의 참조를 유도하는 구조적 최적화가 중요함
- 개인 개발자 수준에서도 스키마 적용을 통해 AI 추천 효과를 얻을 수 있음
The Rank Masters라는 미국의 SEO 에이전시가 ChatGPT 추천 트래픽이 8,337% 상승했음을 보여주는 90일간의 케이스 스터디(case study)를 발표했을 때, 그 헤드라인은 헤드라인이 마땅히 해야 할 역할을 정확히 수행했습니다. 저는 클릭했습니다. 그러다 기준점이 8회 방문이었고, 해당 기간 이후가 675회라는 점을 발견했습니다. 따라서 네, 그 퍼센티지는 기술적으로는 사실입니다. 고객이 1명에서 12명으로 늘어나면 비즈니스가 1,100% 성장했다고 말하는 것도 사실인 것과 같습니다.
제가 실제로 관심을 가졌던 것은 표의 나머지 부분이었습니다. AI 검색 트래픽의 평균 참여 시간(Average engagement time)은 사용자당 5분 41초였습니다. 사용자당 페이지 뷰(Page views)는 48회까지 올라갔습니다. 이 수치들은 퍼센티지 트릭이 아닙니다. 이는 이미 관심이 있는 상태로 유입되어 머무른 사람들이라는 뜻입니다. 바로 이 부분이 복제할 가치가 있는 부분입니다.
TRM은 그들의 플레이북(playbook)을 네 가지 기둥(pillars)으로 설명했습니다. 저는 에이전시 규모의 콘텐츠 팀을 등에 업지 않은 개인에게 어떤 것이 실제로 성과를 내는지 확인하기 위해, 90일 동안 이 네 가지를 모두 저의 인디 사이트 3곳에 적용해 보았습니다. 네 가지 중 세 가지는 소음(noise)에 불과했습니다. 효과가 있었던 단 하나는 제가 거의 건너뛸 뻔했던 것이었습니다.
[

설정 (The setup)
세 개의 인디 사이트:
- kenimoto.dev — 저의 엔지니어링 블로그로, 테스트 시작 시점에 약 50개의 기사가 있었으며, 4개 언어 스택(EN/JA/PT/ES)을 사용합니다. 대부분의 페이지에 이미
llms.txt와 JSON-LD가 적용되어 있었습니다. - Site B — 취미 프로젝트를 위해 만든 12페이지 규모의 니치 툴(niche tools) 사이트로, 스키마(schema)가 거의 없고 저자 소개(author bio)도 없습니다.
- Site C — 롱테일 키워드(long-tail keyword)로 순위가 매겨진 원페이지 인디 SaaS 랜딩 페이지로, 블로그도 없고 스키마도 없습니다.
저는 의도적으로 매우 다른 세 단계의 사이트들을 선택했습니다. 만약 어떤 "기둥(pillar)"이 이미 80% 정도 준비된 사이트에서만 작동한다면, 그것은 진정한 기둥이 아닙니다. 그것은 그저 마무리 작업(finishing touch)일 뿐입니다.
기준 기간(Baseline period)은 테스트 전 30일이었습니다. 처치 기간(Treatment period)은 그 이후의 90일이었습니다. 저는 llmoframework.com의 기둥 가이드에 나온 chatgpt.com 및 perplexity.ai 참조자 정규 표현식(referrer regex)을 적용한 GA4와, 교차 채널(cross-channel) 유입을 확인하기 위한 서버 로그 내 4개의 AI 크롤러 사용자 에이전트(user-agent) 필터를 사용했습니다. 플레이북을 반대로 실행하는 네 번째 대조군 사이트(control site)를 운영하지는 못했는데, 이는 명백한 공백입니다. 다른 누군가가 하기 전에 제가 먼저 이를 언급하고자 합니다.
TRM이 설명한 4가지 기둥
원본 사례 연구를 읽지 않은 분들을 위해, TRM이 실행한 내용을 요약하면 다음과 같습니다:
- 시맨틱 SEO (Semantic SEO) 시스템 — 콘텐츠를 키워드가 아닌 엔티티(entities)와 검색 의도(search intent)에 매핑합니다. 관련 엔티티 범위를 통해 주제적 권위(topical authority)를 구축합니다.
- 모듈형 콘텐츠 아키텍처 (Modular content architecture) — 문제(Problem) → 프레임워크(Framework) → 단계(Steps) → 증거(Proof) → CTA 블록 순으로 구성합니다. 각 블록은 독립적으로 존재하여 LLM이 이를 인용할 수 있게 합니다.
- GEO(Generative Engine Optimization) 강화 — 모든 페이지에 Article / FAQ / HowTo / Organization JSON-LD를 적용하고, 저자 및 E-E-A-T 신호를 추가합니다.
- 쿼리 팬아웃 클러스터 (Query fan-out cluster) — 각 핵심 개념을 중심으로 30개의 롱테일(long-tail) 페이지를 구축하여, AI의 하위 쿼리(subqueries)가 항상 당신이 작성한 콘텐츠에 도달하도록 합니다.
TRM의 경우, 12주 동안 42개 페이지에 시스템으로서 이 4가지 기둥을 적용하여 8,337%라는 수치를 만들어냈습니다. 저에게는 12주의 시간도, 42개 페이지를 운영할 역량도 없었습니다. 제가 가진 것은 3개의 사이트와 저녁 시간이라는 한정된 예산뿐이었습니다. 그래서 저는 가능한 곳에 각 기둥을 개별적으로 적용해 보았고
90일 후, kenimoto.dev로 유입되는 ChatGPT 추천(referrals) 트래픽은 월 18회에서 23회로 증가했습니다. 사이트 B는 0에서 2로 이동했습니다. 사이트 C는 변화가 없었습니다. 0은 아니지만, 이것 또한 하나의 기둥(pillar)이라고 보기는 어렵습니다.
제 분석은 이렇습니다: 시맨틱 SEO (semantic SEO)는 실재하지만, 그 보상 창구(payoff window)는 90일보다 길며, 당신이 수행하는 다른 모든 작업과 복리로 결합됩니다. 이를 단독 레버(standalone lever)로 사용하는 소규모 사이트의 경우, 그 신호는 노이즈(noise) 속으로 사라져 버립니다. TRM은 아마도 42개의 새로운 페이지와 쿼리 팬아웃 클러스터 (query fan-out cluster)를 동시에 실행했기 때문에 그 이점을 얻었을 것입니다.
이 기둥은 괜찮습니다. 다만 분기 내에 50개의 기사가 있는 블로그를 움직이게 할 만한 요소는 아닐 뿐입니다.
기둥 2: 모듈형 콘텐츠 (Modular content). 작성자에게는 최고지만, 테스트에는 최악입니다.
문제(Problem) → 프레임워크(Framework) → 단계(Steps) → 증거(Proof) → 행동 유도(CTA) 구조는 훌륭한 편집 제약 조건입니다. 저는 kenimoto.dev의 기존 포스트 8개를 이 구조에 맞게 다시 작성했습니다. 글이 더 잘 읽힙니다. 훑어보기가 더 쉽습니다. 개인적으로는 결과물에 더 만족합니다.
하지만 트래픽 데이터는 이를 알아차리지 못했습니다. 재작성된 8개 포스트로 유입되는 ChatGPT 추천 트래픽은 평소의 주간 변동 범위 내에 있었습니다. 새로운 TL;DR 블록이 제 AI 인용 트래커(AI citation tracker) 결과에 두 번 나타나긴 했지만, 이는 0보다는 크지만 8개라는 표본 크기를 고려할 때 노이즈 범위 안에 충분히 들어옵니다.
두 가지 현상이 일어나고 있다고 생각합니다:
- TRM의 모듈형 블록은 이전에 AI 노출이 없었던 완전히 새로운 페이지에서 작동했습니다. 이미 크롤링되었고 이미 인용되었을 수도 있는 인디 블로그 포스트를 다시 쓰는 것은 그러한 인식을 초기화하지 못합니다.
- "단독으로 인용 가능한 문단 (Standalone-quotable paragraph)"은 대부분의 괜찮은 기술 문서(technical writing)가 이미 충족하고 있는 품질 기준입니다. 이미 인간이 작성한 인디 블로그에서 이를 공식화함으로써 얻는 한계 이익(marginal gain)은 작습니다.
저는 이 구조를 유지할 것입니다. 다만 이것이 TRM의 수치를 움직인 핵심 요소라고는 생각하지 않습니다.
기둥 3: 저자 스키마 (Author schema) 및 E-E-A-T. 유일하게 효과가 있었던 것.
이 부분은 제가 거의 건너뛸 뻔한 대목입니다. JSON-LD는 어차피 합격했을 직장에 제출하는 훌륭한 자기소개서를 쓰는 것과 마찬가지인, LLMO (Large Language Model Optimization) 관점에서의 무의미한 작업이라는 평판이 있습니다. 저는 단 하나의 Person 스키마 없이도 순위가 잘 나오는 사이트를 구축해 본 적이 있고, 완벽한 스키마를 갖추었음에도 아무도 인용하지 않는 사이트를 구축해 본 적도 있습니다.
세 가지가 바뀌었습니다:
- kenimoto.dev의 모든 저자 바이라인(byline)에
Person스키마를 추가했으며,sameAs를 통해 GitHub, X, LinkedIn, 그리고 인증된 Zenn 프로필을 연결했습니다. - 자격 증명과
WorkExample링크를 포함한 출간 도서 및 기사 목록을 포함하여,Person+ProfilePage스키마가 적용된 실제/about페이지를 작성했습니다. - 모든 포스트의 기존
Article스키마에author및publisher필드를 추가했습니다.
총 소요 시간: 약 6시간. 콘텐츠는 추가되지 않았고, 포스트를 다시 작성하지도 않았습니다.
kenimoto.dev에서의 90일간의 결과:
- ChatGPT 추천 트래픽: 월 18회 → 월 127회
- Perplexity 추천 트래픽: 월 4회 → 월 41회
- 5개의 AI 인용 트래커(citation tracker) 측정 결과: 중앙값 기준 3.7배 상승, 그중 2개의 트래커에서 제 저자 이름이 "LLMO indie" 및 "AI search optimization individual practitioner" 쿼리에 대한 추천 소스로 표시되었습니다.
사이트 B는 (훨씬 더 작은 노출 범위에서) 동일한 효과의 축소 버전을 얻었습니다 (ChatGPT 추천 트래픽 월 0회 → 8회). 실제 저자가 없고 작성할 만한 /about 페이지도 없었던 사이트 C는 변화가 없었습니다.
여기서 주의를 기울이고 싶습니다. n=3은 통계적 연구가 아닙니다. 또한, 이 상승 수치는 제가 같은 기간 동안 llmoframework.com에 게스트 기사를 게재했다는 사실과 혼재되어 있습니다. 이로 인해 sameAs 그래프가 더 빠르게 연결되었을 가능성이 있습니다. 하지만 kenimoto.dev에서의 스파이크(spike) 타이밍은 제가 수행한 다른 어떤 변화보다 스키마 배포 날짜를 더 명확하게 추적하고 있습니다.
제가 추측하는 현재 가장 유력한 이유는 다음과 같습니다. 거대 언어 모델 (LLM)들은 **이름이 명시되고 검증 가능한 인물 (named, verifiable people)**에게 인용 (citation)을 연결하려고 매우 노력하고 있습니다. 모델 제공업체들이 환각 (hallucination)된 인용 사례로 인해 피해를 입은 후 눈에 띄게 규제를 강화했기 때문에, 익명의 SEO 콘텐츠처럼 보이는 페이지를 인용하는 것에 대해 조심스러워하고 있습니다. 검증 가능한 외부 프로필로 연결되는 깨끗한 Person 스키마 (schema) 뭉치는 이름이 있고 검증 가능한 인물처럼 보일 수 있는 가장 저렴한 방법입니다.
이것은 제가 작성한 "성과를 만들어낼 항목" 목록에 없던 것이었습니다. 저는 Pillar 4 (기둥 4)에 베팅했었습니다.
Pillar 4: 쿼리 팬아웃 클러스터 (Query fan-out cluster). 11페이지에서 역량 소진.
TRM의 플레이북 (playbook)은 핵심 개념당 30개의 롱테일 (long-tail) 페이지를 요구합니다. 저는 kenimoto.dev에서 "Claude Code subagents"를 핵심 개념으로 선정하고 클러스터 (cluster)를 계획했습니다. 90일 동안 30개 페이지 중 11개를 발행했습니다. 나머지 19개는 스프레드시트 상에서 저를 조롱하듯 남아 있었습니다.
이 11개의 페이지는 어느 정도 AI 인용 (AI citation)을 끌어냈습니다. 그중 5개는 관련 서브 쿼리 (sub-query)에 대한 최소 하나 이상의 AI 검색 결과에 나타났습니다. 하지만 그 규모가 너무 작아서, 각 페이지당 방문 수가 몇 건 미만이었기에 위에서 언급한 리퍼러 (referrer) 데이터에는 나타나지 않았습니다.
저는 이 Pillar (기둥)가 효과가 있다고 생각합니다. 다만, 90일이라는 기간 내에 1인 인디 운영자에게는 효과적이지 않다고 생각합니다. TRM이 발표한 수치는 "12주 동안 42개 페이지"였는데, 이는 TRM에 에이전시 (agency)가 있었기 때문입니다. 저는 일주일에 딱 두 번의 저녁 시간만 있었습니다. 확산 (fan out)을 위해 30개의 페이지가 필요한 클러스터 전략은 본질적으로 채용 전략을 위장한 것에 불과합니다.
팀이 있다면 Pillar 4를 먼저 실행하십시오. 팀이 없다면 Pillar 3를 실행하고, 채용 예산이 생겼을 때 Pillar 4를 다시 검토하십시오.
히트맵 (heatmap)이 실제로 말해주는 것
세 개의 인디 사이트 전체에서 AI 리퍼럴 (AI-referral) 상승 폭을 기준으로 네 가지 Pillar를 순위 매겨보면 다음과 같습니다.
| Pillar | kenimoto.dev | Site B | Site C |
|---|---|---|---|
| 1. 시맨틱 SEO (Semantic SEO) | + (약함) | + (약함) | 정체 |
| ... |
"Pillar 3만 적용"한 결과는 긍정적인 의미에서 의심스럽습니다. 이는 구현 비용이 가장 저렴한 Pillar이며, 너무 당연하게 느껴져서 대부분의 사람들이 건너뛰는 항목이자, "쉬워 보였던 것"과 "실제로 데이터를 움직인 것" 사이의 격차가 가장 큰 항목입니다.
만약 제가 2026년에 이 플레이북(Playbook)을 실행하려는 다른 인디 개발자(Indie dev)에게 조언을 한다면 다음과 같습니다:
- 기둥 3(Pillar 3)을 가장 먼저 수행하세요. 제가 측정한 바로는 6시간 동안의 JSON-LD 작업이 시간당 가장 높은 수익률을 보였습니다.
- 기둥 2(Pillar 2)를 캠페인이 아닌 글쓰기 습관으로 운영하세요. 이는 품질을 높이는 전략적 움직임입니다. 이것만으로 리퍼러(Referrer) 데이터에 결과가 나타나기를 기대하지 마세요.
- 콘텐츠 팀을 갖추기 전까지 기둥 4(Pillar 4)는 미루세요. 팬아웃(Fan-out) 수학은 당신이 아마도 보유하지 못했을 처리량(Throughput)을 전제로 합니다.
- 기둥 1(Pillar 1)은 백그라운드에서 실행하세요. 이는 천천히 복리로 쌓입니다. 중단하지는 마되, 이를 위해 대시보드를 계속 주시하지는 마세요.
8,337%라는 수치는 TRM의 스프레드시트에서 실재하는 수치입니다. 하지만 그것은 또한 675회의 페이지 뷰로 귀결된, 여러 기둥과 여러 페이지, 그리고 에이전시 규모의 노력이 투입된 결과입니다. 세 개의 인디 사이트의 경우, 레버리지(Leverage)는 기둥 3에 있으며, 기둥 3만으로도 저의 월간 AI 리퍼럴(AI referrals)을 22회에서 176회로 늘릴 수 있었습니다. 이는 제가 실제로 체감할 수 있는 700%의 트래픽 상승입니다.
그리고 저에게도 6시간이 걸렸습니다.
구현 세부 사항을 원하신다면, llmoframework.com pillars guide에 제가 사용한 JSON-LD 템플릿이 있습니다. 어떤 스키마(Schema)가 실제로 LLM 크롤러(LLM crawlers)에 의해 파싱되는지(그리고 어떤 것이 장식용인지)에 대한 더 자세한 글은 LLMO: AI Search Optimization에서 확인하실 수 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기