brunch

You can make anything
by writing

C.S.Lewis

by 조영수 Aug 13. 2020

프로덕트 매니저, 프로덕트 오너!

프로덕트는 좋은 팀이 만듭니다. 그래서 좋은 리더가 필요합니다.

<프로덕트 오너>, <프로덕트 매니저>, <기획자> 이 중 여러분은 어떤 직함을 가지고 계신가요? 세 직무 간 교집합은 많지만 구분이 명확하지는 않습니다.


제가 그동안 읽어본 아티클로 간단히 정리해보면,


해외에서는 <프로덕트 매니저>를 <프로덕트 오너>의 상위 직군으로 분류합니다. 프로덕트 매니저 아래 여러 프로덕트 오너가 있는 구조이죠.


국내에서는 반대로 <프로덕트 오너>가 <프로덕트 매니저>의 상위 개념으로 분류하고 있는 것 같습니다. 어감상 매니저보다는 오너가 더 윗 직급으로 느껴져서 그런 것 같기도 합니다 ^^;;


<프로덕트 매니저>와 <기획자>가 조금 더 비슷한 역할을 수행하는데, <프로덕트 오너>는 일정관리와 의사결정에 포커스가 되어있고, <프로덕트 매니저>와 <기획자>는 실무 기획까지 포함하고 있습니다.


이 개념이 완전히 정착된 건 아니고 자리를 잡아가고 있는 과정이라고 보면 될 것 같습니다. 사실 우리가 용어를 정의하기 어려운 이유는 세 직무 간 공통점이 너무나 많기 때문입니다. 프로덕트 담당자는 비즈니스와 기술, 고객을 이해하고 동료들과의 협업을 통해 좋은 제품을 만드는 역할을 수행합니다.


Source: Product Focus



잠시 다른 이야기를 곁들이면,


지금은 대다수의 IT 회사들이 <개발자 모셔오기>에 노력을 쏟고 있습니다. 좋은 제품을 만들기 위해서는 좋은 개발자가 필요하기 때문이죠. 그래서 네임밸류, 연봉, 문화, 복지를 앞세워 개발자 채용에 힘주고 있습니다. 그런데 좋은 개발자를 채용한다고 해서 문제가 해결되지 않습니다. 좋은 개발자일수록 회사와 Fit이 안 맞으면 얼마 안 돼서 그만두는 경우가 많습니다.


여기서 회사와의 Fit이 중요한데, Fit이 안 맞는 2가지 이유를 꼽아보겠습니다.


1. 개발자 간의 보이지 않는 힘겨루기

지극히 개인적인 의견이지만 개발자를 두 그룹으로 분류하면 <비즈니스 중심의 개발자>와 <아키텍처 중심의 개발자>가 있습니다. 전자는 아키텍처가 조금 엉성하더라도 일단 비즈니스가 돌아가게 만드는데 중점을 두는 유형으로 비즈니스 관계자들이 좋아합니다. 후자는 아키텍처를 중시하는 유형으로 예상되는 모든 케이스를 고려해 기초공사와 설계를 중요하게 생각합니다.


전자를 중시하는 조직에서는 비즈니스가 조금 더 빠르게 성장할 수 있지만 시간이 지날수록 레거시 코드로 인해 확장성이 떨어지게 됩니다. 그리고 메인 개발자가 이탈하면 그때부터는 헬게이트가 열립니다. 후자를 중시하는 조직에서는 완성도 높은 제품을 만들 수 있지만 고객이 원하는 제품이 아닌 개발자가 원하는 제품을 만들게 될 수도 있습니다.


한 팀에 <비즈니스 중심의 개발자>와 <아키텍처 중심의 개발자>가 섞여있고 중재자가 없는 경우에 이들은 부딪히게 됩니다. 이상적으로는 잘 섞여주면 좋겠지만 서로의 결이 다르다 보니 좀처럼 섞이기가 쉽지 않습니다. 서로가 서로에게 불만이 쌓이게 되고 회사가 어느 한쪽 편을 들어주면 반대쪽 편의 개발자는 조직을 떠나게 됩니다.


2. 성장하지 않고 소모되는 느낌

아마도 IT 직군 내에서는 <개발 직군>의 학습량이 가장 많을 거라 생각되는데요. 기술 트렌드가 빠르게 변하기 때문에 고인물이 되지 않기 위해서는 필연적으로 계속 공부를 해야 합니다. 그리고 대부분의 개발자들이 자신이 뒷처지고 있다고 느끼면 불안해지기 시작합니다.


또한 새로운 언어와 프레임워크가 나오고 핫한 기업들에서 그 기술들을 사용하고 있는데 나만 (구) 기술을 사용하고 있다는 생각이 들면 불안감이 찾아오고, 새로운 프로젝트 없이 남이 짜 놓은 코드를 유지보수만 하면서 소모되는 느낌이 들면 회사에 계속 있어야 하는가? 에 대한 회의감이 듭니다. 그리고 결심을 하고 떠나게 되죠!



이야기가 잠시 샛길로 샜지만 그래서 역으로 프로덕트 오너의 역할이 중요해지고 있습니다. 프로덕트 오너는 프로덕트의 중심에서 모든 의사결정을 진행합니다. 경영진과 협의해서 비즈니스 방향을 정하고, 기술 부채를 파악하고, 고객의 소리를 귀담아듣습니다. 그리고 프로덕트 우선순위와 팀 구성원들의 성향과 상황에 맞춰 각자의 역할에만 집중할 수 있도록 업무를 분배하고 설득합니다.


프로덕트는 팀이 만듭니다. 그렇기 때문에 좋은 팀을 구성해야 좋은 제품이 만들어집니다. 좋은 팀을 구성하기 위해서는 좋은 리더가 필수적입니다.



아래 영상에서는 애자일 조직에서 프로덕트 일정을 관리하고 스프린트 회고를 진행하는 방식을 소개하고 있습니다. 일정을 관리하는 중간 관리자 분들이 참고해보시면 좋을 것 같습니다.






매거진의 이전글 프로덕트 매니저, 데이터 분석 얼마나 알아야 할까요?
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari