brunch

라이킷 11 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Stephan Seo Aug 06. 2022

9년 동안 잘 깨워주던 알라미,

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

슬립 사운드 출시기 (1) : 어떻게 이토록 빠르게 출시할 수 있었을까?

알라미에 출시된 슬립 사운드 화면

0. 어쩌다가 슬립 사운드를…?

알라미 유저들 중에는 불면증을 겪는 유저들이 더러 있다. 아무래도 잠에 잘 못들수록 아침에 일어나는 것이 더 힘들테니, 천성적으로 헤비 슬리퍼인 유저군과는 그 특성이 사뭇 다르지만 어찌됐든 확실하게 일어나기 어렵다는 문제는 동일하다보니 알라미를 통해 그 문제를 해결하고 있는 셈이다.

딜라이트룸 입장에서도 넘버 그로스(구독, 광고 매출 증대)외에 딜리버 밸류 측면에서, 유저들을 확실하게 깨워주는 것에서 더 나아가 개운하고 상쾌하게 깨워주는 것으로의 밸류 확장을 고민하던 때였다. 생뚱맞게 아무 기능이나 더하는 방향이 아니라, 기존의 유저들과 접점을 유기적으로 넓힐 수 있는 방향으로 고민을 하다가 충분한 양과 질의 수면을 취하게끔 해주는 피쳐로 발을 먼저 내딛기로 했다.

“유저는 편히 잠들고 개운하게 일어난다!”

PO 워크샵을 통해 스스로 작성해본 Work domain Analysis Practice 중 일부 캡쳐

지난 9년 동안 최고의 알람 앱으로서 기능해온 알라미에, 어쩌면 이는 창사 이래 가장 큰 변화일 수도 있겠다는 생각이 들었다. 제품 입장에서도 그러하고, 그 제품을 사용해 오던 유저 입장에서도 그러할 것이다. 갑자기 이런 기능이 추가된다고? 당황해할 수도 있고, 기뻐할 수도 있다. 사실 iOS 앱에는 간단하게나마 수면 유도 음악이 존재해왔었다. 관련해서 간간이 유저들의 긍정적인 피드백들이 들어오곤 했던터라, 그들이 기뻐할 것임을 좀 더 확신하고 제품 기획에 착수했다.

수면 유도 음악과 관련한 유저들의 제안들

그리고 딱 3개월 걸려 슬립 사운드는 세상에 공개되었다. TF 형태로 구성된 슬립사운드 TF가 어떤 산전수전을 겪으며 3개월 만에 가치를 딜리버할 수 있었는지를 회고해보려한다.

슬립사운드 출시기 (1) : 어떻게 이토록 빠르게 출시할 수 있었을까?
슬립사운드 출시기(2) : 빠르게 출시할 때 무엇을 주의했어야 했을까?

1. 해결할 문제 좁히기 (What Why)

자, 어떠한 기획들을 해볼까? 하고 싶은 것은 많다. 하지만 해야 하는 것부터 찾아야 한다.

1–1. 먼저 타겟 유저를 좁혔다. 우리는 어떤 유저들의 문제를 해결할 것인가?

개운하게 일어나고 싶은 모든 유저

개운하게 일어나고 싶은 유저 중에 입면에 어려움을 갖고 있는 유저

개운하게 일어나고 싶은 유저 중에 입면에 어려움을 갖고 있는 유저 중에 이미 슬립 사운드를 어디선가 사용 중인 유저

충분히 임팩트를 낼 수 있을 정도의 타겟군으로 좁히고, 이어서 점차 타겟 유저군을 확장하는 것이다.

곧바로 2번으로 가도 좋겠지만, 이는 그들이 겪는 문제가 무엇인지에 따라 지나치게 많은 솔루션들이 도출된다. (조도 밝기, 폰사용 못하게 하기, 수면 향, 수면 음악, 침대 온도, 방 온도/습도, 샤워 여부, 직전에 식사 못하게 하기 등등…) 보다 뾰족하게 기존에 슬립 사운드를 이용 중인 유저들이 겪는 문제부터 해결하기로 했다. 마치 알라미가 처음부터 여러 기상 솔루션을 제공한 것이 아니라 뾰족하게 ‘미션’으로 시작하여 초기 유저들의 마음을 사로잡기 시작했던 것처럼.

