Google OKF로 설계하는 AI 에이전트 지식 교환 아키텍처

에이전트마다 달랐던 지식 포맷을 맞추다

Google Cloud는 2026년 6월 12일 AI 에이전트가 조직 지식을 벤더 중립적으로 교환할 수 있도록 Open Knowledge Format(OKF) v0.1을 공개했다. BigQuery Tech Lead인 Sam McVeety와 Amir Hormati가 주도했으며, 사양은 451행의 Markdown 명세로 작성됐다. Apache 2.0 라이선스를 적용해 GoogleCloudPlatform/knowledge-catalog 저장소에서 배포한다.

멀티에이전트 환경에서는 여러 에이전트가 같은 지식을 사용해야 하지만, 실제 프로젝트에서는 위키·스프레드시트·API 문서를 프레임워크별로 다시 파싱하거나 임베딩하는 경우가 많았다. LangChain, CrewAI, ADK 등에 같은 비즈니스 지식을 연결하면서도 별도 커넥터를 반복해서 만들어야 했다.

이 방식은 팀마다 서로 다른 컨텍스트 파일이 쌓이는 지식 사일로를 만든다. 비정형 문서를 그대로 주입하면 LLM이 맥락을 잘못 해석할 위험도 커진다. 어떤 지식 업데이트가 어느 에이전트에 반영됐는지 추적할 공통 메커니즘도 없었다.

Google은 이를 “LLM wiki 패턴의 비공식성” 문제로 보고, 별도 인프라 없이 파일시스템과 Git만으로 읽을 수 있는 Markdown 기반 표준을 제안했다. OKF는 에이전트 간 지식 포맷 표준 부재를 해결하려는 첫 번째 벤더 중립 시도다.

개념 하나를 문서 하나로 표현한다

OKF의 기본 단위는 **개념 문서(concept document)**다. 메트릭, 테이블, 데이터셋, API, 런북, 플레이북 같은 개념 하나를 Markdown 파일 하나에 대응시킨다.

문서 사이의 관계는 전용 그래프 문법이 아니라 [text](./other-concept.md) 형태의 표준 Markdown 링크로 표현한다. 디렉터리 안에 연결된 문서가 쌓이면 번들 전체가 자연스럽게 지식 그래프로 동작한다.

knowledge-bundle/
├── log.md                     # 번들 수준 감사 로그 (ISO 8601)
├── metrics/
│   ├── log.md                 # 디렉터리 수준 감사 로그
│   ├── daily-active-users.md  # 개념 문서
│   └── revenue-per-user.md
├── tables/
│   ├── events.md
│   └── sessions.md
└── runbooks/
    └── incident-response.md

각 문서의 YAML 프론트매터에는 에이전트가 본문 전체를 읽기 전에 검색과 분류에 사용할 메타데이터를 둔다.

필드	필수 여부	역할
`type`	필수	metric, table, dataset, api, runbook 등의 개념 유형
`title`	권장	사람이 읽는 개념 이름
`description`	권장	에이전트 검색에 활용할 간략한 개념 설명
`resource`	선택	BigQuery 테이블이나 API 엔드포인트 같은 실제 리소스 URI
`tags`	선택	검색과 필터링에 쓰는 분류 태그 배열
`timestamp`	선택	ISO 8601 형식의 마지막 업데이트 시각

---
type: metric
title: Daily Active Users (DAU)
description: 하루 동안 앱에 접속한 고유 사용자 수. 세션 기준이 아닌 사용자 기준.
resource: bigquery://my-project.analytics.events
tags: [engagement, core-kpi, product]
timestamp: 2026-06-15T09:00:00Z
---

## 정의

DAU는 `events` 테이블에서 `event_name = 'session_start'` 조건으로 집계한다.

## 관련 메트릭

- [Monthly Active Users](./monthly-active-users.md)
- [세션당 평균 시간](./avg-session-duration.md)

번들을 Git 저장소로 운영하는 방식

