반응형 웹으로 된 공연 서포터즈 플랫폼 개발 시 기획 프로세스

과거 자체 서비스였던 공연 서포터즈 플랫폼을 개발할 때 기획 했던 내용들을 정리해 보겠습니다. 서포터즈 플랫폼은 스마트폰과 PC 모두에서 이용할 수 있게 반응형 웹으로 개발했습니다. 그리고 커머스와 커뮤니티가 결합된 형태였습니다. 커머스 관점에서는 티켓 쇼핑몰과 클라우드 펀딩의 결합형 쇼핑몰이었습니다.

 

 

상황별 기획 차이 

 

내가 투자해 직업 앱/웹 서비스를 개발해서 운영할 때와 회사의 직원으로 개발하고 운영할 때, 또는 외주 개발사의 기획자로 기획할 때는 전혀 다른 기획을 하게 됩니다.

 

기획자로서 처한 포지션이 다르기 때문입니다. 각 상황의 기획자는 그 기획자의 관리자로부터 부여받는 역할과 책임이 매우 다릅니다.

 

내 앱/웹을 개발해서 운영할 때는 개발 비용도 내가 대고, 운영도 내가 해야 합니다. 모든 책임을 져야 합니다. 그러나 회사의 직원으로 앱/웹 서비스를 기획할 때는 우선 컨펌(결제) 가능성을 생각하지 않을 수 없습니다.

 

그러므로 내 서비스를 개발/운영할 때, 회사 직원으로 기획을 때 1차적으로 기획하는 내용은 사업성과 관련된 부분입니다. 여기에 추가해 결제(컨펌)를 하는 임원 또는 대표의 취향을 반영하여 기획을 합니다. 내 앱/웹의 경우 내 취향이 반영되게 됩니다.

 

사업성이 있다고 판단되고 취향에 적합한 앱 또는 웹 분야가 결정되면 개발을 위한 기획이 진행됩니다.

 

지금부터가 이 글에서 할 기획과 관련한 이야기가 진행되게 됩니다.

 

그리고 먼저 언급된 내 앱/웹 서비스 기획, 회사 직원으로 온라인 서비스를 기획하는 경우는 지금까지의 과정의 영향을 받게 됩니다.

 

물론 앱/웹을 외주로 개발하는 경우 앱/웹 경쟁 전략과 핵심 자산 등 사내 보안의 문제로 외부 기획자에게 제공할 문서를 따로 정리합니다. 이 문서는 앱/웹과 관련 너무 많은 내용을 담고 있어서는 안 되지만, 개발 앱/웹을 이해할 수 없을 정도로 모호해도 안됩니다.

 

흔히 외주 기획자에게 전달되는 문서는 요구 사항의 형태입니다. 그리고 이 요구 사항을 통해 개발할 앱/웹의 모습을 구체화하고, 이에 따라 앱/웹 서비스 설계, 개발 계획 등을 수립하게 됩니다.

 

물론 외주 기획자에게 부여되는 역할도 해당 앱/웹 프로젝트팀의 상황에 따라 달라집니다. 

 

 

서포터즈 플랫폼 사업 기획 

 

공연 서포터즈 플랫폼은 제가 개발/운영 비용을 내는 내 비즈니스였습니다. 그러므로 모든 결정과 책임을 나 스스로 져야 하는 것이었습니다. 그러므로 앱/웹의 기획도 세밀해야 했습니다. 사용할 비용은 내 돈이고 또 그렇게 자금 여력도 많지 않았기 때문입니다.

 

앱/웹 기획의 시작은 시장 기회를 찾는 것이었습니다. 저는 당시 커지고 있던 국내 공연 열풍에 관심을 두었습니다.

 

짧은 기간 국내 공연 시장은 세계가 주목하는 거대 시장으로 빠르게 성장하였습니다. 브로드웨이 뮤지컬들이 국내에서 공연되기 시작했고, 오리지널 팀들의 내한도 많아졌습니다. 세계 4대 뮤지컬 같은 인기 공연은 물론 브로드웨이에 올려졌던 뮤지컬이면 수입되어 공연되기도 했습니다.

 

이제 어떤 사람들에게 대형 뮤지컬이 보았는지가 교양인의 스펙이 되기도 하였습니다. 이렇게 여러 이유로 라이선스 뮤지컬을 즐기는 사람들이 많아지면서 자연스럽게 국내에서 공연에 대한 관심이 커졌습니다.

 

