실리콘밸리의 프로덕트 매니저 vs. 한국의 기획자

부제 : 책 '카오스 멍키'를 읽고

 

골드만삭스의 퀀트 출신으로 애드테크 스타트업을 창업하여 1년도 채 안돼 회사는 트위터에 매각하고 정작 본인은 페이스북에 입사하여 페이스북과 트위터에서 프로덕트 매니저(Product Manager, PM)로 일했던 '안토니오 가르시아 마르티네즈'가 쓴 책 '카오스 멍키'를 읽다 보면 페이스북에서 프로덕트 매니저가 어떠한 일을 어떻게 하는지 엿볼 수 있는 내용이 구체적이다 못해 매우 자세하게 그것도 자주 나온다.
게다가 기획자 사이에서도 끊임없는 논란인 기획자가 코딩을 배우고 할 수 있어야 하는지에 대해 언급도 한다. 실리콘밸리에서도 프로덕트 매니저가 코딩을 할 줄 알아야 하는지에 대한 논란이 있나 보다.

 

그렇다고 해서 이 책을 사서 읽으라는 이야기는 아니다.
책은 인성과 인격의 수양이 부족해 자아성찰이 필요한 스펙만 번지르르한 '헛똑똑이'이자 '속물'인 저자가 실리콘밸리에서 자기도 똥이 묻은 것을 알면서 똥 묻은 남들을 싸잡아 비난하고 험담하는 찌질하다 못해, 이 새끼 이딴 글은 일기장이나 개인 블로그에나 쓸 것이지 종이 아깝게 굳이 출판할 필요까지 있었나 싶은 내용이니 말이다.

그나마 다행이라면 다행인 건 실리콘밸리와 타인의 치부뿐만 아니라 본인의 치부도 적나라하게 공개한다는 것이다.
그래서 종이 아깝지 않게 실리콘밸리의 프로덕트 매니저에 관해 언급한 내용 중 일부분을 발췌하여 옮겨본다. :)

 

__________

 

 

실리콘밸리의 프로덕트 매니저

제품관리자의 공식적인 역할은 규모에 상관없이 어느 IT기업에서나 엇비슷하지만, 현실을 들여다보면 실제 업무는 기업에 따라 상당히 다르다. 제품관리자가 하는 일은 여러 면에서 회사가 제품을 개발하는 과정을 보여준다. 일부 기업은 다른 직함을 쓰기도 한다. 마이크로소프트에서는 '프로그램관리자'라고 한다. 억만장자 투자자 피터 틸이 세운 비밀스러운 방위첩보 소프트웨어 기업 팰런티어에서는 낭만적인 느낌을 담아 '제품항해사'라고 부른다. 

직함이야 어쨌건 간에, 대체 제품관리자란 무엇을 하는 존재일까?

MBA풍으로 정의를 하자면 '제품의 CEO'(그래서 일부 국내 기업에서는 기획자를 프로덕트 오너라 부르기도 한다.)라 할 수 있다. 많은 기업이 제품관리자를 그렇게 정의하며, 비록 실제 업무보다 더 거창해 보이긴 하지만 아예 틀린 말은 아니다. 
하지만 보다 실질적인 정의는 '똥우산'에 가깝다. 

성경에 등장하는 신이 내린 재앙처럼, 설사의 폭풍우가 몰아치는 모습을 상상해보자.
스타트업에서 일하든 페이스북처럼 유명하고 복잡한 대기업에서 일하든 상황은 똑같다. 제품관리자는 똥의 폭풍 속에서 미친 듯이 키보드를 두들기고 있는 팀원들의 머리 위에 너무 커서 들기도 힘에 부치는 거대한 똥우산을 씌워주는, 엔지니어링팀의 머슴 같은 존재다.
정의에 따라, 제품관리자는 할 필요가 있는 모든 일을 한다. 직접 키보드로 코드를 타이핑하는 일만 제외된다.
사생활보호 담당 법무팀과 무수한 미팅을 하고, 제품이 발휘할 수 있는 기능을 엄선하고 편집해서 보여주고, 케케묵은 법적 틀과는 어떻게 맞아떨어질지 설명해야 한다. 또한 웃고는 있지만 머리가 텅 빈 영업직원들로 가득한 회의실에서 그들이 신제품을 사용할 고객을 유치할 수 있도록 제품에 대해 소개해야 한다. 또한 다른 제품관리자를 상대로 권모술수를 써서 그들이 개발 중인 제품을 변경하거나 엔지니어링에 배분된 자원을 조금 내부도록 구워삶아야 한다. 고위 경영진 등 고위급과의 미팅에 참석해서 제품을 홍보하고, 빠른 속도로 떨어지는 테트리스 조각을 맞추듯 제품을 홍보하고 제품을 그들 세상의 청사진에 끼워 넣어야 한다. 다른 제품관리자가 다가와 우리 팀원을 약탈해가려 들거나, 우리 제품 계획안에서 그들의 제품과 비교되는 몇몇 요소를 문제 삼고 우선순위에서 밀어내려 할 때는 목소리를 높여 팀을 방어해야 한다.

