PlayInfoBox

홈 / 유틸리티 / RAID 로그

RAID 로그 도구

프로젝트의 리스크·가정·이슈·의존성을 한 곳에 기록하고 해결 여부를 체크해보세요.

⚠️ Risks 아직 일어나지 않았지만 우려되는 위험

🤔 Assumptions 사실 확인 없이 전제하고 있는 것

🔥 Issues 이미 발생한 문제

🔗 Dependencies 다른 팀·외부 요인에 대한 의존

RAID 로그가 해결하는 문제

프로젝트가 틀어지는 원인은 대개 일정표에 적혀 있지 않은 것들입니다. 누군가의 머릿속에만 있는 우려, 확인하지 않은 채 굳어진 전제, 다른 팀이 약속한 날짜, 이미 터졌지만 회의에서 한 번 언급되고 잊힌 문제가 그렇습니다. RAID 로그는 이런 것들을 Risk, Assumption, Issue, Dependency 네 칸에 나눠 적어 정기 점검의 대상으로 만드는 단순한 표입니다. 프로젝트 관리 현장에서 널리 쓰이는 형식이며, 팀마다 칸 이름이나 열을 바꿔 쓰기도 합니다.

네 칸의 구분과 다음 행동

칸상태스스로 던질 질문기록 후 해야 할 일
Risk (리스크)아직 일어나지 않음일어날 가능성과 영향은?예방·완화 계획 또는 감시 지표 지정. 현실화되면 Issue로 이동
Assumption (가정)확인되지 않은 전제틀리면 무엇이 무너지나?확인 담당자와 확인 기한 지정. 틀린 것으로 판명되면 Risk 또는 Issue로 이동
Issue (이슈)이미 발생지금 누가 해결하나?담당자·기한·에스컬레이션 대상 지정
Dependency (의존성)외부 산출물 대기누가 언제까지 무엇을 주나?상대 담당자와 약속 기한 기록, 지연 시 Issue로 이동

헷갈리기 쉬운 경계는 두 군데입니다. "고객이 요구사항을 바꿀 수 있다"는 아직 일어나지 않았으므로 Risk이고, "고객이 어제 요구사항을 바꿨다"는 이미 일어났으므로 Issue입니다. "API 문서가 최신일 것이다"는 Assumption이며, 그 문서를 갱신해 줄 팀이 있고 날짜를 약속했다면 Dependency로 따로 적습니다. 한 항목이 두 칸에 걸치면 상태가 더 구체적인 쪽에 적으세요.

작성 예시: 발주사 PM이 관리하는 외주 쇼핑몰 리뉴얼(3개월)

아래는 설명용 가상 프로젝트입니다. 발주사 PM이 외부 제작사에 쇼핑몰 리뉴얼을 맡겼고, 킥오프 직후 이 로그를 만든다고 가정합니다.

Risk에는 우선순위를 붙이면 회의가 훨씬 짧아집니다. 가능성과 영향을 각각 1~5점으로 매기고 곱하는 방식은 가장 단순한 방법입니다(점수와 구간은 팀이 정하는 약속이며 표준값이 아닙니다). 위 Risk 후보에 임의로 점수를 매겨 정렬하면 다음과 같습니다.

Risk (예시)가능성영향점수
런칭 직전 요구사항이 추가됨4416
결제 대행사 심사가 일정보다 늦어짐3515
상품 이미지 2,000장을 우리 쪽에서 제때 못 줌4312
제작사 핵심 개발자가 중간에 교체됨248
기존 회원 데이터 이전 포맷이 예상과 다름236

이 예시에서는 "런칭 직전 요구사항 추가"(4×4=16)와 "결제 심사 지연"(3×5=15)이 거의 같은 점수라 순위만으로는 구분이 안 됩니다. 점수가 근접하면 영향이 더 큰 쪽(여기서는 심사 지연)을 먼저 다루는 식의 보조 규칙을 정해 두세요. 점수보다 더 중요한 것은 상위 항목마다 담당자와 대응 날짜를 정하는 일입니다. 정교한 매트릭스가 필요하면리스크 매트릭스 도구를 쓰세요.

점수를 구간으로 나누는 참고표

가능성과 영향을 각각 1~5점으로 매기면 곱은 1부터 25까지입니다. 아래 표는 25개 조합이 각 구간에 몇 칸씩 들어가는지 계산한 것이며, 구간의 경계와 대응 방식은 설명을 위한 예시일 뿐 표준이 아닙니다. 표에서 보듯 "매우 높음"에 들어가는 조합은 4칸뿐이라, 모든 항목이 꼭대기에 몰렸다면 점수를 너무 후하게 줬거나 프로젝트가 정말 위험한 상태라는 신호입니다.

