프로덕트 매니저에게 개발공부란

태영님은 2년 차 주니어 프로덕트 매니저입니다. 최근 팀에서 처음으로 혼자 프로젝트를 맡게 되면서, 큰 벽에 부딪혔습니다. 개발팀과의 회의에서 사용되는 기술 용어들이 외계어처럼 들렸고, 때로는 개발자들이 무시하는 듯한 발언을 하는 것 같아 자신감이 크게 떨어졌습니다.

한 회의에서 앱 개발자와 서버 개발자가 사용자 피드 데이터 로딩 문제에 대해 논의하는 것을 들었습니다. 그들은 '페이징 처리', 'API 파라미터' 등의 용어를 사용하며 해결책을 모색했지만, 태영은 그 의미를 이해하지 못했습니다. 회의록에는 액션 아이템을 작성했지만, 사실 그 내용을 완전히 파악하지 못한 상태였습니다.

이러한 상황을 극복하고자 태영님은 프로그래밍 교육을 수강하기로 결심했습니다. 열정적으로 개발 공부를 시작했지만, 예상과 달리 개발자들과의 커뮤니케이션은 크게 개선되지 않았습니다. 오히려 더 복잡한 기술적 논의에 직면하게 되면서 점점 더 자신감을 잃어갔습니다. 태영님은 고민했습니다. ‘이렇게 힘들게 공부해서 어느 세월에 1인분의 몫을 할 수 있을까?’

사실 태영님이 직면한 진짜 문제는 단순히 개발 용어를 모른다는 것이 아니었습니다. 그것은 개발 프로세스와 시스템 구조에 대한 전반적인 이해가 부족하다는 것이었습니다. 이건 프로그래밍 언어를 배우는 것으로는 해결할 수 없습니다.

프로덕트 매니저, 개발을 얼마나 알아야 할까?

프로덕트 매니저가 기술적인 이해도를 갖추면 개발 팀과의 커뮤니케이션이 원활해지고, 효율적인 의사 결정이 가능해집니다. 애자일이나 스크럼과 같은 제품 개발 프로세스를 최적화하고 제품 품질을 향상시키는 데에도 도움이 됩니다. 개발을 전공하지 않은 프로덕트 매니저는 이런 갈증을 일을 하는 내내 가지고 있어야 하고, 개발을 전공한 프로덕트 매니저들은 이런 차별점을 가지고 승승장구 하기도 합니다. 심지어 용어를 써가며 개발자들과 농담도 하더라구요. 많은 개발자들은 ‘개발 좀 아는' 프로덕트 매니저와 편하게 협업하고 싶어할테지요.

그런 묘한 분위기 때문에 개발을 공부해야겠다 마음먹은 프로덕트 매니저의 팔할은 개발을 전공하지 않는 프로덕트 매니저인 경우가 많은 것 같습니다. 하지만 실제로 서비스를 기획하고 개발의 의사결정을 해내는 많은 프로덕트 매니저들은 컴퓨터과학이나 공학을 전공하지 않은, 심지어 인문계열이나 예체능 계열도 많습니다. 이들이 모두 개발을 배워야만 일해야 한다면 과연 이 직군에서 얼마나 많은 분들이 살아남을 수 있었을까요. 저 역시 개발을 전공하였지만, 코드 한 줄도 스스로 짤 줄 모릅니다. 여러분들도 아시다시피 대학에서 전공을 한 것과 전공으로 밥 벌이를 한다는 것은 전혀 다른 이야기니까요.

프로덕트 매니저으로서 일을 하다 보면, ‘프로덕트 매니저은 그냥 문서 쓰는 역할 아니야?’라는 말을 들을 때가 있을지도 모릅니다. 하지만 실제로는 이해관계자들과 협력해 요구사항을 분석하고, 가설을 세워 검증하며, 그 결과를 바탕으로 비즈니스 성과를 만들어내는 데 중점을 둡니다. 기획서는 이 과정의 한 부분에 불과하죠.

마찬가지로, 개발을 배워보는 것은 개발자의 사고방식을 이해하는 데 도움이 될 수 있지만 개발자의 역할을 모두 이해할 수 있는 것은 아닙니다. 개발자도 문제를 해결하는 사람입니다. 문제 해결을 하는 영역이 프로덕트매니저와 조금 다를 뿐입니다. 비즈니스 요구사항을 수용할 수 있도록 시스템을 설계하며 구현하는 일을 담당하기 때문에, 개발자의 전체적인 사고방식을 이해하고 설계 과정에 대해 이해하는 것이 프로덕트를 이해하는데에 더 도움이 됩니다. 

용어보다 중요한 것은 대화예요

