소프트웨어 시스템 구현시 부딪히는 어려움

 

목차

구현 (Implementation)

시스템 구현 단계에서는 설계의 결과를 사용자가 이용할 수 있는 모 습으로 변환시킨다. 구현은 앞의 설계 단계에서 나온 설계 도면(설계 명 세서)을 시스템의 실제 모습으로 변환시키는 것이며, 이러한 과정을 통해 시스템의 기능이 수행가능한 모습으로 나타난다. 이 과정은 건축의 시공단계에 해당하며 설계가 세부적인 방법으로 수 행되어, 그 결과물로 건축물에 해당하는 소프트웨어 제품이 나온다. 소프 트웨어 시스템의 경우, 구현은 프로그래밍 또는 코딩이라고 불리며 설계 명세서를 컴퓨터가 알 수 있는 모습(프로그래밍 언어로 표시)으로 변화시 키는 것이다. 프로그래밍의 결과는 컴퓨터 프로그램이다. | 건축의 경우, 구현 과정이 설계 이전의 과정보다 비용이 많이 든다. 이는 시공을 하기 위해 구입해야 하는 많은 기자재 값과 임금 때문이다. (일반적으로 전체 비용의 80~90%가 시공에 투자된다). 반면 소프트웨 어 시스템은 구현에 필요한 기자재나 장비가 많지 않아 시스템 개발 과정 중 프로그래밍에 드는 비용은 평균 20% 정도이며 40~50%의 비용이 요 구사항 분석과 설계에 들어간다. 이 비율은 소프트웨어 개발시 요구사항 분석과 설계가 가지는 중요성을 단적으로 보여준다.

소프트웨어 시스템 구현시 부딪히는 어려움은 대부분 분석과 설계의 잘못에 의한 것이고 설계가 제대로 이루어지면 시스템 구현은 상대적으로 단순해지고 기계적인 과정이 되어 매우 효율적으로 진행될 수 있다. 따라 서 건축의 경우와는 달리 소프트웨어 개발과정에서는 구현 이전의 요구사 항 분석과 설계에 많은 시간과 노력이 투입되어야 한다. 그러나 우리 나라의 현실은 소프트웨어 시스템 개발 과정에서 분석과 설계에 대한 노력 없이 직접 프로그래밍에 돌입하는 경우가 많아, 상대적 으로 프로그래밍에 더 많은 노력을 투자한다. 이는 도면 없이 건물을 짓 는 것과 같이 위험한 일이다. 결과적으로는 프로젝트의 후반부에 가서 사 용자 요구사항이 많이 추가되어, 만들어 놓은 시스템에 엄청난 수정이 가 해지게 된다.

어떤 엔지니어들은 이런 고백을 한다. “우리 매니저는 앉아서 생각하 고 조사하는 것을 보면 놀고 있는 것으로 생각한다. 열심히 프로그래밍을 해야 무엇인가 생산적인 일을 하는 것으로 생각한다.” 이러한 소프트웨어 개발 현실에 대한 지적을 들으며 우리의 엔지니어링 문화도 이제는 행동 에 옮기기 전에 심사 숙고하는 과정의 중요성을 인식하는 것으로 바뀌어야 한다고 생각한다. | 작은 규모의 시스템을 만들 때는 요구사항 분석이나 설계가 요하지 않을지 모른다. 그러나 시스템이 커지면 상황은 달라진다. 딩을 짓는다고 생각해 보자. 초가집을 짓던 공법으로 63빌딩을 지을 스 있겠는가? 같은 개념으로 “오천 줄 크기의 시스템을 만들던 공법이 . 만 줄 크기의 시스템을 만들 수 있겠는가?” 작은 시스템을 개발하며, 끼지 못했던 많은 문제점들이 큰 시스템 개발 과정에서 도출되며 체계제 인 공법 적용의 필요성을 절감하게 한다.