국내 공연, 특히 창작 공연의 메카는 여전히 대학로였습니다. 그 당시 일부 자료로는 대형 뮤지컬을 제외한 중소 국내 공연 시장의 70% 이상을 대학로가 차지하고 있다는 내용을 나타내기도 하였습니다. 

 

이렇게 국내 공연(연극. 뮤지컬) 시장은 성장하고 있었지만, 중소 창작 공연의 경우 과거와 다르지 않은 어려움을 겪고 있는 것으로 조사되었습니다.

 

중소 창작 공연의 대부분은 여전히 상업적 이득과 거리가 먼, 국가 또는 지자체 지원으로 유지되고 있는 상황이 지속되었습니다.

 

공연 관람객도 양분되어 있었습니다. 20대~30대 공연 관람객은 대형 뮤지컬을 통해 입문한 사람들이 많았습니다. 그래서 이들에게는 공연이 유료라는 것은 당연한 것이었습니다. 그러나 40대 후반 이상 사람들에게는 공연은 무료로 보는 것이었습니다. 공연은 바 주는 것이며 관람료는 공연에 대한 대가가 아닌 자비로운 기부/후원이었습니다.        

 

20대~30대, 특히 여성 관객은 뮤지컬에서 중소 창작 공연으로 관심이 확장되고 있었습니다. 이에 따라 대학로는 제2의 호황이 되었습니다.

 

공연 서포터즈 플랫폼은 이러한 시장 상황에서 앱/웹 비즈니스 기획을 포착하여 기획된 것이었습니다.

 

그리고 이를 어떻게 수익화할 지에 대한 알고리즘도 고민했습니다. 이런 기획 고민이 적용된 앱/웹이 개발된 것입니다.

 

기존 티켓 판매 쇼핑몰과 같은 공연 티켓 판매 기능은 기본 탑재하였습니다. 그러나 이것만으로 인터파크티켓, 소셜커머스 및 공연 할인 쇼핑 사이트와 경쟁할 만한 특별한 가치가 없는 것이었습니다.

 

그래서 기존 공연 관련 앱/웹에는 없는 기능을 넣어야 했습니다. 이 기능은 성장하고 있었던 20대~30대 여성 공연 관객의 필요(니즈)를 바탕으로 설계하였습니다.

 

가장 큰 필요(니즈)는 정보였습니다. 중소 창작 공연의 경우 부족한 자금력으로 공연을 할 무대를 대관하는 것도 벅찬 상황이었습니다. 당연히 공연을 올리질 때 광고나 홍보는 어려웠습니다. 그래서 아무리 좋은 공연이라도 20대~30대 여성 공연 관객 알 수 없었습니다.

 

그래서 넣은 기능이 바로 커뮤니티 기능이었습니다. 1차로는 공연과 관객의 커뮤니티 기능을 넣었습니다. 그래서 서포터즈 플랫폼이라 불렀던 것입니다.

 

그리고 2차로 관객과 관객의 커뮤니티 기능을 계획하였습니다. 이는 개발 비용이나 운영 비용 때문에 1차 이후 투자 유치로 진행하는 것으로 계획하였습니다.   

 

공연 판매 상품은 기존 앱/웹들의 티켓 판매 외에 다양한 공연 관련 상품을 판매할 수 있게 했습니다. 이러한 다양한 공연 관련 상품은 다시 공연과 관객의 커뮤니티 기능을 강화하게 될 수 있도록 설계하였습니다. 그리고 다양한 공연 상품은 공연이 무대에 올라있지 않는 시기에도 공연이 관객을 관리할 수 있는 아이템이 되었습니다. 

 

이렇게 공연 서포터즈 플랫폼에는 성장하고 있고, 공연에 기꺼이 돈을 지불하려는 20대~30대 여성 공연 관객들의 필요(니즈)는 충족하면서 다양한 수익 모델을 붙일 수 있는 여건이 되었습니다. 특히 티켓 판매와 같은 바로 매출이 되는 분명한 것은 물론 서포터즈 상품이라는 추가적인 매출 상품도 가지고 있다는 점이 사업성에 긍정적 요인이었습니다.

 

그러나 여전히 대형 뮤지컬 시장에 비해 상대적으로 작은 중소 공연 시장은 앱/웹의 사업화에 문제였습니다. 이 시기 영화 티켓 가격은 중소 공연 관람 티켓 가격과 비슷해졌습니다. 그리고 영화 티켓 가격은 계속 오르고 있는 반면, 공연 티켓 가격은 할인 정책으로 인해 점점 낮아지고 있었습니다.

 

