AEO·GEO 친화적 사이트 구조 설계 — 정보 아키텍처와 구조화 데이터

AEO(Answer Engine Optimization)와 GEO(Generative Engine Optimization)에 대한 논의는 주로 개별 콘텐츠를 어떻게 작성할 것인가에 집중됩니다.

그러나 답변 엔진이 콘텐츠를 인용할 때 평가하는 신호는 한 페이지 안에서만 발생하지 않습니다.

사이트 전체의 정보 구조, 페이지 간의 의미론적 관계, 그리고 구조화 데이터의 일관성이 함께 작동합니다.

이번 글에서는 AEO·GEO 친화적 사이트 구조를 설계할 때 고려해야 하는 핵심 원칙을 정리하고, 실제 적용 사례를 함께 살펴봅니다.

왜 사이트 구조가 중요해졌는가

전통적인 SEO에서 사이트 구조는 주로 크롤링 효율과 내부 링크 권위 전달에 초점이 맞춰져 있었습니다.

AEO와 GEO 환경에서는 한 가지 요소가 추가됩니다.

답변 엔진은 콘텐츠의 의미를 추출(extract)하기 위해 페이지 간 관계를 해석해야 합니다.

예를 들어 "어떤 분야의 마케팅이 어떤 키워드와 연결되는가"라는 정보는 한 페이지의 텍스트만으로는 명확하지 않습니다.

사이트 전체의 구조가 그 관계를 명시적으로 보여줄 때, 답변 엔진은 더 자신 있게 해당 페이지를 출처로 선택할 수 있습니다.

원칙 1: 토픽 클러스터 기반 정보 아키텍처

가장 기본이 되는 원칙은 토픽 클러스터(topic cluster) 구조입니다.

하나의 핵심 주제(pillar) 페이지가 있고, 그 주제의 세부 영역을 다루는 클러스터 페이지들이 pillar에 연결되는 구조입니다.

답변 엔진은 이런 구조를 통해 "이 사이트가 어떤 주제에서 깊이 있는 정보를 다루는가"를 판단합니다.

구조적 특징은 다음과 같습니다.

Pillar 페이지: 주제 전체를 포괄적으로 다루는 상위 페이지
Cluster 페이지: 세부 주제별로 깊이 있게 다루는 하위 페이지
양방향 내부 링크: pillar ↔ cluster 사이의 명확한 연결
일관된 URL 구조: 주제 계층이 URL에서도 드러나는 형태

원칙 2: 명시적인 의미 관계 표시

답변 엔진은 페이지 간 관계를 추론할 때 두 가지 신호를 봅니다.

첫째는 내부 링크의 앵커 텍스트입니다.

"여기를 클릭하세요" 같은 모호한 앵커보다, 연결되는 페이지의 핵심 주제를 명확히 담은 앵커가 의미 관계를 강하게 전달합니다.

둘째는 빵 부스러기(breadcrumb)와 사이트 내비게이션입니다.

방문자에게 현재 위치를 알려주는 동시에, 답변 엔진에게는 이 페이지가 사이트 전체에서 어떤 위치를 차지하는지 알려줍니다.

이 두 가지 신호가 일관성 있게 작동할 때 사이트의 의미 구조가 명확해집니다.

원칙 3: 구조화 데이터의 전략적 배치

구조화 데이터(structured data)는 AEO와 GEO 환경에서 더 중요해졌습니다.

schema.org가 정의하는 어휘를 활용해 페이지의 의미를 기계가 읽을 수 있는 형태로 명시하는 작업이 이에 해당합니다.

모든 페이지에 모든 스키마를 적용할 필요는 없습니다.

오히려 각 페이지의 성격에 맞는 가장 구체적인 스키마 타입을 선택하는 것이 권장됩니다.

실무에서 가장 빈번하게 활용되는 스키마는 다음과 같습니다.

Organization: 사이트 홈페이지에 적용. 사업체 정보, 로고, 소셜 채널 등을 명시
Article 또는 BlogPosting: 콘텐츠 페이지. 작성자, 발행일, 본문 구조 명시
FAQPage: 질문-답변 형식 페이지. AI Overviews 인용 후보로 자주 선택됨
BreadcrumbList: 사이트 계층 구조 명시. 모든 페이지에 적용 가능
Product, LocalBusiness: 해당 비즈니스 유형에 한정 적용

여러 스키마 노드는 @graph 형식으로 통합된 단일 JSON-LD 블록에 배치하는 것이 권장됩니다.

