“알람앱에 ‘수면 도우미’ 기능을 추가하라”
알라미가 3달 만에 이룬 미션 완수 스토리
글. 서승환 딜라이트룸 섭스크립션 팀 프로덕트 오너
stephan@delightroom.com
‘잘 일어나기 위해선 잘 자야 한다’, 이는 알람앱 ‘알라미’가 슬립 사운드 기능을 출시한 이유다. 우리는 유저가 충분한 숙면을 취할 수 있도록 돕는 동시에, 알람앱의 가치를 기상에서 수면까지 확장하기로 했다.
이런 결정은 ‘알람의 책임 범위는 어디까지일까?’라는 본질적 고민에서 시작됐다. 우리는 유저를 단순히 깨우는 것뿐 아니라, 숙면 후 좋은 컨디션으로 기상하도록 도와야 했다. 이에 따라 알라미의 책임 범위는 자연스럽게 수면까지 넓어졌다.
지난 10년간 최고의 알람앱으로 기능했기에, 알라미의 책임 범위를 수면까지 확장하는 건 창사 이래 거대한 변화였다. 그럼에도 불구하고 수면에 도움을 주는 ‘슬립 사운드’ 기능은 3개월 만에 세상에 공개됐다. TF 형태로 구성된 슬립 사운드 팀이 어떻게 기획·디자인·개발·QA를 거쳐 신속히 기능을 완성했는지, 이 글을 통해 모든 과정을 공유하고자 한다.
슬립 사운드 기능 출시 과정
① 타깃 유저와 해결 문제 좁히기
▶타깃 유저 좁히기
‘어떤 유저의 문제를 해결할까?’
입면의 어려움을 분석하면 조도 밝기, 스마트폰, 침실 내 향기·온도, 샤워 여부, 공복 등 다양한 이유가 도출된다. 우리는 입면의 어려움보다 기존 슬립 사운드를 이용 중인 유저가 겪는 문제부터 해결하기로 했다. 마치 알라미가 처음부터 여러 기상 솔루션을 제공한 것이 아닌, 기발한 ‘미션’으로 시작해 유저의 마음을 사로잡았던 것처럼.
▶해결 문제 좁히기
‘타깃 유저의 어떤 문제를 해결할까?’
앞서 선정한 타깃 유저를 사전 조사한 결과, 대부분 유튜브를 이용하고 다양한 문제가 있었다. 우리는 각 문제를 해결했을 때의 임팩트와 난이도를 고려해 2가지로 문제를 좁혔다.
이로써 우리가 달성해야 하는 목표는 다음과 같이 좁혀졌다.
“유저에게 잘 맞는 슬립 사운드를 찾아주고, 편한 입면을 돕는다”
② 솔루션 도출하기
[문제 1]에 대한 답은 ▲유튜브에서 찾은 콘텐츠 자체가 별로라서 ▲유튜브에서 찾은 콘텐츠는 괜찮은데, 내 취향에 딱 맞지 않아서 등으로 정리했다. 조회 수만 높이기 위해 유저를 속이는 섬네일이 많은데, 이는 양질의 콘텐츠만 필터링해 소싱하면 해결된다.
유저의 취향은 ‘추천 콘텐츠’로 맞춰보기로 했다. 당장 퍼스트 파티 데이터는 없으니, 써드 파티 데이터 기반(조회 및 구독자 수 등)으로 제공하고, 추후 그 추천 로직을 고도화하는 방향으로 정했다. 또한 취향에 맞는 콘텐츠를 쉽게 찾을 수 있도록 탐색에 용이한 UI를 제공하기로 했다. 직접 검색이나 즐겨찾기보다는 유저가 콘텐츠 탐색 시 취하는 행동 패턴 중 가장 기본적인 ‘카테고리’로 구분해 구성했다.
[문제 2]에 대한 이유는 ▲(유튜브 프리미엄 이용자가 아닌 경우)유튜브 화면을 틀어 두고 자야 해서 ▲입면 무렵 꺼지게 해주는 타이머 설정이 되지 않아서 등으로 규정했다. 이 문제들은 앱에서 자체 슬립 사운드 콘텐츠와 타이머 기능을 제공하면 해결된다.
하지만 내장 동영상 플레이어로 자체 슬립 사운드 콘텐츠를 제공하는 건 얼핏 봐도 대규모 작업이었다. 빠른 유저 피드백을 위해 유튜브 API로 구현해야 했기에 유튜브 정책을 따라야 했다. 그래서 유저는 알라미 슬립 사운드 이용 시에도 화면을 틀고 자야 한다. 우리는 유저의 불편함을 조금이라도 줄이고자 실제 화면은 켜져 있지만, 마치 꺼진 느낌이 들게 만드는 ‘수면 모드’ 기능을 제공하기로 했다. 우선 밝기를 낮추고 시간을 표시했고, 출시 이후 피드백을 받아 개선해 나갈 예정이다. 타이머 기능이 없는 문제는 상대적으로 중요도가 낮다고 판단해 기획 과정에서 제외했다.
③ 솔루션 빠르게 실행하기
기획 논의를 제외하면 디자인부터 개발까지 한 달 정도 소요됐다. 팀원들이 본업을 수행하면서 빠르게 작업할 수 있었던 이유엔 4가지 특징이 있다.
1) 적절한 인력 아웃소싱
솔루션 중 양질의 콘텐츠만 필터링해 소싱하는 건 TF 팀원끼리 진행할 수 있었다. 하지만 슬립 사운드 분야 전문가의 손길을 더하면 좋을 거라 판단해, 업계 콘텐츠 PM으로 유명한 전문가와 협업했다. 덕분에 콘텐츠 1,000개 이상을 빠르게 모을 수 있었다.
2) 외부 API와 라이브러리 사용
내장 동영상 플레이어를 구현하는 건 대규모 작업이기에, 외부 소스를 활용해 플레이어를 웹뷰로 나타내는 방향을 택했다. 콘텐츠는 유튜브 API로 불러와 그대로 사용했고, 대략적으로 ‘백오피스↔서버↔클라이언트↔유튜브 서버’ 구조가 완성됐다. 외부 API인 만큼 유튜브 정책을 준수하고 해당 API로 제공받지 못하는 것도 있었지만, 이를 기반으로 내부 API 스펙이나 유저 플로우 구성을 초반부터 탄탄히 다질 수 있었다.
3) 팀원 간 싱크 맞추기
팀원 모두 본업이 있으니 효율적인 협업을 고민했고, 가능한 자주 싱크를 맞추는 것이 좋다고 판단했다. 그렇지 않으면 우선 순위에서 계속 밀리게 될 것이 자명했다. 특히 제로 베이스에서 출발하는 신규 기능이라, 자칫 싱크가 어긋나면 오차의 폭이 매우 컸을 것이다.
유저 스토리뿐 아니라 디테일한 유스 케이스(Use Case) 레벨까지 화면 디자인에 표기하며 싱크를 맞췄다. 각 화면의 디자인 목표 기술에 그치는 것이 아닌, 해당 화면에서 일어날 수 있는 모든 유스 케이스를 상세히 서술했다. 이로써 모두 동일한 유저 플로우를 머릿속에 그릴 수 있었다.
4) 중간중간 진행한 QA
호기롭게 문제를 정의하고 솔루션을 도출했지만, 옳지 않은 판단이 섞여 있을 수 있었다. 그래서 유저의 평가를 받기 전, 먼저 내부에서 사용하며 중간중간에 앱을 빌드해 QA(품질보증)를 진행했다. 내부 QA를 통해 ‘무엇이 더 필요하고, 무엇이 덜 필요한지’를 가늠했는데, 효과는 놀라웠다.
일례로 유튜브 API가 제공하지 않는 기능 중 재생 구간을 10초씩 이동하는 기능이 있는데, 원래 계획은 이를 제외하기로 했었다. 유저가 직접 프로그레스 바를 이동해 재생 구간을 넘나들 수 있기 때문이다. 하지만 직접 사용해 보니 팀원 대부분이 10초 이동을 위해 무의식적으로 더블 탭했고, 입을 모아 이렇게 이야기했다. “더블 터치로 앞뒤 10초씩 이동하는 기능은 무조건 필요하다”.
신규 기능을 빠르게 출시할 때 주의 사항은?
① 목표인 ‘핵심 지표’뿐 아니라 ‘초기 선행 지표’도 함께 설정하기
슬립 사운드는 유저의 입면 시간을 단축시키기 위해 출시됐다. 이를 지표로 표현한다면 유저가 잠드는 데 소요되는 시간이 얼마나 줄었는지를 측정할 수 있지만, 물리적으로 불가능하다. ‘재생 후 우리가 제공하는 수면 모드를 설정하는 것’ ‘사운드 재생 자체를 일정 시간 이상 유지하는 것’ 등 대체할 만한 지표를 설정했었다. 하지만 핵심 지표는 단기에 성과를 파악하기 어려운 후행 지표다.
유저 입장에서 신규 기능은 낯설다. 알람 기능을 기대하며 알라미 앱을 설치한 유저가 수면 기능을 보면 관심을 가질까? 그렇다 해도 수면 모드를 포함한 여러 기능을 바로 이해하기란 쉽지 않다. 유저의 기대치를 우리의 기대치와 맞추는 작업을 병행하며 수면 기능에 대한 유저의 이해도를 서서히 올려야 했다. 이런 과정까지 고려하면 단기간에 핵심 지표를 달성하는 건 너무 야심찬 계획이었다.
그래서 우리는 ‘유저가 알라미 슬립 사운드 콘텐츠 하나를 재생하게 하는 것’이라는 초기 선행 지표를 정했다. 이를 더 명확히 하기 위해 알라미 앱을 설치한 지 7일째 되는 유저의 앱 접속 대비 슬립 사운드 재생 비율을 선행 지표로 삼고, 목표 수준은 핵심 지표로부터 역산해 잡았다. 그렇게 해서 결정된 목표는 ‘7일차 유저의 재생률 n% 달성하기!’. 이후 기획 방향이 좁혀졌을뿐 아니라, 어디에 집중해야 할지도 확실해졌다.
② 출시 전, 가설별 목푯값을 구체적으로 설정하기
처음 출시하는 기능은 기획의 이유를 뒷받침할 수 있는 데이터가 없다. 최소한의 유저 인터뷰, 리서치 자료, 타사 레퍼런스 등에 근거할 수 있지만 갈피만 잡는 역할에 그친다. 결국 제품에 대한 감은 상세한 기획에서 나온다. 그래서 ‘왜 그렇게 기획했는지’ ‘출시 이후 어떤 데이터로 크로스 체크할 건지’에 대한 기록을 남겨야 한다.
신규 기능을 출시한 후 데이터들을 직접 마주하니 어디서부터 개선해야 할지 막막했지만, 초기 가설부터 검증하기로 했다. 이를 위해 출시 버전에 포함된 여러 기획의 근거와 가설을 다시 정리했다.
다행히 기존 이벤트 값들로 위 내용을 크로스 체크하고, 초기 가설 중 어떤 문제가 있는지 대략적으로 알 수 있었다. 하지만 초기 가설의 구체적인 목표치를 설정하지 않았고, 검증을 위해 기획한 이벤트 설계가 아니다 보니 어림잡아 살펴볼 수밖에 없었다. 물론 이조차 알 수 없는 상황이었다면 정말 아찔했을 것이다. 이 경험을 통해 아무리 바쁘더라도 모든 가설이 제대로 작동하는지 검증할 수 있도록, 가설별 목푯값을 대강이라도 잡고 이를 확인할 수 있는 초기 이벤트를 설정해야 함을 깨달았다.
③ 초기 유저의 피드백에서 불만과 버그를 예상하고 대응 방안 마련하기
대형 업데이트인 만큼 슬립 사운드에 대한 유저 반응은 뜨거웠고, 의외의 피드백이 전달됐다. 6~8개 정도로 제공되던 슬립 사운드 콘텐츠가 사라진 것에 대한 불만이 주를 이뤘다. 유저에게 새로 제공하는 양질의 콘텐츠 700여 개는 소용없었다. 전체 유저 250만명 중 소수의 목소리였지만, 듣던 사운드 콘텐츠가 사라진 건 마치 생필품을 뺏겨 삶이 어려워진 듯한 상황이었다. 유저는 그 사운드 콘텐츠가 없으면 잠을 잘 수 없기 때문이다.
우리는 바로 예전 콘텐츠도 들을 수 있게 설정했고, 빠른 대응에 고맙다는 유저의 피드백이 이어졌다. 기존 콘텐츠를 돌려 달라는 피드백을 해결하고 나서야, 신규 슬립 사운드에 집중된 피드백들이 보이기 시작했다.
여기서 아쉬운 부분은 2가지다. 첫째는 MVP(유저의 피드백을 받아 최소한의 기능을 구현한 제품)를 출시하느라 3개월을 바쁘게 보내긴 했지만, 유저에게 신규 기능에 대해 미리 안내할 시간은 충분했다는 점이다. 기존 슬립 사운드 콘텐츠의 소중함이 어느 정도였는지 알고 있었다면, 접근 경로를 열어 둔 채 출시했을 것이다.
두 번째는 빨리 대응하긴 했지만 예상하지 못한 이슈 때문에 모든 팀원이 갑자기 리소스를 빼 작업했다는 점이다. 대규모 업데이트인 것을 감안하고 일정 부분 버그·불만 대응을 위해 버퍼 리소스를 뒀다면, 더 수월하게 대응했을 것이다.
슬립 사운드 기능 출시 후 몇 달이 흘렀다. 초기 데이터는 넉넉히 쌓이고 있고, 유저 피드백에 기반해 여러 문제를 개선하며 ‘입면 시간 단축’이라는 궁극적 목표로 나아가는 중이다. 출시 과정에서 느낀 주의 사항 3가지를 유념하며, 다음 기획 논의 땐 안정적으로 운전대를 잡아야겠다는 생각이 든다. 4분기에는 알라미가 더 많은 유저의 수면 문제를 해결하길 바란다.
