R&D 리스크 등록부는 한 번 만들어 두는 위험 목록이 아닙니다. 실제로 프로젝트가 흔들리는 순간은 위험을 처음 발견한 날보다 운영회의에서 그 위험을 애매하게 넘긴 날에 더 자주 생깁니다. “기술 위험은 그대로”, “담당자가 확인 예정”, “다음 회의에서 재논의” 같은 문장이 반복되면 등록부는 살아 있는 관리 도구가 아니라 회의록 뒤에 붙은 표가 됩니다. 특히 연구개발 과제는 실험 실패, 시료 지연, 외주 시험 일정, 설계 변경, 인증 해석, 예산 소진 속도처럼 서로 연결된 변수가 많기 때문에 위험 등급, 조치자, 만료일을 회의 때마다 명확히 갱신해야 합니다.

이 글은 R&D 리스크 등록부를 새로 만드는 방법보다 운영회의에서 이미 등록된 위험을 어떻게 검토하고 업데이트할지에 집중합니다. 같은 사이트의 R&D 리스크 등록부와 컨틴전시 체크리스트가 위험 행을 설계하고 비상 조치를 정하는 글이라면, 이 글은 그 행을 매주 또는 격주 회의에서 어떻게 읽고, 무엇을 바꾸고, 누가 언제까지 닫을지 결정하는 절차입니다. ISO 31000, IEC 31010, ICH Q9(R1), NASA 위험관리 핸드북, NIST SP 800-30, 영국 정부 프로젝트 딜리버리 자료는 공통적으로 위험관리를 평가, 처리, 소통, 검토, 기록의 반복 과정으로 봅니다[S1][S2][S3][S5][S6][S7]. 따라서 운영회의의 목표도 “문제 없음”을 확인하는 것이 아니라 현재 판단이 아직 유효한지 검증하는 것입니다.

빠른 결론

R&D 리스크 등록부 운영회의에서는 각 위험 행마다 다섯 가지를 반드시 갱신해야 합니다. 첫째, 위험 등급이 그대로인지 바뀌었는지와 그 근거입니다. 둘째, 위험 소유자와 실제 조치자가 분리되어 있는지입니다. 셋째, due date가 “다음 회의”가 아니라 검증 가능한 날짜인지입니다. 넷째, 조치 후에도 남는 잔여위험이 허용 가능한지입니다. 다섯째, 회의 기록에 변경 전 값, 변경 후 값, 결정자, 근거 자료, 다음 확인일이 남았는지입니다.

R&D 리스크 등록부 운영회의는 위험 목록 점검이 아니라 상태 변경 결정입니다

운영회의에서 가장 먼저 버려야 할 습관은 위험을 순서대로 읽기만 하는 것입니다. 리스크 등록부의 각 행은 아직 발생하지 않았지만 목표, 일정, 비용, 성능, 품질, 규제 판단에 영향을 줄 수 있는 불확실성을 다룹니다. 영국 정부 프로젝트 딜리버리 지침은 위험 등록부에 고유 식별번호, 제기일, 위험 설명, 범주, 위험 소유자, 가능성과 영향 점수, 현재 등급, 목표 등급, 대응 조치, 잔여위험을 유지하라고 설명합니다[S3]. 이 필드들은 표를 예쁘게 만들기 위한 항목이 아니라 회의에서 무엇을 결정해야 하는지 알려주는 질문입니다.

좋은 회의는 각 위험 행을 보고 세 문장으로 끝냅니다. “이 위험은 지난 회의 이후 근거가 바뀌었는가.” “그 변화 때문에 등급, 조치자, 만료일 중 무엇을 바꿔야 하는가.” “바뀐 결정을 누가 어떤 증거로 다음 회의까지 확인할 것인가.” 반대로 나쁜 회의는 위험 행을 보고도 “계속 모니터링”이라는 문장만 남깁니다. 모니터링은 실제 관찰 신호, 책임자, 확인 날짜가 있을 때만 조치입니다. 그렇지 않으면 조치를 하지 않는 선택을 포장한 말이 됩니다.

