새로운 AI 개발 모델 순위

Rob Shocks 구독자 11,300명

요약

이 영상은 다양한 AI 모델로 실제 앱을 제작하며 생산성 기반 테스트를 수행한 결과를 공유합니다. 모델별 계획 수립, 반복 속도, 도구 활용, 커뮤니케이션, 코드 품질, 비용 등의 항목을 종합해 ‘모델 생산성 스코어’를 도출합니다. 테스트 결과를 바탕으로 Sonnet 4.5, GPT-5 등을 S티어로 분류하고, 시청자가 자신의 작업 환경에 맞춘 기준을 세워 최적의 AI 모델을 선택하도록 제안합니다.

주요 키워드

Model Productivity Score Plan Mode TPS URL Shortener Tool Calling Clarifying Question MVP Agent Communication Tokens Code Quality

하이라이트

🔑 모델 생산성 스코어는 실제 작업에서 얻을 수 있는 생산성 지표로, 단순 벤치마크 대신 실사용 테스트에 초점을 맞춥니다.
⚡️ Plan Mode를 활용해 모델의 계획 수립 능력을 비교했으며, Claude와 Gemini가 특히 우수한 성능을 보였습니다.
🚀 반복 속도가 중요한 디자인 모드에서는 Cheetah와 Haiku가 빠른 응답성으로 개발 효율성을 크게 높였습니다.
⚙️ 파일 시스템·터미널·MCP 호출 등 도구 활용 능력 평가에서 Anthropic 계열 모델이 도구 호출에 강점을 보였습니다.
💡 에이전트 커뮤니케이션 비교를 통해 Haiku는 상세한 사고 과정을, GPT 모델은 간결한 요약을 제공해 각기 다른 장단점을 드러냈습니다.
💰 모델별 토큰 사용량과 가격을 종합 분석해 비용 대비 효과를 고려한 선택이 중요하다고 강조합니다.
📊 코드 품질 검토 결과 GPT-5 Codeex가 최소 이슈를 기록했으며, Sonnet 4.5는 많은 코드를 작성했지만 이슈도 다소 늘어났습니다.
🏆 최종 티어 리스트에서 Sonnet 4.5와 GPT-5를 S티어로 선정했고, 개인 작업 특성에 맞춘 기준 수립을 권장합니다.

용어 설명

Model Productivity Score

실제 앱 개발·자동화 작업 단위로 측정한 생산성 점수

Plan Mode

Cursor에서 제공하는 사전 계획 생성 기능으로, 데이터베이스·API 라우트·투두 리스트까지 구성

Tokens per Second (TPS)

초당 처리되는 토큰 수를 뜻하는 속도 지표

MCP (모델 호출 프로그램)

모델이 외부 도구나 API를 호출할 때 활용하는 기능

Clarifying Question

계획 단계에서 요구사항을 명확히 하기 위해 모델이 묻는 추가 질문

Custom Slug

URL 단축기에서 사용자가 직접 설정하는 짧은 식별 문자열

MVP

Minimum Viable Product의 약자로, 최소 기능만 갖춘 초기 제품

Agent Communication

모델이 수행 과정과 다음 작업을 어떻게 설명해주는지에 대한 상호작용 방식

AI 앱 아이디어 구현을 위한 다양한 모델을 소개하며, 단순 벤치마크가 아닌 실제 작업 생산성에 기반한 '모델 생산성 스코어' 개념을 설명합니다.

[00:00] AI 개발 모델들이 정말 많아져서 선택의 폭이 넓어졌지만, 벤치마크만으로는 올바른 선택을 할 수 없다는 문제점을 제기합니다.

[00:26] 실제 앱 개발과 자동화 작업을 통해 '모델 생산성 점수'를 측정하는 실질적인 테스트 방법론을 소개하며, 7개 모델로 동일한 URL 단축기 앱을 만들어 비교하겠다고 설명합니다.

Cursor에서 Grock, Haiku, Sonnet, Codex, GLM, Gemini, Cheetah 7개 모델을 동시에 실행해 URL 단축기 앱을 동일한 프롬프트로 빌드하며 비교 테스트를 준비합니다.

타임라인 정보가 없습니다.

Plan Mode를 통해 데이터베이스 설계, API 라우트, 투두 리스트를 생성하게 한 뒤 모델별 계획의 완성도와 구체성을 비교합니다. Claude와 Gemini가 특히 우수했습니다.

[01:19] 모델의 계획 수립 능력이 중요해지고 있으며, 이는 좋은 계획을 세우고 검토할 시간을 제공해 크레딧 낭비를 방지한다고 설명합니다. 커서의 새로운 플랜 모드 기능을 활용해 테스트를 진행합니다.

[02:04] 모든 모델이 계획 수립에서 괜찮은 성과를 보였으며, Claude와 Gemini가 특히 좋았고, GPT-5 Codex는 간결하지만 정밀한 제어가 필요한 프로덕션 환경에서는 오히려 장점이 될 수 있다고 평가합니다.

디자인 모드에서 빠른 피드백이 중요함을 강조하며, Cheetah(내장 모델 추정)와 Anthropic Haiku가 반응 속도가 뛰어나 프로토타입 반복에 강점을 보였습니다.

[02:39] AI 모델 평가에서 반복 속도가 중요한 이유를 설명하며, 디자인 모드에서 AI를 활용한 와이어프레임과 프로토타이핑 작업 과정에서 빠른 반응성의 필요성을 강조합니다.

[02:54] Cursor의 내장 모델인 Cheetah와 Anthropic의 Haiku가 테스트에서 우수한 속도 성능을 보였으며, 개발자들이 채팅 시작 후 소셜 미디어나 다른 일에 방해받아 플로우를 잃는 문제점을 지적합니다.

[03:11] 이런 방해 상황을 AI를 활용한 코드 검토와 학습의 기회로 전환하는 방법을 제안하며, 이해하지 못하는 코드 부분을 파악하고 리팩토링하는 과정을 통해 더 나은 개발자가 될 수 있다고 설명합니다.

