개주 훈련일지/📚 코살대 교본 학습

프로젝트 리스크 관리

lshfood2 2025. 12. 23. 23:40

[ 리스크 관리 ] 

프로젝트 계획서에는

“이런 목적을 달성한다”가  또렷하게 적혀 있다.

 

하지만 계획 단계에서 반드시

같이 다뤄야 하는 것이 있다.

 

목표를 달성하는 과정에서 마주치는

불확정성(변화, 부정적 요인) 이다.

 

계획은 고정돼 보여도,

현실의 실행 환경은 계속 흔들리기 때문이다.

 

그래서 프로젝트에서는

리스크 관리(Risk Management) 가 필요하다.


1. 리스크 관리란 무엇인가

리스크 관리는 위험 요인을 파악하고(Identify),

평가하고(Assess), 관리하는(Respond/Monitor)

기술과 노하우를 의미한다. 목적은 명확하다.

  • 긍정적인 사건이 일어날 가능성은 높이고
  • 부정적인 사건이 일어날 가능성은 낮추는 것

즉, “문제가 터지면 그때 처리”가 아니라,

문제가 터질 수 있는 지점을 미리 찾아

확률/영향을 줄이는 관리 활동이다.


2. 리스크 관리는 보통 이렇게 굴러간다

실무적으로는 아래 흐름이 가장 자연스럽다.

  1. 리스크 파악: 어떤 위험이 프로젝트에 영향을 줄 수 있는가?
  2. 리스크 평가: 발생 확률은? 발생하면 영향은?
  3. 리스크 대응/관리: 피할지, 줄일지, 넘길지, 받아들일지 결정 + 실행
  4. 모니터링: 진행 중 계속 관찰하고, 계획과 차이가 나면 원인 분석/수정

특히 리스크 파악은 “반복 작업” 이다.

 

프로젝트가 진행될수록 새 위험이 장하거나,

기존 위험의 크기가 바뀐다.


3. 리스크 파악(Identify): 리스크는 이렇게 찾는다

리스크를 “감”으로만 두면 관리가 불가능하다.

문서화가 시작이다. 대표적인 파악 방법은 다음과 같다.

  • 회의(워크숍)
    : 팀이 모여 리스크 아이템을 쏟아내고 정리
  • 문서 분석
    : 요구사항/일정/계약/기술 문서 등을 읽고 위험 요소 추출
  • 리스크 분할 구조(RBS) / 체크리스트
    : 리스크를 계층 구조로 분해해서 누락 방지
  • 유추(Analogies)
    : 과거 유사 프로젝트와 비교해 위험을 끌어오기

여기서 핵심은 “많이 모으기”가 아니라,

등록(리스크 등록부)해서 평가 가능한 형태로 만들기다.


4. 리스크 분류 프레임: 무엇을 기준으로 볼 것인가

리스크를 잘 찾으려면 “렌즈”가 필요하다.

아래 분류 틀을 쓰면 누락이 확 줄어든다.

 

(1) SW 관련 프로젝트 리스크
     (예시: Boehm이 제시한 관점)

  • 인력 부족
  • 비현실적인 일정 및 예산
  • 잘못된 기능과 특징 개발
  • 잘못된 인터페이스 개발
  • 과포장(필요 이상 기능/품질 목표)
  • 계속적인 요구 변경
  • 외부에 보일만한 컴포넌트(데모/대외 산출물) 빈약
  • 실시간 성능(성능/응답) 빈약
  • 낡은/부족한 기술 역량, 기술 부채

 

이런 항목은 대부분의 SW 프로젝트에서

반복적으로 터지는 영역이라 체크리스트로 강력하다.

 

 

(2) 8P(경영/서비스 관련 프로젝트 관점)

  • Price(가격)
  • Promotion(홍보/프로모션)
  • People(인력)
  • Process(프로세스)
  • Place/Plant(장소/설비)
  • Policy(정책)
  • Procedure(절차)
  • Product/Service(제품/서비스)

(3) 6M(제조/운영 관점)

  • Machine(기계/도구)
  • Method(방법)
  • Materials(재료/리소스)
  • Measurement(측정/지표)
  • Man(사람)
  • Mother nature(환경)

 

개발 프로젝트라도 운영/배포/테스트/인프라까지

포함되면 6M 관점이 꽤 유용하다.

 


5. 리스크 평가(Assess): 우선순위를 매기는 방법

리스크는 “있다/없다”가 아니라,

얼마나 위험한가가 중요하다.

 

보통 두 축으로 우선순위를 매긴다.

  • 발생 확률(빈도)
    : 얼마나 자주/가능성 높게 발생하는가?
  • 영향도(결과)
    : 발생했을 때 프로젝트에 얼마나 큰 타격인가?

(1) 정성적 평가

정확한 데이터가 없거나 초기 단계라면,

보통 정성 평가가 현실적이다.


확률/영향도를 스케일로 두고

리스크 매트릭스에 찍는다.

(예: Low/Medium/High/Extremely High 등)

  • 매트릭스에서 발생 빈도 높고
    영향 큰 구간(E: Extreme) 은 “특별 관리 대상”
  • 그 다음이 H(High) 로 “면밀히 모니터링”
  • 나머지는 일반 관리(M/L)

정성 평가는 속도가 빠르고 팀 합의를 만들기 쉽다.

 

(2) 정량적 평가

리스크 확률을 고려한 영향을 비용(돈) 으로 환산해 보는 방식이다.
예: 기대 손실(Expected Loss) = 발생확률 × 손실비용

 

데이터가 받쳐줄수록 강력하지만,

초기에는 추정 오차가 크니 정성+정량을 섞어도 좋다.


6. 리스크 대응(Respond): E/H/M/L에 따라 전략이 달라진다

리스크를 관리한다는 것은  받아들일 수 없는 위험을

줄이거나 해소하는 방법을 실행하는 것이다.

 

E와 같이 위헙적인 요소에 대한 관리 전략은

리스크를 피하기 위하여 계획을 바꾸거나

책임을 다른 기관에 맡기는 방법이 있으며

 

또는 빈도나 영향도를 낮추기 위하여

프로토타이핑할 수도 있다.

 

리스크를 기회로 바꾸는 계기가 될 수도 있는데

불확실성을 제거하기 위하여 유능한 인재를 등용하거나

이익을 나누기 위하여 제3자와 협업할 수도 있다.

 

리스크 관리 시 유의할 점

  • 1) 너무 큰 위험은 ‘관리’가 아니라 ‘프로젝트 자체를 재검토’할 것
    완전히 감당 불가한 수준이라면 시작을 포기하는 판단도 필요하다.
  • 2) 영향(Impact)과 원인(Cause)을 혼동하지 말 것
    예: “프로젝트 지연”은 원인이 아니라 영향이다.
    원인은 인력 부족/요구 변경/기술 난이도 과소평가 등일 수 있다.