• 이 책은 한빛미디어의 «나는 리뷰어다» 이벤트로 받은 서적입니다.

[…] CTO는 관리 직무이기도 하다. […] 다시 말해 그 비즈니스에 적극적으로 달려들 대규모 팀에 대한 모든 책임을 지고 싶지 않다면, CTO는 당신에게 맞는 직무가 아니다.

1

먼저 이 책의 저자인 카밀 푸르니에(Camille Fournier)는 Rent The runway의 CTO이자, 골드만삭스의 부사장을 역임했던 인물이며 아파치 주키퍼의 커미터다. 쉽게 말해서 관리자(CTO), 비지니스 이해관계자(부사장, Stakeholder), 개발자(커미터)임을 기억하고 읽어야 한다.

만약 이 사전 지식없이 책을 읽으면 엄청난 꼰대가 말도 안되는 소리 한다는 느낌을 받을 수 있다.

2

책의 전반적인 내용 중에서 약 1/3은 충불히 줄일 수 있을 것 같은 느낌이다. 왜냐하면 비슷한 이야기가 반복해서 나오는 경향성이 있다. 그리고 국내 상황과 비교해서 적절한지 묻지 않을 수 없다. 예를 들어 «1장 IT 관리 101»에서 아래와 같은 구절이 나온다.

매니저가 문제를 해결해주길 바라는 대신 매니저에게 문제 접근 방식에 대한 조언을 구하자. 조언을 구하는 것은 존중과 신뢰를 표현하는 좋은 방법이기도 하다.

책에 서술한 바와 같이 조언을 구하는게 존중과 신뢰를 표현할 수 있지만 과연 해당 매니저가 존중과 신뢰를 할 지 아니면 일을 떠넘긴다고 느낄지는 Case by Case 경향이 강하다. 그러니 이 책을 수용하는 독자는 이 분이 주로 근무하시는 곳이 ‘미국’임을 잊지 않아야 하며 환경이 사뭇 다르다는 점도 사전에 알고 있어야 한다.

3

반면 이 책의 전체 분량 2/3에 대해서 한 마디로 정의하면 ‘우린 문제를 해결하기 위해 존재한다’라는 명제를 계속해서 주장하고 있다는 점이다. 이게 일반적인 관리자를 위한 에세이와 사뭇 다른 점이다.

그러나 기술적으로 뛰어난 것과 좋은 테크리드가 되는 것은 직접적인 관련이 없다. […] 기술적인면과 팀 전체 요구사항 사이의 균형을 잡는 방법을 찾아야 한다. « 3장. 테크리드 »

테크리드라는 역할은 코딩을 해야 하지만 너무 많이 해서도 안 된다. 마술사가 모자 속에서 토끼를 꺼내듯이 해결책을 내놓고 싶더라도 우선 문제를 알릴 줄 알아야 한다. « 3장. 테크리드 »

제품 매니저가 주장하는 엄청난 아이디어를 시스템에서 구현할 수 있을지를 평가하는 데 스스로 확신이 있다면 상황을 관리하기가 엄청 쉽다. « 5장. 팀 관리 »

매니저가 되기 전에 충분한 시간을 들여 반드시 프로그래밍을 숙달하기를 권한다« 6장. 여러 팀 관리 »

훌륭한 디버깅이 관리와 무슨 관련이 있을까? […] 이 블랙박스는 눈으로 확인 가능한 입력과 출력이 있지만, 출력이 예상과 다를 때 그 이유를 살펴보려면 블랙박스를 열어 내부적으로 어떤 일이 벌어지고 있는지 보아야 한다. « 7장. 매니저 관리»

인용 구문에서 볼 수 있듯이 뭔가를 관리하는데 집중하는 것 같지만, 그 관리의 목적이 ‘비즈니스 문제’를 해결하기 위한 관리라는 것을 암묵적으로 전제하고 있는 듯 하다.

4

임백준님을 비롯한 다른 분들의 에세이도 실려있는데, 이런 점은 매우 훌륭하다. 왜냐하면 책일 읽으면서 미묘하게 느껴지는 이질감을 해소시켜 줄 수 있고, 기고자와 글쓴이가 묘하게 대립되는 주장을 하고 있는 부분이 있는데 이런 대립되는 주장에 대해서 다시 생각해 볼 수 있는 기회를 주기 때문이다.

5

비슷한 내용이 많아서 조금 늘어지는 감이 있지만, 책의 내용이나 글쓴이의 견해가 매우 명쾌하기 때문에 회사에서 어쩔 수 없니 매니저 업무를 진행해야 된다면 참고하면 좋을 책이고, 개발을 처음 시작하는 분들에게도 좋은 책이다. (초입개발자는 이 책을 읽고 여러분의 매니저가 어떻게 행동하는지 관찰해보면 좋지 않을까?)