Organization 스키마로 회사 정보를 AI에게 알려주려면 어떻게 하나요?
홈페이지에 Organization 타입 JSON-LD를 넣고 @id·sameAs·parentOrganization으로 공식 채널과 조직 관계를 연결하면 된다. 구글은 이 마크업을 홈 또는 회사 소개 페이지 한 곳에 두라고 권장한다. 핵심은 여러 도메인에 흩어진 정보가 '같은 회사'라는 사실을 기계가 읽을 수 있게 만드는 것이다.
최종 업데이트 2026-07-12
AI에게 "○○는 어떤 회사야?"라고 물으면, AI는 웹 곳곳에 흩어진 조각 — 홈페이지, 자회사 사이트, 운영 서비스, 프로필 페이지 — 을 모아 답을 만든다. 문제는 기계가 이름이 비슷하다는 이유만으로 "이게 전부 같은 회사"라고 확신하지 못한다는 점이다. Organization 스키마는 그 확신을 만들어주는 장치다. "우리는 누구고, 공식 채널은 무엇이며, 어떤 조직에 속하는지"를 기계가 읽는 형식인 JSON-LD로 선언한다.
어디에, 무엇을 넣나
구글 공식 문서는 Organization 마크업을 홈페이지 또는 회사를 소개하는 단일 페이지에 두라고 권장한다. 필수 속성은 없고, 회사에 실제로 해당하는 속성(name, url, logo, description, sameAs, 주소·연락처 등)만 골라 넣으면 된다. 아래는 이 사이트(aeo.io.kr)가 실제로 쓰는 마크업을 단순화한 것이다.
{
"@context": "https://schema.org",
"@type": "Organization",
"@id": "https://aeo.io.kr/#organization",
"name": "지음",
"url": "https://aeo.io.kr/",
"logo": "https://aeo.io.kr/logo.png",
"description": "AI 검색 시대의 AI 가시성 최적화(AEO/GEO) 전문사.",
"sameAs": ["https://byteforce.ai.kr", "https://114pet.com"],
"parentOrganization": {
"@type": "Organization",
"@id": "https://byteforce.ai.kr/#org",
"name": "BYTEFORCE",
"url": "https://byteforce.ai.kr"
}
}
@id — 노드에 이름표를 붙인다
@id는 JSON-LD에서 노드에 부여하는 고유 식별자다. 이름표가 있으면 같은 정보를 반복 서술할 필요 없이 참조만 하면 된다. 예컨대 이 사이트의 WebSite 노드는 발행 주체를 이렇게만 적는다.
{
"@type": "WebSite",
"@id": "https://aeo.io.kr/#website",
"publisher": { "@id": "https://aeo.io.kr/#organization" }
}
페이지마다 흩어진 노드들이 @id로 서로를 가리키면, 기계 입장에서는 낱장 문서가 아니라 하나의 엔티티 그래프가 된다.
sameAs — "이 도메인들은 같은 실체"라는 봉합선
schema.org는 sameAs를 "그 항목의 정체를 분명하게 가리키는 참조 웹페이지의 URL"로 정의한다. 위키피디아·위키데이터 항목이나 공식 웹사이트가 대표적인 값이다. 도메인이 달라도 sameAs로 이어두면 "다른 주소지만 같은 실체"라는 선언이 된다.
이 사이트가 표본이다. aeo.io.kr의 Organization 노드는 sameAs로 모회사 byteforce.ai.kr과 운영 서비스 114pet.com을 연결하고, parentOrganization으로 BYTEFORCE를 명시한다. schema.org 정의상 parentOrganization은 "이 조직이 속한 더 큰 조직"을 뜻하므로, 세 도메인에 흩어진 활동이 하나의 회사 이력으로 봉합된다. 단, 원칙이 있다. 확정된 채널만 넣는다. 운영하지 않는 SNS나 존재하지 않는 프로필을 지어 넣는 것은 신뢰를 깎는 역효과만 낸다.
매장이 있다면 LocalBusiness로 확장
동네 가게·병원·학원처럼 물리적 장소가 있다면 Organization 대신 그 하위 타입인 LocalBusiness를 쓴다. 구글 문서 기준 name과 address는 필수이고, geo(좌표)·openingHoursSpecification(영업시간)·telephone·priceRange가 권장 속성이다. 구글은 Restaurant, DaySpa처럼 가능한 한 구체적인 하위 타입을 쓰라고 안내한다. 업종별 적용 순서는 로컬 비즈니스 AEO 체크리스트에 정리해 두었다.
마크업은 보장이 아니라 자격이다
구글 공식 지침은 "페이지가 올바르게 마크업돼 있어도 구조화 데이터가 검색 결과에 표시된다고 보장하지 않는다"고 명시한다. 같은 문서에서 구글은 구조화 데이터 관련 수동 조치조차 리치 결과 자격만 잃게 할 뿐, 웹 검색 순위에는 영향을 주지 않는다고 설명한다. 그럼에도 하는 이유는 분명하다. AI가 회사 정보를 잘못 조합할 여지를 줄이고, 인용·지식패널·브랜드 프로필의 후보가 될 자격을 만들기 때문이다. AEO는 이 자격 위에 확률을 쌓는 일이다.
다음 단계
코드가 낯설다면 개발자가 아니어도 되는 스키마 입문부터 보면 된다. 타입별 전체 지형은 2026년 구조화 데이터 가이드에서 확인할 수 있다.
자주 묻는 질문
- Organization 스키마로 회사 정보를 AI에게 알려주려면 어떻게 하나요?
- 홈페이지(또는 회사 소개 페이지)에 Organization 타입 JSON-LD를 넣고, @id로 고유 식별자를 부여한 뒤 sameAs로 공식 채널을, parentOrganization으로 모회사 관계를 연결한다. 여러 도메인에 흩어진 정보가 같은 회사라는 사실을 기계가 읽을 수 있게 하는 것이 핵심이다.
- sameAs에는 어떤 URL을 넣어야 하나요?
- schema.org 정의상 '그 항목의 정체를 분명하게 가리키는 참조 웹페이지의 URL'만 넣는다. 공식 사이트, 위키피디아·위키데이터 항목, 회사가 실제로 운영하는 공식 채널이 해당한다. 확정된 채널만 넣고, 없는 채널을 지어내면 안 된다.
- Organization 스키마를 넣으면 지식패널 노출이 보장되나요?
- 아니다. 구글은 페이지가 올바르게 마크업돼 있어도 구조화 데이터가 검색 결과에 표시된다고 보장하지 않는다고 공식 문서에 명시한다. 마크업은 노출을 보장하는 장치가 아니라, AI와 검색엔진이 회사를 정확히 이해할 자격을 만드는 기반이다.