제미니 2.5 플래시: 가격 대비 성능에서 독보적인 모델

GosuCoder 구독자 9,180명

요약

이 영상은 제미니 2.5 플래시가 이전 모델인 제미니 플래시 2.0의 강점을 계승하며 가격 대비 뛰어난 성능을 보여준다는 점을 강조한다. 평가 프레임워크를 통해 토큰 비용, arena score 등 여러 지표를 바탕으로 실사용 코드 환경에서의 성능을 분석하였다. 특히 ‘생각 모드’와 ‘코드 모드’ 간의 차이가 모델의 출력 및 diff 처리에 미치는 영향을 상세하게 비교하였다. 마지막으로, 다양한 모델 간 역할 분담과 혼합 모델 평가를 통해 향후 활용 방향과 개선점을 논의한다.

주요 키워드

제미니 2.5 플래시 가격 대비 성능 평가 프레임워크 토큰 비용 arena score 생각 모드 코드 모드 micromanager GPT4.1 오케스트레이터

하이라이트

🔑 제미니 2.5 플래시는 이전 모델 대비 가격 대비 성능이 크게 향상되어 독보적인 위치를 차지합니다.
⚡️ 평가 프레임워크와 arena score를 통해 모델별 토큰 당 비용과 실제 성능을 정량적으로 분석합니다.
🌟 ‘생각 모드’와 ‘코드 모드’의 사용 차이가 모델의 출력 품질 및 diff 처리에 미치는 영향을 중점적으로 다룹니다.
🚀 micromanager 코딩 오케스트레이터를 활용하여 모델의 실제 코드 생성 및 관리 능력을 평가하는 과정을 설명합니다.
📌 혼합 모델 설정을 통해 각 역할에 최적화된 모델 배분 전략을 제시하며, GPT4.1 등과의 성능 차이를 비교합니다.
🔥 최종 평가에서는 제미니 2.5 플래시가 다양한 테스트에서 가격 대비 성능 면에서 확실한 강점을 보임을 강조합니다.

용어 설명

제미니 2.5 플래시

가격 대비 뛰어난 성능을 제공하며, 이전 2.0 모델의 강점을 계승한 차세대 모델.

생각 모드

모델이 추가 토큰을 사용해 사고 과정을 활성화하는 모드로, 코드 작성 시 토큰 생성 및 품질에 영향을 미침.

코드 모드

코드 작성에 최적화되어 동작하는 모드로, 실제 프로그래밍 환경에서 모델이 어떻게 작동하는지 평가함.

micromanager 오케스트레이터

모델의 작업을 작은 단위로 쪼개어 관리하며, 실제 코드 생성 및 실행 평가를 지원하는 도구.

arena score

모델의 성능을 정량적으로 평가하기 위해 토큰 비용과 연계하여 산출하는 지표.

eval framework

모델을 실제 코드베이스 및 다양한 테스트 케이스에 적용하여 평가하는 시스템.

제미니 2.5 플래시의 출시와 초기 인상을 소개하며, 이전 모델인 2.0 플래시와의 차별점을 언급합니다.

[00:01] Gemini 2.5 Flash가 출시되어 MacBook에서 평가 프레임워크를 통한 테스트와 실제 코드베이스에서의 성능 테스트를 진행했습니다.

평가 프레임워크를 통한 arena score 및 토큰 당 가격 분석을 설명하며, 전반적인 테스트 환경을 소개합니다.

[00:22] Gemini Flash 2.0은 이전의 가성비 최강자였으며, 2.5 버전도 가격 대비 성능이 뛰어난 것으로 평가되었습니다.

[00:59] 아레나 점수와 백만 토큰당 가격을 비교했을 때, Gemini 2.5 시리즈는 매우 경쟁력 있는 성능을 보여주고 있습니다.

[01:40] thinking 모드 사용 시 예상과 달리 코딩 작업에서 더 많은 문제가 발생했으며, 특히 코드 비교와 도구 호출에서 어려움이 있었습니다.

생각 모드와 비활성화 상태에서의 성능 차이, 코드 diff 및 문맥 처리 문제를 중심으로 성능 분석 결과를 제시합니다.

[02:30] 현재 개발 중인 화면 녹화 시스템은 로컬 버전의 Loom과 유사하며, 웹캠과 모니터 연결이 가능한 다중 파일 지원 시스템입니다.

[03:20] 성능 평가 방법론을 설명하며, 파이썬 스크립트와 LLM을 심사관으로 활용하여 출력을 검증하고 점수를 산출하는 시스템을 소개합니다.

[03:53] 심사 점수의 편차는 약 15%이며, 이상치가 발견될 경우 사람이 직접 개입하여 판단을 내리는 프로세스를 설명합니다.

