폐쇄망 LLM 4개월간 배포 후기

2025년 12월 말 팀 내 LLM 배포를 시작한 지 4개월이 지났습니다. 그동안의 변화를 한번 정리해 보겠습니다.

현재 저희 팀이 사용하는 모델은 Qwen3.6-27B-FP8입니다. 이전 글 작성 시점에는 Devstral-Small-2-24B-Instruct를 쓰고 있었는데, 그 사이에 여러 모델을 시도하고 검토하는 과정이 있었습니다. 이미 한참 지난 모델도 있지만, 배포 전략과 함께 시간순으로 정리해 보겠습니다.

4개월간의 배포 변화

순서	모델	서빙	코딩 클라이언트	웹 UI
1	GLM-4.5-Air-FP8	vLLM	Claude-Code	Open-WebUI
2	Devstral-Small-2-24B-Instruct	vLLM	Mistral-Vibe	Open-WebUI
3	Qwen3-Coder-Next-FP8	vLLM	Qwen-Code	Open-WebUI
4	Qwen3.5-122B-A10B-FP8	vLLM	Qwen-Code	Open-WebUI
5	Qwen3.6-35B-A3B-FP8	vLLM	Qwen-Code	Open-WebUI
6	Qwen3.6-27B-FP8	vLLM	Qwen-Code	Open-WebUI

보시다시피 서빙 프레임워크는 안정성과 범용성 등의 이유로 vLLM이 줄곧 자리를 지켰고, 웹 채팅 서비스는 사실상 Open-WebUI 외에 마땅한 대안이 없습니다.

모델별 후기

GLM-4.5-Air

GLM-4.5-Air는 그 당시 Reddit에서 호평이 정말 자자했습니다. 그런데 막상 배포해 보니 실망이 좀 컸는데요. 일단 클라우드로 제공되는 모델과 공개 모델이 조금 다르더라고요. 공개 모델은 추론 전용 모델인데, 이게… 추론을 너무 많이 합니다.

모델을 띄우고 나면 가볍게 속도 체크로 Python에 “insertion sort, quick sort, bubble sort 짜줘”를 요청하곤 합니다 (한 번에 여러 개 요청해야 로그로 속도를 볼 수 있습니다). 그런데 quick sort에서 사고가 무한 루프에 빠져서, 다섯 번 시도하면 한 번도 성공하지 못하는 경우가 있었습니다. 희한할 정도로 단순한 태스크에서 막히는 거죠.

이 모델을 염두에 두고 클라우드에서 테스트도 해보고 하드웨어 예산까지 받아서 진행했던 터라, 솔직히 며칠간은 심장이 벌렁거릴 정도로 스트레스였습니다.

Devstral-Small-2-24B

다행히 며칠 뒤 Devstral-2가 나왔습니다. 큰 모델과 작은 모델이 오픈소스로 공개됐는데, 큰 모델은 120B 정도라 실사용자 10명 내외에 동시 요청 4명을 염두에 둔 저희 환경에서는 KV Cache 사이즈가 감당이 안 됐습니다. 그래서 Devstral-2-24B 쪽으로 갔고, 같은 시기에 Mistral에서 Mistral-Vibe라는 CLI 툴도 공개해서 이 두 가지를 묶어 배포했습니다.

정말 다행히도, 그리고 놀랍게도 모델 사이즈에 비해 쓸 만했습니다. ‘폐쇄망에서도 이 정도는 할 수 있구나” 싶은 수준까지는 올라왔거든요. 다만 Mistral-Vibe가 너무 최신 도구라 그런지 잔버그가 꽤 많았습니다. 공식적으로 Linux와 Mac 사용을 권장하긴 하지만, Windows에서 쓸 때는 CLI로 한참 채팅하고 나면 스크롤이 안 돼서 AI가 뭐라고 했는지 거슬러 볼 수가 없더라고요.

그렇게 몇 달간은 약간 불편하면서도 그럭저럭 쓰며 지냈습니다.

Qwen 시리즈

그러다 2026년 2월 초를 기점으로 Qwen 모델이 쏟아지듯 나왔습니다. 이때 맞춰서 CLI도 Qwen-Code로 교체했습니다. Qwen3-Coder-Next부터는 이전 Devstral에 비해 tool call이나 agentic coding 성능이 확실히 한 단계 올라온 게 체감됐습니다. Vibe에 비해 Qwen-Code가 잔버그도 적어서 사용감 측면에서도 더 좋았고요.

