열린 기업 온톨로지: 비즈니스 의미 계층은 누가 소유해야 하는가

결론부터 말하면: 당신의 앱과 agent, 감사관, 그리고 이제는 여러 벤더까지 모두가 의존하는 ‘비즈니스 정의’ 계층은 어느 한 플랫폼에 속해서는 안 된다. 그것은 당신 자신의 저장소에 직접 쥐고 있는 중립적인 계층이어야 한다.

먼저 한 회사가 이 문제 때문에 고객 하나를 어떻게 잃었는지부터 이야기하자. 세부 사항은 익명화했지만, 각 단계는 대부분 당신도 본 적 있는 장면일 것이다.

위안펑(远峰)은 연 매출 수십억, 고객 수천 곳을 둔 산업 설비 제조사다. 2024년, 이 회사는 데이터 기반을 마이크로소프트에 걸었고 Fabric 안에 깔끔한 온톨로지를 구축했다. ‘고객’이 무엇인지, 한 고객이 어떤 ‘설비’와 연결되는지, ‘설비’에 어떤 ‘작업 지시’가 걸려 있는지를 또렷하게 정의했다. 그해 위안펑은 벤더 컨퍼런스에서 거듭 거명되던 모범 사례였다.

2026년, 세 가지 일이 거의 동시에 위안펑에 닥쳤다.

• 데이터 사이언스 팀이 일부 갱신 예측을 Gemini로 돌리고 싶어 했다. 그 구체적인 시나리오에서는 실제로 더 정확했기 때문이다.
• 컴플라이언스 부서는 EU 고객 데이터는 EU 안에 남아야 하며 더 이상 미국 클라우드에 들어가서는 안 된다는 통지를 받았다.
• 인수가 완료되면서 Salesforce 위에서 돌아가는, 고객 수천 곳을 거느린 영업 조직 한 세트가 통째로 들어왔다.

그래서 위안펑에는 ‘고객’이 셋 생겼다. Fabric 안에 하나, Salesforce 안에 하나, 컴플라이언스로 격리된 EU 환경 안에 또 하나.

이야기의 전환점은 ‘H 그룹’이라는 핵심 대형 고객에게서 일어났다. 어느 날 영업 총괄이 agent에게 물었다. “H 그룹의 내년 갱신 리스크는 얼마나 높지?” agent는 답했다. “낮음.” 그것은 Fabric 온톨로지에 연결되어 있었고, 거기서 H 그룹은 최근 주문이 건전했으며 숫자가 보기 좋았다.

하지만 agent가 보지 못한 것이 있었다. Salesforce 쪽 기록(인수로 들어온 것)에서 H 그룹은 반년 사이 두 번이나 불만을 경영진 차원까지 에스컬레이션했고, EU 격리 환경에는 90일을 끈 회수 분쟁 한 건이 걸려 있었다. 세 데이터는 서로를 인정하지 않는 세 개의 ‘고객’에 각각 속해 있었고, 어떤 계층도 이들이 사실은 같은 H 그룹이라는 것을 알지 못했다.

한 분기 뒤, H 그룹은 이탈했고 연 손실은 수백만에 달했다. 사후 분석 결론은 침묵이 흐를 만큼 따가웠다. agent는 기술적으로 틀리지 않았다. 그것이 본 그 한 벌의 데이터는 실제로 낮은 리스크를 보여주고 있었다. 잘못된 것은 모델이 아니라, 그 발밑에 깔린 ‘고객’의 정의가 세 조각으로 잘려 있었다는 점이다.

이것은 위안펑의 실수가 아니다. ‘비즈니스의 정의’를 플랫폼에 보관시킨 데 따른 필연적 결과다. 그리고 각 플랫폼은 자기 몫의 정의만 보관한다.

특수한 사례가 아니다: 모두가 이 계층을 노리고 있다

위안펑의 처지가 보편적인 이유는, 업계 전체가 함께 같은 계층으로 밀려들고 있기 때문이다.

불과 얼마 전까지만 해도 ‘비즈니스 시맨틱 레이어 / 온톨로지’는 일부 데이터 플랫폼의 전문 용어처럼 들렸다. 이제는 주요 클라우드, 데이터 플랫폼, AI 플랫폼이 모두 같은 방향을 향하고 있다. agent가 테이블과 API만으로는 기업을 이해하지 못한다는 사실이 분명해졌기 때문이다.

왜 하필 지금인가? agent가 이 구멍을 찔러 터뜨렸기 때문이다. 지난 10년의 데이터 파이프라인은 ‘데이터가 어디로 흘러가는가’만 신경 썼지 ‘이 데이터가 무슨 의미인가’에는 별 관심이 없었다. 어차피 최후의 안전망은 사람이었다. agent에게는 그 안전망 역할을 해줄 사람이 없다. 수십 장의 테이블, 기준이 제각각인 ‘고객’ 필드를 마주하면, agent는 틀리게 답하거나 아예 답을 못 한다. 많은 agent 파일럿이 프로덕션에 진입하지 못하는 이유 중 하나가 바로 이 계층의 부재다.

그래서 세 거대 기업의 판단은 옳고, 게다가 고도로 일치한다. AI가 기업에 안정적으로 들어가려면, 먼저 기계가 읽을 수 있고 거버넌스되는 비즈니스 정의 계층이 있어야 한다. 이 점은 더 다툴 필요가 없다. 정말 다퉈야 할 것은 다음 질문이다. 이 계층은 누구의 것이 되어야 하는가.

옳은 방향 셋, 서로 다른 자물쇠 셋

세 회사의 방안을 펼쳐 놓으면, 난처한 공통점 하나와 마주친다.

	온톨로지가 어디 저장되나	누가 읽을 수 있나	들고 나갈 수 있나
Palantir Foundry	Palantir 플랫폼 내부	상주 엔지니어 + 플랫폼 도구	플랫폼에 묶임, 이전 = 재구축
Microsoft Fabric IQ	OneLake / Fabric 내부	365 및 Fabric 생태계	마이크로소프트 스택에 묶임
Google 기업 지식 그래프	Google Cloud 내부	Vertex 및 GCP 생태계	구글 스택에 묶임

공정하게 말하면, 각 회사는 자기 영역 안에서는 매우 잘하고 있다. Palantir의 온톨로지 모델링 품질은 정말 높다. 마이크로소프트는 시맨틱 레이어를 OneLake와 365에 용접해 넣어, 전사가 마이크로소프트를 쓰는 회사에게는 거의 마찰 없을 만큼 매끄럽다. 구글도 데이터 규모와 그래프 추론에서 진짜 실력이 있다. 이들은 모두 당신의 비즈니스를 정리해 명료하게 만들어 준다. 그리고 그 명료함을 자기 플랫폼 안에 가둔다.

여기까지 보면 구세대 IT 종사자는 반사적으로 한마디 할 것이다. 또 벤더 락인이군, 낡은 문제잖아.

하지만 이번에 가장 걱정해야 할 것은 락인이 아니다. 이번에는 더 고약한 새 문제가 있다. 그것을 분해하기 전에, 닫힌 플랫폼이 이기는 시나리오를 먼저 진지하게 짚어 두어야 한다. 그것은 결코 약하지 않기 때문이다.

먼저 닫힌 플랫폼이 이기는 시나리오를 짚어 보자

‘개방이 좋다’고 외치기만 한다면 그것은 전도이지 분석이 아니다. 닫힌 플랫폼의 손에는 진짜 카드가 넉 장 있다.

첫째, 모델링 품질. 대기업이 20년간 쌓아 온 엉망인 시스템들을 깔끔하고 자기 일관적인 온톨로지로 갈아 넣는 것은 지극히 무거운 엔지니어링이다. Palantir는 상주 엔지니어들이 개념 하나하나를 맞춰 가며 해낸다. 단기적으로 오픈소스 커뮤니티가 따라갈 수 없는 품질이다. 온톨로지란 것은 엉성하게 짓느니 차라리 짓지 않는 편이 낫다.

둘째, 책임질 수 있는 주체. 일이 터지면 전화를 받아 줄 사람이 있고, SLA가 있고, 계약이 받쳐 준다. CIO에게 ‘한 벤더가 이 계층 전체의 책임을 대신 떠안아 준다’는 것 자체가 값어치가 있다. 이를 one throat to choke라고 부른다.

셋째, 많은 회사가 실제로 ‘대부분 한 곳에’ 있다. 당신의 비즈니스 80%가 한 생태계 안에 있다면, ‘생태계 내 최적’은 당신에게 문자 그대로의 최적이며, 개방이 가져다주는 이점은 애초에 쓸 일이 없다.

넷째, 통합 깊이. 같은 생태계 안에서는 데이터, 신원, 권한이 모두 기성품으로 갖춰져 있어, 절약되는 고된 작업이 인월 단위다.

