실패한 SNS 서비스 개발 기록.0
프롤로그
1인 개발팀이 음성 숏폼, 음성 라이브, SNS 기능을 제공하는 서비스를 만들려는 무모한 시도를 4년 동안 진행하면서 겪은 시행착오와 경험을 40k Loc에 달하는 flutter 소스 코드와 그에 상응하는 서버 코드를 바탕으로 기록하려 합니다.
https://www.producthunt.com/products/effy
0번 문제. 팀의 역량 파악과 그에 맞는 목표의 크기
CEO 겸 CPO가 개발에 참여를 하기는 하였지만 개발을 전담하는 개발자는 1인이었고, 우리는 1인 개발자가 혼자 할 수 있는 일의 범위를 정확히 알지 못하였습니다. 그 결과 우리의 역량 보다 큰 MVP가 기획되었고, MVP 작성에 너무 많은 시간을 보냈습니다. 늘어지는 개발은 기획 수정으로 이이지고, 수정된 기획으로 인하여 또다시 개발이 늘어지는 악순환이 시작되었습니다. 그 결과 우리는 서비스를 출시 하고, 운영 하였지만 한번도 MVP를 만족 시켜 보지 못하였습니다.
개발자 1인이 ‘1’을 할수 있다면 ‘1.1’을 할때는 2명이 필요하지 1.1명이 필요하지 않다!
“현식 님을 둘로 나누면 모든 것이 해결될 텐데" 개발을 진행하면서 자주 나오던 농담입니다. 너무 많지 않은 1.1 정도의 작업양이고, 충분이 해낼 수 있다고 생각 하였지만 오판 이었습니다. 클라이언트 부터 서버 까지 방대한 context를 머리에 넣어 두고, 하루에도 수십번씩 context 전환을 하면서 개발하는 것은 체력적으로도 매우 힘들고, 개발 속도를 느려지게 하는 매우 큰 원인이 되었습니다. 또한 context 전환에서 오는 스트레스로 인하여 context 전환를 줄이는 방향으로 설계가 수정되는 부수적인 효과도 발생하였습니다.
톰 드마르코는 ‘slack’에서 여유를 아까워 하지 말라! 그것이 곧 이슈에 대한 빠른 대응력이 된다고 말했거늘 과도한 욕심에 무리한 목표를 정하였고, 그 결과는 4년 6개월간 완료되지 못한 MVP로 이어졌습니다.
결론.
기획과 설계를 하다 보면 왕왕 나의 역량 보다 큰 상상을 하게 됩니다. 자신과 팀의 능력을 객관화 하고, 지나친 상상을 금지하세요.
