Filed under창업가 & 인물 역설계on•3 분 분량

인디 메이커 토니 다인은 어떻게 여러 프로젝트를 동시에 운영할까?

DevUtils와 Xnapper를 만든 토니 다인의 사례를 통해, 1인 개발자가 유지보수가 적은 제품을 골라 여러 개의 프로젝트를 동시에 성공시키는 작업 분할과 의사결정 루틴을 역설계한다.

토니 다인의 멀티 프로젝트 생존법

개발자이자 인디 메이커인 토니 다인은 Indie Hackers 인터뷰를 통해 DevUtils, Xnapper, Typing Mind 등 여러 프로젝트를 동시에 굴리며 성과를 만들어냈다고 밝혔다. 혼자서 하나의 제품을 유지보수하는 것만으로도 벅찬 경우가 허다하다는 점에서, 그의 행보는 다소 이례적으로 보인다. 마치 여러 개의 트랙을 동시에 달리는 곡예를 연상시키기도 한다.

많은 이들이 하나의 SaaS 제품에 매몰되거나 끊임없는 고객 지원과 서버 관리의 무게에 지쳐 포기하곤 한다. 하지만 토니 다인은 다른 접근을 택했다. 그는 자신이 만들고 싶은 것과 사람들이 원하는 것의 교차점을 찾고, 유지보수가 적은 제품군을 전략적으로 골라 포트폴리오를 꾸린다.

빌드 인 퍼블릭을 배포 채널로 활용하기

그가 제품을 세상에 내놓는 방식은 일반적인 순서와 다르다. 아이디어를 구상할 때 랜딩 페이지를 만들고 대기자 명단을 모으는 대신, 트위터를 통해 공개적으로 빌드를 시작한다.

초기 댓글과 참여도는 제품을 완성하기도 전에 이 문제가 실제로 사람들의 공감을 얻는지 파악할 수 있는 가장 빠른 신호가 된다. 토니 다인은 단순히 기능을 빠르게 출고하는 것에 그치지 않고, 빌드 인 퍼블릭(Build in Public) 방식을 통해 모든 개발 과정을 마케팅 기회로 삼아 매일의 진척 상황을 외부에 알렸다. 사람들은 흔히 빌드 인 퍼블릭을 부수적인 활동으로 여기지만, 그는 이를 가장 강력한 배포 채널로 활용했다.

유지보수 부하를 줄이는 제품 선택의 기준

핵심 비교

일반 SaaS

  • 지속적인 서버 모니터링 및 가동 상태 유지 필요
  • 실시간 고객 지원 및 버그 수정 부담
  • 다중 계정 관리 및 운영 복잡성 높음
VS

다운로드형 앱

  • 서버 인프라 관리 부담 부재
  • 고객 문의 대부분이 기능 요청으로 즉각 대응 불필요
  • 유지보수 부하가 적어 다수 프로젝트 병행 가능

여러 프로젝트를 동시에 굴릴 때 가장 먼저 부딪히는 벽은 운영의 복잡성이다. 혼합된 매출 보고서, 공유 계정, 이메일 지원, 파트너십, 복수의 결제 계정 등 관리가 순식간에 엉망이 되기 쉽다.

토니 다인은 이 문제를 제품의 성격 자체를 조율하는 것으로 해결했다. Indie Hackers에서 언급했듯, SaaS 제품은 늘 고객 지원이 필요하고 서버 가동 상태를 유지해야 하므로 손이 많이 간다. 반면 다운로드 가능한 앱은 서버를 신경 쓸 필요가 없어 상대적으로 여유롭다. 고객 이메일의 대부분은 기능 요청일 뿐 당장 조치를 취할 필요가 없는 경우가 많다는 점에 주목했다.

그가 정하는 아이디어 선정의 핵심 원칙은 명확하다. 가능한 한 유지보수 노력이 적게 드는 제품을 고르는 것이다. 아이디어를 평가할 때는 흥미도와 작업량에 각각 점수를 매겨 곱한 뒤, 가장 높은 점수가 나오는 것부터 실행에 옮긴다.

3~4시간 단위로 쪼개는 실행 루틴

프로젝트가 여러 개일 때 가장 경계해야 할 적은 열정의 소멸이다. 순수한 열정은 한정된 자원이며, 이것이 식어버리면 나머지 도미노는 무너지고 만다.

토니 다인은 이를 방지하기 위해 작업의 90%를 하나의 작업 세션 안에서 끝낼 수 있는 작은 단위로 쪼갠다. 빌드, 테스트, 배포, 문서화까지 포함해 약 3시간에서 4시간 안에 끝낼 수 있는 크기여야 한다. 흥미도와 작업 타임라인을 끊임없이 저울질하며, 당일 처리할 수 있는 단위로 잘게 쪼개는 것이 그가 여러 프로젝트를 동시에 굴리면서도 번아웃에 빠지지 않는 비결이다.

무엇을 차용하고 무엇을 경계해야 하는가

초기 1인 개발자 적용 시 유의점
  • 기존 팔로워 오디언스가 없다면 다수 프로젝트 동시 공개 시 주목도 분산 위험
  • 결제 계정 분리, 세무, 이메일 대응 등 행정적 복잡성이 개발 시간을 잠식할 우려
  • 검증되지 않은 상태에서의 확장을 지양하고 단일 마이크로 제품의 유지보수성부터 확인 필요

이 루틴에서 1인 개발자가 바로 적용할 수 있는 지점은 분명하다. 거대한 SaaS 하나에 모든 것을 걸기보다 유지보수 부담이 적은 마이크로 제품을 검토하고, 업무를 3~4시간 단위로 잘게 쪼개어 실행 속도를 높이는 방식은 당장 시도해볼 만하다.

반면, 이미 트위터에 탄탄한 팔로워 오디언스를 확보하고 있는 토니 다인의 조건은 초기 1인 창업가에게는 당장 재현하기 어려운 불공정한 장점이다. 오디언스가 없는 상태에서 무턱대고 여러 개의 프로젝트를 빌드 인 퍼블릭으로 동시에 노출했다가는, 분산된 주목도 때문에 이도 저도 안 되는 결과를 마주할 수 있다. 여러 제품을 관리하는 데 따르는 행정적 복잡성 역시 충분한 준비가 없다면 오히려 개발 시간을 갉아먹는 독이 될 수 있음을 유념해야 한다.

참고 자료

자주 묻는 질문 (FAQ)

Q. 1인 개발자가 여러 제품을 동시에 관리하는 것이 실제로 가능한가?

토니 다인은 SaaS 대신 다운로드 가능한 앱이나 유지보수 노력이 적은 제품군을 전략적으로 선택하고, 업무를 3~4시간 단위로 잘게 쪼개어 관리하는 방식으로 여러 프로젝트를 병행한다.

Q. 빌드 인 퍼블릭은 제품 개발 전 검증에 얼마나 효과적인가?

랜딩 페이지와 대기자 명단을 모으는 것보다 트위터 등에서 공개적으로 빌드를 진행하며 얻는 초기 반응과 참여도가 훨씬 빠른 검증 신호를 준다.

Q. 여러 프로젝트를 운영할 때 발생하는 관리의 복잡성은 어떻게 해결해야 하는가?

혼자서 여러 제품을 운영하면 결제 계정, 고객 지원, 파트너십 등이 얽혀 관리가 복잡해지므로, 이를 통합할 수 있는 워크플로우를 구축해야 한다고 토니 다인은 조언한다.

모든 아티클로 돌아가기홈