유독 개발자는 시간이 지나면 팀장, 매니저가 되어야 하는 경우가 많은 것 같다. 하지만 경험이 풍부한 개발자가 항상 유능한 매니저가 되는 것은 아니라고 생각했기 때문에 평소에 매니지먼트에 관심이 있던 나는 이 책을 본 순간, 망설이지 않고 그대로 계산대로 향했다.

개발자와 매니저

어떤 분야든지 자신의 영역에서 경험을 더 쌓고, 거기에 연차가 어느정도 쌓이면 무척 자연스럽게 매니저 위치를 맡게 될 수도 있다. 그런데 개발자는 유난히 그런 상황에 자주 놓여지게 된다.

대표적인 케이스로, 개발자는 철저하게 개인으로써 사이드 프로젝트를 진행하는게 아니라면 오늘 작성한 코드는 곧 회사의 코드가 되어, 신입 개발자에게 알려주거나 인수인계 해야 하는 상황이 올 수도 있다.

이 케이스가 개발자로써 가장 흔히 접할 수 있는, 개발자가 매니지먼트를 해야 하는 케이스다. 온보딩이나 인수인계는 응당 당연한 일이고, 현재 매니저나 팀장이 아니기 때문에 멘토(사수)와 매니지먼트는 결이 다르다고 생각할 수 있다.

그렇지만, 나는 개발자가 매니지먼트에 관심을 갖는 것이 좋다고 생각한다.

나쁜 멘토

개발자는 코드를 보고 이해하면 되는거 아닌가?

특히 이러한 사고를 바탕으로 매니지먼트에 큰 관심이 없으면 방치로 이어지게 된다. 멘토가 되어야 하는 상황을 외면하고 **“대충 코드를 보시면 됩니다.”**와 같은 방법으로 방치를 하게 되면 멘티, 새로 들어온 개발자는 어려움을 겪게 된다.

물론 어떤 상황에서는 그렇지 않을 수도 있다. 새로 들어온 사람이 경력직이라던지, 매우 실력이 뛰어나다면 그러한 방치 속에서도 나름대로 잘 적응할 수도 있다.

이런 방식은 부정적 효과가 더 많다. 가장 먼저 멘티는 그런 멘토를 좋게 생각하지 못할 것이고, 멘토는 본인의 방식에 문제가 없다고 생각하게 된다. 이 과정에서 멘토와 멘티 사이에 갈등 내지는 마찰이 일어날 수 있다.

더 안타까운 것은 그 멘토는 스스로 깨닫기 전 까지 계속 같은 방식으로 “매니지먼트”를 할 것이다. 악순환 그 자체라고 볼 수 있다. 결과적으로 멘티에게 부정적 경험을 주게 되고, 최악의 경우 회사는 인재를 놓칠 수도 있다.

적극적인 멘토링을 했다고 가정하자. 예를 들면 프로젝트에 대한 설명이나, 참고할 수 있는 사내 위키를 알려줄 수도 있고, 앞으로 몇주간 페어 프로그래밍을 진행할 수도 있다. 코드 리뷰도 적극적으로 진행하는 것도 포함한다.

매우 이상적으로 멘토링을 진행했다면 앞서 말한 문제는 일어나지 않을 것이다. 나아가 어떤 점이 멘티에게 부족했는지 피드백을 듣고 더욱 발전할 수도 있다. 사소하게는 놓쳤던 레거시를 바로 잡을수도 있고. 운이 좋다면 이번에 멘토링을 받은 멘티가 다음번에 멘토를 자처할 수도 있다. 눈물나게 아름다운 선순환이다.

나의 경험

“나는 주니어 개발자니까, 지금 해야하는 일도 어려우니까…”

앞서 말한 “나쁜 멘토”는 나의 이야기다.

경력이 4년차를 맞이하는 동안, 나보다 나중에 들어온 개발자분들은 분명 많이 있었다. 정규직으로 같이 일한 사람도 있었고 잠시 인턴으로 일한 사람들도 있었다. 나는 방치로 동료들을 일관했다. 나는 팀장이 아니니까.

그래서 첫 회사에서는 다같이 삽질하는 개발 환경을 갖추게 되었고, 두번째 회사에서는 같이 개발했던 동료가 개발하는 것 자체를 힘들어 하는 과정을 지켜보기도 했다.

그리고 지금의 회사에서는 프론트엔드를 혼자서 하고 있다. 지난 여름에 잠시 인턴을 했던 분은 굉장히 능력이 있는 분이었고, 그 분과 더 많은 이야기를 나누고 고민을 했었다면, 나는 지금 혼자서 개발을 하고 있었을까?

돌이켜보니 좋은 동료가 회사에 들어오길 바라면서 정작 스스로는 멘토는 커녕 동료로도 부족한 것이었다. 무려 좋은 동료가 곧 최고의 복지라고 말할 수도 있는 세상에서.

좋은 매니저, 나쁜 매니저

이 책은 사수, 멘토에서 시작하여 CTO까지 매니지먼트의 단계별로 챕터가 나누어져 있다. 즉, 당장 내가 팀장이 아니라 하더라도 앞부분의 챕터는 공감하기 쉬운 주제를 다루고 있다.

그리고 챕터 중간에 챕터 속의 작은 코너처럼 책 내용의 흐름을 잠시 환기하는 부분도 있다. 실제 CTO들의 조언을 들려주는 CTO에게 묻는다나, 어떤 공통된 사례에서 두 매니저의 각기 다른 대처를 알려주는 좋은 매니저, 나쁜 매니저는 단순히 이론적인 내용을 실제 사례에서 어떻게 참고할 수 있을지 알려준다.