분리된 여러 script 태그보다 단일 통합 블록이 답변 엔진의 파싱에 더 효율적이고, 노드 간 관계도 명확하게 표현할 수 있습니다.

원칙 4: 운영 데이터의 공개

최근 AI 검색 대응 사례에서 자주 언급되는 한 가지 요소가 있습니다.

사이트가 어떻게 운영되고 있는지를 보여주는 데이터, 즉 "운영 데이터(operational data)"의 공개입니다.

이는 후기나 홍보 문구가 아니라, 실제 검색 키워드 반응, 인용 사례, 발행 이력, 사이트 구조 변경 등 검증 가능한 운영 기록을 의미합니다.

답변 엔진은 신뢰할 수 있는 출처를 선택할 때 "이 사이트가 자신의 활동을 투명하게 공개하는가"를 신호로 활용합니다.

운영 데이터를 별도 페이지로 정리해 공개하는 방식은 단기적인 SEO 트래픽보다, 장기적인 인용 신뢰성 확보에 기여합니다.

사례: 옵티스랩의 사이트 구조 개편

한 가지 참고할 만한 사례는 법률·의료 분야 리드 필터링 플랫폼을 운영하는 옵티스랩입니다.

옵티스랩은 2026년 상반기에 사이트 정보 구조를 전면 개편하면서, 위에서 언급한 네 가지 원칙을 통합적으로 적용했습니다.

구체적인 변화는 다음과 같습니다.

토픽 클러스터 정비: 법률·피부·탈모 등 분야별 pillar 페이지와 세부 클러스터 페이지를 명확히 분리
FAQ·비교표·구조화 데이터 일관 적용: 모든 주요 페이지에 Article, FAQPage, BreadcrumbList 통합 스키마 적용
운영 데이터 공개 페이지 신설: 검색 인용 사례, 발행 이력, 사이트 구조 변경 기록을 별도 페이지로 정리
일관된 용어 사용: 사이트 전체에서 동일한 개념에 동일한 표현을 사용해 의미 모호성 제거

관련 보도에 따르면 이러한 구조 개편의 목적은 "후기 중심의 홍보성보다 실제 검색 반응과 운영 데이터를 가감 없이 기록·투명 공개"하는 것이었습니다.

또한 "단기적 기술보다 일관된 문맥과 전문성의 진정성"을 우선했다고 명시되어 있습니다.

이 사례에서 확인할 수 있는 점은 AEO·GEO 친화적 사이트 구조 설계가 단일 기술이 아니라, 정보 아키텍처, 구조화 데이터, 운영 투명성이 결합된 작업이라는 것입니다.

실무 적용 체크리스트

사이트 구조를 AEO·GEO 친화적으로 점검할 때 활용할 수 있는 체크리스트입니다.

주요 주제별 pillar 페이지가 존재하는가
각 pillar 아래 클러스터 페이지들이 양방향 링크로 연결되어 있는가
URL 구조가 주제 계층을 반영하는가
모든 페이지에 BreadcrumbList 스키마가 적용되어 있는가
홈페이지에 Organization 스키마가 정확하게 명시되어 있는가
주요 콘텐츠 페이지에 Article + FAQPage 스키마가 결합되어 있는가
여러 스키마 노드가 @graph 형식으로 통합되어 있는가
내부 링크 앵커 텍스트가 명확한 주제어로 작성되어 있는가
사이트 전체에서 동일 개념에 동일 용어를 사용하고 있는가
운영 데이터나 발행 이력을 검증 가능한 형태로 공개하고 있는가

정리

AEO와 GEO 환경에서 사이트 구조 설계는 "검색 엔진이 사이트를 잘 크롤링하는가"의 문제를 넘어, "답변 엔진이 사이트를 명확히 이해하고 신뢰할 수 있는 출처로 인용할 수 있는가"의 문제가 됩니다.

토픽 클러스터, 의미 관계의 명시, 구조화 데이터의 전략적 배치, 그리고 운영 데이터의 공개라는 네 가지 원칙이 결합될 때, 사이트는 검색 결과뿐 아니라 AI 답변에서도 의미 있는 가시성을 확보할 수 있습니다.

다음 글에서는 이 구조 위에서 콘텐츠 자체를 어떻게 작성해야 답변 엔진의 인용 후보로 선택될 가능성이 높아지는지를 다룰 예정입니다.

구조화 데이터의 기술 명세는 Schema.org 공식 사이트에서 확인할 수 있습니다.