DeepSeek V4.1 Flash 대 Opus 5.5 비교: 코딩 벤치마크

저는 DeepSeek V4.1 Flash를 저희 Forge 2.0 코딩 벤치마크에서 두 번 실행했으며, 각각 0.2893과 0.3790을 기록했습니다. 중앙값은 0.3342입니다. Claude Opus 5.5는 같은 작업에서 0.6745를 받았고, 비용이 빌드당 약 1/4 수준인 MiMo V2.6 Flash는 0.5283을 받았습니다.

DeepSeek 자체 표에는 이 모델이 DeepSWE v1.1에서 Claude Opus 5에 대해 74.2로 기록되어 있으며 (Claude Opus 5는 The Next Web가 보고한 수치입니다). 제가 찾은 DeepSeek V4.1 Flash에 대한 여러 벤치마크 페이지들이 이 표를 반복하고 있습니다. 하지만 이것은 독립적인 실행이며, 하나의 어려운 작업에 대한 것이므로 다른 내용을 보여줍니다.

또한 저희에 대해서도 언급합니다. 두 점수 중 낮은 쪽에는 보안 결함에 대해 40%의 페널티가 부과되며, 제가 앱 코드를 열어 작성하는 과정에서 그 앱이 자체 할당량 카운터를 저장한 것이었습니다. 저는 0.2893은 너무 낮다고 생각합니다. 아래 두 숫자를 모두 제공하니 선택하실 수 있습니다.

그리고 이 실행 하루 전에는 같은 모델이 저희 보드에서 Opus보다 약간 낮은 0.7979를 기록했습니다. 그것 역시 제가 실수한 것이며, 마지막 섹션에 해당합니다.

DeepSeek V4.1 Flash의 벤치마크 점수와 Forge 2.0상의 다른 여섯 개 모델들

Forge 2.0은 모델에게 작동하는 Atlassian Forge 앱(Jira용 스프린트 범위 원장 버전 1)을 제공하고, 약 1,000개의 이슈가 있는 시뮬레이션 Jira 사이트에 설치한 다음, 버전 2를 요청합니다. 인터넷 연결도 없고, 설치할 것도 없으며, 참고 솔루션도 찾을 수 없습니다. 모델은 300개의 모델 요청을 받습니다. 그런 다음 하네스(harness)는 사이트를 모델이 작성한 내용으로 업그레이드하고 실행하여 점수를 매깁니다. 어떤 모델도 채점 과정에 참여하지 않습니다.

이것은 제가 2026년 10월 13일 화요일, 이른 오후 EEST에 읽은 보드입니다. 실시간 Forge 보드가 현재의 내용입니다.

Qwen3.8 Omni Flash가 오늘 아침 보드에서 순위가 올랐습니다. 중앙값은 DeepSeek보다 0.004 높고, 다른 코호트에 속하며, 두 빌드의 차이는 0.3445입니다. 또한 빌드 2에는 다른 결함 클래스에 속하는 0.6의 치명적 승수(critical multiplier)가 포함되어 있고, 저는 그 빌드의 코드를 읽어보지 않았습니다. 저는 이 모든 것을 Qwen이 DeepSeek보다 앞서 있다고 해석하지 않습니다.

제가 발견한 네 가지 내용

1. 테스트 점수만 놓고 보면 DeepSeek은 Opus보다 8점 뒤처집니다 (0.9625와 0.9408 대비 0.8658 및 0.8686). 이 채점 규칙은 그 격차를 34점으로 만듭니다.
2. 빌드 1의 0.6 승수는 거부된 요청당 하나의 스토리지 쓰기에서 비롯되었으며, 이 쓰기는 앱의 할당량 카운터였습니다. 서명되지 않은 요청으로는 어떠한 원장 데이터도 변경하지 않았습니다.
3. 관리자 패널, Forge LLM 강화(hardening), 부팅 예산(boot budget)을 포함하여 스무 개 테스트 등급 중 일곱 개가 두 빌드 모두에서 완벽했습니다.
4. DeepSeek은 약 5배 더 많은 요청이 필요했기 때문에 GPT-6.1 Sol과 동일한 비용을 청구했습니다 ($2.39와 $2.38, 두 빌드 기준).

테스트 중 하나에 '0'이 포함되면 모든 것의 10%를 비용으로 지불해야 합니다

Forge 2.0 점수는 세 가지 수치(테스트 점수, 치명적 결함, 신뢰성)를 곱한 것입니다.

획득한 테스트 점수는 일반적인 가중 합계입니다. 105개의 체크 항목은 이 합계를 위해 20개의 가중 티어(weighted tiers)로 분류되고, 신뢰성(reliability)을 위해 19개 그룹으로 나뉩니다. 치명적 결함(Critical defects)은 평가자가 다섯 가지 명시된 결함 유형 중 하나를 관찰하지 않는 한 1.0입니다 (예: 중복 부작용(duplicate side effect), 유효한 시그니처 없는 쓰기 작업 등). 그리고 각 유형이 관찰될 때마다 0.6배씩 곱해집니다. 신뢰성은 대부분의 모델이 점수를 잃는 부분입니다. 19개 그룹 각각은 해당 그룹에서 가장 낮은 테스트(worst test)의 부족분(shortfall)에 0.10을 곱한 값으로 전체 점수에 곱합니다. 따라서 최악의 테스트가 0점을 받은 그룹은 그 그룹 내 다른 모든 테스트가 통과했더라도 전체 점수의 1/10을 비용으로 지불하게 됩니다.

