구글의 새로운 지식 표준, OKF(Open Knowledge Format)란 무엇인가?

요즘 IT 업계의 화두는 단연 ‘AI 에이전트’입니다. 단순한 챗봇을 넘어 스스로 생각하고 행동하는 AI 비서를 만드는 일에 많은 기업들이 뛰어들고 있습니다.

Erik Peterson

하지만 실제로 사내에 AI 에이전트를 도입해 보면 생각보다 똑똑하게 굴지 못하는 경우가 많습니다. 왜일까요? 모델 성능이 부족해서라기보다, 정작 AI가 일을 할 때 필요한 내부 정보들이 여기저기 흩어져 있기 때문입니다.

구글이 최근 공개한 OKF(Open Knowledge Format)는 이 문제를 해결하기 위해 나온 오픈 규격입니다. 사람이 보든 AI가 보든, 바로 가져다 쓸 수 있는 표준화된 지식 포맷을 만들자는 시도입니다. 이게 구체적으로 무엇이고 어떻게 쓰이는지, 그리고 많이 언급되는 LLM Wiki와는 무엇이 다른지 정리해 보았습니다.

1. 구글의 OKF(Open Knowledge Format)란?

회사 내 지식은 파편화되기 쉽습니다.

• 특정 데이터 테이블의 가이드라인
• 올해 비즈니스 매출 지표의 정의
• 긴급한 서버 장애 시 대처 시나리오

이런 정보들은 컨플루언스, 노션, 깃허브 코드 주석, 혹은 시니어 개발자의 머릿속에 제각각 흩어져 있습니다. AI 에이전트를 가동하려 해도 이 정보들이 서로 호환되지 않아, 매번 매뉴얼을 처음부터 학습시키거나 검색(RAG)을 위한 무거운 시스템을 직접 구축해야 했습니다.

OKF는 지식의 단위를 ‘노트’처럼 표준화하여 이 장벽을 허물고자 합니다. 쉽게 말해 “AI와 사람이 동시에 읽을 수 있는 표준 양식의 지식 문서”입니다.

2. OKF 기술 스펙과 포맷 상세 분석

구글이 공개한 OKF v0.1 스펙 초안(Draft)을 뜯어보면, 복잡한 인프라나 특정 기술에 얽매이지 않고 오직 파일 시스템과 텍스트 약속만으로 상호운용성을 확보하려 한 고민의 흔적이 보입니다.

① 지식 꾸러미(Knowledge Bundle)와 디렉토리 구조

OKF에서 배포하고 공유하는 지식의 최소 단위를 ‘지식 꾸러미(Knowledge Bundle)’라고 부릅니다. 이 꾸러미는 특별한 데이터베이스가 아니라, 파일 시스템 상의 폴더와 파일들의 계층 구조(Tree)일 뿐입니다.

기본 구조는 다음과 같습니다:

path/to/bundle/
├── index.md                      # 최상위 디렉토리 목록 (점진적 노출용)
├── log.md                        # 변경 이력을 담은 chronological 로그 파일
├── some_concept.md               # 루트 디렉토리의 개념 파일
└── tables/                       # 하위 폴더로 분류 가능
    ├── index.md
    └── users.md                  # 테이블에 관한 개념 파일 (Concept ID: tables/users)

여기에는 두 가지 특별한 예약어 파일이 존재합니다:

• index.md (디렉토리 목록): 폴더 내에 포함된 문서들을 카테고리별로 정렬해 둡니다. AI나 사람이 한 번에 수천 개의 문서를 전부 메모리에 올리지 않고, 인덱스 파일을 먼저 읽은 뒤 필요한 문서로 파고드는 ‘점진적 노출(Progressive Disclosure)’을 지원하는 핵심 장치입니다.
• log.md (변경 이력 로그): 언제 어떤 정보가 주입(Ingest)되거나 수정되었는지를 타임라인 순으로 기록해 둡니다.

지식 꾸러미는 로컬 폴더 그대로 쓸 수도 있지만, 버전 관리와 동료들 간의 협업(리뷰, 히스토리 추적)을 위해 Git 저장소 형태로 배포하고 관리하는 것이 가장 권장됩니다.

② 개념(Concept) 문서의 물리적 포맷

