개발자에서 개발팀장이 되기까지 겪은 다섯가지 큰 실수

피터 길라드–모스

젊었을 때는 자신의 재능에 확신을 가진 야심 찬 프로그래머로서, 팀장이 되기를 늘 꿈꿨습니다. 그리고 그렇게 되기까지 4년이 채 걸리지 않았죠. 하지만 2년간 팀을 이끌며 느낀 현실은 제게서 리더쉽이라는 것을 완전히 앗아가 버렸습니다. 그 이후로 몇 년 동안 저는 기술의 깊숙한 곳으로 숨어, 더 큰 책임을 요구하는 일에서 도망쳐왔습니다. (역주: Leader를 팀장으로 의역하였습니다)

시간이 지남에 따라, 제가 저지른 실수들의 근본적인 원인에 대해 이해하여 다시 리더가 되는 기회를 잡아 팀장으로 성장할 수 있었고, 지난 2년간 제대로 된 지원을 받으며 ThoughtWorks의 기술 부문장을 맡을 정도로 성장하였습니다. 다른 리더들에게 가르침을 받으면서 제가 했던 실수들이 저만 겪었던 특별한 일이 아니라, 리더쉽을 요구받는 개발자들이 공통적으로 가질 수 있는 문제임을 알았습니다.

다른 분들에게 도움이 되기를 바라며 제 실수와 그로부터 배운 것들을 공유해봅니다.

1: 기술적인 능력이 리더쉽으로 이어질 줄 알았다

기술 리더 역할을 처음 맡으면서, 젊고 재능있는 졸업생들을 고용했습니다. 우리는 새로운 아이디어와 능력으로 서로 밀어주고 당겨주며 열심히 일했습니다. 고작 몇 달 만에 이 친구들이 경험은 부족할지 몰라도, 저보다 기술적으로 더 뛰어날 수 있다는 것을 깨달았습니다. 기술 리더로서 다른 그 누구보다 기술적으로 뛰어남을 증명해야겠다는 생각이 들었습니다. 그들이 다른 사람에게 – 특히 제 상관에게 – 가능성을 보여줄 때마다 저는 불안해져서, 그들이 저보다 제 역할에 더 어울려 보이지 않을까 안절부절못했습니다. 좋은 동료였던 관계가 제 경쟁심과 불신으로 휩싸였습니다. 그들을 공동 작업자(또는 최소한 잠재적인 후임자)로 여기지 못하고 위협적인 존재로만 여겼습니다.

기술적인 능력이 리더를 선택하는 데 있어 가장 큰 요인으로 주로 사용되곤 합니다. 가장 명확하게 보이는 요인이기도 하고요. 이게 제 첫 번째 실수였습니다. 기술적으로 뛰어난 사람이 리더로의 능력도 클 것으로 착각했죠.

제 경우에는 이 착각이 별 도움도 안 되는 경쟁적인 행동들로 이어졌습니다. 주변 환경과 자격지심 때문에 제 불안은 커져갔습니다. 제아무리 겸손하고 능력 있는 사람이라도 이런 실수는 가면 증후군을 강화해, 팀의 다른 사람들이 훨씬 가치 있다는 생각에 빠지게 만듭니다. 팀워크를 과소평가하거나 자신의 존재 가치에 대해 의문을 가지게 되기도 합니다. 이런 경우에, 리더는 자신의 역할을 믿지 못해 우유부단해지고 필요한 순간에 결정을 내리지 못하게 됩니다.

기술이 뛰어난 사람이 리더가 되어야 한다는 잘못된 생각 때문에, 능력 있는 사람들이 스스로 리더 역할을 꺼리게 됩니다.

2: 능력을 넓혀야 할 때 기술에만 집착하고 있었다

