RACI 차트란? 뜻, 작성법, 예시, 템플릿 총정리 (2026 가이드)

프로젝트가 늦어지는 이유는 대개 어려운 문제 때문이 아닙니다. "이건 누가 하기로 했죠?", "최종 승인은 누가 하나요?", "미리 누구한테 물어봤어야 했죠?" 같은 단순한 질문에 아무도 답하지 못할 때 일이 멈춥니다. RACI 차트는 이런 질문의 답을 한 장의 표로 정리해, 혼선이 생기기 전에 막아 줍니다.

이 글에서는 RACI의 뜻과 네 가지 역할이 실무에서 어떤 의미인지 설명합니다. 실제 프로젝트를 바탕으로 한 예시, RACI 차트를 만드는 6단계와 점검 방법도 다룹니다. 이어서 RASCI·DACI와의 차이, 자주 하는 실수, 바로 복사해 쓸 수 있는 템플릿을 소개하고, 정해 둔 역할이 회의에서 흐지부지되지 않게 하는 방법까지 정리했습니다.

⚠️ 이 글은 2026년 10월 기준 공개 정보와 사용자 피드백을 바탕으로 독자적으로 정리한 것입니다.

목차

1. RACI란?
2. RACI 4가지 역할의 의미
3. RACI 차트 예시: 웹사이트 리뉴얼
4. RACI 차트 만드는 법 6단계
5. 완성된 RACI 차트 점검하는 법
6. RACI와 RASCI, DACI, RAPID의 차이
7. RACI가 필요한 경우와 필요 없는 경우
8. RACI에서 흔히 하는 실수
9. 복사해서 쓰는 RACI 템플릿
10. 회의에서 역할 분담을 유지하는 법
11. 자주 묻는 질문
12. 마치며

RACI란?

RACI는 프로젝트의 업무나 의사결정마다 관련자의 역할을 실행 책임자(Responsible), 최종 책임자(Accountable), 협의 대상(Consulted), 보고 대상(Informed) 네 가지로 나누어 정하는 방법입니다. 세로축에 업무를, 가로축에 담당자를 놓고 각 칸에 R, A, C, I 중 하나를 적은 표를 RACI 차트, RACI 매트릭스 또는 책임 분담표라고 부릅니다.

표를 가로로 읽으면 그 업무를 누가 실행하고, 누가 결과를 책임지며, 누구와 협의하고, 누구에게 결과를 알려야 하는지 보입니다. 세로로 읽으면 한 사람이 맡은 역할을 한눈에 확인할 수 있습니다.

RACI는 프로젝트 관리에서 가장 널리 쓰이는 도구입니다. PMI(미국 프로젝트관리협회)의 PMBOK 가이드도 책임 할당 매트릭스(RAM)의 대표적인 형식으로 소개하고 있어, PMP 자격증을 준비하거나 PM 교육을 받아 본 분이라면 한 번쯤 보셨을 것입니다.

RACI가 유용한 이유는 알파벳 네 글자 자체에 있지 않습니다. 표를 채우다 보면 팀이 평소 미뤄 두던 대화를 피할 수 없게 된다는 점이 핵심입니다. 두 팀장이 서로 자신이 최종 승인권자라고 생각하고 있었다면, 출시 직전이 아니라 첫날에 그 사실이 드러납니다. 아무도 계획하지 않았던 법무 검토는 비어 있는 C 칸으로 눈에 띕니다.

다만 RACI 차트는 프로젝트 계획서가 아닙니다. 일정, 선후 관계, 공수는 담지 않습니다. 계획서가 "언제"를 관리한다면 RACI는 "누가, 어떤 입장으로"를 관리합니다. 두 문서를 함께 쓰는 것이 기본입니다.

RACI 4가지 역할의 의미

네 가지 역할의 정의는 단순해 보이지만 사람마다 다르게 해석하기 쉽습니다. 팀에서 처음에 맞춰 두면 좋은 기준을 정리했습니다.

R(실행 책임자)은 산출물을 실제로 만드는 사람입니다. 원고를 쓰고, 기능을 개발하고, 분석 자료를 정리하는 등 직접 손을 움직입니다. R이 비어 있는 업무는 모두가 내용을 잘 알고 있어도 진행되지 않습니다.

