8월 중순에 OCR 정확도 테스트 결과가 들어옵니다. 영수증 100장 기준 78%인데, 차터에 적힌 목표는 90%였습니다. 동시에 보안팀 검토는 한 달째 일정이 잡히지 않고 있고, 어제는 재무이사가 법인카드 명세서 자동 매칭도 들어가냐고 메일을 보냈습니다. 그 기능은 범위 외였습니다. 세 가지가 동시에 흔들립니다. 무엇이 아직 일어나지 않은 일이고, 무엇이 이미 일어난 일이고, 무엇이 원래 약속을 바꾸는 일인지 구분해야 하는 순간입니다.
이 시점의 질문
통제 단계의 문서들은 세 가지 다른 종류의 일에 대응합니다.
- 아직 일어나지 않았지만 일어날 수 있는 일: 리스크
- 이미 일어난 일: 이슈
- 약속을 바꾸자는 요청: 변경
세 가지를 같은 문서에 섞으면 혼란이 시작됩니다. 발생 여부가 다르고, 대응 방식이 다르고, 책임 라인이 다르기 때문입니다.
리스크 레지스터(Risk Register)
리스크(risk) 는 아직 일어나지 않은 일입니다. 일어나면 프로젝트에 대개 부정적인, 드물게는 긍정적인 영향을 미치는 사건입니다. 이런 사건을 예측 가능한 형태로 미리 적어둡니다. 리스크 레지스터(Risk Register) 가 그 목록입니다.
리스크 레지스터의 기본 항목은 다음과 같습니다.
- 리스크 ID와 짧은 이름
- 설명: 어떤 사건이 일어날 수 있는지 적습니다
- 확률(1~5점)
- 영향(1~5점)
- 점수(확률 × 영향)
- 대응 전략: 회피·전가·완화·수용 중 하나입니다
- 대응 계획: 구체적인 조치를 적습니다
- 비상 계획: 만약 일어나면 무엇을 할지 적습니다
- 담당자: 이 리스크를 모니터링하는 사람입니다
확률과 영향을 둘 다 5단계로 잡고 곱하면 1점에서 25점이 나옵니다. 10점 이상이면 빨강, 5점에서 9점이면 노랑, 4점 이하면 초록으로 표시하는 관례가 있습니다.
Receipt의 리스크 레지스터 일부는 다음과 같습니다.
**R-01. OCR 정확도 미달**
- 설명: 외부 OCR API의 한글 영수증 인식률이 목표(90%)에 미달할 수 있다
- 확률: 4 (높음) / 영향: 5 (치명) / 점수: 20
- 전략: 완화 (Mitigate)
- 대응 계획:
- 5월 중 OCR 후보 3종 비교 테스트
- 신뢰도 낮은 영역은 사용자 확인 UI로 보완
- 사내 영수증 1만 장으로 자체 학습 데이터 구축
- 비상 계획: 정확도가 80% 미만이면 자동 추출 대신 수동 입력 보조 모드로 전환
- 담당자: 백엔드 리드 A씨
**R-02. 보안팀 검토 지연**
- 설명: IT 보안팀의 검토 일정이 잡히지 않아 베타 일정이 밀릴 수 있다
- 확률: 4 / 영향: 4 / 점수: 16
- 전략: 완화
- 대응 계획:
- 6월 첫 주에 보안팀과 사전 미팅 확정
- 검토 체크리스트를 사전 공유해 검토 시간 단축
- 비상 계획: 보안팀 검토가 9월 1일까지 완료되지 않으면 사내 1차 베타를 기존 결재 시스템 우회 없이 진행
- 담당자: PM리스크 레지스터에서 가장 자주 빠뜨리는 칸은 담당자와 비상 계획입니다. 담당자가 없으면 리스크는 매주 점수만 보고되고 아무도 손쓰지 않습니다. 비상 계획이 없으면 리스크가 실제로 일어났을 때 그때부터 회의가 시작됩니다.
리스크 대응 전략은 네 가지입니다.
- 회피(Avoid): 그 일이 일어날 만한 원인을 제거합니다. 외부 OCR을 쓰지 않고 내부에서 개발하는 것이 그 예입니다.
- 전가(Transfer): 다른 주체에게 책임을 이전합니다. 보험 가입이나 SLA 계약이 그 예입니다.
- 완화(Mitigate): 확률 또는 영향을 줄입니다. 가장 흔한 선택지입니다.
- 수용(Accept): 일어나도 감당합니다. 단, 비상 계획은 있어야 합니다.
신입 PM이 자주 하는 실수는 모든 리스크에 완화를 적는 것입니다. 어떤 리스크는 수용이 옳은 선택입니다. 외부 OCR이 1시간 다운되는 것은 일어나도 큰일이 아니므로 수용해도 됩니다. 그 리스크를 완화하려고 별도 인프라를 구축하면 비용이 영향보다 큽니다.
개발자·디자이너 시각
개발자는 리스크 레지스터에서 기술 부채와 외부 의존성을 봅니다. 외부 API 장애, 라이브러리 버전 업그레이드, DB 마이그레이션 같은 기술적 리스크가 명시적으로 적혀 있으면, 개발자는 그 일이 공식 작업으로 인정받았다고 느낍니다. 이 항목이 빠지면 개발자는 혼자 그 리스크와 싸우다 지칩니다.
디자이너는 사용자 수용성 리스크가 있는지 봅니다. 사용자 학습곡선, 기존 흐름과의 단절, 접근성 미비 같은 항목이 적혀 있어야 디자인 검증 시간을 정당하게 확보할 수 있습니다.
이슈 로그(Issue Log)
이슈(issue) 는 이미 일어난 일입니다. 리스크가 발생 확률을 다룬다면 이슈는 발생 사실을 다룹니다. 둘은 같은 사건이 시간 축에서 다른 위치에 있는 모습이고, 리스크가 발생하면 이슈가 됩니다. 이슈 로그(Issue Log) 는 그 기록입니다.
이슈 로그의 기본 항목은 다음과 같습니다.
- 이슈 ID
- 발견일과 발견자
- 설명: 지금 정확히 무엇이 안 되고 있는지 적습니다
- 심각도(High / Medium / Low)
- 우선순위
- 현재 상태(Open / In Progress / Resolved / Closed)
- 담당자
- 조치 내역
- 해결일
이슈 로그에서 가장 중요한 칸은 심각도와 상태입니다. 둘은 계속 업데이트되어야 매주 이슈 리뷰가 가능합니다. Open 상태로 3주째 머무는 항목이 쌓여 있으면 그 로그는 곧 아무도 열어보지 않게 됩니다.
이슈가 발견되면 다음 흐름을 거칩니다.
- Open: 누군가 발견해 설명만 적어 둔 상태입니다
- Triaged: PM 또는 리드가 심각도와 담당자를 배정합니다
- In Progress: 담당자가 조치 중이고, 매일 짧은 코멘트를 남깁니다
- Resolved: 조치가 끝나 발견자의 검증을 기다립니다
- Closed: 검증을 통과했고, 다시 일어나지 않도록 학습을 기록합니다
8월의 OCR 정확도 78% 사건은 이렇게 적힙니다.
**I-08. OCR 정확도 목표 미달**
- 발견: 2026-08-14 (백엔드 A씨, OCR 통합 테스트 중)
- 설명: 영수증 100장 인식 테스트 결과 정확도 78% (목표 90%)
- 심각도: High (베타 일정 영향)
- 상태: In Progress
- 담당자: A씨 + PM
- 조치 내역:
- 08-14: 인식 실패 영수증 22장 분석 → 12장이 흐릿한 사진
- 08-15: 사용자 가이드에 '명확한 사진' 안내 추가 제안
- 08-18: API 후처리 룰 추가 (금액·날짜 정규식 보강)
- 관련 리스크: R-01리스크와 이슈는 서로 연결해 두어야 합니다. R-01이 I-08로 현실화되었다는 정보가 다음 프로젝트의 리스크 식별 정확도를 높입니다.
개발자·디자이너 시각
개발자는 이슈 로그에서 Open 상태로 오래 머무는 이슈를 신경 씁니다. 자기 이름이 담당자로 적힌 이슈가 일주일째 Open이면 자기가 못 끝낸다는 신호이고, 팀에 도움을 요청할 시점입니다. PM이 이 상태를 모니터링해 주면 개발자가 혼자 고립되지 않습니다.
디자이너는 디자인이 원인으로 적힌 이슈가 어떻게 처리되는지를 봅니다. 좋은 PM은 디자인 이슈를 디자이너 책임으로 적지 않고 공동 조사로 적습니다. 화면이 어렵다는 이슈는 보통 화면 한 장의 문제가 아니라 흐름 전체의 문제이기 때문입니다.
변경 관리 대장(Change Log)
변경(change) 은 원래 약속을 바꾸자는 요청입니다. 리스크나 이슈와 달리 변경은 합의 자체를 바꾸는 일이고, 새 기능을 추가하자, 일정을 늦추자, 예산을 더 쓰자, 범위에서 빼자는 요청들이 여기 속합니다. 변경 관리 대장(Change Log) 이 그 기록입니다.
모든 변경은 차터·PRD·일정에 영향을 줍니다. 작은 변경 하나가 누적되면 프로젝트는 처음 약속과 다른 곳에 도착합니다. 이 누적을 스코프 크리프(Scope Creep) 라고 부릅니다.
변경 관리 대장의 기본 항목은 다음과 같습니다.
- 변경 ID
- 요청일과 요청자
- 변경 내용: 무엇을 어떻게 바꾸는지 적습니다
- 사유
- 영향 분석: 일정·예산·자원·품질에 미치는 영향을 적습니다
- 의사결정(승인·반려·보류)
- 결정자와 결정일
- 반영된 문서: 차터, PRD, 일정 등입니다
**CR-03. 법인카드 명세서 자동 매칭 추가**
- 요청: 2026-08-12, 재무이사
- 내용: 사내 법인카드 명세서 CSV 업로드 후 영수증과 자동 매칭하는 기능 추가
- 사유: 재무팀 수동 대조 시간이 영수증보다 카드 명세서 쪽이 더 크다는 베타 사용자 피드백
- 영향 분석:
- 일정: +3주 (정식 출시 11.30 → 12.20)
- 예산: +1,500만원 (개발자 추가 투입)
- 범위: 차터의 '범위 외' 항목이었음
- 기술: 카드사 CSV 형식 표준화 필요
- 결정: **승인** (단, 정식 출시일 12.20로 변경)
- 결정자: 재무이사 + PM
- 결정일: 2026-08-20
- 반영 문서: 차터 v1.2, WBS 2.0 하위에 2.4 신설변경 요청을 받았을 때 신입 PM이 가장 흔하게 하는 실수는 즉답입니다. “네, 할 수 있어요” 또는 “안 됩니다”를 그 자리에서 답하면 둘 다 문제입니다. 변경에는 영향 분석이 필요합니다. 영향 분석은 한 시간에 끝나는 일이 아닙니다. 신입 PM은 “검토하고 사흘 안에 답 드리겠습니다”라고 답할 줄 알아야 합니다.
개발자·디자이너 시각
개발자는 변경 관리 대장에서 영향 분석에 본인 의견이 들어갔는지 봅니다. PM이 개발자를 거치지 않고 일정 영향을 추정하면 그 추정은 거의 항상 낙관적입니다. 변경 요청이 들어오면 PM은 영향 분석 단계에서 해당 개발자와 디자이너의 의견을 반드시 듣고, 그 결과를 변경 대장에 적습니다.
디자이너는 디자인 재작업이 영향 분석에 포함되었는지 봅니다. 기능 하나를 추가하면 보통 화면 두세 개가 함께 바뀝니다. PM이 개발 3주만 추정하고 디자인 1주를 빼먹으면 디자이너는 휴일을 잃습니다.
세 문서는 흔들림의 종류에 따라 갈립니다.
| 문서 | 다루는 것 | 시점 | 결정하는 사람 |
|---|---|---|---|
| 리스크 레지스터 | 아직 일어나지 않은 일 | 일어나기 전 | 리스크 담당자 |
| 이슈 로그 | 이미 일어난 일 | 일어난 뒤 | 담당자와 PM |
| 변경 관리 대장 | 약속을 바꾸자는 요청 | 요청이 들어온 시점 | 스폰서 |
통제는 막는 것이 아니라 기록하는 일입니다
PMBOK은 통제 활동을 감시 및 통제 프로세스 그룹(Monitoring and Controlling Process Group)으로 묶습니다. 이름이 무거워서 모든 변화를 막아야 하는 PM의 이미지를 줄 수 있지만, 실제로는 반대입니다.
좋은 PM은 변화를 막는 사람이 아니라 변화를 기록하고 수월히 처리해내는 사람입니다. 막는 권한은 PM에게 없습니다. 변경을 결정하는 사람은 스폰서이고, PM의 일은 결정에 필요한 정보를 제공하는 것입니다.
리스크·이슈·변경 세 문서가 함께 살아 있으면 프로젝트는 흔들려도 표류하지 않습니다. 흔들리는 것이 보이고, 기록되고, 결정되는 것이 중요합니다.
참고 자료
- Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition. PMI.
- ISO 31000:2018. Risk management — Guidelines.
- Hillson, D. (2009). Managing Risk in Projects. Gower Publishing.
다음 편 예고
리스크와 이슈는 흔들림을 다룹니다. 그런데 흔들림이 없는 평소에도 지금 어디까지 왔는지는 보여야 합니다. 상태 보고서, 번다운, 대시보드, 회의록이 같은 그림을 모두에게 보이게 하는 방법을 따라갑니다.