Schema.org와 JSON-LD, 그리고 SEO 최적화의 관계

업무를 하다 보면, 어느 순간부터 늘 하던 일이 다르게 보일 때가 있다.

앞서간 사람들이 가르쳐주는 대로, 인터넷에서 찾아낸 예시대로 끙끙대면서—깊은 생각 없이—하던 작업이 있다. 그러다 그 작업이 손에 익을 즈음, 문득 퍼뜩 머릿속에 뭔가 떠오른다.

“이걸 왜 하지?” “이걸 만든 사람은 어떤 생각으로 만들었지?”

그 질문에 스스로 답을 알아낸 순간. 나는 이런 걸 소소한 깨달음이라고 부른다.

나에게는 schema.org와 JSON-LD 작성이 그랬다.

초보일 때는 그냥 “검색엔진이 이해하기 쉽게 해서 SEO를 위해” HTML 상단에 기계처럼 붙여넣던 것들이, 어느 순간부터 의미가 다르게 느껴지기 시작했다.

이 글은 내가 웹 애플리케이션을 만들다가 깨달은 schema.org의 근본적인 존재 이유, 그리고 “SEO를 넘어서” 어떻게 활용할 수 있는지에 대한 이야기다.

세상의 여러객체를 대상으로 태깅을 하고 관계를 만들고 있는 개발자의 모습

내가 깨달은 것: schema.org는 검색엔진 전용이 아니었다

이번에 schema.org 문서를 샅샅이 읽어보면서, 예전에는 잘 안 보이던 핵심이 눈에 들어왔다.

schema.org는 단지 검색엔진만을 위한 장치가 아니었다. 웹이든 아니든 상관없이, 이 세상의 어떤 대상이든(물건, 웹페이지, 사람, 조직, 사건… 뭐든) JSON 형태로 분류하고 체계화해서 전산화/데이터화하기 쉽게 만드는 “공통 스키마 약속”에 가깝다.

사실 인간은 원래 각자 방식대로 분류하고 체계를 만든다. 그런데 문제는, 누가 쓰고 누가 읽느냐에 따라 기준이 달라진다는 것. schema.org는 그 기준을 “범용적으로” 맞추기 위한 약속이었다.

그래서 나는 schema.org의 본질을 이렇게 정리하게 됐다.

Schema.org = “세상을 위한 데이터 규격”

검색엔진을 넘어, 웹상의 모든 정보를 기계가 읽을 수 있는(Machine-readable) 구조로 만들기 위한 전 세계적인 약속인 셈이다.

예를 들어, 우리는 같은 의미를 이렇게 제각각 부른다.

  • “글쓴이”
  • “Author”
  • “作成者”

하지만 schema.org에서는 이렇게 통일한다.

  • @type: Person
  • name: ...

언어가 달라도, 팀이 달라도, 시스템이 달라도 “그 의미”를 동일하게 잡아준다.

이렇게 정리되면 생기는 일: ‘관계망’이 만들어진다

schema.org를 단순히 “검색엔진용 메타데이터”로 보면, 하는 일은 그저 필드를 채우는 작업이다.

그런데 “세상의 데이터 규격”으로 보면, 갑자기 관점이 바뀐다.

객체 중심의 연결이 가능해진다

사람, 장소, 사건, 물건 같은 세상의 모든 ‘개체(Entity)’가 서로 연결된다.

  • 어떤 글의 author가 누구인지
  • 그 author가 어떤 Organization에 속하는지
  • 그 조직의 url과 sameAs가 무엇인지

이런 식으로 정보가 이어지면, 기계는 단일 페이지를 읽는 게 아니라 관계망(그래프) 을 그리기 시작한다.

데이터 전산화가 훨씬 빨라진다

객체 중심의 프로그래밍 언어가 세상을 바꿔왔듯이, 이렇게 정리된 데이터는 서비스 개발, 통합, 분석을 빠르게 만든다. 그리고 여기서 나는 혼자 소리를 질렀다.

“이게 바로… schema.org의 존재 이유였던 거구나!!!!”

그동안 나는 이걸 “검색엔진이 좋아하는 구조 만들어주는 도구” 정도로만 생각해 왔다. 이 철학을 이제야 깨닫다니.

더욱 재미있어지는 건 여기서부터다.

내부 데이터 통신 규격을 schema.org 기반으로 맞추면, 나중에 다른 서비스와 연동하거나 AI 모델에 데이터를 먹일 때도 별도의 변환 과정 없이 ‘의미’를 전달할 가능성이 커진다.

나는 이건 꽤 큰 장점이 될 거라고 확신한다.

철학을 알았으니, 이제 써보자: SEO는 “활용처 중 하나”일 뿐

철학을 깨달으면 욕심이 생긴다. “이걸 SEO만 위해 쓰기엔 너무 아깝다.”

