ML 서빙 패러다임의 극적인 전환: 전통적 프레임워크에서 LLM 특화 엔진으로

게시 2026/01/25

By BLUEBUG

87 분읽는 시간

내 포트폴리오를 보면 상당수가 MLOps 관련 내용이다.
예전 포폴을 다시 열어보면 torch lightning, torchserve, TF Serving, ray serve, fastapi…
API 호출을 위한 서빙 프레임워크 구성 이야기가 빼곡하다.
그런데 대규모 LLM + 멀티모달 시대가 오고 나서는 상황이 완전히 바뀌었다.
이제는 llama.cpp, Ollama, vLLM 같은 백엔드 엔진 그 자체가 API 서버가 되는 시대다.
불과 2년도 안 된 것 같은데 말이다.
예전에 서빙 프레임워크를 어떻게 붙였는지 설명하는 게 이제는 조금 부끄러워질 정도로 패러다임이 바뀌어버렸다.
세월이 무상하다.
(ollama 쓰다가 한계 느끼고 vLLM으로 갈아탄 1인 😇)
https://www.threads.com/@hwoo_james/post/DT4p3VhE2-x

들어가며: 불과 2년 만에 일어난 혁명
전통적 ML 서빙 프레임워크 시대 (2020-2023)
LLM 시대의 도래와 패러다임 전환
현대적 LLM 서빙 엔진: 새로운 지배자들
성능 비교: 숫자로 보는 패러다임 전환
실무자를 위한 선택 가이드
미래 전망과 결론

들어가며: 불과 2년 만에 일어난 혁명

2023년 초까지만 해도 머신러닝 모델을 프로덕션에 배포하려면 복잡한 인프라 구축 과정이 필요했습니다. TorchServe, TensorFlow Serving, Ray Serve, BentoML, 그리고 FastAPI와 같은 프레임워크들을 조합해 API 서버를 구성하고, Docker 이미지를 빌드하고, Kubernetes 클러스터에 배포하고, CI/CD 파이프라인을 구축하는 것이 표준적인 절차였습니다. MLOps 엔지니어의 포트폴리오는 이러한 복잡한 인프라 구성 경험으로 가득했고, 각 프레임워크의 장단점을 이해하고 적재적소에 활용하는 능력이 핵심 역량으로 평가받았습니다.

그러나 2023년 후반부터 상황이 급격하게 변화하기 시작했습니다. 대규모 언어 모델(LLM)과 멀티모달 AI의 시대가 본격화되면서, llama.cpp, Ollama, vLLM과 같은 새로운 세대의 추론 엔진들이 등장했습니다. 이들의 가장 큰 특징은 백엔드 엔진 그 자체가 API 서버 역할을 한다는 점입니다. 별도의 서빙 프레임워크를 구축할 필요 없이, 단일 명령어로 모델을 로드하고 OpenAI 호환 API를 제공할 수 있게 되었습니다.

이는 단순한 도구의 변화가 아닙니다. 머신러닝 모델 서빙에 대한 근본적인 패러다임 전환입니다. 과거에는 범용 웹 프레임워크에 ML 추론 로직을 통합하는 방식이었다면, 이제는 ML 추론에 최적화된 엔진이 웹 서버 기능까지 내장하는 방식으로 완전히 뒤집힌 것입니다. 불과 2년도 안 되는 시간에 말입니다.

이 문서에서는 이러한 극적인 변화가 왜, 어떻게 일어났는지, 그리고 실무자들이 이 변화를 어떻게 이해하고 대응해야 하는지를 상세히 분석합니다.

전통적 ML 서빙 프레임워크 시대 (2020-2023)

전통적 접근 방식의 핵심 개념

2023년 이전의 ML 서빙 생태계는 크게 두 가지 접근 방식으로 나뉘었습니다.

첫 번째 접근: 범용 웹 프레임워크 활용 가장 직관적인 방법은 Flask나 FastAPI 같은 범용 Python 웹 프레임워크에 모델 추론 로직을 엔드포인트로 추가하는 것이었습니다. 개발자들은 이미 익숙한 웹 개발 패러다임을 그대로 활용하면서, /predict 엔드포인트에서 모델을 로드하고 추론을 실행하는 코드를 작성했습니다. 이 방식의 장점은 명확했습니다. 기존 마이크로서비스 아키텍처와 완벽하게 통합되고, 라우팅, 인증, 로깅 등 웹 서비스에 필요한 모든 기능을 바로 사용할 수 있었습니다.

두 번째 접근: 전문 ML 서빙 프레임워크 보다 정교한 접근은 ML 모델 서빙에 특화된 전용 프레임워크를 사용하는 것이었습니다. TensorFlow Serving, TorchServe, NVIDIA Triton Inference Server 같은 도구들은 모델 버전 관리, A/B 테스트, GPU 최적화, 배치 처리 등 프로덕션 ML에 필요한 고급 기능들을 제공했습니다. 이들은 특정 ML 프레임워크(TensorFlow, PyTorch 등)에 최적화되어 있거나, 멀티 프레임워크를 지원하면서도 성능과 안정성에 중점을 두었습니다.

주요 프레임워크들의 특징과 철학

TensorFlow Serving: 구글의 프로덕션 솔루션 Google이 개발한 TensorFlow Serving은 대규모 프로덕션 환경을 위한 고성능 서빙 시스템으로 설계되었습니다. C++로 작성된 백엔드는 기계어로 컴파일되어 최적의 성능을 제공했고, gRPC와 REST API 모두를 지원했습니다. 모델 버전 관리가 내장되어 있어 새 버전의 모델을 무중단으로 배포할 수 있었고, 자동 배치 처리를 통해 처리량을 극대화했습니다. Google의 검색, 광고, 추천 시스템 등 실제 대규모 서비스에서 검증된 솔루션이었지만, TensorFlow 생태계에 강하게 결합되어 있다는 제약이 있었습니다.

TorchServe: PyTorch 공식 서빙 도구 AWS와 Meta가 공동 개발한 TorchServe는 PyTorch 모델을 위한 공식 서빙 프레임워크입니다. 명령줄 인터페이스를 통한 간편한 배포, 다중 모델 동시 호스팅, 자동 배치 처리, 그리고 커스텀 핸들러를 통한 전처리/후처리 로직 구현이 가능했습니다. PyTorch가 연구 커뮤니티에서 빠르게 성장하면서 TorchServe의 인기도 함께 상승했지만, 상대적으로 새로운 프로젝트이기 때문에 빈번한 업데이트와 변경이 있었고, 일부 엔터프라이즈 기능은 TensorFlow Serving에 비해 부족했습니다.

Ray Serve: 분산 컴퓨팅의 힘 Ray 프레임워크를 기반으로 구축된 Ray Serve는 확장성과 유연성에 중점을 두었습니다. 단일 CPU부터 100개 이상의 GPU 클러스터까지 동일한 코드로 확장할 수 있었고, 복잡한 멀티 모델 파이프라인 구성이 가능했습니다. 특히 FastAPI와의 통합이 뛰어나 웹 프레임워크의 편의성과 분산 서빙의 성능을 동시에 얻을 수 있었습니다. Ray Serve는 단순한 모델 예측을 넘어 전처리, 다중 모델 앙상블, 후처리를 포함한 전체 ML 파이프라인을 하나의 애플리케이션으로 구축할 수 있게 해주었습니다.

실제로 Anyscale의 블로그에 따르면, Ray Serve와 FastAPI의 결합은 “두 세계의 장점”을 모두 가져왔습니다. FastAPI는 라우팅, 엔드포인트 테스팅, 타입 체킹, 헬스체크 등 마이크로서비스에 필요한 모든 기능을 제공하고, Ray Serve는 실시간 ML 모델 서빙에 최적화된 기능들을 제공했습니다. 이는 당시 “범용 Python 웹 서버와 전문 ML 서빙 솔루션 사이의 거의 균등한 선택”이라는 시장 상황을 잘 반영했습니다.

