집중도 계수로 개발자 실가용 시간 산정하기: 스프린트 과부하를 줄이는 방법

TL;DR

스프린트 capacity는 근무일수가 아니라 실제로 약속할 수 있는 개발 시간으로 계산해야 합니다.
기준 근무시간에서 부재와 고정 비개발 시간을 제외한 뒤 집중도 계수와 리스크 버퍼를 적용하면 개발자별 실가용 시간을 구할 수 있습니다.

$$실가용 시간 = max(0, 기준 근무시간 − 부재시간 − 고정 비개발시간) × 집중도 계수 × (1 − 리스크 버퍼)$$

집중도 계수는 개인 평가 점수가 아니라 팀의 업무 환경을 반영하는 계획용 계수입니다.
최근 스프린트 데이터를 바탕으로 보정하고 과도한 스코프를 줄이는 데 사용해야 합니다.

개발자 실가용 시간은 왜 근무시간보다 적은가?

2주 스프린트에서 개발자 한 명의 근무시간을 단순히 80시간으로 계산하면 실제 계획과 차이가 커집니다.
이 시간에는 휴가와 공휴일뿐 아니라 정기 회의, 코드 리뷰, 장애 대응, 기획 논의, 배포 지원, 멘토링이 포함됩니다.

또한 업무를 자주 전환하면 일정 시간 동안 어느 작업에도 완전히 몰입하기 어렵습니다.
이 손실을 컨텍스트 스위칭 비용이라고 부릅니다. 따라서 스프린트 계획에서는 다음 세 가지를 분리해야 합니다.

항목	의미	예시
기준 근무시간	해당 기간의 계약상 또는 팀 기준 근무시간	10일 × 8시간 = 80시간
고정 비개발시간	미리 예정된 회의와 운영 업무	스크럼, 리뷰, 1:1, 온콜
집중도 계수	남은 시간 중 계획한 개발 작업에 안정적으로 사용할 수 있는 비율	0.55, 0.65, 0.75
리스크 버퍼	예측하기 어려운 이슈를 위한 여유 시간	10~20%

핵심은 ‘얼마나 오래 회사에 있었는가’가 아니라 ‘완료를 약속할 수 있는 시간이 얼마인가’를 계산하는 것입니다.

집중도 계수란 무엇인가?

집중도 계수는 순수 작업 가능 시간 중 실제 계획 작업에 사용할 수 있는 비율입니다. 수식으로 표현하면 다음과 같습니다.

$$F = 집중 작업에 사용할 수 있는 시간 ÷ 순수 작업 가능 시간$$

예를 들어 회의와 정기 운영 업무를 제외하고 60시간이 남았지만 지원 요청과 부서 간 협업으로 안정적인 개발 작업에 사용할 수 있는 시간이 약 39시간이라면 집중도 계수는 0.65입니다.

집중도 계수는 능력이나 성실성을 나타내지 않습니다. 같은 개발자라도 다음 조건에 따라 달라집니다.

• 기능 개발에만 집중하는 제품 팀인지 여부
• 라이브 서비스 운영과 장애 대응을 함께 맡는지 여부
• 레거시 코드와 신규 코드의 비율
• 외부 팀이나 플랫폼 팀에 의존하는 작업이 많은지 여부
• 스프린트 중간에 긴급 업무가 자주 들어오는지 여부

따라서 팀원마다 무조건 높은 계수를 적용하거나 모든 팀에 동일한 계수를 적용하면 안 됩니다.

집중도 계수는 어떻게 산정할까?

1단계: 최근 스프린트의 순수 작업 가능 시간을 계산한다

최근 3~5개 스프린트를 기준으로 근무시간에서 휴가, 정기 회의, 고정 운영 업무를 제외합니다.
이때 코드 라인 수나 키보드 입력량처럼 생산성을 감시하는 지표는 사용하지 않는 편이 좋습니다.

대신 다음 자료를 조합합니다.

• 캘린더의 정기 회의 시간
• 온콜과 장애 대응 기록
• 이슈 트래커의 긴급 티켓 수
• 코드 리뷰와 배포 지원에 사용한 대략적인 시간
• 스프린트 회고에서 확인한 중단 업무

정확한 분 단위 기록보다 팀이 합의할 수 있는 일관된 추정 방식이 중요합니다.

2단계: 업무 중단 요인을 분류한다

중단 요인은 고정 업무와 변동 업무로 나눕니다.

구분	계획 반영 방법	예시
고정 업무	기준 근무시간에서 직접 차감	주간 회의, 정기 리뷰
반복 운영 업무	평균 시간을 별도 차감	배포 확인, 빌드 모니터링
변동 업무	집중도 계수 또는 리스크 버퍼에 반영	긴급 버그, 고객 문의
외부 의존성	스코프와 별도로 위험 요소로 관리	API 승인, 아트 리소스 대기

