AI Model Deployment MLOps Pipeline: LLM 기반 모델의 개발부터 운영까지

최근 AI 기술의 발전은 놀라운 속도를 보여주고 있으며, 특히 LLM(Large Language Model)은 다양한 산업 분야에서 혁신적인 변화를 이끌고 있습니다. 하지만 우수한 AI 모델을 개발하는 것만큼 중요한 것은, 이 모델을 안정적이고 효율적으로 실제 서비스에 배포하고 운영하는 것입니다. 여기에서 MLOps(Machine Learning Operations) 파이프라인의 중요성이 부각됩니다.

이 글에서는 AI 모델, 특히 LLM 기반 모델을 개발부터 운영까지 원활하게 관리할 수 있는 MLOps 파이프라인 구축 전략에 대해 심층적으로 다루고자 합니다. 데이터 관리부터 모델 학습, 배포, 모니터링, 그리고 재학습에 이르는 전 과정에서 필요한 핵심 요소와 최신 트렌드, 그리고 실전 구현을 위한 코드 예시를 함께 살펴보겠습니다.

MLOps 파이프라인의 핵심 구성 요소

MLOps는 소프트웨어 개발의 DevOps 개념을 머신러닝 영역에 적용한 것으로, AI 모델의 개발부터 배포, 운영, 그리고 유지보수에 이르는 전 과정의 자동화와 효율화를 목표로 합니다. AI 모델은 코드뿐만 아니라 데이터와 모델 아티팩트라는 추가적인 관리 대상을 가지기 때문에, 일반적인 소프트웨어 개발보다 더 복잡한 파이프라인을 요구합니다.

MLOps 파이프라인은 일반적으로 다음과 같은 핵심 단계를 포함합니다.

1. 데이터 관리: 데이터 수집, 전처리, 버전 관리, 레이블링.
2. 모델 개발 및 학습: 모델 코드 개발, 실험 관리, 학습 실행, 모델 버전 관리.
3. 모델 검증 및 평가: 학습된 모델의 성능 및 품질 평가, 편향(bias) 검증.
4. 모델 배포: 컨테이너화, API 엔드포인트 생성, 배포 자동화.
5. 모델 모니터링: 배포된 모델의 성능, 데이터 드리프트, 개념 드리프트 감지.
6. 모델 재학습: 모니터링 결과에 따른 모델 재학습 및 업데이트.

이러한 단계들은 CI/CD(Continuous Integration/Continuous Deployment) 개념을 넘어 CT(Continuous Training)까지 확장되어, AI 모델이 지속적으로 개선되고 최적의 성능을 유지할 수 있도록 돕습니다.

LLM 배포를 위한 MLOps 고려사항

LLM은 기존 머신러닝 모델과는 다른 독특한 특성을 가지고 있어, MLOps 파이프라인 구축 시 특별한 고려가 필요합니다.

• 대규모 모델 및 자원 요구: LLM은 수십억 개에서 수천억 개의 파라미터를 가지며, 학습 및 추론에 막대한 GPU 자원을 요구합니다. 이는 인프라 설계 및 비용 최적화에 큰 영향을 미칩니다.
• 추론 비용 및 지연 시간: 모델의 크기가 크기 때문에 추론 시간이 길어질 수 있고, 이는 사용자 경험에 직접적인 영향을 미칩니다. 효율적인 서빙 프레임워크와 양자화(Quantization), 지식 증류(Knowledge Distillation) 같은 경량화 기법이 중요합니다.
• 프롬프트 엔지니어링 및 파인튜닝: LLM은 프롬프트에 민감하게 반응하며, 특정 도메인에 최적화하기 위한 파인튜닝이 빈번하게 발생합니다. 프롬프트 버전 관리와 파인튜닝 프로세스의 자동화가 필요합니다.
• 토크나이저 관리: 모델과 함께 사용되는 토크나이저 역시 중요한 아티팩트이며, 모델 버전과 함께 관리되어야 합니다.
• RAG (Retrieval Augmented Generation): 외부 지식 베이스를 활용하는 RAG 패턴은 LLM의 환각(hallucination)을 줄이고 최신 정보를 제공하는 데 효과적입니다. RAG 시스템을 MLOps 파이프라인에 통합하는 것은 데이터 파이프라인과 LLM 서빙 파이프라인의 조화를 의미합니다.

실전 MLOps 파이프라인 구축: 데이터 및 학습 단계

MLOps 파이프라인의 첫 단추는 데이터 관리와 모델 학습입니다. 이 단계에서는 재현성(reproducibility)과 실험 관리가 핵심입니다.

데이터 버전 관리

데이터는 모델 학습의 핵심 자원이므로, 버전 관리가 필수적입니다. 데이터 변경 이력을 추적하고, 특정 모델 학습에 사용된 데이터를 정확히 재현할 수 있어야 합니다. DVC(Data Version Control)나 Git LFS(Large File Storage)와 같은 도구를 활용할 수 있습니다.

