Qwen 3.8-Max enable_thinking 오류

Qwen 3.8-Max enable_thinking 오류가 발생하면 먼저 Qwen Code를 공식 수정이 포함된 v0.20.1 이상으로 올려야 합니다. enable_thinking=false를 설정으로 강제하는 방식은 피해야 하며, 업그레이드 뒤에도 실패하면 주 모델과 측면 조회 모델, 호환 API 경로를 각각 확인해야 합니다. 이 수정은 2026년 7월 21일 병합된 PR에 반영되었고 v0.20.1에 포함되었습니다. (github.com)

이 글은 Qwen Code에서 Qwen 3.8-Max Preview를 주 모델이나 빠른 모델로 사용하다가 HTTP 400을 받은 개발자를 위한 안내입니다. 웹 가져오기, 하위 에이전트, 요약, 권한 분류를 운영하는 AI 에이전트 팀과 격리된 macOS 환경에서 업그레이드 결과를 검증해야 하는 플랫폼 엔지니어에게도 해당합니다.

마지막 업데이트: 2026년 7월 30일. Qwen Code 공식 저장소의 PR, 관련 이슈, v0.20.1 공개 기록을 기준으로 확인했습니다.

먼저 분리해야 하는 오류 신호

대표적인 증상은 일반 대화는 정상인데 웹 가져오기나 권한 분류 단계에서만 다음과 같은 오류가 반복되는 경우입니다.

400 The value of the enable_thinking parameter is restricted to True

Qwen Code 0.20.0에서 qwen3.8-max-preview를 사용한 보고 사례에서는 긴 대화의 문맥 압축, 목표 판단, 권한 분류와 같은 내부 요청이 enable_thinking=false를 보내면서 실패했습니다. 다른 사례에서는 웹 가져오기 자체가 아니라 가져온 내용을 요약하는 측면 조회 단계에서 같은 오류가 발생했습니다. (github.com)

따라서 다음 세 가지를 먼저 저장해야 합니다.

• 전체 오류 문장과 응답 본문
• qwen --version 결과와 설치 경로
• 실제 주 모델, 빠른 모델, 측면 조회 모델의 이름과 API 주소

이 기록이 없으면 API 한도, 네트워크, 인증 토큰, 모델 사용 가능 여부를 같은 문제로 오판하기 쉽습니다.

원인 범위와 수정 상태

Qwen 3.8-Max는 왜 생각 모드를 끌 수 없습니까?

이번 문제의 핵심은 모델 전체의 성능이나 공개 여부가 아닙니다. DashScope 호환 경로에서 Qwen 3.8-Max Preview가 생각 모드를 반드시 켜야 하는 모델로 처리되는데, 이전 Qwen Code가 내부 요청의 비용 절감을 위해 생각 모드를 끄는 매개변수를 추가한 것이 충돌 원인이었습니다.

공식 수정은 특정 모델 이름만 임시로 예외 처리하지 않고, 모델 설정에 생각 모드 필수 여부를 전달하는 방식으로 변경되었습니다. 이 경우 측면 조회에서 enable_thinking=false를 보내지 않으며, 생각 모드에서 거부되는 tool_choice=required도 자동 선택 방식으로 조정합니다. 다른 Qwen 모델과 다른 호환 경로의 기존 동작까지 바꾼다는 의미는 아닙니다. (github.com)

공식 PR에는 수정 전 실제 요청에서 HTTP 400이 발생했고, 수정 후 순수 텍스트 측면 조회와 구조화 요청이 성공하도록 테스트한 내용이 기록되어 있습니다. 다만 이 기록은 Qwen 3.8-Max Preview의 공개 가중치 일정이나 배포 조건을 확인해 주는 자료는 아닙니다. (github.com)

업그레이드 순서

1. 현재 설치 버전 고정

터미널에서 다음 명령으로 실행 파일과 버전을 기록합니다.

which qwen
qwen --version

공식 설치 문서는 macOS에서 독립 설치 스크립트, npm, Homebrew 방식을 제공하므로 설치 방식에 맞춰 업데이트해야 합니다. npm으로 설치했다면 다음과 같이 특정 버전을 명시할 수 있습니다.

npm install -g @qwen-code/[email protected]

설치 방식이 불분명한 상태에서 npm과 Homebrew를 번갈아 실행하면 서로 다른 실행 파일이 호출될 수 있습니다. 공식 저장소의 설치 안내와 v0.20.1 공개 기록을 함께 확인해야 합니다. (github.com)

