SW 개발 생명주기 모델

💡 용어 정리

• SDLC(Software Development Life Cycle): 소프트웨어를 계획하고 개발하여 배포·운영·유지보수까지의 전체 생명주기
• 개발 생명주기 모델: 소프트웨어 개발 활동을 어떤 순서와 방식으로 수행할지 정의한 접근 방식
• 순차적 개발: 개발 단계를 비교적 순서대로 진행하는 방식
• 반복적 개발: 개발 과정을 여러 번 반복하면서 제품을 점진적으로 발전시키는 방식
• Prototype: 요구사항이나 아이디어를 확인하기 위해 빠르게 만든 초기 형태의 제품
• Increment: 기존 제품에 추가되는 기능이나 제품의 일부
• Iteration: 개발 활동을 반복하는 하나의 주기

SW 개발 생명주기 모델이란?

소프트웨어는 단순히 코드를 작성하는 것만으로 만들어지는 것이 아니다.
일반적으로 다음과 같은 여러 개발 활동을 거친다.

계획 → 분석 → 설계 → 구현 → 테스트 → 배포 → 운영 및 개선

이러한 활동을 어떤 순서와 방식으로 수행할 것인지에 따라 다양한 Software Development Life Cycle Model이 존재한다.

대표적으로 다음과 같은 모델이 있다.

• Build-Fix Model
• Waterfall Model
• Prototyping Model
• Spiral Model
• Incremental Model
• Iterative Model
• V-Model
• Agile 계열
• RAD 등

모든 프로젝트에 적합한 하나의 개발 모델이 존재하는 것은 아니다.

프로젝트의 요구사항 명확성, 규모, 기술의 익숙함, 변경 가능성, 위험, 고객 참여 정도 등을 고려하여 적합한 개발 방식을 선택한다.

주먹구구식 개발 모델 (Build-Fix Model)

일단 만들고 문제가 생기면 고친다.

💡 구현 → 사용자 확인 → 수정 → 다시 확인 → 만족할 때까지 반복

요구사항 분석이나 설계 등의 체계적인 개발 단계를 거치지 않고 바로 구현을 시작한 뒤, 사용자가 만족할 때까지 수정하는 방식이다.

특징

• 요구사항 분석이나 설계 없이 구현부터 시작한다.
• 사용자의 피드백에 따라 수정 작업을 반복한다.
• 개발 과정이나 산출물이 체계적으로 관리되지 않는 경우가 많다.
• 규모가 매우 작은 프로그램에서는 간단하게 적용할 수 있다.

장점

• 개발을 빠르게 시작할 수 있다.
• 작은 규모의 소프트웨어에서는 복잡한 개발 절차 없이 빠르게 결과물을 만들 수 있다.

단점

• 개발 계획이 명확하지 않다.
• 프로젝트 진행 상황을 파악하기 어렵다.
• 문서가 부족하여 개발자 변경이나 유지보수 시 어려움이 생길 수 있다.
• 수정이 반복되면서 코드 구조가 복잡해질 수 있다.
• 규모가 커질수록 관리하기 어렵다.

적합한 상황

• 규모가 매우 작은 프로그램
• 한두 명이 전체 구조를 충분히 파악할 수 있는 프로젝트
• 이후 기능 확장이나 유지보수가 거의 필요하지 않은 경우

Build-Fix = 일단 만들고 → 문제가 생기면 수정

작은 프로그램에서는 빠를 수 있지만, 프로젝트 규모가 커지면 계획·문서·관리의 필요성이 커진다.
이러한 문제 때문에 이후 체계적인 개발 생명주기 모델들이 등장하게 되었다.

순차적 접근 vs 반복적 접근

개발 모델을 이해할 때 크게 순차적 접근과 반복적 접근의 특징을 비교할 수 있다.

실제 개발 모델은 두 특성이 혼합되어 사용되기도 하므로
모든 모델을 완전히 두 종류로만 구분할 수 있는 것은 아니다.

1. 순차적 접근

요구사항 분석 → 설계 → 구현 → 테스트처럼 개발 단계를 비교적 정해진 순서대로 진행하는 방식이다.

