Cloud Service Catalog란? GPU 인프라를 서비스 상품으로 만드는 첫 단계
GPU 서버 100대가 있다고 가정해 보겠습니다.
운영팀은 각 서버의 GPU 종류, 메모리, 네트워크, 랙 위치와 상태를 알고 있습니다.
그렇다면 고객도 이 정보를 보고 바로 GPU 클라우드 서비스를 주문할 수 있을까요?
대부분의 경우 그렇지 않습니다.
운영팀이 관리하는 인프라 재고와 고객이 선택하는 서비스 상품은 서로 다른 개념이기 때문입니다.
클라우드 서비스 카탈로그의 역할은 이 둘 사이를 연결하는 것입니다.
가장 단순하게 정의하면:
Cloud Service Catalog는 인프라 자원을 고객이 실제로 선택하고 주문할 수 있는 서비스 상품으로 정의한 체계입니다.
즉 “우리가 어떤 서버를 갖고 있는가?”를 보여주는 목록이 아니라:
“고객은 무엇을 어떤 조건으로 주문할 수 있는가?”
를 정의합니다.
서비스 카탈로그는 재고 목록이 아닙니다
GPU 사업자가 내부적으로 관리하는 재고에는 다음과 같은 정보가 있을 수 있습니다.
- 서버 ID
- GPU 종류
- GPU 수량
- CPU / Memory
- 네트워크 포트
- 랙 위치
- BMC 상태
- 사용 중 / 가용 / 장애 상태
이 정보는 운영에 매우 중요합니다.
하지만 고객은 보통 “서버 ID 7284”를 주문하고 싶어 하지 않습니다.
고객이 원하는 것은 예를 들어:
- 전용 8-GPU 서버
- GPU VM
- 특정 기간 예약 가능한 GPU 용량
- 특정 스토리지 / 네트워크 옵션이 포함된 환경
같은 서비스 상품입니다.
서비스 카탈로그는 실제 인프라의 특성을 고객이 이해하고 주문할 수 있는 상품 구조로 바꿉니다.
GPU 상품 하나를 정의하려면 무엇이 필요할까요?
“GPU 8개”만으로 상품 정의가 끝나는 것은 아닙니다.
환경과 사업 모델에 따라 카탈로그 항목에는 다음과 같은 정보가 연결될 수 있습니다.
상품명 / SKU
고객이 구분할 수 있는 상품 단위가 필요합니다.
GPU 구성
GPU 종류, 수량, 서버 단위 제공 여부 같은 기술 조건이 포함될 수 있습니다.
컴퓨팅 형태
전용 베어메탈인지, VM인지, 워크로드 단위인지에 따라 서비스 방식이 달라질 수 있습니다.
네트워크 / 스토리지 옵션
AI 학습이나 추론에서는 GPU만큼 데이터 이동과 스토리지 구성이 중요할 수 있습니다.
기간 / 예약 방식
온디맨드인지, 특정 기간 예약형인지, 장기 계약인지에 따라 운영 정책이 달라질 수 있습니다.
이용 정책
어떤 고객이 사용할 수 있는지, 조직별 할당량은 얼마인지, 어떤 옵션을 선택할 수 있는지 정의할 수 있습니다.
가격 / 계약 매핑
모든 가격이 공개되어야 하는 것은 아닙니다.
공개 가격, 계약 가격, 장기 약정, 별도 견적 등 사업 방식에 따라 가격 적용 구조가 다를 수 있습니다.
프로비저닝 방식
가장 중요한 부분 중 하나입니다.
카탈로그에 있는 상품이 실제 인프라에서 어떻게 만들어지는지 연결되어야 합니다.
예를 들어 “전용 8-GPU 서버”를 주문하면:
- 어떤 서버 조건을 찾는가?
- 어떤 이미지가 배포되는가?
- 어떤 네트워크가 연결되는가?
- 어떤 스토리지가 제공되는가?
- 어떤 접근 권한이 생성되는가?
가 운영 흐름으로 연결되어야 합니다.
Inventory, Price List, Service Catalog는 무엇이 다를까요?
세 개념은 함께 사용될 수 있지만 역할이 다릅니다.
Inventory — 실제로 무엇이 있는가?
운영자가 관리하는 물리 / 가상 자원 상태입니다.
예:
- GPU 서버 20대
- 현재 가용 8대
- 유지보수 2대
- 사용 중 10대
Inventory는 공급 측의 현실입니다.
Price List — 얼마인가?
상품이나 계약에 적용되는 가격 정보를 보여줍니다.
하지만 가격이 있다고 해서 주문 가능한 상품 구조가 완성된 것은 아닙니다.
Service Catalog — 무엇을 어떤 조건으로 주문할 수 있는가?
고객이 선택할 상품과 옵션, 정책, 제공 방식, 프로비저닝 연결을 정의합니다.
즉:
Inventory는 공급을 설명하고, Price List는 가격을 설명하며, Service Catalog는 고객이 주문할 수 있는 서비스를 설명합니다.
카탈로그와 실제 가용 용량은 연결되어야 합니다
서비스 카탈로그를 잘 디자인해도 실제 인프라와 연결되지 않으면 문제가 생길 수 있습니다.
웹사이트에는 “전용 GPU 서버”가 주문 가능하다고 표시되는데 실제로는 해당 조건의 서버가 모두 사용 중이라고 가정해 보겠습니다.
고객 경험 측면에서는:
- 주문 후 실패
- 장시간 대기
- 영업팀의 수동 조정
- 다른 상품으로 재협상
이 필요할 수 있습니다.
따라서 카탈로그는 고정된 마케팅 페이지가 아니라 실제 용량 정책과 연결되는 것이 중요합니다.
환경에 따라:
- 실시간 가용 여부 표시
- 예약 가능 여부
- 대기 상태
- 관리자 승인
- 대체 상품 제안
같은 방식이 사용될 수 있습니다.
카탈로그가 프로비저닝과 연결되지 않으면 어떻게 될까요?
서비스 카탈로그에 “GPU 서버 A”라는 상품이 있다고 가정해 보겠습니다.
고객은 상품을 주문했지만 운영팀이 주문서를 보고 어떤 서버를 어떻게 준비해야 하는지 매번 다시 판단해야 한다면 상품 정의와 운영 절차 사이에 간격이 존재합니다.
반복 가능한 클라우드 서비스에서는 카탈로그 항목이 실제 운영 템플릿과 연결되는 것이 중요합니다.
예를 들어:
상품 A → 서버 조건 → 이미지 → 네트워크 → 스토리지 → 접근 정책 → 완료 조건
처럼 상품 정의가 실제 프로비저닝 절차와 연결될 수 있습니다.
이렇게 해야 같은 상품을 고객이 여러 번 주문해도 비슷한 결과를 제공할 수 있습니다.
서비스 카탈로그와 과금도 연결되어야 합니다
고객이 주문한 상품과 실제 과금 기준이 서로 다르면 문제가 생깁니다.
예를 들어:
- 카탈로그는 “7일 예약형 전용 GPU 서버”
- 운영 기록은 “실제 GPU 사용률”
- 과금 시스템은 “VM 실행 시간”
을 각각 기준으로 사용한다면 같은 서비스에 세 가지 다른 정의가 존재하게 됩니다.
따라서 상품, 서비스 상태, 사용 기록과 과금 규칙을 일관되게 연결하는 것이 중요합니다.
서비스 카탈로그가 과금 시스템 자체는 아니지만, 무엇을 판매했는가를 정의하는 기준이 될 수 있습니다.
OpenStack Keystone의 Service Catalog와 같은 것인가요?
이름은 같지만 역할이 다릅니다.
OpenStack Keystone의 Service Catalog는 API Client가 OpenStack 환경에서 사용 가능한 서비스를 찾고 해당 Endpoint에 접근할 수 있도록 하는 기술적 Service Discovery 기능입니다.
예를 들어 Compute, Identity, Network 같은 API 서비스의 Endpoint를 알려주는 역할을 합니다.
이 글에서 설명하는 상용 Cloud Service Catalog는 고객이 구매 / 요청할 수 있는 GPU 또는 클라우드 상품을 정의하는 사업·운영 개념입니다.
따라서 둘을 같은 것으로 보면 안 됩니다.
Keystone Service Catalog = API Service Discovery
Commercial Service Catalog = 고객이 주문할 수 있는 서비스 상품 정의
환경에 따라 둘은 서로 연결될 수 있지만 목적은 다릅니다.
좋은 서비스 카탈로그는 “기능 목록”이 아닙니다
카탈로그를 만들 때 자주 생기는 문제는 모든 인프라 옵션을 고객에게 그대로 보여주는 것입니다.
예:
- GPU 종류 8개
- Network Type 12개
- Storage Option 15개
- Image 30개
선택지가 많다고 항상 좋은 카탈로그는 아닙니다.
실제 고객은 자신이 무엇을 선택해야 하는지 이해해야 합니다.
따라서 카탈로그는 인프라의 모든 가능성을 노출하는 것이 아니라:
고객이 반복적으로 구매할 가치가 있는 서비스 조합을 상품화하는 작업
이어야 합니다.
데이터센터 / GPU 사업자에게 왜 중요할까요?
데이터센터가 GPU 서버를 보유하고 있어도 고객 요청을 매번 영업과 운영팀이 개별 설계한다면 사업 확장에는 한계가 생길 수 있습니다.
서비스 카탈로그는:
- 어떤 상품을 판매할 것인지
- 어떤 용량을 사용할 것인지
- 어떤 정책을 적용할 것인지
- 어떤 운영 절차로 제공할 것인지
를 표준화하는 출발점입니다.
즉:
Infrastructure → Product
전환의 핵심 단계입니다.
Thaki Cloud는 이 문제를 어떻게 볼까요?
Thaki Cloud의 Thaki NeoCloud OS 구조는:
Customer Infrastructure → Thaki NeoCloud OS → Customer NeoCloud Service
입니다.
Thaki NeoCloud OS는 GPU와 AI 인프라를 보유한 사업자가 자신의 인프라를 고객이 소비할 수 있는 클라우드 서비스로 운영할 수 있도록 지원하는 플랫폼입니다.
지원되는 배포 환경에서는 서비스 카탈로그가 프로비저닝, 테넌시, 자원 할당 / 스케줄링, 사용량 측정, 과금 연동과 자원 라이프사이클에 연결될 수 있습니다.
실제 상품 모델, 지원 하드웨어와 연동 범위는 프로젝트별 확인이 필요합니다.
정리하면
클라우드 서비스 카탈로그는 단순한 서버 목록도 가격표도 아닙니다.
핵심은:
인프라 특성 → 상품 정의 → 정책 / 옵션 → 서비스 카탈로그 → 주문 → 프로비저닝
입니다.
고객이 어떤 서비스를 주문할 수 있는지 명확히 정의하고, 그 주문이 실제 인프라와 운영 절차로 연결되어야 합니다.
GPU 인프라를 클라우드 사업으로 전환할 때 서비스 카탈로그는 자산을 상품으로 바꾸는 첫 번째 운영 계층이라고 볼 수 있습니다.
FAQ
GPU 재고 화면이 있으면 서비스 카탈로그인가요?
아닙니다. Inventory는 실제 자원 상태를 보여주고, Service Catalog는 고객이 주문할 수 있는 상품을 정의합니다.
서비스 카탈로그는 가격표인가요?
아닙니다. 가격은 카탈로그의 한 요소가 될 수 있지만 계약 조건, 옵션, 정책, 프로비저닝 방식도 함께 연결될 수 있습니다.
모든 GPU 모델을 카탈로그에 공개해야 하나요?
그럴 필요는 없습니다. 고객에게 반복적으로 제공할 가치가 있는 상품 단위로 정의하는 것이 중요합니다.
OpenStack Keystone Service Catalog와 같은 개념인가요?
아닙니다. Keystone의 Service Catalog는 API Service Discovery 용도이며, 이 글의 상용 Service Catalog는 고객 주문 상품을 정의합니다.
카탈로그만 만들면 GPU 클라우드가 완성되나요?
아닙니다. 주문, IAM, 정책, 용량, 프로비저닝, 사용량 측정, 과금과 자원 라이프사이클이 함께 연결되어야 합니다.
GPU 인프라를 서비스 상품으로 만들고 계신가요?
보유 GPU / AI 인프라를 고객이 선택하고 주문할 수 있는 상품으로 정의하고, 실제 프로비저닝과 운영 흐름까지 연결하고 있다면 Thaki Cloud와 서비스 카탈로그 구조를 함께 검토해 보세요.
문의하기참고 자료
관련 아티클
- GPU Cloud란 무엇인가? 개념, 작동 방식, GPUaaS와의 차이GPU Cloud는 데이터센터의 GPU를 네트워크를 통해 필요할 때 사용하는 클라우드 컴퓨팅 방식입니다. GPUaaS와의 차이, 작동 방식, Bare Metal·Virtual GPU 유형, 활용 사례와 운영 구조를 설명합니다.
- AI Factory란 무엇인가? AI 데이터센터와 무엇이 다른가?AI Factory는 AI 워크로드를 반복적으로 개발·학습·배포·운영하기 위한 통합 인프라와 운영 환경입니다. AI 데이터센터와의 차이, 핵심 구성 요소, AI Lifecycle, GPU Cloud와의 관계를 설명합니다.
- GPUaaS란 무엇인가? GPU as a Service의 구조와 핵심 기능GPUaaS는 GPU 연산 자원을 직접 구매하지 않고 서비스 형태로 사용하는 방식입니다. GPU Cloud와의 차이, 작동 방식, Bare Metal·Virtual GPU 제공 형태, 운영 기능과 선택 기준을 설명합니다.
- Private AI Cloud란 무엇인가?Private AI Cloud는 단일 조직 전용의 Private Cloud 운영 모델에 GPU·AI 플랫폼·데이터·보안·거버넌스를 결합한 AI 환경입니다. Public AI Cloud, On-Prem AI, Sovereign AI, Air-Gapped AI와의 차이와 구축 고려사항을 설명합니다.
- GPU 서버가 있다고 GPU Cloud가 되는 것은 아닙니다GPU 서버를 보유하거나 호스팅한다고 자동으로 GPU Cloud가 되는 것은 아닙니다. GPU Hosting과 GPU Cloud의 차이, Self-Service·Provisioning·Scheduling·Metering 등 Cloud 운영에 필요한 핵심 기능을 설명합니다.
- NeoCloud란 무엇인가? AI 시대의 GPU 중심 클라우드NeoCloud는 GPU와 AI Workload에 특화된 Cloud Infrastructure Provider를 설명할 때 사용되는 산업 용어입니다. 기존 Hyperscaler, GPU Cloud, GPUaaS와의 관계와 Thaki Cloud의 NeoCloud Enablement 관점을 설명합니다.
- AI Factory의 다음 단계는 Cloud Service입니다AI Factory를 구축하는 것과 고객이 실제로 사용할 수 있는 Cloud Service를 운영하는 것은 다릅니다. Provisioning, Multi-Tenancy, GPU Scheduling, Metering, Billing, SLA 등 서비스화에 필요한 운영 계층을 설명합니다.
- AI 인프라를 Cloud Business로 전환한다는 것은 무엇인가?GPU와 AI 인프라를 보유하는 것과 실제 Cloud Business를 운영하는 것은 다릅니다. Infrastructure → Product → On-demand Cloud Service 전환 과정과 Service Catalog, Provisioning, Metering, Billing, SLA 등 사업화에 필요한 운영 구조를 설명합니다.
- Bare Metal GPU란? 가상화 GPU와의 차이와 활용 방식Bare Metal GPU의 개념과 GPU VM, vGPU, GPU Passthrough의 차이를 알아보세요. 전용성, 성능 일관성, 유연성, 자원 효율, Provisioning 관점에서 어떤 방식이 적합한지 설명합니다.
- Private AI Cloud와 Public AI Cloud의 차이Private AI Cloud와 Public AI Cloud를 전용성, 통제 범위, 확장성, Managed Service, 운영 책임, 비용 구조 관점에서 비교합니다. 어떤 AI Workload에 각각 적합한지 알아보세요.
- GPU Scheduling이란? AI Cloud에서 GPU 자원을 배분하는 방법GPU Scheduling의 개념과 Queue, Priority, Quota, GPU Type, Topology, Multi-GPU Job, Resource Fragmentation을 알아보세요. GPU Cloud에서 Scheduling과 Provisioning이 어떻게 다른지도 설명합니다.
- AI Factory 구축 이후에 필요한 운영 플랫폼은 무엇인가?AI Factory 구축 이후 실제 운영 단계에서 필요한 Provisioning, GPU Scheduling, 사용자·Policy 관리, Observability, Capacity Management, Metering과 Lifecycle Automation을 알아보세요.
- On-Prem AI란? 기업이 자체 환경에서 AI를 운영하는 이유On-Prem AI의 개념과 Private AI Cloud와의 차이, 기업이 데이터·모델·네트워크·지연시간·운영 통제를 이유로 자체 환경에서 AI를 운영하는 경우와 Trade-off를 알아보세요.
- GPU Multi-Tenancy란? 여러 고객이 GPU 인프라를 안전하게 사용하는 구조GPU Multi-Tenancy의 개념과 Tenant Isolation, Dedicated GPU, vGPU, MIG, Kubernetes Namespace, Quota, Scheduling, Network·Storage 분리와 Usage 관리 구조를 알아보세요.
- GPU Provisioning이란? 주문에서 사용 가능 상태까지의 자동화GPU Provisioning의 개념과 GPU 요청 이후 Compute, Network, Storage, Image, Runtime, Access를 준비해 실제 사용 가능한 환경으로 만드는 자동화 과정을 알아보세요.
- AI Factory를 Multi-Customer Cloud Service로 전환하려면AI Factory를 여러 고객이 사용하는 Cloud Service로 전환할 때 필요한 Service Catalog, Multi-Tenancy, Provisioning, Scheduling, Metering, Billing, SLA와 Lifecycle을 알아보세요.
- GPU 클라우드 사업화 준비도 체크리스트: 무엇을 점검해야 할까?GPU 서버를 보유했다고 바로 GPU 클라우드 서비스를 판매할 수 있는 것은 아닙니다. 서비스 상품화, 멀티테넌시, 프로비저닝, 사용량 측정, 과금, SLA와 자원 라이프사이클을 12개 실무 항목으로 점검합니다.
- GPU 클라우드 수익성 분석: 가동률보다 중요한 것은 무엇일까?GPU 사용률과 과금 가능 시간은 같은 지표가 아닙니다. 가상의 32-GPU 계산 예시를 통해 판매 가능 용량, 과금 가능 GPU 시간, 실현 단가, 고정비·변동비와 손익분기점을 설명합니다.
- GPU 클라우드 직접 구축 vs. 통합 운영 플랫폼: 무엇이 더 합리적일까?OpenStack, Kubernetes, Prometheus 같은 오픈소스로 GPU 클라우드를 구축할 수 있습니다. 직접 통합과 운영 플랫폼 도입을 연동, 실패 처리, 과금, 확장성과 3–5년 총소유비용 관점에서 비교합니다.
- Self-Service Cloud란? 고객이 직접 주문하고 사용하는 클라우드 서비스셀프서비스 클라우드는 단순한 포털이 아닙니다. 서비스 카탈로그, IAM, 정책·할당량, 가용 용량, 프로비저닝, 사용량 측정과 자원 회수가 어떻게 연결되어야 하는지 설명합니다.
- On-demand GPU Service란? 필요한 GPU를 필요할 때 제공받는 방식온디맨드 GPU는 Shared GPU나 Spot GPU와 같은 말이 아닙니다. 요청, 가용 용량, 프로비저닝, 사용량 측정과 반환이 어떻게 연결되는지, 전용 베어메탈도 온디맨드 방식으로 제공할 수 있는지 설명합니다.
- 데이터센터가 GPU Hosting에서 GPU Cloud로 전환하려면GPU Hosting에서 GPU Cloud로의 전환은 하드웨어 교체보다 운영 모델 변화에 가깝습니다. 서비스 카탈로그, 셀프서비스, 프로비저닝, 고객 분리, 사용량 측정·과금과 자원 회수를 어떻게 추가해야 하는지 설명합니다.