코딩 테스트: Qwen3.8 27B Q8 vs Qwen3.6 27B BF16 비교

지난번 글(https://www.reddit.com/r/LocalLLaMA/comments/1vldngi/tested_in_coding_bf16_muse_glimmer_vs_bf16_qwen36/)에 이어서, 요청받았던 Qwen3.8 27B 비교 분석 가져왔다.

상황: 두 모델 모두 풀 FP16 KV-캐시로 돌렸다. 램 용량 한계 때문에 BF16 Qwen3.6은 150,000 컨텍스트로, Q8 Qwen3.8은 공식 Qwen 가이드에 따라 rope-scale 1.4를 적용해서 367,001 컨텍스트로 돌렸음. 대충 900페이지 분량이다.

Qwen3.6은 기본 추론 설정, Qwen3.8은 xhigh 설정으로 돌림.

두 모델 다 기업용 웹 애플리케이션 작업에 투입했다. Qwen 3.6은 평균 컨텍스트 120,000 정도일 때 작업했고, 지금은 작업량이 늘어서 평균 280,000 컨텍스트 수준임. Qwen3.8 출시 이후로 하루 6시간 넘게 코딩 작업만 시켰다.

세 줄 요약: Muse Glimmer는 코딩용으로는 완전히 퇴물이다. Q8 Qwen3.8은 아래에서 언급할 치명적인 단점 하나를 제외하면 모든 면에서 BF16 Qwen3.6보다 압도적으로 강하다.

지시사항 이행 (Instructions)

Qwen3.8의 가장 큰 강점은 지시사항을 읽고, 해석하고, 기억해서 그대로 따라 하는 능력이다. 이번 모델 나오자마자 Qwen3.6에서 쓰던 개선 사항 20페이지 분량을 Qwen3.8로 옮겨봤다.

Qwen3.6은 이 개선 사항들을 자주 씹었는데, Qwen3.8은 하나도 안 빼놓고 다 기억한다. 심지어 사고 과정에서 자기가 개선 사항을 어떻게 적용할지 언급까지 함. 다만 한 가지, 매 라운드마다 첫 번째 시도에서는 지시사항을 가끔 틀리는데, 바로 스스로 수정해서 나머지 라운드를 끝내는 식이다.

진단 (Diagnostic)

Qwen3.6도 진단 능력은 좋았는데, 문제 해결한다고 보안 설정을 멋대로 풀거나, 실패한 테스트를 통과시키려고 인수 조건(Acceptance Criteria)을 지 맘대로 수정하는 등 무결성 문제가 심각했다.

Qwen3.8은 진단 능력이 더 세졌다. 심지어 챗GPT나 오퍼스 같은 프론티어 모델들이 틀린 걸 여러 번 잡아내기도 함.

둘 다 진단은 진짜 잘하는데, 공통적으로 보고하기 전에 기준점이나 진단 스크립트 결과랑 대조해서 검증하는 걸 안 한다. 그래도 Qwen3.8은 이 문제가 좀 덜한 편임.

추적 (Tracing)

이게 Qwen3.8의 가장 확실한 강점이고, 증거도 차고 넘친다. 몇 달 동안 아무도 못 찾았던 진짜 버그들을 잡아냈고, 심지어 QA 테스트가 몇 달 동안 조용히 실패하게 만들었던 환경 설정 오류까지 찾아냄.

Qwen3.8의 단점은 추적 효율성이다. 결국엔 거의 모든 경우에 정답을 찾아내긴 하는데, 처음 진단할 때 헛다리 짚는 가설을 너무 많이 세운다. 추적 과정에서 자꾸 "옆길로 새는" 경향이 있어서 조사 시간이 생각보다 훨씬 오래 걸림. 레딧 다른 애들은 이걸 보고 "생각을 너무 많이 한다"고 하던데, 확실히 엄청 꼼꼼하긴 하다.

코딩 (Coding)

구현 범위가 좁을 때조차 Qwen3.6은 수정 범위를 너무 넓게 잡는 경향이 있었다. 결국 QA에서 걸리고 나서야 수정하고 다시는 안 틀리는 식이었음. 즉, Qwen3.6은 코딩 범위를 너무 일반화해서 에이전트 테스트 프레임워크가 결함을 찾아내게끔 떠넘기는 경향이 있었다. 만약 프레임워크가 못 잡아내면 코드 곳곳에 결함이 박히는 거임. 이게 실제로 꽤 자주 일어났다.

Qwen3.8은 생각을 훨씬 많이 한다. 간단한 함수 하나 짤 때도 코드베이스 전체를 5번 넘게 독자적으로 체크함. 시간은 훨씬 오래 걸리는데, 자체 검증하는 습관이 잡혀 있어서 내부적으로 결함을 잡아내는 신뢰도가 훨씬 높다.