🏃🏻‍➡️ 프론트엔드 개발자 창업 도전기

이 글은 "창업 도전기"이지만, "근사한 성공담"은 아닙니다.
지난 10개월 간 몰두해 MVP를 기획·개발한 후 영업에 나섰고, 현재는 사업 잠정 중단 결정을 내렸습니다.
개발만 했던 개발자가 직접 제품을 영업하며 고민한 내용을 공유하고 기록해두고자 이 글을 썼습니다.

작년 8월 말일 퇴사했습니다. 회사의 경영악화로 인한 퇴사로 갑작스러웠던 만큼, 다음 커리어에 대해 고민해볼 시간을 갖기로 했습니다. 약 2년 간 프론트엔드 개발자로 근무했던 시간을 돌아보았습니다. 다양한 직군의 팀 동료들과 협업하는 과정은 만족스러웠으나, 개발을 담당한 제품에는 기대만큼 애정을 갖지 못했던 점이 아쉬웠습니다. 당장 이직하기보다는 관심을 꾸준히 가져온 도메인의 서비스를 직접 개발해보기로 했습니다. Dio는 다음과 같은 타임라인으로 제작되었습니다.

(백엔드 동료 한 명과 함께 2인 프로젝트로 시작했으나 프로젝트 중반(6월), 개인 프로젝트로 전환하기로 결정했습니다. 서버를 처음부터 새로 구축하게 되어, 백엔드 개발을 프론트 개발 후에 진행하였습니다.)

❊ 댄스 스튜디오 플랫폼 웹 서비스 Dio

제가 개발한 제품은 댄스 스튜디오 플랫폼 웹 서비스 Dio입니다.
댄스 스튜디오 수강권을 구매하고, 수업을 예약할 수 있는 서비스입니다.
아래 사진과 같이 일반 유저 플랫폼 ≪Dio≫와 댄스 스튜디오 관리자를 위한 ≪Dio 스튜디오 센터≫로 구성된 제품입니다.

랜딩페이지(https://diowith.me)에 방문하시면 더 상세한 ≪Dio≫ 소개를 만나보실 수 있습니다. Dio 스튜디오 센터도 링크를 통해 접속할 수 있고요.

Dio의 주요 기능은 다음과 같습니다.

Dio를 기획한 이유는요...!

퇴사 후 서울 소재 F댄스스튜디오에서 수업을 들었습니다. 한참 Mnet ≪스트리트우먼파이터2≫가 방영을 마치고, 방송 출연 댄서들이 유명 댄스 스튜디오에서 팝업 클래스를 하던 때였습니다. Yoonji의 왁킹 클래스가 예정되어 있다기에 예약을 하려고 웹사이트에 접속했습니다. 본업이 개발자이다보니 웹사이트에서 생각보다 많은 개선점을 발견할 수 있었습니다. 기억나는 대로 적어보면,

• 구글에서 웹사이트 링크를 클릭 시 곧장 TIMED_OUT 에러가 발생 (새로고침 후에 정상 접속 가능)
• 모바일 접근 시 결제 과정에서 에러 발생
• 인증 과정과 결제 기능이 있지만 http로 배포됨

썩 매끄럽지 못한 과정이었으나, 결국 예약을 하고 클래스도 재밌게 들었습니다. 수업 후 F댄스스튜디오 관리자 분과 이야기를 나누었습니다. 예약과정의 어려움을 이야기 하니, 관리자로서도 매번 웹사이트 관련 문의를 대응하기가 번거롭다는 이야기를 해주셨습니다. 웹사이트 구축과 관리에 적지 않은 비용이 든다는 이야기도 전해들었고요.

Dio의 아이디어는 여기서 시작되었습니다.

댄스 스튜디오 플랫폼 웹사이트를 개발해 수강권 결제 및 예약 서비스를 제공하면, 원밀리언댄스스튜디오나 YGX 같은 기업 단위의 댄스 스튜디오가 아니라도 더 매끄러운 UI/UX를 갖춘 서비스를 이용할 수 있을 거라 생각했습니다. 프로젝트에 앞서 직접 방문했던 F댄스스튜디오 관리자 분, 그리고 M댄스스튜디오 대표님, 총 두 분과 인터뷰를 진행하고, 간단한 리서치를 진행했습니다.

리서치를 해보니 F댄스스튜디오보다 더 복잡한 예약 플로우를 가진 스튜디오도 많았습니다.

위 사진과 같은 경우가 그 예시입니다.
유명 댄스 스튜디오들 중 일부는 인스타그램 + 구글폼을 조합해 예약 솔루션으로 활용중이었습니다.

예약 플로우를 정리해보면 아래와 같습니다.

1) 스튜디오가 인스타그램을 통해 이미지로 제작된 수업 스케쥴을 공지하면,
2) 수강생은 원하는 수업을 골라 구글폼을 통해 예약 신청서를 작성합니다.
3) 신청서 제출 후 입금을 완료하면,
4) 스튜디오에서는 입금 내역을 확인하고 예약 처리합니다.

