Gemini 2.5 Pro와 함께하는 최고의 AI 코딩 어시스턴트…큰 편차

GosuCoder 구독자 9,180명

요약

이 영상은 Gemini 2.5 Pro 위에서 작동하는 다양한 AI 코딩 어시스턴트를 테스트해 각 모델의 지시 이행 능력, 정적 코드 분석, 단위 테스트 통과율 등을 측정한 결과를 보여준다. 테스트마다 큰 편차(variance)가 발생해 중간값(median)을 기준으로 순위를 매겼으며, Zed AI, Cursor, Windsurf가 상위권을 차지했다. 반면 Open Code나 Void는 무한 루프나 오류로 제대로 동작하지 않아 점수가 낮았다. 이를 통해 AI 어시스턴트를 특정 모델에 맞춰 튜닝하는 중요성과 Gemini 2.5 Pro의 대규모 컨텍스트 윈도우가 리팩터링에 강점을 가짐을 확인했다.

주요 키워드

Gemini 2.5 Pro AI 코딩 어시스턴트 Instruction Following Static Code Analysis Unit Test Variance Median Score LLM Judge Prompt Tuning Self-testing

하이라이트

🔑 Gemini 2.5 Pro 테스트는 반복 측정이 불가피할 만큼 결과 편차가 컸으며, 중간값을 기준으로 평가했다.
⚡️ LLM을 판정자로 활용해 지시 이행, 정적 코드 분석, 단위 테스트까지 종합적으로 점수를 매겼고, 판정 편차는 5% 이내로 안정적이었다.
🌟 상위 1위는 Zed AI(14,680점), 2위는 Cursor(12,638점), 3위는 Windsurf(10,700점)로, 모델에 최적화된 에이전트가 높은 성능을 보였다.
📌 IDER는 가격 대비 준수한 점수를 기록했지만 자체 반복 테스트(loop testing)를 수행하지 않아 점수 편차가 컸다.
🚀 Open Code와 Void 2.5 Pro는 무한 루프 혹은 오류 발생으로 테스트를 완료하지 못해 사실상 부적합했다.
⚠️ 일부 에이전트(warp.dev, Klein, Root Code 등)는 스텁 코드만 생성하거나 구현을 생략해 평가가 까다로웠다.
🔍 편차 그래프를 보면 Windsurf는 7,322점에서 14,718점까지 폭넓게 변동해 일관된 성능 보장은 어렵다.
🎯 Gemini 2.5 Pro의 대규모 컨텍스트 윈도우는 큰 리팩터링 작업에 유리했으며, 명확한 요구사항을 제시하면 안정적으로 결과를 뽑아냈다.
💡 에이전트를 특정 모델에 맞춰 튜닝할 때 성능과 비용(토큰 사용량) 사이에서 균형을 잡는 것이 중요하다.

용어 설명

Instruction Following(지시 이행)

프롬프트로 받은 구체적 명령을 얼마나 정확히 수행하는지를 나타내는 능력

Static Code Analysis(정적 코드 분석)

실행 전 소스코드를 검사해 버그나 취약점을 찾아내는 자동 도구 사용 평가

Unit Test(단위 테스트)

코드의 개별 기능이 예상대로 작동하는지 검증하는 테스트 절차

Variance(편차)

동일 프롬프트 반복 실행 시 점수의 최대·최소 차이로, 일관성 정도를 나타냄

Median Score(중앙값 점수)

편차가 큰 경우 평균 대신 반복 측정값을 정렬해 중앙에 위치한 점수를 평가 기준으로 사용

LLM Judge

별도의 거대언어모델(LLM)을 활용해 코드 품질과 테스트 결과를 평가하는 판정자 역할

Prompt Tuning(프롬프트 튜닝)

특정 모델 성능을 최대화하기 위해 명령어 형태나 설명을 최적화하는 과정

Self-testing(자체 테스트)

코드 완성 후 내부에서 반복적으로 단위 테스트를 실행해 결과를 검증하는 자동화 루프

Context Window(컨텍스트 윈도우)

모델이 한 번에 참조할 수 있는 토큰(문맥)의 최대량

