WBS 회의실의 화이트보드에 작업이 빼곡합니다. 누군가 “이 OCR API 통합, 누가 해요?”라고 묻자 잠시 침묵이 흐르고, 다른 누군가가 “백엔드팀이요”라고 답합니다. “거기 누구요?”라는 물음에 다시 침묵이 흐릅니다. 작업과 사람이 만나야 비로소 일이 됩니다. 이번 편의 문서들은 그 만남을 기록합니다.
이 시점의 질문
분담 단계의 문서들은 세 가지 질문에 답해야 합니다.
- 각 작업에 누가 어떤 방식으로 관여하는가
- 그 사람들에게 시간이 있는가
- 그 결과를 누구에게 어떻게 알릴 것인가
세 질문은 다른 듯 이어집니다. 책임이 정해져야 시간이 잡히고, 시간이 잡혀야 일정이 살아 있고, 일정이 살아 있어야 보고할 내용이 생깁니다.
RACI 매트릭스
RACI 매트릭스(RACI Matrix) 는 누가 어떤 방식으로 관여하는지를 표 한 장으로 답합니다. 네 글자는 네 가지 관여 방식입니다.
- R(Responsible): 실제로 손을 움직여 일하는 사람입니다
- A(Accountable): 결과에 책임지는 사람이고, 잘못되면 책임을 지는 사람입니다
- C(Consulted): 일이 시작되기 전에 의견을 묻는 사람입니다(양방향)
- I(Informed): 일이 끝난 뒤 결과를 알리는 사람입니다(단방향)
가로축에 사람(또는 역할), 세로축에 작업을 두고 칸을 채웁니다.
RACI의 가장 중요한 규칙은 A는 한 명, 한 칸뿐이라는 것입니다. R은 함께 일하는 사람들이라 여럿일 수 있어도, A는 반드시 한 명이어야 합니다. 책임은 분산되면 사라져버리기 때문에, 두 사람이 같이 책임지면 결국 둘 다 안 합니다.
흔한 함정이 몇 가지 있습니다.
- 모든 칸이 R: 한 작업에 R이 너무 많으면 그 작업은 너무 큰 것입니다. 쪼개야 합니다.
- A가 빠진 줄: 책임자가 없으면 그 작업은 자동으로 PM에게 떨어집니다. PM이 30개 작업의 A를 다 가져가면 PM은 쓰러집니다.
- C와 I가 같음: 의견을 묻는 것과 알리는 것은 다릅니다. C는 일이 시작되기 전이고 I는 끝난 뒤라서, 시점이 다르면 영향도 다릅니다.
Receipt에서 OCR API 통합 행을 풀어 쓰면 이렇게 됩니다.
**활동: OCR API 통합 (작업 패키지 2.1)**
- R: 백엔드 개발자 (실제 통합 작업)
- A: 백엔드 팀장 (책임자, 한 명)
- C: 보안 검토 담당 (IT 운영), 데이터 거버넌스
- I: PM, 프론트엔드 개발자C에 보안과 거버넌스가 들어간 것이 중요합니다. OCR이 외부 API라면 데이터가 외부로 나가므로, 작업 시작 전에 보안 의견을 받아야 끝난 뒤 보안팀이 “이거 왜 우리한테 안 물어봤어요?”라고 묻지 않습니다.
개발자·디자이너 시각
개발자가 RACI에서 가장 먼저 보는 칸은 자기가 A인 줄입니다. 책임자로 적힌 작업은 잘못되면 회의실에서 자기 이름이 불립니다. 그래서 개발자는 RACI 초안을 받으면 자기 줄의 A 칸을 가장 신경 써서 확인합니다. “이거 정말 제가 책임지는 거 맞아요?”라는 질문이 나오면 RACI가 살아 있는 것이고, 아무 말 없이 통과되면 그 RACI는 잘못되었을 가능성이 높습니다.
디자이너는 디자이너 칸이 C 위주인지를 봅니다. 좋은 RACI에서는 디자이너가 화면 관련 작업에 R 또는 A로 들어가 있습니다. 컨설팅만 하는 RACI는 디자이너를 외부인 취급하는 것이고, 그 결과 디자이너의 결정이 늦게 반영됩니다.
리소스 플랜(Resource Plan)
RACI가 누가를 정한다면 리소스 플랜(Resource Plan) 은 얼마나를 정합니다. 사람의 시간은 무한하지 않고, 한 프로젝트에만 100% 투입되는 사람은 잘 없습니다. 보통은 두세 개 프로젝트에 부분 투입됩니다.
리소스 플랜의 기본 단위는 할당률(allocation) 입니다. 한 사람이 한 프로젝트에 자기 시간의 몇 퍼센트를 쓸 수 있는가를 적습니다. 예시는 다음과 같습니다.
## Receipt 리소스 플랜 (6~11월)
| 역할 | 담당자 | 할당률 | 비고 |
| --- | --- | --- | --- |
| PM | 파이 | 80% | 다른 사내 도구 PM 겸직 20% |
| 백엔드 (리드) | A씨 | 100% | 6~9월 OCR 집중 |
| 백엔드 | B씨 | 60% | 결재 시스템 유지보수 40% 병행 |
| 프론트엔드 | C씨 | 80% | |
| 디자이너 | D씨 | 40% | 회사 디자인 시스템 작업 60% 병행 |
| QA | E씨 | 50% | 8월부터 100%로 증가 |
| 보안 검토 | F씨 | 5% | 마일스톤 단위 검토 |모든 사람이 100% 가용하다고 가정해서 짠 일정은 현실적으로 가능하지 않습니다. 또 디자이너가 40%인데 한 스프린트에 디자인 3건이 들어가 있으면, 그 스프린트의 디자인은 일정 내에 끝나지 않습니다.
리소스 플랜은 보통 월 단위 또는 주 단위로 합니다. 월 단위는 큰 그림용이고, 주 단위는 실행용입니다. Receipt처럼 6개월짜리는 월 단위로 잡고, 가장 바쁠 시기인 8월과 9월에만 주 단위로 자세히 합니다.
개발자·디자이너 시각
개발자는 리소스 플랜에서 시니어의 할당률을 봅니다. 시니어 한 명이 30% 할당이면 코드 리뷰 정도만 할 수 있고 직접 개발은 어렵습니다. PM이 시니어에게 R을 잔뜩 배정해 놓고 할당률은 30%로 잡았다면 그 RACI는 망할 운명이 됩니다.
디자이너는 디자인 작업이 시간 축의 어디에 몰려 있는지를 봅니다. 디자이너가 50%라도 그 50%가 프로젝트 초반에 몰려 있는지 끝까지 균등한지는 다른 이야기입니다. 디자이너는 초반에 화면을 다 그리고 나면 후반에는 검토와 미세 조정만 하므로, 디자이너의 할당률은 시간에 따른 곡선으로 그리는 것이 낫습니다.
커뮤니케이션 플랜(Communication Plan)
RACI와 리소스 플랜이 내부를 정리한다면 커뮤니케이션 플랜(Communication Plan) 은 외부를 정리합니다. 누구에게 무엇을 언제 어떤 채널로 알릴 것인지를 정합니다.
이 문서의 뼈대는 ep.01 왜 시작하는가의 이해관계자 매트릭스에서 가져옵니다. 매트릭스의 마지막 칸인 커뮤니케이션 빈도가 이 문서로 발전합니다.
커뮤니케이션 플랜에는 위계가 있어야 합니다. 모두에게 같은 정보를 같은 빈도로 보내면 안 됩니다. 스폰서가 받아야 할 정보와 일반 사용자가 받아야 할 정보는 다릅니다. 다음 원칙이 도움이 됩니다.
- 상위로 갈수록 짧고 적게: 스폰서에게는 한 페이지 격주 리포트로 충분합니다. 매일 보내면 읽지 않습니다.
- 사용자에게는 변화가 닿는 시점에만: 일반 사원에게는 베타 시작, 정식 출시, 기능 추가처럼 변화가 있는 시점에만 알립니다. 진행 중에는 알리지 않는 편이 낫습니다.
- 게이트키퍼는 임계점에서만: 보안팀장 같은 게이트키퍼는 평소에는 멀리 두고, 보안 검토가 필요한 시점에만 정식으로 부릅니다.
Receipt의 커뮤니케이션 플랜 일부는 이렇게 적힙니다.
## 청중: 재무이사 (스폰서)
- 콘텐츠: 진척, 리스크, 의사결정 요청 사항
- 빈도: 격주
- 채널: 1:1 미팅 + 한 페이지 요약 메일
- 책임자: PM
- 형식: PPT 1슬라이드, 빨강·노랑·초록 상태 표시
## 청중: 일반 사원
- 콘텐츠: 베타 모집, 출시 안내, 사용법
- 빈도: 변화 시점 (3회 예상)
- 채널: 사내 공지 + 슬랙 #general
- 책임자: PM + 인사팀 협조
- 형식: 짧은 공지 글 + 1분 영상이 문서를 만들다 보면 청중마다 콘텐츠도 형식도 달라야 한다는 것이 드러납니다.
세 문서가 각각 정하는 것과 그 문서를 살아 있게 만드는 조건은 이렇습니다.
| 문서 | 정하는 것 | 누가 확인해야 효력이 생기는가 | 갱신 시점 |
|---|---|---|---|
| RACI 매트릭스 | 작업마다 누가 어떤 방식으로 관여하는가 | 이름이 적힌 본인 | 작업이 바뀔 때 |
| 리소스 플랜 | 그 사람이 얼마나 쓸 수 있는가 | 각자의 팀장 | 월 단위, 가장 바쁜 시기에는 주 단위 |
| 커뮤니케이션 플랜 | 누구에게 무엇을 언제 알리는가 | 받는 쪽 이해관계자 | 이해관계자가 바뀔 때 |
분담은 명세가 아니라 약속입니다
PMBOK은 분담 관련 문서를 자원 관리(Resource Management)와 의사소통 관리(Communications Management)의 산출물로 정리합니다. 책에는 정형적인 표 형식만 적혀 있지만, 현장에서 더 중요한 것은 표를 만드는 과정입니다.
RACI를 PM이 혼자 채우면 PM의 추정이지 합의가 아닙니다. 이름이 적힌 사람이 그 배정에 동의해야 효력이 생기므로, RACI는 보통 한 시간짜리 회의에서 다 같이 채웁니다. 회의실에 모여 한 줄씩 읽으며 “이거 누가 책임?”, “내가요”, “확인”의 흐름을 거쳐야 합니다.
리소스 플랜도 마찬가지입니다. 80%로 적힌 사람이 실제로는 50%만 가능하다면 문서는 거짓말이 되고 일정은 무너집니다.
참고 자료
- Project Management Institute. (2021). A Guide to the Project Management Body of Knowledge (PMBOK Guide) – Seventh Edition. PMI.
- Smith, M. L. (2005). Role and responsibility charting (RACI). Project Management Forum.
- Gido, J., & Clements, J. P. (2014). Successful Project Management (Sixth Edition). Cengage Learning.
다음 편 예고
분담이 끝나도 평화는 오지 않습니다. 예상치 못한 일이 일어나고, 일정이 흔들리고, 누군가는 그건 원래 범위가 아니었다고 주장합니다. 리스크 레지스터, 이슈 로그, 변경 관리 대장이 등장하는 시점입니다.