구간(예시)점수 범위해당 조합 수(25칸 중)권장 대응(예시)
낮음1~48칸기록만 하고 월 1회 훑어봄
보통5~97칸담당자 지정, 주간 점검에서 상태 확인
높음10~156칸대응 계획과 기한을 정해 매주 보고
매우 높음16~254칸즉시 대응 회의, 상위 책임자에게 공유

다른 상황에서의 작성 예시: 사내 소프트웨어 릴리스 준비(6주)

앞의 예시가 외부 업체와 일하는 발주사 입장이었다면, 이번에는 같은 회사 안에서 앱 업데이트를 내는 제품 담당자의 로그입니다. 역시 설명용 가상의 상황입니다.

이 예시에서 눈여겨볼 곳은 Assumption입니다. "약관 개정이 필요 없다"는 확인 담당자와 기한을 붙이면 며칠 안에 사실로 굳거나 Risk로 바뀌고, 그대로 두면 출시 직전에야 법무 검토 일정과 부딪힐 수 있습니다. Dependency에 약속 날짜가 있는 이유도 같습니다. 날짜가 적혀 있어야 점검 때 "지났는가"를 기계적으로 물을 수 있습니다.

항목을 잘 쓰는 문장 구조

한 줄 입력이라 길게 쓸 수 없는 만큼, 문장의 뼈대를 정해 두면 나중에 읽을 때 의미가 분명합니다. Risk는 "원인 때문에 결과가 생길 수 있다"로, Issue는 "무슨 일이 이미 일어났고 어디에 영향이 있다"로, Assumption은 "무엇이 참이라고 가정하며 틀리면 무엇이 달라진다"로, Dependency는 "누가 무엇을 언제까지 준다"로 쓰는 식입니다. 예를 들어 "일정 지연 우려"처럼 막연히 쓰기보다 "결제 대행사 심사가 늦어지면 런칭이 밀릴 수 있다"가 낫습니다. 입력창은 200자까지 받으므로 담당자 표기까지 넣어도 충분합니다.

이 도구에서 쓰는 법

각 칸의 입력창에 한 줄을 쓰고 Enter 또는 "추가"를 누릅니다. 항목 글자를 클릭하면 취소선과 함께 해결됨으로 표시되고 다시 누르면 되돌아갑니다. 칸 제목 옆에는 "해결/전체" 수가 표시되어 어느 칸이 쌓이는지 한눈에 보입니다. "텍스트로 복사"는 네 칸의 내용을 해결 표시와 함께 문자열로 만들어 클립보드에 넣고, "해결된 항목 정리"는 완료 표시가 된 항목만 삭제합니다. 같은 칸에 같은 문장을 중복해서 추가할 수는 없습니다.

정기 점검은 이렇게

로그는 쓰는 것보다 다시 보는 것이 중요합니다. 주 1회 15분만 정해 두고 세 가지를 확인하세요. (1) Dependency 중 약속 기한이 지난 것이 있는가, (2) Assumption 중 확인이 끝나 사실 또는 거짓으로 판명된 것이 있는가, (3) Risk 중 현실화되어 Issue 칸으로 옮겨야 할 것이 있는가. 옮길 때는 기존 줄을 지우고 Issue 칸에 새로 적으면 됩니다.

흔한 실수와 한계

점검 회의 진행 예시

15분 점검을 이렇게 쓰는 방법이 있습니다. 처음 3분은 Dependency를 위에서부터 읽으며 기한이 지난 것을 표시하고, 다음 4분은 Assumption에서 확인이 끝난 것을 해결 표시하거나 Risk 또는 Issue 칸으로 옮깁니다. 이어서 5분 동안 Risk 상위 항목의 대응 담당자가 있는지 묻고, 마지막 3분에 Issue를 읽으며 막힌 것이 있는지 확인합니다. 끝나면 "텍스트로 복사"로 현재 상태를 팀 채널이나 회의록에 남기면 다음 주에 비교할 기준이 생깁니다. 복사 결과는 칸 이름 아래에 체크 표시가 붙은 목록 형태입니다.

이 도구를 쓰기 어려운 경우

