AI 워크로드를 Kubernetes 관점에서 다시 보기

핵심 메시지: 모델이 아니라 실행 단위로 본다

AI 프로젝트는 종종 "좋은 모델을 만드는 일"로 설명됩니다. 그러나 운영 단계로 넘어가면 질문이 달라집니다. 모델의 정확도만큼이나 중요한 것은 어떤 작업이, 언제, 어떤 자원으로, 얼마나 오래 실행되는가입니다.

Kubernetes 관점에서 AI 시스템을 보면 모델 개발은 여러 실행 단위로 나뉩니다. 학습 작업, 하이퍼파라미터 튜닝, 배치 추론, 실시간 추론, 데이터 전처리, 모델 배포, 로그 수집이 각각 다른 방식으로 실행됩니다. 어떤 작업은 몇 시간 뒤 끝나고, 어떤 작업은 24시간 계속 떠 있어야 합니다. 어떤 작업은 GPU를 짧고 강하게 쓰고, 어떤 작업은 CPU와 메모리를 넓게 씁니다.

이 장의 목적은 AI 시스템을 막연한 "AI 플랫폼"이 아니라 Kubernetes에서 운영 가능한 워크로드 구조로 다시 보는 것입니다. 이 관점이 잡히면 이후 아키텍처 설계, GPU 관리, 모델 서빙, 비용 최적화 논의가 훨씬 명확해집니다.

AI 생성 이미지

AI 워크로드는 하나의 형태가 아니다

AI 워크로드는 크게 네 가지 실행 패턴으로 나눌 수 있습니다.

학습 작업은 보통 "끝나는 작업"입니다. 특정 데이터셋과 코드 버전, 설정값을 기준으로 실행되고 결과 모델 파일을 남깁니다. 실패하면 어디서부터 다시 시작할지, 중간 산출물인 체크포인트를 어디에 저장할지가 중요합니다.

하이퍼파라미터 튜닝은 학습 작업의 반복입니다. 예를 들어 학습률, 배치 크기, 모델 구조를 바꿔가며 수십 개의 실험을 돌립니다. 이때 문제는 개별 작업보다 전체 실험 묶음의 자원 소비입니다. GPU가 비싼 조직에서는 "누가 몇 개의 GPU를 동시에 쓸 수 있는가"가 곧 운영 정책이 됩니다.

배치 추론은 일정량의 데이터를 모아 한 번에 예측 결과를 만드는 방식입니다. 고객 이탈 가능성 예측, 문서 분류, 이미지 태깅처럼 실시간 응답이 필요 없는 업무에 잘 맞습니다. 배치 추론은 서비스 지연 시간보다 처리량과 실패 재시도가 중요합니다.

실시간 추론은 웹 API처럼 계속 떠 있는 서비스입니다. 사용자의 요청이 들어오면 모델이 즉시 응답해야 합니다. 이 경우 핵심은 짧은 응답 시간, 안정적인 확장, 새 모델 배포 시 장애를 줄이는 방식입니다.

같은 AI라는 이름을 쓰더라도 네 가지 작업의 운영 요구사항은 다릅니다. 따라서 하나의 배포 방식으로 모두 처리하려 하기보다, 실행 특성에 맞게 Kubernetes 리소스를 선택해야 합니다.

Kubernetes 리소스로 AI 작업을 해석하기

Kubernetes에서 모든 실행은 결국 Pod 위에서 이루어집니다. Pod는 컨테이너가 실제로 실행되는 가장 작은 단위입니다. 그러나 AI 플랫폼을 설계할 때는 Pod만 보면 부족합니다. 작업의 수명과 운영 방식에 따라 Job, CronJob, Deployment, StatefulSet 같은 상위 리소스를 함께 봐야 합니다.

Pod: 실행의 최소 단위

Pod는 모델 학습 코드, 데이터 전처리 스크립트, 추론 서버 컨테이너가 실제로 올라가는 단위입니다. GPU가 필요한 경우 Pod는 "GPU 1개 필요", "메모리 64GiB 필요"처럼 자원을 요청합니다.

다만 운영자가 보통 Pod를 직접 만들지는 않습니다. 학습처럼 끝나는 작업은 Job이 Pod를 만들고, 실시간 추론 서비스는 Deployment가 Pod를 관리합니다. Pod는 실행의 최소 단위이고, 실제 운영 설계는 그 위의 컨트롤러를 선택하는 문제에 가깝습니다.

Job: 끝나는 AI 작업에 적합

Job은 실행 후 완료되는 작업에 적합합니다. 모델 학습, 일회성 데이터 전처리, 평가 작업, 배치 추론이 대표적인 예입니다.

예를 들어 매일 밤 새 데이터로 추천 모델을 다시 학습한다면 학습 컨테이너를 Job으로 실행할 수 있습니다. Job은 작업이 실패했을 때 재시도할 수 있고, 완료 상태를 남길 수 있습니다. 운영자는 "이 학습이 성공했는가", "몇 번 실패했는가", "어떤 로그를 남겼는가"를 확인할 수 있습니다.

