26S06h1

QK·약 8시간 전

네. 이 규모에서는 “노드당 몇 명” 같은 단순 비율로 산정하면 거의 반드시 왜곡됩니다.

지금 환경은 내년에 약 1,600~1,700 bare-metal node / 약 10개 K8s cluster / 수천 namespace / 수천~7천 사용자 / K8s+Cilium+AIStor+CNPG+Kafka+OpenEBS+Observability+GitOps 수준이므로, 저는 ① 업무량 기반 Bottom-up 산정 → ② 자동화 효과 반영 → ③ 24×7/휴가/장애 여유율 반영 → ④ 노드/클러스터 비율로 sanity check 하는 4단계 방식을 권합니다.

특히 Google SRE도 인력 산정에서 단순 티켓 수보다 실제 반복 운영 업무(toil)에 들어가는 시간을 측정하고, 운영 업무가 전체 시간의 50%를 넘지 않도록 관리하는 방식을 제시합니다. (Google Cloud)

1. 먼저 "운영인력"을 업무영역으로 쪼개야 합니다

현재 말씀하신 운영모델 기준이라면 저는 다음처럼 나누겠습니다.

영역	주요 업무	내년 산정
Platform/K8s	K8s, Kubespray, kubelet, containerd	O
Network	Cilium, BGP, ECMP, ClusterMesh, NIC/RDMA	O
Storage	AIStor, OpenEBS, filesystem	O
DB/Middleware	CNPG, Kafka, Redis 등	O
OS/Hardware	RHEL, firmware, HW acceptance	△
Observability	Prometheus, Grafana, OpenSearch, Thanos	O
DevOps/GitOps	GitLab, ArgoCD, AWX, Ansible, Nexus	O
Security	Keycloak, OPA, Kyverno, Vault 등	△
Performance/Capacity	성능분석, capacity planning, tuning	O
Architecture/Governance	Architecture, CMDB, configuration, lifecycle	O
Service Desk	사용자 요청/namespace/resource	별도 또는 L1
Application	Spark/StarRocks/Trino/Airflow 등	별도

여기서 중요한 것은 Application 운영인력과 Platform 운영인력을 섞지 않는 것입니다.

예를 들어:

Spark job이 느리다 → Platform이 책임지는 범위는 CPU/NUMA/network/storage/K8s/resource 쪽이고, Spark SQL이나 application code 최적화는 Data Platform 쪽

으로 경계를 명확히 해야 합니다.

2. 가장 중요한 것은 "FTE = 업무시간 ÷ 가용시간"

제가 가장 추천하는 공식은 이것입니다.

기본식

FTE = \frac{\sum (업무량_i \times 건당소요시간_i)} {연간 생산가능시간}

그런데 실제 운영에서는 이것만으로 부족합니다.

그래서:

FTE = \frac{운영업무시간 + 장애시간 + 프로젝트시간 + 관리시간} {1인당 실질가용시간}

으로 잡는 것이 좋습니다.

3. 1인당 1년을 1,800시간으로 보면 안 됩니다

예를 들어 근무시간이:

8시간 × 5일 × 52주 = 2,080h

라고 해도 실제 운영에 사용할 수 있는 시간은 훨씬 적습니다.

예시:

항목	시간
연간 근무	2,080h
휴가/교육/회의	-280h
조직/보고/공통업무	-200h
실제 업무 가능	1,600h

그리고 운영조직은 이 1,600시간을 100% 채우면 안 됩니다.

저라면 70~75% utilization을 capacity 기준으로 잡겠습니다.

즉,

1 FTE \approx 1,100~1,200 productive\ hours/year

정도로 잡습니다.

이렇게 해야 장애, 긴급변경, 야간작업, 휴가, 교육 등을 흡수할 수 있습니다.

4. 그리고 "업무를 건수 × 시간"으로 바꿉니다

예를 들어 K8s 운영을 이렇게 쪼갭니다.

Kubernetes 운영

업무	연간 건수	건당 실작업	연간 h
Node 신규 인수	800	1.5h	1,200
Node 장애	400	1.5h	600
Node maintenance	800	1h	800
K8s upgrade	10 cluster	80h	800
K8s configuration change	300	1h	300
장애 RCA	100	4h	400
Performance tuning	100	6h	600
합계			4,700h

