[AI] Open Knowledge Format(OKF) 파헤치기

이번 글에서는 Google Cloud가 2026년 6월 공개한 Open Knowledge Format(OKF) 을 깊이 있게 뜯어봅니다.

---

OKF란 무엇인가?

OKF는 한 문장으로 정의됩니다.

"OKF is an open, human- and agent-friendly format for representing knowledge — the metadata, context, and curated insight that surrounds data and systems."
(OKF는 데이터와 시스템을 둘러싼 메타데이터·맥락·정제된 통찰, 즉 지식을 표현하기 위한, 사람과 에이전트 모두에게 친화적인 오픈 포맷이다.)

여기서 핵심은 대상이 데이터 자체가 아니라 지식(knowledge) 이라는 점입니다. "이 테이블은 무엇인가", "이 지표는 어떻게 계산하는가", "이 파이프라인이 늦으면 무엇을 확인하는가" 같은, 데이터 주변의 맥락을 다룹니다.

그리고 그 형식은 놀라울 만큼 소박합니다. YAML frontmatter를 얹은 마크다운 파일들의 디렉터리가 전부입니다. 스펙은 이렇게 못을 박습니다.

"There is no schema registry, no central authority, and no required tooling. If you can cat a file, you can read OKF; if you can git clone a repo, you can ship it."
(스키마 레지스트리도, 중앙 권위도, 필수 도구도 없다. 파일을 cat 할 수 있으면 OKF를 읽을 수 있고, 저장소를 git clone 할 수 있으면 그것을 배포할 수 있다.)

 

이 소박함이 곧 설계 의도입니다. OKF는 벤더 중립 '교환 포맷' 을 지향합니다. 누구나 생산하고, 누구나 소비합니다.

 

생산 측은 사람이 손으로 쓸 수도 있고, 에이전트(Google ADK·LangChain·커스텀)가 만들 수도 있으며, 기존 카탈로그(Dataplex·Unity Catalog·Collibra)에서 export할 수도 있습니다. 소비 측은 정적 파일 서버, Obsidian·Notion·MkDocs 같은 지식관리 UI, 파일을 그대로 컨텍스트에 적재하는 LLM, 검색 인덱스, 그래프 뷰어 등 무엇이든 될 수 있습니다. 이 둘 사이에 오직 포맷 하나만 계약으로 두는 것이 OKF의 발상입니다. 발표 글의 표현을 빌리면 이렇습니다. "The format itself is the contribution."(형식 그 자체가 기여다.)

---

왜 OKF가 필요할까?

발표 글이 지목하는 문제는 지식의 파편화입니다. 조직의 내부 지식은 서로 호환되지 않는 시스템에 흩어져 있습니다 — 독자 API를 가진 메타데이터 카탈로그, 위키와 공유 드라이브, 코드 주석과 docstring과 노트북 셀, 그리고 시니어 엔지니어의 머릿속.

AI 에이전트가 "우리 이벤트 스트림에서 주간 활성 사용자(WAU)를 어떻게 구하지?" 같은 질문에 답하려면, 이 흩어진 조각들을 매번 밑바닥부터 재조립해야 합니다. 그 결과 발표 글의 표현처럼, 모든 에이전트 개발자가 컨텍스트 조립을 처음부터 다시 풀고, 모든 카탈로그 벤더가 같은 데이터 모델을 재발명하며, 지식은 그것을 만든 인터페이스에 갇혀 버립니다.

[질문] "우리 이벤트 스트림에서 WAU를 어떻게 계산하지?"

기존 방식:  흩어진 소스 → 에이전트가 매번 밑바닥부터 재조립
            (카탈로그 API · 위키 · 코드 주석 · 시니어의 머릿속)

OKF 방식:   지식을 한 번 정제해 파일로 → 어떤 소비자든 그대로 읽음
            (사람도 cat, LLM도 컨텍스트 적재, 검색기도 인덱싱)

OKF는 이 문제를 "더 똑똑한 카탈로그"가 아니라 "공통 파일 포맷" 으로 풀자고 제안합니다. 지식을 한 번 정제해 표준 형식의 파일로 남겨 두면, 생산자와 소비자가 각자 다른 도구를 쓰더라도 같은 산출물을 공유할 수 있습니다.

---

