개발팀장이 필요 없는 이유

내가 CEO로 있는 이우소프트에는 한국에서 흔히 얘기하는 개발팀장이 없다. 정확히 말하면 개발팀장이라는 포지션이 있기는 한데 일반적인 개발팀장은 아니다. 관리를 전혀 하지 않는 개발팀장이다. 평가 등 몇몇 행정적인 역할이 필요하기 때문에 개발팀장 포지션이 있기는 하다.

회사마다 개발팀장의 역할이 다르고 뭐가 옳고 뭐가 그르다라고 할 수는 없다. 하지만 대부분의 소프트웨어 회사에서 조금 또는 많은 시간을 관리에 할애를 해야 하는 개발팀장과 다르게 이우소프트에서는 개발팀장이 관리를 전혀 하지 않는다. 이우소프트에서는 이렇게 하는 것이 가장 효율적이라고 생각을 하기 때문에 개발자에게는 지위고하를 막론하고 관리를 전혀 시키지 않는다.

개발팀장이 관리를 전혀 하지 않는다는 것은 크게 두 가지 의미가 있다.

첫째, 개발자에게는 팀장이든, 누구든 관리를 시키지 않음으로써 개발에 전념하도록 하고 개발자로서 꾸준히 성장하여 60세가 되어도 개발자로서 경력을 유지할 수 있도록 한다.

둘째, 관리가 필요 없는 조직 문화에서는 개발이 더 효율적으로 진행된다.

첫 번째, 개발자 경력에 대한 얘기를 먼저 해보자.

관리형이냐 실무형이냐에 따라서 조금씩 다르기는 하지만 소프트웨어 개발이 아니라도 대부분의 팀장들은 관리도 하고 실무도 하게 된다. 많은 회사에서 개발팀장은 개발도 하고 관리도 한다. 대부분은 경력이 많을수록 관리를 더 많이 하게 된다. 관리 일이 많아질수록 개발에 힘을 쏟을 시간은 부족하게 되고 점점 개발자로서 역량을 유지하기 힘들게 된다. 그렇게 오랜 시간 관리에 시간을 빼앗기면 마음만 개발자이고 실제 개발에는 별로 도움이 안 되는 간섭 잘하는 관리자가 되기도 한다.

그렇게 어정쩡한 관리형 개발팀장들은 전문적인 관리자와는 다르다. 자신이 기술과 개발에 대해서 잘 알기 때문에 수시로 기술에 관여를 하게 된다. 그러면서 권위를 내세워 잘못된 기술적인 결정을 하기도 한다. 그러면서 전문적인 관리는 잘 하지 못하기 때문에 개발자들은 오히려 힘겨워하곤 한다.

다른 분야보다 소프트웨어 개발 분야에서는 유독 개발자로서 경력을 유지하기 어려운 이유는 소프트웨어 기술이 너무 빨리 바뀌고 새로 배워야 할 기술이 너무나 많기 때문이다. 또한 그 속도는 점점 빨라지고 있다. 관리도 하고 보고서 쓰는 등으로 시간을 보내서는 그 속도를 따라 갈 수가 없다.

우리 회사에서는 개발팀장이라고 해서 행정적인 권위는 거의 없고 기술 카리스마 밖에 없다. 그렇게 기술로 경쟁을 해야 하기 때문에 끊임없이 기술을 익혀야 하고, 그렇기 때문에 60세가 넘어도 개발자로서 일할 수 있다. 또한 연공서열이 의미가 없기 때문에 나이 어린 PM과도 문제 없이 일해야 한다. 구글의 경우 72세의 개발자도 현역으로 일을 하고 있다고 하는데 개발자가 개발에 전념을 할 때 가능한 일이다.

두 번째, 관리가 거의 필요 없는 조직 문화가 왜 더 효율적인지 얘기해보자.

관리를 많이 필요로 하는 조직은 개발팀장이 관리 때문에 할 일이 많아지고 개발실장, 본부장 등 회사마다 다르지만 여러 단계의 많은 관리자들이 필요하게 된다. 그럼 관리를 잘 하면 개발이 더 효율적으로 진행이 될까? 현실은 그렇지 않다.

소프트웨어 개발은 창의적인 지식노동이기 때문에 벽돌 쌓듯이 할 일을 딱 정해서 시간 단위로 관리를 하는 것이 그렇게 효율적이지 못하다. 해야 할 일의 대부분은 개발자들이 스스로 찾아내는데, 관리가 철저한 조직일수록 꼭 해야 할 일들이 숨겨지게 된다.