그러면 K8s 운영만:

4700 / 1150 \approx 4.1 FTE

입니다.

이런 식으로 모든 영역을 계산합니다.

5. 특히 지금 환경에서는 "Node 수"보다 "운영 이벤트"를 세는 게 중요합니다

예를 들어 내년에 1,600 node가 된다고 해서

1,600 / 100 = 16명

같이 계산하면 안 됩니다.

왜냐하면 자동화 수준에 따라 같은 1,600 node라도 업무량이 완전히 달라지기 때문입니다.

예

Node 1대 추가에

수작업

HW 확인
→ BIOS
→ RHEL
→ NIC
→ bonding
→ sysctl
→ containerd
→ kubelet
→ Cilium
→ monitoring
→ acceptance
→ documentation

을 사람이 하면 3~5시간이 걸릴 수 있습니다.

반면

PXE
→ Ansible
→ Kubespray
→ ArgoCD
→ monitoring auto-registration
→ acceptance script

가 되어 있으면 사람은 20~40분만 개입할 수도 있습니다.

따라서 인력산정에서 자동화율을 변수로 넣어야 합니다.

6. 저는 다음과 같은 "Automation Factor"를 넣겠습니다

예를 들어 업무별로:

자동화 수준	Human effort
Manual	100%
Script	60%
Ansible/AWX	40%
GitOps	25%
Full self-service	10~15%

예를 들어 node provisioning 1,000건이 있고 원래 3h라면:

Manual

1000×3=3000h

Ansible

3000×0.4=1200h

GitOps/self-service

3000×0.15=450h

즉 2,550시간 = 약 2.2 FTE가 차이납니다.

이게 지금 조직에서는 굉장히 중요합니다.

플랫폼 엔지니어링에서는 반복적인 toil을 줄이는 것이 핵심이며, 실제로 업무량을 "티켓 수"보다 엔지니어가 반복 작업에 소비한 시간으로 측정하는 접근이 권장됩니다. (Platform Engineering)

7. 그래서 저는 "업무량 × 난이도 × 자동화율" 모델을 추천합니다

실제로 Excel을 만들 때는 다음 컬럼을 만듭니다.

Domain	Activity	Driver	Annual Volume	Manual Time	Automation	Human Time	Annual Hours
K8s	Node onboarding	node	800	3h	30%	0.9h	720
K8s	Node failure	node	400	2h	20%	1.6h	640
K8s	Upgrade	cluster	10	80h	50%	40h	400
Network	BGP incident	incident	80	3h	20%	2.4h	192
Storage	AIStor maintenance	cluster	10	60h	40%	36h	360
Config	Change	change	500	1.5h	60%	0.6h	300
Performance	Tuning	case	100	8h	10%	7.2h	720

그리고:

Annual\ FTE = \frac{Annual\ Hours}{1,150}

로 계산합니다.

8. 그런데 이것만으로도 부족합니다: "상시 운영 FTE"를 별도로 계산해야 합니다

운영조직에는 업무량으로 계산하기 어려운 것이 있습니다.

예를 들어:

장애 대응
On-call
모니터링
변경 승인
장애 escalation
보안 대응
capacity monitoring

입니다.

따라서 저는 크게 3개의 FTE pool로 나누겠습니다.

A. BAU Operations

일상적인 운영

monitoring
incident
request
maintenance
patch
backup
certificate
account
node
storage
network

B. Engineering

개선/자동화

GitOps
Ansible
automation
performance tuning
architecture
observability
self-service
capacity optimization

C. Project / Expansion

내년도 증설과 migration

800 → 1600 nodes
new cluster
GPU cluster
AIStor expansion
network expansion
new software
K8s upgrade
GitLab migration
CMDB implementation

이렇게 분리해야 합니다.

9. 특히 내년에는 "증설 업무"를 별도 FTE로 잡아야 합니다

이게 매우 중요합니다.

예를 들어 올해 800 node를 운영하다가 내년 말 1,600 node가 된다고 합시다.

그럼 평균 운영대수는 대략:

(800+1600)/2 = 1,200

입니다.

따라서 BAU 운영은 1,200 node 기준으로 계산하고,

