한상엽
소니 A7M4 뽐뿌때문에 미치겠어요.
하늘에서 똑 하고 떨어지면 좋겠다,
쇼츠 PR 해야지...
아티클
박주혜
양대현
비전프로에 나만의 다마고치가 산다면? - 버추얼 펫 '와바(Waba)'
'스페이셜 펫(Spatial Pet)' 또는 '버추얼 펫(Virtual Pet)'이라 불리는 비전프로 앱 '와바(Waba)'의 사례를 공유드려요.
현실 세계에 실제로 존재하진 않지만 마치 '실재하는 것'처럼 느껴지고(Physical), 만질 수는 없지만 마치 '만져지는 것'처럼 느껴지는(Touchable) 감각을 구현한 부분이 흥미롭게 느껴져요.
왠지 과거 닌텐도 DS 시절 게임을 별로 좋아하지 않던 여성 유저에게 큰 인기를 끌었던 '닌텐독스'가 떠오르기도 하고, 최근 각광을 받고 있는 삼성전자의 '볼리'와 같은 반려로봇도 연상되어요.
저는 반려동물을 키우고 있진 않지만, 언젠간 독립을 하게 된다면 검은 고양이와 시바견을 키우고 싶다는 꿈을 항상 갖고 있었는데요!
'버추얼 펫'이 현실적인 이유로 거주 환경에서 반려동물을 키우기 어려운 이들의 감성을 채워줄 수 있다면, 사람들이 비전프로를 착용하고 있는 시간도 더욱 증가할 수 있지 않을까요? :)
강병연
서비스 개선에 가장 중요한 것은 무엇일까요? 문제를 명확히 정의하는 것입니다.
여러분은 어떻게 문제를 정의하시나요?
저는 MECE(미씨)하게 합니다. MECE는 제가 습관처럼 사용하는 논리적 사고 기법인데요. 가볍게 정리해 보겠습니다.
MECE 알아보기
= Mutually Exclusive and Collectively Exhaustive
= 상호 배타적이면서 전체적으로 포괄하는
= 상호 중복이 없고 누락이 없는
= 서로 겹치지 않으면서도 빠뜨리는 것이 없는
MECE한 사고는 대상 또는 현상을 서로 겹치지 않으면서도 빠지는 것 없이 나누는(쪼개는) 것입니다.
쉬운 예로 사람을 남과 여로 나누는 것과 시간을 과거, 현재, 미래로 나누는 것이 있습니다.
MECE 사고의 가장 큰 장점은 대상과 현상을 명확히 바라볼 수 있다는 것입니다. 명확히 바라본다면 ‘진짜 문제’를 정의할 수 있습니다.
주의할 점은 MECE 하다고 무조건 좋은 것은 아닙니다. 유의미한 정보를 이끌어낼 수 있는 기준으로 나누는 것이 중요합니다.
MECE 예시보기
커피 원두를 판매하는 쇼핑몰의 최근 구매 취소율이 증가했다는 가정 하에 MECE하게 문제를 정의해보겠습니다.
1. 첫구매자 / 재구매자
커피 원두는 정기 구매자가 많을 수 있는 상품입니다. 첫구매자와 재구매자의 경험 차이가 있을 수 있어 대상을 나누어 각 취소율을 구합니다.
2. 원두1 / 원두2
쇼핑몰의 원두는 2가지 입니다. 쇼핑몰 전반의 취소율이 증가한 것이 아니라 특정 원두에서 발생한 문제일 수 있습니다. 각 원두의 취소율을 구합니다.
3. 배송전 / 배송중 / 배송후
언제 취소가 많이 발생했는지 궁금합니다. 원두를 받기 전과 후의 취소 사유가 다를 수 있습니다. 배송 상태를 나누어 취소율을 구합니다.
분석 결과는 상단 이미지에서 확인하실 수 있습니다.
이렇게 대상을 나누고 나눠 취소율을 확인하니 많은 재구매자가 원두2를 배송 받은 뒤 환불을 하는 것이 취소율 증가의 주요 원인이라는 점을 확인했습니다.
환불 고객이 남긴 취소 사유와 인터뷰 데이터를 취합하니 원두2의 패키지가 최근에 변경되었는데 재구매 고객이 원두 맛이 달라졌다고 착각해 취소율이 늘어난 것입니다.
문제와 원인을 명확히 알았으니 제품 상세 페이지에 패키지만 변경되었을 뿐 맛이 동일한 원두라고 명시하는 방법으로 해결할 수 있습니다.
MECE 활용하기
위 쇼핑몰 예시는 사실 취소 사유 데이터만 뜯어보는 등 간단한 방식으로도 문제와 원인을 파악할 수도 있습니다. 그러나 우리가 운영하는 서비스는 훨씬 복잡하게 돌아가고 있을겁니다. 그래서 MECE하지 않으면 현상을 명확히 바라보지 못해 막막해 하거나 효과 없는 엉뚱한 액션만 취할 수 있습니다.
서비스 개선에 가장 중요한 것은 문제를 명확히 정의하는 것입니다. 현재 운영하시는 서비스의 문제를 얼마나 잘 알고 있는지 아래 내용을 점검해보시는 것은 어떨까요?
📌 현재 서비스에서 가장 문제가 되는 지표가 무엇인가요?
📌 문제 정의를 어떻게 하고 있나요? MECE가 이뤄지고 있나요?
📌 MECE하게 접근했을 때 가장 중요하고 시급한 문제는 무엇인가요?
워킨스
유튜브 채널 7개를 운영하고 깨달은, 알고리즘이 좋아하는 콘텐츠
본 글은 인디브랜더 워킨스의 사업일기에 연재된 글을 재구성한 글입니다.
1인 창업가의 생생한 사업일기를 통해 인사이트를 해킹하세요.
구독하고 매주 사업일기 훔쳐보기✅
앞으로 론칭하게 될 마케팅 교육프로그램은
돈, 시간, 인력이 부족한 사업가들을 위해
리소스를 덜 쓰고도 잘 팔수 있게 돕는 것이 목표이다.
하지만 제작을 위한 시간이 소요되므로
잠재고객을 먼저 모아가면서
교육프로그램 개발을 병행하기로 결정했다.
그리고
이번주엔 총 8개의 콘텐츠를 발행했다.
한 주간 발행한 콘텐츠는 아래와 같다.
네이버 블로그 글 1개
유튜브 긴영상 1개, 숏츠 3개
인스타그램 릴스 1개, 카드뉴스 1개
쓰레드 글 1개
현재 고객을 모으기 위한 메인 매체는 유튜브이다.
하지만 블로그, 인스타그램, 심지어 쓰레드에도
콘텐츠를 발행하는 것은 이유가 있는데,
그 이유는, 유튜브 알고리즘에게 잘 보이기 위함이다.
나는 지금까지 유튜브 채널 7개를 운영해봤다.
예술, 건강, 음악, 교육
다양한 주제와 형식으로 운영을 했고,
심지어 부족한 그림실력이지만
글로벌 구독자를 타겟한
2D애니메이션 콘텐츠를 만들기도 했다.
(라바와 같은 형식으로 만들면
영어 대사를 넣지 않아도
스토리를 전달할 수 있다고 판단했기에)
출처 - Youtube 투바앤 TV Korea, 애니메이션 라바
이런 다양한 시도를 하는 과정에서
정말 많은 시행착오를 겪었고,
그 결과 유튜브 알고리즘이 좋아하는
콘텐츠 만드는 방법을 알게 되었다.
유튜브 알고리즘이 좋아하는 콘텐츠는
생각보다 간단하고 명료하다.
= 유튜브가 돈을 더 많이 벌게 해주는 콘텐츠!
유튜브는 광고회사이다.
그러므로 유튜브가 돈을 더 많이 벌기 위해선
광고주들이 더 많은 광고를 하면 된다.
그렇다면 광고주들이 더 많은 광고를 하게 하려면
어떻게 해야할까?
더 많은 사람들을 데려와서,
오래 머무르게 하면 된다.
그래야 사람들이 더 많은 광고를 보게 될 것이니까!
그러므로 구글은 더 많은 돈을 벌기 위해
유튜브의 알고리즘을 개발한 것이다.
즉, 더 많은 사람을 데려오고
플랫폼에 오래 잡아두는 콘텐츠가
유튜브 알고리즘이 좋아하는
콘텐츠라고 할 수 있다.
그리고 이런 콘텐츠를 측정하고 선별하는 것이
알고리즘의 역할이고
알고리즘이 측정을
더 잘하도록 개발한 것이
조회수, 시청지속시간, 재방문시청자 등의
측정지표라고 할 수 있다.
이런 측정지표의 성적에 따라
알고리즘은 당근과 채찍을 준다.
하지만 생성 초기 채널은
구독자가 없는 상태이므로
알고리즘이 콘텐츠를 평가 할
시청자 모수 자체가 부족하다.
그러므로 외부에서 트래픽을 만들어주는
활동을 해주어야 한다.
이제 알고리즘 입장에서 생각해보자.
특정 콘텐츠를 통해
외부 플랫폼에서 시청자들이 유입된다.
그리고 그렇게 들어온 시청자들이
유튜브에서 오래 머무르는 게 확인되었다.
알고리즘 입장에선
돈이 되는 행동이 포착된 것이다.
그렇다면 사람들에게 노출을 늘려주는
당근을 조금씩 줄 것이다.
이러한 원리로 작동하는 알고리즘을 이용하기 위해
나는 네이버 블로그, 인스타그램, 쓰레드를 이용해
트래픽을 유튜브 영상으로 넣고 있는 것이다.
하지만 반대로 생각해보면
블로그를 운영하는 네이버나
인스타그램,쓰레드를 운영하는 메타(Meta) 입장에선
콘텐츠를 본 고객들이 외부 플랫폼으로
빠져나가는 것이므로 좋아하지 않을 것이다.
고객이 들어오자 마자
외부로 빠져나가는 것이 감지된다면
내 콘텐츠의 노출을 최소화하려 할 것이다.
그러니 여러 플랫폼을 활용하려면
해당 플랫폼의 특성에 맞게 정보를 가공하고
충분히 가치를 제공하려고 노력해야 한다.
예를들어 블로그 글은 몇 문장 안 적고
유튜브 링크를 걸어두는 것이 아니라
충분히 양질의 내용으로 블로그 글을 작성하되,
운전 중에 음성으로 듣고 싶거나
영상으로 보고 싶은 분들을 위한
추가적인 도구로 유튜브 콘텐츠를 제안하는 것이
보다 효과적인 방법이라고 할 수 있다.
이런 방법으로 사람들을 많이 데려왔다면
이제 그들이 플랫폼에 오래 머무를 수 있도록
시청지속시간을 높이는 콘텐츠를 제공해야한다.
시청지속시간을 높이기 위한 다양한 전략이 있지만
크게 2가지를 생각해보는 것이 좋다.이 두 가지 중, 한 가지만 충족되어도
영상을 끝까지 볼 확률은 매우 높아진다.
본글에서 계속 읽기▶
Hyunseo Caroline Oh
노션에 글을 쓰고 이미지를 업로드하면
인스타에 자동으로 업로드 해주는 자동화 프로그램이 있으면 좋겠어요
현실적으로 구현 할 수 있나요?
구현할 수 있다면, 어떤 기술이 필요한가요?
김주형
멘토링 꼭 필요해?
근면성실 스터디 구성원을 위해 가상 환경 설정을 통한 함께 자라기를 고민하며 클린코더라는 책을 읽다보니 결국 멘토링 사업의 수요가 꽤 크다는 생각을 갖게 되었습니다
특히나 대한민국은 사회적 접근, 즉 인맥사업(학연지연혈연)이 돈 버는데 최고고 그 다음에 해야할 일을 잘하는 것을 따지게 되는데
업계 짬밥이나 전문성, 인맥 등이 떨어지면 협력업체 등록을 위해 싫어도 억지로 술마시고 로비하면서 먹고 살기 위해 희생해온게 대부분 아버지들의 현실이었고
요즘은 그게 인강이나 멘토링, 교육과정 으로 변질된 것 같습니다
물론 그게 도움되고 좋은 결실을 맛보며 성장한 분들도 있겠지만 그럼에도 불구하고 나와 비슷한 고민을 하는 사람들이 있다면, 그들에게
정말로 필요한 건 무엇일까? 고민했습니다그래서 단순히 네이버사전에 검색했습니다
정말 : 거짓없이 말 그대로
시장의 멘토링 사업
네카라쿠배, 잘만났다. 진심으로
어떻게 하면 이런 테크 기업들을 부술 수 있을까 궁금했습니다
기왕이면 잘
세계 최고 수준으로
그래서 책을 조금 훑으며 모서리접기 정도까지 했습니다
함께 자라기
육각형 개발자
실용주의 프로그래머
사소한 일이라도 맡은 분야에서 세계 최고가 되어라
그냥 최고 말고,
세계최고, 어떤 누구보다도 잘할 자신 있는
최근 파트타임 아르바이트를 구했습니다
정말로 솔직하게 이런 일까지 해야하나 라는 생각에 많이 고민될만큼 낯선 일이지만
주워들은 명언 정도이더라도, 사소한 일이라도 맡았으면 세계 최고가 되어라 라는 말을 무시할 수 없어서
그리고 나보다 절박하게 노력하는 모습을 보이는 사람들이 있어서
그냥 내가 속한 상황과 환경이 세계 최고라고 생각하려고 노력하고 있습니다
억텐일 수 있지만, 그럼에도 불구하고 불평만 하기보다는 어떤 대안과 노력이 도움될지 고민하는 사람으로 성장하고자 합니다
오늘의 반성
쉬려는 노력을 좀 하고 있습니다
어처구니 없는 세상에서 소소하게 잘 사는 유튜브 브이로그 보면서 대리만족하고 댓글을 달았습니다
맛있는 음식을 사먹으러 식당 상가에 가봤습니다
혼자 돈써봤자 입맛만 버릴 것 같다는 생각에 돈주고 사먹지 않았습니다
알고리즘(그리디, DP, 분할정복), 한계 수용 능력, 대규모 데이터 핸들링 에 대해 관심을 가졌습니다
혼자 할 일이 너무 많으니 힘들어서 머리 좋은 사람들이 처리하는 비결에 대해 학습했습니다
그때그때 좋은 결정하는 비결(그리디), 같은 비결 재사용(DP), 중복 없는 역할분담(분할정복)
이런걸 스토리있는 공식문서로 만들어 가상 상황을 설정하는 문서, 되도록 학습을 강요하지 않고 스스로 일으키는 효과나 경험을 원한다는 생각을 하면서 읽었습니다
velog보다 티스토리 결과로 검색했을때 좀 더 품질 좋은 검색결과가 나온다고 느꼈습니다
하지만 시간투자에 비해 깊은 고민보다는 빠른 소비 위주로 정보들을 접했습니다
분수에 넘치는 일을 자꾸 벌리고 책임지기 버거워하는 점 반성합니다
그렇다고 그만둔다고 해서 딱히 할게 있는 것도 아니고
정말로 어쩔 수 없어서 할 건 하겠슴다
Drew Hong
업데이트했더니 유저 반 토막? 어떻게 모았는데.. [찐스타트업] ep.5 유저 반 토막
#스타트업 #현실
#터닝 #도파민디톡스 #앱스토어 #다운로드
📺 찐 스타트업의 성장을 기록한 웹드라마 ≪찐 스타트업≫ 5화 입니다
짧은 숏폼과 자극적인 영상으로 집중하지 못하는 사람들을 위해 '터닝' 앱을 제작했어요😎
▶︎ 앱 스토어에서 '터닝'를 검색하세요
▶︎ ≪터닝 인스타그램≫ 보러가기 👉 https://litt.ly/turning
-
구독 @turning_korea
for your turning point.
김성령
일기 쓰기 에디터
앞으로 매주 4월 중 iOS앱으로 출시될 TODA의 기획 과정을 공유합니다. 앱에 대한 소개보다는, 기능 단위의 요소를 기획할 때에 어떠한 과정으로 작업하였는지에 대한 기록을 작성합니다. (안드로이드 개발자분 구인하고 있습니다)
*시리즈에서 앞으로 소개할 기능 예시
1. 배경
일기를 작성해본 적이 없는 사람들은 다음과 같은 어려움을 겪습니다.
(1) 본인의 삶에 대해 무엇을 기록해야 하는지 모른다
(2) 어떻게 기록해야 하는지 모른다
(3) 왜 기록해야 하는지 모른다
2. 요구사항
가장 간편한 기록을 제공하면서도(What, How), 일기 작성의 효용(Why)을 느낄 수 있어야 합니다.
(1) 무엇을 기록해야하는지 알려주어야 합니다
(2) 어떻게 기록해야하는지 알려주어야 합니다
(3) 왜 기록해야하는지 알려주어야 합니다
3. 구현
위 세 가지 요구사항을 만족하기 위해 TODA에서는 다음과 같은 세가지 작성 툴을 제공합니다.
(1) 직접 작성하기
(2) 키워드로 작성하기
오늘 하루 있었던 일을 키워드로 떠올려보고 (What)
키워드를 입력하여 ai에게 전달하면
약 1,000자 이내의 일기를 ai가 작성해줍니다.
ai가 작성해준 일기를 읽으면, 어떻게 일기가 작성되는지(How)를 학습할 수 있습니다.
ai가 작성해준 일기를 읽다보면, 본인의 실제 경험과 부합하는 문장과, 그렇지 않은 문장을 확인할 수 있고 본인에 대한 사실적인 경험이 무엇이었는지 되짚어보면서 일기 작성의 효용(Why)를 경험할 수 있습니다.
본인도 모르던 사건에 대한 본인의 감정을 알 수 있고, 사실과 다르게 작성된 ai의 일기를 보면서 실제 느꼇던 경험이 무엇이었는지 되짚어 볼 수 있습니다.
(3) 대화하며 작성하기
ai와 아침부터, 밤까지 하루 있었던 일에 대해 대화합니다.
아침, 오전, 점심, 오후, 저녁, 밤을 주제로 설정하고,
각 주제에 대한 유저의 답변, 답변에 대한 ai의 공감, 답변에 대한 꼬리질문을 이어나가며
오늘 하루 있었던 일을 떠올려 보고 (What)
모든 대화가 종료된 뒤에, ai가 일기를 요약해 전달해주어 오늘 하루가 어떻게 작성되는지(How) 확인해보고
ai가 작성해준 일기를 읽다보면, 본인의 실제 경험과 부합하는 문장과, 그렇지 않은 문장을 확인할 수 있고 본인에 대한 사실적인 경험이 무엇이었는지 되짚어보면서 일기 작성의 효용(Why)를 경험할 수 있습니다.
혹은 ai와 대화하는 과정에서도 하루를 기록해야하는 이유(Why)를 경험할 수 있습니다.
4. 협업하기
요구사항을 만족하기 위해 구현해야할 사항을 개발자에게 전달합니다.
ai 연동
(1) ai 작성 기능에 어떤 api를 활용할 것인지
(2) 해당 api를 활용하기 위해, 환경 세팅을 도와줄 것은 없는지
(3) api 통신 실패(타임아웃), api 실패값 전달 시 예외케이스는 어떻게 할 것인지
에디터
(1) 입력값
입력값 저장 시, 네이티브에서 서버로 전달하는 정보와 활용할 api
입력값을 불러올 경우, 서버에서 네이티브로 전달하는 정보와 활용할 api
필수 입력값, 선택 입력값에 대한 정책 및 예외케이스 정리
(2) CRUD (생성, 수정, 활용, 삭제)
(3) UI 배치
(4) 인터렉션
입력값을 입력할 때에, 어떤 화면이 노출되는지
화면 간 이동은 어떠한 방식으로 할지
시스템 키보드가 노출될 때에는 UI가 어떤 화면이 되어야 하는지
해당 화면으로 변할 때의 작동은 어떻게 할 것인지
(5) 결과
결과적으로 작성된 일기는 유저에게 어떻게 보여질 것인지
한예원
만약 내 브랜드만의 GEN AI 이미지&디자인 스톡플랫폼이 있다면?!
루카스메타는 항상 브랜드/회사가 어떻게하면 더 효과적으로 브랜딩이 될 수 있을지, 디자인&이미지 부분에서 비효율적인 부분이 발생하여 본질을 놓치고 있는 회사가 있는건 아닌지, 이런 회사가 있다면 어떻게 도움이 될 수 있을지 항상 고민하고 있습니다.
이러한 고민들을 해결하기 위해, 루카스메타가 브랜드 맞춤형 GEN AI 이미지&디자인 스톡플랫폼 서비스를 오픈하였습니다.
브랜드의 컨셉, 컬러, 무드, 등을 학습시켜서 브랜드가 원하는 디자인과 이미지를 매월 맞춤형 으로 제공합니다.
다른 브랜드와 겹치지 않는 브랜드 고유의 디자인과 이미지 확보가능
JPG, PNG, SVG(.ai) 파일 확장자 제공가능
노동집약적 디자인 & 이미지 검색 시간 비용 절감
브랜드무드 + 새로운 트랜드가 반영된 이미지 & 디자인 제공
더 궁금하신 부분이 있다면, 커피챗 주세요 :D
Lucy Seo
이전 글들에서 앱을 처음 설치한 직후에 노출시키는 온보딩 구매화면 (인트로 구매화면)의 강력한 힘의 비밀에 대해서 공유한 바 있듯, 이른 시점에 유저들에게 적극적으로 다가가는 것은 매출 그로스 측면에서 매우 중요하다. 하지만 동시에 이는 유저 사용성 측면에서는 좋지 않은 (불쾌한) 접근일 수 있고, 실제로 유저 리텐션 하락으로 이어지기 쉽다. 그렇기 때문에 꼼꼼한 A/B Test를 통해 조심스럽게 접근해야 하는, 생각보다 어려운 전략이다.
이와 달리 특정 프리미엄 기능을 사용하려 시도하는 때에 구매화면을 띄우는 것은 상대적으로 덜 불쾌한 접근이다. 유저 입장에서 어느 정도 맥락이 이해되기 때문이다. ‘아 이 기능을 사용하려면 구독을 해야 하구나.’ 이러한 접근은 유저 리텐션에 악영향을 끼치진 않지만, 반대로 구독 매출 측면에서 쏠쏠한 역할을 해내진 못한다. 해당 기능을 사용하기 위해서는 유저가 제법 여러 단계를 거쳐 그 맥락을 찾아 들어가야 하기 때문이다. 결과적으로 구매화면 노출 대비 전환율은 뛰어나지만, 구매화면 노출량 자체가 적은 것이 문제인 것이다.
구매화면 엔트리포인트 기획의 두 갈래
두 종류의 엔트리포인트, 각각의 강점을 다 살릴 수 없을까?
유저의 사용 경험도 살리고, 전환율도 높이는 지점을 찾고 싶었다.
유저 사용 경험이 좋은 ‘맥락 위 깊게’에서 ‘깊게’가 중요한 것은 아니다. 적절한 ‘맥락 위’에 놓이는 것이 핵심이다. 그저 유저가 특정 기능을 찾아 상대적으로 깊게 들어가기 때문에 ‘깊게’가 된 것이었다. 그래서 괜찮은 맥락을 한번 ‘얕게’ 빌드업 해보기로 했다.
맥락을 빌드업하다
이를 위해 모든 프리미엄 기능의 위치를 무작정 얕은 뎁스로 옮길 수는 없다. ‘얕은 맥락’에서도 중요한 건 ‘얕음’이 아니라 여전히 ‘맥락’이기 때문이다. 하여 먼저 적절한 맥락을 기획하기 위해, 유저들이 깊게 위치한 프리미엄 기능 화면에 들르게 된 이유, 그리고 사용하려 했던 이유가 무엇일지 조명해 보았다.
‘단순 호기심에’, ‘더 강력한 알람이 필요해서’, ‘신기해 보여서’ 등의 여러 가설 중에, ‘더 강력한 알람이 필요해서’가 가장 설득력 있어 보였다. 더 강력한 알람이 필요한 유저들이 여러 기능들을 둘러보다가 깊게 위치한 프리미엄 기능까지 도달한 것일 것이다. 그럼 더 강력한 알람이 필요한 유저를 찾아 얕은 곳으로 나서 봐야겠다는 생각이 들었다.
어떤 유저군을 타겟할지 어떻게 소구 할지는 미정이었지만, 하나 확실했던 것은 이것이 짧은 ‘넛지성’ 메시지가 아니라 ‘일련의 플로우’로 제공되어, 유저로 하여금 정말 ‘맥락’ 위에 놓여 있다고 느끼게끔 하는 것이 중요하다는 것이었다.
기존 알람을 더 강력하게 만들어주는 프리미엄 온보딩 플로우
이에 기존에 구독 유저들에게 제공되고 있는 ‘프리미엄 온보딩’ 플로우를 재활용해보기로 했다. 당시 프리미엄 온보딩의 골자도 ‘기존 알람을 프리미엄 기능을 통해 더 강하게 만들어 주는 것’이었기에, 진행 플로우의 목적이 이번 목적과 비슷했다. 그리하여 이번 기획은 구독 직후의 ‘알람 강화 프로세스’를 구독하기 전에 맛보기로 제공하여, 알람을 강화시키는 맥락 위에 놓이게 해 보는 실험이 되었다.
방법은 간단했다. 특정 유저군에게 ‘현재 알람 파워가 부족한데, 알람을 강화시켜 보세요’라는 다이얼로그를 띄우고, 이에 응한 유저들에 한하여 위 강화 프로세스를 진행시킨다. 그리고 마지막 CTA 인 ‘이대로 알람 강화하기’를 누르면 구매화면이 뜨는 것이다.
빌드업의 효과는?
1.4배 구독 전환율 증대, 리텐션 하락 없음!
약 41% 증대한 구독 전환율…!
빌드업 그 효과는 대단했다. 어찌 보면 전에 없던 새로운 구독 퍼널이 추가되는 셈이라 구독 증분이 발생하는 것은 당연한 기대였다. 다만 얼마나 크게 증가하느냐, 그리고 리텐션이 떨어지지 않느냐, 이 2가지가 중요했고, 그것을 결정짓는 변수가 바로 ‘얼마나 적절한 맥락인가’였던 것이다. 리텐션 하락 없이 전환율 증분이 크게 늘어난 것을 보니, 직접 알람 파워를 강화시켜 보는 일련의 과정이 유저가 놓일만한 탄탄한 맥락이 된 것으로 보인다. 심지어 전체 구독 전환 엔트리 포인트 중에서 2위에 해당되는 비중을 차지할 정도…!
이번 맥락에서의 전환 모수가 전체 신규 구독 전환에서 차지하는 비중 15~20%
빌드업의 고도화
본 실험은 특정 조건을 충족시킨 신규 유저에게 제공되는 실험이었다. 여기서 ‘더 강력한 알람이 필요하지 않니?’라는 질문은 어쩌면 신규 유저보다는 알람을 최소 1회 이상 사용한 기존 유저에게 더 적합한 맥락일지도 모른다는 생각이 들었다. 이래저래 임팩트를 산정해 보니 타겟 모수가 넉넉해 신규 유저 못지않은 쏠쏠한 임팩트까지 예상되었다. 바로 이어서 기존 유저를 대상으로 동일한 빌드업을 재활용해보려 한다. 신규 유저와 달리 기존 유저들은 어느 정도 고착된 사용 경험을 가지고 있기 때문에 새로운 기능을 활용한 알람 강화 맥락에 더 반응할 것이라 예상되며 (전환율 증대), 리텐션 하락의 염려도 훨씬 덜할 것이라 예상된다.
또한 빌드업 과정에서의 퍼널별 이탈률을 살펴보니 특정 구간에서 유난히 이탈이 많은 구간이 있었다. 만약 퍼널을 개선하여 빌드업의 최종 종착지인 구매화면까지 더 많은 유저가 도달하게 된다면, 이 빌드업의 임팩트는 더 커지지 않을까? 마찬가지로 임팩트를 계산해 보니 더 큰 증분의 전환율을 일궈낼 수 있으리라 기대가 되었다. 이 또한 별도의 후속 실험으로 진행해보려 한다.
두 종류의 엔트리포인트, 각각의 강점을 다 살릴 수 없을까?
유저의 사용 경험도 살리고, 전환율도 높이는 지점을 찾고 싶었다.
새로운 시도를 통해 위 질문에 대한 어렴풋한 답을 찾은 것 같다.
여기서 핵심은 유저의 문제(니즈)를 해결해 주는 맥락을 빌드업하여 적시에 먼저 다가가는 것이었다.
이때 그 맥락이 얼마나 억지스럽지 않게 매력적으로 구성되느냐가 중요하고, 노출되는 타겟 및 시점에 따라 충분히 더 매력적인 맥락이 될 수도 있기 때문에, 해당 변수에 대한 지속적인 최적화를 신경 써야 할 것이다.
⏰ 딜라이트룸에서 알라미와 함께 아침을 바꿀 분들을 모십니다 🙌
딜라이트룸의 다양한 채널들을 팔로우하고 빠르게 소식을 받아보세요!
딜라이터들의 다음 아티클도 빠르게 만나보려면? 지금 바로 미디엄 팔로우!
절찬 채용중인 포지션 알아보기 ⏰(+ 여기서 지원하면 입사 축하금 100만원💸)
Rachel
안녕하세요. IT 대기업에서 프로덕트 매니저로 일하고 있는 Rachel입니다. 오늘은 저의 이야기와 함께 하는 나만의 밥벌이 찾기 두 번째 시리즈예요. 결론적으로 말하면 AI붐으로 정규직 일자리 대신 긱 이코노미가 커지는 현실에서 나만의 밥벌이를 하려면 나에게 맞는 아이템이 뭐가 있을 지 정보가 필요하고, 이런 정보를 같이 나누고 나의 행동을 부스팅 할 네트워크와 나의 반복적 행동이 필요해요.
저는 이런 맥락에서 뉴스레터로 N잡을 통해 1인 창업 나아가 경제적 자유를 이루고 싶은 사람들에게 정보를 주고 싶어요. 그리고 규모가 커지면 관심사가 맞는 사람들 중 몇 가지 기준을 갖고 허들을 만든 후 커뮤니티를 만들 계획이예요. 날이 갈수록 막막해지는 세상에서 두려움에 떨고만 있다면 인생은 더 어둡게 변해갈 수 있지만 답을 찾고자 하는 사람이 모이면 반드시 답이 찾아지죠.
자세한 내용은 아래 링크를 참고해 주세요.
지인호
이전 BIP를 올린지 어느덧 6일째, 제품에대한 시간을 별로 내지 못한 상황에서, 일단 BIP로그로 지금까지 한일부터 빠르게 정리하고자, 에디터를 켰어요.
지난주동안 한 일
최소한의 브랜드 리소스 만들기
챌린징 서비스에서 운영하는 스터디들과의 차별성 고민하기
메이커로그 원고 초안들 작성하기
플레이북 문서 생성하기 (작성하기 X)
다음으로 할 일
디스콰이엇 메이커분들께 스터디 운영에 참고할만한 팁 댓글로 듣기
플레이북 문서 완성하기
스터디 템플릿 작성하기
최소한의 브랜드 리소스 만들기
전에 이야기했던대로, 새로 생긴 제품에 대한 고민들을 정리해보고, 간단한 브랜드 리소스를 만들어봤어요.
우선 서비스명은 스터디와 개발(Dev)을 합쳐서 스터뎁으로 결정했어요.
예전에 해당 아이디어에 대해 임의로 붙인 가명이었는데 나름 괜찮은 것 같아서 그대로 사용했어요.
챌린징 서비스에서 운영하는 스터디들과의 차별성 고민하기
챌린징 앱에서 운영하는 스터디 같은‘유사 서비스’들과 어떤 차이점이 있는지를 고민해봤어요.
챌린징 서비스처럼 누군가가 운영을 도맡아서 하는 형태라면, 결국 챌린징 서비스에서 진행하는 일부 스터디만 잘 되는 스터디가 될 것 이고, IT 스터디들 모두의 질을 높이진 못할것이라고 생각했어요.
이에 대한 내용도 기회가되면 좀더 깊게 이야기해보려해요.
메이커로그 원고 초안들 작성하기
원페이저를 작성하면서 생각이 정리되는 경험이 상당히 좋았었어서, 원페이저를 어떻게 작성하였는지, 어떤 이점이 있었는지에 대한 경험을 공유하고자, 원고를 작성했어요.
생각보다 분량이 많아져서 시간날때마다 작성해서 메이커로그로 올리려해요.
플레이북 문서 생성하기 (작성하기 X)
여러 고민들을 통해, 제품에 대한 구체적인 형태가 얼추 보이면서, 실제 프로토타입(겸 MVP)을 만들어보려해요.
빠른 가설검증 및 VoC수집을 위해서 노션을 통한 플레이북과 템플릿을 만들고자, 우선 플레이북 문서부터 만들었어요.
아직 어떤 내용들이 들어가야할지 잘 생각이안나서 문서를 생성만 해둔 상태에요.
최대한 스터디를 처음 운영하는 사람의 입장에서, 큰 고민 없이 플레이북만으로 템플릿을 활용해 성공적으로 스터디를 운영할 수 있도록 해보자는 목적을 기반으로 컨텐츠들을 떠올리고있어요.
혹 이 글을 읽으시는 분들중에서 '스터디를 운영하면서 이런부분이 어려웠다.' 혹은 '스터디에 참여하면서 이런부분이 아쉬웠다.' 같이, 스터디 운영에 참고할만한 내용들이 있다면 언제든지 댓글 달아주세요! 🙇
앞으로 할 일
제품을 완성하는걸 다음 목표로 가져가려고해요.
다른분들의 의견을 참고하여 스터디 플레이북을 완성하고, 스터디 운영 템플릿을 빠르게 만드려고해요.
그렇게 최소한의 제품을 빠르게 완성하고, 스터디 예비 운영자분들께 여러 피드백을 받고자하고있어요.
스터뎁이 여러분께 도달하기까지 앞으로 많은 관심 부탁드려요.
글 읽어주셔서 감사합니다. 🙇
이홍열
많은 분들이 회사를 운영하기 전까지는 영업을 천시하는 경우가 있다. 한 여름에 밖에서 땀 뻘뻘 흘리면서 고객 만나고 왔더니 냄새난다고 노골적으로 싫어하는 직원들도 있었다. 전날 고객사와 4차까지 가서 옷도 전날과 같은 옷 입고 와서(사실은 속옷도), 오자마자 술냄새 풍긴다고 하고, 또 졸리기도 해서 눈치가 보여서 화장실에 2시간 동안 자다가(=사실은 거의 기절해서) 걸려서 쪼인트 까인 적도 있다.
중국 출장 갔더니 고객사놈들은 미팅은 하는 둥 마는 둥이고, 까오리빵즈(=한국인 하대하는 말)들 술실력을 알아보겠다고 11시부터 2시까지 멕인다. 그리고 오후 미팅은 술이 덜 깬 상태로 가서 어떻게 했는지 기억 안 나고 눈 뜨니 다시 술 집이다. 우리는 지사원까지 3명인데, 지들 인해전술로 10명 데려와서 또 바이주 50도짜리를 멕인다. 역시 까오리빵즈 술 잘 마신다고 하면서 원샷을 강요한다. 원샷하고 눈 뜨니 갑자기 우리 3명이서 한국인 술집에서 소주를 까고 있었다. 다시 눈 뜨니 이번에는 맥주집이었다. 다시 눈 뜨니 내가 나무를 짚고 토하고 있었다. 다시 눈 뜨니 침대였다. 다시 눈 뜨니 귀국하는 비행기 안이었다. 역시 중국 출장은 술로 시작해서 술로 끝난다.
영업은 어떻게 보면 참 지저분하고 가장 더러운 일들만 도맡아서 하는 거 같다. 고객 미팅에 가서 우리 회사 제품과 서비스를 비즈니스 웃음과 함께 설명을 한다. 고객은 하나도 관심이 없다. 듣는 둥 마는 둥. 그렇지만 이번 달 매출을 올려야 한다. 고객의 눈치가 보이지만 내 자존심을 높이면 영업이 실패하고 매출이 줄어든다. 고객과의 접점을 찾기 위해서 있는 아부 없는 아부를 떨어가면서 무관심속의 이야기를 이어간다. 그러다가 고객과의 접점을 찾아서 고객이 신나하는 것을 보면, 다행이다라는 생각을 하면서 그 동안 여기 저기서 들어왔던 이야기를 덧붙여 미팅을 끝낸다.
고객이 무리한 부탁을 한다. 말도 안된다. 그렇다고 딱 잘라서 안 들어 줄 수도 없다. 회사 담당자에게 일단 얘기는 해본다. 쓸데없고 말도 안되는 억지 부리지 말라고 한다. 그래도 매출로 연결될 수 있기에 커피와 밥과 술을 먹여가면서 이야기를 풀어 본다. 결국 다는 아니지만 일부를 들어준다고 한다. 고객에게 쪼르르 달려가서 이 이야기를 해 준다. 그럼 안 될 줄로 예상했던 고객도 놀라면서 계약을 해준다. 외부의 영업도 중요하지만, 내부영업도 중요하다. 내부에 기름칠을 하지 않으면 바깥 영업이 굴러가지 않는다.
항상 고객은 돈이 없다. CI(Cost Innovation = 비용 혁신)이라고 좋은 말로 포장했지만 결국 깎아달라는 이야기다. 견적을 할 때 버퍼를 좀 넣어놨는데 이 중 일부를 깎아준다. CI는 한 번에 안 끝는다. 도대체 몇 차까지 CI가 있는 것인가? 그래도 결국 우리가 마진이 좀 남는 수준에서라도 계약을 해 주면 양반이다. 진짜 사기꾼 같은 놈들한테 걸리면 끝이다.
우리는 항상 사기의 최전선에 있다. 비즈니스 세상에는 포장만 잘 된 사기꾼들이 득실득실하다. 영업은 이 들을 잘 발라내야(?) 한다. 무턱대고 모든 계약을 해서는 안 된다. 꽃뱀같은 놈들한테 한 건이라도 걸리면 최소 몇 개월에서 몇 년이 피곤해 진다. 나름 열심히 해서 매출 올리려고 했다가 괜히 회사 전체의 적이 되기 쉽상이다.
내가 책임져야 하는 우리 회사의 인력은 20명이다. 무슨 말이냐고? 내가 20억원의 매출을 올려야지 20명의 급여와 비용을 주고 회사가 운영될 수 있다는 뜻이다. 즉, 내 등에는 우리 회사 직원 20명이 항상 엎혀 있다는 것이다. 집에 가면 아내와 우리 귀여운 자식들이 내 등에 있지만, 회사에 출근하면 매출을 일으키지 않는 운영팀, 지원팀, 재무팀, 법무팀 등의 인력들이 내 등 뒤에 타고 있다는 것이다. 내가 영업을 포기할 수 없는 이유다. 내가 그 X 같은 상황을 다 견디는 이유이다. 내 성장을 원해서 영업하는 것보다 회사가 살아남아야 하고, 내 동료들이 마음껏 걱정없이 회사를 다닐 수 있기 때문이다.
직장을 다니셨다가 회사를 창업하신 대표님들께서 공통적으로 하는 말씀이 있다. 영업이 이렇게까지 중요한지 회사 다닐 때까지는 몰랐다. 그냥 제품과 서비스만 좋으면 영업은 그냥 자동으로 되는 줄 알았다고 한다. 그래서 한 때는 영업담당자들을 무시했다고 한다. 그렇지만, 본인이 직접 회사를 운영하게 되면 제품과 서비스보다 영업이 중요하다는 것을 체감하게 된다. 아무리 제품과 서비스가 좋아도 영업을 못 하면 매출을 올릴 수 없기 때문이다. 영업을 못 하면 그냥 못 하는 걸로 끝나지 않는다. 영업을 못 하면, 회사가 망한다.
우리가 이런 X 같은 상황속에서도 영업을 계속하는 이유는
우리 가족과
우리 동료들을
그리고 우리 회사를
지키기 위해서다.
영업의 기본과 뿌리 깊은 이야기를 강의합니다. 현재 영업스쿨 6기를 모집중입니다.
Lucy Seo
실전 사례로 보는 테스트 코드 도입
테스트 코드가 중요한 이유에 대해서 모두들 많이 들어봤을것입니다.
제가 생각하는 테스트 코드가 중요한 이유는 크게 3가지인데요.
테스트 코드가 중요한 이유
리팩터링 보장
- 리팩토링하면서 기존 기능에 사이드 이펙트가 없는지 확인할 수 있음문서화의 역할
- 특정 기능이 어떻게 동작해야하는지에 대한 예시를 제공, 새로운 개발자가 코드 베이스를 더 쉽게 이해할 수 있음버그 감지
- 개발 초기 단계에서 버그를 발견하고 수정하는데 도움을 줄 수 있음
- 모든 시나리오를 검증 할수는 없지만, 엣지 케이스에 대한 검증이 테스트 코드를 작성하면서 알 수 있음
테스트 코드 작성의 어려움
그렇지만 테스트 코드의 작성은 쉽지 않습니다. 왜 그럴까요?
저의 경우는 아래의 경우로 어려웠습니다.
테스트 코드를 작성하는데 시간이 너무 오래걸린다.
테스트 범위와 세부 사항을 결정하는게 어렵다.
2–1. 어디까지 테스트 해야 할것인가?
2–2. 무엇을 테스트 해야할것인가?
어렵다는 이유로 테스트 코드 작성은 미루어졌고, 그 과정에서 기획 변경 시 개발 구조를 크게 수정해야하는 문제가 있거나, 아니면 테스트를 하며 버그를 잡게 되는 경우가 빈번했습니다.
변화의 계기는 안드로이드팀 OKR 을 더 달성하고 싶은 마음으로 시작하게 되었습니다. 크래시를 예방하고, 크래시가 발생하더라도 재발 방지 하고싶은 마음으로 테스트 코드를 작성하게되었습니다.
안정적인 제품을 만들기 위해서 저희 팀은 BDD 스타일의 테스트 코드 작성에 정착하게 되었는데요. 이번 글에서는 kotest 를 사용하여 BDD 방식으로 테스트 케이스를 작성하는 경험을 공유하고 그 과정에서 제가 느꼈던 점들에 대하여 공유하고자 합니다.
BDD 란 무엇인가?
Full name 으로는 Behavior Driven Development 인데요. 한마디로 행동 주도 개발을 뜻합니다.
유저의 행동 기반을 바탕으로 사용자 시나리오를 구성하여 테스트 케이스를 작성하는 방법입니다.
여기서 말하는 사용자 시나리오는 각 기능의 요구사항이라고 생각하시면 됩니다.
테스트 코드 작성 과정
테스트 코드의 방식으로는 여러가지가 있지만, 이번 글에서는 Kotest 의 BehaviorSpec 을 이용한 방식을 예를 들어 보겠습니다.
BehaviorSpec 이란?
Given — When — Then 형태로 주어진 조건(Given) 에서 특정 행동(When) 을 했을때 기대하는 결과(Then) 를 나타냅니다.
Given : 환경 (ex : 유저가 비밀번호 변경 화면에서 )
When : 행위 (ex: 유효하지 않는 비밀번호를 입력하면)
Then : 기대결과 (ex : 비밀번호 변경 버튼이 비활성화 된다.)
테스트 코드가 기획서의 요구사항이나 사용자 스토리를 반영한다고 생각하시면 되고, 기획서의 요구사항의 경우의 수를 더 자세하게 표현할 수록 테스트 코드가 더 다양해 진다고 보시면 됩니다.
코드로 예시를 들자면 아래와 같은 형태입니다.
class ChangePasswordTest : BehaviorSpec() {
Given("비밀번호를 변경하려는 유저가") {
When("유효하지 않는 비밀번호를 입력하면") {
Then("비밀번호 변경 버튼이 비활성화된다.") {
}
}
}
}
}실제 프로젝트 작성 예시
출석 체크의 기능에 대해 예를 들어보겠습니다.
알라미의 출석 체크 기능은 ‘출석 체크 시작 후 알람 해제를 연속으로 5일 해제 했을때 출석체크가 완료’ 됩니다.
기존에는 출석 체크 완료의 기준이 연속 7일이였지만, 참여율을 높이기 위해 완료 기준이 5일로 변경되었습니다.
출석 체크 완료 날짜가 변경되었을 때 작성했던 테스트 코드의 예시를 들어 보겠습니다.
class WakeUpCheckChallengeViewModelTest : BehaviorSpec() {
Given("유저가 출석체크 진행중이면") {
val staredTime = LocalDateTime(2023, 1, 1, 8, 0)
val fakeWakeUpCheckChallengeRepository = FakeWakeUpCheckChallengeRepository(
wakeUpCheckChallenge = ChallengeCheck(
status = ChallengeStatus.PARTICIPATING,
startedTime = staredTime.toEpochMilliseconds(),
dismissTime = 0L,
successCount = 2
),
)
When("출석 체크의 성공 날짜 기준은") {
val expectedSuccessCount = fakeWakeUpCheckChallengeRepository.getSuccessCount()
Then("7이다") {
expectedSuccessCount shouldBe 7
}
}
When("출석 체크 실패 후") {
fakeWakeUpCheckChallengeRepository.failed()
Then("출석 체크 성공 횟수는 5로 초기화 된다.") {
val expectedSuccessCount = fakeWakeUpCheckChallengeRepository.getSuccessCount()
expectedSuccessCount shouldBe 5
}
}
}
}
}위 테스트 코드를 작성하면서 저는 테스트 코드의 장점에 대해서 실감 할 수 있었습니다.
테스트 코드의 장점
알람을 실제로 울리지 않고도 기능에 대한 검증을 할 수 있다.
엣지 케이스에 대한 테스트를 해볼 수 있다.
ex) 기존에 출석체크를 5일 이상 진행한 유저가 있을때는 성공 날짜 기준을 무엇으로 잡을 것인가?
만약 테스트 코드를 작성하지 않았더라면, 기능에 대한 테스트를 매번 알람을 울리면서 테스트 하였거나 혹은 엣지 케이스에 대한 경우를 뒤늦게 확인했을것 같아요.
결론
기존에는 테스트 코드 작성이 더 오래 걸려서 비효율적이다라는 막연한 생각으로 테스트 코드를 멀리하게 되었는데요.
하지만 실제로 테스트 코드를 작성해보면서 테스트 코드가 중요한 이유에 대하 실감하게 되었습니다.
리팩토링 지원 : 기존 기능을 리팩터링 할때 자신감이 생김
문서화의 역할 : 출석체크 완료 기준이 7일에서 5일로 변경되었구나, 테스트 코드를 보며 알 수 있음
버그 감지 : 테스트 코드를 작성하며 예외 케이스에 대한 고민을 빨리 체크 할 수 있음
테스트 가능한 구조에 대한 고민 : 테스트 코드를 작성하면서 dependancy 가 덜한 코드에 구조에 대한 고민을 하게 됨
빠를 수록 돌아가라는 말이 있는데요, 테스트 코드 작성하면서 그런 경험을 할 수 있었고, 변화에 유연한 설계가 되어가고 있다고 느낄 수 있었습니다.
한번에 완벽한 테스트 코드를 작성하려고 테스트 코드를 작성하지 않는것 보다, 테스트 코드를 작성하면서 테스트 코드에 대한 고민과 더 좋은 테스트 코드를 작성하기 위해 노력하는것이 더 중요하다
한마디로 완벽한 첫 삽을 위해 시도 하지 않는 것 보다, 지속적인 노력이 더 중요하다는 사실입니다.
테스트 코드에 대한 도입에 대한 고민을 하고 계시다면, 어떤 점이 고민인지 정의 해보시고 실제로 작게나마 테스트 코드에 대한 작성을 해보시면서 그 고민이 정말인지 확인해보시는것을 추천드립니다.
🙌딜라이트룸의 다양한 채널들을 팔로우하고 빠르게 소식을 받아보세요!
지금 바로 미디엄 팔로우하고 다음 아티클도 빠르게 만나보세요!
박주혜
건강한 메이커의 삶을 살기 위해서 주말 루틴을 바꿔보고 있습니다.
9:00~10:00 | 기상 및 청소, 빨래 + 그래놀라/요거트 아침밥
10:00~11:00 | 운동 to 운동
11:00~18:00 | 작어-업 + 브로콜리 점심밥
18:00~20:00 | 맹작어-업 + 양배추 닭가슴살 쌈 저녁밥
20:00~21:00 | 운동 to 운동
21:00~24:00 | 마지막 자거어어업-
김주형
근면성실 스터디 환경 구성에 대해 고민했습니다
오리엔테이션을 준비하며 실시간 참여가 어려운 경우에도 추후 확인 가능한 문서와 영상을 준비해야 함을 발견했습니다
어떻게 해야할지 방법을 찾는데 오전 시간을 조금 사용했습니다
그냥 최고 말고 세계 최고가 될 수 있는 일은 무엇인지 고민하는데 하루를 쓴 결과
함께 자라기라는 근사값을 얻었습니다열심히 해봤자 결국 망할 거라는 생각에 정말 어처구니가 없지만 그럼에도 불구하고 점심 시간에 맛있는 음식을 사서 가족과 나눠먹고 카페에 가서 스몰토크를 하고 왔습니다
스톡데일 패러독스 상태이거나 자기기만인 것 같다고 생각해보고 있습니다
남는 시간엔 인강을 듣고 클린 코더라는 책을 읽고 집에 갈 준비를 했습니다
1일 1커밋을 해야하나 고민하다 그냥 쿨하게 집에 가려고 합니다
의도적으로 하는 것도 좋지만 저절로 일으키는 상황을 만드는 것을 더 고민하고 있습니다
준프
Shift Left Testing이 어떻게 버그, 시간 그리고 돈을 아낄까?
이번에 소개해드리는 글은 Shift Left Testing이 무엇인지 소개하는 글입니다. 사실 그보다는 제품을 만드는 과정에 대해 거시적으로 살펴볼 수 있도록 합니다. 이 내용이 도움이 되었다면 함께 일하는 동료와 논의해보는 것도 정말 좋을 것 같습니다.
버그의 책임은 누구에게 있는가?
이 글은 가장 먼저 제품에서 발생한 버그의 책임은 어디 그리고 누구에게 있는지 간단하게 알아봅니다. 사실 이 문장에서 조금 뜨끔한 포인트가 있습니다. 제품을 개발하는 과정 마지막에 제품이 정상적으로 동작하고 기대한 동작을 하는지 검증하는 과정(QA)이 있다면 코드를 작성하면서 은연중에 아래와 같이 생각한다는 것입니다.
"마지막 검증 과정에서 중요한 버그는 발견되고 이후 수정 기간에 수정하겠지"
하지만 이렇게 했을 때 결과는 그리 유쾌하지 않습니다. 아래는 검증 과정에 강하게 의존하면 발생하는 문제에 대한 제 생각입니다.
신뢰가 떨어집니다. 이러한 태도는 좋지 않은 질을 가진 코드를 생산해냅니다. 그리고 마지막 검증 단계에서 발견되는 버그의 갯수가 감소하지 않습니다. 결국 다른 구성원이 개발자를 신뢰하지 못하는 문제가 발생합니다.
시간과 돈이 많이 듭니다 1. 신뢰가 낮다면 비용은 증가합니다. 개발자가 만든 코드에 대한 신뢰가 낮기 때문에 검증 시간과 인력이 많이 듭니다.
시간과 돈이 많이 듭니다 2. 배포 하기 전 마지막 단계에서 하는 검증이기 때문에 이 때 발견된 버그는 수정할 시간이 부족하고 급하게 처리하다보면 또 다른 버그를 만들어내기 마련입니다. 만약 버그를 고치지 못했다면 제때 배포하지 못하고 다음 스프린트로 넘어갑니다.
그리고 이 글에선 아래와 같이 강조합니다.
The quality of the code is a shared responsibility among the entire team.
좋은 결과물에 대한 책임은 마지막 검증 단계, 개발자 등 특정 단계나 팀의 책임이 아닙니다. 각자가 자신의 책임이라 생각하는 태도가 중요합니다.
Shift Left Testing이란?
따라서 마지막 단계에 의존하는 검증이 아니라 개발 과정의 왼편(Left)으로 검증(Test) 과정을 이동(Shift)시킴으로써 더 나은 방법의 검증을 해야 한다고 강조합니다.
Shift Left Testing에 대해 저자는 아래와 같이 소개합니다.
Shift left testing means focusing on testing from the very beginning when we start thinking about how to approach a task.
이 방법의 자세한 수행 방법을 요약하면 아래와 같습니다.
자세한 인수 조건(acceptance criteria)
관계된 모든 구성원이 인수 조건을 파악함
개발자는 마지막 검증 단계 전에 반드시 테스트를 해야함
개발 과정에서 PM과 검증 팀으로부터 지속적인 피드백
이 방법은 실제로 업무를 하며 개선해나가는 과정과 닮아 있어 더욱 공감이 됐습니다. 이 방법을 처음 도입하거나 도입하는 중이지만 잘 안 된다면 아래 세부 내용을 살펴보는 게 도움이 되리라 생각합니다. 이 내용은 제가 추가한 내용입니다.
PM 또는 모든 괸계자는 자세한 인수 조건을 준비하고, 개발자는 인수 조건에 따라 개발해야 합니다. 이 글에서 소개한 것처럼 준비하는 것만으론 충분하지 않습니다. 때로 이 과정은 매우 번거롭고 힘듭니다. 저 처럼 덤벙대는 성격을 가진 사람이라면 더욱 그렇습니다. 하지만 훈련해야 합니다.
인수 조건이 자세하게 준비되어야 하는 이유는 버그는 코드로부터 나오는 것 뿐만 아니라 애초에 잘못된 인수조건에서 나올 수 있기 때문입니다. (이 글에서도 이 부분을 강조하고 있습니다.)
보통 전문 QA 팀이 있지 않은 조직에선 모든 관계자가 함께 검증을 합니다. 그렇기 때문에 더욱더 인수 조건을 모두 파악하고 있어야 합니다. 그래야 발견하지 못한 문제 케이스를 발견할 수 있습니다.
개발자는 마지막 검증 단계 전 반드시 테스트를 해봐야 합니다. 여기엔 단위 테스트, 개발자 간의 테스트 등을 포함합니다. 이 방법은 마지막 검증보다 비용이 낮고 속도가 빠릅니다.
시작부터 마지막 단계까지 지속적으로 피드백을 주고받아야 합니다. 왜냐하면 우리 모두 사람이기 때문에 각 과정에서 문제를 발견할 수 있기 때문입니다.
지속적인 피드백과 개선이 필요하려면 변경에 유연한 코드를 작성해야 합니다. (이 역시 소개한 글에서 강조하고 있습니다.)
더 자세한 내용은 소개해드리는 글을 참고해보시는 걸 권해드립니다. 위 내용을 더 자세하게 설명하는 것 뿐만 아니라 실제 적용 결과를 공유하고 있기도 합니다.
뿐만 아니라 테스트와 관련해 이전에 공유해드린 '테스트는 센서다'라는 글을 다시 공유드립니다.
Ash
"망한 프로젝트를 치유할 수 있을까?"라는 질문에서 시작한 컨텐츠입니다.
노션을 쇼핑몰로 만들면 어떨까?
노션을 블로그 또는 개인사이트로 만들어주는 서비스는 외국에서도 국내에서도 꽤나 인기를 끌었습니다.
노션과 관련된 사이드 비즈니스를 고민하다가 카페24나 아임웹처럼 바로 쇼핑몰을 만들 수 있으면 좋은 점들이 있겠다고 생각했습니다.
첫째로, 고객은 카페24나 아임웹보다 훨씬 쉽게 자사몰을 얻을 수 있습니다.
둘째로, 실제로 돈이 오고가니 수수료 비즈니스를 할 수 있습니다.
그래서 노션 Properties를 가지고 컨트롤 할 수 있는 쇼핑몰 페이지를 만들었습니다.
기능 개발은 아주 순탄했습니다. 기능자체가 어려운 부분은 거의 없었기 때문입니다.
근데 막상해보니 오히려 막힌 곳은 결제를 어떻게 받아야하지? 였습니다.
결제를 받는 모델은 크게 쿠팡이나 11번가 같은 오픈마켓처럼 결제를 대신 받고 나중에 정산해주는 방법과 각자의 PG를 달아주는 카페24 같은 모델이 있는데요.
각자의 PG를 달아주는 모델은 이 '노샵(가제)'이라는 모델이 편하게 자사몰을 갖는 모델인데, 편하게 쓸 수 있는 모델이 아니라고 생각했습니다.
그런데 막상 오픈마켓처럼 결제를 대신 받자니 세무에 약한 내가 잘 해낼 수 있을까라는 고민이 들어서 결국 개발 도중에 흐지부지하고 내렸던 기억이 나네요.
벌써 1년전에 만들었던 프로젝트인데, 그 사이에 리틀리에서도 샵을 만드는 기능이 생겼군요. 토스도 간편하게 몰을 만들 수 있게 되었구요.
여러분이라면 어떻게 진행하셨을 것 같은가요?
저는 혼자서는 이렇게 쫄보라 종종 같이 할 친구가 있으면 좋겠다는 생각도 드네요.
앞으로는 혼자서 고민하다가 흐지부지 하지 말고 Building In Public으로 진행해서 도움을 받을 수 있는 부분은 받을 수 있는 사람이 되면 좋겠습니다.
오늘도 좋은하루 되세요 :)
한수아 Sua
포포리가 적은 리소스로 유저 이탈률과 신뢰도를 방어하는 방법
라고 하고 앱/웹 오류 시 적합한 안내 문구 작성하는 방법이기도 합니다.
가볍고 재밌게 즐겨주시면 감사하겠읍니다!
0. 이 방법, 왜 생각하게 되었나요?
ㅋㅋ 혼란의 포포리 카톡방..
토큰기간(7일) 만료 후 앱에 진입했을 때, 기존 리프레시 토큰으로 새로운 액세스토큰이 요청되지 않아 첫 화면에서 정보를 불러오지 못하는 이슈가 생겼거등요😭
이게 무슨소리냐면,
로그인한지 일주일이 지난 유저가 앱을 눌러 첫 화면을 보게 되었을 때 아무것도 안보인다는 뜻입니다. (심각)
앱에 들어왔는데 아무것도 안보이면 어떻게 될까요?
간단합니다, 앱을 안쓰게 되겠죠.
물론 [마이]탭을 누르거나, 다른 버튼을 누르면 새로 API를 호출하기 때문에 유저의 정보가 그때 불러와지게 됩니다.
하지만 그건 앱을 만든 우리 팀 정도나 알지, 유저는 모르거든요.
이렇게 별거 아니게 말하고 있지만 굉장히 심각한 문제였습니다,,,🥺💦
개발팀과 대책 회의를 통해
초반에 서버를 연결하는 과정에서 로직이 꼬인 상황이었고 '쉽고 가볍게 수정할 수 있는 이슈가 아님', '약 일주일 소요'의 결론을 낼 수 있었습니다.
자 이제 기획자인 저는 개발팀이 본질적인 이슈를 해결하는 일주일 동안,
임시방편(?)으로나마 떠나는 유저를 붙잡을 방법을 강구해내야 했습니다.
[방법1] 서버/클라이언트/외부 중 선택
문제상황이 발생한 부분, 해결 할 수 있는 부분을 가장 먼저 해결해야 합니다.
a. 서버 단에서
b. 클라이언트 단에서
c. 외부 플랫폼을 통해(SMS 안내, 사이트 공지 등)
[방법2] 적절한 안내문구 생각하기
고객의 언어로 친절하게 간결하게 작성해야 합니다.
어떠한 상황에서도 유저에게 책임을 전가하지 않아야 합니다. but 너무나 우리 서비스의 잘못임을 드러내지 않아야 합니다.
예를 들어,
이런 기술적인 문제, 오류 발생 등의 표현 or 난데없는 오류코드 공유 등은 사용자가 현재 상황을 스스로 해결할 수 없는 문제로 인식할 가능성이 높습니다.
또한 문제가 발생한 원인을 정확히 알 수 없어 곧바로 해결책을 찾을 수 없는 문제점도 존재합니다.
오류 상황이 일어나지 않는 것이 가장 좋지만, 일어날 수 있는 상황이라면 사용자가 현재 상황을 벗어날 수 있도록 도와줘야 합니다. 적어도 현재 일어난 오류를 정확히 안내하는 것이 중요하며, 해결 방법을 같이 제시해주면 더 좋습니다.
[방법3] 현재 상황을 잘 안내하고, 구체적인 행동을 안내/제공
단순히 상황을 알려주는 것이 아닌, 이 문제상황을 해결할 수 있는 방법 또는 액션을 제공해야 합니다.
예시)
a. 서비스를 사용할 수 없습니다
b. 이러이러한 이유로 서비스를 사용할 수 없습니다 (이유 제시)
c. 이러이러한 이유로 서비스를 사용할 수 없습니다, 이런 방법으로 해결해보세요(이유 + 안내 제공)
d. 이러이러한 이유로 서비스를 사용할 수 없습니다, 이렇게 해결해드릴게요(이유 제시 + 방법 제공)
이 중에서 d가 가장 이상적인 방법입니다.
이해를 돕기 위해 예시를 준비했습니다 짜잔-
네트워크가 연결되지 않아 서비스를 이용할 수 없는 상황이라면, 이 중 어떤 화면을 보여줘야 할까요?
포포리 서비스의 특성 상, 네트워크가 연결되지 않으면 앱 내의 기능을 보여줄 것이 없어 반드시 연결이 필요합니다. 그렇기 때문에 유저가 네트워크 상태를 확인할 수 있는 구체적인 행동을 하도록 유도해야 합니다.
텍스트로 방법을 안내할 수도 있지만, 조금 더 친절하게 느낄 수 있도록
새로고침 / 설정(Wi-Fi)으로 이동 두 가지의 행동을 안내하는 것이 가장 좋은 솔루션이라고 생각했습니다.
사용자에게 ‘서비스를 사용할 수 없음’을 안내, 그 이유가 ‘네트워크 오류’ 때문일 것이라는 판단을 제공, 그리고 특정 버튼을 활용해 새로고침을 해보거나 설정 화면으로 이동할 수 있는 기회를 제공하기 때문입니다.
종합하면 현재 상황을 안내하고, 구체적인 행동을 안내/제공함으로써 UX를 개선하고, 소중한 유저를 지킬 수 있습니다.
요약해보자면!
해결할 방법 정하기 : 문제 발생 위치, 문제 해결 위치를 고려한 안내 방법을 생각합니다.
명백하고 정확하게 작성하기 : 사용자가 현재 상황을 명확하게 인지할 수 있어야 합니다.
원인 알려주기 : 오류가 발생한 분명한 이유를 안내해야 합니다.
쉽게 쓰기 : 내부에서 사용하는 전문적인 용어는 사용자가 이해하기 어렵습니다. 고객의 언어로!!
간결하게 쓰기 : 핵심을 담아 최대한 깔끔하게 전달해야 합니다.
서비스의 특성 고려하기 : 서비스 고유 분위기를 고려하지 않으면 가볍게/불친절하게 느껴질 수 있습니다.
해결을 위한 방법 제공하기 : 상황을 벗어날 수 있는 방법을 안내/제공해야 합니다.
포포리에 적용하기
그래서 포포리에는 어떻게 적용했을까요?
1. 해결할 방법 정하기
포포리의 경우, 현재 토큰기간이 만료된 상태에서 앱에 들어오면 앱이 서버와 연결되지 않았기 때문에 서버를 통한 방법은 적절하지 않았습니다.
모든 유저의 개인정보를 갖고 있지 않았기 때문에 유저에게 안내 메시지를 보내는 것 또한 어려운 상황이었습니다.
즉, 앱에 들어오는 유저에게 즉각적으로 대처해야하기 때문에 클라이언트 내에서 해결해야 한다고 판단했습니다.
첫 화면에서 오류가 발생했을 경우 어떤 방식으로 안내해야할지 고민이 있었습니다.
기존에는 오류 상황 발생 시에는 full 화면으로 안내하고 있었지만, 이번 이슈의 경우 유저가 앱에 접속한 첫 화면에서 만나는 이슈이기 때문에 full 화면이 먼저 뜨면 서비스의 안정성에 대한 의심을 크게 느끼게 될 것이라 생각했습니다.
오류 안내를 full화면으로 진행할 때,
a. 앱을 사용하던 중 오류 상황이 발생함 > 오류 페이지 노출
b. 앱에 들어감 > 오류 페이지 노출
b의 경우 서비스에 대한 신뢰를 잃고 이탈할 가능성이 더 높아진다고 판단했기에,
최대한 이탈률을 줄이고자 기존 화면 위로 dim처리를 하고 팝업으로 문제상황과 해결방법을 안내하고자 했습니다.
2. 적절한 안내 문구 작성 + 구체적인 행동을 제공
유저의 상태와 관련 없는 오류였기 때문에, 새로고침을 통해 api를 호출하면 바로 홈 화면을 불러올 수 있었습니다.
개발적인 오류였기 때문에 현재 상황에 대한 안내를 어떻게 해야할지 고민했습니다.
팝업이었기 때문에, 최대한 간결함이 중요했고 문제 /발생이유의 내용은 생략하였습니다,
- 문제 설명 > '화면에 정보를 불러오지 않음'의 문제를 유저가 이미 시각적으로 인지함
- 문제가 발생한 이유 설명 > 유저가 해결할 수 있는 문제가 아님 (유저에게 중요하지 않음)
대신, 확실히 해결할 수 있는 방법을 제시하여 유저가 최대한 빨리 문제를 벗어나 서비스를 사용할 수 있도록 했습니다.
지금은 모두 해결된 상태이기 때문에, 앱에서 이 팝업을 만나실 일은 없쥐만!!!!!!!
로직을 수정하는 일주일 간 포포리만의 '적은 리소스로 유저 이탈률과 신뢰도를 방어하는 방법'에 대해 설명드렸읍니다,.
포포리 v1.3.0 업데이트 소식을 슬쩍- 전해드리며!
앞으로도 더 발전하는 포포리가 되겠습니다💜
짱 쉽게 공유하고 짱 오래 보관하는 내 손 안의 모바일 네컷앨범,
포포리가 궁금하다면?
포포리 pophory
짱 쉽게 공유하고 짱 오래 보관하는 내 손 안의 모바일 네컷앨범