비개발자를 위한 배포 가이드

01 먼저 알아야 할 것

내 노트북에서는 데모가 잘 돌아가는데, 아직 낯선 사람이 접속할 수 있는 주소가 없다면 이 가이드가 필요합니다.

배포는 로컬에서 작동하는 결과물을 인터넷에 올려 누구나 접속할 수 있게 만드는 일입니다. DevOps 엔지니어가 될 필요는 없습니다. 어떤 부분을 플랫폼에 맡길지, 비밀키는 어디에 둬야 하는지, 처음 선택해도 안전한 기본 조합이 무엇인지 알면 됩니다.

02 60초 요약

시간이 없다면 여기서 시작하세요. 내 앱과 가장 비슷한 상황을 고르고, 그 조합을 기본값으로 삼으면 됩니다. 실제 트래픽, 실제 사용자, 실제 고객 요구사항이 생기면 그때 조정하면 됩니다.

03 실제로 배포하는 것들

배포된 앱은 여러 층으로 이루어져 있습니다. 이 층의 이름만 알아도 플랫폼 설명을 훨씬 쉽게 읽을 수 있습니다.

정적 앱과 동적 앱

정적 앱은 사진 앨범에 가깝습니다. 모든 방문자에게 같은 파일을 보여줍니다. 랜딩 페이지, 문서, 포트폴리오, 블로그, 단순 마케팅 사이트가 여기에 해당합니다.

동적 앱은 맞춤 양복점에 가깝습니다. 누가 로그인했는지, 무엇을 입력했는지, 데이터베이스에 무엇이 있는지, AI가 무엇을 반환했는지에 따라 응답이 달라집니다. 대시보드, 예약 시스템, 챗봇, 결제, 협업 도구가 여기에 해당합니다.

이 차이가 배포 선택의 대부분을 결정합니다. 정적 앱은 거의 어디서나 저렴하게 운영할 수 있습니다. 동적 앱은 비공개 코드, 상태, 권한, 시크릿을 처리할 장소가 필요합니다.

04 프론트엔드 호스팅

프론트엔드 호스팅은 스택에서 가장 쉬운 부분입니다. 대부분의 현대적 선택지는 충분히 좋습니다. 차이는 개발 경험, 비용 구조, 프레임워크 궁합, 백엔드 로직 필요성에서 납니다.

Vercel

Vercel은 Next.js 앱의 기본 목적지에 가깝습니다. GitHub 기반 배포, 브랜치별 프리뷰 URL, 빠른 CDN, 서버리스 함수, 이미지 최적화, 간단한 도메인 연결을 제공합니다. 설정이 맞으면 배포 과정이 거의 보이지 않을 정도로 부드럽습니다.

Vercel을 쓰기 좋은 경우:

• Next.js, React, Vercel이 잘 지원하는 프레임워크로 만들고 있습니다.
• 브랜치나 PR마다 프리뷰 배포가 필요합니다.
• 웹 SaaS, 대시보드, AI 어시스턴트, 로그인 기반 웹앱입니다.
• 프론트엔드와 가벼운 API 라우트를 한곳에서 관리하고 싶습니다.

비용 구조에서 확인할 것:

• 개인 취미 프로젝트는 무료로 시작할 수 있지만, 상업용 작업은 보통 유료 플랜을 기준으로 봐야 합니다.
• bandwidth, 이미지 최적화, 함수 사용량, 팀 seat가 실제 월 비용을 바꿉니다.
• 바이럴 트래픽, 봇, DDoS, 이미지가 많은 페이지는 예산 알림과 지출 제한이 없을 때 위험합니다.

Netlify

Netlify는 정적 사이트, 콘텐츠 중심 사이트, Jamstack 프로젝트, 다양한 프레임워크를 쓰는 팀에 좋습니다. Git 배포, 프리뷰 배포, form 처리, serverless functions, redirect, edge functions, 도메인 관리를 제공합니다.

Netlify를 쓰기 좋은 경우:

• 랜딩 페이지, 문서 사이트, 블로그, 마케팅 사이트를 만들고 있습니다.
• 커스텀 백엔드 없이 form 제출을 받고 싶습니다.
• Astro, Eleventy, Hugo, Gatsby, SvelteKit 등 static-first 프레임워크를 씁니다.
• GitHub → preview → production 흐름을 원합니다.

주의할 점:

• Next.js의 최신 고급 기능은 Vercel에서 먼저 안정화되는 경우가 많습니다.
• 큰 콘텐츠 사이트에서는 build minutes 한도가 중요할 수 있습니다.
• Netlify Functions는 유용하지만, 본격 백엔드는 Render, Railway, Supabase, Cloud Run이 더 적합할 수 있습니다.

Cloudflare Pages

Cloudflare Pages는 정적 사이트와 edge-first 프로젝트에 좋습니다. 가장 큰 장점은 비용 구조입니다. Cloudflare는 거대한 네트워크와 bandwidth 처리에 강하기 때문에, 트래픽이 많은 정적 사이트를 저렴하게 운영하기 좋습니다.

Cloudflare Pages를 쓰기 좋은 경우:

