Qwen3.8-27B는 왜 기본값으로 '과하게 생각'할까 — 추론 토큰 폭주 실측과 끄는 법

핵심 요약

• Qwen3.8-27B는 2026-08-14 출시된 Apache 2.0 라이선스 오픈 모델입니다. 27B dense 파라미터에 비전 인코더가 달려 있고, 컨텍스트는 262,144 토큰 네이티브(1M 확장 가능), Q4_K_M 양자화 기준 17GB 파일입니다 (GitHub QwenLM/Qwen3.8, HF 모델 카드).
• 출시 이틀 만에 다운로드 **300만+**를 기록했고 (Cybernews), 자체 보고 벤치마크에서 SWE-bench Pro 61.7로 Opus4.6 Max(53.4)를 추월하는 프론티어급 에이전트 코딩 점수를 냈습니다 (HF 모델 카드).
• 문제는 기본 reasoning_effort가 xhigh라는 점입니다. "생각하는 모드"가 기본으로 켜져 있어 단순 작업에도 과잉 사고가 발생합니다. Simon Willison은 펠리컨 SVG 한 장에 추론 토큰 22,276개 + 출력 3,223개, 21분을 기록했고, 같은 프롬프트를 reasoning을 끄고 실행하자 3,715개 토큰, 137초로 끝났습니다 (Simon Willison).
• 과잉 사고는 Qwen만의 문제가 아닙니다. 긴 사고가 성능을 올리지만 중복·장황한 출력으로 계산 비용이 커지는 현상은 **"overthinking 현상"**으로 학계에서 정리됐고, post-training 보상 함수가 만든 생성 선호에서 비롯된다는 분석이 나와 있습니다 (arXiv 2503.16419, arXiv 2601.21418).
• 해법은 모델이 아니라 설정입니다. reasoning_effort를 low/medium으로 내리거나 thinking을 끄면 됩니다. llama.cpp에서는 --reasoning off, MTP 추측 디코딩(--spec-type draft-mtp)으로 약 72% 속도 향상도 확인됐습니다 (Simon Willison).
• 이 글에서는 같은 Qwen 패밀리 소형 모델을 직접 구동해 thinking on/off 토큰 차이를 실측했고, 상황별 권장 설정 체크리스트를 정리했습니다.

과잉 사고(overthinking)란 무엇인가

과잉 사고(overthinking)는 추론형 모델이 단순한 작업까지 길고 장황한 사고 과정을 거쳐 토큰과 시간을 낭비하게 만드는 동작 특성입니다. 사용자 프롬프트가 간단하면 간단할수록 사고 과정과 실제 답변의 비율이 비대해집니다. "1+1이 뭐야?" 같은 질문에 수백 개의 사고 토큰을 쓰는 식입니다.

이 현상은 2025년부터 학계에서 체계적으로 다뤄졌습니다. "Stop Overthinking" 서베이는 긴 Chain-of-Thought가 성능을 올리지만 동시에 중복·장황한 출력으로 상당한 계산 오버헤드를 만든다고 정리했고 (arXiv 2503.16419), 2026년 1월 DiPO 논문은 과잉 사고가 post-training 단계의 보상 함수가 만든 생성 선호에서 비롯된다고 분석했습니다 (arXiv 2601.21418). 즉 모델이 "길게 생각하면 보상을 받았다"는 학습 이력 때문에 짧게 끝내는 법을 잊은 것입니다.

Qwen3.8-27B, 왜 5일 만에 화제가 되었나

Qwen3.8-27B가 주목받은 이유는 세 가지입니다. 첫째, 라이선스와 크기입니다. Apache 2.0으로 상업 사용이 자유롭고, 17GB 파일 하나면 노트북에서도 실행됩니다. 둘째, 성능입니다. 자체 보고 기준 SWE-bench Pro 61.7(Qwen3.6-27B 53.5, Opus4.6 Max 53.4), QwenSWEBench 79.0(Opus4.6 Max 63.8), OSWorld-Verified 84.3을 기록해 "로컬 Opus"라는 평가가 나왔습니다 (HF 모델 카드, Pandaily).

셋째, 생태계 반응입니다. 출시 이틀 만에 300만+ 다운로드(Cybernews), GitHub 저장소는 3,838★(2026-08-17 기준, GitHub API 실측), 알리바바의 TSMC 5nm RISC-V 칩 XuanTie C950에서 네이티브 구동까지 확인됐습니다 (wccftech). 같은 시리즈의 MoE 모델 Qwen3.8-2.4T-A95B가 2026-08-12 먼저 나왔고, 27B dense 버전이 08-14에 뒤따랐습니다 (GitHub QwenLM/Qwen3.8).

"기본값이 과잉 사고다" — reasoning_effort=xhigh의 실측

Qwen 공식 문서는 모델의 기본 reasoning effort를 xhigh로 명시합니다. 옵션은 xhigh(기본, 복잡한 작업용), medium(정확도와 속도 균형), low(속도와 비용 최적화)입니다. 그리고 thinking 모드 자체가 기본 ON입니다. "Thinking mode is on by default and can be disabled per request"가 모델 카드의 원문입니다 (HF 모델 카드).

이 기본값이 실제로 얼마나 비싼지는 Simon Willison의 실측이 가장 선명합니다. 그는 펠리컨이 자전거를 타는 SVG를 그리라는 프롬프트를 기본 설정으로 실행해 추론 토큰 22,276개 + 출력 토큰 3,223개, 총 21분을 기록했습니다. 같은 프롬프트에서 reasoning을 끄자 **3,715개 토큰, 137초(약 2분)**가 걸렸습니다. 무려 6배의 시간과 7배의 토큰 차이입니다 (Simon Willison).

더 황당한 사례도 있습니다. "원을 그려줘"라는 요청에 기본 설정으로 실행하자 몇 분간 사고한 끝에 요청과 무관한 애니메이션 원을 만들어냈습니다. LM Studio의 기본 컨텍스트 8,192 토큰은 단순 작업에 대한 사고만으로 전부 소진됐고, 262,144 전체 컨텍스트로 로드하고 나서야 문제가 해결됐습니다. 속도도 기본 상태에선 LM Studio 기준 15~30 tok/s로, 호스팅 API 대비 체감이 느립니다 (Simon Willison).

같은 패밀리에서 재현한 우리 실측

Qwen3.8-27B는 17GB라 이 글을 쓰는 서버(4코어 CPU, 7.8GB RAM)에서 실행할 수 없었습니다. 그래서 **같은 Qwen 패밀리의 Qwen3.5-4B(Q4_K_M)**를 llama.cpp로 구동해 thinking on/off 차이를 직접 측정했습니다.

측정 환경은 llama.cpp(b10488) + Qwen3.5-4B Q4_K_M, CPU 4코어 전용, temperature 0.3입니다. 결과는 다음과 같습니다.

"1+1은 뭐야?"에 reasoning on으로 실행하자, 모델은 답을 내기 전에 "Thinking Process: 1. Analyze the Request — Input: '1+1은 뭐야?', Intent: basic arithmetic question, Tone: casual..." 식으로 요청을 분석하는 사고 과정을 먼저 출력했습니다. 같은 질문이 53초면 끝날 일을 154초(2분 34초) 동안 붙잡고 있는 것입니다. SVG 프롬프트에서도 reasoning on은 태그 선택부터 스타일까지 계획을 먼저 늘어놓았고(55초), off는 코드 한 덩어리로 바로 끝냈습니다(25초).

측정의 함의는 두 가지입니다. 첫째, overthinking은 특정 모델의 버그가 아니라 Qwen 계열의 설계 기본값이라는 점. 둘째, 토큰 비용의 대부분이 사고 과정에서 발생하므로 reasoning 제어가 로컬 구동의 체감 속도를 좌우한다는 점입니다.

끄는 법과 대안 — 생각을 통제하는 4가지 방법

1. reasoning_effort 낮추기. LM Studio, llama.cpp, Qwen API 모두 reasoning_effort를 지원합니다. 기본 xhigh 대신 low부터 시작하고, 복잡한 작업에만 medium 이상을 쓰는 것이 Simon Willison의 권고입니다: "ignore that default. Run Qwen 3.8 27B on low or even no reasoning levels at first" (Simon Willison).

2. thinking 완전히 끄기. llama.cpp에서는 --reasoning off 플래그 하나로 사고 과정을 제거합니다. 단순 코드 생성, 번역, 포맷팅 같은 작업은 thinking 없이도 충분한 품질이 나옵니다. 이 글의 실측에서 thinking off 실행은 3,715개 토큰으로 끝났습니다 (Simon Willison).

3. MTP 추측 디코딩으로 속도 확보. Qwen3.8은 아키텍처에 MTP(Multi-Token Prediction)가 내장돼 있습니다. llama.cpp에서 llama serve -hf ggml-org/Qwen3.8-27B-GGUF:Q4_K_M -hfd ggml-org/Qwen3.8-27B-GGUF:Q4_0 --spec-default --spec-type draft-mtp --reasoning-preserve로 실행하면 추측 디코딩이 동작해 약 72% 성능 향상이 측정됐습니다 (Simon Willison).

4. preserve_thinking과 컨텍스트 설정. preserve_thinking은 이전 턴의 사고 맥락을 유지해 반복 작업의 재사고를 줄여줍니다. 그리고 로컬에서 돌릴 땐 컨텍스트를 8,192 기본값이 아니라 모델이 지원하는 최대치(262K)로 올려야 사고 토큰이 컨텍스트를 다 먹는 사고를 피할 수 있습니다 (HF 모델 카드).

판단 — 로컬 모델은 "생각하는 기본값"과 싸워야 한다

Qwen3.8-27B는 17GB 파일로 프론티어급 코딩을 하는 인상적인 모델입니다. 다운로드 300만+와 벤치마크 수치가 말해주듯 로컬 LLM의 실용성은 분명히 올라왔습니다. 다만 기본 설정이 xhigh인 것은 소비자 하드웨어 기준으로는 명백한 오버엔지니어링입니다. 벤치마크 점수는 xhigh로 낸 점수이고, 일상 작업에서 그 깊이의 사고가 필요한 경우는 드뭅니다.

표본 한계도 분명히 합니다. 벤치마크 수치는 Qwen 자체 보고이며, 27B 실측은 Simon Willison의 개인 환경(M5 Max, DGX Spark, LM Studio) 기준입니다. 우리 실측은 4B 모델이라 27B와 정확히 같은 수치는 아니지만, 같은 패밀리에서 기본 thinking의 토큰 비용이 얼마나 큰지를 보여줍니다.

실행 체크리스트

• 로컬에서 처음 돌릴 때는 reasoning_effort=low 또는 thinking off로 시작하라. 결과가 부족할 때만 단계를 올려라.
• 복잡한 코드 리팩토링이나 다단계 에이전트 작업에만 xhigh를 써라.
• 컨텍스트를 262,144로 확장하고, 반복 작업에는 preserve_thinking을 켜라.
• 속도가 아쉬우면 MTP 추측 디코딩(--spec-type draft-mtp)을 먼저 시도해보라 — 하드웨어 교체보다 효과가 큽니다.
• 벤치마크 표의 "프론티어급" 수치를 보고 기본값을 믿지 말고, 자기 작업에서 thinking on/off를 한 번씩 비교 측정해보라. 이 글의 실측처럼 수 분 차이가 현실입니다.