소프트웨어 회사에서 프로젝트관리시스템(PMS)은 필요 없다

국내 소프트웨어 회사에서 프로젝트 관리를 심각하게 고려하는 경우는 목마른 사람에게 소금물을 주는 암담한 경우가 거의 대부분이다. 프로젝트 관리(Project Management, PM)를 하려면 프로젝트관리 시스템(Project Management System, PMS)이 필요하다 라고 생각하는 것은 단세포적인 논리이다. 오버 스펙인 도구를 사용하는 부작용이 더 클 수도 있다. 소프트웨어 개발을 잘 하겠다는 것과, 프로젝트관리를 잘 하겠다는 것과, PMS 도구를 사용하겠다는 세가지 목표는 상관관계가 크지 않다.

먼저 국내 소프트웨어 업계 상황을 살펴보면 가장 PMS가 잘 구축되어 있는 회사는 대기업 시스템통합(SI) 회사이다. 잘 되어 있다는 표현은 "효율적으로 사용된다"라는 의미를 내포하고 있기 때문에 옳은 표현이 아니고 거대한 PMS라고 하는 것이 옳다. 거대하다 못해 짓눌리는 느낌이 든다. 필자가 이전에 블로그에 게시한 전세계의 SW 개발 Outsourcing 상황에 대한 기사에서 베트남의 SI 회사들이 인도회사와 함께 글로벌 고객들을 상대로 하는 Outsourcing 시장의 최고의 강자이다. 그런데 국내 소프트웨어 회사들은 그런 베트남 SI 회사에 프로젝트를 발주할 수 있는 역량도 없고 반대로 국내 SI 회사들은 다른 외국의 고객들로부터 프로젝트를 수주할 수도 없는 역량인 것이 소프트웨어 업계의 현실이다. 극히 소수가 시도했다고 해도 다 실패로 끝났다. 철저한 국내용 SI 생태계인 것이다. 

국내에서도 외주 개발이 성공적으로 끝난 경우는 필자의 경험상 거의 없다. 열악한 외주개발 생태계는 개선 없이 몇십년이 그대로 유지되고 있는 것이다. 필자가 글로벌이라고 표현할 때는 중국과 동남아시아는 제외한다. 이런 후진국형 시장은 특수한 관계와 특수한 계약에 의해 고객을 인위적으로 만들 수는 있지만 글로벌 시장에서의 성공과는 전혀 상관이 없다. 예를 들어 국내회사의 외국 지사에 판매한 것을 법적으로는 글로벌 매출로 주장하여 정부의 지원금도 받아가지만 필자는 인정하지 않는다.

물론 외주개발 생태계만 열악한 것이 아니다. 회사내의 개발도 다를 리가 없다. 다만 프로젝트가 계약관계에 의해 수행되지 않기 때문에 소송이 걸리지도 않고 잘 나타나지 않기 때문이다. 다행인 것은 아무리 역량이 떨어진다고 해도 어차피 똑같은 국내회사들끼리의 경쟁이다. 외국 경쟁 제품은 배타적인 국내 정책과 국내 고객의 과다한 Customization 요구에 포기하는 경우가 대부분이다. 외국에는 팔 수도 없고 외국제품도 들어오기 어려운 동네잔치인 것이다. 수십년을 정부의 막대한 금전적인 지원 하에 소프트웨어 업계가 그렇게라도 생존할 수 있었다는 것은 다행이다. 글로벌 사용자가 국내 사용자보다 더 많은 국내 소프트웨어 제품은 필자가 오래 동안 컨설팅을 수행했던 소프트웨어 회사만이 유일한 경우인 것이 20년간 관찰한 결과이다.

다시 프로젝트 이슈로 돌아와서 프로젝트관리(PM)는 건설시공과 같이 하드웨어를 만드는 산업에서는 매우 중요하다. 그래서 프로젝트관리시스템(PMS)도 성능 좋은 고가의 제품을 사용한다. 하지만 건설에서도 지식산업인 건물 설계는 PMS와는 아무 관계가 없다. 노동산업인 시공에는 PMS가 필수적이다. 소프트웨어를 지식산업으로 개발한다면 PMS는 거의 필요가 없고 노동산업과 같은 상황이라면 PMS가 중요할 수 있다. 