A(최종 책임자)는 결과에 최종적으로 책임을 지는 단 한 사람입니다. 산출물을 승인하고, 실행 책임자들끼리 의견이 갈리면 결정을 내리며, 일이 잘못되었을 때 경위를 설명합니다. RACI에서 가장 중요한 규칙은 "A는 행마다 반드시 1명"입니다. A가 두 명이면 서로 상대가 챙기겠거니 생각하다가 결국 아무도 책임지지 않게 됩니다.

R과 A의 차이는 많은 팀이 헷갈려 하는 부분입니다. 우리말로는 둘 다 "책임자"라고 옮기니 더 그렇습니다. 쉽게 기억하려면 R은 "하는 사람", A는 "책임지는 사람"이라고 생각하면 됩니다. 작은 업무에서는 한 사람이 둘 다 맡는 경우가 많고, 이때는 칸에 "A/R"이라고 적습니다. 규모가 큰 업무에서는 보통 서로 다른 사람이 맡습니다. 예를 들어 새 메인 페이지를 디자인하는 사람은 디자이너(R)이지만, 일정에 맞춰 공개하고 성과를 내는 책임은 마케팅 리더(A)가 집니다.

C(협의 대상)는 전문 지식으로 작업 품질에 영향을 주는 사람입니다. 시스템 구조를 바꾸기 전의 보안 담당자, 가격을 정하기 전의 재무 담당자가 여기에 해당합니다. 협의는 양방향이라 양쪽 모두의 시간이 듭니다. C가 한 명 늘 때마다 업무 속도가 그만큼 느려진다고 생각하는 편이 좋습니다.

I(보고 대상)는 진행 상황이나 결과를 알아야 하지만 의견까지는 필요 없는 사람입니다. 진행 보고, 릴리스 공지, 회의 요약 메일을 받는 입장입니다. 보고에 드는 수고는 적은 데 비해 효과는 큽니다. 여러 부서가 얽힌 프로젝트에서 나오는 불만은 반대 의견보다 "나는 못 들었다"인 경우가 훨씬 많기 때문입니다.

RACI 차트 예시: 웹사이트 리뉴얼

중견 기업이 회사 웹사이트를 리뉴얼하는 상황을 예로 RACI 차트를 만들어 보겠습니다. 역할은 여섯 개, 업무는 여덟 개입니다.

이 표에서 눈여겨볼 점은 네 가지입니다.

• 모든 행에 A는 한 명뿐입니다. 대부분의 업무는 마케팅 리더가 A이지만, 개발은 웹 개발자가, 법무 검토는 법무팀이 A를 맡습니다. A는 직급이 높은 사람에게 자동으로 돌아가는 자리가 아닙니다. 그 결과를 가장 잘 설명할 수 있는 사람이 맡습니다.
• 전문성이 높은 업무는 A/R이 됩니다. 실행과 최종 책임을 한 사람이 함께 지는 것은 자연스러운 일입니다.
• 영업은 대부분 I입니다. 영업팀에게도 새 웹사이트는 중요한 일입니다. 하지만 디자인 단계부터 협의 대상에 넣으면 검토만 한 번 더 늘고 얻는 것은 많지 않습니다. 중요한 시점마다 공유만 잘해도 방향은 맞추면서 일정은 지킬 수 있습니다.
• 빈칸이 있어도 괜찮습니다. 모든 사람이 모든 업무에 관여할 필요는 없습니다. 표가 빽빽하게 차 있다면 오히려 다시 살펴봐야 한다는 신호입니다.

RACI 차트 만드는 법 6단계

일반적인 프로젝트라면 RACI 차트는 한 시간 정도면 만들 수 있습니다. 그 시간의 대부분은 대화에 쓰이는데, 사실 그것이 RACI의 진짜 목적입니다.

