Introduction

소프트웨어 생명 주기Life Cycle는 소프트웨어 제품의 개발부터 운영, 유지보수, 폐기까지의 전체 과정을 기술한 것입니다. 프로젝트의 규모와 요구사항의 불확실성에 따라 적합한 생명 주기 모델이 달라지며, 이 선택이 프로젝트의 성패를 좌우합니다. 이 글에서는 Code-and-fix 모델부터 폭포 모델, 점진적 모델, 나선형 모델, 그리고 통합 프로세스까지 생명 주기 모델의 발전 과정을 살펴봅니다.

Life Cycle

소프트웨어의 생명 주기는 소프트웨어 제품을 개발하고, 운영하고, 유지보수하고, 최종적으로 폐기하는 전체 과정에서 수행되는 활동들의 순서를 기술한 것이다. 즉, 소프트웨어 제품의 개발부터 운영과 유지 및 보수, 그리고 폐기까지의 모든 과정을 통틀어 소프트웨어의 생명 주기라 부르는 셈이다.

Definition

software system or software product cycle initiated by a user need or a perceived customer need and terminated by discontinued use of the product or when the software is no longer available for use

소프트웨어의 생명 주기는 SDLCSoftware Development Life Cycle이라고도 부르는데, 운영과 유지보수의 중요성이 부각되지 않았던 시절에는 두가지 이름을 혼용하기도 했다.

Software Life Cycle Models

실제 소프트웨어 개발에서 사용된 생명 주기 모델에는 여러가지가 있다. 각 모델의 등장과 쇠퇴는 소프트웨어의 발전사와 맞물려 있고, 이에 따라 제품을 개발하는 과정도 계속 변해왔다. 시대순으로 소프트웨어 생명 주기 모델의 등장과 쇠퇴를 살펴보자.

Code-and-fix model

소프트웨어 개발은 원래 매우 단순하게 이루어졌다. 개발 이전에 특별히 계획을 세운 것도 아니고, 디자인을 만든 것도 아니고, 요구사항이나 그런 것을 만들지도 않았다. 일단 뭔가 만든 다음 계속 수정하면서 제품을 완성했다. 후술할 모델들과 비교하면 진행 상황을 쉽고 빠르게 눈으로 확인할 수 있고 작은 규모의 프로젝트에 적합하지만, 그만큼 유지보수에 드는 비용이 높고 규모를 키울 수가 없다.

Waterfall Model

그러다 1970년에 Winston Royce가 폭포 모델Waterfall Model을 제안했다.1 이 모델은 큰 규모의 프로젝트를 다루기 위해 고안된 단계별 접근법으로, 요구사항Requirements → 분석Analysis → 디자인Design → 구현Coding/Implementation → 테스트Testing → 운영Operation/Deployment → 유지보수Maintenance 순서로 소프트웨어 제품을 개발하는 방식이다.

이 단계에서 가장 중요한 것 두가지는 구현보다 설계를 먼저 하는 것, 그리고 문서를 작성하고 단계를 지키는 것이다. 이 모델은 특성상 앞선 단계가 완벽하게 끝나야 다음 단계를 진행할 수 있기 때문에 중간중간 제대로 했는지, 제대로 끝냈는지 확인할 방법이 필요하다. 그래서 각 단계를 제대로 수행했다는 것을 문서로서 보여줘야 했고, 문서화와 절차가 강조되었다.

이 모델은 간단한 구조를 지니고 있어 이해하기 쉽고 각 단계마다 결과물이 명확하다. 경영 측면에서 관리하기도 편하고, 요구사항이 명확하고 위험이 낮은 소규모 프로젝트에 적합하다. 그러나 이 모델이 제대로 작동하기 위해서는 변경되지 않는 요구사항을 도출해야 하는데, 고객이 모든 요구사항을 명시적으로 미리 진술하기 어렵다.2 작동하는 시스템이 생명 주기의 후반부에야 나와서, 소프트웨어 요구사항이 생명 주기 후반부에 테스트된다. 만약 여기서 문제가 생긴다면? 이전 단계로 다시 거슬러 올라가야 한다.

Pressman은 폭포 모델의 문제점을 세 가지로 정리한다. 첫째, 실제 프로젝트가 순차적인 흐름을 따르는 경우는 드물다. 둘째, 고객이 모든 요구사항을 사전에 명확히 제시하기 어렵다. 셋째, 작동하는 프로그램이 프로젝트 후반부에야 나오기 때문에 고객이 인내심을 가져야 한다.3 그럼에도 불구하고 폭포 모델은 소프트웨어 공학에서 가장 오래된 패러다임이며, 요구사항이 잘 이해되고 안정적인 상황에서는 여전히 유효한 접근법이다.

Prototyping Model

