Introduction

SW Engineering을 알아보기 전에, Software에 대해서 알아보자.

우리가 건물을 바라볼 때, 여러 관점의 사람들과 이해관계자들이 접근하게 된다. 시공자, 거주자, 설계사, 인부 등에 따라 그 건물을 바라보는 시야가 달라진다. SW도 마찬가지다. 디자이너, 개발자, 사용자, 매니저 등 여러 이해관계자의 상황에 따라 다른 관점을 가지게 된다.

SW란 무엇일까. 소프트웨어란 사전적 의미로 접근하면 프로그램과 프로그램의 개발, 운용, 수정 및 기능 확정을 위해 필요한 모든 정보를 말한다. 소프트웨어는 어찌보면 프로그램의 동적인 의미로 볼 수 있다. 운영체제 관점에서는 Process와도 상통하는 개념이라고 볼 수 있다.

이러한 SW가 가지는 특성으로는 첫째로 비가시성을 가진다. 비가시성이란 무형적인 특성을 가지고 구조가 코드 속에 내제된 상태로 구현된다. 둘째로 복잡성을 가진다. 복잡성이란 개념을 코드로 구현한 것 자체는 복잡하고 난해한 상태를 말한다. 추가로 요구나 환경 변화에 대한 변경 가능성, 복제 가능성, 테스팅의 어려움 등의 특성을 가진다.

소프트웨어 유형

소프트웨어의 분류 체계

SW는 아래와 같은 분류 체계를 가진다.

• 기능
  - 시스템 소프트웨어 : 하드웨어를 직접 관리하고 원활하게 실행하는 기반을 제공한다.
  - 응용 소프트웨어 : 특정 목적을 위해 직접 사용하는 프로그램을 말한다.
  
  
• 개발 과정 : reusable, newly-built, modification, porting 등이 존재한다.
  
  
• 신뢰도
  - critical : 오류 발생 시, 심각한 문제를 초래할 수 있어 신뢰성을 요하는 시스템을 말한다.
  - non-critical : 오류 발생시 불편할 수 있으나 심각한 문제가 발생하지 않는 시스템이다.
  
  
• 소프트웨어 크기 : 규모에 따라 두 가지로 나뉜다.
  - programming-in-the-small : 규모가 작아 소수의 개발자가 단기간에 완성할 수 있는 것을 이야기하며, 개발자의 역량이 큰 영향을 준다.
  - programming-in-the-large : 장기간 개발하는 대규모 프로젝트이다. 이 때는 방법론을 적절하게 적용해야한다.
  
  
• 데이터 특성 : 그래픽이나 이미지, 텍스트 등의 특성을 이야기한다.

정보 시스템 (Information System)

대량의 데이터의 분류, 저장, 검색에 관심을 두는 시스템으로 GUI 기반의 서비스 인터페이스를 제공한다.

정보 시스템의 특성을 몇 가지 알아보자면 이 시스템의 경우 문서가 중요한 요소로 작용하고, 개발이나 유지보수가 많은 노력과 비용이 발생한다. 데이터 설계는 비중이 큰 반면 제어구조는 비교적 간단하다는 특징도 가지고 있다.

우리가 흔히 볼 수 있는 쇼핑몰 사이트나 이런 대형 사이트들이 이런 정보 시스템의 예시가 될 수 있다.

내포 시스템 (Embedded System)

임베디드 시스템은 컴퓨터의 연산이 주 목적이 아니라 더 큰 기계나 시스템의 내부에 포함되어 제어 기능을 수행하는 소프트웨어를 말한다. 우리가 요즘에는 흔히 자동차나 냉장고 등의 전자 기기 내에 들어가는 형태로 주로 볼 수 있다.

특징으로는 시스템의 규모가 크고 수명이 긴 편이며, 실시간 응답성이 필수적으로 접목되어야한다. 또한 오류나 장애가 발생해도 치명적인 사고를 방지할 수 있어야 한다. 마지막으로 비동기성이 특징인데 여기서 비동기성이란 작업의 완료를 기다리지 않고 바로 다음 작업을 실행하는 것을 말한다.

소프트웨어와 관련된 사담

