김희준
RAID 로그는 위험, 가정, 이슈, 의존성을 구분해 기록하는 문서입니다. 제품 기획을 위한 공유 작업 공간에 정리하면 무엇이 달라졌는지, 누가 다음 대응을 맡는지, 언제 다시 확인할지를 계획과 함께 검토할 수 있습니다.
발생 가능성과 영향도를 평가할 때는 리스크 매트릭스 가이드를 참고하고, RAID 보드에서는 그 결과를 가정 검증과 다른 팀의 작업에 연결하세요. 아직 확인하지 않은 가정과 이미 발생한 문제를 모두 같은 위험으로 기록하지 않는 것이 핵심입니다.
네 가지 RAID 영역 정의하기
위험은 앞으로 일어날 수 있는 사건, 가정은 계획을 세울 때 사실이라고 전제하는 조건, 이슈는 이미 발생한 문제입니다. 의존성은 작업을 진행하는 데 필요한 다른 작업이나 조건을 뜻합니다. 새로운 근거가 생기면 항목의 분류도 다시 검토합니다.
| 영역 | 예시 | 먼저 확인할 질문 |
|---|---|---|
| 위험 | 보안 검토가 늦어져 후보 버전의 출시가 지연될 수 있다. | 발생 가능성이나 영향을 줄일 대응은 무엇인가? |
| 가정 | 현재 내보내기 형식으로 파일럿 업무를 처리할 수 있다고 본다. | 어떤 샘플을 누구에게 확인받아야 하는가? |
| 이슈 | 테스트 계정 두 개가 새 보드에 접속하지 못한다. | 누가 수정을 조정하고, 무엇을 확인하면 해결된 것으로 볼 것인가? |
| 의존성 | 다른 팀에서 API 스키마를 제공해야 한다. | 무엇을, 누구에게서, 언제까지 받아야 하는가? |
카드 형식 통일하기
카드마다 ID, 짧은 설명, 근거, 담당자, 현재 상태, 다음 대응, 재검토일을 기록합니다. 담당자는 다음 단계를 조정할 사람이며, 모든 작업을 혼자 해결할 사람이라는 뜻은 아닙니다.
아래는 고객 5곳이 시험 사용하는 보고서 포털을 가정한 예시입니다. “내보내기가 막힘”이라고만 쓰면 무엇을 고칠지 알기 어렵습니다. “파일럿에 CSV가 필요하지만 내보낸 파일에 열 이름이 없다”라고 쓰면 확인할 파일과 수정 범위가 분명해집니다.
| 항목 | 기록 내용 |
|---|---|
| ID와 설명 | I2: 내보낸 CSV에 열 이름이 없다. |
| 근거 | 테스트에서 받은 CSV 샘플과 필요한 열 이름을 명시한 스키마. |
| 담당자 | 프리야가 내보내기 수정을 조정한다. |
| 현재 상태 | 미해결. 수정한 샘플은 아직 검증하지 않았다. |
| 다음 대응 | 열 이름을 포함한 CSV를 생성하고 플랫폼 팀의 스키마와 대조한다. |
| 재검토 시점 | 수정 샘플을 받으면 확인한다. 고객에게 전달하기 전에 담당자와 구체적인 확인 기한을 정한다. |
계획과 연결하기
영향을 받는 마일스톤이나 결정 옆에 카드를 배치하고, 직접적인 관계만 연결선으로 표시합니다. “이 스키마로 검증”처럼 선의 의미를 짧게 적으면 다른 담당자도 관계를 이해할 수 있습니다.
그림의 A1은 “CSV로 파일럿 업무를 처리할 수 있다”는 가정입니다. I2에서 열 이름 누락을 발견했다고 해서 CSV 형식 자체가 부적절하다는 결론이 나오지는 않습니다. A1을 검증 중으로 두고, I2를 수정한 샘플을 고객과 확인합니다. D2는 플랫폼 팀의 스키마 제공에 관한 의존성입니다. 파일을 받는 데서 끝내지 않고 샘플을 대조한 뒤 인수 여부를 기록합니다.
검토가 5월 18일을 넘길 가능성은 아직 발생하지 않은 위험으로 남겨 둡니다. 검토 일정을 미리 확보하고 일정 확정 여부를 확인하세요. 실제로 기한을 넘겼다면 원래 위험 ID와의 연결을 유지하면서 발생한 지연과 영향을 이슈로 기록합니다.
RAID 리뷰에서 다음 대응 정하기
- 프로젝트 목표와 이번 검토 기간을 확인합니다.
- 새 이슈부터 살펴보고 즉시 조정이 필요한 항목을 고릅니다.
- 기한이 가깝거나 이미 지난 의존성을 확인합니다.
- 새 근거가 가정을 뒷받침하는지, 반박하는지 검토합니다.
- 각 위험의 대응과 다음 확인 조건을 정합니다.
- 담당자, 재검토일, 아직 결정하지 못한 내용을 확인합니다.
이 예시의 다음 리뷰에서는 I2의 수정 샘플, D2의 스키마 대조 결과, A1에 대한 고객의 확인 결과를 봅니다. 수정 작업을 끝냈다는 보고만으로 세 항목을 모두 완료 처리하지 마세요.
Boardmix에서는 메모와 텍스트에 현재 기록을 남기고, 도형과 연결선으로 관계를 표시할 수 있습니다. 특정 카드에 대한 질문은 댓글로 남기고, 확인된 결과는 카드 본문에 반영하세요. 상태와 대응 방향은 팀이 판단해 기록합니다.
리뷰 사이에도 로그를 유용하게 유지하기
해결한 카드는 근거와 해결 이유를 남겨 보관합니다. 같은 항목이 계속 남아 있다면 “확인 예정”을 반복하지 말고 확인할 자료, 담당자, 기한을 구체화하세요. 가정이 틀린 것으로 드러났을 때도 원래 ID와의 연결을 남기면 계획을 바꾼 이유를 추적할 수 있습니다.
Boardmix 보드를 열고 네 영역과 카드 항목을 배치한 뒤, 각 영역에 실제 프로젝트 항목을 하나씩 적어 보세요. 영역별 정의도 보드에 남겨 두면 새로 참여한 팀원이 같은 기준으로 항목을 추가할 수 있습니다.
