GLM-5.1: 오픈소스가 프런티어 코딩 모델을 따라잡은 순간

원본 영상: YouTube · 채널: Onchain AI Garage · 업로드: 2026-04-08

서론

2026년 4월 7일, 중국 Z.ai가 공개한 GLM-5.1은 오픈소스 진영에 작은 충격파를 남겼습니다. 단순히 “또 하나의 오픈 웨이트 모델”이 아니라, SWE-Bench Pro에서 58.4점으로 Claude Opus 4.6(57.3)과 GPT-5.4를 밀어내고 1위에 오른 최초의 오픈소스 모델이기 때문입니다(MarkTechPost 보도). Onchain AI Garage의 리뷰 영상은 이 모델을 Hermes 에이전트 위에 얹어 실전 코딩 과제 두 건을 맡기고, 실제로 “광고대로 동작하는지”를 12분 동안 속도감 있게 보여줍니다.

이 글은 해당 영상을 보고 느낀 것을 한국어로 풀어쓰면서, GLM-5.1의 아키텍처·가격·벤치마크에 대한 외부 자료까지 교차 확인해 한 편의 리서치형 블로그로 재구성한 것입니다.

본론

1. GLM-5.1은 정확히 무엇인가

GLM-5.1은 Z.ai의 기존 GLM-5 베이스 모델을 사후 학습(post-training)으로 확장한 744B 파라미터(MoE + DSA 아키텍처) 모델입니다. 200K 컨텍스트 윈도를 지원하고 최대 출력 토큰은 128K에 달하며, 허깅 페이스에 MIT 라이선스로 공개되어 있습니다. 영상 속 발표자가 말한 “754B 파라미터”는 공식 스펙(744B)과 소폭 차이가 있지만, 동일한 모델을 가리키는 구두 근사치로 보면 됩니다. 정확한 수치는 Z.ai 공식 GLM-5 블로그와 Analytics Vidhya 기술 리뷰에서 확인할 수 있습니다.

핵심 설계 철학은 “Vibe Coding에서 Agentic Engineering으로”입니다. 즉 짧은 조각 코드를 잘 짜는 것보다, 수 시간에 걸친 멀티스텝 엔지니어링 워크플로우를 끊김 없이 완주하는 능력에 초점을 맞췄습니다. 이것이 영상 속 8시간짜리 Linux 데스크톱 자가 구축 데모와 정확히 같은 이야기입니다.

2. 벤치마크: 1위 주장, 그러나 사각지대도 존재

Z.ai는 아래 지표들에서 SOTA 또는 SOTA 근접을 주장합니다.

• SWE-Bench Pro: 58.4 (Claude Opus 4.6: 57.3, GPT-5.4보다 앞섬)
• CyberGym: 68.7 (직전 세대 GLM-5의 48.3에서 대폭 상승)
• BrowseComp: 68.0 / τ³-Bench: 70.6 / MCP-Atlas: 71.8
• AIME 2026: 95.3 / GPQA-Diamond: 86.2

그러나 Lushbinary 비교 분석에 따르면, Terminal-Bench 2.0 + NL2Repo를 합산한 넓은 코딩 컴포짓에서는 Claude Opus 4.6이 57.5점으로 여전히 GLM-5.1(54.9)보다 앞섭니다. 즉 “오픈소스 코딩 1위”라는 헤드라인은 사실이지만, 벤치마크 하나(SWE-Bench Pro)에 지나치게 의존하고 있다는 점은 독자가 반드시 주의해야 할 대목입니다. 영상에서 한 발짝 떨어져 검증해 보면, GLM-5.1은 “대부분의 워크로드에서 Opus 4.6 수준이고, 장기 호라이즌에서는 사실상 유일한 오픈 옵션”이라고 말하는 쪽이 훨씬 정직합니다.

3. 장기 호라이즌 에이전틱 코딩: 진짜 차별점

영상의 두 번째 실험(트레이딩 전략 추출 → 스크리너 → 페이퍼 트레이더)이 특히 인상적인 이유는, 약 1시간 동안 거의 프롬프트를 추가하지 않고도 모델이 ICT 전략의 핵심 요소(fair value gap, order block, liquidity pool)를 코드로 증류해 냈다는 점입니다. 3일치 백테스트 기준 승률 37%·수익 $7,490이라는 결과도 “데모용 허상”이 아니라 전형적인 ICT R:R 구조가 살아 있음을 보여줍니다.

외부 리뷰들도 같은 방향을 가리킵니다. Atlas Cloud 분석은 GLM-5.1을 “8시간 무인 실행을 지속할 수 있는 최초의 오픈소스 모델”로 평가했고, Medium Joe Njenga 리뷰는 VectorDBBench에서 600회 이상 반복 최적화 끝에 21.5K QPS(단일 세션 최고 대비 6배)를 달성했다고 보고합니다. 영상 속 발표자가 느낀 “내가 베이비시팅할 필요가 없었다”는 체감은 단순한 호평이 아니라, 모델의 학습 목표 그 자체가 그 방향으로 정렬되어 있다는 증거입니다.

4. 환각과 한계: “리뷰는 좋았지만 보너스는 거짓이었다”

영상에서 가장 정직한 부분은 발표자가 Opus 4.6으로 교차 검증했을 때 드러난 보너스 제안의 환각입니다. GLM-5.1이 제안한 다섯 가지 개선안 중 네 가지는 정당했지만, 추가로 끼워 넣은 “truncation 이슈”는 코드 베이스에 존재하지 않는 사실이었습니다. 이는 현재 세대 LLM에서 여전히 흔한 실패 모드이며, 장기 호라이즌 작업일수록 누적 오류가 위험해진다는 점을 시사합니다. 실전 도입 시에는 “모델이 한 일”을 전부 그대로 받아들이지 말고, 핵심 주장만 뽑아 별도 모델이나 테스트로 재검증하는 다계층 워크플로우가 반드시 필요합니다.

