<div id="readability-page-1" class="page"><div>
<p>'태영'은 2년 차 주니어 프로덕트 매니저다. 최근 팀에서 처음으로 혼자 프로젝트를 맡게 되면서 큰 벽에 부딪혔다. 개발팀과의 회의에서 사용되는 기술 용어들이 외계어처럼 들렸고, 때로는 개발자들이 무시하는 듯한 발언을 하는 것 같아 자신감이 크게 떨어졌다.</p>
<p>한 회의에서 앱 개발자와 서버 개발자가 사용자 피드 데이터 로딩 문제에 대해 논의하는 것을 들었다. 그들은 '페이징 처리', 'API 파라미터' 등의 용어를 사용하며 해결책을 모색했지만, '태영'은 그 의미를 이해하지 못했다. 회의록에는 액션 아이템을 작성했지만, 사실 그 내용을 완전히 파악하지 못한 상태였다.</p>
<p>이러한 상황을 극복하고자 '태영'은 프로그래밍 교육을 수강하기로 결심했다. 열정적으로 개발 공부를 시작했지만, 예상과 달리 개발자들과의 커뮤니케이션은 크게 개선되지 않았다. 오히려 더 복잡한 기술적 논의에 직면하게 되면서 점점 더 자신감을 잃어갔다. '태영'은 고민했다. '이렇게 힘들게 공부해서 어느 세월에 1인분의 몫을 할 수 있을까?'</p>
<p>사실 '태영'이 직면한 진짜 문제는 단순히 개발 용어를 모른다는 것이 아니었다. 그것은 개발 프로세스와 시스템 구조에 대한 전반적인 이해가 부족하다는 것이었다. 이는 프로그래밍 언어를 배우는 것으로는 해결할 수 없다.</p>
<h3>프로덕트 매니저, 개발을 얼마나 알아야 할까?</h3>
<p>프로덕트 매니저가 기술적인 이해도를 갖추면 개발 팀과의 커뮤니케이션이 원활해지고, 효율적인 의사 결정이 가능해진다. 애자일이나 스크럼과 같은 제품 개발 프로세스를 최적화하고 제품 품질을 향상시키는 데에도 도움이 된다. 개발을 전공하지 않은 프로덕트 매니저는 이런 갈증을 일을 하는 내내 가지고 있어야 하고, 개발을 전공한 프로덕트 매니저들은 이런 차별점을 가지고 승승장구 하기도 한다. 심지어 용어를 써가며 개발자들과 농담도 한다. 많은 개발자들은 '개발 좀 아는' 프로덕트 매니저와 편하게 협업하고 싶어할 것이다.</p>
<p>그런 묘한 분위기 때문에 개발을 공부해야겠다고 마음먹은 프로덕트 매니저의 팔할은 개발을 전공하지 않은 프로덕트 매니저인 경우가 많은 것 같다. 하지만 실제로 서비스를 기획하고 개발의 의사결정을 해내는 많은 프로덕트 매니저들은 컴퓨터과학이나 공학을 전공하지 않은, 심지어 인문계열이나 예체능 계열도 많다. 이들이 모두 개발을 배워야만 일해야 한다면 과연 이 직군에서 얼마나 많은 사람들이 살아남을 수 있었을까. 나 역시 개발을 전공하였지만, 코드 한 줄도 스스로 짤 줄 모른다. 여러분들도 알다시피 대학에서 전공을 한 것과 전공으로 밥벌이를 한다는 것은 전혀 다른 이야기다.</p>
<p>프로덕트 매니저로서 일을 하다 보면, '프로덕트 매니저는 그냥 문서 쓰는 역할 아니야?'라는 말을 들을 때가 있을 것이다. 하지만 실제로는 이해관계자들과 협력해 요구사항을 분석하고, 가설을 세워 검증하며, 그 결과를 바탕으로 비즈니스 성과를 만들어내는 데 중점을 둔다. 기획서는 이 과정의 한 부분에 불과하다.</p>
<p>마찬가지로, 개발을 배워보는 것은 개발자의 사고방식을 이해하는 데 도움이 될 수 있지만 개발자의 역할을 모두 이해할 수 있는 것은 아니다. 개발자도 문제를 해결하는 사람이다. 문제 해결을 하는 영역이 프로덕트매니저와 조금 다를 뿐이다. 비즈니스 요구사항을 수용할 수 있도록 시스템을 설계하며 구현하는 일을 담당하기 때문에, 개발자의 전체적인 사고방식을 이해하고 설계 과정에 대해 이해하는 것이 프로덕트를 이해하는데 더 도움이 된다.</p>
<h3>용어보다 중요한 것은 대화다</h3>
<p>여기까지 글을 읽는데 어렵지 않았다면 이런 생각이 들었을 것이다. 개발을 이해하는 게 프로덕트 매니저 업무에 좋다는 건 알겠고, 프로그래밍은 쓸데없으니 공부하지 말라니, 어떻게 하면 좋을까? 좋다. 우리가 다시 한번 개발을 이해해야 한다는 목적과 목표를 분명히 해보자. 많은 이유가 있겠지만 개발을 배우고 싶다고 생각하게 되는 이유는 3가지 정도로 수렴한다.</p>
<ul>
<li>개발자들과 <strong>커뮤니케이션</strong>하기 위해서</li>
<li>서비스 정책의 <strong>의사결정</strong>을 원활히 하기 위해서</li>
<li>기술적 이슈, 운영이슈 등을 <strong>긴급히 대응</strong>하기 위해서</li>
</ul>
<p>물론 나도 많은 시행착오가 있었다. 내가 서비스기획의 일을 시작했을 때에는 그럴듯한 서비스 기획 부트캠프 같은 것조차 없었기 때문에, Java나 Objective-C 같은 개발언어 서적들을 보면서 모바일 앱에 대한 이해를 높여보려고 했다. 공식 개발문서들도 참 많이 읽어봤다. 그 때는 참 자부심이 있었는데, 지금 돌아보면 부질없는 짓이었다고 생각한다.</p>
<p>내가 서비스와 개발의 이해에 대해 레벨업을 했을 때는 "개발자들에게 우리 서비스의 구조에 대해 설명해달라"고 요청하고 설명을 들었을 때였다. 바로 시각화를 활용했던 것이다. 개발자의 옆에 앉아 노트에 구조를 그려보자. 복잡한 기술 용어 대신 네모, 동그라미, 화살표로 구성된 간단한 다이어그램으로 시작하면 훨씬 이해하기 쉬워진다. 머리속으로 있던 것들을 눈으로 표현하면서 읽어내면서 개발자와 프로덕트 매니저가 같은 생각을 하기 시작하는 순간이다.</p>
<p>이 과정에서 한 단계 더 나아간다면 개발자에게 시스템 설계 이유를 물어보며 이해를 깊이하고, 프로덕트 매니저의 역할 범위에 대해서도 의견을 구해보자. 조금 더 문서화에 욕심이 난다면 컨텍스트 다이어그램, 유저 플로우 다이어그램, 시퀀스 다이어그램, 상태 다이어그램 등 다양한 다이어그램을 익히면 매우 도움이 된다. 이러한 방식으로 접근하면 복잡한 기술적 개념을 더 쉽게 이해하고 개발자와 효과적으로 소통할 수 있다. 드디어 개발을 배우지 않고도 개발자와 소통하는 방법을 배웠다!</p>
<h3>그래도 좀 더 해보고 싶다면</h3>
<p>개발자들이 스터디를 통해 개발 역량을 키우는 것을 관찰해보자. 어떤 책을 보는지 봐도 잘 모를 수도 있다. (그럼 물어보자! 물어본다고 해치지 않을 것이다!) 스터디의 주제는 크게 구분하면 둘로 나뉜다. 바로 개념적인 이해들을 통해 멘탈 모델을 구축(밖에서 안으로)하는 것과, 새로운 프로그래밍 언어를 배워서 그것을 실제로 구현(안에서 밖으로)하는 것이다.</p>
<p>프로덕트 매니저가 배웠을 때 가치가 있을만한 정보는 개발자들이 멘탈 모델을 구축하는 단계에서 다뤄지는 지식들이다. 개발자들도 기획을 하고 설계를 하는 단계가 있기 때문에, 프로덕트 매니저가 하는 일과 굉장히 밀접하게 닿아있다. 리얼 월드의 정보들을 데이터로 어떻게 정의해야 하는지, 어떻게 시스템을 구성하고, 요구사항을 구조화해야 하는지 등을 다루기 때문에, 이런 정보들을 이해한다면 프로덕트 매니저도 개발자처럼 프로덕트의 역할과 정의를 명확히 하고, 시스템 간 혹은 서비스 간의 정책들을 설계해나갈 수 있다.</p>
<p>개발자들은 신간이 나오면 유행처럼 같은 책을 사곤 하는데, 나는 그런 책 제목을 보면 흥미가 발동해서 알아듣지도 못하는 책을 사고 후회를 하기도 한다. 그 중에 읽었던 책 중에 어? 프로덕트 매니저가 읽으면 괜찮을 만한 책인데? 싶은 몇 권을 추천한다.</p>
<ul>
<li><a href="https://product.kyobobook.co.kr/detail/S000001804574">도메인 주도 설계 핵심</a> (반 버논 지음)</li>
<li><a href="https://product.kyobobook.co.kr/detail/S000001628109">객체지향의 사실과 오해</a> (조영호 지음)</li>
<li><a href="https://product.kyobobook.co.kr/detail/S000001810394">개발자에서 아키텍트로</a> (마이클 킬링 지음)</li>
</ul>
<p>코드는 나오지 않고, 그림과 설명이 있는 책이라서 글자만 읽어보아도 어느 정도 도움이 될 것이다. 물론 여러분의 회사의 서비스에 적용할 수 있는 개념이 아닐 수도 있다. 어딘가에 써먹을 생각을 하기보다는 개발자들은 이런 고민들을 한다는 것을 이해하는 것만으로도 충분하다.</p>
<hr>
<p>ps. 이 글은 <a href="https://maily.so/writing2alive/posts/323c8cc6">AC2 커뮤니티 뉴스레터</a>에서 먼저 발행된 글입니다.</p>
</div></div>

