사이드 프로젝트 팀원 구하기,
어디서 어떻게 했나
세 번의 팀 구성 경험 — 성공한 것과 실패한 것 모두
팀원 구하기 전에 먼저 깨달은 것
사이드 프로젝트를 혼자 시작했다가 두 달 만에 포기한 경험이 두 번 있었다. 기술적으로 막힌 게 아니었다. 그냥 혼자라서 지속하기가 어려웠다. 진척이 없는 것처럼 느껴지고, 피드백이 없고, 막히면 며칠씩 방치했다.
팀원을 구하기로 한 건 그 두 번의 실패 이후였다. 구하는 게 쉽지 않았다. 처음엔 아무나 찾으려고 했다가 더 힘들어졌다. 세 번의 팀 구성을 경험하고 나서야 "어떻게 구해야 하는지"가 보이기 시작했다.
플랫폼별 실제 경험 — 어디서 구했나
첫 번째 팀 구성 — 실패한 모집 글
처음엔 무작정 올렸다. 오픈채팅방에 모집 글을 붙였는데 지금 보면 왜 안 됐는지 보인다.
안녕하세요! 사이드 프로젝트 팀원 모집합니다.
모집 인원: 백엔드 1명, 디자이너 1명
프로젝트: 개발자를 위한 유용한 서비스 예정
기간: 미정
스택: Next.js, TypeScript
같이 열심히 하실 분 DM 주세요!
개선한 모집 글 — 반응이 달랐다
세 번째 팀을 구할 때는 글을 완전히 다르게 썼다. 팀원 후보 입장에서 "내가 이 글을 보고 DM을 보낼 것 같은가"를 먼저 생각했다.
무엇을 만드나요?
개발자들이 읽은 기술 서적을 기록하고, 같은 책을 읽은 사람들끼리 독서 노트를 공유하는 서비스입니다. 개인적으로 "좋은 책인데 같이 읽을 사람이 없다"는 문제를 직접 겪어서 만들려고 합니다.
현재 상태
• 기획 문서 작성 완료 (Notion 링크 첨부)
• 와이어프레임 1차 완성
• 프론트엔드(저) 개발 중 — 기본 레이아웃 구현 완료
이런 분을 찾습니다
• 주 2~3시간 정도 시간을 낼 수 있는 분 (많지 않아도 됩니다)
• 기술보다 꾸준히 함께할 의지가 더 중요합니다
• 백엔드: Node.js 또는 Python, DB 설계 가능하신 분
• 디자이너: Figma 사용 가능, UX 감각 있으신 분
목표와 일정
• 3개월 MVP 완성 목표
• 수익화보다 포트폴리오 + 실제 사용자 확보가 주 목표
• 주 1회 30분 온라인 미팅
관심 있으시면 DM으로 간단한 자기소개 주세요.
팀원 입장에서 판단하는 정보는 다섯 가지다. 무엇을 왜 만드는지, 지금 어디까지 됐는지, 얼마나 시간이 필요한지, 완성 후 어떻게 할 건지, 어떤 사람을 원하는지. 이 다섯 가지가 없으면 DM을 보낼 이유가 없다.
실제 팀 구성 사례 — 세 번의 기록
3명이 빠르게 모였다. 첫 미팅은 좋았다. 아이디어도 좋고 열의도 있었다. 문제는 2주 후부터였다. 백엔드 A는 연락이 뜸해지더니 한 달 후 "개인 사정이 생겼다"고 나갔다. 디자이너 B는 한 달 반 뒤에 "다른 팀에서 같이 하자는 곳이 있어서"라고 나갔다. 아무것도 완성 못 하고 해산했다. 시간 약속도, 기여 기준도 없이 시작한 게 문제였다.
해커톤에서 같이 48시간을 보낸 팀원들이었다. 서로 어떻게 일하는지 이미 알았다. "이분들이랑 사이드 프로젝트 해보면 어떨까"라고 제안했고, 둘 다 동의했다. 처음 만나는 사람들과는 다른 출발점이었다. 3개월 만에 MVP를 완성했고, 실제 사용자가 50명 넘었다. 지금도 가끔 연락한다.
개선한 모집 글을 사이드프로젝트바에 올렸다. DM 8건 중 3명을 인터뷰했고, 1명을 선택했다. 선택 기준은 기술 스택보다 "이분이 완성까지 같이 갈 것 같은가"였다. 민수는 이전에 사이드 프로젝트를 완성한 경험이 있었고, 왜 이 프로젝트에 관심이 있는지를 명확하게 말했다. 지금 3개월 째 진행 중이다.
팀원 선택할 때 보는 것들
DM이 와도 다 같이 하면 안 됐다. 인터뷰를 거쳤고, 내가 보는 기준이 생겼다.
이전에 사이드 프로젝트나 개인 프로젝트를 완성한 경험이 있는 사람. 완성하는 습관이 있는 사람이 다시 완성한다. 능력보다 완주력이 더 중요했다.
"재밌어 보여서요"보다 "저도 이 문제를 겪어봤어요"가 훨씬 낫다. 당사자성이 있는 사람이 힘든 시기에도 계속한다.
"주말에 많이 할 수 있어요"보다 "주 2~3시간 정도는 확실히 가능해요"가 더 믿음직스럽다. 과도한 의욕보다 지속 가능한 약속이 맞다.
포트폴리오가 3년 전에 멈춘 사람보다 최근에도 코드를 쓰는 사람이 낫다. 기술보다 현재 활동성을 본다.
DM에 답이 이틀 걸리는 사람은 프로젝트 중에도 그렇다. 반응 속도가 협업 스타일을 보여준다.
"수익 분배는요?", "나중에 스타트업 하면 지분은요?" — 시작도 안 했는데 이런 얘기부터 나오면 조심하는 게 맞다. 지금 만들자는 얘기를 먼저 해야 한다.
팀이 흐지부지되는 패턴들
"각자 할 수 있을 만큼 하자"는 말이 처음엔 좋게 들리지만, 나중에 누군가는 많이 하고 누군가는 조금 하는 불균형이 생긴다. 시작할 때 "주 몇 시간, 주 몇 커밋" 같은 기준을 명확하게 해야 한다.
"이 기능 넣을까요?" "글쎄요 어떻게 생각해요?" — 이런 논의가 계속되면 진행이 안 된다. 누가 최종 결정하는지를 미리 정해야 한다. 작은 프로젝트라도 PM 역할이 필요하다.
"이 기능도 넣으면 어때요?" — MVP에 없던 기능이 계속 추가됐다. 완성 기준이 없으면 프로젝트가 끝나지 않는다. "이 기능들만 완성하면 1차 배포"를 처음에 정해야 한다.
바빠서 미팅을 미루다 보면 두 달이 지나간다. 두 달 공백은 거의 해산이다. 주 1회 30분이 어려우면 격주 30분이라도 고정으로 잡아야 한다.
좋은 팀원보다 맞는 팀원이 낫다. 실력이 뛰어나도 같이 완성하기 어려운 사람이 있고, 평범해도 끝까지 같이 가는 사람이 있다. 사이드 프로젝트에서는 후자가 훨씬 더 가치 있다.
팀을 유지하는 데 실제로 효과 있었던 것들
격주 30분 미팅 고정. 바쁜 사람들끼리 만나는 거라 1시간 미팅은 부담이 됐다. 30분짜리 고정 미팅이 더 오래갔다. 짧지만 규칙적인 것이 길지만 불규칙한 것보다 팀을 유지했다.
슬랙에 "오늘 한 것" 채널. 매일 올릴 필요 없이, 뭔가 했을 때 짧게 공유하는 채널을 만들었다. 서로가 프로젝트를 계속하고 있다는 걸 확인하는 것만으로 팀 분위기가 달랐다.
작은 이정표마다 축하. "이 기능 완성됐어요" → 팀 채팅에 이모지 잔뜩 달기. 별 거 아닌 것 같지만 사이드 프로젝트는 외부 압박이 없어서 내부 보상이 없으면 지속하기 어렵다.
팀원을 구하기 전에 이 세 가지를 먼저 준비한다. 첫째, 왜 이 프로젝트를 만드는지 한 문장으로 설명할 수 있는가. 둘째, MVP 기준이 정해져 있는가 (어디까지 만들면 1차 완성인지). 셋째, 현재 어디까지 진행됐는지 보여줄 것이 있는가. 이 세 가지가 없으면 좋은 팀원이 관심을 가질 이유가 없다.
사이드 프로젝트 팀원 구하기는 채용과 비슷하다. 아무나 빠르게 구하는 것보다 맞는 사람을 천천히 구하는 게 낫다. 그리고 팀원을 구하는 것보다 팀을 유지하는 게 더 어렵다는 것도 경험으로 알았다.
지금 팀이 3개월 째 잘 돌아가는 건 처음에 기준을 정하고, 서로 기대치를 맞추고, 작은 것도 공유하는 루틴이 있기 때문이다. 팀원 한 명이 좋은 것도 있지만, 이번엔 팀 자체가 잘 설계됐다는 생각이 든다.
💬 사이드 프로젝트 팀원을 어떻게 구하셨나요?
성공한 팀 구성 방법, 실패 경험, 팀을 유지하는 노하우 — 어떤 이야기든 댓글로 나눠주세요. 지금 팀원을 찾고 있는 분들에게 가장 현실적인 정보가 될 것 같습니다.
'개발자 > 사이드프로젝트 창업' 카테고리의 다른 글
| 주말 48시간 해커톤 참가 경험담 (0) | 2026.08.01 |
|---|---|
| 개발자가 유튜브·블로그로 부수입 만든 방법 (1) | 2026.07.25 |
| 오픈소스 프로젝트 만들어서 스타 100개 받기까지 (0) | 2026.07.18 |
| 개발자가 부업으로 외주 받아본 현실 후기 (0) | 2026.07.11 |
| 개발자 둘이서 창업했을 때 갈라진 이유 (0) | 2026.07.04 |
