개발자들 사이에서 사이드 프로젝트는 흔하다. 근데 거기서 실제로 돈이 나오는 경우는 드물다. GitHub에 올려두고 스타 받으면 뿌듯한 정도이거나, 포트폴리오에 한 줄 추가하는 정도로 끝난다. 나도 그랬다.

근데 최근에 주변에서 사이드 프로젝트로 월 몇십만 원, 어떤 사람은 몇백만 원의 수익을 내는 걸 직접 목격하면서 생각이 바뀌었다. 불가능한 일이 아니구나. 다만 프로젝트를 대하는 접근법이 좀 다르구나. 그 차이에 대해 정리해본다.

아이디어는 어디서 오는가#

"좋은 아이디어가 없어서 못 시작한다"는 말을 자주 듣는다. 나도 그랬고. 근데 주변에서 수익을 내는 사이드 프로젝트를 관찰해보면, 대단한 아이디어에서 시작한 경우가 거의 없다.

한 지인이 만든 서비스는 "개발자 이력서 빌더"다. 세상에 이력서 빌더가 얼마나 많은데. Canva에도 있고, Resume.io 같은 전문 서비스도 있고, 심지어 Notion 템플릿도 있다. 근데 이 지인이 발견한 건, 한국 개발자들이 원하는 이력서 포맷이 해외 서비스와 다르다는 거였다. 한국 회사에 지원할 때 필요한 양식, 경력기술서의 구조, 프로젝트 상세 작성 방식이 다르다. 그 간극을 채운 거다.

아이디어의 출발점은 대부분 "내가 직접 불편을 겪은 것"이다. Y Combinator에서 반복적으로 하는 말이 "Make something people want"인데, 이 중에서 가장 확실한 건 내가 원하는 걸 만드는 거다. 내가 겪은 문제는 비슷한 처지의 다른 사람들도 겪고 있을 확률이 높다.

중요한 건 이 불편이 "있으면 좋겠다" 수준이 아니라 "없으면 진짜 귀찮다" 수준이어야 한다는 거다. 사람들은 "있으면 좋겠다"에는 돈을 안 낸다. "이게 없으면 매일 30분씩 삽질하는데"에 돈을 낸다.

그래서 아이디어를 찾을 때 물어볼 질문은 "뭘 만들면 재밌을까?"가 아니라 "뭘 할 때마다 짜증나지?"다. 반복적으로 수작업하는 것, 기존 도구가 있는데 미묘하게 안 맞는 것, 엑셀이나 Notion으로 억지로 관리하는 것. 이런 것들이 사이드 프로젝트의 씨앗이 된다.

만들기 전에 확인하는 법#

아이디어가 떠오르면 바로 코드를 짜고 싶어진다. 이 충동을 참아야 한다. 적어도 며칠은.

확인하는 방법은 생각보다 저비용이다. 내가 본 방법들을 적어보면.

가장 간단한 건, 해당 문제를 겪고 있을 것 같은 사람 5명에게 DM을 보내는 거다. "혹시 이런 불편함 있어요?" 5명 중 3명 이상이 "아 맞아 그거 진짜 불편해"라고 하면 일단 수요는 있는 거다. 5명 중 1명 이하가 공감하면 문제 설정을 다시 해야 한다.

좀 더 체계적으로 하려면 랜딩 페이지를 하나 만든다. 제품이 뭔지 설명하고, "출시되면 알려드릴게요" 이메일 수집 폼을 넣는다. 이 페이지를 관련 커뮤니티에 공유하고, 이메일이 얼마나 모이는지 본다. 2주 안에 이메일이 100개 이상 모이면 상당히 긍정적인 신호다. 10개도 안 모이면 관심이 없거나, 설명이 공감을 못 주고 있는 거다.

더 과감한 방법도 있다. 아직 제품이 없는데 가격 페이지를 만들고 결제 버튼을 넣는다. 물론 실제로 결제를 받는 건 아니고, 버튼을 누르면 "아직 준비 중입니다, 출시되면 알려드릴게요"가 뜬다. 근데 버튼을 누른 사람의 숫자는 실제 수요의 매우 강한 신호다. 이메일 등록보다 결제 버튼 클릭이 훨씬 높은 의향을 보여주니까.

이게 속이는 것 같아서 불편하다고 느낄 수 있다. 근데 사용자 입장에서는 "관심 표현"을 한 것이고, 우리 입장에서는 6개월 개발 후 "아무도 안 사네"를 경험하는 것보다 훨씬 정직한 접근이다.

무료에서 유료로의 심리적 장벽#

개발자들이 사이드 프로젝트에 가격을 매기지 못하는 이유가 있다. 몇 가지 심리가 겹쳐 있다.

첫째, "이 정도 걸로 돈을 받을 수 있나?" 자기가 만든 걸 과소평가한다. 주말에 몇 시간 만에 만든 거라 별것 아닌 것 같다. 근데 사용자한테 중요한 건 개발 시간이 아니라, 해결해주는 문제의 크기다. 주말에 만든 스크립트가 누군가의 주 3시간짜리 반복 작업을 없앨 수 있다면, 그건 충분히 가치가 있다.

둘째, "돈 받으면 사람들이 안 쓸 텐데." 가격을 매기는 순간 사용자가 줄어들 거라는 공포. 맞다, 줄어든다. 무료 사용자의 대부분은 떨어져 나간다. 근데 남는 사람이 진짜 사용자다. 무료 사용자 1,000명보다 유료 사용자 10명이 사업적으로 더 가치가 있다. 유료 사용자는 피드백을 주고, 기능을 요청하고, 다른 사람한테 추천한다. 무료 사용자는 대부분 가입만 하고 사라진다.

셋째, "오픈소스 문화에서 돈을 받는 게 맞나?" 개발자 커뮤니티는 무료와 오픈소스에 대한 강한 문화가 있다. 나도 그 문화를 좋아한다. 근데 오픈소스로 유지할 수 있는 건 결국 다른 수입원이 있을 때다. 지속 가능한 프로젝트를 만들고 싶으면 수익 모델이 필요하다. 오픈소스와 유료가 양립할 수 있는 모델도 많다. 코어는 오픈소스, 부가 기능이나 호스팅은 유료 같은 방식.

가격은 어떻게 정하는가#

가격 책정은 개발자한테 가장 어색한 영역 중 하나다. 정답이 없으니까.

내가 주변에서 관찰한 패턴과, 여러 글에서 읽은 걸 종합하면 이렇다.

대부분의 사이드 프로젝트 운영자가 가격을 너무 낮게 책정한다. "월 3,000원이면 부담 없이 쓰겠지?"라고 생각한다. 근데 월 3,000원이든 월 30,000원이든 결제라는 행위 자체의 허들은 비슷하다. 어차피 카드 번호를 입력해야 하니까. 그런데 월 3,000원이면 사용자 300명이 있어야 월 90만 원인데, 월 30,000원이면 30명이면 된다. 사용자 300명 모으는 거랑 30명 모으는 거는 난이도가 10배 차이다.

물론 가격을 높이려면 그만한 가치가 있어야 한다. 핵심은 "내가 투자한 시간" 기준으로 가격을 매기지 말고, "사용자가 얻는 가치" 기준으로 매기는 거다. 이 도구가 사용자의 시간을 한 달에 5시간 절약해준다면, 그 사용자의 시급 기준으로 계산해볼 수 있다. 개발자 시급이 5만 원이라면 25만 원의 가치를 만들어주는 건데, 월 2만 원은 합리적인 가격이 된다.

초기에는 과감하게 실험하는 것도 방법이다. 같은 서비스를 월 9,900원과 월 19,900원으로 A/B 테스트해볼 수 있다. 전환율 차이가 크지 않다면 높은 가격이 더 좋은 선택이다.

한 가지 더. 가격 페이지에 세 가지 플랜을 넣는 패턴이 있다. Free, Pro, Enterprise 같은 구조. 근데 MVP 단계에서 세 가지 플랜은 과하다. 플랜이 여러 개면 각 플랜의 기능을 나눠야 하고, 그 구분을 구현해야 하고, 업그레이드 플로우를 만들어야 한다. 초기에는 무료 + 유료 하나, 이렇게 두 개면 충분하다.

메이커에서 마케터로의 전환#

수익이 나기 시작하면 역할이 바뀐다. 이게 가장 불편한 부분이다.

코드를 짜는 시간보다 다른 일을 하는 시간이 늘어난다. 사용자 문의에 답하고, 기능 요청을 정리하고, 랜딩 페이지 문구를 고치고, 커뮤니티에 글을 올리고, 트위터에서 사람들과 대화하고. 이게 다 "마케팅"이다. 광고를 돌리는 것만이 마케팅이 아니다.

개발자한테 이 전환이 특히 어려운 이유가 있다. 코딩은 즉각적인 피드백이 온다. 코드를 짜면 화면에 결과가 나온다. 테스트를 돌리면 통과하거나 실패하거나. 마케팅은 그렇지 않다. 글을 올려도 반응이 없을 수 있다. 트위터에 제품을 공유해도 좋아요 2개로 끝날 수 있다. 이 피드백 루프의 불확실성이 스트레스다.

근데 수익을 내려면 이 불편함을 감수해야 한다. 좋은 제품이 자동으로 퍼지는 경우는 극히 드물다. Sam Altman도 "Cohesive teams, the right combination of calmness and urgency, and unreasonable commitment are how things get finished"라고 했는데, 여기서 "unreasonable commitment" 부분이 핵심이다. 합리적인 범위를 넘어서는 노력이 필요하다는 거다.

내가 본 효과적인 방법 몇 가지를 적어보면.

