실행 가능한 비즈니스 온톨로지를 쓰지 말아야 할 때는 언제인가?

짧은 답: 다섯 가지 워크로드에는 쓰지 말라. 그리고 그 다섯은 ObjectStack 문서가 스스로 지목한다. 대기업의 핵심 ERP나 재무 시스템을 대체하는 일. 많은 기존 시스템을 통합하는 데 가치가 있는 일. 데이터 레이크 위의 분석. 알고리즘을 액션으로 감싸지 않는 한, 가격 책정이나 스케줄링 같은 알고리즘 중심 도메인. 그리고 인증된 플랫폼 위에서 실행되어야 하는 모든 것. 각각에는 더 나은 도구가 있으며, 이 글은 그것이 무엇인지, 왜 그것이 옳은 선택인지, 잘못 고르면 무엇을 치르게 되는지를 말한다. 끝에는 모든 행에 출처를 단 결정표와, 무엇이든 설치하기 전에 자기 사례에 돌려 볼 수 있는 열 문항의 자가 점검이 있다.

어떤 제품이 어디에서 맞지 않는 도구인지 정직하게 적은 목록은 벤더가 발표할 수 있는 가장 유용한 것이다. 구매자가 영업 자료에서는 결코 얻을 수 없는 유일한 것이기 때문이다. ObjectStack의 한 줄 포지셔닝은 “실행 가능한 비즈니스 온톨로지 하나. AI가 쓰고, 런타임이 실행하고, 에이전트가 운영하고, 당신이 소유합니다.”이다. 아래의 모든 내용은 그 문장의 가장자리에 관한 것으로, 프로젝트 자신의 when-to-use 페이지와 비교 페이지(태그 @objectstack/[email protected], 2026-10-28 읽음), 그리고 한계가 곧 한 줄의 코드인 소스 파일에서 가져왔다. 이 사이트의 비교 페이지는 이미 다섯 가지 워크로드와 다섯 가지 질문을 각각 한 줄로 나열한다. 이 글은 그 긴 판이다. 각각에 시나리오, 대안과 그 근거, 비용, 그리고 결정적 사실을 준다.

여섯 종류 테스트

하나의 테스트가 다섯 사례를 모두 덮으므로 먼저 말해 둘 가치가 있다. 개념 페이지는 실행 가능한 비즈니스 온톨로지의 핵심을 여섯 종류의 것으로 정의한다. 오브젝트와 필드, 관계, 액션, 권한, 플로우, 그리고 에이전트와 도구 정의. 런타임은 이 여섯에서 데이터베이스, API, UI, 에이전트 도구를 도출하고, 모든 호출에서 그것들을 강제한다. 코드는 사라지지 않지만 런타임 안으로, 훅, 액션 본문, CEL, 제한된 JSX로 옮겨 가서, 여섯 종류가 정의한 울타리 안에서 돈다.

그러니 어떤 워크로드에든 이렇게 물어라. 어려운 부분이 여섯 종류 중 하나인가? 일에서 어렵고, 가치 있고, 위험한 부분이 무엇이 존재하는지, 어떻게 연결되는지, 무엇을 할 수 있는지, 누가 할 수 있는지, 언제 무엇이 일어나는지를 정하는 것이라면, 온톨로지가 도구이고 에이전트가 그것을 쓸 수 있다. 어려운 부분이 다른 것, 즉 법정 계산, 40개 시스템과의 연결, 페타바이트 스캔, 솔버, 감사인의 인증서라면, 그 부분은 정의로 표현할 수 없고, 온톨로지는 잘해야 그것을 감싸고 최악의 경우 흉내 낸다. 이것을 여섯 종류 테스트라고 부르자. 아래의 다섯 워크로드는 각각 다른 이유로 이 테스트에 실패하며, 그래서 하나가 아니라 다섯 개의 서로 다른 대안이 필요하다.

1. 대기업의 핵심 ERP나 재무 시스템

시나리오. 직원 4천 명의 제조사가 총계정원장, 연결, 급여를 패키지 ERP에서 12년째 운영하고 있다. 계정과목표를 본 코딩 에이전트가 그것을 오브젝트로 다시 선언하겠다고 제안한다. 전기 규칙은 플로우로, 세금은 수식으로. 데모는 설득력 있다. 분개장, 시산표, 모든 분개에 승인.

