RACI 매트릭스는 업무·결정마다 Responsible(실무 담당), Accountable(최종 책임), Consulted(자문), Informed(통보)의 네 가지 역할을 배정해 "이 일은 누가 하고, 누가 책임지는가"를 한 장의 표로 못박는 책임 할당 도구입니다. 핵심 규칙은 단 하나, 모든 업무에 A(최종 책임자)는 정확히 한 명이어야 한다는 것인데요. 역할 모호성이 직무 만족과 생산성을 떨어뜨리고 갈등을 키운다는 연구가 누적된 상황에서, RACI는 회의에서 매번 반복되는 "그거 누가 하기로 했죠?"를 구조적으로 없애는 가장 단순한 장치입니다. 이 글에서는 RACI의 정의와 작성 4단계, 흔한 실패 패턴, RASCI·RACI-VS 변형까지 실무 관점으로 정리합니다.
목차
- 회의는 끝났는데 아무도 안 움직이던 프로젝트
- 역할 모호성은 왜 조직을 갉아먹는가
- RACI 매트릭스란 무엇인가: 네 글자의 정의
- RACI 매트릭스 작성 4단계
- RACI가 실패하는 5가지 패턴
- RASCI·RACI-VS: 언제 변형을 써야 하나
- FAQ
- 같이 읽으면 좋은 것들
회의는 끝났는데 아무도 안 움직이던 프로젝트
예전에 한 중견 커머스 회사의 신규 멤버십 출시 프로젝트를 곁에서 본 적이 있는데요. 킥오프 회의에는 마케팅, 개발, CS, 법무, 디자인까지 열한 명이 들어왔습니다. 두 시간 동안 활발하게 논의가 오갔고 다들 "좋은 방향"이라며 끄덕였죠. 그런데 2주 뒤 진행 점검 회의에서 약관 초안이 한 글자도 진척되지 않았다는 사실이 드러났습니다.
이유는 허무했습니다. 마케팅팀은 "약관은 당연히 법무가 쓰는 것"이라 생각했고, 법무팀은 "우리는 검토만 하지 초안은 사업부가 주는 것"이라 여겼던 겁니다. 둘 다 자기가 R(담당)이 아니라고 믿었던 거죠. 회의록에는 "약관 정비 필요"라고만 적혀 있었고, 그 칸 옆에 이름이 없었습니다.
그 회사가 다음 분기에 도입한 게 바로 RACI 매트릭스였습니다. 거창한 컨설팅이 아니라, 스프레드시트 한 장이었어요. 세로에 업무 25개, 가로에 팀 7개를 두고 각 칸에 R·A·C·I를 채워 넣었습니다. 작성하는 데 걸린 시간은 두 번의 워크숍, 약 세 시간 정도였습니다. 흥미로운 건 표를 채우는 과정 자체였는데요. "이 칸 A는 누구죠?"라는 질문이 나올 때마다 그동안 아무도 입 밖에 내지 않던 책임 공백이 하나씩 튀어나왔습니다.
표가 완성된 뒤 가장 달라진 건 회의 시간이었습니다. "이거 누가 하기로 했더라"를 더듬는 대화가 사라지니, 같은 안건을 다루는 회의가 평균 40분에서 25분 안팎으로 줄었다고 합니다. 정확한 수치는 그 팀의 내부 체감이지만, 핵심은 분명했어요. 일이 빨라진 게 아니라, 누가 그 일을 쥐고 있는지가 보이기 시작한 것뿐이었습니다.
역할 모호성은 왜 조직을 갉아먹는가
한 줄 요약: 누가 책임지는지 모르면 일은 멈추고, 사람은 서로를 의심합니다.
브랜드나 솔루션을 이야기하기 전에 문제의 구조부터 봐야 하는데요. 조직이 커질수록 업무는 여러 부서에 걸쳐 흩어집니다. 이때 "협업"이라는 좋은 말 뒤에는 책임 소재의 분산이라는 함정이 숨어 있습니다. 역할 모호성(role ambiguity)은 구성원 간 업무 혼선과 책임 떠넘기기로 이어지고, 직무 만족·생산성·조직 효과성을 낮추는 반면 긴장과 적대감을 키운다는 국내 경험 연구가 있습니다.
심리학에서 말하는 책임 분산(diffusion of responsibility)이 조직에서도 똑같이 작동합니다. 여러 사람이 한 업무를 "공동으로" 맡으면, 역설적으로 아무도 그 일을 자기 일로 느끼지 않습니다. 다들 옆 사람이 챙길 거라 가정하기 때문이죠. RACI는 바로 이 인간 본성을 거스르기 위해 설계된 도구입니다. 모든 업무에 단 하나의 A를 강제함으로써, "당신이 책임자"라는 사실을 표 위에 박제하는 거예요.
Asana의 역할·책임 정립 가이드도 같은 결을 짚습니다. 명확한 역할과 책임이 없으면 프로젝트 계획을 고수하기 어렵고, 생산성을 높이려면 프로젝트 초반에 각 팀원이 맡을 구체적 작업을 분명히 해야 한다는 것입니다. 기능적 조직 구조가 효율적이라 평가받는 이유도 부서 내에 책임과 역할이 또렷하게 정의돼 있기 때문입니다.
문제는 대부분의 조직이 이걸 머릿속으로만 합의한다는 점입니다. 말로는 "역할 분담이 중요하다"고 하면서도, 그것을 가시화한 문서는 어디에도 없습니다. RACI 매트릭스가 하는 일은 단순합니다. 머릿속의 암묵적 합의를 표 한 장으로 끌어내, 더 이상 해석의 여지가 없게 만드는 것이죠.
RACI 매트릭스란 무엇인가: 네 글자의 정의
한 줄 요약: RACI는 업무마다 네 종류의 관여 방식을 지정하는 책임 할당 매트릭스(Responsibility Assignment Matrix)입니다.
RACI 매트릭스(RACI Matrix)는 프로젝트나 프로세스의 각 업무·결정에 대해 사람과 팀의 역할을 정의하는 표입니다. 세로축에는 업무·결과물·마일스톤을, 가로축에는 관여하는 사람·팀·이해관계자를 둡니다. 그리고 업무와 사람이 만나는 칸마다 R·A·C·I 중 하나를 적습니다. Atlassian과 monday.com은 이 도구를 협업 프로젝트의 역할 혼선을 줄이는 표준 프레임워크로 소개합니다.
네 글자의 의미는 다음과 같습니다.
| 역할 | 영문 | 정의 | 인원 규칙 |
|---|---|---|---|
| R | Responsible (실무 담당) | 실제로 그 일을 수행하는 사람 | 한 업무에 최소 1명, 가급적 소수 |
| A | Accountable (최종 책임) | 완료를 감독하고 승인하며 결과를 책임지는 사람 | 한 업무에 정확히 1명 |
| C | Consulted (자문) | 작업 전·중에 의견과 전문성을 제공하는 사람 | 필요한 사람만, 양방향 소통 |
| I | Informed (통보) | 진행 상황과 결정을 통보받는 사람 | 결과를 알아야 하는 사람, 단방향 소통 |
가장 헷갈리는 건 R과 A의 차이인데요. R은 손을 움직여 일을 하는 사람이고, A는 "이 일이 제대로 끝났다"고 서명하는 사람입니다. A는 일을 직접 하지 않을 수 있지만, 결과가 잘못되면 책임지는 단 한 명입니다. 종종 한 사람이 R과 A를 겸할 수도 있습니다. 다만 A가 여러 명이면 그 순간 책임은 사라집니다. 결정이 필요할 때 두 사람이 서로를 쳐다보기 때문이죠.
C와 I의 구분도 실무에서 중요합니다. C는 일을 시작하기 전이나 진행 중에 의견을 구하는 양방향 관계이고, I는 결과만 통보받는 단방향 관계입니다. C를 너무 많이 두면 의사결정이 느려지고 표가 무거워지므로, 의견이 정말로 필요한 사람만 C에 넣는 게 원칙입니다. Wikipedia의 책임 할당 매트릭스 문서도 RACI를 RAM의 대표적 형태로 정리하고 있습니다.
RACI 매트릭스 작성 4단계
한 줄 요약: 업무를 나열하고, 사람을 배치하고, 칸을 채운 뒤, 규칙으로 검증하면 끝입니다.
기존 방식은 회의에서 "이건 A팀이, 저건 B팀이"라고 말로 합의하고 회의록에 흘려 적는 것이었습니다. 새 방식은 그 합의를 한 장의 표로 강제 출력하는 것이고요. 변화된 결과는 명확합니다. 빠진 책임이 빈칸으로 드러나니까요. 초보자도 따라 할 수 있게 4단계로 정리하겠습니다.
1단계: 업무·결과물을 세로축에 나열
프로젝트 계획을 참고해 모든 업무, 결과물, 마일스톤을 세로로 적습니다. 이때 너무 잘게 쪼개지 말고 의미 있는 단위로 묶는 게 중요합니다. "이메일 보내기" 같은 미세한 작업이 아니라 "런칭 약관 확정", "결제 모듈 연동", "고객 안내 발송"처럼 결정이 필요한 단위로 잡는 것이죠. 일상적인 상태 공유 회의 같은 관리 항목은 표에서 빼는 편이 깔끔합니다.
2단계: 사람·팀을 가로축에 배치
프로젝트에 관여하는 모든 팀원, 관리자, 이해관계자를 가로로 배치합니다. 개인 이름으로 둘지 역할(예: PM, 디자인 리드)로 둘지는 조직 규모에 따라 정하면 되는데요. 잦은 인사 이동이 있는 조직이라면 역할명으로 두는 편이 표의 수명을 늘려줍니다.
3단계: 각 칸에 R·A·C·I 채우기
업무와 사람이 만나는 칸마다 네 글자 중 하나를 넣습니다. 빈칸으로 두는 것도 의미가 있습니다. "이 사람은 이 업무에 관여하지 않는다"는 명시적 선언이니까요. 칸을 채우다 보면 자연스럽게 토론이 일어나는데, 그 토론 자체가 RACI의 진짜 가치입니다.
4단계: 규칙으로 검증
마지막으로 세 가지를 점검합니다. 첫째, 모든 행에 A가 정확히 하나 있는가. 둘째, A 없는 업무나 A가 둘인 업무는 없는가. 셋째, 한 사람에게 R이 지나치게 몰려 있지 않은가. project-management.com의 2026 가이드는 이 검증 단계를 건너뛰면 표가 장식품이 된다고 지적합니다. 표를 만든 뒤에는 분기마다 한 번씩 다시 들여다보며 현실과 맞는지 갱신해야 합니다.
RACI가 실패하는 5가지 패턴
한 줄 요약: RACI는 만드는 것보다 살아 움직이게 하는 게 어렵습니다.
RACI는 단순해서 강력하지만, 바로 그 단순함 때문에 자주 망가집니다. 실패 패턴을 알면 절반은 피할 수 있는데요. Tallyfy는 "RACI가 실패하는 이유는 인간 본성과 싸우기 때문"이라는 흥미로운 진단을 내놓기도 했습니다.
- A가 둘 이상인 업무: 가장 치명적인 실수입니다. 책임자가 둘이면 결정 순간에 서로를 바라보고, 책임 분산이 그대로 재현됩니다. A는 무조건 한 명입니다.
- R이 한 사람에게 몰림: 특정 인물에게 R이 줄줄이 붙어 있다면 그건 역량의 표시가 아니라 병목의 신호입니다. 표가 그 위험을 보여주는데도 많은 실무자가 그냥 넘깁니다.
- C가 너무 많음: 자문 대상이 많을수록 의사결정이 느려집니다. 의견이 정말 필요한 사람만 C에 넣어야 합니다.
- 만들고 방치함: 가장 흔하고 아까운 실수입니다. 공들여 만든 표를 폴더에 묻어두고 다시 안 보는 것이죠. 표가 컴플라이언스 문서가 되는 순간 죽은 도구가 됩니다.
- 사람은 7일 안에 배운 것의 90%를 잊는다: 원격·분산 팀에서 특히 문제인데요. 벽에 붙이고 교육해도 매 결정마다 표를 확인하게 만들 수는 없습니다. 그래서 RACI는 사람들이 자주 보는 협업 도구나 업무 흐름 안에 녹여 넣어야 효과가 납니다.
이 다섯 가지 중 앞의 셋은 표를 만들 때, 뒤의 둘은 표를 운영할 때 발생합니다. 작성 워크숍에서 "이 행 A는 정말 한 명인가?"를 소리 내어 확인하는 작은 습관만으로도 앞쪽 실수는 대부분 막을 수 있습니다.
RASCI·RACI-VS: 언제 변형을 써야 하나
한 줄 요약: 기본은 RACI, 도움 역할이 중요하면 RASCI, 품질 검증이 핵심이면 RACI-VS입니다.
RACI에는 상황별 변형이 있습니다. Manifestly와 Perfony의 비교를 종합하면 다음과 같이 정리됩니다.
RASCI는 기존 RACI에 S(Support, 지원)를 더한 형태입니다. 일을 직접 하는 R과, 자원이나 도움을 제공하는 S를 구분하는 거죠. 부서 간 협업이 많거나 외부 이해관계자가 얽힌 큰 프로젝트에서, 보이지 않던 지원 역할을 명시적으로 인정하고 싶을 때 유용합니다.
RACI-VS는 V(Verifier, 검증자)와 S(Signatory, 승인자)를 추가합니다. V는 결과물이 회사가 요구하는 기준에 맞는지 확인하는 사람으로, 의료기기·제약·항공처럼 품질 요건이 극도로 높은 산업에서 쓰입니다.
그렇다면 무엇을 선택해야 할까요. 역할 정의가 처음인 팀이라면 기본 RACI로 시작하는 게 정석입니다. 직관적이고 업계 어디서나 통하며, 대부분의 협업 프로젝트엔 그걸로 충분합니다. RASCI는 지원 역할을 분명히 드러내야 할 때만, RACI-VS는 검증이 비즈니스의 핵심일 때만 쓰는 게 좋습니다. 변형은 정보를 더해주는 동시에 복잡성도 더하므로, 그 구분이 진짜로 도움이 될 때만 도입하라는 것이 공통된 조언입니다.
FAQ
RACI 매트릭스는 만들기 어렵나요?
도구 자체는 스프레드시트 한 장이면 충분할 만큼 단순합니다. 어려운 건 표를 채우는 과정에서 "이 일의 진짜 책임자가 누구냐"를 정직하게 합의하는 일입니다. 보통 두세 시간짜리 워크숍 한두 번이면 초안이 나옵니다. 진짜 난이도는 만든 뒤 꾸준히 갱신하며 살아 있는 문서로 유지하는 데 있습니다.
R과 A는 같은 사람이 맡아도 되나요?
됩니다. 작은 업무에서는 일을 직접 하는 사람(R)이 책임도 지는 경우(A)가 흔합니다. 중요한 규칙은 A가 한 업무에 정확히 한 명이어야 한다는 점뿐입니다. 반대로 A가 둘이 되는 순간 책임은 사라지니 그것만은 피해야 합니다.
RACI를 도입하면 회의 시간이 정말 줄어드나요?
"누가 하기로 했죠?"를 더듬는 대화가 사라지기 때문에 체감상 회의가 짧아진다는 사례가 많습니다. 다만 표를 만들어 두고 보지 않으면 효과가 없습니다. 사람들이 자주 들여다보는 업무 도구나 진행 문서 안에 표를 녹여 넣어야 실제로 작동합니다.
스타트업처럼 작은 팀에도 필요한가요?
다섯 명 안팎의 팀이라면 머릿속 합의로도 굴러갑니다. 하지만 부서가 셋 이상 얽히기 시작하면, 그러니까 협업의 경계가 흐려지는 순간부터 RACI의 효용이 급격히 커집니다. 규모보다는 업무가 여러 사람에 걸쳐 있는지가 도입 기준입니다.
RACI와 OKR·데이터 기반 의사결정은 어떻게 다른가요?
OKR이 "무엇을 달성할 것인가"라는 목표를 정렬한다면, RACI는 "그 일을 누가 한다"는 책임을 정렬합니다. 데이터 기반 의사결정이 결정의 근거를 다룬다면, RACI는 결정의 주체를 다룹니다. 셋은 경쟁 관계가 아니라 목표·근거·책임을 각각 맡는 보완 도구입니다.