AI 지식의 이식성: OKF v0.2로 출처와 검증 이력을 함께 옮기기

Open Knowledge Format v0.2는 지식 문서와 함께 출처, 생성·검증 이력, 수명 정보를 전달한다. 형식 호환과 업무상 신뢰를 구분하고, AKM과 RAG의 지식을 다른 도구로 옮길 때 보존할 기준을 살펴본다.

표지는 GPT Image 2로 생성한 개념 이미지이며, 실제 제품 화면이나 시스템 구조도가 아니다.

주간 활성 사용자를 계산해 달라는 요청은 짧다. 그러나 어느 이벤트를 활동으로 볼지, 내부 테스트 계정을 뺄지, 어떤 테이블을 연결할지는 팀의 업무 지식에 달려 있다. Google Cloud가 2026년 6월 12일 Open Knowledge Format을 소개하며 든 질문도 이런 종류였다. 에이전트가 답을 만들 때마다 카탈로그, 위키, 코드 주석에 흩어진 맥락을 다시 조립해야 한다는 문제다. 공식 발표는 이를 서로 다른 도구가 읽을 수 있는 지식 교환 형식의 문제로 다룬다.

문서를 Markdown으로 내려받으면 이동은 쉬워진다. 그렇다고 내용을 믿었던 이유까지 함께 옮겨지는 것은 아니다. 다른 팀이 파일을 받았을 때 작성 시점만 있고 원출처가 없거나, 사람이 확인했다는 표시만 있고 무엇을 언제 확인했는지 알 수 없다면 검토를 다시 해야 한다. AI가 만든 요약과 업무에 사용해도 된다고 승인한 지식을 구분하는 일도 받는 쪽의 몫으로 남는다.

Open Knowledge Format, 줄여서 OKF는 이 전달 경계를 살펴볼 만한 사례다. 최초 발표는 v0.1을 설명한다. 이 글은 2026년 9월 16일 확인한 v0.2 명세를 기준으로, 출처와 검증 이력이 어떻게 문서와 함께 이동하고 어디까지 믿을 수 있는지 읽는다. 포맷을 도입하면 RAG의 정확도가 오른다는 성능 주장은 하지 않는다.

지식을 전달하는 단위를 합의하기

OKF의 배포 단위인 지식 번들은 Markdown 파일의 디렉터리다. 개별 개념은 UTF-8 Markdown 파일 하나로 표현하고, 파일 앞의 YAML frontmatter에 구조화된 필드를 둔다. 개념의 ID는 번들 내부 경로에서 .md를 뺀 값이다. 특정 벡터 데이터베이스나 모델, 전용 SDK를 설치해야만 읽을 수 있는 구조가 아니다.

이때 개념은 추상적인 용어에 한정되지 않는다. 테이블의 의미, 지표의 정의, API 설명, 장애 대응 절차도 한 문서가 될 수 있다. 표준 Markdown 링크가 문서를 연결하고, 선택적인 index.md는 개별 문서를 열기 전에 내용의 범위를 보여 준다. log.md는 변경 이력을 기록한다. 링크의 관계 유형은 링크 자체의 고정된 스키마가 아니라 주변 문장으로 설명한다. 따라서 같은 파일을 읽을 수 있다는 사실이 모든 소비자가 동일한 의미의 그래프를 만든다는 보장은 아니다.

모든 개념 문서에 항상 필요한 필드는 type 하나다. 명세는 알지 못하는 유형이나 추가 필드를 이유로 문서를 거부하지 않도록 요구하며, 왕복 변환 때 알지 못하는 필드를 보존하도록 권고한다. 서로 다른 조직의 지식 체계를 하나의 분류표로 강제하기보다, 읽고 전달할 수 있는 공통 부분을 작게 유지하는 것이다. 다만 특정 유형에는 추가 조건이 있다. 뒤에서 다룰 Attested Computation은 runtime도 필요하다.

팀 내부에서 필수로 쓰는 승인 담당자나 검토 상태가 OKF의 최소 요구에 없다고 해서 지워도 되는 것은 아니다. 파일이 포맷에 맞는지와 우리 업무에 투입할 정보가 충분한지는 별도의 판단이다. 앞서 다룬 RAG 문서 수명 관리가 어떤 문서를 현재 근거로 쓸지에 초점을 맞췄다면, 여기서는 그 판단에 필요한 정보를 도구 사이에서 어떻게 잃지 않을지가 중심이다.