이 넉 장은 모두 진짜다. 그래서 결론은 ‘닫힌 플랫폼은 다 함정’이 아니다. 그 전제에 놓인 회사에게는 종종 그것이 정답이다. 문제는 위안펑 같은 회사에서 생긴다. 그들의 전제가 무너지고 있다는 점이다.

이번 시나리오에는 새 구멍이 있다: 파편화

단일 벤더 락인이라면, 적어도 당신의 비즈니스 정의는 온전한 한 벌이고 단지 옮겨 갈 수 없을 뿐이다. 아프지만 온전하다.

세 거대 기업이 동시에 닫힌 온톨로지를 만들면, 만들어지는 것은 다른 무언가다. 파편화다. 위안펑의 ‘고객’은 잠긴 것이 아니라 세 조각으로 잘려, 서로를 인정하지 않는 세 플랫폼에 각각 누워 있다. 이것은 락인보다 훨씬 괴롭고, 게다가 그 괴로움에는 이유가 있다. 그것이 스스로 아물지 못하도록 보장하는 두 겹의 메커니즘이 있기 때문이다.

첫째 겹은 이해관계다. 이렇게 생각할 수도 있다. 마이크로소프트의 온톨로지가 Salesforce의 ‘고객’을 이해하게 만들면 되지 않나? 안 된다. 어느 한 곳도 그렇게 할 동기가 없기 때문이다. 각 회사의 온톨로지는 곧 그 회사의 해자다. 마이크로소프트가 자발적으로 Salesforce 사이의 ‘고객’ 시맨틱을 통일한다면, 이는 경쟁자가 데이터를 더 매끄럽게 옮기도록 손수 돕고 자기 자신을 범용화하는 셈이다. 통일이라는 행위는 모든 참가 선수에게 자해다. 이것은 기술적 부주의가 아니라 이성적 선택이다. 그러니 이들 중 누군가가 파편화를 수습해 주기를 기대하는 것은 헛된 기대다.

둘째 겹은 기술이다. 이해관계를 차치하더라도, 온톨로지 간 시맨틱 정렬 자체가 풀리지 않은 난제다. A 시스템의 ‘고객’이 B 시스템의 ‘Account’와 같은가? 양쪽의 필드 기준, 라이프사이클, 중복 제거 규칙, 무엇을 ‘같은 엔터티’로 칠지가 전부 다르다. 이 일은 AI도 안정적으로 자동 처리할 수 없다. 오히려 정반대로, agent는 바로 이 확정적인 정의 계층이 없어서 틀린다. H 그룹으로 돌아가 보자. agent에게 ‘이 세 기록이 같은 회사인지’를 스스로 추측하게 하면, 추측이 틀린 대가가 바로 그 수백만이다.

한 문장으로 종합하면 이렇다. 당신은 도구 세 개를 산 줄 알았지만, 실은 서로를 인정하지 않는 ‘진실의 원천’ 세 개를 산 것이다. 시스템이 많을수록, 인수가 많을수록, 컴플라이언스 격리가 많을수록 이 파편화는 심해지고, 하필 agent 시대가 그 대가를 증폭한다. 사람의 머리는 그럭저럭 세 시스템 사이를 수동으로 정렬할 수 있지만, agent는 못 한다. agent는 확정적이고 시스템을 가로질러 일관된 정의 계층이 있어야 추론할 수 있다.

파편화가 일어나지 않게 하려면, 논리적으로 출구는 하나뿐이다. 비즈니스의 정의는 경쟁에 참여하는 어느 플랫폼에도 속해서는 안 되며, 중립적인 무언가여야 한다. 당신이 직접 소유하고 세 회사의 도구가 모두 읽을 수 있는 한 벌의 정의여야 한다. 닫힌 플랫폼은 구조적으로 이것을 줄 수 없다. 그들은 경기의 선수이지, 동시에 심판이 될 수는 없다.

당신이 파편화되고 있는지 판단하는 법

이것은 추상적인 이야기가 아니라 매우 구체적인 초기 증상이 있다. 아래 몇 항목을 대조해, 셋 이상 들어맞는다면 파편화는 이미 당신 회사에서 일어나고 있다.

