벤치마크상 로컬 Qwen과 Claude Opus의 코딩 점수 차이는 12% 남짓입니다. 그런데 1만 5천 달러짜리 GPU를 사서 1년 넘게 로컬 모델을 돌려온 한 창업자는, 그 모델에 긴 작업을 절대 혼자 맡기지 않습니다. 점수는 코앞까지 따라왔는데, 왜 신뢰는 따라오지 못했을까요.

OpenFaaS 메인테이너이자 소프트웨어 회사를 운영하는 Alex Ellis가 로컬 AI 모델을 실전에서 써본 장문의 후기를 공개했습니다. 그는 “로컬 Qwen이 Opus급”이라는 흔한 주장에 대해, X에 올라오는 단발성 데모나 자랑이 아니라 실제 사업에서 나온 “영수증(receipts)”으로 반박합니다. 핵심 메시지는 분명합니다. 로컬 모델은 더 나쁜 Opus가 아니라, 용도가 다른 도구라는 것입니다.

벤치마크 12% 차이라는 함정

숫자만 보면 격차는 좁아 보입니다. 작은 밀집(dense) 모델인 Qwen 3.6 27B조차 SWE-Bench Verified에서 77.2점을 기록했고, Claude Opus 4.8은 88.6점입니다. 그래서 많은 사람이 “로컬이 SOTA보다 고작 12% 뒤진다”며 6년 된 GPU 한 장으로 월 200달러 구독을 대체할 수 있다고 주장합니다.

하지만 Ellis는 이 점수를 그대로 믿으면 안 된다고 말합니다. 벤치마크는 공개돼 있어서 거기에 맞춰 모델을 튜닝하면 실제 실력보다 높은 점수를 받을 수 있습니다(이른바 벤치맥싱). 더 근본적인 문제는 측정 대상입니다. SWE-Bench Verified는 파이썬 오픈소스 이슈들로 구성돼 있는데, 실무에서 마주치는 코드 상당수는 그와 결이 다릅니다. Ellis의 팀은 채널과 컨텍스트, 구조체가 넓은 실행 범위에 걸쳐 동작하는 Go 기반 분산 시스템을 작성합니다. 벤치마크 점수가 곧 내 작업에서의 신뢰도는 아니라는 뜻입니다.

오픈웨이트 모델이 클로즈드 프런티어를 몇 점 차이까지 좁힌 흐름 자체는 분명한 사실입니다. 같은 맥락의 GLM-5.2 이야기는 별도로 다룬 적이 있습니다.

진짜 약점은 무한 루프와 환각

Ellis가 로컬 모델을 신뢰하지 못하는 결정적 이유는 두 가지, 무한 루프와 환각입니다. 그는 이를 칼을 만들 때의 열처리(템퍼링)에 빗댑니다. 강철을 달굴 때 원하는 색을 지나쳐 너무 뜨거워지면 처음부터 다시 해야 하듯, 로컬 모델도 너무 ‘뜨겁게’ 달리다 목표를 지나쳐 같은 출력을 반복하기 시작합니다.

실제 사례가 구체적입니다. CLI에 어떤 명령어를 추가하면 좋을지 물었더니, 모델은 그럴듯한 제안을 내놓다가 같은 목록을 끝없이 반복하며 30분 동안 600W의 전기를 태웠습니다. 다른 작업에서는 파일을 수정하다 스스로 망가뜨린 뒤 “어떻게 고칠지 모르겠다”며 점점 엉뚱한 방향으로 빠지는, 다른 종류의 루프에 갇혔습니다. 환각도 만만치 않습니다. 머신을 분석시키자 파일명을 지어내고(~/faas-netes를 ~/faaned로), 텔레메트리를 분석할 때는 27.3K를 273,000으로 잘못 읽는 산술 오류까지 냈습니다. 이런 실수는 사람이 일일이 검수해야만 잡힙니다.

그래서 그는 칼날을 달구는 동안 자리를 뜨지 않는 것처럼, 로컬 모델에게 장기 자율 작업을 맡기지 않습니다. 이것이 Claude나 Codex와의 결정적 차이입니다. 클라우드 프런티어 모델은 몇 분에서 십수 분간 혼자 일하며 실제로 목표를 향해 나아가지만, 로컬 모델은 그 지점에서 무너집니다.

그럼 어디에 쓰는가

그럼에도 이 1만 5천 달러짜리 카드는 제값을 했습니다. 답은 클라우드로는 할 수 없는 일, 즉 프라이버시가 핵심인 작업에 있습니다.

Ellis의 회사는 데이터 통제가 중요한 기업 고객을 상대합니다. 고객의 진단 덤프나 텔레메트리 데이터를 외부 클라우드 모델에 넣는 건 계약상으로도 양심상으로도 불가능합니다. 그래서 이 데이터들은 격리된 환경에서 로컬 모델로 처리됩니다. 한번은 텔레메트리 데이터베이스를 로컬 모델에 넣어 분석한 덕에, 한 고객이 1년 넘게 라이선스를 4~5배 적게 신고해 과소 납부해온 사실을 찾아냈습니다. 회수한 매출만으로 카드값을 뽑았습니다.

다만 여기에도 분명한 선이 있습니다. 모델이 고객의 함수 개수가 적다는 이유로 이탈 가능성이 높다고 판단했는데, 그 고객이 적은 함수를 하루에도 여러 번 돌린다는 사실은 놓쳤습니다. Ellis의 결론은 간결합니다. 로컬 모델에는 분석을 맡기되, 해석은 맡기지 말 것. 코드베이스를 빠르게 읽고 설명하는 일은 잘하지만, 믿고 맡기려면 사람의 감독이 필요한 도구라는 뜻입니다.

다른 도구라는 관점

Ellis의 이야기가 중요한 이유는, 로컬 모델을 클라우드의 열등한 대체재로 보는 흔한 프레임을 뒤집기 때문입니다. 그가 로컬에서 찾은 가치는 더 싼 Opus가 아니라 프라이버시, 고정 비용, 그리고 벤더 리스크에 대한 방어였습니다. 미국 밖 사용자들에게 Anthropic의 Fable 5 모델이 하루아침에 비활성화된 사건은 이 벤더 리스크가 가상의 우려가 아님을 보여줍니다. 클라우드 프런티어 모델이 어느 날 정책을 바꾸거나 접근을 끊을 때, 로컬 모델은 그 “만약”에 대한 답이 됩니다.

물론 그는 로컬 모델이 아직 갈 길이 멀다는 점도 숨기지 않습니다. 27B 모델은 하루 종일 Go 코드를 작성하기엔 지식과 주의력이 부족하고, 그 한계는 코드 리뷰에서 곧바로 드러납니다. 다만 이제 막 시작된 영역이고 여기서부터 나아질 일만 남았다는 게 그의 시선입니다. 로컬과 클라우드를 같은 작업에 함께 돌려보고 비교하는 일을 일상화하라는 그의 제안은, 둘을 우열이 아니라 서로 다른 쓰임으로 본다는 태도에서 나옵니다.

Ellis의 원문에는 GPU 셋업의 시행착오, 양자화와 컨텍스트 압축의 트레이드오프, llama.cpp 운영 노하우 등 로컬 모델을 실제로 굴리려는 사람을 위한 현장 디테일이 훨씬 더 담겨 있습니다. 직접 로컬 환경을 꾸리려 한다면 원문이 좋은 길잡이가 됩니다.

출처: Local Qwen isn’t a worse Opus, it’s a different tool – Alex Ellis’ Blog