스키마는 망가진다. 내가 측정한 반감기는 이렇다.

Sprint 6주차에 깔끔한 스키마 아키텍처를 출시한 팀이 있습니다. 검증기는 통과하고, AI 엔진들이 인용을 시작하고, 오가닉 매출이 올라가고, 런칭 후 리포트는 멋져 보여요. 12주가 지나면 인용 점유율은 협업 이전 수준으로 돌아가 있고, 정확히 무엇이 깨졌는지 아무도 짚을 수 없습니다.

이게 이 일에서 가장 비싼 실패 모드입니다. 스키마는 눈에 띄게 깨진 적이 없어요. 그냥 망가져 갔습니다.

여러 협업에서 충분히 데이터를 모은 끝에 이 망가짐의 타임라인에 숫자를 붙일 수 있게 됐어요. 그 숫자가 Retainer가 존재하는 이유이고, "그냥 우리가 알아서 유지할게요"라는 한 문장이 6자리수의 재작업 프로젝트로 이어진 이유입니다.

측정된 반감기: 60일에서 90일

스키마 인지형 CI 게이트 없이 매주 배포하는 팀에서, 클린한 런칭 베이스라인부터 AI 인용 점유율에 실제로 영향을 주는 첫 번째 리그레션이 발생하기까지 걸리는 시간은 60~90일입니다. 이게 유지되지 않은 스키마 아키텍처가 프로덕션에서 갖는 반감기예요.

"첫 번째 리그레션"이라 함은 다음 중 최소 하나를 깨뜨리는 변경입니다.
- @id 체인 (가장 흔히는 누군가 다른 @id 패턴으로 Organization을 발행하는 신규 템플릿을 배포하는 경우, 커머스 진단 카탈로그의 1번 버그에 기록된 그 드리프트)
- 리치 결과 자격이 있는 엔티티의 필수 필드 (가격 로직 리팩터링 이후 priceValidUntil이 빠진 Product)
- 스키마의 서버 사이드 렌더링 (개발자가 코드베이스를 "현대화"한다며 JSON-LD를 클라이언트 전용 컴포넌트로 옮기는 경우. 같은 카탈로그의 8번 버그, 가장 치명적입니다.)

깨짐은 조용히 일어납니다. 검증기는 잡지 못해요. 검증기는 문법만 봅니다. Search Console은 표면화하지 못합니다. 리치 결과 손실이 AI 엔진 레이어에서 일어나는데, 구글은 그걸 보고하지 않으니까요. 팀은 분기별 가시성 리뷰에서 알게 되는데, 그 시점엔 이미 첫 번째 리그레션 뒤로 세 개가 더 쌓여 있어요.

망가짐은 부주의가 아니라 구조적이다

스키마 리그레션은 거의 항상 부주의한 작업이 만든 게 아닙니다. 스키마와 무관한 코드 변경에서 시작돼요. 스키마가 하중 부담 레이어라는 사실을 모르는 엔지니어들이 만든 변경에서.

반복적으로 보는 패턴들:

프런트엔드 리팩터링이 컴포넌트를 클라이언트 전용 렌더링으로 옮긴다. 그 템플릿의 스키마 제너레이터는 서버 사이드였고, 페이지 단위 컴포넌트 안에 임베드되어 있었어요. 리팩터링이 페이지 단위 컴포넌트를 더 작은 조각으로 분해하면, 스키마 제너레이터가 클라이언트 전용 래퍼 안으로 끌려 들어가고, AI 엔진 페처는 그걸 더 이상 보지 못합니다. (각 AI 엔진이 클라이언트 렌더링 스키마를 다루는 방식.)

새 상품 속성이 데이터베이스에 추가된다. 마케팅이 그걸 표면에 노출하고 싶어해요. 엔지니어링은 표면 변경을 배포합니다. 아무도 그 새 필드를 포함하도록 Product 스키마를 업데이트하지 않아요. 페이지에 있는 것과 비교해 AI 엔진에 발행되는 Product 엔티티가 이제 불완전합니다. 엔진들은 부분 매치로 플래그하고 가중치를 깎아요.

다른 이유로 CMS 플러그인이 설치된다. 플러그인이 방어적 디폴트로 자체 JSON-LD를 주입합니다. 이제 페이지에 서로 다른 @id를 가진 Organization 블록이 두 개 있어요. 엔티티 머지가 실패합니다.

누군가 깔끔하게 정리한다며 여러 JSON-LD 블록을 하나로 "통합"한다. 새 구조에 둘 자리가 없어서 통합 과정에서 @id 참조를 잃어요. @graph가 이제 평평합니다.

