Qwen3.5 무료라서 설치했더니 이게 막혔습니다

알리바바가 2026년 2월 16일 오픈소스로 공개한 Qwen3.5. “무료에 Apache 2.0이니 마음껏 쓰면 되겠지”라고 생각했다면, 막상 설치 단계에서 예상 밖의 벽에 부딪힐 수 있습니다. 35B 모델인데 활성 파라미터가 3B라는 말이 무슨 뜻인지, 왜 Ollama에서는 지금 당장 안 돌아가는지 — 짚고 넘어갈 게 몇 가지 있습니다.

Qwen3.5가 화제인 진짜 이유

결론부터 말씀드리면, Qwen3.5는 “무료니까 한번 써보는” 수준의 모델이 아닙니다. 알리바바 클라우드 산하 통이(通义) 연구소가 2026년 2월 16일 HuggingFace에 공개한 이 모델은, 공식 벤치마크에서 GPT-5.2, Claude Opus 4.5와 같은 최상위 상용 모델들과 나란히 비교되는 위치에 놓였습니다. (출처: Qwen 공식 블로그, 2026.02.15)

무엇보다 이 모델의 정체성은 “네이티브 멀티모달 에이전트”입니다. 텍스트, 이미지, 영상, 문서를 별도 어댑터 없이 하나의 모델 안에서 처리합니다. 이전 세대인 Qwen3까지는 비전 기능이 별도 VL 버전으로 분리돼 있었지만, Qwen3.5는 처음부터 텍스트와 비전 토큰을 함께 학습하는 얼리 퓨전(early fusion) 방식으로 만들었습니다. 이미지 이해 성능이 덤으로 따라오는 게 아니라, 처음부터 그게 설계 목표였던 겁니다.

지원 언어도 119개에서 201개 언어/방언으로 늘었고, 어휘집(vocabulary) 규모도 15만에서 25만으로 키웠습니다. 어휘집이 커지면 한국어처럼 형태소가 복잡한 언어에서 같은 문장을 더 적은 토큰으로 표현할 수 있어, API 비용이나 로컬 추론 속도 모두 유리해집니다. (출처: Qwen 공식 블로그, 2026.02.15)

▲ 목차로 돌아가기

35B인데 왜 3B처럼 빠를까 — MoE 구조 핵심 정리

Qwen3.5 계열의 모델 이름에는 “A3B”, “A10B”, “A17B” 같은 표기가 붙습니다. “A”는 Active(활성)를 뜻합니다. Qwen3.5-35B-A3B는 총 파라미터가 35B지만, 한 번 추론할 때 실제로 작동하는 파라미터는 3B뿐입니다. 이게 MoE(Mixture-of-Experts) 구조의 핵심입니다.

MoE는 모델 내부에 여러 개의 “전문가(Expert)” 네트워크를 두고, 입력된 토큰마다 관련된 소수의 전문가만 골라서 작동시킵니다. 전체를 다 돌리지 않으니 연산 비용은 작은 모델 수준이고, 총 파라미터에 녹아있는 지식은 큰 모델 수준으로 쓸 수 있습니다. Qwen3.5-35B-A3B의 추론 속도는 3B 수준인데 성능은 이전 세대 235B 모델을 넘습니다. — 이건 벤치마크 발표가 아니라 공식 블로그에 직접 나온 수치입니다. (출처: Qwen 공식 블로그, 2026.02.15)

실제 VRAM 요구량을 보면, 35B-A3B(12~15GB)가 27B(18~20GB)보다 오히려 메모리를 덜 씁니다. 35B짜리를 RTX 3090 한 장으로 돌릴 수 있다는 뜻입니다. 숫자만 보고 “더 크니까 더 무겁겠지”라고 판단하면 선택을 잘못할 수 있습니다.

▲ 목차로 돌아가기

무료라도 바로 못 쓰는 조건이 있습니다

Qwen3.5는 Apache 2.0 라이선스입니다. 상업적 이용, 수정, 재배포 모두 가능합니다. 근데 “무료 오픈소스”라는 말만 듣고 Ollama에 바로 설치하려 하면 지금 당장은 안 됩니다.

Ollama 대신 llama.cpp 기반 백엔드(Unsloth Studio, LM Studio, llama-server)를 써야 합니다. Ollama가 로컬 LLM 사용의 진입장벽을 가장 많이 낮춰준 도구인 만큼, 이 제약은 체감 상 상당한 불편입니다.

