AI Factory를 Multi-Customer Cloud Service로 전환하려면

AI Factory를 구축했다고 해서 여러 고객이 바로 사용할 수 있는 Cloud Service가 되는 것은 아닙니다.

AI Factory는 GPU, Server, Network, Storage와 AI Software를 결합해 Training, Fine-tuning, Inference 같은 AI Workload를 실행하는 Infrastructure / Platform Environment입니다.

하지만 외부 고객이 스스로 Resource를 선택하고 주문하고 사용하는 Service가 되려면 그 위에 Productization과 Cloud Operations Layer가 추가되어야 합니다.

핵심 차이는 이것입니다.

AI Factory를 구축하는 것과 AI Factory를 Cloud Service로 운영하는 것은 서로 다른 문제입니다.

내부 AI Factory와 Multi-Customer Service는 무엇이 다를까요?

내부 AI Factory는 보통 Organization 내부의 Team과 Workload를 중심으로 운영할 수 있습니다.

예를 들어:

• Research Team
• Data Science Team
• Product Team
• Internal AI Platform Team

이 GPU Resource를 사용합니다.

이 경우에도 Scheduling, Provisioning, Access, Observability와 Capacity Management는 중요합니다.

하지만 여러 외부 고객이 같은 Infrastructure를 Service로 사용하기 시작하면 추가 문제가 생깁니다.

Operator는:

• 고객별 Account / Organization을 관리하고
• Service를 상품처럼 보여주고
• 주문을 받고
• Resource를 자동으로 준비하고
• Tenant를 분리하고
• Usage를 측정하고
• 비용을 계산하거나 정산하고
• SLA와 Lifecycle을 관리해야 합니다.

Infrastructure Operation이 Service Operation으로 바뀌는 것입니다.

무엇이 달라져야 할까요?

1. Service Catalog

Customer가 무엇을 살 수 있는지 정의해야 합니다.

예:

• GPU Type
• GPU Quantity
• Bare Metal / VM
• Storage Option
• Network Option
• Service Duration
• Pricing / Commercial Policy

Infrastructure Spec이 Customer-facing Product로 바뀌는 단계입니다.

2. Customer / Organization Management

여러 고객을 운영하려면 User뿐 아니라 Organization / Tenant 단위 관리가 필요합니다.

고객별로:

• User
• Role
• Credential
• Project
• Policy
• Quota

를 분리할 수 있어야 합니다.

3. Multi-Tenancy

한 고객의 Workload, Network, Storage와 Credential이 다른 고객과 섞여서는 안 됩니다.

Multi-Tenancy는 GPU를 물리적으로 공유하는 것만을 의미하지 않습니다.

Dedicated GPU / Node를 제공하더라도 Customer별 Identity, Network, Storage, Policy와 Usage를 분리해야 합니다.

4. Ordering / Fulfillment

Customer가 Console이나 API에서 Resource를 주문하면 Service Platform이 이를 운영 Workflow로 연결해야 합니다.

Order가 단순 Ticket으로 끝나지 않고 실제 Resource Request로 이어져야 합니다.

5. Provisioning

주문된 Resource를 실제 사용 가능한 상태로 만들어야 합니다.

Compute, GPU, Network, Storage, Image / Runtime과 Access가 준비되어야 합니다.

6. Scheduling / Quota / Policy

여러 Customer가 동시에 Resource를 요청하면:

• GPU Type
• Available Capacity
• Quota
• Priority
• Reservation
• Topology

를 기준으로 Resource를 배치해야 할 수 있습니다.

Self-Service가 왜 중요할까요?

NIST의 Cloud Computing 정의에서 On-demand Self-Service는 핵심 특성 중 하나입니다.

Customer가 매번 Operator에게 전화하거나 Ticket을 보내야 Resource를 받을 수 있다면 Cloud Experience와는 거리가 있습니다.

Self-Service Environment에서는 Customer가:

• Service를 선택하고
• 주문하고
• 상태를 확인하고
• Access하고
• Usage를 확인하고
• 필요하면 Resource를 종료

