Google Cloud가 공개한 Open Knowledge Format, OKF 쉽게 이해하기

AI 에이전트 시대, 지식은 문서가 아니라 “포맷”이 된다

AI를 업무에 붙여보면 금방 깨닫는 문제가 하나 있습니다.

모델 자체가 부족해서가 아니라,
모델이 참고해야 할 맥락이 흩어져 있다는 것입니다.

예를 들어 회사 안에서 AI 에이전트에게 이렇게 물었다고 해보겠습니다.

“우리 서비스의 주간 활성 사용자, WAU는 어떻게 계산해?”

사람이라면 누군가에게 물어보고, 노션 문서를 뒤지고, BigQuery 테이블을 확인하고, 예전 슬랙 대화를 찾아볼 수 있습니다. 하지만 AI 에이전트 입장에서는 이 정보들이 모두 서로 다른 장소에 있습니다.

데이터 스키마는 데이터 카탈로그에 있고,
지표 정의는 노션에 있고,
운영 절차는 위키에 있고,
예외 규칙은 시니어 개발자의 머릿속에 있습니다.

Google Cloud는 이 문제를 “지식이 너무 많은 곳에 흩어져 있고, 서로 호환되지 않는다”는 문제로 봅니다. 그리고 그 해결책으로 Open Knowledge Format, 줄여서 OKF를 소개했습니다. (Google Cloud)

---

OKF는 무엇인가?

OKF는 쉽게 말하면,

AI 에이전트와 사람이 함께 읽을 수 있는
지식 정리용 오픈 포맷입니다.

더 구체적으로는 Markdown 파일 + YAML frontmatter 조합으로 지식을 표현하는 방식입니다. Google Cloud 설명에 따르면 OKF v0.1은 지식을 여러 개의 Markdown 파일 디렉터리로 표현하고, 각 파일 상단에 YAML frontmatter를 붙이는 구조입니다. (Google Cloud)

중요한 점은 이겁니다.

OKF는 새로운 데이터베이스가 아닙니다.
OKF는 새로운 SaaS도 아닙니다.
OKF는 특정 클라우드나 특정 AI 모델에 묶인 SDK도 아닙니다.

그냥 파일입니다.

Markdown이기 때문에 사람이 읽을 수 있고,
GitHub에서 바로 볼 수 있고,
검색 도구가 인덱싱할 수 있고,
AI 에이전트가 그대로 컨텍스트로 읽을 수 있습니다. Google Cloud는 OKF 번들이 “just markdown”, “just files”, “just YAML frontmatter”라는 점을 강조합니다. (Google Cloud)

---

왜 지금 OKF가 필요한가?

지금 많은 조직은 AI 에이전트를 만들면서 비슷한 문제를 반복해서 풀고 있습니다.

에이전트가 정확한 답을 하려면 조직 내부 지식이 필요합니다. 예를 들면 이런 것들입니다.

• 테이블 스키마
• 지표 정의
• API 사용법
• 운영 runbook
• 장애 대응 절차
• 데이터 간 join 경로
• deprecated 된 API 안내
• 특정 비즈니스 용어의 내부 정의

문제는 이 지식들이 한곳에 있지 않다는 것입니다. 원문에서도 조직 내부 지식이 메타데이터 카탈로그, 위키, 공유 드라이브, 코드 주석, 노트북 셀, 소수의 시니어 엔지니어 머릿속 등에 흩어져 있다고 설명합니다. (Google Cloud)

그러다 보니 새로운 AI 에이전트를 만들 때마다 같은 작업을 다시 하게 됩니다.

“이 테이블은 무슨 뜻이지?”
“이 지표는 어디서 계산하지?”
“이 API는 아직 써도 되나?”
“이 장애가 나면 어떤 순서로 확인하지?”
“이 정보는 최신인가?”

AI 에이전트 개발에서 진짜 병목은 모델 호출 코드가 아니라,
쓸 만한 지식을 어떻게 구조화해서 넣어줄 것인가가 됩니다.

OKF는 이 문제를 “또 하나의 지식 관리 서비스”로 풀지 않습니다.
대신 모든 도구가 읽고 쓸 수 있는 공통 포맷으로 풀려고 합니다.

---

OKF의 기본 구조

OKF 번들은 하나의 폴더입니다.
그 안에 Markdown 파일들이 들어갑니다.

예를 들어 커머스 서비스의 데이터 지식을 OKF로 정리하면 이런 식이 될 수 있습니다.

