brunch

라이킷 11 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Stephan Seo Sep 06. 2022

단 3개월 만에 '잘 재워주는' 기능이 출시된 알라미

시간을 다시 돌린다면, 무엇에 유의했을까

이전 글 : 9년 동안 잘 깨워주던 알라미, 단 3개월 만에 '잘 재워주는' 기능이 출시된 이야기
슬립사운드 출시기(1) : 어떻게 이토록 빠르게 출시할 수 있었을까?

이전 글에서는 어떻게 3개월 만에 슬립사운드 기능이 출시되었는지를 살펴보았다.

타겟 유저를 좁히고, 그들이 겪는 문제들 중 가장 핵심이 되는 문제들을 정의하여 그것들만을 해결하는 솔루션으로 기획을 간소화했다. 또한 작업에 착수함에 있어서도 적절한 인적 자본 & 물적 자본 아웃 소싱을 통해 시간을 단축 시켰고, 백문이불여일견 프로세스 (시각 자료 기반의 논의, 빠른 빌드로 실제 동작해보며 세부 기획 등)로 세부 유저 스토리들을 다져갔다. 그렇게 유저들에게 빠르게 우리의 수면 기능을 선보일 수 있었다.

이전 글 말미에 예상한 바와 같이, 유저들의 반응과 데이터를 보고나니 지난 날들에 대한 여러 회고 포인트들이 생겼다. 만약 시간을 돌린다면 나는 무엇에 유의했을까?

슬립사운드 출시기(2) : 빠르게 출시할 때 무엇을 주의했어야 했을까?

1. 목표 '핵심 지표'를 설정하되, 보다 가까운 '초기 선행 지표'도 함께 설정할 것

그리고 선행 지표 달성을 MVP 목표로 삼아보는 것도 고려해볼 것

슬립사운드 출시의 목적은 유저들의 입면 시간을 단축시키는 것이다. 이를 지표로 표현한다면, 실제 그들이 잠드는 데에 소요되는 시간이 얼마나 줄었는지를 측정해보면 되겠다. 하지만 이는 물리적으로 (현재로서) 불가능하기 때문에 이를 대체할만한 지표를 설정했어야 했다. '재생 이후 우리가 제공하는 수면 모드를 설정하는 것', '사운드 재생 자체를 일정 시간 이상 유지하는 것' 등 대표로 삼아볼만한 지표 후보는 여럿 있었다. 하지만 이러한 '핵심 지표'는 대체로 후행 지표이고, 단기에 달성하기 어려운 지표이기 마련이다.

기본적으로 신규 기능이라 함은 거시적인 제품 로드맵 하에 기획이 되다보니 그 목표치 자체가 다소 ambitious 하고 visionary 한 경향이 있다. '슬립사운드로 유저들의 수면 문제를 해결하겠어!'와 같이 웅장하게 출발하다보니 그럴 수밖에. 그렇다보니 핵심 지표들은 출시 직후 당장 사용 모수도 적은 상황에서 마주하게 되는 문제를 해결하는 데에 뾰족한 이정표 역할을 해주기 어렵다. 입면 중에 불편을 겪은 것인지, 입면 시도 조차 안하게 된 것인지, 컨텐트 고르는 단계에서 불편을 겪은 것인지, 아예 수면 탭에 진입을 안 한 것이 문제인지... 핵심지표 하나만으로는 출시 직후 우리가 어디에 힘을 실어야 할지 판단이 어렵다.

유저 입장에서도 신규 기능은 굉장히 낯선 기능이다. '알람'을 기대하고 우리 앱을 설치한 유저들이 '수면' 기능을 보게 되면 관심을 가질까? 관심을 갖는 유저라한들 우리가 제공하는 '수면 모드'를 포함한 여러 커스텀 기능들을 단기간에 이해하기란 쉽지 않다. 그들의 기대치를 우리의 기대치와 맞추는 작업이 병행되어야 하고, 제공되는 기능에 대한 이해 수준도 또한 서서히 올려야 한다. 이 모든 것을 고려하면 단기간에 ambitious한 핵심 지표를 달성하는 것은 매우 어려운 일이다.

