프로덕트 매니저 인간 관계도 - 기술직군편
2편 : 기술직군과 사이좋게 지내기
PM은 기술직군(tech) 동료들과 함께 일합니다.
크게 보면 아래 6개 직군인데요.
1. 서버 개발자
2. 모바일 클라이언트 개발자
3. 웹 프론트엔드 개발자
4. 데이터 분석가
5. 데이터 사이언티스트
6. QA
이번 챕터에서는 위 6개 직군 동료들의 업무를 알아보고, 함께 일하는 센스에 대해 이야기해 보겠습니다.
1. 서버 개발자(Server Developer)
1. 역할
서버 개발자는 사업/서비스의 논리를 컴퓨터 프로그래밍으로 구현합니다.
서버 개발자는 백엔드 개발자(Backend Developer)라고도 부릅니다. 보이지 않는 뒷단(backend)을 만드는 사람이라는 뜻입니다. 이들은
1) 시스템 구성도를 그리고,
2) 데이터베이스(DB)를 구축하며,
3) 필요한 API를 만들어 내고,
4) 대용량 트래픽을 처리한 뒤,
5) 보안 처리까지 담당합니다.
쉽게 생각하면 대형마트 건설과 비슷합니다.
1. 시스템 구성도 그리기 → 마트 설계도 그리기
2. DB 만들기 → 재고 창고 / 판매 장부 만들기
3. API 제공하기 → 상품 공급 수레 만들기
4. 트래픽 처리하기 → 입구 / 엘베 만들기
5. 보안 처리하기 → 경보기 설치 / 보안요원 채용
이처럼 서버 개발자는 제품의 거의 모든 것에 관여합니다. 때문에 새로운 일을 시작하려면 반드시 서버팀을 거쳐야 합니다. 심지어 이들은 사업과 연관이 적은 업무도 책임집니다. 예를 들어 [4번 트래픽 처리]의 경우 PM이 직접적으로 요청하는 업무는 아니지만 기술 영역에서는 중요도가 무척 높은 일입니다.
2. 서버 개발자 도와주기
서버 개발자를 돕고 싶다면 우선 면담부터 합니다. 개발자들은 각자 선호하는 업무 스타일이 있습니다. 예를 들어 어떤 개발자는 사업 구상 단계부터 함께하고 싶어 하는 반면, 다른 개발자는 요구사항만 전달해 달라고 요청하기도 합니다. 확실한 정답은 없으며 스타일의 장단일 뿐입니다. 동료들이 장점 위주로 발휘될 수 있도록 지지하는 것도 PM의 역량입니다.
다만, 모든 개발자가 확실하게 선호하는 공통점은 있습니다. 아래 3가지를 지키면 사이좋게 일하는데 도움이 됩니다.
첫째, 요구사항은 명료하게 합니다. 명료하다는 것은 1) 뚜렷한 원칙이 있고 2) 원칙 아래 모든 디테일에 통일성이 있으며 3) 이해하기 쉽다는 의미입니다. 일부 PM의 기획서를 보면 2000년대 초반 일본 가전제품 설명서처럼 요구사항이 깨알같이 적혀있는 경우가 있습니다. 이런 문서는 개발자가 읽을 수 없습니다. 만들어야 할 제품의 요구사항은 한 문장으로도 설명 가능할 만큼 단순해야 합니다.
둘째, 유연하게 대화합니다. 개발자에게는 통보가 아니라 대화를 해야 합니다. 똑똑한 서버팀과 일하다 보면 사업의 논리를 꿰뚫는 훌륭한 대안을 제시하는 경우가 많습니다. PM이 당장의 운영에 매몰되어 서비스의 본질을 잊었을 때 오히려 시스템을 관장하는 사람들이 단순하고 직설적인 해결책을 떠올립니다. ‘개발은 사업 이해도가 낮아’처럼 고압적인 태도를 가진다면 좋은 팀워크가 나올 수 없습니다.
셋째, 검토된 일정을 존중합니다. PM이 개발팀과 가장 첨예하게 부딪히는 것이 일정입니다. PM 입장에서는 빨리 할 수 있을 것 같은데, 개발팀에서는 시간이 걸린다고 말할 때 싸움이 납니다. 이럴 때는 대개 개발팀 말대로 하는 것이 장기적으로 훨씬 낫습니다. 다만 구체적인 이유도 모르고 따르면 안 됩니다. 허심탄회하게 대화하여 납득할만한 이유인지 꼼꼼하게 확인하고 조정합니다. (개발팀도 설명할 의무가 있습니다)
2. 모바일 클라이언트 개발자(iOS/And Developer)
1. 역할
모바일 클라이언트 개발자(이하 클라이언트 개발자)는 서버의 논리를 모바일 앱을 통해 사용자에게 전달합니다.
클라이언트 개발자는 안드로이드, iOS 앱을 만듭니다. 이들은 구글과 애플에서 제공하는 도구(언어/스튜디오)를 이용하여
1) 화면과 버튼을 그리고,
2) 그것을 서버 API와 연결하며,
3) 사용자의 행동 관찰을 위해 로그를 설치한 뒤
4) A/B테스트를 돕기도 합니다.
대형마트에 비유하면 아래와 같습니다.
1. 화면과 버튼 그리기 → 물품 진열대 만들기
2. 서버 API 연결 → 상품 창고와 진열대 연결
3. 사용자 행동 관찰 로그 → 진열대 카메라 설치
4. A/B테스트 → 상품 진열 방식 실험
클라이언트 개발은 서버 개발과 달리 배포에 민감합니다. 제품이 한번 잘못 배포되면 수정이 어렵기 때문입니다. 가전제품 판매와 비슷한데요, 냉장고가 고장 났다고 해서 원격으로 수정할 수 없는 것과 같습니다. 서버나 웹의 경우 언제든지 모든 사용자에게 새로운 배포가 가능하지만 클라이언트는 스마트폰에 다운로드 받는다는 특성상 품질 검증에 예민합니다.
2. 모바일 클라이언트 개발자 도와주기
기본적으로 클라이언트 개발자를 돕는 것은 서버 개발자와 다르지 않습니다. 이들 역시 생각이 명료하고, 유연하며, 자신들의 의견을 존중하는 PM과 일하고 싶어 합니다. 다만 아래 2가지를 추가적으로 신경 씁니다.
첫째, 디자이너와 직접 소통하도록 돕습니다. 클라이언트 개발자는 주로 프로덕트 디자이너와 협의합니다. 단순한 버튼 위치에서부터 화면 순서, 각종 효과까지 챙깁니다. PM이 중간에 자꾸 끼어들어서 어쭙잖게 한두마디 거들면 오히려 방해만 됩니다. 좋은 PM은 초기 방향성과 레퍼런스들만 분명하게 전달하고 동료들이 먼저 요청하는 경우에 조언하는 포지션입니다.
둘째, 배포 관리를 돕습니다. 앞서 클라이언트 개발자들은 배포에 민감하다고 말했습니다. 오류가 발생하지 않도록 충분한 검사(QA) 일정을 확보합니다. 여러 클라이언트 배포를 조율하는 것도 중요합니다. 예를 들어 네이버의 경우 1개 앱 안에 1) 단순 검색부터 2) 쇼핑 3) AI까지 수백 개의 서비스가 있습니다. 클라이언트 배포는 기차 시간표처럼 2-3주에 1번 정기적인 배포 일정을 잡고 모든 서비스가 일관된 규칙을 따를 수 있도록 합니다.
3. 웹프론트엔드 개발자(Web Frontend Developer)
1. 역할
웹프론트엔드 개발자는 서버의 논리를 웹을 통해 사용자에게 전달합니다. (일부 서비스의 경우 앱은 껍데기만 만들어 둔 뒤 웹으로 알맹이를 개발하기도 합니다.)
웹의 경우 앱보다 업무가 분리되어 있습니다.
첫 번째 업무는 마크업 개발입니다. 이들은 디자이너가 잡아놓은 화면을 코드의 형태로 옮겨놓습니다. 상대적 볼때 진입장벽이 낮은 개발이기 때문에 IT가 본업인 회사들도 외주로 맡기는 경우가 종종 있습니다. 대개 프론트엔드 개발자들의 일손이 부족할 때 활용합니다. (다만, 이 분야 역시 복잡한 인터랙션이 필요할 경우 실력이 뛰어난 개발자가 필요한 것은 마찬가지입니다.)
두 번째는 마크업 외 프론트엔드 개발입니다. 이들은 마크업으로 구현한 화면을 서버의 논리와 연결합니다. 모바일 클라이언트 개발 업무와 크게 다르지 않습니다. 다만 웹의 경우 스토어에 등록할 필요가 없기 때문에 (= 새로운 버전을 배포하면 기존 화면이 모두 자동으로 업데이트됨) 배포로 인한 스트레스에서 훨씬 자유롭습니다.
2. 웹프론트엔드 개발자 도와주기
웹프론트엔드 개발자도 다른 개발자들과 같습니다. 다만 웹프론트만의 장점을 살리기 위해서는 아래 원칙을 합의하는 것이 좋습니다.
첫째, 속도를 내줬다면 신뢰로 대답한다. 웹개발은 특유의 유연성과 자유도 때문에 속도 중심으로 개발하는 경우가 많습니다. 대개 마케팅 페이지처럼 사업부서의 긴급한 요청건이 생기면 웹에서 대응합니다. 이렇게 긴급건이 많다 보면 사소한 실수가 많이 발생하는데요. PM은 이런 자잘한 실수를 뒤에서 챙기며 웹개발에 속도감을 더해주는 역할을 합니다.
4. 데이터 분석가(Data Analyst)
1. 역할
데이터 분석가는 사업 부서의 가설을 검증하고 지표를 세팅합니다.
데이터 분석가는 PM이 요청한 가설을 검증합니다. 이들은 기본적으로 SQL이나 파이썬과 같은 분석 도구를 매우 능숙하게 사용합니다. 거대한 DB(Database)에 접근하여 원하는 정보만 뽑아 빠른 속도로 가공하는 데 특화되어 있습니다. 수천만 권의 데이터가 쌓여있는 도서관에서 필요한 책만 찾아내는 사서들과 같습니다. 때문에 PM은 가설 검증이 필요할 때 혼자 끙끙 앓는 것이 아니라 이들에게 도움을 받습니다.
분석가는 지표도 세팅합니다. PM이 서비스를 운영하려면 일 단위로 핵심 지표를 관찰해야 합니다. 아침 해가 뜨면 전날의 성적표를 확인하며 출근하는 것이 관리자들의 일상입니다. 분석가들은 동료들이 확인하기 편한 1) 메신저, 2) 대시보드 등 도구를 통해 지표의 틀을 잡습니다. 새로운 기능이 출시되면 DB에 쌓인 정보를 청소하여 유의미한 정보로 편집해 둡니다.
2. 데이터 분석가 도와주기
데이터 분석가는 프로덕트 디자이너 다음으로 PM과 짝꿍처럼 일하는 직종입니다. 이들이 제공하는 분석 기술과 인사이트는 PM이 자기 능력을 3-4배 증폭할 수 있도록 돕습니다. 데이터 분석가와 매끄럽게 일하려면 PM은 아래 2가지 사항을 유의합니다.
첫째, 가설 중심으로 분석 요청합니다. 미숙한 PM은 본인이 알고 싶은 결과만 앞뒤 맥락 자른 뒤 요청합니다. 물론 이런 경우라도 분석가들이 답을 낼 수 있지만 바람직하지 않습니다. 대개 분석가들은 서버/클라이언트의 데이터 구조를 완벽하게 꿰고 때문에 PM보다 어떤 면에서 월등히 똑똑합니다. 그들에게는 퀴즈를 내지 말고 차라리 “OO는 OO일 것이다가 고민이에요” 라며 상담을 신청한다면 훨씬 좋은 결과를 만들어 줍니다.
둘째, 분석가들이 사용할 데이터의 품질을 관리해 둡니다. 분석가는 데이터를 만들어 내는 사람이 아닙니다. 그들은 일종의 요리사와 같습니다. 주어진 데이터를 활용해 맛있는 결과물을 생산합니다. PM이 데이터의 품질에 관심이 없으면 기능 구현에 바쁜 개발팀에서 잘못된 데이터를 저장하곤 합니다. 상한 재료만 있다면 천재 분석가도 인사이트를 뽑아낼 수 없습니다. PM은 개발 완료 전, 필요 데이터를 확인하고 정확히 적재되고 있는지 검증합니다.
5. 데이터 사이언티스트(Data Scientist)
1. 역할
데이터 사이언티스트는 머신러닝을 활용해 기술적인 핵심역량을 만듭니다.
데이터 사이언스는 세부 분야가 매우 다양합니다. PM은 주로 머신러닝 모델러(이하 ML 모델러)들과 일합니다. 모델러들은 머신러닝을 활용하여 사업에 적용할 수 있는 다양한 모델을 개발합니다. 여기서 모델이란
1) 과거의 데이터를 학습하여,
2) 현재 상황을 주었을 때
3) 가장 좋은 미래가 기대되는 답을 찾는 프로그래밍을 말합니다.
예를 들어 배민 같은 서비스의 경우 아래처럼 다양한 모델을 도입할 수 있습니다.
주요 모델 예시
1. 배달 비용 할증 모델
실시간 주문수와
운행 중인 기사수를 확인하여
30분 내 도착 가능한
최적의 배달비를 제안한다.
2. 기사 배정 모델
1개의 주문에 대해
주변 100명의 기사 중
가장 수락 확률이 높은
기사를 순서대로 제안한다.
3. 30분 단위 수요 예측 모델
30분 뒤 배달 주문이
많이 발생할 지역을 예측한다.
머신러닝 기술은 사업에 적절하게 활용하면 수많은 비효율을 걷어냅니다. 더불어 기술적인 진입 장벽도 세울 수 있습니다.
1) 좋은 모델에는 방대한 데이터가 필요합니다.
2) 선발 기업만 ML모델을 도입할 수 있습니다.
3) 우수한 모델은 사업의 성장을 돕고,
4) 성장한 사업이 다시 모델의 성능을 개선합니다.
후발 기업들은 튼튼한 모델을 가지고 있는 기존 기업을 뛰어넘기 어려워집니다.
2. 데이터 사이언티스트 도와주기
PM은 아래 2가지 방식으로 ML모델러를 도울 수 있습니다.
첫째, 현장의 감각을 꾸준히 전달합니다.
PM은 모델러들에게 사업 현장의 논리를 끊임없이 전달해야 합니다. 모델러들은 좋은 모델을 만들기 위해 말 그대로 데이터에 파묻혀서 끊임없이 테스트를 돌립니다. 이렇게 폐관수련을 하다 보면 모델의 성능 자체는 매우 우수하지만 실생활에는 적용할 수 없는 경우가 생깁니다. 예를 들어 배달 할증액을 예측하는 모델을 만들었는데, 1분 단위로 금액이 계속 달라진다면 서비스에 적용할 수 없습니다. 고객들이 신뢰할 수 없으니까요.
둘째, 서버팀과 소통에 가교 역할을 합니다.
좋은 모델이 나오기 위해서는 최소 수십만 건의 과거 데이터가 필요합니다. 또한 완성된 모델을 적용하기 위해 실시간 데이터도 끊임없이 흘러들어와야 합니다. 모든 과정이 서버 개발의 도움을 필요로 합니다. PM은 모델러들이 진행하려는 머신러닝 과제의 중요성을 서버팀에 공유하고 해야 하는 업무를 정리하여 전달합니다. 모델러는 연구에만 집중할 수 있도록 돕습니다.
6. QA (Quality Assurance)
1. 역할
QA는 프로그램의 무결성을 확인하고 취약점이 없는지 체크합니다.
QA팀은 완성된 제품이 세상으로 나가기 전 수백 가지 테스트를 통해 문제점을 찾아냅니다. 보통 개발 기간이 4주라면 이후 1-2주 정도 QA를 진행하며 문제 지점을 발견하는 것이 일반적입니다. 이들은 TC(Test Case)라는 문서를 만들어 테스트해 볼 상황을 정리하고 검증하며, 문제를 찾으면 각각 이슈(Issue)로 발행하여 PM과 개발팀에 전달합니다. 이슈를 할당받은 담당자는 QA기간 중 문제를 해결합니다.
상당수 회사가 QA 시 외부 업체를 사용합니다. (여태까지 제가 경험한 회사들은 전부 그랬습니다.) 대개 한 명의 책임 QA관리자가 여러 명의 QA실무자를 관리하는 형태로 운영됩니다. QA는 회사의 규모가 일정 수준 이상일 때부터 부각됩니다. 서비스를 배포하고 발생할 사고의 위험이 QA에 들어가는 자원보다 많을 때부터 QA가 필요해집니다. 작은 서비스는 PM이 QA 하는 경우도 많습니다.
2. QA 도와주기
회사마다 QA팀을 운영하는 방식이 워낙 천차만별인지라 정형화된 소통방식은 없습니다. 하지만 아래 2가지는 모든 환경에서 효과적인 소통 원칙입니다.
첫째, 기획 의도를 구체적으로 설명합니다.
PM은 개발이 어느 정도 진행되면 QA 리뷰를 합니다. 이때 1) 기획의 의도, 2) 주요 검증 포인트, 3) 개발 시 파악된 취약점을 전달합니다. 리뷰 시간에는 기획의 의도를 강조해야 합니다. 문서를 줄줄 읽기보다 새로운 기능이 사용자에게 공개되었을 때 무엇을 핵심인지 위주로 설명합니다. 이렇게 해야 QA팀도 노가다성 TC가 아닌 합리적인 TC를 작성할 수 있습니다.
둘째, 사업적 중요도를 허심탄회하게 소통합니다.
PM은 QA팀과 일정 관련해서 충돌할 일이 잦습니다. 특히 강경한 사업 부서가 있는 경우 개발이 완료되면 QA를 생략하고 바로 출시하자고 소리치는 경우도 흔합니다. (사실 사업부서의 마음도 충분히 이해할 수 있습니다.) QA팀이 검증 기간을 길게 잡는다면 각각 기능을 나누어 중요도를 함께 판단하고 범위를 조정합니다. 충분히 대책만 세워둔다면 QA는 절대 불변의 일정이 아닙니다.
정리하며
총 2편의 글을 통해 사업(non-tech) 직군, 기술(tech) 직군, 총 12개 직군의 1) 역할과 2) 협업방식에 대해 이야기해 보았습니다. 사실 PM은 위 12개 직군 외에도 개인정보팀, 보안팀, 법무팀, 전략팀, 재무팀, 인프라팀 등 다양한 부서와 주기적으로 소통해야 하는 입장이지만 12개 팀이야 말로 PM과 가장 가까운 동료입니다.
PM은 제품 제작 시 가장 중요한 사람은 아니지만, 가장 중앙에 있는 사람인 것은 맞습니다. 똑똑하고 부지런한 전문가들 사이에서 때로는 강단있게, 또 때로는 부드럽게 소통해야 합니다. PM이 제품을 오랜 시간 아끼며 성장시킨다면 동료 모두 PM을 존중합니다. PM이 발생시키는 구심력은 제품과 조직이 아름답게 유지되는 원동력이 됩니다.
사이좋게 일하는 개발팀의 모습 c. yve.atelier