brunch

You can make anything
by writing

C.S.Lewis

by coder Oct 09. 2023

새 상품 론칭후 배운 점 I

다음엔 정말 이렇게 안 하렵니다

같은 회사에 오래 있다 보니까, 항상 하던 일을 조금씩 바꿔서 했지 새로운 상품을 개발하는 과정에 참여할 기회가 많지 않았다. 그러다가 몇 달 동안 회사에서 새로운 상품을 개발하는 팀에 들어가게 되었고 드디어 지난주에 론칭하게 되었다. 나는 그저 한 명의 개발자에 불과하지만 여러 사람들의 노력과, 각자의 전문성을 살려서 상품을 개발하고 상품을 만드는 과정을 보니 7년 동안 회사에 다니면서 큰 앱을 관리하는 것과는 전혀 색다른 경험을 하게 되었다.

오늘은 시리즈의 첫 번째로 간단하게 실리콘밸리에서 새로운 상품을 론칭하는 과정과 내가 거기서 배운 것들에 대해서 간략히 써보려한다. 물론 실리콘밸리에서는 매일 색다른 상품들이 계속해서 나오고 있고, 우리가 내놓은 상품이 크고 소위, sexy한 상품은 아니지만, 대략 이런 과정을 거쳐서 상품이 나오는구나 정도로 이해하시고 재미있게 읽으시기를 바란다. 오늘은 짧게 가장 크게 배운 한 가지만 소개하고 나중에 시간이 되면 좀 더 자세한 이야기를 분야별로 하는 기회를 갖겠다.

새로운 상품을 개발하는 과정

사실은 새로운 상품을 개발하는 과정만 자세하게 설명하는데 책 한 권 정도가 필요하다. 새로운 상품을 구상하고 상품화가 되는 데는 여러 가지 요소가 필요하고 참여하는 사람들도 많다. 우선 가장 중요하다고 생각하는 몇 가지만 간단히 나열해 보았다.

Needs Analysis - 왜 필요한가

상품을 개발할 때는 "도대체 왜 이 상품이 필요한가?" 즉 "어떤 문제를 해결하려고 상품을 내놓는 것인가?"가중요하다. 이 질문에 "돈을 벌려고"는 상품의 필요성에 대한 대답을 한 것이 아니라 내가 왜 이 짓을 하고 있나에 대한 답이다. 가령, "의사들이 환자 진료를 하는데 보내는 시간보다 문서작성에 더 많은 시간을 들인다. 이 앱은 ㅇㅇ의 문제를 해결해서 의사가 환자를 진료하는데 더 시간을 쓰게 도울 것이다." 또는 "이 앱을 통해서 의사들의 문서작성 효율성을 높히고 남은 시간을 환자와 더 보낼 수 있다" 정도는 나와야 한다.

이번 상품을 개발하는 초입 단계에서 우리 회사 마케팅 부서에서는 의사들을 대상으로 인터뷰도 수차례 하고, 몇 천명의 의사들에게 이런 상품이 나오면 써볼 의향이 있냐고 묻기도 했다. 이런 필요성이 확립되어야 앱이 성공할 수 있다.

Target Audience - 누구를 위한 앱

누구를 위한 앱이냐는 정말 중요한 질문이다. 이 질문에 따라 앱의 개발시간, 투자 정도, 마케팅방법 등이 결정된다. 가령 미국에서 일하는 의사를 대상으로 하는 앱과 전 세계 의사들를 대상으로 하는 앱은 개발하는데 엄청난 차이가 난다. 그리고 사용자의 demographic, 즉 인구특성에 따라서 같은 앱이라도 구조, 디자인등이 크게 변한다.

우리의 경우 미국에서 현재 일하고 있는 의사들만을 겨냥하기로함으로써 상품의 구조를 단순화하고 조금 더 전문화시키는데 힘을 쓰기로 결정 했다. 사용자들의 숫자가 아무래도 제한되어 있으니 계발 비용은 적어지고 계발 속도도 빨라졌다.

Market Anlaysis - 경쟁자는 누구?

시장조사는 경쟁자만 보는 것은 아니다. 이 앱이 나올만한 시기가 적절한가? 도 들어갈 수 있고, 지금 고용상태나, 투자상태도 시장 조사에 들어갈 수 있다. 개발자로서 이런 것은 잘 염두에 두는 사항이 아님으로 여기서는 소개하는 정도로만 하겠다. 이러한 시장조사를 바탕으로 앱을 론칭하는 시점도 결정된다. 무조건 앱을 빨리 뽑는다고 다 이득은 아니다. 예로 의사들이 휴가를 많이 가는 12월에 앱을 론칭하면 아무래도 그 효과가 잘 나타나지 않는다. 그래서 시기적절한 론칭을 위해서도 역시 시장조사가 중요하다.

