모델 파일을 실제로 돌려주는 프로그램인 서빙 엔진을 비교합니다. 세 가지 대표 엔진이 각각 어떤 상황에 맞는지 정리하고, 우리 연구회의 서버 구성이 왜 그렇게 짜여 있는지도 확인합니다.
모델 파일(GGUF)은 그 자체로는 그냥 커다란 파일에 불과합니다. 이 파일을 메모리에 올리고, 채팅창이나 API 요청을 받아 답변을 만들어 돌려주는 프로그램이 바로 서빙 엔진(serving engine)입니다. API란 프로그램끼리 정해진 형식으로 요청과 답을 주고받는 창구입니다 — 자판기에 정해진 버튼을 누르면 정해진 물건이 나오듯, 정해진 형식으로 요청하면 정해진 형식의 답이 돌아옵니다. 더 자세히는 워밍업을 참고하세요.
서빙 엔진을 고를 때 자주 듣게 될 말이 "OpenAI 호환 API"입니다. ChatGPT API와 같은 형식의 주소로 요청을 받는다는 뜻으로, n8n(코드 없이 업무 자동화 흐름을 만드는 도구) 같은 외부 도구들이 주소만 바꿔 그대로 붙을 수 있다는 의미입니다.
C++(프로그램을 만드는 데 쓰는 언어 중 하나)로 만들어진 llama.cpp는 로컬 추론 엔진의 사실상 표준이자, 앞서 배운 GGUF 포맷의 본가입니다.
가장 큰 강점은 지원 폭입니다. 최신 소비자 GPU는 물론 구형 GPU, 심지어 GPU 없이 CPU만으로도 돌릴 수 있습니다. GPU 여러 장에 모델을 나눠 싣는 것도 가능합니다.
llama-server 실행 파일 하나만 띄우면 그대로 OpenAI 호환 API 서버가 되고, 도커(Docker — 프로그램과 실행 환경을 상자 하나로 포장해 어디서든 똑같이 돌게 하는 기술, 이 모듈 뒷부분에서 자세히)로도 배포할 수 있습니다.
Ollama는 llama.cpp 엔진을 감싸 ollama pull 모델명, ollama run 모델명 단 두 개의 명령으로 쓸 수 있게 만든 도구입니다. 이 "명령"은 브라우저 주소창이 아니라 터미널(명령창)이라는 별도 프로그램에 타이핑하는 것입니다 — 지금 당장 따라 하지 않아도 됩니다, 실습은 모임에서 함께 합니다. 터미널이 낯설다면 워밍업에서 먼저 익히고 오세요.
모델 저장, 전환, API 제공까지 전부 자동으로 처리해줘서 개인 실습의 표준으로 자리 잡았습니다. 다만 동시 접속 슬롯 수나 KV 캐시의 세밀한 제어 같은 깊은 서버 설정은 llama-server를 직접 실행하는 것보다 제한적입니다.
LM Studio는 모델 검색부터 다운로드, 채팅까지 전부 화면 클릭만으로 끝낼 수 있는 도구입니다. 서버 기능을 켜는 것도 버튼 하나면 충분합니다.
코드를 다뤄본 적 없는 사람이 로컬 LLM을 처음 경험하기에 가장 알맞고, 6월 발표 때 핸즈온 자료로 소개한 그 도구입니다.
vLLM은 연속 배칭(continuous batching — 여러 사용자의 요청을 묶어 한 번에 처리하는 기법, 자세한 설명은 이 모듈 뒷부분에서) 같은 고급 기법으로 수십에서 수백 명의 동시 사용자를 감당하도록 만들어진 고성능 서빙 엔진입니다.
다만 중요한 제약이 있습니다. 최신 세대 GPU를 전제로 개발되어, 파스칼 세대(2016년경 나온 구형 GPU 세대명)처럼 오래된 GPU는 지원하지 않습니다.
지금까지 본 세 엔진을 상황별로 정리하면 다음과 같습니다.
| 상황 | 추천 | 이유 |
|---|---|---|
| 개인 PC에서 가볍게 실습 (GPU 없어도 됨) | Ollama 또는 LM Studio | 설치·실행 최단 경로, CPU만으로 1B~4B급 구동 가능 |
| 팀이 공유하는 사내 서버(구형 GPU 포함) | llama.cpp의 llama-server | 지원 폭·멀티 GPU·API 제공 |
| 신형 GPU 다수, 대규모 동시 사용자 | vLLM | 처리량 최적화 |
엔진 이름을 아는 것과 생태계 전체가 어떻게 맞물리는지 아는 것은 다릅니다. 로컬 LLM이 여러분 앞에 도착하기까지의 전체 경로를 한 층씩 쌓아보면 이렇습니다.
⑤층의 용어 두 개만 짚고 갑시다. Docker(도커)는 프로그램과 그 실행 환경(라이브러리, 설정)을 통째로 상자 하나에 포장하는 기술입니다. "내 컴퓨터에선 되는데 저 서버에선 안 돼요" 문제를 없애주기 때문에, 서버에 서빙 엔진을 올릴 때 사실상 표준으로 쓰입니다. k8s(쿠버네티스)는 그런 상자를 수십~수백 개 규모로 여러 서버에 자동 배치·복구하는 도구인데, 우리 규모(서버 1대)에서는 아직 필요 없습니다. 그리고 vLLM 설명에 나온 배칭(batching)은 여러 사용자의 요청을 묶어 GPU가 노는 시간 없이 한꺼번에 처리하는 기법입니다 — 동시 사용자가 많을수록 처리량을 지키는 핵심 기술입니다.
엔진 층을 조금 더 넓게 보면, 이 판에는 저마다의 전문 분야를 가진 선수가 더 있습니다. 아래 표는 훑어보기용입니다 — SGLang·TensorRT-LLM 같은 이름까지 외울 필요는 없고, "이런 전문 엔진들도 있다" 정도만 눈에 담아두면 충분합니다.
| 엔진 | 주특기 | 전제 조건 |
|---|---|---|
| llama.cpp | 지원 폭(구형 GPU·CPU·멀티 GPU), GGUF의 본가 | 거의 없음 — 그래서 우리의 기본기 |
| Ollama / LM Studio | 개인 실습 편의 (llama.cpp 기반) | 거의 없음 |
| vLLM | 대규모 동시 사용자 처리량 | 신형 GPU |
| SGLang | 구조화된 출력·에이전트 워크로드 고속 처리 | 신형 GPU |
| TGI | HuggingFace 생태계 통합 운영 | 비교적 신형 GPU |
| TensorRT-LLM | NVIDIA 칩 한계 성능 추출 | NVIDIA 신형 + 전담 인력 |
표가 길어 보여도 판단 구조는 단순합니다. 내 하드웨어가 선택지를 먼저 거르고(모듈 1), 남은 것 중 운영 요구(동시 사용자·처리량)가 최종 선택을 정합니다. 그리고 어느 엔진을 고르든 API 표준 층이 같기 때문에, 이 API 위에 올리게 될 워크플로우·에이전트(다음 모듈에서 배웁니다)는 엔진을 갈아타도 거의 그대로 살아남습니다. 이것이 생태계가 표준으로 수렴하면서 생긴 실무적 이점입니다.