[03:26] 모델 처리량 그래프를 분석하며 Cheetah가 TPS(초당 토큰 수) 면에서 매우 빠르고, Haiku, Gemini Pro 2.5, Sonnet 4.5 순으로 이어지며, GPT-5 Codex는 가장 느리지만 최고 품질의 모델 중 하나라고 평가합니다.

파일 시스템 액세스, 터미널 사용, 검색·브라우저·MCP 호출 등 모델이 올바르게 도구를 호출하는지 테스트했습니다. Anthropic 계열이 도구 호출 정확도가 높았습니다.

[03:54] AI 모델의 도구 사용 능력 평가 기준을 제시하며, 파일 시스템 접근, 터미널 사용, 검색/브라우저 기능, MCP와 규칙 사용 등의 고급 기능과 맥락 인식 능력의 중요성을 설명합니다.

[04:18] 테스트 결과 Anthropic의 Sonnet과 Haiku 모델들이 도구 호출에서 우수한 성능을 보였으며, 의외로 GPT 모델들은 전반적으로 괜찮지만 때때로 도구 호출을 놓치는 경향이 있다고 분석합니다.

[04:39] JetBrains와 Juni의 후원을 소개하며 Python 개발자를 위한 PyCharm의 장점을 설명합니다. Python 구문에 대한 깊은 이해, 빠른 성능, 테스트 러너와 검사 도구 등의 기능으로 Python 작업을 편리하게 만든다고 강조합니다.

[05:07] JetBrains의 새로운 AI 에이전트 Juni를 소개하며, PyCharm, PHPStorm, IntelliJ IDEA 등 전체 제품군에서 작동하는 플랜 모드 기능과 프로젝트 이해 및 자율적 구축 능력을 설명합니다.

[05:23] AI 개발 도구가 프로젝트를 자율적으로 개발하고 빠른 작업을 위한 브레이브 모드, 그리고 테스트 자동화 기능까지 제공한다는 내용을 소개합니다.

Haiku의 상세한 사고 과정 출력과 GPT 모델의 간결한 설명 방식을 나란히 비교해, 사용자 관점에서 필요한 커뮤니케이션 스타일을 고를 수 있는 기준을 제시합니다.

[05:44] AI 에이전트의 커뮤니케이션 능력을 평가하며, Haiku 모델은 상세하게 설명하는 반면 GPT는 간결한 방식을 보인다고 비교 분석합니다.

[06:18] AI 모델의 계획 수립 과정에서 명확한 질문을 통해 요구사항을 정제하는 것의 중요성을 강조하며, GPT-5를 제외한 모든 모델이 이러한 접근법을 보인다고 설명합니다.

계획 후 요구사항을 확장하는 명확화 질문 여부를 확인했고, Haiku 등 6개 모델은 질문을 제시했으나 GPT-5는 바로 구현에 들어가는 차이를 보였습니다. 완료 후 결과 요약도 평가했습니다.

[06:50] 작업 완료 후 제공되는 요약 보고서의 차이점을 비교하며, 상세한 정보를 제공하는 Haiku와 간결한 GPT-5의 접근 방식을 대조합니다.

각 모델의 토큰당 요금을 시각화해 예산 관점에서 비교합니다. 더 비싼 모델이라도 높은 생산성으로 개발 시간을 절감하면 투자 대비 효율이 높아진다는 점을 강조했습니다.

[07:13] 모델 가격 책정에 대한 개인적 견해를 공유하며, 투자 수익률 관점에서 더 나은 모델에 추가 비용을 지불하는 것이 결국 시간 절약과 생산성 향상으로 이어진다고 주장합니다.

[08:00] AI 모델들의 토큰 비용 분석 결과를 시각적으로 보여주며, 단순히 입출력 토큰 비용만으로는 실제 프로젝트 비용을 판단하기 어렵다고 설명합니다.

앱 빌드 과정에서 각 모델의 실제 입력·출력 토큰 사용량을 수집해 비용을 계산했습니다. Claude Sonnet이 가장 비쌌고, GLM이 가장 저렴했으며 다양한 활용 시나리오를 고려합니다.

[08:14] 앱 구축 과정에서 각 모델의 실제 토큰 사용량을 측정한 결과, Claude Sonnet이 가장 높은 비용과 토큰 사용량을 기록했고, 그 다음으로 GPT-4o, Claude, Gemini Pro 순이었다고 보고합니다.

[08:42] 일부 모델들은 더 많은 가이드가 필요해서 프로젝트 완료를 위한 대화가 더 많이 필요했으며, Cheetah 모델의 경우 빠르지만 상당한 토큰 사용량으로 인해 비용이 높다고 언급합니다.

각 모델이 생성한 URL 단축기 UI를 비교했습니다. Grock은 단순했고 Haiku는 다양한 페이지 구성, Sonnet/GPT-5는 깔끔한 디자인을, Cheetah/GLM/Gemini는 요청한 기능을 충실히 구현했습니다.

[09:04] 디자인 측면에서 각 모델의 결과물을 평가하기 시작하며, Grok 2는 너무 단순하고, Haiku는 가장 많은 기능을 제공했지만 커스터마이징 기능이 부족했다고 설명합니다.

[09:33] Claude 3.5 Sonnet은 필요한 모든 기능을 완벽하게 구현했고, GPT-4o도 깔끔한 디자인을 보여줬으며, 특히 Cheetah는 매우 빠른 속도와 우수한 디자인 결과물을 제공했다고 평가합니다.

[10:09] GLM 4.6과 Gemini 2.0 Flash도 각각 대시보드 기능과 깔끔한 디자인으로 요청사항을 충족했으며, 이제 속도와 비용에 이어 코드 품질이라는 가장 중요한 평가 지표로 넘어간다고 예고합니다.

