로컬 LLM (Local LLM)은 결국 놀이일 뿐이라고 생각하며, 3개월 정도 RTX 4070 폴더를 방치해 두었습니다. 가정용 GPU로 35B 클래스를 돌릴 수 있어도, 어차피 품질은 API 방식의 GPT-4에게 완패할 것이라고. 그렇게 단정 짓고 벤치마크 측정도 게을리했던 것이 솔직한 심정입니다.

하지만, 승리할 수 있는 구성을 만든 기세로 7가지 질문을 던져보니 이야기가 조금 달라졌습니다.

"똑똑한 모델일수록 넓게 쓰인다"라는 상식 밖의 영역에서, Qwen 35B가 확실히 파고드는 영역이 분명히 존재했습니다. 오늘은 그 7개 항목 채점 결과를 승패 맵(Map)으로서 정리하여 공유합니다. 참고로, Dev.to 측에서는 별도의 기사로 KV cache 최적화에 따른 8배의 속도 개선과 장문 맥락(Long Context)의 트레이드오프(Trade-off)에 대해 썼습니다. 이번에는 품질 축에 관한 이야기로 한정합니다. 속도와 품질은 같은 모델이라도 별도로 측정하지 않으면 결론을 잘못 내리게 됩니다.

전제: 무엇을 측정했는가

측정 조건은 심플합니다.

• 모델: Qwen 3.5 계열 35B (양자화 (Quantization) + CPU 오프로드 (Offload) 구성)
• 비교 대상: GPT-4 계열 (API 경유, 사고 모드(Thinking mode) 없음)
• 샘플: 각 영역당 짧은 질문을 몇 개씩 던지고, 답변의 정확성과 입도(Granularity)를 내가 채점
• 온도 (Temperature): 두 모델 모두 0.3으로 통일

태스크는 7개 영역으로 나누었습니다. 코드 생성, 요약, 번역, 논리 추론, 장문 처리, 일본어 네이티브성, JSON 구조화 출력. 일상 업무에서 내가 LLM을 사용하는 장면에서 그대로 추출한 세트입니다. 벤치마크용 합성 문제는 피했습니다. 내가 실제로 월간 단위로 던지는 쿼리(Query)의 형태를 추출한 점이 핵심입니다.

채점은 3단계입니다. ○는 "실용에 견딜 수 있음". △는 "리뷰하면 사용 가능". ×는 "사용하면 사고가 남". 세세한 수치 스코어보다는 업무에서 대체 가능한지를 보고 싶었기에, 이 정도의 거친 정도면 충분하다고 판단했습니다. '신장의 야망' 게임으로 비유하자면, 세력의 세세한 수치보다는 "동맹을 맺을 것인가, 공격할 것인가, 관망할 것인가"라는 3가지 선택지로 판단하는 것에 가까운 입도입니다.

또한, 공개 벤치마크상에서 Qwen 3.5 계열은 Apache 2.0 라이선스로 배포되며, 프런티어 모델(Frontier Model)에 육박하는 수치를 보여주고 있습니다. 다만 공개 벤치마크는 어디까지나 참고치입니다. 수중에 있는 업무 쿼리로 다시 측정하지 않으면 실운용에 도입할지는 판단할 수 없습니다.

결과: 7개 항목 × 2개 모델의 승패 맵

먼저 전체상을 보여드립니다.

7項目タスクの勝敗マップ

Qwen 35B가 GPT-4와 대등한 영역은 3곳, 패배하는 영역은 4곳

표로 나타내면 다음과 같습니다.

7개 항목 중 Qwen 35B가 GPT-4와 대등하거나 이기는 곳은 3개 영역뿐입니다. 나머지 4개 영역은 확실히 패배합니다. 이 결과를 보고 저는 조금 안심했습니다. 전부 대등하다면 "거대 API 과금의 의미는 무엇인가?"가 될 것이고, 전부 패배한다면 "로컬 LLM을 만지는 의미는 무엇인가?"가 될 테니까요. 3 대 4라는 결과는 양쪽의 역할이 명확해지는 적절한 분기점이었습니다.

"잘 해낸 3개 영역"과 "완패한 4개 영역"을 차례대로 살펴보겠습니다.

Qwen 35B가 파고드는 3개 영역

1. 코드 생성 (정형): 무승부

