성장하지 못하는 PM의 착각

성장하지 못하는 PM

① 성장하지 못하는 PM의 착각

② PM의 ‘진짜 성장’은 언제 올까?

“성장하지 못하는 PM”은 “모두가 알지만 누구도 제대로 쓰지 못하는, PRD”의 후속편 격에 해당하는 글입니다. 앞선 글에서는 PRD에 대해서, 그리고 PRD를 접하거나 대하는 상황에 대해 서술하며 ‘이제 우리도 진짜 PRD를 써보자’라는 내용을 남겼습니다.

이번 글은 PM이 성장하는 지점에 대해 정확하게 설명하기 위해 역설적으로 접근하려고 합니다. “우리가 어떤 상황에 놓여 있다면 성장 지점에 도달하지 못하는가, 왜 PM으로서 성장하지 못할 것이라고 생각하는가”에 대해 얘기해 보기로 합시다.

분량의 문제로 글은 제품 개발 프로세스의 전반부와 후반부로 나누었습니다. 1편은 제품의 형상화와 코덱, 2편은 제품의 산출과 PM의 성장을 다뤄보겠습니다.

앞선 글과 마찬가지로 푸딩캠프의 학습과 성장 콘퍼런스 2024에서 세션을 준비하고 진행한 경험으로부터 이 글이 시작되었다는 것을 먼저 말씀드립니다.

 제품 개발 프로세스를 설명해 보자

“PM은 제품을 내야만 성장할 수 있다”라고 늘 얘기합니다. 때로는 ‘제품은 내본 놈만 낼 수 있다'는 식의 말을 들어본 적도 있습니다. 이쯤에서 제품을 낸다, 즉, 제품을 산출한다는 것이란 대체 무엇인지에 대해서 한 번쯤 정의를 해보고 넘어가기로 합시다.

제품을 개발하고 산출하는 과정을 간단하게 도식화한 그림입니다. 저 모든 과정을 오롯이 주관하고 경험하며 제품을 출시(launch)해 낸다면 우리는 비로소 ‘제품을 산출하였다’라고 말할 수 있을 것입니다. 프로덕트 매니저(혹은 프로덕트 오너)로 일하고 있는 사람들 가운데 저 과정 전체를 경험하지 않았다고 생각하는 사람은 아무도 없지 않을까요?

그렇다면 그 사람들 모두 제품을 산출하면서 충분히, 혹은 잘 성장하고 있을 텐데요. 이런 종류의 글이나 강연은 무엇 때문에 필요한 것일까요? 당연히 ‘실제로는’ 그렇지 않기 때문입니다. 누군가는 본인 스스로가 제품을 잘 산출하고, 전체 프로세스를 주관하며 오롯이 경험해 나가고 있다 착각할 지 모릅니다. 그와 동시에 스스로 꾸준히 성장해 나가고 있다 착각할 수도 있습니다. 그러나 모두가 그렇지는 않습니다.

제품 개발 프로세스 가운데 어떤 지점에서 우리가 성장하게 되는지, 어떤 지점에서 제품을 산출한다는 착각을 가질 수 있는지 살펴보겠습니다. 특정한 스킬 혹은 단계에서 익숙해지는 것을 성장이라고 착각하고 있지는 않는지도 함께 생각해 봅시다.

제품 개발 프로세스의 전반부, 제품의 형상화 

위에서 설명한 제품 개발 프로세스는 크게 전반부와 후반부로 나누어 생각해 볼 수 있습니다. 전반부는 아이디어를 생성하고, 마켓 리서치를 하고, 이로부터 MRD와 PRD의 초기 버전이 산출되는 단계입니다. 저는 이 단계를 “제품의 형상”을 꾸려가는 단계라고 얘기합니다. 저와는 약간의 차이가 있지만 BaseCamp의 Shape Up에서는 이 단계를 ‘Sketch’라는 단계로 설명하고 있기도 합니다.

전반부에서 많이 일어나는 상황을 한번 가정해 보기로 합시다. 어떠한 이유와 경로로, 제품의 아이디어가 산출되었습니다. 누군가 좋은 책을 읽었거나 칼럼 혹은 발표를 보고 왔을 수 있습니다. 때로는 대표가 투자자와 비전에 대한 고민을 나누고 왔을 수도 있습니다. 어떻든 누군가 아이디어를 가지고 왔을 때, 그 사람의 머릿속에 존재하는 유니버스는 이미 ‘제품이 무엇이고, 시장에서 어떻게 작동하고, 어떤 밸류와 성과를 가져올지’에 대한 상상으로 가득할 것입니다.

