구글 Open Knowledge Format 공개 - AI에이전트를 위한 지식 공유 표준

• 서로 다른 생산자가 작성한 위키를 번역 없이 여러 에이전트가 소비할 수 있게 하는 벤더 중립적 개방형 사양으로, LLM-wiki 패턴을 이식 가능하고 상호운용 가능한 형식으로 정형화
• OKF v0.1은 지식을 YAML frontmatter가 포함된 markdown 파일 디렉터리로 표현하며, 복잡한 압축 방식·새 런타임·필수 SDK 없이 동작
• 조직 내부 지식이 메타데이터 카탈로그, 위키, 코드 주석, 일부 시니어 엔지니어의 머릿속 등 파편화된 시스템에 흩어져 있어 에이전트가 매번 동일한 컨텍스트 조립 문제를 처음부터 해결
• 새로운 지식 서비스가 아니라 포맷 자체가 해답으로, 누구나 SDK 없이 생산하고 통합 없이 소비하며 버전 관리에서 코드와 함께 관리 가능
• 개방형 표준으로 공개되어 생산자·소비자 생태계의 확장을 통해 가치가 결정되는 구조

배경: 파편화된 컨텍스트 환경

• 파운데이션 모델은 발전하더라도 관련 컨텍스트 부족으로 인해 특히 에이전트 시스템 구축 시 성능이 제한됨
  • 코드 작성, 문서 요약, 데이터셋 분석은 가능하나 정확하고 실행 가능한 결과를 내려면 올바른 정보가 필요
• 조직에서 모델이 사용하는 정보는 대부분 내부 지식이며, 테이블 스키마, 비즈니스상 지표의 의미, 인시던트 런북, 두 시스템 간 조인 경로, 구 API의 폐기 공지 등이 해당
• 이러한 지식 단위가 흩어져 있는 시스템 예시
  • 자체 API를 가진 메타데이터 카탈로그
  • 위키, 서드파티 시스템, 공유 드라이브
  • 코드 주석, docstring, 노트북 셀
  • 일부 시니어 엔지니어의 머릿속
• "이벤트 스트림에서 주간 활성 사용자(WAU)를 어떻게 계산하는가"라는 질문에 답하려면 에이전트가 상호 호환되지 않는 표면들에서 답을 조립해야 함
  • 모든 벤더가 자체 카탈로그, 자체 SDK, 자체 지식 그래프 스키마를 제공하며 지식이 제품·조직 간 이식되지 않음
• 결과적으로 모든 에이전트 빌더가 동일한 컨텍스트 조립 문제를 반복하고, 카탈로그 벤더는 동일한 데이터 모델을 재발명하며, 지식은 생성한 표면에 갇힘

살아있는 위키로서의 지식

• 개발 팀은 동일한 문서에서 동일한 사실을 반복 검색하는 대신, 시간이 지날수록 유용해지는 공유 markdown 라이브러리를 에이전트에 제공하는 방식으로 전환
  • 에이전트가 자체 파일을 읽고 갱신하는 잡무를 맡고, 팀은 콘텐츠를 큐레이션하며 코드처럼 관리
• Andrej Karpathy가 LLM Wiki gist에서 이 아이디어를 제시
  • "LLM은 지루해하지 않고, 상호 참조 갱신을 잊지 않으며, 한 번에 15개 파일을 다룰 수 있다"고 기술
  • 사람이 개인 위키를 포기하게 만드는 부기(bookkeeping) 작업이 바로 LLM이 잘하는 일
• 동일한 지식-위키 패턴이 여러 이름으로 반복 등장
  • 코딩 에이전트와 연결된 Obsidian vault
  • AGENTS.md / CLAUDE.md 계열의 컨벤션 파일
  • 에이전트가 작업 전 참조하는 index.md, log.md 아티팩트 저장소
  • 데이터 팀 내부의 "metadata as code" 저장소
• 패턴은 강력하나 각 사례가 개별 맞춤형(bespoke) 이라는 한계
  • markdown, frontmatter, 상호 링크 등 형태는 유사하나 협업하도록 설계되지 않음
  • 모든 문서가 가져야 할 필드나 파일명의 의미에 대한 합의가 없어 지식이 원래 팀 내부에 사일로화되고, 새 에이전트 구축 시 중복 작업 발생

필요한 것은 서비스가 아닌 포맷

• 해답은 또 다른 지식 서비스가 아니라 지식을 표현하는 포맷이며, 다음 요건을 충족해야 함
  • 누구나 SDK 없이 생산 가능
  • 누구나 통합 없이 소비 가능
  • 시스템·조직·도구 간 이동에도 보존
  • 설명 대상 코드와 함께 버전 관리에 존재
  • 사람이 읽고 에이전트가 파싱 가능, 번역 계층 없이 동일 파일 사용
• OKF는 설계상 이 요건을 충족하는 포맷

OKF 동작 방식: 한 화면에 담긴 설계

• OKF 번들(bundle) 은 개념(concept) 을 표현하는 markdown 파일 디렉터리로, 테이블·데이터셋·지표·플레이북·런북·API 등 포착하려는 모든 대상을 포함
  • 각 개념은 하나의 파일이며, 파일 경로가 개념의 정체성
  • 디렉터리 구조 예시: sales 하위에 datasets, tables, metrics 폴더와 orders.md, customers.md, weekly_active_users.md 등 배치
