게임 개발 팀원별 업무 부하량(Workload) 균형 분석과 태스크 자동 재분배 추천 시스템
게임 개발 프로젝트의 팀원별 Workload를 잔여 작업 시간과 실제 가용 시간으로 정량화하고 우선순위·역량·의존성을 반영해 태스크 재분배 후보를 자동 추천하는 방법을 정리합니다.
핵심 요약
팀원별 Workload는 할당된 태스크 수가 아니라 잔여 작업 시간과 실제 가용 시간을 비교해 계산해야 합니다. 추천 시스템은 우선순위·마감일·역량·의존성·컨텍스트 스위칭 비용을 함께 평가한 뒤 팀 전체의 부하 편차를 줄이는 태스크 재분배 후보를 제시하고 PM 또는 담당자의 승인을 거쳐 반영합니다.
팀원별 업무 부하량 분석이 필요한 이유
게임 개발 프로젝트에서 업무 불균형은 단순히 한 사람이 바쁘다는 문제로 끝나지 않습니다. 특정 프로그래머에게 핵심 시스템 태스크가 몰리면 QA와 통합 일정이 함께 밀리고 아트 담당자에게 수정 요청이 집중되면 빌드에 필요한 리소스가 늦게 반영됩니다.
특히 다음과 같은 상황에서는 태스크 개수만으로 업무량을 판단하기 어렵습니다.
- 2시간짜리 버그 수정 5개와 5일이 필요한 전투 시스템 구현 1개가 같은 태스크 1개로 집계되는 경우
- 회의, 코드 리뷰, 빌드 대응, 외부 협업으로 실제 집중 작업 시간이 줄어드는 경우
- 특정 팀원만 사용할 수 있는 엔진 지식이나 도메인 경험이 필요한 경우
- 선행 태스크가 끝나지 않아 후속 태스크를 시작할 수 없는 경우
- 마감일이 가까워졌지만 작업 시간 추정치가 갱신되지 않은 경우
따라서 Workload 분석의 목표는 “누가 태스크를 많이 가지고 있는가?”가 아니라 “현재 가용 시간 대비 어떤 팀원이 일정 위험을 가장 크게 부담하고 있는가?”를 파악하는 데 있습니다.
Workload는 어떻게 계산하는가?
1. 실제 가용 시간을 먼저 계산한다
주당 근무 시간이 40시간이어도 그 시간을 모두 개발에 사용할 수는 없습니다. 회의, 코드 리뷰, QA 대응, 기획 논의, 운영 이슈를 제외한 시간을 실제 가용 시간으로 계산해야 합니다.
예를 들어 5일 근무하고 하루 6시간을 집중 작업에 사용할 수 있으며 회의·지원 비율이 20%라면 실제 가용 시간은 다음과 같습니다.
팀원마다 가용 시간이 다를 수 있으므로 개인별 기준을 사용해야 합니다. 휴가, 교육, 파트타임 근무, 릴리스 대응 기간도 별도의 보정값으로 관리하는 편이 안전합니다.
2. 태스크의 잔여 작업 시간을 반영한다
각 태스크에는 다음 데이터를 저장합니다.
| 필드 | 설명 | 예시 |
|---|---|---|
remainingHours | 완료까지 남은 예상 시간 | 12 |
priorityWeight | 우선순위 가중치 | 1.5 |
riskWeight | 일정·기술 위험 가중치 | 1.2 |
deadlineDays | 마감일까지 남은 일수 | 3 |
requiredSkills | 필요한 역량 | Unreal, C++ |
dependencies | 선행 태스크 목록 | Combat-102 |
우선순위와 위험도가 높은 태스크는 동일한 잔여 시간이라도 팀 부하에 더 큰 영향을 줍니다. 이를 반영한 기본 Workload는 다음과 같이 계산할 수 있습니다.
Workload_i가 1.0이면 가용 시간과 가중 잔여 작업량이 같다는 뜻입니다. 다만 이 값은 절대적인 생산성 점수가 아니라 현재 계획의 일정 압력을 나타내는 지표로 사용해야 합니다.
권장 해석 기준은 다음과 같습니다.
| Workload 비율 | 상태 | PM 대응 |
|---|---|---|
| 0.00~0.75 | 여유 | 다음 우선순위 태스크 후보 검토 |
| 0.76~1.00 | 안정 | 현재 계획 유지 및 추적 |
| 1.01~1.25 | 주의 | 범위 조정 또는 일부 재분배 검토 |
| 1.26 이상 | 위험 | 재분배·일정 변경·지원 인력 투입 검토 |
프로젝트에 따라 기준값은 달라질 수 있습니다. 중요한 점은 한 번 정한 임계값을 영구적으로 고정하지 않고 스프린트 회고에서 예측 오차와 함께 조정하는 것입니다.
태스크 자동 재분배 추천은 어떻게 동작하는가?
추천 시스템은 단순히 가장 여유 있는 사람에게 태스크를 보내면 안 됩니다. 게임 개발 태스크는 역량, 코드 소유권, 플랫폼, 선행 작업, 협업 비용에 따라 실제 배정 가능 여부가 달라지기 때문입니다.
Step 1. 후보 태스크와 후보 담당자를 필터링한다
먼저 재분배 대상 태스크를 선정합니다. 일반적으로 다음 조건에 해당하는 태스크가 후보가 됩니다.
- 담당자의 예상 Workload가 위험 임계값을 초과함
- 태스크의 상태가
Todo또는In Progress임 - 선행 태스크가 완료되었거나 재배정 대상 팀원이 처리할 수 있음
- 외부 계약, 보안, 접근 권한 등 재배정 금지 조건이 없음
- 마감일까지 다른 팀원이 작업을 완료할 수 있음
그 다음 후보 담당자를 필터링합니다.
- 필요한 기술 스택을 보유함
- 해당 플랫폼이나 코드베이스에 접근할 수 있음
- 가용 시간이 태스크의 잔여 시간보다 충분함
- 이미 동일한 릴리스 구간에 과도한 태스크를 가지고 있지 않음
- 현재 진행 중인 작업을 중단했을 때 더 큰 위험이 발생하지 않음
Step 2. 재배정 비용을 점수화한다
후보 담당자별로 다음 점수를 계산합니다. 점수가 낮을수록 좋은 후보로 취급합니다.
각 항목의 의미는 다음과 같습니다.
| 항목 | 의미 |
|---|---|
LoadAfter | 태스크 배정 후 예상되는 담당자 부하량 |
SkillGap | 요구 역량과 담당자 역량의 차이 |
ContextSwitch | 현재 업무와 새 태스크의 문맥 전환 비용 |
DeadlineRisk | 재배정 후 마감일을 지키지 못할 위험 |
OwnershipPenalty | 기존 담당자의 코드·기획 소유권을 바꾸는 비용 |
가중치 α~ε는 프로젝트 상황에 따라 조정합니다. 예를 들어 릴리스 직전이라면 DeadlineRisk의 가중치를 높이고 신규 시스템 개발 초기라면 SkillGap과 OwnershipPenalty를 높이는 방식입니다.
Step 3. 여러 태스크의 조합을 평가한다
태스크 하나만 재배정했을 때는 균형이 맞아 보이지만 여러 태스크를 동시에 옮기면 새로운 과부하가 생길 수 있습니다. 따라서 추천 시스템은 한 번에 다음 결과를 함께 계산해야 합니다.
- 재배정 전후 팀원별 Workload
- 전체 Workload의 최대값
- 팀원 간 Workload 표준편차
- 마감 지연 예상 태스크 수
- 새로 발생하는 의존성 또는 리뷰 병목
- 컨텍스트 스위칭 횟수
간단한 초기 구현은 탐욕 알고리즘으로 시작할 수 있습니다. 위험도가 가장 높은 태스크부터 가장 낮은 점수의 담당자에게 배정하고 배정 후 Workload를 다시 계산합니다. 태스크 간 상호작용이 많거나 최적화 품질이 중요하다면 최소 비용 최대 유량 알고리즘 또는 정수 선형 계획법을 검토할 수 있습니다.
interface Task {
id: string;
remainingHours: number;
priorityWeight: number;
riskWeight: number;
requiredSkills: string[];
deadlineDays: number;
}
interface Member {
id: string;
availableHours: number;
skills: string[];
currentWeightedHours: number;
}
function workload(member: Member): number {
return member.currentWeightedHours / member.availableHours;
}
function skillGap(task: Task, member: Member): number {
if (task.requiredSkills.length === 0) return 0;
const matched = task.requiredSkills.filter(skill => member.skills.includes(skill));
return 1 - matched.length / task.requiredSkills.length;
}
function recommendationScore(task: Task, member: Member): number {
const projectedHours = task.remainingHours * task.priorityWeight * task.riskWeight;
const loadAfter = (member.currentWeightedHours + projectedHours) / member.availableHours;
const deadlineRisk = task.deadlineDays <= 2 && loadAfter > 1 ? 2 : 0;
return loadAfter * 5 + skillGap(task, member) * 3 + deadlineRisk * 4;
}위 코드는 추천 로직의 핵심 구조만 보여주는 예시입니다. 실제 시스템에서는 휴가 일정, 리뷰어 필요 여부, 태스크 의존성, 팀원별 최대 동시 진행 태스크 수를 추가로 검증해야 합니다.
flowchart TD
A[태스크와 팀원 데이터 수집] --> B[가용 시간과 Workload 계산]
B --> C[과부하 태스크 필터링]
C --> D[역량과 의존성으로 후보자 필터링]
D --> E[재배정 비용 점수 계산]
E --> F[전후 일정과 부하 비교]
F --> G[PM 승인 요청]
G --> H[태스크 업데이트와 변경 이력 기록]자동 재분배 시스템에 어떤 안전장치가 필요한가?
업무 재분배는 수치만으로 결정하면 안 됩니다. 태스크 담당자 변경은 코드 소유권, 커뮤니케이션 비용, 개인의 전문성 성장과도 연결되므로 추천 시스템은 자동 실행보다 승인 가능한 의사결정 자료를 제공하는 방향이 적합합니다.
추천 결과에 반드시 표시할 정보
- 현재 담당자와 추천 담당자
- 재배정 대상 태스크와 잔여 예상 시간
- 재배정 전후의 Workload 변화
- 추천 점수와 점수를 구성한 세부 항목
- 필요한 역량과 후보자의 일치 여부
- 선행·후속 태스크 영향
- 예상되는 마감일 변화
- 추천을 제외하거나 승인할 수 있는 사유 입력란
자동 재배정을 제한해야 하는 태스크
다음 태스크는 기본적으로 수동 승인 대상으로 두는 것이 좋습니다.
- 핵심 전투·저장·네트워크 시스템처럼 소유권 전환 비용이 큰 태스크
- 콘솔 인증이나 플랫폼 SDK 접근 권한이 필요한 태스크
- 외부 업체 또는 특정 계약 담당자와 연결된 태스크
- 출시 빌드 차단 버그
- 플레이어 데이터와 결제 기능을 다루는 태스크
- 담당자의 전문 지식이 없으면 품질 검증이 어려운 태스크
추천 시스템은 “누구에게 넘길까?”뿐 아니라 “넘기지 않는 편이 나은가?”도 판단해야 합니다.
어떤 데이터 구조로 운영할까?
Jira, Linear, Notion 데이터베이스, Airtable 또는 사내 태스크 관리 도구에서 다음 구조를 사용할 수 있습니다.
| 객체 | 핵심 필드 |
|---|---|
Member | availableHours, skills, timezone, maxWip, leaveSchedule |
Task | remainingHours, priority, risk, deadline, dependencies, requiredSkills |
Assignment | memberId, taskId, assignedAt, confidence, approvedBy |
WorkloadSnapshot | capturedAt, weightedHours, availableHours, loadRatio |
Recommendation | sourceMember, targetMember, score, reason, status |
WorkloadSnapshot을 매일 또는 스프린트 계획 시점마다 저장하면 예측값과 실제 진행량을 비교할 수 있습니다. 추천 결과를 바로 덮어쓰지 말고 Recommendation 객체로 분리해야 승인·반려·수정 이력을 추적하기 쉽습니다.
추천 품질을 어떻게 검증할까?
추천 시스템의 성공 기준은 태스크를 많이 이동시키는 것이 아닙니다. 실제로 일정 위험과 병목이 줄었는지를 검증해야 합니다.
핵심 지표
- 스프린트 종료 시 Workload 최대값
- 팀원 간 Workload 표준편차
- 재분배 후 마감 지연 태스크 수
- 예상 시간과 실제 소요 시간의 오차율
- 추천 승인율과 반려율
- 재분배 후 재변경된 태스크 비율
- 담당자 변경으로 발생한 리뷰·인수인계 시간
- 특정 팀원에게 반복적으로 집중되는 태스크 비율
초기에는 자동화 정확도보다 설명 가능성이 중요합니다. PM과 팀원이 “왜 이 사람에게 추천되었는가?”를 이해할 수 있어야 추천 결과를 일정 계획에 반영할 수 있습니다.
도입 절차는 어떻게 시작할까?
1. 작은 범위의 데이터부터 정리한다
한 개 스프린트 또는 한 개 기능 영역을 대상으로 시작합니다. 처음부터 모든 태스크를 자동화하려 하면 추정치 품질, 태그 체계, 담당자 정보가 서로 맞지 않아 결과를 해석하기 어렵습니다.
2. 업무 시간 추정치를 갱신한다
태스크 생성 시점의 추정치만 사용하지 말고 작업 시작 후 남은 시간을 갱신합니다. originalEstimate, remainingEstimate, actualHours를 구분하면 예측 오차를 측정할 수 있습니다.
3. 추천 결과를 승인형 워크플로로 연결한다
추천 시스템이 다음과 같은 상태를 갖도록 설계합니다.
Suggested: 재분배 후보 생성Reviewed: PM 또는 리드가 검토Approved: 담당자 변경 승인Applied: 태스크 시스템에 반영Rejected: 반려 사유 저장
승인자는 추천 결과를 그대로 적용하거나 대상 팀원, 시작일, 잔여 시간 등을 수정할 수 있어야 합니다.
4. 회고에서 가중치와 임계값을 조정한다
추천이 자주 반려되는 이유가 역량 데이터 부족인지 추정치 오류인지 업무 소유권 문제인지 구분합니다. 그 결과를 바탕으로 priorityWeight, riskWeight, ContextSwitch 가중치를 조정합니다.
자주 묻는 질문(FAQ)
태스크 개수만으로 Workload를 계산하면 안 되나요?
안 됩니다. 태스크마다 잔여 작업 시간과 위험도가 다르므로 태스크 개수는 참고 지표로만 사용해야 합니다. 최소한 잔여 시간과 실제 가용 시간을 함께 계산해야 합니다.
가장 여유 있는 팀원에게 자동으로 태스크를 배정하면 되나요?
권장하지 않습니다. 필요한 역량, 코드 소유권, 의존성, 마감일, 컨텍스트 스위칭 비용을 함께 평가해야 합니다. 여유 시간이 있어도 해당 태스크를 완료할 수 없다면 좋은 후보가 아닙니다.
자동 재분배를 바로 실행해도 되나요?
출시 차단 버그나 단순 반복 업무처럼 위험이 낮은 태스크를 제외하면 승인형 운영이 안전합니다. 추천 근거와 변경 이력을 남기고 PM 또는 담당 리드가 최종 승인하도록 설계하는 것이 좋습니다.
정리
팀원별 Workload 균형 분석은 태스크 수를 세는 기능이 아니라 가용 시간, 잔여 작업량, 우선순위, 위험도, 역량, 의존성을 함께 계산하는 일정 관리 시스템입니다.
초기에는 Workload 비율 계산 → 과부하 태스크 필터링 → 후보 담당자 평가 → 전후 결과 비교 → 승인형 반영의 흐름만 구현해도 충분합니다. 이후 실제 시간 기록과 반려 사유를 축적하면 프로젝트 특성에 맞는 가중치와 추천 규칙을 정교하게 조정할 수 있습니다.
