서론

지난번, AI에게 GitHub 리포지토리를 인식시킨다면 「계층 구조 + index.md」와 「Obsidian 형식」 중 어느 쪽이 더 빠르고 저렴하며 정확한가 라는 기사를 썼습니다. 결론은 심플했습니다. **「구조는 디렉토리, 의미는 태그, 두 마리 토끼를 모두 잡는 것이 최강」**이었습니다.

이 기사는 그 후속편입니다. 「하나의 리포지토리를 AI에게 읽히는」 이야기를, 「회사 전체의 지식을 AI에게 배포 가능한 형태로 만드는」 스케일로 끌어올립니다. 키워드는 세 가지입니다.

OKF (Open Knowledge Format) — 2026년 6월에 Google Cloud가 발표한, 조직 지식을 「AI가 읽을 수 있는 파일」로 패키징하는 오픈 사양 (Open Specification) -
RAG — 그 지식을 「검색하여 가져오는」 파이프라인 -
Corporate OS (회사의 OS) — 두 가지를 토대로, 사내의 모든 AI 에이전트가 동일한 지식을 참조할 수 있는 상태

결론부터 말씀드리겠습니다.

OKF는 「지식을 어떤 형태로 파일에 저장할 것인가」를 결정합니다. RAG는 「그 지식을 어떻게 추출하여 LLM에 전달할 것인가」를 결정합니다. 두 가지는 경쟁 관계가 아니라 상하 레이어(Layer) 관계이며, 이를 겹치면 「회사의 OS」가 됩니다.

지난번의 「index.md + 태그」 설계 사상은 사실 그대로 OKF의 사상과 맞닿아 있습니다. 차례대로 살펴보겠습니다.

OKF (Open Knowledge Format)란 무엇인가

OKF = Open Knowledge Format. 2026년 6월 12일에 Google Cloud가 발표한, 벤더 중립적인 오픈 사양입니다. 한마디로 말하자면——

조직의 지식 (데이터의 정의, 지표의 계산 방법, API 사양, 업무 프로세스, Runbook 등)을 YAML frontmatter가 포함된 Markdown 파일군으로 패키징하여, AI 에이전트가 읽고·추론하고·행동할 수 있도록 하는 형식

입니다. 사양의 슬로건이 매우 뛰어난데, 다음과 같이 표현되어 있습니다.

cat

할 수 있다면 OKF는 읽을 수 있다. git clone

할 수 있다면 OKF는 배포할 수 있다.

즉, 특별한 SDK도 스키마 레지스트리 (Schema Registry)도 중앙 집권적인 관리 서버도 필요 없습니다. Markdown과 git만 있으면 성립합니다. 지난 기사에서 「AI에게 친화적인 리포지토리는 신입 엔지니어에게 친화적인 리포지토리와 같다」고 썼는데, OKF는 그것을 조직 스케일로 표준화한 것이라고 생각하면 이해가 빠를 것입니다.

왜 지금 이것이 필요한가

기업들이 AI 에이전트를 차례로 도입하는 과정에서, 어떤 「구멍」이 드러났습니다.

「이 지표 (예: MRR)는 어떻게 계산되는가?」 「이 업무 용어는 어떤 테이블에 대응하는가?」 ——

그 지식을 에이전트가 참조할 수 있는 통일된 포맷이 존재하지 않습니다.

이러한 지식은 데이터 카탈로그, 사내 Wiki, GitHub 리포지토리, 공유 드라이브, Slack의 과거 로그 등에 흩어져 있습니다. 인간조차 찾기 힘든 것을 에이전트가 읽을 수 있을 리 없습니다. OKF는 이렇게 흩어진 지식을 **「이동 가능한 공통 지식 레이어」**로 집약하기 위한 그릇입니다.

OKF의 구성 요소 (지난 설계와 맞닿아 있는 부분)

OKF의 내용은 놀라울 정도로 지난번의 「두 마리 토끼 레시피」와 닮아 있습니다.