AI 학습에서는 Job과 함께 체크포인트 저장 위치를 반드시 설계해야 합니다. GPU 노드가 재시작되거나 작업이 중단될 수 있기 때문입니다. 컨테이너 안에만 결과를 저장하면 Pod가 사라질 때 결과도 함께 사라질 수 있습니다.

CronJob: 정해진 시간에 반복되는 작업

CronJob은 일정에 따라 Job을 실행합니다. 매일 새벽 데이터 전처리, 주간 리포트 생성, 정기 배치 추론처럼 반복 일정이 있는 작업에 적합합니다.

다만 CronJob을 무분별하게 늘리면 클러스터가 특정 시간대에 갑자기 바빠질 수 있습니다. 예를 들어 모든 팀이 새벽 2시에 배치 추론을 실행하면 CPU, GPU, 스토리지 I/O가 동시에 몰립니다. 운영 환경에서는 실행 시간을 분산하고, 실패 시 재시도 정책을 명확히 두는 편이 안전합니다.

Deployment: 계속 떠 있어야 하는 추론 서비스

Deployment는 실시간 추론 API처럼 항상 실행되어야 하는 서비스에 적합합니다. Deployment는 원하는 Pod 개수를 유지하고, 새 버전으로 점진적으로 교체할 수 있습니다.

예를 들어 텍스트 분류 모델을 API로 제공한다면 Deployment로 여러 개의 추론 Pod를 띄울 수 있습니다. 트래픽이 늘어나면 Pod 수를 늘리고, 새 모델 버전을 배포할 때는 기존 Pod를 한꺼번에 내리지 않고 순차적으로 교체할 수 있습니다.

실시간 추론에서는 단순히 Pod를 많이 띄우는 것만으로 충분하지 않습니다. 모델 로딩 시간이 길 수 있고, GPU 메모리 사용량이 크며, 요청 지연 시간이 비즈니스 지표와 직접 연결될 수 있습니다. 따라서 준비 상태 확인, 자동 확장 기준, 롤백 전략을 함께 설계해야 합니다.

StatefulSet: 상태를 가진 구성 요소에 신중하게 사용

StatefulSet은 각 Pod에 안정적인 이름과 저장소를 부여해야 할 때 사용합니다. AI 워크로드에서 직접 모델 서버를 StatefulSet으로 운영하는 경우는 제한적입니다. 그러나 벡터 데이터베이스, 일부 분산 학습 구성 요소, 상태를 가진 내부 서비스에는 필요할 수 있습니다.

중요한 점은 "상태가 있다"는 이유만으로 StatefulSet을 선택하지 않는 것입니다. 모델 파일, 데이터셋, 로그처럼 저장이 필요한 요소는 오브젝트 스토리지, 파일 스토리지, 데이터베이스 등 외부 저장 계층으로 분리하는 편이 운영상 단순한 경우가 많습니다.

CPU 중심 작업과 GPU 중심 작업은 비용 구조가 다르다

Kubernetes에서 CPU와 메모리는 비교적 잘게 나누어 여러 Pod에 배분하기 쉽습니다. 반면 GPU는 대개 고가이고, 물리 장치 단위로 할당되는 경우가 많습니다. 이 차이가 AI 플랫폼의 운영 비용을 크게 좌우합니다.

CPU 중심 워크로드는 데이터 전처리, 피처 생성, 간단한 배치 추론, API 주변 로직에 많이 사용됩니다. 이런 작업은 여러 노드에 넓게 분산하기 쉽고, 수평 확장을 적용하기도 상대적으로 단순합니다.

GPU 중심 워크로드는 대규모 학습, 파인튜닝, 고성능 추론에 사용됩니다. GPU는 비용이 높고 유휴 시간이 곧 낭비로 이어지기 때문에 스케줄링 정책이 중요합니다. 예를 들어 한 팀이 장시간 학습 작업으로 모든 GPU를 점유하면 다른 팀의 긴급 추론 실험이 지연될 수 있습니다.

실무에서는 다음 기준을 먼저 정하는 것이 좋습니다.

• 팀별 GPU 사용 한도를 둘 것인가

• 학습 작업과 실시간 추론 작업을 같은 GPU 노드 풀에서 실행할 것인가

• 낮 시간에는 추론을 우선하고, 밤에는 학습을 우선할 것인가

• 실패한 학습 작업의 재시도를 몇 번까지 허용할 것인가

• GPU가 필요한 작업과 CPU로 충분한 작업을 어떻게 구분할 것인가

이 질문에 답하지 않고 Kubernetes만 도입하면, 클러스터는 있어도 GPU 비용은 통제되지 않을 수 있습니다. Kubernetes는 자원을 배치하는 도구이지, 조직의 우선순위를 자동으로 정해주지는 않습니다.

데이터, 모델, 피처, 로그의 이동 흐름을 그려야 한다

AI 워크로드는 컨테이너만 배포해서 끝나지 않습니다. 데이터가 들어오고, 전처리되고, 학습에 사용되고, 모델 파일로 저장되고, 추론 서비스에 배포되고, 다시 로그가 쌓입니다. 이 흐름을 보지 않으면 운영 설계가 단편적으로 됩니다.