뛰어는 제품관리자는 내가 구성한 제품을 만들어내도록 엔지니어를 설득할 수 있어야 한다. 하지만 그렇게 하지 못한다면 자신의 군대에 대한 통제력을 잃어버린 독재자 꼴이 된다. UN이나 종교단체가 내 편을 드는가는 중요치 않다. 곧 미친 듯이 총을 쏴대는 사람들 앞에 서게 될 테니까. 페이스북 광고부에서 가장 애잔한 사람은 엔지니어의 신뢰를 잃은 제품관리자였다. 자신의 지위가 주는 허세를 누리며 이메일과 로드맵을 사방에 보내도, 아무런 결과물도 내지 못했던 것이다. 

제품관리자는 실제로는 몸을 낮춰야 하는 비굴한 일이었다.
하지만 겉보기에는 달랐다.
페이스북의 제품관리자는 겉보기엔 마치 아프가니스탄의 군벌이나 해적 선장과 같았다.

 

----- 중략 -----

 

제품관리자를 꿈꾸는 이들에게 전하고픈 교훈이 있다.
여러분이 기술적 사항을 알아야 하는 원칙적인 이유는 엔지니어가 개발 중인 시스템을 고안하는 것을 기술적으로 돕기 위해서가 아니다. 만일 그런 작업을 하고 있다면 제품관리자로서의 업무를 제대로 하지 못하고 있다는 뜻이다. 기술적 사항에 대해 알아야 하는 진짜 이유는 엔지니어가 거짓말을 할 때 진위를 가려내기 위해서다. 그런 일은 꽤 잦다. 때때로 오해, 잘못된 기억, 혹은 개인적인 소망(모든 사람들이 그렇듯 엔지니어도 생각하고 싶은 대로 생각한다.) 등이 원인이 되어 우발적으로 사고가 일어난다. 그런가 하면 때로는 좀 더 동의하지 않아서 수동-공격적인 이유로 거짓말을 하거나("그렇게 했다간 서버를 몽땅 잡아먹을걸요!"), 게으름 때문에 그냥 둘러대는 것이다("그걸 만드는 건 불가능해요!"). 제품관리자는 제품을 죽여버리는 그런 말의 진위를 가려내기 위해 존재한다.

 

__________

 

실리콘밸리의 프로덕트 매니저도 한국의 기획자와 하는 일은 별반 다르지 않은 것 같다. 

다만 우리보다 그나마 형편이 나을 뿐.


한국의 기획자

그럼 이제 한국의 기획자인 나의 이야기를 해볼까?

언제나 그렇듯 프로젝트 일정이 빡빡하다 보니 개발과 테스트가 동시에 진행된다.
테스트를 진행하는데 구현된 기능이 기획서의 내용과 다르다.
담당 개발자에게 개발된 기능이 기획서의 내용과 달라 수정을 요청했다. 기획서에 빽빽하게 적어놓은 기능 정의 명세(Description)를 읽지 않고 레이아웃(Layout 또는 Wireframe)만 보고 개발한 것이 분명했다. 실제 개발된 기능으로는 운영자들이 사용하는데 너무 불편하여 수정을 요청했는데 개발자가 짜증을 내며 타 개발자에게도 영향을 미치는 데다 복잡도가 높아 한달이 걸릴지도 모른다는 것이다.
아무리 직접 코딩을 못하는 기획자라지만 13년 차의 경험칙상 하루면 될 작업량인데 한달이라니...

이 페이지는 3단 그리드지만, 기획서엔 최대 4단 그리드도 있었다. 이 기획서를 보는 퍼블리셔, 개발자라면 분명 망할 기획자 같으니라고 욕하고 싶겠지만 내부 관리자와 체인점/매장 관리자 및 역할과 직급 등 복잡한 권한 분기에 따라 1/2/3단이 숨겨지고 태블릿에서 POS처럼 사용해야 하는 상황이다 보니 동료들에게 미안하지만 이런 공포스런 UI가 나왔다.

 

위와 같이 1/2단은 상하위 목록 리스트, 3단은 컨텐츠인 레이아웃에서 1/2단에서 페이지 이동 후 3단의 컨텐츠의 상태를 업데이트했을 때 1/2단에서 업데이트된 콘텐츠가 포함된 페이지로 이동하여 해당 업데이트된 콘텐츠에 포커스-인된 상태로 이동시키는 것이 복잡하다는 건 이해하겠지만 그렇다고 해서 한달이 걸릴 작업이 아니라는 건 서당개도 알 수 있을 것이다. 하지만 해당 페이지로 이동이 되지 않는다면 1/2단에서 여러 페이지를 이동했는데 운영자가 그 페이지를 기억하지 못했을 때 발생할 끔찍함을 생각해보라. 업데이트된 콘텐츠를 확인하려고 몇 번의 클릭질을 해야 할까?

