소프트웨어 생명주기와 개발 모델 선정 | 정보처리기사 필기

핵심 요약

소프트웨어 생명주기(Software Life Cycle)는 소프트웨어의 필요성 제기와 기획에서 시작해 요구사항 분석, 설계, 구현, 시험, 배포·운영, 유지보수, 폐기에 이르는 전체 흐름이다. 생명주기 모델(Life Cycle Model)은 이 활동들을 어떤 순서와 반복 구조로 수행하고, 어느 시점에 검토·승인할지를 정한 틀이다.

대표 모델은 다음 조건으로 구분한다.

요구가 안정적이고 단계별 승인·추적성이 중요하면 폭포수 모델을 우선 검토한다.
사용자가 원하는 화면이나 업무 규칙이 모호하면 프로토타입 모델로 요구를 구체화한다.
기술·사업·안전 위험이 크면 반복마다 위험을 분석하는 나선형 모델이 적합하다.
우선순위가 변하고 일부 기능부터 인도해야 하면 반복·증분 모델이 유리하다.

소프트웨어 생명주기와 생명주기 모델

소프트웨어 생명주기는 특정 개발 기법 하나가 아니라 소프트웨어가 만들어지고 사용된 뒤 폐기될 때까지의 전 과정을 뜻한다. 대표적인 단계는 다음과 같다.

기획·계획 → 요구사항 분석 → 설계 → 구현 → 시험 → 배포·운영 → 유지보수·폐기

프로젝트와 표준에 따라 단계의 이름이나 경계는 달라질 수 있으며, 여러 단계가 겹치거나 반복될 수도 있다. 유지보수와 폐기도 생명주기의 일부이므로 개발 완료 시점만을 생명주기의 끝으로 보면 안 된다.

생명주기 모델은 이러한 활동을 배치하는 방식이다. 모델을 선택하면 단계별 산출물, 진입·종료 조건, 검토 시점, 변경 처리 방식, 검증·확인 방법을 구체화할 수 있다. 어떤 모델도 모든 프로젝트에 항상 최적인 것은 아니며, 실제 프로젝트에서는 조직 표준과 제약에 맞게 모델을 조정하거나 여러 모델의 요소를 함께 사용하기도 한다.

대표 개발 모델 비교

모델	핵심 흐름	적합한 상황	강점	주의점
폭포수(Waterfall)	한 단계를 완료·검토한 뒤 다음 단계로 순차 진행	요구가 비교적 안정적이고 계약·승인 기준이 명확한 경우	단계·산출물·마일스톤이 명확해 진행 상황과 추적성 관리가 비교적 쉽다	후반에 요구 오류가 발견되면 되돌림 비용이 커질 수 있다
프로토타입(Prototyping)	초기 모형을 만들고 사용자 평가를 받아 요구를 보완	화면, 사용 절차, 업무 규칙 등 요구가 모호한 경우	사용자가 구체적인 결과를 보며 요구를 확인할 수 있다	임시 모형을 완성품으로 오해하거나 성급한 구조를 그대로 제품화할 수 있다
나선형(Spiral)	목표 설정 → 위험 분석·해결 → 개발·검증 → 다음 반복 계획을 순환	규모가 크고 기술·사업·안전 위험이 높은 경우	중요한 위험을 초기에 반복적으로 줄일 수 있다	위험 분석 역량이 필요하고 관리 비용이 커질 수 있다
반복·증분(Iterative·Incremental)	짧은 주기로 결과를 다듬고, 사용 가능한 기능 범위를 단계적으로 확대	요구와 우선순위가 변하며 일부 기능부터 인도할 가치가 있는 경우	조기 인도와 피드백 반영이 가능하다	전체 구조, 인터페이스, 통합 순서와 우선순위를 지속적으로 관리해야 한다

프로토타입의 두 형태

폐기형 프로토타입(Throwaway Prototype): 요구를 확인한 뒤 모형은 버리고, 확인된 요구를 바탕으로 본 시스템을 새로 개발한다.
진화형 프로토타입(Evolutionary Prototype): 초기 모형을 반복적으로 보완해 최종 시스템으로 발전시킨다.

따라서 “프로토타입은 반드시 폐기한다” 또는 “프로토타입은 곧 최종 제품이다”라는 설명은 모두 틀릴 수 있다. 어떤 형태인지 조건을 확인해야 한다.

반복과 증분의 차이

반복 개발은 같은 결과나 기능을 여러 주기에 걸쳐 분석·설계·구현하며 점차 정교하게 만든다.
증분 개발은 각 주기에서 사용 가능한 기능 묶음을 추가해 전체 범위를 넓힌다.

두 방식은 함께 사용되는 경우가 많지만 뜻은 다르다. 또한 반복·증분 개발을 사용한다고 해서 반드시 애자일인 것은 아니다. 애자일은 반복·증분 방식을 자주 활용하지만 가치, 역할, 협업 방식까지 포함하는 별도의 접근이다.

