컴퓨터공학 300 주제 시리즈의 181번째 글이다. 전체 지도는 여기.

한 줄 요약

소프트웨어 개발 생명주기(SDLC, Software Development Life Cycle)는 “무엇을 만들지 정하고, 만들고, 확인하고, 내보내고, 고치고, 언젠가 버리는” 전 과정을 단계로 나눠 부르는 이름이다. 모델마다 다른 것은 단계의 목록이 아니라 단계를 도는 방식이다.

왜 필요한가

혼자 쓰는 스크립트는 생명주기를 의식하지 않아도 된다. 머릿속에서 요구사항을 정하고, 짜고, 돌려 보고, 끝이다. 팀이 몇 년 동안 운영하는 서비스는 다르다. 누가 요구사항을 확정하는지, 언제 테스트하는지, 배포는 누가 승인하는지, 장애가 나면 누가 고치는지를 정하지 않으면 일이 겹치거나 빠진다.

생명주기 모델은 이런 질문에 대한 합의된 기본값이다. “우리 팀은 2주마다 한 번 배포한다”, “설계 문서 리뷰를 통과해야 구현을 시작한다” 같은 규칙이 모두 어떤 생명주기 모델에서 나온다. 모델을 알면 팀의 규칙이 왜 그런 모양인지 이해할 수 있고, 규칙이 맞지 않을 때 무엇을 바꿔야 하는지도 보인다.

핵심 개념

단계: 거의 모든 모델이 공유하는 활동

이름은 조금씩 다르지만 대부분의 모델은 다음 활동을 포함한다.

활동 핵심 질문 대표 산출물
요구사항 분석 무엇을, 누구를 위해 만드는가 요구사항 명세, 사용자 스토리
설계 어떤 구조로 만드는가 아키텍처 문서, 인터페이스 정의
구현 실제로 짠다 소스 코드
검증(테스트) 맞게 만들었는가, 맞는 것을 만들었는가 테스트 코드, 테스트 리포트
배포 사용자에게 어떻게 전달하는가 릴리스, 배포 파이프라인
운영·유지보수 살아 있는 동안 어떻게 돌보는가 모니터링, 패치, 개선
폐기 언제, 어떻게 끝내는가 데이터 이전, 서비스 종료 공지

국제 표준 ISO/IEC/IEEE 12207 은 이 활동들을 “소프트웨어 생명주기 프로세스” 라는 이름으로 정리한다. 표준은 특정 모델을 강요하지 않고, 조직이 필요한 프로세스를 골라 조합하도록 한다. IEEE Computer Society 가 내는 SWEBOK(소프트웨어 공학 지식 체계)도 요구사항·설계·구성·테스트·유지보수를 별개의 지식 영역으로 나눈다.

검증(verification)과 확인(validation)은 구분해서 쓰는 것이 좋다. 검증은 “명세대로 만들었는가”, 확인은 “사용자가 정말 원하는 것을 만들었는가” 를 묻는다. 명세가 틀렸으면 검증은 통과하고 확인은 실패한다.

모델 1: 폭포수(Waterfall)

요구사항 → 설계 → 구현 → 테스트 → 배포 → 유지보수
   (앞 단계가 끝나야 다음 단계로)

한 단계를 끝내고 산출물을 확정한 뒤에 다음 단계로 넘어간다. 계획과 문서가 명확하고, 계약·감리가 있는 프로젝트에서 관리하기 쉽다. 약점은 피드백이 늦다는 것이다. 사용자가 실제로 돌아가는 소프트웨어를 처음 보는 시점이 거의 마지막이다. 그때 요구사항 오해가 드러나면 설계부터 다시 해야 한다.

흔히 폭포수의 원전으로 인용되는 Winston Royce 의 1970년 논문은, 사실 순수한 일직선 모델을 위험하다고 지적하고 반복과 피드백을 추가하라고 권했다. “폭포수 = 원래부터 일직선” 은 정확하지 않은 이해다.

모델 2: V 모델

폭포수의 각 단계에 대응하는 테스트 단계를 짝지은 모델이다.

요구사항 분석 ─────────────── 인수 테스트
   시스템 설계 ─────────── 시스템 테스트
      아키텍처 설계 ──── 통합 테스트
         모듈 설계 ── 단위 테스트
                구현

왼쪽에서 내린 결정을 오른쪽의 어떤 테스트가 확인하는지가 분명해진다. 안전이 중요한 분야(자동차, 의료기기 등)에서 추적성(traceability)을 요구할 때 자주 쓰는 틀이다.

모델 3: 반복·점진적(Iterative & Incremental)

전체를 한 번에 만들지 않고, 작은 조각을 여러 번 완성한다. 매 반복이 요구사항부터 테스트까지 짧은 생명주기 한 바퀴다.

[요구→설계→구현→테스트] → 피드백 → [요구→설계→구현→테스트] → 피드백 → ...
      반복 1 (기능 A)                  반복 2 (기능 A 개선 + B)

애자일 방법론(다음 글)과 스크럼은 이 계열이다. 핵심 이점은 사용자가 일찍, 자주 결과물을 본다는 것이다.

모델 4: 나선형(Spiral)

Barry Boehm 이 제안한 모델로, 매 바퀴마다 위험 분석을 명시적으로 한다. “지금 가장 불확실한 것이 무엇인가” 를 먼저 찾아 프로토타입으로 줄인 다음 진행한다. 큰 규모, 높은 위험의 프로젝트에 맞는다.

비교

기준 폭포수 V 모델 반복·점진 나선형
요구사항 변경 수용 어렵다 어렵다 쉽다 중간
첫 동작 결과물 늦다 늦다 이르다 프로토타입으로 이르다
문서·추적성 강하다 매우 강하다 가볍다(팀 재량) 강하다
맞는 상황 요구가 안정적, 계약 중심 규제·안전 요구가 불확실 위험이 큰 대형

어느 모델이 “정답” 인 것은 아니다. 현업 대부분은 반복 모델을 기본으로 하되, 규제가 있는 부분에서는 V 모델식 추적성 문서를 함께 쓰는 식으로 섞는다.

보안도 생명주기 안에 넣는다

미국 NIST 의 SSDF(SP 800-218, Secure Software Development Framework)는 보안 활동을 개발이 끝난 뒤에 붙이지 말고 생명주기 전체에 넣으라고 권고한다. 조직 준비, 소프트웨어 보호, 잘 보호된 소프트웨어 생산, 취약점 대응의 네 묶음으로 실천 항목을 정리한다.

직접 해 보기

폭포수와 반복 모델에서 “사용자 피드백이 처음 도착하는 시점” 이 얼마나 다른지 단순한 모형으로 계산해 본다. 6개 기능을 각각 요구·설계·구현·테스트 1주씩 들여 만든다고 가정한다(숫자는 설명용 가정이다).

FEATURES = 6
PHASES = ["요구", "설계", "구현", "테스트"]  # 단계당 1주

def waterfall():
    # 모든 기능의 요구 → 모든 기능의 설계 → ... 순서
    week = 0
    for phase in PHASES:
        week += FEATURES  # 기능 6개 분량을 한 단계에서 처리
    return [week] * FEATURES  # 모든 기능이 마지막에 한 번에 나간다

def iterative():
    week, releases = 0, []
    for _ in range(FEATURES):
        week += len(PHASES)  # 기능 하나를 끝까지 만든다
        releases.append(week)  # 그 주에 사용자가 본다
    return releases

for name, fn in [("폭포수", waterfall), ("반복", iterative)]:
    r = fn()
    print(f"{name:4s} 첫 피드백 {r[0]:2d}주차, 마지막 {r[-1]:2d}주차, "
          f"기능별 평균 대기 {sum(r)/len(r):.1f}주")

실행 결과:

폭포수  첫 피드백 24주차, 마지막 24주차, 기능별 평균 대기 24.0주
반복   첫 피드백  4주차, 마지막 24주차, 기능별 평균 대기 14.0주

총 작업량은 같다. 끝나는 시점도 같다. 달라지는 것은 사용자가 언제 처음 보느냐다. 4주차에 첫 기능을 본 사용자가 “이게 아니다” 라고 말하면 나머지 다섯 기능의 방향을 바꿀 수 있다. 폭포수에서는 그 말을 24주차에 듣는다. 이 모형은 단순화가 크다. 실제로는 반복마다 통합·배포 비용이 들고, 폭포수도 중간 산출물 리뷰로 피드백을 받는다. 그래도 피드백 지연이라는 핵심 차이는 잘 보여 준다.

현업에서는

  • 티켓 상태가 곧 생명주기다. 이슈 트래커의 To Do → In Progress → In Review → Done 같은 상태 전이는 한 기능이 도는 작은 생명주기를 그대로 옮긴 것이다.
  • 배포 파이프라인은 검증 단계를 자동화한 것이다. 홈랩 k3s 클러스터에 서비스를 올릴 때도 “코드 푸시 → 테스트 → 이미지 빌드 → 매니페스트 갱신 → 롤아웃” 순서가 고정돼 있다. 사람이 단계를 건너뛰지 못하게 기계가 순서를 강제한다.
  • 운영과 폐기를 잊기 쉽다. 생명주기에서 가장 긴 기간은 대개 운영·유지보수다. 새 서비스를 띄울 때 모니터링, 로그 보존 기간, 종료 조건을 같이 정해 두지 않으면 아무도 쓰지 않는 서비스가 리소스만 먹으며 남는다.
  • 규제 산업은 섞어 쓴다. 금융·의료 쪽은 개발은 스프린트로 하면서 변경 승인과 추적성 문서는 V 모델처럼 남기는 경우가 흔하다.

확인 문제

  1. 검증(verification)과 확인(validation)의 차이를 한 문장씩 설명하라.
  2. 폭포수 모델의 가장 큰 약점을 “피드백” 이라는 단어를 써서 설명하라.
  3. V 모델에서 “아키텍처 설계” 단계에 대응하는 테스트 단계는 무엇인가?
  4. 나선형 모델이 다른 모델과 구별되는 핵심 활동은 무엇인가?
  5. 위 파이썬 모형에서 기능 수를 12개로 늘리면 반복 모델의 첫 피드백 시점은 바뀌는가?

풀이

  1. 검증은 명세대로 만들었는지 확인하는 것이고, 확인은 사용자가 원하는 것을 만들었는지 확인하는 것이다.
  2. 사용자가 동작하는 결과물을 마지막에야 보므로, 요구사항 오해에 대한 피드백이 가장 비싼 시점에 도착한다.
  3. 통합 테스트.
  4. 매 반복마다 명시적으로 위험을 분석하고, 가장 큰 위험부터 프로토타입 등으로 줄인다.
  5. 바뀌지 않는다. 첫 기능 하나만 끝나면 되므로 여전히 4주차다. 폭포수의 첫 피드백은 48주차로 밀린다.

더 읽을거리 (References)