[04:30] 화면 녹화 테스트에서 GPT4.1과 GPT4.0 Mini는 30%, Flash 2.5 비사고 버전은 60%, 사고 버전은 46%의 성능을 보였습니다.

[05:32] GPT4.1은 더 비싼 모델임에도 코드 모드에서는 Flash 2.5보다 낮은 성능을 보였습니다.

[05:54] 마이크로매니저 코딩 오케스트레이터를 도입하여 작업을 더 작은 단위로 나누어 각각 독립적인 컨텍스트로 처리하는 방식을 설명합니다.

[06:22] 새로운 접근 방식으로 GPT4.1은 75%까지 성능이 향상되었고, Flash 2.5 사고 버전은 62%로 개선되었으나, 비사고 버전은 비슷한 수준을 유지했습니다.

[07:02] 모델 성능 비교 결과, GPT4.0 mini와 GPT4.1 mini는 아키텍트, 마이크로매니저, 디자이너 역할에서 성능이 크게 저하되어 각각 8%와 12%의 낮은 성과를 보였습니다.

[07:45] 혼합 모델 테스트에서는 Gemini 2.5를 아키텍트와 마이크로매니저로 사용하고, 다른 모델들을 보조 역할로 활용했습니다. GPT4.1은 80% 초반대의 좋은 성과를 보였고, Gemini 2.5 버전들은 75-80% 정도의 성능을 보였습니다.

다양한 역할(아키텍트, 디자이너 등)로 모델을 배분해 테스트하며, GPT4.1 등 다른 모델과의 성능 및 역할 배분 전략을 비교합니다.

[08:59] Eval 2 테스트에서 GPT04 mini가 놀랍게도 90-95% 의 매우 높은 성능을 보였으며, Flash 2.5의 non-thinking 버전이 thinking 버전보다 더 좋은 결과를 나타냈습니다.

[09:41] 토큰 수 증가에 따른 성능 차이가 발견되었으며, thinking 모드는 코드 모드에서 맥락이 늘어날수록 품질이 저하되는 경향을 보였습니다.

[10:13] 이러한 테스트 결과를 통해 문제 유형에 따른 모델 선택의 중요성이 입증되었으며, 향후 모든 평가와 코드 프롬프트를 오픈소스로 공개할 예정입니다.

[10:33] GPT4.1은 코드 모드 단독으로는 성능이 좋지 않았지만, 오케스트레이터에서는 뛰어난 성능을 보여줬습니다. 이는 많은 사람들이 GPT4.1의 코딩 능력을 평가절하하는 이유를 설명해줍니다.

[10:57] Eval 3 테스트에서 Flash 2.5는 약 30%, 비사고 버전은 40% 성능을 보여준 반면, GPT4.1 미니와 GPT04 미니는 한자릿수 성능을 기록했습니다.

[11:45] Ader Polyglot 리더보드에서 새 모델은 Gemini 2.0 Flash보다 크게 향상된 성능을 보여주며, GPT4.1과 비슷한 수준의 결과를 더 저렴한 비용으로 달성했습니다.

[12:34] 새로운 팀 구성: 마이크로 매니저로 Gemini 2.5 Pro Preview, 디자이너로 Claude 3.7 Sonic, 미들레벨에 GPT4.1, 시니어와 아키텍트에 Gemini 2.5 Pro를 배치할 예정입니다.

[13:32] 이전에는 OpenAI와 Claude가 지배적이었던 환경이 이제는 Google의 모델들이 주도하게 되었으며, 특히 비용 효율성과 정확한 서버 호출, 웹 검색 능력이 돋보입니다.

[14:00] Gemini 2.5 Flash에 대한 매우 긍정적인 평가를 내리며, GPT4.1과 비교했을 때도 대등한 성능을 보여주고 있다고 설명합니다.

전체 테스트 결과를 종합해 제미니 2.5 플래시의 가격 대비 성능 우수성을 강조하며, 향후 개선 및 추가 테스트 계획을 공유합니다.

[14:28] 이 모델의 주요 장점으로 2.0 대비 큰 업그레이드, 뛰어난 가격 대비 가치, 일관된 출력 품질, 그리고 향상된 코드베이스 처리 능력을 언급합니다.

[15:15] 부메랑 모드 사용 시의 제한사항과 이를 개선하기 위한 방안에 대해 설명하며, 큰 컨텍스트 윈도우의 장점을 강조합니다.

[16:01] 모델의 한계점으로 생각 모드 설정의 개선 필요성과 큰 컨텍스트 윈도우에서 발생하는 diff 오류 문제를 지적합니다.

[17:22] thinking 모드는 단순 코드 작성, 주니어 모드, 인턴 모드, 코드 모드에는 적합하지 않으며, 아키텍트 모드나 계획 수립용 오케스트레이터로 사용하는 것이 좋을 것 같다고 설명합니다.

