요금제를 올려도 아키텍처는 살 수 없다
무료 티어에서 걸린 문제들을 Pro 요금제로 올리면 몇 개가 사라질까. 세어보니 용량 문제는 전부 지워졌는데 블로커는 오히려 하나 늘었다. 돈으로 사는 것과 못 사는 것의 경계에 대한 기록.
무료 티어에서 걸린 문제들을 Pro 요금제로 올리면 몇 개가 사라질까. 세어보니 용량 문제는 전부 지워졌는데 블로커는 오히려 하나 늘었다. 돈으로 사는 것과 못 사는 것의 경계에 대한 기록.
잘 돌아가던 개인 프로젝트를 Vercel과 Supabase 무료 티어로 옮길 수 있을지 검토했다. 요금제 한도표부터 보는 대신 코드를 먼저 읽었고, 진짜 제약은 숫자가 아니라 실행 모델 쪽에 있었다.
Supabase를 처음 접하면 관리형 PostgreSQL 서비스로 이해하기 쉽습니다. 실제로 PostgreSQL은 Supabase의 중심이지만, 전체 제품은 데이터베이스보다 훨씬 넓은 범위를 다룹니다.
온프레미스에서 서비스를 운영하면 애플리케이션, 데이터베이스, Redis, WebSocket 서버와 백그라운드 워커를 한 네트워크 안에 둘 수 있습니다. 프로세스를 계속 띄워두기도 쉽습니다. setInterval로 10초마다 데이터베이스를 확인하는 코드도 일단은 잘 동작합니다.
백업이 성공했다는 알림은 데이터를 되살릴 수 있다는 보증이 아니다. 파일이 손상됐거나, 필요한 암호화 키가 없거나, 복구 순서를 아무도 모르면 백업은 있어도 업무를 재개할 수 없다. 사내 시스템의 백업 설계는 저장 횟수보다 복구 목표와 복원 시험에서 시작해야 한다.
사내 시스템은 직원 수가 적다고 해서 항상 가볍지 않다. 20명이 쓰는 문서 변환 시스템은 100명이 쓰는 단순 결재 시스템보다 더 많은 CPU와 저장 공간을 요구할 수 있다. 그래서 배포 구조는 인원수보다 동시 접속, 요청 시간, 파일 크기, 실시간 연결 수, 장애 허용 시간을 기준으로 정해야 한다.
웹과 모바일 앱을 함께 제공하는 서비스를 배포할 때는 화면을 올리는 비용만 계산해서는 안 됩니다. 데이터베이스, 캐시, 실시간 통신, 백그라운드 작업, 이미지 저장소까지 포함해야 실제 운영비에 가까워집니다.
사내 시스템을 만들 때 가장 자주 나오는 질문 중 하나는 "직원 수가 늘어나면 서버 비용도 같은 비율로 늘어나는가"입니다. Vercel과 Supabase 조합에서는 직원 수보다 배포를 관리하는 개발자 수, 동시에 발생하는 요청, 데이터베이스 쿼리와 배치 작업이 비용에 더 큰 영향을 줍니다.
사내 시스템을 새로 만들 때 인프라를 처음부터 크게 잡아야 할지 고민하게 됩니다. 특히 Supabase Pro를 검토하면 Micro와 Small의 월 비용 차이는 크지 않지만, 어떤 기준으로 선택해야 하는지는 가격표만 보고 판단하기 어렵습니다.
온프레미스 Docker로 돌아가던 서비스를 Vercel + Supabase로 옮기는 중이었습니다.