어쩌다, 블로그

들어가면서

  [1편]에서 매니저로서 피해야 할 길(절망 편)에 대해서 이야기했다. 2편에서는 반대로 마주하고 나아가야 할 길(희망 편)에 대해서 말해보려 한다. 초보 매니저에게 도움이 되는 글이 되었으면 좋겠다.

마주하고 나아가야 할 길

작은 목소리에 귀 기울이기

  매니저가 된 이후 가장 어려웠던 부분은 구성원의 기분과 컨디션을 파악하는 일이었다. 팀원들에게 나의 의견을 강하게 전달하거나 회의에서 구성원과 반대되는 목소리를 내고 난 후에는 하루 종일 회의가 떠오르고 신경 쓰여 편히 쉴 수가 없었다. 구성원의 사기가 꺾이거나 실망하진 않았을지, 더 부드럽게 전달할 수 있는 방법은 없었는지 고민이 고민을 낳아 잠을 이루기 어려운 적도 많았다.(소심함이 문제였을지도...) 매니저로서 의사결정에 확신이 있었더라면 고민이 덜 했을지도 모르겠다. 하지만 나는 주니어 매니저였고 확신에 찬 결정을 할 수 있는 인사이트가 부족했다.
  이렇게 잠 못 드는 상황을 피하기 위해 구성원들에게 늘 반대 의견을 내어주길 요청했지만 사실 구성원들이 강한 목소리를 내는 것은 매니저인 나보다 더욱 어려움이 따르는 일이었다. 그래서 나는 구성원에게 강한 목소리를 내어주는 것을 요구하는 것에 앞서 그들이 내어주고 있는 작은 목소리를 듣는 것에 집중했다. 주니어, 그리고 비전공자로서 가지는 고민, 회사 복지 체계에 대한 개선 의견, 장비나 의자와 같은 소모품에 대한 불편함 등 흘러가듯 오가는 말들에 집중하여 피드백을 드렸다. 모든 요청에 대하여 대하여 해결책을 드릴 수는 없었지만, 작은 목소리에도 확실한 피드백을 드리는 것을 통해 구성원들의 의견 표현이 조금씩 늘어갔다. 작지만 분명한 피드백을 통해 활발한 의사소통을 이어간다면 프로덕트에 집중된 다양하고 강한 목소리도 편하게 낼 수 있지 않을까? 작은 목소리에 귀 기울이는것을 시작으로 구성원의 목소리에 집중하여 잠 못 드는 밤(서로의 상심을 걱정때문에)을 줄여가고 있다.   

동종 업계의 연봉 시세 확인하기

  스타트업처럼 작은 회사는 HR을 위한 전문 부서를 꾸리기 어려울 때가 많다. HR부서가 없는 작은 조직의 경우 연봉협상을 위해 사내 연봉 테이블과 업무성과 평가표에 절대적으로 의존하기보다, 1차 조직장의 리뷰와 회사와 프로덕트의 성과를 바탕으로 연봉협상을 진행하는 경우가 많다. 우리 팀은 여기에 서라운드 리뷰라는 팀 평가기준을 더했지만 정량적인 기준이 되기엔 부족한 면이 있었다. 이런 상황에서 프로덕트의 성장을 위해 함께 달려온 동료와 돈 이야기를 나누고 연봉을 결정해야 하는 것은 초보 매니저에게 여간 어려운 일이 아니었다. (당장 나의 연봉 협상 자리도 어려운걸...)

  더군다나 코로나 이슈로 인해 IT인력시장은 뜨겁게 달궈져 있었고 하루가 멀다 하고 "OO기업 신입 연봉 6천만원!", "이직 시 사이닝 보너스 1억 제공!" 등 자극적인 채용가 홍보 쏟아지며 연봉협상의 난이도를 더욱 높였다. 

  이런 상황에서 구성원의 이탈을 막고, 동기를 부여하면서도 회사까지 수용할 수 있는!! 회사와 구성원 사이에서 최대한의 협상 만족점을 찾아내야 한다는 고민에 빠졌다. 나는 그 고민을 업계 시세에 기반하여 연봉을 협상하는 방법으로 덜어 낼 수 있었다. 헤드헌터로부터 우리 팀원이 제의받은 금액, 초봉 6천이라는 기업의 인재 요구 수준, 이직한 동료가 받는 연봉과 해당 회사의 연봉 밴드, 전 직장 동료들의 재계약 연봉 등 최대한 많은 곳에서 업계 싯가?를 모았고 이를 토대로 구성원과 회사 사이에서 합의점을 찾을 수 있었다. 어렵게 모은 업계 시세정보는 나와 구성원, 그리고 회사에게도 계약 연봉을 가늠할 수 있는 좋은 척도가 되었고 연봉 협상을 조금이나마 가볍게 시작할 수 있는 출발점으로 활용할 수 있었다.