프로토타입 모델은 바로 그 문제를 해결하기 위해 등장했다.

고객은 기술적으로 이야기해주지 않는다. 보통 기술적으로 무엇이 가능하고 무엇이 불가능한지를 알지 못하고 무엇을 원하는지를 잘 모른다. 그래서 프로토타입 모델에서는 이게 맞는지 저게 맞는지 시제품을 미리 만들어보고 이를 통해 고객이 무엇을 원하는지 파악한다. 이렇게 만들어진 시제품을 Throw-away prototype이라 부르며, 점차 진화해가는 Evolutionary prototype과는 다른 종류다.

이렇게 시제품을 미리 던져보면 요구사항을 잘못 파악할 가능성도 줄어들고 정기적으로 가시적인 진척을 보여줄 수 있어 관리에도 도움이 되며, 조기에 제품을 홍보할 수도 있다. 하지만 불안정하거나 잘못 구현된 프로토타입이 종종 최종 제품이 되어버리기도 하고 광범위한 고객 협력이 필요하다. 또한 프로젝트가 얼마나 오래 지속될지 알 수 없고, 적절한 요구사항 분석, 설계, 고객 평가와 피드백이 없다면 쉽게 code-and-fix 모델로 퇴보할 수 있다.

Incremental Model

프로토타입 모델에서 시스템이 생명 주기 후반부에 나온다는 단점을 보완하기 위해 점진적 모델Incremental Model이 등장했다. 이 모델은 폭포 모델과 기본적으로 같은 과정을 공유하지만, 몇가지 다른 점이 존재한다.

제품의 릴리즈는 한번에 이루어지지 않고, 여러 번의 증분Increment으로 이루어진다. 첫번째 릴리즈는 주로 기본적인 요구사항이 반영된 핵심 제품이고, 여기서 요구사항을 추가로 반영해가며 새로운 릴리즈를 계속 만든다. 각 릴리즈가 지켜야 할 요건 중 하나는 작동하는 제품을 전달하는 것이다. 각 릴리즈는 폭포 모델과 똑같이 요구사항, 디자인, 구현, 테스팅, 배포, 유지보수의 과정을 거치고, 시간에 따라 릴리즈의 기능과 특징이 점진적으로 증가한다.

그래서 점진적 모델은 사용자로부터 미리 피드백을 받을 수 있고 따라서 고객의 요구를 더 잘 충족시킬 수 있다. 또한 마감일까지 완전한 구현을 위한 인력이 없어도 제품을 개발할 수 있고, 증분을 통해 기술적 위험을 관리할 수도 있다. 하지만 문제는 어떤 요구사항이 추가될지 모른다는 것이다. 모든 릴리즈에 필요한 공통 기능을 찾기 어려울 수 있고, 새로운 릴리즈를 개발하는 동안 기존 릴리즈에 대한 유지보수가 필요하기 때문에, 유지보수에 투입되는 비용으로 인해 부하가 점점 추가되며 갈수록 마감 날짜에 쫓기게 된다. 그리고 기존의 릴리즈에 반영된 모든 수정과 업데이트가 현재 개발 중인 버전과 통합돼야 하고, 특히 고정 비용 계약의 경우 시스템 개발 계약에 완전한 시스템 명세가 포함된 많은 조직의 조달 모델Procurement Model과 충돌할 수 있다.

Evolutionary Model

점진적 모델을 통해 핵심적인 제품의 요구사항은 잘 파악해도 디테일이나 추가 기능이 정의되지 않는 문제가 있다. 그리고 폭포 모델이나 폭포 모델에 기반한 점진적 모델로는 시시각각 변하는 요구사항을 수용하기가 어렵다. 그래서 이 문제를 해결하기 위해 진화적 모델Evolutionary Model이 탄생했다.

Evolutionary Prototyping Model

진화적 모델에 속하는 첫번째 유형은 진화적 프로토타입 모델Evolutionary Prototyping Model이다. 사용자는 각 사이클의 최종 단계에서 제품을 써보고 피드백을 제공할 수 있고 이 피드백은 다음 버전을 개발할 때 반영된다.

시간이 흐르면서 고객은 제품이 자신의 요구사항을 점점 더 충족해가는 것을 확인할 수 있고, 개발자 입장에서는 시시각각 변하는 요구사항에 대응할 수 있다. 모든 작업은 쪼개져 있으며, 덕분에 요구사항을 중간에 바꿔도 기술적인 부담이 덜하다. 점차 더 나은 제품을 만든다는 것은 점진적 모델과 동일하나, 이 모델에서 다음 릴리즈의 목표는 현 릴리즈의 더 완전한 버전이라는 점이 다르다.

Spiral Model

