Posted by 중년하플링 :


Posted by 중년하플링 :
프로젝트 매니저와 아키텍트를 혼동하는 사람들

류한석(피플웨어 운영자) 2006/08/22
소프트웨어 프로젝트가 실패하는 이유에는 수많은 원인들이 있다. 가장 고전적인 원인을 꼽는다면 ‘잘못 결정된 프로젝트 기간과 비용’일 것이다. 또는 요구사항을 제대로 파악하지 않았거나 빈번하게 수정했기 때문일 수도 있고, 주요 이해관계자의 참여 또는 경영층의 지원이 부족했거나, 제대로 된 프로젝트 계획을 작성하지 않았기 때문일 수도 있다. 그것도 아니면 프로젝트 또는 조직 내부의 정치적인 문제 때문일 수도 있다.

어떤 최악의 프로젝트에서는, 그 모든 요인들이 결합해서 나쁜 시너지를 만들어내고 그 결과로 참담한 상황을 맞이하기도 한다. 프로젝트에 나쁜 영향을 미치는 모든 요인들에 대해 살펴보려면 엄청난 지면이 필요할 것이다.

이번 컬럼에서는 가장 중요한 실패 원인 중 하나이지만 잘 거론되지 않는 사실을 하나 소개해 보겠다. 그것은 바로 프로젝트 매니저, 아키텍트의 역할을 혼동한 나머지, 잘못한 책임을 부여하는 것이다. 즉 관리 책임과 기술 책임을 구분하지 않는 문제인데, 가장 중요한 인적자원에 오류가 있는 것이어서 프로젝트의 근본적인 실패 원인으로 작용하게 된다.

현재의 상황을 살펴보자. 먼저, 지금 당장 아무 구인구직 사이트든 가서 확인해보라. 다음과 같은 글을 쉽게 만날 수 있을 것이다.

[PM 모집: 자격 요건은 다음과 같음]
C/C++, Java, DBMS를 능란하게 구사 가능해야 함
UML 등을 활용한 설계 능력이 뛰어나야 함
고객과의 원활한 의사소통 및 협상이 가능해야 함
교육 및 프레젠테이션 스킬이 뛰어나야 함
소프트웨어 프로젝트의 관리 능력이 능숙해야 함
기술사, PMP, CISA 등의 자격증 우대


위와 같은 사람을 구하려고 한다면 장담컨대 거의 확실하게 구할 수 없을 것이다. 우리 업계에 그런 스펙을 갖춘 사람도 드물지만, 그런 사람이 있다고 하더라도 구인 업체에서 어떻게 평가하고 판단할 수 있겠는가? 또한 충분한 대우는 가능할까?

멀티 플레이어에 대한 무지 또는 욕심
프로그래밍 능력의 경우 면접 시 테스트 프로그래밍을 통해 어느 정도 평가를 할 수도 있겠지만, 설계 능력과 관리 능력의 경우 테스트 자체가 거의 불가능하다.

위와 같은 사람을 구하는 것은 그저 업체의 욕심일 뿐이다. 프로그래밍 능력, 설계 능력, 관리 능력을 모두 갖춘 그런 자원이 거의 없는 것이 국내 업계의 현실이다. 개인 탓이 아니라 시대가 그렇다.

기술 쪽을 살펴보면, 지금은 코볼로 개발을 하던 1980년대가 아니다. 그때에는 코볼 하나만 알면 모든 것이 해결되었지만 지금은 알아야 할 것이 너무 많다. 관리 쪽도 만만치 않다. 비즈니스 환경을 전반적으로 이해해야 하고, 정치력도 필요하고, 문서 작성, 프레젠테이션을 잘 해야 하는 등 고도의 스킬이 필요해졌다. 그리고 관리와 기술은 서로 다른 분야이다.

하지만 주요 인적자원의 실제 업무를 이해하지 못한 채로, 멀티 플레이어(또는 업계 용어로 올라운드 플레이어)를 뽑으려고 노력하는 업체들이 참으로 많다. 그것은 무지 또는 욕심. 둘 중의 하나이다.

잘못된 역할 배정의 문제
위에 예를 든 구인 공고를 보면 알겠지만 그 제목은 어쨌거나 ‘PM 모집’이다. 즉 프로젝트 매니저를 뽑는 것이다. 그런데 세부 사항을 보면 도통 프로그래머를 뽑는 것인지, 설계자를 뽑는 것인지, 관리자를 뽑는 것인지 헷갈린다.