또 하나의 한계는 속도입니다. Buildfast 리뷰에 따르면 GLM-5.1의 스루풋은 약 44.3 tokens/s 수준으로 Opus 4.6보다 확연히 느립니다. 발표자도 “확실히 느리다”고 반복해서 말합니다. 대신 API 가격은 입력 $1.00/M, 출력 $3.20/M로 Opus 4.6($5/$25) 대비 입력 기준 약 56배, 출력 기준 약 810배 저렴합니다.

5. 어떻게 사용할 것인가

• API: OpenRouter, Z.ai 공식 엔드포인트, Atlas Cloud 등에서 즉시 사용 가능. 입력 $1.00/M, 출력 $3.20/M이라는 가격은 시간당 비용이 생업 수준이 되는 에이전트 루프에서 특히 의미가 크다.
• 로컬: SGLang 0.5.10+, vLLM 0.19.0+, Transformers 0.5.3+, KTransformers 0.5.3+에서 지원. 다만 원본 744B 가중치는 최소 수백 GB VRAM이 필요하므로, 소비자 하드웨어 사용자는 커뮤니티 INT4/INT3 양자화 트리나 전문가 오프로드 빌드를 기다려야 하는 현실적 제약이 있습니다.
• 에이전트 래퍼: 영상은 Hermes 에이전트를 사용했지만, Claude Code, Aider, Cline, OpenHands 등 MCP 지원 도구라면 어디에든 붙일 수 있습니다. 같은 GLM-5.1이라도 에이전트 프레임워크의 툴 스키마·메모리·리트라이 로직에 따라 체감 성능이 갈리므로, “모델 교체”가 아니라 “스택 전체 교체”로 접근하는 편이 안전합니다.

6. 실무 적용 레시피: 하이브리드 스택

영상의 발표자는 말로 표현하지 않았지만, 그가 한 일의 본질은 GLM-5.1을 1차 탐색·생성기로, Claude Opus 4.6을 검증·리팩토러로 두는 하이브리드 스택이었습니다. GLM-5.1의 보너스 제안 환각을 Opus로 잡아낸 바로 그 순간, 그는 “어느 모델이 더 강한가”라는 게임을 이미 졸업한 셈입니다. 2026년 하반기의 실무자에게 권장되는 레시피는 다음과 같습니다.

1. 탐색·스케치 단계: GLM-5.1에 저렴한 비용으로 1~2시간 범위의 자율 루프를 맡긴다. 환각을 받아들일 각오를 하고, 넓게 생성하게 둔다.
2. 검증·타이트닝 단계: 상위 프런티어 모델(또는 동일 GLM-5.1의 별도 세션)에 결과물을 넘겨 사실 정합성과 구조 품질을 점검한다. 이 단계는 상대적으로 짧고 토큰도 적게 든다.
3. 실행·모니터링 단계: 스크리너·백테스트·린터·타입 체커 같은 환경 신호를 무조건 루프 안에 넣는다. LLM이 잡지 못하는 오류를 환경이 잡아낸다.
4. 사람 개입 포인트 설계: 장기 호라이즌 루프는 반드시 “사람이 결정하는 체크포인트”를 갖도록 한다. 영상에서 발표자가 레이트 리밋 문제에 개입한 순간이 바로 그런 포인트였다.

핵심 인사이트

1. “오픈소스 1위”는 사실이지만 맥락이 중요하다. GLM-5.1은 SWE-Bench Pro에서 진짜로 Opus 4.6을 이겼으나, 넓은 코딩 컴포짓에서는 여전히 Opus가 앞선다. 차별점은 점수가 아니라 장기 자율 실행에 있다.
2. 속도 vs 비용의 트레이드오프가 명확하다. 10배 저렴한 API, 5~6배 느린 응답, 그러나 무인 실행이 가능한 1시간 단위 작업에서는 속도 손해가 사실상 0이 된다.
3. 환각은 여전하다. 장기 에이전틱 워크플로우에서는 교차 검증 계층이 필수. GLM-5.1은 이 계층이 잘 구축된 파이프라인에서 진가를 발휘한다.
4. 로컬 실행은 아직 커뮤니티의 숙제다. 744B MoE는 개인 장비로는 무리이며, 양자화·샤딩·오프로드 기법이 성숙해야 진짜 “무료”가 된다.
5. 에이전트 프레임워크의 UX가 점점 더 중요해진다. 같은 GLM-5.1이라도 Hermes / Claude Code / Cline 어느 위에 얹느냐에 따라 체감 성능이 크게 갈린다.

더 알아보기

• Z.ai 공식 블로그: GLM-5 — From Vibe Coding to Agentic Engineering
• MarkTechPost: GLM-5.1은 SWE-Bench Pro에서 SOTA, 8시간 무인 실행
• Analytics Vidhya: GLM-5.1 아키텍처와 벤치마크 해설
• Lushbinary: GLM-5.1 vs Claude Opus 4.6 vs GPT-5.4 비교
• Buildfast: Opus와의 실전 비교 리뷰
• Hugging Face: zai-org/GLM-5 모델 카드

토론: “GLM-5.1은 오픈소스가 프런티어 코딩 모델을 실질적으로 따라잡았음을 증명한다”

논제: GLM-5.1의 등장으로 실무 코딩 워크플로우에서 오픈소스 모델이 Claude Opus 4.6·GPT-5.4급 상용 프런티어 모델을 대체할 수 있게 되었는가?

Round 1

🟢 Pro — “벤치마크와 실전 데모 모두가 ‘이미 따라잡았다’고 말한다”

