'개발SI'에 해당되는 글 2건

  1. 2007/08/03 글뻥 "대한민국 개발자 희망보고서"를 읽고나서의 소감...
  2. 2007/07/23 글뻥 개발은 강아지 발이 아니다.
오병곤씨의 "대한민국 개발자 희망보고서"(한빛미디어 ISBN 978-89-7914-475-8)를 읽었다.
사용자 삽입 이미지

한 3일정도 푹빠졌다고 해야 하나? 3일정도 읽고나서의 느낌은

"처음 10%는 필자가 프로젝트 경험으로 얻은 개발자의 어려움 토로하고 나머지 90%는 짜집기"

특히 에자일 방법론에서 파생된 수많은 방법론들에 대해 그냥 쫘아아아악 펼쳐 놓았다는 것이 문제로 느껴졌다. 다시 말해 XP 방법론에 대한 애찬이 곳곳에 들어가 있지만 처음에는 요구사항 중심의 개발을 찬양하다가 어느순간에 CRUD와 같은 방법을 찬양하다가 다시 테스트주도 방법론을 찬양한다.
다시말해 책에서 이야기하고자 하는 것이 무엇인지 처음 접하는 사람은 당췌 감을 못잡게 만들어 버린다. 그러면서 중후반부에는 글쓰기를 잘해야 한다고 강조하고 마지막에는 개발자로 성장하는 로드맵을 제시하는 것으로 끝을 맺으니 당췌 중심이 없다는 생각이 드는건 왜일까?

아마도 필자가 너무나 많은것을 알고 있기에 그것을 정리 하지 못한체로 책을 쓰지 않았나 싶다. 이런 책들이야 말로 오히려 실무에 있는 사람들을 더 햇갈리게 하는 그런책 되겠다.
그냥 대한민국에 있는 방법론 소개서정도로 만족해야 하지 않을까 싶다.

그렇지만 너무 아쉬움이 많이 남는 책이다.

첫째, 쭈우우욱 펼쳐놓고 여기서 니네에게 맞는것 찾아서 그거 중심으로 해라. 이건 완전 SI회사 마인드이다. 고객하고 이야기할때 "A가 있는데요~ A쓰면 뭐가 좋구여 뭐가 단점이예요. B는 뭐가 좋구여 뭐가 단점이거든요. 어떤거 하실레요?"와 같은 내용을 쭈우우우욱 좌판에 펼쳐 놓듯이 펼쳐 놓았다. 이경우 대부분의 경우 대화자체가 안된다. 왜? 돈주고 사는 고객입장에서는 뭔가 내 문제에 대한 솔루션(해결책)을 원한다. 그것도 강력한 리더쉽으로 좌판식 나열의 종착역은 고객이 "아~ 이래보니까 안되는데 이렇게 하면 어떤가요?"라고 이야기했을때 "아니~!? 고객님! 고객님이 선택해서 고객님이 책임지는것 아닙니까?" 이런 대답밖에는 안나온다. 딱! 그 느낌이다.

둘째, 차라리 개발자들에게 케리어 로드맵을 제시하는게 더 좋지 않았을까? 시대가 이렇게 변해왔고 현재 시장은 이런것을 원하고 있지만 이렇게 변할 것이니 요렇게 변화에 대응하는것이 오래 살아남는 방법이다. 뭐 이런것으로...

셋째, 요구사항수렴, 분석, 설계, 구현, 테스트, 릴리즈 중에 이 모든것을 관통하는 관통자가 없다. 이런 절차들 주루루룩 나열해 놓고 요구사항단계에서는 A방법론에 따라하는게 좋기때문에 유즈케이스 주도로 개발하구요~ 설계단계에서는 B방법론에 따라 테스트주도로 개발하는게 좋구요~ 등등. 한프로젝트에서 무슨놈의 방법론이 왜 그리 많이 등장하고 단계별로 나오는 산출물이 다 중요하면 왜 방법론 대로 하는가? 어떤 핵심이 되는 모든 단계를 관통할 수 있는 개념을 제시하고 그 개념에 따라 진행했을때 이러이러한 리스크가 있고 대신 이러한 잇점이 있으니 리스크는 이렇게 막아라 등의 단계를 떠나 프로젝트 전반을 관통하는 Silver Bullet이 필요한데 중반부에는 "은총알은 없다"라는 책에서 인용한 문구가 계속 눈에 띈다!
OTL... / 그렇다고 각 방법론을 내재화 할 수 있도록 도와주는 글들도 아니니 참으로 아쉽기만 하다.