대신 쓸 것, 그리고 왜 그것이 옳은가. 패키지 시스템을 쓰고 그 주위에 지어라. when-to-use 페이지는 이렇게 말한다. “A general ledger, consolidation, tax and payroll carry regulation and edge cases that packaged systems already encode. Build around that core, not instead of it.”(총계정원장, 연결, 세금, 급여는 패키지 시스템이 이미 인코딩한 규제와 예외 사례를 안고 있다. 그 핵심을 대체하지 말고 그 주위에 지어라.) 그 시장에서는 규제가 곧 제품이다. 급여 엔진은 관할권, 신고 일정, 소급 정정의 라이브러리이며, 그것을 최신으로 유지하는 것만이 유일한 일인 사람들이 관리한다. 연결 엔진은 수년간 쌓인 내부거래 제거와 환산 예외 사례다. 그중 어느 것도 “무엇이 존재하고 누가 무엇을 할 수 있는가”가 아니다. 그것은 계산이며, 당신의 사업이 바뀔 때가 아니라 정부가 바꿀 때 바뀐다.

잘못 골랐을 때의 비용. 두 번째 원장. 당신이 다시 인코딩한 모든 규칙이 이제 당신이 유지해야 할 diff, 통과해야 할 감사, 과세 연도가 바뀔 때의 결함이 된다. 한편 법정 보고를 위해 남겨 둔 패키지 시스템은 분기마다 당신의 사본과 조금씩 더 어긋난다. 하루 만에 규칙을 쓴 에이전트는 당신을 대신해 세법을 읽어 주지 않는다.

결정적 사실. README의 기능 표는 런타임이 제공하는 열두 가지를 나열한다. 오브젝트와 필드, 권한, 자동화, 승인, 뷰, 대시보드와 보고서, 액션, API와 SDK, AI 도구, 번역, 시드 데이터, 데이터소스. 원장, 세금 엔진, 급여 처리는 거기에 없고, 프로젝트는 그것들이 온다고 말하지도 않는다.

같은 페이지가 맞는다고 말하는 것은 그 핵심 주변의 롱테일이다. “vendor onboarding, inspections, internal requests”(공급업체 온보딩, 점검, 내부 요청), 즉 ERP가 다루지 않는 것을 추적하는 스프레드시트와 양식들. 각각은 이메일로 돌아다니는 파일 대신 타입이 있는 정의가 되고, 각각은 ERP의 데이터를 소유하지 않고도 읽을 수 있다. 그것이 다음 사례다.

2. 많은 기존 시스템을 통합하는 데 가치가 있는 워크로드

시나리오. 한 은행은 에이전트가 코어 뱅킹, CRM, 카드 플랫폼, 티켓 시스템에서 고객의 질문에 한 번에 답하고, 그중 둘에 상태를 되써 주기를 원한다. 그 시스템들 중 어느 것도 움직이지 않는다. 일은 그것들을 에이전트가 읽을 수 있게 하고, 그것들을 가로질러 행동하는 것이다.

대신 쓸 것, 그리고 왜. 시스템들 위의 계층. 읽기에는 시맨틱 계층이나 컨텍스트 계층, 다스려야 할 되쓰기가 있을 때는 Palantir류의 운영 온톨로지. 비교 페이지는 이를 솔직하게 인정한다. “When the data already lives in a warehouse, a lakehouse and a dozen operational systems, these start where you are.”(데이터가 이미 웨어하우스, 레이크하우스, 십여 개의 운영 시스템에 살고 있다면, 이들은 당신이 있는 곳에서 시작한다.) 그 제품들은 기록 시스템이 그대로 있다는 가정 위에 지어졌다. 그들의 오브젝트 모델은 뷰이고, 쓰기는 되쓰기이며, 가치는 아래에 있는 시스템의 수와 함께 커진다. ObjectStack은 반대의 가정, 즉 온톨로지가 곧 시스템이고 데이터베이스는 거기서 도출된다는 가정 위에 지어졌다.