처음 팀장을 맡았을 때 정말 좋았습니다. 완전한 새 프로젝트에 새로운 팀이었으니까요. 유닛 테스팅, ORM, 지속적 통합(CI), 페어 코딩, 더 나은 소스 관리 도구, 빌드 시스템 등 신기술과 방법론들을 도입했습니다. 힙스터의 새로운 블로그 글을 읽으면 바로 회사 프로세스와 도구에 도입해보았습니다.

도구와 기술을 선택하는 것은 처음에만 해당하는 일이었습니다. 이제 날마다 해야 하는 일의 차례였습니다. 관리하고, 관계자들을 설득하고, 팀 회의를 진행하고, 실적 리뷰를 하고, 사람을 뽑고, 예산을 관리하는 일 같은 것들요. SVN, nunit, CruiseControl, C# 같은 건 고를 줄 알았지만 다른 일들은 완전히 처음이었습니다.

제가 이해하지 못하고 어렵다고 생각하는 것들에 점점 화만 쌓여갔습니다. 문제의 원인을 알아보려 하지 않고, 저는 제가 그나마 할 수 있는 것에만 집중했습니다. 바로 기술이죠. 이는 제 가면 증후군을 더 악화시키기만 했는데, 팀 성장에 자신 있어 하는 다른 팀장을 만날 때, 투자를 위한 비즈니스 미팅, 새로운 팀 멤버들이나 장애 복구 계획 등을 얘기할 때 특별히 더 심했습니다.

앞서도 말했지만, 기술적인 역량은 리더의 역할에 얼마나 적합한지를 알려주는 유일한 지표가 아닙니다. 기술적으로 탁월한 것은 여러 부분 중 하나일 뿐입니다. 동료에게 영향을 주고 설득하며 코칭하는 능력, 프로세스에 대한 이해, 신뢰받는 조언, 복잡도를 다루는 능력, 전략적 사고 등 이루 말할 수 없이 많습니다. 이러한 것들은 눈에 잘 띄진 않지만 업무 중에 계속해서 섬세하게 요구되는 역량입니다.

새롭게 리더 역할을 맡게 되면 이런 역량들의 중요성을 이해하고 폭넓은 분야에서 자기 계발을 하는 것이 필요합니다. 그렇지 않으면 가장 눈에 띄는 역량인 ‘기술’에만 불나방처럼 빠져들어 문제를 악화시키게 됩니다.

또 다른 함정은, 개발자들이 새로운 기술 역량을 익히기가 상대적으로 쉽다는 것입니다. 우리는 새로운 기술을 습득하는데 꽤 익숙합니다. 수식을 이해하고, 블로그를 읽으며, 스택오버플로우를 찾아보고, 좋은 리더를 알고 있으며, 컨퍼런스에 참석하며, 책을 봅니다. 적당한 ‘Hello World’ 예제와 몇 번의 시도를 하고 나면 새로운 기술에 이미 익숙해져 있습니다.

하지만 다른 역량은 이렇게 익힐 수 없습니다.

코칭이나 시간 관리, 비즈니스 가치에 영향을 주거나 설득하는 방법에 대해서는 명확한 ‘Hello World’가 없습니다.

우리는 의사 결정을 내리거나 팀을 조직하고 이해 관계자를 이해시키는 ‘올바른 방법’을 듣기 위해 트위터에서 누굴 팔로우 해야 할 지 모릅니다.

리더쉽이 있어야 하는 새로운 역할을 맡을 때는 걸맞는 대가를 치뤄야 합니다. 이러한 것들 중 대부분은 새롭기 때문에 신임 팀장들은 갈팡질팡하게 됩니다. 익숙하지 않은 역량들은 익혀서 어떤 가치를 줄지 알 수 없으므로, 눈에 보여 쉽게 익힐 수 있을 것 같은 기술적 역량을 익히는 데 치중하기가 쉽습니다.

3: 계속해서 개발자로 일하려고 했다