Regulations - 합법성

합법성은 요즘들어서 상당히 중요한 부분이 되었다. 예전에는 "대중이 원하면 법은 문제가 아니다." 이렇게 막 가는 분위기에서(Uber, AirBnb가 이런 경우) 이제는 "법이 허용하는 테두리 안에서 만들어보자"로 실리콘밸리 분위기가 바뀌었다. 우리도 앱이 지금 현재 법에 저촉되는 면은 없는지 변호사들과 오랫동안 상의를 했다. 앞으로 이런 부분이 앱을 개발하는데 계속해서 더욱더 중요한 관건이 될것이다. 법도 복잡해지고, 새로 생기고, 바뀌기도 하고, 비슷비슷한 앱도 많아지니 앱을 론칭하고 나서도 이런 문제가 끊임없이 제기될 수 있기 때문이다. 최소한 앱을 계발하는 초기 단계에서 법적인 문제를 꼼꼼히 짚어보는 것이 최선이다.

최고경영단의 참여

최고경영자들을 처음부터 포함하는 것이 무척 중요하다. 이 상품이 가능한지, 또 얼마나 돈이 드는지, 어느 팀이나 부서가 책임을 지고 만들어야 하는지, 언제까지 만들어야 하는지 등을 최고경영자들과 함께 결정한다. 결정을 하고 나서는 최소한 이 상품이 성공이다라고 말할 수 있으려면 어떤기능이 있고 어떤 이득이 회사에 돌아올 수 있는가를 정한다. 그리고 MVP(Minimum Viable Product) 최소한의 기능을 가진 상품을 정의한다. 이 결정이 최고경영단과 처음부터 이루어져야 나중에 기획을 끝내고 실제로 제품을 만드는 단계에서 큰 마찰 없이 일이 진행된다. 예를 들어:

이 상품은 최소한 ㅇㅇ를 사용자에게 제공해야 한다(핵심 기능)

이 상품은 10억 안에서 계발되어야 한다

이 상품은 앞으로 90일 안에 론칭되어야 한다

론칭 후 30일 안에 최소한 천 명의 사용자가 있어야 한다

론칭 후 6개월 안에 최소한 이 만 명의 사용자가 있어야 한다

론칭 후 1년 안에 최소한 ㅇㅇ를 얻는 효과가 있어야 한다

UX/UI, PM의 기획

UX/UI 디자이너들과 PM(Product Manager)들이 앞서서 세운 MVP에 따라서 앱의 구성을 진지하게 시작한다. 이때 엔지니어 쪽에서도 매니저쯤이 제품구성에 참여한다. 앱의 기능들을 중심으로 페이지마다의 구성도 대략 정해진다. 이때 UX 디자이너가 다시 사용자 인터뷰, 또는 다른 비슷한 앱들을 연구하고 우리의 목적에 맞게 구성을 한다. 우리가 이런 구성도를 Wireframe이라고 한다. 한마디로 앱을 종이에 그리면 이런 모양일 것이라고 하는 기본적인 구성 체계다. 아래의 예가 바로 wireframe의 예. 요즘에는 이런 것을 잘할 수 있도록 도와주는 앱이 많아서 꼭 전문가가 아니더라도 쉽게 만들 수 있다.

wireframe 예시 - https://www.figma.com/는 실리콘밸리에서 유행하는 툴

엔지니어 기획

구성된 상품을 보고 어떻게 만들지를 각각의 기능별로 쪼개서 컴포넌트로 정한다. MVP를 기준으로 이 상품이 꼭 해야 하는 주요 기능을 정의하고, 그 외에 다른 필요한 기능들도 이때 추가된다. 왜냐하면, 앤지니어가 아닌 사람들이 정의하는 기능과 앤지니어들이 정의하는 기능에 약간 차이가 나서 그럴 수 도 있고, 때로는 얼마나 이런 기능이 쉽게 만들어지느냐, 어렵냐에 따라 기능을 포기하기도 또 추가되기도 한다.

여기까지 오면 사실 상품의 1/3은 만들어진 거다. 여기까지 오기도 참 힘들다. 얼마나 간단한 앱이냐, 복잡한 앱이냐에 따라 여기까지 오는데 6개월에서 1년이 걸릴 수 도 있다. 요즘은 이런 상품 기획이 생각보다 빨리 이루어지는 추세다. 너무 질질 끌다가 경쟁사에서 먼저 상품을 내놓을 수 도 있고, 생각지도 않은 분야에서 상품이 나올 수 도 있기 때문이다. 법이 바뀌는 경우도 많다. 여기까지 올 때, 아주 가끔은 엔지니어를 한 번도 상품기획에 참여를 안 시키는 경우도 있다. 아무래도 기술적인 면이 들어가면 대화가 복잡해져서 그렇다. 그랬다가 나중에 엔지니어가 이건 불가능하다 그래서 상품을 포기해야 하는 경우도 있다.

