저는 단체 채팅(group-chat) 방식의 비교를 믿지 않습니다. 그것이 모델의 진정한 가치를 반영한다고 생각하지 않기 때문입니다.

한 사용자가 GLM 5.2 + Claude Code 조합과 DeepSeek V4 Flash + Codex 조합에 동일한 프롬프트를 사용했습니다. 첫 번째 실행에서는 20회 남짓한 턴 만에 플레이 가능한 게임이 만들어졌습니다. 반면 또 다른 유사한 테스트에서는 수백 개의 기록과 긴 수정 루프(repair loop)가 남았습니다. 동일한 인물과 프롬프트가 사용되었기에 첫 번째 비교가 더 설득력이 있습니다. 하지만 그 프롬프트조차도 대상(audience), 플랫폼(platform), 핵심적인 즐거움(core delight), 트레이드오프(trade-offs), 그리고 수락 기준(acceptance criteria) 등 제품에 대한 정의를 내리지 않은 상태였습니다.

불충분하게 정의된(underspecified) 작업을 실행해내는 모델은 빈칸을 채울 수 있다는 것을 보여준 것입니다. 그것이 당신이 실제로 의도한 결과물을 만들어냈다는 것을 보여준 것은 아닙니다.

하나의 리더보드가 아닌, 두 개의 축

저는 모델을 두 개의 축으로 생각합니다.

**역량 (Capability)**은 생소한 문제에 대한 한계치입니다: 유용한 질문, 일관된 계획, 제품의 트레이드오프(trade-offs), 그리고 버그의 원인을 모를 때의 가설 설정 등이 여기에 해당합니다.

**성숙도 (Maturity)**는 프로세스가 정의되었을 때의 신뢰성입니다: 안정적인 도구 사용(tool use), 계획 준수, 상태 보존(state preservation), 복구(recovery), 그리고 다시 확인하려는 의지 등이 포함됩니다.

매개변수(Parameter) 수는 역량의 한계치에 영향을 미칠 수 있습니다. 하지만 성숙도는 단순히 매개변수의 함수가 아닙니다. 사후 학습(post-training), 도구 적응(tool adaptation), 컨텍스트 정책(context policy), 그리고 실제 작업 피드백이 중요합니다.

이것이 제가 현재의 Codex 설정에서 DeepSeek V4 Flash를 바라보는 관점입니다. 제품의 방향성을 정하거나 개방형 탐색(open-ended exploration)을 할 때 저의 첫 번째 선택은 아닙니다. 하지만 목표와 단계가 결정되었을 때, 즉 파일을 읽고, 제한된 범위 내에서 편집하며, 체크를 실행하고, 알려진 오류를 수정하며, 다시 검증해야 할 때 매우 가치 있는 모델입니다.

제로(Zero) 상태에서 시작하는 방법

가벼운 Angry Birds 스타일의 모바일 게임을 만든다면, 저는 먼저 강력한 모델에게 대상, 플랫폼, 핵심적인 재미, 시각적 요소와 메커니즘의 트레이드오프(trade-offs), 그리고 버전 1(version one)이 무엇을 의미하는지를 명확히 해달라고 요청할 것입니다. 그런 다음 그 방향성을 모듈 경계(module boundaries), 의존성(dependencies), 수락 증거(acceptance evidence), 그리고 복구 지점(recovery points)으로 전환해달라고 요청할 것입니다.

계획이 표류(drifting)를 멈추고, 모든 단계에서 관찰 가능한 증거(observable evidence)가 있으며, 적대적 검토(adversarial review)가 더 이상 전체적인 방향을 바꾸지 않을 때, 나는 성숙한 실행기(mature executor)로 전환합니다. 이 전환은 턴 횟수(turn count)에 따라 이루어지지 않습니다.

디버깅(Debugging)도 동일한 규칙을 따릅니다. 버그가 대략 어디에 있는지, 그리고 어떻게 수정해야 하는지 알고 있다면 빠른 성숙한 모델(fast mature model)을 사용합니다. 만약 버그의 위치를 모른다면, 문제 모델(problem model)을 재구축할 수 있는 더 강력한 모델로 에스컬레이션(escalate)합니다. 수락(Acceptance) 단계에서는 단순히 "완료됨"이 아니라, 원래의 목표, 계획, 차이점(diff), 테스트, 리스크, 그리고 실행 로그(run logs)를 전달받습니다.

모델 간의 핸드오프(handoff)는 파일 확장자가 아니라 불확실성(uncertainty)에 의해 결정됩니다.

나의 실질적인 측정 기준은 간단합니다: 수정된 결과물(artifact)이 초기 기대치에 얼마나 근접했는지, 시간과 토큰 예산(token budget)을 얼마나 소비했는지, 그리고 해당 접근 방식을 재사용할 수 있는지 여부입니다.

작업이 더 저렴한 실행기에 맡길 수 있을 만큼 충분히 확실해졌다는 당신만의 신호는 무엇입니까?

공개: 이 기사는 AI의 도움을 받아 작성되었으며 저자가 검토하였습니다.