OKF의 실제 규칙: 놀라울 만큼 얇다

스펙을 실제로 읽어 보면, OKF가 강제하는 규칙이 대단히 적다는 데 놀라게 됩니다. 하나씩 정리하겠습니다.

번들과 개념(Concept)

• Knowledge Bundle(지식 번들): 마크다운 문서들의 자족적·계층적 모음. 배포의 단위입니다. git 저장소, tarball/zip, 혹은 더 큰 저장소의 하위 디렉터리로 배포할 수 있습니다(git 권장).
• Concept(개념): 번들 안의 지식 한 단위 = 마크다운 문서 한 개. 테이블·API 같은 실물 자산일 수도, 지표·업무 프로세스 같은 추상 개념일 수도 있습니다.
• Concept ID: 파일 경로에서 .md를 뗀 것. 예를 들어 tables/orders.md의 Concept ID는 tables/orders입니다. 즉 파일 경로가 곧 정체성입니다.

frontmatter: 필수는 딱 하나

각 문서는 ---로 감싼 YAML frontmatter와 그 아래 마크다운 본문으로 이루어집니다. 그런데 필수 필드는 type 하나뿐입니다. 나머지는 전부 '권장'입니다.

필드	필수 여부	역할
type	필수	개념의 종류. 라우팅·필터링·표시에 사용. 예: BigQuery Table, Metric, Playbook. 중앙 등록 없음
title	권장	사람이 읽을 표시 이름
description	권장	한 문장 요약. 인덱스·검색 스니펫·미리보기에 사용
resource	권장	밑단 자산을 식별하는 URI. 추상 개념에는 없을 수 있음
tags	권장	교차 분류용 문자열 목록
timestamp	권장	마지막 의미 있는 변경 시각(ISO 8601)

 

type 값조차 중앙에 등록되지 않습니다. 생산자는 서술적인 값을 고르도록 권고되고, 소비자는 모르는 type을 만나도 우아하게 관용해야(MUST tolerate) 합니다(보통 generic 개념으로 취급). 또한 생산자는 임의의 추가 키를 넣을 수 있고, 소비자는 모르는 필드가 있다고 문서를 거부하면 안 됩니다.

본문에는 필수 섹션이 없습니다. 다만 # Schema(자산의 컬럼·필드), # Examples, # Citations(근거 출처) 세 제목이 관례적 의미를 가집니다.

실제 문서는 이렇게 생겼습니다

---
type: BigQuery Table
title: Customer Orders
description: One row per completed customer order across all channels.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders, revenue]
timestamp: 2026-05-28T14:30:00Z
---

# Schema
| Column        | Type    | Description                          |
|---------------|---------|--------------------------------------|
| `order_id`    | STRING  | Globally unique order identifier.    |
| `customer_id` | STRING  | FK into [customers](/tables/customers.md). |

# Joins
Joined with [customers](/tables/customers.md) on `customer_id`.

트리이면서 그래프

디렉터리는 부모/자식이라는 계층(트리) 을 만듭니다. 그런데 문서들은 마크다운 링크로 서로를 가리켜 그래프가 됩니다. 위 예시에서 [customers](/tables/customers.md) 같은 링크가 그것입니다.

 

여기서 스펙의 두 가지 결정이 그래프의 성격을 규정합니다(§5.3).

1. 링크는 관계의 '존재'만 주장합니다. 그 관계가 parent/child인지, references인지, joins-with인지, depends-on인지 — 그 종류는 링크가 아니라 surrounding prose 이 전달합니다. 그래서 그래프를 만드는 소비자는 모든 링크를 "방향만 있는 무유형 간선"으로 취급합니다.
2. 깨진 링크도 허용됩니다. 스펙 원문은 이렇게 말합니다. "Consumers MUST tolerate broken links — a link whose target does not exist in the bundle is not malformed; it may simply represent not-yet-written knowledge."(존재하지 않는 대상을 가리키는 링크도 잘못된 것이 아니다. 아직 쓰이지 않은 지식일 수 있다.)

링크는 절대 경로(번들 루트 기준, /로 시작)가 권장됩니다. 문서를 하위 디렉터리 안에서 옮겨도 링크가 깨지지 않기 때문입니다.

예약 파일과 적합성(Conformance)

예약된 파일명은 딱 둘입니다.

