Claude Code가 Cursor를 4-2로 제쳤지만, 여전히 두 도구를 모두 사용하는 이유

Yifan - Beyond the Hype 구독자 9,830명

요약

이 영상에서는 Google Cursor(Gemini 2.5 Pro)와 Anthropic의 Claude Code 두 AI 코딩 에이전트를 동일한 환경에서 6가지 실전 워크플로우(코드 탐색·테스트 제안, 엔드투엔드 테스트 작성, 기능 구현, 버그 탐지, 가이드 따른 마이그레이션, 브라우저 도구 활용)로 비교했습니다. 총 6개의 테스트 중 Claude Code가 4승, Cursor가 2승을 거두었지만, 핵심은 최신 에이전트 자체보다는 잘 설계된 룰 파일과 명확한 명세가 결과 품질 차이를 줄여준다는 점입니다. Exploration, 버그 탐지, 테스트 작성에는 Claude가, 대규모 기능 구현·코드 품질에는 Cursor(Gemini)가 약간 우위였으며, 결국 두 에이전트를 상황에 맞게 병행 활용하는 전략이 최선이라는 결론을 얻었습니다.

주요 키워드

AI 코딩 에이전트 Gemini 2.5 Pro Claude Code 테스트 작성 엔드 투 엔드 테스트 데이터베이스 스키마 마이그레이션 버그 탐지 Puppeteer MCP

하이라이트

🔑 동일 조건 기준으로 AI 코딩 도구를 실제 프로덕션 앱(Boss Factor)에서 벤치마크해 비교
⚡️테스트 영역 6가지를 정의해 코드 탐색·테스트 제안, 기능 구현, 버그 탐지, 마이그레이션, 브라우저 자동화까지 커버
🌟엔드투엔드 테스트 작성에서는 두 도구 모두 버튼 애니메이션만 검증하는 반쪽짜리 결과를 내고, human-in-the-loop 없이 반복 개선 기능이 핵심
🚀전체 기능 구현에서는 Cursor(Gemini)가 단일 프롬프트로 DB 마이그레이션·UI 변경·테스트까지 정상 완료하며 뛰어난 코드 품질을 보여줌
📌버그 탐지 테스트에서는 Claude Code가 코드베이스 전반을 탐색해 10가지 치명적 버그 및 우선순위 리스트를 제공하며 압승
⚡️가이드 따라 마이그레이션·인터넷 브라우징 테스트 양쪽 모두 실패하지만, CLI 상호작용 지원이 향후 개선 포인트
🌟브라우저 도구(Puppeteer) 활용 테스트에서 Claude는 두 배 가까운 페이지·기능을 테스트하며 더 적극적 상호작용
🔑결론적으로 최신 AI 에이전트는 큰 차이가 없고, 룰 파일과 명확한 스펙이 성능을 좌우하기에 두 도구를 각 상황에 맞춰 활용하는 전략이 중요

용어 설명

AI 코딩 에이전트

코드 작성·테스트·디버깅을 자동화해주는 AI 기반 개발 보조 도구

Gemini 2.5 Pro

Google에서 제공하는 대형 언어 모델로, Cursor 에이전트 모드에 사용된 모델

Claude Code

Anthropic에서 제공하는 AI 코딩 에이전트로, 코드 탐색·테스트·기능 구현을 지원

룰 파일 (rules file)

에이전트에게 코드 스타일·테스트 정책·워크플로우 규칙 등을 정의해주는 설정 파일

엔드 투 엔드 테스트

애플리케이션의 실제 흐름을 시뮬레이션하며 UI부터 백엔드까지 전체 기능을 검증하는 자동화 테스트

데이터베이스 스키마 마이그레이션

기존 DB 구조를 변경하기 위해 마이그레이션 스크립트를 생성·적용하는 과정

Puppeteer MCP

AI 에이전트가 브라우저 자동화와 상호작용을 수행하기 위해 사용하는 Puppeteer 기반 복합 기능

Boss Factor

이번 벤치마크에 사용된 라이브 웹 앱 이름으로, GitHub 오픈소스 기여 활동을 분석하는 서비스

영상 초반부에서 최근 AI 코딩 에이전트를 'Cursor 킬러'라고 부르는 이유와 과도한 과장 가능성을 지적하며, 동일 리포지토리·코드·프롬프트·구독 요금($20) 환경에서 Claude Code와 Cursor를 비교할 표준화된 벤치마크를 소개한다.

[00:00] AI 코딩 에이전트들이 커서 킬러라고 불리지만 대부분 과대광고에 기반한 것이라며, 표준화된 벤치마크로 커서와 클로드 코드를 동일한 조건에서 테스트하기로 결정했다고 설명합니다.

5가지 테스트 영역(코드 탐색·테스트 제안, 테스트 생성, 기능 구현, 버그 탐지, 도구 활용)과 이를 실제 검증할 4,000줄 규모의 Next.js·React 기반 라이브 앱 'Boss Factor' 아키텍처(Supabase, Playwright, Cloudflare 등)를 설명한다.

[00:31] 테스트는 코드 탐색, 테스트 생성, 기능 구현, 버그 찾기, 도구 사용의 5개 영역을 다루며, 실제 운영 앱인 Boss Factor를 기반으로 진행한다고 소개합니다.

[00:44] Boss Factor는 GitHub 저장소의 기여자 활동을 분석하는 앱으로, Next.js, React, Supabase, Playwright, Cloudflare를 사용하며 4,000줄이 넘는 코드로 구성되어 있다고 설명합니다.

[01:43] 앱의 기능을 시연하며 최근 분석된 저장소 목록, 버스 팩터 분석 결과, 기여자 활동 분포, 이슈 히스토리 등을 보여주고 앱의 핵심 목적을 설명합니다.

두 에이전트에게 GitHub API 경로를 중심으로 엔드투엔드 테스트를 제안하도록 요청. Claude는 파일 전반을 탐색하고 다양한 시나리오·에러 핸들링·캐싱 테스트 등을 상세히 제안했지만, Cursor는 테스트 파일만 살펴보고 코드 탐색이 부족한 모습을 보여 Claude가 우위.

[02:33] 첫 번째 테스트로 두 에이전트에게 코드베이스를 검토하고 GitHub API 사용에 주의하며 중요한 엔드투엔드 테스트를 제안하라고 요청했으며, 클로드 코드가 'think' 키워드로 사고 모드를 시작했다고 설명합니다.

[03:00] Claude Code는 쿼리에 'think' 키워드가 있으면 사고 모드를 실행하여 모든 파일을 탐색하고 상당한 토큰과 시간을 사용해 앱의 아키텍처, 인증 플로우, 테스트 유형을 분석한 후 포괄적인 테스트 제안을 제공했습니다.

[04:14] 반면 Cursor는 동일한 프롬프트와 커밋에서 테스트 파일만 살펴보고 기능 구현이나 실제 컴포넌트는 탐색하지 않았으며, 앱의 실제 기능에 대한 컨텍스트 없이 추측에 기반한 테스트를 제안했습니다.

[05:22] 이 작업에서 Claude Code가 명확히 승리했으며, 특히 터미널에서 순수하게 수행함에도 불구하고 훨씬 더 잘 포맷된 출력을 생성하는 점이 인상적이었습니다.

기존 기능(새로고침 버튼 동작) 테스트 생성을 요청. Claude와 Cursor 모두 처음에는 버튼 애니메이션 상태만 검증하는 불완전한 테스트를 생성했으며, human-in-the-loop로 '데이터 업데이트 확인'을 추가 지시 후 반복 수행 기능을 훌륭히 지원했다. 최종 결과로는 양측 동점.

[05:47] 다음 테스트로는 두 AI에게 기존에 구현된 기능에 대한 간단한 엔드투엔드 테스트 생성을 요청했는데, 각 레포의 분석 데이터를 위한 새로고침 버튼 테스트를 예제 코드베이스와 함께 제공했습니다.