특히 나는 좋은 매니저와 나쁜 매니저의 사례를 들려주는 부분이 매우 재밌었다. 단언컨대 이 부분을 읽다보면 스스로를 돌이켜 보기도 하고, 누군가 생각이 나기도 할 것이라고 감히 생각한다. (농담)

팀원이 매니저에게 기대하는 것

매니지먼트를 하는 것에 관심은 없어도, 매니지먼트를 받는 것, 좋은 매니저와 일 하는 것에는 그래도 관심이 있을 것이다. 좋은 매니저가 무엇인지 어떻게 알 수 있을까? 가장 좋은 것은 진짜로 좋은 매니저와 일하는 경험을 쌓는 것이겠지만, 쉬운 방법은 아니다.

또 다른 방법은 좋은 매니저가 어떻게, 어떤 매니지먼트를 하는지 이해하는 것이다. 즉, 관리되는 법을 이해하는 것이다. 아래 내용은 이 책의 챕터1, IT 관리 101의 매니저에게 기대하는 것 부분을 일부 발췌했다.

원온원 미팅

원온원 미팅, 일대일 대화는 매니저와 팀원 사이에 인간적인 교감을 하는 목적이 있다. 회사에서는 같이 일하는 동료지만, 회사 밖에서는 각자의 삶이 있는 하나의 인간임을 존중해야 한다.

이러한 교감이 필요한 이유는 예를 들어 팀원이 개인적인 사정으로 인해 연차를 써야할 경우, 매니저가 이를 이해하고 있다면 팀원 입장에서 도움을 요청하는 것이 더 쉬울 것이다. 혹은 매니저가 팀원의 컨디션을 체크하고 먼저 물어볼 수도 있다.

원온원 미팅을 오용하는 대표적인 케이스는 프로젝트의 진행 상황을 보고하는 것이다. 마이크로매니징을 위한 원온원 미팅은 매니저는 만족할 수도 있지만 원온원 미팅을 시간 낭비라고 생각하게 될 수도 있다.

원온원 미팅의 본질은 교감이고, 이를 통해 상호간 신뢰를 쌓는 것이다.

피드백

칭찬도, 잘못된 점을 지적하는 것도, 어떤 일에 대한 리뷰나 검토 결과를 알려주는 것도 피드백이다. 코드 리뷰 또한 거시적인 측면에서 피드백이라고 할 수 있다.

좋은 피드백, 칭찬은 공개적으로 진행하고 나쁜 피드백, 지적이나 비판은 비공개로 진행하는 것이 이상적이다. 다만 팀원의 성향에 따라 공개적인 칭찬을 힘들어 할 수 있기 때문에 미리 사전에 물어보거나, 반대로 팀원이 미리 말해두는 것이 좋을 수 있다.

가장 잘못된 피드백은 나쁜 피드백을 공개적으로 하는 것이다. 특히 어떤 이슈가 발생했을 때, 이 이슈에 대해서 특정 팀원을 단어 그대로 Blame 하는 것은 매우 좋지 않다. 어떤 경우에도 공개적으로 비난하는 것은 위험하다. 비난 피드백을 받는 대상은 한 명이지만 영향을 받는 것은 그 자리에 있는 모든 사람들이기 때문이다.

건강한 피드백을 통해 팀원의 도전 욕구를 채워주고, 팀원이 하고 있는 일이 회사의 성공에 어떻게 기여하게 되는지 설명한다면 팀원은 가치를 느끼고 하고 있는 일에 대한 자부심을 느끼게 된다.

교육과 성장의 기회

정확히는 팀원 스스로 원할 때 매니저가 그 기회를 보장하는 것이다. 각 팀원에게 필요한 역량에 맞는 교육 세미나나 컨퍼런스를 매니저가 다 기억하고 정리할 순 없기 때문이다.

팀원이 필요하다면 적극적으로 도서를 구매 해 주고 컨퍼런스 참여를 할 수 있도록 여건을 보장해준다.

개발자가 소프트 스킬에 관심을 가져야 하는 이유

“개발자는 혼자서 일할 수 없다.”

평생 학습해야 하는 개발자가 매니지먼트까지 관심을 갖고 공부해야 하는 이유를 묻는다면 위와 같이 말하고 싶다. 혼자서 개발할 수는 있다. 그러나 일을 하기는 어렵다. 단순 코드를 치는게 아닌, 하나의 제품을, 가치를 만든다면 개발자는 회사에서 많은 사람과 소통할 필요가 있다.

나는 제품 관점에서 실제 고객의 목소리가 아니라는 이유로 비개발 직군에 있는 사람들의 의견을 바로 수용하지 않곤 했다. 그런데 최근 회사에서 전사적으로 브레인스토밍을 진행한 결과, 제품을 사용하는 것은 개발자가 아닌 고객이고, 고객과 가장 가까이 있는 사람들이 지금 회사에서 고객을 가장 이해하고 있는 사람들이라는 것을 느꼈다.

비개발 직군이든, 나와 같이 일하는 개발 직군의 동료들이든 커뮤니케이션은 언제나 중요하다. 소프트 스킬이 부족하면 문제가 발생하기 마련이다. 특히 소통과 관련된 문제는 해결하기 어려운 편에 속한다.

갑자기 매니지먼트 이야기 하다가 소프트 스킬이 나온 느낌이지만, 매니지먼트는 소프트 스킬 그 자체이기 때문이다. 소프트 스킬에 대한 역량이 부족한 상태에서 단순히 연차가 쌓였다는 이유로 팀의 매니저가 된다면 여러모로 많이 힘들 것이다.

항상 능력있는 개발자가 능력있는 매니저가 되는 것은 아니다. 그러므로 매니지먼트에 관심이 있는 개발자라면 이 책을 읽어보는 것을 추천한다.