이에 우리는 아주 간단하게 초기 선행 지표를 정해보았다. 유저들이 우리의 '슬립사운드 컨텐트 하나를 재생해보게끔 하는 것'을 앞단 목표로 잡았다. 보다 뾰족하게는 우리 앱을 설치한지 7일째 되는 유저들의 앱 오픈 대비 슬립사운드 재생 비율을 선행 지표로 삼고, 그 목표 수준도 핵심 지표로부터 역산하여 잡았다.

'7일차 유저들의 재생률 n% 달성하기!'

그 덕에 기획의 방향도 많이 좁혀졌고 어디에 힘을 주어야 할지 명확해졌다.

한편, 애초에 이 선행지표에 더 집중하여 MVP 를 출시했으면 어땠을까 하는 아쉬움도 들었다. 핵심 지표까지의 여정을 전부 커버한 버전을 배포하는 것이 아니라, 앞쪽 여정까지만 다져서 먼저 배포 후 지표 및 유저 피드백을 반영해 나가는 방식이었다면 어땠을까. 어느 방법이든 장단점이 있겠지만, 당시에는 이 방법을 전혀 생각지 못했었다는 것이 아찔한 부분이었다. 나또한 지나치게 ambitious 했던 것 같다. 하하.

2. 출시 전에 가정했던 여러 가설들을, 출시 이후에 제대로 검증할 수 있게끔 가설별 목표값을 구체적으로 설정해둘 것

'처음' 출시되는 기능들은 늘 그러하듯 기획의 이유를 뒷받침할 수 있는 데이터가 부재하다. 최소한의 유저 인터뷰, 리서치 자료, 타사 레퍼런스 등에 근거하긴 하지만 이는 굵직한 맥락에서의 갈피를 잡아주는 역할에 그친다. 처음 출시되는 기능의 디테일한 기획들을 결정짓는 것에 생각보다 큰 역할을 하는 것은 제품에 대한 감이고, 그것은 제법 사람마다 달라서 의견을 맞추는 것이 쉽지 않다. 극적으로 의견이 좁혀지면 이를 액션으로 바로 옮기기 바쁘다. 어려운 문제를 해결한듯한 상쾌함과, 얼마 없는 시간의 빠듯함이 그 이유이다. 우리가 '왜' 그러한 기획을 하였는지, 출시 이후 '어떠한 데이터로' 이를 크로스 체크해볼 것인지에 대한 기록을 남기지 않았다.

그렇게 기능이 출시한 이후, 기다리던 데이터들을 직접 마주하고 나니 어디서부터 개선을 시작해야 될지 갈피가 잡히질 않았다. 마치 '처음' 출시할 때와 동일하게, 여전히 기획의 이유를 뒷받침할 수 있는 데이터가 없는 느낌이었다. 생각해보니, 초기 가설들이 들어맞았는지부터 확인해봐야할 타이밍이었다. 이에 출시 버전에 포함된 여러 기획들의 근거 및 가설들을 다시 정리해보았다.

우리가 최상단에 Featured 섹션을 두었던 이유는, 유저의 첫 탐색을 돕기 위함이었다. >> 그들의 첫 탐색으로서 Featured 를 잘 활용하고 있을까?

우리가 '수면 모드'라는 기능을 만들었던 이유는 슬립사운드 컨텐트를 결정한 유저의 수면 환경 조성을 돕기 위함이었다. >> 그들의 수면 환경 조성을 위해 수면 모드가 잘 활용되고 있을까?

우리가 카테고리 순서를 Nature > ASMR > ... > Music 으로 두었던 이유는, 그것이 유저 인터뷰시 가장 높은 인기순이었기 때문이다. >> 실제로 유저의 인기를 반영하고 있을까?