필자가 실리콘밸리에서 근무했던 회사들은 모두 세계 1, 2위의 글로벌 회사들이었다. 그런데 프로젝트관리가 중요했다는 생각을 해 본 적도 없고 프로젝트 관리자가 누구였고 무슨 일을 했는지 조차도 기억이 나지 않는다. 나의 인사평가에 관련한 적도 없고 뭔가 진척 사항 정도만 가끔 알려주었다는 정도 희미하게 기억난다. Bookkeeping 정도의 역할로만 기억할 뿐이다. 엑셀 정도의 도구만 사용했다. 마이크로소프트의 엑셀 개발팀도 자체 엑셀로 프로젝트관리를 했었다. 즉 프로젝트관리에는 회계의 예를 들면 회사의 전략을 결정하는 회계사(Accountant)의 역할부터 기록만 담당하는 부기담당자(Bookkeeper)의 역할까지 다양한 역할이 있다.

PMS를 도입해서 개발을 잘해보겠다는 회사가 있으면 걱정부터 든다. 얼마나 열악한 환경이면 PMS를 도입해서 관리를 해야 한다는 생각이 들까?  회사가 노동산업 형태로 만들어져 버렸다면 그 때의 유일한 단기 해결책은 노동인력관리이며 그 때는 PMS가 필요할지 모른다.. 하지만 건축 설계사나 모차르트를 관리한다고 좋은 디자인이나 음악이 나올 수는 없다. 관리는 전형적인 노동산업에 필수적인 요소일 뿐이다. 지식산업에서는 관리가 아닌 Bookkeeping하는 도우미 정도의 역할로 충분하다. 노동산업적인 관리를 시작하면 의욕이 떨어지고 직원들은 부품처럼 움직이게 된다. 건설 현장의 인부를 생각하면 된다.

이런 부작용에도 불구하고 소프트웨어 개발에 관리가 필요하다는 것은 그 만큼 열악한 환경에 처했다는 얘기이고 목말라 쓰러져가는 사람에게 소금물 주기와 같다. 물론 소금물을 준다는 사실조차 모르는 상황에서 희망적인 결과를 바라고 시작하겠지만 결과는 명백하다. 열정도 사라져 생산성도 낮은 무기력한 삶이 지속될 뿐이다. 한번 열정을 잃어 버리면 희망이 아주 작게 변한다. 노예들의 희망은 해방되는 것이 아니라 금으로 만든 쇠줄을 가지는 것이라는 속담도 있다. 훌륭한 제품을 만드는 것이 목적이 아니라 안정된 급여만 보장 된다면 편히 살아가는 것으로 목적이 변하게 된다. 그러면 더 관리가 필요하게 된다. 소금물 마시기와 같은 악순환이 계속된다.

눈 앞의 문제를 해결하기 위해 단기적인 관리가 필요함과 동시에 그런 상황이 된 근본적인 원인을 파악하고 해결책을 마련해야 한다. 국내 소프트웨어 업계는 이런 면에서 지금까지 수십 년을 허송세월 했다. 또 다른 부수적인 관리의 목적은 투명성의 문제와도 직결되어 있다. Black Box 속에서 직원들이 무슨 일을 하는지도 모르는 상황에서 회사에 대한 충성도나 프로페셔널로서의 책임감이나 자존심도 없다면 관리는 매우 중요해 진다. 이는 근본적인 프로젝트관리의 목적과는 벗어난 다른 문제이며 이미 희망적인 환경은 아니다. 책임감과 역량이 충분하다면 관리는 알림에 대한 수동적인 Bookkeeping 정도의 관리만으로도 충분하다. 하지만 반대의 경우는 능동적으로 감시와 참견을 해야 하는 세밀하고 많은 관리가 필요하다.

작은 관리가 되었던 큰 관리가 되었던 관리를 하려면 관리할 정확한 항목이 필요하다. 건설 시공현장에서 관리가 가능한 이유는 건물 설계도가 있기 때문이다. 설계도가 없이는 공사 시작도 할 수 없고 인부관리가 불가능하다. 관리의 필수적인 조건은 규모가 크든 작든 관리할 항목이 있어야 한다는 것이다. 관리할 항목도 없는 상태에서 요새는 또 수시로 변하는 상황에 적합한 애자일이라는 방법론을 들고 나올 수 있는데 이는 말장난에 불과하다. 관리와 애자일은 원칙적으로 상충되는 용어이다.

애자일을 관리와 관련하여 간략하게 소개해 보자. 폭포수모델을 본 적도 없는 사람들이 폭포수 모델의 단점 때문에 애자일을 시도해 보겠다는 코미디 같은 일이 벌어지기도 한다. 폭포수모델과 애자일의 논쟁은 소프트웨어가 생겨나면서부터 격렬하게 벌어진 60년의 지속적인 논쟁거리였고 요새 유행하는 Scrum도 적어도 1987년의 논문 혹은 그전에 이미 소개된 오래된 개념이다. 애자일 방법론 중에서 이전에 한때 유행했지만 사라진 것이 Pair Programming으로 유명한 XP 방법론이고 지금 유행하는 것은 Scrum 방법론이다. 애자일이나 DevOps같은 유행이 나라를 구할 수 있다면 다 하겠지만 지금까지 유행이 나라를 구했다는 소리는 들어 본 적이 없다. 반대로 유행이 나라를 망치는 경우는 많다. 

