웹 서비스 개발팀의 팀장

지위가 사람을 규정한다는 말이 있다. 심리학적인 관점이든 경영학적 관점이든 지위에 따라 똑같은 사람의 생각과 행동 양식이 달라진다는 것은 익히 알려진 사실이다. 이것은 웹 서비스 개발팀의 팀장에게도 똑같이 적용된다.




이야기를 시작하기 전에 '웹 서비스 개발팀의 팀장'은 프로그래머를 지칭하지 않음을 분명히 해야겠다. 개발팀의 팀장이라면 대개 프로그래머이거나 프로그래머 경력이 있는 사람일 가능성이 매우 높지만 '웹 서비스 개발팀'은 그렇지 않은 경우도 있다. 여기서 '개발팀'은 특정 웹 서비스를 만들기 위해 모인 사람들 모두를 말한다. 개발팀은 프로그래밍을 하는 사람과 디자인을 하는 사람, 기획을 하는 사람을 지칭한다. 마케팅이나 고객 지원, 프로모션 팀도 포함될 수 있겠지만 이렇게 될 경우 개발의 범주가 '비즈니스 개발'로 확대된다.


거부

새로운 웹 서비스를 개발하기 위한 프로젝트가 시작되었고 팀이 구성될 시점이다. 누군가 이 팀을 총괄할 팀장 역할을 수행해야 한다. 팀장 대신 PM(Project Manager)이라고 부르는 곳도 있고, 팀장과 PM이 각각 존재하는 경우도 있다. 어쨌든 팀장을 뽑아야 한다. 서로의 장점과 한계를 잘 알고 있는 작은 조직의 경우 자연스럽게 팀장이 정해 진다. 어떤 작은 조직은 누구도 팀장 경험이 없었고 팀장의 역할이 무엇인지 제대로 의논하지도 않았지만 그 사람이 팀장이 되어야 한다는데 아무런 이견이 없었다. 왜냐면 그 사람이 팀을 만든 사람이고 회사의 사장이기도 했기 때문이다.

그러나 조직의 규모가 커지면 팀장을 선정하는 문제는 복잡해진다. 어떤 조직은 팀장이 되려는 사람이나 될 수 있는 사람이 너무 많아서 문제고, 또 다른 조직은 팀장이 되려는 사람이 아예 없거나 팀장이 되지 않으려는 사람이 너무 많아서 문제다. 큰 조직은 실제로 팀장의 역할 수행에 대한 문제보다 누구도 팀장이 되지 않으려는 문제가 더 자주 나타난다. 그 이유도 다양하다. 큰 조직에서 일하는 사람들이 팀장이 되길 거부하는 이유는 대개 이런 것이었다.

- 시간이 없다
- 바쁘다
- 다른 일을 해야 한다
- 그가 훨씬 잘 할 것이다, 난 바쁘다

자신이 팀장이 될 수 없는 수 천 가지의 이유를 들어 봤지만 대개 위 이유를 벗어나는 경우는 없었다. 웹 서비스를 제대로 만들기 위해 회사는 제대로 된 인재를 개발팀에 포함시켜야 하는데 인력 배치에 있어서 가장 중요한 첫번째 선정 작업은 바로 '팀장'이다. 누군가 나서서 자신이 팀장이 되겠다고 하는 아름다운 광경은 보기 매우 힘들다. 특히 누구도 다루기 힘든 뜨거운 감자와 같은 프로젝트의 개발팀장을 뽑는 것은 꽤 까다로운 일이어서 이것 때문에 프로젝트 시작이 지연되기도 한다.

몇 년 전 한 회사가 처한 상황도 비슷했다. 벌써 1개월 전에 프로젝트에 돌입해야했지만 개발팀장이 뽑히지 않은 상태였다. 회사에서 개발팀장 후보자에 오른 사람은 3명이었다. 회사는 3명 중 누군가 반드시 팀장이 될 것이라 확신했던 것 같다. 그러나 3명 모두 개발팀장이 되길 거부했다. 3명이 거부한 이유는 흥미롭게도 3가지였다. 3명을 만나서 거부의 이유를 들어 봤다,

A씨 : "현재 업무가 과중해서 새로운 업무를 맡을 수 없어요."
B씨 : "프로젝트에 처음부터 제가 개입한 것도 아니고 제가 잘 할 수 없을 것 같아요."
C씨 : "그동안 제가 했던 일과 관련이 많기는 하지만 저는 곧 회사를 그만 둘 것입니다."

