말썽꾸러기 잠수부들

얼마 전에 아는 후배한테서 뜬금없이 고민상담 요청이 왔었다.

같이 프로젝트에 나가 있는 나이 어린 동료 한명이 이틀째 출근을 안한다는 것이다. 프로젝트 기간 내내 칼퇴근 하다가 갑자기 일이 몰려서 바빠진 상태이긴 했지만, 전혀 어떤 문제가 있는 내색이 없어서 예상치 못한 돌발상황에 적잖이 당황스러워 했다. 그 어린 친구는 후배가 추천해서 입사를 시켰기 때문에 프로젝트에 대한 걱정뿐만 아니라 도의적인 책임까지 갖게 되었다.

그 어린 친구는 나도 잘 알고 있고 개인적으로 무척 좋아했던 사람이다. 개발에 대한 기본기도 탄탄했고 전반적인 스킬도 훌륭하였다. 업무에 대한 이해도 정확하고 무척 빨랐을 뿐더러 무엇보다 주위 동료들이 힘들어 할 때 많은 도움을 주던 사람이었다. (주로 여자들한테 도움의 손길을 뻗쳤지만..)

문제는 그 어린 친구가 이삼일 씩 무단 결근을 한 것이 벌써 네번째라는 것이었다. 예전 회사에서 무려 세 번의 전과가 있었고, 마지막에는 그 능력은 인정하나 조직의 질서를 위해 어쩔 수 없이 자의반 타의반으로 회사를 그만두게 되었다. 이미 회사에 대한 미련이 전혀 없었을 때였으리라.

추가인력의 투입은 언제가 좋을까?

일명 "죽음의 행진(Death March)" 프로젝트에는 여러 공통점들이 있다.
그 중 가장 흔하고, 그러지 말아야지 하면서 잘 안지켜지는 게 밑빠진 독에 물붓는 식으로 추가인력을 투입하는 것이다. 이는 필요에 의해서 일 수도 있고, 갑이나 을의 압박에 의해 울며겨자먹기 식으로 발생하기도 하고, 전략적인 차원(주로 비지니스적인)에서 일어나기도 한다.

스티브 맥코넬의 말을 굳이 빌리지 않더라도, 프로젝트가 어려움에 빠져있을 때 이를 해소하기 위해 추가인력을 투입하면 프로젝트가 오히려 더 깊은 수렁에 빠지는 경우가 실제로 아주 많다.

예전에 갔었던 어느 금융권 프로젝트에서는, 일정 지연을 이유로 고참 PL이라는 사람이 너무나 쉽고 당당하게 추가 인력을 요구하는 모습을 봤었다.

> 본부장 : "일정이 왜 이리 안나가지?"
> PL : "개발자가 부족합니다."
> 본부장 : "얼마나 있어야 되는데?"
> PL : "많으면 많을 수록 좋죠."
> 본부장 : "헐... 두 세명이면 되나?"
> PL : "예. 그 정도면 될 것 같습니다"

자신이 그 업무의 리더라는 사실을 잊고 사는 사람이다. 정확하게 어느 수준(스펙)의 개발자가 어떤 파트에 필요한지 정도는 파악을 하고 있어야 하지 않을까? 이런 부류의 사람들은 프로젝트가 한참 더 힘들어져 있을 때, 그 추가로 투입된 신입개발자 2명의 실력이 떨어져서 진도가 안나간다고 보고할 사람들이다. 그런 상황을 미리 예측하고 필요한 조치를 취하지 못한 자신에게 모든 책임이 있을 뿐이다.

티맥스소프트의 워크아웃을 바라보며...

티맥스가 워크아웃에 들어갔다고 한다.

수년간 몸담으며 꿈과 희망을 갖고 젊은 나날을 보냈던 티맥스의 워크아웃 소식에, 이미 예견은 했지만 그래도 가슴이 아프다. 대한민국 Software의 미래라며 끊임없이 스포트라이트를 받아온 티맥스소프트가 어쩌다가 저렇게 한방에 훅 갔을까?

대부분의 사람들은 티맥스 몰락의 원인을 "무리한 윈도우 개발" 탓이라 생각하지만, 나는 그보다 훨씬 오래 전에 박대연 회장에 의해 만들어진 "Software Stack" 전략 때문이라 본다.

Software Stack이란 OS - DB - Middleware - Framework - Application 등 시스템의 모든 Layer를 다 커버할 수 있도록 각 Layer에 맞는 제품군을 모두 확보하려는 전략이다. 그것도 자체 개발로... "이것은 세계에서 유일하게 IBM만이 갖고 있을 뿐이다"라고 박대연 회장은 늘 말해왔었다. Middleware야 원래 주력이었으니 논외로 하고, DB와 Framework(프로프레임)의 시작은 7~8년 까지 올라간다. 기업용 Embedded OS가 아닌 일반 사용자용 윈도우 개발이 본격적으로 시작된 시점은 불과 3년 정도일 뿐이다.