테스트 대상은 Gemini 2.5 Pro를 지원하는 AI 코딩 어시스턴트로, 정적 코드 분석과 단위 테스트, LLM 판정자를 활용해 점수를 매긴다. 반복 측정을 통해 점수 편차를 확인하고, 중간값(median)을 기준으로 최종 순위를 정했다. 판정용 LLM으로는 Claw 4 Sonnet을 사용하며, 편차는 대체로 5% 이내로 안정적이다.

[00:00] Gemini 2.5 Pro 테스트가 완료되었으며, 이 모델은 테스트하기 매우 어려워서 반복적인 테스트가 필요했습니다.

[00:20] Gemini 2.5 Pro를 실행할 수 있는 도구들만 테스트했으며, 주로 지시사항 따르기 능력을 평가했습니다.

[00:40] 정적 코드 분석, 단위 테스트, 그리고 Claude 3.5 Sonnet을 판정자로 사용하여 일관성 있는 측정을 수행했습니다.

Rust 기반 웹 서버 코드의 버그 수정을 예시로, 기존 코드베이스를 편집하고 수정된 버전을 생성하는 프롬프트를 소개한다. AI 에이전트에 실제 코드 수정 작업을 맡길 때 설명을 얼마나 상세히 주어야 하는지 시연하며, 지시 이행 능력이 테스트에 미치는 영향을 확인한다.

[01:10] 버그가 있는 Rust 웹 서버를 수정하는 예시를 포함하여 기존 코드베이스 편집 작업을 테스트했습니다.

[01:34] Gemini 2.5 Pro 테스트 결과 Windsurf가 3위를 차지했으며, 점수 편차가 커서 9번 실행 후 중간값을 취했습니다.

3위 Windsurf(10,700점)는 실행마다 점수가 널뛸 만큼 편차가 컸다. 2위 Cursor(12,638점)는 Gemini 2.5 Pro에 특화된 튜닝 덕분에 순위가 올랐고, 1위 Zed AI(14,680점)는 꾸준히 높은 점수를 기록했다. 특히 Windsurf와 Cursor는 모델과의 조합에 따라 사용자 만족도가 크게 달라진다.

[02:01] 2위는 Cursor로 12,638점을 기록했으며, Windsurf와 Cursor 모두 Gemini 2.5 Pro와 작동하도록 에이전트를 잘 조정한 것으로 보입니다.

[02:36] 1위는 Z AI로 14,680점을 기록하여 일관적으로 높은 성과를 보였습니다.

[02:57] Claude 3.5 Sonnet이 이번 달 우승했으며, 최저 16,774점에서 최고 17,140점을 기록했습니다. Gemini 2.5 Pro의 최고 점수도 Claude의 3위 점수보다 낮습니다.

4위 Klein, Root Code는 통계적 오차 범위 내에서 비슷한 성능을 보였고, Kilo Code가 근소하게 뒤처졌다. IDER는 저렴한 가격에 괜찮은 점수를 기록했으나 루프 기반 자체 테스트가 부족해 편차가 컸다. Open Code와 Void 2.5 Pro는 무한 루프나 처리 오류로 테스트를 완료하지 못했다.

[03:16] AI 코딩 어시스턴트들의 성능을 비교한 결과, 루트 코드와 클라이언트는 거의 동일한 성능을 보이는 반면 킬로 코드는 일관되게 약간 뒤처지는 모습을 보였습니다.

[03:29] 최고 성능 에이전트 순위에서 2.5 프로가 1위, 커서 윈드서프가 2위, 클라인이 4위를 차지했으며, 루트 코드 아이더는 예상외로 좋은 성능을 보여주었습니다.

[03:48] 아이더의 문제점은 자체 테스트를 충분히 하지 않고 한 번의 테스트 후 바로 종료한다는 것이었습니다. 제미니 CLI의 점수는 예상보다 낮았지만 시간이 지나면서 개선되기를 기대합니다.

[04:09] 킬로 코드와 GitHub 코파일럿은 비슷한 성능을 보였고, Warp.dev와 Trey는 예상보다 낮은 점수를 받았습니다. 오픈 코드와 Void 2.5 Pro는 루프에 갇히거나 중도 포기하는 문제로 0점을 받았습니다.

[04:43] 실행 간 편차가 매우 심해서 프롬프트 방식, AI 어시스턴트, 또는 모델 자체의 문제인지 판단하기 어려웠습니다. 최고 성능을 보이는 것들이 낮은 편차를 보인 것으로 보아 각 어시스턴트가 특정 모델에 얼마나 잘 조정되었는지가 중요한 것 같습니다.