개발자가 IT 프로덕트를 통해 자동화했을 때 임팩트를 내기 좋은 플로우라고 생각헀습니다. 특히, 하나의 시스템 내에서 스케쥴 공지, 수업 예약, 결제를 한번에 할 수 있고, 예약 절차를 간소화할 수 있다면, 충분히 경쟁력있는 솔루션이 담긴 제품을 만들 수 있겠다고 판단했습니다.

❊ 사업 준비과정

• 비상주 사무실을 계약하고,
• 사업자 등록과 정보통신판매업 신고를 마친 후,

• 결제 기능(토스페이먼츠)과 이메일(AWS SES), 알림톡 발송(Naver Cloud Service) 기능을 구현하기 위해 외부 솔루션을 선정하고 심사를 거쳤습니다.
• 서비스 이용약관과 개인정보 처리 방침, 그리고 학원법 시행령에 기반한 환불 정책을 작성했습니다.

그리고 프론트엔드와 백엔드 개발을 거쳐 Dio MVP를 완성하게 되었습니다.

(이 글은 "개발 회고"보다는 "영업 후기"를 공유하는데 그 목적이 있으므로,
MVP 개발 과정에 대한 자세한 내용은 추후 다른 포스팅에 정리해보겠습니다.)

❊ 영업 타임라인

9월에 MVP 개발을 마무리하고, Dio의 파트너사를 찾기 위해, 10월 2일 첫 영업에 나섰습니다.

총 세 차례에 걸쳐 서울 소재의 댄스 스튜디오 30여 곳에 방문하였습니다.
댄스 스튜디오가 밀집해 있는 지역 세 곳을 선정하고, 해당 지역에서 운영되고 있는 댄스 스튜디오에 방문해
Dio를 소개하였습니다.

• 10월 2일: 압구정, 신사, 논현, 강남 일대
• 10월 8일: 신촌, 홍대, 합정 일대
• 10월 15일: 건대입구, 성수 일대

• 스튜디오 대표님과 직접 대화를 나눈 곳과
• 매니저분께 서비스를 소개드린 곳
• 그리고 수업 중이거나 관리자가 없어서 명함만 전달드리거나 방문이 불가하였던 곳이 있었습니다.

이제부터 본론으로 들어가보겠습니다.
제가 30여 곳의 댄스 스튜디오로 영업을 다니며, 직접 잠재 고객들을 만나 이야기를 나누고 알게 된 댄스 스튜디오 시장은 제가 막연하게 리서치하고 예측했던 것과는 사뭇 달랐습니다.

1. IT 프로덕트는 정말 모든 곳에 필요할까?

"댄스 스튜디오"를 상상하면, "1Million Dance Studio"나 지금은 영업을 종료한 "YGX Academy"를 떠올리기 마련입니다. 하지만 영업을 다니며 접한 댄스 스튜디오 중 많은 경우는 "댄스 스튜디오"보다는 "춤 학원"에 가까웠습니다.

"댄스 스튜디오"는 여러 지역에서 다수의 익명 수강생이 유입되는 춤 활동 거점에 가깝다면,
"춤 학원"은 특정 지역에 기반을 둔 오프라인 커뮤니티에 가깝습니다.
(현재 서술한 "댄스 스튜디오"와 "춤 학원"에 대한 정의는 편의상의 정의이며, 이 포스팅 바깥에서 통용되는 정의가 아닙니다.)

영업차 방문한 30 곳의 스튜디오 중,
1. "원데이 클래스"나 "팝업 클래스" 위주로 매주 혹은 매달 스케쥴이 갱신되는 스튜디오들(Dio MVP의 타겟 고객)은 23.3%였으며,
2. 그 중에서도 둘 이상의 대규모 댄스룸(10명 이상의 수강생이 수업을 들을 수 있는 규모)을 가진 경우는 42% 정도에 불과했습니다. (전체 백분율로 환산 시 13.3%)