[18:00] O4 mini가 가격 대비 가치 면에서 가장 큰 경쟁자이며, Gemini 2.5 Flash와 성능을 비교했을 때 케이스별로 다양한 결과를 보이지만, Gemini 2.5 Flash가 여전히 우위를 가지고 있다고 평가합니다.

[18:51] 코딩과 마케팅 분야에서 LLM 성능을 평가하기 위한 두 개의 평가 프레임워크를 구축 중이며, LLM을 심사관으로 활용하고 인간 중심 평가를 포함한 다양한 방법론을 연구하고 있습니다.

[19:26] 초기 단계의 테스트임에도 불구하고 매우 일관된 결과를 보여주었으며, 극단적인 이상치가 거의 없었다고 보고합니다.

[00:01] Gemini 2.5 Flash가 목요일에 출시되었는데, 마침 그때

[00:03] 제가 아이들과 캠핑을 가는 중이었어요.

[00:05] 그래서 시간을 내서 MacBook으로

[00:08] 이것을 테스트해보고 제가 만든 평가 프레임워크로

[00:10] 테스트를 해봤는데, 이에 대해서는

[00:12] 잠시 후에 더 자세히 설명드리겠습니다.

[00:14] 실제 제 코드베이스에서

[00:15] 성능을 테스트해봤고, 그 결과도

[00:17] 공유해드리겠습니다. 하지만 그전에

[00:20] Gemini Flash 2.0에 대해 언급하고 싶습니다.

[00:22] 이 모델은 제가 몇 달 전까지 정말 많이 사용했던 모델입니다.

[00:26] 이 모델은 가성비 최강자 중 하나였죠.

[00:31] 제가 자주 찾는 모델 중 하나였습니다.

[00:34] 그리고 Gemini Flash 2.5는

[00:37] 이러한 명성을 이어받았다고 생각합니다.

[00:39] 제 생각에는 여전히 가성비 최강자입니다.

[00:42] 제가 지금까지 진행한 모든 테스트에서

[00:45] 가격 대비 성능이 가장 뛰어났습니다.

[00:48] 이에 대해 좀 더 자세히 살펴보겠습니다.

[00:49] 아레나 점수는 약간의 의구심을 가지고 봐야 하지만

[00:52] 제대로 측정했을 때는

[00:54] 모델의 성능을 판단하는 좋은 기준이 된다고 생각합니다.

[00:56] 이 경우 특히

[00:59] 모델의 성능이

[01:01] 매우 뛰어난 것을 볼 수 있습니다.

[01:04] Gemini 2.5 시리즈의 백만 토큰당 가격이

[01:08] 아레나 점수와 비교했을 때 정말 놀랍습니다.

[01:12] 아레나 점수 대비 가격이 매우 경쟁력 있죠.

[01:15] 현재 Gemini 2.5 Flash 프리뷰 버전은

[01:18] 아직 많은 투표를 받지 않아서

[01:22] 점수가 더 낮아질 수 있지만

[01:24] 이 정도의 저렴한 가격으로

[01:27] 더 큰 모델들과 비슷한 성능을 보여주는 것은

[01:32] 정말 놀라운 일입니다.

[01:35] 이에 대한 자세한 통계를

[01:36] 곧 보여드리겠습니다. 한 가지

[01:39] 강조하고 싶은 점은

[01:40] thinking 모드를 켰을 때와 껐을 때의

[01:42] 출력 토큰 가격 차이입니다.

[01:45] 처음에 제 가설은

[01:48] 코딩할 때는 대부분

[01:51] thinking 모드를 켜는 것이 좋을 거라고

[01:54] 생각했는데, 실제로는

[01:56] 그렇지 않다는 것을 발견했고

[01:59] 대부분의 작업을

[02:00] thinking 모드 없이 더 잘 수행할 수 있었습니다.

[02:02] 여러분도 같은 경험을 하셨는지 궁금합니다.

[02:04] 특히 저는

[02:07] 때때로 코드 비교(diffing)에서

[02:10] 더 많은 문제가 발생하고

[02:14] root 코드 내에서 특정 도구 호출에

[02:17] thinking 모드가 켜져 있을 때 문제가 있었습니다.

[02:19] 이는 아마도 컨텍스트 윈도우가

[02:21] 증가함에 따라 발생하는 문제로 보입니다.

[02:25] 코드 비교도 잘 안 되고 도구 호출도

[02:28] 잘 작동하지 않았죠. 이제

[02:30] root 코드에서의 평가 시스템에 대해

[02:32] 말씀드리겠습니다. 이것은

[02:34] 제가 실제로 테스트하고 있는

[02:36] 화면 녹화기입니다. 이것은

[02:39] 로컬 버전의 Loom이라고 생각하시면 됩니다.