BentoML: 프레임워크 중립적 접근 BentoML은 프레임워크에 구애받지 않는 유연성을 핵심 가치로 내세웠습니다. TensorFlow, PyTorch, Scikit-learn, XGBoost 등 다양한 ML 프레임워크를 동일한 방식으로 패키징하고 배포할 수 있었습니다. Docker 컨테이너와 Kubernetes를 네이티브로 지원했고, 복잡한 추론 파이프라인을 Python 코드로 표현할 수 있었습니다. BentoML의 철학은 모델 개발과 배포 사이의 간극을 최소화하는 것이었습니다. 데이터 과학자가 Jupyter 노트북에서 작성한 모델을 몇 줄의 코드만 추가하면 프로덕션 준비 완료된 API 서비스로 전환할 수 있었습니다.

Neptune.ai의 분석에 따르면, BentoML은 대부분의 사용 사례에 잘 맞는 훌륭한 도구였지만, 두 가지 주요 단점이 있었습니다. 첫째, Python으로 실행되기 때문에 C++로 작성된 TensorFlow Serving이나 TorchServe만큼 최적화되지 않았습니다. 둘째, 각 모델마다 Python 서비스를 재구현해야 했고, 고성능 런타임에서 모델을 통합하는 것이 복잡할 수 있었습니다.

전통적 접근 방식의 구조적 문제점

이러한 프레임워크들은 각자의 영역에서 훌륭했지만, 공통적인 구조적 문제들을 안고 있었습니다.

복잡한 설정과 학습 곡선 Klaviyo의 엔지니어링 팀이 2024년 Medium에 공유한 경험은 이를 잘 보여줍니다. 2년 전까지만 해도 Klaviyo에는 ML 모델을 프로덕션에 배포하기 위한 표준화된 플랫폼이 없었습니다. 새로운 모델을 배포할 때마다 Flask나 FastAPI 애플리케이션을 처음부터 구축해야 했고, AWS 인프라와 CI 파이프라인을 새로 설정하고, Docker 이미지를 빌드하는 전체 과정을 반복해야 했습니다. 이는 새로운 ML 기능을 Klaviyo 앱에 추가하는 데 매우 오랜 시간이 걸린다는 것을 의미했습니다.

데이터 과학 플랫폼 팀을 만들어 이 문제를 해결하기 위해 SageMaker, KServe, BentoML, TorchServe, Ray Serve를 포함한 많은 프레임워크를 평가했고, 결국 Ray Serve를 선택했습니다. 하지만 이 선택 과정 자체가 상당한 연구와 여러 PoC(Proof of Concept) 작업을 필요로 했습니다.

프레임워크 간의 불일치 Anyscale의 블로그에서 지적한 것처럼, 전통적인 ML 스택은 데이터 전처리에 Spark나 Dask를 사용하고, 학습에는 Horovod나 PyTorch를 사용하는 등 여러 라이브러리들이 사일로로 동작했습니다. 이들 간의 임피던스 미스매치(Java vs Python)나 결합력 부족으로 인해 중간 결과를 디스크에 저장해야 했고, 이는 전체 파이프라인의 효율성을 떨어뜨렸습니다.

배포 복잡도 TrueFoundry의 분석에 따르면, 모델 서빙과 배포는 단순히 모델을 로드하고 예측을 제공하는 것 이상이었습니다. 모델을 패키징하고, 추론 API를 노출하고, 성능을 유지하는 것이 핵심 과제였습니다. 특히 Kubernetes 네이티브 솔루션인 KServe나 Seldon Core는 강력했지만, Kubernetes 클러스터가 없는 팀에게는 진입 장벽이 높았습니다.

왜 이런 복잡성이 필요했는가?

당시의 ML 모델들은 대부분 특정 도메인의 문제를 해결하기 위해 맞춤 설계되었습니다. 이미지 분류, 음성 인식, 추천 시스템, 시계열 예측 등 각 태스크마다 다른 아키텍처와 전처리 로직이 필요했습니다. 따라서 유연하고 범용적인 서빙 인프라가 필요했고, 이는 필연적으로 복잡성을 수반했습니다.

또한 대부분의 모델은 상대적으로 작았습니다. 수백만에서 수억 개의 파라미터를 가진 모델들은 단일 GPU나 심지어 CPU만으로도 서빙이 가능했습니다. GPU 최적화는 중요했지만 필수는 아니었고, 많은 경우 CPU 기반 서빙으로도 충분한 지연시간을 달성할 수 있었습니다.

마지막으로, 배치 추론이 많은 비중을 차지했습니다. 실시간 추론보다는 야간에 수백만 개의 데이터를 한 번에 처리하는 배치 작업이 흔했고, 이런 워크로드에는 높은 처리량이 낮은 지연시간보다 중요했습니다.

LLM 시대의 도래와 패러다임 전환

2023년: 전환의 해

2023년은 AI 역사에서 분수령이 되는 해였습니다. OpenAI의 ChatGPT가 2022년 11월 출시된 후 폭발적인 인기를 끌었고, GPT-4가 2023년 3월 공개되면서 대규모 언어 모델의 능력이 대중에게 명확하게 입증되었습니다. Meta는 Llama 모델 시리즈를 오픈소스로 공개하면서 오픈 웨이트 LLM 혁명을 촉발했습니다. Google은 Gemini를 발표했고, Anthropic의 Claude도 주목받기 시작했습니다.

Sebastian Raschka의 2025년 분석에 따르면, 2023년에는 LoRA와 같은 파라미터 효율적 미세 조정 기법에 많은 초점이 맞춰졌습니다. 작은 커스텀 LLM을 학습하는 것이 주요 관심사였습니다. 그러나 2024년에 들어서면서 모든 주요 연구소들이 사전 학습 파이프라인을 더욱 정교하게 만들기 시작했습니다. 합성 데이터, 데이터 믹스 최적화, 도메인별 데이터 활용, 전용 장문맥 학습 단계 등이 도입되었습니다.

Simon Willison의 연례 리뷰는 2024년을 “Llama의 해”로 정의합니다. Meta의 Llama 모델들이 가장 인기 있는 오픈 웨이트 모델이었고, 특히 Llama 3 시리즈, 특히 3.1과 3.2 릴리스는 오픈 웨이트 능력에서 큰 도약을 이루었습니다. 2024년 9월 OpenAI가 o1과 o1-mini로 “추론” 혁명을 시작했고, 이는 추론 시간 스케일링(inference-time scaling)이라는 새로운 패러다임을 열었습니다.

무엇이 근본적으로 달라졌는가?

모델 크기의 폭발적 증가 전통적인 ML 모델이 수백만에서 수억 개의 파라미터를 가졌다면, LLM은 수십억에서 수천억 개의 파라미터를 가집니다. GPT-3는 1,750억 개, GPT-4는 그보다 훨씬 더 많은 파라미터를 가진 것으로 추정됩니다. Llama 3.1은 405억 개의 파라미터 버전까지 공개되었습니다. 이는 단순한 양적 차이가 아니라, 서빙 인프라에 대한 근본적으로 다른 요구사항을 의미했습니다.

이런 거대 모델을 메모리에 로드하려면 여러 개의 고사양 GPU가 필요합니다. 단일 NVIDIA A100 GPU(80GB 메모리)로도 부족한 경우가 많아, 텐서 병렬화(tensor parallelism)를 통해 모델을 여러 GPU에 분산시켜야 합니다. 이는 전통적인 서빙 프레임워크들이 상정한 것과는 완전히 다른 스케일입니다.

