Ox Alpha가 놀라운 이유

URL: https://www.youtube.com/watch?v=Xdxp3lbQKyQ 날짜: 2026-08-28 채널: t3dotgg

메타데이터

• 원문 제목: Ox Alpha is INSANE
• 원본 발행일: 2026-08-28
• 영상 길이: 43분 14초
• 원문 채널 표기: Theo - t3․gg
• 모델 정체: 익명 모델명 Ox Alpha로 먼저 공개된 GLM 5.3 Flash
• 주제 분류: AI·LLM, 에이전트 코딩, 모델 비용·성능
• 자막: 영어 자동 생성 자막(한국어 자막 부재로 대체 사용)

---

핵심 질문 / 이 영상이 다루는 핵심 논점

==GLM 5.3 Flash는 최상위 지능형 모델보다 덜 똑똑해도, 매우 저렴한 가격·멀티모달 능력·집요하게 작업을 끝내는 행동성 때문에 실제 에이전트 업무에서 독보적인 가치를 만든다.==

• Ox Alpha는 정체를 숨긴 채 OpenCode와 OpenRouter에서 무료로 풀렸고, 익명 모델이라는 호기심이 사용을 촉진했다.
• 하루 100조 토큰 처리 용량과 수십조 토큰 사용량은 모델을 호스팅하는 규모 자체가 비정상적으로 크다는 신호였다.
• GLM 5.3 Flash는 3,200억 총 파라미터 중 한 번에 약 180억 개만 활성화하는 작은 Mixture of Experts 모델이며, 입력 100만 토큰당 7.5센트, 출력 100만 토큰당 25센트 수준이다.
• 어려운 문제 해결력은 Fable·Soul보다 낮지만, 지시를 유지하고 중간에 추가된 요구를 기억하며 도구·서브에이전트 오류에서 스스로 우회하는 행동성은 탁월하다.
• 자체 하드웨어에서 실행할 수 있는 오픈 웨이트 모델이므로 코드 보안과 프라이버시를 중시하는 사용자에게도 Muse Spark나 DeepSeek V4 Flash보다 실용적인 선택지가 된다.

1. 익명 모델의 등장과 정체

Ox Alpha의 충격은 벤치마크 숫자 하나보다 정체를 알 수 없는 모델이 실제 업무에서 보여 준 비용 대비 행동성에서 출발했다.

1.1. 비정상적으로 큰 무료 서비스 규모

1. 익명 출시가 만든 호기심

   1. Ox Alpha라는 가명: 모델은 처음부터 제작사를 밝히지 않고 Ox Alpha라는 이름으로 공개됐다.
   2. 공개 주체: OpenCode와 OpenRouter가 모델을 알렸지만, 누가 만들었는지는 알려지지 않았다.
   3. 무료 접근성: OpenRouter 사용자는 무료 모델을 과도하게 활용하는 경향이 있고, 실제로 Ox Alpha가 무료였기 때문에 사용량이 급격히 몰렸다.

2. 100조 토큰이라는 처리 용량

   1. 서비스 용량: Ox Alpha에는 하루 100조 토큰(token) 처리 용량이 있다고 공지됐다.
   2. 규모 비교: 사용자가 가장 많이 쓰는 날에도 약 70억 토큰을 소비하고, Google Gemini의 하루 전체 트래픽은 약 150조 토큰으로 추정된다.
   3. 호스팅 난이도: 몇 개 제공업체가 하루 수조~수백조 토큰 범위를 처리하도록 모델을 제공했다는 사실은 숨겨진 컴퓨트(compute) 자원이나 매우 작은 모델 구조를 전제해야 설명된다.
   4. 비용에 대한 초기 추론: 모델이 작고 싸게 실행된다고 해도 하루 100조 토큰은 여전히 상상을 초월하는 처리량이다.

1.2. 초기 벤치마크와 GLM 5.3 Flash 확인

1. 공개된 DeepSuite 문제 비교

   1. Ben Davis와의 테스트: Ben Davis는 공동 팟캐스트와 채널 작업에 자주 참여하는 친구이며, 공개된 DeepSuite 문제의 일부를 Ox Alpha에 풀게 했다.
   2. 비교 점수: 5.6 Soul은 52%, People 5는 65%, Ox Alpha는 80%를 기록했다.
   3. 정체에 대한 의문: 값싼 익명 모델이 더 비싼 모델을 크게 앞서면서 “무언가 이상하다”는 결론이 나왔다.

2. 실제 모델명 공개

   1. 정체: Ox Alpha는 GLM 5.3 Flash였다.
   2. 예상 밖의 등급: 거대한 플래그십 모델이 아니라 Flash 모델인데도 GLM 5.3 일반 버전보다 사용감이 좋았다.
   3. 성능·가격 관계: Opus 4.8과 비슷한 체감 행동성을 보이면서 가격은 10분의 1에서 100분의 1 수준이었다.
   4. 사용 빈도: 정체를 알기 전부터 가장 많이 쓰는 모델 중 하나가 됐고, 정체를 확인한 뒤에도 계속 사용할 만한 모델로 평가됐다.

2. 코드 보안과 공급망을 점검하는 도구

CodeRabbit Security는 모델이 생성하는 코드가 늘수록 커지는 보안 위험을 줄이는 별도 사례로 제시됐다.

2.1. 모델 보안 작업의 한계

1. 일반 모델의 제약

   1. 보안 감사 차단: Fable과 Soul 같은 모델에 애플리케이션 보안 감사를 맡기면 AI 연구소 정책 때문에 보안 작업 자체를 거부하거나 오류를 쏟아낼 수 있다.
   2. 필요한 대안: 코드베이스를 이해하면서 실제로 취약한 지점을 파일·경로 단위로 설명하는 도구가 필요하다.

2. CodeRabbit Security의 역할

   1. PR 검사: Pull Request가 생성될 때마다 보안 리뷰를 수행한다.
   2. 의존성 검사: 프로젝트가 의존하는 패키지와 구성요소의 보안 문제를 함께 점검한다.
   3. 전체 감사: Deep Audit은 코드베이스 전체를 처음부터 끝까지 훑어 잠재적 문제를 찾는다.

