[스터디14] 06. 소프트웨어 프로세스 모델 이해하기

목차

8장. 소프트웨어 프로세스 모델 이해하기

8-1 소프트웨어 프로세스 모델이란?

소프트웨어 프로세스 모델(software process model)은 소프트웨어 개발의 전체 흐름과 생애 주기를 체계화한 모형이다. 적절한 모델을 적용하면 기존에 겪었던 문제를 반복하지 않고 프로젝트를 효율적이고 안정적으로 수행할 수 있다.

소프트웨어 프로세스 모델의 필요성

• 체계적인 개발 절차: 개발 과정의 각 단계를 명확히 정의해 일관된 방식으로 업무를 수행하고, 개발자와 이해관계자 간 의사소통을 원활하게 한다.
• 효율적인 자원 관리: 시간과 비용을 효과적으로 분배 및 관리하고, 단계별 산출물을 문서화해 유지 보수를 원활하게 한다.
• 높은 수준의 위험 관리: 개발 초기부터 잠재적 위험 요인을 식별하고 대응하도록 유도하며, 특히 반복적이고 점진적인 모델이 위험 관리에 강점을 보인다.

소프트웨어 프로세스 모델의 역사

• 1960년대 ~ 1990년대 중반: 소프트웨어를 한 번에 완벽하게 개발하는 데 중점을 둔다.
• 1990년대 중반 이후: 객체 지향 프로그래밍의 부상과 함께 변화와 외부 상호 작용을 중시하는 방식이 주목받는다.
• 2000년대 이후: 소프트웨어 규모가 커지면서, 폭포수 모델과 반복적 모델이 Unified Process(UP)로 통합되는 흐름으로 발전한다.

1960~2000년대	2000년대~현재
폭포수 모델, V-모델, 증분형 모델, 진화형 모델, 애자일	폭포수 모델 + 반복적 모델 → Unified Process(UP)로 통합

 

반드시 한 가지 모델만 적용해야 한다는 규칙은 없으며 소프트웨어의 형태, 규모, 기능에 따라 적절한 모델을 선택하는 것이 중요하다.

8-2 단계별 진행과 문서화에 중점을 둔 폭포수 모델

선형적이고 순차적인 접근 방식인 폭포수 모델

폭포수 모델(waterfall model)은 요구 사항 분석, 설계, 개발, 테스트, 유지 보수가 순차적으로 흐르는 선형적 접근 방식이다. 각 단계에서 이전 단계로 되돌아가기 어렵지만, 단계별 산출물이 명확해 일정 관리와 진행 파악이 쉽다.

단계	산출물	작성 내용
요구 사항 분석	요구 사항 정의서	시스템의 기능적, 비기능적 요구 사항을 기술함
프로그램 설계	설계 사양서	시스템 아키텍처와 데이터베이스 설계 문서를 만듦
개발	소스 코드(모듈별 코드)	실제 프로그램을 구현하며, 프로그래밍 언어로 코드 파일을 작성함
테스트	테스트 결과서	요구 사항 충족 여부 확인을 위해 입력, 예상 결과, 실제 결과 등을 기록함

• 적용 분야: 요구 사항이 명확한 프로젝트에서 여전히 자주 사용한다.
• 단점: 요구 사항 변경에 대한 유연성이 부족하고, 오류와 버그가 주로 테스트 단계에서 발견된다.
• 보완 방법: 초기 요구 사항 분석 단계에서 고객과 긴밀하게 소통하고, 테스트 프로세스를 강화한다.

테스트 프로세스를 강화한 V-모델

V-모델은 폭포수 모델을 확장해 테스트 프로세스를 강화한 모델이다. 개발 단계와 테스트 단계를 일대일로 대응시켜 V자 형태로 진행하며, 오류를 조기에 발견할수록 일정과 비용을 효과적으로 단축할 수 있다.

• Verification(검증): 개발 단계까지 각 산출물이 요구 사항을 충족하는지 검증한다.
• Validation(확인): 완성된 프로그램이 실제 요구 사항에 맞게 동작하며 문제가 없는지 확인한다.

