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

요약부터: 이 글이 2026년 6월에 처음 나왔을 때 던진 질문은 “비즈니스 의미 계층을 누가 소유할 것인가”였다. 그 경주는 이미 끝났다. 아홉 달 동안 다섯 플랫폼이 각자 하나씩 출시했다. 그리고 아무도 예상하지 못한 일이 벌어졌다. 이들은 온톨로지에 이르는 접근 경로를 MCP로 열면서, 정의 자체는 안에 남겨두었다. 이를 프로토콜은 열리고 정의는 닫혔다고 부르자. 이제 agent는 가져갈 수 없는 다섯 개의 온톨로지를 읽을 수 있다. 이것은 소유권 질문을 무디게 하는 것이 아니라 날카롭게 만든다. 그리고 답은 그대로다. 애플리케이션, agent, 감사, 여러 벤더의 도구가 함께 의존하는 정의 계층은 당신의 저장소에 두는 중립 계층이어야 한다.

먼저 한 회사가 바로 이 문제로 고객을 잃은 이야기부터 시작하자. 세부는 익명화했지만, 각 단계는 아마 익숙할 것이다.

위안펑이라고 부를 이 산업 장비 제조사는 연매출 수십억 달러 규모에 수천 개 고객사를 두고 있다. 2024년, 이 회사는 데이터 기반을 Microsoft에 걸고 Fabric 안에 깔끔한 온톨로지를 세웠다. “고객”이 무엇인지, 어떤 “설비”가 어떤 고객에 연결되는지, 어떤 “작업 지시”가 어떤 설비에 붙는지. 그해 이 회사는 벤더 콘퍼런스에서 반복해 인용되는 모범 사례가 되었다.

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

• 데이터 사이언스 팀이 갱신 예측을 Gemini로 돌리고 싶어 했다. 그 시나리오에서는 실제로 더 정확했기 때문이다.
• 컴플라이언스 부서에 EU 고객 데이터는 EU에 머물러야 하며 미국 클라우드에 둘 수 없다는 통지가 왔다.
• 인수가 마무리되며 Salesforce 위에서 돌아가는 수천 개 고객사의 영업 조직이 통째로 들어왔다.

그렇게 위안펑에는 세 개의 “고객”이 생겼다. Fabric에 하나, Salesforce에 하나, 컴플라이언스로 격리된 EU 환경에 또 하나.

전환점은 H 그룹이라 부를 핵심 고객에서 왔다. 어느 날 영업 총괄이 agent에게 물었다. “H 그룹의 내년 갱신 리스크는 얼마나 높습니까?” agent는 “낮습니다”라고 답했다. 그것은 Fabric 온톨로지를 읽고 있었고, 거기서 H 그룹의 최근 수주는 건강했으며 숫자는 보기 좋았다.

그러나 agent가 보지 못한 것: 인수로 들어온 Salesforce 기록에서 H 그룹은 6개월 사이 두 번이나 불만을 임원급으로 에스컬레이션했다. EU 격리 환경에는 90일 연체된 대금 분쟁이 미결로 걸려 있었다. 세 벌의 데이터는 서로를 모르는 세 개의 “고객”에 속해 있었고, 그것들이 모두 같은 H 그룹이라는 사실을 아는 계층은 어디에도 없었다.

한 분기 뒤 H 그룹은 이탈했다. 연간 수백만 달러의 손실이었다. 사후 분석의 결론은 회의실을 침묵시킬 만큼 냉정했다. agent는 기술적으로 틀리지 않았다. 그것이 본 데이터 조각은 정말로 낮은 리스크를 보여주고 있었다. 잘못된 것은 모델이 아니었다. 그 발밑의 “고객” 정의가 셋으로 잘려 있었던 것이다.

이것은 단순히 위안펑의 실수가 아니다. “당신 비즈니스의 정의”를 플랫폼에 맡겼을 때 예측 가능한 결과다. 각 플랫폼은 자기 몫만 지키고, 자기 몫만 이해하기 때문이다.

