GLM 5.3 Review (Don''t Use Subagents on ZCode)

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Zcode에서 GLM 5.3을 사용할 때는 프로젝트 메모리를 공유하지 못하는 서브에이전트에 맡기지 말고, 메인 모델이 프로젝트별로 직접 코딩하고 검증해야 한다.

📌 핵심 요점

1. Zcode의 프로젝트 메모리는 메인 에이전트에만 적용되므로, 서브에이전트는 기존 맥락을 이어받지 못하고 복잡한 프로젝트의 기능·스타일 일관성을 잃기 쉽다.
2. GLM 5.3은 GLM 5.2와 같은 기반 모델을 사용하면서도 강화학습과 후처리 학습으로 코딩 성능을 50% 높였고, Terminal Bench 3.0·Automation Bench·CyberGym에서도 강한 결과를 보였다.
3. GLM 5.3은 이미지 입력이 없는 텍스트 전용 모델이므로, 시각 프로젝트에서는 구체적인 UI·UX 사양과 결과물 레퍼런스가 없으면 모델의 구현 능력과 Zcode의 오케스트레이션 실패가 뒤섞일 수 있다.
4. 16개 시각·게임 프로젝트에서는 순서 규칙, 공간 안내, 성장 구조처럼 부분적인 로직은 작동했지만, 포탑 설치 불능·검은 화면·카메라 방향 오류·붕괴한 3D 구조처럼 핵심 상호작용과 시각 구현 실패가 반복됐다.
5. 서브에이전트 활용은 검증 루프가 없는 상태에서도 하루 만에 주간 한도의 40%를 소모했으므로, 비용 절감 수단으로 단정하기 어렵고 메인 모델의 직접 구현과 프로젝트별 검증이 더 합리적이다.

🧩 배경과 문제 정의

• GLM 5.3 자체의 코딩 역량은 크게 향상됐지만, Zcode의 프로젝트 메모리는 메인 에이전트만 사용하고 서브에이전트는 맥락을 공유받지 못한다.
• 시각·게임 프로젝트 16개의 코드를 서브에이전트에 전담한 결과, 작동 여부와 시각적 일관성이 크게 흔들렸다.
• GLM 5.3은 이미지 입력이 없는 텍스트 전용 모델이므로, 시각 레퍼런스가 부족한 자유형 작업에서는 모델 자체의 한계와 Zcode 하네스의 오케스트레이션 문제를 구분해야 한다.
• 토큰과 시간을 절약하려고 서브에이전트를 활용했지만, 별도의 검증 루프 없이도 라이트 코딩 요금제 주간 한도의 40%가 하루 만에 소모됐다.

🕒 시간순 섹션별 상세정리

1. Zcode 서브에이전트의 구조적 제약

• Z.AI 문서상 프로젝트 메모리는 메인 에이전트에만 적용되며, 서브에이전트는 동일한 맥락을 이어받지 못해 복잡한 작업의 일관성이 떨어질 수 있다. [00:18]
• 모든 미니 프로젝트의 코드를 서브에이전트가 작성했지만 검증 루프까지 포함하지 않은 상태에서도 주간 한도의 40%를 소모해, 비용과 시간 절감이라는 목적과 충돌했다. [01:10]

2. 후처리 학습으로 높아진 코딩 성능

• GLM 5.3은 GLM 5.2와 같은 기반 모델을 사용하면서도 강화학습과 후처리 학습을 통해 코딩 성능을 50% 높였다. [01:42]
• Terminal Bench 3.0에서는 GLM 5.2보다 크게 상승해 최상위 모델들과 근접했고, Kimi K3보다 앞서는 결과도 나타났다. [02:22]

3. 텍스트 전용 모델의 시각 작업 조건

• GLM 5.3은 이미지 기능이 없는 텍스트 전용 모델이어서, 시각 작업에는 UI·UX 사양과 결과물 레퍼런스를 충분히 제공해야 일관된 구현을 기대할 수 있다. [03:49]
• City Scroll Journey는 참조 없이 자유 생성해 장면 구성이 일관되지 않았지만, 스크롤을 건너뛰어도 중간 애니메이션을 거쳐 목적 위치에 도달하는 UI 동작은 정확했다. [05:21]

4. 비행 게임의 순서 로직과 3D 구현 붕괴

• Ember Glider는 조작이 어렵고 기본적인 재미도 부족했지만, 놓친 링을 화면 흔들림으로 알리고 모든 링을 순서대로 통과하게 만들어 이전 모델보다 게임 규칙을 엄격하게 처리했다. [07:01]
• Helm’s Deep은 경사로가 보이지 않는 등 시각 구현이 무너졌으며, Zcode에서는 서브에이전트 대신 GLM 5.3 메인 모델이 직접 코딩하도록 해야 한다는 결론으로 이어졌다. [08:10]

5. 테마 구현과 조작 체계의 불균형

• Hogwarts 비행 시뮬레이터는 진행 방향과 탑승 위치가 어긋났고, 지나치게 어두운 화면과 작은 성, 어지러운 이동감 때문에 실패로 판정됐다. [08:38]
• Jabberwock은 소용돌이형 이동, 시 구절을 활용한 전투, 체력 표시와 ‘Snicker-Snack’ 공격 같은 테마 세부 요소를 실제 게임 규칙으로 연결했다. [09:29]

6. 핵심 상호작용 실패와 공간 안내의 성공

• 타워 디펜스는 적의 경로 탐색 자체는 단순하고 안정적이었지만, 패드를 선택해도 포탑을 설치할 수 없어 핵심 게임 메커니즘이 작동하지 않았다. [10:47]
• 미니 Minecraft형 프로젝트는 미니맵과 동쪽 돌길 안내를 통해 작업대로 유도했고, 작업대를 명확한 기지 공간에 배치해 이동 목표를 알아보기 쉬웠다. [11:18]

