2주 전 저는 온톨로지 (ontology) 계층이 반복되는 에이전트의 실패를 해결하는 지점이며, 이를 해결하는 아티팩트 (artifact)는 벤더의 콘솔이 아닌 여러분의 저장소 (repository)에 존재해야 한다고 주장했습니다 (Stevens, 2026a). 저는 그 글을 다음과 같은 요구로 마무리했습니다. 엔티티 (entities), 관계 (relationships), 그리고 허용된 작업 (permitted actions)을 위해 중립적이고, 버전 관리(versioned)가 가능하며, 검토 가능한 (reviewable) 형식을 고수하라는 것입니다. 당연히 뒤따르는 질문은 이것입니다. 정확히 어떤 언어로 된 중립적 형식인가?

그래서 저는 그 이후 저녁 시간을 할애하여 이를 구축했습니다.

Arkhe v0.2.0이 오늘 출시되었습니다: AI 시스템을 위한 작고 오픈 소스인 온톨로지 (ontology) 언어입니다. Arkhe는 저의 개인적인 프로젝트로, 개인 시간에 작성되었으며, Apache-2.0 라이선스를 따르고, 영구적으로 무료이며, CLA (Contributor License Agreement)가 없습니다. 이는 어떤 의미에서도 Sakura Sky의 제품이 아닙니다. 제가 여기서 이 글을 쓰는 이유는 논쟁이 여기서 시작되었기 때문입니다.

하나의 파일, 세 가지 레지스터 (registers)

Arkhe 모듈은 git에 있는 YAML 파일입니다. 이 파일은 이전 포스트에서 언급한 세 가지 레지스터를 선언합니다: 무엇이 존재하는지, 어떻게 연결되는지, 그리고 누가 어떤 흔적 (trace)을 남기며 무엇을 할 수 있는지에 대한 것입니다.

entities:
  FinancialModel:
    keys: [model_id]
...

모델 리스크 (model risk) 책임자는 해당 파일을 읽고 11행에 대해 이의를 제기할 수 있습니다. 파이프라인 (pipeline)이 아닌 비즈니스 개념을 소유한 사람이 검토할 수 있다는 속성이 설계의 대부분을 주도합니다. 가드 (Guards)는 Google의 CEL (Common Expression Language)로 작성되었습니다. CEL은 크기가 작고, 부작용 (side-effect)이 없으며, 이미 클라우드 자산의 절반에서 정책 표현 언어로 사용되고 있기 때문입니다 (Google, n.d.). 세상은 폐쇄적입니다: 파일에 없는 엔티티와 작업은 시스템에도 존재하지 않으며, 어떤 추론 엔진 (inference engine)도 새로운 것을 만들어내지 않습니다. 온톨로지 (ontology)라는 단어 뒤에 숨은 철학적 전통은 인정하되 단호하게 제쳐둡니다. 개념화 (conceptualisation)에 대한 명시적 사양이라는 Gruber의 정의가 유일한 목표입니다 (Gruber, 1993).

또 다른 핵심적인 결정 사항은 명세(spec)가 계약(contract)이며, 결코 런타임(runtime)이 아니라는 점입니다. Arkhe는 사용자의 모듈을 중립적인 중간 형태(intermediate form)로 컴파일하며, 각 액션(action)당 하나의 도구 계약(tool contract)을 생성하고, 에미터(emitter)는 그로부터 시스템이 소비할 결과물을 생성합니다. Arkhe의 그 어떤 것도 사용자의 서빙 경로(serving path)에서 실행되지 않습니다. 만약 이 프로젝트가 내일 당장 사라지더라도, Arkhe가 생성한 모든 것은 계속 작동할 것이며, YAML 파일은 여전히 다른 도구로 컴파일할 수 있는 사용자의 소유로 남을 것입니다.

컴파일을 통해 얻는 이점

컴파일러 파이프라인은 의도적으로 단순합니다. 모듈을 검증합니다 (발행된 JSON 스키마로부터의 구조적 규칙, 그 다음은 키 참조(key references), 링크 엔드포인트(link endpoints), 가드 이름(guard names), 이펙트 타입(effect types)과 같은 의미론적 규칙). 계약을 생성합니다. 그리고 에밋(Emit)합니다.

현재 두 가지 에미터가 존재합니다:

