개념
배분의 세 가지 입력
리드가 업무를 나눌 때 흔히 쓰는 기준은 "지금 누가 비어 있는가"다. 이것만으로 나누면 세 가지 문제가 생긴다. 고위험 기능이 신규 팀원에게 가고, 같은 사람만 같은 영역을 계속 맡아 대체 불가능한 사람이 생기고, 누군가는 성장 기회를 계속 놓친다.
그래서 배분에는 세 가지 입력을 함께 쓴다.
- 기능 위험도 — 모듈 4의 위험 기반 테스트에서 나온 영향도 × 발생 가능성
- 팀원 숙련도 — 해당 영역·기법·도구에 대한 숙련(모듈 7 레슨 9의 스킬 매트릭스)
- 팀원 성장 목표 — 1:1에서 합의한 방향(레슨 3)
위험 × 숙련도 2x2
| 숙련도 높음 | 숙련도 낮음 | |
|---|---|---|
| 위험 높음 | 기본 배정. 결제·인증·정산 같은 핵심 경로 | 성장 배정 + 페어 또는 리뷰 강화. 혼자 두지 않는다 |
| 위험 낮음 | 가능하면 피한다. 숙련자의 시간이 아깝다. 멘토 역할로 전환 | 입문 배정. 새 팀원의 첫 과제로 적합 |
오른쪽 위 칸이 성장의 자리다. 위험이 높은 일을 숙련도가 낮은 사람에게 맡길 때는 반드시 안전망 을 붙인다 — 숙련자와 페어로 설계하거나, 케이스 전체 리뷰를 걸거나, 리드가 핵심 시나리오만 따로 확인한다. 안전망 없이 맡기면 성장이 아니라 도박이다.
왼쪽 아래 칸의 일은 숙련자에게 계속 주면 지루함과 이탈을 부른다. 이런 일은 신규 팀원에게 넘기고, 숙련자는 그 신규 팀원의 멘토가 되게 한다.
버스 팩터를 줄인다
버스 팩터(bus factor)는 "몇 명이 갑자기 빠지면 이 영역이 멈추는가"를 뜻한다. 결제 테스트를 3년째 한 사람만 알고 있다면 버스 팩터는 1이다. 그 사람이 휴가를 가면 결제 릴리스가 멈춘다.
리드는 핵심 영역마다 버스 팩터를 2 이상으로 유지한다.
- 분기마다 핵심 영역의 보조 담당 을 한 명씩 지정하고, 주 담당과 한 스프린트씩 페어로 일하게 한다
- 영역별 테스트 노트(환경 설정, 알려진 함정, 연락할 사람)를 주 담당이 쓰고 보조 담당이 검토한다
- 휴가 전에 "이 영역을 보조 담당 혼자 한 번 돌려 보기"를 연습한다
[영역별 담당표 예]
영역 주 담당 보조 담당 버스 팩터 다음 분기 조치
결제 김OO 이OO 2 -
정산 배치 박OO - 1 ← 최OO를 보조로, 3월 스프린트 페어
회원·인증 이OO 김OO 2 -
관리자 화면 최OO - 1 ← 신규 입사자 온보딩 과제로공정성이 보이는 배분 규칙
팀원은 배분이 공정한지를 민감하게 본다. 특히 동료에서 리드가 된 경우 "친한 사람에게 좋은 일을 준다"는 인상이 생기기 쉽다. 규칙을 공개하면 이런 인상이 줄어든다.
[우리 팀 배분 규칙]
1. 고위험 기능은 숙련자 1명 + 성장 목표가 맞는 1명을 짝으로 배정한다
2. 같은 사람이 같은 영역의 주 담당을 3분기 이상 연속으로 맡지 않는다(원하면 예외)
3. 신규 입사자의 첫 4주는 저위험 영역 + 멘토 배정
4. 성장 목표와 맞는 일이 생기면 1:1에서 합의한 사람에게 먼저 제안한다
5. 배분 결과는 스프린트 시작 시 보드에 공개한다차단 이슈 — 다섯 가지 유형
팀원이 "막혀 있다"고 할 때 리드의 가장 중요한 일은 빨리 풀어 주는 것 이다. 차단 이슈는 원인에 따라 푸는 방법이 다르다.
| 유형 | 예 | 리드의 행동 |
|---|---|---|
| 환경 | 테스트 서버 다운, 빌드 배포 실패 | 인프라·개발 담당에게 연결, 우회 환경 확보 |
| 데이터 | 테스트 계정·데이터 부족, 마스킹 안 된 데이터 | 데이터 준비 요청, 합성 데이터 대안(모듈 7 레슨 2) |
| 정보 | 요구사항 불명확, 기대 결과 모름 | 기획자와 15분 확인 자리 마련, 질문 목록 정리 |
| 결정 | "이건 결함인가 사양인가", 범위 판단 | 결정권자 확인, 결정 기록 |
| 외부 | 외부 연동사 응답 지연, 제3자 API 장애 | 외부 담당자 에스컬레이션, 모의 서버 대안 |
"정보"와 "결정" 유형이 가장 오래 방치된다. 팀원은 기획자에게 몇 번 물어도 답이 없으면 그냥 기다린다. 리드가 개입하면 한 시간 안에 풀리는 일이 사흘씩 간다.
에스컬레이션 시한
차단 이슈마다 몇 시간 안에 누구에게 올린다 는 규칙을 둔다. 규칙이 없으면 팀원은 "이 정도로 리드를 귀찮게 해도 되나" 고민하며 시간을 잃는다.
| 경과 시간 | 행동 |
|---|---|
| 발생 즉시 | 보드에 차단 표시, 유형 기록 |
| 2시간 | 스스로 풀지 못하면 리드에게 알림 |
| 4시간(당일) | 리드가 해당 팀 리드·담당자에게 직접 연락 |
| 1일 | 일정 영향 판단, 이해관계자에게 공유 |
| 2일 이상 | 범위·일정 조정 안건으로 올림 |
차단 시간의 합계는 그 자체로 지표다. 스프린트마다 "차단으로 잃은 시간"을 유형별로 합산하면 어떤 개선(환경 안정화, 요구사항 리뷰 강화)이 가장 효과가 클지 보인다.
우선순위 충돌 조정
리드에게는 여러 방향에서 동시에 요청이 온다. 기획은 신규 기능 테스트를, 운영은 긴급 장애 재현을, 개발은 핫픽스 확인을 원한다. 조정 원칙은 다음과 같다.
- 충돌을 보이게 만든다 — 요청을 한 목록에 모으고 각 요청의 위험과 마감을 적는다
- 기준으로 정한다 — 운영 장애 > 릴리스 차단 > 계획된 테스트 > 개선 작업 같은 팀 기준을 미리 합의해 둔다
- 리드가 결정할 수 없는 충돌은 올린다 — 두 기획 과제가 같은 날 마감이면 어느 것을 미룰지는 제품 책임자가 정한다. 리드는 선택지와 영향을 정리해 준다
- 결정을 기록한다 — 누가 무엇을 근거로 정했는지. 나중에 "왜 이게 늦었냐"는 질문의 답이 된다
실무에서 왜 필요한가
배분은 리드가 매일 하는 결정 중 영향이 가장 큰 것이다. 잘못된 배분은 결함 탈출(숙련도 부족), 이탈(성장 정체), 병목(버스 팩터 1)을 동시에 만든다. 차단 이슈 해소는 팀 처리량에 직접 영향을 준다. 네 명 팀에서 하루 평균 2시간씩 차단되면 한 주에 한 사람 분의 시간이 사라진다.
채용시장에서의 위치
리드 면접에서 "업무를 어떻게 나누셨나요"라는 질문에 2x2 원칙과 버스 팩터 관리, 차단 시간 지표를 이야기할 수 있으면 운영 감각이 있는 리드로 보인다. 특히 "차단 시간을 유형별로 재서 환경 안정화에 투자를 얻어 냈다" 같은 사례는 데이터로 조직을 움직인 경험으로 읽힌다.