진화적 모델에 속하는 두 번째 유형은 나선형 모델Spiral Model이다. Barry Boehm이 1988년에 제안한 위험 주도 프로세스 모델Risk-driven Process Model이며, 프로토타이핑의 반복적 성격과 폭포 모델의 체계적이고 통제된 측면을 결합한 것이 핵심이다.4 나선형 모델에서 소프트웨어는 일련의 진화적 릴리즈를 통해 개발된다. 초기 반복에서는 모형이나 프로토타입이 릴리즈될 수 있고, 이후 반복에서는 점점 더 완전한 버전이 만들어진다. 나선의 각 회전은 프레임워크 활동(커뮤니케이션, 계획, 모델링, 구축, 배포)의 한 세그먼트를 나타내며, 시계 방향으로 중심부에서 바깥으로 진행된다. 매 회전마다 위험risk이 평가되고, 앵커 포인트 마일스톤anchor point milestone을 통해 진행 상태를 확인한다.

이 모델의 가장 큰 장점은 폭포 모델의 품질 보장과 프로토타입 모델의 유연함을 동시에 가지고 있다는 것이다. 대규모 시스템 개발에 적합하며, 프로토타이핑을 위험 감소 메커니즘으로 활용한다. 다른 프로세스 모델과 달리 소프트웨어가 인도된 이후에도 모델을 계속 적용할 수 있다. 다만 상당한 위험 평가 전문성이 요구되며, 주요 위험을 발견하지 못하고 관리하지 못하면 문제가 발생할 수밖에 없다. 또한 계약 상황에서 고객에게 진화적 접근이 통제 가능하다고 설득하기 어려울 수 있다.

Unified Software Development Process

통합 소프트웨어 개발 프로세스Unified Software Development Process는 통합 프로세스Unified Process(이하 UP)라고도 불린다. Pressman에 따르면 UP는 전통적 프로세스 모델의 장점을 취하면서 애자일 소프트웨어 개발의 모범 사례를 반영하려는 시도다. 유스케이스use case를 통한 고객 소통을 중시하고, 소프트웨어 아키텍처의 역할을 강조하며, 반복적이고 점진적인 프로세스 흐름을 제공한다.5 UP는 단순한 프로세스가 아니라 조직과 프로젝트의 상황에 맞는 최적화가 필요한 프레임워크이며, 전체 개발 사이클은 Inception → Elaboration → Construction → Transition → Production의 순서로 이어진다.

Phases

여기서 페이즈별로 여러 작업이 조금씩 겹칠 수 있다. Inception 페이즈에서는 예비 유스케이스를 통해 근본적인 사업 요구사항을 기술하고, 자원을 파악하며 주요 위험을 평가하고 예비 일정을 수립한다. Elaboration 페이즈에서는 예비 유스케이스를 정제·확장하고 유스케이스 모형, 분석 모형, 설계 모형, 구현 모형, 배포 모형이라는 다섯 가지 뷰를 포함하는 아키텍처 베이스라인architectural baseline을 만든다.6 이 과정에서 핵심 아키텍처를 반복적으로 구현하고, 리스크를 구체적으로 파악하고, 대부분의 요구사항과 개발 범위를 파악한다. Construction 페이즈에서는 소프트웨어 증분에 필요한 모든 기능을 소스 코드로 구현하고, 컴포넌트를 조립하여 통합 테스트를 수행한다. 유스케이스로부터 인수 테스트 스위트를 도출하여 다음 페이즈 진입 전에 실행한다. Transition 페이즈에서는 베타 테스트를 하며 배포 직전 최종 점검을 한다. 그러고 나면 프로덕션 환경에서 사용하기 위한 최종 배포가 이루어진다.

Disciplines

UP에서 유스케이스 작성과 같은 업무 활동은 discipline이라는 활동의 모음으로 기술한다. 업무는 주제에 따라 분류되며, 이들을 묶어 discipline이라 부르는 것이다. Discipline과 Phase의 관계는 아래와 같다. 페이즈마다 하는 일이 조금씩 겹칠 수 있고, 같은 주제로 묶이는 일이라 해도 여러 페이즈에 걸쳐 수행될 수도 있다는 것을 확인할 수 있다.

V Model

한편, 폭포 모델을 조금 다른 방식으로 보완한 모델도 있으니 바로 V 모델이다. V 모델은 폭포 모델의 변종으로, 소프트웨어 요구사항이 생명주기 후반부에 테스트된다는 문제를 해결하기 위해 기존의 폭포 모델에서 제품의 품질을 보증하기 위한 여러 활동을 과정의 중간에 끼워넣었다.