별도로:

800\ node\ expansion

에 대한 project workload를 추가해야 합니다.

즉,

"내년에는 1,600 node니까 1,600 node 운영인력"

이 아니라

평균 운영량 1,200 node + 800 node expansion workload

입니다.

10. 제가 현재 환경이라면 이렇게 모델링하겠습니다

가정:

올해 말: 800 nodes
내년 말: 1,600 nodes
평균: 1,200 nodes
K8s cluster: 10
사용자: ~7,000
namespace: ~6,000
Kubernetes/Data Platform 중심
Application team은 제외
24×7 장애 대응 포함
자동화/GitOps 적극 적용

1차 예상 FTE 구조

영역	FTE
Platform/K8s	4.0
Network/Cilium/RDMA	2.5
Storage/AIStor/OpenEBS	3.0
DB/Middleware	2.0
OS/Hardware	3.0
Observability	1.5
DevOps/GitOps/Automation	2.5
Security/Platform policy	1.0
Performance/Capacity	2.0
Architecture/Governance/CMDB	1.5
Incident/Service Operations	2.0
합계	25.0 FTE

즉 제가 지금까지 알고 있는 환경만 놓고 1차 budgetary estimate를 한다면 약 24~27 FTE를 중심값으로 잡겠습니다.

그리고 이건 상당히 중요한 포인트입니다.

이 숫자는 "1,600 node라서 25명"이 아닙니다.

오히려:

1,200 average nodes + 800 node expansion + 10 clusters + 6,000 namespaces + 7,000 users + platform stack complexity + 24×7 requirement

에서 나온 숫자입니다.

11. 그리고 "26명"을 그대로 유지할지 판단하는 방법

이전에 이야기했던 약 26명 규모가 있다면, 저는 올해/내년을 이렇게 비교하겠습니다.

올해

800 node

26 FTE
↓
800 nodes

내년

1,600 node

26 FTE
↓
1,600 nodes

겉으로 보면 생산성이 2배가 됩니다.

하지만 실제로는:

자동화
GitOps
AWX
ArgoCD
표준화
self-service
CMDB
monitoring

으로 인해 사람이 처리해야 하는 workload가 2배까지 증가하지 않도록 만드는 것이 목표입니다.

예를 들어:

	올해	내년
Node	800	1,600
Cluster	5	10
Namespace	3,000	6,000
User	4,000	7,000
FTE	24	26
Node/FTE	33	62
Namespace/FTE	125	231

이렇게 되면 경영진에게는

"인프라는 2배 증가하지만 운영인력은 8% 증가"

라는 이야기를 할 수 있습니다.

그 대신 이 숫자가 성립하려면 자동화율과 운영 KPI를 같이 제시해야 합니다.

12. 그래서 저는 "FTE 산정표"를 3개 시나리오로 만들겠습니다

이게 경영진 설득에는 훨씬 좋습니다.

Scenario A — Conservative

자동화가 예상보다 느림.

	FTE
BAU	20
Expansion	5
Engineering	4
Management/Governance	2
Total	31

Scenario B — Target

현재 추진 중인 GitOps/자동화가 정상적으로 정착.

	FTE
BAU	17
Expansion	4
Engineering	3
Governance	2
Total	26

Scenario C — Automation

Self-service 및 자동화가 상당히 성숙.

	FTE
BAU	14
Expansion	3
Engineering	3
Governance	2
Total	22

그러면 26명은 "임의의 숫자"가 아니라 Target Operating Model의 결과가 됩니다.

13. 그리고 반드시 "24×7 coverage"를 별도로 검증해야 합니다

이 부분을 빼먹으면 인력산정이 크게 틀어집니다.

예를 들어 한 명이 24×7을 책임지는 구조는 안 됩니다.

실제로는:

Primary
Secondary
Escalation

이 필요합니다.

예를 들어 최소:

Week 1 : A / B
Week 2 : C / D
Week 3 : E / F
Week 4 : G / H

처럼 돌아가야 합니다.

따라서 On-call 자체가 별도 FTE requirement를 만들어냅니다.

특히 장애가 잦은 환경에서는 단순 "장애 건수"보다 실제 interrupt 시간을 측정해야 합니다. Google도 이런 이유로 ticket/request 자체보다 toil 시간을 측정하도록 권고합니다. (Google Cloud)