[02:42] 웹캠과 모니터를 연결할 수 있고

[02:45] 여러 파일에서 작동할 수 있습니다.

[02:49] 제 평가 시스템이 현재

[02:52] 작동하는 방식을 설명드리면

[02:54] 더 견고하게 만들어가는 중인데

[02:56] 최대한 완벽하게 만들려고

[02:59] 노력하고 있습니다. 기본적으로

[03:03] 충족해야 할 요구사항 목록을 제시합니다.

[03:05] 예를 들어, 필요한 파일들,

[03:07] 존재해야 하는 파일들, 필요한 테스트들,

[03:10] 그리고 매우 구체적으로

[03:13] 필요한 기능들에 대해

[03:14] 설명합니다. 이는 0부터 4까지의

[03:18] 등급 척도를 사용합니다.

[03:20] 이것을 모두 퍼센트로 환산하여

[03:23] 잠시 후에 차트로 보여드리겠습니다.

[03:25] 점수는 몇 가지 방식으로 산출됩니다.

[03:28] 첫째, 출력을 검증하기 위한

[03:31] 파이썬 스크립트 시리즈가 있습니다.

[03:33] 간단한 예로 파일이

[03:35] 존재하는지 확인하는 것이 있죠.

[03:36] 둘째, LLM을 심사관으로 사용하여

[03:40] 3번 실행하고 중간값을 취합니다.

[03:41] 매우 복잡한 심사 프롬프트가 있고

[03:45] 심사 프롬프트를 받아들이고

[03:48] 점수를 검증하는 심사 모드를

[03:52] 구축했습니다.

[03:53] 제가 테스트해본 결과, 심사 점수 간의 편차는

[03:58] 약 15% 정도입니다.

[04:01] 그래서 중간값을 사용하는데,

[04:04] 비교적 일관성이 있습니다. 만약

[04:07] 이상치가 있다면 표시를 하고

[04:09] 사람이 직접 개입하여

[04:13] 점수에 대한 판단을 내립니다.

[04:15] 또한 검토 중인 애플리케이션의

[04:18] 좋은 예시와 나쁜 예시를 제공합니다.

[04:21] 이 모든 것을 고려하여

[04:24] 살펴보면

[04:26] 여기 제 평가 테스트 중 하나가 있습니다.

[04:30] 이것은 화면 녹화 테스트입니다.

[04:32] 이것은 코드 모드로만 실행되었습니다.

[04:36] 퍼센트는 모든 요구사항을 충족하고

[04:38] 완벽하게 실행되는 것을

[04:42] 의미합니다.

[04:42] 여기서 놀라운 점은

[04:45] GPT4.1과 GPT4.0 Mini가 모두

[04:50] 약 30%의 점수를 받은 반면

[04:54] Flash 2.5 비사고 버전은 약 60%를 기록했고

[04:57] Flash 2.5 사고 버전은

[05:00] 46%를 기록했다는 것입니다.

[05:02] 이때부터 저는 진지하게

[05:05] 사고 방식에 대해 의문을 갖기 시작했고

[05:07] 이러한 성능을 보기 시작했습니다.

[05:10] 여러 번 실행해봤는데 이 결과들은

[05:13] 매우 일관적이었습니다. 오차 범위는

[05:15] 약 3~5% 정도로

[05:17] 점수 산정 과정에서

[05:19] 발생합니다. 따라서 여기에

[05:21] 막대가 있다고 상상해보면

[05:24] 위아래로 3~5% 정도 될 수 있습니다.

[05:26] 따라서 점수가 매우 근접하다면

[05:28] 오차 범위 내라고

[05:30] 생각할 수 있습니다. 여기서 주목할 점은

[05:32] 이들 간의 차이입니다.

[05:35] GPT4.1은 훨씬 더 비싼 모델이지만

[05:38] 코드 모드에서는 매우 일관되게

[05:41] 이 특정 문제에서 Flash 2.5보다 성능이 떨어졌습니다.

[05:44] 이제 제 마이크로매니저

[05:47] 코딩 오케스트레이터에 대해

[05:48] 소개하고 싶은데, 이는

[05:50] 다음 벤치마크로 넘어가기 전에

[05:52] 매우 중요한 부분입니다.

[05:54] 이것은 작업을 더 작은 단위로 나누며

[05:57] 각각은 자체 컨텍스트

[06:00] 윈도우를 가집니다. 첫 번째 테스트에서

[06:02] 우리가 방금 언급했던 각 모드에서

[06:06] 모델을 설정했습니다. 아키텍트,

[06:10] 연구원, 마이크로매니저, 인턴,

[06:12] 주니어, 미드레벨, 시니어, 디자이너

[06:14] 모두 테스트 중인 모델로 설정했습니다.

[06:17] GPT4.1은 코드 모드에서 했던