물론 척박한 국내의 IT 현실에 비추어 볼 때, 프로젝트에서 수많은 역할을 동시에 수행할 수 있는 그런 멀티 플레이어를 선호하는 상황을 인정하지 못하는 바는 아니다. 하지만 바로 그런 잘못된 판단 또는 욕심이 바로 프로젝트를 실패하게 만든다.

일단 프로그래머의 경우 모든 사람들이 익히 잘 아는 역할이므로 논외로 치고, 소프트웨어 아키텍트와 프로젝트 매니저의 역할을 생각해보자.

소프트웨어 아키텍트는 설계자이다. 개발을 위한 ‘소프트웨어 요구사항’을 파악하고, 큰 그림의 소프트웨어 아키텍처를 디자인하고, 개개의 프로그래머들이 작업해야 할 서브 시스템과 컴포넌트를 정의하는 사람이다. 또한 테스트 엔지니어들과 함께 테스트 요구사항을 수립하기도 하면서, 소프트웨어 개발의 전 과정에서 중요한 기술 책임자의 역할을 수행하는 사람이다.

프로젝트 매니저는 관리자이다. 프로젝트의 진행을 위한 ‘프로젝트 요구사항’을 파악하고, 프로젝트 계획을 수립하고, 개개의 팀원들이 작업해야 할 프로젝트 활동을 시간과 비용 개념을 갖고서 정의하는 사람이다. 또한 품질 담당자와 함께 품질 보증을 위한 활동을 수립하기도 하면서, 프로젝트의 전 과정에서 관리 책임자의 역할을 수행하는 사람이다.

소프트웨어 아키텍트는 소프트웨어 개발을 위한 높은 수준의 디자인을 계획하고 책임지는 사람이고, 프로젝트 매니저는 프로젝트 관리를 위한 여러 활동들을 계획하고 책임지는 사람이다. 기술 활동과 관리 활동은 분명히 다른 것이다.

하지만 많은 업체들이 그것을 혼동함으로써 재앙을 불러온다. 마치 프로젝트 매니저가 프로그래밍도 잘 알아야 하고, 설계도 잘 해야 하고, 관리도 잘 해야 한다고 생각한다. 물론 작은 규모의 프로젝트에서는 단 한 명이 모든 역할을 다 수행하는 경우도 있겠지만, 그것은 아주 예외적인 것이다.

기술 책임자와 관리 책임자는 구분되어야 한다
대부분의 소프트웨어 프로젝트에서 프로젝트 매니저의 역할과 아키텍트의 역할은 명확히 구분될 필요가 있다. 물론 두 사람이 상호 신뢰 하에 관리 책임자, 기술 책임자로서 긴밀하게 협조해야 하는 것은 자명하다.

그러므로 이 컬럼의 진지한 충고는, 프로젝트 매니저와 아키텍트의 역할을 제대로 구분하고 적합한 사람을 각각의 역할에 배정하라는 것이다. 그런 사람이 없어서 못 쓴다고 항변하는 업체들도 있을 것이다. 글쎄, 세상에 쉬운 일이 어디 있겠는가? 그것은 시간을 갖고 업체 스스로 양성을 하든, 경쟁 업체에서 스카우트를 하든, 해외에서 데려오든 해당 업체가 판단할 일이다.

프로젝트의 실패. 그것은 바로 소프트웨어와 프로젝트의 본질을 무시하고 인적자원의 중요성을 무시한 행동에 따른 필연적인 결과가 아닐까 필자는 생각한다. 그래서 필자는 다음의 주장을 명백히 강조하고 싶다.

“기술 책임자와 관리 책임자는 구분되어야 한다” 그것은 CEO와 CTO가 구분되어야 하는 것과 같은 개념이다. 만일 무지하여 그러한 구분을 제대로 해내지 못하거나, 또는 비용 절감의 욕심에 사로잡혀 고의적으로 그것을 행하지 않는다면, 프로젝트는 필히 재앙으로 보답할 것이다. 소프트웨어 프로젝트의 역사는 그것을 증명하고 있다. @
Posted by 중년하플링 :