CRUD, REST 엔드포인트, 테스트 코드 생성, 정규 표현식. 이 부근의 정형화된 코드는 Qwen 35B가 API 방식의 GPT-4와 거의 동일한 품질을 반환합니다.

타입 힌트(Type Hint)가 포함된 Python 함수를 쓰게 해도, TypeScript의 zod 스키마를 뽑아내게 해도, 내가 채점한 범위 내에서는 차이를 느끼지 못했습니다. API 비용을 지불하지 않고 수중에서 돌릴 수 있습니다. 그것만으로도 승리 전략이 됩니다.

구체적으로 던진 질문을 하나 예로 들겠습니다. "pydantic v2로, 중첩된 사용자 정보의 JSON을 검증하는 Model과, 실패 시의 에러 메시지를 일본어화하는 validator를 작성해줘". 두 모델 모두, model_validator를 사용한 구현과 ValidationError의 handler를 제대로 분리하여 작성했습니다.

차이는 없습니다.

차이가 발생하는 것은 코드량이 300행을 넘어가는 시점부터입니다. 전체 설계의 일관성, 명명 규칙(Naming)의 통일감, 리팩터링(Refactoring) 제안의 정밀도. 이 세 가지 측면에서 GPT-4가 조금씩 앞서 나갑니다. 다만, 코드를 작성하기 시작하는 첫 번째 라운드에서 작은 부품을 만들어내는 용도라면 Qwen 35B로도 충분합니다. 저의 경우, CLI 도구의 템플릿, CI 워크플로, 시드 데이터(Seed data) 스크립트 등 잡무 성격의 코드 생성은 거의 전부 로컬로 돌렸습니다.

하지만 알고리즘의 신규 설계나, 여러 파일에 걸친 대규모 수정이 되면 차이가 나타나기 시작합니다. 다음 섹션인 '논리 추론'에서 자세히 다루겠습니다.

2. 일본어 네이티브 성능: Qwen 승

이것은 의외였습니다.

GPT-4의 일본어는 '영어로 생각하고 일본어로 번역했다'는 느낌이 남습니다. 정중합니다. 하지만 미묘하게 부자연스러운 표현이 섞여 있습니다. Qwen 계열은 중국에서 개발되었지만, 동아시아 언어의 학습 비중이 높은 것인지 일본어의 경어(敬体)·평어(常体)·조사 운용이 눈에 띄게 자연스럽습니다.

제가 테스트한 것은 세 가지입니다. 사내용 공지문, 사과문 초안, Slack의 캐주얼한 답장 안입니다. 모두 Qwen 쪽이 수정 없이 그대로 사용할 수 있는 문장이었습니다. 특히 사과문 초안이 이해하기 쉬운 예입니다. GPT-4는 "이번 일로 막대한 폐를 끼쳐드린 점, 진심으로 사과드립니다"와 같이 이른바 번역투의 격식을 차린 문장을 내놓습니다. 문법적으로는 맞습니다. 다만, 실제 일본 비즈니스 메일에서 쓰이는 뉘앙스와는 조금 거리가 있습니다. Qwen은 "이번 건은 제 확인 부족으로 폐를 끼쳤습니다. 죄송합니다"와 같이 일본어 화자가 실제로 쓸 법한 느낌을 돌려줍니다.

조사의 구분 역시 Qwen 쪽이 더 자연스럽습니다. 'は(하)'와 'が(가)'의 구분, 'に(니)'와 'へ(헤)'의 선택, 복합 동사 뒤에 이어지는 조사의 탈락 등. 이런 부분은 일본어를 제1언어로 사용하지 않으면 실수하기 쉬운 포인트입니다. 하지만 Qwen은 거의 틀리지 않습니다.

'똑똑한 LLM일수록 일본어도 잘한다'는 직관은, 적어도 2026년 7월 시점에서는 성립하지 않습니다. 학습 데이터의 균형. 이는 파라미터(Parameter) 수와는 별개의 축으로 작용한다는 것을 다시 한번 느꼈습니다.

3. JSON 구조화 출력: 무승부

스키마(Schema)를 전달하여 JSON을 출력하게 하는 태스크. 양쪽 모두 실용적인 수준입니다. llama-server의 grammar 옵션을 사용하면 구문 오류(Syntax error) 발생률을 제로에 가깝게 낮출 수 있습니다. 따라서 오히려 Qwen 쪽에 활용의 여지가 있습니다. API인 GPT-4에서도 response_format을 사용하면 동일한 작업을 할 수 있습니다. 다만, 비용이 들지 않는다는 점 때문에 Qwen이 다루기 더 쉽습니다.

