3개월간 경험한 사내 목적 조직 후기 2023
올해 1월부터 지금까지 약 3개월 동안 택시 앱에서 유저가 택시를 성공적으로 호출할 수 있도록 그 호출과정을 개선하는 목적조직을 경험했다. 이전 목적조직에 대한 회고 글 에 이어 이번에도 어떤 부분을 원했고, 어떤 일을 하였는지를 중심으로 회고를 써보려고 한다. (이전 글을 읽고 보면 또 색다른 재미가 있긴하다.)
이전 글은 목적조직에서 구성원들의 목적에 대한 공감대를 형성하는 과정 / 협업 프로세스의 개선 사이클 에 대한 이야기가 중심적이었다면, 이번 글은 실험을 통한 데이터 기반의 제품 개선 경험 을 다루려고 한다.
합류 과정
간단하게 왜 목적조직에 참여하고자 했는지를 두 가지 측면에서 이야기해보려고 한다.
주니어(?) 서버 개발자는 기능 개발을 하고 싶다
목적조직 참여와 별개로 모바일 클라이언트 개발자 -> 서버 개발자로의 포지션 변경을 했다. (자세한 내용은 다른 글로 설명해 보려고 한다.) 클라이언트 개발은 나름 오랜 경험을 통해서 축적된 지식/짬밥(?)이 있었다면 이제 서버 개발자로 포지션 변경을 했으니 사실상 연차가 초기화 된거나 다름없었다.
zero 에서 부터 다시 시작하는 서버 개발인 만큼, 모바일 팀에서 도맡아 하던 코드 베이스의 기반을 닦는 플랫폼 개발보다는 마구마구 뱉어져 나오는 피쳐 개발 을 통해 서버 생태계의 코드를 많이 작성하는 경험을 쌓아보는 것이 중요하다고 생각했다. 목적조직에 참여하는 것은 곧 빠르고 다양한 피쳐 개발을 의미하기에 안성맞춤이라고 생각하고 있었다.
제품을 통해 비즈니스에 영향을 줄 수 있는가?
택시 앱을 개발하면서 제품이 비즈니스에 큰 영향을 줄 수 있는가? 에 대한 회의를 많이 가져왔다. 택시라는 오프라인 비즈니스의 특성상 제품 외적인 택시 업계나 시장의 상황에 따라 회사의 지표들이 크게 흔들리는 상황을 자주 목격해 왔다. 그럴 때마다 내가 하는 제품의 개발이 실제로 "중요한" 일인가? 에 대한 의심을 자주 가지곤 했다.
CTO 님을 비롯한 다른 분들과도 이에 대한 이야기를 나눠보았고, 결국 제품의 개선으로 비즈니스 영향을 만들고 데이터로 증명할 수 있는지 직접 부딪혀 보자! 라는 결론으로 돌아오게 되었다.
이전에는 부끄럽지만, 기술과 커리어 성장에 집중하다 보니 비즈니스의 영향을 위해 모든 노력을 기울인다! 라는 자세로 일한 적이 잦지 않았고, 물 흐르듯 주어진 개발을 해 왔던 것 같다...
그만큼 개발만 하기 보단 직접 데이터를 통해 문제를 정의하고 임팩트를 만들 수 있는 가설을 세우고, 결과를 판단을 하는 일에 직접 참여하는 것에 목말라 있었다. (특히 이전 목적조직 회고에서 아쉬운 부분이었던 만큼...!)
합류
이런 니즈를 지속적으로 호소해 왔고, 결국 올해 초 실험을 통한 제품 개선에 능숙한 PO 분이 계시는 목적조직에 서버 개발자로 합류하게 되었다.
- 주니어 서버 개발자의 성장을 위한 폭풍 피쳐 개발
- 데이터를 중심으로 사고하고 제품을 개선하여 비즈니스 임팩트를 만드는 경험
이 두 부분을 기대하고 합류하여 현재까지 3개월간 목적조직을 경험하였다.
3개월간 경험한 목적조직
조직에서 일했던 문제 정의 -> 가설 도출 -> 가설 증명의 사이클에 맞추어 어떻게 일을 하였는지를 회고해본다.
유저의 택시 호출 여정을 살펴보며 문제를 정의한다.
택시를 호출하는 승객의 앱 사용 여정을 떠올려 보자면 여러가지 장애요소들이 있을 수 있다. 가격이 비싸다, 할인을 제대로 받을 수 없다, 주변에 택시가 없다, 앱 조작에 미숙하다 등등...
목적조직에서는 정석적으로 장애들이 어디에서 발생하고 있는지 App Open -> 호출 까지의 과정에서 Churn 되는 유저의 비율들을 꼼꼼히 살펴보면서 문제를 정의하기 시작했다. 각 퍼널간의 전환율이나, 메인 퍼널을 이탈할 경우 어느 쪽으로 유저의 이탈이 발생하는지, 신규/기존 유저의 코호트 별로 나타나는 경향성은 어떤 것이 있는지 많은 데이터를 보기 시작했다.
이 과정에서 최근 전사적으로 도입한 앰플리튜드의 퍼널 차트가 아주 유용하게 쓰였다. 복잡한 쿼리문 없이도 GUI 를 통해 내가 보고 싶은 데이터를 아주 잘 보여주는게 정말 좋은 툴이었다.
문제 해결의 가설을 세워본다.
위 데이터를 기반으로 문제를 정의하였다면 해결을 위한 다양한 가설을 세워볼 수 있었다. 구체적인 예를 들 수는 없지만, 퍼널에서 귀찮은 일을 해야하는 곳에서 유저의 이탈이 많이 발생하는데 이걸 앱이 제안하는 가치를 제대로 보고 나서 할 수 있도록 미뤄준다면 어떨까? 타사 대비 ~의 사용성이 상이해 신규 가입 유저가 어색함을 느껴 전환율이 떨어지는 것 같다. 등등...
이런 식의 가설들이 세워지면 멋진 프로덕트 디자이너 분들이 빠르게 가설을 기반으로 만들어진 UX 를 보여주시고 개발팀과 함께 ROI 를 산정하며 제품 개발에 들어가게 되었다.
실험을 통해 가설을 증명한다.
이제 만들어진 제품을 유저에게 제공하고 그 피드백을 통해 가설을 증명해야 한다. 우리 조직에서는 모든 개선을 A/B 테스팅을 통해 유의성을 검증하였다. 무작위의 유저군을 배정하여 기존 UX 와 변경된 UX 를 각각 제공하고 실험군과 대조군의 지표 차이를 분석하게 되면, 거의 모든 변인을 통제한 채로 UX 의 변화에 대한 영향만을 볼 수 있으므로 실제로 우리가 만든 제품 개선이 어떤 영향을 만들고 있는지 잘 파악할 수 있었다.
개인적으로도 정확한 영향력을 판단할 수 있는 부분에서 마음에 드는 과정이었다. 특히 이 과정에서 멋진 인터널 개발팀이 만들어주신 사내 AB Testing 서비스와의 연동을 통해 좀 더 쉽게 실험의 진행 상황들을 볼 수 있어서 더욱 편하게 실험을 해 볼 수 있어 더더욱 만족스러웠던 것 같다.
AB Testing 을 통해 제품 개선의 결과를 명확하게 파악하고 지표 개선과 레슨런을 차곡차곡 쌓아가며 그 다음 문제 정의가 지속적으로 발생할 수 있었다. 퍼널에서 귀찮은 과정을 뒤로 뺐더니 확실히 최종적인 전환율이 올라갔지만, 그래도 여전히 귀찮은 과정이 큰 블로커다. 이걸 해결하는게 큰 임팩트가 될 수 있다 라던가, 특정 형태로 혜택을 노출하는 것은 큰 효과가 없는 것 같으니 이 안은 앞으로도 사용하지 말자 라던가...
결론
위와 같은 과정을 통해서 3개월간 목적조직에 참여하고 있고, 결론적으로 현재에도 계속 임팩트를 정확하게 측정하며 꾸준한 제품 개선과 실제 (측정가능하고) 유의미한 택시 호출율의 개선을 만들어 가고 있는 중이다! 사실상 글 초반에 이야기한 서버 개발자로 피쳐 마구마구 찍어내기나, 제품을 통한 비즈니스 임팩트 만들기 두 부분을 다 충족하면서 꾸준히 성장하고 있는 중이다 :happy_cat:
사실 이렇게 만족스럽게 일할 수 있었던 것은 조직 구성원분들의 덕이 너무 크다. 실험을 통한 제품 개선에 능숙하고, 좋은 가설을 제시하고 구현할 수 있는 PO, 디자이너, 개발자 분들이 계시기 때문에 정말 옆에서 많이 배우고 있는 중이다. (앞서 글을 작성하며 개발에 대한 이야기는 많이 하지 못하였지만, 목적조직 내의 서버 개발자가 나 포함 2명이 있기 때문에 티키타카 하면서 정말 빠르게 Spring, MySQL 등등에 적응해 나가는 중이다.)
또한 적절한 툴을 사용해서 생산성을 끌어올리는 것이 너무 중요하다는 것을 깨닿고 있는 중이기도 하다.
이전에도 데이터를 보고 싶어 했지만, 사실상 빅쿼리 만을 사용하고 있을 때는 데이터 접근성이 그렇게 높지 못했고, 결국 데이터 팀을 통해서 필요한 데이터를 뽑아보아야 했다. 하지만 앰플리튜드와 같이 데이터 리터러시를 크게 끌어올려주는 툴이 도입되니 모두가 데이터를 기반으로 판단하는 것이 정말 쉬워졌고 그만큼 자연스럽고 당연해진 느낌이다.
또한 사내에서 제공하는 AB Testing 서비스 덕분에 불필요한 과정 없이 GUI 쉽게 실험을 계획하고 테스팅 할 수 있어 구성원 모두의 실험 친화도 또한 정말 높아졌다.
여튼 회고에서 좋은말 밖에 없긴 한데 재밌게 일하고 있고, 앞으로도 꾸준히 요렇게 일을 계속 해보려고 한다 :)