지난 2주 동안 GLM 5.2가 많은 화제를 모으고 있으며, 그 이유는 타당합니다. MIT 가중치(weights), 1M 컨텍스트(context), OpenRouter 기준 1M당 약 $1/$4.20의 비용, 그리고 FrontierSWE에서 Opus 4.8과 1점 차이 내로 들어오는 벤치마크 성능 등이 그것입니다. 제가 가졌던 의문은 이것이 실제 업무에서도 잘 버텨주는가, 아니면 다중 파일 빌드에서 맥락을 놓치는 또 다른 벤치마크 튜닝 모델인가 하는 점이었습니다.

그래서 저는 다음과 같은 까다로운 작업으로 테스트를 진행했습니다:
브라우저 CV 스튜디오 구축: 객체 탐지 (TF.js + COCO-SSD), 지속적 추적(persistent tracking), 라인 교차 카운팅, 비디오 프록시 기능을 갖춘 FastAPI 백엔드, 그리고 추적 데이터로부터 LLM이 생성하는 활동 보고서. 프론트엔드 + 백엔드 + CV 파이프라인 + LLM 통합 작업입니다. 약한 모델들은 맥락을 놓치기 쉬운 다중 파일, 다중 라운드 프로젝트입니다.

결론: 잘 버텨냅니다.

공유할 만한 구체적인 사항들:
코드를 작성하기 전의 계획 수립. 애플리케이션 코드를 건드리기 전에 실제 계획 문서(plan doc)를 작성했습니다. 해당 문서에서 모델은 캔버스 오염(canvas tainting) 버그(교차 출처(cross-origin) 비디오를 캔버스에 그리면 픽셀 읽기가 조용히 차단되어 TF.js 탐지를 방해하는 현상)를 미리 예측하였고, 탐지 코드를 작성하기 전에 비디오를 동일 출처(same-origin)로 제공할 FastAPI 프록시를 설계했습니다. 이는 단순히 코드만 작성하는 모델이라면 아무것도 작동하지 않을 때에야 발견하게 될 종류의 버그입니다.

많은 편집 과정에서도 다중 파일 일관성(Multi-file coherence)이 유지되었습니다. 추적기(tracker), 보고 패널, 그리고 백엔드 시스템 프롬프트 간의 JSON 규약(contracts)이 여러 라운드에 걸쳐 일관되게 유지되었습니다. 프론트엔드가 구축하는 JSON, 백엔드가 기대하는 JSON, 그리고 프롬프트가 설명하는 JSON이 모두 일치했습니다. 제가 사용해 본 대부분의 "롱 컨텍스트(long context)" 모델들은 50k 토큰을 넘어가면 규약에서 벗어나기 시작하지만, GLM 5.2는 그렇지 않았습니다.

기본적으로 수행되는 자기 검증(Self-verification). 성공했다고 선언하는 대신, 변경 사항 이후에 프로덕션 빌드를 실행하고 백엔드 라우트를 확인했습니다. 모델이 반복 작업을 수행하도록 허용할 때 매우 중요한 부분입니다.

요청하지 않아도 합리적인 트레이드오프(tradeoff) 결정. CPU 정확도를 위해 lite 모델 대신 Mobilenet_v2 베이스를 선택했고, 이식성을 위해 WebGL 대신 일반 CPU 폴백(fallback)을 갖춘 WASM 백엔드를 선택했으며, 노출된 샘플 레이트 조절 기능을 갖춘 탐지 루프를 위해 requestVideoFrameCallback을 사용했습니다. 요구 사항(brief)에는 아무것도 없었지만, 모두 올바른 결정이었습니다.

GLM 5.2가 부족한 점:

• 텍스트 전용이며, 네이티브 이미지 입력(native image input) 기능이 없습니다. 작업 내용에 모델이 스크린샷이나 비디오 프레임을 직접 보는 과정이 포함된다면, 루프(loop) 내에 별도의 비전 모델(vision model)이 필요합니다.
• 가장 강력한 성능을 보이는 공개 벤치마크(benchmark) 영역은 코딩(coding)과 도구 사용(tool use)입니다. 순수 수학 및 일부 비영어권 언어 작업에서는 최첨단 폐쇄형 모델(frontier closed models)에 비해 성능 저하가 더 눈에 띄게 나타납니다. 작업 부하(workload)가 해당 방향으로 치우쳐 있다면 이 점을 알아둘 가치가 있습니다.

테스트 방법:
제가 작업 중인 자율 AI 엔지니어링 에이전트(Autonomous AI agent)인 Neo 내부에서, OpenRouter를 통해 GLM 5.2를 '자체 모델 가져오기(bring your own model)' 방식으로 사용했습니다.

이것이 벤치마크라고 주장하는 것은 아니며, 하나의 확장된 관찰 결과일 뿐입니다. 해당 리포지토리(repo)는 MIT 라이선스이며, GLM이 생성한 실제 코드를 직접 읽고 판단하실 수 있습니다. 링크는 아래 댓글에 있습니다.

다른 분들도 실제 다중 파일 작업에서 GLM 5.2를 테스트하고 계신가요? 다른 분들에게는 어떤 부분에서 실패하는지 궁금합니다. 품질이 유지된다면 에이전틱 루프(agentic-loop)의 가격 산정 방식(pricing math)은 무시하기에 너무나 매력적입니다.
제출자: /u/gvij
[link] [comments]