GLM-5.2: GPT-5.5를 넘은 MIT 오픈웨이트, 그리고 소버린 서빙의 기회
지난 한 해 동안 “오픈웨이트 모델은 결국 닫힌 모델을 따라잡지 못한다”는 회의론이 꾸준히 있었습니다. 성능은 늘 한두 세대 뒤처졌고, 진짜 프런티어 작업은 GPT나 Claude 같은 API에 맡겨야 한다는 인식이 강했습니다. 중국 Z.ai(구 Zhipu)가 2026년 6월 공개한 GLM-5.2는 이 전제를 정면으로 흔드는 사례입니다. SWE-bench Pro에서 GPT-5.5를 앞섰고, 라이선스는 제약 없는 MIT이며, 가중치를 통째로 내려받아 자체 인프라에서 돌릴 수 있습니다.
저희 ThakiCloud는 K8s 기반 AI/ML SaaS 플랫폼에서 모델 서빙을 다룹니다. 닫힌 API에 의존하지 않고도 프런티어 코딩 모델을 운용할 수 있다는 것은, 온프레미스와 소버린 AI를 사업의 축으로 삼는 회사에게 특별한 의미가 있습니다. 이 글에서는 GLM-5.2가 실제로 무엇인지, 셀프호스팅에 무엇이 필요한지, 그리고 그것이 저희 같은 GPU 클라우드 사업자에게 어떤 기회와 한계를 동시에 던지는지를 정리하겠습니다.
GLM-5.2는 무엇인가
GLM-5.2는 Z.ai의 GLM 계열 최신 플래그십으로, 긴 호흡의 에이전트 작업과 프로그래밍에 초점을 맞춘 모델입니다. 구조는 Mixture-of-Experts(MoE)이며, 총 파라미터는 약 744B에 이르지만 토큰 하나를 처리할 때 실제로 활성화되는 파라미터는 약 40B 수준입니다. MoE 레이어마다 256개의 전문가(expert)가 존재하고 그중 토큰당 8개만 선택되어 작동합니다. 즉 거대한 지식 용량을 가지면서도, 실제 추론 시의 연산량은 40B급 밀집(dense) 모델에 가깝게 유지하는 설계입니다.
컨텍스트 윈도우는 입력 기준 약 100만(1,048,576) 토큰까지 확장되며, 출력은 약 128K(131,072) 토큰을 상한으로 둡니다. 100만 토큰이라는 숫자가 단순한 마케팅 구호가 아닌 이유는, 코드베이스 전체나 긴 작업 로그를 한 번에 모델 컨텍스트에 올려놓고 여러 단계에 걸친 작업을 이어가는 “롱호라이즌” 시나리오를 정조준했기 때문입니다. 또한 GLM-5.2는 추론 강도(reasoning intensity)를 여러 단계로 조절할 수 있어, 품질과 지연 시간 사이의 균형을 워크로드에 맞게 선택할 수 있습니다.
가장 중요한 사실은 라이선스입니다. GLM-5.2의 핵심 가중치는 제약 없는 MIT 라이선스로 공개되었습니다. 기업은 Hugging Face의 zai-org/GLM-5.2 저장소에서 가중치를 자유롭게 내려받아 파인튜닝하거나, 자체 서버나 폐쇄망 환경에서 운용할 수 있습니다. 상업적 이용에 단서를 다는 일부 “오픈” 모델과 달리, MIT는 사실상 가장 자유로운 형태의 허가입니다.
벤치마크: 오픈웨이트가 GPT-5.5를 넘다
GLM-5.2가 주목받는 핵심은 결국 성능 수치입니다. 가장 인용되는 지표는 SWE-bench Pro입니다. 이 벤치마크는 단발성 코드 수정이 아니라, 여러 파일에 걸친 긴 호흡의 실제 소프트웨어 엔지니어링 작업을 에이전트가 해결할 수 있는지를 측정합니다.
| 벤치마크 | GLM-5.2 | GPT-5.5 | GLM-5.1 | Claude Opus 4.8 |
|---|---|---|---|---|
| SWE-bench Pro | 62.1 | 58.6 | 58.4 | n/a |
| FrontierSWE (Dominance) | 74.4% | 72.6% | n/a | 75.1% |
SWE-bench Pro에서 GLM-5.2는 62.1점을 기록하며 GPT-5.5(58.6)와 직전 버전인 GLM-5.1(58.4)을 분명한 차이로 앞섰습니다. 롱호라이즌 코딩을 측정하는 FrontierSWE(Dominance) 항목에서는 74.4%를 기록해 GPT-5.5(72.6%)를 넘어섰고, Claude Opus 4.8(75.1%)과는 사실상 박빙입니다.
수치 자체보다 더 무거운 함의는 비용입니다. VentureBeat의 보도에 따르면 GLM-5.2는 이런 롱호라이즌 코딩 벤치마크들에서 GPT-5.5를 앞서면서도 약 6분의 1 수준의 비용으로 작동한다고 평가됩니다. “성능은 비슷하지만 싼” 정도가 아니라, “더 좋으면서 훨씬 싼” 영역에 들어선 셈입니다. 다만 이 6분의 1이라는 비교는 특정 워크로드와 가격 가정에 기반한 것이므로, 실제 비용 우위는 운용 환경에 따라 달라질 수 있다는 점은 짚어 두겠습니다.
오픈웨이트 모델이 폐쇄형 프런티어를 코딩 같은 고난도 영역에서 따라잡고, 거기에 가격 경쟁력까지 갖춘 사례는 흔치 않습니다. 이것이 GLM-5.2가 공개 5일 만에 실사용 사례 스레드가 쏟아진 배경입니다.
셀프호스팅: vLLM로 GLM-5.2 서빙하기
성능과 라이선스가 매력적이어도, 744B MoE 모델을 실제로 굴리는 것은 별개의 문제입니다. 셀프호스팅의 현실을 숫자로 보겠습니다.
가중치 메모리부터 따져야 합니다. FP8 정밀도에서 가중치는 파라미터당 1바이트로 약 744GB를 차지합니다. BF16으로 올리면 두 배인 약 1,488GB가 필요합니다. 여기에 KV 캐시와 런타임 오버헤드까지 고려해야 하므로, 현실적인 단일 노드 구성은 FP8 기준 8장짜리 H200 노드입니다. H200 한 장이 141GB이므로 8장이면 약 1,128GB의 VRAM이 모이고, 744GB의 가중치를 올린 뒤에도 KV 캐시와 10~20%의 런타임 여유분을 확보할 수 있습니다. 100만 토큰 컨텍스트 워크로드라면 8xH200 또는 8xB200이 권장 구성입니다.
서빙 엔진은 vLLM이 사실상의 표준입니다. vLLM 0.19.0 이상이 GLM 계열 MoE 모델을 지원하며, 핵심 플래그는 다음과 같습니다.
vllm serve zai-org/GLM-5.2 \
--tensor-parallel-size 8 \
--enable-expert-parallel \
--quantization fp8 \
--kv-cache-dtype fp8_e5m2 \
--max-model-len 131072 \
--enable-chunked-prefill
여기서 --enable-expert-parallel은 MoE의 전문가들을 GPU에 분산 배치해 메모리와 연산을 나누는 옵션으로, 이런 대형 MoE를 단일 노드에 올릴 때 핵심이 됩니다. --max-model-len은 기본 워크로드에서는 131072로 두되, 100만 토큰 컨텍스트가 필요하면 1048576까지 끌어올릴 수 있습니다. 더 최신인 vLLM 0.23.0부터는 MTP(multi-token prediction) 기반 추측 디코딩(speculative decoding)을 지원해 처리량을 더 끌어올릴 수 있습니다.
가중치 규모가 부담스럽다면 양자화 변형도 선택지입니다. 커뮤니티와 NVIDIA가 공개한 NVFP4 변형, 그리고 GGUF 변형이 이미 Hugging Face에 올라와 있어, VRAM 예산이 빠듯한 환경에서는 정밀도를 일부 희생하고 메모리를 절약하는 경로를 택할 수 있습니다.
ThakiCloud K8s AI/ML SaaS 플랫폼 적용 및 시사점
GLM-5.2 같은 모델은 저희 ThakiCloud가 그동안 강조해 온 방향과 정확히 맞물립니다. 저희는 닫힌 API에 종속되지 않고 고객의 환경 안에서 AI 워크로드를 운용하는 것을 핵심 가치로 둡니다. 프런티어급 코딩 모델을 MIT 라이선스로 내려받아 자체 GPU에서 돌릴 수 있다는 것은, 그 가치를 실현할 재료가 손에 들어왔다는 뜻입니다.
구체적으로는 다음과 같이 연결됩니다. 첫째, GPU 스케줄링입니다. 8xH200급 노드를 멀티테넌트 환경에서 효율적으로 나눠 쓰려면 작업 큐와 공정한 자원 배분이 필수입니다. 저희는 Kueue 기반의 배치 스케줄링으로 GPU 노드를 관리하므로, GLM-5.2 같은 대형 서빙 워크로드와 학습/파인튜닝 잡을 같은 클러스터에서 우선순위에 따라 배치할 수 있습니다. 둘째, 멀티테넌트 격리입니다. 고객마다 다른 컨텍스트와 데이터를 다루는 코딩 에이전트를 운용하려면 모델 인스턴스와 데이터 경로의 격리가 중요한데, 이는 저희가 K8s 네임스페이스와 네트워크 정책으로 이미 다루는 영역입니다. 셋째, 서빙 스택입니다. 위에서 본 vLLM expert-parallel 구성은 저희가 다른 오픈웨이트 모델을 서빙할 때 쓰는 패턴과 동일한 계열이므로, GLM-5.2를 추가 모델로 편입하는 데 구조적 장벽이 크지 않습니다.
전략적으로 더 중요한 지점은 소버린 AI입니다. 데이터가 외부 API로 나가지 않아야 하는 공공·금융·국방 영역, 그리고 데이터 주권 규제를 받는 환경에서는 “성능 좋은 모델을 우리 망 안에서 돌린다”가 협상의 출발점이 됩니다. GLM-5.2는 그 출발점을 구체화합니다. 폐쇄망에 배치 가능하고, 라이선스가 자유롭고, 닫힌 모델과 견줄 성능을 내며, 운용 비용은 더 낮다고 주장하는 모델이기 때문입니다. 저희 입장에서 이는 “온프레미스로도 충분하다”는 메시지를 뒷받침하는 강력한 사례입니다.
물론 모델 하나가 사업을 만들지는 않습니다. 진짜 가치는 이런 모델을 안정적으로 서빙하고, GPU 자원을 효율적으로 나누고, 고객 데이터를 격리하고, 운용을 관측 가능하게 만드는 플랫폼 계층에서 나옵니다. GLM-5.2는 그 플랫폼 위에 올릴 수 있는 매력적인 콘텐츠일 뿐이며, 콘텐츠와 플랫폼이 함께 가야 의미가 있습니다.
한계 및 반론
GLM-5.2를 무비판적으로 받아들이기 전에 짚어야 할 약점이 있습니다.
첫째, 진입 장벽이 여전히 높습니다. 8xH200 노드는 도입과 운용 비용이 상당합니다. “6분의 1 비용”이라는 주장은 모델을 충분히 가동률 높게 돌렸을 때의 단위 비용이지, 소규모로 띄워 두면 닫힌 API보다 오히려 비쌀 수 있습니다. 활용도가 낮은 GPU는 그 자체로 가장 비싼 자원입니다.
둘째, 벤치마크와 실제 사용은 다릅니다. SWE-bench Pro나 FrontierSWE에서 GPT-5.5를 앞섰다는 것이 곧 모든 코딩 작업에서 더 낫다는 뜻은 아닙니다. 특정 언어, 특정 프레임워크, 도구 호출의 안정성, 긴 세션에서의 일관성 같은 실무 지표는 벤치마크 점수와 따로 검증해야 합니다. 공개 직후의 화제성과 장기 신뢰성은 구분할 필요가 있습니다.
셋째, 공급망과 거버넌스 고려입니다. 중국에서 개발된 모델을 도입할 때 일부 고객은 출처와 컴플라이언스를 문제 삼을 수 있습니다. MIT 라이선스는 법적 자유를 보장하지만, 조직의 정책이나 조달 규정은 별개의 차원입니다. 또한 모델 가중치 자체의 안전성 검증, 학습 데이터의 불투명성 같은 부분은 도입 전 자체적인 평가가 필요합니다.
넷째, 양자화의 함정입니다. VRAM 예산을 맞추려고 NVFP4나 GGUF로 내려받으면 메모리는 절약되지만, 코딩처럼 정밀도가 민감한 작업에서는 품질 저하가 측정 가능한 수준으로 나타날 수 있습니다. “돌아간다”와 “프로덕션 품질로 돌아간다”는 다른 이야기입니다.
결론적으로 GLM-5.2는 오픈웨이트가 프런티어를 따라잡았다는 상징적 사건이자, 온프레미스·소버린 AI 사업자에게는 실질적인 재료입니다. 다만 그 재료를 제품으로 만드는 일은 모델을 내려받는 순간이 아니라, 그것을 안정적이고 경제적으로 서빙하는 플랫폼을 갖췄을 때 비로소 시작됩니다. 저희 ThakiCloud가 집중하는 지점도 바로 그 플랫폼 계층입니다.
