AI Overviews에 내 개발 글이 인용되려면: 구글 공식 가이드를 개발 블로거 입장에서 다시 읽었습니다

다시 읽게 된 계기

개발 블로그를 운영하다 보면 어느 순간부터 검색 유입의 결이 달라졌다는 걸 체감하게 됩니다. 검색 결과 상단에 AI가 정리해 준 요약이 먼저 뜨고, 그 안에 출처 링크가 몇 개만 노출되는 화면이 이제는 예외가 아니라 기본에 가깝습니다. 안드로이드 관련 글을 검색해 봐도 마찬가지였습니다.

그래서 구글이 발행한 생성형 AI 검색 최적화 공식 가이드를 다시 펼쳤습니다. 이 문서는 처음 나왔을 때 한 번 훑어봤지만, 이번에는 질문을 좁혀서 읽었습니다. "이 가이드가 마케터가 아니라 개발 블로그를 쓰는 나에게는 정확히 무엇을 요구하는가."

이 글은 그 재독 후기입니다. 문서를 그대로 요약하는 대신, 개발 블로거 입장에서 실제로 바꿀 것과 무시해도 되는 것을 골라 정리했습니다.

이 가이드가 지금 중요한 이유

먼저 문서의 위치부터 짚겠습니다. 이 가이드는 구글 서치 센트럴의 새 "생성형 AI 기초(Generative AI fundamentals)" 섹션에 정식으로 올라간 공식 문서입니다. 2026년 5월 15일에 처음 공개됐고, 문서 하단 기준 2026년 7월 10일에 갱신됐습니다. 블로그 글이나 컨퍼런스 발언이 아니라, SEO 스타터 가이드와 같은 층위에 놓인 정식 레퍼런스라는 점이 중요합니다. 구글이 이 주제를 임시 대응이 아니라 기본 문서로 취급하기 시작했다는 신호이기 때문입니다.

가이드의 메시지를 한 문장으로 압축하면 이렇습니다. AEO(answer engine optimization)나 GEO(generative engine optimization)는 별도의 분야가 아니라 결국 SEO다. 구글 입장에서 생성형 AI 검색을 최적화하는 일은 검색 경험 자체를 최적화하는 일이고, 그래서 여전히 SEO라는 것입니다.

이 주장의 근거는 기술 구조에 있습니다. 가이드는 생성형 AI 기능이 별도의 인덱스가 아니라 기존 코어 검색 랭킹 시스템 위에서 동작한다고 설명합니다. 그 위에서 두 가지 기법이 핵심으로 등장합니다.

첫째는 RAG(검색 증강 생성)입니다. 가이드는 이를 "그라운딩"이라고도 부르는데, 모델이 기억에만 의존해 답하지 않고 검색 인덱스에서 관련성 높은 최신 페이지를 끌어와 그 내용을 근거로 답변을 생성하는 방식입니다. 그래서 답변에는 근거가 된 페이지로 이동하는 클릭 가능한 링크가 함께 붙습니다. 개발자 관점으로 바꿔 말하면, 답변 생성 전에 인덱스에서 문서를 조회(retrieval)하는 단계가 있고, 그 조회 대상이 되지 못하면 인용될 수 없다는 뜻입니다.

둘째는 쿼리 팬아웃(query fan-out)입니다. 사용자가 하나를 물어도 모델이 관련 하위 질의 여러 개를 동시에 만들어 검색을 확장하는 기법입니다. 가이드가 든 예시는 "잡초가 무성한 잔디밭을 어떻게 고치나"라는 질문이 "잔디용 제초제 추천", "화학약품 없이 잡초 제거", "잡초 예방법" 같은 하위 질의로 갈라지는 경우입니다.

이 두 기법을 이해하고 나면 나머지 조언이 왜 나왔는지가 자연스럽게 읽힙니다.

핵심 1: '누구나 쓸 수 있는 글'은 이제 잘 안 통합니다

가이드가 가장 힘줘서 말하는 원칙은 커머디티 콘텐츠를 피하라는 것입니다. 여기서 커머디티 콘텐츠란 흔한 상식을 정리한, 누가 써도 비슷해지는 글을 뜻합니다. 가이드는 대비되는 예시를 듭니다. "첫 주택 구매자를 위한 7가지 팁" 같은 글은 커머디티에 가깝고, "우리가 주택 점검을 생략하고 오히려 돈을 아낀 이유: 하수관 내부를 들여다본 기록" 같은 글은 직접 겪은 사람만 쓸 수 있는 non-commodity 콘텐츠라는 것입니다.