Grammar를 BNF로 작성하여 출력을 엄격하게 제한하는 운용 방식은, 저와 같이 '한 번에 통과시키고 싶은 파'에게 궁합이 좋습니다. 파싱 에러(Parsing error)로 인한 재시도 비용이 단순하게 사라지기 때문입니다. API 측에서도 같은 일을 할 수 있습니다. 다만, grammar 기술의 자유도는 llama-server 쪽이 더 세밀하게 제어할 수 있다는 인상을 줍니다.

'무승부지만, 무료인 Qwen을 선택한다'는 판단이 서는 영역입니다. 특히 사내 데이터 변환 파이프라인처럼 '동일한 스키마로 하루에 수천 건을 돌리는' 용도가 있습니다. 로컬에서 돌리는 이점이 매우 큽니다. API 비용이 선형적으로 증가하는 처리는 가급적 로컬로 돌리는 것이 저의 전략이 되었습니다.

GPT-4에게 완패하는 4개 영역

패배에 대해서도 솔직하게 적어두겠습니다.

이 부분을 숨기면, 나중에 테스트해 본 사람이 "말이 다르잖아"라고 할 수 있기 때문입니다.

4. 단문 요약: GPT-4 승

요약은 GPT-4가 한 수 위입니다.

Qwen 35B의 요약은 원문의 중요도를 구분하는 능력이 다소 부족하다는 인상을 줍니다. 긴 회의록을 주고 "결정 사항만 추출하라"고 지시했을 때, 결정 사항과 보류 사항을 섞어서 답변합니다. GPT-4는 이러한 선별 능력이 명확하게 뛰어납니다.

예를 들어, 사내 정례 회의록(2,000자)을 전달하며 "결정된 것만 5줄로"라고 지시하면, Qwen은 "다음 회의로 이월" 같은 내용도 함께 섞어서 5줄을 채웁니다. GPT-4는 "다음 회의로 이월"을 별도로 취급합니다. 결정 사항만으로 5줄이 채워지지 않으면 3줄로 답변합니다. 이러한 판단의 결단력이 실무에서는 큰 차이를 만듭니다.

흥미로운 점은, Qwen도 "결정 사항과 보류 사항을 나누어 요약하라"고 2단계로 나누어 지시하면 정확도가 단번에 올라간다는 것입니다. 즉, 암묵적인 정보 선별을 한 번에 포착하는 능력에 차이가 있다는 뜻입니다. 하지만 업무에서 사용할 때 일일이 프롬프트(Prompt)를 2단계로 나누는 것은 번거롭습니다. 따라서 실질적으로는 GPT-4의 승리입니다.

짧은 시간 내에 신뢰할 수 있는 요약을 만들고 싶다. 그런 업무에서는 결국 GPT-4에 맡기는 것이 더 빠릅니다.

5. 영-일 번역: GPT-4 승리

일본어 네이티브성(Native-ness)에서는 Qwen이 이겼지만, 번역에서는 패배합니다. 이 역전 현상이 흥미로운 지점입니다. 번역은 원문의 의도를 유지하면서 자연스러운 번역문을 만드는 2단계 처리를 요구합니다. 일본어 단독 생성은 잘하더라도, 영어의 의도를 정확하게 파악하지 못하면 번역 품질이 저하되는 것으로 보입니다. GPT-4는 영어의 뉘앙스를 깎아내지 않고 일본어로 옮기는 작업이 역시 강력합니다.

구체적으로는 arXiv의 초록(abstract)을 번역시켰을 때 차이가 나타났습니다. GPT-4는 영어의 헤징(hedging, 「suggests that」, 「may indicate」 등)을 일본어의 추량 표현(推量表現)에 적절히 대응시킵니다. Qwen은 이 헤징(hedging)을 누락합니다. 단정적인 어조로 치우치는 경우가 있습니다. 학술 문서 번역에서는 이 차이가 치명적입니다.

