GLM 5.2 대 Opus

 (techstackups.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 같은 원샷 프롬프트로 raw WebGL 3D 플랫폼 게임을 만들게 하자, Opus는 더 빠르고 완성도 높은 결과를 냈고 GLM-5.2는 낮은 비용과 오픈 가중치라는 장점을 보임
  • GLM-5.2는 Z.ai의 MIT 라이선스 오픈 가중치 모델로 1M 토큰 컨텍스트와 High/Max 사고 수준을 제공하지만, 텍스트 전용이라 이미지 기반 자기 검증에는 한계가 있음
  • 실제 테스트 비용은 GLM-5.2가 $5.39, Opus가 약 $21.92였고, 빌드 시간은 각각 1시간 10분 40초와 33분 30초로 속도와 비용의 선택지가 갈림
  • GLM-5.2 결과물에는 텍스처 누락, 작동하지 않는 스파이크, 승리 조건 부재, 디버그 오버레이 잔존 같은 기본 문제가 있었고, Opus는 더 깨끗했지만 얇은 공중 발판 판정과 먼 승리 트리거가 남음
  • 벤치마크와 외부 평가에서도 GLM-5.2는 강한 오픈 가중치 모델로 보이지만, 코딩·에이전트 작업 다수에서는 Opus가 앞서며 비용·개방성·시각 판단이 선택 기준이 됨

같은 과제에서 드러난 차이

  • GLM-5.2는 오픈 모델의 가능성을 보여준 최신 사례지만, 동일한 실전 과제에서는 Claude Opus 4.8이 더 빠르고 정확한 결과물을 냄
  • 테스트는 두 모델에 같은 원샷 프롬프트를 주고, 게임 엔진이나 Three.js 같은 3D 렌더링 라이브러리 없이 브라우저용 3D 플랫폼 게임을 raw WebGL로 처음부터 만들게 하는 방식이었음
  • 두 결과물과 소스는 공개되어 있음
  • 두 게임 모두 무료 CC0 에셋인 Kenney Platformer Kit를 사용함

GLM-5.2의 성격과 접근 방식

  • GLM-5.2는 Z.ai의 최신 플래그십 모델이며, MIT 라이선스 오픈 가중치로 제공됨
    • 다운로드해 직접 실행하거나 Z.ai API로 호출할 수 있음
    • Hugging Face와 ModelScope에 가중치가 올라와 있으며 지역 제한은 없음
    • vLLM, SGLang, Transformers 같은 프레임워크로 로컬 서빙이 가능함
  • 모델은 장시간 다단계 코딩 에이전트 작업 같은 long-horizon 작업을 겨냥함
    • 1M 토큰 컨텍스트 창을 제공함
    • 사고 수준은 High와 Max가 있으며, 테스트에서는 High가 사용됨
  • 결정적인 제한은 텍스트 전용이라는 점임
    • GLM-5.2는 이미지를 읽을 수 없음
    • 스크린샷이나 다이어그램을 직접 확인해야 하는 워크플로에는 Claude Opus 같은 멀티모달 모델이 필요함

가격과 실행 비용

  • 벤더 문서 기준 1M 토큰당 가격은 GLM-5.2가 Opus보다 낮음
    • Claude Opus 4.8: 입력 $5, 캐시 읽기 $0.50, 출력 $25
    • GLM-5.2: 입력 $1.4, 캐시 읽기 $0.26, 출력 $4.4
  • 출력 토큰 기준으로 GLM-5.2는 Opus 가격의 5분의 1 미만임
  • 실제 게임 제작 테스트에서는 시간과 비용이 반대로 갈림
지표 GLM-5.2 (Pi/OpenRouter) Opus (Claude Code)
벽시계 기준 빌드 시간 1시간 10분 40초 33분 30초
출력 토큰 131,000 216,809
최대 컨텍스트 사용량 1M의 16% 1M의 19%
도구 호출 128 153
비용 $5.39 실제 청구액 약 $21.92 추정치
  • Opus는 약 절반의 시간에 끝났고, GLM-5.2는 훨씬 낮은 비용으로 작업을 완료함

테스트 과제: raw WebGL 3D 플랫폼 게임

  • 과제는 단순한 랜딩 페이지 생성보다 구조가 복잡했음
    • GLB 모델 파서
    • 행렬·벡터 수학
    • GLSL 셰이더
    • 스키닝된 골격 애니메이션
    • 고정 타임스텝 루프
    • 충돌 처리
    • 팔로우 카메라
  • 두 모델은 동일한 프롬프트, 동일한 에셋, 힌트 없는 단일 시도를 받음
  • 완성 조건은 다음과 같았음
    • raw WebGL 기반 3D 엔진과 렌더러
    • 제공된 3D 캐릭터와 월드 모델 로더
    • 중력과 충돌이 있는 캐릭터 이동·점프
    • 팔로우 카메라와 키보드 조작
    • 하나의 명령으로 브라우저에서 실행 가능한 전체 게임
  • 두 모델 모두 GLB 바이너리 파서, 행렬·쿼터니언 수학, WebGL2 렌더러, GLSL 스키닝 셰이더, 서브스텝 AABB 충돌을 상당 부분 직접 구현함
  • 빌드 기록도 공개되어 있음

플레이 결과와 남은 버그

  • 두 게임 모두 세 번째 사람 시점의 3D 플랫폼 게임 형태를 갖춤
    • WASD 또는 방향키로 이동
    • Space로 점프
    • Shift로 달리기
    • 마우스 드래그로 카메라 회전
    • 휠로 줌
    • 코인을 모으고, 스파이크를 피하며, 깃발에 도달하는 목표를 가짐
    • 맵 밖으로 떨어지면 시작점으로 돌아감

  • GLM-5.2 결과

    • GLM-5.2의 게임은 전반적으로 거친 완성도를 보임
    • 캐릭터 일부 머티리얼이 빠지고, 캐릭터가 이동 방향과 반대로 돌아선 채 걷는 문제가 있었음
    • 스파이크 함정은 캐릭터를 죽이거나 리셋하지 않았고, 깃발에 도달해도 승리 조건이 발동하지 않음
    • 카메라가 움직일 때 머리가 사라졌고, 디버그 오버레이도 남아 있었음
    • 스프링을 밟으면 다음 플랫폼까지 캐릭터가 튀어 오르는 부분은 잘 동작함
    • Kenney 모델은 별도 파일의 공유 색상 팔레트를 참조하지만, GLM-5.2의 렌더러는 이 파일을 로드하지 않아 평면 색상으로 대체됨

  • Opus 결과

    • Opus의 게임은 더 깨끗하고 잘 동작함
    • 카메라와 컨트롤러가 작동했고, 스파이크가 플레이어를 죽이는 로직도 동작함
    • 텍스처가 제대로 적용되고 애니메이션이 부드러웠으며, 깃발에 도달하면 승리할 수 있음
    • 남은 버그는 기본 기능보다 엣지 케이스에 가까웠음
    • 플랫폼 옆 공중에 캐릭터가 잠시 서 있을 수 있었고, 이는 엣지에서 벗어난 직후에도 점프를 허용하는 coyote-time 유예 시간이 과하게 설정된 결과임
    • 깃발에서 아직 꽤 떨어져 있어도 승리 조건이 발동함

자기 검증에서 갈린 멀티모달 차이

  • 두 모델 모두 작업을 끝내기 전에 결과를 검증하라는 지시를 받음
  • Opus는 멀티모달 모델이라 게임을 렌더링한 뒤 캡처된 스크린샷을 직접 검사함
    • 화면에 남아 있던 디버그 표시를 보고 제거한 뒤 마무리함
    • 최종 장면에서 블록, 계단, 코인, 보석, 스파이크, 깃발, 캐릭터, 점수 HUD, 조명과 지오메트리를 확인함
  • GLM-5.2는 이미지를 읽을 수 없어 스크린샷을 직접 보지 못함
    • 대신 원시 픽셀 데이터를 읽고 색상이 기대값과 대략 맞는지 확인하는 우회 방식을 사용함
    • 저장된 이미지에서 grass green, dirt brown, coin gold, flag red, character bluish, half-Lambert lit, no black 같은 색상 조건을 확인함
  • 이 방식은 실제 화면의 문제를 놓침
    • 캐릭터가 회색으로 보이고 텍스처가 누락된 상태였음
    • 디버그 오버레이가 여전히 화면 위에 남아 있었음
  • 시각적 결과물이 중요한 작업에서는 이미지를 이해할 수 있는 멀티모달 검증이 실제 품질 차이로 이어짐

벤치마크에서 보인 위치

  • Z.ai의 모델 카드 벤치마크에서 GLM-5.2는 최상위 폐쇄 모델 바로 뒤쪽에 위치하는 항목이 많았고, 일부 추론 벤치마크에서는 앞섬
  • 주요 수치는 다음과 같음
    • HLE: GLM-5.2 40.5, Opus 4.8 49.8
    • HLE with tools: GLM-5.2 54.7, Opus 4.8 57.9
    • AIME 2026: GLM-5.2 99.2, Opus 4.8 95.7
    • IMOAnswerBench: GLM-5.2 91.0, Opus 4.8 83.5
    • SWE-bench Pro: GLM-5.2 62.1, Opus 4.8 69.2
    • NL2Repo: GLM-5.2 48.9, Opus 4.8 69.7
    • ProgramBench: GLM-5.2 63.7, Opus 4.8 71.9
    • SWE-Marathon: GLM-5.2 13.0, Opus 4.8 26.0
    • MCP-Atlas public: GLM-5.2 76.8, Opus 4.8 77.8
    • Tool-Decathlon: GLM-5.2 48.2, Opus 4.8 59.9
  • ArtificialAnalysis의 독립 실행 결과도 GLM-5.2를 강한 오픈 가중치 모델로 평가함
    • Intelligence Index v4.1 점수 51
    • MiniMax-M3 44, DeepSeek V4 Pro 44, Kimi K2.6 43보다 높음
    • TerminalBench v2.1은 78%로, 모델 카드의 81 또는 82.7과는 다른 하네스를 사용함
    • 작업당 출력 토큰은 약 43k로 GLM-5.1의 26k보다 많음
  • 벤치마크 흐름은 실전 테스트와 비슷함
    • GLM-5.2는 오픈 가중치 모델 중 선두권이고 추론에서는 일부 경쟁력이 있음
    • Opus는 코딩과 에이전트 벤치마크 다수에서 앞섬

외부 반응

  • Simon Willison은 GLM-5.2를 “아마도 가장 강력한 텍스트 전용 오픈 가중치 LLM”이라고 평가함
    • 그의 SVG 테스트에서 GLM-5.2는 자전거를 타는 펠리컨을 완전히 애니메이션된 형태로 생성했고, 깨진 부분이 없었음
    • 스쿠터를 탄 주머니쥐 테스트는 이전 GLM-5.1보다 좋지 않아 성능이 균일하지는 않았음
  • Artificial Analysis는 GLM-5.2를 자체 Intelligence Index에서 선두 오픈 가중치 모델로 평가함
    • 같은 수준에서 가장 저렴한 모델로 비용 대비 지능 프런티어에 위치한다고 봄
    • 다만 작업당 약 43k 출력 토큰을 쓰는 토큰 소모가 큰 모델로 표시함
  • Nathan Lambert는 LMArena 리더보드 기준으로 GLM-5.2가 Gemini보다 나은 에이전트라고 볼 수도 있다고 평가했고, MIT 라이선스 오픈 모델로서는 “serious accomplishment”라고 봄
    • 최상위 미국 모델이 여전히 전체적으로 앞서지만, 중국 연구소들이 더 적은 컴퓨트로 높은 점수에 도달하고 있다는 점을 강조함

어떤 모델을 선택할지

  • GLM-5.2는 Opus 가격의 일부로 강한 성능을 내는 오픈 가중치 모델임
    • 비용과 개방성이 중요하고 작업이 주로 텍스트와 논리 중심일 때 적합함
    • 다운로드 가능한 가중치는 폐쇄형 모델처럼 갑자기 은퇴하거나 제한될 수 없음
  • Opus는 테스트에서 더 빠르고 더 깨끗하며 더 정확한 결과를 냄
    • 시각적 결과물을 직접 보고 검증할 수 있음
    • 정확성, 폴리시, 시각적 판단이 중요하고 비용을 감수할 수 있는 작업에 더 적합함
  • GLM-5.2는 Opus를 대체할 주력 모델이라기보다, 저렴하고 항상 접근 가능한 강력한 보조 모델에 가까움

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들
  • 원샷 프롬프팅이 왜 이렇게 큰 소란인지 정말 모르겠음
    정의상 단일 프롬프트 하나가 소프트웨어 프로젝트의 복잡도를 담을 수는 없음. 결국 모델이 학습 말뭉치의 기존 코드를 바탕으로 여러 가정을 해서 결과를 내놓을 뿐임
    차라리 사람이 검토한 명세의 가드레일과 코딩 관례를 지키면서 계획 파일의 단계를 정확히 따라가는 코딩 에이전트를 보고 싶음. 사람이 정한 목표에 대해 에이전트 루프가 가드레일을 벗어나지 않고 목표 완료까지 흔들리지 않는지도 검증해야 함
    또한 만들려는 사용 사례의 맥락을 파악해 기존 코드에서 버그나 성능 개선 가능성을 찾고, 리팩터링을 제안하는 능력이 훨씬 가치 있는 지표임
    • 이 실험은 모델이 다소 모호하고 열린 명세만으로도 주관적으로 좋다고 평가될 결과를 만들 수 있는지 보려는 점에서는 흥미로움
      출력이 입력에 맞는지를 보는 벤치마크라기보다, 출력물이 내부적으로 일관적인지를 보는 것에 가까움. 게임이라면 목표에 도달했을 때 끝나는지, 가시에 닿으면 죽는지, 움직일 때 이상한 경계 사례가 생기지 않는지를 보는 식임
      다만 같은 실행 환경을 쓰고 실험을 여러 번 반복해서 결과의 분산도 봤어야 한다고 봄
    • 문제는 원샷 자체가 아니라 빈 프로젝트에서 시작하는 그린필드 상황임
      예전에는 어떤 프레임워크 README를 따라 빈 프로젝트에서 테스트해 보고 “우리 10년 된 프로덕션 앱에 이 프레임워크가 최고”라고 말하는 엔지니어들을 놀리곤 했음. 그린필드식 사고는 모든 문제의 해법이자 모든 해법의 문제임
      원샷 능력도 중요한 자기 측정 지표라서 재야 하지만, 이미 자리 잡은 대규모 코드베이스를 대상으로 해야 함
    • 지금 당장 심각한 작업을 원샷으로 하려는 사람은 없지만, 그래도 중요한 지표이긴 함
      Claude Code와 Opus가 크게 주목받은 건 실행 환경이 개선되어 사용자 입력 없이도 많은 실수를 스스로 고칠 수 있게 됐기 때문임. 장기적으로는 몇 시간 단위의 자율성과 자기 수정 능력에서 앞으로 가장 큰 개선이 나올 것 같음
    • 원샷은 테스트할 가치가 있지만, “이 명세에 따라 만들어라”처럼 아주 큰 프롬프트일 때만 의미가 있음
      입력 토큰 몇 개로 수백만 토큰을 생성하는 건 별 의미를 전달하지 못한다고 봄
    • 모델이 점점 복잡해지는 지시를 받아 사람 개입 없이 요구사항을 충족할 수 있다면 전체 성능을 꽤 쉽게 판단할 수 있음
      더 좋은 모델을 평가하려면 작업에 요구사항을 더 추가하면 됨. 현실적인 사용 사례는 아니더라도 유용한 방법이라고 생각함
      물론 소프트웨어 엔지니어가 조종하면 모델은 훨씬 나은 결과를 만들 수 있음. 엔지니어에 따라 더 나빠질 수도 있고
  • “같은 원샷 프롬프트로 Claude Opus 4.8과 정면 대결시켰다: 원시 WebGL로 3D 플랫폼 게임을 처음부터 만들기”라는 식의 단일 원샷 실행은 벤치마크도 아니고 현실 사용을 대표하지도 않음
    대부분의 에이전트 사용은 협업형이라서, 작업을 맡겼을 때 테스트 결과를 지어내지 않고 완료하는지 같은 신뢰성과, 내 지시를 따르는지 아니면 자기 생각대로 하는지 같은 조종 가능성을 테스트해야 함
    • 작성자인데 완전히 동의함. 이번에는 벤치마크가 아니라 바이브 테스트로 해본 것이고, 실제 벤치마크는 따로 나열해 두었음
      이 테스트는 두 모델 모두에게 오래 걸리고 기술적으로 어려운 원샷 작업을 줬을 때 무엇을 할 수 있는지 보여줌
      협업, 작업 위임, 완료, 테스트 주도 개발, 조종 가능성을 보는 형식은 향후 꼭 시도해 볼 만한 좋은 테스트라고 봄
    • 반대로 방금 Raspberry Pi 에이전트에 GPT 5.5를 붙여 명확히 정의된 장기 작업을 밤새 돌려뒀는데, 10시간쯤 실행됐고 거의 끝나감. 이런 사용 사례도 유효함
      생각해 보면 내가 하는 에이전트 작업의 대부분은 메인 세션에서 자체 프롬프트로 실행되는 하위 에이전트들임. 이것들도 완전 자율 작업의 짧은 버전으로 볼 수 있음
    • 그래서 정식 벤치마크, 나란히 비교한 긴 분석, 신뢰하는 여러 사람들의 평가를 섞어서 봐야 함
      글에서도 그런 내용을 다뤘고, 이 자체를 정식 벤치마크로 의도한 건 아님. 정식 벤치마크는 이미 충분히 많음
  • Anthropic이 계속 529 Overloaded를 던져서 어제 GLM 5.2에 가입해 써봤음
    마음에 들긴 하지만, GLM 5.2의 xhigh에서 프롬프트 2개를 넣은 단일 세션만으로 5시간 리셋 창의 라이트 플랜 사용량을 22% 먹었음
    결과는 만족스러웠고 품질도 괜찮음. 둘 다 쓰고 싶으니 Anthropic과 GLM을 함께 쓸 수 있는 통합 구독 플랜이 있으면 좋겠음
  • 몇몇 프로젝트에서 GLM 5.2를 써본 느낌은, 코드를 쓰기 시작하기까지 시간이 꽤 걸리고 결코 빠른 모델은 아니라는 것임
    탐색과 계획 단계에서 많이 샛길로 가지만 이후 바로잡고, 조종하기는 쉽지 않음. 나중에 따르지도 않을 내용을 환각하기 때문임. 그래도 출력 품질은 꽤 좋음
    예를 들어 Swift+Zig 코드베이스에서 렌더링을 최적화했는데 5천 개 데이터 항목에서 막혔음. GLM 5.2는 벤치마크를 만들고 데이터를 뽑는 데 20분을 썼고, 답답해서 편집 외 도구 접근을 막고 자리를 비웠음. 약 30분 뒤 돌아오니 이미 만들어 둔 벤치마크와 몇 가지 “결론”을 바탕으로 병목 3곳을 최적화해 두었고, 의심을 검증할 수 없으니 더 많은 데이터가 필요하다고도 했음
    구현은 잘 동작했고 관용적이며 비침투적이었음. 같은 저장소에서 GPT 5.5가 만든 결과보다 더 관용적이었다고도 말할 수 있음. 더 쓰고 싶지만 GPT는 보통 같은 요청을 5배 빠르게 끝냄
    GLM 5.2 덕분에 격리 컨테이너와 JJ 워크스페이스 안에서 여러 개를 병렬 실행하는 구성을 준비하게 됨
    • 얼마 전 중요도가 낮은 작업에 써봤는데, 다른 모델들이 못 풀고 있었고 Opus 4.8을 태우고 싶지 않았음
      macOS 메뉴 막대에서 왼쪽 클릭을 가로채고, Ctrl+클릭이나 오른쪽 클릭이 원래 왼쪽 클릭처럼 메뉴를 띄우게 하되 조건부로 동작하게 하는 문제였음
      문제 해결 세션 중간에 모델을 GLM-5.2로 바꿨고, 다시 프롬프트를 넣지도 않고 추론 중간에 교체했는데 몇 분 뒤 문제가 고쳐짐. OpenCode Go의 구독 기반 할당에서 쓴 건데, 이런 문제는 Opus 사용량을 현재 5시간 창이나 심지어 주간 한도까지 다 태울 수 있었음
    • 전체 추론 흔적을 볼 수 있는 점도 좋음
      모델이 궤도를 벗어나는 걸 보거나 내가 말해주지 않은 부분을 발견하면 멈추고 고칠 수 있음. 또는 왜 그런 선택을 했는지도 배울 수 있어서 나중에 의문을 가질 필요가 줄어듦
    • 내 경험과도 비슷함. Pi에서 쓰고 있는데 똑똑하고 출력도 좋지만, 거기까지 가는 과정이 효율적이지는 않음
    • 가격도 문제임. 써보고 싶었지만 Opus보다 겨우 30% 싼 정도라면 이런 문제들이 있는 상태에서는 선택하지 않을 것 같음
  • “GLM-5.2는 이미지를 읽을 수 없어서 여기서 문제가 생겼다. 멀티모달이 아니기 때문이다. 그래서 스크린샷을 보는 대신 원시 픽셀 데이터를 읽고 색상이 대략 예상대로 나왔는지 확인하는 스크립트를 작성하는 꼼수를 썼다”라고 되어 있는데, 더 나은 방법은 https://github.com/openbmb/MiniCPM-V를 쓰는 것임
    • 맞음. 텍스트 LLM에 시각 전용 에이전트 접근 권한을 주면 그 문제는 해결됨
      정말 원한다면 이미지를 Opus에 호출하게 해도 되고, 그래도 비용은 절약될 것 같음
  • 오픈소스 모델을 실험하려고 Ollama에 가입했음
    지난 3개월 동안은 계속 실험하고 써보는 수준이었는데, GLM은 Claude와 함께 실제 코딩 작업에 매일 쓰는 첫 모델임. 꽤 좋아서 매일 Ollama 사용 한도를 꽉 채우고 있음
    • 흥미롭다. GLM을 어떤 종류의 작업에 쓰고 있는지, Ollama를 통해 유용하다고 느낀 다른 모델은 무엇인지 궁금함
  • GLM은 토큰도 더 적게 내고 도구 호출도 더 적은데, 완료에는 두 배 넘게 걸림
    그 시간이 모델 동작 자체가 아니라면 어디서 쓰이는 건지 궁금함
    개별 도구 호출이 더 복잡해서 오래 걸리는 건가, 아니면 모델이 토큰마다 더 많은 계산을 해서 초당 토큰 수가 낮은 건가?
    • Opus와 GPT 5.5는 작업에 따라 사고와 추론 강도를 조절하는 능력이 매우 좋고, 오픈 가중치 모델들은 아직 그 부분이 덜 좋다고 느꼈음
      거기에 GLM 5.2나 DeepSeek v4 Pro 같은 일부 오픈 가중치 모델은 토큰 생성 속도가 훨씬 느린 편이라 체감 지연에 영향을 줌. 그래도 GLM 5.2를 느린 모델이라고 부르기는 어렵고, 예를 들어 현재 Notion 안에서는 가장 빠른 모델 중 하나임
    • 모델이 도는 데이터센터 영향이 가장 클 가능성이 있음
      또 다른 가능성은 Opus가 전문가 혼합(Mixture of Experts) 같은 방식을 써서 한 번에 메모리에 올리는 모델 부분이 GLM보다 작을 수 있다는 것임
    • 인프라 때문일 수 있음. Anthropic이 훨씬 더 잘 준비되어 있을 것 같음
  • GLM 5.2에는 의미 있는 성공을 제한할 큰 문제가 하나 있는데, 코딩 구독의 가치임
    API 가격만 보면 GLM 5.2가 경쟁자를 이김. 하지만 코딩 작업에 API 과금을 쓰는 건 대기업 정도이고, 이들에게는 크게 보조된 구독형 상품이 점점 사라지고 있음
    동시에 이런 회사들은 직원들에게 중국 API를 쓰게 하지 않을 것임
    개인과 소규모 팀 입장에서는 Z.ai의 코딩 구독이 Anthropic과 OpenAI보다 못함. Claude와는 비슷한 사용량을 얻을 수 있을지 몰라도, Codex는 지불 금액 대비 사용량이 확실히 더 많음
    Z.ai가 GPT5.5와 Opus 4.8을 얼마나 따라잡았는지는 논쟁할 수 있지만, 모두 같은 가격인 세상에서 자유롭게 고를 수 있다면 GLM을 선택하지 않을 것임
    따라서 중요한 질문은 GLM 5.3이나 6에서 Z.ai의 상품이 얼마나 좋아질지, 그리고 OpenAI와 Anthropic이 가까운 미래에 현재 상품을 얼마나 제약할지임
    • 미국 밖에서 보면 다르게 보임. 유럽 회사들은 미국 수출 통제로 Fable을 빼앗겼고, 그 전에는 Anthropic이 데이터를 30일간 보관한다고 발표했음
      언제든 빼앗기지 않을 인공지능을 중심으로 인프라를 구축하는 건 이런 회사들에 즉각적인 가치가 있음. 유럽 밖의 다른 나라들은 가격에 더 민감하고, 중국 기업과 관계를 맺는 데 같은 두려움을 갖지도 않음
    • API 과금을 쓰는 건 대기업뿐만 아니라 OpenCode 같은 서드파티 실행 환경을 쓰는 사람들도 포함됨
      동시에 “이 회사들은 중국 API를 직원들에게 쓰게 하지 않는다”면, GLM을 제공하는 Amazon Bedrock은 누구를 겨냥하는 건지 궁금함
      개인들은 아마 DeepInfra처럼 더 싼 미국 제공업체를 택할 것임. GLM의 캐시 입력은 100만 토큰당 $0.18이고 Opus는 $0.50임. Fireworks AI도 선택지임
    • 개인 구독은 손실을 감수하는 미끼라고 봄. 돈은 기업 토큰 계약에서 벌림
      20달러나 100달러 플랜으로 수천 달러어치 토큰을 써가며 코딩하는 데 익숙해진 직원과 학생들이 기업 지출을 밀어붙일 것임
      경쟁력 있는 중국 모델이 나왔다고 해서 이 기업 지출이 대체되지는 않겠지만, 미국이나 EU에서 호스팅되는 오픈 모델은 그럴 수 있음
      GLM 5.2의 존재는 OpenAI와 Anthropic이 API 접근에 매길 수 있는 가격에 상한을 만들어 줌
    • 중요한 포인트임. API 가격 모델은 MMS에 돈 내던 것이 사라진 것처럼 결국 사라질 가능성이 있다고 봄. 구식 모델임
      대부분의 작업은 코딩 플랜에서 이뤄지고 있을 것이라는 게 내 추측임
      다만 플랜이 사용량 제한 외에도 너무 제약적인 건 짜증 남. 이해는 되지만 불편함. 실제로는 Anthropic과 어쩌면 Google 정도만 정말 엄격한 편임
      Anthropic은 사용이 이용약관에 맞지 않는다고 판단하면 나중에 API 요율로 청구할 수 있다는 정책으로 겁을 줬음. 근거 없는 걱정일 수도 있지만, 실제로 그렇게 할 것 같다는 느낌이 들어서 피하게 됨
    • OpenRouter에 계정과 잔액이 있어서 GLM 5.2를 테스트하다가, 더 나은 조건을 기대하고 z.ai 구독을 보려 했음
      그런데 그쪽 인프라가 명백히 과부하라서 5.2 채팅 요청이 100% 시간 초과됐음. 인프라가 모델 성능을 따라잡으면 나중에 다시 시도해 보고, 그때야 구독 가치가 있는지 판단할 수 있을 듯함
  • 오늘 GLM-5.2가 미적 감각과 UI 작업에서 GPT-5.5보다 훨씬 나아서 놀랐음
    당분간 Conductor를 통한 Claude/Codex 구성은 유지하겠지만, 이 모델 때문에 OpenCode를 설정하고 데스크톱 앱을 내려받아 오늘 작업 대부분을 거기서 하게 됨
  • “GLM-5.2는 비용이 훨씬 적었다. Opus는 절반의 시간에 끝냈고 더 깔끔한 게임을 냈다” 같은 문장을 보면 바로 LLM식 문체가 느껴짐
    모델들이 전부 이런 글쓰기 스타일로 수렴한 것 같고, 성능이 좋아져도 이 부분은 별로 바뀌지 않는 듯함
    • 좋은 피드백임. 이런 LLM식 문체는 지금 겪고 있고 개선하려는 과제임
      기술 글쓰기 업계가 현재 큰 타격을 받고 있음. 회사들은 더 짧은 시간에 더 많은 작업을 요구하고 품질은 크게 떨어지고 있어서, 일상적으로 글의 문장 품질을 다듬을 시간이 점점 줄어듦
      우리는 지금 이 변화의 최전선에서 일하고 있어서 가장 큰 영향을 받지만, 동시에 변화를 먼저 실험할 수 있다는 점은 자극적이면서도 매우 답답함
    • 실제 사람들이 LLM 문체를 많이 받아들이기 시작한 것 같음
    • 맞음. 정말 거슬림. 새로 쓰이는 글의 절반쯤이 이제 같은 “목소리”로 들림
답변달기