RACI 차트(책임분담표) 만드는 법: R과 A를 헷갈리지 않는 기준

요지

RACI 차트는 일마다 누가 하고(R), 누가 결과를 책임지고(A), 누구에게 미리 묻고(C), 누구에게 알리는지(I)를 한 장에 적은 표다.
자주 틀리는 곳은 R과 A다. R은 그 일을 실제로 하는 사람, A는 결과가 됐는지 안 됐는지를 답하는 사람이다. 한 일에 R은 여럿일 수 있지만 A는 한 사람만 둔다.
표를 다 채웠으면 가로로 한 번, 세로로 한 번 읽는다. 가로로는 A가 하나인지와 R이 있는지를, 세로로는 한 사람에게 일이 몰렸는지를 본다.

네 글자의 뜻

표는 가로로 밀어서 볼 수 있습니다.

글자	영어	뜻	확인하는 질문
R	Responsible	그 일을 실제로 하는 사람	누가 손을 움직여 이 일을 하나
A	Accountable	결과를 최종 책임지고 승인하는 사람	이 일이 잘못되면 누구에게 묻나
C	Consulted	하기 전에 의견을 묻는 사람	누구의 의견을 듣지 않고 하면 다시 해야 하나
I	Informed	한 뒤에 결과를 알리는 사람	누가 이 결과를 모르면 곤란해지나

C와 I는 방향이 다르다. C는 묻고 답을 받는다. 그래서 C가 많으면 답을 기다리는 시간이 늘어난다. I는 알리기만 하면 된다.

PMBOK® 지침서 8판 한국어판은 이 표를 RACI 매트릭스라고 부르고, 책임배정매트릭스의 한 예로 든다. 네 글자를 담당, 책임, 자문, 통보로 옮기고, 그림에서는 수행 책임, 최종 책임, 협의 대상, 공유 대상으로 적는다. 이 글에서는 실무에서 흔히 쓰는 「RACI 차트」와 네 글자를 그대로 쓴다. 우리말로는 책임분담표라고도 부른다.

R과 A를 구분하는 기준 세 가지

첫째, 질문을 바꿔서 묻는다. 「누가 하나」의 답이 R이고, 「잘못되면 누구에게 묻나」의 답이 A다. 두 질문의 답이 같은 사람이면 그 사람이 R과 A를 함께 맡는다. 작은 팀에서는 흔한 일이고 틀린 것이 아니다.

둘째, A는 한 일에 한 사람만 둔다. A가 둘이면 서로 상대가 확인했다고 생각하기 쉽다. 두 부서가 함께 책임져야 한다고 느껴지면 일을 둘로 나눈다. 「요구사항 정리」를 「업무 요구사항 정리」와 「기술 요구사항 정리」로 나누면 A를 하나씩 둘 수 있다.

셋째, A는 그 일을 승인할 권한이 있는 사람이어야 한다. 일을 가장 잘 아는 사람과 승인할 수 있는 사람이 다르면, 잘 아는 사람이 R이고 승인하는 사람이 A다. 권한이 없는 사람을 A로 적으면 결정이 필요할 때마다 다른 사람을 찾아가야 한다.

예: 고치기 전과 고친 뒤

가상의 물류 회사가 창고 재고 조회 화면을 개편하는 프로젝트를 한다고 하자. 프로젝트 관리자가 처음 만든 표는 아래와 같았다.

고치기 전

표는 가로로 밀어서 볼 수 있습니다.

일	스폰서	프로젝트 관리자	현업 팀장	개발 리드	개발자	테스트 담당
요구사항 정리	I	A	A	C	C	C
화면 설계	I	C	C	A		C
개발	I	I	I	R	R	I
인수 테스트	C	C	R	C	C	R
운영 전환 결정	A	R	C	C	C	C

가로로 한 줄씩 읽으면 문제가 보인다.

요구사항 정리: A가 둘이고 R이 없다. 책임지는 사람은 둘인데 실제로 정리하는 사람은 적혀 있지 않다.
화면 설계: R이 없다. 개발 리드가 책임진다는 것만 있고 누가 그리는지 모른다.
개발: A가 없다. 일정이 늦어지면 누구에게 물어야 하는지 정해지지 않았다.
인수 테스트: A가 없고 C가 넷이다. 테스트를 시작하기 전에 네 사람의 의견을 기다려야 한다.
운영 전환 결정: C가 넷이다. 결정에 꼭 필요한 의견이 누구 것인지 구분되지 않았다.

고친 뒤

표는 가로로 밀어서 볼 수 있습니다.

일	스폰서	프로젝트 관리자	현업 팀장	개발 리드	개발자	테스트 담당
요구사항 정리	I	A	R	C
화면 설계		I	C	A	R
개발		I		A	R
인수 테스트	I	I	A	C		R
운영 전환 결정	A	R	C	C		I