[05:18] 아이더는 제미니 2.5 프로와 함께 놀라운 성능을 보였습니다. 툴 호출 실패가 전혀 없었고 가격도 매우 저렴했습니다. 하지만 루프 테스팅을 하지 않아서 첫 시도에서 성공하면 좋은 점수, 실패하면 나쁜 점수를 받는 편차를 보였습니다.

[05:52] 편차 그래프를 보면 노란 선이 최고 점수, 파란 선이 실제 도달한 점수, 낮은 선이 최저 점수를 나타냅니다. 오픈 코드의 경우 9,500점대를 기록했지만 완료된 테스트가 충분하지 않아 중간값을 선택할 수 없었습니다.

편차 그래프에서 각 에이전트의 최고·중간·최저 점수를 시각화했다. Windsurf는 7,322점부터 14,718점까지 극단적 변동을 보였고, Cursor도 일부 아웃라이어가 점수 하락을 유발했다. 반면 IDER, Kilo Code, Gemini CLI 등은 상대적으로 안정적인 편차 범위를 유지했다.

[06:17] AI 코딩 도구들의 성능 편차에 대한 분석 결과를 설명하며, Void는 8,000점까지 도달했지만 Trey는 완료되었으나 대부분 제대로 작동하지 않았다고 언급합니다.

[06:29] Warp.dev는 예상보다 낮은 편차를 보였지만 종종 게을러서 작업을 완료하지 않았고, GitHub Copilot은 큰 편차를 보였지만 일관성이 부족했다고 설명합니다.

[06:47] Kilo, Gemini, CLI, IDER, Rode, Klein은 모두 정상적인 편차를 보였지만, Wind surf는 9,500-11,500점 사이의 대부분 결과와 함께 14,718점과 7,322점의 극단적인 결과를 보여 매우 큰 편차를 나타냈습니다.

[07:21] 같은 프롬프트를 반복 사용할 때 이런 큰 편차가 발생하면 사용자는 놀라운 경험과 매우 나쁜 경험을 번갈아 겪을 수 있다고 설명합니다. Cursor는 상대적으로 낮은 편차를 보였지만 한 번의 저조한 결과로 인해 평균이 낮아졌습니다.

[08:07] 가장 좋은 성과를 보인 Windsor는 Gemini 2.5 프로모 모드로 설정되어 자체 테스트를 통해 계속 반복하고 개선하여 높은 점수를 받았으며, 토큰 사용량은 많았지만 다른 에이전트들보다 자체 테스트를 훨씬 잘 수행했다고 분석합니다.

[08:38] Warp.dev는 게을러서 종종 코드를 완전히 구현하지 않고 스텁만 만들어놓았고, Ruk code, Klein, Kilo도 비슷하게 게으른 면을 보였습니다. Trey는 완료하지 못하고 계속 오류만 발생시켰다고 설명합니다.

[09:21] 모델 처리 중 오류가 발생하여 다시 시도하거나 모델을 변경하라는 메시지가 나타났고, Void는 계속해서 반복 실행되는 문제가 발생했습니다.

[09:31] 실제로 이 프로그램을 너무 오래 실행시켰다가 돌아와서 확인했을 때 매우 오랜 시간 실행되고 있었다고 경고합니다.

[09:40] 더 많은 실행에서는 다른 AI 에이전트에서도 유사한 문제가 발생할 수 있지만, Trey와 Void는 Gemini 2.5 Pro에 전혀 최적화되어 있지 않다고 설명합니다.

Gemini 2.5 Pro는 대용량 컨텍스트 윈도우 덕에 큰 리팩터링 작업에 강점을 보이며, 명확한 요구사항 제시 시 안정적으로 결과를 생성한다. 모델·에이전트 조합별 성능 차이가 크므로 프롬프트 튜닝과 비용(토큰 사용량) 최적화가 필수다. 추후 버전 업데이트와 추가 테스트로 편차 원인을 더 분석할 계획이다.

[09:51] Gemini 2.5 Pro를 특히 대규모 리팩토링에서 사랑한다고 말하며, 구체적으로 원하는 것을 알고 있고 페어 프로그래밍 모드를 그룹 코드에서 사용할 때 큰 컨텍스트 윈도우 덕분에 잘 작동한다고 설명합니다.