[06:21] 동일한 문제에서

[06:22] 75%까지 상승했습니다. 실제로 최고점은

[06:27] 80%에 근접했고, 최저점은

[06:30] 71% 약간 위였습니다.

[06:35] GPT4.1은 뛰어난 성능을 보였습니다.

[06:39] 그다음 Flash 2.5 사고 버전을 보면

[06:42] 약 46%에서 60% 정도로 증가했습니다.

[06:47] 실제 정확한 수치는 62%입니다.

[06:52] 반면 비사고 버전은

[06:55] 거의 동일한 수준을

[06:57] 유지했습니다.

[06:59] 사실 약간의 차이가 있을 수 있습니다.

[07:02] 오차 범위의 차이가 있었는데

[07:04] 실제로 약간 더 나빠졌습니다. GPT4.0 mini와

[07:07] GPT4.1 mini는 성능이 크게 저하되어

[07:12] 각각 8%와 12%로 떨어졌습니다. 이는

[07:15] 아키텍트나 마이크로매니저,

[07:18] 디자이너로서의 역할을

[07:21] 제대로 수행하지 못했기 때문입니다.

[07:23] 결과적으로 필요한 요구사항들을

[07:26] 많이 놓치게 되었죠.

[07:28]

[07:29] 이는 모든 역할을 부여했을 때의 결과입니다.

[07:32] GPT4.1은 더 비싼 모델인데,

[07:35] 이러한 테스트를 실행해보니

[07:38] 제가 만든 마이크로매니저가

[07:41] 일부 모델에서는 더 나은 코딩을 할 수 있다는 것이 입증되었습니다.

[07:45] 이제 혼합 모델 관점에서 살펴보겠습니다.

[07:49] 실제로 우리는

[07:50] Gemini를 사용할 건데

[07:52]

[07:54] 2.5를 아키텍트와

[07:57] 마이크로매니저로 사용하고

[07:59] 왼쪽에 나열된 모델들을

[08:02] 다른 모드에 사용할 것입니다. 다시 말해서

[08:06] 더 강력한 모델인 Gemini 2.5 Pro로

[08:09] 아키텍처와 오케스트레이터를 관리할 것입니다.

[08:12] 그 결과를 보면 GPT4.1이

[08:14] 80% 초반대로 올라갔습니다.

[08:17] 매우 매우 좋은 성과를 보였죠. 하지만

[08:21] Gemini 2.5 thinking과

[08:24] non-thinking 버전을 보면

[08:27] 런타임 오류를 포함해도

[08:31] 약간의 차이만 있을 뿐

[08:32] 75%에서 80% 정도를 기록했습니다.

[08:36] GPT4.0 mini와 GPT4.1 Mini는

[08:40] 50%에

[08:42] 근접했는데, 이는 같은 모델로 실행했을 때와 비교하면

[08:46] 놀라운 향상입니다. 이 점이 제게

[08:49] 정말 흥미진진한 부분인데요.

[08:51] 이러한 테스트를 실행하는 데

[08:53] 시간이 좀 걸립니다.

[08:55] 모든 평가를

[08:57] 여러 번 실행하고 싶기 때문이죠.

[08:59] 자, 이제 다음 결과를 보겠습니다. 이건 Eval 2인데

[09:02] 여기서 오타가 하나 있었습니다.

[09:05] GPT04 mini라고 했는데, 실제로는 GPT04

[09:08] mini입니다.

[09:10] 이 모델이 압도적이었는데

[09:11] 너무나 놀라운 성과를 보여서

[09:17] 정말 놀랐습니다.

[09:19] 이 테스트는 실제로 2-3회

[09:21] 더 실행해봤는데

[09:24] 편차가 매우 일관적이었습니다.

[09:27] 대부분의 경우 90% 이상을

[09:30] 기록했고 최대 95%까지 도달했습니다.

[09:33] 그리고 Flash 2.5의

[09:35] non-thinking 버전이 thinking 버전보다

[09:38] 더 좋은 성능을 보였습니다.

[09:41] 이는 토큰 수가 증가하면서

[09:43] 발생한 현상이라고 생각합니다. thinking 모드가

[09:48] 코드 모드에서 성능이 떨어지는 것은

[09:50] 토큰 생성 능력 때문이라고 봅니다.

[09:55] 맥락이 늘어날수록

[09:57] 품질이 저하되는 것 같습니다.

[10:00] 반면 오케스트레이터에서는

[10:01] 더 나은 성능을 보이는데,

[10:03] 이는 맥락을 부분적으로 살펴보기 때문입니다.

[10:06] 놀랍게도 GPT4.1과 GPT4.1

[10:10] Mini는 매우 저조한 성능을 보였습니다.

[10:13] 여기서 얻은 몇 가지 교훈이 있는데