이 글이 지목한 경주는 이미 끝났다

이 글이 처음 나왔을 때 참가자는 아직 예측이었다. 이제는 기록이다. 2025년 11월부터 2026년 8월까지 다섯 플랫폼이 비즈니스 의미 계층을 출시했다.

플랫폼	무엇을 출시했나	시점
Microsoft Fabric IQ	Ontology 항목과 함께 Graph·Data Agent·Operations Agent로 구성된 agent 워크로드 일체. 퍼블릭 프리뷰이며, 공개 Ontology MCP 엔드포인트로 어떤 agent든 접근 가능	Ignite, 2025년 11월. 2026년 3월 FabCon 애틀랜타에서 규칙과 자동화 추가
Snowflake	Semantic View Autopilot GA. 위원회가 “매출”을 처음부터 정의하게 하는 대신, 기존 쿼리 이력과 BI 자산에서 의미 뷰를 초안한다	2026년 2월 3일
Google	Looker BI Agents가 Looker 의미 계층에 근거해 동작. Dataplex는 Knowledge Catalog로 개칭되어 카탈로그 메타데이터를 의미 그래프로 바꾸고 agent용 컨텍스트 API를 제공	Cloud Next ‘26, 2026년 4월
Databricks Unity Catalog	Business Semantics GA. 통제된 메트릭 뷰와 agent 메타데이터를 데이터 계층에서 한 번 정의하며, 핵심 구현은 Apache Spark로 오픈소스화 진행 중	2026년 GA. Business Glossary와 Domains는 2026년 6월 Data + AI Summit에서
Palantir Foundry	Ontology MCP가 모든 Foundry 환경에서 GA. 객체 타입, 액션 타입, 함수가 어떤 MCP 클라이언트에서든 호출 가능한 도구로 노출된다	2026년 6월 16일 주

논의를 이어가기 전에 이 표에 대해 두 가지를 분명히 해두자.

이 글은 이들을 칸 단위로 비교하는 자리가 아니다. 역량별로, 각 벤더 자신의 문서를 출처로 삼아 맞춰본 것은 별도의 글이다: Fabric IQ vs Palantir vs Unity Catalog vs Snowflake. 거기서는 어느 쪽이 비즈니스를 설명하는 데 그치지 않고 액션을 모델링하는지 — 가장 결정적인 행 — 이 정리되어 있다. 선정 중이라면 그 글을, 무엇을 소유할지 정하는 중이라면 이 글을 읽으라.

논지를 만드는 것은 날짜이지 기능 목록이 아니다. 아홉 달, 다섯 플랫폼, “이 계층은 만들 가치가 있다”는 다섯 개의 독립적인 판단. 기업에서 AI를 쓰려면 기계가 읽을 수 있고 통제된 비즈니스 정의 계층이 필요하다 — 이 절반은 더 이상 설득할 필요가 없다.

한 가지 정리가 여기 필요하다. 여기 등장하는 세 단어는 흔히 동의어처럼 쓰이지만 동의어가 아니다: ontology vs semantic layer vs knowledge graph가 각각 무엇에 답할 수 있고 없는지를 못 박는다. 아래 소유권 논의는 어느 계층을 말하는지 이미 정한 독자를 전제한다.

반전: 프로토콜은 열리고, 정의는 닫혔다

여기서부터가 누구의 예상과도 다르게 흘러간 부분이며, 6월 이후 가장 중요한 변화다.

플랫폼들은 벽을 닫지 않았다. 오히려 열었다 — MCP로. Fabric IQ는 공개 Ontology MCP 엔드포인트를 제공한다. Palantir는 이 글이 처음 공개된 바로 그 주에 모든 Foundry 환경에서 Ontology MCP를 정식 출시했다. Snowflake는 관리형 MCP 서버를 제공한다. Google은 Knowledge Catalog 앞에 컨텍스트 API를 두었다. 위 비교 글의 네 플랫폼 중 셋이 자신의 의미 계층을 MCP로 agent에 열어두고 있다.