R&D 운영회의에서는 위험과 이슈도 구분해야 합니다. 위험은 아직 발생하지 않은 불확실성이고, 이슈는 이미 발생해 관리가 필요한 상태입니다. 위험이 실제로 발생했다면 등록부에서 색깔만 올릴 것이 아니라 이슈 관리, 변경관리, CAPA, 시험계획 변경, 예산 영향 검토 중 어디로 넘길지 결정해야 합니다. 프로젝트 딜리버리 지침도 위험이 발생하면 이슈로 관리해야 한다고 구분합니다[S3]. 이 구분이 없으면 같은 행이 몇 달 동안 빨간색으로만 남고 실제 복구 절차는 시작되지 않습니다.

위험 등급 산정은 가능성, 영향, 속도, 잔여위험을 같은 기준으로 봐야 합니다

위험 등급을 “상, 중, 하”로만 표현하면 회의마다 판단이 흔들립니다. ISO 31000은 위험을 식별, 분석, 평가, 처리, 모니터링, 소통하는 구조를 제시하고, IEC 31010은 불확실성 아래에서 의사결정을 돕기 위해 위험평가 기법을 선택하고 적용하는 기준을 제공합니다[S1][S2]. R&D 회의에서는 이 원칙을 단순한 점수표로 바꿔야 합니다. 가능성은 사건이 일어날 확률 또는 관찰 신호의 강도, 영향은 목표 성능이나 일정에 미치는 손상, 속도는 위험이 현실화되면 얼마나 빨리 프로젝트 목표를 흔드는지를 봅니다.

예를 들어 “외주 시험기관 일정 지연”이라는 행이 있다고 가정하겠습니다. 가능성은 시험기관의 확정 회신, 이전 지연 이력, 계약서상 슬롯 보장 여부로 판단할 수 있습니다. 영향은 다음 마일스톤, 시료 보관 조건, 인증 제출 자료, 내부 설계 변경 일정에 미치는 영향을 봅니다. 속도는 시험 시작일이 밀렸을 때 며칠 안에 다른 작업까지 멈추는지를 봅니다. 여기에 현재 대응 후 남는 잔여위험까지 기록해야 합니다. 대응책을 넣었는데도 등급이 그대로라면 조치가 약하거나, 원인이 잘못 잡혔거나, 허용 기준이 너무 느슨한 것입니다.

<table>

<thead>

<tr>

<th>회의 질문</th>

<th>확인할 근거</th>

<th>등록부 갱신 값</th>

</tr>

</thead>

<tbody>

<tr>

<td>가능성이 바뀌었는가</td>

<td>실험 결과, 공급사 회신, 시험기관 일정, 규제 질의 답변</td>

<td>가능성 점수와 변경 사유</td>

</tr>

<tr>

<td>영향이 바뀌었는가</td>

<td>마일스톤, 성능 기준, 예산 버퍼, 제출 자료 의존성</td>

<td>영향 점수와 영향 영역</td>

</tr>

<tr>

<td>속도가 바뀌었는가</td>

<td>위험이 현실화될 때 의사결정까지 남은 시간</td>

<td>즉시 조치, 다음 회의, 월말 검토 중 하나</td>

</tr>

<tr>

<td>잔여위험이 허용 가능한가</td>

<td>대응 후 남는 지연일, 비용, 품질 영향, 재시험 가능성</td>

<td>수용, 추가 조치, 상위 의사결정 요청</td>

</tr>

</tbody>

</table>

위험 등급 산정에서 중요한 것은 정밀한 수학보다 일관성입니다. Comcover의 ISO 31000 기반 설명도 가능성과 영향으로 위험을 분석하고, 조직의 기준에 맞춘 위험 매트릭스를 일관되게 적용해야 한다고 설명합니다[S4]. 따라서 회의 전에는 “상향 기준”과 “하향 기준”을 먼저 고정해야 합니다. 예를 들어 성능 기준 미달이 두 번 연속 발생하면 기술 위험을 한 단계 올리고, 독립 확인 시험에서 기준을 만족하면 한 단계 낮춘다는 식입니다. 이런 기준이 없으면 목소리가 큰 사람이 등급을 정하게 됩니다.

조치자 지정은 위험 소유자와 액션 담당자를 분리해야 추적됩니다