특징

• 요구사항이 비교적 명확한 프로젝트에 적합하다.
• 각 개발 단계와 산출물이 명확하다.
• 계획과 일정 관리가 비교적 쉽다.
• 문서화를 중요하게 다룬다.
• 이전 단계가 충분히 완료된 후 다음 단계로 진행한다.
• 개발 중 요구사항이 변경되면 대응하기 어렵거나 비용이 증가할 수 있다.

적합한 상황

• 과거에 유사한 시스템을 개발한 경험이 있는 경우
• 사용하는 기술이 충분히 검증되어 있는 경우
• 요구사항의 변경 가능성이 낮은 경우
• 프로젝트 시작 단계에서 요구사항을 비교적 명확하게 정의할 수 있는 경우

대표 모델

• Waterfall Model
• V-Model

1-1. 폭포수 모델 (Waterfall Model)

개발 단계를 정해진 순서대로 진행한다.
앞 단계를 완료한 뒤 다음 단계로 진행

소프트웨어 개발 과정을 여러 단계로 나누고,
앞 단계의 결과를 바탕으로 다음 단계로 진행하는 대표적인 순차적 개발 모델이다.

요구사항 분석 → 설계 → 구현 → 테스트 → 배포

요구사항이 명확하고 변경 가능성이 낮을수록 적용하기 좋다.
반대로 새로운 기술이나 요구사항 변화가 많은 프로젝트에서는 대응이 어려울 수 있다.

특징

• 개발 단계가 비교적 명확하게 구분된다.
• 이전 단계가 충분히 완료된 후 다음 단계로 진행한다.
• 단계별 산출물과 문서화를 중요하게 다룬다.
• 프로젝트 초기에 요구사항을 명확하게 정의하는 것이 중요하다.

장점

• 개발 단계와 진행 상황을 파악하기 쉽다.
• 단계별 산출물을 체계적으로 관리할 수 있다.
• 문서화가 잘 이루어져 새로운 인력이 프로젝트에 참여할 때 이해하기 비교적 쉽다.
• 이미 잘 알고 있는 기술이나 유사한 프로젝트 경험이 있는 경우 적용하기 좋다.

단점

• 요구사항 변경에 유연하게 대응하기 어렵다.
• 문서 작성에 많은 시간과 노력이 필요할 수 있다.
• 실제 동작하는 소프트웨어를 개발 후반부에서 확인하게 된다.
• 초기에 발생한 요구사항이나 설계 문제가 뒤늦게 발견되면 수정 범위와 비용이 커질 수 있다.
• 앞 단계가 지연되면 뒤 단계에도 영향을 줄 수 있다.

적합한 상황

• 요구사항이 명확한 경우
• 요구사항 변경 가능성이 낮은 경우
• 과거에 유사한 프로젝트 경험이 있는 경우
• 사용 기술이 충분히 검증되어 있는 경우
• 단계별 산출물과 문서 관리가 중요한 경우

1-2. V-Model

개발 단계와 그에 대응하는 테스트 단계를 연결하여 생각하는 모델

V-Model은 폭포수 모델을 확장하여
개발 단계마다 어떤 테스트 활동과 연결되는지를 보여주는 개발 생명주기 모델이다.

일반적으로 개발 활동이 V자의 왼쪽에, 테스트 활동이 오른쪽에 배치된다.

요구사항 분석 ↔ 인수 테스트
시스템 설계 ↔ 시스템 테스트
상세 설계 ↔ 통합 테스트
구현 ↔ 컴포넌트 테스트

특징

• 개발 단계와 테스트 단계를 대응시킨다.
• 테스트를 개발 완료 후에만 수행하는 활동으로 보지 않는다.
• 개발 초기부터 테스트 계획과 설계를 함께 고려할 수 있다.
• 각 테스트 레벨의 테스트 베이시스를 이해하기 쉽다.

V-Model = 개발 단계 ↔ 대응하는 테스트 단계

2. 반복적 접근

제품이나 개발 과정을 한 번에 완성하지 않고, 여러 번 개발하고 평가하면서 점진적으로 개선하는 방식이다.