또 하나, Small 시리즈(0.8B, 2B, 4B, 9B)는 Thinking 모드가 기본적으로 꺼져 있습니다. 추론 기능을 쓰고 싶다면 실행 시 --chat-template-kwargs '{"enable_thinking":true}' 파라미터를 별도로 넘겨야 합니다. 이걸 모르고 쓰면 “이게 왜 이렇게 답변이 단순하지?”라는 느낌이 들 수 있습니다. (출처: Unsloth 공식 문서)

LM Studio를 쓰는 경우에도 별도 주의사항이 있습니다. 커뮤니티 보고에 따르면, LM Studio의 파서가 Qwen3.5의 도구 호출(tool calling) 특수 토큰을 인식하지 못해 MCP 서버 연동이 조용히 실패하는 문제가 있었습니다. Unsloth가 2026년 3월 5일 GGUF 업데이트에서 채팅 템플릿 버그를 수정했으니 반드시 최신 버전으로 재다운로드해야 합니다. (출처: LocalLLaMA 커뮤니티, 2026.03.03)

▲ 목차로 돌아가기

모델별로 용도가 다릅니다 — 선택 기준 정리

Qwen3.5는 현재 크게 네 가지 오픈웨이트 모델과 하나의 API 전용 버전(Qwen3.5-Plus)으로 구성돼 있습니다. 이름만 보고 “큰 게 무조건 좋겠지”라고 고르면 실제 작업에서 손해를 봅니다.

파인튜닝이나 특정 분야 적용이 목적이라면 → Qwen3.5-27B

27B는 Dense 모델입니다. 모든 파라미터가 항상 활성화됩니다. MoE 구조가 아니기 때문에 메모리 사용량이 예측 가능하고, 파인튜닝 시 학습이 더 안정적입니다. 의료, 법률, 금융처럼 특정 도메인 데이터로 학습을 더 돌려야 하는 상황이라면 MoE 모델보다 Dense 모델이 권장됩니다. (출처: CurateClick 가이드, 2026.02.25)

동시 사용자 많고 비용 민감한 서비스 → Qwen3.5-35B-A3B

활성 파라미터 3B라는 건 추론 한 번의 연산 비용이 3B 모델 수준이라는 뜻입니다. 트래픽이 많은 서비스에서 단위 요청당 비용이 가장 낮으면서, 성능은 이전 세대 235B를 넘습니다. API 서비스로 Qwen3.5-Flash(35B-A3B 기반)를 쓰면 약 100만 토큰당 $0.40 수준입니다. (출처: CurateClick 가이드, 2026.02.25) GPT-5 계열 대비 수십 배 저렴한 수준입니다.

장문서·복잡한 멀티스텝 추론 → Qwen3.5-122B-A10B

법률 계약서 전체, 코드베이스 전체를 컨텍스트에 넣고 분석해야 한다면 122B-A10B를 선택합니다. 활성 파라미터는 10B지만 262K+ 컨텍스트를 안정적으로 유지하면서 깊은 추론을 처리합니다. 다만 로컬에서 돌리려면 멀티 GPU 환경이나 상당히 공격적인 양자화(Q2/Q3)가 필요합니다.

▲ 목차로 돌아가기

벤치마크가 말해주지 않는 것 — 실사용 한계

벤치마크 수치는 인상적입니다. 근데 실사용 커뮤니티에서 확인되는 한계 몇 가지는 벤치마크 표에 안 나옵니다.

코딩 에이전트로 Qwen3.5를 쓰는 경우, 공식 GitHub 이슈 트래커에는 “모델이 매우 장황하고 감지 루프에 빠진다”는 보고가 올라와 있습니다. 단순 코드 생성은 잘 되지만, 에이전틱 코딩 루프에서 툴 호출이 반복되거나 멈추는 경우가 보고됐습니다. 알리바바가 공식 답변을 아직 내놓지 않은 부분입니다. (출처: QwenLM GitHub Issues, 2026.02.23)

커뮤니티 사용 후기에서는 Qwen3.5가 코딩보다 검색 에이전트에 특화돼 있다는 평가가 나옵니다. BrowseComp(에이전틱 검색) 벤치마크 78.6은 Gemini 3 Pro(59.2)를 크게 앞섭니다. 반면 Terminal-Bench 2 코딩 에이전트 점수(52.5)는 Claude Opus 4.6(59.3), Gemini 3 Pro(54.2)에 모두 뒤집니다. 어떤 용도인지에 따라 결과가 달라지는 겁니다. (출처: DataCamp 분석, 2026.02.16)

