들어가며

최근 몇 달 간 소형 프로젝트를 여러 개 진행해보면서 어떻게 배포 구성을 가져갈지 고민을 많이 해보고 여러 가지를 사용해봤습니다. 사용하면서 느낀 점과 어떤 것이 더 좋다고 느꼈는지 정리해 봤습니다.

이 글은 다음 상황에 있으신 분들이 읽으면 좋습니다.

  1. 사이드/취미/스타트업 프로젝트를 처음 시작하시는 분
  2. Web + 서버 + RDB 조합의 프로젝트를 시작하시는 분

클라우드 : 대형 컴퓨팅 vs Function vs 신생

대형 클라우드

장점

  1. 보통 중소형 클라우드에 비해 좀 더 비쌉니다.
  2. 레퍼런스가 더 많고 커리어에 좀 더 도움됨

단점

  1. 배포가 보통 더 까다롭습니다.
  2. 보통 좀 더 비쌉니다.

대형 클라우드

장점

  1. 사용량 과금이라 비용 계산이 쉽고 저렴합니다.
  2. 프리 티어가 꽤 많습니다.

단점

  1. 런타임 특성상 추가적인 코드 작성이 필요합니다.
  2. 콜드 스타트 문제가 있습니다.

중소형 클라우드

장점

  1. 좀 더 저렴합니다.
  2. 프레임워크/언어 별로 특화된 부분이 있습니다.

단점

  1. 레퍼런스가 적습니다.
  2. 부가 기능이 없습니다.

서버리스 Function을 사용하지 않고 학습 목적을 배제한다면, 중소형 클라우드를 선택하는 것이 더 좋다고 생각합니다. Fly.io, netlify, vercel을 사용해봤는데 AWS를 사용했을 때에 비해 배포가 굉장히 편리했습니다. 레퍼런스가 없다는 점은 공식 문서가 굉장히 잘 나와 있어서 생각보다 문제가 되지 않았습니다. 비용 측면에서도 Hobby 플랜(Vercel, fly.io 등)이 있고 좀 더 저렴해서 좋았습니다. 서버리스의 경우 일반적인 HTTP 서버 코드를 작동시키기 위한 추가 코드가 적다면 괜찮습니다. 그게 어렵다면 고려할 이유가 없습니다. 중소형 클라우드와 서버리스 Function를 비교하면 저는 비용 측면에서 마음이 편해서 서버리스 Function이 좋았습니다. 게다가 저는 python을 주로 사용하는데 python은 Magnum이라는 AWS Lambda 어댑터가 있어서 추가 코드가 적습니다. 결론적으로 서버리스 Function vs 중소형 클라우드는 취향 차이인 것 같습니다.

데이터베이스

  1. 대형 Cloud(AWS, GCP, Azure, Naver …)
    1. 경우에 따라 다르지만 10만원 이상이 기본적으로 들어감
  2. supabase, vercel
    1. 초저사양은 무료로 가능한 것이 장점
  3. SQLite + Litestream(LiteFS)
    1. 기본적으로 단일 인스턴스로만 가능함
    2. 추가 비용이 없고 운영/개발이 매우 쉬움 일단 데이터베이스의 경우, 대형 클라우드의 서비스(AWS RDS, Azure SQL, …)은 우선순위가 많이 밀립니다.. 가장 저성능의 구성으로도 한 달 10만원이 넘는 것이 보통이라 매우 비쌉니다. SQLite + Litestream 구성이나 중소 클라우드에서 선택해볼 수 있습니다.

SQLite + Litestream 구성

장점

  1. 인스턴스를 따로 쓰지 않아 추가 비용 없음
  2. 단일 파일 데이터베이스라서 운영, 개발이 쉬움
    1. 백업, 롤백이 복사, 붙여넣기, 업로드, 다운로드 한 번으로 끝나는 게 생각보다 굉장한 이점입니다.

단점

  1. 수평 스케일링이 불가능
    1. Fly.io에서 Litestream 대신 LiteFS를 사용하면 가능하긴 합니다.
  2. SQLite 생태계가 좀 더 작음

Vercel Postgres, Supabase

장점

  1. 서비스가 커져도 데이터베이스 벤더는 동일함
  2. Supabase의 경우 부가 기능을 쓸 수 있습니다.
    1. 인증 구현이 편한 점이 제일 큽니다.
    2. 혼자 운영한다면 Dashboard로 Admin을 어느 정도 갈음할 수도 있고요.

단점

  1. 연결 관리 등 운영, 개발에 신경써야 할 부분이 더 많음

Supabase가 제일 좋다고 생각합니다. 인증 구현이 포함되어 있다는 점과 대시보드 기능이 너무 압도적입니다. SQlite + Litestream 구성이 더 저렴하지만 supabase의 부가 기능을 경험해보니 SQLite + Litestream을 쓸 생각이 안 납니다. 자체적으로 프로젝트 템플릿 구성이 되어 있다면 생각이 달라질 수도 있겠지만, 그 수준이 애매하다면 고민할 필요 없이 Supabase를 추천합니다. 소소하지만 스케일링이 편하다는 장점도 있습니다.

캐시

  1. 쿠키 세션으로 가능하다면 쿠키 세션으로
  2. 인메모리는 개인적으로 선호하지 않음
    1. 모니터링하기 까다로움
  3. 정말 필요한지 고민해봐야 함
    1. 이미 취미의 영역을 벗어난 서비스가 아닐까? 캐시의 경우 추가 비용이 전혀 없는 쿠키로 하는 것이 가장 좋습니다. 기능이 제한적이긴 하지만 시작하는 사이드 프로젝트에서 추가로 캐시를 쓸 정도로 트래픽이 몰릴 가능성은 없으므로 무조건 쿠키가 좋습니다.

기타

  1. k8s : 체계적인 배포, 생태계 이점이 매우 커서 서비스가 조금 커지면 최우선적으로 고민해야 한다고 생각합니다. 하지만 비용 문제로 시작할 때는 좋지 않아보입니다.
  2. padman/docker compose : 서버 인스턴스에 데이터를 저장하는 점이 불안하다고 생각해서 배제했습니다.

결론

결론적으로 프로젝트를 새로 시작한다면, AWS Lambda + supabase + 세션 쿠키 방식이 개인적으로 가장 좋은 것 같습니다. 프로젝트를 새로 시작한다면 이 구성으로 진행할 계획입니다.