할 수 있어야 합니다.

API도 같은 이유로 중요합니다.

Customer가 Application이나 Automation System에서 Resource를 Programmatic하게 요청할 수 있어야 실제 On-demand Service로 확장하기 쉽습니다.

Metering은 왜 필요할까요?

Internal Environment에서는 “GPU를 몇 개 보유하고 있는가?”가 중요할 수 있습니다.

Customer-facing Service에서는:

누가 어떤 Resource를 얼마나 사용했는가?

가 중요해집니다.

Metering은:

• GPU Usage
• Allocation Duration
• Storage Usage
• Network Usage
• Service Consumption

같은 Usage Data를 수집하는 기반이 될 수 있습니다.

이 Data는:

• Customer Usage Report
• Billing
• Settlement
• Capacity Planning
• SLA Analysis

과 연결될 수 있습니다.

Measured Service가 Cloud Operating Model에서 중요한 이유입니다.

Billing은 Metering과 같은 기능일까요?

아닙니다.

Metering

Usage를 측정합니다.

Rating / Pricing

Usage에 가격 Policy를 적용합니다.

Billing / Settlement

청구 또는 정산 Workflow로 연결합니다.

즉 단순히 GPU 사용 시간을 측정한다고 Billing이 완성되는 것은 아닙니다.

Commercial Service에서는 Service Plan, Contract, Discount, Tax, Settlement 같은 Business Logic도 필요할 수 있습니다.

SLA가 필요한 이유는 무엇일까요?

내부 Resource는 Team 간 운영 Policy로 관리할 수 있습니다.

외부 Customer에게 Service를 판매하면 기대 수준이 달라집니다.

예:

• Resource Availability
• Provisioning Time
• Support Response
• Failure Recovery
• Maintenance Notice

같은 Service Commitment가 필요할 수 있습니다.

SLA는 Monitoring 숫자 하나가 아니라 Customer에게 약속한 Service Level을 운영하는 체계입니다.

Cloud Service는 하나의 Lifecycle로 운영됩니다

Customer-facing Service는 Resource를 만드는 것으로 끝나지 않습니다.

전체 흐름은 다음처럼 볼 수 있습니다.

Catalog → Order → Provision → Isolate → Schedule → Consume → Meter → Bill → Recover → Recycle

Customer가 Service를 선택하고 주문하면 Resource가 준비됩니다.

Tenant Boundary와 Policy가 적용되고 Workload가 실행됩니다.

Usage를 측정하고 필요하면 Billing / Settlement에 연결합니다.

사용이 끝나면 Resource를 회수하고 정리한 뒤 다음 Customer가 사용할 수 있도록 Pool로 반환합니다.

Capacity Management도 달라집니다

Internal AI Factory에서는 내부 Demand를 중심으로 Capacity를 계획할 수 있습니다.

Commercial Service에서는 Customer Demand가 더 변동적일 수 있습니다.

Operator는:

• Available GPU
• Reserved Capacity
• Tenant Quota
• Maintenance
• Failure
• New Customer Demand

를 동시에 봐야 합니다.

“GPU가 몇 개 있는가?”만으로는 충분하지 않습니다.

지금 Customer에게 실제로 Provision 가능한 Capacity가 얼마나 남아 있는가?

가 중요해집니다.

모든 AI Factory를 Multi-Customer Cloud로 만들어야 할까요?

아닙니다.

다음 목적이라면 Internal AI Factory로 운영하는 것이 자연스러울 수 있습니다.

• 내부 R&D
• Internal Enterprise AI
• Sensitive / Restricted Workload
• 전용 Production Inference
• Research / Training

Multi-Customer Cloud Service는:

• 외부 고객에게 Capacity를 판매하거나
• GPU Infrastructure를 Service Business로 Productize하거나
• 여러 Organization에게 Self-Service Resource를 제공하려는 경우

에 필요한 Operating Model입니다.

