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

> Clean Markdown view of GeekNews topic #30622. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=30622](https://news.hada.io/topic?id=30622)
- GeekNews Markdown: [https://news.hada.io/topic/30622.md](https://news.hada.io/topic/30622.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-06-19T09:28:01+09:00
- Updated: 2026-06-19T09:28:01+09:00
- Original source: [cloud.google.com](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing)
- Points: 5
- Comments: 2

## Topic Body

- 서로 다른 생산자가 작성한 위키를 번역 없이 여러 에이전트가 소비할 수 있게 하는 **벤더 중립적 개방형 사양**으로, **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)** 로 설계됨

## Comments



### Comment 59926

- Author: leothelion
- Created: 2026-06-19T12:01:04+09:00
- Points: 1

.claude와 .agent를 먹지못한 자의 최선이랄까

### Comment 59910

- Author: neo
- Created: 2026-06-19T09:29:01+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48517735)   
- 이 **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/](<https://equalexperts.github.io/satsuma-lang/>)임. 자연어를 허용하는 간결한 구조적 텍스트 표현이면서, 좋은 시각화와 LSP/문법 도구도 제공해 에이전트가 계보나 완전성, 정의되지 않은 소스 같은 것을 추론하려고 큰 문서를 토큰 비효율적으로 잘라보지 않아도 되게 함  
  - OKF는 괜찮아 보이지만 Markdown에 묶여 있음  
    Markdown 문서는 앞부분 YAML에 `type`을 추가하면 OKF 문서가 될 수 있음  
    Markdown 산문이나 Markdown 코드 블록 안에서도 쓸 수 있고, 텍스트 필드가 있는 어디서나 쓸 수 있는 **지식 그래프 언어**는 어떨까 싶음  
    미니멀한 언어 [https://ddot.it](<https://ddot.it>)에서는 Markdown 세계 바깥의 파일, URL, 단순 라벨까지 연결할 수 있음. OKF처럼 그냥 하나의 형식임  
    고지하자면, 그 짧은 명세는 내가 작성했음  
  - 엔터티 사이의 **라벨 붙은 관계**를 보여주는 그래프 형식 없이는 지식을 잘 표현할 수 없음  
  - Markdown은 LLM과 사람이 상호운용하는 **사실상의 형식**임  
    모든 것을 잘 표현할 수 없다는 데는 동의하지만, 그건 핵심을 빗나간 얘기임. Markdown은 사람과 AI 모델 모두에게 최저공통분모라서 이기는 것으로 보임  
  
- 10년마다 RDF/OWL **시맨틱 웹 형식**을 다시 들여다보는 게 즐거움  
  언젠가는 그중 한 해가 진짜 해가 될 것임  
  [https://en.wikipedia.org/wiki/Semantic_Web](<https://en.wikipedia.org/wiki/Semantic_Web>)  
  
- 원문에 깨진 링크가 여럿 있어서 저장소를 남김  
  [https://github.com/GoogleCloudPlatform/knowledge-catalog](<https://github.com/GoogleCloudPlatform/knowledge-catalog>)  
  명세: [https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...](<https://github.com/GoogleCloudPlatform/knowledge-catalog/blob/main/okf/SPEC.md>)  
  
- 내가 이해한 바로는, 우리는 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](<https://news.ycombinator.com/item?id=48407998>)  
  
- barrasindustries.com/okfind/ 를 확인해보면 좋음  
  OKF 번들 레지스트리에 대한 아이디어임