추론 패턴의 변화 LLM의 추론은 자기회귀적(autoregressive)입니다. 한 번에 하나의 토큰을 생성하고, 그 토큰을 다시 입력으로 사용해 다음 토큰을 생성하는 과정을 반복합니다. 이는 기존의 “입력을 받아 단일 출력을 반환”하는 패턴과는 근본적으로 다릅니다.

더욱이, Transformer 아키텍처의 self-attention 메커니즘은 과거의 모든 토큰에 대한 정보(Key-Value cache, KV cache)를 메모리에 유지해야 합니다. 이 KV cache는 시퀀스 길이가 길어질수록 메모리를 급격히 소모하며, 이는 “memory-bound” 워크로드를 만듭니다. 즉, 계산 능력보다 메모리 대역폭이 병목이 되는 경우가 많습니다.

arXiv에 발표된 “LLM Inference Serving: Survey of Recent Advances and Opportunities” 논문은 2023년 이후 LLM 서빙 시스템의 발전을 체계적으로 정리했습니다. 2023년 1월부터 2024년 6월까지 발표된 연구들을 분석한 결과, 거의 모든 혁신이 메모리 관리, 배치 처리, KV cache 최적화에 집중되어 있었습니다.

동시 사용자 처리의 중요성 ChatGPT와 같은 서비스는 수백만 명의 사용자가 동시에 접속합니다. 각 사용자의 대화는 서로 다른 길이의 프롬프트와 응답을 가지며, 이들을 효율적으로 배치(batch)하여 처리하는 것이 핵심입니다. 전통적인 배치 처리는 모든 요청이 동일한 길이를 가진다고 가정했지만, LLM에서는 각 요청의 길이가 크게 다르고 동적으로 변합니다.

vLLM이 도입한 PagedAttention 기법은 운영체제의 가상 메모리 페이징 개념을 KV cache 관리에 적용했습니다. 이를 통해 메모리 단편화를 거의 제로에 가깝게 줄이고, 동일한 하드웨어에서 더 많은 동시 요청을 처리할 수 있게 되었습니다. SOSP 2023에 발표된 vLLM 논문에 따르면, 이 기법은 기존 시스템 대비 처리량을 최대 24배까지 향상시켰습니다.

추론 비용의 중요성 증대 Foundation Capital의 2024년 분석에 따르면, “2024년은 추론의 해”가 될 것이라 예측했습니다. 사전 학습된 모델의 성능이 전문가 수준에 근접하면서, 학습 시대는 끝나고 개발자들이 모델을 실제 애플리케이션에 적용하는 추론 시대가 도래했다는 것입니다.

추론 비용은 학습 비용과는 다른 특성을 가집니다. 학습은 일회성이거나 주기적이지만, 추론은 서비스가 운영되는 한 지속적으로 발생합니다. 사용자가 늘어날수록 추론 비용은 선형적으로 증가합니다. 시장 분석에 따르면 추론 칩 시장은 2027년까지 약 1,000억 달러 규모로 성장할 것으로 예측되며, 추론 비용이 학습 비용을 초과할 것으로 예상됩니다.

IntuitionLabs의 엔터프라이즈 가이드는 NVIDIA 단일 A100 GPU의 비용이 하드웨어 구매 시 1만~1만 5천 달러, 클라우드 월 렌탈 비용은 2천~3천 달러라고 보고합니다. 이런 높은 비용 때문에 추론 효율성은 단순한 성능 지표를 넘어 비즈니스의 생존과 직결된 문제가 되었습니다.

왜 전통적 프레임워크로는 부족한가?

전통적 ML 서빙 프레임워크들은 LLM의 이런 새로운 요구사항을 충족하기 어려웠습니다.

메모리 관리의 한계 FastAPI나 Flask 같은 범용 웹 프레임워크는 KV cache 관리 같은 LLM 특화 최적화가 전혀 없습니다. 각 요청마다 새로운 메모리를 할당하고 해제하는 방식은 메모리 단편화를 유발하고, GPU 메모리 활용률을 크게 떨어뜨립니다.

TorchServe나 TensorFlow Serving도 마찬가지입니다. 이들은 고정된 크기의 입력과 출력을 가정하고 설계되었습니다. 자기회귀적 생성 과정에서 동적으로 변하는 KV cache를 효율적으로 관리하는 기능이 없었습니다.

배치 처리의 비효율성 전통적인 배치 처리는 “static batching”입니다. 배치 크기를 미리 정하고, 그만큼의 요청이 모일 때까지 기다린 후 한 번에 처리합니다. 모든 요청이 완료될 때까지 다음 배치를 시작할 수 없습니다.

LLM에서는 각 요청의 생성 길이가 크게 다릅니다. 어떤 요청은 10개의 토큰만 생성하고 끝나지만, 다른 요청은 1,000개의 토큰을 생성할 수 있습니다. Static batching에서는 가장 긴 요청이 끝날 때까지 전체 배치가 묶여 있어야 하므로, GPU가 유휴 상태로 낭비되는 시간이 많습니다.

vLLM과 같은 현대적 엔진들은 “continuous batching”을 구현합니다. 한 요청이 완료되면 즉시 새로운 요청을 배치에 추가하여 GPU 활용률을 최대화합니다. 이는 지연시간과 처리량 모두를 크게 개선합니다.

하드웨어 최적화의 부족 LLM 추론은 GPU에서 실행되는 매우 특화된 워크로드입니다. Attention 연산, matrix multiplication, 그리고 메모리 액세스 패턴이 모두 최적화되어야 합니다. vLLM, llama.cpp, TensorRT-LLM 같은 엔진들은 CUDA 커널 레벨에서 최적화되어 있고, Flash Attention 같은 최신 알고리즘을 구현하고 있습니다.

전통적 프레임워크들도 PyTorch나 TensorFlow를 백엔드로 사용하므로 어느 정도의 최적화는 얻을 수 있지만, LLM 특화 최적화가 없어 상대적으로 비효율적입니다.

현대적 LLM 서빙 엔진: 새로운 지배자들

llama.cpp: 이식성과 효율성의 대명사

철학과 설계 원칙 llama.cpp는 순수 C/C++로 작성되어 외부 의존성이 전혀 없는 LLM 추론 엔진입니다. 원래 Meta의 LLaMA 모델을 MacBook에서 실행하기 위해 시작된 프로젝트였지만, 이제는 강력한 서버부터 엣지 디바이스, 노트북, 심지어 스마트폰까지 거의 모든 하드웨어에서 실행 가능한 가장 이식성 높은 LLM 엔진이 되었습니다.

Red Hat Developer의 벤치마크에 따르면, llama.cpp의 가장 큰 강점은 극도의 효율성과 이식성입니다. C++ 코어 덕분에 빠른 시작 시간과 최소한의 메모리 오버헤드를 가지며, 거의 어디서나 실행할 수 있습니다.

양자화를 통한 민주화 llama.cpp의 핵심 기능 중 하나는 광범위한 양자화(quantization) 지원입니다. GGML/GGUF 포맷을 통해 16비트부터 2비트까지 다양한 정밀도로 모델을 압축할 수 있습니다. 예를 들어, 70억 파라미터 모델을 4비트로 양자화하면 약 4GB 메모리만으로 실행할 수 있습니다. 이는 소비자급 하드웨어에서도 최신 LLM을 실행할 수 있게 만들었고, LLM을 “민주화”하는 데 큰 역할을 했습니다.