14. 저는 내년도 산정을 다음 공식으로 최종 확정하겠습니다

실무적으로는 이 식 하나로 정리할 수 있습니다.

\boxed{ FTE = \frac{ BAU\ Workload + Incident + OnCall + Expansion + Engineering + Governance }{ 1인당\ 생산가능시간 } }

그리고 각 workload를 다시:

Workload = Volume \times Standard\ Effort \times (1-Automation\ Rate)

로 계산합니다.

여기에 마지막으로:

Required\ FTE = Calculated\ FTE \times Risk\ Buffer

를 적용합니다.

저라면 Risk Buffer 10~15% 정도를 두겠습니다.

15. 이 모델의 핵심은 "운영업무 Catalog"입니다

따라서 바로 인원부터 정하지 말고 먼저 아래 표를 만드는 게 좋습니다.

예

ID	업무	Driver	현재/년	내년/년	건당시간	자동화
K8S-01	Node 인수	node	400	800	2h	60%
K8S-02	Node 장애	node	200	400	2h	30%
K8S-03	Cluster upgrade	cluster	5	10	80h	50%
NET-01	Network incident	incident	40	80	4h	20%
STG-01	AIStor maintenance	cluster	5	10	60h	40%
STG-02	Storage incident	incident	50	100	4h	20%
CFG-01	Configuration change	change	300	600	1h	70%
SW-01	SW upgrade	product	30	50	8h	40%
PERF-01	Performance tuning	case	50	100	8h	20%
CAP-01	Capacity analysis	month	12	12	20h	30%
GOV-01	Architecture review	case	50	100	4h	20%

이걸 K8s / Network / Storage / OS / Middleware / Observability / DevOps / Security / Performance / Capacity / Governance 전체에 대해 만들면 됩니다.

16. 그리고 이 표는 향후 실제 운영관리 체계와 연결됩니다

이게 제가 보기에는 가장 중요합니다.

단순히 HR용 FTE 계산표를 만들지 말고:

             ┌───────────────┐
             │ Service Catalog│
             └───────┬───────┘
                     ↓
             ┌───────────────┐
             │ Work Catalog  │
             └───────┬───────┘
                     ↓
        ┌────────────┴────────────┐
        ↓                         ↓
   Volume Driver            Standard Effort
        ↓                         ↓
        └────────────┬────────────┘
                     ↓
              Automation Factor
                     ↓
               Annual Hours
                     ↓
                    FTE
                     ↓
              Role / Skill Mix

으로 만들어야 합니다.

그러면 나중에:

"AIStor 노드가 128 → 256으로 증가하면 Storage FTE가 몇 명 늘어나나?"

"K8s cluster가 10 → 15개가 되면?"

"namespace가 6천 → 1만개가 되면?"

"GitOps 자동화율을 60% → 90%로 올리면?"

을 Excel에서 바로 simulation할 수 있습니다.

이게 Capacity Management의 Workforce 버전입니다. ITIL의 capacity 관점에서도 단순 headcount보다 demand와 available capacity를 비교하고 미래 시나리오를 보는 접근이 맞습니다. (ITIL)

제가 권하는 최종 산정 구조

현재 상황이라면 저는 3단계로 보고서를 만들겠습니다.

① 경영진용

"2027 Platform Operations FTE Plan"

2026                     2027
800 nodes     ───────→   1,600 nodes
5 clusters    ───────→   10 clusters
4,000 users   ───────→   7,000 users

FTE 24        ───────→   FTE 26

Infrastructure +100%
Operations FTE +8%

그리고 핵심 메시지:

인프라 규모는 약 2배 증가하지만, 표준화/GitOps/자동화를 통해 운영인력 증가는 최소화한다.

② 관리용

Domain × Workload × FTE

→ K8s 4.0
→ Storage 3.0
→ Network 2.5
→ OS/HW 3.0
→ ...

③ 실제 운영용

Work Catalog

→ 어떤 업무가
→ 얼마나 발생하고
→ 몇 시간이 걸리고
→ 얼마나 자동화되어 있고
→ 어느 역할이 수행하는지

