SAPㅣ개발자 출신이 말하는 프로덕트 매니저의 역량

김영욱 SAP 시니어 프로그램 매니저

SAPㅣ개발자 출신이 말하는 프로덕트 매니저의 역량

일자

상시

유형

아티클

태그

이 아티클은 <PM/PO를 말하다> 시리즈의 1화입니다.

✍ 오늘의 아티클

김영욱 매니저는 PM을 '프로덕트를 통해 세상에 임팩트를 만드는 과정의 중심에 서 있는 사람'이라고 생각했습니다. 그들의 인사이트가 사용자와 프로덕트에 생명을 부여한다고 느꼈으니까요.
고객의 목소리를 듣는 것은 중요합니다. 그동안 쌓아온 기본적인 프로세스가 있기 때문에 그 방식대로 디자인하기 쉬운데, 고객들의 니즈는 늘 변하기 때문이죠. 고객의 목소리를 듣지 않으면 제대로 된 제품을 만들 수가 없어요.
SAP에서는 ‘좋은 UX는 절대로 드러나지 않는다’라고 말합니다. 비즈니스 디자인은 사용자 디자인처럼 화려하고 ‘와우’하는 시간이 필요한 것이 아니라 거부감 없이 사용하면서 매뉴얼을 보지 않고도 결과물을 취득할 수 있도록 이루어져야 한다고요.

프로덕트를 책임지는 PM 중에는 다양한 백그라운드를 가진 사람이 많다. 데이터 분석가나 프로덕트 디자이너, 개발자가 대표적이고 그 외에도 비즈니스 분석가나 마케터, IT세일즈 등 다양한 직무를 경험한 이들을 쉽게 만나볼 수 있다. 이는 제품의 가장 가까이에서 깊숙이 관여하는 프로덕트 매니저라는 일이 어느 날 갑자기 하얀 백지에서 만들어지기보다 늘 제품의 어느 언저리에서 제 몫을 하던 사람에게 맡겨지는 것이 자연스럽기 때문이다.

김영욱 SAP 시니어 PM은 개발자로 15년을 일한 뒤 PM으로 전환한 케이스다. 그는 개발자로의 시간이 있었기에 현재 PM의 역할을 해내고 있다고 말한다. 개발자로 커리어를 그대로 이어갔을 법도 한 그가 커리어를 전환하고 ‘오히려 좋아’를 외치는 이유는 무엇일까.

김영욱

SAP 시니어 프로그램 매니저

전) 비즈니스 오브젝트 Development Architect
전) 후지쯔 코리아 Software Dev Chief

영욱 님이 하시는 업무에 대한 소개 부탁드립니다.

현재 SAP 프로덕트 엔지니어링의 Cloud ERP 그룹에서 UX를 총괄하는 부서의 시니어 프로덕트 매니저로 일하고 있어요. SAP는 글로벌 전체 직원이 11만 정도이고 프로덕트 엔지니어링에는 5만 명이 근무해요. 그중 2만 명이 Cloud ERP에서 일하고요. 저는 SAP 클라우드 솔루션의 표준 디자인 시스템과 UX 컴포넌트 개발을 지원하는 역할을 하고 있어요.

굉장히 큰 규모의 조직인 거 같아요. 현재 소속되어 있는 팀 이야기를 좀 더 자세히 해주실 수 있나요?

글로벌 테크 기업은 여러 나라에 오피스가 존재하는데, 소위 지사라고 말하는 로컬 오피스는 세일즈나 마케팅 위주의 일을 해요. 본사에서 만들어진 제품을 로컬에서 세일즈하는 것에 집중하는 역할이에요. 로컬에 있는 엔지니어들은 고객사에 가서 데모를 하거나 제품을 세팅해 주는 역할을 주로 해요.

저는 본사 프로젝트 엔지니어링 그룹에서 일하고 있는데 저희 조직은 전 세계 각각에 퍼져 있어요. 리포트 라인이 어디에 있을지는 모르지만, 어디에서 일하는지와 상관없이 함께 일하고 있어요.

영욱 님이 소속된 SAP의 UX 총괄 부서는 어떤 역할을 하나요?

SAP에는 인사, 구매, 세일즈, 조달 등 다양한 제품과 서비스가 존재하는데 그동안 각 서비스마다 조금씩 다른 UX를 사용해 왔어요. 각 제품 도메인의 특징에 따라 디자인되었지만 고객 입장에서는 SAP 안에서 각기 다른 UX를 경험해야 하니 혼란스러워했죠. 그래서 디자인 표준 작업이 필요해졌어요. 각 도메인에 공통된 UX가 적용되도록 하나의 SAP를 브랜딩하고 고객들의 사용성을 높이고 있어요. UX 총괄 부서에서는 직접 디자인을 하기보다는 각 엔지니어 그룹에서 어떻게 디자인해야 하는지 표준을 만들고 이 같은 표준이 잘 지켜질 수 있도록 교육과 가이드 역할을 합니다. 약 5천 명이 근무하고 있고 저는 부서가 출범했던 4년 전부터 여기에서 일하고 있어요.

