기업 AI Ontology: 비즈니스 의미 계층을 열린 프로토콜로 둬야 하는 이유

결론부터 말하면: Palantir는 AI가 기업에 들어가려면 거버넌스가 적용된 비즈니스 시맨틱 레이어가 필요하다는 것을 증명했다 — 하지만 그 레이어는 닫힌 플랫폼 안에 갇히는 것이 아니라, Linux처럼 당신이 소유하는 열린 프로토콜이어야 한다. 정의 레이어는 열고, 런타임으로 수익을 내라.

아마 당신도 직접 본 적이 있을 과정부터 시작하겠습니다.

한 기업이 “AI 어시스턴트” 프로젝트를 시작합니다. 첫째 주, 데모는 놀랍습니다. 고객 데이터를 내보내 모델에 넣었더니 “수도권에서 갱신 리스크가 높은 고객은 어디인가”에 정말로 답합니다. 경영진은 그 자리에서 파일럿 확대를 결정합니다.

3개월 차, 운영 데이터를 연결할 차례가 되자 보안팀이 들어와 세 가지 질문을 던집니다.

AI는 어떤 데이터를 볼 수 있는가? 영업사원 A가 “전사 실적 순위”를 물으면 다른 사람의 인센티브까지 말해 버리지 않는가?
AI가 작업을 실행한다면 — 할인 변경, 계약서 발송 — 누구의 권한으로 움직이는가? 문제가 생기면 누구 책임인가?
감사팀이 “이 할인은 누가 승인했나”를 조사할 때, AI가 관여한 부분의 기록은 어디에 있는가?

프로젝트팀은 답하지 못합니다. 태만해서가 아니라, 아키텍처 안에 이 질문들에 답할 수 있는 레이어 자체가 없기 때문입니다. 데이터는 십여 개 시스템에 흩어져 있고, 권한은 각 애플리케이션 코드 안에 박혀 있으며, “할인 승인” 규칙은 어느 베테랑 직원의 머릿속에만 존재합니다. AI가 마주한 것은 날것의 테이블과 날것의 API뿐이고, 아무리 똑똑해도 어디에도 적혀 있지 않은 회사의 규칙을 읽어낼 수는 없습니다.

9개월 차, 파일럿은 조용히 끝납니다. 모델은 능력에서 진 것이 아닙니다. 아무도 서명하려 하지 않았기 때문에 진 것입니다.

업계에는 여기서 빠져 있던 것의 이름이 있습니다. 온톨로지(Ontology, 비즈니스 본체) — 어떤 비즈니스 객체가 존재하고, 서로 어떤 관계이며, 누가 무엇을 할 수 있고, 실행된 일이 어디에 기록되는지를 구조화된 기계 가독 형태로 명시적으로 정의하는 시맨틱 레이어입니다.

Palantir가 맞았던 것

온톨로지를 연구 개념에서 상업적 사실로 바꾼 회사가 Palantir입니다. 왜 성공했는지 공정하게 살펴볼 가치가 있습니다 — 공정하게 볼수록 그다음 질문이 선명해지기 때문입니다.

Palantir Foundry의 핵심 동작은 두 가지입니다. 첫째, 기업 곳곳에 흩어진 데이터를 하나의 통합된 온톨로지 레이어로 통합합니다. 고객, 설비, 주문은 수십 개의 테이블이 아니라 타입과 관계와 속성을 가진 비즈니스 객체가 됩니다. 둘째, 모든 쓰기 작업을 거버넌스가 적용된 Actions로 수렴시킵니다. 모든 액션은 검증되고, 권한이 확인되고, 완전히 감사됩니다. 2023년 이후의 AIP는 이 아키텍처를 대규모 언어 모델에 직접 겨눴습니다. LLM은 데이터베이스를 건드리지 않는다. 온톨로지 레이어가 노출하는 거버넌스 적용 도구만 호출할 수 있다. 모델은 교체 가능하고, 경계는 움직이지 않습니다.