다시 종합해보면 이것은 대형SI기업에 속한 사람이 쓴 대기업 SI맨의 입장에서 쓴 책되겠다.

여기서 글맺으면 짱돌 맞을것 같아 이렇게 하면 어떤지에 대해 제안해본다.

첫째, 우리나라 SI수주관행이 잘못되어 있다.
A라는 사람은 하루에 10본을 만들고 B라는 사람은 하루에 5본을 만드는 것은 자연스러운 일이다. 그리고 X라는 업무는 어렵고 Y는 쉽다. 따라서, 현재의 정통부 단가에 의한 단순한Man/Month 단가표는 엄청나게 현실과 괴리가 깊을수 밖에 없는 체계이다.
따라서, 영업초기에 업무분석과 그 업무에 대한 투입인력이 어느정도 정해져야 한다. 최소한 80%는 정해 져야 하고 여기에 M/M가 책정되어야 하는 것이다. 그래야만 고객도 인건비 짜르자는 이야기 안한다. 왜? 그거 짜르면 그 업무 진행 못하니까. 그리고 왜 80%인가? 실패하는 프로젝트를 분석한 자료를 본적이 있는데 약 30%의 요구사항 변경이 있게되면 그 프로젝트는 반드시 실패한다고 한다. 따라서, 요구사항 변경을 초기부터 20%로 제한하는 정책을 사용하는 것이다.

둘째, 개발자와 회사의 문제이다.
개발자는 일단 비판을 못견뎌한다. 나도 그러한것을 보니 개발자 맞나보다. 그리고 타인에게 자신을 보이거나 타인을 수용하는 자세가 안되어 있다. 팀웤은 무시하기 일수이고 혼자하는 것에 만족을 느끼지만 여러 사람과 함께하는 것에는 만족을 느끼지 못한다. 아니 느껴본적이 거의 없다. 그래서 팀웤에 대한 중요성을 알지 못한다. 다시말해 이는 개개인의 개발자가 속한 조직의 문제이다. 조직이 개인의 이직율이 높다는 것만으로 교육투자를 기피하여 개인의 발전에 도움을 주지 않고 개인의 능력만 쏙 빼먹고 베터리 떨어지면 버리는 풍토부터 없애야 한다. 그럴려면 작은 SI업체는 이제 정리해야 하는 것이다. 근근히 월급 주는데 무슨 교육이겠는가?  이러한 소규모 SI업체는 SI시장에서 철수하고 솔루션 시장이나 컨설팅업을 하는 것이 전체 시장에는 더 순이익이 될것이며 대형 SI가 더 생기게 하기위해서는 "정통부 단가"를 폐지하여야 한다.

셋째, 엄청난 산출물부터 정리해야 한다.
고객이 필요한것은 최초의 요구사항과 그에 부합되는 사용자/운영 매뉴얼 밖에 없다.
전자제품사면서 제품 설계도와 조립방법, 조립시간, 조립간 이슈사항 등등등이 담긴 산출물을 받아본 사람!?
지금 우리는 이짓거리를 하고 있는것이다. 다시말해 향후 유지보수라는 명목하에 이러고 있다. 즉, 개발초기부터 개발사가 해야할 유지보수에 대한 것도 고객에서 다 하겠으니 다 내놔라. 그렇게 시작하고 끝을 내면 고객에서 할 수 있나? 못한다. 하는 업체 정말 몇 못봤다. 결국 돈안들이고 개발사에 공갈협박에 아쉬운 소리해가면서 유지보수한다.
이게 현실인데 각종 설계서에 각종 위험관리 문서에다가 WBS에 테스트 케이스 등등등 (본인은 단일 프로젝트의 1권 출력으로 바인더만 40권 가득 터져라 바인딩해서 납품한적도 있다.. OTL) 고객에게 떠밀어 버리면 그거 감당할 수 있는 사람이 몇이나 되나?
이게다 문서 좋아하는 사람들이 만들어낸 허상일뿐이다. 참고로 CBD방법론의 표준인 아르미III는 문서산출물만 150여종이 된다! 이게 말이나 되나?
UML 산출물 5종(1+4접근방법일때)이면 모든것이 다 통하는데 왜 그짓거리 해야 하는가?
그것도 다 자동으로 소스까지 생성해주고 산출물 템플릿 정해놓으면 알아서 생성해주는데?
물론 요구사항 변경에 따른 형상관리는 당연히 따라줘야 하는것은 필수이다. 그렇지만 이러한 자동화되는 형상관리 내역까지 따로 출력물로 있어야 한다는 사고가 문제인것이다.
왜 자동파일로 저장되어 있으면 안되는 것이지?

