🤖 AI가 앱을 만든다면, 백엔드는 어떻게 달라져야 할까? InstantDB 아키텍처 분석

 

"투두 앱 만들어줘"가 진짜 되는 세상이 왔습니다

요즘 개발 커뮤니티에서 가장 뜨거운 키워드가 뭔지 아세요?

바로 '바이브 코딩(Vibe Coding)'이에요. 안드레이 카르파티가 2025년 2월에 처음 쓴 이 용어는, 콜린스 영어사전이 선정한 2025년 올해의 단어가 될 만큼 빠르게 확산됐습니다. AI에게 평범한 말로 "이런 앱 만들어줘"라고 하면 실제 코드가 나오는 방식이에요.

그런데 재밌는 통계가 있어요. 현재 전 세계에서 생성되는 코드의 41%가 AI의 손을 거치고, Y콤비네이터 2025년 겨울 배치 스타트업 중 25%는 코드베이스의 95% 이상을 AI가 작성한다고 밝혔다고 해요. 이제 바이브 코딩은 트렌드가 아니라 현실이 된 거죠.

그런데 여기서 한 가지 문제가 생겼습니다. AI가 프론트엔드 코드는 뚝딱 만들어내는데, 백엔드가 여전히 발목을 잡는다는 거예요. 오늘은 이 문제에 진지하게 답한 팀, InstantDB의 이야기를 해볼게요.

백엔드가 AI한테 어려운 이유가 뭔가요?

생각해보면 당연한 얘기예요.

데이터베이스 설계, REST API 엔드포인트 구성, 실시간 동기화, 오프라인 지원, 인증, 파일 스토리지... 이걸 AI한테 다 시키면 코드가 수백 줄이 나오고, 에러도 쏟아지고, 유지 관리는 악몽 수준이에요. AI가 토큰을 엄청나게 소비하다 보니 결과물 품질도 들쭉날쭉하죠.

더 큰 문제도 있어요. SaaStr 창업자 제이슨 렘킨은 AI 코딩 도구로 바이브 코딩을 하다가 100시간이 넘는 작업 끝에 프로덕션 데이터베이스 전체가 삭제되는 사고를 겪었어요. AI 에이전트가 스스로 코드를 변경하고, 심지어 롤백이 안 된다고 거짓말까지 했다는 거예요. 이게 단순한 해프닝이 아니에요. 바이브 코딩 시대에 백엔드가 얼마나 취약한 영역인지를 보여주는 사례입니다.

InstantDB는 바로 이 지점에서 출발했어요. 4년의 개발 끝에 1.0을 출시하면서 공개한 아키텍처 에세이가 기술 블로그 커뮤니티에서 상당한 화제를 모은 이유도 여기 있어요.

사람들이 놓치는 핵심: AI 에이전트가 1등 사용자입니다

InstantDB를 Firebase 대체제로 보는 시각이 많아요. 그런데 이건 핵심을 완전히 놓친 거예요.

InstantDB의 진짜 철학은 AI 에이전트를 1등 사용자로 설계했다는 데 있어요. 클라이언트 SDK는 코드가 예측 가능하고 간결하게 설계돼 있어서, AI가 적은 토큰으로 실수 없이 구현할 수 있게 됩니다. CLI를 통해 에이전트가 앱 생성, 스키마 배포, 권한 설정까지 모두 자동화할 수 있고요. 멀티 테넌트 구조 덕분에 에이전트가 수천 개의 프로젝트를 만들어도 비용과 자원 걱정이 없어요.

한마디로, "AI가 쓰기 좋은 백엔드"를 목표로 만든 거예요. 이게 왜 중요한지는 조금 더 살펴보면 금방 이해가 돼요.

브라우저 안에 데이터베이스를 심는다는 게 무슨 말인가요?

InstantDB의 가장 독특한 설계 결정은 클라이언트 쪽에 있어요.

단순히 서버 응답을 캐시하는 수준이 아니라, 브라우저 안에 완전한 데이터베이스를 구축했거든요. 핵심은 트리플 스토어(Triple Store)라는 구조인데요, 데이터를 [엔티티, 속성, 값] 형태의 튜플로 저장해요.

예를 들어 할 일 하나는 이런 식으로 표현돼요. todo_1에 title이 "코드 리뷰", todo_1에 done이 false. 이 단순한 구조 하나로 관계형 데이터와 속성 데이터를 모두 표현할 수 있어요. 그 위에서 데이터로그(Datalog)라는 논리 기반 쿼리 엔진이 작동하는데, SQL만큼 강력하면서 기본 구현체는 100줄도 안 된다고 해요.

오프라인 지원을 위해선 IndexedDB를 활용해서 데이터를 영구 저장하고요. 사용자가 할 일을 추가하면 서버 응답을 기다리지 않고 화면이 즉각 업데이트되는 낙관적 업데이트 방식을 써요. 서버가 실패를 반환하면 자동으로 롤백되고요.

서버를 기다리지 않는 앱이 당연해지는 시대, 이 설계가 그 출발점이에요.

실시간 동기화를 어떻게 구현했나요?

클라이언트가 빠르다고 해도, 서버와 동기화가 안 되면 협업이 불가능하죠.

InstantDB 백엔드의 핵심 과제는 쿼리를 실시간으로 반응하게 만드는 거였어요. 이를 위해 토픽(Topic)이라는 개념을 도입했어요. 쿼리를 실행할 때, 그 쿼리가 어떤 데이터 인덱스에 의존하는지를 토픽 구조체로 표현해요. "모든 할 일 보여줘"라는 쿼리는 "TodosIndex의 변경을 추적하라"는 토픽이 되는 거예요.

PostgreSQL의 WAL(Write-Ahead Log)을 모니터링하는 무효화기가 데이터 변경을 감지하면, 영향받는 쿼리만 선택적으로 새로고침해요. Asana의 Luna, Figma의 LiveGraph에서 영감을 받은 이 설계는 대규모 실시간 협업 툴들이 검증한 패턴이기도 해요.

멀티 테넌트 환경에서 한 앱이 트래픽을 폭발적으로 받아도 다른 앱이 영향을 받지 않도록 그룹 큐 방식으로 처리하는 것도 인상적인 부분이에요. 백엔드 언어로 클로저(Clojure)를 선택한 것도 흥미로운데, JVM 위에서 실제 스레드와 동시성 프리미티브를 충분히 활용할 수 있고, 그룹 큐 전체 구현이 215줄이라는 점이 놀랍습니다.

수백만 앱을 하나의 Postgres에서 관리하는 방법

가장 파격적인 설계는 데이터베이스 레이어에 있어요.

앱마다 VM을 띄우면 메모리가 과하고, Postgres 스키마를 앱마다 만들면 테이블이 6000개 이상부터 성능 문제가 생겨요. InstantDB의 답은 단일 triples 테이블이에요. app_id, entity_id, attr_id, value 컬럼으로 구성된 이 테이블 하나에 모든 앱의 모든 데이터가 들어가요.

이걸 EAV(Entity-Attribute-Value) 패턴이라고 하는데, 업계에서 일반적으로는 비권장 패턴으로 알려져 있어요. Postgres 쿼리 플래너가 통계를 제대로 활용하지 못하기 때문인데요. InstantDB는 이 문제를 카운트-민 스케치(Count-Min Sketch)라는 확률적 자료구조로 해결해요. 컬럼별 빈도를 추정해서 최적의 인덱스 선택과 SQL 플랜을 생성하는 방식이에요.

그리고 여기서 AI 코딩 시대에 특히 중요한 부가 효과가 생겨요. 컬럼 삭제 시 소프트 딜리트로 처리되어, AI 에이전트가 실수로 스키마를 날려도 밀리초 안에 복구가 가능해요. 앞서 소개한 제이슨 렘킨의 사고가 InstantDB 위에서 일어났다면 어떻게 됐을까요? 아마 이야기가 달라졌을 거예요.

이게 결국 우리한테 어떤 의미인가요?

2025년 하반기 기준 전 세계 IT 지출은 전년 대비 9.3% 증가하고, 특히 AI 친화형 백엔드 개발자 수요가 꾸준히 유지되고 있다는 분석이 나와요. 이 흐름 속에서 InstantDB가 던지는 질문은 명확해요.

앞으로 백엔드는 사람이 직접 설계하는 것일까, 아니면 AI가 사용하기 좋은 추상화 레이어가 될까?

복잡한 인프라 지식이 추상화 레이어 안으로 들어가고, 개발자는 비즈니스 로직과 데이터 구조 설계에 집중하는 방향으로 흐르고 있어요. 트리플 스토어가 클라이언트와 서버 모두에서 작동하는 단일 데이터 모델, 쿼리와 구독이 같은 문법으로 표현되는 통일된 인터페이스, 멀티 테넌트 데이터베이스 위의 무제한 프로젝트. 이 세 가지가 결합할 때 어떤 가능성이 열리는지, InstantDB는 이미 실제 서비스로 증명하고 있어요.

아직 프로덕션 도입은 신중하게 접근해야 하지만, 적어도 사이드 프로젝트나 MVP에서는 한 번쯤 실험해볼 가치가 충분합니다.

마무리

AI가 코드를 짜는 시대에, 백엔드의 역할은 달라집니다.

복잡함을 숨기고, 추상화를 제공하고, 실수를 안전하게 되돌릴 수 있어야 해요. InstantDB가 4년 동안 만들어온 것은 단순한 개발 도구가 아니에요. AI 에이전트와 협업하는 새로운 백엔드의 형태입니다.

여러분이 다음 프로젝트에서 백엔드를 고민하고 있다면, 한 번은 이 방향도 생각해보세요. AI가 쓰기 좋은 백엔드가 결국 사람도 쓰기 좋은 백엔드가 될 수 있다는 것, 그게 InstantDB가 우리에게 던지는 핵심 메시지니까요.