[소프트웨어공학] 2. 소프트웨어 공학의 의미

소프트웨어

소프트웨어라고 하면 제일 먼저 생각나는 것은 소스 코드일 것이다.

하지만 소프트웨어는 바이너리 코드 외의 요소도 포함하는 개념이다.

 

소프트웨어는 다음 요소를 포함한다.

 

- computer program

바이너리 코드 자체

 

- configuration files

.env 파일에 따라 동작이 달라지는 스프링 앱, 프로그램의 설정 값 등

 

- system documentation

소프트웨어를 개발하는 과정에서 나오는 결과물들

요구사항 분석 후 나온 스펙 문서, 설계하면서 나온 디자인 문서, 구현, 테스팅 관련 문서들

(테스트를 어떻게 할 지 세운 계획, 테스트 케이스에 대한 문서, 버그 수정 리포트 등)

이처럼 소프트웨어를 개발할 때는 소스코드 뿐만 아니라 다양한 문서들도 함께 나오며, 이것들도 소프트웨어에 포함된다.

즉, 소프트웨어를 개발한다는 것은 document 를 만드는 개념까지도 포함된다.

 

- user documentation

소프트웨어를 사용하는 방법을 기술한 사용자 메뉴얼

소프트웨어를 어떻게 사용해야 하는지 설명할 때는 소프트웨어를 만든 개발자가 관여하지 않을 수 없다.

 

---

 

소프트웨어의 종류

새로운 소프트웨어를 만드는 방법은 크게 2가지가 있다.

완전히 0에서부터 만드는 방법 / 기존의 소프트웨어를 재사용하는 방법

 

그리고 이렇게 만들어진 소프트웨어는 크게 3가지로 분류할 수 있다.

 

- Generic Software

일반적인 목적으로 만드는 소프트웨어를 말한다.

그래서 어떤 고객이든 자신이 원한다면 이 소프트웨어를 누구나 살 수 있다.

(특정 분야의 고객을 대상으로 하는 것이 아니라 모든 고객을 대상으로 하는 소프트웨어)

ex) MS Office, 아래 한글, CAD 소프트웨어

 

- Customized

특정 고객을 겨냥하여 만든 소프트웨어

고객사의 요구에 맞추어 만든 소프트웨어를 말한다.

ex) 이커머스 소프트웨어(쿠팡), 실시간 교통 정보 추적 소프트웨어

 

- Both generic and customized

실제로는 이 양쪽에 모두 해당되는 경우가 많다.

ex) ERP software (모든 회사가 필요로 하는 공통 부분을 개발해두고, 회사마다 필요한 부분을 커스터마이징해서 제공)

 

실제로 사용하고 있는 소프트웨어도 한번 분류해보자.

- 헤이영 : Generic and Customized, 기본적인 기능은 공통적으로 개발해두고, 학교마다 커스터마이징 해서 제공

- 클래스룸 : Generic, 공통 기능만 있고, 커스터마이징 된 기능은 없다. (우리 학교에서 안 쓰는 기능이 너무 많다.)

- 클래스넷 : Customized, 우리 학교에 맞춰서 디자인하고 기능을 개발했다.

 

Generic Software 와 Customized Software 의 차이는 개발자 관점에서는 스펙을 결정하는 주체로 분류할 수 있다.

Generic Software 는 모든 고객들이 필요로 할 만한 기능을 개발자가 결정해서 개발한다.

Customized Software 는 고객이 필요하다고 결정한 기능을 개발자가 개발한다.

 

 

소프트웨어 공학

소프트웨어 공학은 소프트웨어를 생산하는 것과 관련된 모든 내용을 포함하는 개념이다. (개발 이론, 방법, 도구 등등)

그리고 특히 cost-effective한 소프트웨어 개발과 관련이 있다.

 

엔지니어링은 굉장히 실용적인 분야이다.

이론만 파는 것이 아니라 실제로 응용이 가능해야 한다는 뜻이다.

화학과와 화학공학과는 둘 다 화학과 관련이 되어있지만, 전자는 순수화학에 가깝고 후자는 물리에 가깝다. (자연과학과 공학의 차이)

화학과와 같은 자연과학 분야의 목적은 discovery, 새로운 사실을 발견하는 것이 목적이다.

반면 화학공학과와 같은 공학의 목적은 invention, 새로운 것을 만들어내는 것이 목적이다.

 