아무튼 현재 대한민국의 대표 IT업종 다시말해 대한민국 개발자의 대부분이 몸담고 있는 업종 SI산업은 모순덩어리이다. 거기다 너무 많은 업체가 몰려 있다. 이것도 문제이다.

이제좀 하나씩 풀자. 하나하나씩.
이것이 "대한민국 개발자 희망보고서"에서 유일하게 공감하는 내용이다.
2007/08/03 11:11 2007/08/03 11:11

먼저 스마트 프레이스라는 유명한 사이트의 글을 한번 읽어보자.

삼성 SDS, LG CNS, SK C&C 그리고 기타 업체들

안녕하세요. 스마트플레이스의 치프 블로거이자 개인 블로그 피플웨어를 운영하고 있는 류한석입니다.

이 포스트는 여러분의 의견을 듣기위한 포스트입니다.
 
이번에 매체에 칼럼을 쓰는데, 국내 소프트웨어 업계의 현실을 주제로 쓸 예정입니다. 한국의 경우 유독 SI 위주의 기형적인 소프트웨어 산업 구조를 갖고 있습니다. 통계에 따르면 삼성 SDS, LG CNS, SK C&C 상위 3개사가 매출의 80% 이상을 차지하고 있습니다. (참고: SW 진흥법 개정안 상정을 환영하며)

저는 대기업 계열 SI업체들로 인해 한국 소프트웨어 산업이 후진성을 벗어나지 못하고 있다고 생각합니다. 즉 이것은 혈액순환이 완전히 막혀있는 것과 같습니다. 그들만의 리그입니다.
 
패키지 소프트웨어는 거의 찾아볼 수 없습니다. 많은 소프트웨어 업체들이 솔루션을 가장한 SI로 먹고 살고 있습니다. 저 또한 사회 생활을 SI로 시작하였으며, 눈물을 흘려야 했던 기억을 갖고 있습니다.
 
대기업 계열 SI업체들에 대한 여러분의 의견, 그리고 직접 일을 하면서 또는 협력 업체로서 겪은 사례들에 대해 코멘트를 남겨주시면 칼럼 작성시 참고하겠으며 필요하면 인용토록 하겠습니다.

언제나 고맙습니다.
대한민국 소프트웨어 발전과 개발자의 개인 복지를 다 아사가는 것이 모두 대형 SI책임이라고 한다.
그렇다. 대형 SI회사 책임맞다.
첫째, 그렇게 많은 돈을 가지고 제대로된 방법론이나 SI사업시장 확대, 솔루션에 투자가 아주 미미하다.
둘째, 대형 SI가 CAP만 씌워서 매출 가져가는 프로젝트 많다. 인정한다.
셋째, 협력사에게 무례하게 굴은 경우 굉장히 많다. 이것도 인정한다.

그러나, 이게 개발자의 개인적인 복리후생과 무슨관계인가?

