26Z05a2
노드 수가 버전 A 1,200대, 버전 B 1,800대로 확대될 경우, [제안사의 기존 산정 로직]과 [Cloud-Native / 플랫폼 엔지니어링 표준 로직]에 따른 결과가 극명하게 갈립니다.
제안사의 논리를 적용하면 인력과 비용이 폭증하지만, Modern Cloud-Native(GitOps, eBPF, S3) 표준을 적용하면 인력 증가를 최소화할 수 있습니다. 두 관점에서의 변경 사항을 비교·분석해 드립니다.
1. 두 관점별 인력 및 비용 변경 비교
| 구분 | 버전 A (LAKE 단독) | 버전 B (LAKE + DtOps) |
|---|---|---|
| 노드 수 | 1,200대 (기존 690대 대비 +74% 증가) | 1,800대 (기존 975대 대비 +85% 증가) |
① 제안사 기존 로직 적용 시 (노드/클러스터 비례 산정 방식)
제안사는 1차/2차 제안서에서 "노드 및 클러스터 증가율 ≒ 인원 증가율"의 선형 비례 관계(노드 약 27대당 SM 1명)를 적용했습니다.
- 버전 A (1,200노드):
- 인원: 약 40~42명 (SM 35명, SI 5~7명)
- 연 비용: 약 37억 ~ 39억 원
- 버전 B (1,800노드):
- 인원: 약 60~65명 (SM 50~53명, SI 10~12명)
- 연 비용: 약 55억 ~ 60억 원
⚠️ 위험 요소: 신규 데이터센터 2개 추가(DC당 400~500노드)로 노드가 1,800대까지 늘어날 때 제안사 로직을 그대로 인정해주면 운영 인력만 60명이 넘고 연간 60억 원에 육박하는 예산 폭탄을 맞게 됩니다.
② 플랫폼 엔지니어링 표준 기준 적정 산정안 (권장)
Kubernetes, Cilium(eBPF), MinIO AIStor, ArgoCD(GitOps), AWX 기반 환경에서는 노드 수가 600대에서 1,800대로 3배 늘어나더라도 Control Plane과 자동화 파이프라인이 동일하다면 일상 운영 공수가 3배 늘어나지 않습니다.
규모 확장에 맞춰 '플랫폼 지원(L1 문의)' 및 '노드/OS 물리 패치 작업'에 한해 일부 인원만 보충하는 것이 타당합니다.
| 영역 | 기존(975노드) 적정안 | 버전 A (1,200노드) | 버전 B (1,800노드) | 조정 및 운영 로직 |
|---|---|---|---|---|
| 총괄 / 아키텍트 | 2명 | 2명 | 2명 | 대규모 통합 컨트롤 및 백업 체계 유지 |
| Core K8s & Cilium | 4명 | 5명 | 6명 | 노드 증설 및 멀티 DC eBPF 라우팅/CNI 이슈 대응 (+1~2명) |
| Data & AIStor (S3) | 2명 | 3명 | 4명 | 1,800노드 규모 S3 IOPS/클러스터 증설 및 디스크 장애 대응 (+1~2명) |
| Security & Auth | 2명 | 2명 | 2명 | Keycloak, Vault, AD/LDAP은 노드 수 증가와 직접 연관 없음 (동결) |
| Observability (모니터링) | 2명 | 2명 | 3명 | Promethus/Thanos, Grafana 메트릭 수집량 증가 대응 (+1명) |
| CI/CD & 플랫폼 지원 | 4명 | 5명 | 7명 | 노드 OS 패치, HW 장애 교체 지원, 개발자 L1/L2 문의 대응 (+1~3명) |
| 상시 운영(SM) 합계 | 16명 | 19명 | 24명 | 1,800노드여도 SM 상주 24명으로 충분 커버 |
| SI (구축/업그레이드) | M/M 별도 | Short-term M/M | Short-term M/M | 신규 DC 구축 및 Major 업그레이드 시 프로젝트성 M/M 발주 |
| 총 연간 예산 (추정) | 약 16~18억 | 약 20~22억 원 | 약 25~27억 원 | 제안사 대비 연 30억 원 이상 절감 |
2. 노드 급증(1,800대) 시 제안사 상대 핵심 대응 논리
외주/제안사가 "노드가 1,800대로 늘었으니 60명이 필요하다"고 주장할 때 다음 4가지 논리로 차단하셔야 합니다.
- "Scale-out Architecture의 본질 제시"
- Bare-metal 노드가 1,800대로 늘어나더라도, GitOps(ArgoCD) 배포 체계와 AWX 자동화 Playbook이 갖춰져 있다면 K8s 마스터 노드 및 worker 노드 관리 공수는 비례해서 증가하지 않음을 지적하십시오.
- "AIStor(MinIO) & Cilium의 관리 효율성"
- AIStor(S3)는 노드와 드라이브가 늘어나도 중앙 관리 UI/API 및 Kubernetes Operator를 통해 선형적인 관리가 가능합니다. 스토리지 전담 인원을 노드 증가 비율대로 늘릴 이유가 없습니다.
- "멀티 DC 환경에서의 인력 구조 재편"
- 클러스터별로 Pod-A, Pod-B, Pod-C식으로 인력을 파편화(Silo)하지 않고, 전체 DC를 통틀어 'K8s/CNI 전담팀', 'Data/스토리지 전담팀'으로 중앙집중화(Shared Service Center)하면 24명 수준으로 1,800노드 전체 커버가 가능함을 강조하십시오.
- "Hardware/OS 작업과 Platform 작업의 분리"
- 1,800노드 규모에서 실질적으로 늘어나는 공수는 '디스크/노드 HW 고장 교체'와 'OS 패치'입니다. 고급/중급 K8s 엔지니어를 늘릴 것이 아니라, 단순 HW/OS 패치 지원(초/중급 2~3명)만 추가하는 것이 올바른 구조입니다.
engineer