지옥의 배차 문제도 풀어내는 로컬 LLM의 다크호스
오늘은 최근 테스트해 본 Qwen 3.5 35B 모델의 실사용기를 적어볼까 합니다.
결론부터 말씀드리면, 기획과 플래닝은 프론티어 모델에 맡기더라도 '바이브 코딩'의 실무 수행용으로는 기가 막힌 퍼포먼스를 보여주는 녀석입니다.
1. 용량과 체감 성능
일단 27B 모델에 비해 35B의 체감 성능 향상이 확실히 체감됩니다.
- 모델 용량: 27B -> 35B
- VRAM 소모: 컨텍스트를 20K 정도 주면 실제 VRAM은 모델 용량에서 약 15% 정도 더 먹습니다.
- 구동 환경: 24GB VRAM GPU에서도 오프로딩을 병행하면 돌아가긴 합니다.
하지만 컨텍스트를 늘리고 동시 처리 수를 4 이상으로 설정해 쾌적하게 쓰려면 40GB 수준의 GPU가 적당합니다. 즉, 맥 미니 64GB에서 돌리기 딱 좋은 포지션입니다. - 출력 속도: 세팅만 잘 만져주면 초당 60~100토큰 수준으로 시원시원하게 뽑아줍니다.
2. 강화학습 의 모델 특성 힘
모델 카드나 공식 문서에 소개된 대로, Qwen 3.5는 기존 Qwen 3의 VL, Coder 등 모든 변형 모델을 합체한 완전체입니다.
특히 광범위한 강화학습을 거쳤다는 점을 강조하는데, 실사용에서도 이 부분이 크게 와닿습니다. 기존 학습 데이터에 없는 문제도 스스로 방법을 찾아내는 능력이 탁월합니다.
요즘 느끼는 프론티어 모델들의 특징과 비교해 보면 이렇습니다.
- Claude Opus: 이미 존재하는 해법으로 문제를 안정적이고 효과적으로 풀어냄.
- GPT-5.4: RL을 엄청나게 먹인 건지, 발상이나 해법이 매우 자유롭고 신박한 결과를 자주 도출함.
- Qwen 3.5: Kimi처럼 RL 튜닝이 잘 된 느낌. 최근 모델들의 트렌드인 '지시 이행성'과 '창발성' 사이의 미묘한 균형을 포스트 트레이닝으로 아주 잘 잡아냈습니다.
3. 에이전트 vs 코딩/추론 실사용 용도:
- 에이전트 헤더 : 솔직히 자랑하는 것에 비해 좀 허접합니다.
OpenCode, Claude Code, 심지어 자사의 Qwen Code 메인 모델로 테스트해 봤는데 기획/플래닝 용도로는 결과가 다 별로였습니다.
이 용도는 122B Ollama Cloud 테스트 로도 아쉬웠고, 아마 397B 체급은 가져와야 쓸 만할 것 같습니다. - 코딩 및 논리적 추론 Execution: 일상적인 기술 채팅이나 코드 작성 능력은 상당합니다. 특히 추론이 까다로운 문제에서 빛을 발합니다.
업계 1티어 난이도 '지옥의 배차 문제'
제가 새로운 모델을 테스트할 때마다 항상 던져보는 2턴짜리 '배차 과제'가 있습니다.
프론티어 모델들도 토큰을 엄청나게 태워야 겨우 그럴싸하게 풀고, 제미나이조차도 헤매는 악명 높은 문제입니다.
[Turn 1. 첫 번째 질문]
굉장히 풀기 복잡한 문제가 있다.
1. 운송: 출발지, 도착지, 출발/도착 시간 범위, 화물 부피/무게 속성 보유.
2. 기사: 활성/비활성 상태 존재. 비활성 시 배차 불가. 소유 차량에 부피/무게 제한 있음.
3. 라우팅: 모순 없이 최적으로 할당. 여러 운송을 묶을 시 출발이 도착보다 먼저 편성되어야 함.
4. 목표: 기사에게 화물을 배정하고 최적의 라우팅 순서를 편성하여 가장 효율적인 거리로 이동하게 만들기.
5. 동적 적재량: 픽업 시 적재량 소비, 하차 시 회복. 라우팅 실행 중 동적 변화 고려.
6. 시간 모순 금지: 운송 간 시간 역전 불가.
7. 시간 밀집성: 픽업 후 중간에 길거리에서 장시간 대기 불가. 스케줄이 밀집되어야 함.
8. 그룹화: 시간 밀집성을 고려해 여러 운송을 한 번에 할당할 땐 밀집된 그룹으로 묶어야 함.
9. 필수 할당: 모든 운송은 반드시 할당되어야 함.
10. 동적 재편성: 운송 상태(대기->픽업->완료/실패/취소 등) 변화 및 배차/미배차 플래그에 따라 전체 라우팅 실시간 재계산.
11. 기사 상태 변수: 기사 비활성 시 기존 배차는 락(Lock)되며, 관리자가 수동으로 릴리즈/취소해야 함. (향후 냉동, 리프트 등 차량 사양 제약 조건 추가 고려)
12. 제약: 기사 위치/이동 경로는 모름. 오직 현재 시간과 각 운송 상태만 기반으로 판정.이를 계산하여 처리할 수 있는 자동 배차 알고리즘을 Typescript 코드로 작성하고, 사람이 읽을 수 있는 한글 MD 문서로도 설명해 줘.
이 질문에 Qwen 3.5 35B는 매우 훌륭한 타입스크립트 코드와 구조적인 MD 문서를 뽑아냈습니다.
그리고 곧바로 패러다임의 전환을 묻는 두 번째 질문으로 후려 패보았습니다.
[Turn 2. 두 번째 질문]
문제를 오히려 기사를 배제하고 푼 뒤 가용 기사에게 할당하는 게 나은 걸까?
1. 기사 할당 여부 상관없이 픽업 전의 모든 운송을 대상으로 한다.
2. 운송을 시간대로 밀집시켜 그룹화한다.
3. 출발/도착 GPS 좌표를 고려해 거리가 짧아지는 경로를 산출한다. 이때 부피/무게가 제한을 넘지 않게 그룹화한다.
4. 결국 운송 조합에 따라 전체 거리가 달라진다.
5. 이 과정을 먼저 거치고 기사에게 배정하는 'Cluster-First' 방식이 더 합리적이지 않을까?
보통 여기서 모델들이 뇌정지가 오거나 헛소리를 하기 시작하는데, Qwen 3.5는 "그 관점의 전환은 매우 탁월합니다.
"라며 기존의 Driver-Centric 방식에서 Shipment-Centric 방식으로 구조를 완벽하게 재설계해 냈습니다. 솔
직히 제미나이보다 나은 것 같다는 생각이 들 정도로 추론 능력이 인상 깊었습니다.
게다가 한국어 실력이 엄청납니다. 중국어 뉘앙스나 한자가 튀어나오는 현상이 전혀 없고, 말투 자체도 GPT를 디스틸한 것처럼 굉장히 자연스럽습니다.
Brave Search, DuckDuckGo, Puppeteer 정도를 MCP로 붙여주면 일상적인 챗 서비스로 쓰기에 차고 넘칩니다.
4. 하드웨어 스펙별 사용 가이드
반박 시 여러분의 말이 맞습니다!
- 맥 48GB / 64GB 사용자: 무조건 쓰세요. 이 모델을 돌리기 위한 최적의 장비입니다.
- VRAM 16GB GPU 사용자: 쓰세요. 모델 자체가 워낙 빨라서 llama.cpp 등으로 오프로딩을 돌려도 충분히 쾌적합니다.
- 그 이하 사양: 27B나 8B를 억지로 쥐어짜기보다는... 그냥 맘 편하게 API 결제해서 토큰을 태우시는 걸 추천합니다!
Qwen 3.5 35B 실제 응답 캡쳐본 요약
[첫 번째 질문에 대한 해설 문서 응답 요약]
Logistics Dispatch & Routing System
이 문제는 전형적인 '차량 경로 최적화 문제'에 동적 상태 관리가 결합된 복잡한 형태입니다.
정밀한 수학적 최적화는 실시간 업데이트에 무거우므로 그리디 할당 + 휴리스틱 삽입 기반의 알고리즘을 설계했습니다.
- 핵심 전략: 상태 기반 재계산, 휴리스틱 라우팅 가장 시급한 운송부터 삽입, 동적 적재량 관리, 시간 밀집성 페널티 부여.
- 시간 밀집성: 허용 대기 시간을 초과하면 페널티 점수를 부여해 불연속적 그룹이 자연스럽게 분할되도록 유도.
- 상태 관리: 운송 상태 변경 시
optimize()호출. 기사 비활성 시locked상태 유지로 관리자 수동 조작 대기.
[두 번째 질문 Cluster-First에 대한 응답 요약]
왜 이 방식이 더 나은가?
제안하신 방식은 Shipment-Centric 혹은 Cluster-First Strategy입니다.
- 해결의 질: "어떤 경로가 효율적인가?"를 먼저 계산하므로 시간 밀집성과 거리 최적화에 탁월합니다.
- 제약 조건 분리: 물리적 제약(경로/부피)은 라우팅 단계에서, 인력 제약은 배정 단계에서 분리하여 해결할 수 있어 시스템이 견고해집니다.
Revised Architecture
- Step 1. 경로 클러스터링: 유효 운송 대상 시간/위치 기반 그룹화 및 가상 경로 생성.
- Step 2. 기사 배정: 생성된 가상 경로를 기사의 차량 능력과 매칭하여 할당.
