-
-
개발 7년차, 매니저 1일차 - 개발만 해왔던 내가, 어느 날 갑자기 '팀'을 맡았다!
카미유 푸르니에 지음, 권원상 외 옮김 / 한빛미디어 / 2020년 2월
평점 :
이미 관심을 갖고 있던 책이었지만, 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장 결론. 가장 중요한 교훈은 스스로를 잘 관리해야 한다는 점이다. 저자는 명상과 호기심을 통해 어려운 상황에서도 자신을 관리한 경험을 이야기한다. 명상을 권하는 게 아니라 스스로를 컨트롤하는 방법이 있어야 어려움을 겪을 때도 헤쳐 나갈 수 있다는 뜻이다.