1–2. 좁혀진 타겟 유저들이 겪는 문제 중, 해결할 문제도 좁혔다

우리 타겟 유저들이 겪는 문제만 뽑아도 수두룩하다.

사전 조사 결과 타겟 유저들의 대부분은 유튜브를 이용하고 있었고, 공통적으로 있는 문제들이 있었다. 그 중에서는 기술적으로 너무 어렵거나, 기획적으로 까다로워 해결하려다가는 반년 이상이 소요됨직한 문제들도 있었다. 각 문제들을 해결했을 때의 임팩트와 이를 위한 난이도를 고려하여 딱 두 가지로 문제를 좁혔다.

유저는 본인에게 맞는 슬립 사운드를 찾기 어렵다.

유저는 슬립 사운드를 재생하며 편히 입면하기 어렵다

고로 우리가 달성하고자 하는 목표 유저스토리는 아래와 같이 좁혀졌다.

“유저는 그들에게 맞는 슬립 사운드를 쉽게 찾고 편히 입면한다”

2. 해결 방식 추리기 (How)

솔루션은 늘 그렇듯 문제 정의에서 출발한다. 그들은 왜 슬립 사운드 찾는 게 어렵지? 그들은 왜 편히 입면하기 어렵지? 그 ‘왜?’를 어떻게 정의하느냐에 따라, 충분히 좁혀진 문제임에도 솔루션 도출 단계에서 다시 그 경우의 수가 셀 수 없이 많아진다. 하여 대략 아래와 같이 문제를 정의했고, 이에 따라 자연스레 솔루션들이 도출되었다.

2–1. 유저는 본인에게 맞는 슬립 사운드를 찾기 어렵다.

왜 찾기 어렵지?

유튜브에서 찾은 컨텐트 자체가 별로 좋은 컨텐트가 아니라서

유튜브에서 찾은 컨텐트 자체는 괜찮은데, 내 취향에 딱 맞지 않아서

단순 view 수를 높이기 위해 유저를 속이는 썸네일들이 있다고 하니, 이는 기본적으로 양질의 컨텐트만을 필터링하여 소싱하면 해결될 문제였다. 이에 더해 취향에 맞추기 어려운 문제는 ‘추천 컨텐트'로 해결해보기로 했다. 당장 퍼스트 파티 데이터는 없으니 써드파티 데이터 기반 (조회수, 구독자수..)으로라도 제공하고, 추후 그 추천 로직을 고도화하는 방향으로. 또한 취향에 맞는 컨텐트를 쉽게 찾을 수 있게끔 탐색에 용이한 UI 를 제공해주기로 했다. 직접 검색해볼 수 있는 기능, 즐겨 찾기 해둘 수 있는 기능 등 여타 다른 해결방식들도 있었지만, 유저들이 탐색시 취하는 여러 행동 패턴 중 가장 기본이 되는 ‘카테고리'로 구분하여 구성하기로 했다.

2–2. 유저는 슬립 사운드를 재생하며 편히 입면하기 어렵다.

왜 입면하기(잠들기) 어렵지?

유튜브 화면을 틀어두고 자야되서 (유튜브 프리미엄 이용자가 아닌 경우)

입면 즈음에 꺼지게끔 해주는 타이머 설정이 안되어서

앱 내에서 자체적인 슬립 사운드 컨텐트를 제공하고, 타이머 기능을 제공하면 위 문제들은 자연스레 해결된다. 하지만 내장 동영상 플레이어로, 자체적인 슬립 사운드 컨텐트를 제공하는 것은 얼핏 봐도 공수가 매우 크게 드는 기획이다. 해당 기획을 하려거든 해당 문제에 대한 컨피던스가 보다 높아져야 한다. (가령 이게 없으면 절대 슬립 사운드를 듣지 않는다든지)