[10:14] 어제 클라우드 코드에서는 불가능했던 작업을 성공적으로 완료했으며, 이는 필요한 컨텍스트 양 때문이었다고 경험을 공유합니다.

[10:23] 일부 사람들이 2.5 Pro를 좋아하는 이유를 이해한다고 말하며, 일부 에이전트에서는 매우 잘 작동하지만 다른 에이전트에서는 그저 그렇게 작동하기 때문에 대규모 리팩토링이 아닌 경우에는 애매한 입장을 취해왔다고 설명합니다.

[10:39] 이 모델이 테스트하기 가장 어려운 모델 중 하나이며, 다른 모델들과 비교해서 왜 이렇게 많은 변동성이 있는지 평가하려고 노력하고 있다고 말합니다.

[10:48] GPT4.1, Claude 3.7, Claude 4, Deepseek 등은 변동성이 거의 없는 반면, Gemini 2.5 Pro는 모델의 추론 능력이나 AI 코딩 도구와의 상호작용 방식 때문에 높은 변동성을 보인다고 분석합니다.

[11:12] 테스트 결과에 너무 놀라서 여러 번 확인했지만, 이 테스트의 승자들은 주로 Cursor, Windsor, Zed 같은 도구들로 2.5 Pro와 잘 작동하도록 만들어지고 조정되었다고 결론짓습니다.

[00:00] Gemini 2.5 Pro 테스트가 완료되었습니다. 이건

[00:04] 제가 지금까지 만든 영상 중에서

[00:06] 가장 이상한 영상 중 하나가 될 것 같습니다

[00:08] 이 모델이 정말 테스트하기 어렵거든요. 너무나도

[00:12] 어려워서 결국

[00:13] 테스트를 계속 반복하고 또 반복해야 했습니다

[00:16] 이 그래프에서 보여드릴 기준점을 잡기 위해서요

[00:18] 하지만 분산도 보여드릴 예정입니다

[00:20] 물론 Gemini 2.5 Pro를 실행할 수 있는

[00:22] 것들만 테스트했고

[00:24] 주로 지시사항 따르기 능력을 판단하기 위해 테스트했습니다

[00:26] 예를 들어

[00:29] 매우 자세한 프롬프트를 제공하고

[00:31] 특정 작업을 수행하라고 지시했을 때

[00:35] AI 코딩 어시스턴트와 모델이 얼마나 잘

[00:38] 그 작업을 수행하는지 말이죠

[00:40] 정적 코드 분석과 단위 테스트도 실행했습니다

[00:44] 출력물에 대해서요

[00:46] 그리고 LLM을 판정자로 사용했는데

[00:50] 솔직히 이게 측정 과정에서

[00:51] 가장 일관적인 부분 중 하나였습니다

[00:53] 그 LLM 판정자는 매우 자세한 프롬프트로

[00:56] 좋은 예시와 나쁜 예시를 제공받았고

[00:58] 보통 동일한 실행에서의 분산은

[01:01] 5% 미만입니다

[01:04] 이 경우 LLM 판정자는

[01:07] Claude 3.5 Sonnet을 사용하고 있습니다

[01:09] 제가 실행한 프롬프트 예시가 여기 있습니다

[01:11] 이전 영상에서 보여드린 적이 있지만

[01:13] 실제로 버그 수정도 하고 있다는 것을

[01:15] 보여드리고 싶습니다

[01:18] 이것은 최근에 사용을 중단한 것입니다

[01:20] 이것은 버그가 있는 Rust 웹 서버입니다

[01:22] 여기서 일어난 일은 버그를 수정하고

[01:25] 들어가서 버그를 고치고

[01:27] 수정된 버전을 만들어야 했습니다

[01:28] 기존 코드베이스를 편집하는 것들을

[01:30] 조금씩 시작하려고 합니다

[01:32] 이런, 이건 정말 대단할 것 같습니다

[01:34] Gemini 2.5 Pro에서 Windsurf가 3위입니다

[01:38] 이런 결과가 나온 이유에 대해서는

[01:40] 잠시 후에 말씀드리겠지만

[01:41] Windsurf가 저를 놀라게 했습니다