왜 비쌀까요? 해결하는 문제가 정말로 비싸기 때문입니다. 대기업이 20년간 쌓아온 레거시 시스템을 하나의 깨끗한 온톨로지로 정리하려면, Palantir의 상주 엔지니어(Forward Deployed Engineer)가 시스템을 하나씩 파헤치고 개념을 하나씩 맞춰야 합니다 — 말 그대로 노동집약적 엔지니어링입니다. 고객은 정부, 국방, 금융, 에너지입니다. “AI의 모든 단계가 권한 안에서, 모든 단계가 기록되는 것”이 필수 요건이고 예산도 그에 걸맞은 고객들입니다. 계약은 수백만 달러부터 시작하지만 고객은 계속 갱신합니다. CISO가 가장 중요하게 여기는 세 가지 질문 — 서두의 바로 그 세 가지 — 에 실제로 답하기 때문입니다.

즉 Palantir의 시가총액이 증명하는 것은 영업력이 아니라 하나의 아키텍처 판단입니다. AI가 기업에 들어가려면 거버넌스가 적용된 비즈니스 시맨틱 레이어가 먼저 존재해야 한다. 이 판단에는 더 이상 논증이 필요 없습니다.

다시 생각해야 할 것은 그다음 질문입니다. 이 레이어는 어떤 형태로 존재해야 하는가? 몇 가지가 변하고 있기 때문입니다.

소프트웨어는 점점 AI가 쓰는 것이 되고 있다

첫 번째 변화는 가장 눈에 보이는 것입니다. 애플리케이션 자체가 점점 AI에 의해 작성되고 있습니다.

“50명 팀을 위한 경비 승인 시스템을 맞춤 개발한다”는 과거에는 경제적으로 성립하지 않았습니다 — 개발비가 고통보다 컸기 때문입니다. 지금은 AI agent가 오후 안에 납품합니다. 맞춤형 업무 소프트웨어는 희소품에서 일용품이 되어 가고 있고, 총수요는 폭발적으로 늘어날 것입니다.

그 폭발이 어디서 일어나는지 주목하세요. 롱테일입니다. 어떤 엔터프라이즈 벤더의 잠재 고객 명단에도 결코 오르지 않을 팀들 — 구매 프로세스도, 도입 예산도, POC 심사 회의도 없는 팀들 — 에서 일어납니다. 그들은 그저 agent에게 “돌아가는 걸 만들어 줘”라고 말하고, 그날부터 쓰기 시작합니다.

상주 엔지니어와 수백만 달러 계약으로 돌아가는 모델은 구조적으로 이 시장에 닿을 수 없습니다. 비판이 아니라, 단지 서로 다른 두 시장이라는 이야기입니다. 하지만 이 새로운 시장의 모든 시스템이 서두의 그 세 가지 보안 질문에 똑같이 부딪히게 됩니다 — 다만 부딪힐 때 옆에 상주 엔지니어는 없습니다.

다음에 기술을 선택하는 것은 agent다

두 번째 변화는 더 조용하지만 더 깊습니다. 기술을 선택한다는 행위 자체가 인간에게서 AI로 옮겨가고 있습니다.

오늘 agent에게 “고객 관리 시스템을 만들어 줘”라고 하면, 높은 확률로 Next.js와 Postgres를 고릅니다. 왜일까요? 누가 agent의 머릿속에 광고를 한 것이 아닙니다. 이 기술들이 개방되어 있고, 문서가 완비되어 있고, 훈련 데이터 안에 대량으로 존재하기 때문입니다. agent는 수십만 개의 사용 사례를 봤고, 어디에 함정이 있는지 압니다.

이것은 이전에는 존재하지 않던 상황을 만듭니다. 개발자 대상 기술에서, 공개된 프로토콜 텍스트와 오픈소스 코드가 곧 유통 채널 그 자체가 된 것입니다. 프로토콜이 개방될수록 논의가 늘고, 배울 코드가 늘고, 차세대 모델의 이해가 깊어지고, agent는 그것을 기본값으로 선택하게 됩니다 — 스스로를 강화하는 루프입니다.

닫힌 플랫폼은 이 루프에 들어갈 수 없습니다. 온톨로지 표기법도, 액션 의미론도, 권한 모델도 문서 장벽과 계약 뒤에 있습니다. 모델은 학습할 수 없고, agent는 셀프서비스로 시작할 수도 없습니다. 구매 프로세스에는 선택될 수 있어도, agent에게는 선택될 수 없습니다. 점점 더 많은 소프트웨어가 agent에 의해 작성될 때, 이것은 더 이상 마케팅 문제가 아닙니다. 채널에서의 부재입니다.