OKF에서 번들은 개념 문서가 모인 디렉터리 집합이다. 디렉터리 자체를 Git 저장소로 관리하므로 버전 이력, 브랜치, Pull Request 리뷰를 지식 관리 과정에 그대로 적용할 수 있다.

에이전트는 목적별 커넥터 없이 파일시스템에서 문서를 읽거나 저장소를 clone해 번들을 소비한다. 같은 파일을 사람은 GitHub UI에서 열람하고 편집하며, 에이전트는 컨텍스트로 주입한다. 이 구조가 OKF가 내세우는 Git 네이티브, Zero-infrastructure Read, Human-Agent 이중 가독성의 기반이다.

⤢✕

사내 지식을 OKF 번들로 옮기는 순서

도입의 출발점은 새로운 문서를 만드는 일이 아니라 기존 에이전트가 이미 참조하는 지식을 찾는 일이다.

에이전트 프롬프트에 하드코딩됐거나 RAG로 처리 중인 문서를 목록화한다. 핵심 KPI 정의, 주요 데이터 테이블 스키마, 서비스 런북이 우선 대상이다.
각 항목에 type을 부여하고 description을 작성해 개념 문서 초안을 만든다. BigQuery 레퍼런스 구현처럼 LLM으로 기존 문서에서 OKF 초안을 생성하는 방식도 사용할 수 있다.
번들을 GitHub Enterprise나 GitLab 같은 사내 Git 서버에 올린다. 브랜치 보호와 코드 리뷰 정책은 지식 거버넌스 정책으로 다시 해석한다.
에이전트 시작 시 저장소를 clone하거나 Git sparse-checkout으로 필요한 서브디렉터리만 가져와 컨텍스트에 넣는다.

RAG와 경쟁시키지 않고 정형 지식으로 보완한다

OKF와 RAG는 대체 관계가 아니다. OKF는 사람이 큐레이션하고 버전을 관리하는 개념의 정규 표현(canonical representation)이다. RAG는 대규모 비정형 문서 코퍼스에서 질의와 관련된 청크를 찾는 동적 검색 메커니즘이다.

두 방식을 연결할 때는 OKF as structured seed 패턴을 적용할 수 있다. OKF 개념 문서는 청크로 나누지 않고 전체를 임베딩해 RAG 인덱스의 고품질 시드로 사용한다. 나머지 비정형 문서는 기존 청크 기반 파이프라인에서 처리한다.

[OKF 번들] ─→ 전체 문서 임베딩 (청크 없음)
                        ↓
            [벡터 DB — OKF 네임스페이스]
                        ↓
[비정형 문서] ─→ 청크 임베딩 → [벡터 DB — 일반 네임스페이스]
                        ↓
            [하이브리드 리트리버 — OKF 우선순위 부스팅]
                        ↓
                [LLM 컨텍스트 조립]

이 구성에서는 OKF 문서에 리트리버 스코어 가중치를 주어 비정형 문서보다 먼저 노출한다.

여러 에이전트가 같은 번들을 읽게 하려면

멀티에이전트 환경에서는 쓰기 경로와 읽기 경로를 분리할 수 있다. Knowledge Authority Agent가 OKF 번들에 대한 유일한 쓰기 권한을 갖고 지식 업데이트 PR을 생성한다. 변경은 리뷰 승인을 거쳐 머지한다.

Knowledge Consumer Agents는 번들을 읽기 전용으로 clone한다. 최신 변경은 주기적인 git pull이나 webhook으로 감지한다.

번들 전체를 컨텍스트에 넣는 방식이 부담스럽다면 MCP Knowledge Server를 선택적으로 배치할 수 있다. MCP 도구로 OKF 번들을 노출하고, 에이전트가 필요한 개념만 동적으로 질의하게 만들어 토큰 사용을 줄이는 구성이다.

변경 이력을 지식 거버넌스로 확장한다

각 디렉터리의 log.md는 변경 감사 로그를 보관한다. 이를 기업 지식 관리 체계로 확장할 때는 Git의 기존 제어 기능을 함께 사용할 수 있다.

