소프트웨어 엔지니어링 분야의 고전 맨먼스 머신에는 일반적인 개발자에 비해 생산성이 2배, 10배, 심지어 100배 이상 뛰어난 슈퍼 프로그래머에 대한 이야기가 나옵니다. 생산성을 정의하는 방법에 따라 구체적인 숫자는 바뀔 수 있겠지만, 프로그래밍은 다른 분야와 달리 물리적인 제약이 없는 만큼 개인의 생산성 차이가 다른 분야에 비해 클 수 있다는 주장에는 많은 사람들이 공감하는 것 같습니다.

하지만 제 경험상 PM 입장에서 슈퍼 프로그래머의 존재는 좋아할 일만은 아닙니다. 소프트웨어 개발 문화나 프로젝트 관리 능력이 제대로 갖추어지지 않은 조직에 슈퍼 프로그래머가 있다면, 개인의 개발 생산성이 정말로 뛰어난 경우보다는 PM의 관리 능력에 문제가 있는 경우가 더 많기 때문입니다.

일례로 예전 직장에 모바일 액션 RPG 게임을 만들던 M팀이 있었는데, 이 팀에는 이른바 슈퍼 프로그래머로 알려진 K군이 있었습니다. K군은 중고등학교 때부터 정보 올림피아드에 출전하여 입상한 경험이 있고 수상 실적을 바탕으로 명문대를 특례 입학한 친구입니다. K군은 병역 특례로 지원을 했는데 회사 면접에서도 출중한 실력을 보여서 만장 일치로 선발하였습니다. K군은 팀은 클라이언트 개발자로 팀의 두 번째 멤버였는데, 첫 번째 멤버가 다른 회사로 옮기면서 입사 후 얼마되지 않아 M팀의 메인 개발자가 되었습니다.

M팀의 팀장은 이런 K군을 애지중지하며 K군이 일반적인 개발자 6명 이상의 몫을 한다며 그를 치켜세우곤 했습니다. (6이라는 숫자가 구체적으로 어떻게 도출되었는지는 알 수가 없습니다.) 2배도 아닌 6배의 생산성을 내는 K군은 슈퍼 프로그래머로 분류하기에 무리가 없어 보입니다. 실무에 무지한 사장도 팀장의 평가만 믿고 K군을 회사의 보배라고 생각하고 신입인 K군에게 파격적인 연봉을 줍니다. 이런 K군의 회사 내 별명은 “왕의 아들”이 됩니다.

M팀은 장르가 RPG인만큼 개발자가 10명 이상되는 중간 규모의 팀이었고, 이후 클라이언트 개발자를 충원하여 3-4명 수준을 유지하게 됩니다. 이후 합류한 멤버 중에는 10년 경력의 개발자도 있었고, K군과 비슷한 수준의 대학을 나온 또 다른 병역 특례 개발자도 있었습니다. 객관적으로 봤을 때 K군보다 못할 이유가 없는 개발자들이지만, 팀에 합류 후에 이렇다 할 생산성을 내지 못하였고 팀장은 더더욱 K군이 슈퍼 프로그래머임을 확신하여 K군에만 의지하여 개발을 진행하게 됩니다.

하지만 프로젝트가 중반 이후로 가면서 생산성에 문제가 생기기 시작합니다. 그다지 복잡할 것도 없는 요구사항 변경에 대응하는 속도가 현저히 느려지기 시작하였기 때문입니다. 팀의 일정이라는 것도 의미가 없어집니다. 모든 일정은 K군이 할 수 있는지 없는지에 달려 있기 때문입니다. K군이 3일을 부르면 3일이 일정이 되고, 일주일을 부르면 일주일이 일정이 되는 상황이 됩니다. 다른 개발자를 투입하려고 해도 소용이 없었습니다. K군이 작성한 코드는 K군 외에는 아무도 알아 볼 수가 없었고, 다른 개발자가 겨우 코드를 파악해서 수정을 해도 여기저기서 예상치 못한 문제가 추가로 생기는 경우가 많았기 때문입니다.

설상가상으로 영특한 K군은 이런 상황을 악용합니다. 본인이 아니면 프로젝트를 완성해서 출시할 수 없다는 사실을 알고 자기 마음대로 행동하기 시작합니다. 출근 시간을 지키지 않거나 업무 시간에 2-3시간씩 자리를 비우는 것은 약과고, 업무 시간에 다른 회사의 외주 일을 하는 경우까지 있었습니다. 참다 못한 M팀의 다른 개발자가 이 상황을 팀장과 사장에게 이야기했으나 묵살됩니다. K군이 없으면 프로젝트 출시를 못할 수도 있으니 다소 부당하게 느껴지더라도 참으라는 것입니다.

이 사례는 프로젝트 관리에서 위험 관리에 실패했을 때 어떤 일이 일어나는지 잘 보여줍니다. 이 사례가 극단적인 사례도 아닙니다. 부끄럽지만 저도 옆에서 지켜본 일이고, 주변에서도 한 번쯤 들어보셨을 흔한 일이기도 합니다. 그리고 팀장과 사장의 대처에도 볼 수 있듯이 PM이나 경영진은 본인의 실수를 인정하고 싶어하지 않아 합니다.

문제의 근본적인 원인은 K군이 아니라 팀장의 관리 능력에 있습니다. M팀의 팀장은 위험 관리를 전혀 하지 않았습니다. K군이 나쁜 마음을 먹고 이 상황을 이용하지 않았더라도 프로젝트를 진행하면서 어떤 일이 생길지 알 수가 없습니다. K군이 더 좋은 조건을 받아 다른 회사로 옮길 수도 있고, 심지어 출근하다가 교통 사고가 나서 죽을 수도 있습니다.

소프트웨어 개발 프로젝트의 가장 큰 위험 요소 중 하나는 지식이 한 명에게 집중되는 것입니다. M팀의 프로젝트는 개발 관련 지식이 K군에게 집중되어 있고, 또한 그렇기 때문에 더더욱 K군에게만 의존하게 되었습니다. 이 문제를 방지하려면 M팀의 팀장이 다른 개발자들도 코드를 파악할 수 있도록 업무 분담을 시키거나, 설계 리뷰, 코드 리뷰 등을 통해 팀내 지식이 자연스럽게 전파될 수 있도록 프로세스를 만들었어야 합니다.

또한 다른 개발자들이 코드 파악을 못하거나 생산성이 낮은 것을 보고 문제에 대한 힌트를 얻었어야 합니다. 하지만 팀장은 거꾸로 같은 상황을 보고 K군에 비해 다른 개발자들의 역량이 부족하다고 판단하였습니다. 실상은 K군이 다른 사람이 이해하기 쉽게 코드를 짜는 능력이 부족한 것이었습니다. 프로젝트 후반에 가서 생산성이 떨어진 이유는 코드가 너무 복잡해지면서 K군 본인도 본인이 작성한 코드를 100% 이해하지 못하기 시작하면서 발생한 일입니다.

슈퍼 프로그래머는 적당히 잘하는 개발자와 못하는 PM이 만들어내는 일종의 콤비 플레이입니다. 개발자가 소프트웨에 엔지니어링 원칙에 충실하게 누구나 쉽게 유지보수 할 수 있는 이해하기 쉬운 코드를 작성했다면 이런 일이 벌어질 수 없었을 것이고, 개발 팀장 혹은 PM이 이런 위험 요소를 관리하기 위한 프로세스를 도입했어도 이런 일이 벌어질 수 없었을 겁니다.

주변에 슈퍼 프로그래머가 있으시다고요? 그 팀의 팀장님은 어떤 사람인가요?