본문 바로가기
서치뉴스SearchNews
검색
← 목록으로

오픈 널리지 포맷(OKF)이 실제로 무엇인가: 구글이 정말 공개한 것과 그 이유

iloveseo.net조회수 06일 전

핵심

구글 클라우드가 2026년 6월 공개한 오픈 널리지 포맷(OKF)은 실제로는 SEO 순위 신호가 아니며, 내부 에이전트 구축 팀을 위한 지식 패키징 표준이다. 이는 포장 방식만 표준화할 뿐 의미 자체는 표준화하지 않으므로, 기존 의미론적 웹 스택(RDF/시맨틱 웹)과는 정반대의 트레이드오프를 취한다.

OKF가 실제로 무엇인가

사양의 구성

규격 준수 기준

역사적 배경

배포 채널을 읽기 (보도자료가 아니라)

OKF는 Search Central이나 developers.google.com에 발표되지 않았다. 대신:

전략적 해석

청중은 데이터 엔지니어, 플랫폼 팀, 기업 내부 에이전트 구축자. 문제는 엔터프라이즈가 직면한 고전적 난제: 에이전트가 필요한 지식이 독점 API 카탈로그, 2023년 이후 갱신되지 않은 위키, 코드 주석, Slack 스레드, 휴가 중인 시니어 엔지니어의 머리에 흩어져 있음.

구글의 논제: 해법은 또 다른 통합 필수 지식 서비스가 아니라, 누구나 SDK 없이 제작하고 통합 없이 소비할 수 있는 휴대용 포맷. 상업적 논리는 숨겨지지 않음: 엔터프라이즈 지식이 경쟁사 카탈로그 안에 갇혀 있고, 휴대용 개방 표준이 그 락인(lock-in)을 녹인다. 하지만 참조 경로(Gemini가 번들 작성, BigQuery 소스, Knowledge Catalog 수집)는 중력을 구글 클라우드 내에 유지.

검색 가시성 질문 (공식 문서로 확정)

구글 검색 가시성에 미치는 영향: 없음.

공식 근거

중요한 구분

링크 타입 부재의 의미 (§5.3)

구조적 vs 시맨틱 상호 운용성

tables/orders → tables/customers 링크는 두 개념이 관련있음을 말할 뿐, 어떻게 관련있는지는 말하지 않음:

설계 의도

트레이드오프 매트릭스

| 항목 | OKF | RDF/시맨틱 웹 스택 | |------|-----|-------------------| | 아이디 | 파일 경로 (tables/orders) | 발행된 IRI | | 관계 | 타입 없는 마크다운 링크; 의미는 산문에 | 타입 지정 술어; 의미는 엣지에 | | 어휘 | 자유 텍스트 타입, 중앙 레지스트리 없음 | 공유 온톨로지 (RDFS, OWL) | | 검증 | 프론트매터 파싱 + 타입 비어있지 않음. 그게 다 | SHACL 제약 | | 쿼리 | 문서 읽기 | SPARQL, 결정론적 | | 저작 비용 | 마크다운 파일 작성 | 온톨로지스트 고용 | | 획득물 | 구조적 상호 운용성 | 시맨틱 상호 운용성 |

실제 결과

Entity SEO 용어로 매핑

메타포

OKF는 신뢰할 수 있는 선반 시스템을 가진 아름다운 도서관이지만 카드 카탈로그는 없다. 건물을 이미 알면 모든 것이 발견 가능. 건물 간에는 아무것도 쿼리 불가능.

시맨틱 웹 커뮤니티의 반응

Kurt Cagle (W3C RDFa 공동 저자)은 DataBook 사양을 공식 OKF 프로필로 제안:

이는 OKF 주변에서 일어나는 가장 중요한 일이지만 SEO 대화 밖에서 거의 완전히 진행 중. 지금까지는 Hacker News 비평가들이 더 직설적: 라벨 있는 엔티티 간 관계 없이 지식을 잘 나타낼 수 없다는 게 가장 흔한 지적.

묻지 않은 질문: 누가 번들을 가져가는가?

현재 상태

누락된 메커니즘 (ARD)