꾸러미 내부에서 다루는 각각의 독립된 지식 단위를 ‘개념(Concept)’이라고 하며, 하나의 파일(.md)로 저장합니다. 이 파일은 반드시 UTF-8 형식이어야 하며 두 부분으로 구분됩니다.

YAML Frontmatter (메타데이터 영역)

문서 가장 상단에 --- 구분자로 감싸진 메타정보 입력 영역입니다. 기계가 빠르고 직관적으로 분류(Filtering)하고 라우팅할 수 있도록 정형 데이터 구조를 띱니다.

• type (필수): 이 지식의 본질이 무엇인지 정의합니다. (예: BigQuery Table, API Endpoint, Metric, Playbook 등)
• title (권장): 사람이 읽기 편한 제목입니다. 생략 시 파일명이 제목이 됩니다.
• description (권장): 한 줄 요약입니다. 인덱스 생성이나 AI의 빠른 미리보기에 활용됩니다.
• resource (권장): 이 지식과 매핑되는 실제 시스템 상의 canonical URI입니다. (예: 특정 테이블의 클라우드 콘솔 링크)
• tags (권장): 다차원적인 탐색을 위한 태그 목록입니다.
• timestamp (권장): 마지막 수정 시각(ISO 8601 형식)입니다.

사용자는 위 표준 필드 외에도 필요한 임의의 필드를 메타데이터에 자유롭게 확장하여 넣을 수 있습니다.

Markdown Body (본문 영역)

Frontmatter 아래에는 사람이 자유롭게 줄글로 설명하는 영역입니다. AI가 실제 상세 맥락을 파악해야 할 때 이 부분을 꼼꼼하게 독해합니다.

③ 지식 그래프(Graph-shaped) 구축

폴더 구조는 단순히 트리(Tree) 형태에 머물지만, OKF 안의 지식들은 본문 영역에 적힌 마크다운 내부 링크([텍스트](/path/to/another_concept.md))를 통해 서로 촘촘하게 엮입니다. 이를 통해 단순 트리 구조를 넘어서는 입체적인 지식 그래프(Graph)가 형성됩니다. AI가 관련 문서들을 탐색하고 추론할 때 이 링크 정보를 따라가며 깊이 있는 문맥을 이해하게 됩니다.

3. 실제 업무에서 어떻게 쓰일 수 있을까?

기술적인 스펙보다 더 중요한 건 실제 체감되는 활용성입니다. 실무에서 겪을 수 있는 세 가지 상황을 예로 들어보겠습니다.

① 신규 팀원의 인수인계와 온보딩

새 팀원이 합류하면 히스토리를 파악하는 데 시간이 걸립니다. 위키 링크를 수십 개 전달해 주거나 메신저로 매번 툴 사용법을 물어보곤 하죠. 여기에 OKF를 적용하면 편리해집니다. 개발 규칙이나 사내 FAQ 등을 OKF 규격에 맞춰 정리해 두고 이를 사내 AI 비서에게 연동해 놓는 것입니다. 새 팀원이 AI에게 “우리 팀 배포 규칙이 어떻게 돼?”라고 물어보면, AI가 OKF로 잘 정리된 지식 폴더를 훑어 정확한 가이드를 알려주므로 온보딩 비용을 크게 줄일 수 있습니다.

② 데이터 분석가와 기획자의 데이터 스펙 공유

마케팅이나 기획 부서에서 분석을 진행할 때, 특정 매출 데이터 테이블의 속성에 대해 매번 데이터 팀원에게 DM을 보내 질문하는 번거로움이 있습니다. 데이터 엔지니어가 테이블의 상세 가이드와 지표(Metric) 정의를 OKF 마크다운 문서로 변환해 두면 해결됩니다. 기획자가 “이번 달 총매출 계산을 위해 어떤 테이블을 봐야 해?”라고 질문하면, AI 비서가 OKF 문서를 확인하고 필요한 SQL 쿼리를 정확하게 작성해 줍니다. 데이터 팀의 불필요한 질의응답 리소스가 세이브됩니다.

③ 기획-개발 간의 스펙 불일치 방지