강약약약으로 처세하기 (강자에게 약하고, 약자에게도 약하게)

  회사의 정치적 구조를 생각하지 않고 프로덕트에 몰입할 수 있는 것은 스타트업이 가진 큰 매력점이다. 지나친 정치에서 벗어나기 위해 대기업에서 스타트업으로 이직하는 경우도 많다. 하지만 사람이 셋만 모이면 정치가 시작된다고 하지 않던가. 정도의 차이는 있겠지만, 성장하는 회사라면 구성원 간의 관계 복잡도 또한 올라가기 마련이다. 특히 매니저라는 직책은 협의를 통해 결과물을 만들어내는 것이 주요 업무이고, 정치적 구조안에서 풀어 가야 하는 일이 많기 때문에 매니저로서 협업을 위한 중심을 잡는 것이 중요하다.

  나는 그 중심을 '정정당당함'에서 찾으려 했다. '강자에게는 강하고 약자에게는 귀를 귀울이는 것'을 정정당당한 것으로 생각했고 이에 맞춰 회사에서도 강강약약의 자세로 협업을 진행했다. 특히 강강에 집중했던 나는 상위 결정권자의 의견을 더욱 엄격한 기준으로 판단했고, 팀원들에게 부끄럽지 않은 결정을 해야 한다는 생각에 몰입했다. 하지만 '정정당당'함을 지키기 위한 노력이 협업에 도움이 되거나 프로덕트의 성장에 긍정적인 영향을 미쳤을까? 아니다. 매니저로서 2년이 지난 지금 돌이켜 보면, 나의 강강약약은 프로덕트와 팀원보다 나의 자존심을 더 잘 지켜내는 방법이었다.

  회사는 수익을 내기 위해 협업을 하는 곳이다. 강자에게 강하게 대응한다고 해서 우리의 프로덕트가 눈에 띄게 성장하거나, 우리 팀이 더 편해지지 않는다. 팀과 프로덕트의 성장을 위해서는 강자에게도 약하고 약자에게도 약한 자세를 취해서 최대한 많은 의견을 끌어내고 수렴해서, 발화자의 직책 높낮이에 상관없이 프로덕트만을 위한 결정을 해야 한다. 나보다 직책이 높은 사람의 의견을 따른다고 해서 아부하는 게 아니며, 직책이 낮은 사람의 의견을 반대한다고 해서 군림하는 것이 아님을 늦게 알게 되었다. (정말 집중하고 잘 보이기 위해 노력해야 하는 곳은 유저와 프로덕트였던 것을....) 그때부터 강약약약으로 대응하려 노력하고 있으나 잘 하고있는지 판단하기 위해서는 좀 더 시간이 필요할 것 같다.

개밥 먹기

  개밥 먹기란 우리가 개발하고 있는 프로덕트를 일상적인 생활과 업무에서 사용해보는 것을 뜻하는 IT업계 용어다. 이스포츠 플랫폼을 개발하는 우리 팀의 경우 사내 게임대회를 레벨업지지에서 개최해 본다거나, 유저가 만든 대회에 직접 참가하는 것이 개밥을 먹는 것이다.

  매니저에게 개밥 먹기는 우리가 만들고 있는 것이 무엇인지 제작자의 관점에서 한발 벗어나서 객관적으로 볼 수 있는 좋은 도구이다. 여러 곳에서 쏟아지는 아이디어를 정리하며, 기능을 구현하고 더하는 것에만 집중하다 보면 우리가 만들고 있는 것이 무엇인지 놓칠 때가 있다. 그럴 때면 개밥 먹기를 통해 우리 프로덕트의 현황을 파악하고 해결해야 할 문제점들을 파악할 수 있다.

  그리고 개밥 먹기는 애자일 형태로 개발을 진행하는 조직에게 필수사항으로 업무시간을 들여서라도 진행 하는 것을 추천한다. 무엇을 만들 것인지, 어떻게 만들 것인지, 이번 변경사항이 얼마나 의미있었는지, 어디를 개선해야 할지 등 애자일의 과정 과정마다 좋은 아이디어를 낼 수 있는 원동력을 프로덕트에 대한 이해도로부터 얻을 수 있기 때문이다. 기획자와 디자이너는 물론 개발자와 운영자까지 유저로서 프로덕트를 이해한다면 각자의 파트에서 더욱 의미 있는 역할을 해낼 수 있을 것이라 믿는다. 

투명한 정보 공유

  매니저 업무를 시작하면서 관리해야 하는 정보의 양이 기존보다 두배 이상 증가했다. 실무자일 때보다 더 많은 회의에 참석했고, 더 많은 의사 결정에 참여함으로써 운영진과 타 부서의 정보도 챙겨야 했다. 매니저로서 얻는 정보를 어디까지 구성원에게 공유해야 할까?라는 물음표가 생겼고, 잦은 결정 변경으로 인한 피로감, 무뎌짐, 실패의식을 느꼈던 과거 실무자로서의 경험을 바탕으로 '확정된 것만 공유하자'라는 판단을 했었다. 

  하지만 대표님은 반대로 대부분의 정보(심지어 투자 현황까지)를 전 직원에 공유했고, 나의 우려와는 반대로, 정보를 받아들이는 주체였던 구성원들은 성숙하게 정보를 소화해내고 있었다. 빅픽처의 동료들은 나보다 훨씬 더 강하고 성숙한 사람들이었고, 모든 정보를 투명하게 공유하였을 때 실망하거나 걱정하기에 앞서 그들의 사유를 바탕으로 판단하고 있었다. 정보의 제한을 통해 피할 수 있었던 실망과 아쉬움을 감내해야하는 경우도 있었지만, 투명한 정보 공유로부터 오는 고통은 정보를 차단하고 필터링 하는 것으로부터 오는 부작용보다 건강하고 성장의 바탕이 되는 성장통이었다. 앞선 경험을 통해 나 역시 확정된 정보만 공유하는 것에서 모든 정보를 투명하게 공유하는 것으로 자세를 바꾸었다. 정보를 투명하게 공유함으로써 쌓이는 신뢰도는 우리를 더 단단하게 만들어 주었고 정보 공유를 더 편하게 할 수 있는 선순환구조가 자연스럽게 생겨나 매니저로서 정보를 관리해야 하는 어려움을 줄일 수 있었다.

