많은 개발자들이 연차가 쌓여가면서, 주니어에서 시니어 개발자, 시니어 개발자에서 팀장, CTO 등으로 성장하게 됩니다.

개발실력은 연차가 쌓여가면서 서서히 올라가게 되는데, 인력과 사람을 대하는 능력은 과연 어떨까요? 코드로 이야기하고,

코드로 답하는 개발자들은 이렇게 이야기 하곤 합니다. 나는 앉아서 코드 짜는 것만 시키면 정말 좋겠는데...

회사라는 조직은 사람들이 어떤 목표를 향해 각자의 역량을 최대한 집중시키는 곳이라고 할 수 있습니다. 그 안에서 팀의 

방향을 결정하는 매니저의 역할이 중요하다는 것 두말할 나위가 없습니다. 그런데.. 특히 개발이라는 분야에서 매니저가 

되기 위해서는 어떻게 해야 하는 것일까요? 오늘 리뷰할 이책에서 답을 찾을 수 있게 되길 기대해봅니다.

1. 매니저, 생각보다 신경쓸 것이 정말 많다.

이 책을 옮긴 권원상 님은 앞부분에서 이렇게 이야기 하고 있습니다. '프로젝트 매니저를 처음 맞게 되었을 때, 문제가 있는

프로젝트에 투입되어 관리를 시작해야 하는 상황이었다. 당시 같은 직책을 가진 사람이 혼자였기 때문에 함께 이야기 나눌

사람이 없어 아쉬웠다.' 그렇습니다. 개발자에게는 항상 프로젝트 매니저라는 직책 어느 순간 훅다가오게 됩니다. 

    개발 연차가 쌓이고, 맞고 있는 프로젝트에 대해 가장 잘알고 있거나 혹은, 여러 프로젝트를 경험했다는 이유로, 매니저를

시키는 거나, 나이가 많다는 이유로 매니저를 시키는 등, 예측 할 수 없는 상황에서 프로젝트 매니저를 맡게되는 상황이

많습니다. 처음부터 프로젝트 매니저를 해야겠어! 하고 이 분야에 뛰어드는 사람은 많지 않을 것입니다. 이 책에서는

프로젝트 매니저에 대해서 여러 상황별로 설명하고 있습니다. 독자가 어느 정도 레벨인지, 또는 어떤 상황에 처해 있는지,

혹 어떤 것이 우리 프로젝트에 가장 필요한 것인지를 판단하여, 장별로 읽는 것을 추천하고 있습니다. 

또한 장별로 섹션이 있는데, 'CTO에게 묻는다.'  라는 색션은 프로젝트를 진행하면서 실제 일어날 수 있는 상황에 대해

소개하는 색션이 있습니다. 이 색션을 보면서, 아 실제로 이런 상황이 벌어 질수 있겠구나, 이런 상황에서는 이렇게 대처하면

도움이 되겠구나. 라는 것을 간접적으로 체험할 수 있었습니다. 비슷하게는 도전 상황 이라는 섹션도 있습니다. 역시 프로젝트

진행  시 흔하게 맞닥드릴 상황을 먼저 이야기하고, 이런 경우에 어떻게 대처하면 좋을 지에 대해서 소개하고 있습니다.

    '좋은 매니저, 나쁜 매니저' 라는 색션에서는 어떤 매니저가 좋은 매니저이고, 어떤 매니저가 나쁜 매니저이며 각 매니저의 대처로

프로젝트가 어떻게 흘러가게 될지를 소개하고 있습니다. 이 섹션을 읽으면서는 나는 누군가에게 코칭, 또는 조언을 할 때

어떤 사람이었나 인가를 되돌아 보게 되어서, 참으로 나 자신을 돌아보게 되는 좋은 효과가 있었던것 같습니다.

2. 총평

    이 책을 읽으면서, 나늘 거쳐갔단 매니저들은 좋은 매니저였을까? 나쁜 매니저였을까? 되집어 보기도 하고, 그들에게

나는 어떤 팀원이었을까? 하고 생각해보기도 하는 야릇한 경험을 선사해 주는 책인것 같습니다. 개발자 누군가는

 좋은 개발자는 물론 코드도 잘짜는 것이 먼저이겠지만, 결국에 더 높은 연봉과 대우를 받기 위해서는 사람과 프로젝트를 관리하는 능력을

갖추는 것이 우선시 되어야 함을 이시대를 살아가는 개발자들이라면, 인지하고 있다고 생각합니다. 시간이 흘러 언젠가는 매니저의 직책을 갖게 될 때를 대비하여 미리 읽어두면 참 좋은 책이라고 생각합니다.



개발일을 하고 있지만 언젠가는 매니저(관리자) 일을 해야한다는 불안감을 가지고 있었다.

그게 연차가 쌓일 수록 더 많은 고민이 되는 것 중에 하나다.

막연히 쉽게 생각하면 그냥 관리잖아라고 생각할 수 있지만, 아니라는 것을 알고 있다.

잠깐이긴 했지만 개발 4년차가 지나고 Pm(프로젝트 매니저)를 한 경험이 있었다.

그 시작은 얼떨떨했고, 마지막은 너털너털해졌다.

개발일을 할때보다 몸과 마음이 더 힘들었다.

프로젝트의 시작과 끝에는 매니저가 있어야 했고, 당연히 업무스케줄링 과 사람들 관리를 함께 하는 것이다.

그래서 더 어렵고 무섭다고 생각을 하게 되었다.

개발일은 내가 해내면 되지만, 매니저라는 일은 사람들에게 일정을 맞추도록 이야기 하고 성과물을 가져와야 하는 것이다.

당연히 답답함은 2~3배 더하다.

스케줄이 어긋나버릴 경우.. 다음 스케줄링을 다시 해야한다.

하지만 그런 것들이 다른사람들에게는 보이지 않는다.

그냥 당연히 해야할 것들이라고 생각하고, 자연스럽게 흘러가는 과정이라고 생각한다.

하지만 더 큰 문제는 매니저라는 일의 중요성도 모르지만,

무슨 일을 해야하는지를 모른다는 것이다.

그래서 "개발 7년차, 매니저 1일차"는 꼭 읽어보았으면 한다.



이책은 1장부터 9장까지 구성되어 있다.

1장은 매니저의 역할과 매니저에게 사람들이 기대하는 것이 무엇인지를 알려준다.

2~3장은 멘토링과 테크리드, 어려워 보이지만 프로젝트를 진행하는 과정이라던가, 인력관리하는 방법을 알려준다.

4~7장은 직원을 관리하고, 팀을 관리하고, 또 여러 팀을 관리하는 방법에 대해서 알려준다.

8장은 시니어 리더십에 대해서 알려준다.

9장은 문화를 수립하고 수정하고 향상시키기 원하는 사람들을 위한 내용에 대해서 알려준다.

사실 개발자가 무슨 매니저(관리저) 책을 읽어 라고 생각하겠지만,

매니저역할을 하지 않더라도 그 사람을 이해하는데 큰 도움이 된다.

알다싶이 프로젝트는 혼자만 잘 한다고 이루어지지 않는다.

팀단위로 하는 것이 많기 때문에 매니저의 역할을 이해하고, 돕는 것도 중요하기 때문이다.

막상 내가 그 역할을 해야한다고 하면 더 멘붕일 것이다.

주니어개발자와 시니어개발자의 룰과 책임감이 다르듯,

매니저도 마찬가지다.

개발자가 없으면 프로젝트가 안돌아가듯이, 매니저 또한 마찬가지다.

전체적인 흐름이 잘 돌아갈 수 있도록 하는 것이 매니저의 롤이기 때문이다.

미리 책을 읽고 매니저가 되는 방법(사실 언제 될지 모른다)에 대해서 대비하기 위해 책을 읽는 것도 좋지만,

또 지금 있는 매니저와 잘 지내는 방법을 아는 방법 중 하나이지 않을까 싶다.

IT 업계에 종사하고 있는 엔지니어(소프트웨어 엔지니어를 위시한 직군)는 주니어에서 시니어 레벨을 거쳐 언젠가는 매니저 직급에 이르게 된다. 이것은 피할 수 없는 숙명이다. 그런데, 언제라도 제대로 된 매니저 훈련을 받은 적이 있는가? 아니 매니저가 되는 트레이닝을 회사에서 제대로 가르쳐 준적이 있는가? 매니저는 탄생하는 게 아니라 만들어 지는 것인데 과연 그 과정이 순탄하기만 할까? 그렇다면 어떻게 해야 매니저가 될 수 있고 더 좋은 매니저가 될 수 있을 것인가에 대한 물음에 좋은 길잡이 역할을 해 주는 책을 소개할까 한다. 한빛미디어에서 출판 된 '개발 7년차, 매니저 1일차'라는 책이 바로 오늘의 주인공이다.

책 중간 중간에 'CTO에게 묻는다' 라는 코너가 마련 되어 있는데, 원 저자의 생생한 경험이 온전히 녹아 있는 핵심 중의 핵심 가이드라 하지 않을 수 없다. 

우선 이 책은 외서를 번역한 서적이지만 번역서 특유의 매끄럽지 못한 구조가 전혀 없고 군더더기 없이 잘 된 번역을 기반으로 구성 되어 있기에 소설책 읽듯이 술술 읽을 수 있는 재미가 쏠쏠하다. 부담 없이 읽을 수 있는 재미와 저자의 경험이 반영 되어 있는 스토리를 따라 읽어 내려 가면 어느새 책 한 권 완독에 이르게 되는 경험을 맛 볼 수 있다. 

각설하고 본 서적은 총 10장으로 구성 되어 있고, 각 장의 대주제를 기반으로 하여 다양한 실무 경험담을 저자가 서술해 나가고 있다. 

1장의 IT 관리를 시작으로 하여 매니저의 본질이 무엇인지에 대해 이해할 수 있는 시간을 갖게 된다. 매니저에 요구 되는 자질과 매니로서 갖춰야 할 덕목등에 대해 다시금 생각할 수 있는 소중한 기회를 얻을 수 있다고 할까?

2장의 멘토링은 매니저로서 팀원들에게 어떻게 멘토링을 해야할지에 대한 깨알같은 꿀팁을 제공하고 멘토링의 정수를 맛보게 된다. 이 장을 통해 훌륭한 매니저는 반드시 훌륭한 멘토여야 한다는 걸 깨닫게 되었다.

이윽고 각 장을 거쳐 9장에 이르러서는 문화가 언급 되는데, 결국 조직의 힘은 좋은 문화에서 비롯한다는 걸 새삼 깨닫게 된다. 좋은 문화에서 좋은 조직이 구성 될 수 있고 좋은 매니저와 좋은 팀원이 만들어 지는 것은 너무나 당연한 사실 아닐까?

10장의 결론 파트에서 결국엔 관리의 주체인 '나'에 대해 미시적인 관점에서 바라 볼 수 있는 시간을 갖게 된다. 나라는 개체가 온전히 관리 되지 않고서 누구를 관리할 수 있을까? 나와의 내밀한 대화를 통해 다시 한번 나 자신을 진정으로 관리할 수 있을 때, 팀원들을 관리하고 조직을 관리할 수 있는 훌륭한 매니저로 거듭날 수 있는 변곡점이 되지 않을까 싶다. 

P.S :   
한빛미디어 '나는 리뷰어' 이벤트에 당첨 되어 제공 받은 도서를 바탕으로 작성된 후기입니다.

저는 현재 25년차 IT 프로젝트 매니저 일을 하고 있습니다. 관리와 개발을 동시에 수행해야하는 역할 때문에 저자의 지식과 경험이 간접적이지만 큰 도움이 되었습니다.

이 책은 제목처럼 프로젝트(IT) 매니저로서 역할과 책임 그리고 팀과 함께 성장할 수 있는 다양한 주제를 다룬 책입니다. 

다양한 주제와 더불어 가장 현실적인 실천 방법이 소개되어 있어 현업에서 매니저 일을 하고 있는 분들이나 이제 매니저 일을 시작하는 분들께 현실적이고 실질적인 도움이 될 것 같습니다.

이 책에서 언급되는 매니저는 한국에서 CTO, 팀장, 파트장, 본부장 등 다양한 직책으로 정의가 되는데 의미가 조금 다르게 해석될 뿐 결국 하는 역할은 동일합니다.

IT 관리, 멘토링, 테크리드, 사람관리, 팀 관리, 여러 팀 관리, 매니저 관리, 문화개선 등 매니저 역할을 수행하다 보면 반드시 한번은 겪게 되는 고민을 파트별로 나누어서 가이드하고 있습니다.

중소기업이나 소기업에서 일종의 테크리드를 담당하고 계시는 분들이라면, 2장의 멘토링, 3장 테크리드, 5장 팀관리 그리고 좀 여유가 있다면 9장 문화 개선 파트에서 좀 더 나는 팀운영 대한 힌트를 얻을 수 있습니다.

특히 개발과 관리를 병행하거나 개발자에서 관리자로 직무를 변경해야하는 분들께 214페이지의 ‘매니저직은 개발자의 무덤인가”을 꼭 읽어 보시라고 권장합니다.

시니어의 시선을 간접적으로 느낄 수 있는 책이라 재밌게 읽었습니다.

쉬는타임으로 한번 읽어봐도 괜찮은 내용인거 같아요.

지난달 말 회사의 연구소장님과 일부 인원들과 함께 점심 간담회를 한 적이 있다. 연구소장님은 개발자들이 자신의 캐리어 패스를 적을 때 매니저 트랙을 선택하지 않는지 궁금해하셨다. 그렇다. 대부분 개발자들은 매니저가 되는 것을 싫어한다. 

대답은 이러했다. 매니저를 보면 이슈와 보고를 대응하느라 너무 바쁘다. 하루 종일 회의다. 얼굴 보기도 힘들다. 어려운 이슈나 문제를 해결해주지 못한다. 자료만 만들고 윗분들에게 보고만 한다. 개발에서 손 놓은지도 오래다. 힘들기만 하고 얻는 게 없어 보인다. 개발자 트랙을 유지하고 싶은 이유는 개발하는 것은 어려운 기술적인 문제를 풀어가면서 실력이 늘어가는 것을 느끼는 것에서 희열과 개발자로서 자부심을 느낀다. 

하지만 여차 저차 한 이유로 개발자에서 매니저로 승진한다면 그동안 욕했던 매니저의 모습을 내가 하고 있을 수 있다. 어떻게 하면 좋을지 잘 모르겠는 경우가 있을 거다. 

<<개발 7년 차, 매니저 1일 차>> 는 개발자에서 매니저가 막 되어서 이런저런 고민들이 많은 사람들, 혹은 앞으로 매니저가 되고 싶은 사람들, 혹은 매니저가 되지 않더라도 내 매니저는 어떨까 생각해볼 사람들에게 유용하다. 내용은 궁금한 점을 찾아 읽기는 좋지만 큰 흐름이 있지는 않다. 작가는 장별로 읽는 법과 매니저의 경력에 따라 어떤 챕터를 먼저 읽으면 좋을지 가이드라인을 제시한다. 이 책의 저자는 카미유 푸르니에로 패션계의 넷플릭스로 불리는 의류 대여 회사인 Rent the Runway의 전 CTO다. 미국 회사라 우리와는 다른 회사 문화일 것이라 생각하지만 읽어보면 글로벌 시대고, 사람 사는 곳의 문제는 다 비슷하다는 공감을 얻을 수 있다. 

좋은 테크 리드 또는 좋은 매니저를 만나기란 쉽지 않다. 이 책은 그 이상적인 모습이 무엇인가 생각할 기회를 주는 책이다. (이 책에서 말하는 테크 리드는 두 명에서 열 명 규모의 개발 팀을 책임지는 팀장으로 관리와 개발 업무를 병행한다.)

뛰어난 기술 매니저란? 

작가가 말하는 좋은 리더는 의사소통에 능숙하고, 문서 작성도 깔끔하며, 발표도 잘한다. 다른 팀이나 다른 역할의 사람과 소통하기 즐기며, 업무 진행 상황을 정확히 파악하고 설명한다. 우선순위를 정하는데도 능숙하며, 업무를 추진하며 다음 할 일을 결정하는 것을 좋아하고 추진력이 강하다. 또한 사내 정치도 잘해서 자신의 팀원을 돋보이게 하고 키우는 역할을 잘하는 사람이다. 

이 책을 읽으면서 처음 알게 된 것은 RTR(Record to Report) 기술에 따라 팀 멤버를 관리해야 한다는 것이다. 

-정기적인 원온원 미팅 (주 1회) 

-경력 성장, 목표 진행, 개선된 영역 및 명시적인 칭찬 등에 대한 정기적 피드백

-프로젝트 업무, 외부 교육 등 멘토링 등을 통해서 팀원의 성장을 돕는 교육과 지원 보고서 작업

프로젝트 관리를 위해서는 

대부분 매니저들이 잘 알 것 같지만 저자가 말하는 방법을 나열해 본다. 저자가 말하는 프로젝트 관리란 "복잡한 최종 목표를 작은 일로 나누고, 이 일을 끝내기 위한 가장 효과적인 순서로 배치하고, 병행 처리할 일과 순차 처리할 일을 찾아내고, 프로젝트 진척 속도를 늦추거나 실패하도록 하는 원인을 찾아 제거하는 것"이다. 저자가 제시하는 가이드라인은 다음과 같다. 

1) 작업을 잘게 나눈다.

2) 일을 어렵게 만드는 세부 사황과 문제가 될 수 있는 부분은 끝까지 신경 쓴다. 

3) 프로젝트를 시작하고 진행하며 계획을 수정한다.

4) 계획 프로세스에서 얻은 통찰로 변경된 요구사항을 관리한다. 

5) 프로젝트 완료 시점이 가까워지면 세부사항을 다시 검토한다. 

후배들을 위해서는 

좋은 매니저가 된다는 것은 기술적으로 가장 뛰어나야 한다는 의미는 아니었다. 사람들을 돕는 일이 매니저로서 성공하는 데 훨씬 중요하다. '현대의 소프트웨어 개발은 팀 스포츠'이다. 매니저는 '코치'이자 '지지자'가 되는 것이 가장 좋다고 저자는 말한다. 이 책 중간에 기고자의 글도 있는데, 임백준 저자의 말이 가장 기억에 남는다. 

"좋은 매니저는 착한 사람도 능력 있는 사람도, 정치를 잘하는 사람도 아니다. 좋은 매니저는 후배를 성장시키는 사람이다. 후배들의 앞길을 있는 힘을 다해 열어주고, 이끌어주고, 밀어주는 사람이다. 그게 좋은 매니저다."

자신을 위해서는

기술 역량을 유지하자. 사실 지금 세계 최고 회사를 보더라도 CEO는 모두 다 엔지니어 출신이다. 개발자가 매니저가 되는 것이 꼭 개발 커리어를 멈추는 일만은 아니다. 매니저가 되었다고 개발자 무덤에 갔다 생각하지 말고 기술 역량을 유지하자. 저자는 그 이유를 이렇게 말한다. 

"기술 관리는 단순히 사람을 관리하는 방법을 모은 것과는 다른 기술적인 분야다. 경력 개발 과정에서 코딩은 하지 않더라도 기술적 의사 결정을 해야 하는 역할이기 때문이다. (중략) 

팀 매니저로서 아키텍트나 시니어 기술 담당자가 자신의 결정에 책임을 지도록 하고, 기술적인 문제가 없는지 확인하고, 팀과 비즈니스라는 맥락에서 균형을 맞추는 것이 기술 매니저의 업무다. 몇 년에 걸쳐 쌓인 숙련된 기술적 감각은 이런 과정에서 매우 중요하다."

정말 일반 매니저가 되는 것도 어려운데 기술 매니저는 그 어려운 것을 다 해내야 한다. 그 쉽지 않은 길을 가는 분들의 앞길이 꽃길만 가득하길. 

