[도서리뷰] 해결 할 프로덕트 디자인

해결 할 프로덕트 디자인을 신청한 이유

길벗 21차 개발자 도서 리뷰어에 선정되었다.
이번에 받아본 도서는 '해결 할 프로덕트 디자인'

나의 길벗 개발자 도서 리뷰 이력을 쭉 보아온 분은 되게 다양한 분야의 서적들을 읽는다고 생각하실 것 같다.
그도 그럴 것이, Tensorflow.js , 가상화 및 컨테이너를 거쳐 이번엔 프로덕트 디자인을 읽고 있으니... 나의 정체성에 슬슬 의문부호가 생기실 지도...?

사실 나는 풀스택 웹 개발자로 커리어를 시작했지만, 이미 정해진 세부적인 구현사항을 방법론적인 관점 및 리소스 효율 관점에서 코드로 구현해내는 개발보다는 서비스나 프로덕트 자체의 디자인과 기획, 직면한 문제의 해결방안 제시 등에 더 흥미를 느끼게 되었다.

생각해보면 내가 애초에 개발자라는 직업에 매력을 느낀 것도 Problem Solving 때문이었는데 조직의 규모가 커지면 커질수록, 직무가 분화되고 전문화되면 될수록 개발자보다는 기획자가 그러한 분야에 더 큰 영향력을 지닌다는 생각이 들었다. 그래서 현재는 PM 내지는 기획자로 커리어를 전환한 상태.

기획력을 지닌 개발자라는 포지션도 충분히 매력적이지만, 현실적으로 이미 기획단에서의 작업이 끝난 후 개발단으로 기획안이 넘어왔을 때는 그 산출물에 대해 이런 저런 제안을 하는 것이 어려운 측면이 있다. 그래서 첫 단추를 내가 직접 끼우겠다는 입장.

뭐 어쨌든 결론은, 나는 PM 으로서 다방면의 개발 기술에 대한 얕고 넓은 지식이 필요한 편이기에 다양한 분야의 서적을 읽고 있다. 하지만 그동안의 도서들이 PM으로서의 개발 지식 저변을 넓히기 위한 것들이었다면, 이번 도서는 나의 직무에 보다 직접적인 관련이 있는 도서라는 점에서 차이가 있다.

해결 할 프로덕트 디자인 (21차 길벗 개발자 도서리뷰)

 

첫 인상 : 어라? 기획보다는 디자인에 가까운 책인가...?

사실 프로덕트 디자인이란 말을 외국에서는 기획과 비슷한 의미로 쓴다. 직역하자면, 제품 설계이니 기획의 의미로 쓰는 것도 무리는 아니다. 그런 점에서 나는 이번 책을 신청할 때, 기획 직무와 관련된 도서를 상상했었다.

하지만 내가 받아 본 책의 내용은 나의 예상보다는 좀 더 '디자인'에 가까운 느낌을 받았다. 
와이어프레임의 스케치에 대한 내용이 나온다거나 '시각적 측면에서 벗어난 본질적인 경험에 초점을 둔 디자인을 하라'는 문장 등은 말 그대로 일반적으로 생각하는 '디자이너'의 직무에 보다 가까운 내용들이었다.

기획단에서 사용하는 '스토리보드'와는 조금 거리가 먼 '스토리보드'이다. 나는 위와 같은 '스토리보드'는 디자인단에서 주로 쓴다고 알고 있다.

그렇지만 기획자의 입장에서, 그리고 PM의 입장에서 이 책의 내용이 직무상 필요 없는 내용이냐를 본다면 그것은 결코 아니다. 이것은 리뷰어로 선정되었기 때문에 하는 소리가 아니다!

아래 사진들을 보자.

이런 부분은 사실 우리나라 IT 업계에서는 기획단에서 작업하는 부분이다.

이 부분 역시 마찬가지. 위와 같은 업무도 국내에서는 주로 기획직군이 담당한다.

이처럼 이 책에는 기획 직군의 종사자들이 알아야 하는 내용도 많이 다루고 있다.

앞서 한 번 언급했지만, 외국에서는 프로덕트 디자이너가 기획자의 역할을 수행한다. 좀 더 엄밀히 말하자면, 외국계에서는 기획자라는 별도의 포지션이 없고, 디자이너가 기획 직무+디자인 직무를 모두 담당하고 있는 것.

그러니 이 책의 저자가 외국인이라는 점에서 이 책에 기획 직무의 내용과 디자인 직무의 내용이 모두 함께 들어있는 것은 정말 자연스러운 일이다.

 