2.2. 실제 감사 화면과 조치 흐름

1. 문제 재현 정보

   1. T3 코드베이스 적용: T3 관련 코드 전체에 Deep Audit을 실행한 뒤, 중요하게 여기는 다른 프로젝트에도 같은 검사를 확대했다.
   2. 심각도 공개: 실제로 수정해야 하는 보안 문제는 가렸고, Medium·Low 등급 결과만 화면에 공개했다.
   3. 도달 경로: 보안 설정 오류를 열면 무엇이 잘못됐는지, 어느 파일에 있는지, 어떤 경로로 도달하는지 확인할 수 있다.

2. AI 수정과 추세 확인

   1. Fix with AI: 버튼을 누르면 실제 프로젝트에 수정 Pull Request를 열어 준다.
   2. 프로젝트 관리: 여러 프로젝트의 보안 추세를 시간에 따라 확인할 수 있어 수정이 누적될수록 수치가 내려가는지 추적할 수 있다.
   3. 무료 체험: 가입 후 첫 10회 스캔은 무료로 제공되며, 신청 경로는 soyv.link/codrabbit다.

3. GLM 5.3 Flash를 에이전트 코딩에 연결하기

백만 토큰 컨텍스트와 이미지·오디오·비디오 입력은 GLM 5.3 Flash를 단순 텍스트 코더가 아니라 범용 에이전트 도구로 만든다.

3.1. 컨텍스트와 멀티모달 능력

1. 대형 컨텍스트

   1. 컨텍스트 창: 모델은 100만 토큰 컨텍스트 창(context window)을 지원한다.
   2. 긴 작업의 이점: 긴 저장소, 많은 Pull Request, 장시간 에이전트 실행을 한 컨텍스트에 유지할 수 있다.

2. 완전한 멀티모달 입력

   1. 지원 입력: 이미지·오디오·비디오를 모두 받을 수 있다.
   2. 세대 간 차이: GLM 5.3 Flash가 아닌 일반 5.3조차 스크린샷을 받지 못했던 상황과 비교하면 큰 도약이다.
   3. 에이전트 활용: 코드 실행 결과의 스크린샷을 읽고, 자신의 작업 결과를 시각적으로 점검할 수 있다.

3.2. Codex 안의 OpenRouter 연결

1. 연결 방식

   1. 사용 환경: 주로 T3 코드에서 Codex와 Claude Code를 사용하기 때문에 다른 애플리케이션보다 Codex 내부 연결을 먼저 시도했다.
   2. 프록시 계층: OpenRouter 바인딩을 개인 프록시 계층을 거쳐 Codex에 연결했고, 시행착오 끝에 GLM 5.3 Flash를 T3 코드에서 작동시켰다.
   3. 권장 이유: OpenRouter 측은 이 모델이 에이전트 작업에 적합하다고 권했다.

2. 첫 작업으로 저장소의 기존 작업 평가

   1. 초기 지시: 현재 저장소에서 열린 모든 Pull Request를 살펴보고, 병합 난이도와 사용자 가치에 따라 우선순위를 정하도록 요청했다.
   2. 도구 전환: 파일시스템 MCP resource read 도구를 사용하다 실패하자 명령줄 사용으로 돌아갔다.
   3. 하네스 학습의 흔적: 특정 하네스의 특이한 동작에 맞춰 강화학습된 모델은 그 하네스의 규칙을 잘 따르지만, GLM 5.3 Flash는 Codex 특화 학습이 부족한데도 작업을 계속 수행했다.
   4. GitHub 조회: GitHub fetch를 호출해 현재 열린 PR의 정보와 내용을 수집했다.

4. 수백 개 Pull Request를 처리한 에이전트 행동성

GLM 5.3 Flash의 강점은 완벽한 추론이 아니라 범위를 유지하고, 실패를 스스로 우회하며, 결과를 실제 행동으로 연결하는 능력이다.

4.1. 범위 변경과 추가 지시

1. 필터를 뒤늦게 추가한 상황

   1. 원래 범위: 처음에는 저장소에 열린 모든 PR을 대상으로 했다.
   2. 수정 지시: Codex가 만든 PR은 본문에 표시된 단서를 이용해 모두 제외하고, Fable과 Claude Code가 만든 PR만 검토하도록 요구했다.
   3. 추가 결과물: 관심 PR에 댓글을 남기거나, 휴대전화에서 보기 쉽게 결과를 HTML로 작성하도록 요청할 수 있었다.

2. 범위 유지 능력

   1. 일반적인 실패: 다른 오픈 웨이트 에이전트 모델은 작업 도중 방향을 바꾸면 길을 잃고, HTML 결과를 만들겠다고 답한 뒤 중지 신호를 보내며 멈추는 경우가 많았다.
   2. GLM의 반응: “열린 PR 중 Fable·Claude Code가 만든 것만, Codex 빌드는 제외”라는 추가 조향(steering context)을 작업 범위로 유지했다.
   3. 범위 오류의 책임: 모든 PR을 보라고 했기 때문에 전체 PR을 검토한 것은 모델의 범위 일탈이 아니라 잘못 작성한 사용자 지시의 결과였다.

4.2. 5일치 PR 대규모 감사

1. 감사 프롬프트

   1. 대상: T3 코드에서 최근 5일 동안 업데이트된 모든 PR을 조사했다.
   2. 질문: 어떤 PR이 서로 겹치는지, 어떤 이슈를 해결하는지, 병합 위험은 얼마인지, 병합 가능성에 얼마나 확신하는지, 닫아야 하는지, 행동하기 쉬운 순서가 무엇인지 물었다.
   3. 병렬화: 작업을 작은 단위로 나누기 위해 여러 서브에이전트를 사용하도록 요청했다.