이후로 Qwen 모델이 정말 와다다 쏟아져 나왔습니다. Qwen3.5-122B-A10B → Qwen3.6-35B-A3B → Qwen3.6-27B 순으로 옮겨가며 테스트했고, 지금은 Qwen3.6-27B에 정착했습니다.

4개월의 결론: 이제 on-premise도 충분히 쓸 만하다

현재 Qwen3.6-27B를 쓰며 드는 생각을 말씀드리면, 이제 진짜로 on-premise 도입이 전혀 이르지 않은 시대가 왔다는 겁니다. 이전 모델들까지는 오픈 모델 특유의 문제, 그러니까 틀린 소리를 당당하게 한다거나 같은 말을 반복한다거나 하는 부분이 종종 있었는데, 지금은 상당히 신뢰할 만한 수준까지 올라왔습니다.

벤치마크를 잠깐 볼까요?

항목	Gemma4-31B	Claude 4.5 Opus	Qwen3.6-35B-A3B	Qwen3.6-27B
Coding Agent
SWE-bench Verified	52.0	80.9	73.4	77.2
SWE-bench Pro	35.7	57.1	49.5	53.5
SWE-bench Multilingual	51.7	77.5	67.2	71.3
Terminal-Bench 2.0	42.9	59.3	51.5	59.3
SkillsBench Avg5	23.6	45.3	28.7	48.2
QwenWebBench	1197	1536	1397	1487
NL2Repo	15.5	43.2	29.4	36.2
Claw-Eval Avg	48.5	76.6	68.7	72.4
Claw-Eval Pass^3	25.0	59.6	50.0	60.6
QwenClawBench	41.7	52.3	52.6	53.4

제가 가장 먼저 보는 지표는 Terminal-Bench 2.0이고, 그 다음으로 보는 게 SWE-bench입니다. Terminal-Bench는 agentic coding 시 터미널 사용 능력을 보는 벤치마크인데, 체감상 이 점수가 CLI 작업 성능에 가장 크게 영향을 미치는 것 같습니다. Terminal-Bench와 SWE-bench를 같이 놓고 보면 Opus 4.5보다 살짝 떨어지는 정도로 나오는데, 과장 없이 제 체감과 거의 일치합니다.

속도

속도는 MTP와 FLASHINFER를 함께 사용할 때 decode 기준 약 100 TPS 정도 나옵니다.

MTP(Multi-Token Prediction)는 답변 경로 예측을 통해 decode 속도를 향상시키는 기법입니다. Qwen 모델에서는 제 경험상 30~40% 정도의 속도 개선이 있습니다.

decode와 prefill에 대해서는 이전 글을 참고하세요.

하드웨어 설계 글에서 말씀드렸다시피 제가 사용 하는 장비는 RTX Pro 6000 Blackwell × 2입니다.

장비 가격 상승

가슴 아픈 변화도 하나 있습니다. 첫 글을 쓸 당시에는 6,000만원 내외라고 말씀드렸는데, 지금은 사정이 좀 다를 것 같습니다.

저는 2026년 초부터 회사 매매서버 교체 건으로 품의를 진행하고 있는데, 진행 단계마다 가격이 달라지는 진귀한 경험을 했습니다. 2026년 3월 즈음에 64GB 서버용 RAM이 400만원 정도 했으니, 여러 가지 측면에서 지금 192GB VRAM(CPU RAM도 이 이상은 필요합니다)을 장착한 on-premise 장비를 구매하려고 하면 가격이 어떻게 나올지 모르겠습니다.

당시 6,000만원 내외로 셋업할 때 노파심에 수냉 쿨러나 RAM을 최대한 크게 잡아 두었는데, 지금은 그런 여유 사양들을 좀 깎으면 비슷한 예산에 맞출 수 있을지도 모르겠네요.

추가 변화

몇 가지 추가적인 변화도 있었습니다. LLM 성능이 어느 정도 안정화되면서 생긴 변화라고 봅니다.

먼저 처음에는 저희 팀 전용으로 운영하던 모델을 다른 팀에도 제공하기 시작했습니다. 그리고 MCP도 도입했습니다. 예전에는 무서워서 손도 못 대던 작업인데, 모델이 신뢰할 만한 수준이 되면서 데이터베이스, Gitea, YouTrack, filesystem 등에 MCP를 붙여 보고 있습니다.

후기와 구체적인 사용 사례는 다음 글에서 다루도록 하겠습니다.