commerce/
├── index.md
├── datasets/
│   ├── index.md
│   └── ecommerce_db.md
├── tables/
│   ├── index.md
│   ├── orders.md
│   ├── customers.md
│   └── events.md
└── metrics/
    ├── index.md
    ├── weekly_active_users.md
    └── conversion_rate.md

여기서 중요한 원칙은 간단합니다.

하나의 개념은 하나의 파일로 표현합니다.

예를 들어 orders.md는 주문 테이블에 대한 설명이고,
weekly_active_users.md는 WAU 지표 정의 문서입니다.

각 파일은 보통 이렇게 생겼습니다.

---
type: table
title: Orders
description: 완료된 주문 정보를 저장하는 테이블
resource: bigquery://my-project.commerce.orders
tags: [commerce, sales, revenue]
timestamp: 2026-06-14T09:00:00Z
---

# 개요

`orders` 테이블은 사용자의 완료된 주문을 저장한다.

# 주요 컬럼

| Column | Type | Description |
|---|---|---|
| order_id | STRING | 주문 고유 ID |
| customer_id | STRING | 고객 ID |
| order_amount | NUMERIC | 주문 금액 |
| created_at | TIMESTAMP | 주문 생성 시각 |

# 조인 관계

- `customer_id`를 기준으로 [customers](../tables/customers.md) 테이블과 조인한다.

# 자주 쓰는 쿼리

```sql
SELECT
  DATE(created_at) AS order_date,
  COUNT(*) AS order_count,
  SUM(order_amount) AS total_revenue
FROM commerce.orders
GROUP BY order_date
ORDER BY order_date DESC;

상단의 `---` 사이에 있는 부분이 YAML frontmatter입니다.

여기에는 기계가 읽기 좋은 구조화된 정보가 들어갑니다.

```yaml
type: table
title: Orders
description: 완료된 주문 정보를 저장하는 테이블
resource: bigquery://my-project.commerce.orders
tags: [commerce, sales, revenue]
timestamp: 2026-06-14T09:00:00Z

본문은 사람이 읽기 좋은 Markdown입니다.

즉, OKF는 구조화된 필드와 자유로운 설명을 함께 담습니다. Google Cloud의 GitHub README도 OKF가 type, resource, tags, timestamp 같은 쿼리·필터·인덱싱용 frontmatter와, 사람이 실제로 읽는 설명·스키마·예제 쿼리용 Markdown 본문을 함께 사용한다고 설명합니다. (GitHub)

---

예제 1. 지표 정의를 OKF로 만들기

AI 에이전트가 데이터 분석을 도와주려면 지표 정의가 명확해야 합니다.

예를 들어 “WAU”라는 지표를 생각해보겠습니다.
회사마다 WAU의 정의가 다를 수 있습니다.

어떤 회사는 로그인 기준으로 볼 수 있고,
어떤 회사는 특정 핵심 이벤트 발생 기준으로 볼 수 있고,
어떤 회사는 봇·테스트 계정을 제외해야 할 수도 있습니다.

이 정의를 OKF 문서로 만들면 이렇게 됩니다.

---
type: metric
title: Weekly Active Users
description: 최근 7일 동안 핵심 활동 이벤트를 1회 이상 수행한 고유 사용자 수
resource: bigquery://my-project.analytics.events
tags: [metric, product, engagement]
timestamp: 2026-06-14T09:00:00Z
---

# 정의

Weekly Active Users, WAU는 최근 7일 동안 핵심 활동 이벤트를 1회 이상 수행한 고유 사용자 수다.

# 포함 이벤트

다음 이벤트 중 하나 이상을 수행한 사용자를 active user로 본다.

- app_open
- lesson_start
- purchase_complete
- content_view

# 제외 조건

다음 사용자는 제외한다.

- 내부 테스트 계정
- 관리자 계정
- 봇으로 분류된 계정
- 삭제된 계정

# 계산 예시

