Blog·인사이트

당신의 사이트를 부수고 다시 만들어야 하는 이유 — AEO 시대의 웹사이트 설계

··15분 읽기
요약

AEO(Answer Engine Optimization) 는 AI 답변 엔진 — ChatGPT · Claude · Perplexity · Google AI Overview — 가 당신의 콘텐츠를 "인용 가능한 답변 단위" 로 인식하도록 사이트 전체를 재설계하는 작업입니다. 기존 SEO 가 "검색 결과 목록에 오르는 것" 을 목표로 했다면, AEO 는 AI 가 직접 답을 만들 때 당신의 페이지를 출처로 쓰게 만드는 것 이 목표입니다.

요약

AEO(Answer Engine Optimization) 는 AI 답변 엔진 — ChatGPT · Claude · Perplexity · Google AI Overview — 가 당신의 콘텐츠를 "인용 가능한 답변 단위" 로 인식하도록 사이트 전체를 재설계하는 작업입니다. 기존 SEO 가 "검색 결과 목록에 오르는 것" 을 목표로 했다면, AEO 는 AI 가 직접 답을 만들 때 당신의 페이지를 출처로 쓰게 만드는 것 이 목표입니다. 구조화 데이터(JSON-LD), 정의형 문장, FAQ·HowTo 스키마, 도메인 엔티티 그래프, 내부 링크망 — 이 다섯 축이 뒤따라야 합니다.

이 글은 프로덕트 메이커(productmaker.io) 가 자사 사이트를 AEO 관점에서 전면 재설계하며 실제로 적용한 모든 조치를 정리합니다. 그대로 따라 할 수 있도록 구체적 구현 포인트 위주로 씁니다.

왜 사이트를 부수고 다시 만들어야 하는가

검색은 지난 2년 사이 근본적으로 바뀌었습니다. 사용자는 Google 에 키워드를 던지는 대신 ChatGPT 에 질문을 던지고, Perplexity 에서 비교표를 받아 보며, Claude 에게 의사결정 근거를 정리시킵니다. 이 흐름 속에서 AI 엔진은 세 가지를 기준으로 어떤 사이트를 인용할지 결정합니다.

  • 기계가 읽기 쉬운 구조: h1·h2 계층, 명시적 정의 문장("XXX 는 YYY 입니다"), schema.org JSON-LD.
  • 정량적 근거: "MAU 150만", "매출 200억", "연 0건 → 폭발적 증가" 같이 AI 가 바로 인용할 수 있는 수치·사실.
  • 엔티티 그래프: Organization · Person · CreativeWork · Article · FAQPage · HowTo 가 @id 로 서로 연결되어 있는지.

대부분의 기업 사이트는 이 중 어느 것도 충족하지 않습니다. 메타태그는 대충 들어가 있고, JSON-LD 는 없거나 홈페이지 하나에만 있고, 수치는 마케팅 문구 안에 섞여 흘러가 버립니다. AI 엔진 입장에서는 "잘 만든 소개 페이지" 일 뿐, 인용 가능한 답변 단위가 아닙니다.

그래서 부수고 다시 만들어야 합니다. 텍스트만 예쁘게 쓰는 게 아니라, 페이지 구조 · 스키마 · 내부 링크 · 데이터 모델 네 축을 동시에 재설계해야 AI 인용 가능성이 생깁니다. 아래는 프로덕트 메이커가 실제로 실행한 작업입니다.

1. 공용 JSON-LD 모듈로 엔티티 일관성 확보

