[LLMOps 가이드] PoC를 넘어 프로덕션 레벨 LLM 배포: K8s 기반 최적화 및 GPU 자원 관리 전략

안녕하세요, AI 플랫폼 아키텍트 여러분.

최근 LLM 기술의 발전 속도는 경이롭습니다. 몇 주 전만 해도 'PoC(Proof of Concept)' 단계에서 API 키 몇 번 호출하는 수준이었다면, 이제는 수백 명의 동시 사용자가 몰리는 실제 서비스의 핵심 기능으로 자리 잡고 있습니다.

하지만 솔직히 말씀드리자면, PoC 환경에서 잘 돌아가던 모델이 프로덕션 환경에서 트래픽을 받기 시작하면, 예상치 못한 벽에 부딪히는 경우가 비일비재합니다.

"지연 시간이 너무 길어요.", "GPU 자원을 너무 많이 잡아먹어서 다른 서비스가 느려져요.", "사용량이 폭증할 때 비용이 감당이 안 돼요."

이런 문제들이 바로 우리가 오늘 다룰 '운영(Operation)'의 복잡성입니다. 단순히 모델을 배포하는 것을 넘어, 고가용성(HA)을 확보하고, 비용 효율성을 극대화하며, 수많은 트래픽을 안정적으로 처리하는 아키텍처 설계가 필요합니다.

이 글은 ML 엔지니어, DevOps 엔지니어, AI 플랫폼 아키텍트 여러분이 PoC 단계를 넘어, 실제 비즈니스 트래픽을 감당하는 '프로덕션 레벨 LLMOps' 아키텍처를 구축하는 데 필요한 핵심 기술 스택과 설계 원칙을 깊이 있게 다루고자 합니다.

1. 왜 LLM 배포는 어려운가? (PoC와 프로덕션의 괴리)

우리가 흔히 간과하는 LLM 배포의 어려움은 '추론(Inference)' 자체의 문제가 아닙니다. 문제는 **'운영(Serving)'**의 영역에 있습니다.

PoC 단계에서는 보통 다음과 같은 단순한 흐름으로 테스트합니다. 사용자 요청 -> API Gateway -> 모델 추론 -> 응답

하지만 프로덕션에서는 이 흐름 하나하나가 병목 지점이 될 수 있습니다.

1. 지연 시간(Latency)의 문제: 사용자는 1초 이내의 응답을 기대합니다. 모델 추론 시간 외에도, 요청을 받아 큐에 넣고, 자원을 할당하고, 응답을 전송하는 오버헤드가 누적됩니다.
2. 비용(Cost)의 문제: GPU는 가장 비싼 자원 중 하나입니다. GPU를 100% 사용하지 못하고 20%만 사용한다면, 나머지 80%는 '낭비되는 비용'입니다.
3. 확장성(Scalability)의 문제: 트래픽이 갑자기 10배로 늘어났을 때, 수동 개입 없이 자동으로 자원을 늘리고(Scale-out), 자원이 남으면 줄이는(Scale-in) 메커니즘이 필수적입니다.

이러한 요구사항을 만족시키기 위해, 우리는 **컨테이너 오케스트레이션 도구인 Kubernetes(K8s)**를 중심으로 아키텍처를 설계해야 합니다.

2. 모델 서빙 아키텍처의 기본 이해와 병목 지점 분석

LLM 추론 과정은 단순히 행렬 곱셈의 연속이 아닙니다. 여기에는 여러 물리적 병목 지점이 존재합니다.

LLM 추론 과정의 병목 지점

LLM 추론은 크게 Compute (계산), Memory Bandwidth (메모리 대역폭), I/O (입출력) 세 가지 자원의 싸움입니다.

• Compute: 트랜스포머 레이어의 가중치 계산 자체의 복잡도입니다.
• Memory Bandwidth: 가장 치명적일 수 있습니다. LLM은 수많은 파라미터(가중치)를 메모리에서 읽어와야 하는데, 이 데이터 전송 속도가 느리면 아무리 좋은 GPU를 써도 병목이 발생합니다.
• I/O: 요청을 받아 큐에 넣고, 결과를 외부로 내보내는 과정의 지연 시간입니다.

기존 배포 방식의 한계점: 단일 GPU 할당의 비효율성

가장 흔한 실수는 모델 하나를 통째로 하나의 GPU에 할당하는 것입니다.

# ❌ 비효율적인 예시 (GPU 전체를 점유)
resources:
  limits:
    nvidia.com/gpu: 1  # GPU 1개 전체를 사용한다고 선언

