개발 8년, 매니징 2년
팀에서 나의 역할에 대해서
  • etc

image

어느덧 10년

개발자라는 직업을 시작하고 이것 저것 많은것들을 만들어온지 어느덧 10년차가 되었다.

감사하게도 지난 회사에서 약 1년 그리고 지금 회사에서 약 1년간의 매니징을 맡겨주었고 이제 매니징이라는 자리에 선지는 약 2년이 되었다. 단순히 개발을 할때와 지금은 어떻게 다를까? 또 회사가 나에게 바라는 역할과 내가 바라는 매니저의 역할에는 어떤 차이가 있을까.

처음 1년간의 경험

우선 지난 회사에서의 경험을 되돌아보면 매니저라고는 하지만 대단하게 매니징을 요구하지는 않았다. 어쩌면 한 도메인의 리드개발자로서의 역할을 더 원했다. 하나의 도메인에 대해 MSA로 새로운 시스템으로 갈아엎는 작업을 진행중에 있었고 새로운 프로젝트 또는 기존 시스템에서 내용을 알고있는 개발자가 없거나 문서로도 남아있지 않은 미지의 영역에 대해 책임지고 이어나갈 사람이 필요했다.

사실 그땐 구성원들과 프로젝트를 일정에 맞춰 잘 진행하고 미지의 영역에 대한 코드 파악과 문서화, MSA 전환에 집중했고 매니징에 대한 고민은 크지 하지 않았던 것 같다. 어쩌면 주어진 프로젝트의 일정완수가 나에겐 가장 큰 성과였다. (실제로 그것으로 성과도 책정했었다.)

지금의 TL의 역할

반면에 지금 회사에서의 매니징은 조금 다르다. TL 이라는 이름으로 (Tech Leader 의 줄임말이다) 활동하고 매니징의 역할을 함께한다.

이 곳 역시 MSA로 전환중이고 그 프로젝트에 함께 투입되어있긴 하지만 일정을 TL이 결정하지는 않는다. 대부분의 결정은 PO가 하고 TL는 이에 협의하고 조율하는 역할이다. 그렇다면 TL의 역할은 어떤 것일까?

image

내가 생각하고 추구하는 리더의 역할

최소 1개월에서 최대 3개월 정도의 기간이 소요되는 프로젝트의 일정을 조율하고 시스템 설계를 같이 한다. (혹은 조언을 준다 정도가 더 맞겠다) 함께하는 구성원의 실력을 믿고 전적으로 맡겨준다. 그 구성원이 막혀있거나 헤맬 때 함께 살펴보며 도움을 줄 수 있는 정도로 참여하려고 노력한다.

팀에 생각보다 자잘한 운영 유지보수가 많이 들어온다. 내 업무시간에서 허락하는 한 대부분의 운영 유지보수의 6할은 내가 처리한다. 그리고 항상 PR리뷰나 회의와 업무 공유시간을 통해 어떤 것이 어떻게 처리되고있는지 공유한다. (4할 정도는 구성원에게 맡기는 편인데 그 이유로는 기존 시스템에 대해 도메인 지식도 계속해서 학습하고 유지해야하기 때문이다)

모두가 시간만 들이면 처리가능한 일을 모든 구성원과 나누지 않으려고 노력한다. 구성원들의 시간은 프로젝트 설계를 더 고민하고 코드 퀄리티를 개선하는데 할애했으면 좋겠다.

물론 주제를 던져주는건 나의 몫이다. 이러이러한 프로젝트가 있고 일정은 어느정도이며 어떤 부분 수정, 혹은 개발이 필요하다. 또는 기존 프로젝트에서 이런 부분은 코드를 이런 방법으로 개선해보면 유지보수와 가독성이 좋아질 것 같다. 그리고 kafka, e2e, 부하테스트 와 같은 키워드와 함께 고민을 던지는 식이다.

나는 주제를 던지고 의견을 제시하고 최종 결정만 할 뿐, 과정에는 최대한 참여하지 않는다. 이게 나와 함께 일하는 모든 구성원들의 역량을 더 성장시키는 방법일거라고 생각한다.

우리는 특정 위치에 부하가 많은 편이고 이걸 해결하기위해 scale out 합니다.

혹은
kafka를 도입해 이렇게 사용할것이고 컨슈머는 어떤 서비스를 사용해 이렇게 처리하도록 개선합니다.

와 같이 원인과 과정 그리고 결과를 모두 던져주고 코딩만 하세요. 라고 하는건 모두의 기회를 뺏고 성장을 막는길이라고 생각한다.

image

또 TL은 구성원의 역량 강화에만 고민하지는 않는다. 회사의 성장도 고민해야 한다.

우리 서비스가 더 잘되기 위해서 어떤 기능이 필요할까. 현재의 문제는 무엇일까 에 대해 더 많은 고민을 해야하는 약할이다. 물론 이런 부분은 PO가 대부분 오너쉽을 가지고 진행하는 일이긴 하지만 옆에서 그 고민을 함께 나눈다. 일정을 함께 논의하고 필요하다면 데이터분석도 돕는다. 그러면 분기별로 혹은 연간 일정을 정하고 그걸 팀과 공유하는 일도 하게된다.

마지막으로 구성원들의 취미생활에 대해 질문한다. 이게 무슨말일까 싶기도 하겠지만 취미생활을 질문하며 고민에 대한 이야기를 나눈다. 어쩌면 업무가 아닌 개인적인 내용을 나눈다 라고 하는게 더 맞겠다.

업무의 사기가 저하되는 일이 있다던가 업무로 인해 야근이 많아졌다 와 같은 고민을 나누고 내가 해결할 수 있는게 무엇인지 찾아본다. 만약 내가 해결할 수 없는 내용임에도 분명 해결이 필요한 문제라면 C레벨 (개발자는 대부분 CTO이다) 을 불러서라도 해결하고 넘어가야 한다.

구성원의 개인사가 있다면 충분히 공감하고 업무 일정을 조율하는 것 역시 리드가 해야할 역할이다.

이처럼 리드는 팀 내에서 여러가지 역할을 하고있다. 물론 이 많은 일들을 모든 일을 혼자서 하지는 못한다. 함께 하는 구성원들이 많이 도와주고 다른 팀 리드, C레벨에서도 도움을 준다.

리드에게도 워라벨은 중요하다. 퇴근 후 운동을 하거나 취미생활을 하는것 역시 필요한 일이다. 하지만 이 모든건 구성원들이 적절한 보호와 보상을 받고있을 때의 얘기이다.

팀 구성원이 없다면 리드는 없고 리드가 없다면 구성원들은 적절한 보호를 받지 못한다. 리드가 다른 구성원에 비해 얼마나 많은 금전적 보상을 받고있을지는 모르겠지만 누구보다 더 노력해야하는 자리임에는 틀림없다.

오늘도 리드의 자리와 역할에 대한 고민은 여전히 진행중이다.