그래서 내 자리로 돌아오자마자 마우스를 던지며 개발자가 있는 방향에 고함을 질렀다.
몇 시간 후에 기획서대로 기능은 변경되었고 나는 그 개발자에게 사과를 했다. 다만, 그 개발자는 선임 개발자들을 비롯하여 동료 개발자들로부터 비난을 들어야만 했다.
이렇듯 기획자는 해당 프로젝트에 참여하는 수많은 동료들과 협의하고 설득하고 때론 다투더라도 프로젝트를 어떻게든 목적지까지 끌고 나가야 한다.

 

 

디자이너가 기획서를 보고 디자인한 시안을 확인하는데 UX적으로 사용자에게 불편함을 줄 가능성이 큰 데다 안드로이드의 특성상 다양한 해상도, 즉 스크롤이 생길 상황을 고려하여 디자인이 되지 않아 수정을 요청했다.
그런데 디자이너가 이런저런 이유로 수정이 어렵다고 하는데 아무리 들어도 논리적인 이유는 없고 디자인적, 즉 심미적인 개인적 취향 때문에 변경하기 싫다는 이야기로 들린다.
한참을 논쟁하다 그 디자이너는 기획자가 가장 듣기 싫어하는 말 한마디로 못을 박았다.

 

절대 안 되요!

 

세상엔 시간과 비용만 해결된다면 절대 안 되는 개발과 디자인은 없다.
정중하게 이야기를 했다. 절대 안 된다는 이야기는 나랑 싸우자는 이야기로 밖에 들리지 않는다고.
그러면서 나 또한 해당 페이지의 와이어프레임을 논란의 여지가 없게 모두 바꾸겠다고 으름장을 놓으며 결국 수정을 했다. 

물론 이전에 그 디자이너와 디자인 시안을 놓고 논쟁을 벌이다 결국 협의가 이루어지지 않아 디자이너의 의견대로 진행하며 받아두었던 '양보티켓' 한장을 써야 했다. 조금만 더 설득을 했다면 주변의 관심을 끌며 나를 지지할 동료들로 인해 수정을 할 수 밖에 없는 사안이라 굳이 양보티켓을 쓰지 않았어도 됐는데 티켓을 쓰고 돌아오는 길에 많은 아쉬움이 남았다. 전투엔 이겼는데 전쟁에서 진 기분이랄까...

합리적이고 논리적으로 설득이 어려운 부분, 즉 개취의 영역이면서 동시에 A/B 테스트나 검증이 불가능한 상황에서 논란이 발생할 때에는 서로의 기분을 상하지 않으면서 협의한답시고 서로의 시간을 잡아먹는 것보단 이런 제도와 시스템을 도입하는 것을 추천한다.

 

예컨데 카뱅에서 우측 하단에 위치한 이체를 위한 양방향 화살표 버튼이 투명이라면?!?!

 

레이어드 레이아웃(Layered layout)에서 페이지 위에 좌우 위치값을 기준으로 위치값을 고정하여 투명도를 준 버튼을 띄운다고 생각해보라. 해상도에 따라 버튼은 상하좌우로 움직일테고 버튼이 컨텐츠 위에 겹쳐질 땐 버튼 이미지와 텍스트가 겹쳐 보일텐데 수정하지 않겠다고?


