이 정보가 굉장히 중요합니다.

H/W와 OS 운영은 별도 인프라 조직이 담당하고, DevOps/SRE 조직은 요청, 일정 조율, reboot 확인, kernel 작업 협조 정도만 수행

그러면 제가 이전에 계산했던 모델은 OS/HW 운영을 과대평가한 것입니다.

예를 들어 이전에는

• Disk 교체
• BIOS
• RAID
• Firmware
• NIC
• Switch
• Rack
• Cable

까지 포함했는데,

이제는 이것들이 거의 빠집니다.

즉 OS/HW 분야만 3~4 FTE 정도 감소합니다.

반면 귀사 조직은

• Kubernetes Platform
• AIStor
• Cilium
• DevOps
• Security
• Observability
• Data Platform

비중이 훨씬 커집니다.

저는 이것이 오히려 Google SRE / CNCF가 말하는 Platform Engineering 조직에 더 가까운 형태라고 생각합니다.

---

제가 추천하는 Hybrid Model

저는 아래 순서가 가장 논리적이라고 봅니다.

1. Top-down Benchmark
          ↓
2. Complexity Adjustment
          ↓
========================
예상 범위 도출 (Expected Range)
========================
          ↓
3. Bottom-up Workload
          ↓
4. Service Catalog Coverage
          ↓
5. FTE Validation
          ↓
최종 권고 인원

즉,

Top-down은

"세계적으로 이 정도 규모면 어느 정도인가"

Bottom-up은

"우리 업무량은 실제 얼마인가"

를 계산하는 것입니다.

---

STEP1 Top-down

① CNCF Benchmark

귀사와 가장 유사한 사례

회사	특징	유사도
Michelin	★★★★★	제조 + On-prem
Mercedes	★★★★★	Enterprise Platform
Pinterest	★★★★☆	Data Platform
Uber	★★★☆☆	Cloud 중심
OpenAI	★★★☆☆	AI Platform

이들의 평균

1800 Nodes

↓

Platform Team

약 12~15명

그러나

여기에는

• Air-gap 없음
• AIStor 없음
• 운영지원 적음

---

② Complexity

귀사

요소	영향
Air-gap	높음
AIStor	높음
Cilium	높음
Bare Metal	중간
Data Lakehouse	높음
Multi Cluster	높음

복잡도

약

1.5~1.7배

↓

15명

↓

22~26명

Top-down 결과

22~26명

---

STEP2 Bottom-up

여기서부터가 핵심입니다.

이번에는

사람이 아니라

서비스를 계산합니다.

---

Kubernetes

운영 대상

10 Cluster
1800 Node

주요 업무

• Upgrade
• Cluster 생성
• Control Plane
• Admission
• CRD
• Scheduler
• CSI
• Runtime
• 장애

평균

4.5FTE

---

Cilium

업무

• eBPF
• Network Policy
• BGP
• LB
• Hubble
• 장애

1.5FTE

---

AIStor

업무

• Capacity
• Healing
• ILM
• Scanner
• Replication
• Pool
• S3
• 성능
• Vendor

3.5FTE

---

DevOps

• Jenkins
• Nexus
• ArgoCD
• Helm
• GitOps

2.5FTE

---

Security

• Vault
• Keycloak
• RBAC
• Secret
• PKI

2FTE

---

Monitoring

• Prometheus
• Thanos
• Grafana
• Alertmanager
• OpenSearch

2.5FTE

---

Data Platform

여기가 많이 빠집니다.

질문입니다.

Spark

Trino

Iceberg

Airflow

이걸

누가 운영하는가?

만약

DevOps 팀이면

2FTE

전담 DataOps가 있다면

0FTE

---

Architecture

• 설계
• Vendor
• Review
• 장애

2FTE

---

Bottom-up

Platform          4.5
Network           1.5
Storage           3.5
DevOps            2.5
Security          2
Monitoring        2.5
Architecture      2
-----------------------
18.5FTE

여기에

운영지원

회의

교육

문서

개선

On-call

여유율

20%

18.5

×

1.2

=

22.2

Bottom-up

22명

---

STEP3 Service Coverage Validation

이번에는

정말

"빠진 업무가 없는가"

를 검증합니다.

Domain	Primary	Backup
K8s	2	2
AIStor	2	1
Cilium	1	1
Security	1	1
DevOps	1	1
Monitoring	1	1
Architecture	2	-

합계

20명

휴가

교육

병가

15%

↓

23명

---

STEP4 Cross Validation

방법	결과
Benchmark	22~26
Complexity	23~25
Bottom-up	22
Service Coverage	23

평균

23명

---

그런데 여기서 제가 가장 추천하는 개선점이 있습니다.

지금까지의 모든 모델은 FTE(사람 수)를 직접 계산합니다.

하지만 경영진과 제안사가 가장 반박하기 어려운 것은 "운영시간(Work Hours)"입니다.

예를 들어 AIStor를 보겠습니다.

현재 귀사 환경에서는 AIStor 운영자가 하는 일은 단순히 "Storage 운영"이 아니라 다음과 같이 구체적으로 정의할 수 있습니다.

• Capacity Planning
• Pool Expansion
• ILM 정책 관리
• Replication 관리
• 성능 분석(TTFB, IOPS, Erasure Set)
• 장애 분석(Healing, Scanner, Quorum)
• 버전 검증 및 업그레이드
• Vendor Ticket 대응
• 운영 표준화(SOP, Runbook)

각 항목별 연간 예상 건수 × 평균 소요시간을 계산하면 AIStor만의 연간 총 운영시간이 나옵니다.

이 작업을 Kubernetes, Cilium, Observability, Security, DevOps까지 모두 수행하면 사람 수가 아니라 '총 운영시간'이 먼저 계산되고, 마지막에만 총 운영시간 ÷ 1인 실가용시간으로 FTE를 산출하게 됩니다.

이 방식은 Top-down 결과(22~26명)와 Bottom-up 결과(예: 22~24명)가 자연스럽게 비교되며, "우리 업무량으로 계산해도 이 정도가 나온다"는 가장 강력한 근거가 됩니다.

---

제 제안

지금 수준에서 한 단계 더 발전시켜 엑셀에서 바로 계산 가능한 운영인력 산정 모델을 만드는 것을 추천드립니다.

입력값만 바꾸면 자동으로 계산되도록 구성합니다.

• Sheet 1: 환경 입력(노드 수, 클러스터 수, AIStor Pool 수, 디스크 수, 서비스 수)
• Sheet 2: Top-down Benchmark(CNCF 사례 기반)
• Sheet 3: Bottom-up Workload(Incident, Change, Upgrade, Capacity, Vendor 대응 등)
• Sheet 4: Complexity 보정(Air-gap, AIStor, Cilium, 보안 등)
• Sheet 5: 최종 FTE 및 민감도 분석(노드 1800→2500 증가 시 자동 재계산)

이렇게 만들면 경영진 보고뿐 아니라 향후 증설(예: 2,500노드, 15클러스터)이나 제안사 재협상에도 동일한 모델을 계속 사용할 수 있습니다.