구글 클라우드가 2026년 6월 공개한 OKF는 조직 곳곳에 흩어진 지식을, AI 에이전트가 별도 변환 없이 그대로 읽어 들이는 마크다운 묶음으로 표준화하려는 시도다. 무엇을, 왜, 어떻게 하려는지 차근히 들여다본다.
파운데이션 모델(foundation model, 방대한 데이터로 사전학습되어 다양한 작업에 두루 쓰이는 대형 인공지능 모델)은 해마다 똑똑해진다. 그러나 모델이 실제로 쓸모 있는 답을 내놓으려면 “그 조직만 아는 맥락”이 필요하다. 어떤 표(table)의 스키마가 무엇인지, 특정 지표가 사내에서 정확히 무엇을 뜻하는지, 장애가 났을 때 따라야 할 대응 절차는 무엇인지, 두 시스템의 데이터를 어떤 키로 잇는지 같은 것들이다. 이런 정보는 보통 메타데이터 카탈로그, 위키, 공유 드라이브, 코드 주석, 그리고 몇몇 선임 엔지니어의 머릿속에 제각기 흩어져 있다.
문제는 이 조각들이 서로 호환되지 않는다는 점이다. 에이전트가 “이벤트 스트림에서 주간 활성 사용자 수를 어떻게 계산하지?” 같은 질문에 답하려면, 흩어진 출처에서 단서를 매번 새로 그러모아야 한다. 카탈로그마다 자체 응용프로그래밍 인터페이스(API)가 있고, 벤더마다 자체 소프트웨어 개발 키트(SDK)와 지식 그래프 스키마가 있다. 그래서 새 에이전트를 만들 때마다 같은 “맥락 조립” 문제를 처음부터 다시 푼다. 지식 자체가 그것을 만든 도구 안에 갇혀 있기 때문이다.
실력 있는 요리사를 한 명 데려왔다고 하자. 그런데 레시피는 사무실 서랍에, 재료 목록은 옆 부서 엑셀 파일에, 단골손님의 알레르기 정보는 매니저의 머릿속에 있다. 주문이 들어올 때마다 요리사는 이 흩어진 정보를 다시 그러모아야 한다.
지금 AI 모델이 처한 상황이 정확히 이렇다. OKF는 요리사가 한 번에 펼쳐 볼 수 있도록 레시피·재료·주의사항을 “표준 형식의 노트 한 권”으로 묶어 두자는 제안이다.
Open Knowledge Format(OKF, 오픈 지식 포맷)은 구글 클라우드 데이터 부문의 샘 맥비티(Sam McVeety)와 아미르 호르마티(Amir Hormati)가 2026년 6월 공개한 개방형 명세(specification)다. 버전은 v0.1이며, 아파치 2.0 라이선스로 깃허브에 공개됐다. 명세 분량은 약 450줄에 불과해, “한 화면에 담기는 표준”을 표방한다.
구조의 핵심은 단순하다. OKF 묶음(bundle)은 YAML 프런트매터(frontmatter, 파일 맨 앞에 두는 구조화된 머리말)가 붙은 마크다운(Markdown) 파일들을 담은 디렉터리다. 그게 전부다. 새로운 압축 방식도, 별도 런타임도, 필수 SDK도 없다. 그래서 깃허브에서 그대로 렌더링되고, 압축 파일 하나로 배포되며, 어떤 파일 시스템에든 마운트된다. 옵시디언(Obsidian)이나 노션(Notion), 휴고(Hugo) 같은 도구를 써 본 사람에게는 익숙한 모양일 것이다. OKF는 이런 패턴들이 “서로 통하도록” 만드는 데 필요한 최소한의 약속만 표준화한다.
OKF 묶음은 “개념(concept)”을 담은 마크다운 파일들의 디렉터리다. 여기서 개념이란 표, 데이터셋, 지표, 실행 절차(playbook), 장애 대응 절차(runbook), API 등 포착하고 싶은 모든 대상을 말한다. 규칙은 간단하다. 개념 하나가 파일 하나이고, 파일의 경로가 곧 그 개념의 정체성이다.
각 개념 문서는 구조화된 필드를 담는 작은 YAML 머리말과, 나머지 전부를 담는 마크다운 본문으로 이뤄진다. 머리말에서 강제되는 필드는 단 하나, type(개념의 종류)뿐이다. title(제목), description(설명), resource(원본 링크), tags(태그), timestamp(시각)는 권장 필드일 뿐 의무가 아니다. 본문에는 스키마 표든 조인 경로든 자유롭게 적는다.
--- type: BigQuery Table title: Orders description: 완료된 고객 주문 한 건당 한 행. resource: https://console.cloud.google.com/.../orders tags: [sales, revenue] timestamp: 2026-05-28T14:30:00Z --- # Schema | 컬럼 | 타입 | 설명 | |--------------|--------|------------------------------| | order_id | STRING | 전역적으로 유일한 주문 식별자. | | customer_id | STRING | customers 로 향하는 외래 키. | # Joins customers 와 customer_id 로 조인한다.
개념들은 평범한 마크다운 링크로 서로를 가리킨다. 그러면 평면적인 디렉터리가 “관계의 그래프”로 변한다. 파일 시스템의 부모–자식 구조보다 훨씬 풍부한 연결망이다. 묶음에는 선택적으로 index.md(에이전트가 계층을 탐색하며 점진적으로 내용을 펼쳐 보도록 돕는 안내 파일)와 log.md(변경 이력을 시간순으로 적는 파일)를 둘 수 있다.
설계상 또 하나 중요한 약속은 관용성이다. 소비하는 쪽은 모르는 필드나 모르는 type 값을 만나도 문서를 거부해서는 안 된다. 덕분에 초기 단계의 불완전한 구현이나 부분 구현도 그대로 받아들여진다.
OKF는 세 가지 원칙 위에 서 있다. 첫째, 최소한의 규정이다. 모든 개념에 강제되는 것은 type 필드 하나뿐이다. 어떤 종류가 존재하는지, 어떤 필드를 더 넣을지, 본문을 어떤 절(section)로 구성할지는 전부 생산자에게 맡긴다. 명세는 내용 모델이 아니라 “상호운용의 접점”만 정의한다.
둘째, 생산자와 소비자의 분리다. 사람이 손으로 쓴 묶음을 AI 에이전트가 읽을 수 있고, 메타데이터 추출 파이프라인이 만든 묶음을 사람이 시각화 도구로 둘러볼 수 있다. 한 LLM이 합성한 묶음을 다른 LLM이 질의할 수도 있다. 포맷이 계약이고, 양쪽 끝의 도구는 각자 독립적으로 갈아 끼울 수 있다.
셋째, 플랫폼이 아니라 포맷이다. OKF는 특정 클라우드·데이터베이스·모델 제공자·에이전트 프레임워크에 묶이지 않는다. 읽고 쓰고 제공하는 데 독점 계정이나 SDK가 결코 필요하지 않다. 명세를 개방형 표준으로 내놓은 이유는, 지식 포맷의 가치가 “누가 소유하느냐”가 아니라 “몇 명이 그 언어를 말하느냐”에서 나오기 때문이다.
1950년대 이전 해운에서는 화물 규격이 제각각이었다. 배에서 트럭으로, 트럭에서 기차로 옮길 때마다 짐을 풀었다 다시 쌌다. 표준 컨테이너가 등장하자 같은 상자가 어느 운송 수단에서나 그대로 통했고, 물류 비용이 급감했다.
OKF가 노리는 것이 바로 이 “표준 컨테이너”다. 지식을 어느 에이전트·도구·조직에서나 통하는 표준 상자에 담아 두면, 옮길 때마다 다시 포장하는 비용이 사라진다.
OKF는 무에서 나온 것이 아니다. 2026년 4월, 오픈AI 창립 멤버이자 전 테슬라 AI 총괄인 안드레이 카르파시(Andrej Karpathy)가 “LLM 위키”라는 패턴을 공개했다. 관련 글은 트윗만 1,600만 회 넘게 조회됐고, 정리한 깃허브 지스트(gist)는 며칠 만에 별 5,000개를 넘겼다. 핵심은 LLM을 코드 생성기로만 쓰지 말고, “자기가 읽고 갱신하는 지식 베이스”를 짓고 유지하는 데 쓰자는 것이었다.
카르파시의 패턴은 세 계층으로 이뤄진다. 손대지 않는 원본 모음(raw/), LLM이 이를 정리해 써 내려가는 위키 페이지(wiki/), 그리고 위키를 어떻게 다룰지 규정한 스키마 파일(CLAUDE.md 또는 AGENTS.md)이다. 그는 이를 컴파일러에 빗댔다. 원본은 소스 코드, LLM은 컴파일러, 위키는 실행 파일에 해당한다는 것이다.
지식은 한 번 “컴파일”해 두고 계속 최신으로 유지한다. 질의할 때마다 매번 다시 만들어 내지 않는다.
이 발상의 뿌리는 더 멀리 닿는다. 카르파시 자신이 1945년 버니바 부시(Vannevar Bush)가 구상한 메멕스(Memex), 즉 문서 사이를 연관 링크로 잇는 개인 큐레이션 지식 저장소를 떠올렸다고 밝혔다. 사람들이 20년 넘게 개인 위키를 만들고 또 방치해 온 이유는 “교차 참조 갱신 같은 잡무”를 감당하기 어려웠기 때문인데, 바로 그 잡무가 LLM이 잘하는 일이라는 점이 새로웠다.
문제는, 이 패턴이 여러 이름으로 반복 등장했지만 서로 협력하도록 설계되지는 않았다는 점이다. 옵시디언 볼트, AGENTS.md·CLAUDE.md 같은 관습 파일, 에이전트가 작업 전에 참조하는 index.md·log.md 더미, 데이터 팀의 “코드로서의 메타데이터” 저장소가 모두 비슷하게 생겼다(마크다운, 프런트매터, 교차 링크). 그러나 어떤 필드를 모든 문서가 가져야 하는지, 어떤 파일명이 무엇을 뜻하는지에 대한 합의가 없었다. OKF의 기여는 바로 이 “상호운용에 필요한 최소한의 합의”를 표준으로 못 박은 데 있다.
개발자에게 가장 유용한 비교는 RAG와의 차이다. RAG(Retrieval-Augmented Generation, 검색 증강 생성)는 질문이 들어올 때마다 원본 조각을 다시 검색해 답을 재구성한다. 빠르고 강력하지만, 매번 지식을 처음부터 다시 발견한다는 한계가 있다. 누적이 없는 셈이다. 다섯 문서를 종합해야 풀리는 미묘한 질문이라면, LLM은 그때마다 관련 조각을 다시 찾아 짜맞춰야 한다.
OKF는 반대 방향이다. 큐레이션되고 서로 연결된 개념을 저장해 두고, 에이전트가 그것을 읽고 직접 갱신한다. 정리해 둔 노력이 다음 질문에도 그대로 쌓인다.
질문마다 원본 청크를 다시 검색·요약. 누적이 없고, 같은 사실을 매번 다시 발견한다. 대규모 비정형 문서에 강하다.
정리된 개념을 저장해 읽고 갱신. 지식이 누적되고 버전 관리된다. 정제된 도메인 지식에 강하다.
다만 OKF가 RAG를 완전히 대체한다고 보기는 어렵다. 단일 컨텍스트로 다루는 위키는 대략 5만~10만 토큰(token, 모델이 한 번에 처리하는 텍스트 단위)이 실용적 상한으로 알려져 있다. 그 이상으로 커지면 필요한 페이지만 선택적으로 불러오거나, 별도의 검색 계층을 덧붙여야 한다. 즉 둘은 경쟁한다기보다 규모와 성격에 따라 역할을 나눠 갖는다.
RAG는 질문을 받을 때마다 도서관 서가로 달려가 관련 책을 찾고, 필요한 부분을 발췌해 그 자리에서 요약하는 사서다. 빠르지만 매번 처음부터 한다.
OKF는 그 사서가 미리 정리해 둔 “주제별 위키 페이지”를 펼치는 것에 가깝다. 한 번 정리해 둔 수고가 사라지지 않고 다음 질문에도 그대로 쌓인다.
OKF를 둘러싼 흔한 오해는 “또 하나의 프로토콜이냐”는 것이다. 그렇지 않다. OKF는 기존 에이전트 프로토콜과 경쟁하지 않고 보완한다. 좌표를 잡아 보면 이렇다.
MCP(Model Context Protocol, 모델 컨텍스트 프로토콜)는 에이전트가 도구와 실시간 데이터에 “어떻게 접속하는가”를 다루는 런타임 규약이다. 일종의 소켓이다. 반면 OKF는 그 소켓을 타고 흐르는 “지식 콘텐츠” 자체다. 실제로 MCP 서버가 OKF 묶음을 하나의 지식 소스로 노출할 수 있다. A2A(Agent-to-Agent, 에이전트 간 통신)가 “에이전트끼리 어떻게 대화하는가”를 다룬다면, OKF는 “에이전트가 무엇을 알고 있으며, 그 지식이 어떤 형식으로 사는가”라는 세 번째 질문에 답한다.
도메인 스키마와의 관계도 분명하다. OKF는 Avro·Protobuf·OpenAPI 같은 기존 스키마를 대체하지 않고 “참조”한다. 더 표현력이 풍부한 시맨틱 웹 표준인 OWL·RDF와 비교하면 의도적으로 단순하다. OWL·RDF는 타입 관계와 형식 논리, 자동 추론까지 지원하지만, 스키마 레지스트리와 전문 인력을 요구해 실제 기업 도입이 제한적이었다. OKF는 정반대로 베팅한다. 텍스트 에디터와 git 저장소만 있으면 누구나 구현할 수 있을 만큼 단순하게.
MCP는 벽의 콘센트와 배선이다. 전기가 “어떤 통로로” 흐르는지를 정한다. OKF는 그 선을 타고 흐르는 콘텐츠, 즉 “무엇을” 전달하는가다.
콘센트만 있고 보낼 게 없으면 의미가 없고, 잘 정리된 지식이 있어도 통로 규격이 안 맞으면 보낼 수 없다. 둘은 서로 다른 층의 문제를 풀기에, 한쪽이 다른 쪽을 대체하지 않는다.
포맷을 구체적으로 보여 주기 위해, 구글은 생산자와 소비자 양쪽 끝의 참고 구현(reference implementation)을 함께 공개했다. 생산 쪽에는 “보강 에이전트(enrichment agent)”가 있다. 이 에이전트는 빅쿼리(BigQuery) 데이터셋을 훑으며 표와 뷰마다 OKF 개념 문서 초안을 작성한 뒤, 두 번째 LLM 패스로 공식 문서를 크롤링해 인용·스키마·조인 경로를 채워 넣는다.
소비 쪽에는 정적 HTML 시각화 도구가 있다. 어떤 OKF 묶음이든 단일 self-contained HTML 파일 하나로 상호작용형 그래프 뷰로 바꿔 준다. 백엔드도, 보는 쪽의 설치도 필요 없으며, 데이터가 페이지를 벗어나지 않는다. 여기에 곧바로 둘러볼 수 있는 샘플 묶음 세 개(GA4 이커머스, 스택 오버플로, 비트코인 공개 데이터셋)를 저장소에 살아 있는 예시로 함께 올렸다. 구글 클라우드의 Knowledge Catalog도 OKF를 네이티브로 수집해 자사 에이전트에 제공하도록 업데이트됐다.
다만 구글은 이것들이 어디까지나 “증명용 구현”임을 분명히 한다. 보강 에이전트는 OKF를 만드는 한 가지 방법일 뿐 특정 프레임워크나 LLM을 요구하지 않으며, 시각화 도구 역시 소비의 한 방법일 뿐 HTML이나 그래프 뷰를 강제하지 않는다. 포맷 자체가 기여이고, 도구는 그것을 “실재하게” 만들기 위한 보조라는 입장이다.
OKF의 핵심 베팅은 명확하다. 풍부하지만 도입 장벽이 높은 포맷보다, 단순해서 누구나 텍스트 에디터와 git만으로 구현할 수 있는 포맷이 조직에 더 많은 가치를 만든다는 것이다. 표준의 힘은 정교함이 아니라 채택의 폭에서 나온다는 판단이다. 실제로 깃허브에서 그대로 읽히고, 사람도 cat 한 번으로 열어 보며, LLM은 변환 계층 없이 그대로 읽는다는 점은 강력한 진입 유인이다.
그러나 v0.1이라는 버전 번호가 말해 주듯, 이것은 완성품이 아니라 시작점이다. 몇 가지 의문이 남는다.
강제 필드가 type 하나뿐이라는 단순함은 양날의 검이다. 소비자가 모르는 type을 허용해야 하므로 도입은 쉽지만, 실질적 상호운용은 결국 “어떤 type 어휘를 누가 합의하느냐”로 이동한다. 생산자마다 type을 제각기 쓰면, 형식은 같아도 의미는 다시 파편화될 수 있다. 명세가 비워 둔 “내용 모델”이 현실에서 어떻게 수렴할지가 관건이다.
큰 조직의 지식은 단일 컨텍스트로 다루기에는 너무 크다. 결국 선택적 로딩이나 검색 계층이 필요하며, 그 지점에서 OKF는 RAG·인덱싱 같은 기존 기법과 다시 손을 잡아야 한다. 포맷만으로 맥락 조립 문제 전체가 풀리지는 않는다.
누가 무엇을 쓸 수 있는지, 민감한 지식의 접근을 어떻게 통제할지는 포맷 바깥의 문제로 남는다. “그냥 파일”이라는 단순함은 보안·권한 관리를 도구와 운영의 몫으로 미룬다.
OKF는 구글이 주도하면서도 “벤더 중립”을 표방한다. 아파치 2.0 라이선스와 공개 저장소는 그 약속을 뒷받침하지만, 진짜 시험은 구글 생태계 밖에서 얼마나 많은 생산자와 소비자가 이 포맷을 “말하기” 시작하느냐다. 표준은 쓰는 사람이 많아질 때 비로소 표준이 된다.
정리하면, OKF는 새로운 서비스가 아니라 “합의된 모양”이다. 위키와 옵시디언, CLAUDE.md로 각자 굴리던 지식 관리 패턴을 서로 읽을 수 있게 만드는 최소한의 규약이다. 야심은 크지 않다. 바로 그 절제가 도입 장벽을 낮추고, 도입 장벽이 낮다는 점이 이 포맷의 가장 큰 무기다. 성패는 명세의 정교함이 아니라, 얼마나 많은 도구와 조직이 이 언어를 공통어로 받아들이느냐에 달려 있다.