아주 좋은 글입니다. 그렇지 않아도 회사에서 제가 요즘하고 있는일이 '프로젝트관리' 라기 보다는 갑입장에서 간섭 --; 하는 작업이라서 이 밤을 세는 부분에 대해서 좀 관심이 많습니다. 원래 야근을 무지하게 싫어하는데.. 이놈의 개발현장이랄까.. 모두들 저녁은 그냥 밥먹고 일하는 분위기가 되다보니 혼자 일찍 가기도 눈치보이고... 조금 뭉게다가 집에가서 밥먹으려니 요즘 속을 버리고 있습니다.

그래도.. 가능하면 새로운 요구사항 들어왔을때 M/M을 따져서 추가적인 투입시간을 산정한뒤 판단하려고 노력하고 있고, 프로젝트 관리도 WBS에 기반을 두고 하려고 합니다만.. 이것도 혼자서 하기는 힘들더군요... 역시 한계는아래 글에 쓰여있는 개발경력이 일천하기 때문...--; 이기도 하고..개발업체 담당과장 내지는 개발자들도 이런 마인드 자체가 없는것 같아요. 일을 하기 전에 공수를 정확하게 산정해서 계획에 반영한다든가 하는 그런 부분은 전혀 없이 그냥 요구나오면 대충버팅기던가 받아서 디자인하고 바로 그냥 코딩 하더라구요.

쉽게 해결될 문제는 분명히 아니고.. 뭐 개인적으로는 이쪽 바닥은 얼씬도 하지 말아야겠다는 다짐만 했습니다. 저 혼자서 우리나라 IT업계를 책임질것도 아니고...

개발자는 왜 밤을 세는가?

sizers | 2006-08-08 19:54
내가 3~4년 전에 조그만 프로젝트에서 일을 할 때의 일이다.
우연히 개발자 중에 네덜란드인 1명, 러시아인 1명이랑 같이 일을 하게 되었었다.
네덜란드인은 BMW사에서 근무하다가 자기 상사가 한국에서 사업을 시작하는
바람에 따라온 케이스가 되었다.

당시는 나도 경력이 많지 않았고 그래서 개발자들은 당연히 밤을 세야 하는 줄
알았다. 그런데 이 네덜란드인.. 근무시간 중엔 정말로 열심히 일을 했다.
근데 6시 땡치면 짐싸서 퇴근했다. 늘 그렇듯이 당시 우리는 일정에 상당히 쫒기는
상황이었고 그래서 전전긍긍했는데 그 개발자의 그러한 행동은 나로 하여금
상당히 쇼크받게 만들었다.

당연히 우리는 그 사람의 메니저에게 이야기 했고 그 사람으로 하여금 일정을 채우려면
오버타임으로 일을 하도록 종용을 했다.

네덜란드인 개발자는 한참동안 메니저와 상의하더니 페이부분을 재 조정한 다음에
2시간 연장근무를 하는 것으로 쇼부를 봤나 보다.

네덜란드인 개발자는 그 이후 부터는8시 땡치면 퇴근을 했다. 우리는 계속 밤을
세가면서 일을 했는데 말이다.

네덜란드인 개발자는 절대로 일을 그냥 맡는 법이 없었다. 일을 맡기면 그 일의
기능을 먼저 분석을 한 다음에 MM을 계산하여 자기들이 시간 내에 할 수 있는 범위
이상의 일은 맡지 않았다. 절데로 말이다.

그 이후로 나는 배운게 많다.

왜 한국에서 하는 프로젝트는 항상 일정에 쫒기는가?
왜 한국의 개발자들은 박봉을 받는가?
왜 한국의 개발자들은 밤을 세는가?

자 이게 어떻게 된 영문인지 시뮬레이션을 해보자..

남성부라는 정부기관이 있다고 치자
남성부는 예산을 소진할 사업을 짜고 있다. 예산을 다 쓰지 못하면 다음 회기에서의
예산이 깎이기 때문에 그들은 민원관리프로젝트를 기획하고 기존에 개판으로
만들어진 민원관리프로그램을 다시 만들기로 하였다(왜 개판으로 만들어졌는지는
이 글을 읽다보면 자연스레 이해가 될 것이다)

예산으로는 1년동안 100억을 들이는 것으로 기획했다. 이 눈먼 정부돈을
따먹기 위해서 굵직굵직한 SI업체들이 입찰에 참가했다. 삼선SBS가 인맥과 담당자
로비를 통해서 이 프로젝트를 낙찰 받았다.