Knowledge Bundle (번들)

자기 완결적인 계층적 Markdown 디렉토리. 이것이 배포의 단위입니다. git clone으로 통째로 배포할 수 있다는 발상이 바로 이것입니다.

Concept (개념) — 1파일 1개념

하나의 Markdown 파일이 하나의 개념 (테이블, API, 지표, 업무 프로세스 등)을 나타냅니다. 지난 기사에서 「Zettelkasten 방식으로 1토픽 1파일로 구성하면 청크 (Chunk) 분할이 깔끔하여 임베딩 (Embedding) 정밀도가 높아진다」고 썼던 그 원칙 그대로입니다.

Frontmatter (최소한의 메타데이터)

합의된 작은 필드 세트만을 사용합니다.

---
type: metric # 유일한 필수 필드
title: "월간 반복 매출 (MRR)"
...

필수 사항은 type뿐입니다. 나머지는 title / description / resource / tags / timestamp 등을 임의로 추가합니다. 지난번에 「frontmatter로 메타데이터를 갖게 하라」고 말했던 태그 전략이 그대로 사양으로 구현되어 있습니다.

크로스링크로 지식 그래프가 됨

파일 간의 링크가 지식 그래프를 형성합니다. 지난번에 "Wikilink보다 상대 경로의 표준 링크가 AI에 친화적이다"라고 썼던 포인트는 OKF에서도 중요합니다. 에이전트가 링크를 따라가며 문맥을 보강할 수 있는 형태로 만들어 두는 것입니다.

index.md

과 log.md

: 디렉터리의 목차. index.md는 Progressive Disclosure (단계적 개시) —— 우선 지도 한 장을 읽게 한 뒤, 필요한 개념만 깊이 파고들게 합니다. 지난번에 "최상단에 AI용 지도를 한 장 두라"고 역설했던 그 index.md가 사양으로 격상되었습니다.

: 업데이트 이력을 시계열로 남기는 옵션 파일. log.md

지난 기사를 읽어주신 분이라면 "어라, 이거 전부 저번에 했던 이야기잖아"라고 깨달으실 겁니다. OKF는 개별 리포지토리에서 배양된 AI 친화적 설계를 조직 간에 교환 가능한 표준으로 끌어올린 것입니다.

OKF와 RAG의 관계 —— 「저장의 형태」와 「불러오기」

이 부분이 가장 중요한 포인트입니다. OKF와 RAG는 자주 혼동되지만, 담당하는 레이어가 다릅니다.

구분	OKF	RAG
무엇을 결정하는가	지식을 어떤 형태로 파일에 저장할 것인가	지식을 어떻게 검색하여 LLM에 전달할 것인가
레이어	파이프라인의 상류 (지식의 형태)	파이프라인의 하류 (취득과 생성)
구체물	Markdown + frontmatter의 번들	Embedding · Vector 검색 · Rerank · 프롬프트 구축
비유	식재료의 밑준비 · 포장 작업	주문에 따라 식재료를 꺼내 조리함

즉, 다음과 같은 흐름이 됩니다.

【상류: OKF】
조직 지식을 1개념 1파일의 Markdown 번들로 정형화
↓
...

지난 기사에서 언급한 **하이브리드 검색 (Hybrid Search, 벡터 + 메타데이터 필터)**이 여기서 빛을 발합니다. OKF의 tags나 type은 그대로 RAG의 필터 조건이 됩니다. "type: metric 이면서 tags: [finance]인 개념만 검색"과 같은 필터링을 자연스럽게 할 수 있습니다. OKF로 깔끔하게 포장해 둘수록 RAG의 정확도와 비용 효율이 올라가는 것입니다.

RAG의 내용(HyDE나 Multi-Query, pgvector를 이용한 Embedding 등)에 대해서는 아래 기사도 참고해 주세요.

Corporate OS (회사의 OS)라는 발상

OKF와 RAG를 조직 전체에서 운용하면 무엇이 탄생할까요? 그것이 바로 **Corporate OS (회사의 OS)**입니다.