Code Rabbit, Bugbot 자동 검사와 수동 리뷰를 통해 각 모델 코드의 보안·버그 이슈를 분석했습니다. GPT-5 Codeex가 가장 적은 이슈를 기록했고, Sonnet은 코드량 대비 이슈가 다소 많았습니다.

[10:38] 단순한 앱 완성이 아닌 견고하고 프로덕션 준비된 코드 품질에 대해 설명하며, Code Rabbit과 Bugbot을 활용한 이슈 탐지 방법과 수동 코드 검토의 필요성을 강조합니다.

[11:00] GPT-5의 간결한 계획 수립이 걱정스러웠지만, 결과적으로 가장 적은 이슈를 발생시켜 놀라운 결과를 보여주었다고 분석합니다.

[11:28] Cheetah 모델의 우수한 성능과 Sonnet 4.5가 많은 코드를 작성함으로써 더 많은 이슈를 발생시킨 점을 설명하며, GPT-5를 정밀한 작업에 선호하는 이유를 제시합니다.

[11:54] 각 모델별 프로젝트 완성 시간을 비교하면서, 여기서 말하는 완성은 기능하는 MVP 수준이며, 프로덕션 배포까지 고려하면 이슈 수에 따라 결과가 달라질 수 있다고 설명합니다.

모델별로 최소 기능 제품(MVP)이 완성되는 데 걸린 시간을 측정했습니다. 속도뿐 아니라 이슈 수정까지 고려하면 실제 배포 준비 시간 차이를 가늠할 수 있습니다.

[12:13] 모든 중요 지표를 종합하여 S, A, B, C 티어로 구분한 결과를 발표하며, 계획 수립과 구현 모델을 분리하여 평가했다고 설명합니다.

Plan Mode·구현·디자인·속도·코스트·품질 기준을 종합해 S(최고)부터 C(보통)까지 티어를 매기고, 프로젝트 성격에 따른 모델 선택 가이드를 제시합니다.

[12:33] S 티어에는 Sonnet 4.5와 GPT-5가 포함되며, 하나만 선택한다면 Sonnet 4를 택하겠다고 하면서 그 이유를 개인의 디자인 중심 작업 패턴과 프로토타이핑 업무에서 설명합니다.

[13:10] 그린필드 프로젝트에서는 Sonnet 4.5를 선호하지만, 대규모 기존 프로젝트의 프로덕션 작업에서는 더 간결한 GPT-5를 선택할 것이라고 상황별 모델 선택 기준을 제시합니다.

[13:18] 기존 프로젝트나 대규모 브라운필드 작업에서는 GPT5를 선택할 것이라고 설명하며, 더 정밀하고 요청한 일만 정확히 수행하는 특성을 강조합니다.

[13:28] Gemini 2.5를 개발용 견실한 모델이자 합리적인 가격의 모델로 평가하며, Gemini 3.0에 대한 기대감을 표현합니다.

모델별 생산성 순위는 개인 작업 환경에 따라 달라질 수 있으므로, 다양한 프로젝트에서 반복 테스트하며 자신만의 평가 기준을 세울 것을 권장합니다.

[13:50] GLM 4.6과 Grok 4를 비교 평가하며, GLM의 가격 대비 성능과 Grok 4의 비용 효율성 문제를 분석합니다.

[14:27] 실제로는 가능하면 한 모델을 모든 작업에 사용하려고 하며, 빠른 구현이나 디자인 작업에 적합한 모델들을 소개합니다.

[14:41] Haiku를 S등급으로 평가하며, Sonnet과 유사한 성능과 빠른 속도, 프로토타입 디자인에서의 활용성을 설명합니다.

[15:08] Cheetah의 뛰어난 속도와 디자인 작업에서의 성능을 언급하며, Cursor 모델일 가능성에 대한 관심을 표현합니다.

[15:36] 빠른 구현에서 GPT 모델들을 사용하지 않는 이유를 설명하고, Grok4f에 대한 개인적인 사용 패턴을 공유합니다.

[16:01] 이 순위가 개인적인 생산성 기준임을 명확히 하고, 시청자들에게 각자의 프레임워크와 업무 환경을 고려한 독립적인 평가를 권합니다.

[00:00] AI로 앱 아이디어를 구현하고 싶다면

[00:01] 정말 선택지가 많습니다.

[00:04] Claude Sonnet, GPT-5,

[00:06] GLM, Grok, Qwen, Gemini, Cheetah,

[00:09] 그리고 이제 Anthropic의 새로운 Haiku 4.5까지 있는데,

[00:12] 이건 정말 빠릅니다. 하지만 문제가 있어요.

[00:15] 이 모든 놀라운 모델들이 있을 때,

[00:18] 실제로 어떻게 자신에게 맞는 것을 선택할까요?

[00:20] 스포일러를 하자면, 벤치마크로는 안 됩니다.

[00:22] 이미 벤치마크는 너무 쉽게

[00:24] 조작될 수 있다는 걸 알고 있죠.

[00:26] 그래서 지난 몇 달 동안 심층적인 실제 테스트를 진행했습니다.

[00:28] 실제로 앱을 만들고, 자동화된 작업을 실행하며,

[00:29] 제가 '모델 생산성 점수'라고 부르는 것을 측정했습니다.

[00:31] 특정 모델로 실제로 얼마나 많은

[00:34] 생산적인 작업을 완료할 수 있는지 말이죠.

[00:36] 실제 앱을 처음부터 만드는 라이브 테스트를 진행하며

[00:38] 모든 다른 모델들을 비교해보겠습니다.

[00:40] 그리고 어떤 모델이 어떤 분야에 좋은지

[00:42] 제 인사이트를 공유하겠습니다.

[00:44] 이 내용 중에서

[00:46] 다음 AI 모델을 선택하는 방법에 대한

[00:47] 생각을 바꿀 요소들을 많이 찾을 수 있을 겁니다.