여기에 Dio MVP 설계의 첫 번째 실수가 있었습니다.

저는 IT 제품을 만들고 또 데이터를 통해 문제와 결과를 진단하는 개발자이다보니, 오프라인 반복작업을 온라인으로 자동화하고, 데이터를 분석할 수 있다면 어디에든 도움이 될 것이라 생각했습니다. 결제 기능과 출석체크 기능, 출결 데이터 조회 기능 등이 그 생각에서 설계된 기능들입니다.

그런데 "춤 학원"의 경우, 누가 공간에 오고 가는지, 현재 스튜디오의 상황은 어떠한지, 디지털 데이터에 의존하지 않아도 얼추 파악이 가능했습니다. 지역 기반의 "학원"에 다녀본 경험을 떠올리면 이해할 수 있을 것입니다. 누가 결석했고, 누가 새로 온 수강생인지 관리자가 단번에 파악이 가능하죠.

아래는 제가 영업 당시 인터뷰하며 들었던 응답들 중 일부를 발췌한 내용입니다.

• "코로나 시기에는 예약 시스템이 불가피 했어요. 평당 수용 인원이 제한되었으니까요. 그런데 지금은 아니에요. 사전에 예약이 마감되는 클래스는 그리 많지 않아요. 게다가 대부분의 수강생들은 온라인을 통해 사전 예약을 하기보다는 그냥 현장에서 카드 결제를 하는 걸 더 선호해요." (M댄스스튜디오)

• "사전에 SNS로 예약을 하고 방문하는 수강생은 수업 당 2~5 명 정도가 전부라 구글폼을 사용하는게 딱히 불편하지 않아요." (M댄스스튜디오)

• "댄스 스튜디오들은 수업을 하고 나면, 주로 영상을 남기는데, SNS에 업로드된 영상의 좋아요 수를 살피는 것으로 수강생들의 반응을 충분히 파악할 수 있어요. 특히 현장에서 스튜디오를 관리하면 어떤 수업이 인기 있는지 정도는 단번에 파악이 가능하고요. 지나간 수업의 출결 데이터를 다시 찾아보는 일은 거의 없어요." (M댄스스튜디오)

• "강사와 수강생의 유대감 형성을 위해서 일부러 출석부를 강사에게 전달하고, 한 명 한 명 출석을 부르면서 얼굴을 익힐 걸 권장해요." (J댄스아카데미)

• "우리 스튜디오가 3층, 4층이고, 층마다 댄스룸이 몇 개씩 있다면 당장이라도 앱이나 웹사이트를 사용할 것 같아요. 하지만 지금은 대표인 제가 혼자서 충분히 운영할 수 있는 정도예요." (M댄스스튜디오)

좁고 촘촘한 네트워크보다는 넓고 느슨한 네트워크를 기반으로 할 때,
IT 프로덕트는 더 큰 효능을 발휘한다.

제가 내린 결론은 위와 같습니다. 촘촘하고 좁은 네트워크의 경우, 온라인 IT 프로덕트를 통해 도출해낸 인사이트가 오프라인에서 감각적인 인지를 통해 얻은 인사이트와 크게 다르지 않습니다. 무엇보다 IT 프로덕트는 반드시 디바이스를 통해 접근해야 한다는 점을 떠올리면, "자동화"라고 하지만 자칫하면 오프라인 워크플로보다 번거로운 프로세스를 만들어낼 수도 있죠.

물론 촘촘하고 좁은 네트워크라 해도, 여전히 개발자가 IT 프로덕트를 통해 솔루션을 제공할 여지가 있다고 생각합니다. (댄스 스튜디오의 경우, 영상 아카이빙 서비스 라던지.) IT 프로덕트는 어디에나 필요합니다. 다만 타겟 시장의 규모와 특성에 적합한 솔루션을 제공할 때, IT 프로덕트는 비로소 큰 임팩트를 낼 수 있다는 점을 염두에 두어야겠습니다.

2. 고객이 제품을 선택하기 위해 고려하는 것은 기능뿐만이 아니다.

프로젝트를 시작하며, 경쟁사 리서치를 수행했었습니다.