잠깐 — 닫힌 플랫폼이 이긴 적도 있지 않나?

여기까지 오면 똑똑한 반론이 나와야 합니다. 개방이 항상 이기는 것은 아니다. 클라우드 시대의 승자는 AWS였고, 모바일의 승자는 iPhone이었다. 둘 다 닫혀 있다.

이 반론은 진지하게 받아들일 가치가 있습니다. 끝까지 받아내면 진짜 패턴이 보이기 때문입니다.

AWS가 어떻게 돈을 버는지 보세요. 호스팅하는 것은 Linux, Kubernetes, Postgres — 처음부터 끝까지 오픈 스탠더드입니다. iPhone은 닫혀 있지만, 그것이 보내는 모든 패킷은 TCP/IP와 HTTP 위를 달립니다. 더 거슬러 올라가면, 데이터베이스 벤더들은 피 튀기게 싸웠지만 SQL이라는 언어 자체는 공공재로 남았고, 컨테이너 오케스트레이션 전쟁은 모두가 같은 개방형 OCI 이미지 포맷 위에서 달리는 것으로 끝났습니다.

패턴은 놀라울 만큼 일관됩니다. 생태계 전체가 의존하는 “정의 레이어”는 결국 개방으로 간다 — 누구도 자신의 자산을 단일 벤더의 문법 위에 쌓으려 하지 않기 때문이다. 반면 “실행 레이어”는 닫힌 채 돈을 받을 수 있다 — 실행에는 지속적인 운영, 성능, 책임이 따르고, 그것은 실재하는 지속 비용이기 때문이다. AWS 자체가 가장 큰 증거입니다. 정의는 커뮤니티의 것, 실행이 비즈니스.

비즈니스 시맨틱 레이어는 전형적인 정의 레이어입니다. 당신의 객체 모델, 권한 규칙, 승인 플로우는 앞으로 당신의 애플리케이션이, agent가, 감사 시스템이 의존하게 됩니다. 의존하는 것이 많아질수록, 그것은 한 회사의 플랫폼 데이터베이스 안이 아니라 당신 자신의 저장소 안에 있는, 읽을 수 있고 버전 관리되고 가지고 떠날 수 있는 파일이어야 합니다.

기업들은 20년에 걸쳐 데이터를 닫힌 시스템들로부터 해방시켜 왔습니다. AI 시대에 데이터보다 더 근원적인 자산 — 비즈니스의 정의 그 자체 — 를 다시 가둬서는 안 됩니다.

이 “정의”는 실제로 어떤 모습인가

추상적인 이야기는 여기까지. ObjectStack 프로토콜의 영업 기회 객체 정의를 보겠습니다(실제 예제에서 발췌).

export const Opportunity = ObjectSchema.create({
  name: 'crm_opportunity',
  label: '영업 기회',
  fields: {
    name: Field.text({ label: '기회명', required: true }),
    account: Field.lookup('crm_account', { label: '고객사', required: true }),
    amount: Field.currency({ label: '금액', min: 0 }),
    probability: Field.percent({ label: '성공 확률', defaultValue: 50 }),
    expected_revenue: Field.formula({
      label: '기대 수익',
      expression: cel`amount * probability / 100`,
    }),
    discount_percent: Field.percent({ label: '할인율', max: 100 }),
  },
});

// 권한도 똑같이 선언적입니다: 영업은 읽고 쓸 수 있지만 삭제는 불가
export const SalesUser: Security.PermissionSet = {
  name: 'crm_sales_user',
  objects: {
    crm_opportunity: { allowRead: true, allowCreate: true, allowEdit: true, allowDelete: false },
  },
};

핵심은 문법이 아닙니다. 이 몇십 줄이 곧 시스템이라는 것입니다. 런타임(ObjectOS)이 이 정의를 읽어 데이터베이스 테이블, REST API, 관리 화면, 그리고 — AI agent가 직접 호출할 수 있는 거버넌스 적용 도구를 자동 생성합니다. 30%를 넘는 할인은 재무 승인이 필요하다? 그것은 이 객체에 붙는 플로우 정의이고, 똑같이 선언적이며, 똑같이 버전 관리됩니다.

하나의 메타데이터 정의가 API, 화면, AI 도구, 권한과 감사로 동시에 효력을 가진다

여기서 세 가지 결과가 직접 따라 나옵니다.