Scrum은 그냥 소수의 팀이 필요에 따라 수행하는 하나의 방법일 뿐이다. 이미 애자일 창시자들도 애자일은 죽었다고 선언한 상황에서 지금 현재 이 순간에 국내에서 유행하고 있다고 하는 것이 정확한 표현이다. 미래에 어떻게 될지는 알 수 없다. 스크럼은 소수의 팀(편의상 최대로 잡아서 10명 이하의 규모라고 해 두자)이 고객의 요구사항이 불확실할 경우에 고려해 볼만한 방법에 불과하다. 비법으로 착각하여 너무 큰 의미를 부여하지 않았으면 좋겠다. 이미 수십년 되는 개념이다. 건물이나 자동차를 애자일로 개발할 수는 없다. 정확한 분석과 설계가 성공의 핵심인 것은 극소규모 개발이 아닌 이상 소프트웨어의 공통점이다. 작은 규모의 개발이라고 해도 최소한도의 분석과 설계가 없이는 어떤 방법론도 사용할 수는 없다.

결국 관리를 하려면 요구사항이든, 스펙이든, 일정이든, 인력이든, 리스크가 되었던 뭔가 시작점이 있어야 한다. 구름 잡는 비전이나 열정만으로 시작해야 할 일이 없다. 인력은 있는데 당장 할 일이 없으니 알아서 사전공부를 하거나 다른 일을 한다. 그래도 뭔가 하고는 있으니 바쁘고 정신 없다고 한다. 다 계획이 없어서 벌어지는 현상이다. 설상가상으로 할 일도 없고 책임감마저도 없다면 어떤 현상이 벌어질지는 명백하다. 

계획 없는 관리는 불가능하다. 폭포수나 애자일이나 정도의 차이는 있지만 마찬가지이다. 필자가 보아온 국내의 현실은 폭포수는 물론이고 스크럼을 수행하기에도 충분하지 않은 분석과 설계를 하는 것이 현실의 상황이다. 템플릿이나 프로세스 흉내는 내지만 질적인 문제에서는 항상 부족하다. 세계적인 프로젝트 관리시스템인 Primavera를 가져다 준 들 관리할 항목이 없이 관리할 수 있는 방법은 없다. 건물 설계도가 없으면 시공을 할 수 없는 것과 동일하다. 시간과 돈만 낭비할 뿐이다.

세계적인 유행 따라 인공지능을 하든 블록체인을 하든 무엇을 해도 잘하고 못하는 것은 관리의 문제는 아니다. 관리는 역량에 따라 적절한 수준으로 맞추면 된다. 실리콘밸리의 글로벌 회사와 같이 되도록이면 관리를 적게 해도 되는 상황이 가장 바람직한 상황이다. 프로젝트 관리를 잘해서 훌륭한 소프트웨어 회사가 되었다는 얘기는 들어본 적이 없다. 이미 잘 안 되는 회사에서 현상유지 하는 정도의 목표가 현실적이다. 진정한 이해도 못하는 폭포수니 애자일이니 하는 용어에 현혹되지 말기 바란다. 기본적으로 분석과 설계를 적절히 한 상태에서는 방법론도 중요하지 않고 관리도 중요하지 않다. 프로젝트관리니 방법론이니 하는 얘기는 이미 회사가 안되기 때문에 생겨난다. 그리고 점점 더 깊은 구렁 속으로 빠지기 쉽다.

소프트웨어 개발이 잘 안 되는 근본 원인은 적절한 분석과 설계의 부족이다. 그런 상태에서는 PMS와 같은 도구는 의미도 없고 백약이 무효다. 개발자의 코딩 역량은 그 후의 문제이다. 천재 개발자들이 겨우 한번 만들었다고 해도 아키텍처가 망가진 상태에서는 미래의 유지보수가 모두를 괴롭히기 시작한다. 전형적인 국내 SI나 제품의 현상이다. 진정한 이해 없이 무조건 PMS를 도입하기 보다는 먼저 무엇이 중요한 가를 진정으로 깨닫는 것이 중요하며 회사에서는 리더들의 전적인 책임이기도 하다.