등록부에 이름이 하나만 들어가면 책임이 명확해 보이지만 실제 회의에서는 자주 막힙니다. 위험 소유자는 해당 위험의 판단과 보고를 책임지는 사람입니다. 액션 담당자는 특정 조치를 수행하는 사람입니다. 영국 정부 프로젝트 딜리버리 지침은 위험 소유자가 승인된 대응 조치에 대해 한 명 이상의 액션 담당자를 지정할 수 있다고 설명합니다[S3]. R&D에서는 이 분리가 특히 필요합니다. 기술 리더가 위험 소유자일 수 있지만, 외주 시험기관 일정 확인은 구매 담당자가, 설계 변경 영향 분석은 시스템 엔지니어가, 규제 문의 초안은 RA 담당자가 맡을 수 있습니다.

운영회의에서는 “담당자 누구?”보다 “어떤 역할의 책임인가?”를 먼저 묻는 편이 안전합니다. 위험 소유자는 등급 변경, 잔여위험 수용, 상위 보고 필요 여부를 결정합니다. 액션 담당자는 시험 추가, 공급사 확인, 문서 수정, 데이터 재분석처럼 구체적인 일을 끝냅니다. 승인자는 잔여위험을 수용하거나 예산, 일정, 범위 변경을 허가합니다. 기록 담당자는 회의 결정과 근거 자료 위치를 남깁니다. 네 역할이 한 사람에게 겹칠 수는 있지만, 등록부에는 역할을 분리해 적어야 나중에 지연 원인을 알 수 있습니다.

<table>

<thead>

<tr>

<th>등록부 필드</th>

<th>회의에서 물어볼 질문</th>

<th>비어 있으면 생기는 문제</th>

</tr>

</thead>

<tbody>

<tr>

<td>Risk owner</td>

<td>이 위험의 등급과 잔여위험 판단을 누가 책임지는가</td>

<td>등급 변경이 회의 분위기에 따라 흔들림</td>

</tr>

<tr>

<td>Action owner</td>

<td>다음 due date까지 실제 조치를 끝낼 사람은 누구인가</td>

<td>“검토 중”만 반복되고 작업이 닫히지 않음</td>

</tr>

<tr>

<td>Approver</td>

<td>일정, 비용, 범위 영향이 있을 때 누가 수용하는가</td>

<td>잔여위험 수용이 비공식 결정으로 남음</td>

</tr>

<tr>

<td>Recorder</td>

<td>근거 자료와 회의 결정을 어디에 남기는가</td>

<td>다음 회의에서 같은 설명을 반복함</td>

</tr>

</tbody>

</table>

조치자를 지정할 때는 이름만 쓰지 말고 산출물을 함께 써야 합니다. “김OO 확인”은 부족합니다. “7월 10일까지 시험기관 B의 슬롯 확정 메일을 받아 등록부 R-14에 첨부”처럼 완료 조건이 있어야 합니다. ICH Q9(R1)은 품질 위험관리가 제품 생애주기 전반의 평가, 통제, 소통, 검토 과정이며, 위험 수준에 맞춰 노력과 문서화 수준을 조절해야 한다고 설명합니다[S7]. R&D 운영회의에서도 낮은 위험은 간단한 메일 확인으로 충분할 수 있지만, 높은 위험은 독립 검토, 변경 영향 분석, 승인 기록까지 요구해야 합니다.

due date 추적은 마감일보다 다음 판단일을 설계하는 일입니다

R&D 리스크 등록부에서 due date가 실패하는 이유는 날짜가 너무 늦어서가 아니라 날짜의 의미가 불분명해서입니다. 어떤 due date는 조치 완료일이고, 어떤 due date는 중간 확인일이며, 어떤 due date는 상위 의사결정 요청일입니다. 이 셋을 한 칸에 섞으면 회의에서 “아직 기한 전”이라는 말로 위험이 방치됩니다. 운영회의에서는 due date를 최소한 세 종류로 나누는 것이 좋습니다. 조치 완료일, 근거 제출일, 재평가일입니다.

