GLM, DeepSeek, Kimi, Qwen 코딩 테스트

작성일 : 2026. 06. 24

TL;DR

직접 비교해서 플레이 해봅시다.
https://surviver-game-llm-comapre.vercel.app

플랜 문서와 실제 코드는 여기에 있습니다.
https://github.com/unk/surviver-game-llm-comapre

들어가며

최근 GLM 5.2가 소셜에서 대단히 난리입니다. Opus 급의 성능을 냈다고 하면서요. 어차피 요즘 나오는 대부분의 모델은 Opus 아니면 GPT 와 비교를 합니다. "GPT 5.5의 85% 성능 달성!" 같은 식으로요.

GLM은 그동안 꾸준히 Opus를 경쟁 모델로 언급했고, 5.2에서 괄목할만한 성과가 나온 것 같습니다.

그런데 사실 좀 긴가민가한 부분도 있습니다. 보통 벤치마크 점수를 많이 내세우는 모델들은 벤치마크 점수를 내기 위한 최적화가 들어간 경우들이 많이 있으니까요.

그래서 실제 테스트를 한번 해보자 하는 생각을 해보게 되었습니다.

테스트 방식

우선 플랜 문서를 하나 준비합니다.

간단하게 캔버스 기반 게임을 하나 만들어보는 걸로 계획을 잡았습니다.

가능하면 한번의 세션에서 완료되어 압축이 일어나거나 여러 세션에 걸쳐서 진행되지 않는 정도의 규모로 잡았습니다. 실제 업무에서는 이보다 큰 단위의 작업이 일어나겠죠. 그런 중장기 작업을 테스트 하려면 좀 더 많은 준비가 필요할 것 같아 지금은 테스트 규모를 작게 잡았습니다.

계획 문서는 이렇습니다. TECH-DEMO.md

계획 문서는 Opus 4.8 을 이용해서 만들었습니다.

개발 환경

모든 작업은 클로드 코드를 이용해서 진행합니다.

클로드 코드에 GLM, DeepSeek, Kimi, Qwen 을 연결하는 건 cc-switch 를 이용했습니다. (틈새 홍보)

...다만 마지막에 GPT 5.5가 테스트 후보로 올라오면서 GPT 5.5에 한해서는 Codex CLI 를 이용했습니다.

후보 모델

한계

이 테스트는 (당연하게도) 공신력이 없습니다.

여러차례 반복 테스트를 돌린 후 통계를 낸 작업도 아니고, 결과를 상세히 정량화/정성화 한 것도 아닙니다.

이 테스트는 딱 한번씩 작업을 돌린 것이고, LLM은 고급 모델이라도 간혹 실수 같은 결과가 나오기도 합니다.

실제 작업이었다면 몇 번에 걸쳐서 수정 요청을 해서 다듬었을거고, 그럼 대부분 다 좋은 결과물로 다듬어졌을겁니다.

결과

게임 링크 :
https://surviver-game-llm-comapre.vercel.app

플랜 문서와 실제 코드 :
https://github.com/unk/surviver-game-llm-comapre

공통점

모든 모델은 컨텍스트 압축 없이, 한 세션에서 한번만에 완성했습니다.

플랜 문서에 꽤 상세하게 지정한 내용들이 많아서, 대부분 비슷한 형태로 구현되었습니다.

실제 구현상 가장 차이가 나는 부분은 game.js 일텐데, 열어보면 대부분 비슷한 구성을 가지고 있습니다.

디자인도 레트로 도트 디자인에 CRT 스캔라인 느낌까지 살려서 비슷하게들 구현되었습니다.

차이점

DeepSeek, GLM, Qwen 은 게임 시작을 키보드로 할 수 있게 편의 기능까지 제공했습니다.

GLM, GPT, Kimi 는 배경에 그리드를 깔았습니다.

GPT는 유일하게 Playwright 로 e2e 테스트를 수행했습니다. (Codex CLI 특성인가?)

GLM이 유일하게 충돌판정을 제대로 구현하지 못해 게임오버가 되지않는 문제가 있습니다.

Kimi는 유일하게 경험치바를 생명바 아래에 표기했습니다.

감상 및 마무리

플랜 문서가 잘 나온 상태에서는, 어느 모델을 쓰든 웬만한 수준의 결과가 나오는 걸 알 수 있습니다.

당연하게도, Opus 의 몇 세대 전인 4, 4.5 같은 모델로도 실무 작업을 하는 사람들이 있었고 지금 보급형 모델들도 그보다는 좋은 성능을 내니까요.

그렇다면 결국 성능을 가르는 건 플랜 문서를 잘 만드는데 있는게 아닐까 하는 생각이 듭니다. 다음에는 플랜 문서 자체를 각 모델이 스스로 만드는 테스트를 후속으로 진행해봐야 할 것 같습니다.

다음에는 조금 더 복잡한 과제를 플랜부터 각 모델들에게 맡기는 형태로 테스트를 준비해 보겠습니다.


이 블로그는 댓글 기능이 없습니다.
이 게시물에 대한 의견이 있으시면 i.am@naram.kim 으로 메일을 남겨주세요.