• 각 개념 문서는 구조화 필드를 위한 YAML front matter 블록과 나머지를 담는 markdown 본문으로 구성
  • front matter 필드 예: type(BigQuery Table), title(Orders), description, resource(콘솔 URL), tags([sales, revenue]), timestamp(2026-05-28T14:30:00Z)
  • 본문에는 Schema(order_id, customer_id 컬럼과 타입·설명), Joins(customer_id 기준 customers 조인) 등 포함
• 개념은 일반 markdown 링크로 서로 연결되어 디렉터리를 파일 시스템의 부모/자식 관계보다 풍부한 그래프로 전환
  • 번들은 선택적으로 index.md(에이전트 탐색 시 점진적 공개)와 log.md(변경 이력) 파일 포함 가능
• v0.1 전체 사양은 적합성 기준, 상호 링크 규칙, 소수의 예약 파일명을 포함해 한 페이지에 수록

설계의 세 가지 원칙

• 최소한의 규정(Minimally opinionated)

  • OKF가 모든 개념에 요구하는 것은 단 하나, type 필드
  • 어떤 type이 존재하는지, 어떤 필드를 추가할지, 본문에 어떤 섹션을 둘지는 생산자에게 위임
  • 사양은 상호운용 표면을 정의할 뿐, 콘텐츠 모델은 규정하지 않음

• 생산자/소비자 독립성(Producer/consumer independence)

  • 지식을 작성하는 주체와 소비하는 주체를 깔끔하게 분리
  • 사람이 손으로 작성한 번들을 AI 에이전트가 소비, 메타데이터 내보내기 파이프라인이 생성한 번들을 비주얼라이저에서 탐색, 한 LLM이 합성한 번들을 다른 LLM이 질의 가능
  • 포맷이 계약이며, 양 끝단의 도구는 독립적으로 교체 가능

• 플랫폼이 아닌 포맷(Format, not platform)

  • 특정 클라우드·데이터베이스·모델 제공자·에이전트 프레임워크에 종속되지 않음
  • 읽기·쓰기·서빙에 독점 계정이나 SDK를 요구하지 않음
  • 지식 포맷의 가치는 소유자가 아니라 얼마나 많은 주체가 그 포맷을 사용하는가에서 나오므로 개방형 표준으로 공개

사양과 함께 제공되는 것

• 포맷을 구체화하기 위해 생산자·소비자 양단의 레퍼런스 구현을 공개
• Enrichment agent: BigQuery 데이터셋을 순회하며 모든 테이블·뷰에 대한 OKF 개념 문서를 초안 작성한 뒤, 2차 LLM 패스로 공식 문서를 크롤링해 인용·스키마·조인 경로로 각 개념을 보강
• 정적 HTML 비주얼라이저: 임의의 OKF 번들을 자체 포함 단일 파일의 인터랙티브 그래프 뷰로 전환하며, 백엔드 불필요·뷰어 측 설치 불필요·데이터가 페이지를 벗어나지 않음
• 즉시 탐색 가능한 샘플 번들 3종: GA4 e-commerce, Stack Overflow, Bitcoin 공개 데이터셋으로, 레퍼런스 에이전트가 생성해 적합한 OKF의 살아있는 예시로 저장소에 커밋
• 이들은 의도적으로 개념 증명(proof of concept)
  • 에이전트는 OKF 생산의 한 방식을 보여줄 뿐 특정 프레임워크나 LLM을 요구하지 않음
  • 비주얼라이저는 소비의 한 방식을 보여줄 뿐 HTML이나 그래프 뷰를 요구하지 않음
  • 생산자·소비자 생태계가 제공된 범위를 훨씬 넘어 성장하기를 기대

향후 방향

• OKF v0.1은 완성된 표준이 아니라 출발점이며, 더 많은 생산자·소비자가 등장하고 에이전트가 실제로 필요로 하는 지식 표현을 학습하면서 진화
• 지식 카탈로그, 보강 파이프라인, AI 에이전트용 위키 등 무엇을 만들든 첫날부터 개방형으로 공개해야 포맷이 제 이름값을 함
• 권장 행동
  • 사양 읽기 (짧음)
  • 소스 시스템·데이터베이스·문서 사이트용 생산자(producer) 작성
  • 뷰어, 검색 인덱스, 번들 위에서 추론하는 에이전트 등 소비자(consumer) 작성
  • 자체 데이터에 레퍼런스 구현 적용
  • 이슈 제기, PR 전송, 확장 제안 (사양은 버전 관리되며 하위 호환 성장을 위해 설계됨)
• 저장소·사양·샘플 번들은 GitHub에 공개되어 있으며, Google Cloud의 Knowledge Catalog가 OKF를 수집해 에이전트에 서빙하도록 업데이트됨
• 기여 자체는 포맷이며, 제공 도구는 포맷을 현실화하고 시도 비용을 낮추기 위한 것으로, OKF는 향후 지식 교환의 공용어(lingua franca) 로 설계됨