Dio MVP는 경쟁사와 비교해 아래와 같은 이유로 경쟁력이 있을 것이라 판단했습니다.

• 스*** **트, 다*, 비** **M: 회원제로 운영되는 공간 관리 솔루션. 스*** **트의 경우에는 시스템 내 결제 기능을 제공하지 않음. 그 외에도 이 세 서비스는 모두 댄스 스튜디오에 최적화된 시스템이 아님. Dio MVP는 댄스 클래스에 최적화된 스케쥴링 기능과 시스템 내 결제 기능을 제공함.
• 인스타그램 + 구글폼: 관리자가 수동으로 입금 내역을 확인해야 하며, 수업 예약을 원하는 수강생이 구글 폼에서 원하는 클래스를 직접 찾아야 하는 번거로움이 있음. 동시에 학원 관리자가 매번 이미지로 클래스 스케쥴을 생성해서 공지해야 하고, 이미지로 스케쥴을 확인할 경우 정보 접근성이 떨어짐.

직접 들른 30 곳의 스튜디오들에서 사용하고 있는 솔루션 현황은 다음과 같았습니다.

(자체 웹사이트를 가진 12 곳의 스튜디오 중 자체 웹사이트에 예약 시스템이 있는 경우는 1 곳, 이외 자체 웹사이트는 주로 홍보 및 공지, 정보전달용 웹사이트)

저는 "이미 출시되어있는 솔루션보다 더 좋은 기능을 제공할 수만 있다면, 고객이 Dio MVP를 선택해줄 것"이라 생각했습니다. Dio MVP 기능들이라면 현재 스튜디오들에서 사용하고 있는 솔루션들보다 조금 이라도 더 나은 유저경험을 선사할 수 있을 거란 자신이 있었습니다. 그런데 막상 영업에 나서서 대화를 나누어보니 좋은 기능이 있어도 Dio MVP를 선택하지 않을 이유는 무궁무진했습니다.

제가 방문한 스튜디오들 중 Dio MVP 도입을 거절한 스튜디오들이 말씀해주신 이유는 다음과 같았습니다.

• 이미 구독한 서비스가 있어서, 구독이 만료될 때까지는 다른 서비스를 고려하기 어렵다.
• 이미 큰 비용을 지불하고 자체 웹사이트를 구축했다. 100% 만족스러운 것은 아니지만, 저희 스튜디오에 최적화되어있다.
• Dio MVP는 갓 론칭한 서비스라 불안정성이 우려된다.
• 제품의 운영 방식이 저희 스튜디오와는 맞지 않는다.

"기존의 솔루션보다 더 나은 솔루션"이라고 할 때, 더 나은 솔루션의 기준은 단순히 "기능", 그 자체에만 있는 것이 아니었습니다. 고객사들이 Dio를 선택하기 위해 지불해야 할 비용도 "서비스 이용료"에 그치는 것이 아니었고요.

정리해보면, 고객사가 직간접적으로 지불하는 비용은 아래와 같습니다.

• Dio 서비스 구독료
• 이미 지불한 기존 이용 서비스에 대한 남은 비용
• 새로운 서비스에 적응하기 위해 사용해야 하는 리소스
• (Dio의 경우 첫 론칭이므로) 새로운 서비스의 불안정성

결국 "내 제품이 사용할 만큼 충분히 좋다"고 말하려면, 제품이 제안하는 솔루션이 위 모든 비용을 상쇄할 수 있을 만큼 혁신적이어야 할 것입니다. 이렇게 생각하니, 단순히 좋은 기능, 혹은 좀 더 나은 기능을 제품에 담아낸다고 해서 고객의 선택을 받을 수 있을 것이란 판단은 조금 나이브했던 것이 아니었을까, 돌아보게 됩니다.

또 하나 제가 충분히 고려하지 못한 점이 있다면, 제품의 운영방식입니다.

Dio MVP는 마켓플레이스 형태를 띄고 있습니다. 이를테면 댄스 스튜디오계의 무신사 같은 형태인 것이지요. 여러 댄스 스튜디오의 클래스를 한 눈에 볼 수 있다면 수강생의 입장에서 좋겠다고 생각했습니다. 요즘엔 유명 댄서들이 여러 댄스 스튜디오를 돌아다니며 수업을 하기도 하는데, 수강생의 최애 댄서의 클래스 스케쥴을 모아서 보고 알림을 받을 수 있다면 제품이 더 경쟁력을 갖출 수 있겠다고 생각했습니다.

