2편에서 제품에 쓸 기술 스택을 고르는 동안, 어느 인프라를 사용할지 고민하고 있었습니다. Laravel이라면 저렴한 해외 VPS를 쓰고, .NET이라면 애저를 사용합니다. PHP/Laravel용 저렴한 해외 VPS 호스팅 업체는 많고, .NET은 애저와의 통합이 매끄럽기 때문입니다. 다른 방법으로는 AWS Lightsail로 출발해 규모에 맞춰 AWS로 옮겨 가는 것도 가능합니다. Lightsail은 AWS의 다른 서비스로 확장, 이전하는 도구를 잘 갖추고 있습니다. 모두 합리적인 선택이라 생각했습니다. 하지만 기술 스택을 TypeScript 풀스택으로 결정하면서 인프라도 처음부터 다시 생각하게 됐습니다.
반복 실험을 방해하는 고정비
1인 창업은 여러 실험을 빠르게, 그것도 반복해서 돌려 봐야 하는 일입니다. 이 관점에서 다시 보니 VPS와 AWS의 복잡한 관리 요소, 그리고 만만치 않은 고정비가 부담으로 다가왔습니다. 서버를 띄워 두는 것만으로 매달 비용이 빠져나가는 구조는, 성공을 장담할 수 없는 실험을 여러 번 시도해야 하는 상황과는 잘 맞지 않습니다. 게다가 이 비용은 프로젝트 수만큼 쌓입니다. 사용자가 없는 MVP 하나를 더 띄우는 것만으로도 고정비가 따라 붙어서, 시도 횟수를 늘릴수록 청구서도 같이 불어납니다.
그래서 기준을 바꿔 초기 고정비가 없거나 적어서 부담 없이 몇 번이고 다시 실행해 볼 수 있는 서버리스 제품이 낫다고 판단했습니다. 유휴 상태에서는 비용이 0으로 내려가고(scale-to-zero) 트래픽이 붙을 때만 과금되는 구조라면, 실험의 문턱이 크게 낮아집니다.
물론 AWS, 애저, GCP 3대 클라우드도 서버리스를 제공합니다. 다만 MVP 하나를 굴리기에는 앞서 말한 관리 요소와 고정비 부담이 여전해서, 좀 더 가벼운 업체를 고를 필요가 있었습니다.
편리함이 부르는 확장 부담
서버리스 업체는 결이 제각각입니다. 컴퓨팅, 스토리지, 데이터베이스, CDN 같은 인프라 중심 업체가 있는가 하면, 인증, 메일, 검색, CMS, 결제 같은 서비스 중심 업체도 있습니다. 분류 기준도 많고 저마다 커버리지가 달라서, 이름값만으로 줄을 세우기가 어렵습니다.
파이어베이스와 슈파베이스는 인증, DB, 스토리지, 함수를 하나로 묶은 균형 잡힌 BaaS(Backend as a Service)로 평판이 좋습니다. 특히 초기 프로젝트를 빠르게 구현할 수 있는데, 무엇보다 귀찮고 까다로운 인증 시스템을 손쉽게 통합할 수 있다는 것이 장점입니다.
문제는 그다음입니다. 인증 시스템이 내재화되지 않고 핵심 비즈니스 로직을 서버리스 함수에 기대야 한다는 점은, 훗날 서비스를 확장하거나 이전할 때 만만치 않은 비용으로 돌아옵니다. 파이어베이스로 초기 구성을 하고 성장하면서 자연스럽게 GCP로의 확장을 생각해 볼 수 있습니다. 하지만 회사에서 볼륨 있는 프로젝트로 몇 차례 시도해 본 경험을 떠올리면, 과금이 특별히 저렴하지도 않았고 확장을 위한 DB 재설계와 앱 아키텍처 변경 등 이전에 드는 리팩터링 비용이 상당했습니다.
파이어베이스나 슈파베이스를 큰 아키텍처 변경 없이 끝까지 쓸 수 있고 과금도 감당 가능한 수준이라면, 나쁘지 않은 선택입니다. 다만 점진적 개선과 확장을 위한 리팩터링을 지향하는 방향과는 맞지 않아서, 데모나 토이 프로젝트 정도로만 권할 만합니다.
참고로 Clerk, Auth0 같은 인증 서비스도 초기 편리함과 무료 티어만 보고 택하기보다는, 같은 이유에서 BetterAuth로 자체 호스팅해 내재화하고 SMTP 릴레이 정도만 외부 서비스를 쓰는 편이 낫습니다.
Vercel과 Netlify는 좋은 개발자 경험으로 인기가 많습니다. 웹을 호스팅하기에 최적화되어 있고 서버리스 함수도 갖췄지만, 범용 컴퓨팅 인프라로 보기에는 아쉬운 구석이 있고 자체 데이터베이스가 없어 외부 서비스를 빌려 써야 합니다. 거기에 이따금 들려오는 Vercel의 과금 이슈는, 그럴 만한 사정이 있다 해도 1인 개발자에게는 괴담처럼 들려 막연한 거부감을 남겼습니다.
이처럼 업체마다 커버리지와 장단점이 갈리다 보니, 여럿을 조합해 쓰면 이번에는 관리 요소가 불어납니다. 그나마 커버리지가 넓은 파이어베이스도 인증 내재화라는 숙제가 남아 고민이 이어졌습니다. 결국 더 범용적이면서 저렴하고, 적용 범위까지 넓은 서버리스 플랫폼 하나가 필요했습니다.
클라우드플레어 하나로
그러다 예전에 찜해 두고 잊고 있던, 개발자를 위한 클라우드플레어를 다룬 영상 하나가 눈에 들어왔습니다. 그동안 클라우드플레어는 CDN과 DDoS 방어, GitHub Pages 비슷한 Pages 정도로만 알고 있었는데, Cloudflare Developer Platform은 그보다 훨씬 넓은 개발 플랫폼이었습니다.
혼자서도 컴퓨팅부터 DB, KV(키-값 저장소), 스토리지까지 한 플랫폼에서 한 번의 배포로 끝낼 수 있어 따로 조립하고 운영할 것이 거의 없었습니다. 실시간 통신과 WebSocket은 Durable Objects로 처리합니다. 유휴 시 scale-to-zero로 내려가고, egress(데이터 송신)가 무료이며, 기본 DDoS 방어가 포함되고, 요금이 예측 가능해 청구 폭탄을 걱정할 일이 적었습니다. 여기에 더해, 요금이 프로젝트가 아니라 계정 단위로 매겨진다는 점이 컸습니다. 요구사항에 맞춰 무료 플랜이나 월 5달러 유료 플랜 하나로 MVP를 몇 개든 얹을 수 있으니, 시도 횟수가 곧바로 비용으로 불어나지 않습니다. 반복 실험을 전제로 하는 1인 창업에는, 이만큼 마음 편한 비용 구조도 드뭅니다. 엔터프라이즈급 시스템이 필요한 서비스가 아니라면, 클라우드플레어만으로도 상당한 수준의 요구사항까지 수용할 수 있어, 서비스를 운영하는 동안 확장이나 이전을 위해 구조를 크게 손볼 일이 많지 않습니다.
아쉬운 점이 없지는 않습니다. D1이 SQLite라는 점, 하위 플랜에서는 서울 엣지가 보장되지 않는다는 점, 조직 단위 관리 개념이 아직 자리 잡지 않았고 개발자 경험도 최상급이라 하긴 어렵다는 점이 그렇습니다. 그럼에도 비용 걱정 없이 반복 가능한 1인 창업이라는 목적에는, 이만한 조합을 찾기 어려웠습니다.
인프라를 고르는 기준도 스택과 크게 다르지 않았습니다. 기능이 얼마나 많은지, 취향에 맞는지보다는 실패를 몇 번이고 감당할 수 있는 비용 구조와 성공했을 때 갈아엎지 않아도 될 확장성을 보고 클라우드플레어를 선택했습니다.
참고
개발자를 위한 클라우드플레어를 소개합니다 - 바이라인네트워크 웨비나
Fullstack Cloudflare - Syntax
2025 반드시 알아둬야할 이 개발자 플랫폼은? - 노마드코더