까지 관리합니다.

그리고 여기서 한 단계 더 나가면 좋습니다.

지금까지 말씀해주신 현재 26명 체계와 올해 800 node → 내년 1,600 node/약 10 cluster라는 조건을 기준으로 제가 다음 단계에서 실제로 2027 운영인력 산정 Excel 모델 형태로 만들어드릴 수 있습니다.

그때는 단순히 26명이라고 찍는 것이 아니라,

① K8s / Network / Storage / OS / Middleware / Observability / DevOps / Security / Performance / Capacity / Governance별 업무 Catalog → ② 월별 workload → ③ 자동화율 → ④ 연간 MH → ⑤ FTE → ⑥ Junior/Senior 비율 → ⑦ 24×7 On-call → ⑧ 800→1,600 node 증설 → ⑨ Conservative/Target/Automation 3개 시나리오

까지 계산해서 "왜 24명인지 / 왜 26명인지 / 왜 30명이 필요한지"를 숫자로 설명할 수 있는 모델로 만드는 게 가장 좋습니다. (platformengineering.org)

특히 지금 규모에서는 "노드당 FTE"보다 "업무량 × 자동화율 × 복잡도 × 24×7 coverage" 모델이 훨씬 설득력이 있습니다.

인력 산정은 "감으로 몇 명" 이 아니라 ① 업무량(상향식) ② Toil 예산 상한 ③ On-call 커버리지 하한, 이 세 가지를 각각 계산해서 큰 쪽을 택하는 방식이 실무에서 가장 방어 가능한 정량적 근거가 됩니다. 하나씩 보겠습니다.

1. 접근 구조

(A) 상향식 업무량 산정        →  월간 필요 작업시간(hr) 산출
(B) Toil 예산 규칙(50/25/25)  →  1인당 "감당 가능한" 운영시간 상한
(C) On-call 구조적 하한        →  24/7 대응을 위한 최소 인원(업무량과 무관)

최종 필요 인원 = max( A/B로 나온 FTE,  C의 최소인원 ) + 전문분야별 버스팩터 보정

A만 계산하면 "업무는 감당되는데 새벽에 깨울 사람이 3명뿐"인 상황이 생기고, C만 보면 업무량 대비 과다/과소 배치가 됩니다. 반드시 둘 다 계산해야 합니다.

2. (A) 상향식 업무량 산정

지난 대화의 5개 관리영역 + 인시던트 대응을 "반복 발생하는 작업 단위 × 빈도 × 단위 소요시간"으로 쪼갭니다.

관리영역	대표 작업 단위	빈도(예시)	단위 소요시간(예시)	월간 시간
성능관리(신규인수)	노드 1대 인수 점검(HW/OS baseline)	신규 노드 수/월	2~4h	빈도×시간
성능관리(튜닝)	튜닝 사이클 1건(관측→적용→검증)	활성 튜닝 이슈 수/월	8~16h	〃
용량관리	캐패시티 리뷰 + 증설 조치	월 1회 정례 + 임계치 알림 대응	4h(정례)+2h/알림	〃
설정관리	Helm/Ansible 변경 1건(PR리뷰+적용+검증)	변경 건수/월	1~3h	〃
자원관리	리소스 요청 검토/쿼터 조정	요청 건수/월	0.5~2h	〃
SW관리	패치/버전업 1건(테스트+롤아웃)	패키지/이미지 수 × 패치주기	2~6h	〃
인시던트 대응	Sev별 대응(트리아지+복구+포스트모템)	과거 티켓 이력 또는 업계 추정	Sev1: 4~8h, Sev2: 2h, Sev3: 0.5h	〃
문서/카탈로그 유지	ADR/카탈로그 갱신	변경 발생시	0.5~1h	〃

계산 방법
1. 지금 조직은 신생 플랫폼이라 이력 데이터가 없으니, 처음엔 위 표처럼 업계 추정치로 초안을 만듭니다.
2. 1~2개월간 실제로 시간 트래킹(Jira 티켓에 소요시간 기록 등)을 해서 실측값으로 교체합니다. 이게 가장 정확한 방법입니다.
3. 전체를 합산 → 월간 총 필요 작업시간(H_total)

3. (B) Toil 예산으로 FTE 환산

