소프트웨어 공학 100 주제 시리즈의 75번째 글이다. (카테고리: 프로젝트 관리와 추정)

한 줄 요약

위험(risk)은 아직 일어나지 않았지만 일어나면 프로젝트를 해치는 사건이다. 위험 관리는 위험을 찾고, 크기를 매기고, 순서를 정한 뒤(평가), 대응을 계획하고 실행하고 추적하는(통제) 반복 활동이다. 핵심 도구는 확률과 손실을 곱한 위험 노출도(risk exposure) 하나다.

왜 필요한가

실패한 프로젝트의 회고를 읽어 보면 놀라울 만큼 자주 이런 문장이 나온다. “사실 다들 알고 있었다.” 외부 업체의 API 가 늦을 거라는 것, 핵심 개발자가 이직을 고민한다는 것, 성능 요구가 현재 구조로는 무리라는 것을 누군가는 알았다. 다만 말할 자리가 없었거나, 말했어도 아무도 책임지고 추적하지 않았다.

위험 관리가 없으면 위험은 문제(issue) 가 된 뒤에야 다뤄진다. 그 시점에는 선택지가 줄고 비용은 커진다. Boehm 은 위험 관리의 목적을 위험 항목이 성공적인 운영에 대한 위협이 되거나 대규모 재작업의 원인이 되기 전에 식별하고 다루고 제거하는 것이라고 정의했다.

핵심 개념

위험 노출도 — Boehm 1991

Barry Boehm 의 Software Risk Management: Principles and Practices(IEEE Software, 1991)는 이 분야의 출발점이다. 그는 위험 노출도를 이렇게 정의한다.

\[RE = P(UO) \times L(UO)\]

P(UO) 는 불만족스러운 결과(unsatisfactory outcome)가 일어날 확률, L(UO) 는 그 결과가 일어났을 때 영향받는 당사자의 손실이다. 그 결과 자체를 정밀하게 확률로 매기기는 어렵다. 그래서 Boehm 은 우선순위를 정하는 목적이라면 확률과 손실을 0~10 의 상대 척도로 매겨도 충분하다고 쓴다. 논문의 위성 실험 예시에서는 “데이터 축소 소프트웨어 오류로 추가 작업 발생” 이 확률은 높지만(8) 복구 가능해 손실이 낮아 RE 가 낮게 나온다. “프로세서 메모리 부족” 은 손실은 크지만 확률이 낮아(1) 역시 RE 가 낮다.

두 단계, 여섯 활동

Boehm 은 위험 관리를 두 개의 주 단계로 나눈다.

위험 관리
├─ 위험 평가 (risk assessment)
│   ├─ 식별   : 체크리스트, 가정 분석, 분해 → 위험 항목 목록
│   ├─ 분석   : 확률·손실 추정 (프로토타입, 벤치마크, 시뮬레이션, 비용 모형)
│   └─ 우선순위: 위험 노출도 순위, 위험 감소 효과 대비 비용 분석
└─ 위험 통제 (risk control)
    ├─ 관리 계획: 항목별 대응 계획과 전체 계획의 통합
    ├─ 해소     : 프로토타입, 시뮬레이션, 인력 보강, 설계 변경, 점증 개발
    └─ 감시     : 해소 진척 추적, 마일스톤 추적, Top-10 목록 검토

Boehm 의 Top 10 위험 항목

같은 논문의 표 1 은 경험 많은 프로젝트 관리자 여러 명을 조사해 뽑은 소프트웨어 프로젝트의 상위 10개 위험 원천과, 그때까지 가장 성공적이었던 대응 기법이다.

순위 위험 항목 대표 대응
1 인력 부족 최고 인재 배치, 역할 매칭, 팀 빌딩, 교차 훈련
2 비현실적 일정·예산 다중 출처 비용·일정 추정, 비용 맞춤 설계, 점증 개발
3 잘못된 기능 개발 조직·임무 분석, 사용자 조사, 프로토타입
4 잘못된 UI 개발 프로토타입, 시나리오, 사용자 참여
5 금도금(gold-plating) 요구사항 정리, 비용-효익 분석
6 요구사항 변경의 연속 높은 변경 문턱, 정보 은닉, 점증 개발(변경을 다음 증분으로)
7 외부 제공 컴포넌트 부족 벤치마크, 검사, 참조 확인
8 외부 수행 작업 부족 참조 확인, 계약 전 감사, 경쟁 설계·프로토타입
9 실시간 성능 부족 시뮬레이션, 벤치마크, 모델링, 프로토타입
10 컴퓨터 과학 역량의 한계 초과 기술 분석, 비용-효익 분석, 프로토타입