지금은 다소 `매니저`와는 거리가 먼 위치이지만, 소프트스킬에 관해 얻는게 있을 것이라는 기대로 시작했다.  

근데 의외의 부분에서 인사이트를 얻을 수 있었다. 

책에서는 성공적으로 매니징하는 법을 소개하지만 역설적으로 성공적으로 매니징되는 법을 얻을 수 있었다. 

몇 가지 keep해둔 부분을 남긴다.

> 프로젝트 관리에 대한 부분에서 

`.. 어떤 이유에서든 한 번 또는 두 번의 스프린트만으로 완료할 수 없는 프로젝트가 있기 때문이다. 팀을 관리하기 위해서는 프로젝트 기간을 추정해야 하며 왜 오랜 시간이 필요한지를 자세하게 정리해야 한다. ... '계획의 가치'는 실제 업무를 시작하기 전에 스스로 프로젝트를 어느 정도까지 깊이 있게 생각할 수 있는지에 있다.`  

-> 단순한 ideation에서는 잘 보이지 않는 부분이 많다. 스스로 더 깊이있게 검토하는 부분을 강화해야겠다고 생각했다. 

> 설명의 중요성에 대한 부분에서 

`우리는 기술자로서 우리가 한 일을 매니저가 당연히 '알고 있을 것'이라고 생각한다. "매니저님, 그냥 코드를 보시면 돼요!"라고 한다. ... 무엇보다 이런 노력이 결국 우리에게 좋은 변화를 가져온다. 시간을 들여 설명하는 건 매우 중요하다.`

-> 설명의 중요성에 공감했다. 상대방이 당연히 알 것이라는 편견, 내가 모를 때도 상대방의 자세한 설명에 감사할 때가 많았다. 

> 기고글 중에서 

`전에 비해서 달라진 것은 단순히 기술의 다양성이 아니었다. 코딩 실력도 아니었다. 맥락에 대한 이해와 통찰이었다.`  

-> 요 부분에서 이것이 인사이트의 역할이구나 하는 깨달음을 얻었다. 

우리 모두 시니어 엔지니어로 성장한다면 갑작스럽게 여유없이 매니저의 역할을 맡게 될 수도 있기 때문에 시기에 관계없이 언제든 읽어볼만한 책이라고 생각한다. 

나에서는 역시 아직 먼 이야기였지만 오히려 책임감은 내려놓고 호기심을 가지고, 매니저들이 가질 만한 고민이나 역할에 대해 구경해 볼 수 있었다.

이 책은 카미유 푸르니에라는 패션계의 넷플릭스로 불리는 의류 대여 회사, 렌트더런웨이의 전 CTO가 쓴 책이다. 저자는 미국 회사에서만 근무해본 개발자라 미국인의 관점에서 이 책을 썼지만, 한국인 개발자들에게도 공감을 많이 불어일으킨다.

이 책은 여러 종류의 사내 위계질서와 조직 구조에 대한 내용을 담고 있고, 개개인을 관리하는 매니저에서 회사의 임원으로 성장하는 위계질서를 개발 매니저의 역할로 책에 설명하고 있다.

매지너가 정장하며 더 큰 팀에서 권력을 키워가는 부분에 초점을 맞추어 쓴 것이 아니라, 고위 임원의 역할을 맡게 될수록 책임감을 키워야 한다는 것에 초점을 맞추었다. 매니저가 되면 부하직원들 위에서 큰 권력을 가질 수 있겠지만, 진정한 힘은 직원들이 효율적으로 협력하여 좀 더 나은 결정으로 앞으로 나아갈 수 있도록 매니저가 팀을 섬길 때 생긴다고 말하고 있다.

목차는 크게 10장으로 구성되어 있다.

1장 IT 관리 101

2장 멘토링

3장 테크리드

4장 사람 관리

5장 팀 관리

6장 여러 팀 관리

7장 매니저 관리

8장 빅 리그

9장 문화 개선

10장 결론

1장은 좋은 매니저가 되기 위한 방법을 소개하고 있다.

2장은 많은 조직에서 신입 교육 프로그램으로 멘토링 제도를 운영하는데, 멘토 역할을 어떻게 해야 잘 하는 것인지 팁을 알려주고 있다.

3장은 팀 전체의 성장을 위해 기술 프로젝트 리더로 활동하면서, 대규모 프로젝트에서 자신의 전문성을 살려 팀에 기여하는 테크리드에 대해서 상세하게 설명해준다.

4장은 팀을 이끌어 가기 위해 팀원들을 고려하는 것이 중요한데, 팀원 하나하나를 관리하는 매니저로 사람을 관리하는 방법에 대해 소개하고 있다.

5장은 팀장 역할에서 기술적인 부분은 어떻게 바뀌는지, 팀 전체를 다룰 때의 어려움이 무엇인지에 대해 설명한다.

6장은 5장은 한 팀을 관리하는 부분을 다루었다면, 이번 장은 여러 팀을 관리하는 방법에 대해 다룬다.

7장은 여러 매니저를 관리하는 방법, 매니저 채용 시 고려할 점 등에 대하여 다룬다.

8장은 기술 시니어 매니저로 역할, 모델, CTO의 역할, 기술 전략 수립 노하우 등을 다룬다.

9장은 팀 문화를 만드는 시니어 개발 리더의 역할에 대해서 다룬다.

마지막으로 10장은 다른 사람들을 잘 관리하기 위해서는 나 자신을 관리할 수 있다는 부분을 강조하여 마무리를 한다.

개발자들에 대한 책이 많이 없는데, 개발자들이 관리자로 되었을 때 어떻게 해야 하는지에 대해서는 더 없는 듯 하다. 이 책은 개발자들, 개발자 출신 관리자들의 궁금증을 해소하는 책이다.

그런데, 이 책은 일반적인 자기 계발서처럼 본인의 회사 경험담으로 시작해서, 여러 단계와 필요한 상황들을 잘 나누어서 설명하지만, 추상적인 해법들이 많다. 

왜 그렇게 느껴지냐 하면, 이 책에서도 언급하듯이 모든 회사, 모든 직장내 인간관계들이 무우 자르듯이 딱 떨어지는 상황은 없기 때문이다. 

그래서 그 해법이란 것이 읽으면 다 맞는 이야기이고, 그 직책에 필요한 것처럼 느껴지지만, 사실 회사마다, 팀마다 놓여있는 문제들이란 다 다르다. 

구체적인 해결 방법이 될 수 있을지는 좀 의문이다.

평소에 남들이 가지고 있는 생각이 궁금해서 에세이를 많이 읽는 편인데 개발자라는 타이틀을 달고 있으면서도 IT 에세이는 처음 접해봤다. 이 책은 한빛미디어에서 출간된 "개발 7년차 매니저 1일차" 라는 책인데 관리자의 입장에서 "좋은 관리자는 무엇인가" 라는 물음에 대답을 해주고 있는 책이며, 관리자가 아닌 개발자도 관리자를 이해하는데 도움이 될 수 있는 책이다. 또한 개발자가 꼭 알아야하는 소프트 스킬에 대해서도 다루고 있으며, 사람 및 조직 관리를 하는데 좋을 노하우들을 담고 있다.

개발자는 언젠가 관리자가 되는 시점이 오는데, 시니어 개발자로 남을 것인가, 관리자로 사람들을 매니징할 것인가에 대한 관점도 담고 있어서 주니어 개발자들도 읽으면 미래 커리어에 큰 도움이 될 수 있는 책이다. 주니어 입장에서는 아직은 먼 미래 같지만 시간은 빠르게 흘러 가므로 눈뜨면 도달해있을 미래에 대해서 탄탄한 준비를 하는데 도움을 줄 수있는 책 같다. 주니어 입장에서 한번 읽어보고, 나중에 시니어가 되었을 때도 한번 읽으면 생각이 어떻게 바뀌었는지, 주변환경이 어떻게 바뀌었는지에 대해 깊은 고찰이 가능 할 것 같기 때문에 나중에 한번 더 읽고 싶다는 생각을 했다.

이 책은 현업자들이 집필해놓은 책이기 때문에 더 현실 고증적이며, 내가 좋아하는 개발자 중 하나인 임백준님의 기고문도 포함되어있어서 굉장히 흥미로운 책이었다. 시간이 되면 임백준의 대살개문이라는 책도 이 책이랑 같이 읽어보면 좋을 것 같다.

정리해보자면 이 책은 관리 받는 입장에서 혹은 관리 하는 입장에서의 사람 및 조직을 다루는데 노하우를 담고 있기 때문에 개발 7년차가 아니더라도 개발 1년차부터 매니저들까지 IT 생태계에서 잘 살아 남을 수 있는 방법을 담고 있기 때문에 이 책을 강력히 추천한다. 

이미 관심을 갖고 있던 책이었지만, The Manager’s Path를 구입해서 읽던 중이어서 같은 주제니까 나중에 한 번 읽어보자는 생각만 갖고 있었다(번역서인줄도 모르고…).

The Manager’s Path는 역시 영어라서 진도가 빠르지 않은 상황이었는데, 마침 기회가 되어 이 책의 첫 장을 넘기자마자 현재 읽던 책의 번역서라는 걸 알게 되었다. 제목과 표지만 봐서는 원서와는 워낙 분위기가 달라 누가 봐도 알아채긴 힘들지 않았을까?라고 스스로에게 변명을 하며, 마침 잘 됐다 싶어 단숨에 읽었다. 일단 하룻만에 한 번 다 읽고 다시 천천히 읽어봤다.

“개발 7년차, 매니저 1일차"라는 제목이 나쁘진 않지만 이제 막 매니저가 되는 사람을 위한 내용만 있다는 착각을 할 수도 있어서, 이 책의 내용을 나타내기에는 원서의 제목 “The Manager’s Path”가 더 적절하다는 생각이다.

1~4장은 하나의 팀을 관리하는 매니저에 대한 내용이다.

1장은 IT 관계 101이란 제목에서와 같이 매니저가 해야 할 가장 기초적인 내용이다. 매니저는 팀을 manage 하는 사람이기 때문에 1:1을 갖고 팀원과 인간적인 연결을 갖고 피드백을 주는 게 가장 중요하다. 팀원에게 필요나 상황에 따라 칭찬, 비판, 교육, 승진을 제공해야 하는데 중요한 점은 관계가 일방향이 아니라 쌍방향이 되야한다는 부분이다. 특히 시니어 멤버일수록 매니저에게 문제가 있는 경우 해결책을 제시하는 등 도움을 줘야 한다.

2장은 멘토링으로 인턴을 받게 되는 경우 어떻게 해야 하는지 프로젝트 선정, 듣기, 명확하게 의사소통하기 등으로 설명한다. 개인적으로는 팀원뿐만 아니라 product owner와 이야기할 때 명확한 의사 소통이 더 중요하다고 생각하는데, 얼마 전에는 자동 발송 email template을 수정하는데 포함되야 하는 문장을 일부 변경할 task가 있었다. 처음에는 간단할 거라 생각하고 시작했지만 서로 생각하는 방향이 달랐고, 답답했던 내가 결국 이미지로 간단히 만들어서 보낸 후에야 서로 간에 동일하게 이해했다는 걸 확인하고 일을 진행할 수 있었다. 이외에도 멘토 멘티간 관계를 만드는 경우, 목표가 명확해야 하며, 멘토에게는 또 다른 책임이 부과된 걸 이해해야 한다. 매니저 입장에서는 시니어 멤버들의 리더쉽 훈련의 기회로 삼을 수도 있다.

3장 테크 리드는 Tech Lead라는 직책에 대해 이야기한다. 매니저는 아니지만 개발과 매니지먼트를 병행하며 팀 외부와의 소통도 주로 담당하고 팀원을 이끄는 리더십이 필요한 자리이다. 저자의 경우 렌트더런웨이에서 이 역할을 다음과 같이 정의한다.

1:1, 정기적 피드백, 팀원의 성장을 지원하며, 팀 전체의 생산성 향상 및 소통을 돕고, 필요시 팀 내부와 외부 양쪽에서 다 이런 역할을 맡는다. 개발 vs 매니지먼트 사이에서 균형을 잡아야 한다.

회사 및 프로젝트 상황에 따라 시스템 아키텍처, 비즈니스 분석, 팀 리더의 역할을 맡아야 하며 팀의 계획 수립도 고민해야 한다. 계획을 세울 때 중요한 점은 계획의 가치는 계획을 완벽히 수행하고, 세부사항을 미리 파악하는 게 아니라(즉 예측하는 게 아니라) 실제 업무 시작 전 얼마나 깊게 고민하느냐에 있다. 프로젝트 관리를 위해 업무를 작게 나누고, 세부 사항과 문제점을 추적하며, 시작, 진행을 관리하고 계획을 수정해 변경된 요구사항을 반영해야 한다.

1:1에 대해 앞에서도 나왔지만 목록을 점검하고, 피드백을 주고받으며, 개인 간 관계를 강화해야 한다. 미팅 노트를 작성해 공유를 하며 서로 간에 이야기한 내용이 일치하고 공감하는지도 알아야 한다(영어로 on the same page로 표현하는데 회의 때 이 이야기가 정말 자주 나옴). 피드백을 주고받을 때는 팀원을 이해, 관찰하며, 가볍고 긍정적인 부분부터 얘기해야 하는데 팀원들의 상태에 대해 잘 아는 건 일할 때 매우 중요하다. 팀에 여자 직원이 한 명 있는데 얼마 전에 임신을 해서 조심도 해야 하고 아무래도 전처럼 일하기가 쉽지 않았는데, 변화된 부분을 조심스레 매니저에게 전달했다. 매니저는 따로 그 팀원과 이야기를 나누고 육체적으로 힘들지만 그래도 일 하는데 문제는 없다고 하며 큰 걱정을 할 필요는 없고 좋은 관찰이었다면서 칭찬을 듣기도 했다.

성과 평가는 누구에게나 매우 중요한 부분이기 때문에 시간을 들여서 일찍 시작하는 게 좋다. 최근이 아니라 기간 전체(예를 들어 1년)를 고려해야 하고, 구체적인 예, 특히 동료 평가에서 나온 걸 이용하면 좋다. 성취와 강점에 많은 부분을 할애하되 개선할 점을 가장 신경 써야 한다. 개선할 점이 없다면 승진을 하거나, 업무를 변경하거나, 새로운 기술을 학습하는 등 변화가 필요한 시점일 수 있다. 저 성과자의 경우 개선 방법을 예와 함께 이유를 설명해야 한다. 물론 이런 이유를 설명해도 납득하긴 어려울 수 있지만 아무 피드백 없이 낮은 평가를 주면 더 상황을 악화시킬 수 있다. 부정적인 피드백을 주게 되는 경우 기록하고 HR에 공유할 필요가 있을 수도 있다. 우리나라에선 흔한 상황은 아니겠지만 해고와 같이 힘든 상황을 가능한 막고 소송이 흔한 미국에서는 그런 대비를 위해서도 미리 피드백을 주고 기록하는 게 필요한 듯싶다.

5장 팀 관리는 개인 관리와는 차원이 다르다는 이야기로 시작한다.

우선 기술 매니저가 가져야 할 자질 중 필수는 여전히 기술 역량을 유지해야 한다는 점인데, 기술적 감각이 있어야 아키텍처나 세부 기술에 문제가 없는지 알 수 있고 동시에 팀과 비즈니스의 맥락에서 균형을 맞출 수도 있기 때문이다. 하지만 또 새로운 책임, 더 많은 회의, 계획, 관리 업무 등으로 코딩에 집중할 수 있는 시간이 없어진다(정말 그렇다). 코드 내 병목이나 프로세스 문제 등을 파악할 수 있는 정도로 작은 기능을 구현하거나 버그를 수정하는 일을 여전히 진행하는 게 좋다. 프로젝트 관리의 핵심은 기능 구현에 필요한 최적의 방법을 결정할 수 있을 정도로 시스템의 각 부분을 충분히 이해하는 점에 달려있기 때문이다.

매니저는 문제 있는 팀을 디버깅할 수 있어야 한다. 예를 들어, 출시하지 못하는 상황이나, 릴리즈 주기를 도구와 프로세스 때문에 못 맞추는 경우 병목 상황을 제거할 필요가 있다. 문제 있는 팀원이 있다면, 부정적인 에너지가 팀 내에 퍼지기 전에 해결을 하거나 다른 팀으로 보내는 등의 대처가 필요하다. burnout이 있다면 일정 조정이 가능하면 조정을 하고, 보상이 가능하면 프로젝트 종료 후 일시적 보상을 줘야 한다. 더 중요한 건 다음 프로젝트에서는 이런 상황이 발생하지 않도록 방지하는 일이다. 협업이 안 되는 경우는 단기적인 해결책은 없다. 장기적 관점에서 팀 내 신뢰 관계를 회복할 여러 가지 방법을 시도해야 한다. 기본적으로 팀을 보호해야 할 필요가 있지만 외부의 스트레스를 전달해 자극을 해야 할 수도 있다(흔히 프로스포츠에서 감독들이 선수의 의욕을 고취시키기 위해 많이 사용하는 방법).

이런 다양한 상황에서 매니저는 좋은 의사 결정을 내려야 하는데, 그 기반에는 데이터 중심의 팀 문화가 있어야 하며, 이를 통해 제품 역량을 강화(고객이 만족하는 결과물. 외부고객 뿐만 아니라 내부 고객도 마찬가지)하고, 미래를 내다볼 수 있어야 하며(business feature 구현을 위해 새로운 기술 도입), 의사 결정과 프로젝트 결과를 검토하고, 프로세스와 일상 업무에 대한 회고가 필요하다.

매니저에게 중요한 상황 중 하나가 갈등 관리인데, 문제를 해결하기 위해 합의가 항상 좋지는 않다. 객관적인 결정을 위한 프로세스와 기준이 필요하며 이슈가 있으면, 특히 부정적일수록, 빠른 대응이 필요하다(1:1의 목적 중 하나). 두려워하지도 말고 호기심을 가지며 친절하게 행동해야 한다.

프로젝트 관리를 위한 경험 법칙도 설명한다. 1년은 52주 분기별 13주이지만 사실 항상 최고의 성과를 내는 건 불가능하다. 마치 운동선수가 최고의 컨디션으로 모든 경기에 임하지는 못하듯이 팀과 개인에게도 리듬이 있고 매니저는 이런 리듬을 좋게 가져갈 수 있게, 즉 생산성을 향상하고 유지하도록 도와야 한다. 20% 정도의 테크 업무 할당이 흔히 사용하는 방법인데, 디버깅, 리팩터링, 개발 언어/프레임워크 변경, 버그 처리 등 business feature와는 무관한 작업을 위한 시간을 개발자들에게 허용하는 방법이다. 매니저가 빈번하게 해야 할 게 계획을 세우고 일정을 관리하는 일인데, 시간 추정을 요청받으면 생각한 시간의 두 배를 말하고(나의 경우 planning에서 팀원들과 story point로 task 업무량을 정할 때 팀원들의 평균값보다 두 배 정도로 추정하는 게 맞는 경우가 꽤 많았다), 긴 작업인 경우는 별도로 더 생각해봐야 한다.

6장 여러 팀 관리부터는 관리 업무의 수준이 높아지고 개발과는 점점 멀어지는 직급을 다룬다.

대규모 팀을 여러 개 관리하면 조직의 전반적인 기술 역량을 책임지고, 교육과 채용으로 팀의 역량을 성장시켜야 한다. 새로운 기술 및 트렌드를 연구하고, 중요한 시스템 디버깅 선별해서 진행하며 코드 리뷰를 하고 문제 분석을 해야 한다. 비즈니스와 제품에 대해 전문적인 답변을 할 수 있어야 하고 코드가 제품과 비즈니스에 부합하도록 해야 한다. 요구사항 추가에 대응할 수 있도록 구조와 설계를 확립하고, 필요에 따라 벤더사와의 관계를 관리하고 예산을 책정해야 한다. 사업과 기술을 모두 이해해야 하며 잠재적인 지원자에게 회사와 활동 분야 소개할 필요도 있다.