Comcover 자료는 위험 모니터링과 검토가 주기적일 수도 있고 트리거 이벤트나 상황 변화에 따라 이루어질 수도 있으며, 검토 빈도는 조직과 환경 변화 속도에 맞아야 한다고 설명합니다[S4]. 런던 리스크 등록부처럼 공공 위험 등록부도 마지막 검토일과 다음 검토일을 별도 필드로 두어 위험이 정적으로 남지 않게 합니다[S8]. R&D 과제에서는 이 원칙을 더 촘촘히 적용해야 합니다. 시료 안정성이 2주 안에 떨어지는 위험과 인증기관 해석이 2개월 뒤 필요한 위험은 같은 주기로 검토하면 안 됩니다.

due date는 다음 문장으로 검증할 수 있어야 합니다. “이 날짜가 지나면 무엇을 결정할 수 있는가.” 답이 없으면 날짜가 아닙니다. 예를 들어 “7월 12일”보다 “7월 12일까지 대체 소재 2종의 초기 물성 데이터를 받아 기존 소재 유지 또는 대체 검증 착수 중 하나를 결정”이 훨씬 좋습니다. 일정 위험이라면 due date는 작업 종료일이 아니라 일정 버퍼를 다시 계산하는 날일 수 있습니다. 품질 위험이라면 재시험 여부를 결정하는 날일 수 있습니다. 공급망 위험이라면 2차 공급사 전환 여부를 승인받는 날일 수 있습니다.

due date가 약하다는 신호

  • “다음 회의까지”라고만 쓰여 있고 실제 완료 산출물이 없다.
  • 기한이 지났는데 위험 등급, 잔여위험, 조치 상태가 그대로다.
  • 조치 담당자는 있는데 승인자나 수용 기준이 없다.
  • 중간 확인일과 최종 완료일이 같은 날짜로 적혀 있다.
  • 외부 회신, 시험 결과, 공급사 일정처럼 통제 밖의 조건에 대한 대안 날짜가 없다.

운영회의 기록은 변경 전 값, 변경 후 값, 근거, 결정자를 남겨야 합니다

회의록은 길게 쓸수록 좋은 문서가 아닙니다. 리스크 운영회의 기록은 나중에 “왜 그때 등급을 낮췄는가”, “왜 조치를 그 사람에게 맡겼는가”, “왜 만료일을 연장했는가”를 설명할 수 있으면 됩니다. NASA의 2024 위험관리 핸드북은 위험관리를 프로젝트 생애주기와 일상적 프로그램 기능에 통합하는 관점을 강조합니다[S5]. NIST SP 800-30도 위험평가가 식별된 위험에 대한 적절한 행동 방침을 결정하는 정보를 제공한다고 설명합니다[S6]. 즉 회의 기록은 보고용 문장이 아니라 다음 행동 방침의 근거입니다.

운영회의 기록에는 최소 여섯 칸이 필요합니다. 첫째, 변경 전 상태입니다. 기존 등급, 조치자, due date, 잔여위험을 남깁니다. 둘째, 새 근거입니다. 실험 결과, 공급사 회신, 외부 시험 일정, 변경요청 번호, 검토 메모 같은 자료 위치를 적습니다. 셋째, 변경 후 상태입니다. 위험 등급, 조치자, 만료일, 상태값이 어떻게 바뀌었는지 적습니다. 넷째, 결정자입니다. 위험 소유자와 승인자가 다르면 둘 다 적습니다. 다섯째, 다음 확인 조건입니다. 어떤 증거가 나오면 닫거나 올릴지 적습니다. 여섯째, 관련 문서 링크입니다. 시험계획, 변경영향평가, CAPA, 요구사항 추적표 중 어디와 연결되는지 남깁니다.

예를 들어 “R-08, 배터리 발열 시험 재현성 위험”이라는 행을 보겠습니다. 나쁜 기록은 “추가 시험 진행, 담당 박OO, 다음 주 확인”입니다. 좋은 기록은 “기존 등급 중, 7월 2일 3차 시험에서 동일 조건 편차가 반복되어 가능성 중에서 상으로 변경. 박OO가 7월 9일까지 시험 fixture 고정 조건과 온도 로그를 재분석하고, 이OO가 7월 10일 재시험 필요 여부 승인. 재시험 필요 시 R&D 테스트 픽스처 교정 체크리스트와 연결”입니다. 이 정도 기록이면 다음 회의에서 같은 설명을 반복하지 않아도 됩니다.

