RABSIC 실전 적용법
이론은 알겠는데, 실제로 어떻게 쓰나요?
이 문서는 RABSIC을 실전에서 적용하는 구체적인 방법을 설명합니다.
1단계: RABSIC이 필요한지 판단
모든 일에 RABSIC을 쓸 필요는 없습니다.
RABSIC이 필요한 경우
- ✅ 여러 팀이 관여하는 프로젝트
- ✅ 중요한 의사결정 (예산, 전략, 채용)
- ✅ 반복되는 프로세스 (SOP 문서화)
- ✅ 책임 소재가 나중에 문제될 수 있는 일
RABSIC이 불필요한 경우
- ❌ 나 혼자 하는 작은 일
- ❌ 5분 안에 끝나는 단순 작업
- ❌ 명백하게 책임이 분명한 일상 업무
판단 기준: "나중에 '누가 책임자였죠?'라는 질문이 나올 것 같으면" → RABSIC 사용
2단계: R과 A 먼저 정하기
RABSIC의 핵심은 R(실행자)과 A(책임자)입니다. 이 둘부터 정하세요.
R (실행자) 정하는 법
질문: "실제로 이 일을 손으로 하는 사람은 누구인가?"
``` 예시: 신제품 디자인 → R: 디자이너 (디자인을 그리는 사람)
예시: 고객 클레임 응대 → R: CS 담당자 (고객과 대화하는 사람)
예시: 서버 배포 → R: 백엔드 개발자 (배포 스크립트를 실행하는 사람) ```
팁: 관리자나 팀장을 R로 지정하지 마세요. 실무자를 R로 지정하세요.
A (책임자) 정하는 법
질문: "이 일의 결과에 대해 조직에 설명할 책임이 있는 사람은 누구인가?"
``` 예시: 신제품 디자인 → A: 브랜드 오퍼레이션 팀장 (최종 승인권)
예시: 고객 클레임 응대 → A: 브랜드 오퍼레이션 팀장 (환불/교환 권한)
예시: 서버 배포 → A: 기술 팀장 (프로덕션 배포 승인권) ```
핵심 규칙: A는 정확히 1명
``` ❌ 잘못된 예: A: CTO, CEO → 누가 진짜 책임자?
✅ 올바른 예: A: CTO I: CEO → CTO가 책임지고, CEO는 통보만 ```
3단계: B, S, I, C 추가하기
R과 A를 정했으면, 필요에 따라 나머지 역할을 추가합니다.
B (백업) - "R이 없으면?"
질문: "R이 휴가 가거나 퇴사하면 누가 대신하나?"
``` 예시: 주 CS 담당자가 휴가 → B: 다른 CS 담당자
예시: 메인 디자이너 병가 → B: 다른 디자이너 ```
언제 필요: 작은 팀, 단일 담당자 의존도가 높은 업무
S (지원) - "누가 도와주나?"
질문: "R이 일을 완수하는 데 누가 도움을 주나?"
``` 예시: 디자이너가 디자인 작업 → S: 시니어 디자이너 (리뷰), 개발자 (구현 가능성 검토)
예시: 백엔드 개발자가 API 개발 → S: 프론트엔드 개발자 (API 스펙 협의), QA (테스트) ```
언제 필요: 협업이 많은 복잡한 작업
I (통보) - "누가 알아야 하나?"
질문: "결과가 나온 후, 누구에게 알려야 하나?"
``` 예시: 신제품 디자인 완료 → I: CEO, 전체 팀, 마케팅 팀
예시: 서버 배포 완료 → I: 전체 개발팀, 운영팀, CS팀 ```
언제 필요: 결과가 다른 팀에 영향을 주는 경우
C (자문) - "누구에게 물어봐야 하나?"
질문: "결정하기 전에 누구의 의견을 들어야 하나?"
``` 예시: 신제품 디자인 결정 전 → C: CEO (브랜드 방향), 생산팀 (생산 가능성)
예시: 기술 스택 선택 전 → C: 시니어 개발자 (기술 자문), 보안팀 (보안 리스크) ```
언제 필요: 전문성이나 승인이 필요한 중요한 결정
4단계: 타이밍 확인
RABSIC 역할은 타이밍이 중요합니다.
``` [시작] ↓
- C에게 자문 (결정 전) ↓
- A가 결정 ↓
- R이 실행 (S가 지원, B는 대기) ↓
- A가 승인 ↓
- I에게 통보 (결정 후) ↓ [완료] ```
자주하는 실수
❌ I를 회의에 부름 → I는 결과만 통보받으면 됩니다. 회의 참석 불필요.
❌ C에게 자문 안 하고 결정 후 통보 → C: "왜 안 물어봤어요?" 불만 발생
❌ I에게 사전 자문 요청 → I: "결정에 참여하고 싶어요" 불만 발생
✅ 올바른 순서:
- C에게 먼저 물어봄
- A가 결정
- I에게 결과 통보
실전 예시
예시 1: 새로운 제품 라인 출시
상황: 신규 제품 라인을 기획하고 출시해야 합니다.
RABSIC 할당
- R: 브랜드 오퍼레이션 팀 (제품 기획 및 실행)
- A: CEO (최종 승인 및 책임)
- B: 없음 (팀 단위 작업이라 백업 불필요)
- S: 아틀리에 팀 (생산 지원), 마케팅 팀 (홍보 지원)
- I: 전체 팀 (출시 결과 공유)
- C: 재무팀 (예산 검토), 생산팀 (생산 가능성)
실행 흐름
-
자문 (C)
- 재무팀에게 예산 검토 요청
- 생산팀에게 생산 가능성 확인
-
결정 (A)
- CEO가 제품 라인 승인
-
실행 (R, S)
- 브랜드 오퍼레이션 팀이 제품 기획
- 아틀리에 팀이 생산
- 마케팅 팀이 홍보
-
승인 (A)
- CEO가 최종 제품 승인
-
통보 (I)
- 전체 팀에 출시 공지
예시 2: 긴급 서버 장애 대응
상황: 프로덕션 서버가 다운되었습니다.
RABSIC 할당
- R: 백엔드 개발자 (서버 복구)
- A: 기술 팀장 (복구 전략 승인 및 책임)
- B: 다른 백엔드 개발자 (주 담당자 부재 시)
- S: 인프라 팀 (서버 로그 제공), QA (복구 후 테스트)
- I: CEO, 전체 개발팀, CS팀 (장애 상황 및 복구 알림)
- C: 시니어 개발자 (복구 방법 자문)
실행 흐름
-
긴급 자문 (C)
- 시니어 개발자에게 빠른 자문 (5분 이내)
-
긴급 결정 (A)
- 기술 팀장이 복구 방법 승인
-
긴급 실행 (R, S)
- 백엔드 개발자가 서버 복구
- 인프라 팀이 로그 제공
- QA가 복구 확인
-
승인 (A)
- 기술 팀장이 복구 확인
-
통보 (I)
- CEO, 개발팀, CS팀에 복구 완료 알림
참고: 긴급 상황에서는 C 단계를 짧게 가져갑니다 (5-10분).
예시 3: 고객 클레임 처리
상황: 심각한 제품 불량 클레임이 접수되었습니다.
RABSIC 할당
- R: CS 담당자 (고객 응대 및 처리)
- A: 브랜드 오퍼레이션 팀장 (환불/교환 승인)
- B: 다른 CS 담당자 (주 담당자 부재 시)
- S: 생산팀 (불량 원인 분석), 물류팀 (교환 배송)
- I: CEO (클레임 보고)
- C: 품질 관리팀 (불량 판정)
실행 흐름
-
자문 (C)
- 품질 관리팀에게 불량 여부 확인
-
결정 (A)
- 브랜드 오퍼레이션 팀장이 환불/교환 결정
-
실행 (R, S)
- CS 담당자가 고객 응대
- 생산팀이 원인 분석
- 물류팀이 교환 배송
-
승인 (A)
- 브랜드 오퍼레이션 팀장이 처리 결과 확인
-
통보 (I)
- CEO에게 클레임 처리 보고
Value Stream과 RABSIC 연동
킨도프는 모든 업무를 Value Stream (가치 흐름)으로 정의합니다.
Value Stream은 "Input → Output"으로 이어지는 가치 생성 경로입니다.
Value Stream 예시
``` B2C Value Stream: 고객 주문 → 디자인 → 생산 → 배송 → 피드백
B2B Value Stream: 파트너 요청 → 제안 → 협의 → 납품 → 정산 ```
RABSIC 자동 추천
각 Value Stream에는 기본 RABSIC이 정의되어 있습니다.
예시: B2C 주문 처리
``` Task: 고객 주문 접수
Value Stream: B2C Value Stream 조회 → 자동 추천: R: CS 담당자 A: 브랜드 오퍼레이션 팀장 S: 생산팀 I: CEO ```
이렇게 하면 매번 RABSIC을 처음부터 정할 필요가 없습니다.
자세한 내용은 Value Stream 운영 가이드를 참고하세요.
Position vs Person
RABSIC에서는 가능하면 Position (역할/직책)을 사용하고, 개인 이름은 보조로만 씁니다.
왜?
사람은 바뀌지만, 역할은 유지되기 때문입니다.
``` ❌ 잘못된 예: R: 김철수
✅ 올바른 예: R: 브랜드 오퍼레이션 디자이너 (현재: 김철수) ```
언제 Person을 써도 되나?
- 일회성 작업
- 외부 파트너/프리랜서
- Position이 아직 정의되지 않은 경우
안티 패턴 (하지 말아야 할 것)
❌ 1. 모든 결정의 A를 같은 사람으로
``` 잘못된 예: 모든 작업의 A: CEO
문제:
- CEO가 병목
- 실제 책임자가 누군지 모호 ```
❌ 2. R을 관리자로 지정
``` 잘못된 예: R: 팀장
문제:
- 실무자와 책임자가 달라서 혼란 ```
❌ 3. B/S/I/C를 전혀 안 씀
``` 잘못된 예: R: 개발자 A: 팀장
문제:
- 협업 구조가 안 보임
- 누구한테 도움 요청해야 하는지 모름 ```
❌ 4. I를 회의에 부름
``` 잘못된 예: "I 역할인데 왜 회의에 와야 하나요?"
올바른 예: I는 결과만 통보받으면 됨. 회의 불필요. ```
❌ 5. C에게 자문 안 하고 결정 후 통보
``` 잘못된 예: 결정 후 → C에게 "이렇게 했어요"
올바른 예: 결정 전 → C에게 "어떻게 생각하세요?" ```
체크리스트
RABSIC을 제대로 적용했는지 확인하세요:
- R (실행자)가 지정되어 있나?
- A (책임자)가 정확히 1명인가?
- A가 실제로 승인권을 가진 사람인가?
- R이 실무자인가? (관리자가 아닌가?)
- B (백업)가 필요한 경우 지정했나?
- S (지원)가 필요한 경우 지정했나?
- I (통보)가 결정 후 통보받는가?
- C (자문)이 결정 전 의견을 제시하는가?
- Position 우선으로 지정했나?
관련 문서:
이전: RABSIC 개요