내가 테크 리더로 일하면서 얻은 8가지 교훈

본문은 요즘IT와 번역가 Jay Eum과 함께 만든 해외 번역 콘텐츠입니다. 글의 필자인 Tyler Hawkins는 수석 소프트웨어 엔지니어로 개인 웹 사이트를 통해 개발에 관한 다양한 글을 올리고 있습니다.

이번 글은 회사에서 우리가 테크 리더를 맡았을 때 두려움 없이 원활하게 직책을 수행하기 위해서는 무엇을 해야 하는지를 설명하고 있습니다. 이 글을 통해 리더로서 무엇을 해야 하는지 알 수 있기를 기대합니다.

저는 지난 수년간 다양한 회사에서 테크 리더(Tech Lead)로 일했습니다. 수행했던 직책별로 다소 다르긴 했지만, 업무를 진행하는 과정에서 공통점이 있었습니다. 이번 글에서는 테크니컬 리더가 무엇이며, 어떤 일을 하는지 등을 살펴보고, 이 과정에서 습득한 몇 가지 교훈을 공유하고자 합니다.

테크 리더란?

가장 먼저 알아야 할 점은 테크 리더는 관리자가 아니라는 것입니다. 테크 리더는 여전히 개별적으로 기여하는 직책이며, 팀을 도와주는 동시에 상당한 업무성과를 낼 것으로 기대를 받습니다. 일반적으로 테크 리더는 팀에서 관리자의 입장이지만, 항상 그런 것은 아닙니다. 직속 부하직원이 없기 때문에 팀원들과 1:1 관계가 이루어지거나 성과에 대한 검토를 하지 않습니다. 하지만, 팀원들에게 멘토링을 제공하여 도움을 줍니다.

테크 리더의 책임

테크 리더는 다양한 직책을 수행합니다. 아키텍트, 프로젝트 관리자, 소프트웨어 엔지니어, 멘토 및 팀원 역할을 동시에 수행합니다. 또한 팀이 수행하는 업무에 관하여 높은 수준의 아키텍처적인 토론을 주도하는 것을 도와줄 책임이 있습니다. 디자인 회의와 기술 분야를 세부적으로 살펴보는 과정을 주도합니다. 극단적인 상황을 극복할 수 있는지 질문을 던지고, 아이디어의 미비점을 찾기 위해 노력합니다.

이와 함께 제품의 진행 상황을 이야기와 임무로 나누어 업무 준비를 돕습니다. 이러한 작업은 개별적으로 수행하거나 다른 팀원들과 함께 수행할 수 있으며, 이는 기업마다 상이합니다. 업무 우선순위를 정하고, 적절한 업무가 적시에 완료될 수 있도록 관리합니다.

테크 리더는 장애요소를 제거할 수 있도록 해야 합니다. 여기에는 프로덕트 책임자, UX 디자이너 (User eXperience designer)[1] 또는 다른 팀의 엔지니어를 위한 질문에 대한 답변을 처리하는 업무도 포함될 수 있습니다. 또한, 개발 의뢰서에 대한 여러 승인 기준을 명확히 하기 위해 팀원과 협력하기도 합니다. 여기에는 매일 코드를 검토하고, 풀 리퀘스트(pull request)[2]가 관심을 받지 못한 상태로 너무 오래 유지되지 않도록 확인하는 것이 포함됩니다.

또한, 팀원들에게 멘토링을 제공하고, 팀의 수준을 올리는 것을 도와줄 책임이 있습니다. 최적의 적용 사례를 구현하고, 준수하도록 합니다. 페어 프로그래밍(pair programming)[3]과 코드 검토를 통해 교육도 시킵니다. 때로는 관련 기사나 조언, 아이디어를 공유하기도 합니다.

요약하자면, 테크 리더가 된다는 것은 직접적인 권한은 없지만 영향력을 행사하는 것입니다.

이제 테크 리더가 무엇이고, 무엇을 하는지를 충분히 이해했으니 제가 리더로 일한 경험을 통해 습득한 몇 가지 교훈을 살펴보겠습니다.

1) 팀의 요구사항을 우선적으로 처리하기

테크 리더는 자신의 성공에 더 이상 관심을 갖지 않게 됩니다. 대신 팀 전체의 성공에 투자하는 것입니다. 이는 팀의 요구사항이 개인적인 요구사항보다 중요하다는 것을 의미합니다.

저는 통상적으로 모든 풀 리퀘스트를 검토하고, 슬랙으로 받은 질문에 답하며, 새로운 오류를 분류하는 데 하루에 1시간에서 3시간 정도를 보냅니다. 한 마디로, 팀원들이 기다리고 있는 어떤 것이라도 해결하기 위해 할 수 있는 모든 것들을 합니다.

이 모든 일을 마치고 나서야 그날 저에게 주어진 일을 시작합니다. 나머지 시간에도 슬랙을 확인하거나 코드를 검토하지만, 제 업무 흐름을 방해하지 않고 자연스럽게 잠시 멈출 수 있을 때에만 합니다.