이 방식은 모델이 GPU의 30%만 사용해도, 나머지 70%는 다른 서비스가 사용할 수 없게 만드는 '자원 고립(Resource Siloing)' 문제를 야기합니다. 이는 비용 효율성 측면에서 치명적입니다.

3. Kubernetes를 활용한 모델 오케스트레이션 및 자원 격리

K8s는 이러한 자원 고립 문제를 해결하고, 모델 배포를 일련의 자동화된 파이프라인으로 만들어줍니다.

K8s를 이용한 모델 배포 파이프라인 구축 개요

우리는 모델을 단순한 Pod가 아닌, **'서비스 엔티티'**로 취급해야 합니다. 이를 위해 보통 Kubernetes Operator 패턴을 사용하거나, Helm Chart를 활용하여 모델 버전, 스케일링 정책, 리소스 요청을 묶어 배포합니다.

실무 적용 예시: GPU 리소스 요청

GPU 자원을 요청할 때는 반드시 Device Plugin을 통해 네이티브 리소스로 인식시켜야 합니다.

# ✅ 실무 적용 예시: GPU 리소스 요청 (v1.27+ 기준)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: llm-inference-service
spec:
  template:
    spec:
      containers:
      - name: model-server
        image: your-registry/llm-server:latest
        resources:
          limits:
            # GPU 1개를 요청합니다. (실제로는 파티셔닝을 고려해야 함)
            nvidia.com/gpu: 1
          requests:
            nvidia.com/gpu: 1

GPU 자원 관리의 핵심: 파티셔닝과 다중 모델 동시 서빙 (Multi-tenancy)

진정한 최적화는 **'GPU를 쪼개서 쓰는 것'**에서 시작됩니다.

1. GPU 파티셔닝 (Virtualization): 최신 GPU 아키텍처(예: NVIDIA MIG)를 사용하거나, 소프트웨어적으로 메모리 및 컴퓨팅 자원을 논리적으로 분할하여 여러 모델이 하나의 GPU를 공유하게 만드는 기술이 필요합니다. 이는 자원 활용률(Utilization)을 극대화하는 핵심입니다.
2. Multi-tenancy (다중 모델 동시 서빙): 단순히 여러 Pod를 띄우는 것을 넘어, 하나의 GPU 인스턴스 내에서 여러 개의 독립적인 모델(또는 같은 모델의 다른 버전)을 동시에 로드하고 추론하게 만드는 것이 목표입니다. 이는 GPU 메모리 및 컴퓨팅 파이프라인을 공유하여 오버헤드를 줄입니다.

4. 성능과 비용을 극대화하는 최적화 기법 (The Optimization Stack)

아무리 K8s로 자원을 잘 분배해도, 모델 서빙 엔진 자체가 비효율적이라면 소용이 없습니다. 여기서는 세 가지 축으로 최적화를 진행합니다.

🚀 추론 엔진 비교: 나에게 맞는 무기를 선택하라

현재 시장에는 여러 강력한 서빙 엔진들이 존재합니다. 어떤 것을 쓸지는 **'사용 목적'**에 따라 달라집니다.

핵심 요약: 동시 요청 처리량이 가장 중요하다면 vLLM을, 가장 안정적이고 폭넓은 지원이 필요하다면 TGI를 우선 고려하세요.

💡 메모리 최적화: Paged Attention과 KV Cache

LLM 추론 시 가장 큰 병목은 KV Cache 관리입니다. 매 토큰마다 이전 토큰들의 Key와 Value를 저장해야 하는데, 이 캐시가 메모리를 엄청나게 차지합니다.

Paged Attention (vLLM의 핵심): 운영체제의 가상 메모리 개념을 차용하여, KV Cache를 페이지 단위로 관리합니다. 이는 메모리 단편화(Fragmentation)를 막고, 같은 GPU 메모리 공간에서 더 많은 요청을 처리할 수 있게 해주는 혁신적인 기술입니다.

🚀 실전 최적화: 배치 처리와 동적 배치

단순히 요청을 순서대로 처리하는 것이 아니라, **여러 요청을 모아서 한 번에 처리(Batching)**해야 합니다.

• Static Batching: 고정된 크기로 묶어 처리합니다.
• Dynamic Batching (Continuous Batching): 요청이 들어오는 즉시, 완료되는 요청의 자원을 즉시 다른 요청에 할당합니다. 이것이 현대 LLM 서빙의 표준이며, vLLM 등이 이를 구현합니다.

결론적으로, 성공적인 LLM 서빙은 단순히 모델을 올리는 것이 아니라, '최적의 추론 엔진(vLLM/TGI)을 선택하여, 동적 배치와 Paged Attention을 통해 GPU 자원을 낭비 없이 최대한 활용하는 공학적 과정'입니다.