중급 모델이 이미 충분히 훌륭하다면, 정말로 플래그십(flagship) 가격을 지불하는 것이 정당할까요?

원래의 비교는 Gemini 3 Flash 대 Claude Sonnet 4.6으로 시작되었으나, 이후 Gemini 3.5 Flash가 등장하면서 테스트는 더욱 흥미로워졌습니다. 만약 더 저렴한 모델이 이제 실제 업무에 충분히 강력하다면, 대형 모델은 가장 어려운 추론(reasoning) 작업에만 예약해 두어야 할지도 모릅니다.

가설: 최첨단 모델(frontier models)이 가장 어려운 사고 작업에서는 여전히 승리하겠지만, 중급 모델은 대부분의 실제 업무를 수행하기에 충분할 것이며, 훨씬 적은 비용으로 이를 수행할 것입니다.

Ship-Bench는 더 현명한 지출이 저렴한 모델을 선택하는 것인지, 아니면 플래그십 모델이 여전히 프리미엄 가치를 증명하는 것인지 확인하기 위해 Gemini 3 Flash, Gemini 3.5 Flash, 그리고 Claude Sonnet 4.6을 대상으로 실행되었습니다.

설정 (Setup)

세 번의 실행 모두 동일한 벤치마크 작업과 동일한 일반적인 운영자(operator) 설정을 사용했습니다. 중요한 차이점은 대상 모델과 하네스(harness)였습니다.

환경 (Environment)

실행 구성 (Run configuration)

판정 구성 (Judge configuration)

전체 결과 (Overall results)

Gemini 3.5 Flash는 이번 비교에서 평균 93.10점과 깔끔한 5/5 통과율을 기록하며 전체 1위를 차지했습니다. 가장 큰 장점은 초기 단계에서 나타났는데, 아키텍처와 UX 아티팩트(artifacts)가 이례적으로 완전했으며, Gemini 3 Flash를 저하시켰던 주요 공백 없이 리뷰 단계까지 강력한 성능을 유지했습니다.

아키텍트 (Architect)

아키텍트 (Architect) 단계는 모델이 제품 브리프 (product brief)를 명확한 결정 사항과 최소한의 미해결 모호성을 포함한 구체적인 기술 계획으로 전환할 수 있는지 테스트합니다.

LLM 판사 요약 (LLM judge summary): Sonnet 4.6과 Gemini 3.5 Flash는 아키텍처 부문에서 확실한 두각을 나타냈으며, 두 모델 모두 구체적인 스키마 (schema), 강력한 검색 전략, 명시적인 로컬 실행 지침, 그리고 개발자가 거의 즉시 빌드 모드로 전환할 수 있을 만큼 충분한 구현 세부 사항을 갖춘 실행 가능한 사양 (specs)을 생성했습니다. Gemini 3 Flash는 특히 스택 (stack) 선택과 스키마 설계 측면에서 여전히 견고하고 실용적이었으나, 상위 두 모델에 비해 환경 설정, 도구 (tooling), 보안 및 확장 메커니즘에 관한 모호함을 더 많이 남겨두어 운영상의 완결성 (operational completeness) 면에서 눈에 띄게 부족했습니다.

인간 검토 의견 (Human notes): Gemini 3.5 Flash는 실무적인 검토 관점에서 가장 강력한 아키텍처 결과물을 생성했습니다. 강력한 세부 사항, 근거 (rationale), 다이어그램 (diagrams), 그리고 탄탄한 사전 결정 사항 테이블 (decisions table)을 갖추어 플래그십 (flagship) 품질에 근접한 느낌을 주었습니다. Sonnet 4.6 또한 이 부문에서 우수한 성적을 거두었으며, 더 사려 깊은 수준의 세부 사항과 더 강력한 요약 구조를 통해 Gemini 3 Flash보다 확실히 개선된 모습을 보였습니다. 반면 Gemini 3 Flash는 쓸만하긴 했으나 더 간소화되어 있었고, 더 많은 결정 사항을 후속 단계로 남겨두었습니다. Gemini 3 Flash와 Sonnet 4.6 모두에서 나타난 긍정적인 공통점은 SQLite 대신 PostgreSQL을 선택했다는 점이며, 이는 두 모델 모두 앱의 의도된 형태에 더 부합한다는 느낌을 주었습니다.

UX 디자이너 (UX Designer)

UX 단계는 디자인 방향이 흐름 (flows), 상태 (states), 레이아웃 결정, 상호작용 세부 사항을 포함하여 구현을 가이드할 수 있을 만큼 충분히 구체적인지를 평가합니다.

LLM 판사 요약 (LLM judge summary): Sonnet 4.6과 Gemini 3.5 Flash 모두 뛰어난 UX 명세 (UX specs)를 제공했습니다. Sonnet 4.6은 가장 철저하고 체계적이라는 느낌을 주었으며, Gemini 3.5 Flash는 강력한 시각적 방향성(visual direction)과 더불어 특히 구체적인 반응형(responsive) 및 접근성(accessibility) 핸드오프(handoff)를 결합했습니다. Gemini 3 Flash는 양호하고 명확하게 사용 가능했으나, 검증 상태 (validation states), 검색 동작 (search behavior), 컴포넌트 수준의 전달 세부 사항 (component-level delivery detail)에 대한 처리가 다소 미흡하여, 완전히 실행 가능한 핸드오프 패키지라기보다는 유능한 텍스트 중심의 제품 디자인 명세 (product design spec)에 더 가까웠습니다.

