Google Open Knowledge Format 해설: AI 에이전트 데이터 공유는 벡터DB보다 컨텍스트 파일 계약을 먼저 설계해야 하는 이유

발행일: 2026-06-14 | 카테고리: AI 활용법

1) 한 줄 문제 정의

핵심 요약: AI 에이전트가 데이터를 잘 쓰지 못하는 이유는 모델이 약해서만이 아니라, 조직 지식이 서로 다른 도구와 사람 머릿속에 흩어져 있기 때문입니다.

Google Cloud는 2026년 6월 13일 Open Knowledge Format, 줄여서 OKF를 공개했습니다. OKF는 데이터셋, 테이블, 지표, API, 런북 같은 지식을 Markdown 파일과 YAML frontmatter로 표현하는 초안 규격입니다. 쉽게 말하면 AI 에이전트와 사람이 함께 읽을 수 있는 데이터 지식용 공용 문서 폴더 규칙입니다.

이 글의 대상 독자는 사내 데이터 질의응답, RAG, BI 자동화, SQL 생성 에이전트, 업무 자동화 에이전트를 만들고 있는 개발자와 기획자입니다. 범위는 Google 발표 요약이 아니라, OKF를 어떤 상황에서 도입할 가치가 있는지, 벡터DB·데이터 카탈로그·사내 위키와 어떤 역할을 나눠야 하는지, 작게 시작하려면 어떤 파일부터 만들어야 하는지입니다.

반대로 OKF를 모든 지식관리 문제의 정답처럼 말하지는 않겠습니다. v0.1은 아직 초안이고, 권한·검증·자동 동기화·운영 책임은 각 팀이 별도로 설계해야 합니다.

2) 먼저 결론

핵심 요약: OKF는 새로운 데이터베이스가 아니라, AI가 읽을 수 있는 컨텍스트를 git처럼 관리하게 만드는 포맷입니다.

• 지금 볼 만한 팀: 데이터 카탈로그, 사내 위키, dbt 문서, Looker/BI 정의, 런북, 코드 주석이 따로 놀아 AI 답변이 자주 흔들리는 팀
• 아직 과한 팀: 테이블 수가 적고 담당자가 바로 답할 수 있으며, AI 에이전트가 실제 업무 판단에 쓰이지 않는 팀
• 제 판단: OKF의 핵심은 “Markdown이라 쉽다”가 아닙니다. 진짜 의미는 컨텍스트를 모델·클라우드·카탈로그 제품에서 떼어내 이동 가능한 계약으로 만든다는 점입니다.

저라면 OKF를 바로 전사 표준으로 밀지 않습니다. 먼저 가장 자주 틀리는 질문 20개를 고르고, 그 질문에 필요한 테이블·지표·조인·용어·런북만 작은 OKF 번들로 만들겠습니다. 그다음 SQL 생성 또는 데이터 Q&A 에이전트가 이 번들을 읽었을 때 답변 정확도, 출처 제시율, 잘못된 조인 감소율이 좋아지는지 측정하겠습니다.

3) 핵심 구조 분해

핵심 요약: OKF는 파일 폴더, YAML frontmatter, Markdown 본문, 내부 링크, index/log 파일이라는 다섯 조각으로 움직입니다.

3-1. Knowledge Bundle: 배포 단위

OKF에서 번들은 지식 문서들이 들어 있는 하나의 디렉터리입니다. git 저장소일 수도 있고, zip 파일일 수도 있고, 더 큰 저장소 안의 하위 폴더일 수도 있습니다. 중요한 점은 “서비스에 접속해야만 읽히는 지식”이 아니라 “파일로 복사하고 버전 관리할 수 있는 지식”이라는 점입니다.

3-2. Concept Document: 지식 하나당 파일 하나

테이블 하나, 지표 하나, API 하나, 업무 규칙 하나를 각각 Markdown 파일로 둡니다. 파일 경로가 곧 개념 ID가 됩니다. 예를 들어 tables/orders.md는 주문 테이블 개념을 가리키고, metrics/weekly_active_users.md는 주간 활성 사용자 지표를 가리킵니다.

3-3. YAML frontmatter: 최소 구조화 필드

파일 맨 위에는 YAML frontmatter가 들어갑니다. OKF v0.1에서 필수 필드는 type 하나입니다. 그 외 title, description, resource, tags, timestamp는 권장 필드입니다. 이 설계는 의도적으로 느슨합니다. 중앙 등록소 없이도 각 팀이 필요한 타입을 만들 수 있게 하기 위해서입니다.