첫째, 객관 지표가 바뀌었습니다. MarkTechPost 보도에 따르면 GLM-5.1은 SWE-Bench Pro에서 58.4점으로 Claude Opus 4.6(57.3), GPT-5.4, Gemini 3.1 Pro를 전부 제쳤습니다. SWE-Bench Pro는 “70%를 찍던 SWE-Bench Verified와 달리 상위 모델이 23% 수준에 머무르는” 난이도로 설계되었고, GPL 카피레프트·사유 저장소 기반이라 데이터 오염(contamination) 저항성이 높은 벤치마크로 평가됩니다. 따라서 이 점수는 단순한 리더보드 치장이 아니라 “처음부터 어렵게 만들어 놓은 시험”에서의 역전입니다.

둘째, 영상이 보여 준 실전이 결정적입니다. Hermes 에이전트 위에서 GLM-5.1은 트레이딩 저널 트랜스크립트를 받아, ICT 전략(fair value gap, order block, liquidity pool)을 증류하고, Hyperliquid API 기반 스크리너와 페이퍼 트레이더를 약 1시간 만에 거의 원샷으로 완성했습니다. 3일 백테스트에서 승률 37%·수익 $7,490이라는, 설계 의도(R:R 3~4배)와 정확히 맞는 결과가 나왔습니다. “벤치마크만 좋은” 모델이라면 불가능했을 종단 간 작업입니다.

셋째, 가격과 라이선스의 의미를 과소평가해선 안 됩니다. API 기준 입력 $1/M, 출력 $3.20/M은 Opus 4.6($5/$25) 대비 압도적으로 저렴하며, 모델 가중치는 MIT로 풀렸습니다(Z.ai 공식 블로그). 동일 작업을 10배 낮은 비용으로 해낸다는 것은 “기능적 동등”을 넘어 “실무 대체 가능”을 뜻합니다.

🔴 Con — “헤드라인 한 줄이 생태계 전체를 대체하진 못한다”

첫째, 단일 벤치마크 승리로 프런티어가 뒤집혔다고 말하는 것은 너무 성급합니다. Lushbinary 비교에 따르면 Terminal-Bench 2.0 + NL2Repo를 합산한 넓은 코딩 컴포짓에서는 Claude Opus 4.6이 57.5 대 54.9로 여전히 앞섭니다. 더 본질적으로, arXiv의 “SWE-Bench Illusion” 논문은 SWE-Bench 계열 점수의 상당 부분이 실제 추론이 아닌 기억(memorization)에서 오며, 일부 모델은 이슈 설명만으로 버그 파일 경로를 76%까지 맞춘다고 지적합니다. 벤치마크 한 줄의 역전을 “실력 역전”으로 읽는 것은 위험합니다.

둘째, 영상 자체가 환각을 기록하고 있습니다. GLM-5.1이 제시한 다섯 가지 개선안 중 “보너스 제안”은 코드 베이스에 존재하지 않는 truncation을 있다고 주장하는 명백한 환각이었습니다. 발표자가 Opus 4.6으로 교차 검증하지 않았다면 그대로 반영됐을 오류입니다. 1시간짜리 자율 실행에 누적될 이런 환각이 얼마나 되는지, 영상은 말하지 않습니다.

셋째, 속도와 운영 현실입니다. GLM-5.1의 스루풋은 약 44 tokens/s 수준으로 Opus 대비 확연히 느리며, 754B/744B MoE는 개인 장비로 로컬 실행이 불가능해 사실상 “또 다른 API 호출”입니다. “오픈소스”라는 단어가 주는 자유도는 대부분의 실사용자에게 현실화되지 않습니다. 결론적으로 GLM-5.1은 훌륭한 보완재이지, 프런티어 모델의 대체재라고 선언할 수는 없습니다.

Round 2

🟢 Pro (재반론) — Con의 세 주장을 하나씩 반박한다

Con의 첫째 — “벤치마크 메모라이제이션” 우려에 답합니다. Con이 인용한 SWE-Bench Illusion 논문은 주로 SWE-Bench Verified를 표적으로 삼았고, 문제가 된 것은 “이슈 설명만으로 파일 경로를 맞추는” 저항성 낮은 하위 태스크입니다. 반면 GLM-5.1이 1위를 한 것은 SWE-Bench Pro이며, Scale AI의 공개 리더보드가 명시하듯 GPL 카피레프트·사유 코드베이스로 구성되어 훈련 데이터 오염 가능성을 구조적으로 낮춘 벤치마크입니다. Con이 걱정하는 메모라이제이션 이슈가 가장 적게 작동하는 지형에서 역전이 일어났다는 것이 오히려 Pro 주장을 강화합니다.

Con의 둘째 — “환각 사례”에 답합니다. 환각은 현재 세대 모든 LLM의 공통 실패 모드입니다. Opus 4.6도, GPT-5.4도 동일한 이슈를 안고 있으며, 실제 기업 도입 시에는 어차피 다계층 검증(리뷰어 모델, 테스트, 린터)이 전제됩니다. Con이 지적한 “보너스 제안 1건”을 뒤집어 보면, 다섯 제안 중 네 건은 논문 레벨로 정당했고 심지어 발표자가 아직 업로드하지 않은 브랜치의 구현까지 예측해 맞혔습니다. 4/5의 적중률은 “프런티어 대체 불가”의 증거가 아니라, 다계층 파이프라인에서 충분히 신뢰 가능한 1차 에이전트라는 증거입니다.

Con의 셋째 — “속도·로컬 실행”에 답합니다. 장기 호라이즌 작업에서 스루풋의 의미는 달라집니다. 1시간짜리 무인 실행에서 44 tokens/s와 200 tokens/s의 실질 차이는 “발표자가 자리를 비우고 다녀오는 시간”일 뿐입니다. 로컬 실행이 현재는 어렵다는 지적은 맞지만, MIT 라이선스와 745B 가중치가 공개되어 있다는 사실 자체가 비가역적입니다. 이미 커뮤니티에서는 양자화 트리가 올라오고 있고, 6개월 내 소비자 하드웨어에서 도는 변종이 나올 가능성은 역사적으로 거의 확실합니다.

🔴 Con (재반박) — Pro의 세 주장을 하나씩 꺾는다

