(위 사진은 USC Viterbi Server Room이며, 실제 금융기관의 메인 컴퓨터가 들어 있는 컴퓨터실과는 많이 다르다. 금융기관의 컴퓨터 실은 메인 중앙에 IBM 컴퓨터 CPU 유닛이 2개 있으며, 그 주위에 조그만 가지각색의 서버가 약 500여개 있다)
제가 프로그램 개발과 관련하여 알고 있는 지식은 크지 않습니다. 왜냐하면 저는 큰 조직에서 일반 업무를 담당하는 직원이었고, 이 업무관련해서 몇번 전산개발업무에 참여한 경험이 있기 때문입니다.
어쨌든, 대다수 업무를 보는 직원들은 프로그램을 사용하기는 하지만 프로그램을 직접만들어본 경험은 많지 않기에, 제가 가지고 있는 작은 경험 일지라도 참고하실 수 있도록 여기에 사적인 의견을 적어놓습니다.
우선, 프로그램은과 음식물과 매우 비슷합니다. 현대에는 모든 사람이 만들어진 프로그램을 선택해서 사용하고 있습니다. 카카오톡, 쿠팡, 엑셀, 아래한글 등 이런 훌륭한 프로그램 덕택에 편리하고 쉬운 생활을 유지합니다. 마찬가지로 점심을 먹기 위해서 사무실만 나가면 선택할 수 있는 다양한 음식이 있습니다. 즉, 사용자는 아래한글이 어떻게 만들어 졌는지 알지는 못하지만, 매일 사용하고 있습니다. 내가 어제먹은 김치찌게를 나는 만들줄은 모르지만 맛있는지는 알 수 있습니다.
점심에 먹을 음식도, 수많은 시행착오 및 경험을 통해서, 어디서 먹으면 후회하지 않는다는 사실을 만들어 놓고 있습니다. 역시 프로그램도 MS오피스에서 만든 엑셀을 사용하고, 아래한글을 사용한 경험이 있기에 프로그램 눈 높이 척도도 높은 편입니다.
하지만, 자신이 매일 먹는 맛집의 김치찌개를 자신이 스스로 만들어 먹는다면 그 맛에 버금가는 음식 만들기가 가능할까요? 김치찌개를 만들때 알아야할 점이 10가지라면, 프로그램 개발을 위해서는 100가지 정도를 알아야 합니다.
▲개발하는 프로그램을 개발자가 얼마나 이해할 수 있을까?
그래서, 큰 기업에서 프로그램 개발할 때 다음과 같은 팀으로 구분해서 개발을 시작하게 됩니다.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
위에 표에서 보다시피, 전산 개발에서 가장 중요한 것은 얼마나 전산을 이해하고 있느냐 보다는, 얼마나 업무를 이해하고 있느냐가 전산개발에서 성공을 결정하는 중요한 요소입니다.
실제 프로그램이 필요한 발주 업무팀 직원은 업무는 잘 알고 있지만, 이것을 어떻게 프로그램으로 만들 수 있는지?를 모르기 때문에 무작정 많은 요구사항을 나열하게 됩니다. 요구사항을 실제 프로그램으로 전환하는 외주 개발팀 직원은 업무의 중요도나 우선순위를 모르기 때문에 나열된 요구사항을 만들기에 급급합니다. 그래서, 발주 전산팀의 역할이 중요하지만 발주 전산팀 직원들 또한 업무지식은 부족하기에 실제 업무팀 직원들이 필요한 내용을 이해하고 있지 않습니다. (단, 대부분 프로그램을 개발한다고 하면, 쉬운 업무는 없습니다. 쉬운 업무라고하면 프로그램 개발을 시작하지도 않고, 필요했다면 벌써 만들어서 사용하기 때문입니다.)
어떻게 진행되번 프로젝트 기간을 연장해서라도 프로그램이 완성되고, 그 프로그램은 런칭됩니다. 당연히 프로그램 개발 완료 보고를 하게되고, 자체 평가에서는 개발된 프로그램에 우수한 평가를 부여합니다.
하지만, 전산부에서 최근 1년동안 100건의 프로그램을 개발했다면, 각각의 프로그램 실제 사용이 6개월 정도 지나면 실제 사용자(업무팀 또는 그 업무팀과 관련있는 직원들)의 불만과 불평이 나오기 시작합니다. 이렇게 만들거면 왜 만들었냐가 주 불만입니다. 그래서 100건 중 30%는 폐기됩니다. (연구결과 70%가 실패라고 보는 곳도 많이 있습니다. ‘여전히 70%가 실패’… IT 프로젝트의 복병 10가지 https://www.ciokorea.com/news/220579)
▲ 비전문 현업부서(발주 업무팀) 직원의 개발 참여
위 도표에 그림과 같이 프로젝트는 현업부서(업무팀), 현업부서(전산팀), 외주개발팀으로 구성되며, 현업부서(업무팀)의 요건정의를 현업부서(전산팀)에서 분석하여 외주개발팀으로 의뢰하는 형식입니다..
단, 현업부서(업무팀)의 구성인원은 업무에 능숙한 전무직원이어야 하나, 부서장의 단기 실적주의 때문에 현직업무에서 주변업무를 담당하는 비교적 한가한 직원을 파견하여 개발 프로젝트에 참여시키는 경향이 있습니다.
개발에서 가장 중요한 부분을 담당하는 현업부서의 직원이 무능하다면 그 프로젝트는 시작과 동시에 실패를 합니다.
▲개발하는 프로그램의 복잡성
우리가 점심을 먹으면서 그 음식의 맛을 평가하는 것처럼, 프로그램을 사용하면서 장. 단점을 이야기 합니다. 장.단점을 알고 있다고 해서 프로그램을 개발 할 수 있게되는 것은 아닙니다. 음식을 만드는 것과는 비교할 수 없을 정도로 복잡하며 많은 비용이 드는 것이 바로 프로그램 개발입니다.
예를 들어 단순한 회사 홍보용 홈페이지 만들때 고려해야 할 사항도 다음과 같습니다.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
즉, 하나의 프로그램 개발을 위해서는 다양한 전산 지식 뿐 아니라, 해당 회사에서 필요한 내용을 이해하는 업무지식도 필요합니다. 물론 이런 개발자가 없는 것은 아닙니다. 문제는 이런 사람은 2023년 기준해서 최소 연봉이 1억원을 초과하고, 이런 인원이 투입되는 프로그램 프로젝트는 3달만 이 사람 1명이 개발한다고 하더라도 최소 5천만원 입니다.
▲개발하는 프로그램의 범용성
만약 개발하는 프로그램을 개발하고 난 후에 이 프로그램을 다른 회사에 판매가 가능한 경우에는 개발회사 입장에서 투자로 생각하고 개발비용을 줄일 수 있습니다. 반대로, 동 프로그램 개발 후 더 이상 수익이 발생하지 않는 경우에는 개발 자체를 꺼려할 수 도 있습니다.
▲개발 업체의 상업주의
개발업체(SI업체)는 난립 중입니다. 초기 자본이 필요없는 인력파견업이기 때문입니다. 프로젝트의 완성도 보다는 일단 수주후에 어떻게하더라도 마무리 짓자는 자세입니다. 어떻게 보면 프로젝트를 수임해야지만 직원들 월급도 줄수 있고, 또 타 개발사와 협업해서 새로운 기술도 익힐 수 있기 때문에 약간 무리해서라도 개발에 참여하고 싶어합니다.
이런 욕구는 발주처의 무리한 요구사항을 조율없이 할 수 있다고 저가 수주하는 것 입니다. 당연하게도 실제 개발에 들어가면 무리한 요구는 개발할 수 없게 되거나 발주처의 의도와 다른 결과로 프로젝트가 끝나게 됩니다.
만약에 발주처가 대외 신인도가 있는 회사라면 그 회사이름을 위해서 비록 저가라도 개발업체는 참여하려고 하며, 그 결과물은 완성도가 떨어지게 됩니다.
▲ 프로그램 개발의 종료는 없습니다.
프로젝트의 끝은 끝이 아니라 시작입니다. 제대로 만든 프로그램이면 사용자들은 그 프로그램을 계속사용하길 바라며, 그 프로그램의 장. 단점을 바로 알게 됩니다. 즉, 사용자들이 더 개선해서 업무에 도움이 될 수 있는 가능성을 진단하고 요구하게 됩니다.
즉, 이전에 하던 방식과 다른 방식으로 업무에 접근하는 자세를 갖게되며 그런 생각은 업무의 효율성을 배가 시킵니다. 업무팀과 개발팀의 소통으로 탄생한 프로그램은 종료와 동시에 또 다른 시작을 하게됩니다.
다음에는 실패한 프로젝트(프로그램 개발)에 관해서 제가 느끼고 경험한 것들을 적어 보도록 하겠습니다.
다시 한번더 말씀드리지만, 위에 기술한 것들은 비 전문가인 제가 전산 프로그램 개발 프로젝트를 하면서 개인적으로 느낀 것들 입니다. 제 개인적인 생각은 일반적인 의견과 다를 수 있음을 다시 상기해 주세요. 감사합니다..
많은 도움이 되었습니다.