- OKF는 마크다운 파일 묶음과 YAML 프론트매터, 그리고 각 개념에 단 하나의 type 필드를 요구하는 최소 명세로, LLM-위키 패턴을 형식화한 vendor-neutral 오픈 스펙이다
- 구글 클라우드는 세 가지 설계 원칙과 참조 도구, Python 컨슈머 예제, 인터랙티브 번들 탐색기를 함께 공개했다
- 기존 RAG 방식과 구분되는 큐레이션 기반 컨텍스트 전달 방식을 지향하며, 인간이 정제한 지식 번들을 에이전트가 안정적으로 소비하도록 설계된 vendor-neutral 오픈 스펙으로 규정된다
OKF는 검색이 아닌 큐레이션으로 에이전트 컨텍스트를 정의한다는 점에서 RAG를 대체하는 것이 아니라 보완하는 명세로 해석된다
2026년 6월 구글 클라우드는 AI 에이전트가 신뢰할 수 있는 컨텍스트를 안정적으로 소비할 수 있도록 돕는 오픈 명세인 Open Knowledge Format, 약칭 OKF를 공개했다. 이 명세는 단순한 파일 포맷 제안이 아니라 LLM-위키 패턴을 표준화하려는 시도라는 점에서 업계 관심을 모으고 있다. 본문에서는 OKF의 구조, 설계 원칙, 함께 공개된 참조 도구, 그리고 RAG와의 비교를 통해 도입 여부를 판단할 수 있는 기준을 제시한다.
OKF의 등장 배경과 구글 클라우드의 의도
LLM-위키 패턴의 한계와 표준화 필요성
여러 팀이 LLM-위키 형태로 마크다운 지식 베이스를 운영해 왔으나, 디렉터리 구조와 메타데이터가 제각각이라 에이전트 측 파서가 표준화되지 못한 문제가 있었다. OKF는 이러한 암묵적 패턴을 명시적 명세로 승격시켜 파서 의존도를 낮추고, 도구 생태계 형성을 촉진하기 위한 시도로 소개된다.
벤더 중립 명세를 선택한 전략적 의미
구글 클라우드가 특정 클라우드 서비스에 종속되지 않는 vendor-neutral 형태로 스펙을 정의한 것은 채택률을 높이기 위한 선택으로 보인다. 특정 벤더가 소유한 포맷은 생태계 확장에서 저항을 받기 쉬우며, 오픈 명세는 표준 경쟁에서 유리한 위치를 확보한다. 이는 OKF가 사실상 표준이 되려는 전략적 포석일 가능성이 있다.
OKF의 기술적 구조와 설계 원칙 3가지
번들의 기본 구성: 마크다운 디렉터리와 YAML 프론트매터
OKF 번들의 가장 작은 단위는 마크다운 파일과 YAML 프론트매터의 조합이다. 디렉터리 안에 개념 단위 문서가 배치되고, 각 문서 상단에 메타데이터 블록이 위치한다. 이 구조는 GitHub 위키나 정적 사이트 생성기에서 흔히 사용되는 패턴과 유사해 진입 장벽을 낮추며, 기존 문서 자산을 큰 변환 없이 OKF 번들로 재구성할 수 있는 이점을 제공한다.
type 필드 중심의 최소 메타데이터 설계
OKF가 요구하는 핵심 메타데이터는 개념당 단 하나의 type 필드이다. 이는 의도적인 최소화 결정으로, 명세의 강제 필드를 최소화함으로써 작성자 부담을 줄이고 확장을 용이하게 한다. 나머지 메타데이터는 권장 사항으로 두고 생태계가 스스로 표준을 형성하도록 유도하는 구조이다.
세 가지 설계 원칙 해설
구글 클라우드는 OKF의 설계 원칙으로 최소 명세, 인간 가독성, 도구 친화성을 제시한 것으로 기사에서 요약된다. 최소 명세는 type 필드 하나로 압축되며, 인간 가독성은 마크다운 사용을 통해 확보된다. 도구 친화성은 참조 도구와 Python 컨슈머 코드를 함께 출하해 생태계 진입 비용을 낮추는 방식으로 구현된다. 세 원칙은 서로 모순되지 않으면서도 빠른 채택을 가능하게 하는 균형점인 것으로 분석된다.
구글 클라우드가 함께 공개한 참조 도구
참조 구현 도구의 역할
구글 클라우드는 OKF 명세와 함께 참조(reference) 도구를 공개했다. 이 도구는 OKF 번들이 명세를 만족하는지 검증하는 역할을 하며, 파서 개발자에게는 표준 동작의 기준선이 된다. 참조 구현의 존재는 명세 해석의 모호성을 해소하고 생태계 분열을 방지하는 효과가 있다.
Python 컨슈머 코드 동작 방식
기사에 포함된 Python 컨슈머 코드는 OKF 번들을 읽어 인덱싱하는 최소 구현을 보여준다. 디렉터리 순회, 프론트매터 파싱, type 필드 검증을 거쳐 검색 가능한 지식 그래프를 구성한다. 개발자는 이 코드를 베이스로 자사 시스템에 맞는 컨슈머를 손쉽게 작성할 수 있다.
인터랙티브 번들 탐색기의 활용 시나리오
인터랙티브 번들 탐색기는 브라우저에서 OKF 번들의 구조를 시각적으로 탐색하도록 돕는다. 문서 간 링크 관계, type 분포, 메타데이터 일관성을 즉시 확인할 수 있어 작성자 교육과 리뷰에 유용하다. 비개발 직군도 명세 품질을 손쉽게 감사할 수 있는 도구로 활용 가능하다.
RAG와 OKF의 비교 및 도입 시 고려사항
검색 기반 vs 큐레이션 기반 컨텍스트
전통적인 RAG는 대규모 코퍼스에서 관련 청크를 검색해 컨텍스트로 전달한다. 반면 OKF는 인간이 큐레이션한 정제된 지식 번들을 에이전트에 직접 전달한다. 두 방식은 상호 배타적이라기보다 보완 관계로 해석된다. RAG는 광범위한 검색 범위를, OKF는 인간 큐레이션을 거친 신뢰성과 일관성 강점을 제공한다.
| 구분 | RAG | OKF |
|---|---|---|
| 데이터 출처 | 전체 코퍼스 | 큐레이션된 번들 |
| 컨텍스트 품질 | 검색 정확도에 의존 | 사전 검증된 일관성 |
| 유지보수 | 인덱스 갱신 | 번들 버전 관리 |
| 적합한 시나리오 | 광범위한 Q&A | 에이전트 도메인 지식 |
에이전트 워크플로 통합 포인트
OKF 번들은 에이전트의 시스템 프롬프트나 도구 설명에 임베드되거나, 함수 호출을 통해 동적으로 주입될 수 있다. RAG 파이프라인의 전처리 단계로 활용하면 검색 정확도를 높이면서도 검증된 컨텍스트를 우선 노출할 수 있다. 통합 시나리오는 명세 공개 이후 생태계가 형성해 갈 영역으로 예상된다.
도입 시 비용, 유지보수, 거버넌스
도입 비용 측면에서 OKF는 마크다운 작성 역량이 있는 조직이라면 낮게 시작할 수 있다. 다만 큐레이션이 핵심이므로 전담 문서 책임자와 거버넌스 체계가 필요하다. 장기적으로는 번들 버전 관리 정책과 갱신 워크플로가 운영 비용을 결정짓는 요소로 부상할 가능성이 있다.
시사점과 향후 전망
OKF는 AI 에이전트 시대를 맞아 컨텍스트의 신뢰성 문제를 명세 차원에서 해결하려는 시도라는 점에서 의의가 있다. 향후 유사한 명세와의 경쟁에서 살아남으려면 참조 도구의 품질과 생태계 참여자 수, 그리고 거버넌스 투명성이 핵심 변수가 될 것으로 보인다. 단기적으로는 자사 지식 베이스의 OKF 호환 여부를 점검하고, RAG와 병행하는 파일럿을 설계해 보는 것이 현실적인 첫 단계로 판단된다. 본문 분석은 기사 공개 사실에 기반한 해석이며, 시장 채택 효과는 별도 검증이 필요하다.
- OKF는 type 필드 하나만 요구하는 최소 명세로 진입 장벽을 최소화한 점이 강점이다
- 구글 클라우드가 vendor-neutral 형태를 선택한 것은 사실상 표준 경쟁을 의식한 전략으로 해석된다
- RAG를 대체하기보다 큐레이션 계층을 추가하는 보완 명제로 접근하는 것이 합리적이다
- 동반 공개된 참조 도구와 Python 컨슈머 코드는 생태계 초기 전환 비용을 낮추는 핵심 자산이다
- 도입 성패는 번들 거버넌스와 전담 문서 운영 조직의 성숙도에 달려 있을 가능성이 높다