질문 1. 소프트웨어 시스템을 개발하는 데 드는 비용 중 프로그래밍에 드는 비용은 어느정도일까?

소프트웨어 시스템을 개발하는 데 드는 비용 중에 프로그래밍에 드는 비용은 20% 정도이다. 이외의 비용은 테스팅과 요구분석 및 설계가 각각 40%씩 나눠 가진다. 물론 모든 프로젝트가 이 추이를 따라가는 것은 아니고 전반적인 이야기이다.

질문 2. 사용자에게 배달되는 소프트웨어의 실행코드 1000줄 당 예상 오류의 개수는 몇 개일까?

보편적으로 4개 미만이라고 한다. 이는 개발 과정에서 50~60개의 오류가 발생하고 이를 보완해 사용자에게 제공되기에 현저히 떨어진 수치로 보여진다.

질문 3. 사용자가 발견하는 시스템의 오류 중 가장 발견하기 어려운 것은 어느것일까?

이 질문에 대한 답은 "제안서와 사용자 요구사항에 대한 잘못된 이해"이다. 오류가 빠르게 발견되어 요구사항 분석 시점에 가까이 발견될수록 비용이 저렴하고 유지보수 이후로 넘어갈수록 비용이 급격하게 올라간다.

질문 4. 소프트웨어 시스템을 유지 보수하는 데 드는 비용이 개발 비용의 몇배일까?

소프트웨어 시스템을 유지 보수하는데 드는 비용은 개발 비용의 2배 가량 드는 것을 알 수 있다. 이는 제품이 얼마나 체계적으로 만들어졌는지에 따라 반비례적인 추세를 가진다. 또한 처음에 다룬 질문 1번의 내용인 비용 문제에 대한 내용과도 일부 상통하는 내용이라고 볼 수 있다.

소프트웨어에 대한 오해

소프트웨어에 대한 오해는 관점에 따라서 관리자, 그리고 고객과 엔지니어의 오해로 나눌 수 있다. "이정도는 해줄 수 있는거 아닌가?"라는 이해관계의 문제가 중심이다. 그로 인해 이해관계자들의 상황에 맞게 서로 오해의 상황이 발생한다.

관리자의 오해

관리자들은 주로 도구, 인력, 표준화된 프로세스만 갖춰지면 프로젝트가 기계적으로 통제될 수 있다는 착각을 하는 경향이 있다. 쉽게 말해서 자원과 틀만 제공이 되면 프로젝트가 잘 이루어질 것이라는 일종의 믿음을 가진다는 의미이다.

"우리가 이정도 자원을 제공했으니 그들은 충분히 우리가 원하는 결과물을 만들 것이다"라거나 "엔지니어라면 엔지니어링에 중심을 둬야지 요구분석을 하는 것은 좋지 않다", "공정이 지연되면 인력을 투입하는 방식으로 해결할 수 있다" 등의 생각들이 그들이 쉽게 생각하는 오해이다.

자원을 제공했을 때 그에 상응하는 output이 나오기를 바라고 그러리라 믿는 경향이 있는 것이 관리자의 특징이다. 이에 따라 위와 같이 상호간의 오해가 생기기도 한다.

고객의 오해

고객은 소프트웨어의 유연성을 과대평가하여 초기에 요구사항을 명확히 하지 않아도 나중에 고칠 수 있을 것이라 생각한다. 하지만 이 생각은 착각이고, 이후에 수정을 하는 것이 더 힘든 상황이 발생하고 설령 가능하더라도 코드가 난잡해지는 등의 문제가 발생할 가능성이 높다.

흔히 고객이 생각하는 방향을 예로 들자면 "목표에 대한 기술만 대충 적어두면 SW를 만드는데 충분하고 세부적인건 나중에 채우면 된다" 나, "요구사항은 계속 변하고 이를 소프트웨어는 쉽게 수용할 수 있어야한다."는 생각을 하기 쉽다.

엔지니어의 오해

그럼 마지막으로 엔지니어의 오해를 알아보자. 개발자는 코딩과 실행결과에 치중되게 생각을 하는 경향이 있다. 그래서 기능을 만들고 생성하는 것을 중점을 두고 유지보수를 위한 문서화나 설계에서의 품질 검증이 쉽게 넘어가곤 한다.