```sql
SELECT
  COUNT(DISTINCT user_id) AS weekly_active_users
FROM analytics.events
WHERE event_name IN (
  'app_open',
  'lesson_start',
  'purchase_complete',
  'content_view'
)
AND event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
AND user_id NOT IN (
  SELECT user_id
  FROM analytics.excluded_users
);

관련 문서

• events table
• excluded users

이렇게 해두면 AI 에이전트는 “WAU 계산해줘”라는 요청을 받았을 때, 단순히 이벤트 테이블을 추측하지 않습니다.

먼저 `weekly_active_users.md`를 읽고,  
그 안의 정의와 제외 조건을 확인하고,  
관련 테이블 문서로 이동한 뒤,  
쿼리를 작성할 수 있습니다.

[Inference] 이 방식은 RAG 시스템의 검색 대상 문서를 더 명확하게 만들고, 에이전트가 잘못된 지표 정의를 임의로 추측하는 위험을 줄이는 데 도움이 될 수 있습니다. 단, 실제 정확도 향상 정도는 검색 파이프라인, 문서 품질, 모델, 평가 방식에 따라 달라집니다.

---

# 예제 2. API 문서를 OKF로 만들기

OKF는 데이터 카탈로그에만 쓸 수 있는 형식이 아닙니다. 원문은 OKF 개념 문서가 테이블, 데이터셋, 메트릭, 플레이북, 런북, API 등 원하는 지식을 담을 수 있다고 설명합니다. :contentReference[oaicite:6]{index=6}

예를 들어 결제 API를 OKF 문서로 만든다면 이렇게 정리할 수 있습니다.

```markdown
---
type: api
title: Create Payment API
description: 사용자의 결제 요청을 생성하는 API
resource: https://api.example.com/v1/payments
tags: [payment, api, backend]
timestamp: 2026-06-14T09:00:00Z
---

# 개요

Create Payment API는 사용자가 상품을 구매할 때 결제 요청을 생성한다.

# Endpoint

```http
POST /v1/payments

Request Body

{
  "user_id": "user_123",
  "product_id": "product_456",
  "amount": 19000,
  "currency": "KRW"
}

Response

{
  "payment_id": "pay_789",
  "status": "pending",
  "checkout_url": "https://checkout.example.com/pay_789"
}

주의사항

• amount는 서버에서 상품 가격을 기준으로 재검증한다.
• 클라이언트가 보낸 금액을 그대로 신뢰하지 않는다.
• 결제 완료 여부는 webhook 이벤트로 최종 확인한다.

관련 문서

• Payment Webhook
• Orders Table

이렇게 문서화하면 AI 코딩 에이전트가 결제 기능을 수정할 때 더 안전하게 작업할 수 있습니다.

예를 들어 사용자가 이렇게 요청할 수 있습니다.

> “결제 성공 후 주문 상태를 paid로 바꾸는 코드를 추가해줘.”

에이전트는 결제 API 문서만 보는 것이 아니라,  
Payment Webhook 문서와 Orders Table 문서까지 따라가며 확인할 수 있습니다.

OKF는 Markdown 링크를 통해 개념 간 관계를 표현합니다. Google Cloud는 이러한 링크들이 디렉터리를 단순한 트리 구조가 아니라 관계 그래프처럼 만들어준다고 설명합니다. :contentReference[oaicite:7]{index=7}

---

# 예제 3. 장애 대응 Runbook을 OKF로 만들기

AI 에이전트가 운영 업무를 도와주려면 장애 대응 절차도 지식으로 관리되어야 합니다.

예를 들어 “결제 승인 실패율 증가” 장애 runbook은 이렇게 만들 수 있습니다.

```markdown
---
type: runbook
title: Payment Approval Failure Spike
description: 결제 승인 실패율이 평소보다 급격히 증가했을 때 확인하는 절차
resource: internal://runbooks/payment-approval-failure
tags: [payment, incident, runbook]
timestamp: 2026-06-14T09:00:00Z
---

# 증상

다음 지표 중 하나 이상이 발생하면 이 runbook을 확인한다.

- 결제 승인 실패율이 10분 이상 5%를 초과
- PG사 timeout error 증가
- 결제 완료 webhook 지연 증가

# 1차 확인

## 1. PG사 상태 페이지 확인

PG사 장애 공지가 있는지 확인한다.

## 2. 최근 배포 확인

최근 1시간 내 결제 관련 배포가 있었는지 확인한다.

## 3. 에러 로그 확인

다음 키워드로 로그를 검색한다.

```text
payment_timeout
pg_auth_failed
webhook_signature_invalid

임시 대응

• PG사 장애가 확인되면 공지 배너를 노출한다.
• 내부 배포 문제가 의심되면 직전 버전으로 롤백한다.
• webhook 지연이면 주문 상태를 pending으로 유지하고 재처리 큐를 확인한다.

관련 문서

• Create Payment API
• Payment Webhook
• Orders Table

이런 문서가 OKF 형태로 정리되어 있으면, 장애 상황에서 AI 에이전트에게 이렇게 물을 수 있습니다.

> “지금 결제 실패율이 올라갔는데, 어떤 순서로 확인해야 해?”

그러면 에이전트는 runbook을 읽고, 관련 API와 테이블 문서까지 연결해서 대응 순서를 제안할 수 있습니다.

[Inference] 특히 운영 조직에서는 OKF를 Git으로 관리하면 runbook 변경 이력, 리뷰, 승인 절차를 코드처럼 관리할 수 있습니다. Google Cloud의 GitHub README도 OKF 번들이 Git에 저장될 수 있고 PR, diff, blame, review workflow를 활용할 수 있다고 설명합니다. :contentReference[oaicite:8]{index=8}

---

# OKF의 핵심 장점

## 1. 사람과 AI가 같은 문서를 읽는다

기존 문서 시스템에서는 사람용 문서와 기계용 메타데이터가 분리되는 경우가 많습니다.

사람은 노션을 보고,  
시스템은 API를 보고,  
AI 에이전트는 별도 인덱스를 봅니다.

OKF는 이 구조를 단순화합니다.

Markdown 본문은 사람이 읽고,  
YAML frontmatter는 기계가 읽습니다.

같은 파일을 사람이 리뷰하고,  
같은 파일을 AI가 검색하고,  
같은 파일을 에이전트가 컨텍스트로 가져갈 수 있습니다.

## 2. 특정 벤더에 묶이지 않는다

OKF는 특정 클라우드, 데이터베이스, 모델 제공자, 에이전트 프레임워크에 묶이지 않는 포맷으로 소개되었습니다. Google Cloud는 OKF가 proprietary account나 SDK를 요구하지 않는 open standard라고 설명합니다. :contentReference[oaicite:9]{index=9}

이 점이 중요합니다.

회사 지식은 한 번 쌓이면 오래갑니다.  
그런데 특정 벤더의 전용 포맷에만 저장하면 나중에 옮기기 어렵습니다.

OKF는 폴더와 Markdown 파일이기 때문에 GitHub, GitLab, 로컬 파일 시스템, 정적 파일 서버, Obsidian, MkDocs, Hugo 같은 기존 도구와 잘 어울립니다. Google Cloud의 GitHub README도 Notion, Obsidian, MkDocs, Hugo, Jekyll 같은 Markdown 기반 도구들과 조합할 수 있다고 설명합니다. :contentReference[oaicite:10]{index=10}

## 3. 지식을 코드처럼 관리할 수 있다

OKF의 큰 장점은 지식을 Git으로 관리할 수 있다는 점입니다.

예를 들어 지표 정의가 바뀌면 Pull Request를 만들 수 있습니다.

```diff
- WAU는 최근 7일 동안 로그인한 사용자 수다.
+ WAU는 최근 7일 동안 핵심 활동 이벤트를 1회 이상 수행한 사용자 수다.

리뷰어는 이렇게 코멘트할 수 있습니다.

“관리자 계정 제외 조건도 명시해주세요.”

승인 후 merge하면 변경 이력이 남습니다.

누가, 언제, 왜 지표 정의를 바꿨는지 추적할 수 있습니다.

이것은 단순한 문서 관리가 아니라
조직 지식을 버전 관리하는 방식입니다.

4. 에이전트가 탐색하기 쉽다

OKF는 index.md 파일을 선택적으로 둘 수 있습니다. 원문은 index.md가 에이전트가 계층 구조를 단계적으로 탐색하는 데 도움이 될 수 있다고 설명합니다. (Google Cloud)

예를 들어 에이전트가 처음부터 모든 문서를 읽을 필요는 없습니다.

먼저 commerce/index.md를 읽고,
그다음 tables/index.md를 읽고,
필요한 경우 orders.md로 들어갈 수 있습니다.

이것은 LLM 컨텍스트를 절약하는 데도 유리합니다.

[Inference] 긴 문서 전체를 무작정 넣는 방식보다, 계층적 index와 링크를 따라 필요한 문서만 읽는 방식이 에이전트 설계에 더 적합할 수 있습니다. 다만 실제 성능은 검색기, 라우팅 방식, 컨텍스트 정책에 따라 달라집니다.

---

OKF와 RAG는 어떤 관계인가?

많은 사람이 OKF를 보면 “이거 RAG용 문서 포맷인가?”라고 생각할 수 있습니다.

