구시대 프로젝트 매니저의 실패기(記)

1.
참으로 오랜만의 글쓰기입니다. 프로젝트를 시작하면서 한주의 한번 글쓰기 다짐은 끝내 이루지 못하였습니다. 무척 힘들었던 프로젝트였습니다. 주어진 업무와 시간 및 인원을 놓고 아무리 궁리를 하여고 끝낼 수 없는 일이었습니다. 그렇지만 프로젝트 매니저는 프로젝트의 끝을 책임져야 하는 사람입니다. 주어진 책임을 어떻게 이룰지 고민과 고민의 연속이었던 시간이었습니다.

여의도에서 이루어지는 프로젝트. 대부분의 프로젝트는 발주부터 부실합니다. 요구사항이 무엇인지 두리뭉실한 경우가 많고 요구사항과비용사이에도 괴리가 큽니다. 비용을 절약하여야 성공이라고 생각하는 분들이 많습니다. C 임원부터 시작하여 구매부서도 그렇고 IT담당자도 다르지 않습니다. 현실과 목표의 괴리는 고스란히 프로젝트를 수주한 회사의 책임으로 남습니다. 경쟁입찰을 한 경우 어떤 변명도 통하지 않습니다. “적자를 감수하면서 프로젝트에 입찰했냐?” 는 질문을 받으면 답변이 궁색해집니다. 이제 모든 책임은 프로젝트를 맡은 책임자와 개발자에게 주어집니다.

지금도 인구에 회자하는 ‘월화수목금금금’은 이런 구조의 산물이고 기업이 프로젝트조직에 책임을 떠넘기는 일반적인 방식입니다. 요구사항에 비해 시간과 인원이 부족한 현실에서 누구나 쉽게 떠올릴 수 있는 방법은 시간과 인원을 늘리는 방법입니다. 근로기준법에서 정의한 휴일근로, 연장근로입니다. 노동자에게 시간은 곧 돈입니다. 일하는 시간이 늘어나면 당연히 댓가도 커져야 하지만 현실은 그렇지 않습니다. 계약때문입니다.

오래전 회사를 경영한 이후 프로젝트를 수주하지 않습니다. ZeroAOS와 관련한 프로젝트를 제외한 영업활동을 하지 않습니다. 이번에 맡았던 프로젝트 매니저는 외주개발자로써 주어진 역할입니다. 외주PM은 내부PM과 비교할 때 차이가 많습니다. 결정적인 차이는 인사와 관련한 부분입니다. 개발자를 늘리고 교체하는 부분입니다. 외주PM은 수주기업의 사업담당자의 지휘감독을 받을 수 밖에 없습니다.

2.
ActiveX로 개발된 5개 사이트를 4개월동안 HTML5로 전환하는 일을 놓고 어떻게 해야할지 막막했습니다. 더구나 HTML5라고 하지만 생소한 기술을 적용하여야 합니다. 2003년 미래에셋증권 WTS를 개발할 때 악몽이 떠올랐습니다. 개발시스템을 1단계와 2단계로 나누었습니다. “All or Nothing”으로 프로젝트를 할 수 없기때문에 최소한의 보험을 만들었습니다. 시스템을 개발할 때 무척 중요한 분석과 설계를 건너뛰었습니다. 대신 내부 파일럿으로 공통기능을 구현하는 단계를 두는 것으로 WBS를 작성하였습니다. 아울러 개발을 두 부분으로 나누어 HTML과 관련한 일정(UI), Javascript와 관련한 일정(비즈니스)로 나누었습니다. 최대로 노력해도 5개중 2개를 할둥말둥한 일정이었습니다. 프로젝트를 시작하고 몇 주가 지난 어느 월요일 전체회의. 이런 말을 하였습니다.

“주어진 기간내에 프로젝트를 끝내기에는 범위가 작지 않다. 프로젝트의 앞날을 위해 최선을 다하는 모습이 프로젝트의 끝을 위해 중요하다. 아마도 추석이 끝난 이후부터 주 6일, 좀더 지난 주 7일근무를 해야 한다”

관행이라는 이름의 부조리입니다. 그래서 특별한 반응이 없을 것으로 예상했지만 의외의 반응이 나왔습니다.

“개발자의 동의 없는 강제근로는 불법입니다.”

순간 크게 한방을 맞았습니다. ‘강제근로’를 시킨 나쁜 경영자가 되는 순간이었고 앞날이 캄캄했습니다. 앞서 지적한 것처럼 외주PM이 특별한 계기없이 인원을 늘려달라고 할 수 없습니다. 책임이 따릅니다. 더구나 프로젝트의 초반입니다. 더욱더 할 수 없는 일입니다. 제가 구시대 발상을 하는 것인지, 개발자들이 무책임한지 각자의 몫입니다.