초급 기획자일 때(아니다! 최근까지도...)는 사실 기획자로서 경영진과 프로젝트 동료들 사이에서, 개발자와 디자이너를 비롯한 여러 직군들 사이에서 정치질을 했다. 그게 프로젝트를 원활히 진행시키기 위해서였던, 내가 기획자로서 일을 편하게 하려고 했건 이유를 불문하고 정치질을 했다.
그런데 요새 들어 정치질이 조금씩 줄어들고 필요 없어지면서 내가 왜 정치질을 했는지 정확히 이해할 수 있었다.
수많은 동료들에게 합리적이고 논리적으로 설득할 역량이 부족해서였다. 이제서야 뒤늦게 인정을 한다.
기획자는 경영진과 비즈니스를 이야기하고, 개발자와 개발을, 디자이너와 디자인을, 마케터와 마케팅을 놓고 논의하고 협의하고 때론 설득을 해야 한다. 각 분야의 전문가들과 그들의 전문분야를 놓고 협의를 하고 설득을 해야 한다는 이야기다. 
웃기지 않나? 코딩은 할 줄 모르는데 개발자와 개발을 이야기하고, 디자인을 할 줄 모르는데 디자이너와 디자인을 이야기해야 한다는 사실이.
그런데 그게 가능하다.
빈도수를 놓고 보면 기획자가 개발자와 디자이너를 설득하는 비율이 압도적으로 높다.
어떻게 가능하냐고?
예를 들어 기획자는 개발자와 개발을 놓고 이야기하지만 그 기능은 사용자가 사용해야 하니 사용자의 의견이 반영되어야 하고, 경영진이 생각하는 전략과 일정, 비용을 반영해야 하며, UI/UX/디자인을 고려해야 하고, 관련 법규를 고려해야 하고, 비즈니스 모델과 파트너, 협력사를 고려해야 하고 운영자를 고려해야 하다 보니 개발자가 미처 생각하지 못한 또는 생각할 수 없었던 다차원적인 시각에서 여러 이유를 가지고 직접 코딩은 못하지만 기술에 대한 이해를 바탕으로 충분히 설득이 가능하다.
설득이 안 된다면 이유는 딱 3가지다.
당신이 정말 바보 같은 이야기를 했거나, 합리적이고 논리적인 이유를 근거로 설득할 능력과 지식이 부족했거나, 상대방이 합리적이고 논리적인 근거를 이해할 능력과 지식이 부족한 경우이다.
때문에 기획자는 각 직군과 대화하며 협의하고 설득하기 위해서라도 그들의 언어에 익숙해져야 하고 기획은 물론이거니와 비즈니스, 해당 도메인, 개발, 디자인, 마케팅, 광고, 데이터분석, 관련 법규, 시장, 사용자 등 다양한 분야에 관심을 가지고 있어야 한다. 그래서 신입기획자들에게 그렇게 IT기사를 읽고, 책을 읽고, 다양한 컨텐츠를 소비하고, 선배들의 기획서를 많이 접하고 보라고 잔소리를 하는 것이다.

잡부와 통섭의 예술가 그 사이에서...

기획자는 한 방향, 한 시선, 한 시각만으로 사물과 현상을 바라보고 판단하면 안 된다.
그래서 기획을 통섭의 예술이라고 표현한다.
과학과 인문학, 기획과 개발 또는 디자인, 비즈니스와 기술을 잇는 통섭의 영역이 기획인 것이다.
그래서 문과대 출신의 기획자들이 많은 것이고 또 어려운 이유다.
어느 하나만 잘해서는 뛰어난 기획자가 될 수 없기 때문이다.

 

뛰어난 기획자가 되기 위한 마스터키이자 자질은 지적 호기심과 이를 통해 쌓은 다양한 정보와 지식을 통섭과 융합하는 능력이 아닐까?

 

기획자는
때론 사용자의 눈으로 사물을 바라보며 사용자를 대변해야 하고
때론 개발자와 디자이너, 경영진과 사용자, 광고팀과 운영팀 사이에서 합리적이고 논리적인 판단을 해야 하며
때론 리서처가 되어 시장을 조사하고 분석해야 하며
때론 기획자, 설계자, 디자이너가 되어 와이어프레임을 그려야 하고
때론 사업가가 되어 비즈니스 모델을 설계해야 하며
때론 법률가가 되어 법규를 살펴보고 정책을 결정해야 하며
때론 사용자와 개발자, 디자이너의 입장에서 의사를 결정하고 커뮤니케이션을 하며 협의를 진행해야 하며
때론 카피라이터가 되어 사용자가 이해하기 쉽고 읽기 쉬운 문장과 문구를 작성해야 하며
때론 선생님이 되어 내가 기획한 내용을 설명하고 이해시켜야 하며
때론 문서를 작성하고 또 작성하고 또 작성하고 또 작성하며 내가 인간인지 타자기인지 헷갈려야 하며
때론 기획서를 작성할 수 없는 마케터와 운영자, 고객지원부서를 대신하여 기획서를 작성하기도 하며
때론 니 머리속에서 나온거니 니가 가장 잘 알지 않냐며 테스트도 해야하고 
때론 우리 회사엔 그로스해커나 데이터분석가가 없으니 툴이라도 써서 데이터 분석이란 걸 좀 해보란 이야기를 들어야 하며 
때론 이게 어느 파트의 업무인지 구분이 모호해 아무도 신경을 쓰지 않아 프로덕트의 오너로서 처리해야 하는 등 정말 말 그대로 코딩과 디자인을 제외한 모든 업무를 도맡아 해야 한다.

그럼에도 불구하고 기획자는 참 마력 있는 직업임에는 틀림없다.
'안토니오 가르시아 마르티네즈'가 이야기한 것처럼 똥우산을 씌워주는 머슴 같은 존재라 할지라도 말이다.

 

 

세균무기가 알려주는 서비스 기획의 모든 것 | 세균무기 - 교보문고