팀장 딜레마…에 붙여

많은 회사들이 개발자들의 경력 관리에 있어서 딜레마에 빠집니다. Jason님의 팀장 딜레마를 보면 모험과 개선을 위한 일과 안정적인 일 사이에 인력을 어떻게 배치 할지 어떤 사람을 들어 써야 할지 참 애매할 때가 많습니다. 바로 아래와 같은 경우죠.

– 팀에서 개발 잘하는 사람이 팀장을 합니다. 그렇게 되면 개발을 제일 잘하는 사람은 없어집니다.
– 팀이나 회사나 새로운 성장 동력을 찾아야 하는데, 제일 일 잘하는 사람은 기존(안정적인) 일에서 쉽게 뺄 수가 없습니다. 혁신은 그만큼 리스크가 따르기 때문에 현재 상태를 유지하는 일도 챙겨야 하기 때문이죠.
– 제일 일 잘하는 사람이 개선도 그만큼 잘 할텐데, 그걸 알면서도 쉽사리 결정할 수 없는 딜레마에 빠집니다.
팀장 딜레마 중에서

제 주변에서도 이런 일을 흔히 겪고 있습니다. 개발 잘 하는 사람이 곧 매니징을 잘 하는 사람은 아니기 때문에 꼭 사람을 관리하는 주 업무에서 시행착오를 겪게 됩니다. “팀장 되니 사람 바뀌더라” 또는 “팀장이 제대로 방어 못한다” 등등… 새로 팀장 된 사람들은 매니징의 굴레속에 번민 하기도 합니다.

국내 대부분 IT 회사의 개발자 커리어 패스가 결국 PM과 HR이 혼합된 팀장으로 가고 있기 때문에 나타나는 현상입니다. 그렇다고 무턱대고 외국 처럼 아키텍터 그룹을 만들기도 쉽지는 않습니다. 제가 생각한 방법은 한 팀 내에 관리팀장(Project Manager)과 기술팀장(Technical Manager)을 두는 것입니다.

관리 팀장은 대인 관계가 원만하고 프로젝트 일정을 꼼꼼히 챙기며 업무 분담을 잘 주고 관리할 줄 아는 사람으로 두고 기술 팀장은 프로젝트 중 기술 컨설팅과 개발자 교육 및 스킬업 등등을 챙기게 하는 것입니다. 개발팀이 하나인 회사에서는 관리팀장과 기술팀장이 정말 친하고 맘이 맞는 사람으로 합니다만 의사 결정은 관리팀장이 하도록 합니다.

개발팀이 여러개인 곳에서는 기술팀장들만 따로 풀(Pool)을 운영 합니다. 기술팀장들은 각 팀의 프로젝트 단위로 업무에 관계 합니다. 초기 프로젝트 기능 명세를 작성할 때 들어가 어떤 프레임웍을 사용할 것인지 어떤 방식으로 개발 할 것인지 어떤 개발 기법을 사용할 것인지를 컨설팅 해 줍니다. 또한, 프로젝트 중간 중간에 생기는 문제를 그때 그때 관리팀장의 요청을 받아 해결 해주러 들어갑니다. 또한 마지막 QA 시 기술팀장들이 마지막 점검을 합니다.

기술팀장 풀에는 아키텍쳐, QA, 문제 해결 담당 등 역할에 따라 업무를 나누어서 필요할 때 각 개발팀을 지원해 주는 업무를 하는 것이죠. 기술 팀장들은 업무의 일부(30%) 정도를 기존 업무 개선 활동에 참여 합니다. 서비스 운영을 하는 유지 보수 개발자들과 인터뷰 하면서 기술 멘토링과 더불어 개선 사항이 있는지 찾아 냅니다. 개선 사항이 있다고 판단 되면 관리 팀장에게 이야기 해서 개선 일정을 잡도록 합니다.

이들은 개발을 잘하는 사람들이 모여 있기 때문에 밤에 남아 종종 프로토 타입도 만들고 아이디어도 구현해 볼 수 있습니다. 이렇게 나온 아이디어는 서비스 프로젝트로 발전할 수 있을 것이구요. 그렇게 되면 기술팀장들이 다시 개발 프로젝트에 컨설턴트로 참여 합니다.