• index.md — 디렉터리 목록. 점진적 공개(progressive disclosure) 를 위한 것으로, 소비자가 전부 열어보기 전에 무엇이 있는지 훑게 해줍니다.
• log.md — 변경 이력. ISO 8601 날짜별로, 최신순 기록.

그리고 "OKF v0.1에 적합(conformant)하다"는 판정 기준은 단 세 가지입니다(§9).

1. 예약 파일이 아닌 모든 .md가 파싱 가능한 YAML frontmatter를 가진다.
2. 그 frontmatter에 비어 있지 않은 type 필드가 있다.
3. 예약 파일(index.md·log.md)이 있다면 정해진 구조를 따른다.

나머지는 전부 "soft guidance(권고)"입니다. 결정적으로 스펙은 소비자가 다음을 이유로 번들을 거부해서는 안 된다(MUST NOT reject) 고 못박습니다 — 옵션 필드 누락, 모르는 type, 모르는 추가 키, 깨진 크로스링크, index.md 부재. 그리고 이렇게 덧붙입니다. "This permissive consumption model is intentional."(이 관대한 소비 모델은 의도적이다.)

정리하면, OKF는 "최소한만 강제하고, 나머지는 관례와 소비자에게 맡긴다"는 철학 위에 서 있습니다. 이 관대함이 이식성과 단순함을 낳는 원천이자, 뒤에서 볼 한계의 원천이기도 합니다.

---

참조 구현을 뜯어보면: 2-패스 파이프라인

스펙만으로는 추상적이니, Google이 함께 공개한 참조 에이전트(reference agent) 를 코드 수준에서 살펴보겠습니다. 여기서부터는 스펙이 아니라 하나의 개념 증명(proof of concept) 이라는 점을 기억해 주세요. 발표 글도 "에이전트는 OKF를 생산하는 하나의 방법을 보여줄 뿐"이라고 분명히 합니다.

참조 에이전트의 CLI는 서브커맨드 두 개로 구성됩니다 — enrich(소스 → OKF 번들 생산)와 visualize(번들 → 시각화 HTML). enrich는 두 개의 독립된 Google ADK 에이전트를 띄우고, 기본 모델은 gemini-flash-latest입니다. 그리고 이름 그대로 2개의 패스(pass) 로 동작합니다.

[BigQuery 데이터셋]
   -> [BQ pass]   개념당 OKF 문서 정확히 1개 (BigQuery 메타데이터만)
   -> [web pass]  LLM이 크롤러가 되어 문서를 보강
   -> [index.md 재생성]  점진적 공개용 목록을 LLM이 다시 생성
   -> [OKF 번들]
   -> [visualize] 단일 HTML로 렌더

BQ 패스 — 뼈대 만들기

첫 패스는 BigQuery 메타데이터만으로 소스가 광고하는 개념마다 문서를 정확히 하나씩 씁니다. 순수한 사실(스키마, 이름)로 뼈대를 세우는 단계입니다.

web 패스 — LLM을 크롤러로

두 번째 패스가 흥미롭습니다. LLM이 스스로 크롤러가 되어, 주어진 시드 URL(--web-seed)에서 출발해 바깥 링크를 따라가며 "이 페이지가 권위 있는 문서로 보이는가"를 판단합니다. 각 페이지에 대해 (a) 기존 개념 문서를 보강하거나, (b) references/<slug> 새 문서를 만들거나, (c) 건너뜁니다.

여기서 가장 인상적인 설계는 가드레일이 프롬프트가 아니라 코드로 강제된다는 점입니다. fetch_url 툴 소스(web_tools.py)를 보면, 스킴·허용 호스트·경로 접두사·금지 문자열·중복 방문·최대 페이지 수·홉 깊이를 툴 내부에서 검사하고, 위반하면 페이지 대신 error를 돌려주며 "같은 URL을 재시도하지 말라"고 지시합니다.

특히 깊이(depth) 추적이 정교합니다. 시드는 깊이 0으로 미리 등록되고, 실제로 가져온 페이지에 링크로 등장한 URL만 깊이 +1로 등록됩니다. 그래서 에이전트가 부모 페이지에 없는 URL을 지어내 요청하면 이렇게 거부됩니다.