1. 같은 ‘고객 / 주문 / 설비’가 시스템마다 기준이 달라 맞아떨어지지 않고, 리포트를 만들 때마다 사람이 수동으로 끌어 맞춰야 한다.
2. agent에게 시스템을 가로지르는 질문을 시키면, 모호하게 얼버무리거나 절반만 맞게 답한다(한 시스템은 봤지만 다른 시스템은 못 봤다).
3. 새 시스템을 하나 붙일 때마다 AI에게 ‘이게 뭔지, 필드가 무슨 뜻인지’를 처음부터 다시 가르쳐야 한다.
4. 인수가 1년이 넘었는데도 양쪽 마스터 데이터가 진짜로 하나로 합쳐지지 않은 채 각각 따로 보고된다.
5. 컴플라이언스 요건으로 어떤 종류의 데이터를 격리하면서, 같은 엔터티가 여러 벌로 강제 저장되어 서로를 인정하지 않는다.

위안펑은 H 그룹을 잃기 전, 이 다섯 가운데 넷이 들어맞았다. 당시 그것들은 모두 ‘데이터 거버넌스 처리 대기 항목’으로 치부되었고, 그것이 실은 agent가 언젠가 밟으면 터질 지뢰라는 것을 아무도 알아차리지 못했다.

먼저 찬물 한 바가지: 개방은 만병통치약이 아니다

여기서 정직하게 한 번 멈춰야 한다. 그러지 않으면 약장수가 된다.

첫째, 정의를 오픈 프로토콜로 바꾼다고 해서 위안펑의 세 ‘고객’이 자동으로 하나로 합쳐지지는 않는다. 마땅히 해야 할 시맨틱 모델링, 중복 제거, 기준 정렬은 똑같이 해야 한다. 이 부분에는 만병통치약이 없으니, 그걸 떠벌리는 사람은 믿지 마라. 개방이 진짜로 바꾸는 것은 이 고된 작업의 귀속이다. 오늘 힘들여 정렬해 낸 정의가 당신 자신의 저장소에 적혀 있는 것이지, 어느 플랫폼의 백엔드에 가라앉아 있는 것이 아니다. 내년에 모델을 바꾸고 클라우드를 바꾸고 인수당해도, 다시 만드는 것은 커넥션이지 정의 자체가 아니다.

둘째, ‘개방’ 자체가 승리를 보장하지도 않는다. 역사적으로 개방 표준이 진짜로 이기려면, 충분히 좋은 참조 구현과 활발한 생태계가 함께 필요했다. 프로토콜만 공개해 놓고 아무도 그것을 쓸 만하게 만들지 않으면 똑같이 식어 버린다. 그러니 개방을 택한다는 것은 ‘누군가가 그것을 탄탄하게 만들어 줄 것’에 거는 베팅이며, 이는 실행 리스크가 있는 판단이지 확실한 승리가 아니다.

다만 이 두 바가지 찬물의 무게에 주목하라. 그것이 말하는 바는 ‘개방에도 품이 들고 리스크가 있다’이지, ‘닫힌 쪽이 더 낫다’가 아니다. 그에 비해, 비즈니스 정의를 한 플랫폼에 가두는 하방 리스크 — 즉 위안펑식 파편화 — 는 훨씬 크고 되돌리기도 더 어렵다. 양쪽 다 공짜는 아니다. 다만 그중 한쪽은 가장 핵심적인 자산을 당신 손에 쥐여 준다.

모두에게 의존되는 계층은 결국 중립이 되었다

이 법칙 자체는 새롭지 않지만, 새 사례로 말할 가치가 있다. 지금 반복해서 일어나고 있기 때문이다.

생태계 전체가 함께 의존하는 ‘정의 계층’은 결국 중립으로 향한다. 가장 오래된 예는 SQL이다. 데이터베이스 벤더들이 레드오션에서 치고받았지만, 쿼리 언어 자체는 공공의 것이다. 더 최근이면서 더 시사적인 두 사례는 이것이다. OpenTelemetry — 관측 가능성 분야의 데이터 정의로, 모든 모니터링 벤더가 와서 연동하고, 중립적인 CNCF가 호스팅하며, 누구도 독점하지 못한다. 그리고 LSP(언어 서버 프로토콜) — 마이크로소프트가 직접 만들었지만, 바로 개방되었기 때문에 모든 에디터에 채택되어 사실상의 표준이 되었다.

LSP라는 사례는 특히 음미할 가치가 있다. 그것은 마이크로소프트가 자기 손으로 증명한 사실이기 때문이다. 정의 계층을 개방하고 자신은 가장 좋은 구현으로 돈을 버는 편이, 그것을 걸어 잠그는 것보다 더 이긴다. 비즈니스 시맨틱 레이어는 같은 종류의 것이다. 그것은 앞으로 당신의 애플리케이션, 당신의 agent, 당신의 감사 시스템, 그리고 세 벤더의 도구에 동시에 의존된다. 이렇게 여러 당사자에게 의존되는 계층이 논리적으로 그중 어느 한쪽의 사유물로 장기간 남을 수는 없다. 그것은 중립이 되거나, 아니면 위안펑 같은 파편화를 계속 만들어 낼 것이다.

