소프트웨어 관료화
2009/08/31 22:25 by 전규현
All of Software 블로그를 RSS Feed에 등록을 해 놓으시면 편리하게 받아보실 수 있습니다.
RSS Feed
RSS Feed
"공무원 수는 해야 할 일의 경중이나 업무 유무에 관계없이 일정한 비율로 증가한다", "공무원은 서로를 위하여 서로 일을 만들어 낸다", "유능하지 못한 사람은 공무원이 된다."
이는 그 유명한 파킨슨의 법칙입니다.
소프트웨어를 개발할 때도 이와 같은 함정이 도사리고 있습니다.
주먹구구식으로 소프트웨어를 개발하다가 체계적으로 개발하고 싶은 요구가 생길 때 프로세스팀을 구축하고 개발 프로세스를 정립하다 보면 파킨슨의 법칙에 빠지기 쉽습니다.
프로세스팀의 구성원들은 진짜 소프트웨어 전문가로 구성되는 경우가 드믑니다. 여기서 말하는 소프트웨어 전문가란 코딩만 잘하는 개발자가 아니고, 구축, 설계, 테스트, 형상관리, 버그 추적, 빌드, 릴리즈, 방법론 등 소프트웨어 관련 여러 분야의 지식과 경험을 두루 갖추고 있는 사람입니다.
이런 비전문가로 구성된 프로세스 팀은 소프트웨어 개발의 내용을 속속들이 잘 모르고 너무 형식에 치우칠 수 있고, 끊임없이 프로세스팀이 할 일을 만들어 내기 위해서 프로세스를 점점 복잡하게 만들곤 합니다. 이들은 어떤 것이 정확하게 올바른 방법인지 잘 몰라서 그렇게 하기도 하고, 자신들의 밥줄을 견고하게 하기 위해서 여기저기 승인 절차를 많이 추가해서 프로세스팀이 소프트웨어 개발 프로세스의 중요한 역할을 하고자 한다.
프로세스팀은 소프트웨어를 효율적으로 개발하기 위한 방법들을 연구하지만 소프트웨어 개발 프로세스 중간에 직접 끼어들어서 간섭하는 프로세스를 만드는 것은 바람직하지 않다. 소프트웨어를 개발하는데 있어서 여기저기 승인 절차를 잔뜩 집어 넣어 놓는 것도 그리 좋지 않습니다. 승인 절차가 소프트웨어의 무결성을 보장해주진 않습니다. 오히려 관료화된 승인 절차는 아무런 도움이 되지 않는 경우가 많습니다. 소프트웨어는 각 분야의 전문가들이 자율적으로 효과적으로 움직였을 때 가장 효율적으로 개발됩니다. 명시적인 승인 절차가 없더라 승인절차를 거친 것과 같이 모두가 진행상황을 훤히 알 수 있게 됩니다. 이렇게 개발되는 방식이 오히려 소프트웨어 무결성에 더 도움이 됩니다. 승인 절차는 형식적인 승인이 되기 쉽지만, 각 단계의 전문가들이 리뷰를 하고 Unit 테스트를 하고 시스템 테스트를 하고 빌드전문가가 확인을 하고 이러한 전 과정을 통해서 문제가 되는 것들은 발견이 되고 개발도 효율적으로 진행됩니다.
소프트웨어 개발 경험이 부족한 프로세스 팀은 철저한 승인 절차가 아니면 안전한 소프트웨어를 개발하기 어려울 것 같이 생각되지만, 이는 경험 부족에서 오는 착각이거나 관료화의 조짐입니다.
또 소프트웨어 개발에 대한 이해가 부족한 경영자들은 이들이 주장하는 프로세스가 그럴듯해 보이지만 사실은 소프트웨어 개발에 상당부분 걸림돌이 되고 있다는 것을 눈치채기 어렵습니다.
진짜 소프트웨어 전문가로 프로세스팀을 만들 것이 아니면 내부에서 진행하는 여러 개선 시도들이 시간 낭비인 경우 많고, 시행착오 없이 6개월이면 갖출 수 있는 경쟁력을 먼 거리를 돌아서 수년이 걸리거나 영영 경쟁력을 갖추지 못하는 경우도 많습니다. 프로세스팀을 갖추려면 소프트웨어 전문가로 구성을 하거나 내부에 전문가가 없다면 외부에서 도움을 받는 것이 좋습니다.
회사 내에서 소프트웨어 개발을 잘 하는 개발자가 소프트웨어 전문가라고 생각하지는 마세요. 공을 잘 차는 축구 선수일 뿐입니다.
* 이 포스트는 blogkorea [블코채널 : 꿈꾸는 소프트웨어 개발자 세상] 에 링크 되어있습니다.
(image by Microsoft Office Online)
'개발프로세스' 카테고리의 다른 글
| 획일화된 프로세스의 함정 (6) | 2011/04/03 |
|---|---|
| 이번 프로젝트 내일 끝나? (10) | 2011/01/31 |
| 소프트웨어 관료화 (16) | 2009/08/31 |
| 프로세스가 창의성을 저해한다고? (8) | 2009/04/08 |
| 소프트웨어 개발의 극과 극 (0) | 2009/02/18 |
| Waterfall과 Agile (5) | 2009/02/06 |
Trackback Address: http://allofsoftware.net/trackback/143
우리나라 공무원은 엘리트라서 말이죠 ㅋㅋ
저런 이유에서 사수가 있는건 참 좋은것 같습니다
(사수없이 3년 ㅠ.ㅠ)
구차니님 안녕하세요.
사수... 이것에 대해서도 할말이 많습니다. ^^;
기형적인 구조 떄문에 사수가 아니면 별 뾰족한 방법이 없는 것도 현실이고... 나중에 올릴께요.
프로세스팀의 구성원들은 진짜 소프트웨어 전문가로 구성되는 경우가 드물다는 말...
상당히 찔리고 공감이 가네요 ^^;;;
안녕하세요. 김경록님
솔직하시군요. ^^
너 자신을 알라!, 아는 것이 힘이다.
즉, 자신을 아는 것이 힘이다.
해결책은 없겠죠.
철통 밥그릇이 그렇듯...
전문가가 아닌 사람의 머리를 쪼개서 지식을 넣어 줄 수도 없고...
참으로 난형난재입니다.
hermian님 안녕하세요.
지식을 넣어 주는 기술은 300년은 지나야 나올 듯합니다.
300년 지나면 가능해지나요??
가능한 일이면 좋겠습니다.
어쨌든, Ray님의 글들에 동의 합니다..
안녕하세요. 이혜원님
그래서 저희같은 사람의 도움이 필요합니다.
외부 전무가의 힘을 빌어서 변화를 꾀하는 것이 가장 빠르고 무리없이 변화에 성공할 수 있는 방법입니다.
제가 유일하게 RSS등록해두고 잘 보고있는 블로그인데 처음 글 남깁니다.
7년 동안 사수없이 고군분투해오다 보니 남는게 별로 없네요....
그래서, 요즘 전규현님 책과 블로그의 도움을 받아서 흔히 얘기하는 시스템과 프로세스를 구축하고 있습니다.
앞으로도 좋은 글 부탁드립니다.
가끔 글도 남길께요^^
장호진님 안녕하세요.
열심히신군요. ^^ 책보고 스스로 뭘 해보는 것이 정말 힘들죠. 궁금하신 것이 있으면 언제든지 문의해주세요. Email은 항상 열려있습니다.
소프트웨어 전문가란 어떤 사람을 말하는지요..제대로 된 정의를 찾기 힘드네요..
본문에서도 언급했듯이 "소프트웨어 전문가란 코딩만 잘하는 개발자가 아니고, 구축, 설계, 테스트, 형상관리, 버그 추적, 빌드, 릴리즈, 방법론 등 소프트웨어 관련 여러 분야의 지식과 경험을 두루 갖추고 있는 사람입니다."
제대로 시스템과 프로세스, 개발 문화를 갖추고 있는 회사에서 10년 이상을 개발을 해 온 개발자라면 이런 분야를 두루 섭렵할 수 있지만, 보통의 경우에는 주로 구축(코딩)과 설계만 치중하기 때문에 소프트웨어 전문가가 되기는 어렵습니다.
소프트웨어 전문가인가요 아니면 소프트웨어 엔지니어링 전문가 인가요?
본래 둘을 같은 의미로 쓰던가요?
소프트웨어 공학하면 왠지 이론적인 냄새가 많이 나서 별로 사용하기가 꺼려지지만 지식과 경험을 모두 갖추고 있어야 진짜 소프트웨어 공학이라고 할 수 있죠. 따라서 지식과 경험을 모두 가지고 있다면 소프트웨어 전문가, 소프트웨어 공학 전문가를 따로 구분할 필요는 없어 보입니다. 그래서 가끔 이론적으로만 소프트웨어 공학을 공부하고 연구한 교수를 전문가로 봐야 하는지에 대해서는 섯불리 얘기하기 어려운 측면이 있습니다. 그 분들도 분명히 이론적인 기반을 다지고 새로운 기법들을 연구하는 것에는 의미가 있으나 실제 소프트웨어에 접목할 수 있는 경험이 없고 실제로도 어렵기 때문에 여전히 이슈는 존재합니다.
개인적으로는 그것 가지고 소프트웨어란 광범위한 전문가라고 부르기엔 뭔가 찜찜하네요,..
안녕하세요. dkinght님
관념적으로 접근을 하는 것은 별 의미 없을 것 같고, 진짜 소프트웨어 필드에서 필요한 전문 지식 몇 경험 분야를 보려면 IEEE에서 정의한 소프트웨어 전문 영역 10가지를 보는 것도 좋을 것 같습니다. 정확한 답은 아니더라도 도움을 될 겁니다.