1인 개발자로 사이드 프로젝트
런칭하며 배운 것
혼자 만들고 혼자 배포하고 혼자 마케팅했던 6개월의 기록
왜 1인 프로젝트를 시작했나
팀 사이드 프로젝트를 두 번 했다. 두 번 다 완성 못 했다. 팀원이 바빠지고, 방향이 달라지고, 연락이 뜸해지는 패턴이 똑같이 반복됐다. 세 번째엔 혼자 하기로 했다. 이유는 단순했다. 완성하지 못하는 이유가 팀이었다면, 팀 없이 시작하면 그 이유가 사라진다.
재직 중이었다. 퇴근 후와 주말만 썼다. 처음엔 "언제 만들어" 싶었는데, 혼자 하니까 결정 하나하나가 빨랐다. 팀원에게 설명하고 동의를 구하는 과정이 없었다. 생각보다 빨리 만들어졌다. 그 과정에서 팀 프로젝트와는 완전히 다른 종류의 것들을 배웠다.
만든 것 — 개발자 영문 이력서 피드백 서비스
해외 취업을 준비하면서 직접 겪은 문제를 서비스로 만들었다. 영문 이력서를 어떻게 써야 하는지, 내 이력서가 ATS를 통과할 수 있는지, 어떤 부분이 약한지를 AI가 분석해주는 서비스였다. 스택은 Next.js 14 App Router, Supabase, Vercel, Claude API.
기획부터 배포까지 완전히 혼자. 디자인도 혼자. 마케팅도 혼자. 고객 대응도 혼자. 그 "혼자"가 이 프로젝트에서 배운 것의 대부분이다.
6개월 타임라인 — 실제로 어떻게 진행됐나
가장 중요한 결정이었다. 개발 시작 전에 먼저 수요를 확인했다. 커뮤니티에 "영문 이력서 피드백 받고 싶은 분 있으세요?"를 올렸다. 48시간 안에 67명이 DM을 보냈다. 그 중 8명은 "돈 내고 쓰겠다"고 했다. 그때 만들기로 확신했다. 코드보다 먼저 수요가 있어야 한다는 걸 이전 두 번의 팀 프로젝트가 가르쳐줬다.
원래 계획했던 기능의 70%를 잘랐다. "이력서 버전 관리", "면접 대비 예상 질문 생성", "커리어 트래커" — 전부 나중으로. MVP에는 딱 하나만 넣었다. 이력서 업로드하면 AI 피드백 받기. 그 하나를 잘 만드는 데 집중했다. 기능을 줄이는 게 개발보다 어려웠다. 넣고 싶은 것들을 참는 게 힘들었다.
검증 단계에서 DM 보낸 8명에게 먼저 연락했다. 무료로 써보고 피드백을 달라고 했다. 그 중 5명이 실제로 써줬다. "이 부분 설명이 더 있으면 좋겠어요", "PDF 업로드가 안 돼요", "영어 피드백인데 한국어로도 받고 싶어요". 그 피드백들이 1.0 버전을 완성했다. 10명의 베타 유저가 100개의 설문보다 값졌다.
Product Hunt에 올렸다. 당일 오전 12시 01분에. 런칭 전날 커뮤니티에 "내일 Product Hunt에 올릴 예정이에요"를 알렸다. 첫 날 업보트 180개. 당일 카테고리 3위. 340명 가입. 처음 알림이 쏟아졌을 때 손이 떨렸다. 혼자 만들었는데 340명이 쓰고 있다는 게 실감이 안 났다.
서버 에러, 결제 문제, 사용자 이메일, 환불 요청. 만드는 단계에서 없던 일들이 생겼다. 개발보다 운영이 더 많은 날도 있었다. 그래도 매달 구독자가 늘었다. 4개월 차에 월 100만 원을 넘었다. 생활비에 보태는 수준이 됐다. 퇴사하지 않고 재직하면서 만든 것치고는 만족스러웠다.
가장 많이 배운 것들
가장 중요한 교훈. 코드 한 줄도 쓰기 전에 "이게 없어서 불편한 사람이 있는가"를 확인해야 한다. 있으면 만들고, 없으면 만들지 않는다. 검증 없이 시작하면 아무도 안 쓰는 걸 만든다.
모든 기능을 넣고 싶은 충동이 있다. 그 충동을 이기는 게 1인 프로젝트에서 가장 어렵다. 핵심 하나를 잘 만드는 게 열 개를 대충 만드는 것보다 낫다.
좋은 것을 만들어도 알려지지 않으면 아무 의미가 없다. Product Hunt, 커뮤니티 글쓰기, SNS — 이게 없었으면 300명 가입도 없었다. 개발 시간의 30%는 마케팅에 써야 한다.
팀이 없으면 필터가 없다. 사용자 피드백이 바로 나한테 온다. 불편하지만 이게 제일 빠른 개선이다. 이메일 하나하나 답하면서 서비스가 나아진다.
런칭이 끝이 아니다. 서버 장애, 환불 요청, 기능 요청, 버그 리포트. 만드는 것보다 유지하는 게 더 많은 날도 있다. 운영 계획을 미리 세워야 한다.
가장 당황했던 순간들
340명이 몰린 그날 오후에 Supabase rate limit에 걸렸다. 30분 동안 서비스가 안 됐다. 가장 사람이 많이 오는 날에. 연결 풀링 설정을 미리 하지 않은 것이 원인이었다. 그날 이후 트래픽 시뮬레이션 테스트를 런칭 전에 반드시 한다.
첫 달 API 비용이 예상보다 훨씬 많이 나왔다. 이력서 하나당 비용 계산을 잘못했다. 프롬프트가 길고 응답도 길어서 토큰이 많이 소모됐다. 가격 모델을 다시 계산하고 구독료를 올렸다. 수익화 전에 서버·API 비용을 정확히 계산해야 한다는 걸 비싸게 배웠다.
"서비스가 기대와 달라서 환불 요청합니다"라는 이메일이 왔다. 처음엔 어떻게 답해야 할지, 법적으로 환불 의무가 있는지도 몰랐다. 결국 전액 환불했다. 이후에 환불 정책, 개인정보처리방침, 이용약관을 제대로 정비했다. 서비스 시작 전에 이 문서들을 먼저 준비했어야 했다.
Product Hunt 효과로 첫 주에 340명이 왔다. 두 번째 주는 40명이었다. 세 번째 주는 12명. 이 낙폭을 예상하지 못했다. 런칭 이후의 지속 유입 채널을 만들지 않았던 것이 문제였다. 블로그 SEO, 커뮤니티 활동, 소셜 콘텐츠 — 이것들이 있어야 꾸준한 유입이 된다는 걸 런칭 후에 알았다.
기술 스택 선택 — 왜 이걸 골랐나
팀 프로젝트와 다르게 1인 프로젝트에서 기술 선택 기준은 하나다. 내가 가장 빠르게 만들 수 있는 것. 새로운 기술을 배우면서 만들면 시간이 두 배 걸린다. 시간이 두 배 걸리면 완성 확률이 절반이 된다.
그래서 Next.js 14 (이미 실무에서 쓰던 것), Supabase (Auth + DB + Storage를 한 번에), Vercel (배포 자동화), Claude API (AI 기능). 모두 이미 알거나 쉽게 쓸 수 있는 것들이었다. 이 선택 덕분에 실제 개발 시간이 2개월로 줄었다. 새 기술 공부하느라 6개월 썼다면 런칭을 못 했을 것이다.
const soloDevStack = {
// 프레임워크: 이미 아는 것 써라 framework: 'Next.js 14 App Router',
// 백엔드: 설정 없이 바로 쓸 수 있는 BaaS backend: 'Supabase', // Auth + DB + Storage + Edge Functions
// 배포: 커밋하면 자동 배포 hosting: 'Vercel', // 무료 플랜으로 시작 가능
// 결제: 국내는 토스페이먼츠, 해외는 Stripe payment: '토스페이먼츠',
// UI: 빠른 프로토타이핑 ui: 'Tailwind CSS + shadcn/ui',
// AI: 기능의 핵심이 AI라면 ai: 'Claude API / OpenAI API',
// 이메일: 트랜잭션 이메일 email: 'Resend', // 무료 100개/월
// 분석: 무료 + GDPR 친화 analytics: 'Umami', // self-hosted or cloud
}
// 핵심 원칙: 내가 모르는 스택 = 런칭 실패 위험 // 완성이 퀄리티보다 우선이다
Product Hunt 런칭 — 실제로 어떻게 했나
# 런칭 D-7
[완료] Product Hunt 계정 생성 (최소 7일 전에)
[완료] 커뮤니티에 런칭 예고 게시물 올리기
[완료] 베타 유저들에게 런칭일 사전 공유
[완료] 트위터/링크드인에 런칭 예고
─────────────────────────────────────────
# 런칭 당일 (자정 12:01 AM PST 기준)
[완료] 제품 등록 — 스크린샷 5장, 데모 GIF 1개
[완료] 매시간 댓글 모니터링 + 답글
[완료] 커뮤니티에 "오늘 런칭했습니다" 글 올리기
[아쉬움] Maker 코멘트를 더 길고 진솔하게 썼으면
[실패] 서버 트래픽 대비 미흡 → 30분 다운
─────────────────────────────────────────
결과: 업보트 180개 / 카테고리 3위 / 340명 가입
# 핵심: Maker 댓글에서 "왜 만들었는지"를 솔직하게 써라
# Product Hunt은 제품보다 스토리에 반응한다
Product Hunt은 완성도보다 스토리에 반응한다. "왜 이걸 만들었는가", "어떤 문제를 직접 겪었는가"를 진솔하게 쓰는 Maker 코멘트가 업보트를 만든다. 그리고 자정에 올려야 하루 전체 카운팅 기회를 갖는다. PST 기준 자정이 우리 시간으로 오후 4~5시다.
1인 프로젝트이기에 가능했던 것들
베타 테스트에서 피드백이 왔다. "한국어 피드백도 있으면 좋겠어요." 그날 저녁에 구현했다. 다음 날 배포했다. 팀이었다면 회의하고, 기획하고, 우선순위 조율하는 데 일주일이 걸렸을 것이다. 1인이니까 피드백을 받은 날 바로 움직일 수 있었다.
어느 날 사용자가 "이력서 말고 LinkedIn 프로필 분석도 해주세요"를 요청했다. 그날 바로 실험해봤다. 아이디어가 나쁘지 않아서 2주 만에 추가했다. 이게 실제로 유료 전환율을 높이는 기능이 됐다. 팀이었다면 이 기능이 MVP에 없었기 때문에 "나중에"가 됐을 것이다.
팀 프로젝트에서 "나중에 하자"고 넘겼던 것들이 1인 프로젝트에서는 그날 결정됐다. 빠른 결정이 빠른 완성을 만들었다. 완성이 모든 것의 시작이었다.
1인 프로젝트를 고민하는 분들에게
완성하지 못한 프로젝트는 없는 것과 같다. 완벽하게 만들려다 완성 못 하는 것보다 부족하게 만들어도 런칭하는 게 낫다. 런칭하면 피드백이 오고, 피드백이 개선을 만들고, 개선이 완성도를 올린다. 이 사이클이 시작되려면 일단 세상에 나와야 한다.
내가 직접 겪은 문제를 풀어라. 내가 아는 문제는 설명할 수 있고, 설명할 수 있는 것은 마케팅이 된다. "저도 이 문제로 고생했어요"라는 한 마디가 Product Hunt 코멘트에서 공감을 만들었다. 남의 문제를 풀려다가 수요 파악이 안 되는 경우가 많다.
개발 시작 전에 10명의 예비 사용자를 찾아라. "이런 거 만들려고 하는데 쓸 것 같으세요?"라고 커뮤니티에 먼저 물어보는 게 3개월의 개발 시간을 낭비하지 않는 방법이다. 10명이 "쓸 것 같다"고 하면 만들어도 된다. 아무도 반응 안 하면 다른 아이디어를 찾는다.
아이디어가 있다면 코드부터 쓰지 않는다. 커뮤니티나 SNS에 그 아이디어를 올린다. "이런 서비스 있으면 쓸 것 같으세요?"를 묻는다. 10명 이상이 긍정 반응을 하면 그때 개발을 시작한다. 이 한 단계가 몇 달의 낭비를 막는다.
6개월이 지나고 지금도 서비스를 운영하고 있다. 매달 구독자가 조금씩 늘고, 매달 한두 개의 기능을 개선한다. 완벽하지 않다. 버그도 있고, 아쉬운 UI도 있고, 더 잘 만들고 싶은 것들이 있다.
그래도 이 프로젝트가 가르쳐준 것이 있다. 회사에서 배운 것과 완전히 다른 종류의 것들이었다. 수요 검증, 런칭, 운영, 마케팅, 고객 대응, 비용 관리. 이걸 혼자 경험한 것이 개발자로서 가장 값진 성장이었다. 더 좋은 것을 만들 수 있는 사람이 됐다기보다, 만들어서 세상에 내놓는 것을 두려워하지 않는 사람이 됐다.
💬 사이드 프로젝트 런칭 경험이 있으신가요?
런칭하면서 배운 것, 당황했던 순간, 지금 진행 중인 프로젝트 — 어떤 이야기든 댓글로 나눠주세요. 지금 사이드 프로젝트를 고민 중인 분들에게 가장 현실적인 참고가 될 것 같습니다.
'개발자 > 실무 개발 현장' 카테고리의 다른 글
| 기술 부채를 처음 실감한 순간 (0) | 2026.08.10 |
|---|---|
| 개발자의 하루 루틴, 실제로 어떻게 생겼나 (0) | 2026.08.03 |
| 야근이 일상인 스타트업에서 버틴 방법 (0) | 2026.07.27 |
| 내가 짠 코드가 운영 중 터졌을 때의 경험담 (0) | 2026.07.20 |
| 개발자가 PM·기획자와 갈등했던 실제 사례 (0) | 2026.07.13 |
