CMS 설계에서 metadata SSoT를 어떻게 다룰 것인가

검색엔진은 생각보다 많은 메타데이터를 읽는다. * title * canonical * og:title * og:site_name * JSON-LD * favicon * webmanifest * structured data 그리고 대부분의 CMS는 시간이 지나면서 이 메타데이터들이 여러 설정 화면으로 분산된다. 처음에는 단순하다. 사이트 이름 하나만 있으면 된다. 하지만 운영 기능이 추가되기 시작하면 다음과 같은 필드가 생긴다. * SEO 전용 사이트 이름 * Open Graph 전용 이름 * 앱 설치 이름 * 모바일 short name * Twitter 카드 이름 * JSON-LD name * organization title 문제는 여기서부터 시작된다. --- 메타데이터 문제의 본질은 렌더링이 아니다 대부분의 경우 메타데이터 문제는 렌더링 버그가 아니다. 실제 문제는: "동일 개념이 여러 설정으로 분산되는 것" 이다. 예를 들어: * 사이트 이름 → Example Platform * OG 사이트 이름 → ExampleHub * WebManifest Name → Example App * JSON-LD WebSite Name → Example Platform Hub 이런 상태가 가능해진다. 기술적으로는 모두 정상일 수 있다. 하지만 운영 관점에서는 이미 Drift가 시작된 상태다. --- Drift는 시간이 지나면서 발생한다 초기 운영에서는 대부분 문제가 없다. 운영자는 같은 값을 넣는다. 하지만 시간이 지나면 다음 상황들이 생긴다. * 브랜드명 변경 * 서비스 축약명 도입 * SEO 담당자 변경 * 운영자 교체 * 다국어 정책 변경 * 앱 설치명 수정 * SNS 공유명 최적화 그리고 어느 순간: * canonical title * og:site_name * JSON-LD WebSite.name * manifest.name 이 서로 달라진다. 운영자는 왜 달라졌는지 모른다. CMS는 각 설정을 독립 기능처럼 보여주기 때문이다. --- 검색엔진은 "한 개의 진실"을 좋아한다 Google은 site name을 강제로 등록하게 하지 않는다. 대신 여러 신호를 읽는다. * title * og:site_name * structured data * heading * homepage consistency 그리고 이 신호들이 일관될수록 신뢰도가 올라간다. 즉 검색엔진 입장에서 중요한 것은: "정확히 어떤 값을 쓰느냐" 보다: "여러 신호가 같은 의미를 말하고 있는가" 에 가깝다. 그래서 CMS 설계에서도 중요한 건 기능 개수가 아니라: "메타데이터의 Single Source of Truth" 이다. --- SSoT가 없는 CMS는 결국 설정 관리 시스템이 된다 많은 CMS들이 시간이 지나면 이런 상태가 된다. * SEO 설정 * OG 설정 * SNS 설정 * 앱 설정 * 구조화 데이터 설정 * PWA 설정 그리고 각각이 독립적으로 사이트 이름을 가진다. 이 구조는 단기적으로는 유연해 보인다. 하지만 장기 운영에서는: * 설정 drift * 브랜딩 불일치 * 운영자 혼란 * 검색 결과 불일치 * SNS preview mismatch 를 만든다. 결국 CMS가 콘텐츠 시스템이 아니라: "중복 설정 관리자" 가 된다. --- 가장 중요한 건 "override의 의미를 명확히 하는 것" 실제로는 override 자체가 문제는 아니다. 문제는: * override인지 * 독립 설정인지 * fallback인지 구분되지 않는 것이다. 예를 들어: OG Site Name Override (optional) 는 의미가 명확하다. 하지만 단순히: OG 사이트 이름 만 존재하면 운영자는: "이게 별도의 공식 사이트 이름인가?" 라고 이해할 수 있다. 즉 CMS 설계에서는: * override인지 * fallback인지 * primary source인지 를 운영 UI에서도 드러내야 한다. --- 가장 안정적인 구조 실무적으로 가장 안정적인 구조는 대부분 다음 형태다. og_site_name ?? general.site_name 즉: * 기본 공개 사이트 이름은 하나만 존재 * 특수한 경우만 override 허용 * 기본적으로는 자동 fallback 이 구조가 drift를 가장 잘 막는다. --- 메타데이터는 SEO 기능이 아니라 운영 구조다 많은 사람들이 metadata를 SEO 기능으로만 본다. 하지만 실제 운영에서는: * 검색엔진 * SNS preview * PWA * 앱 설치명 * structured data * crawler identity * 공유 링크 까지 모두 연결된다. 즉 metadata는 단순 HTML tag가 아니라: "플랫폼의 공개 정체성 레이어" 에 가깝다. 그래서 CMS에서 metadata 설계는: * 렌더링 문제 * SEO 옵션 추가 * 설정 개수 증가 보다: "어떤 값을 플랫폼의 기준 정체성으로 삼을 것인가" 를 먼저 결정해야 한다. 그리고 그 이후에만 override가 존재해야 한다. 그 순서가 뒤집히면, 운영 규모가 커질수록 metadata drift는 반드시 발생한다.