UX 총괄 부서가 생긴 지 4년 정도 됐다면 고객들도 변화를 느낄 만할 거 같은데, 어떤가요?

실제로 긍정적인 피드백을 많이 받고 있어요. SAP에서는 ‘좋은 UX는 절대로 드러나지 않는다’라고 말해요. 사용자가 어떤 한 지점에서 멈춤없이 물 흐르듯 자연스럽게 사용할 수 있어야 한다고 보는 거죠. 비즈니스 디자인은 사용자 디자인처럼 화려하고 ‘와우’하는 시간이 필요한 것이 아니라 거부감 없이 사용하면서 매뉴얼을 보지 않고도 결과물을 취득할 수 있도록 이루어져야 해요. UX 총괄 부서에서는 이러한 기준을 계속 만들고 적립해나가고 있어요.

제품에 대해서는 사람마다 생각하는 게 다를 수 있잖아요. 이럴 때는 어떠한 방식으로 의견을 모으나요?

무엇보다 고객의 목소리를 듣는 것이 중요해요. 그동안 쌓아온 기본적인 프로세스가 있기 때문에 그 방식대로 디자인하기 쉬운데, 고객들의 니즈는 늘 변하고 있어요. 그래서 고객의 목소리를 듣지 않으면 제대로 된 제품을 만들 수가 없어요.

고객들은 처음에는 ‘이런 게 있었으면 좋을 거 같아요’ 정도의 의견을 주세요. 그럼 이게 과연 한 사람만의 이야기인지, 같은 인더스트리의 다른 기업에서도 비슷하게 요구하는 것인지 알아봐야 해요. 그래야지 표준 기능으로 만들지, 아니면 해당 고객만을 위한 기능이 될지 결정할 수 있어요. 꾸준히 듣고 다른 쪽과도 크로스 체크를 해봤을 때 필요하다는 결론이 나면 그때부터 엔지니어링 팀과 디자인 팀에게 업무 요청를 해요. 우리 고객 입장들은 이런 기능을 필요로 한다고. 또 동시에 우리 경쟁 제품은 과연 이런 준비가 되어 있는지, 어떻게 준비되어 있는지 등을 확인해야 해요.

영욱 님이 진행했던 가장 대표적인 프로젝트에 대해 소개 부탁드려요.

수많은 프로덕트의 프로젝트를 진행했지만, 대부분이 ‘라떼’ 이야기가 될 것 같아서 그나마 최근에 했던 프로젝트를 소개해볼게요.

첫 번째는 독일 정부의 요청으로 SAP가 코로나 경고 앱을 빠르게 출시했던 경험이 있습니다. 6주 안에 독일 전 국민이 사용하는 앱을 제작하면서, 오픈 소스로 릴리스하고, 최신 탈중앙화 기술을 사용했었어요. 이 앱은 개발 구현 능력과 디플로이 기술이 부족한 동구권에서 그래도 가져다가 사용할 수 있도록 오픈한 것도 큰 도전이었죠.

또 하나는 기업의 COO와 CFO가 함께 볼 수 있는 대시보드를 만들어 내는 프로젝트예요. 보통 기업의 살림살이는 COO와 CFO가 한다고 볼 수 있는데 그럼에도 지금까지 모든 기업은 이 두 영역의 데이터를 통합해 오지 못했어요. 예를 들어 직원을 채용할 때 임직원 수를 관리하는 COO와 비용을 관리하는 CFO의 관점이 완전히 달라요. COO는 입사 후부터 계산이 시작돼요. 그래서 인원수 대비 비용을 고려하죠. 그런데 CFO는 입사 공고를 시작하면서부터 비용이 나가는 거예요. 헤드헌터 비용이나 인터뷰 하는 직원들의 시간도 비용으로 환산해요. 별 거 아닌 거 같지만 짧으면 몇 달, 길면 1년까지도 그 비용 차이가 생겨요. 이 사람을 인도에서 뽑는 것과 실리콘밸리에서 뽑는 걸 비교해본다면 한 명이라고 쳐도 그 차이는 3배 이상 나겠죠. 이것을 한 눈에 볼 수 있도록 대시보드를 만들어 제공했던 프로젝트가 기억에 남아요. 조만간에 SAP의 제품으로 나올 예정인데 기대가 아주 큽니다.