절반은 맞고, 절반은 다릅니다.

RAG는 보통 검색 시스템입니다.

문서를 쪼개고,
임베딩하고,
벡터DB에 넣고,
질문과 관련 있는 조각을 찾아
LLM에 넣어주는 방식입니다.

OKF는 검색 시스템 자체가 아닙니다.
OKF는 검색하기 좋은 지식 원본을 만드는 포맷에 가깝습니다.

즉 관계를 이렇게 볼 수 있습니다.

OKF = 지식을 정리하는 표준 파일 포맷
RAG = 그 지식을 검색해서 LLM에 넣는 실행 방식

OKF 문서를 RAG 파이프라인에 넣을 수 있습니다.
하지만 OKF는 RAG 없이도 쓸 수 있습니다.

예를 들어 코딩 에이전트가 로컬 파일 시스템에서 OKF 폴더를 직접 읽게 할 수도 있고,
정적 HTML 뷰어로 사람이 탐색할 수도 있고,
검색 인덱스로 변환할 수도 있습니다.

Google Cloud의 GitHub README도 OKF 번들이 Markdown을 읽는 어떤 도구로든 소비될 수 있으며, 정적 파일 서버, 지식 관리 UI, LLM 컨텍스트, 검색 인덱스, 그래프 뷰어 등 다양한 소비 방식을 언급합니다. (GitHub)

---

OKF를 실제로 어디에 쓸 수 있을까?

1. 데이터팀의 지표 사전

가장 현실적인 사용처는 데이터팀입니다.

• KPI 정의
• 테이블 설명
• 컬럼 의미
• join 방법
• SQL 예제
• deprecated 테이블 안내
• 대시보드와 지표 연결

이런 정보를 OKF로 관리하면 AI 데이터 분석 에이전트가 훨씬 명확한 기준으로 답할 수 있습니다.

예를 들어 에이전트에게 이렇게 시킬 수 있습니다.

“지난 4주간 신규 가입자의 구매 전환율을 계산하는 SQL을 작성해줘. 우리 회사의 conversion_rate 정의를 기준으로 해줘.”

에이전트는 conversion_rate.md, users.md, orders.md, events.md를 읽고 쿼리를 작성할 수 있습니다.

2. 개발팀의 API·아키텍처 문서

개발팀에서는 API 문서, 서비스 간 의존성, 배포 절차를 OKF로 정리할 수 있습니다.

backend/
├── services/
│   ├── auth_service.md
│   ├── payment_service.md
│   └── notification_service.md
├── apis/
│   ├── create_payment.md
│   └── send_push.md
└── runbooks/
    ├── payment_failure.md
    └── notification_delay.md

이렇게 해두면 코딩 에이전트에게 단순히 “코드 수정해줘”라고 하는 것이 아니라,

“OKF 문서를 먼저 읽고, payment_service의 설계 원칙을 지키면서 수정해줘.”

라고 요청할 수 있습니다.

3. 고객지원팀의 운영 지식

고객지원팀도 OKF를 쓸 수 있습니다.

• 환불 정책
• 계정 복구 절차
• 자주 묻는 질문
• 예외 처리 기준
• 내부 escalations
• 고객 유형별 응대 가이드

예를 들어 환불 정책 문서는 이렇게 만들 수 있습니다.

---
type: policy
title: Refund Policy
description: 구독 상품 환불 처리 기준
resource: internal://policies/refund
tags: [support, refund, subscription]
timestamp: 2026-06-14T09:00:00Z
---

# 기본 원칙

구독 결제 후 7일 이내이고, 유료 기능 사용 이력이 없으면 전액 환불 가능하다.

# 예외

다음 경우에는 수동 검토가 필요하다.

- 중복 결제
- 미성년자 결제
- 결제 오류
- 프로모션 코드 사용
- 부분 사용 후 환불 요청

# 상담원 응대 예시

고객에게 먼저 결제일, 계정 이메일, 사용 여부를 확인한다.

고객지원 AI 에이전트는 이 문서를 읽고 상담 답변 초안을 만들 수 있습니다.

---

OKF를 도입할 때의 현실적인 시작 방법

처음부터 전사 지식 전체를 OKF로 바꾸려고 하면 실패하기 쉽습니다.

작게 시작하는 편이 좋습니다.

1단계: 가장 자주 물어보는 지식 10개만 고른다