# web_tools.py — fetch_url()
depth = state.url_depth.get(url)
if depth is None:
    return _reject(
        "URL not reachable from a seed within the crawl graph "
        "(was not returned as a link by any fetched page)"
    )

 

즉 LLM이 환각으로 아무 URL이나 부르며 범위를 벗어나는 것을 코드가 물리적으로 봉쇄합니다. README가 언급한 --web-max-pages(기본 100)·허용 호스트 외에도, 코드에는 --web-max-depth(기본 2)·--web-allowed-path-prefix·--web-denied-path-substring가 더 있습니다.

또 하나 눈에 띄는 것은 증강 가드(augmentation guard) 입니다. 문서를 쓰는 write_concept_doc(bundle_tools.py)은, web 패스가 기존 BigQuery Table 문서의 # Schema 필드 집합을 줄이거나 # Citations 항목 수를 감소시키는 쓰기를 거부합니다. 주석이 그 의도를 그대로 설명합니다.

"Augmentation guard: during the web pass, refuse writes that shrink an existing BigQuery Table doc's # Schema field set or # Citations entry count. The BQ pass populates these from real metadata; the web pass must augment, not replace."

 

BQ 패스가 실제 메타데이터로 채워 넣은 사실을, web 패스가 실수로 덮어쓰지 못하게 막는 안전장치입니다. "먼저 사실로 뼈대, 그다음 보강만"이라는 원칙을 코드로 집행한 셈입니다.

시각화 — 그리고 'self-contained'의 정확한 의미

visualize는 번들을 단일 인터랙티브 HTML로 렌더합니다. 개념을 노드로, 링크를 간선으로 그린 힘-기반(force-directed) 그래프에, 'Cited by' 백링크·검색·타입 필터·상세 패널을 붙였습니다.

여기서 한 가지 정확히 짚을 점이 있습니다. README는 이를 "self-contained(자족형)"라고 부르는데, 소스를 보면 뉘앙스가 있습니다. CSS·JS는 인라인되고 번들 데이터는 JSON으로 파일에 임베드되므로 "데이터가 페이지를 떠나지 않는다" 는 말은 정확합니다. 다만 뷰어는 그래프 라이브러리 cytoscape와 마크다운 렌더러 marked를 CDN에서 로드합니다. 즉 데이터는 로컬에 머물지만, 페이지가 완전한 오프라인 동작을 보장하는 것은 아닙니다. 오프라인·폐쇄망 환경이라면 이 점을 고려하는 것이 좋습니다.

---

이미 있던 것들과 무엇이 다른가?

OKF를 처음 보면 이런 의문이 듭니다. "MCP랑 뭐가 다르지?", "그냥 dbt나 데이터 카탈로그 아냐?" 인접한 것들과 나란히 두고 보면 OKF의 자리가 오히려 선명해집니다.

대상	무엇인가 (한 줄 사실)	OKF와의 관계·차이
MCP (Model Context Protocol)	AI 앱과 서버가 런타임에 컨텍스트·툴을 주고받는 JSON-RPC 기반 프로토콜	직교(orthogonal). MCP는 동작(전송·호출이 본질, 서버가 떠 있어야 함), OKF는 정적 산출물(파일이 전부, 실행 주체 없음). 경쟁이 아니라 층위가 다릅니다
AGENTS.md / CLAUDE.md	에이전트에게 규약·지시를 주는 리포 루트의 단일 마크다운 파일	같은 계보(마크다운 = 에이전트가 읽는 것). 발표 글이 영감으로 인용. 차이: 이들은 행동 지시 파일 한 개, OKF는 상호링크된 지식 코퍼스 전체
dbt Semantic Layer / MetricFlow	메트릭을 YAML로 정의하면 쿼리 시점에 SQL을 생성·실행하는 시맨틱 레이어	차이: MetricFlow의 메트릭은 실행 가능한 정의(실제 값을 계산), OKF의 Metric 개념은 서술적 지식(계산법을 설명할 뿐 실행하지 않음). 상호보완
OpenMetadata · DataHub · Apache Atlas	자체 DB·API를 갖춘 오픈소스 메타데이터 카탈로그 플랫폼(서비스)	핵심 대비: 이들은 서비스 소유 저장소 + API(메타데이터가 DB에 살고 API로만 접근), OKF는 파일 = 배포 단위(DB·서버 없이 git clone이면 끝). OKF는 대체가 아니라 이들 사이의 교환 포맷
Collibra · Unity Catalog · Dataplex	상용·플랫폼 데이터 카탈로그/거버넌스	README가 이들을 경쟁자가 아니라 OKF 생산자(export 파이프라인)로 지목. 참고로 Google Dataplex는 2026-04 'Knowledge Catalog'로 개명됐고(OKF 저장소명 knowledge-catalog와 일치), OKF를 ingest하도록 업데이트됐습니다
docs-as-code / metadata-as-code	문서·메타데이터를 소스코드처럼 git에 두는 실천 운동	가장 큰 겹침. OKF는 스스로를 "metadata as code"로 규정합니다. 차이: 이 운동은 실천·철학이지 포맷 명세가 아닙니다. OKF는 그 철학을 상호운용 가능한 최소 규칙 명세로 못박은 것