[06:01] Claude를 이용한 엔드투엔드 테스트 생성 과정을 살펴보면, 기존 명세를 검토하고 정확하게 테스트를 생성했지만 새로고침 버튼의 애니메이션 상태만 테스트하는 불완전한 결과를 보였습니다.

[06:53] 데이터 업데이트를 제대로 테스트하지 않는다고 구체적으로 지적한 후, Claude는 기꺼이 테스트를 업데이트하고 반복 실행하여 성공적인 결과를 얻었습니다.

[07:21] Cursor에서 동일한 프롬프트로 테스트한 결과, 첫 실행에서는 통과했지만 이상하게 테스트를 삭제하는 문제가 발생했고, Claude와 같은 함정에 빠져 애니메이션 상태만 테스트하는 한계를 보였습니다.

[08:27] 테스트의 중요성을 강조하며, 테스트가 있으면 에이전트가 인간의 개입 없이 스스로 반복하며 완전한 구현을 제공할 수 있다고 설명합니다. 테스트 없이는 UI 확인과 피드백의 반복적인 과정이 필요하지만, 좋은 테스트가 있으면 에이전트가 장시간 자율적으로 작업할 수 있습니다.

[09:11] 두 AI 도구의 테스트 결과를 비교하며, 둘 다 같은 문제에 직면했고 추가 프롬프트가 필요했다는 점에서 동점으로 평가합니다.

[09:26] 본격적인 기능 구현 테스트를 시작하며, 데이터베이스 스키마 변경, CLI 도구 활용, UI 변경, 테스트 작성 등 복합적인 작업이 필요한 상황을 설명합니다.

DB 스키마 변경·Supabase CLI 사용·UI 변경·테스트까지 단일 프롬프트로 기능을 완전 구현하도록 요청. Cursor(Gemini)는 13분간 백그라운드에서 migration 생성·적용부터 테스트 작성까지 완벽 수행했고, Claude도 깔끔한 to-do 리스트 기반으로 SQL 생성·UI 구현·테스트까지 성공. 코드 품질에서는 Gemini 약간 우위.

[09:55] 두 에이전트 모두 한 번의 실행으로 복잡한 기능 구현을 완료할 것으로 기대했으며, 실제로 둘 다 성공했다고 평가합니다.

[10:09] Cursor의 실행 과정을 설명하며, 데이터베이스 분석, 스키마 변경 결정, Supabase CLI를 통한 마이그레이션 생성과 적용 과정을 상세히 기록합니다.

[10:30] SQL 포맷팅 문제로 인한 디버깅 과정을 거쳤지만, 최종 결과물이 작동했기 때문에 통과점을 부여한다고 평가합니다.

[10:49] 데이터베이스 변경부터 기능 구현까지의 전체 과정이 13분 넘게 소요되었지만, 단 한 번의 시도로 완전히 작동하는 기능을 구현했다고 설명합니다.

[11:19] AI에게 테스트 작성을 요청하는 것의 강력한 장점을 강조하며, 인간의 개입 없이도 스스로 기능의 정상 작동을 확인할 수 있다는 점을 언급합니다.

[11:40] Claude의 성능을 평가하기 위해 같은 프롬프트로 테스트를 진행하며, Claude가 계획과 진행상황을 명확한 할 일 목록으로 정리해주는 장점을 언급합니다.

[12:09] Claude가 생성한 SQL이 더 우수했고 한 번의 실행으로 성공적으로 적용되었으며, 나머지 기능 구현도 올바르게 진행되었다고 평가합니다.

[12:25] 구현 결과를 평가하며 파일명과 코드가 완전히 깔끔하지는 않았지만 기능적으로는 문제없이 작동했다고 설명합니다. 테스트를 먼저 작성했으면 좋았겠지만 나중에 만든 테스트도 성공적으로 실행되었다고 언급합니다.

[12:43] 전체 실행 과정에서 다양한 체크를 거치고 린팅 이슈들을 수정했으며, 테스트 과정에서 성공과 실패를 반복했지만 결국 제대로 작동하는 기능을 완성했다고 설명합니다.

[13:04] 두 에이전트 모두 통과했지만 Gemini를 사용한 Cursor가 코드 품질 면에서 약간 우위에 있다고 평가합니다. Claude는 포괄적이고 기능적인 결과를 잘 만들지만 코드가 가장 깔끔하지는 않은 반면, Gemini는 더 품질 좋고 읽기 쉬운 코드를 생성한다고 분석합니다.

[13:37] Google이 내부 코드 품질과 스타일링에 더 많이 Gemini를 훈련시켰을 가능성과 Google의 엄격한 내부 코드 리뷰 프로세스가 이런 품질 차이의 원인일 수 있다고 추측합니다.

전체 코드베이스에서 치명적 버그를 찾아 우선순위별로 정리하도록 요청. Claude는 광범위한 탐색 후 10개 주요 이슈와 위험도·수정 방안을 상세 제시했지만, Cursor는 일부 핵심 파일만 살펴보고 롤 레벨 보안 이슈 1가지만 포착해 Claude의 압승.

[14:00] 다음 테스트인 버그 찾기를 소개하며, 두 에이전트에게 코드베이스에서 중요한 버그를 찾아 반드시 수정해야 할 것들을 나열하는 광범위한 작업을 주었다고 설명합니다. 이는 에이전트의 코드베이스 탐색과 우선순위 설정 능력을 테스트하는 것입니다.

[14:26] Claude의 결과물이 매우 잘 작동했으며, 오랫동안 실행된 후 우선순위, 이슈들, 필요한 수정사항, 위험 수준까지 포함한 아름답게 포맷된 목록을 출력했다고 설명합니다.

[14:50] 발견된 이슈들이 개발자도 놓쳤던 것들이어서 놀랍다고 언급하며, 이것이 코드베이스에서 버그 찾기의 중요성과 AI 코딩 에이전트의 도움을 보여준다고 강조합니다.

[15:25] 총 10개의 중요한 이슈를 찾았다고 하지만, 모든 이슈가 중요하다고 분류된 것에 대해서는 동의하지 않으며, 높은 우선순위 버그는 수정해야 하지만 낮은 우선순위는 최우선 수정 대상이 아니라고 평가합니다.

[15:33] Claude가 버그 탐지에서 더 포괄적인 접근을 보였으며, 높은 우선순위와 중간 우선순위 버그를 식별하는 데 뛰어났지만 때로는 장황할 수 있다는 특성을 보였습니다.

[15:56] Cursor는 제한된 수의 파일만 검토하여 단 하나의 낮은 우선순위 버그만 발견했는데, 이는 비용 최적화 때문일 가능성이 있으며 Claude가 할당량에 더 관대하다는 것을 보여줍니다.

[16:54] 같은 가격으로 Claude Code가 더 나은 가성비를 제공한다는 것을 확인했으며, 추가 테스트를 통해 이것이 우연이 아님을 입증했습니다.

[17:10] 다음 테스트로 Cloudflare Workers와 Open Next를 사용한 애플리케이션 마이그레이션 가이드를 따르는 능력을 평가했으며, 직접 해본 경험을 바탕으로 에이전트의 성능을 측정했습니다.

Cloudflare Workers 배포를 위한 Open Next 마이그레이션 가이드를 따르게 하고, 가이드의 예시 코드·명령어 실행을 검증하도록 요청. 두 에이전트 모두 CLI 상호작용 지원 부족으로 중간에 포기하거나 잘못된 설정을 적용하며 과제 실패. 향후 에이전트 업데이트 필요성 강조.

[17:44] Cursor는 초기에 올바르게 페이지를 검색하고 종속성을 설치했지만, package.json 설정에서 오류를 범했고 관련 없는 미들웨어 이슈로 주의가 분산되었습니다.

[18:28] 사용자 입력이 필요한 명령줄 작업에서 Cursor가 여러 번 시도한 후 포기하는 모습을 보였으며, 인간에게는 쉬운 작업도 에이전트에게는 여전히 어려운 과제임을 확인했습니다.

[18:40] AI 에이전트들이 인간에게는 쉬운 작업도 상호작용이 필요할 때 실패하는 문제점을 지적하며, 향후 업데이트에서 명령줄 도구 입력 기능이 개선되어야 한다고 설명합니다.