[10:15] 문제에 따라 모델의 중요성이 매우 크다는 것입니다.

[10:18] 04 Mini가 이번 테스트에서 놀라웠는데

[10:21] 이와 관련해서

[10:23] 모든 평가와 코드 프롬프트를

[10:25] 오픈소스로 공개할 계획입니다.

[10:27] 시간이 좀 걸리겠지만

[10:28] 여러분들도

[10:29] 직접 실행해볼 수 있게 할 예정입니다.

[10:33] GPT4.1은 제가 테스트한 방식에서는

[10:36] 코드 모드만으로는 좋은 성능을 보여주지 못했습니다.

[10:38] 하지만 제 오케스트레이터에서는

[10:41] 놀라울 정도로 뛰어난 성능을 보여줬죠.

[10:45] 이것이 바로 제가 왜

[10:47] 제가 대화하는 사람들 중 일부가

[10:49] GPT4.1의 코딩 능력이 좋지 않다고 불평하는지

[10:52] 이해하게 된 이유입니다. 코드 모드에서는 실제로 성능이 떨어지거든요.

[10:57] Eval 3를 실행했을 때

[11:00] 아쉽게도 복잡도가 매우 높아서

[11:02] 점수가 일관성이 부족해 결과를 보여드리기가

[11:06] 어려운 상황입니다.

[11:08] 참고로 말씀드리면

[11:11] GPT4.1 미니와 GPT04 미니는

[11:15] 의미 있는 방식으로 과제를 완료하지 못했습니다.

[11:17] 그들의 점수는 한 자릿수에 불과했고

[11:19] Flash 2.5는 약 30%의 성능을 보여줬습니다.

[11:23] 그리고 생각하지 않는 버전의 Flash 2.5는

[11:25] 실제로 약 40% 정도였습니다.

[11:28] GPT4.1도 매우 저조한 성능을 보였죠.

[11:33] 그래서 Eval 3를 공개하기 전에

[11:35] 안정화 작업이 필요합니다.

[11:37] 아직 제가 만들고 있는

[11:39] 프레임워크의 초기 단계이기도 하고요.

[11:40] 이제 Ader Polyglot

[11:43] 리더보드를 살펴보겠습니다.

[11:45] 여기서 보시면 Gemini 2.0 Flash보다

[11:48] 훨씬 더 좋은 성능을 보여주는 것을 알 수 있습니다.

[11:50] 제가 사용해본 결과로는 이 Z 모델이

[11:53] 제가 사용하는 언어들에서

[11:55] 큰 발전을 이루었다고 생각합니다.

[11:58] 또한 GPT4.1과 매우 근접한 성능을 보여주는데

[12:03] 이 차트를 보시면

[12:06] 제가 말씀드린 내용을 확인하실 수 있습니다.

[12:09] 이걸 보세요. 이것은

[12:12] 제 마이크로 매니저로 진행한

[12:14] 특정 테스트 결과입니다.

[12:18] 보시다시피 GPT4.1보다

[12:20] 몇 퍼센트 포인트 더 좋은 성능을 보여주는데

[12:24] 훨씬 더 저렴한 가격으로 가능합니다.

[12:27] 물론 Gemini 2.5 Pro Preview가 더 좋고

[12:29] 이것과 페어링하면

[12:31] 정말 놀라운 결과를 얻을 수 있습니다.

[12:34] 그래서 제가 내일부터 사용할

[12:36] 팀 구성을 말씀드리면, Gemini 2.5 Pro Preview를

[12:40] 마이크로 매니저로, Claude 3.7 Sonic을

[12:44] 디자이너로 사용할 예정입니다.

[12:46] 사실 Claude의 자리를 대체한 모델은

[12:49] 아직 없었죠. 그리고

[12:51] Gemini Flash 2.5 Preview를 임시로

[12:53] 실행해서 더 많은 경험을 쌓을 예정입니다.

[12:56] 이 모델을 더 잘 이해하기 위해

[12:57] 주니어 레벨에서도 실행할 예정이고

[13:00] 미들 레벨에서는

[13:03] GPT4.1을 사용할 예정입니다. 특히

[13:05] 마이크로 매니저 도구에서

[13:08] 더 좋은 성능을 보여주거든요.

[13:10] 시니어는 Gemini 2.5 Pro를 유지하고

[13:13] 연구원은 당연히

[13:14] 2.0에서 2.5로 업그레이드됩니다.

[13:17] 매우 합리적인 선택이죠.

[13:20] 아키텍트는 Gemini 2.5 Pro를 사용할 건데

[13:22] 잠깐 생각해보면

[13:25] 얼마 전만 해도 이런 구성을

[13:28] 실행할 때

[13:29] 모든 것이

[13:32] OpenAI와 Claude였는데, 이제는 Google이