마치면서

  [1편]은 하면 안 되는 것들에 대하여 적다 보니 편하게 쓸 수 있었나보다. 이번 편은 해야 하는 것들에 대해 적다 보니 소심함과 조심스러움이 더해져 문장들마다 쉼표가 늘어났다. 이제 막 3년 차에 접어드는 초보 매니저의 글로써 나와 비슷한 길에 올라선 분들께 조금이나마 도움이 되는 글이길 바란다. 다음 회고 때는 조금 더 자신감을 뿜뿜할 수 있기를....! 

김병규 (bk@bigpi.co)
새로움과 자유로움을 좋아하는 개발자입니다.
프로덕트의 성장은 구성원의 성장으로부터 온다고 믿습니다.  

들어가면서

  실무자가 매니저로 넘어가는 길에 도움이 되는 이정표를 작게나마 더하고 싶었다.

개발자로 7년을 일하다 7명을 팀원을 맡게 되고(자기소개의 글), 2년간 팀과 함께 성장하며 33명이 되기까지 경험을 바탕으로 피해서 돌아가야 할 것과 마주하고 정면 돌파해야 하는 것들을 정리해 보았다.

피하고 돌아가야 할 길

비교형 문장

  우리 팀은 반기마다 서라운드 리뷰(협업했던 동료를 서로 리뷰하고 평가함)를 진행한다. 팀을 리드하는 입장에서 좀처럼 받기 어려운 동료들의 피드백을 들을 수 있는 소중한 시간이다. 서라운드 리뷰를 통해 나는 "프런트엔드와 백엔드를 비교하며 표현하지 말아 달라."라는 피드백을 받았다. 할 일을 계획하는 부서회의 때 "A라는 기능은 트랜잭션 관리 때문에 프런트엔드 개발보다 백엔드 개발이 중요하다. 일정을 더 많이 잡아 달라"라는 표현을 하였고 이에 대한 피드백으로 주신 말씀이었다. 너무나 맞는 피드백이었고 늘 새기며 일하게 되었다. 업무량과 영향범위는 다를 수 있지만  무엇이 더 중요한 일은 없다. 더 중요하다고 생각되더라도 그것은 개인의 의견일 뿐 모두가 동의할 수 있는 사실은 아니다.
  비교하는 표현을 사용하면 부정적으로 표현되는 면이 생기기 마련이다. 매니저가 전체회의에서 하는 말은 영향력이 크기 때문에 비교형 문장은 피하자.

개발 리소스에 등 떠밀리기

  스타트업은 언제나 리소스가 부족하다. FE개발자에게 퍼블리싱 작업은 기본이고 데이터 지표 추적 같은 스크립트 추가는 일상이다. 이런 상황에서 새로운 프로젝트를 목표한 기간 안에 완성하기 위해 가장 쉽게 선택할 수 있는 선택지는 개발자 채용이다. (채용 난이도도 높지만 개발자 출신 뉴비 매니저였던 나는 '그 일정으로는 안됩니다'라고 말하고 실망감을 감내하는 것보다 채용을 통해 일정을 맞추는 방향이 좀 더 쉬웠다.)
  어려운 채용시장에 맞춰 주니어 역량의 구성원을 채용하고 성장을 유도하며 프로젝트를 완료한 뒤 우리 팀은 디자인/기획 리소스에 비해 개발 리소스가 큰 조직이 되었다.(팀 유지비용이 올라가는 것은 덤이었다.) 

이때부터 매니저로서의 나는 '개발자를 놀릴 순 없어!', '개발하지 않으면 재미가 없어져버린다구!'라는 생각을 하며 충분한 고민이 담기지 않은 기획서와 디자인을 요구했고, 유기적으로 돌아가는 팀을 보며 흐뭇해하기까지 했다. 높아진 팀 유지비용을 성과로서 상쇄해야 한다는 조바심이 더해져 상황은 좀처럼 나아질 기미가 없었다.

  조바심이 난 매니저는 어떤 행동이든 할 수 있는 무서운 동물이었다. 의욕이 넘치는 초보 매니저로서 회사를 위해 열심히 달리고 목표를 완수하기 위해 최선을 다했을 뿐인데 나는 예측 불가한 추진체가 되어 있었다. 자연스럽게도 개발 리소스에 등이 떠밀리게 되었고 매니저로서 부족한 결정을 하면서 팀과 프로덕트의 성장에 걸림돌을 만들었다. 

  사용자를 충분히 고려하지 않거나 모두를 만족시키기 위해 복잡한 기능을 설계하고, 유지보수에 사용되는 리소스 예측에 소홀해 매일같이 야근이 이어졌다. 무엇보다 철야하며 구현한 기능들이 유저에게 외면받을 때에는 그 원인을 나에게서 찾지 않고 시장을 탓하곤 했다. 자연스럽고 쉽게 빠져들 수 있는 실수로 인한 등떠밀림의 효과는 강력했고, 그로 인한 결과는 랜덤박스처럼 다방면에서 터져 나왔다. 매니저는 여유롭게 고민하는 시간이 많아야 한다는 조언을 들었을 때 이것은 무슨 소리인가! 했었는데 실수를 거듭하고 난 뒤에야 비싼 값을 치르고 그 의미를 체득하게 되었다. 다시 처음으로 돌아갈 수 있다면 개발 리소스를 늘리기 전에 충분히 고민하고 설계할 수 있는 기획/디자인 리소스 그리고 개발 리소스를 효율적으로 사용할 수 있는 매니저로서의 역량을 먼저 준비할 것이다.