언뜻 보면 열린 답이 저절로 도착한 것처럼 보인다. 아니다. 이 구분은 정확하게 말할 가치가 있다.

MCP가 표준화한 것은 agent가 당신의 온톨로지에 어떻게 닿는지다. 누가 그것을 쥐고 있는지에 대해서는 아무것도 표준화하지 않았다.

MCP 엔드포인트는 읽기 경로이지 소유권 증서가 아니다. 당신의 agent는 깔끔하고 통제되며 벤더 중립적인 질의 수단을 얻는다. 그러나 그 질의가 향하는 정의는 여전히 남의 플랫폼에 살고, 여전히 그들의 릴리스 일정에 따라 버전이 매겨지며, 당신이 떠날 때 그들과 함께 남는다. 프로토콜은 열려 있다. 정의는 닫혀 있다. 프로토콜은 열리고, 정의는 닫혔다.

이것이 중요한 이유는 이 둘이 하필 가장 돈이 드는 방향으로 혼동되기 쉽기 때문이다. “어떤 agent든 읽을 수 있다”는 이식성처럼 들린다. 그것은 이식성의 반대다. 이식되지 않는 상태를 편안하게 만들어 주는 것이다.

그것이 파편화를 완화하지 않고 악화시키는 이유

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

다섯 플랫폼이 각자 자기 온톨로지를 쥐면 다른 것이 생긴다. 파편화다. 위안펑의 “고객”은 단지 잠긴 것이 아니라 셋으로 잘려 서로를 모르는 세 플랫폼에 보관되었다. 그것이 저절로 낫지 않게 막는 장치가 두 겹 있었고, MCP가 이제 세 번째를 더했다.

첫 번째 겹은 인센티브다. Microsoft의 온톨로지가 Salesforce의 “고객”을 이해하게 하면 되지 않느냐고 생각할 수 있다. 그렇게 간단하지 않다. 각 벤더의 온톨로지는 자사 해자의 일부이기 때문이다. Microsoft가 일방적으로 “고객” 의미론을 경쟁사와 통일한다면, 경쟁사가 데이터를 더 매끄럽게 옮기도록 돕고 자사의 차별화는 줄이는 셈이다. 경주의 모든 참가자에게 통일은 전략적으로 매력적이지 않다. 이것은 기술적 실수가 아니라 합리적인 플랫폼 행동이다.

두 번째 겹은 기술이다. 인센티브를 제쳐두더라도 온톨로지 간 의미 정렬은 어렵다. A 시스템의 “고객”은 B 시스템의 “Account”와 같은가? 필드 정의, 생명주기, 중복 제거 규칙, “같은 실체”의 판단 기준이 시스템마다 다르다. AI도 이것을 신뢰할 만하게 자동 추론하지 못한다. agent가 틀리는 이유가 바로 이 확정된 정의 계층이 없기 때문이다. H 그룹으로 돌아가자. “이 세 기록이 같은 회사인가”를 agent가 추측하게 두었을 때, 틀린 대가가 바로 그 손실이었다.

세 번째 겹은 새롭고, 가장 불편하다: MCP는 파편화를 견디는 비용을 낮췄다. 예전에는 서로 연결되지 않은 다섯 개의 의미 계층에 agent를 배선하는 일이 충분히 고통스러워서, 결국 누군가 문제를 위로 올렸고 정합 프로젝트에 예산이 붙었다. 이제 그것은 오후 한나절에 엔드포인트 다섯 개를 등록하는 일이다. agent는 “이 고객이 누구인가”에 서로 다르게 답하는 다섯 개의 도구를 태연히 들고 다니며, 가장 먼저 닿은 쪽에서 자신 있게 답할 것이다. 정합을 강제하던 통합의 고통은 제거되었다. 그것이 경고하던 파편화는 그대로다.