Pro의 첫째 — “SWE-Bench Pro가 오염 저항적”에 답합니다. SWE-Bench++ 연구는 오염 저항을 주장하던 초기 벤치마크조차 이후 버전에서 “재현성 문제”가 드러났음을 보여 줍니다. 또한 CodeAnt 분석은 SWE-Bench 자체의 47.93%가 “약한 테스트 통과만으로 해결됐다”고 잘못 라벨링되어 있으며, 필터링 후 해결률이 절반 가까이 떨어진다고 보고합니다. Pro가 “오염이 구조적으로 낮다”고 말하는 Pro 벤치마크도 예외가 아니며, 점수 1.1점 차이를 “역전”으로 해석하는 것은 측정 오차 범위 안의 이야기일 수 있습니다.

Pro의 둘째 — “4/5 적중이면 충분”에 답합니다. Pro는 환각을 검증 계층으로 보완할 수 있다고 말하지만, 영상에서 검증을 수행한 모델은 바로 Claude Opus 4.6이었습니다. 즉 GLM-5.1이 신뢰 가능해 보이는 이유 자체가 상용 프런티어 모델의 존재에 의존하고 있습니다. 이는 “프런티어 대체”가 아니라 “프런티어에 기생하는 1차 생성기”를 의미합니다. 또 1/5의 환각율은 10단계 체인에서는 89%의 누적 오류율로 커집니다. 장기 호라이즌이 강점이라는 주장과 정면으로 충돌합니다.

Pro의 셋째 — “오픈소스는 시간이 해결한다”에 답합니다. 이것은 희망 논증입니다. LLaMA 계열 모델들이 2년이 지나도록 여전히 “소비자 GPU에서 편히 도는 버전”에 가깝지 않다는 점을 생각해 보면, 744B MoE의 실질 로컬화는 최소 12~18개월, 그 시점에는 이미 프런티어 모델이 또 한 세대 앞서 있을 가능성이 큽니다. “언젠가는”은 현재 시점의 논제(“실질적으로 따라잡았다”)를 정당화하지 못합니다.

Round 3

🟢 Pro — Con의 Round 2 주장에 다시 답한다

Con의 첫 번째 Round 2 반박(벤치마크 오염과 1.1점 격차)은 기술적으로 타당하지만 논의의 초점을 놓치고 있습니다. Pro 진영은 “GLM-5.1이 모든 지표에서 Opus를 영원히 앞섰다”고 주장한 적이 없습니다. 주장은 “실질적으로 따라잡았다”입니다. 측정 오차 안에 들어온다는 것은 곧 프런티어와 동급 밴드에 진입했다는 뜻이며, 이것이 바로 논제의 정의입니다. 1년 전만 해도 오픈소스 최강 모델은 SWE-Bench Pro에서 프런티어에 두 자릿수 차이로 뒤처져 있었습니다. 격차가 측정 노이즈 수준으로 좁혀졌다는 사실 자체가 역사적 변곡점입니다.

Con의 두 번째 Round 2 반박(검증 모델로 Opus에 기생)은 교묘하지만 뒤집힙니다. 발표자가 Opus 4.6을 검증자로 쓴 이유는 “그 레포를 실제로 구축한 원본 세션”이 Opus 쪽에 있었기 때문입니다. 맥락 독점 때문이지, Opus가 구조적 우위를 가졌기 때문이 아닙니다. 더 중요한 건 환각율 계산입니다. 1/5를 10단계에 곱해 89%를 만드는 공식은 각 단계가 독립 시행이라고 가정할 때만 성립합니다. 실제 에이전틱 코딩에서는 테스트 실행, 파일 시스템 피드백, 컴파일 에러 같은 환경 신호가 각 단계마다 오류를 교정하므로 누적 오류는 기하급수가 아니라 로그 스케일에 가깝습니다. 영상의 1시간짜리 트레이딩 봇이 실제로 작동한다는 사실이 그 증거입니다.

Con의 세 번째 Round 2 반박(LLaMA 2년 사례)은 오해의 소지가 있습니다. LLaMA-65B(2023)는 이미 2024년부터 4bit 양자화로 소비자 GPU 2장에서 구동됐습니다. MoE 아키텍처는 활성 파라미터가 전체의 극히 일부(GLM-5.1은 활성 파라미터가 44B 수준)이기 때문에 오히려 양자화·오프로드에 유리합니다. 6~9개월 내 3090/4090 듀얼 구성에서 돌아가는 변종은 낙관이 아니라 합리적 추정입니다.

🔴 Con — Pro의 Round 2 주장에 다시 답한다

Pro의 첫 번째 Round 2 재반론(SWE-Bench Pro는 오염에 강하다)에 답합니다. LiveCodeBench가 월간 롤링 업데이트를 고수하는 이유는 정확히 “오염 저항을 처음부터 설계했던” 벤치마크들조차 시간이 지나면 누출된다는 경험적 교훈 때문입니다. Pro 벤치마크도 공개된 지 이미 수 개월이 지났고, 모델 개발사들이 해당 저장소의 구조를 간접적으로 학습할 경로는 무수히 많습니다. Pro가 말하는 “구조적 저항성”은 출시 시점의 특성이지 영구 자산이 아닙니다.

Pro의 두 번째 Round 2 재반론(환경 신호가 오류를 교정한다)에 답합니다. 환경 신호는 컴파일러와 테스트가 잡는 종류의 오류만 교정합니다. 영상의 환각 사례는 “존재하지 않는 truncation”이었는데, 이것은 컴파일도 통과하고 테스트도 통과합니다. 오직 인간 또는 컨텍스트를 완벽히 보유한 다른 모델만 잡아낼 수 있는 **사실 환각(factual hallucination)**이며, 장기 호라이즌 작업에서 가장 위험한 유형입니다. Pro의 “로그 스케일” 낙관은 이 부류의 오류 앞에서 성립하지 않습니다.

