바이브코딩으로 서비스 만들기 — 시작부터 배포까지 기술 선택 지도

선택지는 왜 이렇게 많아 보일까? — 결정 지도를 읽는 법
두뇌와 손 — LLM 모델과 AI 코딩 도구는 어떻게 나눠서 골라야 할까?
화면은 무엇으로 그릴까 — 프레임워크와 UI 키트의 선택지들
백엔드는 '어느 층'에서 고르는 걸까? — AWS를 어디에 놓아야 하는가
부품 고르기 — 데이터베이스와 로그인은 무엇으로 할까?
코드 보관, 배포, 도메인 — 세상에 공개되기까지 마지막 세 걸음
그래서 왜 Firebase였을까 — 저울에 올린 다섯 개의 질문
Firebase로 정하면 무엇이 따라오고, 배포는 어떤 순서로 흘러갈까?

들어가며 — 이 글이 약속하는 것과 약속하지 않는 것

시작하기 전에 딱 하나만 못을 박고 가겠습니다.

이 글은 "Firebase가 정답이다"라고 말하는 글이 아닙니다.

뒤에 가면 Firebase를 고르는 과정이 나오고, 마지막에는 실제 배포까지 따라갑니다. 그러다 보니 자칫 "그래, Firebase가 최고구나"로 읽힐 수 있는데, 그건 제가 하려는 이야기가 아니에요. 같은 앱을 Supabase로 만들어도, AWS로 만들어도, 서버를 직접 짜서 만들어도 아주 잘 돌아갑니다. 실무에서는 오히려 Firebase가 답이 아닌 경우도 많고요. 그 이유도 7번 섹션에서 정직하게 적어뒀습니다.

제가 하려는 이야기는 이겁니다.

선택지가 이렇게 많은데, 사람들은 대체 무슨 기준으로 하나를 고르는 걸까?

그래서 Firebase는 "정답"이 아니라 하나의 사례로 쓰입니다. 결정이 어떻게 내려지는지 보여주려면 끝까지 따라가는 예시가 하나 필요한데, 그 역할을 맡은 것뿐이에요.

그런데 말이죠, 하필 왜 Firebase를 예시로 골랐냐고 물으신다면 — 바이브코딩으로 첫 서비스를 만들어보는 사람에게는 나쁘지 않은 출발점이기 때문입니다. 이유는 딱 세 가지입니다.

결정해야 할 개수가 줄어듭니다. 로그인·데이터·파일 저장·배포가 세트로 딸려오니, 갈림길 다섯 개 중 두세 개가 자동으로 통과됩니다.
서버를 관리하지 않아도 됩니다. 새벽에 서버가 죽어서 일어나는 일이 없습니다.
공식 문서와 예제가 아주 많습니다. 막혔을 때 검색하면 답이 나옵니다. 이게 초보자에게는 성능보다 중요합니다.

반대로 나중에 사용자가 크게 늘거나, 데이터가 복잡하게 얽히거나, 요금을 촘촘히 통제해야 하는 순간이 오면 다른 선택지로 옮겨가면 됩니다. 처음 고른 것을 평생 쓸 필요는 없습니다. 이사도 하는데 기술 스택쯤이야.

이 글을 다 읽고 나면 이런 상태가 되시면 좋겠습니다.

개발 시작할 때 마주치는 갈림길이 몇 개고 각각 뭘 고르는 건지 안다
각 갈림길에서 초보자에게 쉬운 길과 손이 많이 가는 길을 구분할 수 있다
"Firebase로 시작하는 거, 나도 주말에 한번 해볼 수 있겠는데?" 싶다

마지막 항목을 위해 각 섹션 끝에 "여기서 실제로 할 일"을 한 줄씩 달아뒀고, 맨 뒤에는 첫 주말 코스를 붙여뒀습니다.

전체 지도

바이브코딩 서비스 개발에서 일어날 수 있는 의사결정

자, 본문에 들어가기 전에 지도부터 같이 봅시다. 이 지도는 세 가지 장치로 읽습니다.

왼쪽 위 구석에 범례 박스가 있죠. 3층 케이크 그림이 그려져 있습니다. 이게 이 지도의 열쇠예요. 개발 선택지들은 사실 서로 다른 층에 살고 있는데, 그걸 모르고 한 줄에 늘어놓으면 비교 자체가 안 됩니다. 이 이야기는 4번 갈림길에서 제대로 풀 겁니다.

범례 아래에는 형광펜 자국 두 개가 샘플로 그려져 있습니다. 파란 자국은 "초보자에게 쉬운 길", 빨간 자국은 "전문가 영역"입니다. 여기서 오해하지 마셔야 할 게 있어요. 빨강은 틀린 길이 아닙니다. 손이 많이 가는 길일 뿐이고, 실무에서는 빨강이 정답인 경우가 아주 많습니다. 색은 우열이 아니라 체력 소모량 표시라고 생각해 주세요.

그리고 화면을 가로지르는 굵은 길이 하나 있습니다. 왼쪽 끝 전구에서 출발해 오른쪽 끝 브라우저 창까지 가는 길이에요. 그 위에 나무 표지판 다섯 개가 박혀 있고, 표지판마다 길이 갈라집니다. 굵은 동그라미가 쳐진 ☑ 항목이 이번 사례가 고른 길, 가늘게 적힌 ☐ 항목은 가지 않았지만 충분히 갈 수 있었던 길입니다.

오른쪽을 보시면 갈라졌던 화살표들이 전부 모닥불 하나로 모여듭니다. Firebase죠. 그럼 출발해 볼까요?

1. 선택지는 왜 이렇게 많아 보일까? — 결정 지도를 읽는 법

지도에서 우리는 아직 길에 올라서지도 않았습니다. 왼쪽 위 범례 박스 앞에 서 있는 상태예요.

결정 지도를 읽는 법

바이브코딩(Vibe Coding)이라는 말은 이제 설명이 필요 없을 정도죠. 사람이 자연어로 원하는 걸 말하면 AI가 코드를 만들고, 사람은 방향을 잡아주는 방식. 정의는 이 정도면 충분합니다. 문제는 그다음이에요.

바이브코딩이 퍼지면서 개발자의 시간 배분이 조용히 뒤집혔습니다. 예전엔 "이걸 어떻게 구현하지?"에 시간의 8할이 들어갔는데, 지금은 구현이 빨라진 대신 "무엇으로 만들지 고르는 시간"이 병목이 됐습니다.

비유하자면 이렇습니다. 예전의 개발은 나무를 직접 깎는 목공이었어요. 톱질 실력이 곧 결과물이었죠. 지금은 거대한 가구 매장에 들어와 있는 상태입니다. 조립은 AI가 해줍니다. 대신 매장이 너무 넓어서, 어느 코너로 갈지 못 정하면 아무것도 못 사고 나옵니다.

그래서 지도를 읽는 원칙 세 개를 먼저 깔고 가겠습니다.

원칙 1 — 층을 먼저 구분한다

선택지가 무한해 보이는 가장 큰 이유는, 사실 층위가 다른 것들이 한 바구니에 섞여 있기 때문입니다.

"Firebase 쓸까요, AWS 쓸까요?"

정말 자주 듣는 질문인데, 이건 "비빔밥 먹을까요, 한식 먹을까요?"와 같은 구조입니다. AWS는 클라우드 회사고, Firebase는 그 위에서 돌아가는 서비스 형태예요. 층이 다릅니다.

개발 스택(어떤 기술들을 쌓아 올렸는지를 가리키는 말)은 이렇게 3층으로 나눠 보면 정리됩니다.

층	고르는 것	예시
1층 — 인프라	어느 회사의 땅 위에 지을까	AWS, Google Cloud, Azure, Cloudflare
2층 — 제공 방식	얼마나 직접 만들까	직접 서버 / PaaS / 서버리스 / BaaS
3층 — 부품	무엇을 끼워 넣을까	데이터베이스, 로그인, 파일 저장소

낯선 영어 약자들이 보이시죠. 지금은 몰라도 됩니다. 4번 섹션에서 하나씩 풀 거예요. 지금 기억할 건 "층이 다르면 비교하면 안 된다" 이 한 줄입니다.

원칙 2 — 난이도를 색으로 본다

지도의 파랑/빨강 표시가 그것입니다. 같은 크기 글씨로 나란히 적혀 있으면 모든 선택지가 비슷해 보이지만, 실제로 감당해야 할 부담은 열 배쯤 차이 납니다.

파랑(초보자 친화) — 설정할 게 적고, 관리 부담이 거의 없고, 무료로 시작 가능
표시 없음(중간) — 개념 몇 개만 익히면 혼자서도 감당 가능
빨강(전문가 영역) — 서버 운영·보안·비용을 직접 책임져야 함

전략은 단순합니다. 파랑에서 시작해서, 필요해지면 빨강으로 옮겨간다. 처음부터 빨강에서 시작하면 앱은 못 만들고 서버 설정만 만지다 끝납니다. 실제로 그렇게 지쳐서 그만두시는 분들, 정말 많이 봤어요.

원칙 3 — 되돌리기 쉬운 것부터 정한다

도메인 주소는 나중에 얼마든지 바꿔 붙일 수 있습니다. 화면 디자인도 갈아엎으면 됩니다. 반면 데이터를 어디에 어떤 구조로 저장할지는 사용자가 쌓이기 시작하면 되돌리는 비용이 확 올라갑니다.

그러니 되돌리기 쉬운 건 10분 안에 정하고 넘어가고, 되돌리기 어려운 것에만 고민을 몰아주세요. 지도에서 4번 표지판(백엔드)이 유독 크게 그려진 이유가 그겁니다.

여기서 실제로 할 일 종이 한 장에 "내가 만들 앱이 반드시 해야 하는 일" 세 줄만 적어보세요. (예: 로그인한다 / 일정을 저장한다 / 다른 기기에서도 보인다) 이 세 줄이 앞으로 모든 갈림길의 판단 기준이 됩니다.

참고 자료

2026 AI 코딩 에이전트 비교 가이드

AWS Amplify vs Firebase vs Supabase 2026 비교

2. 두뇌와 손 — LLM 모델과 AI 코딩 도구는 어떻게 나눠서 골라야 할까?

이제 첫 번째 표지판입니다. 지도에서 터미널 창(까만 화면에 명령어를 치는 프로그램) 안에 뇌가 그려진 아이콘이 있는 자리죠.

LLM 모델과 AI 코딩 도구는 어떻게 나눠서 골라야 할까?

여기서 많은 분들이 질문을 섞어서 합니다. "GPT 쓸까요, Claude 쓸까요?"와 "Cursor 쓸까요, Claude Code 쓸까요?"는 다른 층위의 질문입니다. 앞은 모델(두뇌), 뒤는 도구(손) 이야기예요.

자동차로 치면 모델은 엔진, 도구는 차체입니다. 엔진 성능도 중요하지만 같은 엔진을 얹어도 승용차와 트럭은 하는 일이 다르죠. 그리고 요즘 도구들은 대부분 엔진을 바꿔 끼울 수 있습니다. Cursor 안에서 Claude를 쓸 수도, GPT를 쓸 수도 있어요. 그래서 정리하면 이렇습니다.

두뇌는 소모품이고, 손은 오래 씁니다. 모델은 몇 달마다 새 버전이 나오지만, 도구에 익숙해지는 데는 시간이 걸립니다. 그러니 도구를 먼저 고르고, 모델은 그 안에서 바꿔 끼우세요.

두뇌(모델) 선택지

2026년 현재 상용 모델은 크게 네 진영입니다. Anthropic Claude, OpenAI GPT, Google Gemini, xAI Grok. 여기에 오픈소스 진영(Qwen, DeepSeek, Llama 등)이 따라붙습니다.

세부 버전명은 몇 달 단위로 바뀌니 여기서는 적지 않겠습니다. 대신 고르는 기준만 기억하세요.

긴 코드를 통째로 이해해야 하는가 → 한 번에 읽어들이는 분량이 큰 모델
비용이 예민한가 → 매달 정해진 금액을 내는 구독형인지, 쓴 만큼 내는 종량제인지 확인
코드가 외부로 나가면 안 되는가 → 오픈소스 모델을 내 서버에 직접 띄우기 (빨강)

마지막이 빨간 이유는, 모델을 직접 띄우려면 값비싼 GPU 서버를 운영해야 하기 때문입니다. 개인 프로젝트에서는 거의 답이 아닙니다.

손(도구) 선택지

여기가 진짜 갈림길입니다. 성격별로 세 묶음으로 나눠 봅시다.

① 터미널(CLI)형 — 까만 명령창에서 돌아가며 내 컴퓨터의 파일을 직접 고칩니다.

Claude Code — 여러 파일을 한꺼번에 고치는 작업에 강합니다. MCP(AI에게 외부 서비스를 도구처럼 쥐여주는 규격)를 기본으로 지원해서, GitHub이나 Firebase 같은 서비스를 붙여 쓸 수 있습니다.
OpenAI Codex CLI — 명령창·웹·데스크톱 세 형태로 제공. "일감을 던져놓고 자리 뜨기"에 어울립니다.
Gemini CLI — 가볍고 무료 한도가 넉넉한 편.
Aider (빨강) — 오픈소스. 도구 자체는 공짜지만 모델 API 키를 직접 발급받아 관리해야 합니다.

② 에디터(IDE)형 — 코드를 눈으로 보면서 다듬습니다.

Cursor (파랑) — AI가 들어간 코드 편집기. 손에 익는 속도가 가장 빠르다는 평이 많습니다. 다만 쓴 만큼 내는 방식이라 월 비용 변동이 큽니다.
GitHub Copilot (파랑) — 이미 쓰던 편집기에 확장 프로그램으로 붙습니다. 진입 장벽이 가장 낮습니다.
Windsurf, Cline / Roo Code, JetBrains AI — 같은 자리의 다른 선수들.

③ 브라우저·클라우드형 (대부분 파랑) — 설치 없이 웹사이트에서 바로 시작합니다.

Firebase Studio — 브라우저에서 만들고 그대로 배포까지 이어집니다.
Replit, Lovable, v0, Bolt.new — 프롬프트만으로 앱 뼈대를 뽑아주는 쪽에 가깝습니다.

AI가 사고 치는 걸 어떻게 막느냐

성능만큼 중요한 축입니다. AI에게 내 컴퓨터를 맡기는 거니까요. 대략 세 유형입니다.

승인 게이트형 — 위험한 명령을 실행하기 전에 사람에게 물어봅니다. (Claude Code, Cursor)
격리 실행형 — 내 컴퓨터가 아닌 별도 공간에서 먼저 돌려보고, 뭐가 바뀌었는지만 보여줍니다. (Codex, Copilot의 클라우드 기능)
되돌리기 보장형 — 모든 변경을 기록으로 남겨 언제든 취소합니다. (Aider)

그리고 같은 도구라도 내 컴퓨터에 설치하는 판과 웹에서 쓰는 판의 기능이 다릅니다. 설치판은 내 파일을 직접 만지니 강력하지만 권한을 신경 써야 하고, 웹판은 안전한 대신 내 컴퓨터 폴더를 못 봅니다. 이걸 모르고 "왜 내 파일을 못 읽지?" 하며 헤매는 경우가 정말 많아요.

이번 사례의 선택은 Claude Code입니다. 우리가 만들 건 화면만 있는 앱이 아니라 화면·서버 설정·배포 설정이 한 폴더에 섞여 있는 프로젝트예요. 파일 하나를 고치면 옆 파일도 같이 고쳐야 하는 상황이 계속 생깁니다. 이런 작업에서 터미널형이 유리하고, 뒤에서 만날 Firebase·GitHub을 붙여 쓸 수 있다는 점도 맞아떨어졌습니다.

다만 솔직히 말씀드리면, 명령창이 무섭게 느껴지신다면 Cursor나 Copilot으로 시작하셔도 이 글의 나머지는 그대로 적용됩니다. 도구는 되돌리기 아주 쉬운 결정이에요.

여기서 실제로 할 일 도구 하나를 골라 설치하고, "간단한 할 일 목록 화면 하나만 만들어줘"라고 시켜보세요. 결과물보다 승인을 물어보는 방식이 내 성격에 맞는지를 보는 게 목적입니다.

참고 자료

2026 AI 코딩 에이전트 정면 비교

AI 코딩 에이전트 비교 2026: Claude Code vs Codex vs Gemini CLI

코딩용 LLM 비교 2026

Firebase Studio 공식 문서

3. 화면은 무엇으로 그릴까 — 프레임워크와 UI 키트의 선택지들

손에 도구를 쥐었으니 두 번째 표지판입니다. 브라우저 창 안에 체크리스트가 그려진 아이콘, 딱 우리가 만들 일정관리 앱 화면이죠.

프레임워크와 UI 키트의 선택지들

여기서 초심자분들이 제일 크게 좌절합니다. 이름이 너무 많거든요. 그런데 이 많은 이름들은 사실 "집을 어디까지 미리 지어놓고 시작할까" 하나의 축 위에 늘어서 있습니다.

순수 HTML/CSS/JavaScript는 목재와 못만 받는 것입니다. 무엇이든 만들 수 있지만 전부 직접 해야 해요. React 같은 라이브러리는 전동 공구를 함께 받는 것이고요. Next.js 같은 프레임워크는 골조와 배관이 이미 들어간 조립식 주택 키트입니다. 자유도는 줄지만, 주소에 따라 화면을 바꿔주는 기능이나 로그인 처리 같은 게 처음부터 자리를 잡고 있습니다.

프레임워크 선택지

순수 HTML + CSS + JS (파랑) — 페이지 몇 장이면 이게 정답일 수 있습니다. 준비 과정조차 없어요.
React + Vite (파랑) — 화면이 복잡하지만 서버에서 할 일은 별로 없을 때.
Next.js — React에 서버 기능이 붙은 프레임워크. 로그인, 검색엔진 노출이 필요할 때.
SvelteKit — 문법이 간결하고 결과물이 가볍습니다.
Nuxt — Vue 진영의 같은 자리 선수.
Astro — 글이 중심인 사이트(블로그, 문서)에서 강합니다.
Angular (빨강) — 구조가 엄격해서 배울 게 많지만 큰 조직에서 강합니다.
Flutter Web (빨강) — 나중에 모바일 앱까지 같은 코드로 가고 싶을 때.

UI 키트 — 버튼 하나 만들려고 CSS 30줄 쓰지 않기

프레임워크가 골조라면 UI 키트는 마감재입니다. 이걸 안 고르면 버튼 하나 예쁘게 만드는 데 한나절이 갑니다.

Bootstrap (파랑) — 가장 쉽습니다. 정해진 이름 몇 개만 붙이면 화면이 나옵니다.
Tailwind CSS + shadcn/ui — 현재 가장 널리 쓰이는 조합. AI에게 시킬 때도 이 조합을 가장 잘 알아듣습니다.
MUI / Chakra UI / Ant Design — 완성된 부품을 통째로 가져다 쓰는 방식.
디자인을 처음부터 직접 설계 (빨강) — 브랜드가 확고할 때만.

판단 기준 세 개

서버에서 처리할 일이 있는가? 로그인이나, 남에게 보이면 안 되는 비밀 키를 쓰는 작업. 있으면 프레임워크 쪽이 편합니다.
검색엔진에 나와야 하는가? 소개 페이지가 붙는다면 서버가 화면을 미리 만들어 보내주는 방식이 유리합니다.
내가 쓸 배포 서비스가 그걸 공식 지원하는가?

3번이 의외로 결정적입니다. 지도를 보면 2번 표지판에서 5번 표지판(배포)으로 화살표가 길게 이어져 있죠. 배포 서비스들은 특정 프레임워크를 "공식 지원"합니다. 예컨대 Firebase App Hosting은 Next.js와 Angular를 미리 설정된 형태로 지원해요. 지원 목록에 있는 걸 고르면 설정 씨름 없이 커밋 한 번으로 배포가 됩니다. 목록 밖이면 준비 과정을 직접 손봐야 하고요. 화면 선택은 배포 선택과 한 세트라는 걸 여기서 알아채는 게 좋습니다.

이번 사례의 선택은 Next.js + Tailwind/shadcn-ui입니다. 일정관리 앱은 로그인이 필요하고, 소개 페이지가 붙을 여지가 있고, 무엇보다 가려는 배포 서비스가 Next.js를 공식 지원합니다. 세 기준이 모두 같은 방향을 가리켰어요.

여기서 실제로 할 일 아직 아무것도 설치하지 마세요. 대신 6번 섹션까지 읽고 배포 서비스를 먼저 정한 다음, 그 서비스의 지원 목록에서 프레임워크를 고르세요. 순서를 바꾸면 나중에 고생합니다.

참고 자료

Firebase Hosting × Next.js 통합 문서

Firebase App Hosting — 지원 프레임워크

4. 백엔드는 '어느 층'에서 고르는 걸까? — AWS를 어디에 놓아야 하는가

세 번째 표지판입니다. 지도에서 가장 큰 상자, 3층 건물 단면도가 그려진 자리예요. 그리고 옆에 이런 말풍선이 붙어 있죠.

백엔드는 '어느 층'에서 고르는 걸까? — AWS를 어디에 놓아야 하는가

"AWS는 1층 회사, Firebase는 2층 방식 — 맞상대는 AWS Amplify!"

먼저 용어 하나만 풀고 갑시다. 백엔드는 사용자 눈에 안 보이는 쪽, 그러니까 데이터를 저장하고 로그인을 처리하는 부분입니다. 화면(프론트엔드)이 식당의 홀이라면 백엔드는 주방이에요.

솔직히 말씀드리면, 이 원고의 초안 지도에는 AWS라는 이름이 아예 없었습니다. 백엔드 칸에 "직접 서버 / 서버리스 / BaaS" 세 개만 적어뒀거든요. 왜 그랬냐면 AWS가 저 세 칸 중 어디에도 딱 안 들어가기 때문입니다. AWS는 셋 다 파는 회사니까요.

그런데 그건 변명이고, 세계에서 가장 많이 쓰이는 클라우드가 지도에 없는 건 그냥 잘못입니다. 그래서 이 표지판을 3층으로 쪼갰습니다.

1층 — 인프라: 어느 회사 땅 위에 지을까

실제 서버 컴퓨터를 잔뜩 가지고 있는 회사들입니다.

AWS (빨강) — 압도적 1위. 서비스가 200개가 넘어서 뭘 골라야 할지부터 막막합니다. 그게 강점이자 진입 장벽이에요.
Google Cloud (GCP) — Firebase의 본진. AWS보다 서비스 수가 적어 덜 복잡합니다.
Microsoft Azure (빨강) — 기업 환경, 특히 Microsoft 제품을 쓰는 조직에서 강합니다.
Cloudflare — 원래 전 세계에 데이터를 빠르게 배달해주는 회사였는데, 지금은 데이터베이스와 서버 기능까지 갖췄습니다.
VPS 사업자 (빨강) — DigitalOcean, Vultr, Hetzner 등. 리눅스 서버 한 대를 통째로 빌려 직접 세팅합니다.
국내 클라우드 — 네이버 클라우드, NHN Cloud 등. 국내 규제나 공공 프로젝트에서 선택됩니다.

2층 — 제공 방식: 얼마나 직접 만들까

같은 AWS 위에서도 여기서 완전히 다른 삶이 펼쳐집니다. 이 층이 이번 갈림길의 진짜 핵심이에요.

직접 서버 (빨강) — 빈 서버 컴퓨터를 빌려서 프로그램을 직접 올립니다. 자유도 100%. 대신 서버가 죽으면 내가 살리고, 보안 업데이트도 내 몫입니다.
컨테이너 PaaS — Render, Railway, Fly.io 등. 코드를 올리면 알아서 실행 환경을 만들어 돌려줍니다. 직접 서버와 아래의 서버리스 중간쯤.
서버리스 함수 — 서버를 늘 켜두지 않고, 요청이 올 때만 잠깐 깨어나 처리하고 다시 잠듭니다. 관리 부담은 줄지만 데이터베이스와 로그인은 따로 마련해야 해요.
BaaS (Backend as a Service, 서비스로 제공되는 백엔드) (파랑) — 로그인·데이터베이스·파일 저장이 이미 세트로 조립된 주방을 통째로 빌립니다.

주거 형태로 비유하면 이렇습니다.

방식	비유	내가 하는 일
직접 서버	자취	가전도 내가 사고, 고장 나면 내가 부름
컨테이너 PaaS	원룸 임대	기본 옵션은 있고 관리비는 냄
서버리스 함수	공유 주방	필요할 때만 쓰고 쓴 만큼 냄
BaaS	풀옵션 오피스텔	짐만 풀면 됨. 대신 벽지는 못 뜯음

혼자서 첫 서비스를 만든다면 대부분 BaaS가 맞습니다. 서버 운영은 그 자체로 하나의 직업이에요. 아직 사용자도 없는 앱을 위해 그 직업을 겸업할 이유가 없습니다.

3층 — BaaS 후보: 세트 안에 무엇이 들었나

2층에서 BaaS를 골랐다면, 이제 브랜드를 고릅니다.

Firebase (파랑) — 구글. 데이터가 바뀌면 화면이 저절로 갱신되는 기능이 기본으로 들어 있습니다. 문서와 예제가 압도적으로 많습니다.
Supabase (파랑) — 데이터를 표 형태로 다루는 방식(SQL)을 그대로 씁니다. 요금이 정액제라 예측이 쉬운 편.
AWS Amplify (빨강) — AWS 진영에서 Firebase의 진짜 맞상대입니다. 인증·데이터·파일 저장을 하나로 묶어주죠. 확장성과 기업 보안 요구를 맞추는 데는 최고지만, 배울 게 가장 많습니다.
Appwrite / PocketBase — 오픈소스 진영. PocketBase는 실행 파일 하나로 돌아갈 만큼 가볍습니다.
Convex — 코드로 데이터를 다루고, 화면 갱신이 기본으로 딸려옵니다.

그래서 AWS는 왜 안 골랐나

AWS가 나빠서가 아닙니다. 이번 사례의 조건에서 AWS를 고르면 이런 일이 벌어집니다. Amplify를 쓰더라도 그 아래에 있는 인증 서비스, 데이터 서비스, 그리고 "누가 무엇을 할 수 있는지 정하는 권한 설정"을 최소한은 이해해야 하는데, 그 개념들을 익히는 시간이 일정관리 앱을 만드는 시간보다 깁니다. 그건 앱을 만드는 게 아니라 AWS를 배우는 프로젝트가 되는 거예요.

거꾸로 말하면, 사용자가 수십만 명이 되거나 회사 인프라가 이미 AWS 위에 있다면 Amplify가 정답입니다. 빨간 형광펜은 "지금의 나에게 무겁다"는 뜻이지, 영원히 가지 말라는 뜻이 아닙니다.

이번 사례의 선택은 1층 Google Cloud + 2층 BaaS + 3층 Firebase입니다.

여기서 실제로 할 일 1층은 건너뛰세요. BaaS를 고르면 1층은 그쪽 회사가 알아서 처리합니다. 여러분이 실제로 결정할 건 3층 브랜드 하나뿐입니다. 이게 BaaS의 가장 큰 이득이에요.

참고 자료

AWS Amplify vs Firebase vs Supabase 2026 비교

Firebase vs AWS Amplify 2026

Vercel vs Cloudflare vs Firebase — 플랫폼 성격 비교

5. 부품 고르기 — 데이터베이스와 로그인은 무엇으로 할까?

네 번째 표지판, 3층에 해당하는 자리입니다. 데이터베이스 아이콘 두 개와 열쇠가 그려져 있죠.

데이터베이스와 로그인은 무엇으로 할까?

먼저 좋은 소식부터. BaaS를 골랐다면 이 표지판은 그냥 통과됩니다. Firebase를 고르는 순간 데이터베이스는 Firestore, 로그인은 Firebase Auth로 자동으로 정해지니까요.

그런데도 이 갈림길을 따로 설명하는 이유가 있습니다. 언젠가 BaaS를 안 쓰는 날이 오면, 여기서 하나하나 직접 골라야 하기 때문입니다. 지금 눈에 익혀두면 그때 길을 잃지 않아요. 부담 갖지 말고 "이런 게 있구나" 정도로 훑고 넘어가셔도 됩니다.

데이터베이스 — 표냐 서랍이냐

이름은 많지만 고르는 기준은 하나로 줄일 수 있습니다. 내 데이터가 표에 가까운가, 서랍에 가까운가.

표(엑셀 시트처럼 줄과 칸이 정해진 형태) — 전문 용어로는 관계형 또는 SQL이라고 부릅니다.

Supabase (PostgreSQL) (파랑), Neon, PlanetScale
AWS RDS, Google Cloud SQL (빨강) — 강력하지만 설정할 게 많습니다.

서랍(사람마다 자기 서랍이 있고 그 안에 카드가 쌓이는 형태) — 전문 용어로는 문서형 또는 NoSQL입니다.

Firestore (파랑) — Firebase의 심장. 데이터가 바뀌면 화면이 저절로 갱신됩니다.
MongoDB Atlas — 문서형의 대표주자.
DynamoDB (빨강) — AWS의 초고속 저장소. 대신 데이터를 어떻게 꺼내 쓸지 미리 다 설계해야 합니다.

그 밖에 — 전 세계에 복사본을 뿌려두고 가까운 데서 읽게 하는 Cloudflare D1 / Turso, 코드로 데이터를 다루는 Convex, 임시 데이터를 빠르게 담아두는 Redis(Upstash) 등이 있습니다. 지금은 이름만 알아두시면 충분합니다.

일정 데이터를 그려보면 사용자 → 그 사람의 일정 목록 → 각 일정(제목, 시간, 완료 여부)입니다. 사용자마다 자기 서랍이 있고 그 안에 카드가 쌓이는 구조죠. 얽힘이 적으니 서랍형이 자연스럽습니다. 반대로 "일정 ↔ 프로젝트 ↔ 팀 ↔ 권한"이 서로 여러 개씩 얽히는 협업 도구였다면, 여러 표를 이어 붙여 조회하는 게 강한 표 형태가 유리했을 겁니다.

로그인 — 절대 직접 만들지 마세요

이건 좀 강하게 말씀드리겠습니다. 로그인 기능은 직접 구현하지 마세요. 비밀번호를 안전하게 저장하는 법, 로그인 상태를 유지하는 법, 비밀번호 재설정, 소셜 로그인 연동… 하나만 틀려도 사용자 계정이 통째로 털립니다. 자물쇠는 깎아 쓰는 게 아니라 사서 쓰는 겁니다.

Firebase Auth (파랑) — 이메일·구글 로그인이 몇 줄로 붙습니다.
Supabase Auth (파랑) — Supabase를 쓴다면 자연스럽게 딸려옵니다.
Clerk (파랑) — 로그인 화면 디자인까지 통째로 제공합니다. 붙이는 속도가 가장 빠른 편.
Auth.js (구 NextAuth) — 무료지만 설정을 직접 합니다.
Auth0 — 기업용 표준. 기능이 많고 요금은 사용자 수에 따라 오릅니다.
AWS Cognito (빨강), Keycloak 직접 운영 (빨강)

이번 사례의 선택은 Firestore + Firebase Auth입니다. 정확히는 "고른 것"이 아니라 "따라온 것"에 가깝습니다. 4번 표지판에서 Firebase를 고르는 순간 이 둘이 세트로 딸려왔어요.

여기서 실제로 할 일 이 섹션은 외우지 마세요. "로그인은 직접 만들지 않는다" 이 한 줄만 가져가시면 됩니다. 나머지는 필요해질 때 다시 펴보면 됩니다.

참고 자료

서버리스 DB 비교 2026 — Supabase · Neon · PlanetScale · Turso · Convex

DB 무료 티어 비교 2026

인증 서비스 비교 2026 — Auth0 · Clerk · Supabase Auth · Firebase Auth

6. 코드 보관, 배포, 도메인 — 세상에 공개되기까지 마지막 세 걸음

코드 보관, 배포, 도메인 — 세상에 공개되기까지 마지막 세 걸음

다섯 번째 표지판입니다. 옥토캣과 로켓, 지구본이 한 상자 안에 모여 있는 자리죠. 이 셋은 실제로 한 덩어리로 움직이기 때문에 묶어서 봅니다.

걸음 1 — 코드 보관: GitHub이 사실상 기본값

GitHub, GitLab, Bitbucket이 나란히 적혀 있지만 개인 프로젝트라면 십중팔구 GitHub입니다. 그러니 "무엇을 고를까"보다 "왜 이게 지도 한복판에 있는가"를 이야기하는 게 낫겠습니다.

Git을 처음 배울 때 흔한 오해가 "코드를 백업하는 곳"이라는 생각입니다. 절반만 맞아요. Git의 본질은 백업이 아니라 되돌릴 권리입니다.

게임의 세이브 파일을 떠올려 보세요. 세이브가 없으면 보스에게 지는 순간 처음부터 다시 해야 하니 위험한 시도를 못 합니다. 세이브가 있으면 과감하게 덤빌 수 있죠. 커밋(변경 사항을 기록으로 남기는 것)이 바로 그 세이브 파일입니다.

그리고 이게 바이브코딩에서 특히 중요합니다. AI에게 "이 기능 추가해줘"라고 시켰는데 파일 열 개가 한꺼번에 바뀌었다고 해봅시다. 커밋을 안 해뒀다면 어디가 망가졌는지 찾을 방법이 없어요. 해뒀다면 명령어 하나로 AI가 뭘 건드렸는지 전부 보이고, 마음에 안 들면 통째로 되돌리면 됩니다. AI에게 과감하게 맡길 배짱은 Git에서 나옵니다.

여기서 실제로 정할 것은 셋입니다.

공개 여부 — 누구나 볼 수 있게(public) 할지, 나만 볼 수 있게(private) 할지.
.gitignore 파일 — 올리면 안 되는 것을 미리 막아두는 목록입니다. 비밀번호나 API 키가 담긴 파일은 반드시 여기 적으세요. 한 번 올라가면 나중에 지워도 기록에 남습니다.
브랜치 — 혼자면 main 하나로 충분합니다.

걸음 2 — 배포: 어디에 올려야 URL이 생기나

용어부터 정리합시다. "독립된 URL로 서비스한다"는 말에는 사실 세 가지가 섞여 있습니다.

호스팅 — 내 코드를 항상 켜져 있는 컴퓨터에 올려두기
도메인 — 사람이 읽을 수 있는 주소 얻기
HTTPS — 주소 앞에 자물쇠 달기 (안전한 연결이라는 표시)

예전엔 셋 다 별개의 고생이었는데, 지금은 1번을 정하면 2·3번이 자동으로 딸려옵니다. 이게 요즘 배포가 쉬워진 진짜 이유예요.

Vercel (파랑) — Next.js를 만든 회사. Next.js 지원이 가장 매끄럽습니다.
Netlify (파랑) — 프론트엔드 배포의 오랜 강자.
Firebase App Hosting (파랑) — Next.js·Angular를 공식 지원하고, GitHub만 연결하면 자동 배포가 됩니다.
Cloudflare Pages — 전 세계 배달망이 가장 넓고 무료 사용량 제한이 사실상 없습니다.
Render / Railway — 항상 켜져 있는 서버가 필요할 때.
GitHub Pages (파랑) — 정적인 페이지만 올릴 수 있습니다. 서버 기능은 못 씁니다.
AWS Amplify Hosting (빨강), 직접 VPS 배포 (빨강)

걸음 3 — 도메인: 이름은 마지막에 붙인다

배포하면 서비스가 무료 주소를 하나 줍니다. Firebase는 백엔드이름--프로젝트ID.리전.hosted.app, Vercel은 프로젝트명.vercel.app 형태예요. 이 순간부터 이미 "독립된 URL"입니다. 누구에게든 링크를 보낼 수 있어요.

my-todo.app 같은 진짜 내 주소를 원한다면 도메인을 삽니다. Cloudflare Registrar(가장 저렴한 편), Porkbun, Namecheap, 국내라면 가비아 같은 곳이죠. 사고 나면 배포 서비스가 알려주는 DNS 레코드(이 도메인이 어느 서버를 가리키는지 적어두는 메모)를 등록합니다. 소유권 확인용 메모를 하나 넣고, 실제 주소를 가리키는 메모를 하나 넣으면, 자물쇠(SSL 인증서)는 자동으로 발급됩니다. 보통 몇 시간, 최대 24시간이에요.

꼭 드리는 조언 하나. 도메인은 마지막에 사세요. 앱이 제대로 도는 걸 무료 주소로 먼저 확인하고 이름을 붙이는 겁니다. 이름부터 짓고 시작하면 이름값에 눌려 정작 앱을 못 만드는 일이 생각보다 흔합니다.

이번 사례의 선택은 GitHub + Firebase App Hosting + 무료 자동 도메인입니다.

여기서 실제로 할 일 GitHub 계정만 먼저 만들어 두세요. 그리고 저장소를 하나 만들 때 .gitignore 항목에서 Node를 선택하는 것만 기억하세요. 이 한 번의 클릭이 비밀 키 유출을 막아줍니다.

참고 자료

Firebase App Hosting 시작하기 — 자동 부여 도메인 형식

