73. 인스파이어드 - 마티 케이건

이 책은 세번이나 읽었다. 처음 읽은 건 2010년대 말이었는데 - 내가 2017년에서 2019년까지 다닌 회사에 있을 때 이 책을 알게 됐으니 그 중 어느 때일 것이다 - 회사에서 PM 직군에게 필독서라며 이 책과 다른 책 두 권을 돌렸다. 나는 PM 직군은 아니었지만 옆에서 동료가 읽는 걸 보고 '대체 어떤 책이기에 그 정도야?' 라는 궁금증에 읽었다. 두 번째 읽은 건 2021년이었는데, 업무상 어쩌다 PM 업무를 하게 되어 '이 책이라도 참고하자' 싶어 다시 읽었다. 그리고 세 번째 읽은 게 25년 6월이다. 높은 확률로 다시는 PM할 일이 없을 거 같은데 이 책을 나눔할까? 그 전에 한 번 더 읽어볼까? 라는 생각으로 읽었다.

 

총평을 먼저 하자면 '이론적으로 완벽한 책' 이라고 하겠다. 이 책에 있는 말은, 특히 PM을 해보고 여러 회사를 경험해보니 구구절절 옳다. 이 책에서 제시한 것처럼 일한 회사들이 확실히 잘 되는 경향이 있었다. 다만 '이론적으로' 라고 단서를 붙인 이유는 현실적인 이유로 이 책에서 제시하는 대로 완벽하게 할 수가 없기 때문이다. 역설적으로 그래서 PM의 필독서일지도 모르겠다. 교과서 같은 책이라고 해야하나? 굉장히 이상주의적이고 무엇보다 '사업 직군'의 영향력을 너무 간과한 느낌이 든다.

 

그래서 자신이 맡은 프로덕트가 잘 되게 하고 싶은 PM이 이 책을 읽는다면 현실과 동떨어진 부분에 대해 어떻게 적용하면 좋을지 고민하게 될 것이다. 다만 PM이 판단할 때 조직에서 어떤 점만 개선하면 이 책에서 제시한 것처럼, 혹은 최대한 비슷하게라도 할 수 있을 것 같은데 윗선에서 No 해서 시도조차 할 수 없는 상황이라면 그 리더 밑에 계속 있는 게 맞는가, 혹은 그 회사를 계속 다니는 게 맞는가 진지하게 고민할 필요가 있다고 생각한다. 이 책과 그나마 가장 흡사하게 개선하려고 노력이라도 한 회사는 지금 꽤 잘 되고 있다. 하지만 어떤 개선을 시도할 때 그것이 잘 되지 않는 회사는 역시나 잘 되지 않고 있다.

 

이 책에 대한 가장 큰 아쉬움은 번역이다. 번역이 좀 직역체인 듯한 부분이 있어 처음 읽을 때 매우 어색하다고 느꼈다. 지금도 어색하게 보이지만 이 책을 세 번 읽다보니 어느 정도는 익숙해진 면이 있다. 그 다음 아쉬운 부분은 목차 구성이다. 크게 다섯 개의 파트가 있고 파트 하위에 챕터가 나열된 형태인데, 몇 개의 챕터는 하나의 묶음으로 묶을 수 있다고 느꼈다. 기계적으로 파트(대분류) - 챕터(소분류)로 하지 않고, 파트 - (필요시 중분류) - 챕터 이런 식으로 하면 더 좋았을 거 같다. 특히 파트 3과 파트 4에서 그렇게 느꼈다.

 

---

 

각 파트에 대해 느낀 점을 간단히(?) 남겨보려고 한다.

 

파트 1

어찌 보면 뻔한 내용이다. IT 회사를 좀 다녔거나, 이런 류의 책을 읽어봤다면 익숙할 내용이다.

 

파트 2

제품팀의 중요성, 그리고 각 담당자들의 R&R에 대해 다룬다. 이론적으로는 꽤 괜찮지만 이 책에서 다루지 않은 직군과의 트러블 - 특히 사업 직군에 대해 지나치게 순진하게 접근한 느낌이다. 제품 관리 리더의 중요성에는 공감하지만 사업 리더와 제품 리더가 충돌하고 해결이 잘 될 경우 업무 진행 역시 속도가 더뎌지고 사업 쪽 의견에 무조건적으로 따르게 되면 기술 부채가 엄청난 속도로 쌓이게 된다. 그런 면에서 비즈니스 관점을 너무 가볍게 본 느낌이다.

 

파트 3

로드맵의 문제점을 다루고 제품 비전, 목표 등에 대한 중요성을 언급한다. 그러나 몇 번을 다시 읽어도 왜 로드맵이 문제인지 잘 모르겠다. 저자가 우려하는 것처럼 로드맵에 목숨 거는 타입의 회사가 그렇게 흔한지 잘 모르겠다. 간격이 아무리 넓어도 분기마다 재점검하고 수정하곤 했던 거 같은데. 개인적으로는 이 파트 중후반에 나오는 OKR이 로드맵보다 더 별로라고 생각한다. (경험이 좋지 않았다는 뜻이기도 하다.)

 

파트 4

각종 프로세스를 소개하고 그 기법에 대해 자세히 다룬다. 하나의 정답이 있는 프로세스는 아니라고 강조하는데 공감한다. 보통 IT 기업의 평가에 흔히 나오는 말이 '체계가 없다'는 불평인데, 과연 좋은 체계란 무엇인가? 내가 경험한 IT 회사들의 체계는 보통 조직의 목표가 있고 그 목표를 향해 가는 과정은 자율에 맡겼고 이게 '체계가 없다'는 것과 연결된다. 그러나 너무 강한 체계는 이 책에서 언급한 것처럼 혁신을 멈추게 하기 때문에 '안정보다 도전'이 중요한 IT 업계 특성상 '체계 없어 보이는' 모습을 수용할 필요가 있다고 생각한다. 다만 '목표에 대해 각자 자율적으로 달성하라' 해놓고 '목표 달성에 대한 책임만 있고 과정에 대한 권한(자율)은 없는' 회사/조직이 간혹 보이는데 이런 곳은 빨리 탈출하는 것이 답이라고 생각한다.

 

파트 5

대체적으로 공감했다. 특히 '혁신/속도를 잃는 이유' 쪽에서 공감이 많이 됐다. 제품 문화 구축은 회사가 커질수록 어려운 일이기 때문에 제도적 변경을 통한 문화 혁신은 탑다운으로 하는 방향도 고려할 필요가 있는 듯 하다.

 

---

 

나는 경험적으로 이 책에 대한 이런 결론을 내렸지만 과연 지금도 이 책이 각광받는가 궁금해서 알라딘 서점에서 검색을 해보았는데 여전히 잘 나가는 모양이다. e비즈니스/창업 주간 23위, 컴퓨터/모바일 top100 19주라고 표기된 걸 보니 말이다.

내돈내산이자 내가 쓴 독후감/서평/책 리뷰 73편 : 인스파이어드 (마티 케이건 저)