프로그래밍을 건축에서의 목수나 미장이들이 하는 일이라고 한다면 지나친 말일까? 우리 나라에는 훌륭한 프로그래머가 많이 있다. 프로그래 밍 기술은 세계 어디에 내 놓아도 손색이 없다. 그러나 여전히 많은 시스 템 개발을 외국에 의존하는 이유는 사용자 요구사항과 문제점을 정의하는 기술, 즉 사용자 요구사항을 철저히 분석하고 또 그것을 설계화할 수 있 는 능력이 부족하기 때문이다. 따라서 이러한 실력이 갖추어지면 우리도 크고 훌륭한 시스템을 만들 수 있게 될 것이다. 프로그래밍에 들어가기 전에 사용자 요구사항을 뽑아 내고 설계할 수 있는 숙련된 엔지니어들이 많이 배출될 때 우리 나라 소프트웨어 산업, 정보통신 산업의 미래는 보 다 밝아지게 될 것이다. 

시험(Testing)

어느 제품이든 품질에 대한 중요성은 아무리 강조해도 지나치지 않는 다. 우수한 품질의 제품을 얻기 위해서는 제품이 개발되는 공정 과정(고 구사항 분석, 설계, 구현 등)마다 품질 보증을 위한 절차를 따라야 하고, 공식적인 검토회 등을 통하여 잘못된 것을 걸러내는(filtering) 작업이 수행되어야만 한다. 시스템 개발 과정에서 시스템 시험은 품질보증 활동의 중요한 일부분이며, 사용자 요구사항, 설계, 구현의 전 과정에 대한 최종 점검을 포함한다. 시험은 제품의 오류를 발견하고 수정하는 과정이다. 시험을 하지 않았을 때 나타나는 문제점과 이를 시정하는 데 요구되는 과다한 비용을 생각해 보면, 시험하는 데 드는 비용의 정당성을 찾을 수 있다.

시험은 시스템 개발 전체 과정에 대하여 체계적으로 점검할 수 있는 일 련의 활동들의 집합이다. 시스템 시험은 건축 공학의 경우 감리에 해당하는 부분이다. 건축의 감리는 법적 절차로서 설계 도면대로 시공되었는가를 검 사한다. 그러나 소프트웨어 시스템 시험은 사용자 요구사항, 설계, 그리고 코 딩의 전 과정에 대한 점검이며, 소프트웨어 개발 비용 중 40% 이상을 차 지하는 경우가 흔히 있다. 체계적인 소프트웨어 시스템 테스트를 하기 위 해서는 테스트 계획(test plan)이 만들어지는데, 이 문서에는 시험 진행 단계, 시험에 사용되는 데이터 및 시험의 한계점 등이 기술되어야 한다. 테스트 계획은 최소한의 시간과 비용을 투자해서 최대한의 확률로 오류를 찾아낼 수 있도록 만들어져야 한다.

미국 프로그래머의 몰락

소프트웨어 분야의 유명한 저자이며 구조적 분석 및 설계기법 창시자 중의 한 사람인 Edward Yourdon은 「미국 프로그래머의 몰락(Decline & Fall of the American Programmer) | (YOU 93]이라는 책에서 다음과 같이 주장하고 있다. 미국의 공룡과는 낮은 생산성과 품질로 말미암아 옛날 중생대의 맞이하고 있다. 1990년대로 진입하면서 많은 소프트웨어 개발이 미국에서 다른 나라들로 이동되고 있다. 특히 잘 교육된 인력을 보유하 고 있고 비용이 적게 들며, 열정적으로 품질과 생산성을 높이는 데 주력할 수 있는 인도, 중국을 비롯한 10여 개의 국가들로 중점적으로 옮겨가고 있다. 이들 국가들은 미국의 5% 내지 10%도 안 되는 싼 인건비와 우수한 노동력을 제공하고 있다.

그러나 미국의 소프트웨어 산업이 1990년대의 앞서가는 소프트웨어 기술들을 제대로 활용한다면 생산성과 품질 면에서 계속 우위를 점유할 수는 있을 것이다. 그렇지 못한 많은 기업은 21세기가 시작하기 전에 존재하지 못하게 될 것이다. 2000년이 시작하기 전 많은 미국의 프로그래머는 직장을 잃게 될 것이다. 그 이유 는 1970년대 미국의 자동차 산업이 일본과의 경쟁에서 수모를 당한 것과 마찬가지 이며, 미국의 프로그래머들은 국내적인 요소보다는 국제적인 경쟁으로 말미암아 더욱 어려움을 겪게 될 것이다.