위험을 낮출 때는 닫기, 수용, 보류, 이슈 전환을 구분해야 합니다

위험 등급을 올리는 회의는 비교적 쉽습니다. 모두가 불안하기 때문입니다. 더 어려운 것은 위험을 낮추거나 닫는 회의입니다. 위험을 낮추는 순간에는 실제로 근거가 충분한지, 아니면 일정 압박 때문에 색깔만 바꾸는지 확인해야 합니다. 프로젝트 딜리버리 지침은 위험 대응 후 잔여위험을 평가하고, 수용 가능한지 또는 추가 조치가 필요한지 이해해야 한다고 설명합니다[S3]. 따라서 운영회의에서 위험 등급을 낮출 때는 “조치 완료”와 “위험 해소”를 분리해야 합니다.

닫기는 위험 원인이 사라졌거나 위험 발생 가능 기간이 지났고, 더 이상 관리할 필요가 없을 때 사용합니다. 수용은 위험이 남아 있지만 정해진 허용 기준 안에 있고, 승인자가 그 잔여위험을 받아들였을 때 사용합니다. 보류는 필요한 근거가 아직 없지만 다음 판단일까지 기다리는 것이 합리적일 때 사용합니다. 이슈 전환은 위험이 현실화되어 별도의 문제 해결 흐름으로 넘길 때 사용합니다. 이 네 상태를 구분하지 않으면 모든 행이 “완료”로 보이다가 나중에 같은 위험이 다시 나타납니다.

R&D 품질 문서와 연결되는 위험은 더 신중해야 합니다. ICH Q10은 모니터링, CAPA, 변경관리, 경영검토 같은 품질시스템 요소를 제품 생애주기 단계에 맞게 적용한다고 설명합니다[S7]. 모든 R&D 과제가 의약품 품질시스템 범위에 들어간다는 뜻은 아닙니다. 다만 품질, 안전성, 규제 제출, 검증 자료에 영향을 주는 위험이라면 단순히 등록부에서 닫지 말고 변경영향평가나 CAPA 성격의 문서로 이동해야 할 수 있습니다. 이 경계는 R&D 변경 영향 평가 체크리스트와 함께 보아야 합니다.

운영회의에서 쪼개야 하는 위험과 합쳐야 하는 위험을 구분합니다

리스크 등록부가 커지면 회의 시간이 길어지고, 반대로 너무 압축하면 실제 위험이 묻힙니다. 운영회의의 역할은 위험 행 수를 줄이는 것이 아니라 의사결정 단위를 맞추는 것입니다. 한 위험 행에 기술, 일정, 공급사, 규제 해석, 예산 영향이 모두 들어 있으면 조치자를 정할 수 없습니다. 반대로 동일한 원인에서 나온 작은 위험을 다섯 행으로 나누면 회의가 관리되지 않습니다. 영국 정부 프로젝트 딜리버리 지침은 위험을 집계해서 보면서 소유자 재배정, 분할, 통합이 필요할 수 있다고 설명합니다[S3].

쪼개야 하는 위험은 조치자와 만료일이 서로 다른 경우입니다. 예를 들어 “시료 수급 지연으로 시험 일정과 인증 제출이 모두 위험”이라는 행은 공급사 확보 위험과 인증 제출 일정 위험으로 나누는 편이 낫습니다. 공급사 위험의 액션 담당자는 구매 또는 협력사 담당자이고, 인증 제출 일정 위험의 액션 담당자는 RA 또는 PM일 수 있기 때문입니다. 합쳐야 하는 위험은 원인, 조치자, due date, 판단 근거가 사실상 같은 경우입니다. 같은 시험 실패를 성능 위험, 일정 위험, 예산 위험으로 세 행에 반복해 적으면 색깔만 많아지고 결정은 흐려집니다.