서두의 세 가지 보안 질문에 구조적인 답이 생깁니다. AI가 무엇을 볼 수 있는가 — 권한 세트에 적혀 있습니다. 어떤 권한으로 행동하는가 — 로그인한 사용자의 신분으로 행동하며 런타임이 강제합니다. 프롬프트로 부탁하는 것이 아닙니다. 감사 기록은 어디에 — 사람과 agent의 모든 읽기/쓰기가 같은 장부에 기록됩니다. 누가, 무엇을, 언제, 왜. 컴플라이언스가 보는 장부는 하나뿐입니다.
업무 변경이 코드 리뷰가 됩니다. AI가 시스템에 “갱신 알림”을 추가하고 싶다면? 제출되는 것은 메타데이터 diff입니다. 어떤 필드가 바뀌고 어떤 권한이 움직였는지 한눈에 보입니다. 정의가 버전 관리되므로 실수는 롤백할 수 있습니다.
시스템 전체가 agent 하나의 컨텍스트 윈도에 들어갑니다. 전형적인 엔터프라이즈 모듈은 수만 줄의 CRUD와 글루 코드에서 수백 줄의 선언으로 수렴합니다 — AI가 모든 의존 관계를 끝까지 읽고, 데이터·API·화면·권한을 가로지르는 안전한 리팩터링을 한 번의 변경으로 해낼 수 있는 크기입니다. 이것이 “공동 메인테이너로서의 AI”와 “자동완성으로서의 AI”의 분기점입니다.

프로토콜은 커뮤니티로, 런타임은 비즈니스로

이제 논증 전체가 닫힙니다.

온톨로지라는 판단은 옳습니다 — Palantir가 업계 전체를 위해 증명했습니다. 하지만 “정의는 개방, 실행은 유료” 패턴에 따르면, AI 시대에 이 레이어의 건강한 형태는 이렇습니다. 비즈니스 시맨틱 프로토콜은 Linux처럼 오픈 생태계에 속하고, 거버넌스가 적용된 런타임이 그것을 당신 자신의 환경에서 실행한다.

이것이 바로 ObjectStack과 ObjectOS의 분업입니다.

ObjectStack은 업무 애플리케이션을 기술하는 오픈 프로토콜(Apache 2.0)입니다. 객체, 관계, 권한, 플로우, API, UI, AI 도구를 한 번만 정의합니다. 그것은 당신의 저장소 안에 있고, diff할 수 있고, 이전할 수 있고, 어떤 agent든 읽을 수 있습니다 — 그래서 공개 인터넷에 존재하고, 미래 모든 모델의 훈련 데이터 안에 존재합니다.
ObjectOS는 그 정의들의 런타임입니다. 당신의 서버에서, 당신의 데이터베이스에 대해 모든 것을 실행하고, 실행 시점에 권한을 강제하고 감사 로그를 기록합니다. 거버넌스는 프롬프트가 아니라 실행 엔진에 쓰여 있습니다.

한쪽에는 어떤 팀이든, 어떤 agent든 오늘부터 감당할 수 있고, 이해할 수 있고, 가지고 떠날 수 있는 프로토콜. 다른 한쪽에는 기업이 진짜로 돈을 내는 것들 — 호스팅, 컴플라이언스, 멀티 환경 배포, 운영을 책임질 누군가. 정의는 당신의 것입니다. 그것을 돌리는 수고가 우리의 비즈니스입니다.

맺으며

9개월 만에 죽은 그 AI 파일럿은 모델 능력에 진 것이 아닙니다. 보안팀이 서명할 수 있는 시맨틱 레이어가 없었다는 것에 진 것입니다. 업계에서 가장 비싼 회사가 이 레이어의 가치를 10년에 걸쳐 증명했습니다. 다음 할 일은 그것이 더 이상 대기업만의 사치품이 아니게 만드는 것입니다.

이 모든 것이 진짜인지 확인하고 싶다면:

npm i -g @objectstack/cli && os start

5분 뒤, 첫 비즈니스 객체를 정의해 보세요. 그것이 데이터베이스 테이블이 되고, API가 되고, 관리 화면이 되고, AI가 안전하게 호출할 수 있는 도구가 되는 것을 보게 됩니다 — 모든 호출이 권한을 지니고, 장부에 기록되면서.