by minieetea

'태영'은 2년 차 주니어 프로덕트 매니저다. 최근 팀에서 처음으로 혼자 프로젝트를 맡게 되면서 큰 벽에 부딪혔다. 개발팀과의 회의에서 사용되는 기술 용어들이 외계어처럼 들렸고, 때로는 개발자들이 무시하는 듯한 발언을 하는 것 같아 자신감이 크게 떨어졌다.
한 회의에서 앱 개발자와 서버 개발자가 사용자 피드 데이터 로딩 문제에 대해 논의하는 것을 들었다. 그들은 '페이징 처리', 'API 파라미터' 등의 용어를 사용하며 해결책을 모색했지만, '태영'은 그 의미를 이해하지 못했다. 회의록에는 액션 아이템을 작성했지만, 사실 그 내용을 완전히 파악하지 못한 상태였다.
이러한 상황을 극복하고자 '태영'은 프로그래밍 교육을 수강하기로 결심했다. 열정적으로 개발 공부를 시작했지만, 예상과 달리 개발자들과의 커뮤니케이션은 크게 개선되지 않았다. 오히려 더 복잡한 기술적 논의에 직면하게 되면서 점점 더 자신감을 잃어갔다. '태영'은 고민했다. '이렇게 힘들게 공부해서 어느 세월에 1인분의 몫을 할 수 있을까?'
사실 '태영'이 직면한 진짜 문제는 단순히 개발 용어를 모른다는 것이 아니었다. 그것은 개발 프로세스와 시스템 구조에 대한 전반적인 이해가 부족하다는 것이었다. 이는 프로그래밍 언어를 배우는 것으로는 해결할 수 없다.
프로덕트 매니저, 개발을 얼마나 알아야 할까?
프로덕트 매니저가 기술적인 이해도를 갖추면 개발 팀과의 커뮤니케이션이 원활해지고, 효율적인 의사 결정이 가능해진다. 애자일이나 스크럼과 같은 제품 개발 프로세스를 최적화하고 제품 품질을 향상시키는 데에도 도움이 된다. 개발을 전공하지 않은 프로덕트 매니저는 이런 갈증을 일을 하는 내내 가지고 있어야 하고, 개발을 전공한 프로덕트 매니저들은 이런 차별점을 가지고 승승장구 하기도 한다. 심지어 용어를 써가며 개발자들과 농담도 한다. 많은 개발자들은 '개발 좀 아는' 프로덕트 매니저와 편하게 협업하고 싶어할 것이다.
그런 묘한 분위기 때문에 개발을 공부해야겠다고 마음먹은 프로덕트 매니저의 팔할은 개발을 전공하지 않은 프로덕트 매니저인 경우가 많은 것 같다. 하지만 실제로 서비스를 기획하고 개발의 의사결정을 해내는 많은 프로덕트 매니저들은 컴퓨터과학이나 공학을 전공하지 않은, 심지어 인문계열이나 예체능 계열도 많다. 이들이 모두 개발을 배워야만 일해야 한다면 과연 이 직군에서 얼마나 많은 사람들이 살아남을 수 있었을까. 나 역시 개발을 전공하였지만, 코드 한 줄도 스스로 짤 줄 모른다. 여러분들도 알다시피 대학에서 전공을 한 것과 전공으로 밥벌이를 한다는 것은 전혀 다른 이야기다.
프로덕트 매니저로서 일을 하다 보면, '프로덕트 매니저는 그냥 문서 쓰는 역할 아니야?'라는 말을 들을 때가 있을 것이다. 하지만 실제로는 이해관계자들과 협력해 요구사항을 분석하고, 가설을 세워 검증하며, 그 결과를 바탕으로 비즈니스 성과를 만들어내는 데 중점을 둔다. 기획서는 이 과정의 한 부분에 불과하다.
마찬가지로, 개발을 배워보는 것은 개발자의 사고방식을 이해하는 데 도움이 될 수 있지만 개발자의 역할을 모두 이해할 수 있는 것은 아니다. 개발자도 문제를 해결하는 사람이다. 문제 해결을 하는 영역이 프로덕트매니저와 조금 다를 뿐이다. 비즈니스 요구사항을 수용할 수 있도록 시스템을 설계하며 구현하는 일을 담당하기 때문에, 개발자의 전체적인 사고방식을 이해하고 설계 과정에 대해 이해하는 것이 프로덕트를 이해하는데 더 도움이 된다.
용어보다 중요한 것은 대화다
여기까지 글을 읽는데 어렵지 않았다면 이런 생각이 들었을 것이다. 개발을 이해하는 게 프로덕트 매니저 업무에 좋다는 건 알겠고, 프로그래밍은 쓸데없으니 공부하지 말라니, 어떻게 하면 좋을까? 좋다. 우리가 다시 한번 개발을 이해해야 한다는 목적과 목표를 분명히 해보자. 많은 이유가 있겠지만 개발을 배우고 싶다고 생각하게 되는 이유는 3가지 정도로 수렴한다.
개발자들과 커뮤니케이션하기 위해서
서비스 정책의 의사결정을 원활히 하기 위해서
기술적 이슈, 운영이슈 등을 긴급히 대응하기 위해서
물론 나도 많은 시행착오가 있었다. 내가 서비스기획의 일을 시작했을 때에는 그럴듯한 서비스 기획 부트캠프 같은 것조차 없었기 때문에, Java나 Objective-C 같은 개발언어 서적들을 보면서 모바일 앱에 대한 이해를 높여보려고 했다. 공식 개발문서들도 참 많이 읽어봤다. 그 때는 참 자부심이 있었는데, 지금 돌아보면 부질없는 짓이었다고 생각한다.
내가 서비스와 개발의 이해에 대해 레벨업을 했을 때는 "개발자들에게 우리 서비스의 구조에 대해 설명해달라"고 요청하고 설명을 들었을 때였다. 바로 시각화를 활용했던 것이다. 개발자의 옆에 앉아 노트에 구조를 그려보자. 복잡한 기술 용어 대신 네모, 동그라미, 화살표로 구성된 간단한 다이어그램으로 시작하면 훨씬 이해하기 쉬워진다. 머리속으로 있던 것들을 눈으로 표현하면서 읽어내면서 개발자와 프로덕트 매니저가 같은 생각을 하기 시작하는 순간이다.
이 과정에서 한 단계 더 나아간다면 개발자에게 시스템 설계 이유를 물어보며 이해를 깊이하고, 프로덕트 매니저의 역할 범위에 대해서도 의견을 구해보자. 조금 더 문서화에 욕심이 난다면 컨텍스트 다이어그램, 유저 플로우 다이어그램, 시퀀스 다이어그램, 상태 다이어그램 등 다양한 다이어그램을 익히면 매우 도움이 된다. 이러한 방식으로 접근하면 복잡한 기술적 개념을 더 쉽게 이해하고 개발자와 효과적으로 소통할 수 있다. 드디어 개발을 배우지 않고도 개발자와 소통하는 방법을 배웠다!
그래도 좀 더 해보고 싶다면
개발자들이 스터디를 통해 개발 역량을 키우는 것을 관찰해보자. 어떤 책을 보는지 봐도 잘 모를 수도 있다. (그럼 물어보자! 물어본다고 해치지 않을 것이다!) 스터디의 주제는 크게 구분하면 둘로 나뉜다. 바로 개념적인 이해들을 통해 멘탈 모델을 구축(밖에서 안으로)하는 것과, 새로운 프로그래밍 언어를 배워서 그것을 실제로 구현(안에서 밖으로)하는 것이다.
프로덕트 매니저가 배웠을 때 가치가 있을만한 정보는 개발자들이 멘탈 모델을 구축하는 단계에서 다뤄지는 지식들이다. 개발자들도 기획을 하고 설계를 하는 단계가 있기 때문에, 프로덕트 매니저가 하는 일과 굉장히 밀접하게 닿아있다. 리얼 월드의 정보들을 데이터로 어떻게 정의해야 하는지, 어떻게 시스템을 구성하고, 요구사항을 구조화해야 하는지 등을 다루기 때문에, 이런 정보들을 이해한다면 프로덕트 매니저도 개발자처럼 프로덕트의 역할과 정의를 명확히 하고, 시스템 간 혹은 서비스 간의 정책들을 설계해나갈 수 있다.
개발자들은 신간이 나오면 유행처럼 같은 책을 사곤 하는데, 나는 그런 책 제목을 보면 흥미가 발동해서 알아듣지도 못하는 책을 사고 후회를 하기도 한다. 그 중에 읽었던 책 중에 어? 프로덕트 매니저가 읽으면 괜찮을 만한 책인데? 싶은 몇 권을 추천한다.
도메인 주도 설계 핵심 (반 버논 지음)
객체지향의 사실과 오해 (조영호 지음)
개발자에서 아키텍트로 (마이클 킬링 지음)
코드는 나오지 않고, 그림과 설명이 있는 책이라서 글자만 읽어보아도 어느 정도 도움이 될 것이다. 물론 여러분의 회사의 서비스에 적용할 수 있는 개념이 아닐 수도 있다. 어딘가에 써먹을 생각을 하기보다는 개발자들은 이런 고민들을 한다는 것을 이해하는 것만으로도 충분하다.
ps. 이 글은 AC2 커뮤니티 뉴스레터에서 먼저 발행된 글입니다.

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

댓글