[01:43] 점수 편차도 꽤 많아서

[01:47] 판단하기가 매우 어려웠습니다

[01:49] 실제로 꽤 높은 점수를 받을 때도 있었고

[01:51] 낮은 점수를 받을 때도 있었습니다

[01:52] 하지만 다시 말씀드리지만

[01:54] 여러 번 실행한 후 중간값을 취했습니다

[01:56] 이 경우 Windsurf는 9번 실행했습니다

[01:58] 2위는 Cursor입니다

[02:01] Cursor는 12,638점입니다

[02:06] Windsurf보다 엄청난 점프를 보였습니다

[02:09] 이것은 놀라웠습니다

[02:12] Windsurf와 Cursor가 Gemini 2.5 Pro와

[02:15] 작동하도록 에이전트를 조정하는 데

[02:18] 많은 시간을 투자했을 것 같습니다

[02:21] 예상하지 못했지만

[02:23] 많은 사람들이 Gemini 2.5 Pro를

[02:25] 좋아한다고 말하는 이유를 알 것 같습니다

[02:29] 에이전트가 제대로 가이드하면

[02:32] 훌륭하게 작동할 수 있기 때문입니다

[02:36] 그리고 1위는 저에게 가장 큰 놀라움이었습니다

[02:39] Z AI

[02:41] 14,680점

[02:44] 엄청난 점프입니다

[02:46] 매우 일관적으로 높은 점수를 받았습니다

[02:50] Claude 4 변형만큼 높은 점수는 아니지만

[02:53] Gemini 2.5 Pro로 놀라운 성과를 보였습니다

[02:55] 예상하지 못했던 결과입니다

[02:57] 비교를 위해 말씀드리면

[02:59] 이번 달 Claude 3.5 Sonnet이 우승했습니다

[03:02] 최저 점수는 16,774점

[03:04] 최고 점수는 17,140점이었습니다

[03:08] Gemini 2.5 Pro의 최고 점수는

[03:11] Claude 3.5 Sonnet의 3위 점수보다 낮습니다

[03:14] Kilocode, Rootcode, Client는 어디에 위치할까요? 거의

[03:16] 거의 동일합니다. 다시 말하지만, 루트 코드와

[03:18] 클라이언트는 오차 범위 내의 차이이고

[03:21] 킬로 코드는 그것보다 약간 뒤처져 있습니다.

[03:23] 무슨 이유에서인지

[03:25] 다른 두 개보다 약간 뒤처지는 것 같습니다

[03:27] 제가 하는 모든 테스트에서요.

[03:29] 최고 에이전트들을 보면, 1위를 확인할 수 있습니다.

[03:32] 2.5 프로와 함께 2위라고 했습니다.

[03:34] 2위는 커서 윈드서프이고

[03:36] 클라인이 4위에 있습니다.

[03:38] 루트 코드 아이더는 실제로 막상막하입니다.

[03:42] 솔직히 아이더가 저를 놀라게 했습니다.

[03:45] 실제로 생성할 수 있는 것에 꽤 높은 편차를 보였습니다.

[03:48] 아이더가 가진 문제는

[03:49] 실제로 자기 자신을 그리 많이 테스트하지 않았다는 것입니다.

[03:52] 기본적으로 한 번 테스트하고

[03:55] 채팅에 컨텍스트를 넣고 끝냅니다.

[03:56] 그리고 그곳에서 제 테스트가 멈춥니다.

[03:59] 제미니 CLI는 시간이 지나면서

[04:01] 이 점수들이 실제로 올라가길 희망합니다

[04:03] 왜냐하면 제가 예상했던 것보다 실제로 낮기 때문입니다.

[04:05] 최신 버전을 받기 위해 업데이트했습니다.

[04:07] 여전히 괜찮습니다.

[04:09] 킬로 코드와 GitHub 코파일럿은

[04:12] 모두 상대적으로 비슷합니다.

[04:15] Warp.dev는 제가 예상했던 것보다 낮았고

[04:18] Trey는 제가 예상했던 것보다 훨씬 낮았습니다.

[04:20] 그리고 0점들은 안타깝게도

[04:23] 완료하지 못했습니다.

[04:25] 오픈 코드는 루프에 갇혀서

[04:27] 저에게 많은 돈을 들게 했습니다.

