요약 (TL;DR)

RTX 3090에서 qwen3-coder:30b를 사용하여 Jarvis(나의 LangGraph 에이전트, 약 90개의 도구 보유)의 실제 역사적 작업 27개를 재현하였으며, 동일한 작업에 대한 Claude의 실제 프로덕션 답변과 비교 점수를 매겼습니다. 품질: Claude 89.4/100 vs qwen 22.8/100. 비용: qwen이 작업당 약 5,150배 더 저렴함 ($0.00015 vs $0.763, 실제 GPU 전력 소비 vs 실제 API 과금 기준). 신뢰성: qwen은 **답변의 26%**에서 잘못된 형식의 도구 호출 (tool-call) 태그를 유출했으며, 작업에 실제로 필요한 도구와 겹치는 경우는 **14.8%**에 불과했습니다. 동일한 qwen3-coder:30b가 이전의 훨씬 작은 규모의 벤치마크에서는 100%를 기록했습니다. 여기서의 격차는 모델 자체의 성능 문제라기보다 도구 인터페이스 (tool-surface)의 복잡성 차이입니다.

질문

Jarvis는 실제 개인용 AI 에이전트입니다. LangGraph의 create_react_agent를 사용하며, 이메일/캘린더/노트/파일/메시징/코드에 걸친 약 90개의 도구를 갖추고 있으며, 프로덕션 환경에서 Claude로 실행됩니다. qwen3-coder:30b는 동일한 RTX 3090 환경의 제어된 17개 작업 벤치마크에서 이미 100%의 작업 성공률을 기록한 바 있습니다. 당연한 다음 질문은 이것입니다: 이를 실제 에이전트에 투입하면 어떤 일이 벌어질까?

설정 (The setup)

• Jarvis의 자체 Langfuse 트레이스(90일 기간)에서 추출한 28개의 실제 작업 프롬프트(real task prompts)를 사용하였으며, 캘린더 / 코드 / 이메일 / 파일 / 일반 / 메시징 / 노트의 4×7 계층 구조로 층화(stratified)하였습니다.
• Claude의 답변은 재실행된 것이 아니라 실제 프로덕션 기록(real production history)입니다. 샌드박스(sandbox)를 통해 재실행하는 것은 모델이 한 번도 보지 못한 가짜 스텁(stub) 데이터를 제공하는 것이며, 이는 더 공정한 기준이 아니라 더 나쁜 기준이 됩니다.
• qwen은 샌드박스 리플레이 하네스(sandboxed replay harness)를 통해 새롭게 실행됩니다. 프로세스 내의 실제 Jarvis 에이전트 코드를 사용하며, 쓰기 권한이 있는 모든 도구(tool)는 가로채기(intercepted) 처리됩니다(실제로 전송되거나 기록되지 않음). 또한, 읽기 전용(read-only)으로 모킹(mocked)된 모든 도구는 일반적인 스텁이 아니라, 해당 작업의 원래 트레이스에서 기록된 _실제 출력값_을 사용 가능한 경우 제공합니다. 즉, 두 모델 모두 동일한 데이터를 사용합니다.
• 28개 작업 중 1개는 제외되었습니다(336,906자 프롬프트로, 16K–24K 컨텍스트 윈도우(context window)를 초과함) → 총 27개 점수 산출.
• 판정관(Judge): LLM-as-judge (claude-opus-4-8)를 사용하였으며, 위치 편향(position bias)을 피하기 위해 답변별로 독립적으로 점수를 매겼으며(쌍체 비교 방식 아님), 1–5점을 0–100점으로 변환하였습니다.
• 모든 qwen 실행 비용은 실제 3090 전력 소모량에 따른 HomeLab Monitor 실험으로 산정되었습니다. Claude의 비용은 Langfuse에 기록된 API 과금 내역을 따릅니다.

솔직하게 주의사항을 말씀드립니다: 판정관은 Claude 모델이며, qwen의 답변과 함께 Claude 자신의 답변을 채점합니다. 자기 선호 편향(self-preference bias)은 LLM-as-judge 설정에서 문서화된 효과이며, 아마도 격차를 어느 정도 부풀렸을 것입니다. 그렇다고 해서 66점의 격차, 26%의 잘못된 형식의 출력률(malformed-output rate), 또는 두 번의 도구 호출 루프(tool-call loops)를 설명할 수는 없지만, 이는 실제 방법론적 한계이며 단순한 각주 수준의 문제가 아닙니다.

이 단계에 도달하기까지 세 번의 재실행이 필요했습니다. 첫째는 약 40/54개의 호출에 대해 조용히 중립 점수를 부여한 판정관-응답 파싱 버그였고, 둘째는 Claude의 기준점에는 실제 데이터가 있었던 반면 qwen에게는 28개 작업 중 16개 작업에서 실제 편지함/캘린더 콘텐츠를 제공하지 못했던 모킹 데이터 버그였으며, 셋째는 채점 도중 다른 배치(batch)에 대해 중립 점수를 부여한 Claude-API 속도 제한(rate limit) 문제였습니다. 이 세 가지 모두 깨끗한 종료 코드(exit code)를 믿는 대신 점수 분포를 확인함으로써 발견되었습니다. 아래의 수치를 신뢰하기 전에 이 점을 알아둘 가치가 있습니다.

수치 (The numbers)

	Claude	qwen3-coder:30b
평균 품질 (Avg quality, 0–100)	89.4	22.8
...

