RABSIC 역할 정의
각 역할의 상세한 정의와 책임 범위를 설명합니다.
R - Responsible (실행자)
정의
실제로 일을 실행하는 사람. 손을 더럽히는 사람.
책임 범위
- 작업을 직접 수행
- 진행 상황을 A에게 보고
- 필요한 경우 S에게 도움 요청
- 완료 후 결과물을 A에게 제출
특징
- 복수 가능: 한 작업에 여러 명의 R이 있을 수 있음
- 하지만 그중 1명은 주 담당자로 지정하는 것이 좋음
예시
- 코드를 작성하는 개발자
- 디자인을 만드는 디자이너
- 고객 문의에 답변하는 CS 담당자
- 제품을 생산하는 아틀리에 팀
주의사항
❌ R을 관리자나 팀장으로 지정하지 마세요 → 실제로 일하는 사람이 R이어야 합니다
✅ R은 실무자 → 매니저는 A나 I로 지정
A - Accountable (책임자)
정의
최종 책임자. 승인권을 가진 사람. 결과에 대해 조직에 설명할 의무가 있는 사람.
책임 범위
- R의 결과물을 승인 또는 거부
- 문제 발생 시 최종 의사결정
- 조직에 결과 보고
- 필요한 리소스 확보
특징
- 정확히 1명: 모든 작업/결정은 단 1명의 A를 가짐
- 위임 불가: 책임은 위임할 수 없음 (실행은 위임 가능)
예시
- 프로젝트 오너
- 팀 리더
- 부서장
- 최종 승인권자
주의사항
❌ A가 여러 명이면 안 됩니다
잘못된 예:
A: CTO, CEO
→ 둘 중 누가 진짜 책임자?
올바른 예:
A: CTO
I: CEO
→ CTO가 책임지고, CEO는 통보만 받음
✅ A는 단 1명 → 명확한 책임 소재
B - Backup (백업)
정의
R(실행자)이 부재하거나 불가능할 때 대신하는 사람.
책임 범위
- R이 휴가, 병가, 퇴사 등으로 부재 시 대신 실행
- 평소에는 대기 상태
- R이 있을 때는 직접 개입하지 않음
특징
- 조건부 활성화: R이 없을 때만 작동
- 연속성 보장: 팀원 1-2명이 작은 조직에서 중요
예시
- 주 CS 담당자가 휴가일 때 대응하는 부 담당자
- 메인 디자이너가 병가일 때 대신하는 다른 디자이너
- 담당 개발자가 퇴사했을 때 인수인계받는 개발자
주의사항
❌ B를 일상적인 협업자로 사용하지 마세요 → 그건 S (Support)입니다
✅ B는 비상 대응용 → 평소엔 대기, 필요할 때만 활성화
S - Support (지원자)
정의
R이 일을 완수하는 데 도움을 주는 사람. 리소스, 전문성, 시간을 제공.
책임 범위
- R의 요청에 응답
- 전문 지식 제공
- 리소스나 도구 제공
- 장애물 제거
특징
- 적극적 협업: 일이 진행되는 동안 계속 관여
- 실행 공유: R과 함께 일의 일부를 분담할 수 있음
예시
- 디자이너의 작업을 리뷰하는 시니어 디자이너
- 개발자에게 API 명세를 제공하는 백엔드 팀
- 생산팀에게 원자재를 제공하는 구매팀
- R의 코드를 리뷰하는 동료
주의사항
❌ S와 C를 혼동하지 마세요
- S: 일이 진행되는 동안 계속 도와줌
- C: 결정하기 전에만 의견 제시
✅ S는 실행 단계의 파트너 → 프로젝트 내내 협업
I - Informed (통보 대상)
정의
결정이 완료된 후 통보받는 사람. 정보 수신자.
책임 범위
- 결과를 전달받음
- 필요시 질문
- 의사결정에 참여하지 않음
특징
- 일방향 소통: 결과 → I
- 수동적 역할: 알기만 하면 됨
예시
- 프로젝트 완료를 보고받는 CEO
- 새 제품 출시를 통보받는 다른 팀
- 의사결정 결과를 공유받는 전체 직원
- 시스템 변경을 알림받는 사용자
주의사항
❌ I를 회의에 부르지 마세요 → I는 결정 후 통보만 받으면 됩니다
✅ I에게는 이메일이나 메시지로 충분 → 회의 참석 불필요
C - Consulted (자문 대상)
정의
결정하기 전에 의견을 구하는 사람. 전문가, 이해관계자.
책임 범위
- 요청받으면 전문 의견 제공
- 대안 제시
- 리스크 지적
- 하지만 최종 결정은 A가 내림
특징
- 양방향 소통: 질문 ↔ 답변
- 결정 전 단계: 자문 → 결정 → 실행
예시
- 신제품 디자인에 대해 의견을 묻는 CEO
- 기술 스택 결정 시 자문하는 시니어 개발자
- 생산 가능성을 검토하는 아틀리에 팀
- 법률 리스크를 검토하는 법무팀
주의사항
❌ C의 의견을 무조건 따를 필요는 없습니다 → 자문일 뿐, 최종 결정은 A
✅ C의 의견을 경청하되, 결정은 A가 → 존중하지만 구속되지 않음
역할 간 타이밍
프로젝트 시작
↓
C에게 자문 (의견 수렴)
↓
A가 결정
↓
R이 실행 (S가 지원, B는 대기)
↓
A가 승인
↓
I에게 통보
역할 조합 예시
예시 1: 신제품 디자인
- R: 디자이너 (디자인 작성)
- A: 브랜드 오퍼레이션 팀장 (최종 승인)
- B: 다른 디자이너 (주 디자이너 부재 시)
- S: 아틀리에 팀 (생산 가능성 검토)
- I: CEO, 전체 팀 (결과 통보)
- C: CEO (디자인 방향 자문)
예시 2: 코드 배포
- R: 백엔드 개발자 (코드 작성 및 배포)
- A: 기술 팀장 (배포 승인)
- B: 다른 백엔드 개발자 (담당자 부재 시)
- S: QA 팀 (테스트 지원)
- I: 전체 개발팀, 운영팀 (배포 알림)
- C: 시니어 개발자 (아키텍처 리뷰)
예시 3: 마케팅 캠페인
- R: 마케팅 담당자 (캠페인 실행)
- A: 마케팅 팀장 (예산 및 전략 승인)
- B: 다른 마케팅 담당자 (휴가 시 대응)
- S: 디자이너 (이미지 제작 지원), 개발자 (랜딩 페이지)
- I: CEO, 영업팀 (결과 보고)
- C: 브랜드 팀 (브랜드 가이드라인 검토)
다음:
이전: RABSIC 개요