이것은 저의 개인적인 실측 노트이며, 벤치마크 (benchmark)가 아닙니다. 샘플 크기가 매우 작으며 (n=2 라운드), 그중 한 라운드는 제 환경 설정 오류로 인해 발생했습니다. 모든 수치는 제 개인 기기에서의 관찰 결과이며, 제조사 데이터나 재현 가능한 기준이 아닙니다. 결론적인 모델 비교가 아닌, '한 엔지니어의 5분간의 판단'으로 읽어 주시기 바랍니다.

배경: 무엇을 비교하고 있는가

저는 보안에 민감한 동일 유형의 소규모 도구 규격을 각각 2026년형 코딩 모델들에게 대리인 (delegate)으로서 맡겼습니다:

• 빠른 Grok 코딩 모델 —— 제 툴체인(toolchain)에서는 'Grok Composer 2.5 Fast'로 표시됩니다. 이는 제 환경에서 표시되는 라벨일 뿐이며, 해당 모델의 공식 명칭이라고 주장하지 않습니다 (여담으로, 'Composer 2.5'는 Cursor 자체의 에이전트 (agent) 모델 이름이기도 하며, xAI와는 별개의 문제입니다. 모델을 비교하기 전에 실제로 어떤 모델을 실행 중인지 먼저 확인하십시오).
• GLM-5.2 —— Z.ai / 智譜의 오픈 웨이트 (open-weights) 플래그십 모델로, 제가 직접 작성한 CLI 하네스 (harness)를 통해 실행했습니다.

'출시 ≠ 사용 가능 ≠ 상업적 이용 가능'은 제가 모델을 바라보는 습관입니다. 이 글은 오로지 '사용 가능' 단계에 대해 다룹니다. 즉, 실제 워크플로 (workflow) 내에서 이 두 모델이 대리인 (delegate)로서 결과물을 제대로 내놓는지, 그리고 그 결과물을 신뢰할 수 있는지에 대한 이야기입니다.

첫 번째 라운드 (불공정: 도구가 다름)

Grok은 transcribe.py / login_assist.py를 생성했고, GLM은 form_fill.py를 생성했습니다. 도구가 다르기 때문에 이 라운드로는 우열을 가릴 수 없습니다. 하지만 '누가 이기는가'와는 무관하지만 남겨둘 만한 발견이 하나 있었습니다:

GLM의 코드는 깔끔했고 '114개 테스트 통과'를 보고했습니다. 하지만 이 모델은 자신의 테스트를 자신의 코드에 맞게 수정해 버렸습니다 (모델 스스로는 'regex에 맞게 테스트 이름을 수정함'이라고 답했습니다). 그 결과, 실제 인증 정보 유출(하나의 일회용 코드(one-time code)가 거부되지 않음)이 초록색 불빛(pass) 사이를 그대로 통과해 버렸습니다. 저는 실제 DOM을 읽어본 후에야 이를 잡아낼 수 있었습니다.

이것이 가장 위험한 실패 유형입니다: 초록색 불빛이 안심을 시키지만, 밑바닥은 망가져 있는 상태입니다. 빨간색 불빛은 어디를 고쳐야 할지 알려주지만, '가짜 초록색 불빛'은 그저 제품을 출고하라고 재촉할 뿐입니다.

두 번째 라운드 (공정: 동일 도구 combo_select, 격리된 worktree, 동일 규격, 직접 검증)

이 라운드에서는 Grok이 확실히 더 나았습니다: 간결하고, 규격에 부합하며, 통과할 줄 알고, 기존 컴포넌트를 깔끔하게 조합하며, 단 하나의 사소한 self-test 버그만 있었습니다. 반면 GLM은 과잉 설계되었고, 자신의 테스트를 통과하지 못했으며, 명확한 단일 반환 (single-return) 규칙을 위반했고, 수렴하지 못했습니다.

솔직한 주의 사항: 제가 이 라운드를 처음 실행했을 때, 커밋되지 않은 의존성 때문에 격리된 worktree가 망가졌었습니다. 당시의 '결과'는 사실 제 설정 오류가 만든 노이즈였으며, 나중에 이를 감지하고 수정하여 다시 실행했습니다. 비교의 유효성은 그 테스트 조건 자체보다 높을 수 없습니다 — 검증하기 전에 환경부터 검증하십시오.

진짜 교훈: 실패의 '방향'이 다르므로, 양쪽 모두 파악할 줄 알아야 한다

• GLM은 단순한 작업에서 조용히 망가진다: form_fill 사례에서 114개의 테스트가 '통과'했지만, 밑바닥에는 3개의 런타임 버그 (runtime bug)가 있었고 실제로는 전혀 입력되지 않았습니다. 가짜 초록색 불빛, 이것은 위험한 패턴입니다.
• Grok은 어려운 작업에서 시끄럽게 망가진다: 플랜 모드 (plan-mode)에서

