Skill/프로그래밍(Dev)

Google OKF란 — 게임 개발 지식을 사람과 AI가 함께 읽는 방법

fmapark / 2026. 8. 11. 12:37

1. 들어가며

같은 게임을 만들고 있지만, 파트마다 보고 있는 정보는 조금씩 다를 수 있어요.

“그래서 지금 어떤 문서가 기준이에요?”
게임을 만들다 보면 한 번쯤 듣는 말이죠.
기획자는 문서와 밸런스 시트를 손봐요. 프로그래머는 바뀐 내용을 코드에 반영하고, 아트 파트는 Figma를 확인하죠. 변경 이유는 Discord 회의록에만 남기도 하고요.
문서가 없어서 생기는 문제는 아니에요. 오히려 문서는 많은데 무엇이 현재 기준인지 알기 어렵다는 것이 문제죠.
Google Cloud가 공개한 OKF(Open Knowledge Format)는 조직의 지식을 사람과 AI가 함께 읽을 수 있게 표현하는 규격이에요.
이 글에서는 OKF가 무엇인지, 게임 개발에서 어디에 쓸 수 있는지, 그리고 어떤 한계가 있는지 차례로 살펴볼게요.

2. 그래서 OKF가 뭔가요?

OKF는 사람이 읽는 지식에 문서를 판단할 정보와 다른 지식과의 관계를 더하는 개방형 규격이에요.
정식 명칭은 Open Knowledge Format입니다. Google Cloud가 2026년 6월 처음 공개했고, 같은 해 7월에는 출처와 검증 정보를 보강한 v0.2를 발표했죠.
OKF 문서에는 세 가지 역할이 함께 들어가요.

역할 OKF에서 표현하는 방식
지식의 내용 Markdown 본문에 규칙과 맥락을 작성해요
판단 정보 YAML frontmatter에 종류·출처·상태를 표시해요
지식의 관계 Markdown 링크로 관련 문서를 연결해요

게임의 플레이어 이동 속도를 정리한다면 이런 모습이에요.

---
type: Game Design Concept
title: 플레이어 이동 속도
status: stable
sources:
  - resource: balance-sheet.md
---

# 플레이어 이동 속도

플레이어의 기본 이동 속도와 변경 이유를 설명합니다.

이 규칙은 [캐릭터 애니메이션](character-animation.md)과
[QA 테스트 기준](movement-test.md)에도 영향을 줍니다.

이 문서에서는 세 요소가 역할을 나눠 가져요.

  1. Markdown 본문에는 이동 속도의 기준과 변경 이유를 적어요.
  2. YAML frontmatter에는 문서의 종류와 현재 상태, 출처를 표시해요.
  3. Markdown 링크로 함께 확인해야 할 애니메이션과 QA 문서를 연결해요.

사람은 본문을 읽으며 규칙과 맥락을 이해할 수 있어요. AI는 메타데이터로 어떤 문서를 먼저 볼지 판단하고, 링크를 따라 관련 지식까지 확인할 수 있고요.
여러 OKF 문서를 하나의 폴더에 모은 것을 OKF bundle(관련 지식을 묶은 디렉터리)이라고 불러요. 각 문서는 하나의 개념을 설명하고, 링크를 따라 다른 개념과 이어집니다. 그렇게 프로젝트의 지식 구조가 만들어지는 거예요.

 

OKF 문서는 내용만 담지 않아요. 문서의 상태와 출처를 표시하고, 함께 확인할 다른 지식까지 연결해요.

 

3. 왜 이런 형식이 필요한가요?

캐릭터의 최대 체력이 처음에는 100이었다고 해볼게요.
밸런스 테스트를 거친 뒤 기획자는 체력을 120으로 바꿨어요. 프로그래머도 코드에 반영했죠. 그런데 UI 시안과 QA 체크리스트에는 여전히 100이 남아 있어요.
변경 이유를 알려면 지난 회의록까지 찾아봐야 하고요.
이때 필요한 정보는 세 가지예요.

  • 기준: 현재 사용해야 하는 값은 무엇인가
  • 출처: 그 값은 어느 문서와 결정에서 나왔는가
  • 관계: 변경되면 함께 확인해야 하는 문서는 무엇인가