잘못 골랐을 때의 비용. 가장 자주 틀리는 사례다. 첫 주가 잘 풀리기 때문이다. ObjectStack은 schemaMode: 'external'로 외부 데이터베이스를 데이터소스로 연합할 수 있고, 레거시 테이블 위의 읽기 모델은 짧은 오후면 된다. 그다음이 쓰기다. 연합된 쓰기는 기본적으로 두 겹으로 꺼져 있다. 데이터소스는 external.allowWrites: true를, 오브젝트는 external.writable: true를 선언해야 하며, “with either gate off, insert/update/delete on the federated object is rejected.”(어느 한쪽 게이트라도 닫혀 있으면 연합된 오브젝트에 대한 insert/update/delete는 거부된다.) 이 게이트는 권고가 아니다. assertWriteAllowed는 엔진의 insert와 update 맨 위에서, 기본값, 훅, 검증보다 먼저 실행된다. 오브젝트마다 두 게이트를 모두 열면 당신은 이제 당신이 통제하지 않는 스키마에 대한 쓰기 의미론을 소유하게 되고, schemaMode: 'external'은 스키마 불일치 시 부팅을 실패시키므로 업스트림의 컬럼 이름 하나가 바뀌면 당신의 앱이 내려간다. 아니면 대신 동기화 작업을 만들고, 그때쯤이면 사지 않으려 했던 통합 계층을, 자기 문서에서 연합을 “early”(초기)라고 부르는 도구 안에 직접 지어 버린 셈이 된다.

결정적 사실. 기본적으로 둘 다 꺼진 두 개의 옵트인. 데이터소스의 allowWrites와 오브젝트의 writable(content/docs/data-modeling/external-datasources.mdx, 쓰기에 관한 절)이며, packages/objectql/src/engine.ts의 assertWriteAllowed가 강제한다.

정직한 길은 존재하고, 좁다. 읽기 전용으로 연결하고, 측정하고, 오브젝트 하나씩 쓰기를 켜고, 오브젝트 단위로 전환한다. How to move an internal system to metadata가 그 길을, 아예 옮기지 않는 것이 정답인 경우까지 포함해 걷는다. 그 길은 당신이 대체하려는 시스템을 위한 것이다. 40개 시스템을 그대로 두고 가로질러 읽으려 한다면, 그것은 잘못된 길이다.

3. 데이터 레이크 위의 분석

시나리오. 한 소매업체가 3년치 클릭스트림과 POS 이벤트를 Parquet와 Iceberg 테이블로 오브젝트 스토리지에 갖고 있고, 머천다이징 팀은 대시보드를 원한다. 누군가 이 플랫폼에 대시보드, 보고서, 그리고 문서가 시맨틱이라 부르는 데이터셋 계층이 있음을 알아채고, 그것을 레이크로 향하게 하자고 제안한다.

대신 쓸 것, 그리고 왜. 웨어하우스 스택. 컬럼 스캔을 위해 만들어진 쿼리 엔진, 그 위의 메트릭 또는 시맨틱 계층, 그리고 맨 위의 BI 도구. ObjectStack의 분석 계층은 애플리케이션 자신의 행을 위한 메트릭 계층이다. 그 문서는 데이터셋을 “a base object, the relationships to include, and the declared dimensions and measures”(베이스 오브젝트, 포함할 관계, 그리고 선언된 차원과 측정값)로 정의하고, 조인은 오브젝트 그래프에서 도출된다. 스키마는 이를 문자 그대로 만들어 데이터셋의 object를 “Base object name”(베이스 오브젝트 이름)으로 기술한다. when-to-use 페이지는 한 문장으로 말한다. 분석 계층은 “defines metrics over the app’s own objects for its reports and dashboards. It is not built to query a lake.”(앱 자신의 오브젝트 위에 보고서와 대시보드를 위한 메트릭을 정의한다. 레이크를 질의하기 위해 만들어지지 않았다.) 웨어하우스의 시맨틱 계층은 레이크 위에서 같은 일을 하며, 이 사이트의 비교 페이지도 BI를 진지하게 하는 회사는 여전히 그것을 원할 것이라고 말한다.

잘못 골랐을 때의 비용. 두 사본 중 하나. 레이크를 앱 오브젝트에 적재하면, 이제 3년치 이벤트의 두 번째 사본이 자체 신선도와 자체 청구서를 갖고, 스캔을 위해 설계된 것이 아니라 비즈니스 정의에서 도출된 행 저장소에 놓인다. 아니면 웨어하우스 테이블을 연합하고, 분석 질문을 애플리케이션을 위해 행 단위 쿼리에 답하도록 만들어진 엔진, 필터 푸시다운은 있지만 컬럼 파일을 아는 것은 아무것도 없는 엔진으로 보내고 있음을 알게 된다. 대시보드는 렌더링될 것이다. 머천다이징 팀이 요청한 대시보드는 아닐 것이다.

결정적 사실. README가 나열하는 데이터소스는 PostgreSQL, MySQL, SQLite, MongoDB, 인메모리이고, README가 이제 CONTRIBUTING.md에 넘긴 패키지 디렉터리가 Turso와 WebAssembly 안의 SQLite를 더한다. 레이크 포맷도, 컬럼 엔진도, 오브젝트 스토리지 드라이버도 없으며, 데이터셋 계층은 오브젝트에 바인딩되지, 레이크 안의 테이블에 바인딩되지 않는다.

4. 가격 책정이나 스케줄링 같은 알고리즘 중심 도메인

시나리오. 한 물류 회사의 제품은 경로 최적화기다. 하루치 주문과 차량을 받아 계획을 내놓는 솔버, 그리고 플래너가 정차지를 차량 사이로 끌어다 놓고 계획이 다시 풀리는 것을 지켜보는 배차 보드. 주문, 차량, 기사, 계획은 분명히 오브젝트다. 회사는 이 전부가 실행 가능한 온톨로지가 될 수 있는지 묻는다.

대신 쓸 것, 그리고 왜. 솔버에도 보드에도 코드. 그리고 여기서는 온톨로지 자신의 문서가 대안을 위한 가장 강력한 논거다. when-to-use 페이지는 온톨로지가 “declares what can be done; it does not express an optimiser.”(무엇을 할 수 있는지를 선언한다. 최적화기를 표현하지는 않는다.)라고 말한다. 액션의 type은 script, url, modal, flow, api, form 중 하나이고, script 액션의 핸들러는 앱의 전체 데이터 권한으로 실행되는 코드다. 정의가 소유하는 것은 문, 문의 권한, 누가 그 문을 지나갔는지의 감사다. 문 뒤의 알고리즘은 당신의 것이며, 그것을 풀 수 있는 어떤 언어든 좋다. 인터페이스는 같은 이야기의 반대 방향이다. 비교 페이지는 Console이 “server-driven from metadata, and an interface unlike any business app is easier to build directly.”(메타데이터에서 서버 구동되며, 어떤 비즈니스 앱과도 닮지 않은 인터페이스는 직접 만드는 것이 더 쉽다)라고 말한다.

잘못 골랐을 때의 비용. 가장 중요한 부분을 자유가 가장 적은 곳에 짓는 것. 솔버는 액션 뒤에 살 수 있고, 레코드에서 트리거되는 스케줄링 실행에는 그것이 정확히 옳다. 배차 보드는 그럴 수 없다. 페이지 안의 제한된 JSX는 설계상 “is parsed into a server-driven UI tree, never executed as code”(서버 구동 UI 트리로 파싱되며, 코드로 실행되는 일은 결코 없다)이므로, 플래너가 필요로 하는 모든 상호작용이 목록, 양식, 보드를 위해 만들어진 렌더러와의 협상이 된다. 여섯 달 뒤, 온톨로지는 당신이 실제로 파는 것을 둘러싼 얇은 껍데기가 된다.

통하는 분할은 이렇다. 비즈니스 절반, 즉 주문, 차량, 기사, 누가 계획을 승인할 수 있는지, 계획이 게시되면 무엇이 일어나는지는 온톨로지로 만들어 에이전트가 쓰고 운영할 수 있게 한다. 솔버는 script 액션 뒤의 코드로 만들어 권한, 감사, 에이전트 접근이 다른 모든 액션과 마찬가지로 적용되게 한다. 플래너의 보드는 자체 애플리케이션으로 만든다. 보드가 곧 제품이라면 거기서 시작하라.

5. 인증된 플랫폼을 요구하는 워크로드

시나리오. 한 병원 그룹이 입원 접수 워크플로를 원하고, 그 구매 부서는 그것이 돌아가는 플랫폼이 특정 인증을 보유할 것을 요구한다. 공공 입찰은 ISO 인증서에 대해 같은 질문을 던진다. 워크로드 자체, 즉 양식, 라우팅, 승인, 감사 추적은 교과서적인 적합 사례다.