오히려 구조적인 문제는 아닌지 봐보자.
첫째, 소형 SI업체가 너무 난립하고 있다. 솔찍히 A라는 업체 마음에 안들면 B로 바꾸는거 다반사다. 그만큼 종속된 기술도 아닐뿐더러 기술자체가 쉽다. 특히 인터넷개발이 그러하다.
둘째, 솔루션...솔루션하는데 대한민국에 불법복제때문에 솔루션 시장자체가 존재하는가? 대한민국 대학생들부터가 불법복제로 무료로 사용하고 기업도 SI개발비 몇푼은 아쉬워도 하드웨어 아쉬워 하는데 못봤다.
셋째, 지금 개발하는 방법 그 자체가 문제가 있다고 생각해본적은 없는지? CRUD니 ERD니 실컷 그려놓으면 뭐하나? 문서를 위한 문서일뿐인데...
*CRUD와 ERD. 쉬파. 나도 존나 짜증난다.
사용자 삽입 이미지
사용자 삽입 이미지
넷째, 솔찍히 작은 협력사 인원해봐야 20명정도이다. 이정도면 꽤 규모 있는 회사인데 프로젝트에 한 3~4명 투입한다고 치자. 그럼 3달 개발한다고보면 1인에 500만원씩 한 6천짜리 개발하는거다. 규모있다고 치는 10억이상이면? 6개월정도 잡고 한 30명 투입해야 하는데 상시 30명 스텐바이하고 있는 회사가 몇이나 되나? 결국 돌려막기하는거다. A프로젝트 투입되어 있는 인원을 밤에 불러서 B프로젝트 일 도와주게하고 B프로젝트인원은 C프로젝트 휴일에 불러서 일시키고 이런식으로 사람돌린다. 이게 현실이다.

다섯째, 새로운 방법이 있다고 다른길로 한번 가보자고 하는 인간 한번도 못봤다. 입으로는 객체지향이라고 떠들면서 UML툴로 요구사항수렴, 분석, 객체설계, 컴포넌트설계, 개발, 테스트, 배포까지 흐름을 제대로 타고 문서를 위한 문서가 아닌 정말 개발을 위한 문서작업을 해본 개발자는 몇이나 될까? 아마도 이글을 보는 10명중에 1명 될까 말까할것이다.

여섯째, 정보통신부 단가표를 쓰레기통에 버려야 한다. 정보통신부 스스로도 지키지 않는 단가표를 공표하다보니 어떠한가? 일반 기업에서는 30% 우습게 치고 들어간다. 그래서 재경비에 기술료 포함해서 중급개발자 690만원짜리가 500만원되고 이걸로 기업하는 사람입장에서 월급주고 사무실 운영하고 전기세에 기타등등 굴리는 거다. 물론 이 구조의 장점도 있다. 힘없는 작은 업체가 최소한의 개발비는 얻을 수 있는 것이다. 그러나, 그 작은 업체들의 보호하기 때문에 다른 경쟁력 있는 업체가 크지 못하는 것이다. 다시말해 시장을 수백개의 업체가 나눠먹기하고 있는데 어떻게 돈을 벌것이며 어떻게 회사규모를 키울것이가? 결국 규모가 되는 대기업이 따먹게 되는 구조인것이다.

일곱째, 개발자 스스로 한번 물어보자. 고객입장에서 고객이 원하는 산출물을 만들어주기위해 노력했냐고... 고객과 싸우는 개발자 한두명 본것도 아니고 고객이 A라고원했는데 B라고만들어와서는 B가 더 쓰기 편하니 그냥 쓰라고 우기는 개발자 수두룩하다. (설계서하고도 딴판이니 더욱 가관) 거기다가 10년전쯤 부터 개발자=웹스크립트개발자라는 이상한 등식이 거의 박혀있다보니 노가다 하고있는것이다. 웹스크립트가 컴포넌트 베이스처럼 심플하기는한가? HTML코딩하고 디자인 신경쓰고 뭐 어쩌다보면 사용자 UI라는 측면하고는 완전 동쩔어지게 마련인데다가 WEB은 스크립트 어느정도 공부하면 되기때문에 진입장벽도 낮고 더이상 발전이 없는경우가 허다하다. "원래 팔자가 노가다인 웹개발을 하면서 노가다가 싫어요"하는것은 조금 우습지 않을까?(했던 코딩 또하고 또하고 또하고...) 더군다나 UML2.0 MDA가 지원되면서 왠만한 코드는 UML만 그려놓으면 90%정도의 완성도로 자동으로 생성되는데 그래도 코딩한 할렵니까?

대기업만 가지고 두들겨 패는 편엽한 생각에 나도 모르게 같은 밥 먹고사는 개발자들끼리 싸움붙이는 정부기관이 미워서 이렇게 내 블로그에 한마디 남긴다.

긴훗날 이글을 보며 이렇게 힘들게 일할때도 있었구나 추억으로 간직하고 싶다.
2007/07/23 23:59 2007/07/23 23:59