코딩을 할 수 있는 시간이 거의 없으므로 코드 리뷰, 디버깅, 제품 팀 지원 등을 통해 개발에 대한 감을 유지해야 한다.

가장 중요한 건 시간의 우선순위를 정하는 일이다. 중요도와 긴급도에 따라 간단히 나눌 수 있다. 중요하고 긴급한 일은 당연히 지금 진행해야 한다. 중요하지도 긴급하지도 않은 일은 아마 신경 쓸 겨를이 없을 가능성이 높다(나는 현재 하나 혹은 경우에 따라 두 팀을 맡은 지금도 그렇다). 중요하지만 긴급하지 않은 일 — 미래에 대한 고민, 채용과 관련된 프로세스, 중요한 일 목록 작성 등은 직접 진행해야 한다. 긴급하지만 중요하지 않은 일은 그냥 지나칠 수 있다고 생각할 수 있는데 일부 회의가 그럴 수도 있지만, 그렇다고 모든 회의를 빠질 수도 없다. 중요도에 따라 시간을 적절히 분배할 필요가 있다. ‘적절히'란 말하기는 쉽지만 실행하기는 어렵다는 뜻이다.

업무 위임

단순하고 빈번한 일은 테크리드나 다른 매니저에게 위임한다. 단순하지만 드문 일은 혼자 처리하는 게 빠르다면 비록 자신의 업무가 아니라고 생각이 들어도 바로 하는 게 좋다. 복잡하고 드문 일, 고과 평가, 채용 계획 등은 익숙해질 때까지는 도움을 받고, 그 이후에는 리더가 될 사람들의 교육을 위해 위임한다. 복잡하고 빈번한 업무, 프로젝트 계획, 시스템 설계, 긴급 상황 수습 등은 이런 업무를 통해 팀원들의 능력을 향상하는 기회로 사용한다. 조언을 주되 한 발 떨어져서, 위임을 할 수 있을 정도로 교육을 시킨다. 예를 들어 내 매니저는 bug가 발생하면 보통 한 발 떨어져서 내가 어떻게 하는지 보고 자신의 마음에 들지 않을 때 slack에 와서 진행을 정리하고 나중에 나를 따로 불러 이야기했다. 개인적인 성격이 맞지 않아 인간적으로는 좋아하진 않지만 여러 모로 배울 점들이 있는 이야기였고 시간이 지나면서 나에게도 도움이 되는 일이란 걸 깨달으면서 고맙단 생각이 들었다.

거절 전략

긍정적인 거절은 그냥 단순히 ‘아니오'라고 말하는 게 아니라, 요청한 작업을 시작하면 우선순위를 조정해 다른 낮은 우선순위 작업은 뒤로 미루면 가능하다는 방식으로 말하는 걸 의미한다. 이 부분은 내가 지금 매니저와 일을 하면서 특히 어느 순간 자연스럽게 말하게 됐는데, 항상 업무의 우선순위를 정하게 요청하는 방식 때문에 그랬던 거 같다. 명확하게 말하는 게 좋지만 안된다고 이야기했다가 실수였다는 걸 깨달을 수도 있다. 이럴 때는 실수를 바로 사과한다. 모든 결정마다 신중하고 시간을 들여 조사할 수는 없기 때문에 이런 상황도 발생한다. 생각해보면 개발자의 작업은 항상 버그의 위험이 있다. 버그가 나오면 개발자였을 때는 상황을 파악하고 버그를 수습하고 원인을 분석하고 방지하기 위해 노력을 하지, 숨기지는 않는다. 마찬가지로 매니저도 실수를 할 수는 있다. 실수는 사과하고 재발을 방지하는 게 더 중요하다.

개발 팀 운영의 건강도 확인 방법

릴리스 빈도, 체크인 빈도, 문제 발생 빈도 등을 통해 파악한다. 현재 회사에서는 매 스프린트마다 task 완료 비율, velocity, 버그 발생 빈도, A/B 테스트 목록, code coverage를 공유하고, 매 분기마다 중요도 별 버그 발생 빈도, feedback time, PR review time, deployment 횟수 및 소요 시간, code coverage, system capacity, sprint goal achieved %, milestone completion %등을 보고한다. 이런 작업이 따분하고 재미없는 건 사실이지만, 팀의 작업 진행 상황을 수치적으로 파악할 수 있어서 매니저 레벨에서는 유용하다는 점 역시 명확하다.

우리 대 상대, 팀 플레이어

새로 온 매니저가 팀 정체성을 만드는 일이 어려울 수 있다. 팀의 정체성을 다른 팀과 비교해서 얼마나 특별한 지 강조해서 팀을 단결시키면 비교적 쉽게 할 수 있다. 하지만 이런 방식은 회사 전체의 결속력을 무너뜨리고, 회사 전체의 목표보다 팀을 우선시할 수 있는 위험이 있다. 매니저는 자신의 팀에만 집중해서는 안 된다. 결국 회사의 목표를 공유하고 가치에 부합하는 방식으로 해야 신뢰 관계가 형성되고 오래갈 수 있는 팀을 만들 수 있다.

7장 매니저 관리는 팀을 직접 관리할 때와는 다른 어려움으로 시작한다.

스킵 레벨 보고서에서 정보를 얻어야 하는데, 원온원 스킵 레벨 미팅을 갖는 이유는 신뢰와 참여를 유지하고 매니저가 이끄는 팀이 겪고 있는 어려움을 파악하기 위함이다.

매니저가 팀원 각각의 세부사항을 챙기고, 이 역할을 맡은 사람은 큰 그림을 그려야 한다. 매니저는 팀의 건강과 생산성을 향상해야 하기 때문에 팀에 문제가 발생하면 매니저를 도와 문제를 해결해야 한다.

팀에 개발자들이 주니어와 시니어가 같이 있듯이 매니저를 데리고 있는 직급도 신입 매니저와 숙련된 매니저가 동시에 있을 수 있다. 신입 매니저에게는 (주니어 개발자를 교육하듯이) 훈련이 필요하다. 신입 매니저를 돕기 위해 팀원들과 원온원 미팅을 진행하고, (처음 맞는 여러 가지 관리 업무 때문에) 과로하지 않도록 주의하며, 코칭, 피드백, 외부 교육 등을 지원해 성장을 돕는다. 숙련된 매니저의 경우는 자신만의 방법이 있으므로 가장 중요한 건 팀 문화에 적합한지, 정보를 공유하며 전체의 방향성에 맞추도록 하는 점이다. 매니저를 채용한다면 매니저 면접은 기본적으로 대화를 통해 이뤄지기 때문에 개발자 면접보다 더 평가하기 어렵다. 얻고 싶은 정보와 기대하는 능력을 미리 정리해서 면접 때 평가해야 한다. 중요한 점은 매니저가 팀을 디버깅할 수 있어야 하므로 관리 철학, 기술 능력, 문화적 적합성(= 회사의 가치)등을 파악하고, 레퍼런스 체크를 통해 보강한다.

조직에 문제가 있으면 근본적인 문제를 파악해야 한다. 팀 문제를 디버깅하기 위해, 가설 세우기, 기록 확인하기, 팀 관찰하기, 질문하기, 팀 내부의 활동성 확인하기, 돕기 위해 뛰어들기, 호기심 가지기 등이 필요하다. 특히 계획과 연관된 부분을 잘 처리해야 하는데 프로젝트 예측치를 항상 적극적으로 업데이트하고 공유해야 한다. 제품/비즈니스 로드맵 변경을 다루기는 어렵다. 대규모 프로젝트를 작은 단위로 나눠야 하는데, (나중에 하겠다고 개발자들이 기술적으로 흥미를 가질만한) 개발 프로젝트를 팀에 약속하는 건 금물이다. 팀 업무 20%를 개발 유지보수에 할당해 개발자들이 비즈니스 이외의 업무를 할 수 있는 여유를 주는 게 좋다.

기술에 투자하고 감독해야 한다. 잘 아는 것에 대해 질문해 개발자들의 상태를 확인할 수 있다. 개발 — 비즈니스 트레이드오프를 이해해야 하고 구체적으로 요청하며 진행상황을 확인해야 한다. 코드를 읽고, 모르는 부분을 개발자에게 설명해 달라고 요청하고, postmortem 모임에 참여하고, 소프트웨어 개발 과정에 대한 업계 동향을 파악하고, 회사 외부의 기술 인력 네트워크를 육성하고, 배움을 멈추지 말아야 한다.

8장 빅 리그는 시니어 리더, 시니어 매니저에 관한 장이다. 첫 번째로 해야 할 일이 리더가 되는 일이다. 리더는 완벽한 정보가 없이도 어려운 결정을 내려야 하며, 현재의 비즈니스 상황을 이해하고 미래에 대한 계획을 세우고, 조직 구조를 이해하고 강화시켜야 하며, 조직과 비즈니스 발전을 위한 생산적인 정치를 하고, 개인과 조직이 결과에 책임지도록 해야 한다. 다음과 같은 4가지 범주로 관리 업무를 나눌 수 있다.

정보를 수집하고 공유하기, 살짝 찔러보기(nudging이라고 되어 있는데, 지시보다 질문을 통해 사람들이 할 일을 상기시키는 것), 결정하기(부딪히는 의견과 불완전한 정보 속에서), 롤 모델되기

개발 부사장의 역할, CTO가 하는 일은 조직의 비즈니스 요구사항에 따라 조직이나 경영에 집중할 수도, R&D를 주도할 수도, 인프라나 개발 전략을 책임질 수도 있다. 하지만 어떤 역할을 맡더라도 우선 비즈니스가 우선이라는 걸 기억해야 한다. 갑자기 떠오른 CEO의 아이디어 때문에 업무 우선순위를 바꿔야 한다면 혹은 방향을 수정해야 한다면, 현재 진행 중인 프로젝트에 대해 타협해서 자원을 다시 배분해야 하며, 이 과정에서 발생할 수 있는 불만도 해결해야 한다. 조직원들이 충분히 이해할 수 있도록 자주 다양한 방법으로 이야기해야 한다(저자의 경험은 최소한 세 번). 이외에도 기술 전략 수집 노하우, 나쁜 뉴스 전하기, 다른 역할의 시니어 동료들과 잘 지내기, 나를 팀에서 분리하기, 기분 나쁘게 만들지 않으면서 책임지게 하는 방법 익히기 등의 소제목을 통해 리더가 해야 할 일을 저자의 경험을 바탕으로 설명한다.

9장 문화 개선. 리더의 역할로 개발 팀 문화를 만드는 방법에 대해 설명한다.

훌륭한 개발자가 좋은 시스템 구조를 만들 듯 훌륭한 리더는 팀 구조와 팀 내 역학 관계를 파악해서 팀 구조를 만들어야 한다. 회사의 직원 수, 연혁, 기존 인프라의 크기, 위험 허용 정도 등을 통해 팀 구조를 만들고 때로는 변경하고 또 때로는 기존 방식을 유지하는 결정을 내려야 한다.

문화를 만들기 위해서는 핵심 가치를 적용해 분위기를 조성하고, 좋은 방향으로 회사의 가치를 살린 직원들에게는 보상을 통해 강화를 해야 한다. 코칭을 하거나 면접을 진행할 때도 이에 부합하는지를 확인해 문제가 되는 부분은 제거하고 같이 일할 동료를 선별해야 한다. 문화를 만드는 건 추상적이어서 여러 가지 방법이 있고 상황이나 회사에 따라 다를 수 있지만, 커리어 패스, 연봉 체계, 위기관리 정책 등을 참고해서 자기 조직의 문화 정책 문서를 작성하면 좀 더 수월하다. 하지만 결국 체계를 개선할 시기가 오는 데 보통 일에 실패하는 경우이다. 예를 들어 커리어 패스 수립 시 저자는 친구 회사의 것을 참고해 작성했는데 친구 회사에서는 성공한 방식이었지만 저자의 회사에서는 실패했다. 친구의 회사에서는 같은 개발 분야의 대기업 출신으로 핵심 인력을 구성해 비슷한 배경과 문화를 가졌지만, 저자의 회사에서는 다양한 출신 배경으로 경험은 다양하고 반면에 공통된 문화적 습관은 없었기 때문일 거라고 추측한다.

이외에도 개발 프로세스의 경우 코드 리뷰, 장애 사후 분석(Postmortem), 아키텍처 검토 등 매우 중요한 업무들을 통해 설명하는데 간단해서 조금 부족한 감은 있지만 객관적으로 의사 결정을 하는 방법을 볼 수 있다.

10장 결론. 가장 중요한 교훈은 스스로를 잘 관리해야 한다는 점이다. 저자는 명상과 호기심을 통해 어려운 상황에서도 자신을 관리한 경험을 이야기한다. 명상을 권하는 게 아니라 스스로를 컨트롤하는 방법이 있어야 어려움을 겪을 때도 헤쳐 나갈 수 있다는 뜻이다.

   우리나라에서는 높은 직책까지 개발자로 가는 것이 쉽지 않습니다. 끊임없이 새로나오는 기술들을 배우고, 나이들어서도 야근 및 주말근무를 하는 것도 힘듭니다. 그러나 더 큰 문제는 내가 개발을 계속 하고 싶다고 하더라도 회사에서 과장급 이상의 연차가 되면 개발과 관리 두 가지를 병행으로 요구하거나 관리하길 바라기 때문입니다. 개발자만으로 퇴직때까지 업무를 수행하기에는 그런 자리 자체가 별로 없습니다.

   이렇듯 우리나라에서는 자의보다는 타의에 의해서 인적자원 관리 등의 업무로 갑자기 변경되는 경우가 많습니다. 이 책은 그러한 사람들을 고려해서 갑자기 바뀐 직무에 도움을 주고자 나온 책으로 보여집니다. 지은이가 우리나라가 아닌 외국에서 근무해서 조금 다른 점은 있겠지만요.

   책에 좋은 이야기는 많은데 저는 개인적으로는 지은이가 자신의 경험을 바탕으로 스토리텔링 방식으로 서술했으면 더 와닿았을 것이라고 생각되어 집니다. 개발하다 매니저가 되었을 때 그 충격 그리고 실제로 업무를 수행하면서 생긴 에피소드 중심으로 해서 구성되는 방식으로요.

   이런 내용의 책이 많지 않기에 매니저 업무를 맡게 되신 분들에게는 이 책을 읽는 것이 도움이 될 것으로 보여집니다. 개발을 하고 계신 분들도 읽으시면 향후 바뀔 때를 생각해볼 수 있는 기회가 되고, 현재 매니저의 입장이나 생각을 이해할 수 있을 것입니다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."

소개

이번에 리뷰하게될 이 책은 Camille Fournier의 The Manager’s Path 번역서인 개발 7년차, 매니저 1일차이다.

Camille Fournier는 MS 개발자를 시작으로 다양한 경험을 쌓은 CTO로 컨퍼런스를 통해 이러한 주제에 대한 스피커를 자주 맡고 있다.

사실 원서와는 다르게 제목부터 특이했고 여러 챕터에 있는 사례조차 굉장히 자극적이면서도 흥미로워 관심이 있었다.

한빛의 리뷰어를 통해 운 좋게 책을 읽어볼 수 있게 되었다.

흥미로운 사례 제시

관리 측면에 대한 경험과 스토리텔링이 녹아져있다.

멘토링, 테크 리딩, 사람, 팀, 다수의 팀, 매니저 등등 다양한 관리를 통해 문화를 개선하고

결론적으로는 나 자신을 관리해야 한다는 통찰의 시점으로 가는 로드맵에 대한 흐름으로 읽힌다.

이 와중에 시니어 개발자로 남을지, 매니저가 될지 선택하기, 좋은 매니저, 나쁜 매니저 : 프로세스 독재자, 도전 상황 : 성과가 낮은 사람 해고하기

같은 자극적인 챕터가 소소하게 있어 읽는 내내 흥미로운 부분이 있었다.

가끔 소제목에 비해 내용이 자극적이지 않아 김이 빠지는 경향도 있었으나 충분히 가치 있는 이야기였다.

예비 팀장보다는 우리 모두를 위한 관리 기술

팀장으로 성장하는 내용을 주로 다루는 그런 내용이지만

결국은 팀장이 아닌 반대 입장으로 읽을 수 있기 때문에 공감되는 내용이 많이 있었다.

제목과 내용의 흐름이 팀장에 초점을 맞추고 있더라도 충분히 볼거리 많을 수밖에 없는 이유이기도 했다.

팀장이 왜 그렇게 행동할 수밖에 없었는지 팀장도 어쩌면 결국 같은 팀원이구나 하며

내가 팀장이라면 나는 어떻게 했을까라는 가정도 가능했다.

재미요소

책의 중간중간

• CTO에게 묻는다
• 좋은 매니저, 나쁜 매니저,
• 자신의 경험 평가하기,
• 도전 상황

위와 같은 코너를 통해 사례에 대한 액션 플랜과 액션 아이템을 제시하고 있어 깊이 고민할 시간을 가지며 자아성찰을 하게 된다.

결론

정년이 길어지는 동시에 인구와 고용은 감소하고 있다.

이런 상황에 개발자로서의 길을 계속 걸으며 많은 일과 수많은 고난을 겪게 될 것이다.

어쩌면 팀장이 되기 싫을 수 있을 수 있고 팀장이 되고 싶지만 될 수 없을 수도 있다.

국내 IT 상황과 100% 일치하지는 않지만 다양한 사례에 대한 액션을 많이 담고 있기 때문에

어려운 순간이나 슬럼프가 왔을 때 좋은 인생 멘토의 경험이라 생각하고 두고두고 펴볼 수 있을 것 같다.

"개발 7년차, 매니저 1일차"는 한빛미디어 리뷰 이벤트 덕분에 받아보게 된 매니저에 대한 책이다. 이 책이 굉장히 흥미로운 점은 개발자가 매니저 역할로 돌아서면서 심리적으로 두려워하는 부분, 우려하는 포인트 그리고 역할 등에 대해서 잘 표현하고 있다는 점이다. 가령 매니저가 정말 개발자의 무덤인지, 팀을 위해 무엇을 해야 하는지, 갈등은 어떻게 해소해야 하는지와 같은 이야기가 잔뜩 실려있다.

일단 책 제목이 재밌다. 개발 7년 차에 매니저 시작이라니. 그런데 곰곰이 생각해보면 정말 재미있는 표현이다. 우리 주변에 매니저 역할을 수행하는 사람의 연차를 돌이켜보거나 개발자가 진로에 대한 깊은 고민에 빠지는 시기가 아니던가. 제목부터 센스가 돋보이는 이 책을 소개한다.

이 책은 당연한 이야기들이 교과서처럼 쓰여있지만 그럼에도 많은 사람들에게 추천할 만한 책이다. 매니저 역할을 수행하게 되는 사람뿐만 아니라 개발자가 읽기에도 재미있다. 우리 팀, 혹은 매니저, 과거의 경험들과 비교하면서 읽어보면 더욱 재밌다. 이 책은 번역서지만 우리나라 정서에도 꽤 잘 맞는다. 특히 중간에 기고되어 있는 글은 이 책을 더욱 훌륭하게 만들어준다.

- 기고 : 좋은 매니저는 누구인가_ 임백준
- 기고 : 매니저직은 개발자의 무덤인가_ 정도현
- 기고 : 뉴비 프로젝트 매니저를 위한 이야기 한 조각_ 배상언

