역할 책임 분장표
| 작업 | 기획 | 디자인 | 아키텍트 | UI/UX | FE | BE | 보안 | QA | |------|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:| | PRD · User Story 작성 | **A/R*
reference docs/reference/01-raci-matrix.md
R=Responsible (실제 수행) · A=Accountable (최종 책임, 1인) · C=Consulted (협의) · I=Informed (통보)
원칙: A는 항상 1명, R은 여러 명 가능, 공란은 관여 없음
8-역할 기준 (기획 · 디자인 · 아키텍트 · UI/UX 개발 · FE · BE · 보안 · QA)
📋 기획 활동
| 작업 |
기획 |
디자인 |
아키텍트 |
UI/UX |
FE |
BE |
보안 |
QA |
| PRD · User Story 작성 |
A/R |
C |
C |
|
I |
I |
|
C |
| 지표 · KPI 정의 |
A/R |
|
C |
|
I |
I |
|
C |
| 유저 리서치 · 인터뷰 |
A/R |
C |
|
|
|
|
|
|
| 로드맵 · 우선순위 |
A/R |
C |
C |
|
I |
I |
|
I |
| A/B 테스트 설계 |
A/R |
C |
C |
C |
R |
C |
|
C |
| 릴리스 노트 · 공지 |
A/R |
C |
|
|
I |
I |
|
I |
🎨 디자인 활동
| 작업 |
기획 |
디자인 |
아키텍트 |
UI/UX |
FE |
BE |
보안 |
QA |
| 디자인 시스템 · 토큰 |
C |
A/R |
|
C |
|
|
|
|
| 비주얼 디자인 |
C |
A/R |
|
C |
|
|
|
|
| 인터랙션 · 모션 |
C |
A/R |
|
C |
|
|
|
I |
| 접근성 디자인 |
I |
A/R |
|
C |
|
|
|
C |
| 프로토타입 · UT |
R |
A/R |
|
|
|
|
|
|
| Figma 핸드오프 |
I |
A/R |
|
C |
|
|
|
|
📐 아키텍처
| 작업 |
아키텍트 |
UI/UX |
FE |
BE |
보안 |
QA |
| 비즈니스 도메인 모델링 |
A/R |
C |
C |
C |
I |
I |
| NFR 정의 (성능·가용성·확장성) |
A/R |
|
C |
C |
C |
C |
| 기술 스택 선정 |
A/R |
I |
C |
C |
C |
I |
| 렌더링 전략 (SSR/CSR/SSG) |
A |
C |
R |
C |
I |
I |
| 시스템 경계 · 서비스 분리 |
A/R |
I |
C |
C |
C |
I |
| ADR / DECISIONS.md |
A |
C |
C |
C |
C |
I |
| R0/R1/R2 작업 분류 정책 |
A/R |
C |
C |
C |
C |
C |
🎨 디자인 · UX
| 작업 |
아키텍트 |
UI/UX |
FE |
BE |
보안 |
QA |
| 페르소나 · 유저 저니맵 |
I |
A/R |
C |
I |
|
I |
| 정보 구조 · 내비게이션 |
I |
A/R |
C |
|
|
I |
| 디자인 시스템 구축 |
|
A/R |
R |
|
|
|
| 디자인 토큰 정의 |
|
A/R |
C |
|
|
|
| 토큰 → 코드 변환 |
|
C |
A/R |
|
|
I |
| 인터랙션 · 모션 스펙 |
|
A/R |
C |
|
|
I |
| 접근성 디자인 (색대비·포커스) |
|
A/R |
C |
|
|
C |
| 빈 상태 · 에러 상태 UI |
|
A/R |
R |
|
|
I |
💻 프론트엔드
| 작업 |
아키텍트 |
UI/UX |
FE |
BE |
보안 |
QA |
| 프로젝트 초기 셋업 |
C |
|
A/R |
|
C |
|
| 컴포넌트 구현 |
|
C |
A/R |
|
|
I |
| 상태 관리 구조 설계 |
C |
|
A/R |
C |
|
|
| API 연동 · 에러 핸들링 |
I |
|
A/R |
C |
I |
I |
| 타입 안정성 (strict, zod) |
|
|
A/R |
|
|
|
| 성능 최적화 (번들·렌더링) |
C |
|
A/R |
|
|
I |
| 접근성 코드 구현 |
|
C |
A/R |
|
|
C |
| i18n 구현 |
|
C |
A/R |
C |
|
I |
| Storybook 관리 |
|
C |
A/R |
|
|
I |
🔧 백엔드
| 작업 |
아키텍트 |
UI/UX |
FE |
BE |
보안 |
QA |
| API 계약 설계 (OpenAPI/GraphQL) |
C |
|
C |
A/R |
I |
I |
| DB 스키마 · 인덱스 전략 |
C |
|
|
A/R |
I |
|
| 마이그레이션 절차 |
C |
|
I |
A/R |
C |
I |
| 캐싱 전략 (Redis/CDN) |
C |
|
C |
A/R |
|
|
| 비동기 작업 큐 · 스케줄링 |
C |
|
|
A/R |
|
I |
| 관측성 (로깅·트레이싱·메트릭) |
C |
|
I |
A/R |
C |
I |
| RAG · LLM 통합 (해당 시) |
C |
|
C |
A/R |
C |
I |
🛡️ 보안
| 작업 |
아키텍트 |
UI/UX |
FE |
BE |
보안 |
QA |
| 시크릿 관리 정책 |
C |
|
I |
R |
A/R |
|
| 인증 · 인가 설계 |
C |
|
C |
R |
A/R |
I |
| OWASP Top 10 대응 |
I |
|
R |
R |
A/R |
C |
| 의존성 취약점 스캔 |
|
|
R |
R |
A/R |
I |
| 보안 헤더 (CSP · HSTS · SRI) |
I |
|
R |
R |
A/R |
I |
| 접근 로그 · 감사 로그 |
C |
|
|
R |
A/R |
I |
| 침투 테스트 · 보안 감사 |
I |
|
C |
C |
A/R |
C |
| 컴플라이언스 (ISMS-P · GDPR) |
C |
|
|
C |
A/R |
I |
🧪 QA · 테스트
| 작업 |
아키텍트 |
UI/UX |
FE |
BE |
보안 |
QA |
| 테스트 전략 수립 |
C |
|
C |
C |
|
A/R |
| 단위 테스트 작성 |
|
|
R (FE측) |
R (BE측) |
|
A |
| 통합 테스트 |
|
|
C |
R |
|
A/R |
| E2E 테스트 (Playwright/Cypress) |
|
C |
C |
I |
|
A/R |
| 성능 · 부하 테스트 |
C |
|
C |
C |
|
A/R |
| 접근성 자동 테스트 (axe) |
|
C |
C |
|
|
A/R |
| 시각 회귀 (Visual Regression) |
|
C |
C |
|
|
A/R |
| UAT · 릴리스 QA |
I |
I |
I |
I |
I |
A/R |
| 버그 트리아지 · RCA |
C |
|
R |
R |
C |
A/R |
🚀 배포 · 운영
| 작업 |
아키텍트 |
UI/UX |
FE |
BE |
보안 |
QA |
| CI/CD 파이프라인 |
A |
|
R |
R |
C |
C |
| 배포 전략 (Blue-Green · Canary) |
A/R |
|
C |
C |
C |
C |
| Feature Flag 운영 |
C |
|
A/R |
R |
|
C |
| 모니터링 · 알람 셋업 |
A |
|
I |
R |
C |
I |
| 롤백 리허설 |
C |
|
C |
C |
|
A/R |
| 릴리스 승인 |
A |
I |
I |
I |
C |
C |
| 인시던트 대응 |
A |
|
R |
R |
C |
I |
🤖 AI 거버넌스
| 작업 |
아키텍트 |
UI/UX |
FE |
BE |
보안 |
QA |
| CLAUDE.md · 프로젝트 룰 관리 |
A/R |
C |
C |
C |
C |
C |
| SEED.md · CONSTRAINTS.md |
A/R |
C |
C |
C |
C |
C |
| Guard 룰셋 정의 |
A |
|
C |
C |
R |
|
| AI 생성 코드 git diff 검증 |
|
|
A/R (FE측) |
A/R (BE측) |
|
C |
| R2 비가역 작업 휴먼 게이트 |
A |
|
R |
R |
C |
R |
| AI 활용 가이드 업데이트 |
A/R |
C |
C |
C |
C |
C |
⚖️ 사용 규칙
1. A(Accountable)는 반드시 1명
- 여러 명이 A면 결국 아무도 책임지지 않음
- R은 실제 수행하는 사람(여러 명 가능)
2. 조직 크기에 따라 열 병합
- 1~3인 팀: 아키텍트 = FE = BE 한 사람 → 해당 열 합치고 셀은 유지
- 5~10인 팀: UI/UX 가 겸직인 경우 많음 → 그대로 사용 권장
- 10인 이상: QA 가 기능별 QA + 릴리스 QA로 분리 가능
3. 스프린트 킥오프에서 활용
- 각 작업 카드에 R/A 태그를 달고 시작
- 회의에서 "A는 누구입니까?" 한 줄 확인하면 책임 공백 방지
4. 체크리스트와 연동
- RACI 는 "누가", 체크리스트는 "무엇을"
- 스프린트 레트로에서 "A 가 없었던 작업 = 공백 작업" 식별
⚠️ 자주 발생하는 RACI 안티패턴
| 패턴 |
증상 |
해법 |
| A가 너무 많음 |
모두가 "내 일"이라고 하지만 결정 안 됨 |
A는 1명으로 강제 |
| C가 너무 많음 |
회의 무한 반복, 의사결정 지연 |
C는 진짜 협의 필요한 역할만 |
| R 없는 A |
A가 직접 실행까지 떠안음 (병목) |
R을 명시적으로 지정 |
| I 누락 |
"나는 그런 변경 몰랐다" 사고 |
영향받는 역할은 모두 I 로 표시 |
| 전부 C |
아무도 책임 안 짐 |
R/A 명확화 |
💡 활용 팁
- 이 매트릭스 자체를
docs/raci.md 로 리포에 커밋하면, 신규 합류자가 15분 안에 "누구에게 물어볼지" 판단 가능
- 변경 시 ADR처럼 날짜 · 변경 사유 기록 권장
- Jira · Linear 커스텀 필드로
Accountable / Responsible 추가하면 티켓 단위 추적 가능