Can a local LLM replace Claude Code? The benchmark everyone quotes is the wrong one.
로컬 LLM이 Claude Code를 대체할 수 있을까요? 자주 인용되는 벤치마크가 놓치는 것
SWE-bench 점수만으로 코딩 에이전트의 실사용성을 판단하기 어렵다고 주장합니다. 다단계 도구 호출의 신뢰성, 컨텍스트 유지, 재시도 비용을 따져 로컬 모델과 클라우드 모델을 작업별로 나누어 쓰는 방식을 제안합니다.
- 주제
에디터 노트
이 글의 문제 제기는 타당하지만, 제시한 도구 호출 신뢰성 주장을 뒷받침하는 측정은 본문에 없습니다. 저자는 댓글에서 호출별 유효성을 기록하지 않았고 사용 경험에 기대어 판단했다고 인정합니다. 따라서 14B~32B 권장이나 모델별 신뢰도 순위는 검증된 비교 결과보다 저자의 관찰로 읽어야 합니다. 댓글은 그 빈자리를 구체적인 측정 문제로 좁힙니다. 호출별 성공률을 여러 단계로 거듭 곱하면 전체 작업 성공률이 빠르게 낮아진다는 계산은 다단계 에이전트 평가에 유용하지만, 호출 실패가 독립적이라는 가정은 컨텍스트 드리프트나 세션별 편차에 따라 맞지 않을 수 있습니다. 또 200건 중 38건이 형식 검사를 통과하고도 잘못된 호출이었다는 댓글 사례는 스키마 검증만으로 의미상 정확성을 보장하지 못한다는 점을 보여줍니다. 저자의 결론처럼 로컬과 클라우드를 작업별로 배분하려면 벤치마크 점수뿐 아니라 재시도와 잘못된 호출까지 기록해야 합니다. 다만 댓글의 수치와 제안도 각 작성자가 보고한 사례이므로, 일반적인 모델 성능으로 확대해 해석할 근거는 자료에 없습니다.
AI 요약
글은 SWE-bench Verified 점수가 로컬 코딩 에이전트의 실사용성을 충분히 보여주지 못한다고 주장합니다. 이 벤치마크는 버그에 맞는 패치를 작성하는 능력을 측정하지만, 에이전트가 여러 파일을 수정하며 도구 호출을 반복할 때의 신뢰성은 측정하지 않습니다. 글이 실제 업무에서 문제가 된다고 꼽는 항목은 도구 호출 형식의 유효성, 긴 작업에서 계획을 유지하는 능력, 긴 컨텍스트에서의 품질, 지시 준수입니다.
모델과 하드웨어
글은 모델을 단일 점수보다 계열과 사용 조건으로 비교합니다. Qwen 계열은 코딩과 도구 사용을 함께 고려할 때 기본 선택지로 제시합니다. Qwen 3.6 27B는 양자화해 약 22GB를 차지하며 24GB GPU나 M 시리즈 Mac에서 사용할 수 있다고 설명합니다. Qwen 3.5 35B-A3B는 전체 35B 중 토큰마다 약 3B를 활성화하는 Mixture-of-Experts 모델이라 Q4 양자화 기준 약 8GB VRAM에서 실행할 수 있다고 합니다. GLM-4.7-Flash는 5~8GB급 장치에서 가벼운 작업에 쓸 선택지로, Devstral Small 2는 Apache-2.0 라이선스와 중급 GPU 지원을 이유로 듭니다. DeepSeek V4-Pro와 Kimi 계열은 80GB 이상 서버급 장비를 요구하는 선택지로 분류합니다.
글은 24GB GPU에서 Qwen 3.6 27B를 실행하는 구성을 가격과 성능의 균형점으로 꼽습니다. 다만 본문에 등장하는 성능 수치는 공급업체가 보고한 값이라고 밝힙니다. SWE-bench Verified와 Pro, Terminal-Bench 점수를 서로 바꾸어 인용하는 사례가 있으므로 공식 리더보드에서 같은 기준인지 확인하라고 덧붙입니다. 컨텍스트 창은 최소 32K, 가능하면 64K 이상으로 명시하라고 권합니다. 창 크기가 커질수록 KV cache가 VRAM을 차지하고, 모델 품질도 표시된 한도에 도달하기 전에 떨어질 수 있다고 설명합니다.
에이전트에서 드러나는 실패
글에 따르면 도구 호출은 코드를 작성하는 능력과 별도로 학습해야 하는 기술입니다. 호출 하나가 통과해도 여러 호출을 연속으로 수행하면 존재하지 않는 함수를 지어내거나 인자 형식을 바꾸면서 에이전트가 재시도에 빠질 수 있습니다. 저자는 14B~32B급 모델 중 도구 사용 학습을 거친 계열을 에이전트 작업에 권하고, 7B 미만 모델은 긴 작업에 적합하지 않다고 주장합니다.
실패 양상으로는 스키마가 조금씩 어긋나 재시도가 반복되는 경우, 여러 파일을 수정하는 동안 추론이 흐트러지는 경우, 반복 생성 탓에 지연이 커지는 경우, 컨텍스트 창 중간쯤부터 계획을 따르는 품질이 낮아지는 경우를 듭니다. 사용 사례도 나눕니다. 비공개 코드, 오프라인 작업, 단일 파일 수정, 분류나 서식 지정처럼 반복량이 많은 작업은 로컬 모델에 맡기고, 긴 컨텍스트와 다단계 변경, 첫 시도에 빠르게 끝내야 하는 작업은 Claude나 Codex 같은 클라우드 모델에 맡기라고 제안합니다. 비용 면에서도 개인의 가벼운 사용은 장비 구입과 관리 부담 때문에 클라우드보다 저렴하지 않을 수 있다고 봅니다. 대량의 반복 작업에서 쉬운 호출은 로컬로 보내고 어려운 일부만 프런티어 모델로 넘기는 구성이 비용을 줄이는 경로라고 설명합니다.
dev.to 반응
- @howcani_howcani_77e786a89 — 호출 하나가 유효할 확률을 q, 필요한 호출 수를 k라고 하면 전체 작업이 성공할 확률은 q의 k제곱입니다. 11회 호출 작업을 90% 성공률로 끝내려면 호출별 유효성이 0.9905 이상이어야 하고, 95% 성공률에는 0.9953 이상이 필요합니다. 단일 호출 점수만으로 신뢰할 수 있는 에이전트라고 말하기 어렵습니다. 작업 유형별 호출 유효성과 성공률이 허용 기준 아래로 떨어지는 호출 횟수를 함께 측정해야 합니다.
- @rudratosh — 제 차트에 빠진 숫자가 바로 q의 k제곱입니다. 0.99와 0.995는 단일 호출 그래프에서는 비슷해 보여도 50회 연속 작업에서는 성공률이 각각 0.61과 0.78입니다. 실제 측정에서는 같은 작업을 다시 실행하고 호출 수를 세야 합니다. 저는 호출별 유효성을 기록하지 않았습니다. 제 주장은 통제된 측정이 아니라 일상적인 사용 경험에 기대고 있었습니다.
- @tokenlat — 실제 선택은 로컬 모델과 프런티어 모델 가운데 하나를 고르는 일이 아닌 경우가 많습니다. 상용구 작성, 분류, 서식 지정 같은 호출 대부분은 로컬이나 작은 모델로 처리하고, 어려운 단계만 프런티어 모델에 맡길 수 있습니다. 모델 하나가 아니라 작업 조합을 벤치마크해야 합니다.
- @howcani_howcani_77e786a89 — AST 차이를 이용한 경보를 세 가지 경우로 시험했습니다. 같은 의미의 변수명 변경과 문장 재배치는 경보를 일으키지 않았지만, 세 번 모두 같은 잘못된 수정안을 낸 경우에도 경보가 울리지 않았습니다. 세 결과가 서로 다른 잘못된 수정안을 내면 차이가 크게 나타났습니다. 따라서 이 방법은 결과의 일치가 정답임을 증명하지 않고, 출력 간 불일치를 알리는 용도로만 써야 합니다.
- @tom_jones_230c4659491adcd — 저희 게이트웨이에서 BFCL과 ToolACE의 도구 호출 200건을 검사했습니다. 정답 호출은 162건이었지만 JSON 형식과 필수 필드, 함수 이름만 확인하는 검증 표시는 200건 모두 통과했습니다. 나머지 38건은 형식이 맞아도 잘못된 호출이었습니다. 스키마 검사 통과와 사용자의 요청에 맞는 호출은 별도 기준으로 측정해야 합니다.
원문: dev.to / 번역·요약: Trawling