위에 기고 내용만 보더라도 매니저를 너무 잘 표현하고 있다. 책을 다 읽고 표지를 덮고 나서 생각해보니 기고들은 마치 이 책의 요약본 같은 느낌이었다. 그리고 나는 운 좋게 주변에 좋은 매니저가 많았고 그들을 통해서 가치관까지 영향을 받았으니 매니저는 단순히 사람을 관리하는 역할만 있는 것은 아니겠다. 한편 과거에 매니저 역할을 수행하면서 받았던 다양한 스트레스 상황이 이 책에 잘 녹아있어서 나를 돌아보는 계기까지 되었으니 이 얼마나 좋은 책인가 :-) 

요즘처럼 소프트웨어 직군이 다양하게 나뉘어져 있는 시대에 매니저는 어쩌면 슈퍼맨이 되어야 할지도 모른다. 모든 직군의 테크니컬 한 부분을 이해할 수 없음에도 이를 인정하고 팀은 케어하고 앞으로 나아갈 수 있어야 하니까. 조금 거창하지만 현대를 살고 있는 매니저들에게 깊은 존경을 표하고 매니저를 필두로 좋은 기업이 넘쳐나는 대한민국이 되기를 바라본다.

제목을 정말 잘 지었다. 개발자로서 경력을 쌓다가 관리직에 첫 발을 들여놓은 사람을 위한 책이다. 

[1장 IT 관리 101]

101은 미국 대학교에서 어떤 코스의 첫단계를 뜻하는 수업 번호이다. IT 관리의 시작점을 의미하는 장이다. 일대일미팅에서는 매니저 뿐만 아니라, 팀원도 주제를 고르고 시간과 장소를 정해서 미팅을 만드는 책임을 함께 나눠지는 것이 좋다는 걸 처음 알게 되었다. 

[2장 멘토링]

여기서 묘사하는 알파 긱(Alpha geek)은 꼭 개발자가 아니더라도 회사에서 한 명쯤 있는 상사를 그대로 그려놓은 것 같다. 

"알파 긱(Alpha geek)은 팀에서 인정받은 최고의 개발자로, 늘 정답을 말하며 어떤 어려운 문제도 풀어내는 사람이다. 지적이고 기술력에 최고의 가치를 두며, 실력이 의사결정에 영향을 미쳐야 한다고 믿는다. 그런데 이들은 대개 다른 의견에 대처하지 못하며, 자기가 받아야할 관심을 빼앗는 사람이나 자기를 능가하는 사람을 만나면 쉽게 위축된다. 알파 긱은 자신이 최고라고 믿으며 이에 동조하는 말에만 반응한다. 한마디로 이들은 뭐든 뛰어나야 하는 '탁월함의 문화'를 만들려고 하지만 결국에는 '두려움의 문화'를 만드는 경향이 있다."

[3장 테크리드]

우리나라에서 흔히 '개발팀장'이란 단어로 통칭하는 역할이 테크리드와 비슷하다. 순수한 관리자(매니저)가 아니면서도 순수한 개발자(엔지니어)도 아닌, 보다 무거운 책임을 지는 단계이다. 개발 외길만 걸어온 사람들이 처음 맡았을 때 가장 힘들어하는  역할이기도 하다. 내용 중에는 '시니어 개발자의 이상적인 생활' vs '시니어 개발자의 실제 생활', '매니저의 이상적인 생활' vs '매니저의 실제 생활' 부분이 심히 웃기면서도 공감이 갔다. 

[4장 사람 관리]

새로운 팀원과 관계 맺기부터 시작해서 팀과 소통하기, 일대일 미팅의 기법 등 다양한 방법으로 사람을 관리하는 내용이 나온다. 제목이 사람 관리이지만, 실제로 누군가를 쥐어짜서 원하는 형태로 만들어 간다는 자세가 아니라, 상호 소통과 그리고 문제 해결기법에 중점을 두고 있다. 

[5장 팀 관리]

동료였던 팀원이 내 관리대상이 되는 건 정말 어색한 일이다. 그리고 신임 팀장에게는 좋은 의사 결정을 내리는 방법과 프로젝트 일정 관리 방법을 비롯해서 익혀야 할 일들이 산더미 처럼 많다. 무엇보다도, 세세한 것 하나까지 사사건건 간섭하는 마이크로매니저는 되지 말자고 다시 다짐하게 됐다. 

[6장 여러 팀 관리]

여러 팀을 관리한다는 것은 다수의 개발팀장을 관리하게 된다는 의미이다. 이 역할은 엔지니어링 디렉터라고 칭해지는 경우가 많다. 그리고 더 이상 코드를 짜고 있지 않을 것이다. (정확히는 코드를 짤 시간이 없다.) 이 위치에서는 조직의 전반적인 기술 역량을 책임지고, 필요한 경우 교육과 채용을 통해 전체 팀의 역량을 이끌고 성장시키는 역할을 해야한다. 이 장은 맨 뒤의 "기고: 매니저직은 개발자의 무덤인가_ 정도현" 부분이 제일 인상적이었다. 나도 매니저는 꼭 필요한 역할이지만 개발자보다 이직이 많이 불리하다고 생각해왔기 때문이다.

[7장 매니저 관리]

매니저의 매니저이다. 이제부터는 자신이 전문성을 갖지 못한 일까지 관리해야한다. 세부사항을 알 수 없을 때에도 의사결정을 하는 방법을 익혀야 하다니, 생각만해도 머리가 아프다. 그래도 책에 나온 방법대로 매니저에게 책임 일깨우는 법, 신입 매니저 관리하기, 숙련된 매니저 관리하기 등을 익힌다면 좀 나을지도 모르겠다.

[8장 빅 리그]

기술 시니어 매니저, CTO, 부사장 등의 위치는 명실상부한 리더 자리이다. 회사가 무엇을 해야 하는지, 어디로 가야 하는지, 어떻게 행동해야 하는지, 어떻게 생각해야 하는지, 무엇을 소중히 여겨야 하는지를 알고, 또 전파해야 한다. 그로 인해서 사람과 문화와 기술을 모두 이끌어 나가야 한다. 생각만해도 얼마나 어려울지 끔찍하다. 

[9장 문화 개선]

회사 구조를 파악해서 명확하고 신중한 개발팀 문화를 만들어야 한다. 중요한 인프라에 신경을 쓰는 것만큼 팀 문화에도 신경을 써야한다. 정말로 뛰어난 기업들은 그들의 기술보다도 그들의 문화로 인해 더 널리 알려졌다는 걸 되새겨본다.

[10장 결론]

나 자신부터 관리하기. 다른 사람들을 잘 관리하기 위해서는 나 자신을 먼저 관리할 수 있어야 한다. 자신이 반응하는 방법, 영감을 주는 일, 자신을 미치게 만드는 일에 대해 이해하기 위한 시간이 필요하다. 동시에 상황을 다른 사람의 시각으로 객관적으로 살펴보는 것도 중요하다. '사람들은 무엇을 하려는 것일까? 사람들은 무엇을 중요시할까? 사람들은 무엇을 원할까?' 등에 대해 언제나 호기심을 가지고 관찰해야 한다. 

[후기]

이 책은 내게 많은 조언과 고민거리를 동시에 안겨줬다. 읽는 내내 이전에 했던 관리적인 실수가 떠올라서 얼굴이 화끈화끈해졌다. 시니어 개발자를 벗어나는 사다리의 첫 시작점부터 CTO 이상까지 모든 커리어 패스에 적용되는 내용이기 때문에, 나이를 먹고 직장생활의 연륜이 깊어질수록 두고두고 다시 펴서 참고할 수 있는 책이다. 

[단점]

P.S. 아쉽게도 편집 실수가 약간 있다. 본문 중 저자 외에 다른 사람이 작성한 컬럼이 군데군데 삽입되어 있는데, 원서는 박스로 별도 표기되었지만, 번역서에는 컬럼도 저자가 작성한 본문과 구분되지 않게 동일한 스타일로 편집되었다. 그래서 책을 읽다보면 문단 끝에 갑자기 엉뚱한 사람 이름이 붙어있는 경우가 있는데, 이럴 때는 조금 당황스러웠다. 

시간이 지남에 따라 세상은 복잡해져 간다. 복잡한 세상의 다양한 수요를 충족하기 위해 소프트웨어도 점점 복잡해진다. 이러한 복잡한 소프트웨어나 IT 서비스를 개발하기 위해서는 다양한 사람들의 협업이 필수인 시대가 된 것이다. 지금 개발자의 경력을 쌓고 있는 당신도 언젠가는 누군가, 혹은 특정 조직을 관리할 필요가 생길 수 있다는 의미다.

본인은 관계없다고 생각할 수 있지만 우리는 이미 회사 내에서 관리를 받거나 관리하는 입장에 놓여 있다.

- 신입 사원 멘토링을 하는 사수

- 테크 리드

- 팀 관리자

- 다수의 팀을 관리하는 관리자

- CTO

이 책의 내용을 요약하자면 

- 각 직책별 관리자의 역할과 책임 설명

- 관리자로써 만날 수 있는 다양한 상황 제시 및 올바른 해결 방안 설명

- 잘못된 방법과 올바른 방법의 비교 설명을 통해 관리자가 흔히 빠질 수 있는 실수 설명

비록 현재 자신이 관리자가 아니더라도 이 책의 내용은 회사 생활에 많은 도움이 될 수 있다. 현재 자신의 상사 입장에서 프로젝트나 조직을 바라볼 수 있는 넓은 안목을 가질 수 있다. 이는 당신이 회사에서 인정 받고, 승진하고 더욱 중요한 역할을 차지하기 위한 필수 요소이다.

이 책에서 아쉬운 점이 있다면 읽어도 잘 이해가 되지 않는 문장이 종종 보인다는 점이다. 주어와 동사 관계가 어색하기도 하고, 주어가 생략된 경우에는 매니저가 주어인지 팀원이 주어인지 모호한 경우도 가끔 있었다. 원서의 내용이 그런 것인지 번역하는 과정에서 발생한 문제인지는 잘 모르겠지만 이 부분은 약간 아쉬움이 남는다.

하지만 이 점만 제외하면 내용은 무난하다고 생각하며 관리자 업무를 맡아야 하거나 개발자와 관리자를 선택해야 하는 갈림길에 서 있는 사람들이라면 참고하기에 좋은 책이다. 그리고 마지막으로 효율적 개발 관리를 위한 수많은 프로세스와 기술이 존재하지만 결국 관리의 주체는 사람이고 사람 간의 의사 소통이 가장 중요한 핵심이 아닐까 생각한다. 지금까지 너무 코딩에 집중한 나머지 팀원들과의 의사 소통에 조금이나마 소홀하지 않았나 반성해본다.

책 소개

경력이 쌓이면 누구나 겪게 될

‘개발 관리’의 모든 것을 한 권에!

• 사수, 멘토, 팀장, CTO까지 직책별 관리 기술 대백과
• 개발자도 꼭 알아야 하는 소프트 스킬, 사람 및 조직 관리 노하우 수록
• 개발 팀을 성공으로 이끄는 IT 팀장에 대한 모든 것

대다수 사람들은 조직에 들어가고 ‘관리받게’ 된다. 하지만 경력이 쌓일수록 ‘관리하게 되는’ 비중이 늘어난다. 따라서 개발자가 매니저로 전향하는 순간이 오는 건 피할 수 없다. 이 책은 매니저로 성장하면서 겪는 여러 문제를 구체적인 사례를 통해 보여 주고, 이를 극복할 수 있는 실질적인 조언을 담았다. 개발자에서 테크리드로, 팀장으로, 여러 팀을 관리하는 CTO로 성장하며 겪게 되는 다양한 시나리오와 각 직책별 좋은 매니저의 모습을 알려 준다. 또한, 소프트 스킬이 부족한 사수를 둔 개발자를 위해 사수에게 어떤 도움을 받을 수 있는지에 대한 구체적인 내용도 담았다.

이런 분들 주목!

• 개발자 vs 매니저 갈림길에 서 있다.
• 개발 관리를 체계적, 효율적으로 하고 싶다.
• 내 사수가 사수 역할을 못해서 내가 고생 중이다.

이 책을 주목해야 하는 이유!

첫째, 아마존 베스트셀러 『The Manager’s Path』의 한국어판! 현재 아마존 ‘엔지니어링/기술 프로젝트 관리’ 분야 베스트셀러이다.

둘째, 멘토로 시작하여 시니어 리더십에 이르기까지 각 직급에서 알아두어야 할 관리 기술을 모두 담았다. 개발자라면 한 권은 구비해 두고 경력 ‘레벨업’ 할 때마다 꺼내 읽어야 하는 바이블 같은 도서이다. 

셋째, 개발 관리에서 겪게 될 여러 문제를 사례를 통해 보여주고, 실질적인 조언을 제시했다. ‘개발자’라는 환경에서 겪는 특수한 상황들을 들려줌으로써, 비슷한 상황이 닥쳤을 때 잘 대처할 수 있는 방향성을 알려 준다.

추가로 원서에 없는 삼성전자, AWS 코리아, GroundX 등 국내 대기업에서 활동 중인 현업자들의 이야기까지 담았다.

자세한 내용 : https://www.hanbit.co.kr/store/books/look.php?p_code=B3838365362

목차

책을 읽으며

이번에 리뷰하게 된 책은 한빛미디어의 개발 7년차, 매니저 1일차 입니다.

이 책을 받기까지 해프닝이 하나 있었습니다. 개발 관련 서적을 받아야하는데 택배를 뜯어보니

이런 책이 배송되어 있어서 굉장히 놀랐습니다. 놀란 마음으로 담당자분께 연락드렸더니 책을 다시 보내주셔서 받은 책이었습니다. OREILLY 책인데도 불구하고 동물 사진이 아니라서 다소 어색한 책이긴 합니다.

개발자로 일하다보면 어느순간 매니저 역할을 할때가 많습니다. 신입사원이라던지 인턴이라던지. 어떻게 하면 잘 할 수 있을까를 항상 고민하던 저에게 좋은 책이었습니다.

책 내용 중 와닿는 내용에는 '팀원이 매니저에게 기대하는 것은 피드백이다.' 라는 부분입니다. 제가 매니저에게 미팅을 요청했을 때 매니저로부터 피드백을 받기 위해 요청하는 경우가 많았기 때문에 기억에 남았고 체크해두었습니다. 책에서는 이런 내용들을 많이 다루고 있습니다. 팀원이 매니저에게 바라는 것, 매니저가 팀원에게 해줄 수 있는 부분에 대한 내용. 매니저라는 것이 강제가 되서는 안된다 등 매니저에 대한 내용을 볼 수 있습니다. 

미팅도 그렇지만, 원앤원 미팅에는 팀원과 매니저 사이의 인간적인 연결 이라는 것을 강조합니다. 그도 그렇듯, 매니저도 사람이고 팀원도 사람이기 때문에 상호간의 인간적인 대화랑 연결이 참 중요하다고 생각합니다. 전에 있던 직장에서는 매니저와의 미팅을 거의 할 수 없었지만 현 직장은 매니저와의 대화를 통해 업무를 조율하고 컨디션을 조율할 수 있었습니다. 그렇다보니 일에 있어서 자신감도 생기고 시간 관리도 할 수 있는 근무환경에서 근무 중에 있고, 매니저가 필요한 이유를 알 수 있는 경험이었습니다.

제가 주의 깊게 봤던 문장은 '뛰어난 개발자가 주니어 팀원에게는 훌륭한 멘토일 수 있지만, 시니어 개발자에게는 그저 자기 주장만 강한 변호형 일지도 모른다.' 라는 문자이었습니다. 많은 것을 알고 있는 개발자는 좋은 멘토 역할을 할 수 있지만 시니어 개발자와의 충돌이 생길 수도 있고, 자기 주장만 강한 사람이 될 수도 있다는 문장이 마음에 와닿습니다. 개발을 하다보면 아는 내용만 맞다라고 생각 될 때가 있고 그러한 생각을 항상 조심해야 한다는 생각을 하는데 그런 부분들을 잘 짚어주는 책이라 좋았습니다.

마지막 장에는 가장 중요한 문화를 개선해야하는 내용이 나옵니다. 맞습니다. 문화가 개선되지 않으면 좋은 매니저가 있더라도 그런 문화가 좋게 보이지 않는 회사라면 매니저의 역할을 할 수 없다. 반대로 좋은 문화가 자리잡혀 있다면 그 속에서 좋은 매니저가 나오기는 쉬울 수 있다고 생각한다. 그런 부분에서 내 자신과 내가 일하고 있는 회사를 돌아보게 해주는 좋은 책이다.

개발 7년차, 매니저 1일차. 이 책은 '개발' 조직에서의 매니저의 역할을 얘기한다. 멘토링 부터 시작해서, 테크리드, 사람 관리, 팀 관리, 여러 팀 관리, 매니저 관리, 문화 개선까지-

표지와 제목에서도 느낄 수 있듯이 가볍게 읽어볼수있는 책이다.

각 챕터별로 CTO에게 묻는다 라는 코너가 있는데, 실제 내가 궁금해 하는 부분을 정확히 콕 찝어주었다.

'테크리드가 되고 싶지 않아요', '성장하지 않는 직원을 어떻게 해야 하나요?'

또, 시니어 개발자, 매니저의 이상적인 생활과 실제 생활 비교 부분은 재밌기도 하고 공감가기도 한 웃픈 내용이였다.

나같이 당장 '매니저'에 관심 없는 사람에게도 도움이 될만한 부분이 많았다. 연차가 쌓이면 주니어 팀원분들과 함께 일하게 되면서 매니징은 아니더라도 멘토의 역할을 하게 될 수도 있고, 꼭 매니저는 아니더라도 테크리드의 역할을 하게 될 수도 있으니-

(사실 이책을 읽기 전 까진 테크리드가 정확히 뭔지도 잘 몰랐다.)

또, 결국은 '나 자신부터 관리하기' 라는 결론으로 나를 되돌아 볼 수도 있었다.