빠르게 유저 피드백을 받기 위해 유튜브 API 로 구현하기로 한 이상, 우리는 유튜브 정책을 따라야 하고, 고로 알라미에서도 유저는 화면을 틀어두고 자야만 한다. 하여 실제로 화면을 틀어져 있지만, 마치 꺼진 느낌이 들게 만드는 기능 (이하 수면모드)을 제공하기로 했다. 어떻게 백그라운드 느낌이 들게 만들지?도 방향이 또 다양했지만, 기본적으로 밝기를 낮추고 시각을 표시하는 정도로 좁혀보았다. 유저가 해당 화면에서 ‘화면이 꺼진 것 같은' 효능감을 느낄지부터 확신이 없는 상황이지만 이는 출시 이후 피드백을 받아보기로 했다. 또한 타이머 기능이 없는 문제는 상대적으로 그 중요도가 낮다고 판단하여 기획에서 빼고 진행하기로 했다.

타겟 유저와 문제를 좁혔고, 해결책도 추렸다. 이제 달리면 된다.

여전히 기획에 포함하지 못한 것들이 눈 앞에 아른거렸지만, 후속 기획으로 남겨두고 디자인/개발에 착수했다.

3. 솔루션 빠르게 딜리버하기 (Shipping)

지난 시간을 돌아보면, 위 기획 논의를 제외하면 실제 디자인 및 개발은 총 한달 남짓 소요되었다. 각자의 본캐도 지속 수행하면서, 부캐로서 참여한 구성원들이 어떻게 이리 빠르게 작업을 할 수 있었는지 돌아보니 4가지 특징이 있었다.

3–1. 적절하게 인력 아웃소싱하기

TF 런칭 이전에 미리 진행되었던 컨텐트 선별

우리의 솔루션 중에 ‘양질의 컨텐트만을 필터링하여 소싱’은 내부 작업자에 대한 의존 없이 바로 진행해둘 수 있는 부분이었다. 심지어 이는 슬립사운드 쪽으로 식견이 있는 전문가의 손길이 필요한 영역이기도 하다. 업계 내 컨텐트 PM 으로서 유명하신 전문가과 협업하여 정말 빠르게 1,000개 이상의 컨텐트 수급을 끝마칠 수 있었다.

TF 런칭 이후 제품 내 유기적인 호환을 위해 Migrate 된 컨텐트 DB

3–2. 적절하게 외부 API 및 라이브러리 사용하기

위에 잠깐 언급한 것과 같이 곧장 내장 동영상 플레이어를 구현하기 보다는, 외부 소스를 활용하여 플레이어를 웹뷰로 구현하는 방향을 택했다. 자연스레 컨텐트는 유튜브의 것을 api 로 불러와 그대로 사용하는 방향이 되었고, 대략적인 백오피스↔서버↔클라이언트↔유튜브서버 라는 구조가 잡히게 되었다.

이 때 외부 API 인 만큼 그들의 정책 준수 (compliance)가 중요했고, 또 해당 API 로 제공받지 못하는 것에 대한 명확한 인지도 필요했다. 이를 기반으로 내부 API 스펙이나 유저 플로우 구성을 초반부터 탄탄하게 다져갈 수 있었다.

(이 API 자체가 무결하지 않아 적용 과정이 예상보다 녹록지 않았다. 또한 그들의 정책을 준수하며 만든 UI/UX 가 유저 사용성에 예상보다 큰 마이너스가 될 수도 있다. 이는 배포 이후 가장 먼저 확인해볼 부분들!)

3–3. 적절하게 협업하기

다들 본캐로서 활동하는 팀이 별도로 있었다보니, 어떻게 협업하는 것이 좋을지부터가 고민이었다. 다소 아이러니하지만 부캐일수록 빈번하게 싱크하는 것이 좋다고 판단했다. 그렇지 않으면 우선 순위에서 계속 밀리게 될 것이 자명했기 때문이다. 특히나 제로베이스에서 출발하는 완전 신규 기능이니만큼 자칫 싱크가 맞지 않을 경우 그 오차의 폭이 굉장히 커질 거라 판단했다.