CPU-GPU 하이브리드 추론 llama.cpp는 CPU와 GPU 메모리를 동시에 활용하는 하이브리드 추론을 지원합니다. GPU VRAM이 부족할 때, 모델의 일부 레이어를 GPU에 올리고 나머지는 CPU에서 실행할 수 있습니다. 이는 제한된 하드웨어에서 큰 모델을 실행할 수 있게 해주는 독특한 기능입니다.

단점과 한계 그러나 llama.cpp는 고동시성 프로덕션 환경을 위해 설계되지 않았습니다. Red Hat의 벤치마크에서 llama.cpp의 처리량은 동시성이 증가해도 거의 평평하게 유지되었습니다. 이는 순차적 처리 방식을 사용하기 때문입니다. 단일 사용자나 저동시성 태스크에는 완벽하지만, 수백 명의 사용자가 동시에 요청하는 프로덕션 API 서버로는 적합하지 않습니다.

피크 부하에서 vLLM은 llama.cpp 대비 요청 처리량(RPS)에서 35배 이상, 총 출력 토큰 처리량(TPS)에서 44배 이상의 성능을 보였습니다. 이는 llama.cpp의 아키텍처가 단일 사용자나 저동시성 태스크에 적합하다는 것을 명확히 보여줍니다.

사용 사례 llama.cpp는 다음과 같은 상황에서 최적의 선택입니다:

로컬 개발 환경에서 모델 테스트
CPU만으로 LLM 실행이 필요한 경우
GPU VRAM이 제한된 환경에서 큰 모델 실행 (CPU 오프로드 활용)
엣지 디바이스나 임베디드 시스템에 배포
오프라인 배치 처리나 단일 사용자 애플리케이션

Ollama: 사용자 친화성의 정점

핵심 가치: 단순함 Ollama는 llama.cpp를 래핑한 사용자 친화적 도구입니다. “엔진이 llama.cpp라면, Ollama는 그 주위에 아름답게 디자인된 자동차”라는 비유가 적절합니다. 단일 명령어로 모델을 다운로드하고 실행할 수 있으며, 마법처럼 쉽습니다.

  
# 모델 다운로드 및 실행
ollama run llama3

# 즉시 대화 시작
>>> 안녕하세요!

이런 단순함은 개발자들이 다양한 모델을 빠르게 실험하거나, 연구자들이 새로운 아이디어를 테스트하거나, 누구나 LLM을 경험해보고 싶을 때 완벽합니다.

동적 모델 전환 Ollama의 또 다른 강점은 모델 간 전환이 매우 쉽다는 것입니다. vLLM에서는 서버를 재시작해야 하지만, Ollama에서는 즉석에서 다른 모델로 전환할 수 있습니다. 이는 여러 모델의 성능을 비교하거나 특정 태스크에 가장 적합한 모델을 찾는 과정에서 매우 유용합니다.

프로덕션 사용 가능성 Ollama는 단순히 “장난감”이 아닙니다. 내부 도구, 제한된 사용자 수의 애플리케이션, 비동기 작업(콘텐츠 모더레이션, 코드 문서화 생성 등)에서는 완벽하게 사용 가능합니다. 핵심은 Ollama가 고동시성 실시간 애플리케이션을 위해 설계되지 않았다는 점을 이해하는 것입니다. 하지만 많은 비즈니스에서는 그런 수준의 성능이 필요하지 않습니다. 간단하고 신뢰할 수 있는 방식으로 LLM을 내부 워크플로우에 통합하는 것이 목표라면 Ollama는 환상적인 선택입니다.

성능 특성 Red Hat의 벤치마크에서 Ollama의 기본 설정은 최대 4개의 병렬 요청만 처리하도록 되어 있습니다. 이는 단일 사용자 시나리오를 주로 상정했기 때문입니다. 처리량은 동시성이 증가해도 평평하게 유지되어, 최대 용량에 빠르게 도달합니다.

그러나 Robert McDermott의 Medium 글에 따르면, 병렬 처리 설정을 조정하면 상황이 개선됩니다. OLLAMA_NUM_PARALLEL=32 같은 환경 변수를 설정하여 더 많은 동시 요청을 처리할 수 있지만, 그럼에도 불구하고 vLLM과 비교하면 처리량과 지연시간에서 큰 차이가 있습니다.

동시성 128에서 vLLM은 Ollama 대비 3.23배 빠른 성능을 보였습니다. vLLM의 피크 성능은 793 TPS였지만, Ollama는 41 TPS에 그쳤습니다. P99 지연시간도 vLLM은 80ms, Ollama는 673ms로 큰 차이를 보였습니다.

사용 사례 Ollama는 다음과 같은 상황에서 최고의 선택입니다:

빠른 프로토타이핑과 개발
로컬 환경에서 여러 모델 테스트
개인 프로젝트나 교육 목적
제한된 사용자 수의 내부 도구
비동기 백그라운드 태스크 (배치 처리, 콘텐츠 생성 등)

vLLM: 프로덕션의 왕

Berkeley의 야심작 vLLM은 UC Berkeley에서 시작된 프로젝트로, LLM 추론 서빙을 위한 “빠르고 사용하기 쉬운 라이브러리”를 표방합니다. 현재는 PyTorch 생태계의 일부가 되었고, UC Berkeley, Stanford, Meta, NVIDIA 등 주요 기관들이 후원하고 있습니다.

PagedAttention: 게임 체인저 vLLM의 핵심 혁신은 PagedAttention입니다. 운영체제의 가상 메모리 페이징 개념을 KV cache 관리에 적용한 이 기법은 메모리 단편화를 거의 제로로 줄이고, 동일한 하드웨어에서 훨씬 더 많은 요청을 처리할 수 있게 합니다. SOSP 2023 논문에서 vLLM은 기존 시스템 대비 최대 24배의 처리량 향상을 달성했다고 보고했습니다.

Continuous Batching과 텐서 병렬화 vLLM은 continuous batching(동적 배치 처리)을 구현하여 GPU 활용률을 극대화합니다. 한 요청이 완료되는 즉시 새로운 요청을 배치에 추가하여, GPU가 놀지 않고 계속 일하도록 합니다.

또한 텐서 병렬화를 네이티브로 지원하여 매우 큰 모델을 여러 GPU에 분산시킬 수 있습니다. 이는 단일 GPU 메모리에 맞지 않는 모델을 서빙하는 데 필수적입니다.

OpenAI 호환 API vLLM은 OpenAI API와 호환되는 엔드포인트를 제공합니다. 이는 OpenAI의 유료 서비스를 사용하던 애플리케이션이 코드 변경 없이 vLLM으로 전환할 수 있다는 의미입니다. 단지 기본 URL만 변경하면 됩니다. 이 호환성은 벤더 종속을 줄이고, 비용을 절감하며, 데이터 프라이버시를 강화하는 데 큰 도움이 됩니다.

성능 데이터 실제 벤치마크 결과는 놀랍습니다:

처리량: 동시성 256에서 793 TPS (Ollama의 41 TPS와 비교)
지연시간: P99 지연시간 80ms (Ollama의 673ms와 비교)
확장성: 동시성이 증가함에 따라 선형적으로 성능이 향상

Red Hat의 벤치마크에서 vLLM은 llama.cpp 대비 피크 부하에서 RPS는 35배 이상, TPS는 44배 이상의 성능을 보였습니다. 이는 멀티 사용자 애플리케이션에서 vLLM이 압도적으로 우수하다는 것을 명확히 보여줍니다.

Trade-off: 지연시간 vs 처리량 vLLM은 처리량을 극대화하기 위해 큰 배치를 생성합니다. 이는 단일 요청의 토큰간 지연시간(Inter-Token Latency, ITL)을 약간 증가시킬 수 있습니다. 저동시성 환경에서는 llama.cpp가 더 낮고 안정적인 ITL을 보일 수 있습니다. 하지만 동시 사용자가 많은 프로덕션 환경에서는 vLLM의 배치 처리가 훨씬 효율적입니다.