2020년 4월, 두번째 [나는 리뷰어다]. 이번에는책이 너무 늦게 와서 다른 일정이 바쁜 탓에 급하게 쓰는 감이 있다. 추후에 브런치 같은 곳에 업로드하게된다면 퇴고하는 걸로. :-(

결론적으로 좋은 매니저가 되는 방법은, 서로 잘 소통하는 것이라고책은 말하고 있다.

개발은 팀 프로젝트만 해 본 나이지만, 책에서 말하는 부분이 공감가는게 몇 있었다. 팀원이 아무리 적더라도 의견 차이와 갈등은 생기기 마련이더라. 그 부분을 잘 조율하고 일정관리를 잘 하는 것이 좋은 결과물을 내는 것에 가장 중요한 법이다.

사적인 얘기지만, 소프트웨어 개발자를 지망하고 공부함에 있어 무엇보다중요한 역량은 협업 능력이라고 생각한다. 사실 어떤 직종이든 ‘누군가와함께 일하기’는 필수적인 능력이긴 하다. 하지만 그 중에서도 Git, Slack 등 협업 툴이 기본인 개발 직종이기에 더 중요한 느낌이 드는 것이다. 그동안 협업을 할 기회가 많이 없어서 아쉬웠는데 이번에 NaverHackday를 진행하게 되면서 Gitflow를 사용하며 협업할 기회를 갖게 되어 열심히하면서 많이 배울 생각이다.

2018년 통계에 의하면 지구상 최초로 합계출산율이 0.98명이 된 놀라운 나라 대한민국에서, 취준생으로 2020년을 맞이하게 되어 정말... 여러 가지 생각이 든다. 사실 이번 해에는 유럽 여행을 가려고 생각하고 있었기에 돈을 7~8백정도 모아 두었었다. 그런데 COVID19가 터져버렸고... 계획하던 1달 반의 유럽여행은 포기하고 학자금을 갚는 것에 값지게쓰였다. 어떻게 보면 여행을 못 가게 되어 취준을 본격적으로 시작하게 된 느낌도 있다. 여러모로 답답한 상황이긴 하지만 부디 각자의 자리에서 노력하고 취뽀하기를.

미국 회사에서 근무한 사람이 쓴 책이기도 하고, 돈을 받으며 일해본 경험이 없어서 그런지 책에 관해서는 쓸 내용이 많이 부족했다. 내 주저리가 많이 담긴 똥글이 탄생해버렸지만 나같은 고민을 하는 사람이 꽤나 있을 테니 이 글을 읽는다면 한 줌의 위로가 되었기를.

이제 3년차에 접어든 주니어가 과연 읽어도 괜찮은지 의문이 들었지만, 많은 사람의 추천으로 읽게 되었고 많은 인사이트를 얻게 되었다.

주변의 개발자들과 마찬가지로, 나는 쭉 나이들어서도 개발을 하고 싶고, 때문에 한국 사정상 연차가 쌓일 수록 매니저가 될 수 밖에 없는 숙명에 한탄하며, 해외 이직을 생각하곤 했는데 그런 생각 또한 다시한번 생각하게 되는 계기가 되었다.

매니징을 하는 일이 사람을 다루는 일이다보니 프로젝트 매니저가 된다면 자연히 나의 기술적 지식이나 실력이 떨어질 것이고 그에 따라 내가 매니저를 하지 않고 다시 시니어 개발자로 돌아가고 싶을때 돌아 갈 수 없을것에 대한 두려움이 컸었다. 하지만, 이 책을 읽고 나선 매니징이 단순히 사람들을 이끌고 프로젝트를 이끌어 성공하는게 다가 아니라, 그 안에서 더 많은 기술을 접하고 시야를 넓히며 기술과 실무를 더 적절히 배합 할 수 있는 능력을 기를 수 있다는 것을 알게 되었다. 

최근에 프로젝트를 잠시나마 혼자 맡아서 진행한 적이 있었는데, 리더의 부재가 너무 힘들었었다.

그와 함께, 나와 같은 일이 일어나지 않도록 좋은 리더가 되기 위해선 어떻게 해야하는지에 대해서 고민하기 시작했는데, 이 책은 이 부분에 대해서도 어느정도 해법을 주는 것같았다. 또한 아직 매니저가 아닌 팀원 입장에서 좋은 팀원이 되기 위해서는 어떻게 해야하는지에 대한 인사이트를 주었다.

매니저가 될 사람 뿐만 아니라, 나같은 주니어, 혹은 IT업에 종사하면서 개발을 하지 않고 프로젝트 매니징을 하는 사람들은 꼭 한번쯤은 읽어 보았으면 하는 책이다.

이 책을 읽으면서 막연하게 내가 생각했던 편견들을 많이 알게되었는데, 어떠한 사람들이 읽건 각자의 위치에서 각자의 인사이트를 충분히 얻을 수 있는 책이다.

또한 한번 읽어서 끝날 책이 아니라, 여러번 두고두고 읽으면서 하나의 지침처럼 보아도(꼭 책의 내용이 정답은 아니지만) 어느정도 방향은 알려 줄 수 있지 않을까 생각이 된다.

본 리뷰는 한빛미디어로부터 도서를 지원받아 작성되었습니다.

표지

예쁘다

한빛미디어의 책을 읽으면서 표지 디자인 때문에 실망했던 적은 없었던 것 같다. 오히려 디자인이 너무 마음에 들기에 읽지 않으면서도 괜히 버스나 지하철을 타면 무릎 위에 얹어두고 싶을 만큼 예쁘다.

개발만 해왔던 내가, 어느 날 갑자기 '팀'을 맡았다!

경력이 쌓이면서 어느새 팀원들의 업무와 실적을 책임져야만 하는 매니저가 된 사람의 이야기를 담고 있다는 사실을 제목을 보조하여 독자에게 알려준다.

사람을 상대하고, 그들에게 도움을 주거나 받는다는 것은 생각보다 어려운 일이었다. 그리고 지금도 여전히 어렵다. 그렇기에 이 책이 더욱 끌리는 것이 아닌가 생각된다.

내용

노하우의 끝판왕

시작부터 끝까지 노하우의 연속이다. 여기서는 그 어느 페이지에서도 정돈된 이론과 간단한 결과를 이야기하지 않는다. 모든 페이지에서는 경험에 기반한 결과, 그리고 그 결과를 원하는 방향으로 비틀기 위한 노하우를 전수 해 준다. 그야말로 이 책 밖에서도 충분히 어디서나 배울 수 있지만 어디서도 알려주지 않는 통찰력을 빌려주는 책이다.

물론 그 통찰력이 모든 사람의 모든 상황에서 동일하게 정해진 공식처럼 적용되는 것은 아니기에 그것을 자신의 것으로 만드는 것은 독자의 몫이다.

'나 자신부터 관리하기'

이 책에서는 계속해서 팀, 기술, 사람을 지켜보고 관리하며 팀 안에서 시너지효과를 일으킬 수 있도록 도와주는 방법에 대해 길게 설명한다. 그리고, 끝에서는 '나 자신부터 관리하기'라는 이름으로 이야기한다.

필자도 이 부분에서는 크게 고개를 끄덕일 수 밖에 없었다. 그 누구보다 게으른 사람이 주변 사람들에게 성실하게 살았을 때의 장점을 이야기하면 그것을 믿고 따를 사람이 몇 명이나 있겠는가?

팀을 이끌기 위해서는 우선 나 자신부터 바르게 이끌어나갈 수 있어야 한다는 사실을 다시금 느낄 수 있었다.

결론

잘 보았다. 아직은 팀을 이끌만큼 경력이 많지도 않고 이끌 팀도 없지만 작은 프로젝트를 진행하거나 과제를 수행할 때, 또는 자기 자신과 싸워야 할 때(?) 큰 도움이 될 수 있을 것이라 생각되는 책이다.

그리고 팀의 리더라면, 그리고 자신이 좋은 리더라고 깊게 착각하고 있다면 더더욱 한 번쯤 읽어보았으면 한다.

경력 3 년 곱하기 2 는 7 년 차… 개발 7년차, 매니저 1일차

어떤 분야에서 일을 하든 그 분야에서 3 년 정도를 일하면, 그 분야에 발을 들여 놓았다고 말을 할 수 있을 것이다. 아울러이 책의 제목처럼 3 년의 2배 수, 즉 7년차 정도 되었다면 주변에서 경력을 인정해주면서 다른 사람들과조화롭게 함께 일을 진행할 수 있는 매니저 자격을 주는 것이 일반적이라고 생각한다.

특히 내가 몸 담고 있는 IT 프로그래밍 쪽에서는 관리직을 자연스러운경력의 단계로 보지 않고 개발만을 전적으로 담당하고 싶어하는 사람이 많은 것으로 알고 있다. 객관적인통계 자료가 있진 않지만, 주변인을 바라볼 때, 관리직으로넘어가느냐 개발직군으로 계속 남아 있느냐를 두고 고민을 하는 사람이 많은 것이 사실이다.

“개발 7년차, 매니저 1일차” 라는제목을 가진 이 책이 출시되자 마자 주변의 개발직군 동료들이 다양한 SNS 에서 이 책의 출간 소식을알리며 함께 살펴보자 독려하던 모습들은 그동안 많은 동분야 사람들에게 팀원이 아닌 팀장 혹은 매니저로써 어떤 역할을 수행해야 하는지 어떻게 관리하게되는지 혹은 관리에서 만나게 될 문제들은 무엇인가에 대한 시원한 가이드 북이 그동안 없었음을 증명하는 것이 아닐까 싶다.

특히 IT 는 연차별로 쌓이는 경력보다는 새로운 내용을 받아들이고기술에 대한 경험을 많이 습득 하는가에 따라서 실력과 능력이 천차만별로 나뉘어지는 것이 다반사이기에 개발 연차가 쌓였다고 해서 자연스럽게 관리기술까지 늘어나는 것이 아니기에 더더욱 그러하다.

그간 일을 하면서 직간접적으로 느꼇을 많은 일들은 멘토가 나이가 많다 하여 혹은 경력이 많다고 하여 훌륭하게멘티들을 이끌 수 있는 것이 아님을 증명하고 있다.

이 책의 내용을 간략하게 요약하자면, 개발자가 테크 분야에서 리더로써성장함을 기본으로 동시에 다양한 팀원과 팀장, 팀장을 관리하는 관리직의 역할까지 설명하는 일종의 롤플레잉매뉴얼로써 느껴졌다.

다만 한가지 아쉬운 점은 이 책에서 종종 나오는 인사분야의 대처 방법이 서양과 동양의 차이를 적절히 담아내지못했다는 생각을 버릴 수 없었다. 짧은 시간이었지만 해외에서 일을 해 본 경험을 바탕으로 이 책에서의내용은 직원의 채용과 해고가 비교적 자유롭고 실직에 대한 리스크 관리가 공공의 분야에서 잘 갖춘 서양 문화에 어울릴 내용이어서… 종종 고개를 갸우뚱하면서 과연 한국에서(?) 라는 의문이 들었던부분이 있다.

예전부터 다양하게 주장되어온 것들을 확장적으로 살펴보면 XP 에서애자일, 도구로서 칸반과 스크럼, 최근은 OKR 등등.. 서양에서는 개인으로써 프로가 되어 일하는 방식과 팀으로성과를 내는 방향과 지향점, 다양한 시도를 해보고 있는 것들을 시도해보고 있는 것으로 알고 있다. 아울러, 개인적으로도 시도해 본 경험이 있는데, 해외 취업을 위한 구직사이트 내용을 살펴보면, 해당 회사가 어떤방식으로 팀을 운영하고 성과를 측정하는지에 대한 구체적인 안내들이 있던 것으로 기억된다. 이 책의 내용을마치 증명이라도 하 듯 말이다. 당신이 프로임을 증명할 방법이라고 미리 공지를 하는 느낌이랄까.

아직도 행해지고 있는 사실들이지만, 아주 일부라고 믿고 싶다. 아직 한국의 일부 관리자는 팀 관리와 성과 관리를 아직도 제조업의 컨베이 벨트 타입에서나 통할 것 같은 방법으로하고 있는 곳이 많다. 단위 시간을 정해 놓고, 엑셀 시트를꺼내 놓고, 거기에 빗금을 쳐가며, 앉은 자리에서 완성/미완성의 O/X 를 채워 넣는 일로 팀원을 관리/감독하는 형태의 성과관리를 말이다. 아이러니하게도 대부분의 개발자들이혀를 내두르는 SI 현장에서 특히 이 방법은 아주 훌륭하게 동작한다.

최근 들어 IT 업무가 주된 비즈니스의 한 축으로 동작하는 회사들이많아지고, 글로벌화 된 IT 문화를 자연스럽게 받아 들이고, 호칭 문화의 개선으로 대표 될 수 있는 다양한 시도를 통해 평등한 문화를 받아 들이는 곳이 많이 있는데, 평등은 결코 관리직의 부재를 뜻함이 아니라 공동의 권리임과 동시에 책임과 의무의 분산을 의미하는 것이기에 마냥핑크 빛은 아니다. 프로가 되어 책임을 다하고, 그 결과로성과를 가져갈 수 있는 문화가 정착된 곳이 많이 나타나고 있다.

그리하여, 개인이 팀의 구성원으로써 역할과 팀장으로써 역할, 아울러 다른 사람과 함께 어우러지는 다양한 소프트 스킬 등을 이 책에서는 마치 사전처럼 나열하며 알려준다. 이 책의 마지막 페이지에서 결국 책임이라는 것은 결국 자신을 둘러싼 많은 요소들을 관리를 할 수 있는가를 보여주는것이고, 가장 먼저 할 것은 자기관리라는 결론에 도달하게 된다.

뒤통수를 한 대 쌔게 얻어 맞은 기분이 들면서, 이게 정답이 아니라면, 이 세상 그 어떤 무엇이 정답이겠는가? 라는 질문을 던지게 된다. 우리가 만나는 모든 문제들의 해답을 찾다 보면 결국 철학을 찾게 되고, 그철학의 근본은 “나는 누구인가?” 로 시작되지 않는가 말이다.

자신의 현재 위치가 어디든… 누구든 한 번은 읽어 보기를 강권한다. 앞으로 어떤 길을 갈지 누구도 알 수 없지만, 나 자신부터 점검하고알고 준비하고 길을 나서는 사람과 그렇지 않은 사람은 그 길 위에서의 과정은 분명 다를 것이기에…

한빛 미디어 나는 리뷰어 다 를 통해서 이번에는 "개발 7년차, 매니저 1일차" 라는 책을 리뷰하게 되었다.

"개발 7년차, 매니저 1일차".

우선 이 책의 제목부터가 흥미롭다. 

개발자로 일을 하고 있는 사람이라면 언젠가는 겪어야 하는 과정의 한 부분이기 때문이다. 그런데 현실은 그렇게 만만치 않다. 누군가 자세히 설명해주는 사람도 없다. 그러한 과정들이 항상 되풀이 되고 이제 곧 나에게도 다가올 것이라는 생각이 든다.

책은 매니저에서 부터 시작해서 점점 더 큰 조직을 맡게 되면 어떻게 팀을 관리를 해야 하는지, 매니저들은 어떻게 관리를 해야 하는지에 대해서 이야기를 해준다. 그리고 중간 중간에 같은 상황에 대해서 어떻게 대처하느냐에 따라서 상황이 어떻게 달라지는지 비교해서 설명을 해주는 부분들도 있다. 

도움이 되는 Q&A 와 생각해볼수 있는 문제들

각 챕터 중간중간에 위와같이 "CTO에게 묻는다" 라는 소주제들이 있다. 질문과 답변 형식으로 되어있고 실체 처음 관리를 맡게 되는 사람들이 궁금해 할 만한 질문들로 이루어져 있다. 답변들을 천천히 읽다 실제로 우리 주변에서 많이 볼수 있는 일들이어서 공감이 많이 됐다.

그리고 챕터 마지막에는 오른쪽과 같이 질문들이 있어서 한번 생각해보고 챕터를 마무리 할 수 있다.

실제 종사자들의 경험담

많지는 않지만 3편 정도의 기고글이 책 중간에 담겨져 있다. 실제 이러한 일들을 겪었던 분들의 경험담이기 때문에 같은 고민을 하고 있는 분들이나 이야기에서 말하는 상황에 놓인 분들에게 도움이 될만한 내용이다.

이런 분들에게 꼭 권해주고 싶어요.

책을 읽으면서 처음 부터 끝까지 나와 비슷한 상황 또는 고민들에 대한 내용들이 많이 나왔다. 아마 나 또한 직장생활한지 이제 곧 10년정도 되어가고 관리를 해야되는 역할에 다가가고 있어서 그런것 같다. 나는 항상 개발밖에 할수 없으며 무엇인가 관리하는 일들은 정말 나와는 안맞는다 라고 생각해왔다. 아래 글을 잠깐 보자.

딱 내가 생각했던 것들이다. 매니저가 되면 개발할 시간이 줄어들고 여기저기 회의에만 쫓아다녀야 하고. 그런 모습들이 정말 싫었다. 그리고 처음 개발을 할때에는 이러한 업무들은 개발보다 중요하지 않다고 생각을 하기도 했다. 하지만 그건 나의 잘못된 생각이었다. 이건 쉽게 생각할 업무가 아니고 정말 무거운 책임을 갖고 임해야 하는 중요한 일이다. 또 매니저란 역할은 연차가 올라간다고 맡는게 아니라 그 업무를 잘 해낼수 있는 사람에게 맡겨야 된다는 생각이 들었다. 이 책에서도 그러한 이야기를 계속 해주고 있다. 

안타깝게도 실제 우리가 다니고 있는 회사에서는 그런 것들을 배려해주지는 않는다. 그래서 이런 글들을 통해 조금이라도 준비를 할수 있으면 실제 매니저가 되었을때에 아주 조금이라도 덜 힘들지 않을까 생각이 든다. 

이제 곧 매지너라는 역할을 맞이 해야하는 모든 개발자 분들에게 이 책을 적극 권해주고 싶다. 파이팅.

https://blusky10.tistory.com/453

개발자로서의 본인의 능력이 타인의 멘토, 관리자로서의 능력과 일치한다고 보기는 어렵다. 그 방향에 본인이 능력을 가지고 있는지의 여부는, 땅이 알고 하늘은 알겠지만 본인 스스로는 잘 알기 어려운 것이 당연하다. 덕분에 당신이 개발한지 굳이 7년차가 되지 않았더라도, 개발한지 7년이 훌쩍 넘었더라도 이 책은 한번쯤 읽어볼만하다.

개발자로서 일하는 와중에, 인턴이나 신입 혹은 후임과 함께 일하게 되는 것은 당연하고 자연스러운 과정이다. 때로는 여러모로 갖춰지지 않은 선임과 매니저와 일하는 경우가 발생하는 것도 사실이고... 이럴 때는 정말 눈물이 쏟...

이 도서는 분명히 본인이 매니저 혹은 멘토, 테크 리드로서 적합한 자인지 아닌지, 현재까지 그 역할을 제대로 수행했는지 하고 있는지에 대한 회고에 적지 않은 도움을 줄 것이다. 자기 개발서류의 약간의 뻔한 이야기는 포함되어 있지 않느냐고 묻는다면 아니라고는 못 하겠다. 'ㅅ') 후후. 사람들이 일하는 형태라는게 거기서 거기 아니겠는가.

본인이 개발자라면 커뮤니케이션, 팀과 코드 작성을 위한 시간의 분배, 기술 부채의 해결과 운영 등 시간이 갈수록 나이가 들수록, 고려해야 할 불확실성과 이슈 사항은 늘어가고 부담감과 고민, 때로는 죄책감까지도 마음에 쌓이고 있을 것이다. // 그게 아니라면 당신은 행운아 아니면 천재 'ㅅ')!

매니저로서의 자신과 시니어 개발자로서의 자신을 저울질하며 앞으로의 진로를 선택하며 나아가는 과정에 있는 누구에게나, 이 도서는 참고할만한 레퍼런스가 되어줄 수 있을 것으로 생각되어 일독을 조심스레 권해본다. // 개인적으로는 어느 회사에나 존재하기 쉬운 프로세스 독재자에 대한 이야기와, 테크리드, CTO 에 대한 이야기가 흥미로웠다. 'ㅅ')

결론

갑자기 결론이지만, 결국은 나 자신을 잘 관리하는 능력이 요구된다는 내용입니다. 무척 단순한 말일 수도 있지만, 단순한 결과를 도출시키기 위해 필요한 배경에 깔려 있는 과정을 무시해서는 안 된다는 말이기도 합니다. 개발자로서 현장에서 요구되는 코드는 당연한 것이고 사람을 대하는 기술도 코드 경력만큼 필요하다는 것을 자각하면서 읽어야 할 것 같습니다.

국내 IT에서 매니저의 역할은 슈퍼맨

매니저라는 직업은 무척 힘이 드는 직업입니다. 특히 외국과는 약간 다른 위치에 있을 것으로 보이는 국내 개발 환경 실정에서의 매니저는 무척 중노동을 강요당하는 입장입니다. 개발도 책임감 있게 해야 하고, 부하 직원들도 제대로 관리해야 하고, 회의에도 꼬박꼬박 참여해야 하고, 릴레이 회의 뒤의 회의록도 작성해야 하는 등 몸이 두 개라도 모자란 환경에 내몰리게 되는 경우가 많이 있습니다. 정말 잔혹하게 혹사당하는 경우가 비일비재하죠. 이런 환경에서 말이라도 잘 들어주는 팀원이라면 다행이지만 그렇지 않다면 지옥도가 그려지기 시작하는 것이죠. 이 책이 이런 상황에 처해있는 관리자 신입생들에게 조금이나마 도움이 되는 책이 될 것 같다는 생각이 들었습니다.

