가장 중요한 문단은 바로 RBS(Risk Breakdown Structure, 리스크 분류 체계)가 프로젝트 리스크를 식별·관리하는 데 있어 핵심적인 체계라는 점이다. 프로젝트가 성공적으로 완수되려면, 예측 가능한 문제점부터 예측하기 어려운 불확실성까지 폭넓게 식별하고, 체계적으로 분류해야 한다. PMBOK 7판에서도 프로젝트 리스크 관리를 포괄적으로 다루는데, RBS야말로 이 리스크 관리의 출발점이자 토대를 제공하는 강력한 도구다. RBS는 단순히 문서를 작성하는 절차가 아니라, 프로젝트 구성원 전체가 공통 언어와 시각을 가지고 위험요소를 인지하고 대응 방안을 모색할 수 있도록 해준다. 프로젝트가 복잡해지고 이해관계자가 많아질수록, RBS를 잘 구축해둔 조직과 그렇지 않은 조직의 차이는 매우 크게 벌어진다.
프로젝트 리스크 관리가 소홀해지면, 일정 지연이나 예산 초과, 품질 문제, 심지어 프로젝트 실패까지 이어질 수 있다. PMBOK 7판에서는 ‘가치 중심’ 접근법과 ‘원칙 중심’ 접근법을 제시하고 있는데, 그중에서도 위험 관리(Risk Management) 원칙은 프로젝트 초기에 리스크를 충분히 식별하고 분류해두어야 한다고 강조한다. 이때 리스크를 직관적·단편적으로만 보는 것이 아니라, RBS라는 틀을 활용해 조직적으로 분류해두면, 추후 대응 방안을 마련할 때 훨씬 효율적이다. 본문에서는 RBS가 왜 중요한지, PMBOK 7판과 어떤 식으로 연계되는지, 그리고 실제 실무에서 발생하는 이슈와 해결 사례를 중심으로 살펴보겠다.
RBS의 핵심 개념과 PMBOK 7판의 연계
RBS란 무엇인가
RBS(Risk Breakdown Structure)는 프로젝트와 관련된 리스크를 여러 범주(Category)나 계층(Level)으로 분류하여 구조화한 계층적 도표를 말한다. 예를 들어, 최상위 레벨에서는 ‘기술적 위험’, ‘조직적 위험’, ‘외부 위험’, ‘프로젝트 관리 프로세스 위험’ 등과 같이 크게 나눌 수 있고, 하위 레벨로 내려갈수록 좀 더 구체적인 세부 위험항목이 정의된다.
- 기술적 위험: 새로운 기술 도입이나 시스템 통합 과정에서 발생하는 문제
- 조직적 위험: 인력 부족, 팀 조직 변화, 경영진 우선순위 변경 등
- 외부 위험: 법규 변화, 시장 환경 급변, 공급망 문제 등
- 프로세스 위험: 요구사항 누락, 일정 산정 오류, 의사결정 지연 등
이런 식으로 RBS를 활용하면, 프로젝트 팀이 “이 프로젝트에는 어떤 유형의 리스크가 존재할까?”를 보다 체계적으로 식별할 수 있다. 이때 PMBOK 7판의 위험 관리(Risk Management) 지식 영역과 접목해, 리스크 식별, 정성적·정량적 분석, 대응 계획 수립, 모니터링 및 통제 단계에 이르기까지 단계별로 RBS를 참조하게 된다.
PMBOK 7판과 RBS
PMBOK 7판은 기존보다 훨씬 ‘원칙 중심’ 접근을 강조한다. 그러나 전통적인 지식 영역(범위, 일정, 비용, 위험 등)과 프로세스 그룹(계획, 실행, 모니터링·통제, 종료)은 여전히 실무에서 중요한 틀을 제공한다. 프로젝트 위험 관리는 PMBOK 7판에서도 핵심 요소로 남아 있으며, 조직과 팀이 리스크를 폭넓게 식별하고, 적시에 대응 전략을 세우도록 독려하고 있다.
그 과정에서 RBS는 다음과 같은 이점을 갖는다.
- 리스크 식별 단계에서의 활용
PMBOK 7판의 위험 식별 프로세스(Identify Risks)에서 팀원들이 “어떤 리스크가 있는가?”를 브레인스토밍하는 데 그치지 않고, RBS의 틀을 참고해 빠뜨릴 가능성이 있는 영역까지 고르게 살펴보도록 유도한다. - 정성적·정량적 위험 분석과의 연계
식별된 리스크를 RBS 상의 위치에 따라 파악하면, 어느 카테고리가 가장 많은 리스크를 포함하는지, 어떤 계층(기술/조직/외부 등)에 높은 우선순위를 부여해야 하는지 등이 쉽게 보인다. 정량적 분석(Quantitative Risk Analysis) 단계에서도, RBS 계층별로 확률과 영향도(Impact)를 집계해볼 수 있다. - 위험 대응 계획 수립 시의 가시성
리스크 대응 방안(회피, 완화, 전가, 수용)을 결정할 때, 동일 계층의 리스크 간 유사 대응 전략이 있는지, 혹은 특정 부서나 전문가 그룹이 집중 대응해야 할 영역이 있는지 한눈에 확인할 수 있다.
요컨대, PMBOK 7판에서 요구하는 ‘체계적이고 가치 지향적인 리스크 관리’를 수행
RBS 리스크분류체계: 프로젝트 위험을 체계적으로 파악하는 열쇠
가장 중요한 문단은 바로 RBS(Risk Breakdown Structure, 리스크 분류 체계)가 프로젝트 리스크를 식별·관리하는 데 있어 핵심적인 체계라는 점이다. 프로젝트가 성공적으로 완수되려면, 예측 가능한 문제점부터 예측하기 어려운 불확실성까지 폭넓게 식별하고, 체계적으로 분류해야 한다. PMBOK 7판에서도 프로젝트 리스크 관리를 포괄적으로 다루는데, RBS야말로 이 리스크 관리의 출발점이자 토대를 제공하는 강력한 도구다. RBS는 단순히 문서를 작성하는 절차가 아니라, 프로젝트 구성원 전체가 공통 언어와 시각을 가지고 위험요소를 인지하고 대응 방안을 모색할 수 있도록 해준다. 프로젝트가 복잡해지고 이해관계자가 많아질수록, RBS를 잘 구축해둔 조직과 그렇지 않은 조직의 차이는 매우 크게 벌어진다.
프로젝트 리스크 관리가 소홀해지면, 일정 지연이나 예산 초과, 품질 문제, 심지어 프로젝트 실패까지 이어질 수 있다. PMBOK 7판에서는 ‘가치 중심’ 접근법과 ‘원칙 중심’ 접근법을 제시하고 있는데, 그중에서도 위험 관리(Risk Management) 원칙은 프로젝트 초기에 리스크를 충분히 식별하고 분류해두어야 한다고 강조한다. 이때 리스크를 직관적·단편적으로만 보는 것이 아니라, RBS라는 틀을 활용해 조직적으로 분류해두면, 추후 대응 방안을 마련할 때 훨씬 효율적이다. 본문에서는 RBS가 왜 중요한지, PMBOK 7판과 어떤 식으로 연계되는지, 그리고 실제 실무에서 발생하는 이슈와 해결 사례를 중심으로 살펴보겠다.
RBS의 핵심 개념과 PMBOK 7판의 연계
RBS란 무엇인가
RBS(Risk Breakdown Structure)는 프로젝트와 관련된 리스크를 여러 범주(Category)나 계층(Level)으로 분류하여 구조화한 계층적 도표를 말한다. 예를 들어, 최상위 레벨에서는 ‘기술적 위험’, ‘조직적 위험’, ‘외부 위험’, ‘프로젝트 관리 프로세스 위험’ 등과 같이 크게 나눌 수 있고, 하위 레벨로 내려갈수록 좀 더 구체적인 세부 위험항목이 정의된다.
- 기술적 위험: 새로운 기술 도입이나 시스템 통합 과정에서 발생하는 문제
- 조직적 위험: 인력 부족, 팀 조직 변화, 경영진 우선순위 변경 등
- 외부 위험: 법규 변화, 시장 환경 급변, 공급망 문제 등
- 프로세스 위험: 요구사항 누락, 일정 산정 오류, 의사결정 지연 등
이런 식으로 RBS를 활용하면, 프로젝트 팀이 “이 프로젝트에는 어떤 유형의 리스크가 존재할까?”를 보다 체계적으로 식별할 수 있다. 이때 PMBOK 7판의 위험 관리(Risk Management) 지식 영역과 접목해, 리스크 식별, 정성적·정량적 분석, 대응 계획 수립, 모니터링 및 통제 단계에 이르기까지 단계별로 RBS를 참조하게 된다.
PMBOK 7판과 RBS
PMBOK 7판은 기존보다 훨씬 ‘원칙 중심’ 접근을 강조한다. 그러나 전통적인 지식 영역(범위, 일정, 비용, 위험 등)과 프로세스 그룹(계획, 실행, 모니터링·통제, 종료)은 여전히 실무에서 중요한 틀을 제공한다. 프로젝트 위험 관리는 PMBOK 7판에서도 핵심 요소로 남아 있으며, 조직과 팀이 리스크를 폭넓게 식별하고, 적시에 대응 전략을 세우도록 독려하고 있다.
그 과정에서 RBS는 다음과 같은 이점을 갖는다.
- 리스크 식별 단계에서의 활용
PMBOK 7판의 위험 식별 프로세스(Identify Risks)에서 팀원들이 “어떤 리스크가 있는가?”를 브레인스토밍하는 데 그치지 않고, RBS의 틀을 참고해 빠뜨릴 가능성이 있는 영역까지 고르게 살펴보도록 유도한다. - 정성적·정량적 위험 분석과의 연계
식별된 리스크를 RBS 상의 위치에 따라 파악하면, 어느 카테고리가 가장 많은 리스크를 포함하는지, 어떤 계층(기술/조직/외부 등)에 높은 우선순위를 부여해야 하는지 등이 쉽게 보인다. 정량적 분석(Quantitative Risk Analysis) 단계에서도, RBS 계층별로 확률과 영향도(Impact)를 집계해볼 수 있다. - 위험 대응 계획 수립 시의 가시성
리스크 대응 방안(회피, 완화, 전가, 수용)을 결정할 때, 동일 계층의 리스크 간 유사 대응 전략이 있는지, 혹은 특정 부서나 전문가 그룹이 집중 대응해야 할 영역이 있는지 한눈에 확인할 수 있다.
요컨대, PMBOK 7판에서 요구하는 ‘체계적이고 가치 지향적인 리스크 관리’를 수행하려면, RBS를 활용해 리스크를 분류하고, 분석과 대응 전략을 연결하는 접근이 매우 유효하다.
RBS 구축의 주요 프로세스
요구사항 수집과 범위 정의
PMBOK 7판은 프로젝트 관리에서 요구사항 수집과 범위 정의가 모든 활동의 기초라고 설명한다. RBS 구축도 마찬가지다. 프로젝트 범위가 어디까지인지 명확하지 않으면, RBS에서 리스크 범주를 설정하는 것 자체가 애매해진다. 예를 들어, 범위에 포함된 특정 기술 플랫폼이 확실해야 ‘플랫폼 호환성 리스크’가 존재하는지 판단할 수 있다.
- 요구사항 수집: 이해관계자로부터 프로젝트 목표, 기능 요구사항, 성능 요구사항, 외부 의존사항 등을 수집한다.
- 범위 정의: 수집된 요구사항을 구체적으로 분석해, WBS(Work Breakdown Structure)를 작성하고 최종 범위를 확정한다.
- 잠재 리스크 목록 초안: 범위를 확인하면서 추정되는 위험요소를 1차적으로 수집해두고, 이를 나중에 RBS 단계에서 좀 더 체계적으로 분류한다.
리스크 식별과 분류 범주 선정
범위가 명확해졌다면, 이제 프로젝트 리스크를 전방위적으로 식별한다. 이때 RBS의 큰 틀, 즉 범주(Category)부터 설정하는 것이 좋다. 전형적인 RBS의 최상위 범주는 ‘기술/프로젝트 관리/조직/외부’ 등으로 나눌 수 있지만, 프로젝트 성격에 따라 다른 기준을 적용해도 무방하다. 예를 들어, 하드웨어 중심 프로젝트에서는 ‘설계 리스크’, ‘제조 리스크’, ‘공급망 리스크’, ‘인증/규제 리스크’ 등으로 범주화할 수 있다.
이렇게 최상위 범주를 정한 뒤, 리스크 식별 워크숍이나 브레인스토밍 세션을 통해 실제 가능한 리스크를 나열한다. 이후 이들을 적절한 범주에 속하도록 재분류하고, 필요하면 2~3단계의 하위 범주를 둬서 분류 체계를 더욱 정교화한다.
RBS의 계층 구조화
RBS는 이름 그대로 ‘계층 구조(Breakdown Structure)’다. PMBOK 7판에서는 프로젝트 범위(WBS)나 자원(RBS Resource Breakdown Structure) 등 다양한 Breakdown Structure를 권장하는데, 위험 분야에서도 같은 논리를 적용한다. 예컨대 다음과 같은 다단계 구조를 가질 수 있다.
- Level 1: 기술적 위험, 조직적 위험, 외부 위험, 프로젝트 관리 프로세스 위험
- Level 2 (기술적 위험 예시)
- 시스템 호환성
- 요구사항 변경
- 성능 문제
- 보안/안전 이슈
- Level 3 (시스템 호환성 예시)
- OS 버전 불일치
- API/SDK 버전 충돌
- 라이브러리 업데이트 지연
이렇게 계층을 구분해두면, 프로젝트가 진행되는 동안 특정 하위 레벨의 위험이 얼마나 자주 발생하는지, 그 중 어떤 위험이 높은 영향도를 가졌는지 쉽게 파악할 수 있다. PMBOK 7판의 ‘분류 기반 분석(Classification-based analysis)’ 개념과도 접목 가능하다.
RBS 검증과 업데이트
초기에 만든 RBS가 프로젝트 완료 때까지 똑같이 유지될 것이라 가정하면 위험하다. PMBOK 7판은 프로젝트가 동적으로 변화한다는 점을 강조하므로, RBS도 주기적인 리뷰와 업데이트가 필요하다. 예를 들어, 새로운 기술 스택을 도입하기로 결정하면, ‘기술적 위험’ 하위 범주가 새롭게 추가되거나 기존 범주가 삭제·수정될 수 있다.
- 정기 리뷰: 위험 관리를 체계적으로 하는 조직은 주간 혹은 월간 단위로 리스크를 재평가한다. 이때 RBS에 없는 리스크가 새로 발견되면, RBS 자체에 반영한다.
- 변경관리 프로세스 연동: 프로젝트 범위나 요구사항이 변경될 때마다, RBS의 범주나 하위 리스크가 어떻게 변동되는지도 확인한다.
- 교훈(Lessons Learned) 반영: 과거 프로젝트에서 발견된 위험이나 대응 방식 중 이번 프로젝트에도 적용 가능한 사항이 있으면, RBS에 추가해 식별 누락을 줄인다.
프로젝트 실무에서의 RBS 이슈와 해결 사례
이슈 1: 리스크 누락
프로젝트 팀이 브레인스토밍이나 인터뷰 등을 통해 위험을 식별했지만, 특정 영역에만 집중하고 다른 영역은 놓칠 수 있다. 예를 들어, 기술적 위험에는 매우 민감하게 반응하면서 정작 외부 공급망 리스크나 법규 변화 같은 요소는 간과하기 쉽다.
해결 사례
- RBS 활용: 브레인스토밍 전, RBS 상의 범주를 미리 제시하면 팀원들이 ‘아, 이런 영역에도 리스크가 있을 수 있구나’ 하고 떠올리게 된다.
- 전문가 자문: 법무팀, 재무팀, 인사팀 등 프로젝트 팀 외부 전문가와 협업해, 해당 분야의 잠재 위험을 파악한다.
- 레퍼런스 프로젝트 분석: 과거 유사 프로젝트의 RBS를 참고해, 누락 위험을 줄인다.
이슈 2: 리스크 우선순위 혼선
리스크는 다양하게 식별됐지만, 실제로 어떤 리스크를 먼저 다뤄야 하는지, 어느 리스크가 자원이 많이 필요한지 명확하지 않아 팀 내 혼선이 발생하는 경우가 있다.
해결 사례
- 정성적·정량적 위험 분석: PMBOK 7판에서도 강조하는 대로, 발생 확률과 영향도를 기준으로 등급화(High/Medium/Low)하거나, 기대금액(EMV, Expected Monetary Value) 같은 정량 지표를 활용한다.
- RBS 기반의 ‘핫스팟’ 식별: RBS 계층별로 리스크가 얼마나 집중되는지 시각화해, 특정 카테고리에 높은 위험도가 몰려 있다면 우선순위를 그쪽에 할당한다.
- 리스크 우선순위 회의: PMO나 프로젝트 관리자가 정기적으로 리스크 우선순위를 재평가하는 미팅을 주재해, 팀원들의 의견을 조정하고 업데이트한다.
이슈 3: RBS가 문서로만 존재하고 실무에 반영되지 않는 경우
RBS를 초기에만 작성해놓고, 실제 프로젝트 진행 과정에서는 거의 참고하지 않는 사례가 많다. 이는 결국 리스크 관리를 형식적 절차로 전락시키며, 문제가 발생했을 때 ‘왜 미리 대비하지 않았는가’라는 상황을 초래한다.
해결 사례
- 디지털 요구사항 추적 시스템 및 협업 툴 연계: Jira, Azure DevOps, MS Project 등 툴에 RBS 기반의 리스크 목록을 등록하고, 주기적으로 상태를 업데이트한다. 특정 작업 패키지나 요구사항과 연결해두면, 해당 작업 진행 시 자동으로 리스크가 표시되거나 알림이 뜨도록 설정할 수 있다.
- 정기 모니터링: 스탠드업 미팅, 스프린트 리뷰, PMO 보고 등 공식 의사소통 채널에 리스크 보고 섹션을 포함해, 자연스럽게 RBS를 참조하도록 만든다.
- 리스크 담당자 지정: 식별된 리스크마다 ‘Risk Owner(책임자)’를 지정해, 대응 상황을 추적하고 변경 시점에 RBS를 갱신하도록 한다.
간단한 예시: RBS 표
| 레벨1(최상위) | 레벨2(중분류) | 레벨3(세부 분류) |
|---|---|---|
| 기술적 위험 | 요구사항 변경 | 기능 확장, 주요 요청 누락 등 |
| 기술적 위험 | 호환성 | OS, 라이브러리, API 버전 충돌 등 |
| 조직적 위험 | 인력 이탈 및 부족 | 핵심 개발자 퇴사, 인력 채용 지연 등 |
| 조직적 위험 | 조직 구조 변화 | 부서 통합, 경영진 우선순위 변경 등 |
| 외부 위험 | 법규·규제 변경 | 신기술 규제, 개인정보 보호 법안 등 |
| 외부 위험 | 시장 변동 | 경쟁사 신규 제품 출시, 가격 변동 등 |
| 프로젝트 관리 프로세스 위험 | 일정 산정 오류 | 과도하게 낙관적 일정 추정 등 |
| 프로젝트 관리 프로세스 위험 | 요구사항 수립 프로세스 | 검증 절차 부족, 이해관계자 참여 저조 등 |
위 예시는 매우 단순화된 형태지만, 실제 프로젝트에서는 훨씬 더 깊이 있는 하위 레벨까지 세분화할 수 있다. 가장 중요한 점은 RBS가 프로젝트 특성에 맞게 커스터마이징되어야 한다는 것이다.
애자일 트렌드와 RBS
애자일 프로젝트에서의 RBS 적용
애자일(Agile) 프로젝트는 요구사항이 유동적이고, 짧은 스프린트 주기로 결과물을 제공한다는 특징을 지닌다. 그러다 보니 전통적 폭포수(Waterfall) 방식보다 리스크 식별 타이밍이나 범위가 조금 다를 수 있다. 그렇지만 애자일이라고 해서 RBS가 불필요한 것은 아니다. 오히려 스프린트마다 짧은 주기로 목표와 업무 범위가 바뀌기에, RBS가 없다면 빠르게 떠오르는 위험요소를 놓치기 쉽다.
- 스프린트 계획 단계에서의 RBS 확인: 각 스프린트가 시작될 때, RBS 상 어떤 범주가 이번 스프린트 범위와 연계되어 있는지 확인한다. 예를 들어, 특정 API 통합 작업이 이번 스프린트에 포함되면, ‘기술적 위험-호환성’ 영역을 집중 점검한다.
- 정기적 업데이트: 스프린트 리뷰나 레트로스펙티브에서 새롭게 발견된 리스크를 RBS에 추가하고, 필요 없는 항목은 제거하거나 수정한다.
- 하이브리드 모델 적용 시: 일부 범위는 폭포수형으로 진행하고, 일부는 애자일로 운영하는 하이브리드 프로젝트라면, 폭포수 측면에서 한 번에 많은 리스크를 식별하고, 애자일 측면에서 짧은 간격으로 RBS를 업데이트하는 방식을 결합할 수 있다.
디지털 요구사항 추적 시스템과의 연계
프로젝트 규모가 커지고, 분산된 팀원들이 협업하는 경우가 많아질수록 RBS도 문서 형태로만 관리하기보다는 디지털 툴과 연계해 실시간으로 접근 가능하도록 하는 편이 훨씬 효율적이다.
- Jira, Azure DevOps 등 협업 툴: 이슈나 에픽, 스토리에 리스크 태그를 달고, 해당 리스크가 어느 카테고리에 속하는지 RBS 구조를 반영한다. 필요 시 커스텀 필드를 만들어서, 레벨1/레벨2/레벨3 카테고리를 지정할 수도 있다.
- 프로젝트 관리 솔루션(MS Project 등)과 연동: 일정, 자원 배분과 리스크 항목을 연결해, 특정 작업 패키지가 착수될 때 자동으로 연관된 리스크가 팝업되거나, 대시보드에 표시되도록 설정한다.
- 실시간 대시보드: PMO나 프로젝트 관리자는 RBS 기반으로 어느 카테고리에 리스크가 몰리는지 한눈에 볼 수 있는 대시보드를 만든다. 예컨대 ‘기술적 위험 30%, 외부 위험 25%, 조직적 위험 15%, 프로세스 위험 30%’처럼 시각화해두면, 리소스 투입이나 우선순위 조정에 큰 도움이 된다.
RBS의 전체적 중요성과 적용 시 주의점
RBS(Risk Breakdown Structure)는 프로젝트 위험을 조직적으로 식별하고 관리하기 위한 강력한 수단이다. PMBOK 7판이 강조하는 ‘가치 중심’ 프로젝트 운영에서도, 위험 요인이 제대로 관리되지 않으면 결과적으로 팀이 창출하려는 가치가 크게 훼손될 수 있다는 점을 잊어서는 안 된다. RBS가 제공하는 체계화된 분류체계는 팀원들이 각기 다른 시각과 전문 영역을 가지고 있어도, 공통의 언어로 리스크를 논의하도록 만들어준다.
다만, RBS를 도입할 때 주의해야 할 점도 있다. 첫째, 분류 체계가 지나치게 복잡해지면 오히려 관리를 어렵게 만든다. 프로젝트 특성상 꼭 필요한 범주와 계층만 정교하게 관리하되, 불필요한 세분화는 삼가는 것이 좋다. 둘째, RBS를 만들기만 하고 실제로는 업데이트하지 않으면 ‘묵은 문서’가 되어버린다. 프로젝트 진행 상황이 바뀔 때마다 주기적으로 RBS를 재검토하고, 발견된 새로운 위험을 즉시 반영해야 한다. 셋째, RBS는 ‘팀 전체’가 공유해야 하는 산출물이다. 중앙에 있는 프로젝트 관리자 한 명만 알고 있어서는 소용이 없고, 이해관계자와 팀원 모두가 상호작용하면서 리스크를 관리해야 한다.
결국 RBS는 하나의 ‘프레임워크’이자 ‘도구’일 뿐, 그것을 잘 활용해 실제 대응 전략을 실행하고, 의사소통하고, 지속적인 모니터링을 하는 것은 사람의 몫이다. PMBOK 7판도 프로젝트의 궁극적 성공을 위해선 팀원, 이해관계자, 조직 문화가 모두 조화롭게 작동해야 한다고 본다. RBS는 그중에서 특히 위험 관리를 돕는 핵심 역할을 담당하므로, 프로젝트를 시작할 때 가장 먼저 착수해야 할 문서 중 하나로 인식해도 무방하다. 이를 통해 프로젝트 중 발생할 수 있는 다양한 난관을 예측 가능한 범위 안으로 끌어들일 수 있고, 나아가 프로젝트 성과와 가치를 극대화할 수 있을 것이다.