Til - 초기 서비스 데이터베이스 선정의 기준

기준이 없어도 되지만…

  • 두 가지 길이 있는 것 같다. 초기 서비스의 상태를 탈피했을 때에도 유지 가능한 인프라를 고르는 방법이 있고, 초기 서비스의 상태일 때만 괜찮은 인프라를 고르는 방법 말이다.
  • 예를 들어 명목상 Scaling이 가능한 서비스들이 있다. 워드프레스도 그렇고, 버블도 그렇고, 훨씬 더 많은 노코드 툴이나 신규 백엔드 서비스들이 있고 계속 나오고 있다.
  • 그러나 이들 툴 모두가 모든 서비스와 도메인에서 Scaling 가능한 것은 아니다.
    • 서비스 유지보수가 어렵거나 (예를 들어 코드 확장이 어려운 노코드 서비스가 있다.)
    • 추후 비용이 너무 많이 들거나 (예를 들어 노코드 툴은 Scaling 했을 때 비용이 10배씩도 비싸질 수 있다. 경우에 따라 다르다.)
    • 개발 팀 내지 인력과 성격이 안 맞거나 (예를 들어 한국 개발자들에게 가장 익숙한 클라우드 인프라는 일률적으로 AWS다.)
    • 요구사항에 대응할 수 없게 된다. 채팅 기능을 추가하고 싶을 때는 어떻게 하지? 폼 기능을 추가하고 싶을 때는 어떻게 하지? 물론 기본적인 기능들은 노코드 환경에서도 대부분 구현이 가능하다. 그러나, 조금만 고급화된 기능을 필요로 하는 순간 뭔가 아니라는 느낌을 받을 수 있다. 개발자 입장에서 그럴 가능성이 있다.

새로운 기술이 최고의 기술이 아니다.

  • MongoDB는 MySQL에 비하자면 아주 늦게 나온 신참이다. NoSQL 문서 데이터베이스라는 특별한 컨셉을 가지고 있다.
  • 그러나 왠만하면. 아주 명확한 이유를 알고 있지 않다면 무턱대고 MongoDB를 쓰지 말아야 한다. 왜냐, 거의 모든 서비스와 모든 도메인과 모든 데이터셋에 ‘관계’가 표현될 수 있고 이를 통해 쿼리가 효율화될 여지가 있기 때문이다. 관계형 데이터베이스를 쓰는 게 낫다.
  • PostgreSQL은 어떨까? MySQL과 똑같은 관계형 데이터베이스이지만, 안정성과 확장성 측면에서 MySQL의 손을 들어 주는 사람들도 여전히 엄청나게 많다. PostgreSQL은 오픈소스 커뮤니티와 스타트업 커뮤니티에서 유망한데, MySQL보다 좋은 게 아니라 서로 좋은 점이 다르다고 한다.
    • 예를 들어 PostgreSQL은 Full Text Search 같은 기능을 MySQL보다 먼저 지원했다.
    • Notion의 데이터베이스는 PostgreSQL이며 AWS RDS 인프라를 통해서 구동되고 있다.
  • PlanetScale, Supabase, Hasura 등 아름답고 번지르르 해보이는 서비스들이 많다. 내가 필요로 하는 기능이 진짜로 있는 지, 쓸 줄 아는지, 배울 생각인지 등 고려해서 선택하면 좋을 것이다.

무엇을 쓰기로 했는지는 안 중요하다. 팀이 유지보수 할 줄 안다면 말이다.

  • MAU 1억건 이상을 달성한 remoteok는 SQLite를 쓰고 있다. 심지어 서버 한 대에서 여러 서비스를 구동하고 있다. 그 흔한 마이크로서비스 아키텍쳐도 안 쓰고 있다. PMF를 상회하는 성과를 낼 때까지 개발자가 단 한명이었다. 문제가 없었다. 그 기술로도 어떤 사람은 99.9% 이상의 가용성을 확보했다.

진짜로 안 중요하지만, 만약 의사결정 비용이 그리 크지 않다면, 한 번 더 생각해서 고르면 먼 길을 쉽게 갈 수도 있을 지 모른다.

1개의 좋아요