예를 들어 신물질을 발견하였는데, 이 물질이 바이러스도 차단하고, 황사도 차단하고, 가볍고, 방수도 잘되고 너무 좋은 물질이라고 해보자.

자연과학 분야에서는 이 물질을 발견한 것만으로 이미 목적을 달성했고 매우 만족한다.

하지만 공학자들은 이 물질을 가지고 새로운 무언가를 만들어낼 수 있어야 만족한다.

그런데 만약 이렇게 좋은 물질의 가격이 1억원이라고 한다면, 실용적인 무언가를 만들어서 많은 사람들에게 보급하기가 힘들다.

이런 상황에서 공학자들의 고민이 시작된다. 즉, 공학은 cost, 비용에 대한 고민을 무조건 해야 한다.

비용과 퀄리티 사이에서 저울질을 하며 최적의 적정선을 찾는 것이다.

 

cost-effective 하다는 것이 바로 이런 뜻이다.

같은 가격일 때는 더 높은 퀄리티를, 같은 퀄리티라면 더 낮은 가격을 추구하는 것이다.

이런 고민이 없으면 공학(엔지니어링)이 아니다.

그리고 이런 고민을 소프트웨어에 적용하는 것이 소프트웨어 공학이다.

같은 비용으로 더 퀄리티가 좋은 소프트웨어를 만들고, 같은 퀄리티의 소프트웨어를 더 낮은 비용으로 만들고자 하는 것이다.

(이때 비용에는 개발 시간, 개발 비용, 필요한 컴퓨터 리소스, 실행 시간 등이 모두 포함된다.)

 

---

 

점점 기존 산업의 많은 부분들이 디지털로 전환되기 시작하면서 다양한 소프트웨어의 수요가 증가하고 있다.

거기에 빅데이터와 AI 의 등장으로 기존 소프트웨어도 계속해서 변화하고 있다.

이는 곧 소프트웨어의 복잡도 증가로 이어지면서 소프트웨어 공학적 지식의 중요성이 높아지고 있으며, 더 빠르게 소프트웨어가 delivery 되기를 바라는 수요가 증가하고 있다. (delivery = 일반 사용자가 사용할 수 있도록 출시되는 것)

 

소프트웨어 공학의 핵심은 장기적으로 더 싸고, 더 빠르게 소프트웨어를 만드는 것이다.

개인프로젝트 하듯이 일단 프로그램을 짜고 보는 것이 아니라, 요구사항을 분석해서 필요한 기능을 모두 찾아내고, 해당 기능들을 구현하기 위해 소프트웨어를 디자인하고, 해당 디자인에 맞춰 인터페이스를 설계한 뒤, 각자 인터페이스에 맞춰 구현하는 것이 장기적으로 비용이 덜 들고 더 빠르게 퀄리티 높은 소프트웨어를 만드는 방법이다.

 

만약 요구사항을 제대로 분석하지 않고 적당히 기능을 나눠서 각자 알아서 개발하면, 그 개발 결과물을 합치는 과정에서도 비용이 발생하고, 버그가 발생하기도 쉬우며, 기존의 코드 작성자가 떠났을 때 이를 유지보수 하는 것도 힘들어지므로 장기적으로는 더 비용이 많이 발생한다.

 

---

 

 

컴퓨터 과학과 소프트웨어 공학을 비교하면, 컴퓨터 과학은 이론과 기초지식에 대한 학문이고, 소프트웨어 공학은 소프트웨어를 만드는 것과 관련된 실제 문제를 해결하는 것과 관련된 학문이다.

컴퓨터 과학은 문제를 해결하는데 있어 매우매우 중요한 기초지식이지만, 이것만 가지고는 소프트웨어를 효율적으로 생산할 수 없다.

그래서 소프트웨어 공학이 필요한 것이다.

 

Software Process

뒤에서 다양한 개발 방법론마다 갖고 있는 소프트웨어 개발 프로세스를 정리할 예정이다.

하지만 모든 방법론이 공통적으로 갖고 있는 개발 프로세스들이 있다.

 

1. specification

요구사항을 분석한 내용을 기반으로 프로그램의 스펙을 결정한다.

스펙을 결정할 때는 소프트웨어의 기능, 실행 환경, 개발 기간, 개발 인원을 고려한다.

 

2. Design and Implementation