현재 각 회사에서 소프트웨어에 투자하는 비용은 많은 비중을 차지하고 있지 않다. 그러나 소프트웨어가 잘못 만들어지면 시스템이 마비된다. 이제 소프트웨어는 회사의 존재와 직결되는 중요성을 가지고 있다. 만약 기업이 우수한 소프트웨어 엔 지니어를 보유하고 있으면 그렇지 못한 기업보다 결정적인 우위를 점유할 수 있다. 경쟁 기업보다 우수한 인력을 보유하지 못한 기업은 결국 문을 닫게 될 것이다. 세 계 일류 기업과 문을 닫아야만 하는 기업의 차이는 직원에게 소요되는 비용, 즉 월 급과 혜택, 직원의 생산성, 개발된 시스템의 품질에 의해 결정된다.

불행히도 이제 프로그래머가 일하는 장소는 점점 문제시되지 않는다. 언어의 장벽이 무너져 가고 있으며 프로그래머는 통신의 발달로 인공 위성을 통해 세계 어 디에 있든지 사용자 및 고객과 통화할 수 있게 되었다. 미국의 경우, 옛날 대영제국 의 식민지였던 많은 나라들이 영어 문화권을 형성하고 있고 이들의 교육 시스템이 훌륭하여, 손쉽게 소프트웨어 개발 비용을 절감할 수 있다. 미국 소프트웨어 엔지니어가 살아남고 소프트웨어 분야에서 세계 일류 기업이 되기 위해서는 다음과 같은 6가지 즉, 실제 적용할 수 있는 기술을 활용하여 소 트웨어를 개발하지 않으면 안 된다.

유지보수 시스템의 4단계

Yourdon의 주장을 들으며 우리보다 앞서가는 기술력을 가진 나라의 배부른 외침이라고 생각할 수도 있으나 그들이 어떻게 앞날을 준비하고 있는가를 배울 수 있다. 한국의 인건비 는 지난 수년간 급상승하여 이제 인건비로 경쟁할 수 있는 시대는 지나갔다. 이 책은 앞으 로 우리가 어떻게 치열해지는 국제 경쟁에 대한 준비를 해야 하는가를 보여주고 있다. 유지보수(Maintenance) 시스템은 앞의 4단계를 거쳐 개발되어진 뒤 고객에게 배달되어 사용 된다. 사용자가 제품을 사용하면서 유지보수 과정을 거치게 된다. 제품의 유지보수는 사용 중 발생하는 여러 변경 사항에 대해 적응하는 활동이며 변화에 대비하는 과정이다. 소프트웨어 유지보수는 다음 4가지 활동으로 요약될 수 있다.

• 잘못된 것을 수정하는 유지보수(corrective maintenance)
• 시스템을 새 환경에 적응시키는 유지보수(adaptive maintenance)
• 새로운 기능을 추가하는 유지보수(perfective maintenance)
• 미래의 시스템 관리를 위한 유지보수(preventive maintenance)

소프트웨어 시스템의 유지보수를 위해서는 시스템 변경에 의한 재 요 구 분석, 재 설계, 재 구현, 재 시험이 필요하게 되고, 관련된 문서의 수 정까지도 수반해야 하기 때문에 체계적인 관리 기능이 필요하다. 소프트웨어 시스템이 눈에 보이지 않아 말랑말랑하고 유연성이 있다고 생각하여 언제나 쉽게 바꿀 수 있다고 생각하기 쉽다. 소프트웨어가 건축 이나 다른 공학에 비해 그 이름(소프트)에서 보이듯 유연성을 가지고 있 는 것은 사실이나 흔히 그 유연성이 너무 남용되어 결국 유지보수가 불가 능한 상황까지 가는 경우가 대부분이다.

엔트로피 법칙

물리학에서는 열역학 제2법칙을 엔트로피(entropy) 법칙이라고 한다. 엔트로피는 열역학 적 상태를 나타내는 것으로, 통계학이나 정보 분야에서는 시스템 안에 존재하는 유용하지 못한 에너지의 척도, 불확실성, 또는 부정확한 정보의 양을 나타낸다. 엔트로피는 무질서의 정도를 표시한다고 볼 수 있으며, 엔트로피가 높으면 무질서의 정도가 심하고 엔트로피가 낮으면 질서가 잡혀 있다고 말할 수 있다.