위의 Grok 결과는 **상호작용 경로(interactive path)**입니다. 하지만 제 환경에서는 헤드리스(headless) grok -p 경로는 독립적인 구현자로서 아예 실행되지 않습니다: 두 번 시도했을 때 모두 0 파일을 생성했고, sub-worker가 Auth(AuthorizationRequired)에서 죽었습니다. 먼저 「I'll port the three features… / Implementing…」라는 독백을 내뱉은 후 아무것도 건드리지 않고 종료되었습니다. grok login을 했고 도구 호출이 없는 스모크 테스트(smoke test)에서도 GROK_AUTH_OK가 반환되었지만, 실제로 많은 도구 호출이 필요한 경우에는 움직이지 않았습니다: -p에 --always-approve가 없으면 첫 번째 게이트된 도구 호출에서 멈춥니다.

• 이는 제가 직접 실행한 codex exec CLI의 실패와 완전히 똑같습니다 (상호작용 인증, 0% CPU에 막힘).
• 유일하게 사용할 수 있는 외부 위임(delegate)은 companion runtime(자체 세션 인증 포함)을 거친 리뷰 경로입니다. 하지만 이것은 검토/분석 용도이며 다중 파일 구현자가 아닙니다.
• 실제로 코드를 내놓은 것은 로컬 워크플로우/에이전트 경로(외부 인증 없음, in-process)였습니다. 이 경로는 위험성이 있는 Vec<String>→Vec<Activity> 모델을 리팩토링하는 것을 한 번에 정확하게 수행했습니다 (컴파일 깨끗함, 118 테스트 통과). 자체적인 적대적 검증(adversarial validation)도 PASS와 소수의 작은 발견 사항을 솔직하게 보고했습니다.

저의 현장 판단 (개인 프로젝트)

• 독립 구현: 제 환경에서는 로컬 워크플로우/에이전트 경로를 우선 사용해야 합니다. 이것이 이번에 유일하게 안정적으로 실행되고 정확한 코드를 내놓은 위임자입니다.
• Codex (리뷰 경로를 통한): 검토/분석 용도로 남겨두고, 다중 파일 구현자로 사용하지 마십시오.
• Grok 모델 자체: 상호작용 경로 하에서는 제한적이고 단일 파일/단일 목적의 작업(하나의 도구, 하나의 패치, 기존 컴포넌트 조합)에 적합한 파트너입니다. 명확한 사양을 주고 한 번에 끝내거나 크게 실패할 것을 예상하며, 그 후 독립적으로 검증해야 합니다. Grok headless는 여기에서 사용 불가능합니다. --always-approve 권한 게이트를 먼저 해제하고(클래시파이어가 정확하게 막은 독립 모드), 세션 인증이 헤드리스 실행을 지탱할 수 있는지 확인해야 합니다.
• 다단계, 모호하며 아키텍처에 영향을 주는 작업: 스스로 운전하십시오. 워크플로우 + Codex 패턴을 사용하고 외주를 주지 마십시오.

절대 타협할 수 없는 것

'테스트 통과'라는 것을 절대로 믿지 마세요. 이번 모든 위임자(Grok, GLM, 그리고 fullstack agent의 form_state.py)가 내놓은 결과물에는 독립적인 검증을 통해서만 찾아낼 수 있는 실제 결함이 있었습니다. 저의 검증 방식: 직접 테스트 실행, diff 읽기, 실제로 한 번 돌려보기, 그리고 다시 Codex 리뷰를 통해 대조하기. 모델 선택은 단지 당신이 '처음부터 깨끗하게' 시작할 확률을 바꿀 뿐입니다. 이 검증 단계는 결코 생략되지 않습니다.

'테스트 통과'는 주장일 뿐이지 결과가 아닙니다—그것이 모델의 말이라 할지라도, 아니면 당신이 처음 실행한 것이라 할지라도. 구별할 수 있는 유일한 방법은 테스트를 잡고 있는 사람이 바로 당신이라는 것입니다.

위 내용은 개인적인 실습 관찰이며 통제된 벤치마크가 아닙니다. 작업, 하네스(harness), 모델 버전에 따라 다를 수 있습니다. 만약 여러분도 '조용히 실패 vs 크게 실패'와 같은 분열을 경험했거나 이를 성공적으로 설계해냈다면, 댓글로 방법을 공유해 주시면 감사하겠습니다.

— YangGF (AI 현장 적용 판단 엔지니어 관찰자)