매니징과 실무를 동시에 하기

  개발자에서 초보 매니저로 넘어온 나는 의욕이 넘쳤다. 동료들에게 기술역량이 있는 매니저로서 인정받고 싶었고 코드를 작성하는 실무를 통해 증명할 수 있다고 생각했다. 하지만 실무를 통해 구성원의 신뢰를 얻을 수 있었던 기간은 고작 6개월이었던 것 같다. 성장곡선이 너무나 가팔랐던 동료들은 내가 공유했던 기술 레벨 수준을 각자의 분야에서 빠르게 뛰어넘었고 나는 그들이 챙기지 못하거나 리소스 부족으로 담당자가 없는 업무들을 찾아 빈틈을 채우는 정도로 실무를 이어갔다.

  물론 실무를 이어가며 매니징을 하는데 문제가 없다면 실무에도 도움이 되는 매니저가 될 수 있었다. 하지만 나는 초보 매니저였고, 새로운 업무에 적응하기 위해 모든 리소스를 사용하여도 부족한 상황인 것이 문제였다. 그로 인해 매니저로서 해야 하는 것들을 놓치는 경우가 많았고, 실무에도 온전히 집중할 수 없어 리팩터링이 필요한 코드들이 쌓여갔다.

  매니징과 실무를 동시에 하느라 매일같이 야근하는 매니저, 거기에다 완성도 낮은 코드와 인사이트가 부족한 결정을 내리는 리더와 함께 일하는 동료들은 얼마나 힘이 들지 그때는 미처 생각하지 못했다. 초보 매니저라면 겸업은 피하고 매니저로서의 역할을 먼저 소화해 내는 것이 동료들에게 깊은 신뢰를 얻을 수 있는 길이 아니었을까. 역시나 다시 돌아간다면 매니저로서 역할을 할 수 있도록 온전히 노력을 쏟고 싶다.

K-애자일

스타트업이나 소프트웨어를 개발하는 IT조직에서는 애자일 방법론을 채택하는 경우가 많다.
K-애자일을 논하기 전에 찐 애자일 선언문 먼저 살펴보자.

공정과 도구보다 개인과 상호작용을, 포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을, 계획을 따르기보다 변화에 대응하기를 가치 있게 여긴다.

  나는 애자일 선언문을 바탕으로 최소 기능 제품(MVP)을 만드는데 주력하고 유저에 집중하여 완성도를 높여가는(때로는 목적지도 바꾸어가며) 형태로 일하려고 했다(근데 못했다). 지난 2년간 우리 팀은 정말 유저에 집중하고 있었을까? 프로덕트의 완성도를 높여가는데 집중하고 있었을까? 반문해보면 명확히 '아니다'라는 답이 돌아온다. 그러면 내가 추구하고 요구했던 개발 방법론은 무엇이었을까? 그것은 바로 K-애자일이었다 흑ㅠ흑ㅠ

우리가 했던 K-애자일은 이렇게 진행된다.

① 스프린트 결과에 대한 정량적, 정성적 성과를 측정할 수 있는 환경이 없다.

  이전 스프린트의 성과를 측정하지 않고서 다음 스프린트를 계획할 수 있을까? 스케이트보드가 제대로 완성되었는지 알기 어려운 상황에서 핸들을 추가한다면 그것은 킥보드로서 동작할 수 있을 것인가? 거듭되는 스프린트마다 행운이 따라야만 우리는 목적지에 다다를 수 있을 것이다. 

② 결과물(목적지)은 변경할 수 없으며, 개발 완료 시점이 확정되어있다.

  나는 스프린트로 작업해나가는 것을 관철했고 스프린트를 계획하고 종료하는 기준은 배포일이었다. 2주 또는 3주마다 배포일을 지정해두고 배포일에 맞춰 스프린트를 진행했다. 정해진 개발 완료 시점으로 인해 우리 팀은 유저와 기능에 대하여 충분히 고민할 시간은 줄어들고 기획 파트와 개발 파트의 갈등을 야기했다. 기획서 리뷰 시간에 개발자 의견이 더해지면 기획자는 다시 기획서를 업데이트해야 했고, 그만큼 개발할 시간은 줄어들기에 일정을 더 확보해야 했다. (그러나 일정을 추가하지 못하는 것이 K-애자일의 핵심!)

③ 기능 배포 시점을 팀 외부(타 부서, 고객사 등)에서 결정한다.

  앞선 ②번의 상황에서 기능의 퀄리티 높이기 위해서는 일정을 조율하고 다시 첫 스탭부터 수정해나가는 과정을 반복해야 한다. 하지만 기능 배포 시점을 우리가 조정할 수 있는 상황이 아니라면? 스프린트를 진행하는 중간에 꼭 개발해야만 하는 기능이 추가된다면? 무엇보다 그것이 전사 관점의 이슈(이것은 몹시 민감하고 예민하다.)가 반영되어있다면, 개발팀은 일정보다 늦게 완성된 기획서에 발맞춰 개발을 해내야만 한다. 이를 통해 우리는 파트 간 볼맨 소리, 퀄리티의 결핍, 우리가 원했던 건 이게 아닌 데와 같은 다양한 부작용을 얻게 된다.