모델 선정 기준

모델명부터 고르기보다 다음 질문을 순서대로 검토한다.

요구 안정성: 요구를 초기에 충분히 확정할 수 있는가, 개발 중 자주 바뀌는가?
위험과 실패 비용: 새로운 기술, 대규모 통합, 안전·보안·사업 실패 위험이 큰가?
사용자 참여: 사용자가 중간 결과를 자주 확인하고 빠르게 피드백할 수 있는가?
인도 주기: 전체 완성 전에도 일부 기능을 먼저 제공할 필요가 있는가?
규제·계약·문서화: 단계별 승인, 감사 증거, 요구 추적성, 공식 산출물이 강하게 요구되는가?
조직과 기술 여건: 프로젝트 규모, 팀 경험, 외부 의존성, 시스템 구조와 인터페이스를 얼마나 안정적으로 관리할 수 있는가?

다음 연결을 기억하면 상황형 선지를 빠르게 판별할 수 있다.

안정된 요구 + 강한 단계별 승인 → 폭포수 모델 후보
모호한 요구 + 사용자 확인 필요 → 프로토타입 모델 후보
높은 위험 + 반복적 위험 감소 필요 → 나선형 모델 후보
변화하는 우선순위 + 단계적 인도 필요 → 반복·증분 모델 후보

시험에서 가르는 핵심

반복마다 위험 분석을 수행한다는 설명은 나선형 모델의 가장 강한 단서다. 단순히 여러 번 개발한다는 이유만으로 나선형이 되는 것은 아니다.
초기에 가시적인 모형을 만들어 사용자와 요구를 확인한다는 설명은 프로토타입 모델의 핵심이다.
단계별 완료 기준, 문서, 검토·승인, 기준선 통제가 강조되면 폭포수 모델을 우선 검토한다.
매 주기 사용 가능한 기능 범위가 늘어난다면 증분 개발이고, 기존 결과의 완성도를 반복해 높인다면 반복 개발이다.
고전적 폭포수 모델은 이전 단계로의 되돌림을 최소화하므로 변경 비용이 커지기 쉽다. 그러나 이를 “변경이나 피드백이 절대 불가능하다”라고 표현하면 지나친 단정이다.
프로토타입은 요구 확인 수단이 될 수 있지만, 그 자체가 성능·보안·유지보수성을 갖춘 운영 제품임을 보장하지는 않는다.

생명주기를 끝까지 보는 기준

개발 모델은 일을 진행하는 방식이며 생명주기는 기획부터 폐기까지의 전체 흐름이다. 초기 타당성 분석에서 기술적 타당성은 필요한 기능·성능을 사용 가능한 기술과 인력으로 구현할 수 있는지, 경제적 타당성은 비용에 비해 기대 편익이 적절한지를 판단한다. 기술적으로 가능하더라도 경제성이 없을 수 있으며 두 판단을 하나로 취급하지 않는다.

V 모델은 개발 단계와 대응하는 시험 활동을 연결한다. 일반적인 대응은 사용자 요구–인수 시험, 시스템 명세–시스템 시험, 상위 구조 설계–통합 시험, 모듈 상세 설계–단위 시험이다. 구체적인 명칭은 조직마다 달라도 '무엇을 명세했는가'와 '무엇을 확인하는가'가 대응해야 한다.

사용자 요구는 인수 시험, 시스템 명세는 시스템 시험, 구조 설계는 통합 시험, 모듈 설계는 단위 시험과 대응한다.

유지보수의 네 목적

구분	변경의 직접적인 목적	예
수정 유지보수	발견된 결함 제거	잘못된 할인 계산 수정
적응 유지보수	외부 환경 변화에 대응	운영체제·외부 인터페이스 변경 대응
완전 유지보수	사용자 가치·성능·사용성 개선	검색 속도 향상, 새 조회 기능
예방 유지보수	잠재 결함과 미래 유지 위험 감소	취약한 내부 구조 정리, 잠재 오류 원인 제거

변경의 결과가 비슷해 보여도 요구가 발생한 이유로 분류한다. 운영체제 변경 대응을 '새 코드를 작성했다'는 이유로 기능 추가라고 보지 않는다. 소프트웨어 위기는 개발 규모 증가에 비해 일정·비용·품질·유지보수성이 충분히 통제되지 않는 문제를 가리킨다. 코드 생산량 하나만 늘려 해결할 수 있는 문제가 아니다.

서비스 폐기 단계에서도 데이터 이전·보존·적절한 파기, 계정과 키의 회수, 외부 연결 해제와 사용자 통지가 필요하다. 프로그램 실행을 멈춘다고 데이터와 권한의 책임까지 자동으로 사라지지는 않는다.