🕸️

엔티티 및 시맨틱 SEO

키워드에서 엔티티로 전환하라 — Google 지식 그래프가 당신이 누구이고 무엇을 다루는지 이해하도록 돕는 법.

📖 13 분 읽기 🕑 업데이트 2026-06-22

검색 역사의 대부분 동안 Google은 문자열 매칭 기계였다. cheapest flights to tokyo라고 입력하면, 엔진은 그 정확한 문자열을 포함하는 문서를 찾았다. 그에 따라 SEO는 올바른 문자열을 올바른 위치에 배치하는 게임이었다. title 태그, H1, 앵커 텍스트, 그리고 — 좋지 않던 옛 시절에는 — 키워드로 도배된 푸터까지.

그 세계는 사라졌다. 2012년 지식 그래프(Knowledge Graph)가 출시되고 2013년 허밍버드(Hummingbird) 업데이트가 랭킹 파이프라인을 재구성한 이래로, Google은 *문자열(strings)*에서 *사물(things)*로 이동해 왔다. 발표 당시의 공식 표현은 글자 그대로였다. “things, not strings.” 현대의 Google은 “어떤 페이지가 이 단어들을 포함하는가”를 묻는 대신, “이 쿼리는 어떤 실세계 엔티티에 관한 것이며, 어떤 페이지가 그 엔티티에 대한 권위 있는 출처인가”를 묻는다.

이 전환은 2026년 고급 SEO에서 가장 중요한 단 하나의 사고 모델이다. 여전히 키워드로 생각한다면, 당신은 더 이상 존재하지 않는 엔진을 위해 최적화하고 있는 것이다. 이 가이드는 키워드 대신 엔티티로 생각하고 — 그리고 마크업하는 — 법을 보여준다.

엔티티 vs 키워드

키워드는 텍스트 문자열이다. 엔티티는 사물이다 — 사람, 조직, 장소, 제품, 개념, 또는 이벤트 — 어떤 특정한 표현 방식과도 무관하게 존재하는 것이다.

엔티티 *팀 버너스리(Tim Berners-Lee)*를 보자. 키워드 tim berners-lee, inventor of the world wide web, creator of HTTP, TBL은 모두 같은 엔티티를 가리킨다. Google은 이들을 지식 그래프의 한 노드로 해소(resolve)하고, 기계가 읽을 수 있는 ID(/m/07d5b 같은 지식 그래프 MID, 또는 Q80 같은 Wikidata QID)를 할당하며, 다른 엔티티들과 연결한다. 월드 와이드 웹, CERN, MIT, W3C.

차이를 한 표로 정리하면 다음과 같다.

측면키워드(문자열)엔티티(사물)
본질문자의 나열안정적인 ID를 가진 실세계 개념
정체성nyc ≠ new york citynyc = new york city = Q60
모호성”Jaguar”는 하나의 문자열동물 vs 자동차 vs OS — 세 개의 엔티티
관계본질적으로 없음그래프 안에서 연결됨(isA, partOf, worksFor)
Google의 활용 방식어휘적 매칭명확화 + 추론 + 검색

🧑‍💻 개발자 관점: 키워드를 원시 string 입력으로, 엔티티를 해소된 외래 키(foreign key)로 생각하라. 검색은 예전엔 WHERE body LIKE '%term%'였다. 이제는 그 앞에 엔티티 해소(entity-resolution) 계층이 있다 — 쿼리 문자열은 엔티티 ID로 파싱되고, 랭킹은 부분적으로 그 ID들의 그래프 위에서 일어난다. 당신의 일은 자신의 페이지를 올바른 노드에 깔끔하게 *조인 가능(joinable)*하게 만드는 것이다.

이것이 실무에서 왜 중요한가?

  • 명확화(Disambiguation). Google이 “Python”에 관한 당신의 페이지가 뱀(Q472)이 아니라 프로그래밍 언어(Q28865)에 관한 것임을 이해하면, 무관한 SERP에서 경쟁하기를 멈추고 당신이 속해야 할 곳에서 랭킹되기 시작한다.
  • 동의어 및 의도 커버리지. 이제 열다섯 가지 키워드 변형을 반복할 필요가 없다. 엔티티를 잘 다루면, 그 엔티티로 해소되는 문자열 클러스터 전체에 대해 랭킹된다.
  • 추론(Reasoning). Google은 React, JSX, 훅(hooks), 가상 DOM을 다루는 페이지가 프런트엔드 프레임워크에 대한 진정한 권위자임을 추론할 수 있다. 그 엔티티들이 그래프상의 이웃이기 때문이다. 키워드 밀도로는 이것을 위조할 수 없다.

