구글이 OKF(Open Knowledge Format)를 공개했다. 한 줄로 줄이면 “AI 에이전트가 먹기 좋게, 조직의 지식을 마크다운 + YAML 파일로 표현하는 벤더 중립 포맷”이다. 마크다운에 YAML 헤더 붙이는 게 뭐 대단한 발명이냐 싶고, 실제로 기술적으로는 새로운 게 거의 없다.
그런데 이걸 포맷의 신선도로 보면 진짜 이야기를 놓친다. OKF는 구글의 전략실에서 튀어나온 게 아니다. 거슬러 올라가면 출발점은 따로 있다 — 이건 군중이 먼저 증명한 수요를, 구글이 뒤늦게 포섭한 사건이다.
수요는 군중이 먼저 증명했다
2026년 4월, Andrej Karpathy가 한 화면에 들어가는 gist 하나(“LLM Wiki”)를 올렸다. 제품도 논문도 아닌, 그냥 ‘아이디어 파일’이었다. 그게 2주 만에 별 5천·포크 4천을 넘기고, 수십 개의 재구현과 VentureBeat 기사를 낳으며 번졌다. 그리고 구글은 그 gist가 터지고 며칠 뒤 벤더 중립 버전인 OKF를 내놨다.
Karpathy 한 명의 일도 아니었다. llms.txt는 2024년 9월에 제안돼 84만 개 사이트가 채택했고, AGENTS.md·CLAUDE.md·.cursorrules는 코딩 에이전트의 사실상 표준 메모리 파일이 됐다. 전부 한 패턴으로 바닥에서 수렴하고 있었다 — 필수 필드 없는 평범한 마크다운 파일을, 에이전트의 맥락이자 지식으로 쓴다. 어떤 벤더가 축복하기 한참 전에, 사람들은 답을 이미 직접 써내고 있었다. 수요는 분명했고, OKF는 그 흐름의 맨 끝에 붙은 정거장이다.
Karpathy가 진짜 제안한 것 — OKF가 가져간 것과 버린 것
여기서 한 번 짚고 갈 게 있다. Karpathy의 핵심은 ‘마크다운 파일’이 아니었다. 그가 친 못은 “RAG 너머 — LLM이 스스로 유지하면서 복리로 불어나는 지식 덩어리” 였다.
기존 RAG는 질문이 들어올 때마다 원본 문서에서 정보를 처음부터 다시 긁는다. 다섯 개 문서를 종합해야 하면 매번 다섯 번 다시 찾는다. 쌓이는 게 없다. Karpathy의 위키는 세 층으로 그걸 뒤집는다 — 원본 소스(고정), 위키(LLM이 통째로 관리하는 마크다운 페이지·인덱스·상호참조), 스키마(유지 방식을 지시하는 CLAUDE.md 같은 설정). 사람은 소스를 큐레이션하고 좋은 질문을 던지는 데 집중하고, 교차참조 갱신과 일관성 관리 같은 나머지는 LLM이 한다. 요점은 단어 하나다 — 쌓인다(compounding).
그럼 OKF는 이 중 뭘 가져갔나. 산출물(파일 포맷) 이다. 버린 건 루프(그 산출물을 복리로 불어나게 만드는 유지 과정) 다. 명사는 표준화했는데 동사는 안 했다. Karpathy 아이디어의 진짜 마법이었던 ‘스스로 쌓여가는 과정’은 OKF에선 숙제로 남는다. 그래서 실물로 만든 샘플 번들을 열어 보면, 잘 만든 데이터 카탈로그 위키 페이지와 구분이 안 된다. 정적인 스냅샷이지, 살아 움직이는 위키가 아니다.
그럼 왜 구글이 또 따로 표준을 냈나
이게 가장 흥미로운 질문이다. 이미 중립 마크다운 표준이 있다 — AGENTS.md다. OpenAI·구글·Cursor·Sourcegraph가 함께 만들어 Linux Foundation 산하 재단이 거버넌스를 갖고, 구글도 공동 저자에 이름이 있다. 코딩 에이전트가 읽는 그 중립 표준을 구글이 이미 같이 만들고 있는데, 왜 지식/데이터 조각만 따로 떼어 단독으로 OKF를 냈을까.
그 조각이 바로 구글의 해자가 있는 자리이기 때문이다. AGENTS.md가 다루는 건 ‘이 프로젝트를 어떻게 빌드·테스트하나’ 같은 코드 맥락이다. 거기엔 클라우드 벤더의 데이터 창고가 낄 자리가 없다. 반면 OKF가 다루는 ‘조직의 지식’은 결국 데이터 웨어하우스에서 나온다 — 어떤 테이블이 뭘 뜻하고, 지표를 어떻게 집계하고, 데이터 계보가 어떻게 되는지. 구글이 스펙과 함께 푼 게 정확히 그 변환 도구(BigQuery에서 OKF를 자동 생성하는 enrichment 에이전트)다.
그래서 그림이 맞아떨어진다. 포맷은 공짜로 풀고, 해자는 한 칸 아래 데이터 중력에 둔다. OKF 자체는 누구나 생산·소비하라고 오픈했지만, 네 데이터가 이미 BigQuery에 쌓여 있다면 세상에서 가장 매끄러운 OKF 생산자는 구글이다. 포맷은 벤더 중립이어도, 그 포맷을 채우는 가장 쉬운 경로는 벤더 중립이 아니다. 이건 전에 「계약을 먼저 합의한다」에서 본 그림과 같다 — 포맷은 양쪽을 잇는 계약일 뿐이고, 값은 그 계약을 가장 잘 이행하는 쪽에 쌓인다. 그리고 그 값의 정체는 「AI를 위한 데이터」에서 다룬 데이터 그 자체다.
미래 — 군중이 가진 패턴을 벤더가 쥘 수 있을까
이 계보가 말해 주는 건 분명하다. 이 패턴은 바닥에서 이긴다. llms.txt도 AGENTS.md도 LLM Wiki도, 벤더가 위에서 내려준 게 아니라 사람들이 쓰면서 굳어졌다. OKF의 승패도 결국 두 가지에 달렸다 — 복리로 불어나는 루프까지 담아내느냐, 그리고 생태계를 한 곳으로 수렴시키느냐.
둘 다 못 하면 OKF는 구글의 데이터 카탈로그 export 포맷으로 남고, 진짜 중립의 자리는 AGENTS.md 계열이 가져간다. 군중이 수요를 증명해 구글의 손에 쥐여 줬는데, 정작 군중이 이미 소유한 패턴을 벤더가 앵커로 박은 포맷이 다시 쥘 수 있을지는 — 아직 모른다. 거의 아무것도 강제하지 않는 오픈 포맷은 채택은 쉽지만 파편화도 쉽다. 모두가 자기 식으로 쓰면 ‘표준’이라는 말이 무색해진다.
패턴은 분명하다
정리하면 OKF에서 봐야 할 건 포맷의 우아함이 아니다. 값은 벤더가 포맷을 발명해서 나온 게 아니라, 한 화면짜리 아이디어가 공개된 채로 복리로 불어나며 나왔다. 구글의 베팅은 그 흐름을 데이터가 쌓이는 곳에 묶인 무언가로 굳히는 것이다.
그래서 OKF의 승패는 ‘이 포맷이 좋냐’로 갈리지 않는다. 구글이 “조직의 지식이 에이전트에게 가닿는 기본 경로”가 되느냐로 갈린다. 그리고 그 경로의 출발점이 군중의 gist 하나였다는 게, 이 사례에서 진짜 기억할 대목이다. 수요는 늘 바닥에서 먼저 증명되고, 그 수요를 누가 가져가느냐의 승부는 데이터가 쌓이는 창고에서 난다.