프로덕트 매니저는 무슨 일을 하고 있을까

- '애자일 소프트웨어 개발 선언" 
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

- 사용자 중심의 제품 구현이 힘을 얻은 것은 얼마 되지 않았다. 그전에는 이해관계자가 요 구하는 대로 제품을 만들고 제때 납품하면 되는 업무수행 방식이 주를 이루었다. 단계적 으로 업무가 진행되고 위에서 떨어진다는 수직적인 의사소통의 의미도 담아 이러한 개 발 방식을 워터폴 Waterfall 이라고 부른다. 워터폴 개발 방식은 모든 것이 사전에 계획되어 납기에 맞추어 결과물을 내는 것이 최고의 목표이다. 그렇기 때문에 계획이 옳고 그른지 를 생각하기보다는 제때 해내는 것이 가장 중요하다. 이와 같은 방식에 의문을 제기하고 가치 있는 제품을 빠르게 고객에게 전달하자는 기조를 세우게 된 것이 애자일 개발 방법론agile software development이다. 의미 있는 배경과 공감할 수 있는 내용과는 달리 현업에서 이를 적용하는 데에는 상당한 어려움이 있다.
제품의 특성에 따라 사용자에 전달하는 유의미한 가치뿐만 아니라 감안해야 하는 요소가 많은 제품이 있다. 법적인 규제 또는 재무적인 구성 등 정책을 정하면서 논의하고 점검해 야 할 부분이 많은 경우가 있다. 이 과정을 생략하고 사용자에게 제품을 출시한다면 사용 자는 행복할 수 있으나 기업은 건전성을 잃을 수 있다. 또한 이러한 정책 파악 과정을 애 자일 개발 방법론에 따라 프로덕트 매니저뿐만 아니라 제품팀 모두가 참여하게 된다면 유관부서와의 협업 내용을 모든 담당자가 숙지해야 한다. 이는 구현 담당자의 집중을 분산시키는 결정일 수 있다.
-  프로덕트 매니저는 사용자가 제품을 만났을 때의 경험에 대한 설계 책임을 진다. 사업적인 목표 달성을 위해 노력하고 마지막으로는 기술적으로 지속 가능하고 안정 적이며 효율적인 방식을 사용해야 한다. 벤다이어그램이 프로덕트 매니저의 이상적인 모 델을 대표한다면, 프로덕트 매니저의 현실적인 역할은 시멘트에 비유할 수 있다.
프로덕트 매니저는 제품이라는 집을 짓기 위해서 벽돌을 쌓아 올리고 연결하여 완성하고 자 한다. 아무리 뛰어난 능력을 갖춘 프로덕트 매니저라도 각각의 업무를 하나로 연결해 서 종합적인 사고를 할 수 없다면 의미가 없다. 예를 들어 마티 케이건의 벤다이어그램에 서 사용자 경험과 사업적 효용만 생각한 제품이라면 기술적인 결함으로 인해 결국 안정 적으로 운영될 수 없으며, 사용자 경험과 기술적인 결합만을 생각한 제품이라면 사업적 으로 영속이 불가능해서 실패할 수밖에 없다. 마지막으로 사업적인 목적이 뚜렷하게 반 영된 기술이라고 하더라도 사용자가 쓸 수 없다면 범용성을 띠지 않아 결국 아는 사람만 아는 서비스가 된다. 비단 이와 같은 업무 영역이 아니고도 프로덕트 매니저는 제품이 시 장에 안착하여 사용자 반응을 끌어내는 역할을 하게 된다. 조직마다 비어 있는 공간이 다 르기 때문에 각 조직의 프로덕트 매니저는 개개인의 특성을 가질 수밖에 없다.
- 요구사항 정의서가 방향을 정하는 것이라면 실제로 어떻게 그 방향으로 나아 갈지를 결정하는 것은 화면 설계서이다. 두 문서는 서로 영향을 주고받기 때문에 하나의 문서로 작성되는 경우가 잦다. 한 팀에 프로덕트 매니저, 화면, 사용자 경험 설계 전문가, 프로덕트 디자이너가 모두 있다면 프로덕트 매니저가 요구사항 정의서, 화면 설계 전문가 가 화면 설계서 그리고 실제로 이를 디자이너가 구현할 것이다. 하지만 앞서 말한 것과 같 이 프로덕트 매니저가 요구사항 정의서와 화면 설계서를 함께 작성하는 경우가 더 잦다. 이유는 화면 설계서가 기본적으로 상위 정책을 바탕으로 하고 이에 대한 충분한 이해로 작 성해야 하기 때문이다. 사용자 경험 자체에 집중하는 것이 디자이너 역량을 더 살릴 수 있 기 때문에 상위 정책이 복잡하고 이에 대한 정확한 반영이 필요한 경우에는 프로덕트 매니 저가 이 업무를 담당하는 것이 효율적이다. 이와 같은 경우는 담당자가 여럿이기 때문에 각자의 업무에 집중할 수 있는 만큼 반대로 서로가 같은 공감대를 이루기 위한 커뮤니케이 션 비용이 증가한다. 반면 화면 설계서를 별도로 작성하지 않고 요구사항 정의서를 보고 제품팀이 곧바로 제품을 구현하는 경우도 있다. 조직마다 문화가 다르고 이는 그 조직에서 효과적이라고 생각하는 커뮤니케이션 방식과 닿아있으므로 우선 지금 당장 벌어지고 있는 커뮤니케이션 방식과 문법을 파악하는 것이 중요하다.
주니어 프로덕트 매니저라면 당장 기획서를 작성해야 할 때 자신의 스타일이나 커뮤니케 이션 방식이 적립되어 있지 않기 때문에 두려울 수 있다. 그렇다면 가장 먼저 해야 하는 일은 속한 조직에서 사용하는 문서를 확인하는 것이다. 조직에서 통용되는 문서의 종류 와 기준은 회사의 조직문화가 강하게 연결되어 있다. 가장 효율적인 커뮤니케이션 방식 은 기존의 방식이다. 제 아무리 대단히 뛰어난 방식이라도 현재 조직에서의 학습 비용이 필요하고 적응 기간이 필요하기 때문에 근본적으로 변화의 필요성이 없을 때에는 구관 이 명관이라는 것이다. 물론 기존 업무 방식에 개선점은 있을 수 있다. 조직에서 작성하 는 문서에 익숙해진다면 이 장에서 다루는 내용을 자신의 업무에 적용하면서 나에게 가 장 잘 어울리는 스타일을 정하자. 물론 기본적인 조직의 기조는 있겠지만 조직에서 필요 한 부분을 찾아서 당신의 커뮤니케이션 스타일과 문서 작성에 녹일 수 있다면 그것이 당신의 경쟁력이 될 것이다.
- 최종 시안이 확정되고 나면 디자인 담당자는 해당 시안을 바탕으로 프런트 구현 작업을 진행할 수 있도록 디자인 리소스를 마크업 담당자에게 전달한다. 전달 방식은 조직별로 다르다. 디자인 작업 원본 파일 형태로 전달하거나 제플린, 피그마 등 협업 툴을 통해 전 달하기도 한다.
웹 제품에서 디자인 다음으로 진행되는 작업은 마크업 개발이다. 마크업은 간단히 말 하면 이미지로 된 디자인이 코드로 된 웹페이지로 만들어지기 위한 연결고리와 같은 작 업이다. 마크업 개발자는 디자인 리소스를 바탕으로 제품을 구성하는 페이지를 하나씩 html 형태로 구현해낸다. 이 마크업 페이지는 실제로 동작하는 것은 아니고 말 그대로 제품의 디자인을 고스란히 코드 형태로 옮긴 것으로 보면 된다. 브라우저에 띄워 놓으면 실제 제품 페이지로 보이지만 클릭을 한다고 해서 무언가가 바뀌지도 움직이지도 않는 껍데기뿐인 페이지라고 생각하면 쉽다. 그러나 마크업으로 구현된 이상 그것은 더 이상 단순한 이미지가 아닌, 코드로 짜여진 웹페이지이다. 그리고 이렇게 만들어진 마크업을 가지고 실제로 동작하는 페이지를 만들어내는 것이 바로 프런트 개발에서 진행하는 작업이다. 
마크업 담당자가 1차 마크업 결과물을 완성하면 우선 프로덕트 매니저에게 이를 공유하 고, 프로덕트 매니저는 마크업 결과물을 검토하면서 기획서와 다르게 구현된 부분이 있 는지 확인한다. 필요시 마크업 담당자에게 수정을 요청해서 결과물에 반영시킨다. 경우 에 따라서는 마크업에 굳이 반영할 필요 없이 프런트 개발에서 처리가 가능한 것도 있으니, 마크업 담당자의 의견을 참고하도록 하자.
프로덕트 매니저가 요청한 수정 사항이 마크업에 모두 반영되면 디자인 담당자에게 디자인 필터링을 요청한다. 디자인 필터링이란 마크업 결과물이 시각적으로 디자인을 정확하 게 반영하고 있는지 디자이너가 검수하는 작업을 말한다. 필터링 작업이 필요한 이유는 코드 영역에서 이루어지는 마크업 작업을 하다 보면 디자인과 완전하게 일치하지 않는 부분이 발생할 수 있기 때문이다. 비록 일반적인 사용자는 눈치채기 어려운 미세한 차이 일지라도 제품의 시각적인 모양새는 본질적으로 디자이너의 손에서 만들어진 디자인과 동일해야 한다. 디자인 담당자는 이러한 필터링 작업을 통해 이미지로 된 디자인 결과물 을 제작하는 것을 넘어서 실제로 구현된 제품의 디자인을 감독하는 역할 또한 수행하게 된다.
- 디자인 필터링에서 마크업에 수정이 필요한 부분이 발견되면 디자인 담당자가 이를 마크 업 담당자에게 전달하고 마크업 담당자는 다시 해당 사항을 수정 반영하여 마크업을 완 성한다. 다만 마크업은 이 시점에서 최종본이 완성되었다고 보기는 어렵다. 이후 마크업 을 전달받아 프런트 개발을 진행하는 과정에서 이번에는 프런트 개발 담당자가 마크업 담당자에게 수정을 요청할 수도 있기 때문이다. 디자인 필터링에서 전달되는 수정 요청 이 마크업이 시각적으로 구현한 부분에 대한 요청이라면 프런트 개발 과정에서 전달되는 수정 요청은 코드 레벨에서의 요청이다. 사실 이 중에서 프로덕트 매니저가 직접적으로 관여할 수 있는 부분은 없다. 그러나 현재 제품 구현이 어느 단계를 지나고 있으며 각담 당자가 어떠한 작업을 진행하고 있는지, 어떤 상황이 발생하고 있는지는 항시 파악하고 있어야 하므로 이러한 작업의 흐름은 반드시 이해하고 있어야 한다.
- 백엔드 개발은 디자인이나 마크업 등 별도 작업 없이 기획이 완성된 시점부터 바로 착수 할 수 있다. 물론 이는 백엔드 개발자가 바로 코딩을 통한 구현을 시작할 수 있다는 의미 는 아니다. 기획서를 만들 때 문서 자체를 작성하는 일보다 그 내용을 구상하고 결정하는 것이 본질적으로 더 중요하듯이 개발 작업 또한 직접적인 코딩 외에도 머릿속으로 전체 적인 설계를 잡는 것이 매우 중요한 부분이다. 특히 백엔드 개발이 맡은 것은 제품의 밑바탕을 이루는 데이터 흐름을 구현하는 것으로, 가장 눈에 보이지 않는 부분이지만 이것 에 문제가 생기면 제품 전체가 무너질 수밖에 없다.
제품을 상점에 비유한다면 프런트 개발에서 구현하는 것은 상점 내부를 가지런하게 꾸미고 쾌적하게 유지하는 것, 상점에 들어온 손님에게 전반적인 서비스 제공, 손님이 구매하 려는 상품을 전달하고 결제를 진행하는 부분일 것이다. 이에 비해 백엔드 개발에서 구현 하는 것은 상점에서 판매할 상품의 유통 및 재고관리, 회원제로 운영되는 상점이라면 고 객 정보 관리, 손님이 구매한 상품과 결제 정보를 받아서 장부를 기록하고 정산하는 부분 이라고 볼 수 있다. 백엔드에서 한번 잡아 놓은 구조를 나중에 가서 바꿔야 한다면 이는 제품의 모든 로직과 프런트 설계에까지 영향을 미치며, 그만큼 규모가 큰 작업이다. 그것 이 사용자 입장에서는 아무런 차이를 감지할 수 없는 변경이라 할지라도 말이다. 따라서 백엔드 개발자는 실제 구현 작업에 들어가기 전, 안정적으로 장기간 유지 운영이 가능하면서도 제품 오픈 이후 변경 요구사항이 발생할 수 있음을 고려하여 가급적 유연한 구조로 백엔드를 설계하는 데에 많은 공수를 들이게 된다. 
- 회고의 목적과 형식
제품을 신규로 오픈하거나 대대적 개편 이후 담당 실무자들이 모여서 지난 과정을 돌아 보면서 의견을 나누는 것을 회고라고 한다. 회고는 프로젝트 완료를 함께 자축하기 위함 도 있지만, 가장 중요한 목적은 지금까지의 업무 진행 방식과 내용에 대해 좋았던 점과 그렇지 못했던 점을 함께 짚어보면서 앞으로도 함께할 팀 내 협업 역량을 성장시키는 것 이라고 할 수 있다. 하나의 제품 프로젝트로 모인 실무자들은 별다른 특이사항이 없으면 대개 앞으로도 계속 해당 제품을 담당하게 되기 때문에 이후 협업을 더 매끄럽고 효율적 으로 진행하기 위해서도 회고는 필수적이다.
회고는 주로 프로젝트의 PMProject manager 역할을 담당했던 프로덕트 매니저가 준비하고 진행한다(경우에 따라 개발이나 디자인 등 프로젝트에 참여한 직군별로 회고를 준비할 수도 있다. 필요하다고 판단되면 직군별 리더에게 회고 준비를 요청하자). 정해진 형식 은 없지만 기본적으로 다음과 같은 내용을 정리하여 공유하고, 이후 모두가 함께 자유로 운 형태로 후기를 나누는 방식으로 진행된다고 생각하면 된다.
- 보고의 목적과 형식
제품 오픈 또는 개편 이후, 프로젝트 PM은 해당 프로젝트를 승인한 상위 의사결정권자 에게 프로젝트 완료 직후 성과에 대한 보고를 진행한다. 보고의 목적과 성격은 회고와는 전혀 다르다. 회고는 실무자들이 모여서 서로를 위한 피드백을 주고받는 자리라면, 보고 는 의사결정권자에게 인정받기 위한 자리다.
열심히 만들고 개선한 제품은 사용자들에게 평가받을 것이고 결과는 지표로 나타날 것이다. 프로덕트 매니저는 지표를 기반으로 의사결정권자에게 오픈 또는 개편의 성과를 어필하고 해당 조직에서 그 제품이 갖는 중요도와 의미를 각인시켜야 한다.
물론 제품 자체가 너무나 훌륭하고 제품팀의 역량도 뛰어나다면, 제품은 순조롭게 성장 할 것이다. 그러나 구성원이 열심히 하기만 하면 조직의 인정과 보상이 따라오는 것은 아 니다. 어필하지 않으면 성과가 존재하지 않게 되는 경우가 비일비재하다. 그뿐만 아니라 조직에서 인정받는 제품일수록 당연히 그것을 운영, 개선, 성장시켜 나가는 데 필요한 지 원도 우선적으로 받게 된다.
따라서 상위 보고를 할 때에는 겸손은 잠시 접어 두도록 하자. 프로젝트 성과 위주로, 마 땅히 인정받아야 하는 부분을 효과적으로 전달할 수 있어야 한다. 물론 제품을 오픈 또는 개편하자마자 바로 눈부신 성과가 나타나는 경우는 극히 드물다. 지표 수치 이외에도 객 관적으로 제시할 수 있는 사용자들의 긍정적인 반응, 제품의 핵심 가치와 성장 비전, 앞 으로의 마일스톤을 정리하여 제시할 수 있어야 한다. 또한 지금은 부족해 보이는 부분일지라도 어떤 방식으로 보완해 나갈 것인지에 대한 계획과 기대 성과에 대한 예상치에 대 해서도 설득력 있는 내용을 준비해야 한다.
이러한 보고와 어필을 어떻게 해내느냐에 따라서 본인은 물론 함께 협업하는 동료들의 성과에 대한 평가도 달라질 수 있음을 염두에 두고, 본업만큼 성실하게 보고를 준비하도 록 하자. 결국 상위 의사결정권자나 조직장과의 커뮤니케이션도, 유관부서와의 커뮤니케 이션과 마찬가지로 프로덕트 매니저의 주요 역할 중 하나이기 때문이다.

- CS 대응 가이드란 접수된 고객 문의/불만에 대한 답변을 어떤 내용과 방식으로 진행할 것인지 정의한 것을 말하며, 기본적으로 갖추어야 할 구성은 다음과 같다.
* 예상 문의/불만사항 항목과 그에 대한 답변 스크립트
* 예상 항목 이외의 내용이 인입되었을 경우 대처 가이드 (ex. 고객센터 담당자가 프로덕트 매니저에게 문의내용 이관)
* 강성 항의에 대한 대응 가이드 (ex. TO DO, NOT TO DO, 모범 답변 스크립트 등)
* 고객센터에서 제품팀으로 필수 공유가 필요한 대상 정의 (ex. 서비스 오류 제보, 고객에게 피해발생 사례 등)
* 답변 처리 기간 기준 (ex. 인입 후 영업일 기준 5일 이내 답변 처리)