대신 쓸 것, 그리고 왜. 인증서를 보유한 플랫폼이거나, 당신이 직접 인증하는 배포이며, 결정은 벤더의 로드맵이 아니라 구매자의 달력이 한다. when-to-use 페이지는 이렇게 말한다. “ObjectStack is open-source software you deploy and operate, and it carries no compliance certification of its own. Where a workload must run on a certified platform, certifying your deployment is work you own.”(ObjectStack은 당신이 배포하고 운영하는 오픈소스 소프트웨어이며, 자체 컴플라이언스 인증을 갖고 있지 않다. 워크로드가 인증된 플랫폼에서 실행되어야 하는 곳에서는, 당신의 배포를 인증하는 것은 당신이 소유한 일이다.) 이것은 회피가 아니다. 인증은 원래 그렇게 동작한다. 인증은 실행 중인 환경, 그 통제, 그 운영자를 다루며, Apache-2.0 저장소는 그중 어느 것도 아니다. 이 사이트의 보안 페이지는 상용 에디션에 대해 같은 말을 한다. “Certification depends on your running deployment, not a binary alone.”(인증은 실행 중인 배포에 달려 있지, 바이너리 하나에 달려 있지 않다.)

잘못 골랐을 때의 비용. 설계 단계가 아니라 구매 단계에서 이것을 발견하는 것. 그때쯤이면 일정은 이미 플랫폼이 인증서를 가져온다고 가정하고 있다. 그러면 감사는 예산 없이, 가동 직전에 당신의 계획 위로 떨어진다.

결정적 사실. 프로젝트의 용어집은 자체 프로토콜 적합성 키트조차 “planned”(계획됨)로 나열하며, “no TCK program or certification mechanism in the codebase today”(오늘 코드베이스에는 TCK 프로그램도 인증 메커니즘도 없다)라고 적는다. 감사인에게 가리킬 것은 당신의 배포 말고는 없다.

워크로드는 여전히 적합하다. 문제는 호스트다. 정직한 순서는 먼저 인증 작업의 비용을 산정한 다음 결정하는 것이다.

다른 범주가 앞서 출발하는 두 곳 더

비교 페이지는 두 가지 양보를 더 추가하는데, 그것들은 부적합 목록에 없다. 워크로드의 종류가 아니라 문제의 종류에 관한 것이기 때문이다. 둘 다 여섯 종류 테스트를 같은 방식으로 통과한다.

이종 데이터에 대한 추론. 질문이 “우리가 아는 모든 것에서 무엇이 따라 나오는가”이고, 클래스 계층, 도출된 사실, 어휘를 가로지르는 일관성 검사를 동반한다면, 그것은 지식 온톨로지의 일이며, ObjectStack에는 “no object inheritance, no axioms and no reasoner”(오브젝트 상속도, 공리도, 추론기도 없다). abstract 키는 약속으로 남겨지는 대신 스펙에서 제거되었다. 정의는 검증된 다음 실행된다. 런타임에 추론되는 것은 아무것도 없다. 정의 글이 이 부정을 충분히 다룬다.

생태계 성숙도. Salesforce, Odoo, ERPNext는 “bring years of production use, packaged applications, app marketplaces and implementation partners. ObjectStack is younger; expect to build more of it yourself.”(수년간의 프로덕션 사용, 패키지 애플리케이션, 앱 마켓플레이스, 구현 파트너를 가져온다. ObjectStack은 더 젊다. 더 많은 것을 직접 지을 각오를 하라.) 이번 분기에 패키지 앱이 필요하고 당신의 도시에 구현 파트너가 필요하다면, 정의가 어떻게 쓰이든 더 젊은 플랫폼은 잘못된 베팅이다.

결정표