v1.0.0, v1.1.0 같은 Semantic Versioning 태그로 번들 버전을 표시하면 에이전트가 특정 버전에 고정될 수 있다. PR을 머지하기 전에는 CI에서 필수 필드인 type, ./referenced-file.md 형태의 링크 유효성, timestamp의 ISO 8601 준수 여부를 검사한다.

서브디렉터리별 책임자는 CODEOWNERS에 매핑한다. 비즈니스 지식이 변경될 때 해당 도메인 팀의 승인을 요구하는 방식이다.

기존 지식 도구와의 경계

항목	Google OKF v0.1	OpenAI Memory API	LangChain Knowledge Base
출시 시기	2026년 6월 12일	2024년 하반기 (점진적 롤아웃)	지속적 업데이트
지식 저장 위치	Git 저장소 (로컬/원격)	OpenAI 서버 (벤더 종속)	개발자 인프라 (다양)
벤더 중립성	완전 중립 (Apache 2.0)	OpenAI 전용	부분 중립 (오픈소스이나 LangChain 생태계 의존)
포맷	Markdown + YAML 프론트매터	JSON (API 응답)	다양 (VectorStore, SQL, Graph 등)
버전 관리	Git 네이티브	없음 (스냅샷)	별도 구현 필요
Human Readability	높음 (GitHub 렌더링)	낮음 (API 쿼리 필요)	중간 (포맷에 따라 상이)
인프라 요구사항	없음 (파일시스템만)	OpenAI API 접근 필요	VectorDB 등 별도 인프라
적용 범위	정형 개념 문서	사용자 선호/기억	광범위 (비정형 포함)
라이선스	Apache 2.0	독점	MIT (LangChain 프레임워크)
멀티에이전트 공유	Git pull로 즉시 공유	에이전트별 별도 메모리	공유 VectorStore 구성 필요

llms.txt는 도메인 루트인 example.com/llms.txt에 두고 외부 AI 크롤러에 사이트 구조를 안내하는 공개 파일이다. OKF는 조직 내부 에이전트가 공유하는 사설 지식 번들이므로 쓰임새가 겹치지 않는다.

MCP는 에이전트가 외부 도구를 동적으로 호출하기 위한 통신 프로토콜이고, OKF는 지식의 저장 포맷이다. MCP 서버가 OKF 번들을 지식 소스로 노출하는 형태로 함께 사용할 수 있다.

RAG 역시 검색 메커니즘이라는 점에서 저장 포맷인 OKF와 역할이 다르다. OKF 문서에는 명시적인 type과 description이 있어 청크 분할 없이도 고품질 임베딩 입력으로 활용할 수 있다.

Google Cloud가 제공한 구현 경로

Google은 OKF v0.1과 함께 두 가지 레퍼런스 구현을 내놓았다.

BigQuery 강화 에이전트는 BigQuery 데이터셋을 순회하며 테이블 스키마와 설명을 바탕으로 OKF 개념 문서 초안을 자동 생성한다. GA4 전자상거래와 Bitcoin 블록체인 등 BigQuery 공개 데이터셋이 샘플 번들에 포함됐다.

정적 HTML 시각화기는 번들 내부의 Markdown 링크를 파싱해 노드와 엣지로 구성된 인터랙티브 지식 그래프를 렌더링한다.

2026년 4월 10일 Dataplex에서 리브랜딩된 Google Cloud Knowledge Catalog는 OKF 번들과 양방향 동기화를 지원한다. 로컬 YAML·Markdown 변경을 클라우드 카탈로그에 반영하는 구조이며, “메타데이터의 Git”이라는 개념으로 설명된다.

BDC Connect for Google BigQuery는 2026년 2분기 GA(General Availability)로 출시됐다. 데이터 프로덕트를 Google Dataplex 카탈로그를 통해 직접 공유하며, OKF 번들은 이 데이터 공유 레이어의 지식 표현 포맷으로 기능한다.