[04:30] Void 2.5 Pro도 루프에 갇히거나

[04:33] 기본적으로 포기하곤 했습니다.

[04:35] 따라서 안타깝게도 이 두 개는

[04:38] 제미니 2.5 프로와 잘 작동하지 않는 것 같습니다

[04:40] 이 녹화 날짜인 2025년 7월 8일 기준으로 말입니다.

[04:43] 실행 간 편차가 너무 심해서

[04:46] 그것이 제가 프롬프트를 사용하는 방식 때문인지

[04:49] AI 코딩 어시스턴트 때문인지

[04:51] 아니면 모델 때문인지 알 수 없었습니다.

[04:54] 하지만 최고 성능을 보이는 것들 중 일부가

[04:57] 실제로 더 낮은 편차를 보였다는 것을 발견했습니다.

[04:59] 편차를 보였습니다.

[05:00] 그래서 저는 이것이 둘 다의 조합이라고 생각하고

[05:02] 각각이 제미니 2.5 프로와 작동하도록

[05:04] 얼마나 잘 조정되었는지의 문제일 것입니다.

[05:07] 이것은 저에게 AI 코딩 어시스턴트들이

[05:09] 특정 모델에 맞춰 조정되는 것이 얼마나 중요한지를

[05:11] 보여주는데, 이는 이런 것들이

[05:13] 모든 것을 포괄하는 원사이즈

[05:15] 에이전트가 되기 매우 어려울 것이라는 것을 의미합니다.

[05:18] 아이더는 솔직히 제미니 2.5 프로와 함께 놀라울 정도로 좋습니다.

[05:21] 툴 호출 실패가 전혀 없었습니다.

[05:23] 실제로 아이더의 가격이 마음에 들었습니다.

[05:28] 비용의 일부분으로 다른 모든 것들만큼 좋은 성과를 보였습니다.

[05:31] 예를 들어, 다른 에이전트들과 함께

[05:34] 약 3달러가 드는 테스트가 있었는데

[05:36] 아이더는 23센트 정도였습니다.

[05:37] 하지만 아이더는 실제로 루프 테스팅을 하지 않았습니다

[05:39] 실제로 모든 것이 충분한지 확인하지 않았습니다.

[05:42] 실제로 점검하고 확인하지 않았습니다.

[05:44] 모든 것이 충분했는지 확인하지 않았습니다.

[05:45] 그래서 첫 시도에서 제대로 했다면

[05:47] 좋은 점수를 받았을 것입니다.

[05:49] 그렇지 않으면 나쁜 점수를 받았을 것이고

[05:51] 이것이 실제로 편차를 만들어냅니다.

[05:52] 여기 편차 그래프가 있습니다.

[05:55] 노란 선은 제가 얻은 최고 점수입니다.

[05:58] 파란 선은 제가 결국 도달한 점수입니다.

[06:01] 낮은 선은 제가 얻은 최저 점수입니다.

[06:03] 예를 들어, 맨 아래에서 시작하면

[06:07] 오픈 코드가 실제로 9,500점대를 기록했지만

[06:09] 완료된 것이 충분하지 않아서

[06:10] 중간값을 선택할 수 없었습니다.

[06:14] 중간값을 선택할 수 없었습니다.

[06:17] 중간값을 선택할 수 있었습니다. Void도 마찬가지로

[06:20] 8,000점까지 도달할 수 있었습니다.

[06:23] Trey는 성공적으로 완료되긴 했지만

[06:26] 대부분 제대로 작동하지 않았습니다.

[06:29] 안타깝게도 말이죠. Warp.dev는 편차가 매우 낮았습니다.

[06:31] 솔직히 제가 예상했던 것보다 낮은 편차였지만

[06:33] 그래도 낮은 편차였습니다. 그리고

[06:35] 많은 경우에, 이것에 대해 좀 더 자세히

[06:36] 이야기하겠습니다. Warp.dev는 그냥 게을러서

[06:38] 실제로 작업을 완료하지 않았습니다.

[06:40] GitHub Copilot은 꽤 큰 편차를 보였습니다.

[06:42] 하지만 그것들은 더 이상값에 가까웠습니다.

[06:46] 일관성이 있는 것은 아니었습니다.

[06:47] Kilo, Gemini, CLI, IDER, Rode, 그리고 Klein.

