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

 (cloud.google.com)
3P by GN⁺ | ★ favorite | 댓글 1개
  • 서로 다른 생산자가 작성한 위키를 번역 없이 여러 에이전트가 소비할 수 있게 하는 벤더 중립적 개방형 사양으로, 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) 로 설계됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이 OKF 명세의 단순함은 좋지만, 모든 것을 “그냥 Markdown”으로 잘 표현할 수 있을지는 확신이 안 듦
    최근에는 AI가 효과적이고 토큰 효율적으로 공동 기여할 수 있게 개념을 표현하는 방식에 관심이 생겼고, 보통은 무언가를 반구조적 순차 텍스트로 잘 표현하는 방법을 찾는 쪽임. 하지만 그 과정에서 사람이 보는 지식 표현 경험을 희생하면 안 됨
    특히 전통적으로 개발자가 아닌 역할까지 기여해야 한다면, “이상한 텍스트 형식 + git”은 현재 쓰는 저작·시각화 도구보다 훨씬 나쁘게 느껴질 가능성이 큼
    앞으로 몇 년 동안 여러 종류의 지식을 의미적으로 표현하는 표준이 어떻게 등장할지 기대됨
    참고할 만한 성공 사례로는 스키마/E-R용 DBML, 아키텍처용 LikeC4, Mermaid 같은 다이어그램-as-code 방식이 있음. LLM도 이런 형식을 잘 이해하는 편이고, 짧은 EBNF 프롬프트로 알려줄 수도 있음. 중요한 건 이들도 사람이 보기 좋은 시각화 형태가 있고, Markdown 안에 code block으로 자연어 옆에 바로 넣을 수 있으며, LLM이 문법 작성도 도와줄 수 있다는 점임
    더 어려운 건 복잡한 스프레드시트나 Miro처럼 공간 배치와 색상에 암묵적 의미가 있는 것들임. 아직 좋은 대안을 못 찾았음
    데이터 엔지니어링 영역에서 직접 시도한 것은 AI와 사람이 함께 소스-타깃 매핑과 변환을 다루기 위한 https://equalexperts.github.io/satsuma-lang/임. 자연어를 허용하는 간결한 구조적 텍스트 표현이면서, 좋은 시각화와 LSP/문법 도구도 제공해 에이전트가 계보나 완전성, 정의되지 않은 소스 같은 것을 추론하려고 큰 문서를 토큰 비효율적으로 잘라보지 않아도 되게 함

    • OKF는 괜찮아 보이지만 Markdown에 묶여 있음
      Markdown 문서는 앞부분 YAML에 type을 추가하면 OKF 문서가 될 수 있음
      Markdown 산문이나 Markdown 코드 블록 안에서도 쓸 수 있고, 텍스트 필드가 있는 어디서나 쓸 수 있는 지식 그래프 언어는 어떨까 싶음
      미니멀한 언어 https://ddot.it에서는 Markdown 세계 바깥의 파일, URL, 단순 라벨까지 연결할 수 있음. OKF처럼 그냥 하나의 형식임
      고지하자면, 그 짧은 명세는 내가 작성했음
    • 엔터티 사이의 라벨 붙은 관계를 보여주는 그래프 형식 없이는 지식을 잘 표현할 수 없음
    • Markdown은 LLM과 사람이 상호운용하는 사실상의 형식임
      모든 것을 잘 표현할 수 없다는 데는 동의하지만, 그건 핵심을 빗나간 얘기임. Markdown은 사람과 AI 모델 모두에게 최저공통분모라서 이기는 것으로 보임

  • 10년마다 RDF/OWL 시맨틱 웹 형식을 다시 들여다보는 게 즐거움
    언젠가는 그중 한 해가 진짜 해가 될 것임
    https://en.wikipedia.org/wiki/Semantic_Web

  • 원문에 깨진 링크가 여럿 있어서 저장소를 남김
    https://github.com/GoogleCloudPlatform/knowledge-catalog
    명세: https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...

  • 내가 이해한 바로는, 우리는 3차원 너머를 볼 수 없으니 이것은 본질적으로 사람을 위한 발판에 가까움
    우리가 적당히 잘 정리해두면 에이전트가 Markdown을 받아 메모리에 그래프 인프라를 만들거나 Neo4j에 저장할 수 있기를 기대함

  • Markdown의 변형, 예를 들어 CommonMark 같은 것이 지정돼 있나?
    앞 몇 페이지만 훑어봤을 때는 관련 내용을 못 봤는데, 명세라면 꽤 중요한 부분으로 느껴짐

  • Google이 발표한 건 결국 YAML 프런트매터가 붙은 Markdown임. 여러분 박수 부탁드림. 이걸 위해 15KB짜리 명세라니
    모두가 “앗, 들여쓰기 하나 놓쳤네” 식의 YAML 사용을 멈출 수 있다면 덜 비꼬았을 것임

  • Markdown으로 “번역”해야 했던 PDF를 많이 봐온 입장에서는 이상한 선택처럼 느껴짐
    AI가 쉽게 접근하게 하려는 목적이 크다는 건 알지만, 어차피 모델을 학습시킬 거라면 왜 더 나은 형식으로 학습시키지 않는지 의문임
    Markdown은 꽤 제한적이고, 예를 들어 중첩 테이블 같은 것도 렌더링할 수 없음. “열린 지식”의 목적이 AI라면, 사람이 실제로 읽지 않을 형식을 굳이 써야 하는지도 모르겠음

  • 접근 방식이 마음에 듦. 계층적 지식 조직화를 매우 좋아함
    현재 Claude의 지식 관리 추상화는 거의 다 망가져 있다고 봄. 여러 코더를 동시에 돌리거나 1,000개 이상의 스킬을 만들어야 할 때 그게 드러남. 예: https://news.ycombinator.com/item?id=48407998

  • barrasindustries.com/okfind/ 를 확인해보면 좋음
    OKF 번들 레지스트리에 대한 아이디어임

답변달기