1. 업무, 산출물, 의사결정을 나열합니다. 담당이 바뀌는 단위로 적는 것이 요령입니다. "사이트 오픈"은 너무 크고, "푸터 링크 색상 수정"은 너무 작습니다. 대부분의 프로젝트는 8~20행이면 충분합니다. "예산 승인", "외주사 선정" 같은 의사결정은 별도의 행으로 두십시오. 모호함 때문에 문제가 가장 크게 불거지는 곳이 바로 이런 판단 지점입니다.
2. 역할을 나열합니다. 사람이 바뀔 수 있다면 개인 이름보다 역할명으로 적습니다. "김 대리"가 아니라 "프로덕트 매니저"라고 적고, 실명은 표 아래 범례에 따로 적습니다. 실제 업무를 맡는 외주사나 고객사도 포함합니다.
3. A부터 정합니다. 행마다 "이게 잘못되면 누가 설명해야 하는가?"를 묻습니다. 그 사람이 A입니다. 가장 민감한 역할인 A를 먼저 정해 두면 이후 조율이 훨씬 수월해집니다.
4. 다음으로 R을 정하고, 이어서 C와 I를 정합니다. 누가 실제로 일을 하는지, 누구의 전문 의견이 꼭 필요한지, 누구는 결과만 알면 되는지 순서대로 판단합니다. C는 아껴서 쓰십시오. 협의 대상을 한 명 늘리는 것은 회의나 검토를 한 번 더 잡는 것과 같습니다.
5. 관련자 전원과 함께 검토합니다. 메일로 돌려서 의견을 받기보다 짧은 회의에서 함께 확인하는 편이 좋습니다. 의견 차이는 말로 할 때 더 빨리 드러나고, 자신이 함께 정한 역할은 기꺼이 받아들이게 됩니다. 프로젝트 전체에서 가장 가치 있는 회의가 되는 경우도 많습니다.
6. 공유하고 정기적으로 다시 봅니다. 프로젝트 문서, 사내 위키, 프로젝트 채널처럼 팀이 평소 쓰는 곳에 올려 둡니다. 단계가 바뀌거나 구성원이 들고 날 때는 반드시 다시 확인하십시오. 지난 분기 팀 구성이 그대로 남은 RACI 차트는 없느니만 못합니다. 모두가 그 내용을 믿고 움직이기 때문입니다.

완성된 RACI 차트 점검하는 법

표를 다 채웠다면 가로(행)와 세로(열) 두 방향으로 다시 읽어 봅니다. 방향에 따라 찾을 수 있는 문제가 다릅니다.

행별로 보기 (업무):

열별로 보기 (담당자):

RACI가 진가를 발휘하는 것은 바로 이 두 방향 점검입니다. 한 열에 A가 잔뜩 몰려 있다면, 프로젝트가 자꾸 멈추는 이유는 대개 그것으로 설명됩니다. 모든 결정이 한 사람의 일정만 기다리고 있는 것입니다.

RACI와 RASCI, DACI, RAPID의 차이

RACI에는 여러 변형 모델이 있습니다. 어느 쪽이 더 낫다기보다 중점을 두는 부분이 다릅니다.

가장 큰 차이는 업무의 책임을 다루느냐, 의사결정의 책임을 다루느냐입니다. RACI는 여러 업무에 걸쳐 "누가 무엇을 하는가"를 정리하는 도구입니다. 반면 DACI와 RAPID는 "이 결정 하나를 어떻게 내릴 것인가"를 정리할 때 씁니다. DACI에서는 추진자(Driver)가 과정을 이끌고 승인자(Approver)가 최종 결정을 내립니다. RACI의 R과 A에 가까운 구조이지만, 산출물 목록이 아니라 하나의 의사결정에만 초점을 맞춘다는 점이 다릅니다. DACI와 결정 권한을 정하는 방법은 의사결정 가이드에서 자세히 다룹니다.

실무에서는 둘을 함께 쓰는 경우가 많습니다. 프로젝트 전체는 RACI로 관리하고, 그 안의 큰 결정 두세 건만 DACI로 정리하는 방식입니다.

RACI가 필요한 경우와 필요 없는 경우

RACI는 협업이 어려울 때 쓰는 도구입니다. 그래서 협업이 어려운 상황일수록 효과가 큽니다.

RACI가 필요한 경우:

