소프트웨어 엔지니어와 일한다는 것
"프로덕트 매니저란 무슨 일을 하는 것일까"
현재 필자는 아마존에서 시니어 프로덕트 매니저로 근무 중이다. 이전 프로덕트 매니저의 업무와 관련하여 설명한 적 있는데, 그 후 연락을 주셨던 분들과 대화를 하다 보니 조금 더 구체적인 설명을 드리는 것도 좋을 것 같다고 생각이 들었다. 그리하여 앞으로 몇 편정도는 프로덕트 매니저는 어떠한 업무를 하고 어떤 분들과 근무하는지에 초점을 맞추어 대화를 풀어나가려고 한다.
필자 역시 입사 전까지 PM들이 어떤 업무를 하는지 잘 몰랐다. 그저 인터넷 기사를 읽다 보면 뭔가 멋있어 보이기도 했고 새로운 제품을 만들고 담당하는 업무를 할 것이라는 대략적인 이해만 있었을 뿐. 그렇게 입사하게 되었고, 긴 시간은 아니지만 업무를 해나가며 이제야 PM이 어떠한 업무를 하는지 조금이나마 이해할 수 있게 되었다. 그리하여 오늘은 과거의 필자와 비슷한 상황에서 커리어 고민을 하는 학생들에게 간접적으로나마 필자의 경험을 공유하려고 한다. 이 글이 아주 작게라도 그들의 커리어 결정에 도움이 된다면 더할 나위 없이 좋을 것 같다.
*필자의 경험을 바탕으로 개인적인 생각을 이야기를 할 예정으로 타 PM과 차이가 있음을 알려드립니다.
몇 년 전부터 코딩의 중요성에 대한 기사들을 쉽게 접할 수 있게 되었다. 국내 초등학교에서 코딩 교육을 의무화한다는 기사도 읽은 적이 있고, 직장인들 역시 미래를 대비하여 퇴근 후 코딩을 배우러 학원을 다닌다는 뉴스를 본 적도 있다. 4차 산업혁명 시대라는 단어와 함께 따라오는 인공지능, 사물인터넷, 클라우드 등 새로운 기술을 이해하기 위해서는 컴퓨터 언어를 알아야 하고 미래 코딩을 하지 못한다면 일자리에 위협을 받을 수 있다는 극단적인 소견들도 간혹 보이기도 했다. 그리하여 컴퓨터 공학 관련 전공 역시 큰 인기를 얻고 있는데, 아무래도 이러한 열풍은 한동안 식을 것 같지 않다. 그렇다면 우리들이 흔히 말하는 미래의 일꾼 소프트웨어 엔지니어들과 일한다는 것은 어떤 것일까?
입사한 지 얼마 되지 않아 첫 교육으로 런던 오피스를 다녀온 적 있다. MBA 프로그램을 통해서 입사한 직원들에게 아마존이라는 회사 전반적인 소개와 함께 업무 관련 팁을 알려주는 교육이었는데, 개인적으로 "소프트웨어 엔지니어와 일하는 방법"이라는 세션이 가장 기억이 남는다. 소프트웨어 엔지니어. 말 그대로 코딩을 하는 친구들로서 지금 아마존의 모든 소프트웨어 시스템을 구축한 빛과 소금과 같은 존재다. 기존 하드웨어를 만드는 회사에서 소프트웨어 회사로 (물론 아마존 역시 하드웨어 제품들을 만들고 있기도 하지만) 이직한 필자에게 소프트웨어 엔지니어들이란 꽤나 멀게만 느껴졌던 존재들이었다. 교육에서는 어떻게 그들과 일을 해야 최대 효율을 얻을 수 있는지, 어떤 방식으로 서로의 의견을 주고받아야 추후 소통으로 인한 문제가 발생하지 않을지 등 꽤나 당연하지만 중요한 내용들을 설명해줬다. 이 세션이 특히 흥미로웠던 이유는 회사 차원에서도 PM-테크팀과의 협업에 얼마나 관심이 많은지를 보여줬다는 것이다. 다 큰 어른들이 일하는데 이런 것까지 알려준다니?라는 생각이 들만큼 때로는 당연하지만 꼭 알아둬야 하는 내용들을 알려줬는데, 다른 한편으로는 이 일이 회사에게 얼마나 중요한지 보여주는 좋은 예라고도 생각한다.
PM은 크게 세 가지 업무를 포괄적으로 이해하고 이끌어 나가야 한다. 먼저 시장을 이해하여 고객의 니즈에 맞는 제품을 만들거나, 기존 제품을 시장 흐름에 맞추어 끊임없이 개선하고 발전시켜 제품의 성공을 이뤄내야 한다. 이렇게 하기 위해서는 세일즈 팀이나 마케팅 팀과 협업해야 하고, 실제 고객들과 만나 그들을 이해하고 그들에게 맞는 비전을 세워야 한다. 두 번째로는 고객의 니즈를 파악하여 제품을 만들거나 개선할 때 최고의 고객 경험을 제공하기 위해서 UX 디자이너와 협업해야 한다. 아무리 좋은 의도를 갖고 만들어진 제품이라도 사용하기가 어렵다면 시장에서 외면받을 수 있다. 예를 들어 필자에게는 세 종류의 무선 헤드폰이 있다. 운동할 때 사용할 수 있는 제품이 있는가 하면 노이즈 캔슬링이 가능하여 비행기에서나 청소기를 돌릴 때 외부 소음을 들을 수 없는 신박한 제품도 있다. 하지만 현재 음악을 듣거나 운동을 할 때 자연스럽게 에어팟에 손이 간다. 제품 자체가 가볍기도 하지만 핸드폰으로 음악을 듣다가 에어팟을 귀에 꼽으면 바로 연결된다는 그 편리함에 어떠한 음향기기보다 만족하며 사용하고 있다 (광고 아니다). 정말 별 것 아닌 것 같지만 애플은 그 누구보다 고객의 입장에서 제품을 디자인했고 훌륭한 고객 경험을 선사했다고 생각한다. 마지막으로는 오늘의 주제인 테크팀과 근무하는 것이다. 고객을 이해하고 훌륭한 UX 디자인을 해도 제품을 만들지 못한다면 말짱 도루묵이다. 이 모든 상상들을 현실화해주는 사람들, 소프트웨어 엔지니어들과 근무하는 것 역시 PM의 가장 중요한 업무 중 하나이다.
쉽게 설명하기 위해서 필자의 프로젝트가 한 도시에서 다른 도시로 이동할 수 있는 다리를 만드는 것이라고 가정해보자. 그렇다면 필자의 역할은 가장 먼저 어떤 도시의 사람들을 어떤 도시로 이동시킬 것인지 고민을 해볼 것이고, 다리를 건설한다면 정확히 어느 위치에 지을 것인지 우선 고민할 것이다. 해당 도시에서 살고 있는 사람들의 분포도에 대해서 공부를 할 수도 있고, 그 도시를 찾아가 살고 있는 사람들의 의견을 직접 들을 수도 있다. 그 후 어느 위치에 다리를 건설할 것이라는 비전이 확실하게 확립된다면 다음으로는 UX 디자이너와 함께 어떤 다리를 지을 것인지 고민할 것이다. 한강 잠수교와 같이 아래에는 사람들이 조금 더 편하게 다닐 수 있는 다리를 만들 것인지, 아니면 자동차와 기차만 다닐 수 있는 길을 만들 것인지를 고민할 수 있고, 영국의 타워브릿지처럼 아름다운 다리를 지을 것인지 아니면 외형과 상관없는 실용적인 다리를 건설할 것인지도 생각을 해봐야 한다. 그렇게 타깃 고객들에게 가장 잘 맞는 다리를 디자인했다면 그 다리를 건설하는 사람들과 일을 시작한다. 원하는 디자인에 대한 설명을 충분히 하여 건설하는 사람들이 놓치는 것이 없는지 끊임없이 살펴봐야 할 것이고, 디자인을 하던 과정 중 놓쳤던 부분이 있을 수도 있으니 꼼꼼하게 살피며 같이 완공해야 한다. 그렇게 다리가 완성되면 시민들이 실제로 다리의 존재를 알 수 있도록 광고할 필요도 있다. 왜 이 다리를 이용해야 하는지 뉴스 광고를 할 수도 있고, 실제 시민들을 만나 설득할 수도 있는 것이다. 보통 해당 업무를 마케팅 팀과 세일즈 팀들과 함께 진행하는데, 완성된 제품을 고객들이 사용하게 권유하는 꼭 필요한 업무들이다. 생각해보면 PM에게 어느 한 분야에 대한 전문성을 요구하지 않는다. 다만 비즈니스, 고객 경험 (UX), 기술 (Tech)를 포괄적으로 이해하고 고객 니즈를 현실화할 수 있도록 비전을 제시하는 사람이라고 보면 될 것 같다.
필자는 꽤나 운이 좋은 케이스라고 생각한다. 많은 PM들이 테크팀들과 함께 근무하게 되지만 실제로 본인 팀에 소속된 테크팀과 일하는 경우는 그렇게 흔하지 않다. 필자네 제품이 유럽 내 꽤나 중요한 역할을 하게 되었고, 이를 잘 알고 있는 회사에서도 적극적으로 미뤄주고 있다. 덕분에 필자만을 위한 테크팀과 함께 프로젝트를 진행 중인데, 이들로 하여금 필자가 그려놓은 제품을 현실화할 수 있게 되었다. 물론 다른 테크 팀과 협업하여 프로젝트를 진행하는 경우도 있었지만, 아무래도 본인을 위한 테크팀이 있을 경우 머릿속에 그려놓은 그림들을 조금 더 자유롭게 현실화할 수 있다는 장점이 있다.
우선 PM이라면 본인의 비전을 조금 더 효율적으로 실천하기 위해서 기술적인 이해를 갖춰야 한다. PM이 직접 코딩하는 경우는 많지 않지만 (스타트업이나 조금 더 기술적인 회사에서는 실제로 PM이 코딩하는 경우도 꽤나 있다고 한다) 기술적 디테일에 약한 PM이라면 본인이 상상했던 제품과 꽤나 다른 결과물을 맞이하는 리스크가 존재한다. 그러므로 얇더라도 기술적인 질문을 이해할 수 있는 수준이 되기 위해 끊임없이 공부를 해야 하는 위치라고 생각한다. 필자는 첫 엔지니어와의 미팅을 잊지 못한다. 그 회의의 목적은 타국가의 세법을 이해시키고 기존 제품에 어떠한 개선을 해야 하는지 토론하는 자리였다. 그런데 세법을 설명한 다음 바로 문제가 발생했다. 그가 A라는 시스템을 변경해야 할 것 같다며 필자의 의견을 물어봤는데, 당시 필자는 해당 시스템에 대한 이해가 하나도 없었다. 방향을 제시해야 하는 입장에서 되려 단어 하나하나 물어보며 회의를 마쳤던 기억이 있다. 한동안 그 엔지니어의 신뢰를 얻지 못했는데 아마도 그에게 필자는 제품을 모르는 PM으로 기억되지 않았을까 싶다. 그 후 시간이 흐르며 자연스럽게 제품에 대한 이해를 했고 그들이 사용하는 언어들을 같이 사용하며 조금 더 자연스럽게 회의를 진행할 수 있게 되었다 (물론 아직도 모르는 용어들이 많은 것은 함정이다).
PM은 좋은 설계도를 작성하는데서 시작한다. 우리는 신규 제품을 개발하거나 기존 제품을 개선할 때 변경할 내용들을 서류에 작성한다. 그 후 엔지니어들과 서류를 읽으며 "왜 그리고 어떤 시스템을 변경해야 하는지" 설명하는데, 좋은 PM의 글은 명확하고 MECE (Mutually Exclusive Collectively Exhaustive의 약자로 상호 배제와 전체 포괄 - 즉 빈틈이 없다는 뜻) 하다. 이 글을 쓰는데 필자 역시 수많은 수행 착오를 했고 (매니저는 스파르타 스타일이어서 본인이 마음에 드는 글이 완성될 때까지 재작성을 요구했다) 아직 부족하지만 조금이나마 익숙해진 것 같다. 해당 서류를 작성하는데 가장 중요한 것은 고객의 입장에서 구체적인 경험을 글로 작성할 줄 알아야 하고, 고객이 경험할 수 있는 수많은 경우들을 고려하여 글을 작성해야 한다는 것이다. 아마존의 미션은 세상에서 가장 고객 중심적인 회사가 되는 것이다. 그러므로 그 회사의 제품 담당자라면 누구보다 고객에게 집착하고 그들의 입장에 서서 제품을 바라봐야 한다.
그 후 제품 개발이 시작되면 PM의 역할에는 약간의 변화가 생긴다. PM은 제품 담당자 (Product manager)이지만 상황에 따라서 프로그램 담당자 (Program manager) 혹은 프로젝트 담당자 (Project manager)의 역할도 도맡아 해야 한다. 이는 부서 내 해당 역할을 하는 사람이 있는지에 대한 여부와 담당하는 제품에 따라서 달라질 수 있다. 필자 같은 경우 새로운 프로젝트를 진행했을 때 수많은 기존 시스템에 변화를 줘야 했다. 그리하여 테크 팀을 여러 단위로 나뉘어 다른 업무들을 수행하도록 부탁했는데, 진행 상황들을 주기적으로 확인하여 프로젝트가 한 방향으로 흘러갈 수 있도록 가이드 역할도 했었다. 그 외에도 제품을 만드는 엔지니어들 곁에서 그들의 일정을 챙기기도 했고, 코딩을 하던 중 시스템 적인 문제가 발생했을 때 두 팔을 걷어붙여 어설프지만 도움을 주기 위해서 노력했다.
제품을 론칭했다고 하여 테크팀과의 관계가 끝나는 것이 아니다. 제품을 운영하며 보수 및 유지하는 것을 신경 써야 하는데 그보다 먼저 그들의 노고를 인정해줘야 한다. 테크팀들과 같이 근무를 하다 보면 그들이 얼마나 바쁘고 어려운 문제들을 맞이한다는 것을 자주 접한다. 복잡한 문제의 답을 찾기 위해 머리를 쥐어짜야 하기에 공대생이지만 코딩을 너무나도 싫어했던 필자에게 그들은 마치 슈퍼맨처럼 보이기도 하다. 모든 프로젝트가 완료되면 테크팀의 공로를 인정해주는 것 역시 PM의 중요한 역할이라고 생각한다. 작년 말, 마케팅 팀과 모 사이트에 링크를 올리는 것에 대하여 상의한 적이 있었다. 얼마나 효과적일지 모르겠지만 엔지니어에게 내년 시간이 날 때 링크를 추가해달라고 설명을 해줬고, 그가 필요한 서류들을 작성하여 전달했다. 그런데 그는 짬짬이 해당 업무를 진행해왔고 마치 크리스마스 선물처럼 완성시켜줬다. 그의 발 빠른 행동력에 꽤나 감동했는데, 추후 확인해보니 그가 만든 링크는 다음 해 수많은 고객들을 유치한 가성비 최고의 링크가 되었다. 이에 필자는 분기별 트래픽과 함께 그와 그의 매니저를 포함하여 감사 메일을 보낸 적이 있다.
바쁜 와중에 신경을 써서 해줬던 업무가 이러한 성과를 내었다.
아마존의 리더십 원칙 중 멋진 Bias for action을 보여준 것 같다. 고맙다
그러자 그의 매니저는 매니저의 매니저까지 포함하여 그의 행동을 칭찬해줬고, 상사들이 그를 칭찬해주자 그 역시 나에게 고맙다며 이러한 업무가 있다면 언제든 알려달라고 했다. 물론 아마존 특성상 서로 잘한 것이 있다면 칭찬해주는 문화가 있었기에 가능하기도 했지만 이와 같이 칭찬을 하고 인정해주는 것 역시 PM의 중요한 역할이라고 생각한다.
엔지니어와 같이 일하다 보면 물론 어려운 부분도 있다. 대부분 화상전화로 회의를 진행하다 보니 소통의 어려움은 항상 존재한다. 그러므로 필자의 경우 시간이 날 때마다 연락하여 몇 번이고 필자의 생각을 공유하여 서로 얼라인 (align) 하려 한다. 소통의 경우 협업하는 기회가 잦아지면 쿵짝이 잘 맞는 사이로 발전함으로, 시간이 어느 정도 해결해준다고 믿는다. 그렇지만 그들의 언어를 이해하고 동일한 온도로 말을 건넬 줄 아는 센스가 더 좋은 PM을 만든다고 믿는다.
개인적으로는 같이 근무한 엔지니어들은 대부분 미국 혹은 인도에서 근무하고 있었다. 그들은 매우 똑똑하고 업무도 잘하는데, 때론 "왜 한국에는 테크팀을 구축하지 않을까"라는 생각을 했다. 한국의 엔지니어들 역시 그들과 견주어 부족하지 않는 실력을 가지고 있고, 높은 주인의식과 미적인 센스까지 겸비하고 있어 훌륭한 인재들로 인정받을 텐데 말이다. 최근 동료들과 비슷한 대화를 나눠본 적이 있는데 아무래도 언어라는 장벽이 가장 큰 걸림돌이 아닐까 라는 생각을 한다. 엔지니어들이라면 전 세계에 있는 직원들과 소통하여 제품을 만들어 나가야 한다. 그렇기에 영어에 특화된 인도 친구들이 많은 사랑을 받고 있는 것 같다. 코딩이 미래일 수도 있다. 하지만 뛰어난 인재들이 더 넓은 시장에서 인정받기 위해서 언어에도 그만한 관심을 준다면 얼마나 좋을까 라는 생각을 해본다. 어느 기업에서 먼저 시도해보고 그들의 능력을 인정하는 순간, 더 많은 기업들이 국내 엔지니어들과 일하고 싶어 하지 않을까 라는 생각을 하면서 말이다.
