기업이 생성형 AI와 에이전트를 업무에 붙이기 시작하면서, 병목은 점점 모델 자체보다 ‘모델이 참고할 수 있는 지식의 형태’로 이동하고 있습니다. 문서가 많다는 것과 AI가 활용할 수 있는 지식 기반이 있다는 것은 다릅니다. 사람이 읽기 위해 작성된 위키, 데이터 카탈로그, 운영 문서, 코드 저장소의 README는 각각 유용하지만, 에이전트가 일관된 방식으로 탐색하고 조합하기에는 형식과 맥락이 제각각입니다.
이 지점에서 Google Cloud의 Open Knowledge Format, 즉 OKF는 단순한 문서 포맷 이상의 의미를 갖습니다. OKF는 새로운 지식관리 서비스라기보다, LLM 위키 패턴을 휴대 가능하고 상호운용 가능한 공개 사양으로 공식화하려는 시도입니다.1 핵심은 조직의 메타데이터, 맥락, 큐레이션된 지식을 사람과 에이전트가 모두 다루기 쉬운 파일 단위로 정리하자는 데 있습니다.
왜 ‘파일 형식’이 다시 중요해졌나
AI 도입 초기에는 검색 증강 생성, 벡터 데이터베이스, 에이전트 프레임워크 같은 실행 기술에 관심이 집중됐습니다. 그러나 실제 운영 단계에서는 더 기초적인 문제가 드러납니다. 어떤 지식을 신뢰할 것인지, 누가 고칠 수 있는지, 변경 이력을 어떻게 남길 것인지, 특정 도구를 바꿔도 지식 자산을 유지할 수 있는지가 중요해집니다.
전통적인 엔터프라이즈 지식 시스템은 대체로 애플리케이션 중심입니다. 데이터 카탈로그에는 데이터 자산 설명이 있고, 위키에는 업무 정의가 있으며, 티켓 시스템에는 운영 이력이 남습니다. 반면 AI 에이전트는 특정 화면을 보는 사람이 아니라, 구조화된 맥락을 입력으로 받아 작업하는 소프트웨어입니다. 따라서 지식은 사람이 읽을 수 있으면서도 기계가 안정적으로 해석할 수 있는 중간 형태를 필요로 합니다.
OKF가 주목하는 지점이 바로 이 중간층입니다. 복잡한 플랫폼을 먼저 도입하기보다, 지식을 이동 가능한 번들로 만들고 여러 도구가 같은 파일을 읽게 하자는 접근입니다.
OKF의 설계 철학: 낮은 진입장벽과 높은 이동성
OKF v0.1에서 지식은 YAML 프런트매터가 포함된 Markdown 파일 디렉터리로 표현됩니다.2 다시 말해 OKF 번들은 특별한 바이너리 패키지나 전용 데이터베이스가 아니라, Markdown 문서들의 묶음입니다. 복잡한 압축 방식이나 별도 런타임이 필요하지 않으며, 전용 SDK 없이도 읽고 쓸 수 있도록 설계됐습니다.1
이 선택은 기술적으로 화려하지 않지만 실무적으로는 중요합니다. Markdown 문서는 일반 편집기에서 열 수 있고 GitHub에서도 렌더링됩니다.1 개발자와 데이터 엔지니어는 Git으로 변경 이력을 관리할 수 있고, 문서 담당자나 분석가도 비교적 쉽게 내용을 확인할 수 있습니다. 에이전트 역시 별도 변환 계층 없이 텍스트와 메타데이터를 함께 활용할 수 있습니다.
또 하나의 특징은 최소 스키마입니다. OKF의 필수 필드는 type 하나입니다.2 이는 초기 도입 장벽을 낮춥니다. 조직마다 지식의 종류와 세부 메타데이터가 다르기 때문에, 처음부터 무거운 공통 모델을 강제하면 채택이 어려워집니다. OKF는 최소한의 타입 식별만 요구하고, 나머지는 사용 사례에 따라 확장할 수 있는 방향에 가깝습니다.
배포 방식도 특정 서비스에 종속되지 않습니다. OKF 번들은 tarball로 전달하거나, Git 저장소에 호스팅하거나, 파일시스템에 마운트할 수 있습니다.1 이 점은 벤더 종속을 우려하는 조직에 의미가 있습니다. 지식이 어느 한 SaaS나 에이전트 프레임워크 내부에만 갇히지 않고, 파일 형태로 이동할 수 있기 때문입니다.
Google Cloud가 제공한 구체적 출발점
확인된 구현 측면에서 Google Cloud는 OKF를 도입했고, 사양과 코드를 GitHub에 공개했습니다.23 또한 BigQuery 데이터셋을 크롤링해 각 테이블의 OKF 문서를 만드는 enrichment agent를 제공합니다.3
이 예시는 OKF의 현실적인 적용 영역을 보여줍니다. 데이터 조직에서 테이블은 단순한 스키마 이상의 의미를 갖습니다. 어떤 목적으로 만들어졌는지, 어떤 지표 계산에 쓰이는지, 주의해야 할 컬럼은 무엇인지, 최신성이 어떤지 같은 맥락이 함께 있어야 합니다. OKF는 이런 설명을 Markdown 본문과 YAML 메타데이터로 묶어, 사람이 검토하고 에이전트가 참조할 수 있는 단위로 만들 수 있습니다.
다만 BigQuery 연동은 OKF의 전부가 아닙니다. 중요한 것은 특정 데이터웨어하우스용 자동 문서화 기능이 아니라, 지식 표현을 파일 기반 공개 형식으로 분리했다는 점입니다.
기대효과와 현실적 한계
OKF의 장점은 명확합니다. 첫째, 지식의 소유권과 이동성이 높아집니다. 파일로 존재하는 지식은 저장소를 옮기거나 다른 도구에 연결하기가 상대적으로 쉽습니다. 둘째, 사람과 에이전트가 같은 원천을 볼 수 있습니다. 사람이 수정한 Markdown 문서를 에이전트가 읽고, 에이전트가 보강한 내용을 사람이 검토하는 순환 구조를 만들 수 있습니다. 셋째, Git 기반 워크플로와 잘 맞습니다. 변경 이력, 리뷰, 승인 절차를 기존 개발 문화 위에 얹을 수 있습니다.
하지만 해결해야 할 질문도 남아 있습니다. OKF는 v0.1 단계이므로 타입 체계가 어디까지 표준화될지, 서로 다른 조직이 만든 OKF 문서가 실제로 얼마나 잘 호환될지, 문서 품질과 최신성을 어떻게 관리할지에 대한 답은 앞으로의 채택 과정에서 검증돼야 합니다. 필수 필드가 적다는 것은 도입이 쉽다는 뜻이지만, 동시에 조직 내부 규칙이 부실하면 문서 간 일관성이 떨어질 수 있다는 뜻이기도 합니다.
또한 파일 형식은 거버넌스를 자동으로 해결하지 않습니다. 어떤 지식을 공식으로 볼 것인지, 에이전트가 생성한 보강 내용을 누가 승인할 것인지, 민감한 정보가 Markdown 파일에 섞이지 않도록 어떻게 통제할 것인지는 별도의 운영 설계가 필요합니다.
도입을 검토한다면 무엇부터 볼 것인가
OKF를 평가할 때는 ‘우리 조직의 모든 문서를 바꿀 수 있는가’보다 ‘AI가 자주 실패하는 지식 공백을 파일로 고정할 수 있는가’를 먼저 봐야 합니다. 예를 들어 핵심 데이터셋, 자주 참조되는 지표 정의, 반복적인 운영 절차처럼 에이전트가 정확히 알아야 하는 지식부터 후보가 될 수 있습니다.
다음으로는 세 가지를 점검할 필요가 있습니다. 첫째, type을 중심으로 내부 분류 규칙을 얼마나 단순하게 정할 수 있는가. 둘째, Git 리뷰나 문서 승인 절차와 연결해 최신성을 유지할 수 있는가. 셋째, 기존 카탈로그·위키·데이터 파이프라인과 중복을 만들지 않고 연결할 수 있는가.
OKF의 의미는 거대한 표준의 완성이 아니라, AI 시대의 지식 관리가 다시 파일, 버전관리, 이식성이라는 기본기로 돌아가고 있음을 보여준다는 데 있습니다. 앞으로 봐야 할 것은 GitHub에 공개된 사양과 코드가 어떻게 확장되는지, BigQuery 같은 구체적 자산 외에 다른 업무 지식에도 적용될 수 있는지, 그리고 여러 도구와 에이전트가 실제로 같은 OKF 번들을 공유하는 생태계가 형성되는지입니다.
1Introducing the Open Knowledge Format
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.