3-4. Markdown body: 사람이 읽는 설명

본문은 표, 목록, 코드 블록, 예시 SQL, 운영 절차를 담습니다. AI 입장에서는 이 부분이 실제 답변 근거입니다. frontmatter가 검색과 필터링을 돕는다면, 본문은 “왜 이 테이블을 이렇게 조인해야 하는가” 같은 맥락을 설명합니다.

3-5. Markdown links: 폴더를 그래프로 바꾸는 장치

문서끼리는 일반 Markdown 링크로 연결합니다. orders 테이블이 customers 테이블과 조인된다면 본문에서 링크로 연결합니다. 이 링크가 쌓이면 단순 폴더 구조가 아니라 개념 간 관계 그래프가 됩니다. 에이전트는 전체 문서를 한 번에 읽지 않아도, index를 보고 필요한 문서로 이동할 수 있습니다.

4) 설계 의도 해설

핵심 요약: OKF는 “더 똑똑한 검색 서비스”보다 “누가 만들어도 읽히는 지식 파일”을 우선합니다.

많은 팀은 AI가 데이터를 못 다루면 먼저 벡터DB, 카탈로그, RAG 파이프라인부터 떠올립니다. 하지만 실제 실패 원인은 검색 인프라보다 앞단에 있습니다. 같은 지표 이름이 부서마다 다르고, 조인 규칙은 담당자만 알고, 오래된 테이블은 deprecated 되었는데 문서에는 남아 있고, SQL 예시는 Slack 어딘가에 묻혀 있습니다.

Google Cloud 블로그는 이 문제를 “흩어진 컨텍스트”로 봅니다. OKF는 이 컨텍스트를 한 서비스에 다시 가두는 대신, 파일 형식으로 꺼내려는 시도입니다. Markdown은 사람이 읽기 쉽고, YAML은 기계가 필터링하기 쉽고, git은 변경 이력과 리뷰를 남기기 쉽습니다.

여기서 중요한 트레이드오프가 있습니다. OKF는 스키마를 강하게 고정하지 않습니다. 그래서 도입은 쉽지만, 팀마다 type 이름이나 본문 섹션이 달라질 수 있습니다. 즉 OKF는 “완성된 카탈로그 제품”이 아니라 “카탈로그·위키·에이전트가 주고받을 최소 포맷”입니다. 이 차이를 이해해야 과도한 기대를 피할 수 있습니다.

5) 근거 및 비교

핵심 요약: OKF의 경쟁 상대는 벡터DB 하나가 아니라 사내 위키, 데이터 카탈로그, dbt 문서, RAG용 chunk 저장소 전체입니다.

공식 SPEC은 OKF가 도메인별 스키마를 대체하지 않는다고 명확히 선을 긋습니다. 이 점이 중요합니다. OKF는 OpenAPI나 dbt schema를 없애는 형식이 아니라, 그런 자료를 AI와 사람이 읽을 수 있는 지식 문서 안에서 연결하는 형식입니다.

Google Cloud의 Knowledge Catalog 발표와 연결해서 보면 방향은 더 분명합니다. Google은 카탈로그를 AI 에이전트의 컨텍스트 엔진으로 확장하고 있고, OKF는 그 컨텍스트를 외부와 교환 가능한 형태로 낮추는 역할을 합니다. 즉 제품 전략으로는 Knowledge Catalog, 교환 포맷으로는 OKF라는 분업입니다.

6) 실제 동작 흐름 / 단계별 실행 방법

핵심 요약: 처음부터 전사 지식 그래프를 만들지 말고, “AI가 자주 틀리는 데이터 질문”부터 OKF 번들로 고정해야 합니다.

Step 1. 실패 질문 20개를 고릅니다

예를 들어 “주간 활성 사용자는 어떻게 계산해?”, “환불 주문은 매출에서 빼야 해?”, “고객 테이블과 주문 테이블은 어떤 키로 조인해?” 같은 질문입니다. 이미 AI가 틀린 로그가 있다면 그 로그를 먼저 씁니다.

Step 2. 최소 폴더 구조를 만듭니다

okf-sales/
├── index.md
├── log.md
├── datasets/
│   └── sales.md
├── tables/
│   ├── orders.md
│   └── customers.md
├── metrics/
│   └── weekly_active_users.md
└── playbooks/
    └── revenue-quality-check.md