배포와 운영 vLLM은 Python 라이브러리로 제공되지만, Docker 컨테이너나 Kubernetes에 쉽게 배포할 수 있습니다. OpenShift, Ray Serve, KServe 같은 플랫폼과의 통합도 잘 지원됩니다. 텐서 병렬화를 위한 명령어는 간단합니다:

  
vllm serve meta-llama/Llama-3.1-70B-Instruct \
    --tensor-parallel-size 4 \
    --gpu-memory-utilization 0.95

사용 사례 vLLM은 다음과 같은 상황에서 최적의 선택입니다:

높은 동시성을 가진 프로덕션 API 서비스
실시간 챗봇이나 대화형 애플리케이션
처리량과 확장성이 중요한 엔터프라이즈 배포
멀티 GPU 환경에서 큰 모델 서빙
비용 효율적인 추론 인프라 구축

그 외 주목할 만한 엔진들

SGLang: 버클리의 또 다른 걸작 SGLang(Structured Generation Language)은 버클리 팀이 개발한 또 다른 추론 엔진으로, v0.4 릴리스에서 상당한 성능 향상을 이루었습니다. SGLang의 특징은 구조화된 생성을 네이티브로 지원한다는 점입니다. JSON 스키마를 따르는 출력을 생성하거나, 특정 문법을 준수하는 텍스트를 생성하는 것이 매우 쉽습니다.

2025년 1월 Ant Open Source의 분석에 따르면, vLLM과 SGLang은 현재 LLM 추론 공간에서 잠재적 듀오폴리를 형성하고 있으며, DeepSeek도 이 두 엔진을 권장했습니다. 모델 추론 서비스 분야에서 명확한 새로운 기회(벡터화 스토리지 등)가 보이는 반면, 다른 영역에서는 생태계 재조정과 재정렬이 일어나고 있습니다.

TensorRT-LLM: NVIDIA의 극한 최적화 NVIDIA의 TensorRT-LLM은 NVIDIA GPU에서 최고의 성능을 제공하는 것을 목표로 합니다. CUDA 커널 레벨의 최적화, FP8 정밀도 지원, 그리고 NVIDIA의 최신 하드웨어 기능을 모두 활용합니다. 지연시간이 매우 중요한 고객 대면 애플리케이션에서는 TensorRT-LLM이 최선의 선택일 수 있습니다.

ITECS의 2025년 가이드에 따르면, TensorRT-LLM 최적화는 전문가의 노력이 수주 소요될 수 있지만, 그 결과는 놀랍습니다. 밀리초 단위의 차이가 사용자 경험에 영향을 미치는 애플리케이션에서는 이 투자가 정당화됩니다.

Text Generation Inference (TGI): Hugging Face의 선택 Hugging Face가 개발한 TGI는 Rust와 Python으로 작성된 프로덕션 준비 추론 서버입니다. Hugging Face 생태계와의 긴밀한 통합이 강점이며, 모델 허브에서 직접 모델을 로드할 수 있습니다. vLLM과 유사한 수준의 성능을 제공하면서도 Hugging Face 워크플로우에 더 잘 맞습니다.

성능 비교: 숫자로 보는 패러다임 전환

Red Hat의 종합 벤치마크 분석

Red Hat Developer 팀은 2024-2025년에 걸쳐 vLLM, Ollama, llama.cpp를 동일한 환경에서 체계적으로 벤치마킹했습니다. OpenShift 클러스터에서 동일한 모델(meta-llama/Llama-3.1-8B-Instruct)을 사용하고, GuideLLM 벤치마킹 도구로 1명부터 256명까지의 동시 사용자를 시뮬레이션했습니다.

처리량 비교 동시성 256에서:

vLLM: 793 TPS (Tokens Per Second)
Ollama (조정됨): 41 TPS
llama.cpp: 거의 평평한 처리량 유지

vLLM의 처리량은 동시성이 증가할수록 거의 선형적으로 증가했습니다. 이는 continuous batching과 PagedAttention의 효과입니다. 반면 Ollama와 llama.cpp는 동시성이 증가해도 처리량이 거의 변하지 않았습니다.

지연시간 비교 P99 지연시간 (피크 처리량 시점):

vLLM: 80ms
Ollama: 673ms

이는 8배 이상의 차이입니다. 사용자 경험 관점에서 vLLM은 거의 즉각적으로 느껴지는 반면, Ollama는 눈에 띄는 지연이 있습니다.

Time to First Token (TTFT) 낮은 동시성에서 vLLM은 거의 즉각적인 TTFT를 제공합니다. 이는 사용자가 “생각하고 있다”는 느낌을 빠르게 받을 수 있게 합니다. llama.cpp는 큐잉 모델로 인해 높은 TTFT를 보였고, 이는 오프라인 배치 처리나 단일 사용자 태스크에 더 적합함을 나타냅니다.

Robert McDermott의 실전 비교

Robert McDermott는 Medium에서 2개의 NVIDIA GPU를 사용한 실제 벤치마크를 공유했습니다. Qwen3-14B 모델을 사용하고, 동시성을 1부터 1,000까지 증가시키며 테스트했습니다.

완료된 요청 수/초 (RPS)

동시성 1: vLLM과 Ollama 비슷
동시성 128: vLLM이 3.23배 빠름
동시성 256+: vLLM의 우위가 더욱 명확

토큰/초 (TPS) 유사한 패턴을 보였으며, vLLM이 모든 동시성 수준에서 일관되게 우수한 성능을 보였습니다.

평균 지연시간 낮은 동시성에서는 차이가 크지 않지만, 동시성이 증가할수록 vLLM의 지연시간이 훨씬 더 안정적이고 낮게 유지되었습니다.

Multi-GPU 환경에서의 차이

Arsturn의 분석은 멀티 GPU 환경에서 엔진들이 얼마나 다르게 동작하는지를 보여줍니다.

vLLM과 ExLlamaV2: 진정한 병렬화 vLLM과 ExLlamaV2는 텐서 병렬화를 통해 여러 GPU를 진정으로 병렬로 사용합니다. 모델의 파라미터를 GPU들 사이에 분할하여, 각 GPU가 계산의 일부를 담당합니다. 이는 단일 GPU 메모리를 초과하는 큰 모델을 로드할 수 있게 하고, 처리 속도도 크게 향상시킵니다.

llama.cpp와 Ollama: 순차적 처리 llama.cpp와 Ollama는 여러 GPU가 있어도 이들을 효율적으로 활용하지 못합니다. GPU 레이어 분할을 지원하지만, 이는 진정한 병렬 처리가 아니라 순차적 처리입니다. 따라서 멀티 GPU 설정에서의 성능 향상이 제한적입니다.

벤치마크 부재의 의미 Ollama의 멀티 GPU 벤치마크가 거의 없는 이유는 그것이 의도된 사용 사례가 아니기 때문입니다. Ollama는 단일 GPU나 개인용 설정에 최적화되어 있습니다.

하드웨어 효율성

GPU 메모리 활용 vLLM은 --gpu-memory-utilization 0.95 같은 옵션으로 GPU 메모리의 95%까지 사용할 수 있습니다. PagedAttention 덕분에 메모리 단편화가 거의 없어 이런 높은 활용률이 안전합니다.

Ollama와 llama.cpp는 메모리 관리가 덜 정교하여, 안전 마진을 더 많이 남겨야 합니다.

에너지 효율성 추론당 비용은 처리량과 직결됩니다. vLLM이 동일한 하드웨어에서 10배 이상의 처리량을 제공한다면, 토큰당 비용은 1/10이 됩니다. 이는 대규모 배포에서 수백만 달러의 차이를 만들 수 있습니다.