[06:51] 모두 매우 정상적인 편차를 보였습니다.

[06:54] 꽤 괜찮은 높은 점수와

[06:57] 낮은 점수들이 있었습니다. 그 사이의 격차는

[06:59] 매우 작았습니다. 하지만 Wind surf는 정말 대단했습니다.

[07:01] 제가 실행한 대부분의 결과는

[07:05] 9,500에서 11,500 사이였습니다.

[07:08] 10,700이 제가 선택한 중간값이었습니다.

[07:11] 하지만 한 번의 실행에서는

[07:14] 14,718점을 받았고, 다른 실행에서는

[07:16] 7,322점을 받았습니다.

[07:19] 이것은 테스트하기 매우 어려운 것입니다.

[07:21] 그래서 이 그래프를 보여드리는 것입니다.

[07:23] 같은 프롬프트로 계속 반복했을 때

[07:24] 이런 종류의 편차가 발생하면

[07:27] 여러분은 놀라운 경험을 할 수도 있지만

[07:29] 바로 다음에 사용할 때는

[07:32] 매우 좋지 않은 경험을 할 수 있습니다.

[07:34] 다음에 사용할 때는 매우 매우 나쁜

[07:36] 경험을 할 수 있습니다. Cursor는 조금 더 낮은

[07:38] 편차를 보였고, 솔직히 대부분의

[07:41] 점수가 상대적으로

[07:45] 12,000에서 13,000점 사이였지만, 한 번의 실행에서는

[07:47] 10,322점을 받았습니다.

[07:51] 그래서 결국 낮은 점수에

[07:53] 영향을 미쳤습니다. 꽤 일관성 있게

[07:55] 13,000에서 15,000점 사이였습니다.

[07:58] 대부분 14,500점 범위 주변이었습니다.

[08:01] 아래 댓글에서 이것에 대해 여러분이

[08:05] 어떻게 생각하시는지 정말 궁금합니다.

[08:06] 가장 좋은 성과를 보인 것들을 보면

[08:07] Windsor를 예로 들어보겠습니다.

[08:10] 제가 Gemini 2.5를 프로모 모드로 설정했습니다.

[08:12] 따라서 자체 테스트가 많은 도움이 되었습니다.

[08:14] 왼쪽에서 보시면

[08:16] 실제로 자체 단위 테스트를 시작했고

[08:18] 계속 반복하고 개선했습니다. 그래서

[08:20] 이렇게 좋은 점수를 받을 수 있었습니다.

[08:22] 사용한 토큰 수는 아마도

[08:25] 상당히 많았을 것으로 추정되지만

[08:27] 다른 에이전트들보다 자체 테스트를

[08:29] 훨씬 더 잘 수행했습니다.

[08:31] 일반적으로 그들은 끝까지 가서

[08:33] 자체 테스트를 시도조차 하지 않거나

[08:36] 한 번만 시도하고 끝났습니다.

[08:38] Warp.dev는 그냥 게을렀습니다.

[08:40] 다르게 표현할 방법을 모르겠지만

[08:44] 때로는 그냥 구현을 스텁으로 만들어놓고

[08:46] 실제로 코드를 작성하지 않았습니다.

[08:48] 또는 함수의 스텁만 작성하기도 했는데

[08:51] 이것은 실제로 평가하기 매우 어렵습니다.

[08:53] 네, 함수들은 있지만

[08:54] 그 안에 기능은 없기 때문입니다.

[08:58] 이런 식으로 하는 다른 것들도 있었습니다.

[09:00] Ruk code, Klein, Kilo 모두

[09:01] 어느 정도 게으르기도 했고

[09:04] 때때로 모든 것을 완전히 구현하지 않았습니다.

[09:06] 그 다음에는 완료하지 못한 것들이 있었습니다.

[09:10] Trey는 완료하지 못했고

[09:12] 그냥 이런 오류들만 발생했습니다.

[09:14] 그냥 계속 반복하고 반복하고

[09:16] 모델 처리 중에 오류가 발생했습니다.

[09:20] 그냥 이런 오류들만 받게 됩니다.

[09:21] 모델 처리 중 오류가 발생했습니다.

[09:23] 다시 시도하거나 모델을 변경해 주세요.

[09:25] Void는 계속해서 반복되기만 했습니다.