‘왜’가 궁금했던 개발자, 지금은 ‘왜’를 만들어

현재 영욱 님은 SAP Cloud ERP의 표준 디자인 시스템과 UX를 담당하고 계십니다. 그전에는 개발자로 탄탄하게 커리어를 쌓아오셨고요. 커리어를 전환하게 되신 계기가 있었나요?

저는 개발자로 일할 때도 어떻게 프로덕트 기능들이 결정되는지에 대해 궁금해했어요. 개발자는 보통 PM이 전달해 주는 일감을 듣는 즉시 머릿속으로 코드 구현을 하는 뇌가 발달되어 있는데, 저는 들으면서도 ‘왜’라는 생각을 자꾸 했던 거 같아요.

사실 개발을 할 때 ‘왜’를 이해하지 않으면 ‘무엇을’과 ‘어떻게’를 하는 데에 굉장한 차이가 있을 수 있어요. 만들어 놓고도 왜를 충족시키지 못하는 경우가 발생해요. 흔히들 개발자에게는 창의력이 있어서는 안 된다고 말해요. 개발자는 탁월한 구현 능력만 있으면 되지, 창의력을 갖는 순간 제품이 망가질 수 있다고 하죠. 더 좋은 알고리즘을 만들고 싶은 부분은 충분히 이해되고, 허용되지만 개발자가 창의력이 많아지는 순간 PM이 정해놓은 울타리의 사양이 무너질 수 있어요. 창의력은 사양을 정리하기 전 단계에서 필요한 것이지 구현 단계에서 만들어지면 안되는 거예요. 저는 개발자로서 PM이 정해놓은 걸 만들기만 해야하니까 답답함을 느꼈던 거 같아요.

나중에 저를 PM으로 추천한 상사에게 물어보니 저는 개발자이면서도 시장과 고객의 이야기에 깊은 관심이 있고, 데이터를 기반해 업무의 우선순위를 결정하고, 다양한 방식으로 개발팀을 설득했던 모습이 PM에 잘 맞아보였다고 하더라고요.

저라면 15년 쌓아온 일을 버리고 새로운 일을 해보라는 제안에 선뜻 결정을 내리지 못할 거 같아요. 처음 PM 업무를 제안 받았을 때 망설임은 없으셨어요?

당연히 있었죠. 개발자로 일은 익숙한데, PM으로 새롭게 시작하면 지금까지의 성과만큼이나 좋은 결과를 가져올 수 있을지 두려움도 있었고, 제 경력을 그대로 가져간다고 해도 어쨌든 PM 업무는 새롭게 배워야 하는데, 그게 말처럼 쉬운 일은 아니잖아요. 그럼에도 불구하고 ‘PM이란 프로덕트를 통해 세상에 임팩트를 만드는 과정의 중심에 서 있는 사람’이라는 믿음이 있었어요. 그들의 인사이트가 사용자와 프로덕트에 생명을 부여한다고 느꼈으니까요. 돌이켜보면 15년이 지난 현재는 그때의 결정이 제 인생에서 몇 안되는 최고의 결정이었던 거 같아요.

개발자로서 경험이 PM업무에 많은 도움이 될 거 같아요. 특히 어떤 이점이 있나요.

일단 기술과 구현 프로세스를 이해하는 것이 빠르고 명확해서 엔지니어링, 디자인, 테스트, 데브옵스와 같은 코어 엔지니어링 팀과 대화를 원활하게 진행할 수 있어요. 그들이 하는 언어와 사정을 충분히 이해할 수 있는 것이죠. 또한 새로운 기술이 나올 때마다 그 기술 원리를 이해하기 쉬워요. 덕분에 엔지니어링팀은 물론 고객이나 사용자와 대화를 하는 데에 큰 도움이 되고 신뢰감을 얻는 데에도 도움이 돼요.

SAP에서는 처음 PM이 되면 어떤 교육을 주로 받았나요?

우선 PM이 됐다고 해서 바로 프로덕트를 맡을 수 없어요. 일단 PM의 소양을 배우기 위해 멘토 선배 PM을 따라 1년간 쉐도우 PM으로 교육을 받아요. 이때 익혀야 하는 몇가지 기본 소양이 있어요.

커뮤니케이션 스킬: 제품 비전, 전략, 로드맵
테크니컬 스킬: 개발, 디자인 및 사용자 경험
비즈니스 스킬: 시장 수요, 고객 요구, 수익 모델, 가격 책정 전략, 판매 목표, 마케팅 캠페인, 시장 조사 및 분석, 경쟁사 벤치마킹, 제품 성능 측정 및 최적화
리서치 스킬: 사용자 리서치 및 서베이, 사용자 피드백, 데이터 수집/분석 후 사용자 행동⠂선호도⠂고충⠂요구사항 파악, 설문조사, 인터뷰, 포커스 그룹, 사용성 테스트, 분석 플랫폼
분석 스킬: 통계 모델과 알고리즘을 사용해 상관 관계 파악, 데이터 기반으로 기능의 우선순위를 정하고, 제품 성능 최적화, 제품 성과 측정

