Supabase가 SQLite를 품는다면: AI 에이전트가 바꾸는 DB 경제학

핵심 요약

• Supabase는 Postgres 기반 플랫폼이고, Turso는 SQLite 계열 기술에서 출발했습니다.
• SQLite는 애플리케이션 안에서 실행할 수 있어 별도 데이터베이스 서버 없이도 데이터를 다룰 수 있습니다.
• 에이전트가 작업마다 데이터베이스를 만든다면 생성·복제·폐기에 드는 비용도 더 중요해집니다.
• 서비스의 핵심 데이터와 에이전트의 임시 작업 데이터는 서로 다른 방식으로 저장할 수 있습니다.

AI 에이전트에게 여러 단계의 일을 맡기면 중간 결과를 어디에 보관할지 정해야 합니다. Postgres 기반의 Supabase가 SQLite 계열의 Turso까지 아우른다고 가정해 보겠습니다. 이런 상황에서는 에이전트의 데이터 보관 방식이 데이터베이스 사업에도 영향을 줍니다. 저장하는 데이터의 양과 함께 얼마나 자주 만들고 지우느냐도 중요해집니다.

Postgres와 SQLite, 데이터를 담는 방식부터 다릅니다

Postgres는 서버로 실행되는 데이터베이스입니다. 여러 애플리케이션과 사용자가 접속해 데이터를 읽고 씁니다. 주문 내역처럼 여러 사람이 함께 쓰는 데이터를 일관되게 관리하는 데 잘 맞습니다.

SQLite는 애플리케이션 안에 넣어 실행할 수 있는 데이터베이스입니다. 별도 서버 프로세스 없이 파일에 데이터를 저장하고 SQL로 조회할 수 있습니다. 작은 프로그램도 데이터베이스를 프로그램의 한 부품처럼 쓸 수 있습니다.

물론 SQLite 계열 기술을 쓴다고 해서 서비스 전체가 로컬 파일 하나로 돌아가는 것은 아닙니다. Turso 같은 플랫폼을 평가할 때는 원격 접근과 복제 등 서비스가 제공하는 기능도 함께 봐야 합니다. 엔진의 특성과 서비스의 운영 비용은 나눠서 따져봐야 합니다.

두 방식을 함께 제공하는 플랫폼이라면 고객은 데이터의 용도에 맞춰 저장 방식을 고르기가 더 수월해집니다.

에이전트에게도 작업용 노트가 필요합니다

보고서를 만드는 에이전트는 문서에서 뽑은 문장과 계산 중간값을 보관해야 합니다. 어떤 항목을 이미 처리했는지도 기억해야 하고, 작업이 중단되면 어디부터 다시 시작할지도 알아야 합니다.

이런 정보는 고객 계정이나 결제 기록과 보관 기간이 다를 수 있습니다. 보고서를 완성하면 대부분 버려도 되는 데이터가 있는가 하면, 검토를 위해 일정 기간 남겨야 하는 데이터도 있습니다.

예를 들어 에이전트 100개가 각각 독립적으로 분석한다고 가정해 보겠습니다. 하나의 Postgres 데이터베이스에 작업 번호로 데이터를 구분해 넣을 수도 있고, 각 작업에 작은 SQLite 데이터베이스를 붙일 수도 있습니다.

하나의 데이터베이스에 모으면 중앙에서 관리하기 편합니다. 작업마다 데이터베이스를 붙이면 작업 데이터 전체를 한 단위로 옮기거나 폐기하기 편할 수 있습니다. 다만 파일을 나눴다는 이유만으로 접근 권한 문제가 해결되거나 실행 환경까지 격리되는 것은 아닙니다.

어느 쪽이 유리한지는 작업끼리 데이터를 공유하는지, 여러 실행 주체가 동시에 수정하는지에 달려 있습니다.

비용 계산에 ‘만들고 버리는 횟수’가 들어옵니다

데이터베이스 비용을 생각하면 저장 용량과 서버 크기가 먼저 떠오릅니다. 에이전트가 짧은 작업을 반복한다면 여기에 더해 계산할 비용이 있습니다.

작업을 시작할 때 저장 공간을 준비하는 데 걸리는 시간부터 따져야 합니다. 같은 초기 데이터로 실험을 반복할 때 드는 복사 비용도 있고, 작업이 끝나면 데이터와 권한을 정리하는 일도 남습니다.

실제 분석이 몇 초 만에 끝난다면 저장 환경을 준비하는 시간이 전체 작업에서 큰 비중을 차지할 수 있습니다. 작업 수가 늘수록 이런 작은 비용도 쌓입니다.

SQLite를 실행 환경에 포함하면 별도 데이터베이스 서버를 띄우는 절차를 줄일 수 있습니다. 대신 파일을 어디에 보관하고 어떻게 백업할지 정해야 합니다. 동시 쓰기와 장애 복구를 처리할 방법도 필요합니다. 원격 서비스로 제공한다면 네트워크와 복제 비용도 따져야 합니다.

그래서 SQLite를 쓰면 무조건 싸진다고 단정할 수는 없습니다. 같은 작업을 끝내고 필요한 데이터를 보존하는 데 드는 총비용을 비교해야 합니다.

Postgres에서도 하나의 서버에 여러 작업의 데이터를 모아 비용을 나눌 수 있습니다. 작업마다 독립적인 데이터베이스가 필요한지부터 따져봐야 비용을 제대로 계산할 수 있습니다.

함께 제공한다면, 고객의 선택 범위가 넓어집니다

Postgres 기반 플랫폼이 SQLite 계열 기술까지 제공한다면 고객은 더 다양한 작업을 이 플랫폼에 맡길 수 있습니다. 사업에서도 그만큼 다룰 수 있는 작업의 범위가 넓어집니다.

사용자 계정과 결제 내역은 Postgres에 두고, 에이전트가 잠깐 쓰는 분석 데이터는 작업 환경 가까이에 둘 수 있습니다. 검토가 끝난 결과만 서비스의 핵심 데이터베이스에 반영하도록 구성할 수도 있습니다.

이때 플랫폼의 가치는 데이터베이스 종류만 늘린다고 높아지지는 않습니다. 작업 데이터가 어디에 있는지 추적하고 접근 권한을 부여할 수 있어야 합니다. 필요한 결과를 안전하게 옮기는 기능도 갖춰야 합니다. 데이터가 여러 곳에 나뉠수록 이런 관리 기능이 더 중요해집니다.

저는 이 조합으로 데이터의 수명에 맞는 선택을 할 수 있다는 점에 끌립니다. 오래 보존할 기록과 잠깐 쓸 작업 데이터를 각각 알맞은 방식으로 다룰 수 있기 때문입니다.

에이전트가 작업별로 저장 공간을 쓰는 경우가 늘어난다면, 데이터베이스를 얼마나 쉽게 만들고 정리할 수 있는지가 경쟁에서 더 중요해질 수 있습니다. Postgres와 SQLite의 조합을 살펴볼 때도 이 점을 따져볼 수 있습니다. 에이전트가 만드는 데이터가 오래 보관할 기록인지, 작업이 끝나면 정리할 노트인지에 따라 선택은 달라질 수 있습니다.