[00:49] 이런 것이 제가 매주 하는 미친 테스트입니다.

[00:51] 여기 커서의 6개 다른 인스턴스가

[00:53] 설정되어 있습니다.

[00:55] Grok, Haiku, Sonnet, Codex, GLM, Gemini가 있고,

[00:58] 또한 다른 창에서 Cheetah도 실행 중입니다

[01:00] 이것도 테스트해보려고요.

[01:02] 모든 7개 모델에서

[01:04] 동일한 앱을 만들어보겠습니다.

[01:06] 그리고 모델 생산성 점수 측면에서

[01:07] 제가 찾는 것들에 대해 이야기하겠습니다.

[01:09] 성능을 비교하기 위해

[01:12] 동일한 프롬프트를 제공했습니다.

[01:14] 그리고 먼저 확인하고 싶은 것은

[01:16] 계획 수립 능력입니다.

[01:18] 계획 수립은 점점 더

[01:19] 중요해지고 있습니다. 모델에게

[01:22] 좋은 계획을 세울 기회를 주는

[01:23] 추가적인 사고 시간입니다.

[01:25] 둘째로, 계획을 진행하기 전에

[01:27] 검토하고 수정할 수 있게 해줍니다.

[01:29] 그래서 크레딧을 낭비하며

[01:30] 많은 시간을 허비하지 않죠.

[01:33] 모든 모델에 동일한 프롬프트를 사용했습니다.

[01:35] 기본적으로 URL 단축기를 만들고 싶었는데,

[01:37] bit.ly 같은 것 말이죠.

[01:39] 어떻게 진행되는지 봅시다.

[01:42] 커서의 새로운 플랜 모드를 사용하고 있는데,

[01:44] 이건 아마도 지금까지 어떤 도구에서도

[01:45] 본 것 중 최고의 기능 중 하나라고 생각합니다.

[01:48] 아래쪽을 클릭하기만 하면 됩니다.

[01:49] 제 머리 바로 아래 박스에서

[01:51] 플랜 모드가 보이실 겁니다.

[01:53] 커서에서 생성된 계획을 받게 되는데

[01:55] 일반적으로 데이터베이스 설정,

[01:57] API 라우트를 다루고

[01:58] 할 일 목록을 만듭니다.

[02:01] 계획 측면에서, 모든 모델이

[02:04] 상당히 좋은 성과를 냈습니다.

[02:06] Claude와 Gemini에는 추가 점수를 줍니다.

[02:08] GPT-5 Codex는 매우 간결한 계획을 제공했는데,

[02:12] 꼭 나쁜 것은 아닙니다.

[02:14] GPT-5 모델들과 GPT-5 Codex는

[02:17] 상당히 간결한 경향이 있습니다.

[02:20] 약간의 작업을 하고 멈춥니다.

[02:22] 매우 구체적으로 지시하고 싶을 때는

[02:24] 실제로 꽤 좋습니다.

[02:25] 기능을 작업할 때나

[02:27] 프로덕션 앱에서 작업할 때

[02:29] 모델이 혼자서 너무 멀리 나가지 않고,

[02:31] 단지 제어하면서

[02:33] 매우 지정된 방식으로 작업하기를 원할 때 말이죠.

[02:35] 그래서 다음으로 중요한 요소는

[02:37] 속도, 또는 제게는 중요한 것이

[02:39] 중요한 건 바로 반복 속도입니다. 제가

[02:42] 속도를 중요하게 생각하는 이유는 디자인

[02:44] 모드로 작업할 때입니다. 이 방식에서는 AI를 활용해

[02:46] 사용자 인터페이스를 와이어프레임하고 프로토타이핑합니다.

[02:48] 그리고 많은 디자인을 버리게 되죠.

[02:51] 이 과정이 빠르고 반응성이 좋아야 합니다.

[02:53] 기다리는 시간을 원하지 않거든요.

[02:54] 제 테스트에서 Cursor에 직접 내장된

[02:57] Cheetah 모델이 좋은 성능을 보였습니다.

[02:59] 많은 사람들이 이게 Cursor의 자체

[03:00] 모델이라고 생각하는데, Anthropic의 Haiku와 함께

[03:03] 좋은 성과를 거뒀습니다. 개발

[03:06] 시간의 많은 부분이 개발자가 채팅을 시작하고

[03:08] 소셜 미디어를 스크롤하거나

[03:09] 다른 일에 방해받을 때 낭비됩니다.

[03:11] 플로우에서 벗어나게 되죠. 사실 저는

[03:13] 이때가 코드를 검토하고 AI를 활용해

[03:15] 이해하지 못하는 코드 부분을

[03:18] 파악하거나 필요하면 리팩토링할 때라고

[03:19] 생각합니다. 이렇게 해야 학습할 수 있고

[03:22] 더 나은 개발자가 될 수 있습니다.

[03:24] 이 그래프를 보시면

[03:26] 정확한지 완전히 확신할 수는 없습니다.

[03:27] 어디서도 공식 발표를 본 적이 없거든요.

[03:29] 하지만 Cheetah는 모델 처리량 면에서

[03:30] 매우 빠릅니다. 이를

[03:33] TPS 또는

[03:34] 초당 토큰 수로 측정합니다.

[03:36] 그 다음에는

[03:39] Haiku, Gemini Pro 2.5, Sonnet 4.5, 그리고

[03:42] 나머지 모델들이 있습니다. GPT-5 Codex는

[03:45] 여기서 가장 느리지만, 사실

[03:46] 최고의 모델 중 하나라고 생각합니다.

[03:48] 다시 말하지만, 속도나

[03:51] 처리량만으로 모델을 평가할 수는 없습니다.

[03:54] 다음으로 도구 사용 능력으로 모델을 평가해보겠습니다.

[03:56] 기본적으로는 파일 시스템에

[03:58] 접근할 수 있는지, 터미널을

[04:00] 제대로 사용할 수 있는지입니다.

