2022년 회고(Product Owner에서 리더로…)

리더

2021년부터 회고글을 작성하고 있다. 이번이 3번째 회고인데…늘 그렇듯이 2022년도도 참 힘든 시기였다. 매년 힘들고 어려운 것은 똑같은데…신기하게도 힘겨움의 종류는 항상 다르다.

  • 2020년도는 일이 많아서 힘들었다.
  • 2021년도는 환경이 힘들었다.
  • 2022년도는 내 역할이 바뀌면서 힘들었다.

리더의 역할

2022년도 3월 내 리더였던 CTO님이 퇴사를 했다. 그리고 나는 플랫폼개발본부의 본부장이 되었다. 지인들은 나에게 승진을 축하한다고 했지만…사실, 나는 별 감흥이 없었다. 업무적으로 크게 달라질 것은 없었기 때문이다. 오히려, 내 리더가 담당했었던 업무 일부를 내가 추가적으로 해야했기 때문에 업무가 더 늘어났다. 나는 그 전처럼 Product에 대한 오너십을 가지고 Product Owner로서의 역할을 하면 된다고 생각했다. 2022년 나의 실수중 가장 큰 실수를 하나 꼽으라면, 바로 이런 생각을 통해 나 스스로 아무런 의식적 변화를 하지 않은 것이었다.

좋은 업무환경 만드는 역할을 간과했다.

급변하는 비지니스 사이드와 회사의 상황에 맞춰 Product이 잘 만들어지면, 큰 문제가 없을 줄 알았다. 그래서 늘 그래왔듯이, Product을 만드는 역할에 집중했다. 그런데 Product이 잘 만들어지려면…그런 환경이 필요하고, 누군가는 그런 환경을 만드는 것에 집중해야 한다. 나는 이 역할을 간과했다.

생각해보면…플랫폼개발본부는 35명 이상의 구성원이 7개의 팀으로 구성있고, 각 구성원들은 경력, 역할, 도메인에 대한 지식, 근속 등에서 많은 차이가 있다. 이들이 함께 협업을 하면서, 매끄럽게 일이 진행되려면…. 프로세스와 업무환경은 굉장히 중요할 수 밖에 없다.

그런데 나는 눈앞에 보이는 문제해결에 집중했고, 그러다보니 Product을 개발하면서 발생하는 각 팀간의 문제를 빠르게 인지하지 못했다. 인지를 한 부분이 있더라도, 현재 내가 담당하고 있는 Product 업무가 있다보니, 인지한 문제에 대해서 깊게 고민을 하지 못했다.

그러다보니, 일부 구성원들은 나에게 불만을 토로하기도 했으며, 일부 구성원들은 그런 매끄럽지 못한 업무 환경속에서 스트레스를 받기도 했다.

해결할 수 없는 문제를 계속 바라볼 수 밖에 없는 고통이 생각보다 컸다.

2022년도에 엔지니어의 가치가 최고 정점을 찍었다. 그 무슨짓을 해도 시니어 엔지니어를 채용할 수가 없었다. 리멤버의 통계를 보니, 가장 오퍼를 많이 받은 직군이 ‘테크 리크루터’라고 한다. 엔지니어 채용 경쟁속에서 밀리지 않으려면, ‘테크 리크루터’가 필요하기 때문이다. 그래서 대부분의 기업들이 엔지니어를 채용하기 위해 ‘테크 리크루터’를 먼저 채용했다.

아무튼, 이런 상황이다보니 리소스 부족으로 인해 Product 개발 속도에 한계가 있었고, 몇 개월간은 이를 가만히 지켜볼 수 밖에 없었다. 그런데 생각보다 이 과정에서 겪은 심리적 고통이 컸다. Product Owner로서는 이 부분이 내가 꼭 해결해야 할 문제는 아니었지만, 본부장으로서는 해결해야 하는 문제이기 때문이다.

이런 상황속에서 나를 더 힘들게 한 것은, 채용이 되어야 할 상황에 일부 인원이 퇴사를 한 것이었다. 리소스가 부족해서 채용을 열심히 했으나, 결과적으로 리소스가 더 줄었다. 정말 암울했다. 채용에 대한 절박함으로 인해 나는 10년전에 함께 일했던 엔지니어에게 10년만에 전화를 걸어보기도 했다.(날 기억못하면 어떡하나 걱정이 많았는데…다행히 그 분은 나를 기억하고 있었다.)

그런데 절망 끝까지 가더라도…..역시 사람이 죽으란 법은 없다. 정말 다행스럽게도 BE 시니어 엔지니어 3명과 기획팀장을 정말 운좋게 예상치 못한 방법으로 채용할 수 있었고, 그 이후부터 Product 개발 속도가 굉장히 빨라졌다.