• 정적 사이트, 문서, 랜딩 페이지, 콘텐츠 중심 사이트입니다.
• 트래픽 급증 가능성이 있고 CDN 비용을 낮추고 싶습니다.
• Pages와 Workers, KV, D1, Durable Objects, R2를 함께 쓰고 싶습니다.
• 글로벌 지연시간과 edge delivery가 중요합니다.

주의할 점:

• Cloudflare Workers는 full Node.js 서버가 아닙니다. 일부 Node 패키지와 API는 수정 없이 작동하지 않을 수 있습니다.
• 플랫폼은 강력하지만, 전통적인 서버보다 edge-native 사고방식에 가깝습니다.
• 전통적인 장기 실행 백엔드가 필요하다면 Pages는 프론트엔드로 두고 API는 Render, Railway, Cloud Run에 두는 조합이 낫습니다.

Firebase Hosting

Firebase Hosting은 이미 Firebase Auth, Firestore, Cloud Storage, Cloud Functions를 쓰는 앱에 좋습니다. 정적 assets를 빠르게 제공하고 Firebase 생태계와 자연스럽게 연결됩니다.

Firebase Hosting을 쓰기 좋은 경우:

• 모바일 우선 제품을 Firebase SDK로 만들고 있습니다.
• 인증, 데이터베이스, 저장소, 호스팅, 함수를 하나의 콘솔에서 관리하고 싶습니다.
• 웹앱은 대부분 정적이지만 Cloud Functions로 rewrite가 필요합니다.
• 팀이 Firebase 프로젝트와 security rules에 익숙합니다.

주의할 점:

• Firebase Hosting 자체는 정적 파일을 제공합니다. 동적 백엔드 로직은 Cloud Functions 또는 Cloud Run이 필요합니다.
• Firestore와 Storage security rules는 출시 직전 옵션이 아니라 출시 필수 작업입니다.
• reads, writes, storage downloads, functions가 예상보다 커지면 사용량 기반 비용이 커질 수 있습니다.

프론트엔드 플랫폼 비교

빠른 선택

• Next.js SaaS나 AI 대시보드라면 Vercel로 시작하세요.
• 정적 마케팅 사이트나 문서 사이트라면 Cloudflare Pages 또는 Netlify로 시작하세요.
• 모바일, Auth, Firestore, push 등 Firebase를 이미 쓴다면 Firebase Hosting을 쓰세요.
• 공개 bandwidth나 파일 다운로드가 많을 것 같다면 Cloudflare Pages + R2를 일찍 검토하세요.
• form 수집과 마케팅 워크플로가 중요하면 Netlify가 편합니다.

05 Backend-as-a-Service

Backend-as-a-Service는 데이터베이스, 인증, 저장소, serverless functions를 한 플랫폼에서 제공합니다. 다섯 개의 공급자를 직접 연결하지 않아도 되기 때문에 비개발자와 작은 팀에게 특히 매력적입니다.

하지만 백엔드 생각이 사라지는 것은 아닙니다. 데이터 모델링, 권한, 마이그레이션, 백업, rate limit, 환경변수는 여전히 필요합니다.

Supabase

Supabase는 많은 바이브 코딩 웹앱의 좋은 기본값입니다. PostgreSQL을 중심으로 만들어졌기 때문입니다. 테이블, row, column, 관계, SQL, policy라는 익숙하고 표준적인 모델을 사용합니다.

Supabase가 제공하는 것:

• Postgres database: 구조화된 데이터 저장.
• Auth: 이메일/비밀번호, magic link, OAuth, session.
• Row Level Security: 데이터베이스에서 강제하는 권한.
• Storage: 이미지, PDF, 사용자 업로드.
• Edge Functions: 비공개 서버 로직.
• Realtime: 구독과 협업 기능.
• SQL 접근: 데이터를 직접 확인하고 복구하기 쉬움.

Supabase를 쓰기 좋은 경우:

• 계정, 대시보드, 프로젝트, 팀, 구독, 기록이 있는 앱입니다.
• 독자적인 NoSQL 쿼리보다 SQL을 원합니다.
• 나중에 export, reporting, analytics, join, admin view가 필요할 수 있습니다.
• AWS를 배우기 전에 하나의 백엔드 플랫폼으로 시작하고 싶습니다.

주의할 점:

• Row Level Security는 신중히 설계해야 합니다. 켜기만 하고 policy가 없으면 접근이 막히고, 끄면 데이터가 새어 나갈 수 있습니다.
• 무료 플랜의 백업 보장은 production 기준에 부족할 수 있습니다.
• 트래픽이 늘면 serverless functions와 데이터베이스 connection pooling을 이해해야 합니다.

Firebase

Firebase는 모바일 우선, real-time 제품에 강합니다. Authentication, Firestore, Realtime Database, Cloud Storage, Cloud Messaging, Analytics, Hosting, Cloud Functions와 성숙한 모바일 SDK를 제공합니다.

Firebase를 쓰기 좋은 경우:

• iOS, Android, Flutter, React Native, 모바일 우선 웹앱입니다.
• offline sync, real-time update, push notification이 핵심입니다.
• Google-native tooling과 성숙한 SDK 생태계를 원합니다.
• 데이터가 document 기반 접근 패턴에 잘 맞습니다.

주의할 점:

• Firestore는 relational database가 아닙니다. 쿼리 설계와 데이터 중복이 일반적입니다.
• 화면 하나가 많은 문서를 읽는 read-heavy 앱은 비용이 커질 수 있습니다.
• Security rules는 강력하지만 잘못 작성하기 쉽습니다.
• Firestore 전용 패턴에 깊게 묶이면 나중에 이동하기 어렵습니다.

Supabase와 Firebase 비교

06 클라우드 대형 플랫폼

AWS, Google Cloud, Azure는 강력하고 안정적이지만, 비개발자에게 좋은 첫 스승은 아닙니다. 엔터프라이즈 통제, 컴플라이언스, private networking, 복잡한 인프라, 고객이 요구하는 cloud alignment가 있을 때 중요해집니다.

Amazon Web Services

AWS는 가장 넓은 클라우드 플랫폼입니다. S3, Lambda, RDS, DynamoDB, CloudFront, Cognito, Secrets Manager, CloudWatch, IAM 등 거의 모든 인프라 기능이 있습니다.

AWS를 쓰기 좋은 경우:

• 고객이나 회사가 이미 AWS를 씁니다.
• enterprise procurement, compliance, region control이 필요합니다.
• 엔지니어링 도움을 받을 수 있습니다.
• 단순 플랫폼이 제공하지 못하는 성숙한 인프라가 필요합니다.

첫 앱을 만들면서 “전문적으로 보이니까” AWS로 시작하지 마세요. AWS는 배포를 제품 출시가 아니라 인프라 학습 프로젝트로 바꿀 수 있습니다.

Google Cloud Platform

GCP는 Firebase, Google Workspace, BigQuery, Vertex AI, Google Cloud 인프라를 이미 쓰는 팀에 자연스럽습니다. 바이브 코딩 앱에서는 Firebase Hosting + Cloud Run + Cloud SQL 조합이 접근하기 쉬운 production 경로입니다.

알아두면 좋은 GCP 서비스:

• Cloud Run: containerized web service와 AI backend.
• Cloud SQL: managed Postgres 또는 MySQL.
• Secret Manager: 비밀키 저장.
• Cloud Logging / Cloud Monitoring: production visibility.
• Firebase Hosting/Auth/Firestore: 앱 사용자와 직접 맞닿는 부분.
• Vertex AI: AI workflow를 Google Cloud 안에 둬야 할 때.

GCP를 쓰기 좋은 경우:

• Kubernetes 없이 container를 운영하고 싶습니다.
• Firebase에서 시작했고 더 강한 백엔드가 필요합니다.
• BigQuery, Vertex AI, Google-native enterprise tooling이 필요합니다.

Microsoft Azure

Azure는 고객이나 조직이 Microsoft 중심일 때 강합니다. Entra ID, Microsoft 365, .NET, enterprise procurement, Azure DevOps와 잘 맞습니다.

알아두면 좋은 Azure 서비스:

• Azure Static Web Apps: 정적 프론트엔드와 serverless API.
• Azure App Service: 여러 언어의 웹앱과 API.
• Azure Functions: serverless logic.
• Azure SQL Database / Cosmos DB: 데이터 저장.
• Azure Key Vault: 시크릿 저장.
• Application Insights: 모니터링.

Azure를 쓰기 좋은 경우:

• 고객이 Microsoft identity, SSO, procurement를 요구합니다.
• 팀이 .NET 또는 Azure DevOps를 씁니다.
• 비즈니스 환경이 Microsoft-first입니다.

클라우드 대형 플랫폼을 써야 할 때

AWS, GCP, Azure는 아래 중 하나가 실제로 있을 때 쓰세요.

• 실제 고객이 요구합니다.
• compliance, audit, procurement, data residency가 필요합니다.
• 엔지니어 또는 DevOps 파트너가 있습니다.
• private networking, container orchestration, advanced observability, enterprise identity가 필요합니다.
• 앱이 이미 인프라 복잡도를 감당할 만큼 매출을 만들고 있습니다.

그 외에는 단순하게 시작하세요. 실제 사용자가 오늘 접속할 수 있는 Vercel + Supabase 앱이, 배포되지 않는 완벽한 AWS 다이어그램보다 낫습니다.

07 인증

인증은 로그인 화면 하나가 아닙니다. 회원가입, 비밀번호 재설정, 이메일 인증, session, 권한, social login, multi-factor authentication, organization, role, enterprise SSO까지 포함합니다.

인증이 제품 자체가 아니라면 직접 만들지 마세요. 인증 버그는 곧 보안 버그가 됩니다.

인증 제공자

실전 기본값

• 데이터베이스로 Supabase를 쓴다면 Supabase Auth로 시작하세요.
• 모바일 앱이고 Firebase를 쓴다면 Firebase Auth로 시작하세요.
• 로그인 경험이 제품의 중요한 차별점이라면 Clerk를 검토하세요.
• 회사 고객이 SAML, SCIM, enterprise SSO를 요구하면 WorkOS, Auth0, Clerk B2B, Cognito를 검토하세요.

출시 전 테스트할 것:

1. 회원가입.
2. 로그인.
3. 로그아웃.
4. 비밀번호 재설정.
5. 이메일 인증.
6. Social login을 켰다면 social login.
7. Production redirect URL.
8. 필요한 경우 사용자 데이터 삭제 또는 export.

08 데이터베이스

데이터베이스 선택은 나중에 reporting, 권한, migration, export, debugging, integration, 앱 변경 난이도에 영향을 줍니다.

Supabase / PostgreSQL

Postgres는 많은 웹앱의 좋은 기본값입니다. 표준적이고, relational이고, 성숙하며, 이해하기 쉽습니다. structured data, join, constraint, index, transaction, JSON, full-text search, pgvector 같은 vector extension을 지원합니다.

적합한 경우:

• SaaS 앱.
• 대시보드.
• 내부 도구.
• 사용자, 프로젝트, 문서, 사용량 기록이 있는 AI 앱.
• export, report, admin operation이 필요할 수 있는 제품.

Firebase Firestore

Firestore는 real-time과 모바일에 강한 document database입니다. 알려진 path의 document를 빠르게 읽고 쓰며 client에 동기화하는 앱에 잘 맞습니다.

적합한 경우:

• 모바일 앱.
• 실시간 채팅 또는 협업 상태.
• Offline-first 경험.
• 이미 Firebase를 깊게 쓰는 앱.

피하는 것이 좋은 경우:

• 복잡한 relational query가 필요합니다.
• reporting이 중요합니다.
• SQL export나 join이 필요합니다.
• 화면 하나가 많은 document read를 발생시켜 비용 예측이 어렵습니다.

MongoDB Atlas

MongoDB Atlas는 유연한 JSON-like document를 저장합니다. record 구조가 다양할 때 유용할 수 있지만, 그 유연함은 application layer에서 schema를 관리하지 않으면 데이터 불일치로 바뀔 수 있습니다.

적합한 경우:

• 팀이 MongoDB에 익숙합니다.
• 앱의 데이터가 자연스럽게 document 형태입니다.
• 직접 운영하지 않는 managed MongoDB가 필요합니다.

Neon

Neon은 serverless Postgres입니다. Postgres를 원하지만 hosting platform에 데이터베이스를 묶고 싶지 않을 때 유용합니다. Branching과 scale-to-zero 특성 때문에 현대적인 앱 workflow와 잘 맞습니다.

적합한 경우:

• 프론트엔드는 Vercel, Netlify, Cloudflare에 두고 독립적인 Postgres를 쓰고 싶습니다.
• preview나 개발용 database branching이 필요합니다.
• 서버를 직접 관리하지 않는 serverless-friendly Postgres가 필요합니다.

PlanetScale

PlanetScale은 MySQL-compatible serverless database workflow를 중심으로 합니다. MySQL을 잘 아는 팀과 branching-style database operation을 원하는 팀에 맞을 수 있습니다.

적합한 경우:

• 앱이나 팀이 MySQL을 선호합니다.
• serverless database workflow가 필요합니다.
• constraint, relation, migration 방식의 tradeoff를 이해합니다.

AWS RDS와 DynamoDB

RDS는 Postgres, MySQL 등 relational database를 AWS에서 managed로 운영하는 서비스입니다. DynamoDB는 AWS의 고성능 NoSQL key-value/document database입니다.

AWS 안에서 전통적인 relational database가 필요하면 RDS를 쓰세요. 매우 높은 scale과 명확한 access pattern이 있고 AWS 엔지니어링 도움을 받을 수 있다면 DynamoDB를 검토하세요. DynamoDB를 초보자의 기본값으로 선택하지는 마세요.

AI 앱을 위한 vector database

Vector database는 embedding, 즉 의미를 숫자로 표현한 값을 저장합니다. semantic search, retrieval-augmented generation, recommendation, clustering, “비슷한 것 찾기”에 유용합니다.

선택지:

• Supabase 또는 Neon의 pgvector: 이미 Postgres를 쓰고 있다면 가장 좋은 첫 선택.
• Pinecone: scale과 performance를 위한 dedicated managed vector database.
• Weaviate: open-source와 managed option이 있는 vector search platform.
• Qdrant: managed option을 제공하는 강한 open-source vector database.
• Chroma: local prototype과 작은 실험에 유용.

초기 AI 앱 대부분은 Postgres 안의 pgvector로 충분합니다. 검색량, latency, vector scale이 실제 제약이 될 때 dedicated vector database로 넘어가세요.

데이터베이스 비교

09 파일 저장소

이미지, PDF, 오디오, 비디오를 데이터베이스에 직접 넣지 마세요. 파일은 object storage에 저장하고, 데이터베이스에는 파일 URL, path, owner ID, size, MIME type, metadata만 저장하세요.

사용자 업로드가 있다면 반드시 정할 것:

1. 최대 파일 크기.
2. 허용 파일 형식.
3. 누가 업로드할 수 있는지.
4. 누가 다운로드할 수 있는지.
5. public, private, signed-link 중 어떤 방식인지.
6. 사용자가 계정을 삭제하면 파일을 어떻게 삭제할지.
7. 업로드 파일을 scan, compress, resize해야 하는지.

10 아키텍처 패턴

아키텍처는 앱의 모양입니다. 대부분의 배포된 제품은 몇 가지 패턴 안에 들어갑니다. 실제 출시하려는 제품을 지원하는 가장 단순한 패턴을 고르세요.

추상화 수준 4단계

흔한 아키텍처 패턴 6가지

AI 비용 방어 패턴

AI 앱에는 추가 계층이 필요합니다. 바로 server-side AI gateway입니다. OpenAI, Anthropic, Gemini 같은 유료 모델 제공자를 브라우저 코드에서 직접 호출하지 마세요.

AI gateway가 해야 할 일:

• 사용자가 로그인했는지 확인.
• 입력 길이와 파일 크기 검증.
• 사용자별, 팀별, IP별 rate limit.
• 자주 나오는 응답 cache.
• 단순 작업은 더 저렴한 모델 사용.
• latency가 중요하면 streaming.
• 비용 분석을 위해 usage record 저장.
• 사용자가 plan limit을 넘으면 요청 거절.
• provider API key는 server-side environment variables에만 보관.

11 환경변수와 시크릿

핵심 원칙은 간단합니다. public으로 노출되는 값은 사용자가 볼 수 있습니다.

Frontend framework는 NEXT_PUBLIC_, PUBLIC_, VITE_ 같은 prefix로 브라우저에 값을 노출합니다. 이런 값은 시크릿이 아니라 설정값입니다.

서버에만 있어야 하는 비공개 시크릿

• OpenAI, Anthropic, Gemini, OpenRouter API key.
• Database service-role key.
• Stripe 또는 결제 provider secret key.
• Webhook signing secret.
• Email provider API key.
• Admin token.
• Cloud service credential.
• JWT signing secret.

공개 설정값

• Public Supabase URL.
• RLS가 제대로 설정된 경우 Supabase anon key.
• Public Firebase config.
• Public analytics ID.
• Site URL.
• 비공개 로직을 드러내지 않는 feature flag.

플랫폼별 시크릿 저장 위치

보안 체크리스트

• .env, .env.local을 .gitignore에 추가합니다.
• production secret은 hosting platform dashboard에 저장합니다.
• AI provider key를 React, Vue, Svelte, client-side code에 넣지 않습니다.
• service-role database key를 commit하지 않습니다.
• GitHub에 올라간 key는 즉시 rotate합니다.
• development와 production key를 분리합니다.
• 결제와 auth event의 webhook signature를 검증합니다.
• AI, hosting, cloud dashboard에서 월 사용량 제한을 설정합니다.
• 로그에 시크릿이 출력되지 않는지 확인합니다.

12 도메인, DNS, SSL

도메인은 임시 플랫폼 URL을 실제 제품 주소로 바꿔줍니다. DNS는 그 도메인을 hosting platform으로 연결하는 인터넷 주소 시스템입니다. SSL/TLS는 사이트를 https://로 안전하게 열리게 하는 certificate layer입니다.

일반적인 흐름:

1. Cloudflare, Namecheap, Squarespace Domains, GoDaddy, 국내 등록기관 등에서 도메인을 삽니다.
2. Hosting platform에 도메인을 추가합니다.
3. Host가 보여주는 DNS record를 복사합니다.
4. Domain registrar의 DNS 설정에 붙여넣습니다.
5. Propagation을 기다립니다.
6. Hosting platform이 SSL을 자동 발급하도록 둡니다.
7. example.com과 www.example.com을 모두 테스트합니다.

자주 쓰는 DNS record

대부분의 현대적 호스트는 SSL을 자동으로 발급합니다. 해야 할 일은 플랫폼이 보여주는 DNS record를 정확히 추가하고, propagation을 기다리고, 최종 URL을 테스트하는 것입니다.

13 비개발자를 위한 CI/CD

CI/CD는 GitHub에 코드를 push하면 앱이 자동으로 build되고 deploy되는 흐름입니다. 전문가가 될 필요는 없지만, 반복 가능한 배포 경로는 필요합니다.

초보자에게 안전한 workflow:

1. 로컬 또는 AI coding tool에서 작업합니다.
2. Commit하고 GitHub에 push합니다.
3. Hosting platform이 preview를 build합니다.
4. Preview URL에서 테스트합니다.
5. Main branch에 merge합니다.
6. Production deploy가 자동으로 진행됩니다.
7. Deploy 후 logs를 확인합니다.

Preview에서 테스트할 것:

• Signup, login, logout, password reset.
• Database read/write.
• File upload/download.
• Server를 통한 AI call.
• Payment checkout과 webhook, 있다면.
• Mobile layout.
• Error state.