한 줄로 정리하면: 당신은 다섯 개의 도구를 샀다고 생각했지만, 실제로는 서로를 모르는 다섯 개의 진실 소스를 샀다. 게다가 이제는 편리하게 호출된다. 시스템이 많을수록, 인수가 많을수록, 컴플라이언스 격리가 많을수록 이 파편화는 심해진다. agent 시대는 그 대가를 증폭한다. 사람은 고통스럽게나마 여러 시스템을 수작업으로 맞출 수 있지만 agent는 못 한다. 추론하기 전에 확정된, 시스템 간 일관된 정의 계층이 필요하다.

파편화를 피하려면 당신 비즈니스의 정의가 경주에 참가한 플랫폼에 온전히 속해서는 안 된다. 그것은 중립 계층 — 당신이 직접 쥐고, 여러 벤더의 도구가 읽을 수 있는 정의 — 이어야 한다. 닫힌 플랫폼은 구조적으로 이것을 제공하기 어렵다. 그들은 경주의 선수이며, 동시에 중립 심판이 될 수는 없다.

먼저, 닫힌 플랫폼이 이기는 각본

“열린 것이 좋다”만 반복한다면 그것은 분석이 아니라 설교다. 닫힌 플랫폼은 진짜 카드 네 장을 쥐고 있고, 지난 아홉 달 동안 그중 둘은 더 강해졌다.

첫째, 모델링 품질. 20년 쌓인 기업의 복잡성을 깨끗하고 자기일관적인 온톨로지로 빚어내는 일은 무거운 엔지니어링이다. Palantir는 상주 엔지니어와 함께 개념을 하나씩 맞춰간다. 그 품질을 오픈소스 커뮤니티가 단기간에 따라잡기는 어렵다. 온톨로지는 잘못 만들면 아예 안 만드느니만 못할 수 있다. 상주 모델에는 고유한 경제학이 있고, 그것은 직함만큼 쉽게 옮겨지지 않는다 — 상주 모델을 흉내 내면 왜 컨설팅 회사가 만들어지는가가 그 밑에 무엇이 먼저 있어야 하는지를 풀어낸다.

둘째, 책임지는 단일 주체. 무언가 깨졌을 때 전화를 받는 사람이 있고, SLA가 있고, 뒤에 계약이 있다. CIO에게 “한 벤더가 이 계층 전체를 책임진다”는 것은 실제로 값어치가 있다.

셋째, 실제로 “거의 한 스택”인 회사가 많다. 업무의 80%가 이미 한 생태계 안에 있다면 “생태계 내 최선”이 문자 그대로 최선일 수 있다. 사업이 시스템을 가로지르지 않는다면 개방의 이점은 쓰기 어렵다.

넷째 — 이 카드가 강해졌다 — 콜드 스타트 문제. Snowflake의 Autopilot은 이미 있는 쿼리 이력에서 의미 모델을 초안한다. Fabric IQ는 업무 전문가가 노코드 시각 도구로 온톨로지를 직접 만들게 해 데이터 엔지니어를 기다리지 않아도 되게 했다. 둘 다 진짜 장애물을 겨눈다. 장애물은 기술이 아니라 6개월짜리 모델링 위원회였다. 열린 포맷이 건네주는 것은 파일 한 개와 빈 페이지다.

네 장 모두 진짜다. 그러니 결론은 “닫힌 플랫폼은 다 함정”이 아니다. 한 생태계 안에 편안히 들어맞는 회사에게는 흔히 정답이다. 문제는 위안펑 같은 회사에서 드러난다. 전제가 만료된다.

파편화되고 있는지 알아보는 법

이것은 추상적이지 않고 구체적인 초기 증상이 있다. 아래와 대조해 보라. 셋 이상 해당한다면 파편화는 이미 사내에서 일어나고 있다.

