저는 대학교에서 전공은 제어계측공학이었지만 실제로는 경제학이나 사회학에 더 관심이 많았습니다.(^^) 특히 소프트웨어공학이나 경영과는 거리가 멀어도 한참 먼 경력을 가지고 있었습니다. 더구나 학교를 마친 후 군대를 제대하자마자 바로 구로동에 있는 생산공장에서 선반기술자로 취직을 하였고 공장을 그만둔 후에는 노동단체나 사회단체에서 쭉 일을 하였기때문에 일반기업에서의 경험이 전혀 없는 상황이었습니다. 이런 점이 회사 경영자로써의 실패를 하게된 배경일 수도 있습니다. 특히 정보화사회에서 어떻게 하면 사회에 기여할 수 있을까라는 고민에서 출발하였던 바른정보는 기업이라고 할 수 있는 요소가 거의 없었습니다. 그래서 넥스트웨어라는 회사를 같이 창업을 하고 새출발을 한다는 것은 모험이었습니다. (지금 생각하면 모험이라고 할 수 있습니다. )
넥스트웨어를 할 때 일반적인 개발방법은 별다른 것이 없었습니다. 90년대 초반부터 기술자 몇명이서 개발을 진행하였던 수공업적인 집단에게 무슨 방법론이니 프로젝트관리니 하는 개념들이 들어갈 자리가 없었습니다. 중요한 것은 개발자 개인의 능력뿐이었습니다. 10명이 넘는 개발자가 팀을 이루어서 개발을 한다는 것은 상상하기 힘들었던 시기였습니다. 그러다 인터넷을 시작으로 하여 사회전반적으로 IT열기가 높아지면서 기업고객들의 수요가 급속히 늘어났고 이때 아무런 준비없이 회사규모를 키울 수 밖에 없었습니다. 제품개발을 통해 수익모델을 창출하기보다는 솔류션이라는 이름으로 고객이 요구하는 최소한 기능을 Framework(?)형태로 준비해놓고 고객의 요구사항을 분석하여 제품을 개발납품하는 방식이었기때문입니다. 이런 사업모델은 SI사업이라고 하죠.
저는 97년부터 98년중반까지 핵심기술자의 대부분이 퇴사한 상황에서 98년 신영증권 Java Trading System을 개발납품하는 프로젝트부터 프로젝트매니저역할을 할 수 밖에 없었습니다. 제안서를 작성하고 영업을 하고 PM으로 프로젝트에 투입되어 요구사항을 정리하고 일정을 관리하고 검수를 받고 다시 비용청구를 하는 그런 일을 2002년까지 하였습니다.
프로젝트는 “제한된 시간”과 “제한된 비용”과 “제한된 자원”을 가지고 고객이 요구하는 제품을 납품하는 것이라고 생각합니다. 그렇기 때문에 당연히 모든 프로젝트는 위험요소를 가질 수 밖에 없고 그것을 효율적으로 관리하는 것이 SI를 주된 수익구조로 하는 상황에서는 이익을 내는데 핵심적인 요소였습니다. 그런데 1998년부터 2001년까지는 공급보다는 수요가 많은 상황이었기때문에 이러한 위험요소가 관리가 철저한지 아닌지가 눈에 드러나지 않았습니다. 인터넷거품에 따른 추가비용이 이미 프로젝트 총비용에 반영되어 있기때문에 프로젝트관리가 잘되든 못되든 어느정도의 이익을 만들 수있었기때문입니다. 그런데 문제는 2002년부터 인터넷거품이 걷히고 비용이 정상화하거나 낮아지는 과정에서 잠재되어 있던 위험요소를 해결할 수 있는 준비를 하지 못했습니다.
영업단계에서는 매출중심으로 사고를 하였기때문에 “적정한 이익”에 대한 고려없이 저가라도 수주하는 것이 좋다는 생각을 하였고 – 돈을 돌리는 것이라도 좋다는 식이죠 – 업무협의단계에서는 추가비용발생에 대한 고려없이 고객의 요구를 최대한 수용하여 요건정의를 하였습니다. 프로젝트팀을 구성할 때도 관리에 대한 고려없이 개발자중심으로 팀을 구성하여 결국 프로젝트관리가 부실화되는 결과를 초래하였습니다.
제가 넥스트웨어를 하면서 프로젝트를 수행하면서 범한 가장 큰 오류는 두가지입니다.
첫째는 사내R&D프로젝트를 수행하면서 사전준비과정 및 프로젝트계획에서 부실하였습니다. R&D프로젝트는 사외프로젝트와는 달리 회사의 재무적인 능력과 밀접하게 연관되기때문에 재무적인 계획을 반드시 동반하여야 합니다. R&D의 목표에 따른 예상 프로젝트계획을 수립하고 “투입되는 인적자원”과 “필요로 하는 기간”을 산정하여 얼마만큼의 자금을 투입하여야 하는지 아니면 얼마만큼 가능한지를 판단하여야 했습니다. 그렇지만 벤처자금을 유치한 이후 자금에 대한 막연한 자신감으로 R&D프로젝트를 수행하였고 그때문에 회사가 부담할 수 있는 범위를 벗어난 과도한 R&D를 하게되었습니다. SI프로젝트에서 수입을 거의 없고 그 상태에서 막연히 놀고 있는 개발자들을 이용하여 R&D를 추진할 수 있다는 막연한 자신감이 결국 실패로 귀결되었습니다. 예를 들어 어떤 프로젝트는 1년이 투입된 경우도 있었고 어떤 경우는 2년이상을 지속하는 경우도 있었습니다. 그리고 최소 몇달이상의 프로젝트를 수행하였지만 매출로 귀결되지 못한 제품도 10개가 넘습니다.
2002년부터 회사에서 진행하였던 R&D프로젝트를 보면
– OFX Engine 개발
– FIX Engine개발
– Web Band(Band Trading System)개발
– Help Desk System Based On Cross Messenger
– Map Generatior for HTS
– FIX Based BOND Trading System
– ISO15022 Post Trading System
– Margin FX Trading System
– Content Management System
– Transaction Middleware For HTS
– Message Middleware For Order Management System
등을 지난 5년동안 진행하였습니다.
여기에 중국계기업과 공동으로 Contents사업을 전개할 목적으로 Forex Trading Site를 개발하느라 1년을 소비하였습니다.이중에서 마지막까지 수익을 발생한 제품은 FIX,Transaction Middleware, Message Middleware,FX trading system정도입니다. 그렇지만 그것도 초기 예측과는 달리 완성하는데 시간이 많이 걸렸습니다..
두번째는 사외SI프로젝트이든 사내R&D프로젝트이든 프로젝트에 적합한 PM를 확보하지 못했거나 육성하지 못했다는 점입니다.
개발자를 프로젝트매니저로 육성하거나 외부에서 PM능력을 확보한 사람을 채용하는 방식을 부분으로는 시도하였지만 결과적으로 대부분
실패하였습니다. 그 결과 사내든 사외든 개발하고자 하는 제품의 품질이 떨어지거나 납품기간이 늘어지면서 계속적인 비용이 발생하는 사태가 발생하였습니다.
정리하면
– 재무계획을 동반하지 못한 프로젝트 진행
– 목표가 없는 프로젝트 진행
– 책임자가 없는 프로젝트 진행
– 제품개발의 경험이 없는 개발자
로 이루어진 팀구성이 이루어졌습니다.
프로젝트를 진행하면서 발생할 수 있는 최악의 사례는 다 발생하였다고 생각하면 그것과 거의 같은 모습입니다.
SI를 주사업모델로 하는 회사가 불황기에 SI를 위해 필요한 인력을 유지하면서 프로젝트 수주건수의 부족을 R&D로 해결하고 이를 통해 새로운 수익모델로 창출한다는 아주 단순한 생각이 현실에서는 완전히 박살났습니다. 그 결과 기업의 실패입니다.
프로젝트관리가 처음에는 경험의 영역에서 이제는 과학의 영역으로 전화되어야 하지 않을까 합니다. 특히 프로젝트관리가 회사의 성패를 좌지우지하는 소프트웨어개발회사에서는…옛날에는 그저 짠밥을 많이 먹고 해당업무에 대해 좀 안다는 사람이 PM을 하는 식인데 그렇게 해서는 곤란하다는 생각을 합니다.
