26Z05a1

Young-Kyoo Kim·2026년 8월 4일

제안해주신 「2027년 LAKE DevOps & AIStor(S3) 운영 인력 제안서 (2차)」에 대해, 현재 귀사의 실제 운영 환경(온프레미스/고성능 스택 중심)과 향후 확장 계획(멀티 DC)을 바탕으로 타당성을 검토한 결과입니다.

결론부터 말씀드리면, 이 제안서는 현재 기준(수동 운영 비중, 업무시간 내 정/부 이중화 강제)으로는 논리가 정교하지만, '플랫폼 엔지니어링의 본질(자동화 및 Self-Service)'과 '귀사의 실제 기술 스택/확장 규모'를 고려할 때 인력이 과다하게 산정(Over-staffing)되어 있으며, 비용/조직 효율성 측면에서 치명적인 약점을 가지고 있습니다.

아래 상세 분석 및 대응 전략을 참고하셔서 경영진 보고 및 외주/수주사 협상에 활용하시기 바랍니다.

1. 핵심 요약 및 종합 판정

종합 평점: 3.0 / 5.0 (비현실적 외주 인력 부풀리기 위험 상존)
핵심 문제점:

인력 규모의 과도함: automation/GitOps/IaC가 적용된 Modern Cloud-Native 환경임에도 '노드 수/클러스터 수에 비례한 인력 증원(1:1 선형 비례)'이라는 전통적 SM 산정 방식을 적용함.
기술 스택에 대한 이해 부족: Cilium, MinIO AIStor, Keycloak, Vault, ArgoCD 등 고도화된 Cloud-Native ecosystem은 인프라가 늘어난다고 운영 공수가 선형 증가하지 않음.
멀티 DC 확장 시 예산 폭발: 신규 DC 2개(노드 800~1,000대 추가) 확장 시, 현재 산정 로직대로라면 인력이 60~70명, 연 60~70억 원으로 폭증하는 치명적 구조임.

권장 인원 수준:
버전 A (LAKE 690노드): 제안 25명 $\rightarrow$ 적정 12~14명 (약 45~50% 감축 가능)
버전 B (LAKE+DtOps 975노드): 제안 36명 $\rightarrow$ 적정 16~18명 (약 50% 감축 가능)

2. 세부 영역별 타당성 검토 (Fact & Logic Check)

① 규모 및 확장성 로직의 오류 (가장 큰 허점)

제안서 주장: 노드 41% 증가 / 클러스터 40% 증가 $\rightarrow$ 인원 44% 증원 (버전 A $\rightarrow$ B)
검토 의견 (Critique):
K8s 및 eBPF(Cilium), S3(AIStor) 기반의 Data Lakehouse 플랫폼은 '인프라 선형 확장(Scale-Out)'이 장점입니다. 클러스터 개수나 노드가 늘어난다고 해서 Helm/Kustomize, GitOps(ArgoCD), AWX/Ansible 제어면 운영 공수가 비례하여 늘어나지 않습니다.
신규 데이터센터 2개(400~500노드/DC)가 추가되면 이 로직대로라면 인력과 비용이 2배로 뜁니다. 플랫폼 엔지니어링 조직의 목표인 "Scale without linear head-count growth(인력 증가 없는 규모 확장)"에 완전히 정면 배치됩니다.

② 타사 사례 벤치마크 및 인당 커버리지 해석의 오류

제안서 주장: 타사(Mercedes 1인당 200노드, LINE 1인당 25클러스터) 대비 커버리지가 낮은 이유(1인당 27노드, 0.2클러스터)는 "책임 범위가 넓고 수동 운영 비중이 높기 때문"임.
검토 의견 (Critique):
수동 운영 비중이 높다는 것은 자랑이 아니라 결함입니다. SI 트랙으로 4~6명(고급)을 별도 배정하여 "표준화, 자동화, PoC"를 수행하도록 예산을 반영했음에도, SM 인력을 타사 대비 10배 가까이 빽빽하게 잡은 것은 SI 인력의 자동화 성과를 SM 인력 감축에 반영하지 않겠다는 모순입니다.
Mercedes-Benz(30명으로 900클러스터/6,000노드)나 LINE, Zalando의 사례와 비교했을 때, 690~975노드에 25~36명을 투입하는 것은 글로벌 기준은 물론 국내 금융/대기업 엔터프라이즈 K8s 전담팀 기준(보통 10~15명 내외)으로도 과도합니다.

③ 조직 구조 및 역할 중복 (R&R Overlap)

Core Pod (K8s·Cilium):
I클러스터용 Pod-A(3명), Pod-B(3명), Y클러스터 Pod-Y(2명) 등으로 클러스터별로 정/부를 쪼개놓았습니다. K8s/Cilium 스택은 클러스터 단위로 담당자를 분리할 이유가 없으며, 통합 K8s/Network 팀(4~5명)이 Control Plane과 CNI 전체를 중앙에서 L2/L3로 커버하는 것이 타당합니다.

보안 및 스토리지, CI/CD:
Keycloak/Vault/AD 통합 운영에 고급 2~3명, OpenEBS/Isilon/AIStor 운영에 중/고급 3~4명 배정됨.
Vault/Keycloak은 초기 Architecture 및 Policy 수립 후 일상 운영(Token, ACL, PKI) 공수가 적으며, AIStor(MinIO) 및 Isilon 역시 S3 API / NFS 기반이므로 대시보드 및 M&M(Monitoring & Management) 위주입니다. 별도 전담 인원이 정/부로 붙을 규모가 아닙니다.

