데이터베이스, 정말 필요한 걸까? — 작은 프로젝트에서 DB 없이 살아남는 법

모든 프로젝트에 데이터베이스가 필요할까?

개발을 시작하면 거의 자동으로 "자, 이제 DB 뭐 쓸까?" 하고 고민하잖아요. PostgreSQL로 갈까, MySQL로 갈까, 아니면 요즘 핫한 MongoDB를 써볼까… 그런데 한 발짝 물러서서 생각해보면, 정말 모든 프로젝트에 데이터베이스가 필요한 걸까요? 이 질문을 진지하게 던져보는 글이 최근 개발자들 사이에서 흥미로운 논의를 만들어내고 있어요.

사실 많은 사이드 프로젝트나 소규모 서비스는 사용자가 수십 명에서 수백 명 수준이고, 데이터 양도 그렇게 많지 않거든요. 이런 상황에서 데이터베이스 서버를 띄우고, ORM을 세팅하고, 마이그레이션을 관리하는 게 오히려 배보다 배꼽이 더 큰 경우가 있어요.

데이터베이스 없이 데이터를 다루는 방법들

그러면 DB 없이 데이터를 어디에 저장하느냐, 이게 핵심인데요. 가장 단순한 방법은 파일 시스템을 직접 사용하는 거예요. JSON 파일이나 YAML 파일에 데이터를 저장하고, 필요할 때 읽어서 쓰는 방식이죠. 이게 뭐냐면, 우리가 설정 파일 다루듯이 데이터도 그냥 파일로 관리하는 거예요. 블로그 플랫폼 중에 Hugo나 Jekyll 같은 정적 사이트 생성기가 바로 이런 방식을 쓰고 있어요. 마크다운 파일 하나가 곧 하나의 게시글이 되는 거죠.

그다음으로 SQLite라는 선택지가 있어요. SQLite는 서버 없이 돌아가는 데이터베이스인데, 하나의 파일이 곧 데이터베이스 전체예요. 별도의 데이터베이스 서버를 설치하거나 관리할 필요가 없어서, "DB는 필요한데 인프라 관리는 하기 싫다"라는 상황에 딱 맞거든요. 실제로 모바일 앱들은 대부분 SQLite를 내장 데이터베이스로 쓰고 있고, 최근에는 서버 사이드에서도 SQLite를 적극적으로 활용하는 움직임이 늘고 있어요. Litestream 같은 도구를 쓰면 SQLite 파일을 실시간으로 S3에 백업할 수도 있고요.

또 하나 재미있는 방식은 인메모리 저장소예요. 서버가 뜰 때 데이터를 메모리에 올려놓고, 주기적으로 파일에 저장하는 방식이죠. 데이터 양이 적고 속도가 중요한 경우에 유용해요. 다만 서버가 죽으면 마지막 저장 시점 이후의 데이터는 날아갈 수 있다는 단점이 있어요.

그러면 데이터베이스는 언제 필요한 건가요?

여기서 중요한 건, "DB가 필요 없다"는 말이 아니라 "당장은 필요 없을 수도 있다"는 거예요. 데이터베이스가 진짜 필요해지는 시점이 있거든요.

첫 번째는 동시 접근이 많아질 때예요. 파일 시스템은 여러 프로세스가 동시에 같은 파일을 쓰려고 하면 문제가 생길 수 있어요. 데이터베이스는 이런 동시성 문제를 트랜잭션이라는 메커니즘으로 깔끔하게 처리해주죠. 트랜잭션이 뭐냐면, 여러 작업을 하나의 묶음으로 처리해서 "다 되거나, 아예 안 되거나" 둘 중 하나만 보장하는 거예요. 은행 송금할 때 내 통장에서는 빠졌는데 상대방 통장에 안 들어가는 일이 없도록 하는 것과 같은 원리예요.

두 번째는 복잡한 쿼리가 필요할 때예요. "지난 30일간 가장 많이 팔린 상품 카테고리별 Top 5를 구해줘" 같은 질문에 답하려면, JSON 파일을 일일이 읽어서 코드로 필터링하고 정렬하고 그룹핑하는 것보다 SQL 한 줄이 훨씬 효율적이거든요.

세 번째는 데이터 간의 관계가 복잡해질 때예요. 사용자가 있고, 그 사용자가 쓴 게시글이 있고, 그 게시글에 달린 댓글이 있고, 그 댓글에 대한 좋아요가 있고… 이런 관계형 데이터가 많아지면 파일 기반 저장소로는 한계가 와요.

업계에서 보이는 "탈 데이터베이스" 움직임

사실 이런 논의가 나오는 배경에는 업계의 큰 흐름이 있어요. 서버리스(Serverless)와 엣지 컴퓨팅이 대세가 되면서, 기존의 무거운 데이터베이스 서버를 유지하는 것이 아키텍처적으로 잘 안 맞는 경우가 늘어나고 있거든요.

Cloudflare의 KV나 Durable Objects, Vercel의 Edge Config 같은 서비스들은 전통적인 데이터베이스 없이도 엣지에서 데이터를 읽고 쓸 수 있게 해줘요. Turso 같은 서비스는 아예 SQLite를 엣지에 배포하는 방식을 제공하고요. 그리고 Firebase의 Firestore나 Supabase처럼 백엔드 없이 프론트엔드에서 바로 데이터를 다루는 BaaS(Backend as a Service) 모델도 전통적인 "내가 직접 DB를 세팅한다"는 개념을 흐리게 만들고 있죠.

반면에 PlanetScale이나 Neon 같은 서비스들은 기존 데이터베이스의 관리 부담을 줄이는 방향으로 가고 있어요. "DB가 필요하긴 한데, 관리가 귀찮다"는 문제를 해결하는 거죠. 결국 핵심은 데이터베이스 자체를 안 쓰는 게 아니라, 불필요한 복잡성을 줄이자는 거예요.

한국 개발자에게 주는 시사점

한국에서 사이드 프로젝트나 토이 프로젝트를 할 때, 습관적으로 RDS나 Cloud SQL 인스턴스를 먼저 만들곤 하잖아요. 그런데 사실 MVP 단계에서는 SQLite 하나로도 충분한 경우가 많아요. 특히 개인 프로젝트의 월 서버 비용을 아끼고 싶을 때, DB 서버 비용만 빼도 꽤 절약이 되거든요.

실무에서도 마찬가지예요. 어드민 페이지나 내부 도구처럼 사용자가 적고 트래픽이 낮은 서비스는 SQLite나 파일 기반 저장소로 시작해서, 트래픽이 늘어나는 시점에 데이터베이스로 마이그레이션하는 전략이 꽤 실용적이에요. "처음부터 완벽한 인프라"보다 "지금 필요한 만큼만"이라는 사고방식이죠.

다만 주의할 점도 있어요. 파일 기반 저장소는 백업과 복구 전략을 직접 짜야 하고, 데이터 정합성도 코드 레벨에서 보장해야 해요. 이걸 제대로 하지 않으면 나중에 큰 문제가 될 수 있으니, 장단점을 잘 따져보고 결정하는 게 중요해요.

정리하면

"최적의 데이터베이스는 없고, 최적의 선택만 있다." 중요한 건 기술 선택 자체가 아니라, 현재 프로젝트의 규모와 요구사항에 맞는 수준의 솔루션을 고르는 판단력이에요.

여러분은 새 프로젝트를 시작할 때 데이터 저장소를 어떻게 결정하시나요? 처음부터 DB를 쓰는 편인가요, 아니면 최대한 가볍게 시작하는 편인가요?