스키마를 깔았는데
Search Console에 "경고"가 떴다

구조화 데이터를 잘 넣으면 검색·AI가 우리를 더 잘 이해합니다. 맞는 말입니다. 그래서 우리도 조직·저자·서비스 스키마를 페이지마다 빠짐없이 넣었습니다. 그런데 어느 날 Search Console 리치 결과 점검에서 구조화 데이터 관련 이상 신호(경고)가 관측됐습니다.

솔직히 말하면 — 구글은 “항목에 문제가 있다”까지만 알려 줍니다. 무엇이 왜 문제인지는 말해 주지 않습니다. 그래서 Search Console·리치 결과 테스트·페이지 JSON-LD를 함께 대조하며 원인을 추적했습니다. 그 끝에 찾은 가장 유력한 원인은 — 같은 조직 @id에 이름이 둘(“넥스트티” / “(주)넥스트티”)로 섞여 있던 점이었습니다. 구글이 준 건 신호, 진단은 우리 몫 — 디버깅의 진짜 일은 그 “왜?”를 추적하는 데 있습니다.

스키마를 안 넣어서 생긴 문제가 아니었습니다. 넣긴 넣었는데, 같은 대상을 페이지마다 다르게 적은 것이 문제였습니다. 사람 눈엔 "넥스트티"나 "(주)넥스트티"나 같은 회사지만, 기계가 읽는 표식에서는 그 한 글자 차이가 "다른 대상일 수 있다"는 신호가 됩니다.

이 글은 그 신호를 어떻게 발견하고, 원인을 찾고, 25개 페이지를 어떻게 고쳤는지를 그대로 적은 현장 기록입니다. 일반론이 아니라, 우리가 실제로 겪고 고친 일입니다.

2026년 5월, 사이트를 점검하다 한 가지가 눈에 걸렸습니다. 우리 회사를 가리키는 조직 엔티티는 분명 하나의 @id(예: …/#organization)로 묶여 있는데, 그 엔티티의 이름표가 페이지마다 달랐습니다. 특히 저자 정보의 '소속(worksFor)'에 법인명을 적어 둔 흔적이 25개 페이지에 퍼져 있었습니다 — 한 페이지의 단발 실수가 아니라, 공통 틀을 타고 같은 이름이 다르게 적힌 문제였습니다.

검색엔진과 AI는 @id를 보고 "이건 같은 대상"이라고 묶습니다. 그런데 같은 @id에 이름이 둘이면, 구조를 읽는 쪽에서 같은 회사인지 확신하기 어려워질 수 있습니다. knowledge-graph 글에서 말한 개체 해소(같은 대상인지 구분하는 일)가 바로 이 지점에서 흔들립니다. 물론 @id만으로 같은 대상을 잘 연결하는 경우도 많습니다 — 다만 이름 신호가 흔들리면 그 연결의 확신도가 낮아질 수 있습니다.

// ✗ 잘못 — 같은 @id 인데 name 이 둘
{ "@type": "Person", "name": "홍은표",
  "worksFor": { "@id": "…/#organization", "name": "(주)넥스트티" } }

{ "@type": "Organization", "@id": "…/#organization",
  "name": "넥스트티" }
// → 받는 쪽: "넥스트티" 와 "(주)넥스트티" … 같은 회사 맞아?

// ✓ 올바름 — @id 가 같으면 name 도 한 가지로
{ "@type": "Organization", "@id": "…/#organization",
  "name": "넥스트티",            // 표시 이름은 하나로 통일
  "legalName": "(주)넥스트티",     // 법인 정식명칭은 따로
  "alternateName": ["NXT", "Next-T"] }  // 별칭은 영문만

방법은 단순합니다. 페이지를 하나씩 열어 보는 게 아니라, 사이트 전체에서 조직 name 표기를 한 번에 모은 뒤 값이 두 종류 이상이면 그게 범인입니다.

// 의사코드 — 페이지를 도는 게 아니라 "표기를 모은다"
names = []
for page in allPages:
  for node in page.jsonld:
    if node["@id"] == "…/#organization":
      names.push(node["name"])

unique = dedupe(names)
if unique.length > 1:        // 종류가 2개 이상이면 불일치
  report(unique)            // → ["넥스트티", "(주)넥스트티"]

핵심은 "페이지를 도는" 게 아니라 "표기를 모아 종류를 세는" 점검이라는 점 — 사이트가 커질수록 이 방식이라야 잡힙니다.

관측된 결과 — 통일 후 이름 충돌 신호는 사라졌습니다. 다만 여기까지가 관측된 사실이고, 이걸로 순위가 올랐다거나 트래픽이 늘었다고는 말하지 않습니다. 우리가 본 것만 책임집니다 — 측정의 경계를 지킵니다.

대부분의 업체는 “스키마 넣어드립니다”에서 끝납니다. 그런데 검사 도구에서 정상이라고, 검색·AI가 같은 의미로 읽는 건 아닙니다. 그래서 넥스트티는 “넣었는가”가 아니라 “실제로 읽히고 연결되는가”를 확인합니다. 무엇보다 — 대부분은 페이지 한 장을 검사하지만, 우리는 사이트 전체에서 ‘같은 대상을 같은 이름으로 쓰고 있는지’를 한꺼번에 봅니다. 페이지 한 장의 오류보다 더 위험한 건, 사이트 전체에서 같은 대상이 조금씩 다르게 쓰이며 쌓이는 누적 오류라고 보기 때문입니다.

그리고 우리는 “AI가 이해했을 것”이라고 주장하지 않습니다. 구조 신호·수집 기록·이름 일관성(같은 대상을 같은 이름으로 쓰는지)을 함께 보고, 측정 가능한 것만 말합니다 — 추정과 측정을 섞지 않는 것, 그게 넥스트티의 방식입니다.

그래서 차이는 — 구조화 데이터는 ‘설치’의 문제가 아니라 ‘이해’의 문제입니다. 넣는 건 누구나 합니다. 왜 안 읽히는지 찾아 고치는 일은 측정 없이는 안 됩니다 — 그게 넥스트티가 하는 일입니다.

CONCLUSION

구조화 데이터는 ‘설치’가 아니라 ‘이해’의 문제입니다.

검사에서 정상이라고 검색·AI가 같은 의미로 이해하는 건 아닙니다. 중요한 건 넣었는가가 아니라 실제로 읽히고 연결되는가입니다. 넣는 데서 끝나지 않고 읽히는지까지 보는 것 — 그게 이 글이 말하려던 전부입니다.