커서 플랫폼 모델 비교: DeepSeek V3/R1 대 Claude 3.5 소네트 테스트

DeepSeek 최신 모델 테스트: V3 및 R1 vs. Claude 3.5 소네트, 누가 더 낫죠?

딥시크는 최근 다음과 같은 발표를 했습니다. 커서 이 플랫폼은 두 가지 새로운 모델인 DeepSeek V3와 R1을 출시했습니다. 현재 당사를 포함한 많은 개발자가 Claude 3.5 Sonnet(최신 버전 claude-3-5-sonnet-20241022)을 기본 언어 모델로 사용하고 있습니다. 새로운 모델이 실제로 어떻게 작동하는지 확인하기 위해 이 두 가지 DeepSeek 모델과 클로드 3.5 소네트를 실제로 비교 테스트하기로 결정했습니다.

딥서치 모델 소개

딥시크는 최근 성능 면에서 OpenAI의 o1 모델에 필적한다고 알려진 강력한 R1 모델을 오픈소스로 공개해 많은 주목을 받고 있습니다. Cursor 플랫폼은 항상 발 빠르게 대응해 왔으며, DeepSeek 모델이 출시되자마자 사람들은 실제 애플리케이션에서 테스트를 시작하기를 기다릴 수 없었습니다.

성능 비교 참조
DeepSeek의 공식 출시 DeepSeek R1 및 V3 성능 데이터를 OpenAI의 o1 및 o1-mini 모델과 비교합니다.

테스트 작업 개요

이 비교 테스트는 크게 두 부분으로 구성되어 있습니다:

• 채팅 모드 -- 일상적인 개발 시나리오를 시뮬레이션하고 Next.js 애플리케이션의 대화 상자 구성 요소에 서버 측 동작을 추가하는 방법을 살펴봅니다.
• 코드 생성 모드 -- 더 이상 필요하지 않은 프런트엔드 배포 관련 구성 및 E2E(엔드투엔드) 테스트 단계를 제거하기 위해 CircleCI 구성 파일을 수정하여 코드 유지 관리 시나리오를 시뮬레이션합니다.

일반적으로 모델이 자율적으로 작업을 수행하고 도구를 호출할 수 있는 모드를 의미하는 커서 플랫폼의 '에이전트 모드'는 현재 커서 플랫폼에서만 사용할 수 있다는 점에 유의하세요. 인류학 모델과 GPT-4o가 개방되어 있으므로 이 테스트에는 프록시 모델이 포함되지 않습니다.

채팅 모드 비교

사명 선언문

우리가 제기한 질문은 Next.js 애플리케이션의 대화 상자 구성 요소에 서버 측 동작을 올바르게 추가하는 방법이었습니다. 구체적인 질문 프롬프트는 다음과 같습니다:

"서버 측 작업을 구현하고 이 대화 상자 구성 요소에 올바르게 전달하는 방법을 설명해 주세요."

보다 구체적인 맥락을 제공하기 위해 대화 상자 구성 요소와 관련된 코드가 포함된 파일도 첨부했습니다.

DeepSeek R1의 성능

높은 인지도를 자랑하는 DeepSeek R1은 당연히 테스트의 첫 번째 선택이었습니다. 하지만 R1을 사용하면서 두 가지 명백한 문제를 빠르게 발견했습니다:

• 출력 스트리밍이 느림
  R1은 답변 생성 속도가 느리고 전체 결과를 확인하기 위해 더 오래 기다려야 합니다.
• 명확한 블록으로 답변 시작
  R1은 정식으로 답변하기 전에 사고 과정을 제시하는 것과 유사하게 태그가 포함된 콘텐츠의 큰 부분을 출력합니다. 이 전처리 단계는 최종 답변의 품질을 크게 향상시킨다면 허용될 수 있습니다. 그러나 문제는 느린 스트리밍 출력과 겹쳐지면 실제 유효한 정보를 표시하는 데 상당한 지연이 발생한다는 것입니다. 예를 들어, 모델이 실제 답변을 느리게 스트리밍하기 전에 대량의 콘텐츠를 출력하면 전체 대기 시간이 매우 길어집니다. 이론적으로는 커서 규칙을 설정하여 섹션을 건너뛰는 것이 가능하지만 이는 현재 기본 상태 테스트의 범위를 벗어난 것입니다.

또한 R1의 답변은 문제를 해결하기 위해 next-safe-action/hooks 라이브러리를 설치하라고 제안하지만, 후속 답변에서 이 라이브러리를 서버 측 작업에 사용하는 방법에 대해서는 자세히 설명하지 않습니다. 저희가 제기한 문제와 같이 비교적 간단한 문제에 대해 추가 라이브러리 설치를 제안하는 것은 다소 '사소한' 것 같습니다.

DeepSeek V3의 성능

DeepSeek V3는 또한 상당히 우수한 성능을 제공하며, 심지어 React 19의 새로운 기능인 사용 폼 상태. 이는 V3 모델이 최신 프론트엔드 기술 및 코드베이스에 대해 학습하고 있음을 시사합니다. 그러나 V3는 코드 구현에 클라이언트 측 구성 요소에서 직접 서버 측 작업을 호출하는 심각한 버그가 있습니다. Next.js에서는 이것이 불가능합니다. (참고로 Next.js는 보안, 성능 및 코드 정리를 위해 서버 측 코드를 서버 측 환경에서 실행해야 하며 클라이언트 측 구성 요소의 코드는 기본적으로 브라우저 측에서 실행됩니다. 클라이언트 측 컴포넌트에서 서버 측 코드를 직접 호출하면 서버 측 모듈을 찾지 못하거나 네트워크 요청이 실패하는 등의 오류가 발생할 수 있습니다(예: 네트워크 요청 실패 등). 예를 들어 클라이언트 측 JavaScript 코드에서 서버 측 함수를 직접 호출하면 런타임 오류가 발생하거나 서버 측 코드가 전혀 실행되지 않습니다.

R1과 마찬가지로 V3의 출력 스트리밍 속도는 느립니다. 하지만 V3에는 R1의 긴 블록이 없기 때문에 전반적인 경험은 R1보다 약간 더 좋습니다.

클로드 3.5 소네트 공연

이에 비해 Claude 3.5 Sonnet은 "느린 요청 모드"(예: 월 API 요청 수가 무료 할당량을 초과하여 유료 요청에 들어가는 경우 요청 속도 제한이 발생할 수 있음)에서도 가장 빠릅니다. Sonnet은 V3처럼 최신 React 기능(useFormStatus)을 권장하지 않고 클라이언트 측 컴포넌트에서 서버 측 연산을 직접 호출하여 V3와 비슷한 실수를 범하지만, 실제 가능한 답변에 더 가까운 솔루션을 제공합니다.Sonnet은 서버 측 연산 기능에 'use server' 지시문을 추가하면 다음과 같은 효과가 있다고 제안합니다. 소네트는 서버 측 동작 함수에 'use server' 지시어를 추가하면 Next.js의 요구 사항을 충족할 수 있다고 제안합니다.(지식 보충: '서버 사용') 는 서버 측 작업으로 함수를 명시적으로 선언하기 위해 Next.js 버전 13 이상에 도입된 핵심 지시어입니다. 서버 측에 '서버 사용' 그러면 Next.js가 해당 함수를 서버 측 코드로 올바르게 인식하고 클라이언트 측 컴포넌트가 이를 안전하게 호출할 수 있습니다.) 실제로는 다음과 같이 간단하게 추가할 수 있습니다. '서버 사용' 참고로 소네트의 솔루션은 문제를 본질적으로 해결하며, 딥서치 모델이 제공하는 솔루션보다 더 실용적입니다.

코드 생성 모드 비교

사명 선언문

이 테스트 세션에서는 풀스택 애플리케이션을 배포하기 위한 CircleCI 프로필을 제공합니다. 이 애플리케이션에는 순수 React 프론트엔드와 Node.js 백엔드가 포함되어 있습니다. 원래 배포 프로세스에는 여러 단계가 포함되어 있습니다. 우리의 목표는 이 구성 파일을 수정하여 다음 두 가지를 모두 수행하는 것입니다:

• 프런트엔드 배포와 관련된 모든 구성을 제거합니다.
• 애플리케이션이 백엔드에 불과하다는 것을 인식하면 E2E 테스트(엔드투엔드 테스트, 일반적으로 전체 사용자 흐름을 테스트하는 데 사용)가 더 이상 필요하지 않으며 관련 구성 단계가 제거됩니다. (추가 지식: E2E 테스트는 주로 사용자 행동을 시뮬레이션하고 프런트엔드 및 백엔드 상호 작용의 전체 흐름을 확인하는 데 사용됩니다. 애플리케이션에 백엔드만 있고 사용자 인터페이스가 없는 경우 E2E 테스트는 의미가 없습니다. 일반적으로 사용되는 E2E 테스트 프레임워크에는 Cypress, Selenium 등이 있습니다.)

문제 프롬프트에 "프론트엔드 배포와 관련된 모든 섹션을 제거"하도록 명시하고 모델에 전체 CircleCI 구성 파일을 컨텍스트로 제공하도록 명시하고 있습니다.

DeepSeek R1의 성능

저희는 문맥 이해와 여러 번의 수정이 필요한 작업(작곡가 작업)에서는 블록이 있는 R1 모델이 더 나은 성능을 발휘할 것으로 예상했습니다. 하지만 결과는 그렇지 않았습니다:

• R1은 프론트엔드 배포와 명확하게 관련된 일부 구성을 생략합니다. (예: 구성 파일에서 웹앱 참조 구축을 참조하는 부분은 여전히 보존됩니다). 그러나 그 장점으로는, 이 도구는 배포-넷리파이 (프런트엔드 정적 리소스 호스팅 플랫폼으로 일반적으로 사용되는 Netlify 플랫폼에 배포하는 단계) 이 단계는 더 이상 필요하지 않으므로 제거되었습니다.
• 동시에 R1은 배포_프로덕션_api라는 레이블이 지정된 백엔드 배포 단계를 잘못 제거합니다.로 인해 백엔드 서비스가 제대로 배포되지 않을 수 있습니다. 또한 R1 감지할 수 없음 E2E 테스트는 더 이상 관련이 없으며 관련 구성은 여전히 유지됩니다.

DeepSeek V3의 성능

DeepSeek V3는 코드 수정 작업에서 R1보다 약간 더 나은 성능을 보였습니다. R1이 놓친 일부 프런트엔드 배포 구성을 수정하지만 새로운 문제도 노출합니다. 예를 들어, V3는 여전히 배포-넷라이즈 단계를 유지하므로 작업 요구 사항을 완전히 이해하지 못한다는 것을 알 수 있습니다. 다행히도 V3는 백엔드 배포 단계를 그대로 유지했으며 R1에서와 마찬가지로 실수로 백엔드 배포 구성을 삭제하지 않았습니다. 그러나 R1과 마찬가지로 V3도 E2E 테스트 섹션을 삭제할 수 있는지 확인하지 못했습니다.

클로드 3.5 소네트 공연

이 코드 수정 작업에서는 유서 깊은 Claude 3.5 Sonnet이 가장 뛰어난 성능을 발휘했습니다:

• Sonnet은 프런트엔드 배포와 관련된 대부분의 명령을 성공적으로 제거했습니다.V3와 마찬가지로 이 제품도 배포-넷리파이 단계를 제거하지 못했습니다..
• 백엔드 배포 단계의 측면에서도 Sonnet은아니요, 실수로 삭제된 것이 아닙니다.
• 결정적으로 Sonnet은 백엔드 서비스만 남았기 때문에 E2E 테스트가 더 이상 필요하지 않다는 사실을 정확히 인식했습니다.그 결과, Sonnet은 Cypress 테스트를 가속하는 데 사용되는 Cypress 바이너리 캐시를 포함한 모든 E2E 테스트 관련 구성을 제거했습니다. 그 결과 Sonnet은 Cypress 바이너리 캐시(Cypress 테스트 가속화에 사용되는 캐시)를 포함한 모든 E2E 테스트 관련 구성을 제거했습니다.(추가 지식: Cypress 바이너리 캐시는 Cypress 테스트를 실행하는 데 필요한 바이너리를 캐시하는 데 사용되므로 후속 테스트의 시작 속도를 높일 수 있습니다. 그러나 E2E 테스트가 제거되면 중복 구성을 피하기 위해 이 캐시 구성도 제거해야 합니다.) 이는 이번 테스트에서 가장 우수한 솔루션으로, Sonnet이 작업의 의도를 깊이 이해하고 보다 포괄적인 코드 변경을 수행할 수 있는 능력을 보여줬습니다.

요약

커서 플랫폼은 지속적으로 새로운 AI 모델을 도입하여 개발자에게 항상 새로운 옵션과 가능성을 제공하고 있습니다. 이 비교 테스트의 작업은 비교적 간단했지만, 실제 개발 시나리오에서 두 DeepSeek 모델의 기능을 처음에 입증하기에 충분했습니다. Claude 3.5 Sonnet과 비교했을 때 DeepSeek의 모델에는 고유한 강점과 약점이 있습니다.

전반적으로 이 테스트에서는 응답 속도와 출력 품질 모두에서 Claude 3.5 Sonnet이 DeepSeek의 두 모델보다 확실히 앞섰습니다. 서버 최적화, 네트워크 분산 및 기타 요인으로 인해 향후 버전에서 DeepSeek 모델의 응답 속도가 개선될 수 있지만, 지금까지의 실제 테스트 결과에서 실용성과 신뢰성 측면에서 Claude 3.5 Sonnet이 여전히 최상위권에 속합니다.

전반적으로 이 테스트는 현재 커서 플랫폼에서 클로드 3.5 소네트가 여전히 더 성숙하고 신뢰할 수 있는 선택임을 보여줍니다. 그러나 DeepSeek의 새로운 모델도 잠재력을 보여주며 개발자의 지속적인 관심과 실험이 필요합니다. 이 모델이 계속 반복되고 개선됨에 따라 앞으로 더 나은 성능을 발휘할 수 있을 것입니다.