데이터베이스는 정답이 아니라 타이밍이다. DB Pro 벤치마크 글 번역

데이터베이스는 정답이 아니라 타이밍이다

작은 서비스를 만들 때, 우리가 너무 빨리 무거운 답을 고르는 이유

서비스를 만들기 시작하면 이상하게도 사람보다 테이블이 먼저 생긴다.

아직 사용자는 한 명도 없는데 users 테이블부터 만들고, 아직 주문은 한 건도 없는데 orders 구조를 정한다.

기능은 겨우 두세 개인데도, 우리는 너무 자연스럽게 데이터베이스부터 붙인다. 마치 그것이 서비스를 만드는 사람의 기본 자세인 것처럼.

 

그런데 가끔은 그 익숙한 순서를 의심해볼 필요가 있다.

정말로, 처음부터 데이터베이스가 필요할까.

이 질문은 생각보다 불편하다. 데이터베이스는 너무 오랫동안 “당연한 출발점”이었기 때문이다. 서비스 개발을 배울 때도, 실무에서 프로젝트를 시작할 때도, 우리는 거의 반사적으로 DB부터 떠올린다. PostgreSQL을 쓸지, MySQL을 쓸지, ORM은 무엇으로 갈지부터 정하고 나서야 비로소 서비스를 만든다는 기분이 든다.

 

하지만 조금만 물러서서 보면, 이 질문은 꽤 현실적이다.

데이터베이스도 결국은 데이터를 저장하고 읽어오는 시스템이다. 물론 그 위에는 인덱스가 있고, 검색이 있고, 동시성 제어가 있고, 트랜잭션이 있다. 중요한 건 바로 그 지점이다. 데이터베이스가 강력한 이유는 기능이 많기 때문이고, 동시에 무거운 이유도 기능이 많기 때문이다.

그래서 더 정확한 질문은 이것인지도 모른다.

지금 내 서비스는 정말 데이터베이스의 기능을 필요로 하고 있는가.

이 질문을 던지면 풍경이 조금 달라진다.

우리가 처음 만드는 많은 서비스는 생각보다 단순하다. 사내에서 잠깐 쓰는 관리 도구일 수도 있고, 혼자 운영하는 작은 웹서비스일 수도 있고, 핵심 기능만 빠르게 검증해야 하는 MVP일 수도 있다. 이런 단계에서는 데이터의 양보다 중요한 것이 더 많다. 빨리 만들어 보는 것, 실제로 사람들이 쓰는지 확인하는 것, 기능이 필요한지 아닌지 판단하는 것이 먼저다.

 

이때 가장 비싼 비용은 인프라 비용이 아니라, 복잡성을 유지하는 비용이다.

처음부터 너무 많은 구조를 들여오면 개발자는 제품보다 구조를 관리하게 된다. DB를 세팅하고, 마이그레이션을 관리하고, 운영 환경을 따로 나누고, 연결 이슈를 보고, 예외를 처리하고, 백업을 고민한다. 물론 언젠가는 필요한 일들이다. 하지만 중요한 건 “언젠가”와 “지금”은 다르다는 사실이다.

 

작은 서비스에서 파일 저장은 생각보다 오래 버틴다.

가장 단순한 방법은 데이터를 파일에 그대로 저장해두고, 필요할 때마다 읽는 것이다. 처음엔 투박해 보인다. 하지만 기능 검증이 목적이라면, 이 단순함은 꽤 강한 무기가 된다. 구현은 빠르고, 구조는 눈에 잘 들어오고, 디버깅도 쉽다. 특히 조회가 단순하고 데이터 규모가 작다면 파일 기반 저장만으로도 예상보다 오래 서비스를 굴릴 수 있다.

조금 더 나아가면 선택지는 늘어난다.

 

서버가 시작할 때 파일 전체를 메모리에 올려두고 조회를 메모리에서 처리할 수도 있다. 그러면 읽기 속도는 훨씬 빨라진다. 데이터를 정렬하고 인덱스를 따로 만들어 필요한 위치만 찾는 방식도 가능하다. 여기까지 오면 파일 저장은 더 이상 “원시적인 방법”이 아니라, 꽤 영리한 전략처럼 보인다.

