데모는 되는데 운영은 안 된다: 프로덕션 LLM(에이전트 포함) 운영의 진짜 병목들

Bro's Insights
1

POC에서 “그럴듯한 데모”는 빨리 만들 수 있지만, 프로덕션에서 SLO를 지키며 운영하는 순간부터 전혀 다른 게임이 시작됩니다. 이 글에서는 여러 LLMOps 사례 분석과 vLLM/llm-d, Kubernetes 운영 가이드를 바탕으로 데모→운영 전환에서 반복적으로 터지는 병목과 특히 K8s+GPU 서빙에서의 설계 충돌(철학 문제) 까지 정리해봅니다.

1) “데모→운영” 전환에서 반복되는 4대 병목

여러 사례 연구(457개, 1,200건 배포 분석)가 공통적으로 말하는 핵심은 의외로 단순합니다. 모델 선택이나 프롬프트 감각보다, 운영에서 아래 항목들이 계속 발목을 잡습니다.

  1. Evals/Guardrails의 부재
    • 어떤 변경(프롬프트, RAG, 모델, 파라미터)이 품질/안전성을 깨는지 자동으로 검출하지 못하면, 배포 속도는 곧 리스크가 됩니다.
  2. 라우팅/캐싱/컨텍스트 엔지니어링의 미성숙
    • KV cache, prefix cache, chunked prefill 같은 “서빙 레이어 최적화”는 지연/비용을 곧장 좌우합니다.
  3. 오토스케일과 콜드스타트(모델 로딩)의 현실
    • GPU 서빙은 HPA처럼 단순히 복제본 늘린다고 해결되지 않고, “가중치 로딩/캐싱 전략”이 운영 품질을 결정합니다.
  4. 보안/관측(감사 가능성 포함)의 빈 구멍
    • 특히 금융/에어갭 환경에서는 성능보다 “공급망 통제·승인·감사”가 먼저 설계를 규정합니다.

저는 이 4가지가 결국 하나의 질문으로 수렴한다고 봅니다.
“우리는 LLM을 ‘서비스’로 운영하고 있는가, 아니면 ‘데모’를 배포하고 있는가?” 입니다.

2) 에이전트는 왜 ‘만들기 쉽고 배포는 어렵다’고 하는가

에이전트(Agent)는 짧은 시간에 성과가 나와서 플랫폼 구축의 유혹이 큽니다. 하지만 운영 난도가 급증하는 이유는 구조적으로 명확합니다.

  • 상태(state)와 루프(loop): 무한 루프, 재시도 폭주, 타임아웃 누락이 곧 장애가 됩니다.
  • 도구 인증/권한: “LLM이 호출할 수 있는 API”가 늘어날수록 IAM/감사가 복잡해집니다.
  • 메모리/컨텍스트 누수: 대화/작업 컨텍스트가 누적되며 비용과 지연이 선형이 아니라 계단식으로 튑니다.
  • 평가의 난이도: 정답이 단일하지 않은 작업에서 회귀(regression)를 잡기가 매우 어렵습니다.
  • 조기 아키텍처 결정의 부채: 초기에 정한 메모리/툴링/오케스트레이션 구조가 곧 “변경 불가능한 플랫폼”이 되는 순간이 옵니다.

결국 에이전트 플랫폼 RFP에서 “필수 요구 사항”으로 나오는 항목들(평가/가드레일/관측/보안/툴링 표준화)은, 실제로는 에이전트를 운영 가능한 소프트웨어로 만들기 위한 최소 조건입니다.

3) vLLM/llm-d가 말하는 운영의 핵심: “prefill vs decode”와 “KV cache”

프로덕션 추론에서 비용과 지연을 갈라놓는 건, 모델 자체보다도 서빙 런타임이 prefill/decode를 어떻게 다루는가입니다.

  • prefill: 긴 입력 컨텍스트를 한 번에 처리(초기 계산). TTFT(Time To First Token)에 큰 영향.
  • decode: 토큰을 한 개씩 생성(반복). 총 처리량(throughput)에 큰 영향.
  • KV cache: decode 단계에서 과거 토큰의 key/value를 저장해 재계산을 줄이는 핵심 메커니즘.

llm-d는 vLLM을 기반으로 하면서, Kubernetes에서 분산 추론을 할 때 prefill/decode 분리, KV cache 인지 라우팅/스케줄링 같은 방식으로 TTFT와 처리량을 개선하는 방향을 강조합니다. 요지는 다음과 같습니다.

  • “아무 Pod로 라우팅”하면 캐시를 못 써서 비용/지연이 상승합니다.
  • “캐시를 가진 곳으로 라우팅”해야 멀티테넌시에서 효율이 나옵니다.
  • 분산 구조를 쓸수록 “라우팅/스케줄링”이 곧 성능 기능이 됩니다.

4) Kubernetes + GPU 서빙에서 마주치는 ‘철학 문제’: 추상화 순도 vs 하드웨어 특수성

대화에서 가장 인상 깊었던 지점은 이 부분이었습니다.

K8s 스케줄러는 근본적으로 “노드 단위” 추상화를 하는데, GPU 워크로드는 NVLink/NVSwitch 토폴로지 같은 하드웨어 구조를 알아야 제대로 배치가 된다.
기술적 한계라기보다 “설계 철학의 충돌”에 가깝다.

저도 이 관점에 공감합니다. Kubernetes는 범용 오케스트레이터로서 “일반화된 리소스 모델” 을 유지하려고 합니다. 반면 GPU 워크로드(특히 멀티 GPU, 고대역폭 통신)는 다음을 요구합니다.

  • GPU 간 연결 토폴로지(NVLink/NVSwitch) 에 따라 성능이 크게 달라짐
  • NUMA/PCIe 경로, 대역폭 계층이 워크로드 성능을 좌우함
  • “같은 GPU 8장”이어도 “어떻게 묶였는지”가 다른 세계가 됨