삼선SBS는 당신들이 마땅히 개발을 해야 함에도 불구하고 그렇게 하지 않았다.
그들은 그 프로젝트를 할 만한 인력을 충원해야 하지만 그 인력을 뽑자니 프로젝트가
끝나고도 그 인력을 보존하려면 비용이 발생하기 때문이다. 더군다나 다른 SI업체에
떠넘겨도 충분히 개발이 가능하다고 생각하기 때문이다.

삼선SBS는 중급SI업체에 50억에 턴키로 위의 프로젝트를 의뢰했다.
결국 삼선SBS는 손하나 까딱 않하고 관리자 1~2명 감시단으로 파견시킨 후에
50억을 꿀꺽 삼켰다.

중급SI업체 또한 사정이 마찬가지다. 지들도 네임벨류가 조금은 있다보니 여기저기
프로젝트 의뢰는 많이 들어오지만 그들이 그만한 인력도 있지 않을 뿐더러
소규모 SI업체에 맡겨도 알아서 잘 하리란걸 알고 있다.

중급SI업체는 소규모SI업체에게 20억에 턴키로 맡기고 PM내지는 PL몇명 파견하고
30억을 꿀꺽 삼켰다.

소규모 SI업체라고 해서 훌륭한 개발자가 많이 있으리라는 보장은 없다. 훌륭한
개발자가 소규모 SI업체에 있을리가 만무하지 않은가.. 그래서 소규모 SI업체는
프리랜서를 고용하기로 했다. 필요인력이 고급 10명 중급 30명이라고 치면
프리랜서 개발자들의 이력서를 조작하여 중급은 고급으로, 초급은 중급으로 둔갑시켜
프로젝트에 투입시킨다. 솔직히 소규모 SI업체가 받는 돈으로는 돈을 많이 주고
좋은 개발자를 사올 수도 없는 형편이다. 제대로 된 개발자를 쓰기엔 그들이 받는
20억으론 오히려 적자가 되기 때문이다.

소규모 SI업체는 그나마 프로젝트를 제대로 수행해야 그 돈이라도 받을 수 있기
때문에 열심히 개발을 시킨다.

마땅히 고급개발자가 설계를 해야 함에도 불구하고 중급이 설계를 하다 보니 설계가
제대로 될 리가 없다. 마땅히 중급이 개발해야 함에도 불구하고 초급이 하다보니
개발이 제대로 될 리가 없다.

설계의 부실을 매꾸기 위해서 설계자와 개발자들이 모두 개발에 투입된다.
그들이 모두 밤을 세워서 일요일도 없이 일을 한 덕택에 개발진척도가 100%가
되었다. 그러나 그들이 제대로 설계를 하지 않았기 때문에 설계서가 있을 리 없다
설계서를 적당히 꾸미기 위해서 개발이 끝난 후에 다시 개발자와 설계자가
모두 달라들었다.

왜 삼풍백화점이 무너졌는가? 왜 성수대교가 무너졌는가?
겉모습이야 그럴듯하게 지어졌다고는 하나 설계가 부실했고 부실시공을 했기 때문이다.

한국의 대부분의 프로젝트에서 이런 한심한현상이 벌어지고 있다.
문제는 이들이 이런 짓을 해도 뭐가 제대로 된건지 조차 모르는 사람들이 관리를 하고
있다보니 그냥 의례히 그런것인 줄 안다는 거다.

왜 고급기술자는 IT바닥을 떠나는가?
위에 언급했듯이 중급, 초급으로 얼추 때워먹다 보니 고급기술자는 갈데가 없다.
마땅히 그만큼의 비용을 지불하고 고급기술자를 쓰기보다는 업체가쌈마이들 데려와서
돈 조금 들이고 날로먹으려고 생각하기 때문이다. 또한 고급기술자들은 이런 밤새는
생활에 환멸을 느끼고 남은 여생이라도 좀 편하게 살려고 바닥을 뜨는 것이다.

고급기술자는 없고 고만고만한 사람들이 말 좀 하는 사람은 관리나 영업,
기획하고 그나마 그런 스킬도 없으면 설계하고 개발하고 그러다 보니 이렇게 된 것이다.

