클로드 코드 아키텍처를 로컬 9B 모델에 적용: 주요 발견과 최적화

실험 설정 및 핵심 발견

개발자는 RTX 5070 Ti(16GB VRAM)를 사용하여 Ollama(6.6GB)와 OpenClaw 로컬 에이전트 프레임워크를 통해 qwen3.5:9b를 실행했습니다. 18번의 테스트와 10가지 최적화 후, 핵심 발견은 qwen3.5:9b가 기본적으로 구조화된 tool_calls를 지원하는 반면, qwen2.5-coder:14b와 qwen2.5:14b는 적절한 tool_calls 대신 content 필드에 JSON을 넣어 추가 파싱이 필요하다는 점이었습니다.

성능 비교

모델 성능 비교:

• qwen3.5:9b: 기본 tool_calls 구조, 사고 체인 활성화, 39 tok/s
• qwen2.5-coder:14b: 손상된 tool calling(content 필드 내), 사고 체인 없음, ~30 tok/s
• qwen2.5:14b: 손상된 tool calling(content 필드 내), 사고 체인 없음, ~35 tok/s

Claude Code 아키텍처에서 도출한 10가지 최적화

• 구조화된 시스템 프롬프트 → 출력 품질 +600%(A/B 테스트: 4개 문제 발견 vs 25개 이상)
• MicroCompact(도구 결과 압축) → 80-93% 압축, 11KB에서 367자로 감소
• 강제 전환(탐색→생산 강제 전환) → 9B 모델이 출력 없이 파일만 읽으며 갇히는 탐색 루프 해결
• think=false → 8-10배 토큰 효율성, 언어 오염 제거
• ToolSearch 지연 로딩 → 프롬프트 공간 -60%(229 vs 568 토큰)
• 4종류 메모리 시스템(사용자/피드백/프로젝트/참조) → 개인화된 응답
• KV 캐시 포킹 → 단일 GPU에서 미미한 효과(1.1배), vLLM 필요
• 엄격한 쓰기 규칙 → 메모리 업데이트 전 검증, 메모리 손상 방지
• 병렬 부트스트랩 → 콜드 스타트 9% 빠름
• 캐시 브레이크 추적 → Ollama가 동일한 프롬프트 캐싱(182ms→75ms)

핵심 발견: 실제 한계는 자기 절제력

가장 큰 발견은 9B 모델의 실제 한계가 추론 능력이나 도구 사용 정확도가 아니라, 탐색을 멈추고 출력을 시작할 시점을 아는 자기 절제력이라는 점이었습니다. 강제 전환 없이, 모델은 12단계 모두 파일 읽기에 사용하고 0바이트 보고서를 생성했습니다. 강제 전환 적용 시: 5단계 읽기 + 1단계 쓰기 = 6080바이트 구조화된 보고서.

qwen3.5:9b가 실제로 할 수 있는 일

• 800줄 bash 스크립트 읽고 실제 버그 찾기(경쟁 조건, 비원자적 연산) — 2분
• 판매 피드백 시스템 아키텍처 설계 — 8.7KB 문서 2.5분 내
• 완전한 프로젝트 구축(계산기 + 테스트 + 테스트 실행) — 28초
• 10단계 자율 실행: 웹 스크래퍼 작성 → pip 설치 실패 → 해결책 찾기 → 재시도 → 테스트 통과 — 인간 개입 제로
• 전체 미니 팩토리 파이프라인: 검색 → 기사 작성 → 검토 → HTML 게시 — 2.5분

완전한 엔진 성능

10가지 최적화가 단일 Python 엔진(~280줄)으로 패키징되었습니다. 첫 실행 결과:

• 부트스트랩: 527ms(병렬 메모리 + 모델 워밍업)
• 탐색: MicroCompact 적용 5단계 도구 단계(88% 압축)
• 생산: 1947자 구조화된 보고서
• 총계: 39.4초 / API 비용 제로

효과가 없었던 것들

• 단일 GPU에서 KV 캐시 포킹(다중 GPU 또는 vLLM 필요)
• 시스템 프롬프트 내 단계 예산(모델이 자신의 행동에 대한 메타 지시 무시)
• tool calling용 qwen2.5 시리즈(형식 문제)

개발자는 WSL2 + Ubuntu 24.04에서 이를 실행했으며, 더 자세한 내용이나 엔진 코드를 공유할 의향이 있습니다.