개발자들은 꽉 짜여진 관리틀 속에서 꼭 해야 할 일을 찾아내더라도 적극적으로 수면 위로 드러내지 못한다. 작은 리팩토링이 필요한 모듈을 찾아내거나 개선 사항이 있어도 팀장이나 관리자에게 얘기를 했다가는 자신이 해야 할 일만 늘어나는 결과를 초래하여 야근만 증가하기 때문에 적극적으로 얘기를 하지 않곤 한다. 흔히 누군가 아이디어를 얘기하거나 개선 사항을 말하면 의견 제시자에게 일을 시키는 것이 관행인 회사에서는 쉽게 말을 못 꺼낸다. 결국 시키는 일만 최소로 하는 소극적인 자세를 보이게 된다. 특히나 야근을 밥 먹듯이 하는 회사에서는 더욱더 스스로 일을 찾아서 겉으로 드러내기가 쉽지 않다. 문제는 꼭꼭 숨어 있다가 지뢰나 시한폭탄이 된다.

우리 회사에서는 어떤 할 일을 찾아내거나 아이디어, 개선 사항이 있으면 그 즉시, 지체하지 않고 이슈관리시스템에 등록하도록 되어 있고, 많은 직원들이 습관처럼 그렇게 하고 있다. 이렇게 시스템에 올리면 등록자는 시스템에 올리는 것으로서 첫 번째 역할을 끝낸 것이다. 이 일이 무작정 등록자에게 할당이 되거나 당장 처리를 하게 되는 일은 없다.

이렇게 등록된 일은 곧 여러 사람이 보게 된다. 그래서 다른 사람이 스스로 일을 가져가서 일을 하기도 하고, 기술적인 이슈라면 기술위원회에서 처리를 하기도 하고, 버그나 새로운 기능은 PM이 관리를 하기도 한다. 또한, 당장 처리를 하는 일도 가끔 있지만 대부분은 우선순위에 따라서 나중에 처리를 한다. 어떤 이슈는 몇 년 후에 처리를 하기도 한다.

이렇게 누구나 해야 할 일을 찾아서 시스템에 자유롭게 등록하고 스스로 관심이 있는 일을 가져가 처리를 하게 되면 관리가 최소화 되고 꼭 해야 할 일의 대부분의 일들이 숨겨지지 않고 표면 위로 드러나며 빠짐없이 관리가 된다.

물론 개발자가 프로젝트에 투입되면 명확한 임무가 주어진다. 프로젝트 안에서도 미시적으로는 위와 같이 스스로 진행하는 일들이 매우 많기는 하다.

이렇게 일하기 때문에 모든 업무는 시스템에 자동으로 기록이 되며 그 과정이 추적되고 공유되기 때문에 대부분은 사전에 허락을 받지 않고 스스로 판단 하에 진행을 한다. 그래서 별도의 일일보고, 주간보고를 작성할 필요도 없다.

간단한 일은 이슈관리시스템에 공유를 하고 진행하지만 일주일 이상 걸리는 일들은 엔지니어링 원페이저(Engineering One-Pager)라는 문서를 작성하곤 한다. One-Pager는 아주 간단한 스펙 문서로서 1,2페이지 또는 조금 더 작성하기도 한다. 작성된 One-Pager는 관련된 사람들이 모두 리뷰를 하여 필요성과 적절성을 검토한다. One-Pager를 작성한 사람이 그 일을 하기도 하고 다른 사람에게 그 일을 시키기도 한다. 어쩔 때는 홀딩(Holding)을 해 놨다가 나중에 진행하기도 한다. 물론 드롭(Drop)을 하기도 한다.

One-Pager를 쓰는 이유는 공유, 기술검증, 중복 방지, 학습, 타당성 검토 등 여러 가지 목적이 있다. One-Pager를 숙제처럼 부담스러워하는 개발자들도 일부 있다. 2,3일에서 2,3주 걸리는 일은 자연스럽게 무엇을 할지를 적고 검토를 받는 것을 자연스럽게 생각해야 한다. 우리 회사에서는 그 형식이 One-Pager일 뿐이고, 형식은 회사마다 다를 수 있다.

이렇게 스스로 일하는 문화를 통해서 적극적인 사람은 얼마든지 자신의 생각을 표출하고 기회를 얻을 수 있고, 수동적인 사람은 매일 시키는 일만 하기도 한다. 물론 이우소프트에서는 적극적인 표현을 권장하고 있다. 이러다 보니 개발자의 커뮤니케이션 능력을 매우 중요한 역량으로 본다.

개발자 채용 시 코딩테스트를 할 때도 코딩만 평가하지 않고 코드를 적어가는 과정에서 얼마나 적절한 커뮤니케이션을 하는지 본다. 물론 문제마다 커뮤니케이션 내용이 다르기 때문에 정답은 없다. 문제의 의도를 좀더 정확하게 파악하고 불확실한 요소를 제거해 나가는 대화 접근법은 10분짜리 코딩 테스트 시나 실전 개발 시나 비슷하게 나타나기 때문이다.

가장 골치 아픈 개발자는 의문이 있거나 문제가 있는데도 공유, 리뷰, 의논 등을 하지 않고 혼자가 다 처리해버리는 경우다. 이렇게 대화를 싫어하는 개발자는 문제를 일으키기 쉬우며 성장하기도 어렵다.