위험 및 이슈관리, PM의 심장을 쫄깃하게 만드는 '지뢰찾기'!💣

위험 및 이슈관리, PM의 심장을 쫄깃하게 만드는 '지뢰찾기'!💣 

안녕하세요, 여러분의 친절한 프로젝트 가이드, 수다쟁이 PM입니다! 🙋‍♀️

선배 PM들 사이에서 농담처럼 하는 말 중에 이런 말이 있어요. "PM은 위험과 이슈만 잘 관리해도 프로젝트는 성공한다!" 이게 우스갯소리 같지만, 20년 넘게 이 바닥에서 뒹굴어보니 이거 정말 '진리'에 가깝더라고요. 그만큼 위험 및 이슈 관리가 중요합니다.

프로젝트를 하다 보면 등골을 서늘하게 만드는 순간들이 있죠. "설마 이게 터지겠어?" 했던 일들이 현실이 되고, 고요했던 프로젝트가 순식간에 전쟁터로 변하는 경험, 다들 한 번쯤은 있으시죠? 😅

오늘은 바로 이 예측 불가능한 전장에서 살아남기 위한 PM의 필수 생존 기술, '위험 및 이슈 관리'에 대해 수다를 떨어보려고 합니다. 이거 잘하면 '유능한 PM', 놓치면 '무능한 PM' 소리 듣기 딱 좋은, 아주 중요한 기본기랍니다!

1. 위험 관리(Risk Management)란 무엇일까요?

위험 관리는 한 마디로 '아직 터지지 않은 시한폭탄을 미리 찾아 해체하는 활동' 💣 입니다. 즉, 미래에 우리 프로젝트에 부정적인 영향을 줄 수도 있는 잠재적인 사건(위험)을 미리 식별하고, 분석해서, 대응 방안을 세우고 지속적으로 추적 관리하는 '예방' 활동이죠.

PM은 항상 "뭐가 잘못될 수 있을까?"를 고민하며 프로젝트 곳곳에 숨겨진 위험 요소를 찾아내야 합니다. 그리고 그 모든 활동을 기록하는 문서가 바로 '위험관리대장'입니다. 우리 공공 프로젝트의 교과서인 '전자정부지원사업 사업관리매뉴얼'에서도 이 문서의 중요성을 아주 강력하게 이야기하고 있죠.

[샘플: 위험관리대장]

ID	위험 내용	구분	발생확률	영향도	대응 방안	담당자
R-01	핵심 개발 인력(DBA)의 퇴사 가능성	인력	중	상	대체 인력 확보 계획 수립, 기술 내재화 문서 강화	박PM
R-02	고객의 잦은 요구사항 변경으로 인한 개발 범위 증가	범위	상	상	주간 보고 시 변경 영향도 정량적 보고, 변경 통제 절차 강화	김PL
R-03	신규 도입 솔루션의 성능 저하 가능성	기술	중	중	BMT(벤치마크 테스트) 결과 재검토, 부하 테스트 계획	최AA

전자정부 사업관리메뉴얼에서의 위험수준 분석방법 예시

📌 공공 프로젝트에서 자주 만나는 위험 Top 10

1. 요구사항 변경 및 증가: 고객의 요구사항이 지속적으로 변경되거나 늘어나는 경우 (Scope Creep)
2. 핵심 인력 이탈: PM, PL, DBA 등 핵심 인력의 갑작스러운 퇴사 또는 교체
3. 의사결정 지연: 고객 또는 유관부서의 기술 검토 및 의사결정이 늦어지는 경우
4. 기술 성숙도 부족: 신규로 도입하는 기술이나 솔루션의 안정성이 검증되지 않은 경우
5. 외부 시스템 연계: 연계해야 할 외부 시스템의 변경, 비협조, 장애 발생
6. 데이터 확보의 어려움: 개인정보 등의 이슈로 테스트에 필요한 데이터를 확보하기 어려운 경우
7. 불명확한 요구사항: 요구사항 자체가 모호하여 개발 범위 해석에 차이가 발생하는 경우
8. 일정 지연: 특정 공정의 지연이 후속 공정에 연쇄적으로 영향을 미치는 경우
9. 의사소통 부재: 발주사-수행사, 현업-개발팀 등 이해관계자 간 소통이 원활하지 않은 경우
10. 보안 취약점 발생: 보안 점검에서 예상치 못한 취약점이 다수 발견되는 경우

 

2. 이슈 관리(Issue Management)란 무엇일까요?