이 과정이 지루하게 느껴진다면 좋은 신호입니다. 배포는 지루해져야 합니다. 모든 변경에 preview가 있고, 모든 deploy가 재현 가능하고, rollback이 가능할 때 건강한 상태입니다.

14 모니터링과 알림

보이지 않는 것은 고칠 수 없습니다. 낯선 사용자에게 링크를 보내기 전에 monitoring을 추가하세요.

최소 설정:

1. Sentry 또는 비슷한 error tracking을 설치합니다.
2. Homepage와 health endpoint에 uptime monitoring을 추가합니다.
3. Platform logs를 켭니다.
4. Hosting, cloud, database, AI provider에 budget alerts를 설정합니다.
5. 가짜 error 하나를 만들어 alert가 실제로 도착하는지 확인합니다.

예산 알림

예산 알림은 public launch 이후가 아니라 이전에 설정합니다. 보통 다음 세 단계가 유용합니다.

• 첫 번째 경고: 내가 “어?” 하고 볼 금액.
• 두 번째 경고: 누군가에게 설명해야 할 금액.
• 세 번째 경고: 트래픽이나 비싼 기능을 멈춰야 할 금액.

AI 제품은 model provider dashboard에서도 hard cap을 설정하세요. Hosting은 저렴한데 모델 호출이 실제 비용이 되는 경우가 많습니다.

15 앱 유형별 추천 스택

이 섹션은 의도적으로 실용적으로 정리했습니다. 내 제품과 가장 비슷한 유형을 고르고, 실제 제약이 생길 때만 스택을 바꾸세요.

16 단계별 배포 경로

아래 경로는 일부러 구체적으로 적었습니다. 유일한 방법은 아니지만, 흔한 앱 유형에 안정적인 출발점입니다.

Path A — Vercel + Supabase 웹 SaaS / AI 앱

적합한 경우: Next.js SaaS, AI assistant, dashboard, internal tool, user account가 있는 제품.

1. Supabase project를 만듭니다.
2. 앱에 필요한 최소 table을 만듭니다. 예: users/profiles, projects, documents, messages, usage.
3. Supabase Auth를 켭니다.
4. Local과 production redirect URL을 설정합니다.
5. 실제 사용자를 받기 전에 Row Level Security policy를 만듭니다.
6. 사용자가 파일을 올린다면 storage bucket을 만듭니다.
7. AI call, Stripe call, private DB operation은 server-side API route로 옮깁니다.
8. 코드를 GitHub에 push합니다.
9. Vercel에서 repo를 import합니다.
10. Supabase URL, anon key, server-side service role key, AI provider key를 Vercel environment variables에 추가합니다.
11. Preview를 deploy합니다.
12. Signup, login, logout, database write, RLS, file upload, AI call을 테스트합니다.
13. Custom domain을 연결합니다.
14. Sentry, uptime check, analytics, budget alerts를 추가합니다.
15. 공개적으로 올리기 전에 작은 그룹에게 먼저 공유합니다.

Path B — Netlify + Supabase 정적 / 콘텐츠 사이트

적합한 경우: marketing site, content site, docs, lead capture, 가벼운 backend behavior가 필요한 사이트.

1. 사이트를 GitHub에 push합니다.
2. Netlify에서 Git repo로 project를 만듭니다.
3. Build command를 설정합니다. 보통 npm run build입니다.
4. Publish directory를 설정합니다. 예: dist, out, build, framework-specific output.
5. 필요한 environment variables를 추가합니다.
6. Preview를 deploy합니다.
7. Custom backend 없이 lead capture가 필요하면 Netlify Forms를 씁니다.
8. 작은 server-side task에는 Netlify Functions를 추가합니다.
9. Custom domain을 연결합니다.
10. Netlify가 SSL을 발급하도록 둡니다.
11. Analytics를 추가하고 sitemap을 제출합니다.

Path C — Render full-stack API / Python backend

적합한 경우: FastAPI, Flask, Django, Express, background worker, webhook, warm 상태가 필요한 API.

1. requirements.txt, package.json, Dockerfile 중 필요한 파일과 함께 backend code를 GitHub에 push합니다.
2. Render Web Service를 만듭니다.
3. Runtime 또는 Docker deploy를 선택합니다.
4. Build command를 설정합니다.
5. Start command를 설정합니다.
6. Environment variables를 추가합니다.
7. 필요하면 managed Postgres를 만듭니다.
8. Deploy하고 logs를 봅니다.
9. /health endpoint를 만듭니다.
10. Frontend를 Render API URL에 연결합니다.
11. Custom domain과 SSL을 연결합니다.
12. Cold start가 문제라면 public traffic 전에 paid always-on plan으로 전환합니다.

Path D — Railway 빠른 MVP / prototype

적합한 경우: quick API, prototype, hackathon app, 완벽한 cost predictability보다 speed가 중요한 팀.