같은 시간을 집중도 계수와 리스크 버퍼에 모두 넣으면 이중 차감이 됩니다.
회의처럼 이미 확정된 시간은 먼저 차감하고 예측하기 어려운 중단만 계수나 버퍼로 반영합니다.

3단계: 평균보다 중앙값을 우선한다

특정 스프린트에 대형 장애가 발생하면 평균값이 실제 업무 환경보다 낮게 나올 수 있습니다.
반대로 휴일이 많았던 스프린트는 계수를 지나치게 높일 수 있습니다.

초기에는 최근 데이터의 중앙값을 사용하고 다음 스프린트가 끝날 때마다 보정하는 방식이 안정적입니다.
계수를 한 번 정한 뒤 고정하지 말고 다음 상황에서 다시 검토합니다.

• 팀 구성원이 바뀐 경우
• 운영 책임이 추가되거나 제거된 경우
• 제품 출시 직전처럼 협업 밀도가 높아진 경우
• 회의 구조나 배포 방식이 바뀐 경우

실가용 시간 계산 공식과 예시

다음 변수로 스프린트 capacity를 계산할 수 있습니다.

• T: 기준 근무시간
• A: 휴가와 공휴일을 포함한 부재시간
• M: 고정 비개발시간
• F: 집중도 계수
• B: 리스크 버퍼
• C: 실가용 시간

$$C = max(0, T − A − M) × F × (1 − B)$$

예를 들어 개발자 한 명의 2주 스프린트 조건이 다음과 같다고 가정해 보겠습니다.

변수	값
기준 근무시간 T	80시간
부재시간 A	8시간
고정 비개발시간 M	14시간
집중도 계수 F	0.65
리스크 버퍼 B	0.15

계산 과정은 다음과 같습니다.

$$C = (80 − 8 − 14) × 0.65 × (1 − 0.15) = 32.05시간$$

따라서 이 개발자에게 안정적으로 약속할 수 있는 개발 작업은 약 32시간입니다.
나머지 시간은 여유가 아니라 회의, 협업, 중단, 문제 해결을 감당하기 위한 현실적인 공간입니다.

실무에서는 소수점 단위의 정확성보다 반올림 규칙을 먼저 정하는 것이 좋습니다.
예를 들어 32.05시간을 32시간으로 내림하면 계획 초과를 줄일 수 있습니다.

스프린트 스코프는 어떻게 줄여야 하는가?

1단계: 사람별 capacity를 합산한다

팀원별 실가용 시간을 계산한 뒤 합산합니다.
단, 역할과 기술이 다르면 단순 합산만으로 완료 가능성을 판단하지 않습니다.

예를 들어 클라이언트 개발자의 시간이 남아도 서버 API가 준비되지 않으면 기능 전체를 완료할 수 없습니다.
따라서 전체 시간과 함께 병목 역할의 capacity도 확인해야 합니다.

2단계: 작업을 예상 시간으로 분해한다

스프린트에 넣을 작업은 개발, 리뷰, 테스트, 배포 준비를 포함한 완료 조건 기준으로 산정합니다.

작업	개발	리뷰·테스트	총 예상시간
저장 기능 구현	16시간	6시간	22시간
설정 화면 수정	8시간	3시간	11시간
긴급 버그 수정	4시간	2시간	6시간
합계	28시간	11시간	39시간

capacity가 32시간인 개발자에게 39시간의 작업을 배정하면 스프린트 시작부터 7시간이 초과됩니다.
이때 개발 속도를 높이도록 요구하기보다 우선순위가 낮은 작업을 다음 스프린트로 이동해야 합니다.

3단계: 약속 영역과 선택 영역을 구분한다

전체 capacity를 모두 확정 작업으로 채우지 말고 약속 영역과 선택 영역을 나눕니다.
예를 들어 실가용 시간 32시간 중 27시간을 필수 작업으로 잡고 5시간은 작은 개선이나 기술 부채에 사용합니다.

영역	비중 예시	운영 방식
필수 약속 작업	80~90%	스프린트 목표에 직접 연결
변동 대응 여유	10~20%	긴급 버그와 협업 이슈 대응
선택 작업	남은 시간	필수 작업 완료 후 착수

80~90%는 보편적인 법칙이 아니라 시작점입니다. 운영 업무가 많은 팀은 약속 영역을 더 낮게 잡고 실제 완료율을 확인하면서 조정해야 합니다.

스토리 포인트와 시간 추정을 함께 사용할 때의 주의점

스토리 포인트를 시간으로 고정 변환하면 추정 체계가 쉽게 왜곡됩니다. 포인트는 작업의 상대적인 복잡도와 불확실성을 표현하는 단위이고 시간은 사람의 가용성을 표현하는 단위이기 때문입니다.