시작 시간과 유연성

llama.cpp의 강점 llama.cpp는 C++ 구현 덕분에 매우 빠른 시작 시간을 가집니다. 몇 초 만에 모델을 로드하고 추론을 시작할 수 있습니다.

vLLM의 Trade-off vLLM은 Python 기반이고 복잡한 초기화 과정을 거칩니다. 큰 모델의 경우 시작에 수 분이 걸릴 수 있습니다. 하지만 일단 실행되면, 장시간 운영되는 프로덕션 서비스에서는 이 초기 비용이 상각됩니다.

비용 분석 시나리오

가상의 프로덕션 API 서비스 하루 100만 요청을 처리하는 API 서비스를 가정해봅시다:

Ollama 사용 시:

41 TPS 처리 가능
하루 86,400초 × 41 TPS = 약 354만 토큰/일
100만 요청을 처리하려면 여러 인스턴스 필요
요청당 평균 50 토큰 생성 가정 시 5천만 토큰 필요
약 14개의 GPU 인스턴스 필요
월 비용: 14 × $2,500 = $35,000

vLLM 사용 시:

793 TPS 처리 가능
하루 86,400초 × 793 TPS = 약 6,850만 토큰/일
단일 인스턴스로 충분
월 비용: $2,500

이는 월 $32,500, 연간 약 $390,000의 절감입니다. 이것이 vLLM이 프로덕션에서 선호되는 이유입니다.

실무자를 위한 선택 가이드

의사 결정 프레임워크

1단계: 사용 패턴 파악 먼저 애플리케이션의 사용 패턴을 명확히 해야 합니다:

동시 사용자 수: 1-10명? 10-100명? 100명 이상?
응답 시간 요구사항: 실시간 대화? 비동기 처리 가능?
처리량 요구사항: 초당 몇 개의 요청?
비용 민감도: 하드웨어 비용이 제약인가, 운영 복잡도가 제약인가?

2단계: 하드웨어 환경 평가 현재 또는 계획된 하드웨어를 평가합니다:

GPU 가용성: GPU가 있는가? 몇 개? 어떤 종류?
메모리: 각 GPU의 VRAM은 얼마인가?
CPU/시스템 메모리: 하이브리드 추론이 필요한가?
네트워크: 클러스터 환경인가, 단일 서버인가?

3단계: 운영 역량 고려 팀의 기술 스택과 역량도 중요합니다:

Kubernetes 경험: 컨테이너 오케스트레이션에 익숙한가?
Python vs C++: 어떤 언어에 더 편안한가?
MLOps 성숙도: 복잡한 배포 파이프라인을 관리할 수 있는가?
모니터링/로깅: 기존 관측성 스택은 무엇인가?

시나리오별 권장사항

시나리오 1: 개인 개발자 / 연구자

상황: 로컬 MacBook이나 개인 워크스테이션에서 여러 모델을 실험
권장: Ollama
이유:
- 한 줄 명령어로 모델 실행
- 모델 간 빠른 전환
- 학습 곡선이 거의 없음
- 로컬 리소스에 최적화
대안: llama.cpp (더 많은 커스터마이제이션이 필요한 경우)

시나리오 2: 스타트업 - 내부 도구

상황: 10-20명 팀의 내부 문서 검색/요약 도구
권장: Ollama
이유:
- 빠른 설치와 배포
- 제한된 사용자 수에 충분한 성능
- 유지보수 오버헤드 최소화
- 팀원들이 쉽게 이해하고 관리 가능
주의사항: 사용자가 늘어나면 vLLM 마이그레이션 계획 수립

시나리오 3: 스타트업 - 고객 대면 챗봇

상황: 수백 명의 동시 사용자, 실시간 응답 필요
권장: vLLM
이유:
- 높은 처리량과 낮은 지연시간
- 동시성 증가에 따른 선형적 확장
- OpenAI 호환 API로 쉬운 통합
- 비용 효율성
구성:
- Kubernetes에 배포
- 수평적 확장 (Horizontal Pod Autoscaler)
- Prometheus + Grafana로 모니터링

시나리오 4: 엔터프라이즈 - 배치 처리

상황: 야간에 수백만 개의 문서를 분류/요약
권장: vLLM (배치 모드)
이유:
- 최대 처리량 달성
- 대용량 배치 처리 최적화
- 비용당 처리량 최고
대안: llama.cpp (GPU가 제한적이고 CPU 클러스터가 많은 경우)

시나리오 5: 엣지/임베디드

상황: IoT 디바이스, 스마트폰, 자동차에서 오프라인 추론
권장: llama.cpp
이유:
- 극도의 이식성
- 최소 의존성
- CPU 전용 실행 가능
- 양자화를 통한 작은 메모리 풋프린트
구성:
- 4비트 양자화 모델 사용
- CPU 최적화 플래그 활성화

시나리오 6: 엔터프라이즈 - 미션 크리티컬 서비스

상황: 금융, 의료 등 밀리초 단위 지연시간이 중요한 서비스
권장: TensorRT-LLM
이유:
- 최저 지연시간
- NVIDIA GPU에서 극한의 최적화
- 안정성과 신뢰성 중시
주의사항:
- 높은 초기 설정 비용
- 전문 지식 필요
- NVIDIA GPU 종속성

하이브리드 전략

많은 조직들이 단일 솔루션이 아닌 하이브리드 접근을 취합니다:

개발 → 프로덕션 파이프라인

개발/테스트: Ollama (빠른 반복)
스테이징: vLLM (프로덕션 환경 시뮬레이션)
프로덕션: vLLM (최대 성능과 확장성)

계층화된 서비스

내부 도구: Ollama
고객 대면 실시간: vLLM
배치/비동기: vLLM 또는 llama.cpp

지역별 배포

중앙 데이터센터: vLLM 클러스터 (멀티 GPU)
엣지 위치: llama.cpp (저사양 서버)
개발자 로컬: Ollama (편의성)

OpenAI API 호환성 활용

현대적 LLM 엔진들의 OpenAI API 호환성은 전략적 유연성을 제공합니다:

벤더 중립적 개발 애플리케이션을 OpenAI API 인터페이스에 맞춰 개발하면:

OpenAI의 유료 서비스로 시작 (빠른 프로토타이핑)
성장하면서 vLLM으로 마이그레이션 (비용 절감)
필요시 다시 OpenAI로 전환 (예: 최신 GPT 모델 사용)
코드 변경 없이 백엔드만 교체

A/B 테스트와 폴백

기본: 자체 호스팅 vLLM
폴백: 트래픽 급증 시 OpenAI API
비교: 동일 프롬프트로 다른 백엔드 성능 측정

비용 최적화 전략

모델 크기 vs 성능 Trade-off

7B 모델: 단일 GPU로 충분, 대부분의 태스크에 적합
13B-70B 모델: 2-4 GPU 필요, 복잡한 추론에 필요
200B+ 모델: 8+ GPU, 특수한 경우만 정당화

양자화 활용

FP16: 기본, 최고 품질
Int8: 2배 메모리 절감, 품질 손실 미미
Int4: 4배 메모리 절감, 약간의 품질 저하
Int2: 8배 메모리 절감, 상당한 품질 저하 (특수 목적)

동적 리소스 할당

피크 시간: 더 많은 인스턴스
오프 피크: 최소 인스턴스로 축소
Kubernetes HPA (Horizontal Pod Autoscaler) 활용

마이그레이션 경로

Ollama → vLLM 마이그레이션