달라진 것은 세 가지다. 모든 줄에 A가 하나씩 있다. 모든 줄에 R이 있다. C는 의견을 듣지 않으면 다시 해야 하는 사람만 남기고 나머지는 I로 바꾸거나 비웠고, I도 결과를 꼭 알아야 하는 사람만 남겼다. 빈칸은 그 일에 관여하지 않는다는 뜻이고, 빈칸이 있어야 표가 읽힌다.

이 표는 가상의 예이고 정답이 아니다. 인수 테스트의 A를 현업 팀장이 아니라 프로젝트 관리자로 두는 조직도 있다. 중요한 것은 어느 쪽으로 정했는지가 표에 적혀 있고 관련된 사람이 모두 같은 표를 보는 것이다.

다 채운 뒤 확인하는 순서

가로로 읽는다. 줄마다 A가 정확히 하나인지, R이 하나 이상인지 본다.
C를 센다. 한 줄에 C가 셋을 넘으면 정말 미리 물어야 하는 사람인지 다시 본다. 알리기만 하면 되는 사람은 I로 바꾼다.
세로로 읽는다. 한 사람의 열에 R과 A가 몰려 있으면 그 사람이 병목이 되기 쉽다. 열 전체가 비어 있으면 그 사람이 이 표에 있어야 하는지 본다.
당사자에게 보여 준다. 자기 이름이 적힌 칸을 본인이 확인해야 한다. 「제가 A인 줄 몰랐다」는 말은 표를 공유할 때 나와야 하고, 일이 잘못된 뒤에 나오면 늦다.
바뀌면 고친다. 사람이 바뀌거나 범위가 바뀌면 표도 고친다. 고친 날짜를 표에 적어 둔다.

자주 하는 실수

일을 너무 잘게 나눈다. 모든 일을 줄로 만들면 표가 길어져 아무도 읽지 않는다. 주요 인도물이나 결정 단위로 스무 줄 안팎이면 대부분 충분하다. 정해진 숫자는 아니고 경험칙이다.
사람 대신 부서를 적는다. 열 제목이 부서 이름이어도 되지만, A 칸은 그 부서의 누구인지까지 정한다. 부서 전체가 A이면 실제로는 아무도 A가 아니다.
모든 칸을 채운다. 빠지면 서운할까 봐 모두에게 C나 I를 주면, 정작 꼭 물어야 할 사람이 묻힌다.
만들고 다시 보지 않는다. 착수할 때 한 번 만들고 서랍에 넣어 둔 표는 몇 달 뒤 실제와 달라져 있기 쉽다.

AI 에이전트가 일을 맡을 때

AI 에이전트가 초안 작성이나 테스트 실행 같은 일을 맡으면, 표에 에이전트 열을 따로 두고 R 칸에 적을 수 있다. 이때도 A 칸에는 사람을 적는다. 결과가 됐는지 안 됐는지를 답하고 고칠지 정하는 일은 사람이 하기 때문이다. 에이전트의 결과를 확인하는 사람이 A와 다르면, 그 사람을 같은 줄에 R로 함께 적어 둔다. 에이전트가 담당자가 될 때의 책임 문제는 「Jira 업무 항목의 담당자가 AI 에이전트일 때, 책임은 누구에게 남는가」 글에서 따로 다뤘다.

이번 주에 할 일

진행 중인 프로젝트의 주요 인도물과 결정을 적는다. 처음에는 열 줄 안팎으로 시작한다.
줄마다 「누가 하나」와 「잘못되면 누구에게 묻나」를 물어 R과 A를 먼저 채운다. C와 I는 그 뒤에 채운다.
가로와 세로로 한 번씩 읽고, 이름이 적힌 사람들에게 보여 준다.

역할을 처음 정하는 회의의 안건은 「프로젝트 킥오프 미팅 안건과 준비물」 글에서, 일을 어떤 단위로 나눌지는 「WBS 작성법」 글에서 이어서 볼 수 있다.

참고

PMBOK® 지침서 8판 한국어판, 지침서 편 섹션 5 도구 및 기법의 책임배정매트릭스, 그림 5-21 RACI 매트릭스 샘플. 용어와 개념을 따랐고 문장은 옮기지 않았다. 한 일에 책임지는 사람을 한 사람으로 둔다는 것, 사람 대신 그룹으로 적을 수 있다는 것은 이 절의 개념이다.
R과 A를 구분하는 기준 세 가지, 확인하는 순서, 자주 하는 실수는 실무 경험칙을 이 글에서 새로 정리한 것이다. 표준이 아니라 한 가지 방법이다.
예의 회사, 프로젝트, 표는 모두 가상의 것이다.
PMI와 PMBOK은 Project Management Institute의 등록 상표입니다.