RACI 모델: 역할과 책임을 명확하게 나누기
[RACI 모델 - 초심자 해설]
RACI는 프로젝트에서 누가 실행하고, 누가 최종 결정하며, 누구와 협의하고, 누구에게 결과를 공유할지 정리하는 역할 분담 프레임워크입니다.
이번 문서에서 주목할 포인트 몇 가지를 짚어 보겠습니다.
포인트 1. RACI는 업무의 담당자를 정하는 표입니다
여러 사람이 함께 일하다 보면 "그래서 누가 하는 일인가?", "누가 최종 결정하는가?"가 모호해지는 순간이 생깁니다. 담당자가 여러 명이라 아무도 먼저 움직이지 않거나, 결정권자가 분명하지 않아 승인이 계속 미뤄지기도 합니다. 반대로 모든 사람을 회의에 불러 같은 내용을 반복해서 공유하는 일도 생깁니다.
RACI는 이런 문제를 줄이기 위해 업무마다 네 가지 역할을 표시합니다.
| 구분 | 의미 | 핵심 질문 |
|---|---|---|
| R — Responsible | 실제로 업무를 수행하고 결과물을 만드는 사람 | 누가 이 일을 실행하는가? |
| A — Accountable | 결과에 최종 책임을 지고 의사결정하거나 승인하는 사람 | 누가 최종 결정을 내리는가? |
| C — Consulted | 전문 지식이나 이해관계를 바탕으로 의견을 제공하는 사람 | 실행이나 결정 전에 누구와 협의해야 하는가? |
| I — Informed | 진행 상황이나 결과를 공유받는 사람 | 누구에게 진행 상황이나 결과를 알려야 하는가? |
보통 업무 항목을 행(row), 사람이나 역할을 열(column)에 배치한 뒤 각 칸에 R, A, C, I를 표시합니다. 이 표를 RACI 매트릭스라고 부릅니다.
RACI는 조직도를 다시 만드는 도구가 아닙니다. 조직도는 보고 관계를 보여 주지만, RACI는 특정 업무의 실행 책임, 결정 권한, 커뮤니케이션 방식을 보여 줍니다. 같은 사람이라도 업무에 따라 R이 될 수도 있고 C나 I가 될 수도 있습니다.
포인트 2. Responsible과 Accountable은 다릅니다
R과 A는 번역하면 모두 "책임자"처럼 보여 가장 많이 혼동하는 개념입니다. 간단히 구분하면 R은 직접 하는 사람, A는 최종 결과에 답하는 사람입니다.
예를 들어 개발자가 기능을 구현하고 PO가 출시 여부를 승인한다고 해 보겠습니다. 코드를 작성하고 테스트하는 개발팀은 R이고, 우선순위와 인수 조건을 결정하며 결과를 승인하는 PO는 A입니다. A가 모든 실무를 직접 수행해야 한다는 뜻은 아닙니다.
R은 한 명 이상이 될 수 있습니다. 프론트엔드 개발자와 백엔드 개발자가 함께 기능을 구현한다면 둘 다 R이 될 수 있습니다. 다만 R이 지나치게 많으면 오히려 실행 책임이 흐려질 수 있으므로, 누가 어떤 결과물을 맡는지 더 작은 업무 단위로 나누는 편이 좋습니다.
반면 A는 업무마다 항상 한 명만 두는 것이 핵심입니다. A가 두 명 이상이면 의견이 다를 때 최종 결정을 누가 내리는지 다시 모호해집니다. 작은 팀에서는 한 사람이 A와 R을 함께 맡아 직접 실행하고 최종 결정할 수도 있습니다.
포인트 3. Consulted와 Informed는 소통의 방향이 다릅니다
C와 I의 차이는 단순히 "관련된 사람"과 "덜 관련된 사람"의 차이가 아닙니다. 핵심은 커뮤니케이션의 방향과 시점입니다.
C는 의사결정이나 실행 전에 의견을 들어야 하는 사람입니다. 개발팀이 결제 기능을 설계할 때 보안 담당자에게 규정과 위험 요소를 확인하는 과정처럼 양방향 커뮤니케이션이 필요합니다. C의 의견을 반드시 그대로 따라야 한다는 뜻은 아니지만, 적어도 결정을 내리기 전에 의견을 들을 기회는 제공해야 합니다.
I는 결정이나 진행 상황을 공유받으면 되는 사람입니다. 주로 단방향 커뮤니케이션이며, 매번 회의에 참여할 필요는 없습니다. 슬랙 알림, 프로젝트 대시보드, 스프린트 리뷰, 릴리스 노트 등으로 충분히 정보를 제공할 수 있습니다.
모든 이해관계자를 C로 지정하면 협의 비용이 커지고 의사결정이 느려집니다. 단순히 결과를 알아야 하는 사람이라면 I가 더 적합합니다. 반대로 사전에 의견을 반영해야 하는 사람을 I로만 두면 중요한 요구사항이나 위험을 뒤늦게 발견할 수 있습니다.
포인트 4. 애자일 조직에서는 역할을 고정하는 규칙이 아닙니다
애자일 조직에서 RACI를 사용하면 팀의 자율성을 제한한다고 생각할 수 있습니다. 하지만 RACI의 목적은 직무의 경계를 단단하게 고정하는 것이 아니라, 특정 업무에서 책임과 의사결정의 경계를 분명하게 만드는 것입니다.
일반적인 제품 개발 상황은 다음과 같이 정리할 수 있습니다.
- 개발팀은 기능을 설계, 구현, 테스트하는 R을 맡습니다.
- PO(Product Owner)는 우선순위와 인수 조건을 결정하고 결과를 승인하는 A를 맡습니다.
- 고객, 비즈니스 담당자, 보안 담당자 등의 이해관계자(Stakeholder)는 필요한 의견을 제공하는 C가 됩니다.
- 관련 조직과 경영진은 진행 상황과 결과를 공유받는 I가 됩니다.
여기서 중요한 점은 실제 권한 구조를 반영해야 한다는 것입니다. 모든 업무의 A를 무조건 PO로 지정하는 것은 올바른 사용법이 아닙니다. 예를 들어 보안 담당자가 보안 승인의 최종 결정권을 가진 조직이라면 보안 검토 업무의 A는 보안 담당자가 되어야 합니다.
또한 애자일 팀의 스프린트 보드가 "누가 어떤 태스크를 진행하는지" 보여 준다면, RACI는 "누가 최종 결정하고 누구의 의견을 미리 들어야 하는지"를 보완합니다. 두 도구는 서로 대체 관계라기보다 다루는 질문이 다릅니다.
포인트 5. 신규 결제 기능으로 보는 실제 예시
신규 결제 기능을 출시하는 프로젝트를 예로 들어 보겠습니다.
| 업무 | 개발팀 | PO | 보안 담당자 | 고객 지원팀 | 경영진 |
|---|---|---|---|---|---|
| 요구사항과 인수 조건 확정 | C | A/R | C | C | I |
| 기능 설계 및 구현 | R | A | C | I | I |
| 보안 검토 및 승인 | R | C | A | I | I |
| 출시 여부 결정 | C | A/R | C | C | I |
| 출시 결과 공유 | R | A | I | I | I |
첫 번째 업무에서는 PO가 요구사항을 직접 작성하고 최종 확정하므로 A와 R을 함께 맡습니다. 개발팀, 보안 담당자, 고객 지원팀은 구현 가능성, 보안 위험, 예상 고객 문의에 관해 의견을 제공하므로 C입니다.
기능 설계와 구현에서는 개발팀이 R입니다. PO는 결과가 인수 조건을 충족하는지 최종 책임을 지므로 A이고, 보안 담당자는 구현 전에 검토 의견을 제공하므로 C입니다.
보안 검토 및 승인은 보안 담당자가 최종 승인 권한을 가진 조직이라고 가정했습니다. 따라서 개발팀은 검토에 필요한 수정 작업을 수행하는 R, 보안 담당자는 승인 결과에 책임지는 A가 됩니다. 이처럼 같은 사람이나 팀도 업무가 달라지면 RACI 역할이 달라집니다.
마지막으로 경영진은 모든 과정에 참여하지 않고 결과를 공유받는 I입니다. 진행 상황은 대시보드로, 출시 결과는 릴리스 보고로 전달하면 불필요한 회의를 줄이면서도 투명성을 유지할 수 있습니다.
포인트 6. 표를 만드는 것보다 합의하는 과정이 중요합니다
RACI 표는 다음 순서로 작성하면 됩니다.
- 프로젝트 전체가 아니라 의사결정이나 산출물이 분명한 업무 단위로 나눕니다.
- 개인 이름보다 PO, 개발팀, 보안 담당자처럼 역할을 기준으로 열을 만듭니다.
- 각 업무를 실제로 수행할 R을 지정합니다.
- 최종 결정권자 A를 반드시 한 명만 지정합니다.
- 업무 전에 의견이 필요한 C와 결과만 공유받으면 되는 I를 구분합니다.
- 관련자들과 역할과 권한이 현실에 맞는지 합의합니다.
표만 작성해서 공유하면 실제 업무에서는 작동하지 않을 수 있습니다. A로 적힌 사람에게 실제 승인 권한이 있는지, R이 업무를 수행할 역량과 시간을 확보했는지, C가 언제 어떤 방식으로 의견을 줄 것인지까지 확인해야 합니다.
프로젝트 시작 시 한 번 만들고 끝내는 문서도 아닙니다. 팀 구성, 프로젝트 범위, 의사결정 권한이 바뀌면 RACI도 함께 갱신해야 합니다.
포인트 7. 좋은 RACI는 칸이 많은 표가 아닙니다
RACI를 세밀하게 작성하려다 보면 모든 칸을 채우고 싶은 유혹이 생깁니다. 하지만 관련이 없는 사람의 칸은 비워 두어도 됩니다. 중요한 것은 표의 완성도가 아니라, 실행과 결정에 필요한 관계가 명확한지입니다.
실무에서는 다음 기준으로 점검할 수 있습니다.
- 모든 업무에 최소 한 명의 R이 있는가?
- 모든 업무에 A가 정확히 한 명 있는가?
- R이 너무 많아 실제 담당자가 모호하지 않은가?
- A에게 실제 최종 결정 권한이 있는가?
- C가 너무 많아 모든 결정이 합의제로 변하지 않았는가?
- I에게 전달할 정보와 공유 채널이 정해져 있는가?
- "프로젝트 성공"처럼 너무 큰 업무 대신 결과를 확인할 수 있는 단위로 나누었는가?
결국 RACI의 목적은 실패했을 때 비난할 사람을 정하는 것이 아닙니다. 일을 시작하기 전에 누가 실행하고, 누가 결정하며, 누구의 의견을 듣고, 누구에게 알려야 하는지 합의하는 것이 핵심입니다.
포인트 8. 기술적 분석 에이전트 제품에 적용해 보기
기술적 분석을 이용해 사용자의 투자 의사결정을 돕는 에이전트 제품을 만든다고 가정해 보겠습니다. 이 제품은 가격과 거래량 데이터를 분석하고, 이동평균선이나 RSI와 같은 지표를 계산해 시장 상태와 참고 신호를 설명합니다.
이 제품에서는 단순히 기능을 구현하는 것만으로 출시할 수 없습니다. 어떤 분석을 제공할지 정하고, 데이터와 계산의 정확성을 검증하고, 과거 데이터로 성능을 평가하고, 사용자가 결과를 투자 권유로 오해하지 않도록 위험 표현도 검토해야 합니다. 따라서 개발팀과 PO뿐 아니라 기술적 분석 전문가, 리스크·컴플라이언스 담당자의 역할도 필요합니다.
| 업무 | 개발팀 | PO | 기술적 분석 전문가 | 리스크·컴플라이언스 | 경영진·상위 리더 |
|---|---|---|---|---|---|
| 제품 범위와 사용자 가치 정의 | C | A/R | C | C | I |
| 기술적 지표와 분석 규칙 설계 | C | A | R | C | I |
| 데이터 파이프라인과 에이전트 구현 | R | A | C | C | I |
| 백테스트와 분석 결과 평가 | R | A | R | C | I |
| 위험 문구와 규제 요건 검토 | R | C | C | A/R | I |
| 출시 여부 결정 | C | A/R | C | C | I |
| 출시 후 품질과 이상 신호 모니터링 | R | A | C | C | I |
제품 범위 정의에서는 PO가 A와 R을 함께 맡습니다. "매수·매도 지시가 아니라 의사결정에 참고할 분석 근거를 제공한다"와 같은 제품 경계를 정하고, 어떤 사용자 문제를 해결할지 최종 결정하기 때문입니다. 개발팀은 구현 가능성, 분석 전문가는 지표의 타당성, 리스크·컴플라이언스 담당자는 표현과 규제 위험에 관해 의견을 제공하는 C가 됩니다.
기술적 지표와 분석 규칙을 설계할 때는 분석 전문가가 R입니다. 예를 들어 RSI 과매수 기준, 이동평균선 배열, 거래량 변화 등을 어떤 방식으로 해석할지 정의합니다. PO는 이 분석이 제품 목적과 사용자 경험에 부합하는지 최종 책임지는 A가 되고, 개발팀은 데이터와 구현 제약을 설명하는 C가 됩니다.
구현 단계에서는 개발팀이 R입니다. 시세 데이터 수집, 지표 계산, 에이전트 프롬프트, 근거 표시, 오류 처리 등을 개발합니다. PO는 인수 조건과 출시 가능한 품질 수준에 책임지는 A이고, 분석 전문가와 리스크 담당자는 계산 결과와 표현 방식을 검토하는 C입니다.
백테스트에서는 개발팀과 분석 전문가가 함께 R이 될 수 있습니다. 개발팀은 재현 가능한 평가 파이프라인을 만들고, 분석 전문가는 결과를 해석합니다. 이때 높은 과거 수익률만 보는 것이 아니라 거래 비용, 과최적화, 미래 정보 사용 여부, 상승장 편향 등을 함께 확인해야 합니다.
위험 문구와 규제 요건 검토에서는 리스크·컴플라이언스 담당자가 A가 됩니다. 검토 과정에서 발견된 표시나 기능 문제를 개발팀이 수정하므로 개발팀은 R입니다. 이처럼 모든 업무의 A가 PO일 필요는 없으며, 실제 최종 승인 권한을 가진 역할을 반영해야 합니다.
경영진이나 상위 리더는 진행률, 주요 위험, 출시 결과를 대시보드나 정기 보고로 공유받는다면 I입니다. 다만 별도의 예산 승인이나 전략적 출시 승인 업무가 있다면 그 업무에서는 경영진이 A가 될 수 있습니다.
마지막으로 에이전트 자체를 R이나 A로 지정하지 않는 것이 중요합니다. 에이전트는 분석 결과를 생성하는 도구이지 결과에 책임을 질 수 있는 조직 구성원이 아닙니다. 제품 조직은 분석 결과의 품질과 안전장치에 책임을 지고, 사용자는 제공된 정보를 참고해 자신의 최종 투자 여부를 결정합니다. 만약 제품이 참고 정보 제공을 넘어 주문까지 자동으로 실행한다면, 거래 승인과 손실 통제, 규제 준수에 대한 별도의 RACI를 설계해야 합니다.