[조직 문화] 엔지니어링 관리자 vs. 테크 리드
<구글 엔지니어는 이렇게 일한다> A/S
★ 맘처럼 움직여주지 않는 팀원들을 규합해 프로젝트를 성공으로 이끌어야 하는 리더의 어깨는 무겁습니다. 기술은 빠르게 변하고, 소프트웨어의 규모는 점점 커지고, 그만큼 관리할 대상과 소통해야 할 사람도 늘어나죠. 그래서 ‘관리’에도 변화의 물결이 일고 있습니다. 전문 영역을 나눈 다음 서로 협력해 이끌어가는 관리 모델이 퍼져가면서 한 사람이 모든 걸 책임지던 옛 방식을 조금씩 밀어내고 있습니다.
이번 글에서는 새로운 관리 모델로 인기를 더해가고 있는 ‘엔지니어링 관리자 + 테크 리드’ 협업 모델을 이해하기 쉽게 풀어보겠습니다.
개념 잡기
먼저 이해를 돕기 위해 단순화해 정의해보겠습니다.
지금과 같은 ‘테크 리드’ 개념이 널리 쓰이기 전에도 관리자가 되기 싫어하는 엔지니어들의 진로를 고민하면서 소위 ‘전문가 트랙’이란 용어가 많이 쓰였습니다. 테크 리드는 엔지니어가 전문성을 살리면서 조직에서 더 큰 역할, 책임, 리더십을 발휘할 수 있는 다음 단계의 위치입니다.
엔지니어링 관리자는 사람과 제품에 중점을 두고, 테크 리드는 기술과 코드에 중점을 둡니다. 전통적인 1인 관리자 모델에서 기술 관련 역할 일부를 테크 리드에 위임한다고 생각해도 좋습니다. 깊이 들어가면 두 역할이 겹치는 부분도 많고, 회사나 사람마다 요구하는 구체적인 내용은 조금씩 다를 수 있습니다.
역시 이해를 돕기 위해, 이번에는 각 역할이 조직 안에서 어떻게 배치될 수 있는지를 살펴보죠.
모델 1은 테크 리드 없이 엔지니어링 관리자가 모든 일을 수행하는 경우이며, 구글에서는 이를 테크 리드 관리자(Tech Lead Manager)라고 합니다. 주로 팀이 작을 때에는 적합하지만 제품과 조직이 커지면 혼자 감당하기가 점차 버거워집니다.
독립적인 테크 리드는 모델 2부터 등장합니다. 테크 리드는 팀에 1명만 있을 수도 있고(모델 2), 기술별로 여러 명이 있을 수도(모델 3), 여러 팀에 걸친 테크 리드를 둘 수도 있습니다(모델 4). 특히 모델 4는 조직 구성과 인재 풀에 따라 여러 변형이 가능함을 보여주기 위해 추가했습니다.
이상에서 알 수 있듯이 엔지니어링 관리자는 팀별로 1명이 반드시 필요하며, 테크 리드는 활용하는 기술, 조직의 상황, 개인의 역량에 따라 다양한 방식으로 운용할 수 있습니다. 테크 리드는 특정 기술의 전문가이기 때문에 어느 한 팀에 얽매이지 않습니다.
One more thing!
애자일을 새로 도입하고자 애자일 코치의 도움을 받으려는 팀도 많을 것입니다. 애자일 코치는 어디까지나 ‘코치’이긴 합니다만, 프로젝트와 팀 관리에 입김이 크게 작용할 수밖에 없는 상황입니다. 그렇다면 리더 역할이 총 3개로 늘어나는군요.
다행히도 애자일은 프로세스 자체와 프로젝트 관련자들의 마인드셋 측면에서의 변화를 시도합니다. ‘프로세스’와 ‘사람’. 바로 엔지니어링 관리자가 신경 쓰는 대상입니다. 자연스럽게 애자일 코치는 주로 엔지니어링 관리자와 소통합니다.
그렇다고 테크 리드가 애자일 코치와 소통할 일이 전혀 없는 건 아닙니다. 만약 릴리스 주기가 긴 프로세스만 경험해온 테크 리드라면 시스템 아키텍처와 개발 방식을 애자일에 맞추는 데 애를 먹을 수 있습니다. 작게 시작하여 자주 빠르게 릴리스하려면 접근 방식을 바꿔야 합니다. 예컨대 모듈(서비스)을 독립적이고 더 작게 나누는 방법이 있겠죠. 테크 리드는 이런 차이점을 인지하고 프로세스 정립 시 애자일 코치/엔지니어링 관리자와 적극적으로 상의하고 조율해야 합니다.
왜 나누는가?
리더를 하나에서 여럿으로 나눈 이유는 무엇일까요? 한 명일 때의 단점과 여럿일 때의 이점을 이해하면 여러분의 조직에서는 어떤 모델로 어떻게 운영할지를 논의하는 데 훌륭한 밑거름이 될 것입니다. 이유는 다양하겠지만, 제가 생각하는 대표적인 3가지만 짚어보겠습니다.
리더의 전문성이 커진다.
비용을 크게 줄일 수 있다.
우수한 엔지니어를 형편없는 관리자로 내모는 일이 줄어든다.
하나씩 살펴보죠.
1. 리더의 전문성이 커진다.
혼자 하던 일을 남과 나누려면 필연적으로 할 일들을 명확하게 정의해야 합니다. 리더가 해야 하는 온갖 일, 그 온갖 일들을 하나하나 나열하고 어느 리더가 어떤 일을 책임질지 조율해야 합니다.
이 과정에서 리더라는 자리는 과연 무엇인지, 나는 무슨 일을 해야 하고 무엇을 놓치고 있는지, 부족한 부분을 채우기 위해서는 또 무엇을 해야 하는지를 고민하고 깨우칠 수 있습니다. 개인뿐 아니라 조직 차원에서도 똑같습니다.
일이 세분화되어 있지 않다면 전문성을 기를 수 없습니다. 따라서 역할 나누기는 리더들을 전문성을 갖춘 인재로 성장시키는 토대가 되기도 합니다.
2. 비용을 크게 줄일 수 있다.
건강하게 성장 중인 조직이라면 대체로 리더들이 매우 바쁩니다. 해도 해도 일이 끝나지 않죠. 프로젝트 일정 관리, 기술 관련 결정, 팀원 관리, 인력 충원, 새로운 먹거리를 찾으려는 경영진 혹은 기획팀 요청에 대응 등등.. 하지만 정신없이 하루하루를 지내다 보면 정작 중요한 일을 놓치기 쉽습니다. 유명한 아래 도표에서, 3순위에 밀려 2순위 일들을 돌보지 못한다는 이야기입니다.
2순위(중요하지만 급하지 않음)에 해당하는 대표적인 일이 ‘팀원 케어’입니다. 소프트웨어 개발과 같이 고도의 창의력을 요하는 분야에서는 전체 비용 중 ‘인적 비용’의 비중이 가장 큽니다. 그런데 눈앞으로 다가온 마감일과 매일 같이 터져 나오는 기술 이슈들에 매몰되어 정작 중요한 ‘사람’을 놓치게 되는 것이죠.
팀원 케어에는 멘탈 관리, 동기 부여, 갈등 중재, 성장 돕기 등 수많은 일이 있습니다. 소셜 스킬을 갖춘 엔지니어링 관리자를 두고 기술 관련 역할을 테크 리드와 나눈다면, 팀원들이 더 행복을 느끼고 일에 집중하고 적극적으로 참여하게 도울 수 있습니다. 소프트웨어 개발에서는 엔지니어 생산성 향상이 곧 최고의 비용 절감입니다.
3. 우수한 엔지니어를 형편없는 관리자로 내모는 일이 줄어든다.
슈퍼 개발자가 골칫거리 관리자가 되기는 아주 쉽습니다. 팀원이 하는 일과 리더가 하는 일은 매우 달라서 필요한 역량도 차이가 크기 때문이죠.
리더 중에서도 기술에 주안점을 두는 테크 리드는 팀원 때의 전문성을 이어 나가기가 비교적 수월합니다. 하지만 엔지니어링 관리자에게 요구되는 역량은 종류가 매우 다릅니다. 그래서 두 역할을 모두 잘 해내는 사람은 매우 드뭅니다.
이런 현실에서 팀원으로서 우수한 엔지니어를 무작정 관리자로 승진시키면 조직에 큰 해가 될 수 있습니다. 최악의 경우 우수한 엔지니어를 잃고, 그대신 형편없는 관리자를 채용하는 효과를 낳습니다. 팀에 치명적인 2연타를 스스로 날리게 꼴이죠.
물론 엔지니어링 관리자에게도 기술적인 백그라운드는 필요합니다. 하지만 팀에 다른 우수한 엔지니어가 있다면 모든 짐을 혼자 짊어질 이유가 없겠죠.
경영진은 이러한 사실을 유념하고 엔지니어링 ‘관리자’로 올릴 사람을 신중하게 정해야 하겠습니다. 엔지니어들은 자신보다 개발 실력이 부족한 동료가 관리자로 올라서는 게 전혀 이상한 일이 아님을 받아들여야 합니다. 오히려 팀과 회사의 경쟁력을 키우고 건강하게 가꿔줄 수 있습니다. 그러니 마음을 열고, 평소 자신의 성향과 능력이 어느 쪽에 적합한지 때때로 점검해보세요. 그러면서 원하는 진로에서 요구하는 역량 개발에 힘쓴다면 미래를 더 주도적으로 개척할 수 있을 것입니다.
권한과 책임
엔지니어링 관리자와 테크 리드의 권한과 책임을 구체적으로 살펴보겠습니다. 앞에서도 말씀드렸듯이 이 구분은 조직과 사람에 따라 다를 수 있습니다. 참고하셔서 본인의 조직에 맞게 조정해 활용하세요.
엔지니어링 관리자가 되려면 사람을 이끌고 관리하는 일을 즐길 줄 알아야 합니다. 팀원, 프로젝트, 프로세스에 집중하여 팀이 성공하는 데 이바지해야 하기 때문입니다. 관리직을 잘 수행하려면 열린 마음, 공감 능력, 인내력을 갖춰야 하고, ‘성장’이라는 단어를 머릿속에 항시 담고 있어야 합니다. 이 외에도 프로젝트에 필요한 기술에 대해서도 깊이 이해하고 있어야 팀 작업의 품질을 감독하고 팀원들이 기술적 사고 능력을 개선하도록 안내할 수 있습니다.
테크 리드가 되려면 시스템이 사업을 뒷받침하도록 구성하는 설계 능력과 뛰어난 코딩 능력을 갖춰야 합니다. 프로젝트를 성공시키겠다는 열망도 있어야겠죠. 또한 사업적인 맥락에서 현재 프로젝트가 전체 그림과 어떻게 관련되는지를 파악해내는 눈도 필요합니다.
마치며
역할을 굳이 나누는 이유는 혼자서는 벅차기 때문입니다. 리더가 정신없이 바빠지면 시야에서 가장 빠르게 사라지는 게 사람(팀원)입니다. 그런데 소프트웨어 개발에서 가장 중요한 요인이 하필 사람이죠. 규모가 일정 수준 커지면 혼자 이끄는 조직의 경쟁력은 역할을 잘 나눠 협력해 이끄는 조직보다 떨어지기 쉽다는 이야기입니다.
그렇다고 무작정 나누는 게 능사는 아닙니다. 구체적인 권한과 책임을 명확히 정의하지 않으면 혼선만 늘어날 뿐이죠. 각자의 조직에서 충분히 논의하여 역할별 권한과 책임 명문화하고, 꾸준히 시행해보면서 다듬어야 할 것입니다.
당장 역할을 나누지 않더라도 리더가 할 일을 나열하고 정의해두길 권합니다. 주기적으로 검토하면서 놓치고 있는 중요한 일을 파악할 수 있고, 인력 충원 계획의 기초 자료로도 아주 훌륭합니다.
★ 이번 글 작성에는 다음 문헌들을 많이 참고했습니다.
(블로그) Engineering Manager vs. Tech Lead: Everything You Need to Know
(포럼) What is the relationship between an engineering manager and a tech lead?