또한 비동기 싱크의 경우 유저 스토리 뿐 아니라 디테일한 유즈 케이스 레벨까지 화면 디자인 상에 표기하며 싱크하기로 했다. 각 화면들의 디자인 목표 기술에 그치는 것이 아니라, 해당 화면에서 벌어질 수 있는 모든 유즈 케이스들을 상세히 서술한 것이다. 어느 정도 유저 스토리들은 정기 미팅에서 논의가 되지만, 디테일한 플로우 또는 엣지 케이스들은 실제 작업 진행 중에 싱크가 필요해지기도 한다. 피그마 상에서 서로가 서로에게 물음표를 던져가며 유즈 케이스들을 채워갔다. 모두가 하나의 문서만 바라보면 되었고, 그 문서를 보면 모두가 동일한 유저 플로우를 머릿 속에 그릴 수 있었다.

3–4. 적절하게 오랜 기간 QA 하기

호기롭게 문제를 정의하고 솔루션을 도출했지만, 허허벌판에 뚝딱 뚝딱 지어낸 것이기 때문에 우리의 판단 중에 옳지 않은 판단이 섞여 있을 수 있다. 유저들에게 직접 채점을 받기 전에, 내부적으로 우리가 사용해보는 방법을 취했다. 모든 기획을 다 담아내지 않더라도, 중간 중간 앱을 빌드하여 내부 QA를 진행하며 무엇이 더 필요하고, 덜 필요한지를 가늠해본 것이다. 그리고 그 효과는 대단했다.

유튜브 API 가 제공하지 않는 기능들 중에, 재생 구간을 10초씩 이동하는 기능이 있는데 당초 기획 때는 이를 제외하기로 했었다. 유저가 직접 프로그레스 바를 이동하여 재생 구간을 넘나들 수 있기 때문에, 즉 대체 가능한 플로우가 있기 때문에 제외한 것이었다. 헌데 막상 내부 QA를 하며 직접 사용해보니 나도 모르게 뒤로 10초 이동을 위해 더블 탭을 하는 나 자신을 발견했다. 그것이 동작하지 않는 것은 생각보다 크리티컬한 사용성 누락이었고, 재밌게도 모든 멤버들이 입을 모아 이야기 했다. “더블 터치로 앞뒤 10초씩 이동하는거 무조건 필요하다.”

적절하게 아웃소싱하고, 외부 API 및 라이브러리를 잘 활용하고, 적합한 협업 프로세스를 안착시키고, 넉넉하게 내부 QA를 했더니 한달 안짝에 제품 딜리버가 가능했다.

빠름~빠름~

물론 이 모든 것이 가능하기 위해서는, 개개인의 기획/디자인/개발/QA 관련한 하드스킬/소프트스킬은 기본적으로 전제되어야 할 것이다.
(딜라이터의 그것들을 굳이 말해 무엇하랴…)

사실 지금까지 이야기는 말그대로 ‘출시’에 대한 이야기이다. 이제부터 시작이고 헤쳐나가야 할 난관이 많다.

초기에 정의한 문제들이 의도대로 잘 해결되고 있는지 체크가 필요하고, 퍼널 데이터와 유저들의 목소리를 기반으로 지표 개선을 위한 여러 최적화가 필요하다. 또, 초기에 정의했던 문제에 포함되지 않았던 문제들을 해결하기 위한 기획 확장도 필요하다.

그럼에도 불구하고 이 모든 것을 할 수 있는 그 토대를, 모두가 본캐를 병행하며 부캐로서 3개월 만에 마련하였다는 것은 의미가 있다고 생각한다. 위에서 전부 다루지 못하였지만 목표 지표 세팅, 내부 API 설계, 이벤트 설계, 현지화 고민, 컨텐트 DB 관리 등 무에서 유를 만들 때에 챙겨야 할 것들이 정말 많았다. 멤버 모두가 정말 고생을 많이 했다.