장애가 터졌습니다. 결제가 안 됩니다. 슬랙에 사람들이 모이는데 아무도 먼저 움직이지 않습니다. "이거 백엔드 문제예요?" "인프라 같은데요?" "PO님이 결정해 주셔야..." 10분이 그냥 흘러갑니다. 누가 무엇을 책임지는지, 이 상황의 최종 의사결정자가 누구인지 합의돼 있지 않으면, 역량이 충분해도 조직은 멈춥니다. 역할과 책임 경계를 아는 것은 조직도를 외우는 게 아니라 — "이 일은 누구에게"를 1초 안에 답하는 능력입니다.
- 1개발 조직의 주요 역할(PO/PM·FE·BE·QA·DevOps/SRE·디자이너·데이터)을 책임으로 구분할 수 있다
- 2역할 간 협업 인터페이스(FE↔BE는 API, 개발↔운영은 CI/CD)를 짚을 수 있다
- 3DevOps/SRE가 전통적 개발·운영 분리와 어떻게 다른지 설명할 수 있다
- 4RACI로 작업별 책임 주체를 명시해 역할 공백/중복을 없앨 수 있다
역할 지도 — 누가 무엇을
역할은 '직책'이 아니라 '책임'으로 본다
사람 수보다 역할이 많을 수도, 한 사람이 여러 역할을 겸할 수도 있습니다. 중요한 건 각 책임이 누구에게 있는가입니다.
| 역할 | 핵심 책임 | 주된 산출물/접점 |
|---|---|---|
| PO/PM | 무엇을 왜 만들지·우선순위·일정 | 백로그·PRD·로드맵 |
| 디자이너(UX/UI) | 사용자 경험·화면 | 와이어프레임·디자인 시스템 |
| 프론트엔드 | 화면 구현·상호작용 | UI 코드, API 호출 |
| 백엔드 | 데이터·로직·인증·연동 | API, DB 스키마 |
| QA | 품질 검증·테스트 | 테스트 케이스·결함 리포트 |
| DevOps/SRE/인프라 | 배포 자동화·안정성·운영 | CI/CD·IaC·모니터링·온콜 |
| 데이터(분석/엔지니어) | 지표·파이프라인 | 대시보드·ETL |
PM·인프라 관점: 하나의 기능이 흐르려면 **PO(무엇)→디자이너(어떻게 보이나)→FE/BE(구현)→QA(검증)→DevOps(배포·운영)**가 릴레이로 이어집니다. 한 칸이 비면 거기서 막힙니다.
협업 인터페이스 — 역할이 만나는 지점
역할 사이의 '계약'이 흔들리면 조직이 흔들린다
역할들은 정해진 접점(인터페이스)에서 만납니다. 이 접점의 합의가 협업의 품질을 결정합니다.
- FE ↔ BE: [[api-contract]] — API 요청/응답 형식. 먼저 합의하면 병렬 개발 가능.
- 디자이너 ↔ FE: 디자인 시스템·컴포넌트 명세. 토큰(색·간격)이 합의되면 재작업이 준다.
- 개발 ↔ QA: 인수 기준(AC)·테스트 케이스. "완료의 정의(DoD)"가 공유돼야 한다.
- 개발 ↔ DevOps/SRE: [[cicd-pipeline]]·헬스체크·로그 포맷. 배포·운영의 접점.
- 전체 ↔ PO: 우선순위·범위 결정. "이번 스프린트에 뭘 넣나"의 최종 판단.
인프라 담당이 자주 빠지는 함정: 설계 단계에 늦게 합류하는 것. 접점(헬스체크 엔드포인트, 환경변수, 로그 포맷)을 개발이 다 정한 뒤 받으면 재작업이 큽니다. 일찍 끼어드는 게 역할입니다.
RACI로 책임 명확히 하기 — 직접 작성
장애·배포처럼 여러 역할이 얽히는 작업은 RACI로 책임을 못 박습니다. R(실무 담당)·A(최종 책임, 단 1명)·C(자문)·I(통보)를 작업별로 채웁니다.
작업: "프로덕션 배포" PO BE SRE QA
─────────────────────────────────────────────────
릴리스 범위 승인 A C I C
배포 실행 I C R I
배포 전 테스트 통과 확인 I C I R/A
롤백 결정 C C R/A I
사용자 공지 R/A I I I
규칙: A(최종책임)는 작업마다 정확히 1명. R은 여러 명 가능.
echo '작업 × 역할 → R/A/C/I 매핑'- 각 행(작업)에 A가 정확히 1명인지 먼저 확인 — A가 없으면 "아무도 책임 안 짐", A가 둘이면 "서로 미룸". 장애 시 10분이 날아가는 원인
- R(실무 담당)이 비어 있는 작업이 있으면 그 일은 실제로 아무도 안 한다는 신호 → 담당 지정 필요
- "롤백 결정"의 A가 SRE인지 PO인지 사전 합의 — 장애 순간 이걸 논쟁하면 이미 늦다. 미리 못 박아 둔다
- 한 사람에게 R/A가 과도하게 몰리면 병목·번아웃 위험 → 분산하거나 백업 담당을 둔다
상황: 결제 장애가 났는데 슬랙에 모인 사람들이 서로 "백엔드?" "인프라?" "PO 결정?"만 반복하다 초기 10~20분을 흘려보냅니다. 복구 시간(MTTR)이 그만큼 늘어납니다.
원인: 인시던트 역할(Incident Commander, 커뮤니케이터, 해결 담당)과 의사결정 권한이 사전에 정의돼 있지 않습니다. 평소엔 역할이 암묵적으로 굴러가지만, 압박 상황에서는 명시적 책임이 없으면 멈춥니다.
진단 — 사전 점검:
□ 온콜 당번이 정해져 있고 알림이 그 사람에게 가는가?
□ 인시던트 발생 시 'Incident Commander(상황 지휘)'가 누구인지 합의됐는가?
□ 롤백/공지 권한(A)이 누구인지 RACI에 있는가?
해결: 인시던트 대응 역할을 미리 정의합니다 — IC(지휘·결정), Ops(실제 조치), Comms(이해관계자 공지). 이는 [[slo-error-budget]]에서 다루는 운영 문화의 일부입니다. 평시에 RACI와 온콜표를 만들어 두면, 장애 순간 "누가"를 논쟁하지 않고 바로 "무엇"에 집중합니다.
인프라/SRE로서 당신의 역할은 단순히 "서버를 관리"하는 것을 넘어, 개발과 운영 사이의 접점(배포 파이프라인·관측성·온콜)을 책임지는 것입니다. 새 팀에 합류하면 가장 먼저 할 일 중 하나가 "배포와 장애대응의 RACI가 있는가?"를 확인하고, 없으면 만드는 것입니다. PM은 같은 RACI로 기능 단위의 책임 릴레이(PO→디자이너→FE/BE→QA→배포)에 구멍이 없는지 점검합니다. 역할을 명확히 하는 것은 통제가 아니라, 압박 상황에서 조직이 멈추지 않게 하는 안전장치입니다.
다음 모듈에서는 이 역할들이 함께 일하는 가장 흔한 방식 — 애자일과 스크럼의 리듬(스프린트·세리머니)을 다룹니다.