# DVC를 사용한 데이터 버전 관리 예시
dvc init
dvc add data/raw_data.csv
git add data/.dvcignore data/raw_data.csv.dvc
git commit -m "Add raw data v1"

# 데이터 변경 후
dvc add data/raw_data.csv
git commit -m "Update raw data v2"

실험 관리 및 모델 학습

모델 학습 과정에서는 다양한 하이퍼파라미터, 데이터셋, 모델 아키텍처를 시도하게 됩니다. MLflow, Weights & Biases(W&B)와 같은 실험 관리 도구는 이러한 실험들을 체계적으로 기록하고 비교 분석할 수 있도록 돕습니다.

다음은 LLM 파인튜닝을 위한 데이터 전처리 및 학습 스크립트의 간략한 예시입니다.

# preprocess_and_train.py
import pandas as pd
from datasets import Dataset
from transformers import AutoTokenizer, AutoModelForCausalLM, TrainingArguments, Trainer
import mlflow

def preprocess_data(file_path: str):
    """CSV 파일에서 데이터를 로드하고 전처리합니다."""
    df = pd.read_csv(file_path)
    # 예시: 'instruction'과 'response' 컬럼을 결합하여 훈련 포맷으로 만듭니다.
    df['text'] = df.apply(lambda row: f"### Instruction:\n{row['instruction']}\n\n### Response:\n{row['response']}", axis=1)
    return Dataset.from_pandas(df)

def train_llm_model(model_name: str, dataset: Dataset, output_dir: str = "./fine_tuned_llm"):
    """LLM을 파인튜닝하고 MLflow에 결과를 로깅합니다."""
    mlflow.set_experiment("LLM Fine-tuning Experiment")
    with mlflow.start_run():
        tokenizer = AutoTokenizer.from_pretrained(model_name)
        # 패딩 토큰이 없는 경우 추가
        if tokenizer.pad_token is None:
            tokenizer.add_special_tokens({'pad_token': '[PAD]'})
            # 모델의 임베딩 레이어 크기 조정
            # model.resize_token_embeddings(len(tokenizer))

        def tokenize_function(examples):
            return tokenizer(examples["text"], truncation=True, padding="max_length", max_length=512)

        tokenized_dataset = dataset.map(tokenize_function, batched=True)

        model = AutoModelForCausalLM.from_pretrained(model_name)
        # 모델에 새로운 토큰 추가 시 임베딩 레이어 크기 조정 필요
        # model.resize_token_embeddings(len(tokenizer))

        training_args = TrainingArguments(
            output_dir=output_dir,
            num_train_epochs=3,
            per_device_train_batch_size=4,
            gradient_accumulation_steps=2,
            logging_dir='./logs',
            logging_steps=10,
            save_steps=500,
            evaluation_strategy="epoch",
            ml_flow=True, # MLflow 로깅 활성화
        )

        trainer = Trainer(
            model=model,
            args=training_args,
            train_dataset=tokenized_dataset,
            eval_dataset=tokenized_dataset, # 간단한 예시를 위해 동일 데이터셋 사용
            tokenizer=tokenizer,
        )

        trainer.train()
        trainer.save_model(output_dir)
        tokenizer.save_pretrained(output_dir)

        mlflow.log_params(training_args.to_dict())
        mlflow.log_artifact(output_dir)

if __name__ == "__main__":
    raw_data_path = "data/llm_finetuning_data.csv" # DVC로 관리되는 데이터 경로
    base_llm_model = "beomi/gemma-ko-7b" # 예시 모델명
    
    # 데이터 전처리
    processed_dataset = preprocess_data(raw_data_path)
    
    # 모델 학습 및 MLflow 로깅
    train_llm_model(base_llm_model, processed_dataset)

모델 배포 및 서빙 전략

학습된 모델은 안정적이고 효율적으로 서비스될 수 있도록 배포되어야 합니다. 특히 LLM은 높은 자원 요구 사항과 추론 복잡성 때문에 더욱 신중한 배포 전략이 필요합니다.

컨테이너화 및 오케스트레이션

Docker를 이용한 컨테이너화는 모델과 그 의존성을 격리하여 환경 불일치 문제를 해결하고 배포의 일관성을 보장합니다. Kubernetes는 이러한 컨테이너화된 애플리케이션을 자동으로 배포, 스케일링, 관리하는 오케스트레이션 도구로, 대규모 AI 서비스 환경에서 필수적입니다.

다음은 LLM 서빙을 위한 간단한 Dockerfile과 FastAPI 기반의 서빙 스크립트 예시입니다.

# Dockerfile
FROM python:3.9-slim-buster

WORKDIR /app