④ ①번부터 ③번까지 과정을 반복한다.

  어쩌면 워터폴 방식이 어울렸을 우리 조직에 K-애자일이 자리 잡게 된 것은 애자일에 대한 이해도가 부족한 상태에서 애자일을 해야 한다고 큰소리로 주장했던 매니저(나)가 가장 큰 원인이었다. "한국 기업들에서 행해지는 애자일 방법론은 일을 빠르게 많이 시키기 위한 것이 아니냐"는 글이 커뮤니티에 올라올 때마다  "우리는 아니야(응 맞아)"라며 현실을 부정하는 내 모습이 늘 함께했다.

  다행히도 우리 조직은 얼마 전 애자일을 코치와 스크럼 마스터를 전담해주시는 @김영민 님을 만나게 되어 건강한 애자일 문화를 처음부터 다시 키워나가고 나가고 있다. 곧 건강한 애자일 문화에 대한 블로그를 올릴 수 있을 것 같아, 자조 섞인 K-애자일에 대한 설명은 서둘러 마친다.

마치면서 

  초보 매니저로서 피하고 돌아가야 할 길을 작성하다 보니, 내용이 너무 길어져 버렸다. 아마도 많은 길을 돌아왔기 때문이 아닐까? 매니저로서 역할을 더 잘했다면 피해 갈 수 있었던 길들을 돌아보면서, 어떤 문제든 팀에서 발생하는 문제는 모두 매니저의 책임임을 또 한 번 느낀다.😢 (그렇다면 잘한 것도 모두!? 🤣)

  피해 가야 할 길에 대해서 글을 쓰다 보니 반성문이 되어버렸다. 잘해온 것도 무척?이나 많기에, 반대로 마주하고 지나가야 할 길에 대해서 페이지를 분리해서 공유할 예정이다. 내가 작성한 글이 나와 비슷한 길에 올라서 있는 분들께 조금이나마 도움이 되고 실수를 덜할 수 있는, 혹은 잘못된 길은 피해 갈 수 있는 단서가 될 수 있으면 좋겠다. 

다음 글) 마주하고 지나가야 할 길 

• 작은 목소리에 귀 기울이기
• 동종 업계 연봉 시세
• 강약약약
• 개밥 먹기
• 투명한 정보 공유 

김병규 (bk@bigpi.co)
새로움과 자유로움을 좋아하는 개발자입니다.
프로덕트의 성장은 구성원의 성장으로부터 온다고 믿습니다.  

들어가면서

  지난 데이터 대시보드 1편에서 공유한 데이터 대시보드를 고도화하고 당시 아쉬웠던 부분들(고객군 분리, 유저 획득 경로 상세화, 리소스 데이터 추가)을 보완한 내용을 공유한다. 데이터 대시보드 생성 이후 프로덕트를 담당하는 팀원들의  아이디어가 더해지면서 조금 더 실용적인 지표들이 추가되었다. 정답이 없는 질문에 최선의 답을 구하기 위해, 계속해서 데이터와 결과물을 조정해야 하는 작업이다 보니 소심해지고🤭, 집단지성🧠에 기대게 된다. 이 글도 집단지성이라는 호수에 한 방울💧 보탬이 되기를, 그리고 다음 단계를 제안하고 발전할 수 있는 발판이 될 수 있기를 바란다.🙏

대시보드 추가

  기존에 구축했던 데이터 대시보드에는 프로덕트 사용자의 흐름을 전반적으로 살펴보는 AARRR 분석만 존재했다. 동료들에게 AARRR 대시보드를 공유하고 나서, 프로덕트 담당자들이 가지고 있는 개발 스토리에 대한 기능별 대시보드 생성 요청을 받았고 이에 맞춰 3가지 대시보드를 추가했다. 새로운 대시보드를 추가하면서 데이터 구렁텅이에서 방향감각을 잃어 갈 때마다 아래 세 가지 포인트를 기준점으로 다시 정신을 부여잡고 작업을 진행했다. 새롭게 추가한 대시보드들을 소개하며 더불어 대시보드를 통해 개인적으로 얻을 수 있었던 힌트들을 첨언했다.

📌우리가 무엇을 위해 리소스를 투입하는지 목표에 대한 선명도를 높이자.(목표)
📌유저에게 전달한 스토리는 목표를 달성했는지 확인할 수 있어야 한다.(결과 측정)
📌다음 작업에서 우리가 집중해야 할 부분은 무엇인지 힌트를 제공하자.(계획)

• 유저 랜딩 기능분석 (연관 페이지 : online.gamecoach.pro)
  • 목표
    • 신규 수강생 방문자에게 제품의 핵심 가치를 전달한다.
    • 방문자가 CTA버튼 통해 핵심 Task를 수행하도록 유도한다.
  • 결과 측정
    • 신규 수강생 페이지 참여도 지표 (참여율, 평균 참여 시간, 스크롤 90%, 기타 세부 이벤트)
    • CTA버튼 클릭률 (CTA 클릭 수 / 첫 방문자 수,  CTA 클릭 수 / 세션 수, CTA 클릭 수 / 페이지 방문 수)
  • 특이사항 & 힌트
    
    • CTA버튼 클릭률을 어떤 기준으로 보아야 할 것인지에 대한 고민이 필요하다. 첫 방문자의 CTA 클릭률이 유저 랜딩 페이지의 목적에 가장 적합하고 퍼센트도 가장 높은 상황이지만, 목표한 클릭률을 달성했는지 등의 성공 판단 기준이 추가된다면 다음 단계를 고민하는데 더욱 도움 될 것으로 보인다.
    • 기존 유저의 CTA 버튼 클릭률은 첫 방문자 대비하여 12 ~ 20% 낮은 상황이다. 재방문자에게는 상대적으로 CTA 버튼이 매력적으로 다가가지 못하고 있다. 재방문에게 맞는 CTA버튼이나 기능 등 리텐션과 연계해서 고민해 본다며 개선 목표를 정할 수 있을 것 같다.