7. 기능적 시뮬레이터와 실행 불능 프로젝트

• 기계식 시계 시뮬레이터는 완성되지 않은 부분이 있었지만 카메라 회전에 따라 부품의 광택과 조명이 변했고, 전체 프로젝트 중 가장 기능적이고 깔끔한 결과에 가까웠다. [12:06]
• Neon Drift는 검은 화면에서 벗어나지 못해 게임 자체를 시작할 수 없었으며, 기능 검증 단계에 진입하지 못한 완전한 실패 사례였다. [12:13]

8. 생태계 논리의 모순과 슈터의 진행 시스템

• Petri Dish에서는 포식자가 처음에는 먹이를 줄였지만 이후 먹이가 많이 남은 상태에서 포식자 수가 오히려 감소해, 단순한 포식 관계와 맞지 않는 시뮬레이션 결과가 발생했다. [14:27]
• 먹이보다 포식자가 먼저 쇠퇴한 결과를 약자 선호 편향의 지표로 볼 수 있다는 해석이 나왔지만, 단일 시뮬레이션에 기반한 추정 수준에 머문다. [14:51]

9. 연속된 실행 실패와 Vice City의 반전

• Stormwind Tribune은 발사체가 성으로 날아가지 않고 투석 장치가 사라지거나 공중에 고정돼, 발사와 시점 추적이라는 핵심 동작이 모두 실패했다. [16:37]
• Universe Simulator는 검은 화면 외에 아무 요소도 생성하지 못해, 시뮬레이션 기능과 시각 결과를 전혀 확인할 수 없었다. [16:41]

10. 최종 실패 사례와 Zcode 사용 원칙

• 중국 고대 건축 조립 프로젝트는 구조물이 비정상적으로 떠 있고 형태도 무너졌지만, 이 결과는 GLM 5.3 기반 모델보다 작업을 수행한 Zcode 서브에이전트의 실패에 가깝다. [18:05]
• 서브에이전트가 만든 16개 프로젝트는 GLM 5.3 메인 모델이 직접 하나씩 다시 구현하는 방식으로 재시험해야 하며, 한 번에 처리하기보다 프로젝트별 검증이 필요하다. [18:25]

🧾 결론

• GLM 5.3의 순수 코딩 역량과 Zcode 서브에이전트의 실행 품질은 분리해서 평가해야 한다.
• 현재 결과만 보면 Zcode에서는 서브에이전트보다 GLM 5.3 메인 모델이 직접 코딩하고 검증 루프를 수행하는 방식이 더 신뢰할 만하다.
• 16개 프로젝트의 실패를 GLM 5.3 자체의 한계로 확정하려면 동일 조건에서 메인 모델이 하나씩 다시 구현한 비교 결과가 필요하다.
• 시각 작업에서는 프롬프트만 늘리는 것보다 명시적인 사양, 레퍼런스, 실행 검사, 조작 검증을 하나의 작업 흐름으로 묶는 것이 중요하다.

📈 투자·시사 포인트

• AI 코딩 모델의 벤치마크 상승이 실제 개발 생산성으로 곧바로 이어지는 것은 아니며, 하네스의 맥락 전달과 검증 구조가 실사용 성과를 좌우할 수 있다.
• 에이전트 제품을 평가할 때는 모델 성능뿐 아니라 프로젝트 메모리 상속, 서브에이전트 조율, 실패 복구, 결과 검증 기능을 함께 살펴봐야 한다.
• 텍스트 전용 모델은 논리와 코드 생성에서 강점을 보여도 시각적 완성도 평가에는 구조적인 제약이 있으므로, 시각 레퍼런스 지원 여부가 제품 차별화 요소가 될 수 있다.
• 서브에이전트가 항상 비용과 시간을 줄여 주는 것은 아니므로, 토큰 소비량과 재작업 비용까지 포함한 총비용 관점의 비교가 필요하다.

⚠️ 불확실하거나 확인이 필요한 부분

• 16개 프로젝트를 GLM 5.3 메인 모델로 동일하게 재실행한 결과가 없으므로, 실패 가운데 어느 정도가 서브에이전트의 맥락 손실 때문인지 아직 정량적으로 분리되지 않았다.
• 시각·게임 프로젝트 중심의 16개 사례만으로 일반적인 업무 자동화나 비시각적 소프트웨어 개발 성능까지 일반화하기는 어렵다.
• 코딩 성능이 50% 향상됐다는 수치와 각 벤치마크 결과의 세부 측정 방식·조건은 제공된 내용만으로 독립 검증할 수 없다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• Zcode의 복잡한 코딩 작업은 GLM 5.3 메인 모델이 직접 수행하도록 구성한다.
• 시각 프로젝트를 시작하기 전에 UI·UX 사양, 화면 상태, 조작 규칙, 결과물 레퍼런스를 명시한다.
• 프로젝트를 하나씩 실행해 시작 가능 여부, 핵심 상호작용, 카메라·조작 방향, 시각 일관성을 검증한다.
• 기존 16개 프로젝트를 동일 프롬프트와 조건으로 메인 모델에서 재구현해 서브에이전트 결과와 비교한다.

❓ 열린 질문

• 동일한 16개 프로젝트를 메인 모델이 직접 구현하면 실행 성공률과 시각적 일관성이 얼마나 개선될까?
• Zcode가 향후 프로젝트 메모리를 서브에이전트와 공유하거나 검증 상태를 전달할 수 있게 되면 현재의 품질 문제가 얼마나 해소될까?
• 이미지 입력을 지원하는 모델과 GLM 5.3에 동일한 시각 사양을 제공했을 때 기능 정확도와 시각 완성도는 어떻게 달라질까?