리스크 관리대장 쓰는 법: 리스크와 이슈를 섞지 않는 칸 구성

요지

리스크는 아직 일어나지 않은 일이고, 이슈는 이미 일어난 일이다. 이미 터진 문제를 리스크 관리대장에 적기 시작하면 대장은 「문제 목록」이 되고, 정작 앞으로 올 일을 미리 막는 일은 아무도 하지 않는다.
한 줄을 「원인 때문에 사건이 생길 수 있고, 그러면 영향이 생긴다」의 세 토막으로 쓰면, 막연한 걱정이 대응할 수 있는 리스크로 바뀐다.
칸은 많을수록 좋은 것이 아니다. 담당(리스크 오너), 대응, 신호, 다시 볼 날 네 칸이 비어 있으면 나머지 칸이 다 차 있어도 그 줄은 관리되고 있지 않다.

리스크와 이슈는 어디서 갈리나

가장 흔한 실수는 「이번 주에 생긴 문제」를 리스크 대장에 적는 것이다. 기준은 하나다. 지금 이 순간 이미 일어났는가.

표는 가로로 밀어서 볼 수 있습니다.

구분	리스크	이슈
시점	앞으로 일어날 수 있음	이미 일어남
물을 것	일어날 가능성은? 일어나면 얼마나?	지금 무엇을 하나? 누가 언제까지?
하는 일	미리 줄이거나 피하거나 넘기거나 받아들일 준비	바로 해결하거나 윗선에 올림
적는 곳	리스크 관리대장	이슈 기록부

리스크가 실제로 터지면 그 줄을 지우지 않는다. 리스크 대장의 상태를 「발생」으로 바꾸고, 이슈 기록부에 새 줄을 만들어 서로 번호를 적어 둔다. 그래야 나중에 「예상했던 일이 터진 것인가, 예상 못 한 일이 터진 것인가」를 셀 수 있다. 예상 못 한 이슈가 많다면 리스크를 찾는 방식부터 손볼 때다.

한 줄을 세 토막으로 쓴다

나쁜 예와 고친 예를 나란히 놓으면 차이가 잘 보인다.

표는 가로로 밀어서 볼 수 있습니다.

나쁜 예	왜 나쁜가	고친 예(원인 → 사건 → 영향)
일정 지연	결과만 있고 원인이 없어 대응할 곳이 없다	외부 결제 모듈 업체의 담당 개발자가 한 명뿐이라(원인), 그 사람이 빠지면 연동 개발이 멈출 수 있고(사건), 그러면 통합 시험 시작이 2주 밀린다(영향)
인력 부족	이미 부족하다면 이슈다. 앞으로의 일이라면 언제, 누가인지 없다	11월에 디자이너 한 명이 다른 프로젝트로 옮길 예정이라(원인), 화면 시안 검토가 한 주에 한 번으로 줄 수 있고(사건), 그러면 시안 확정이 늦어진다(영향)
고객 요구 변경	너무 넓어서 무엇을 해야 할지 모른다	고객사 결재 라인이 개통 한 달 전에 바뀌어(원인), 새 결재자가 화면 범위를 다시 열 수 있고(사건), 그러면 추가 개발이 생긴다(영향)

원인을 적으면 대응이 저절로 보인다. 개발자가 한 명뿐인 것이 원인이라면 「업체에 대체 인력 지정을 계약 조건으로 요청한다」가 대응이 된다. 「일정 지연」에는 대응을 붙일 곳이 없다.

칸 구성

아래는 이 글을 위해 새로 만든 서식이다. 처음에는 이 정도면 충분하고, 프로젝트가 커지면 칸을 더한다.

표는 가로로 밀어서 볼 수 있습니다.

칸	무엇을 적나	자주 하는 실수
번호	R-01, R-02 … (이슈는 I-01로 따로)	지운 줄의 번호를 다시 씀
리스크 문장	원인 → 사건 → 영향 세 토막	결과만 한 낱말로 적음
위협/기회	나쁜 쪽인지 좋은 쪽인지	기회는 아예 적지 않음
가능성	높음, 중간, 낮음(또는 1~5)	팀마다 기준이 달라 비교가 안 됨
영향	높음, 중간, 낮음(또는 1~5). 일정, 비용, 범위, 품질 중 어디에	「크다」만 적고 무엇에 큰지 없음
우선순위	가능성 × 영향 같은 정해 둔 계산	회의 분위기로 정함
담당(리스크 오너)	사람 이름 한 명	「개발팀」, 「전원」
대응	무엇을, 언제까지. 대응 전략 이름(아래)도 함께	「모니터링」 한 낱말
신호	이것이 보이면 터지기 직전이라는 표시	비워 둠
다시 볼 날	날짜	비워 둠
상태	열림, 대응 중, 발생(이슈 번호), 닫힘	닫을 기준이 없어 계속 열려 있음