기획서의 기능 요구사항이 바뀌었는데, 개발 명세서(API 가이드)나 피그마 UI 화면에 이를 깜빡하고 연동하지 않아 에러가 나는 일이 잦습니다. 프로젝트 기획 문서, 디자인 파일 링크, API 가이드라인을 하나의 OKF 번들로 묶어두고 서로 연결하면 좋습니다. 요구사항 문서가 바뀔 때, AI가 연결된 지식 그래프를 훑어보고 “기획서의 결제 로직이 바뀌었습니다. 이와 연결된 API 명세 문서도 변경이 필요합니다”라고 먼저 짚어줄 수 있습니다.

4. 지식 관리의 새로운 패러다임, LLM Wiki와의 연결성

OKF를 이해하는 데 빼놓을 수 없는 흐름이 있습니다. 바로 AI 연구자 안드레이 카파시(Andrej Karpathy)가 제안한 LLM Wiki 패턴입니다.

카파시는 “인간이 위키를 쓰다 결국 방치하게 되는 이유는 유지보수의 번거로움(링크 연결, 중복 제거, 낡은 정보 수정) 때문이다”라고 짚었습니다. 그리고 이를 해결하기 위해 지루한 지식 정리(사서 업무)를 LLM에게 전부 넘겨버리는 패러다임을 제안했습니다. 사용자는 단순 정보나 웹 아티클을 툭 던져두기만 하면, AI가 알아서 기존 문서를 갱신하고 정리하며 지식을 누적(Compounding)해 나가는 방식입니다.

구글의 OKF는 이 LLM Wiki의 아이디어를 가져와서, 다양한 시스템과 AI가 서로 약속된 형태로 지식을 공유할 수 있게 규격화한 것입니다.

5. OKF와 LLM Wiki, 무엇이 다를까?

두 개념 모두 ‘마크다운으로 지식을 관리한다’는 뿌리는 같지만, 그 지향점이 다릅니다.

• 개념의 성격: LLM Wiki는 AI가 지식을 업데이트하고 쌓아가는 워크플로우이자 행동 패턴(아이디어)에 가깝습니다. 반면 OKF는 이 지식을 담아내기 위한 구체적인 파일 규격(스펙)입니다.
• 목표: LLM Wiki는 정보가 지속해서 합성되고 누적되는 ‘과정’이 핵심입니다. 반면 OKF는 서로 다른 도구와 AI 플랫폼 간에 번역 없이도 정보를 원활히 주고받는 ‘호환성’에 초점을 맞춥니다.
• 자율성: LLM Wiki는 자유도가 높아 각자 원하는 폴더와 문서 형태로 구성하지만, OKF는 최소한의 상호 규격(YAML 포맷, 필수 type 태그 등)을 지켜야 합니다.
• 비유: LLM Wiki가 “지식을 수집하고 정제하여 끓여내는 조리법(Recipe)”이라면, OKF는 그 요리를 타 시스템에 온전히 배달하기 위한 “포장 규격(Box Specification)”입니다.

구글 역시 블로그 글을 통해 자신들이 공개한 OKF가 카파시의 LLM Wiki 패턴을 상호운용이 가능하도록 공식 표준 스펙으로 정립한 것임을 설명하고 있습니다.

6. 마치며: OKF가 바꿀 문서화의 미래

OKF가 가져다줄 변화는 명확합니다.

하나는 개인이 AI 비서와 협업하며 정리한 지식(LLM Wiki)을 OKF 포맷 그대로 전사 시스템에 배포하여 팀 전체가 바로 활용할 수 있게 된다는 점입니다. 다른 하나는 구글이 함께 오픈소스로 선보인 에이전트(Enrichment Agent)처럼, 기존 데이터베이스를 AI가 돌아다니며 가이드를 스스로 작성하고 규격 문서로 뽑아내는 자동화가 실현된다는 점입니다.

AI를 단순한 채팅 상대가 아닌 지식을 같이 쌓아가는 동료로 대하는 시대, OKF는 그 지식들이 서로 통할 수 있게 만드는 첫 단추가 될 수 있습니다.

관련 링크

• Google Cloud Blog — How the Open Knowledge Format can improve data sharing
• GitHub — Google Cloud Platform Knowledge Catalog
• Andrej Karpathy Gist — LLM Wiki