나의 경험

책의 원서의 배경이 외국인만큼, 국내 실정과는 거리가 있는 내용이 있기도 합니다. 프로그램, 개발자 직군은 아니지만 IT업에 종사한 지 경력이 좀 있다 보니 책에서 다루고 있는 PL 업무를 보게 되는 경우도 종종 있습니다.

책을 읽으면서 공감되는 부분도 많이 있었고 리더에 대해 제대로 배울 수 있는 경험도 없이 갑자기 4, 5명의 팀원을 관리하게 될 경우 대책 없이 시작된 만큼 잘 진행될 리가 없었습니다. 책을 읽으면서 계속 나쁜 기억이 떠오르며 다음에 또 비슷한 자리에 앉게 된다면 지난번과 같은 실수는 하지 않기를 바라며 읽게 되었습니다.

책에 대해서

초판이 2월 4일인데 근 두 달 만에 2쇄 발행이라면, 상당히 잘 나가고 있는 책 아닌가요? 이쪽 분야에서 이런 내용을 다루는 책이 부족했음을 직감할 수 있는 부분이었습니다. 책 선정을 잘한 것 같습니다.

좋은 매니저인지, 나쁜 매니저 인지는 참 판단하기 어려울 수 있습니다. 외부적으로는 좋은 매니저가 내부적으로는 공공의 적 취급을 받기도 하고 그 반대의 경우도 있고 참 어려운 문제이긴 합니다. 업무가 잘 돌아가게 하기 위해 정치적인 부분도 어느 정도 필요하고, 모두의 시선에 지독한 사람이라 손가락질을 받을 수도 있는 위치에 서게 되는 등 정신적 스트레스가 이만저만이 아닙니다.

다시 결론

나이를 나타내는 숫자가 하나씩 늘어남에 따라 사회에서 요구하는 능력치도 같이 올라가게 됩니다. 그 과정에 있는 누구나 경험하게 되는 매니저라는 역할. 업종을 불문하고 경험하게 되는 과정 속에서 개발이라는 특화된 분야의 내용을 잘 정리한 책이라는 생각이 들었습니다. 이 책을 조금 더 매니저의 역할에 대해 고민하게 되었습니다.

언젠가 다시 팀원을 관리해야 하는 상황이 온다면 다시 읽어보게 될 책일 것 같습니다. 현재 개발자이지만 부사수를 관리해야 하는 입장에 있다면, 갑자기 많은 인원을 관리해야 하는 상황이 온다면, 내가 관리하는 팀의 불협화음이 심하다 느껴진다면, 내 팀을 좀 더 좋은 방향으로 이끌고 싶다면 한 번쯤 일독을 권하고 싶습니다.

서평단 책으로 신청을 하면서 제목을 보고 신청할지 말지 고민을 많이 했다. 나는 아직 대학생인데 매니저들이나 읽을 법한 책을 읽어서 얻는 게 있을까라는 생각 때문이었다. 그래서 매니저는 어떤 사람들이 하고 어떤 일을 하는지 알고나 있자는 가벼운 생각으로 신청하게 됐다.

책의 내용은 멘토부터 CTO까지 직책별로 필요한 관리 기술에 대한 내용이다. 팀을 관리, 경영하는 것이 주 내용이고 그 내용 속에 팀원(개발자, 멘티)이 팀에서 어떻게 해야 하는지에 대해서도 이야기한다.

이 책의 초반 ~ 중반까지는 매니저뿐만 아니라 개발자들에게도 도움이 되는 내용이 많아 대학생의 입장에서 내가 신입 개발자가 됐을 때 어떻게 해야 할지를 초점에 두고 읽었다. 책의 후반부는 아직 대학생인 내가 읽기에는 지루한 내용이 많고 너무 먼 미래의 이야기처럼 느껴지기도 했다.

주니어, 신입 개발자가 멘토, 매니저에게 무언갈 얻고 싶은 마음이 있듯이 매니저도 그들에게 기대하는 게 있을 것이다. 책에서는 매니저의 입장에서 팀을 관리하고 경영하는 걸 이야기하면서 동시에 주니어, 신입 개발자들 개발자로서 어떤 자세를 가져야 할지도 알려주면서 굳이 매니저가 아니어도 충분히 읽어볼 만한 내용들이 있다.

미래에 팀을 이끌고 프로젝트를 진행할 매니저 혹은 그 이상을 원하는 대학생이라면 충분히 읽을 가치가 있다. 또 굳이 매니저까지 생각하지 않더라도 책의 내용은 앞으로 개발자로서 살아가는데 필요한 아주아주 기본적인 자세에 대한 이야기도 있어 읽어볼 만하다. 그리고 책에 나오는 매니저로서 갖춰야 할 기술들은 대학생에게도 충분히 필요한 기술들이라고 생각한다. 대학생활 중 진행하는 프로젝트에서도 프로젝트를 팀으로서 진행하게 될 텐데 이 책의 내용들은 도움이 될 수 있다고 생각한다.

개발자 혹은 매니저로서 잘하기 위해서는 나 자신부터 관리해야 한다는 책의 결론 부분이 와닿았다.

서점에서 몇번을 들었다 놨다 한 책이었는데 결국은 읽게 되었다.

읽자마자 느꼈던 것은 너무너무 재밌다! 였다.

주니어라고 하기에도 민망한 아직은 초보 개발자인 입장에서 내가 이 책을 읽어보고 싶었던 이유는 매일매일 만나는 동료들에 대한 마음이 가장 컸었다. 과장님들은 진급할 때 무서움이 없었을까? 팀장님도 처음부터 팀장님은 아니었을텐데.. 같은 생각들 말이다. 나의 팀장님은 장애가 발생해도 냉정하고 침착하게 대응하시며 사람 관리까지 해내시고 그러면서도 늘 팀원들 고생했다고 해주시는 분. 가끔 경험과 마음가짐이 감탄스러워 팀장님은 어쩌다 팀장님이 되셨어요? 여쭤보면 "그냥.. 어쩌다보니 해야되니까 하게 됐네요 ㅎㅎ" 하며 웃으신다. 거절하고 싶어도 언젠가는 관리자가 되어야 한다면 어떤 관리자가 되어야 할지.. 나같은 주니어들이라면 한번쯤은 해봤을 그런 생각들 저자도 똑같이 무서워했고 같은 마음을 겪어보았기에 양쪽 입장에서 서로의 입장을 잘 풀어나간다.

반대로 내 입장에서는 매니저가 될 날보다 팀원으로 일할 날들이 더 많기 때문에 하게 되는 나는 좋은 팀원일까? 업무 + 사람에 대한 고민에 가뜩이나 힘든 팀장님에게 도움이 되는 직원일까? 같은 고민들을 위로해주는 내용들도 존재한다.

개발자 농담에 낄낄 웃게 된 사람이라면 분명 앗 이건 내 얘기 아 이건 내 동료같다! 하며 실실 웃으며 읽게 되는 책이었다. 지금 매니저를 맡고 있는 사람이든 아니든 본인과 팀원들을 생각하며 즐겁게 읽을 수 있는 책이라고 생각한다. 지금 내 입장에선 현재 같이 일하는 분들께 좋은 동료가 되려면 나 또한 어떤 사람이 되어야 할 지 다시금 돌아볼 수 있는 기회가 되었다.



저번달 3월에 이어 4월에 받아서 서평을 작성하는 책은 "개발 7년 차, 매니저 1일 차"라는 책이다.

사실 3월부터 이 책을 읽어보고 싶어 서평단 책으로 신청을 했지만, 아쉽게 다른 책이 선정되어 4월 신청 목록을 보고 바로 신청을 했다.

제목에서 알 수 있듯이 아직 학부생 4학년인 내가 읽어도 될까?라는 의무심이 들게 되는 책이다. 
하지만 내가 읽어보고 싶다고 생각한 이유는 18년도 군 전역후 지금까지 휴학 없이 쉴 틈 없이 학부생 생활을 하고 있다. 
우리 학교는 매 학기 프로젝트형 수업을 진행하면서 팀 프로젝트를 진행하고 있으며, 매 학기 1-3개 정도의 팀 프로젝트를 진행한다.

그 과정에서 어쩌다 보니 나는 팀장이라는 역할을 어느순간 자연스럽게 하고 있었고, 팀원들과의 소통 및 프로젝트 진행에서 좋은 리더란 어떤 사람인가 라는 의무심을 갖게 되던 중 우연히 인스타그램에서 이 책에 관련된 내용을 쓰신 분의 내용을 보고 기회가 된다면 한 번쯤 읽어 보고 싶다는 생각이 들었다. 또한 책 소개 페이지를 보니 아래와 같이 글이 써져 있었기 때문에 더욱더 '무슨 책일까?'라는 생각을 들게 해 주었다

목차

목차에서 볼 수 있듯이 IT분야에서의 팀 관리와 관련되어 작성된 글이다 라고 생각할 수 있지만, IT와 관련된 기술이 아닌 하나의 팀을 관리하는 팀장 혹은 매니저에 대한 글이기 때문에, 어느 분야의 팀장 혹은 매니저 직급을 가진 사람이라면 한 번쯤 읽어보고 '나는 어떠한 리더인가..' 혹은 '어떠한 리더가 되어야 할까..'라는 생각을 하기에 좋은 책이다.

이 책은 장 끝부분에 간단한 체크리스트가 있어 나의 경험을 평가하며 자신에 대해 생각하게 해 준다. 사실 이 부분이 공감은 많이 안되었지만, '리더란 어떤 사람이다'라는 생각을 해주게 된 페이지이다.

이 책을 읽으면서 많은 생각을 하게 되었다.

사람마다 원하는 좋은 리더가 다를 것이다. 또한 나에게 좋은 리더일지라도, 다른 사람에게는 좋은 리더가 아닐 수도 있다.

다시 한번 팀장 혹은 리더라는 직급에 대해 자신의 자리는 책임감이 항상 따른다는 생각을 하게 된 책이었다.

지은이 카미유 푸르니에는 미국 회사에서만 근무해본 개발자이기에

미국인의 관점에서 쓰인 책이지만,

여러 종류의 사내 위계질서와 조직 구조에 대한 이야기가 담겨있고,

관리와 조직 구조가 가지는 가치에 대해서 독자를 설득한다.

개발만 해오던 개발자가 매니저가 되었을 때,

어떻게 해야할지 막막할텐데,

저자는 이러한 사람들을 위해

어떤 매니저가 되어야 하는지, 어떻게 사람을 관리해야하는지

이 책을 통해 알려준다.

그리고 숙련된 매니저는 현재 겪고 있는 어려움에 맞춰

해당 장을 찾아 읽으면 된다는 팁까지 소소하게 준다.

중간중간 담겨있는 CTO에게 묻는다, 좋은 매니저, 나쁜 매니저, 도전 상황을 통해

현실적인 상황들과 조언을 보며 쉬어갈 수 있다.

꼭 개발자가 아니라 직장 생활을 하는 사람들이라면

한번쯤 읽어보면 도움 될 책.

리더라는 것은 참 애매하다. 아래에 있을땐 위로 가면 모든사람에게 잘해주자고 마음을 먹게되지만, 정작 위로 가면 어떻게 해야할지 모르는 경우가 많다. 필자 역시 그런 경우가 많았고. 아직 학부생이고, 인턴경험도 없어 사내의 분위기가 어떤지는 잘 모르지만, 확실히 팀원과 팀장이 가지는 느낌은 무언가 다르다는 생각이 든다. 

우리는 언제나 밑의 개발자로만 있는것은 아니다. 지금 있는 자리가 항상 그대로일수도 없고, 또 연차를 먹게 되면 언젠간 밑에 후배나 인턴 같은 신입들이 들어오길 마련이다. 그렇다고 그들을 그냥 알아서 잘 자라듯이 놔둘수도 없지 않는가. 

이 책은 개발자라면 누구나 겪게될 관리의 모든것에 대해 얘기를 하고 있다. IT서적임에도 개발이 아닌 매니지먼트 관련 얘기를 하는것이 독특하다. 게다가 그냥 간단하게 얘기하는 것이 아니라 세부적으로 애기를 하고 있다. 멘토링부터 사람,팀,매니저 관리하는 법에 조직문화 개선방법까지. 단순 자기계발서로 얘기하기엔 내용도 자세해서 마치 매니저를 잘 하는 법엔 이런것들이 있다는 듯이 소개하는 전문 서적을 보는 것 같다.

사실 아직 학부생이어서 쉬이 공감을 하지 못한 부분이 많기는 하다. 조직문화나 팀 분위기 같은것이 더욱 그랬다. 하지만 조별과제나 동아리 같은 그 동안 경험했던 단체생활과 비교해본다면 이 책에 나온 말이 확실히 맞다는 점이 몇몇 보이곤 한다. 

기업에서 중간급에 위치한 개발자 겸 매니저를 하고 계신 분들에게는 적극 추천하고 싶고, 신입 개발자한테도 후에 좋은 선배가 되기 위한 좋은 밑거름이 될 수있게 해주는 교양도서로의 역할도 잘 할법한 도서라고 생각된다. 개발자라면 기술서적뿐만 아니라 이런 관리쪽 서적이 필요하다고 생각이 들었는데, 이 책이 좋은 해결책을 보여줄 것이라고 생각한다.

"개발 7년차, 매니저 1일차" 책의 제목만 보고 실용서 느낌이 물씬 풍겼다. 궁금하여 원제를 찾아보니 다음과 같았다.

> The Manager's Path : A Guide for Tech Leaders Navigation Growth and Change.

매니저의 길 : 성장과 변화를 모색하는 테크리더를 위한 가이드. 아, 이 책이 무슨 이야기를 하게 될까? 조금 더 느낌이 온다.

"개인적인 경험"이지만 "개발 매니저"에 대한 이야기로 시작해본다.

## 개발 팀장이 됐어요.

개발 팀장은 언제 어떻게 되는 걸까? 그리고 우리나라 개발자의 현실은 또 어떠할까? 관리를 잘해서, 리더십이 있어서, 팀을 잘 이끌 수 있는 능력이 검증되어서 팀장이 되는 경우는 드문 것 같다.

"경력 연차도 어느 정도 쌓였고, 개발 역량도 있으니 이제 관리도 해야 하지 않을까?" 그렇다. 스스로 원해서라기 보다 때가 되었고 개발도 잘한다고 인정받고 있으니 팀장 역할을 떠맡는 게 아닐까 생각이 든다. 또 이렇게 관리의 길로 들어서는 게 "승진"인 우리나라 개발자의 커리어 패스이고 현실이기도 하다.

## 나 다시 (개발자로) 돌아갈래.

개발자로서의 역할과 매니저로서의 역할이 전혀 다른데 이렇게 떠맡게 된 자리에 많은 스트레스를 받는 게 이내 우리나라 개발 팀장들의 현실이지 않을까?

어느새 GOD의 "길"을 들으며,

> 내가 가는 이길이 어디로 가는지 어디로 날 데려가는지 그 곳은 어딘지...

  알 수 없지만~ 알 수 없지만~ 알 수 없지만~ 오늘도 난 걸어가고 있네~~

하루에도 열두번씩 행복했던 그리고 원하던 개발을 맘껏 하던 개발자로 다시 돌아가야 하나 진지한 고민을 해보지 않은 개발 팀장은 없지 않을까?

## 매니저의 길을 알려주마.

이렇게 개발 팀장이 되었는데 과연 잘할 수 있을까? 스스로에 대한 대답은 "아니오."이다. 개발은 많은 레퍼런스와 문제 해결을 위한 과정들을 함께 고민하고 알맞은 해결 책을 찾아나갈 수 있는 반면 관리란 눈에 보이지 않는 무형의 것으로 사람과 조직을 관리하며 회사와 조직의 목표를 달성함은 물론 개인의 동기부여와 성장까지 이끌어야 하는 -내 몸 하나 챙기기 어려운 이 시대에- 진정 리더의 모습이 필요하다.

이 책은 바로 이런 조직 그리고 개인의 성장과 변화를 이끌 수 있는 테크 리더를 위한 친절한 안내서와 같은 책이다. 대인관계, 소통, 리더십 등 소프트 스킬은 물론 신입 멘토링을 시작으로 테크 리드, 팀 관리까지의 주옥같은 팁들, 더 나아가 역할 레벨이 올라감에 따라 더 많은 팀, 매니저 관리, CTO의 역할과 책임은 무엇인지 저자의 경험을 살려 친절하게 설명하고 있다.

## 통찰, 그리고 시도해보기

작은 개발 팀을 관리하는 리더로서 이 가이드를 보고 이제 나는 무엇을 해야 할까? 책에 나온 "알파긱"이란 모습에 스스로가 투영되었다. 자의든 타의든 내가 갖게 된 리더라는 역할에는 큰 권한이 주어지며 그 이면에는 더 큰 책임과 의무가 함께 주어진다는 것을 다시 한번 생각해보는 계기가 되었다.

또 이 책의 부제가 "A Guide for Tech Leaders Navigation Growth and Change."인 것처럼 내가 지금 테크 리더, 매니저로서 올바르게 잘 가고 있는지 되돌아볼 수 있는 친절한 안내서이다. 안내서에 나와 있는 다양한 전략들, 지침들을 시도해보고 내 상황과 환경에 맞게 적용시켜보는 것. 책을 덮고 나니 또 하나의 숙제가 남았다.

## 매니저 또 하나의 길

매니저의 길로 들어선 수많은 개발자들에게 매니저의 숲에서 헤매지 않고 잘 헤쳐나갈 수 있게 도움을 줄 수 있는 입문서로써 매우 추천한다. 번역의 질도 괜찮다. 다만 책의 제목은 원제가 이 책을 더 잘 설명해 주는 것 같아 다소 아쉽다.

 개발자에게 관리라는 것이 떠맡게 되거나 기피하는 대상이 아닌 또 다른 영역으로 도전하고 싶은 그런 역할이 되면 좋겠다. 그 경험을 통해 개인은 물론 팀, 회사의 성장과 변화를 이끌고 더 넓은 안목을 얻게 된다면 우리나라 개발 문화가 한층 성숙해질 수 있는 계기가 되지 않을까?

속이 시꺼매질 일이 있던 차에 발견한 책입니다.

안녕하세요, 괴짜 개발자 namedboy 입니다. :)

제가 오늘 리뷰할 책은 `개발 7년차, 매니저 1일차` 라는 책입니다.  

저는 사실 그동안 왜 이런 책이 국내에 없었을까 싶을 정도로 이런 내용을 다루는 책이 반가웠습니다.  

책의 내용이 좋고 나쁨을 떠나서 드디어 국내에서도 관리자의 역할에 대해 고민하고 있다는 반증이라는 생각에서 입니다. 

국내에서 개발자로 일을 하다 보면 언젠가는 팀 관리에 대한 요구사항을 만나게 됩니다.  

회사에서는 좋든 싫든 관리자 역할을 요구하게 되는 것이지요. 당연히 그 이유는 일을 잘하는 직원은 많지만 관리를 잘하는 직원은 찾기 힘들기 때문이지 않을까 싶은데요.  

사실 요구사항만 있지 어떻게 해야 관리를 잘 할 수 있는지에 대한 내용은 국내에선 잘 다뤄지지 않는 것 같습니다.  

특히나 회사에서 관리자라는 역할은 `그냥 대충 일 잘하는 사람이면 다들 할 수 있는 것 아닌가?`라는 생각을 많이 하시기 때문에 맡은 업무를 잘 하는 직원에게 관리자 역할도 덤으로 주는 것 같네요.  