[13:36] 제 코딩 팀을 지배하기 시작했네요.

[13:39] 정말 놀라운 일입니다.

[13:41] 이 구성을 얼마나 유지할지는 두고 봐야겠지만

[13:44] 초기 징후를 봤을 때 이 모델은

[13:48] 정말 놀랍도록

[13:50] 비용 효율적이면서도

[13:52] 코딩을 아주 잘합니다. MCP 서버도

[13:55] 정확하게 호출하고 웹 검색도

[13:58] 제대로 수행하면서 정보를 가져왔습니다.

[14:00] 이 모델들에 매우 매우 감동받았습니다

[14:03] 실제로 제 미들웨어를 이것으로

[14:05] 교체하는 것도 괜찮을 것 같습니다. 하지만 솔직히

[14:08] GPT로 다시 돌아가서 말씀드리면

[14:12] 제 마이크로매니저에서 GPT4.1이 너무나 잘 작동해서

[14:15] 아직은 교체하기가 어렵습니다

[14:18] 왜냐하면 적절히 가이드만 한다면

[14:21] 정말 놀라운 성과를

[14:24] 보여주기 때문입니다. 이제

[14:26] 전반적인 생각을 마무리하겠습니다

[14:28] 우리가 이 모델을 가지게 된 것이

[14:30] 정말 행운이라고 말씀드리고 싶습니다. 2.0에서

[14:32] 큰 업그레이드가 이루어졌고, 가격 대비 가치가

[14:37] 정말 뛰어납니다. 2.0과 비교했을 때 대등한 수준이며

[14:41] 일관성과 출력 품질이 매우 뛰어납니다

[14:46] 코드베이스를 다루는 능력이

[14:48] 훨씬 더 좋아졌습니다. 이 모델에 매우 감동받았습니다

[14:52] 제가 코드베이스에서 매우

[14:54] 어려운 작업들을 마이크로매니저를 통해 실행해보았는데

[14:57] 제가 보여드린 방식으로 통합했을 때

[14:59] 정말 잘 작동했고

[15:01] 주니어 레벨과 인턴 레벨에서

[15:04] 일관되게 호출되었으며

[15:06] 놀라운 성과를 보여주었습니다

[15:09] 더 강력한 모델들과 비교해도

[15:12] 많은 가능성을 열어줍니다. 만약

[15:15] 마이크로매니저를 사용하지 않고

[15:17] 부메랑 모드를 사용한다면

[15:19] 조금 더 어려워질 수 있습니다. 부메랑 모드는

[15:21] 코드 모드, 아키텍트 모드,

[15:23] 부메랑 모드로만 제한되어 있기 때문입니다

[15:27] 조금 까다롭긴 하지만

[15:29] 부메랑 모드를 수정하여

[15:31] 여러 모드를 추가할 수 있습니다

[15:33] 간단한 작업의 경우 코드 모드로

[15:36] 전환하도록 설정할 수 있죠. 또 다른 장점은

[15:38] 매우 큰 컨텍스트 윈도우를 가지고 있어서

[15:40] 이에 대해 전혀 걱정할 필요가 없다는 것입니다

[15:42] 이 모델들은 상당히 잘 수행되며

[15:45] 컨텍스트를 잘 유지한다는 것을 알 수 있습니다

[15:48] 제가 이 모델들을 테스트해봤는데

[15:51] 컨텍스트 윈도우에서

[15:53] 50만에서 70만 토큰까지 테스트해봤고

[15:56] 기억력이 정말 놀랍도록 좋았습니다

[16:01] 하지만 생각 모드 설정에

[16:03] 약간의 작업이 필요할 것 같습니다

[16:06] 특히 코드 모드에서

[16:08] 지속적으로 더 나쁜

[16:10] 결과를 얻었기 때문입니다. 이는 조금 이상한 점인데

[16:14] 평가를 시작하기 전에

[16:16] 물어보았다면

[16:19] 반대의 결과를 예상했을 것입니다

[16:21] 충분한 생각 토큰을

[16:22] 제공하도록 설정했고

[16:24] 어떤 방식으로도 제한하지 않았습니다

[16:27] 아마도 커스텀 온도 설정이

[16:29] 변경되어야 할 것 같습니다. 이 부분에 대해

[16:31] 좀 더 연구가 필요합니다

[16:33] 이 모델의 약점은

[16:36] 특히 diff와 루트 코드에서 나타나는데

[16:40] 확실히 증명할 순 없지만

[16:43] 컨텍스트 윈도우가 커질수록

[16:45] 성능이 저하되는 것 같습니다

[16:47] 이는 제가 특히

[16:50] 코드 모드에서 생각 버전을 실행할 때

[16:53] 발생했는데, 컨텍스트 윈도우가

[16:56] 약 10만 토큰에 도달하면

