멀티 에이전트 오케스트레이터에서 Claude를 로컬 Qwen3.6-27B로 2주간 교체해 본 후기

2주 동안 내 멀티 에이전트 오케스트레이터를 3090 한 장 꽂고 Ollama로 Qwen3.6-27B만 돌려봤다.

목표는 간단함. 로컬 모델이 리드/매니저/서브 에이전트 루프에서 Claude를 대체할 수 있는 추론 레이어가 될 수 있는지 확인하는 거였다. 어디서 잘 돌아가고 어디서 박살 났는지 정리해 본다.

세팅:

• RTX 3090, 24GB VRAM

• Qwen3.6-27B (Q6_K, GPU에 약 22GB 점유), 유효 컨텍스트 32k

• 추론 엔진으로 Ollama 사용

• 구조화된 JSON 플랜, 플랜 승인 모달, 서브 에이전트 작업 완료 후 자동 리뷰 패스가 포함된 멀티 에이전트 오케스트레이터

• 실제 레포지토리 2개에서 47개의 다단계 코딩 워크플로우로 테스트

잘 된 점 (추론 레이어):

• 플랜 생성. Qwen3.6이 이 작업들에서 Claude만큼이나 다단계 플랜을 잘 짜더라. 좀 더 보수적이긴 함(지들이 알아서 "X도 리팩토링할게요" 같은 짓을 덜 함). 프롬프트 몇 번 수정하니까 95% 확률로 일관성 있고 스키마도 잘 맞췄음. 나머지 5%는 재질문 한 번 날리면 해결되는 수준.

• 메모리 추출. 6턴마다 Mem0 스타일로 팩트 추출하는 것도 잘 돌아감. Claude가 뽑아내는 거랑 똑같은 수준으로 팩트를 잘 뽑아내서("사용자는 '왜'를 설명하지 않는 한 주석 다는 걸 싫어함") Qdrant에 깔끔하게 저장함.

• 서브 에이전트 결과물 자동 리뷰. Qwen 인스턴스 하나 더 띄워서 첫 번째 놈이 짠 코드 리뷰 시켰는데, Claude가 똑같은 작업에서 잡아낸 버그의 60% 정도를 잡아냄. Claude보다 덜 매섭긴 한데, 그래도 공짜로 이 정도면 쓸만함.

박살 난 점:

• 툴 호출 신뢰성. 47개 작업 돌리는 동안 Qwen3.6의 JSON 툴 호출 출력 에러율이 12% 정도 됨. Claude는 같은 작업에서 0.5% 수준이었는데. 에러가 JSON 형식이 깨지는 게 아니라, 필드 이름을 틀리거나, 타입을 잘못 쓰거나, 아예 없는 툴 시그니처를 환각으로 만들어냄. Outlines나 strict-output 모드 써도 줄어들긴 하는데 완전히 해결은 안 됨.

• 긴 컨텍스트에서의 드리프트. 세션 컨텍스트가 14k 토큰 넘어가기 시작하면, Qwen이 지가 아까 내린 결정도 까먹음 ("Postgres 쓰라고 했잖아" -> "아니, 반대로 말했음"). 실질적인 한계는 12k 토큰 정도고, 그 이후엔 빡세게 요약하고 리셋해야 함.

• 연쇄 실패 처리. 서브 에이전트가 뻗으면 Claude의 플래너는 보통 그걸 알아채고 플랜을 다시 짜는데, Qwen은 가끔 서브 에이전트가 성공했다고 치고 다음 단계로 넘어가 버림. 47번 돌리는 동안 연쇄 환각 3번 발생. 플랜 게이팅(검증)을 걸어놔서 대참사는 면했지만, 그거 없었으면 바로 좆될 뻔함.

반골의 시각: Qwen3.6-27B는 지금 당장 로컬 멀티 에이전트 시스템의 추론 레이어로 쓸만함. 근데 실행 레이어로는 절대 아님. 플랜 짜는 용도로만 쓰고, 툴 호출은 무조건 검증 거쳐라.

실질적인 결론: 로컬 전용 에이전트를 만들 거라면 (1) 툴 호출 경계에서 구조화된 출력 강제(outlines, lm-format-enforcer, 혹은 추론 엔진의 그래마 모드 사용), (2) 12%의 형식 에러가 실제 파일 쓰기로 이어지지 않게 플랜 승인 게이팅 필수, (3) 모델 스스로는 믿을 수 없으니 실패 시 재플랜 로직을 따로 짜야 함.

12%의 툴 호출 격차를 줄이는 게 핵심이다. Qwen3.6(혹은 다음 로컬 모델)이 이 수치를 2%대까지 낮추면, 에이전트 루프에서 클라우드 추론을 쓸 이유가 빠르게 사라질 거다.

공개: 이 테스트에 쓴 오케스트레이터는 OpenYabby(openyabby.com)임. 내가 만든 거다. Anthropic에 돈 갖다 바치는 거 그만하고 싶어서 진짜 솔직하게 테스트해 봄.