26Z05b1
결론부터 말씀드리면,
"26명이라는 숫자가 반드시 맞다"는 결론까지는 근거가 부족합니다.
하지만 "60~65명은 과다 산정일 가능성이 매우 높다"는 주장은 충분히 논리적으로 방어할 수 있습니다.
제가 하나씩 검증해 보겠습니다.
총평
| 항목 | 평가 |
|---|---|
| CNCF 사례 인용 | ★★★★☆ 매우 좋음 |
| Google SRE 인용 | ★★★☆☆ 일부 과장 |
| Gartner 인용 | ★★☆☆☆ 실제 문헌 확인 필요 |
| COCOMO II 적용 | ★★☆☆☆ 운영인력 산정에는 부적절 |
| Air-gap 보정 | ★★★★★ 매우 타당 |
| AIStor/Cilium 보정 | ★★★★★ 매우 타당 |
| 최종 26명 결론 | ★★★☆☆ 가능성은 있지만 증명이 부족 |
즉,
앞부분은 상당히 좋지만 마지막 숫자를 만드는 과정이 다소 비약적입니다.
1. CNCF 사례는 상당히 좋은 근거이다.
이 부분은 거의 문제 없습니다.
예를 들어
Michelin
Mercedes-Benz
LINE
Zalando
모두 실제 Case Study입니다.
이들이 공통적으로 말하는 것은
Platform Engineering을 제대로 구축하면
운영 인력은 노드 수에 선형적으로 증가하지 않는다.
입니다.
이건 귀사의 주장과 정확히 일치합니다.
특히 Michelin 사례는
- 제조업
- On-prem
- Multi Cluster
- GitOps
- 중앙 운영
이라서 귀사 환경과 매우 유사합니다.
이건 적극적으로 사용하는 것이 좋습니다.
2. Google SRE 인용은 약간 수정해야 한다.
여기가 조금 위험합니다.
예를 들어
현재 문서에는
"Sublinear"
"O(logN)"
"O(√N)"
이라고 되어 있는데,
Google SRE Book은
O(logN)
이나
O(√N)
을 어디에서도 공식적으로 말하지 않습니다.
Google이 말하는 것은
Toil은 자동화해야 한다.
입니다.
즉
현재 문서처럼
Google이 O(logN)을 주장했다
라고 쓰면
반박당할 수 있습니다.
대신 이렇게 쓰는 것이 좋습니다.
Google SRE는 운영 규모 증가에 따라 운영 공수가 선형적으로 증가해서는 안 되며, 반복 작업(Toil)을 자동화하여 운영 효율을 지속적으로 개선해야 한다고 권고한다.
이렇게 쓰면 정확합니다.
3. Gartner 부분은 가장 조심해야 한다.
여기가 제일 위험합니다.
문서에는
Air-gap
+15~20%
Security
+10~15%
Emerging Tech
+15~25%
라고 되어 있는데
제가 아는 Gartner Research에서는
이 숫자를 그대로 표 형태로 제시하지는 않습니다.
Gartner는
Complexity Driver
Business Criticality
Automation Maturity
같은 개념은 이야기하지만
"Air-gap +20%"
처럼 공식 수치를 공개하지 않습니다.
즉
경영진 보고서에는
아래처럼 바꾸는 것이 좋습니다.
Gartner I&O Sizing Framework에서는
운영 난이도(보안, 폐쇄망, 신기술)에 따라
운영 인력 산정 시 Complexity Driver를 적용하도록 권고한다.
이 정도가 안전합니다.
4. COCOMO II는 조금 무리한 적용이다.
COCOMO II는
원래
Software Development
예측 모델입니다.
운영 조직 산정 모델은 아닙니다.
따라서
RELY
PVOL
SECU
를
운영인력 산정에 그대로 가져오면
반박당하기 쉽습니다.
대신
COCOMO는
참고 수준으로만 사용하는 것이 좋습니다.
예를 들어
신기술 및 높은 신뢰성이 필요한 환경에서는 일반 SW Engineering에서도 추가 공수가 인정된다.
정도로 사용하는 것이 좋습니다.
5. Air-Gapped 보정은 매우 타당하다.
이 부분은 오히려 더 강조해도 됩니다.
귀사 환경은
인터넷 차단
패키지 반입
이미지 반입
보안 승인
Artifact 검증
외부 Vendor 접속 제한
모두 존재합니다.
이건 실제 운영 생산성을 크게 낮춥니다.
실제 글로벌 SI에서도
Air-gap은 가장 큰 Cost Driver 중 하나입니다.
6. AIStor/Cilium 보정도 매우 타당하다.
이건 귀사만의 강력한 근거입니다.
일반 Kubernetes 운영과 달리
귀사는
AIStor
Cilium
OpenEBS
Vault
Keycloak
ArgoCD
Jenkins
Nexus
OpenSearch
Prometheus
Thanos
Alertmanager
Spark
Iceberg
Trino
Airflow
StarRocks
까지 운영합니다.
즉
단순 Kubernetes 운영이 아닙니다.
특히
AIStor는
Storage
Network
Disk
S3 API
Erasure Coding
Healing
Scanner
Replication
ILM
을 모두 이해해야 합니다.
일반 K8s보다 훨씬 어렵습니다.
이 부분은 오히려
더 강조해도 됩니다.
7. 가장 아쉬운 부분은 "26명"이 어떻게 나왔는가이다.
현재 표를 보면
예를 들어
Storage
2명
↓
4명
왜?
Air-gap
Lakehouse
S3
이라고 되어 있습니다.
하지만
왜 4명인지
근거가 없습니다.
Observability
2명
↓
3명
왜?
근거가 없습니다.
Platform
3명
↓
8명
왜?
역시 없습니다.
즉
보정은 이해되지만
수학적 산출이 없습니다.
경영진은
이 부분을 가장 질문합니다.
제가 추천하는 방식
26명을 먼저 정하지 말고
업무를 먼저 산정하는 것이 훨씬 설득력이 있습니다.
예를 들어
Platform
- Kubernetes
- Cilium
- Upgrade
- Cluster Lifecycle
- DR
- Capacity
→ 5명
Storage
- AIStor
- Disk
- EC
- Healing
- ILM
→ 4명
Observability
- Prometheus
- Grafana
- OpenSearch
- Alertmanager
→ 3명
Security
- Vault
- Keycloak
- RBAC
- Audit
→ 3명
DevOps
- Jenkins
- Nexus
- ArgoCD
→ 3명
HW/OS
- Bare Metal
- Firmware
- RAID
- BIOS
→ 5명
Architect
→ 2명
합계
약
25~27명
정도가 자연스럽게 나옵니다.
이 방식은
"업무 기반(Function-based Sizing)"
이라서
Gartner에서도 자주 사용하는 접근입니다.
귀사 환경(약 1,800노드) 기준으로 본 제 의견
귀사의 환경은 이전 대화에서 공유해 주신 내용을 종합하면 다음과 같은 특징이 있습니다.
- 약 1,700~1,800대 Bare Metal
- 약 10개 Kubernetes 운영 클러스터(이전 계획 기준)
- Air-Gapped 환경
- AIStor 기반 Object Storage
- Cilium eBPF
- OpenEBS
- Vault / Keycloak
- ArgoCD / Jenkins / Nexus
- OpenSearch + Prometheus/Thanos + Grafana
- Spark, Trino, Iceberg, Airflow 등 Data Lakehouse 플랫폼
- 장기적으로 여러 사이트를 중앙에서 운영
이 환경은 일반적인 Kubernetes 운영보다 복잡도가 높은 것은 분명합니다. 반면 GitOps, Operator, 표준화, 자동화를 적극 활용한다면 운영 인력이 노드 수에 비례해서 증가해야 한다고 보기는 어렵습니다.
따라서 제안사의 60~65명 상주는 상당한 근거 제시가 필요하며, 반대로 20명 중후반~30명 초반 수준은 충분히 검토 가능한 범위입니다. 다만 26명이라는 특정 숫자는 "보정계수의 합"보다는 기능별 책임(Function-based sizing) + 실제 운영 업무량 + SLA + 교대 여부를 근거로 제시하는 편이 훨씬 방어력이 높습니다.
최종 평가
제가 이 보고서를 경영진 제출용으로 다듬는다면 다음과 같이 수정하겠습니다.
-
유지
- CNCF Case Study 기반 비교
- Air-Gapped 보정
- Data Lakehouse 특수성
- AIStor/Cilium 운영 난이도
- Google SRE의 "Toil 감소" 철학
-
수정
- Google SRE의 O(logN), O(√N) 표현 삭제
- Gartner의 구체적인 % 수치는 "예시"가 아닌 "복잡도 증가 요인" 수준으로 표현
- COCOMO II는 참고 자료로만 축소
-
추가
- 기능(Function) 기반 운영업무 분해(WBS)
- RACI(책임 매트릭스)
- 운영 KPI(MTTR, 변경 건수, 업그레이드 주기, 장애 대응, 용량 관리)
- 26명 산정 과정을 업무량 기준으로 재구성
이렇게 보완하면 단순한 "인원 주장"이 아니라 글로벌 사례 + SRE 원칙 + 기능 기반 인력 산정이 결합된 보고서가 되어, 제안사와의 협상이나 경영진 보고에서도 훨씬 설득력이 높아질 것입니다.
