김우정
OTT 오딧세이 2번째 연재입니다. 넷플릭스의 오리지널 드라마 ‘하우스 오브 카드(House of Cards, 이하 카드)’를 윌리엄 셰익스피어의 비극 ‘리어왕(King Lear, 이하 리어)’을 통해 분석했습니다. 2022년 11월, 넷플릭스는 기존 요금제보다 저렴한 광고형 멤버십을 출시했습니다. 이 요금제로는 ‘하우스 오브 카드'를 더 이상 시청할 수 없습니다. 그 흥망성쇠의 스토리를 만나보세요.
아티클
John
어쩌다 보니 PM 없이 메이커만으로 구성된 팀으로 신사업을 진행하게 되었습니다. 디자이너와 FE, BE 개발자 3명이 1달 반 동안 어디까지 갈 수 있었을까요? 지금부터 그 후기를 공유드리겠습니다.
새로운 시작
2024년 새해의 시작과 함께 새로운 팀과 새로운 프로젝트가 시작되었습니다. 역시 언제나 그렇듯이 예상대로 흘러가는 것은 아무것도 없습니다. 새로운 팀에 함께 하기로 했던 PM 분이 퇴사하게 되면서 저희는 PM 없이 신규사업을 진행할지 선택해야 하는 상황이 되었습니다.
과연 메이커만으로 구성된 팀의 장점과 단점은 무엇일까요?
장점: 빠르게 개발할 수 있다. 개발한 실제 결과물을 가지고 피드백을 수집해서 개선해 갈 수 있다. 모든 사람이 기획과 의사결정에 조금 더 깊이 참여하게 된다.
단점: 모두의 의견을 듣고 중심을 잡아줄 사람이 없다. 의사결정 과정에서 누군가가 명확하게 결론을 내기가 어렵다. 자신의 전문 영역 밖의 영역들도 같이 고민하고 시간을 투입해야 한다(비즈니스 모델, 마케팅 등).
이러한 장단점을 모두 고려한 결과 저희는 그래도 저희끼리 한 번 갈 수 있는 데까지 가보기로 하였습니다.
한계 파악하기
적은 시간(3개월)과 리소스를 이용해서 하나의 서비스를 만들기 위해 먼저 가능한 범위에 대해 파악해 보았습니다. 우선 아이템 선정과 관련된 제약사항을 먼저 파악해 보았습니다.
아이템: 적은 노력으로 큰 파급력을 얻을 수 있는 분야
할 수 있는 아이템: 소셜, 커뮤니티, 유틸, 플랫폼, ...
하기 어려운 아이템: 제조, 유통, 커머스, 협상이 필요한 B2B, ...
역시 원천기술이 필요하거나 물건을 직접 판매하는 등의 아이템은 저희에게 적합하지 않다고 판단하였고, 커뮤니티와 같이 많은 사람이 모이는 곳을 만들고 이 안에서 가설들을 테스트하기로 정하였습니다.
다음으로 구체적인 업무에서의 한계에 대해서 고민해 보았습니다.
기획 및 프로젝트 진행 방법: 구성원이 이해하기 어렵지 않으면서도 유연함과 일관성을 가질 수 있는 방법
쉬운 방향: 피드백 루프, MVP, 애자일
어려운 방향: 치밀한 비즈니스 모델 설계, 대규모 waterfall
기술: 기술적으로 개발 가능한 분야
개발 가능한 분야: 간단한 웹, 간단한 앱, 커뮤니티, 사진 및 글 업로드
개발이 부적합한 분야: 자체 데이터로 학습이 필요한 AI 관련 아이템, 기술적 난이도가 높은 기능
디자인: 적은 노력으로 큰 효과를 낼 수 있는 아이템
효율적인 아이템: 재사용 가능한 디자인, 확장 가능한 디자인
비효율적 아이템: 지속적으로 컨텐츠 추가가 필요한 아이템
이를 종합하여 다음의 목표를 도출하였습니다.
소셜 분야에서 간단한 웹 서비스를 피드백 루프와 MVP 방법론을 이용해서 빠르고 효율적으로 개발한다.
팀 전략 세우기
팀이 앞으로 나가기 위한 전략으로 가장 크게 참고했던 방법은 피드백 루프(Feedback Loop)와 MVP입니다.
피드백 루프
피드백 루프는 Build -> Measure -> Learn 과정을 반복하면서 초기 아이디어를 검증해가는 방법으로 저희가 지켜야 할 큰 틀이라고 생각했습니다. 먼저 최초 아이디어를 빠르게 웹으로 만들어서 출시하고(Build), 수집된 결과(Measure)를 통해 앞으로 만들 기능에 대한 힌트를 얻는(Learn) 방식으로 프로젝트를 진행하였습니다. 이러한 루프를 3개월 안에 최소 2회 완주할 수 있도록 목표를 설정하였습니다.
niceideas.ch: The Search for Product-Market Fit
MVP
다음으로 참고했던 방법론은 MVP(Minimum Viable Product)입니다. MVP란 용어는 이미 많은 곳에서 자주 사용되고 있지만 모호한 의미로 사용되는 경우가 많은 것 같습니다. 저희 팀은 이번 기회에 MVP의 M과 V가 무엇을 의미하는지 집중해 보기로 하였습니다.
Minimum: 제품이 가져야 하는 최소한의 기능. 이를 지키지 못하면 사용할 수 없는 조악한 결과물이 됩니다.
Viable: 제품의 생존 능력. 너무 약하면 생존하지 못하며 너무 과하면 규모만 크고 효율이 떨어지는 제품이 됩니다.
niceideas.ch: The Search for Product-Market Fit
결론적으로 저희는 MVP를 M과 V 사이의 외줄 타기로 정의했습니다. 또한 MVP는 아래 그림처럼 바퀴만 만들고 끝나거나 최종 결과물과 완전 다른 제품을 만드는 것이 아니라는 점도 팀 안에서 확실하게 인식을 맞추고 시작하였습니다.
Fred Voorhorst - Expressive Product Design
아이템 선정하기
사실 가장 고통스러운 과정은 바로 아이템을 선정 과정이었습니다. 만약 시장 분석 전문가가 팀에 함께했다면 현재 한국이나 미국에서 가장 유망한 아이템을 분석해서 빠르게 카피하는 방식으로 접근하는 것이 성공 확률을 가장 높일 방법일 것입니다. 그러나 저희는 그렇게 트렌드에 대한 레이더를 체계적으로 가동하기 어렵다고 판단했습니다. 따라서 저희 주변을 기준으로 필요할 만한 것들을 생각해 보았습니다.
실제 내 삶에 도움이 되면서 (Feasibility)
친구들과 같이 사용이 가능한 (Desirability)
오래 남을 아이템 (Viability)
About Product/Market Fit — what I’ve learned about the goal, the process and the nuance
먼저 며칠 동안 계속해서 브레인스토밍을 진행하였고,
위 과정을 통해 키워드 3개를 도출하게 되었습니다.
일정
그룹
사진
이를 조합하여 설정한 첫 번째 아이템은 다음과 같습니다.
아이템: 친구들과 함께 사용하는 카카오톡 그룹 채팅방을 하나의 서비스로 분리해 일정과 사진을 공유하는 서비스를 만들어 보자
문제:
카카오톡은 그룹만을 위해 만들어진 것은 아니므로 여러 가지 불편한 점들이 있다.
시간이 지나면 단톡방의 사진이 사라진다.
일정 투표 시에 응답 현황 등이 보여 눈치가 보인다.
채팅 내역이 많아지거나 사진과 뒤섞이면 이전 내용을 찾기 어렵다.
해결방안:
그룹 일정 관리와 사진 저장에 특화된 서비스를 만들자
사진을 영원히 남길 수 있도록 한다.
일정에 특화된 다양한 기능을 제공한다.
기존 채팅 방식과 다른 캘린더 피드 등을 제공한다.
그러나 처음부터 완전한 제품을 만들어 테스트하기는 어려울 것으로 보였습니다. 따라서 3개의 키워드 중에서 일정 부분만 웹을 통해 간단히 테스트해 보기로 합니다.
첫 번째 루프
서비스 만들기 (Build)
사실 메이커로 구성된 팀이 가장 신나는 시점이 바로 만드는(Build) 단계라고 생각합니다. 디자이너가 전체 서비스 구조를 설계하는 과정에서 API를 설계해야 하는 백엔드 개발자와 함께 논의하고, 최종 시안이 나오기 전에 프론트엔드 개발자는 먼저 스타일을 제외한 컴포넌트 개발을 진행해두는 식으로 빠르고 유연하게 작업하였습니다. 만약 PM이 있었다면 모든 과정을 조율해 주었겠지만, 저희는 그런 사치를 누릴 수 없었기에 앉은 자리에서 서로가 완벽하게 이해될 때까지 빠르게 의사소통하였습니다.
긴밀하게 서로 한자리에 모여 개발하면서 추가되면 좋을 것 같은 기능을 자유롭게 제안하였고 이를 통해 제품을 더욱 구체화할 수 있었습니다. 또한 서로 우려되는 부분을 미리 체크해 주기도 하면서 각 담당자가 체크하기 어려운 빈틈을 메꿔주기도 하였습니다.
이러한 과정을 거쳐 처음으로 만든 결과물이 바로 OURR(Our Record)입니다.
링크 → OURR.io
2주 동안의 작업 결과 일정을 만들고 초대장을 생성해서 친구들에게 참석 여부를 확인하는 서비스를 개발하였고 참여 인증샷도 남길 수 있도록 하였습니다. 마케팅 관련해선 먼저 사용자 인터뷰 대상자들을 모집하였고 서비스에 대해 알려드린 뒤 주변 사람들에게도 일정을 공유하도록 유도하였습니다.
그렇다면 결과는 어땠을까요?
1주일 데이터 종합 결과 (Measure)
(SignUp) 총 207명이 서비스에 접속하였으며
이 중에서 106명이 로그인 창을 열었고
다시 이 중에서 60명이 가입에 성공하였습니다.
(Activation) 가입한 사람의
58.6%는 일정 참석 여부에 응답하였습니다.
41.4%는 일정 캘린더 추가 버튼을 클릭하였습니다.
34.5%는 초대장을 만들었고 같은 비율로 이를 공유하였습니다.
8.62%만 인증샷을 실제로 업로드 하였습니다.
(Event) 생성된 일정은 총 62개로 1명 당 약 1개 일정이 생성되었으며
이에 대한 참석 여부 응답은 177건 발생하였습니다.
참석 138건, 모름 23건, 거절 16건.
(Retention) 가입 이후에 다시 돌아온 사람은
다음날 10% 였습니다.
그다음 날은 8% 였습니다.
첫 루프의 결과로 판단할 수 있는 것은 무엇이었을까요?
데이터를 통해 알 수 있었던 점 (Learn)
데이터를 통해 다음 인사이트를 얻을 수 있었습니다.
회원가입 방식에 따라 사용자가 이탈하는 비율이 엄청나게 달라질 수 있다는 것을 확인하였습니다.
초반에 알림 문자 발송을 위해 전화번호 가입 방식만 지원하였으나 절반 이상이 이탈하였습니다.
카카오 로그인을 추가한 이후 이탈 유저가 훨씬 감소하였습니다.
일정을 만들고 공유로 이어지는 부분에 대한 설계 및 측정이 부족하였습니다.
일정을 만들고 공유를 통해 다시 다음 가입자를 모집해야 서비스가 자연스럽게 확장될 수 있었습니다.
생각보다 일정 생성 이후 공유하기 버튼을 클릭하는 경우가 적어서 critical path에 대한 점검을 하게 되었습니다.
정확한 데이터 측정을 위해 초대코드를 함께 보내도록 수정이 필요하다는 것을 알게 되었습니다.
생각보다 인증샷 올리기 기능을 잘 이해하지 못한 사용자들이 많았습니다.
실제로 사진을 업로드 한 사용자는 10%도 되지 않았습니다.
자연스러운 흐름에 따라 특정 행동이 발생하도록 기능을 설계해야 한다는 점을 확인하였습니다.
지금까지의 데이터 결과를 보면 생각보다 적극적인 행동이 발생하진 않은 것으로 보입니다. 이탈 비율도 높고 공유도 많이 발생하지 않았으며 서비스를 다음 날 다시 방문하지도 않았기 때문입니다. 그렇다면 이제 서비스를 버리고 처음부터 다시 시작해야 할까요? 아니면 여기서 다시 문제점을 찾고 보완하기 위한 가설을 세우고 앞으로 나아가야 할까요?
저희 팀은 일단 현재 상태에 대한 가설을 만들어 보기로 하였습니다.
1. 만약 일정 기능 자체는 사용자에게 중요하지 않다면?
이미 구글 캘린더나 카카오 일정 등을 편하게 잘 이용하고 있어서 별도의 서비스를 사용할 니즈가 없다.
그렇다면 일정 관련된 기능은 아무리 잘 만들어도 사용하지 않을 것이다. → 아이데이션으로 돌아가기
2. 만약 일정 관련해서 아직 발견하지 못한 다른 니즈가 있다면?
사실 일정을 고르고 초대하고 조율하는 부분을 더 편하게 하고 싶다.
그렇다면 기능을 보완해서 조금 더 필요한 기능을 찾는다면 많이 사용될 것이다. → 기능 개발로 돌아가기
3. 만약 현재 상태의 기능도 충분히 원하는 사용자들이 있지만 아직 그들에게 도달하지 못했다면?
만약 이런 서비스가 있다는 것을 알고 있다면 충분히 사용해 볼 만 하다.
그렇다면 서비스를 알리는 채널을 늘리고 더 멀리 퍼뜨리면 많이 사용할 것이다. → 현재 상태에서 마케팅 보완하기
위 가설 중에서 한 가지를 선택하기로 하였고 가설을 토대로 얼마나 다시 시작할지를 결정하기로 합니다. 이제 여기까지가 첫 루프의 Build-Measure-Learn의 결론입니다. 역시 한 번에 대박이 나는 경우는 없었습니다. 비록 좋은 결과가 나오지는 않았을지 몰라도 앞으로의 방향을 결정할 수 있는 단서는 찾았다고 생각합니다. 다음 루프에선 배운 내용을 반영해서 더 나은 제품이 만들어질 것입니다.
결론
지금까지 팀이 한 번의 루프를 완료하기까지 겪었던 일들을 적어보았습니다. 여기까지 오는 것도 힘들지만 이 과정을 무한 반복한다고 생각하면 막막하게 느껴질 수도 있을 것 같습니다. 그러나 이러한 경험을 통해 팀은 짧은 주기로 현재의 문제점을 계속 확인하고 학습하는 방법을 배울 수 있었습니다. 또한 이 모든 과정이 1달 반 안에 완료되었다고 생각하면 긍정적이라고 생각합니다. 주어진 3달을 모두 아이데이션(Build)만 하다가 끝날 수도 있었기 때문입니다.
만약 누군가가 기획 전문가 없이 새로운 서비스를 만들어야 한다면 일단 빨리 만들고 이를 통해 측정해 보시기를 추천해 드리고 싶습니다. 직접 측정한 데이터를 얻을 수 있다면 앞으로 나아갈 방향에 대한 확실한 단서를 얻을 수 있을 것입니다.
References
niceideas.ch: The Search for Product-Market Fit
About Product/Market Fit — what I’ve learned about the goal, the process and the nuance
알렉스 오스터왈더, 『밸류 프로포지션 디자인』, 아르고나인미디어그룹(2016)
OURR 아워레코드
우리끼리 일정 만들고 인증샷 공유하자!
Richard Lim
데이터리차드
데이터를 재미있고 가치있게 배울수 있도록
왕 왕
좋은 월요일 되시길....
이예진
좋은 마케팅 아이디어는 '나라면?’을 상상할 때 가장 많이 나옵니다.
혼자서도 활용할 수 있는 마이크로 마케팅 아이디어를 받아보세요 [구독하기]
혹시 뉴스레터 발행하거나 혹은 준비중이신가요?
올해 Gmail 정책이 강화되면서
메일이 스팸함으로 가는 현상이 자주 발생하고 있어요.
특히 뉴스레터의 경우 도메인이나 설정을 최적화하고
플랫폼을 통해 발행한다 하더라도
받는 사람의 메일함 설정이나 인식 여부에 따라
스팸함으로 가는 경우가 늘어났습니다.
이럴 때 우리는 과연 어떻게 해야 할까요?
구독자분들께 좀 더 잘 닿기 위해
오늘은 간단하지만, 똑똑한 장치를 마련한 아이디어를 알아봤습니다.
예상 읽기 시간: 1분 18초
📮 뉴스레터: 스팸함에서 저 좀 꺼내주세요...!
내 뉴스레터를 스팸함에서 구출하고 싶다면, 구독자에게 말을 걸어보세요
내 뉴스레터가 자꾸 스팸함으로 간다…!
구매 고객의 소비 심리를 분석하는 뉴스레터 ‘Why We Buy’를 운영중인 Katelyn. 하지만 최근 자신의 뉴스레터가 스팸함에서 발견되는 횟수가 늘어나고 있음을 느껴요. 구독자 중에도 메일이 오지 않는다며 항의하는 연락이 오곤 합니다. 뉴스레터 도메인이나 설정은 이미 최적화했지만, 그 외에 구독자의 메일함이 자신을 스팸으로 인식하지 않도록 할 직접적인 방법을 고민합니다.
구독자에게 말 걸어보기 (with 깜짝 리워드)
Katelyn의 웰컴 메일
Katelyn은 웰컴 메일을 똑똑하게 세팅합니다. 메일에는 2가지 장치가 포함되어 있는데요. 1. 곧 깜짝 선물이 도착하니 잠시 기다려라 2. 선물이 메일함에 잘 도착하기 위해서는 간단한 액션을 해달라는 요청이었습니다. 액션은 정말 간단해요. 내 메일을 스팸함에서 꺼내 ‘기본 편지함’으로 옮기고, ‘안녕’만 쳐서 답장하면 끝입니다. 구독 타이밍이 뉴스레터에 가장 관심도가 높을 때임을 알고, 이를 공략해 구독자가 바로 행동할 수 있도록 만든거죠. 답장을 유도 하면 뭐가 좋을까요? 실제 교류가 생기면 메일함이 ‘진짜 인맥’으로 판단해 스팸 처리를 안 합니다.
📝 포인트
답장 유도하기
구독자가 레터에 답장하도록 해서 메일함이 뉴스레터를 스팸이 아닌, 사람으로 인식하게 만듦귀찮음 최소화하기
엄청나게 단순한 2가지 액션(스팸함에서 꺼내기, ‘안녕’만 보내기)을 제안해 귀찮음을 최소화함타이밍 노리기
가장 관심도가 높은 구독 직후의 타이밍을 공략해 바로 액션을 하도록 유도함깜짝 무료 리워드 주기
예상치 못했던 보상을 주어 구독자가 기꺼이 이 행동을 하도록 만듦메일과 리워드 사이에 텀 두기
바로 뉴스레터를 취소할 수 없도록 웰컴 메일과 시간 차를 두고 선물을 발송함
(ex - Katelyn의 리워드는 총 2개, 30분 후 구매자 심리 치트 시트 / 1일 후 구매력 상승 마케팅 팁을 준다)
🫵 만약 활용해본다면?
웰컴 메일 구성해 보기 (인사 - 소개 - 무료 깜짝 선물 - 답장/행동 유도)
웰컴 메일과 30분정도 텀 두고 깜짝 리워드 세팅하기(타깃의 니즈 고려)
회신율 체크하면서 지속적으로 리워드와 메일 내용 개선하기
TMI) ‘수신 거부 문구’ 넣는 게 좋을까, 아닐까?
뉴스레터 하단에 보면 보통 이런 문구가 쓰여 있어요. ‘수신 거부를 원하신다면 이곳을 클릭하세요’ 막상 이 문구를 넣으려니 사람들이 쉽게 내 레터를 취소할까봐 망설여 지는데요. 이 문구는 오히려 더 큰 문제를 방지해줍니다. 만약 이 문구가 없다면, 구독자가 메일을 취소하고 싶을 때 ‘스팸함’으로 넣거나 이 발신자를 차단하게 되고, 그럼 Gmail이 내 도메인을 스팸으로 인식할 확률이 커지거든요. 그러니 가급적이면 수신 거부 문구를 포함하는게 좋아요 :)
P.S. 후킹 문구 리스트 사랑해 주셔서 감사합니다🙇♀️
이전 뉴스레터에서 ‘후킹’을 주제로 다루며, 기존에 제가 모아서 사용하던 ‘65개 후킹 문구 리스트’를 공유했는데요. 생각보다 많은 분들이 받고 좋은 피드백 주셔서 뿌듯했습니다. 원래는 주말 내 신청 마감을 했었는데, 감사의 마음을 담아 하루만 더 연장해 배포하려 합니다. 아직 후킹 문구 리스트를 받지 못하셨다면, 하단 링크에서 받으실 수 있습니다. 링크는 오늘까지만 열려있을 예정이니 참고 부탁드립니다 :)
📮 [오늘 마감] ‘65개 후킹 문구 리스트’ 받기
TMI
Tiny Marketing Information
이연수
프론트엔드 기술 스택 정리하며, 개인 포트폴리오(프로젝트) 준비.
안녕하세요. 웹 개발 7년차에 접어들고 있는 개발자입니다.
최근까지 의료 AI 회사의 플랫폼 개발을 담당하다 퇴사 후 프리랜서로 일을 진행하고 있습니다. 백엔드 개발자로 시작하여, 프론트엔드 개발자로 전향하고, 지금은 기술 스택을 쌓으며 다음 스탭을 준비하고 있습니다.
혼자 프로젝트를 개인 포트폴리오 형태로 준비하고 있습니다. 그동안 업무에서 쌓아왔던 기술을 정리하려고 합니다.
현재는 노션(Notion)과 유사한 기능의 WYSIWYG(Rich Text Editor)를 개발하고자 개발을 진행하고 있습니다. 아래에서 설명 드릴 WEB PACS(의료영상저장전송시스템)가 완성되면, 의료(AI 판독문, 인허가 문서 등), AI 연구, 필요한 문서 템플릿 등을 개발하여 연동하는 작업을 목표로 개발하고 있습니다.
앞에서 말씀드린 의료 AI 관련 분야에서 수행하였던, WEB PACS(의료영상저장전송시스템)을 오픈소스 도움 없이 vision(Graphic) 개발에 .dcm(DICOM)파일을 binary 수준까지 연구하여 표현하는 프로젝트를 진행 하려합니다. 주로 의료 AI를 연구하시는 연구자에게 Data Labeling(ROI - 흥미영역)에 대한 어노테이션 툴과 작업된 의료 AI(모델)을 연결하여 병변 분류, 표시 등이 가능한 연구 플랫폼 구성을 프로젝트에 포함하여 작업 하려합니다.
의료분야에 대해 혹은 의료공학을 전문적으로 배운 것이 아니기에 데이터 전처리 플러그인 개발과 AI(모델)에 서빙과 하이퍼 파라미터 등 전반적인 연동에 필요한 조언이 필요한 상태입니다.
그리고 의료 데이터가 가진 특수성(민감 데이터, 보안)을 고려한 WebRTC(Web Real-Time Communication)을 활용하여 데이터 반출 없이 원격진료, 원격판독 등의 기술 개발도 진행해보려고 합니다.
프로젝트를 진행하고 계신 의료, 산업, 교육 등 다양한 분야의 AI, 웹 관련 개발자 분들과 많이 소통하고 정보를 공유하면 좋겠다고 생각하고 있습니다.
클럽 가입 후 첫 글이라 진행중인 개인 프로젝트 소개와 간략한 제 소개를 하였습니다.
앞으로 잘 부탁드립니다~
(편안하게 스몰톡을 위한 커피톡 환영입니다.)
Hannah Kim
EA korea, NEXON, COSDOTS 궁금하신 분!
안녕하세요! 게임 업계 커리어 패스가 궁금한 분들을 위한 행사 가져왔어요📢
평소에 피파온라인, 메이플스토리 등 게임을 함께 만드는 분들이 궁금했다면 지금 바로 신청하세요 😎
🕹게임 기획🕹부터
🍄게임 업계 커리어 성장🍄까지!
걸스인텍 코리아와 EA Korea의 24년 첫 행사가 오픈되었습니다!
[#StartHerSuccess: 게임 메이커들의 커리어 레벨업]
1. 사랑받는 게임의 기획부터 개발과정
2. 잘 만들어진 게임이 유저들에게 전달되기까지
3. 게임과 커리어 성장에 대한 이야기
이 세 가지 주제의 이야기를 세 분의 연사님을 통해 나눌 예정입니다!
✅ 게임 업계 커리어 패스가 궁금한 누구나
✅ 커리어 레벨업을 꿈꾸는 게임업계 신입/주니어
-----
👉일시: 2024.3.9 (토) 02:00 ~ 04:30
👉 장소: EA Korea 오피스 타운홀
👉 참가비: 무료
👉 모집: 50명 (추첨선별)
👉 모집일정: 2024.2.19 (월) - 3.3 (일) 23:59
👉 합격자 발표 : 2024.3.4(월) 개별 연락
🏃 신청하러 가기 : https://event-us.kr/m/78725/14320
Lucy Seo
유입량을 극적으로 높여주는 홈 엔트리
대부분의 신규 기능들은 초반에 어느 정도의 진입률을 보일까? 10%? 5%? 1%? 제품마다 다르겠지만, 제품 코어 기능이 아니고서야 0.1%~0.5% 내에 있을 기능들이 대부분일 것이다. 이 경우 진입 대비 전환율 보다 진입률을 높이는 것이 전체 퍼널 관점에서 임팩트가 훨씬 크기 때문에 진입 엔트리를 넓히는 개선이 필요하다.
특정 기능의 진입률을 높이기 위해 해당 기능의 위치를 옮기는 것도 방법이지만 이는 인지 부조화 등의 부작용이 클 수 있어 조심스럽게 접근해야 한다. (하지만 인지 부조화 없이 10배 개선했던 사례 — 기능의 위치 조정으로 무료체험 10배 늘리기) 위치를 옮기는 방법 외에 진입률을 올릴 수 있는 전략은 엔트리 전략이다. 해당 기능으로 바로 랜딩 되는 지름길을 만드는 것이다. 엔트리 전략도 2개로 나눠볼 수 있다
(이전 글 — 퍼널 최적화 전략)
홈 엔트리
뭉툭하지만 노출량을 극대화하는 엔트리
제품 홈에서 해당 기능을 대대적으로 홍보를 하는 것이다. 아래와 같은 화면들을 여러 앱들에서 본 적이 있을 것이다. 광고처럼 느껴지지 않고 오히려 그냥 원래 앱 내에 있는 여러 컴포넌트처럼 보이면서, 눌러보면 특정 기능으로 랜딩이 되는 — 그리고 묘하게 내가 필요한 것 위주로 그 내용이 매번 바뀌는 — 그런 지면.
익숙한 제품들의 홈화면 — 그 상단 영역
사실 나도 처음 이런 지면들을 봤을 때는, 솔루션 관점에서 ‘새로 뭔가 출시되면 당연히 유저들에게 알릴 필요가 있으니까 이런 지면들을 활용하는 거겠지’ 정도로 생각했다. 하지만 몇 차례 경험 속에서 이 지면을 활용하는 것이 전환을 크게 증폭할 수 있는 필승 전략이라는 사실을 깨닫게 되었다.
가볍게 만들어서 출시했던 알라미 홈 화면 상단 엔트리
친구초대 기능 출시 후, 진입률이 너무 낮은 것을 확인하고는 제품 메인 화면 상단 영역에 엔트리를 하나 만들기로 했다. 기획적으로 복잡하게 생각하지 않았고, 한 번도 방문하지 않은 유저들에게만 노출하는 방향으로 빠르게 작업해서 배포를 했다. 결과는 놀라웠다.
출시 직후 모든 유저들에게 노출됨에 따라 친구초대로 유입되는 유저 수 (= 친구초대의 최종 전환 값)가 5배까지 치솟았다. 일시적으로 기존 유저들의 트래픽이 크게 임팩트에 기여를 했던 것이고, 그 효과가 거둬진 시점 이후 그로스 관점에서는 3배 성장한 것으로 분석이 되었다.
이 과정에서 반대의 경험도 맛보게 되었는데, 그 경험으로 홈 엔트리의 효과를 더블체크 할 수 있었다.
친구 초대 엔트리를 추가하면서 기상 챌린지 엔트리가 사라졌는데, 기상 챌린지 퍼널 전환이 크게 떨어진 것이다. (기상 챌린지는 출시할 때부터 홈 엔트리와 함께 출시되었다.) 이를 통해 역산을 해보면 이 또한 약 3배 정도의 전환 기여가 있었던 것으로 추정된다.
3배는 시작일 뿐
‘뭐야.. 홈화면 상단 영역까지 활용했는데, 겨우 3배?’라고 생각할 수도 있다. 하지만 3배는 그저 시작일 뿐이다. 앞서 말했듯 우리는 홈 엔트리에 전략적으로 접근했던 것이 아니다. 신규 기능 출시를 알리고 싶은 마음에 추가했을 뿐이다. 하여 그로스 관점에서는 몇 가지 약하게 구현된 점들이 있다.
[타겟 유저] 불특정 다수에게 일괄 노출 : 특정 기능을 필요로 함직한 유저 새그먼트를 타겟해서 보여주지 않았다. 타겟팅이 정교화되면 홈 엔트리의 임팩트는 더욱 커질 것이다. 유저 만족도도 더 높아질 것이고.
[UI/UX] 광고처럼 보일 수 있음 : 광고처럼 보이지 않기 위해 크게 노력하지 않았다. 어차피 한번 방문하면 사라질 지면이기 때문에 오히려 더 눈에 띄게끔 시안을 잡았었다. 더 자연스러운 UI/UX를 제공하면 유저 인게이지먼트가 좋아져 임팩트가 더 커질 것이다.
[노출 이후 동작] 단순한 동작 : 여러 기능들의 엔트리가 순차적으로 롤링되거나, 유저가 스와이프를 할 수 있거나 등의 인터렉션이 없었다. 그냥 터치하면 사라지는 지면이었다. 더 잘 인게이지 하게끔 노출 이후의 동작을 재기획해 볼 수 있다.
위 이유로 우리의 상단 홈 엔트리를 터치해 보는 유저 비율은 전체 유저의 채 3%가 안 되었다. 그럼에도 불구하고 전환 수를 3배 가까이 만들어낸 것. 만약 홈 엔트리 인게이지 비율을 10%까지 늘릴 수 있다면? 3배가 10배가 될 수도 있는 길인 것이다.
그리하여 본격적으로 홈 엔트리 영역을 퍼널 그로스 관점에서 적극 활용해 보기로 했다.
홈화면 엔트리 전략을 더 집중적으로 그로스적으로 파고들 경험이 되는 만큼, 보다 디테일한 레슨들이 마구마구 도출되기를 기대하고 있다. 특정 기능 단위의 10배 개선뿐 아니라, 예측 못한 여러 시너지까지 (신규 유저 앱 리텐션 xx% 증대 등) 있기를 기대해 본다.
관련해서 경험 및 지식이 있으신 분 나눔 부탁드려요. :D
⏰ 딜라이트룸에서 알라미와 함께 아침을 바꿀 분들을 모십니다 🙌
딜라이트룸의 다양한 채널들을 팔로우하고 빠르게 소식을 받아보세요!
딜라이터들의 다음 아티클도 빠르게 만나보려면? 지금 바로 미디엄 팔로우!
절찬 채용중인 포지션 알아보기 ⏰(+ 여기서 지원하면 입사 축하금 100만원💸)
김예나
[웨비나]GA4 전자상거래 측정기준, 측정항목 이해하기
전자상거래 이벤트🛒, 세팅은 했는데 보고서 조회가 어려워 답답하셨나요?
오픈소스마케팅의 2024년 첫 웨비나는 많은 분들이 기다리셨을 전자상거래 데이터 조회를 위한 GA4 측정기준과 측정항목 이해하기 내용으로 준비했습니다. 전자상거래 데이터 활용이 필요하신 분들, 특히 커머스 서비스를 담당하시는 분들은 꼭 신청하셔서 데이터 활용 의사결정에 도움 되시기 바랍니다. 🤗
📌 일정 안내
- 일시: 2024년 3월 7일 오후 8시 ~ 오후 9시 30분
- 진행 방식: 온라인 웨비나(Zoom)
- 연사 소개: 오경석 (오픈소스마케팅 대표)
- 참가 신청:
📌 이런 분들을 위해 준비했습니다.
GA4 전자상거래 이벤트의 구성요소에 대해 알고 싶은 분
이미 전자상거래 이벤트를 수집하고 있는데 보고서에서 어떤 요소를 봐야하는지 혼란스러운 분
GA4에서 상품 정보를 조회하는데 어려움이 있는 분
📌 이런 내용이 준비되어 있습니다.
GA4 전자상거래 이벤트의 구성 요소 이해하기
GA4 전자상거래 측정기준과 측정항목 이해하기
웹사이트와 모바일 앱의 전자상거래 이벤트 차이점
2024년 오픈소스마케팅 첫 웨비나도 많은 관심과 신청 부탁드립니다. 🎉
GA4 전자상거래 측정기준과 측정항목 이해하기
GA4 전자상거래 이벤트 구성을 이해하고, 전자상거래 이벤트 데이터 분석을 위한 보고서 만들기
Inchol Hong
[3분 디자인 스트레치] ① 브랜드 디자인의 본질을 재고하다.
3분 디자인 스트레치로 다시 생각해보는 브랜드 디자인의 본질.
안녕하세요.
'3분 디자인 스트레치' 입니다.
오늘은 디자이너로서, 클라이언트로서, 유저로서 흔히 알고있는 '브랜드 디자인'에 관한 우리의 생각을 다시 한번 되짚어보는 시간을 갖고자 합니다. 브랜드 디자인을 설명할때 이미 다양한 분야와 매체 속에서 진정성, 유니크함, 환경적 책임, 혁신, 창조성 같은 단어들이 반복되고 있지만, 우리는 과연 브랜드 디자인의 근본에 대해 충분히 이야기하고 있는 것일까요?
식상한 이야기 너머로
많은 사람들이 브랜드 디자인을 논할 때, 자주 언급되는 키워드들은 이제는 너무나 익숙해졌습니다. 하지만 이러한 키워드들이 진정으로 브랜드 디자인의 본질을 대변한다고 할 수 있을까요? 브랜드, 사용자, 시장의 관계 속에서, 우리는 종종 가장 기본적이면서도 중요한 질문을 간과하곤 합니다: 진정한 브랜드 디자인이란 무엇인가?
진정한 디자인? 올바른 디자인?
브랜드 디자인은 단순히 로고, 색상, 폰트의 조합을 넘어서는 것입니다. 이러한 요소들은 중요할 수 있지만, 브랜드 디자인의 진짜 핵심은 이야기와 전달하고자 하는 메시지에 있습니다. 올바른 브랜드 디자인은 사용자와 고객, 대중들이 직접 경험하고 평가하는 것입니다. 각자 다른 기준과 경험을 가진 사람들이 공감할 수 있는, 흥미로운 브랜드의 이야기가 진정으로 중요한 것입니다.
공감과 흥미를 이끄는 디자인
브랜드 디자인의 진정한 가치는 형식이나 기준에 있지 않습니다. 중요한 것은 우리가 전달하고자 하는 아이디어와 경험을 어떻게 효과적으로 또한, 매력적으로 이야기할 수 있는가입니다. 공감을 불러일으키고, 사람들이 '멋지다!'라고 생각할 수 있는 브랜드 이야기가 바로 우리가 지향해야 할 브랜드 디자인의 본질입니다.
이제 우리는 브랜드 디자인에 대한 새로운 시각을 가지고, 단순한 형식을 넘어서 진정으로 의미 있는 메시지를 전달하는 디자인을 추구해야 합니다. 여러분의 브랜드 이야기는 어떤가요? 공감과 흥미를 이끌어내는 진정한 브랜드 디자인으로, 사람들의 마음에 남는 브랜드가 되길 바랍니다.
이번 뉴스레터를 통해, 우리 모두 브랜드 디자인에 대한 깊이 있는 고민을 함께 나누고, 보다 풍부하고 다채로운 디자인 세계를 탐험해 나갈 수 있기를 바랍니다.
다음 편에서 뵙겠습니다.
감사합니다.
-
안녕하세요.
'3분 디자인 스트레치' 입니다.
저는 7년 동안 실리콘밸리의 디자인 에이전시, 스타트업, 구글 어시스턴트 팀에서 근무하면서,다양한 사람, 팀원, 파트너, 클라이언트들과 함께 일하면서 겪고, 느끼고, 끄적끄적 적어두었던 것을 편하게 이야기할 수 있는 공간으로 소식지를 쓰고 있어요.
여기서는 디자인, AI, 경험 디자인, UX 등 다양한 디자인과 Creative에 관련된 이야기를 진짜 개인적이고 편하게 적어낼 거예요.
Lear more about the writer,
www.helen.xyz
Lucy Seo
iOS Core Data HeavyWeight 마이그레이션 실패기
그림을 그리다가 마음에 들지 않거나 예상대로 흘러가지 않을 때 어떻게 하는지 보여드릴게요.
그냥 이렇게 덧그리기만 하면 돼요. 이렇게 하면 완전히 아름다운 나무가 다시 탄생하죠. 우리는 실수를 하지 않아요. 단지 행복한 사고가 일어났을 뿐이죠!
-밥 로스
안녕하세요 리디입니다. 🧑🏻💻
당신을 위한 나의 실패
딜라이트룸에는 ‘당신을 위한 나의 실패’ 라는 문화가 있습니다. 실패를 통해 레슨을 얻고 이를 공유함으로 다른 사람들의 비용을 아껴주자라는 의미입니다. 오늘은 저의 실패를 공유함으로 여러분들이 소비할 시간을 아껴드리고자 합니다.
최근 알라미 DB구조에 대한 대규모 업데이트를 진행 중에 있습니다.
그리고 해당 작업의 저의 첫 플랜은 다음과 같았습니다.
Realm과 CoreData 로 나눠진 DB를 CoreData로 합친다.
CoreData 데이터를 V3로 마이그레이션을 진행한다.
이 과정 중 특히 2번에서 많은 시도가 있었고, 덕분에 좋은 레슨도 얻을 수 있었습니다. 오늘은 이 과정에서의 레슨을 공유하고자 합니다.
먼저 제가 Core Data를 선택한 이유는 다음과 같았습니다.
FirstParty Framework에 대한 신뢰.
이후 SwiftData로 넘어가기에 용이함.
이번에 모두 CoreData로 넘어가고 나면 이후에는 문제없이 SwiftData까지 잘 넘어갈 수 있을 것이라는 기대가 컸습니다.
Core Data Migration
먼저 CoreData의 Migration 방식에는 크게 자동(Automatically) 이라고 이야기하는 LightWeight 방식 그리고 수동(Manual) 이라고 이야기하는 HeavyWeight 방식이 있다는 것은 다들 알고 계실 것입니다.
일반적으로 우리는 LightWeight 방식을 사용하게 됩니다. Row를 추가하거나, entity 혹은 property의 이름을 바꾸거나 하는 가벼운 구조의 변경에서는 말이죠.
developer.apple.com에 따르면 다음과 같은 경우에 대하여 LightWeight 방식을 이야기하고 있습니다.
- 속성 추가
-속성 제거
-선택사항이 아닌 속성이 선택사항이 됨
-선택사항 속성이 선택사항이 아니며 기본값을 정의함
-엔터티 또는 속성 이름 바꾸기
예를 들면 다음과 같습니다.
공통으로 사용 할 것이라고 생각하여 ALColorEntity로 정의한 이름을 차량에만 사용하게 되어 ALCarColorEntity로 변경 한다거나, Entity내부의 RGB값을 rgb로 property명을 변경하는 경우에는 LightWeight로 충분합니다.(LightWeight 에 대한 자료는 구글링을 통해 금방 확인이 가능하니, 더이상의 설명은 생략하도록 하겠습니다.)
하지만 우리의 DB는 이런 light migration만을 필요로 하지 않습니다. 새로운 Column에 기본 값을 추가해준다거나, 마이그레이션 중 연산을 통해 다른 값으로 변경해줘야하는 경우도 있습니다.
이 경우 우리는 HeavyWeight방식을 통한 마이그레이션이 필요합니다. HeavyWeight 마이그레이션 방식을 찾아보면 몇가지 방법들이 나오지만, 개인적으로는 이 강의가 제일 좋았습니다..
친절하지 않은 애플놈들 대신 친절한 raywenderlich 강의는 마음을 편안하게 만들어주죠.
요약해보면 다음과 같습니다.
1. 새로운 모델을 추가해주고 Model Version을 변경해준다.
2. Source와 Destination을 설정한 MappingModel을 만들어준다.
3.세뷰 규칙을 정한 객체를 만들고 NSEntityMigrationPolicy 를 채택합니다.
4.그리고 이 객체를 CustomPolicy에 등록시켜준다.
그러면 App의 Launch타임에 HeavyWeight migration이 동작하게 되는 것이죠.
참 쉽죠?
오늘의 주제는 HeavyWeight 하는 방법이 아니기 때문에 강의로 설명을 대체합니다
하지만 우리는 이러한 마이그레이션을 1회만 하지는 않을 것입니다.
V1 → V2 → V3 시간이 지남에 따라 버젼이 늘어나겠죠. 그리고 여기에서부터 모든 문제가 시작하게 되죠…
Realm Migration
알라미는 그동안 대부분의 DB를 Realm을 통해 관리하고 있었습니다. 최근 추가된 수면 관련 데이터들만 CoreData를 통해 관리하고 있었죠.
Realm에서의 Migration 방식을 살펴보자면 다음과 같습니다.
1. Realm.Configuration 에 새로운 schemaVersion을 등록해준다.
2. migrationBlock 내부에 세부 마이그레이션 로직을 넣어둔다.
3. Realm을 초기화하기 전 Configuration에 넣어준다.
4. Realm은 migrationBlock 을 실행하며 마이그레이션을 진행한다.
migrationBlock에서 우리는 마이그레이션 수행에 사용되는 Migration 객체와 oldSchemaVersion을 통해 쉽게 마이그레이션을 동작시킬 수 있습니다.
Realm에서는 migration schema가 v1 → v2 → v3로 업데이트가 되도 문제가 되지 않습니다. 순차적으로 마이그레이션을 타도록 코드를 짠다면 우리는 직전 모델에 대해서만 대응을 하면 되니까요!
AlarmEntity migration시 사용되는 코드.. schemaVersion이 상당하다..!
Core Data Migrating multiple versions
그렇다면 CoreData는 이런 여러가지 버젼에 대한 Migration에 대하여 어떻게 동작하고 있을까요?
CoreData는 기본적으로 저장소에 사용된 모델과 번들의 현재 모델간의 불일치를 감지합니다. 그리고 불일치할 경우 자동으로 마이그레이션 시도합니다. 때문에 CoreData는 version에 대한 순차적 마이그레이션을 지원하지 않습니다.
즉, V1 모델을 갖고 있는 유저와 V2의 모델을 갖고 있는 유저가 최신인 V3로 업데이트 할 경우에는 다음과 같이 동작하게 됩니다.
하아…
사실 여기까지의 동작을 파악하는 데에도 꽤 오랜 시간이 걸렸습니다.
당연히 버젼을 순차적으로 기억할 것이라 생각했기 때문이죠.
다시 돌아와서 이로인해 발생하는 문제점은 명확합니다. Version이 올라갈 수록 관리비용이 급격하게 증가한다는 점이죠. Version 4가 나올 경우, [V1 → V4, V2 → V4, V3 → V4] 3개의 mapper가 필요합니다. 즉, version N의 경우 N-1 개의 Mapping Model이 필요하게 되는 것이죠.
시간이 흐르고 우리가 V10까지 만들었다고 가정을 해봅시다.
우리는 기억도 안나는 과거의 V1에서부터 V10으로의 마이그레이션을 고민해야합니다. 생각만해도 끔찍하죠..
딱 이 심정…
마이그레이션을 최소화 시키라는 애플의 큰 그림일까요..
하지만 저는 그런 그림 싫은데요…
물론 갓플에서도 이러한 문제점을 알았는지 WWDC 2023에서 Staged 방식을 통해 CoreData Migration의 문제점을 해결할 수 있도록 해주었습니다.
https://developer.apple.com/videos/play/wwdc2023/10186
너무나 매력적이죠!
단,
iOS 17에서부터 된다는 것만 제외하면요…. ㅂㄷㅂㄷ..
iOS17 이면 SwiftData를 썼겠지.. 이 사과놈아..
Core Data progressive migration
하지만 좌절하긴 이르죠. 우리의 선배님들이 이런 문제에서 고통만 받고 계실 리 없죠.
이러한 마이그레이션의 문제점을 해결하기 위한 키워드로 Core Data progressive migration이라는 키워드로 검색해본 결과 몇가지 유용한 아티클들을 찾게 됩니다.
PROGRESSIVE CORE DATA MIGRATIONS
by.williamboles
Core Data Progressive Migrations
by.kean
그리고 이를 응용한 Framework도 찾게 되었죠.
GitHub — prisma-ai/Sworm: CoreData based Swift ORM
(🫢 오이오이.. 믿고있었다구..)
내용을 살펴보면 다들 비슷한 방식으로 순차적 마이그레이션을 진행하고 있습니다.
이해가 잘 안되실 경우, 블로그 가서 코드 한번 보면 이해가 쏙쏙 됩니다.
자세한 설명은 블로그를 찬찬히 읽어보시고, 내용을 더 요약해보자면 다음과 같습니다.
1. 버젼의 순서를 수동으로 등록 한다.
2. NSManagedObjectModel API를 통해 SourceModel의 현재 버젼을 파악한다.
3. 순차적으로 MigrationStep을 따라간다.
4. 마이그레이션 끝 🥳
오! 쉽습니다. 실제로 동작시켜보니 잘 동작하는 것도 확인할 수 있습니다.
해치웠나..!?
이렇게 행복하게 마이그레이션 글쓰기를 종료..
하고 싶었지만.. 코어데이터는 그렇게 호락호락하지 않습니다..
Product에 적용하는 것은 또 다른 이야기이죠..
이제 문제는 알 수 없는 곳에서 발생했습니다.
특정 commit 이전에서 현재 버젼으로 마이그레이션을 시도할 경우 SourceModel의 현재 버젼을 파악할 수 없는 상황이 발생했기 때문입니다.
* 문제가 되었던 API
metadata 오픈 해봐도 값들이 전부 잘 들어있어 원인 파악이 되지 않았고,
version을 강제하기도 하니 맵핑과정에서 크래시가 났습니다…
configuration에 대한 내부 로직을 알 수 없으니 안정감이 떨어졌습니다.
후..!
정말이지.. 왜 Realm을 사용하는지 갑자기 이해가 되기 시작했습니다..
선녀 같은 Realm의 마이그레이션..
급작스러운 글의 마무리이긴 하지만,
여기까지의 시도를 마지막으로 코어데이터 마이그레이션에 대한 저의 도전은 막을 내렸습니다.
이유들은 위의 원인만 있었던 것은 아니었습니다.
여전히 안정성에 대한 불안함
- 코어데이터에 대한 이해도가 여전히 낮았고, 위의 이슈를 해결한다고 해도 안정성에 대한 불안감이 사라지지 않을 것 같았습니다.소비되는 비용이 너무 커지고 있음
- 우리의 목표는 유저에게 원하는 가치를 안전하고, 빠르게 전달하는 것이었습니다. 하지만 이대로 작업하다가는 안전함과 빠름 어떤 것도 달성하기 힘들다고 판단했기 때문입니다.Model과 MappingModel 의 수정을 코드로 할 수 없어서 변경에 대한 확인이 어려움.
- Storyboard를 쓰지 않음과 마찬가지로 변화를 코드로 확인할 수 없고, 이 부분이 쌓였을 때 안정성을 해칠 수 있다고 판단했기 때문입니다.
CoreData에 대하여 어느 정도 다이브 해보고 나니 오히려 필요한 부분이 명확하게 그려졌습니다.
저는 결국 CoreData의 모델들을 모두 Realm 으로 이관시키기로 결정하였습니다. 다행히 우리는 interface를 통해 Repository에 접근을 하고 있었기 때문에 변경 비용이 크게 들어가진 않았습니다.
그렇게 우리 앱은 조금 더 안정적인 상태로 QA를 진행 중에 있습니다.
마무리
정리해보면 이번에 제가 얻은 레슨은 크게 2가지 입니다.
첫번째로, CoreData의 마이그레이션 로직에 대한 이해도를 높일 수 있었습니다.
지금껏 서버와 통신이 중요한 앱들을 만들다보니, Local DB에 대해서 이렇게 만져볼 기회가 없었습니다. 이번 기회를 통해 Core Data와 Realm의 동작들에 대한 이해도를 높일 수 있었고, 덕분에 앞으로의 방향성에 대한 확신을 얻을 수 있었습니다.
두번째는, FirstParty Framework 이라도 검증을 통해 안정성을 체크해야 한다라는 점이었습니다.
만약 POC의 결과만 믿고 앱을 배포 했다면, 특정 버젼 이전의 유저들은 크래시를 경험하게 되었을 것이고, 이는 우리 앱에 치명적인 결과를 낳을 수 있기 때문입니다. 결국 모두 도구라고 생각하고 검증에 대한 필요성을 한번 더 느끼게 되었습니다.
하지만 그렇다고 FirstParty Framework를 포기하지는 않았습니다.
한번 깔끔하게 털어내고, 잘 닦아내고 이해도를 높인 후 다음에는 Realm에서 SwiftData 로 다시 돌아올 예정입니다. 물론 이 경우에도 여러가지 실험을 통해 안전함과 유용함을 검증 해야겠지요.
끝까지 읽어주셔서 감사합니다!
⏰ 딜라이트룸에서 알라미와 함께 아침을 바꿀 분들을 모십니다
🙌딜라이트룸의 다양한 채널들을 팔로우하고 빠르게 소식을 받아보세요!
지금 바로 미디엄 팔로우하고 다음 아티클도 빠르게 만나보세요!
사스캐치
이 글은 [사스캐치] 에서 발행되었습니다.
사스캐치의 뉴스래터를 구독하고 온라인 사업도구 모음 (200+) 받아가세요. [구독하기]
💬 사스캐치의 오픈톡에 참여하세요.
비즈니스에 관한 자료를 확인하고 소통할 수 있습니다.[참여하기]
이 글은 Principled Instructions Are All You Need for Questioning LLaMA-1/2, GPT-3.5/4 (Sondos Mahmoud Bsharat, Aidar Myrzakhan, Zhiqiang Shen)논문에서 발췌한 내용입니다.
해당 논문에서는 ChatGPT에서 프롬프트를 간소화 하면서도 정확하고 구체적인 답변을 받기 위한 연구를 진행했는데요, 연구 결과 아래의 26가지 프롬프트 원칙을 제안했어요.
명령, 협박, 팁, 벌칙 등 재밌는 내용도 보이고, 역할을 부여하는 것도 효과가 있었어요.
자세한 원칙과 예제는 아래 표를 참고하세요.
26가지 프롬프트 원칙 개요 (번역)
Overview of 26 prompt principles
26개의 원칙이 프롬프트 설계에 미치는 효과를 검증하기 위해 제작된 프로젝트 페이지 확인하기
더욱 상세한 설명과 예시가 필요하다면? 원문확인하기
💬 사스캐치의 오픈톡에 참여하세요.
비즈니스에 관한 자료를 확인하고 소통할 수 있습니다.[참여하기]
사스캐치 구독하고 온라인 사업도구 모음(200개+) 받아가세요 (웰컴메일 확인필수)
Roy Kim
Product Hunt 출시로 성공 가도를 달린 Superpowered: 스타트업의 첫걸음을 빛낸 전략
Superpowered는 캘린더에 새로운 방식을 도입한 흥미로운 제품으로, 단 하나의 단축키(CMD+J)만으로 다음 회의에 자동으로 참여할 수 있으며, 메뉴 바에서 캘린더를 우아하게 확인할 수 있습니다. 이 제품의 단순함, 우아함, 속도, 그리고 천재성 덕분에 많은 사람들이 Superpowered를 사랑하게 되었습니다. 제품의 첫 번째 고객을 얻기 위해, Superpowered의 창립자들(캐나다 워털루 대학교의 학부생 4명)은 Product Hunt에서 제품을 출시하여 첫 수백 명의 유료 사용자를 확보하는 데 성공했습니다.
제품을 출시하기 전에 완벽하게 준비되지 않았더라도 출시하는 것이 중요합니다. Superpowered 팀은 핵심 기능이 작동하고 있었지만, "무료 체험"이나 사용자를 제한하는 기능은 실제로 존재하지 않았습니다. 그러나 두 주간의 무료 체험 기간을 제공함으로써, 그들은 이를 해결할 시간을 가졌습니다.
출시 준비는 최소한 출시 이주 전에 시작해야 합니다. Superpowered 팀은 크게 네 가지 작업에 초점을 맞추었습니다: 훌륭한 헌터(제품을 사냥하는 사람)를 찾기, 샤우트아웃 백로그 생성, 자산 준비, 그리고 Product Hunt에서의 첫 몇 시간을 활용하기. 특히 첫 몇 시간은 제품의 성공에 매우 중요한데, 이 시간 동안 지지자들이 초기에 투표를 해줌으로써 순위를 올릴 수 있기 때문입니다.
이러한 전략은 Superpowered 팀이 Product Hunt에서의 출시를 통해 첫 수백 명의 유료 사용자를 성공적으로 확보하는 데 도움이 되었습니다. 이러한 접근 방식은 다른 스타트업이나 제품 출시를 계획하는 이들에게도 유용한 교훈을 제공합니다. Product Hunt에서의 성공적인 출시는 단지 제품을 알리는 것뿐만 아니라, 빠른 시간 내에 유의미한 피드백과 초기 사용자 기반을 확보하는 데 큰 도움이 될 수 있습니다.
이성봉
언론사에서 2017년부터 일했습니다. 중앙일보, 아웃스탠딩에서 기자로 일했습니다. 10년 이상 커리어 중 대부분 유료 기사가 차지하고 있습니다. 언론의 유료 모델이 아직 국내에선 실험적으로 읽히지만, 거스를 수 없는 흐름이라고 생각하고 있습니다. 대표적인 사례가 뉴욕타임즈, 블룸버그, 테크크런치 등이죠. 유료 독자들에게 높은 가치를 전달하는 기사를 계속 쓰겠습니다.
1. 플랫폼법을 둘러싼 논쟁이 이어지고 있습니다. 당초 취지와 달리 역차별 논란이 나왔는데요. 외국 기업의 플랫폼들이 규제에서 빠져나갈 가능성이 크기 때문이었죠. 이에 업계에서는 과거 사례를 언급하는 일이 있었는데요.
2. 대표적인 사례가 '판도라TV'입니다. 2004년 10월 출시됐는데요. 2005년 2월 설립된 유튜브보다 앞서 세계 최초로 동영상 서비스를 내놨습니다. 당시 글로벌 100대 기업에 선정될 만큼 혁신적인 서비스였습니다.
3. 그러나 성장은 5년도 지나지 않아 멈췄습니다. 저작권법 강화와 인터넷 실명제 때문이었습니다. 영상을 올리던 A씨는 판도라TV를 고소했습니다. 자신의 당구 강좌 영상이 무단 유포됐기 때문이었습니다.
4. 판도라TV는 당국의 규제를 잘 따랐습니다. 그 사이 유튜브가 규제를 피해 성장했습니다. 실명제가 부담스러운 사람, 불법 영상물을 올리던 사람은 모두 유튜브로 떠났습니다. 2023년 판도라TV의 서비스는 문을 닫았습니다.
(위 글은 아웃스탠딩 기사 요약문입니다. 기사 본문은 아래 링크를 통해 볼 수 있습니다)
William Jung
초기 팀은 많은 포지션보다, 많은 실행횟수가 더 중요합니다. 때문에 직군을 나눠 일하는 것보다 모두가 각자의 장점을 살려 효율적으로 가설검증을 빠르게 하는 것이 중요해요. 하지만 모든 구성원이 목표 중심적으로 일하는 문화를 만드는 일이 너무 어렵습니다.
그래서 오늘은 매달 20개의 가설을 검증하는 무니스를 만나 가설검증 에피소드와 팀 문화를 만들어가는 방법에 대해 물어봤습니다. 많은 사람들이 더 잘 잤으면 하는 마음에 마루에 남아 본인들의 잠을 줄이는 무니스 팀의 이야기를 들려드릴게요.
무니스의 인사이트 요약
시간이나 비용을 줄이는 것만이 최적화가 아닐 수 있습니다. 유저의 몰입에 초점을 맞추고 몰입을 방해하는 경험을 제거해나가보세요. 무니스는 이 사고를 한 뒤로 전환율이 10% 이상 올랐습니다.
A/B 테스트를 한다면, 실험군에게는 업데이트 소식을 적극적으로 전달하세요. 무니스의 경우 업데이트 홍보를 하지 않으면 실험군의 30% 만이 업데이트된 기능을 사용했다고 합니다.
가설과 직관이 충돌한다면 무조건 실험을 통해 결과를 확인하세요. 의외로 실험군과 대조군 모두 큰 변화가 없을 수도 있어요. 그럼 중요하지 않은 곳에 쓸 시간을 아낄 수 있게 되는거죠.
빠르게 실험을 돌리고 싶다면, 팀을 분리하지 말고 함께 스프린트할 수 있는 환경을 만들어보세요. 매주 실험에 대한 이야기로 소통하다보면 목표에 대한 얼라인과 빠르게 실행하는 팀을 동시에 만들어낼 수 있습니다.
마루 입주사들과 교류하면서 빠르게 제품개발하고 싶다면?
예전부터 궁금했는데, A/B 테스트는 언제부터 적극적으로 돌리기 시작했나요?
이게 계기가 있었어요. 미라클나잇은 기본적으로 질 좋은 수면을 위해 유저에게 적합한 모노럴비트를 생성해서 들려주는데요, 모노럴비트 외에도 명상과 ASMR을 들을 수 있어요.이 중에서 명상과 ASMR을 유저 저니의 유저 경험의 맨 앞단으로 뺐던 적이 있습니다. 저희는 나름대로 편의를 위해 순서를 바꾼 것뿐인데 리텐션과 결제율이 뚝뚝 떨어지는 거예요.
그래서 원인을 찾다 결국 롤백을 했는데 다시 회복이 되더라고요. 알고보니 명상과 ASMR을 맨 앞에 배치했더니 유저들이 홈 화면을 보고서 우리 앱을 명상앱으로 인지한 것이 문제였어요.
그때부터 A/B 테스트를 도입하기 시작했어요.
좋은 레슨런이네요. 기억에 남는 테스트가 있나요?
그랬더니 결과적으로 지표가 10% 가량 상승했습니다.
그래서 이걸 마켓핏 랩 정성영 대표님께 말씀드렸더니, ‘작은 yes를 받아냄으로써 큰 yes를 받아내는게 쉬워진다’라는 말씀을 해주시더라고요. 저희의 온보딩을 경험하면서 저희가 던졌던 작은 질문들과 사람들의 답변이 결국 전환율에 유의미한 영향을 준 것이죠.
가설과 직관이 충돌할 때 고객의 니즈는 실험만이 알려줄 수 있다는 말씀이시네요.
이렇게 생각이 잡히고 나서 다시 퍼널을 보니 유저의 몰입을 방해하는 요소들이 보였고요. 하나씩 최적화시켜나갔고, 현재는 2분이 넘는 온보딩을 가지고 있지만 전보다 높은 전환율을 기록하고 있습니다.
유저의 편의성보다 유저의 몰입에 집중하는 것도 좋은 인사이트네요.
창업가들이 A/B 테스트를 하면서 쉽게 놓칠 수 있는 부분에는 어떤 것이있을까요?
한 번은 커뮤니티 탭에 투표기능을 추가해서 A/B 테스트를 한 적이 있어요. 예를 들면 ‘평소에 자는 자세는?’이라는 질문에 왼쪽, 오른쪽 이렇게 답하는거죠. 아무래도 A/B 테스트라는게 새로운 기능에 대해 홍보하는게 어렵잖아요. 그래서 이번에도 홍보 없이 사람들이 투표 기능 자체에 가치를 느끼는지 확인하고 싶었어요.
결론부터 말하면 실패한 실험이었습니다. 커뮤니티 탭에 한 번이라도 들어온 사람들은 결제율과 리텐션이 모두 높았어요. 문제는 지표가 높은 이유가 투표 기능 때문인지 아닌지 알 수 없다는 것이죠. 왜냐하면 A/B로 비교하니까 지표에 차이가 없었거든요. 이외에도 굉장히 많은 실험을 했는데 비슷한 이유로 실패했어요.
그래서 저희가 얻었던 가장 큰 교훈은 실험군에 속한 사람들에게는 새로운 업데이트에 소식을 진짜 열심히 알려야한다는 것이에요.
물론 B2C 특성상 주변사람들 때문에 알 수도 있겠죠. 그래도 일단 실험군한테는 새로운 업데이트가 있다는 사실을 우리가 무조건 알려보자는 생각으로 실험을 진행하고 있어요.
팀 문화에 대해서도 궁금해요.
사실 지난 번에 디스콰이엇 팀과 식사할 때도 느꼈지만,
무니스 팀의 에너지 레벨이 상당한 것 같아요.
HR 컨설턴트 분이 저희 회의를 보시고 ‘삼성에서는 3개월 동안 할 의사결정들이 여기서는 2시간 안에 일어나는게 대단하네요’라는 피드백을 주셨어요. 저희가 대화의 밀도도 높고, 소통도 많이 하고, 화제 전환도 빠르게 되는 편인 것 같아요.
그리고 이런 팀을 만들 수 있었던 것은 아무래도 채용의 영향이 크죠. 도언님한테도 조언을 많이 받았지만, 내부적으로 견고하니까 새로운 팀원이 들어와도 길을 잃지 않고 문화에 잘 스며드는 것 같아요. 어제 새로 오신 분들은 새벽 5시까지 일하다 가시더라고요.
조직적으로도 변화가 있었는데요, 예전에는 프로덕트 팀과 오퍼레이션 팀을 따로 운영했었습니다. 그렇다보니 사일로 현상이 생기더라고요. 서로 무슨 일을 하는지 잘 모르는거죠.
그래서 지금은 1인 1PM 체제로 바꿨습니다.
매주 각자 진행할 실험과 진행한 실험에 대해 공유하고 소통하는 시간을 가지면서 개발자의 도움이 필요하면 요청하기도 하고, 실험에 대한 피드백도 주는 것이죠.
저는 이 시간이 너무 좋은 것 같아요. ‘이번 주에는 어떤 KPI를 높이기 위해 무슨 액션을 하지?’를 매주 상상하다 보니 빠른 액션을 위한 트리거가 되어주는 느낌입니다.
일하다가도 둘이서 하나의 안건에 대해 이야기하고 있다가도 팀원들이 오가면서 그 대화에 한 명씩 끼기 시작해요. 물 마시러 가다가 합류하거나 화장실을 가다 합류하는거죠. 이어폰을 끼고 있어도 밖에서 말하는 소리는 들리는거 어떤 건지 아시죠? 그렇게 결국 다 같이 이야기하면서 새로운 아이디어를 만들어내고, 또 그걸 빨리 실행하게 돼요.
팀원 분들과의 라포형성이 엄청 잘 되어있지 않으면 힘든 문화 같아요.
굉장히 좋은 문화를 만들고 계시네요.
주변에 회사 이야기를 하면 응답하라 1988의 동네골목 같다는 이야기를 들어요. 되게 정이 많고 사람 한 명 한 명의 캐릭터가 명확해서 재미있는거죠. 드라마 속으로 들어온 느낌이랄까. 그래서 이 조직 안에 있는게 너무 재미있어요. 당연히 예기치 않게 힘든 일도 많기는 하지만 하나씩 풀어가면서 진짜 가족 같은 팀이 되어가고 있어요.
그리고 여기서 그치지 않고, 저희는 목표 KPI를 달성했을 때 재화 보상을 줘요. 월 보너스죠. 두터운 유대감과 적절한 인센티브가 무니스만의 팀 문화를 더 강화시키는 것 같아요.
그리고 아쉬운게, 이제 곧 마루를 나가시잖아요.
지금까지의 마루민 경험에 대해 들려주세요.
아 이거는 정말 말하고 싶은게 채용에 도움이 돼요. 면접자분들이 마루로 인터뷰 오기 전에 자연스럽게 디스콰이엇에 적힌 무니스의 글을 읽어보고 오세요. 그러면 인터뷰를 끝내고 ‘혹시 디스콰이엇 아세요?’ 물어보고, 안다고 하시면 디스콰이엇 사무실로 데려가는거죠. 사실 어디가서 아는 스타트업 만나는게 쉽지 않잖아요. 이게 정말 복지에요. 그 순간 신뢰도가 확 올라가고 이 공간에 대한 동경이 생기는 것 같아요.
뿐만 아니라 여러 스타트업들이 모인 오피스에 처음 온 사람들은 이 커뮤니티에 대해 가치를 크게 느끼시는 것 같아요. 사실 마루가 다른 팀과 협업하기에도 좋은 곳이잖아요.
(디스콰이엇은 내년 3월까지 마루에 있습니다! 빨리 들어오시면 이 채용전략을 써먹으실 수 있어요 ㅎㅎ)
마지막으로, 마루 지원서에 어떻게 Pay it forward할지 물어보는 문항이 있어요.
많은 분들이 어려워하시더라고요. 어떻게 적으셨나요?
아무래도 저희는 웰니스 쪽이다 보니 창업가 분들의 웰니스를 위해 기여할 수 있는 부분을 적었어요. 다들 아시다시피, 창업가분들이 우울증에 많이 걸리잖아요. 강도 높은 일을 계속 하고 있기 때문에 멘탈리티가 좋지 않고. 그래서 이런 쪽으로 지원해야겠다 싶었고, 실제로 마루 타운홀 미팅을 할 때 무료 이용권을 창업가 분들에게 공유드리기도 했어요.
이외에도 제가 대단한 창업가는 아니지만 공유할 수 있는 인사이트가 있다면 언제든지 공유하면서 도움을 드리기도 했었고요.
좋은 공유 오피스는 많지만,
좋은 사람을 만나는게 참 어려운 것 같습니다. 저희는 내년 3월까지 있습니다.
마루에 입주하시고 함께 야근도 하고 식사도 할 동료 팀이 될 분들을 기다리고 있을게요.
외롭지 않은 창업을 위해 마루에 지원해보세요 :)
(업데이트) 마루에서 2024 하반기 입주사를 찾고 있습니다!
링크 : https://asan-nanum.org/notice/2024-2nd-maru-startup-apply/
이현석
치킨랭크
당신의 최애 치킨은 무엇인가요?
JD
현재 저희 창업 팀에서 FE 개발자 분을 모시고 있는데, 관련해서 이야기 나누어 보실 분 계실까요?
홍지영
지금부터 이각세 팀의 praise up 서비스를 기획한 여정 A부터 Z까지를 말씀드릴게요.
목차
praise up은 어떤 서비스 인가요?
praise up을 만들게 된 계기는 어떻게 되나요?
디자인팀에게 주어진 챌린지...!를 이렇게 해결해봤어요
개발팀에게 주어진 챌린지...!를 이렇게 해결해봤어요
praise up의 추후계획
🔮 praise up은 어떤 서비스 인가요?
제목에서 유추할 수 있듯이, praise up은 서로에게 칭찬을 부담 없이 주고받을 수 있는 서비스에요!
유저는 날마다 제공되는 다른 키워드에 따라 오늘의 칭찬 받을 순간을 작성하고 작성한 게시글을 지인들과 공유해서 칭찬 메시지를 받아볼 수 있어요.
이때 서비스를 이용하는 과정에서 칭찬 구슬을 이용한 다양한 인터랙션을 접하고, 재치 있는 이미지를 함께 활용해 칭찬을 남길 수 있다는 점이 저희 서비스만의 큰 특징이에요.
🔮 praise up을 만들게 된 계기는 어떻게 되나요?
praise up은 인스타그램과 같은 기존 SNS에서 느끼는 피로감을 해소하려는 목적에서 시작된 서비스에요.
‘무조건 칭찬만 하는 구조로 SNS를 통한 긍정적인 경험을 제안하자!’ 라는 아이디어에서 출발했으며, 아래의 유저 리서치와 데스크 리서치를 기반으로 방향성을 확고하게 다져나갔어요.
💡 SNS를 이용하며 피로감을 느끼고 있었던 많은 사람들
87명이 응답한 설문 결과, 70%가 넘는 사람들이 기존 SNS 경험에서 피로감을 느끼고 있었어요.
특히 상대방의 콘텐츠를 보고 느끼는 상대적 박탈감과, 부정적인 콘텐츠로부터 느끼는 피로감이 가장 큰 비중을 차지했어요. 🥲
💡 칭찬, 격려 등의 긍정적인 메시지 활용에 대한 가능성 발견
SNS의 피로감을 어떻게 해소할 수 있을지 고민하며 데스크 리서치도 진행했어요.
마침 미국에서 긍정적인 메시지로 서로의 자존감을 북돋아 주는 서비스 ‘gas’가 SNS에서 피로감을 느꼈던 유저들에게 큰 인기였다는 사실을 발견했어요. 또한 SNS에서 긍정적인 콘텐츠를 읽은 사람들의 경우 우울감이 낮아진다는 논문의 내용을 근거로 하여, SNS에서 느끼는 피로감을 긍정적인 메시지로 해소할 수 있는 것에 대한 가능성을 발견했습니다.
💡 그러나, 긍정적인 메시지인 칭찬을 전달하는 것에 대한 부담이 존재
하지만, 생각보다 많은 사람들이 칭찬을 전달하는 것에 대한 부담을 느끼고 있었어요. 설문조사에 따르면 ‘직접 칭찬을 건네는 것이 쑥스러워서' 의 이유가 가장 많은 응답을 차지했어요.
위의 리서치 내용을 종합하여 저희 팀이 정한 방향성은 아래와 같았어요.
➡️ 이미지를 이용해 익명으로 칭찬을 부담없이 주고 받을 수 있게 하여 서로에게 긍정적인 영향을 줄 수 있으면 어떨까?
이런 기획의 과정을 거쳐 ‘이미지로 소통하는 칭찬 SNS, praise up’이 탄생했어요. 🥳
🔮 디자인팀에게 주어진 챌린지...!를 이렇게 해결해봤어요
더 좋은 서비스를 위한 고민 : 피로감을 어떻게 풀어내야 할까?🤔
기존 SNS에서의 피로감을 풀어내고자 하는 것이 서비스의 목적이었지만, ‘칭찬'이라는 요소만으로는 2% 부족하다는 생각이 들었어요. 사용자들이 서비스를 이용하며 칭찬 말고도 우리의 서비스를 이용하고 싶은 이유를 더하고 싶었는데, 그건 바로 ‘재미’의 요소였습니다. 작은 핸드폰 화면 내에서 '어떻게 하면 효과적으로 사용자의 피로감을 해소할 수 있을까?' 고민했고 두 가지의 방법을 모색했답니다.
☝🏻 일반적이지 않은 인터랙션을 이용해 서비스를 사용하는 동안 재미를 느낄 수 있게 하자 ✨
일상적으로 많이 사용하는 앱 서비스들에선 서비스의 플로우가 자연스러워 보이도록 하는 인터랙션들을 많이 사용하고 있었어요. 자연스러운 인터랙션에 익숙해져 있을 때, 위치를 기반으로 하는 ‘Z' 서비스를 사용했는데요, 화려한 인터랙션으로 첫 사용부터 너무 재미있게 썼던 기억이 있었어요!
이 기억을 기반으로 praise up에서도 특별한 인터랙션으로 사용자들의 관심을 끌어보자는 목표를 세웠답니다.
🤞🏻 칭찬을 시각적으로 예쁘게 보일 수 있는 모티프를 이용하자 ✨
칭찬, 듣기만 해도 기분이 좋아지죠!
하지만 저희의 서비스에선 칭찬을 말로 들을 수 없답니다. 🥲 지인들이 남긴 칭찬을 두 눈으로 보고 읽어야 해요!
지인들이 남겨준 소중한 칭찬, 보기만 해도 기분이 좋아지겠죠? 이에 더해 칭찬이 시각적으로도 예쁘게 생기면 더 기분이 좋아지겠죠?
그래서 저희는 칭찬을 예쁜 구슬에 담기로 결정했답니다!✨ 듣기에도 좋은 칭찬, 보기에도 좋게 말이죠!
더 좋은 협업을 위한 고민 : 화면을 어떻게 개발자들에게 전달해야 효율적으로 서비스를 만들 수 있을까?
화면설계서.... 너무 쓰기 싫었어요. 😇
화면 설계서는 숫자 알파벳 등 이런저런 기호들을 넣어가면서 문서화하는 과정에서 많은 품이 들지만
화면 flow를 직관적으로 살펴볼 수 없다는 지점이 큰 단점으로 느껴졌어요. 기획 과정에도 함께 참여한 개발자들이 서비스에 대한 이해도가 높아야 QA과정을 단축하고 완성도가 높은 서비스를 빠르게 완성할 수 있을텐데 기능들의 flow를 살피기 어렵다는건 효율성이 떨어지는 방식이라고 생각했어요.
이를 해결하기 위해서 단순하게 접근했는데요, 피그마를 이용했답니다!
화면 설계서에 작성해야 하는 내용들을 피그마에 똑같이 넣는 대신, 타이틀바를 이용해 기능별 flow에 해당하는 화면들을 순차적으로 묶어 개발자들도 flow를 한눈에 확인하기 쉽도록 제작했어요.
🔮 개발팀에게 주어진 챌린지...!를 이렇게 해결해봤어요
🚀 서버 파트에서는 ‘헥사고날' 아키텍쳐를 도입했어요
서버 파트에서는 서비스에 맞는 ‘아키텍처' 에 대해 많이 고민했어요. 기존에 많이 사용하는 ‘모놀로식' 아키텍처에서 벗어나 ‘멀티 모듈’을 적용할지, 한 번도 사용해 보지 못했던 ‘헥사고날’ 아키텍처를 적용할지 많이 고민하고 개발을 시작했습니다. 고민하는 과정에서 멀티 모듈로 가져가기에는 저희 서비스의 도메인이 너무 간단하고, 각 모듈이 담당할 기능의 크기가 작다고 판단했어요.
따라서 헥사고날 아키텍처를 공부하며 도입하는 것을 저희의 도전 과제로 삼았습니다.
먼저 헥사고날 아키텍처는 핵심적인 비즈니스 로직과, 외부 로직이 분리되어 있어 코드의 가독성이 올라갔습니다. 또한 테스트도 정말 편리했어요. 하지만 결합도를 낮추기 위한 port, adapter와 같은 파일들이 많아져 패키지 depth가 깊어지기 때문에 구조 파악이 힘들다는 단점이 있었습니다.
추후에 서버 파트는 이 헥사고날 아키텍처를 유지하며, 서비스의 여러 확장성을 고려해 멀티 모듈로 전환할 계획이에요.
🚀 웹 파트에서는 다양한 인터랙션을 구현했어요.
저희 praise up 서비스에는 정말 많은 인터랙션이 포함되어 있어요. 따라서 웹 파트에서는 저희의 서비스 최고 매력 요소인 ‘인터랙션' 구현을 도전 과제로 삼았습니다.
짧은 시간 내에 많은 인터랙션 요소를 효율적으로 구현하기 위해 디자인을 기반으로 SwiperJS, MatterJS, Framer 라이브러리를 도입했습니다. 하지만 저희의 인터랙션은 단순히 라이브러리의 내장 기능만으로는 구현할 수 없는 부분들이 몇 가지 있었어요.
저희 서비스의 대표적인 두 화면과 각각의 구현 과정을 소개할게요.
☝🏻 칭찬 키워드 선택 화면
게시글을 작성하기 전, 오늘의 칭찬 키워드를 선택하는 화면이에요.
가로 슬라이드 모션과 동시에 구슬과 백그라운드가 돌아가야 하기 때문에 SwiperJS의 회전 상태 값에 따라 구슬과 백그라운드의 rotate 값을 변경하면서 해당 인터랙션을 구현할 수 있었어요.
구슬 키워드의 경우, 구슬을 Y축으로 드래그 시에 키워드가 따라가도록 framer의 useAnimiation을 이용한 구슬의 위칫값 추적 이벤트 구현으로 키워드가 같이 자연스레 올라갈 수 있는 인터랙션을 구현할 수 있었어요.
🤞🏻 받은 칭찬 메시지 확인하는 화면
아래 화면은 받은 칭찬 메세지를 확인할 수 있는 아카이브 화면이에요.
먼저 해당 화면은 Javascript 2D obejct 라이브러리 MatterJS를 기반으로 만들어졌어요. 받은 칭찬 메세지의 개수에 따라 여러 텍스처를 가진 구슬들이 떨어지는 기능은 쉽게 구현할 수 있었습니다.
다만 저희 서비스의 화면에는 2d object에 칭찬 메세지를 보낸 친구의 닉네임이 랜더링 되어야 하는 요구사항이 있었어요. 🤔 이 부분은 MatterJS 라이브러리에서 지원하지 않는 기능으로 저희는 라이브러리 내부 코드를 일부 수정하게 되었습니다.
MatterJS에 그려지는 Body object 코드를 분석한 뒤 object가 그려지는 코드를 가져와, canvas object가 그려지는 위치에 텍스트를 함께 그려주는 기능을 추가했어요. 또한 글씨체, 색상, 크기는 외부에서 주입받아 사용할 수 있도록 작성했기 때문에, 라이브러리에 옵션을 넣어주듯이 쉽게 사용할 수 있었습니다.
웹 파트는 다양한 인터랙션 구현을 위해 대부분의 시간을 소요했어요. 따라서 코드의 퀄리티와 가독성이 좋지 않다고 생각해요. 앞으로 많은 도전 과제가 남아있지만, 그중에서도 코드 리팩토링을 1순위로 진행하며 열심히 서비스를 개발해 나갈 예정입니다. 💪🏻
🔮 praise up의 추후계획
praise up은 지속적인 유지보수를 통해 앞으로 더 발전할 계획입니다!
우선은 아래와 같은 계획을 갖고 있어요.
⚡️어플리케이션 지원 및 소셜 로그인의 다양화
어플리케이션 지원을 통해 보다 더욱 편리한 접근성을 제공하고 푸쉬알림을 구현해 유저 리텐션을 높이려고해요.
또한 기존의 카카오톡 로그인과 더불어 더 많은 종류의 소셜 로그인을 지원하려고 합니다!
⚡️유저들의 피드백에서 많이 언급되었던 기능 개선
기존에 칭찬 메시지를 남길 때 이미지를 활용하는 것에 대한 장벽 문제를 해결하고 칭찬 공개까지의 시간 텀이 길다는 문제를 해결하려고 해요.
⚡️GA기반 데이터 분석을 통해서 사용자의 UX경험 개선
⚡️개발 팀의 개발 환경 개선
클린 코드를 위한 전반적인 리팩토링을 진행하고 일부 원활한 서비스 제공을 위한 SSR 마이그레이션을 진행할 예정입니다.
저희의 애정어린 긴 메이커 로그 읽어주셔서 진심으로 감사합니다.
앞으로도 꾸준히 발전해 나갈 저희 praise up을 지켜봐주시면 감사하겠습니다. 모두들 좋은 하루 되세요 😊
🔮 praise up 서비스 사용해보러 가기
[서비스 피드백 구글폼 링크]
praise up 서비스를 이용해 보신 후 아래의 구글폼 링크에 피드백을 자유롭게 남겨주세요🍀
praise up
친구와 함께 소중한 칭찬구슬을 주고받아보세요!
이병우
현재 만들고 있는 프로덕트를 개선하기 위해 챗GPT와 대화를 나눠봤습니다. 그동안 개발이 막힐 때만 챗GPT한테 질문을 했었는데, 이렇게도 활용할 수 있다는 생각은 못 했었네요! 업무 과정에서 챗GPT를 활용하는 방법 뉴스레터와 ChatGPT로 프로덕트 디자인 시간을 줄일 수 있을까 아티클을 읽고, 한번 실제로 제가 만들고 있는 프로덕트에 대해 물어보았습니다.
우선 어떤 서비스인지 한 문장으로 알려주고, 왜 이 서비스를 구상하게 되었는지 문제 상황과 핵심적인 특징들을 정리하여 알려주었습니다. 그리고 서비스 이름을 알려주고, 저와 함께 서비스를 만들고 있는 프로덕트 디자이너라는 역할을 부여했죠.
결론적으로, 저의 프롬프트가 미숙해서인지 혹은 3.5의 한계인지 만족스러운 답변은 얻지 못했습니다. 하지만 잠깐 해본 건데도 큰 장점을 느꼈습니다! 챗GPT에게 잘 전달하기 위해 저도 서비스의 기획적인 부분을 한 번 더 잘 정리 해보게 되었고, 함께 서비스에 대해 의견을 나눠보는 행위 자체에서 제가 발상을 좀 더 넓힐 수 있는 계기가 되었기 때문입니다. 역시 질문하는 역량을 키워야겠습니다. 또한… 4.0을 빨리 사용하고 싶단 생각이 드네요!
김주형
오늘 하루 딱 한가지만 일하려 노력했으나 좀 어려웠습니다
왜냐하면 김봉진 님께서 꾸준히 뭔가 하는 습관을 들이라시길래
달력을 딱 한칸만 지우는게 실제로 굉장히 어렵다 라는 말에서 영감을 얻었슴다
도서
해빗읽었습니다환경 재배열을 나의 상황에 적용할 방법을 고민했슴다
참고
느낀점을 정리해야 하는데에에에 쉽지가 않습니다
북극성 지표에 관해 관심 생겨 학습 중