서비스는 그냥 만들어지지 않는다
BP음악산업 아카데미 7주 차 리뷰 2
음악산업 아카데미에서의 7주 차 마지막 강의는 류형규 강사님의 <서비스 기획과 과정> 수업이었다. 지난 6주 차 강의에서 김민준 강사님의 강의 내용과 오버랩되는 부분이 있었으나, 해당 강의가 조금 더 마인드셋, 스킬 셋에 관한 내용이었다면, 이번 강의는 사례를 중심으로 풀어가는 형식이었다. 많은 도움이 되는 강의였으니, 일독을 권합니다.
나의 서비스와 경험
먼저 류형규 강사님의 소개와 함께 개인 경험들을 공유하는 것으로 강의가 시작되었다.
case #1 - maniadb.com
음악을 좋아하거나, 찾아본 경험이 있다면 maniadb를 알고 있거나, 적어도 한번쯤은 방문해보았을 것이다. maniadb는 아티스트와 앨범, 리뷰 등 다양한 데이터와 컨텐츠를 제공하는 서비스이다. 강의에서는 '온라인 음악 아카이브'라는 말로 설명을 해주셨다. 약 20만 명 이상의 아티스트 정보, 약 40만 장의 앨범 그리고 400만 곡이 넘는 트랙에 대한 정보가 아카이빙 되어 있다. 처음에는 개인 웹사이트로 시작했다가 2005년부터는 현재의 maniadb라는 이름으로 서비스가 운영되고 있다. 오픈 API를 제공하기 때문에 상업적인 용도가 아니라면, maniadb의 API를 이용하여 다양한 데이터를 얻을 수 있다.
서비스를 기획하고 개발하고 또 운영하는데 중요한 부분 중 하나는 그 이유를 찾는 일일 것이다. maniadb의 경우에는 시작은 개인의 덕질(?)에서 출발했지만, 음악 시장, 특히 우리 음악에 대해서 제대로 정리되어있는 데이터베이스가 없었던 것이 가장 큰 서비스 운영의 이유였다. 더불어 오픈 API를 제공함으로써, 다양한 음악 서비스들이 음악 데이터베이스라는 첫 번째 허들을 순조롭게 통과할 수 있다면 더 멋진 실험을 할 수 있을 것이라는 생각이 덧붙여졌다. 국내 시장을 목표로 한 음악 서비스에 대한 생각이 있다면, maniadb를 잘 활용해보는 것이 어떨까.
case #2 - Streaming Radio
강사님이 두 번째로 개발하게 된 서비스는 24hz라는 음악 스트리밍 라디오였다. 현재의 판도라, 스포티파이나 국내의 딩가 라디오의 형태와 유사하다고 보면 된다. NC소프트에서 해당 프로젝트를 진행하게 되었는데, 서비스 기획의 이유는 다음과 같다.
- 게이머들의 경우, 게임을 더욱 즐기기 위해 게임 BGM 대신, '다른 음악'을 듣고 있음.
- 게임 플랫폼으로서, 모바일 환경이 중요해지고 있고 게임에 집중을 방해하지 않는 음악이 주는 모바일 환경에서의 즐거움이 커지고 있음.
- 디지털 음악시장의 경우 매년 20% 이상 성장하고 있으며, 잠재시장 규모가 크기 때문에 투자가치가 있음.
이러한 관찰과 업계 동향, 그리고 숫자를 바탕으로 음악 스트리밍 라디오를 개발하게 되었고 서비스가 추구하는 목표는 다음과 같았다.
- No Limit (돈을 낼 필요도, 로그인할 필요도 없다.)
- No Selection (선택하는 것이 아니라, 채널에 따라 선곡된 음악을 듣는다.)
- Simply Listen (설치할 필요 없이 듣는다.)
- Anywhere Listen (PC, 모바일 그리고 게임 내 등 모든 환경에서 듣는다.)
24hz는 무료, 유료 버전의 스트리밍 가격정책을 가지고 있었다. 더해서 개인화된 음악 추천, 소셜, 게임 내 주크박스 등의 기능을 제공했다. 지금 생각해보면 2009년에 벌써 그런 기능들을 구축했나 싶지만, 24hz는 아쉽게도 서비스를 종료했다. 그 이유는 먼저 NC소프트가 기본적으로 게임회사였고 당시 디아블로 3과 리그 오브 레전드의 등장으로 업계 내의 위기감이 고조되고 있었다. 그래서 회사와 내부 인력들이 '더 잘할 수 있는 것'에 집중하자는 의사결정을 하게 되었고, 가파르지는 않지만 성장세에 있던 24hz는 아쉽지만 서비스를 종료하게 되었다.
Case #3 - Live Club
세 번째 사례는 라이브클럽 운영이었다. 가로수길에서 'Jass'라는 재즈 클럽을 운영했었는데 현재는 사라졌다. 그 이유를 말씀해주시길, 가로수길의 상권이 경리단 등으로 이동했지만 다양한 고급 브랜드들이 가로수에 매장을 차리면서 임대료는 계속 상승한 것이 첫 번째 이슈. 또한 '목숨 걸고' 운영하지 않았다는 이유가 있었다. 고객에 대해서도 관찰을 해보니, 대부분의 고객들이 음악을 들으러 클럽에 오는 것이 아니라 술을 마시고 2차 혹은 3차로 들리는 곳이 되어있었고, 그렇기 때문에 음악이 시끄러워 대화가 어렵다는 사람들도 나타나기 시작했다고 한다. 마지막으로는 뮤지션들의 고충이 있었다. 장비나 무대시설이 좋지 않았고 사운드나 모니터 시설들을 담당해 줄 엔지니어가 없었기 때문에 그리 즐겁지 못한 연주가 이어졌다고 한다. 결국, 'Jass'는 문을 닫았다.
사진 = 커먼 키친 페이스북 페이지첫 번째 라이브 클럽 운영과 운영 실패를 통해 얻은 교훈을 가지고, 강사님은 새로운 클럽을 열었다. 먼저 상권과 고정 고객의 필요성을 절감하고 유동인구는 많지만 상권이 아직 완전히 형성되지 않은 판교에 그 터를 잡았다. 또한 공연만으로 돈이 되지 않았기 때문에 음식이나 주류 등을 함께 판매하여 다양한 수익원을 마련했다. 음향 시설 또한 최상의 장비로 마련하고 사운드 엔지니어 또한 운영진에 두어 뮤지션들이 즐거운 공연을 할 수 있도록 했다. 그렇게 만들어진 것이 현재의 '커먼 키친'이다. 판교에 있는 회사에 다니거나, 놀러 갈 일이 있으신 분들은 한 번 방문해 보시길.
서비스를 만드는 과정 이해하기
서비스를 기획하거나 제품을 만드는 것에 대해서는 정해진 답이 없다. 많은 유니콘 (1조 이상의 기업가치를 가진 비상장 기업) 들이 '블랙 스완'의 딜레마와 잘 맞아떨어진다. 그럼에도 서비스를 만드는 과정에서 보편적으로 고려해야 할 것들은 있다. 그리고 지난 주의 강의는 이 '정도'에 초점을 맞추었다. 다시 말하지만, 성공하는 서비스를 만드는 정답 같은 것은 없다.
서비스를 만든다는 것은 무엇인가?
서비스를 만드는 이유는 여러 가지가 있다. 하지만 그중에서도 꼭 생각해보아야 할 부분이 있다.
먼저, 쓸 사람이 존재하는 서비스를 만들어야 한다는 것.
만드는 사람이 생각했을 때 아무리 좋은 서비스라 해도, 쓸 사람이 없다면 더 이상 좋은 서비스가 아니게 된다. 내가 하고 싶은 것을 하는 게 아니라, 사람들이 원하는 것을 만들어야 한다는 이야기다. 사람들이 필요로 하거나 (문제점이나 불편함을 해결하는 것) 사람들을 더 즐겁게 해줄 수 있는(게임 등 엔터테인먼트적 요소가 있는 것) 서비스가 가치가 있다. 또한 스스로 고객이 될 수 없다면, 서비스 개발을 포기하는 것이 낫다. "Eating our own dogfood"라는 말이 있다. 최고의 개밥 요리사는 개밥을 직접 먹는다.
내가 더 잘 만들 수 있는 것을 만드는 것
두 번째로 생각해보아야 할 것은 '왜 이 서비스를 굳이 내가 만들어야 하는가?'에 대한 부분이다. 많은 사람들이 서비스를 기획하거나 만든다. 과연 고객이 원하는 것을 내가 더 잘 해결할 수 있는가? 무엇이 다른 사람들 그리고 팀들보다 왜 내가, 혹은 우리 팀이 이 서비스를 잘 만들 수 있게 하는가? 에 대해 진지하게 고민해 볼 필요가 있다. 역량이나 배경 그리고 열정에 엣지가 없다면, 다른 사람들이 같은 것을 만들었을 때, 더 잘 만들거나 운영할 수 있다는 확신이 없어질 것이고, 이는 당연히 나보다 다른 사람이 더 잘만들 무언가를 내가 하고 있다는 말이기도 하다.
만들어서 얻을 수 있는 이익이 무엇일까?
무언가를 만드는 이유는 비단, 좋아서만은 아닐 것이다. 대부분의 경우에 서비스를 만든다는 것을 업으로 하고 있다면 해당 서비스를 통해서 고객가치를 전달하고 그 반대급부로 경제적인 보상이나 가격을 받아야 함을 의미한다. 자연스레 서비스를 통해 전달하는 가치들이 '가격'에 상응하는 것이어야 할 테고 그렇지 않다면 해당 서비스는 지속 가능한 구조가 되지 못할 것이다. 하고 싶은 것? 다 좋다. 하지만 결국 이것도 수익사업이다. 철저한 비즈니스 모델링과 숫자에 대한 감이 없다면 서비스의 의미는 퇴색되고 만다.
만든 것을 전량 회수할 때까지 책임을 지는 것
고객, 사용자는 서비스 기획, 개발자를 먹어 살리는 근간이다. 설사 사업성이 없어서 서비스를 종료하더라도 고객에게 피해를 주면 안 된다. 책임감을 가지라는 말이다. 비단 법적인 책임을 말하려는 것이 아니라 도의적인 책임까지 서비스를 만드는 사람은 느끼고 있어야 한다. 서비스를 자신이 만든 아이처럼 생각한다면, 사용자들은 그 아이를 먹여 살리는 사람들이다.
'보편적인' 서비스의 탄생 과정
위에서 말한 것처럼, 좋은 서비스나 서비스가 만들어지는 과정에 대해 정답은 없다. 하지만 보편적인 과정들은 존재한다. 강의에서는 이 보편적인 과정에 대해 하나하나 다루어보고, 서비스를 기획하는 사람의 입장에서 고려해야 할 부분들을 다루었다. (업계에서도 서비스를 만들어가는 과정이나 문서의 이름들이 여러 가지 이름을 가지고 있다. 아래의 내용에서는 강의 자료에서 사용된 단어를 그대로 사용한다.)
※ PRD에 대해서
PRD(Product Requirement Document)는 제품/서비스의 내용과 목적, 기능 등을 명확하게 설명하여 해당 제품/서비스가 만드는 구성원들에게 업무 수행에 대한 정보를 제공하기 위한 문서이다. 더불어 상위 의사결정자가 제품/서비스에 대해 더 잘 이해하고 의사결정을 내리기 위한 목적도 가지고 있다.
서비스의 PRD는 다음과 같은 내용으로 구성된다.
- 서비스 정의 및 목표
- 이것을 왜 해야 하는가?
- 서비스 시나리오
- 서비스에 필요한 요구사항 (기술, 제휴 등)
- 로드맵 및 일정
- 평가 지표 (정량적 목표로서 서비스를 지속할 것인가에 대한 첫 번째 검증 지표가 된다.)
- 팀 구성과 서로의 역할 및 책임 (Role & Responsibility)
0. Ideation
아이디어는 제약이 없다
세상 모든 아이디어는 모두 가치를 가지고 있다. 쓰레기 아이디어는 없다. 팀 내에서 아이디어가 나온다면, 그 아이디어를 구체화할 수 있도록 도와주는 것이 다른 팀원들의 역할이다. 낡은 아이디어는 어떤가. 에버노트가 나왔을 때, LINE이 국내에서 카카오톡에 밀렸을 때를 생각해보면 쉽다. 어떤 아이디어든 새로운 것은 없었지만, 어떻게 그리고 언제 실행하느냐에 따라 성공과 실패가 달릴 뿐이다. 그러니, 낡은 아이디어도 없는 셈이다.
아이디어가 있는 곳에 가라
아이디어가 발현되는 방법은 다양하다. 관찰로부터, 개인적인 경험으로부터, 때로는 툭 던진 말에서 시작되기도 한다. 중요한 것은 아이디어를 검증해야 한다는 것이다. 아이디어에 포함되어 있는 '고객'이 어떻게 생각하는지가 중요하다. 나의 관찰이나 경험에서 아이디어는 시작되지만, 그것을 검증하려면 고객을 만나야 한다.
그렇다면, 좋은 아이디어는 무엇인가?
좋은 아이디어는 3가지 요소를 갖추어야 한다.
- Understandable (이해할 수 있는가?)
- Acceptable (동의할 수 있는가?)
- Executable (실현 가능한가?)
고객이 이해할 수 있어야 하고, 동의할 수 있어야 하고 또한 기술적, 사회적, 경제적 측면으로 보았을 때 실현 가능해야 한다. 이 셋 중 하나라도 충족하지 않으면 대부분의 경우에는 좋은 아이디어가 아닐 것이다.
모든 아이디어는 구체화해볼 가치와 구체화될 권리를 가지고 있다. 솔직하게 요즘 새로이 나오는 서비스들 또한 세상에 없던 무언가는 아니다. 더 고객을 잘 이해하고, 더 실행을 잘하는 팀이 만드는 서비스와 제품이 시장에서 성공한다.
1. Conception / Mockup
아이디어를 구체화하자
아이디어가 떠올랐다면 이제는 아이디어를 구체화하는 과정이 필요하다. 무엇을 할 것인지? 누가 고객이고 수혜자인지? 그것을 만든다면 우리에게는 무엇이 좋은지? 등의 이야기를 구체화해야 한다. 엄청난 수준의 시장조사는 아니더라도 서비스를 만들어가는 근거를 찾는 과정은 필요하다.
핵심가치 탐구하기
우리 서비스가 전달할 수 있는 핵심가치는 무엇일까? 문제를 해결한다면, 정말 그 문제가 '진짜' 문제인 지부터, 해결하는 과정에서 진정으로 가치를 전달할 수 있는지까지에 대한 근거와 증명이 필요하다. 서비스의 핵심가치를 명확히 설명할 수 없다면, 이미 서비스로서의 가치를 잃는 것이나 마찬가지이다.
성공을 확신하는가?
성공을 확신할 수 있을까? 세상만사에 100%는 없다지만, 결국 리서치를 하거나 서비스 기획에 공을 들이는 이유는 '해당 서비스의 성공확률을 100%에 가깝게 만들어가자'이다. 공감이 갔던 부분은 나뿐만 아니라 팀원의 확신도 그만큼 중요하다는 것이다. 비전이 정확하게 공유되지 않은 상황 혹은 팀 전체가 확신을 하지 못할 때에는 그만큼의 고통이 따르고, 서비스도 모두가 생각하는 같은 방향으로 발전되지 못한다.
초기 단계에서는 서비스가 출시된 것이 아니기 때문에 팀원의 역량이 그 팀의 거의 전부다. 그렇기 때문에 서로 확고한 믿음과 같은 목표를 바라보고 서비스를 만들어가는 것이 중요하다. 팀원들은 배에 타던지, 타지 말던지 둘 중 하나를 선택해야만 한다. 적당히 발을 걸치고 있는 것은 없는 것보다 더 부정적인 결과를 초래하곤 한다.
2. Prototyping
Cross-Functional Team
초기에는 적은 인원의 팀이 좋다. 커뮤니케이션 비용도 줄어들 뿐 아니라, 각자 해야 할 역할이 명확해진다. GTD (Get Things Done). 능력보다는 비전이 공유가 된 팀이 좋다. 하기 싫은 일을 하는 것이 아니라, 능력이 부족하더라도 밤을 새우고 공부하고 또 보완하며 그 일을 끝까지 해나갈 수 있는 사람이 더 낫다는 것이다.
역할 분배 (PM, Designer, Engineer)
기획서는 누가 쓰는가? 비전은 누가 제시하는가?
2단계에서는 니 일 내 일이 없다. 그냥 팀원 모두가 같이 일을 하는 것이 중요하다. 잘할 수 있는 사람이 그 일을 맡아서 하면 되는 것이다.
프로토타이핑
대규모 투자를 유치하기 전, 점검을 목적으로 프로토타이핑을 주로 한다. 어떤 서비스의 경우에는 생략하는 경우도 있다. 이 단계에서 고민해보아야 할 부분은 '꼭 직접 개발을 해야 하나?'에 대한 부분이다. 다른 서비스를 인수하거나 솔루션을 사용하는 것도 대안이 될 수 있다.
100% PRD를 완성하기
100%가 충족되는 PRD를 완성하는 것이 2단계의 주요 목표 중 하나이다. 서비스의 KEY FEATURE (핵심 기능)에 대한 상세 기획, 서비스 환경 (PC/모바일 등)에 대해서도 정리가 되어야만 개발 인력과 개발 기간을 산정할 수 있는 근거를 만들 수 있다. 마지막으로 많은 과정들을 문서화하는 것이 중요하다. 경험상으로도 서비스를 만들어가면서 커뮤니케이션 때문에 생기는 비용이 너무나도 많았다. 미스커뮤니케이션을 막으려면, 어떠한 형태로든 약속된 문서를 만드는 것이 중요하다.
3. Product Development
개발 시작
이제 준비가 끝났다. 준비한 계획대로 서비스를 개발한다. 개발은 핵심기능에 초점을 맞추어야 한다.
우선순위를 생각해보자. (P = Priority)
P0 = 서비스의 존재 이유
P1 = 서비스의 차별성
P2 = 서비스의 부가기능
핵심에 집중하고, P2는 과감하게 버릴 수 있어야 한다.
우리 서비스의 P0는 정말 P0가 맞는가? 지속적으로 고민해야 하는 부분이다.
Timing? Quality?
개발이 진행됨에 따라서 기획자, 디자이너 그리고 개발자까지 일이 전달되며 진행이 된다. 이러한 과정에서도 특히 개발 과정의 경우에는 코드가 많아짐에 따라 여러 가지 부분에서 버그가 생기는 등 다양한 이슈때문에 일정이 밀릴 때가 많다. 그러니, 개발자의 일정을 믿지 마라. 더불어 팀에서 생각하는 서비스의 가치에 대한 비중도 생각해봐야 할 것이다. 출시 일정을 빡빡하게 잡는다면, 서비스의 퀄리티보다는 몇 가지 문제점이 생기더라도 개발 속도에 더 초점을 맞출 것이고, 서비스의 퀄리티를 생각한다면, 일정은 조금 유연하게 뒤로 밀릴 수도 있다.
커뮤니케이션, 또 커뮤니케이션
개인적으로는 서비스 기획과 개발 단계에서 가장 중요한 분야 중 하나라고 생각하는 커뮤니케이션. 자주 해야 한다. 그리고 용어와 방법을 통일시키는 것이 중요하다. 각자가 다른 배경을 가지고, 다른 분야의 공부를 하다가 한 팀으로 만났기 때문에 이런 과정이 꼭 필요하다. 일부는 약속을 한다손 치더라도 어쩔 수 없는 비용이 발생되기도 한다. 난상 토론은 좋다. 하지만 감정을 섞지는 말자. 커뮤니케이션을 할 때, 중요한 것은 무엇을 하든 기록을 남기고 약속에 따르는 것이다.
QA (Quality Assurance)
위에서 말한 일정이 밀리는 여러 이유 중 하나는 바로 개발 과정 중간중간, 테스트가 필요하기 때문이다. 대부분의 경우 크던 작던 버그들이 발견되고, 이 버그를 수정해야 할 시간이 새로이 발생한다. 그래서 버그 리포트나, 테스트 QA 등의 검수과정이 있는데 재미있는 것은 Fun QA라는 것이었다. NC 소프트에 재직할 당시에는 게임을 개발하는 회사이다 보니, 재미요소에 대한 검수도 개발 과정에 들어 갓더란다. 이런 것을 보면 게임 만드는 회사는 재미있는 요소가 있다는 생각도 들고, 새삼 대단하게 느껴진다.
(읽을만한 글: 게임 만드는 사람들이 돈을 많이 번 이유)
Data Analytics
데이터 분석은 서비스 개발과 운영의 필수 요소이다. 왜냐면, 이것을 통해 서비스를 운영하는 사람들은 그들의 정량적 목표가 달성되었는지, 그리고 그들에게 주어진 과제들이 무엇인지 확인할 수 있기 때문이다. 사용자들이 어떻게 서비스를 이용하는지 분석을 함으로써 서비스에서 부족한 부분을 찾을 수 있고 이는 소중한 피드백이 된다. 더불어 KPI (Key Performance Indicator)와 같은 목표에 대해서도 설정부터 분석까지의 과정을 이 데이터 분석을 통해 진행할 수 있다. (KPI가 필요 없다고 주장하는 사람들도 있다.)
필수요소이고 다양한 방면에서 서비스에 도움을 주는 데이터 분석은 양날의 검이기도 하다. 사용자의 개인정보를 필요치 않은 부분까지 요구하거나, 활용하게 된다면 이는 서비스의 신뢰도를 낮추고 더불어 법적인 이슈를 불러일으킬 수도 있다. 결국, 데이터 분석은 사용자에게 피해를 주지 않고, 서비스에 도움이 되는 부분까지, 최대한 활용하는 것이 현명하다.
경쟁사 동향
서비스를 만드는 사람들은 경쟁사 동향에 대해서 관심이 많다. 이미 개발 전부터 이런 질문들을 받는다. "네이버에서 똑같이 만들면 어떻게 할 건가요?" 이 질문에 대한 대답은 서비스마다 다르지만, 어쨌든 유사 서비스가 등장한다는 것은 사업성이 있다는 이야기이겠지만, 마냥 기분 좋은 일은 아니다. 다만 눈에 불을 켜고 경쟁사들을 찾아내고, 그들을 보며 걱정하는 것은 전혀 도움이 되지 않는다는 것을 말하고 싶다. 많이 양보해서 딱 5% 정도만 신경을 쓰고, 95%의 역량은 내 서비스를 잘하는 데에 쏟는 것이 좋다. 누군가 비슷하거나 동일한 서비스를 만든다고 해서, 지금 우리가 할 수 있는 것은 없으니까 말이다. 그러니까, 그냥 내 것을 잘 만드는데 최선을 다하는 것이 정답에 가까운 방법이다.
초기 서비스 운영 계획
서비스 개발을 하면서 초보 창업자나 프로젝트 팀이 놓치게 되는 것이 바로 초기 서비스 운영 계획이다. 개발은 다 완료가 되었는데, 사용자들에게 마케팅을 하지 않아서 혹은 영업을 통한 유입이 되지 않아서 휑한 서비스를 시장에 내놓는 경우도 있다. 이런 불상사를 막기 위해서는 개발 단계에서부터 초기 서비스를 어떻게 운영할 것인지에 대한 계획이 필요하다. 예를 들어 데이팅 어플리케이션 같은 경우에는 수십 명의 여성 사용자를 미리 섭외하여 어플리케이션 내에 정보를 게재해 남성 사용자들을 후킹 할 수 있는 유인을 만드는 그런 초기 계획이 필요할 것이다.
마케팅
마케팅은 사용자와의 커뮤니케이션이다. 서비스를 알리기도 해야 하고, 직접 유입시킬 수 있는 마케팅도 필요하다. "100 lovers are better than 10k users"라는 말이 있다. (비슷한 말인 것 같은데 정확히는 기억이 나지 않는다.) 모든 서비스에는 초기 10명, 100명의 열성 사용자들이 있었다. 그리고 이들을 기반으로 서비스는 퍼져나간다. 그렇기 때문에 100명의 열성 사용자가 10,000명의 보통 사용자보다 중요하다는 말을 생각해보면서, 그 100명을 어떻게 만들 것인가에 대해 생각해 볼 필요가 있다.
위와 같은 진정성 있는 고민과 더불어 편법에 대한 부분도 고려해볼 수 있다. S.E.O (Search Engine Optimization) 등을 고려할 때 유명한 동일 분야 서비스를 키워드나 연관 검색어로 등록해둠으로써 내 서비스를 알리기도 하고 또 게임이나 쇼핑몰과 제휴해서 앱 다운로드 어뷰징(?)을 진행할 수도 있다. (모바일 게임에서 앱을 다운로드하면 일정 포인트를 주는 식 등) 마케팅은 할 말이 너무나 많지만, 강의 내에서는 시간 관계상 크게 위의 몇 가지 포인트에 초점을 두었다.
4. Launch & Iteration
베타 그리고 정식 서비스
알파, 베타 서비스를 할까? 아니면, 바로 정식 서비스를 출시해서 유료화를 노려볼까? 서비스 런칭을 할 때 할 수 있는 고민들이다. 일반적으로 비즈니스 모델에 따라 혹은 개발 일정에 따라 의사결정을 하는 경우가 많다. 베타 서비스를 진행할 경우에는 추후 유료화를 진행할 때, 약간의 부담이 될 수도 있는 반면 초기에 부담 없이 사용자들을 모을 수 있다는 장점이 있다. 대부분의 서비스들이 오픈/클로즈드 베타 서비스를 통해 초기 사용자들을 모으고 소통한다. 지금 글을 쓰고 있는 브런치 또한, 아직은 베타 서비스 딱지가 붙여져 있다. 정식 서비스를 출시할 때에는 만반의 준비를 갖추어야 한다. 사용자에게 확실한 서비스 핵심가치를 전달할 수 있을 만큼의 완성도와 가치사슬을 잘 확인해보는 것이 중요하다. 돈을 내는 순간, 사용자들은 작은 것에 대해서도 많은 불만이 생긴다는 것을 잊지 말자.
서비스 런칭 그 이후,
서비스의 런칭은 시작일 뿐이다. 3번 단계에서 기획한 초기 마케팅과 운영을 통해서 실제 목표에 다가가야 한다. 또한 운영을 하며 발견된 여러 문제점과 사용자들의 피드백을 통해 계속해서 개선해 나가야 할 것이다. 결국 서비스 런칭 이후에는 매주 매주가 '다음'을 찾는 과정이다. 서비스가 올바른 방향으로 나아가고 있는지, 설정해 둔 KPI나 목표들에는 어떻게 다가가고 있는지 그리고 서비스가 문제점을 가지고 있다면 어떻게 해결할 수 있는지에 대한 고민의 연속이다. 이런 과정이 반복(Iteration)되고 서비스가 매주마다 올바른 방향으로 업데이트된다면 해당 서비스는 하나의 브랜드가 되고, 사용자들을 락 인하게 만든다.
휴먼 네트워크
이런 네트워크가 있다면 적어도 굶어죽진 않겠지...개발까지의 과정이 팀 내부에서 이루어지는 것이었다면, 마지막으로 휴먼 네트워크에 대해서도 생각해 볼 필요가 있다. 네트워크라는 것은 국내뿐 아니라 어디서든 빼놓을 수 없는 자산이 된다고 생각한다. 내 서비스와 이야기를 더 많은 사람들에게 알릴 수 있는 어쩌면 최고의 마케팅 전략이 될 수도 있고, 내부적으로 부족한 부분에 대해 도움을 받을 수도 있는 창구가 된다. '서비스만 좋으면 뭐든 다 될 거야!'라고 생각하는 것보다는 자신이 가진 네트워크를 충분히 활용하는 것이 여러모로 도움이 된다.
코멘트
서비스와 관련된 2시간 이내의 강연 중, 손에 꼽을 정도로 공감되는 내용이 많았다. 창업 컨설턴트랍시고 강의를 하는 사람들은 대부분 서비스를 직접 만들거나 운영해본 경험이 없다. VC들의 경우에는 관점이 조금 다른 내용의 강연이 많다. 이렇게 서비스를 만들고, 운영하는 분의 이야기를 듣는 것이 적어도 기획이나 개발 과정을 거쳐야 하는 사람 입장에서는 훨씬 좋다. 나는 몇 개의 서비스를 운영해보았고, 직접 기획부터 종료까지 책임졌던 미천하지만 소중한 경험도 있었기 때문에 강사님이 백그라운드로 깔고 이야기하는 부분에 대해서도 인지하고 있었다는 생각이 든다. 그래서 강의 내용을 거의 100% 이해할 수 있다는 점이 좋았다. 반대로, 백그라운드에 대한 공유가 없다면 얼마나 공감하고 이해할 수 있을지는 잘 모르겠다.
강의 전반에 대한 내용과 더불어 여러 가지 생각이 들었던 시간이었다. 특히 다시 한 번 마음에 새길 수 있는 부분이 있었다.
1) 새로운 것은 없고, 누가 어떻게 실행하는지가 중요하다는 것
2) 핵심기능에 대한 깊은 고민과 부가기능을 줄일 수 있는 결단이 필요하다는 것
3) 서비스는 목숨 걸고, 책임감 있게 운영해야 한다는 것
4) 배에 탈사람이 아니면, 같은 팀이 될 수 없다는 것
5) 일 잘하고 비전 공유가 덜 된 사람보다는 일을 잘 못하더라도 같은 곳을 바라볼 수 있는 사람이 필요하다는 것
매번 듣는 것인데도 실제로 실천하기는 정말 어렵다. 그래도 '실천으로 옮겨야지.' 하는 다짐을 한다. 대단한 서비스는 아니더라도, 킬링 컨텐츠가 있는, 단순하지만 강력한 서비스를 어서, 만들어내고 싶다. 빨리 실패하고, 더 좋은 것들을 만들어내고 싶다. 웃으며 진행된 강의를 돌아보며 과거의 비장했던 내 모습이 문득, 떠올랐다.