2026년 6월 17일, OKF로부터 5일 뒤, 구글이 발표한 에이전틱 리소스 디스커버리(ARD) (Apache 2.0, Linux Foundation 워킹그룹 개발 데이터 모델 기반):

메커니즘 (sitemap과 유사)

  1. 퍼블리셔가 자신의 도메인 잘 알려진 경로에 머신 리더블 매니페스트 호스팅: /.well-known/ai-catalog.json
  2. 매니페스트가 도메인이 제공하는 에이전틱 리소스 선언:
    • 각 항목 = 균일 형태의 봉투
    • IANA 미디어 타입, URN 식별자, URL 포함
    • MCP 서버, A2A 에이전트, OpenAPI 도구, 스킬, 중첩 카탈로그 가능
  3. 레지스트리가 이 카탈로그들을 크롤, 인덱싱
  4. 런타임에 에이전트의 자연어 발견 쿼리에 답하며, 퍼블리셔 검증 전 필요 메타데이터와 함께 매치 반환

위치

ARD는 호출 전 완전히 위치. MCP나 A2A 대체 아님. 에이전트가 사용 전 물어야 할 질문에 답함: 이 작업용 기능이 존재하고, 신뢰할 수 있나?

참여

핵심 연결 (지금까지 그려진 적 없음)

ARD 카탈로그가 광고할 수 있는 리소스 타입에 명시적으로 오픈 널리지 포맷 번들 포함

→ 아무도 당신의 OKF 번들을 가져가지 않는 이유 = OKF가 쓸모없어서 아니라, OKF는 디스커버리 층 없는 페이로드이고, 구글이 5일 뒤 다른 부서에서 디스커버리 층을 발표했는데, 업계가 둘을 연결하지 않았음

현재 채택

올바른 진술

❌ "아무도 절대 당신의 번들을 읽지 않을 것"

✅ "현재 아무도 웹사이트 호스팅 OKF 번들을 읽지 않지만, 무언가가 결국 읽을 수도 있는 메커니즘은 이제 명시되어 있고, Linux Foundation 워킹그룹이 뒤를 받치며, /.well-known/ai-catalog.json 대기 중"

결론

오늘 구축하라는 뜻이 아님. 모니터할 것은 OKF 채택이 아니라 ARD 레지스트리 채택 — 페이로드는 디스커버리 층이 채워질 때까지 쓸모없고, 채워지는 순간 흥미로워짐.

개방 라이선스 ≠ 개방 거버넌스

OKF는 개발자에게 중요한 점에서 진정히 개방적:

하지만 "개방 라이선스"와 "개방 거버넌스"는 다른 짐승이고, 업계가 자주 혼동:

비교 표

| | Spec 출처 | 거버넌스 홈 | 크로스 벤더 채택 | |---|-----------|-----------|-----------------| | MCP | Anthropic | Linux Foundation — Agentic AI Foundation (Dec 2025) | 에이전트 표면 전반 사실상 보편적 | | A2A | Google | Linux Foundation (Jun 2025) | 100+ 지원 조직 | | ARD | Google | Linux Foundation 워킹그룹 기반 구축 | Microsoft, Hugging Face, Snowflake 명시 기여자 | | OKF | Google Cloud | 없음 | 서드파티 도구만, 벤더 지지 없음 |

의미

OKF는 표준 체계 홈이 없음. 구글이 작성, 구글이 v0.1 제어, 로드맵은 구글 결정. 비열정적이지만 8주된 사양의 정상 상태.

결론: "개방 표준"을 OKF에 적용하는 것은 아직 벌어들인 것보다 많은 일을 시킴.

진단 공식: 개방 라이선스, 아직 개방 거버넌스 아님.

또한 사양 자체가 완전히 정착하지 않음: 한 필드 필수라고 하지만 구글 자체 참조 파서는 더 엄격. 드래프트에선 용서할 수 있지만 준수가 아무것도 보장함을 상기시킴.

세 가지가 "OKF"라고 불림

혼동의 대부분은 세 가지 서로 다른 객체를 한 단어로 붕괴:

1. OKF 포맷