[04:02] 고급 기능으로는 검색과 브라우저 사용,

[04:04] 특히 MCP와 규칙 사용이 있습니다.

[04:08] MCP를 언제 사용할 수 있는지에 대한

[04:10] 맥락 인식 능력, 얼마나 많은 MCP를

[04:12] 메모리에 담을 수 있는지, 언제

[04:15] MCP를 호출해야 하는지 말이죠.

[04:18] 제 테스트에서는 Sonnet이나

[04:20] Haiku, Sonnet 같은 Anthropic 모델들이

[04:22] 도구 호출에서 매우 우수했습니다.

[04:25] 그리고 놀랍게도 GPT 모델들은

[04:28] 도구 호출에서 최고는 아니었습니다.

[04:30] GPT를 변호하자면, 전반적으로는

[04:32] 꽤 괜찮습니다. 다만

[04:33] 모든 모델을 스펙트럼으로 평가한다면,

[04:37] GPT는 때때로 도구 호출을 놓치는 경향이 있습니다.

[04:39] 잠깐 JetBrains와 Juni가

[04:42] 이 영상을 후원해 주신 것에 감사드립니다.

[04:43] Python 개발자라면

[04:45] 주목할 가치가 있습니다. 제 첫 번째 스타트업은

[04:47] 완전히 Python으로 구축되었습니다.

[04:49] 전문 Python 개발자라면

[04:52] JetBrains의 PyCharm보다

[04:54] 나은 IDE는 아마 없을 겁니다. Python 구문에 대한

[04:56] 깊은 네이티브 이해를 가지고 있습니다.

[04:59] 빠르고 테스트 러너와 검사 도구 등

[05:01] 필요한 모든 기능을 갖추고 있어서

[05:03] Python으로 작업할 때 생활을 훨씬

[05:05] 편하게 만들어줍니다. 정말 멋진 점은

[05:07] JetBrains가 이제

[05:09] Juni라는 전용 AI 에이전트를 갖고 있다는 것이고,

[05:12] PyCharm, PHPStorm, IntelliJ

[05:15] IDEA와 나머지 제품군에서 작동합니다.

[05:17] 프로젝트에 대한 이해를 설정하는

[05:19] 플랜 모드가 있습니다. 원하는 대로

[05:21] 자율적으로 작동하여 프로젝트를 구축해줍니다.

[05:23] 프로젝트를 개발할 수 있습니다. 그리고 빠르게 움직이고 싶을 때를 위한 브레이브 모드도 있어요.

[05:25] 사실 브레이브 모드라는 이름이 정말 마음에 듭니다.

[05:27] 그리고 작업이 완료되면

[05:28] 테스트를 설정하고 실행까지 해서

[05:30] 마음의 평안을 더해줍니다.

[05:32] 특히 AI로 작업할 때 말이죠.

[05:34] JetBrains 사용자라면

[05:36] Junie는 당연한 선택입니다.

[05:39] 설명란 링크를 통해 체험해보세요.

[05:40] 또한 에이전트 커뮤니케이션도

[05:42] 고려해야 합니다.

[05:44] 에이전트가 사용자와 얼마나 잘 소통하는지,

[05:46] 무엇을 하고 있는지, 다음에 무엇을 할 것인지 말이죠.

[05:48] 그럼 Haiku를 나란히 살펴보겠습니다.

[05:51] 이 모델은 매우 상세하거나 말을 많이 하는 편이고

[05:54] 반면 GPT는 좀 더 간결합니다.

[05:56] 많은 모델들이 실제로

[05:59] 실시간으로 사고 과정을 보여줍니다.

[06:01] 그리고 이는 모델이 어떻게 생각하는지

[06:03] 통찰을 얻는 데 정말 좋다고 생각해요.

[06:05] 그리고 실제로 무엇을 단계적으로 처리하기 시작하는지 말이죠.

[06:07] 모델의 초기 생각을 보고 있다면

[06:08] 프로세스를 빠르게 중단하고

[06:10] 다시 수정할 수 있습니다.

[06:13] 그러면 잘못된 가정을 하고 있다는 것을 깨달았을 때

[06:14] 많은 토큰을 낭비하지 않아도 됩니다.

[06:16] 우리는 앞서 계획이 매우 중요하다고 말했습니다.

[06:18] 커서에서 새로운 계획 모드로

[06:20] 계획을 생성할 때 일어나는 일 중 하나는

[06:22] 모델이 보통

[06:24] 몇 가지 명확한 질문을 가지고 돌아온다는 것입니다.

[06:26] 그리고 이것이 매우 중요하다고 생각합니다.

[06:28] 제가 테스트한 7개 모델 중에서

[06:30] GPT-5를 제외하고 모두

[06:33] 명확한 질문을 가지고 돌아왔습니다.

[06:34] GPT-5는 바로 구현에 뛰어들었어요.

[06:37] 이러한 명확한 질문들이 중요한 이유는

[06:38] 뛰어들기 전에 계획을 다듬는 데 도움이 되고

[06:40] 실제로 다음에 무엇을 만들지에 대해

[06:42] 조금 더 깊이 생각하게 하기 때문입니다.

[06:43] 모델이 프로세스를 완료하면

[06:45] 보통 완료된 작업에 대한

[06:47] 어떤 종류의 요약을 제공합니다.

[06:50] 그럼 Haiku의 요약 길이와

[06:51] 세부 사항을 비교해보겠습니다.

[06:53] 프로젝트 구조, 디자인 기능,

[06:55] 기술 스택과 모든 요구사항까지

[06:57] 제공하는 것과

[07:00] 매우 깔끔하고 짧은

[07:01] GPT-5의 결과를 비교해보겠습니다.

[07:04] 정말 개인 취향의 문제죠.

[07:07] 저는 이 더 상세한 접근 방식을 선호합니다.

[07:09] 우리가 살펴보는 명백한 요소는

[07:11] 모델 가격입니다.

