GPU 플랫폼, 직접 구축할까 도입할까: 숨은 비용까지 따진 TCO 판단법
GPU를 수십 장 들여놓고 나면 반드시 맞닥뜨리는 결정이 있습니다. "이 GPU들을 여러 팀이 나눠 쓰고, 스케줄링하고, 사용량을 집계하는 플랫폼을 쿠버네티스로 직접 만들 것인가, 아니면 이미 만들어진 것을 도입할 것인가."
엔지니어가 많은 조직일수록 "우리가 직접 만들면 되지"라는 결론으로 기웁니다. 쿠버네티스는 오픈소스이고, NVIDIA device plugin도 공개돼 있고, 스케줄러도 Volcano 같은 오픈소스가 있으니까요. 라이선스 비용 0원. 표면적으로는 직접 구축이 명백히 저렴해 보입니다.
이 글은 그 “0원”에 가려진 비용을 드러내고, 직접 구축과 도입을 3년 총소유비용(TCO) 관점에서 어떻게 비교해야 하는지, 그리고 어느 쪽을 언제 선택해야 하는지를 정리합니다.
직접 구축이 싸 보이는 이유, 그리고 그 착시
직접 구축의 비용을 물으면 대부분 "엔지니어 인건비 조금"이라고 답합니다. 하지만 GPU 플랫폼은 "한 번 세팅하면 끝"이 아니라 계속 운영·유지해야 하는 시스템입니다. 숨은 비용은 세 갈래에서 발생합니다.
첫째, 초기 구축 비용입니다. 쿠버네티스 위에 GPU 스케줄링, 멀티테넌시(네임스페이스·쿼터·격리), 모니터링 파이프라인(DCGM·Prometheus·Grafana), 사용량 집계, 접근 제어(RBAC)를 조립하는 일은 YAML 몇 개로 끝나지 않습니다. GPU를 분할해 여러 팀이 안전하게 나눠 쓰게 만드는 것, 그 분할된 사용량을 팀별로 정확히 집계하는 것은 오픈소스를 가져다 붙인다고 저절로 되지 않습니다.
둘째, 지속 운영 비용입니다. 쿠버네티스 생태계는 대략 3개월 주기로 릴리스되고, 그 업데이트에는 보안·안정성에 영향을 주는 변경이 포함됩니다. 직접 구축한 플랫폼은 이 변화를 따라가는 유지보수를 직접 해야 합니다. NVIDIA 드라이버·CUDA·device plugin 버전 호환성, 스케줄러 버그, 모니터링 파이프라인 장애 — 이 모든 것이 운영팀의 상시 업무가 됩니다.
셋째, 기회비용입니다. 가장 큰 비용이면서 가장 자주 간과됩니다. 플랫폼을 만들고 유지하는 데 투입된 엔지니어는 그 시간 동안 제품을 만들지 못합니다. GPU 인프라 플랫폼이 회사의 핵심 경쟁력이 아니라면, 그 엔지니어링 역량은 제품에 쓰는 편이 낫습니다.
3년 TCO로 비교하는 법
Build vs Buy는 1년이 아니라 최소 3년으로 봐야 공정합니다. 직접 구축은 초기 비용이 크고 이후 운영비가 누적되는 구조, 도입은 초기 비용이 작고 구독료가 일정하게 나가는 구조이기 때문입니다. 아래 항목을 모두 넣어야 비교가 성립합니다.
TCO 항목 | 직접 구축 (Build) | 도입 (Buy) |
|---|---|---|
초기 구축 | 설계·개발 인건비 (수개월×다수 엔지니어) | 도입·온보딩 비용 |
라이선스/구독 | 0원 (오픈소스) | 연간 구독료 |
운영·유지보수 | 상시 전담 인력 (업데이트·장애 대응) | 벤더 제공 (구독에 포함) |
기능 개발 | 필요 기능 직접 구현 | 벤더 로드맵으로 제공 |
기회비용 | 제품 개발에 못 쓴 엔지니어 시간 | 낮음 |
리스크 | 핵심 인력 이탈 시 유지보수 공백 | 벤더 종속성 |
핵심은 직접 구축의 "라이선스 0원"이 운영·유지보수·기회비용으로 옮겨갈 뿐 사라지지 않는다는 점입니다. 많은 조직이 1년 차에는 직접 구축이 싸다고 느끼지만, 2~3년 차에 유지보수 부담과 기능 요구가 쌓이면서 역전되는 경우가 많습니다.
직접 구축이 맞는 경우 vs 도입이 맞는 경우
어느 쪽도 항상 정답은 아니며, 판단 기준은 다음과 같습니다.
직접 구축이 합리적인 경우:
GPU 인프라 운영 자체가 회사의 핵심 경쟁력인 경우 (예: GPU 클라우드를 파는 회사)
플랫폼 엔지니어링 전담 조직을 상시 유지할 수 있는 규모
매우 특수한 요구사항이 있어 기성 제품으로는 불가능한 경우
도입이 합리적인 경우:
GPU는 '쓰는' 것이지 '운영하는 것'을 팔지 않는 경우 (대부분의 기업·연구조직)
엔지니어를 제품/연구에 집중시키고 싶은 경우
사용량 기반 비용 배분(Chargeback), 멀티테넌시, 모니터링을 빠르게 갖춰야 하는 경우
AIPub으로 '도입'을 택했을 때 얻는 것
TEN의 AIPub은 직접 구축했다면 수개월이 걸렸을 기능을 플랫폼으로 제공합니다. GPU를 100블록(1% 단위) 또는 MIG로 분할해 여러 팀이 간섭 없이 나눠 쓰게 하고, 우선순위 큐·동적 할당 스케줄링으로 유휴 자원을 자동 회수·재분배합니다. 운영 가시성 측면에서는 5계층·50개 이상의 자체 지표로 모니터링하고, FinOps Suite(월별 사용량 집계, 계정·프로젝트별 Excel 리포트)로 사용량 기반 비용 배분을 바로 가능하게 합니다. 접근 제어(RBAC)와 쿼터 관리도 포함됩니다.
즉, 직접 구축에서 가장 품이 많이 드는 부분인 ‘안전한 GPU 분할, 정확한 팀별 사용량 집계, 계층형 모니터링’ 을 조립이 아니라 제품으로 가져가는 선택입니다. 그리고 쿠버네티스 생태계 업데이트를 따라가는 유지보수를, 벤더가 대신 책임집니다.
직접 구축의 “0원”을 다시 계산해봐야 합니다. 라이선스가 아니라, 그 플랫폼을 3년간 만들고 지키는 데 들어갈 엔지니어 시간을 넣어서요. 많은 경우, 그 시간이 가장 비쌉니다.
자주 묻는 질문(FAQ)
Q. 오픈소스만으로 GPU 플랫폼을 만들 수 있지 않나요?
기술적으로는 가능합니다. 쿠버네티스, NVIDIA device plugin, Volcano, DCGM, Prometheus를 조합하면 기본 기능은 만들 수 있습니다. 문제는 '만들 수 있는가'가 아니라 '만들고 3년간 유지할 수 있는가'입니다. 특히 GPU 분할 사용량의 팀별 정확한 집계와 안전한 멀티테넌시는 조립만으로는 난도가 높습니다.
Q. 도입하면 벤더에 종속되는 것 아닌가요?
일정 부분 맞습니다. 다만 직접 구축도 '그 플랫폼을 만든 핵심 엔지니어'에게 종속됩니다. 그 인력이 이탈하면 유지보수 공백이 생깁니다. 종속성은 어느 쪽에도 존재하며, 쿠버네티스 표준 위에서 동작하는 제품을 택하면 종속 리스크를 줄일 수 있습니다.
Q. TCO를 왜 3년으로 보나요?
직접 구축은 초기 비용이 크고 운영비가 누적되는 구조라, 1년만 보면 왜곡됩니다. GPU 하드웨어 교체 주기(대략 18~24개월)와 쿠버네티스 유지보수 부담이 쌓이는 2~3년 차를 포함해야 공정한 비교가 됩니다.
→ AIPub으로 직접 구축 없이 GPU 플랫폼 갖추기: