기획부터 앱스토어 등록까지 — 개발자가 쓴 솔직한 사이드 프로젝트 분투기. 예상 일정은 항상 틀렸다.
처음 아이디어가 떠올랐을 때 나는 노션을 열고 "예상 출시일: 3개월 후"라고 적었다. Next.js로 웹앱, 모바일은 PWA로 감싸면 되니까 빠를 거라 생각했다. 기획 2주, 개발 6주, QA 2주, 출시. 완벽한 계획이었다.
실제로는 7개월이 걸렸다.
이 글은 그 7개월을 있는 그대로 기록한 것이다. 성공담이 아니다. 오히려 "왜 이렇게 오래 걸렸지?"를 돌아본 반성문에 가깝다. 비슷한 여정을 준비 중인 분들에게 솔직한 참고서가 됐으면 한다.
Phase 0. 아이디어 — 가장 들뜨고, 가장 위험한 시간
1주
아이디어 단계에서 내가 기획한 기능은 총 23개였다. MVP를 만들어야 한다는 걸 머리로는 알면서도, "이것도 있어야 하고, 저것도 넣으면 좋겠고"가 멈추질 않았다. 퇴근 후 피자 시키며 혼자 기획서 보는 그 시간이 사이드 프로젝트에서 제일 행복한 순간인 것 같다. 아직 코드를 한 줄도 안 짰으니까.
Phase 1. 기술 스택 선택 — 이것도 생각보다 오래 걸린다
2주
// 최초 구상 (Day 1)
// Next.js + Firebase + styled-components + React Native
// 1차 변경 (Day 8) — "Firebase 비용이 무서워"
// Next.js + Supabase + Tailwind + React Native
// 최종 결정 (Day 13) — "React Native 러닝커브 지금 감당 안 됨"
const finalStack = {
frontend: 'Next.js 14 (App Router)',
backend: 'Supabase (Auth + DB + Storage)',
styling: 'Tailwind CSS + shadcn/ui',
mobile: 'PWA (Capacitor로 앱 래핑)', // 타협
deploy: 'Vercel',
};스택 결정이 끝나고 나서도 보일러플레이트 세팅에 4일이 더 갔다. ESLint, Prettier, Husky, 폴더 구조, 환경변수 관리, Supabase 로컬 세팅. 이 단계를 가볍게 보면 나중에 더 힘들다는 걸 알지만, 그래도 예상보다 항상 오래 걸린다.
Phase 2. 개발 — 처음 2주와 나머지 6주가 완전히 다르다
2주
5주
개발 5주 차쯤에 커밋 히스토리를 보다가 충격을 받았다. 일주일 전 커밋 메시지가 fix: 진짜로 고쳐짐이었다. 그 전 커밋은 fix: 제발이었다. 그리고 그 전은 fix: 왜 안 돼. 아마 그 주에 Supabase의 Row Level Security 정책이랑 씨름하던 것 같다.
"사이드 프로젝트는 세 번 포기하고 싶을 때 버티면 완성된다. 나는 다섯 번 포기하고 싶었다."
— 개발 6주 차 일기1. Supabase RLS + Next.js 서버 컴포넌트 — 서버에서 인증된 유저로 DB 접근하는 패턴을 이해하는 데 3일
2. Capacitor + Next.js PWA 빌드 — iOS Safari 뷰포트 높이 버그. 100vh가 주소창 포함 계산되는 문제. 해결법이
dvh 단위 하나였는데 이걸 찾는 데 이틀3. 이미지 업로드 + Supabase Storage + CORS — 로컬에서는 되는데 프로덕션에서 안 되는 CORS 이슈. 원인은 Storage 버킷 정책 설정 한 줄이었다
Phase 3. "기능은 다 됐는데" — 디자인이 발목을 잡다
4주
개발자 입장에서 제일 과소평가하는 게 디자인 공수다. "shadcn 쓰면 예쁘게 나오겠지"라고 생각했는데, 컴포넌트가 예쁜 것과 앱 전체가 예뻐 보이는 것은 완전히 다른 문제였다. 간격, 색상 체계, 타이포그래피, 빈 상태(empty state) 화면, 로딩 스켈레톤. 이것들을 하나하나 잡는 데 4주가 걸렸다.
| 작업 항목 | 예상 공수 | 실제 공수 | 차이 |
|---|---|---|---|
| 색상 시스템 / 다크모드 | 2일 | 5일 | +3일 |
| 모바일 반응형 조정 | 3일 | 7일 | +4일 |
| 로딩 / 에러 / 빈 상태 UI | 1일 | 4일 | +3일 |
| 앱 아이콘 / 스플래시 스크린 | 반나절 | 3일 | +2.5일 |
| 온보딩 플로우 | 2일 | 2일 | 예상 적중 |
온보딩 플로우만 예상 적중이었다. 나머지는 전부 초과였다. 특히 다크모드는 "그냥 CSS 변수 바꾸면 되지"라고 생각했다가 크게 당했다. 이미지, 그림자, 반투명 레이어가 모두 다크모드에서 다시 손봐야 했다.
Phase 4. QA — 혼자 하는 테스트의 한계
3주
개발자는 앱의 올바른 사용법을 알고 쓴다. 실제 사용자는 내가 상상도 못 한 순서로 화면을 탐색한다. 지인 베타 5명이 찾아낸 버그 중 3개는 "이 버튼을 왜 저 타이밍에 누르지?"라고 생각한 케이스였다. 그게 실제 사용자였다.
Phase 5. 앱스토어 등록 — 여기서 또 막힌다
3주
앱스토어 등록을 준비하면서 처음 알게 된 것들이 생각보다 많았다. 개인정보 처리방침 페이지 따로 만들기, 앱 심사용 계정 제공, 특정 기능 사용 이유 명시(카메라, 알림 등 권한별로), 스크린샷은 기기별로 최소 3장씩. Play Store는 앱 카테고리별로 추가 서류가 붙는 경우도 있었다.
• 개인정보 처리방침 URL (별도 웹페이지 필요)
• 이용약관 URL
• 앱 심사용 테스트 계정 (ID/PW)
• 각 권한 사용 이유 문구 (NSCameraUsageDescription 등)
• 기기별 스크린샷: iPhone 6.9인치, 6.5인치, iPad — 각각 따로
• 앱 프리뷰 영상 (선택이지만 없으면 노출 불이익)
실제 시간 분배 — 예상과 현실
한 가지 놀라운 점은, 버그 수정과 삽질이 전체 기간의 22%를 차지했다는 것이다. 처음 계획에서 이 항목은 "개발 기간 안에 포함"으로 0% 취급했다. 그리고 디자인 폴리싱도 별도 항목으로 잡지 않았다. 이 두 개가 내 일정 예측을 완전히 무너뜨렸다.
Phase 6. 출시 당일 — 기대보다 조용했다
출시일
현재
결국 배운 것들 — 다음 프로젝트에 적용할 것
① 기능 목록에서 60%를 지운 뒤 시작하기 — MVP는 생각보다 훨씬 작아야 한다
② 디자인 공수를 개발 공수의 30%로 별도 산정하기
③ "삽질 버퍼"를 전체 기간의 25%로 예산에 포함시키기
④ 스토어 등록 준비물 체크리스트 미리 만들어두기
⑤ 베타 테스트를 개발 완료 전(기능 70% 시점)에 시작하기
그리고 한 가지 더. 출시 후 조용한 게 실패가 아니라는 것. 38건 다운로드 중 실제로 매일 쓰는 사람이 11명 있다는 통계를 보고 처음엔 실망했다가, 11명이 매일 내가 만든 걸 쓴다는 게 오히려 신기하고 뿌듯해졌다. 이 감각이 없었으면 다음 프로젝트도 없었을 것이다.
출시하는 순간보다, 누군가가 처음으로 "이거 좋네요"라는 리뷰를 남겼을 때가 훨씬 더 기뻤다.
— 출시 2주 후, 앱스토어 리뷰 알림을 받던 새벽 1시7개월이 걸렸고, 예상은 전부 빗나갔다. 그래도 후회는 없다. 다만 솔직하게 말하면 — 혼자서 앱 하나를 처음 출시하는 건 "3개월이면 되겠지"라고 생각할 때의 두 배 이상 걸린다. 이 글을 읽는 분이 지금 사이드 프로젝트를 준비 중이라면, 일정표의 오른쪽 끝을 조금만 더 늘려두시길 권한다.
🚀 여러분의 출시 타임라인은 어땠나요?
사이드 프로젝트를 완성해서 출시한 경험이 있으신가요? 예상 기간과 실제 기간이 얼마나 차이 났는지, 어느 단계에서 제일 막혔는지 댓글로 이야기해 주세요. 반대로 아직 기획 단계에서 시작도 못 하고 있다면 — 그것도 댓글로 남겨주시면 같이 이야기해 봐요. 저도 시작은 그랬으니까요. 💬
'개발자 > 사이드프로젝트 창업' 카테고리의 다른 글
| 사이드 프로젝트 세 번 실패하고 얻은 진짜 교훈들 (0) | 2026.06.13 |
|---|