30년 넘은 목록이지만 1~3번은 오늘의 프로젝트 회고에서도 그대로 나온다.

Top-10 위험 항목 추적

Boehm 이 실무에서 가장 효과적이라고 꼽은 기법은 단순하다. 상위 위험 항목 목록을 만들고, 정기 검토 회의를 그 목록의 진척 요약으로 시작하는 것이다. 요약에는 각 항목의 이번 순위, 지난 순위, 목록에 오른 개월 수, 해소 진척을 적는다. 그는 20명이 넘는 큰 프로젝트라면 이 검토를 매월, 프로젝트 관리자의 상사급이 주재하라고 권한다. 숫자는 7개든 12개든 상관없다고 덧붙인다.

체계적 식별 — SEI 위험 분류 체계

체크리스트가 기억에 의존하지 않도록 SEI 는 1993년 Taxonomy-Based Risk Identification(CMU/SEI-93-TR-006)을 냈다. 위험 원천을 세 개의 대분류 아래 요소와 속성으로 나누고, 속성마다 질문지를 붙였다.

대분류 요소
제품 엔지니어링 요구사항, 설계, 코드·단위 테스트, 통합·테스트, 엔지니어링 특수 분야(안전·보안·신뢰성 등)
개발 환경 개발 프로세스, 개발 시스템, 관리 프로세스, 관리 방법, 작업 환경
프로그램 제약 자원(일정·인력·예산·시설), 계약, 프로그램 인터페이스(고객·협력사·경영진·벤더)

세 번째 분류가 중요하다. 보고서는 이를 “프로젝트가 직접 통제할 수 없지만 성공에 큰 영향을 주는 외부 요인” 으로 정의한다. 기술 위험만 보는 팀이 가장 자주 놓치는 영역이다.

표준

위험 관리 프로세스는 ISO/IEC/IEEE 16085:2021 Systems and software engineering — Life cycle processes — Risk management 로 표준화되어 있다. 생애주기 프로세스 표준(ISO/IEC/IEEE 12207, 15288)의 위험 관리 프로세스를 구체화한 문서다.

실무 적용

위험 등록부와 우선순위

# 위험 등록부: 확률(P)·손실(L)은 Boehm 이 제안한 0~10 상대 척도
risks = [
    # (위험, P, L, 대응 비용[인-일], 대응 후 P)
    ("결제 PG 사 API 일정 지연",        6, 8, 3, 3),
    ("핵심 백엔드 개발자 이탈",          3, 9, 5, 2),
    ("트래픽 피크 시 응답 지연",          5, 7, 8, 2),
    ("디자인 시안 확정 지연",            7, 4, 1, 4),
    ("신규 ORM 학습 곡선",               4, 3, 2, 2),
]
print(f"{'위험':<22}{'RE':>4}{'대응후RE':>8}{'감소/비용':>10}")
for name, p, l, cost, p2 in sorted(risks, key=lambda r: -r[1] * r[2]):
    re0, re1 = p * l, p2 * l
    print(f"{name:<20}{re0:>4}{re1:>8}{(re0 - re1) / cost:>10.1f}")

실행 결과:

위험                      RE   대응후RE     감소/비용
결제 PG 사 API 일정 지연     48      24       8.0
트래픽 피크 시 응답 지연        35      14       2.6
디자인 시안 확정 지연          28      16      12.0
핵심 백엔드 개발자 이탈         27      18       1.8
신규 ORM 학습 곡선          12       6       3.0

RE 순서와 “비용 대비 감소 효과” 순서는 다르다. 디자인 시안 지연은 RE 3위지만, 하루 투자로 RE 를 12 줄인다. 이런 항목은 바로 처리한다. Boehm 이 우선순위 기법으로 위험 노출도와 함께 위험 감소 효과 분석을 든 이유다. (마지막 열의 계산식은 이 글의 예시다.)

대응 전략 네 가지

전략 뜻 예
회피 위험을 낳는 선택 자체를 바꾼다 검증 안 된 신기술 대신 익숙한 스택
전가 손실을 다른 주체에 넘긴다 SLA·위약금 조항, 관리형 서비스
완화 확률이나 손실을 줄인다 스파이크·프로토타입, 페어링으로 지식 분산
수용 감수하되 예비 계획과 신호를 정해 둔다 버퍼 확보, “2주 지연 시 범위 축소” 트리거

사전 부검(pre-mortem)

Gary Klein 은 HBR 2007년 9월호 글에서 사전 부검을 제안했다. 팀원들이 프로젝트가 이미 실패했다고 가정하고 그럴듯한 실패 이유를 각자 적는다. 그는 계획 단계에서 우려를 말하기를 꺼리는 분위기가 프로젝트 실패의 한 원인이라고 보고, 이 방식이 지식 있는 반대 의견을 안전하게 꺼내게 한다고 설명한다. 플래닝 포커(SE100 #074)의 “먼저 각자 적기” 와 같은 원리다.

사전 부검 30분 진행
1. (2분) "6개월 뒤, 이 프로젝트는 처참하게 실패했다." 를 선언
2. (8분) 각자 조용히 실패 이유를 적는다
3. (10분) 한 사람씩 한 개씩 돌아가며 발표 → 화이트보드
4. (10분) 묶고, 상위 항목을 위험 등록부로 옮기고 담당자 지정

흔한 오해와 함정

  • “위험 = 문제.” 위험은 아직 일어나지 않은 것이다. 이미 일어난 것은 이슈로 관리한다. 둘을 한 목록에 섞으면 급한 이슈가 위험을 밀어낸다.
  • “한 번 작성하면 끝.” Boehm 의 핵심은 감시다. 순위가 매달 바뀌는 살아 있는 목록이어야 한다.
  • “확률을 정밀하게 추정해야 한다.” Boehm 도 체크리스트의 확률 범위가 정밀한 추정을 지원하지 못한다고 인정했다. 우선순위를 정하는 데는 상대 척도면 충분하다.
  • “위험은 기술 문제다.” SEI 분류의 세 번째 범주(계약, 고객, 벤더, 정치)가 기술 위험보다 더 자주 프로젝트를 흔든다.
  • “위험을 말하면 부정적인 사람이 된다.” 이 문화가 있으면 위험 관리는 형식만 남는다. 사전 부검처럼 실패 상상을 공식 절차로 만드는 이유다. 반복 주기마다 가장 큰 위험부터 다루는 사고방식은 Boehm 의 나선형 모형으로 이어진다(SE100 #062 에서 다룬다).

확인 문제

  1. 위험 노출도의 정의를 쓰고 두 항의 뜻을 설명하라.
  2. Boehm 이 말한 위험 관리의 두 주 단계와 각각의 하위 활동 세 개는?
  3. RE 는 같은데 대응 비용이 다른 두 위험이 있다. 무엇을 먼저 다뤄야 하는가?
  4. SEI 위험 분류 체계의 세 대분류는 무엇이며, “프로그램 제약” 이 특별히 중요한 이유는?
  5. 사전 부검이 일반적인 “위험 브레인스토밍” 보다 나은 점은?

풀이

  1. RE = P(UO) × L(UO). P(UO)는 불만족스러운 결과가 일어날 확률, L(UO)는 그 결과로 영향받는 당사자가 입는 손실이다.
  2. 위험 평가(식별, 분석, 우선순위)와 위험 통제(관리 계획, 해소, 감시).
  3. 같은 비용으로 RE 를 더 많이 줄이는 쪽, 즉 감소 효과 대비 비용이 큰 쪽이다.
  4. 제품 엔지니어링, 개발 환경, 프로그램 제약. 프로그램 제약은 프로젝트가 직접 통제할 수 없는 외부 요인이라 기술 중심 검토에서 빠지기 쉽다.
  5. 실패를 기정사실로 놓고 이유를 각자 먼저 적게 하므로, 우려를 말하기 꺼리는 분위기와 다른 사람 의견에 휩쓸리는 효과를 줄인다.

더 읽을거리 (References)