2. 실제 적용 버전 확인

업데이트 직후 새 터미널을 열고 다시 확인합니다.

which qwen
qwen --version

which qwen 경로가 바뀌지 않았거나 버전이 계속 0.20.0으로 표시되면 새 버전이 설치되지 않은 것이 아니라, 오래된 실행 파일이 먼저 검색되는 상황일 수 있습니다. 이 단계에서 모델 설정을 수정하기보다 실행 파일 경로부터 해결해야 합니다.

3. 실행 중인 세션 종료

기존 Qwen Code 세션을 완전히 닫고 새로 시작합니다. 이전 버전의 프로세스가 남아 있으면 모델 공급자 설정과 측면 조회 생성기 캐시가 계속 유지될 수 있습니다.

공식 수정에는 공급자 설정을 다시 불러올 때 모델별 생성기 캐시를 무효화하는 처리가 포함되어 있습니다. 그래도 업그레이드 직후 같은 오류가 반복되면 터미널 프로세스와 관련된 백그라운드 프로세스를 종료한 뒤 새 세션에서 재현해야 합니다. (github.com)

4. enable_thinking=false 강제 설정 제거

설정 파일이나 사용자 지정 모델 항목에 다음과 같은 내용이 있다면 우선 제거합니다.

{
  "extra_body": {
    "enable_thinking": false
  }
}

Qwen 3.8-Max Preview에서는 이 값을 반대로 true로 덮어쓰는 것보다, Qwen Code가 모델의 필수 생각 모드 정보를 처리하도록 두는 편이 안전합니다. 전역 reasoning: false도 측면 조회 비용을 줄이기 위한 설정이라면 일단 해제하고 기본 동작으로 검증해야 합니다.

Qwen Code에서 enable_thinking=false 400 오류가 나면 어떻게 해야 합니까?

매개변수를 계속 바꾸며 재시도하지 말고, 먼저 v0.20.1 이상인지 확인합니다. 그 다음 사용자 설정에 남은 enable_thinking=false, 모델 별칭, 측면 조회 대상 모델을 순서대로 확인해야 합니다. 공식 수정은 모델별 조건을 구분하도록 설계되었으므로, 무조건 모든 모델에 생각 모드를 켜는 방식은 다른 모델의 동작을 바꿀 수 있습니다. (github.com)

5. 주 모델과 측면 조회 모델 분리

설정에서 다음 항목을 따로 기록합니다.

• 주 대화 모델
• 빠른 모델 또는 측면 조회 모델
• 웹 가져오기와 요약에 사용되는 모델
• API 기본 주소
• 인증 공급자 이름

주 대화와 측면 조회가 같은 모델로 보인다고 해서 실제 요청 경로까지 같은 것은 아닙니다. Qwen Code는 일반 대화, 웹 가져오기 후처리, 권한 분류, 하위 에이전트 생성에 서로 다른 요청 구성 흐름을 사용할 수 있습니다.

실제 모델이 qwen3.8-max-preview인지, 별칭이 다른 모델로 해석되는지 확인합니다. 측면 조회 모델만 오래된 별칭을 참조하면 주 대화가 정상이어도 웹 가져오기만 계속 실패할 수 있습니다.

6. API 경로 확인

DashScope의 일반 호환 경로와 토큰 요금제 호환 경로를 혼동하지 않아야 합니다. 모델 이름이 같아도 공급자 설정과 기본 주소가 다르면 서버의 매개변수 제약이 달라질 수 있습니다.

확인 순서는 다음과 같습니다.

• 설정에 기록된 기본 주소
• 실제 응답의 모델 이름
• 인증 방식과 사용 중인 키
• 주 모델과 측면 조회 모델의 공급자 일치 여부

Qwen Code 공식 문서도 호환 API 공급자별로 생각 모드와 생성 설정을 다르게 처리한다고 설명합니다. 따라서 한 경로에서 성공한 설정을 다른 경로에 그대로 복사하면 안 됩니다. (github.com)

기능별 복구 확인

일반 텍스트 요청이 성공했다고 복구가 끝난 것은 아닙니다. 다음 순서로 기능을 나눠 확인합니다.

