작게 시작하는 AI 플랫폼 기준 아키텍처

핵심 메시지

AI 플랫폼은 처음부터 거대할 필요가 없습니다. 초기 PoC나 파일럿 단계에서 중요한 것은 "모든 기능을 갖춘 플랫폼"이 아니라 "반복해서 검증할 수 있는 운영 환경"입니다.

작게 시작한다는 것은 임시방편으로 만든다는 뜻이 아닙니다. 네임스페이스, 노드풀, 이미지 저장소, 모델 저장소, 시크릿 관리, 서비스 노출 방식처럼 나중에 운영 규모가 커져도 유지될 기본 뼈대를 먼저 정한다는 뜻입니다.

초기 기준 아키텍처의 목표는 세 가지입니다.

1. 개발팀이 모델을 빠르게 실험하고 배포할 수 있어야 합니다.

2. GPU 같은 고비용 자원을 통제 가능한 방식으로 써야 합니다.

3. 운영 전환 시 다시 만들지 않아도 되는 구조여야 합니다.

AI 생성 이미지

작게 시작할 때의 기준선

초기 AI 플랫폼을 설계할 때 가장 흔한 실수는 두 가지입니다. 하나는 노트북, 스크립트, 수동 배포만으로 PoC를 끝내는 것입니다. 이 경우 모델 성능은 검증할 수 있어도 운영 가능성은 검증하기 어렵습니다. 다른 하나는 처음부터 대규모 MLOps 플랫폼을 만들려는 것입니다. 이 경우 실제 사용자가 생기기 전에 플랫폼 복잡도가 먼저 커집니다.

현실적인 출발점은 그 사이입니다. Kubernetes 클러스터 하나를 기준으로 개발, 검증, 제한적 운영까지 이어질 수 있는 최소 구성을 잡습니다.

초기 기준선은 다음 정도면 충분합니다.

• 환경 분리를 위한 네임스페이스

• CPU 노드풀과 GPU 노드풀 분리

• GPU 드라이버와 디바이스 플러그인 구성

• 컨테이너 이미지 저장소

• 데이터와 모델 아티팩트를 저장할 오브젝트 스토리지

• 모델 버전 또는 모델 패키지 저장소

• API 키, DB 비밀번호, 토큰을 위한 시크릿 관리

• 추론 서비스를 외부 또는 내부에 노출할 Ingress/API Gateway

• 기본 로그, 메트릭, 비용 확인 체계

여기서 중요한 것은 "도구 이름"이 아니라 "역할"입니다. 특정 솔루션은 조직의 클라우드, 보안 정책, 기존 DevOps 체계에 맞춰 선택하면 됩니다. 컨테이너 레지스트리, 오브젝트 스토리지, 시크릿 매니저도 반드시 클러스터 안에 설치해야 하는 것은 아닙니다. 관리형 클라우드 서비스를 써도 되고, 이미 조직에서 운영 중인 공통 서비스를 연결해도 됩니다.

네임스페이스로 환경과 책임을 나누기

Kubernetes에서 네임스페이스는 하나의 클러스터 안에서 리소스를 논리적으로 나누는 경계입니다. 초기 AI 플랫폼에서는 최소한 다음 세 가지 네임스페이스를 권장합니다.

이 구조는 단순하지만 효과가 큽니다. 개발 실험이 운영 서비스에 영향을 주지 않고, 운영 배포 전에 스테이징에서 이미지, 모델 파일, 환경변수, GPU 요청량을 검증할 수 있습니다.

다만 네임스페이스만으로 보안이 완성되는 것은 아닙니다. 네임스페이스는 리소스를 나누는 기본 경계이고, 실제 통제는 RBAC, 리소스 쿼터, 네트워크 정책, 시크릿 접근 제어를 함께 적용해야 작동합니다.

네임스페이스를 나눌 때 함께 정해야 할 것은 권한과 쿼터입니다.

• ai-dev는 실험 속도를 위해 배포 권한을 비교적 넓게 줄 수 있습니다.

• ai-staging은 운영과 동일한 배포 파이프라인을 사용하되 외부 노출을 제한합니다.

• ai-prod는 승인된 서비스 계정과 배포 파이프라인만 변경할 수 있게 합니다.

• GPU는 네임스페이스별 쿼터를 둬야 특정 팀이 전체 자원을 점유하는 일을 줄일 수 있습니다.

초기에는 복잡한 멀티테넌시보다 "환경 분리 + 팀별 쿼터 + 최소 권한"만 지켜도 충분합니다. 여러 팀이 동시에 사용하기 시작하면 팀 단위 네임스페이스를 추가하거나, 프로젝트별 네임스페이스로 확장하면 됩니다.

CPU 노드풀과 GPU 노드풀 분리하기