[07:13] 우리 모두 각자의 예산이 있죠.

[07:15] 저는 다른 사람들만큼 이것에 집중하지 않습니다.

[07:18] 그리고 그 이유는

[07:20] 이 일에 쓸 돈이 많아서가 아닙니다.

[07:22] 투자 수익률을 보기 때문입니다.

[07:24] 더 나은 모델을 위해

[07:27] 조금 더 지불할 의향이 있습니다.

[07:29] 왜냐하면 결국 매달 추가로 지불하는

[07:32] $100이나 $200가

[07:35] 얻는 추가 품질이

[07:37] 더 적은 오류와 더 높은 생산성을 의미하기 때문입니다.

[07:39] 일반적인 개발자의 시간당 요율을 생각해보면

[07:41] 더 나은 모델로 한 달에 단 몇 시간만 절약해도

[07:44] 이미 상당한 비용 절약입니다.

[07:45] 여기서 보시다시피

[07:48] 이번 주 기준으로, 모델 가격은 이렇습니다.

[07:50] 완전히 정확하지는 않습니다.

[07:52] 다른 모델들이 다른 요금제를 가지고 있어서

[07:53] 20만 토큰 사용량 이하와 이상에 대해

[07:55] 다른 요금을 부과하기 때문입니다.

[07:58] 저는 그냥 평균을 내었습니다.

[08:00] 여기서 평균을 내어 시각적으로 보여드린 것입니다.

[08:02] 또 다른 흥미로운 점은

[08:04] 이런 모델들의 입력과 출력 토큰 비용만으로는 판단할 수 없다는 것입니다.

[08:09] 그 이유는 다음과 같습니다.

[08:11] 모든 모델에 대해

[08:14] 이 앱을 구축할 때 정확한 사용량을 내보냈습니다.

[08:16] 왜냐하면 이런 사실을 고려해야 하기 때문이죠.

[08:19] 모델이 더 저렴할 수는 있지만

[08:20] 실제로 프로젝트를 구축하는 과정에서

[08:22] 훨씬 더 많은 토큰을 사용할 수 있습니다.

[08:25] 따라서 현재 가격을 기준으로

[08:27] Claude Sonnet이 가장 비싼 비용과

[08:29] 가장 높은 토큰 생성량을 기록했습니다.

[08:32] 그 다음으로는

[08:34] GPT-4o, Claude, Gemini Pro,

[08:36] Grok, 그리고 GLM 순이었습니다.

[08:39] 어떤 경우에는 모델들이 좀 더 많은

[08:42] 가이드가 필요했고

[08:43] 그로 인해 모델과 저 사이에

[08:45] 더 많은 대화가 오고갔습니다.

[08:47] 프로젝트를 완료하기 위해서 말이죠.

[08:48] 하지만 전반적으로는 이런 결과가 나왔습니다.

[08:51] Cheetah가 여기에 없다는 걸 발견했는데,

[08:52] 기본적으로 GPT-4o와

[08:54] Claude 3.5 Haiku 사이 정도에 위치합니다.

[08:57] 사용량 측면에서 이 정도 수준이죠.

[08:59] 빠르긴 하지만 꽤 많은 비용이 듭니다.

[09:01] 토큰 사용량이 많거든요.

[09:04] 이제 디자인 측면에서 모델들을 평가해보겠습니다.

[09:06] Grok 2에서 나온 결과는 이렇습니다.

[09:08] 가장 간결하고 심플했지만

[09:10] 제 취향에는 조금 너무 단순했습니다.

[09:13] Haiku가 실제로 가장 많은 기능을 만들었어요.

[09:14] 랜딩 페이지와 디자인을 생성했습니다.

[09:17] 그 다음 짧은 링크를 만들 수 있습니다.

[09:19] 링크를 여기에 넣고 URL을 단축할 수 있죠.

[09:21] 단축된 URL을 제공해줍니다.

[09:24] 하지만 커스터마이징 기능은 제공하지 않았어요.

[09:25] 링크를 보면

[09:27] 이전에 추가된 모든 링크들을

[09:28] 별도의 페이지를 통해 보여줍니다.

[09:30] Claude 3.5 Sonnet은 필요한 모든 기능을 제공했습니다.

[09:33] 원본 URL과

[09:34] 커스텀 슬러그를 입력할 수 있고

[09:37] 추가한 모든 다른 URL들과

[09:39] 각각의 클릭 수를 볼 수 있습니다.

[09:42] 물론 몇 번 클릭되었는지도요.

[09:43] GPT-4o는 깔끔한 디자인을 보여줬습니다.

[09:47] URL과 커스텀 슬러그를 입력할 수 있고

[09:49] Sonnet 3.5와 거의 비슷하지만

[09:51] 실제로는 여기 디자인이

[09:53] 약간 더 선호되는 것 같습니다.

[09:55] 이것은 Cheetah에서 나온 결과인데

[09:57] 정말 훌륭합니다.

[09:59] 이 모델은 너무 빨라서 실제로 디자인 모드에서

[10:02] 꽤 많이 사용할 수 있을 것 같습니다.

[10:04] Cheetah가 실제로 Cursor 모델인지

[10:07] 확인해보는 게 정말 기대됩니다.

[10:09] GLM 4.6에서 괜찮은 결과를 얻었습니다.

[10:12] 죄송합니다, 여기 4.5라고 되어있는데

[10:14] 4.6이어야 합니다. 그리고 여기서

[10:16] 작은 차이점은

[10:18] 상단에 작은 대시보드를 제공한다는 것입니다.

[10:20] Gemini 2.0 Flash는 꽤 깔끔한 디자인을 보여줬습니다.

[10:23] 짧은 링크를 만들고

[10:24] 커스텀 별칭을 설정할 수 있으며

[10:26] 클릭 수 등을 제공했습니다.

[10:28] 정확히 요청한 대로 말이죠.

[10:30] 이제 흥미로운 지표들을 살펴보겠습니다.