지식 표현과 정보 아키텍처로 읽는 OKF

OKF는 지식 관리 이론과도 연결된다. 노나카의 SECI 모델에서 암묵지(tacit knowledge)를 형식지(explicit knowledge)로 바꾸는 표출화(Externalization)를 조직 지식에 적용한 형태로 해석할 수 있다. 비정형 지식을 YAML 메타데이터가 붙은 Markdown 문서로 만드는 과정이 이에 해당한다.

YAML 프론트매터는 Dublin Core 메타데이터와 개념적으로 유사하다. type, title, description, resource, tags, timestamp는 각각 DC.type, DC.title, DC.description, DC.source, DC.subject, DC.date에 대응한다.

번들의 디렉터리 구조는 파셋 분류(faceted classification)를 구현한다. type으로 메트릭·테이블·API 같은 수직 분류를 만들고, 디렉터리 계층으로 도메인별 수평 분류를 함께 제공한다.

CODEOWNERS와 Git PR 리뷰를 결합한 워크플로우는 COBIT 5의 정보 관련 거버넌스 원칙 가운데 정보의 책임성(Accountability)과 변경 관리(Change Management)를 코드베이스 수준에서 구현하는 메커니즘으로 볼 수 있다.

단순함이 장점인지 한계인지는 아직 열려 있다

OKF v0.1을 두고는 긍정적인 평가와 비판이 함께 나온다. 가장 자주 제기되는 지적은 “결국 Markdown 파일 폴더에 불과하다(just a folder of Markdown files)”는 것이다. 새로운 기술 요소가 적다는 비판이다.

실질적인 벤더 중립성은 Google의 BigQuery, Dataplex, ADK 밖에서 채택되는지로 판단해야 한다. 그러나 2026년 6월 현재 다른 벤더가 공식 지원을 발표한 사례는 없다. OKF 적용 에이전트와 미적용 에이전트의 성능이나 환각 빈도를 비교한 벤치마크도 공개되지 않아 정량적 효과를 검증하기 어렵다.

Google은 v0.1을 “완성된 표준이 아닌 출발점(a starting point rather than a finished standard)”이라고 명시했다. 커뮤니티 피드백을 반영해 반복적으로 발전시키고, 장기적으로 IETF나 W3C 같은 표준화 기구에 제출할 가능성도 열어 두었다.

채택 범위가 표준의 운명을 가른다

2026년 하반기에는 LangChain, LlamaIndex, CrewAI 같은 대형 에이전트 프레임워크에서 OKF 번들을 직접 읽는 로더 통합이 등장할 것으로 예상된다. Google의 ADK(Agent Development Kit)가 먼저 공식 통합을 제공할 가능성이 높다.

2027년에는 Collibra, Alation, Atlan 같은 기업 데이터 카탈로그가 OKF 번들을 익스포트 포맷으로 채택하거나 기존 카탈로그 자산을 OKF로 변환하는 커넥터를 제공할 가능성이 있다. 그렇게 되면 기존 데이터 거버넌스 투자와 AI 에이전트 지식 관리가 연결된다.

2028년 이후의 벤더 중립성은 Microsoft, AWS, OpenAI 같은 주요 플레이어의 공식 채택에 달려 있다. 여러 클라우드 벤더가 지원한다면 OKF는 에이전트 포터빌리티를 위한 핵심 레이어가 될 수 있다. 채택 범위가 Google Cloud에 머문다면 해당 생태계의 편의 도구로 남을 가능성도 있다.

기술적 혁신성만 놓고 보면 YAML 메타데이터가 붙은 Markdown 디렉터리는 단순하다. 그 단순함 덕분에 별도 인프라 없이 시작할 수 있고, RAG의 고품질 시드와 멀티에이전트 공유 번들, Git 기반 지식 거버넌스에 같은 포맷을 적용할 수 있다. 공통 지식 언어가 없던 에이전트 생태계의 공백을 실제 표준으로 메울 수 있는지는 다른 플랫폼의 채택 과정에서 드러날 것이다.