2) 시간 관리를 잘하기

제가 직접 해야 하는 업무와 팀 업무 사이에서 시간 균형을 맞추는 것은 매우 어려운 일입니다. 어떤 날에는 장시간 코딩을 해야 하는 ‘개발자 일정’에 참여해야 합니다. 또 다른 날에는 업무에 집중할 수 있는 시간이 없고, 많은 회의에 참가해서 방해를 받게 되는 ‘관리자 일정’을 소화해야 하기도 합니다. 이런 두 가지가 섞이는 날이 대부분입니다.

코드를 검토하거나 팀원들의 질문에 답해주다 보면 코드를 직접 작성할 수 있는 시간이 거의 없습니다. 자신의 고유 업무에 집중할 수 있도록 방해받지 않는 시간을 위해 일정표에 범위를 정해서 시간을 비워 놓는 방법을 배워야 합니다.

팀이 더욱 스스로 업무를 할 수 있도록 하고, 각자의 의문사항에 답을 찾을 수 있게 도와주어야 합니다. 위임해 줄 수 있는 업무를 찾아야 하는 것입니다.

3) 일을 위임하기

모든 것을 혼자 하려고 하는 것은 잘못된 생각입니다. 팀을 구성하는 이유는 업무를 분담하고, 각자가 혼자서 해낼 수 있는 것보다 함께 더 많은 것을 달성하기 위해서입니다.

업무의 부담을 혼자 짊어지려고 하면 곧 지치고 말 것입니다. 어떤 일에 대해서 자기 자신이 그 일을 해야 할 때와 이를 위임해 줄 때를 안다는 것은 까다로운 일입니다.

4) 프로세스를 개선하기

팀을 위해 끊임없이 화재를 진압하러 다니는 자신을 발견한다면 잠시 시간을 내어 그 문제의 근본적인 원인을 생각해 보십시오.

예를 들면, 팀원들이 같은 질문을 반복적으로 한다면 이런 기회를 자신의 프로세스로 문서화할 수 있는 기회로 활용해야 합니다. 이를 통해 다음에 동일한 질문을 받게 되면 사람들에게 본인이 정리한 문서를 공유할 수 있어야 합니다.

팀의 풀 리퀘스트를 모두 검토해야 하나요? 왜 그런 것일까요? 모든 팀원들이 코드를 검토할 책임이 있다는 사실을 정해야 합니다. 무엇을 찾아야 할지 가르쳐 주고, 자신의 사고 과정을 자세히 설명해 주세요. 코드 리뷰에 대한 최적의 적용 사례와 지침도 문서화해 주십시오. 코드 리뷰 몇 개를 다른 팀원에게 넘겨주기만 해도 일주일에 몇 시간 정도를 확보할 수 있습니다.

여러분은 뭔가 잘못되었을 때 이런 곤란한 문제를 해결하 는데 항상 참여합니까? 이런 과정을 팀원에게 가르치기 위한 시간을 활용할 필요가 있습니다. 문제를 진단하고, 해결할 때 팀원이 항상 따라다니거나 짝을 지어 함께 하도록 해봅시다. 그러면 비슷한 일이 일어났을 때 도움을 줄 준비가 된 또 다른 인원이 팀에 있게 됩니다.

5) 개발자 경험 최적화하기

개발 프로세스를 더 쉽게 하고, 팀의 생산성을 높이는 데 도움을 줄 수 있도록 최적화할 수 있는 것들을 찾아야 합니다.

• 누락된 문서가 있습니까? 해당 문서를 작성합시다.
• 어떠한 저장소에 대해 로컬에서 앱을 실행하는 절차를 알고 있습니까? README에 이런 절차를 문서화합시다.
• 자주 중단되는 영역에 테스트가 누락되었습니까? 해당 테스트를 작성해야 합니다.
• CI 파이프라인이 느립니까? 파이프라인에서 병렬로 실행할 수 있는 단계나 줄일 수 있을 다른 작업이 있는 확인해 봅시다.
• 팀의 수준을 올리기 위한 교육 기회가 있습니까? 팀원의 숙련도에서 부족한 부분을 찾고, 이러한 부분을 채우는 데 도움을 주기 위한 계획을 수립하기 위해 팀원과 협력하는 게 중요합니다.

6) 어려운 피드백을 잘하기

리더로서 가장 어려운 부분 중 하나는 부정적인 피드백을 제공하는 것입니다. 어려운 대화를 나누는 방법을 익혀야 합니다. Kim Scott은 자신의 책 에서 개인적으로 관심을 갖고, 직접 도전해야 한다고 말했습니다. 팀원들이 성장할 수 있도록 좋은 질문을 계속해야 합니다.

