오픈 날리지 포맷(OKF) — 흩어진 지식을 에이전트가 읽는 하나의 표준으로

AI 에이전트에게 이렇게 물어봅시다. "우리 이벤트 스트림에서 주간 활성 사용자(WAU)는 어떻게 계산하지?"

간단해 보이는 질문이지만, 답은 한 곳에 없습니다. 테이블 정의는 메타데이터 카탈로그에, 계산 규칙은 사내 위키에, 예외 처리는 어느 노트북 셀의 주석에, 그리고 "사실 그 지표는 2024년부터 정의가 바뀌었어"라는 결정적 맥락은 시니어 엔지니어의 머릿속에 있습니다. 에이전트는 이 서로 호환되지 않는 흩어진 표면들에서 답을 짜맞춰야 합니다.

"An AI agent needs to answer 'How do I compute weekly active users from our event stream?' — it has to assemble the answer from these scattered, mutually incompatible surfaces." — Google Cloud, OKF 발표글

2026년 6월 13일, Google Cloud가 이 오래된 문제에 답을 내놨습니다. 오픈 날리지 포맷(Open Knowledge Format, OKF) v0.1. 거창한 새 플랫폼이 아닙니다. 오히려 정반대 — 그냥 마크다운 파일 몇 개입니다. 그런데 바로 그 단순함이 핵심입니다.

이 글은 OKF가 무엇인지만 설명하지 않습니다. 왜 이런 게 필요했는지를 더블린 코어와 시맨틱 웹까지 거슬러 올라가 짚고, 왜 30년간 어려웠던 일이 이번엔 '그냥 마크다운'으로 풀렸는지, 그리고 2026년 에이전트 시대에 이게 어떤 자리를 차지하는지까지 따라갑니다. 용어가 생소해도 괜찮습니다. 그림과 직접 만져보는 탐색기로 하나씩 풀어가겠습니다.

이 글에서 다룰 것

1. 문제 — 파편화된 컨텍스트 풍경
2. 역사 — '데이터를 함께 쓰자'는 30년의 꿈
3. 전환점 — Karpathy의 'LLM 위키' 패턴
4. OKF란? — 그냥 마크다운, 그냥 파일, 그냥 YAML
5. 아키텍처 — 파일이 곧 개념, 링크가 곧 관계
6. OKF vs MCP vs llms.txt — '무엇'과 '어떻게'
7. 논쟁 — "표준이냐, 그냥 폴더냐"
8. 2026년, OKF의 자리

1. 문제 — 파편화된 컨텍스트 풍경

2026년의 파운데이션 모델은 똑똑합니다. 문제는 모델이 아니라 맥락(context)입니다. 특히 에이전트가 실제 일을 하려면, 조직 내부의 살아있는 지식이 필요한데 — 그게 사방에 흩어져 있습니다.

Google은 이 상황의 비용을 세 가지로 정리합니다.

• 에이전트 빌더마다 컨텍스트 조립을 맨바닥부터 다시 만든다.
• 카탈로그 벤더마다 똑같은 데이터 모델을 다시 발명한다.
• 지식은 그것을 만든 시스템 뒤에 갇힌 채로 남는다.

핵심 통찰은 이것입니다. "필요한 건 또 하나의 서비스가 아니라, 하나의 포맷이다." 누구나 SDK 없이 만들 수 있고, 누구나 통합 작업 없이 읽을 수 있고, 시스템·조직·도구 사이를 이동해도 살아남으며, 코드 옆 버전 관리에 함께 사는 — 그리고 사람과 에이전트가 같은 파일을 번역 없이 읽는 포맷. 그런데 이 꿈은 사실 어제오늘의 것이 아닙니다.

2. 역사 — '데이터를 함께 쓰자'는 30년의 꿈

"흩어진 데이터에 공통의 의미를 부여해 기계가 이해하게 하자"는 꿈은 인터넷만큼이나 오래됐습니다. OKF를 제대로 이해하려면 이 계보를 알아야 합니다.

여기서 자연스러운 질문. 그 좋은 시맨틱 웹·RDF·온톨로지는 왜 30년간 세상을 못 덮었을까요? Ontotext의 회고가 솔직합니다 — "시맨틱 웹 20년, 그리고 손에 꼽을 만큼의 엔터프라이즈 지식 그래프." 이유는 분명합니다.

