26Z05b2

Young-Kyoo Kim·2026년 8월 4일

저도 같은 고민을 했습니다.

사실 Function-based sizing은 Gartner나 ITIL에서도 사용하는 접근이지만, 가장 큰 약점은 말씀하신 것처럼 "왜 Storage가 4명이고 5명이 아닌가?"를 설명하기 어렵다는 것입니다.

그래서 글로벌 대기업이나 컨설팅사(PwC, Deloitte, Accenture)가 실제로는 Function Based만 쓰지 않고 Workload Based + Complexity Based + Benchmark Based를 같이 사용합니다.

저라면 이번 보고서는 3단계 검증 구조(Triangulation) 로 가져가겠습니다.

① Benchmark(외부 사례)

→ CNCF, Google, Mercedes, Michelin

② Complexity Model(환경 난이도)

→ Air-gap, AIStor, Cilium, Security

③ Workload Model(실제 업무량)

→ Ticket, Change, Upgrade, Incident, Capacity

이 세 가지가 같은 숫자로 수렴하면 "26명"의 신뢰도가 훨씬 높아집니다.

제가 추천하는 방법은 "Function"이 아니라 "Workload Unit"입니다.

Function은

Storage
Network
Security

처럼 사람 기준입니다.

반대로

Workload Unit은

운영 대상(Object) 기준입니다.

이게 훨씬 객관적입니다.

예를 들면

관리 대상	수량
Kubernetes Cluster	10
Bare-metal Node	1800
Disk	약 36,000
Object Storage Pool	XX
Namespace	수천
Tenant	XX
Prometheus Target	수천
Alert Rule	수백~수천
Git Repository	XX
Application	XX

이렇게 됩니다.

즉

사람이 아니라 관리 대상의 개수를 먼저 정의합니다.

그리고 "관리 대상"마다 연간 평균 운영공수를 계산합니다.

예를 들어

Node

한 Node는 1년에

BIOS
Firmware
OS Patch
Kernel
HW Failure
Disk Failure
Capacity
Health Check

등이 발생합니다.

예를 들면

작업	연간
OS Patch	4
Firmware	2
Disk 교체	0.3
장애	0.2
Capacity Review	1

합계

약

7~8건

1800 Nodes

약 13,000건

이번에는 Cluster

10 Cluster

Cluster Upgrade

4회

Cert Rotation

4회

Backup Test

12회

DR Test

2회

Policy 변경

20회

등

이렇게 계산합니다.

Storage도 마찬가지입니다.

예를 들면

AIStor

128 Node Pool

EC Expansion

Healing

Scanner

Replication

ILM

Capacity

Disk 교체

Version Upgrade

Bug 대응

Vendor 협업

이런 것들을 연간 이벤트로 환산합니다.

여기서 중요한 것은 MTTR입니다.

운영은

사람 수가 아니라

시간입니다.

예를 들어

Disk Failure

연 350건

1건 처리

2시간

700시간

입니다.

이런 식으로

모든 작업을 시간으로 바꾸면

객관성이 생깁니다.

결국 FTE가 나옵니다.

예를 들어

1 FTE

실제 운영 가능한 시간

약

1,650시간/년

(휴가, 교육, 회의 제외)

그러면

Storage 업무

7,200시간

↓

7,200 / 1,650

4.36 FTE

≈

4명

이건 누구도 반박하기 어렵습니다.

이 방식의 장점

예를 들어

Storage

왜 4명인가?

↓

왜냐하면

연간 운영업무가

7,000시간

이기 때문입니다.

왜 Security가 3명인가?

↓

RBAC

Audit

Vault

Key Rotation

계정 승인

PKI

총

5,100시간

↓

3.1FTE

이건

"느낌"

이 아니라

시간 기반입니다.

귀사에서는 더 강력한 무기가 하나 있습니다.

이전 대화를 보면 귀사 환경은

약 1,800 Bare-metal Node
약 10 Kubernetes Cluster
20 Disk × Node ≒ 36,000 Disk
AIStor
Cilium
Vault
Keycloak
ArgoCD
Jenkins
OpenSearch
Prometheus
Spark
Trino
Airflow

를 운영합니다.

즉

이미

운영 대상이 명확합니다.

여기에

Vendor Guide

SOP

Weekly Report

Incident

Change History

까지 존재합니다.

여기서 진짜 좋은 방법

귀사는 Confluence에

SOP

장애보고

작업계획서

주간보고

등이 계속 쌓이고 있다고 하셨습니다.

이게 사실 최고의 근거입니다.

예를 들어 최근 1년

Incident

215건

Change

480건

Upgrade

120건

Capacity

95건

HW 교체

320건

Disk

540건

Patch

180건

...

이렇게 실제 데이터를 뽑으면

연간 운영시간이 나옵니다.

그러면

"26명"은 추정이 아니라 실제 운영 실적에서 계산된 값이 됩니다.

이건 Gartner보다도 훨씬 설득력이 있습니다.

제가 가장 추천하는 방법

보고서를 한 단계 더 끌어올리려면 국내 SI나 감사에서도 방어 가능한 "Evidence-based Operations Sizing Model(EOSM)" 형태로 만드는 것입니다.

즉 인력을 다음 식으로 계산합니다.

FTE = (연간 운영 이벤트 수 × 표준 작업시간 × 복잡도 계수) ÷ 실가용 작업시간

여기서 각 항목은 모두 근거를 가집니다.

연간 운영 이벤트 수: Change, Incident, Patch, Upgrade, HW 교체, Capacity 증설 등 실제 운영 데이터 또는 제조사 권장 주기.
표준 작업시간: SOP 수행시간, 작업계획서, ITIL Incident/Change 기록, 유지보수 실적.
복잡도 계수: Air-gap, AIStor, Cilium, 보안 승인 등은 Gartner·Google SRE·CNCF 사례를 참고해 "왜 일반 환경보다 시간이 더 드는지"를 설명하는 용도.
실가용 작업시간: 교육·회의·휴가를 제외한 연간 실투입 가능 시간(예: 1,600~1,700시간/FTE).

이 모델의 장점은 26명이 먼저 정해져 있는 것이 아니라 계산 결과로 26명이 나온다는 점입니다.