이 표를 관통하는 결론은 하나입니다. 선행 기술과 OKF의 기여를 구분해야 합니다.

"마크다운 + frontmatter로 지식베이스를 만든다"는 아이디어 자체는 완전한 선행 기술입니다. Obsidian·Notion, MkDocs·Hugo의 frontmatter 관행, docs-as-code 운동, 그리고 특히 Karpathy의 LLM 위키가 이미 있었습니다. index.md·log.md 같은 구체적 장치까지 그 계보에서 왔습니다.

그러면 OKF가 실제로 새로 한 일은 무엇일까요? 그 패턴을 "상호운용을 위해 최소 규칙만 명세한 벤더 중립 교환 포맷"으로 고정한 것입니다. 필수 필드를 type 하나로 못박고, 관대한 소비 모델·무유형 링크·예약 파일명·적합성 규칙을 정의해서, 독립적으로 만들어진 생산자와 소비자가 중앙 권위나 필수 SDK 없이 지식 번들을 주고받게 한 것 — 이것이 기여입니다. OKF는 dbt처럼 메트릭을 실행하지도, OpenMetadata처럼 서비스·API를 제공하지도, MCP처럼 런타임 전송을 하지도 않습니다. 대신 이들 사이의 중립적 교환 계층을 자처합니다.

참고로, 구조적으로는 OKF 번들을 MCP 서버가 리소스로 노출해 에이전트에 서빙하는 것도 상상할 수 있습니다. 다만 이는 두 규약의 상호보완성에 대한 추론이며, 문서화된 통합 사례를 확인하지는 못했습니다.

---

OKF의 계보: Karpathy의 LLM 위키에서 Memex까지

OKF는 무에서 나온 발명이 아닙니다. "마크다운 + frontmatter로 지식을 관리한다"는 관행은 이미 실무에서 굳어지고 있었고, OKF는 그것을 표준으로 못박은(specified) 산물입니다. 스펙 §10이 이를 스스로 인정합니다 — OKF는 (1) LLM '위키' 저장소, (2) Obsidian·Notion 같은 개인 지식도구, (3) "metadata as code"와 의도적으로 가깝다고 밝히면서, 이들과 다른 단 하나의 차이는 "specified", 즉 상호운용에 필요한 최소 규칙을 도구를 강요하지 않으면서 명문화했다는 점이라고 말합니다.

가장 직접적인 조상은 Andrej Karpathy의 LLM 위키 패턴입니다. 발표 글도 이를 영감의 원천으로 명시합니다. Karpathy의 구상은 세 개의 레이어로 이루어집니다.

레이어	역할	OKF에서
Raw sources	LLM이 읽되 절대 수정하지 않는 불변의 원본	(번들 밖 원자료)
Wiki	LLM이 생성·유지하는 마크다운 지식	OKF 번들 그 자체
Schema	CLAUDE.md 같은 설정 문서로 구조·규약을 지시	스펙 + frontmatter 규약으로 형식화

Karpathy 패턴에는 세 개의 연산(ingest·query·lint)과 두 개의 운영 파일(index.md·log.md)이 있습니다. OKF가 물려받은 것과 의도적으로 물려받지 않은 것을 나눠 보면 성격이 선명해집니다.