여러 사람이 동시에 편집해야 하거나, 항목마다 담당자·기한·점수 열을 필터링해야 하거나, 감사 기록처럼 변경 이력이 필요한 프로젝트라면 이 도구는 맞지 않습니다. 이 도구는 한 사람이 빠르게 머릿속을 비우고 정리하는 용도에 가깝습니다. 입력한 내용은 이 기기의 이 브라우저에만 남으므로, 중요한 로그는 복사해서 별도 문서에 보관하세요.

저장 위치와 보안 주의

코드를 확인한 결과, 입력한 항목은 이 브라우저의 로컬 저장소(localStorage, 키pib-project-raid-log-v1)에만 저장되며 도구 코드가 서버로 전송하지 않습니다. 따라서 다른 기기와 동기화되지 않고, 암호화되지 않으며, 사이트 데이터를 지우거나 시크릿 창을 닫으면 사라질 수 있습니다. 삭제는 항목별 ✕, "해결된 항목 정리", "전체 초기화", 또는 브라우저의 사이트 데이터 삭제로 합니다. 외주 계약 금액, 협력사의 내부 사정, 개인을 특정하는 평가 같은 정보는 회사의 정보보호 지침을 먼저 확인하고 적으세요. 공용 PC에서는 사용하지 않는 것이 안전합니다.

자주 묻는 질문

해결된 항목은 삭제해야 하나요?

꼭 그럴 필요는 없습니다. 완료 표시만 해 두면 프로젝트 종료 후 회고 때 어떤 위험이 실제로 터졌는지 돌아볼 수 있습니다. 화면이 길어졌다면 "해결된 항목 정리"로 지우되, 그 전에 "텍스트로 복사"로 한 번 남겨 두세요.

팀 전체가 함께 실시간으로 편집할 수 있나요?

아니요. 사용 중인 브라우저에만 저장되는 개인용입니다. 회의에서는 한 사람이 화면을 공유하며 입력하고, 회의 후에 복사한 텍스트를 팀 문서에 붙여 넣는 방식을 권합니다.

RAID 로그와 RACI 표는 같은 건가요?

다릅니다. RAID는 위험·가정·이슈·의존성을 모으는 로그이고, 역할 분담을 정리하는 표는 별개입니다. 역할 정의는 RACI 매트릭스 생성기를 참고하세요.

항목이 너무 많아지면 어떻게 하나요?

칸당 열 개를 넘으면 점검이 형식적으로 변합니다. 점수 상위 항목만 남기고 나머지는 "감시 목록"으로 따로 복사해 보관하거나, 해결된 것부터 정리하세요.

Issue와 일반 작업(할 일)은 어떻게 구분하나요?

계획에 있던 작업은 작업 목록에, 계획에 없던 문제나 계획을 방해하는 문제는 Issue에 적습니다. 처리 방법이 한 번의 작업으로 끝나는 문제라도 발생 사실은 Issue로 남겨 두면 재발 방지에 도움이 됩니다.

같은 항목을 Risk와 Issue에 둘 다 적어도 되나요?

같은 칸 안에서는 동일한 문장이 중복 입력되지 않지만, 다른 칸에는 같은 문장을 적을 수 있습니다. 다만 한 사건은 한 칸에만 두는 것이 좋습니다. Risk가 현실화되면 Risk 쪽 줄은 해결 표시나 삭제로 정리하고 Issue 칸에 새로 쓰세요.

Assumption은 언제 해결된 것으로 표시하나요?

사실 여부가 확인된 시점입니다. 사실로 확인됐다면 해결 표시를 하고, 틀린 것으로 드러났다면 영향에 따라 Risk나 Issue 칸에 새로 옮겨 적은 뒤 해결 표시를 하면 이력이 남습니다.

입력한 내용이 사라졌어요. 복구할 수 있나요?

이 브라우저의 저장소에서 사라졌다면 이 도구가 되살릴 방법은 없습니다. 사이트 데이터 삭제, 시크릿 창 종료, 다른 브라우저나 기기 사용이 흔한 원인입니다. 중요한 시점마다 텍스트로 복사해 별도 문서에 보관하는 습관을 권합니다.

RAID의 R과 A는 왜 한 번 더 구분하나요?

Risk는 "일어날 수도 있는 일", Assumption은 "일어났다고 또는 일어날 거라고 믿고 있는 일"입니다. 둘을 섞으면 확인해야 할 전제가 걱정 목록에 묻힙니다. 헷갈리면 확인 행동이 필요한지, 대비 행동이 필요한지로 나누세요.

함께 쓰기 좋은 도구