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

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

AI 활용 배경과 사업 맥락

• OpenFaaS를 시작으로 SlicerVM, Actuated, Inlets 등 저수준 인프라·Linux 프리미티브 중심 제품을 소규모 팀이 운영하고 있음
  • 컨테이너, Firecracker microVM, 네트워크 프로토콜, 터널, CLI, Kubernetes 기반이며 주로 Go로 작성, 일부 React UI 포함
• VS Code 탭 자동완성 시절부터 AI 도구를 사용해 왔고, 현재 코드 대부분은 Claude 또는 Codex가 수행, 손코딩은 거의 하지 않음
• tmux에서 장시간 작업하는 흐름을 관리하려고 Superterm.dev를 만들었고, 세션·노트 관리와 코딩 에이전트의 시각적 피드백에 사용함

프런티어 지능의 전환점

• 2025년 11월~2026년 1월 사이 전환점 발생, X에서 다수 개발자가 Claude Opus가 자기 작업 전부를 처리 가능하다고 평가
• 최상위 코딩 플랜 비용은 개인 기준 월 약 200 USD로 안착, 과도한 무감독 작업만 피하면 5시간·주간 한도 내 사용 가능

로컬 모델이 흥미로운 이유

• 2026년은 누구든 구독 하나로 아이디어를 하룻밤에 복제 가능한 시대, SlicerVM과 Superterm도 클론 사례 경험
  • 소프트웨어 비용이 0에 수렴하는 시장에서 "무료이면서 충분히 좋음"이 핵심이 될 수 있음
• 선도 모델은 0.5~2T 파라미터로 추정, 로컬 하드웨어 최상급과는 차원이 다른 규모임

• 벤치맥싱 (Benchmaxxing)

  • 벤치마크는 공개돼 있어 점수를 높이도록 튜닝 가능, 절대 지표로 신뢰하기 어려움
  • SWE-Bench Verified는 Python 이슈 기반이나 대부분 코드가 단일 스레드·동기식, 반면 Go 분산 시스템은 channel·context·struct가 큰 실행 영역에 걸쳐있음
  • 벤치마크 점수만 보고 “로컬이 SOTA보다 12% 뒤처진다”고 보기 어렵고, 실제 업무에서는 언어와 시스템 특성이 성패를 크게 좌우함

• 비용 (Cost)

  • “로컬 모델은 비용 문제가 아니다”라는 말은 모든 사용자에게 맞지 않음
  • 개인용 코딩 플랜은 월 200달러로 높은 사용량과 SOTA 수준의 지능을 제공하지만, 코딩 플랜 자체는 보조금(subsidised)을 받는 구조로 보임
  • GitHub Copilot은 월 39달러에 1,500개 요청을 제공하던 구조에서 토큰 기반 과금으로 전환했고, 이에 대한 반발이 컸음
  • API 토큰 비용으로 과금되면 손익분기점은 빨리 올 수 있음
    • Uber는 개발자당 도구별 월 1,500달러로 AI 지출을 제한함
    • Uber의 중위 연봉 330,000달러 기준, 개발자가 두 도구를 한도까지 쓰면 연봉의 약 12%에 해당함
  • 대량 사용·루프·에이전트 분석·SaaS 내장 기능에서는 open weight·로컬 모델이 상당한 가치 제공

• 주권과 프라이버시 (Sovereignty and privacy)

  • 고객 데이터와 계약 조건 때문에 클라우드 플랜에 데이터를 올리기 어려운 경우가 있음
  • ChatGPT Pro와 Claude Max는 30일 보관 기간으로 설정할 수 있지만, 그 수준도 고객 계약을 무효화할 가능성이 있다고 봄
  • 미국 밖 사용자에게 Anthropic의 Fable 5 모델이 하룻밤 사이 제거된 사례는 벤더 리스크로 작용함
  • 로컬 모델은 "프런티어 랩이 X를 한다면?"에 대한 해법임

칼날 단조 비유 — 로컬 모델의 본질

• 강철 열처리에서 한 단계만 지나치면 처음부터 다시 해야 하듯, 로컬 모델도 너무 뜨겁게 작동하면 목표를 지나쳐 루프에 빠짐
  • 유일한 해결책은 harness를 종료하고 비워진 context로 다른 결과를 기대하는 것
• 칼날 단조를 무감독 방치하지 않듯, Qwen 3.6 27B에 장기 horizon 작업을 맡기지 않음

• 내가 찾던 것 (What I was looking for)

  • 목표는 프라이버시, 고정 비용, 벤더 리스크 방어
  • 로컬 모델을 Claude·Codex와 동일하게 다룰 때 실망 발생
  • Claude는 짧은 지시("do it and test it end to end")만으로 5~15분 내 PR 작성·자동 코드 리뷰·반복까지 효율적 루프 수행