1. 같은 “고객 / 주문 / 설비”가 시스템마다 다르게 정의되어 대사가 안 되고, 보고서마다 사람이 이어 붙인다.
2. agent에게 시스템을 가로지르는 질문을 하면 얼버무리거나 절반만 맞는다(한쪽은 봤고 다른 쪽은 못 봤다).
3. 새 시스템을 붙일 때마다 AI에게 “이게 무엇이고 필드가 무슨 뜻인지”를 다시 가르친다.
4. 인수가 1년 넘게 지났는데 양쪽 마스터 데이터가 아직 진짜로 합쳐지지 않았고, 각자 자기 버전을 보고한다.
5. 컴플라이언스가 특정 데이터의 격리를 요구해 같은 실체가 여러 벌로 나뉘었고, 서로를 인식하지 못한다.
6. 당신의 agent에 의미 계층 도구가 두 개 이상 붙어 있는데, 서로 어긋날 때 무엇이 우선인지 아무도 적어두지 않았다.

위안펑이 H 그룹을 잃기 전, 앞의 다섯 중 넷이 해당했다. 당시 그것들은 “데이터 거버넌스 할 일”로 정리되었고, agent가 언젠가 터뜨릴 리스크라고는 아무도 생각하지 않았다. 여섯 번째는 2026년에 추가된 항목이며 가장 조용히 찾아온다. 엔드포인트를 하나 더 붙이는 일은 진전처럼 느껴지기 때문이다.

찬물 한 바가지: 개방은 은탄환이 아니고, 이 분야는 표준화되고 있다

여기서 정직하게 멈추자. 그러지 않으면 판촉이 된다. 타당한 반론이 셋 있고, 세 번째는 새롭다.

첫째, 정의를 열린 프로토콜로 바꾼다고 위안펑의 세 “고객”이 저절로 하나가 되지는 않는다. 의미 모델링, 중복 제거, 정의 정렬은 여전히 해야 한다. 여기에 은탄환은 없고, 있다고 말하는 사람을 믿어서는 안 된다. 개방이 진짜로 바꾸는 것은 이 고된 일의 귀속이다. 오늘 맞춰낸 정의는 플랫폼 뒤편이 아니라 당신의 저장소에 쓰인다. 내년에 모델을 바꾸고, 클라우드를 바꾸고, 인수될 때 다시 만드는 것은 연결이지 정의 자체가 아니다.

둘째, “개방” 자체가 승리를 보장하지 않는다. 역사적으로 열린 표준이 이기려면 대개 좋은 참조 구현과 활발한 생태계가 함께 필요했다. 아무도 쓰기 좋게 만들지 않는 프로토콜을 공개하는 것만으로는 부족하다. 개방을 택하는 것은 “누군가 제대로 만들 것”에 거는 베팅이다. 이는 실행 리스크이지 확정된 승리가 아니다.

셋째 — 그리고 이 글의 입장에 대한 가장 강한 반론인데 — 벤더들이 스스로 정의 계층을 표준화하고 있다. Snowflake는 Salesforce, dbt Labs, BlackRock, RelationalAI와 함께 Open Semantic Interchange를 공동 창설했다. 이 이니셔티브는 2026년 7월 Apache Ossie로 Apache 인큐베이터에 들어갔고, Databricks, Oracle, Collibra를 포함해 50개 이상의 조직이 참여한다. Databricks는 별도로 메트릭 뷰 구현을 Apache Spark로 오픈소스화하고 있다. 이것은 진짜이고, 대부분의 중립 계층 시도보다 빠르다. 오늘 “닫힌 플랫폼은 절대 수렴하지 않는다”고 주장하는 것은 증거와 다투는 일이다.

그러나 그 수렴이 어디서 멈추는지 잘 보라. Ossie가 다루는 것은 분석계 의미론 — 메트릭, 디멘션, 관계다. 액션과 권한은 범위 밖이다. 즉 당신 온톨로지에서 비즈니스를 설명하는 절반은 이식 가능해지고 있고, 비즈니스를 바꾸는 절반 — 연산 자체, 누가 실행해도 되는지, 감사 로그에 무엇이 남는지 — 은 여전히 독점으로 남는다. 이것은 작은 나머지가 아니다. agent가 무언가를 할 수 있는지를 결정하는 절반이고, 파편화의 대가가 가장 비싼 절반이다.