담당은 사람 한 명으로 적는 편이 좋다. 표준이 정한 규칙이라기보다 실무에서 흔히 쓰는 방법이다. 팀 이름을 적으면 모두가 누군가 보고 있겠지 하고 넘어간다. 담당은 혼자 다 하는 사람이 아니라 그 줄을 끝까지 지켜보고 대응을 챙기는 사람이다.

「모니터링」은 대응이 아니다. 지켜보기만 할 거라면 무엇을 보면 움직일지(신호 칸)와 언제 다시 볼지(다시 볼 날)를 함께 적어야 한다. 그래야 받아들이기로 한 것인지 잊은 것인지 구분된다.

신호 칸이 가장 쓸모 있다. 위 예라면 「업체 담당 개발자의 회신이 사흘 넘게 없음」이 신호다. 신호를 적어 두면 주간 회의에서 「신호가 보인 줄이 있나」만 물어도 대장이 살아 있게 된다.

대응 전략 이름을 맞춰 둔다

대응 칸에는 무엇을 할지와 함께 어떤 종류의 대응인지 적어 두면, 나중에 대장을 훑을 때 한눈에 보인다. PMBOK® Guide 8판 한국어판 용어집의 이름을 따르면 다음과 같다(본문 일부에는 「개선」 대신 「강화」라는 말도 쓰인다).

표는 가로로 밀어서 볼 수 있습니다.

위협(나쁜 쪽)	뜻	기회(좋은 쪽)	뜻
회피	원인을 없애 아예 생기지 않게	활용	반드시 일어나게
전가	책임과 비용을 다른 쪽(계약, 보험)으로 넘김	공유	더 잘 살릴 수 있는 쪽과 나눔
완화	가능성이나 영향을 줄임	개선	가능성이나 효과를 키움
수용	알고 받아들임(예비 시간과 비용을 두거나 그대로 둠)	수용	생기면 누림
에스컬레이션	프로젝트 권한 밖이라 윗선이나 다른 조직에 넘김	에스컬레이션	위와 같음

예를 들어 결제 모듈 업체 리스크에 「대체 인력 지정을 계약 조건으로 요청」은 완화, 「통합 시험 앞에 1주 여유를 둠」은 수용(예비 시간)이다. 한 줄에 대응이 둘일 수도 있다.

회의에서 대장을 살려 두는 법

주간 회의에서 대장 전체를 읽지 않는다. 신호가 보인 줄, 다시 볼 날이 지난 줄, 우선순위 상위 몇 줄만 본다. 몇 줄을 볼지는 팀이 정하면 되고, 처음에는 다섯 줄 정도로 시작해 볼 만하다.
새로 생긴 문제가 보고되면 먼저 묻는다. 「이건 이미 일어났나요?」 그렇다면 이슈 기록부로 보낸다.
리스크가 이슈가 되면 리스크 줄의 상태를 「발생」으로 바꾸고 이슈 번호를 적는다. 지우지 않는다.
닫을 때는 이유를 한 줄 남긴다. 「업체가 대체 인력 지정, 원인 해소」처럼.
단계가 끝날 때마다, 예상한 리스크가 터진 수와 예상 못 한 이슈 수를 센다. 다음 프로젝트에서 리스크를 찾을 때 이 숫자가 좋은 참고가 된다.

이번 주에 할 일

지금 쓰는 리스크 목록에서 이미 일어난 일을 골라 이슈 기록부로 옮긴다.
남은 줄 중 우선순위가 높은 다섯 줄을 원인 → 사건 → 영향 세 토막으로 다시 쓴다.
그 다섯 줄에 담당 한 명, 대응, 신호, 다시 볼 날을 채운다.
기회 줄이 하나도 없다면 하나를 찾아 적어 본다.

가능성과 영향을 숫자로 더 정밀하게 다루고 싶다면 「의사결정 트리와 기대화폐가치(EMV)」 글과 「몬테카를로 시뮬레이션으로 일정 리스크 읽기」 글에서 이어서 볼 수 있다.

참고

PMI, 『PMBOK® Guide』 8판 한국어판의 용어: 리스크 관리대장, 이슈 기록부, 리스크 오너, 위협과 기회의 대응 전략 이름. 이 글은 용어만 따랐고 본문 문장은 옮기지 않았다.
서식, 나쁜 예와 고친 예는 이 글을 위해 새로 만든 것이고, 예시 속 업체와 일정은 지어낸 것이다.
PMBOK은 Project Management Institute, Inc.의 등록 상표입니다.