Firebase Hosting 커스텀 도메인 연결 및 SSL 자동 발급

웹 호스팅 비교 2026 — Vercel · Netlify · Cloudflare · Render

7. 그래서 왜 Firebase였을까 — 저울에 올린 다섯 개의 질문

지도의 오른쪽 구역으로 넘어왔습니다. 모닥불 아이콘 아래 손저울이 그려져 있고, 접시가 세 개 달려 있죠. Firebase, Supabase, AWS Amplify입니다.

그래서 왜 Firebase였을까 — 저울에 올린 다섯 개의 질문

다시 한번 말씀드립니다. 셋 다 좋은 선택지입니다. 같은 앱을 어느 쪽으로 만들어도 잘 돌아갑니다. 다만 이번 사례의 조건에서 저울이 한쪽으로 기울었고, 그 과정을 다섯 개의 질문으로 재구성해 보겠습니다. 여러분이 다음 프로젝트에서 이 저울을 그대로 다시 쓰실 수 있게요. 사실 이 섹션이 이 글에서 가장 오래 쓸모 있는 부분입니다.

질문 1. 혼자서 관리할 수 있는가?

이 프로젝트에는 서버 담당자가 없습니다. 혼자예요. "장애가 났을 때 내가 새벽에 일어나야 하는가"가 첫 필터입니다. 직접 서버가 여기서 탈락했고, BaaS 셋이 남았습니다.

여기서 Amplify가 먼저 기울었어요. Amplify는 겉으로는 하나의 도구지만 그 아래에 인증·데이터·권한 서비스가 각각 따로 있고, 문제가 생기면 그것들을 직접 들여다봐야 합니다. 반면 Firebase는 로그인·데이터·파일·배포가 하나의 관리 화면 안에 있어요. 혼자 하는 사람에게 "볼 창이 하나"라는 건 생각보다 큰 차이입니다.

질문 2. 화면이 저절로 갱신되어야 하는가?

일정관리 앱을 떠올려 보세요. 휴대폰에서 일정을 추가했는데 노트북 브라우저도 켜져 있다면, 그 화면도 같이 바뀌어야 자연스럽습니다.

Firestore는 이 기능이 부가 기능이 아니라 기본 성격입니다. 데이터를 "구독"해두면 서버 값이 바뀔 때 화면이 알아서 갱신돼요. 새로고침이라는 개념이 사라집니다. 비유하자면, 보통의 데이터 조회가 도서관에 책을 빌리러 가는 것이라면 이건 신문 정기구독입니다. 새 소식이 나오면 배달부가 알아서 문 앞에 놓고 가죠.

질문 3. 데이터 모양이 서랍형인가, 표형인가?

5번 표지판에서 이미 답이 나왔습니다. 사용자별 일정 서랍 구조는 서랍형에 자연스럽습니다. 여기서 Supabase가 조금 기울었어요.

다만 이건 아슬아슬한 판정이었다는 걸 밝혀둡니다. 나중에 "일정에 태그를 달고 태그별 통계를 내겠다"는 요구가 생기면 표 형태가 그리워질 겁니다. 만약 여러분의 앱이 처음부터 통계나 복잡한 조회를 염두에 둔다면, 이 질문에서 저울은 반대로 기울 수 있습니다.

질문 4. 배포까지 이어지는가?

이게 결정타였습니다. Firebase를 백엔드로 정하는 순간 6번 표지판(배포)의 답이 거의 정해집니다. Firebase App Hosting은 Next.js를 공식 지원하고, 같은 프로젝트 안의 로그인·데이터와 자동으로 연결됩니다.

백엔드와 배포가 다른 회사에 있으면 설정값을 양쪽에 넣고, 권한을 양쪽에서 열고, 문제가 나면 어느 쪽 탓인지 찾아야 합니다. 그 왕복이 통째로 사라지는 거예요. 한 결정이 다음 결정을 대신 내려준다 — 개인 프로젝트에서 이건 정말 큰 이득입니다.

질문 5. 요금 사고를 막을 수 있는가?

여기서는 Firebase가 불리한 쪽입니다. 정직하게 적어둡니다.

Firebase App Hosting을 쓰려면 쓴 만큼 내는 Blaze 요금제로 바꿔야 합니다. 무료 한도 자체는 있지만 카드 등록이 필요하고, 방문자가 갑자기 몰리면 요금도 함께 튈 수 있어요. 반면 Supabase는 정액제라 예측이 쉽고, Cloudflare는 무료 사용량 제한이 사실상 없습니다.

그래서 이 선택에는 조건이 붙었습니다. 예산 알림을 반드시 걸어둔다. 저울은 기울었지만, 기울인 대가를 알고 기울인 겁니다.

그리고 이게 제가 가장 전하고 싶은 태도이기도 해요.

좋은 결정은 단점이 없는 선택이 아니라, 단점을 알고 대비한 선택입니다.

정리하면 이렇습니다. 다섯 질문 중 넷은 Firebase 쪽으로, 하나는 반대쪽으로 기울었습니다. 만약 여러분의 상황에서 5번(요금 통제)이 가장 중요하다면, 같은 저울로 Supabase나 Cloudflare가 나올 수 있습니다. 저울은 그대로 쓰고 무게추만 바꾸면 됩니다.

여기서 실제로 할 일 1번 섹션에서 적어둔 "내 앱이 반드시 해야 하는 일 세 줄"을 다시 꺼내서, 이 다섯 질문에 각각 답해보세요. 답이 Firebase가 아니어도 괜찮습니다. 답을 아는 것보다 저울을 갖는 게 중요합니다.

참고 자료

Firebase App Hosting — Blaze 요금제 요구사항

AWS Amplify vs Firebase vs Supabase 2026 — 아키텍처와 학습 곡선

Supabase vs Firebase 2026 — 요금 비교

Firebase 무료·유료 요금제(Spark vs Blaze) 정리

8. Firebase로 정하면 무엇이 따라오고, 배포는 어떤 순서로 흘러갈까?

지도의 오른쪽 끝입니다. 네모 블록 네 개가 한 상자에 묶여 "세트로 온다"고 적힌 그림, 그 아래 컨베이어 벨트가 마지막 조각이죠.

Firebase로 정하면 무엇이 따라오고, 배포는 어떤 순서로 흘러갈까?

하나를 고르면 넷이 따라온다

