Qwen3.6-27B로 2주간 agent orchestration, 실행보다 계획에 강한 이유

LocalLLaMA에 올라온 2주 실험은 local model을 agent 시스템에 넣을 때 어디까지 맡길 수 있는지 꽤 선명하게 보여준다. 작성자는 RTX 3090 24GB 한 장에서 Ollama로 Qwen3.6-27B Q6_K를 돌리고, lead/manager/sub-agent 구조의 multi-agent orchestrator에서 reasoning layer를 Claude 대신 맡겼다고 설명했다. 테스트는 두 개의 실제 repo에서 47개 multi-step coding workflow로 진행됐다.

좋게 나온 영역은 계획과 검토였다. Qwen3.6-27B는 plan generation에서 비교적 일관된 다단계 계획을 만들었고, 몇 차례 prompt 조정 후 schema-valid 비율이 약 95%까지 올라갔다. Mem0 스타일의 memory extraction도 무난했고, 두 번째 Qwen instance로 sub-agent output을 review했을 때 Claude review가 잡은 bug의 약 60%를 잡았다고 한다. 무료 local loop라는 점을 감안하면 충분히 쓸 만한 결과다.

문제는 execution boundary였다. 작성자에 따르면 Qwen3.6의 JSON tool-call output은 47개 작업에서 약 12% format error를 냈다. 단순히 JSON이 깨지는 문제가 아니라 field name, type, 존재하지 않는 tool signature가 틀어지는 식이었다. 같은 workload에서 Claude는 약 0.5%였다고 비교했다. strict output이나 grammar 계열 도구가 줄여주긴 했지만 완전히 없애지는 못했다.

긴 context도 약점으로 남았다. 14k tokens를 넘기면 이전 결정을 잘못 기억하기 시작했고, 실무 한계는 12k tokens 근처로 보고 aggressive summarize-and-reset이 필요했다. sub-agent 실패 후 재계획도 안정적이지 않아, 실패를 성공으로 가정하고 다음 단계를 밀고 가는 cascade failure가 47회 중 3회 있었다.

이 실험의 결론은 local agent를 부정하는 쪽이 아니다. Qwen3.6-27B는 local planning layer로는 가능성이 있지만, 파일 쓰기나 외부 tool 실행을 직접 맡기기에는 gate가 필요하다. plan approval, structured-output enforcement, failure 감지 후 재계획을 시스템 레벨에서 강제해야 한다. LocalLLaMA가 주목한 지점도 “cloud 모델을 당장 끊자”가 아니라, 어떤 경계까지 local model을 믿을 수 있는가라는 실무 질문이다.

Source: Reddit r/LocalLLaMA.