책의 구성

이 책의 원제는 다음과 같다.

"Solving Product Design Exercises"

그렇다. 사실 애초에 이 책은 제목부터가 "프로덕트 디자인 예제 풀이"였다. 그래서인지, 이 책은 디자인 실기테스트 완전정복이라는 목표 아래, 몇 가지 예제들을 풀이하면서 내용을 이끌어 나간다. 이러한 구성은 사실 개발IT서적에서는 흔한 전개이기도 하다. 개발 목표를 구체적으로 정해두고 이를 구현할 수 있는 코드를 보여준 뒤, 코드 리뷰를 서술하는 식으로 전개되는 것이 일반적인 개발IT서적의 전개이기 때문이다. 개발IT서적을 자주 접해본 나로서는 책의 구성 자체가 매우 친숙해서 편하게 받아들일 수 있었다.

아래는 이 책의 최상위 목차구조이다.
여기서 왜 2번 목차에서만 '프로덕트'가 앞에 붙었는지는 의문. 아마 편집상 '프로덕트'를 넣고 빼고를 반복하다가 실수가 난게 아닌가 추측..

1. 디자인 실기 테스트 완전 정복: 이론편
2. 프로덕트 디자인 실기 테스트 완전 정복: 실전 풀이편
3. 디자인 실기 테스트 완전 정복: 예제편
4. 디자인 실기 테스트 완전 정복: 인터뷰어편
5. 디자인 실기 테스트 완전 정복: 예제 총괄편
6. 디자인 리더들의 현실 조언
7. 추가 리소스
8. 디자인 실기 테스트 캔버스

위 목차를 보면 알 수 있지만, 이 책에는 인터뷰어 편도 있다. 이 부분은 인터뷰이 입장에서는 '출제자의 의도'를 조금이나마 엿 볼 수 있는 부분이 될 것이다. 그리고 개인적으로는, PM으로서 또 인터뷰어로 직무 면접을 봐야할지도 모르는 사람으로서 그동안 직무 면접의 설계와 고려사항에 관해서는 정제된 지식을 단 한 번도 접할 수 없었던지라 매우 흥미로웠다. 분량이 너무 짧아서 아쉬웠지만 그래도 큰 틀에서 어떤 점들을 고려해서 직무 면접을 구성해야할 지는 대략적으로 다 나와있었기에 정말 많은 도움이 되었다. 아무래도 이 책이 인터뷰어보다는 인터뷰이를 위한 책이다보니 분량 조절을 한 느낌.

300x250

자주 꺼내어 볼 것 같은 책

이 책을 처음 받았을 때, 얇고 글씨도 컸기에 정말 빠르게 1회독을 끝냈었다. 그동안 리뷰를 진행한 책들 중 가장 빠르게 다 읽은 책이 아닌가 싶다. 하지만, 시간이 지나면서 문득문득 이 책에서 참고하고 싶은 부분들이 떠오르는 경험을 했다.

정확히는 책 내용 중에서 정석대로 차근차근 기획을 빌드업하는 과정과 그 과정에서 어떤 산출물을 내놓는지를 참고 하고 싶었다. 나는 시드 ~ pre A 단계의 소규모 스타트업에서만 경험을 쌓아왔으므로 나 이외의 기획자들이 어떻게 일하는지 직접 본 적이 없다. 그런 점에서 책으로 출판된, (비록 예제이다보니 디테일하지는 못했지만) 스탠다드한 산출물을 엿볼 수 있는 것은 내가 만든 기획 산출물의 장단점과 보완점을 체크하는데 많은 도움이 되었다.

이런 점에서 나처럼 소규모 조직에서 거의 유일무이한 기획자로만 일해본 사람들에게는 이 책이 많은 도움이 되지 않을까한다. 

마지막으로, 기획 직무쪽으로도 이제 개발IT서적들처럼 많은 책들이 나왔으면 한다.
PM쪽으로 커리어를 전환하면서 느낀 점이 책으로 정제된 필드 지식이 너무 귀하다는 점이었다. 인터넷에 검색하면 파편화된 정보들을 접할 수는 있지만, 이런 정보들은 하나같이 '정보 조각'에 지나지 않는다. '기획'을 주제로 하여, 한 명의 혹은 소수의 저자가 처음부터 끝까지 완결성 있게 정리하고 정제하여 걸러낸 책이 좀 더 많아지길 희망해본다.

내가 써볼까...