2. 실패를 스스로 복구

   1. 첫 웨이브: 서브에이전트 6개를 시작했고 그중 3개가 API 인증(provider auth) 문제로 실패했다.
   2. 복구: 모델은 실패를 기다리기만 하지 않고 문제를 인식해 직접 감사하는 방식으로 전환했다.
   3. 대체 경로: GitHub inspection skill과 기계 생성 요약을 사용하되, 위험이 높거나 행동하기 쉬운 PR은 직접 검토했다.
   4. 자기 흐름 디버깅: 코드베이스의 버그가 아니라 자신의 도구 호출·위임 흐름을 디버깅하고, 위임 실패 때문에 전체 작업이 막히지 않도록 스스로 우회했다.

3. 감사 결과

   1. 처리량: 최근 5일치 수백 개 PR을 약 20분 안에 분석했다.
   2. 변경 안전성: 저장소 소스는 수정하지 않고 GitHub 메타데이터, diff, 리뷰, CI 댓글, 로컬 소스 컨텍스트를 이용해 보고서를 작성했다.
   3. 링크 품질: PR 번호만 적는 모델과 달리 병합하기 쉬운 PR의 실제 링크를 결과에 포함했다.
   4. 실행 결과: 병합하기 쉬운 것으로 분류된 8개 PR을 실제로 병합했다.

4.3. 후속 검토와 작은 디테일의 가치

1. 병합 후 재검토

   1. 후속 요청: 쉬운 병합으로 판단한 항목을 거의 모두 병합한 뒤, 변경사항을 반영해 다시 검토하도록 했다.
   2. 제외 조건: Draft PR은 무시하고, 같은 5일 코호트(cohort) 안에서 병합 가치와 종료 여부를 다시 판단하게 했다.
   3. 잔여 수량: 병합 후 비초안(non-draft) PR 352개가 남았다.
   4. 이슈 정리: 병합된 PR이 해결한 GitHub 이슈를 찾아 닫았고, 연결된 이슈가 없는 PR도 구분했다.

2. 구체적인 번호와 우선순위

   1. 미해결 주장: 5276, 5289, 7233 이슈를 주장하는 열린 PR은 없다고 확인했다.
   2. 높은 가치 항목: 바쁜 스레드가 클라이언트를 멈추게 하는 문제를 고치는 PR이 발견됐고, 작성 시점 기준 6시간 전에 올라온 실제 PR이었다.
   3. 검토 질문: 해당 문제의 원인이 legacy stream token-by-token 설정인지 묻는 댓글도 확인했다.
   4. 실용적 가치: 이 검사를 하지 않았다면 알아채지 못했을 수정 사항을 찾아 그날 밤 병합할 수 있었다.

5. 가격, 토큰 사용량, 실제 비용

GLM 5.3 Flash의 핵심 가치는 낮은 가격 그 자체가 아니라, 수십억 토큰을 써도 실제 비용이 거의 0에 가까운 상태에서 유용한 에이전트 결과를 내는 데 있다.

5.1. ZAI·OpenRouter의 요금과 속도

1. 호스팅 상태

   1. ZAI 구독: 개인 ZAI 플랜을 프록시 계층에 연결했고, 기존 V2 ZI 코드 플랜에 매달 80달러를 내고 있어 추론을 사실상 무제한에 가깝게 사용할 수 있다고 봤다.
   2. 속도 저하: 초기 테스트 때보다 느려졌고, ZAI의 첫 토큰까지 시간이 4분 40초로 표시된 뒤 실제로는 4.4초였다고 정정했다.
   3. 처리 속도: 사용량이 몰리면서 약 33 tokens per second(TPS)까지 떨어졌지만, 시간이 지나거나 다른 호스팅 업체가 늘면 회복될 것으로 예상했다.
   4. 대체 호스트: 오픈 웨이트로 공개됐고 Base10 같은 업체는 약 114 TPS까지 기록했기 때문에 당분간 Base10 호스트로 연결할 수 있다고 판단했다.

2. 단가

   1. 할인 가격: 입력 100만 토큰당 7.5센트, 출력 100만 토큰당 25센트다.
   2. 비교: 출력 100만 토큰당 25센트는 Gemini Flash 2 수준이며, 무료였던 Ox Alpha보다 비싸도 일반 사용자에게는 여전히 사실상 무료에 가깝다.
   3. 구조적 원인: 모델이 작기 때문에 실행비가 낮고, 오픈 웨이트라 호스팅 경쟁이 붙으면 추가로 저렴해질 가능성이 있다.

5.2. PR 감사의 실제 청구액

1. 초기 추정과 정정

   1. 거친 계산: 1,000개가 넘는 열린 PR 전체를 감사한 비용을 처음에는 약 50센트로 계산했다.
   2. 정밀 계산: 모델에 입력·출력·캐시 토큰을 직접 확인하게 하고 스크린샷을 보여 준 뒤, 캐시 토큰을 충분히 반영하지 않았다는 점을 발견했다.
   3. 최종 수치: 약 60억 입력 토큰 중 대부분이 캐시됐고 출력은 약 30만 토큰이었으며, 실제 계산값은 12.06센트, 즉 약 12센트였다.

2. 비용 대비 결과

   1. 비교 기준: Fable로 자신의 PR만 검사했을 때는 100달러가 넘었지만, GLM 5.3 Flash는 범위를 실수로 훨씬 넓혀 수백 개 PR을 검사해도 12센트에 그쳤다.
   2. 자동화 구상: 3시간마다 봇을 실행해 병합 준비가 됐다고 판단한 PR이 있을 때 알림을 보내면 출시 속도를 크게 높일 수 있다.
   3. 비용의 실감: 60억 토큰 입력, 대부분 캐시, 출력 30만 토큰이라는 작업이 12센트라서 사실상 0달러로 반올림된다.
   4. 경제적 결론: 무료 토큰을 대량으로 제공할 수 있었던 이유는 모델이 거의 비용 없이 실행되기 때문이다.

6. 지능과 행동성은 다른 축이다