[10:31] 적어도 제게는 흥미로운 지표들이죠.

[10:33] 속도와 비용을 살펴봤으니

[10:35] 가장 중요한 요소 중 하나는 물론

[10:36] 코드 품질인데, 저는 단순히

[10:38] 단순히 앱이 완성되고

[10:40] 끝났다는 것을 말하는 게 아닙니다. 실제로는

[10:42] 얼마나 견고하고

[10:44] 프로덕션에 준비된 코드가 생성되는지에 대해 말하고 있습니다.

[10:46] Code Rabbit과

[10:48] Bugbot을 조합해서 사용해 이슈들을 찾아냈습니다. 그리고

[10:51] 코드 자체를 수동으로 검토했습니다.

[10:53] 여전히 인간의

[10:54] 검토가 필요하다고 생각합니다. 보안 이슈나

[10:56] 큰 버그들을

[10:58] 나중에 도입하지 않도록 말입니다. 앞서

[11:00] GPT-5가 계획 수립에서 매우 간결했고

[11:03] 그것이 걱정스러웠다고 말했는데,

[11:04] 아이러니하게도 결국에는

[11:06] 코드베이스에서 가장 적은 수의 이슈를 가졌습니다.

[11:08] 프로젝트를 완성했을 때 말이죠.

[11:10] 이 막대 차트가 모든 것을 말해주지는 않습니다

[11:12] 왜냐하면

[11:14] GPT-5와 몇 차례 개입해야 했기 때문입니다

[11:16] 몇 가지 오류를 수정하기 위해 말입니다.

[11:18] 하지만 단순히 오류를 붙여넣고

[11:20] 수정해달라고 요청하는 것 이상은 하지 않았습니다.

[11:22] 문제를 어떻게 해결할지

[11:24] 아는 저만의 편견을 개입시키지 않았습니다.

[11:25] 이번에서 저에게 놀라운 발견은

[11:28] Cheetah가 얼마나 잘했는지였습니다.

[11:30] 이것은 매우 빠른 모델입니다.

[11:32] 이것이 어떻게 발전할지 흥미롭습니다.

[11:34] 여기서 보실 수 있듯이

[11:35] 제가 좋아하는 모델 중 하나인 Sonnet 4.5가 실제로

[11:38] 상당한 양의 이슈들을 도입했습니다. 그리고 이것은

[11:40] 약간 치우쳐진 것입니다. 왜냐하면

[11:42] 훨씬 더 많은 코드를 작성했고

[11:43] 따라서 문제가 발생할

[11:45] 표면적이 더 많기 때문입니다. 이것이 바로

[11:47] GPT-5를 사용하기를 좋아하는 이유입니다

[11:50] 정확하기를 원하고 기존의

[11:52] 프로젝트로 작업할 때 말입니다. 각

[11:54] 모델로 완성된 프로젝트에 도달하는데

[11:56] 걸린 시간입니다. 여기서 주목할 중요한 점은

[11:58] 완성된 프로젝트라고 할 때

[12:00] 기능하는 MVP를 의미한다는 것입니다. 만약 이것을

[12:03] 배포된 프로덕션 애플리케이션까지

[12:04] 완전히 가져간다면,

[12:06] 각 모델에서 해결해야 할 이슈의 수에 의해

[12:09] 약간 치우쳐질 수도 있습니다.

[12:11] 지금까지 제가 중요하다고 생각하는

[12:13] 모든 지표들을 살펴봤습니다

[12:14] 그리고 여러분이 주의를 기울여야 할

[12:16] 지표들 말입니다. 이 테스트를 실행한 후

[12:18] 제 최종 결론은 무엇일까요? 모든

[12:21] 기준을 고려한다면,

[12:22] 다음과 같이 티어 리스트로 분류합니다.

[12:25] S가 최고이고 A, B, C 순입니다.

[12:27] 또한 계획 수립과 구현 모델로 분류했습니다.

[12:30] 여기 S 티어에는 Sonnet 4.5와

[12:33] GPT-5가 있습니다. 계획 수립 측면에서

[12:37] 이 모델들을 가장 높게 평가했습니다. 만약

[12:40] 하나의 모델에만 접근할 수 있다고 한다면

[12:43] 아마도

[12:45] Sonnet 4를 선택할 것입니다. 그리고 이것은

[12:47] 꽤 주관적입니다. 첫째, 저는

[12:49] 디자인 작업을 많이 하는데 이 모델이 디자인을 잘합니다.

[12:51] 저와 잘 소통하기 때문에 무엇이

[12:54] 진행되고 있는지 알 수 있고

[12:55] 진행하면서 모델을 수정할 수 있습니다.

[12:57] 제가 하는 일의 대부분은 프로토타이핑입니다.

[12:59] 저와 제 고객들을 위한

[13:01] 아이디어를 테스트하기 위해 MVP를 생성하고

[13:03] 구축합니다. 그리고

[13:06] Sonnet 4.5가 이런 종류의

[13:08] 그린필드 프로젝트에 매우 좋다는 것을 발견했습니다.

[13:10] 만약 제 주요 역할이 대규모 브라운필드나

[13:13] 기존 프로젝트의 프로덕션이라면, 아마도 GPT-5를 선택할 것입니다

[13:16] 단순히 더 간결하기 때문입니다

[13:18] 좀 더 정밀하기 때문이죠

[13:20] 제가 요청한 일만 정확히 하고

[13:22] 그 이상은 하지 않거든요. 그리고 기존

[13:24] 기능을 업데이트하거나 코드베이스를

[13:26] 리팩토링할 때는 바로 그런 점이

[13:28] 필요하거든요. Gemini 2.5는 개발에

[13:31] 매우 견실한 모델이고

[13:32] 실제로 꽤 합리적인 가격이에요.

[13:34] Gemini 시리즈는 주목할 만하다고

[13:36] 생각합니다. 저희는 Gemini 3.0을

