소프트웨어 공학 100 주제 시리즈의 61번째 글이다. (카테고리: 프로세스와 방법론)

한 줄 요약

프로세스 모델은 “어느 것이 더 좋은가” 로 고르는 것이 아니라 그 모델이 깔고 있는 가정이 우리 프로젝트에서 참인가 로 고른다. 폭포수는 요구사항을 미리 알 수 있다는 가정, V 모델은 각 명세 수준마다 짝이 되는 검증 수준이 있다는 가정, 점증·반복은 일찍 보여 주고 배울 수 있다는 가정, 나선은 위험이 다음 행동을 정한다는 가정 위에 서 있다.

왜 필요한가

네 모델의 그림은 소프트웨어 개발 생명주기 글에서 이미 봤다. 그림을 아는 것과 고를 줄 아는 것은 다르다. 현장에서 생기는 문제는 대개 이렇다.

  • 요구사항이 매주 바뀌는 사내 웹 서비스에 계약서 양식 그대로 “분석 3개월 → 설계 2개월 → 구현” 일정을 박는다. 석 달 뒤 분석서는 이미 낡았다.
  • 반대로 인증 기관 심사를 받아야 하는 임베디드 제어 소프트웨어에서 “애자일이니까” 추적성 문서를 생략한다. 심사 직전에 몇 달치 문서를 거꾸로 만든다.
  • “우리는 반복 개발을 한다” 면서 실제로는 3개월짜리 미니 폭포수를 네 번 이어 붙인다. 위험한 부분은 마지막 반복으로 밀린다.

세 경우 모두 모델의 이름은 골랐지만 가정은 확인하지 않았다.

핵심 개념

폭포수: 가정을 명시하면 쓸 곳이 보인다

Winston Royce 의 1970년 논문이 실제로는 “한 번에 쭉 내려가는” 폭포수를 권하지 않았다는 이야기는 SE100 #009 에서 원문으로 자세히 다룬다. 여기서는 결론만 쓴다. Larman 과 Basili 는 Iterative and Incremental Development: A Brief History(IEEE Computer, 2003)에서 Royce 가 “처음 개발하는 프로그램이라면 고객에게 최종 인도되는 판이 사실상 두 번째 판이 되도록 하라” 고 권했고, 30개월 프로젝트라면 10개월짜리 파일럿 모델을 둘 수 있다고 썼다고 정리한다.

폭포수를 쓸지 판단하는 데 가장 쓸모 있는 글은 오히려 Boehm 쪽이다. Boehm 은 Spiral Development: Experience, Principles, and Refinements(CMU/SEI-2000-SR-008)에서 폭포수가 성공하려면 다음 여섯 가정이 모두 참이어야 한다고 적었다.

# 가정 깨지는 전형적 상황
1 요구사항을 구현 전에 알 수 있다 새 사용자 화면 — “보면 알겠다(IKIWISI)”
2 요구사항에 해결 안 된 고위험 함의가 없다 성능·보안·외부 제품(COTS) 선택이 불확실
3 요구사항의 성격이 개발·진화 중 크게 바뀌지 않는다 시장·기술 변동이 큰 전자상거래
4 요구사항이 모든 핵심 이해관계자의 기대와 양립한다 사용자는 원하지만 예산이 감당 못 함
5 구현에 맞는 아키텍처가 잘 알려져 있다 처음 해 보는 규모·구조
6 순차로 진행할 만큼 달력 시간이 있다 출시 시점이 정해진 신규 서비스

그리고 이렇게 덧붙인다. 여섯 가정이 모두 참이라면 요구사항을 미리 명세하지 않는 것이 오히려 위험이고, 그때 폭포수는 나선 모델의 위험 주도적 특수 사례가 된다. 폭포수는 “낡은 모델” 이 아니라 조건부로 옳은 모델이다.

V 모델: 명세 수준과 검증 수준의 짝

V 모델은 흔히 “폭포수에 테스트를 붙인 것” 으로 소개되지만 핵심은 짝짓기다. 시스템 공학 쪽에서 Forsberg 와 Mooz 가 The Relationship of System Engineering to the Project Cycle(INCOSE, 1991)에서 정리한 그림이 대표적이다. 왼쪽 팔은 분해(decomposition)와 정의, 오른쪽 팔은 통합(integration)과 검증이다.

  사용자 요구 ─────────────────────────── 인수 테스트(validation)
     시스템 요구 ───────────────────── 시스템 테스트
         아키텍처 설계 ────────── 통합 테스트
             상세 설계 ──────── 단위 테스트
                     \  구현  /