인간 평가 노트 (Human notes): Gemini 3.5 Flash가 UX 측면에서 확실한 선두주자였습니다. 이 모델의 명세는 텍스트 와이어프레임 (text wireframes), 다이어그램 (diagrams), 근거 (rationale)를 포함하여 가장 완벽하고 개발자 친화적이었으며, 때때로 코드 샘플이 과한 경우가 있었음에도 구현 중 추측을 줄일 수 있을 만큼 충분한 세부 사항을 갖추고 있었습니다. Sonnet 4.6은 Gemini 3 Flash보다 더 사려 깊고 상세한 디자인 명세를 제공하며 텍스트 와이어 (text wires)를 포함하여 2위를 차지했습니다. 반면 Gemini 3 Flash는 눈에 띄게 가벼운 느낌이었으며, 핸드오프를 특히 강력하게 만들어 줄 시각적 계획 세부 사항 (visual planning detail)이 부족했습니다.

플래너 (Planner)

플래너 (Planner) 단계는 모델이 이전의 산출물 (artifacts)을 합리적인 작업 크기 산정 (task sizing) 및 의존성 순서 (dependency order)를 갖춘 실행 가능한 전달 시퀀스 (delivery sequence)로 변환할 수 있는지 테스트합니다.

LLM judge 요약 (LLM judge summary): 계획 수립 (Planning) 측면에서는 Gemini 3.5 Flash와 Gemini 3 Flash가 전반적으로 가장 강력한 모습을 보였습니다. 두 모델 모두 벤치마크가 선호하는 청킹 (chunking) 방식을 엄격히 준수하였으며, 강력한 MVP 중심의 개발자 친화적인 반복 (iteration) 세부 분석을 제공했습니다. Sonnet 4.6 또한 실무적인 관점에서는 매우 훌륭한 계획 수립 능력을 보여주었으나, 7번의 반복 단계로 범위를 넓히고 이상적인 크기보다 작은 청크 (chunk)를 최소 하나 포함함으로써 벤치마크의 정밀도 측면에서 다소 점수를 잃었습니다. 이로 인해 계획 자체는 실행 가능했음에도 불구하고, 크기 조절 (right-sizing) 측면에서 약간 덜 적절하다는 느낌을 주었습니다.

인간 평가 노트 (Human notes): 계획 수립 능력은 초기 단계의 역할들보다 결과가 더 엇갈렸습니다. Gemini 3 Flash는 테스트를 마지막 반복 단계로 미루는 흔한 실수를 범하긴 했지만, 수직적 슬라이스 (vertical slices) 방식에 더 가깝게 접근했기에 저에게는 전반적으로 가장 매력적인 계획 스타일을 보여주었습니다. Sonnet 4.6은 기능 중심의 작업으로 전환하기 전에 수평적 레이어 구축 (horizontal layer building)에 더 많은 시간을 할애했는데, 이는 이번 벤치마크에서는 덜 효과적으로 느껴졌습니다. Gemini 3.5 Flash 또한 테스트를 후반부에 배치했으며, 실행은 가능하지만 선호하지 않는 하이브리드 분할 (hybrid breakdown) 방식을 사용했습니다. 세 모델 중 Gemini 3.5 Flash는 작업 분할을 개선하기 위해 한 번의 반복 (iteration) 단계가 더 있었다면 더 좋았을 것입니다.

개발자 (Developer)

개발자 (Developer) 단계는 모델이 이전의 산출물 (artifacts)들과 일관성을 유지하면서, 할당된 백로그 (backlog)를 작동 가능한 MVP로 구현할 수 있는지를 측정합니다.

LLM 판사 요약 (LLM judge summary): 가장 강력한 구현은 Sonnet 4.6과 Gemini 3.5 Flash에서 나타났으나, 두 모델이 도달한 방식은 서로 달랐습니다. Sonnet 4.6은 범위 (breadth), 완성도 (polish), 그리고 테스트 깊이 (test depth) 면에서 뛰어났던 반면, Gemini 3.5 Flash는 더 단순한 아키텍처 (architecture)를 결합하면서도 매우 강력한 실행력, 깔끔한 로컬 시작 (local startup), 그리고 심각한 인도 (delivery) 문제 없이 작업을 수행했습니다. Gemini 3 Flash는 여전히 작동 가능한 엔드 투 엔드 (end-to-end) 흐름을 갖춘 유능한 MVP를 생성했지만, 깨진 빌드 경로 (build path), 약한 모바일 실행력, 그리고 아키텍처상의 약속과 실제 인도된 워크플로 (workflow) 사이의 일부 간극으로 인해 프로덕션 준비성 (production-readiness) 측면에서 다른 두 모델에 뒤처졌습니다.

