로컬 LLM이 Claude Code를 대체할까? 잘못된 벤치마크

배경

dev.to에 올라온 rudratosh의 글을 Buzzing AI가 소개했다. 질문은 단순하다. 로컬에서 돌리는 대규모 언어 모델이 터미널 코딩 에이전트인 Claude Code를 대체할 수 있을까. 필자는 이 논쟁에서 가장 자주 인용되는 벤치마크가 잘못 고른 잣대라고 주장한다. 그 벤치마크는 코딩 에이전트가 실제 저장소에서 해내야 하는 일을 재지 못한다는 것이다.

이 기사가 확인한 자료는 글의 제목과 요약뿐이다. 어떤 모델을 시험했는지, 점수가 얼마였는지는 전해지지 않으므로 수치를 지어내지 않는다. 아래 내용은 필자의 주장과, 모델 단위 시험과 에이전트 단위 작업 사이의 널리 알려진 차이에 근거한다.

글은 누구의 점수가 높은가에서 멈추지 않는다. 로컬 모델을 에이전트 용도로 평가할 때 무엇을 확인해야 하는지로 질문을 옮긴다. 이 전환이 글의 핵심 기여다.

심층 분석

로컬 LLM과 Claude Code 비교에서 흔히 쓰는 벤치마크는 왜 오해를 부를까. 대부분의 코드 벤치마크는 모델을 시험하지만, Claude Code는 에이전트이기 때문이다. 전형적인 벤치마크는 비교적 독립된 문제 하나를 주고, 한 번의 응답으로 함수나 코드 조각을 받아 단위 테스트로 채점한다. 이는 짧은 맥락에서 경계가 분명한 문제를 푸는 코딩 실력만 보여 준다. Claude Code의 작업 방식은 다르다. 디렉터리와 파일을 읽고, 어디를 볼지 스스로 정하고, 검색과 파일 수정과 명령 실행 같은 도구를 호출한다. 오류가 나면 테스트가 통과할 때까지 고친다. 한 작업에 도구 호출이 수십 번 이어질 수 있고, 출력이 쌓일 때마다 맥락도 불어난다. 성패는 코드 한 조각의 품질만으로 갈리지 않는다. 요약은 이런 작업에 더 맞는 지표로 네 가지를 꼽는다. 도구 호출 안정성, 긴 맥락에서의 성능, 다단계 작업 완료율, 추론 속도다. 도구 호출 안정성은 모델이 약속된 형식으로 호출을 매번 내보내는지를 뜻한다. 단계마다 작은 실패율이 있어도 긴 세션에서는 누적된다. 그래서 단일 문제 점수가 비슷한 두 모델도 에이전트 루프 안에서는 크게 다르게 움직일 수 있다.

로컬 환경에서는 긴 맥락과 속도가 더 중요하다. 기록이 길어지면 GPU 메모리를 더 쓰고, 매 턴마다 늘어난 기록을 다시 처리하느라 프리필이 느려진다. 사용자는 이를 지능 부족이 아니라 기다림으로 체감한다. 양자화는 모델을 일반 소비자용 하드웨어에 올려 주지만, 도구 호출 형식과 장기 추론을 약화시킬 수 있다. 단일 문제 벤치마크는 이런 손실을 거의 드러내지 못한다.

산업 영향

개인 개발자에게 위험은 현실적이다. 벤치마크 점수가 좋다는 이유로 클라우드 구독을 해지하면 낭패를 볼 수 있다. 순위표에서는 충분해 보이던 모델이 실제 프로젝트에서는 도구 호출 실패, 잊어버린 제약, 느린 응답에서 막힐 수 있다. 반대 실수도 있다. 에이전트 체감만 보고 로컬 모델을 쓸모없다고 단정하면 정당한 용도를 놓친다. 망 분리된 사내망, 민감한 코드, 오프라인 작업, 자동 완성과 설명과 작은 리팩터링 같은 가벼운 작업이 그렇다.

모델과 도구 제공사에게 이 주장은 경쟁의 무게중심이 순위표 점수에서 에이전트 시스템 전체로 옮겨 간다는 뜻이다. 도구를 가장 안정적으로 쓰는 모델, 맥락 관리와 캐시가 강한 쪽, 재시도와 권한과 작업 분할을 잘 다루는 클라이언트가 승부처가 된다. Claude Code의 강점 상당 부분은 모델과 도구 껍질을 함께 조율한 데서 나온다. 공개 가중치만으로는 이를 쉽게 따라 하기 어렵다.

오픈소스 커뮤니티와 로컬 추론 프레임워크에는 개선 방향이 분명해진다. 도구 호출 호환성을 높이고, 긴 맥락 추론을 빠르게 하고, 에이전트 현실에 가까운 평가를 공개하는 것이다. 실제 저장소에서 이슈를 끝까지 고치는 시험을 만들고, 성공률과 소요 시간과 실패 사유를 기록하면 된다.

전망

지켜볼 신호가 몇 가지 있다. 첫째는 평가 관행의 변화다. 다단계 작업 완료율, 도구 호출 오류율, 긴 맥락에서의 성능 저하 곡선, 작업당 총 시간과 비용을 보고하는 사례가 늘어난다면 커뮤니티가 글이 지적한 빈틈을 메우고 있다는 뜻이다.

둘째는 로컬 모델의 에이전트 전용 훈련이다. 오픈 모델이 도구 사용과 장기 계획을 겨냥해 조율되면, 클라우드 에이전트와의 거리는 단일 문제 점수가 보여 주는 것보다 빨리 좁혀질 수 있다. 셋째는 하드웨어와 추론 소프트웨어의 진전이다. 더 나은 캐시 재사용, 개선된 양자화, 더 큰 소비자용 메모리가 긴 맥락의 로컬 에이전트를 쓸 만하게 만들지 결정한다.

둘 중 하나를 고르는 것보다 혼합 구성이 더 현실적일 수 있다. 민감하거나 단순한 단계는 로컬 모델이 맡고, 계획과 어려운 문제는 더 강한 클라우드 모델이 맡는 방식이다. 가장 실용적인 조언은 어떤 단일 점수도 믿지 않는 것이다. 후보 모델을 자기 실제 작업에 여러 번 돌려 보고, 성공률과 재작업 횟수와 대기 시간을 기록한 뒤 결정하면 된다.