팀장이 되고 나서 처음 몇 달간은 근심이 깊어갔습니다. 개발과는 무관한 일들만 잔뜩 해야 하는 것 같았습니다. 코드를 작성하는 시간은 점점 줄어만 가고, 회의와 이메일, 이해 관계자들을 상대하는 일들로 바빴습니다. 제 이름이 걸린 일들은 진전이 없게 느껴졌고요. 이런 일을 하느라 못했던 것들을 제 개인 시간을 희생해서라도 하려고 했습니다. 당연히 야근으로 이어졌습니다.

개발자에서 개발팀장이 되면서 깨닫지 못한 게 있다면, ‘생산자’라는 관점에서 제 책임과 성공의 척도가 바뀌었다는 것입니다. 전달하는 조직에서는 주된 목표가 생산된 ‘가치’를 극대화 하는 데 있습니다. 이런 관점에서 팀에는 두 가지 주된 활동이 있습니다. 하나는 직접 가치를 창출하는 일과, 다른 하나는 생산된 가치를 극대화하는 일입니다. 이 일을 하기 위한 유일한 방법은 아니지만, 가장 단순한 방법은 생산자(개발자)가 생산 활동(코드를 작성하는 것)에 집중하는 시간을 극대화하는 것입니다. PM부터 XD, BA, QA까지 이르는 다른 팀은 업무 과정이 최대한 정확하고 물처럼 흘러 일이 막히거나 실패 요인(버그 같은 것)을 만들지 않도록 노력해야 합니다. 간단하게 말하자면, 개발자들의 생산성을 높이기 위해서는 주변 팀에서 장애나 산만함을 제거해서 개발자가 제대로 된 코드를 작성해 가치를 창출하는데 집중할 수 있어야 한다는 것입니다.

개발자에서 개발팀장이 된다는 것은 더 이상 생산자의 역할이 아니라 전체적인 영향을 극대화하는 역할로 바뀐다는 것입니다. 물론, 장애물과 방해자들을 제거하는 일도 포함해서요.

이런 것들을 잘 이해하지 못한다면 다른 개발자들과 같이 코딩하는데 시간을 쓸 수 없는 현실에 정말 큰 스트레스를 받게 됩니다. 너무 많은 회의에 좌절하거나 특정 시간에만 미팅을 하려고 하기도 하죠(코어 코딩/페어링 시간을 정해서). 극단적인 경우에는 기술과 관련 없는 모든 활동을 거부하는 행위를 보이기도 합니다(이해 관계자를 만나야 한다거나 하는). 이런 일련의 행동은 개발 리더가 다른 사람의 가치를 극대화하는 사람이 아니라 직접 개발을 해야 한다는 인식에 기인합니다.

제 경우에는, 저 자신을 팀의 핵심적인, 대체할 수 없는 역할로 여기기까지 했습니다. 다른 사람들도 이렇게 하는 것을 자주 봤는데요, 팀장과 팀원 사이의 기술적 역량 차이가 큰 작은 규모의 팀에서 특히 심했습니다. 개발을 해야 한다는 압박감에 다른 책임감까지 더해져 짓눌리는 상황에서 기술 리더들은 자신이 직접 개발하지 않으면 팀의 생산성이 떨어진다고 여기게 됩니다.

4: 다른 사람에게 위임해야 할 때 모든 것을 알고 제어하려고 했다.

어느 날, 회의에서 다른 팀장이 저에게 버그에 관해 물었습니다. 제가 손 댄 적이 없는 분야였기 때문에 답하기가 어려웠고, 노력하면 할수록 제 말의 설득력은 떨어졌습니다. 모른다는 것을 인정하기가 어려워 경험에 따라 적당히 답을 해버렸습니다. 다른 팀이 제 추측에 따라 애플리케이션을 변경하기 시작했고, 엄청난 시간을 낭비하고 나서야 제 추측이 틀렸음을 밝혀냈습니다. 저는 이런 실수가 무지에서 비롯되었다고 여기고, 아침마다 모든 커밋 로그를 읽기 시작했습니다.