다시금 한달이라는 시간이 흘렀습니다. 프로젝트를 두달 반 남겨놓은 시점에서 남은 일을 판단했습니다. 1단계도 지지부진하니 2단계를 시작할 수 없었습니다. 총체적인 난국입니다. 생소한 개발도구가 미친 영향이 큽니다. 그렇지만 더 큰 문제는 개발자들간의 불협화음입니다. 비슷한 경력이고 인원이 많지 않아서 별도의 리더를 만들지 않았습니다. 팀 빌딩을 하지 않는 저의 탓이겠지만 협력이 이루어지지 않습니다. 소통이 원할하지 않고 일을 놓고 갈등을 합니다. 이 때문에 몇 번 주사업자와 교체를 이야기했지만 번번히 거부당했습니다. 할 수 있는 방법은 ‘나누기’였습니다. 개발자 전체를 1단계와 2단계로 팀을 나누고 2단계를 새로 시작하는 개발자들은 하던 일을 1단계 개발자에게 인수인계하는 방식이었습니다. 그리고 TBD로 잡혀있던 개발자들을 투입하지 않고 1개월 기간을 연장하는 방식으로 인력운용계획도 변경하였습니다.

3.
이 때부터 고생길이었습니다. Javascript로 개발하거나 하기로 한 업무와 HTML/CSS를 통합하고 다시금 개별화면을 묶어서 하나의 시스템으로 만드는 작업은 길고 길었습니다. 주 7일 근무의 시작입니다. PM인 저는 테스터, JS개발은 두명, HTML 및 CSS는 한명이 맡아서 120개 화면을 마무리하여야 했습니다. 일반고객용 자산운용사서비스입니다. 일반적인 매매시스템과 비교할 때 단순한 듯 보였지만 펀드매매는 쉽지않았습니다. 그리고 10여년동안 사용했던 역사가 고스란히 시스템에 녹아 있었습니다. 시험을 할 때 마다 보이는 ‘JScript error’는 정말 환장하게 만듭니다. 테스터이지만 PM입니다. 2단계와 관련한 일정계획과 진척사항을 확인하여야 합니다. 예상과 다른 지척을 보입니다. 개발자들과 회의를 해보니 두팀으로 분리할 때 목표로 했고 합의했던 사항이 지켜지지 않았습니다. 개발자들이 HTML작업을 할 인원이 부족하다고 합니다. 저는 합의대로 진행하자고 했지만 수행기업의 사업관리책임자와 개발자들이 협의하여 인력을 추가로 투입하기로 합의했네요. 저의 무능력으로 하나의 프로젝트안에 천당과 지옥을 만들었습니다. 저를 선택한 개발자들은 주7일 근무에 야근까지 지옥을 맛보아야 했습니다. 다른 개발자들은 야근을 하지만 주5일의 천당속 개발입니다.

무척이나 화가 나는 순간입니다. PM으로 할 수 있는 일의 한계에 화가 났고 팀을 이렇게 양분시킨 저에게 화가 났고 프로젝트와 관련한 의사결정을 독단적으로 한 수행회사에 화가 났습니다. 그러나 어쩔 수 없습니다. 저는 외주PM입니다. 아니 정확히 한 일만 놓고 보면 저는 테스터였고 리포터였습니다.

일을 마친지 나흘. 다시금 복기를 해봅니다.

“프로젝트의 끝을 위해 주7일근무를 요청한 것이 잘못이었을까?”
“PM의 말을 따르지 않는 사람을 교체해달라고 요청한 것이 잘못일까?”
“프로젝트의 끝을 위해 주7일을 감내한 개발자들의 선택이 잘못일까?”
“프로젝트 초반 개발자를 믿고 투입인력을 대폭 늘려달라고 하지 않는 것이 잘못일까?”

어찌되었든 하나 배웠습니다.

시간이 흐르면서 개발자들의 생각도 바뀌고 있다.

발주회사와 수행회사 및 개발자사이의 괴리가 아직은 큽니다. 영원히 불가능할지 모르지만 괴리가 많이 줄어들었으면 하는 희망을 가집니다. 저도 ‘열정이라는 이름의 고생’을 하고 싶지 않습니다. 그리고 마지막까지 프로젝트의 끝을 위해 함께 해준 독수리 3남매에게 감사를 드립니다.