Pro의 세 번째 Round 2 재반론(MoE 활성 파라미터가 작아서 로컬화 쉽다)에 답합니다. 활성 파라미터가 44B여도 라우팅을 위해 전체 744B를 어딘가에 상주시켜야 합니다. KV 캐시, 전문가 가중치 스와핑, 200K 컨텍스트 유지는 소비자 하드웨어의 PCIe 대역폭과 RAM 한계에 정면으로 부딪힙니다. Pro가 말하는 “듀얼 4090 구동”은 기술적으로 가능하더라도 초당 2~5 토큰 수준의 사실상 사용 불가 구간입니다. 진짜 “오픈소스의 자유”는 아직 도래하지 않았습니다.

🧭 종합

합의 지점

• GLM-5.1은 오픈소스 진영 역대 최고의 코딩 모델이며, 적어도 SWE-Bench Pro라는 좁은 축 위에서는 Claude Opus 4.6과 GPT-5.4와 동일한 밴드에 들어왔다.
• 영상의 실전 데모(코드 리뷰·트레이딩 전략 추출·페이퍼 트레이더)는 조작이 아니며, 장기 호라이즌 작업에서 프롬프트 개입을 최소화한 상태로도 유의미한 완성도를 낸다.
• 환각은 여전히 존재하고, 실무 도입에는 다계층 검증 파이프라인이 필요하다.
• API 가격 경쟁력(Opus 대비 5~10배 저렴)은 실무 의사결정에서 충분히 의미 있는 변수이다.

열린 질문

1. SWE-Bench Pro의 오염 저항성은 몇 개월까지 유지되는가? LiveCodeBench처럼 롤링 업데이트 없이 정적 데이터셋으로 남는다면, 차기 릴리스에서의 점수 상승을 어떻게 해석해야 하는가.
2. 사실 환각(존재하지 않는 코드 구조에 대한 주장)의 빈도가 장기 호라이즌 작업에서 어떻게 누적되는가? 이를 정량화할 공개 벤치마크는 아직 없다.
3. MoE 아키텍처의 실질 로컬화 시점은 언제인가? 양자화·오프로드·전문가 프루닝이 듀얼 GPU 소비자 장비에서 사용 가능한 속도를 낼 수 있을지.
4. 에이전트 프레임워크가 모델 체감 성능에 미치는 영향을 어떻게 통제할 것인가? Hermes, Claude Code, Cline 간의 격차가 모델 간 격차보다 클 수 있다.

더 나아간 관점

이 토론이 진짜로 말하고 있는 것은 “GLM-5.1이 Opus보다 나은가”가 아니라, 오픈소스 코딩 생태계가 ‘더 이상 한 세대 뒤처지지 않는다’는 새로운 국면에 진입했다는 사실입니다. 차이는 월 단위로 좁혀지고 있고, 이는 독점 모델의 해자를 “원시 능력치”에서 “툴 통합·안정성·엔터프라이즈 신뢰”로 이동시킵니다. 실무자의 최선의 전략은 “한 모델에 올인”이 아니라, 프런티어 모델을 검증자·리팩토러로, GLM-5.1을 탐색·생성·장기 루프 실행자로 조합하는 하이브리드 스택을 구축하는 것입니다. 영상의 발표자가 직관적으로 한 것(Opus로 GLM 결과를 교차 검증)이 사실상 이 전략의 초기 형태이며, 2026년 하반기의 표준 워크플로우로 자리 잡을 가능성이 높습니다.

오픈소스의 승리 여부는 “Opus를 이기는 한 방”이 아니라, “Opus와 협력 가능한 동료”가 되는 것에 달려 있습니다. GLM-5.1은 그 문턱을 넘은 첫 모델로 기록될 자격이 충분합니다.

GLM-5.1 첫인상: 최고의 오픈소스 코딩 모델일까?

원본: https://www.youtube.com/watch?v=y-e8QiUXdpE · 업로드: 2026-04-08 · 길이: 12m · 채널: Onchain AI Garage

도입: GLM-5.1의 등장

Z.ai가 방금 GLM-5.1(GLM 5.1)을 공개했습니다. 여러 소프트웨어 엔지니어링 벤치마크에서 오픈소스 진영 최고 성능을 주장하는 모델입니다. 지난주에 리뷰했던 GLM-5V Turbo가 비주얼 코딩에 초점을 맞춘 멀티모달 모델이었다면, 이번 GLM-5.1은 Opus(오푸스)나 GPT-5.1 같은 프런티어 모델과 정면으로 비교될 법한 본격적인 코딩 특화 모델입니다.

공개된 벤치마크 차트를 보면 최상위 프런티어 모델에는 살짝 못 미치지만, Qwen 3.6+, MiniMax M27, Kimi K25처럼 오픈소스 코딩 모델 진영에서 인기 있는 모델들보다는 앞서 있습니다. 특히 에이전틱 코딩(agentic coding) 영역에서는 BenchPro 기준으로 GPT-5.4와 Opus 4.6보다 오히려 근소하게 앞서 있다고 주장합니다.

자율 코딩 능력과 라이선스

Z.ai가 유난히 강조하는 것은 이 모델의 “자율 설계·코딩” 능력입니다. 예시 데모에서 GLM-5.1은 단일 작업에 약 8시간을 루프 안에서 소비하며, Linux 데스크톱을 맨바닥에서부터 쌓아올립니다. 기능, 스타일링, 상호작용을 스스로 다듬어 가는 식으로, 장기 호라이즌(long-horizon) 코딩 작업에 최적화되어 있다고 합니다. 제작사는 모호한 문제에서도 더 나은 판단을 보이며 반복을 통한 최적화를 지속한다고 설명합니다.