커밋을 읽으면서, 절차적으로 작성된 코드의 특정 부분이 객체 지향적으로 바꾸면 좋겠다는 생각이 들었습니다. 다른 개발자 옆에 앉아서 다른 방법을 시도해보자고 얘기했고, 며칠 동안이나 코드의 작은 부분을 고치는 일에 빠져 있었습니다. 그러는 와중에 다른 팀원들은 큰 틀에서 설계를 변경하고 있었습니다. 그 변경 사항이 배포되고 나서 제가 눈치채지 못한 잘못된 가정 때문에 엄청난 버그를 일으키고 말았습니다.

저는 제 상관에게 어떤 일이 있었는지 솔직히 얘기했습니다. 제가 맡은 코드를 제대로 만드는 데 집중하느라 다른 부분에 신경 쓰지 못했다고요. 하지만 중요하지 않은 일에 신경 쓰고 있다는 질책을 이겨내기 어려웠습니다. 객체 지향적으로 코드를 작성하는 게 정말 중요했을까요? 그들의 반응은? 저는 선택을 해야 했습니다.

이런 일에는 공통점이 하나 있습니다. 모든 일에 개입할 수는 없다는 것입니다. 인간적으로 불가능합니다. 개발 리더로서 저는 책임감을 느끼고 다른 사람들을 믿고 중요한 것들에 더 집중해야 했습니다. 때로는 모른 체 해야 할 수도 있고, 제가 원하는 방식이나 이상적인 방법으로 진행되지 않아도 어쩔 수 없습니다. “나는 잘 모르겠고, 팀과 확인해봐야겠다.”고 얘기하는 게 잘못된 정보를 퍼트리는 것보다는 낫습니다. 절차적인 코드가 좀 있으면 어떻습니까. 오히려 제가 눈치채지 못한 큰 설계의 변경은 있을 수 없는 일입니다.

장기적인 관점에서 코드 수준을 높이기 위해서는, 문제가 생길 때마다 작은 문제를 고치는 데 노력을 기울이지 말고 멘토링과 코드 리뷰를 운영하는 것이 훨씬 효율적임을 깨달았습니다.

5: 신호가 바뀐 걸 몰랐다

프로젝트 회의에 참석하고, 개선을 제안해도 무언가 바뀌는 것이 없다고 생각되니 두려워지기 시작했습니다. 구체적인 제 성과가 보이지 않았습니다. 모든 단계에서 개발자들과 팀워크를 재고하는 방법들을 논의했습니다. 하지만 한 번 하고 난 다음에는 번번이 원래대로 돌아가기 일쑤였습니다. 다른 사람들은 개발자가 직접 데이터베이스를 다뤄야 한다고 생각하겠지만, 우리는 DBA가 스토어드 프로시저를 작성해줄 때까지 기다렸습니다. 개발자들에게 TDD를 하자고 해봤지만 한 번 하고 나서는 다들 손을 들었습니다. 말만 하고 아무것도 되질 않으니 겁이 나고 위축되었습니다.

매일 매일 기술만 생각하고 있다면, 당신은 피드백 과정과 일상적인 신호에 적응하게 됩니다. 우리는 일감 스토리보드의 일부로, 빌드가 통과되거나 프로덕션으로 릴리즈 될 때 엔도르핀을 방출합니다. 그리고 빌드가 깨지거나 새로운 스토리(이슈)가 생기면 코르티솔이 분비되어 ‘개발 중’ 상태에 빠집니다. 하지만 리더쉽을 요구하는 역할에서의 신호는 다른 곳에서 옵니다.

개발자가 신경 쓰는 것은 매일 매일 비슷하기 때문에 이러한 변화를 알아차리기가 어렵습니다. 스토리는 계속해서 만들어지고 전달되어야 하고 코드는 계속 작성되어야 합니다. 기술 팀장이 받는 신호는 여전히 기술적으로 여겨집니다.