이런 상황에서 기대 매출은 작을 수밖에 없습니다. 이에 대한 사업적인 대응이 필요했습니다.

 

그래서 이후 기획된 부분은, 바로 앱/웹을 개발하기 위한 것이 아닌, 앱/웹을 활성화할 수 있고 가치를 높일 수 있는 서비스 기획이었습니다.

 

 

서포터즈 플랫폼 서비스 기획

 

사업 진행할 앱/웹 비즈니스 모델을 정했고, 수익 모델도 잡았습니다. 문제는 여전히 중소 공연 시장의 구조적 내부 문제로 기대 수익이 낮을 수밖에 없다는 문제가 남았습니다. 

      

그래서 고민한 것이 어떻게 개발할 앱/웹 가치를 높일 수 있느냐에 대한 것입니다.

 

이 부분은 중소 공연 서포터즈 플랫폼에서의 사용자의 수익성 있는 경험이라는 서비스 기획과 연결된 고민이었습니다.

 

그래서 중소 창작 공연이라는 정보 한계를 극복하기 위한 서비스 알고리즘이 필요했습니다. 사용자는 노력 없이 단지 공연 서포터즈 플랫폼만 이용하면 적절한 공연을 매칭해 주고, 해당 공연 관련 다양한 정보를 제공해 줄 수 있는 서비스 알고리즘을 의미했습니다. 

 

이 알고리즘을 위해 준비한 것이 중소 공연 관련 데이터에 대한 부분과 공연 관객들의 공연에 대한 인식과 관련한 것이었습니다. 이를 위해 다양한 자료를 수집하였습니다.

 

그리고 이 자료를 바탕으로 공연 관련 데이터 구조와 국내 공연 관객들이 관람 선호에 대한 가설을 수립하였습니다.

 

이 공연 데이터 구조와 관객의 관람 선호 반응 체계는 개인화 추천 알고리즘으로 발전하였습니다. 또한 앱/웹 개발 시 어떤 데이터를 확보하여 어떤 방식으로 분석해야 하는지에 대한 설계도 하였습니다.

 

이러한 설계는 다시 개인화 추천에서는 행동 벡터 알고리즘으로 발전하였습니다.

 

그리고 이는 다시 앱/웹 개발에 필요한 화면 구성과 UI, 기능에 대한 세부 정리로 발전하게 됩니다. 추천 버튼, 저장, 구매, 좋아요, 댓글의 의미를 분석할 수 있게 앱/웹 개발 시 적용하였습니다. 여러 공연이 노출되고, 사용자가 공연 정보를 보거나 그냥 넘어가는 등의 행동의 의미도 수치화 발판을 마련하였습니다. 

 

이는 향후 앱/웹 개발 시 데이터 구성에 대한 것이기도 합니다. 앱/웹 서비스 기획은 본질적으로 데이터와 정보에 기반하기에 앱/웹 데이터 구조와 관리에 영향을 줄 수밖에 없습니다.

 

  

서포터즈 플랫폼 앱/웹 기획

 

개발할 준비가 완벽하게 되었다고 해도 고민이 될 수밖에 없는 것은 비용 때문입니다.

 

직접 개발자를 고용하여 개발할 경우 매출이 없는 기간에도 인건비는 계속 나가게 됩니다. 회사를 운영할 수 있는 수준의 매출이 나오는 그때까지 회사가 버틸 수 있을 수 있을지 불확실합니다.

 

그렇다고 외주 개발을 주는 것도 문제입니다. 개발 비용이 작은 경우 지속적이고 반복적인 개발 미팅이 어렵습니다. 이에 따라 개발 관리가 쉽지 않습니다. 또한 앱/웹 개발 역량을 키울 수 없습니다. 때로는 기업 정보가 외부로 유출될 수 있습니다.

 

여러 문제를 감안하여 앱/웹 개발 스토리보드를 작성해야 한다는 점은 외부 기획과는 다른 점입니다.

 

스토리보드는 외부의 외주 개발사에 제공할 때와 내부 개발자에게 제공할 때 다르게 작성합니다. 저의 경우 외주 개발에 1차 실패한 후 개발자를 고용하여 작업하였습니다. 이때 제공한 스토리보드는 달랐습니다.

 

개발 비용이 크던 작던 외주 개발사를 관리하는 것은 상당히 어려운 일입니다. 물론 내부 개발자 관리도 그에 못지않습니다.

 

