Google이 공개한 생성형 AI 검색 최적화 가이드 ↗를 읽고, 관련 내용을 GeekNews 요약 ↗으로도 훑어봤습니다. 결론은 꽤 단순했습니다. AI 검색 시대라고 해서 완전히 새로운 꼼수가 필요한 것은 아니고, 여전히 기본 SEO와 사람이 읽을 만한 고유한 경험이 중요하다는 것입니다.
이 글은 작성 시점 2026-05-18 · Google Search의 생성형 AI 최적화 가이드와 GeekNews 요약 스냅숏 기준으로 정리했습니다. 그리고 단순 요약에서 멈추지 않고, 실제로 블로그에 적용한 수정까지 함께 남깁니다.
원문에서 읽은 핵심
Google 문서의 첫 번째 메시지는 명확합니다. 생성형 AI 기능도 Google Search의 기존 랭킹·품질 시스템과 검색 인덱스 위에서 동작하므로, 기존 SEO 베스트 프랙티스 ↗는 여전히 유효합니다.
문서에서 특히 중요하게 본 부분은 세 가지였습니다.
-
RAG와 Query fan-out
Google의 생성형 AI 응답은 검색 인덱스에서 관련 문서를 가져오고, 원래 질문에서 파생된 여러 관련 질의를 함께 탐색합니다. 한 문서가 하나의 정확한 키워드에만 맞춰져 있을 필요는 줄었지만, 페이지의 주제와 맥락은 더 명확해야 합니다. -
Non-commodity content
누구나 쓸 수 있는 일반론보다, 직접 해본 경험과 고유한 관점이 더 중요합니다. Google은 단순 요약보다 first-hand review나 경험 기반 설명을 더 좋은 예로 듭니다. -
명확한 기술 구조
크롤링 가능성, 페이지 경험, 시맨틱 HTML, JavaScript SEO 같은 기본기는 계속 중요합니다. 특히 Google은 시맨틱 HTML이 검색엔진뿐 아니라 스크린리더 같은 사용자 환경에도 도움이 된다고 설명합니다.
하지 않아도 된다고 판단한 것
이번 글에서 오히려 중요한 부분은 “하지 않아도 되는 것”이었습니다.
Google은 생성형 AI 검색을 위해 별도의 llms.txt나 특수 마크업을 만들 필요가 없다고 설명합니다. 또 AI가 이해하기 좋게 만든다는 이유로 콘텐츠를 인위적으로 잘게 쪼개거나, 검색 질의 변형마다 비슷한 페이지를 대량으로 만드는 접근도 권하지 않습니다.
그래서 블로그에서는 다음 작업을 하지 않기로 했습니다.
- AI 검색 전용 파일을 새로 만들지 않기
- 본문을 기계적으로 청킹하지 않기
- 롱테일 키워드를 반복해서 넣지 않기
- 기존 글을 AI 답변체로 다시 쓰지 않기
대신 실제로 고친 것은 더 기본적인 부분이었습니다.
블로그에 적용한 수정
수정 범위는 작지만, 사이트의 의미 구조를 더 분명하게 만드는 쪽에 집중했습니다.
flowchart LR
A[Google 생성형 AI 검색 가이드] --> B{블로그 점검}
B --> C[홈<br/>h1 추가]
B --> D[메타데이터<br/>JSON-LD 보강]
B --> E[접근성<br/>heading anchor 개선]
C --> F[사람과 검색엔진이<br/>사이트 주제를 더 명확히 이해]
D --> G[페이지·글의 의미를<br/>구조화 데이터로 표현]
E --> H[스크린리더에서도<br/>섹션 링크 목적을 설명]1. 홈에 h1 추가
기존 홈 화면에는 시각적인 소개 문구는 있었지만 h1이 없었습니다. 블로그의 정체성을 검색엔진과 보조기술이 더 명확히 파악할 수 있도록 홈 hero 영역에 다음 제목을 추가했습니다.
블로그 — 프론트엔드와 AI 툴링 실험 기록이건 단순히 SEO용 문구가 아니라, 블로그가 어떤 기록을 쌓는 공간인지 사람에게도 바로 드러내는 역할을 합니다.
2. 홈 JSON-LD 추가
기존에는 글 상세 페이지에만 BlogPosting 구조화 데이터가 있었습니다. 이번에는 홈 페이지에도 WebSite와 Blog JSON-LD를 추가했습니다.
특히 사이트 내부 검색 페이지가 있으므로 SearchAction도 함께 연결했습니다.
// src/layouts/Layout.astro
const siteSearchURL = new URL("search/", siteURL);
siteSearchURL.searchParams.set("q", "{search_term_string}");이 변경은 “AI 전용 마크업”을 만든 것이 아니라, 기존 웹 표준에 가까운 구조화 데이터를 더 정확히 채운 것입니다.
3. 글 상세 BlogPosting 보강
글 상세 페이지의 BlogPosting에는 이미 제목, 이미지, 발행일, 작성자가 들어가 있었습니다. 이번에는 아래 필드를 추가했습니다.
descriptionmainEntityOfPageurldateModifiedkeywordspublisher
이렇게 하면 글 하나가 어떤 페이지의 본문인지, 어떤 키워드와 연결되는지, 누가 발행했는지를 더 명확히 표현할 수 있습니다. Google의 구조화 데이터 가이드 ↗는 구조화 데이터가 페이지 의미를 더 잘 이해하게 돕는다고 설명합니다.
4. heading anchor 접근성 개선
글 상세 페이지에서는 각 제목 옆에 # anchor 링크를 붙이고 있었습니다. 시각적으로는 자연스럽지만, 스크린리더 사용자에게는 링크 목적이 모호할 수 있습니다.
그래서 제목 텍스트를 기반으로 aria-label을 추가했습니다.
// src/layouts/PostDetails.astro
const headingText = heading.textContent?.trim() || "현재 섹션";
link.ariaLabel = `이 섹션 링크: ${headingText}`;Google 문서가 말한 시맨틱 HTML과 접근성의 접점이 바로 이런 부분이라고 봤습니다. 검색엔진을 위한 구조와 사용자 보조기술을 위한 구조가 완전히 별개의 일이 아닙니다.
콘텐츠 쪽에서 앞으로 바꿀 점
이번 수정은 기술 구조 개선에 가까웠습니다. 하지만 Google 문서를 기준으로 보면 더 중요한 건 글의 내용입니다.
블로그에는 Claude Code, Codex, 접근성, 프론트엔드 도구 관련 글이 많습니다. 이런 주제는 이미 공개 자료가 많기 때문에 단순 기능 요약만으로는 쉽게 commodity content가 됩니다. 앞으로는 글마다 아래 요소를 더 의식적으로 넣는 편이 좋아 보입니다.
- 직접 써본 뒤 좋았던 점
- 실제로 막힌 부분
- 내 워크플로우에 적용한 방식
- 추천하는 상황과 추천하지 않는 상황
- 기존 글과 이어지는 맥락
예를 들어 Claude Code 관련 글은 Agent View 글, Remote Control 글, Agent Teams 글처럼 서로 연결되는 주제가 많습니다. 앞으로는 새 기능 소개에서 끝내지 않고, “내가 이 도구를 어떻게 운영하는가”를 더 분명히 남기는 쪽이 AI 검색 시대에도 더 강한 콘텐츠가 될 것 같습니다.
마무리
이번 점검의 결론은 단순합니다.
AI 검색 시대라고 해서 블로그 운영 방식이 완전히 바뀌지는 않습니다. 오히려 기본기가 더 중요해집니다. 크롤링 가능한 페이지, 명확한 제목 구조, 구조화 데이터, 접근성, 그리고 직접 경험에서 나온 관점이 합쳐질 때 검색엔진과 사람 모두에게 읽히기 좋은 글이 됩니다.
이번에는 홈 h1, JSON-LD, heading anchor 접근성처럼 바로 고칠 수 있는 부분부터 적용했습니다. 다음 단계는 각 포스트에 더 많은 실제 사용 경험과 판단을 넣는 것입니다. 검색을 위한 글이 아니라, 사람이 읽고 “이건 직접 해본 사람이 쓴 글이네”라고 느낄 수 있는 글을 늘리는 쪽이 맞다고 봅니다.