분할과 통합을 판단할 때는 “다음 회의에서 다른 결정을 할 가능성이 있는가”를 묻습니다. 답이 예라면 분리합니다. 답이 아니오라면 통합합니다. 이 기준은 R&D 문서 전체에도 유용합니다. 요구사항 자체가 불명확해서 위험이 생긴 경우에는 R&D 사용자 요구사항 명세서 체크리스트로 돌아가야 합니다. 요구사항과 시험, 증거의 연결이 약해서 위험이 생긴 경우에는 R&D 증거 추적 매트릭스 체크리스트가 다음 작업입니다. 데이터 보관과 원자료 무결성이 문제라면 R&D 데이터 관리 계획 체크리스트로 분리해야 합니다.

R&D 리스크 등록부 운영회의 체크리스트는 30분 안에 끝나야 합니다

운영회의가 길어지는 이유는 논의가 많아서가 아니라 질문 순서가 없기 때문입니다. 30분 회의를 기준으로 보면 처음 5분은 새 근거 확인, 다음 10분은 등급 변경 행 검토, 다음 10분은 조치자와 due date 재지정, 마지막 5분은 회의 기록 확인에 써야 합니다. 모든 위험을 매번 같은 깊이로 보지 않아도 됩니다. 등급이 높거나 due date가 지났거나 외부 조건이 바뀐 행을 먼저 보고, 낮은 위험은 변경 신호가 없을 때 짧게 유지합니다.

<table>

<thead>

<tr>

<th>시간</th>

<th>회의 질문</th>

<th>결정 산출물</th>

</tr>

</thead>

<tbody>

<tr>

<td>0~5분</td>

<td>지난 회의 이후 새 근거가 들어온 위험은 무엇인가</td>

<td>검토 대상 행 목록</td>

</tr>

<tr>

<td>5~15분</td>

<td>위험 등급을 올리거나 낮출 근거가 있는가</td>

<td>현재 등급, 목표 등급, 잔여위험</td>

</tr>

<tr>

<td>15~25분</td>

<td>조치자와 due date가 실제 산출물 기준으로 적혔는가</td>

<td>risk owner, action owner, 완료 조건, 다음 확인일</td>

</tr>

<tr>

<td>25~30분</td>

<td>회의 기록만 봐도 다음 사람이 판단을 이어갈 수 있는가</td>

<td>변경 전후 값, 결정자, 근거 링크, 다음 회의 안건</td>

</tr>

</tbody>

</table>

마지막 5분에는 네 가지 금지 문장을 지워야 합니다. “계속 확인”은 무엇을 확인할지 쓰기 전까지 금지입니다. “담당자 검토”는 산출물과 날짜가 붙기 전까지 금지입니다. “위험 감소”는 잔여위험과 근거가 없으면 금지입니다. “완료”는 닫기, 수용, 보류, 이슈 전환 중 어떤 상태인지 정하기 전까지 금지입니다. 이 네 문장을 지우는 것만으로도 등록부의 품질이 크게 올라갑니다.

R&D 리스크 등록부 운영회의의 최종 목적은 위험을 없애는 것이 아닙니다. 위험이 아직 남아 있는지, 남아 있다면 누가 어떤 날짜까지 무엇을 해서 다음 판단을 가능하게 만들지 합의하는 것입니다. 위험 등급은 우선순위를 정하고, 조치자는 실행을 만들고, due date는 다음 판단 시점을 만들고, 회의 기록은 판단의 연속성을 만듭니다. 이 네 가지가 연결되어 있으면 등록부는 보고서 부록이 아니라 프로젝트를 살리는 의사결정 장부가 됩니다.

참고 출처

  • [S1] ISO 31000:2018 Risk management - Guidelines, International Organization for Standardization.
  • [S2] IEC 31010:2019 Risk management - Risk assessment techniques, International Organization for Standardization.
  • [S3] Chapter 20: Risk management, Government Project Delivery, UK Government.
  • [S4] An Overview of the Risk Management Process, Comcover, Australian Government Department of Finance.
  • [S5] NASA Risk Management Handbook: Version 2.0, Part 1, NASA Technical Reports Server.
  • [S6] NIST SP 800-30 Rev. 1, Guide for Conducting Risk Assessments, NIST CSRC.
  • [S7] ICH Q9(R1) Quality Risk Management and ICH Q10 Pharmaceutical Quality System, International Council for Harmonisation.
  • [S8] London Risk Register v14 Public Version, London Resilience.