← 프로젝트 목록으로

업무량 데이터 기반 적정 정원(TO) 산정 및 스킬 기반 인력계획 HR Analytics

2026/10/11 → 2026/10/12

산업/분야

HR인력계획AI기업

직무/기술

HR AnalyticsPython수요예측Claude CodeStreamlitGemini APIpytest

조직 생산성 진단부터 업무량 예측, 적정 정원 산정, 스킬 기반 충원 방식 제안까지 연결한 인력계획 분석 도구

• 개인 프로젝트 — 문제 정의·데이터 설계·분석·대시보드·AI 설명 기능까지 전 과정을 단독으로 수행
• GitHub : GitHub (orgpilot-ai)

※ 모든 데이터는 가상 IT 서비스 기업 Aster Digital(8개 조직, 300명)을 가정해 직접 생성한 합성 데이터입니다. 결과 수치는 방법론을 보여 주기 위한 것이며 실제 조직의 성과가 아닙니다.

프로젝트 한눈에 보기

OrgPilot AI는 “지금 조직별 적정 인원은 몇 명이고, 부족한 인원을 어떻게 채울 것인가”에 업무량 데이터로 답하는 HR Analytics 도구다. 조직별 업무부하율로 과부하·저활용 조직을 진단하고, 월별 업무량을 예측해 필요 FTE와 권장 정원을 산정한다. 예측이 틀렸을 때 판단이 바뀌는지까지 확인해 확실한 충원 대상과 재검토 대상을 구분하고, 스킬 공급·수요 격차를 바탕으로 내부 재배치·외부 채용·기존 인력 육성 인원을 나눠 제안한다. 모든 수치는 Python이 계산하고, Gemini는 계산 결과를 설명만 하도록 설계했다.

핵심 성과

• 업무량 예측 오차(WAPE) 3.5% — 현행 관행에 해당하는 “최근 12개월 평균”(6.6%) 대비 절반 수준
• 예측 오차 ±10% 민감도로 확실한 충원 대상(2개 조직)과 분기별 재검토 대상(4개 조직)을 구분
• 충원 필요 41명을 내부 재배치 11명 + 외부 채용 30명 + 기존 인력 육성 최소 7명으로 분해
• Gemini 응답 속 모든 숫자를 계산 결과와 자동 대조해, 계산에 없는 숫자가 나오면 응답을 버리는 구조 구현
• 테스트 63개로 공식·미래 정보 누출·대시보드 연동까지 자동 검증 (API 호출 없음)

OrgPilot AI 분석 파이프라인

1. 문제 정의

많은 조직의 인력계획은 “작년 정원 + 부서 요청분”으로 정해진다. 이 방식은 연초에 한 번 정해지고 업무량 변화를 반영하지 못한다.

기존 인력계획의 문제

• 성장 조직의 만성 과부하 — 업무가 빠르게 늘어도 정원은 작년 기준이라 인력이 계속 부족함
• 축소 조직의 정원 과다 — 업무가 줄어도 정원은 과거 현원 기준으로 유지됨
• 신규 역량 부족 — AI·클라우드처럼 새로 필요한 스킬은 채용·육성 계획 없이 부족한 채로 남음
• 근거 부족 — “몇 명이 필요한가”를 데이터로 설명하기 어려워 부서 요청에 의존하게 됨

가설

업무량을 시간 단위로 환산해 조직별 부하를 비교하고, 향후 업무량을 예측해 필요 인원을 산정한다면 과거 정원에 의존하지 않는 근거 있는 인력계획을 세울 수 있을 것이다. 또한 스킬 데이터를 함께 보면 “몇 명”뿐 아니라 “어떻게 채울지”까지 제안할 수 있을 것이다.

현원 · 현행 정원 · 필요 FTE — 현행 정원이 업무량을 반영하지 못함

2. 데이터 설계

가상 기업의 HR 데이터를 5개 테이블, 24개월(2024-10 ~ 2026-09)로 설계하고 seed를 고정해 재현 가능하게 생성했다.

테이블	내용	행 수
departments	조직, 기능, 현원	8
employees	직무군, 근속, 재직/휴직	300
workload	월별 업무건수, 건당 표준처리시간	192
skills	직원별 스킬 3~5개, 숙련도 1~5	1,199
staffing_plan	월별 정원(TO)·현원	192