그러나 무질서해 보이는 자연 현상 속에서도 질서는 엄연히 존재한다. 그러한 질서를 유지시키거나 엔트로피가 낮은 상태로 가기 위해서는 에너지를 필요로 한다. 예를 들어 우 리의 몸은 질서를 가지고 움직이는 시스템이며, 그 질서를 유지하는 데 많은 에너지가 요구 된다. 우리가 음식을 섭취하고 호흡하는 것도 에너지를 공급받아 몸의 질서를 유지하기 위 해서이다. 만약 사람이 죽으면 질서를 유지시켜 주던 에너지를 공급받지 못하게 되고 엔트 로피가 증가하는 무질서의 상태로 변화하여 결국 썩어서 분해된다.좋은 것은 실천하기 어렵고 나쁜 것은 노력 없이도 쉽게 배워 행하게 된다. 우리가 나 쁜 일(짓)을 하려고 하면 노력과 에너지는 별로 요구되지 않는다. 그러나 뛰어난 작품을 만든다거나 남을 돕는 등의 좋은 일을 하려 들면 힘이 들고 많은 에너지가 필요한 이유는 무엇일까? 외국 문화가 들어오는 경우에도 외국의 저급 문화와 나쁜 점들은 빨리 소개되고 퍼져나가고, 좋은 점, 교훈적인 내용은 제대로 배우지 못하는 경우가 대부분이다. 자연 법 칙과 연관지어 생각해 보면 나쁜 일을 하는 것은 엔트로피가 증가하는 무질서로 나가는 것 이므로 힘들지 않고, 착한 일을 하거나 좋은 것을 배우는 것은 엔트로피를 줄여 질서를 잡 아가는 것이라 많은 에너지와 노력이 필요하다. 

