솔직한 제안 — 언제 사용해야 하고, 언제 사용하지 말아야 하며, 무엇이 다른지.

왜 ObjectOS인가

이 페이지는 ObjectOS가 여러분에게 적합한지 알아내기 위해 다른 모든 문서의 행간을 읽을 필요가 없도록 존재합니다.

이 베팅의 형태

ObjectOS는 하나의 확고한 베팅을 합니다. AI가 애플리케이션의 메타데이터를 작성하고, 여러분은 그것을 실행하는 런타임을 소유합니다.

여러분은 객체, 필드, 뷰, 플로우, 권한을 파일 하나하나 직접 손으로 작성하지 않습니다. 사용자(또는 그들을 대신해 작동하는 AI 에이전트)가 필요한 것을 Console 내장 AI Builder에게 평이한 언어로 설명합니다. 그러면 AI Builder는 감사된 소규모 도구 집합을 호출하고, 모든 변경 사항을 사람의 승인을 위해 대기열에 넣으며, 그 결과는 곧바로 작동합니다 — REST 엔드포인트, Console 화면, RBAC, 감사 로그, 이 모든 것이 동일한 메타데이터에서 생성됩니다.

런타임은 여러분의 VPC, 여러분의 데이터베이스, 여러분의 Apache-2.0 포크 위에 자리합니다. 모델은 여러분의 데이터 웨어하우스가 아니라 샌드박스화된 메타데이터 API와 대화합니다.

이것이 제안의 전부입니다. 이 페이지의 나머지는 누구에게 맞고 누구에게 맞지 않는지에 관한 것입니다.

다음과 같다면 ObjectOS를 사용하세요 …

내부 도구, 관리자 패널 또는 백오피스 앱이 필요하고, 또한
그것을 사용하는 사람들(또는 그들을 대신해 작동하는 AI 에이전트)이 티켓을 발행하지 않고도 그것을 확장할 수 있기를 원하며, 또한
데이터를 다른 사람의 클라우드에 둘 수 없거나 두고 싶지 않고, 또한
인증 + RBAC + 감사 + 파일 업로드 + 작업 + 웹훅을 열 번째로 다시 만들고 싶지 않다면.

적합한 일반적인 시나리오:

시나리오	왜 효과적인가
보안 검토에서 데이터 주권이 거론되어 Retool / Appsmith 앱을 대체할 때	ObjectOS는 여러분의 VPC에서 실행되며, 데이터는 절대 외부로 나가지 않습니다
규제 대상 비즈니스를 위한 컴플라이언스 / 리스크 / 벤더 관리 도구를 구축할 때	감사 로그, RBAC, 필드 보안, 행 수준 격리가 기본 기능이며 — 모든 AI 주도 변경 자체가 하나의 감사 항목입니다
SaaS 제품을 위한 내부 관리자를 구축할 때	단일 Node 프로세스로, 기존 서비스 옆에 그대로 들어맞습니다
엔터프라이즈 고객을 위한 에어갭 또는 온프레미스 배포	기본 배포 대상이며, 인터넷 송신이 필요 없습니다(로컬 모델 직접 준비)
멀티 테넌트 내부 포털(하나의 런타임, 여러 개의 작은 앱)	프로젝트별 커널 + LRU 캐시가 이를 위해 설계되었습니다
사용자가 자신만의 확장을 안전하게 "바이브 코딩"하기를 원할 때	AI Builder + HITL 승인 대기열 + 감사 로그가 바로 그 핵심입니다

다음과 같다면 ObjectOS를 사용하지 마세요 …

트래픽이 많은 소비자 제품을 구축하고 있다면 → 전통적인 웹 프레임워크를 사용하세요, 더 많은 제어권을 갖게 됩니다.
최종 사용자를 위한 픽셀 단위로 완벽한 맞춤형 UI가 필요하다면 → ObjectOS의 Console은 관리자/내부용입니다. REST를 통해 여러분만의 프런트엔드와 함께 사용하세요.
비엔지니어를 위한 노코드 드래그 앤 드롭 빌더와 호스팅된 클라우드를 원한다면 → Retool, Bubble 또는 Airtable을 사용하세요. ObjectOS는 코드 우선, AI 주도, 자체 호스팅 방식입니다.
실시간 협업 편집(Figma 스타일)이 필요하다면 → 그것은 realtime 플러그인이 해결하는 문제가 아닙니다.

여러분이 아마 사용 중인 것과의 비교

vs. Retool / Appsmith / Internal

	Retool	ObjectOS