다음과 같이 역할을 분리하는 편이 좋습니다.

• 스토리 포인트: 작업 간 상대적 크기와 복잡도 비교
• 시간 capacity: 이번 스프린트에 실제로 사용할 수 있는 인력 시간
• 과거 throughput: 현재 팀 구성에서 완료 가능한 포인트 범위 예측

예를 들어 최근 팀이 정상적인 capacity에서 평균 28포인트를 완료했고 이번 스프린트의 capacity가 기준의 75%라면 21포인트를 1차 예측값으로 삼을 수 있습니다.

$$예상 throughput = 기준 throughput × 현재 capacity 비율$$

다만 팀 구성, 작업 유형, 장애 빈도가 달라졌다면 이 계산은 참고값에 불과합니다. 포인트와 시간을 정밀하게 환산하기보다 스프린트 목표와 완료 조건을 함께 검토해야 합니다.

팀 운영에 집중도 계수를 적용하는 방법

집중도 계수를 개인 성과 지표로 사용하면 팀원은 계수를 높게 보고하거나 업무 중단을 숨기게 됩니다. 따라서 다음 운영 규칙을 문서로 합의하는 것이 좋습니다.

1. 계수는 성과 평가와 승진 평가에 사용하지 않는다.
2. 개인별 숫자보다 팀의 업무 환경과 역할별 범위를 우선한다.
3. 긴급 업무가 들어오면 같은 시간만큼 기존 스코프를 제거한다.
4. 코드 리뷰, 테스트, 문서화, 배포 지원도 작업 시간으로 인정한다.
5. 스프린트 회고에서 계수와 버퍼가 적절했는지 확인한다.
6. 계수를 높여 과도한 스코프를 수용하지 않는다.

특히 긴급 업무를 추가하면서 기존 작업을 그대로 유지하면 capacity 산정은 의미를 잃습니다. 변경된 업무량을 공개하고 무엇을 뺄지 함께 결정해야 합니다.

스프린트 계획 템플릿

다음 항목을 스프린트 계획 문서나 이슈 템플릿에 넣으면 계산 과정을 반복해서 사용할 수 있습니다.

스프린트 기간:
기준 근무시간:
부재시간:
고정 비개발시간:
집중도 계수:
리스크 버퍼:
실가용 시간:
필수 약속 작업 예상시간:
선택 작업 예상시간:
외부 의존성:
이번 스프린트에서 제외할 작업:

Google Sheets나 Excel에서 열을 나누어 관리한다면 실가용 시간 계산식은 다음과 같이 표현할 수 있습니다.

=MAX(0, 기준근무시간-부재시간-고정비개발시간)*집중도계수*(1-리스크버퍼)

계산 결과만 남기지 말고 각 숫자의 근거도 기록해야 합니다.
그래야 다음 회고에서 회의 시간이 늘었는지 운영 이슈가 많았는지 계수를 조정해야 하는지 확인할 수 있습니다.

자주 묻는 질문 FAQ

집중도 계수는 팀원마다 다르게 적용해야 하나요?

역할과 업무 환경이 다르면 다르게 적용할 수 있습니다. 다만 개인의 능력을 평가하는 숫자가 아니라 업무 중단 수준을 반영하는 계획용 값이어야 합니다.
가능하면 개인 숫자를 공개 비교하기보다 역할별 또는 팀 단위 범위로 관리하세요.

리스크 버퍼와 집중도 계수는 어떻게 구분하나요?

집중도 계수는 반복적으로 발생하는 업무 중단과 컨텍스트 스위칭을 반영합니다.
리스크 버퍼는 발생 여부와 규모를 미리 알기 어려운 버그, 장애, 외부 의존성 지연을 위한 공간입니다. 같은 시간을 두 항목에 중복 반영하지 않아야 합니다.

실가용 시간이 남으면 작업을 더 넣어도 되나요?

필수 작업이 완료되고 품질 기준을 지킬 수 있을 때만 선택 작업을 넣습니다.
남은 시간 전부를 다시 채우면 다음 스프린트의 과부하가 반복될 수 있으므로 기술 부채, 문서화, 자동화처럼 예측 가능한 작은 작업을 우선하는 편이 안전합니다.

정리

집중도 계수를 반영한 실가용 시간 산정은 개발자를 더 세밀하게 통제하는 방법이 아니라 스프린트 약속의 현실성을 높이는 방법입니다.

기준 근무시간에서 부재와 고정 비개발시간을 제외하고 집중도 계수와 리스크 버퍼를 적용하면 팀은 과도한 스코프를 수치로 확인할 수 있습니다.
이후 필수 작업과 선택 작업을 나누고 긴급 업무가 발생할 때 기존 스코프를 줄이는 규칙을 지키면 스프린트 과부하를 지속적으로 낮출 수 있습니다.