매주 100만 개, 1.5억 달러 투자: Supabase가 Turso를 사서 에이전트용 데이터베이스에 건다

에이전트에게 "고객 문의 정리용 앱 하나 만들어 줘"라고 시키면 앱 한 개만 나오지 않는다. 데이터를 담을 데이터베이스도 같이 생긴다. Supabase는 자기 플랫폼에서 이미 매주 100만 개 이상의 데이터베이스가 만들어진다고 밝혔다. 그 수요를 겨냥해 SQLite를 Rust로 다시 쓴 Turso 인수를 추진한다.

발표는 10월 2일이다. 같은 날 Supabase는 싱가포르 GIC가 이끈 1.5억 달러 투자를 공개했다. 알파벳의 CapitalG도 참여했다. 인수 금액은 알려지지 않았다. Turso 창업자 글라우버 코스타와 페카 엔베리는 Supabase에 합류하고 코스타가 에이전트용 인프라 사업을 맡는다.

한 줄 정리

Supabase가 Postgres 옆에 SQLite 계열 Turso를 붙여서 에이전트가 쏟아내는 수백만 개의 일회용 데이터베이스를 받겠다고 나섰다.

한눈에 보기

항목	Supabase	Turso
기반	Postgres	SQLite를 Rust로 재작성
잘하는 일	오래 가는 서비스 본체	한 서버에서 수백만 개의 작고 가벼운 데이터베이스
에이전트 쪽 용도	정식 앱의 저장소	시제품, 탐색용 대시보드, 임시 작업 공간
인수 후	에이전트 인프라 사업 신설	기존 사용자는 당장 변화 없음, 독립 운영 계속
같이 나온 것	Compute: 오래 도는 에이전트용 호스팅 샌드박스	해당 없음

데이터베이스가 소모품이 된다

사람이 소프트웨어를 만들 때 데이터베이스는 신중하게 하나 고르는 부품이었다. 에이전트는 다르다. 시제품 하나, 탐색 한 번, 대시보드 하나마다 새로 만들고 쓰고 버린다. Supabase 공동창업자 폴 코플스톤의 표현으로는 에이전트가 시제품과 탐색과 대시보드와 앱을 만들면서 데이터베이스를 수백만 개씩 띄운다.

이 패턴에서 Postgres 서버를 하나씩 켜는 방식은 비용도 시간도 맞지 않는다. 파일 하나로 도는 SQLite 계열이 훨씬 가볍다. Turso가 노린 지점이 그 가벼움이고 Supabase가 돈을 낸 이유도 거기에 있다. 두 제품은 용도가 달라서 Turso는 SQLite, Supabase는 Postgres로 나란히 간다.

같은 주에 나온 신호들

이번 주 ChatGPT는 말로 사이트를 만들어 저장소와 데이터베이스까지 붙여 주는 Sites를 열었다. 쇼핑몰 빌더, 업무용 에이전트, 사이트 빌더가 한꺼번에 "만들어 주는 쪽"으로 몰린다. 만들어진 것들은 전부 어딘가에 데이터를 둬야 한다. 만드는 층이 두꺼워질수록 뒤에서 저장을 받아 주는 층의 주문이 늘어난다.

반대 방향의 위험도 있다. 에이전트가 만든 데이터베이스 수백만 개 중 누가 주인인지 모르는 것이 대부분이 된다. 정리 주기, 백업, 접근 권한을 누가 맡느냐는 인수 발표문에 없다.

같이 나온 Compute가 말해 주는 것

Supabase는 인수와 함께 Compute도 내놓았다. 오래 도는 에이전트를 위한 호스팅 샌드박스다. 데이터베이스만 늘리는 게 아니라 에이전트가 일하는 공간 자체를 한 회사에서 빌려 주겠다는 구도다. 저장소와 실행 환경이 한 곳에 있으면 에이전트가 만든 앱은 그 플랫폼 안에서 살고 죽는다.

작은 팀에는 양날이다. 설정할 게 줄어드는 대신 옮겨 가기 어려워진다. Turso가 오픈소스 기반이라 데이터 이동 경로는 열려 있지만 샌드박스 설정까지 따라오지는 않는다. 처음 도입할 때 나갈 길을 한 번 적어 두면 나중에 값이 오르거나 정책이 바뀌어도 협상할 여지가 남는다.

콘텐츠 제작이나 마케팅 대행처럼 개발 인력이 없는 팀은 이런 인프라를 직접 고를 일이 드물다. 그래도 쓰는 에이전트 도구가 뒤에서 어떤 저장소를 쓰는지는 물어볼 수 있다. 질문 하나로 계약서의 데이터 위치 조항을 지킬 수 있는지 갈린다.

위시클레이 관점

콘텐츠 에이전시가 에이전트로 고객사별 성과 보드를 열 개 만든다고 하자. 보드마다 데이터베이스가 하나씩 생기고 그중 서너 개는 3주 뒤 아무도 열지 않는다. 열 개의 청구서는 작지만 고객 이름과 광고 성과가 든 열 개의 저장소는 작지 않다. 비용은 가볍고 책임은 무겁다.

그래서 이 뉴스에서 챙길 건 가격이 아니라 목록이다. 에이전트에게 앱을 만들게 하는 팀이라면 만들어진 데이터베이스를 한곳에서 볼 수 있는지부터 확인하는 게 순서다. 만드는 속도가 사람의 점검 속도를 앞지르면 "누가 만들었는지 모르는 저장소"가 사고의 출발점이 된다.

인프라는 빌려 쓰는 게 맞다. 다만 빌려 쓴 인프라 위에 쌓이는 데이터의 주소록은 빌릴 수 없다. 에이전트 하나당 데이터베이스 하나라는 규칙을 둘지, 프로젝트당 하나로 묶을지 지금 정해 두면 100만 개 단위로 늘어나는 세계에서도 우리 쪽 숫자는 두 자릿수에 머문다.