• 조직별로 업무량 성장률, 분기말 계절성, 스킬 분포를 다르게 설계하고, 정원은 “직전 연말 현원 + 부서 요청분”으로 생성해 문제 상황 자체를 데이터에 재현
• 생성기가 알고 있는 ‘진짜 필요 인원’은 테이블에 저장하지 않고 스키마로 검증 — 분석이 정답을 몰래 참조하지 못하도록 차단
• PK/FK, 결측, 현원 일치, 미래 정보 누출, 값 범위 등 무결성 검증 7종을 자동화하고, 일부러 망가뜨린 데이터로 검증 함수가 실제로 오류를 잡는지까지 테스트

3. 분석

3-1. 조직 생산성 진단

업무 1건의 크기가 조직마다 달라(운영 티켓 2.5시간 vs AI 과제 40시간) 건수가 아닌 시간 단위로 부하를 비교했다.

지표	계산식
업무부하율	Σ(업무건수 × 건당 표준시간) ÷ Σ(가용인원 × 140h) — 최근 12개월, 휴직자 제외
1인당 월 초과근무 추정	max(0, 필요시간 − 가용시간) ÷ 가용인원 — 부족분을 초과근무로 메운다고 가정한 상한

• 부하율 > 1.05 과부하, < 0.95 저활용
• AI서비스팀 1.37(1인당 월 초과근무 추정 52.3시간), 클라우드인프라팀 1.21은 과부하, 경영지원팀 0.85는 저활용으로 진단
• 월별 비율의 평균이 아니라 합계의 비율로 계산해 업무가 몰리는 분기말이 결과에 더 크게 반영되도록 설계

3-2. 업무량 예측과 모델 선택

조직별로 log(업무건수) = a + b·t + c·분기말 + d·1월 회귀를 적합하고, 학습 12개월부터 기준점을 한 달씩 옮기며 1~6개월 뒤를 예측하는 Rolling-origin 검증(기준점 12개)을 수행했다.

Rolling-origin 검증 결과 — 모델별 예측 오차

모델	월 단위 오차(WAPE)	정원 산정용 평균 수준 오차
추세+계절성 회귀 (채택)	3.5%	2.4%
XGBoost	4.6%	3.6%
최근 12개월 평균 (현행 관행)	6.6%	5.0%

• 회귀를 채택한 이유 — 조직당 데이터가 24개월뿐이고, 트리 기반 XGBoost는 학습 범위 밖으로 추세를 외삽하지 못해 고성장 조직(AI서비스팀)에서 오차가 2배(6.4% vs 3.3%)였다. 회귀 계수는 그대로 “월 성장률”, “분기말 증가폭”이라 현업에 근거를 설명할 수 있다는 장점도 있다.
• 정원은 평균 수준으로 산정하므로 월별 오차와 별도로 예측 구간 평균 수준의 오차를 지표로 만들었다.
• 합성 데이터라서 가능한 추가 검증으로, 생성기의 숨은 정답과 비교해 8개 조직 모두 예측 필요 FTE가 5% 이내임을 확인했다.

필요 FTE 실적과 12개월 예측 — 과부하 2개 조직 / 저활용 2개 조직

3-3. 적정 정원 산정과 민감도

항목	계산식	비고
필요 FTE	예측 업무건수 × 건당 표준시간 ÷ 140h	향후 12개월 평균
권장 정원	ceil(필요 FTE ÷ 가용비율)	정원에는 휴직자도 포함되므로 머릿수로 환산
인원 격차	권장 정원 − 현원	(+) 충원 필요 / (−) 재배치 검토

조직	현원	현행 정원	권장 정원	인원 격차	±10% 오차 시 판단
AI서비스팀	24	26	39	+15	안정
클라우드인프라팀	38	38	52	+14	안정
SI사업1팀	55	58	61	+6	재검토
정보보안팀	22	23	26	+4	안정
PMO팀	30	30	32	+2	재검토
IT운영팀	50	52	47	−3	재검토
SI사업2팀	48	52	45	−3	재검토
경영지원팀	33	35	28	−5	안정

