Context
풀어야 했던 문제.
배경
2024년에 FAQ·회사 정보·아티클 구조화 데이터를 페이지 단위로 적용한 뒤, 컴포넌트가 스키마를 직접 생성하는 구조(JSON Renderer)로 전환하는 과제가 시작됐습니다.
생성형 검색(GEO) 대응까지 목표에 포함됐습니다.
문제 정의
글로벌·중국·일본·한국 4개 도메인의 언어 구조와 주요 검색 엔진(Google/Baidu)이 달라, 스키마 타입·필드 정책이 제각각이 될 위험이 있었습니다.
HTML 메타태그·Open Graph·Schema.org 사이의 제목·설명·이미지 불일치도 정리되지 않은 상태였습니다.
제약사항
기존 컴포넌트를 병행 운영하면서 점진적으로 교체해야 했습니다.
Phase 1(1분기)·Phase 2(2분기) 일정 안에서 기획 담당 산출물 8개를 SEO팀·개발팀·QA팀 작업과 맞물려 진행해야 했습니다.
Insight
핵심 판단.
- 01GEO는 SEO의 확장입니다. 페이지가 아니라 컴포넌트가 스키마를 만들어야 다국어·대량 페이지에서 정합성이 유지됩니다.
- 02hreflang·canonical·스키마의 @id/url/inLanguage를 한 정책으로 묶지 않으면 언어별 스키마가 서로 모순됩니다.
- 03리치 리절트 우선순위(FAQ·Product·Breadcrumb)는 도메인별 검색 엔진에 따라 다르게 잡아야 합니다.
Solution
제가 맡아 해낸 일.
기획 담당 산출물 8개를 정의하고 마감일을 일정화했습니다. AEM↔Schema 필드 매핑 테이블과 JSON-LD 샘플, 메타데이터 자동화 규칙서, 다국어 스키마 정의, 파일럿·롤아웃 계획, HTML 영향도 분석, hreflang/canonical 자동화 설계, QA 검증 프로세스, SEO 영향도 측정 기준입니다.
SEO팀과는 스키마 검증·메타데이터 통합·다국어·영향도·마이그레이션·hreflang·모니터링·롤아웃 8개 협력 항목의 확인 포인트를 문서로 합의했습니다.
Phase 1은 JSON Renderer와 기본 스키마 적용, Phase 2는 A/B 검증과 버전 병행을 통한 컴포넌트 점진 교체로 추진 구조를 설계했습니다.
함께한 조직
고객사 SEO팀, AEM 개발팀, QA팀, 웹 기획팀
화면·기획 자료
스키마 적용 대상 페이지 유형의 현재 공식 사이트 참고 화면입니다.
삼성 반도체 FAQ 페이지
구조화 데이터 적용 대상 페이지 유형(FAQ)의 참고 화면 · 2026.09.12 캡처. 매핑 명세와 규칙서는 내부 자료로 제외했습니다.
Performance
범위와 성과.
기획 담당 8개 산출물 · 4개 도메인 다국어 정책
기획 범위
Phase 1 JSON Renderer → Phase 2 컴포넌트 점진 교체
추진 구조
이 프로젝트에서 얻은 것
- 01구조화 데이터는 한 번 적용하는 작업이 아니라 콘텐츠 생성 구조에 넣어야 하는 규칙입니다.
- 02다국어 사이트의 SEO/GEO 정책은 언어·도메인·검색 엔진 세 축을 한 표에서 결정해야 합니다.
- 03협력 항목을 "확인 포인트" 단위로 쪼개 문서화하면 팀 간 합의가 회의가 아닌 체크리스트로 진행됩니다.