1. 첫 번째는 가드된 함수(guarded functions)로 구성된 네이티브 Python 라이브러리를 생성합니다. 14개월 전에 검증된 모델에 대해 grant_production_use를 호출하면, 예외(exception)가 발생하거나 최악의 경우 성공하는 대신, 실패한 조항인 months_since(target.last_validated) <= 12를 명시하며 거부합니다. 해당 함수들에 연결된 에이전트(agent)는 프롬프트 엔지니어링(prompt engineering) 없이도 이러한 거부 의미론(refusal semantics)을 상속받습니다.
2. v0.2에서 새로 추가된 두 번째 에미터는 오픈 지식 형식(Open Knowledge Format, OKF) 번들을 생성합니다. 이는 LLM이 소비할 수 있도록 모듈의 어노테이션(annotation)으로부터 생성된 엔티티(entity), 링크(link), 액션(action)당 하나의 마크다운(markdown) 개념 문서입니다.

저는 이 쌍을 상호 보완적인 두 부분으로 생각합니다. 계약은 에이전트가 무엇을 할 수 있는지 선언하고, OKF 번들은 에이전트가 무엇을 알아야 하는지를 선언합니다. 둘 다 동일한 파일로부터 재생성되므로 서로 어긋날 수 없습니다.

v0.2에서는 유의어(synonyms)를 일급 어노테이션(first-class annotations)으로 추가하여, 정식 명칭(canonical names)은 안정적으로 유지하면서도 그라운딩(grounding)이 사람들이 실제로 사용하는 어휘(

하지만 제가 가장 기쁘게 생각하는 출시는 사용자들이 결코 직접 호출하지 않을 것입니다. 바로 두 번째 구현체입니다. 이제 검증기(validator)의 Rust 포팅 버전은 Python 참조 구현과 동일한 고정된 골든 피스처(golden fixtures)를 통과합니다. 포팅 과정에서 명세(spec)가 실제로 결정하지 않았던 세 가지 동작이 드러났는데, 이들은 모두 Python의 YAML 라이브러리로부터 조용히 상속된 것이었습니다. 여기에는 no를 불리언(boolean)으로 파싱하는 유서 깊은 '노르웨이 문제(Norway problem)'도 포함됩니다. 이 세 가지 모두 현재 공개된 ADR(Architecture Decision Record)에 엄격하게 고정되었습니다. 이 과정을 통해 얻은 저의 결론은 별도의 포스트를 작성할 가치가 있습니다. 즉, 단 하나의 구현체만을 가진 언어는 우연히 명세를 갖게 될 뿐이라는 것입니다.

대상 사용자

저는 이 작업을 하며 계속 마주치는 세 가지 대상에 대해 페르소나 가이드를 작성했으며, 이들은 각각의 레지스터(registers)에 대응합니다:

• GRC(Governance, Risk, and Compliance) 전문가들은 통제(controls)를 구조로 얻습니다. authority: head_of_model_risk 및 audit: mandatory는 추적 가능한 강제 속성(enforced properties)이며, 실패한 조항을 인용하며 거부하는 행위는 프롬프트 지시어(prompt instruction)가 결코 할 수 없는 방식으로 감사 증거(audit evidence)가 됩니다. 검토 가능한 YAML은 통제 라이브러리(control library)가 되며, git 히스토리는 감사인이 계속해서 요구하는 변경 기록(change record)이 됩니다.

• 데이터 엔지니어들은 시맨틱 레이어(semantic layer)를 코드로 얻습니다. 이는 설명 대상인 스키마(schema)와 동일한 저장소(repository)에 위치하며, 다른 산출물(artifact)과 마찬가지로 CI에서 오류 코드 및 줄 번호와 함께 검증됩니다. 만약 데이터 웨어하우스(warehouse)가 변하는 동안 위키(wiki)에서 비즈니스 정의를 유지 관리해 본 경험이 있다면, arkhe validate가 파이프라인을 실패시키는 매력은 즉각적으로 다가올 것입니다.

• 아키텍트들은 프로토콜 독립성을 얻습니다. 도구-계약 IR(Intermediate Representation)이 중심에 위치합니다. MCP, OpenAI 함수 스키마(function schemas), Google ADK 도구 정의는 모두 이 IR로부터 얇게 방출(emitters)되도록 설계되었습니다. 이는 지난 2년간의 프로토콜 급변(churn)이 더 이상 재작성(rewrite)의 트리거가 되지 않음을 의미합니다. Arkhe를 선택한다는 것은 파일 형식에는 전념하되, 그 외의 다른 것에는 의도적으로 전념하지 않음을 의미합니다.

제가 가장 구축되기를 바라고, 플래그십 모듈로서 구축하고자 의도하는 유스케이스 (use case)는 AI 자산 (AI estate) 자체에 대한 온톨로지 (ontology)입니다. 즉, 모델 (models), 에이전트 (agents), 도구 (tools), 데이터셋 (datasets), 평가 (evals), 가드레일 (guardrails), 그리고 인시던트 (incidents)를 포함하며, 평가 결과에 따라 '운영 환경으로 승격 (promote-to-production)'과 같은 액션 (actions)이 보호되는 구조입니다. 현재 업계는 가장 중대한 시스템들을 고객 테이블 (customer table)에 적용하는 것보다도 구조적 엄밀함 (structural rigour)이 결여된 방식으로 관리하고 있습니다. 이는 동일한 처방을 통해 해결할 가치가 있어 보입니다.

Arkhe가 거부하는 것들

Arkhe는 언어이자 컴파일러 (compiler)입니다. 워크스페이스 (workspace), 운영 데이터베이스 (operational database), 쿼리 엔진 (query engine), 에이전트 런타임 (agent runtime)은 존재하지 않습니다. Palantir는 10년 전 플랫폼 내에 세 가지 레지스터 (registers)를 제품화했으며 (Palantir Technologies, 2026), 여러 오픈 프로젝트들이 현재 런타임 (runtimes)을 결합하여 동일한 영역을 공략하고 있습니다. README의 선행 기술 (prior-art) 섹션은 이 아이디어가 무에서 유로 창조된 것처럼 가장하기보다 이들을 명시하고 있습니다. Arkhe가 거는 베팅은 그 어느 것보다 좁습니다. 즉, 지속 가능한 아티팩트 (artifact)는 검토 가능한 파일과 그 컴파일된 계약 (compiled contracts)이며, 상태를 가진 모든 것 (everything stateful)은 여러분이 이미 실행 중인 시스템의 영역이라는 것입니다. 만약 이 베팅이 틀렸더라도, 시도에 따른 비용은 그저 어떤 도구로도 여전히 파싱 (parse)할 수 있는 YAML 파일 하나뿐입니다.

v0.2.0은 PyPI (pip install arkhelang), crates.io (cargo install arkhe), 그리고 GitHub에 공개되어 있으며, 스펙 스케치 (spec sketch), 9개의 ADR (Architectural Decision Records), 골든 픽스처 (golden fixtures), 그리고 페르소나 가이드 (persona guides)를 포함하고 있습니다. 이는 의도적으로 작게 설계되었습니다. 이전 포스트를 통해 중립적인 형태가 존재해야 한다는 점에 설득되었다면, 이번 포스트는 구체적인 후보를 두고 논쟁해 보라는 초대장입니다. 이상적으로는 실패하는 픽스처 (failing fixture)를 첨부한 이슈 (issue) 형태라면 더욱 좋습니다.

공시: Arkhe는 저자의 개인 오픈 소스 프로젝트이며 Sakura Sky와는 무관합니다. Sakura Sky는 이에 대해 어떠한 상업적 이해관계도 없습니다. 저자는 또한 거버넌스 기반 에이전트 런타임 (governed agent runtimes)을 위한 오픈 프레임워크인 GATE를 유지 관리하고 있으며, Arkhe는 다른 어떤 런타임과도 대등한 조건에서 상호 운용 (interoperate)하는 것을 목표로 합니다.

참고 문헌

참고 문헌

Google (n.d.) Common Expression Language 사양. 이용 가능 주소: https://github.com/google/cel-spec (접근일: 2026년 7월 23일).

Gruber, T.R. (1993) '이식 가능한 온톨로지 사양을 위한 번역 접근법', Knowledge Acquisition, 5(2), pp. 199-220.

Palantir Technologies (2026) 온톨로지 개요, Foundry 문서. 이용 가능 주소: https://www.palantir.com/docs/foundry/ontology/overview (접근일: 2026년 7월 23일).

Stevens, A. (2026a) 당신의 온톨로지가 자산입니다. 임대하지 마세요. Sakura Sky, 10 July. 이용 가능 주소: https://www.sakurasky.com/blog/own-your-ontology/ (접근일: 2026년 7월 23일).

Stevens, A. (2026b) Arkhe: AI 시스템을 위한 온톨로지 언어. 이용 가능 주소: https://github.com/arkhelang/arkhelang (접근일: 2026년 7월 23일).