1P by GN⁺ 3시간전 | ★ favorite | 댓글 1개
  • AI가 생성한 코드로 완전한 앱을 빌드할 수 있도록 설계된 오픈소스 백엔드 시스템으로, 실시간 동기화와 오프라인 모드를 기본 제공
  • 구조는 Client SDK, Clojure 기반 백엔드, Postgres 멀티테넌트 데이터베이스로 구성되어, 수천 개의 앱을 동시에 운영 가능
  • 앱 생성은 VM 없이 데이터베이스 행만 추가하는 방식으로, 수 밀리초 내에 백엔드가 완성되고 비활성 앱에는 비용이 발생하지 않음
  • Auth, File Storage, Presence, Streams 등 주요 서비스가 통합되어 있으며, AI 에이전트가 직접 앱 생성과 스키마 업데이트를 수행할 수 있음
  • 4년에 걸쳐 개발된 이 시스템은 차세대 AI 앱 빌더를 위한 핵심 인프라로, GitHub와 Discord를 통해 공개 협업이 가능함

Instant 1.0의 구조와 설계

  • Instant 1.0은 AI가 코드를 작성하는 앱을 위한 완전한 백엔드 플랫폼으로, 오픈소스로 공개됨
  • 핵심 구성은 Client SDK, Clojure 기반 백엔드, Postgres 기반 멀티테넌트 데이터베이스 세 부분으로 이루어짐
  • 앱은 실시간 동기화, 오프라인 모드, 낙관적 업데이트를 기본 제공하며, 인증·파일 저장·Presence·Streams 등의 서비스가 통합됨
  • 모든 앱은 별도 VM 없이 데이터베이스의 몇 개 행만 추가하여 생성되며, 수천 개의 앱을 동시에 운영 가능
  • 전체 시스템은 4년에 걸쳐 개발되었으며, 차세대 AI 기반 앱 빌더를 위한 인프라로 설계됨

Demos

  • Instant는 무제한 앱 생성, 실시간 동기화 엔진, 통합 서비스를 주요 특징으로 제공
    • 앱은 ‘freeze’되지 않으며, VM 대신 데이터베이스 행만 추가해 수 밀리초 내에 백엔드가 완성됨
    • 비활성 앱은 메모리나 컴퓨트 비용이 없고, 활성 시에도 수 KB 수준의 오버헤드만 발생
  • Sync Engine은 오프라인·멀티플레이어·낙관적 업데이트를 지원
    • Linear, Notion, Figma와 같은 현대적 앱의 동작을 일반화해, 클라이언트에서 직접 쿼리와 트랜잭션을 수행
    • db.useQuerydb.transact API로 프론트엔드에서 관계형 쿼리와 변경을 처리
  • 추가 서비스로 Auth, File Storage, Presence, Streams를 통합 제공
    • 파일은 데이터베이스 행으로 관리되어, S3 동기화나 백그라운드 워커 없이도 CASCADE 삭제 등 규칙 적용 가능
    • Auth는 Magic Code, OAuth, Guest Auth를 지원하며, Presence로 온라인 사용자 표시 가능
  • 모든 기능은 API 또는 CLI로 제어 가능하며, AI 에이전트가 직접 앱 생성·스키마 업데이트·권한 설정 수행 가능
    • npx create-instant-app 명령으로 NextJS, Bun, Vite 등 환경에 즉시 프로젝트 생성 가능

아키텍처 개요

  • Instant의 구조는 Client SDK, Clojure Backend, Multi-Tenant Database로 구성
    • Client SDK는 오프라인 쿼리와 낙관적 업데이트를 처리
    • Clojure Backend는 실시간 쿼리 유지와 멀티테넌트 자원 관리 담당
    • Postgres는 모든 앱 데이터를 단일 인스턴스에서 Triple Store 형태로 관리

