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

한 줄 요약

나선형 모델은 “동그랗게 도는 폭포수” 가 아니다. Boehm 스스로의 정의로는 위험 주도의 프로세스 모델 생성기다. 매 사이클마다 “지금 무엇이 우리를 가장 크게 망칠 수 있는가” 를 묻고, 그 답이 다음에 할 일과 그 일을 얼마나 깊게 할지를 정한다.

왜 필요한가

일정표는 “무엇을 할지” 를 순서대로 나열한다. 그런데 프로젝트를 실제로 무너뜨리는 것은 일정표의 마지막 줄에 숨어 있는 검증 안 된 가정이다. “응답 1초는 당연히 되겠지”, “그 외부 솔루션이 우리 구조에 붙겠지”, “사용자는 이 화면을 원하겠지”.

Boehm 은 Spiral Development: Experience, Principles, and Refinements(CMU/SEI-2000-SR-008, 2000)에서 TRW 의 실제 사례를 든다. 1980년대 초 한 정부 기관의 대형 정보 시스템 계약에 “응답 시간 1초 미만” 이 고정됐다. 수천 쪽 요구사항을 쓴 뒤에야 아키텍트들은 그 요건을 맞추려면 고도로 맞춤화된 캐싱 아키텍처가 필요하고 예상 비용이 1억 달러에 가깝다는 것을 알았다. 고객과 개발사가 사용자 인터페이스와 대표 기능의 프로토타입을 만들어 시험해 보니, 4초 응답이면 사용자를 90% 의 경우 만족시켰고, 그 수준은 다른 아키텍처로 3천만 달러에 가능했다.

1초라는 요건 자체가 위험이었는데, 아무도 그것을 위험으로 다루지 않았다. 나선형 모델은 이런 위험을 계획의 맨 앞으로 끌어내는 장치다.

핵심 개념

원전과 정의

원 논문은 Barry Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer 21(5), 1988 이다. Larman 과 Basili 의 IID 역사 정리에 따르면 1985년 판이 먼저 있었고(흔히 1986년으로 인용된다), 위험으로 사이클의 우선순위를 정한 것이 나선이 처음은 아니지만 “반복마다 별도의 위험 평가 단계를 둔다” 는 개념을 정식화하고 널리 알린 것은 나선 모델이라고 평가한다.

2000년 SEI 보고서에서 Boehm 이 직접 쓴 정의는 이렇다.

나선 개발 모델은 위험 주도의 프로세스 모델 생성기다. 소프트웨어 집약 시스템의 다중 이해관계자 동시 공학을 안내하는 데 쓴다. 두 가지 특징이 있다. 하나는 시스템의 정의·구현 수준은 점점 높이고 위험 수준은 점점 낮추는 순환적 접근이고, 다른 하나는 실현 가능하고 서로 만족할 수 있는 해법에 이해관계자가 약속(commitment)하도록 하는 앵커 포인트 마일스톤이다.

“생성기” 라는 단어가 핵심이다. 위험 양상에 따라 어떤 프로젝트는 점증으로, 어떤 프로젝트는 폭포수로, 어떤 프로젝트는 진화적 프로토타이핑으로 흘러간다. 프로세스 모델이 답해야 할 두 질문 — “다음에 무엇을 할까”, “얼마나 오래 계속할까” — 에 위험이 답한다.

한 사이클의 구성

원래 그림의 네 사분면은 보고서에서 다음 요소로 정리된다.

          ┌─────────────────────────┬──────────────────────────┐
          │ 1. 목표·제약 결정          │ 2. 대안 평가               │
          │  핵심 이해관계자의 목표,     │  제품·프로세스 대안,         │
          │  제약 조건                │  위험 식별과 해소            │
          ├─────────────────────────┼──────────────────────────┤
          │ 4. 검토와 진행 약속         │ 3. 개발·검증               │
          │  이해관계자 검토,           │  이번 사이클의 산출물         │
          │  다음 사이클 계획           │  (프로토타입, 명세, 코드 ...) │
          └─────────────────────────┴──────────────────────────┘

중요한 것은 4번이다. 매 사이클 끝에 이해관계자가 계속할지 결정한다. 그만둘 수도 있다.

여섯 가지 불변 조건

보고서는 “나선이라고 부를 자격” 을 여섯 불변 조건(invariant)으로 못 박는다.

