SDLC 모델과 테스트 원칙으로 설계하는 소프트웨어 개발 생명주기

개발을 관리 가능한 과정으로 나누는 이유

소프트웨어 개발 생명주기(Software Development Life Cycle, SDLC)는 계획부터 폐기까지 이어지는 개발 활동을 단계별로 정의하고, 각 단계의 산출물을 분명히 하는 절차다. 개발 과정의 가시성을 확보하고 품질을 보증하기 위한 관리 체계이기도 하다.

대규모 시스템에서는 주먹구구식 개발이 요구사항 변경 관리 실패, 일정 지연, 품질 저하로 이어질 수 있다. 이른바 소프트웨어 위기에 대응하기 위해 SDLC는 비가시적인 개발 작업을 관리 가능한 단위로 나눈다.

수만 라인을 넘어 수백만 라인에 이르는 코드를 다루려면 체계적인 구조가 필요하다.
표준화된 프로세스는 반복되는 실수를 줄이고 개발 효율을 높인다.
초기 단계에서 오류를 발견하면 전체 생명주기 비용(LCC)을 최적화하는 데 도움이 된다.
개발자, 고객, 관리자가 진행 상태를 객관적으로 확인할 수 있다.

프로젝트 조건에 따라 달라지는 개발 모델

SDLC는 하나의 고정된 방식이 아니다. 요구사항의 안정성, 위험 수준, 사용자 피드백의 필요성에 따라 서로 다른 모델을 적용한다.

요구사항이 안정적인 경우의 폭포수 모델

폭포수 모델(Waterfall Model)은 이전 단계가 완료된 뒤 다음 단계로 이동하는 선형 순차 방식이다. 요구사항이 명확하고 변경 가능성이 낮은 항공우주나 금융 시스템 프로젝트에 적합하다.

단계별 산출물이 뚜렷해 관리하기 쉽지만, 요구사항이 바뀌었을 때 대응하기 어렵다. 결과물을 개발 후반에 확인하게 되는 점도 제약이다.

요구를 구체화하는 프로토타입 모델

프로토타입 모델(Prototype Model)은 실제 개발에 앞서 견본품을 만들어 사용자의 요구사항을 구체화하는 방식이다. 비전문가 사용자가 원하는 바를 표현하고 확인하는 과정에 유용하다.

요구사항을 더 정확하게 반영하고 사용자 만족도를 높일 수 있지만, 시제품 제작에는 추가 비용과 시간이 든다.

위험을 반복적으로 다루는 나선형 모델

보헴(Boehm)이 제안한 나선형 모델(Spiral Model)은 폭포수 모델과 프로토타입 모델의 장점에 위험 분석(Risk Analysis)을 결합한다. 계획, 위험 분석, 개발, 고객 평가의 네 단계를 반복하면서 시스템을 점진적으로 완성한다.

대규모 프로젝트의 위험 관리에는 강점이 있지만, 위험 분석 전문가가 필요하고 프로젝트 관리가 복잡해질 수 있다.

핵심 기능부터 내놓는 점진적 모델

점진적 모델(Incremental Model)은 전체 시스템을 여러 모듈로 나누고, 핵심 기능을 먼저 개발해 릴리스한 뒤 이후 기능을 추가하는 방식이다. 사용자가 제품을 빠르게 사용할 수 있다는 점이 특징이다.

유스케이스와 아키텍처를 중심에 둔 RUP

래셔널 통합 프로세스(RUP)는 IBM Rational에서 제안한 반복적 개발 방법론이다. 유스케이스(Use Case) 중심, 아키텍처 기반 개발을 지향하며 객체지향 프로젝트에 많이 활용된다.

도입(Inception), 상세(Elaboration), 구축(Construction), 전이(Transition)의 4단계를 거친다.

모델 선택과 반복 흐름

⤢✕

테스트가 지켜야 할 관점

SDLC 전반에서 품질을 확보하려면 테스트를 단순한 개발 막바지 검증으로 다루지 않아야 한다. 다음 원칙은 테스트 과정에서 놓치기 쉬운 판단 기준을 짚는다.

테스트는 결함이 있음을 보여주는 것: 테스트는 결함이 없음을 증명하는 행위가 아니라 잠재된 결함을 찾는 과정이다.
완벽한 테스팅은 불가능: 모든 경로와 입력을 시험하는 일은 물리적으로 불가능하므로, 리스크 기반의 선택적 테스팅이 필요하다.
초기 테스팅(Early Testing): SDLC 초기 단계부터 테스트를 시작해야 수정 비용을 줄일 수 있다. 요구사항 정의 단계부터 시작한다.
결함 집중(Defect Clustering): 특정 모듈에 결함의 대부분이 집중되는 파레토 법칙이 적용되는 경우가 많다.
살충제 패러독스(Pesticide Paradox): 같은 테스트 케이스를 반복하면 새로운 결함을 더 이상 찾기 어려우므로 주기적으로 갱신해야 한다.
테스팅은 정황(Context)에 의존: 보안 시스템과 일반 웹 사이트에는 서로 다른 테스트 방식이 필요하다.
오류-부재의 궤변(Absence-of-Errors Fallacy): 결함을 제거했더라도 사용자의 요구를 충족하지 못한다면 시스템은 쓸모가 없다.

SDLC는 개발 순서를 나열한 문서가 아니라, 품질을 갖춘 소프트웨어를 안정적으로 공급하기 위한 공학적 약속이다. 프로젝트 규모, 예산, 기술적 난이도에 맞는 모델을 선택하고 초기 단계부터 품질 관리를 이어가야 한다. 변화하는 비즈니스 환경에서는 체계성과 유연성 사이의 균형이 특히 중요하다.

Sources

소프트웨어 공학론, 최은만 저
IEEE Standard for Software Life Cycle Processes
ISTQB Foundation Level Syllabus
IBM Rational Unified Process Documentation