엔티티가 되기

첫 번째 전략적 수는 당신 자신 — 당신의 브랜드와 저자들 — 을 Google이 인식하는 엔티티로 만드는 것이다. 인식되지 않은 브랜드는 추론 계층에 보이지 않는다. 그저 또 하나의 문자열일 뿐이다. 인식된 엔티티는 지식 패널(Knowledge Panel)을 얻고, 신뢰 신호(E-E-A-T의 “T”)를 획득하며, 출처로 인용될 자격을 갖춘다.

Google은 웹 전반의 상호 입증 증거로부터 엔티티를 구축한다. 당신의 일은 일관되고, 기계가 읽을 수 있으며, 상호 참조되는 신호를 Google에 공급하는 것이다. 가장 중요한 세 가지 지렛대가 있다.

1. sameAs — 당신의 엔티티를 알려진 권위와 연결하라

schema.org 마크업의 sameAs 속성은 “이 페이지의 엔티티는 당신이 이미 신뢰하는 이 노드와 동일하다”라고 말하는 가장 직접적인 방법이다. Wikidata, Wikipedia, LinkedIn, GitHub, Crunchbase, 그리고 공식 소셜 프로필을 가리키게 하라. Wikidata와 Wikipedia는 Google의 지식 그래프가 부분적으로 그것들로부터 시드(seed)되기 때문에 가장 가치가 높은 대상이다.

다음은 가상의 개발자 도구 회사를 위한 Organization 마크업이다. JSON-LD로 <head>나 </body> 직전에, 이상적으로는 홈페이지와 소개(About) 페이지에 넣어라.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://acme.dev/#organization",
  "name": "Acme Dev Tools",
  "url": "https://acme.dev/",
  "logo": "https://acme.dev/logo.png",
  "foundingDate": "2019-04-01",
  "description": "Acme builds open-source observability tooling for distributed systems.",
  "sameAs": [
    "https://www.wikidata.org/wiki/Q123456789",
    "https://en.wikipedia.org/wiki/Acme_Dev_Tools",
    "https://www.linkedin.com/company/acme-dev-tools",
    "https://github.com/acme-dev",
    "https://www.crunchbase.com/organization/acme-dev-tools",
    "https://x.com/acmedev"
  ]
}
</script>

그리고 저자를 위한 그에 대응하는 Person 마크업이다 — 저자가 조직에 worksFor하면서 두 엔티티를 서로 엮는 방식에 주목하라.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Person",
  "@id": "https://acme.dev/team/jane-doe/#person",
  "name": "Jane Doe",
  "jobTitle": "Principal Engineer",
  "worksFor": { "@id": "https://acme.dev/#organization" },
  "url": "https://acme.dev/team/jane-doe/",
  "knowsAbout": ["Distributed tracing", "OpenTelemetry", "Go"],
  "sameAs": [
    "https://www.linkedin.com/in/janedoe",
    "https://github.com/janedoe",
    "https://orcid.org/0000-0002-1825-0097"
  ]
}
</script>

💡 팁: @id 값은 당신의 스키마 그래프가 스스로를 참조하게 해주는 내부 앵커다. #organization 같은 안정적인 URL 프래그먼트를 사용하면, Article, Person, BreadcrumbList 블록이 조직을 재정의하는 대신 모두 하나의 정규(canonical) 조직 노드로 되짚어 가리킬 수 있다. 이것이 바로 그래프를 모델링해야 하는 방식이다 — 한 번 정의하고, 어디서나 참조하라.

2. about / mentions — 콘텐츠가 무엇을 다루는지 선언하라

about은 “이 페이지는 주로 엔티티 X에 관한 것이다”라고 말한다. mentions는 “이 페이지는 엔티티 Y를 언급한다”라고 말한다. 모호함이 없도록 실제 엔티티 ID를 사용하라.

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "OpenTelemetry vs Jaeger: choosing a tracing backend",
  "author": { "@id": "https://acme.dev/team/jane-doe/#person" },
  "publisher": { "@id": "https://acme.dev/#organization" },
  "about": {
    "@type": "Thing",
    "name": "OpenTelemetry",
    "sameAs": "https://www.wikidata.org/wiki/Q98961422"
  },
  "mentions": [
    { "@type": "SoftwareApplication", "name": "Jaeger",
      "sameAs": "https://www.wikidata.org/wiki/Q60803298" },
    { "@type": "Thing", "name": "Distributed tracing",
      "sameAs": "https://www.wikidata.org/wiki/Q105749746" }
  ]
}
</script>