# 불변 조건 지키지 않으면
1 운영 개념·요구·계획·설계·코드를 순차가 아니라 동시에 결정 검증 안 된 요구에 조기 고정 (1초 응답 사례)
2 매 사이클에 목표·제약, 대안, 위험 식별·해소, 이해관계자 검토, 진행 약속을 모두 다룸 핵심 이해관계자에게 받아들여지지 않는 대안에 몰입
3 각 활동에 쏟는 노력의 양을 위험으로 결정 과잉 또는 뒤늦은 위험 해소
4 각 산출물의 상세 수준을 위험으로 결정 위험 없는 부분까지 과잉 명세, 위험한 부분은 과소 명세
5 세 앵커 포인트(LCO, LCA, IOC)로 이해관계자 약속 관리 아키텍처 없는 점증, 요구 표류
6 소프트웨어 초기 개발만이 아니라 시스템과 생명주기 전체에 집중 코드만 보고 운영·전환을 놓침

3번과 4번이 “얼마나 하면 충분한가(how much is enough)” 에 대한 답이다. 프로토타이핑을 얼마나, 테스트를 얼마나, 문서를 얼마나 — 모두 위험이 결정한다.

위험 노출도로 “얼마나 충분한가” 를 정한다

보고서는 출시 전 테스트를 예로 든다. 위험 노출도(risk exposure)는

\[RE = P(\text{손실}) \times S(\text{손실})\]

이다. 테스트를 더 할수록 결함으로 인한 RE 는 내려가고, 출시가 늦어져 시장 점유를 잃는 RE 는 올라간다. 두 RE 의 합이 최소가 되는 지점이 “충분한 테스트” 다. 그 지점은 조직마다 다르다. 보고서는 닷컴 회사라면 훨씬 이르고, 원자력 발전소 같은 안전 필수 제품이라면 훨씬 늦을 것이라고 쓴다.

앵커 포인트 마일스톤

마일스톤 이해관계자의 약속 검토 초점
LCO (Life Cycle Objectives) 아키텍처 작업을 지원한다 사업 관점에서 실현 가능한 아키텍처 선택지가 적어도 하나 있는가
LCA (Life Cycle Architecture) 생명주기 전체를 지원한다 하나의 상세 정의에 약속했는가, 중요한 위험을 모두 없앴거나 받아들일 만한 위험 관리 계획이 있는가
IOC (Initial Operational Capability) 운영을 지원한다 소프트웨어·현장·사용자(운영자, 유지보수자) 준비가 됐는가

보고서의 비유로는 LCO 가 약혼, LCA 가 결혼, IOC 가 첫 아이다. 아키텍처와 서둘러 결혼하면 두고두고 후회한다.