OpenRouter(오픈라우터)에서는 이미 API로 사용 가능하며, 가격이 상당히 공격적입니다. 무엇보다 오픈소스로 풀렸기 때문에 이론적으로는 로컬에서 무료로 돌릴 수 있습니다. Hugging Face(허깅 페이스)에도 이미 GLM-5.1이 올라와 있고, 커뮤니티 멤버들이 양자화(quantization) 작업을 시작한 모습도 보입니다. 다만 파라미터 규모가 7,540억(754B)이라 제 개인 컴퓨터로는 도저히 돌릴 수 없습니다. 그래도 Opus나 GPT-4 Turbo API에 비하면 훨씬 저렴하고, 다른 오픈소스 제공자들이 내놓은 코딩 모델들과 비슷한 가격대이면서 성능은 프런티어 급에 근접합니다.

테스트 환경: Hermes 에이전트

이번 영상은 GLM-5.1 첫인상 리뷰입니다. 로컬에서 돌릴 수 없으니 OpenRouter를 경유하고, 실제 코딩 작업 평가는 Hermes 에이전트(Hermes agent)를 통해 진행했습니다. 새 모델이 너무 자주 쏟아져서 모두를 다룰 수는 없지만, “오픈소스 코딩 모델 1위”라는 주장 하나만으로도 이 릴리스는 충분히 의미 있는 이벤트라고 판단했습니다.

첫 번째 과제: 실험적 어텐션 레포 리뷰

첫 번째 작업으로 제가 작업 중인 실험적 레포를 가리켰습니다. 내일 에피소드에서 심도 있게 다룰 예정인 주제인데, 스파스 어텐션(sparse attention) 기법을 다른 어텐션 방식을 쓰는 기존 오픈소스 모델에 이식해 보려는 실험용 코드 베이스입니다. 과제는 간단했습니다. “이 코드 베이스를 리뷰하고, 주제에 대해 리서치한 뒤, 속도와 성능을 개선할 수 있는 리비전 다섯 가지를 제안해 달라.”

Hermes 에이전트 화면에서 GLM-5.1이 실시간으로 하는 작업이 전부 보입니다. 툴 콜이 돌아가고, 리서치를 위해 별도 서브 에이전트를 띄우고, 우리가 이식하려던 어텐션 기법을 파고듭니다. 결과적으로 제안된 다섯 가지는 모두 자신이 찾아본 논문들에 기반한 구체적인 것이었고, 제 코드 베이스의 특정 라인 번호까지 인용하면서 최종 기대 결과를 함께 제시했습니다. 꽤 인상적인 결과물입니다.

이 제안들의 품질을 교차 검증하기 위해, 같은 제안들을 Claude Opus 4.6(클로드 오푸스 4.6)에게 넘겼습니다. 이 레포를 실제로 구축했던 원본 세션이라 해당 주제에 대한 맥락과 디테일을 가장 많이 가지고 있는 모델이었기 때문입니다. 검증 결과, GLM-5.1이 내놓은 제안 중 마지막 “보너스 제안” 하나는 환각(hallucination)이었습니다. 실제로는 존재하지 않는 truncation을 있다고 착각한 것입니다. 그 외 제안들은 모두 정당했고, 일부는 타당하지만 제 하드웨어에선 실현 불가능했으며, 일부는 이미 아직 레포에 업로드하지 않은 제 다른 브랜치에서 구현이 끝난 것이었습니다. 즉 빠른 1차 패스치고는 딥 리서치 없이도 상당히 괜찮은 리뷰 품질입니다.

장기 호라이즌 특성 덕분에 이 제안들을 하나씩 실제로 구현해 보고, 결과가 좋으면 유지하고 아니면 버리는 식으로 작업을 이어갈 수도 있습니다.

두 번째 과제: 트레이딩 전략 추출과 페이퍼 트레이더 구축

두 번째 과제는 훨씬 더 야심찬 것이었습니다. 매우 긴 트레이딩 저널 트랜스크립트를 여러 개 가지고 있는데, 누군가가 자신의 트레이드를 분석하며 설명하는 내용입니다. GLM-5.1에게 요구한 것은: (1) 이 트랜스크립트들을 분석해 실행 가능한 트레이딩 전략을 추출하고, (2) Hyperliquid(하이퍼리퀴드) API 같은 라이브 API를 써서 스크리너와 모니터를 구축하고, (3) 실제 페이퍼 트레이더까지 만들어 달라는 것이었습니다. 이건 확실한 코딩 과제입니다.

작업을 넘겼는데 초반에 툴 이슈가 있었습니다. 첨부해 둔 트랜스크립트를 인식하지 못해 결국 다시 직접 첨부해 줘야 찾았습니다. 새 모델을 쓸 땐 항상 이런 과정이 필요합니다. 어떤 부분에 강하고 어떤 부분에 약한지, 어떻게 써야 하는지를 실시간으로 파악해 가야 합니다.

작업이 진행되는 동안 파일 몇 개를 작성하고, Hyperliquid API 테스트 중에 레이트 리밋(rate limit)에 걸렸습니다. 이후에는 보다 보수적인 레이트 리밋으로 조정해 에러를 회피했습니다. 먼저 구축된 기반은 설정(config) 파일과 Hyperliquid 데이터 피드 두 가지였고, 그 위에 ICT(Inner Circle Trader) 분석, 트레이딩 시그널 엔진, 라이브 스크리너, 페이퍼 트레이더, CLI 엔트리 포인트를 계획만 잡아 둔 상태였습니다. 약 30~40분이 지난 시점까지 이만큼을 제가 추가 프롬프트를 거의 넣지 않고도 해낸 것입니다. 체감상 Opus 4.6보다는 확실히 느리지만, 작업을 완수하는 데는 문제가 없었습니다.

결과: 한 시간 만의 풀 스택 트레이딩 봇