게임 개발에서는 하나의 지식을 여러 파트가 함께 써요.

파트 같은 지식을 사용하는 방식
기획 규칙과 수치를 정의해요
프로그래밍 규칙을 코드로 구현해요
아트·UI 규칙을 화면에 표현해요
QA 정의한 규칙을 기준으로 테스트해요
PM 변경 사항이 관련 파트에 전달됐는지 확인해요

문서 하나를 고쳤다고 관련 자료까지 동시에 바뀌지는 않아요. 시간이 지나면 같은 개념이 문서마다 다르게 적히기 시작하죠.
AI도 어느 문서가 최신인지 저절로 알지는 못해요. 기획 초안과 확정안을 함께 건네면 둘을 같은 무게로 참고할 수 있거든요.
OKF는 사람과 AI가 무엇을 기준으로 판단해야 하는지 문서 안에 표시하는 방법을 제안해요.

4. OKF는 무엇을 표시하나요?

OKF에서 꼭 필요한 메타데이터는 type 하나예요. 나머지는 팀이 필요할 때 더하면 되고요.

2026년 7월 공개된 OKF v0.2에는 출처와 검증 상태를 표현하는 항목도 추가됐어요.

항목 의미 게임 개발에서의 활용
type 문서의 종류 기획 개념, 기술 결정, 아트 가이드 등을 구분해요
sources 정보의 출처 기획서, 밸런스 시트, 회의록을 연결해요
verified 검증한 주체 담당자가 현재 기준과 일치하는지 확인해요
status 현재 상태 논의 중, 사용 중, 폐기된 정보를 구분해요
Markdown 링크 다른 지식과의 관계 기획, 코드, UI, QA 문서를 연결해요

① 아이디어와 확정안을 구분해요

회의에서 나온 아이디어와 실제 게임에 반영하기로 한 규칙은 달라요.

status를 표시하면 다음 상태를 구분할 수 있어요.

  • 아직 논의 중인 아이디어
  • 현재 사용하는 기준
  • 더 이상 사용하지 않는 내용
  • 새로운 규칙으로 대체된 내용

AI가 관련 문서를 검색하더라도 폐기된 아이디어를 현재 기획으로 오해할 가능성을 줄일 수 있어요.

② 정보의 출처를 남겨요

캐릭터 공격력이 30이라는 값만 남아 있다면, 시간이 지난 뒤에는 왜 30인지 알기 어려워요.

sources에는 다음과 같은 원본을 연결할 수 있어요.

  • 현재 사용하는 밸런스 시트
  • 플레이 테스트 결과
  • 담당 파트가 승인한 기획 문서
  • 기술 검증 결과
  • 해당 결정을 내린 회의 기록

내용이 부딪혔을 때 무엇을 다시 확인해야 할지도 분명해져요.

③ 관련된 지식을 연결해요

플레이어의 이동 속도가 바뀌면 이동 코드만 고치면 끝일까요?
다음 요소도 함께 바뀔 수 있어요.

  • 캐릭터 애니메이션
  • 카메라 추적 속도
  • 맵의 크기
  • 적의 이동 속도
  • 이동 튜토리얼
  • QA 테스트 기준

OKF는 별도의 관계 데이터베이스를 두는 대신 Markdown 링크로 관련 문서를 이어 줘요.

하나의 게임 규칙이 바뀌면 여러 파트의 문서와 작업에도 영향을 줄 수 있어요.

5. 게임 개발에서는 어디에 쓸 수 있을까요?

OKF는 데이터 조직의 활용 사례와 함께 공개됐지만, 데이터 문서에만 쓰는 규격은 아니에요.
게임 개발에서는 여러 파트가 반복해서 확인하는 지식을 정리할 때 살펴볼 수 있어요.

분야 정리할 수 있는 지식
게임 기획 전투 규칙, 밸런스 기준, 공통 용어
프로그래밍 시스템 구조, 기술적 결정, 구현 제약
아트·UI 에셋 규격, 파일명 규칙, UI 상태
QA 테스트 기준, 재현 조건, 알려진 제약
프로젝트 관리 결정 사항, 변경 이유, 관련 담당자