즉 기술적으로 가능하다고 해서 반드시 Business Model까지 전환해야 하는 것은 아닙니다.

Multi-Customer가 곧 Public Cloud라는 뜻일까요?

항상 그렇지는 않습니다.

“Multi-Customer Cloud Service”는 본 Article에서 여러 독립 Customer에게 Resource를 반복적으로 제공하는 Service Operating Model을 설명하기 위한 표현입니다.

NIST의 Public Cloud Deployment Model은 일반 대중에게 Open Use를 제공하는 Cloud를 의미합니다.

따라서 제한된 Partner, Consortium, 특정 Customer Group을 대상으로 하는 Service는 Business / Deployment Model에 따라 다른 형태일 수 있습니다.

중요한 것은 Public이라는 Label보다 실제:

• Tenant Model
• Access Model
• Resource Pool
• Service Policy
• Commercial Model

을 명확히 정의하는 것입니다.

Thaki Cloud는 이 전환을 어떻게 볼까요?

Thaki Cloud의 핵심 Market Narrative 중 하나는:

AI Factory의 다음 단계는 Cloud Service

입니다.

Canonical Architecture는:

Customer Infrastructure → Thaki NeoCloud OS → Customer NeoCloud Service

입니다.

Thaki NeoCloud OS는 Customer가 보유한 GPU / AI Infrastructure와 실제 Cloud Business 사이의 Software Layer입니다.

Capability Model에는:

• Service Catalog
• Ordering / Fulfillment
• User / Organization Management
• Multi-Tenancy
• Provisioning
• GPU Scheduling
• Quota / Policy
• Metering
• Billing / Settlement
• SLA
• Observability
• Capacity Management
• Lifecycle Automation
• API
• Self-Service Console

이 포함됩니다.

목표는 Thaki Cloud가 고객 대신 Hyperscaler가 되는 것이 아니라, Infrastructure Owner가 자신의 Brand와 Policy로 Cloud Service를 운영할 수 있게 하는 것입니다.

정리하면

AI Factory를 여러 Customer가 사용하는 Cloud Service로 전환하려면 GPU Infrastructure만으로는 부족합니다.

필요한 변화는:

Infrastructure Operation → Productized Service Operation

입니다.

Customer는 Service를 선택하고 주문하고 사용하고 Usage를 확인할 수 있어야 합니다.

Operator는 그 뒤에서 Tenant, Provisioning, Scheduling, Metering, Billing, SLA와 Lifecycle을 반복적으로 운영해야 합니다.

그래서:

AI Factory를 구축하는 것과 Cloud Business를 운영하는 것은 서로 다른 문제입니다.

FAQ

AI Factory와 GPU Cloud는 같은가요?

같은 개념은 아닙니다. AI Factory는 AI Workload를 생산·실행하기 위한 Infrastructure / Platform Environment를 의미할 수 있고, GPU Cloud는 Resource를 Cloud Service 방식으로 제공하는 Operating Model을 포함합니다.

Multi-Customer Service에는 반드시 Billing이 필요한가요?

외부 유료 Service라면 Billing / Settlement가 중요해질 수 있습니다. 하지만 내부 Showback, Consortium, 특정 Contract Model에서는 구현 방식이 다를 수 있습니다.

Multi-Tenancy는 GPU를 공유한다는 의미인가요?

아닙니다. Dedicated GPU / Node를 제공하더라도 Customer별 Identity, Network, Storage, Policy와 Usage를 분리하면 Multi-Tenant Platform이 될 수 있습니다.

Self-Service가 왜 중요한가요?

Customer가 Provider의 수작업 개입 없이 Resource를 선택하고 Provision할 수 있어야 On-demand Cloud Experience를 만들 수 있기 때문입니다.

모든 AI Factory를 Cloud Service로 전환해야 하나요?

아닙니다. 내부 AI Workload 전용 AI Factory도 충분히 유효한 Operating Model입니다. External Customer Service가 Business Goal일 때 추가 Cloud Operations Layer가 필요합니다.