GLM-5.1은 결국 ICT 스크리너와 페이퍼 트레이더 전부를 완성했습니다. ICT 트레이딩 영상들의 트랜스크립트 더미를 입력으로 받아 실제 트레이딩 전략을 증류해 낸 것입니다. 결과물에는 ICT 전략의 핵심 요소인 공정가 갭(fair value gap), 오더 블록(order block), 스윙, 유동성 풀이 모두 포함된 코어 ICT 엔진이 들어 있었습니다. 거기에 스크리너와 페이퍼 트레이더를 위한 Python(파이썬) 스크립트까지 만들어 냈고, 3일치 백테스트를 실행한 결과 승률 37%에 $7,490 수익을 기록했습니다. 승률은 낮지만 승자가 패자의 3~4배를 먹는, 전형적인 ICT 리스크·리워드(R:R) 접근이 설계대로 작동한 셈입니다.

첫 과제를 10:45에 넘겼고 12시 직전 즈음에 끝났으니 대략 1시간이 조금 넘게 걸렸습니다. 느린 건 맞지만 제가 계속 붙어서 지시할 필요는 없었습니다. 기본 지시를 한 번 주고 나서 제 명령은 대부분 API 이슈에 대한 질문이었고, 그마저도 레이트 리밋 때문이었습니다. 모델을 일일이 베이비시팅하지 않아도 됐다는 점이 핵심입니다. 화면에 보이는 WSL 터미널에서 스크리너가 30초마다 스캔하며 SPX 가격 변화를 잡아내고 있는 모습이 그 결과물입니다.

총평

요약하면, 이 작업은 큰 데이터셋 분석 → 전략 추출 → 스크리너·페이퍼 트레이더 코딩이라는 여러 단계가 얽힌 복합 과제였는데 GLM-5.1은 거의 원샷(one-shot)으로 완성해 냈습니다. Opus보다 오래 걸리긴 했지만 제 주의를 훨씬 덜 요구했고, 최종 결과물은 전에 Opus가 만들어 준 것과 거의 동등한 수준입니다. 속도에서 약간의 희생은 있지만 품질은 확실합니다. 벤치마크 성적이 왜 그렇게 높은지 납득이 가는 결과입니다.

가장 흥분되는 점은 이 모델이 오픈소스라는 사실입니다. 저는 로컬에서 돌릴 수 없지만, 커뮤니티가 작은 하드웨어에서 동작하는 커스텀 버전을 이미 만들고 있을 것이 분명합니다. 로컬에서 돌리면 무료, API로 써도 저렴한데, 코딩과 에이전틱 코딩 벤치마크에서 프런티어에 근접하거나 약간 앞서는 모델이라는 점에서 매우 인상적입니다.

오늘은 GLM-5.1 첫인상 리뷰였습니다. 여러분의 경험도 궁금합니다. 이미 사용해 보셨나요? 다른 오픈소스 코딩 모델보다 선호하시나요? 의미 있는 모델이 나올 때마다 계속 첫인상 리뷰를 해 보겠습니다. 좋아요와 구독 부탁드리며, 다음 영상에서 뵙겠습니다.