마지막 줄이 결정적입니다. 시맨틱 웹은 "기계가 읽을 수 있도록 사람이 엄격하게 쓰는" 세계였습니다. OKF는 그 부담을 뒤집습니다 — "사람이 편하게 쓴 마크다운을, 똑똑해진 기계(LLM)가 알아서 이해하는" 세계입니다. 이 역전을 가능하게 한 직접적 계기가 바로 다음 장입니다.

3. 전환점 — Karpathy의 'LLM 위키' 패턴

2026년 4월, Andrej Karpathy(OpenAI 공동창업자, 전 테슬라 AI 디렉터)가 트위터에 한 패턴을 공유했습니다. 곧 'LLM 위키(LLM wiki)'라 불리게 된 이 아이디어는, 깃허브 별 5,000개 이상을 받으며 OKF의 직접적 영감이 됩니다.

핵심 통찰은 이 한 문장입니다.

"LLM은 지루해하지 않고, 크로스레퍼런스 갱신을 잊지 않으며, 한 번에 15개 파일을 건드릴 수 있다." — Andrej Karpathy

무슨 뜻일까요? 위키(서로 링크된 문서 더미)를 잘 가꾸는 일은 사람에겐 고역입니다. 항목이 늘면 일관성이 깨지고, 링크가 끊어지고, 누가 업데이트를 까먹습니다. 그런데 LLM은 바로 이 지겨운 유지보수를 지치지 않고 한다는 겁니다. 그래서 발상을 바꿉니다 — 모델이 매번 같은 문서를 검색(RAG)하게 하는 대신, 에이전트에게 공유 마크다운 라이브러리를 주고 그걸 직접 읽고 갱신하게 하자. 시간이 갈수록 쓸모가 복리로 쌓이는 지식 베이스가 됩니다.

Karpathy의 위키는 3계층으로 단순합니다.

여기서 CLAUDE.md(또는 Codex의 AGENTS.md)는 "이 위키가 무엇에 관한 것이고, 어떤 규칙을 따르며, 충돌을 어떻게 처리할지"를 모델에게 알려주는 편집 지침입니다. 이게 없으면 위키는 표류합니다 — 페이지가 제멋대로가 되고, 명명 규칙이 쪼개지고, 링크가 깨집니다.

흥미로운 점은, 수백~수천 페이지 규모의 큐레이션된 지식 베이스에서는 이 LLM 위키 패턴이 RAG보다 더 정확하고, 빠르고, 유지하기 쉽다는 평가입니다. 다만 한계도 분명했습니다 — 모두가 제각각 만들었습니다. 어떤 필드를 쓸지, 파일 이름을 뭐라 할지에 대한 상호운용 합의가 전혀 없었죠. Obsidian 볼트, AGENTS.md/CLAUDE.md, index.md+log.md 저장소, "metadata as code" 리포… 패턴은 같은데 방언만 수십 개였습니다.

OKF의 한 줄 정의: 바로 이 'LLM 위키 패턴'을, 이식 가능하고 상호운용되는 포맷으로 형식화한 것. 방언들을 하나의 공용어(lingua franca)로.

4. OKF란? — 그냥 마크다운, 그냥 파일, 그냥 YAML

이제 본론입니다. OKF v0.1의 정의는 놀랄 만큼 간단합니다.

OKF 번들 = YAML 프론트매터가 붙은 마크다운 파일들의 디렉터리. 거기에 상호운용을 위한 소수의 약속된 관례가 더해진 것.

Google은 OKF의 본질을 세 개의 "그냥(just)"으로 설명합니다.

"복잡한 압축 방식도, 새 런타임도, 필수 SDK도 없다." — OKF 발표글

그리고 이 단순함을 떠받치는 3대 설계 원칙이 있습니다.

발표글의 핵심 한 줄: "우리가 이걸 오픈 표준으로 내는 이유는, 지식 포맷의 가치는 누가 소유하느냐가 아니라 몇 명이 그 말을 하느냐에서 나오기 때문이다."

5. 아키텍처 — 파일이 곧 개념, 링크가 곧 관계

추상적인 설명은 충분합니다. OKF 번들이 실제로 어떻게 생겼는지 구체적으로 봅시다. Google이 든 영업(sales) 도메인 예시입니다.

디렉터리 = 개념의 지도

sales/
├── index.md
├── datasets/
│   ├── index.md
│   └── orders_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   └── customers.md
└── metrics/
    ├── index.md
    └── weekly_active_users.md

핵심 규칙: 개념 하나 = 파일 하나. 그리고 파일 경로가 곧 그 개념의 정체성(identity)이다. 테이블·데이터셋·지표·플레이북·런북·API… 잡고 싶은 무엇이든 한 파일이 됩니다.