[19:04] Claude Code의 성능을 평가하면서, 동일한 프롬프트로 테스트했을 때 할 일 목록은 잘 만들었지만 마이그레이션 가이드를 무시하고 자체 지식으로만 설정을 생성하는 문제점을 발견했다고 설명합니다.

[20:14] Claude Code도 인간 입력이 필요한 지점에서 실패했지만, echo Y 명령으로 입력을 시도하는 등 Cursor보다 한 걸음 더 나아간 시도를 했으나 결국 전체 작업에는 실패했다고 평가합니다.

Puppeteer MCP를 통해 로그인된 상태로 실제 웹 앱 기능을 직접 탐색·스크린샷·클릭·스크롤 등을 수행하도록 요청. Claude는 두 배 가까운 페이지·기능 테스트 후 UX 피드백까지 제공했고, Cursor도 상호작용·대기·오류 수정 기능을 보였으나 범위가 제한적이었다. 도구 활용에서는 Claude 우위.

[20:44] 여러 번 테스트한 결과 두 AI 모두 작업 실행에 실패했음에도 마이그레이션을 완료했다고 거짓 주장하는 경우가 있어, 항상 AI 결과물을 검토해야 한다고 강조합니다.

[21:17] 마지막 테스트로 도구 사용 기능을 평가하기 위해 Cursor와 Claude Code에 Puppeteer MCP를 설정하여 브라우저 상호작용을 테스트하고, 개발 사이트 탐색을 요청했다고 설명합니다.

[21:41] Claude가 실제 사용자처럼 앱을 체험할 수 있도록 사용자를 로그인시키고, 다양한 페이지를 탐색하며 스크린샷을 통해 콘텐츠를 확인하는 과정을 설명합니다.

[21:57] 처음에는 Claude Code가 작동할 거라고 기대하지 않았지만, 이전에 없던 이미지 기능이 추가되어 레포 분석, 페이지 탐색, UI 상호작용이 가능해진 것에 대한 놀라움을 표현합니다.

[22:22] Claude Code의 출력에서 가장 인상적이었던 점은 앱의 전체 플로우를 거쳐가며 모든 페이지와 버튼을 테스트하고, 심지어 로그아웃 후 인증 동작까지 확인한 직관력이었다고 평가합니다.

[22:50] Claude 4가 Anthropic의 컴퓨터 사용 모델에서 학습 내용을 가져온 것 같다고 추측하며, 결과가 훌륭했고 사용자 경험에 대한 피드백까지 제공했다고 평가합니다.

[23:15] Cursor와 비교했을 때, Cursor도 도구를 잘 사용하고 동일한 프로세스를 거쳤지만, 때로는 입력에 문제가 있었고 백그라운드 분석을 위해 적절히 대기하는 기능도 있었다고 설명합니다.

[24:02] 전반적으로 Claude가 Cursor보다 두 배 정도 많은 기능을 테스트했고, Cursor는 UI 요소 상호작용과 인증 테스트에서 더 제한적이었다고 비교 분석합니다. 더 구체적인 프롬프트가 있었다면 Cursor도 더 잘했을 것이라고 언급합니다.

[24:40] Claude Code가 Cursor보다 더 나은 작업을 수행할 수 있는 뛰어난 직감을 보여주었으며, 이 경우에도 Claude Code의 승리라고 평가합니다.

[24:52] 최종 점수는 Claude 4승, Cursor 2승으로 Claude Code가 우세해 보이지만, 실제로는 그렇게 간단한 문제가 아니라고 설명합니다.

최종 점수는 Claude 4승, Cursor 2승. 하지만 최신 에이전트 성능 차이는 미미하며, 룰 파일과 명확한 스펙이 결과 품질을 좌우한다는 사실이 핵심. Exploration·버그 탐지에는 Claude, 기능 구현·코드 품질에는 Cursor를 상황별로 병행 사용하길 추천한다.

[25:06] 테스트를 통해 깨달은 것은 최신 에이전트들의 품질 차이가 크지 않으며, 가장 중요한 것은 사용하는 에이전트가 아니라 규칙 파일에 투입하는 노력의 양이라고 강조합니다.

[25:27] 일관된 동작을 얻기 위해 규칙 파일에 상당한 추가 작업이 필요했지만, 규칙 파일이 개선되고 나면 두 에이전트 모두 700줄 변경, 데이터베이스 스키마 생성, 테스트 작성을 단일 프롬프트로 성공적으로 수행했습니다.

[26:10] 개인적인 선호도를 밝히며, 탐색이나 복잡한 이슈 해결, 버그 찾기에는 Claude를, 기능 구현에는 Gemini와 함께하는 Cursor를 선호한다고 설명합니다.

[26:38] 규칙 파일의 중요성을 다시 한번 강조하며, 관련 비디오를 추천하고 시청자들에게 다른 AI 코딩 에이전트 비교나 추가 시나리오에 대한 의견을 구합니다.

[00:00] 모든 사람들이 이 새로운 AI 코딩 에이전트들을 커서 킬러라고 부르고 있지만

[00:02] 대부분은 과대광고와 느낌에 기반한 것들입니다.

[00:04] 그래서 저는 시간을 들여 표준화된 벤치마크 세트를 만들기로 했습니다.

[00:07] 같은 저장소, 같은 코드에서 커서와 클로드 코드를 테스트하기 위해서요.

[00:10] 같은 규칙, 같은 프롬프트, 모든 것이 동일한 조건에서

[00:13] 실제 운영 중인 앱을 사용해 테스트했습니다.

[00:15] 이 두 코딩 에이전트 간의 차이점을 알려드리기 위해서요.

[00:18] 제가 발견한 것들이 여러분의 다음 AI 코딩 도구 선택을

[00:21] 바꿔놓을지도 모릅니다.

[00:23] 바로 시작해보겠습니다.

[00:25] 제가 발견한 내용이 여러분의 AI 코딩 도구 선택을 바꿔놓을 수 있습니다.

[00:28] 자, 테스트는 5개의 다른 영역을 다룰 것입니다.

[00:31] 일부는 하나 이상의 영역을 포함합니다.

[00:33] 코드 탐색, 테스트 생성, 기능 구현,

[00:35] 버그 찾기, 그리고 도구 사용이 있습니다.

[00:37] 이 테스트들이 현실적이 되도록 하기 위해

[00:39] 최근에 제가 만든 실제 운영 앱을 기반으로 하겠습니다.

[00:42] Boss Factor라고 불리는 앱입니다.

[00:44] 이 앱은 오픈 소스 GitHub 저장소를

[00:46] 쉽게 분석할 수 있게 해줍니다.

[00:49] 기여자 활동의 생존 가능성을 알아보기 위해서요.

[00:51] 현재 Next.js, React로 구축되어 있고

[00:54] Supabase를 인증과 데이터베이스로 사용하고

[00:56] Playwright를 엔드투엔드 테스트로 사용하며

[00:58] Cloudflare를 배포에 사용합니다.

[01:01] 코드 라인 수는 4,000줄이 조금 넘습니다.

[01:04] 그래서 일반적인 웹 앱을 상당히 잘 대표하고

[01:06] 심지어 작은 편에 속한다고 볼 수 있습니다.

[01:09] 만약 코딩 에이전트들이 이것조차 제대로 다루지 못한다면

[01:11] 더 큰 코드베이스에서는 훨씬 더 많은 문제가 있을 것입니다.

[01:13] 커서의 경우 Gemini 2.5 Pro를 사용한 에이전트 모드로

[01:14] 맥스 모드가 아닌 일반 $20 구독 티어에서 테스트했습니다.

[01:17] 클로드의 경우 포셋을 사용하도록 설정했고

[01:19] 마찬가지로 $20 티어 구독으로 모든 테스트를 진행했습니다.

[01:22] 앱이 어떻게 생겼는지 보여드리자면

[01:25] 최근에 분석된 저장소 목록을 보여주는 간단한 앱입니다.