AI 플랫폼에서 비용을 좌우하는 핵심은 GPU입니다. GPU 노드는 비싸고, 모든 작업에 필요한 것도 아닙니다. 따라서 초기부터 CPU 노드풀과 GPU 노드풀을 분리하는 것이 좋습니다.

기본 구조는 다음과 같습니다.

Kubernetes Cluster
├─ CPU Node Pool
│  ├─ API Gateway / Ingress Controller
│  ├─ 전처리 작업
│  ├─ 일반 배치 작업
│  ├─ 로그·모니터링 에이전트
│  └─ 가벼운 추론 서비스
│
└─ GPU Node Pool
   ├─ 모델 학습 Job
   ├─ 파인튜닝 Job
   ├─ GPU 기반 실시간 추론 Pod
   └─ 대규모 배치 추론 Job

CPU 노드풀에는 일반 웹 API, 전처리, 큐 워커, 모니터링 구성 요소를 배치합니다. GPU 노드풀에는 학습, 파인튜닝, GPU 추론처럼 실제로 GPU가 필요한 작업만 배치합니다.

여기서 한 가지를 분명히 해야 합니다. GPU 노드풀을 만든다고 해서 Kubernetes가 GPU를 자동으로 세밀하게 관리하는 것은 아닙니다. GPU 노드에는 적절한 드라이버가 준비되어 있어야 하고, 클러스터에는 GPU를 Kubernetes 리소스로 노출하는 디바이스 플러그인이나 GPU Operator 같은 구성이 필요합니다. 관리형 Kubernetes를 쓰더라도 이 부분이 자동으로 제공되는지, 별도 애드온을 설치해야 하는지 먼저 확인해야 합니다.

운영 기준은 간단해야 합니다.

• GPU가 필요 없는 작업은 GPU 노드에 배치하지 않습니다.

• GPU 작업은 반드시 명시적으로 GPU 리소스를 요청하게 합니다.

• GPU 노드에는 라벨과 테인트를 설정해 실수로 일반 Pod가 올라가지 않게 합니다.

• 개발 환경의 GPU 사용량은 쿼터로 제한합니다.

• 장시간 학습 작업과 실시간 추론 서비스는 가능하면 다른 GPU 노드풀로 분리합니다.

테인트와 톨러레이션은 특정 노드에 아무 Pod나 배치되지 않게 하는 Kubernetes의 장치입니다. 예를 들어 GPU 노드에 "GPU 작업만 허용"이라는 표시를 해두고, GPU가 필요한 Pod만 그 표시를 허용하도록 설정하는 방식입니다. 여기에 노드 라벨과 노드 선택 조건을 함께 쓰면 "GPU가 필요한 Pod는 GPU 노드로, 일반 Pod는 CPU 노드로"라는 배치 기준을 더 명확히 만들 수 있습니다.

초기에는 GPU 노드풀을 하나만 두고 시작해도 됩니다. 다만 운영 추론이 시작되면 학습용 GPU와 추론용 GPU를 분리하는 것을 검토해야 합니다. 학습 작업은 긴 시간 동안 자원을 점유하고, 추론 서비스는 안정적인 응답 시간이 중요하기 때문입니다.

최소 플랫폼 구성 요소

작은 AI 플랫폼이라도 저장소와 배포 흐름은 처음부터 정리해야 합니다. 모델 파일이 개인 노트북이나 임시 디렉터리에 있으면 운영 전환이 어렵습니다.

초기 구성은 다음 네 가지 저장·관리 계층으로 나눌 수 있습니다.

1. 컨테이너 레지스트리

컨테이너 레지스트리는 학습 코드, 추론 서버, 전처리 스크립트를 이미지로 저장하는 곳입니다. Kubernetes는 이 이미지를 내려받아 Pod로 실행합니다.

초기 원칙은 단순합니다.

• 모든 학습·추론 코드는 컨테이너 이미지로 빌드합니다.

• 이미지 태그는 latest만 쓰지 말고 버전 또는 Git 커밋 ID를 포함합니다.

• 운영 배포에는 검증된 이미지 태그만 사용합니다.

• 한 번 운영에 사용한 태그는 가급적 덮어쓰지 않습니다.

이렇게 해야 "어떤 코드로 이 모델을 학습했는가", "어떤 이미지가 운영 추론에 배포되었는가"를 추적할 수 있습니다.

2. 오브젝트 스토리지

오브젝트 스토리지는 대용량 데이터를 저장하는 계층입니다. 학습 데이터, 전처리 결과, 평가 리포트, 배치 추론 결과를 저장하는 데 적합합니다.

PoC 단계에서도 데이터 저장 위치는 명확해야 합니다.

object-storage
├─ datasets/
├─ features/
├─ training-runs/
├─ batch-inference-results/
└─ evaluation-reports/