모델을 “가장 똑똑한가” 하나로 평가하면 GLM 5.3 Flash가 제공하는 실제 업무 가치를 놓치게 된다.

6.1. 고비용 추론을 무조건 선택하는 문제

1. 사용자 선택의 함정

   1. 최고 설정 편향: 낮음·중간·높음·X-high처럼 선택지가 있으면 많은 사용자가 가장 크고 비싼 모델과 최고 추론 설정을 무조건 고른다.
   2. 사용량 소진: 지능이 필요한 정도를 판단하지 않고 X-high를 계속 사용하면 사용량을 빨리 소진한다.
   3. 불평의 원인: 사용량이 바닥난 뒤 서비스가 나쁘다고 불평하지만, 실제 원인은 모든 작업에 최고 비용 설정을 선택한 데 있다.
   4. 대안: 많은 사용자는 최고급 모델이 아니라 Luna 같은 모델로도 충분히 만족할 수 있다.

2. 업무별 완벽한 모델 선택이라는 환상

   1. 단순 분류의 한계: GLM은 수학, Grock은 농담, Fable은 프런트엔드, Soul은 기계 설정에 강하다고 단정하면 실제 차이를 설명하기 어렵다.
   2. 두 축의 제안: 모델은 지능(intelligence)과 행동성(behavior)이라는 두 축으로 보는 편이 유용하다.
   3. 이상적인 조합: 지능도 높고 행동성도 높은 모델이 가장 좋으며, 한 축이 다른 축을 보완하는 경우도 있다.

6.2. 지능형 모델과 행동형 모델

1. 지능이 높지만 행동성이 낮은 모델

   1. GPT 4.5 사례: 최대 10조 파라미터라는 소문이 돌 만큼 크고, 지식이 많고, 단순 질문에 답하는 능력이 뛰어났다.
   2. 한계: 추론 모델이 아니어서 어려운 문제를 단계적으로 생각하지 못했고, 에이전트 개발 작업을 수행할 만큼의 행동성은 부족했다.
   3. Gemini 3.1 Pro 사례: 스케이트보드 기술명을 설명으로부터 맞히는 Skatebench에서 95~97%를 기록하며 지식·지능은 압도적이었다.
   4. 코딩 실패: “무엇을 바꿔야 고쳐지는가”를 묻는 데는 잘 답하지만 “직접 고쳐라”라고 하면 엉뚱하게 추론한 뒤 코드베이스 전체를 재구축하려 한다.

2. 행동성이 높은 모델

   1. 행동성의 정의: 지시를 계속 유지하고, 도중에 추가된 요구를 기억하며, 스스로 막힌 부분을 풀고, 궤도를 이탈하지 않는 능력이다.
   2. 강화학습의 영향: ZAI는 실제 작업을 수행할 수 있는 프로비저닝 환경에서 모델을 후속 학습(post-training)해 행동성을 높였다.
   3. 기준선: 행동성에는 최소 기준선이 있어야 하며, 그 아래에서는 지능이 높아도 실무적으로 유용하지 않다.
   4. GLM의 위치: GLM 5.3 Flash는 특수한 수학·프런트엔드 문제를 잘 푸는 모델은 아니지만, 시킨 일을 수행하고 중간 지시도 기억하는 모델이다.

3. 서로 다른 균형

   1. Fable: 지능 쪽으로 기울며 행동성은 상대적으로 약하다.
   2. Soul: 작업을 끝까지 해내도록 강하게 강화학습되어 긴 시간 동안 공격적으로 행동성을 유지한다.
   3. Fable·Soul: 두 모델은 지능과 행동성 모두 높아 최상위권 조합으로 평가된다.
   4. GLM의 독특함: 이전에는 “지능은 평범하지만 함께 일하기는 정말 좋은” 모델을 거의 경험하지 못했으며, GLM 5.3 Flash가 그 사례가 됐다.

7. GLM 5.3 Flash의 실제 코딩·비전 사용

저렴한 모델의 가치는 일회성 질문, 반복적인 저장소 감사, 화면 점검처럼 실패 비용이 낮고 실행량이 많은 업무에서 특히 커진다.

7.1. 다른 저가 모델과의 실용적 비교

1. DeepSeek V4 Flash와의 차이

   1. 비전 부재: 다운로드해 실행할 수 있는 DeepSeek V4 Flash에는 비전이 없다.
   2. 비공개 API 예외: DeepSeek 인프라의 비공개 V4 Flash Vision API 엔드포인트가 있다는 이야기는 있지만, 오픈 웨이트 모델의 능력으로 볼 수 없다.
   3. 장기 작업 문제: V4 Flash는 긴 작업에서 산만해지고 길을 잃어 추가 격려와 개입이 필요한 경우가 있었다.
   4. GLM의 우위: GLM 5.3 Flash는 조금 덜 똑똑할 수 있어도 비전을 지원하고 작업을 더 오래 유지하며 더 철저하게 수행한다.

2. 업무 유형별 선택

   1. 일회성 작업: 웹페이지 변경 확인, 단발성 질문, 코드베이스 감사처럼 반복 호출이 많은 작업에 적합하다.
   2. 어려운 문제: Fable이나 Soul처럼 고난도 문제를 해결하는 능력은 낮으므로 핵심 설계·복잡한 디버깅의 주력 모델을 대체하지 않는다.
   3. 현재의 조합: 실제 코딩의 주력은 여전히 Soul과 Fable이지만, GLM 5.3 Flash는 보조 도구로 매우 자주 사용할 만하다.
   4. 하드웨어 실행: 가중치를 내려받아 접근 가능한 하드웨어에서 실행할 수 있다는 점이 추가적인 사용 사례를 만든다.

7.2. 시각 입력으로 자기 작업을 점검

1. PR 감사 비용 점검

   1. 질문: GLM 5.3 Flash가 Codex에서 오늘 사용한 입력·출력·캐시 토큰과 비용을 계산하도록 했다.
   2. 비전 확인: 계산 결과를 스크린샷으로 찍어 현재 스레드에 붙이고, 방금 수행한 작업의 비용이 합리적인지 물었다.
   3. 결과: 모델은 약 60억 입력 토큰과 30만 출력 토큰을 사용한 실행의 비용을 분석했다.