각 행은 워크로드, 오늘 적합한지와 대신 쓸 것, 그리고 그것을 결정하는 하나의 사실과 출처다. “오늘”은 날짜다. 출처는 objectstack의 태그 @objectstack/[email protected], 즉 npm view @objectstack/cli dist-tags가 2026-10-28에 latest로 보고한 버전이며, 그날 읽었다. 출처는 파일 이름으로 쓴다. when-to-use, compare, ontology는 content/docs/concepts/*.mdx, external-datasources와 analytics는 content/docs/data-modeling/ 아래, glossary는 content/docs/getting-started/ 아래, engine.ts는 packages/objectql/src/engine.ts, dataset.zod.ts와 action.zod.ts는 packages/spec/src/ui/ 아래, README와 CONTRIBUTING.md는 저장소 루트에 있다.

워크로드	오늘 적합한가? 대신 쓸 것	결정적 사실(출처)
대기업의 핵심 ERP나 재무	아니오. 패키지 시스템. 그 주위에 짓는다	규제와 예외 사례가 곧 제품. 런타임의 열두 기능에 원장, 세금, 급여 엔진은 없다(when-to-use; README 기능 표)
많은 기존 시스템의 통합	아니오. 시맨틱 또는 컨텍스트 계층. 되쓰기가 있으면 운영 온톨로지	연합은 기본적으로 두 겹으로 읽기 전용. 데이터소스의 `allowWrites`와 오브젝트의 `writable`(external-datasources; `engine.ts`의 `assertWriteAllowed`)
데이터 레이크 위의 분석	아니오. 웨어하우스 쿼리 엔진, 메트릭 계층, BI	데이터셋은 베이스 오브젝트에 바인딩. 드라이버는 행 저장소이고 레이크 포맷은 없다(analytics; `dataset.zod.ts`; README 데이터소스; `CONTRIBUTING.md` 드라이버)
알고리즘 중심 도메인	알고리즘에는 아니오. 코드. 나머지가 비즈니스 앱이면 `script` 액션 뒤에	`ActionType`은 script, url, modal, flow, api, form. 솔버는 결코 타입이 아니다(`action.zod.ts`; when-to-use)
인증된 플랫폼에서 실행되어야 함	당신이 소유한 작업 없이는 아니오. 인증된 플랫폼, 또는 당신의 배포를 인증	자체 컴플라이언스 인증 없음. 적합성 키트조차 “계획됨”(when-to-use; glossary)
이종 데이터에 대한 추론	아니오. 추론기를 갖춘 지식 온톨로지	상속도, 공리도, 추론기도 없음. `abstract`는 ADR-0049에 따라 제거(ontology; compare)
지금 당장 성숙한 생태계가 필요	아직은 아니오. 패키지 앱과 파트너를 갖춘 메타데이터 플랫폼	“ObjectStack은 더 젊다. 더 많은 것을 직접 지을 각오를 하라”(compare)
새 비즈니스 앱: CRM, 티켓, 승인, 운영, 내부 도구	예.	오브젝트, 관계, 액션, 권한, 플로우가 이런 앱의 대부분이다(when-to-use)
핵심 ERP 주변의 롱테일	예.	작고, 구체적이고, 자주 바뀐다. 앱마다 타입이 있는 정의 하나, ERP를 소유하지 않고 읽는다(when-to-use)
첫날부터 에이전트가 운영하는 백오피스	예.	모든 배포가 MCP 서버이고, 기본으로 켜져 있으며, 사용자의 권한 아래에 있다(when-to-use; README)

자가 점검을 돌려 보라

열 문항, 두 단계, 십 분. 1단계는 배제 목록이고, 2단계는 when-to-use 페이지의 “Five questions before you start”(시작하기 전 다섯 가지 질문)를 거기 인쇄된 그대로 인용한 것이다.

1단계. 어느 하나라도 예이면 온톨로지는 그 부분의 도구가 아니다.

이 워크로드의 어려운 부분이 패키지 시스템이 이미 인코딩한 규제 계산인가. 원장, 연결, 세금, 급여인가?
가치의 대부분이 당신이 남겨 두되 소유하지 않는 시스템을 읽고 쓰는 데서 오는가?
분석하려는 데이터가 애플리케이션 자신의 레코드가 아니라 레이크나 웨어하우스에 정지해 있는가?
제품의 핵심이 솔버, 최적화기, 시뮬레이션이거나, 어떤 비즈니스 앱과도 닮지 않은 인터페이스인가?
워크로드가 특정 인증을 보유한 플랫폼에서 실행되어야 하며, 자체 배포를 인증할 예산이 없는가?

2단계. 당신의 팀은 오늘 비즈니스에 대해 이것들에 답할 수 있는가?

“What we have — the objects and their fields.”(무엇을 갖고 있는가. 오브젝트와 그 필드.)
“How it relates — the lookups and master-detail links between them.”(어떻게 연결되는가. 그들 사이의 룩업과 마스터-디테일 링크.)
“What can be done — the actions a user or an agent may take on a record.”(무엇을 할 수 있는가. 사용자나 에이전트가 레코드에 취할 수 있는 액션.)
“Who may do it — permission sets, row-level and field-level security, sharing.”(누가 할 수 있는가. 권한 집합, 행 수준과 필드 수준 보안, 공유.)
“What happens when — record triggers, scheduled jobs, approvals, workflows.”(언제 무엇이 일어나는가. 레코드 트리거, 예약 작업, 승인, 워크플로.)

다섯 번의 아니오와 다섯 개의 답. 온톨로지는 그 페이지의 말로 “a day’s work, because an agent does the writing.”(하루 일이다. 쓰는 것은 에이전트이기 때문이다.) 다섯 번의 아니오와 답 없음. “no tool helps yet, this one included. The first investment is answering these five questions, not installing anything.”(아직 어떤 도구도 도움이 되지 않는다. 이것도 포함해서. 첫 투자는 무언가를 설치하는 것이 아니라 이 다섯 가지 질문에 답하는 것이다.) 1단계에 예가 하나. 그 선을 따라 워크로드를 나누고, 통과한 부분을 남기고, 나머지에는 표의 대안을 쓴다.

이 목록이 말하지 않는 것

이 한계들이 영구적이라고 말하지 않는다. 페이지의 제목은 “not a fit today”(오늘은 맞지 않음)이고, 연합은 “early”(초기)라고 불리며, 위의 표에는 날짜가 붙어 있다. 결정하기 전에 현재 페이지와 대조하라.

대안이 일반적으로 더 낫다고 말하지 않는다. 시맨틱 계층은 40개 시스템을 가로질러 읽기에는 옳은 도구이고, 티켓 데스크를 운영하기에는 틀린 도구다. 이유는 2절이 반대 방향에서 말한 그대로다. 각 행의 대안은 그 행에 대해서 옳다.

그리고 한 행에 실패하면 워크로드가 실패한다고 말하지 않는다. 대부분의 실제 사례는 나뉜다. 입원 접수 워크플로는 적합하고 호스트는 구매의 문제다. 배차 도메인은 적합하고 솔버는 코드다. ERP 주변의 부서 앱은 적합하고 원장은 있던 자리에 남는다. 여섯 종류 테스트는 어려운 부분에 적용되지, 프로젝트 이름에 적용되지 않는다.

이 목록에서 ObjectOS의 자리

위의 어느 것도 에디션에 따라 바뀌지 않는다. ObjectOS는 세 가지 에디션으로 제공됩니다. 오픈소스이며 무료로 직접 호스팅하는 ObjectOS Community, 설치 없이 브라우저에서 호스팅되는 ObjectOS Cloud, 자체 인프라에서 직접 운영하는 ObjectOS Enterprise입니다. 온톨로지는 일반적인 ObjectStack 메타데이터입니다. ObjectOS Cloud 또는 ObjectOS Enterprise에서 내보내 오픈소스 ObjectStack 런타임에서 실행하는 기능은 계획 중입니다. 다섯 가지 워크로드는 실행 가능한 온톨로지가 무엇을 표현할 수 있는지에 관한 것이지, 어디서 실행되는지에 관한 것이 아니다. 그래서 이 목록은 어떤 호스트에서든 같게 읽힌다. 호스트에 관한 유일한 질문인 인증에 대해, 보안 페이지는 ObjectOS에 대해 오픈소스 페이지와 같은 말로 답한다. 실행 중인 배포에 달려 있다고.

당신의 사례가 통과했다면

그렇다면 가장 빠르고 정직한 다음 단계는 데모가 아니라 정의다. how to point your agent at ObjectStack에서 다루는 규칙 파일, 스킬 번들, 도구 서버로 코딩 에이전트를 ObjectStack에 향하게 하고, 첫 오브젝트를 요청하라. 필드 몇 개, 관계 하나, 액션 하나, 권한 집합 하나, 트리거 하나. npm run validate를 실행하고, Console을 읽기 전에 diff를 읽어라. diff 전체를 읽을 수 있고 그것이 당신의 비즈니스가 하는 일을 말한다면, 여섯 종류 테스트는 실전에서 통과한 것이며, 에이전트에게 다음으로 건넬 페이지는 정의란 무엇인가다. 읽을 수 없다면, 이 글의 어떤 것도 애초에 당신을 도울 수 없었을 것이고, 당신은 방금 프로젝트 하나를 아낀 것이다.