Skill/프로젝트 관리(PM)

[시리즈] 작은 팀이 흔들리지 않고 일하는 법: RACI 매트릭스로 "이거 누가 하기로 했죠?" 없애기 (실전 표 3개 포함)

hmgames / 2026. 6. 18. 09:21

1. 들어가며

 

"이거 누가 하기로 했죠?" 프로젝트를 하다 보면 꼭 한 번은 나오는 말입니다.

분명 다 같이 회의했는데, 막상 마감이 다가오면 어떤 일은 두 명이 겹쳐서 하고, 어떤 일은 아무도 안 하고 붕 떠 있습니다.

 

이건 누가 게을러서가 아니라, '누가 무엇을 책임지는지'를 명확히 정하지 않았기 때문입니다.

 

이번 시리즈에서는 작은 팀이 혼란 없이 일하는 두 가지 축을 다룹니다.

바로 R&R(누가 무엇을)과 Agile(어떻게)입니다.

 

그 첫 편으로, 오늘은 역할과 책임을 깔끔하게 정리하는 방법을 이야기해 보겠습니다.

 

2. R&R이 뭔가요?

 

R&R은 Role & Responsibilities, 즉 '역할과 책임'의 줄임말입니다.

 

누가 어떤 일을 맡고(역할), 그 결과까지 책임지는지(책임)를 정하는 것이죠.

말은 거창하지만, 핵심은 단순합니다. "이 일은 결국 누구 손에서 끝나는가?"를 분명히 하는 겁니다.

 

R&R이 흐릿하면 두 가지 사고가 납니다.

하나는 공백(아무도 안 맡은 일이 마감 직전에 발견됨), 다른 하나는 중복(두 사람이 같은 일을 따로 하다가 충돌).

 

둘 다 의욕의 문제가 아니라 구조의 문제입니다.

그래서 R&R을 정하는 건 누군가를 감시하려는 게 아니라, 모두가 안심하고 자기 일에 집중하게 만드는 장치입니다.

 

3. RACI: 역할을 4가지로 쪼개기

R&R을 체계적으로 정리하는 가장 유명한 도구가 RACI 매트릭스입니다.

이건 우리만 쓰는 동아리식 방법이 아니라, 국제 프로젝트 관리 표준(PMBOK)에 정식으로 실려 있는 기법이고, AWS는 조직 역할을 정의하는 가이드로 RACI를 공식 블로그에서 직접 소개할 만큼 실무에서 널리 쓰입니다.

 

모든 일을 네 가지 역할로 나누어 누구에게 붙일지 정하는 표입니다.

  • R (Responsible, 실행): 실제로 손을 움직여 그 일을 하는 사람. 여러 명일 수 있습니다.
  • A (Accountable, 최종 책임): 그 일의 성패를 최종적으로 책임지는 사람. 반드시 딱 한 명이어야 합니다.
  • C (Consulted, 자문): 일을 진행하기 전에 의견을 구하는 사람. 양방향으로 대화합니다.
  • I (Informed, 통보): 결과만 공유받으면 되는 사람. 한 방향으로 알려주면 됩니다.

여기서 가장 중요한 건 A는 무조건 한 명이라는 원칙입니다. 책임자가 둘이면 결국 아무도 책임지지 않는 상태가 되거든요.

 

흥미롭게도 아마존(Amazon)에도 이와 똑 닮은 원칙이 있습니다.

중요한 일마다 '단 한 명의 최종 책임자(Single-Threaded Owner)'를 둬서, 그 사람이 100% 그 일에 책임지게 하는 방식이죠.

 

규모는 달라도, 잘하는 조직일수록 "이건 네가 최종 책임이야"를 분명히 한다는 점은 똑같습니다.

 

