목차
- 버스 팩터란?
- 버스 팩터가 낮으면 발생하는 문제
- 버스 팩터 진단하기
- 버스 팩터를 높이는 전략
- 문서화 전략
- 코드 리뷰와 페어 프로그래밍
- 온보딩 프로세스 개선
- 도구를 활용한 지식 공유
- 실천 체크리스트
버스 팩터란?
버스 팩터(Bus Factor)는 “팀에서 몇 명이 버스에 치여 사라지면 프로젝트가 멈추는가?”를 나타내는 지표입니다. 더 부드럽게 표현하면 “복권 당첨 지수(Lottery Factor)”라고도 합니다. 팀원이 복권에 당첨되어 갑자기 퇴사해도 프로젝트가 계속될 수 있는지를 의미합니다.
버스 팩터가 1이라면 특정 한 명만 없어도 프로젝트가 심각한 위기에 처한다는 뜻입니다.
버스 팩터 계산 예시
| 상황 | 버스 팩터 | 위험도 |
|---|
| 모든 핵심 지식이 한 사람에게 집중 | 1 | 매우 위험 |
| 2명이 핵심 시스템을 이해 | 2 | 위험 |
| 3명 이상이 전체 시스템 이해 | 3+ | 안정적 |
| 팀 전체가 대부분의 영역 이해 | N | 매우 안정적 |
버스 팩터가 낮으면 발생하는 문제
1. 업무 병목 현상
특정 개발자만 처리할 수 있는 작업이 생기면 해당 개발자의 일정에 모든 것이 의존하게 됩니다. 휴가, 병가, 퇴사 시 프로젝트 전체가 지연됩니다.
2. 기술 부채 누적
“김대리만 아는 코드”가 늘어나면 다른 사람이 수정하기를 꺼리게 되고, 레거시 코드가 방치됩니다.
3. 의사결정 지연
특정 영역에 대한 판단을 한 사람에게만 의존하면 그 사람이 바쁠 때 의사결정이 멈춥니다.
4. 신규 인력 온보딩 어려움
지식이 문서화되지 않고 특정인의 머릿속에만 있으면 새로운 팀원이 적응하는 데 오랜 시간이 걸립니다.
5. 퇴사 리스크
핵심 인력 퇴사 시 인수인계가 제대로 되지 않아 지식이 유실됩니다.
버스 팩터 진단하기
Git 기반 분석
코드베이스에서 특정 파일이나 디렉토리를 누가 주로 수정하는지 분석합니다.
1
2
3
4
5
6
7
8
9
10
| # 특정 파일의 커밋 기여자 확인
git log --format='%an' -- src/core/payment.js | sort | uniq -c | sort -rn
# 디렉토리별 기여자 분석
git log --format='%an' -- src/auth/ | sort | uniq -c | sort -rn
# 최근 1년간 각 디렉토리별 주요 기여자
git log --since="1 year ago" --format='%an' --name-only | \
awk '/^[a-zA-Z]/ {author=$0; next} /^src/ {print author, $0}' | \
sort | uniq -c | sort -rn
|
진단 체크리스트
각 항목에 대해 “예/아니오”로 답해보세요:
| 질문 | 예 | 아니오 |
|---|
| 특정 시스템을 담당하는 사람이 1명뿐인가? | 위험 | 안전 |
| 해당 담당자 휴가 시 긴급 이슈 대응이 불가능한가? | 위험 | 안전 |
| 시스템 아키텍처 문서가 최신 상태인가? | 안전 | 위험 |
| 배포 프로세스를 2명 이상이 수행할 수 있는가? | 안전 | 위험 |
| 장애 대응 매뉴얼이 문서화되어 있는가? | 안전 | 위험 |
| 코드 리뷰가 다양한 사람에 의해 진행되는가? | 안전 | 위험 |
위험 영역 식별 매트릭스
| 영역 | 담당자 수 | 문서화 상태 | 위험도 | 조치 우선순위 |
|---|
| 결제 시스템 | 1명 | 없음 | 매우 높음 | 1순위 |
| 인증/인가 | 2명 | 부분적 | 높음 | 2순위 |
| API Gateway | 3명 | 양호 | 보통 | 3순위 |
| 프론트엔드 | 4명 | 양호 | 낮음 | - |
버스 팩터를 높이는 전략
1. 지식 공유 세션 운영
정기 기술 공유 미팅
1
2
3
4
| 매주 금요일 오후 4시
- 각자 담당 영역의 최근 변경사항 공유
- 30분 발표 + 15분 Q&A
- 발표 자료는 Confluence/Notion에 아카이빙
|
브라운백 세션
점심시간을 활용한 가벼운 기술 공유:
- 새로 도입한 라이브러리 소개
- 트러블슈팅 경험 공유
- 최신 기술 트렌드 공유
2. 담당자 다중화
| 영역 | Primary | Secondary | 목표 |
|---|
| 결제 시스템 | 김개발 | 이개발 | Secondary도 긴급 이슈 대응 가능 |
| 인증 서버 | 박개발 | 최개발 | 양쪽 모두 배포/롤백 가능 |
| 데이터 파이프라인 | 정개발 | 김개발 | 스키마 변경 리뷰 가능 |
Primary-Secondary 체계 운영 방법:
- Secondary는 Primary의 모든 코드 리뷰에 참여
- 분기별로 역할 교체하여 지식 균형 맞추기
- Secondary도 해당 영역의 작은 기능 개발 경험 쌓기
3. 로테이션 프로그램
1
2
3
4
5
| 분기별 담당 영역 로테이션 예시
Q1: 김개발 - 결제, 이개발 - 인증, 박개발 - 알림
Q2: 김개발 - 인증, 이개발 - 알림, 박개발 - 결제
Q3: 김개발 - 알림, 이개발 - 결제, 박개발 - 인증
|
로테이션 시 주의사항:
- 인수인계 기간 2주 확보
- 인수인계 체크리스트 작성
- 로테이션 후 1개월은 이전 담당자가 멘토 역할
문서화 전략
문서화 우선순위
| 우선순위 | 문서 유형 | 예시 |
|---|
| 1 | 장애 대응 매뉴얼 | 서버 다운 시 복구 절차 |
| 2 | 배포 가이드 | 릴리스 프로세스, 롤백 방법 |
| 3 | 아키텍처 문서 | 시스템 구성도, 데이터 흐름 |
| 4 | API 문서 | 엔드포인트, 요청/응답 스펙 |
| 5 | 개발 환경 설정 | 로컬 개발 환경 구축 가이드 |
좋은 문서의 조건
1. 실행 가능한 가이드
1
2
3
4
5
6
7
| ❌ 나쁜 예시
"서버를 재시작한다"
✅ 좋은 예시
1. SSH로 production 서버 접속
```bash
ssh deploy@prod-api-01.example.com
|
- 현재 실행 중인 프로세스 확인
1
| sudo systemctl status api-server
|
- 서비스 재시작
1
| sudo systemctl restart api-server
|
- 로그로 정상 기동 확인
1
| tail -f /var/log/api-server/application.log
|
```
2. 의사결정 배경 기록 (ADR)
아키텍처 결정 기록(Architecture Decision Record)을 작성합니다:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
| # ADR-001: 메시지 큐로 Kafka 선정
## 상태
승인됨 (2024-03-15)
## 컨텍스트
주문 처리 시스템에서 비동기 메시지 처리가 필요함.
RabbitMQ, Kafka, AWS SQS를 검토함.
## 결정
Kafka를 선정함.
## 이유
- 일 100만 건 이상의 메시지 처리 예상
- 메시지 재처리가 필요한 경우가 많음
- 팀 내 Kafka 운영 경험 있음
## 결과
- Kafka 클러스터 구축 필요
- Consumer 장애 시 재처리 로직 구현
- 모니터링 체계 구축
|
3. 트러블슈팅 위키
실제 발생했던 장애와 해결 방법을 기록합니다:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| # 2024-06-15 결제 서버 OOM 장애
## 증상
- 14:30 결제 API 응답 지연 발생
- 14:35 결제 서버 3대 중 2대 응답 불가
- CloudWatch에서 메모리 사용률 98% 확인
## 원인
- 대량 환불 배치 작업이 메모리를 과다 사용
- 배치 크기 제한 없이 전체 데이터 로드
## 해결
1. 긴급 서버 재시작으로 서비스 복구
2. 배치 크기를 1000건으로 제한하는 코드 수정
3. PR: https://github.com/example/payment/pull/234
## 재발 방지
- 배치 작업 시 페이징 필수 적용
- 메모리 사용량 80% 초과 시 알림 설정
|
문서 유지보수
1
2
3
4
5
6
7
8
9
10
11
12
| # 문서 리뷰 스케줄
monthly:
- 장애 대응 매뉴얼 유효성 검증
- 배포 가이드 최신화 확인
quarterly:
- 아키텍처 문서 전체 리뷰
- 온보딩 가이드 피드백 반영
yearly:
- 전체 문서 대청소
- 사용하지 않는 문서 아카이빙
|
코드 리뷰와 페어 프로그래밍
코드 리뷰 가이드라인
리뷰어 선정 원칙
1
2
3
| 1. 해당 영역 Primary 담당자는 필수 리뷰어
2. Secondary 담당자도 리뷰 참여
3. 주니어 개발자는 학습 목적으로 모든 PR 열람 권장
|
효과적인 리뷰 방법
1
2
3
4
5
6
7
8
| ✅ 좋은 리뷰 코멘트
"이 부분은 기존 PaymentService의 processRefund()와
비슷한 로직인데, 공통화하면 좋을 것 같습니다.
참고: src/services/PaymentService.java:234"
❌ 나쁜 리뷰 코멘트
"이상해 보임"
"이렇게 하면 안 됨"
|
페어 프로그래밍
버스 팩터를 높이는 데 페어 프로그래밍만큼 효과적인 방법은 없습니다.
페어링 시나리오
| 상황 | 드라이버 | 네비게이터 | 효과 |
|---|
| 신규 기능 개발 | 시니어 | 주니어 | 지식 전파 |
| 레거시 코드 수정 | 담당자 | 타 영역 개발자 | 지식 분산 |
| 장애 대응 | 누구든 | 담당자 | 실전 경험 공유 |
| 복잡한 버그 수정 | 번갈아가며 | 번갈아가며 | 다양한 관점 |
페어 프로그래밍 팁
1
2
3
4
| 1. 25분 코딩 + 5분 휴식 (뽀모도로)
2. 30분마다 드라이버/네비게이터 역할 교체
3. 네비게이터는 큰 그림 보기, 드라이버는 구현에 집중
4. "왜 이렇게 했는지" 설명하며 진행
|
온보딩 프로세스 개선
신규 입사자 온보딩 체크리스트
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
| ## Week 1: 환경 설정 및 기본 이해
### Day 1-2
- [ ] 개발 환경 설정 (IDE, Git, Docker 등)
- [ ] 사내 위키/문서 접근 권한 확인
- [ ] Slack/Teams 채널 가입
- [ ] 팀원 소개 및 담당 영역 파악
### Day 3-5
- [ ] 프로젝트 로컬 빌드 및 실행
- [ ] 전체 아키텍처 문서 읽기
- [ ] 간단한 버그 수정 PR 1건 올리기
## Week 2: 시스템 이해
- [ ] 주요 서비스 코드 리딩 (결제, 인증 등)
- [ ] API 문서 숙지
- [ ] 배포 프로세스 참관
- [ ] 담당 예정 영역 페어 프로그래밍 1회
## Week 3-4: 실전 참여
- [ ] 실제 기능 개발 태스크 1건 수행
- [ ] 코드 리뷰 참여 (리뷰어로)
- [ ] 장애 대응 시뮬레이션 참관
- [ ] 온보딩 피드백 제출
|
온보딩 버디 제도
신규 입사자에게 버디를 배정합니다:
| 역할 | 책임 |
|---|
| 버디 | 일상적인 질문 응대, 문화 적응 도움 |
| 멘토 | 기술적 가이드, 코드 리뷰, 성장 방향 논의 |
| 매니저 | 업무 할당, 성과 관리 |
1
2
3
4
| 버디 운영 원칙:
- 입사 후 3개월간 버디 배정
- 버디는 다른 프로젝트/영역 담당자로 선정 (시야 확장)
- 주 1회 30분 1:1 미팅
|
도구를 활용한 지식 공유
1. 내부 기술 블로그/위키
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
| Confluence, Notion, GitBook 등 활용
구조 예시:
├── 아키텍처
│ ├── 시스템 구성도
│ ├── 데이터 흐름
│ └── ADR (아키텍처 결정 기록)
├── 개발 가이드
│ ├── 코딩 컨벤션
│ ├── Git 브랜치 전략
│ └── 코드 리뷰 가이드
├── 운영
│ ├── 배포 가이드
│ ├── 모니터링
│ └── 장애 대응
└── 트러블슈팅
├── 2024년
└── 2023년
|
2. 영상 녹화
복잡한 프로세스는 영상으로 기록:
- 배포 과정 녹화
- 장애 대응 시뮬레이션 녹화
- 아키텍처 설명 세션 녹화
1
2
3
4
| 도구 추천:
- Loom: 간단한 설명 영상
- OBS Studio: 긴 세션 녹화
- Zoom/Google Meet 녹화: 미팅 아카이빙
|
3. 코드 주석과 커밋 메시지
의미 있는 커밋 메시지
1
2
3
4
5
6
7
8
9
10
11
12
| ❌ 나쁜 예
"fix bug"
"update"
"WIP"
✅ 좋은 예
"fix: 결제 실패 시 중복 환불 방지
결제 상태가 'FAILED'인 경우에도 환불 API가 호출되는
버그 수정. 환불 전 결제 상태를 확인하는 검증 로직 추가.
관련 이슈: #234"
|
코드 내 WHY 주석
1
2
3
4
5
6
7
8
| // ❌ WHAT 설명 (불필요)
// i를 1 증가시킨다
i++;
// ✅ WHY 설명 (필요)
// 레거시 시스템과의 호환성을 위해 1-based index 사용
// 참고: https://wiki.example.com/legacy-payment-api
i++;
|
4. 자동화된 지식 추출
1
2
3
4
5
6
7
8
9
| # README 자동 생성 도구
# 코드에서 API 문서 자동 추출 (Swagger, OpenAPI)
# 의존성 그래프 시각화
# 예: 디렉토리 구조 자동 문서화
tree -L 2 --dirsfirst -I 'node_modules|dist|build' > STRUCTURE.md
# 예: Git 기여 통계
git shortlog -sn --all
|
실천 체크리스트
즉시 실행 가능한 액션
| 액션 | 담당 | 기한 | 완료 |
|---|
| 버스 팩터가 1인 영역 리스트업 | 테크리드 | 1주 | [ ] |
| 각 영역별 Secondary 담당자 지정 | 매니저 | 2주 | [ ] |
| 장애 대응 매뉴얼 작성/업데이트 | 각 담당자 | 1개월 | [ ] |
| 주간 기술 공유 세션 시작 | 팀 전체 | 즉시 | [ ] |
| 온보딩 체크리스트 정비 | HR/테크리드 | 2주 | [ ] |
장기 개선 계획
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| Phase 1 (1-3개월): 위험 영역 식별 및 긴급 대응
- 버스 팩터 1인 영역 파악
- Secondary 담당자 지정
- 핵심 문서 작성
Phase 2 (3-6개월): 체계 구축
- 정기 지식 공유 세션 정착
- 코드 리뷰 문화 강화
- 문서 템플릿 및 가이드라인 수립
Phase 3 (6-12개월): 지속적 개선
- 분기별 로테이션 시작
- 버스 팩터 정기 측정 및 리포팅
- 온보딩 프로세스 고도화
|
버스 팩터 개선 지표
| 지표 | 측정 방법 | 목표 |
|---|
| 영역별 담당자 수 | Git 기여 분석 | 모든 영역 2명 이상 |
| 문서 최신화율 | 분기별 리뷰 | 90% 이상 |
| 크로스 리뷰율 | PR 리뷰어 분석 | 타 영역 리뷰 30% 이상 |
| 온보딩 만족도 | 신규 입사자 설문 | 4.0/5.0 이상 |
버스 팩터 관리는 하루아침에 되지 않습니다.
하지만 꾸준히 지식을 공유하고 문서화하는 문화를 만들어가면 팀은 개인에 의존하지 않는 견고한 조직이 됩니다. 좋은 팀은 한 명의 영웅이 아니라 서로의 지식을 나누는 동료들로 이루어진다고 생각합니다.