qwen이 작업당 약 5,150배 더 저렴함 (정확한 수치이며, 27개 전체 작업에 걸친 총 0.0072 BGN을 1 BGN = $0.5547 기준으로 환산함 — 이 프로젝트에 대한 이전의 대략적인 추정치인 180배는 잘못되었으며, 이것이 수정된 수치임).

카테고리별 (Claude | qwen | n):

calendar:   90 | 30 | 4
code:       87 | 25 | 3
email:      92 | 15 | 4
...

qwen이 보여준 가장 좋은 상대적 성과(calendar, general)조차 여전히 Claude 점수의 3분의 1 수준입니다. qwen은 단 한 번도 카테고리에서 승리하지 못했습니다.

한계점 (Where it breaks)

잘못된 도구 호출 유출 (Malformed tool-call leak) — 실제 LangGraph 도구 호출 (tool call) 대신, qwen은 때때로 최종 답변에 호출 내용을 가공되지 않은 텍스트(raw text)로 내보냅니다:

<function=send_email>
{"to": "...", "subject": "...", "body": "..."}
</function>

이는 **27개 작업 중 7개(26%)**에서 발생했습니다. 해당 답변을 읽는 사용자는 실제 동작이 확인되거나 실제 답변이 제공되어야 할 자리에 깨진 구문(broken syntax)을 보게 됩니다.

도구 중복 재현율 (Tool-overlap recall): 평균 14.8%, 원본 히스토리 추적(historical trace)에서 실제로 최소 하나 이상의 도구를 사용한 18/27개 작업(9개 작업은 도구가 필요 없었음)을 기준으로 측정되었습니다. 대부분의 경우 qwen은 실제로 작업을 해결한 도구와 다른 도구를 사용했거나, 혹은 아무것도 사용하지 않았습니다.

반복 루프 실패 (Repetitive-loop failure) 2/27개 작업: pilot-17 (email, 24개 도구 호출, 138.6초, 약 196.7K 입력 토큰)과 pilot-27 (messaging, 27개 도구 호출, 148.9초, 약 196.7K 입력 토큰) 모두 중단하는 대신 이미 답변된 동일한 도구 (run_command, todo_write)를 반복해서 호출했습니다. 로우 로그(raw logs)를 통해 두 작업 모두 실제 재현된 데이터(replayed_real_data: true)를 받았음을 확인했습니다 — 이는 데이터 부족으로 인한 현상이 아닌, 진정한 종료 조건(stopping-condition) 실패입니다.

판결을 내리기 위한 것은 아니지만, 참고할 만한 데이터 포인트가 하나 더 있습니다. 두 모델 모두 테스트 환경(harness) 내에서 실제로 send_email(...)을 호출했을 때(가로채기 수행, 실제 전송은 안 됨), Claude는 사용자에게 이메일이 전송되었다고 말했습니다. 이는 환각(fabrication)입니다. 반면 qwen은 전송이 이루어지지 않았음을 정확히 밝혔습니다. 이것이 단순히 "qwen이 더 정직하다"는 뜻은 아닙니다. qwen은 모델이 원시 태그(raw tags)를 26%의 확률로 유출하기도 합니다. 두 모델 모두 모의 객체(mock)를 잘못 다루었지만, 방식이 달랐을 뿐입니다.

주장의 범위 (Scope of the claim)

동일한 qwen3-coder:30b, 동일한 GPU를 사용했음에도, 훨씬 더 작은 도구 표면(tool surface)을 가진 17개 작업의 통제된 벤치마크에서는 100%를 기록했습니다. 이것은 "로컬 LLM은 나쁘다"는 뜻이 아닙니다. 범위가 제한된 벤치마크에서 뛰어난 모델이라고 해서, 31KB의 컨텍스트 프롬프트와 복잡한 실제 이력이 뒤따르는 약 90개의 도구를 가진 거대하고 실제적인 프로덕션 환경에 즉시 안전하게 교체 투입(drop-in)될 수 있는 것은 아니라는 뜻입니다. 여기서는 작업/도구 표면의 복잡성(Task/tool-surface complexity)이 모델 자체의 품질만큼이나 중요했습니다. Claude 역시 결함이 없습니다. 위에서 언급한 조작된 이메일 전송 확인 사례를 보십시오.

Jarvis는 당분간 Claude를 계속 사용합니다. 비용 문제는 더 좁은 범위의 후속 연구를 진행할 가치가 있을 만큼 실질적입니다. 즉, 전체를 교체하는 대신, qwen이 가장 높은 점수를 기록했던 카테고리(캘린더, 일반)에서만 저렴한 폴백 경로(fallback path)로 테스트하는 방식입니다.

전체 내러티브 버전, 차트, 그리고 세 가지 버그 점수 산정 이야기(three-bug scoring saga)는 Medium에서 확인할 수 있습니다.

여기서 수행된 모든 qwen 실행 비용은 HomeLab Monitor를 통해 3090의 실제 전력 소비량을 기준으로 산정되었습니다. MIT 라이선스이며, 단일 컨테이너로 구성되어 있어 여러분의 로컬 모델 실험 비용을 동일한 방식으로 산정하고 싶다면 재현 가능합니다.

여러분의 기준선은 어디인지 궁금합니다. 실제 에이전트의 일부를 신뢰하고 맡기기 위해 로컬 모델이 얼마나 저렴해야 하며, 어떤 부분부터 가장 먼저 맡기시겠습니까?