소프트웨어 프로젝트가 커지면 커질수록 누가 어떤 일을, 어떤 책임으로 수행하는가를 명확히 정의하는 것이 중요합니다.
그렇기에 R & R 방식에 대해 알아봅시다.
1. 업무·산출물(Deliverables) 식별
프로젝트를 작은 단위로 쪼개야 책임 분담도 명확해집니다.
1. WBS(Work Breakdown Structure) 작성
- 프로젝트 목표 → 주요 단계(Phase) → 산출물(Deliverable) → 세부작업(Task) 순으로 계층 분해
2. 주요 산출물 정의
- 요구사항 명세서, 설계문서(아키텍처·DB·API), 구현 모듈, 테스트 케이스, 배포 스크립트 등
이 단계에서 나오는 산출물들이 매트릭스의 행(Row) 이 됩니다.
2. 역할(Role) 범위 정리
“누가 어떤 역할을 맡느냐”도 명확히 해야 나중에 책임을 돌리지 않습니다.
1. 기본 역할(Role) 유형
- Project Manager (PM): 일정·범위·자원 관리, 리스크·이슈 조율
- Lead/Architect: 전체 아키텍처 설계, 기술 스택 결정
- Developer: 모듈 구현, 코드 리뷰, 유닛 테스트
- QA/Test Engineer: 테스트 계획·자동화·버그 리포트
- DevOps/Release Engineer: CI/CD 파이프라인, 배포·모니터링
- Business Analyst/PO: 요구사항 수집·우선순위 결정
2. 세부 역할(Role Profile) 정의
- 책임 범위(What? How? When?), 권한(의사결정 수준), 성과 지표(KPI) 등 구체화
이 역할들이 매트릭스의 열(Column) 이 됩니다.
3. R & R 매트릭스 종류와 예시
3.1 RACI 매트릭스 (기본형)
- R (Responsible): 실제 수행
- A (Accountable): 최종 승인·책임 (각 Task당 하나)
- C (Consulted): 사전 검토·자문
- I (Informed): 결과 공유
모듈 개발은 Developer가 실제 구현(R), Architect가 설계 자문(C), PM/PO 등이 결과를 I로 공유받습니다.
3.2 RASCI 매트릭스 (Support 추가)
- S (Support): 수행을 지원
UI 프로토타입 제작은 UX가 지원(S)하고, Dev가 실제 제작(R)합니다.
3.3 DACI 매트릭스 (의사결정 중심)
- D (Driver): 추진 및 진척 관리
- A (Approver): 최종 승인
- C (Contributor): 수행·의견 제공
- I (Informed): 결과 공유
기술 스택 선정은 Architect가 주도(D)하고, CTO가 승인(A)합니다.
3.4 RAPID 매트릭스 (제안·합의 세분화)
- R (Recommend): 대안 제안
- A (Agree): 동의
- P (Perform): 실행
- I (Input): 사전 의견
- D (Decide): 최종 결정
배포 스크립트 설계는 DevOps가 제안(R)하고, Arch이 동의(A)하며, PM이 최종 결정(D)합니다.
3.5 MOCHA 매트릭스 (관리자·실무 분리)
- M (Manager): 자원·성과 관리
- O (Owner): 수행 및 결과 책임
- C (Consulted): 자문
- H (Helper): 지원
- A (Approver): 최종 승인
Scrum Master가 워크숍 운영(O), PM이 자원 배치·성과 관리(M)를 담당합니다.
4. 언제, 어떤 매트릭스를 선택할까?
5. 팀원 역량 매칭과 문서화
- 스킬 매트릭스로 개인 역량(Level 1~5) 관리 → 시니어에게 A, 주니어에게 R 배치
- 문서화:
- RACI·변형 매트릭스를 Confluence나 스프레드시트로 공유
- 역할 설명서(Role Description)에 권한·의사소통 플로우 상세 기재
- 정기 리뷰: 프로젝트 중간·종료 시 매트릭스와 실제 수행 비교·피드백
6. 변경 관리(Change Control)
- 역할·매트릭스 변경 시 항상 문서 업데이트
- 변경 내역은 이슈 트래커에 기록해 “누가 언제 왜 바뀌었는지”를 투명하게 관리
작은 문제를 하나하나 해결하며, 누군가의 하루에 선물이 되는 코드를 작성해 갑니다.