스펙을 결정했다면 설계와 구현 작업을 시작한다.

이 과정을 통해 실제 소프트웨어 개발이 진행된다.

 

3. Validation

완성된 소프트웨어가 고객의 요구사항에 맞게 잘 동작하는지 테스트한다.

 

4. Evolution (Maintenance)

하나의 버전이 만들어진 후, 고객의 요구사항이 추가되거나 변경될 때마다 소프트웨어를 수정한다.

 

이때 전체 소프트웨어를 개발하는데 필요한 리소스가 100이라고 할 때, 각 단계에서 필요한 리소스의 양은 대략 다음과 같다.

 

 

대체로 60%는 시스템 개발(스펙 결정, 설계 및 개발) 에 관련되어 있고, 나머지 40%는 테스트하는데 비용이 들어간다.

특히 실제로 소프트웨어를 구현하는 것은 20% 의 비용 밖에 들지 않는다.

 

물론 이런 비용의 구성은 개발하려는 소프트웨어 종류나 요구사항의 특성에 따라 달라진다.

(성능을 매우 중요하게 여긴다거나, 안정성을 매우 중요하게 여기면 그만큼 설계와 테스트를 철저하게 해야하니 구현의 비중이 더욱 줄어들 것이다.)

그렇기에 소프트웨어 공학에서도 모든 상황에 적용할 수 있는 절대적이거나 통일된 테크닉 같은 것은 존재하지 않는다.

항상 개발하려는 소프트웨어에 맞춰 애드 혹 접근방법을 사용한다.

 

하지만 모든 소프트웨어에 적용할 수 있는 기본적인 원칙은 존재한다.

- 내가 잘 이해하고 사용할 수 있는 소프트웨어 프로세스를 적용해야 한다.

- 요구사항을 이해하고 소프트웨어를 설계하는 것이 중요하다.

- 항상 새로운 소프트웨어를 짜기보다, 기존에 작성된 소프트웨어를 재사용해야 한다.

 

이 원칙은 어떤 방법론, 어떤 툴을 사용하더라도 중요한 원칙이다.

 

좋은 소프트웨어

소프트웨어 공학은 결국 좋은 소프트웨어를 적은 비용으로 만들기 위한 기법이다.

그렇다면 '좋은 소프트웨어' 의 기준이 무엇일까?

좋은 소프트웨어는 다음과 같은 특징을 가진다.

 

1. Maintainability

계속 강조한 이야기이지만, 좋은 소프트웨어는 유지보수하기 좋아야 한다.

고객의 요구사항이 바뀌었을 때 수정된 요구사항을 쉽게 반영할 수 있어야 하고, 이를 위해 소프트웨어의 각 부분이 모듈화되어 있어야 한다.

 

2. Dependability

좋은 소프트웨어는 의존할 수 있고, 신뢰할 수 있어야 한다.

언제나 이용 가능해야 하고 (availability), 한번 이용을 시작했을 때 중간에 끊김없이 이용할 수 있어야 하고 (reliability), 외부의 공격으로부터 안전하며 (security), 시스템의 동작을 제한하는 결과가 없도록 백업이 잘 되어있는 등 안정적이여야 하고 (safety), 서비스의 데이터나 동작이 항상 일관적이어야 한다. (integrity)

 

3. Efficiency

좋은 소프트웨어는 효율적이어야 한다.

즉, 투입한 자원에 비해 결과가 더 좋아야 한다.

정렬을 구현할 때 버블 소트와 같이 O(n²) 로직을 사용하는 것보다 일반적으로 O(n log n) 로직을 사용하는 것이 더 좋듯, 같은 자원을 투자했을 때 더 효율적이어야 한다.

 

4. Acceptability

좋은 소프트웨어는 사용자가 수용해야 한다.

아무리 유지보수하기 좋고, 안정적이고, 효율적인 소프트웨어라고 하더라도 결국 고객의 요구사항을 만족시키지 못하고, 고객이 사용하기 어려워서 받아들이지 않는다면 의미가 없다.

 

 

---

 

이번 글에서는 소프트웨어 공학의 큰 의미와 소프트웨어 공학을 통해 만들고자 하는 좋은 소프트웨어의 기준을 정리하였다.

다음 글에서는 소프트웨어 공학의 세부적인 내용들을 하나씩 살펴보며, 첫 번째로 다양한 개발 방법론들에 대해 정리해본다.