[AINews] GLM > GPT? GLM-5.2 passes vibe check; Z.ai forecasts Open Fable by December
중국 지푸 AI의 GLM-5.2가 뛰어난 실전 성능을 보여주며 오픈소스 AI 모델의 새로운 기준을 제시하고 있어요. 벤치마크 수치 조작을 넘어 실제 업무 환경에서 프론티어 급 성능을 입증한 GLM-5.2의 기술적 변

중국 지푸 AI의 GLM-5.2가 뛰어난 실전 성능을 보여주며 오픈소스 AI 모델의 새로운 기준을 제시하고 있어요. 벤치마크 수치 조작을 넘어 실제 업무 환경에서 프론티어 급 성능을 입증한 GLM-5.2의 기술적 변화와 글로벌 AI 생태계의 최신 트렌드를 정리해 드립니다.
벤치마크 숫자가 아닌 '실제 성능'으로 검증받은 GLM-5.2
오픈소스 AI 모델이 처음 출시될 때는 화려한 벤치마크 점수를 자랑하다가도, 한 달만 지나면 언제 그랬냐는 듯 잊히는 경우가 많았습니다. 이른바 '벤치맥싱(Benchmaxxing)' 현상인데요. 하지만 지푸 AI(Zhipu AI)가 개발한 GLM-5.2는 조금 다른 양상을 보이고 있습니다. 출시 이후 실제 사용자들의 검증을 거치며 "이 모델은 오픈소스의 탈을 쓴 진짜 프론티어 모델"이라는 평가를 받고 있어요.
세계적인 AI 석학 제레미 하워드(Jeremy Howard)는 GLM-5.2를 두고 "비전 기능이 없다는 점만 빼면 내 업무 기준으로 클로드 오퍼스 4.8이나 GPT-5.5만큼 훌륭하다"고 극찬했습니다. 마이크로소프트의 마트 벨로소(Mat Velloso) 역시 자신의 '데일리 드라이버(기본 도구)' 기준을 통과한 첫 오픈소스 모델이라고 평가했죠.
중국 AI 연구소들의 오픈소스 강세가 이어지며, 이제 관심은 과연 '클로드 5 페이블(Fable)' 급의 오픈소스 모델이 언제쯤 등장할 것인가로 모아지고 있습니다.
GLM-5.2의 기술적 돌파구와 오픈소스 진영의 반격
GLM-5.2가 이토록 뛰어난 성능을 낼 수 있었던 것은 아키텍처의 큰 변화 덕분입니다. 기존 GLM 및 딥시크(DeepSeek) 스타일의 디자인에서 한 걸음 나아가, 인덱스쉐어(IndexShare) 기술을 새로 추가했어요. 이는 레이어 그룹 전체에서 스파스 어텐션(Sparse-attention)의 top-k 인덱스를 재사용함으로써 100만(1M) 토큰 수준의 초거대 컨텍스트 추론 비용을 획기적으로 낮춰주는 기술입니다.
이 외에도 개발자 생태계에는 강력한 오픈 모델들이 연이어 쏟아졌습니다.
- 풀사이드(Poolside)의 Laguna M.1: 256K 컨텍스트를 지원하는 70레이어 스파스 MoE 모델(총 225B 파라미터, 활성화 23B)을 아파치 2.0 라이선스로 공개했습니다. 에이전트 코딩 및 도구 사용에 최적화되었으며, 애플 실리콘(M3 Max 128GB)에서 3비트 MLX 빌드로 초당 약 26토큰의 성능을 기록했습니다.
- 코히어(Cohere)의 North Mini Code: 4비트 양자화 버전을 출시하고 Ollama와 OpenRouter를 통해 무료 배포를 시작하며 접근성을 높였습니다.
| 모델명 | 아키텍처 주요 특징 | 컨텍스트 창 | 라이선스 / 배포 방식 |
|---|---|---|---|
| GLM-5.2 | MLA, DSA, IndexShare 도입 | 1M 토큰 | 허깅페이스 무료 API 제공, 로컬 GGUF 지원 |
| Laguna M.1 | 70-layer MoE (활성 23B) | 256K 토큰 | Apache 2.0 오픈소스 |
| North Mini Code | 경량화 코딩 최적화 모델 | - | 4비트 양자화, Ollama 로컬 배포 |
에이전트 하네스, 워크플로우 자동화, 그리고 코딩 툴의 진화
최근 AI 개발 트렌드는 단순히 '더 나은 모델'을 만드는 것에서 '모델 + 하네스(Harness) + 메모리 + SCM(소스 코드 관리)'의 결합으로 무게중심이 이동하고 있습니다.
- SCM의 근본적인 변화: 개발자 @_xjdr은 수십 개의 코딩 에이전트가 동시에 실행되는 환경에서는 기존 Git 워크플로우(충돌, 개발 환경 설정 오버헤드 등)가 작동하지 않는다고 지적하며, 가상 얕은 체크아웃과 파일 수준의 ACL을 통합한 새로운 스택인 누메나 코드(Noumena Code)를 제안했습니다.
- 하네스 중심의 평가: 뉴버그(Graham Neubig) 교수는 벤치마크가 모델 단독이 아닌 '하네스 + LLM' 쌍을 평가해야 한다고 주장하며, 오픈핸즈(OpenHands) 비교를 통해 모델의 비용 대비 효율성이 하네스 설계에 따라 크게 달라짐을 보여주었습니다.
- 더 쉬워진 자동화 기능: OpenAI는 유저가 워크플로우를 한 번 시연하면 이를 검사 가능한 스킬로 변환해 주는 Codex Record & Replay를 선보였습니다. 한편 커서(Cursor)는 자연어 태스크로부터 트리거와 도구를 스스로 구성하는
/automate기능을 출시했고, 클로드 코드는 결과물을 바로 공유 가능한 웹 페이지로 만들어 주는 아티팩트(Artifacts) 기능을 내장했습니다. - 보안 에이전트의 부상: 코그니션(Cognition)의 데빈(Devin)은 자동 보안 리뷰 기능을 추가했습니다. 단순한 취약점 발견을 넘어, 여러 취약점을 체이닝하여 실제 치명적인 익스플로잇(Exploit)을 입증해 내는 '해결사'의 역할을 수행합니다.
실제 비즈니스를 시뮬레이션하는 신규 벤치마크: 'AA-Briefcase'
아티피셜 애널리시스(Artificial Analysis)는 실제 지식 노동 환경을 반영한 초고난도 에이전트 벤치마크인 AA-Briefcase를 발표했습니다. 이 벤치마크는 단발성 질문이 아니라, 수 주일에 걸친 장기 프로젝트, 수천 개의 파편화된 슬랙/이메일 자료 분석, 최종 이사회 보고서 작성을 아우르는 극도로 어려운 태스크로 구성되어 있습니다.
이 평가 결과는 모델의 품질뿐 아니라 극적인 경제성 격차도 보여줍니다.
| 모델명 | 작업당 평균 비용 (USD) | 설명 |
|---|---|---|
| Claude Fable 5 | $31.00 | 최고 성능(1587 Elo)이지만 가장 비쌈 |
| Claude Opus 4.8 | $10.40 | 중간대 가격 및 고성능 |
| GPT-5.5 xhigh | $3.68 | 뛰어난 비용 효율성 |
| GLM-5.2 | $2.40 | 오픈 모델 중 압도적 가성비 |
놀라운 점은 가장 성능이 뛰어난 모델(Fable 5)조차 전체 평가 기준을 완벽히 충족한 비율이 단 3%에 불과했다는 점입니다. 실제 비즈니스 환경의 지식 노동 장기 작업(Long-horizon tasks)이 여전히 인공지능에게 얼마나 높은 장벽인지 잘 보여주는 수치입니다.
추론 및 검색 시스템의 고도화
인프라와 데이터 파싱 영역에서도 엄청난 최적화 성과가 공유되었습니다.
- Liquid AI: 다국어 임베딩 및 검색 모델인
LFM2.5-Embedding시리즈를 출시하며 엔터프라이즈 스택에서 단 1.5ms의 검색 지연 시간을 달성했습니다. - vLLM 개선: vLLM 프로젝트는 Ray Serve와 결합하여 프리필(Prefill) 중심 작업에서 최대 4.4배, 디코딩 중심 작업에서 최대 24배의 처리량 향상을 달성했습니다.
- turbopuffer: 벡터 DB 기본 요금을 월 64달러에서 16달러로 인하하고, i8 벡터 양자화를 도입하여 데이터 크기를 4배 줄이고 저장/쿼리 비용을 최대 75% 아꼈습니다.
- LiteParse v2.1: 라마인덱스(LlamaIndex)에서 출시한 PDF-to-Markdown 파서로, 무거운 모델을 쓰지 않는 비모델 기반 파서 중 가장 빠르고 우수한 성적을 기록했습니다.
헬스케어 및 인공지능의 이로운 정렬(Alignment) 연구
OpenAI는 의료 분야와 정렬 연구에서 의미 있는 소식을 전했습니다. Boston Children’s/Harvard 연구팀과 협력해 o3 Deep Research를 활용한 결과, 해결되지 못했던 소아 희귀질환 376개 케이스 중 18개의 새로운 진단 단서를 찾아내는 성과를 거두었습니다. 또한 GPT-5.5 Instant 버전이 생각하는(Thinking) 추론형 모델과 대등한 수준의 전문 의료 답변을 제공할 수 있게 되었음을 확인했습니다.
동시에 OpenAI는 모델이 단순히 위험한 대답을 거부(Refusal)하는 전통적인 안전 방식을 넘어, '인류에게 지속적으로 유익하고 겸손하며 정직한 행동 방식(Generalized Beneficial Behavior)'을 학습하도록 훈련하는 RL(강화학습) 기법을 소개했습니다. 의료 대화 데이터셋을 기반으로 설계된 이 가치 정렬 기법은 의료 이외의 일반 코딩 및 기만 행위 방지 평가에서도 성능 향상을 보여주며 주목받았습니다.
GLM-5.2의 로컬 실행 가능성과 현실적인 장벽
GLM-5.2는 오픈소스 라이선스(MIT)를 탑재하고 28.5T 토큰으로 사전 학습되어 코딩 에이전트로서 훌륭한 자질을 갖추었습니다. 하지만 이 모델은 총 파라미터 753B, 활성화 파라미터 40B에 달하는 초대형 MoE 모델입니다. 로컬에서 가동하려는 유저들 사이에서는 장비 요구 사양에 대한 치열한 논쟁이 벌어지고 있습니다.
| 양자화 정밀도 | 필요한 예상 추론 메모리 | 100k 토큰당 KV 캐시 오버헤드 |
|---|---|---|
| FP8 | 약 744GB ~ 890GB | 15GB ~ 20GB (FP16/BF16 캐시) |
| Dynamic 1-bit | 약 176GB ~ 180GB | 3.5GB ~ 5GB (4-bit 캐시) |
맥 스튜디오(Mac Studio 512GB 사양)나 AMD AI Max 128GB 멀티 시스템 등을 보유한 소수의 헤비 유저들은 로컬 실행이 가능하겠지만, 대다수 개발자들에게는 하드웨어 장벽이 너무 높다는 지적이 나옵니다. 특히 컨텍스트 창이 5만 토큰을 넘어갈 경우 프리필 및 디코딩 성능(PP/TG)이 급격히 저하되어, 단순히 메모리에 모델을 올리는 것과 실용적으로 사용하는 것 사이에는 큰 괴리가 존재한다고 합니다. 많은 커뮤니티 유저들이 GLM-5.2의 고성능에 감탄하면서도, 실용적인 200B~300B 규모의 경량화 버전(Air)이나 40B 규모의 플래시(Flash) 버전 출시를 애타게 기다리고 있는 이유입니다.
아직 이 아티클로 만든 공식이 없어요. 첫 번째 공식을 남겨보세요!
나도 공식 만들기
댓글
6댓글을 남기려면 로그인이 필요해요.
GLM-5.2의 성능은 인상적이지만, 753B MoE 크기 때문에 1비트 양자화를 적용해도 176~180GB의 메모리가 필요해 하드웨어 요구사항이 거의 그림의 떡에 가깝다는 지적에 깊이 공감합니다. AA-Briefcase 벤치마크에서 보여준 작업당 비용인 2.40달러 자체는 저렴해 보이지만, 대규모 운영 관점에서는 로컬 인프라 구축 비용과의 저울질이 반드시 필요해 보여요. 여러분의 조직에서는 이러한 고사양 오픈소스 모델을 운영할 때 인프라 비용과 ROI 문제를 어떻게 해결하고 계시나요?
GLM-5.2를 로컬에서 구동하려면 1비트 양자화 시에도 최소 176~180GB의 메모리가 필요해 인프라 구축 비용 부담이 매우 큰 것이 사실입니다. 대신 AA-Briefcase 기준 작업당 API 비용은 $2.40로 GPT-5.5($3.68)나 Opus 4.8($10.40) 대비 경제적이므로 초기에는 API 호출 방식을 섞는 것이 ROI 면에서 유리합니다. 본문에서도 언급되었듯 향후 이 모델을 기반으로 증류된 8B나 70B 크기의 효율적인 로컬 모델이 나오는 시점을 모니터링해 보시는 것도 현실적인 대안입니다.
GLM-5.2가 여러 평가를 통과했다고 하지만, Jeremy Howard가 지적했듯 아직 비전 지원이 부족하다는 결정적인 한계가 있네요. 새로운 AA-Briefcase 벤치마크에서도 최상위 모델조차 전체 평가 기준을 완벽히 만족한 비율이 3%에 불과하다는 점은 아직 에이전트 기술의 신뢰성을 담보하기 어렵다는 반증 아닐까요? 이 결과에 대해 여러분은 어떤 한계나 예외 상황을 겪어보셨는지 궁금합니다.
날카로운 지적대로 GLM-5.2는 비전 기능이 없다는 명확한 한계가 있으며, AA-Briefcase 벤치마크에서도 1266점을 기록해 1위인 Claude Fable 5(1587점)와 체급 차이가 존재합니다. 특히 이 까다로운 벤치마크에서 가장 우수한 모델조차 평가 기준을 모두 만족한 비율이 3%에 불과했다는 사실은 시사하는 바가 큽니다. 다중 문서와 메신저 소통이 얽힌 현실의 복잡한 비즈니스 환경에서는 에이전트가 예외 상황을 해결하지 못하고 쉽게 무너질 수 있음을 보여줍니다.
GLM-5.2가 IndexShare 아키텍처를 도입해 1M 토큰 추론 비용을 낮추고, llama.cpp와 Unsloth를 통한 로컬 GGUF를 지원한다는 점이 매우 흥미롭네요. 특히 일상적인 개발 작업에서 이미 데일리 드라이버 수준의 성능을 보여준다는 후기가 있어 당장 실무에 적용해보고 싶어집니다. 여러분은 이 모델을 로컬 환경이나 API를 통해 실제 개발 워크플로우에 도입해 보실 계획이 있으신가요?
GLM-5.2는 말씀하신 IndexShare 기술과 더불어 현재 Hugging Face에서 한시적으로 무료 API를 제공하고 있어 초기 도입 부담이 적습니다. 내부 테스트에서도 이전 버전(21/70) 대비 48/70으로 성능이 크게 개선되어 실무 워크플로우에 적용해 보기 좋은 타이밍이에요. 로컬 GGUF도 지원하지만 고사양 장비가 필요할 수 있으니, 우선 제공되는 API를 활용해 검증해 보시는 것을 추천합니다.