Dio MVP 기능을 선정할 때 제가 더 면밀히 따졌으면 좋았을 부분이 있다면, Dio가 가진 많은 기능들 각각이 타겟팅하고 있는 고객이 정확히 어떤 고객인지, 하는 부분입니다. Dio MVP는 크게 두 고객 유형을 대응합니다. 한 유형은 스튜디오 회원이고, 다른 한 유형은 수강생 회원입니다. 앞서 언급한 최애 댄서의 스케쥴 조회는 수강생 입장에서는 편리하고 좋은 기능이지만, 스튜디오 입장에서는 고객 이탈을 우려하게 될 수 있다는 점을 미처 생각하지 못했었습니다.

하나의 IT 프로덕트에는 여러 고객이 혼재해 있으며,
어떤 기능에 대해서는 여러 고객들의 반응이 서로 상충될 수 있다.

실제로 세 스튜디오에서 마켓플레이스 형식에 대한 우려를 표해주셨습니다.

아래와 같은 말씀을 해주신 스튜디오 대표님도 있었습니다.

• "댄서들은 경제적인 부분에서 무언가를 쉽게 보장받는 환경에 있는 사람들이 아니에요. 저는 나름대로 이름이 있는 댄스 스튜디오에 소속되어 일한 적이 있는데, 우리나라에서 가장 유명한 댄스 스튜디오인데도 월급을 받고 일하거나 하는 것도 아니에요. 그니까 댄서들은 자기 것을 지키려고 하지, 무작정 '너도 좋고 나도 좋게'라는 태도로 나오기가 힘들거에요."

이에 저는 "반대로 생각하면 다른 스튜디오 회원이 대표님의 스튜디오로 유입될 수도 있지 않을까요?"하고 반문했으나, 전혀 예상치 못한 대답이 돌아왔습니다.

• "그렇게까지 공격적으로 마케팅을 하는 건 이 업계에서 예의가 아닐 수도 있을 것 같아요."

물론 저는 아직도 Dio MVP가 제시한 마켓플레이스 형태가 수강생 유저에게 좋은 유저 경험을 선사할 수 있을 거라 생각합니다. 수강생 유저들에게 좋은 유저 경험을 선사해 유저의 유입이 많아져서 댄스 스튜디오 시장의 파이 자체가 커지면 결국 스튜디오 회원에게도 좋을 것이고요. 하지만 제가 Dio MVP의 주요 타겟을 수강생보다는 스튜디오로 선정했다면, 서비스 운영 초반에 오픈마켓에 대한 거부감을 완화할 수 있을만한 장치들을 고민했으면 좋았을 것입니다.

3. 사람을 모으는 것이 먼저일까, 실용적인 기능이 먼저일까

춤과 관련된 IT 제품을 만들겠다고 생각했을 때, 두 가지 큰 갈래의 방향이 있었습니다.

1. 댄서를 중심으로 한 커뮤니티 혹은 콘텐츠 웹사이트 개발
2. 춤추는 사람들이 이용할 수 있는 실용적인 기능 중심의 솔루션 개발

사업자등록을 하고 프로젝트를 이어나갈 계획이었으므로, 제품의 방향성을 결정하는데 있어 가장 중요한 문제는 "어떤 방향이 더 지속가능한 방향인가"하는 문제였습니다. 다시 말해, "어떤 방향이 더 지속적인 수익을 내기에 적합한가"하는 문제였죠.

1. 댄서를 중심으로 한 커뮤니티 혹은 콘텐츠 웹사이트 개발
   첫 번째 안이 창출할 수 있는 수익의 형태는 "광고료"일 것입니다. 간단한 기능을 중심으로 IT 제품 내에 먼저 유저들을 유입시키고, 추후 기능들을 고도화시켜 나가는 방안입니다. 쉬운 예시로는 춤 관련 행사 정보를 공유하는 웹사이트가 있을 수 있겠습니다.

2. 춤추는 사람들이 이용할 수 있는 실용적인 기능 중심의 솔루션 개발
   두 번째 안에 좀 더 적합한 수익의 형태는 "서비스 구독료 혹은 결제 수수료"겠죠. 잠재 고객들이 기꺼이 비용을 지불할 충분히 혁신적인 기능을 구현해 유저를 모으는 전략입니다. 유저가 모이고 나면 "광고" 서비스까지도 노려볼 수 있겠죠.