그런데 바로 부딪히는 현실도 있다.

바로 만나게 되는 문제

  • schema.org 문서 양이 정말 어마어마하다. 전부 파악하는 건 사실상 불가능이다.
  • 종류가 너무 많다. “어떤 장르에 어떤 속성을 넣어야 하는가” 이전에 구조 자체를 잡는 게 어렵다.

그래서 나는 최소한 이것만은 정리해두면 좋겠다고 생각했다.

이것만 알아두자 1: JSON-LD에서 @ 마크의 정체

JSON-LD에서 @가 붙은 키워드는, 일반 데이터가 아니라 JSON-LD 자체의 규칙을 정의하는 메타 정보다. 내용물(name, url, image…)과, 그 내용물의 규격(@type, @context…)을 분리하기 위해 존재한다.

일단 자주 쓰는 3가지만 알고 있으면 될 것 같다.

@context: “내가 쓰는 단어의 사전은 어디야?”

"@context": "https://schema.org"

이 한 줄은 이런 선언이다.

“이제부터 내가 쓸 name, author 같은 단어는 schema.org라는 사전 정의를 따를게.”

@type: “이 데이터 덩어리의 정체는 뭐야?”

"@type": "BlogPosting"

Person, Organization, Article, Product 같은 “객체의 종류”를 지정한다.

@id: “이 객체의 고유 식별자는 뭐야?”

"@id": "https://example.com/posts/schema-org"

전 세계에서 유일하게 이 객체를 가리킬 수 있는 이름표 같은 것이다. 보통 URL을 넣는다.

정리하면 이런 느낌이다.

  • name, url 같은 키는 내용물
  • @context, @type, @id 같은 키는 그릇의 규격

이것만 알아두자 2: 어떤 장르에 어떤 속성을 넣을지 찾는 법

schema.org는 세상 모든 걸 다루려다 보니 수천 개다. 다 외우려 하면 지친다. 대신 계층 구조를 타고 내려가는 방식이 현실적이다.

1) 최상위 객체 Thing에서 시작하기

모든 객체의 조상은 Thing이다. 대부분 여기서 기본 속성을 공유한다.

  • name
  • description
  • url
  • image

그리고 가지가 갈라진다.

  • 사람인가? → Person
  • 장소인가? → Place
  • 무형의 저작물인가? → CreativeWork (블로그 포스트, 책, 영화 등)
  • 조직인가? → Organization

웹 페이지 글이라면 대체로 CreativeWork 계열에서 시작하게 된다.

2) “다 채우기”가 아니라 “핵심부터” 채우기

schema.org 페이지 하단에 보면 Properties from ... 목록이 있다. 이곳에 나온 것 위주로 채워넣되 그걸 전부 채울 필요는 없다.

처음엔 이렇게만 생각하면 편하다.

  • 검색엔진이 요구하는 필수에 가깝거나
  • 내가 이 객체를 설명하는 데 꼭 필요한 것부터

3) 가장 쉬운 길: Google 구조화 데이터 가이드를 정답지로 쓰기

schema.org 공식 문서는 방대하고, 처음엔 피로하다. 대신 구글은 웹에서 흔히 쓰는 장르별로 “이 속성은 넣어라”를 정리해 둔다.

  • 기사(Article)
  • Breadcrumb
  • Event
  • FAQ
  • Product
  • Review …같은 것들.

링크: Google 검색에서 지원하는 구조화된 데이터 마크업

웹 개발하는 사람이라면, 저 페이지는 반드시!! 즐겨찾기 해두자.

예시: BlogPosting의 최소 형태(감 잡기용)

아래는 “대충 이렇게 생겼구나”를 잡기 위한 예시다.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  "@id": "https://example.com/posts/schema-ldjson-seo",
  "headline": "Schema.org와 JSON-LD, 그리고 SEO 최적화의 관계",
  "datePublished": "2026-02-04",
  "author": {
    "@type": "Person",
    "name": "jesselab"
  }
}
</script>

이 정도만 넣어도, 이 글이 “무엇인지”, “누가 썼는지”, “언제 발행됐는지” 같은 핵심 의미가 꽤 명확해진다.

마무리: 나는 이제 schema.org를 다르게 본다

예전의 나는 schema.org를 “SEO를 위한 체크리스트”로 취급했다. 그래서 작업도 그냥 “채우기”였다.

하지만 지금은 다르다.

schema.org는 세상을 데이터로 표현하기 위한 약속이고, JSON-LD는 그 약속을 웹에 얹는 형식이며, SEO는 그 결과로 얻는 수많은 이점 중 하나일 뿐이다.

이렇게 관점이 바뀌면, “왜 해야 하는지”가 또렷해지고, 그 순간부터는 작업이 더 이상 복붙이 아니라 설계가 된다.

나에게는, 그게 이번 소소한 깨달음이었다.