이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
작성자는 Pydantic Agent framework로 모델이 결과물을 만들고 스스로 리뷰한 뒤 최대 세 번 수정하는 자체 코딩 하네스를 구축했습니다. GLM-5.2는 9회 실행에서 1회 수리만 필요해 UI 품질과 첫 시도 정확도의 균형이 가장 좋았고, MiniMax M3는 $0.081로 속도와 비용에서 앞섰습니다. DeepSeek V4 Flash는 $0.0282와 0 repairs로 실용적인 가치가 높았으며, Kimi-K3는 공개 coding benchmark의 강한 순위와 달리 6 repairs를 기록했습니다. 공개 benchmark보다 비용, 시간, 수리 횟수, 최종 코드 품질을 함께 묶은 usable output per loop가 실제 코딩 모델 선택에 더 가까운 신호라는 결론입니다.
실용적 조언
- 코딩 모델을 비교할 때는 동일한 provider와 작업 모드를 유지하고, 모델이 결과를 만든 뒤 리뷰와 수정까지 수행하도록 실행 흐름을 고정하는 편이 좋습니다. 각 실행에서 tokens, 비용, runtime, repair count, final usability를 함께 기록하면 첫 시도 품질과 반복 수정 비용을 분리해 볼 수 있습니다. 외부 judge model을 추가하지 않으면 모델 자체 결과가 최종 산출물에 미치는 영향을 더 직접적으로 확인할 수 있습니다.
- 속도와 비용이 중요한 작업에는 MiniMax M3나 DeepSeek V4 Flash처럼 낮은 비용과 짧은 실행 시간을 보인 모델을 우선 비교할 수 있습니다. UI 품질과 첫 시도 정확도가 중요한 경우에는 GLM-5.2처럼 수리 횟수와 최종 화면 품질을 함께 고려해야 합니다. 앱 로직 중심 작업에서는 Kimi K-2.7 Code처럼 해당 작업에서 더 빠르고 나은 코드 로직을 만든 모델을 별도로 확인해야 합니다.
섹션별 상세
작성자는 기존 코딩 하네스를 쓰지 않고 Pydantic Agent framework로 자체 에이전트형 하네스를 만들었습니다. 두 모델을 같은 provider에서 나란히 실행하고 Game, Design, Code 세 가지 모드에서 각 모델이 결과물을 만든 뒤 스스로 리뷰하게 했습니다. 오류가 발견되면 최대 세 번의 수정 기회를 부여했으며, 외부 judge model이나 helper model은 결과에 개입하지 않았습니다.
테스트는 공개 벤치마크 점수보다 빌드·리뷰·수정 루프 안에서 실제로 쓸 수 있는 결과가 나오는지를 측정했습니다. GLM-5.2는 277,288 tokens와 $0.969를 사용하고 1 repair만 기록해 전체 품질에서 가장 좋은 균형을 보였습니다. MiniMax M3는 121,323 tokens, $0.081, 3 repairs로 속도와 비용에서 앞섰고, DeepSeek V4 Flash는 115,950 tokens, $0.0282, 0 repairs로 가장 낮은 평균 비용과 실용성을 함께 보였습니다.
모델별 공개 순위와 실제 작업 결과 사이에는 차이가 있었습니다. Kimi-K3는 공개 coding 및 front-end benchmark에서는 강했지만 하네스에서는 66,237 tokens를 사용하며 6 repairs로 가장 많은 수정이 필요했습니다. 반대로 DeepSeek V4 Flash는 DeepSeek V4 Pro보다 적은 tokens를 쓰지는 않았지만 Code mode에서 더 쓸 만한 흐름과 앱 로직을 만들었고, Kimi K-2.7 Code는 Kimi-K3보다 앱 로직 중심 작업에서 더 빠르고 나은 코드를 작성했습니다.
작성자는 Cursor에서 Kimi K3를 다시 시험해 Voxel Pagoda와 Rube Goldberg Machine 작업을 수행했습니다. K3는 Voxel Pagoda에서 준수한 사용성을 만들었지만 매우 인상적인 수준은 아니었고, 다른 프롬프트에서는 네 번의 시도 뒤에도 준수한 결과에 가까이 가지 못했습니다. 최종 결론은 모델 선택에서 benchmark 점수 하나보다 비용, 시간, 수리 횟수, 최종 코드 품질을 묶은 usable output per loop가 더 직접적인 신호라는 것입니다.
용어 해설
- 에이전트형 테스트 하네스(Agentic Harness)
- — 모델이 작업을 수행하고 결과를 다시 점검하도록 구성한 실행 환경입니다. 이 글에서는 각 모델이 출력물을 만든 뒤 자체 리뷰를 거치고, 오류가 있으면 최대 세 번 수정합니다. 외부 판정 모델은 사용하지 않았습니다.
- 빌드·리뷰·수정 루프(Build → Review → Fix Loop)
- — 코드를 먼저 만든 다음 결과를 점검하고 오류를 고치는 반복 절차입니다. 입력은 작업 프롬프트이고 출력은 수정된 코드와 최종 결과물입니다. 이 글에서는 수리 횟수와 최종 사용성을 모델 비교 기준으로 삼았습니다.
- 공개 벤치마크(Public Benchmark)
- — 모델의 성능을 공통 과제로 측정해 비교하는 공개 평가 결과입니다. 글의 테스트에서는 공개 코딩·프론트엔드 벤치마크 순위와 실제 하네스 결과가 일대일로 맞지 않았습니다. 따라서 점수만으로 실사용 품질을 판단하기 어렵다는 결론으로 이어졌습니다.
- 수리 시도(Repair Attempt)
- — 모델이 만든 결과물에서 오류가 발견된 뒤 수정 작업을 다시 수행하는 횟수입니다. 각 모델은 최대 세 번의 수정 기회를 받았고, 모델별 총 수리 횟수는 0회에서 6회까지 달랐습니다. 수리 횟수는 첫 결과의 일관성을 가늠하는 지표로 쓰였습니다.
- 시각적 위계(Visual Hierarchy)
- — UI에서 요소의 크기와 배치, 강조 정도를 조절해 사용자가 정보를 읽는 순서를 만드는 특성입니다. GLM-5.2는 테스트에서 UI 품질과 시각적 위계가 가장 강한 모델로 평가됐습니다. 최종 화면의 사용성을 비교하는 기준에 포함됐습니다.
언급된 도구
Pydantic Agent중립
외부 코딩 하네스 없이 모델의 빌드·리뷰·수정 흐름을 실행하는 자체 agentic harness 구축에 사용됐습니다.
Cursor중립
Kimi K3를 Voxel Pagoda와 Rube Goldberg Machine 프롬프트로 재시험하는 데 사용됐습니다.
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 08. 14.수집 2026. 08. 14.출처 타입 REDDIT
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