2. 컴퓨터 사용(computer use)

   1. 레이아웃 수정: 모델이 만든 페이지의 레이아웃 문제를 Codex 컴퓨터 사용 기능으로 확인했다.
   2. 자기 디버깅: 화면을 본 뒤 무엇이 잘못됐는지 판단하고 코드의 레이아웃 문제를 수정했다.
   3. 슬라이드 생성: 슬라이드를 만들게 했을 때 예상보다 보기 좋은 결과가 나왔다.

8. 공식 자료의 구조·벤치마크·비용 분석

GLM 5.3 Flash는 단순히 “작은 모델”이 아니라, 긴 컨텍스트 비용과 멀티모달 사전학습을 함께 설계한 모델이다.

8.1. 익명 무료 드롭의 출시 전략

1. 마케팅 효과
   1. 공식 글만 공개했다면: “Frontier Intelligence at Flash Cost”라는 문구만 공식 블로그에 올렸다면 과장이라고 생각하고 관심을 두지 않았을 가능성이 컸다.
   2. 익명·무료의 효과: 제작사를 숨긴 채 무료로 먼저 사용하게 해 실제 경험으로 관심을 만들었다.
   3. 순위 상승: OpenRouter에서 무료 모델을 활용하려는 사용자가 몰려 테스트 기간 중 1위 모델이 됐다.
   4. OpenCode 성과: OpenCode에서도 최고 모델이 되었고, 테스트 기간 중 약 43조 토큰 사용량을 기록했다.

8.2. 아키텍처와 모델 규모

1. 효율적인 어텐션

   1. 하이브리드 구조: Sparse Attention과 Linear Attention을 결합했다.
   2. 서빙 비용: 긴 컨텍스트를 정확하게 유지하면서도 장기 컨텍스트 제공 비용을 낮춘다.
   3. 가격의 안정성: 컨텍스트가 특정 토큰 임계치를 넘었다고 가격이 갑자기 오르지 않고, 길이와 무관하게 같은 단가가 적용된다.

2. 멀티모달 사전학습

   1. 학습 코퍼스: 30조 토큰 규모의 멀티모달 사전학습(pre-training) 코퍼스를 사용했다.
   2. 능력 범위: 이미지 인식뿐 아니라 오디오와 비디오 입력을 처리할 수 있는 기반이 됐다.

3. MoE 규모

   1. 총 파라미터: 3,200억 개(total parameters)다.
   2. 활성 파라미터: 한 번에 작업하는 전문가(expert)에 약 180억 개만 활성화된다.
   3. 비교: Kimi K3는 3조 파라미터이므로 GLM 5.3 Flash 총량은 약 10분의 1이다.
   4. 성능의 의미: 훨씬 작은 규모로 비슷한 체감 성능을 내며, 특히 지시 준수와 에이전트 행동이 좋다.

8.3. 비용-지능 파레토 프런티어

1. 모델 간 비용 지수

   1. 작업당 비용: GLM 5.3 Flash는 약 9센트, Luna는 약 5센트다.
   2. 로그 축 주의: 비용 축이 로그 스케일이어서 그래프상 간격이 실제 차이보다 커 보이며, 절대 차이는 약 4센트다.
   3. 지능 지수: Kimi K3와 거의 붙어 60 대 57 정도로 표시됐다.
   4. 가격의 방향: 더 높은 지능이 비싸지는 현상은 맞지만, 같은 지능 수준에서 가격은 지수적으로 내려가고 있다.

2. 기존 모델과의 비교

   1. GLM 5.2 대비: Automation Bench 등에서 이전 모델보다 크게 앞섰다.
   2. Gemini의 특이점: Automation Bench에서 Gemini가 유난히 잘하는 점은 의외로 평가됐다.
   3. 상위 모델과의 격차: GLM 5.3 Flash는 GLM 5.3 Max보다 조금 낮지만, Max는 대략 10배 비싸다.
   4. Opus 4.8과의 관계: 넓은 벤치마크 묶음에서 Opus 4.8·5.6 Terra와 비슷한 결과를 내면서 가격은 10분의 1 미만이다.

8.4. 코드 작업 토큰 효율

1. ZI CodeBench의 출력 토큰

   1. Fable: 품질 결과에서 가장 높았고, 토큰 효율도 나쁘지 않았다.
   2. Opus 4.8: High와 Max 설정 사이의 비용·토큰 격차가 컸으며, Max는 약 12만 토큰을 사용했다.
   3. GLM 5.3 Flash: High·Max에서 Opus 4.8과 비슷한 위치에 있으면서 약 7만 토큰으로 같은 작업을 수행했다.
   4. 핵심 차이: GLM 5.3 Flash의 High 결과는 Max와 거의 차이가 없고, Opus 4.8의 절반보다 적은 토큰을 사용했다.

2. Artificial Analysis 평균

   1. GLM 5.3 Flash: 작업당 약 4.7만 토큰을 사용했다.
   2. Luna Max: 작업당 약 2만 토큰을 사용했다.
   3. Soul: 작업당 약 1.7만 토큰을 사용했다.
   4. Muse Spark: 비슷한 수준의 작업에 약 3만 토큰을 썼다.
   5. Sonnet 5와 비교: GLM 5.3 Flash는 Sonnet 5보다 거의 두 배 많은 토큰을 사용하는 편이다.

3. 토큰 효율이 중요한 이유

   1. 완료 시간: 토큰을 많이 생성하면 작업이 끝나는 데 더 오래 걸린다.
   2. 컨텍스트 팽창: 모델이 스스로 생성한 토큰이 컨텍스트를 빠르게 채운다.
   3. 실패 확률: 같은 품질을 얻기 전에 컨텍스트가 가득 차면 해결 전에 작업이 중단될 가능성이 커진다.
   4. GLM의 평가: Flash 모델치고는 나쁘지 않지만, 비슷한 지능과 가격이라면 더 적은 토큰을 쓰는 모델이 바람직하다.
   5. 개선 전망: 이번 학습으로 이 정도 품질을 만들었으므로, ZAI가 다음 버전에서 토큰 효율을 높이기는 어렵지 않을 것으로 예상된다.