• 코치 추천 기능분석 (연관 페이지 : online.gamecoach.pro/coach-matching) 
  • 목표
    • 신규 방문자와 코치님의 1:1 채팅 성사율을 높인다.
  • 결과 측정
    • 생애 첫 채팅과 일반 채팅 성사에 대한 커스텀 이벤트를 생성하여 분자에 대입하고 첫 발문자 수, 세션 시작 수를 분모로 활용하여 목표 결과를 측정할 수 있는 3가지 핵심 지표를 등록했다. 
    • 추천 코치 페이지에서 추천받기 시작부터 추천받기 완료, 추천 코치 카드 선택 등 스탭 별 참여도 지표를 생성하여 유저가 코치를 추천받는 스탭 별 정보를 시각화했다.
  • 특이사항 & 힌트
    • 커스텀 이벤트를 만드는 과정에서 이벤트 등록을 누락한 포인트가 있어서 중요 포인트인 `채팅 수` 값이 상당기간 오염되어 있었다. 확인 즉시 수정하였지만 과거 데이터와 비교가 불가하여 아쉬운 점이 있었다.
    • 추천받기 완료율 | 채팅 성사율 | 수강 결제 완료율 세 가지 지표 간에 강한 연관도가 있을 것으로 보인다. 수강률은 프로덕트 최종 목표에 직결되는 분명한 지표지만 수강률 상승까지 복잡한 단계와 설계가 필요하다. 반면 채팅 성사율 | 추천받기 완료율은 접근 단계가 단순하고, 수강률과 강한 연관이 있기 때문에 수강률 상승을 위한 분할 공략지점으로 활용할 수 있을 것으로 보인다.

• 코치 찾기 기능분석 (연관 페이지 : online.gamecoach.pro/coach-finder)
  • 목표
    • 수강생이 코치를 검색하는 행동을 분석한다.
  • 결과 측정
    • 수강생이 어떤 코치를 찾는지, 중요하게 보는 이력은 무엇인지 등 유저의 니즈를 파악하는 것은 유저 페르소나를 선정할 때 매우 중요한 부분이다. 코치 찾기 페이지를 오픈 한 뒤 실제 유저가 검색하는 태그와 정렬 등 클릭 위주의 데이터를 수집하여 시각화했다.
  • 특이사항 & 힌트
    • 코치를 검색하기 위해 태그를 클릭하거나 우선순위 정렬을 변경하는 등의 액션이 페이지 뷰 대비 10% 이하로 측정되었다. 코치를 검색하고 정렬하는 기능 자체의 사용률이 낮은 것을 바탕으로 수강생이 코치를 검색하기 이전에 검색이 필요한 환경을 마련하는 것이 우선일지 고민해봐야겠다. 

고객군 분리 & 유저 획득 경로 상세화

  대시보드 개선을 위해 유저 타입을 세분화하여 데이터를 필터링할 수 있는 뷰와 유저 획득 경로를 상세화하여 주요 유입 포인트를 필터링할 수 있는 뷰를 제공하려 노력했다. 무엇보다 기능 안정화 이후 본격적인 마케팅을 진행할 예정이어서, 신규 유저의 획득 경로 파악이 꼭 필요한 상황이었다.

  먼저 유저 타입을 세분화하기 위해 GA4 연동 스크립트에 userId와 user_properties값을 추가하여 로그인 여부 및 유저 역할(수강생, 코치)을 GA4 보고서의 비교 기준으로 사용할 수 있도록 개선했다. 작업량은 크지 않았은데 레퍼런스가 적고 공유된 자료들은 쇼핑몰 기준이라 온라인 게임코치 서비스 특성에 맞게 커스텀하기에 어려움이 있었다. (결과적으로 GA4 연동 스크립트를 수정하여 대부분 gtag의 'config'기능을 사용하여 세팅했다. 비슷한 작업을 하실 분들을 위해 구글 공식문서를 추천한다.) userId와 user_properties값을 세팅한 이후에는 데이터 비교/필터링 기준으로 로그인 여부와 유저 타입 (코치인지, 학생인지)을 선택할 수 있게 되었고 코치와 유저라는 양 극단에 위치한 유저들의 데이터를 분리하여 확인/비교할 수 있게 되었다.

  두 번째로 유저 획득 경로를 상세화 하기 위해 구글 캠페인 URL 빌더를 적극 활용했다. 구글  캠페인 URL 규격에 맞춰 생성한 URL을 통해 유저가 페이지를 방문하면 URL에 세팅한 referrer(source)와 medium, campaign name 등의 데이터를 얻을 수 있다. 이 기능을 이용하여 direct와 not set으로 뭉쳐져 있던 세션 유입 경로를 각 캠페인, 소스 등으로 세분화하여 확인할 수 있게 되었다. (드디어 direct와 not set의 유입 순위를 떨어뜨렸다. 😂)

  앞서 설정한 두 가지 작업을 바탕으로 데이터 대시보드에서도 필터링을 쉽게 적용할 수 있었다. 이제 모든 대시보드에서 로그인 여부와 캠페인을 기준으로 데이터를 확인할 수 있다. 예를 들면 페이스북 캠페인으로 얻은 유저들의 지표와 틱톡 캠페인으로 얻은 유저들의 지표들을 디테일하게 비교하여 우리가 집중해야 할 매체들을 찾을 수 있게 된 것이다.