Firebase를 고른다는 건 데이터베이스 하나를 고르는 게 아닙니다. 세트가 통째로 딸려옵니다.

Authentication — 이메일·구글 로그인을 붙여 씁니다.
Firestore — 일정 데이터가 쌓이는 서랍장.
Storage — 첨부파일이나 사진 자리. 지금 안 써도 나중에 열면 됩니다.
App Hosting — 앱이 실제로 돌아가는 자리.

진짜 이득은 기능 개수가 아니라 이것들이 서로를 이미 알고 있다는 점입니다. "로그인한 사람만 자기 일정을 읽고 쓸 수 있다"는 규칙을 몇 줄 적어두면, 로그인 기능이 확인한 신원을 데이터베이스가 그대로 알아듣습니다. 다른 회사 서비스를 조합했다면 이걸 잇는 코드를 직접 짜야 했을 부분이에요.

가구로 비유하면, 낱개로 사면 나사 규격이 안 맞아 어댑터를 사러 다시 나가야 합니다. 세트로 사면 상자 안에 맞는 나사가 들어 있죠. 대신 그 브랜드에 묶입니다. 나중에 옮기려면 짐을 다시 싸야 해요. 이걸 "한 회사에 묶인다"고 표현하는데, 초기 개인 프로젝트에서는 대체로 감수할 만한 대가입니다.

커밋 한 번이 배포가 되는 파이프라인

컨베이어 벨트를 따라가 봅시다.

Firebase 프로젝트 생성 — 콘솔(관리 화면)에서 프로젝트를 만듭니다.
Blaze 요금제로 전환 — App Hosting을 쓰려면 필수. 이때 예산 알림을 함께 설정하세요. 7번의 조건이 여기서 회수됩니다.
GitHub 저장소 연결 — 콘솔에서 App Hosting을 열고 저장소 접근 권한을 줍니다.
백엔드 생성 — 네 가지를 정합니다. 서비스할 지역(사용자와 가까운 곳), 앱 폴더 위치, 지켜볼 브랜치(보통 main), 자동 배포 사용 여부.
비밀 값 등록 — API 키 같은 건 코드에 적지 않고 여기 넣습니다. .gitignore로 막아둔 이유가 여기서 회수됩니다.
git push — 그리고 이게 끝입니다.

6번 이후에 자동으로 벌어지는 일은 이렇습니다. 커밋이 감지되면 → 소스를 받아 실행 가능한 형태로 만들고 → 앱이 돌아가는 데 필요한 것들을 상자 하나에 담고 → 새 버전을 띄운 뒤 정상 동작을 확인하고 → 접속을 새 버전으로 넘깁니다. 전 세계 배달망(CDN)도 함께 붙습니다.

배포가 끝나면 백엔드이름--프로젝트ID.리전.hosted.app 주소가 살아납니다. 처음엔 5분쯤 기다려야 열려요. 이 주소가 여러분의 첫 독립 URL입니다.

공개 다음 날 아침에 할 일

배포로 끝이 아닙니다. 최소한 이 셋은 켜두세요.

예산 알림 — 쓴 만큼 내는 방식의 유일한 방어선입니다. 무조건 첫날 설정.
에러 추적 — Sentry나 Firebase Crashlytics. 사용자가 겪은 오류를 내가 모르고 지나가지 않게.
사용량 확인 — Firebase 콘솔의 사용량 화면. 어느 기능이 요금을 먹는지 보입니다.

그래서, 첫 주말 코스

여기까지 읽고 "해볼 만한데?" 싶으시다면, 실제로 이 정도가 하루치입니다.

순서	할 일	예상 시간
1	AI 코딩 도구 하나 설치 (Cursor나 Claude Code)	20분
2	GitHub 계정 만들고 빈 저장소 생성 (`.gitignore`는 Node 선택)	15분
3	AI에게 "Next.js로 할 일 목록 앱 만들어줘" 시키고 내 컴퓨터에서 열어보기	1시간
4	Firebase 프로젝트 생성 + 로그인 기능 붙이기	1시간
5	일정 데이터를 Firestore에 저장하도록 연결	1시간
6	GitHub에 올리고 App Hosting 연결 → `git push` → 주소 열어보기	40분
7	예산 알림 설정	10분

막히는 지점은 대개 4번과 6번입니다. 그리고 그 두 군데는 공식 문서에 단계별 안내가 잘 되어 있어요. 아래 참고 자료의 시작 가이드와 Codelab을 그대로 따라가시면 됩니다.

마지막으로, 지도를 다시 봅시다

왼쪽 끝에서 오른쪽 끝까지 한 번에 훑어보세요. 범례 하나, 표지판 다섯, 합류점 하나였습니다.

그런데 눈치채셨을까요. 뒤로 갈수록 고민이 줄었습니다. 1번 표지판에서는 선택지가 열 개가 넘었는데, 6번 배포에서는 사실상 하나로 좁혀져 있었어요. 앞의 결정이 뒤의 선택지를 계속 깎아냈기 때문입니다. Next.js를 골랐기에 그걸 지원하는 곳만 남았고, Firebase를 골랐기에 배포가 따라왔죠.

그래서 마지막으로 드리고 싶은 말은 이겁니다.

선택지가 많아 보이는 건 대개 아직 앞의 결정을 안 했기 때문입니다.

다 알아보고 고르려 하지 마세요. 층을 먼저 정하고, 파란 칸에서 하나 고르고, 되돌리기 쉬운 것부터 정하면 나머지는 저절로 줄어듭니다.

그리고 다시 한번, Firebase는 정답이 아니라 출발점입니다. 이 지도의 진짜 값어치는 "Firebase를 쓰세요"가 아니라, 여러분이 다음 프로젝트에서 다른 답을 스스로 고를 수 있게 되는 것에 있습니다. 그러니 일단 길 위로 한 걸음 올라서세요. 다음 갈림길은 걸어가면서 보면 됩니다.

참고 자료

Firebase App Hosting 시작하기 — GitHub 연결부터 배포까지

Firebase App Hosting 개요 — 자동 배포 동작 방식

App Hosting 정식 출시(GA) 발표

Firebase Hosting 커스텀 도메인 연결

Firebase × Next.js 통합 Codelab (단계별 실습)

바이브코딩으로 서비스 하나 만들기 — 시작부터 배포까지, 갈림길 지도

목차