예를 들자면 "프로그램이 만들어지고 작동하면 할 일을 다 한 것이다" 또는 "시스템을 작동시켜 보기 전까지는 품질을 평가할 방법이 없다", "프로젝트의 결과는 작동하는 프로그램일 뿐이다" 등의 오해를 할 수 있다.

소프트웨어 공학

소프트웨어의 위기

소프트웨어를 개발할 때는 많은 문제들이 발생할 수 있다.

• 예산 초과
• 개발 일정 지연
• 불충분한 성능
• 신뢰하기 어려운 품질
• 유지 보수의 어려움
• 막대한 유지보수 비용

등이 있다. 물론 이보다 훨씬 많은 문제들이 개발이나 설계, 유지보수 과정에서 발생한다. 이 때 우리가 주의깊게 볼 위기는 하드웨어의 급속한 발전과 컴퓨터의 대중화로 SW의 수요가 급증한다는 배경을 두고 심화된다.

현재 대부분의 빅테크가 SW 기업인 것을 감안하면 이 사실에 대해 짐작할 수 있다. 하지만 문제는 여기서 발생한다. 소프트웨어 생산성과 생산 기술은 그에 미치지 못하는 상황이 발생한다.

소프트웨어 공학이란 ?

소프트웨어 공학이란 품질 좋은 소프트웨어를 최소의 비용으로 계획된 일정에 맞추어 개발하기 위하여 여러가지 공학적 원리와 방법을 체계적으로 적용하는 것을 말한다. 한마디로 "일정에 맞게 개발하기 위해 방법론을 적용하여 좋은 퀄리티의 소프트웨어를 제작하는 공정"이다.

소프트웨어 공학의 역사

소프트웨어의 위기로부터 이어진 소프트웨어 공학의 역사에 대해서 알아보자. 우선 이 이야기를 하려면 1970년대부터 시작해야한다.

~1970

이 시기까지 소프트웨어의 위기가 인식되기 시작하고 이를 해결하기 위해 소프트웨어 공학이 탄생한다. 고급 언어가 발생하고, interactive한 프로그래밍이 생기기 시작한다. 이 때 goto 논쟁이라는 것도 발생하는데, 이는 스파게티 코드를 지양하고 논리적 흐름을 강조하는 "구조적 프로그래밍"이 중요하다는 것이 대두되는 기점이 된다.

~1980

이제 본격적으로 소프트웨어 위기로부터의 해결책을 모색하기 시작한다. 소프트웨어 공학이라는 분야가 학문적으로 정착하기 시작했고, 하드웨어로부터 독립된 개념의 소프트웨어가 점점 발생하기 시작한다. 이 때 아래와 같은 개념들이 생기기 시작했다.

• 소프트웨어 생명주기
• 대규모 프로그래밍
• 방법론 및 도구
• 정보 은닉
• 구조적 설계

~Present

80년대에 본격적으로 거론되기 시작한 해결책들은 오늘날까지 여러 방식으로 진화와 발전을 거듭해왔다. 기존의 구조적 프로그래밍의 중심을 벗어나 객체 지향 프로그래밍(방법론)이 흐름의 중심으로 다가서고, 그로인해서 재사용, 디자인 패턴, 소프트웨어 컴포넌트/설계 등의 개념들이 추가적으로 도입되기 시작한다.

소프트웨어 공학의 크기 체계

일전에 소프트웨어 공학의 분류 체계를 하면서 나온 개념이긴 하지만 더 세세하게 개념에 대해서 알아보도록 하자.

1. Programming-in-the-Small

규모가 작은 프로그램을 말하며 프로그램의 규모 자체가 작기 때문에 명확하게 정의가 가능하고 그 문제들을 집중적으로 해결하는 방식이다. 이러한 경우엔 정확하게 개발하는 것이 중요하고, 명세가 잘 변경되지 않는 특성을 가진다.

2. Programming-in-the-Large