1. 코드를 GitHub에 push합니다.
2. Railway project를 만듭니다.
3. GitHub repo에서 deploy합니다.
4. Railway가 build settings를 감지하게 둡니다.
5. Variables tab에 environment variables를 추가합니다.
6. 필요하면 database service를 추가합니다.
7. Railway domain을 생성합니다.
8. 준비되면 custom domain을 연결합니다.
9. 여러 service가 켜져 있다면 usage를 자주 확인합니다.
10. MVP가 production product가 되면 더 예측 가능한 구조로 옮길지 검토합니다.

Path E — Firebase 모바일 우선 앱

적합한 경우: iOS, Android, Flutter, React Native, mobile SDK, offline sync, push notification이 필요한 앱.

1. Firebase project를 만듭니다.
2. iOS, Android, web app credential을 추가합니다.
3. Firebase Auth를 켭니다.
4. Auth provider와 production redirect/callback을 설정합니다.
5. Firestore 또는 Realtime Database를 선택합니다.
6. 실제 화면 기준으로 collection과 index를 설계합니다.
7. Launch 전에 security rules를 작성합니다.
8. Cloud Storage를 추가합니다.
9. Private logic은 Cloud Functions 또는 Cloud Run에 둡니다.
10. Mobile SDK를 연결합니다.
11. Login, offline behavior, upload/download, push notification을 테스트합니다.
12. Paid plan으로 전환하기 전에 billing alerts를 설정합니다.

Path F — Cloud Run 컨테이너형 AI 백엔드

적합한 경우: AI API, Python service, 긴 endpoint, model orchestration, container가 필요한 backend.

1. Backend를 Docker로 package합니다.
2. AI provider key는 server-side에만 둡니다.
3. 코드를 GitHub에 push합니다.
4. Cloud Build 또는 GitHub Actions로 container를 build합니다.
5. Cloud Run에 deploy합니다.
6. Secret Manager에 secrets를 저장합니다.
7. Cloud SQL, Neon, Supabase 또는 다른 managed database에 연결합니다.
8. Concurrency, memory, CPU, region, min instances, max instances를 설정합니다.
9. Request logging을 추가합니다.
10. Budget alerts와 max instance limits를 설정합니다.
11. Sentry 또는 OpenTelemetry를 추가합니다.
12. 일반 web request보다 오래 걸리는 작업은 queue나 background worker로 보냅니다.

Path G — GCP full production: Firebase Hosting + Cloud Run + Cloud SQL

적합한 경우: Google Workspace를 쓰는 팀, Firebase에서 시작했지만 simple functions를 넘어선 프로젝트, all-Google production setup이 필요한 제품.

1. GCP project를 만듭니다.
2. Static frontend를 Firebase Hosting에 deploy합니다.
3. Backend를 containerize하고 Cloud Run에 deploy합니다.
4. Cloud SQL Postgres를 만들거나, NoSQL이 정말 맞다면 Firestore를 씁니다.
5. Secret Manager에 secrets를 저장합니다.
6. Secrets는 frontend code가 아니라 Cloud Run에서 참조합니다.
7. Firebase Auth 또는 Google Cloud Identity Platform을 씁니다.
8. Custom domain을 설정합니다.
9. Cloud Logging, Cloud Monitoring, uptime check, budget alerts를 추가합니다.
10. Deploy, rollback, database restore 절차를 문서화합니다.

Path H — Azure Microsoft 중심 팀

적합한 경우: Microsoft 계약이 있는 enterprise client, .NET app, Entra ID를 쓰는 internal tool, 이미 Azure를 쓰는 팀.

1. 정적 frontend + serverless API는 Azure Static Web Apps를 선택합니다.
2. 일반 web app 또는 API는 Azure App Service를 선택합니다.
3. Data model에 따라 Azure SQL Database, Cosmos DB, managed Postgres를 선택합니다.
4. Secrets는 Azure Key Vault에 저장합니다.
5. 가능하면 secret string을 복사하지 말고 managed identity를 씁니다.
6. Managed SSL로 custom domain을 추가합니다.
7. GitHub Actions 또는 Azure DevOps Pipelines로 deployment를 연결합니다.
8. Application Insights를 추가합니다.
9. Azure Cost Management alerts를 설정합니다.
10. Enterprise identity가 필요하면 Entra ID를 사용합니다.

Path I — AWS AWS 중심 팀

적합한 경우: enterprise, regulated app, AWS-heavy customer, AWS engineering support가 있는 팀.

1. beginner AWS frontend/full-stack path가 필요하면 Amplify를 씁니다.
2. Serverless API는 Lambda + API Gateway를 씁니다.
3. Serverless로 충분하지 않은 이유가 명확할 때만 ECS/Fargate 등 container path를 검토합니다.
4. Relational data는 RDS, 명확한 high-scale access pattern은 DynamoDB를 씁니다.
5. AWS-native auth가 필요하면 Cognito를 씁니다.
6. File은 S3, CDN은 CloudFront를 씁니다.
7. Secrets는 Secrets Manager 또는 Parameter Store에 저장합니다.
8. IAM role은 조심해서 설정하고 broad permission을 피합니다.
9. Logs와 metrics는 CloudWatch를 씁니다.
10. AWS Budgets를 즉시 설정합니다.
11. 사용자, 매출, compliance risk가 있다면 experienced help 예산을 잡습니다.