하지만 관리자로 하게 되는 일들 또는 "업무" 입니다. 관리자가 하는 업무인거죠. 단순히 일을 잘하니까 다른 사람들 관리도 하세요. 라고 할 수 있는 일이 아니라는 겁니다. 때문에 해외에서는 관리에 대한 자격증도 존재하고 관리를 할 때 어떻게 해야 하는지에 대한 교육도 이루어지고 있습니다. 대기업에서는 HR 부서에서 이런 내용을 다루기도 합니다. 하지만 우리나라 사람들이 가지고 있는 관리자에 대한 개념은 이런 전문적인 일이라는 인식은 많이 떨어지는 것 같습니다.

기본적으로 관리자가 되는 과정에 대해 제대로 가르쳐 주는 곳이 잘 없기 때문이기도 합니다.  

그런 의미에서 이 책이 정말 반가웠고 마음이 들떠서 읽게 되었습니다.  

개발자로 오랜 기간 일을 하다 보면 팀 리더로 일을 하게 되거나 그냥 현업을 지속하거나 둘 중 하나의 길을 선택하게 됩니다. 개인의 성향 또는 커리어에 따라 결정하게 됩니다.  

기술직으로 계속해서 경력을 쌓고 싶은 사람이라면 경력이 많아도 기술직으로 일을 할 수 있는 회사에 있어야 할 것입니다. 보통은 그런 커리어를 쌓게 두지 않기 때문입니다. 보통의 회사는 경력이 5년 이상 되면 관리직의 요구사항을 직원에게 요구합니다. 그렇게 되면 반 강제적으로 관리직을 겸해야 하죠. 관리자는 기술직이 아니기 때문에 관리에 대해 전혀 생각해보지 않았다면 그 때부터 지옥이 시작된다고 생각합니다. 이런 상황이 되면 당사자는 완전히 새로운 업무를 하는 것처럼 느껴지게 됩니다. 기술직으로 일을 할 때는 하지 않는 일들을 하게 때문인데요.

그런 일들은 상사에게서 욕을 들어가며 배우거나 해보면서 알게 되는 거라며 그런걸 가르쳐 주는 곳이 어디있냐고 얘기를 하는 곳도 있긴 합니다.

기존에 힘들게 배웠던 분들이니 그렇게 얘기할 수도 있다고 생각합니다. 하지만 지금은 아니라고 말씀드리고 싶네요.  

그런 내용이 바로 이책 `개발 7년차, 매니저 1일차`에 담겨있다고 생각이 듭니다. 내가 관리자의 역량을 키우고 싶거나 CTO 또는 관리직을 생각하고 계시다면 이 책을 읽어보는 것을 강력히 추천드립니다. 정말 피가되고 살이 되는 책일 것이라 자부합니다.

저는 개발자로 10년이 넘게 일을 해오고 있습니다. 그렇기 때문에 개발자가 관리직으로 올라서야 할 때 무엇을 해야 하는지에 대해 몇 년 전부터 계속해서 고민을 해오고 워크샵이나 교육들을 들었었는데 이 책에 그런 내용들이 고스란히 담겨 있는 걸 보고 많은 간접 경험을 할 수 있었고 매니징을 어떻게 해야 하는가에 대해 꽤 많은 인사이트를 얻을 수 있었습니다.

관리직을 생각하고 계시다면 이 책을 추천드립니다.

"개발 7년차, 매니저 1일차"

제목을 보자 마자 느낄수 있었던건 부사수된 입장, 리딩 당하던 입장에서 벗어서 이제는 다수의 팀원을 이끌수 있는 리더십에 대한 이야기라 생각했다.

특히 "개발만 해왔던 내가, 어느 날 갑자기 '팀'을 맡았다!" 라는 상황에 놓였을 경우를 생각해보니, 사실 아찔한 생각이 들었다.

지금 가지고 있는 지식으로, 지금 가지고 있는 스킬로 나라면 어떻게 할까? 특히는 사람과의 관계가 가장 어려운 부분인데 이 부분은 어떻게 해결해야 할까?

고민에 대한 답을 찾을수 있지 않을까 라는 생각이 들었다. 

리더의 입장에서 다수를 이끈 다는건 쉽지 않은 일이고, 아직까지 그런 상황을 경험하지는 못했다. 앞으로 언젠가는 이런 상황의 입장에 놓이게 된다는 생각으로 책을 접하게 되었다.

이 책은 아래와 같이 도움을 받을 수 있다.

. 사수, 멘토, 팀장, CTO 까지 직책별 관리 기술 대백과

. 개발자도 꼭 알아야 하는 소프트 스킬, 사람 및 조직 관리 노하우 수록

. 개발팀을 성공으로 이끄는 IT 팀장에 대한 모든것

먼저 이책은 카미유 푸르니에라는 렌트더런웨이의 CTO 역할을 했던 분이 저자이다. 

사실 우리나라와 외국의 상황이나 팀 문화 등이 다르다는 것은 이미 좀 알고 있기 때문에 우리나라 정서와 맞을까라는 의문도 들었다. 

자, 좀더 살펴보자. 이책은 이런 분들을 위한 책이다.

. 개발자 VS 매니저 갈림길에 서 있다

. 개발자 관리를 체계적, 효율적으로 하고 싶다

. 내 사수가 사수 역할을 못해서 내가 고생 중이다

책의 가장 첫장에는 친절하게도 이 책을 읽는 방법에 대한 가이드를 설명해 주고 있다. 

장별로 있는 방법과 매니저의 경험에 따라 읽는 방법을 가이도 해주고 있고, 중간에 "CTO에게 묻는다", "좋은 매니저, 나쁜 매니저", "도전 상황"에 대한 코너도 마련하여 여러 상황에 대한 노하우를 얻을 수 있었다.

책을 읽으면서 가장 떠오르는 단어가 있다면 "소통" 이라는 단어가 머릿속에 맴돌았다.

항상 매니저라 하면 방패막, 팀원들의 우산이 되어 줘야하고 뭔가 책임을 져야하는 무거운 자리 임을 생각하고 있었던 내게 이 책은 꼭 그런것 만은 아니다라는 생각을 들게 했다.

매니저는 팀원들이 핵심 목표를 이해 하고 이에 집중하도록 도와 줘야 하지만 모든 것에서 보호해야 하는것은 아니다. 때로는 스트레스의 일부를 팀에 전달하여 처한 상황을 함께 이해할 필요도 있다는 것이다.

그리고 가장 쉽지 않다고 생각했던게 어쨋든 갈등들은 항상 생기는 문제인데 이것은 어떻게 생각해야 할까라는 부분이었다. 이책은 내가 매니저일때 할수 있는 생각들에 대한 답변을 주고 있었다. 

회사내 어떤 위치에 있던지 마주하게 되는 어려움들이 있다. 이러한 어려움을 이겨낼 수 있도록 상담해 주는 책이라는 생각이 들었다. 매니저의 마음을 이해 할 수 있는 계기가 되었고 또한 좋은 매니저로서 나 자신과 그리고 팀원들과 소통할 수 있는 방법들에 대한 생각을 정리하게 만들어주는 시간이었다.

그리고 마지막 결론 부분에 기억에 남는 말이 있다면,

다른 사람을 잘 관리하기 위해서는 나 자신을 관리할 수 있어야 한다는 것..

훌륭한 매니저는 갈등을 잘 해결해야 한다는 점 (대화할때 자존심을 잘 분리한다는 의미)

사람들에 호기심을 가져라. 프로세스에 호기심을 가져라. 기술과 전략과 비즈니스에 호기심을 가져라.

항상 호기심을 품고 좋은 매니저가 되기 위한 준비를 해야겠다.

책 제목을 보는 순간 개발 8년차인 나와 비슷한 눈높이에서 많은 조언을 얻을 수 있을 것 같다는 생각이 들었다. 사실 나는 아직 매니저 역할은 하지 않고 있고, 아직 먼 얘기라고 생각하고 있지만 나와 비슷한 연차에서 매니징을 하시는 분들도 많기 때문에 그 분들은 어떤 고민을 하고 있을지 또 어떤 판단과 결정을 내리고 있는지 궁금했다.

책을 읽으면서 매니저에 대해 내가 생각하지 못했던 부분들이 참 많다라는 것을 느꼈다. 그 동안은 매니징을 받는 입장이었기 때문에 매니저 입장에서는 거의 생각을 해본적이 없었던 것 같다. 왜 팀장님은 저런 지시를 내리고 지난 번에는 이 업무가 꼭 필요하다는 듯이 얘기했으면서 갑자기 우선순위가 떨어지니 다른 업무를 먼저 하라는 지시를 내리는 것인가, 그리고 왜 내 일정은 고려하지 않고 일정을 결정하고 통보를 할까 등등 이해하기 어려운 부분들이 있었다. 어느 장단에 맞춰서 업무를 해야하는지 파악하기가 어려운 부분도 있었다. 그래서 이러한 것들 때문에 불만이 많이 쌓이기도 했고, 내 입장만을 생각했던 것 같다.

이 책을 읽으면서 작게나마 팀장님들의 고충을 이해할 수 있었다. 회사는 내 위주로 돌아가는 것이 아니고, 팀장 입장에서는 나 말고도 매니징해야하는 직원들이 많이 있다. 팀장님 또한 오더를 받는 입장이고, 이에 따라 일정은 언제든지 바뀔 수가 있는 부분이었던 것이다. 이런 내용을 일일히 다 팀원들에게 설명하기에는 업무량이 너무 많고 체력적으로도 힘든 부분이 있었기 때문에 팀원들 입장에서는 갑자기 일정이 바뀐다거나 중요했던 업무가 한순간 사라지는 등과 같은 일들이 발생했던 것 같다. 책에서 팀장님도 사람이고 팀장님도 짜증을 낼 수 있고 팀원들은 가끔은 팀장님에게 휴가를 줄 수 있어야한다는 내용이 있는데 많은 생각이 들게 했다.

이 책은 사실 매니저로 들어서는 개발자 뿐만아니라 팀원으로 업무를 하고 있는 개발자들에게도 많은 도움이 되는 책이다. 왜냐하면 팀원으로써 가져할 자세나 마음가짐, 그리고 후임 또는 새로운 개발자가 들어왔을 때 알아두면 좋은 점들, 나를 발전시키기 위한 팁 등등 정말 많은 정보를 담고 있고, 이 내용들이 모두 저자의 경험과 시행착오로부터 나왔다는 것이 독자에게 큰 도움을 줄 수 있다고 생각한다.

나는 아직 매니저는 아니지만 이 책을 읽고나니 한번 도전해보고 싶다는 생각이 들기도 했다. 원래 나의 꿈은 나이 들어서까지 개발을 하는 것이었는데 책에도 언급되어 있듯이 마냥 어렵게 느껴지는 매니징이 겪어보지 않고는 나에게 적합한지 아닌지를 판단할 수가 없는 것이다. 개발을 엄청나게 잘하는 사람도 매니징 능력은 정반대일 수 있는 것이고, 개발은 어느정도 하지만 자기도 몰랐던 매니징 능력을 발견할 수도 있다. 나 또한 매니징은 한번도 해보지 않았기 때문에 지금까지는 나와는 맞지 않는 업무라고 생각해왔지만 겪어보지 않고는 모르는 일이라는 생각이 들었다. 기회가 된다면 매니징 업무를 해보는 것도 큰 도움이 될 수 있을 것 같고, 책에서도 얘기하듯 매니징 업무로 간다고 해서다시 개발을 할 수 없는 것은 아니기 때문에 맞지 않는다는 생각이 들면 다시 개발 업무도 할 수 있을 것이라 생가한다.

어쨋거나 중요한 것은 현재 나의 위치에서 잘할 수 있는 방법을 찾고, 항상 더 나아지려고 노력하며 나와 팀원들, 그리고 회사에 기여하는 것이다. 이러한 노력들이 쌓이면 개발이든, 매니징 업무든 잘해낼 수 있을 것이라고 생각한다.

올해도 한빛미디어 나는 리뷰어다에 신청을 했는데 당첨이 되어서 너무 좋았습니다.

신청한 책 중에 올해 들어 꼭 읽고 싶은 책이 있었는데 다행히도 이 책이 당첨되어서 너무 좋았어요

그 책은 개발 7년 차 매니저 1일 차라는 책입니다.

일단 이 책을 선정한 이유는 작년에 잠시 팀장님이 그만두셨을 때 임시로 팀장 대행을 역할 하였습니다.

처음으로 동료들이 아닌 팀장 대행 역활로써 동료들을 대할 때가 너무 달랐고 당황스러운 것도 많았습니다.

이 책을 읽다 보면 책의 내용 중에 자신의 경험 평가하기라는 챕터가 끝나갈 때 나오는 내용인데 생각을 많이 하게 되는 것 같습니다.

이 책은 저와 같이 시니어 개발자분들도 꼭 읽어 보셨으면 좋겠습니다. 우리나라에서 경력이 쌓다 보면 언젠가는

팀을 이끌 팀장 역활이 올 수 도 있을 겁니다. 그때 당황스러울 수도 있지만 이 책을 읽다 보면 다양한 케이스의 사례를 예시로 이야기가 나오고 또한 저자의 다양한 경험이 녹여져 있는 책입니다. 여러모로 도움이 많이 될 것입니다.

또한 개발 직군이 아니더라도 관리의 다양한 사례와 내용이 많음으로 관리자 직급의 여러 업종의 사람들이 읽어도 좋을 것 같습니다.

그리고 이 책에서 제가 좋았던 점은 개발자가 관리자가 되더라도 언제나 다시 개발자로 돌아오도록 항상 기술 트렌드와 자기계발에 열심히 해야 한다는 내용이 있어서 많은 공감을 하게 되었습니다.

이렇게 좋은 책을 추천해주신 한빛미디어 관계자분들께 감사드립니다.

“현대의 소프트웨어 개발은 팀 스포츠입니다. 매니저는 ‘코치’이자 ‘지지자’가 되는 것이 가장 좋습니다. “
 책의 앞부분에 있는 ‘한국 독자에게’ 코너에 있는 이 말은 이 책을 통해 저자인 카미유 푸르니에가 하고자 하는 말을 함축적으로 나타내고 있다. 대부분의 직장은 나 혼자만 잘해서 성공하기 어렵다. 단기간이나 또는 특정 업무, 소규모 프로젝트에서는 뛰어난 누군가에 의해 성공으로 비춰질 수도 있지만, 장기적으로 보면 조직과 그 조직에 속한 구성원들이 성공하기 위해서는 같이 업무를 수행하는 구성원들이 같은 목표를 향해 달려나가야 한다. 저자가 말했듯 팀플레이가 제대로 되어야 하는 것이다.
 누군가와 함께 일을 한다는 것은 공식적이던, 비공식적이던 지에 관계없이 일을 시키는 역할과 그에 따르는 역할이 존재하게 된다. 일을 시키는 사람은 같은 팀의 선배일 수 도 있고, 팀장일 수도 있고, 조직에서 더 높은 상사일 수도 있다. 이 책은 소프트웨어 개발 조직에서 일을 시키는 사람의 입장, 즉 관리에 초점을 맞추고 있다.
 전체 10개의 파트로 구성된 이 책은 점차 조직의 상위 관리자로 나아가는 방식을 취하고 있다. 팀 내에서 멘토 되기, 훌륭한 테크리드가 되는 방법, 매니저가 되어 팀을 관리하기, 여러 팀을 관리하고, 또 매니저들을 관리하는 방법 끝으로 개발 부사장, CTO 등 최고 책임자로서의 역할과 책임에 대해 다루고 있다.
 책의 초반부는 마치 내 이야기 같아서 흥미로웠고, 중반 쯤은 내가 속한 조직의 상사들을 떠올릴 수 있어 재미있었다. 그 뒤의 이야기는 아직은 먼 미래의 이야기 같은 느낌에 몰입도가 떨어진 것도 사실이다. 하지만 곁에 두고 조직의 구성원과의 관계에서 어려움을 마주할 때 꺼내어 볼 만한 책임에는 틀림이 없다.

개발 7년차, 매니저 1일차

작가

카미유 푸르니에

출판

한빛미디어

발매

2020.02.04.

리뷰보기

 코로나로 재택근무를 하는 중인데, 집에서 있는 시간은 분명 많아졌지만 일하는 시간이 상대적으로 많아서 그런지 쉬거나 독서할 시간이 부족해진 느낌이다.

 이 책은 SNS에서 임백준님의 글로 먼저 접하게 되었다. 그 글이 인상 깊었던 건지, 나의 현재 상황에 어느 정도 투영되어서인지 책을 한번 보고 싶었다. 마음이 넓고 그릇이 커야 한다는 부분이 특히 마음에 와닿았다. 

 수 년 간 개발만 한참 하다가 최근 들어서야 딱히 직책은 없지만 파트장 역할을 맡아서 개발자 몇 명과 함께 업무를 보고 있다. 다른 팀과 공유하는 내용이 많은 업무다 보니 얽힌 사람, 얽힌 코드가 무척이나 많은데, 업무 자체의 양도 많아서 스트레스를 많이 받고 있다. 스트레스를 많이 받으니까 자꾸 남 탓을 하고 싶어지고 속이 좁아진다는 느낌을 받던 차에 이 글을 읽을 수 있어서 마인드 컨트롤을 더 잘 해보자는 의지가 생긴다.

 알파긱이라는 용어는 처음 접해봤는데, 장점들을 보며 나랑 비슷한데?라는 생각을 하다가도 단점을 보면 어 이것도 나랑 비슷하네라는 느낌을 받았다. 여기서 설명하는 알파긱은 좋은 경우도 있지만 폐쇄적이고 자기중심적인 그런 면이 좀 더 부각돼 보인다. 나는 장점에 좀 더 가깝다고 생각해본다. 사회생활을 하면서 느낌적으로만 알고 있던 어떤 현상(?)에 대해 이렇게 명확한 용어와 개념을 알게 되면 스스로에 대해 좀 더 정확한 분석이 가능해지는 느낌을 받는다. 

 3장 정도까지는 딱 매니저 역할을 시작하는 사람에게 알맞은 내용인 것 같고, 그 뒤 이야기는 어느 정도 매니저를 경험해본 사람에게 많은 도움이 될 것 같다. 멘토, 매니저, 테크 리드, 시니어 개발자 등 다양한 역할에 대해 각각의 장단점과 이상적인 업무 생활에 대해 잘 설명해준다. 아마 회사 생활을 어느 정도 해본 사람은 공감되는 내용이 아주 많을 것이다.

 어떤 역할에 대해 어떤 어떤 업무를 해야 한다라든지 정확한 평가 기준에 대해 정확하고 수치적으로 설명해주지는 않지만 어떤 방향으로 어떤 내용에 대해 생각해봐야 하는지 경험적으로 제시해준다. 역할이 바뀌면서 맡아야 하는 업무는 어느 정도 스스로 파악할 수 있지만, 장점이나 단점 시행착오 등은 이 책에서 소개해주는 여러 경험자의 얘기를 들어보는 게 많은 도움이 될 것이다. 챕터 뒷부분에서는 자신의 경험을 기억해내고 한번 더 고민해볼 수 있는 질문지가 있어서 생각을 정리하는데 도움을 준다.

◈ 이 책은 한빛미디어의 <나는 리뷰어다> 이벤트로 지원받은 도서 리뷰입니다.

[한 줄 평]

"모든 IT인의 길잡이 책"

[도서 리뷰]

처음 "개발 7년차, 매니저 1일차"라는 책을 접했을 때, '나에게는 조금 이른 책이 아닐까'라는 걱정이 들었습니다.

이제 막 경력 3년차를 바라보고 있는 IT인에게는 "관리"라는 단어는 낯설고 두려운 단어였기 때문입니다.

두려움을 안고 펼친 책의 목차를 훝던 중에 가장 관심을 끈 항목은 "2장 멘토링"이라는 주제였습니다.