이런 이유로 마케팅, 엔지니어, 최고 관리자들 그리고 핵심 사용자들이 전부 기획 초기에 참여해야 한다. 이제 본격적으로 내가 이번에 배운 점 또 아쉬운 점들을 소개하겠다.

너무 적은 사람들 의견수렴

우선 새로운 상품을 다 만들어 놓고 나서 이것저것 테스트를 하고 상품을 제한된 사람들에게 론칭하는 것을 베타론칭(Beta Launching)이라고 한다. 이때는 보통, 회사의 직원들 아니면 몇몇의 사용자들에게만 앱을 사용하게 하고 피드백을 받는다. 이 과정에서 여러 명의 사용자들이 문제점을 제기하면 문제를 인식하고 앱을 고치거나 바꾸기 시작한다. 이번 우리가 베타론칭을 하고 처음 power user 50명에게 피드백을 물었더니 문제점을 여럿 지적받았다. 그래서 바로 앱을 고치기 시작했다. 지금 생각해 보면 50명은 너무 적은 인원인데 그때는 그저 사용자 의견이라면 묻지 않고 그냥 받아들였다. 고치고 또 수정하는데 2주 정도를 허비하고 1000명 정도에게 오픈했다. 그러고 나니 의견이 다르더라. 그래서 다시 앱을 바꿨다. 그래서 또 2 주간을 허비했다.

우리가 흔히 하는 A/B 테스트도 비슷한 주의점이 있다. 상품 초기부터 욕심내서 계속 테스트만 해대면 정작 무엇이 중요한지를 간과할 수 있다. 또 너무 적은 숫자의 이용자들을 대상으로 테스트를 하면 결과가 나와도 그 의미가 없다. 30명이 좋아하는 디자인이랑 80명이 좋아하는 디자인? 의미가 없다. 나중에 더 많은 대중에게 앱을 선 보였을 때 80명이 좋아해서..라는 공식은 듣지 않는다. 의미 없는 이런 작은 의견수렴보다 정말 중요한 부분을 완벽하게 완성하는 게 중요하다는 걸 이번에 다시 한번 배웠다.

앱은 진화한다

앱 개발자가 좋든 싫든 앱이 변화하고 더 나아지기 위해서는 우선은 앱이 정말 사용자에게 필요한 앱이어야 한다. 처음 사용자에게 앱에 관해서 물어보면, 불만도 많고 개선점도 많이 알려준다. 그런데 이런 소수의 의견이 언제나 옳거나 다수가 원하는 것은 아니다. 그리고 다수가 원한다고 해도 회사의 방향과 맞지 않으면 그 타협점을 찾아야 한다. 사용자 의견이라고 그냥 다 받아들이다가는 앱이 진화가 어렵다.

베타론칭은 사용자의 의견을 묻기보다는 우선은 앱의 기능을 테스트하는데 중점을 두었어야 한다. 우선 앱이 완벽하게 그 기능을 다 하고 나서, 그 다음에 개선점을 물어보는 것이 맞다. 그렇지 않으면 앱을 만드는 사람이나 기획하는 이들이 핵심적인 것을 떠나서 별로 중요하지 않은 작은 점에 집착하게 된다. 이렇게 되면 시간도 잃고, 앱이 수행해야하는 가장 중요한 기능을 오히려 망가트릴 수 있다. 우리가 베타론칭을 하고 사용자의견에 따라 여기저기 수정하는 동안, 가장 중요한 핵심기능이 망가지는 오류를 범했다. 더 나아가, 계속해서 새롭게 추가한 기능들만 집중해서 테스트하느라 주요 기능이 망가진 것조차 몰랐다. 이래서 더 소비자들을 혼란시켰고, 오히려 시간을 더 끌게 되었다. 그리고 early users(처음에 사용하던 사용자들)의 신뢰를 잃었다.

이번에 앱을 론칭하면서 정말 많은 것을 배웠는데 가장 중요한 것이 이 부분이었다. 다시는 이런 오류를 범하지 않으려고 또 새로운 상품을 준비하시는 분들께 도움을 드리고자 썼습니다.

대문사진은 Photo by Kelly Sikkema on Unsplash

keyword