[09:29] 사실 이걸 너무 오래 실행시켰어요.

[09:31] 솔직히 말하면 다시 돌아와서 봤을 때

[09:33] "이런, 이게 너무 오래 실행되고 있네요."

[09:35] 라고 생각했어요. 그러니까 조심하세요.

[09:37] 그리고 누가 알겠어요, 더 많은 실행에서는

[09:40] 이런 일이 다른 AI 에이전트에서도 일어날 수 있어요.

[09:42] 하지만 제가 말씀드리고 싶은 건, Trey와 Void는

[09:44] Gemini 2.5 Pro에 전혀 최적화되어 있지 않다는 점입니다.

[09:46] 자, 여기서 마지막 생각을 말씀드리겠습니다.

[09:49] 저는 Gemini 2.5 Pro를 정말 좋아해요,

[09:51] 특히 대규모 리팩토링에서요.

[09:55] 구체적으로 무엇을 원하는지 알고 있고

[09:58] 저에게 페어 프로그래밍 모드가 있어서

[10:00] 그룹 코드에서 사용하는데,

[10:03] 제가 원하는 변경사항을 매우 구체적으로 말하면

[10:06] 그리고 컨텍스트 윈도우가 매우 크기 때문에

[10:09] 정말 잘 작동해요.

[10:11] 실제로 어제 한 작업이 있었는데

[10:14] 클라우드 코드에서는 불가능했던 일이었어요.

[10:17] 제가 필요한 컨텍스트의 양 때문에 말이죠.

[10:20] 두 번째 생각은 제가 이해하는 바로는

[10:23] 일부 사람들이 2.5 Pro를 정말 좋아하는 이유는

[10:24] 일부 에이전트에서는 정말 잘 작동하지만

[10:27] 다른 에이전트에서는 그저 그렇게 작동하기 때문이고,

[10:29] 이것이 제가 애매한 입장을 취해온 이유입니다.

[10:32] 저에게는 대규모 리팩토링을 하는 경우가 아니면요.

[10:34] 그리고 이것은 솔직히 제가 테스트하기 가장 어려운 모델 중 하나예요.

[10:36] 그리고 여전히 왜 이렇게 많은 변동성이 있는지

[10:39] 다른 모델들과 비교해서 평가하려고 노력하고 있어요.

[10:41] 예를 들어, GPT4.1, Claude 3.7, Claude 4는

[10:43] 서로 간에 변동성이 거의 없어요.

[10:45] Deepseek도 실행할 때 변동성이 거의 없고요.

[10:48] Gemini 2.5 Pro는 모델의 추론 능력과

[10:51] 관련이 있는 것 같아요.

[10:53] 아마도 이런 모델들이

[10:55] AI 코딩 도구와 상호작용하는 방식과

[10:58] 관련이 있을 수도 있지만,

[11:01] 그 모델에는 뭔가 변동성을 높게 만드는

[11:04] 요소가 있는 것 같아요.

[11:07] 좋아요, 여기서 마무리하겠습니다.

[11:09] 아래에 댓글을 남겨주시고

[11:10] 점수에 대해 어떻게 생각하시는지 알려주세요.

[11:12] 정말 놀라웠어요. 너무 놀라서

[11:13] 두 번, 세 번, 네 번까지 확인해야 했어요.

[11:14] 제가 뭔가 놓친 게 있는지 확인하기 위해서요.

[11:16] 하지만 아니에요, 제게는 분명해요.

[11:18] 이 테스트의 승자들은

[11:20] 주로 Cursor, Windsor, Zed 같은

[11:22] 도구들입니다. 이들은 2.5 Pro와

[11:25] 정말 잘 작동하도록 만들어지고 조정되었어요.

[11:27] 실제로 온도 설정도 조금 가지고 놀아봤는데

[11:31] Gemini 2.5 Pro의 최신 버전에서는

[11:33] 이전 버전만큼 중요하지 않은 것 같았어요.

[11:35] 어쨌든, 여러분의 생각을 알고 싶고

[11:38] 이런 콘텐츠를 위해 좋아요와 구독을

[11:39] 해주신다면 정말 감사하겠습니다.

[11:41] 다음 시간까지, 모든 분들 안녕히 계세요.

[11:43]

[11:46]

[11:47]

[11:49]

[11:50]