우리가 주로 마주하는 프로그램의 크기는 이 형태를 가진다. 규모가 커지게 되면서 개인의 코딩 실력이 중요한 것이 아니라 시스템 전체의 구조와 관리가 중요한 방식이다. 규모가 큰 만큼 해결할 문제를 정확하게 정의해야하고, 아무래도 크기가 크다보니 요구사항을 초기에 정한대로 흘러가지 않는 경우가 많다. 이런 경우를 고려한 상태로 대응책을 마련해야한다.

또한 시스템을 구성하는 컴포넌트들 사이의 인터페이스를 명확하게 설계해야하고 시스템 통합과 테스팅 과정이 필요하다. 규모가 크다보니 협업이 여기서부터는 매우 중요하게 여겨지는데, 변경사항을 체계적으로 관리하는 git과 같은 툴이 적용되어야하고 지속적으로 문서, 유지보수 등을 수정하고 작업하며 탄탄히 나아가야한다.

3. Programming-in-the-Many

프로그램의 크기도 크기지만 인원에 중심을 둔 프로그래밍이다. 팀 단위로 무언가를 구축할 때, 주로 마주하는 문제들을 다루고 팀원 간의 정보 교환 등의 커뮤니케이션을 진행해야한다. 작업을 적당하게 할당해야하고, 표준화를 통해서 팀원들간의 문서 및 개발 성향을 조정할 필요가 있다. 결국 이 시점에 PM(Project Management)의 역량이 중요해진다.

사실상 Many의 경우는 Large인 프로그램에서는 필연적으로 필요한 상황이 발생하고, 규모가 크면 사람이 많아야하고 그에 따라서 2번과 3번은 유기적으로 이어질 가능성이 매우 높다.

소프트웨어 테스팅

구현과 테스팅

그림 1을 통해서 프로젝트의 규모가 클수록 구현과 테스트의 비중이 줄어든다는 사실을 알 수 있고, 프로젝트에서의 구현 오류의 비중이 높은 경우를 그림2를 통해 확인할 수 있다.

SW 코드 검증 방법과 소스코드 검증 기법은 아래와 같다.

SW 코드 검증 방법	소스코드 검증 방법

다양한 테스트 기법들의 오류 감지율

오류 감지를 위한 여러 테스트 기법들이 존재하는데, 그 리스트를 보면 아래와 같다. 하나의 방법이 평균 75%를 넘는 경우가 없고, 그로 인해 다양한 방법을 병행으로 사용해야 효과를 볼 수 있다는 특징이 있다.

V-Model

테스팅을 할 때, 우리는 V 모델을 자주 사용한다. V 모델은 확인 절차가 왼쪽과 오른쪽 두 개로 나뉘고, V자 모양으로 움직일 때 아래의 순차적인 절차를 따라 움직인다.

왼쪽(Architecture Design)
1. 요구사항 분석 : 고객이 무엇을 원하는지 요구사항을 정리한다.
2. 시스템 셀계: 전체 시스템의 하드웨어, 소프트웨어 구조를 기획하는 과정이다.
3. 아키텍처 설계 : 시스템을 구성하는 여러 모듈(기능) 간의 관계와 구조를 설계한다.
4. 모듈 상세 설계 : 각 모듈 내부의 구체적인 로직이나 알고리즘, 데이터 구조 등을 상세히 설계한다.

중간(Coding)
5. 코딩 : 말 그대로 프로그램을 구현하는 절차를 말한다.

오른쪽(Testing)
6. 단위 테스트 : 개발자가 작성한 개별 함수나 클래스가 의도대로 작동하는지 테스트한다.
7. 통합 테스트 : 각각 만들어진 모듈을 연결하면 데이터가 잘 넘어가고 충돌 없이 작동하는지 테스트한다.
8. 시스템 테스트 : 완성된 전체 시스템이 정상적으로 작동하는지, 성능은 잘 나오는지 테스트한다.
9. 인수 테스트 : 최종 고객이 요구사항대로 완성되었는지 직접 사용해보며 승인하는 테스트이다.
10. 설치 테스트 : 최종 사용자의 실제 운영 환경에 소프트웨어가 문제없이 설치 및 구동되는지 테스트한다.

이번 포스트에서는 SW Engineering 과 Testing을 위한 개요를 알아보았다.