저는 무작정 "커뮤니티 기능 혹은 콘텐츠"를 구현한다고 해도 아무것도 없는 황무지같은 애플리케이션에 유저가 모여들지는 않는다고 생각했습니다. 오히려 유저를 움직이는 요인은 "혁신적인 기능"에 있다고 보았습니다. (지금은 이 결정에 대한 더 구체적인 고민과 검토가 필요했다고 생각합니다.) 그래서 우선 댄스 스튜디오를 타겟팅해, 구독료를 받고 명확한 기능을 제공하는 쪽을 택했습니다. 댄스 스튜디오를 통해 유저가 유입되고 나면 그 때 광고료를 받고 수익을 늘려볼 계획이었죠.

그런데 막상 영업에 나서니, 결제 기능이나 출석체크 기능보다 처음부터 "마케팅 효과"를 기대하는 스튜디오들이 더러 있었습니다. T댄스아카데미에서는 Dio 명함을 건네드리자마자, "그럼 여기에 저희 스튜디오를 홍보할 수 있는 거예요?"하고 되물으셨습니다. 저는 "기능"이 있어야 "유저"를 확보할 수 있다고 생각했지만, 사실 IT 제품은 일정 규모 이상의 "유저"가 모여야 또 다른 유저의 유입이 점점 쉬워진다는 사실을 미처 떠올리지 못했습니다. 특히 규모가 커지면 "대규모 유저" 자체가 주요한 셀링 포인트가 될수도 있고요. (여기서 언급한 "기능"이란 넓은 의미의 "기능"이 아니라, "편리함을 제공하는 솔루션"의 의미에 가깝습니다.)

영업 첫날 열 다섯 곳의 스튜디오를 방문해 서비스를 소개하고 대화를 나누었지만 파트너 스튜디오를 확보하지 못했습니다. 그래서 "Dio를 무료 서비스로 전환해서, 우선 서비스를 살리기라도 하는 건 어떨까?" 생각했습니다. 실제로 영업 둘 째날, 셋 째날에는 Dio MVP를 무료 서비스로 소개했습니다. 그러나 Dio MVP를 무료 서비스로 배포하려면 Dio MVP의 주요 기능인 결제 기능을 제외해야 했습니다. 서비스를 무료로 배포해 당장의 수익을 포기하면 서비스에 투자할 수 있는 리소스도 적어지니까요. 특히 결제와 같은 기능은 상시로 안정성 체크와 에러 대응이 필요한 기능으로 유지관리에 들어가는 리소스가 큰 기능이죠. 그러나 결제기능을 제외하고 나니 "결제기능이 없는 Dio MVP가 충분히 혁신적인 솔루션을 제공하고 있는가"에 스스로도 의문이 생겼습니다. 결국 두 번째와 세 번째 영업에서도 파트너 스튜디오를 찾지는 못했습니다.

필요한 리소스가 크지 않은 흥미로운 기능이나 콘텐츠로 먼저 유저를 확보하는 방안은 어땠을까 생각해봅니다. 혁신적인 기능이라해도 기꺼이 써줄 유저가 없다면 제품은 지속될 수 없지만, 유저가 일단 확보되었다면 아직 제품을 확장해볼 여지가 더 있었을테니까요. 특히 위에서 적었던 내용과 같이, 이미 확보된 유저들이 제품의 또 하나의 셀링포인트가 될 수도 있었겠죠.

"사람을 모으는 것이 먼저일까, 혁신적인 기능이 먼저일까"라는 우문愚問에 한 가지 답은 없겠습니다. 사실 "커뮤니티"든 "콘텐츠"든 제품에 구현된 것은 모두 기능이니까요. 오히려 중요한 것은 모든 기능을 설계할 때는 이 기능을 유지 및 관리하는데 필요한 리소스를 공급해 줄 유저를 필요한 시간 내에 확보할 수 있는지를 검토해야 한다는 것이겠죠. IT 제품의 기능 개발에 리소스를 기꺼이 투자하기 전에, 먼저 기능을 사용할 준비가 된 유저가 충분한지를 면밀히 확인하는 작업이, 혹은 잠재 고객들이 정말로 원하는 기능이 무엇인지 살펴보는 작업이 왜 그렇게 중요한지 경험을 통해 알게 되었습니다.

