3줄 요약
- 리스크 관리 대장(Risk Register)은 IT 프로젝트의 잠재 위험을 확률과 영향으로 정량화해 우선순위를 매기는 핵심 산출물이다.
- 현장의 가장 큰 문제는 리스크를 식별만 하고 대응 전략 없이 방치하거나, 대장을 만든 뒤 한 번도 열어보지 않는 것이다.
- PSTA는 리스크 관리를 직접 지원하지 않는다. 경량 스프레드시트 로그와 PSTA Action을 연계하는 방식이 현실적인 보완책이다.
“리스크 관리 대장을 만들긴 했습니다. 어디 있냐고요? 첫 기획 때 쓴 스프레드시트인데… 그 뒤로 한 번도 안 열었어요.”
IT 프로젝트를 몇 번 경험한 사람이라면 이 상황이 낯설지 않을 것이다. 리스크 관리는 PMBOK 11장이 다루는 영역으로, “아직 일어나지 않은 문제를 미리 식별하고 대응한다”는 예방적 사고가 핵심이다. 리스크 관리란 프로젝트 목표 달성을 위협하는 불확실성을 체계적으로 식별·분석·대응·감시하는 활동이다. 핵심 산출물인 리스크 관리 대장(Risk Register)에는 각 리스크의 확률, 영향, 우선순위, 대응 전략, 담당자, 트리거가 기록된다. 이 편에서는 정석의 구조를 파악하고, 현장에서 왜 이 도구가 사문화되는지, 그리고 PSTA와는 어떻게 연계하면 좋은지를 정직하게 살펴본다.
📖 PMBOK 11장이 말하는 리스크 관리의 정석
PMBOK의 리스크 관리(위험 관리)는 크게 일곱 단계 프로세스로 구성된다.
- 리스크 관리 계획 수립: 리스크를 어떻게 식별하고 분석할지 방법론을 먼저 정한다.
- 리스크 식별: 프로젝트에 영향을 미칠 수 있는 위험 요인을 전수 발굴한다. 브레인스토밍, 체크리스트, 전문가 인터뷰가 주요 기법이다.
- 정성적 리스크 분석: 확률(Probability)과 영향(Impact)을 조합한 확률×영향 매트릭스(P×I Matrix)로 우선순위를 정한다. 발생 가능성은 높고 영향이 큰 리스크가 최우선 대응 대상이다.
- 정량적 리스크 분석: 몬테카를로 시뮬레이션 등 수치 모델로 리스크의 재무·일정 영향을 수치화한다. 대형 프로젝트에서 사용하며 소규모 IT 프로젝트에서는 생략하는 경우가 많다.
- 리스크 대응 계획 수립: 각 리스크에 구체적인 대응 전략을 배정한다. 부정적 리스크(위협)에는 회피(Avoid)·전가(Transfer)·완화(Mitigate)·수용(Accept), 긍정적 리스크(기회)에는 활용(Exploit)·공유(Share)·증대(Enhance)·수용(Accept)을 사용한다.
- 리스크 대응 실행: 계획한 대응 조치를 실제 프로젝트 활동에 통합해 실행한다.
- 리스크 감시: 식별된 리스크를 정기적으로 재검토하고, 새로운 리스크를 추가하며, 발생한 리스크를 이슈로 전환해 추적한다.
이 모든 과정의 중심에 리스크 관리 대장(Risk Register)이 있다. 리스크 관리 대장이란 식별된 모든 리스크와 그 속성(확률, 영향, 우선순위, 대응 전략, 담당자, 상태)을 한곳에 모은 살아있는 문서다. “살아있는”이 핵심이다. 최초 작성이 아니라 프로젝트 내내 갱신해야 의미가 있다.
✅ 읽으며 좋았던 점: 예방적 사고의 체계화
11장을 읽으면서 가장 인상적이었던 것은 “문제가 터진 뒤 반응하는” 사후 관리 대신 “아직 일어나지 않은 것을 미리 다룬다”는 예방적 사고의 체계화였다. 현장에서 PM이 가장 많이 받는 비판이 “왜 그걸 몰랐냐”인데, 리스크 관리는 이 질문에 사전에 답하는 구조다. 리스크를 식별했다면 최소한 “알고 있었는데 수용했다”와 “몰랐다”를 구분할 수 있다. 이 차이가 사후 책임 소재와 팀의 신뢰에 실질적인 영향을 미친다.
확률×영향 매트릭스도 실용적이다. 모든 리스크를 동등하게 다룰 수 없다. 발생 가능성이 낮고 영향도 미미한 리스크에 에너지를 쏟는 것은 낭비다. P×I 매트릭스는 “어디에 집중해야 하나”를 팀 전체가 합의할 수 있는 시각적 도구로 만들어준다. 대응 전략의 4분류(회피·전가·완화·수용)도 실전에서 바로 쓸 수 있는 어휘다. “이 리스크를 수용하기로 했다”는 말 한마디가 팀의 에너지를 불필요한 논쟁에서 구해줄 수 있다.
⚠️ 현장과의 괴리: 리스크 관리표를 왜 아무도 안 보나
리스크 관리가 이렇게 좋은 도구임에도 불구하고, 대부분의 IT 현장에서 리스크 관리 대장은 사문화된다. 이유가 있다.
첫째, 형식화 문제다. 킥오프 때 리스크 관리 대장을 만드는 것은 프로세스다. 그러나 그 뒤로 매주 열어보고 갱신하는 것은 습관이다. 프로세스는 강제할 수 있지만 습관은 그렇지 않다. 결국 대장은 초기 한 번 작성 후 방치된다.
둘째, IT 특유 리스크가 일반 템플릿에 안 담긴다. PMBOK의 리스크 식별 체크리스트는 건설·제조 프로젝트 중심으로 설계된 경우가 많다. IT 프로젝트가 자주 마주하는 기술 불확실성(새로운 프레임워크 도입, 외부 API 의존성), 핵심 인력 이탈, 요구사항 변동(스코프 크립), 레거시 시스템 연동의 불확실성 같은 리스크는 일반 템플릿을 그대로 쓰면 잘 안 잡힌다.
셋째, 식별에서 멈춘다. 리스크를 쭉 나열하는 데서 그치고 대응 전략까지 나아가지 못한다. “외부 API가 변경될 수 있다”를 적는 것과 “외부 API 변경 시 자체 어댑터 레이어를 두어 영향을 최소화한다(완화)”를 적는 것은 천지 차이다. 전자는 걱정 목록, 후자는 행동 계획이다.
넷째, 담당자와 트리거가 없다. “누가 이 리스크를 감시하는가?”와 “어떤 신호가 왔을 때 대응을 시작하는가?”가 빠지면 리스크 관리 대장은 그냥 걱정 목록일 뿐이다.
🔧 실전 번역: 살아있는 리스크 로그를 만드는 법
무거운 리스크 관리 대장 대신 Top 5 리스크 로그라는 경량 버전이 현장에서 실용적이다. 아래 컬럼만 있으면 충분하다.
| 항목 | 설명 |
|---|---|
| 리스크 설명 | 한 문장으로 구체적으로 (예: “결제 외부 API가 버전 변경 시 연동 오류”) |
| 확률 (H/M/L) | H=높음, M=중간, L=낮음 |
| 영향 (H/M/L) | 일정·비용·품질 중 어디에 얼마나 |
| 우선순위 | 확률×영향으로 H/M/L 결정 |
| 대응 전략 | 회피/전가/완화/수용 중 선택 + 구체 조치 |
| 트리거 | 이 리스크가 현실화되는 신호 (예: “API 공지 이메일 수신”) |
| 담당자 | 감시·대응 책임자 1명 |
| 상태 | 감시 중 / 이슈로 전환 / 종료 |
이 로그를 살아있게 유지하는 리듬 설계가 핵심이다. 권장하는 방법은 다음과 같다.
- 격주 15분 리뷰: 스탠드업이나 주간 회의 끝에 “Top 5 리스크 상태 변화 있나?”를 묻는 루틴을 고정한다. 별도 회의 소집이 아니라 기존 회의에 올라타야 지속된다.
- 회고와 연결: 스프린트 회고나 마일스톤 리뷰 때 새로운 리스크가 없는지, 기존 리스크 우선순위가 바뀌지 않았는지 확인한다.
- 리스크→이슈 전환: 리스크가 실제로 발생하면 이슈로 전환해 별도 추적한다. “리스크 감시 중”에서 “이슈 대응 중”으로 상태를 바꾸는 것이 추적의 출발점이다.
- IT 특유 리스크 항목을 선제 등록: 프로젝트 초기에 아래 카테고리를 체크리스트로 활용해 빠뜨리지 않는다.
- 기술 불확실성: 새 프레임워크·라이브러리 도입, 미검증 기술 스택
- 외부 의존성: 외부 API, 써드파티 서비스, 클라우드 공급업체 정책 변경
- 핵심 인력: 특정 기술을 보유한 팀원의 이탈·부재
- 요구사항 변동: 스코프 크립, 이해관계자 우선순위 변경
- 레거시 연동: 구 시스템 문서 부재, 예측 불가능한 데이터 품질
- 보안·컴플라이언스: 개인정보보호 규제 변경, 보안 감사 일정
🟥 PSTA로 보면 — 그리고 정직한 빈칸
PSTA로 보면 — 정직하게: 이 영역은 PSTA 범위 밖이다
솔직하게 말한다. PSTA는 리스크 관리를 직접 지원하지 않는다. 리스크 관리 대장, 확률×영향 매트릭스, 리스크 식별 워크플로 같은 기능이 PSTA에는 없다. 이것은 설계상의 의도적 빈칸이다. PSTA는 프로젝트·업무의 실행 추적(Project→Service→Action)과 진행률 집계, 팀 커뮤니케이션에 집중하기로 선택했고, 리스크 분석 영역은 그 범위 밖에 두었다.
그렇다고 완전히 손을 놓을 필요는 없다. 현실적인 연계 방법은 이렇다: 리스크 로그는 별도 스프레드시트(Google Sheets 등)나 경량 이슈 트래커로 관리하고, 리스크가 실제로 발생해 이슈가 되면 PSTA의 Action으로 전환해 실행을 추적한다. 예를 들어 “외부 API 버전 변경 리스크”가 현실화되면, PSTA에 “API 어댑터 레이어 구현” Action을 등록하고 담당자·기한·상태를 추적하는 식이다. 리스크 분석은 외부 도구, 대응 실행은 PSTA — 이 역할 분리가 현재로선 가장 현실적인 연계다.
언젠가 PSTA에 경량 리스크 로그 기능이 붙으면 이 글은 구식이 될 것이다. 지금은 없다는 사실을 그대로 전달한다.
🎓 이 장을 떼면 당신은 이것을 할 수 있다
- 프로젝트 초기에 IT 특유 리스크 카테고리를 체크리스트로 활용해 Top 5 리스크를 식별할 수 있다.
- 확률(H/M/L)과 영향(H/M/L)을 곱해 리스크 우선순위를 매기고, 어디에 먼저 에너지를 쏟아야 하는지 팀과 합의할 수 있다.
- 각 리스크에 회피·전가·완화·수용 중 하나를 선택하고, 구체적인 대응 조치와 담당자를 지정할 수 있다.
- 리스크가 현실화되는 트리거를 미리 정의해, “대응을 언제 시작해야 하는가”에 대한 판단 기준을 팀이 공유할 수 있다.
- 격주 리뷰 루틴을 기존 회의에 올라타는 형태로 설계해, 리스크 로그가 방치되지 않고 살아있게 유지할 수 있다.
❓ FAQ
리스크 관리 대장이란 무엇인가?
리스크 관리 대장(Risk Register)이란 프로젝트에서 식별된 모든 리스크와 그 속성—확률, 영향, 우선순위, 대응 전략, 트리거, 담당자, 현재 상태—을 한곳에 기록하고 프로젝트 내내 갱신하는 살아있는 문서다. 초기 작성이 아닌 지속적 갱신이 핵심이며, 이것이 멈추는 순간 대장은 걱정 목록으로 전락한다.
리스크 관리표를 왜 아무도 안 보나?
가장 큰 이유는 작성 후 갱신하는 루틴이 없어서다. 리스크 관리 대장 작성은 프로세스로 강제할 수 있지만, 격주로 열어보는 것은 습관이 돼야 한다. 또한 대응 전략 없이 리스크만 나열하거나, 트리거와 담당자가 빠져 있으면 대장을 열어봐도 할 수 있는 행동이 없어 자연히 외면하게 된다. 경량 Top 5 로그로 시작해 리뷰 루틴을 기존 회의에 붙이는 것이 현실적인 해법이다.
IT 프로젝트의 대표적인 리스크는 무엇인가?
IT 프로젝트에서 자주 등장하는 리스크는 기술 불확실성(미검증 스택 도입), 외부 API·써드파티 서비스 의존성, 핵심 인력 이탈, 요구사항 변동(스코프 크립), 레거시 시스템 연동의 불확실성, 보안·컴플라이언스 규제 변경이다. 일반 건설·제조 중심 리스크 체크리스트를 그대로 쓰면 이 항목들이 빠지기 쉬우므로, IT 전용 카테고리를 선제적으로 등록해두는 것이 좋다.
리스크와 이슈의 차이는 무엇인가?
리스크(Risk)는 아직 일어나지 않은 불확실한 사건이고, 이슈(Issue)는 이미 발생해 현재 진행 중인 문제다. 리스크는 확률이 있지만 이슈는 확률이 없다—이미 현실이 됐기 때문이다. 리스크 관리에서 중요한 전환점은 “리스크→이슈 전환”이다. 트리거가 발생해 리스크가 현실화되면 이슈로 상태를 바꾸고 대응 조치를 실행 추적해야 한다. 이 전환을 놓치면 리스크 로그는 갱신되지 않고, 이슈는 관리되지 않는 이중 공백이 생긴다.
리스크 관리는 미래를 통제하는 것이 아니라, 불확실성 앞에서 팀이 얼마나 준비돼 있는지를 높이는 활동이다. 무거운 대장 대신 살아있는 경량 로그로 시작해보자. 프로젝트 관리 전반에 대해 더 이야기 나누고 싶다면 주니크 문의 페이지나 PSTA를 방문해보길 권한다.
『PMBOK 완독기』 시리즈
← 이전: 08. 의사소통관리: 보고 오버헤드 줄이기 (10장)
→ 다음: 10. 조달관리: 외주 계약과 검수 (12장)
