결론부터: AI가 우리 브랜드를 답변에 넣을지 말지는 '얼마나 많이 언급됐냐'보다 '하나의 개체(엔티티)로 또렷하게 식별되느냐'에서 먼저 갈린다. AI 엔진에게 브랜드명은 기본적으로 그냥 글자 몇 개다. 이 글자가 세상에 실재하는 하나의 회사를 가리킨다는 걸 엔진이 확신하지 못하면, 검색 후보에 올라도 재정렬에서 밀리고, 운 좋게 생성에 들어가도 다른 동명 브랜드와 뒤섞이거나 아예 지어낸(할루시네이션) 정보가 붙는다. 이 글은 그 '개체 식별'이 RAG(검색→재정렬→생성)의 각 단계에서 왜 결정적인지 메커니즘으로 뜯어보고, 위키데이터·schema.org로 브랜드를 지식 그래프에 새기는 실무를 ❌약한 예/✅강한 예로 보여준다. 마지막엔 한국 기업 두 가지 시나리오와, 이걸 어떻게 숫자로 측정해 매출에 연결하는지까지 붙인다. 나는 tao, 그로스·퍼포먼스 리드다.
엔티티가 뭐길래 — '떠다니는 글자'와 '주민등록된 개체'의 차이
엔티티(entity)는 지식 그래프에서 하나의 노드다. 사람·회사·제품·장소처럼 세상에 실재하는 개체 하나가 노드 하나로 대응되고, 노드끼리 '만든다·위치한다·소속이다' 같은 관계선으로 연결된다. 구글 지식 그래프, 위키데이터가 대표적이다.
비유하자면 이렇다. 브랜드명이 문서 여기저기에 흩어진 이름표라면, 엔티티는 그 이름표들을 하나로 묶어주는 주민등록이다. 동명이인이 열 명이어도 주민등록번호는 각자 하나뿐이라 헷갈리지 않는다. 위키데이터의 QID(예: Q12345 같은 고유 식별자)가 바로 브랜드의 주민등록번호 역할을 한다. QID가 있으면 '앱토(가상)'라는 회사가 '앱토라는 동네 카페'와도, '앱토라는 영어 단어'와도 구별된다.
왜 이게 AI 시대에 갑자기 중요해졌나. 예전 검색은 글자가 겹치는 페이지를 링크로 나열해주면 끝이었다. 그러나 AI 답변 엔진은 '이 브랜드가 무엇인지'를 스스로 이해한 다음 문장으로 요약해야 한다. 이해하려면 개체가 또렷해야 하고, 개체가 흐릿하면 엔진은 둘 중 하나를 한다 — 보수적으로 빼버리거나(누락), 아무 정보나 갖다 붙이거나(할루시네이션). 둘 다 브랜드에겐 최악이다.
RAG 3단계에서 엔티티가 판을 가르는 지점
AI 답변 엔진은 외운 지식만으로 답하지 않는다. 대부분 RAG(Retrieval-Augmented Generation) 구조다. Lewis 등의 2020년 원전(arXiv:2005.11401)이 정의한 대로, 모델이 '외운 지식(파라메트릭 메모리)'에 '그때그때 찾아온 문서(비파라메트릭 메모리)'를 결합해 답을 만든다. 크게 세 단계다.
- 검색(retrieval) — 질문과 의미가 가까운 문서 조각(청크)을 후보로 끌어온다.
- 재정렬(reranking) — 후보를 질문과 나란히 다시 읽어 진짜 관련 있는 순으로 줄 세운다.
- 생성(generation) — 상위 몇 개 문서를 근거로 문장을 짓고 인용을 단다.
엔티티 식별은 이 세 단계 전부에 영향을 준다. 하나씩 보자.
1단계 검색 — 이름이 흩어지면 신호도 흩어진다
검색 단계의 핵심은 의미 검색(임베딩)이다. Karpukhin 등의 Dense Passage Retrieval(arXiv:2004.04906)은 단어가 겹치는지만 세는 옛 방식(BM25)보다, 의미가 가까운 문장을 임베딩 벡터로 찾는 편이 더 정확하다는 걸 보였다. 실무에선 둘을 합친 하이브리드 검색이 표준이다. 도서관에 비유하면, 키워드 색인 카드(BM25)와 '주제를 아는 사서'(임베딩)를 함께 쓰는 셈이다. 공개 벤치마크를 종합하면 recall@10이 의미 단독 약 78%, BM25 단독 약 65%인데 둘을 합치면(RRF) 약 91%까지 오른다.
문제는 브랜드명이 표기마다 흩어질 때 벌어진다. 홈페이지엔 'Citeon', 블로그엔 '사이티온', 보도자료엔 '싸이티온', 회사소개엔 '(주)블룸 Citeon'… 이렇게 표기가 갈라지면 BM25는 각 표기를 다른 단어로 세고, 임베딩도 문맥이 파편화돼 신호가 약해진다. 한 브랜드에 대한 100의 신호가 4갈래로 쪼개져 25씩 흩어지는 격이다.
Anthropic이 2024년 공개한 Contextual Retrieval이 이 문제의 반대 방향을 잘 보여준다. 청크마다 '이게 무엇에 관한 조각인지' 맥락을 앞에 붙이면 검색 실패율이 35% 줄었고(5.7%→3.7%), BM25를 더하면 49%, 재정렬까지 얹으면 67% 줄었다. 엔티티 일관성은 사람 손으로 하는 contextual retrieval이다. 모든 문서에서 브랜드를 같은 이름·같은 식별자로 못 박아두면, 엔진이 조각들을 '같은 개체 이야기'로 묶기 쉬워진다.
❌ 약한 예 (표기 파편화)
홈: "Citeon은 풀퍼널 AI 마케팅 대행입니다"
블로그: "사이티온이 이번에 세미나를 열었다"
보도자료: "싸이티온(대표 ...) ..."
→ 엔진 입장: 서로 다른 3개 무언가일 수도 있음
✅ 강한 예 (표기 고정 + 별칭 명시)
모든 문서: "Citeon(사이티온)"으로 통일
schema.org에 name="Citeon", alternateName=["사이티온"]
→ 엔진 입장: 3개 문서 = 하나의 개체 Citeon
2단계 재정렬 — 애매한 개체는 뒤로 밀린다
재정렬은 교차 인코더(cross-encoder)가 후보를 질문과 함께 한 번 더 읽고 순위를 다시 매기는 단계다. 실무에서 재정렬을 넣으면 NDCG(순위 품질 지표)가 대략 5~15, 어려운 질의에선 20 가까이 오른다. 여기서 엔진은 '이 문서가 질문 속 개체를 정확히 다루는가'를 본다.
브랜드가 지식 그래프에 등록돼 있으면(위키데이터 QID, 구글 지식 패널), 엔진은 브랜드명을 그 노드로 연결(entity linking)한 뒤 질의와 대조한다. 개체가 또렷할수록 '이 문서는 확실히 그 회사 이야기'라는 확신이 커져 상위로 올라간다. 반대로 개체가 흐릿하면, 특히 이름이 일반 단어나 동명 브랜드와 겹치면, 엔진은 확신이 서지 않아 안전하게 순위를 낮춘다. Claude 계열이 근거 약한 콘텐츠를 보수적으로 걸러내는 성향을 떠올리면 된다 — 애매하면 뺀다.
3단계 생성 — 개체가 흐리면 '지어내기'가 시작된다
생성 단계에선 엔진이 상위 문서를 근거로 문장을 짓는다. 이때 개체가 또렷하지 않으면 두 가지 사고가 난다. 첫째 혼동 — 동명의 다른 회사 정보를 우리 것으로 섞는다. 둘째 할루시네이션 — 근거가 부족한 빈칸을 그럴듯한 말로 메운다. 실무에서 답변의 주장이 실제 출처로 추적되는 정도를 재는 지표가 RAGAS faithfulness인데, 팀마다 편차는 있지만 흔히 0.9 이상이면 안정, 0.7 미만이면 위험으로 본다. 개체가 흐린 브랜드는 이 값이 구조적으로 낮아지기 쉽다 — 엔진이 붙잡을 '단단한 사실'이 부족하기 때문이다.
또 하나. Liu 등의 Lost in the Middle(arXiv:2307.03172)은 긴 맥락에서 중간에 놓인 정보가 잘 안 쓰이는 U자형 현상을 보였다. 핵심은 앞·끝에 둬야 살아남는다. 브랜드의 정의 문장(무엇을 하는 회사인지 한 문장)이 페이지 맨 앞, 그리고 schema.org의 구조화된 필드처럼 엔진이 앞자리에서 읽는 위치에 박혀 있어야 생성 단계에서 그대로 인용된다.
브랜드를 지식 그래프에 새기는 4개의 못
정리하면, 목표는 하나다 — 엔진이 우리 브랜드명을 볼 때마다 '아, 그 회사(하나의 노드)'로 즉시 연결하게 만드는 것. 이걸 위해 박는 못은 크게 넷이다.
| 못 | 무엇 | 엔진에게 주는 신호 |
|---|---|---|
| 1. schema.org Organization | 홈페이지에 회사 구조화 데이터(JSON-LD). name·alternateName·url·logo·sameAs·description | "이 URL은 이 개체의 공식 원점이다" |
| 2. sameAs 링크 | 공식 홈↔위키데이터↔링크드인↔업계 DB를 서로 가리키게 | "흩어진 프로필들은 전부 같은 개체다" |
| 3. 위키데이터 항목 | 회사 QID 생성 + 산업·설립·소재지·공식 웹사이트 속성 | "이 개체는 검증 가능한 주민등록이 있다" |
| 4. 정의 문장 일관성 | 모든 채널에서 같은 한 문장 정의 + 표기 고정 | "이 개체가 무엇을 하는지 확정적이다" |
schema.org의 sameAs는 특히 저평가돼 있다. 이건 '이 계정들은 전부 나야'라고 엔진에게 도장을 찍어주는 장치다. 여러 SNS·디렉터리에 흩어진 프로필을 하나의 개체로 봉합한다.
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "Organization",
"name": "Citeon",
"alternateName": ["사이티온"],
"url": "https://citeon.cloud",
"description": "AI 검색에서 브랜드가 인용되게 만들고 매출까지 잇는 풀퍼널 마케팅 대행",
"sameAs": [
"https://www.wikidata.org/wiki/Q...",
"https://www.linkedin.com/company/..."
]
}
</script>
주의 — 정직하게 채워야 한다. 존재하지 않는 계정을 sameAs에 넣어 권위를 부풀리는 건 금물이다. 엔진(과 사람)이 클릭 한 번으로 확인하면 오히려 신뢰가 무너진다. 실재하는 프로필만, 실제로 서로 연결하라.
한국 기업 시나리오 1 — 이름이 일반 단어와 겹치는 B2B SaaS
가상의 회사 '리프(Leap)'라는 국내 B2B 워크플로우 SaaS를 보자. 문제는 이름이다. '리프'는 나뭇잎(leaf)·도약(leap)·음악 밴드·해외 동명 스타트업까지 겹친다. ChatGPT에 "리프 어때?"라고 물으면 엉뚱한 개체가 튀어나오거나, 우리 회사 소개에 남의 투자 유치 소식이 섞였다.
처방은 개체를 못 박는 것이었다. ① 홈페이지 표기를 '리프(Leap)'로 통일하고 schema.org Organization + alternateName 추가. ② 위키데이터에 회사 항목을 만들고 '산업=SaaS', '소재지=대한민국', '공식 웹사이트' 속성을 넣어 동명 개체와 구별되는 좌표를 부여. ③ sameAs로 링크드인·홈·위키데이터를 삼각 결선. ④ 모든 블로그 첫 문단에 "리프(Leap)는 ~하는 국내 B2B SaaS다"라는 정의 문장을 고정.
❌ 약한 예 (개체 흐림)
질문: "리프라는 협업 툴 알려줘"
AI: "리프는 여러 의미가 있습니다. 밴드일 수도, 해외 스타트업일 수도..."
✅ 강한 예 (개체 또렷)
질문: "리프라는 협업 툴 알려줘"
AI: "리프(Leap)는 대한민국의 B2B 워크플로우 SaaS로, ...입니다."
핵심은 '더 많이 노출'이 아니라 '더 또렷하게 식별'이었다. 언급량을 늘리기 전에 개체부터 세우는 순서가 중요하다.
한국 기업 시나리오 2 — 오늘의 한 걸음 더: 해외로 나가는 중견 제조사
이번엔 결이 다른 사례다. 경상권의 가상 정밀부품 제조사 '한성정밀'을 보자. 국내 업력 30년, 산업용 커넥터를 만들어 대기업에 납품한다. 최근 북미·유럽 바이어를 AI로 발굴하려는데, 문제가 있었다. 해외 바이어가 Perplexity나 ChatGPT에 "Korean precision connector manufacturer for EV"라고 물으면 한성정밀이 전혀 안 나온다. 이유는 두 가지가 겹쳐 있었다.
- 한글 자산은 대부분 네이버 안에 있다. 그런데 네이버는 외부 크롤러를 막아, 글로벌 AI는 나무위키·위키백과·티스토리 같은 우회 경로로만 한국 정보를 줍는다. 네이버 블로그에 아무리 실적을 쌓아도 글로벌 엔진 후보엔 안 들어간다.
- 영문 개체가 존재하지 않는다. 'Hanseong Precision'인지 'Hansung'인지 로마자 표기조차 문서마다 달라, 엔진이 하나의 개체로 묶을 수가 없다.
제조사의 처방은 시나리오 1과 순서가 같지만 언어·경로가 국제형이다.
| 단계 | 한성정밀의 실행 | 노리는 효과 |
|---|---|---|
| 로마자 표기 확정 | 'Hanseong Precision Co., Ltd.'로 국제 표기 1개 고정, 국문·영문 사이트에 alternateName로 상호 명시 | 영문 문서 신호가 한 개체로 수렴 |
| 글로벌이 읽는 곳에 심기 | 영문 위키백과는 특별관심(notability) 기준이 높으니 우선 위키데이터 항목(사실 기반, 문턱 낮음) + 영문 회사 프로필·업계 디렉터리·영문 보도자료 | 네이버 밖, 글로벌 크롤러 경로에 개체 등장 |
| schema.org + sameAs | 영문 사이트에 Organization(제품군·인증·소재지) + 위키데이터·링크드인 결선 | 흩어진 영문 프로필을 하나로 봉합 |
| 크롤러 허용 점검 | robots.txt에서 GPTBot·OAI-SearchBot·PerplexityBot·ClaudeBot·anthropic-ai·Google-Extended 허용 | 후보군 진입 자체를 보장 |
여기서 0순위는 robots.txt다. AI 크롤러가 막혀 있으면 위 모든 노력이 후보 진입 전에 무효가 된다. 1시간이면 점검되는데 효과는 가장 근본적이다. 제조사처럼 '한글 자산은 많은데 글로벌 AI엔 안 잡히는' 기업일수록, 언급을 늘리기 전에 글로벌 크롤러가 닿는 곳에 또렷한 영문 개체를 세우는 것이 승부처다. 참고로 한국 시장 안에서라면 반대로 네이버의 C-Rank(출처 신뢰·전문성)와 D.I.A.+(문서 의도)를 함께 봐야 하고, AI 브리핑 인용을 노린다면 직접경험·일관주제·진정성 같은 콘텐츠 원칙이 개체 신뢰의 토대가 된다.
엔진마다 개체를 대하는 성향이 다르다
같은 개체 최적화라도 엔진별 성향을 알면 우선순위가 잡힌다. 대규모 인용 분석을 보면 엔진 간 인용 도메인 중복은 약 11%에 불과하고, 인용의 약 90%가 엔진마다 다르다. 즉 '한 엔진에서 됐으니 다 된다'는 착각이다.
| 엔진 | 개체 인식 성향 | 공략 포인트 |
|---|---|---|
| ChatGPT | 위키백과·커뮤니티 비중 큼(위키백과 약 47.9%) | 위키데이터·위키백과 존재 여부가 개체 확신에 크게 기여 |
| Gemini | 구글 색인·지식 그래프·E-E-A-T 기반 | 구글 지식 패널·schema.org 정합성 |
| Claude | 근거 약한 개체 보수적으로 걸러냄 | 검증 가능한 사실·일관된 정의 문장 |
| Perplexity | 실시간 웹·인라인 인용, 커뮤니티(레딧 약 46.7%) | 최신성 + 외부에서 인용되는 개체 언급 |
측정 — 개체가 서 있는지 어떻게 숫자로 아는가
그로스 리드로서 여기가 본론이다. 개체 최적화는 '했다/안 했다'가 아니라 측정되는 상태여야 한다. 두 축으로 본다.
- 식별 정확도 — 여러 엔진에 "OO는 무엇을 하는 회사야?"를 반복해 묻고, 답이 (1) 우리 개체를 정확히 지목하는지 (2) 동명 개체와 안 섞이는지 (3) 정의 문장이 일관되는지를 점수화한다.
- 인용 점유율(SOV) — 카테고리 대표 질문들에 대한 AI 답변에서 우리 브랜드가 언급되는 비율. 개체가 서면 이 값이 따라 오른다.
단, 한 번 측정은 노이즈다. LLM은 temperature=0에서도 출력이 흔들린다(GPU 연산·배치 순서 탓). 한 분석에선 대형 모델을 1,000회 돌렸더니 80가지 출력이 나왔다. AI 가시성의 불확실성을 정량화한 연구(arXiv:2603.08924)는 인용이 멱법칙처럼 출렁이므로 다중 실행 + 부트스트랩 신뢰구간을 권한다. 그러니 개체 최적화 전후를 비교할 땐 단일 스냅샷이 아니라 반복 측정의 분포로 봐야 한다.
❌ 약한 측정: "오늘 ChatGPT가 우리를 정확히 설명함 → 개체 완성!"
✅ 강한 측정: 4개 엔진 × 대표질문 20개 × 주 3회 반복
→ 식별정확도 62%→89%, SOV 8%→19% (신뢰구간 함께)
그리고 여기서 멈추지 않는다. 가시성·식별정확도는 2차 지표다. 최종 질문은 늘 같다 — 그래서 리드·매출이 늘었는가. 개체가 또렷해지면 AI 유입의 질이 올라가는데(일부 분석에선 AI 검색 유입의 전환율이 일반 검색보다 몇 배 높게 나타나기도 한다), 이걸 어트리뷰션으로 붙잡아 매출까지 연결해야 프로젝트가 끝난다.
Citeon은 이 원리를 제품에 담았다
Citeon은 '개체가 서 있는지'를 눈으로 확인시켜 준다. 4개 엔진(ChatGPT·Gemini·Perplexity·Claude) 인용 측정(SOV)으로 카테고리 질문에서 브랜드가 얼마나·어떻게 언급되는지 추적하고, 동명 개체와 섞이는지·정의가 일관되는지를 드러낸다. 사이트 진단엔진은 schema.org·표기 일관성·robots.txt(AI 크롤러 허용)처럼 개체를 세우는 못이 제대로 박혔는지 URL 하나로 점검한다. 경쟁사 역추적으로 같은 카테고리에서 경쟁 개체가 어디에 어떻게 인용되는지 역설계하고, 주간 모니터 추이로 개체 최적화 전후의 SOV·식별 변화를 시계열로 본다. 위에서 말한 '단일 측정은 노이즈'라는 원칙 그대로, 한 번이 아니라 추이로 판단하게 설계했다.
우리 브랜드가 AI에게 '하나의 개체'로 인식되고 있는지 궁금하다면, Citeon 무료진단(₩0)으로 시작하라. URL만 넣으면 SEO·AEO·GEO 점수와 함께 개체 최적화가 어디서 새는지 처방 리포트를 받는다.
자주 묻는 질문
위키백과에 우리 회사 문서를 만들면 되나요?
영문 위키백과는 특별관심(notability) 기준이 높아 중소·신생 기업은 등재가 어렵거나 삭제되기 쉽습니다. 먼저 문턱이 낮고 사실 기반인 위키데이터 항목부터 만들고(산업·소재지·공식 웹사이트 속성), schema.org sameAs로 홈·위키데이터·링크드인을 결선하는 편이 현실적입니다. 위키백과는 실제 언론 보도·2차 출처가 충분히 쌓인 뒤 시도하세요.
schema.org만 잘 넣으면 AI가 우리를 개체로 인식하나요?
schema.org는 '못' 하나일 뿐 충분조건은 아닙니다. 구조화 데이터가 완벽해도, 외부 문서들에서 표기가 흩어져 있거나 위키데이터 같은 검증 좌표가 없으면 엔진의 개체 확신은 약합니다. schema.org(사이트 내부 신호) + sameAs/위키데이터(외부 검증) + 표기·정의 문장 일관성(모든 채널)이 함께 가야 합니다.
브랜드명이 흔한 단어라 계속 다른 것과 섞입니다. 어떻게 하죠?
동명·일반어 충돌은 개체 좌표로 푸는 문제입니다. 위키데이터에 '산업·소재지·설립·공식 웹사이트'를 넣어 다른 동명 개체와 구별되는 좌표를 부여하고, 모든 문서 첫 문단에 "OO(영문표기)는 ~하는 [국가]의 [업종]이다"라는 정의 문장을 고정하세요. 엔진이 그 문장을 개체의 '설명 앵커'로 잡습니다. Lost in the Middle 연구처럼 이 문장은 페이지 앞자리에 둬야 합니다.
네이버에 자산이 많은데 왜 글로벌 AI엔 안 나오나요?
네이버가 외부 크롤러를 차단하기 때문입니다. 글로벌 AI는 네이버 대신 나무위키·위키백과·티스토리 등 열린 경로로 한국 정보를 수집합니다. 따라서 해외·글로벌 엔진을 노린다면 네이버 밖의 열린 채널(위키데이터, 영문 프로필·디렉터리, 티스토리 등)에 개체를 세워야 하고, robots.txt에서 AI 크롤러가 허용돼 있는지부터 확인해야 합니다.
개체 최적화 효과를 한 번 측정으로 판단해도 되나요?
안 됩니다. LLM은 temperature=0에서도 출력이 흔들려 단일 측정은 노이즈입니다. 한 연구는 다중 실행 + 부트스트랩 신뢰구간을 권합니다. 최소한 여러 엔진 × 대표질문 여러 개 × 반복 측정으로 분포를 보고, 전후 비교는 추이로 판단하세요. 그리고 가시성은 2차 지표이니 최종적으로 리드·매출 어트리뷰션과 연결해야 합니다.
참고자료
- Lewis et al. (2020), Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- Karpukhin et al. (2020), Dense Passage Retrieval for Open-Domain QA
- Liu et al. (2023), Lost in the Middle: How Language Models Use Long Contexts
- Aggarwal et al. (2023), GEO: Generative Engine Optimization (KDD 2024)
- Anthropic (2024), Introducing Contextual Retrieval