글을 마치며

처음부터 "1인 창업, 9개월간의 MVP 기획 및 개발"이라는 터무니 없는 계획을 세웠던 것은 아닙니다. 너무 많은 리소스를 투자하기 전에, 빠르게 MVP 모델을 구축하고 제품을 검증했어야 했습니다. 그러나 사업은 예상치 못한 일의 연속이었습니다.

가장 큰 시련이라면, 팀 프로젝트를 개인 프로젝트로 전환하기로 결정했던 때였습니다. 백엔드 팀원이 부재한 상황에서, 프로젝트를 그만둬야 하나 고민도 했지만, 제품이 아닌 다른 이유로 프로젝트를 그만두고 싶지는 않았습니다. Node.js로 백엔드를 새로 구축하기로 결정했고, 기존 Kotlin으로 작성된 코드는 따로 인계받지 않고 서버를 새로 구축했습니다. 그러다보니 제품을 검증하기도 전에 이미 너무 많은 리소스를 소모해버린 결과를 낳았습니다. (만약 더 빠르게 제품을 검증하는 과정을 거쳤다면, 아직 Dio를 수정해볼 리소스가 남아있었을지도 모르겠습니다.)

마지막 영업을 마치고 집으로 돌아오면서, 제가 제품기획 자체에 얼마나 무지했는지를 실감하며 IT 제품 기획에 관련된 서적 <인스파이어드>를 샀습니다. "솔루션이 아니라 문제와 사랑에 빠지라"는 이야기를 보았습니다. 뒤늦게 돌이켜보면 제가 해결하고 싶었는 문제는 "댄서씬에는 왜 큰 자본이 흘러들어오지 못할까"하는 문제였습니다. 사람이 모이면 돈이 된다고 생각했고, 우선 확실한 기능을 이미 사람이 모인 공간에 제공해 사람을 모아보자는 것이 저의 주요한 생각이었습니다. 그래서 Dio MVP를 개발했고요.

그러나,

• "댄스 스튜디오"라는 시장에 IT 제품에 대한 수요가 확실한지,
• Dio MVP가 충분히 혁신적인 기능을 갖고 있는지,
• 내가 설정한 문제를 해결하기에 적합한, 또 지속가능한 솔루션은 무엇인지

에 대한 고려가 부족했습니다.

Dio MVP가 파트너사를 찾지 못했던 것은 결국 고객에 대한 이해가 부족했던 탓이라고 생각합니다. 개발자나 기획자로 살아가면서, 우리는 스스로가 어떤 주제에 관심이 있다고 쉽게 생각하지만, 정말 고객의 문제를 파악하는 것은 생각만큼 쉽지 않다는 것을 새삼 느낍니다.

Dio는 잠정 중단되었지만, 중간에 포기하지 않고 영업 단계까지 프로젝트를 끌고온 덕분에 다음 단계에 대해 고민해볼 수 있게 되었습니다. (무작정 찾아간 댄스 스튜디오들에서 문전박대 당하지 않고, 영업을 할 수 있었던 것도 구체적인 모습의 제품이 있었던 덕분이라고 생각합니다.)

이직을 준비하며 제가 하고 있는 다음 단계의 고민들은 다음과 같습니다.

• "적은 리소스로 많은 유저를 모을 수 있는 MVP 모델은 구체적으로 어떤 모델이 있을까?"
• "높은 수준의 꾸준한 관리가 필요없지만, 고객이 기꺼이 비용을 지불할 서비스는 없을까?"

모든 것들이 그렇겠지만, IT 프로덕트는 단순한 영감이나 아이디어만으로 성공할 수 없다는 당연한 사실을 실감합니다. "고객에 대한 충분한 이해가 있기 전에, 섣불리 코드를 작성하지 않겠다"는 개발자스럽지 않은 다짐을 해봅니다. Dio 프로젝트는 잠정 중단했지만, 앞으로 계속해서 IT 제품을 개발해나가는데 있어서 Dio MVP 제작 경험은 중요한 판단지표로 활용될 것입니다. 새로운 제품팀이든 사이드프로젝트이든 Dio를 통해 얻은 인사이트를 바탕으로 지속가능한 IT 제품을 만드는데 앞으로도 꾸준히 기여할 수 있다면 좋겠습니다.

긴 글 읽어주셔서 감사드립니다.