모든 문서를 OKF로 바꿀 필요는 없어요. 다음 조건에 해당하는 지식부터 살펴보면 됩니다.

  1. 여러 파트가 반복해서 확인해요.
  2. 잘못 전달됐을 때 수정 비용이 커요.
  3. 변경 이유를 나중에도 확인해야 해요.
  4. 신규 팀원이나 AI가 자주 참고해요.

게임의 핵심 용어, 확정된 규칙, 기술적 결정처럼 시간이 지나도 다시 확인할 가치가 있는 지식부터 시작하면 좋아요.

6. 기존 도구를 대체하나요?

OKF는 새로운 협업 플랫폼이 아니에요. Notion이나 Google Drive, Figma를 없애고 OKF만 사용하자는 제안도 아니고요.

도구·기술 역할
Notion·Google Drive 문서를 작성하고 공유해요
Git 파일의 변경 이력과 리뷰를 관리해요
RAG 필요한 자료를 검색해 AI의 답변에 제공해요
MCP AI가 외부 도구와 상호작용하도록 연결해요
OKF 지식의 종류와 출처, 상태, 관계를 표현해요

서로 경쟁하는 기술이라기보다, 맡은 역할이 다른 거예요.
RAG가 문서를 잘 찾더라도 원본에 최신 상태가 표시되지 않았다면 오래된 내용을 가져올 수 있어요. OKF는 검색을 대신하지 않아요. 검색할 지식을 더 잘 설명된 상태로 만드는 형식에 가깝죠.
Google Cloud가 공개했다고 Google 검색 노출을 보장하는 규격도 아니에요. 검색 순위를 위한 형식이 아니라, 조직의 지식을 사람과 AI가 함께 사용하기 위한 규격이에요.

7. OKF만으로 해결되지는 않아요

OKF 파일을 만든다고 기획서와 코드가 자동으로 같아지지는 않아요.
OKF를 사용하더라도 팀이 직접 챙겨야 할 일이 있어요.

  1. 어떤 문서를 기준으로 삼을지 정해요.
  2. 정보가 바뀌면 상태와 출처를 갱신해요.
  3. 관련된 문서를 함께 연결해요.
  4. AI가 작성한 내용은 담당자가 확인해요.
  5. 더 이상 사용하지 않는 정보는 상태를 변경해요.

제대로 관리하지 않으면 Markdown 파일만 하나 더 늘어날 수도 있죠.
OKF는 2026년에 공개된 초기 규격이기도 해요. 게임 개발 조직에서 널리 쓰이고 검증된 표준이라고 말하기에는 아직 일러요.
그래도 OKF가 던지는 질문은 생각해 볼 만해요.

  • 지금 어떤 정보가 기준인가요?
  • 이 내용은 어디에서 나왔나요?
  • 누가 확인한 정보인가요?
  • 관련된 다른 문서는 무엇인가요?

게임을 만들면서 “어느 문서가 최신이지?”라는 말을 자주 한다면, 이런 정보를 문서에 함께 남기는 방법부터 살펴봐도 좋겠어요.

8. 마무리

OKF의 핵심은 거창한 지식 시스템을 새로 만드는 데 있지 않아요. 사람과 AI가 같은 정보를 읽고, 무엇을 믿어야 하는지 판단할 수 있게 만드는 것이죠.
결국 문서에 더하는 정보는 세 가지예요.

  • 이 문서가 무엇인지
  • 어디에서 나온 정보인지
  • 현재도 사용하고 있는지

처음부터 모든 문서를 옮길 필요는 없어요. 여러 파트가 자주 확인하는 게임 규칙이나 공통 용어처럼 작은 범위부터 살펴보면 충분해요.
여러분의 팀은 기획과 코드, 아트 문서가 서로 달라졌을 때 어떤 방식으로 기준을 관리하나요? 경험이나 궁금한 점이 있다면 댓글로 남겨주세요.

OKF는 흩어진 문서를 하나로 합치기보다, 각 지식의 기준과 관계를 드러내는 방식이에요.

참고 자료

  • Google Cloud, How the Open Knowledge Format can improve data sharing
  • Google Cloud, Open Knowledge Format v0.2 tackles agentic trust
  • GoogleCloudPlatform, OKF 공식 저장소