장애가 터졌습니다. 결제가 안 됩니다. 슬랙에 사람들이 모이는데 아무도 먼저 움직이지 않습니다. "이거 백엔드 문제예요?" "인프라 같은데요?" "PO님이 결정해 주셔야..." 10분이 그냥 흘러갑니다. 누가 무엇을 책임지는지, 이 상황의 최종 의사결정자가 누구인지 합의돼 있지 않으면, 역량이 충분해도 조직은 멈춥니다. 역할과 책임 경계를 아는 것은 조직도를 외우는 게 아니라 — "이 일은 누구에게"를 1초 안에 답하는 능력입니다.
- 1개발 조직의 주요 역할(PO/PM·FE·BE·QA·DevOps/SRE·디자이너·데이터)을 책임으로 구분할 수 있다
- 2역할 간 협업 인터페이스(FE↔BE는 API, 개발↔운영은 CI/CD)를 짚을 수 있다
- 3DevOps/SRE가 전통적 개발·운영 분리와 어떻게 다른지 설명할 수 있다
- 4RACI로 작업별 책임 주체를 명시해 역할 공백/중복을 없앨 수 있다
역할 지도 — 누가 무엇을
확대
위 그림처럼 제품/사용자를 중심에 두고 PO/PM, FE, BE, DevOps/SRE, QA, 디자이너가 각자의 책임으로 연결되며, FE와 BE는 API를 통해 만난다.
역할은 '직책'이 아니라 '책임'으로 본다
사람 수보다 역할이 많을 수도, 한 사람이 여러 역할을 겸할 수도 있습니다. 중요한 건 각 책임이 누구에게 있는가입니다.
| 역할 | 핵심 책임 | 주된 산출물/접점 |
|---|---|---|
| PO/PM | 무엇을 왜 만들지·우선순위·일정 | 백로그·PRD·로드맵 |
| 디자이너(UX/UI) | 사용자 경험·화면 | 와이어프레임·디자인 시스템 |
| 프론트엔드 | 화면 구현·상호작용 | UI 코드, API 호출 |
| 백엔드 | 데이터·로직·인증·연동 | API, DB 스키마 |
| QA | 품질 검증·테스트 | 테스트 케이스·결함 리포트 |
| DevOps/SRE/인프라 | 배포 자동화·안정성·운영 | CI/CD·IaC·모니터링·온콜 |
| 데이터(분석/엔지니어) | 지표·파이프라인 | 대시보드·ETL |
PM·인프라 관점: 하나의 기능이 흐르려면 **PO(무엇)→디자이너(어떻게 보이나)→FE/BE(구현)→QA(검증)→DevOps(배포·운영)**가 릴레이로 이어집니다. 한 칸이 비면 거기서 막힙니다.
협업 인터페이스 — 역할이 만나는 지점
확대
위 그림처럼 전통 모델은 개발과 운영 사이에 벽이 있어 배포 주기가 길고 책임이 분리되지만, DevOps/SRE 모델은 CI/CD·공동 온콜·SLO로 그 벽을 허문다.
역할 사이의 '계약'이 흔들리면 조직이 흔들린다
역할들은 정해진 접점(인터페이스)에서 만납니다. 이 접점의 합의가 협업의 품질을 결정합니다.
- FE ↔ BE: API와 계약 — API 요청/응답 형식. 먼저 합의하면 병렬 개발 가능.
- 디자이너 ↔ FE: 디자인 시스템·컴포넌트 명세. 토큰(색·간격)이 합의되면 재작업이 준다.
- 개발 ↔ QA: 인수 기준(AC)·테스트 케이스. "완료의 정의(DoD)"가 공유돼야 한다.
- 개발 ↔ DevOps/SRE: CI/CD 파이프라인·헬스체크·로그 포맷. 배포·운영의 접점.
- 전체 ↔ PO: 우선순위·범위 결정. "이번 스프린트에 뭘 넣나"의 최종 판단.
인프라 담당이 자주 빠지는 함정: 설계 단계에 늦게 합류하는 것. 접점(헬스체크 엔드포인트, 환경변수, 로그 포맷)을 개발이 다 정한 뒤 받으면 재작업이 큽니다. 일찍 끼어드는 게 역할입니다.
RACI로 책임 명확히 하기 — 직접 작성
확대
위 그림처럼 작업별로 R(실무)/A(최종책임)/C(자문)/I(통보)를 명시하면 장애·배포 같은 다자 협업에서 "누가 결정하나"의 혼선이 사라진다.
장애·배포처럼 여러 역할이 얽히는 작업은 RACI로 책임을 못 박습니다. R(실무 담당)·A(최종 책임, 단 1명)·C(자문)·I(통보)를 작업별로 채웁니다.
작업 예시: "프로덕션 배포"의 RACI
| 작업 | 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·에러버짓·포스트모템에서 다루는 운영 문화의 일부입니다. 평시에 RACI와 온콜표를 만들어 두면, 장애 순간 "누가"를 논쟁하지 않고 바로 "무엇"에 집중합니다.
심화 — 역할 경계를 긋는 일은 사실상 아키텍처 설계다
심화: 콘웨이의 법칙과 DevOps 팀의 역설 — 조직도가 시스템 구조를 결정한다
역할 지도와 RACI를 그릴 줄 알게 되면, 다음 질문은 "그 경계를 어디에 긋느냐"입니다. 이 결정은 조직 관리의 문제가 아니라 시스템 설계의 문제입니다 — 소프트웨어는 그것을 만든 조직의 커뮤니케이션 구조를 닮기 때문입니다(콘웨이의 법칙).
- 팀 경계 = 시스템 경계: FE팀·BE팀·DB팀으로 조직을 나누면 시스템도 정확히 그 경계로 잘리고, 경계마다 티켓과 대기열이 생깁니다. 기능 하나가 세 팀의 백로그를 순서대로 통과해야 한다면, 그 리드타임은 조직도가 만든 것입니다. 그래서 성숙한 조직은 반대로 갑니다 — 원하는 시스템 구조에 맞춰 팀을 먼저 재편하는 역콘웨이 전략입니다.
- DevOps '팀'의 역설: "개발과 운영의 벽을 없애자"며 DevOps 팀을 신설하면, 개발↔DevOps팀↔운영이라는 벽 두 개짜리 구조가 되기 쉽습니다. DevOps는 부서명이 아니라 일하는 방식입니다. 별도 팀을 두려면 그 팀의 산출물은 '대신 배포해 주기'(새로운 대기열)가 아니라, 개발팀이 스스로 배포할 수 있게 하는 셀프서비스 플랫폼(CI/CD 파이프라인의 파이프라인·템플릿)이어야 합니다. 요청을 받는 팀인지, 요청을 없애는 팀인지가 갈림길입니다.
- 역할 분화의 타이밍: 5인 팀에서 역할은 사람이 아니라 모자입니다 — 한 사람이 여러 모자를 바꿔 씁니다. 전담을 채용할 시점의 신호는 두 가지입니다: 특정 책임이 반복적으로 방치되거나(빈 구멍), 특정인의 대기열이 되거나(병목). 이 신호 전에 직책부터 늘리는 것은 비쌉니다 — 채용보다 먼저 RACI로 책임을 명시하는 쪽이 거의 항상 쌉니다.
- RACI도 낡는다: 조직 개편·퇴사 후 갱신되지 않은 RACI는 없는 것보다 위험합니다 — 장애 순간에 이미 퇴사한 사람이 A로 적힌 표를 보게 됩니다. 분기마다 실제 사건 하나를 골라 "지난번에 정말 이 표대로 움직였는가"를 대조하는 것이 문서를 살아 있게 하는 가장 싼 방법입니다.
정리하면 — 역할과 팀 경계는 한 번 그리는 그림이 아니라, 시스템이 커질 때마다 함께 다시 그려야 하는 설계도입니다.
상황: 5년간 배포·장애를 도맡아 온 인프라 담당자가 퇴사했습니다. 인수인계 문서는 3장. 퇴사 다음 주 첫 배포 시도가 실패합니다 — 배포 스크립트가 그의 서버 홈 디렉터리에 있었고, 외부 서비스 시크릿 절반이 그의 개인 계정으로 발급돼 있었으며, "결제 서비스는 A→B→C 순서로 수동 재시작해야 한다"는 절차는 어디에도 적혀 있지 않았습니다. 신규 릴리스가 2주 밀렸고, 그 사이 나온 보안 패치도 적용하지 못했습니다.
원인: 조직이 '배포 책임'을 시스템이 아니라 사람에게 묶어 뒀습니다. 그가 다 해결해 주는 것이 모두에게 편했으므로 아무도 문서화·자동화를 요구하지 않았고, 그의 평가 기준도 '해결한 건수'였지 '남이 해결할 수 있게 만든 것'이 아니었습니다. 히어로는 단기엔 축복이지만, 조직 관점에서는 단일 장애점(SPOF)입니다 — 그리고 이것은 그의 잘못이 아니라 그렇게 두는 것이 이득이었던 구조의 결과입니다.
진단: 버스 팩터 감사를 합니다 — 핵심 운영 작업(배포, 롤백, 인증서 갱신, DB 페일오버, 시크릿 로테이션 등)을 목록으로 만들고, 작업마다 '지금 당장 수행할 수 있는 사람 수'를 셉니다. 이 팀은 12개 작업 중 7개가 1명이었습니다. 함께 시크릿·권한을 전수 조사해 개인 계정으로 발급된 것을 찾아냅니다.
해결: ① 복구와 동시에 각 작업의 런북 작성을 정식 티켓으로 만들어 스프린트에 배정합니다 ② 시크릿을 개인 계정에서 팀 공용 저장소(vault)로 이전하고 개인 명의 발급을 금지합니다 ③ 운영 작업에 페어·로테이션을 도입해 매 분기 담당을 바꿉니다 ④ 반기마다 '휴가 테스트'를 합니다 — 주 담당자 없이 배포를 실제로 수행해 보고, 막힌 지점을 그 자리에서 문서화합니다 ⑤ 평가 기준에 '지식 이전'을 넣어, 혼자만 아는 것이 아니라 팀이 알게 만든 것이 성과가 되게 합니다. 버스 팩터 1은 그 사람이 뛰어나다는 증거가 아니라 조직이 위험하다는 증거입니다.
인프라/SRE로서 당신의 역할은 단순히 "서버를 관리"하는 것을 넘어, 개발과 운영 사이의 접점(배포 파이프라인·관측성·온콜)을 책임지는 것입니다. 새 팀에 합류하면 가장 먼저 할 일 중 하나가 "배포와 장애대응의 RACI가 있는가?"를 확인하고, 없으면 만드는 것입니다. PM은 같은 RACI로 기능 단위의 책임 릴레이(PO→디자이너→FE/BE→QA→배포)에 구멍이 없는지 점검합니다. 역할을 명확히 하는 것은 통제가 아니라, 압박 상황에서 조직이 멈추지 않게 하는 안전장치입니다.
다음 모듈에서는 이 역할들이 함께 일하는 가장 흔한 방식 — 애자일과 스크럼의 리듬(스프린트·세리머니)을 다룹니다.
실전 랩으로 손에 익히기: 개발 조직 역할 실습 — 역할별 책임·핸드오프 계약·RACI로 책임을 명확히 합니다.
관련 모듈로 더 깊이:
- 애자일과 스크럼 — 이 역할들이 함께 일하는 애자일·스크럼의 리듬
- 요구사항 정의 — 역할 간 합의를 글로 굳히는 요구사항·PRD
- 프레임워크·라이브러리·런타임·SDK — 협업에서 오가는 개발 용어를 층위로 읽는 법