좋은 매니저는 누구인가
@import url('https://fonts.googleapis.com/css?family=Nanum+Gothic:400,700|Noto+Serif+KR:200&display=swap'); 『개발 7년차, 매니저 1일차』 92쪽 중 나는 2007년 무렵에 처음 매니저가 되었다. 트레이딩 플랫폼을 개발하는 월스트리트 회사에서 5년 동안 개발자 겸 테크니컬 리더로 근무했는데, 팀의 매니저가 회사를 떠나면서 매니저 역할을 물려받게 되었다. 코드를 개발하는 업무에서 멀어지는 게 아쉬웠지만 개인 사무실이 주어지고 연봉도 올라가는 승진이라 마다할 이유가 전혀 없었다. 팀은 뉴욕에 있는 12명 정도의 자바 개발자, 런던에 있는 3명의 현장지원 인력, 그리고 그리스에 있는 1명의 외주 개발자로 구성되었다. · · · 매니저는 팀원을 리드한다는 면에서 테크니컬 리더와 비슷하지만 완전히 다른 역할을 수행한다. 가장 큰 차이는 코드를 작성하는가 여부다. 테크니컬 리더는 다른 개발자와 함께 코드베이스에 코드를 체크인하지만 매니저는 코드를 체크인하지 않는다. 또 다른 차이는 팀원들을 평가하는 방식과 수준이다. 테크니컬 리더는 팀원을 직접 평가하거나 팀원의 연봉과 보너스를 결정하지 않는다. 기술적인 영역에서만 리더십을 발휘하며 영향을 미친다. 하지만 매니저는 평가와 연봉, 보너스를 결정하는 업무를 수행한다. 내가 맡았던 매니저는 미국에서 ‘기술적인 매니저(technical manager)’라고 부르는 역할이었기 때문에 단순히 사람 관리만 하는게 아니었다. 소프트웨어 제품의 출시와 품질에 대해 최종적인 책임을 지는 자리였다. 그러므로 팀이 기술적으로 올바른 결정을 내리는지, 개발과정에 불필요한 비효율이 없는지, 약속한 일정을 지키는 데 방해가 되는 돌발상황은 없는지 늘 주시하고 고민해야 했다. 팀의 테크니컬 리더와 대화를 나누며 기술적인 문제를 심도 있게 논의하고, 때로는 직접 코드를 들여다보며 돌아가는 상황 전체를 꿰뚫어보아야 했다. 하지만 앞에서 말한 대로 매니저는 코딩 실무를 보지 않는다. 테크니컬 매니저도 마찬가지다. 미국에서는 코딩 업무를 수행하는 것을 hands-on, 코딩 업무를 하지 않는 것을 hands-off라고 표현한다. 그런 의미에서 나는 매니저가 되면서 처음으로 hands-off 역할을 맡게 되었다. 초보 매니저가 흔히 저지르는 실수의 하나는 자기 본분을 잊고 코딩 업무를 계속 수행하는 것이다. 매니저가 개발자와 함께 코딩을 하는 문화가 바람직하다고 주장하는 사람도 있지만, 그렇지 않다. 사람을 관리하고, 평가하고, 응원하고, 일정을 책임지는 것은 그 자체로 상당한 수준의 역량과 노력을 필요로 하는 전문적인 업무다. 파트타임으로 할 수 있는 일이 아니다. 마찬가지로 코드를 설계하고, 구현하고, 테스트하고, 디버깅하고, 현장문제를 지원하는 일은 온 힘을 다해서 수행해야 하는 고도로 전문적인 업무이며 파트타임으로 감당할 수 있는 일이 아니다. 따라서 그 둘을 섞는건 어느 쪽도 제대로 할 수 없게 만드는 잘못이다. 매니저가 혼자 시간을 내어 코딩 연습을 하는 건 좋다. 하지만 그가 소프트웨어 제품 개발을 위한 공통의 코드 저장소(code repository)에 자기가 짠 코드를 집어넣으면 개발 팀의 역관계에 부정적인 영향을 줄 확률이 높다. 그래서 코딩을 계속 하고 싶은 사람은 처음부터 매니저 자리를 거부하고 테크니컬 리더에 머무르는게 좋다. 매니저 트랙이 아니라 기술 트랙을 밟는 것이다. 매니저가 코딩을 해도 좋은 경우가 있지만 예외적이다. 회사의 개발환경, 문화, 시스템이 구글 수준으로 최적화되어 있고, 본인의 코딩 실력이 출중한 경우가 그렇다. 그런 예외적인 경우가 아니라면 매니저는 철저히 hands-off 하는 것이 옳다. 오랫동안 다른 개발자들과 함께 오픈된 공간에서 코딩을 하며 즐겁게 지내던 나는 매니저가 되면서 월스트리트가 한 눈에 내려다보이는 개인 사무실로 자리를 옮겼다. 사무실 안에서 나는 더 이상 가비지 콜렉션, 멀티스레딩, 객체지향 기법 등을 고민하지 않았다. 대신 경영층이 개발 팀에게 요구하는 사항과 개발팀의 현실을 조율하고, 소프트웨어 사용자의 목소리를 경청하고, 채용과 비용절감을 고민하고, 소프트웨어 제품의 출시 기간을 결정하고, 인사 부서와 함께 직원의 복지 문제를 논의하고, 평가를 통해 연봉과 보너스 수준을 결정하고, 개발자의 불만과 의견을 접수하고, 개발자 문화를 어떻게 개선할지 고민하는 일을 수행했다. 코딩만큼 재미있는 건 아니었지만 그 나름대로 도전이 되고 보람도 있는 흥미로운 업무였다. · · · 그렇게 1년 반 정도 매니저 역할을 수행한 뒤 나는 회사를 옮기면서 다시 hands-on 포지션으로 돌아갔다. 1년 반이 긴 시간은 아니었지만 소중한 경험이었다. 때로는 경영층이 참석하는 칵테일 파티에 초대받기도 했고, 투자자와의 미팅에서 회사의 기술을 설명하기도 했다. 중간 매니저 사이에서 벌어지는 살벌한 사내 정치도 경험했고, 개발자 시절에 알 수 없던 일을 경험하며 시야가 넓어지는 것도 좋았다. 하지만 개발이 그리웠다. 너무 이른 시기에 매니저 트랙으로 빠지는 것에 대한 두려움도 있었다. 이후 여러 회사를 옮겨다녔는데 일부러 관리 업무를 피하고 개발 업무를 추구했다. 그런데 매니저 역할을 수행하느라 hands-on 기술에서 멀어진 1년 반의 시간이 내게 어떤 자극이 되었다는 사실이 흥미롭다. 다시 개발로 돌아온 나는 전과 달랐다. 뭔가 다름을 스스로 느꼈다. 매니저 역할을 포기하고 다시 기술과 만난 3~4년의 기간 동안 내 기술력은 확실히 일취월장했다. 자바와 JVM이라는 단일한 생태계에서 벗어나 다양한 기술을 접했다. C#과 .NET을 익히고, F#을 맛보고, 스칼라와 자바스크립트 생태계도 섭렵했다. 새로운 데이터베이스 기술, 새로운 메시징 기술, 클라우드, 마이크로서비스 아키텍처, 도메인 주도 개발 등을 학습하며 지식을 확장했고, 프로그래밍 팟캐스트, 컨퍼런스, 미트업 모임 등에 참여하며 안목을 넓혔다. 전에 비해서 달라진 것은 단순히 기술의 다양성이 아니었다. 코딩 실력도 아니었다. 맥락에 대한 이해와 통찰이었다. 전에는 특정 기술이 실무에 어떤 의미를 갖는지 모르면서 맹목적으로 공부하는 경우가 많았다. 그런데 잠시 매니저 생활을 하고 돌아오니 기술과 실무의 접점이 눈에 잘 보였다. 안목이 넓어진 덕이다. 이건 자랑이 아니다. 앞으로 매니저를 하려고 마음 먹은 사람이나 이미 매니저의 길을 걷는 사람이 반드시 기억해야 하는 중요한 논점이다. 매니저는 기술의 막다른 골목이 아니다. 매니저가 되면 어쩔 수 없이 기술이 퇴화하고 다시는 개발 현업으로 돌아갈 수 없다고 생각하는 사람이 많다. 이것은 사실이 아니며 사실이 되어서도 안 된다. 이런 생각은 기술적으로 게으른 매니저에게 면죄부를 발급해주는 미신에 불과하다. 매니저 트랙과 기술 트랙은 서로 만나지 않는 두 개의 평행선이 아니다. 그것은 서로 수시로 교차하는 나선형이다. 백세 시대의 기나긴 커리어 기간을 고려하면 매니저는 언제나 기술현업에 돌아갈 준비가 되어 있어야 하고, 코딩 업무를 보는 사람도 상황에 따라 hands-off 매니저 역할을 수행할 수 있어야 한다. 모건스탠리를 끝으로 나는 월스트리트를 떠났다. 2014년 무렵에 다시 조그만 회사의 개발을 진두지휘하는 역할을 맡았다. 4~5명으로 이루어진 아주 작은 개발 팀을 맡아서 광고 서비스를 제공하는 서버 시스템을 처음부터 새로 구축하는 일이었다. 처음에 나는 팀원들의 매니저이면서 동시에 코드를 개발하는 실무 개발자 역할을 수행했다. 앞에서 매니저는 코딩 실무를 겸하지 않는 게 좋다고 말했는데 그 말과 상충되는 역할이었다. 그래서 나는 팀원을 관리하는 업무의 대부분을 내 상급자에게 맡기고 개발에 전념했다. 팀을 실력 있는 개발자로 채우는 일 하나만 제외하고. 매니저가 되면 끊임없이 사람에 대한 판단을 내려야 한다. 그리고 그 판단은 냉철하고 정확해야 한다. 일상생활에서 다른 사람을 제멋대로 판단하는 것은 나쁜 습관이지만 매니저가 팀원에 대해서 내리는 판단은 회사의 정상적인 운영을 위해 꼭 필요한 일이다. 다만 매니저의 판단은 반드시 조직의 목표와 비전이라는 문맥 안에서 이루어져야 한다. 그게 중요하다. 개인적인 감정, 지연, 학연, 호불호가 섞인 판단은 금물이다. 회사에 들어가서 프로젝트를 시작했을 때 나는 내게 주어진 4~5명의 개발자가 대부분 마음에 들지 않았다. 회사 비즈니스의 근간을 이루는 시스템을 빠르게 구축해야 한다는 조직의 목표를 고려했을 때 그랬다는 말이다. 그들은 회사의 레거시 시스템에 대해 아는 게 많고 도메인과 관련된 지식이 풍부했다. 하지만 새로운 기술에 대해 쉽사리 마음을 열지 않았고 프로그래밍 실력도 내가 원하는 수준에 미치지 못했다. 내가 마음에 들어하지 않는다는 것을 느낀 그들은 암묵적으로 집단 태업 비슷한 태도를 취하기도 했다. 나는 팀원들과 수시로 개인면담 시간을 가지며 내가 가려는 방향을 설명하고 설득했다. 어떤 사람은 끝까지 마음을 열지 않았고, 어떤 사람은 마음을 열었으나 역량이 따라오지 못했다. 잦은 기술 세미나 시간을 통해 새로운 패러다임과 기술을 공부했으나 그들이 작성하는 코드의 품질은 계속 날 실망시켰다. 시간이 많지 않았다. 나는 인간적인 면에서 힘들지만 매니저로서 필요한 결정을 내렸다. 판단이 섰으면 실행은 과감해야 한다. 나는 팀을 내가 원하는 사람들로 재구축했다. 월스트리트에서 함께 일했던 실력 있는 친구들을 데려오고, 기존 개발자들은 새로운 곳을 찾아가도록 배려했다. 말은 배려지만 당사자들은 나를 많이 원망했을 것이다. 1년 동안 나는 새로운 시스템의 근간이 되는 코드를 직접 개발했고, 동시에 팀원의 대부분을 새로운 사람으로 교체했다. 정예부대가 협력하기 시작하면서 개발에 가속도가 붙었다. 가까스로 일정을 맞출 수 있었고 새로운 시스템은 큰 성공을 거두었다. 이 성공을 기반으로 해서 회사의 IT 인력 전체를 총괄하는 역할을 맡게 되었다. 시스템 개발만이 아니라, QA, 데이터과학, 데이터엔지니어링, UI 개발, 인프라 관리 등 여러 조직으로 나뉘어져 있는 IT 업무 전체를 관리하는 자리였다. 인력을 다 합쳐봐야 40명을 넘지 않는 인원이었지만 내 업무의 영역이 개발을 벗어났다는 점에서 완전히 새로운 경험이었다. · · · 이제 좋은 매니저가 되려는 후배에게 들려주고 싶은 이야기를 할 시간이 되었다. 현역 시절에 아무리 뛰어난 실력을 가진 사람이라고 해도 관리하는 사람의 수가 늘어나고 업무 영역이 확대되면 자기 전문성이 옅어질 수밖에 없다. 어떤 일에 대해서 자기보다 훨씬 많이 알고, 더 잘 아는 사람을 부하 직원으로 두게 된다는 뜻이다. 믿기 어렵겠지만 이런 부하를 질투하는 못난 매니저가 세상에는 많다. 잘난 부하를 견제하고 찍어눌러서 기어코 아무 소리 못하는 바보 직원으로 만들어야 직성이 풀리는 것이다. 나는 QA 팀의 매니저와 테스트를 자동화하는 일에 대해서 많은 대화를 나누고, 데이터과학 팀 매니저와 새로운 프로젝트에 대한 아이디어, 예측 모델을 자동으로 배포하는 방법, 새로운 데이터과학자를 채용하는 일, 기존 모델의 단점을 개선하는 일을 심도 있게 논의했다. 데이터엔지니어링 팀의 매니저와 함께 빅데이터 처리를 위한 카프카, 스파크 데이터 플로를 구축하는 아키텍처를 설계했다. UI 개발 매니저와 사용자 경험, 새로운 앱 개발 아이디어에 대해 열띤 토론을 하고, 인프라 팀의 매니저와 데이터센터 네트워크 보안, AWS와 애저 등 클라우드 활용방법, 네트워크 모니터링에 대해 대화를 나누며 지식을 확장했다. 부족한 내 지식과 경험을 앞세우지 않고 전문가인 그들의 의견을 존중하며 열심히 경청했다. 나는 전체적인 그림을 그리고, 조직간 커뮤니케이션을 활성화하는 데 신경을 쓰며 큰 방향을 제대로 설정하기 위해 노력했다. 그렇게 하기 위해 많은 권한을 매니저들에게 일임했다. 시간이 조금이라도 생기면 회사의 문화를 좋은 방향으로 개선하는 방법을 찾기 위해 공을 들였다. 기술적으로는 막 시작된 데이터과학 팀을 경쟁력 있는 수준으로 끌어올리기 위해 제일 많은 노력을 기울였다. 젊은 친구들과 함께 나도 열심히 공부했다. 이때 키워낸 젊은 데이터과학자 중에서 다수가 훗날 좋은 오퍼를 받고 페이스북, 링크드인, 구글, 마이크로소프트, 아마존 등으로 자리를 옮겼다. 어떤 사람은 데이터과학을 전공하기 위해 컬럼비아 대학으로 되돌아갔다. 회사로서는 속상한 일이지만 개인 입장에서는 좋은 일이었다. 내가 회사를 떠난 이후로 매니저급 사람들도 여러 명이 좋은 회사로 자리를 옮겼다. 심지어 나 역시 이때의 경험을 밑거름으로 삼아 한국으로 자리를 옮겼다. 여기에서 핵심은 이들이 더 좋은 회사로 자리를 옮겼다는 게 아니다. 핵심은 개인의 성장이다. · · · 이제 결론을 말할 준비가 되었다. 좋은 매니저는 심성이 곱고 착한 사람이 아니다. 그건 그냥 착한 것이다. 프로젝트를 제때 끝내고 경영진의 인정을 잘 받는 사람도 아니다. 그건 그냥 능력이 좋은 것이다. 밥을 잘 사주고 어려운 이야기를 잘 들어주는 사람도 아니다. 그건 그냥 정치를 잘 하는 것이다. 좋은 매니저는 후배를 성장시키는 사람이다. 잘난 후배는 더 잘나게 만들고, 못난 후배는 자신감을 갖도록 도와주는 사람이다. 자기 장점이 무엇인지 깨닫게 해주고, 배움의 기회를 만들어주고, 자기 역량을 발휘하여 스포트라이트를 받게 해주는 사람이다. 후배가 너무 환히 빛나서 자신을 앞질러 가거나 다른 회사가 데려간다 해도 진심으로 개의치 않는 사람이다. 후배들의 앞길을 있는 힘을 다해 열어주고, 이끌어주고, 밀어주는 사람이다. 그게 좋은 매니저다. 후배의 성장만 도와주면 되는 거라고? 어렵지 않은데? 이렇게 생각한다면 이미 좋은 매니저가 될 가능성이 없는 사람이다. 후배의 성장을 돕는 게 쉬운 일이 아니기 때문이다. 이렇게 이야기한다고 해서 내가 스스로를 좋은 매니저로 생각하는 것은 아니다. 그럴 리 없다. 좋은 매니저는 비전, 실력, 전문성, 의사소통 능력 등 여러 가지 덕목을 갖춰야 하지만 무엇보다도 마음이 넓어야 하기 때문이다. 마음이 넓고 그릇이 커야 한다. 이건 단순한 소프트스킬이 아니다. 저절로 생기는 것도 아니다. 매일 온 힘을 기울여 노력해도 간신히 가질 수 있는 무엇이다. 근육이 살을 깎는 노력을 통해 얻는 거라면, 넓은 마음은 뼈를 깎는 노력이 있어야 가질 수 있는 귀한 자산이다. 미국에서 매니저 경험을 쌓은 나는 이제 한국에 들어와 연구소의 랩 하나를 맡고 있다. 데이터과학과 관련된 실전 업무와 연구를 동시에 수행하는 조직이다. 소프트웨어 개발 업무도 일부 포함된다. 하나의 랩이지만 스타트업 회사에서 맡았던 인력의 두 배가 넘으니 적은 규모는 아니다. 내가 맡은 사람들은 박사가 많고 박사가 아니더라도 모두 뛰어난 인재들이다. 데이터과학에 대해 나보다 많이 알고 나보다 똑똑한 사람들인 건 말할 필요도 없다. 이들에게 나는 좋은 매니저일까. 지금은 알 수 없다. 훗날 나와 함께 있는 동안 자신이 성장했음을 느끼는 후배가 존재한다면 그 존재가 답이 될 것이다. 그렇게 되기를 희망한다. 임백준 한빛미디어에서 『팟캐스트 나는 프로그래머다』, 『임백준의 아카 시작하기』, 『폴리글랏 프로그래밍』, 『누워서 읽는 퍼즐북』, 『프로그래밍은 상상이다』, 『뉴욕의 프로그래머』, 『나는 프로그래머다』, 『누워서 읽는 알고리즘』, 『행복한 프로그래밍』 등 다수의 책을 출간했다. 삼성SDS, 루슨트 테크놀로지스, 도이치은행, 바클리스, 모건스탠리 등에서 근무했고 맨해튼에 있는 스타트업에서 분산처리, 빅데이터, 머신러닝과 관계된 업무를 수행했다. 현재는 삼성전자에서 데이터 분석 연구를 총괄하고 있다.