플랫폼 지원 (초급 3~4명):
개발 요청 대응 및 OS 패치용 인력입니다. OS 최적화/패치는 자동화(Image Builder, KubeVirt/OS rolling update script)로 처리해야 하며, 단순 개발자 L1 문의는 티켓팅 시스템 및 Portal/Self-Service 도입으로 최소화해야 합니다.

④ SM vs SI 트랙 분리의 타당성

검토 의견 (Positive & Negative):
양호한 점: SM(상시 운영)과 SI(신규 구축 및 버전 업그레이드)를 분리하여 운영 부하로 인한 고도화 지연을 방지한 논리는 훌륭합니다.
개선할 점: K8s 버전 업그레이드나 Kyverno/Gateway API 도입은 매일 일어나는 일이 아닙니다. SI 고급 4~6명이 연중 상주(1.0 FTE)할 필요가 없으며, 업그레이드 및 구축 시즌(예: 분기별 1~2개월)에만 Man-Month(M/M) 단위로 투입하는 프로젝트성 계약이 훨씬 경제적입니다.

3. 구조개선 및 인력 재산정 안 (Alternative Proposal)

귀사의 현재 450노드+130노드(2개)+190노드 환경 및 향후 신규 DC 2개(800~1,000노드 추가) 확장성을 흡수할 수 있는 '플랫폼 엔지니어링 기반 적정 인력안'을 제시합니다.

💡 적정 인력 산정표 (버전 B 기준: 975노드/7클러스터)

영역	제안서 (36명)	개선안 (16명)	조정 사유 및 운영 방안
총괄 및 아키텍트	2명 (특1, 고1)	2명 (특1, 고1)	총괄 및 백업 체계 유지 (필수)
K8S & Cilium Network	11명 (중11)	4명 (고2, 중2)	Pod 분리 폐지 $\rightarrow$ 통합 Core Infra팀. CNI/eBPF, K8s Core 일괄 커버
Data & Storage (AIStor/NFS)	4명 (고2, 중2)	2명 (고1, 중2)	AIStor(S3) + OpenEBS/Isilon 통합 스토리지 담당
Security & Auth (Vault/Keycloak/AD)	3명 (고3)	2명 (고1, 중2)	Vault, Keycloak, AD 통합 보안/인증 담당 (정/부)
CI/CD, Registry & Platform Support	10명 (중3, 초4 + SI3)	4명 (중2, 초2)	ArgoCD, Nexus, L1/L2 개발 지원 및 OS 패치 (GitOps 및 포털로 업무 효율화)
Observability (모니터링)	3명 (중3)	2명 (중2)	Prometheus/Grafana/APM 파이프라인 관리
합계 (SM 기준)	30명	16명	상시 운영 FTE 16명으로 축소
SI (구축/업그레이드)	6명 (고6 상주)	T&M / MM 계약	연간 K8s 대규모 업그레이드/신규 구축 시에만 Short-term SI(약 12~16 M/M) 별도 발주

비용 절감 효과:

제안서 버전 B: 연 33.2억 원 (36명 상주)

개선안 적용 시: 연 16~18억 원 수준 (약 50% 절감: 연 15억 원 이상 예산 절감)

4. 외주사/제안사 대응 및 협상 전략 (Actionable Advice)

1차 리뷰에서 인원을 확대(5~6명 $\rightarrow$ 25~36명)하도록 피드백이 들어간 역효과로 제안사가 인력을 과도하게 팽창시킨 경향이 있습니다. 아래 논리로 재검토를 요청하십시오.

1️⃣ "노드 비례 인력 산정 로직" 거부

가이드: "우리는 Multi-DC 및 2,000노드 이상으로 확장되는 Architecture를 가지고 있다. 노드 수와 클러스터 수에 따라 SM 인력이 선형 증가하는 제안 구조는 수용할 수 없다. GitOps(ArgoCD), IaC, AWX 기반 자동화 수준을 반영하여 '노드가 증가해도 인력이 동결/미증가하는 플랫폼 중심 구조'로 재산정하라."

2️⃣ SI 인력의 상주(FTE) 계약을 M/M(Man-Month) 계약으로 전환

가이드: "SI 트랙 고급 인력 4~6명이 연중 상주하는 것은 비용 효율성이 떨어진다. SI 영역은 상시 SM 업무에서 제외하고, K8s Major 업그레이드 및 신규 DC 클러스터 구축 이벤트 발생 시 M/M 단위로 정산하는 방식으로 변경하라."

3️⃣ Core Pod 분약 해제 및 Domain 기반 조직화

가이드: "클러스터 단위(Pod-A, Pod-B, Pod-Y, Pod-DtOps)로 중급 인력을 쪼개는 것은 인력 병목 및 Context Switching 비용만 늘린다. K8s/Cilium을 하나의 통합 파이프라인으로 묶어 Domain Expert(고급/중급) 중심의 4~5명 통합 팀으로 재편하라."

4️⃣ 업무시간 외 대응(On-Call) 및 SLA 조건 명확화

가이드: 현재 제안서는 "주 40시간 / 평일 09~18시 대응 / On-Call 없음"을 전제로 36명을 요구하고 있습니다. 업무시간 한정 운영에 36명(33.2억)은 정당화되기 어렵습니다. 업무시간 외 Emergency Call 대응(간이 온콜 체계)을 포함하거나, 인원을 10대 후반으로 대폭 줄일 것을 요구해야 합니다.