So Z.ai just released GLM5.1, which is an open-source model that boasts the highest performance in terms of many software engineering benchmarks.
Last week, I just reviewed the GLM5V Turbo, which was more of a multimodal model focused on visual coding.
This is more a straight-up comparison to something like Opus or a GPT-5.1.
You see how it compares here to a lot of the current models in terms of coding performance.
Slightly below these top-tier frontier models, but ahead of something like Qen 3.6+.
Minimax M27 or Kini K25, which are models that a lot of people like in terms of open-source models that do coding tasks.
In terms of agentic coding, it's actually slightly ahead of GPT-5.4 and Opus 4.6.
In this BenchPro benchmark, at least.
Something that they're kind of boasting is this ability to code or design autonomously.
This one is spent eight hours in kind of a loop with one task, refining the features, styling, and interactions in order to build a Linux desktop from scratch.
So it's specifically built for more longer-horizing coding tasks.
And they say it shows better judgment with ambiguous problems and sustains optimization through iteration.
And on OpenRouter right now, you can get it, and the pricing is very competitive if you're using it with the API.
This was an open-source model, so you could actually run it locally right now for free.
It's available on Hugging Face already, GLM 5.1.
And I've already seen some community members have started with quantization trees.
But it is quite large.
754 billion parameters.
I can't obviously run this on my computer here.
But even with the API, it's much cheaper than something like an API.
I can run it on an Opus or a GPT-4 Turbo.
And it's in the ballpark of other coding models from open-source providers.
But despite the reasonable price, it boasts some coding abilities similar to those frontier models.
So in today's video, this is going to be a first look at GLM 5.1.
I'm going to be running it through OpenRouter since I can't do it on my own computer.
And specifically, I'll be using it through my Hermes agent to see if it can perform any coding tasks.
And there's new models coming out all the time.
I'm not going to be able to do a test or first look at all of them.
But I thought this was significant since it's number one in open-source coding models.
So it's a pretty significant release.
So the first thing I did is I pointed it to this repo, which is a code base that I've been working on.
And if you want to see this in-depth look in tomorrow's episode, which is going to be on attention.
And basically, this is a repo, an experimental one, where I was trying to adapt this sparse attention method onto existing open-source models.
That use a different type of attention.
It's a highly experimental repo that I have here.
But one that I'm trying to actively work on.
So the first thing I'm going to ask it is I said I want you to review this code base that I have.
Do research on the topic and suggest five revisions or improvements to enhance speed or performance.
So you can see this is Hermes agent.
So you can see all the what it's doing in real time.
These little tool calls.
It's now spun off another agent to research.
Which is the type of attention method that we were trying to adapt here.
And here are the ones that it is suggesting based on its research and based on its review of my code base.
And the suggestions are very specific based on papers that it did.
You can see it references specific lines in my code base.
It tells you what it expects at the end.
So this is pretty good list.
And to just check the agent's work.
I gave it the.
Improvements that it suggested and had Claude.
This is called Opus 4.6.
And this was the session where I actually built this repo.
So it has the most detail and most research on this topic.
The one thing it did find is that last little section.
It hallucinated that kind of bonus suggestion.
There was no actual truncation.
The Hermes agent hallucinated that.
But otherwise, the suggestions that made were legitimate and valid.
Some were valid, but not feasible.
With my hardware, and some were actually done in versions that I haven't uploaded to the repo yet.
So in general, it's research and suggestions were all good, except for that one hallucination.
But considering it just did a quick pass, it hadn't done deep research on this topic.
It's a pretty good result.
So this is a pretty good job of a code base review and research and adapting new features.
And we could actually go in and try each of these.
One of the nice things about this model is the long.
Horizon tasks.
So we could go and try to implement each of these, see how the results are.
And then either keep or discard that change.
And for the next task, I wanted to review these transcripts.
I have several very, very long transcripts of trading journals, basically someone breaking down their trades.
And what I'm going to ask it to do is to review these trades, review these transcripts rather try to extract a executable trading strategy based on the transcripts.
And then actually build a screening monitor using live api's.
I think we'll probably use hyper liquid api because they tend to be the best for this kind of thing.
And then to create an actual paper trader so we can implement from these video transcripts into an actual trading algorithm and then a paper trader.
So this is actually going to be a coding task for it.
Let's see how it does.
Okay, so I sent it the transcripts.
And the idea is to try to use this as a long horizon task where I'm going to have it regularly monitor.
The.
Payment.
Paper trader and the strategy to see what's working and what's not working and to constantly adapt the strategy based on that.
It had some tooling issue, even though this was attached here, it couldn't find it.
And then I attached it directly and then it did find it a little bit quirky.
I guess you would say you have to whenever using a new model, you need to figure out what it's good at and what it is not good at and basically how to use it properly.
So we're figuring that out live here.
Okay, it's slowly working through.
This long task, so I'll just let it run and we will see what we get.
Okay, you can see it did a lot of work here, did a lot of research on what I was asking it.
It wrote some files, hit a rate limit with the hyperliquid when it was testing it, the hyperliquid API.
So we're going to use a more conservative rate limit so we don't hit those those errors.
So so far, what it has built is a couple of Python scripts, the config file, which has all the settings, the data feed, which is what we're gonna need for a.
Hyperliquid data from the API, it's built those two as the foundation.
And right now it has planned these out, but it hasn't built them yet, which is the ICT analysis, the trading signal engine, and then the live screener and then the paper trader and then the whole CLI entry point.
So you can see it took around 40 or 30, 30 minutes to get that far, but it was able to do a lot without me having to add extra prompts to it.
So let's let it build the rest of it.
Okay.
So let's let it build the rest of the scripts that it needs to do.
So it is a bit slower, I would say, than the Opus 4.6, which I'm used to using.
I actually did a similar project using that, and it's certainly slower, but it's been able to do everything.
We'll have to see if it actually works at the end, but it has a good plan.
You can see everything it did to write all the files over here.
See, this is Hermes agent specifically, but it wrote a bunch of.
It's based on this task itself.
It's more of a Hermes agent feature, but you can see it's all done.
It did take a while, but we got it didn't take a lot of prompting for me.
It did the ICT screener and paper trainer.
So it was able to process what was basically just a bunch of transcripts of ICT videos, trading videos, and was able to distill a trading strategy from it.
You can see here it has the core ICT engine.
If.
Pair value gaps, order blocks, swings, liquidity pools, all of this, which is key to ICT strategy.
It created this Python scripts for the screener and the paper trader, and it also ran a three day back test.
And it found 37% win rate, but $7,490 profit.
So a low win rate, but the winners are three to four X, the losers.
So it's a classic ICT R and R approach working as designed.
That's a pretty impressive result.
It didn't.
It took a while, took almost an hour.
When did I give it the first task at 1045?
It finished it around 12, 1145, I believe.
Little over, I guess, an hour, a little over an hour.
So it does take a while, but it didn't take a lot of prompting.
Once I gave it the basic instructions, a lot of my commands here were just questions about had some API issues.
And that was, I think, the rate limiting.
But it didn't need me to baby it the whole way.
And you can see this golden outline is screen sharing now from Trimple's laptop.
But you can see this is the screener running in the terminal.
I had to be in W WSL to have it run, but you can see it scanning every 30 seconds and you can see how the SPX price is changing.
So, yeah, it built it very quickly.
I'm actually quite impressed.
For something that had a lot of elements like this up, you see it kind of set up nice bear set up, see if we can make some money here over a task that had a lot of components, analyzing a very large data set, extracting a strategy based on that, and then coding and building this screener and paper trader.
It did it very well and without a lot of direction from me.
So while it took longer, certainly than Opus, it required a lot less attention.
For me, a lot less direction, and it was able to do the task basically one-shotted, and the end result is very similar to what I was getting from the one that Opus built for me.
So you might need to make some sacrifices in terms of speed, but the quality is definitely there.
It makes sense why it did so well in the benchmarks.
And what's really exciting about this and what really sets it apart is that it is an open source model.
So while I can't run it locally, I'm sure there's communities already working to try to make custom versions that can work on.
Small.
Smaller hardware.
So very impressive for a coding model that is open source, free if you run it locally, and fairly cheap if you're using an API.
Getting close to, if not slightly better, benchmarks in terms of coding and agentic coding.
That's going to be it.
This was just a quick look at GLM5.1.
Please let me know what your experience is.
Have you tried this model?
Do you like it?
Do you prefer it more than other open source coding agents?
Coding models, I should say.
But that's going to be it for today.
Please leave a comment.
Please leave a like.
Please subscribe if you'd like to see more.
Whenever a new model comes out that seems significant, I'll always take a first look at it and try to test it out myself.
Models coming out so frequently, I can't do all of them.
But this was a pretty significant one.
So that's going to be it for today.
Please leave a like.
Please subscribe to the channel.
And I will see you in the next one.