엔지니어링 리더의 딜레마: 코드를 놓아야 할까, 붙잡아야 할까?

Introduction

세상에는 두 종류의 기술 리더가 있습니다. 코드를 이해하는 리더와 그렇지 않은 리더.

요즘 들어 자주 듣게 되는 질문입니다.  승진할수록 실무에서 멀어지는 것은 당연한 수순으로 여겨지곤 합니다. 하지만 정말 그래도 될까요? 결정권을 가진 사람이 기술을 이해하지 못한다면 어떤 일이 벌어질까요?

오늘은 알렉스 에벨뢰프(Alex Ewerlöf)의 "엔지니어링 리더는 어떻게 기술력을 유지할 수 있을까?(How can engineer leaders stay technical?)"라는 글을 번역해 가져왔습니다. 이 글에서 그는 중견기업(직원 500-1000명)의 CTO에게 직접 물었습니다.

그의 대답은 의외로 단호했습니다. "기술력을 잃는 순간 CTO로서의 가치도 함께 사라진다"는 것이었죠.

기술 리더십의 핵심은 결국 '기술'에 있습니다. 코드에서 너무 멀어진 리더는 과연 팀을 효과적으로 이끌 수 있을까요? 기술적 뉘앙스를 이해하지 못하는 리더가 내리는 결정의 위험성은 무엇일까요? 그리고 바쁜 관리자 업무 속에서도 기술력을 날카롭게 유지할 수 있는 실질적인 방법에는 어떤 것들이 있을까요?

에벨뢰프의 글을 통해 현업 CTO의 솔직한 고백과 함께, 실제 기술 리더들이 활용하는 기술력 유지 전략을 심층적으로 살펴보겠습니다. 엔지니어에서 리더로 성장하는 과정에서 놓치기 쉬운, 하지만 결코 포기해서는 안 될 가장 핵심적인 역량에 대한 이야기입니다.

엔지니어 리더는 어떻게 기술력을 유지할 수 있을까?

중견 기업(직원 500-1000명 규모)의 CTO인 친구에게 질문을 던졌습니다.

다음은 그의 답변이었어요:

CTO가 기술력을 유지함으로써 다음과 같은 것들이 가능해집니다:

경영진은 모든 것을 요점으로 단순화하길 좋아합니다. 하지만 종종 그 요점들은 맥락과 복잡성을 가리고 말죠.

뉘앙스가 핵심입니다. 악마는 디테일에 있죠. CTO로서 기술적 측면에서 자신을 분리할 여유가 없습니다.

기술적 깊이가 없다면:

그러면 대체 어떻게 기술을 따라잡나요?

어느 정도까지요?

아래 내용을 할 수 있을 만큼 충분히 알고 있어야 합니다:

이러한 격차를 메우기 위해 스태프 엔지니어를 고용하고 싶은 유혹이 있을 수 있습니다. 하지만 그렇게 하지 마세요:

엔지니어-케이션(Engineer-ication)

CTO 배경을 가지고 있으며 현재 다른 CTO들을 코칭하는 세르지오 비시노니(Sergio Visinoni)는 "엔지니어-케이션"에 대해 글을 썼습니다:

"휴가를 떠나는 것처럼 며칠 동안 캘린더와 일정을 비우고 회의 초대를 거절하며 특정 업무를 다른 사람들에게 위임합니다.

개인 기여자(IC)로서 엔지니어링 팀 중 하나에 합류하여 하나 이상의 소프트웨어 엔지니어링 작업을 수행합니다." — 세르지오 비시노니

그는 또한 다른 글에서 몇 가지 모범 사례를 후속으로 공유했습니다.

세르지오는 "엔지니어링 매니저가 코딩을 해야 할까요?"라는 주제에 대한 생각을 다음과 같이 정리했습니다:

취미 프로젝트