특징

• 초기 요구사항이 완전히 명확하지 않아도 개발을 시작할 수 있다.
• 사용자나 고객의 피드백을 빠르게 반영할 수 있다.
• 새로운 기술이나 요구사항 변화가 많은 프로젝트에 유리하다.
• 개발 과정에서 문제나 위험을 비교적 빠르게 발견할 수 있다.
• 제품을 반복적으로 수정하면서 점진적으로 완성도를 높인다.

단점

• 반복 횟수와 범위를 예측하기 어려울 수 있다.
• 요구사항이 계속 변경되면 일정이나 비용 관리가 어려워질 수 있다.
• 반복 과정에서 설계나 문서가 지속적으로 변경될 수 있다.
• 프로젝트 범위를 명확하게 관리하지 않으면 개발 범위가 계속 늘어날 수 있다.

적합한 상황

• 요구사항이 명확하지 않은 경우
• 고객의 의견을 지속적으로 반영해야 하는 경우
• 새로운 기술을 사용하는 경우
• 개발 과정에서 요구사항 변경 가능성이 높은 경우
• 위험을 단계적으로 확인하면서 개발해야 하는 경우

대표 모델

• Prototyping Model
• Spiral Model
• Incremental Model
• Iterative Model
• Agile 계열

2-1. 원형 모델 (Prototyping Model)

먼저 간단하게 만들어 보여주고 고객의 의견을 받는다.
Prototyping = 먼저 보여주고 → 요구사항을 구체화

Prototype 제작 → 사용자 확인 → Feedback → 요구사항 구체화

초기에 요구사항을 완전히 파악하기 어려울 때 Prototype을 빠르게 만들어
고객이나 사용자에게 보여주고, 그 피드백을 통해 요구사항을 구체화하는 개발 방식이다.

Prototype의 목적

Prototype은 일반적으로 완성된 제품을 만드는 것이 목적이라기보다,
고객이 실제로 원하는 것이 무엇인지 확인하기 위한 시제품에 가깝다.

따라서 완벽한 품질보다는 빠르게 만들어 확인하고 피드백을 얻는 것이 중요하다.

특징

• 요구사항이 명확하지 않아도 개발을 시작할 수 있다.
• Prototype을 통해 사용자와 개발자가 요구사항을 함께 확인한다.
• 사용자 Feedback을 반복적으로 반영한다.
• 요구사항을 점차 구체화한다.

장점

• 사용자의 의견을 빠르게 받을 수 있다.
• 요구사항을 보다 정확하게 파악할 수 있다.
• 요구사항 변경에 유연하다.
• 사용자와 개발자 사이의 이해 차이를 일찍 발견할 수 있다.

단점

• 사용자가 Prototype을 완성된 제품으로 오해할 수 있다.
• 반복적인 요구사항 변경으로 일정이나 범위 관리가 어려워질 수 있다.
• 중간 산출물을 명확하게 관리하기 어려울 수 있다.

적합한 상황

• 고객의 요구사항이 명확하지 않은 경우
• 사용자의 의견을 빠르게 확인해야 하는 경우
• UI/UX나 새로운 서비스 아이디어를 검증하는 경우
• 새로운 기술의 실현 가능성을 확인하고 싶은 경우

2-2. 나선형 모델 (Spiral Model)

Risk를 분석하면서 반복적으로 개발한다.

나선형 모델은 폭포수 모델의 체계적인 개발 방식과 Prototype 모델의 반복적인 특성에 Risk 관리를 결합한 모델이다.

계획 → Risk 분석 → 개발 및 검증 → 평가 → 다음 반복

특징

• 반복적으로 개발한다.
• 각 반복 과정에서 Risk를 식별하고 분석한다.
• 위험도가 높은 부분을 우선적으로 확인할 수 있다.
• 개발된 결과물을 계속 발전시켜 최종 시스템을 완성한다.

장점

• 프로젝트의 Risk를 조기에 발견할 수 있다.
• 큰 위험을 한 번에 감수하지 않고 단계적으로 개발할 수 있다.
• 요구사항 변경에 비교적 유연하다.
• 결과를 확인하면서 투자나 개발 방향을 조정할 수 있다.
• 대규모·장기간 프로젝트에 적합하다.