📌 알아두면 좋은 것
RACI 말고 DACI(Driver·Approver·Contributor·Informed)라는 변형도 있습니다.
아틀라시안(Atlassian) 같은 회사가 의사결정에 쓰는 방식인데, RACI가 '일의 책임'을 정한다면 DACI는 '의사결정의 권한'을 정하는 데 강합니다.
큰 결정을 자주 내리는 팀이라면 참고할 만합니다.

 

4. 직접 적용해보기

R&R은 개발에만 쓰는 게 아니라 동아리의 모든 일에 적용할 수 있습니다.

실제 게임 개발 동아리에 있을 만한 세 가지 상황으로 예를 들어 보여드리겠습니다.

 

① 게임 개발 — '튜토리얼 제작'

업무(Task) 기획 개발 아트 팀장
튜토리얼 흐름 설계 A/R C C I
튜토리얼 구현 C A/R I I
튜토리얼 일러스트 I C A/R I
출시 일정 승인 C C C A

* R(실행), A(최종 책임), C(자문), I(통보)

 

② 행사 운영 — '신입 모집 설명회'

업무(Task) 운영 홍보 팀장
행사 기획·진행 A/R C I
홍보물 제작·배포 C A/R I
예산 집행 승인 C I A
장소 섭외 A/R I C

* R(실행), A(최종 책임), C(자문), I(통보)

 

 

 

③ 사업·제휴 — '외부 업체와 콜라보'

업무(Task) 대외협력 마케팅 팀장
제휴처 발굴·접촉 A/R C I
협업 콘텐츠 기획 C A/R I
계약 조건 최종 승인 C C A

* R(실행), A(최종 책임), C(자문), I(통보)

 

세 표 모두 공통점이 보이시나요?

각 일마다 '최종 책임자(A)'가 딱 한 명씩이고, 팀장은 대부분의 실무에선 통보(I)만 받되 예산·계약·일정 같은 큰 결정에서만 책임(A)을 집니다.

 

이렇게 정리해두면 "이거 누가 하기로 했죠?"라는 질문 자체가 사라집니다.

 

5. R&R 잘 잡는 노하우

  1. 일 단위로 쪼개서 붙이세요. '기획팀이 다 알아서'가 아니라 '튜토리얼 설계는 누구'처럼 구체적인 일에 사람을 매칭해야 공백이 안 생깁니다.
  2. A는 반드시 한 명으로. 둘 이상이면 그 칸은 다시 논의해야 한다는 신호입니다. 아마존도 지키는 원칙이라는 걸 기억하세요.
  3. 30분 회의로 시작하세요. 프로젝트 초반에 핵심 일들만 표로 정리하는 짧은 회의 한 번이면 충분합니다. 완벽할 필요 없이, 하면서 고쳐가면 됩니다.
  4. 역할은 사람이 아니라 일에 붙입니다. "쟤가 원래 그거 하던 사람이니까"가 아니라, 이번 프로젝트에서 그 일을 누가 맡는 게 맞는지로 정하세요.

 

6. 마무리

R&R은 누구를 옭아매는 규칙이 아니라, 서로 믿고 편하게 일하기 위한 합의입니다.

글로벌 기업부터 작은 동아리까지 똑같이 통하는 원리죠. 역할이 분명하면 불필요한 눈치 싸움과 책임 공방이 사라지고, 각자 자기 일에 집중할 수 있습니다.

 

거창하게 시작할 필요 없이, 다음 프로젝트 첫 회의에서 핵심 일 몇 개만 표로 정리해보세요.

그것만으로도 팀의 분위기가 달라집니다.

 

다음 편에서는 '그래서 이 역할들을 가지고 어떻게 함께 일할 것인가'를 다룹니다.

"애자일은 그냥 빠르게 하는 거 아니야?"라는 흔한 오해부터 깨고 시작하겠습니다.

 

 


참고 자료
- PMBOK Guide(RACI/책임 할당 매트릭스)
- AWS Public Sector Blog "Defining organizational roles with a RACI matrix"
- AWS Enterprise Strategy "Single-Threaded Leaders"
- Atlassian Team Playbook(DACI)