출처와 검증 표시는 같은 정보가 아니다

v0.2는 sources로 문서가 어떤 자료에서 나왔는지 기록한다. 각 항목의 resource는 구체적인 URL이나 번들 내부 경로일 수 있지만, 명세상 자료 집단의 범위를 설명하는 문구일 수도 있다. 따라서 sources가 있다는 이유만으로 원문에 바로 접근할 수 있다고 가정하면 안 된다. 받는 쪽에서는 실제로 열어 확인할 수 있는 근거와 범위 설명을 구분해야 한다.

개별 주장과 출처를 연결할 때는 sources[].id와 Markdown 각주 표지를 대응시킨다. 출처 목록의 몇 번째 항목인지를 참조하지 않고 고정된 ID를 쓰므로 목록 순서가 바뀌어도 연결을 유지할 수 있다. 이것은 인용을 운반하는 규칙이다. 링크된 자료가 그 주장을 실제로 뒷받침하는지는 여전히 확인해야 한다.

작성과 확인도 나뉜다. generated는 현재 내용의 생성 주체와 시점을, verified는 출처나 대상 자산에 비추어 확인한 주체와 시점을 기록한다. 확인 이력은 여러 항목으로 남길 수 있다. 명세는 내용 변경과 재확인이 독립적이라고 명시한다. 최근에 수정한 파일에 오래된 검증 기록이 남을 수 있고, 본문을 고치지 않고 사실만 다시 확인할 수도 있다. 그러므로 파일의 수정 시각을 검증 시각으로 대신 쓰면 두 사건이 섞인다.

명세가 정의한 신뢰 단계는 이 기록에서 도출한다. verified가 없으면 unverified, 사람 이외의 주체만 있으면 machine-confirmed, human: 접두사의 주체가 확인한 기록이 있으면 human-reviewed다. 이 단계는 접근 제어가 아니라 참고 신호다. human:이라는 문자열 자체가 사람의 신원을 인증하거나 승인 권한을 증명하는 것은 아니다. 수신 조직이 검증 주체를 어떻게 확인할지는 별도로 설계해야 한다.

수명 상태 역시 이와 구별된다. status는 draft, stable, deprecated를 구분하고, 생략하면 stable로 해석한다. 반면 검증 필드가 없으면 신뢰 단계는 unverified다. 두 규칙을 함께 읽으면 안정 상태라는 표시를 검증 완료로 오해하지 않을 수 있다. stale_after는 그 시각 이상에서 오래된 정보로 판단할 절대 시점을 담는다. 상태, 검증 이력, 현재성은 서로 대신할 수 없다.

원출처의 usage_count 같은 이용 정보도 참고 신호에 머문다. 명세는 예약 쿼리의 실행 횟수와 사람이 대시보드를 살펴본 횟수를 정밀한 공통 점수처럼 비교하지 말라고 설명한다. 많이 쓰이는 자료가 무엇인지 관찰하는 일과 그 자료가 참인지 판단하는 일은 다르다.

계산 결과에는 실행 근거가 필요하다

지표 문서에 승인된 계산식을 적어 두어도 에이전트가 실제로 그 식을 실행했는지는 별개다. OKF v0.2의 Attested Computation은 이 간격을 다룬다. 지표를 설명하는 문서와 계산을 정의하는 문서를 나누고, 여러 문서가 같은 계산을 링크할 수 있게 한다. OKF 자체가 계산을 실행하는 것은 아니다.

계산 문서의 runtime은 매개변수를 SQL 바인딩 값으로 볼지, 다른 실행 환경의 인자로 볼지 해석하는 맥락을 정한다. executor는 실행 방법과 반환할 영수증의 필드를 가리킨다. 여기서 영수증은 실행 ID, 실제 실행한 SQL, 결과처럼 실행 후 남기는 근거다. 명세는 이를 번들에 저장하는 정적 문서가 아니라 실행 시점의 산출물로 구분한다. attester는 그 근거를 검사해 판정을 반환하는 결정적 코드이며, LLM 판단을 뜻하지 않는다.