문서 = 프론트매터 + 본문

각 개념 문서는 위에 YAML 프론트매터(구조화 필드), 아래에 마크다운 본문(사람이 읽는 설명)으로 이루어집니다. orders.md를 보면.

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

# Schema
| Column | Type | Description |
|--------|------|-------------|
| order_id    | STRING | 전역 고유 주문 ID |
| customer_id | STRING | [customers](/tables/customers.md)로의 FK |

# Joins
customer_id 로 [customers](/tables/customers.md)와 조인.

링크 = 그래프

여기서 마법이 일어납니다. 개념들이 평범한 마크다운 링크로 서로를 가리키면([customers](/tables/customers.md)), 단순한 폴더 계층이 관계의 그래프로 변합니다. 파일시스템보다 훨씬 풍부한, 진짜 지식 그래프가 공짜로 생기는 거죠. 여기에 선택적으로 index.md(점진적 안내)와 log.md(시간순 변경 이력)를 둘 수 있습니다.

놀랍게도 v0.1 스펙 전체가 한 페이지에 들어갑니다 — 적합성 기준, 상호 링크 규칙, 예약 파일명까지 전부.

말로만 보면 와닿지 않으니, 직접 만져보세요. 아래 탐색기에서 파일을 클릭하고, 본문 속 파란 [링크]를 눌러 개념 사이를 이동해 보세요. "주간 활성 사용자를 어떻게 구하나?"의 답이 어떻게 하나의 파일에 깔끔히 담기는지 보입니다.

Google이 함께 내놓은 것 (레퍼런스 구현)

OKF는 말뿐인 스펙이 아닙니다. Google은 "당장 써볼 수 있는" 세 가지를 함께 공개했습니다.

저장소는 GitHub GoogleCloudPlatform/knowledge-catalog/okf에 공개돼 있고, Google Cloud의 Knowledge Catalog는 이미 OKF를 수집해 에이전트에 서빙하도록 업데이트됐습니다. 다만 Google은 못을 박습니다 — "이것들은 의도적으로 개념 증명(PoC)이다. 에이전트는 OKF를 만드는 한 가지 방법을 보여줄 뿐, 포맷 자체는 특정 프레임워크나 LLM을 요구하지 않는다."

6. OKF vs MCP vs llms.txt — '무엇'과 '어떻게'

OKF 얘기가 나오면 꼭 따라오는 질문. "그거 MCP랑 뭐가 달라요?" 좋은 질문이고, 답은 서로 경쟁이 아니라 보완입니다.

그림으로 그리면 이렇게 쌓입니다. 에이전트가 일을 시작하기 전에 읽는 큐레이션된 지식은 OKF가, 일을 하는 도중에 부르는 실시간 도구·데이터는 MCP가, 그리고 공개 웹의 안내는 llms.txt가 맡습니다. 셋은 서로를 취소하는 게 아니라 더 완전한 그림으로 합쳐집니다.

한 문장 요약: MCP가 "에이전트가 어떻게 손을 뻗는가"라면, OKF는 "에이전트가 무엇을 알아야 하는가"입니다. 손과 지식은 다툴 이유가 없습니다.

이는 우리가 이전 글 컨텍스트 엔지니어링에서 다룬 흐름과도 정확히 맞물립니다. 프롬프트(문장)에서 컨텍스트(모델이 보는 모든 정보)로 무게중심이 옮겨간 시대에, OKF는 그 '컨텍스트'를 이식 가능한 파일로 포장하는 표준 봉투인 셈입니다.

7. 논쟁 — "표준이냐, 그냥 폴더냐"

물론 칭찬만 있는 건 아닙니다. 발표 직후 가장 날카로운 비평의 제목이 핵심을 찌릅니다 — "구글의 새 포맷: 표준인가, 그냥 폴더인가?"

비평의 골자는 "OKF는 구조는 표준화했지만 의미는 비워뒀다"는 것입니다. 여기서 두 종류의 상호운용성을 구분해야 합니다.

문제는 이렇습니다. 두 번들이 각각 완벽히 '적합(conformant)'한데도, 공유 어휘가 없으면 서로 통하지 않습니다. A사는 type: BigQuery Table이라 쓰고 B사는 type: table이라 쓰면 — 같은 뜻이지만, A용으로 만든 에이전트가 B를 못 알아봅니다. 비평가가 든 구체적 문제들.

