알리바바 Qwen 연구팀이 지난주 금요일 공개한 Qwen 3.8 27B는 로컬에서 돌릴 수 있는 오픈 웨이트 모델의 현재 도달점을 잘 보여주는 사례다. 아파치 2 라이선스로 배포된 이 270억 파라미터급 비전 지원 모델은 디스크 용량이 17GB에 불과한 Q4_K_M 양자화 빌드로도 노트북에서 구동된다. 27B라는 크기는 어느 정도 사양을 갖춘 개인용 장비에서 실사용하기에 적당한 규모로, 전작인 Qwen 3.6 27B가 이미 좋은 평가를 받았던 계보를 잇는다. Qwen이 자체 공개한 벤치마크는 3.6 27B는 물론 지난 5월까지도 자사 최상급으로 꼽히던 폐쇄형 Qwen 3.7-Plus까지 넘어서는 수치를 제시하는데, 자체 발표인 만큼 독립적인 벤치마크 검증 결과를 기다려 볼 필요가 있다.
기본값이 만든 21분짜리 그림
이 모델에서 실무자가 가장 먼저 마주치는 함정은 추론 강도(reasoning effort)의 기본값이 'xhigh'로 설정돼 있다는 점이다. Qwen 3.8은 reasoning_effort 파라미터로 추론 깊이와 비용을 조절하도록 공식 지원하지만, 배포된 GGUF 빌드가 이 극단적인 기본값을 그대로 물려받는다. 그 결과 사소한 요청에도 모델이 방대한 사고 과정을 소모한다. 사이먼 윌리슨의 테스트에서 128GB M5 Max 맥북 프로와 NVIDIA DGX Spark 양쪽 모두, LM Studio의 기본 컨텍스트 한도인 8,192 토큰이 추론만으로 순식간에 소진되는 문제가 나타났다. 최대치인 262,144 토큰으로 컨텍스트를 늘리자 문제는 사라졌지만, 이번에는 시간이 문제가 됐다.
대표적인 예가 그가 오래 사용해 온 '자전거 탄 펠리컨' SVG 생성 테스트다. 확장된 컨텍스트에서 이 모델은 22,276개의 추론 토큰을 써서 3,223 토큰짜리 결과물을 만드는 데 무려 21분을 소비했다. 로컬 구동 모델 중 지금까지 가장 뛰어난 펠리컨 그림이었지만, 21분을 기다릴 값어치가 있었느냐는 질문에 그는 단호하게 아니라고 답한다. 같은 프롬프트를 추론을 끈 상태로 돌리자 3,715 토큰을 137초, 즉 2분 남짓 만에 내놓았다. '원을 그려 달라'는 단순 요청에도 모델은 스스로 '단순한 원을 넘어서는 정교한 작품'을 만들겠다며 동심원 안내선과 은은한 애니메이션을 얹은, 요청하지 않은 결과물을 몇 분에 걸쳐 생성했다.
추론이 실제로 도움이 되는 지점
다만 과잉 추론이 늘 무의미한 것은 아니다. 비전 모델 평가에 흔히 쓰이는 바운딩 박스 테스트에서 이 모델은 사진 속 펠리컨의 위치를 0~1000 스케일 좌표로 정확히 짚어냈다. 나아가 그 좌표를 이미지 위에 렌더링하는 HTML 도구를 단일 프롬프트만으로 오프라인에서 만들어냈는데, 추론 강도를 낮추는 것을 잊은 탓에 요청하지 않은 데모 장면 생성 기능까지 스스로 덧붙였다. 흥미롭게도 예시 JSON에 'pelicans'라는 라벨이 있었다는 이유만으로 모델이 캔버스에 펠리컨 실루엣을 직접 그려 넣기로 결정하는 과정이 사고 과정에 그대로 드러났다. 반대로 추론을 끄고 같은 도구를 만들게 하자 박스 위치가 어긋나 완전히 작동하지는 않았다. 한 번에 제대로 된 도구를 뽑아내는 데는 추론이 실질적인 차이를 만든 셈이다.
코딩 에이전트 구동 능력도 실무 관점에서 중요한 검증 대상이다. 긴 컨텍스트, 견고한 코드 생성, 신뢰할 수 있는 도구 호출이라는 세 조건을 스펙상 모두 갖춘 이 모델을, 시스템 프롬프트가 짧아 소형 모델에 적합한 에이전트 Pi에 연결해 테스트한 결과는 긍정적이었다. Datasette 코드베이스에서 여러 파일을 읽어 들여 견실한 답변을 냈고, JSONL 세션 기록을 마크다운으로 변환하는 파이썬 코드를 직접 작성하고 테스트까지 마쳤다. 17GB짜리 모델이 코드 작성, 도구 구동, 이미지 주석까지 실무에 필요한 대부분을 해낸다는 것은 분명한 성취다.
남은 과제는 결국 속도
결정적인 걸림돌은 속도다. LM Studio 기준 초당 15~30 토큰 수준으로, 치명적으로 느리지는 않지만 호스팅 API 모델을 대체할 만큼 빠르지도 않다. 참고로 Artificial Analysis가 집계한 OpenAI 5.6 Sol은 초당 74 토큰, 5.6 Luna는 184 토큰을 기록한다. 근본 원인은 이 모델이 MoE가 아닌 밀집(dense) 구조라 상당한 메모리 대역폭을 요구하는데, 테스트에 쓰인 두 장비 모두 그 부분에서 최상급은 아니라는 데 있다. 그나마 희망적인 것은 커뮤니티의 최적화 시도다. 모델 자체에 내장된 다중 토큰 예측(Multi-Token Prediction)은 저렴한 기제로 여러 토큰을 미리 추측한 뒤 본 모델이 빠르게 검증하는 방식인데, llama.cpp의 --spec-type draft-mtp 옵션으로 구동하자 LM Studio 기본 GGUF 대비 약 72% 빠른 성능이 측정됐다. MLX 진영의 최적화도 뒤따를 것으로 보인다.
실무자 입장에서 이 모델을 도입한다면, 배포 기본값을 그대로 믿지 말고 reasoning_effort를 작업 성격에 맞게 조정하는 것이 첫 번째 원칙이 되어야 한다. 정밀한 코드 생성이나 한 번에 작동하는 도구가 필요할 때는 추론을 유지하되, 단순 변환이나 요약 작업에는 추론을 낮추거나 꺼서 응답 시간을 수십 배 단축할 수 있다. 컨텍스트 한도 역시 기본 8K가 아니라 넉넉히 확보해야 추론 폭주로 인한 중단을 피할 수 있다. 결국 Qwen 3.8 27B가 증명하는 것은 긴 컨텍스트, 효과적인 도구 호출, 강력한 비전 능력, 준수한 코드 생성을 갖춘 범용 오픈 웨이트 모델을 단 17GB 파일에 담을 수 있다는 사실이다. 데이터센터급 하드웨어에 수십만 달러를 쓰지 않고도 유능한 모델을 손에 넣을 수 있게 된 흐름 속에서, 남은 병목은 성능뿐이며 그마저도 빠르게 좁혀지고 있다.