(+) 충원 필요 / (−) 재배치 검토. ‘안정’은 실제 업무량이 예측과 ±10% 달라도 충원·재배치 방향이 바뀌지 않는다는 뜻이다.

예측이 틀렸을 때 정원 판단이 어떻게 바뀌는지 보기 위해, 실제 업무량이 예측보다 ±10%·±20% 다른 경우를 다시 계산했다. 숫자를 나열하는 데서 그치지 않고 ±10% 안에서 충원/재배치 방향이 뒤집히는지를 판정했다.

예측 오차에 따른 인원 격차 범위

• AI서비스팀·클라우드인프라팀 — 실제 업무량이 예측보다 20% 적어도 충원이 필요한 확실한 충원 대상
• SI사업1팀·SI사업2팀·IT운영팀·PMO팀 — ±10% 오차 안에서 판단이 바뀌므로 정원을 바로 조정하기보다 분기별로 실적을 확인하며 재검토
• 현행 정원은 성장 조직에서 필요 인원보다 13~14명 적고, 축소 조직에서 7명 많아 현행 방식의 한계를 수치로 확인

3-4. 스킬 기반 충원 방식

“몇 명”에 이어 “어떻게 채울지”에 답하기 위해, 숙련도 3 이상(실무 가능) 인원을 공급으로, 직무별 필요 비율 × 권장 정원을 수요로 보고 스킬 격차를 계산했다.

조직별 필요 스킬 격차 (빨강 = 부족 · 파랑 = 여유)

재배치 후보는 최적화 없이 사람이 검토할 수 있는 6개 규칙으로 선정했다. 핵심 규칙은 그 사람이 빠져서 원래 조직에 새로운 스킬 부족이 생기면 제외하는 것이다. 한 조직을 채우려고 다른 조직에 구멍을 내는 결과를 막기 위함이다.

충원 방식: 내부 재배치 / 외부 채용 / 육성

• 충원 필요 41명 = 내부 재배치 11명 + 외부 채용 30명
• AI서비스팀은 ML/DL 부족(11명)이 외부 채용 인원(6명)보다 커서, 채용자 전원이 ML/DL을 갖춰도 부족하다 → 기존 인력 육성 최소 5명이 함께 필요함을 지표로 제시

4. AI 설명 기능 — 숫자는 Python이, 설명은 LLM이

조직별 판단 근거를 자연어로 설명하는 기능을 Gemini로 구현했다. LLM이 숫자를 지어내거나 직접 계산하지 못하도록 다음과 같이 설계했다.

• Python이 계산 결과를 표시 형식(1.37, +15명, +26%)까지 확정해 “사실 목록”으로 전달
• 응답에서 숫자를 모두 추출해 사실 목록과 대조 → 하나라도 없으면 응답을 버리고 계산 기반 템플릿으로 대체
• 사실끼리 계산한 숫자(예: 권장 정원 39 − 현행 정원 26 = 13)도 사실 목록에 없으므로 거부
• 응답이 끝까지 생성되지 않은 경우(토큰 한도 초과)도 사용하지 않음
• 검증을 통과한 응답만 저장해 대시보드에 표시 — 대시보드는 API를 호출하지 않아 비용이 발생하지 않음

AI 설명 — 8개 조직 모두 수치 검증 통과

5. 대시보드

분석 결과를 Streamlit 대시보드 2개 화면으로 구현했다. 대시보드는 직접 계산하지 않고 분석 모듈의 결과만 표시해, 노트북·AI 설명·대시보드의 수치가 항상 같도록 했다.

① 조직 현황 — 부하율 진단과 월별 추이

② 적정 TO 산정 — 예측 오차 슬라이더로 권장 정원을 실시간 재계산

6. Claude Code 활용과 검증

Claude Code가 만든 코드를 그대로 쓰지 않고, 결과를 다른 방법으로 다시 계산하거나 화면·출력을 직접 대조해 오류를 찾았다. 단계별 요청·검증·수정 과정은 개발 기록에 남겼다.