[16:59] diff 에러가 발생하기 시작했습니다

[17:02] 항상 그런 것은 아니었지만

[17:04] 제가 관찰한 결과를 퍼센트로 표현하자면

[17:07] 컨텍스트 윈도우가

[17:09] 커질수록 diff 실패율이

[17:12] 더 높아졌습니다

[17:15] 여기에는 상관관계가 있는 것 같고

[17:18] 이것이 한계점이라고 할 수 있습니다

[17:22] 그리고 제가 생각하기에

[17:25] thinking 모드는 아마도 단순 코드 작성에는

[17:27] 사용하지 않는 것이 좋을 것 같습니다

[17:30] 주니어 모드에도 적합하지 않고

[17:32] 인턴 모드에도 적합하지 않으며

[17:34] 코드 모드에도 적합하지 않습니다

[17:36] 이것은 아키텍트 모드나

[17:38] 혹은 어떤 종류의 계획을 세울 때

[17:41] 가벼운 오케스트레이터 역할로

[17:43] 사용하면 괜찮을 것 같습니다

[17:46] 하지만 그런 용도로도

[17:48] 사용하지 않을 것 같네요. 아직은

[17:51] Rico에서 thinking 모드를 켜는 것이

[17:53] 의미가 있는지 확실하지 않습니다

[17:56] 더 많은 테스트가 필요하고, 실제로

[18:00] 이 모델에 대한 위협을 생각해보면

[18:01] O4 mini가 아마도 가격 대비 가치 면에서

[18:04] 가장 큰 위협일 것 같습니다. O4 mini는

[18:07] 실제로 몇몇 케이스에서 좋은 성능을 보이는데

[18:10] 때로는 Gemini 2.5 Flash보다 좋기도 하고 나쁘기도 합니다

[18:13] 하지만 제가 느끼기에 Gemini 2.5 Flash는

[18:17] 여전히 우위를 가지고 있다고 생각합니다

[18:21] 시간이 지나면서 계속 모니터링해야 하고

[18:24] 더 많은 테스트를 완료해서

[18:25] 전반적인 결과를

[18:27] 확인해봐야 할 것 같습니다

[18:28] 하지만 전체적으로 이 모델에 대해

[18:31] 매우 만족하고 있습니다

[18:34] 다음 주에도 계속 사용하면서

[18:37] 추가적인 발견 사항들을 보고하겠습니다

[18:40] 이것으로 마무리하겠습니다

[18:42] 도움이 되었길 바랍니다

[18:44] 제가 평가를 진행하는 방식에 대해

[18:45] 여러분의 생각을 알려주세요

[18:47] 제가 수행하고 있는

[18:49] 평가 작업에 많은 시간을 투자하고 있는데

[18:51] 실제로 두 개의 평가 프레임워크를

[18:53] 구축하고 있습니다

[18:55] 코딩과

[18:56] LLM이 우리 회사의 도메인인

[19:00] 마케팅 분야에서 어떻게 수행되는지

[19:02] 벤치마킹하기 위해서입니다

[19:05] 이 부분에서 정말 뛰어나지고 싶어서

[19:07] 평가 작업의 깊은 부분까지

[19:10] 파고들었습니다. 평가가 어떻게 작동하는지

[19:11] LLM을 심사관으로 활용하는 방법

[19:15] 필요할 때 인간 중심 평가를 하는 방법

[19:18] 알고리즘적으로 점수를 매기는 방법 등을

[19:20] 연구했습니다. 일관성 있는

[19:22] 좋은 시스템을 만드는 것은 결코 쉽지 않습니다

[19:26] 오늘 보여드린 테스트들은

[19:28] 아직 초기 단계이지만

[19:30] 지금까지 작업한 테스트 실행에서

[19:33] 일관성이 매우 좋았고

[19:35] 특히 처음 두 개의

[19:37] 평가에서는

[19:39] 매우 좋은 결과를 얻었습니다

[19:43] 같은 범위 내에서 계속해서

[19:45] 일관된 점수를 얻었고

[19:47] 극단적인 이상치는 거의 없었습니다

[19:50] 계속해서 이를 개선하고

[19:53] 발전시켜 나갈 예정입니다

[19:54] 아직 우리 Discord에 참여하지 않으셨다면

[19:57] 참여해 주시면 좋겠습니다

[20:00] 주말에 캠핑을 다녀오고

[20:02] 이 모델 작업에 집중하느라

[20:04] 제가 없는 동안 있었던 일들을

[20:07] 따라잡느라 바빴습니다

[20:09] 제가 없는 동안 일어난

[20:11] 모든 일들을 확인해야 합니다. 좋아요 버튼과

[20:13] 구독도 고려해 주시면

[20:15] 정말 감사하겠습니다

[20:17] 다음에 또 만나요, 여러분