현재 Ollama로 프로토타입 개발
사용자 증가 모니터링
지연시간/처리량이 병목이 되는 시점 파악
vLLM으로 점진적 마이그레이션:
- 먼저 스테이징 환경에 vLLM 배포
- 트래픽 일부를 vLLM로 라우팅 (카나리 배포)
- 성능 모니터링 후 점진적 확대
OpenAI API 호환성 덕분에 애플리케이션 코드는 거의 변경 없음

전통적 프레임워크 → 현대적 엔진 기존의 TorchServe/FastAPI 스택을 사용 중이라면:

새로운 LLM 프로젝트는 vLLM으로 시작
기존 시스템은 당분간 유지 (안정성)
리소스 절감 효과를 측정
점진적으로 레거시 시스템을 현대적 엔진으로 교체
전환 중에는 두 스택을 병렬 운영

모니터링과 관측성

핵심 메트릭

처리량: TPS (Tokens Per Second), RPS (Requests Per Second)
지연시간: TTFT (Time To First Token), ITL (Inter-Token Latency), E2E (End-to-End)
리소스: GPU 메모리 사용률, GPU 활용률, CPU 사용률
품질: 응답 품질, 에러율, 타임아웃율

도구 추천

Prometheus: 메트릭 수집
Grafana: 시각화 및 대시보드
OpenTelemetry: 분산 추적
vLLM 내장 메트릭: /metrics 엔드포인트
llama.cpp: --metrics 플래그

미래 전망과 결론

기술 트렌드: 앞으로 2-3년

추론 시간 스케일링의 부상 Sebastian Raschka와 Simon Willison의 분석에 따르면, 2024년 OpenAI의 o1이 시작한 “추론” 또는 “inference-time scaling” 혁명은 2025-2026년의 주요 트렌드가 될 것입니다. 모델이 답변을 생성하는 데 더 많은 시간과 컴퓨팅을 투자하면서, 정확도를 크게 향상시키는 접근입니다.

이는 추론 엔진에 새로운 요구사항을 제시합니다:

더 긴 생성 시퀀스 처리
중간 “사고 과정” 관리
자기 반성(self-refinement) 반복 지원
복잡한 추론 트리 탐색

vLLM과 SGLang 같은 엔진들은 이미 이런 기능들을 구현하기 시작했습니다.

멀티모달의 확산 텍스트 전용 LLM에서 이미지, 오디오, 비디오를 동시에 처리하는 멀티모달 모델로의 전환이 가속화되고 있습니다. Gemini, GPT-4V, Claude 3 등이 이미 이 길을 걷고 있습니다.

추론 엔진은 다음을 지원해야 합니다:

다양한 입력 모달리티의 효율적 처리
교차 모달리티 attention 최적화
비디오 스트림의 시간적 KV cache 관리

특화된 하드웨어의 등장 IntuitionLabs의 보고서는 AI 추론 하드웨어의 패러다임 전환을 강조합니다. NVIDIA GPU의 지배에서 도메인 특화 추론 칩으로의 전환이 일어나고 있습니다:

SambaNova: Reconfigurable Dataflow Unit (RDU)로 엔드투엔드 플랫폼 제공
d-Matrix: 3D 스택 DRAM으로 메모리 병목 해결, HBM4 대비 10배 대역폭
Groq: LPU (Language Processing Unit)로 결정론적 추론 제공
Cerebras: 거대한 단일 웨이퍼 칩으로 극한의 병렬화

추론 칩 시장은 2027년까지 약 1,000억 달러 규모로 성장할 것으로 예측됩니다. 추론 비용이 학습 비용을 초과하는 시점이 곧 올 것입니다.

추론 엔진들은 이런 다양한 하드웨어를 지원해야 하는 과제를 안고 있습니다. NVIDIA에 최적화된 코드만으로는 부족하며, 하드웨어 추상화 레이어가 더욱 중요해질 것입니다.

에이전트 프레임워크와의 통합 arXiv의 “LLM Applications” 논문은 에이전트 시스템의 성장을 강조합니다. LangChain, LangGraph, CrewAI, AutoGen 같은 프레임워크들이 복잡한 멀티 에이전트 워크플로우를 가능하게 합니다.

추론 엔진은 단순히 “프롬프트 → 응답”을 넘어:

도구 호출(tool calling) 네이티브 지원
멀티턴 대화의 효율적 상태 관리
에이전트 간 통신 최적화
장기 메모리와 검색 증강 생성(RAG) 통합

오픈 소스 생태계의 성숙 Ant Open Source의 2025년 분석에 따르면, AI가 GitHub에서 가장 영향력 있는 기술 도메인이 되었습니다. 2023년에 클라우드 네이티브를 추월했고, LLM 관련 프로젝트의 60%가 2024년 이후 생성되었으며, 21%는 최근 6개월 내에 만들어졌습니다.

이는 매우 빠르게 진화하는 생태계를 의미합니다:

새로운 최적화 기법이 매주 발표됨
프로덕션 도구의 빠른 혁신
커뮤니티 기여의 폭증

vLLM과 SGLang의 잠재적 듀오폴리가 형성되고 있지만, 이 분야는 여전히 유동적입니다. 새로운 도전자들이 계속 등장할 것입니다.

생태계 재편

“올인원” 프레임워크의 정리 2023-2024년 초에는 수많은 에이전트 개발 프레임워크가 등장했습니다. 모두가 특정 기능(도구 호출, RAG 통합, 장기 메모리, ReAct 계획 등)에 집중했습니다. 2024년 후반부터 시장이 안정화되기 시작했고, 새로운 프레임워크의 등장이 줄어들었습니다.

비슷한 정리가 추론 엔진 분야에서도 일어날 것입니다. 현재의 혼란스러운 선택지들이 몇 개의 지배적 솔루션으로 수렴할 가능성이 높습니다.

클라우드 제공자들의 움직임 AWS, Google Cloud, Azure 모두 관리형 LLM 추론 서비스를 제공하기 시작했습니다. 이들은 vLLM이나 TGI 같은 오픈 소스 엔진을 기반으로 하면서, 관리 편의성을 추가합니다.

기업들은 다음 사이에서 선택해야 합니다:

자체 호스팅: 완전한 제어, 최대 비용 효율성, 높은 운영 부담
관리형 서비스: 편의성, 빠른 시작, 높은 비용
하이브리드: 중요한 워크로드는 자체 호스팅, 보조 기능은 관리형

표준화의 중요성 OpenAI API가 사실상의 표준이 되었습니다. vLLM, Ollama, TGI 모두 이를 지원합니다. 이는 생태계에 큰 이점을 제공합니다:

애플리케이션의 벤더 독립성
개발자들이 한 번만 배우면 됨
도구와 라이브러리의 재사용

앞으로 더 많은 표준화가 예상됩니다:

모델 포맷 (GGUF, SafeTensors 등의 수렴)
배포 패키징 (컨테이너, Helm 차트)
관측성 인터페이스 (메트릭, 로그 포맷)

조직적 영향

MLOps 역할의 진화 2년 전만 해도 MLOps 엔지니어의 핵심 역량은 복잡한 서빙 인프라를 구축하고 관리하는 것이었습니다. 이제는:

더 적은 인프라 코드: Ollama나 vLLM이 대부분을 처리
더 많은 최적화: 프롬프트 엔지니어링, 양자화, 배치 크기 튜닝
비즈니스 가치에 집중: 인프라보다는 사용자 경험과 비용 최적화

데이터 과학자의 권한 확대 전통적으로 데이터 과학자가 모델을 학습하면, MLOps 팀이 배포를 담당했습니다. 이제는:

데이터 과학자가 직접 Ollama로 배포 가능
프로덕션 전환이 훨씬 빨라짐
“던지기” 문화에서 “소유” 문화로