• [ ] 짧은 일반 대화가 성공합니다.
• [ ] 웹 가져오기에서 페이지 내용을 반환합니다.
• [ ] 가져온 내용의 측면 요약이 성공합니다.
• [ ] 구조화 응답이나 도구 호출이 성공합니다.
• [ ] 하위 에이전트가 별도 오류 없이 실행됩니다.
• [ ] 긴 대화에서 문맥 압축이 실행됩니다.
• [ ] 권한 분류 또는 자동 모드 판단이 정상 동작합니다.

업그레이드 후 측면 조회가 복구되었는지 어떻게 확인합니까?

같은 프롬프트를 반복하는 대신 요청 유형별로 성공 여부와 오류 범주를 기록해야 합니다. 웹 가져오기는 주소를 읽는 단계와 결과를 요약하는 단계가 다를 수 있고, 구조화 호출은 생각 모드와 강제 도구 선택의 조합에서 별도 오류가 날 수 있습니다.

공식 PR의 검증 범위도 순수 텍스트 측면 조회와 구조화 측면 조회를 분리합니다. 수정 후에는 생각 모드를 유지한 텍스트 요청이 성공하고, 구조화 요청은 강제 도구 선택 없이 유효한 결과를 반환하는지 확인해야 합니다. (github.com)

Qwen 3.8-Max의 웹 가져오기와 하위 에이전트가 함께 실패하는 이유는 무엇입니까?

두 기능이 같은 서버 기능을 호출해서가 아니라, 내부 요청에서 공통 생성기 설정을 사용할 수 있기 때문입니다. 이전 버전에서는 웹 가져오기 후처리, 권한 분류, 하위 에이전트 생성이 생각 모드를 끄는 경로를 공유하면서 같은 400 오류가 나타날 수 있었습니다. 관련 이슈에서도 웹 가져오기 실패가 실제 페이지 접근보다 내부 측면 조회의 매개변수 충돌에서 발생한 것으로 보고되었습니다. (github.com)

분리 환경과 되돌리기 기록

프로젝트 설정이 복잡하면 기존 환경에서 곧바로 원인을 단정하지 않는 편이 좋습니다. 업그레이드 전후에 다음 표를 복사해 기록하면 클라이언트 문제와 프로젝트 설정 오염을 구분하기 쉽습니다.

기존 프로젝트에 환경 변수, 사용자 설정, 여러 공급자 항목이 겹쳐 있으면 깨끗한 임시 macOS 환경에서 같은 모델과 API 경로만 구성해 재현합니다. 격리 테스트가 필요하다면 ZilCloud의 원격 Mac 환경에서 새 작업 공간을 만들고, 프로젝트 파일을 옮기기 전에 Qwen Code 버전과 모델 호출만 먼저 검증하는 방식이 적합합니다. 환경 격리와 자동화 작업을 함께 시험하는 경우에는 macOS 샌드박스 시작 안내도 참고할 수 있습니다.

새 환경에서 v0.20.1 이상이 정상 동작하면 기존 프로젝트의 설정 충돌 가능성이 커집니다. 새 환경에서도 같은 400이 발생하면 모델 이름, API 경로, 설치된 Qwen Code 버전을 다시 대조하고 공식 이슈가 재개되었는지 확인해야 합니다.

현재 환경과 원격 Mac 선택

개인 Mac에서 계속 수정하는 방식은 추가 설정을 확인하기 어렵고, 여러 개발자가 같은 재현 조건을 공유하기도 힘듭니다. 특히 오래된 실행 파일이 남아 있거나, 사용자 설정과 프로젝트 설정이 겹치거나, API 경로가 팀원마다 다르면 실패 원인을 다시 만들기 어렵습니다.

반면 ZilCloud의 원격 Mac은 짧은 기간 동안 깨끗한 macOS 환경을 만들어 업그레이드 전후를 비교하기 쉽고, 기존 프로젝트와 분리된 상태에서 Qwen Code와 도구 호출을 검증할 수 있습니다. 장기적으로 고정된 무거운 작업이나 물리 장치 연결이 필요한 경우에는 직접 보유한 Mac이 더 적합하지만, 이번처럼 클라이언트 버전과 API 호환성을 확인하는 임시 작업이라면 격리된 원격 Mac이 시행착오를 줄이는 선택이 될 수 있습니다. 필요한 경우 ZilCloud 요금과 이용 방식을 확인해 테스트 기간과 환경을 먼저 계산하는 편이 안전합니다.