• 세 개 이상의 팀이나 부서가 함께하는 프로젝트입니다.
• 중간에 합류한 구성원이 누가 무엇을 맡고 있는지 파악해야 합니다.
• "원래 누가 승인했어야 했나"를 두고 이미 두 번 이상 논쟁했습니다.
• 외주사, 고객사, 협력사 등 외부와 협업하면서 역할 경계를 분명히 해야 합니다.
• 월말 결산, 장애 대응, 릴리스 관리처럼 반복되는 업무에서 누락이 자주 생깁니다.

RACI가 필요 없는 경우:

• 매일 얼굴을 보는 세 명 정도의 팀입니다.
• 탐색 단계의 업무라 역할이 매주 바뀝니다.
• 템플릿을 채우는 것 자체가 목적이 되어 아무도 읽을 계획이 없습니다.

판단 기준은 간단합니다. 역할이 불분명해서 생긴 최근 문제를 팀에서 아무도 떠올리지 못한다면, RACI는 그저 서류 작업처럼 느껴질 것입니다. 반대로 여러 사람이 곧바로 사례를 댄다면 RACI는 반가운 해결책이 됩니다.

RACI에서 흔히 하는 실수

• A가 두 명 이상입니다. 가장 흔하면서도 가장 치명적인 실수입니다. 공동 책임은 협력적으로 보이지만, 실제로는 서로 상대가 움직이기만 기다리게 됩니다. 두 리더가 정말로 같은 목표를 공유한다면 행을 두 개의 업무로 나누고 각각 A를 한 명씩 두십시오.
• 직급으로 책임을 정합니다. 임원이 모든 행의 A일 필요는 없습니다. A는 결과에 가장 가깝고 결정 권한이 있는 사람이 맡는 것이 원칙입니다. 경영진을 모든 행에 넣으면 앞서 본 병목이 그대로 생깁니다.
• 협의 대상을 너무 많이 둡니다. "혹시 몰라서", "서운해할까 봐" C를 추가하는 일이 흔합니다. 하지만 C가 하나 늘 때마다 확인 절차도 한 번 늘어납니다. 의견을 들으면 좋은 정도라면 I로 바꾸십시오.
• 부서 단위로 역할을 정합니다. "개발팀이 R"이라고 하면 명확해 보이지만, 실제로 손을 움직일 사람은 정해지지 않은 상태입니다. 가능하면 한 사람을 가리키는 역할명이나 이름으로 적으십시오.
• 혼자 만들어서 배포만 합니다. 관리자 한 명이 작성해 메일로 돌린 RACI는 가설에 불과합니다. 5단계의 공동 검토를 거쳐야 비로소 팀의 합의가 됩니다.
• 한 번 만들고 다시 보지 않습니다. 프로젝트가 진행되면 역할은 조금씩 바뀝니다. 단계가 바뀔 때 점검하지 않으면 표와 현실은 점점 멀어집니다.
• 회의에서 RACI를 쓰지 않습니다. 표에는 외주사 선정의 A가 김 팀장으로 되어 있는데, 회의에서는 마지막에 말한 사람의 의견대로 결정되는 일이 생깁니다. 실제로 일이 배분되는 자리에서 RACI를 쓰지 않으면 표를 만든 의미가 없습니다.

복사해서 쓰는 RACI 템플릿

아래 내용을 프로젝트 문서에 붙여 넣고 [ ] 부분만 바꿔 쓰시면 됩니다. 범례는 지우지 않기를 권합니다. 모두가 알파벳을 같은 뜻으로 읽는 것만으로도 RACI 효과의 절반은 얻기 때문입니다.

RACI 차트: [프로젝트명]
표 관리자: [이름]   최종 검토일: [날짜]

범례
R = 실행 책임자 (실제로 일을 함, 1명 이상)
A = 최종 책임자 (결과를 책임지고 승인함, 행마다 반드시 1명)
C = 협의 대상 (작업 전이나 도중에 의견을 구함, 양방향)
I = 보고 대상 (결과를 공유받음, 일방향)

| 업무 / 의사결정          | [역할1] | [역할2] | [역할3] | [역할4] | [역할5] |
|--------------------------|---------|---------|---------|---------|---------|
| [범위 확정]              | A       | C       | C       |         | I       |
| [산출물 1]               | C       | A/R     |         | C       |         |
| [산출물 2]               |         | C       | A       | R       | I       |
| [의사결정: 예산]         | A       | C       | C       |         | I       |
| [의사결정: 공개 여부]    | A       | C       | I       | C       | I       |