• 물려받음: index.md와 log.md는 파일명·역할까지 거의 그대로 계승됐습니다. Karpathy의 "한 소스가 보통 10~15페이지를 건드린다"는 관찰은 발표 글의 대표 인용으로 재등장합니다.
• "LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass. The bookkeeping that causes humans to abandon personal wikis is exactly what LLMs are good at." — Andrej Karpathy (LLM은 지루해하지 않고, 상호참조 갱신을 잊지 않으며, 한 번에 15개 파일을 건드릴 수 있다. 인간이 개인 위키를 포기하게 만드는 바로 그 부기(bookkeeping)를 LLM은 잘한다.)
• 형식화함: OKF는 Karpathy 패턴에 없던 상호운용 규칙을 더했습니다 — 유일 필수 필드 type, 적합성 규칙, "소비자는 번들을 거부하면 안 된다"는 관용적 소비 모델, 무유형 방향성 링크 그래프. 개인 한 명의 위키를 넘어 조직 간 교환을 노렸기에 필요한 최소 계약을 표준화한 것입니다.
• 물려받지 않음: OKF의 Non-goals는 저장·서빙·쿼리 인프라를 규정하지 않겠다고 못박습니다. 그래서 Karpathy의 query/lint 연산은 스펙에 들어오지 않고 소비자 재량으로 남습니다.

더 먼 계보로, Karpathy의 글은 Vannevar Bush가 1945년 제안한 "Memex" — 문서만큼이나 문서 사이의 연결이 중요한 개인 큐레이션 저장소 — 까지 거슬러 올라갑니다. Bush가 풀지 못한 문제는 "유지보수"였고, LLM이 그 부기 비용을 0에 가깝게 만들어 이 오래된 비전을 실현 가능하게 했다는 것이 논지입니다. (다만 이 Memex 연결은 OKF 스펙 본문이 아니라 Karpathy의 글을 경유한 것입니다.)

마지막으로 제품화입니다. 발표 글은 "Google Cloud의 Knowledge Catalog를 OKF를 ingest해 우리 에이전트에 서빙할 수 있도록 업데이트했다"고 밝힙니다. 생산 측은 참조 에이전트로, 소비 측은 시각화 뷰어로 실체화됩니다. 그리고 GA4 e-commerce·Stack Overflow·Bitcoin 세 공개데이터셋 번들이 각각 viz.html과 함께 제공되어, 스펙 → 생산 에이전트 → 소비 뷰어의 전 경로를 직접 만져볼 수 있습니다.

---

한계점

정직하게 보려면 밝은 면만 봐선 안 됩니다. OKF의 한계 대부분은 결함이라기보다 의식적인 범위 축소이지만, 그 "밀려난 책임들"이 어디로 떨어지는지는 분명히 알아야 합니다. 모두 스펙 원문에 근거한 것입니다.

• 링크가 무유형이다.
  "그래프 형태"를 장점으로 내세우지만, 관계의 종류는 링크가 아니라 본문 산문에 있습니다. 그래서 "이 테이블에 의존하는 모든 지표를 찾아라" 같은 기계적 그래프 추론이 스펙 레벨에서 불가능합니다. 관계 유형을 알려면 결국 LLM이 산문을 읽어 해석해야 하고, 이는 "SDK 없이 파싱 가능"이라는 강점과 긴장 관계에 놓입니다.
• 품질 보증이 약하다.
  type 하나만 있고 본문이 비어도 형식적으로는 '적합'입니다. 게다가 소비자는 깨진 링크·모르는 타입·누락된 index.md를 이유로 거부할 수 없습니다. 관대함과 품질보증은 정직하게 트레이드오프 관계입니다. 무엇이든 받아들이는 형식은, '적합' 판정이 품질을 거의 보장하지 못한다는 대가를 치릅니다.
• 의미 정합이 소비자에게 전가된다.
  type이 중앙 등록되지 않으므로, 한 조직의 API Endpoint와 다른 조직의 REST API를 맞추는 부담은 전적으로 소비자 몫입니다. 조직 간 교환이 목표인 표준에서 중앙 어휘의 부재는 실질적 마찰 지점입니다.
• 쿼리·스키마 검증이 범위 밖이다.
  OKF 자체에는 쿼리 계층이 없어, 대규모 코퍼스 확장은 index.md와 소비자측 검색에 의존합니다. 또 resource는 URI일 뿐, OKF가 그 밑단 자산의 스키마를 검증하지는 않습니다(도메인 스키마는 Avro/Protobuf/OpenAPI에 위임).