검증 세부 단계	설명
요구 사항 분석	사용자의 니즈를 분석해 요구 사항을 도출하고, 기능적, 비기능적으로 구분해 체계적으로 정리함
시스템 설계	요구 사항 문서를 검토해 필요한 기술을 파악하고, 구현 가능성을 판단함
아키텍처 설계	고수준 설계. 모듈 간 인터페이스, 관계, 의존성을 기술하고, DB 테이블과 아키텍처 다이어그램, 통합 테스트 계획을 작성함
단위 설계	저수준 설계. 모듈의 기능 로직을 의사 코드 수준으로 기술하고, 단위 테스트 계획을 수립함

확인 세부 단계	설명
단위 테스트	화이트박스 테스트로 로직을 검증함. 개별 함수, 메서드의 정확성과 효율성을 개발자가 직접 점검함
통합 테스트	블랙박스 테스트로 동작의 결괏값을 검증함. 모듈을 통합해 컴포넌트 간 인터페이스, 상호 작용 오류를 검증함
시스템 테스트	실제 시스템을 요구 사항과 비교해 검증함. 실사용 환경과 유사한 조건에서 성능 등 시스템 레벨의 오류를 발견함
인수 테스트	요구 사항 충족과 신뢰성 확보 여부를 평가함. 실제 배포, 사용 준비 완료 여부를 최종 확인함

 

8-3 지속적 향상에 중점을 둔 반복적 모델

반복적 모델(iterative model)은 사용자의 요구 사항이나 제품의 일부를 단계에 따라 개발하고 반복해 개선하는 접근 방식이다. 크게 증분형 모델과 진화형 모델로 구분한다.

전체를 모듈로 분해하고 점진적으로 개발하는 증분형 모델

증분형 모델(incremental model)은 전체 시스템을 여러 모듈로 분해하고, 각 모듈을 점진적으로 개발하는 방식이다.

• 개발 방식: 분해한 모듈을 하나의 서브 시스템으로 먼저 구현해 릴리스한 후, 다음 서브 시스템을 순차로 개발한다.
• 특징: 핵심 모듈을 우선 개발해 기능을 점차 확장해 나간다.
• 적용 원리: 하나의 증분 사이클이 폭포수 모델의 흐름을 따르므로, 폭포수 모델을 여러 번 적용한 결과를 순차로 조합해 최종 시스템을 완성한다.
• 장점: 프로젝트 관리자(PM)가 적절하게 관리하면, 각 서브 시스템을 독립적으로 병행해서 개발할 수 있다.

프로토타입을 기반으로 발전시키는 진화형 모델

진화형 모델(evolutionary model)은 MVP(Minimum Viable Product)를 핵심 프로토타입으로 먼저 개발한 후, 운영 중 발생하는 요구 사항과 피드백을 반영해 시스템을 지속적으로 발전시키는 방식이다.

• 적용 분야: 초기 요구 사항이 명확하지 않은 프로젝트에 적합하다.
• 주의점: 무분별하고 빈번한 릴리스는 버전 관리의 부담을 키우므로, 진화 과정의 전반적인 개요를 사전에 정리해 두어야 한다.

구분	증분형 모델	진화형 모델
개념	하나의 증분은 폭포수 모델을 적용해 개발하며, 개발된 증분들을 결합해 최종 시스템을 완성함	MVP를 초기 프로토타입으로 개발한 후, 운영을 시작하고 기능을 점차 발전시켜 최종 시스템을 완성함
특징	초기 요구 사항이 명확한 경우에 적합하며, 각 증분을 병렬로 개발할 수 있음	초기 요구 사항이 불명확한 경우에 적합함
장점	신규 도입 시 발생하는 충격을 완화하고, 후반 통합 시 발생하는 부담을 줄일 수 있음	완성도를 점차 향상시킬 수 있고, 초기의 불완전한 요구 사항에 유연하게 대응할 수 있음
단점	여러 증분을 관리하는 부담이 있고, 요구 사항 변경에 효과적으로 대응하기 어려움	빈번한 릴리스 시 버전 관리 부담이 커지고, 비용과 일정이 증가할 수 있음

