게임 개발 Bus Factor 계산법: 핵심 시스템 담당자 부재 리스크와 지식 이전 우선순위 정하기
핵심 시스템 담당자 부재 리스크를 Bus Factor로 수치화하는 방법을 설명합니다. 소유자와 대체자의 실제 수행 능력, 영향도, 복구 시간을 점수화해 지식 이전과 문서화 순서를 정하고 게임 개발 일정과 스코프 손실을 줄이는 실무 절차를 제시합니다.
핵심 요약
Bus Factor는 핵심 업무를 독립적으로 수행할 수 있는 사람이 몇 명인지 나타내는 지표입니다. 시스템별 Bus Factor가 1이면 담당자 한 명의 부재만으로 일정이나 출시 절차가 멈출 수 있으므로 최우선 관리 대상입니다.
핵심 시스템 목록을 만든 뒤 실제로 빌드·디버깅·배포·복구할 수 있는 사람 수를 세고 영향도와 복구 긴급도를 함께 평가하면 지식 이전 순서를 정할 수 있습니다. 문서를 작성하는 것에서 끝내지 말고 대체 담당자가 실제 작업을 수행하는 검증까지 완료해야 합니다.
Bus Factor는 무엇을 측정하는가?
Bus Factor는 특정 인력이 부재했을 때 업무가 계속될 수 있는지를 측정하는 운영 리스크 지표입니다. 원래는 프로젝트의 핵심 지식을 알고 있는 사람이 몇 명인지 나타내며 게임 개발에서는 시스템 단위 또는 핵심 작업 단위로 계산하는 것이 실용적입니다.
여기서 사람 수를 셀 때는 이름이 문서에 적혀 있는지보다 실제 독립 수행 능력을 기준으로 해야 합니다. 다음 작업을 다른 사람의 실시간 도움 없이 수행할 수 있어야 독립 담당자로 봅니다.
- 코드를 읽고 수정할 수 있음
- 로컬 또는 CI 환경에서 재현하고 디버깅할 수 있음
- 릴리스 빌드와 배포 절차를 수행할 수 있음
- 장애 발생 시 복구하거나 롤백할 수 있음
- 관련 문서와 테스트를 업데이트할 수 있음
시스템의 핵심 작업이 여러 개라면 시스템 전체의 Bus Factor는 가장 낮은 작업의 담당자 수로 계산합니다.
예를 들어 Unity 6와 C# Addressables를 사용하는 프로젝트에서 콘텐츠 번들은 세 명이 다룰 수 있지만 릴리스 카탈로그 복구는 한 명만 할 수 있다면 해당 콘텐츠 파이프라인의 Bus Factor는 1입니다. Unreal Engine 5.4 프로젝트에서 C++ Gameplay Ability System을 두 명이 수정할 수 있어도 패키징 서명과 콘솔 인증서 갱신을 한 명만 처리한다면 출시 파이프라인의 Bus Factor는 1입니다.
핵심 시스템 담당자 부재는 왜 일정 리스크가 되는가?
담당자 부재는 단순한 인력 부족이 아니라 의사결정과 복구 경로의 단절로 이어집니다. 특히 다음 조건이 겹치면 일정 리스크가 커집니다.
| 조건 | 발생 가능한 문제 |
|---|---|
| Bus Factor가 1 | 휴가, 퇴사, 병가만으로 작업이 중단됨 |
| 문서가 오래됨 | 문서와 현재 코드의 차이로 대체자가 재현에 실패함 |
| 테스트가 없음 | 수정 후 회귀 버그를 확인하기 어려움 |
| 권한이 한 사람에게 집중됨 | 저장소, 빌드 서버, 배포 콘솔 접근이 막힘 |
| 암묵지가 많음 | 코드에 드러나지 않는 설정과 판단 기준을 재현하지 못함 |
Bus Factor는 퇴사 확률이나 특정 인력이 떠날 가능성을 계산하는 지표가 아닙니다. 따라서 인사 리스크의 확률 모델로 과해석하면 안 됩니다. Bus Factor는 부재가 발생했을 때 프로젝트가 얼마나 취약한지 알려주는 구조적 지표입니다.
게임 개발에서 Bus Factor를 어떻게 계산할까?
1단계: 핵심 시스템과 중단 기준을 정의한다
먼저 모든 기능을 나열하지 말고 일정, 품질, 출시를 멈출 수 있는 시스템부터 고릅니다.
- 빌드 및 CI/CD: GitHub Actions, Jenkins, BuildGraph, 콘솔 패키징
- 저장 및 마이그레이션: 세이브 포맷, 버전 변환, 롤백
- 런타임 기반 시스템: 게임 상태 관리, 네트워크 동기화, 리소스 로딩
- 콘텐츠 파이프라인: Unity Addressables, Unreal Engine Cooking, 자동 임포트
- 플랫폼 연동: 인증, 결제, 클라우드 세이브, 콘솔 SDK
- 데이터 및 라이브 운영: 원격 설정, 분석 이벤트, 핫픽스 배포
핵심 시스템인지 판단하기 어려우면 다음 질문을 사용합니다.
이 시스템이 24시간 멈추면 현재 스프린트의 완료 조건이나 출시 일정이 바뀌는가?
그렇다면 Bus Factor 측정 목록에 넣습니다. 반대로 중단되어도 다른 작업으로 우회할 수 있고 복구 시간이 긴 시스템은 후순위 목록으로 분리합니다.
2단계: 독립 수행 가능한 사람만 세어 본다
각 핵심 시스템에 대해 작업별 담당자를 기록합니다. 단순히 코드에 커밋한 횟수나 회의 참석 여부는 기준이 되지 않습니다.
| 시스템 | 핵심 작업 | 독립 수행 가능 인원 | 작업 Bus Factor |
|---|---|---|---|
| 릴리스 파이프라인 | CI 빌드 실패 원인 분석 및 재실행 | 1명 | 1 |
| 릴리스 파이프라인 | 스토어 패키지 생성과 배포 | 2명 | 2 |
| 저장 시스템 | 세이브 버전 마이그레이션 | 2명 | 2 |
| 저장 시스템 | 손상 세이브 복구와 롤백 | 1명 | 1 |
| 전투 AI | Behavior Tree 디버깅 | 2명 | 2 |
릴리스 파이프라인의 시스템 Bus Factor는 작업별 최소값인 1입니다. 저장 시스템 역시 마이그레이션 담당자는 두 명이지만 복구와 롤백 담당자가 한 명뿐이므로 Bus Factor는 1입니다.
3단계: 권장 목표를 정한다
모든 시스템의 목표를 동일하게 두면 비효율적입니다. 출시 직결 시스템과 실험 기능의 목표를 다르게 설정합니다.
| 시스템 유형 | 권장 목표 | 이유 |
|---|---|---|
| 출시 빌드, 배포, 인증서 | 3명 이상 | 휴가와 교대 근무를 흡수해야 함 |
| 저장·마이그레이션·롤백 | 2명 이상 | 데이터 손실을 막을 대체 경로가 필요함 |
| 핵심 게임플레이 시스템 | 2명 이상 | 밸런스와 버그 수정의 병목을 줄임 |
| 단기 프로토타입 | 1명 허용 | 폐기 또는 재작성 가능성이 높음 |
목표 인원은 팀 규모와 근무 형태에 맞춰 조정합니다. 중요한 것은 목표를 미리 합의하고 현재 수치와 비교하는 것입니다.
지식 이전 우선순위를 어떻게 점수화할까?
Bus Factor만으로 순서를 정하면 인원이 한 명인 모든 작업이 같은 우선순위를 갖게 됩니다. 실제 계획에는 다음 세 가지를 함께 사용합니다.
- 영향도 I: 실패했을 때 일정, 매출, 품질에 미치는 영향. 1~5점
- 긴급도 U: 복구하지 못했을 때 차단되는 시간. 1~5점
- 노하우 취약도 K: 문서의 최신성, 테스트 유무, 권한 집중도를 반영한 점수. 1~3점
- 독립 담당자 수 O: 현재 실제로 수행 가능한 사람 수
팀 내부 비교를 위한 간단한 위험 점수는 다음처럼 계산할 수 있습니다.
여기서 6 - min(BF, 5)는 Bus Factor가 낮을수록 커지는 노출 계수입니다. 이 수식은 업계 공통 표준이 아니라 팀의 우선순위를 정하기 위한 관리용 모델입니다. 숫자 자체보다 동일한 기준으로 시스템을 비교하는 것이 중요합니다.
예시로 다음과 같이 평가할 수 있습니다.
| 시스템 | BF | 영향도 I | 긴급도 U | 노하우 취약도 K | 위험 점수 | 이전 예상 시간 |
|---|---|---|---|---|---|---|
| 릴리스 파이프라인 | 1 | 5 | 5 | 3 | 375 | 1일 |
| 저장 복구·롤백 | 1 | 5 | 4 | 3 | 300 | 2일 |
| 전투 AI 튜닝 | 2 | 4 | 3 | 2 | 96 | 4일 |
| 로컬라이제이션 임포트 | 3 | 3 | 2 | 1 | 18 | 1일 |
이 결과라면 릴리스 파이프라인과 저장 복구·롤백을 먼저 다룹니다. 이후 남은 일정과 이전 난이도를 고려해 로컬라이제이션 임포트를 짧은 작업으로 처리할 수 있습니다. 위험 점수가 낮아도 한 번의 짧은 세션으로 Bus Factor를 높일 수 있다면 별도 작업으로 묶는 편이 효율적입니다.
간단한 계산은 스프레드시트나 작은 스크립트로 자동화할 수 있습니다.
const exposure = 6 - Math.min(busFactor, 5);
const riskScore = impact * urgency * knowledgeVulnerability * exposure;
const priorityPerDay = riskScore / estimatedTransferDays;priorityPerDay는 위험 점수를 이전 예상 일수로 나눈 값입니다. 다만 이 값만으로 순서를 정하면 짧지만 중요하지 않은 작업이 과대평가될 수 있으므로 다음 원칙을 함께 적용합니다.
- 출시 차단이나 데이터 손실을 유발하는 작업은 위험 점수를 우선한다.
- 같은 위험 수준에서는
priorityPerDay가 높은 작업을 먼저 배치한다. - 실제 이전 후 Bus Factor가 증가하는지 확인한다.
지식 이전을 어떻게 실행할까?
1단계: 결과물 기준으로 이전 범위를 쪼갠다
막연한 주제인 릴리스 시스템 이해하기 대신 수행 가능한 결과물로 바꿉니다.
- CI 빌드 실패를 재현하고 원인을 분류한다.
- 개발 브랜치에서 릴리스 후보 빌드를 만든다.
- 스토어 업로드 전 검증 항목을 실행한다.
- 실패한 배포를 이전 버전으로 롤백한다.
- Addressables 카탈로그 또는 Unreal Engine 패키지 생성 로그를 분석한다.
- 세이브 버전 N을 버전 N+1로 마이그레이션하고 손상 데이터 복구를 시험한다.
이렇게 하면 지식 이전의 완료 여부를 설명할 수 있습니다.
2단계: 문서와 실습을 묶는다
문서만 전달하면 대체 담당자가 이해했다고 착각하기 쉽습니다. 다음 순서가 효과적입니다.
- 기존 담당자가 전체 흐름과 위험 지점을 설명한다.
- 대체 담당자가 같은 작업을 직접 수행한다.
- 기존 담당자는 결과를 검토하되 키보드를 대신 잡지 않는다.
- 실행 명령, 권한, 실패 사례, 롤백 절차를 런북에 반영한다.
- 대체 담당자가 문서 없이 다시 수행하는 리허설을 진행한다.
문서에는 최소한 다음 항목을 포함합니다.
| 문서 항목 | 포함할 내용 |
|---|---|
| 목적 | 이 시스템이 어떤 일정 또는 출시 조건을 지키는지 |
| 진입점 | 저장소 경로, CI 작업 이름, 콘솔 또는 대시보드 위치 |
| 정상 절차 | 명령, 입력값, 예상 로그, 완료 판정 |
| 장애 대응 | 증상별 원인과 확인 순서 |
| 롤백 | 이전 버전 복구 조건과 실행 방법 |
| 권한 | 필요한 계정, 시크릿, 승인자 |
| 검증 | 테스트와 리허설 기록 |
시크릿 값 자체를 문서에 넣어서는 안 됩니다. 대신 승인된 비밀 저장소의 경로와 접근 요청 절차를 기록합니다.
3단계: 부재 리허설로 Bus Factor를 검증한다
지식 이전이 끝났는지는 담당자가 설명을 잘했는지가 아니라 대체자가 실제로 복구했는지로 판단합니다. 다음과 같은 작은 부재 리허설을 진행합니다.
- 기존 담당자는 일정 시간 동안 질문에 답하지 않는다.
- 대체 담당자가 테스트 환경에서 빌드, 배포 또는 복구를 수행한다.
- 관찰자는 막힌 지점과 문서의 누락을 기록한다.
- 리허설 후 문서, 권한, 자동화 테스트를 업데이트한다.
- 같은 작업을 다시 수행해 독립 수행 여부를 확인한다.
리허설에서 대체 담당자가 성공하면 해당 작업의 독립 담당자 수를 1명 늘릴 수 있습니다. 반대로 옆에서 명령을 불러 주거나 기존 담당자가 문제를 해결했다면 Bus Factor가 증가한 것으로 기록하지 않습니다.
어떤 지식 이전 방식을 선택해야 하는가?
| 상황 | 적합한 방식 | 완료 기준 |
|---|---|---|
| 절차가 정형화됨 | 런북 작성과 독립 실습 | 문서만 보고 성공 |
| 디버깅 노하우가 중요함 | 페어 디버깅과 장애 시나리오 | 새로운 오류를 분류하고 복구 |
| 권한과 배포 단계가 복잡함 | 페어 릴리스와 권한 점검 | 테스트 배포부터 롤백까지 수행 |
| 코드 구조 이해가 필요함 | 코드 워크스루와 작은 수정 | 수정 후 테스트 통과 |
| 반복 작업이 많음 | 자동화 스크립트와 체크리스트 | 사람이 바뀌어도 동일한 결과 |
지식 이전의 목표는 기존 담당자를 복제하는 것이 아닙니다. 핵심 경로를 한 사람이 독점하지 않도록 재현 가능한 절차와 최소 두 명의 독립 수행자를 만드는 것입니다.
운영 회의에서 어떻게 관리할까?
Bus Factor는 한 번 계산하고 끝내는 문서 항목이 아닙니다. 스프린트 계획이나 릴리스 준비 회의에서 다음 항목을 짧게 확인합니다.
- 현재 Bus Factor가 1인 출시 관련 시스템은 무엇인가?
- 이번 스프린트에 대체 담당자 실습을 배치했는가?
- 문서가 현재 코드와 빌드 환경을 반영하는가?
- 접근 권한과 시크릿 만료일을 확인했는가?
- 마지막 부재 리허설은 언제였고 무엇이 실패했는가?
권장 대시보드에는 시스템명, 핵심 작업, 현재 BF, 목표 BF, 마지막 검증일, 다음 이전 작업, 담당자를 표시합니다. 숫자만 크게 보여 주기보다 다음 행동과 연결해야 합니다.
자주 묻는 질문 FAQ
Bus Factor가 2면 안전한가?
안전하다고 단정할 수 없습니다. 두 사람이 같은 오래된 문서와 같은 잘못된 가정만 알고 있을 수 있기 때문입니다. 독립 수행 능력, 권한, 테스트, 부재 리허설 결과를 함께 확인해야 합니다.
문서를 작성하면 Bus Factor가 올라가는가?
문서 작성만으로는 올라가지 않습니다. 대체 담당자가 문서를 보고 실제로 빌드, 디버깅, 배포, 복구를 수행하고 그 결과가 검증되어야 독립 담당자로 집계할 수 있습니다.
팀이 작아서 모든 시스템의 BF를 2 이상으로 만들 수 없다면 어떻게 하는가?
모든 시스템을 동시에 해결하려 하지 말고 출시 차단, 데이터 손실, 보안 권한과 연결된 시스템부터 자동화와 런북으로 위험을 낮춥니다. 목표 인원을 현실적으로 정한 뒤 외부 지원, 교차 교육, 자동 롤백 같은 대체 경로를 함께 설계합니다.
정리
Bus Factor는 핵심 시스템에 지식과 권한이 얼마나 집중되어 있는지 빠르게 보여 주는 지표입니다. 먼저 독립 수행 가능한 사람 수를 작업 단위로 계산하고 시스템별 최소값을 Bus Factor로 기록합니다.
그다음 영향도, 긴급도, 노하우 취약도를 결합해 지식 이전 우선순위를 정합니다. 마지막으로 런북 작성, 실제 실습, 부재 리허설을 완료해야 수치가 현실의 대응 능력을 반영합니다. 목표는 숫자를 낮추거나 높이는 것이 아니라 담당자가 바뀌어도 일정과 출시 절차가 계속 흐르게 만드는 것입니다.