일본어 생성과 영-일 번역이 서로 다른 기술이었다는 점은 저에게도 새로운 발견이었습니다. 똑같은 '자연스러운 일본어를 내뱉는' 태스크로 보여도, 입력 언어가 다르다는 것만으로 다른 뇌를 사용하는 것 같습니다.

6. 논리 추론 (다단계): GPT-4 승리

「A라면 B, B라면 C, 단 D인 경우는 제외」와 같은 다단계 추론(multi-step reasoning)이 되면 Qwen 35B의 정밀도가 눈에 띄게 떨어집니다.

사고 모드(thinking mode)를 끄고 있다는 조건 차이는 있습니다.

다만, 사고 모드를 켜더라도 추가적인 사고 토큰(thinking token)을 다 써버린 뒤에 어중간하게 끊기는 경우가 많아, 실무에서는 별로 도움이 되지 않습니다.

제가 측정한 구체적인 예시는 계약서의 조건 해석이었습니다. 「계약 갱신 30일 전까지 통지가 없으면 자동 갱신된다. 단, 갱신료가 전년 대비 10% 이상 상승하는 경우에는 60일 전까지 통지가 필요하다」라는 조건을 주고, 「6월 1일에 갱신료 15% 인상 통지가 도착했다. 계약은 8월 1일에 갱신된다. 유효한가?」라고 물으면, GPT-4는 「60일 전 규칙에 해당하므로, 6월 1일 통지로는 8월 1일 갱신에 맞출 수 없다」라고 즉답합니다. Qwen 35B는 30일 전 규칙과 60일 전 규칙을 혼동합니다. 「유효하다」라고 답하는 경우가 있었습니다.

복잡한 조건 분기나 법무·계약 계열의 문서 해석은 솔직하게 GPT-4에게 맡기는 것이 좋아 보입니다. 여기서 비용을 아끼려다 사고가 나면, 뒷수습 비용이 API 요금의 100배가 됩니다.

7. 장문 처리 (10k 토큰 초과): GPT-4 승리

가정용 GPU로 긴 문맥(long context)을 다루면 우선 속도가 떨어집니다. 그것을 감안하고 품질을 측정하더라도, Qwen 35B는 10k 토큰을 넘어가는 시점부터 문맥 중간을 잊기 시작합니다. 이른바 '로스트 인 더 미들(Lost in the Middle)' 증상이 API 프론티어 모델(frontier model)보다 더 빨리 나타납니다. 긴 기술 문서를 통째로 던져서 분석하게 하는 등의 용도는 GPT-4의 독무대입니다.

저는 15k 토큰 분량의 기술 사양서를 전달하고, 중간인 7k 토큰 부근에 있는 「버전 3.2에서 사양 변경 있음」이라는 한 문장을 후반부 추론에 사용하게 하는 심술궂은 테스트를 했습니다. GPT-4는 매번 이 문장을 찾아내어 추론에 포함시킵니다. Qwen 35B는 5회 중 2회 이 문장을 무시했습니다. 장문의 중간에 묻어둔 중요 정보를 놓치는 것은 업무에서 발견하기 어려운 사고입니다.

하드웨어를 늘리면 개선될 가능성은 있습니다. VRAM을 추가하여 KV 캐시(KV cache)에 여유를 줍니다. 그러면 긴 문맥의 저하는 완화될 것입니다. 다만, 가정용 GPU 예산 범위 내에서는 이 영역은 API를 사용하는 것이 현명하다는 결론을 내렸습니다.

3개 영역에서 이길 수 있다는 사실이 갖는 의미

7개 항목 중 3개 영역에서 대등하다는 결과를 「겨우 3개 영역」으로 읽을지, 「3개 영역이나 이길 수 있다」로 읽을지에 따라 로컬 LLM의 위치가 달라집니다.

저는 후자입니다.

이유는 간단합니다. 업무에서 LLM을 호출하는 횟수의 대부분은 사실 「정형 코드 생성」, 「일본어 문서」, 「JSON 출력」 이 3가지 종류에 집중되어 있기 때문입니다. 저 자신의 Claude / GPT 월간 이용 로그를 되돌아봐도 이 3가지가 절반 이상을 차지했습니다. 횟수 기준으로 보면, 똑똑한 추론을 요구하는 순간은 오히려 소수파입니다.