위 다이어그램은 V 모델 전체를 표현하고 있는데, 왼쪽에는 문제 요구사항을 정제하는 과정이 있다. 요구사항 분석Requirements Analysis, 시스템 설계System Design, 아키텍처 설계Architecture Design, 모듈 설계Module Design, 코드 생성Coding 순으로 이어진다. 모델의 오른쪽에는 테스트를 수행하는 과정이 있는데, 단위 테스팅Unit Testing, 통합 테스팅Integration Testing, 시스템 테스팅System Testing, 인수 테스팅Acceptance Testing 순으로 올라간다. 각 개발 단계는 그에 맞는 품질 보증 과정과 연결되며 개발 프로세스 중에 계속 테스트가 진행된다.

V&V

V 모델의 또다른 이름이 바로 V&VVerification & Validation 모델이다. 여기서 검증Verification과 확인Validation의 차이는 아래와 같다.

Verification vs Validation

Verification: Are we building the product right? Validation: Are we building the right product?

제품을 요구사항에 맞게 만들었는지를 따지는 것은 검증의 영역이고, 제품이 실제로 고객이 원하는 대로 작동하는지를 따지는 것은 확인의 영역이다. V&V에 대한 자세한 내용은 소프트웨어 테스팅에서 다룬다.

마무리

소프트웨어 생명 주기 모델은 프로젝트의 규모, 요구사항의 불확실성, 위험 수준에 따라 적합한 것이 달라진다. 요구사항이 명확하고 안정적이라면 폭포 모델이나 V 모델이 효과적이고, 요구사항이 불확실하다면 프로토타입 모델이나 진화적 모델이 더 적합하다. 대규모 프로젝트에서 위험 관리가 핵심이라면 나선형 모델이, 반복적이고 점진적인 개발이 필요하다면 통합 프로세스가 좋은 선택이다.

어떤 모델을 선택하든 공통적으로 중요한 것은 프로세스의 흐름process flow이다. Pressman은 프로세스 흐름을 선형적linear, 반복적iterative, 진화적evolutionary, 병렬적parallel의 네 가지로 구분하는데, 현대의 대부분의 프로세스 모델은 이 중 둘 이상의 흐름을 결합하여 사용한다. 결국 생명 주기 모델의 선택은 제품과 프로세스 사이의 균형을 찾는 문제이며, 이 선택이 프로젝트의 성패에 직결된다.

출처

  • Pressman, R.S. and Maxim, B.R. (2020) Software engineering: a practitioner's approach. Ninth edition. New York, NY: McGraw-Hill Education. — Ch.2 Process Models.
  • Royce, W.W. (1970) "Managing the Development of Large Software Systems." Proceedings of IEEE WESCON, pp.1–9.
  • Boehm, B.W. (1988) "A Spiral Model of Software Development and Enhancement." Computer, 21(5), pp.61–72. IEEE.
  • Jacobson, I., Booch, G. and Rumbaugh, J. (1999) The Unified Software Development Process. Reading, MA: Addison-Wesley.
  • Larman, C. (2010) Applying UML and patterns: an introduction to object oriented analysis and design and iterative development. 3rd edition. Upper Saddle River, NJ: Prentice Hall PTR.
  • McConnell, S. (1996) Rapid development: taming wild software schedules. Redmond, WA: Microsoft Press.

Footnotes

  1. Royce, W.W. (1970) "Managing the Development of Large Software Systems." Proceedings of IEEE WESCON. Royce의 원래 논문은 "피드백 루프"를 허용하고 있었지만, 대다수의 조직은 이 모델을 엄격하게 선형적인 것으로 취급했다. ↩

  2. 단, 계약과 얽힌 문제로 인해 미리 계약을 맺고 솔루션 등을 개발하는 업체는 여전히 이 모델을 애용한다. ↩

  3. Pressman, Ch.2. 세 번째 문제를 풀어 쓰면, 고객이 작동하는 버전을 처음 보는 시점이 프로젝트 후반부이기 때문에 그때서야 요구사항의 오류를 발견하게 되고, 수정 비용이 크게 증가한다. ↩

  4. Boehm, B.W. (1988) "A Spiral Model of Software Development and Enhancement." Computer, 21(5), pp.61–72. IEEE. 이후 Boehm은 1998년과 2001년에 모델을 더 발전시켰다. ↩

  5. Jacobson, I., Booch, G. and Rumbaugh, J. (1999) The Unified Software Development Process. Addison-Wesley. UML(통합 모델링 언어)은 이들의 작업을 지원하기 위해 개발되었으며, 객체 지향 시스템의 모델링과 개발을 위한 사실상의 산업 표준이 되었다. ↩

  6. 유스케이스 모형use case model은 시스템의 기능적 요구를, 분석 모형analysis model은 도메인 구조를, 설계 모형design model은 구현에 가까운 아키텍처를, 구현 모형implementation model은 소스 코드 구조를, 배포 모형deployment model은 물리적 환경에서의 배치를 각각 기술한다. ↩