OS란 본래 앱이 하드웨어의 차이를 의러내지 않고 동작하기 위한 공통 기반입니다. 회사의 관점으로 바꾸면 ——

어떤 AI 에이전트(고객 지원 Bot · 사내 검색 · 분석 에이전트 · 코딩 에이전트)라도, 벤더에 상관없이 동일한 "조직 지식의 공통 기반"을 참조하여 동작할 수 있는 상태.

이것이 Corporate OS입니다. OKF가 그 **파일 시스템 (File System)**에 해당하며, RAG가 **그 위에서 실행되는 검색·추론 런타임 (Runtime)**에 해당합니다.

구체적인 아키텍처상

┌─────────────────────────────────────────────┐
│ AI 에이전트 층 (벤더 혼재 OK) │
│ 서포트 Bot / 사내 검색 / BI 분석 / Claude Code │
...

포인트는 벤더 락인 (Vendor Lock-in)으로부터의 해방입니다. OKF는 오픈 사양이기 때문에 "지식"을 특정 SaaS 안에 가두지 않아도 됩니다. Google Cloud의 Knowledge Catalog는 발표 시점에 OKF의 수입 및 배포를 지원하고 있지만, 사양 자체는 중립적이므로 내일 다른 도구로 갈아타더라도 지식 번들은 그대로 사용할 수 있습니다. git clone으로 배포할 수 있는 지식, 이라는 강점이 여기에 있습니다.

「회사의 OS」를 키우는 현실적인 단계

작게, 1개 번들부터 시작하기: 우선 finance/나 product/ 등 문의가 많은 한 영역만 OKF화 합니다. 지난번의 "1개념 1파일 + index.md"를 그대로 적용합니다.

frontmatter의 태그 규약 정하기: type의 어휘 (metric / table / api / process / runbook 등)와 tags

방법을 팀 내에서 합의한다. RAG의 필터 품질은 여기서 결정된다. -
RAG를 얹기: 번들(Bundle)을 임베딩(Embedding)하여 Vector DB로 보낸다. tags를 메타데이터(Metadata)에 포함하여 하이브리드 검색(Hybrid Search)을 구축한다. -
에이전트(Agent)를 연결하기: 사내 검색, 서포트, 분석 등 여러 에이전트를 동일한 OKF + RAG로 향하게 한다. 여기서 비로소 'OS'가 된다. -
지식은 부패한다: 업데이트 이력과 log.md를 통해 운영을 돌리고, timestamp로 신선도를 관리하며 오래된 개념을 지속적으로 관리(Maintenance)한다.

요약

레이어	역할	이전 기사와의 대응
OKF	조직 지식을 'AI가 읽을 수 있는 파일'로 패키징하는 형식	'구조는 디렉터리, 의미는 태그, index.md는 지도'의 표준화
...

**OKF는 '지식의 저장 형식', RAG는 '지식을 꺼내는 방법'**이다. 상하 레이어로 겹쳐졌을 때 강력해진다. - OKF의 내용(1개 개념 1개 파일, frontmatter 태그, index.md 지도, 표준 링크)은 지난번에 이야기한 'AI 친화적인 리포지터리(Repository)' 설계의 조직 스케일 버전 그 자체이다. - 오픈 사양(Open Specification)이기에 벤더 락인(Vendor Lock-in)을 피할 수 있으며, git clone으로 배포할 수 있다. 이것이 회사의 OS의 토대가 된다.

지난번에는 "당신의 리포지터리는 AI 에이전트가 가장 먼저 펼쳐볼 지도 한 장을 가지고 있는가?"라고 물었습니다. 이번에는 한 단계 더 확장된 질문으로 마무리하겠습니다.

당신의 회사는 어떤 AI 에이전트에게 물어도 동일한 답변이 돌아오는 '공통의 지식 기반(OS)'을 가지고 있습니까?

참고 링크

Discussion