이 대비를 개발 블로그로 옮기면 결론이 꽤 분명해집니다. "코틀린 코루틴 정리 10가지" 같은 글은 이미 공식 문서와 수백 개의 블로그가 같은 내용을 말하고 있어서, AI가 굳이 내 글을 인용할 이유가 약합니다. 반면 "Hilt 스코프를 잘못 잡아서 ViewModel이 매번 새로 생성되던 문제와, 로그를 찍어가며 원인을 좁혀 실제로 고친 과정" 같은 글은 내가 직접 겪지 않으면 쓸 수 없습니다.

핵심은 정보의 양이 아니라 관점의 고유성입니다. AI 시스템은 여러 출처를 훑기 때문에, 이미 인터넷에 널린 내용을 한 번 더 정리한 글보다는 "이 사람만 아는 것"이 담긴 글을 필요로 합니다. 개발 블로그는 사실 이 부분에서 유리합니다. 실제로 코드를 짜고 막히고 해결한 경험이 곧 고유한 관점이기 때문입니다. 문제는 그 경험을 일반론으로 희석해서 쓰는 습관인데, 저는 이번 재독을 계기로 "이 문단을 나 말고 다른 사람도 똑같이 쓸 수 있는가"를 자문하기로 했습니다. 답이 "그렇다"이면 그 문단은 커머디티입니다.

핵심 2: 페이지가 아니라 '문단 하나'가 인용될 수 있습니다

쿼리 팬아웃이 개발 블로그에 주는 실질적인 힌트가 하나 있습니다. 내 페이지가 넓은 검색어에서 상위 10위 안에 못 들더라도, 특정 하위 주제를 정확하게 다룬 문단 하나가 그 하위 질의를 통해 인용될 수 있다는 점입니다.

이건 글의 구성 방식을 바꾸는 이야기입니다. 하나의 긴 글 안에서도 각 문제와 해결이 자기완결적인 단위로 정리돼 있으면, 그중 일부만 뽑혀 인용될 여지가 커집니다. 개발 글에서는 이렇게 적용할 수 있습니다. 하나의 에러 상황, 그 원인, 실제 해결 코드, 주의점을 한 덩어리로 묶어서, 그 문단만 떼어놔도 말이 되게 쓰는 것입니다.

주의할 점도 같이 나옵니다. 사람들이 검색할 법한 모든 변형을 노리고 페이지를 잘게 쪼개 대량 생산하는 것은 오히려 스팸 정책 위반이라고 가이드는 명시합니다. 팬아웃을 노린다는 명분으로 얇은 페이지를 찍어내면 역효과라는 뜻입니다. 목표는 페이지 수를 늘리는 게 아니라, 하나의 좋은 글 안에서 각 문단의 구체성과 완결성을 높이는 쪽입니다.

핵심 3: 결국 기술적 토대는 예전 그대로의 SEO입니다

가이드는 화려한 새 기법 대신 익숙한 것들을 다시 강조합니다. 정리하면 이렇습니다. 페이지가 색인(index)되고 스니펫으로 노출될 자격이 있어야 AI 기능에도 나올 수 있고, 크롤링이 막혀 있으면 애초에 조회 대상이 되지 못합니다. 의미론적(semantic) HTML은 쓰면 좋지만 완벽할 필요는 없다고 못 박습니다. 스크린 리더 같은 다른 사용자에게 도움이 되니 가능한 선에서 지키면 된다는 정도입니다. 그리고 모바일 대응, 로딩 속도, 본문과 부가 요소의 구분 같은 페이지 경험도 그대로 유효합니다.

티스토리로 블로그를 운영하는 입장에서 이 부분은 통제 가능한 것과 그렇지 않은 것을 나눠서 볼 필요가 있습니다. 렌더링 구조나 전역 HTML 골격은 스킨과 플랫폼에 상당 부분 묶여 있지만, 색인 가능성(공개 설정, robots 관련 설정), 본문 구조(제목 태그, 문단, 목록, 이미지 대체 텍스트), 중복 콘텐츠 정리 같은 건 글쓴이가 직접 챙길 수 있습니다. 저는 여기서 특별한 걸 새로 배우기보다는, 원래 알고 있던 SEO 기본기를 게을리하지 않는 쪽에 초점을 두기로 했습니다.

하지 않아도 되는 것들: 구글이 직접 정리한 오해

가이드에서 개인적으로 가장 실용적이라고 느낀 부분은 "안 해도 된다"를 명확히 해준 항목들입니다. AEO 꿀팁이라는 이름으로 도는 조언 중 상당수를 구글이 직접 걷어냈기 때문입니다.

