처음엔 다 그렇게 시작하잖아요
“이번엔 진짜 될 거야” 하면서 시작한 사이드 프로젝트가 벌써 세 번째失败했어요. 아니, 실패라고 단정 짓긴 뭐하지만, 적어도 제가 기대했던 만큼의 성과는 내지 못했죠.
솔직히 말하면 저만 그런 건 아니잖아요? 퇴근하고 나서 몰입해서 만들고, 주말에 시간 쏟고, 근데 막상 출시하면 아무도 안 쓰는 그런 경험. 한 번쯤은 있으실 거예요.
그래서 오늘은 제가 지난 2년 동안 시도했다가 엎어진 사이드 프로젝트 세 개를 돌아보면서, 진짜 중요한 게 뭔지 정리해보려고 해요. 혹시 지금 뭔가 준비 중이신 분들에게도 도움이 되면 좋겠어요.
첫 번째 실패: 뉴스레터 자동 발송 툴
2024년 초였어요. 제가 블로그 운영하면서 느낀 게, “매주 뉴스레터 보내는 게 너무 귀찮다”였거든요. 그래서 n8n으로 자동화 툴을 만들었어요. 블로그 새 글 감지하면 메일chimp로 자동 발송되는 거요.
기술적으로는 완벽했어요. 실제로 지금도 이 시스템은 잘 돌아가고 있고요. 근데 문제는… 이걸 “남들도 쓸 수 있게” 만들려고 하다가 꼬였어요.
출처: Unsplash
제가 쓰는 용도로만 만들었으면 됐을 걸, 굳이 SaaS 형태로 만들겠다고 사용자 관리, 결제 시스템, 대시보드까지 다 붙였어요. 그러다 보니 개발 기간만 4개월이 걸렸고, 막상 출시했을 땐 이미 비슷한 서비스가 3개나 나와 있더라고요.
교훈이 뭐였냐면, “내 문제를 해결하는 것부터 시작하자”였어요. 남들을 위한 제품을 만들겠다고 욕심 부리다가, 정작 내가 쓰는 버전조차 완성 못 하는 상황이 오더라고요.
두 번째 실패: 인스타그램 콘텐츠 스케줄러
이건 2024년 여름이었나? 마케터로 일하면서 느낀 또 다른痛点, “인스타그램 릴스 예약 올리기 너무 불편하다”에서 시작했어요.
당시엔 메타 비즈니스 스위트가 있긴 했는데, 기능이 너무 제한적이었거든요. 그래서 “이것보다 더 나은 걸 만들 수 있을 것 같아”라고 생각했죠.
근데 제가 간과한 게 있었어요. “이 시장에 진입 장벽이 왜 이렇게 높은지”를 깊게 고민 안 했던 거예요. API 제약, 계정 정지 위험, 플랫폼 정책 변경… 이런 리스크들이 산너머 산이더라고요.
결국 프로토타입까지는 만들었는데, 막상 베타 테스터 모집하려고 하니까 “내 계정 정보 믿고 맡길 수 있어요?”라는 질문이 계속 들어왔어요. 당연한 거죠. 신뢰 쌓는 게 하루아침에 되는 게 아니니까.
여기서 배운 건 “시장 조사는 아무리 해도 부족하다”는 거예요. 특히 다른 사람 계정이나 데이터 다루는 서비스라면, 기술적 구현보다 신뢰 문제가 훨씬 큰 장벽일 수 있어요.
세 번째 실패: AI 글쓰기 도구
2025년 초, AI 도구 관련 글 쓰면서 “나도 AI 글쓰기 도구 만들 수 있겠는데?”란 생각이 들었어요. ChatGPT API 연결해서 블로그 글 초안 생성해주는 툴이요.
이건 기술적으로도 쉬웠고, MVP 만드는 데 한 달도 안 걸렸어요. 사용자도 꽤 모였고, 피드백도 나쁘지 않았죠. 근데 문제는 수익화였어요.
API 비용이 생각보다 많이 나가더라고요. 무료 사용자들이 너무 많이 써서, 월 50만 원 넘게 API 비용만 나가는데 유료 전환율은 2%도 안 되는 상황. 이러다간 제 돈만 나가다 끝나겠다 싶었죠.
결국 서비스 종료했어요. 아, 물론 사용자분들께는 미리 공지드리고, 데이터도 안전하게 삭제했어요. 갑자기 휑하니 사라지는 서비스는 진짜 별로잖아요.
이때 배운 건 “비용 구조부터 계산하자”는 거였어요. API 기반 서비스는 사용자가 늘어날수록 비용도 같이 늘어나니까, 단가 책정할 때 이걸 꼭 고려해야 해요.
실패에서 배운 것들, 정리하면
세 번의 시도를 통해 깨달은 건 몇 가지 있어요.
첫째, 내 문제부터 해결하자. 남들이 뭘 원하는지보다, 내가 진짜 불편한 게 뭔지 먼저 파악하는 게 중요해요. 내 문제면 적어도 한 명의 사용자는 확정이니까요. n8n으로 자동화할 때도 그렇고, 실제로 내가 쓰는 용도로만 시작하는 게 훨씬 안전해요.
둘째, 단순하게 시작하자. 첫 번째 프로젝트처럼 SaaS로 만들겠다고 욕심 부리지 말고, 스크립트 하나, 웹페이지 하나로 시작하는 게 좋아요. 기능 붙이는 건 나중에도 할 수 있어요.
셋째, 비용과 수익을 처음부터 계산하자. 특히 API 비용, 서버 비용 같은 거요. “사용자 늘어나면 수익도 늘겠지”라는 낙관적 전제는 위험해요.
넷째, 실패를 기록하자. 이 글을 쓰면서도 그런데, 실패 과정 정리해두면 나중에 또 다른 사이드 프로젝트 할 때 분명 도움이 돼요. 제 블로그에도 이런 실패담 종종 올리는데, 생각보다 많은 분들이 공감해주시더라고요.
수익보다 중요한 게 있다고요
제목에서도 말했지만, 사이드 프로젝트 하면서 얻은 가장 큰 건 수익이 아니었어요. 물론 돈 버는 거 좋죠. 근데 실패한 프로젝트에서도 배운 건 있었어요.
새로운 기술 스택 익히고, 사용자 피드백 받아보고, 출시 과정 경험하고. 이런 것들이 나중에 진짜 될 수 있는 프로젝트 만날 때 큰 자산이 되더라고요.
그래서 지금도 사이드 프로젝트는 계속하고 있어요. 지금은 조금 더 작게, “내가 진짜 쓸 것” 위주로요. 언젠가는 될 때도 오겠죠? 안 되더라도 배운 건 남으니까요.
여러분도 혹시 진행 중인 사이드 프로젝트 있으시면, 너무 큰 기대보다는 “이걸 통해 뭘 배울 수 있을까” 관점으로 접근해보세요. 그게 마음 편하더라고요.
마무리하며
사이드 프로젝트, 물론 성공하면 좋죠. 부수입도 되고, 이력서에도 한 줄 추가되고. 근데 실패해도 괜찮아요. 중요한 건 계속 시도하는 거니까요.
저도 아직 배우는 중이에요. 이 글 읽으시는 분들 중에 성공 사례 있으시면 댓글로 공유해주세요. 저도 배우고 싶어요. 서로의 경험 공유하면 더 빨리 성장할 수 있잖아요.
다음엔 제가 지금 준비 중인 네 번째 사이드 프로젝트도 소개할게요. 이번엔 진짜 작게 시작하고 있어요. 될지는 모르겠지만, 일단 해보는 거죠 뭐.