그렇게 되면, "승리할 수 있는 3개 영역은 Qwen 35B로 돌리고, 패배하는 4개 영역만 API로 던지는" 라우팅 (Routing)이 현실적인 전략이 됩니다. 전부 GPT-4로 돌리는 것보다 월간 API 비용은 명확하게 낮아집니다. 대략적으로 추산해 보면, 저의 월간 API 지출은 3할 줄어들었습니다. 수치상으로는 미미합니다. 하지만 로컬 LLM (Local LLM)의 전기세를 제외하더라도 충분히 흑자입니다.

이것은 "똑똑한 모델일수록 폭넓게 사용할 수 있다"라는 고정관념에 대한 반례입니다. 작은 모델에게도 확실히 통하는 영역이 있습니다. 투자 세계에서도 비슷한 구조가 있습니다. 시가총액이 큰 종목이 만능으로 강한 것도 아니고, 섹터별로 보면 소형주가 더 잘 들어맞는 상황이 있는 것과 비슷합니다. 그 느낌과 닮아 있습니다.

비슷한 구조에 대한 이야기는 이전에 "똑똑한 LLM일수록 상습적으로 거짓말을 하는 문제"라는 기사에서도 썼습니다. 함께 읽어보시면 모델 크기와 품질의 관계를 다른 각도에서 바라볼 수 있을 것입니다.

채점 과정에서 제가 저지른 실수

솔직히 말하면, 첫 채점에서 저는 두 가지 실수를 했습니다.

첫 번째는 사고 모드 (Thinking Mode)의 온/오프를 통일하지 않고 비교했다는 점입니다. Qwen 측에만 불리한 조건으로 평가하고 있었던 것이죠. 나중에 조건을 다시 맞추었습니다. 그러자 논리 추론 이외의 영역에서 Qwen의 점수가 올라갔습니다. 벤치마크 (Benchmark) 설계의 기본은 "변수를 하나로 좁히는 것"입니다. 로컬 LLM의 옵션이 너무 많다 보니 간과하고 말았습니다.

두 번째는 일본어 네이티브성 (Native-ness)을 "번역의 일부"로서 측정하려 했다는 점입니다. 일본어 생성과 영일 번역은 별개의 태스크 (Task)입니다. 이를 분리하지 않으면 Qwen의 강점이 묻혀버립니다. 만약 분리하지 않고 "번역"이라는 한 항목으로 묶었다면, Qwen은 3개 영역에서 2개 영역으로 줄어드는 결과가 나왔을 것입니다. 평가 축을 어떻게 나누느냐에 따라 모델의 평가가 달라집니다. 무서운 이야기입니다.

이러한 평가 설계에 관한 이야기는 "AI 리뷰의 판단을 모은 AI 리뷰의 기각 제안 다루는 법" 기사에서도 다루고 있습니다. 판정의 입도 (Granularity)를 어떻게 결정할 것인가. 이것이 LLM을 업무에 도입할 때의 핵심이라고 최근 특히 느끼고 있습니다.

요약

7개 항목 × Qwen 35B vs GPT-4의 승패 맵을 다시 한번 대략적으로 정리하겠습니다.

• 무승부 이상: 코드 생성 (Code Generation), 일본어 네이티브성, JSON 구조화 (이 3개 영역)
• 완패: 단문 요약, 영일 번역, 다단계 추론 (Multi-step Reasoning), 장문 처리 (이 4개 영역)

"이길 수 있는 3개 영역"을 알고 있다면, 가정용 GPU에서 돌아가는 Qwen 35B는 월간 비용을 크게 줄여줄 파트너가 됩니다. 반대로 "질 수 있는 4개 영역"을 알고 있다면, 무리하게 로컬에서 시도하다가 사고를 치는 일도 줄어듭니다.

두 가지를 모두 알고 있는 것, 그것이 결론의 전부입니다.

로컬 LLM은 결국 놀이일 뿐이라고 단정 지었던 3개월 전의 저에게 이 승패 맵을 건네주고 싶습니다. 그 정도로 업무의 풍경을 바꾸는 데이터였습니다. 다음 단계로는 7개 항목 세트에 "에이전트적인 다회차 대화 (Multi-turn Dialogue)"와 "함수 호출 (Tool Use)" 2개 영역을 추가하여, 9개 항목으로 재측정할 계획입니다.

에이전트 용도에서는 또 다른 승패 맵이 나올 것 같은 예감이 듭니다.

재미있게 가봅시다.

Discussion