리스크와 이슈 관리 — 아직 안 터진 것과 이미 터진 것 — 실습 Lab

INCIDENT RESPONSE

0 / 5 단계 완료

📚 PREREQUISITES

Theoryitsm/risk-issue-management

TRACK

ITSM

SLA

55분

LEVEL

중급

PHASES

3단계

ENV

local

INCOMING TICKET

“PMO 리드: "운영 반영(배포)이 일주일 남았습니다. 회의에서 '마이그레이션 때 데이터가 깨질 수도 있다', '보안 승인이 늦을 수도 있다'는 말은 나오는데, 어디에도 적히질 않아요. 걱정은 말로만 떠돌고, 정작 터지면 늘 '예상치 못한 장애'로 보고됩니다. 아직 안 터진 것(리스크)과 이미 터진 것(이슈)을 갈라서, 리스크는 가능성·영향으로 등급 매겨 대응을 걸고, 현실화되면 이슈로 넘겨 끝까지 추적하는 규칙을 세워 주세요."”

YOUR ROLE

SI/SM 프로젝트 관리자(PM)·PMO

안 하면 나중에

리스크를 이름 붙여 관리하지 않으면 걱정이 말로만 떠돌다 배포 당일 이슈로 터지고, 보고서엔 "예상치 못한 장애"라고 적힌다. 새벽 비상 소집, 데이터 유실, 오픈 연기, 나아가 "식별하고도 관리하지 않았다"는 귀책과 지체상금까지 수행사가 이중으로 진다.

📋상황 브리핑

SI 프로젝트 막바지, 운영 반영(배포)을 일주일 앞둔 회의입니다.

신입 PM A는 회의록에 "배포 D-7, 이상 없음"이라고 적습니다. 누군가 "운영 DB로 데이터 마이그레이션할 때 깨질 수도 있지 않나요?"라고 묻자 "그건 그때 보죠"라고 넘깁니다. 배포 당일 마이그레이션이 실제로 깨지고 결제 데이터 일부가 유실됩니다. 새벽 3시 전원 소집, 보고서엔 "예상치 못한 장애"라고 적힙니다.

선임 PM B는 같은 질문에 다르게 반응합니다. "그건 리스크네요"라며 그 자리에서 리스크 관리대장에 등록합니다 — 발생가능성 중, 영향 치명적(데이터 유실), 등급 상. 대응으로 완화(리허설 마이그레이션+롤백 스냅샷)와 전가(협력사 DBA 입회)를 걸고 담당·기한을 박습니다. 배포 당일 리허설에서 깨짐을 미리 잡아내 정상 반영합니다.

A에게 그것은 "예상치 못한" 일이었습니다. B에게는 이미 일주일 전부터 이름이 붙어 추적되던 리스크였습니다. 둘의 차이는 운이 아니라, 아직 안 터진 것을 미리 관리하느냐입니다. 이 Lab은 그 관리법 — 리스크와 이슈를 갈라, 등급을 매기고, 대응을 걸고, 현실화되면 이슈로 넘겨 끝까지 추적하는 규칙 — 을 손으로 세웁니다.

⏱ 55분📊 중급🔧 3단계#risk#issue#risk-register#mitigation

MISSION

리스크와 이슈 가르기 — 아직 안 터진 것 vs 이미 터진 것

회의에서 나온 걱정거리를 "이미 발생했는가" 하나로 리스크와 이슈로 가르고, 리스크는 대장에 한 줄로 등록하며 현실화되면 이슈로 넘어감을 문장으로 구분한다.

리스크 식별·정성분석(가능성×영향)·대응전략 — 다 똑같이 위험하지 않다

리스크를 원인-사건-영향 구조로 식별하고, 발생가능성×영향으로 등급(상·중·하)을 매기며, 회피·전가·완화·수용 중 대응을 고른다. 특히 가능성 낮음×영향 치명적은 등급을 올린다.

살아있는 리스크 관리대장 + 이슈 전환·에스컬레이션 — 적어놓고 안 봐서 터진다

리스크 관리대장을 담당·기한·상태로 채워 매주 갱신하고, 리스크가 현실화되면 즉시 이슈 관리대장으로 전환해 담당·해결기한·종결까지 추적하며, "예상치 못한 장애"가 아니라 "등록된 리스크 N번 현실화"로 보고·에스컬레이션한다.

📌 선수 지식

• [이론] itsm/risk-issue-management

ℹ️ 실습 환경

환경: local

🔒

실습 실행은 Pro 플랜 전용입니다

인시던트 브리프와 학습 자료는 지금 바로 확인할 수 있습니다. 실제 실습 진행 및 터미널 사용은 Pro 플랜에서 가능합니다.

Pro로 업그레이드 →

>_ LAB TERMINAL↔ 너비 조절

NOTES