구글 데이터 대시보드에 새로운 데이터 소스 추가

  프로덕트 매니저가 요구하는 지표들을 GA4와 데이터 대시보드가 제공하는 기본적인 기능으로 표현하기 어려울 때가 많다. 이를 극복하기 위해 gtag를 이용하여 커스텀 이벤트를 만들어 대응하고 있지만 부족함을 느끼고 있다. 예를 들어 `게임코치 온라인 유료 포인트를 가지고 있는 유저` 필터 옵션이나 `특정 이벤트를 기준 페이지별 발생 횟수`같은 지표를 구현하기 어렵다. 이를 극복하기 위해 Google BigQuery와 게임코치 온라인 DB를 대시보드의 데이터 소스로 추가하는 작업을 진행했다.

• Google BigQuery
  • BigQuery는 대규모 데이터 세트에 대해서 쿼리를 신속하게 처리할 수 있는 클라우드 데이터 웨어하우스로 GA4에서 축적한 데이터를 기반으로 SQL과 유사한 구문을 사용하여 조회할 수 있는 기능 제공한다. 기존에 UA 버전에서의 GA에서는 BigQuery와 연결하는 BigQuery connector가 유료버전에만 포함되어 있었는데 GA4버전부터는 무료로 변경되어 손쉽게 사용할 수 있게 되었다. (BigQuery 자체는 유료이지만 무료 플랜으로도 충분히 사용 가능함)
  • Google BigQuery로 GA4 데이터를 들여다보니 모든 데이터는 이벤트 형태로 저장하고 있어서, 이벤트 발생 시 함께 저장한 상세 데이터(이벤트 발생 위치, 유저 식별자, 이벤트 벨류 등)를 기준으로 검색하거나 그룹화할 수 있었다. 덕분에 프로덕트 매니저가 요구하는 다양한 이벤트 기반 지표들(채팅 이벤트가 어떤 위치에서 얼마나 발생하는지 등)을 시각화할 수 있었다. (GA4를 조회하는 빅쿼리를 시작한다면 구글 공식 문서를 강추한다.)
• 게임코치 온라인 데이터베이스
  
  • 구글 데이터 대시보드는 MSSQL, MYSQL 등 다양한 데이터베이스를 데이터 소스로 사용할 수 있게 도와주는 커넥터를 지원한다. 또한 데이터 소스들을 연결하는 JOIN 기능을 지원하기 때문에 GA에서 수집한 유저 정보에 기반하여 데이터베이스 정보를 더해 확장하면 강력한 분석 환경을 제공할 수 있다.
    하지만 구글 데이터 대시보드에 우리 게임코치 온라인의 데이터베이스 접근권한을 부여하는 것은 보안상 위험할 뿐만 아니라 법적으로도 검토가 필요한 민감한 사항이기 때문에 연동을 진행하지 않고 내부망에 구성된 별도의 분석 툴을 이용하는 것으로 결정했다. 서비스 DB와 연계가 필요한 지표 요청이 계속되고 있기 때문에 민감한 정보를 조회할 수 없는 DB 엔드포인트를 별도로 준비하여 연결하는 방법을 백엔드 팀장님과 함께 계속 고민하고 있다.

A/B테스트 환경 추가

  최근 12주간 축적해온 개발 내용을 프로덕션에 반영하고 게임코치 메인 페이지는 명확한 CTA 버튼을 노출하고 있다. 페이지의 목표가 명확해지고 예산을 사용하여 마케팅을 진행하려다 보니 A/B테스트에 대한 니즈가 생겼고 해결안으로 Google Optimize를 선택했다. Optimize는 사용하게 된 이유로 몇 가지 장점이 있는데 실제 사용해본 경험을 바탕으로 소개한다. 

• GA4와의 연동
  • Optimize의 가장 큰 장점은 A/B테스트에서 가장 중요한 각 대안별 효과 측정을 GA4 데이터에 기반하여 자동으로 생성해주는 부분이다. 특히 A/B테스트를 생성할 때 테스트의 목적을 선택할 수 있으며, GA4에서 설정해둔 전환 이벤트를 선택할 수 있고, 부가적인 목표도 차순위 이벤트를 선택할 수 있기 때문에 A/B테스트 목적을 GA4와 일원화하고, 결과를 분석하는 뷰를 목적에 맞게 별도로 생성하는 수고를 덜 수 있다.  
• 코드 수정이 필요 없는 대안 생성 툴
  
  • Optimize에서는 A/B테스트를 진행할 대안을 생성하는 툴을 제공한다. 개발자가 아니더라도 클릭만으로 새로운 대안을 추가할 수 있으며 코드 상의 변화도 없기 때문에 배포나 개발팀 도움 없이 대안을 관리할 수 있다. (레이아웃을 변경하거나 노출 순서를 변경하는 등 매우 강력한 기능을 제공하는 것을 보고 감탄만... 🤯)
  • 만약 서비스 프런트엔드를 Vue나 React를 이용하여 SSR형태로 개발했다면, 서버에서 랜더링 한 화면과 프론트에서 랜더링 한 화면이 다르기 때문에 hydration error가 발생할 수 있다. 이 경우 client에서만 렌더링 되도록 예전에 종선 개발자님이 공유한 client-only 컴포넌트와 같은 방법을 적용하면 해결할 수 있다.