단점

• 모델 자체가 복잡하다.
• 반복할 때마다 Risk, 일정, 비용 등을 다시 관리해야 한다.
• Risk 분석 능력이 필요하다.
• 고객 피드백이나 의사결정에 시간이 많이 필요할 수 있다.

2-3. 점증적 모델 (Incremental Model)

기능을 조금씩 추가하면서 시스템의 범위를 넓힌다.

전체 시스템을 한 번에 완성하는 것이 아니라,
기능이나 서브 시스템을 나누어 개발하고 Release하면서 최종 시스템의 범위를 점차 확장하는 방식이다.

1차 : 로그인
↓
2차 : 로그인 + 회원가입
↓
3차 : 로그인 + 회원가입 + 마이페이지

특징

• 전체 시스템을 여러 Increment로 나누어 개발한다.
• 각 Increment는 사용 가능한 형태로 Release할 수 있다.
• 핵심 기능을 먼저 개발하고 이후 기능을 추가할 수 있다.
• 각 Increment 내부에서는 분석 → 설계 → 구현 → 테스트 같은 순차적 개발이 이루어질 수도 있다.

장점

• 핵심 기능을 먼저 출시할 수 있다.
• 전체 시스템 완성 전에도 일부 기능을 사용할 수 있다.
• 빠르게 사용자 Feedback을 받을 수 있다.
• 개발을 기능 단위로 나누어 진행할 수 있다.

단점

• Release가 많아질수록 관리가 복잡해질 수 있다.
• 여러 기능을 병행 개발하면 통합 문제가 발생할 수 있다.
• 각 기능이 최종적으로 하나의 시스템으로 통합되므로 전체 구조를 고려해야 한다.

2-4. 반복적 모델 (Iterative Model)

기존 결과물을 반복적으로 개선하면서 완성도를 높인다.

처음부터 완벽한 제품을 만드는 것이 아니라 개발된 결과물을 반복적으로 수정하고 개선하여 최종 제품으로 발전시키는 방식이다.

로그인 기능 v1
↓
Feedback
↓
로그인 기능 v2
↓
테스트
↓
로그인 기능 v3

특징

• 기존 결과물을 폐기하지 않고 계속 발전시킨다.
• 사용자 Feedback을 다음 Iteration에 반영한다.
• 요구사항을 개발 과정에서 점차 구체화할 수 있다.
• 제품이 반복적으로 진화한다.

장점

• 고객의 요구사항을 지속적으로 반영하기 쉽다.
• 처음부터 요구사항이 완전히 명확하지 않아도 개발할 수 있다.
• 실제 결과물을 보면서 제품을 개선할 수 있다.
• 기능의 완성도를 단계적으로 높일 수 있다.

단점

• 여러 Version을 관리해야 한다.
• 요구사항 변경이 많으면 일정이 지연될 수 있다.
• 반복 횟수가 많아질수록 프로젝트 관리가 복잡해질 수 있다.

2-5. Incremental과 Iterative의 차이

2-5. Incremental과 Iterative의 차이

둘 다 개발을 한 번에 끝내지 않는다는 점에서는 비슷하지만, 무엇을 변화시키는지에 차이가 있다.

구분	Incremental	Iterative
핵심	기능을 추가	기존 기능을 개선
변화	제품의 범위를 확대	제품의 완성도를 향상
예시	로그인 → 회원가입 → 마이페이지 추가	로그인 v1 → v2 → v3 개선

Incremental = 기능을 조금씩 추가
Iterative = 기존 기능을 반복해서 개선

실제 프로젝트에서는 두 방식을 함께 사용하는 경우가 많다.

정리

• 요구사항이 명확하고 변경 가능성이 낮다면 → 순차적 접근
• 요구사항이 불명확하거나 새로운 기술·변경 가능성이 크다면 → 반복적 접근

하지만 실제 프로젝트에서는 하나의 방식만 사용하기보다 여러 접근 방식을 혼합하여 사용하는 경우가 많다.