이 셋 중 어느 것도 닫힌 쪽이 낫다고 말하지 않는다. 개방에도 품이 들고, 리스크가 있고, 절반은 상대가 마중 나오고 있다고 말한다. 그것을, 비즈니스 정의를 한 플랫폼에 묶어두고 이후 다섯 곳으로 쪼개지는 쪽의 하방과 견주어 보라. 어느 쪽도 공짜가 아니다. 다만 한쪽은 핵심 자산을 당신 손에 남긴다.

모두가 의존하는 계층은 결국 중립이 된다

패턴 자체는 새롭지 않지만 새 사례로 말할 가치가 있다. 계속 반복되고 있기 때문이다.

생태계 전체가 함께 의존하는 “정의 계층”은 중립으로 가는 경향이 있다. 가장 오래된 예는 SQL이다. 데이터베이스 벤더는 치열하게 경쟁했지만 질의 언어 자체는 공공으로 남았다. 더 최근의 두 예는 중립적인 CNCF가 호스팅하는 관측성 데이터 표준 OpenTelemetry, 그리고 Microsoft가 공개했고 열려 있었기 때문에 많은 에디터가 채택한 LSP(Language Server Protocol)다.

LSP 사례가 특히 유용한 것은 Microsoft 자신이 그 패턴을 증명했기 때문이다. 정의 계층을 열고 최고의 구현으로 경쟁하는 편이 계층을 걸어 잠그는 것보다 더 큰 가치를 만들 수 있다. 다만 LSP가 실제로 무엇을 열었는지 보라 — 프로토콜, 그리고 언어 서버가 무엇을 제공해야 하는지에 대한 정의다. 온톨로지에 대해서는 MCP가 앞의 절반을 해냈다. Apache Ossie가 분석 부분의 뒤 절반을 시도하고 있다. 그리고 행위하는 부분은 아직 아무도 하지 않았다.

당신의 애플리케이션, agent, 감사 시스템, 그리고 다섯 벤더의 도구가 동시에 의존하는 계층은, 위안펑이 겪은 종류의 파편화를 계속 만들어내지 않는 한 그중 한 곳의 사유물로 남을 수 없다.

중립 계층은 어떻게 생겼나

여기까지 왔으니 실물을 보자. 요점은 문법이 아니라 정의가 어디 있는지, 가져갈 수 있는지, 파편화를 되돌릴 수 있는지다.

위안펑이 애초에 “고객”을 하나의 중립 정의로 만들었다고 하자. 세 시스템을 모두 데이터 소스로 연결하고, 각각을 객체로 모델링한 뒤, 공유 키(사업자 등록번호)로 하나의 통제된 “고객”으로 정렬한다. 당신 저장소 안의 선언이 곧 단일 진실 원천이 된다.

export const Customer = ObjectSchema.create({
  name: 'crm_customer',
  label: 'Customer',
  fields: {
    name: Field.text({ label: 'Customer name', required: true }),
    tax_id: Field.text({ label: 'Tax ID' }), // 시스템 간 "같은 고객"을 정렬하는 공유 키
  },
});

이 정의는 Git 저장소에 있다. diff 되고, 리뷰되고, 이관된다. 다음에 무엇을 할 수 있는지가 핵심이다 — “가져갈 수 있음”을 약속이 아니라 보여줄 수 있는 동작으로 바꾸는 것.