데이터 대시보드를 구축하면서 어려웠던 부분

  프로덕트 매니저가 필요한 데이터와 지표는 자연어 형태로 전달된다. 그리고 이런 요청들은 GA4, BigQuery, 데이터 대시보드, Optimize 등 앞서 소개한 데이터 소스와 툴들이 이해할 수 있는 문맥으로 변환되어야 한다. 데이터 지표를 만드는 과정 초반에는 툴들을 세팅하고 데이터 정합성을 맞추는 것이 어려웠지만, 현재는 매니저 분들의 자연어를 최대한 빈틈없이 기계어로 바꾸는 과정이 가장 어렵고 결과 만족도를 얻기 어려운 상황이다. 지표 생성을 요청 주시는 분들이 데이터 분석 환경과 친해진다면, 그리고 나의 번역 스킬을 높여 간다면 이런 어려움을 극복할 수 있다고 생각한다.(그래서 블로그도 열심히!✍) 울퉁불퉁 어려움 많은 비포장 도로 위에서 프로덕트 매니저와 협업하며 자연어를 기계어?로 번역한 예시를 첨부한다. 💬

• 자연어 - '1월 15일을 기준으로, 기존 서비스 이용자가 아니었던 사람들의 데이터를 분리해주세요.'
  
  • '서비스 이용자'라는 기준을 페이지 방문 여부로 결정할 것인지, 전환 이벤트 발생자로 잡을 것인지, 구매를 완료한 수강생으로 잡을 것인지에 대한 논의가 필요하고 데이터 요청자와 콘텍스트를 맞추어야만 결과 지표를 바라보는 시점도 맞출 수 있다.
  • '1월 15일'이라는 기준을 충족하려면 앞서 논의한 '서비스 이용자'의 기준에 날짜 개념을 적용할 수 있어야 한다. GA4에서 날짜 기반으로 필터링 하기 애매한 것들이 있다. 예를 들어 '서비스 방문', '페이지 조회'를 기반으로 필터링하면 1년 전에 서비스를 마지막으로 방문한 유저가 재방문했을 경우 신규 방문자 속성을 가진 '기존' 방문자 이기 때문에 결과 분석 시 이런 예외 케이스에 대한 고려가 필요해진다. 
  • 이런 상황에서 프로젝트 매니저와 '서비스 이용자', '기간'에 대한 논의(개발자의 애원이었을 지도..👩‍💻)를 진행하고, 다른 예시 대시보드 참고하여 GA4 전환 이벤트 중 하나인 '구매자'를 기존 서비스 이용자로 구분자로 활용하고 데이터 대시보드 조회 기간을 수동으로 선택하여 '기존'이라는 조건은 적용하는 것으로 기계어 번역을 마쳤다. (프로젝트 매니저의 요구사항을 깔끔하게 구현하지 못한 것과 불완전할 수 있는 지표로 인해 번역 품질 만족도가 걱정된다. 어렵고 개선이 필요한 부분이다.)

다음 단계

  지금까지 우리 서비스에서 발생하는 데이터를 수집하고, 팀원 모두 간편하게 확인할 수 있는 기반을 다졌다. 지금부터는 '제품 구매'라는 최종 목표로 더 정확하게 나아갈 수 있는 '중간 목표'를 만들어 데이터 대시보드의 실용성을 높이고 싶다. 예를 들면 스트리밍 서비스의 경우 수익이 발생하는 최종 목표가 '도네이션' 또는 '광고 등록'일 때, 최종 목표에 도달한 유저가 공통적으로 가지고 있는 이벤트를 분석하여 '중간 목표'를 '스트리밍 5분 신청'으로 찾아낼 수 있다. 반대로 '스트리밍 5분 지속 시청 여부'를 기준으로 유저를 분리하고 두 집단의 전환율을 비교하여 1차적으로 가설을 증명해 볼 수도 있다. 만약 '스트리밍 5분 지속 시청'이라는 이벤트가 전환율에 중요한 영향을 미친다면 이것을 '중간 목표'로 잡고 '최종 목표'보다 좀 더 명료한 계획과 실행, 증명을 할 수 있을 것이다.

  우리 서비스인 게임을 1:1로 강의하는 게임코치 온라인의 경우 '제품 구매'를 최종 목표로, '코치와 1:1 대화'를 중간 목표로 잡아 볼 수 있다. 하지만 이런 생각을 상상과 가설에 기반하지 않고 데이터에 기반하여 중간 목표 설정이 타당한지, 최종 목표에는 얼마나 영향을 미치는지, 우리의 작업이 중간 목표 달성률을 올렸는지 등을 데이터에 기반하여 판단해야만 한다. 다음 단계로 '중간 지표'를 찾고, 이를 통해 '최종 목표'에 긍정적인 영향을 미칠 수 있는 대시보드 실용성 향상에 집중해 보겠다. 조만간 즐거운 마음으로 데이터 대시보드 3편을 쓸 수 있기를 바라본다.

김병규 (bk@bigpi.co)
새로움과 자유로움을 좋아하는 개발자입니다.
프로덕트의 성장은 구성원의 성장으로부터 온다고 믿습니다.