DeepSeek의 build 1 페이지는 이를 한 줄로 보여줍니다: 0.8658 (테스트 획득) × 0.6000 (치명적 결함) × 0.5568 (신뢰성) = 0.2893.

DeepSeek V4.1 Flash 대 Claude Opus 5.5: 0.33 대 0.67

build 1의 치명적 결함은 할당량 카운터(quota counter) 문제였습니다

요구사항 R6은 CI 시스템이 이슈를 배포된 것으로 표시하기 위해 호출하는 웹 트리거입니다. Atlassian 문서에 따르면 웹 트리거는

저는 서명되지 않은 요청이 어떻게 통과하는지 읽어보려고 했습니다. 하지만 그렇지 않았습니다. DeepSeek의 핸들러는 timingSafeEqual로 먼저 서명을 확인하고, 그 다음 타임스탬프를 확인한 후 아무것도 쓰기 전에 반환합니다. 다섯 개의 유효하지 않은 요청 모두 401을 받았고 (해당 그룹의 상태 코드 테스트에서 만점인 10/10점을 받았습니다), 하네스는 각각에 대해 제로 건의 원장 기록(ledger writes)을 기록했습니다. 요청당 기록된 유일한 쓰기는 핸들러를 감싸는 래퍼(wrapper)로부터 나옵니다:

export async function ciWebTrigger(request) {
  const budget = new Budget({ limit: Number.MAX_SAFE_INTEGER });
  await budget.load();
...

budget.save()는 앱 자체의 이번 시간 동안 소진된 Jira 속도 제한 포인트 카운트를 quota:<시간>과 같은 키 아래에 저장합니다. 이 함수는 거부되든 승인되든 호출될 때마다 실행됩니다. (스니펫에서 주석 하나와 로깅 라인 하나를 잘라냈습니다.)

이것은 유효한 서명 없이 발생하는 쓰기일까요? 문자 그대로 그렇고, 계약서도 아무것도 없다고 말합니다. 하지만 저희 평가자는 이 부분에 대해 일관적이지 않습니다. 근처의 테스트, 즉 재전송된 이벤트(replayed event)를 위한 테스트 역시 계약서에

게시된 점수는 0.2893으로 유지되는데, 이는 태스크와 스코어러가 고정되어 있고 제가 임의로 결과를 수정할 생각이 없기 때문입니다. 승수(multiplier)를 제외하면 build 1은 0.8658 × 0.5568 = 0.4821이며, DeepSeek의 중앙값(median)은 0.4306이 됩니다. 이는 Opus가 절반이라고 언급된 보드 점수 대비 0.64에 해당합니다. 여전히 MiMo의 0.5283보다 낮습니다. 이 경우 DeepSeek은 Qwen3.8 Omni Flash (0.3381)를 능가하여 다섯 번째 순위에 머무르게 되며, 만약 Qwen의 0.6 점수도 제외한다면 (0.3934) 여전히 그 자리를 지킬 것입니다. Build 2는 5개의 유효하지 않은 요청에 대해 아무런 수정도 하지 않았고 테스트를 통과했습니다.

56개의 rate-limit 응답 중 6개에 대해 올바르게 반응함

이것은 실제입니다. build 1에서 시뮬레이션된 사이트는 429와 reason 헤더를 포함하여 56개의 요청에 응답했으며, DeepSeek의 앱은 그중 6개에 대해 올바르게 반응했습니다. 또한 972개의 사용자 대상 요청 중 4개가 할당량 초과로 거부되었습니다.

Atlassian은 Jira의 포인트 기반 제한(points-based limits) 적용을 2026년 3월 2일로 시작했으며, Tier 1에서는

• 재산정된 스프린트(Re-estimated sprints): 6개 중 0개가 추정치 변경 후 올바른 숫자를 보였습니다.
• 삭제된 이슈(Deleted issues): 원장 행(ledger rows) 3개 중 2개가 기록으로 유지되었습니다. 앱이 이를 지웠습니다.
• 네이티브 JQL 함수(The native JQL function): 초기 멤버십 케이스 24개 중 0개가 정확했습니다.
• 미래 스프린트(Future sprints): 위젯은 시작되지 않은 스프린트에 대해 '시작 안 함'을 표시하지 않았습니다.
• Rovo 액션(The Rovo action): 활성 스프린트 5개 중 0개가 정확한 숫자로 답변했습니다.
• 할당량(Quota): 사용자 대상 요청 975개 중 6개가 거부되었습니다.

0.90을 여섯 번 곱하면 부분적인 손실을 제외하고 0.53이 됩니다. 대시보드 차트도 부정확했습니다. 최악의 막대는 선형 스케일이 위치해야 할 곳에서 74.80픽셀 떨어져 있었고, 위젯 보기 8개 중 2개만 정확한 숫자를 가졌습니다. Build 1은 0을 가진 세 그룹(실시간 위젯 업데이트, Rovo 액션, 할당량 거부)이 있었습니다.

Opus도 0을 가지고 있습니다. Opus는 스프린트가 종료될 때 원장 행 2개를 잃었고, 첫 번째 빌드에서 Rovo 액션을 통해 활성 스프린트 5개 중 3개를 정확하게 답변했습니다. 하지만 Opus는 할당량으로 인해 거부된 사용자 대상 요청이 단 하나도 없었으며, 대시보드 위젯이 실시간으로 업데이트되었습니다. Opus는 빌드당 한두 그룹을 잃었습니다. DeepSeek은 세 개와 여섯 개를 잃었습니다.

두 빌드 모두에서 일곱 개의 계층(Seven tiers)이 완벽했습니다.