중립적인 그 계층은 어떤 모습인가

이만큼 말했으니 실물을 한번 보자. 핵심은 문법이 아니라 그것이 어디 있는지, 들고 나갈 수 있는지, 파편화를 다시 거둬들일 수 있는지다.

위안펑이 애초에 ‘고객’을 한 벌의 중립적 정의로 구축했다면, 세 시스템을 각각 데이터소스로 연결해 객체로 모델링하고, 공유 키(사업자번호)를 기준으로 하나의 거버넌스가 적용된 ‘고객’으로 정렬할 수 있다.

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: '고객',
  fields: {
    name: Field.text({ label: '고객명', required: true }),
    tax_id: Field.text({ label: '사업자번호' }), // 시스템 간 "같은 고객"을 맞추는 공유 키
  },
});

이 정의는 당신의 Git 저장소 안에 있어 diff 가능하고, 리뷰 가능하며, 이전 가능하다. 그것이 다음으로 할 수 있는 일이야말로 핵심이다. ‘들고 나갈 수 있다’를 약속 한마디가 아니라 시연 가능한 동작으로 바꾼다.

git add crm/*.ts          # 정의가 당신의 버전 관리에 들어가, 감사·롤백 가능
os start   # 같은 정의가 당신 자신의 인프라 위에서 돌아감
# 그런 다음 어떤 모델이든 여기에 연결하라 — Claude, GPT, Gemini 모두 가능, 런타임은 그대로

이제 그 치명적인 질문을 다시 던져 보자. “H 그룹의 내년 갱신 리스크는 얼마나 높지?” agent가 마주하는 것은 권한과 감사가 붙은 하나의 통일된 ‘고객’이다. 주문은 건전하지만 경영진 차원 불만 두 건과 90일 회수 분쟁 한 건이 겹쳐 있다. agent는 “고위험, 선제 개입 권장”이라고 답할 것이다. 같은 모델, 같은 질문인데, 단지 발밑의 정의가 더 이상 파편화되지 않았다는 이유만으로 결론은 “수백만을 잃는다”에서 “한 분기 앞서 경보를 울린다”로 바뀐다.

이것이 ObjectStack과 ObjectOS의 역할 분담이자, 이 경쟁에 대한 답이다.

• ObjectStack — 비즈니스를 기술하는 오픈 프로토콜(Apache 2.0). 당신의 저장소 안에 있고, 세 회사의 agent가 모두 읽을 수 있다.
• ObjectOS — 이 정의의 런타임. 당신 자신의 인프라 위에서 돌아가며, 권한을 강제하고 감사를 기록한다.

정의 계층은 중립이고, 실행 계층이 비즈니스를 한다. SQL과 데이터베이스 벤더, LSP와 에디터 벤더의 관계와 같은 종류다.

맺으며

이것은 ‘개방이 좋은가, 닫힌 게 좋은가’ 하는 이념 문제가 아니다. 더 냉정한 산수 문제다. 당신의 벤더 조합은 언젠가 반드시 바뀐다 — 멀티 모델, 멀티 클라우드, 인수, 컴플라이언스 격리로 반드시 바뀐다. 그 순간, 당신 비즈니스의 정의는 누구 손에 쥐여 있는가?

세 거대 기업은 진짜 돈을 들여 이 계층이 만들 가치가 있음을 업계에 증명했다. 그러나 그들은 동시에 이 산수 문제를 모든 기업 앞에 들이밀었다. 위안펑의 세 ‘고객’은 기술 사고가 아니라, 정의를 내준 데 따른 필연적 대가다. 그리고 ‘저위험’으로 오판된 그 H 그룹은 첫 번째 청구서일 뿐이다.

모두에게 의존되는 계층이 역사적으로 한 회사에 장기간 귀속된 적은 없다. 이번이라고 다를 이유는 없다.

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

당신의 첫 비즈니스 객체를 정의하고, 그 데이터가 현재 가진 두 시스템에서 오게 한 다음, 자신의 저장소에 git commit 하라. 그 순간, 비즈니스의 정의는 어느 한 회사의 백엔드가 아니라 당신 손으로 돌아온다.