9. 프런트엔드·카피·애니메이션 생성

GLM 5.3 Flash는 완벽한 디자이너는 아니지만, 적절한 디자인 지시와 비전 피드백을 주면 저가 Flash 모델로 보기 어려운 결과를 만든다.

9.1. 디자인 벤치마크

1. 기본 결과

   1. 스킬 미적용 상태: 기본 디자인은 평범했고, Prague 요소가 레이아웃에 제대로 들어가지 않았다.
   2. 반복 템플릿: 모든 요소가 전형적인 Tailwind 템플릿처럼 보이는 결과가 나왔다.
   3. 터미널 스타일: 흔한 터미널 스타일 가운데서는 가장 덜 민망한 결과로 평가됐다.

2. 디자인 스킬 적용

   1. 개선 폭: Design Scale을 켜자 전체 구성이 훨씬 괜찮아졌다.
   2. 한계: 벤치마크 구조상 생성 과정에서 비전을 사용해 결과를 확인하지 못한 것으로 추정되어 일부 요소는 망가졌다.
   3. 애니메이션: 배경 요소와 텍스트를 움직이고, 스크롤에 따라 카드가 서로 덮이는 인터랙션을 구현했다.
   4. 완성도: 애니메이션이 깨진 부분도 있었지만 방향은 거의 맞았고, 약간의 다듬기만으로 좋은 결과가 될 수 있었다.

9.2. 카피와 Fish Slop

1. 자연스러운 카피

   1. 문장 감각: “Understory grows a private network of notes that get smarter the more you think” 같은 문장이 평범한 LLM 카피보다 자연스럽게 읽혔다.
   2. 희소한 장점: 프런티어 연구소 밖의 모델은 대개 똑똑해도 계속 싸워야 하는데, GLM 5.3 Flash는 지시를 따르면서 카피도 비교적 쾌적하게 만든다.

2. 2D Fish Slop 게임

   1. 기본 구현: 물고기가 돌아다니는 게임을 만들었고, 이동감은 실제로 단단하게 느껴졌다.
   2. 애니메이션: 물고기 이동 순서와 움직임을 조합해 보기 좋은 애니메이션을 만들었다.
   3. 사운드: 사운드를 추가했으며 라우팅이 완전히 설정되지 않았지만 노트북에서 들리는 소리는 괜찮았다.
   4. 세부 표현: 텍스트가 나타나는 방식, 먹이와 상태를 보여 주는 작은 인터랙션 등 여러 디테일을 잘 구현했다.

3. 논리 버그

   1. 먹은 뒤 정지: 물고기가 처음 먹은 뒤 더 이상 움직이지 않는 버그가 있었다.
   2. 배고픔 상태 불일치: 배고프지 않은데도 먹는 동작을 수행했다.
   3. UI 타이밍: 먹이 미터가 플레이 중이 아니라 마지막에 나타났다.
   4. 종합 판단: 논리적 오류는 분명하지만, 프런티어 모델도 더 나쁘게 만들 수 있는 수준의 결과를 100만 토큰당 20센트짜리 모델이 만들었다는 점이 인상적이었다.

9.3. 3D 포팅과 Blender

1. 3D Fish Slop

   1. 포팅: 2D 게임을 3D로 바꾸라고 하자 3D 모델과 나머지 요소를 모두 직접 생성했다.
   2. 완성도 한계: 실제 게임으로 출시하거나 계속 반복 개발할 수준은 아니었다.
   3. 피드백 제한: 컴퓨터 사용이 중간에 계속 실행되는 것이 거슬려 이를 중단하라고 했고, 그 결과 생성 과정에서 시각적 피드백을 많이 받지 못했다.
   4. 가치: 그 조건에서도 3D 버전을 완성한 것은 약 3,000억 파라미터급 모델의 능력으로 상당히 인상적이었다.

2. Blender 환경 생성

   1. 공식 실험: ZAI 팀은 GLM 5.3 Flash에 Blender 장면을 제공했다.
   2. 소요 시간: 모델은 12시간 동안 작업해 레스토랑 주방을 닮은 사실적인 3D 환경 세트를 만들었다.
   3. 품질: Blender를 직접 다루는 사람보다 훨씬 나은 결과로 평가됐고, 실제로 놀라울 만큼 보기 좋았다.
   4. 접근성: 비싼 전용 장비가 아니라 접근 가능한 하드웨어에서 실행할 수 있는 저가 모델이라는 점이 결과의 의미를 키운다.

10. 중국산 AI 칩 위에서 가능한 가격

Ox Alpha에 대량의 무료 사용량을 제공한 배경에는 Nvidia 의존 없이 중국산 하드웨어에서 모델을 서빙한 구조가 있다.

10.1. Huawei Ascend 기반 추론

1. 하드웨어

   1. 칩: 모델은 Huawei Ascend 910 BC에서 전적으로 실행된다.
   2. 메모리 제약: 해당 칩은 메모리 관련 문제가 있어 모델을 상당히 최적화해야 했다.
   3. 트레이드오프: 최적화 과정에서 처리량(throughput)을 희생했을 가능성이 있다.

2. 산업적 의미

   1. Nvidia 비의존: 전체 파이프라인에서 Nvidia 칩을 사용하지 않고도 모델을 서비스한다.
   2. Huawei의 위치: Huawei는 미국에서 대체로 제재받는 중국 기업이지만, 하드웨어 제조 역량은 매우 높다.
   3. 빠른 진입: Huawei가 칩 제조에 빠르게 성공적으로 진입한 과정 자체가 놀라운 변화로 평가된다.
   4. 가격 연결: 값싼 중국산 AI 칩과 작은 활성 파라미터 구조가 결합되어 무료 대량 제공과 낮은 유료 단가를 가능하게 했다.