여기까지 글을 읽는데 어렵지 않게 오셨다면 이런 생각이 드셨을거예요. 개발을 이해하는게 프로덕트 매니저 업무에 좋다는 건 알고 좋다는 건 알겠고, 프로그래밍은 쓸데 없으니 공부하지 말라니, 어떻게 하면 좋을까요? 좋습니다. 우리가 다시 한번 개발을 이해해야 한다는 목적과 목표를 분명히 해보자구요. 많은 이유가 있겠지만 개발을 배우고 싶다고 생각하게 되는 이유는 3가지 정도로 수렴합니다.

물론 저도 많은 시행착오가 있었습니다. 제가 서비스기획의 일을 시작했을 때에는 그럴듯한 서비스 기획 부트캠프 같은 것 조차 없었기 때문에, Java 나 Objective-C 같은 개발언어 서적들을 보면서 모바일 앱에 대한 이해를 높여보려고 했습니다. 공식 개발문서들도 참 많이 읽어봤습니다. 그 때는 참 자부심이 있었는데, 지금 돌아보면 부질없는 짓이었다 싶어요. 

제가 서비스와 개발의 이해에 대해 레벨업을 했을 때에는 “개발자들에게 우리 서비스의 구조에 대해 설명해달라"고 요청하고 설명을 들었을 때입니다. 바로 시각화를 활용했던 것이죠. 개발자의 옆에 앉아 노트에 구조를 그려보세요. 복잡한 기술 용어 대신 네모, 동그라미, 화살표로 구성된 간단한 다이어그램으로 시작하면 훨씬 이해하기 쉬워집니다. 머리속으로 있던 것들을 눈으로 표현하면서 읽어내면서 개발자와 프로덕트 매니저가 같은 생각을 하기 시작하는 순간입니다.

이 과정에서 한 단계 더 나아간다면 개발자에게 시스템 설계 이유를 물어보며 이해를 깊이하고, 프로덕트 매니저의 역할 범위에 대해서도 의견을 구해보세요. 조금 더 문서화에 욕심이 난다면 컨텍스트 다이어그램, 유저 플로우 다이어그램, 시퀀스 다이어그램, 상태 다이어그램 등 다양한 다이어그램을 익히면 매우 도움이 됩니다. 이러한 방식으로 접근하면 복잡한 기술적 개념을 더 쉽게 이해하고 개발자와 효과적으로 소통할 수 있습니다. 드디어 개발을 배우지 않고도 개발자와 소통하는 방법을 배웠네요! 

그래도 좀 더 해보고 싶다면

개발자분들이 스터디를 통해 개발 역량을 키우는 것을 관찰해보세요. 어떤 책을 보는지 봐도 잘 모르실 수도 있겠네요. (그럼 물어봅시다! 물거나 해치지 않을거에요!) 스터디의 주제는 크게 구분하면 둘로 나뉠텐데요. 바로 개념적인 이해들을 통해 멘탈 모델을 구축(밖에서 안으로)하는 것과, 새로운 프로그래밍 언어를 배워서 그것을 실제로 구현(안에서 밖으로) 하는 것 입니다.

프로덕트 매니저가 배웠을 때 가치가 있을만한 정보는 개발자들이 멘탈 모델을 구축하는 단계에서 다뤄지는 지식들입니다. 개발자들도 기획을 하고 설계를 하는 단계가 있기 때문에, 프로덕트 매니저가 하는 일과 굉장히 밀접하게 닿아있습니다. 리얼 월드의 정보들을 데이터로 어떻게 정의해야 하는지, 어떻게 시스템을 구성하고, 요구사항을 구조화해야 하는지 등이 다루기 때문에, 이런 정보들을 이해한다면 프로덕트 매니저도 개발자처럼 프로덕트의 역할과 정의를 명확히 하고, 시스템간 혹은 서비스간의 정책들을 설계해나갈 수 있습니다. 

개발자분들은 신간이 나오면 유행처럼 같은 책을 사실 때가 있는데, 저는 그런 책 제목을 보면 흥미가 발동해서 알아듣지도 못하는 책을 사고 후회를 하기도 합니다. 그 중에 읽었던 책 중에 어? 프로덕트 매니저가 읽으면 괜찮을만한 책인데? 싶은 몇 권을 추천드립니다. 

코드는 나오지 않고, 그림과 설명이 있는 책이라서 글자만 읽어보셔도 어느정도 도움이 될 겁니다. 물론 여러분의 회사의 서비스에 적용할 수 있는 개념이 아닐 수도 있을 거예요. 어딘가에 써먹을 생각을 하기보다는 개발자들은 이런 고민들을 하는구나를 이해하는 것만으로도 충분합니다.