llms.txt 같은 AI 전용 파일은 구글 생성형 AI 검색에 나오기 위해 만들 필요가 없습니다. 구글이 그 파일을 크롤링할 수는 있어도 특별 취급하지는 않습니다. 다만 이건 어디까지나 구글 기준이라는 단서가 중요합니다. 구글 외 다른 AI 시스템 중 일부는 이 표준에 우호적이므로, 내 독자가 어떤 검색 표면을 주로 쓰는지에 따라 판단은 달라질 수 있습니다.

콘텐츠를 AI가 잘 이해하도록 잘게 쪼갤(chunking) 필요도 없습니다. 구글 시스템은 한 페이지 안의 여러 주제를 구분해서 필요한 부분만 사용자에게 보여줄 수 있습니다. 이상적인 페이지 길이 같은 것도 없습니다.

AI만을 위해 별도의 어투로 다시 쓰는 것도 불필요합니다. AI는 동의어와 대략적인 의도를 이해하므로, 롱테일 키워드를 다 채워 넣지 못했다고 걱정하지 않아도 됩니다. 인위적으로 "언급(mention)"을 만들어 내는 것도 생각만큼 효과가 없습니다. 핵심 랭킹 시스템은 고품질 콘텐츠에 집중하고 다른 시스템은 스팸을 걸러내는데, 생성형 AI 기능은 이 둘 모두에 의존하기 때문입니다.

구조화 데이터(structured data)에 과몰입할 필요도 없습니다. 생성형 AI 검색에 필수는 아닙니다. 다만 이건 여전히 리치 결과 자격에는 도움이 되므로, 전체 SEO 전략의 일부로는 계속 쓰는 게 좋다는 균형 잡힌 조언이 붙습니다.

잠깐 미래 이야기: 에이전트가 블로그를 읽는 시대

가이드 마지막에는 아직 초기이고 빠르게 바뀌는 영역이라는 단서와 함께, 에이전트 관련 내용이 짧게 붙어 있습니다. 개발자 입장에서는 오히려 이 부분이 가장 흥미로웠습니다.

여기서 말하는 AI 에이전트는 예약을 잡거나 제품 사양을 비교하는 것처럼 사람을 대신해 작업을 수행하는 자율 시스템입니다. 브라우저 에이전트는 화면 렌더링(스크린샷), DOM 구조, 접근성 트리를 해석하며 사이트에서 필요한 데이터를 모읍니다. 가이드는 에이전트 친화적인 사이트 UX 가이드를 참고하라고 안내하고, UCP(Universal Commerce Protocol)나 WebMCP 같은 신흥 프로토콜을 언급합니다. 검색 에이전트가 검색 결과에서 바로 사용자를 대신해 행동할 수 있게 하는 방향입니다.

지금 당장 개발 블로그가 대응해야 할 일은 아닙니다. 가이드도 이 부분을 선택적이고 미래지향적인 것으로 명확히 선을 긋습니다. 다만 접근성 트리와 의미론적 구조가 사람뿐 아니라 에이전트에게도 읽기 좋은 신호가 된다는 점은 기억해 둘 만합니다. 사람을 위해 잘 구조화하는 것이, 결국 에이전트 대응의 기본기와 겹칩니다.

그래서 내 블로그에 무엇을 바꿀 것인가

재독을 마치고 제가 실제로 조정하기로 한 것들을 정리했습니다.

첫째, 글을 시작하기 전에 "이 글에 나만의 경험이 있는가"를 먼저 확인합니다. 일반론 정리로 끝날 것 같으면 주제를 다시 잡습니다. 둘째, 하나의 글 안에서 문제와 해결을 자기완결 단위로 끊어 씁니다. 각 덩어리만 떼어 읽어도 말이 되게 하는 것이 목표입니다.

셋째, 이미지와 코드 블록을 아끼지 않습니다. 생성형 AI 검색도 관련 이미지를 함께 노출할 수 있으므로, 대체 텍스트를 성의 있게 다는 것까지가 한 세트입니다.

넷째, AEO 전용 꿀팁을 작성하는데 시간을 쓰지 않습니다. 그 시간에 색인 상태와 본문 구조 같은 기본기를 점검하는 편이 낫습니다.

마치며

가이드 전체를 관통하는 원칙은 결국 하나였습니다. 방문자가 읽고 나서 도움이 됐다고, 만족했다고 느낄 콘텐츠인가. 판단이 애매할 때마다 이 질문 하나로 돌아오면 대부분 방향이 잡힙니다.

개발 블로그는 이 흐름에서 불리하지 않습니다. 오히려 직접 부딪히며 얻은 경험이라는, 흔치 않은 재료를 이미 손에 쥐고 있습니다. AI 검색이 커진다는 건 잘 정리된 상식이 흔해진다는 뜻이기도 하고, 그럴수록 직접 겪은 이야기의 값이 올라간다는 뜻이기도 합니다. 저는 그 방향으로 계속 써보려 합니다.