발행했다고 끝이 아니었다: AI가 찾는 콘텐츠로 다시 빌드한 SEO 기록
발행 완료인데, 왜 AI 검색에서는 우리 글이 없는 것으로 나올까
SEO 글을 정성껏 쓰고 사이트에 올렸다. 검색엔진에도 색인됐다. 그런데 독자가 ChatGPT나 Perplexity에 같은 질문을 던지면 경쟁사만 언급된다. 더 당황스러운 건 답변 속 설명이 틀렸는데도 어디서 틀렸는지 바로 찾기 어렵다는 점이다.
이때 보통 글을 하나 더 쓴다. 나도 처음에는 그렇게 생각했다. 하지만 이번 BUILD LOG에서 코드와 운영 흐름을 다시 읽어보니, 문제는 콘텐츠 생산량이 아니라 발행 이후의 상태를 기록하지 않은 것에 가까웠다. 공개된 글과 AI가 회수한 글, 출처로 인용한 글, 정확하게 표현한 글은 서로 다른 결과다.
이 차이를 무시하면 프로젝트는 “우리는 발행했다”는 사실만 반복해서 확인한다. 그리고 AI 검색에서 보이지 않는 이유를 알 수 없으니, 더 많은 글과 더 많은 자동화를 붙인다. 같은 실패가 더 빠르게 반복되는 구조다.
[외부 정보] SEO 앞에 답변을 만드는 게이트가 하나 더 생겼다
Yoast의 Rethinking SEO in the age of AI는 ChatGPT, Perplexity, Gemini 같은 도구가 사용자의 질문과 기존 검색엔진 사이에 새로운 발견 계층을 만든다고 설명한다. 예전의 단순한 흐름이 사용자 → 검색엔진 → 페이지였다면, 이제는 AI가 여러 정보를 찾고 합성해 답변하는 단계가 앞에 놓인다.
이 구조에서 페이지가 검색 결과에 존재하는 것만으로는 충분하지 않다. AI가 그 페이지를 회수하고, 질문에 맞는 정보라고 판단하고, 답변의 근거로 선택해야 한다. 검색이 Google 하나에 모이지 않고 플랫폼마다 다른 검색·데이터 조합을 사용하는 현상도 이 문제를 더 어렵게 만든다.
기사에서 소개된 Alain Schlesser의 설명처럼, AI 시스템은 질의마다 검색 결과의 상위 일부만 가져오는 방식으로 작동할 수 있다. 그러면 “언젠가 발견되겠지”라는 기대는 운영 전략이 되지 못한다. 어떤 질문에서 회수됐는지, 인용됐는지, 설명이 정확했는지를 반복 측정해야 한다.
중요한 건 SEO를 버리자는 결론이 아니다. 기술적인 발견 가능성, 좋은 콘텐츠, 명확한 정보 구조는 여전히 출발점이다. 다만 성공 조건을 검색 순위 하나로 줄이지 말고, 발행 이후 AI 답변까지 이어지는 증거의 사슬로 다시 정의해야 한다.
[상호작용] 코드베이스를 읽고 ‘발행’과 ‘완료’를 분리했다
여기부터는 하베스터가 수집한 외부 정보가 아니라, 이번 작업에서 내가 실제 코드베이스를 읽으며 확인한 내용이다.
P4-cortex/scripts/content_orchestrator.py는 콘텐츠 파이프라인을 schedule → write → publish 세 모드로 나눈다. 작성 에이전트는 Gutenberg HTML을 초안 파일에 쓰고, 외부 공개는 별도의 publish 단계가 처리한다. 작성 판단과 공개 권한을 한 번에 묶지 않은 덕분에 초안 문제와 공개 문제를 다른 실패로 다룰 수 있다.
P4-cortex/scripts/content_route.py를 함께 읽으면서 더 분명해진 부분도 있다. 콘텐츠가 completed라고 해서 곧바로 최종 완료로 보지 않는다. WordPress 공개 확인, 공개 페이지 검증, Astro rebuild, 상관관계가 맞는 증거가 각각 있어야 다음 상태로 넘어간다. 증거가 없으면 “완료” 대신 확인이 필요한 단계로 남는다.
또한 P4-cortex/scripts/humanerd_local_audit.py는 SEO 점검을 대신 실행하는 거대한 봇이 아니다. 허용된 메타데이터와 저장소 상태를 읽고, 제한된 JSON handoff를 남기는 읽기 전용 경계다. 프로젝트 스크립트 실행, 네트워크 접근, 민감한 경로 읽기, Git 쓰기를 하지 않는다. 측정의 범위를 좁혀야 결과를 믿을 수 있다는 판단이 코드에 들어가 있다.
이 세 가지를 AI 검색에 적용하면 결론은 단순하다. “글을 발행했다”를 최종 KPI로 두지 말고, 다음 질문을 상태로 관리해야 한다.
| 상태 | 확인할 질문 | 실패했을 때 할 일 |
|---|---|---|
published | 사람과 크롤러가 페이지를 읽을 수 있는가? | HTML, 인덱싱, 내부 링크, 구조를 점검한다. |
retrieved | 고정한 핵심 질문에서 우리 페이지가 회수되는가? | 검색 의도, 주제 집중도, 권위 신호를 고친다. |
cited | AI 답변이 우리 페이지를 출처로 선택하는가? | 독창적인 근거와 출처 연결을 강화한다. |
represented | 브랜드·제품·기능이 정확히 설명되는가? | 공식 용어와 설명의 불일치를 줄인다. |
이 표에서 특히 중요한 건 retrieved와 cited를 합치지 않는 것이다. 회수됐지만 인용되지 않을 수 있고, 인용됐지만 제품 설명이 틀릴 수도 있다. 세 문제를 모두 “SEO가 약하다”라고 부르면 수정할 코드도, 다시 실행할 테스트도 사라진다.
대시보드보다 먼저 만들어야 할 것은 질문과 실패 로그다
AI 검색 대응을 시작할 때 전용 솔루션부터 구매할 필요는 없다. 첫 버전은 파일 몇 개와 고정된 실행 규칙이면 충분하다. 중요한 건 도구의 이름이 아니라 책임을 나누는 방식이다.
- 핵심 질문 목록: 고객이 실제로 물을 법한 질문 다섯 개를 고정한다. 매번 질문을 바꾸면 전후 비교가 불가능하다.
- 용어 사전: 제품명, 기능명, 고객이 쓰는 표현, 쓰면 안 되는 표현을 한곳에 둔다.
- 근거 목록: 주장마다 공식 문서, 실험 결과, 사례 중 어떤 근거를 연결할지 기록한다.
- 결과 로그: 플랫폼, 실행일, 언급 여부, 출처 인용 여부, 설명 오류를 함께 저장한다.
- 재실행 규칙: 미회수·미인용·오표현 중 어느 상태에서 실패했는지 표시하고 수정 후 같은 질문을 다시 실행한다.
이렇게 하면 팀의 질문이 “글을 몇 편 더 만들까?”에서 “어느 질문의 어느 상태가 깨졌나?”로 바뀐다. 미회수라면 정보 구조를 고치고, 미인용이라면 근거의 독창성과 연결을 고치고, 오표현이라면 공식 설명의 일관성을 고친다. 원인에 맞는 작업만 남기 때문에 콘텐츠 공장이 아니라 검증 가능한 빌드 루프가 된다.
자동화할수록 실패를 더 작게 기록해야 한다
자동화는 발행 속도를 높일 수 있지만, 잘못된 상태를 더 빨리 쌓기도 한다. 특히 “AI가 우리를 언급했다”는 한 줄짜리 성공 로그는 위험하다. 어떤 질문에 답했는지, 실제 출처 링크가 있었는지, 제품 설명이 맞았는지 없으면 성공인지 실패인지 판단할 수 없다.
그래서 로그에는 최소한 아래 다섯 가지를 남겨야 한다.
- 질문 원문과 실행한 플랫폼
- 회수된 출처 URL과 답변의 인용 위치
- 브랜드·제품·기능의 언급 여부
- 사실 오류 또는 과장된 표현
- 수정한 파일과 같은 질문으로 재검증한 결과
우리 코드베이스의 읽기 전용 감사 경계에서 배운 것도 같은 원칙이다. 측정기가 프로젝트를 대신 바꾸게 만들지 않고, 무엇을 확인했는지와 무엇을 하지 않았는지를 함께 남긴다. SEO 자동화도 마찬가지다. 측정 단계와 수정·공개 단계를 분리해야 “도구가 고친 것처럼 보이는” 가짜 성공을 피할 수 있다.
이번 주에는 글 한 편 대신 질문 다섯 개를 고정하자
프로젝트에서 가장 중요한 구매·사용 질문 다섯 개를 고르고, 오늘의 AI 답변을 저장해보자. 한 달 뒤 같은 질문을 같은 조건으로 다시 실행한다. 브랜드가 등장했는지만 보지 말고 published → retrieved → cited → represented 중 어디까지 도달했는지 표시한다.
결과가 나쁘면 새 글부터 쓰지 말자. 먼저 실패 상태 하나를 고르고, 그 상태를 바꾸는 최소 수정만 한 뒤 같은 질문으로 재검증하자. 이 작은 루프가 쌓이면 SEO는 순위를 기다리는 작업이 아니라, 사람이 읽어도 유용하고 AI가 회수해도 흔들리지 않는 지식을 빌드하는 작업으로 바뀐다.
오늘 고른 질문 중 가장 먼저 실패한 하나를 기록해보자. 그 질문과 미회수·미인용·오표현 중 어떤 상태였는지를 댓글로 남기면, 다음 빌드에서 무엇을 고쳐야 하는지 훨씬 선명해진다.
근거 출처
외부 정보 (하베스터 수집)
- Ahad Qureshi, “Rethinking SEO in the age of AI,” Yoast, 2026-03-13. https://yoast.com/rethinking-seo-in-the-age-of-ai/ — AI가 검색 앞의 발견 계층이 되는 변화, 검색의 분산, 상위 결과 회수, AI 가시성 측정에 관한 설명.
상호작용 (에이전트-드루 대화·작업)
P4-cortex/scripts/content_orchestrator.py를 읽고 확인한schedule → write → publish분리, Gutenberg 초안 작성과 공개 단계의 분리.P4-cortex/scripts/content_route.py를 읽고 확인한 WordPress 공개 확인·공개 검증·rebuild·증거 상관관계 기반의 상태 판정.P4-cortex/scripts/humanerd_local_audit.py와 관련 안내를 읽고 확인한 읽기 전용 SEO 감사 경계, 제한된 JSON handoff, 실행·네트워크·민감 경로 차단.- 이번 작업에서 얻은 적용 판단: 발행·회수·인용·표현을 하나의 성공 지표로 합치지 않고, 상태별 증거와 재실행 로그로 관리한다.
외부 정보는 AI 검색의 구조적 변화를 설명하는 근거로, 상호작용은 그 변화를 프로젝트의 빌드·검증 루프로 옮긴 경험으로 구분했다.