회사의 입장에서는 두 명의 팀장을 둬야 하는 리스크가 생깁니다만 비용적인 측면에서 어차피 한명이나 두명이나 조율만 잘 하면 그런 것은 큰 문제가 안되고 오히려 이를 통해 생산성이나 효율성 그리고 창의성이 올라간다면 충분히 투여 가능한 비용이 될 것입니다.

문제는 기술 팀장 조직 혹은 관리 팀장 및 기술 팀장 사이를 잘 조율한 기술 담당 임원이 필수적입니다. 그냥 무턱 대고 기술을 잘 모르는 사장이 두 명을 따로 뽑아서는 효과를 얻기 힘들고 나중에 문제가 생겼을 때 조율하기도 힘드니까요. 이런 방식은 한 사업본부에 하나의 개발팀만 있는 조직에는 적용하기 힘들고 가급적 직능별로 모여 있는 조직에서 수용하기 쉬운 방식입니다.

이 방식은 2005년에 개발팀이 여러 개인 조직에서 아주 짧은 기간 진행해 봤던 방식이었는데, 매니징을 원하지 않는 시니어 개발자와 매니징 업무를 하는 팀장 그리고 일반 개발자들 사이에도 꽤 만족도가 높았던 것으로 기억 합니다. 하지만, 이 방식을 선택해서 생기는 문제에 대해서는 이 블로그는 책임지지 않습니다.^^

여러분의 생각

  1. gimmesilver 2007 6월 26 13:24

    마지막 글의 문투로 봐서는 만족도가 꽤 높았지만 지금은 사용하지 않는 것 같군요…맞다면 혹시 그 이유가 무엇인지 물어봐도 될까요?

  2. gimmesilver / 2006년 초에 Head가 바뀌는 좀 큰 규모의 조직 개편이 있었습니다. 그래서 저는 사내 개발 조직을 보는 업무를 접고 외부 개발자 지원을 맡게 되었습니다.

  3. 저도 같은 문제에 대해서 고민한 적이 있었지만,
    말씀하신대로 해결책은 각 회사내부에서 고민해야 할 것 같습니다.

    회사의 규모, 내부의 상황/경영여건, 인력수준에 따라서 그 대응방법은 달라질 수 있기 때문입니다.

    저희 같은 경우에는 “내부 세미나제도”, “개발 히스토리나 팁 관리를 위한 위키운영”, “프로젝트 리뷰”를 통해서 인력수준을 점차 개선할 수 있었습니다.

    또한, 권한을 팀 하부에 파트를 두어 파트장 중심으로 움직일 수 있도록 하였습니다. 그러면서 기술팀장도 기존의 아키텍처나 설계, 개발을 병행할 수 있게 되었죠…

    이것도 한 예일 뿐입니다. 정답은 없다고 생각합니다.

    문제에 대한 치열한 고민과 나름의 해결책을 찾아야 할 것입니다.

  4. 지영아빠/ 네 좋은 경험 나눠 주셔서 감사합니다. 그런데 저희도 대개 파트장(PL)을 두는 개발팀을 가지고 있는데 그렇더라도 팀장은 파트에서 생기는 HR이슈나 외부 커뮤니케이션때문에 실질적으로 코드짜는 일과는 거리가 멀어질 수 밖에 없더라구요.

  5. 저도 나름대로, 파트 내의 작은 팀을 맡고 있는데요(저희는 sub-pl이라고 해요).
    그렇게 된 다음부터 제 일(개발)을 해낼 시간이 없어지더라구요. 물론, 팀원을 챙길 시간도 점점 없어졌구요. (그렇다면 도대체 무엇을 했을까요??)

    그래서 저도 channy님이 제안한 것 처럼
    아키텍트(기술팀장)와 sub-pl(관리팀장)을 분리해서 운영을 시도하고 있습니다.
    아직은 둘 간의 role이 명확하지 않은 부분도 있지만. 예전보다 (아직까지는) 좋은 것 같습니다.

    좀 더 시간이 더 지나면 더욱 명확하게 잘 정리할 수 있을 것 같아요.

의견 쓰기

이름* 이메일* 홈페이지(선택)