로컬 Qwen은 더 나쁜 Opus가 아니라 다른 도구다

• OpenFaaS·SlicerVM 등을 운영하는 소규모 팀은 로컬 Qwen이 Claude Opus를 대체하지는 못해도, 고객 데이터와 내부 텔레메트리처럼 클라우드에 올리기 어려운 작업에서 가치를 냈다고 봄
• 로컬 모델의 강점은 최고 성능 모델과의 점수 경쟁보다 고정 비용, 개인정보 보호, 벤더 리스크 완화에 있으며, 무거운 사용량과 SaaS 내부 기능에서 특히 차이가 남
• Qwen 3.6 27B는 SWE-Bench Verified에서 77.2를 기록해 Claude Opus 4.8의 88.6%와 비교되지만, Python 벤치마크와 Go 기반 분산 시스템 작업 사이에는 업무 적합성 차이가 큼
• 약 12,000달러에 구매한 RTX 6000 Pro Blackwell 96GB 장비는 고객 라이선스 과소 보고를 찾아낸 매출 회수 사례만으로 비용을 회수함
• 가장 큰 한계는 긴 작업에서 반복 출력과 환각이 생기는 루프 문제이며, 로컬 Qwen은 장기 무감독 코딩보다 고객 지원, 좁은 유지보수, 코드베이스 읽기와 설명에 더 적합함

로컬 Qwen을 쓰는 실제 환경

• OpenFaaS에서 시작한 소규모 팀은 현재 OpenFaaS, SlicerVM, Actuated.com, Inlets.com을 유지함
• 제품군은 컨테이너, Firecracker microVM, 네트워크 프로토콜, 터널, CLI, Kubernetes 같은 저수준 인프라와 Linux 기본 요소를 중심으로 함
• 코드베이스는 Go가 중심이고, 일부 React UI, 랜딩 페이지, 문서, 에이전트 스킬, CLI도 포함함
• 팀의 코딩 작업 대부분은 Claude와 Codex가 맡고, 글쓰기는 직접 유지하지만 코드는 거의 손으로 작성하지 않는 흐름으로 바뀜
• tmux에서 장시간 작업하는 흐름을 관리하려고 Superterm.dev를 만들었고, 세션·노트 관리와 코딩 에이전트의 시각적 피드백에 사용함

최고 성능 모델과 로컬 모델의 거리

• 2025년 11월부터 2026년 1월 사이 Claude Opus가 개발자 작업 전체를 수행할 수 있다는 인식이 커졌고, 고급 코딩 플랜 비용은 개인 기준 약 월 200달러 수준으로 자리 잡음
• 선도 모델은 0.5~2T 파라미터로 추정되며, 로컬 하드웨어에서 쓰는 모델보다 단순히 몇 배 큰 수준이 아니라 다른 규모임
• Qwen 3.6 27B는 SWE-Bench Verified에서 77.2를 기록했고, Claude Opus 4.8은 88.6%임
• SWE-Bench Verified는 여러 오픈소스 프로젝트의 Python 이슈를 기반으로 하지만, 이 팀의 실제 작업은 Go 분산 시스템, 채널, 컨텍스트, 구조체가 넓은 실행 영역에 걸친 형태임
• 벤치마크 점수만 보고 “로컬이 SOTA보다 12% 뒤처진다”고 보기 어렵고, 실제 업무에서는 언어와 시스템 특성이 성패를 크게 좌우함

비용, 개인정보, 벤더 리스크

• “로컬 모델은 비용 문제가 아니다”라는 말은 모든 사용자에게 맞지 않음
• 개인용 코딩 플랜은 월 200달러로 높은 사용량과 SOTA 수준의 지능을 제공하지만, 코딩 플랜 자체는 보조금을 받는 구조로 보임
• GitHub Copilot은 월 39달러에 1,500개 요청을 제공하던 구조에서 토큰 기반 과금으로 전환했고, 이에 대한 반발이 컸음
• API 토큰 비용으로 과금되면 손익분기점은 빨리 올 수 있음
  • Uber는 개발자당 도구별 월 1,500달러로 AI 지출을 제한함
  • Uber의 중위 연봉 330,000달러 기준, 개발자가 두 도구를 한도까지 쓰면 연봉의 약 12%에 해당함
• 고객 데이터와 계약 조건 때문에 클라우드 플랜에 데이터를 올리기 어려운 경우가 있음
  • ChatGPT Pro와 Claude Max는 30일 보관 기간으로 설정할 수 있지만, 그 수준도 고객 계약을 무효화할 가능성이 있다고 봄
  • 미국 밖 사용자에게 Anthropic의 Fable 5 모델이 하룻밤 사이 제거된 사례는 벤더 리스크로 작용함

RTX 6000 Pro 장비와 로컬 운영