11. DNSimple이 보여 주는 개발자 중심 운영

DNSimple은 복잡한 DNS 장애를 실제 사람과 개발자 도구로 해결하는 사례로 소개됐다.

11.1. 개발자용 플랫폼

1. SDK와 언어 지원

   1. 대상: 단순 도메인 리셀러가 아니라 개발자를 위한 플랫폼을 지향한다.
   2. SDK: 사용자가 원하는 언어로 작성할 수 있도록 다양한 언어용 SDK를 제공한다.
   3. Elixir: Elixir를 좋아하는 사용자가 반길 만큼 회사가 Elixir를 적극 사용하는 집단이다.

2. CLI의 완전한 제어

   1. 기존 도구의 한계: 다른 도메인 서비스의 CLI는 기능이 제한되어 결국 대시보드에서 특정 설정을 찾아야 하는 경우가 많다.
   2. DNSimple CLI: 클라이언트 라이브러리나 Terraform provider로 할 수 있는 모든 일을 CLI로 할 수 있다.
   3. 에이전트 활용: DNS를 디버깅하는 에이전트가 대시보드를 헤매지 않고 서비스 전체 기능에 접근할 수 있다.

11.2. 사람 중심 지원

1. 작은 회사의 장점

   1. 기업 형태: 대형 VC 투자 기업이 아니라 도메인 관리를 쉽게 만들려는 작은 가족 기업에 가깝다.
   2. 창업자: 부부인 창업자들과 여러 번 대화했고, 처음 협력할 때 손글씨 편지와 귀여운 셔츠를 받았다.
   3. 실제 도움: 다른 서비스에서 DNS 문제가 생겼을 때 창업자들에게 문의해 도움을 받았다.

2. 지원 품질

   1. 사람의 대응: DNS 장애 때 12시간마다 엉뚱한 답을 내는 챗봇보다 웹을 잘 아는 실제 사람이 필요하다.
   2. 추천 이유: DNSimple의 지원은 실제 문제 해결을 이해하는 사람에게 직접 연결되는 점에서 차별화된다.
   3. 혜택: sov.link/dnsimple에서 가입하면 10달러 크레딧을 받을 수 있다.

12. 모델 티어와 최종 선택

티어는 절대 지능 순위가 아니라 각 모델이 제공하는 고유한 실용적 가치를 반영해야 한다.

12.1. GLM 5.3 Flash의 자리

1. 티어 조정의 고민

   1. 실제 사용성: GLM 5.3 Flash는 Soul과 Fable이 너무 강한 환경에서도 실제로 사용할 사례를 확보했다.
   2. 한계: 동시에 지능이 충분하지 않아 수행하지 못하는 작업도 많다.
   3. 세분화 필요: B와 A 사이, A 위에 더 많은 중간 티어를 넣고 싶을 정도로 성격이 다르다.

2. 실용적 배치

   1. 결정: 설명을 단순하게 하기 위해 GLM 5.3 Flash를 Soul 옆으로 올린다.
   2. 기준: GLM이 Kimi K3나 Opus 5보다 더 똑똑해서가 아니라, 다른 모델이 제공하지 않는 고유한 가치가 있기 때문이다.
   3. 핵심 가치: 비전, 저렴한 가격, 오픈 웨이트, 좋은 지시 준수, 긴 작업 유지, 자체 하드웨어 실행이 결합되어 있다.
   4. 3개 모델 조합: Fable·Soul·GLM 5.3 Flash만 있으면 목록의 나머지 모델을 쓸 이유가 거의 없다고 평가했다.

12.2. Muse Spark와 DeepSeek V4 Flash의 하향

1. Muse Spark

   1. 기존 장점: 비전, 빠른 속도, Contributor 티어의 저렴한 가격이 강점이었다.
   2. 데이터 문제: Contributor 티어가 아니면 코드와 데이터를 자유롭게 사용하는 조건을 감수해야 한다.
   3. 비용 문제: 데이터를 덜 자유롭게 사용하는 티어에서는 가격이 10배 비싸진다.
   4. GLM의 대체: 비슷한 가격에 더 나은 행동성과 훨씬 높은 프라이버시를 제공하며, 자체 장비에서도 실행할 수 있다.

2. DeepSeek V4 Flash

   1. 기존 장점: 저렴하고 직접 실행할 수 있다는 점은 매력적이었지만 비전이 없었다.
   2. 티어 하향: GLM 5.3 Flash가 비전과 행동성을 모두 제공하므로 V4 Flash를 더 아래로 내려야 한다고 판단했다.
   3. 중요한 구분: V4 Flash는 모델 이름이고, DeepSeek 인프라의 V4 Flash Vision은 API가 구현한 엔드포인트 기능이다.
   4. 오픈 웨이트 한계: 다운로드해 실행할 수 있는 어떤 DCV4 Flash 버전에도 비전 기능이 있다고 볼 수 없다.

13. 결론 및 실용적 시사점

1. 익명 테스트의 교훈

   1. 선입견 제거: Ox Alpha라는 정체를 모른 채 써 봤기 때문에 GLM 5.3 Flash의 행동성을 과소평가하지 않았다.
   2. 출시 전략: 익명 무료 드롭은 공식 홍보 문구만으로는 얻기 어려운 실제 사용자의 호기심과 검증을 이끌어냈다.

2. 업무 배치

   1. 저비용 반복 업무: PR 정리, 코드베이스 감사, 웹페이지 변경 확인, 단발성 질문에 GLM 5.3 Flash를 배치한다.
   2. 시각 검증: 이미지·오디오·비디오 입력과 컴퓨터 사용을 결합해 생성 결과를 스스로 점검하게 한다.
   3. 고난도 분리: 어려운 설계·수학·복잡한 문제 해결은 Fable·Soul에 맡기고, GLM은 값싸고 긴 에이전트 작업에 사용한다.
   4. 자동화: 3시간 주기 PR 감사와 병합 준비 알림처럼 호출량이 큰 자동화를 시도할 수 있다.