그래서 2023년을 철저하게 준비했다.

다행스러운건 늦게라도 이 문제를 스스로 인지할 수 있었다는 점이다. 그래서 변화가 필요했다.

Product 개발

  • 2023년 로드맵을 구상하는데 신경을 많이 썼다. 그래서 2022년 연말이 생각보다 바빴다.
  • 합리적인 기준을 마련하고 그 기준에 맞게 개발계획을 수립하는데에 많은 노력을 기울였고, 그 과정에서 생각보다 많은 커뮤니케이션이 있었다.
  • 그런데 로드맵이라는게 상황에 따라 변할 수도 있고, 운영성 업무도 있기 때문에….현실적으로 실현가능한 목표를 수립하고 그 목표를 달성할 수 있는 전략을 구상했다.
  • 목표를 달성하기 위해서는 무엇보다 그 목표에 집중할 수 있는 환경이 필요했다. 그래서 그 환경을 지키기 위한 전략적 커뮤니케이션을 해야했다.
  • 목표수립은 문서작성을 통해 1차적으로 완료되는 것이 아니라, 바로 실행해야만 1차적으로 완료되는 것이다. 그래서 바로 실행해야 하는 과제를 정하고 계획을 바로 실행했다.

개발조직 운영

  • 회사 전체인원이 150명을 넘어섰고, 우리 본부만 하더라도 35명의 구성원이 있다. 사람이 많으면 그 과정에서 다양한 문제가 발생한다. 각 문제에 대한 근본적인 원인을 고민했고, 그 과정에서 팀장들과 많은 논의를 했다.
  • 레몬베이스를 도입하여, 각 구성원들이 서로 피드백을 주고 1 on 1을 할 수 있도록 했다. 사실, 레몬베이스는 성과관리 시스템인데, 나는 소통의 목적으로 서비스를 이용하기로 했다.
  • 다른 회사들과 마찬가지로….나도 인프라비용을 포함해서 비용을 절감할 수 있는 전략을 수립했다. 그리고 보안담당자와 함께 IT 예산을 관리할 수 있는 전략도 수립했다.
  • 업무자동화에 좀 더 신경을 쓰기로 했다. 내 업무 뿐만아니라 다른 유관부서의 업무도 자동화 시킬 수 있는 고민을 했다.(이럴 때 zapier가 많은 도움이 된다.)
  • 어떻게하면 우리 본부의 성과가 잘 드러날 수 있는지 고민했다. 생각해보니…이 부분도 나의 중요한 역할이었다.

Product Owner 역할

나에게 리더로서의 역할도 중요했지만, Product Owner로서의 역할도 안 할 수는 없는 상황이었다. 누군가 나를 대체할 수 없었기 때문에, 이 역할을 위임할 수 없었다. 이 과정에서 많은 힘겨움이 있었지만 다행스럽게도, 각 구성원들이 많은 노력을 했고, 좋은 성과를 낼 수 있었다.

Academy Product 론치

생각해보니 매년 새로운 Product을 론치했었다. 2022년에도 새로운 Product을 론치했다. 2달동안 모든 구성원들이 열심히 달려서, 데이터라벨링 교육 Product을 론치했다.

  • 결제시스템을 넣어서 사용자가 교육과정을 결제할 수 있도록 했다. 물론, 환불도 가능하다.
  • 2달만에 기획/디자인/개발을 완료해야 했기 때문에 첫 배포 때는 부득이하게 하드코딩이 많았다. 그러나 운영을 하면서 하드코딩들을 점차 걷어냈다.
  • 운영팀에서도 많은 노력이 있었고, 비지니스적으로 좋은 성과를 낼 수 있었다.

데이터라벨링 Flow의 처음과 끝을 마무리!

데이터라벨링 플랫폼에서 가장 어려운 부분이 있다. 소스데이터 업로드와 결과데이터 추출이라는 영역이다.

올해 이 부분을 마무리지었다. 즉, 우리 플랫폼에서는 이제 No-Code로 데이터세팅, 데이터라벨링 프로젝트 진행, 결과데이터 추출이 가능하다.

이쪽 도메인을 잘 모르면 이해할 수 없는 이야기일테지만…아무튼 그렇다. 개인적으로 참 의미있는 성과이다.

데이터측정 업무 고도화

