프로젝트 관리

1편 : 소프트웨어 공학을 공부해야 하는 이유

홍옹 2025. 3. 16. 15:12

 

서비스 기획자로서 저는 SI업체에서 커리어를 먼저 시작하였습니다. 그러다보니 요구사항에 맞춰 설계업무만 하는 경우도 있었었지만 프로젝트 전반적으로 이끄는 PM, PL 업무를 맡게 되는 경우도 종종 있었습니다.

 

그러다보면 다양한 사람들의 프로젝트 방법론을 경험해 보게 되는데요. 이게 사람마다 다르고 회사마다 다르더군요. 거기다 A프로젝트를 문제없이 마무리 잘한 사람한테 B프로젝트를 맡겼더니 이게 문제가 많이 발생하는 Case도 있었습니다.

 

이러한 케이스들을 경험하면서 제 나름대로의 프로젝트 방법론을 구축하고 적용해 보면서 저만의 프로젝트 방법론을 다듬어가고 있었습니다.

 

그러던 중 최근에 아주 폭망한 프로젝트를 경험하게 되는데요. 제가 판단했을 땐 피해를 최소화 하기 위해서는 지금이라도 프로젝트를 접거나 지금부터 설계를 새로 하여 재 작업을 하는 방법 밖에 안보이는 상황이였습니다.

 

이 프로젝트는 왜 이런상황이 되었을까요? 이런 상황이 발생하지 않으려면 어떻게 해야 할까요?

 

소프트웨어 위기 현상

소프트웨어 공학의 시작은 1968년 NATO 컨퍼런스에서 프리츠 바우어(Fritz Bauer) 교수가 '소프트웨어 위기'라는 용어를 사용하면서 시작되었다고 할 수 있습니다. 

소프트웨어 위기란?
컴퓨터 하드웨어 기술의 발전과 사용자의 요구사항이 다양해 지면서 해결해야 할 문제가 복잡해 졌으나, 상대적으로 소프트웨어 기술의 진보가 더딤

 

구체적인 현상을 열거하면 다음과 같다고 할 수 있습니다.

  • 개발 일정이 계획보다 지연된다.
  • 초과 비용이 발생한다.
  • 제품의 신뢰도가 결여된다.
  • 빈번하게 명세와 불일치하는 부분이 나타난다.
  • 품질 저하와 유지보수의 어려움이 생긴다.

 

이러한 현상을 야기시키는 주요 원인은 다음과 같다고 합니다.

  • 소프트웨어 공학의 훈련을 받은 전문 인력의 부족
  • 소프트웨어에 관한 경영층의 인식 부족
  • 방법론 및 지원 도구의 문제
  • 소프트웨어 개발 생산성 저하
  • 소프트웨어 자체의 복잡성 증가

 

여기까지 나열해 보니.. 폭망한 프로젝트은 이 모든 상황에 매칭이 되더군요.

 

'아.. 이 프로젝트는 망할 수 밖에 없는 운명이였구나...'

 

 

 

소프트웨어 공학이라는 용어는 최초 소프트웨어 위기 현상을 부각하려는 의도가 내포되어 있었습니다. 이 후 비용의 과다 지출, 신뢰성의 부족, 난해한 유지보수와 같은 소프트웨어 문제를 해결하려는 의도로 새로운 방식들이 논의되었고, 그 해결책으로 표현하기 위해 만들어진 용어가 소프트웨어 공학입니다.

 

신뢰성 있고 요구기능을 효율적으로 수행하는 소프트웨어를 경제적으로 생산하기 위해 건전한 공학적 원리와 방법을 만들고 사용하는 것

 

 

소프트웨어를 개발을 하다보면 요구사항이 관리가 안되서 재작업 한다던가, 개발 일정이 딜레이, 개발 프로그램 신뢰도 문제 등 다양한 상황으로 인해 개발비용이 초과되는 상황이 빈번히 발생합니다. 

 

SI 개발 환경에서는 이러한 상황이 생각보다 자주 발생하고 이로인한 법적 분쟁 상황도 종종 볼 수 있습니다. 

 

인하우스 환경에서는 개발 기간 지연으로 인한 인사고과에 악영향을 받겠죠?

 

 

소프트웨어 공학을 공부해야 하는 이유

소프트웨어를 개발한다는 것은 단순히 코드를 작성해서 릴리즈만 하면 끝나는 것이 아닙니다.

요구사항을 파악하고 이를 통한 설계와 개발, 테스트까지 일련의 프로세스를 모두 거쳐야 소프트웨어가 개발이 됩니다. 그러다보니 개발 과정에서  발생 되는 문제들을 개별적으로 해결한다고 개발이 완료되는 것이 아니라 전체적으로 리스크를 관리하여야 소프트웨어 개발이 완료되는 것 입니다.

 

결국 소프트웨어 공학이란 소프트웨어를 개발하는 환경에서 리스크를 어떻게 관리하여 좋은 소프트웨어를 만드는가에 대한 공학적 방법론을 제시하는 학문이며, 개발 업계에서 밥 빌어먹는 사람으로서 개발 능력도 중요하겠지만 그 개발 능력을 제대로 보여줄 수 있는 프로젝트 환경이 갖춰 질 수 있도록 소프트웨어 공학에 관심을 가져야 할 필요가 있습니다.

 

예를 들어, 개발자 입장에서 본인이 개발 실력이 정말 좋은데 투입된 프로젝트의 PM이 소프트웨어 공학에 대한 지식이 없다면 개발 실력이 아무리 좋아도 그 프로젝트는 망할 수 밖에 없을 겁니다.

 

또, 기획자 입장에서는 고객사 또는 사업부의 요청들에 이리저리 휘둘리다 정신차리고 보면 프로젝트가 망가져있는 상황을 볼수 있습니다.

 

그렇기 때문에 개인적으로 아니 기본적으로 PM/PL이라는 직무를 하시는 분들이라면 이 소프트웨어 공학이라는 학문에 대해 공부해야한다고 생각합니다.

 

 "아, 우리회사에는 적용하기 어렵겠는데?"

"개발자가 개발만 잘하면 되지, 이런것 까지 신경써야되나?"

 

이렇게 생각하시는 분들이 있을 수 있다고 생각이 되는데요. 우리들은 언젠가 PM/PL 업무를 볼 수 밖에 없는 상황이 올 태고, 지금 당장 적용하지 못 하더라도 개발 비용을 낮추기 위해, 또는 신뢰성을 확보하기 위해 고민하는 단계가 올 수 밖에 없습니다. 이 때 '아! 소프트웨어 공학이라는 분야가 있었지?"하고 생각이 난다면 절반은 목표를 달성했다고 볼 수 있겠습니다.

 

앞으로 제가 경험 했던 다양한 프로젝트 사례를 통해 소프트웨어 공학의 관점에서 바라보며 풀어보도록 하겠습니다.