목적 조직에서의 DA가 하는 일
안녕하세요, 29CM 데이터 그로스 팀의 데이터 분석가 최혜린입니다.
데이터 그로스 팀의 분석가들은 기능 조직인 데이터 그로스 팀에 속하지만, 동시에 목적 조직인 스쿼드에서도 일하고 있습니다. 29CM의 스쿼드는 23년 3월 현재 8개의 스쿼드가 운영중이며, 제가 속한 구매경험 스쿼드에서는 상품을 발견하는 유저들이 해당 상품을 구매하게 만들기 위한 경험을 개선하고 있습니다.
이번 포스팅에서는 목적 조직 내에서 데이터 분석가가 어떤 역할을 하는지 소개하겠습니다.
제품 개선을 위한 실행 사이클 내에서도 데이터 기반의 의사결정을 위해 분석가는 많은 부분을 기여하게 됩니다. 실행 사이클을 아래와 같이 단순화하여 각 단계별로 어떤 역할을 하는지 공유드리겠습니다.
[0]문제 정의
처음에는 문제 정의가 바로 이루어져야 합니다. 이 단계가 잘 처리되어야 기획과 분석 단계가 원활하게 진행될 수 있기 때문입니다. 문제정의는 아래와 같은 4단계를 거치게 됩니다.
- 문제 발견
- 문제 정의 : 문제로 보이는 현상에 대한 원인을 정의합니다.
- 문제의 크기 판단 : 분석가는 불편함을 겪는 사람이 얼마나 많은지 파악하여 액션의 임팩트 크기를 확인합니다. 실행 배경이더라도, 정성적 정보와 정량적 정보가 결합되어 있어야 합니다.
- 가설 수립 : 원인을 해소할 수 있는 방법과 그에 따른 기대 효과를 문장으로 정의합니다.
문제점과 기회를 발견하면 누구든지 개선 의견을 제안할 수 있습니다. 분석가는 이 문제를 해결해야만 하는 실행의 당위성을 검증하고, 명확한 문제 정의와 가설 수립이 가능하도록 구체화하고 정량화할 수 있도록 지원합니다. 또한 문제와 가설이 논리적으로 잘 연결되는지 주의하여 확인합니다.
들여다보는 업무 일상 — 사전분석 : 문제의 우선순위 파악
구매 경험 스쿼드에서는 마음에 드는 상품을 발견한 사용자가 ‘이 상품이 내게 잘 맞을까?’하는 고민을 줄이기 위해 리뷰를 통해 이 정보를 얻을 수 있도록 하고자 합니다. 사이즈 리뷰 필터가 존재하지만, 이 고민이 아직 해결되지 않았다면 그 원인들을 추측해보고 가장 먼저 해결해야 하는 부분은 무엇인지 알고자 했습니다. 무엇이 큰 문제인지 확인해야 이후 실행할 수 있는 액션이 달라지기 때문입니다.
가장 먼저 어떻게 판단할 것인가에 대한 부분을 고민하고, 원인을 보여줄 수 있는 지표를 확인해나가기 시작했습니다. 여기서 주의해야 할 점은 원인 A를 보여줄 수 있는 지표가 다른 이유에 의해서도 바뀔 수 있는 가능성을 고민하고 확인해봐야 한다는 것입니다.
예를 들어, 문제의 원인 중 하나였던 ‘유저와 비슷한 사이즈가 포함된 리뷰의 수가 충분하지 않았는가’ 확인하고 싶었습니다. 그리고 이 원인이 맞는지를 위해 실제 유저가 사이즈 리뷰 필터를 사용하였을 때 마주하는 결과 수를 통해 알아보고자 했습니다. 그러자 결과 수 N개 이상을 확인한 유저의 비율의 숫자가 높았지만, 그렇다고 바로 유저와 비슷한 사이즈의 리뷰 수가 충분하구나 하고는 섣불리 판단할 수 없었습니다. 해당 지표가 높게 나올 수 있는 가능성은 두 가지가 있기 때문입니다.
- 진짜로 유저와 비슷한 체형의 리뷰 수가 많았다. (문제가 아님)
- 리뷰가 많이 뜨도록 자신의 체형 범위보다 넓게 설정하였다. (문제가 맞으나 지표로는 드러나지 않을 수 있음)
이 중 2의 가능성을 염두하고, 광범위하게 설정한 케이스를 추가로 확인하여 문제 여부를 제대로 판단할 수 있었습니다.
대부분의 문제는 단 하나의 원인에 의해서만 발생하는 것이 아닌 여러 가지가 영향을 미칠 수 있습니다. 이 경우, 실행 우선 순위를 위해 원인을 나열하여 긴급성을 파악하고, 이 과정에서 합리적인 의사 결정을 위해 데이터가 기반이 될 수 있도록 분석가의 역할이 중요합니다.
[1]실험 기획
문제 해결을 위한 UX 디자인이 완료된 후, 분석가는 정의한 문제가 treatment(실험군의 변경사항)로 인해 해결되었음을 증명할 수 있는 실험을 설계합니다.
1.지표 설정) 성과 측정을 위해 적절한 지표를 선택합니다.
- Primary Metric : 문제가 해결되면 변화할 것으로 예상되는 지표
- Secondary Metric : Primary Metric을 더 잘 이해할 수 있는 보조 지표
- Guardrail Metric : 해당 실험에서 부정적인 영향을 받을 수 있는 지표. 또는 궁극적으로 부정적인 영향을 받아서는 안되는 사용자 경험 지표
좋은 성과 지표는 단기간에 측정 가능하고, 민감하며, 장기 목표에 인과적 영향을 미치는 특성을 갖추어야 합니다.
2.롤아웃 시나리오 작성) 지표가 변화에 따른 의사결정(롤아웃, 롤백)을 어떻게 할 것인지에 대한 시나리오를 작성합니다.
시나리오 작성의 장점은 1) 적절한 지표를 설정하였는지에 대한 재점검과 2) 의사결정의 일관성 확보라는 두 가지 장점을 갖고 있습니다.
Primary Metric과 Secondary Metric 변화(상승, 유지, 하락)에 따라 행동을 해석하여 적어보면, 설정한 지표에 대한 재점검이 가능하게 됩니다. 문제가 해결되었는지를 알 수 있는 지표가 맞는지 혹은 단일 지표로는 확인이 불가능한 경우는 보완해 줄 수 있는 지표의 필요여부도 알 수 있습니다. 또한, 지표가 유지 혹은 하락이 되었을 때 레슨런을 위해서는 추가로 관찰해야 하는 지표는 무엇인지 등을 미리 고려할 수 있습니다.
롤아웃 시나리오 내에 행동에 대한 지표별 해석 뿐만 아니라 지표가 유지 혹은 하락이 되었을 때 롤백을 할 것인지 혹은 어떤 부분을 개선을 하여 재실험을 할 것 인지에 대해 미리 PO와 싱크를 맞춤으로써 의사결정에 대한 일관성을 확보할 수 있습니다.
실험 기획에서 설정한 지표는 실행의 결과를 판단하는 중요한 요소입니다. 그렇기 때문에 재점검을 할 수 있다는 이점과 다양한 경우에서의 다음 실행까지 고려하면서 이 실험에서 우리가 어떤 불확실성을 줄이고자 하는지 확실히 알 수 있다는 점에서 롤아웃시나리오를 작성 해보시는 것을 적극 추천드립니다.
[2]개발 및 QA
이벤트 설계 및 데이터 QA : 개발 과정에서는 분석가는 실험기획에서 설정한 지표를 측정하기 위해서 새로 측정할 필요가 있는 이벤트가 있다면, 이벤트를 설계하여 프론트엔드 개발자분들께 적재요청을 합니다. 기록은 현재 노션으로 진행중이며, 전체 이벤트들이 기록된 아카이빙 보드는 따로 두고 프로젝트 페이지 내에 해당 보드를 필터를 걸어서 끌어오고 있습니다. 이렇게 하면 개발 요청 이벤트와 아카이빙 이벤트를 두 번 기록하지 않아도 된다는 장점이 있습니다.
개발이 완료된 후, 실험 세팅을 점검하면서 각 직군마다 QA를 진행하는데 분석가는 새로 반영된 이벤트들이 의도한 트리거에 맞게 주요 파라미터들이 저장되고 있는지 확인합니다.
들여다 보는 업무 일상 — 이벤트 설계 : 일관성
이벤트 설계는 기본적으로 컨벤션에 맞게 작성하되, 동일한 기능이나 비슷한 영역 내 이벤트들을 참고하면서 통일성을 가져야 합니다. 위 예시 중 이벤트 내 파라미터로 라이크한 상품 수(item_like_count)와 필터 결과 수(cnt_result)를 보면, 집계를 뜻하는 의미가 count와 cnt가 혼용되고 있고, 위치 역시 다른 모습을 볼 수 있습니다(🍠). 그 이유는 바로 연관된 이벤트들과의 통일성을 가져가면서 생긴 현상입니다. 새로 적재하는 두 이벤트는 모두 라이크 메인에서 일어나는 행동인데, 라이크 메인 페이지 방문 시 찍히는 이벤트 내에 먼저 찍히고 있던 동일한 정보를 담은 파라미터명(item_like_count)을 참고하였고, 필터의 결과 수를 의미하는 파라미터명은 기존에 찍히는 다른 필터 이벤트에서는 결과 수를 cnt_result로 적재하고 있었기 때문에 이 역시 동일한 역할의 이벤트를 참고하였습니다.
이러한 문제는 최소한의 컨벤션은 있지만 모든 것을 아우를 수 없고, 여러 사람이 각기 다른 시기에 적재를 하면서 생기는 차이로 인해 발생합니다. 이런 부분은 스쿼드 차원이 아닌 전사 데이터 거버넌스와 관련이 있는 문제이기 때문에, 기능 조직인 데이터 그로스 팀 내에서 동료 DA들과 흩어져 있는 이벤트 문서를 모으고 관리하는 방법을 체계화하고자 노력하고 있습니다. 동시에 이런 이슈들에 잘 대응하기 위하여 이벤트 설계 이슈 아카이빙을 시작하였습니다. 이벤트 설계는 기존에는 PO가 진행을 하다가 각 스쿼드에 DA가 충원되기 시작한 시점부터 맡아서 하게 되어서, 현재는 전체 개편보다는 발생하는 문제들을 모은 이후에 풀어갈 방법을 고민하고 있습니다.
들여다 보는 업무 일상 — 이벤트 설계 : 트리거와 QA
이벤트는 추후 활용 의도에 맞게 적절할 때 찍혀야 합니다. “클릭”이라는 행동은 명확하지만, “노출”과 같은 이벤트에서는 다양한 기준점(어디까지 봐야 노출되었다고 할 것인지, 여러 번 노출될 경우 중복 적재를 할 것인지)에 대해서도 미리 고려되어야 합니다. 리뷰의 전달성과 CTR 민감도를 높이기 위해 리뷰 구역에 노출되는 유저가 얼마나 있는지 알기 위해 노출 이벤트를 적재하고자 했습니다. 그 과정에서 프론트엔드 개발자분과 소통을 통해 마지막 리뷰 노출 기준으로 트리거 조정이 가능하다는 점과 또한 같은 화면 내 스크롤 이동과 리뷰 영역 내 depth가 있는 곳 방문 후 뒤로 가기로 진입하여도 추가 적재를 하지 않는 방법 역시 가능하다는 것을 알고 진행할 수 있었습니다.
또한, QA를 하면서 다양한 케이스에서의 적재를 확인하다보면 미처 생각하지 못했던 부분도 발견할 수 있습니다.
리뷰 구좌 노출 이벤트를 설계하면서 유저가 리뷰 구좌를 인식할 정도로 노출되었다 라고 판단 할 수 있는 기준을 ‘마지막 텍스트 리뷰가 노출되었을 때’라고 생각하였지만, 유저가 자주 하는 행동인 리뷰 바로가기 버튼을 누르면 포토 리뷰가 6개 이상인 경우 마지막 리뷰까지 보이지 않게 되어 노출 이벤트가 찍히지 않습니다. 이렇게 되면 ‘리뷰 바로가기 버튼 이후 포토 리뷰로 바로 진입하는 케이스’는 감지할 수 없게 됩니다. 따라서 리뷰가 많은 상황에서의 바로가기 행동까지 고려하여 ‘첫 번째 리뷰가 노출되었을 때’로 트리거를 변경하였습니다.
의도에 맞는 설계를 하면서 다양한 것을 고려하고 그 과정에서 개발자 분들과 소통하는 것도 중요합니다. 또한, 데이터 QA 역시 개발 이슈 확인 뿐 아니라 자신의 설계 오류 역시 잡아주기 때문에 꼭 필요한 과정입니다.
[3]분석 및 공유
데이터 확인 : 29CM은 현재 Amplitude Experiment를 사용하여 실험을 진행하고 있습니다. 실험 환경을 설정한 후에는 모니터링 기능으로 실험이 정상적으로 진행되고 있는지 확인합니다. 실험 내에 가드레일 지표가 있다면, 실험 중간에 롤백을 해야하는 상황이 발생할 수 있으므로 매일 확인해야 합니다. Amplitude Experiment 내에서 단순한 지표는 대부분 구현 가능하기 때문에 실험의 유의성을 바로 확인할 수 있어 편리합니다. Amplitude로 구현할 수 없는 경우, 직접 쿼리를 작성하여 지표를 구현하고 비교할 수 있습니다. 이 경우, 29CM의 모든 데이터 분석가는 정합성 확보를 위해 쿼리 리뷰를 진행하고 있으므로 해당 기간까지 고려하여 일정을 산정해야 합니다.
분석리포트 작성 : 데이터를 확인한 후 결과를 요약하고 결론을 정리합니다. 결과와 결론은 다음과 같은 차이가 있습니다. 데이터 분석의 최종은 결과만 있는 것이 아니라 결론이 있어야 합니다.
- 결과: 데이터 그 자체로 실제 수치가 어떻게 나타났는지를 의미합니다.
- 결론: 결과(데이터)를 평가하여 구체적인 행동과 판단이 들어간 것입니다.
프로젝트 문서에서는 사람들이 먼저 알고 싶고 알아야만 하는 내용을 전달하기 위해 결과와 결론을 축약한 버전을 사용하며, 분석 리포트에서는 어떤 데이터들을 확인하였는지 어디까지 확인했었는지 모든 내용이 들어가있긴 하지만, 이 역시 읽는 사람이 궁금하고 필요한 순으로 (레슨런-결론-결과-데이터 확인) 내용을 배치하고 있습니다.
들여다 보는 업무 일상 — 분석 시 인사이트 및 노하우 공유, DA 성장 로그 미팅
스쿼드에는 보통 한 명의 분석가만 있기 때문에, 혼자 크고 작은 문제들을 극복해야 할 경우가 있습니다. 데이터 분석가들은 일주일에 한 번씩 모여, 어떤 어려움을 겪고 있는지, 도움이 필요한지, 어떤 문제가 있었는데 그것을 어떻게 해결했는지 노하우를 나누는 시간을 가집니다. 현재는 데이터 그로스 팀의 분석가뿐 아니라, 세일즈, 마케팅, CX 등의 각 기능조직의 데이터 분석가도 참여하여 제품 분석 뿐 아니라 넓은 도메인의 사례들을 들을 수 있습니다. 저는 개인적으로 해당 미팅을 통해 동료를 통해 얻는 간접적인 배움도 좋지만, 자신이 어떤 것을 깨달았는지에 대한 사고 과정을 글로 정리함으로써 무의식적으로 습득하던 역량들을 남에게 설명 가능한 노하우로 바꾸게 된 좋은 경험이라고 생각합니다.
마무리
위에서 설명한 과정들을 거쳐 하나의 실행 사이클이 완료됩니다. 이 과정 중 문제 정의와 기획에 시간을 많이 투자하고 있으며, 가장 중요하다고 생각합니다. 특히 문제 정의는 실험 분석뿐 아니라 어떤 분석을 하더라도 필수적인 과정입니다. 분석가가 목적 중심의 사고를 하기 위해서는 Why에 집중해야 하고, 이를 밝혀주는 방법론과 지표들을 적절히 선택할 수 있어야 하기 때문입니다.
목적 조직에서의 분석가는 위에서 설명한 실행 사이클 외에도 간접적인 기여인 도메인 분석, 지표 대시보드 구축과 같은 일도 수행하며, 때로는 기능조직(데이터그로스팀)에서 다른 분석가분들과 프로젝트성 분석을 수행하기도 합니다.
이번 글을 통해 29CM에서 목적 조직 내 데이터 분석가가 어떤 일을 하는지 궁금하셨던 분들에게 도움이 되었기를 바랍니다.
감사합니다.
함께 성장할 동료를 찾습니다
29CM (무신사) 는 3년 연속 거래액 2배의 성장을 이루었습니다.
다양한 소스 데이터에서 안전하고 빠르게 수집, 처리, 저장, 제공하도록 파이프라인을 개발하고 운영하며, 제공된 데이터를 활용하여 데이터 기반 의사결정을 돕기 위해 다양한 대시보드를 제작 및 분석을 진행하고 있습니다. 데이터를 활용하여 가치를 창출하고 함께 성장할 동료 데이터 엔지니어 및 데이터 분석가를 찾고 있습니다.
많은 지원 부탁드립니다!
🚀 29CM 채용 페이지 : https://www.29cmcareers.co.kr/