# 시스템 의존성 설치 (예: LLM 서빙 프레임워크에 필요한 라이브러리)
# RUN apt-get update && apt-get install -y --no-install-recommends \
#     libgl1-mesa-glx \
#     && rm -rf /var/lib/apt/lists/*

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# fine_tuned_llm 디렉토리를 복사 (학습된 모델 및 토크나이저)
COPY fine_tuned_llm/ ./fine_tuned_llm/
COPY main.py .

EXPOSE 8000

CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

# main.py (FastAPI 기반 LLM 서빙)
from fastapi import FastAPI
from pydantic import BaseModel
from transformers import pipeline, AutoTokenizer, AutoModelForCausalLM
import torch

class TextRequest(BaseModel):
    text: str
    max_new_tokens: int = 50

app = FastAPI()

# 모델 로딩 (GPU 사용 가능 시 GPU로 로드)
# LLM은 크기가 크므로, 애플리케이션 시작 시 로드
try:
    device = 0 if torch.cuda.is_available() else -1
    model_path = "./fine_tuned_llm" # Dockerfile에서 복사된 모델 경로
    tokenizer = AutoTokenizer.from_pretrained(model_path)
    model = AutoModelForCausalLM.from_pretrained(model_path).to(f"cuda:{device}" if device != -1 else "cpu")
    generator = pipeline("text-generation", model=model, tokenizer=tokenizer, device=device)
    print(f"Model loaded successfully on device: {device}")
except Exception as e:
    print(f"Error loading model: {e}")
    generator = None # 모델 로드 실패 시 None으로 설정

@app.post("/generate/")
async def generate_text(request: TextRequest):
    if generator is None:
        return {"error": "Model not loaded. Please check server logs."}
        
    try:
        # 프롬프트 구성 (파인튜닝 시 사용한 포맷과 일치시키는 것이 중요)
        formatted_prompt = f"### Instruction:\n{request.text}\n\n### Response:\n"
        
        result = generator(
            formatted_prompt, 
            max_new_tokens=request.max_new_tokens,
            do_sample=True, # 샘플링 기반 생성 활성화
            temperature=0.7, # 생성 다양성 조절
            top_p=0.9, # 상위 p 확률 내에서 샘플링
            num_return_sequences=1,
            pad_token_id=tokenizer.eos_token_id # 패딩 토큰을 EOS 토큰으로 설정
        )
        # 생성된 텍스트에서 입력 프롬프트 부분을 제거하고 응답만 추출
        generated_response = result[0]['generated_text'][len(formatted_prompt):].strip()
        return {"generated_text": generated_response}
    except Exception as e:
        return {"error": str(e)}

@app.get("/health")
async def health_check():
    return {"status": "ok", "model_loaded": generator is not None}

LLM 서빙 특화 프레임워크

LLM의 효율적인 서빙을 위해 vLLM, TGI(Text Generation Inference)와 같은 전용 프레임워크가 등장했습니다. 이들은 KV Cache 최적화, 연속 배치(Continuous Batching) 등을 통해 처리량(throughput)을 극대화하고 지연 시간을 최소화합니다. 프로덕션 환경에서는 이러한 전용 솔루션을 FastAPI와 결합하여 사용하는 것이 일반적입니다.

지속적인 통합/배포/학습 (CI/CD/CT) 구현

MLOps 파이프라인의 핵심은 CI/CD/CT를 통한 자동화입니다.

• CI (Continuous Integration): 개발자가 코드를 변경할 때마다 자동으로 테스트를 실행하고, 모델 학습 코드를 빌드하며, 잠재적인 오류를 조기에 발견합니다.
• CD (Continuous Deployment): CI 단계를 통과한 모델 아티팩트와 서빙 코드를 자동으로 배포 환경에 배포합니다. 카나리 배포나 A/B 테스트와 같은 고급 배포 전략을 통해 위험을 줄일 수 있습니다.
• CT (Continuous Training): 배포된 모델의 성능이 저하되거나 새로운 데이터가 유입될 때 자동으로 모델을 재학습하고 업데이트합니다.

GitHub Actions, GitLab CI/CD, Argo Workflows와 같은 도구들을 활용하여 이 과정을 자동화할 수 있습니다.

# .github/workflows/mlops_pipeline.yml (GitHub Actions 예시)
name: MLOps CI/CD Pipeline for LLM

on:
  push:
    branches:
      - main # main 브랜치에 푸시될 때마다 실행