하지만 바로 여기서 놓치면 안 되는 사실이 있다.

파일 저장이 생각보다 강력하다는 말과,
그래서 데이터베이스가 필요 없다는 말은
전혀 다르다는 것.

 

https://gitstar.space

GitStar - GitHub Rankings, Package Signals, and Weekly Digests

 

 

처음에는 사용자 한 명을 ID로 찾는 것만으로도 충분할 수 있다. 그런데 서비스는 아주 평범한 방식으로 복잡해진다. 사용자별 주문 목록을 보고 싶어지고, 날짜 기준으로 정렬하고 싶어지고, 가격 조건으로 필터링하고 싶어지고, 관리자 화면에 검색 조건이 늘어난다. 여기에 정산, 통계, 배치 작업이 붙고, 어느 순간 여러 서버가 동시에 같은 데이터를 만지기 시작한다.

실무에서 데이터베이스가 필요해지는 이유는
대개 데이터가 너무 많아져서가 아니다.

오히려 질문이 많아지기 때문이다.

한 건 조회만 하던 시스템은 곧 목록을 원한다.
목록은 필터를 원하고,
필터는 정렬을 원하고,
정렬은 조합을 원한다.

그 순간부터 우리는 단순한 저장이 아니라 질서를 필요로 하게 된다.

 

데이터베이스의 가치는 바로 그 질서에 있다. 검색을 쉽게 하고, 여러 요청이 동시에 와도 데이터가 덜 꼬이게 만들고, 여러 작업이 함께 성공하거나 함께 실패하도록 묶어준다. 다시 말해, 데이터베이스는 단순한 저장소라기보다 운영의 안전장치에 가깝다.

그래서 이 문제는 “파일이냐 DB냐”의 취향 싸움이 아니다.
더 정확히 말하면, 복잡성의 타이밍에 대한 문제다.

작은 서비스는 생각보다 오랫동안 단순하다.
그리고 그 단순함을 인정하는 태도는 종종 좋은 시작을 만든다.

 

처음부터 무거운 답을 고르지 않는 것.
필요한 만큼만 가져가는 것.
제품이 맞는지 아직 모르는 단계에서, 지나치게 완성된 구조를 먼저 짓지 않는 것.

이건 게으름이 아니라 판단이다.

반대로 이미 복잡해진 문제를 계속 작은 도구로 버티는 것도 좋은 선택은 아니다. 검색 조건이 늘고, 여러 데이터를 함께 다뤄야 하고, 실패했을 때 되돌릴 수 있어야 하고, 서버가 여러 대로 늘어난 상황이라면 더 이상 파일 저장의 단순함이 미덕이 아니다. 그때는 SQLite든, PostgreSQL이든, 제대로 된 데이터베이스로 넘어가는 편이 전체 비용을 줄인다.

결국 중요한 건 하나다.

처음은 가볍게 가되,
나중에 쉽게 옮길 수 있게 만드는 것.

파일 저장으로 시작할 수 있다.
SQLite로 버틸 수도 있다.

그리고 정말로 검색, 조인, 동시성, 운영 안정성이 중요해지는 순간이 오면 그때 본격적인 데이터베이스로 넘어가면 된다.

좋은 설계는 미래를 과하게 상상하는 데서 오지 않는다.
오히려 지금의 문제를 정확하게 읽는 데서 온다.

그래서 서비스를 시작할 때 우리가 던져야 할 질문은 이것인지도 모른다.

데이터베이스를 쓸까, 말까.

그 질문보다 먼저,

지금 내 서비스는 정말로 데이터베이스의 기능을 필요로 하고 있는가.

이 질문에 솔직하게 답할 수 있다면,
우리는 조금 더 가볍게 시작할 수 있고,
조금 더 좋은 타이밍에 다음 선택을 할 수 있다.

그리고 아마 그게, 작은 서비스를 더 오래 살아남게 만드는 방식일 것이다.