git add crm/*.ts          # 정의가 버전 관리에 들어간다: 감사 가능, 되돌리기 가능
os start   # 같은 정의가 당신의 인프라 위에서 실행된다
# 그다음 어떤 모델이든 가리키면 된다 — Claude, GPT, Gemini — 런타임은 그대로다

이제 그 결정적인 질문을 다시 던지자. “H 그룹의 내년 갱신 리스크는 얼마나 높습니까?” agent가 마주하는 것은 권한과 감사가 붙은 하나의 통합된 “고객”이다. 건강한 수주 위에 임원급 불만 두 건과 90일 대금 분쟁이 겹쳐 있다. agent는 “높은 리스크, 조기 개입 권고”라고 답한다. 같은 모델, 같은 질문. 발밑의 정의가 더는 파편화되어 있지 않다는 것만으로, 결론은 “수백만 달러를 잃었다”에서 “한 분기 먼저 경고했다”로 바뀐다.

MCP 논점은 여기서도 통하고, 방향이 옳다. 같은 정의가 바로 런타임이 통제된 도구로 agent에게 내주는 그것이다 — 읽기 경로는 열려 있고, 동시에 정의는 당신 것이다. 그것이 정의와 런타임이 왜 둘 다 열려야 하는가가 온전히 펼치는 논증이다.

이것이 ObjectStack과 ObjectOS의 분업이며, 이 경주에 대한 답이다.

• ObjectStack — open business ontology(열린 비즈니스 온톨로지): 열린 정의 프로토콜과 오픈소스 자체 호스팅 런타임(Apache 2.0). 정의는 당신의 저장소에 있고, 어떤 벤더의 agent든 읽을 수 있으며, 런타임이 검증하고 실행하면서 권한과 감사를 강제한다.
• ObjectOS — 같은 ObjectStack 애플리케이션을 위한 선택적 상용 프로덕션 플랫폼과 운영 경험. 클라우드든 자체 관리든, 브라우저 기반 AI 구축·배포·운영을 더한다. 아래의 열린 정의와 런타임을 대체하지 않는다.

정의와 자체 호스팅 런타임은 열리고 중립으로 남으며, 상용 프로덕션 경험에서 제품이 경쟁한다. SQL과 데이터베이스 벤더, LSP와 에디터 벤더의 관계와 같다.

거래 조건도 정직하게 적자. 모델링 깊이, 콜드 스타트, 그리고 웨어하우스 규모의 분석계 의미론 — 이 셋에서는 위 플랫폼들이 앞서 있고, 비교 글이 어디서 앞서는지 자세히 말한다. 여기서 다른 점은 “더 낫다”보다 좁다. 정의가 열린 라이선스 아래 당신 저장소의 평범한 파일이고, 그것을 집행하는 런타임을 당신이 호스팅한다는 것이다.

맺으며

이것은 “개방이 선인가 폐쇄가 선인가”라는 이념 문제가 아니다. 더 냉정한 아키텍처 문제다. 멀티모델 도입, 멀티클라우드 전략, 인수, 컴플라이언스 격리로 벤더 구성이 바뀔 때, 당신 비즈니스의 정의를 쥐고 있는 것은 누구인가.

아홉 달 전 그 질문은 가정이었다. 이 분야가 아직 아무것도 내놓지 않았기 때문이다. 이제는 내놓았다. 다섯 플랫폼이 이 계층을 만들 가치가 있음을 증명했고, 그다음 대부분이 당신 소유가 아닌 집에 현관문을 열었다. 남의 온톨로지 위의 MCP 엔드포인트는 정말 유용하다 — 다만 그 정의를 소유하는 것과 같지는 않으며, 그 둘 사이의 틈이 바로 위안펑의 H 그룹이 떨어진 곳이다.

모두가 의존하는 계층이 한 회사에 오래 머무는 일은 드물다. 이번 계층만 예외일 이유는 없다.

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

첫 비즈니스 객체를 정의하고, 그 데이터를 기존 두 시스템에서 가져온 뒤, 자기 저장소에 git commit 해보라. 그 순간 비즈니스의 정의는 남의 백엔드가 아니라 당신 손으로 돌아와 있다.