이제 막 신입사원을 맞이한 초보 사수로서 여러 난관에 봉착한 상황이었기에 단숨에 읽었습니다.

덕분에 멘토링의 중요성과 멘토의 책임감에 대해서 무겁게 와닿았고

'나는 좋은 멘토가 될 수 있을까?'라는 걱정에 대하여 세세하고 좋은 방안을 안내주고 있었습니다.

이 책은 IT인이라면 한번쯤 겪을만한 여러 문제사항과 그에 대한 방안에 대해서 명쾌하고 세세하게 가이드하는 책입니다.

앞서 IT인의 길을 걷고 있는 선배들이 풀어놓은 경험담에서 문제를 현명하게 해결할 수 있는 많은 꿀팁을 얻을 수 있습니다.

그로인해 '나에게 조금 이른 책이 아닐까'라는 의문은 사라지고 '지금 읽어야하는 책이구나'라고 생각이 바뀌었습니다.

앞으로 경력을 쌓아갈수록 인간관계나 의사소통과 같은 다양한 문제에 직면하게 될 것입니다.

그런 류의 문제는 기술적인 문제와 다르게 직접 경험해보기 전에는 해답이 보이지 않는 경우가 대다수이며 답을 알더라도 대처하기 힘든 상황에 놓일 수 있습니다.

"개발 7년차, 매니저 1일차"라는 책을 통해 

문제사항에 대해서 '나라면 어떻게 대처할까' 고민하고

'어떻게하면 더 좋은 동료로 성장할 수 있는가'에 대해 계획해보고 

'이런 나쁜 동료로 남아서는 안되겠다'라는 다짐을 키울 수 있는 기회를 얻게 되었습니다.

[도서 추천]

주니어 IT인에게 이 책을 추천하고 싶습니다. 

앞으로 어떤 시니어로 성장할 수 있을지에 대해서 진지한 고민과 방안에 대해서 길잡이가 되어 줄 것이라고 생각됩니다.

개발자는 아니지만, 소프트웨어 관련 직군에서 일하고 있는 사회 초년생의 관점에서 이 책을 읽었다.

어떻게 보면 지금 이제 막 회사에 적응하고 일을 배워가고 있는 단계에 개발 7년차에 매니저 일을 하게 된 사람의 이야기가 완전히 와닿았다고 보긴 어려울 것이다.

하지만 사회 초년생의 입장에서 이 책을 보았을 때, 조직이 어떻게 운영되고, 윗 사람이 자신의 부서를 어떻게 관리하려고 하는지를 알 수 있었다.

사실 회사에 갓 들어간 나로써는 내가 하는 일에만 집중해도 모자란데, 그런 큰 그림을 볼 생각조차 없었다.

하지만, 이 책을 읽음으로써 '아, 윗사람이 사람을 보는 시각은 이렇구나', '난 이런 사람이 되지 말아야겠다' 이런 생각을 하면서 자신을 되돌아보게 되었다. 

네이버 블로그에 '개발 7년차, 매니저 1일차'에 대한 포스팅을 한 적이 있습니다. (네이버 포스팅 보러가기) 이 당시엔 모든 내용을 정독하진 못했고 일부 내용을 보고 포스팅을 작성했었는데 이번엔 어느정도 책을 읽고 다시 포스팅을 해보려 합니다.

<깔끔한 표지>

<SETP BY STEP>

'개발 7년차, 매니저 1일차'는 관리자가 가져야할 스킬에 대한 것은 물론, 적절한 예시를 통하여 이해하기 쉽게 글을 풀어나가는 방식을 취하고 있습니다. 흔히 기술서적은 특성상 딱딱하다고 느껴지는데, 이 책은 기술서적이긴 하지만 결국 '사람 대 사람'을 대하는 방식에 대해 언급하고 있기 때문에 꽤나 읽기 편하게 느껴집니다. (개인적으로 외국저자의 책들은 대부분 읽기 편한것 같습니다.)

다만 책의 저자인 카미유푸르니에가 '한국 독자에게' 라는 별도 파트에서 언급했듯이 미국 개발회사에 맞추어 만든 책이기 때문에 국내와는 상황이 조금 다를 수도 있습니다. 저자는 자신의 책이 한국어로 번역이 되어 놀랐다고도 하니, 책이 한국의 상황에 고려하지 않은 상태로 발간된 것은 분명합니다.

<그럼에도 불구하고 이 책은 분명 관리자라면 도움이 될만한 소스로 가득 차 있습니다.>

책의 내용에 대해서는 현재 필기를 병행하여 공부중입니다. 공부한 내용을 바탕으로 따로 포스팅을 연재할까도 생각중인데, 우선 지금 진행하고 있는 프로젝트가 막바지라서, 이 프로젝트가 끝나면 본격적으로 연재를 진행할 예정입니다. (포스트 발행을 네이버에서 할지, Blogger에서 할지는 좀 더 고민해봐야겠습니다.)

책의 내용에 대해 궁금하신 분들이라면 꼭 구매해서 읽어보시거나 추후 제가 연재할 포스팅을 기다려주시기 바랍니다. 기다리기 어려우신 분들이라면 아래 링크를 통해서 책을 구매하실 수 있습니다.

<한빛서점에서 책 구경하기 - 이미지 클릭>

오래간만에 매니저에 대해 볼 만한 책이 출판된 것 같습니다. 한동안 제 책상에 자리잡고 있을 것 같네요 ^^ 좋은 책을 제공해준 한빛출판네트워크측에 이 자리를 빌어 감사의 말씀을 드립니다.

개발자로서 참 많이도 경력을 쌓아왔지만 아직도 올해 막 들어온 신입사원만큼이나 잘 못하는 게 있다. 바로 누군가를 관리하는 일이다. 사람이 사람을 관리 즉 매니징 하는 것이란 참 불편하고 번거롭고 어려운 일이다. 특히나 나처럼 내성적이고 말을 조리 있게 하지 못하는 사람은 고역도 이런 고역이 없다. 오죽하면 식당에 가서도 불편한 점을 내색하느니 차라리 그냥 조용히 먹는 편을 택하는 게 편하다. 

그러나 일에 있어서 그런거 없다. 나의 성향이 그렇더라도 하기 싫어도 맡은 자리의 역할이 그렇다면 해야 하는 게 프로가 아니겠는가. 회사 내에서 뭔가 직급이 올라가면서 책임을 지는 자리가 되었던지, 하는 일이 매니저라면 한 번쯤 읽어 보면 괜찮을 거 같다. 

책 제목 맘에 든다. 개발 7년차, 매니저 1일 차

개발자로서 역량은 많지만 사람 관계는 꽝인 나와 비슷한 상황이랄까? 명확하게 의사소통하는 법이라던가 멘토로서의 마음가짐 같은 것들을 나열하는데, 전부 정독하기보다는 그냥 심심할 때 쉬는 시간에 가볍게 읽기 좋다. 

한빛 미디어 <나는 리뷰어다> 3월!

오랜만에 책 택배가 집에 도착했다. 지난 2월 한빛 미디어에서 하는 <나는 리뷰어다> 에 참가 신청을 했었는데 선정되어 2020년 1년 간 활동하게 되었다.

미션 신청할 때 3권의 도서를 신청하고 랜덤으로 1권을 받게 되는데 꼭 3권을 고를 필요는 없기에 나는 2권만 선택했었다. 기대되는 시간이 지나 도착한 책.

'개발 7년차, 매니저 1일차'

페이스북에서 간간히 이 책이 보여 재밌을 것 같다는 생각을 했었는데, 좋은 기회에 이 책을 받게 되었다.

이 책은 매니저가 된 개발자를 위해 매니저로 성장하면서 겪는 여러 문제를 사례와 조언을 담았다. 또 소프트 스킬이 부족한 사수를 둔 개발자를 위해 사수에게 어떤 도움을 받을 수 있는지에 대한 내용도 담겨있다. 책의 표지에 귀여운 사람 그림이 그려져 있는데 지금 보니 눈 부분이 조금 무섭다....

이 책에는 <한국 독자에게>가 있다. 한국어 외에도 러시아어, 독일어, 일본어까지 번역되는 사실에 놀라며 하며 말미엔 이런 내용을 남겼다.

세계 어디서든, 회사의 문화가 어떻든, 개발 관리는 힘들고 외로운 업무입니다. 이 책을 혼자 읽기보다 친구와 동료들과 함께 읽기를 추천합니다. 제 경험으로는 업무의 어려움에 대해 다른 매니저들과 의견을 나눈 방법이 관리를 더 잘 할 수 있도록 이끄는 데 최고의 방법이었습니다.

 

- 카미유 푸르니에

저 내용이 공감됐다. 개발 관리는 힘들고 외로운 업무다. (내가 해본 건 아니지만...) 그래도 일이라는 게 혼자 하는 것 같지만 혼자 하는 게 아니지 않은가. 나도 읽어 보면서 혼자 읽는 것 보다 여럿이 읽고 이야기하면 더 뜻깊은 독서가 될 것 같았다.

좋았던 점

좋은 매니저, 나쁜 매니저

• 개발 매니저들이 팀이 성장하고 목표를 달성하기 위해 본래의 목적에서 벗어나 바람직하지 못한 방향으로 가는 나쁜 습관들을 파악하고 이를 극복할 수 있는 전략을 알려주는 코너다.
• 이 코너에서는 위에 설명된 대로 나쁜 습관을 파악하고 극복하는 전략을 알려주는데 사실적인 예제를 가지고 설명하기 때문에 이해도 잘 되고, 아 이런게 나쁜 습관이구나, 나쁜 매니저가 이런 행동을 하게 되는 구나 하고 알게 된다.

2장 멘토링

• 이 장에서는 멘토링의 중요성과 멘토링을 어떻게 해야하는 지 설명하는 장인데 멘토, 멘티, 멘토의 매니저를 위한 팁을 제공해 모두가 적용할 수 있는 장이다.
• 회사 입사하게 되면 멘토/사수 이런 관계가 만들어지는 데 그때 실질적으로 어떻게 해야하는지 알려주는 장이라 좋았다.

아쉬웠던 점

책 뒷면 "이런 분들 필독!" 에 '내 사수가 사수 역할을 못해서 내가 고생 중이다.' 라는 문구가 있었는데 읽는 중에 저 부분에 해당되는 내용은 아직 많이 발견하지 못했다..해야하나 쓰다보니 저런 생각을 가지고 있는 사람이 읽는 거라면 이렇게 하면 좋은 매니저가 될 수 있다고 일러주는 책같다. (주절주절)

총평

함께 읽었을 때 더 가치있는 책

일을 잘 하는 사람과 일하는 팀의 매니징을 잘 하는 사람은 같을 수도, 혹은 다를 수도 있다. IT 업계에서 시키는 일만 잘 하는 사람이 있고, 코딩을 잘 짜는 사람이 있으며, 사람 관리를 잘 하는 사람도 있고, 코딩을 잘 하며 사람 관리를 잘 하는 사람도 있기 마련이더라. 중요한 건 본인의 일만 잘한다고 해서 나중에 관리도 잘할 것이라 생각해선 안된다. 그렇기 때문에 개발 7년차, 매니저 "1일차"라고 타이틀을 지은 것 같다. 특히 "난 밑바닥에서 잘했으니 매니저로 올라가면 뭐든 잘할 수 있겠지?"라며 근자감에 차신 분들의 편견을 훌륭하게 깨줄 것이다. 그렇다고 "일은 잘 몰라도 난 사람 관리를 잘 하니까 이 책은 필요 없겠지?"라고 생각하시는 분들에게 도움이 되지 않는 책은 아니다.

저자가 외국인, 정확히는 미국인이다 보니 한국과는 정서적으로나 업무 내용적으로 다른 내용이 많지 않을까?라는 우려를 가지며 책을 접했던 것 같다. 다행히 이는 기우였다. 사내 위계질서와 구조를 지지한다는 저자의 생각을 바탕으로 책이 만들어졌다 보니, 나 또한 어느 정도의 위계질서가 중요하다고 생각하는 입장에서, 그리고 글로벌적인 추세에 비해 아직까진 수직적인 분위기가 강한(물론 이는 앞으로도 완화되어야겠지만) 한국의 회사 생활에도 적용될 수 있기에 이해하는 데에 어려운 책은 아닐 것이다.

​나의 경우에는 커리어의 대부분을 호주 호텔 비즈니스를 차지하고 있고, 지금은 한국으로 돌아와 교육업에 종사하고 있다. 일반적인 한국의 회사 생활과는 조금 거리가 있겠으나, 여전히 프로젝트를 주도하며 진행함에 있어 매니지먼트에 대한 개념이 유효한 것 같다. 최종 결정권은 따로 있지만 결정권자의 입장에서, 그리고 팀원의 입장에서 생각에 생각을 더하며 양방향을 설득하고 있다. 교육업에서는 주로 커리큘럼과 시간대, 프로모션 등이 이에 해당하는 듯? 최근에 이 책으로 많은 내용을 배우고 있는 것 같다.

책은 총 10 챕터로 구성되어 있다. IT 관리, 멘토링, 테크리드, 사람 관리, 팀 관리, 여러 팀 관리, 매니저 관리, 빅 리그, 문화 개선, 결론으로 되어있으며, 챕터로 넘어갈수록 보다 큰 규모의 집단을 매니지먼트하는데에 도움이 되도록 글을 썼다. 그러므로 해당 규모에 맞게 글을 적당히 읽는 것이 좋으며, 만약 보다 높은 자리에 올라가길 희망한다면 미리 책의 끝까지 읽는 편이 좋을 것이다. 굳이 300페이지가 넘어가는 책을 한 번에 읽어야겠다는 부담감을 가지시기보다는, 상황에 맞게 읽는 편을 추천드린다.

​단순히 어떻게 하면 효율적으로(흔히 이야기하는 아랫사람들을 굴리는) 업무를 추진하는지에 대하여 이야기하지 않는다. 어떻게 하면 팀과 소통하며 문제없이 관리하는 것이 책의 주요 내용이다. 게다가 단순히 팀원이 문제일 경우에 대해 사면 이야기하지 않고, 매니저는 어떠면 좋고 어떠면 나쁜지에 대하여 구체적인 예시까지 이해가 쉽게 적혀있다. 게다가 단순 신참 매니저로 가는 길에 대해서만 적은 것이 아닌, 시니어 관리자 등 보다 높은 위치에 있을 경우 어떻게 매니지먼트를 해야 하는지에 대해서도 훌륭히 적혀있다. 특히 감정과 팩트를 나눠서 이야기를 해야 한다던가, 혹은 피드백은 너무 늦게 주기보다는 제때 주는 편이 좋으며 다 같이 있을 때보다는 개인적으로 이야기하는 편이 덜 부담스러운 등, 상당히 실용적인 내용이 많아 좋은 책이라 느껴진다.

​

책의 전반적인 내용이 훌륭하여 전부 인용하고 싶으나, 가장 중요하다고 생각하는 결론 파트의 내용을 부분 인용하도록 하겠다.

"훌륭한 매니저는 갈등을 해결하는 전문가다. 갈등을 잘 해결한다는 의미는 대화할 때 자존심을 잘 분리한다는 의미이다. 복잡한 상황을 명확히 보려면, 내가 상황을 어떻게 합리화했는지 잘 인지하고 있어야 한다. 직원에게 하기 힘든 이야기를 전해야 할 때, 직원이 그 이야기를 들어주기를 바란다면, 사실을 당신 입장에서 꾸며서 이야기하면 안 된다. 매니저가 되고 싶어 하는 사람은 상황이 어떻게 돌아가야 하는지에 대해 단호한 의견을 가지고 있다. 자기 객관성을 유지할 때 단호함은 좋은 자질이다. 하지만 그러지 못할 때는 상황을 잘못 해석하게 만들 수 있다. 주관적인 해석은 그저 해석일 뿐이다."

굳이 IT업계에 종사하지 않는 분들일지라도, 모든 업종의 매니지먼트를 갓 시작하거나 자기만의 방식으로 진행하면서 답답한 경우가 많은 분들께 충분히 권해드릴 수 있는 책이다.

[한줄평]

신입 팀장이 알아할 개발 관리 내용이 잘 정리 되어 있다.

[목차구성]

1장 IT 관리 101

2장 멘토링

3장 테크리드

4장 사람 관리

5장 팀 관리

6장 여러 팀 관리

7장 매니저 관리

8장 빅 리그

9장 문화 개선

10장 결론

[이 책의 특징]

• 사수, 멘토, 팀장, CTO까지 직책별 관리 기술 대백과

• 개발자도 꼭 알아야 하는 소프트 스킬, 사람 및 조직 관리 노하우 수록

• 개발 팀을 성공으로 이끄는 IT 팀장에 대한 모든 것

[대상 독자]

- 개발자 vs 매니저 갈림길에 서 있다.

- 개발 관리를 체계적, 효율적으로 하고 싶다.

- 내 사수가 사수 역할을 못해서 내가 고생 중이다.

[서평]

이책은 개발 매니저 뿐만 아니라 신입 매니저라면 꼭 봐야할 책입니다. 멘토링 부터 시니어 리더십 까지 각 직급에서 알아야 할 관리 기술들을 잘 정리 되어 있습니다.

특히 처음 개발 관리를 하다보면 겪게 되는 여러가지 이슈 사항을 사례를 통해서 실질적인 조언을 과 문제 해결책을 제시 해줍니다.

보너스로 각 챕터마다 국내 대기업에서 활동 중인 현업자들의 이야기들이 들을수 있습니다.

이책은 신입 개발자 보다는 개발과 관리가 교차되는 시점의 개발 팀장 혹은 시니어 개발자들에게 길잡이가 되어줄 개발관리 바이블로 추천 해드립니다.

나는 경력 12년차 이다.

하지만 개발은 2년차 이다.

그동안 개발보다는 주로 관리를 많이 해왔다.

하지만 그 업무가 이 책에서 말하는 매니저의 업무와는 전혀 상관 없는 업무다.

그런데 회사에서 이제 매니저의 역활을 줄려 한다.

개발 경력도 얼마 되지 않고, 매니저와 함께 일해 본 경험도 없다.

어떻게 해야 할지 눈 앞이 캄캄 하기만 하다.

"개발 7년차, 매니저 1일차"

아직 매니저가 아니지만 

곧 들이닥칠 새로운 업무에 대해 걱정이 많았다.

우연히 발견한 책이지만 아무것도 모르는 나이게 정말 한 줄기 빛과 같은 책이다.

이 책은 제목처럼 '매니저 1일차' 인 신입 매니저 부터

경력이 많은 시니어 매니저에 이르기 까지 폭 넓은 독자층을 아우른다.

각각의 회사가 각각의 사내 문화와 사칙을 가지고 있듯이

각 회사의 매니저 역할도 같지는 않을것이다.

하지만 매니저로서 기본적으로 가져야 할 자세와 임무는 비슷하지 않을까?

이 책을 통해 가장 중요하게 생각되었던 부분은 '소통' 이다.

신입사원의 '멘토'가 되었거나, 혹은 신입사원으로써 '맨티'가 되었거나

둘 사이에는 소통이 중요하다.

또한, 매니저로서 중요한 업무중 하나로 소개한 '원온원'을 제대로 하기 위해

필요한 것도 소통 이라고 본다.

어떤 상황에 따라 어떤 소통의 기술을 발휘해야 하는지는 각자의 몫이지만

어떻게 해야 할지 모르는 사람들을 위해 약간의 팁을 제공하고 있으니

상황에 맞게 적용해 보는 것도 좋을거 같다.

마지막으로 이 책은 꼭 매니저가 아니더라도 읽어 봤으면 하는 책이다.

언젠가는 모든 개발자가 계속 개발자로 계속 남을지

아니면 매니저로 전환 할지 선택을 해야하는 순간이 올 것이니까.