• 2023년에는 RTX 3090 한 장으로 시작했지만, 모델과 충분한 컨텍스트를 올리려면 두 번째 카드가 필요했음
• Qwen 3.5는 에이전트로 실제 작업을 수행한 첫 모델로 평가됨
• RTX 3090에서는 Q4 양자화와 200k 컨텍스트로 작은 작업은 가능했지만, 지시 범위가 너무 넓으면 모든 파일을 읽고 컨텍스트를 채운 뒤 파일명과 도구 호출을 환각함
  • ~/faas-netes가 ~/faaned로 바뀌는 사례가 있었음
  • 작업 범위를 “빠르게 둘러보고 누가 무엇에 쓰는지 알려달라”로 좁히면 약 40~50 tokens/s 생성 속도로 명확한 보고서를 얻음
• 27B 모델은 3090 한 장에 완전한 품질로 올리기 어려워 모델 가중치 양자화, 컨텍스트 길이, KV 캐시의 키·값 압축을 조정해야 함
• vLLM도 테스트했지만 같은 구성에서 llama.cpp보다 생성 속도가 3 tokens/s 느렸고, 가중치 로딩에는 몇 분이 걸림
  • vLLM은 연속 배치와 다수 동시 사용자에 적합함
  • 이 팀의 프로슈머 환경에서는 전체 처리량보다 시작 시간, 단순성, 단일 사용자 지연 시간이 더 중요함

장비 비용을 회수한 고객 지원·갱신 사례

• 약 12,000달러를 들여 96GB VRAM의 RTX 6000 Pro Blackwell을 구매했고, 몇 달 뒤 가격은 약 15,400달러까지 올랐음
• 이 장비는 Claude 구독을 대체하지 못하지만, 고객 지원과 갱신 업무에서는 비용을 회수함
• 팀은 Kubernetes 위 OpenFaaS 설치 상태를 캡처하는 diag CLI를 만들었고, 고객이 덤프를 보내면 Slicer가 만든 임시 VM 안의 air-gapped 로컬 모델로 분석함
• Introducing: Painless support and hands-off architecture reviews에는 이 방식으로 찾은 문제들이 정리돼 있음
• 한 갱신 건에서는 텔레메트리 데이터베이스를 로컬 모델에 넣어 고객이 12개월 넘게 라이선스를 약 4~5배 과소 보고하고 과소 지불했다는 점을 찾아냄
• 초기 모델은 산술과 해석에서 실수도 냈음
  • 27.3K를 273,000으로 계산한 사례가 있음
  • 함수 수가 적다는 이유로 이탈 가능성을 추론했지만, 해당 고객이 적은 수의 함수를 하루에 여러 번 실행한다는 점을 놓침
• 이런 경험 때문에 로컬 모델은 최종 해석보다 분석 보조에 집중시키는 편이 낫다고 판단함

현재 Qwen 구성

• 팀은 RTX 6000 장비에서 최신 Qwopus와 기본 Qwen 3.6 27B를 함께 실행함
• Qwopus는 Qwen 위에 Chain of Thought 추적을 얹어 추론과 코딩 성능을 높이려는 파인튜닝 모델임
• 모델은 두 개의 독립적인 llama.cpp 인스턴스로 제공해 전체 컨텍스트 길이를 유지함
  • --parallel 2는 동시성을 주지만 사용 가능한 컨텍스트를 절반으로 줄임
• llama.cpp는 Nvidia GPU 지원을 위해 소스에서 빌드하고, 매주 또는 필요할 때 최신 상태로 유지함
• 단일 Qwen 인스턴스 설정은 262,144 컨텍스트, f16 KV 캐시, Flash Attention, reasoning budget 2048, temperature 0.6, MTP speculative decoding 등을 사용함
• MTP 기반 speculative decoding은 약 93% 수락률을 보였고, 속도는 안정적인 67 tok/s에서 장시간 130~200 tok/s로 늘어남
• 모델 카드의 튜닝 지침을 따르는 것이 중요함
  • Qwopus 파인튜닝 모델은 thinking을 끄고 temperature를 0.85~1.0으로 높였을 때 가장 잘 동작함

반복 출력과 장기 작업의 한계

• Qwen의 가장 큰 문제는 긴 범위 작업에서 루프에 빠지는 현상임
• faas-cli에 추가할 명령을 묻자 처음에는 합리적인 제안을 했지만, 같은 명령 목록을 반복 출력하며 약 30분 동안 600W 전력을 사용함
• get과 list 명령 전체에 --json을 추가하게 했을 때도 처음 한두 개는 그럴듯했고 테스트도 작성했지만, 이후 문제가 커짐
• --json 출력에서 http:// 원격 엔드포인트의 insecure TLS 경고를 막기 위해 Python reverse proxy를 쓰게 했을 때 첫 버전은 그럴듯했지만 들여쓰기가 잘못됐고, 수정 과정에서 파일을 망가뜨린 뒤 계속 막힌 상태로 반복함
• 팀원 Han도 비슷한 루프를 겪었고, 특히 모델이나 에이전트가 능력의 경계에서 멈춰 도움을 요청하지 않는 형태가 많았음
• 이 문제 때문에 로컬 Qwen은 고객 지원과 갱신용 텔레메트리·diag 분석을 제외하고는 쉽게 신뢰하기 어려움