Google SRE의 유명한 규칙을 그대로 씁니다: 엔지니어 1인당 운영성 업무(toil)는 근무시간의 최대 50%까지만. 나머지 50%는 자동화/개선 프로젝트에 써야 운영 부하가 시간이 갈수록 줄어드는 선순환이 생깁니다. 이걸 안 지키면 사람을 늘려도 계속 부족합니다(자동화가 안 되니까).

1인당 월 총 가용시간          : 160h (표준 근무시간 기준)
  - 회의/1:1/행정 등 오버헤드  : -20%  → 32h 차감
  - 휴가/공휴일 평균 안분      : -10%  → 16h 차감
= 순수 작업 가능시간           : 약 112h/월

Toil 예산(50%)                : 약 56h/월/인   ← 이 값이 (A)의 총량을 나눌 분모
개선/자동화 예산(50%)         : 약 56h/월/인   ← 별도 프로젝트 배정(신규 기능, 자동화 스크립트 등)

필요 인원(업무량 기준) = H_total ÷ 56h

예: 위 표를 다 채워서 H_total이 월 450시간 나왔다면 → 450 ÷ 56 ≈ 8.0명

참고: 이 56h는 "운영 순수 작업시간"만 반영한 값이라, 처음엔 보수적으로(56h가 아니라 40h 정도로) 잡아서 자동화 시간을 더 확보하는 조직도 많습니다. 자동화가 진행될수록 H_total 자체가 줄어드니, 분모를 늘리는 것보다 H_total을 줄이는 방향(=자동화)이 정공법입니다.

4. (C) On-call 구조적 하한

이건 업무량과 무관하게, "사람이 번아웃 없이 24/7 대응 가능한 최소 인원" 문제입니다. Google SRE Book 기준:

커버리지 방식	최소 인원	비고
단일 사이트 24/7 (Primary+Secondary, 주 단위 순환)	8명	1인당 약 8주에 한 번 온콜, 번아웃 방지선
2개 지역 Follow-the-sun 24/7	사이트당 6명	야간 부담 분산
업무시간만 대응(비즈니스아워, 야간은 베스트에포트/에스컬레이션)	3~4명	Primary+Backup 주 단위 순환으로도 가능
2~3명 뿐인 팀에서 억지로 24/7 순환	비권장	"죽음의 나선"(이탈 시 즉시 붕괴) 경고가 많음

적용 방법

지금 스택(Cilium, Vault, CNPG, Keycloak 등)에서 야간 장애가 매출/SLA에 직결되는지를 먼저 판단하세요. 아니라면 처음부터 24/7을 만들 필요 없이 "업무시간 대응 + Sev1만 에스컬레이션" 구조로 시작해 3~4명으로도 가능합니다.
24/7이 필요하다고 판단되면, (A)(B)에서 나온 인원이 8명 미만이더라도 온콜 목적만으로 8명(또는 최소 6명)까지 채용을 맞춰야 합니다. 이때는 업무량 대비 남는 시간을 자동화/개선 프로젝트에 명시적으로 배정하면 낭비가 아닙니다.

5. 전문분야 보정 (버스팩터)

스택이 이질적입니다: 네트워킹(Cilium/NIC), 스토리지(OpenEBS/CNPG), 보안/IAM(Vault/Keycloak/Kyverno), 플랫폼(K8s 자체/AWX/Helm). 총원이 계산상 6~8명이어도 한 영역에 전문가가 1명뿐이면 그 사람 휴가/이탈 시 그 영역 전체가 마비됩니다.

원칙: 각 전문 영역에 최소 2명(주+부)을 배치하되, 인원이 부족하면 영역을 넓게 겸직(예: 네트워킹+플랫폼 겸임)시켜서 최소 2인 커버리지를 우선 확보하는 쪽을 인원 늘리는 것보다 먼저 검토하세요.
계산상 FTE가 5명인데 전문영역이 4개라면, 실제로는 "각 영역 2인 크로스커버" 조건을 만족 못 하므로 6명(각 영역 최소 1.5명 겸직 커버 가능한 수준)으로 올리는 게 현실적입니다. 즉 (A)(B)(C) 계산 결과에 "영역 수 × 최소 커버리지"라는 하한을 하나 더 체크하세요.