여러 번 개발자와 팀을 꾸렸다가 해체된 이유도 이런 관리의 어려움 때문입니다. 물론 연봉을 많이 줄 수 있거나, 기업이 충분히 빠르게 성장하고 있다면 이런 어려움은 줄어들 수도 있습니다. 그럼에도 항상 리스크는 존재합니다.

 

이 시기 만났던 개발자 출신 스타트업 대표님과 개발자 관리가 어렵다고 말했습니다. 3개월이 지나면, 1개월마다 개발자는 이직을 고민한다고 말해 주셨습니다.

 

지금 생각해 보면 이 문제로 개발자 연봉이 급속히 올랐던 게 아닌가 생각 듭니다. 이는 다시 기업의 부담으로 작용하여 경영을 악화시킵니다.

 

개발자 연봉이 오르면 개발자 평균 수준이 올라갈 것 같지만 실제 현상은 반대로 갔습니다. 개발자 연봉이 올라갈수록 개발자들의 평균 실력은 낮아졌습니다. 연봉만 보고 유입되는 평균 이하 개발자가 너무 많아졌기 때문입니다.

 

그리고 이는 다시 저와 같은 기획자 설립 스타트업들이 개발자를 구하기 더 어려워지는 이유가 되기도 했습니다.

 

자체 개발로 선회한 이후 연봉은 다소 낮은 대신 지분 계약을 했습니다. 상당한 지분을 통해 책임 개발을 유도하였습니다.

 

그리고 디자인은 외주로 최소화했고, 최종적으로는 디자인은 기획적으로 풀기로 했습니다. 저는 공연 서포터즈 플랫폼이 가지고 있는 공연 자체가 모여 앱/웹의 디자인이 되도록 기획하였습니다.

 

그리고 개발자 확보의 한계 상 스마트폰 앱보다는 반응형 웹으로 먼저 진행하기로 했습니다. 확보한 개발자가 웹 개발자인 이유였습니다. 그리고 추가 개발자 확보가 자금 여력상 어려웠습니다.

 

반응형 웹으로 스마트폰에서 사용이 가능한 서비스를 구현했습니다. 그리고 제휴 공연사에는 반응형 관리자를 제공하여 PC 뿐 아니라 스마트폰에서도 서포터즈 및 상품 관리를 할 수 있게 지원하였습니다.

 

이렇게 개발자와 저 2인은 공연 서포터즈 플랫폼을 개발하여 서비스하게 되었습니다.

 

 

기획 자료 정리와 개발 기획 작업 흐름

 

외주 개발사나 내부 개발자에게는 스토리보드를 제공하였습니다. 그러나 스토리보드 자체 작업보다, 스토리보드를 작업하기 위한 기획 자료를 만들고 정리하는 시간이 더 들어갔습니다.

 

일단 공연 서포터즈 플랫폼 서비스가 어떻게 구성되는지 설계했습니다. 그리고 서비스를 구성하는 데이터 구조와 흐름, 관계를 설계합니다.

 

공연 서포트즈 서비스가 수익성이 있기 위한 가상의 사용자 이용 프로세스를 정리합니다. 이때  발생되는 데이터를 통해 수익성 높은 경험을 형성할 수 있는 UI를 기획합니다.

 

이러한 정리는 공연 서포터즈 플랫폼 사용자 가설을 기반으로 합니다.

 

그리고 이러한 가설을 바탕으로 세부적인 기능과 개발 화면 구조, 플랫폼의 구조를 각각 설계합니다.

 

재밌는 사실을 맨 처음 기획한 것이 앱/웹에서 사용자가 이용하는 맨 마지막 화면이었다는 점입니다.

 

공연 정보 페이지를 가장 먼저 기획하고, 이 페이지들을 모아서 카테고리를 형성합니다. 그리고 이 카테고리들이 연결되는 메인 페이지가 기획되는 순서입니다. 각종 게시판은 이 공연 정보 페이지를 활성하기 위한 지원 페이지/카테고리입니다.     

이는 앱/웹 이용과 개발 또는 수익성을 바라보는 수익성 차이라 생각합니다. 그리고 화면과 개발을 바라보는 차이라 생각합니다. 제가 내부 서비스 개발과 외주 개발에 기획자로 참여해 본 결과 그러합니다.

 

이러한 차이를 적용하여 수익화하는 것이 바로 개인화 알고리즘입니다. 그리고 이 개인의 차이를 파악하기 위하여 공연 서포터즈 플랫폼 기획에서 노력하였습니다.