이 외에도 효과적으로 협업하는 방법이나 적극적으로 경청, 공감, 갈등 해결, 협상하는 소프트 스킬을 배워요.

자신의 기술 파운데이션을 만들어라

영욱 님은 PM은 각자의 업무에서 10년 이상의 경력을 쌓은 사람이 맡았을 때 제 역할을 할 수 있을 것이라고 말씀하셨어요.

네, 맞아요. PM은 프로덕트를 리드하면서 최종 책임지는 사람이며, 수많은 이해관계자들과 함께 일해야 해요. 내가 그들의 전문성을 존중하듯 그들 역시 나의 전문성을 존중해야 하고 서로 그렇게 느껴야 리드할 수 있어요. 꼭 개발이 아니더라도 CS, 회계, 인사, 재무, 마케팅, 디자인, 사용자 지원 등의 어느 한 부분에서라도 전문성을 확보한 상태에서 PM 업무를 담당해야 이해관계자들과 일하기가 수월합니다. 최소한 ‘저 PM은 OO 부분에 대해서는 전문성을 가지고 현재 프로젝트를 리딩하고 있다’는 사실이 인정이 되어야 그들이 따라 올 거예요. 자신만의 기술 파운데이션을 만들고 그 위에 PM의 기술을 쌓아야지 진정한 PM이 될 수 있습니다.

그럼 PM으로 잘 성장하기 위해서는 어떠한 역량을 갖춰야 할까요?

PM은 3가지 축에서 공부를 게을리 하지 말아야 합니다. 바로 고객/시장/경쟁자이지요. 고객을 알기 위해 고객의 업무와 기술을 알아야 하고요. 시장을 알려면 꾸준히 공부하면서 트렌드를 놓치면 안 됩니다. 또한 경쟁자를 분석할 수 있어야 이길 수 있을테고요. 그 외에도 커뮤니케이션과 대인관계 스킬은 기본이라고 할 수 있습니다.

실제로 SAP에서 PM을 채용할 때는 어떤 부분을 중점적으로 확인하나요?

‘왜’를 알지 못하면 ‘어떻게’와 ‘무엇’을 알 수 없습니다. 그 ‘왜’에 대한 로지컬 씽킹을 굉장히 중요하게 생각해요, 이것이 논리적으로 정리되고, 설득력을 갖추어야 그 다음에 어떻게 구현하고 무엇을 넣어야 하는지를 알게 되기 때문이죠. SAP에서는 PM을 채용할 때 이러한 부분을 중요하게 확인합니다.

하루하루가 짜릿한 백발의 PM

영욱님은 다양한 방식으로 본인의 경험을 나누고 계시는 거 같아요.

저는 정말 운이 좋아 남보다 먼저 그리고 좋은 환경에서 필요한 것을 배우고 일하고 살 수 있었습니다. 이런 운이 절대 그냥 생긴 것이라고 생각하지 않고 그것을 당연하게 생각하지도 않습니다. 제가 모르는 수많은 선배님들의 땀과 노력 덕에 제가 이런 행운을 가질 수 있었죠. 저도 이젠 그런 선배의 나이와 경험의 단계가 되었어요. 그래서 후배 세대에게 가장 기본이 되는 입문서라도 하나 남기는 것이 선배의 역할이지 않을까 싶어서 책(프로덕트 매니지먼트_한빛미디어)도 준비하게 되었습니다.

앞으로 영욱 님의 커리어 계획은 어떻게 되시나요.

저는 지금도 PM 으로서의 하루 하루가 짜릿하고 즐겁습니다. 어떤 새로운 기술이 나올지 또 어떤 사용자의 요청이 있을지, 그 하나 하나를 듣고, 해결할 때마다 행복을 느낍니다. 이 일을 오래했으면 합니다. 지금도 부족하지만, 지금만큼의 지력이 오래 머물러 주기만을 바라고 있어요. 그러면서 글도 쓰고, 책도 쓰고, 후배들에게 도움이 되는 일을 하고 싶습니다.

▶ <PM/PO를 말하다> 시리즈 보러 가기

CREDIT
글 | 정은혜 원티드 콘텐츠 에디터
사진 | 김영욱 본인 제공

발행일 2023.05.30

이벤트 모두 보기