티스토리 뷰

인류는 소프트웨어 개발을 시작한지 이미 수십년이 지났다. 그 기간동안 다양한 개발 기법이 탄생했고 실제 실무에서도 상당한 결과물들을 만들어 온 것도 사실이다. 하지만 과거나 지금이나 개발자들은 항상 고통에 쌓여있고 개발 과정에서의 스트레스로 골머리를 앓고있다.

수십년동안 진보하지 않은 것인가?

결코 그렇지 않다. 인류가 진화해 왔고 그 진화속에 기술들이 한 축을 형성하며 인류 진화에 이바지해 왔기에 소프트웨어 개발 역시 꽤 많은 진화를 거듭해 왔다고 보는 것이 맞을 것이다.

그럼에도 영원히 풀리지 않을 숙제처럼 개발과정에서 많은 문제점들이 노출되는 것도 사실이다. 이전글인 "사상 최고 또는 최악의 소프트웨어를 가르는 기준은?"을 보면 전체 소프트웨어 개발 프로젝트에서 약 25 % 정도의 소프트웨어가 완전히 실패했고, 50%의 프로젝트가 개발 기한을 넘겼으며, 대부분의의 프로젝트가 예산을 초과했다는 통계가 있다.

이런 일련의 소프트웨어 개발 실패는 인력 문제, 개발 범위 산출 문제, 스케줄관리 미흡.. 등 다양한 문제들 가운데서 나타나는 것도 사실이다 .

 


과거로부터의 경험을 활용하다.
우리는 과거로부터 이런 실패 사례들을 통해 좋은 경험을 얻어왔지만 이를 잘못이해하는 바람에 오히려 잘못 된 방법으로 프로젝트를 진행하는 경우도 발생한다 .

소프트웨어 개발과 관련한 통계에 따르면 중규모 프로젝트의 75%와 대규모 프로젝트의 90% 이상이 스케줄에 쫒기면서 일하게 된다고 한다. 이런 상황이 한국에서도 심화되다 보니 정상적인 업무 시간 이외에 초과근무는 당연시하는 현상이 일어났다.

기업은 오히려 이것에 문제의식을 가지고 개선해 좀 더 가치있는 프로젝트운영을 위해 기법과 프로세스를 정비하기 보다 직원들의 초과 근무를 은근히 바라는 상황까지 발생하고 있는 것이다.

이 과정에서 우리가 착각하는 것은 과거에 비해 더 큰 규모의 프로젝트를 진행하고 있기 때문에 새로운 기법이나 프로세스 개선이 쉽지 않다고 잘 못 판단하는 경우가 비일비재하다. 

과거의 예를 하나 찾아보자면 1966년에 완성 된 OS/360 개발의 경우 5,000명 가까운 인원이 투입이되었다. 그로부터 10여년 이상이 흐른뒤 Microsoft에 의해 시작 된 윈도우 NT 프로젝트는 3~4년에 걸쳐 1,500명의 인력을 투입해 개발했다.

과연 시간이 지나고 개발 코드의 양이 늘었다고해서 과거에 비해 개발의 양이나 범위가 더 커졌다고 느낄수 있을까?

우리가 이 과정에서 간과하고 있는 것은 5,000여명 이상이 투입되던 프로젝트가 1,500여명 수준으로 줄었다는 것이다. 우리는 과거의 경험을 통해 좀 더 프로젝트 관리를 원활하게 할 수 있는 방법을 찾았고 그것이 오늘날 초대형 프로젝트 속에서 지속적으로 성공율을 높일 수 있게 된 이유인 것이다.


그런데 왜? 급격하게 프로젝트 개발 성공율이 높아지지 않나?
소프트웨어 개발과 관련한 조사 자료들에 따르면 일반적으로 프로젝트가 크게 실패하는 요인은 요구사항에 있다고 한다. (요구사항 문제는 시스템 정의, 요구사항의 지속적인 변화 과정.. 등으로 시스템 디자인이 엉망으로 되는 문제를 일컫는다)