17 비용과 확장성

위험한 비용은 보통 월 구독료가 아닙니다. 위험한 것은 usage-based 비용입니다. Bandwidth, function execution, database read, file egress, AI token, logs, storage가 여기에 해당합니다.

출시 전에 대략 계산하세요.

사용자 1명의 하루 요청 수
× 월 사용자 수
× 요청당 비용
= 월 변동비

그다음 내 가격 정책이 이 비용을 감당하는지 확인해야 합니다.

단계별 비용 감각

이 숫자는 계획용 범위일 뿐 가격 보장이 아닙니다. 플랫폼 가격은 바뀌고, 실제 비용은 로고보다 앱 사용 방식에 더 크게 좌우됩니다.

주요 비용 driver

주의해야 할 숨겨진 한도와 비용

• Egress와 bandwidth. Platform 밖으로 나가는 data가 저장 비용보다 클 수 있습니다.
• AI API 초과 사용. 반복 prompt, 긴 context, retry, bot이 예산을 빠르게 소모합니다.
• Database connection limit. Serverless functions가 connection을 많이 만들 수 있습니다. Pooling을 쓰세요.
• Cold start. 잠자는 free service는 돈 대신 사용자 경험을 잃게 합니다.
• Build minutes. 큰 앱과 잦은 deploy는 무료 build quota를 빨리 씁니다.
• Image optimization. 자동 이미지 기능은 편하지만 별도 사용량 항목이 될 수 있습니다.
• Logs와 analytics. 대량 telemetry를 오래 보관하면 비용이 됩니다.

18 흔한 실수와 문제 해결

아래 실수를 피하면 디버깅 시간과 예상치 못한 비용을 크게 줄일 수 있습니다.

흔한 실수

문제 해결 quick reference

19 사용자와 커뮤니티의 목소리

위의 추천은 의도적으로 의견이 들어간 가이드입니다. 하지만 플랫폼 마케팅처럼 들리면 안 됩니다. 아래는 Hacker News, Reddit, 제품 포럼, Indie Hackers, dev.to, X, 플랫폼 커뮤니티, 바이브 코딩 커뮤니티에서 반복해서 보이는 경험을 직접 인용이 아니라 패턴으로 정리한 것입니다.

이 목소리들의 공통점은 분명합니다. 도구는 강력하지만, 아무 생각 없는 기본값은 비쌉니다. 단순한 스택을 고르고, 제한을 일찍 설정하고, launch를 building의 끝이 아니라 operation의 시작으로 보세요.

20 결정 매트릭스

그래도 결정이 어렵다면

웹앱이면 Vercel + Supabase + Sentry를 쓰고, 정적 사이트면 Cloudflare Pages를 쓰세요. 이 결정은 배우기에 충분히 좋고, 출시하기에 충분히 쉽고, 나중에 다른 개발자가 봐도 이상하지 않습니다.

21 용어 정리

API — 소프트웨어끼리 서로 요청하고 응답하는 방식입니다.

Backend — 사용자가 직접 볼 수 없는 서버 측 코드입니다.

BaaS — Backend-as-a-Service. 데이터베이스, 인증, 저장소, 함수 등을 managed platform으로 제공하는 방식입니다.

CDN — 사용자와 가까운 위치에서 파일을 제공하는 네트워크입니다.

CI/CD — build, test, deploy를 자동화하는 workflow입니다.

Cold start — 잠자고 있던 serverless function이나 service가 첫 요청에서 깨어나느라 생기는 지연입니다.

Container — 앱 실행 환경을 서버마다 일관되게 실행하도록 포장한 단위입니다.

DNS — 인터넷의 주소 시스템입니다.

Egress — cloud나 hosting provider 밖으로 나가는 data입니다. 과금될 수 있습니다.

Environment variables — 코드 밖에 저장하는 설정값입니다.

Frontend — 사용자가 브라우저나 앱에서 보는 부분입니다.

IAM — Identity and Access Management. 주로 cloud permission을 의미합니다.

Object storage — 이미지, PDF, 동영상, backup 같은 파일을 저장하는 공간입니다.

RAG — Retrieval-Augmented Generation. AI가 답하기 전에 문서나 데이터를 검색해 함께 사용하는 방식입니다.

RLS — Row Level Security. 데이터베이스가 직접 강제하는 row 단위 접근 규칙입니다.

Serverless — 서버 관리는 platform이 하고, 개발자는 function code를 배포하는 방식입니다.

Static site — 미리 만들어진 파일을 모든 방문자에게 제공하는 사이트입니다.

Webhook — 어떤 일이 발생했을 때 한 서비스가 다른 서비스로 자동으로 보내는 메시지입니다.

22 마지막 기본값

그래도 모르겠다면 이 조합을 쓰세요.

플랫폼보다 중요한 것은 실제로 배포하는 습관입니다. 진짜 사용자를 안전하게 만날 수 있는 가장 단순한 스택으로 시작하세요. 비용을 모니터링하고, 시크릿을 보호하고, 실제 제약이 생길 때만 업그레이드하면 됩니다.