• 어휘 혼돈: BigQuery Table vs table — 정규화할 레지스트리가 없다.
• 타입 없는 링크: 개념 간 관계에 의미가 정의돼 있지 않다(그냥 링크일 뿐).
• v0.1조차 불완전: 스펙은 type 하나만 필수라면서, 정작 구글의 레퍼런스 파서는 4개 필드를 요구한다.
• 구글 생태계 중력: "벤더 중립"을 표방하지만 기본 구현은 Gemini·BigQuery·Google Cloud로 기운다.

아래에서 이 간극을 직접 느껴보세요. 두 번들 다 '적합'한데도 어휘가 다르면 에이전트가 헷갈리고, 공유 어휘 레지스트리를 켜면 비로소 통합니다.

그렇다면 이건 실패일까요? 꼭 그렇진 않습니다. 비평가조차 인정합니다 — "어휘를 두고 다투기 전에, 일단 패키지부터 표준화하는 건 현명할 수 있다." 시맨틱 웹이 완벽한 의미를 먼저 합의하려다 30년을 끌었다는 걸 떠올리면, OKF의 "구조부터, 의미는 나중에" 전략은 오히려 교훈을 학습한 선택입니다. Google도 이를 분명히 합니다.

"OKF v0.1은 완성된 표준이 아니라 출발점이다. 더 많은 생산자와 소비자가 등장하고, 에이전트가 실제로 어떤 지식 표현을 필요로 하는지 함께 배워가며 포맷은 진화할 것이다."

스펙은 버전이 매겨져 있고, 하위 호환을 지키며 성장하도록 설계됐습니다. 즉 의미적 상호운용성은 v0.2 이후의 숙제로 명시적으로 남겨둔 것이죠.

8. 2026년, OKF의 자리

자, 그래서 2026년 지금 OKF는 어떤 자리에 설까요?

한발 물러서서 보면, OKF는 두 거대한 흐름이 만나는 지점에 있습니다. 하나는 30년 묵은 데이터 상호운용성의 꿈(더블린 코어 → 시맨틱 웹 → 지식 그래프)이고, 다른 하나는 2026년 에이전트 시대의 현실적 필요(LLM 위키, 컨텍스트 엔지니어링)입니다. OKF의 영리함은, 옛 꿈을 옛 방식(무거운 형식주의)으로 풀지 않고 새 도구(마크다운을 너그럽게 읽는 LLM)로 푼 데 있습니다.

성공할까요? 그건 기술이 아니라 채택에 달려 있습니다. 발표글의 말대로 "포맷의 가치는 몇 명이 그 말을 하느냐"에서 나오니까요. schema.org가 검색의 공용어가 된 것처럼 OKF가 에이전트 지식의 공용어가 될지, 아니면 수많은 "○○ 포맷" 중 하나로 남을지는 앞으로의 커뮤니티가 결정합니다. 분명한 건, '또 하나의 독점 플랫폼'이 아니라 '누구나 쓸 수 있는 텍스트 파일'로 출발했다는 점이 그 가능성을 크게 열어둔다는 것입니다.

그리고 우리에게 주는 실용적 교훈은 더 즉각적입니다 — 지금 당신의 팀 지식이 어떤 형태이든(위키든, 카탈로그든, 시니어의 머릿속이든), 그것을 에이전트가 읽을 수 있는 마크다운으로 정리해두는 일은 이미 가치가 있다. OKF는 그 정리에 공용 봉투를 씌워줄 뿐입니다.

발표글의 마지막 문장: "오늘 당신의 지식이 어떤 모양이든, OKF는 내일 그것을 교환할 수 있는 공용어가 되도록 설계되었다."

핵심 요약

함께 읽으면 좋은 글 모델 주변 정보 전체를 설계하는 컨텍스트 엔지니어링 가이드, 에이전트가 도구와 데이터에 어떻게 닿는지를 다루는 MCP 완전 이해, 그리고 지식을 형식화해온 오랜 역사 온톨로지의 역사를 이어 보면 그림이 완성됩니다.

참고 자료: Sam McVeety & Amir Hormati, "How the Open Knowledge Format can improve data sharing"(Google Cloud Blog, 2026.06.13) · Andrej Karpathy, "LLM wiki" 패턴(2026.04) · Marc Bara, "Google's New Format for Agent Context: A Standard, or Just a Folder?"(Medium) · Ontotext, "The Semantic Web: 20 Years Later" · Tim Berners-Lee, "The Semantic Web"(2001) · Dublin Core Metadata Initiative · explainx.ai, nexterwp 등 OKF·MCP·llms.txt 비교 자료.