jobs:
  build-and-deploy:
    runs-on: ubuntu-latest
    env:
      DOCKER_USERNAME: ${{ secrets.DOCKER_USERNAME }}
      DOCKER_PASSWORD: ${{ secrets.DOCKER_PASSWORD }}
      # KUBERNETES_KUBECONFIG: ${{ secrets.KUBECONFIG }} # Kubernetes 배포 시 필요

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Set up Python
      uses: actions/setup-python@v4
      with:
        python-version: '3.9'

    - name: Install dependencies
      run: |
        pip install -r requirements.txt
        # DVC 설정 (원격 스토리지 설정)
        # dvc remote add -d myremote s3://my-dvc-bucket
        # dvc pull # DVC로 관리되는 데이터 다운로드

    - name: Run tests
      run: pytest # 모델 학습 코드, 전처리 코드 등에 대한 단위 테스트

    - name: Train/Fine-tune Model (if needed, or trigger a separate workflow)
      run: |
        # 이 단계에서 모델 학습을 트리거하거나, 이미 학습된 모델을 가져옵니다.
        # python preprocess_and_train.py
        echo "Model training/fine-tuning would happen here or be triggered externally."
        # MLflow에 로그된 모델 아티팩트를 다운로드하는 로직 추가
        # mlflow artifacts download --run-id <RUN_ID> --artifact-path fine_tuned_llm -d fine_tuned_llm/

    - name: Docker Login
      uses: docker/login-action@v2
      with:
        username: ${{ env.DOCKER_USERNAME }}
        password: ${{ env.DOCKER_PASSWORD }}

    - name: Build Docker image
      run: |
        docker build -t my-llm-app:$(git rev-parse --short HEAD) .
        docker tag my-llm-app:$(git rev-parse --short HEAD) my-docker-repo/my-llm-app:latest

    - name: Push Docker image
      run: |
        docker push my-docker-repo/my-llm-app:$(git rev-parse --short HEAD)
        docker push my-docker-repo/my-llm-app:latest

    - name: Deploy to Kubernetes (using Kustomize or Helm)
      # 실제 배포는 클라우드 환경에 따라 다릅니다.
      # 예를 들어, kubectl을 사용하여 Kubernetes 클러스터에 배포
      run: |
        # echo "${{ env.KUBERNETES_KUBECONFIG }}" > $HOME/.kube/config
        # kubectl apply -f kubernetes/deployment.yaml
        echo "Deployment to Kubernetes or other platforms would be configured here."
        echo "Example: Update Kubernetes deployment image"
        # kubectl set image deployment/my-llm-app my-llm-app=my-docker-repo/my-llm-app:$(git rev-parse --short HEAD)

모델 모니터링 및 재학습

배포된 AI 모델은 시간이 지남에 따라 성능이 저하될 수 있습니다. 이를 감지하고 대응하는 것이 MLOps의 중요한 부분입니다.

성능 및 품질 모니터링

• 시스템 성능: API 응답 시간, 처리량, 자원 사용량(CPU, GPU, 메모리) 등을 모니터링하여 서비스의 안정성을 보장합니다. Prometheus, Grafana와 같은 도구가 널리 사용됩니다.
• 모델 성능: 모델의 예측 정확도, F1-score, BLEU/ROUGE 스코어(LLM의 경우) 등 비즈니스 지표를 지속적으로 추적합니다.
• 데이터 및 개념 드리프트:
  • 데이터 드리프트(Data Drift): 학습 데이터 분포와 서비스 데이터 분포 간의 차이를 의미합니다. 새로운 유형의 입력이 들어오거나, 사용자 행동이 변했을 때 발생할 수 있습니다.
  • 개념 드리프트(Concept Drift): 입력 데이터와 타겟 변수 간의 관계가 변하는 것을 의미합니다. 예를 들어, 스팸의 정의가 변하거나, 고객 선호도가 변하는 경우입니다.

자동 재학습 (CT)

드리프트가 감지되거나, 모델 성능이 임계치 이하로 떨어지면 자동으로 모델 재학습 파이프라인을 트리거합니다. 이 과정은 새로운 데이터를 수집하고, 전처리하고, 모델을 다시 학습한 후, 검증을 거쳐 새로운 버전으로 배포하는 전체 MLOps 파이프라인을 다시 실행하는 것을 의미합니다.

마무리

AI 모델, 특히 LLM과 같은 복잡하고 자원 집약적인 모델의 성공적인 서비스 운영을 위해서는 견고한 MLOps 파이프라인 구축이 필수적입니다. 데이터 관리부터 모델 학습, 배포, 그리고 지속적인 모니터링 및 재학습에 이르는 모든 과정을 자동화하고 효율적으로 관리함으로써, 개발자는 모델 개발에 더 집중하고 운영팀은 안정적인 서비스를 제공할 수 있습니다.

오늘날 빠르게 변화하는 AI 환경에서 MLOps는 단순히 모델을 배포하는 것을 넘어, 모델의 생명주기 전체를 관리하며 지속적인 가치를 창출하는 핵심적인 전략이 되고 있습니다. 이 글에서 제시된 MLOps 파이프라인 구축 전략과 코드 예시가 여러분의 AI 모델 배포 여정에 도움이 되기를 바랍니다.