Client SDK

  • 설계 목표는 오프라인 동작낙관적 업데이트 지원
    • IndexedDB를 사용해 브라우저 내 데이터 지속성 확보
  • Triple Store 구조로 데이터를 [entity, attribute, value] 형태로 저장
    • Datalog 기반 쿼리 엔진을 구현해 클라이언트에서 직접 관계형 쿼리 수행
    • SQLite보다 가볍고, 수십 줄의 코드로 구현 가능
  • Pending Queue를 통해 서버 승인 전 변경사항을 별도로 추적
    • 변경 실패 시 큐에서 제거되어 자동 롤백
    • mutative 라이브러리로 불변 데이터 구조 유지
  • InstaQL은 GraphQL에서 영감을 받은 쿼리 언어로, JavaScript 객체 문법을 그대로 사용
    • 빌드 단계 없이 동적 쿼리 생성 가능
  • Reactor는 IndexedDB, 서버 통신, 오프라인 상태, 실패 복구를 조정하는 핵심 상태 머신
    • WebSocket을 통해 서버와 실시간 데이터 교환 수행

Clojure Backend

  • 백엔드는 반응형 쿼리공정한 멀티테넌트 자원 분배를 목표로 설계
  • Query Store는 어떤 사용자가 어떤 쿼리를 구독 중인지 추적
    • 불필요한 데이터베이스 부하를 줄이기 위해 Topics 개념을 도입
    • Asana의 Luna, Figma의 LiveGraph에서 영감을 받아 쿼리를 주제 단위로 분류
  • Invalidator는 Postgres의 WAL(Write-Ahead Log) 을 모니터링하여 변경된 토픽을 감지
    • 트랜잭션과 쿼리 토픽을 매칭해 필요한 쿼리만 갱신
    • 효율성을 위해 트리형 인덱스 구조 사용
  • Grouped Queue는 앱별 서브큐를 두어 순서를 보장하면서 병렬 처리 가능
    • 고트래픽 앱이 자원을 독점하지 않도록 균형 유지
  • Session Manager는 WebSocket 세션을 관리하며, 쿼리·권한·서비스 요청을 조정
    • Grouped Queue를 활용해 부하 분산
  • Clojure와 JVM의 장점
    • 실스레드 기반 동시성, 간결한 추상화, 풍부한 라이브러리 생태계
    • Google CEL을 활용한 권한 언어 샌드박싱
    • DSL 작성이 용이해 멀티테넌트 SQL 생성 자동화

멀티테넌트 데이터베이스

  • 목표는 저비용 데이터베이스 생성관계형 구조 유지
  • Postgres VM이나 스키마 분리 대신, 단일 triples 테이블을 사용
    • 각 앱은 app_id로 논리적 분리
    • 새로운 데이터베이스 생성은 몇 개의 행 추가로 완료
  • Triple Store 구조의 장점

    • 컬럼 생성 시 테이블 락이 없고, 컬럼 삭제는 소프트 삭제로 즉시 복구 가능
    • Partial Indexes를 이용해 고유 제약조건과 효율적 쿼리 지원
    • column_unique 마커를 기반으로 부분 인덱스 생성
    • 중복 슬러그 삽입 방지 및 빠른 조회 가능
    • Count-Min Sketches로 Postgres의 통계 손실 문제 해결
    • EAV 패턴의 단점을 보완해 쿼리 플래너가 효율적 인덱스를 선택하도록 지원
    • Query Engine은 InstaQL을 SQL로 변환하고, Count-Min Sketch 통계를 활용해 최적화된 쿼리 플랜 생성
    • Clojure로 작성되었으며, pg_hint_plan을 통해 Postgres에 힌트를 전달

결론

  • Instant는 AI가 작성한 코드로 완전한 앱을 빌드할 수 있는 백엔드 인프라
  • 실시간·오프라인·멀티테넌트 구조를 통합한 Postgres 기반 Triple Store 시스템
  • 4년간의 개발 끝에 완성된 구조로, 수천 명의 개발자가 핵심 인프라로 사용 중
  • 모든 코드와 문서는 GitHub에 공개되어 있으며, Discord 커뮤니티를 통해 협업 가능