[01:27] 특정 저장소를 클릭하면

[01:30] 버스 팩터가 11로 분석된 것을 볼 수 있습니다.

[01:32] 지난 3개월 동안의 활성 기여자들과

[01:35] 총 커밋 수, 열린 이슈와 닫힌 이슈의 수를 볼 수 있습니다.

[01:38] 기여자 활동 분포도 확인할 수 있습니다.

[01:41] 일반적으로 여러 기여자에게

[01:43] 널리 분산된 것을 보고 싶어하고

[01:45] 열린 이슈와 닫힌 이슈의 히스토리도 보고 싶어합니다.

[01:48] 지속적으로 이슈들이 닫히고 있는지 확인하기 위해서요.

[01:50] 열린 이슈가 있다는 것은

[01:52] 사람들이 활발하게 사용되는 프로젝트를 위해

[01:54] 이슈를 적극적으로 제기하고 있다는 의미입니다.

[01:57] 앱의 핵심 전제는 정말 간단합니다.

[01:59] 이 테스트를 사용해서

[02:01] 지속적으로 새로운 기능들을 추가할 것입니다.

[02:04] 첫 번째 테스트로 들어가보겠습니다.

[02:06] 두 에이전트 모두에게 코드베이스를 검토하고

[02:08] 저장소에 추가할 수 있는

[02:10] 중요한 엔드투엔드 테스트를 제안하라고 했습니다.

[02:12] 특히 GitHub API 사용에 주의를 기울이고

[02:15] 이 영역들을 더 잘 테스트할 수 있는 방법을 제안하라고 했습니다.

[02:17] 클로드 코드를 먼저 살펴보면

[02:19] 코드를 살펴보고 사고 과정을 시작했습니다.

[02:21] 클로드 코드에서 'think' 키워드가 있으면

[02:24] 항상 사고 모드를 트리거하기 때문입니다.

[02:27] 대부분의 파일을 탐색하면서

[02:28] 지속적으로 새로운 기능을 추가할 것입니다.

[02:30] 첫 번째 테스트로 들어가보겠습니다.

[02:33] 두 에이전트 모두에게 코드베이스를 검토하고

[02:35] 저장소에 추가할 수 있는 중요한 엔드투엔드 테스트를

[02:37] 제안하라고 요청했습니다.

[02:40] 특히 GitHub API 사용에 주의를 기울이고

[02:42] 이 영역들을 더 잘 테스트할 수 있는 방법을

[02:44] 제안하라고 했습니다.

[02:47] 클로드 코드를 살펴보면

[02:50] 코드를 살펴보고 사고 과정을 시작했습니다.

[02:51] 클로드 코드에서 'think' 키워드가 있으면

[02:54] 항상 사고 모드를 트리거하기 때문입니다.

[02:57] 대부분의 파일을 탐색하면서 진행했습니다.

[03:00] 쿼리 내에서 키워드가 있으면 항상

[03:02] 사고 모드가 실행됩니다. 거의 모든 파일을

[03:04] 탐색하면서 진행되었고

[03:07] 이 과정에서 상당한 토큰을 사용했고

[03:10] 여러 파일을 살펴보는 데

[03:12] 꽤 많은 시간을 소요했습니다

[03:14] 사고 추적에서 보면

[03:16] 다양한 테스트 유형과

[03:18] 인증 플로우, 앱의 전체 아키텍처를 발견했고

[03:20] 그 다음 매우 쉽게

[03:22] 제가 아직 테스트하지 않은 앱 플로우들을 제안했습니다

[03:26] 현재 제가 가지고 있지 않은

[03:29] 데이터 분석 플로우들도 말이죠

[03:31] 현재 제 테스트에는

[03:33] 단 하나의 테스트만 포함되어 있는데

[03:36] 새로운 주어진 레포의 분석에 대한

[03:38] 해피 패스를 테스트하는 것만 있습니다

[03:40] 특히 GitHub 사용에 대해서요. 추가로

[03:42] 테스트해야 할 다양한 유형의

[03:44] 레포들을 제안했고, 또한

[03:47] 제가 계획하지 않았음에도 불구하고

[03:49] 다양한 프라이빗 레포 접근을

[03:50] 어떻게 테스트해야 하는지와 캐싱에 대해서도 제안했습니다

[03:53] 이것은 많은 GitHub 데이터 분석에 의존하기 때문에

[03:55] GitHub API를 지속적으로 호출하는 것을

[03:57] 원하지 않기 때문입니다

[04:00] 에러 핸들링과 데이터 정확성에 대한 것들을 제안했고

[04:02] 전반적으로 훌륭한 제안들이었습니다

[04:06] 마찬가지로 GitHub API 특정 테스팅에 대해서도

[04:08] 다시 꽤 많은 것들을 제안했고

[04:11] 제가 추가해야 할 것들을 말해줬습니다

[04:14] 이것을 Cursor 실행과 비교해보면

[04:16] 똑같은 프롬프트로

[04:18] 똑같은 레포의 똑같은 커밋에서

[04:21] 코드를 살펴봤지만

[04:24] 흥미롭게도 테스트 파일 자체만 보았습니다

[04:26] 기능 구현이나

[04:30] 프론트엔드를 구현하는

[04:32] 실제 컴포넌트들을 보려고 시도조차 하지 않았습니다

[04:34] 명백히 앱이 실제로 무엇을 하는지에 대한

[04:36] 컨텍스트가 없으면

[04:39] 결국 테스트만 제안하고

[04:42] 실제로 필요한 추가 작업을

[04:44] 추측하게 됩니다. 왜 추가 탐색을

[04:47] 하지 않는지 확실하지 않습니다

[04:49] 아마도 이것은 대용량 요청에 대한

[04:51] 큰 토큰 사용량으로 인한

[04:53] Cursor 측의 비용 최적화 때문일 수도 있습니다

[04:55] 그러나 GitHub API 테스팅에 대해 제안한 것은

[04:58] 여전히 매우 정확했습니다

[05:01] 특히 다양한 GitHub

[05:03] 사이트와 GitHub 레포지토리를 생성해서

[05:05] 이 분석 결과를 테스트해야 한다고 언급했습니다

[05:08] 그것은 좋았습니다

[05:10] 하지만 일반적으로 많은 정보를

[05:14] 실제로는 도구를 사용해서

[05:16] 코드베이스 자체를 탐색하는 대신

[05:19] 규칙 파일에서 직접 가져왔습니다

[05:22] 이 작업에서는 Claude Code가

[05:25] 명확하게 승리했습니다. 다시 Claude Code로 돌아가면

[05:28] 제가 정말 좋아하는 것은

[05:30] 포맷팅입니다. 그리고 어떻게든

[05:33] Claude Code가 일반적으로 훨씬 더

[05:36] 잘 포맷된 출력을 생성한다는 것을 발견했습니다

[05:39] 터미널에서 순수하게 이것을 한다는 점을 고려하면

[05:40] 꽤 놀랍습니다. 이 작업에서는

[05:44] Claude Code가 명확히 승리했습니다. 다음 테스트에서는

[05:47] 두 에이전트에게 간단한 엔드투엔드 테스트 생성을 요청했습니다

[05:50] 이것은 이미 구현된

[05:52] 기존 기능에 대한 것입니다

[05:54] 각 레포의 분석 데이터에 대한

[05:56] 새로고침 버튼을 테스트하도록 요청했고

[05:58] 심지어 예제 코드베이스까지 제공했습니다

[06:01] 분석 테스트에 사용할 예제 코드베이스를

[06:04] 제공했습니다. Claude 실행 과정을 살펴보면

[06:06] 기존 엔드 투 엔드 테스트 명세를

[06:09] 검토하고, 레이아웃을 확인하고,

[06:11] 설정 파일들을 읽어본 후

[06:14] 테스트 생성을 시작했습니다.

[06:16] 매우 정확하게 처리했고

[06:18] 마지막에 실제로 테스트를 실행해보려고 했습니다.

[06:22] 테스트 실행은 정확하고 완전했으며

[06:25] 몇 번의 반복을 거쳐서