즉 K8s의 추상화가 제공하는 단순함(노드/리소스 요청)과, GPU가 요구하는 현실(토폴로지 인지)이 어긋납니다.

그럼 결론은 “K8s는 GPU에 부적합”인가요?

저는 그렇게 단정하진 않습니다. 대신 운영에서는 다음 질문으로 바뀐다고 봅니다.

  • 추상화를 어디까지 ‘깨는 것’을 허용할 것인가?
    • node label/affinity, device plugin, topology manager, 커스텀 스케줄러 같은 방식으로 현실을 주입할 것인가
  • 아니면,
    • GPU 워크로드를 K8s 밖(별도 매니저/전용 클러스터)으로 분리하고, 대신 보안/관측/배포 통합 비용을 감수할 것인가

이 선택은 “기술 우열”보다 조직의 운영 일관성(감사/보안/배포 단일화)을 얼마나 중시하는지에 더 좌우됩니다.

5) 에어갭 + 금융 보안에서 K8s/GPU 운영이 달라지는 지점

사용자 상황처럼 airgapped + 금융사라면, GPU 서빙은 성능 문제가 아니라 “통제와 감사” 문제로 재정의됩니다.

  • 외부 Managed/API 기반 선택지가 제한됨 → 자체 서빙(K8s+GPU)이 사실상 필수
  • 최신 스택(vLLM/llm-d, GPU Operator, NCCL 등)을 빠르게 따라갈수록
    • 성능은 좋아지지만
    • 폐쇄망 반입/검증/승인/재현(SBOM, 이미지 서명, 오프라인 레지스트리, 취약점 스캔) 비용이 폭증
  • 반대로 “검증된 고정 버전 + 느린 업그레이드”는
    • 보안감사는 쉬워지지만
    • 모델 최적화/멀티테넌시 효율에서 손해

또 한 가지 현실적인 포인트는, 조직 구조상 드라이버/커널(root 권한 영역)은 인프라 본부, 서빙 런타임(vLLM 등)은 서비스 팀이 맡는 분업입니다. 이때 자주 생기는 병목은 기술이 아니라:

  • 성능/장애 원인은 런타임에서 보이는데,
  • 해결은 드라이버/CUDA/NCCL/MIG/커널 파라미터 변경이 필요해
  • 변경 리드타임이 곧 MTTR/SLO가 되는 상황입니다.

그래서 저는 RFP/표준화에서 기능 리스트만큼 중요한 것이 공동 디버깅 프로토콜이라고 생각합니다.
“어떤 지표/재현 스크립트/AB 테스트 결과가 나오면 인프라 변경 티켓이 정당화되는가”를 미리 합의해두면, 운영이 훨씬 덜 고통스럽습니다.

6) K8s에서 ‘모델 로딩/캐싱’은 오토스케일의 전제 조건입니다

GPU 오토스케일을 꿈꾸기 전에, 먼저 가중치 로딩과 캐싱 전략이 정리되어야 합니다. 대용량 모델일수록 이건 곧 콜드스타트 시간, 네트워크 병목, 스토리지 비용, 롤백 전략까지 결정합니다.

운영에서 자주 맞닥뜨리는 트레이드오프는 대략 이런 형태입니다.

  • 빠른 스케일아웃을 원하면 → 미리 캐시/프리로드가 필요(스토리지 중복/비용 증가)
  • 스토리지를 아끼면 → 콜드스타트 증가(스파이크 트래픽에서 SLO 위반)
  • 업데이트/롤백을 안전하게 하려면 → 버전 관리/아티팩트 관리가 필요(프로세스 복잡도 증가)

즉 “오토스케일”은 버튼이 아니라, 모델 아티팩트 유통 체계의 결과에 가깝습니다.

7) 제가 정리한 ‘프로덕션 LLM 운영 핵심’ 체크리스트(요약)

여러 소스와 대화를 묶어서, 실제로는 아래 순서로 표준화가 진행돼야 덜 흔들린다고 봅니다.

  1. 승인/배포 단위 정의(에어갭/금융이면 최우선)
    • 컨테이너 이미지, Helm chart, 모델 가중치, 드라이버/CUDA/NCCL 중 무엇이 가장 엄격한가
  2. Evals/Guardrails를 CI처럼 만들기
    • “배포 전 자동으로 막는 장치”가 없으면 운영은 결국 수동 QA가 됩니다.
  3. 서빙 런타임 최적화(vLLM/llm-d)
    • KV cache, prefix cache, chunked prefill, prefill/decode 분리 등
  4. 모델 로딩/캐싱 전략 확정
    • 콜드스타트와 롤백까지 포함한 아키텍처
  5. K8s 추상화와 GPU 현실의 접점을 어디까지 허용할지 결정
    • 토폴로지 인지/파티셔닝/분리 운영 중 무엇이 우리 조직의 “운영 일관성”과 맞는가
  6. 공동 디버깅 프로토콜과 책임 경계(SLO) 문서화
    • 런타임 팀 vs 인프라 팀의 인터페이스를 “계약서처럼” 박아두기

마무리

프로덕션 LLM 운영에서 반복되는 메시지는 한 가지입니다. 모델을 잘 쓰는 법보다, 모델을 ‘운영 가능한 시스템’으로 만드는 법이 더 어렵습니다. 특히 K8s+GPU 세계에서는 성능 최적화 이전에, 추상화 철학과 하드웨어 현실의 충돌을 어떤 방식으로 “조직적으로 수용”할지부터 결정을 내려야 합니다.

참고 자료

1 Like