[13:39] 간절히 기다리고 있고, 초기

[13:40] 징후들을 보면 꽤 강력한

[13:42] 모델이 될 것 같습니다. 출시되면

[13:44] 더 많은 테스트를 해보고 채널에

[13:45] 업데이트를 올릴 예정입니다.

[13:47] 그러니 놓치지 않도록 구독해 주세요.

[13:50] 그리고 GLM 4.6과 Grok 4가 있습니다.

[13:52] Qwen도 여기에 포함시키고

[13:54] 싶었는데요. 이번 테스트에는

[13:56] 포함시키지 않았지만, 아마 이

[13:57] 어딘가에 위치할 것 같습니다.

[13:59] GLM이 A등급까지 올라가지 못한

[14:01] 이유는 작업할 때 꽤 많은

[14:03] 문제가 생기는 경향이 있기

[14:05] 때문입니다. 하지만 가격이

[14:07] 정말 좋다는 점은 부인할 수

[14:09] 없어요. 그래서 예산이 제한적이라면

[14:11] GLM 4.6으로 작업하는 것도

[14:13] 꽤 만족스러울 것 같습니다.

[14:16] 이제 Grok 4를 보면, 사실

[14:18] C등급에 있어야 한다고 생각해요.

[14:20] 그 이유는 동작 방식이나

[14:22] 품질이 GLM 4.6과 비슷한데

[14:24] 비용 면에서는 그렇지 않거든요.

[14:26] GLM보다 훨씬 비싸요. 그래서

[14:27] 실제로는 여기서 등급을

[14:29] 내릴 것 같습니다. 여기 기획이라고

[14:31] 적어뒀지만, 실제로는 가능하면

[14:32] 이 모델들 중 하나를

[14:34] 모든 작업에 사용할 겁니다.

[14:36] 속도가 중요한 빠른 구현을 원하거나

[14:38] 디자인이나 부담 없는 작업을

[14:39] 할 때는 바로 이런 모델들을

[14:41] 사용하겠습니다. 지금 당장은

[14:44] Haiku를 S등급에 올려두겠습니다.

[14:46] 일주일 정도 사용해봤는데

[14:48] Sonnet과 매우 유사한 느낌이고

[14:50] 그 모델에 익숙하며 정말 빠릅니다.

[14:53] 프로토타입 디자인에 많이

[14:55] 사용할 예정입니다. 이전

[14:56] 영상에서 디자인 모드에 대해

[14:58] 이야기한 적이 있는데, 모델이

[15:00] 애플리케이션의 프론트엔드만

[15:02] 작업하도록 해서 아이디어와

[15:04] 인터페이스를 디자인해보고

[15:05] 어떤 것이 효과적인지 확인하는 방식입니다.

[15:08] 대부분 버리고 다시 시작하는

[15:10] 경우가 많아서, Haiku 같은

[15:12] 모델이 그런 작업에 적합하다고

[15:14] 생각합니다. Cheetah는 정말 흥미로워요.

[15:16] Haiku보다 빠르거든요. S등급에

[15:18] 올리지 않은 유일한 이유는

[15:20] 충분히 사용해볼 시간이

[15:22] 없었기 때문인데, 매우

[15:23] 흥미로워 보이고 디자인 변형

[15:25] 작업을 할 때 실제로 꽤 좋은 성능을 보였어요.

[15:28] 이것도 주목할 만하고, 실제로

[15:30] Cursor에서 나온 모델인지

[15:32] 궁금합니다. 저는 개인적으로 빠른 구현에는

[15:36] GPT 모델을 전혀 사용하지 않습니다.

[15:38] GPT mini나 GPT codex low

[15:40] 또는 medium 같은 정말 빠른

[15:43] 모델들에 접근할 수는 있어요.

[15:45] 하지만 Codex 사용자이거나

[15:47] GPT 모델만 사용한다면

[15:49] low나 mini 모델 중 하나가

[15:51] 도움이 될 수 있습니다.

[15:52] 그리고 Grok4f는 완전히 괜찮은

[15:55] 모델이지만, 솔직히 저는

[15:56] 사용하지 않습니다. 선택권이

[15:58] 있다면 Grok 4f fast보다는

[16:01] 위의 것들 중 하나를 선택할 겁니다.

[16:03] 지금 많은 분들이 화면을 보며

[16:06] 왜 선호하는 모델이 여기에

[16:08] 없거나 더 높은 순위에 있지

[16:10] 않는지 궁금해하실 텐데요.

[16:12] 이는 제가 사용하는 프레임워크와

[16:13] 작업하는 업무와 문제, 그리고

[16:16] 제가 구축하는 프로젝트 유형을

[16:17] 바탕으로 한 개인적인 생산성

[16:19] 점수 또는 순위 시스템입니다.

[16:21] 여러분이 정말 해주셨으면

[16:22] 하는 것은 스스로 생각해보는

[16:24] 것입니다. 여러분이 사용하는

[16:25] 프레임워크와 매일 작업하는

[16:27] 업무의 유형, 그리고 여러분에게

[16:29] 중요한 것이 무엇인지 생각해보세요.

[16:31] 여러분만의 기준을 만들어보세요.

[16:33] 제가 여기 나열한 것들은

[16:35] 생산성 측면에서 저에게 중요한

[16:37] 것들이고, 제가 개인적으로

[16:38] 선호하며 가장 많은 가치를

[16:40] 얻는 모델들입니다. 주목할 점은

[16:43] 한 번의 테스트로 특정

[16:44] 결과를 얻을 수도 있다는 것입니다.

[16:46] 이런 모델들을 다양한

[16:48] 프로젝트에서 일정 기간 동안

[16:49] 사용해보는 것이 중요한데

[16:51] 어떤 경우에는 특정 기능이나

[16:52] 제품 구현에서 한 모델이

[16:54] 우연히 좋은 결과를 낼 수 있거든요.