클라이언트는 늘 생각이 변하기 때문에 계약 당시와 프로젝트 진행과정 끝에가서는 프로젝트 완료 과정에까지 끊임 없이 새로운 것, 예상 불가능한 아이디어를 요구한다.

이것이 결국 프로젝트 성공을 어렵게 만드는 요인으로 작용한다는 것이다.

다만 이런 상황은 과거에도 끊임 없이 문제가 되어 왔다는 사실을 알아야 한다. 유명한 매니저들이 이 과정에서 문제점을 이야기 하는 공통적인 요소는 빠르게 만드는 것과 정확하게 만드는 것의 차이를 인지해야 한다는 것이다.

사용자의 요구가 많아지는 요소들을 생각해 보면 실제 시스템 설계시에는 예상하지 못했던 것들이 대부분 일 것이다. 설사 예상을 했어도 예상 범위를 넘어서는 요구들도 많을 것인데, 문제는 이 과정에서 대부분은 정확하게 개발하는 것보다 빠르게 개발할 요소를 찾다보니 이런 불특정한 요구에 쉽게 대응하기 어려운 취약 요소속에서 프로젝트 개발이 시작 된다는 것이다.


빠르게 개발하는 것과 정확하게 개발한다는 것의 차이..
정석적인 답이겠지만 3개월의 프로젝트 기간이 있다고 한다면 끝까지 좋은 프로젝트 성공율을 유지하는 팀은 설계에 시간과 공을 많이 들인다.

빠르게 만든다는 것은 빨리 만들어 사용자의 피드백을 받아 빨리 뜯어 고칠 수 있다는 장점이 생기지만 궁극에는 정확한 설계가 밑받침되지 않는 경우가 많아서 프로그램이 꼬이거나 오류가 발생해 시간이 지날 수록 최악의 문제를 발생시키는 경우가 많다.

최대한 다양한 예상 범위를 생각해 심도있게 설계와 시스템 디자인에 시간을 쏟고 프로그램 개발에 나머지 시간을 쏟을 수 있는 프로젝트 운영이 필요하다는 것이다.

앞으로 이 이외의 다양한 실무적 이야기들로 예를들어 주겠지만 필자가 오늘 하고자 하는 것은 빠르게 만드는 것보다 어떻게 빠른 피드백들을 반영 할 수 있는 완벽한 시스템을 만드느냐에 더 포커싱이 되어야 한다는 것이다.

개발 기법, 매니징, 방법론, 시스템 툴 사용의 문제등은 아주 작은 요소의 단위이다. 충분히 공부하고 노력한다면 어느정도 이런 요소들은 다른 기법을 제시하거나 매니징 툴을 바꾸는등으로 해결 할 수도 있다.

그러나 기본적으로 설계가 잚못된 시스템은 새롭게 프로젝트를 구성하는 것보다 개발이나 업그레이드가 지연되는 현상이 발생한다. 설계와 디자인에 70%의 시간을 쏟고 나머지 30%로 개발 할 수 있는 소프트웨어 개발에 대해 좀 더 심도있게 생각해 볼 필요성이 여기서 생기는 것이다.


