OKF(Open Knowledge Format): AI 에이전트 시대의 지식 공유 표준
OKF(Open Knowledge Format): AI 에이전트 시대의 지식 공유 표준
AI가 똑똑한데도 우리 회사 일을 못하는 이유, 한 번쯤 의심해보신 적 있으신가요?
모델은 점점 좋아지는데, 막상 업무에 붙여보면 기대보다 훨씬 허술하게 느껴지는 경우가 많죠. 문제는 모델의 능력이 아니에요. 정작 발목을 잡는 건 "맥락(context)의 부재" 입니다. 우리 회사의 지식이 도구마다, 팀마다, 사람마다 다 흩어져 있어서 AI가 매번 새로 조립해야 하거든요.
Google Cloud Data Cloud팀이 2026년 6월 12일 공개한 OKF(Open Knowledge Format) v0.1 Draft는 바로 이 문제를 다룹니다. YAML frontmatter가 붙은 마크다운 파일들의 디렉토리로 지식을 표현하는 개방형 스펙인데요, 생각보다 훨씬 단순하고 강력해요.
AI 에이전트가 답을 매번 새로 조립하는 문제
조직의 지식은 지금 어디에 살고 있을까요?
- 자체 API를 가진 메타데이터 카탈로그
- 위키, 서드파티 시스템, 공유 드라이브
- 코드 주석과 노트북 셀
- 그리고 몇몇 시니어 엔지니어의 머릿속
AI 에이전트가 "이벤트 스트림에서 주간 활성 사용자(WAU)를 어떻게 계산하지?"라는 질문에 답하려면 이 호환되지 않는 표면들을 가로질러 매번 답을 새로 조립해야 해요.
결과는? Google Cloud 블로그(2026-06-12)의 표현을 빌리면 이렇습니다.
모든 에이전트 빌더가 똑같은 컨텍스트 조립 문제를 처음부터 풀고, 모든 카탈로그 벤더가 똑같은 데이터 모델을 재발명하며, 지식 자체는 그것을 만든 표면 뒤에 잠긴다.
벤더 락인, 중복 노력, 그리고 지식의 사일로화. 에이전트 시대에 이 문제는 더 심각해져요.
OKF란 무엇인가: YAML frontmatter + 마크다운 디렉토리
OKF(Open Knowledge Format): YAML frontmatter가 붙은 마크다운 파일들의 디렉토리로 지식을 표현하는 vendor-neutral 개방형 스펙(v0.1 Draft). 사람도 읽고 AI 에이전트도 파싱할 수 있는 단일 포맷을 지향하며, Google Cloud Data Cloud팀이 2026년 6월 12일 공개했습니다.
한 줄로 요약하면 이렇게 돼요. "파일을 cat 할 수 있으면 OKF를 읽을 수 있고, repo를 git clone 할 수 있으면 OKF를 배포할 수 있다."
GitHub repo(GoogleCloudPlatform/knowledge-catalog)에 Apache 2.0 라이선스로 공개돼 있고, "not an official Google product"라는 면책 문구가 있는 만큼, Google Cloud Data Cloud팀이 주도하는 개방 스펙이지 구글 공식 제품은 아니에요. 하지만 그게 오히려 이 스펙의 강점이기도 합니다. 어떤 클라우드, 어떤 도구에도 묶이지 않는다는 뜻이니까요.
뿌리가 된 패턴: Karpathy의 LLM Wiki
OKF는 무에서 나온 게 아니에요. Google Cloud 블로그는 명시적으로 "Andrej Karpathy의 LLM-wiki 패턴을 포터블·상호운용 가능한 포맷으로 공식화한 것" 이라고 밝힙니다.
Karpathy의 핵심 아이디어는 RAG와의 대비에서 시작해요.
보통 RAG는 매 질문마다 원본 문서에서 지식을 "처음부터 재발견"합니다. 축적이 없어요. 반면 LLM Wiki는 LLM이 영속적이고 복리로 쌓이는(persistent, compounding) 위키를 점진적으로 구축하고 유지합니다. 지식은 한 번 컴파일되고 그 뒤로 계속 최신 상태로 유지돼요.
RAG는 매번 까먹는다. 위키는 쌓인다.
Karpathy가 말한 핵심이 있어요.
"LLMs don't get bored, don't forget to update a cross-reference, and can touch 15 files in one pass." (LLM은 지루해하지 않고, 상호 참조 갱신을 잊지 않으며, 한 번에 15개 파일을 건드릴 수 있다.)
사람이 개인 위키를 포기하는 이유가 정확히 유지보수 부담인데, 그게 LLM이 제일 잘하는 일이에요. 3계층 아키텍처는 이렇습니다.
- Raw sources — 원본 문서(불변, source of truth). LLM은 읽기만.
- The wiki — LLM이 생성·유지하는 마크다운 디렉토리. 요약, 엔티티 페이지, 개념 페이지.
- The schema —
CLAUDE.md(Claude Code)나AGENTS.md(Codex) 같은 설정 문서. 위키 구조와 관례를 LLM에게 알려주는 핵심 파일.
비유하자면 "Obsidian이 IDE, LLM이 프로그래머, 위키가 코드베이스"예요.
OKF는 어떻게 작동하나: Bundle, Concept, ID
OKF v0.1 Draft의 구조를 정리하면 이렇습니다.
Knowledge Bundle: 자족적·계층적 지식 문서 모음으로, 배포 단위예요. 테이블, API, 메트릭, 비즈니스 프로세스처럼 실물 자산도 추상 개념도 모두 담을 수 있어요.
Concept: 번들 내 지식 1단위 = 마크다운 문서 1개.
Concept ID: 번들 내 파일 경로에서 .md를 제거한 것이에요. tables/users.md라면 Concept ID는 tables/users가 됩니다. 파일 경로 자체가 개념의 정체성이에요.
Frontmatter 필드에서 필수는 type 딱 하나예요. (BigQuery Table, Metric, Playbook, API Endpoint 등) 나머지 title, description, resource, tags, timestamp는 권장 필드이고, 생산자가 임의 키를 추가할 수도 있어요.
예약 파일명도 두 개뿐이에요. index.md(progressive disclosure용 디렉토리 목록)와 log.md(변경 연대기, append-only). 그 외 모든 .md는 Concept 문서예요.
"Just markdown / Just files / Just YAML frontmatter" — 이 원칙이 OKF를 압도적으로 가볍게 만들어요.
설계 3원칙: 최소 간섭, 분리, 포맷
OKF의 설계 철학은 3가지로 요약돼요.
첫째, 최소 간섭(Minimally opinionated): 모든 Concept에 요구하는 건 type 필드 하나뿐이에요. 상호운용 표면만 정의하고, 콘텐츠 모델은 생산자의 자유입니다.
둘째, 생산자·소비자 분리(Producer/consumer independence): 누가 쓰든(사람, LLM, 메타데이터 파이프라인) 누가 읽든(에이전트, 뷰어, 다른 LLM) 독립적으로 교체 가능해요. "포맷이 계약(contract)이고, 양 끝 툴링은 독립 스왑."
셋째, 플랫폼이 아니라 포맷(Format, not platform): 특정 클라우드, DB, 모델, 에이전트 프레임워크에 묶이지 않아요. 읽고 쓰고 서빙하는 데 독점 계정이나 SDK가 필요 없습니다.
Google Cloud 블로그의 표현이 인상적이에요. "지식 포맷의 가치는 누가 소유하느냐가 아니라 몇 명이 그 언어를 말하느냐에서 온다."
왜 CLAUDE.md와 AGENTS.md가 핵심인가
여기서 흥미로운 지점이 있어요. OKF 스펙이 명시적으로 거명하는 파일이 CLAUDE.md(Claude Code)와 AGENTS.md(Codex)예요.
이 파일들은 Karpathy의 LLM Wiki 3계층 아키텍처에서 Schema 레이어에 해당해요. 위키 구조와 관례, 워크플로우를 LLM에게 알려주는 설정 문서인 거죠. "이게 LLM을 일반 챗봇이 아니라 규율 있는 위키 관리자로 만든다"고 Karpathy는 표현했어요.
OKF는 이 컨벤션 파일 패턴을 상호운용 표준으로 끌어올린 거예요. 이미 CLAUDE.md를 쓰고 있다면, 그게 바로 OKF가 표준화하려는 패턴의 Schema 레이어입니다.
한 가지 더 — Google Cloud Knowledge Catalog(구 Dataplex, AI 기반 데이터 카탈로그)도 OKF를 ingest해 자사 에이전트에 서빙하도록 업데이트됐어요. "metadata as code" 패턴이 이미 Google 내부 제품과 연결되는 셈이에요.
1인 기업·실무자에게 주는 의미
실무자 관점에서 OKF가 주는 변화를 정리해볼게요.
벤더 락인 탈출: 메트릭과 시맨틱 정의를 BI 도구마다 재정의하던 중복이 git에 사는 마크다운 한 벌로 수렴될 수 있어요.
metadata as code: 지식이 코드 옆 버전관리에 살아 diff, PR, 리뷰가 가능해집니다. 데이터 거버넌스가 코드 거버넌스와 같은 도구 체인을 탈 수 있어요.
AI 에이전트 온보딩 비용 감소: 새 에이전트를 붙일 때마다 컨텍스트를 새로 조립하지 않고, OKF 번들 하나를 mount하면 돼요.
특히 1인 기업이나 소규모 팀이라면 — 이미 CLAUDE.md, AGENTS.md, index.md, log.md, Obsidian 볼트로 LLM Wiki를 굴리고 있다면, 그게 바로 OKF가 표준화하려는 패턴이에요. 표준을 따르면 내 지식이 도구, 조직, 시간을 건너 이식 가능해져요.
"당신의 CLAUDE.md가 이미 표준의 일부였던 거예요."
마무리: 지식 쌓는 방식이 바뀐다
에이전트 시대의 병목은 더 큰 모델이 아니에요. 기계가 읽을 수 있는 형태로 정리된 도메인 지식이 병목입니다.
OKF v0.1 Draft는 그 방향에서 Google Cloud Data Cloud팀이 내놓은 첫 번째 표준 제안이에요. 아직 Draft 단계이고 v0.1 시작점이지만, 방향은 명확합니다. 지식을 쌓는 법이 RAG(매번 재검색)에서 "영속 위키(한 번 컴파일·계속 유지)"로 이동하는 흐름이고, Google이 표준 깃발을 먼저 꽂았어요.
직접 경험해보고 싶다면 GitHub repo를 clone해서 샘플 번들(GA4 e-commerce, Stack Overflow, Bitcoin 공개 데이터셋)을 먼저 살펴보세요. Enrichment agent로 자신의 BigQuery 데이터셋을 OKF로 변환하거나, Static HTML visualizer로 번들을 그래프로 시각화해볼 수도 있어요.
아직 v0.1 Draft예요. 피드백이 표준을 만들어가는 단계입니다.
자주 묻는 질문 (FAQ)
Q: OKF는 RAG와 어떻게 다른가요?
RAG는 매 질문마다 원본 문서에서 지식을 처음부터 재발견합니다. 축적이 없어요. OKF + LLM Wiki 패턴은 LLM이 영속적이고 복리로 쌓이는 위키를 유지해요. 지식이 한 번 컴파일되고 그 뒤로 계속 갱신됩니다. "RAG는 매번 까먹고, 위키는 쌓인다"는 차이예요.
Q: OKF를 쓰려면 어떤 도구가 필요한가요?
특별한 도구가 필요 없어요. "Just markdown / Just files / Just YAML frontmatter"가 OKF의 원칙입니다. 텍스트 에디터와 git이 있으면 충분하고, GitHub에서 그대로 렌더됩니다. 선택적으로 Google이 제공한 Enrichment agent나 Static HTML visualizer를 쓸 수 있지만, 필수는 아니에요.
Q: OKF와 Avro/Protobuf/OpenAPI 같은 스키마는 어떻게 다른가요?
OKF는 도메인 스키마(Avro, Protobuf, OpenAPI 등)를 대체하지 않아요. 참조(reference)할 뿐 흡수하지 않습니다. 기존 스키마는 그대로 두고, OKF는 그 위에서 "이 자산이 무엇인지"를 사람과 AI 에이전트 모두가 읽을 수 있는 형태로 표현하는 레이어예요.
Q: 1인 기업이나 소규모 팀에도 적용할 수 있나요?
네, 오히려 1인 기업에 더 잘 맞을 수 있어요. 이미 CLAUDE.md, AGENTS.md, Obsidian 볼트로 LLM Wiki를 운영하고 있다면 그게 OKF 패턴의 실천이에요. OKF를 명시적으로 따르면 내 지식이 도구와 플랫폼을 건너 이식 가능해지고, 새 에이전트를 붙일 때마다 컨텍스트를 새로 설명할 필요가 없어집니다.
참고 자료
https://github.com/GoogleCloudPlatform/knowledge-catalog
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