이 설계의 범위를 좁게 읽어야 한다. 정해진 계산을 실행했는지 확인하는 것은 원자료가 현실을 정확히 반영하는지, 지표 정의가 올바른지 확인하는 일과 다르다. 또한 외부 번들에 실행 코드가 연결되어 있다는 이유만으로 이를 실행할 권한이 생기지 않는다. 실행 환경의 격리, 코드 검토와 허용 범위는 수신 시스템이 책임질 부분이다.

별도 구현인 okfcli/okf의 공개 README는 v0.2의 출처·검증·수명 필드와 계산 계약을 파싱하고 검사하는 기능을 설명한다. 동시에 프로젝트 상태를 초기 개발로 밝힌다. 이는 포맷 생산자와 소비자 도구를 분리할 수 있는 구체적인 사례지만, 이 글에서 해당 CLI의 실행 성능이나 기업 도입 효과를 검증한 것은 아니다. 검증 도구가 보고한 형식 적합성을 지식의 사실성으로 확대해서도 안 된다.

AKM에서 내보낼 때 남겨야 할 판단 근거

AKM 같은 에이전트 지식 운영체계에 적용한다면, 내부의 분류와 승인 규칙을 유지하면서 외부 교환용 번들을 따로 만드는 방식이 적절하다. 다음은 이 글의 적용 제안이며, 공개되지 않은 구현이나 이미 입증된 운영 성과를 설명하는 것이 아니다.

처음부터 전체 저장소를 옮기기보다 다른 팀이 실제로 사용할 업무 지식 하나를 선택한다. 예를 들어 지표 정의와 그 근거 문서를 함께 전달할 수 있다. 받는 팀이 본문을 읽는 데서 그치지 않고 원출처를 찾을 수 있는지, 검증 주체와 시점을 구분하는지 확인한다. 내부에만 존재하는 링크나 비공개 자료는 공개 가능한 참조로 바꾸거나 내보내기 대상에서 제외해야 한다. 포맷의 이식성이 정보 공개 권한까지 해결해 주지는 않는다.

변환 과정에서는 내부의 신뢰 상태를 OKF 필드와 이름만 보고 일대일 대응하지 않는 편이 안전하다. 내부에서 정본으로 채택했다는 상태와 사람이 확인했다는 이력은 의미가 다르다. 실제 검증 사건이 있을 때 그 주체와 시점을 기록하고, 별도 승인 상태는 추가 필드와 설명으로 보존할 수 있다. 새 도구에서 이를 다시 읽었을 때 알지 못하는 필드가 사라지는지도 확인해야 한다.

가져오기에서는 파싱 가능한 문서와 현재 작업의 근거로 채택한 문서를 나눈다. 검증 이력이 없는 문서도 읽을 수 있어야 한다는 OKF의 소비 규칙과, 중요한 의사결정에는 검토한 근거만 쓰겠다는 조직의 정책은 함께 유지할 수 있다. 기본 stable 값을 곧바로 내부 승인 상태로 승격하지 않고, 실제 출처와 검증 기록을 검토하는 별도 단계를 두는 것이다.

이동 전후 비교도 파일 수만으로 끝내지 않는다. 주장에 붙은 출처 ID, 연결 대상, 검증 이력, 오래된 정보로 판단할 시점이 남았는지 확인한다. 새 도구가 검토를 보류했다면 왜 보류했는지 설명할 수 있어야 한다. 같은 답을 내는지뿐 아니라, 답을 내지 말아야 할 때 판단 근거가 유지되는지도 이식성의 시험에 포함할 수 있다.

OKF는 바뀌는 도구 사이에서 지식을 읽을 공통 구조를 제공한다. 이 구조는 신뢰를 판단할 재료를 전달한다. 받는 쪽이 그 재료를 다시 확인할 수 있어야 팀이 쌓은 지식이 다음 시스템에서도 업무 근거로 쓰일 수 있다.

참고 자료와 확인 범위

• Google Cloud, Introducing the Open Knowledge Format, 2026년 6월 12일. 최초 발표와 v0.1의 문제 설정.
• GoogleCloudPlatform, Open Knowledge Format v0.2 명세, 2026년 9월 16일 확인. 파일 구조는 §3–4, 출처·검증·수명은 §5, 계산 계약은 §10을 기준으로 읽었다. 인용 링크는 확인한 리비전에 고정했다.
• okfcli, okf README, 2026년 9월 16일 확인. 별도 소비자 구현의 기능 설명과 초기 개발 상태를 확인했으며, 실행 성능은 평가하지 않았다.