누군가가 자신의 역할을 충분히 해내지 못한다면, 이에 대한 근본적인 원인을 찾고, 해결 방안을 모색할 수 있도록 함께 노력해야 합니다. 이러한 문제가 동기 부여나 숙련도의 문제일까요? 숙련도에 관한 문제라면 해당 팀원에게 더욱 적합한 직무나 프로젝트가 있는 것일까요?

이때 테크 리더와 관리자 사이의 경계가 다소 모호해지기 때문에 이러한 상황에서 해당 담당자와 긴밀하게 협력하는 것이 중요합니다. 테크 리더로서 성과에 관한 논의를 하거나 해고 결정을 할 책임은 없지만, 자신의 의견은 상당한 영향을 미칩니다. 팀원들이 성공할 수 있도록 최선을 다해야 합니다. 하지만, 때로는 팀원들이 계속 업무를 할 수 있을 정도로 돕는 것이 가장 친절한 일이기도 합니다.

7) 올바른 판단 내리기

앞으로 나아갈 길이 불확실할 때 팀원들은 테크 리더가 조언을 해주거나 방향 제시를 기대할 것입니다. 소프트웨어 엔지니어링은 기술적 결정을 내릴 때 절충할 수 있는 각종 요소로 가득합니다.

예를 들어, 이 기능에 대한 테스트를 작성해야 할까요? 일반적으로 이 질문에 대한 답은 거의 언제나 ‘그렇다’입니다. 하지만, 저장된 코드가 지난 5년간 수정하지 않은 지금까지 내려오던 코드이고, 오래된 기술 스택을 사용하고 있으며, 기존의 테스트 세트가 없는 경우에는 어떻게 해야 할까요? 특정 테스트의 작성에 추가하여 이런 코드에 대한 테스트 기반 구조를 갖추는 데 시간을 보내야 할까요? 아니면, 이런 상황에서 테스트 작성을 생략해야 할까요?

아니면, 다음과 같은 시나리오를 고려할 수 있습니다. 새로운 기능의 출시가 임박했지만 출시 마감 직전에 오류를 식별했습니다. 오류를 수정하기 위해 코드 배포를 연기해야 할까요? 아니면, 생산단계로 진행하기 위해 오류를 허용해야 할까요? 이 문제의 답은 오류의 심각성, 코드 배포의 빈도, 오류를 얼마나 신속하게 수정할 수 있을지 등 여러 요소에 달려 있을 것입니다.

여기서 핵심은 100% 정확한 해결 방안이 없는 상황에서 어려운 결정을 내리게 되는 경우가 많다는 것입니다. 올바른 판단력을 사용하고, 제한된 정보로 결정을 내리며, 자신의 결정을 지지하는 법을 배우십시오.

일이 잘못되면 자신의 실수를 인정하고, 이를 통해 배워나갈 수 있는 방법을 찾아야 합니다.

8) 언제나 공부하기

마지막으로, 자만하지 말아야 합니다. 팀의 수준을 지속적으로 높이려면 계속 배워야 합니다. 테크 리더가 지속적으로 성장하는 모범을 보이면 팀원들에게도 배움의 문화를 만들어 갈 수 있습니다. 자신이 읽고 있는 흥미로운 기사나 책이나 진행하고 있는 부가 프로젝트를 공유하십시오. 이를 통해 팀과 공유할 수 있는 풍부한 아이디어를 제공해 줄 것입니다.

결론

테크 리더는 쉽지 않지만, 성장할 수 있는 기회로 가득 찬 직책입니다. 요약하면, 본인이 아래와 같이 행동한다면 더욱 원활하게 직책을 수행할 수 있을 것입니다.

1) 개인의 요구사항보다 팀의 요구사항을 우선적으로 고려해야 합니다.

2) 시간을 현명하게 관리해야 합니다.

3) 위임하는 법을 배워야 합니다.

4) 프로세스 문서화를 개선할 방법을 찾아야 합니다.

5) 개발자 경험을 최적화하는 방법을 찾아야 합니다.

6) 부정적인 피드백을 제공하고, 어려운 대화를 나누는 방법을 배워야 합니다.

7) 좋은 판단을 내리기 위해 자신을 믿어야 합니다.

8) 항상 배움의 자세를 잊지 말아야 합니다.

[1] 소비자가 제품이나 서비스 등을 선택하거나 사용할 때 발생하는 제품과의 상호작용을 제품 디자인의 주요소로 고려하는 것을 설계하는 직책
[2] 프로그램의 분산 버전 관리를 위해 개발자가 변경한 사항을 유지보수 관리자에게 반영 요청하는 작업
[3] 2명이 함께 프로그램을 개발하여 한 사람은 코드를 작성하고, 나머지 한 사람은 코드를 검토하여 프로그래밍을 수행하는 방법

<원문 링크>

8 Lessons I Learned as a Tech Lead

©️위 번역글의 저작권은 Tyler Hawkins에게 있으며, 요즘IT는 해당 글로 수익을 창출하지 않습니다.