좋은 시스템을 만든다는 것은 무질서에서 새로운 질서를 잡아 나가는 것이고. (無)에서 유(有)를 창조하는 것처럼 많은 에너지를 요구한다. 에너지를 효과적으로 여 엔트로피를 줄이지 않고는 응집도가 높은 좋은 시스템을 만들 수 없다. 높은 품질이 스템은 우리의 높은 기술력과 많은 에너지를 요구한다. 소프트웨어의 경우에도 시도 눈에 보이지 않고 개발과정이 측정하기 어려려운 까닭에 다른 공학보다 엔트로피(므지, 의 통제가 더욱 어렵고 에너지를 효과적으로 사용하기 힘들다. 에너지는 비생산적인 지 낭비되지 않고 실제 문제를 해결하는 데 사용되어야 한다. 시스템을 개발하며 에너지 나 를 줄이고 엔트로피를 최소화시킬 수 있는 기술력을 제공하는 것. 이것이 소프트웨어 개반 방법론의 목적이 아닐까?

또한, 앞으로 국제적인 보호 장벽이 없어지고 정부의 규제도 없어져 각 개인이나 다 가 스스로에 대해 결정을 하고 책임을 지는 자율화 시대로 돌입하면 점점 경쟁이 가열되리 라 예상된다. 경쟁이 심화되면 경쟁에 영향을 미치는 다양한 변수에 대한 제어가 어려워져 위험 부담이 확대되고 불확실성, 즉 엔트로피가 증가한다. 이제는 앞으로 예상되는, 엔트로 피가 높은 사회에 대비할 수 있는 경쟁력을 갖추기 위하여 우리 모두가 지혜를 모아야 할 때이다.

요약

엔지니어링의 기본 원칙은, 수행되는 임무에 의해 개발 과정이 분리 되어 있어야 한다는 점이다. 이 장에서는 소프트웨어 개발의 경우 필요한 요구사항 분석, 소프트웨어 설계, 프로그래밍, 시험 및 유지보수로 이어 지는 라이프 사이클에 대하여 알아보았다. 요구사항 분석과정에서는 사용 자에게 제공해야 할 기능을 정의하고, 설계 단계부터는 요구사항에서 청 의된 기능을 어떻게 개발할 것인가에 초점을 맞춘다. 이 두 단계는 서로 수행하는 기능이 다르다. 따라서 소프트웨어 시스템 개발도 요구사항 분 석과정과 설계를 포함한 개발 단계가 분리되어야 하며 이를 통해 높은 품 질의 소프트웨어를 만들 수 있다. 소프트웨어 공학은 개발 계획과 진행에 있어 단계별로 수행되어야 하는 임무를 가지고 있으며, 프로젝트 중간 단계에서 나타나는 산출물 (deliverable)을 요구하고 있다. 요구사항 명세서, 설계 명세서, 프로그 램 등이 바로 각 공정 과정의 산출물이며 중간 목표들이다. 중간 목표를 설정하고 목표 달성을 위해 각 과정을 성실히 수행해 나갈 때 최종 목표 인 고품질의 소프트웨어가 만들어진다. 엔지니어는 이 점을 생각하며 각 중간 목표에 대한 철저한 검증을 통해 잘못된 것을 여과하는 작업이 수행 해야 한다.

현재 우리 나라는 정부 및 기업체를 중심으로 많은 비용을 투자하여 대규모의 정보 시스템, 통신 시스템들을 구축하여 나가고 있다. 이런 시 스템들은 미래 우리 사회를 지탱하는 중요한 기간 시스템들이 될 것이다. 그러나 우리는 추구하는 정보화 사회의 중요 시스템들을 잘 구축하고 있 는지 자문해 볼 필요가 있다. 큰 병원과 건물을 지을 때 요구사항을 철저 히 분석하고 설계한 후 땅을 파헤치고 공사를 하는 것과 마찬가지로 이러 한 기간 소프트웨어 시스템 개발도 탄탄한 계획과 절차에 의해 구축하여 야 하며, 이를 등한시 하였을 때 우리 후손들과 후배 엔지니어들이 겪을 고초가 막대하다는 것을 알아야 하겠다.

우리는 건축에서 삼풍 백화점과 성수 대교 붕괴 사건을 보며 기초가 취약할 때 겪어야 하는 피해가 얼마나 큰 것인가 하는 것을 교훈으로 얻 고 있다. 우리가 소프트웨어 시스템을 체계적으로 만들 때 소프트웨어 분 야에서도 이러한 사고가 일어나는 것을 방지할 수 있고, 앞으로 다가올 무한 품질 경쟁 시대에 외국과 겨룰 경쟁력과 기술력도 축적할 수 있다.

처음부터 올바르게 만들지 않고는 품질 개선 노력과 품질 보증 활동이 성공적으로 이루어질 수 없고, 고품질의 제품과 서비스로 고객의 욕구를 만족시킬 수 없다. 아직도 많은 소프트웨어 엔지니어들이 사전 문서 작업 이나 체계적인 공법에 대한 인식 없이 직접 프로그래밍에 들어가고 문서 는 나중에 보고서를 겸해 만든다는 현실을 보며, 이렇게 만드는 소프트웨 어 제품은 아직도 품질과 거리가 멀어 품질이라는 말이 적용되지 못한다. 는 안타까움을 느끼게 된다. 더욱 심각한 것은 각 기업에서 소프트웨어 시스템의 품질 보증을 위한 공정 과정과 품질 관리 체계를 제시, 고 품질 관리를 개인의 역량에 맡기고 있다는 것이다.

개발자가 관리하 지 않게 느껴질 수도

소프트웨어 시스템을 혼자 개발하고 그 이후에도 그 개발, 는 경우에는 소프트웨어 공학의 개념이 별로 필요하지 않게 느껴 있다. 소프트웨어 공학의 많은 주요 원칙들은 여러 사람이 모여 큰 젝트를 하는 경우에 특히 요구되는 지침들이기 때문이다. 그러나 모든 소프트웨어 엔지니어들과 관리자들이 소프트웨어 개 요구되는 체계적인 공정 과정에 대한 중요성을 인식하고 그것을 시 옮기고 정부나 기업에서도 제도적으로 그 공정 과정을 지원해 줄 때 이 리의 소프트웨어 개발 기술은 성장할 수 있다. 이와 함께 생산성 향상과 기업의 경쟁력 강화에 이바지하게 될 것이다.