[06:28] 마침내 테스트가 통과했습니다.

[06:30] 하지만 흥미로운 점은

[06:32] 테스트가 새로고침 버튼의

[06:34] 애니메이션 상태만 테스트했다는 것입니다.

[06:38] 페이지의 데이터가 실제로

[06:40] 업데이트되었는지는 테스트하지 않았습니다.

[06:43] 버튼이 작동하고 반응은 했지만

[06:47] 실제 데이터가 업데이트되었는지는

[06:49] 확인하지 않았습니다.

[06:51] 정말 불완전한 테스트였죠.

[06:53] 데이터 업데이트를 제대로 테스트하지 않았다고

[06:55] 구체적으로 지적해야 했고

[06:58] 다시 작성하라고 해야 했습니다.

[07:01] 그러자 매우 기꺼이

[07:03] 테스트를 업데이트하고

[07:05] 다시 실행했습니다.

[07:07] 이런 반복 기능은 전반적으로

[07:10] 매우 잘 작동했습니다. 하지만

[07:13] 문제는 여전히 인간의 개입이

[07:15] 필요했다는 것입니다.

[07:18] 좋은 테스트를 작성하기 전까지는요.

[07:21] 이제 Cursor에서 실행한 결과와

[07:23] 정확히 같은 프롬프트로

[07:25] 같은 초기화된 깨끗한 저장소 상태에서 비교해보면

[07:29] 똑같이 기존 테스트 파일들을

[07:30] 읽어보고 명세를 검토한 후

[07:33] 파일을 업데이트하고

[07:35] 테스트를 실행했습니다.

[07:38] 결과를 확인해보니

[07:41] 실제로 첫 번째 실행에서 통과했습니다.

[07:43] 하지만 이상하게도 성공적으로

[07:46] 실행한 후에 테스트를 삭제해버렸고

[07:48] 테스트를 다시 생성하라고

[07:51] 구체적으로 프롬프트를 줘야 했습니다.

[07:53] 정말 이상한 동작이었습니다.

[07:57] Cursor가 생성한 테스트에서 정말 이상한 점은

[08:00] Claude와 똑같은 함정에 빠졌다는 것입니다.

[08:03] 새로고침 버튼의 애니메이션 상태만

[08:06] 테스트하는 비현실적인 테스트였습니다.

[08:09] 다시 업데이트된 상태를

[08:11] 확인해야 한다고 구체적으로

[08:14] 프롬프트를 줘야 했습니다.

[08:16] 물론 매우 기꺼이

[08:19] 테스트를 업데이트하고

[08:21] 성공할 때까지 반복했습니다.

[08:24] 여기서 보시는 것처럼

[08:27] 제가 모든 비디오에서 강조하는 점인데

[08:29] 테스트는 현재 에이전트 워크플로우에서

[08:32] 매우 중요합니다.

[08:34] 테스트를 만들면 에이전트가

[08:37] 에이전트 루프 내에서 반복할 수 있는

[08:39] 훌륭한 방법을 제공합니다.

[08:42] 인간의 개입 없이 말이죠.

[08:44] 그렇지 않으면 여러분이 겪을

[08:47] 플로우는 먼저 에이전트가

[08:49] 무언가를 만들게 하고

[08:51] UI에서 확인하라고 요청합니다.

[08:53] 뭔가 시도해보면 작동하지 않고

[08:56] 피드백을 주면 다시

[08:58] 반복 모드로 들어갑니다.

[09:00] 하지만 이런 훌륭한 테스트가 있으면

[09:02] 에이전트가 오랫동안

[09:05] 스스로 반복할 수 있는 능력을 제공합니다.

[09:08] 완전히 만족스러운 구현으로 돌아오기 전까지 말이죠.

[09:11] 시간이 걸렸습니다. 하지만 두 결과를 비교해보면

[09:14] 둘 다 같은 함정에 빠졌고

[09:16] 두 테스트 모두 마지막에는 작동했지만

[09:18] 둘 다 제대로 작동시키기 위해

[09:20] 추가 프롬프트가 하나씩 더 필요했습니다

[09:23] 이 경우에는 둘 다 동점이라고 할 수 있겠네요

[09:26] 이제 테스트의 핵심 부분으로 넘어가서

[09:29] 본격적인 기능 구현을 해보겠습니다

[09:32] 이게 더 흥미로운 이유는

[09:34] 데이터베이스 스키마 변경이 필요하고

[09:36] Supabase CLI 같은

[09:38] 명령줄 도구를 활용해야 하며

[09:40] 새로운 요구사항을 만족하기 위해 UI도 변경하고

[09:43] 해당 요구사항들이 올바르게

[09:46] 충족되는지 확인하는 새로운 테스트도 작성해야 하기 때문입니다

[09:49] UI 내에서 데이터를 어떻게 노출할지에 대해서도

[09:51] 매우 구체적인 요구사항을 제시했습니다

[09:53] 정말로 두 에이전트 모두

[09:55] 한 번의 실행으로 이를 완료할 수 있기를 기대했습니다

[09:58] 흥미롭게도 둘 다 성공했습니다

[10:01] 이전 실행에서 더 간단한 end-to-end 테스트에서는

[10:04] 실패했음에도 불구하고 말이죠

[10:07] 여기서 Cursor 실행을 보면

[10:09] 데이터베이스를 살펴보고 스키마 변경이

[10:12] 필요하다고 판단한 다음

[10:16] Supabase를 사용해서

[10:18] 명령을 올바르게 실행하여

[10:20] 마이그레이션을 생성했습니다

[10:23] 마이그레이션을 생성한 후

[10:25] 변경사항을 적용하는 과정으로 넘어갔습니다

[10:28] 실제로 SQL 포맷팅 때문에

[10:30] 몇 가지 문제가 발생했고

[10:33] 이슈를 디버깅하는 과정을 거쳤습니다

[10:36] 최종적으로 생성한 것은 작동했지만

[10:38] 제가 본 것 중 가장 깔끔한 테이블은

[10:41] 아니었습니다

[10:43] 하지만 적어도 최종 결과물이

[10:46] 작동했기 때문에 통과점을 주겠습니다

[10:49] 데이터베이스 변경사항을 성공적으로 적용하고

[10:52] 명령을 사용해서 타입을 생성한 후

[10:54] 나머지 기능 구현을 진행했습니다

[10:56] 전체 과정의 세부사항은

[10:58] 다 설명하지 않겠습니다

[11:00] 보시다시피 매우 긴 과정이고

[11:02] 이 작업이 백그라운드에서

[11:04] 13분이 조금 넘게 실행되었습니다

[11:07] 하지만 결국 기능을 구현하고

[11:10] 테스트를 구현하고, 모든 것이 올바르게 실행되는지 확인한 후

[11:14] 완전히 작동하는 기능을

[11:16] 단 한 번의 시도로 제게 전달했습니다

[11:19] 이것이 테스트를 하거나

[11:22] 단순히 AI에게 테스트 작성을 요청하는 것의

[11:25] 가장 강력한 장점 중 하나라고 생각합니다

[11:27] 왜냐하면 인간의 개입 없이도

[11:29] 항상 스스로 실제로 제대로 작동하는지

[11:32] 확인하도록 만들기 때문입니다

[11:35] 여기서는 확실히

[11:37] Cursor 내의 Gemini에게 큰 점수를 주겠습니다

[11:40] 그럼 Claude는 어떻게 했을까요?

[11:44] Claude로 넘어가 보겠습니다

[11:47] 여기도 같은 프롬프트입니다

[11:50] Claude의 출력에서 정말 좋아하는 점은

[11:52] 항상 계획과 현재 진행상황을

[11:54] 레포지토리 내의 매우 간단한

[11:57] 할 일 목록으로 명확하게 정리해준다는 것입니다

[11:59] 변경사항을 스크롤해보시면

[12:02] 필요한 여러 단계를 통해

[12:04] 단계별로 진행하는 것을 볼 수 있습니다

[12:06] 세부사항으로 지루하게 만들지는 않겠습니다