항목	폭포수 모델	반복적 모델
개발 방식	순차적, 단계별로 진행	반복적, 점진적으로 개선
변경 대응	유연성이 낮고 변화하기 어려움	유연성이 높고 변경 사항을 쉽게 반영
문서 중요도	각 단계별 산출물이 중요	비교적 덜 중요하며 프로토타입에 중점
고객 참여 시기	초기 요구 사항 전달 단계에서만 참여	지속적인 참여와 피드백 수행
요구 사항 명확성	초기 요구 사항이 명확해야 함	초기 요구 사항이 불완전해도 적용 가능
프로젝트 규모	주로 소규모	소규모에서 대규모까지 적용 가능

8-4 위험 최소화에 중점을 둔 나선형 모델

나선형 모델(spiral model)은 위험 분석 단계를 별도로 두어 위험 최소화를 중요한 요소로 고려하면서, 점차 완벽한 시스템을 구축해 나가는 방식이다. 다음 4단계를 반복하며 시스템을 완성한다.

1. 목표 설정: 고객의 요구 사항을 분석하고 타당성을 검토한 후, 해당 사이클의 목표를 새롭게 수립한다.
2. 위험 분석: 고객의 요구 사항을 기반으로 예상되는 위험 요소를 식별하고, 이를 초기에 최소화하는 해결 방안을 마련한다.
3. 구현 및 테스트: 적합한 개발 모델을 선택해 진행하며, 단위 테스트 후 통합 테스트와 시스템 테스트를 순차로 진행한다.
4. 고객 평가 및 다음 계획 수립: 고객 평가를 바탕으로 반복 여부를 결정하고, 인수 테스트로 시스템의 적합성을 최종 검토한다.

8-5 신속한 개발 경험에 중점을 둔 애자일

애자일(Agile)은 짧은 작업 주기와 반복적인 릴리스 사이클로, 고객의 요구 변화나 시스템 장애에 유연하고 신속하게 대응하는 개발 방법론이다.

애자일 소프트웨어 개발 선언문
공정과 도구보다 개인의 상호 작용을,
포괄적인 문서보다 동작하는 소프트웨어를,
계약 협상보다 고객과의 협력을,
계획에 따르기보다 변화에 대응하기를
가치 있게 여긴다.

구성 요소	설명
제품 백로그(product backlog)	제품에 필요한 항목을 모두 나열한 목록. 한 번에 정해지는 것이 아니라 지속적으로 진화하는 산출물임
스프린트 백로그(sprint backlog)	제품 백로그 중에서 이번 스프린트 주기 동안 개발할 항목을 뜻함
스프린트(sprint)	반복적인 짧은 개발 주기. 보통 2~4주로 설정하며, 정해진 기간 동안 계획한 작업을 완료하는 것을 목표로 함
일일 스크럼(daily scrum)	매일 짧게 진행하는 회의로, 진행 상황, 어려움, 다음 단계 계획을 공유함
제품 개선 반영 부분	스프린트 종료 시 결과물을 평가하고 배포 여부를 결정하며, 개선 사항을 반영하는 과정을 포함함

애자일의 핵심 가치

• 협력: 통찰력과 아이디어를 공유해 시너지를 창출하고, 문제 발생 시 신속하게 해결하며 추가 문제점을 미리 발견하는 데 도움을 준다.
• 피드백: 개발자가 자신이 만든 기능을 스스로 확인하는 내부 피드백과 고객, 사용자가 제품을 사용한 뒤 제공하는 외부 피드백으로 나뉜다.

애자일 스프린트 5단계

1. 분석: 사용자의 요구 사항을 분석하고, 스프린트 백로그에 포함할 항목을 선정한다.
2. 설계: 선정한 스프린트 백로그의 설계와 디자인을 추가하거나 수정한다.
3. 개발: 프로그램 기능을 개발하고, 단위 테스트와 통합 테스트 코드를 작성하고 수행한다.
4. 테스트: 테스트에서 발견한 오류를 수정하고, 이 스프린트에서 개발한 코드 품질을 검증한다.
5. 검토: 내부 피드백과 외부 피드백을 반영해 개선 사항을 정리하고, 이를 다음 스프린트에 적용한다.

애자일의 장점과 한계

