#Tech
#SST
#nextjs
#react native
#aws
#AWS Lambda
#Fastify
#Supabase
#Prisma ORM
Korean
Written by Paul
December 6, 2025
안녕하세요.
COLDSURF를 1인으로 만들고 운영하고 있는 Paul입니다.
COLDSURF가 어느덧 1주년을 넘기고, 서비스 유입 또한 완만하지만 꾸준한 상승 곡선을 그리고 있어 그간의 기록을 정리하는 시리즈를 시작해보려 합니다. 이번 글은 그 첫 시작으로, 오랜만에 개발 이야기를 다뤄보려 합니다.
개발 초기 어떤 선택을 했고, 왜 그런 의사결정을 했는지, 그리고 그 결과가 실제 운영 과정에서 어떤 속도와 부담으로 돌아왔는지를 공유드리겠습니다. 이후 이어질 글에서는 COLDSURF라는 이름으로 활동하며 경험한 장면들, 현장의 질감, 그리고 방향성에 대한 고민까지 차근히 담아볼 예정입니다.
1년 동안 쌓인 기술적·문화적·창작적 기록들을 차분히 풀어볼 테니, 가벼운 마음으로 함께해 주시면 좋겠습니다.
이 글은 비교적 기술적 배경을 전제로 합니다.
바이브 코딩이나 개발 경험이 거의 없으신 분들께는 다소 난이도가 있을 수 있습니다. 다만 향후 팀 구성이나 기술 스택 방향성을 고민하시는 예비 창업자, 초기 팀 빌더, 혹은 서비스 구축을 준비 중이신 분들에게는 충분히 참고가 될 만한 내용일 것입니다.
앱 서비스: React Native
앱 서비스를 처음 구축하신다면 React Native를 우선적으로 추천드립니다.
최근 Flutter를 권하는 흐름도 있고, WebView 기반 하이브리드 앱 형태도 많이 고려하시지만, 제 판단은 조금 다릅니다.
우선 Flutter의 경우, 빠르게 문제를 해결해야 하는 사이드 프로젝트나 MVP 단계에서 사용할 때 커뮤니티 규모의 격차를 체감하게 됩니다. RN은 수년간 축적된 레퍼런스와 즉시 활용 가능한 코드 스니펫이 압도적으로 많고, 이는 ‘개발 생산성’ 그 이상의 실질적인 가치를 제공합니다.
WebView 조합 역시 특정 상황에서는 적합합니다.
다만 캘린더, GPS, 음악 재생과 같은 네이티브 기능을 다루는 순간, 웹 기반 앱 구조는 한계를 드러냅니다. 기기의 고유 SDK를 사용해야 하는 상황이 반드시 찾아오고, 그 지점에서 WebView는 더 이상 유연한 선택이 되기 어렵습니다.
특히 아래와 같은 형태는 추천드리지 않습니다.
- 하나의 웹 플랫폼을 만들고, 이를 모바일에서 WebView로 통째로 감싸는 방식
이 방식은 서비스가 커질수록 다음과 같은 문제가 발생할 가능성이 큽니다.
- 웹과 웹뷰용 브릿지 코드를 모두 포함해야 하므로 구조가 복잡해짐
- 코드 스파게티화로 이어지기 쉬움
- 장기적으로 유지보수성과 확장성이 떨어짐
- 결국 마이그레이션 비용이 발생
제가 권하는 방식은 다음과 같습니다.
- Expo 기반도 아닌, WebView 조합도 아닌, Bare React Native
- UI 역시 순수 RN 컴포넌트로 작성
- OTA(HotUpdater 등)를 적극 활용하여 빠르고 유연한 배포
요즘은 OTA 환경이 안정적이고, 앱 규모가 크지 않은 초기 단계에서는 개발 속도와 운영 난이도를 동시에 잡을 수 있는 선택입니다.
빠르고 가벼운 개발, 즉 “실험 가능한 속도”가 필요한 사이드 프로젝트라면 이 조합이 가장 현실적이라고 생각합니다.
웹 서비스: Next.js + sst (open-next)
웹 서비스 구축에는 다양한 선택지가 존재하지만, 현재 시점에서는 여전히 Next.js가 가장 안정적인 해답이라고 생각합니다.
초기 단계에서는 도메인을 연결해 Vercel에 배포하는 방식이 충분히 유효하며, 이후 AWS 인프라를 붙여 확장하고 싶을 때에는 SST(open-next)를 활용하는 것을 추천드립니다.
SST는 AWS 인프라 구성 요소—권한, CloudFormation, Lambda, Route53, CloudFront 등—을 모두 코드 기반(TypeScript)으로 관리할 수 있게 해주며, 단일 명령어로 배포까지 수행할 수 있는 CaaS(Code as a Service) 도구입니다. Next.js 전용 스택도 제공하므로, 필요한 AWS 권한만 세팅하면 꽤 안정적이고 깔끔한 배포 과정이 가능합니다. 배포 후 스택 삭제(purge) 역시 CLI 한 번으로 정리할 수 있어 운영 종료나 환경 정리 시에도 부담이 적습니다.
제가 Next.js를 추천하는 이유는 다음과 같습니다.
- 사이드 프로젝트라 하더라도 기능이 쌓이는 순간, 라우팅·상태·UI 배치가 쉽게 복잡해짐
- App Router + Server Component 구조는 이러한 분리를 자연스럽게 유도해 줌
- 결과적으로 코드가 정돈되고 유지보수 가능성이 높아짐
- 적은 개발 비용으로 구조적 효율을 극대화할 수 있음
즉, Next.js는 단순히 빠르게 만드는 프레임워크가 아니라 구조의 무질서를 예방하고 서비스의 수명을 연장시키는 도구입니다.
추후 이 기술 스택에 대해서는 단계별 튜토리얼과 함께 별도 글로 자세히 다뤄보겠습니다.
API 서버: Fastify + Serverless Framework + AWS Lambda 조합
GraphQL이든 REST API든, API 서버 운영 비용은 사이드 프로젝트에서 피할 수 없는 부담입니다. 서버 없이 구축하는 서비스들도 많지만, 실제 운영 단계에서 기능 확장과 데이터 연동을 고려하면 API 서버가 존재하는 편이 훨씬 유연합니다.
저 역시 비용 문제를 오래 고민했고, 결국 선택한 결론은 AWS Lambda 기반 FaaS(Function as a Service)였습니다.
Lambda를 선택한 이유
- EC2, ECS+Fargate 등 상시 기동형 서버는 MVP 단계에서 과한 비용 구조
- 사용자가 없는 시간대에도 24시간 운영 비용이 발생
- Lambda는 요청이 발생한 만큼만 비용을 지불하는 구조
- 사이드 프로젝트/초기 서비스에는 가장 현실적인 선택
왜 수많은 FaaS 중 Lambda인가?
- Layer 커스터마이징 가능
- Lambda의 배포 방식은 ZIP 번들인데, 용량 제한을 넘기면 배포 자체가 불가
- Layer를 활용하면 런타임 의존성을 외부화하여 용량 부담 없이 구성 가능
- 모놀리식 서버 아키텍처도 구현 가능
- 단순한 단건 API 라우트 호출 수준이 아닌
- 엔트리포인트부터 라우팅, 서비스 구조까지 하나의 서버 형태로 구성 가능
- 컨테이너나 EC2처럼 서버 전체를 설계할 수 있으면서도 비용은 요청 기반
Fastify를 조합하는 이유
서버 구성은 Fastify를 권합니다.
Fastify는 경량이면서 빠른 서버 프레임워크로 Express에서 가능했던 기능 대부분을 안정적으로 제공하며, Lambda와 조합했을 때 다음과 같은 장점이 있습니다.
- 불필요한 오버헤드 없이 가벼운 아키텍처 구성 가능
- 비대해지기 쉬운 서버 프레임워크 대비 유지보수 부담이 낮음
- 초기 MVP부터 확장까지 무리 없는 성능 확보
즉, Lambda + Fastify는 “비용 효율”과 “구조적 안정성”을 동시에 확보할 수 있는 조합입니다. 초기 서비스 개발에 있어 가장 핵심적인 조건을 만족시켜 줍니다.
DB: Supabase + Prisma
DB의 경우 저는 강력하게 Supabase + Postgresql 조합을 추천합니다.
일단 위에서 언급한 서버비용과 비슷하게, AWS RDB 등을 쓰게 되면 실제 사용량 대비 비용이 꽤나 많이 청구됨을 경험했던 것 같습니다.
하지만 Supabase는 월 3만 5천원 정도의 저렴한 비용으로, DB Infra에 대한 모든 것을 제공하고 그외에 추가적인 인프라도 제공하니 이와같이 좋을 순 없습니다.
웬만한 규모의 서비스라면 굳이 구독까지 하지 않더라도, 충분히 쓸수 있는 무료 플랜을 제공하기도 합니다.
만약 월 egress 등의 사용량이 넘어갈정도의 서비스라면, 좋은 서비스에 후원을 한다는 마음으로 3만 5천원정도 구독 결제 하셔서 쓰셔도 좋을 것 같습니다.
Supabase를 추천하는 이유는 바로 Prisma + Postgresql 조합 때문입니다.
Prisma는 DB model에 대한 migration 등을 코드로써 관리 할 수 있는 아주 좋은 ORM 툴입니다.
물론 요즘 다른 ORM들도 많이 사용중 인 것을 알고 있지만, 아직까지 국룰은 Prisma가 아닌가 하여 소개로 들고 나왔습니다.
이에 대한 깊은 튜토리얼도 이어지는 글에서 다뤄 보겠습니다!
DB: Supabase + Prisma
데이터베이스 구성은 Supabase + PostgreSQL 조합을 가장 우선적으로 추천드립니다.
AWS RDS 기반으로 운영해 본 경험상, 실제 사용량이 크지 않은 초기 단계에서도 비용이 과도하게 청구되는 경우가 많았습니다. 반면 Supabase는 기본 플랜 기준 월 약 3만 5천 원이라는 비교적 부담 없는 비용으로 DB 인프라 전반을 안정적으로 제공합니다. 또한 인증, 스토리지, Edge Function 등 부가 기능까지 함께 포함되어 있어 초기 구축 속도 면에서도 매우 효율적입니다.
규모가 크지 않은 서비스라면 유료 구독 없이도 충분히 쓸 수 있는 무료 플랜을 제공한다는 점 역시 큰 장점입니다. 만약 egress나 스토리지 사용량이 유료 기준을 넘어서는 단계라면, 성장에 대한 투자라고 생각하고 구독을 선택하는 편이 합리적입니다.
제가 Supabase를 추천하는 이유는 Prisma + PostgreSQL 조합 덕분이기도 합니다.
Prisma는 스키마 정의, 마이그레이션, 타입 관리 등 DB 구조를 명시적 코드로 유지할 수 있는 훌륭한 ORM이며, 다음과 같은 강점을 제공합니다.
- DB 모델을 코드로 관리할 수 있어 변경 이력 추적이 명확함
- 마이그레이션 프로세스가 직관적이고 안정적
- PostgreSQL과의 궁합이 뛰어나고 실서비스 적용 사례가 많음
물론 최근 다양한 ORM이 선택지로 등장하고 있지만, 초기 구축 속도와 안정성, 그리고 커뮤니티 지원까지 고려한다면 여전히 Prisma가 가장 무난하고 신뢰할 수 있는 선택이라고 생각합니다.
Supabase + PostgreSQL + Prisma 조합은 빠른 MVP 구성 → 무리 없는 확장 → 유지보수 안정성이라는 세 조건을 모두 충족합니다.
이 조합에 대한 세부 사용법과 마이그레이션 가이드는 이어질 튜토리얼에서 상세히 다뤄보겠습니다.
마치며
여기까지 COLDSURF의 초기 기술 스택과 선택 이유를 간단히 정리해보았습니다.
이 글이 기술 방향을 고민하시는 개발자 분들, 그리고 채용·구성·확장을 고려하는 초기 스타트업 분들께 작게나마 참고가 되었기를 바랍니다.
추후에는 이번에 언급한 각 스택들을 실제로 어떻게 구성하고 배포하며 운영하는지에 대한 구체적인 튜토리얼과 아키텍처 사례도 이어서 공유드릴 예정입니다.
다음 글에서는 기술이 아닌 운영의 관점으로 넘어가,
“COLDSURF; 1년여의 기록 - Part 2. 서비스를 운영한다는 것”
이라는 주제로 COLDSURF가 실제로 어떤 리듬과 태도로 유지되어 왔는지를 이야기해보려 합니다.
읽어주셔서 감사합니다.
다음 글에서 다시 뵙겠습니다.