또 다른 아이디어는 취미 프로젝트를 갖는 것입니다. 제가 매우 존경하는 몇몇 엔지니어링 리더들은 엔지니어링 기술을 향상시키고 기술 발전을 따라잡기 위해 자신만의 취미 프로젝트를 가지고 있습니다.

라즈베리 파이를 가지고 실험하든, 새로운 쿠버네티스 클러스터를 설정하든, 엔지니어의 삶을 경험하고 새로운 통찰력을 얻을 수 있다면 그것으로 충분합니다.

권력 비대칭

기술적으로 '충분히' 기술적이란 어느 정도일까요?

엔지니어링 매니저는 팀 내에서 발언권을 가집니다. 결국, 그들은 모든 사람의 급여, 성과 평가, 휴가 등에 대한 결정권을 쥐고 있습니다.

엔지니어들이 불이익에 대한 두려움 없이 엔지니어링 매니저에게 이의를 제기하는 경우는 드뭅니다.

엔지니어링 매니저의 나쁜 아이디어가 아무런 이의 제기 없이 프로덕션까지 가게 될 위험이 있습니다. 그리고 문제가 발생하면, 그것은 궁극적으로 엔지니어링 매니저의 책임입니다. 엔지니어들은 단지 그들이 맡은 일에 대해서만 책임이 있습니다.

적절한 거리를 유지하고 엔지니어들이 최대한 주도권을 갖게 하는 것이 최선입니다.

또한 리더십에서 나온 것이라도 나쁜 아이디어를 지적할 수 있는 팀 내 심리적 안전성을 구축하는 것이 매우 중요합니다.

한 EM 친구는 PR(풀 리퀘스트) 관점에서 이렇게 표현했습니다:

"리더가 PR을 보내면 개발자는 어떤 느낌이 들까요? PR 리뷰에 달린 코멘트는 어떨까요? 만약 그 피드백이 실제로 좋은 해결책이 아니라면? 매니저가 지시했다는 이유만으로 개발자가 그 피드백을 구현해야 한다고 느낄까요?

기술적인 EM이 PR을 보내면, 개발자는 성과 평가나 급여 조정에서 '문제'에 빠지지 않기 위해 무조건 승인해야 한다고 느낄까요?

이것들은 기술적인 EM이 없는 것보다 더 나쁜 기술적 해결책을 만들어낼 수 있는 두 가지 사례입니다. 하지만, 물론 당신의 관점도 충분히 이해합니다."

저는 (좋은 의도를 가졌지만) 팀 문화를 해치는 "마이크로 매니저"들을 경험해 봤습니다. 코드에 너무 가까이 다가가려면 신뢰, 개방성, 겸손함이 필요하며, 이는 시간을 들여 구축해야 합니다.

그러니 이 글을 읽고 나서 바로 코드에 뛰어들지 마세요(쉬운 길). 대신 어디서 나왔든 상관없이 최고의 아이디어가 인정받을 수 있는 환경을 구축하는 데 시간과 에너지를 투자하세요(훨씬 어려운 길).

이 글이 유용하다고 생각되시면, 다른 사람들에게 영감을 주고 인식을 높이기 위해 여러분의 네트워크에서 공유해 주세요.

👥 더 나은 데브필을 만드는 데 의견을 보태주세요

Top 1% 개발자로 거듭나기 위한 처방전, DevPill 구독자 여러분 안녕하세요 :) 

저는 여러분들이 너무 궁금합니다. 

어떤 마음으로 뉴스레터를 구독해주시는지, 

어떤 환경에서 최고의 개발자가 되기 위해 고군분투하고 계신지, 

제가 드릴 수 있는 도움은 어떤 게 있을지. 

아래 설문조사에 참여해주시면 더 나은 콘텐츠를 제작할 수 있도록 힘쓰겠습니다. 설문에 참여해주시는 분들 전원 1개월 유료 멤버십 구독권을 선물드립니다. 유료 멤버십에서는 아래와 같은 혜택이 제공됩니다.