애자일은 '먼저 만들어 보고 빠르게 수정한다'는 원칙에 따라 계획에 소요되는 시간을 최소화하고, 버그와 피드백을 신속하게 반영해 시장 출시 시간(Time to Market)을 단축한다. 다만 다음과 같은 한계도 있다.

• 다른 방법론에 비해 유지 보수 작업의 부담이 높아질 수 있다.
• 요구 사항의 방향성이 크게 변경되면 전체 모델이 무너질 위험이 있다.
• 민첩하고 빠른 대응을 요구하다 보니 협업이 많아져, 개발자에게 심리적 부담과 스트레스로 다가올 수 있다.
• 지속적인 변화에 적응하기 위해 새로운 기술을 끊임없이 학습해야 하는 부담이 존재할 수 있다.

애자일을 적용한 다양한 개발 방식

• 스크럼(scrum): 애자일 중 가장 대표적인 방식이다. 백로그와 스프린트를 핵심 구성 요소로 사용하며, 각 스프린트 종료 시점마다 목표에 맞는 기능이나 개선 사항을 반영한다.
• 익스트림 프로그래밍(Extreme Programming, XP): 요구 사항을 한 번에 수집하지 않고 반복 주기를 극히 짧게 운영하는 방식이다. 빠른 프로토타입 제작과 지속적인 수정, 변경, 배포가 특징이다.
• 칸반(Kanban): 엄밀히는 '시각적 작업 관리 도구'이지만 애자일의 한 형태로 본다. 작업을 카드 형태로 시각화해 진행 상황을 실시간으로 파악할 수 있으며, 지라(JIRA)와 같은 도구에서도 칸반 보드를 제공한다.

8-6 객체 지향 프로그램 표준, Unified Process

통합 프로세스(Unified Process, UP)는 UML과 함께 OMG(Object Management Group)에서 공개한 통합 개발 프로세스로, 객체 지향 프로그래밍의 실제 표준으로 간주된다. 통합 프로세스보다 줄임말인 UP를 자주 사용한다.

UP의 특징

• 개발 방식: 반복적이며 점진적이고 진화적인 개발 방법론이며, 개발 사이클은 보통 3주 단위로 반복한다.
• 위험 관리: 프로젝트 수행 과정에서 발생할 수 있는 위험 요소, 특히 아키텍처와 고객 요구 사항 측면의 위험을 우선적으로 식별하고 해결한다.
• 아키텍처 확정: 주로 상세화(elaboration) 단계에서 위험을 해결하며, 이 단계가 끝나면 시스템의 아키텍처가 확정된다.

여러 개발 방법론을 적용한 UP

UP는 폭포수 모델, 반복적 모델 등 기존의 개발 방법론을 조합하여 통합적으로 적용하는 프로세스다.

적용 모델	UP에서의 역할
폭포수 모델	개념화 단계에서 목표·범위를 정의하고 초기 요구 사항을 수집함(폭포수의 요구 사항 정의 단계와 유사)
나선형 모델	상세화 단계에서 아키텍처와 고객 요구 사항 관점의 위험을 조기에 발견하고 수정함
프로토타입 모델	상세화가 완료되면 주요 기능을 정의하고, 프로토타입을 개발해 기능 검증을 담당함
반복적 모델(증분형, 진화형)	반복적이고 점진적인 개발로 시스템을 구축함

UP의 4단계

1. 개념화(inception) 단계: 프로젝트의 초기 평가를 진행하고 시스템의 구성 환경을 파악한다.
2. 상세화(elaboration) 단계: 시스템의 구조를 정의하고 고객의 요구 사항을 분석해 유스 케이스를 도출한다. 주요 위험 요소를 집중적으로 분석하고 이해관계자와 협업해 해결하는, UP에서 가장 핵심적인 단계다.
3. 구축(construction) 단계: 시스템을 배포할 수 있는 품질 수준에 도달할 때까지 개발과 테스트를 반복해서 수행한다.
4. 전이(transition) 단계: 구축한 시스템을 실제 운영 환경에 배포하고, 마지막으로 사용자 교육과 인수인계를 진행한다.

이 글은 『 Do it! 클린 프로그래밍 』 책을 학습한 내용을 정리한 것입니다.