사이드 프로젝트를 실서비스로: 0원으로 시작해서 월 100만 사용자 받기까지

발단: 퇴근 후 만든 개발자 도구

2024년 9월, 회사에서 반복적으로 JSON 데이터를 변환하는 작업이 짜증 나서 만든 웹 도구가 있었다. JSON을 TypeScript 타입으로, CSV로, YAML로 변환해주는 단순한 유틸리티 사이트였다. 주말 이틀 만에 뚝딱 만들어서 Vercel 무료 플랜에 올렸다.

"나만 쓰려고" 만든 건데, 사내 슬랙에 공유했더니 동료들이 좋아했고, 그중 한 명이 개발자 커뮤니티에 올렸다. 그로부터 2주 뒤, 하루 방문자가 5,000명을 넘기기 시작했다.

처음엔 당황했다. "이게 왜 이렇게 많이 오지?" 싶었는데, 알고 보니 기존에 비슷한 도구들이 다 광고 떡칠이거나 UI가 구려서, 깔끔하게 만든 내 사이트로 사람들이 몰린 거였다. 그렇게 의도치 않게 사이드 프로젝트가 시작됐다.

초기 기술 스택: 0원의 마법

사이드 프로젝트의 최대 장점은 돈이 안 든다는 거다. 적어도 처음에는. 내가 처음에 사용한 무료 스택은 이랬다:

총 비용: 정확히 0원. 도메인도 처음엔 Vercel에서 제공하는 .vercel.app 서브도메인을 쓰다가, 사용자가 1만 명 넘어가면서 .dev 도메인을 연 12달러에 구입했다. 그게 첫 지출이었다.

인프라 아키텍처 변천사

MVP에서 제품으로: 기능 추가 과정

처음엔 JSON-to-TypeScript 변환 하나뿐이었는데, 사용자 피드백을 받으면서 기능이 늘어났다:

• 2024년 10월: JSON ↔ YAML, JSON ↔ CSV 변환 추가 (사용자 요청 1위)
• 2024년 11월: JSON 포맷터/미니파이어, Base64 인코더 추가
• 2024년 12월: 사용자 계정 도입 (Supabase Auth), 변환 이력 저장
• 2025년 1월: API 제공 시작 (개발자들이 자동화에 쓰고 싶다고 요청)
• 2025년 3월: 정규식 테스터, UUID 생성기, 해시 계산기 등 유틸리티 모음으로 확장
• 2025년 6월: CLI 도구 배포 (npm 패키지)

기능을 추가할 때마다 지켰던 원칙이 하나 있다: "3일 안에 못 만들면 안 만든다." 사이드 프로젝트는 퇴근 후와 주말에 하는 거라, 스코프를 극도로 작게 잡아야 지속할 수 있다. 한 번은 "VS Code 확장까지 만들까?" 생각했다가, 일주일은 걸릴 것 같아서 포기했다. 대신 CLI 도구를 3일 만에 만들어서 npm에 올렸고, 이게 오히려 더 인기가 좋았다.

사용자 0명에서 100만까지

마케팅에 돈을 한 푼도 안 썼다. 진짜다. 모든 사용자 유입은 유기적이었다:

성장의 핵심 전환점들:

1. 2024년 10월: 한국 개발자 커뮤니티(okky, GeekNews)에서 입소문. DAU 1,000 돌파.
2. 2025년 1월: API 출시 후 개발 블로그들에서 소개. 해외 사용자 유입 시작.
3. 2025년 9월: 영어 UI 추가 후 Hacker News 프론트페이지에 올라감. 하루 만에 DAU 80,000 폭발. 이때 서버가 터졌다.
4. 2025년 12월: Product Hunt 런칭. 데일리 3위 달성. 해외 사용자 비중이 60%로 역전.

새벽 3시의 비명: 첫 번째 대규모 장애

2025년 9월 15일, Hacker News에 올라간 날이었다. 퇴근하고 넷플릭스 보다가 슬랙 알림이 미친 듯이 울렸다. Uptime 모니터링 봇이 "사이트 다운"을 외치고 있었다.

Vercel 대시보드를 열어보니 Edge Function 호출이 분당 50,000건을 넘기고 있었다. 무료 플랜 한도를 훌쩍 넘겼고, Supabase도 동시 연결 수 한도(기본 60개)에 걸려서 connection pool exhausted 에러를 뱉고 있었다.

그날 밤에 한 일:

1. Vercel을 Pro 플랜으로 긴급 업그레이드 (월 $20)
2. Supabase에 connection pooler(PgBouncer) 활성화
3. 무거운 변환 로직을 Cloudflare Workers로 이전 (Edge에서 실행)
4. 정적 결과를 Cloudflare R2에 캐싱하는 로직 추가
5. 레이트 리밋을 IP당 분당 30회에서 60회로 올림 (정상 사용자가 차단당하고 있어서)

새벽 3시에 시작해서 6시에 끝났다. 다음 날 회사에서 졸면서 일했지만, 기분은 이상하게 좋았다. 내가 만든 서비스를 전 세계 사람들이 쓰고 있다는 사실이 짜릿했으니까.

DB 병목: Supabase와의 사투

사용자가 30만을 넘기면서 DB가 병목이 되기 시작했다. 특히 "변환 이력 저장" 기능 때문에 쓰기가 많아졌는데, Supabase 무료 티어의 성능 한계가 보이기 시작했다.

시도한 해결책들:

• 쿼리 최적화: 가장 느린 쿼리 Top 10을 EXPLAIN ANALYZE로 분석. 인덱스 3개 추가로 평균 쿼리 시간 340ms → 45ms로 개선.
• 읽기 전용 리플리카: Supabase Pro에서 제공하는 Read Replica 활성화. 읽기 트래픽의 80%를 리플리카로 분산.
• 캐싱 레이어: 자주 조회되는 데이터(인기 변환 템플릿)를 Upstash Redis에 캐싱. 캐시 히트율 92% 달성.
• 이력 데이터 보관 정책: 90일 이상 된 변환 이력은 R2에 아카이빙하고 DB에서 삭제. DB 사이즈 8GB → 2.3GB로 줄임.

비용 구조: 현실적인 이야기

수익화: 무료 서비스로 돈 벌기

처음 6개월은 수익이 0원이었다. 그냥 재미로 운영했다. 하지만 비용이 나가기 시작하면서 수익화를 고민했다.

시도한 수익화 방법과 결과:

광고는 넣자마자 사용자 불만이 폭주해서 2주 만에 뺐다. 개발자 도구에 광고는 독이다. 대신 API rate limit을 무료 30회/분, Pro 1,000회/분으로 나누는 프리미엄 모델이 잘 먹혔다. 의외로 기업 고객이 기꺼이 돈을 내준다. "직원들이 매일 쓰는 도구인데 월 $50이면 싸다"라는 반응이었다.

CDN 최적화: 성능의 80%는 캐싱

사이트가 빠른 이유의 80%는 Cloudflare 덕분이다. 내가 적용한 최적화들:

• 정적 자산 R2 호스팅: JS, CSS, 이미지를 모두 R2에 올리고 Cloudflare CDN으로 서빙. Vercel에서 직접 서빙하던 것보다 TTFB가 60% 개선됐다.
• Edge Caching: 변환 결과 중 자주 사용되는 패턴(예: 빈 JSON → TypeScript)은 Edge에 캐싱. 캐시 히트율 85%.
• Brotli 압축: Cloudflare에서 Brotli를 활성화하면 gzip 대비 번들 크기가 추가로 15~20% 줄어든다.
• 이미지 최적화: 사실 개발자 도구라 이미지가 거의 없지만, 로고와 OG 이미지는 WebP로 변환하고 srcset으로 반응형 처리했다.

결과적으로 Lighthouse 성능 점수 98점, 전 세계 어디서든 FCP(First Contentful Paint) 0.8초 이내를 달성했다.

혼자서 운영하는 노하우

100만 사용자 서비스를 혼자 운영한다니 미쳤다고 생각할 수 있는데, 핵심은 "자동화"와 "단순함"이다:

• 모니터링: BetterStack으로 업타임 모니터링, Sentry로 에러 추적, Posthog로 사용자 행동 분석. 문제가 생기면 슬랙으로 알림이 온다.
• 배포: main 브랜치에 push하면 Vercel이 자동 배포. Preview 배포로 PR마다 테스트 가능.
• 고객 지원: GitHub Issues로 관리. FAQ 페이지를 잘 만들어두면 반복 질문의 80%가 줄어든다.
• 보안: Cloudflare WAF + 레이트 리밋 + Supabase RLS. 한 달에 한 번 의존성 업데이트(Dependabot).

일주일에 이 서비스에 쓰는 시간은 평균 5시간 정도다. 대부분 새 기능 개발이고, 운영 자체는 거의 손이 안 간다.

얻은 교훈 7가지

1. 완벽하지 않아도 출시하라. 첫 버전은 정말 조잡했다. 하지만 출시 안 했으면 아무 일도 안 일어났다.
2. 사용자 피드백은 금이다. 내가 "이거 좋겠지" 하고 만든 기능보다, 사용자가 직접 요청한 기능이 10배 더 인기 있었다.
3. 무료 티어를 최대한 활용하라. 2024년 현재 무료 인프라만으로 놀라울 정도로 많은 걸 할 수 있다. 돈부터 쓰지 마라.
4. 글로벌을 처음부터 고려하라. 영어 UI를 나중에 추가했더니 코드 전체를 i18n 리팩토링해야 했다. 처음부터 했으면 훨씬 쉬웠을 것.
5. 광고보다 프리미엄이 낫다. 개발자 대상 서비스에서 광고는 신뢰를 깎아먹는다. 가치에 대한 대가를 받는 게 더 건강한 비즈니스 모델이다.
6. 인프라는 단순하게. AWS나 GCP를 직접 관리할 수도 있었지만, 관리형 서비스를 쓴 덕에 혼자서도 운영할 수 있다.
7. 재미를 잃지 마라. 사이드 프로젝트의 핵심 동력은 재미다. 돈이 되기 시작하면 의무감이 생기는데, 그러면 번아웃이 온다. 나는 "이번 주에 하기 싫으면 안 해도 된다"는 규칙을 아직도 지키고 있다.

앞으로의 계획

현재 고민하고 있는 것들:

• 팀을 꾸릴까? 아직은 혼자가 좋다. 하지만 기업 고객이 늘면 지원 인력이 필요할 수도.
• 오픈소스화: 핵심 변환 엔진을 오픈소스로 공개하는 것을 고려 중. 커뮤니티 기여를 받으면 혼자서 못 만드는 것도 가능해진다.
• VS Code / IntelliJ 확장: 사용자 요청 1위. 올해 안에 만들 예정.
• 오프라인 모드: PWA로 변환 기능을 오프라인에서도 쓸 수 있게. 보안에 민감한 기업 고객들의 요청.

퇴근 후 주말에 만든 작은 도구가 여기까지 올 줄은 정말 몰랐다. 혹시 사이드 프로젝트를 고민하고 있다면, 일단 만들어서 세상에 내놓아 보라. 반응은 항상 예상 밖이다.

Jaeseong

10년차 풀스택 개발자. Spring Boot, Flutter, AI 등 실무 경험을 기록합니다.

GitHub →