소프트웨어 공학이 필요한 이유

소프트웨어 공학 🤔

 

더 좋은, 더 나은 품질의 소프트웨어를 만들기 위해서는 소프트웨어 공학을 공부해야 한다고 합니다. 대체 소프트웨어 공학은 무엇이고, 왜 공부하면 좋다고 말하는 걸까요? 단순히 프로그래밍만 잘 해도 되는 건 아닌걸까요? 이에 대한 의문을 해소하기에 앞서, 우리는 소프트웨어를 개발하는 환경을 생각해 봐야 합니다.

오늘날의 소프트웨어는 대부분 개인이 아닌 팀 단위로 개발됩니다. 그렇기 때문에 소프트웨어를 필요로 하는 고객도 있을테고, 다양한 팀원들도 있을 것입니다. 이렇게 규모가 있는 프로젝트를 진행하기 위해서 우리는 구현을 위한 기술력도 갖춰야 하고, 고품질을 위한 테스트도 해야 하며, 의사소통 또한 원활하게 할 수 있어야 합니다. 하지만 이를 위한 체계적인 프로세스가 없다면, 우리는 프로젝트 진행에 있어 전반적으로 큰 혼란을 겪을테고, 고객의 요구 사항을 만족시킬 수 없을 것입니다.

 

바로 이런 문제들을 해결하기 위해 소프트웨어 공학이란 것이 필요하게 됩니다. 소프트웨어 공학의 정의는 고품질의 소프트웨어를 만들기 위해 계획을 세우고, 개발하며, 유지보수하는 전 과정에서 도움이 되는 이론과 기술 및 도구에 대해 연구하는 학문입니다. 정의만 봐도 그렇듯 소프트웨어 공학의 목표는 결국 소프트웨어 개발의 생산성을 높이고, 고품질의 소프트웨어를 고객에게 제공하는 것임을 알 수 있습니다.

 

 

소프트웨어 개발 생명 주기 🔥

소프트웨어는 6가지 단계로 나누어 개발이 진행됩니다. 이러한 단계들을 통틀어 소프트웨어 개발 생명 주기(Software Development Life Cycle)라고 말합니다. 또한 이 생명 주기는 개발 프로세스(Development Process)이기도 합니다. 이러한 생명 주기를 어떻게 활용해서 소프트웨어를 만들어 나갈지 많은 고민을 하게 되는데, 이미 기존에 좋은 프로세스 모형들이 만들어져 있기에 이를 그대로 프로젝트에 적용하기만 하면 됩니다.

 

대표적으로 폭포수 모델(Waterfall Model)과 애자일 모델(Agile Model)이 있습니다.

 

자 그럼 각 단계에서 어떤 작업을 하는지, 무엇이 중요한지 정말 간단하게 살펴보겠습니다.

 

 

Planning (계획)

 

계획 단계에서는 개발에 필요한 비용(돈, 인력 등)을 산정하고, 전체적인 일정을 계획합니다. 소프트웨어 개발의 성패는 비용, 기간, 인력과 같은 자원을 토대로 초기에 얼마나 계획을 잘 세우느냐에 달려있습니다. 하지만 소프트웨어 개발은 비용과 같은 부분을 예상하기 어렵고, 또한 계획대로 끝까지 진행하는 것도 쉽지 않습니다. 그렇기 때문에 초기에 최대한 문제를 잘 정의하고, 비용도 산정하며, 위험까지 고려해야 합니다. 그래야 향후 완성될 소프트웨어의 품질을 높일 수 있고, 유지보수 비용까지 낮출 수 있습니다.

 

 

Analysis (요구 분석)

 

요구 분석 단계에서는 기존 시스템이 가지고 있던 문제들을 파악하고, 인터뷰와 같은 수단을 통해 사용자들의 요구 사항을 수집합니다. 이 단계는 전체적으로 어떻게(How) 구현할지보다, 시스템의 기능이 무엇(What)인지에 초점을 두고 있습니다. 그리고 이렇게 수집한 자료들에서 최종 요구 사항을 도출하여 문서화를 시키는 작업을 진행합니다.

 

요구 분석 단계의 최종 결과물은 문서화를 통해 생성된 요구 분석 명세서입니다. 문서를 작성하는 방법은 다양하지만, 소프트웨어 개발 쪽에서는 개체-관계 구조를 나타내는 ERD(Entity-Relationship Diagram)와 유스케이스 다이어그램(Usecase Diagram)을 통한 UML 표기법 등이 대표적인 모델로써 사용됩니다.

 

 

Design (설계)

 

설계 단계는 상위 설계(High-Level Design)와 하위 설계(Low-Level Design)로 나뉩니다.

 

상위 설계는 요구 분석 단계에서 작성된 명세서를 바탕으로 소프트웨어의 골격을 의미하는 아키텍쳐를 설계합니다. 잘 정의된 소프트웨어 아키텍쳐가 있으면, 좋은 품질의 소프트웨어를 만들어낼 수 있습니다. 아키텍쳐에 적용 가능한 모델에는 대표적으로 서버-클라이언트, MVC, 데이터 중심 같은 것들이 있어, 프로젝트의 상황에 맞게 스타일을 적용하면 됩니다. 그리고 자주 사용되는 설계 형태를 정형화해서 템플릿화해 놓은 디자인 패턴(Design Pattern)도 적용하여, 효율성과 재사용성을 높일 수 있습니다.

 

하위 설계는 상세한 내용들을 모듈화하는 단계입니다. 모듈은 실제로 개발할 수 있는 최소한의 단위이며, 독립적으로 컴파일되고, 모듈에서 또다른 모듈을 호출할 수 있는 것을 말합니다. 현실 세계에서도 해결하기 어려운 큰 문제를 잘게 쪼개서 하나씩 해결하는 것처럼, 모듈도 비슷한 예라 봐도 좋을 것 같습니다.

 

 

Implementation (구현)

 

구현 단계는 실질적으로 프로그래밍을 하는 단계이며, 프로젝트를 함께 진행하는 팀원들간 지켜야할 코딩 규칙을 정하는 단계이기도 합니다. 개발자마다 코딩 스타일이 모두 다르기 때문에, 이를 정하지 않으면 코드의 가독성이 좋지 않고, 생산성마저 떨어지는 문제가 발생합니다. 프로그래밍 언어마다 표준으로 제시하는 스타일 가이드들이 있지만, 이는 팀마다 다르니 유의해야 합니다.

 

 

Testing (테스트)

 

테스트 단계는 측정 도구나 장비를 이용해 구현된 소프트웨어에 이상이 없는지, 사용자를 만족시킬 수 있을지를 테스트하는 단계입니다. 테스트는 기본적으로 계획, 설계, 측정, 분석, 수정의 절차로 진행되는데, 종류가 너무나 다양하기 때문에 상황에 맞는 기법을 잘 적용해서 테스트해야 합니다.

 

 

Maintenance (유지보수)

 

현실 세계에서도 그렇듯 무엇인가 오래 사용하면 문제가 발생해 수정이 필요한 경우가 찾아옵니다. 소프트웨어도 동일한 상황이 발생하기 때문에 유지보수가 필요합니다. 하지만 차이가 있다면 소프트웨어는 사용자가 사용하자마자 문제가 발생할 수도 있습니다.