Product의 사용자가 많아지면, 사용자의 서비스 이용행태에 대한 정량적데이터가 필요하다. 실제로 각 유관부서에서 해당 데이터를 많이 요구하기도 한다. 특히, 마케팅을 많이 수행하는 부서에서는 마케팅 각 채널에 대한 성과측정이 필수이기 때문에, 이에 대한 정교한 설계 및 관리가 필요하다. 그래서 나는 2가지 측면에서 데이터측정 업무를 고도화시켰다.

GTM/GA 측정

  • 생각보다 GTM 운영을 위한 설계에 많은 시간을 투자했다. GTM 설정을 각 클릭요소마다 모두 트리거를 설정하여 태그를 생성하면 효율적으로 관리 될 수 없다. 따라서, 운영을 위한 설계가 필요하고, 이를 토대로 FE와 유기적인 협업이 필요하다.
  • 아 네이밍! 네이밍이 중요하다. 정말 중요하다. 그런데 신기한 건, 네이밍을 구상하다보면 자연스럽게 측정방향성에 대한 설계가 된다.

데이터엔지니어와의 협업(Big query 활용)

  • GA 데이터는 한계가 있다. 그리고 솔직히, 유실도 있으며, 샘플링 혹은 기준점적용도 되기 때문에 내가 원하는 데이터를 보는데 많은 한계가 있다.
  • 그렇다고 로그성 데이터를 RDB에 쌓을 수는 없다. 그래서 올해에는 많은 부분을 데이터엔지니어들과 협업했다. 그만큼 복잡도도 올라가고, 개발요소가 늘어나기 때문에 어려움이 있었는데 결과적으로는 많은 성과가 있었다.
  • 데이터엔지니어를 통해 인사이트 있는 데이터를 제공하기 위해서는 크게 3가지가 필요하다. 이 3가지만 명확하고 합리적이면 된다.
    • 목표가 무엇인가?
    • 어떻게 데이터를 적재할 것인가?
    • 이 데이터를 어떻게 볼 것인가?

총평

  • 2022년도도 참 많이 힘들었다. 그래도 그 과정에서 리더로서 성장할 수 있는 기회를 발견할 수 있었다.
  • 매 년 회고를 할 때마다 나 스스로 강조하는 것이지만…2023년도에는 좀 더 가족과 함께 할 수 있도록 노력해야 한다.
  • 그리고 건강해야 한다. 건강하지 않으면, 다 소용없다.

0 Shares:
답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

You May Also Like
Read More

기획자와 스토아철학

기획자로서 일을 하다보면 생각보다 많은 부분에서 우울할 때가 있다. 그 우울함이 심해지면 '나는 과연 필요한 존재가 맞는가?'라는 생각까지 들곤 한다. 문제는 이런 경험을 자주 할수록 자존감이 낮아진다는 것이다. 내가 겪어온 경험을 토대로 이 문제를 어떻게 극복했는지 이야기하고자 한다.
Read More

내 리더가 회사를 떠났다.

어떤 한 사람이 있다. 그 사람을 보면서 나는 이런 생각을 했다. "저 분의 인성과 역량을 닮고 싶다. 내 아들이 커서 어른이 된다면 나의 모습보다는 저 분의 모습을 닮았으면 좋겠다." 그 분은 내가 현재 재직중인 회사의 CTO이자 나의 리더였다. 아이러니하게도 그 분과 나는 전혀 다른 성격의 소유자이고 업무 스타일도 많이 달랐다. 하지만 난 정말로 그분을 닮고 싶었다.
2021년 회고
Read More

2021년 회고(Product Owner, 가족, 성장)

회사에는 동료와 일이 있다. 가정에는 아내와 애들, 육아업무가 있다. 그러나 그 어디에도 나는 없었다. 원래 나 본연의 내가 존재할 수 있는 시간과 장소는 없었다. 단지, 의무로서의 나만 존재했다. 언뜻 생각해보면 참 서글프기도 하지만 잘 생각해보면 꼭 그렇지도 않다. 현재 나의 상황, 역할, 가족, 일.....그 모든 것이 결국은 나를 구성한다. 원래 나 본연의 나는 처음부터 없는 것인지도 모르겠다.
Read More

PO, PM들의 존재이유를 알려주는 책, 인스파이어드

일반적으로 제품개발(Product 개발)이라고 하면 기획/디자인/개발 과정을 거쳐 Product이 완성되는 과정을 의미한다. 그런데 인스파이어드 책의 저자 마티 케이건은 제품을 발견하는 과정과 제품을 시장에 전달하는 과정도 제품개발에 속한 과정이라고 정의한다. 그런 의미로 볼 때 Product을 개발한다는 것은 영업/마케팅 조직의 비지니스 과정과 분리되어 있지 않다는 것을 의미한다.