LCO 와 LCA 에서 이해관계자는 운영 개념, 프로토타이핑 결과, 요구 기술서, 아키텍처 기술서, 생명주기 계획, 타당성 근거(feasibility rationale) 여섯 가지를 함께 검토한다. 보고서에 따르면 이 앵커 포인트는 USC 소프트웨어 공학 센터 제휴 워크숍에서 정의됐고, Rational 사가 RUP 의 단계 관문으로 채택했다(SE100 #069 에서 다룬다).

스터드 포커 비유

보고서는 나선 모델의 자금 투입 방식을 스터드 포커에 빗댄다. 칩 몇 개를 걸고 카드 두 장을 받는다. 패가 나쁘면 큰 손해 없이 접는다. 좋으면 더 건다. 매 라운드마다 “정보를 더 사기 위해 칩을 더 넣을 가치가 있는가” 를 판단한다. 처음부터 전 예산을 거는 대신, 불확실성을 줄이는 만큼씩 약속을 늘려 가는 것이다.

실무 적용

위험 목록으로 다음 사이클 정하기

# 위험 노출도 = 발생 확률 × 손실 크기. 숫자는 팀이 추정한 예시 값이다.
risks = [
    # (위험, 확률, 손실(인-주), 해소 활동, 해소 비용(인-주))
    ("결제 PG 연동 규격 불명확", 0.5, 12, "샌드박스 연동 스파이크", 1),
    ("피크 시 응답 2초 요건",     0.3, 20, "부하 프로토타입",       2),
    ("관리자 화면 요구 변동",     0.6,  4, "클릭 가능한 목업",      0.5),
    ("로그 보관 규정 해석",       0.2,  8, "법무 검토 요청",        0.3),
]

for name, p, loss, action, cost in sorted(risks, key=lambda r: -r[1] * r[2]):
    re_ = p * loss
    leverage = re_ / cost          # 해소 비용 대비 위험 감소 효과(단순화)
    print(f"{name:18s} RE={re_:5.1f}  해소={action:16s} 레버리지={leverage:4.1f}")

결제 PG 연동 규격 불명확    RE=  6.0  해소=샌드박스 연동 스파이크     레버리지= 6.0
피크 시 응답 2초 요건      RE=  6.0  해소=부하 프로토타입         레버리지= 3.0
관리자 화면 요구 변동       RE=  2.4  해소=클릭 가능한 목업        레버리지= 4.8
로그 보관 규정 해석        RE=  1.6  해소=법무 검토 요청         레버리지= 5.3

이 표가 다음 사이클의 계획이다. RE 가 높은 두 위험을 이번 사이클에서 해소하고, 그 결과에 따라 아키텍처를 고른다(LCA). 관리자 화면처럼 RE 는 낮지만 해소가 싼 것은 같이 처리한다. 확률·손실은 추정이므로 사이클마다 다시 매긴다.

사이클 끝 검토 질문

  • 이번 사이클에서 해소하려던 위험은 실제로 줄었는가? 근거(프로토타입 수치, 연동 로그)는?
  • 새로 드러난 위험은 무엇인가?
  • 핵심 이해관계자 중 이번 검토에 빠진 사람이 있는가?
  • 다음 사이클에 더 투자할 가치가 있는가, 범위를 줄이거나 멈춰야 하는가?

흔한 오해와 함정

보고서는 그림 때문에 퍼진 오해를 직접 꼽는다. 나선이 폭포수 증분의 연속일 뿐이라는 것, 프로젝트의 모든 것이 하나의 나선을 따른다는 것, 그림의 모든 요소를 표시된 순서대로 방문해야 한다는 것, 이전 결정으로 되돌아갈 수 없다는 것. 모두 틀렸다.

  • 위험을 나열만 한다. 보고서는 “식별한 위험을 관리할 약속이 없는 흠잡을 데 없는 나선 계획” 을 위험한 흉내로 분류한다. 목록이 아니라 해소 활동과 그 결과가 산출물이다.
  • 위험에 둔감한 점증. 첫 증분을 단기 최적 구조로 만들어 이후 증분에서 버리거나 크게 고쳐야 하는 경우. 확장성 위험을 첫 사이클에서 다루지 않은 결과다.
  • 핵심 이해관계자 제외. 단계마다 일부만 참여하면 나중에 받아들여지지 않는 결론이 난다(불변 조건 2).
  • 작은 팀에 무거운 의식. 나선은 상세 수준도 위험으로 정하라고 한다. 위험이 작으면 문서도 작아야 한다. 무거운 나선은 불변 조건 4 위반이다.

확인 문제

  1. Boehm 이 나선 모델을 “프로세스 모델 생성기” 라 부른 이유는?
  2. 불변 조건 3과 4는 각각 무엇을 위험으로 결정하라고 하는가?
  3. 출시 전 테스트의 적정량을 위험 노출도로 설명하라.
  4. LCO 와 LCA 의 차이를 아키텍처 관점에서 한 문장으로 쓰라.
  5. 1초 응답 사례에서 프로토타입이 바꾼 것은 무엇인가?

풀이

  1. 위험 양상에 따라 같은 틀 안에서 점증, 폭포수, 진화적 프로토타이핑 등 서로 다른 프로세스가 선택되기 때문이다. “다음에 무엇을, 얼마나 오래” 를 위험이 정한다.
  2. 3은 각 활동에 쏟는 노력의 양, 4는 각 산출물의 상세 수준이다.
  3. 테스트를 늘리면 결함 손실의 RE 는 줄고 출시 지연에 따른 시장 손실의 RE 는 커진다. 두 합이 최소인 지점이 적정량이고, 조직의 위험 특성에 따라 위치가 다르다.
  4. LCO 는 사업적으로 실현 가능한 아키텍처 선택지가 적어도 하나 있음을 확인하는 시점이고, LCA 는 하나의 상세 정의에 약속하고 중요한 위험을 없앴거나 관리 계획을 갖춘 시점이다.
  5. 검증되지 않은 “1초” 요건이 실제 사용자 요구(4초면 대부분 만족)로 바뀌었고, 그에 따라 훨씬 싼 아키텍처를 고를 수 있었다. 요구 자체가 위험 해소의 대상이었다.

더 읽을거리 (References)