• 신선도·거버넌스가 미성숙하다.
  timestamp는 권장, log.md는 선택이라 드리프트(stale claim) 방지는 강제되지 않는 관례에만 의존합니다. Karpathy 원류에 있던 lint(모순·stale·orphan 검사)가 표준 요소로 들어와 있지 않습니다. 접근제어·PII·거버넌스 모델은 스펙 어디에도 없습니다 — "누구나 생산·소비"라는 개방성의 이면입니다. 문서 스스로도 "Version 0.1 — Draft" 임을 밝힙니다.

요컨대 실무 판단의 핵심은 "OKF가 무엇을 못 하는가"가 아니라, "밀려난 그 책임들을 우리 소비 스택이 감당할 준비가 되었는가" 입니다.

---

실무에서는 어떻게 볼까?

아직 v0.1 Draft이므로 프로덕션 도입을 서두르기보다, 역할을 나눠 실험해 보는 편이 좋습니다.

• 적합한 자리: 에이전트에게 먹일 데이터 카탈로그/도메인 지식을 git으로 버전관리하고 싶을 때. 마크다운이라 PR·diff·리뷰가 그대로 되어, 발표 글의 표현처럼 "지식 큐레이션이 평범한 소프트웨어 엔지니어링 활동"이 됩니다.
• 신중할 자리: 관계 유형을 이용한 정밀한 그래프 질의, 접근제어가 필요한 민감 데이터, 엄격한 스키마 검증이 필요한 곳. 이건 OKF 밖에서 소비자가 채워야 합니다.

도입 전 체크리스트로는 다음을 권합니다.

• 우리 소비 측(LLM·검색기·뷰어)이 관대한 소비(깨진 링크·미지 타입 허용)를 감당하는가?
• type 값의 공통 어휘를 조직 내에서 합의할 수 있는가?
• timestamp·log.md로 신선도를 유지할 운영 규율이 있는가?
• 민감정보·접근제어는 OKF 밖에서 처리할 설계가 있는가?
• (참조 뷰어 사용 시) CDN 의존을 감안했는가, 아니면 자체 소비기를 붙일 것인가?

단, 한 가지 현실적인 주의가 있습니다. OKF의 매력인 "그냥 마크다운"은 곧 "강제하는 게 거의 없다"는 뜻이기도 합니다. 포맷이 보장해 주지 않는 품질·정합·거버넌스를, 결국 여러분의 파이프라인이 스스로 책임져야 합니다. OKF는 문제를 풀어주는 도구가 아니라, 문제를 풀 수 있는 얇고 이식 가능한 표면을 주는 규약에 가깝습니다.

---

정리

OKF의 기여는 새로운 기술이 아니라 합의에 있습니다. 마크다운+frontmatter 지식베이스라는 아이디어 자체는 Obsidian, Karpathy의 LLM 위키, docs-as-code 등으로 이미 존재했습니다. OKF가 한 일은 그중 상호운용에 꼭 필요한 최소 규칙만 골라 명세로 못박은 것입니다. 발표 글의 마지막 문장이 이 태도를 잘 보여줍니다.

"The format itself is the contribution. ... Whatever shape your knowledge takes today, OKF is designed to be the lingua franca it can be exchanged for tomorrow."
(형식 그 자체가 기여다. … 오늘 당신의 지식이 어떤 모양이든, OKF는 내일 그것이 교환될 수 있는 공용어가 되도록 설계되었다.)

 

이 "공용어"가 실제로 자리 잡을지는, 스펙의 관대함이 밀어낸 품질·거버넌스 문제를 생태계가 어떻게 메우느냐에 달려 있다고 봅니다. 적어도 시도의 비용은 충분히 낮습니다

---

참고 출처

• 저장소·참조 구현: okf/README.md, okf/src/reference_agent/ (web_tools.py, bundle_tools.py 등) — 同 저장소
• 발표 블로그: "How the Open Knowledge Format can improve data sharing" (Google Cloud, 2026-06-13, Sam McVeety·Amir Hormati)
• 계보: Andrej Karpathy, "LLM Wiki" gist — gist.github.com/karpathy/442a6bf555914893e9891c11519de94f