데이터 위치	그들의 클라우드(또는 상위 등급에서 자체 호스팅)	항상 여러분의 네트워크
UI 빌더	드래그 앤 드롭, 매우 세련됨	메타데이터 기반, 생성됨; 덜 맞춤화됨
가격	사용자당, 고통스럽게 증가	자체 호스팅, Apache-2.0
워크플로우 / 트리거	그들의 워크플로우 엔진	선언적 플로우 + 플러그인
백엔드 로직	그들의 쿼리 편집기로 제한됨	전체 TypeScript, 전체 Node 생태계
가장 적합한 용도	기존 API 위에 빠른 대시보드	데이터를 소유하는 앱

vs. Supabase / Firebase

	Supabase	ObjectOS
설정 시간	약 30초	약 30초
데이터베이스	Postgres, 그들의 것(자체 호스팅 가능)	모든 Postgres / MySQL / SQLite / Turso / Mongo, 여러분의 것
인증	내장	내장
생성된 API	PostgREST	ObjectQL 생성 REST
관리자 UI	Console(기본)	Console + Account
RBAC	Postgres RLS를 통한 행 수준	RBAC + 행 수준 + 필드 수준, 선언적
감사 로그	직접 구현	기본 기능
벤더 종속	그들의 인증 + 그들의 스토리지 + 그들의 realtime	없음 — 모든 계층이 플러그인
가장 적합한 용도	BaaS를 원하는 신규 앱	런타임을 소유해야 하는 앱

vs. Salesforce / NetSuite / ServiceNow

	Salesforce	ObjectOS
데이터 모델	객체 + 필드 + 관계	동일
권한	프로필 + 권한 집합 + 공유 규칙 + FLS	동일한 어휘, 선언적 TypeScript
사용자당 비용	사용자당 월 $150-300	$0
커스터마이징	Apex + Lightning + 플로우	TypeScript + 플로우
실행 위치	오직 그들의 클라우드	여러분의 인프라
"우리가 소유"하기까지의 시간	수개월의 컨설턴트 작업	하루 오후
가장 적합한 용도	생태계에 비용을 지불할 영업 주도 기업	세금 없이 모델을 원하는 팀

vs. 직접 구축(Next.js + Prisma + NextAuth)

	DIY	ObjectOS
첫 REST 엔드포인트	몇 시간	60초
인증(이메일 + OAuth + OIDC + 패스키 + 2FA)	수 주	포함됨
모든 객체를 위한 관리자 UI	객체마다 구축	생성됨
감사 로그	직접 구현	플러그인, 선언적
권한이 적용된 S3 파일 업로드	직접 구현	플러그인
백그라운드 작업 + 재시도 + 데드 레터	직접 구현	플러그인
멀티 테넌시	직접 구현(그리고 두 번은 잘못 만들 것입니다)	내장
가장 적합한 용도	맞춤형 UX를 가진 공개 앱	속도가 우선인 내부 도구

솔직한 트레이드오프

Retool보다 UI 자유도가 낮습니다. Console은 여러분의 메타데이터에서 생성됩니다. 맞춤형 프런트엔드와 함께 사용할 수 있지만(REST API는 Console이 사용하는 것과 동일합니다), 손수 만든 픽셀 단위로 완벽한 UI가 필요하다면 직접 구축하고 ObjectOS를 백엔드로 사용하세요.
TypeScript 우선. 비엔지니어가 객체를 직접 작성하지는 않습니다. Salesforce 관리자는 UI 빌더를 클릭하는 데 익숙하지만, 여기서는 git입니다.
Salesforce보다 신생. Salesforce는 25년간 문서화된 엣지 케이스를 가지고 있습니다. 우리는 수백 개를 가지고 있습니다. 프로토콜은 안정적이며, 생태계는 성장 중입니다.
Apache-2.0. 상업용 제품에 사용하고, 임베드하고, 비공개로 수정하세요. 카피레프트의 깜짝 놀랄 일은 없습니다. 선택적 상업 지원은 별도로 제공됩니다.

현실 점검

가장 작은 실용적인 ObjectOS 배포는 단일 pnpm dev 또는 SQLite를 사용하는 단일 Docker 컨테이너입니다. 오늘날 프로덕션에서 가장 큰 배포는 Postgres + S3 + Redis로 여러 지역에 걸쳐 수만 명의 내부 사용자를 서비스합니다. 둘 다 동일한 소프트웨어입니다.

npx @objectstack/cli init my-app으로 시작해서 5분 안에 결정하세요. 여러분에게 맞지 않는다면 5분을 쓴 것뿐입니다.

Quickstart 사용해보기 →

왜 ObjectOS인가

On this page