전형적인 흐름은 다음과 같습니다.

1. 원천 데이터가 데이터 레이크, 데이터베이스, 파일 스토리지에 저장된다.

2. 전처리 Job이 데이터를 읽고 학습용 데이터셋이나 피처를 만든다.

3. 학습 Job이 데이터셋을 읽고 모델 파일과 체크포인트를 저장한다.

4. 모델 검증 작업이 성능 지표와 품질 기준을 확인한다.

5. 승인된 모델이 모델 저장소 또는 오브젝트 스토리지에 등록된다.

6. 추론 Deployment가 특정 모델 버전을 로딩해 API로 제공한다.

7. 요청 로그, 예측 결과, 성능 지표가 모니터링·로그 시스템으로 전달된다.

여기서 Kubernetes 안에 둘 것과 밖에 둘 것을 구분해야 합니다. 대용량 원천 데이터와 장기 보관 모델 파일은 보통 클러스터 외부 저장소에 두는 편이 안정적입니다. Kubernetes 안의 Pod는 필요한 시점에 데이터를 읽고 결과를 다시 외부 저장소에 남기는 방식이 일반적입니다.

피처도 마찬가지입니다. 피처는 모델이 예측에 사용하는 가공된 입력값입니다. 학습 때 사용한 피처 계산 방식과 추론 때 사용하는 방식이 다르면 모델 성능이 흔들릴 수 있습니다. 따라서 피처 생성 로직, 데이터 버전, 모델 버전을 함께 추적하는 체계가 필요합니다.

로그는 단순한 장애 분석 자료가 아닙니다. 추론 요청 수, 응답 시간, 오류율, 모델별 사용량, 예측 분포 변화는 운영과 비용 판단의 근거가 됩니다. 특히 B2B 환경에서는 특정 고객이나 업무 단위별 사용량을 파악해야 비용 배분과 서비스 품질 계약을 논의할 수 있습니다.

연구용 노트북과 운영용 서비스는 분리한다

AI 팀은 노트북 환경에서 빠르게 실험합니다. Jupyter 같은 노트북은 데이터 확인, 모델 실험, 시각화에 매우 유용합니다. 문제는 노트북 환경을 그대로 운영 서비스로 가져갈 때 생깁니다.

연구용 노트북은 유연성이 중요합니다. 라이브러리를 즉시 설치하고, 코드를 셀 단위로 실행하며, 중간 결과를 사람이 직접 확인합니다. 반면 운영용 서비스는 반복 가능성과 안정성이 중요합니다. 같은 입력에 대해 같은 코드와 같은 모델 버전이 실행되어야 하고, 장애가 나면 자동으로 복구되어야 합니다.

따라서 두 환경은 목적에 맞게 분리하는 것이 좋습니다.

분리한다는 말은 연구 환경을 제한하자는 뜻이 아닙니다. 오히려 연구자는 더 자유롭게 실험하고, 운영자는 검증된 코드만 안정적으로 배포할 수 있게 하자는 의미입니다.

실무적으로는 노트북에서 검증한 코드를 컨테이너 이미지로 패키징하고, 학습은 Job으로, 배치 처리는 CronJob으로, 추론은 Deployment로 옮기는 흐름을 만들 수 있습니다. 이 과정에서 데이터 경로, 모델 버전, 환경 변수, 의존 라이브러리를 명확히 고정해야 합니다.

워크로드 분류가 플랫폼 설계의 출발점이다

AI 플랫폼을 설계하기 전에 먼저 현재와 가까운 미래의 워크로드를 분류해야 합니다. 다음 질문이 출발점이 됩니다.

• 우리 조직의 AI 작업 중 학습, 배치 추론, 실시간 추론의 비중은 어느 정도인가

• GPU가 반드시 필요한 작업과 CPU로 충분한 작업은 무엇인가

• 장시간 실행되는 작업은 중단 시 어디서부터 재시작해야 하는가

• 모델 파일과 데이터셋은 어디에 저장하고, 누가 접근할 수 있는가

• 노트북 실험 결과를 운영 배포로 넘기는 기준은 무엇인가

• 고객 또는 팀별 사용량과 비용을 어떻게 추적할 것인가

이 질문에 답하면 Kubernetes에서 어떤 리소스를 먼저 표준화해야 하는지 보입니다. 실시간 추론이 핵심이면 Deployment, 자동 확장, 모델 로딩 전략이 먼저입니다. 정기 배치가 많다면 Job, CronJob, 데이터 접근 권한, 재시도 정책이 중요합니다. 연구 조직이 여러 팀으로 나뉘어 있다면 네임스페이스, 리소스 쿼터, GPU 노드 풀 정책이 먼저 필요할 수 있습니다.

Kubernetes 기반 AI 플랫폼은 거대한 시스템을 한 번에 만드는 일이 아닙니다. AI 작업을 실행 특성별로 나누고, 각 작업에 맞는 Kubernetes 리소스와 운영 정책을 연결하는 일에서 시작합니다. 이 분류가 명확할수록 다음 단계의 기준 아키텍처도 단순해집니다.