위험은 실제로 발생하여 프로젝트 결과에 부정적인 영향을 끼친 문제이다.
위 문장이 왜 틀린걸까요? 이언 소머빌(Ian Sommerville)의 소프트웨어 공학 관점에서 해당 문장이 틀린 이유는 '위험(Risk)'과 '문제(Issue/Problem)'의 시점 차이 때문입니다. 공학적으로 이 둘은 엄격히 구분됩니다.
1. 위험(Risk) vs 문제(Issue)
소머빌은 위험을 다음과 같이 정의합니다.
- 위험(Risk) : 아직 발생하지 않았지만, 미래에 발생할 가능성이 있는 불확실한 사건입니다.
즉, '확률'의 영역에 있습니다. - 문제(Issue) : 이미 실제로 발생하여 현재 프로젝트에 영향을 주고 있는 결정된 사건입니다.
따라서 질문하신 문장에서 "위험은 실제로 발생하여... 문제이다"라는 부분은 위험의 정의가 아니라 '문제' 혹은 '사고'의 정의에 해당합니다. 위험은 발생하기 전까지는 어디까지나 '잠재적인' 상태여야 합니다.
2. 소머빌의 위험 관리 핵심
소머빌은 위험 관리를 크게 두 가지 범주로 나눕니다.
| 구분 | 설명 |
| 불확실성 (Uncertainty) | 사건이 일어날지 안 일어날지 모르는 상태 (위험의 본질) |
| 손실 (Loss) | 사건이 발생했을 때 입게 되는 원치 않는 결과 |
3. 문장이 틀린 결정적 이유
- 시점의 오류: 위험은 '미래'의 일이고, 문제는 '현재/과거'의 일입니다.
- 확률의 부재: 위험에는 반드시 '발생 확률(Probability)'이라는 개념이 포함되어야 합니다. "실제로 발생했다"는 것은 확률이 100%가 되어 더 이상 위험이 아닌 상태를 의미합니다.
올바른 정의 : "위험은 프로젝트의 계획이나 결과에 부정적인 영향을 미칠 가능성이 있는 잠재적인 사건이다."
4. 소머빌의 위험 관리 4단계
소프트웨어 프로젝트의 불확실성을 관리하기 위해 다음 과정을 반복합니다.
- 위험 식별 (Risk Identification)
- 프로젝트에 위협이 될 수 있는 잠재적 위험들을 찾아내는 단계입니다.
- 예) 핵심 개발자의 이직, 요구사항의 급격한 변경, 하드웨어 공급 지연 등 - 위험 분석 (Risk Analysis)
- 식별된 위험들의 발생 확률과 **영향도(심각성)**를 평가합니다.
- 모든 위험을 다 막을 수는 없으므로, 어떤 위험이 가장 치명적인지 우선순위를 정합니다. - 위험 계획 (Risk Planning)
- 위험을 관리하기 위한 전략을 세웁니다.
- 회피 전략: 위험이 발생할 가능성을 아예 없앰.
- 최소화 전략: 발생하더라도 피해를 줄임.
- 비상 계획(Contingency plan): 진짜로 터졌을 때 어떻게 할지 대책 마련. - 위험 모니터링 (Risk Monitoring)
프로젝트 내내 위험이 발생하는지, 혹은 새로운 위험이 생기는지 지속적으로 관찰합니다.
5. PMBOK의 위험관리 프로세스와의 차이
소머빌(Ian Sommerville)의 방식과 PMBOK(Project Management Body of Knowledge)의 위험 관리 프로세스는 본질적인 원리는 같지만, 소머빌은 소프트웨어 개발의 기술적 특성에, PMBOK은 일반적인 프로젝트 관리의 표준 절차에 더 집중하고 있습니다. PMBOK은 절차를 매우 세분화하여 관리 책임을 명확히 하는 반면, 소머빌은 기술적인 분석과 실행에 초점을 맞춘 4단계 사이클을 제시합니다.
| 구분 | 소머빌 (4단계) | PMBOK 6/7판 (7단계) | 핵심 차이점 |
| 기획 | (식별 단계에 포함) | 1. 위험 관리 계획 수립 | PMBOK은 '어떻게 관리할지' 정의하는 단계를 독립적으로 둠 |
| 찾기 | 1. 위험 식별 | 2. 위험 식별 | 유사함 (단, 소머빌은 SW 범주별 체크리스트 강조) |
| 분석 | 2. 위험 분석 | 3. 정성적 분석 4. 정량적 분석 |
PMBOK은 우선순위(정성)와 데이터 수치화(정량)를 엄격히 분리함 |
| 대응 | 3. 위험 계획 | 5. 위험 대응 계획 수립 6. 위험 대응 실행 |
PMBOK은 계획과 실제 '실행' 단계를 별도로 명시함 |
| 점검 | 4. 위험 모니터링 | 7. 위험 감시(Monitor) | 유사함 (지속적인 업데이트 강조) |
① 분석의 깊이 (Analysis)
- 소머빌: 확률과 영향도를 '매우 높음~매우 낮음' 같은 등급으로 나누는 방식에 집중합니다. SW 공학적 관점에서 기술적 불확실성을 빠르게 판단하는 데 유리합니다.
- PMBOK: 정량적 분석(Quantitative Analysis) 단계를 강조합니다. 몬테카를로 시뮬레이션이나 의사결정 트리 같은 도구를 써서 "이 위험으로 인해 비용이 몇 달러 더 들 것인가?"를 수치로 뽑아내는 과정을 중요하게 여깁니다.
② 대응 전략의 명칭 (Planning/Response)
위험을 처리하는 방식에서도 용어의 차이가 있습니다.
- 소머빌의 전략: 회피(Avoidance), 최소화(Minimization), 비상 계획(Contingency plans).
- PMBOK의 전략: 회피(Avoid), 전가(Transfer), 완화(Mitigate), 수용(Accept). (기회 요인에 대해서는 활용, 공유, 증대 등의 용어를 별도로 사용)
③ 초점 (Focus)
- 소머빌: "소프트웨어 기술" 중심입니다. 핵심 개발자의 이직, 요구사항 변경, SW 도구의 결함 등 개발 현장에서 벌어지는 구체적인 기술적 위험을 식별하는 체크리스트를 강조합니다.
- PMBOK: "비즈니스 및 프로세스" 중심입니다. 프로젝트 헌장, 이해관계자 관리, 법적 계약 등 거시적인 관점에서 위험을 체계적으로 문서화하고 승인받는 절차를 중시합니다.
6. PMBOK vs 소머빌(Sommerville) 위험 관리 비교
| 비교 항목 | PMBOK (전통적 표준) | 소머빌 (SW 공학 관점) |
| 기본 성향 | 문서 및 절차 중심 (Formal) | 실무 및 반복 중심 (Iterative) |
| 주요 모델 | 폭포수(Waterfall) 모델에 최적화 | 애자일(Agile) 및 진화적 모델에 가까움 |
| 위험의 성격 | 프로젝트 전반의 비즈니스/관리 위험 | 소프트웨어 기술/개발 중심 위험 |
| 분석 방법 | 정량적 분석(수치화, 통계) 강조 | 정성적 분석(경험적 등급화) 중심 |
| 문서화 수준 | 위험 등록부, 보고서 등 엄격한 기록 | 개발 주기 내 지속적인 업데이트 및 소통 |
| 대응 방식 | 사전에 정의된 프로세스(ITTO*) 준수 | 상황에 따른 전략적 판단과 계획 수정 |
7. 소머빌(Sommerville)의 소프트웨어 위험의 6가지 범주
이언 소머빌(Ian Sommerville)은 소프트웨어 프로젝트에서 발생할 수 있는 위험을 보다 체계적으로 식별하기 위해 이를 6가지 범주(Risk Categories)로 분류했습니다. 단순히 "문제가 생길 것 같다"가 아니라, 아래 리스트를 체크리스트로 활용하여 구체적으로 어떤 영역에서 불확실성이 존재하는지 찾아내는 것이 목적입니다.
| 범주 (Category) | 설명 (Description) | 구체적인 예시 |
| 1. 인력 위험 (People) |
프로젝트에 참여하는 인적 자원과 관련된 위험 | 핵심 개발자의 퇴사, 질병, 교육 훈련 부족, 팀원 간의 갈등 등 |
| 2. 조직 위험 (Organizational) |
프로젝트가 진행되는 조직(회사) 환경의 변화 | 경영진의 교체, 예산 삭감, 조직 개편으로 인한 우선순위 변경 등 |
| 3. 도구 위험 (Tools) |
개발에 사용되는 소프트웨어 도구(CASE 등) 관련 위험 | 컴파일러의 버그, 협업 도구의 성능 저하, 새로운 도구 적응 실패 등 |
| 4. 기술 위험 (Requirements) |
구현해야 할 기술의 난이도나 요구사항 관련 위험 | 요구사항의 잦은 변경, 기술적 구현 불가능성, 촉박한 마감 시한 등 |
| 5. 기술적 위험 (Technology) |
사용 중인 하드웨어나 기반 소프트웨어의 문제 | DB 처리 속도 저하, 네트워크 지연, 하드웨어 부품 공급 중단 등 |
| 6. 추정 위험 (Estimation) |
프로젝트 규모나 자원 산정의 오류 | 개발 기간 과소 산정, 필요한 코드 라인 수(LOC) 오판, 비용 부족 등 |