SI 프로젝트 막바지, 운영 반영(배포)을 일주일 앞둔 회의.
신입 PM A는 회의록에 "배포 D-7, 이상 없음"이라고 적습니다. 누군가 "운영 DB로 데이터 마이그레이션할 때 깨질 수도 있지 않나요?"라고 묻자 "그건 그때 보죠"라고 넘깁니다. 배포 당일, 마이그레이션이 실제로 깨지고 결제 데이터 일부가 유실됩니다. 새벽 3시, 전원 소집. 보고서엔 "예상치 못한 장애"라고 적힙니다.
선임 PM B는 같은 질문에 다르게 반응합니다. "그건 리스크네요"라며 그 자리에서 리스크 관리대장에 등록합니다 — 발생가능성: 중, 영향: 치명적(데이터 유실), 등급: 상. 대응으로 완화(리허설 마이그레이션 + 롤백 스냅샷)와 전가(협력사 DBA 입회, 책임 명시)를 넣고 담당·기한을 박습니다. 배포 당일 리허설에서 깨짐을 미리 잡아내 정상 반영합니다.
A에게 그것은 "예상치 못한" 일이었습니다. B에게는 이미 일주일 전부터 이름이 붙어 추적되던 리스크였습니다. 둘의 차이는 운이 아니라, 아직 안 터진 것을 미리 관리하느냐입니다. 이 모듈은 그 관리법 — 리스크와 이슈 관리 — 를 다룹니다.
- 1리스크(미발생 잠재 문제)와 이슈(이미 발생한 문제)를 명확히 구분하고, 리스크가 현실화되면 이슈로 전환됨을 설명할 수 있다
- 2리스크를 식별하고, 발생가능성×영향으로 정성 분석해 등급(매트릭스)을 매길 수 있다
- 3네 가지 위협 대응 전략(회피·전가·완화·수용)과 기회 전략(활용·공유·증대·수용)을 상황에 맞게 고를 수 있다
- 4리스크 관리대장과 이슈 관리대장의 컬럼 구성과 운영 방식의 차이를 안다
- 5운영 반영 장애·데이터 영향·보안 승인·배포 실패 같은 SI/SM 현장 사안을 리스크로 등록·추적할 수 있다
리스크와 이슈 — 시점이 다르다
아직 안 터진 것 vs 이미 터진 것
프로젝트 관리에서 가장 자주 섞어 쓰는 두 단어가 리스크와 이슈입니다. 그러나 둘을 가르는 기준은 단 하나, 이미 발생했는가입니다.
- 리스크(Risk) — 아직 발생하지 않았지만 발생할 가능성이 있는, 발생하면 프로젝트 목표(일정·비용·품질·범위)에 영향을 줄 불확실한 사건. 핵심 질문은 "얼마나 일어날 법한가, 일어나면 얼마나 아픈가".
- 이슈(Issue) — 이미 발생한 문제. 가능성은 더 이상 의미 없고(100% 발생함), 핵심 질문은 "누가 언제까지 어떻게 해결하는가".
둘은 단절된 게 아니라 이어져 있습니다. 식별된 리스크가 현실화되면 그 순간 이슈가 됩니다. 그래서 잘 관리되는 프로젝트일수록 "예상치 못한 이슈"가 적습니다 — 대부분의 이슈는 리스크 단계에서 이미 이름이 붙어 있었기 때문입니다.
| 구분 | 리스크(Risk) | 이슈(Issue) |
|---|---|---|
| 발생 여부 | 아직 안 터짐(잠재) | 이미 터짐(현실) |
| 핵심 질문 | 가능성·영향이 얼마인가 | 누가·언제까지 해결하나 |
| 시제 | 미래형("~할 수도 있다") | 현재형("~가 되고 있다") |
| 관리 컬럼 | 발생가능성·영향·등급·대응전략 | 담당·기한·진행상태·종결 |
| 관리 문서 | 리스크 관리대장(Risk Register) | 이슈 관리대장(Issue Log) |
| 전환 | 현실화되면 이슈로 넘어감 | (리스크가 넘어온 결과인 경우 많음) |
흔한 함정은 "거론만 하고 적지 않는" 것입니다. 회의에서 "그거 위험하지 않아요?"라고 말만 하고 어디에도 기록하지 않으면, 그 리스크는 관리되지 않는 것입니다. 식별의 결과는 항상 관리대장에 한 줄이어야 합니다.
리스크 식별 — 무엇이 우리를 아프게 할 수 있는가
식별: 후보를 빠짐없이 끌어모은다
리스크 관리는 식별 → 분석 → 대응 → 추적의 순환입니다. 첫 단계인 식별의 목표는 "있을 법한 위협(과 기회)을 최대한 빠짐없이 꺼내는 것"입니다. 한 명의 머릿속이 아니라 팀과 협력사가 함께 꺼내야 사각지대가 줄어듭니다.
식별을 돕는 흔한 방법:
- 체크리스트 — 과거 프로젝트에서 반복된 리스크 목록(마이그레이션, 외부 연동, 인력 이탈 등)을 훑는다.
- 가정·제약 분석 — "협력사가 제때 납품할 것이다" 같은 가정이 틀어지면 그게 곧 리스크다.
- 체계적 질문(범주별) — 기술/일정/비용/인력/외부/보안 범주를 돌며 "여기서 뭐가 틀어질 수 있나" 묻는다.
- 회고·교훈(Lessons Learned) — 지난 프로젝트의 사고를 다시 본다.
SI/SM 현장에서 자주 나오는 리스크 범주:
| 범주 | 전형적 리스크 |
|---|---|
| 운영 반영(배포) | 배포 실패, 롤백 불가, 점검창 초과 |
| 데이터 | 마이그레이션 깨짐, 데이터 유실·정합성 손상 |
| 보안·승인 | 보안 검토 지연, 운영 반영 승인 미획득 |
| 외부 연동 | 결제대행사·인증기관 장애, API 스펙 변경 |
| 인력·일정 | 핵심 인력 이탈, 협력사 납품 지연 |
리스크를 적을 때는 모호한 한 단어("위험함")가 아니라 원인-사건-영향 구조로 씁니다: "운영 DB 마이그레이션 스크립트 미검증으로(원인) 배포 시 데이터가 깨져(사건) 결제 데이터가 유실될(영향) 수 있다." 이렇게 써야 분석·대응이 가능합니다.
정성 분석 — 발생가능성 × 영향 = 등급
다 똑같이 위험하지 않다 — 순위를 매긴다
식별만 하면 리스크가 수십 개로 늘어납니다. 모두에 똑같이 자원을 쓸 수는 없으니 우선순위를 매겨야 합니다. 가장 널리 쓰는 방법이 정성(qualitative) 분석 — 두 축으로 등급을 매기는 것입니다.
- 발생가능성(Probability) — 이 리스크가 실제로 일어날 법한 정도(낮음·중간·높음).
- 영향(Impact) — 일어났을 때 프로젝트 목표에 주는 타격(경미·보통·치명적).
이 둘을 곱하거나 매트릭스에 배치해 리스크 등급(상·중·하)을 냅니다. 핵심 통찰은 두 축을 함께 본다는 것입니다. 가능성만 높다고, 영향만 크다고 최우선이 아닙니다 — 둘이 모두 큰 우측 상단이 가장 위험합니다.
발생가능성 × 영향 매트릭스(정성 등급):
| 발생가능성 \ 영향 | 경미(낮음) | 보통(중간) | 치명적(높음) |
|---|---|---|---|
| 높음 | 중 | 상 | 상 |
| 중간 | 하 | 중 | 상 |
| 낮음 | 하 | 하 | 중 |
읽는 법: 가장 위험한 칸은 우측 상단(가능성 높음 × 영향 치명적 = 상), 가장 안전한 칸은 좌측 하단(하)입니다. 특히 주의할 칸은 가능성 낮음 × 영향 치명적 — 위 표에서 '중'이지만, 데이터 유실·보안 사고처럼 한 번 터지면 회복 불가능한 리스크는 빈도가 낮아도 등급을 올려 회피·전가 같은 강한 대응을 검토합니다. "잘 안 나니까 괜찮다"가 가장 흔한 사고 패턴입니다.
상위 등급 리스크부터 대응 자원을 배정합니다. 정성 분석은 빠르고 직관적이며, 더 정밀한 정량(금액·확률 기댓값) 분석은 대형·고위험 프로젝트에서 별도로 합니다.
대응 전략 — 회피·전가·완화·수용
등급을 매겼으면 '어떻게 다룰지'를 정한다
등급이 정해진 리스크는 그냥 두지 않고 대응 전략을 정합니다. 위협(부정적 리스크)에는 네 가지 표준 전략이 있습니다.
| 전략 | 뜻 | 예시 |
|---|---|---|
| 회피(Avoid) | 리스크 원인을 아예 제거 — 그 일을 안 하거나 방식을 바꿈 | 위험한 신기술 대신 검증된 방식 채택, 불안한 기능을 범위에서 제외 |
| 전가(Transfer) | 책임·영향을 제3자에게 넘김(리스크 자체는 남음) | 보험, 외주 계약, SLA 페널티 조항, 보증보험 |
| 완화(Mitigate) | 발생가능성이나 영향을 줄임 | 마이그레이션 리허설, 롤백 스냅샷, 다중화, 재시도 로직 |
| 수용(Accept) | 별도 대응 없이 받아들임 — 대신 비상 대비(컨틴전시) 준비 | 발생 시 쓸 예비 시간·예산(컨틴전시 리저브) 확보, 비상 연락망 |
대응을 고르는 직관: 영향이 치명적이면 회피·전가를 먼저 본다, 줄일 수 있으면 완화가 가장 흔한 현실적 선택, 작고 드문 리스크는 수용(과잉 대응이 더 낭비). 수용에는 두 종류가 있습니다 — 아무 준비도 안 하는 소극적 수용과, 발생에 대비해 컨틴전시(예비 시간·예산·플랜B)를 잡아두는 적극적 수용. 실무에서 의미 있는 것은 후자입니다.
리스크에는 위협만 있는 게 아니라 **기회(긍정적 리스크)**도 있습니다. 기회에 대한 전략은 대칭적입니다.
| 위협 전략 | 대응되는 기회 전략 | 기회 전략의 뜻 |
|---|---|---|
| 회피(Avoid) | 활용(Exploit) | 기회를 반드시 실현되게 만든다 |
| 전가(Transfer) | 공유(Share) | 기회를 더 잘 살릴 제3자와 함께한다 |
| 완화(Mitigate) | 증대(Enhance) | 기회의 발생가능성·효과를 키운다 |
| 수용(Accept) | 수용(Accept) | 특별히 좇지 않되 오면 받는다 |
예: "성능 테스트가 예상보다 빨리 끝나면 다음 단계를 당길 수 있다"는 기회 → 증대(테스트 자동화로 더 빨리 끝낼 확률을 높임).
그림: 리스크(미발생)와 이슈(발생)를 가르는 기준은 "이미 발생했는가" 하나 — 리스크가 현실화되면 이슈가 되고, 위협에는 회피·전가·완화·수용으로 대응한다.
직접 해보기 — 리스크 등록부터 매트릭스 배치까지
아래는 운영 반영(배포)을 앞둔 SI 프로젝트에서 식별된 리스크 후보 5건입니다. 각 항목을 (1) 발생가능성(낮음·중·높음)과 영향(경미·보통·치명적)으로 분석하고, (2) 매트릭스로 등급(상·중·하)을 매기고, (3) 대응 전략(회피·전가·완화·수용)을 정해 보세요. 모범 답은 ObserveBlock에 있습니다.
1. 운영 DB 마이그레이션 스크립트가 미검증 상태 → 배포 시 데이터 유실 가능
2. 보안팀 운영 반영 승인이 배포 예정일까지 안 떨어질 가능성
3. 외부 결제대행사가 배포 당일 정기 점검과 겹쳐 결제가 멈출 가능성
4. 배포 자체 실패 시 즉시 롤백할 스냅샷·절차 부재
5. 사내 위키 오타 한두 건이 그대로 운영에 노출될 가능성
채울 컬럼: 리스크명 · 발생가능성 · 영향 · 등급 · 대응전략 · 담당 · 기한 · 상태. 종이에 8칸짜리 표를 그려 직접 한 줄씩 채워 보세요 — 이것이 곧 리스크 관리대장입니다.
식별 → 발생가능성×영향 → 등급 → 대응 전략- 1번(마이그레이션 데이터 유실): 가능성 중 × 영향 치명적 → 등급 상. 대응: 완화(리허설+롤백 스냅샷) + 전가(협력사 DBA 입회). 가장 우선.
- 2번(보안 승인 지연): 가능성 중 × 영향 보통(일정 지연) → 등급 중. 대응: 완화(승인 일정 사전 협의·버퍼 확보). 담당·기한 박는 게 핵심.
- 3번(결제대행사 점검 겹침): 가능성 낮음 × 영향 치명적(결제 중단) → 등급 상으로 올림. 대응: 회피(점검 일정과 겹치지 않게 배포일 이동).
- 4번(롤백 절차 부재): 가능성 중 × 영향 치명적 → 등급 상. 대응: 완화(롤백 절차·스냅샷을 배포 전 필수 산출물로 준비).
- 5번(위키 오타): 가능성 높음 × 영향 경미 → 등급 하. 대응: 수용(발생해도 사후 수정으로 충분, 과잉 대응 불필요).
- 핵심 감각: 3번처럼 "가능성 낮음 × 영향 치명적"은 빈도만 보고 무시하면 안 된다 — 영향이 크면 등급을 올려 회피한다.
- 모든 리스크는 담당과 기한이 비어 있으면 "관리되지 않는" 것이다. 등급보다 담당·기한 공란이 더 위험한 신호다.
현장에서 자주 보는 함정
증상: 프로젝트 초기에 리스크 관리대장을 한 번 그럴듯하게 작성했습니다. 그런데 정작 사고가 나고, 회고해 보니 그 사고는 관리대장에 이미 적혀 있던 리스크였습니다. 그런데도 보고서엔 "예상치 못한 장애"라고 적힙니다.
원인: 리스크 관리대장이 살아 있지 않았습니다. 흔한 세 가지 죽은 상태:
- 담당·기한 공란 — 리스크는 적혔는데 "누가 언제까지 무엇을" 칸이 비어 있어 아무도 대응을 실행하지 않음.
- 갱신 안 됨(stale) — 초기에 한 번 쓰고 회의 때 다시 들여다보지 않음. 상태(진행중·완료·종결)가 옛날 그대로.
- 현실화돼도 이슈로 안 넘김 — 리스크가 터졌는데 이슈 관리대장으로 옮겨 추적하지 않아 해결이 흐지부지됨.
해결 방향:
- 리스크 관리대장의 모든 행에 담당·기한·상태를 채우고, 정기 회의(주간)마다 상태를 갱신한다 — 관리대장은 한 번 쓰는 문서가 아니라 매주 살아 움직이는 문서다.
- 리스크가 현실화되면 즉시 이슈 관리대장으로 전환해 담당·해결기한·종결까지 추적한다. "예상치 못한"이 아니라 "등록돼 있던 리스크 N번이 현실화됨"으로 보고한다.
- 신규 리스크는 언제든 추가될 수 있으므로, 식별을 초기 1회로 끝내지 않고 프로젝트 내내 반복한다.
리스크 관리의 실패는 대개 "몰라서"가 아니라 "적어놓고 안 봐서"입니다. 관리대장은 만드는 게 아니라 운영하는 것입니다.
SI/SM 현장에서 리스크·이슈 관리는 PM·PMO의 핵심 보고 언어입니다. 발주사(원청) 주간 보고에서 "현재 상위 리스크 3건과 대응 현황", "이번 주 신규 발생 이슈와 해결 기한"은 거의 고정 항목입니다. 여기서 당신이 협력사·내부 팀으로부터 리스크를 끌어내 등록하고, 등급을 매기고, 담당·기한을 박고, 매주 갱신하는 사람입니다.
특히 한국 SI/SM에서 자주 다루는 리스크는 운영 반영(배포) 장애, 데이터 마이그레이션 영향, 보안 검토·운영 반영 승인 지연, 배포 실패와 롤백 부재입니다. 이들은 전형적으로 "가능성은 중간인데 영향이 치명적"인 우측 상단 리스크라, 등급을 높여 완화(리허설·롤백 준비)와 전가(협력사 책임 명시)를 함께 거는 것이 실무 패턴입니다. 실제 작업은 협력사 엔지니어가 하더라도, 그 리스크가 식별·추적·종결되도록 통제할 책임은 관리자에게 있습니다.
잘못된 보고에 속지 않는 것도 당신의 일입니다. "이상 없습니다"라는 협력사 보고에 대해 "마이그레이션 리허설은 했습니까? 롤백 스냅샷은 있습니까?"라고 리스크 항목으로 되물을 수 있어야, 새벽 3시 비상 소집을 막을 수 있습니다. 리스크·이슈 관리대장은 그 질문들을 체계로 만든 도구입니다.
관련 모듈로 더 깊이:
- WBS와 일정 관리 — 일정 리스크의 근거가 되는 핵심경로·의존성 통제
- 품질과 검수 — 품질·검수 결함을 이슈로 추적·종결하는 연결
- 인시던트 관리 — 이미 터진 문제(이슈)가 운영 인시던트로 번질 때의 대응 절차
다음 모듈에서는 만들어진 결과물이 약속한 기준을 충족하는지 확인하는 품질·검수 관리 — 검수 기준(인수 조건)과 결함 추적, 검수 절차를 SI 산출물 맥락으로 다룹니다.