6. 검증·재조정 절차 (정량 모델을 살아있게 유지하는 법)

분기별 재계산: (A) 표의 빈도/단위시간을 그 분기 실측치로 교체 → FTE 재산출
자동화 효과 추적: 특정 작업(예: 설정 변경, 신규 노드 인수)의 단위 소요시간이 자동화 스크립트 도입 후 얼마나 줄었는지 기록 → H_total 감소 → 이론상 인원 여유 발생 → 그 여유를 신규 클러스터/서비스 확장에 재배치할지, 실제 감원할지는 성장 계획과 맞춰 판단
온콜 건강도 지표: 주당 페이지 수(목표 ≤2회/인), MTTA, MTTR을 추적해서 (C)의 인원이 실제로 지속가능한지 검증
밴치마크 교차검증(참고용, 절대 기준 아님): 자동화 성숙도에 따라 "엔지니어 1인당 관리 서버 수"가 업계에서 널리 인용되지만 편차가 매우 커서(수십~수백 대), 이 숫자만으로 산정하지 말고 어디까지나 (A)(B)(C) 결과의 상식 검증용으로만 쓰세요.

7. 다음 액션 제안

지금 단계(이력 데이터 없음)에서는:
1. 위 표 형태로 스프레드시트를 만들어 5개 관리영역 + 인시던트 작업을 나열
2. 각 항목에 초기값(업계 추정치)을 넣어 1차 FTE 산출
3. 8~12주간 실제 시간 트래킹 병행
4. 실측치로 재계산 + 온콜 필요 여부 결정 → 최종 헤드카운트 확정

원하시면 이 계산을 엑셀/스프레드시트 형태로 만들어서 실제 숫자(노드 수, 서비스 수, 예상 변경 빈도 등)를 넣으면 바로 FTE가 나오는 계산기로 만들어드릴 수 있습니다.

engineer

이전 포스트

26S06g2

다음 포스트

26S06h1

1. 먼저 "운영인력"을 업무영역으로 쪼개야 합니다

2. 가장 중요한 것은 "FTE = 업무시간 ÷ 가용시간"

기본식

3. 1인당 1년을 1,800시간으로 보면 안 됩니다

4. 그리고 "업무를 건수 × 시간"으로 바꿉니다

Kubernetes 운영

5. 특히 지금 환경에서는 "Node 수"보다 "운영 이벤트"를 세는 게 중요합니다

예

6. 저는 다음과 같은 "Automation Factor"를 넣겠습니다

Manual

Ansible

GitOps/self-service

7. 그래서 저는 "업무량 × 난이도 × 자동화율" 모델을 추천합니다

8. 그런데 이것만으로도 부족합니다: "상시 운영 FTE"를 별도로 계산해야 합니다

A. BAU Operations

B. Engineering

C. Project / Expansion

9. 특히 내년에는 "증설 업무"를 별도 FTE로 잡아야 합니다

10. 제가 현재 환경이라면 이렇게 모델링하겠습니다

1차 예상 FTE 구조

11. 그리고 "26명"을 그대로 유지할지 판단하는 방법

올해

내년

12. 그래서 저는 "FTE 산정표"를 3개 시나리오로 만들겠습니다

Scenario A — Conservative

Scenario B — Target

Scenario C — Automation

13. 그리고 반드시 "24×7 coverage"를 별도로 검증해야 합니다

14. 저는 내년도 산정을 다음 공식으로 최종 확정하겠습니다

15. 이 모델의 핵심은 "운영업무 Catalog"입니다

예

16. 그리고 이 표는 향후 실제 운영관리 체계와 연결됩니다

제가 권하는 최종 산정 구조

① 경영진용

② 관리용

③ 실제 운영용

그리고 여기서 한 단계 더 나가면 좋습니다.

1. 접근 구조

2. (A) 상향식 업무량 산정

3. (B) Toil 예산으로 FTE 환산

4. (C) On-call 구조적 하한

5. 전문분야 보정 (버스팩터)

6. 검증·재조정 절차 (정량 모델을 살아있게 유지하는 법)

7. 다음 액션 제안

26S06g2

26S06h2

0개의 댓글