이름: [역할1] = [이름], [역할2] = [이름], ...

공유 전 확인
[ ] 행마다 A는 1명뿐
[ ] 행마다 R이 1명 이상
[ ] A와 R이 한 사람에게 몰린 열이 없음
[ ] 관련자 전원과 함께 검토함
[ ] 다음 검토일을 정함: [날짜]

회의에서 역할 분담을 유지하는 법

RACI 차트는 회의 한 번으로 정해지고, 그 뒤의 모든 회의에서 시험대에 오릅니다. 킥오프, 정례 회의, 의사결정 회의는 업무가 배분되는 자리입니다. 책임 소재가 분명해지기도 하고, 슬그머니 흐려지기도 하는 곳이 바로 여기입니다. 표와 현실이 어긋나지 않도록 다음 세 가지 습관을 들여 보시기 바랍니다.

• 일을 맡길 때 역할을 말로 분명히 합니다. "외주사 선정은 김 팀장님이 최종 결정해 주세요. 이 대리님과 박 과장님은 목요일까지 의견을 보내 주시고요"라고 말하는 데는 5초면 충분합니다. 이 한마디로 RACI의 역할 분담이 그 자리에서 모두에게 공유됩니다.
• 회의를 마칠 때 담당자를 다시 확인합니다. 업무마다 실행 책임자와 최종 책임자가 누구인지 짚어 봅니다. 누군가 머뭇거린다면 그곳이 RACI의 빈틈입니다.
• 팀이 찾을 수 있는 곳에 기록을 남깁니다. 참석자의 기억에만 남은 업무 배분은 시간이 지나면 어긋나기 마련입니다. 누가 무엇을 맡기로 했는지 보여 주는 근거는 회의록뿐입니다.

대부분의 팀이 놓치는 것은 세 번째 습관입니다. 회의를 진행하면서 자세한 회의록까지 쓰기는 쉽지 않기 때문입니다. 이 부분은 AI에게 맡길 수 있습니다.

SuperIntern은 Mac과 Windows에서 쓸 수 있는 봇 없는 AI 회의 어시스턴트입니다. PC의 오디오를 직접 수집하므로 회의에 봇이 들어오지 않습니다. Zoom, Google Meet, Microsoft Teams, Webex는 물론 대면 회의에서도 똑같이 쓸 수 있습니다.

RACI로 역할을 관리하는 팀이라면 다음과 같이 활용할 수 있습니다.

• AI Canvas가 원하는 형식으로 회의록을 실시간 작성합니다. "업무마다 실행 책임자, 최종 책임자, 마감일을 적고, 담당자가 정해지지 않은 업무는 표시해 주세요"라고 평소 쓰는 말로 한 번만 지시해 두면 됩니다. 회의록이 회의 중에 그 형식대로 채워지므로, 마지막 확인도 화면에 이미 정리된 내용을 훑어보는 것으로 끝납니다.

• 화자 식별로 누가 맡았는지 남습니다. "그건 제가 하겠습니다"라고 말한 사람이 스크립트에 기록되므로, 나중에 기억에 의존하지 않고 담당자를 확인할 수 있습니다. 캘린더 일정에서 참석자를 바로 추가할 수 있어 화자 이름을 붙이는 작업도 빠릅니다.
• 여러 회의를 넘나들며 채팅으로 질문할 수 있습니다. "외주사 선정의 최종 책임자는 누구였고, 기한은 언제로 정했지?"라고 물으면 프로젝트 회의에서 실제로 나온 내용을 바탕으로 답해 줍니다.
• 정해진 담당을 업무 도구에 반영할 수 있습니다. SuperIntern의 MCP 연동을 이용하면 Claude나 ChatGPT 같은 AI 에이전트가 회의록을 읽고, 합의된 업무를 Linear나 Asana 등의 티켓으로 등록할 수 있습니다.