그리고 우리는 이 아이디어를 그 사람의 말, 어쩌면 화이트보드에 그려진 그림 몇 개, 또는 A4 이면지에 휘갈겨진 메모와 스케치로 접하게 될 것입니다. 그는 이런 내용들을 토하듯 공유해낸 다음, 개발팀에게 개발해 낼 것을 요구하기도 합니다.

우리가 아주 소규모인 팀이라면, 혹은 텔레파시가 통할 정도로 배경지식을 공유하고 있다면, 어쩌면 이 정도 행위만으로도 개발팀이 훌륭하게 제품을 산출해 낼 수 있을지도 모릅니다. 어떤 사람들은 ‘스타트업이라면 이렇게 해야 한다’ 생각하기도 합니다. 그 때문에 IR 자료에서 “손발을 오래 맞춘, 척하면 척할 수 있는 창업팀/개발팀”이라는 문구를 자랑스레 적어두는 경우도 왕왕 있습니다.

하지만 우리가 영원히 그 상대방하고만 일할 수 있을까요? 사업이 잘되면 잘 되는대로 팀이 커지며 많은 사람과 개발을 해야하고, 안 되면 안 되는대로 또 다른 사람과 일을 해야 할 상황이 올 것입니다. 상대방이 누구이건 간에 일정 수준 이상 결과물을 산출하기 위해서는 텔레파시로 일해서는 안 됩니다. 당연히 저 시점에서부터 어떻게 제품을 문서로 형상화할지를 고민하고, 준비하고, 실행해야 합니다.

무엇보다 거의 대부분 앞에 가정한 상황에서 개발팀은 그 아이디어가 무엇인지를 인지하는 것과는 전혀 무관하게, 그래서 무엇을 개발해야 하는지 전혀 모르는 상황에 놓이고는 합니다. 이 시점에서부터 우리는 무언가 잘못된 길로 빠지게 됩니다.

화면정의서가 등장할 차례입니다. 아이디어를 가져오고 토해내듯 공유한 ‘그 사람’은 이제 자신의 말을 잘 들어주는 디자이너를 찾아 스크린샷을 찍어내기 시작합니다. 스크린플로우도 열심히 연결합니다. 이를 PPT에 그리면 ‘너무 워터폴 같고 애자일하지 않으니까’ 또 피그마에 화면정의서를 그려내기로 합니다. 그렇게만 한다면 이제 피그마 째로 프론트엔드 개발팀에 바로 넘길 수도 있을 테니까요. 그러다 이래저래 문제를 겪고 나서는 “아! 우리 회사는 디자인시스템이 없구나, 역시 잘나가는 회사에서 빠르게 개발하는 데에는 다 그럴만한 이유가 있었어! 먼저 디자인시스템을 갖춰 보자”하고 결론 나기도 합니다. 이쯤 오면 배보다 배꼽이 커져 버린 것은 아닐까요?

피그마에 그리든 PPT에 그리든 화면정의서는 화면정의서일 뿐입니다.

Compress와 Decompress 사이

이런 상황이 저는 전형적으로 형상화에 실패했을 때 나타나는 것이라고 설명합니다. 이런 일이 반복되면 이제 개발팀은 화면정의서 없이 아무것도 개발하지 못한다고 말하기도 합니다. 화면정의서가 없으면 DB를 설계할 수 없다 하기도 하고, UX/디자인 팀은 스크린플로우가 없으면 화면을 구성할 수 없다고 하기도 합니다.

저는 PM에게 스크린샷/와이어프레임을 그리지 않도록 가이드하고 있습니다. 찾아보니 다행히 저만 그런 것은 아닙니다. Shape Up에서도 “Wireframes are too concrete(와이어프레임은 너무 경직되었다)” 라고 언급하며 이를 권장하지 않고 있습니다.

이 상황을 “압축과 풀이”, Compress와 DeCompress로 설명하고자 합니다. 바로 코덱(Codec)입니다.

와이어프레임(Wireframe)은 압축된 정보입니다. 생성한 아이디어에 어떤 종류의 구체화 혹은 구상화를 거친 산출물로 존재합니다. 여기서는 산출하는 사람의 자아를 ‘코덱’ 삼아 압축되었다고 말할 수 있습니다. 우리 자아는 매우 다양합니다. 제품을 개발하는 사람임과 동시에 다른 곳에서는 제품을 소비하는 사람이기도 하며, 제품을 관찰하는 사람이기도 할 것입니다. 그 정도는 개인마다 매우 다를 수밖에 없고, 다른 자아를 기반으로 하는 타인의 코덱하고는 자연히 그만큼의 차이가 존재할 수밖에 없습니다.