3. 일관된 NAP와 명명

NAP — Name(이름), Address(주소), Phone(전화번호) — 는 어디서나 바이트 단위로 동일해야 한다. 당신의 사이트, Google Business Profile, LinkedIn, Crunchbase, 디렉터리까지. 일관되지 않은 NAP는 당신의 엔티티를 약하게 뒷받침되는 여러 후보로 쪼개고, Google이 이들을 병합하지 못할 수 있다. 당신의 정규 엔티티 정보(facts)를 설정 파일 안의 단일 진실 공급원(single source of truth)처럼 다뤄라.

# entity.yml — the one place your NAP lives; render everything from this
name:    "Acme Dev Tools, Inc."
url:     "https://acme.dev/"
phone:   "+1-415-555-0142"
address:
  street:  "500 Howard St, Suite 400"
  city:    "San Francisco"
  region:  "CA"
  postal:  "94105"
  country: "US"

⚠️ 주의: “Acme Dev Tools” vs “Acme Dev Tools, Inc.” vs “ACME”는 순진한 매처에게는 세 개의 서로 다른 문자열이다. 하나의 법적 명칭과 하나의 통용 명칭을 골라 일관되게 사용하라. 같은 규율이 당신의 도메인에도 적용된다. 의도적인 리디렉션 전략이 없다면 acme.dev, acme.io, getacme.com에 브랜드 권위를 분산시키지 마라.

토픽 권위

엔티티는 홀로 존재하지 않는다 — 클러스터 안에서 산다. OpenTelemetry는 분산 추적(distributed tracing), 스팬(spans), OTLP 프로토콜, Prometheus, 샘플링 전략, *계측 라이브러리(instrumentation libraries)*와 연결되어 있다. **토픽 권위(Topical authority)**란 하나의 굵은 키워드로 랭킹되는 것이 아니라, 그 엔티티 이웃 전체와 사용자가 그것에 대해 묻는 질문들을 입증 가능하게 다루는 것을 뜻한다.

옛 키워드 플레이북은 각각 하나의 구절을 노리는 열 개의 얄팍한 페이지(opentelemetry tutorial, opentelemetry vs jaeger, opentelemetry python…)를 만들어냈고, 종종 서로 잠식했다. 엔티티 플레이북은 콘텐츠 클러스터를 만들어낸다. 하나의 포괄적인 필러(pillar)와 상호 링크된 보조 페이지들이 함께, 의미 있는 모든 하위 엔티티와 하위 질문을 다룬다.

키워드 접근엔티티 / 토픽 접근
기획 단위검색 구절토픽과 그 하위 엔티티
페이지 수 논리키워드당 한 페이지지식 맵에 매핑된 페이지
내부 링크무작위 / 관련성에 대한 직감엔티티 관계를 중심으로 구조화
성공 지표그 키워드로 랭킹SERP 전반에서 토픽을 장악
위험잠식, 얄팍한 콘텐츠커버리지 공백

맵을 구축하려면, Google이 이미 당신의 토픽과 연관 짓는 엔티티들을 캐내라.

  • People Also Ask 박스와 “관련 검색어(Related searches)” — 각각은 사실상 하나의 하위 질문 또는 하위 엔티티다.
  • 핵심 엔티티에 대한 Wikipedia의 목차와 “See also” — 무료이며 사람이 큐레이션한 엔티티 그래프다.
  • Wikidata의 속성 패널 — 실제 그래프 엣지(subclass of, uses, has part)다.
  • 관련 지식 그래프 엔티티의 빠른 프로그래밍적 추출.
curl -s "https://kgsearch.googleapis.com/v1/entities:search" \
  --data-urlencode "query=OpenTelemetry" \
  --data-urlencode "types=Thing" \
  --data-urlencode "limit=10" \
  --data-urlencode "key=$GOOGLE_KG_API_KEY" -G \
  | jq '.itemListElement[].result | {name, id: ."@id", desc: .description}'

💡 팁: 유용한 경험칙 — 어떤 토픽에서 권위를 얻으려면, 당신의 클러스터는 박식한 동료가 30분짜리 대화에서 그것에 관해 물을 수 있는 모든 질문에 답해야 한다. 어떤 하위 질문에 해당하는 페이지도 섹션도 없다면, 그것은 경쟁자가 채울 커버리지 공백이다.

보상은 복리로 불어난다. 일단 Google이 당신을 분산 추적의 권위자로 신뢰하면, 그 클러스터의 새 페이지들은 더 빨리 랭킹된다. 신뢰가 개별 URL이 아니라 토픽 내의 당신의 엔티티에 붙기 때문이다.

실전 단계

처음부터 끝까지의 워크플로다. 각 단계는 티켓에 올릴 수 있을 만큼 구체적이다.

1. 엔티티 인벤토리를 작성하라. 당신의 사이트가 무엇인지에 해당하는 엔티티(브랜드, 제품, 저자, 위치)와, 당신이 권위자가 되고 싶은 엔티티(핵심 토픽과 그 하위 엔티티)를 나열하라. 각각에 대해 정규 참조처를 찾거나 만들어라 — 존재한다면 Wikidata QID, 없다면 내부 @id를.

We ARE:        Acme Dev Tools (Q123456789), Jane Doe (no QID → /team/jane-doe/#person)
We OWN:        distributed tracing, OpenTelemetry, observability, OTLP, span sampling
Gaps to fill:  span sampling (no page), OTLP (only a passing mention)

2. 엔티티를 스키마로 마크업하라. 정체성 페이지에 Organization + Person을, 콘텐츠 페이지에 about/mentions가 있는 Article을 추가하고, 모두를 @id로 서로 엮어라. 스키마 생성기로 JSON-LD를 생성하고 검증한 뒤, Google의 Rich Results Test와 Schema.org 검증기로 확인하라. 이것이 레이어 4: 콘텐츠 및 구조에서 깊이 다루는 구조화 데이터 규율이다.

3. 내부 링크를 변덕이 아니라 엔티티 기준으로 조직하라. 모든 보조 페이지는 자신의 필러로 위로 링크하고, 형제 엔티티로 가로질러 링크해야 하며, 엔티티 이름을 명시하는 서술적 앵커 텍스트(click here가 아니라 distributed tracing)를 사용해야 한다. 이것이 당신의 클러스터를 그래프로서 읽히게 만드는 방법이다.

        [ Pillar: Distributed Tracing ]
        /        |          |         \
 [OpenTelemetry][Jaeger][Span sampling][OTLP]
        \________cross-links between siblings________/

4. 권위 있는 언급을 획득하라. sameAs는 당신의 주장이고, 제3자의 상호 입증이 증거다. Google이 이미 신뢰하는 출처들에 의해 인용되고, 프로필로 소개되고, 링크되라 — 콘퍼런스 발표, 인기 프로젝트의 GitHub README, 업계 간행물, 그리고 진정으로 정당화될 때는 Wikidata 항목까지. 링크 없는 브랜드 언급도 포함된다. Google은 이를 엔티티 연관 신호로 읽는다.

5. 측정하고 반복하라. 당신의 브랜드에 지식 패널이 나타나는지, “웹 전반의 출처에서(From sources across the web)“와 AI Overviews에 등장하는지, 어떤 클러스터 페이지가 랭킹되는지 추적하라. 공백을 채우고, 약한 노드를 심화하며, 그렇게 할 때 updated 날짜를 갱신하라.

  • 엔티티 인벤토리 완료(we-are + we-own + 공백)
  • 전체 sameAs를 포함한 Organization과 Person 스키마 배포
  • 모든 중요한 콘텐츠 페이지에 about/mentions 적용
  • 모든 자산(properties)에 걸쳐 NAP 일관성 확보
  • 엔티티 그래프를 중심으로 내부 링크 구조화
  • 분기당 최소 하나의 새로운 권위 있는 제3자 언급

핵심 요약

  • ✅ Google은 키워드(문자열)가 아니라 엔티티(사물) 로 랭킹한다 — 정확한 구절이 아니라 개념을 위해 최적화하라.
  • ✅ Organization/Person 스키마와 Wikidata, LinkedIn, GitHub, Crunchbase로의 sameAs 링크로 당신의 브랜드와 저자를 인식되는 엔티티로 만들어라.
  • ✅ 실제 엔티티 ID와 함께 about과 mentions를 사용해 각 페이지가 정확히 무엇을 다루는지 Google에 알려라.
  • ✅ Google이 당신의 엔티티를 둘로 쪼개지 않도록 NAP와 명명을 바이트 단위로 일관되게 유지하라.
  • ✅ 키워드당 한 페이지가 아니라, 상호 링크된 콘텐츠 클러스터로 토픽의 엔티티 이웃 전체를 다뤄 토픽 권위를 구축하라.
  • ✅ 스키마 생성기로 마크업을 생성하고 검증한 뒤, 레이어 4: 콘텐츠 및 구조를 통해 적용하라.