스키마는 장식이 아니라 번역입니다

스키마는 본문에 없는 정보를 만들어내지 못합니다. 저자가 누구인지, 언제 수정했는지, 무엇을 다루는 글인지를 기계가 오해 없이 읽을 수 있는 형식으로 옮겨 적는 일입니다. 사람은 문장 속에서 "지난달에 내용을 고쳤습니다"를 읽어냅니다. 기계에게는 그 사실이 날짜 필드로 놓여 있을 때 훨씬 분명해집니다.

그래서 스키마를 붙이면 순위가 오른다는 기대는 어긋납니다. 번역을 잘하면 원문이 좋아지는 것이 아니라, 원문이 가진 값이 더 정확하게 전달됩니다. 좋은 글에 스키마를 붙이면 그 글이 무엇인지 덜 오해받습니다. 부실한 글에 스키마를 붙이면 부실함이 더 정확하게 전달됩니다.

이 관점이 실무에서 바꾸는 것은 순서입니다. 스키마를 먼저 설치하고 본문을 나중에 채우는 방식은 번역문을 먼저 쓰고 원문을 맞추는 셈입니다. 본문에서 저자와 수정 이력을 성실하게 밝힌 다음, 그것을 필드로 옮기는 순서가 맞습니다.

오역이 생기는 자리

기술적으로 문법이 맞는 스키마도 틀릴 수 있습니다. 형식 오류가 아니라 본문과 다른 말을 하는 경우입니다.

흔한 경우는 자동 생성입니다. 플러그인이 발행일을 수정일 필드에 함께 넣으면, 3년 전 글이 매번 갱신된 글처럼 표시됩니다. 본문은 아무것도 주장하지 않았는데 스키마가 사실과 다른 말을 하고 있는 상태입니다.

작성자 정보도 자주 어긋납니다. 본문에는 필자 이름이 없는데 스키마에는 조직명이 저자로 들어가는 식입니다. 문법 오류는 없지만, 본문이 밝히지 않은 것을 스키마가 대신 주장하는 셈이 됩니다.

가장 위험한 것은 평점과 리뷰입니다. 실제 수집한 평가가 없는데 별점 필드를 채우면, 검색 결과에는 별이 표시되고 본문에는 근거가 없습니다. 이것은 최적화 기법이 아니라 사실과 다른 표시입니다.

원문과 번역문을 나란히 두면

본문에서 한 말과 스키마 필드가 같은지 확인하는 것이 점검의 핵심입니다.

{
  "@type": "Article",
  "headline": "스키마는 장식이 아니라 번역입니다",
  "author": { "@type": "Person", "name": "필자 이름" },
  "datePublished": "2026-03-02",
  "dateModified": "2026-03-02"
}

이 네 줄이 주장하는 것은 단순합니다. 제목이 이것이고, 이 사람이 썼고, 이 날 발행했고, 아직 고치지 않았다는 사실입니다. 본문에 필자 이름이 없다면 author는 옮길 원문이 없는 문장입니다. 고친 적이 없다면 dateModified는 발행일과 같아야 합니다.

번역 점검표

자주 묻는 질문

스키마를 넣으면 검색에 더 잘 노출됩니까

노출 형태가 달라질 수 있지만 순위가 오른다고 보기는 어렵습니다. 스키마는 이 글이 무엇인지 덜 오해받게 하는 장치이고, 무엇인지 자체를 바꾸지는 못합니다.

플러그인 자동 생성으로 충분하지 않습니까

출발점으로는 유용합니다. 다만 자동 생성은 본문을 읽지 않고 규칙대로 채우기 때문에, 수정일이나 작성자처럼 사실 여부가 걸린 필드에서 어긋나기 쉽습니다. 설치한 뒤 한 번은 사람이 읽어봐야 합니다.

필드를 최대한 많이 채우는 편이 유리합니까

채울 근거가 있는 것만 채우는 편이 낫습니다. 빈 필드는 정보가 없다는 사실을 정확히 전달하지만, 근거 없이 채운 필드는 사실과 다른 말을 전달합니다. 후자가 더 큰 손실입니다.

어떤 타입부터 넣어야 합니까

글을 쓰는 매체라면 Article 계열 하나로 시작하는 것으로 충분합니다. 타입을 늘리는 것보다 한 타입의 필드가 본문과 어긋나지 않는 상태를 만드는 편이 먼저입니다.

남는 이야기

스키마를 번역으로 보면 점검할 것이 줄어듭니다. 문법을 외우는 대신 본문과 대조하면 되고, 확신이 없는 필드는 비워두면 됩니다. 기계에게 더 잘 보이려는 노력이 사실을 부풀리는 쪽으로 기울지 않게 하는 기준도 여기서 나옵니다. 번역자는 원문에 없는 말을 지어내지 않습니다.

출처

이 글은 원리를 설명하는 글이라 외부 인용을 넣지 않았습니다.