FAQPage·HowTo 스키마는 왜 AEO의 기본기인가 — AI가 인용 가능한 답변을 만드는 구조화 데이터 실전 가이드

왜 구조화 데이터가 AI 검색 시대의 "공용 언어"인가

AEO(Answer Engine Optimization)라는 개념 자체는 이제 낯설지 않습니다. 문제는 그 다음 단계입니다 — "AI가 우리 콘텐츠를 인용하게 만들려면 실제로 무엇을 해야 하는가." 많은 팀이 여기서 막힙니다. 좋은 글을 쓰는 것과, 그 글을 AI가 구조적으로 이해할 수 있는 형태로 만드는 것은 다른 작업이기 때문입니다.

사람은 문단을 읽고 맥락을 추론합니다. 반면 AI 답변엔진은 페이지를 크롤링할 때 텍스트와 함께 구조화 데이터(Structured Data) — 즉 schema.org 어휘로 작성된 JSON-LD 마크업 — 를 함께 파싱합니다. 같은 정보라도 이 마크업이 있으면 "이 텍스트는 질문이고, 저 텍스트는 그 질문에 대한 답이다"라는 관계가 기계에게 명시적으로 전달됩니다. 구조화 데이터가 AEO의 기본기로 불리는 이유입니다 — 좋은 콘텐츠를 AI가 "인용 가능한 형태"로 바꿔주는 번역 계층이기 때문입니다.

FAQPage 스키마 — 질문-답변을 AI가 그대로 인용하게 만드는 법

FAQPage는 페이지 안의 질문과 답변 쌍을 구조적으로 선언하는 스키마입니다. 화면에 아코디언 UI로 보여주는 FAQ와 별개로, 그 안의 각 질문(Question)과 수용 답변(acceptedAnswer)을 기계가 읽을 수 있는 쌍으로 명시합니다.

작성 원칙: 실제 사용자가 검색할 법한 질문 형태를 그대로 제목화할 것 · 답변은 화면에 보이는 텍스트와 정확히 일치시킬 것(요약이나 축약 금지) · 한 페이지에 최소 2~3개 이상의 질문-답변 쌍을 포함할 것 · 광고성 문구나 다른 페이지로 유도하는 텍스트만으로 답변을 채우지 않을 것.

핵심은 "질문을 만드는 것"이 아니라 "독자가 이미 궁금해하는 것을 정확히 반영하는 것"입니다. 검색 의도와 무관한 질문을 억지로 채워 넣으면 스키마 문법은 유효해도 AI가 그 답변을 실제 질의에 매칭시키지 않습니다.

HowTo 스키마 — 가중치가 가장 높은 이유와 작성 원칙

HowTo는 순서가 있는 절차를 단계(step)별로 구조화하는 스키마입니다. AEGIS Index의 38개 측정 항목 중 HowTo 스키마는 가장 높은 개별 가중치(×2.0)를 받는데, 이유는 명확합니다 — AI가 "어떻게 하는가"라는 질의에 답할 때 가장 신뢰하는 근거가 순서가 명시적으로 구조화된 절차이기 때문입니다. 산문으로 풀어 쓴 "먼저 이렇게 하고, 그다음 저렇게 하면 됩니다" 형태보다, name과 text가 명확히 분리된 step 배열이 훨씬 인용하기 쉬운 형태입니다.

작성 원칙: 각 단계(step)는 name(짧은 행동 요약)과 text(구체적 실행 내용)를 분리해서 작성 · 단계 순서는 실제 실행 순서와 정확히 일치 · 5~7단계 내외로 지나치게 잘게 쪼개지 않을 것 · 선택적 요소(도구·재료가 필요한 경우 tool·supply 필드)는 있는 경우에만 채울 것.

자주 하는 실수 5가지