맙소사! 회사에서 그렇게 믿고 있던 개발팀장 후보자 3 명은 모두 그럴싸한 이유를 대며 프로젝트를 담당하지 않겠다고 선포하고 있었다. 이 사태를 어떻게 받아들일 것인가. 내부 후보자 대신 새로운 외부 인력을 뽑아야 할까? 아니면 경험이 부족하더라도 적극적으로 프로젝트에 개입하고 싶어하는 보다 경력이 적은 사람을 다시 후보자로 물색해야 할까? 고민이 꼬리를 물고 있을 때 문득 세 명이 내게 정말 정확히 거부의 이유를 밝힌 것인지 궁금해졌다.


진실

나는 3 명의 후보자의 평판을 알아 보기 위해 그들과 친근하거나 그들과 현재 업무를 함께 진행 중인 사람들을 만나가기 시작했다. 후보자들의 회사 동료와 친구, 상사를 만나서 그들의 최근 상황과 프로젝트에 대한 입장을 수집하기 시작했다. 며칠 지나지 않아 놀라운 사실을 발견할 수 있었다. 3 명의 후보자 중 두 명은 동일한 시기에 다른 회사에서 현재 회사로 이직한 사람이었고 매우 절친한 사이였다. 또 다른 한 명은 조금 늦게 입사했는데 두 사람과 관계가 그렇게 좋지 못한 편이었다. 놀라운 사실은 새로운 프로젝트가 시작되기 전에 이미 세 사람이 모여서 이 프로젝트의 팀장으로 누가 적절할 지 의논한 적이 있다는 것이었다. 그 자리에서 A씨는 B씨를 추천했다고 한다. C씨는 자신이 이 프로젝트의 적임자라고 생각했지만 별 다른 의견을 제시하지 못했다고 한다.

그런데 회사는 이런 관계를 잘 모른 상태에서 세 명의 후보자들을 공정하게 평가하여 팀장으로 임명하겠다고 공지를 했다. 회사 측에서는 C씨가 가장 적절한 후보자라고 내부적으로 평가하고 있었다. 문제는 회사 측의 생각을 이미 세 명의 팀장들이 알고 있었다는 점이다. 이렇게 되자 세 명의 후보자들은 위와 같은 태도를 취하기 시작했다. C씨가 회사를 그만두겠다고 말한 것은 A씨와 B씨가 만약 B씨가 아닌 다른 사람이 개발팀장이 된다면 팀원 차출이나 프로젝트 협력에 문제가 있을 것이라고 주위에 이야기를 하고 다녔기 때문이다. C씨는 이런 식이라면 더 이상 회사에 다닐 이유가 없다고 생각하고 있었다.

이 3류 소설과 같은 이야기를 알게 되었을 때 내 심정은 오히려 편안했다. 최소한 모든 후보자들이 프로젝트에 무관심한 상태는 아닌 것이 분명했기 때문이다. 그들은 하나같이 자신이 프로젝트를 맡으면 잘 할 수 있을 것이라고 생각하고 있었던 것 같다. 비록 작은 권력 암투가 벌어지고 있었지만 프로젝트에 대해 무관심한 것보다는 훨씬 낫다. 그 따위 권력 암투를 벌인 대가는 나중에 프로젝트가 시작된 후 '완결성 낮은 웹 서비스'가 나왔을 때 100배로 복수하면 될 일이다.

프로젝트 개발팀장을 선정하지 못하는 주요한 이유를 알아 냈다. 회사의 대표자와 이런 상황에 대해 이야기를 하고 그의 의견을 듣기로 했다. 그는 그런 상황이 있다는 걸 대충 짐작은 했다고 말했다. 그도 이 문제를 어떻게 해결해야 할 지 난감한 상황이라고 말했다. 나는 세 명 중 한 명을 회사에서 떠나게 할 수 있는지 물었다. 결론은 어떻게 되었을까. 프로젝트는 진행되었고 아무도 회사를 떠나지 않았다. 대신 프로젝트는 새로운 팀장을 영입하여 새롭게 구성된 팀에서 진행하게 되었다. 비록 프로젝트는 2개월 가량 더 지연되었지만 회사의 내부 권력 싸움에서 자유로울 수 있었다. 기존 팀장들은 회사의 도움으로 새로운 교육 과정에 들어가거나 다른 업무를 부여 받는 식으로 갈등을 해결해 나갔다.


이 이야기는 개발팀의 팀장에 대한 수 많은 이야기 중 극히 작은 이야기일 뿐이다. 우리는 프로젝트의 팀장을 선정할 때 그들이 가진 기술적 가치로 판단하려는 경우가 많다. 그의 생각이나 상황에 대해 이해를 하지 못하고 단지 그가 가진 기술과 경험에 의해 팀장을 선정하게 된다면 그 결과물을 확신할 수 없게 된다. 사람이 중요하다는 뻔하고 뻔한 이야기는 그 가치가 분명하지만 '사람들의 관계'에 대해 잘 알지 못하면 그저 쓸모없는 분란을 오랫동안 보존할 뿐이다.