텔레파시가 필요했던 앞서 상황을 다시 상기해 봅시다. 어떤 이유로건 멤버끼리 손발을 오래 맞춘 소규모 팀은 비슷하거나 같은 종류의 코덱을 가졌을 확률이 높습니다. 그렇다면 압축과 풀이를 반복해도 손실이 아주 적을 수 있을 것입니다. 하지만 조금 이질적인 사람이 합류한다면 어떻게 될까요? 코덱의 차이로, 우리는 압축과 풀이 과정에서 상당히 큰 손실을 경험하게 될지도 모릅니다. 아주 심한 경우에는 “손상된 파일”이라는 경고 메시지를 확인하게 될지도 모릅니다.

그래서 저는 압축하기 전, 원형의 아이디어를 상대방에게 전달할 것을 요구합니다. 어떻게 아이디어를 스크린샷이나 화면정의서 없이 전달할 수 있을까요? 텍스트로, 문장(Sentence)으로 전달하면 됩니다.

우리가 흔히 화면정의서를 두고 리뷰하며 구술하는 내용 그대로를 문장으로 옮겨 적으면 됩니다. 사실 구술하는 것은 정말 쉽습니다. 조금 모르거나, 애매모호하거나, 무언가 좀 이상해도 구두로 전달하면 그럴싸하게 포장할 수 있습니다.

하지만 글로 적어내면 그렇지 않습니다. 이상하거나 모자란 부분은 단박에 티가 나게 마련입니다. 마치 한 달 전에 적어둔 연애편지처럼 촌스럽고 어색하기 그지없는 경우가 대부분입니다. 그래서 더욱 반드시 텍스트로 적어 내야만 합니다. 그래야 나의 코덱과 상대방의 코덱이 다른 데에서 발생하는 손실을 최소화할 수 있으니까요. 그리고 이렇게 문장으로 구성하며 제품의 형상을 설명하는 문서가 바로, PRD(Product Requirement Document)입니다.

제품을 산출하고 있다는 착각, 할루시네이션

와이어프레임을, 또는 스크린플로우를 열심히 그리고 모아 리뷰를 진행한 다음, “질문이 없냐?”라고 물어보는 것으로 PM의 역할을 다 했다 여기는 상황을 자주 목격합니다. 아무도 질문이 없으면 “제가 그렇게 설명을 잘했나요?” 같은, 시시덕거리는 농담이 동반되기도 합니다. 그렇게 유머러스한 상황은 아닙니다. 아무도 함께 웃어주지는 않았을 거예요.

그리고 여기가 바로 내가 제품을 산출하고 있다는 착각, ‘할루시네이션’이 발생하는 지점입니다. 이렇게 화면을 정의해 개발팀에 넘기고 나면 이제 내가 할 수 있는 일은 ‘일정을 물어보는 것’밖에 남지 않습니다.

“잘 진행되고 있나요?” 매일매일 물어보지만 항상 답은 그린라이트일뿐, 실제로 얼마나 진척되었는지 아무도 모를 가능성이 높습니다.

물론 이러한 ‘나’는 상대방이 질문하면 언제든 답할 준비가 되어있습니다. 다만 아무도 질문하지 않을 뿐이지요. 왜 질문이 없을까요? 그들은 정말 궁금한 것이 없기 때문입니다. 왜냐하면 그들의 코덱으로 화면정의서를 해석한 다음, 완전하게 만들어 내었거든요. 앞서 설명한 ‘손상된 파일’은 그들이 압축을 풀어내지 못하는 상황이 아닙니다. 그들이 압축을 풀어낸 결과물이 내가 압축한 원래의 파일과 동일하지 않은 상황을 말하는 것이지요.

가끔 프로젝트의 진척 상황을 담당자에게 물어보고 답을 얻어 초록/노랑/빨강 신호등으로 표기해 관리하는 경우를 만나면 정말 당황스럽기 짝이 없습니다. 저는 신호등을 차용한 디자인 자체도 싫어하는 데다가 (색맹 때문에 유니버셜 디자인이라고 할 수도 없고요) 언제 노란 불이 들어올지 알 수 없는 그런 상황은 괴롭습니다. 심지어 노란 불을 거치지도 않고 곧바로 빨간 불이 들어올지도 모르는 신호등, 녹색 불이 깜빡거리는 순간도 없이 갑자기 빨간 불로 바뀌는 횡단보도라면, 상상만 해도 끔찍합니다.

스크럼폴, 그리고 숙련된다는 것