실수	왜 문제인가
스키마 내용과 화면 표시 내용 불일치	구조화 데이터 남용으로 판단돼 리치 결과 제외·페널티 위험
같은 타입 스키마 중복 삽입	페이지당 FAQPage·HowTo는 1회만 — 중복 시 파싱 오류
질문을 검색 의도와 무관하게 창작	문법은 유효해도 AI가 실제 질의에 매칭시키지 않음
필수 필드 누락(question/answer, step의 name/text 등)	Rich Results Test에서 오류로 표시되며 파싱 자체가 실패할 수 있음
스키마만 넣고 검증을 생략	문법 오류를 배포 후에야 발견 — 색인 반영까지 시간 손실

검증하는 법 — Rich Results Test와 Search Console

스키마를 작성한 뒤 반드시 거쳐야 할 단계가 검증입니다. Google Rich Results Test에 페이지 URL을 입력하면 어떤 스키마 타입이 인식됐는지, 어떤 필수 필드가 누락됐는지 바로 확인할 수 있습니다. 배포 전 이 단계를 건너뛰면, 문법 오류를 몇 주 뒤 Search Console의 "향상된 기능" 리포트에서야 뒤늦게 발견하게 됩니다 — 그 사이 색인·평가 기회를 그만큼 놓치는 셈입니다.

marketing-pivot이 실제로 쓰는 이원화 전략

이 원칙들을 이론으로만 설명하지 않기 위해, marketing-pivot이 실제로 적용한 방식을 공개합니다. 우리는 스키마를 정적 스키마와 동적 스키마 두 층으로 나눠 관리합니다.

정적 스키마는 자주 바뀌지 않는 조직·저자 정보에 씁니다 — Organization, Person, 그리고 홈페이지의 FAQPage·HowTo·DefinedTerm처럼 페이지 하나에 고정으로 들어가는 데이터는 index.html에 직접 삽입해뒀습니다. 배포마다 다시 생성할 필요가 없고, 크롤러가 렌더링 이전에도 즉시 읽을 수 있다는 장점이 있습니다.

동적 스키마는 블로그 포스트별로 달라지는 FAQ·HowTo·Article·BreadcrumbList에 씁니다 — 이 글을 포함한 모든 블로그 포스트는 faqs·howToSteps 같은 콘텐츠 데이터 필드를 갖고 있고, 렌더링 시점에 그 데이터로부터 JSON-LD를 자동 생성합니다. 포스트를 추가할 때마다 스키마를 손으로 새로 작성하지 않아도, 데이터 구조만 채우면 스키마가 자동으로 따라옵니다. 콘텐츠 수가 늘어날수록 이 이원화가 유지보수 부담을 줄여주는 구조입니다.

이 구조를 처음부터 완벽하게 설계할 필요는 없습니다. 몇 개 안 되는 페이지라면 정적으로 시작해도 충분하고, 콘텐츠가 늘어나는 시점에 동적 생성 계층을 붙이면 됩니다. 중요한 것은 "화면에 보이는 내용 = 스키마에 선언된 내용"이라는 원칙을 처음부터 지키는 것입니다.

자가진단 — 우리 사이트에 스키마가 제대로 들어가 있는지 확인하기

AEGIS Insight는 sitemap.xml을 직접 파싱해 각 URL에 어떤 스키마 타입이 실제로 존재하는지 자동으로 확인합니다(구조적 스캔 단계라 Gemini 토큰 없이 몇 초 안에 실측값이 나옵니다). "스키마를 넣었다고 생각했는데 실제로는 안 들어가 있는" 흔한 사각지대를 이 단계에서 바로 발견할 수 있습니다.

마치며

구조화 데이터는 화려한 신기술이 아닙니다. AI가 이미 좋은 콘텐츠를 "인용 가능한 형태"로 읽게 만드는, 눈에 잘 안 띄지만 반드시 필요한 번역 계층입니다. FAQPage와 HowTo부터 화면 내용과 정확히 일치하게 작성하고, Rich Results Test로 검증하는 습관만 들여도 AEO의 기본기는 갖춰집니다.