397B-A17B를 4비트 양자화(Q4)해서 쓰면 원본 대비 정확도 손실은 약 0.8포인트입니다. 750개 프롬프트 혼합 테스트에서 원본 81.3% → Q4 80.5%로, 상대적 에러 증가율은 4.3%입니다. 정확도를 거의 유지하면서 저장 공간을 약 500GB 줄일 수 있습니다. (출처: Benjamin Marie 벤치마크, Unsloth 문서 인용, 2026.03.05)

▲ 목차로 돌아가기

개발팀 이탈 변수, 알고 쓰는 게 맞습니다

Qwen3.5 출시 이후인 2026년 3월 4일, 핵심 개발자 류쥔양(Junyang Lin)의 사퇴를 시작으로 기존 개발진의 이탈이 이어지고 있습니다. 중국 언론에서는 내부 조직 개편 과정에서 불화가 있었다고 추정하고 있습니다. (출처: 나무위키 Qwen 문서, 2026.03.22 최종 수정)

이걸 왜 언급하는가 하면, 오픈소스 모델의 지속성은 개발팀의 안정성과 직결되기 때문입니다. 이미 Apache 2.0으로 공개된 모델 자체는 사라지지 않지만, 이후 업데이트나 버그 수정 속도가 느려질 수 있습니다. 현재 발견된 Ollama 미지원 문제, 툴 호출 버그 같은 이슈들이 얼마나 빨리 공식 지원으로 해결될지는 현재로서 공식 입장이 없는 부분입니다.

반면, Apache 2.0이라는 라이선스의 특성상 커뮤니티 기반 유지보수는 계속 이어질 수 있습니다. 실제로 Unsloth, llama.cpp, LM Studio 같은 써드파티가 이미 Qwen3.5 지원을 빠르게 추가하고 있고, 3월 5일 GGUF 툴 호출 버그 수정도 알리바바가 아닌 Unsloth 팀에서 먼저 패치를 내놓은 사례입니다. 오픈소스 생태계가 공식 팀을 앞서가는 구조가 만들어지고 있는 셈입니다.

▲ 목차로 돌아가기

Q&A

▲ 목차로 돌아가기

마치며

Qwen3.5는 제대로 이해하고 쓰면 분명히 강력한 선택지입니다. 특히 35B-A3B처럼 이전 세대 235B를 활성 파라미터 3B로 넘어서는 효율성은, AI 모델 선택의 기준이 “파라미터 수”에서 “아키텍처 효율”로 이동하고 있다는 걸 실증적으로 보여줍니다.

솔직히 말하면, “Apache 2.0이니까 무조건 OK”라는 생각으로 접근하면 Ollama 미지원, 툴 호출 버그, Thinking 모드 기본값 비활성화 같은 벽에 금방 부딪힙니다. 로컬 배포를 목표로 한다면 llama.cpp 계열 툴을 먼저 세팅하는 게 현재 기준으로 맞는 순서입니다.

개발팀 이탈 이슈는 장기적으로 지켜봐야 하는 변수입니다. 지금 당장은 커뮤니티와 써드파티가 빠르게 움직이고 있어 실사용에 큰 문제가 없지만, 앞으로 나올 업데이트 속도가 어떻게 될지는 좀 더 봐야 합니다. 모델은 이미 공개됐으니, 지금 써보기엔 나쁘지 않은 타이밍입니다.

▲ 목차로 돌아가기

본 포스팅 참고 자료

1. Qwen 공식 블로그 — Qwen3.5: Towards Native Multimodal Agents https://qwen.ai/blog?id=qwen3.5
2. Unsloth 공식 문서 — Qwen3.5 How to Run Locally Guide https://unsloth.ai/docs/models/qwen3.5
3. DataCamp — Qwen3.5: Features, Access, and Benchmarks https://www.datacamp.com/blog/qwen3-5
4. CurateClick — Complete Guide to Qwen3.5 Models 2026 https://curateclick.com/blog/2026-qwen35-models-guide
5. Hugging Face — Qwen/Qwen3.5-2B https://huggingface.co/Qwen/Qwen3.5-2B
6. 나무위키 — Qwen (2026.03.22 최종 수정)