가로선이 V 모델의 본체다. 각 명세를 쓰는 그 시점에 반대편 검증의 기준을 같이 정한다. 시스템 요구를 쓰면서 시스템 테스트의 합격 기준을 쓰고, 아키텍처를 그리면서 통합 테스트가 확인할 인터페이스를 정한다. 그래서 요구에서 테스트까지의 추적성(SE100 #019 에서 다룬다)이 계약·인증 요건인 안전 필수 도메인에서 V 모델의 짝짓기 구조가 특히 잘 맞는다.

오해 하나: V 모델이 오른쪽 팔의 테스트를 마지막에 몰아서 하라는 뜻은 아니다. 가로선의 의미는 “검증 계획을 일찍 세운다” 이지 “검증 실행을 늦춘다” 가 아니다.

점증과 반복: 비슷하지만 다른 두 축

구분 점증(incremental) 반복(iterative)
질문 무엇을 조각으로 나눠 차례로 인도하나 같은 것을 몇 번 고쳐 가며 나아지게 하나
단위 기능 묶음 설계·구현의 개정
위험 앞 조각의 구조가 뒤 조각을 막을 수 있다 끝없이 다듬기만 할 수 있다
현대 실무 스프린트마다 동작하는 증분 리팩터링, 피드백 반영

Larman 과 Basili 는 두 말을 묶어 IID 라 부르고, 그 뿌리를 1930년대 Shewhart 의 계획-실행-연구-조치(PDSA) 순환까지 거슬러 올라간다. 또한 1970년대 IBM 연방 시스템 부문(FSD)과 TRW 의 대형 국방 프로젝트에서 이미 IID 가 쓰였다고 기록한다. “반복 개발은 애자일과 함께 나온 새것” 이라는 인식은 사실과 다르다.

그들이 짚은 공통점이 실무 판단 기준이 된다. 방법들은 반복 길이나 타임박스 사용에서 달랐지만 모두 “한 번에 끝까지 가는, 문서 주도의, 관문식 순차 진행” 을 피하려 했다.

나선: 모델을 고르는 모델

Boehm 의 A Spiral Model of Software Development and Enhancement(IEEE Computer, 1988)는 다른 세 모델과 층위가 다르다. 앞의 SEI 보고서는 나선 모델을 “위험 주도의 프로세스 모델 생성기” 라고 정의한다. 위험 양상에 따라 한 프로젝트가 점증, 폭포수, 진화적 프로토타이핑 또는 그 일부를 고를 수 있다는 뜻이다. 자세한 원리(불변 조건, 앵커 포인트)는 SE100 #062 에서 다룬다.

한 장으로 비교

모델 핵심 가정 피드백이 처음 오는 때 잘 맞는 곳 잘 안 맞는 곳
폭포수 위 여섯 가정이 참 통합·인수 시점 반복 구축하는 익숙한 시스템, 고정 범위 계약 신규 사용자 경험, 불확실한 기술
V 모델 명세마다 검증 짝을 정할 수 있다 설계 검토(문서), 실행은 후반 인증·규제 도메인 요구가 자주 바뀌는 서비스
점증·반복 일찍 보여 주고 배울 수 있다 첫 증분 대부분의 제품 개발 쪼개서 인도할 수 없는 일회성 전환
나선 위험이 다음 행동을 정한다 첫 위험 해소 활동 대형·고위험·다이해관계자 위험 분석 역량이 없는 소규모 팀

실무 적용

모델 선택 체크리스트

프로젝트 시작 회의에서 아래 질문에 “예/아니오/모름” 으로 답해 본다.

[요구]  사용자 화면·업무 흐름을 실제로 보여 주기 전에 확정할 수 있는가?
[기술]  핵심 아키텍처·성능을 이미 비슷한 시스템에서 검증해 봤는가?
[변동]  개발 기간 중 시장·규정이 바뀔 가능성이 낮은가?
[규제]  외부 심사가 단계별 산출물과 추적성을 요구하는가?
[인도]  기능을 나눠서 먼저 써 보게 할 수 있는가?
[시간]  순차 진행해도 출시 시점을 맞출 수 있는가?
  • 앞의 세 질문(요구·기술·변동)과 시간에 모두 “예” → 폭포수 계획이 합리적이다. 단계 사이 검토를 형식적으로 두지 말 것.
  • “규제” 가 “예” → V 모델의 짝짓기(명세-검증 추적)를 유지하되, 실행은 반복으로 할 수 있다. 둘은 배타적이지 않다.
  • “요구” 나 “기술” 이 “아니오/모름” → 첫 반복을 그 불확실성을 해소하는 데 쓴다(프로토타입, 스파이크). 이것이 나선의 사고방식이다.
  • “인도” 가 “예” → 증분 단위로 인도하고 피드백 루프를 짧게 둔다.

혼합이 기본이다

현실의 프로세스는 거의 혼합형이다. 예를 들어 의료기기 소프트웨어 팀은 다음처럼 섞는다.

lifecycle:
  outer: V-model           # 규제 산출물·추적성 구조
  inner: 2-week iterations # 실제 개발 리듬
  gates:
    - name: requirements-baseline
      evidence: [srs, hazard-analysis, test-plan-draft]
    - name: architecture-baseline
      evidence: [sad, interface-spec, integration-test-plan]
  per_iteration:
    - implement increment
    - unit + integration tests
    - update trace matrix   # 요구 ↔ 설계 ↔ 테스트

바깥은 V, 안은 반복이다. 관문(gate)에서 요구하는 것은 “모든 문서 완성” 이 아니라 그 시점의 의사결정에 필요한 증거다.

흔한 오해와 함정

  • “폭포수 = 나쁜 것, 애자일 = 좋은 것.” Boehm 의 여섯 가정이 모두 참인 프로젝트라면 미리 명세하지 않는 쪽이 위험하다. 문제는 가정이 거짓인데 폭포수를 쓰는 것이다.
  • 미니 폭포수의 연쇄를 반복 개발이라 부른다. Boehm 은 폭포수 가정이 깨질 위험이 큰데도 순차 폭포수를 점증으로 이어 붙이는 방식을 “위험한 나선 흉내(hazardous spiral look-alike)” 로 분류했다. 위험한 부분을 앞 반복에서 해소하지 않으면, 반복을 몇 번 하든 폭포수와 같은 시점에 실패를 발견한다.
  • V 모델의 오른쪽은 나중 일이다. 검증 기준은 왼쪽 팔을 쓸 때 같이 정해야 한다. 오른쪽을 미루면 요구사항이 테스트 불가능한 문장으로 남는다.
  • 점증만 하고 반복은 안 한다. 기능 조각을 쌓기만 하고 앞 조각의 구조를 고치지 않으면 기술 부채가 증분 수에 비례해 쌓인다.

확인 문제

  1. Boehm 이 제시한 폭포수의 여섯 가정 중 새 사용자 인터랙티브 시스템에서 가장 흔히 깨지는 것은 무엇이며, 그 현상을 무엇이라 불렀는가?
  2. V 모델에서 “가로선” 이 의미하는 실무 행동을 한 문장으로 쓰라.
  3. 점증과 반복의 차이를 “무엇을 나누는가 / 무엇을 되풀이하는가” 로 설명하라.
  4. 3개월짜리 순차 개발을 네 번 이어 붙인 계획이 반복 개발의 이점을 얻지 못하는 이유는?
  5. 규제 대상 제품에서 V 모델과 2주 반복을 함께 쓸 수 있는 이유는?

풀이

  1. 가정 1 “요구사항을 구현 전에 알 수 있다”. 사용자가 “말로는 못 하지만 보면 안다” 고 하는 IKIWISI 증후군이다. 그래서 프로토타입·요구·아키텍처를 동시에 다루는 접근이 필요하다.
  2. 각 명세 산출물을 작성할 때 그와 짝이 되는 검증 수준의 합격 기준과 계획을 함께 정한다.
  3. 점증은 인도할 범위를 조각으로 나눠 차례로 내놓는 것이고, 반복은 같은 설계·구현을 피드백에 따라 여러 번 개정하는 것이다.
  4. 위험이 큰 부분을 첫 반복에서 해소하지 않고 순서대로 처리하면, 핵심 가정이 틀렸다는 사실을 여전히 후반에야 발견한다. 반복의 가치는 횟수가 아니라 무엇을 먼저 확인하느냐에 있다.
  5. V 모델은 산출물 간 추적 구조(명세-검증의 짝)를 정하고, 반복은 작업 리듬을 정한다. 반복마다 추적 매트릭스를 갱신하면 두 요구를 모두 만족한다.

더 읽을거리 (References)