각 경우에서 변경을 배포한 엔지니어는 스키마가 영향받았다는 걸 알 길이 없었습니다. 알 수가 없어요. 이걸 잡는 유일한 방법은 변경이 배포되기 전에 CI에서 잡는 것입니다.

검증기 스위트가 실제로 하는 일

CI에 들어간 스키마 검증기 스위트는 모든 PR에서 세 레이어의 검사를 돌립니다.

1. Schema.org 컴플라이언스. 표준 JSON-LD 검증. 잘못된 JSON, 알 수 없는 타입, 필수 필드 누락을 잡습니다.

2. 아키텍처 의사결정 기록의 커스텀 @graph 규칙. 프로젝트별 결정 사항을 인코딩합니다: 모든 Product는 정규 Brand @id를 참조한다, 모든 Article은 정규 Person @id를 참조한다, BreadcrumbList 항목은 트레일링 슬래시 URL만 사용한다. Schema.org에는 없지만 여러분이 출시한 아키텍처에는 있는 규칙들이에요.

3. 엔티티 해상도 분리 테스트. 일부 페이지를 RankLabs가 AI 엔진 추출에 쓰는 동일한 에뮬레이터를 통해 돌립니다. Product가 여전히 올바른 Brand로 해상되는지, Article 저자가 여전히 올바른 Person으로 해상되는지 확인해요.

이 중 하나라도 깨뜨리는 PR은 빌드를 실패시키며, 문제가 된 필드를 가리키는 읽기 좋은 에러를 띄웁니다. 엔지니어가 머지 전에 고쳐요. 60~90일의 망가짐 타임라인이 무의미해집니다. 리그레션이 프로덕션에 닿지 않으니까요.

이 스위트를 만드는 비용은 실재하지만 한정적입니다. 보통 Sprint 동안 며칠의 엔지니어 공수예요. 이걸 안 가졌을 때의 비용은 18개월 뒤 스키마 아키텍처 재구축으로 나타납니다.

지금 스키마가 망가지고 있는지 어떻게 알까

지난 1년 안에 스키마 작업을 출시했고 CI 검증기 스위트가 없다면, 망가지고 있어요. 질문은 얼마나, 입니다. 빠른 점검 세 가지:

오늘 상위 10개 템플릿 URL을 구글 Rich Results Test에 돌려라. 한 달 뒤 다시 돌려라. 두 실행 사이에 잃은 리치 결과 자격이 있다면 그게 망가짐입니다.

라이브 HTML과 코드베이스의 스키마 제너레이터 출력을 비교하라. 라이브 응답에서 제너레이터가 발행하는 필드가 빠져 있다면, 다운스트림 어딘가가(CDN, 캐싱 레이어, 태그 매니저) 출력을 망가뜨리고 있어요.

오늘 우선 쿼리 셋을 ChatGPT나 Perplexity에 돌리고, 60일 뒤 다시 돌려라. 이전에 이기던 쿼리에서 인용 점유율이 떨어졌다면, 스키마가 새고 있어요.

세 점검 중 하나라도 실패하면 프로덕션에 리그레션이 있는 거예요. Audit이 그걸 찾고, Sprint가 고치고, Retainer가 다시 돌아오지 않게 막습니다.

"우리가 알아서 유지할게요"가 보통 안 되는 이유

거의 모든 Sprint 클라이언트가 스키마를 직접 유지하겠다고 말해요. 4명 중 3명은 1년 안에 Retainer나 리미디에이션 Sprint를 요청하며 돌아옵니다. 이유는 능력이 아니에요. 가용 자원입니다.

스키마 리그레션 모니터링은 연속적일 때만 가치 있는 종류의 일이에요. 분기에 한 번 돌리는 팀은 5개의 리그레션을 발견해서 고칩니다. 모든 PR에서 돌리는 팀은 0개의 리그레션을 보는데, 소스에서 잡혀버리니까요. 가용 공수는 크지 않지만 연속적이고, 누군가의 분기 OKR에 들어 있지 않은 연속적 엔지니어링 작업은 떨어집니다.

Retainer가 존재하는 이유는, 스키마 작업이 제 시간이 여러분의 시간보다 큰 차이로 더 싼 일들 중 하나이기 때문이에요. 저는 매일 RankLabs를 돌리고, 리그레션 패턴은 패턴 매칭되어 있고, 3일차에 리그레션을 잡는 엔지니어링 비용은 90일차에 잡는 비용보다 한 자릿수 더 낮습니다.

스키마 작업을 출시했고 모니터링이 없다면, Retainer는 이 사이트에서 가장 지루한 결정입니다. 그리고 가장 레버리지가 높은 결정이기도 합니다.