결국 이렇게 만들어진 프로그램이 제대로 동작할리 없다. 당장 일선에서는 불만이
폭주한다. 그나마 SM계약업체를 통해서 부족한 부분을 매꾸려고 한다.
대충 설계하고 개발했기 때문에 설계서가 제대로 됬을리 없다. 설계서를 보고 분석이
가능한 것이 아니라 그나마 좀 알던것도 설계서를 보면 머리가 더 헷갈린다.
SM업체는 추가 요구사항에 대해서 기존 설계안에서 확장하면서 형상관리를 해야 함에도
불구하고 독립적인 새 프로그램을 짜서 매꾼다. 이렇게 계속 확장하다 보니 프로그램은
서로 연동이 되지 않는다. 결국은 다음회기에서 이 프로그램을 새로 만들기로 하였다.

다음회기에서 남성부는 이 고객관리 프로그램을 아예 새로 만들기 위해서 또다시
100억을 할당받았다. 예산을 써야 예산이 깎이지 않기 때문이다.삼선SBS는 또
인맥과 로비를 하여 이 프로젝트를 낙찰받았다.

매년 국민의 혈세 80억은 아무런 이유도 없이 누군가의 호주머니로 쏙쏙 들어가는 것이다.
개발자들은 아무런 이유도 영문도 모른체 오늘도 밤을 세는 것이 나의 천직이구나 하면서
밤을 세고 있다.

갑-남성부,
을-삼선SBS,
병-중급SI업체,
정-소규모SI업체,
무-프리랜서

이런 먹고 먹히는 먹이사슬구조는 오늘도 탄탄하게 지속되고 있다.

항상 여기까지만 이야기 하면 도데체 해결책이 뭔데 하고 이야기 하는 사람이 많다. ㅋㅋ

내가 생각하는 해결책은..

1. 프로젝트 관리, 설계,품질관리가능인력이 턱없이 부족하다. 이런 과정은
전산과에서도 배울 수가 없다. 심지어 기업에서 이런 인력이 필요하다는 것 조차 모른다.
멍충이들.. 그러다 보니 관련 스킬도없고 대충 말로 때우는사람들이 무늬로만 저런
직책을 맡고 있다.이 분야의 체계적으로 양성해야 한다. SIMPLE하게 시작해서 확장
가능한업계 표준적인 개발방법론도 나와주어야 한다. IT업계의 과장급 이상이면서
개발방법론이 뭔지 모른다면.. 제발 좀 이 바닥을 떠주길 빈다.

2. 고급개발자들을 갑 업체에서 흡수해야 한다. 프로그램을 외주를 주더라도 예네들이
잘 하고 있는지 못하고 있는지를 알 수 있는 인력이 도데체 없다. 프로젝트 인력이
들어오면 예네들이 얼마만큼의 스킬이 있는지 어떤 주특기가 있는지 알리가 없다.
기업에서 전산분야를
육성하기 위해서라도 이들을 키울 필요가 있다. 문제는 기업에선 성실하고 묵묵한 이런
전문가 보다는 말발 좀 있는 양아치들을 더 선호한다는 것이다. 자기네들이 무얼 해야
되는지도 잘 모르고 그냥 다른 기업에서 BPM한다면 아.. 경쟁업체에서도 하는데 우리도
해야 되는구나.. 그거 얼마든데? 하다가 담당자가 인맥이 닿는 모 기업으로 부터 로비좀
받고 그 업체의 솔루션을 밀어준다.

3. 일을 맡는 을 업체에서 자기네 인력을 사용하는지 아닌지를 철저하게 감시하여야 한다.
또한 프로젝트를 수행한 을 업체에서 SM으로도 연장적으로 계약하는 것이 유리하다.
대게 프로그램이 한 번 개발되면 지속적인 관리가 필요함에도 불구하고 프리랜서들은
일단 계약이 끝나면 그 이후의 아무런 책임이 없기 때문에 전혀 새로운 사람들이
이 프로그램을 이어받아서 개발하게 된다. 이들은 프로젝트진행과정시의 이슈나 사상을
전혀 모르기 때문에 지 나름데로 해석해서 프로그램을 뜯어고치게 된다. 어느정도
하다 하다 않되면 프로그램을 다시 만든다. 이 거지같은 윤회의 과정을 또 반복하는 것이다.

4. 여건이 않되더라도 쌈마이들 열심히 밤세우고 굴리면 어떻게 되겠지 하는 인식
자체를 버려야 한다.

하고 싶은 얘긴 많은데 그만 쓸란다. 생각하면 생각할 수록 답답하다.
내가 이바닥에서 8년이 다 되어가도록 살아남았다는게 대견하다. ㅋㅋ


* 개발자들이 오버타임수당을 받는 그 날을 위하여..
Posted by 중년하플링 :