RAID 로그 템플릿 Permalink
이 템플릿을 사용하여 Quire에서 RAID 로그를 운영하세요. 위험, 가정, 이슈, 의존 관계를 한 곳에서 관리하고, 테이블 뷰에서 영향도 기준으로 순위를 매기며, 실제로 항목을 종결하는 매주 검토를 진행하세요.
RAID 로그 프로젝트를 방문하여 워크스페이스에 사본 생성하기하면 처음부터 모든 것을 직접 구성하지 않아도 됩니다.
더 많은 바로 사용할 수 있는 템플릿을 탐색하여 워크플로를 빠르게 시작해 보세요.
RAID 로그 이해하기
RAID는 Risks(위험), Assumptions(가정), Issues(이슈), Dependencies(의존 관계)의 약자입니다. RAID 로그는 이 네 가지 모두를 지속적으로 기록하는 도구입니다. 잘못될 수 있는 것, 확인 없이 전제하고 있는 것, 이미 잘못된 것, 그리고 팀 외부에서 필요한 것을 기록합니다.
대부분의 팀은 이 중 일부를 어딘가에 추적합니다. 그러나 네 가지를 한 곳에 모아두는 팀은 거의 없으며, 바로 거기에 가치가 있습니다. 누락된 예산 코드는 작은 행정적 이슈처럼 보이지만, 알고 보면 벤더가 자격 증명을 제공하지 않는 이유이고, 출시 주간 계약이 여전히 서명되지 않은 이유입니다. 하나의 근본 원인이 세 개의 별도 목록에 흩어져 있고, 아무도 이를 연결하지 못합니다.
로그는 5개의 섹션으로 구성되며, 상단에 마일스톤이 고정되어 그 아래의 모든 날짜가 중요한 마감일 기준으로 읽힙니다.
네 개의 섹션이 카테고리를 담습니다. 다섯 번째 섹션인 RAID 거버넌스는 검토 주기를 담으며, 이것이 로그가 두 번째 달 이후에도 살아남을지를 결정합니다. 21개의 작성 예시 항목이 미리 채워져 있어, 직접 항목을 교체하기 전에 좋은 작성 형식이 어떤 모습인지 확인할 수 있습니다.
RAID 로그와 위험 등록부
Quire는 두 가지 모두를 제공하며, 서로 다른 질문에 답합니다. 위험 등록부는 하나의 카테고리를 깊이 다루는 도구입니다. 5x5 매트릭스, 수치 위험 점수, 5가지 공식 대응 전략, 위험만을 집중적으로 다루는 거버넌스 주기를 제공합니다. RAID 로그는 네 가지 카테고리를 더 가볍게 다루며 확률과 영향도만으로 위험을 점수화하지만, 등록부가 담을 공간이 없는 가정과 의존 관계도 함께 보관합니다.
프로젝트를 탈선시킬 수 있는 모든 것을 한 곳에서 관리하고 싶다면 로그를 사용하세요. 위험 관리 자체가 주요 업무이고 점수가 방어 가능해야 한다면 등록부를 사용하세요. RAID 로그를 실무 기록으로, 등록부를 공식 문서로 병행 운영하는 팀도 많습니다.
이 템플릿에는 설정 방법, 카테고리 규칙, 주의해야 할 실패 모드를 다루는 문서가 포함되어 있습니다.
두 번째 문서에는 매주 검토 안건이 담겨 있어, 회의를 진행하는 사람이 당일 아침에 순서를 즉흥적으로 만들 필요가 없습니다.
네 가지 카테고리 구분하기
카테고리는 자주 혼동됩니다. 항목이 어디에 속하는지를 두고 논쟁하는 것은 검토 회의 첫 10분을 낭비하기 좋은 방법입니다. 네 가지 테스트로 거의 모든 경우를 해결할 수 있습니다.
| 카테고리 | 시제 | 답하는 질문 | 테스트 |
|---|---|---|---|
| 위험 | 미래, 불확실 | 무엇이 잘못될 수 있는가? | “X가 발생하면 Y가 된다”로 작성할 수 있는가? |
| 가정 | 현재, 미검증 | 우리가 전제하고 있는 것은 무엇인가? | 사실이 아닌 것으로 밝혀지면 놀랄 것인가? |
| 이슈 | 현재, 확실 | 지금 무엇이 잘못되고 있는가? | 이미 발생했는가? |
| 의존 관계 | 미래, 타인의 몫 | 외부에서 무엇이 필요한가? | 다음 행동이 팀 외부에 있는가? |
나머지는 세 가지 규칙으로 해결됩니다.
- 현실화된 위험은 더 이상 위험이 아닙니다. 이슈로 이동하고, 어디로 갔는지 메모와 함께 위험을 종결하세요. 양쪽에 모두 열린 상태로 두지 마세요.
- 거짓으로 판명된 가정은 단순히 틀린 것이 아닙니다. 결과를 수반합니다. 가정을 종결하고 그 결과를 위험 또는 이슈로 등록하세요.
- 추적을 중단한 의존 관계는 위험입니다. 매달 정리 검토 시 재점수화하세요.
템플릿의 샘플 항목 A-01은 두 번째 규칙의 작성 예시로, 그것이 만들어낸 이슈와 연결되어 있습니다.
테이블 뷰에서 로그 읽기
테이블 뷰는 Professional, Premium, Enterprise 플랜에서만 사용할 수 있습니다. 자세한 내용은 요금제 페이지에서 확인하세요.
테이블 뷰는 RAID 로그의 핵심입니다. 모든 사용자 지정 필드를 항목 옆에 나란히 보여주며, 영향도 기준으로 정렬하면 목록 상단이 자연스럽게 회의 안건이 됩니다.
7개의 필드가 로그를 지탱합니다.
| 필드 | 역할 |
|---|---|
| RAID ID | R-01 또는 D-05와 같은 안정적인 식별자로, 회의에서 제목 전체를 읽지 않고도 항목을 인용할 수 있습니다. 항목이 종결된 후에도 번호를 재사용하지 마세요. |
| 유형 | 의도적으로 섹션을 중복합니다. 섹션은 목록을 구성하고, 유형은 포트폴리오 전반에서 필터링하거나 그룹화하거나 하나의 카테고리만 추출할 수 있게 합니다. |
| 확률 | 위험에만 해당합니다. 이슈는 이미 발생했으므로 이 열은 비워 둡니다. |
| 영향도 | 모든 항목에 적용됩니다. 정렬 기준이 되는 열이며 무엇을 에스컬레이션할지 결정합니다. |
| 등록일 | 항목이 기록된 날짜입니다. |
| 마지막 검토일 | 방치를 드러내는 필드입니다. 매달 정리 검토 시 이 기준으로 정렬하여 가장 오래된 항목부터 처리하세요. |
| 의존 대상 | 책임 있는 팀, 벤더 또는 담당자를 기명합니다. 주로 의존 관계에 사용되지만, 팀 외부 요인으로 막혀 있는 항목 어디에나 유용합니다. |
등록일과 마지막 검토일은 단순한 행정 기록처럼 보입니다. 그러나 3월에 등록되고 4월에 검토된 항목이 9월에도 여전히 열려 있다면 제대로 관리되지 않고 있는 것이며, 그 사실을 누군가가 우연히 알아채지 않고도 드러내는 것은 이 두 날짜뿐입니다.
참고: 이슈에 확률을 입력하고 있다면 아직 재분류되지 않은 위험일 가능성이 높습니다. 이슈는 이미 발생한 것이므로 확률은 100%입니다.
8개의 태그 — 예산, 일정, 기술, 범위, 고객, 벤더, 인력, 컴플라이언스 — 가 네 가지 카테고리 전체를 가로지릅니다. 이 태그들은 유형과는 다른 질문에 답합니다. 항목이 어떤 종류인지가 아니라 어디서 비롯되었는지를 보여줍니다.
보존할 가치 있는 항목 작성하기
유용한 RAID 로그와 형식적인 문서의 차이는 거의 전적으로 항목이 어떻게 작성되었는가에 달려 있습니다. 템플릿의 모든 샘플 항목은 동일한 4단계 구조를 따릅니다.
설명은 X이면 Y이다 형식의 조건문으로 시작하고, 누군가 관심을 가질 단위로 발생 시 영향도를 명시한 다음, 대응 방안을 기술하고, 마지막으로 주시해야 할 트리거를 제시합니다. 완화 작업은 항목의 하위 업무로 연결되어 계획과 기록이 같은 위치에 유지됩니다.
다섯 가지 규칙이 차이를 만듭니다.
- 위험은 원인과 결과로 작성하세요. “벤더 지연”은 걱정입니다. “벤더가 8월 6일을 놓치면 인증 테스트가 운영 자격 증명 없이 시작되고 테스트가 2주 지연된다”는 팀이 행동할 수 있는 내용입니다.
- 모든 위험에 트리거를 부여하세요. 위험이 더 이상 가설이 아니게 되는 관찰 가능한 시점입니다. 없으면 에스컬레이션이 늦게, 감에 의존하여 이루어집니다.
- 대응 방안을 명시하세요. 회피, 완화, 이전, 수용 중 하나입니다. “모니터링”은 대응이 아니라 “아직 결정하지 못했다”는 표현입니다.
- 영향도는 누군가 관심을 가질 단위로 작성하세요. 주, 비용, 고객 수, 평판. “높은 영향도”는 스폰서에게 아무것도 전달하지 못합니다.
- 모든 항목에 날짜를 부여하세요. 마감일이 없는 항목은 결코 처리되지 않습니다.
모든 항목에 한 명의 담당자를 지정하세요. 팀은 아무것도 추적하지 않습니다. 팀 내 누구도 그 추적이 자신의 몫이라고 생각하지 않기 때문입니다.
보드 뷰에서 흐름 추적하기
상태 기준으로 그룹화된 보드 뷰는 재고 현황이 아닌 흐름을 보여줍니다. 이것은 더 정직한 그림입니다.
6가지 상태가 로그를 운영합니다.
| 상태 | 사용 시점 |
|---|---|
| 열림 | 기록되고 담당자가 지정되었으나 아직 진행 중인 것이 없음. |
| 진행 중 | 누군가 적극적으로 처리 중. |
| 에스컬레이션됨 | 프로젝트 팀의 범위를 초과하여 상위의 결정이 필요함. |
| 응답 대기 중 | 다음 행동이 실질적으로 타인에게 있음. |
| 종결됨 | 해결되었거나, 철회되었거나, 더 이상 관련이 없음. |
| 검증됨 | 확인하여 사실로 확인된 가정. |
‘응답 대기 중’은 그 자리를 충분히 할 일을 합니다. 없으면 ‘진행 중’이 “내가 작업 중”과 “9일 전에 이메일을 보냈다”를 모두 포함해야 하는데, 이 둘은 완전히 다른 후속 조치가 필요합니다.
팁: 에스컬레이션됨 열을 한 번 읽는 것이 아니라 몇 주에 걸쳐 지켜보세요. 채워지는 속도가 비워지는 속도보다 빠르다면, 그것은 어떤 상태 보고서보다 신뢰할 수 있는 프로젝트 건강 신호입니다.
하위 목록으로 교차 뷰 만들기
Free Subscription 플랜에서는 프로젝트당 2개의 하위 목록을 만들 수 있으며, 이 템플릿에는 4개가 포함되어 있습니다. 사본 생성하기 후 팀이 가장 자주 여는 2개를 남기거나, 구독 플랜을 업그레이드하여 모두 사용하세요. 자세한 내용은 요금제 페이지에서 확인하세요.
섹션은 “이것이 어떤 종류인가”에 답합니다. 4개의 하위 목록은 네 가지 카테고리 전체를 가로지르는 질문에 답하며, 바로 이 지점에서 네 개 대신 하나의 로그를 유지하는 것이 효과를 발휘하기 시작합니다.
- 지금 에스컬레이션 — 카테고리에 관계없이 아직 열려 있는 모든 심각 영향도 항목입니다. 이것이 운영 위원회 자료입니다. 약 6개 이상이 되면 프로젝트가 관리되는 것이 아니라 지켜보고 있는 것입니다.
- 타인을 기다리는 항목 — 다음 행동이 내 몫이 아닌 모든 항목입니다. 매번 상태 보고 전에 열어보고 상위 3개를 추적하세요.
- 미검증 가정 — 너무 늦을 때까지 아무도 읽지 않는 목록입니다. 분기에 한 번 소리 내어 읽어보세요.
- 벤더 체인 — 필터가 아닌 작성 예시입니다.
마지막 항목을 먼저 열어볼 가치가 있습니다. 4개의 항목으로 단일 로그의 가치 전체를 보여주기 때문입니다.
미처리된 구매 주문은 이슈입니다. 이것이 재무팀이 주문을 승인하지 못하게 막는 의존 관계를 만들고, 이것이 벤더가 운영 자격 증명을 전달하지 못하게 막는 또 다른 의존 관계가 됩니다. 그리고 그것이 출시 주간 계약이 여전히 서명되지 않은 이유이며, 이는 위험으로 기록됩니다. 세 가지 카테고리, 하나의 근본 원인, 같은 로그에 있기 때문에 비로소 보이는 것입니다. 항목들은 실제 업무 의존 관계로 연결되어 있어, 체인이 설명에 그치지 않고 실제로 적용됩니다.
로그를 정직하게 유지하기
검토 없는 로그는 프로세스가 아닌 문서일 뿐입니다. 거버넌스 섹션에는 4개의 반복 업무가 있어, 누군가의 기억에 의존하는 대신 리듬이 일정에 자동으로 반영됩니다.
| 주기 | 내용 |
|---|---|
| 매주 | 영향도 기준으로 정렬하여 30분 검토. 목록 상단이 안건입니다. |
| 매달 | 오래된 항목을 종결하고 열린 위험을 재점수화합니다. 3월에 점수를 매긴 위험이 7월에도 올바르게 점수화되어 있는 경우는 드뭅니다. |
| 분기별 | 가정을 재검증합니다. 모든 사람이 건너뛰는 검토이자 가장 많은 것을 포착하는 검토입니다. |
| 필요 시 | 위험 항목을 운영 위원회에 에스컬레이션합니다. |
RAID 로그가 죽는 세 가지 실패 모드가 있으며, 조용히 찾아오기 때문에 명시할 가치가 있습니다.
- 묘지가 됩니다. 50개의 열린 항목 대부분이 오래되어 사람들이 아예 열어보지 않습니다. 2개월 동안 아무도 건드리지 않은 항목은 실재하지 않거나 소유되지 않은 것입니다.
- 모든 것이 높은 영향도입니다. 로그 전체가 빨간색이면 더 이상 아무것도 순위를 매기지 못하는 것입니다. 20개 중 4개의 심각 항목은 그럴듯한 프로젝트입니다. 14개는 아무도 제대로 고민하지 않은 프로젝트입니다.
- 운영 위원회 회의 전에만 업데이트됩니다. 그 시점에서 관리 도구에서 보고 도구로 조용히 전락한 것입니다.
세 가지 모두 동일한, 화려하지 않은 해결책이 있습니다. 짧은 매주 검토와 적극적인 항목 종결입니다.
위험을 점수화하고 등록부를 살아있게 유지하는 방법에 대해 블로그에서 더 알아보세요.
자주 묻는 질문
RAID 로그란 무엇인가요?
RAID 로그는 잘못될 수 있는 것, 확인 없이 전제하고 있는 것, 이미 잘못된 것, 그리고 팀 외부에서 필요한 것을 단일 기록으로 지속적으로 관리하는 도구입니다. 네 가지를 한 곳에 모아두면 별개처럼 보이는 문제들이 하나의 근본 원인을 공유하고 있음을 발견할 수 있습니다.
RAID는 무엇의 약자인가요?
Risks(위험), Assumptions(가정), Issues(이슈), Dependencies(의존 관계)의 약자입니다. 프로그램 업무에서는 Risks, Actions, Issues and Decisions로 확장하는 경우도 있습니다. Quire 템플릿은 첫 번째 버전을 사용하는데, 가정과 의존 관계가 팀이 어디에서도 추적하지 않을 가능성이 가장 높은 두 가지 카테고리이기 때문입니다.
위험과 이슈의 차이점은 무엇인가요?
시제와 확실성의 차이입니다. 위험은 미래이고 불확실하여 “X이면 Y이다”로 작성합니다. 이슈는 현재이고 확실합니다. 이미 발생했기 때문입니다. 위험이 현실화되면 더 이상 위험이 아니므로, 이슈로 이동하고 어디로 갔는지 메모와 함께 위험 항목을 종결하세요.
RAID 로그와 위험 등록부의 차이점은 무엇인가요?
위험 등록부는 하나의 카테고리를 5x5 매트릭스와 공식 대응 전략으로 깊이 다루는 도구입니다. RAID 로그는 네 가지 카테고리를 더 가볍게 다루며, 등록부가 담을 공간이 없는 가정과 의존 관계도 함께 보관합니다. 두 가지를 병행 운영하는 팀도 많습니다.
RAID 로그는 누가 소유하나요?
프로젝트 관리자가 로그 자체를 소유합니다. 즉, 검토 주기, 오래된 항목 종결, 에스컬레이션을 담당합니다. 모든 개별 항목에는 한 명의 담당자가 필요하며, 팀이 아닌 개인이어야 합니다. 팀은 아무것도 추적하지 않기 때문입니다.
RAID 로그는 얼마나 자주 검토해야 하나요?
전체 로그를 영향도 기준으로 정렬하여 매주 약 30분씩 검토합니다. 오래된 항목을 종결하고 열린 위험을 재점수화하기 위해 매달 검토합니다. 분기별로 가정을 재검증합니다. 템플릿은 이 세 가지를 반복 업무로 보관하여 일정에 자동으로 반영됩니다.
RAID 로그 항목에는 무엇이 포함되어야 하나요?
R-01과 같은 안정적인 ID, 카테고리, 영향도 평가, 한 명의 담당자, 마감일, 서면 대응이 필요합니다. 위험의 경우 확률과 트리거도 필요합니다. 트리거는 위험이 가설 단계를 중지하고 누군가가 행동해야 하는 관찰 가능한 시점입니다.
RAID 로그가 유용성을 잃는 이유는 무엇인가요?
세 가지 실패 모드가 있습니다. 오래된 항목이 쌓여 묘지가 되어 사람들이 열어보지 않게 됩니다. 모든 것이 높은 영향도로 표시되어 우선순위 판단이 불가능해집니다. 또는 운영 위원회 회의 전에만 업데이트됩니다. 세 가지 모두 동일한 해결책이 있습니다. 짧은 매주 검토와 적극적인 항목 종결입니다.
Quire에 바로 사용할 수 있는 RAID 로그 템플릿이 있나요?
네. RAID 로그 프로젝트를 방문하여 워크스페이스에 사본 생성하기 하면, 4개의 카테고리 섹션과 거버넌스 섹션, 7개의 사용자 지정 필드, 6가지 상태, 8개의 태그, 4개의 교차 카테고리 하위 목록, 21개의 작성 예시 항목이 이미 설정된 상태로 사용할 수 있습니다.