Step 3. 테이블 문서를 하나 작성합니다

---
type: BigQuery Table
title: Orders
description: 결제 완료 또는 환불된 주문 이벤트를 저장하는 테이블.
resource: bigquery://acme/sales/orders
tags: [sales, revenue, orders]
timestamp: 2026-06-14T00:00:00Z
---

# Schema
| Column | Type | Description |
|---|---|---|
| `order_id` | STRING | 주문 고유 ID |
| `customer_id` | STRING | [customers](/tables/customers.md)와 조인하는 키 |
| `status` | STRING | paid, refunded, canceled 중 하나 |

# Examples
```sql
select count(*) from sales.orders where status = 'paid';
```

# Citations
[1] BigQuery table schema: see the internal catalog resource bound above.

Step 4. 지표 문서에는 계산 규칙을 씁니다

AI SQL 생성에서 가장 위험한 것은 “그럴듯한 지표명”입니다. 따라서 지표 문서에는 정의, 제외 조건, 시간대, 중복 제거 기준, 검증용 SQL을 넣어야 합니다. OKF는 이 섹션을 강제하지 않지만, 실무에서는 팀 규칙으로 강제하는 편이 좋습니다.

Step 5. 에이전트 입력 경로를 정합니다

작게 시작할 때는 전체 OKF 번들을 매번 모델에 넣지 마십시오. 먼저 index.md와 질문 관련 후보 문서 3~7개만 검색해서 넣습니다. 고정 파일 번들은 원본이고, 검색 인덱스는 소비용 캐시라고 보면 됩니다.

7) 실수/함정(Pitfalls)

핵심 요약: OKF는 파일이라 쉬워 보이지만, 운영 기준이 없으면 또 하나의 오래된 문서 폴더가 됩니다.

• 실수 1: 모든 문서를 한 번에 OKF로 바꾸려 함
  예방: AI가 실제로 틀리는 질문과 연결된 문서부터 20~50개만 만듭니다.
  복구: 전환 범위를 줄이고, 질문 로그 기준으로 우선순위를 다시 잡습니다.
• 실수 2: frontmatter만 채우고 본문 설명을 비워 둠
  예방: 테이블 문서에는 예시 SQL, 조인 규칙, 제외 조건을 최소 1개 이상 넣습니다.
  복구: AI 오답을 본문 섹션으로 되돌려 “왜 틀렸는지”를 문서화합니다.
• 실수 3: 권한 모델을 파일 포맷에 맡김
  예방: OKF 번들을 만들 때 원본 시스템 권한과 동일한 공개 범위를 따로 적용합니다.
  복구: 민감 테이블, 고객정보, 내부 URL이 섞인 번들은 즉시 분리하고 접근 로그를 점검합니다.
• 실수 4: 자동 생성 문서를 리뷰 없이 배포
  예방: producer agent가 만든 문서는 pull request로 받고 데이터 오너 리뷰를 통과시킵니다.
  복구: 잘못된 문서를 만든 프롬프트, seed URL, 원본 metadata snapshot을 함께 보관해 재현합니다.
• 실수 5: 벡터DB와 OKF 역할을 혼동
  예방: OKF는 원본 계약, 벡터DB는 검색 캐시로 분리합니다.
  복구: 검색 결과가 틀렸을 때 캐시를 직접 고치지 말고 OKF 원본 문서를 수정한 뒤 재색인합니다.

8) 강점과 한계

핵심 요약: OKF의 강점은 이동성과 리뷰 가능성이고, 한계는 표준이 아직 얇다는 점입니다.

강점

• 읽기 장벽이 낮습니다. Markdown과 YAML이라 개발자, 데이터 분석가, AI 에이전트가 같은 파일을 볼 수 있습니다.
• 버전 관리가 자연스럽습니다. git diff, PR 리뷰, blame, 릴리스 태그를 지식 문서에도 적용할 수 있습니다.
• 플랫폼 종속이 약합니다. 특정 클라우드, 모델, 프레임워크, 카탈로그 제품 없이도 읽고 옮길 수 있습니다.
• AI 에이전트 탐색에 맞습니다. index 파일과 내부 링크를 쓰면 필요한 문서만 단계적으로 열어볼 수 있습니다.

한계

• v0.1 초안입니다. 타입 체계, 섹션 관례, 검증 도구 생태계는 아직 성숙해야 합니다.
• 권한과 보안은 별도 문제입니다. 파일 포맷이 접근 제어를 자동으로 해결하지 않습니다.
• 동기화 책임이 남습니다. 원본 스키마가 바뀌었는데 OKF 문서가 늦게 바뀌면 AI는 오래된 컨텍스트를 믿을 수 있습니다.
• 대규모 검색은 별도 인프라가 필요합니다. 파일 포맷만으로 relevance ranking, ACL-aware search, 평가까지 해결되지는 않습니다.

반례: 이미 데이터 카탈로그가 잘 운영되고 있고, AI 에이전트도 그 카탈로그 API를 안정적으로 읽으며, 지표 정의와 권한이 중앙에서 잘 관리된다면 OKF를 별도로 만들 필요가 작을 수 있습니다. 반대로 도구는 많은데 AI가 매번 같은 조인과 지표를 틀리는 팀이라면 OKF는 작은 실험으로도 효과를 확인하기 좋습니다.

9) 더 깊게 공부할 포인트

핵심 요약: OKF를 제대로 보려면 Markdown 문법보다 컨텍스트 운영, metadata as code, 검색 평가를 함께 봐야 합니다.

• OKF SPEC: 필수 필드가 왜 type 하나뿐인지, 소비자가 깨진 링크와 알 수 없는 타입을 어떻게 다뤄야 하는지 읽어야 합니다.
• Google knowledge-catalog 저장소: BigQuery metadata에서 OKF 번들을 만들고, web pass로 문서를 보강하고, HTML visualizer로 보는 흐름을 확인할 수 있습니다.
• LLM wiki 패턴: 에이전트가 작업용 문서를 직접 읽고 갱신하는 방식이 왜 다시 주목받는지 이해하는 데 도움이 됩니다.
• Knowledge Catalog: OKF가 파일 포맷이라면, 카탈로그는 권한·검색·평가·연결을 담당하는 운영 계층입니다.
• 컨텍스트 평가: 답변 정확도만 보지 말고, 필요한 문서를 찾았는지, 오래된 문서를 피했는지, 근거가 답변 문장을 실제로 지지하는지 측정해야 합니다.

10) 실행 체크리스트 + 작성자 관점

핵심 요약: 저는 OKF를 “AI용 문서 포맷”보다 “팀 지식을 코드처럼 다루는 최소 계약”으로 보는 쪽이 실무적으로 맞다고 봅니다.

• AI가 자주 틀리는 데이터 질문 20개가 정리되어 있는가?
• 각 질문에 필요한 테이블, 지표, 조인, 용어, 런북이 파일로 추적 가능한가?
• 모든 concept 문서에 type과 사람이 읽을 수 있는 title, description이 있는가?
• 지표 문서에 계산 SQL, 제외 조건, 시간대, 소유자가 포함되어 있는가?
• 민감 데이터와 내부 URL이 들어간 OKF 번들의 접근 권한을 원본 시스템과 맞췄는가?
• 자동 생성 문서는 데이터 오너가 PR로 리뷰하는가?
• OKF 원본과 벡터DB/검색 인덱스의 재색인 흐름이 분리되어 있는가?
• AI 답변 평가에서 “정답 여부”와 “근거 문서 적중 여부”를 따로 보고 있는가?

Definition of Done: 대표 질문 20개에서 OKF 번들을 사용한 에이전트가 필요한 concept 문서를 80% 이상 찾아내고, 지표 정의·조인·출처를 포함한 답변을 재현 가능하게 생성하면 1차 도입은 성공으로 봅니다.

제 추천: OKF는 지금 당장 큰 플랫폼 이전 프로젝트로 볼 필요가 없습니다. 가장 좋은 시작은 “우리 회사에서 AI가 계속 틀리는 데이터 용어 10개”를 OKF로 만드는 것입니다. 이 작은 번들이 효과를 보이면, 그때 producer agent, visualizer, 검색 인덱스, 카탈로그 연동으로 넓히면 됩니다. 데이터 공유의 병목은 종종 저장소가 아니라 맥락의 계약 부재입니다. OKF는 그 계약을 작고 오래가는 파일로 만들자는 제안입니다.

참고자료

• Google Cloud Blog - Introducing the Open Knowledge Format (2026-06-13)
• Open Knowledge Format v0.1 Draft SPEC
• GoogleCloudPlatform/knowledge-catalog OKF repository
• Google Cloud Blog - Introducing the Google Cloud Knowledge Catalog (2026-04-23)
• Andrej Karpathy - LLM wiki gist