3. 비용·프라이버시 판단

   1. 단가: 입력 100만 토큰 7.5센트, 출력 100만 토큰 25센트는 수십억 토큰 작업에도 매우 낮다.
   2. 토큰 효율: 절대 단가가 낮아도 토큰을 많이 쓰면 완료 시간과 컨텍스트 고갈 위험이 커지므로 효율 개선은 여전히 중요하다.
   3. 자체 실행: 오픈 웨이트와 Huawei Ascend 최적화는 Nvidia 클라우드와 데이터 공유에 덜 의존하는 경로를 제공한다.

4. 최종 평가

   1. 가장 정확한 표현: GLM 5.3 Flash는 가장 똑똑한 모델은 아니지만, 가장 편하게 일을 시킬 수 있는 저가 모델 중 하나다.
   2. 추천 조건: 놀랍도록 저렴하고, 충분히 유능하며, 철저하고, 지시를 잘 따르는 모델을 찾는 사람은 직접 사용해 볼 가치가 있다.
   3. 마지막 농담: Ox Alpha가 Gemini 모델일 것이라고 추측한 사람들에게는 “Gemini가 그렇게 잘 행동할 거라고 정말 생각했느냐”는 식의 농담이 돌아간다.

주요 발언 모음

“When I tell it to do a thing, it does it.”

“This is the first small cheap model that I’ve used that is just a pleasure to use.”

“It will solve easy problems comically cheaper, and it will do real agentic work for you.”

“12 cents to get a useful insight.”

“This model proves out a whole bunch of things that I just would never have believed before it dropped.”

핵심 데이터 & 수치

• 하루 처리 용량: 100조 토큰.
• 사용량 비교: 개인 최고 사용일 약 70억 토큰, Google Gemini 전체 트래픽 추정 약 150조 토큰/일.
• 초기 DeepSuite 비교: 5.6 Soul 52%, People 5 65%, Ox Alpha 80%.
• 컨텍스트: 100만 토큰.
• 모델 규모: 총 3,200억 파라미터, 활성 약 180억 파라미터.
• 비교 모델: Kimi K3 약 3조 파라미터.
• 가격: 입력 100만 토큰당 7.5센트, 출력 100만 토큰당 25센트.
• PR 전체 감사: 1,000개 이상 PR, 약 20분, 초반 추정 50센트에서 최종 약 12.06센트로 정정.
• PR 감사 토큰: 입력 약 60억 토큰(대부분 캐시), 출력 약 30만 토큰.
• 공식 아키텍처: Sparse Attention + Linear Attention 하이브리드.
• 멀티모달 사전학습 코퍼스: 30조 토큰.
• 작업당 비용 지수: GLM 5.3 Flash 약 9센트, Luna 약 5센트.
• Artificial Analysis 토큰 효율: GLM 5.3 Flash 약 4.7만 토큰/작업, Luna Max 약 2만, Soul 약 1.7만.
• ZI CodeBench 예시: GLM 5.3 Flash 약 7만 토큰, Opus 4.8 약 12만 토큰.
• Blender 실험: 12시간 동안 레스토랑 주방 3D 환경 세트 생성.
• DNSimple 혜택: 가입 시 10달러 크레딧, 첫 10회 CodeRabbit Security 스캔 무료.

핵심 요약 (20줄)

Ox Alpha는 제작사를 숨긴 GLM 5.3 Flash의 익명 초기 공개명이었다. OpenCode와 OpenRouter의 무료 배포는 모델 정체보다 실제 사용 경험을 먼저 검증하게 만들었다. Ox Alpha에는 하루 100조 토큰을 처리할 수 있는 비정상적으로 큰 서비스 용량이 제공됐다. 공개 DeepSuite 문제에서 Ox Alpha는 80%를 기록해 5.6 Soul의 52%와 People 5의 65%를 앞섰다. GLM 5.3 Flash는 Opus 4.8과 비슷한 체감 행동성을 훨씬 낮은 가격으로 제공한다. 모델은 100만 토큰 컨텍스트와 이미지·오디오·비디오 입력을 지원한다. 총 3,200억 파라미터 중 약 180억 개만 활성화하는 Mixture of Experts 구조가 실행비를 낮춘다. 입력 100만 토큰 가격은 7.5센트이고 출력 100만 토큰 가격은 25센트다. Codex 안에서 GLM 5.3 Flash는 수백 개 Pull Request를 약 20분 만에 감사했다. 서브에이전트 세 개가 API 인증 문제로 실패하자 모델은 직접 감사 경로로 전환했다. 모델은 저장소를 수정하지 않고 GitHub 메타데이터와 diff를 이용해 병합 우선순위 보고서를 만들었다. 병합하기 쉬운 PR 여덟 개가 발견됐고 실제로 모두 병합됐다. 1,000개가 넘는 PR을 검사한 비용은 초기 50센트 추정에서 캐시 반영 후 약 12센트로 정정됐다. 지능이 높은 모델과 행동성이 높은 모델을 분리하면 GLM 5.3 Flash의 장점이 선명해진다. GLM 5.3 Flash는 중간에 추가된 지시를 기억하고 도구 실패를 우회하며 작업을 계속한다. 토큰 효율은 작업당 약 4.7만 토큰으로 Luna와 Soul보다 낮지만, 절대 비용은 여전히 매우 작다. 프런트엔드 생성에서 애니메이션과 카피는 강점이고 Fish Slop에는 이동·먹이 상태 관련 논리 버그가 있었다. 모델은 Fish Slop을 3D로 포팅했고 Blender에서 12시간 만에 레스토랑 주방 환경을 생성했다. Huawei Ascend 910 BC에서 실행되는 구조는 Nvidia 의존과 코드 데이터 노출을 줄일 가능성을 제공한다. GLM 5.3 Flash는 최고 지능 모델이 아니라 저렴하고 철저하며 함께 일하기 좋은 에이전트 모델이다.