예를 들어 데이터팀이라면 다음 10개를 고릅니다.

• WAU 정의
• MAU 정의
• 구매 전환율 정의
• 매출 테이블
• 주문 테이블
• 사용자 테이블
• 이벤트 테이블
• 테스트 계정 제외 기준
• 주요 대시보드 목록
• deprecated 테이블 목록

2단계: 하나의 폴더에 Markdown으로 정리한다

처음부터 완벽한 구조를 만들 필요는 없습니다.

okf/
├── index.md
├── metrics/
│   ├── weekly_active_users.md
│   └── conversion_rate.md
└── tables/
    ├── users.md
    ├── orders.md
    └── events.md

3단계: frontmatter 필드만 통일한다

최소한 다음 필드만 통일해도 충분합니다.

type:
title:
description:
resource:
tags:
timestamp:

원문에서도 OKF는 최소한의 구조를 지향하며, 모든 concept에 요구되는 것은 type 필드 하나라고 설명합니다. 다른 필드나 본문 구성은 생산자가 정할 수 있습니다. (Google Cloud)

4단계: AI 에이전트에게 “먼저 OKF를 읽어라”라고 지시한다

예를 들어 코딩 에이전트나 데이터 분석 에이전트에게 다음과 같이 지시할 수 있습니다.

작업을 시작하기 전에 /okf/index.md를 먼저 읽어라.
관련 metric, table, api 문서를 확인한 뒤 답변하라.
추측하지 말고 OKF 문서에 없는 내용은 “문서에 없음”이라고 표시하라.

이렇게 하면 OKF가 단순 문서 저장소가 아니라
에이전트의 작업 기준이 됩니다.

---

OKF가 중요한 진짜 이유

OKF의 핵심은 “Markdown으로 문서를 쓰자”가 아닙니다.

이미 많은 팀이 Markdown을 씁니다.
이미 많은 팀이 Notion, Obsidian, GitHub Wiki, Confluence를 씁니다.

OKF가 던지는 질문은 조금 다릅니다.

앞으로 조직 지식은
사람만 읽는 문서여야 할까,
아니면 AI 에이전트도 읽고 갱신할 수 있는 실행 가능한 컨텍스트여야 할까?

AI 에이전트가 실제 업무에 들어오면, 문서는 더 이상 사람이 가끔 참고하는 자료가 아닙니다.

문서는 에이전트가 판단하는 기준이 되고,
코드를 수정하기 전 확인하는 규칙이 되고,
데이터를 분석할 때 따라야 하는 정의가 되고,
장애 대응 때 실행 순서를 정하는 runbook이 됩니다.

그렇다면 문서는 더 구조적이어야 합니다.
버전 관리되어야 합니다.
다른 도구로 옮길 수 있어야 합니다.
사람과 AI가 동시에 읽을 수 있어야 합니다.

OKF는 바로 그 방향을 제안합니다.

---

정리

OKF는 Google Cloud가 공개한 오픈 지식 포맷입니다.
핵심 구조는 단순합니다.

Markdown 파일 + YAML frontmatter + 디렉터리 구조 + Markdown 링크

이 단순한 조합으로 다음을 가능하게 하려는 시도입니다.

• 조직 지식을 파일로 관리한다.
• 사람이 읽고 AI도 읽는다.
• Git으로 버전 관리한다.
• 특정 벤더에 묶이지 않는다.
• 데이터, API, runbook, 지표 정의를 하나의 방식으로 표현한다.
• AI 에이전트가 필요한 맥락을 더 쉽게 찾게 한다.

[Inference] 앞으로 AI 에이전트를 제대로 쓰는 팀과 그렇지 못한 팀의 차이는 “어떤 모델을 쓰느냐”보다 “조직 지식을 얼마나 에이전트가 읽기 좋은 형태로 정리했느냐”에서 갈릴 가능성이 큽니다. 이 판단은 OKF 원문이 제시한 문제의식과 최근 에이전트 시스템 설계 흐름을 바탕으로 한 해석입니다.

OKF는 거창한 플랫폼이 아닙니다.
오히려 너무 단순해서 처음에는 별것 아닌 것처럼 보일 수 있습니다.

하지만 AI 시대의 지식 관리는 결국 이런 방향으로 갈 가능성이 높습니다.

문서를 쓰는 것이 아니라,
AI가 함께 일할 수 있는 지식 포맷을 설계하는 것.

OKF는 그 출발점으로 볼 수 있습니다.