처음부터 복잡한 데이터 플랫폼을 만들 필요는 없습니다. 다만 데이터가 어디에 있고, 누가 접근할 수 있으며, 어떤 버전으로 학습했는지는 남겨야 합니다.

3. 모델 저장소

모델 저장소는 학습 결과물을 관리하는 공간입니다. 단순하게는 오브젝트 스토리지의 특정 경로를 모델 저장소로 사용할 수 있고, 조금 더 체계가 필요하면 모델 레지스트리 도구를 붙일 수 있습니다.

초기 모델 저장소에는 최소한 다음 정보가 함께 있어야 합니다.

• 모델 이름

• 모델 버전

• 학습에 사용한 데이터 버전

• 학습 이미지 태그

• 주요 평가 지표

• 배포 가능 여부

• 승인자 또는 검토 상태

모델 파일만 저장하면 운영 판단이 어렵습니다. "이 모델을 배포해도 되는가"를 판단할 수 있는 메타데이터가 함께 있어야 합니다.

4. 시크릿 관리

AI 워크로드는 다양한 민감 정보를 사용합니다. 데이터베이스 비밀번호, 외부 API 키, 오브젝트 스토리지 접근 키, 모델 다운로드 토큰 등이 대표적입니다.

초기에는 Kubernetes Secret으로 시작할 수 있습니다. 다만 Kubernetes Secret을 쓴다고 해서 자동으로 모든 보안 요구가 해결되는 것은 아닙니다. 클러스터 설정에 따라 암호화, 접근 제어, 감사 로그 수준이 달라질 수 있으므로 운영 환경에서는 저장 시 암호화와 RBAC 설정을 함께 확인해야 합니다. 조직에 이미 클라우드 시크릿 매니저나 사내 비밀 관리 시스템이 있다면 그것과 연동하는 편이 좋습니다.

기본 원칙은 다음과 같습니다.

• 비밀번호와 토큰을 컨테이너 이미지에 넣지 않습니다.

• Git 저장소에 시크릿 값을 커밋하지 않습니다.

• 개발, 스테이징, 운영 시크릿을 분리합니다.

• 운영 시크릿 접근 권한은 서비스 계정 단위로 제한합니다.

시크릿 관리는 작게 시작해도 반드시 포함해야 합니다. 나중에 붙이는 보안은 보통 더 어렵고, 이미 퍼진 키를 회수하는 비용도 큽니다.

추론 서비스를 노출하는 기본 흐름

AI 플랫폼의 가치는 모델을 서비스로 연결할 때 드러납니다. Kubernetes에서는 보통 Pod, Service, Ingress 또는 API Gateway를 조합해 추론 API를 노출합니다.

기본 흐름은 다음과 같습니다.

Client / Internal Service
        │
        ▼
API Gateway 또는 Ingress
        │
        ▼
Kubernetes Service
        │
        ▼
Inference Pods
        │
        ▼
Model Artifact / Feature Store / External DB

각 구성 요소의 역할은 다릅니다.

• Pod: 실제 추론 서버가 실행되는 단위입니다.

• Service: 여러 추론 Pod 앞에서 안정적인 내부 접속 지점을 제공합니다.

• Ingress: HTTP 요청을 클러스터 내부 서비스로 라우팅합니다.

• API Gateway: 인증, 사용량 제한, 라우팅, 감사 로그 같은 API 관리 기능을 제공합니다.

초기에는 Ingress만으로도 충분할 수 있습니다. 내부 사용자만 호출하는 PoC API라면 복잡한 Gateway가 필요하지 않을 수 있습니다. 반대로 외부 고객, 여러 내부 시스템, 파트너가 호출한다면 API Gateway를 앞단에 두는 편이 운영상 유리합니다.

추론 서비스 노출 방식은 다음 기준으로 선택합니다.

중요한 것은 처음부터 외부 공개를 전제로 설계하지 않는 것입니다. PoC에서는 내부 호출로 충분할 수 있습니다. 다만 운영 전환 가능성이 있다면 인증, 로깅, 요청 제한을 어디에서 처리할지 미리 정해두는 것이 좋습니다.

1페이지 참조 아키텍처

아래 구성은 전자책 독자가 바로 가져다 쓸 수 있는 최소 기준 아키텍처입니다. 특정 클라우드나 제품에 종속되지 않는 형태로 정리했습니다.

[사용자 / 내부 시스템]
        │
        ▼
[API Gateway 또는 Ingress]
        │
        ▼
[Inference Service]
        │
        ▼
[Inference Pods on CPU/GPU Nodes]
        │
        ├───────────────┐
        ▼               ▼
[Model Store]       [Object Storage]
        │               │
        ▼               ▼
[Model Metadata]    [Datasets / Features / Results]