이 글은 아이엠데이 IT 칼럼에 기도 된 글입니다.
http://www.iamday.net/apps/article/talk/762/view.iamday
저작자 표시 비영리 동일 조건 변경 허락
신고
댓글
  • 프로필사진 Favicon of http://crabbit.tistory.com/ BlogIcon 굴뚝토끼 좀 다른 이야기지만 삼성이 윈도8 탑재 스마트폰을 만들었다는 이야기를 듣고
    결국 바다는 물론 안드로이드도 손을 뗄 것 같다는 생각이 들더라고요.

    윈도 폰의 성공 역시 소프트웨어 파워일텐데,
    그 파급효과는 스마트폰 시장 평정할 수준이 될 듯 합니다.
    2012.02.06 07:13 신고
  • 프로필사진 Favicon of http://systemplug.com BlogIcon 어설프군 YB 그렇게 예측해 볼 수도 있겠네요. ^^;;

    최근보면 인텔과 같이 만드는 리모 기반의 OS인 타이젠 성과를 봐서 전략이 결정 될 것 같다는 생각이 들기도 하고요. ㅎ
    2012.02.07 10:55 신고
  • 프로필사진 하모니 일류=>인류 2012.02.06 08:23 신고
  • 프로필사진 Favicon of http://systemplug.com BlogIcon 어설프군 YB 지적 감사합니다.
    수정했습니다. ㅎ
    2012.02.07 10:55 신고
  • 프로필사진 Favicon of http://yagulog.tistory.com BlogIcon 박상혁 운이 좋아 이루어진 것이 아니었군요,
    영화만 보고 그렇게 생각했었는데 말입니다.
    2012.02.06 09:01 신고
  • 프로필사진 Favicon of http://systemplug.com BlogIcon 어설프군 YB 그렇죠. ㅎㅎ 2012.02.07 10:55 신고
  • 프로필사진 지나가던IT개발자 대한민국 IT에서는 무조건 빨리 Output을 내는게 장땡입니다.

    많은 개발자들이 이 논제때문에 많은 고민을 하고있을것 같습니다. 아직도.
    2012.02.06 09:06 신고
  • 프로필사진 Favicon of http://systemplug.com BlogIcon 어설프군 YB 네.. 빨리는 좋은데 문제는 시간안에 지키기 힘든 양을 빨리하니깐 문제인듯 합니다. 작은 모듈를 잘개 쪼개서 설계를 기가 막히게 해놓고 하나씩 빨리 적용하는 전략이 개인적으로 최고라고 생각합니다. 2012.02.07 10:56 신고
  • 프로필사진 Favicon of http://bassgrammer.tistory.com BlogIcon 베이스그래머 현업에서 개발을 하고 있는 입장에서 환경의 문제가 많은 것은 지극히 인정하나 프로그래머 스스로도 그런 환경을 바꾸기 위해 얼마나 노력하는지 되짚어 볼 필요는 있을꺼 같습니다.

    참 씁쓸한 현실이지요
    2012.02.06 09:45 신고
  • 프로필사진 Favicon of http://systemplug.com BlogIcon 어설프군 YB 네.. 좋은 지적을 주셨네요.

    환경만 탓하기에 앞서 개선을 위한 공감대에 대해서도 고민해야 한다는 의견으로 생각하겠습니다. ㅎㅎ

    힘내세요.
    2012.02.07 10:57 신고
  • 프로필사진 Favicon of http://otkhm.tistory.com BlogIcon 릿찡 ,근본적인 문재중 하나는 높으신 분들이 소프트웨어를 모른다는 거겠죠. 높으신 분이 소프트웨어를 아는 구글이나 마소 애플과 같은 회사에서 조사하면 약간은 높아지지 않을까 하고 생각해봅니다. 2012.02.06 16:53 신고
  • 프로필사진 Favicon of http://systemplug.com BlogIcon 어설프군 YB 네.. 근데 거기도 거기 나람의 문제가 있어 보이더라구요.

    단지 정도의 차이일 뿐이지요. ㅎ
    2012.02.07 10:57 신고
  • 프로필사진 소프트웨어 개발 설계의 중요성은 항상 소프트웨어를 개발하는데 대두대는 문제점이죠. 시간과 요구사항 참 어려운 문제죠.그래서 요즘 많이 부각 대고 있는것이 소프트웨어 관리자입니다. 소프웨어 개발자와 고객 사이에 요구 사항과 비용등을 적절하게 중간에서 관리하는거죠. 설계에서도 예전에는 리스크나 아님 중요사항을 제일 우선순위에 두었지만, 요즘은 고객의 요구 사항을 제일 우선순위에 두는 추세로 가고 있죠. 그래서 점점더 중간 관리자가 중요해지는 것 같습니다. 2012.02.06 18:49 신고
  • 프로필사진 Favicon of http://systemplug.com BlogIcon 어설프군 YB 좋은 지적 주셨네요. 좋은 중간 관리자가 필요한데.. 사실 이런 부분을 제대로 커버해 줄려면 또, 소프트웨어 공학부터 PM 과정에 대한 별도의 공부가 필요한데..

    아쉽게 이런 분들이 많지 않다는점이죠..

    암튼 한국은 시장에 대해 좀 더 깊이 있는 고민이 필요하단 생각이 들어요.
    2012.02.07 10:59 신고
  • 프로필사진 Favicon of http://kimstreasure.tistory.com BlogIcon Zoom-in 방법론이 뭐가되든 기간이 얼마되든 이보다 중요한게 있습니다.
    개발하려는 소프트웨어에 적정한 비용을 산정하면됩니다.
    국내에 대부분 실패하거니 성공적이지 못한 프로젝트들은 저가 산정입니다.
    2012.02.06 20:22 신고
  • 프로필사진 Favicon of http://systemplug.com BlogIcon 어설프군 YB 그게 가장 큰 문제이지요. ㅡㅡ;;
    이건 당분간 바로 해결은 어렵지 않을까 생각되네요.
    2012.02.07 10:59 신고
  • 프로필사진 그동안 만든 코드들을 보면 어렵고 힘들게 만든 코드들은 변화에 약하더군요.

    보통은 단순하고 쉬운 코드들이 더 오래가고 재사용성도 높지요.

    문제는 어렵고 힘든 상황을 갑과 마더 을들이 걷게 하는 거지요.

    영업이 불필요한 솔루션들을 찔러넣어서 안써도 될 기능을 써야 될 때도 있고.

    정책적으로 결정나지도 않은 것들을 선개발한 경우도 있고.

    무조건적인 개발 가이드의 준수 (뭐든지 극단적이면 문제가 있지요.)를 강요할 때도 있습니다.
    2012.02.07 04:42 신고
  • 프로필사진 Favicon of http://systemplug.com BlogIcon 어설프군 YB 정말 실무를 해본 분들이라면 경험 했을 부분들을 지적 주셨네요.개인적으로 개발자는 아니지만 기획자로 외부 프로젝트를 하다 보면 느끼는 부분중의 하나가 아닐까 생각됩니다. 2012.02.07 11:00 신고
  • 프로필사진 굳이 얘기를 하자면 결국은 돈문제로 귀결이 될텐데..

    S/W 규모 산정 방법 자체가 너무 낙후된 것도 문제가 아닐까 싶네요.

    본수 산정 방식에서 FP 방식으로 넘어가긴 했는데.. FP도 나온지 몇십년 된 방식이고.

    FP는 너무 데이타 흐름 위주여서 UI나 디자인.. 개발의 어려움 등을 넣을 수가 없습니다.

    뭐 보정치라고 주기는 하든데.. 쩝..

    하긴 계산된 FP만큼이라도 받으면 휘청거릴 업체들 없겠죠.
    2012.02.07 04:45 신고
  • 프로필사진 Favicon of http://systemplug.com BlogIcon 어설프군 YB 네..맞습니다. 해외에서는 그런게 그나마 잘 되어 있는 것 같아요.

    문제 분석후 무리한 프로젝트 진행에 따른 부분이 생기면 이와 관련해 인정하는데 한국은 그런 부분이 부족한 것도 있고..

    말씀 하신 것처럼 FP 방식의 문제도 있고요.

    이런건 사실 실무쪽에서 쉽게 해결하기 힘든 부분이거든요. ㅡㅡ;;
    2012.02.07 11:02 신고
  • 프로필사진 Favicon of http://cfono1.tistory.com BlogIcon cfono1 서비스와 논리를 생각하는 사람의 역량에 따라 향후 성장하는 서비스의 무게를 감당할 수 있겠죠. 이런 능력 없이 그때 그때 땜질한다면 참 난감할꺼에요^^;;; 2012.02.07 15:48 신고
  • 프로필사진 Favicon of http://systemplug.com BlogIcon 어설프군 YB 네.. 맞는 말씀이세요. 아무리 힘든 환경이라도 미래를 꿈꾸는 개발자는 확실히 뭔가 달라도 다르더군요. ㅎㅎ 2012.02.07 23:20 신고
댓글쓰기 폼