다행히 이래저래 심어두었던 이벤트 값들로 위 내용들을 크로스 체크 해볼 수 있었고, 이렇게 살펴보고나니 당장 초기 가설 중 어느 가설들에 문제가 있는지 대략적으로 볼 수 있었다. 하지만 초기 가설들의 목표치를 구체적으로 설정해두지 않았고, 또 이 검증을 위해 뾰족하게 기획한 이벤트 설계가 아니었다보니 다소 투박하게 살펴볼 수밖에 없었다. 물론 이조차도 살펴보지 못하는 상황이었다면 정말 아찔했을 것이다. 아무리 바쁘더라도, 모든 가설이 제대로 working 하는지 추후 검증할 수 있게끔 가설별 목표 지표를 러프하게라도 잡아두고 이를 확인할 수 있는 초기 이벤트를 짜두었어야 했다. 그랬다면 보다 양질의 후속 기획들을 뽑아낼 수 있었을 것이다.

끝으로,

3. 초기 유저 피드백 중 불만/버그를 예상해보고, 미리 대응 또는 사후 빠른 대응을 위한 리소스를 확보해둘 것

큰 업데이트이니만큼 유저 반응은 뜨거웠다. 전혀 뜻밖에도 기존에 6-8개 정도로 제공되고 있던 슬립사운드 컨텐트가 사라진 것에 대한 불만이 주를 이루었다. 그들에게 새로 제공되는 양질의 700 여개 컨텐트는 소용이 없었다. 듣던 사운드가 사라진 것이 더 컸다. 전체 유저 250만명 중 극히 소수의 목소리였지만, 그 온도는 마치 생필품을 뺏겨 삶이 어려워진 정도의, 강렬한 뜨거움이었다. 그도 그럴 것이 이것이 단순한 컨텐트가 아니라, 그것이 없으면 잠을 잘 수 없는 수면과 관련된 컨텐트였다보니...

옛 슬립 사운드를 강렬하게 되찾고 싶어하는 유저 목소리

곧바로 예전 컨텐트들도 들을 수 있게끔 접근할 수 있는 제품 내 길을 열어주었고, 유저들의 불만도 빠르게 사라졌다. 오히려 빠르게 대응해줘서 고맙다는 피드백들이 이어졌다. 그렇게 기존 컨텐트를 돌려달라는 불만 피드백들이 걷히고 나서야, 신규 슬립사운드들에 집중된 피드백들이 보이기 시작했다.

친히 메일로 감사 인사를 보내준 유저

따뜻한 감사 메세지들

여기서의 아쉬운 부분은 두 가지이다. 첫째로 MVP 를 출시하느라 바쁘게 3개월을 보내긴 했지만, 유저들에게 신규 출시 기능에 대해 미리 안내할 수 있는 시간은 충분했다는 점이다. 기존 슬립사운드 6-8개의 소중함이 어느 정도였는지 미리 확인이 되었다면 그 접근 경로를 활짝 열어둔 채로 출시를 했을 수 있을 것이다. 두번째로는 부랴부랴 대응을 하긴 했지만 전혀 예상치 못한 이슈로서 모든 멤버들이 급작스럽게 리소스를 빼서 작업을 했어야 했다는 점이다. 상당히 큰 규모의 업데이트였다는 점을 감안하여 일정 부분 버그/불만 대응을 위해 버퍼 리소스를 두었으면 보다 수월하게 대응할 수 있었을 것이다.

슬립사운드 기능을 출시하는 데에 3개월이 걸렸고, 그 이후 벌써 2개월이 흘렀다. 넉넉한 모수의 초기 데이터들이 쌓여가고 있고, 유저들의 피드백에 기반하여 재생률을 높이기 위한 여러 개선 작업들이 진행 중에 있다. 초기 런칭 때 보다는 바라보아야 할 지표도 뚜렷하고 시드로서 활용될 정성적/정량적 데이터들도 많다만, 여전히 갈 길이 먼 상황이다. 얼른 선행 지표로서의 재생률을 높이고, '입면 시간 단축'이라는 궁극적인 목표로 나아가야 하니. 출시 과정에서 느낀 3가지 아쉬운 지점들을 유념하며 추후 필연적으로 있을 큰 규모의 기획 시즌에는 더 안정적으로 운전대를 잡을 수 있어야겠다.