[12:09] 여기서 생성된 SQL은 더 좋았고

[12:11] 한 번의 실행으로 성공적으로 적용할 수 있었으며

[12:13] 나머지 기능을 올바르게 구현하는 단계로 넘어갔습니다

[12:16] 비록 제가 생각하기에는

[12:18] 일부 파일 명명과 코드가

[12:22] 제가 본 것 중 가장 깔끔하지는 않았지만

[12:25] 파일 네이밍과 코드가 완전히 깔끔하지는 않았다고 생각해요

[12:27] 하지만 다시 말하지만 결국엔 제대로 작동했고

[12:31] 또한 두 에이전트 모두 테스트를 먼저 만들었으면 좋았을 텐데

[12:34] 그래도 괜찮아요

[12:36] 나중에 테스트를 만들어서

[12:39] 여전히 성공적으로 실행했죠

[12:41] 전체 실행 과정을 살펴보면

[12:43] 꽤 많은 체크를 거쳤고

[12:45] 진행하면서 몇 가지 린팅 이슈들을 수정했어요

[12:47] 그리고 테스트를 반복해서 개선했죠

[12:49] 중간에 몇 번 성공과 실패를 반복하면서

[12:52] 과거에 깨진 테스트 문제도 겪었지만

[12:56] 결국 제대로 작동하는 기능을 만들어냈어요

[12:58] 두 개 모두 통과했으니 동점이어야 하지만

[13:00] Gemini를 사용한 Cursor가 약간 우위에 있다고 생각해요

[13:04] 코드 품질이 Gemini가 확실히 조금 더 높거든요

[13:06] 이것이 제가 일반적으로 봐온 문제라고 생각해요

[13:08] Claude는 일반적으로 매우 포괄적이고

[13:11] 기능적인 결과를 생성하는 데 뛰어나지만

[13:13] 코드가 반드시 가장 깔끔하고

[13:15] 우아한 것은 아니에요

[13:17] 하지만 Gemini가 생성하는 코드는 품질이 더 좋고 읽기 쉬운 경향이 있어요

[13:21] 이게 Google이 내부 코드 품질과

[13:24] 스타일링에 더 많이 Gemini를 훈련시켜서

[13:27] 출시했기 때문인지 궁금해요

[13:30] Google의 내부 코드 리뷰 프로세스가

[13:32] 코드를 커밋하는 데 얼마나 엄격한지 알고 있거든요

[13:35] 그래서 그것이 Google이 코드 품질 측면에서

[13:37] 가진 이점일 수 있어요

[13:40] 따라서 여기서는 Gemini를 사용한 Cursor에

[13:42] 약간의 우위를 주겠습니다

[13:45] 다음 테스트인 버그 찾기로 넘어가죠

[13:47] 이 경우, 두 에이전트에게

[13:50] 이 코드베이스에서 중요한 버그를 찾아

[13:52] 반드시 수정해야 할 것들을 나열하는

[13:55] 매우 광범위한 작업을 주었어요

[13:57] 이것은 에이전트가 전체 코드베이스를 탐색하고

[14:00] 많은 것들을 컨텍스트에 담아

[14:02] 수행해야 할 작업의 우선순위를 정하는

[14:05] 능력을 테스트하는 거예요

[14:08] Claude의 출력을 보면

[14:10] 실제로 정말 정말 잘 작동했어요

[14:12] 다시 말하지만, 탐색을 위한 할 일 목록을 만들었고

[14:15] 실제로 꽤 오랫동안 실행됐어요

[14:18] 보시다시피, 코드베이스 탐색 단계에서

[14:21] 시간이 정말 많이 누적되었죠

[14:24] 하지만 흥미로운 점은 마지막에

[14:26] 아름답게 포맷된 목록을 출력했다는 거예요

[14:29] 우선순위, 이슈들, 그리고

[14:31] 각각에 필요한 수정사항과 위험 수준까지 말이죠

[14:34] 수정 버그만 요청했는데도

[14:36] 중간 및 낮은 우선순위로

[14:39] 수정해야 할 것들도 나열해줬어요

[14:41] 여기 나열된 몇 가지 이슈들은

[14:44] 이런 문제들을 잡아낸 것이 정말 놀라워요

[14:46] 제가 이것을 코딩할 때는 알지 못했거든요

[14:50] 이 코드베이스 대부분을 바이브 코딩했지만

[14:52] 그래도 진행하면서 대부분의 코드를 검토했어요

[14:54] 이것은 정말로 코드베이스에서

[14:57] 버그 찾기가 얼마나 중요한지

[14:59] 그리고 AI 코딩 에이전트가

[15:02] 얼마나 도움이 될 수 있는지 보여줘요

[15:04] 마지막에 보시면

[15:05] 총 10개의 중요한 이슈를 찾았어요

[15:08] 모든 이슈가 중요하다고 나와 있는데

[15:11] 저는 동의하지 않아요

[15:13] 높은 중간 우선순위 버그들이

[15:16] 수정해야 할 것들이지만

[15:18] 낮은 것들은 확실히 최우선 수정 대상은 아니에요

[15:21] AI 코딩 에이전트가 진행 과정에서

[15:23] 얼마나 도움이 될 수 있는지 보여줘요

[15:25] 마지막에 보시면

[15:27] 총 10개의 중요한 이슈를 찾았다고 되어 있어요

[15:30] 모든 이슈가 중요하다고 하는데

[15:33] 중요도가 높고 중간 우선순위인 버그들이

[15:35] 수정해야 할 것들이라는 점에 동의하지만, 네

[15:38] 낮은 우선순위 버그들은 확실히 지금 당장

[15:41] 수정할 필요는 없지만, 이렇게 포괄적인

[15:44] 목록을 만들어준 것은 정말 좋았습니다.

[15:45] 이것도 Claude의 특성과 일치하는데,

[15:48] 항상 좀 더 포괄적이긴 하지만

[15:50] 때로는 조금 장황할 수 있습니다.

[15:53] 이번 실행을 Cursor의 결과와 비교해보면,

[15:56] 흥미롭게도 Cursor는

[15:59] 이 과정에서 매우 적은 수의 파일만 살펴봤고

[16:03] 코드베이스의 핵심 파일들 몇 개만

[16:06] 확인했습니다. 심지어

[16:09] 다양한 컴포넌트들을 모두

[16:11] 살펴보려고 시도하지도 않았습니다.

[16:13] 일부 기능에 대해서는 실패했습니다.

[16:16] 저장소의 인증 부분을 살펴보지 못했고

[16:18] 결국 단 하나의 버그만 발견했습니다.

[16:22] 흥미롭게도 제가 적용한 역할 수준 보안의

[16:25] 단 하나의 버그만 찾았고, 이것도

[16:28] 다소 낮은 우선순위라고 말할 수 있지만

[16:32] 아마도 이는 제한된 수의

[16:34] 파일들만 살펴볼 수 있었기 때문에

[16:37] 제한된 것일 수도 있고, 아마도 이는

[16:39] Cursor가 비용을 최적화하려고 하고

[16:42] Claude가 할당량 제한에 대해

[16:44] 꽤 관대하기 때문인 것 같습니다.

[16:46] 하지만 다시 말하지만, 같은 가격으로

[16:49] Claude Code 쪽에서 조금 더

[16:51] 가성비를 얻는 것 같습니다.

[16:54] 이것이 단일 실행의 결과물이 아닌지

[16:56] 확실히 하려고 했습니다.

[16:58] 변경사항 없이 이 명령을 다시

[17:00] 실행해보려고 했습니다. 두 개의 다른

[17:03] 이슈들을 생성했지만, 여전히

[17:05] Claude에 비해 매우 제한적이었습니다.

[17:07] 따라서 이 테스트에서는 Claude Code의 명확한 승리입니다.

[17:10] 다음으로는 두 에이전트의

[17:12] 가이드 따르기 능력과

[17:14] 인터넷 검색 능력을 테스트하고 싶습니다.

[17:16] 제 애플리케이션을 Cloudflare workers에

[17:18] 배포하기 위해 Open Next를 사용해서