2. /okf/ 호스팅 규칙

3. "제2 층" 내러티브

계층 비교 표

| 층 | 무엇인가 | 뒤의 것 | 성숙도 | 오늘 읽히는가? | |----|---------|--------|--------|---------------| | sitemap.xml | 크롤 발견 규칙 | 범용, 수십 년 | 무처 | 예 — 모든 것 | | Schema.org | 엔티티·타입 관계의 공유 어휘 | Google, Microsoft, Yahoo, Yandex + 커뮤니티 | 성숙 | 예 — Search, 부자 결과, Knowledge Graph | | UCP | 에이전트-상인 상거래 프로토콜 | Google + Shopify, Etsy, Target, Walmart, Wayfair | 출시됨 | 예 — AI Mode와 Gemini 라이브 체크아웃 | | llms.txt | LLM용 큐레이션 마크다운 인덱스 | 커뮤니티 제안 | 좁게 채택됨 | 부분적 — 일부 코딩 에이전트와 앤서 엔진. Google Search 아님 | | WebMCP | 라이브 페이지가 브라우저 에이전트에 호출 가능 도구 노출 | Google + Microsoft, W3C Community Group 드래프트 | Chrome 오리진 트라이얼 | 실험적 | | ARD | /.well-known/ai-catalog.json 디스커버리 매니페스트 | Google + Linux Foundation 워킹그룹 | 드래프트, 몇 주 | 거의 0 | | EntityMap | 루트 레벨 JSON 엔티티 선언, 타입 관계, 소스 기여 증거 | Fred Laurent와 Dixon Jones, CC BY 4.0 | 제안 | 공식적으로 아님, 하지만 HTML 변형은 Google과 Bing 인덱싱. JSON 변형은 LLM에서 봐짐과 조치 가능 | | OKF | 마크다운 지식 번들 | Google Cloud, Apache 2.0 | v0.1 드래프트 | 조직 내, 예. 개방 웹, 아님 |

주목할 두 행

이것들은 하나 건물의 8층이 아니다. 8개의 서로 다른 단계의 8개 건설장.

실제로 물건을 구축하는 사람들이 발견한 것

가장 유용한 정보는 분석이 아니라 구현에서 오고 있으며, 구현자들은 보는 것에 대해 주목할 만큼 정직:

Suganthan Mohanadasan의 OKF 번들 생성기

생성기의 저평가 출력

웹사이트를 그래프로 렌더링:

이것은 정당한 내부 링크·엔티티 아키텍처 감사, 에이전트가 번들을 읽을지와 무관하게 가치 있음.

기술할 한 가지 (이 글에서)

번들을 배포가 아니라 진단으로 실행: 발견 가능하지 않은 페이지, 구조 약점, 아키텍처 문제를 식별하는 도구.

Emina Demiri-Watson의 분석

"웹이 제2층을 성장시키고 있다 — 거의 제3층도":

OKF 판정

명확·냉정:

같은 결론에 도달한 점들

다른 읽음

OKF와 ARD 관계:

흥미롭게도

Emina가 다른 쪽에서 같은 이음새 순회 중: 누락된 미디어 타입을 플래그, 카탈로그가 그 외엔 목록 가능한 번들을 인식하지 못하게 함. 자율 에이전트가 타입을 유추해야 했던 뭔가 수집·조치할 때 무슨 일이 생기는가 질문, 정확히.

독립적으로 도달한 같은 질문.

Marie Haynes의 접근

Suganthan과 반대 방향: 발표 밖으로, 안으로 구축.

"OKF 뇌" 문서화:

정확히 OKF 설계 의도된 사용 사례, 포맷 찬성의 가장 강한 주장 어디서나 본 것.

검색 순위와 무관하게 작동 이유: 자신의 에이전트가 지식 개선됨 — PDF 무더기에서 매번 재도출이 아니라 큐레이션, 상호연결, 최신 지식을 읽을 때.

흥미로운 가능성 (Karpathy의 LLM Wiki 적용)

Marie도 진정 도발적 가능성 제기: 사전 컴파일 전문가 번들 시장

→ 이 미래에 대해 적절히 다루지 않은 한 가지