팀 구조의 변화 일부 조직들은 별도의 MLOps 팀을 유지하지 않고, 플랫폼 팀에 통합하고 있습니다. LLM 서빙이 “일반 마이크로서비스 배포”에 가까워지면서, 전통적인 DevOps 기술만으로도 충분한 경우가 많아졌습니다.

비용 구조의 변화

학습 vs 추론 비용 과거: 학습 비용이 지배적 (일회성 대규모 투자) 현재: 추론 비용이 지배적 (지속적이고 확장되는 비용)

이는 투자 우선순위를 바꿉니다:

최신 GPU는 학습보다 추론에 더 많이 필요
추론 최적화가 ROI 관점에서 더 중요
프로덕션 인프라가 연구 인프라보다 크게 성장

오픈 소스 모델의 경제학 Meta의 Llama 시리즈, Mistral, Qwen 같은 고품질 오픈 웨이트 모델들이 늘어나면서:

자체 호스팅이 경제적으로 매력적
API 비용 (OpenAI, Anthropic)과 자체 호스팅 비용의 직접 비교 가능
일정 규모 이상에서는 거의 항상 자체 호스팅이 저렴

Foundation Capital의 분석: 초기 프로토타이핑에는 API 서비스, 성장 후에는 자체 호스팅으로 전환하는 패턴이 일반적입니다.

윤리적, 규제적 고려사항

데이터 주권 유럽의 GDPR, 중국의 데이터 현지화 법규 등으로 인해, 데이터를 제3자 API 서비스로 보낼 수 없는 경우가 많습니다. 자체 호스팅이 필수가 됩니다.

llama.cpp, Ollama, vLLM 같은 오픈 소스 엔진들은 완전한 데이터 제어를 제공합니다. 이는 규제가 엄격한 산업(금융, 의료, 정부)에서 큰 장점입니다.

투명성과 감사 오픈 소스 엔진을 사용하면:

정확히 어떤 코드가 실행되는지 알 수 있음
보안 감사 수행 가능
벤더 종속 없음

결론: 패러다임 전환을 어떻게 받아들일 것인가

불과 2년 만에 ML 서빙 세계가 완전히 뒤집혔습니다. 복잡한 프레임워크를 조립하던 시대에서, 특화된 엔진이 모든 것을 처리하는 시대로 넘어왔습니다. 이는 단순한 도구의 변화가 아니라, 사고방식의 근본적 전환입니다.

핵심 인사이트

1. 한 가지 도구가 모든 것을 해결하지 않는다 Ollama, vLLM, llama.cpp는 각자의 영역에서 최고입니다. “최고의 도구”를 찾는 것이 아니라, “내 상황에 맞는 도구”를 찾는 것이 중요합니다. 많은 조직들이 여러 도구를 병행 사용하며, 이것이 실용적인 접근입니다.

2. 시작은 단순하게, 필요할 때 복잡하게 Ollama로 시작하고, 확장이 필요할 때 vLLM으로 전환하는 것이 검증된 경로입니다. 처음부터 과도하게 엔지니어링하지 마세요. OpenAI API 호환성 덕분에 전환 비용이 낮습니다.

3. 비용 최적화는 아키텍처 초기부터 추론 비용은 빠르게 증가합니다. 초기에 효율적인 엔진을 선택하는 것이 나중에 수백만 달러를 절약할 수 있습니다. 프로토타입 단계에서는 비용을 무시해도 되지만, 프로덕션으로 가기 전에 반드시 재평가하세요.

4. 커뮤니티를 활용하라 LLM 추론 생태계는 매우 활발합니다. GitHub Issues, Discord 채널, Reddit 커뮤니티에서 최신 정보와 실전 경험을 얻을 수 있습니다. 특히 vLLM과 llama.cpp는 매우 활발한 커뮤니티를 가지고 있습니다.

5. 지속적 학습이 필수 이 분야는 매주 새로운 혁신이 일어나고 있습니다. 작년의 “베스트 프랙티스”가 올해는 구식일 수 있습니다. arXiv, GitHub Trending, 그리고 주요 연구 그룹의 블로그를 주시하세요.

미래를 준비하기

앞으로 2-3년은 더욱 흥미진진할 것입니다:

추론 시간 스케일링이 표준이 될 것
멀티모달 모델이 텍스트 전용을 대체할 것
특화된 하드웨어가 NVIDIA GPU를 보완할 것
에이전트 시스템이 단순한 Q&A를 넘어설 것

이런 변화에 대비하려면:

유연성을 유지: 벤더 종속을 피하고 표준 인터페이스 사용
실험 문화: 새로운 도구와 기법을 지속적으로 테스트
측정 기반 결정: 추측이 아닌 벤치마크로 선택
커뮤니티 참여: 오픈 소스에 기여하고 피드백 제공

마지막 생각

이 글의 시작점이었던 포트폴리오 이야기로 돌아가 봅시다. 2년 전 TorchServe와 FastAPI로 복잡한 서빙 인프라를 구축한 것이 부끄러운 일일까요? 전혀 그렇지 않습니다. 그것은 당시의 최선이었고, 문제를 해결했습니다.

중요한 것은 변화를 인정하고 적응하는 것입니다. 과거의 지식이 쓸모없어진 것이 아니라, 그 위에 새로운 레이어가 추가된 것입니다. 분산 시스템, GPU 최적화, API 설계, 모니터링 등의 근본적인 원리는 여전히 유효합니다. 단지 도구가 이를 더 쉽게 만들어줄 뿐입니다.

LLM 시대의 ML 서빙은 더 민주화되고, 더 효율적이고, 더 강력해졌습니다. 이제 누구나 최신 AI를 자신의 애플리케이션에 통합할 수 있습니다. 이것이 바로 이 패러다임 전환의 진정한 가치입니다.

불과 2년 만에 세상이 바뀌었습니다. 앞으로 2년은 어떻게 바뀔까요? 그것은 우리 모두가 함께 만들어가는 미래입니다.

참고 문헌 및 리소스

주요 논문

Kwon et al. (2023). “Efficient Memory Management for Large Language Model Serving with PagedAttention.” SOSP 2023.
Li et al. (2024). “LLM Inference Serving: Survey of Recent Advances and Opportunities.” arXiv:2407.12391.
Park et al. (2025). “A Survey on Inference Engines for Large Language Models.” arXiv:2505.01658.

공식 문서

vLLM: https://docs.vllm.ai/
llama.cpp: https://github.com/ggml-org/llama.cpp
Ollama: https://ollama.com/
Ray Serve: https://docs.ray.io/en/latest/serve/

벤치마크 및 비교

Red Hat Developer: “Ollama vs. vLLM: A deep dive into performance benchmarking”
Red Hat Developer: “vLLM or llama.cpp: Choosing the right LLM inference engine”
Robert McDermott: “Performance vs Practicality: A Comparison of vLLM and Ollama”

산업 분석

Foundation Capital: “Why 2024 Will Be the Year of Inference”
IntuitionLabs: “LLM Inference Hardware: An Enterprise Guide”
Ant Open Source: “Open Source LLM Development 2025: Landscape, Trends and Insights”

기술 블로그

Anyscale Blog: Ray Serve와 FastAPI 관련 다수 글
Klaviyo Engineering: “How Klaviyo built a robust model serving platform with Ray Serve”
Neptune.ai: “Best Tools For ML Model Serving”

연례 리뷰

Sebastian Raschka: “The State Of LLMs 2025: Progress, Progress, and Predictions”
Simon Willison: “2025: The year in LLMs”

작성 일자: 2026-01-25

AI, MLOps

AI ai-governance MLOps LLM lama.cpp Ollama vLLM Claude.write