구조화 데이터는 이렇게 넣습니다 — 스키마(JSON-LD) 실무

구조화 데이터가 대체 무엇인가요?

구조화 데이터는 페이지 안의 정보가 '무엇인지'를 기계가 읽을 수 있는 형식으로 따로 적어 둔 표식입니다. 화면에 보이는 글은 그대로 두고, 그 글이 회사인지·사람인지·기사인지·자주 묻는 질문인지를 Schema.org라는 공용 어휘로 명시합니다. 사람은 "Findable · 운영 오엘 · 1522-0722"를 보고 한눈에 회사·연락처를 구분하지만, 기계는 그렇지 않습니다. 구조화 데이터는 "이건 Organization, 이건 name, 이건 telephone"이라고 꼬리표를 달아 주는 일입니다.

형식은 여러 가지가 있지만 저희는 JSON-LD만 씁니다. 본문 HTML과 섞이지 않고 <script type="application/ld+json"> 블록 하나에 따로 들어가서, 디자인을 건드리지 않고 추가·수정·검증이 깔끔하기 때문입니다. 구글도 JSON-LD를 권장합니다.

왜 굳이 넣어야 하나요? 무엇이 좋아지나요?

이유는 두 갈래입니다. 첫째, 검색의 리치 결과입니다. 자주 묻는 질문을 FAQPage로 표시하면 검색 결과에서 질문이 펼쳐지는 형태로 노출될 자격이 생기고, BreadcrumbList를 넣으면 결과에 이동 경로가 함께 보입니다. 같은 순위라도 화면을 더 넓게 차지하니 눈에 띄고 클릭으로 이어집니다.

둘째, AI의 이해입니다. ChatGPT·Perplexity 같은 엔진이 페이지를 읽을 때, 본문 문장만으로 "이 회사가 무엇을 하고 누가 썼는지"를 추측하는 것보다, 구조화 데이터로 명시된 사실을 그대로 가져가는 편이 정확합니다. 저자(Person)와 발행처(Organization)가 분명한 글은 AI가 출처로 인용하기에도 안전합니다. 즉 구조화 데이터는 SEO와 GEO를 따로 두 번 하는 게 아니라, 한 번에 같이 돕는 신호입니다. GEO 쪽 작동 방식은 GEO/AEO 소개에서 더 다룹니다.

한 가지 분명히 해 둘 점 — 구조화 데이터를 넣는다고 검색 순위가 자동으로 오르지는 않습니다. 리치 결과 노출 자격과 정확한 이해를 얻는 것이지, 마크업이 순위를 사 주는 것은 아닙니다.

여러 정보를 어떻게 하나로 엮나요? — @graph

한 페이지에는 보통 여러 엔티티가 함께 있습니다. 이 글에는 발행한 회사(Organization), 쓴 사람(Person), 페이지 자체(WebPage), 글(Article), 자주 묻는 질문(FAQPage), 이동 경로(BreadcrumbList)가 모두 들어갑니다. 이들을 따로따로 흩어 놓으면 엔진은 서로의 관계를 모릅니다.

그래서 저희는 @graph 배열 하나에 이 엔티티들을 모두 담습니다. 한 그래프 안에 있으면 "이 Article의 저자는 저 Person이고, 발행처는 저 Organization"이라고 서로 가리킬 수 있습니다. 흩어진 표식이 아니라 연결된 지식 그래프로 읽히는 것 — 이게 @graph를 쓰는 이유입니다. 이런 신호를 제작 단계부터 한 흐름으로 심는 방식은 우리는 이렇게 합니다에 정리해 두었습니다.

같은 회사를 매번 다시 적어야 하나요? — @id로 연결

아닙니다. 회사 정보를 글마다 통째로 다시 적으면, 어딘가는 전화번호가 틀리고 어딘가는 이름이 다르게 적히기 마련입니다. 그래서 각 엔티티에 @id로 고유 주소를 줍니다. 예를 들어 회사는 https://find-ables.com/#org, 대표는 https://find-ables.com/#founder로 한 번만 정의합니다.

그러면 이 글의 Article에서는 회사 정보를 다시 쓰지 않고 "publisher":{"@id":"https://find-ables.com/#org"}처럼 그 @id만 참조하면 됩니다. 정보를 한 곳에서 한 번만 정의하고 모든 페이지가 그걸 가리키니, 일관성이 깨질 일이 없습니다. 이 글의 JSON-LD에서 author와 publisher가 바로 그 방식으로 #founder·#org를 참조하고 있습니다.

외부 세계와는 어떻게 연결하나요? — sameAs