[Kubernetes Cluster]
├─ Namespaces
│  ├─ ai-dev
│  ├─ ai-staging
│  └─ ai-prod
│
├─ CPU Node Pool
│  ├─ API Gateway / Ingress
│  ├─ 전처리 Job
│  ├─ 배치 작업
│  └─ 모니터링 에이전트
│
├─ GPU Node Pool
│  ├─ GPU Driver / Device Plugin
│  ├─ Training Job
│  ├─ Fine-tuning Job
│  ├─ Batch Inference Job
│  └─ Real-time Inference Pod
│
├─ Platform Services
│  ├─ Container Registry
│  ├─ Secret Management
│  ├─ Logging / Metrics
│  └─ CI/CD Pipeline
│
└─ Policies
   ├─ RBAC
   ├─ ResourceQuota
   ├─ NetworkPolicy
   └─ Image Pull / Approval Policy

위 그림에서 Platform Services는 반드시 클러스터 내부에 설치된다는 뜻이 아닙니다. 조직 상황에 따라 클러스터 밖의 관리형 서비스일 수도 있고, 사내 공통 플랫폼일 수도 있습니다. 중요한 것은 AI 워크로드가 같은 방식으로 이미지를 가져오고, 모델을 저장하고, 시크릿을 읽고, 로그와 메트릭을 남기게 만드는 것입니다.

이 아키텍처에서 반드시 먼저 결정해야 할 질문은 다음과 같습니다.

• 개발, 스테이징, 운영의 경계는 어디인가?

• GPU를 누가, 얼마나, 어떤 우선순위로 사용할 수 있는가?

• GPU 노드를 Kubernetes에서 사용할 수 있도록 드라이버와 디바이스 플러그인은 어떻게 관리할 것인가?

• 모델 파일과 모델 메타데이터는 어디에 저장하는가?

• 운영 배포에 사용할 컨테이너 이미지는 어떻게 승인하는가?

• 추론 API는 내부용인가, 외부 공개용인가?

• 시크릿과 데이터 접근 권한은 어떤 단위로 제한하는가?

이 질문에 답할 수 있다면 초기 플랫폼 설계의 절반은 끝난 셈입니다.

단계별 도입 순서

작게 시작하려면 한 번에 모든 구성 요소를 붙이지 않는 것이 좋습니다. 다음 순서로 진행하면 부담이 줄어듭니다.

1단계: 클러스터와 네임스페이스 구성
ai-dev, ai-staging, ai-prod를 만들고 기본 RBAC와 리소스 쿼터를 설정합니다. 이 단계에서는 완벽한 자동화보다 환경 경계를 명확히 하는 것이 중요합니다.

2단계: CPU/GPU 노드풀 분리
GPU 노드에 라벨과 테인트를 적용합니다. GPU 드라이버와 디바이스 플러그인 구성을 확인하고, GPU가 필요한 Job과 추론 Pod만 해당 노드에 배치되도록 합니다.

3단계: 이미지와 모델 저장 흐름 정리
컨테이너 레지스트리, 오브젝트 스토리지, 모델 저장 경로를 정합니다. 모델 버전과 학습 이미지 태그를 함께 기록합니다.

4단계: 첫 추론 서비스 배포
간단한 모델 하나를 API로 배포합니다. Service와 Ingress를 연결하고, 요청 로그와 기본 메트릭을 확인합니다.

5단계: 운영 전환 기준 추가
스테이징 검증, 승인된 이미지 태그, 시크릿 분리, 배포 롤백, 기본 알림을 추가합니다. 네트워크 정책을 적용한다면 사용 중인 CNI가 NetworkPolicy를 지원하는지도 함께 확인합니다.

이 순서를 따르면 PoC가 끝난 뒤에도 결과물을 버리지 않아도 됩니다. 실험 환경이 곧 운영 후보 환경이 되고, 운영 전환에 필요한 차이만 하나씩 줄이면 됩니다.

작게 시작하되 버리지 않을 구조

초기 AI 플랫폼의 성공 기준은 화려한 기능이 아닙니다. 한 팀이 만든 모델을 다른 팀도 같은 방식으로 배포할 수 있는지, GPU 비용을 설명할 수 있는지, 장애가 났을 때 어떤 버전의 모델과 이미지가 실행 중이었는지 알 수 있는지가 더 중요합니다.

작은 기준 아키텍처는 다음 세 가지를 남겨야 합니다.

• 반복 가능한 배포 흐름

• 통제 가능한 자원 사용

• 추적 가능한 모델과 데이터 이력

이 세 가지가 있으면 플랫폼은 천천히 커질 수 있습니다. 이후에는 GPU 스케줄링, 모델 파이프라인, 보안, 비용 최적화를 단계적으로 더하면 됩니다. 반대로 이 기준선이 없으면 PoC는 성공해도 운영은 다시 시작해야 할 가능성이 큽니다.