이슈 관리는 반대로 '이미 터져버린 폭탄의 불을 끄고 수습하는 활동' 🔥 입니다. 위험 관리가 '예방'이었다면, 이슈 관리는 '사후 조치'이자 '해결' 활동인 셈이죠.

이슈가 발생했을 때, 특히 그 영향도가 크고 여러 부서와의 협력이 필요할 때는 단순히 목록으로만 관리하는 게 아니라, 이렇게 '상세이슈보고서' 형태로 만들어서 관련된 모든 사람들이 상황을 명확히 인지하고 함께 해결하도록 해야 합니다.

[샘플: 상세이슈보고서]

항목	내용
이슈 ID	I-01
이슈 제목	테스트 서버 응답 속도 저하로 인한 개발/테스트 지연
중요도	상
발생일	2025년 6월 30일
작성자	김PL
이슈 상세 내용	6/30 오전, 신규 배치 모듈 배포 이후 테스트 서버의 평균 응답 시간이 1초에서 10초 이상으로 급증함. 이로 인해 개발자들이 소스코드 빌드 및 테스트를 정상적으로 진행할 수 없는 상황.
영향 범위	개발팀 전체 생산성 80% 저하. 금주 예정된 통합 테스트 일정 지연 위기.
발생 원인 분석	신규 배치 모듈의 과도한 메모리 사용으로 인한 서버 과부하로 추정. (서버팀 분석 중)
해결 방안	1. 서버팀 긴급 투입하여 원인 분석 (즉시) 2. 문제 모듈 임시 롤백 조치 (1시간 내) 3. 원인 파악 후 핫픽스 배포 (24시간 내)
조치 담당자	서버팀(이서버), 개발팀(김PL), PM(박PM)
조치 기한	2025년 7월 2일
현재 상태	조치 중 (문제 모듈 롤백 완료, 서버팀 원인 분석 진행 중)

 

📌 PM의 밤잠을 설치게 하는 대표 이슈 Top 5

1. 성능 저하: 특정 화면이나 기능의 응답 속도가 현저히 느려지는 문제
2. 서버 장애: 개발, 테스트, 운영 서버가 다운되거나 오작동하는 문제
3. 결함 발생: 특정 조건에서 데이터가 누락되거나 기능이 오작동하는 소프트웨어 결함
4. 의사결정 지연: 고객 또는 상급자의 의사결정이 늦어져 프로젝트가 대기 상태에 빠지는 문제
5. 범위 해석 차이: 계약서에 명시된 과업 범위를 두고 발주사와 수행사 간에 이견이 발생하는 문제

3. 그래서, 둘의 결정적인 차이는?

• 위험(Risk)은 '시한폭탄' 💣 입니다. 아직 터지진 않았지만, "어? 저기 폭탄이 있네? 저러다 터질 수도 있겠는데?" 하고 미리 식별하고 대비할 수 있는 미래의 잠재적 사건이죠.
• 이슈(Issue)는 '터진 폭탄' 🔥 입니다. "펑!" 하고 이미 터져버려서, 당장 달려가서 수습해야 하는 현재의 명백한 문제입니다.

 

4. 수다쟁이 PM의 실전 꿀팁: 'Top 5'만 관리한다! 🥊

교과서대로 모든 위험을 관리하면 좋겠지만, 우리에겐 시간과 자원이 한정되어 있죠. 20년 경력의 실전 꿀팁을 하나 드리자면, '가장 아픈 놈 Top 5'만 집중적으로 관리하는 겁니다.

수십 개의 위험 목록을 보며 압도당하지 마세요. 각 위험마다 **(발생 확률) X (발생 시 영향도)**를 점수로 매겨보세요. 그리고 가장 점수가 높은, 즉 '터지면 프로젝트가 망하는' 수준의 위험 5개를 선정해서 매일 아침저녁으로 들여다보는 겁니다. 그 Top 5만 막아내도 프로젝트는 80% 이상 성공 가도를 달릴 수 있습니다. 이게 바로 현실적인 우선순위 관리죠!

마무리하며

프로젝트에서 이슈 발생을 '0'으로 만드는 것은 불가능에 가깝습니다. 하지만 성공적인 위험 관리를 통해 이슈의 발생 횟수와 그 충격량을 줄이는 것은 유능한 PM의 역량입니다.

여러분도 오늘부터 '프로 걱정러'가 되어 프로젝트에 숨어있는 '시한폭탄'을 찾아보는 건 어떨까요? 그 걱정이 여러분의 프로젝트를 성공으로 이끌 겁니다!

궁금한 점이 있다면 언제든 댓글 주세요! 😊