@id가 사이트 안에서의 연결이라면, sameAs는 사이트 밖과의 연결입니다. sameAs에는 같은 회사·사람을 가리키는 신뢰할 수 있는 외부 주소를 넣습니다 — 회사 공식 SNS, 공개된 사업자 정보, 대표자의 링크드인 같은 것입니다. 엔진은 이 링크들을 보고 "이 Organization이 그 알려진 곳과 같다"고 확신하게 됩니다.

이 확신이 엔티티 식별과 AI 답변 내 인용에 직접 도움이 됩니다. 다만 한 가지 원칙 — 존재하지 않는 계정을 지어 넣으면 안 됩니다. sameAs는 실제로 살아 있고 우리를 가리키는 주소여야 합니다. 검증 단계에서 모두 실제로 열리는지 확인합니다.

실무에서 자주 쓰는 타입은 무엇인가요?

모든 타입을 다 넣을 필요는 없습니다. 페이지 성격에 맞는 것만 고릅니다. 저희가 가장 자주 쓰는 것들입니다.

Organization은 회사를 정의합니다(이름·로고·전화·sameAs). Person은 저자나 대표를 정의해 글의 신뢰를 받칩니다. WebPage는 페이지 자체를, Article(또는 BlogPosting)은 글의 제목·저자·발행처·발행일·대표 이미지를 담습니다. FAQPage는 자주 묻는 질문을 질문-답변 쌍으로 표시해 리치 결과 자격을 얻습니다. BreadcrumbList는 홈→인사이트→현재 글로 이어지는 이동 경로를 명시합니다. 이 글에는 이 중 Article·FAQPage·BreadcrumbList가 들어가 있고, author·publisher로 Person·Organization을 참조합니다. SEO 전반에서 이들이 어디에 놓이는지는 우리가 SEO를 하는 방식에서 다룹니다.

넣고 나면 어떻게 확인하나요?

마크업은 '넣었다'가 끝이 아니라 '맞게 들어갔다'를 확인해야 끝입니다. 저희 순서는 이렇습니다. 첫째, JSON 자체가 문법적으로 유효한지 봅니다 — 쉼표 하나가 빠지면 블록 전체가 무시되므로, 코드 단계에서 json.loads로 먼저 통과시킵니다. 둘째, 구글 리치 결과 테스트와 Schema Markup Validator에 페이지를 넣어 오류·경고를 확인합니다. 셋째, 화면에 보이는 내용과 마크업 내용이 일치하는지 봅니다.

세 번째가 특히 중요합니다. 화면에 없는 FAQ를 마크업에만 넣거나, 본문에 없는 별점을 표시하는 것은 정책 위반이고 리치 결과가 거부되거나 페널티로 이어집니다. AI 인용 신호를 어떻게 정리하는지는 llms.txt 작성 가이드와 함께 보면 도움이 됩니다.

가장 흔한 실수는 무엇인가요?

현장에서 반복적으로 보는 실수들입니다. ① 화면과 마크업 불일치 — 보이지 않는 정보를 표식에만 넣는 것. ② 날조된 sameAs·수치 — 없는 SNS나 근거 없는 별점·후기 수를 적는 것. ③ 엔티티 미연결 — Article·Person·Organization을 각각 넣고도 @id로 묶지 않아, 엔진이 "누가 쓴 글인지" 연결하지 못하는 것. ④ JSON 문법 오류 — 따옴표·쉼표 실수로 블록 전체가 통째로 무시되는 것. ⑤ 검증 생략 — 넣고 확인하지 않아 몇 달째 잘못된 마크업이 방치되는 것.

저희는 이 다섯 가지를 체크리스트로 두고, 모든 페이지에 @graph·@id 연결과 검증 통과를 기본값으로 적용합니다. 지금 사이트의 구조화 데이터 상태가 궁금하다면 무료 진단으로 점검부터 받으시면 됩니다.

위에서 Article 한 조각만 보여드렸으니, 제가 실제로 페이지에 심는 @graph 연결 형태를 통째로 보여드리겠습니다 — Article이 author·publisher를 @id로 가리키는 부분이 핵심입니다.

{
  "@context": "https://schema.org",
  "@graph": [
    { "@type": "Organization",
      "@id": "https://example.com/#org",
      "name": "회사명",
      "sameAs": ["https://www.linkedin.com/company/회사"] },
    { "@type": "Person",
      "@id": "https://example.com/#founder",
      "name": "저자명" },
    { "@type": "Article",
      "@id": "https://example.com/post#article",
      "headline": "글 제목",
      "author":    { "@id": "https://example.com/#founder" },
      "publisher": { "@id": "https://example.com/#org" },
      "datePublished": "2026-06-24" }
  ]
}

페이지마다 어떤 타입을 고를지 헷갈릴 때 제가 쓰는 판단표입니다 — 타입은 ‘페이지의 정체’에 맞춰 고르면 됩니다.