발견한 문제	찾은 방법	조치
Gemini 3의 내부 추론이 출력 토큰을 소모해 응답이 문장 중간에 끊겼는데, 끊긴 문장의 숫자는 맞아서 수치 검증을 통과하고 저장됨	실제 응답 전문을 직접 읽음	응답 완료 여부 검사 추가, 잘린 응답 삭제·재생성, 회귀 테스트
0.1×3×40 = 12.000000000000002 → 올림하면 정원 1명 과다 산정	손계산 테스트 작성	소수 6자리 반올림 후 올림, 회귀 테스트
예측 오차 슬라이더를 움직이면 차트는 바뀌는데 상단 카드 수치는 그대로(+41 vs +65)	노트북 민감도 표와 화면 숫자 대조	카드도 같은 가정으로 계산, 자동 테스트 추가
재배치 규칙이 부족 스킬 종류가 많은 조직에 유리하게 작동	결과의 원인 추적	결과를 원하는 대로 맞추려 규칙을 바꾸지 않고 한계로 명시, “확정안이 아닌 검토 후보”로 표기
공식을 테스트 안에서 다시 계산해 모듈이 틀려도 통과하는 테스트	테스트 코드 검토	모듈의 실제 출력을 대조하는 테스트로 교체

검증 원칙

• 손계산 가능한 최소 예제로 공식 검증 (예: 10명 × 140h = 100건 × 14h → 부하율 정확히 1.0)
• 검증 함수 자체를 검증 — 일부러 망가뜨린 데이터로 실제로 실패하는지 확인
• 가짜 모델을 넣어 학습 데이터가 항상 예측 대상보다 과거인지 모델 함수 안에서 직접 확인 (미래 정보 누출 방지)
• LLM 출력은 테스트에서만이 아니라 실행 중에도 매번 기계적으로 대조

7. 기술 스택

영역	기술
데이터 처리	Python 3.12 · pandas · NumPy · SQLite
예측	추세+계절성 회귀(NumPy 최소제곱, 채택) · XGBoost(비교 모델)
LLM	Gemini API (google-genai) · 응답 수치 검증 · 응답 캐시
시각화·대시보드	Streamlit · Plotly · matplotlib
테스트	pytest(63개) · Streamlit AppTest
개발 도구	Claude Code · Git/GitHub · Playwright(화면 캡처 자동화)

8. 한계

• 합성 데이터의 생성 구조를 알고 설계했으므로, 여기서 예측이 잘 맞는다고 실제 조직에서도 잘 맞는다는 근거는 되지 않는다. 실제 적용 시 업무량 측정 체계(티켓·공수 데이터)의 품질 검증이 먼저 필요하다.
• 1인당 가용시간(140h), 건당 표준시간, 조직별 필요 스킬 비율은 가정값이며 실제로는 직무분석·현업 인터뷰로 정해야 한다.
• 데이터가 24개월이라 12개월 앞 예측은 직접 검증하지 못했고, 이를 ±10% 민감도로 보완했다.
• 스킬 매칭은 본인 희망, 경력 경로, 성과, 업무 인계를 반영하지 않으므로 결과는 검토 후보 목록이다.
• AI 설명 검증은 숫자의 존재만 확인하며, 맞는 숫자를 다른 항목에 붙이는 오류는 잡지 못한다.

9. 프로젝트를 통해 얻은 점

인력계획에서 중요한 것은 “몇 명이 필요한가”라는 하나의 숫자보다, 그 숫자가 얼마나 확실한지와 어떻게 채울 수 있는지를 함께 제시하는 것이라는 점을 배웠다. 같은 충원 판단이라도 예측 오차에 흔들리지 않는 조직과 분기별로 다시 봐야 하는 조직을 구분하자 의사결정에 바로 쓸 수 있는 형태가 되었고, 스킬 데이터를 더하자 채용만으로는 채울 수 없는 역량 공백(육성 필요)이 드러났다.

또한 생성형 AI 개발 도구를 쓰면서 개발 속도보다 검증 설계가 결과의 신뢰도를 결정한다는 점을 확인했다. 수치 검증을 통과한 AI 응답이 사실은 중간에 잘린 문장이었던 사례처럼, 하나의 검증만으로는 충분하지 않았다. 출력을 직접 읽고, 다른 방법으로 다시 계산하고, 화면과 계산 결과를 대조하는 과정을 반복하며 신뢰할 수 있는 HR 분석 도구를 만드는 방법을 익혔다.