팀 배포와 운영 문제

• 처음에는 inlets 터널 하나로 접근하게 했지만, 두 에이전트가 같은 llama.cpp 인스턴스에 서로 다른 컨텍스트로 접근하면 각 요청이 상대의 캐시된 prefix를 무효화해 전체 프롬프트를 다시 처리함
• 팀 사용자가 늘어나면 모델 운영은 단순 실험이 아니라 운영 문제가 됨
  • 누가 어떤 llama.cpp 인스턴스를 쓰는지
  • 얼마나 쓰는지
  • 어떤 모델을 쓰는지
  • 전기 비용이 얼마인지
  • 팀원이 떠나면 접근을 어떻게 정리할지
  • 새 모델을 어떻게 추가할지
• 이를 위해 opencode용 provider를 만들었고, opencode 모델 선택기에서 toilgate와 사용할 모델을 고르는 방식으로 전환함
• Shelly Plus Plug 두 개로 벽면 전력 소비를 측정함
  • RTX 6000 Pro는 추론 중 600W를 사용하고 비교적 조용함
  • 두 장의 3090은 합쳐 약 750W를 사용하고 매우 시끄러움
• 로컬 AI는 토큰당 비용 비교로 끝나지 않고, 클라우드 모델에 맞지 않는 작업을 위해 신원, 접근 제어, 계량, 할당량, 모델 라우팅, 전력 모니터링을 관리하는 일이 됨

실제로 도움이 된 사용 패턴

• 로컬 모델과 하네스를 전문화된 작업에 맞추는 것이 중요함
  • 고객 지원
  • 범위가 잘 정해진 유지보수
  • 엔드투엔드 테스트
• AGENTS.md에 상세 지침을 추가하면 로컬 모델이 새 CLI를 더 빠르고 효율적으로 추가하고 직접 테스트할 수 있었음
  • alexellis/arkade에서 이런 효과를 봄
• 로컬 모델은 코드를 직접 쓰는 데 한계가 있어도 코드베이스를 빠르게 읽고 설명하는 데 강점이 있음
• Agent Skills도 도움이 됐고, 로컬 에이전트가 새 mini PC에서 Slicer를 처음부터 설정한 사례가 있음
• 같은 작업을 로컬 모델과 클라우드 모델에 모두 실행해보는 방식을 일반화할 필요가 있음
  • 동일 작업 비교 사례처럼 결과가 실망스러울 때도 있고 운이 좋다고 느낄 때도 있음
• 긴 범위의 무감독 에이전트 작업은 피해야 하며, 약 15,000달러에 가까운 장비도 이 문제를 해결하지 못함

현재 결론과 모델 선택의 한계

• 로컬 Qwen은 “Opus 수준에 가깝다”기보다 특정 작업과 워크플로에서 가치가 있는 다른 도구임
• Qwen 3.5는 사용할 만한 결과를 낸 첫 모델로 평가되며, 3.7 루머가 있지만 혁명적 변화보다는 반복 개선을 기대함
• 70B 모델은 대부분 오래됐고 세대가 뒤처졌다고 봄
• Qwen 35-A3B는 MacBook에서 빨라 보여 인기가 있지만, 생성 시 활성 파라미터가 3B뿐이어서 속도보다 품질을 택하겠다는 입장임
• GLM 5.2, Kimi 2.7, Minimax M3, Deepseek V4 Flash 같은 더 큰 모델은 일부 로컬 장비에서 가능하지만, 양자화 버전조차 로드하려면 RTX 6000 Pro 4~6장이 필요한 경우가 많아 범위 밖임
• 현재 27B dense 모델은 하루 종일 Go 코드를 작성하기에는 부족하고, 제한된 지식과 주의력이 코드 리뷰에서 곧바로 드러남
• Qwen은 간결하게 하라는 지시를 잘 따르지 못하고 자동 코드 리뷰에서 불필요하게 자세한 내용을 쓰거나 동시성 이슈와 race condition을 환각해 실험이 빠르게 중단됨
• 더 저렴하고 빠른 Grok Coder Fast 1은 deprecated되기 전까지 몇 달간 잘 동작함
• 관련 사례는 code review bot과 OpenFaaS의 painless customer support and architecture review에 정리돼 있음