Hacker News 의견들
  • 솔직한 질문임. 왜 vibe coded 앱에 프레임워크가 필요한지 모르겠음
    그냥 코딩 에이전트에게 프론트엔드는 HTML5/Vanilla JS/CSS, 백엔드는 원하는 언어로 작성하라고 하면 됨
    수백 개의 의존성도 필요 없고, 배포도 에이전트에게 맡기면 끝임

    • 실제로 그렇게 해봤는데, 현재 LLM들은 프레임워크 위에서 작업할 때 훨씬 효율이 좋았음
      코드가 많아질수록 비용뿐 아니라 성능도 떨어지고, 버그나 불필요한 추상화가 늘어남
      결국 좋은 프레임워크를 직접 만들도록 유도하느라 시간을 낭비하게 됨
      차라리 학습 데이터에 포함된 기존 프레임워크를 쓰는 게 낫다고 생각함
      지금 모델로는 랜딩 페이지 이상 규모에서는 추천하지 않음
    • 농담처럼 들릴 수 있지만, 그럼 어셈블리어로 코딩하지 않는 이유도 같음
      좋은 추상화는 가독성과 유지보수를 높이고, 순수 HTML/CSS/JS는 이미 비주류임
      사람이 이해하고 검증할 수 있어야 하며, 바퀴를 다시 발명하느라 토큰과 시간을 낭비하게 됨
      LLM도 인간처럼 복잡한 스파게티 코드에 빠질 수 있음
    • 몇 가지 이유가 있음
      1. 무제한 프로젝트: 기존 VM 기반 백엔드는 비용이 많이 들지만 Instant는 무제한으로 생성 가능함
      2. 사용자 경험: 멀티플레이어, 오프라인 모드, 낙관적 업데이트 같은 기능을 쉽게 구현 가능함
      3. 풍부한 기능: 파일 저장, 커서 공유, 토큰 스트리밍 등도 내장되어 있음
        예시로, 버튼 클릭만으로 백엔드를 만들고 25줄 코드로 실시간 todo 앱을 완성할 수 있음
    • 프레임워크를 쓰면 처음 1만 줄 이상의 스캐폴딩 코드를 0 토큰 비용으로 얻는 셈임
      바로 비즈니스 로직으로 넘어갈 수 있고, 이미 검증된 패턴과 도구 안에서 작업하게 됨
      기업용 소프트웨어는 여전히 대규모 코드베이스를 필요로 하므로, 프레임워크의 가치가 큼
      수많은 엣지 케이스를 이미 해결해둔 전투 검증된 솔루션을 제공함
    • 간단함. 관리해야 할 범위를 줄이고 그 책임을 프레임워크로 넘기는 것임
      좋은 프레임워크를 고르면 수천 개의 결정과 유지보수 부담을 줄일 수 있음
      프레임워크는 결국 확장성 때문에 존재함
  • 사람들이 정말 이런 게 필요한지 궁금함
    Figma나 Linear 같은 멀티플레이어 앱을 만드는 사람이 얼마나 될까?
    대부분은 CRUD 앱일 텐데, 굳이 독점 기술에 종속될 이유가 있을까 싶음

    • 흥미로운 점은, 멀티플레이어 앱을 만드는 게 쉬워지면 더 많은 앱이 그렇게 될 거라는 것임
      예를 들어 Linear가 멀티플레이어인데, 다른 CRUD 앱은 왜 아닌지 모르겠음
      추상화가 잘 되어 있으면 동기화 엔진 기반 앱이 오히려 더 쉽게 만들어짐
      Linear 팀도 이 트윗에서 그렇게 언급했음
    • 참고로 Instant는 100% 오픈소스
      GitHub 저장소
    • 동의함. 요즘은 대부분의 코드를 LLM이 작성하므로 복잡한 기술이 필요하지 않음
      CRUD 앱은 단순하고 반복적이라 AI에 딱 맞음
      백엔드는 Go 바이너리, 프론트는 React면 99.9%의 경우를 커버함
      월 5달러짜리 노드로도 10만 MAU를 거뜬히 처리할 수 있음
  • 개인 프로젝트용으로 완벽한 도구 같음
    다만 “에이전트” 부분이 좀 더 매끄럽게 통합되면 좋겠음
    내 코딩 에이전트가 이걸 어떻게 다루는지 알 수 있을까?
    블로그에 관련 스킬 링크를 추가하면 좋겠음

    • 좋은 제안이라 생각함. 에세이를 바로 업데이트했음
      PR 링크
    • 이미 스킬이 있음
      npx skills add instantdb/skills 명령으로 추가 가능함
      bunx/pnpx/npx create-instant-app으로 프로젝트 스캐폴딩도 추천함
  • 출시 축하함! InstantDB는 써본 것 중 가장 즐거운 도구였음
    작은 토이 프로젝트만 해봤지만, 이 분야에서 가장 단순하고 직관적임
    다만 핵심 제품이 워낙 좋아서 AI 강조점이 약간 어색하게 느껴짐
    요즘 펀딩을 받으려면 그런 포지셔닝이 필요한 건가 싶음

    • 감사함!
      2024년 8월 오픈소스화 이후 웹사이트를 업데이트하지 않았음
      당시 게시글 이후 AI로 앱을 만드는 사용자가 급증했음
      그래서 메시징을 새로 정비했고, 에이전트 경험을 더 즐겁게 만들기 위해 투자했음
    • 감사함. AI 강조는 마케팅이 아니라 실제 사용자 행동에 기반함
      대부분의 사용자가 AI로 코딩하고 있어서 그에 맞게 최적화했음
  • 잘못 이해한 걸 수도 있지만, 왜 ‘AI-coded’인지 궁금함
    단순한 백엔드를 찾는 입장에서 훌륭한 대안처럼 보이지만
    다른 백엔드와 비교해 무엇이 AI 중심인지 잘 모르겠음
    그리고 TS 중심으로 보이는데, 모바일 네이티브 바인딩 계획도 있는지 궁금함

  • 정말 멋진 데모였음. AI 연동 아이디어가 훌륭하지만 설명이 부족함
    튜토리얼을 봤지만 SaaS 계정 생성 중심임
    Triples, Datalog, Clojure 같은 반응형 앱 패턴이 Instant에서 잘 녹아 있음
    개인적으로 Clojure는 어렵고 Datalog도 낯설었는데, Instant의 추상화는 매우 반가움
    InstantQL-Datalog 변환기가 별도 컴포넌트로 제공된다면 정말 유용할 것 같음
    백엔드가 Clojure 기반이라 Postgres 선택이 이해되지만, 로컬 배포에는 SQLite가 더 간단할 수도 있음

  • 관계형 쿼리 + 실시간”을 실제로 구현했다는 점이 인상적임
    다만 콘솔 UI는 인프라나 웹사이트만큼의 정성이 덜 들어간 느낌임
    1.0 출시 축하하며, 앞으로도 Instant로 계속 빌드할 예정임

    • 감사함!
      홈페이지 데모와 에세이, 문서를 많이 개선했음
      대시보드는 몇 주 내로 리디자인 예정임
      흥미로운 점은, AI 에이전트가 앱을 만들고 스키마를 수정하더라도
      사용자는 Explorer 컴포넌트를 통해 데이터를 직접 탐색하는 걸 더 선호함
  • 문서에서 rate limiting 관련 내용을 찾을 수 없음. 혹시 존재하는지 궁금함

  • Pocketbase를 써봤는데 Instant도 비슷한 용도로 좋아 보임
    다만 Pocketbase는 서버 확장성이 강점이었음
    JS나 Go로 훅을 작성해 푸시 알림 같은 기능을 추가할 수 있었음
    InstantDB에서도 이런 기능이 가능한지, 아니면 별도 워커를 만들어야 하는지 궁금함
    그리고 Dart SDK 계획도 있는지 알고 싶음

    • 서버에서 db.subscribeQuery를 사용해 변경 사항에 반응할 수 있음
      webhook 기능도 추가 예정이며, 다른 언어용 SDK도 장기적으로 지원할 계획임
  • 사전 정의된 패턴이 토큰 비용을 줄인다”는 관점에 공감함
    우리도 empla.io를 만들 때 비슷한 경험을 했음
    백엔드 결정을 에이전트에게 맡기면 토큰 사용량이 3~4배 늘어남
    선언형 쿼리 언어가 인간보다 AI에게 더 큰 효율을 줌
    궁금한 점은 두 가지임

    1. 에이전트가 세션 중간에 새로운 관계를 추가할 때 스키마 진화를 어떻게 처리하는지
    2. 세션별 비용 예산 관리 기능이 내장되어 있는지, 아니면 사용자가 직접 구현해야 하는지