그렇다고 이렇게 화면정의를 하고 상위기획서를 쓰는 것이 ‘아무런 가치가 없다’거나 ‘무언가 매우 잘못되었다’고 단언하는 것은 결코 아닙니다.

조직에서 일하는 우리는 개인의 차원이건 조직의 차원이건 사실 해왔던 대로 다시 하고 있을 뿐이기도 합니다. 어떠한 조직에게는 그 방식이 가장 안정된 방법이라고도 할 수도 있습니다. 조직이 충분히 애자일 방법론에 대해 습득하지 못했다면, 또는 우리 조직이 워터폴 방법론에 더 친숙하다면, 굳이 워터폴을 배격할 필요가 없다고 생각합니다. 때로는 이런 문제가 워터폴에 대한 배격에서부터 시작하는 것이 아닌가 의심스럽기도 합니다.

물론 저는 애자일 방법론, 특히 애자일 제품 개발 프로세스(Agile Product Development Process)를 선호합니다. 소프트웨어 제품에서는 형상화를 비롯하여 훨씬 더 유리하다고 생각합니다. 그렇다고 워터폴 방법론이 열등하다거나 문제가 있는 방법론이라고는 생각하지도 않습니다. 워터폴은 그 자체로 오랜 시간을 들여 완성한 방법입니다. 다만 우리가 현대의 소프트웨어 개발을 함에 있어 시장의 불확실성, 불분명함을 담아내기 어려움이 있다는 점에 공감대를 이루고 있을 뿐이죠.

진짜 문제는 익숙한 워터폴의 특성들, 예를 들면 단계별 사인 오프 같은 것을 유지하면서 ‘애자일인 척’하고 싶어 하는 “스크럼폴”이라고 할 수 있습니다. 7 Factor Software의 창업자인 제레미 듀발(Jeremy Duval)은 스타트업들이 애자일을 가장해 스크럼만으로 워터폴 방식을 유지하는 현상을 “미니워터폴/스크럼폴”이라고 칭하며 강력하게 비난하고 있습니다.

스크럼으로 가장한 워터폴 기법을 통해(이른바 스크럼폴; Scrumfall) 기업들은 하향식 마이크로 관리를 재개하고, 사일로를 강화하고, 유연성을 속박하고, 소프트웨어 엔지니어를 단순히 코드를 생성하는 기계로 대상화하고 있다.

 

• 제레미 듀발, 스크럼폴… 워터폴이 애자일인 척 준동할 때, CIO 코리아

지금까지 ‘성장하지 못한다’는 표현에 거부감이 들거나 반감을 갖는 분도 있을 것입니다. 지금의 나는 1년 전의 나, 6개월 전의 나보다 훨씬 더 잘하고 있을 테니까요. 화면정의서는 훨씬 더 깔끔하고 정확하며 생산에 드는 시간도 절반밖에 필요하지 않으니까요. 개발자 리뷰도 훨씬 편안하고 부드러울지 모릅니다.

하지만 저는 이것은 성장한 것이 아니라 숙련된 것이라고 생각합니다.

배움은 위험을 감수하기로 할 때 다른 것, 먹히지 않는 방법을 시도할 때 일어나요. 10년 동안 매일매일 똑같은 방법으로 양파를 요리해서 완벽하게 내어놓는다면, 그건 배우는 게 아니에요. 실행하는 거죠.

 

• 에드워드 리 셰프 인터뷰에서 발췌

RPG 게임에서 마을 앞 슬라임만 잡다 보면, 어느 시점에서부터는 레벨업을 할 수 없습니다. 결국 더 큰 모험을 하려면, 파티에 참여해 익숙하지 않은 동료들과 낯선 던전에 들어가야만 합니다. 그곳에서는 슬라임을 잡기 위해 숙련된 방법으로는 충분하지 않을 것입니다.

“우리의 삶은 RPG 게임이 아닌데, 꼭 성장을 해야만 하는가”라고 반문할 수도 있습니다. 물론 어떠한 애니메이션이나 게임들처럼 꼭 성장이 없더라도 얼마든지 모험을 즐길 수 있죠. 하지만 성장하는 시점을 발견하고, 또 제품을 산출하는 즐거움을 느껴보는 것 역시 아주 즐거운 경험이 될 수 있습니다.

이어지는 제품 개발 프로세스의 후반부, 2편에서는 ‘PM이 성장을 획득하는 진짜 순간’에 대해 알아보기로 합시다.

성장하지 못하는 PM

① 성장하지 못하는 PM의 착각

② PM의 ‘진짜 성장’은 언제 올까?

요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.