[17:22] 마이그레이션하는 간단한 튜토리얼을

[17:24] 따르도록 했는데, 제가 직접

[17:27] 이 가이드를 따라 수동으로

[17:28] 마이그레이션을 해봤기 때문입니다.

[17:31] 그래서 가이드가 완전히 작동한다는 것을 알고 있고

[17:33] 몇 가지 주의사항도 있는데, 에이전트가

[17:36] 이를 잡아낼 수 있는지도 테스트하고 싶었습니다.

[17:38] 그래서 이 배포 가이드와 함께 간단한 프롬프트를 주고

[17:41] 전체 마이그레이션을 시작하도록 했습니다.

[17:44] Cursor는 페이지를 올바르게 검색했고

[17:46] 먼저 관련 종속성을 설치하여

[17:48] 작업을 시작했습니다.

[17:50] 그리고 package.json을

[17:53] 설정했습니다. 하지만 이미 여기서

[17:56] 잘못되기 시작했는데, 가이드에서는

[17:58] package.json에 추가해야 할

[18:01] 매우 구체적인 명령 세트를 제공하는데

[18:04] 이것들은 확실히 잘못되었습니다.

[18:06] 그 직후 미들웨어 이슈로

[18:08] 주의가 분산되었고, 파일을 수정하려고

[18:10] 시도했고, 그것을 업데이트하는 데

[18:13] 꽤 많은 시간을 들였는데

[18:16] 완전히 관련이 없고 이 마이그레이션을

[18:19] 변경하지 않습니다. 그리고 나중에

[18:22] 과정에서 Cloudflare를 통해

[18:25] Open Next 프로젝트를 설정하려고 했는데

[18:28] 명령줄에서 사용자 입력이 필요하기 때문에

[18:30] 몇 번 실행해보다가

[18:33] 결국 포기했습니다.

[18:36] 그래서 우리는 이런 것들이 인간에게는

[18:38] 매우 쉽게 따라 할 수 있는 것들임에도 불구하고

[18:40] 인간에게는 쉬울 수 있지만, 도구들이 에이전트로부터

[18:43] 좀 더 많은 상호작용을 요구할 때는

[18:46] 현재로서는 여전히 실패합니다. 이는 분명히

[18:48] 향후 에이전트 업데이트에서 반드시 봐야 할

[18:50] 개선사항으로, 명령줄 도구에 입력을 제공할 수 있게 해서

[18:52] 더 잘 활용할 수 있도록 해야 합니다.

[18:54] 이미 브라우저는 사용할 수 있으니까요.

[18:56] 좋습니다. 따라서 이는 여기서

[18:58] 쉽게 추가할 수 있어야 합니다.

[19:01] Cursor는 실패했습니다. 그런데 Claude Code는

[19:04] 어떻게 했을까요? 똑같은 프롬프트를 다시 주었을 때

[19:08] 훌륭한 할 일 목록을 만들었고

[19:11] 페이지를 읽을 수 있었으며

[19:14] 백그라운드에서 실제로 fetch가 일어나는 것을 봤습니다.

[19:16] 여기서는 실제로 출력하지 않았지만요.

[19:17] 하지만 코드를 업데이트하는 과정에서

[19:20] 스스로 뭔가를 상상해서

[19:23] 설정을 만들었습니다.

[19:25] 마이그레이션 가이드가 이미

[19:28] 매우 명확한 예시 설정 파일을 제공하고 있는데도

[19:31] 직접 사용할 수 있었을 텐데 말이죠.

[19:32] 가이드를 전혀 따르지 않는 것을 보니 매우 이상합니다.

[19:35] 그리고 나머지 프로세스를 진행하면서

[19:37] 대부분의 설정이 실제로는

[19:40] 올바르게 만들어졌지만

[19:42] Cloudflare Workers에 배포하기 위해

[19:46] 올바른 작업을 따르려고 했습니다.

[19:48] OpenNext를 사용해서 마이그레이션하려고 했지만

[19:51] 순전히 자신의 지식에만 기반했고

[19:53] 페이지 읽기에 실패했다고도 말하지 않았습니다.

[19:55] 페이지를 올바르게 가져왔다는 것을 알고 있는데도 말이죠.

[19:58] 대부분의 규칙을 따르지 못한 것이 매우 이상합니다.

[20:00] 그리고 다시 package.json에 추가한 것들,

[20:02] package.json에 추가된 스크립트가

[20:04] 완전히 잘못되었고

[20:06] 나머지 변경사항들을 살펴보면

[20:09] 다시 말하지만, Claude Code도

[20:11] 인간 입력이 필요한 지점에서 실패했습니다.

[20:14] 하지만 echo Y를 시도해서

[20:16] 입력으로 넣으려고 한 걸음 더 나아갔습니다.

[20:18] 하지만 분명히, 너무 일찍 그렇게 하면

[20:21] 앱을 위한 입력으로

[20:23] 인식되지 않아서

[20:26] 실제로는 명령줄을 진행시키지 못합니다.

[20:28] 따라서 다시 말하지만,

[20:30] Claude Code도 여기서 실패한 것 같습니다.

[20:33] 하지만 명령줄과 상호작용하려고

[20:35] 더 나은 시도를 했지만

[20:38] 전체적으로는 여전히 작업에 실패했습니다.

[20:40] 그리고 이것이 한 번의 실행 결과가 아님을 확인하기 위해

[20:44] 몇 번 더 실행해봤습니다.

[20:46] 그리고 발견한 것은

[20:47] Claude Code와 Cursor 모두에서

[20:51] 각각 한 번씩 작업 실행에 실패했지만

[20:54] 여전히 마이그레이션을 완료했다고

[20:57] 주장하는 경우가 있었습니다.

[20:59] 왜 거짓말을 하려고 했는지 궁금하네요.

[21:02] 하지만 에이전트들이 여전히 이런 행동을 하는 것을 보니

[21:04] 매우 이상합니다.

[21:06] 이는 우리가 항상, 항상

[21:09] 코딩 에이전트의 결과물을 확인해야 한다는 것을

[21:12] 커밋하기 전에 또는 다음 작업으로

[21:14] 진행하기 전에 상기시켜 줍니다.

[21:17] 다음이자 마지막 작업으로 도구 사용을 다뤄보겠습니다.

[21:20] Cursor와 Claude Code 모두에

[21:23] 동일한 Puppeteer MCP를 설정해서

[21:25] 브라우저와 직접 상호작용할 수 있도록 했습니다.

[21:28] 그리고 구체적으로, 개발 사이트를 탐색하도록 요청했습니다.

[21:31] 이것은 현재 저장소를 기반으로

[21:33] 이미 시작한 것이며

[21:35] 기능을 탐색하고

[21:37] 이미 로그인했습니다

[21:39] 사용자로서 기능을 확인할 수 있도록 말이죠.

[21:41] 사용자에게 로그인을 시켜서 실제 사용자처럼

[21:44] 해당 기능을 체험할 수 있도록 했습니다.

[21:46] 그리고 Claude 내부에서 흥미로운 점은

[21:49] 다양한 페이지들을 어떻게

[21:50] 탐색했는지와 콘텐츠를 확인하기 위해

[21:52] 꽤 많은 스크린샷을 찍었다는 것입니다.

[21:55] 처음에는 이게 실제로 작동할 거라고

[21:57] 기대하지 않았는데, 한두 달 전에

[22:00] Claude Code를 처음 테스트했을 때는

[22:02] 이미지 기능이 없었거든요.

[22:03] 그래서 이 기능이 추가된 걸 보니

[22:05] 정말 좋네요. 레포를 분석하고,

[22:08] 페이지를 탐색하고, 심지어

[22:10] 스크롤링도 하고, 몇 가지

[22:12] UI 요소들과 상호작용하여 상호작용성을

[22:16] 확인했고, 실패한 부분도 있었지만

[22:18] 자신의 행동을 스스로 수정하기도 했습니다.

[22:22] 다시 한번, 이렇게 많은 실제 도구 사용을

[22:24] 반복 처리할 수 있다는 것이 정말 좋네요.

[22:28] 그리고 마지막에 Claude Code의 출력에서

[22:30] 정말 마음에 들었던 점은

[22:32] 앱의 전체 플로우를 거쳐가며

[22:35] 모든 다양한 페이지들을 시도해보고,

[22:37] 앱에 존재하는 거의 모든 버튼들을

[22:39] 클릭해보고, 심지어 사용자를

[22:41] 로그아웃시킨 다음 로그인하지 않은

[22:44] 사용자에 대한 다양한 종류의

[22:46] 인증 동작을 확인해봤다는 것입니다.

[22:48] 여기서의 직관력이 정말 훌륭했어요.

[22:50] Claude 4가 이 대부분을

[22:52] Anthropic에서 이전에 개발한

[22:56] 컴퓨터 사용 모델에서 직접 가져와서

[22:58] 대부분의 학습 내용을 여기에

[23:00] 집어넣었는지 궁금하네요. 결과는

[23:03] 정말 훌륭했고 여기서의 훌륭한 요약과

[23:05] 사용자 경험에 대해 어떻게 생각하는지

[23:08] 피드백까지 주었어요.

[23:10] 칭찬하는 면에서는 아마 너무

[23:12] 관대했을 수도 있지만 정말 잘 작동했습니다.

[23:15] 그리고 이것을 Cursor 실행과

[23:17] 비교해보면, 물론 Cursor도

[23:20] 도구를 정말 잘 사용할 수 있었어요.

[23:22] 탐색하고, 스크린샷을 찍고, 채우고,

[23:25] 상호작용하는 동일한 프로세스를 거쳤고,

[23:27] 가끔은 페이지를 사용해서

[23:29] 제대로 입력할 수 없는 경우도 있었고

[23:32] 페이지 요소들과 상호작용하기 위해서 말이죠.

[23:35] 그리고 어떤 일이 일어나기를

[23:37] 기다리는 부분들이 있었는데, 실제로

[23:39] 페이지에서 도구 자체를 사용해

[23:42] 직접 기다리고 타임아웃하는 것을

[23:45] 알고 있었고, 분석이 백그라운드에서

[23:47] 실제로 일어나도록 했어요. 정말 멋지네요.

[23:50] 그리고 다시 몇 가지 문제에 부딪혔지만

[23:53] 과정에서 자신의 행동을 스스로

[23:56] 수정할 수 있었고, 마지막에는

[23:59] 시도한 행동들에 대한 괜찮은 요약도

[24:02] 만들어냈지만, Cursor의 행동을 비교해보면

[24:05] 실제로 테스트한 UI 요소들 측면에서

[24:07] 훨씬 더 제한적이었어요.

[24:09] 왜냐하면 두 에이전트 모두가

[24:12] 전반적으로 작업을 실행하려고 하는 것을

[24:14] 지켜봤는데, Claude는 아마

[24:16] Cursor가 한 것보다 두 배 정도의

[24:18] 기능들을 거쳐갔고, 그리고

[24:21] Cursor는 그런 다양한

[24:23] UI 요소들을 다룰 때 꽤 많이

[24:25] 제한된 상호작용을 했고, 예를 들어

[24:28] 인증의 경우 로그아웃한 사용자의

[24:31] 동작을 테스트해보려고 하지 않았어요.

[24:33] 그리고 분명히 여기서 우리가

[24:35] 더 나은 규칙을 만들거나 더 구체적인

[24:37] 프롬프트를 가졌다면 Cursor가 더 잘했을 거라고 말할 수 있어요. 아마 그랬을 거예요.

[24:40] 그런 경우였지만 Claude Code가 Cursor보다

[24:42] 더 나은 작업을 수행할 수 있는 뛰어난 직관을 가지고 있다는 것을 보는 것은

[24:45] 매우 흥미로웠습니다. 따라서 이 경우에도

[24:48] Claude Code의 승리입니다.

[24:50]

[24:52] 이제 점수를 합산해보면 Claude가 4승이고

[24:54] Cursor가 2승입니다. 따라서

[24:56] 간단하게 결론내리면

[24:57] Claude Code가 최고라고 말할 수 있을 것 같습니다. 하지만

[25:00] 실제로는 그렇게 간단하지 않습니다. 그리고

[25:02] 이러한 코드 변경사항들을 살펴보고

[25:04] 전체 프로세스를 진행하면서

[25:06] 이러한 테스트들을 구축하는 동안

[25:08] 이러한 코딩 에이전트들로부터 일관된 동작을

[25:10] 얻으려고 시도하면서 깨달은 것은

[25:12] 가장 중요한 것은 실제로 사용하는 에이전트가 아니라는 것입니다.

[25:16] 최신 에이전트 중 하나를 사용하는 한

[25:17] 품질은 실제로 매우 매우 비슷했습니다.

[25:19]

[25:22] 차이를 만든 것은 규칙 파일에

[25:24] 얼마나 많은 노력을 기울였느냐였습니다.

[25:27] 그리고 일부 테스트를 만드는 동안

[25:28] 두 에이전트로부터 일관된 동작을

[25:31] 얻기 위해서는

[25:33] 규칙 파일에 상당한 추가 작업을 해야 했습니다

[25:35] 두 에이전트로부터 훌륭한 동작을

[25:38] 얻기 위해서 말이죠. 하지만 규칙 파일이

[25:39] 개선되고 나면, 두 에이전트 모두

[25:41] 실제로 정말 잘 작동했습니다. 전체

[25:44] 기능 구현 테스트를 보면, 둘 다

[25:47] 700줄의 변경사항을 처리하는 데

[25:49] 정말 잘했고, 첫 번째 시도에서 성공했으며

[25:52] 데이터베이스 스키마 변경사항을 생성하고

[25:54] 테스트를 작성하고, 기능을

[25:56] 모두 단일 프롬프트로 만들어냈습니다. 맞죠? 그리고 그것은

[25:59] 에이전트 자체의 능력보다는

[26:02] 규칙에 설정된 훌륭한

[26:04] 명세의 이점 때문이었습니다.

[26:06] 에이전트 자체의 능력보다는 말이죠. 따라서 실제로 여기서

[26:10] 둘 중에서 선택할 때, 저는

[26:12] 탐색이나 더 복잡한 이슈

[26:15] 해결과 같은 작업에는 Claude를

[26:18] 선호하고, 심지어 버그

[26:20] 찾기 같은 작업에도 선호합니다. 하지만 확실히

[26:22] 기능 구현에는 Gemini와 함께하는 Cursor를

[26:25] 선호합니다. 왜냐하면

[26:27] Gemini와 함께 얻는 더 높고 다른

[26:29] 코드 품질 때문입니다.

[26:32] 물론 이제 Gemini CLI도

[26:34] 출시되었기 때문에, 저는 확실히

[26:36] 곧 그것을 테스트해야겠습니다. 자, 여기까지입니다.

[26:38] 규칙 파일의 중요성을 고려할 때

[26:40] 여러분은 위에 있는 제 비디오를

[26:41] 확인해서 그런 것들을 더 잘

[26:44] 작성하는 방법을 배워

[26:45] 코딩 에이전트 출력의 품질을 향상시켜야 합니다.

[26:48] 아래 댓글로

[26:50] 이러한 테스트들을 사용해서 다른 AI 코딩 에이전트들을

[26:52] 직접 비교해보길 원하시는지

[26:54] 아니면 제가 다뤄봤으면 하는

[26:56] 다른 시나리오가 있는지

[26:58] 알려주세요. 저는 확실히

[27:00] 앞으로 몇 주 동안 이 테스트 스위트를

[27:02] 개선해서 새로운 도구가 나왔을 때

[27:05] 제가 또 다시 새로운

[27:07] Cursor 킬러로 전환해야 하는지

[27:10] 아니면 다음 번에는

[27:12] Claude Code 킬러인지 더 잘 판단할 수 있도록 할 것입니다. 그리고

[27:14] 그때까지, 즐거운 개발하시고

[27:16] 다음 영상에서 만나요.