Build in Public. 만드는 과정을 공개한다. 트위터나 블로그에 매주 진행 상황을 공유한다. "이번 주에 결제 기능을 붙였다", "사용자 피드백으로 이런 걸 고쳤다." 이게 놀라울 정도로 효과가 있다. 사람들은 완성된 제품보다 만들어가는 과정에 관심을 가진다. 과정을 따라오면서 자연스럽게 서비스에 대한 인지가 생긴다.

커뮤니티 기여. 관련 커뮤니티에서 자기 제품을 직접 홍보하는 게 아니라, 해당 분야의 지식을 공유한다. 예를 들어 개발자 생산성 도구를 만든다면, 개발자 커뮤니티에서 생산성 관련 팁을 나누는 거다. 글의 맨 아래에 "참고로 저는 이런 도구를 만들고 있습니다" 한 줄을 넣는다. 직접적인 광고보다 이 방식이 신뢰를 훨씬 많이 얻는다.

기존 사용자 활용. 유료 사용자한테 "혹시 주변에 이 도구가 도움될 만한 분이 있으면 소개해주실 수 있나요?"라고 물어본다. 간단한 부탁인데, 이걸 하는 사람이 별로 없다. 만족하는 사용자는 의외로 기꺼이 추천해준다.

첫 결제의 의미#

사이드 프로젝트에서 첫 결제가 들어온 순간을 기억하는 사람들이 많다. 액수가 중요한 게 아니다. 월 5,000원이어도. "세상에 누군가가 내가 만든 것에 돈을 낼 만큼의 가치를 느꼈다"는 사실 자체가 의미가 있다.

이게 취미와 사업의 경계선이다. 첫 결제가 들어오면 책임이 생긴다. 이 사람이 돈을 냈으니까, 서비스가 안정적이어야 하고, 문제가 생기면 대응해야 하고, 약속한 기능은 유지해야 한다. 부담이 되기도 하지만 동기부여도 된다.

한 지인은 첫 유료 사용자가 생긴 후에 개발 속도가 두 배가 됐다고 했다. "쓰는 사람이 있으니까 대충 할 수가 없더라"고. 반대로 무료 사이드 프로젝트일 때는 1주일에 한 번 커밋하다가 점점 빈도가 줄어서 결국 방치됐었다고.

지속 가능한 구조#

첫 수익이 나면 그 다음 질문은 "이걸 계속 할 수 있는가?"다.

재직 중에 사이드로 운영하는 건 한계가 있다. 사용자가 늘면 문의도 늘고, 버그 수정도 해야 하고, 기능 요청도 처리해야 한다. 퇴근 후에 이걸 다 하기엔 시간이 부족하다. 그래서 이 시점에서 선택이 필요하다. 성장을 제한하면서 관리 가능한 규모로 유지할 건지, 아니면 이직 혹은 퇴사를 고민할 건지.

둘 다 유효한 선택이다. 모든 사이드 프로젝트가 풀타임 사업이 되어야 하는 건 아니다. 월 50만 원짜리 작은 SaaS를 유지하면서 본업을 계속하는 것도 괜찮다. 중요한 건 명시적으로 선택하는 거다. "언젠가는 풀타임으로 해야지" 하면서 애매한 상태로 있으면 양쪽 다 중간만 하게 된다.

Sam Altman이 "Compounding exponentials are magic"이라고 했다. 복리의 마법. 작은 수익이라도 꾸준히 성장하면 어느 순간 의미 있는 규모가 된다. 월 수익이 매달 10%씩 늘어나면, 월 10만 원이 1년 후에 월 31만 원이 되고, 2년 후에 월 98만 원이 된다. 작은 시작이라도 성장률이 일정하면 결국 도달한다.

물론 매달 10% 성장을 유지하는 게 쉽지 않다. 성장이 멈추는 지점이 온다. 그때 다시 결정을 해야 한다. 현재 규모에 만족할 건지, 다음 성장을 위해 투자를 할 건지. 이 판단의 연속이 사이드 프로젝트를 사업으로 만드는 과정이다.

돌이켜보면#

내 GitHub에는 수익을 내지 못한 사이드 프로젝트가 여러 개 있다. 공통점이 있다. 사용자를 나중에 생각했다. 만드는 과정이 즐거웠고, 만드는 것 자체가 목적이었다. 수익이 아니라 학습이 목표였으니까 그 자체로는 괜찮다. 근데 "수익도 내고 싶다"는 마음이 있었다면, 접근이 달랐어야 했다.

다음 사이드 프로젝트에서는 순서를 바꿔보려 한다. 불편한 문제를 먼저 찾고, 사람들한테 먼저 물어보고, 최소한의 것만 만들어서 빠르게 공개하고, 돈을 내겠다는 사람이 나타나면 그때 제대로 만든다. 이 순서가 직관과 반대여서 어렵다. 개발자는 만드는 게 가장 편하니까. 근데 편한 걸 먼저 하면 중요한 걸 놓친다.

작은 시작이어도 괜찮다. 첫 유료 사용자 1명을 만드는 경험이, 무료 사용자 1,000명보다 배우는 게 많다.