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회로 끝내지 않고 프로젝트 내내 반복한다.
리스크 관리의 실패는 대개 "몰라서"가 아니라 "적어놓고 안 봐서"입니다. 관리대장은 만드는 게 아니라 운영하는 것입니다.
심화 — 대장에 올릴 수 있는 리스크와 올릴 수 없는 리스크
심화: 리스크 보고의 정치 — 수박 보고와 발주사 귀책 리스크
본문의 절차는 리스크를 '식별하면 등록한다'고 가정합니다. 그러나 발주-수행 관계에서 리스크 등록은 중립적 행위가 아닙니다. 대장이 발주사 주간보고에 그대로 올라가는 구조에서는, 리스크 한 줄이 정보가 아니라 신호가 됩니다 — 누군가에 대한 문제 제기이자, 누군가의 책임 예고.
- 수박 보고(watermelon reporting): 겉은 초록, 속은 빨강. 등급 '상' 리스크를 정직하게 올리면 발주사의 문책성 질의와 추가 보고 요구가 따라오기 때문에, 현장은 학습합니다 — 해결 전망이 보이는 리스크만 대장에 올리고, 진짜 위험한 것은 팀 내부에서 '조용히' 관리한다. 그 결과 대장은 안전한 리스크의 목록이 되고, 정작 터지는 것은 늘 대장 밖에 있던 것입니다.
- 발주사 귀책 리스크의 딜레마: SI에서 가장 흔한 상위 리스크 — 현업 요구사항 확정 지연, 발주사 의사결정 지연, 현업 인터뷰 미협조 — 는 대부분 발주사 쪽에 원인이 있습니다. 이것을 대장에 쓰는 순간 '발주사 지목'으로 읽혀 빼달라는 요구가 옵니다. 그런데 빼는 순간 수행사는 이중으로 집니다. 리스크는 그대로 남고, 나중에 터졌을 때 "식별하고도 관리하지 않았다"는 책임까지 얹힙니다.
- 면책 알리바이로의 전락: 반대 방향의 형해화도 있습니다. 터질 때를 대비해 온갖 리스크를 등록만 해두는 것 — "우리는 경고했었다"용 대장입니다. 대응·담당·기한 없는 등록은 관리가 아니고, 발주사도 그것을 알기 때문에 대장 전체의 신뢰가 무너집니다.
규모별로 압력의 모양이 다릅니다. 대형 공공은 감리·PMO가 대장을 감사 대상으로 보기 때문에 '감사 대응용 대장'과 '실제 관리'가 이원화되기 쉽고, 중소 사업은 대장 자체가 형식이 되어 구두 관리로 흐릅니다. 처방의 방향은 같습니다 — 리스크 문안을 귀책 지목이 아니라 공동 대응 항목으로 쓰는 기술("현업이 확정을 안 해줘서"가 아니라 "요구사항 확정 절차의 병목으로 설계 일정 영향 가능 — 양측 공동 조치: 확정 회의 정례화"), 그리고 하향 조정·삭제 요구가 오면 제기했다는 사실 자체를 회의록·공문으로 남기는 습관입니다.
상황: 수행사 PM이 주간보고 리스크 대장에 "현업 요구사항 확정 지연 — 이달 말까지 미확정 시 설계 일정 영향(등급: 상)"을 등록했습니다. 보고 다음 날 발주사 정보전략팀 과장이 따로 불러 말합니다. "이게 우리 현업 임원 보고에 올라가면 시끄러워져요. 다음 주면 확정될 테니 이번엔 뺍시다." PM은 관계를 생각해 구두 약속을 믿고 항목을 삭제했습니다. 요구사항은 석 달간 확정되지 않았고, 설계가 두 달 밀리며 오픈이 연기됩니다. 책임 공방에서 발주사는 "수행사가 리스크로 식별·관리하지 않았다, 대장 어디에도 없다"고 주장하고, 빼자고 했던 과장은 이미 인사이동으로 자리에 없습니다. 논의는 지체상금까지 갑니다.
원인: 리스크 대장을 발주사와의 공유 보고 문서 하나로만 운영해, 대장에서 빠지는 순간 기록 자체가 소멸하는 구조였기 때문입니다. 삭제 요구도, "다음 주 확정" 약속도 어디에도 남지 않았습니다. 무너진 것은 리스크 식별이 아니라 기록의 관리입니다 — 리스크는 정확히 식별돼 있었습니다.
진단: 대장의 버전 이력을 확인합니다. 항목이 등록됐다 삭제된 흔적이 있는가, 삭제 시점 전후의 회의록·메일에 그 경위가 남아 있는가. 삭제 전 주간보고 원본(발주사에 이미 송부된 것)이 있다면 그것이 가장 강한 증거입니다. 아무것도 없다면 귀책 협상에서 쓸 카드가 없다는 사실부터 인정하고 현재 시점 기준으로 대응을 재구성해야 합니다.
해결: 사후적으로는 삭제 전 대장 사본·기송부 주간보고·당시 메일을 모아 시간선을 재구성하고, 귀책 100%를 다투기보다 공동 책임 구도로 협상 프레임을 바꿉니다. 구조적으로는 세 가지를 규칙화합니다 — (1) 대장에서 삭제를 금지하고 상태 변경(종결·보류)만 허용하되 사유를 필수 기록한다, (2) 발주사 요청으로 보고서에서 빼더라도 내부 대장에는 유지하고 그 요청 자체를 회의록에 남긴다, (3) 발주사 귀책성 리스크는 공문 또는 공식 회의록으로 최소 1회 제기 기록을 확보한다. "빼자"는 요청을 정면으로 거절하기 어렵다면, 빼는 대신 문안을 공동 조치 형태로 바꾸는 것이 현실적인 타협입니다 — 기록은 남기되 얼굴은 세워 주는 방법입니다.
SI/SM 현장에서 리스크·이슈 관리는 PM·PMO의 핵심 보고 언어입니다. 발주사(원청) 주간 보고에서 "현재 상위 리스크 3건과 대응 현황", "이번 주 신규 발생 이슈와 해결 기한"은 거의 고정 항목입니다. 여기서 당신이 협력사·내부 팀으로부터 리스크를 끌어내 등록하고, 등급을 매기고, 담당·기한을 박고, 매주 갱신하는 사람입니다.
특히 한국 SI/SM에서 자주 다루는 리스크는 운영 반영(배포) 장애, 데이터 마이그레이션 영향, 보안 검토·운영 반영 승인 지연, 배포 실패와 롤백 부재입니다. 이들은 전형적으로 "가능성은 중간인데 영향이 치명적"인 우측 상단 리스크라, 등급을 높여 완화(리허설·롤백 준비)와 전가(협력사 책임 명시)를 함께 거는 것이 실무 패턴입니다. 실제 작업은 협력사 엔지니어가 하더라도, 그 리스크가 식별·추적·종결되도록 통제할 책임은 관리자에게 있습니다.
잘못된 보고에 속지 않는 것도 당신의 일입니다. "이상 없습니다"라는 협력사 보고에 대해 "마이그레이션 리허설은 했습니까? 롤백 스냅샷은 있습니까?"라고 리스크 항목으로 되물을 수 있어야, 새벽 3시 비상 소집을 막을 수 있습니다. 리스크·이슈 관리대장은 그 질문들을 체계로 만든 도구입니다.
실전 랩으로 손에 익히기: 리스크·이슈 관리 실습 — 리스크와 이슈를 구분하고 평가·대응전략·등록부를 설계합니다.
관련 모듈로 더 깊이:
- WBS와 일정 관리 — 일정 리스크의 근거가 되는 핵심경로·의존성 통제
- 품질과 검수 — 품질·검수 결함을 이슈로 추적·종결하는 연결
- 인시던트 관리 — 이미 터진 문제(이슈)가 운영 인시던트로 번질 때의 대응 절차
다음 모듈에서는 만들어진 결과물이 약속한 기준을 충족하는지 확인하는 품질·검수 관리 — 검수 기준(인수 조건)과 결함 추적, 검수 절차를 SI 산출물 맥락으로 다룹니다.