3090에서 얻은 교훈

• 2023년 단일 3090으로 시작, 모델 로드와 충분한 context를 위해 한 장 추가 필요
  • Qwen 3.5가 에이전트로 실제 작업이 되는 것을 처음 본 시점
• "기계를 모든 각도에서 탐색해 포렌식 보고서 작성" 지시 시, 모든 파일을 하나씩 읽다 context를 채우고 파일명·tool call을 환각(~/faas-netes→~/faaned)
  • 작업 범위를 좁혀 "간단히 둘러보라"고 하자 약 40~50 tok/s로 명료한 보고서 생성
• 27B 모델은 3090 한 장에 풀 정밀도로 들어가지 않아, 조절 변수는 가중치 양자화·context 길이·KV 캐시 압축
  • KV 캐시 keys 부분은 Q4_0에서 문제 발생이 통설, 가장 공격적으로도 keys Q8_0 / values Q4_0까지만 사용
• vLLM + NVLink + tensor parallelism 실험에서도 생성 속도가 llama.cpp보다 초당 3토큰 느렸고, 루프 발생·가중치 로딩 수 분 소요
  • vLLM은 대규모 동시 서빙에 적합하나, 프로슈머 환경에서는 시작 시간·단순성·단일 사용자 지연이 더 중요

큰 지출 — RTX 6000 Pro 도입

• 고객 지원 티켓의 신속 해결을 위해 약 12,000 USD의 RTX 6000 Pro Blackwell(96GB VRAM) 구매
  • 이후 가격이 약 15,400 USD로 상승해 두 번째 카드 추가는 어려움
  • PCI 레인·대역폭·카드 간격·PSU 부하 등으로 소비자 머신에 단순 추가 불가
• 계산된 베팅으로 성과를 냈으나, Claude 구독을 대체하지는 못함

데이터 유출 없는 손쉬운 고객 지원

• 운영자가 쉽게 실행 가능한 CLI 도구 "diag"를 제작, OpenFaaS Kubernetes 설치의 완전한 스냅샷을 캡처
  • 받은 덤프를 Slicer가 생성한 ephemeral VM 내 airgapped 로컬 모델로 분석

• 매출 회수 (Revenue recovery)

  • 텔레메트리 DB를 로컬 모델에 투입해 한 고객의 12개월 이상 라이선스 과소 신고·4~5배 미납을 적발, 이 회수만으로 카드 비용 충당
  • 텔레메트리·diag 덤프는 데이터 보존 정책과 무관하게 어떤 클라우드 플랜에도 넣지 않음
  • ChatGPT Pro·Claude Max는 30일 보존 설정 가능하나, 그 수준도 고객 계약을 무효화할 소지
  • 초기 모델은 산술 실패(27.3K를 273,000으로 계산), 함수 수가 적다는 이유로 잦은 실행을 무시하고 이탈 가능성으로 오판
  • 결론적으로 해석보다 분석에 집중시키는 편이 나음

현재 셋업

• RTX 6000 rig에서 Qwopus 최신 세대와 base Qwen 3.6 27B를 함께 운영, 신규 finetune·포인트 릴리스에 따라 변경
  • Qwopus는 Qwen 위에 Chain of Thought 추적을 얹어 추론과 코딩 성능을 높이려는 파인튜닝 모델임
  • 최근까지 thinking을 완전히 끄고 운영, 다시 켠 시점이 루프 증가와 겹침
• 두 개의 독립 llama.cpp 인스턴스로 서빙해 풀 context 길이 유지, --parallel 2는 context를 절반으로 줄임
• 투기적 디코딩(MTP)에서 약 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가 상호 무효화돼 전체 프롬프트 재처리 발생
• 여러 사람이 사용하면 프로토타입을 벗어남, 누가 어느 인스턴스를·얼마나·어떤 모델을 쓰는지, 전력 비용, 이탈 시 처리 등 관리 문제 발생
• opencode.json 수동 편집·배포 대신 opencode용 provider "Toilgate" 를 작성, 모델 피커에서 base부터 실험적 Qwopus 변형까지 선택 가능
  • Toilgate는 100% vibe-coded이며 오픈소스화는 부담이 큼
• 벽면에서 Shelly Plus Plug 2개로 전력 소비 측정, RTX 6000 Pro는 추론 시 600W·정숙, 3090 두 장은 합쳐 약 750W·매우 소음

• 잘못된 비교 (The wrong comparison)

  • 백만 토큰당 입출력 비용을 GPT-5.5 API 가격과 비교하는 것은 현재 역량상 잘못된 비교
  • "로컬 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에 정리돼 있음