리더쉽이 필요한 역할을 맡는다면 다른 신호들도 배우고 유심히 지켜봐야 합니다. 방향을 튼다면, 다른 사람에게 끼치는 영향이 있을 겁니다. 누가 아이디어를 이해했는지, 그리고 어떤 사람이 납득하고 누구를 설득하지 못했는지, 아니면 협조적인지 회의적인지에 대한 신호를 반드시 배워야 합니다. 다른 신호들도 많이 있는데, 이를테면 팀원이 업무에 지쳐 도움이 필요로 한다던가, 새로운 기술을 배우는데 적합한 도구가 없는 경우, 팀이 무엇을 목표로 해야 하는지 모르고 의사소통하는 문제들에 대해서요. 이런 신호들은 무언가 숨기거나, 다른 것을 강조하기도 하는 ‘사람’에게서 오기 때문에 알아차리기가 쉽지 않습니다.

이런 신호를 알아차리는 것은 경험에 따른 육감에 가깝습니다. 이런 일에 익숙하지 않다면 전혀 모를 일이죠.

그리고 이런 일들은 주의 깊게 다뤄져야 합니다. 항상 당신이 생각한 일 때문에 일어나는 것은 아니라서요.

정말 좋은 리더가 되려거든 이런 모든 신호에 귀 기울이고 그것들을 어떻게 이해하고 답을 줄지 고민해야 합니다. 찻잎이나 동물 내장을 통해 짐작하는 흑마법을 쓰는 주술사처럼 보일 수도 있고, 기술만큼 확실하지는 않겠지만 합리적으로 접근하여 배울 수 있는 일입니다.

개발자 출신으로 성장하기

이미 눈치채셨겠지만, 각 실수들은 서로 연관되어 있습니다. 예를 들어, 자신이 리더인 이유가 기술적인 면이 뛰어나서라고 생각한다면, 자기 자신을 생산자로 여기는 것을 피할 수 없을 겁니다. 그러다 보니 새로운 기술을 배우기가 더 어렵죠. 이런 실수들이 서로 꼬이고 꼬인 제 첫 팀장 경험은 완전히 망해버렸습니다.

리더쉽 역할을 맡게 된다는 건 큰 변화이고 벅찰 수 있습니다. 하지만 인간으로서, 고생한 만큼 새로운 능력을 발견할 수도 있습니다. 기술은 리더쉽의 근간이 되어야 하지만, 다른 부분에서 능력을 성장시켜야만 합니다. 이런 능력들이 사람과 함께 일하고, 의사소통하고, 납득시키고 설명하는 능력이든, 아니면 빠르게 습득하고, 새로운 걸 발견하고, 복잡한 문제의 원인을 찾거나 추상화 능력을 발전시켜 문제를 이해하기 쉽게 재구성하는 기술적인 능력이든 간에 말이죠. 제 능력에 자신감이 붙고 나서는 새로운 기술을 배울 수 있는 기회를 찾아, 흥미진진한 새로운 영역을 배우고 개발하는 것으로 뻗어 나갈 수 있었습니다.

리더쉽이 선형적으로 발전하는 게 아니라는 것을 이해하는 것이 중요합니다.

팀장을 맡았다가 다시 순수한 개발자로 돌아가도 좋습니다. 더 나은 개발자로 만들어줄 기회가 될 것입니다. 뻔한 얘기지만, 리더쉽은 ‘팀장’ 딱지를 달아야만 생기는 건 아니니까요.

팀은 자기계발을 위한 작은 기회들을 마련해서, 리더 역할을 맡지 않더라도 더 나은, 안전한 환경에서 다른 능력을 연습하고 배울 수 있는 방법을 찾아야만 합니다.

https://muchtrans.com/translations/techie-tech-lead-my-5-biggest-mistakes.ko.htm

개발자에서 개발팀장이 되기까지 겪은 다섯가지 큰 실수

https://www.thoughtworks.com/insights/blog/techie-tech-lead-my-5-biggest-mistakes

Techie to tech lead: My five biggest mistakes