인간 검토 노트 (Human notes): 개발 단계는 두 가지 서로 다른 질문으로 나뉩니다: 하네스 (harness) 품질과 최종 제품 품질입니다. Sonnet 4.6은 가장 매끄러운 도구 사용 (tool use)을 보여주었으며, 그룹 내에서 가장 강력한 코딩 하네스 (coding harness)인 Claude Code의 이점을 누렸습니다. 반면 Gemini 3 Flash는 반복적인 권한 요청, 대화형 Playwright 실수, 남겨진 백그라운드 태스크 (background tasks), 그리고 프롬프트가 입력될 때까지 .gitignore 파일이 누락되는 등 운영 측면에서 더 거칠었습니다. Gemini 3.5 Flash 또한 승인 및 환경 설정 과정에서 실질적인 마찰을 보이는 Antigravity 1.0으로 인해 하네스 측면에서 제약을 받았으나, 매우 빨랐으며 여전히 견고한 최종 앱을 만들어냈습니다. 실질적인 관점에서 Sonnet은 툴링 (tooling) 면에서 승리했지만, Gemini 3.5 Flash와 Gemini 3 Flash 모두 더 보기 좋은 최종 UI 결과물을 제공했습니다. 반면 Sonnet은 다른 결과가 기능적이었음에도 불구하고 Tailwind 빌드가 누락되어 출시된 경험 (shipped experience)에 큰 타격을 주었습니다.

검토자 (Reviewer)

검토 단계는 구축된 MVP가 실제로 브리프 (brief), 사양 (specs), 그리고 구현 계획을 충족하는지 확인함으로써 루프를 완성합니다.

LLM 심사위원 요약 (LLM judge summary): 검토자 (Reviewer) 성능이 전체 세트에서 가장 취약한 역할이었으나, Gemini 3.5 Flash는 재현 가능한 결함 (reproducible defects)을 근거 있는 출시 권고 (release recommendation)와 결합하고 Gemini 3 Flash보다 더 강력한 증거를 제시함으로써 세 모델 중 가장 강력한 검토를 수행했습니다. Sonnet 4.6 또한 검토를 잘 수행했으나, TypeScript 통화 호출 (currency call)을 놓친 점이 발목을 잡았습니다. 반면 Gemini 3 Flash는 결함에 대한 직관은 방향성 측면에서 맞았음에도 불구하고, 산출물 (artifacts), 벤치마크 판결 (benchmark-verdict) 형식, 그리고 더 광범위한 위험 분석 (risk analysis) 측면에서 기대에 미치지 못해 가장 불완전한 검토자로 나타났습니다.

인간 검토 의견 (Human notes): Sonnet 4.6과 Gemini 3.5 Flash는 검토 품질 면에서 상당히 근접했습니다. 두 모델 모두 탄탄한 버그 탐지 깊이와 유용한 테스트 결과를 보여주었으나, Sonnet은 강력한 재현 단계 (repro steps)와 준수한 커버리지 (coverage)로 눈에 띄는 동시에 앱의 주요 스타일링 실패를 놓쳤습니다. Gemini 3.5 Flash는 전반적으로 대등한 수준이었으며 유사한 범주의 문제들을 포착하여, 실질적인 QA 측면에서 비교할 만한 강점을 보여주었습니다. Gemini 3 Flash는 일부 문제를 식별했으나, 아키텍트 (architect) 및 UX 작업과 마찬가지로 검토 내용이 전반적으로 얇고 덜 철저하다는 느낌을 주었습니다.

스크린샷 (Screenshots)

스크린샷은 루브릭 (rubric) 점수와 실제 앱 품질이 일치하는 부분과 일치하지 않는 부분을 보여주는 데 도움이 됩니다. 이번 실행에서는 레이아웃 다듬기 (layout polish), 스타일링 완성도 (styling completeness), 그리고 각 모델이 기사 상세 (article detail), 목록 (list), 수정 (edit) 흐름을 얼마나 자신 있게 처리하는지에서 가장 큰 시각적 차이가 나타났습니다. Sonnet의 화면은 Tailwind 빌드 단계를 놓친 결과로 깨져 있음에 유의하십시오.

Gemini 3 Flash

Gemini 3.1 Flash articles list

Sonnet 4.6

Sonnet 4.6

Sonnet 4.6 articles list

Gemini 3.5 Flash

Gemini 3.5 Flash articles list

스크린샷 테이블

주관적 UX 리뷰

Gemini 3.5 Flash가 더 완전한 UI를 구현했으며, 레이아웃이 더 좋고 일관성이 있었습니다. Gemini 3 Flash도 콘텐츠 우선 접근 방식(content first approach)으로 근접했습니다. 아쉽게도 Sonnet은 CSS를 제대로 컴파일하지 못하여 UI 출력이 깨졌습니다.

토큰 및 비용 분석

품질 차이도 중요하지만, 경제성 역시 중요합니다. 다시 한번 하네스(harness)와 모델 간의 차이가 토큰 사용량과 전반적인 비용에서 명확하게 나타납니다.

주요 비용 보기