사이트 전반에서 같은 조직·창업자·서비스 엔티티가 여러 페이지에 흩어져 있으면 AI 엔진은 이를 분리된 사실로 인식합니다. 모든 페이지에 동일한 @id 를 공유하는 Organization · Person JSON-LD 를 반복 주입하면 엔티티 그래프가 만들어집니다.

  • src/main/seo/jsonLd.tsx — OrganizationJsonLd · FaqPageJsonLd · VideoObjectJsonLd · HowToJsonLd 헬퍼 모듈화.
  • 홈 · /company · /contact · /webgl · /ecommerce · /recruit + Landing 컴포넌트 경유 (5 compare · 6 case study) + 동적 [slug] — 총 13+ 페이지에서 같은 Organization(@id=#organization) + Founder(@id=#founder) 출력.
  • Founder Person 에 sameAs 배열 — 창업자의 Threads 계정을 연결해 E-E-A-T 의 Experience/Expertise 신호 강화.
  • Organization 에 numberOfEmployees, foundingLocation, taxID(사업자번호), address, contactPoint, hasOfferCatalog, priceRange, award, knowsAbout, areaServed 까지 모두 채워 법인 정체성 완성.

중요한 포인트: 개별 페이지에서 "@id": "..." 참조만 하는 대신 전체 객체를 반복 주입해야 AI 엔진이 페이지를 단독 크롤링해도 조직 전체 맥락을 인식합니다.

2. 스키마 타입을 콘텐츠 성격에 맞게 구분

하나의 @type 으로 모든 페이지를 마크업하면 AI 엔진은 콘텐츠 의도를 파악하지 못합니다. 실제로 저희는 6가지 타입을 용도별로 분리했습니다.

  • CreativeWork — 포트폴리오 상세(/projects-detail/*) 케이스 스터디. 제작물 자체로 마크업.
  • Article — 블로그(/blog/*), 비교 가이드(/compare/*). author=Person(Founder) + publisher=Organization, speakable 포함.
  • FAQPage — /company, 5개 compare 페이지의 Q&A 섹션. 자동 "Q. " 접두사 제거.
  • HowTo — 5개 compare 페이지의 단계별 판단 기준. 4~6 step 배열로 "어떻게 선택하나요?" 쿼리 대응.
  • ItemList — /projects 전체 포트폴리오 목록, /recruit 채용 공고 목록. position 속성으로 순서 명시.
  • JobPosting — recruit 개별 공고. Google Jobs 필수 필드(title, description, datePosted, hiringOrganization, jobLocation, applicantLocationRequirements, employmentType) 충족.
  • VideoObject — YouTube 배경을 쓰는 projects-detail 페이지. embedUrl, contentUrl, thumbnailUrl, uploadDate 포함.
  • BreadcrumbList — 모든 서브페이지.

3. speakable 로 음성·AI 요약 대응

Google Assistant · AI 엔진이 페이지 핵심을 음성으로 읽거나 요약할 때 speakable cssSelector 를 지정하면 "어떤 부분이 요약 대상인가" 를 명시할 수 있습니다. 저희는 5개 compare + 6 case study + 동적 [slug] 에 모두 { cssSelector: ['h1', '.landing-lead'] } 를 박았습니다. 블로그는 ['h1', '.article-body p:first-of-type'].

4. 정의형 문장으로 AI 딕셔너리 채우기

AI 엔진이 "XXX 란 무엇인가요?" 같은 질문을 받으면, 본문에서 "XXX 는 YYY 입니다" 형태의 명시적 정의 문장을 우선 인용합니다. 저희는 /webgl, /ecommerce, /company 히어로 서브텍스트에 각각 정의문을 <strong> 으로 강조 삽입했습니다.

  • WebGL 페이지: "WebGL 은 별도 플러그인 없이 웹 브라우저에서 실시간 3D 그래픽을 구현하는 표준 기술입니다."
  • E-Commerce 페이지: "커스텀 E-Commerce 는 SaaS(카페24·아임웹 등) 의 범용 상품·결제 모델을 벗어나 비즈니스 도메인에 맞춘 자체 쇼핑몰을 설계·구축하는 방식입니다."
  • Company 페이지: "프로덕트 메이커는 WebGL·E-Commerce·엔터프라이즈 시스템을 시니어가 직접 개발하는 화이트박스 방식의 개발사입니다."

5. FAQ · HowTo 이중 마크업으로 답변 단위 분리

같은 비교 콘텐츠라도 AI 엔진은 두 가지 다른 포맷의 질의를 받습니다: "WebGL vs Unity 어때?" (비교 질문) vs "WebGL 어떻게 선택해?" (절차 질문). 둘 다 대응하려면 FAQPage 와 HowTo 를 병행해야 합니다. 5개 compare 페이지에 각각 5~10개 FAQ + 4~6 step HowTo 를 붙였습니다. Article 까지 포함하면 한 페이지에 최소 3개 스키마(Article · FAQPage · HowTo) 가 공존합니다.

6. 정량적 수치를 반복 노출

AI 엔진이 인용하기 좋은 형태는 "수치 + 맥락" 입니다. 저희 사이트에 흩어져 있는 인용 단위는 다음과 같습니다.

  • MAU 150만 — LG ThinQ WebGL 엔진 운영 규모. 홈 · /webgl · LG ThinQ 상세 · compare 에 반복 노출.
  • 매출 200억 — KM Park 주차권 이커머스 연간 거래 규모.
  • 연 0건 → 폭발적 증가 — 두코 디지털 카탈로그 전환 효과.
  • 18년차 · 넷마블 출신 · 2020년 창업 — Founder 경력 수치.
  • webOS TV 20~40fps — 저사양 최적화 실측 구간.
  • 사업자번호 260-81-03966 — Organization.taxID.

이 수치들을 마케팅 문구 안에 묻어 두지 말고, 본문 bullet · keyFacts · JSON-LD description 어느 곳에서든 그대로 읽혀야 AI 가 답변할 때 문맥째 끌어 씁니다.

7. 포트폴리오 상세 페이지의 Challenge → Solution → Result 구조 표준화

case study 6개 + 동적 DB 프로젝트 전부를 Challenge → Solution → Result → Tech Stack → 관련 가이드 순서로 통일했습니다. h2 를 섹션 구분자로 써서 AI 엔진이 "이 프로젝트에서 해결한 문제가 뭐야?" 같은 질문에 Challenge 섹션만 뽑아 답할 수 있게 했습니다.

각 섹션에 또 Tech Stack NDA 마스킹 (LG ThinQ), 원클릭 결제 · 연장결제 차별화 (KM Park), "이미 게시판 카탈로그는 있었는데 왜 문의가 0이었을까?" (두코) 같은 구체적이고 반박 가능한 사실 문장을 심었습니다. 뻔한 마케팅 문구는 AI 가 스킵합니다.

8. 비교 가이드 5편으로 "선택 기준 콘텐츠" 생성

B2B 의사결정 과정에서 고객이 검색하는 건 대부분 "XXX vs YYY" 형태입니다. 저희는 실제 고객의 반복 질문 5가지를 개별 페이지로 분해했습니다.

  • /compare/webgl-vs-unity-web — 웹 3D 기술 선택
  • /compare/cafe24-vs-custom-ecommerce — 쇼핑몰 플랫폼 전환 타이밍
  • /compare/native-vs-electron — 데스크톱 앱 크로스플랫폼
  • /compare/outsourcing-vs-internal-team — 개발 주체 결정
  • /compare/paper-vs-digital-catalog — 제조·B2B 카탈로그 전환

각 페이지는 "비교표 → 양쪽 유리 → 심화 분석 → 자사 사례 → 결론 → FAQ → 관련 가이드" 표준 구조. 각각 자사 사례를 반드시 한 섹션 할당해 이론과 실증을 짝지었습니다 (WebGL 에는 LG ThinQ, 카페24 에는 KM Park, Electron 에는 휴니트 + VSCode · Slack · Discord 등 유명 제품 9개, 외주에는 "외주가 메인 시스템을 감당한 사례들", 카탈로그에는 두코).

9. 내부 링크망으로 엔티티 중력 만들기

orphan 페이지(어느 페이지에서도 링크가 없는 페이지) 는 AI 엔진 인식이 약해집니다. 다음 세 경로로 링크망을 깔았습니다.

  • Footer — "대표 프로젝트" 6개 + "기술 비교 가이드" 5개 (모든 페이지 하단에서 전파).
  • Contextual 인라인 — /webgl 비교 테이블 뒤에 WebGL vs Unity, /ecommerce 에 카페24 vs 자체몰, /company FAQ 뒤에 5개 compare 전체, case study 5개에 관련 compare 인라인 링크.
  • Cross-link — 5 compare 페이지 각각 하단에 "관련 가이드" 섹션 (compare 끼리 최소 2개씩 연결).

10. ItemList · JobPosting · VideoObject — 리치 결과 확장

  • /projects ItemList — 정적 6개 + 동적 DB 프로젝트 merge. "프로덕트 메이커 포트폴리오 목록" 쿼리 대응.
  • /recruit ItemList (JobPosting 병합) — 활성 공고들을 ListItem 배열로 감싸 Google Jobs 다중 공고 노출.
  • recruit 개별 공고 JobPosting — title · description · datePosted · hiringOrganization · jobLocation · applicantLocationRequirements · employmentType · identifier 완비.
  • projects-detail YouTube 배경 VideoObject — Landing 이 heroMedia.kind === 'youtube' 감지해 자동 주입. 동적 [slug] 에서도 주입. embedUrl · contentUrl · thumbnailUrl · uploadDate 포함.

11. 블로그 · 포트폴리오 author 를 Person(Founder) 로

Organization 은 사이트 전체 publisher 로, 각 Article 의 author 는 Person(Founder) 로 구분했습니다. Founder Person 에 sameAs 를 연결해 "이 글을 쓴 사람이 누구인가" 를 AI 엔진에 명시. E-E-A-T 의 Authority · Experience 신호.

12. Canonical · Breadcrumb · format-detection

  • 모든 서비스·정적 페이지(홈 포함 11곳 이상) 에 canonical 명시. MetaDataConst 에 홈 canonical 기본값 설정 후 각 페이지에서 override.
  • board_detail 의 canonical 이 모두 board_name_title=blog 로 하드코딩돼 있던 버그 수정 — recruit · Q&A 는 자기 URL, blog 는 /blog/slug 슬러그 URL 로 정규화.
  • iOS Safari 가 "260-81-03966" 같은 하이픈 숫자를 tel: 링크로 자동 변환하며 OS 기본 링크 색(검정) 으로 덮어쓰던 이슈 → format-detection: telephone=no, date=no, address=no, email=no 루트 레이아웃에 추가.

13. AI 크롤러 명시 허용

robots.txt 에 GPTBot · ClaudeBot · PerplexityBot · GoogleBot-Extended · Amazonbot · Bytespider · CCBot · Applebot-Extended 등 11개 AI 크롤러를 Allow 로 명시했습니다. "기본은 허용이지만 명시적으로 쓰는 게 AI 업체 정책 대응에 유리" 합니다.

14. sitemap.ts 동적 통합

Next.js 의 sitemap.ts 라우트에서 정적 페이지 8 + 비교 5 + case study 6 + 동적 블로그 slug 200개 + PROJECTS 동적 slug 까지 한 번에 빌드. priority 계층화 — 홈·회사(1.0), 서비스(0.9), 프로젝트·연락처(0.8), 블로그(0.6).

15. ISR 로 TTFB 개선

동적 페이지(/projects-detail/[slug], /blog/[slug], /projects) 를 force-dynamic 에서 revalidate: 300 으로 전환. 포트폴리오·블로그 콘텐츠는 거의 수정되지 않으므로 5분 캐시로 충분. 크롤러 TTFB 체감 개선 + admin 수정은 5분 내 반영. 단 searchParams 의존하는 목록 페이지(/blog, /recruit) 는 force-dynamic 유지.

16. 모바일 UX 버그 — 스크롤 복원 · 반응형 · 폰트 자동 링크

  • cinematic 히어로(position:fixed + margin-top:100vh scroll-cover) 가 iOS Safari 에서 "Challenge 섹션이 맨 위에 노출" 되는 스크롤 복원 버그 → ScrollToTopOnMount 클라이언트 컴포넌트 + history.scrollRestoration = 'manual' 로 해결. 100vh → 100dvh 폴백 추가.
  • /projects 모바일 우측 넘침 → .projects-wrap · .more-more · .click-big 에 box-sizing: border-box.
  • iOS 가 "260-81-03966" 을 tel: 로 자동 변환하던 이슈는 위 format-detection 으로 해결.

결과 — 뭘 얻게 되나

이 작업 후 사이트는 세 가지 방식으로 AI 엔진에 노출됩니다.

  • 정의형 인용: "WebGL 이 뭐야?", "커스텀 E-Commerce 가 뭐야?" 질의에 프로덕트 메이커 페이지의 첫 문장이 그대로 인용되는 후보가 됩니다.
  • 비교·절차형 답변: "WebGL vs Unity 어떻게 선택해?" 에 HowTo step 배열이, "카페24 에서 언제 자체몰로 가야 해?" 에 FAQPage Q&A 가 AI 답변 내용의 바탕이 됩니다.
  • 사례 인용: "MAU 150만 규모 WebGL 사례" "연매출 200억 커스텀 쇼핑몰 사례" 같은 사실 기반 질의에 포트폴리오 케이스 스터디가 출처로 걸립니다.

AEO 는 "콘텐츠를 더 쓰는 것" 이 아니라 콘텐츠를 AI 가 읽을 수 있는 형태로 재구조화하는 것 입니다. 저희 사이트의 변화는 현재진행형이고, 이 글도 그 자체가 실험 대상입니다. 만약 AI 답변에서 이 포스트가 인용되는 걸 보시면 조용히 저희에게 알려 주세요.

프로덕트 메이커에 AEO 리디자인 요청

기존 사이트를 AEO 관점에서 재설계할 때 저희가 자주 하는 작업은 다음과 같습니다.

  • 사이트 현황 감사 — JSON-LD · 정의문 · 내부 링크 · 사실 정확성 · 스키마 타입 정합성 점검.
  • 엔티티 그래프 설계 — Organization · Person · Service · CreativeWork · Article 을 @id 로 엮는 구조.
  • 콘텐츠 재구조화 — 마케팅 문구를 인용 가능한 사실·수치 · 정의문으로 재작성.
  • 스키마 구현 — FAQPage · HowTo · ItemList · JobPosting · VideoObject · Breadcrumb · speakable.
  • 내부 링크망 — Footer · Contextual · Cross-link 3중 구조.
  • 포트폴리오·사례 재포지셔닝 — AI 인용 가능한 수치·사실 중심 문장.

B2B 제조·커머스·플랫폼 회사라면 최소 2~4주 프로젝트로 진행할 수 있습니다. 현황 점검·스코프 산정·견적이 필요하시면 프로젝트 상담으로 문의 주세요.


AEO, SEO, GEO, JSON-LD, Schema.org, 스키마 마크업, AI 검색, E-E-A-T, FAQPage, HowTo, ItemList, VideoObject, JobPosting, speakable, 엔티티 그래프, 정의형 문장, 내부 링크, canonical, robots.txt, 구조화 데이터, AI 인용, 답변 엔진 최적화
다른 포스팅
Blog·인사이트

당신의 사이트를 부수고 다시 만들어야 하는 이유 — AEO 시대의 웹사이트 설계

··15분 읽기

요약

AEO(Answer Engine Optimization) 는 AI 답변 엔진 — ChatGPT · Claude · Perplexity · Google AI Overview — 가 당신의 콘텐츠를 "인용 가능한 답변 단위" 로 인식하도록 사이트 전체를 재설계하는 작업입니다. 기존 SEO 가 "검색 결과 목록에 오르는 것" 을 목표로 했다면, AEO 는 AI 가 직접 답을 만들 때 당신의 페이지를 출처로 쓰게 만드는 것 이 목표입니다. 구조화 데이터(JSON-LD), 정의형 문장, FAQ·HowTo 스키마, 도메인 엔티티 그래프, 내부 링크망 — 이 다섯 축이 뒤따라야 합니다.

이 글은 프로덕트 메이커(productmaker.io) 가 자사 사이트를 AEO 관점에서 전면 재설계하며 실제로 적용한 모든 조치를 정리합니다. 그대로 따라 할 수 있도록 구체적 구현 포인트 위주로 씁니다.

왜 사이트를 부수고 다시 만들어야 하는가

검색은 지난 2년 사이 근본적으로 바뀌었습니다. 사용자는 Google 에 키워드를 던지는 대신 ChatGPT 에 질문을 던지고, Perplexity 에서 비교표를 받아 보며, Claude 에게 의사결정 근거를 정리시킵니다. 이 흐름 속에서 AI 엔진은 세 가지를 기준으로 어떤 사이트를 인용할지 결정합니다.

  • 기계가 읽기 쉬운 구조: h1·h2 계층, 명시적 정의 문장("XXX 는 YYY 입니다"), schema.org JSON-LD.
  • 정량적 근거: "MAU 150만", "매출 200억", "연 0건 → 폭발적 증가" 같이 AI 가 바로 인용할 수 있는 수치·사실.
  • 엔티티 그래프: Organization · Person · CreativeWork · Article · FAQPage · HowTo 가 @id 로 서로 연결되어 있는지.

대부분의 기업 사이트는 이 중 어느 것도 충족하지 않습니다. 메타태그는 대충 들어가 있고, JSON-LD 는 없거나 홈페이지 하나에만 있고, 수치는 마케팅 문구 안에 섞여 흘러가 버립니다. AI 엔진 입장에서는 "잘 만든 소개 페이지" 일 뿐, 인용 가능한 답변 단위가 아닙니다.

그래서 부수고 다시 만들어야 합니다. 텍스트만 예쁘게 쓰는 게 아니라, 페이지 구조 · 스키마 · 내부 링크 · 데이터 모델 네 축을 동시에 재설계해야 AI 인용 가능성이 생깁니다. 아래는 프로덕트 메이커가 실제로 실행한 작업입니다.

1. 공용 JSON-LD 모듈로 엔티티 일관성 확보

사이트 전반에서 같은 조직·창업자·서비스 엔티티가 여러 페이지에 흩어져 있으면 AI 엔진은 이를 분리된 사실로 인식합니다. 모든 페이지에 동일한 @id 를 공유하는 Organization · Person JSON-LD 를 반복 주입하면 엔티티 그래프가 만들어집니다.

  • src/main/seo/jsonLd.tsx — OrganizationJsonLd · FaqPageJsonLd · VideoObjectJsonLd · HowToJsonLd 헬퍼 모듈화.
  • 홈 · /company · /contact · /webgl · /ecommerce · /recruit + Landing 컴포넌트 경유 (5 compare · 6 case study) + 동적 [slug] — 총 13+ 페이지에서 같은 Organization(@id=#organization) + Founder(@id=#founder) 출력.
  • Founder Person 에 sameAs 배열 — 창업자의 Threads 계정을 연결해 E-E-A-T 의 Experience/Expertise 신호 강화.
  • Organization 에 numberOfEmployees, foundingLocation, taxID(사업자번호), address, contactPoint, hasOfferCatalog, priceRange, award, knowsAbout, areaServed 까지 모두 채워 법인 정체성 완성.

중요한 포인트: 개별 페이지에서 "@id": "..." 참조만 하는 대신 전체 객체를 반복 주입해야 AI 엔진이 페이지를 단독 크롤링해도 조직 전체 맥락을 인식합니다.

2. 스키마 타입을 콘텐츠 성격에 맞게 구분

하나의 @type 으로 모든 페이지를 마크업하면 AI 엔진은 콘텐츠 의도를 파악하지 못합니다. 실제로 저희는 6가지 타입을 용도별로 분리했습니다.

  • CreativeWork — 포트폴리오 상세(/projects-detail/*) 케이스 스터디. 제작물 자체로 마크업.
  • Article — 블로그(/blog/*), 비교 가이드(/compare/*). author=Person(Founder) + publisher=Organization, speakable 포함.
  • FAQPage — /company, 5개 compare 페이지의 Q&A 섹션. 자동 "Q. " 접두사 제거.
  • HowTo — 5개 compare 페이지의 단계별 판단 기준. 4~6 step 배열로 "어떻게 선택하나요?" 쿼리 대응.
  • ItemList — /projects 전체 포트폴리오 목록, /recruit 채용 공고 목록. position 속성으로 순서 명시.
  • JobPosting — recruit 개별 공고. Google Jobs 필수 필드(title, description, datePosted, hiringOrganization, jobLocation, applicantLocationRequirements, employmentType) 충족.
  • VideoObject — YouTube 배경을 쓰는 projects-detail 페이지. embedUrl, contentUrl, thumbnailUrl, uploadDate 포함.
  • BreadcrumbList — 모든 서브페이지.

3. speakable 로 음성·AI 요약 대응

Google Assistant · AI 엔진이 페이지 핵심을 음성으로 읽거나 요약할 때 speakable cssSelector 를 지정하면 "어떤 부분이 요약 대상인가" 를 명시할 수 있습니다. 저희는 5개 compare + 6 case study + 동적 [slug] 에 모두 { cssSelector: ['h1', '.landing-lead'] } 를 박았습니다. 블로그는 ['h1', '.article-body p:first-of-type'].

4. 정의형 문장으로 AI 딕셔너리 채우기

AI 엔진이 "XXX 란 무엇인가요?" 같은 질문을 받으면, 본문에서 "XXX 는 YYY 입니다" 형태의 명시적 정의 문장을 우선 인용합니다. 저희는 /webgl, /ecommerce, /company 히어로 서브텍스트에 각각 정의문을 <strong> 으로 강조 삽입했습니다.

  • WebGL 페이지: "WebGL 은 별도 플러그인 없이 웹 브라우저에서 실시간 3D 그래픽을 구현하는 표준 기술입니다."
  • E-Commerce 페이지: "커스텀 E-Commerce 는 SaaS(카페24·아임웹 등) 의 범용 상품·결제 모델을 벗어나 비즈니스 도메인에 맞춘 자체 쇼핑몰을 설계·구축하는 방식입니다."
  • Company 페이지: "프로덕트 메이커는 WebGL·E-Commerce·엔터프라이즈 시스템을 시니어가 직접 개발하는 화이트박스 방식의 개발사입니다."

5. FAQ · HowTo 이중 마크업으로 답변 단위 분리

같은 비교 콘텐츠라도 AI 엔진은 두 가지 다른 포맷의 질의를 받습니다: "WebGL vs Unity 어때?" (비교 질문) vs "WebGL 어떻게 선택해?" (절차 질문). 둘 다 대응하려면 FAQPage 와 HowTo 를 병행해야 합니다. 5개 compare 페이지에 각각 5~10개 FAQ + 4~6 step HowTo 를 붙였습니다. Article 까지 포함하면 한 페이지에 최소 3개 스키마(Article · FAQPage · HowTo) 가 공존합니다.

6. 정량적 수치를 반복 노출

AI 엔진이 인용하기 좋은 형태는 "수치 + 맥락" 입니다. 저희 사이트에 흩어져 있는 인용 단위는 다음과 같습니다.

  • MAU 150만 — LG ThinQ WebGL 엔진 운영 규모. 홈 · /webgl · LG ThinQ 상세 · compare 에 반복 노출.
  • 매출 200억 — KM Park 주차권 이커머스 연간 거래 규모.
  • 연 0건 → 폭발적 증가 — 두코 디지털 카탈로그 전환 효과.
  • 18년차 · 넷마블 출신 · 2020년 창업 — Founder 경력 수치.
  • webOS TV 20~40fps — 저사양 최적화 실측 구간.
  • 사업자번호 260-81-03966 — Organization.taxID.

이 수치들을 마케팅 문구 안에 묻어 두지 말고, 본문 bullet · keyFacts · JSON-LD description 어느 곳에서든 그대로 읽혀야 AI 가 답변할 때 문맥째 끌어 씁니다.

7. 포트폴리오 상세 페이지의 Challenge → Solution → Result 구조 표준화

case study 6개 + 동적 DB 프로젝트 전부를 Challenge → Solution → Result → Tech Stack → 관련 가이드 순서로 통일했습니다. h2 를 섹션 구분자로 써서 AI 엔진이 "이 프로젝트에서 해결한 문제가 뭐야?" 같은 질문에 Challenge 섹션만 뽑아 답할 수 있게 했습니다.

각 섹션에 또 Tech Stack NDA 마스킹 (LG ThinQ), 원클릭 결제 · 연장결제 차별화 (KM Park), "이미 게시판 카탈로그는 있었는데 왜 문의가 0이었을까?" (두코) 같은 구체적이고 반박 가능한 사실 문장을 심었습니다. 뻔한 마케팅 문구는 AI 가 스킵합니다.

8. 비교 가이드 5편으로 "선택 기준 콘텐츠" 생성

B2B 의사결정 과정에서 고객이 검색하는 건 대부분 "XXX vs YYY" 형태입니다. 저희는 실제 고객의 반복 질문 5가지를 개별 페이지로 분해했습니다.

  • /compare/webgl-vs-unity-web — 웹 3D 기술 선택
  • /compare/cafe24-vs-custom-ecommerce — 쇼핑몰 플랫폼 전환 타이밍
  • /compare/native-vs-electron — 데스크톱 앱 크로스플랫폼
  • /compare/outsourcing-vs-internal-team — 개발 주체 결정
  • /compare/paper-vs-digital-catalog — 제조·B2B 카탈로그 전환

각 페이지는 "비교표 → 양쪽 유리 → 심화 분석 → 자사 사례 → 결론 → FAQ → 관련 가이드" 표준 구조. 각각 자사 사례를 반드시 한 섹션 할당해 이론과 실증을 짝지었습니다 (WebGL 에는 LG ThinQ, 카페24 에는 KM Park, Electron 에는 휴니트 + VSCode · Slack · Discord 등 유명 제품 9개, 외주에는 "외주가 메인 시스템을 감당한 사례들", 카탈로그에는 두코).

9. 내부 링크망으로 엔티티 중력 만들기

orphan 페이지(어느 페이지에서도 링크가 없는 페이지) 는 AI 엔진 인식이 약해집니다. 다음 세 경로로 링크망을 깔았습니다.

  • Footer — "대표 프로젝트" 6개 + "기술 비교 가이드" 5개 (모든 페이지 하단에서 전파).
  • Contextual 인라인 — /webgl 비교 테이블 뒤에 WebGL vs Unity, /ecommerce 에 카페24 vs 자체몰, /company FAQ 뒤에 5개 compare 전체, case study 5개에 관련 compare 인라인 링크.
  • Cross-link — 5 compare 페이지 각각 하단에 "관련 가이드" 섹션 (compare 끼리 최소 2개씩 연결).

10. ItemList · JobPosting · VideoObject — 리치 결과 확장

  • /projects ItemList — 정적 6개 + 동적 DB 프로젝트 merge. "프로덕트 메이커 포트폴리오 목록" 쿼리 대응.
  • /recruit ItemList (JobPosting 병합) — 활성 공고들을 ListItem 배열로 감싸 Google Jobs 다중 공고 노출.
  • recruit 개별 공고 JobPosting — title · description · datePosted · hiringOrganization · jobLocation · applicantLocationRequirements · employmentType · identifier 완비.
  • projects-detail YouTube 배경 VideoObject — Landing 이 heroMedia.kind === 'youtube' 감지해 자동 주입. 동적 [slug] 에서도 주입. embedUrl · contentUrl · thumbnailUrl · uploadDate 포함.

11. 블로그 · 포트폴리오 author 를 Person(Founder) 로

Organization 은 사이트 전체 publisher 로, 각 Article 의 author 는 Person(Founder) 로 구분했습니다. Founder Person 에 sameAs 를 연결해 "이 글을 쓴 사람이 누구인가" 를 AI 엔진에 명시. E-E-A-T 의 Authority · Experience 신호.

12. Canonical · Breadcrumb · format-detection

  • 모든 서비스·정적 페이지(홈 포함 11곳 이상) 에 canonical 명시. MetaDataConst 에 홈 canonical 기본값 설정 후 각 페이지에서 override.
  • board_detail 의 canonical 이 모두 board_name_title=blog 로 하드코딩돼 있던 버그 수정 — recruit · Q&A 는 자기 URL, blog 는 /blog/slug 슬러그 URL 로 정규화.
  • iOS Safari 가 "260-81-03966" 같은 하이픈 숫자를 tel: 링크로 자동 변환하며 OS 기본 링크 색(검정) 으로 덮어쓰던 이슈 → format-detection: telephone=no, date=no, address=no, email=no 루트 레이아웃에 추가.

13. AI 크롤러 명시 허용

robots.txt 에 GPTBot · ClaudeBot · PerplexityBot · GoogleBot-Extended · Amazonbot · Bytespider · CCBot · Applebot-Extended 등 11개 AI 크롤러를 Allow 로 명시했습니다. "기본은 허용이지만 명시적으로 쓰는 게 AI 업체 정책 대응에 유리" 합니다.

14. sitemap.ts 동적 통합

Next.js 의 sitemap.ts 라우트에서 정적 페이지 8 + 비교 5 + case study 6 + 동적 블로그 slug 200개 + PROJECTS 동적 slug 까지 한 번에 빌드. priority 계층화 — 홈·회사(1.0), 서비스(0.9), 프로젝트·연락처(0.8), 블로그(0.6).

15. ISR 로 TTFB 개선

동적 페이지(/projects-detail/[slug], /blog/[slug], /projects) 를 force-dynamic 에서 revalidate: 300 으로 전환. 포트폴리오·블로그 콘텐츠는 거의 수정되지 않으므로 5분 캐시로 충분. 크롤러 TTFB 체감 개선 + admin 수정은 5분 내 반영. 단 searchParams 의존하는 목록 페이지(/blog, /recruit) 는 force-dynamic 유지.

16. 모바일 UX 버그 — 스크롤 복원 · 반응형 · 폰트 자동 링크

  • cinematic 히어로(position:fixed + margin-top:100vh scroll-cover) 가 iOS Safari 에서 "Challenge 섹션이 맨 위에 노출" 되는 스크롤 복원 버그 → ScrollToTopOnMount 클라이언트 컴포넌트 + history.scrollRestoration = 'manual' 로 해결. 100vh → 100dvh 폴백 추가.
  • /projects 모바일 우측 넘침 → .projects-wrap · .more-more · .click-big 에 box-sizing: border-box.
  • iOS 가 "260-81-03966" 을 tel: 로 자동 변환하던 이슈는 위 format-detection 으로 해결.

결과 — 뭘 얻게 되나

이 작업 후 사이트는 세 가지 방식으로 AI 엔진에 노출됩니다.

  • 정의형 인용: "WebGL 이 뭐야?", "커스텀 E-Commerce 가 뭐야?" 질의에 프로덕트 메이커 페이지의 첫 문장이 그대로 인용되는 후보가 됩니다.
  • 비교·절차형 답변: "WebGL vs Unity 어떻게 선택해?" 에 HowTo step 배열이, "카페24 에서 언제 자체몰로 가야 해?" 에 FAQPage Q&A 가 AI 답변 내용의 바탕이 됩니다.
  • 사례 인용: "MAU 150만 규모 WebGL 사례" "연매출 200억 커스텀 쇼핑몰 사례" 같은 사실 기반 질의에 포트폴리오 케이스 스터디가 출처로 걸립니다.

AEO 는 "콘텐츠를 더 쓰는 것" 이 아니라 콘텐츠를 AI 가 읽을 수 있는 형태로 재구조화하는 것 입니다. 저희 사이트의 변화는 현재진행형이고, 이 글도 그 자체가 실험 대상입니다. 만약 AI 답변에서 이 포스트가 인용되는 걸 보시면 조용히 저희에게 알려 주세요.

프로덕트 메이커에 AEO 리디자인 요청

기존 사이트를 AEO 관점에서 재설계할 때 저희가 자주 하는 작업은 다음과 같습니다.

  • 사이트 현황 감사 — JSON-LD · 정의문 · 내부 링크 · 사실 정확성 · 스키마 타입 정합성 점검.
  • 엔티티 그래프 설계 — Organization · Person · Service · CreativeWork · Article 을 @id 로 엮는 구조.
  • 콘텐츠 재구조화 — 마케팅 문구를 인용 가능한 사실·수치 · 정의문으로 재작성.
  • 스키마 구현 — FAQPage · HowTo · ItemList · JobPosting · VideoObject · Breadcrumb · speakable.
  • 내부 링크망 — Footer · Contextual · Cross-link 3중 구조.
  • 포트폴리오·사례 재포지셔닝 — AI 인용 가능한 수치·사실 중심 문장.

B2B 제조·커머스·플랫폼 회사라면 최소 2~4주 프로젝트로 진행할 수 있습니다. 현황 점검·스코프 산정·견적이 필요하시면 프로젝트 상담으로 문의 주세요.


AEO, SEO, GEO, JSON-LD, Schema.org, 스키마 마크업, AI 검색, E-E-A-T, FAQPage, HowTo, ItemList, VideoObject, JobPosting, speakable, 엔티티 그래프, 정의형 문장, 내부 링크, canonical, robots.txt, 구조화 데이터, AI 인용, 답변 엔진 최적화
다른 포스팅
WebGL프로젝트 상담