50개 이상의 언어를 지원하는 실시간 자막과 번역 기능도 있어, 해외 구성원이 함께하는 팀에서도 쓸 수 있습니다. 다만 SuperIntern이 RACI 차트 자체를 대신하지는 않습니다. 표는 지금처럼 프로젝트 문서에서 관리하면 됩니다. SuperIntern은 업무가 배분될 때마다 정해 둔 역할 분담을 빠짐없이 기록으로 남기는 역할을 합니다. 무료 플랜이 있으니 다음 킥오프 회의에서 부담 없이 써 보시기 바랍니다.

자주 묻는 질문

RACI는 무엇의 약자입니까?

Responsible(실행 책임자), Accountable(최종 책임자), Consulted(협의 대상), Informed(보고 대상)의 머리글자입니다. R은 일을 실행하는 사람, A는 결과를 책임지고 승인하는 사람, C는 작업 전이나 도중에 의견을 구하는 사람, I는 결과를 공유받는 사람입니다.

실행 책임자(R)와 최종 책임자(A)는 어떻게 다릅니까?

R은 일을 하는 사람이고 A는 결과를 책임지는 사람입니다. 한 업무에 R은 여러 명일 수 있지만 A는 한 명뿐이며, A가 산출물을 승인하고 결과를 설명합니다. 작은 업무에서는 한 사람이 둘 다 맡는 경우가 많고, 이때는 A/R로 표기합니다.

한 업무에 A를 두 명 둬도 됩니까?

권하지 않습니다. RACI의 기본 규칙은 "업무 하나에 A는 한 명"입니다. 책임을 나누면 대개 아무도 책임지지 않게 됩니다. 두 사람이 서로 다른 부분을 맡고 있다면 업무를 두 행으로 나누십시오.

RACI와 DACI는 어떻게 다릅니까?

RACI는 프로젝트 안의 여러 업무에 역할을 배정하는 방법입니다. DACI(추진자, 승인자, 기여자, 보고 대상)는 하나의 의사결정에 초점을 맞춰 누가 논의를 이끌고 누가 최종 결정을 내리는지 분명히 합니다. 프로젝트 전체는 RACI로, 큰 결정은 DACI로 나눠 쓰는 팀이 많습니다.

RASCI는 무엇입니까?

RACI에 S(Support, 지원자)를 더한 모델입니다. 지원자는 실행 책임자의 작업을 돕지만 산출물에 대한 책임은 지지 않습니다. IT 운영이나 공유 서비스처럼 지원 조직이 많이 참여하는 대규모 업무에 유용합니다.

엑셀이나 구글 스프레드시트로 RACI 차트를 만들려면 어떻게 합니까?

첫 번째 열에 업무를, 첫 번째 행에 역할을 놓고 각 셀에 R, A, C, I를 입력합니다. 조건부 서식으로 글자마다 색을 다르게 지정하면 훨씬 보기 쉽습니다. 행마다 COUNTIF 함수로 "A"의 개수를 세면 A가 없거나 두 명 이상인 행을 바로 찾을 수 있습니다.

RACI 차트는 얼마나 자주 업데이트해야 합니까?

프로젝트 단계가 바뀔 때, 구성원이 합류하거나 빠질 때, 담당을 두고 갈등이 생겼을 때가 점검 시점입니다. 계속 이어지는 업무 프로세스라면 분기에 한 번 정도 검토하는 것이 적당합니다.

마치며

RACI는 프로젝트 관리 도구 가운데서도 특히 단순한 방법입니다. 그 가치는 표를 만들며 오가는 대화에서 나옵니다. 업무와 의사결정을 나열하고, 무엇보다 먼저 행마다 A를 한 명씩 정하십시오. C는 꼭 필요한 만큼만 두고, 표를 가로와 세로로 점검한 뒤 관련자 전원과 함께 검토합니다.

그다음에는 정해 둔 역할이 실제 회의에서도 지켜지도록 해야 합니다. 일을 맡길 때 R과 A를 말로 분명히 하고, 회의를 마칠 때 담당자를 다시 확인하며, 누군가의 기억에 기대지 않는 기록을 남기십시오. 이런 습관이 자리 잡으면 "그쪽에서 하시는 줄 알았어요"라는 말을 들을 일은 거의 없어질 것입니다.

SuperIntern 무료 체험하기 : 팀이 대화하는 동안 모든 담당자와 업무를 실시간으로 기록하는, 봇 없는 회의록.