출처 :< GPG 포럼 >
출처원문 : < http://www.gpgstudy.com/forum/viewtopic.php?t=11752&highlight=%BA%F1%C1%D6%BE%F3+%C7%C1%B7%CE%B1%D7%B7%A1%B8%D3 >
/*
허헛 이번 글도 굉장히 잼있고 와닿는 이야기 입니다. 앞에 이야기도 그렇지만, 역시 조엘 온 소프트웨어에서도 언급했던 부분이죠. (또한 이에 대한 해결책도 조엘은 제시를 하고 있어요.) 다음 글도 재미있답니다. ^^
*/
작성일 : 2003년 05월 04일 04시 09분 59초
>내용보기
>접기
필자가 몇년전 한 프로젝트를 담당할때 였다. 대기업은 아니나 적지 않는 기업이었다. 그 프로젝트를 위해서 팀을 구성하였는데 그 팀을 보면 팀장 1명 총무관리 여직원 1명 과장 1명 대리 1명 디자인 담당 대리1명 등으로 구성했다. 총 5명의 직원이 이팀을 맏았고 이팀은 프로젝트가 그회사의 핵심 프로젝트가 되는 것이다. 그런데 개발 진행에 대해서 아는 사람이 단 한명도 없는 것이다. 팀장이나 과장 대리등이 사실 IT에서 이럭저럭 업무만 진행했지 그분야에 실무 기술자가 아니라는 것이다. 결국 그 5명은 회사 사장에게 업무 보고를 하기 위해서 무엇이라도 하지 않으면 안되게 되었고, 결국 팀장은 “다음달에는 이기능 추가해서 무엇이라도 보여주시오!” 라고 개발자에게 명령하고 과장은 “기술 보고서를 작성해야 하니까, 요번달까지 한 내용을 문서로 해서 적어도 30페이지 만들어서 주세요” 라고 해서 그 문서에 이름만 바꾸어서 제출하고, “요번 프로그램에 들어갈 디자인이 나왔는데 현재 만든것에 껴서 저에게 보여주세요” 라고 하고...사실 정신이 없었다.
실제 개발에는 전혀 도움이 되지않는 일들이 진행 되는 것이다.
사실 필자는 13년 동안 이런 프로젝트를 해가면서 지금까지 살아왔다. 그리고 몇몇의 프로그램을 제외하고는 모두 완결해주었다. 그덕분에 정말 강인한 기술자로 성공했을지 모르지만 정작 완결 프로그램을 받은 회사에서 성공한 케이스는 10%도 안된다는 것이다. 전에도 이야기 했지만 소프트웨어는 반제품이며 실제 판매에 돌입되면서 나머지 50%가 완결되는 것인데 이렇게 만든 프로그램은 기 발전이 어려워 결국 패배의 쓴맛을 느끼게 되는 것이다.
프로그램을 제작하는 부분에서 프로그램이 진행되는 현재 과정이 어떻게 되어 있는지 알수가 없어서 발생하는 문제가 바로 프로그램을 완결하는데 가장 큰 장애가 된다.
이 원인의 대표적인게 그분야에 전문가가 아닌 사람들이 "메니저"를 맏고 있기 때문이다.
필자가 경험한 부분중에서 가장 고통을 받는 부분이 바로 이부분이다.
" 이프로그램을 제작하는데 기간이 얼마나 걸립니까?"
" 예 1년 정도 걸립니다."
라고 이야기하고 프로젝트를 계약하고 프로그램을 개발해 간다. 2개월이 지나면 아니나 다를까 바로 미팅에 돌입되어서 "어디까지 되었는지 봅시다" 라고 이야기를 한다.
난 내가 지금까지 설계한 내용과 그것을 코딩한 소스를 보여준다.
" 그게 아니라 눈으로 볼때 뭐 돌아가는거 말입니다. 내가 이소스 본다고 압니까?"
" 지금까지 한게 이겁니다. 더 보여줄께 없습니다." 라고 이야기 하면 바로 관리자는 불안에 떨기 시작한다.
' 프로그램 진행이 전혀 되고 있지 않다', '이러다가 프로그램이 나오지 않으면 어떻하지' 등등 여기까지면 다행이다.
' 지금까지 저놈이 개발비만 받아 먹고 논것은 아닌가?' 라는 의구심까지 가게 되는 것이다.
IT 산업에서 기술 개발에 전혀 문외한이 메니저가 될경우 이런 문제가 항시 발생된다.
여기서 문외한이라는게 컴퓨터에 컴자도 모르는 사람이 아니다. 미안하지만 "내가 전산을 전공했어요.." " 모 대기업에서 이분야에서 한 10년 했지요", "내가 이분야를 연구하는 사람이오" 라는 사람도 모두 포함된다. 쉽게 말하면 이론에 대해서는 대가이다. 그러나 그것의 실제 구현방식과 스텝에 대해서는 전혀 아는게 없는 사람들을 필자는 미안하게도 "문외한" 이라고 표현한다.
1 년정도 기간으로 프로그램을 작성하고자 할경우 실질적으로 눈앞에 그 프로그램이 보이는 싯점은 7개월 이후가 맞다. 그 이전에는 어떤 로직은 개발자 머리속에 어떤 작업은 설계도에 의해서 어떤 부분은 라이브러리라는 소스코드로 존재하게 된다.
그런데 안타까운것은 이런 부분에 대한 전혀 이해를 하지않는 국내의 많은 분야의 개발 여건이다.
“저도 솔직하게 많이 기다렸어요. 3개월 동안 제가 뭐라구 간섭을 했습니까? 난 단지 개발비만 꼭꼭 주지 않았습니까? 그런데 사실 여태껏 제가 본게 하나두 없다는 것입니다. 지금 이상태에서 제가 불안하지 않겠습니까? 안그래요? 이선생”
“제가 소스와 설계도 그리고 데이터 타입등을 보여 드렸지 않습니까? 지금까지 한일이요. 그리고 라이브러리 테스트된 결과도 보여 드렸구요”
“제가 그것을 보고 압니까?”
“아니 그래도 이분야에서 한 10년을 했다고 하셨는데...”
“그러니까 답답하지요. 아니 어떻게 3개월동안 아무것도 보이는게 없다는 말입니까? 이렇게 1년 보내다가 아무것도 안나오면 어떻게 해요? 그럼 난 어떻하라는 말입니까? 그러니 마시고 다음달 한달까지 기간을 줄테니까 제가 뭘 볼수 있게 해주세요.”
이런식으로 개발이 진행되면 결국 파탄으로 가게 된다.매니저는 개발자가 놀고 있는 것처럼 생각하고, 개발자는 고립되고 개발에 전념하는것 외에 보고자에게 무엇을 보여주어야 한다는 중압감에 시달리게 된다. 하청을 받아 개발을 하는 사람이면 ‘목구멍이 포도청’ 이라 어쩔수 없이 4개월에는 간단한 대모라도 보이게 해줄수 밖에 없다. 그러나 여기서 부터 어두움은 시작된다고 본다.
“음...이제 제대로 보이는 구먼.. 그럼요 여기에다 이기능을 다음달 까지 만들어 주세요.”
“아니 그것은 힘듭니다. 왜냐면요 지금 현재는 간단한 데모 형태이고요. 전체 구조를 완벽하게 구성하지 않고 넣을수는 없어요.”
“이선생님, 저도 이분야에서 10년은 있던 사람입니다. 저도 알거는 안다는 말입니다. 왜 안된다는 것입니까?”
이런식으로 출발을 하게 되면 결국 매니저가 원하는 형태로 기능을 하나하나 추가 하게 된다. 이렇게 되면 매니저는 무척 기뻐한다. 왜냐면 현재 일의 진척을 본인 스스로가 느끼고 알고 있기 때문이다.
이게 무슨 문제점을 야기하는지 아는가?
건물을 지을때를 이야기 해보자. 만일 10층 건물을 짓고자 한다면 기반공사 부터 들어가야 한다. 즉 10층을 버틸수 있게 지하로 땅을 파고 땅을 단단하게 다지는 공사를 해야 한다는 것이다. 그렇게 기반 공사를 몇개월 동안 한후에 철근 골조를 심어야 눈앞에 건물이 올라가는 볼수 있는 것이다. 소프트웨어에서도 같은 의미이다. 기반 공사를 해야 하고 기반 공사가 완결 될때 까지는 이렇다할 뭐가 보이지 않는 것이다. 그런데 기반공사를 하지도 않은체 이번달에는 1층 짓고 다음달에는 2층 짓고 해보자 그 건물이 제대로 올라가겠는가?
필자가 누구를 나무라기 위해서 이글을 쓰는게 절대 아니다. 이런 문제점은 어디서 부터 출발하는가? 바로 개발에 대한 실무 경험이 없는 사람이나, 또는 아주 간단한 경험을 가진 사람들이 메니저를 할때 출발이 된다.
이글을 읽고 있는 분들에게 부탁드린다. 만약 개발을 시작하고자 한다면 다음과 같은 룰을 가지고 움직이는것이 좋다.
1.말은 유창한 사람들을 절대 믿지 말고, 실무 경험자를 꼭 매니저로 두길 바란다.
어떤 아이템을 가지고 개발할때 보면 두 부류가 있다. 첫번째 부류는 실제 그 분야에서 개발을 해보았던 사람,또는 그와 유사한 제품을 개발해 보았던 사람, 두번째는 그 분야에 있기는 했는데 개발에 참여가 적은사람 으로 나눌수 있다.
개발을 해보지 않은 사람들을 절대 메니저로 나두지 말라. 특히 “모 대기업에서 해당분야에 차장 부장까지 하신 높은분” 은 절대 금물이다. 이렇게 이야기 하면 필자가 욕을 먹겠지만 이것이 사실이다. 대기업에서는 실제 제품의 개발을 담당하는 것이 아니고 많은 부서과 관리를 담당하게 되어있으며 엄청 큰 조직이 관리의 분업으로 이루어진다. 결국 그 대기업의 특정 분야의 특정 부분만 알지 전체적인것에 대해서는 그냥 대략적으로 만 알기 때문이다.
이럼 분들이 매니저로 두게 되면 결국 자기 보다 조금 더 알고 있는 사람을 자기 믿으로 두게 된다. 다행이 그사람이 실무 경험이 있다면 어느정도 다행이나, 그렇지 않다면 결국 그 밑으로 실무자가 배치되게 된다. 결국 일의 진척을 알지 못하는 매니저급이 2명이나 위에 있고 사장까지 합치면 3명이 3단계 보고식으로 구성을 하게 된다는 것이다. 그리고 기술자는 바로 그밑에 존재하는 것이다.
지금 이글을 읽으면서 자신이 아는 어느 기업의 흐름을 보기를 바란다. 내가 보기에 위에 관리자 급 3명 (3단계라고 표현하는 것이 옳을것이다)는 해당 분야에 실제 기술자가 아닌경우가 매우 많을 것이다. 그리고 그 밑에야 어느정도 그분야에 개발을 할수 있는 기술자가 포진 된다. 그런 회사에서 제품을 완결한다 하더라도 제품 개발 비용이 매우 크게 들수 밖에 없다. “관리자 3명의 월급이 뉘집 애 이름인가?”
2.1단계 책임제를 도입하라.-가능하면 1명으로
어떤 아이템이 있고 그것을 개발하고자 한다면 해당 분야에 개발을 해본 사람을 1명을 섭외해서 해당 사람에게 책임을 전가해 주기 바란다. 하청일경우 계약 부분을 정확하게 하고 완결을 못했을때의 책임에 대해서 강력하게 명시하라. 그리고 그 개발 일정에서 볼수 있는 내용들이 어떤것인가를 확인하라. 초기에는 프로그램이 아니더라도 어떤 설계도와 도큐먼트만 있을것이라 해도 그것이 돼어있는지 확인하기 위해서 그것들을 계약에 명시하도록 하라. 회사 내에서 개발을 한다 할경우에서 개발계획을 정확하게 하고 그리고 진행 과정에서 나오는 결과물을 확인하라. 이 결과물은 절대 눈으로 보이는 것이 아니다. 어떨대는 서류 뭉치가 나올수도 있는 것이다.
만일 책임자가 직원이 필요하다고 하면 가능한한 하청으로 유도하라. 해당 분야의 일을 할수 있는 하청자를 선택하고 해당일이 끝나면 그일에 대한 보수를 지급하는 형식을 택하는 것이 좋다. 책임자가 해당 분야에 개발을 알고 있다면 하청을 주어도 그 기술을 그대로 받아 들일수 있기 때문이다.
이런 책임자를 둔다면 비용이 일반 책임자를 두는것보다 매우 비쌀수 있다. 그러나 분명히 말하지만 그것이 비용 절감을 가져오게 된다. 1명이 3명이상의 몫을 하기 때문이다.
또하나 그 책임자는 고임금을 받기 때문에 딴생각 하지 않고 열심히 일하게 되는 효과가 있다.
3.제품이 완결되었을때 조직을 구성하라.
1명 책임제로 하여 제품이 완결되면 그때서 조직을 구성하라. 절대 급하게 구성하지 말기를 바란다. 일단 제품 완결후 부터 몇개월은 기술설명서및 라이브러리 등등을 모두 자료화 해야 한다. 그렇게 하고 앞으로 발전 계획을 생각하고 그 발전 계획이 완결되면 일이 분화 되며 이렇게 일이 분화 되었을때 그 일에 맞는 사람을 써야 하는 것이다.
이때 분명히 이야기 하지만 고임금을 두려워 하지 말기를 바란다. 만일 해당 분화된 분야에 적합하지 못한 인력이 투입된다면 결국 개발자는 늘어나게 되어있기 때문이다.
일반 많은 회사들이 제품의 개발인력보다 최소 2배 또는 3배나 많은 인력을 보유하고 있다. 그이유는 바로 고임금을 두려워 한데 원인이 있으며 적재 적소에 인력배치가 안돼기 때문이다. 그 테스트는 간단하다. “저 사람이 없어지면 개발에 차질이 올까?” 라는 생각을 했을때 “약간 불편을 하지만 크게 차질이 없다!” 라고 한다면 그 인력은 쓸모 없는 인력이 된다.
“도대체 어디까지 만든거야” 라는 발상은 눈으로 보이지 않는 IT 분야에서는 매우 위험한 행동이다. 또한 비용이 점차적으로 증가되는 문제도 야기 하게 된다.
“상엽아! 이 분야가 장난이 아니더라, 처음에는 이정도 금액만 들어간다고 하더니 계속적으로 밑빠진 독에 물붇기가 되더라구,그리고 지금도 엄청 들어가고 있고..사실 죽겠다. 제품은 안나오고”
이런 푸념을 하는 CEO가 있다면 그사람은 본 내용을 꼭 상기 해보기 바란다