불편한 질문: 번들은 명령 집합

OKF 번들이 구매 가능 아티팩트가 되고 에이전트 읽는 파일시스템에 직접 마운트되면, 신중히 생각해야 할 것:

OKF 번들은 데이터가 아니라, 에이전트가 읽고 조치하는 산문.

→ 구조적으로 간접 프롬프트 인젝션 표면.

가설 아님. 구성으로.

보안 기준

시사점

ARD가 신뢰 매니페스트 보유 = 리소스를 도메인 아이디와 규정 증명서에 결속:

결론

번들 경제 도착하면, 질문은 "내 에이전트가 파일을 읽을 수 있나?" 아니라 "누가 썼고, 어떻게 아는가? 안에 명령이 내가 인가하지 않은 무언가를 하라고 하면 무슨 일이 생기는가?"

좋은 답이 없음. 다른 플러그인이 필요하기 전 답이 필요할 거라 상당히 확신.

순서대로 할 것

내부 에이전트·코파일럿·RAG 실행 중인 경우

지식이 메트릭 정의, 데이터 소스, 프로세스를 계속 약간 잘못 이해하면 → OKF 파일럿 이 분기

마이그레이션 아님. 파일럿.

  1. 에이전트가 가장 자주 틀리는 5개 개념 선택:
    • 가장 주장된 두 메트릭
    • 핵심 데이터셋
    • 주요 API
    • 가장 자주 실행하는 플레이북
  2. 각각 파일 하나씩 작성
  3. 에이전트가 폴더를 가리키게
  4. 정확도 개선되는가 측정
  5. 2일 실험, 거짓 결과 가능

SEO·AI 검색 컨설턴트인 경우

OKF를 가시성 전술로 판매하지 말 것.

네 가지 모니터

거짓 결과 아님. 각각 다음이 움직이면 위 조언이 바뀜:

1. 발견 — 임계값, 가시성 재개

증거: ARD 레지스트리 규모 도달; 에이전트가 실증적으로 카탈로그를 통해 OKF 번들 해석

효과: 개방 웹 발표 질문 올바르게 재개. 이것이 병목.

2. 시맨틱 — 타입 프로필 지형화

증거: 타입 지정 프로필 (DataBook 유사)이 형식화됨

효과: OKF는 진정 지식 그래프 교환 포맷, 자체 메리트로 엔티티 SEO 진입

3. 거버넌스 — 중립 기구 기증 또는 지지

증거: 중립 기구 기증, 또는 비 Google 클라우드 또는 주요 카탈로그 벤더 지지

효과: "모니터"에서 "채택"로 졸업

4. 성숙도 — v0.2+ 안정화

증거: v0.2+ (고정된 마크다운 맛, 정착된 필수 필드 집합, 사양·참조 파서 정렬)

효과: 준수가 뭔가 의미 시작

현재 상태

네 개 모두 움직이지 않음. 이것이 전체 답.

이달 내 쓴 구현 가이드보다 가치 있음.

여기 어디 맞는가

20년 봐온 같은 이야기가 다른 코스튬으로 반복:

문자에서 것으로 (Strings to Things)

것에서 답으로 (Things to Answers)

지금: 답에서 조치로 (Answers to Actions)

OKF는 계통에 속함

하지만 더 조용한 질문에 답:

조치 프로토콜: 에이전트가 할 수 있는 것 우려

OKF: 에이전트가 안다 것 우려

→ 모르는 비즈니스에서 조치 불가능, 도구 얼마나 노출하든

평가

OKF는 SEO 업계의 대부분이 가진 적 없는 진정 문제에 대한 잘 설계된 답이며, 자신이 착각하는 것이 아닌 형태로 도착.

올바른 태세

호흡 찬 것도 기각적인 것도 아님, 우리 업계가 유지하기 가장 어렵고 가장 필요한 것:

  1. 사양 읽기
  2. 무엇인지 이해
  3. 네 개 신호 모니터 (위)
  4. 그 사이 지루한 기초 구축 (크롤 가능, 구조화된 HTML, schema.org, 원본 콘텐츠, API)