10월 17일, DeepSeek가 DeepSeek-V4.1-Flash-1017을 공개했습니다. 이름에서 짐작할 수 있듯 새로운 모델 계열이 아닙니다. 9월 10일 공개한 V4.1 Flash에 1017이라는 날짜를 붙인 리프레시입니다.

그런데 마이너 업데이트라고 부르기에는 숫자가 조금 이상합니다. 공식 모델 카드에서 Terminal-Bench 4.0 점수는 31.2에서 42.3으로, Automation-Bench v1.0.6은 54.8에서 60.5로 올랐습니다. 같은 모델의 같은 계열인데, 에이전트가 실제 작업을 끝내는 비율이 눈에 띄게 달라졌습니다.

이 글은 그 숫자가 무엇을 재는지, 그리고 왜 "점수만 보고 모델을 고르면 안 되는지"를 정리합니다.

무엇을 바꿨다고 밝혔나

공식 모델 카드가 말하는 개선 범위는 이렇습니다.

DeepSeek-V4.1-Flash-1017 (공식 모델 카드 요약)

- reasoning · coding · agentic · visual 벤치마크 전반의 개선
- task execution time 감소
- 출력 길이(output length) 감소
→ "더 빠르고 더 저렴하게 작업을 끝낸다"
→ 여러 에이전트 하네스에서 performance-cost 파레토 전진

핵심은 마지막 줄입니다. 정확도만 올린 게 아니라, 같은 작업을 더 적은 토큰과 더 짧은 시간에 끝낸다고 주장합니다. 에이전트를 돌리는 입장에서 비용은 "토큰 × 단가"이므로, 출력이 짧아지는 것은 정확도 향상만큼 중요합니다.

숫자로 보는 변화

먼저 이전 버전과 1017을 나란히 놓겠습니다. 모두 DeepSeek가 자체 발표한 값입니다.

벤치마크 V4.1 Flash 1017 변화
Terminal-Bench 4.0 31.2 42.3 +11.1
Automation-Bench v1.0.6 54.8 60.5 +5.7
DeepSWE v1.1 74.2 77.0 +2.8
ProgramBench 20.3 29.1 +8.8
NL2Repo-Bench 65.4 68.2 +2.8
Agents' Last Exam 31.8 35.4 +3.6
Apex Bench v1.1 64.6 72.1 +7.5
HLE (도구 없이) 36.8 42.6 +5.8
Chartography (도구 사용) 78.9 83.0 +4.1
BabyVision (도구 사용) 89.6 92.5 +2.9
ZeroBench-main (도구 사용) 49.0 51.0 +2.0

가장 극적으로 보이는 항목은 Terminal-Bench 4.0입니다. 이 벤치마크는 모델이 터미널 안에서 실제 작업을 끝내는지, 즉 파일을 읽고, 명령을 실행하고, 결과를 확인하고, 목표 상태에 도달하는지를 측정합니다. 단순히 "코드를 잘 생성하는가"가 아니라 "에이전트가 일을 마무리하는가"를 봅니다. 그래서 코딩 에이전트를 만드는 입장에서 가장 관심 가는 지표입니다.

ProgramBench가 20.3에서 29.1로 오른 것도 눈에 띕니다. 상대적으로 어려운 축에서 개선 폭이 컸다는 뜻입니다.

그런데 1등은 아니다

같은 표에는 경쟁 모델도 함께 놓여 있습니다. 정직하게 보면, 1017이 모든 항목에서 앞서지는 않습니다.

벤치마크 1017 K3 GLM-5.3 GPT-5.6 Sol Opus 5
Terminal-Bench 4.0 42.3 12.6 37.9 39.9 51.8
Automation-Bench v1.0.6 60.5 46.7 48.8 45.8 50.3
DeepSWE v1.1 77.0 67.5 66.9 73.0 74.0
ProgramBench 29.1 17.5 19.0 23.0 37.0
HLE (도구 없이) 42.6 43.5 42.0 44.5 56.3
NL2Repo-Bench 68.2 58.0 58.0 56.8 75.3

읽는 법이 중요합니다. 1017은 Terminal-Bench, Automation-Bench, DeepSWE, ProgramBench, Agents' Last Exam, Apex Bench에서 앞서거나 앞서는 편입니다. 반면 HLE(추론 난이도가 높은 지식 문항)와 NL2Repo에서는 Opus 5가 확실히 위입니다. 즉 "에이전트가 도구를 다루며 일을 끝내는 능력"에서는 강하고, "가장 어려운 추론"에서는 여전히 프런티어 폐쇄 모델이 앞선다는 구도입니다.

K3의 Terminal-Bench 4.0이 12.6으로 낮은 것도 흥미롭습니다. 이 숫자는 K3가 나쁜 모델이라는 뜻이 아닐 수 있습니다. 터미널 벤치마크는 모델이 도구를 어떤 형식으로 호출하도록 학습됐는지에 민감하기 때문입니다.

점수는 '모델'이 아니라 '모델 + 하네스'의 값이다

여기서 이 글의 핵심으로 들어갑니다. 모델 카드 각주를 보면 점수가 어떤 조건에서 측정됐는지 나옵니다.

Terminal-Bench 4.0  → Claude Code 하네스로 측정
DeepSWE v1.1        → Mini-SWE-V2 하네스로 측정
HLE의 † 표시         → 텍스트 전용 하위 집합

즉 표의 한 칸은 이런 값이다.

  [점수] = f(모델, 하네스, 도구 정의, 프롬프트 형식, 재시도 정책)
             ↑ 여기서 하네스가 바뀌면 같은 모델도 점수가 달라진다

하네스(harness)는 모델에게 어떤 도구를 어떤 형식으로 주고, 실행 결과를 어떻게 되돌려주고, 언제 멈추게 하는지를 정의하는 껍데기입니다. 같은 두뇌라도 이 껍데기가 다르면 터미널 작업 완료율이 달라집니다. 그래서 서로 다른 하네스로 측정된 모델 점수를 나란히 놓고 "누가 더 낫다"고 단정하는 것은 위험합니다. 자세한 배경은 모델보다 Harness가 결과를 바꾸는 순간에서 다뤘습니다.

하네스를 만드는 팀에게: 프롬프트 인코딩이 바뀌었다

이번 릴리스에서 실무적으로 중요한 변화가 하나 있습니다. 1017은 Jinja 형식의 채팅 템플릿을 포함하지 않습니다.

대신 두 가지를 함께 제공합니다.

1) encoding/encoding.py — 자체 완결형 참조 구현
   · 다중 턴 대화
   · 도구 호출(tool calling)
   · thinking 모드
   · 숫자형 reasoning effort
   · 대화 중간의 system 메시지
   · 이미지가 섞인 멀티모달 입력
   위 케이스에 대한 테스트 포함

2) deepseek-recipe — 프로토콜을 아는 Rust 라이브러리(파이썬 바인딩)
   · Messages / Chat Completions / Responses API 요청을
     Conversation 형식으로 변환
   · V4·V4.1 프롬프트 또는 토큰 ID로 인코딩
   · 모델 출력을 완전한(또는 스트리밍) 응답으로 파싱
     (thinking, 도구 호출, 이미지, 생성 설정 포함)

왜 이게 중요할까요. 에이전트 하네스의 품질은 "프롬프트를 모델이 기대하는 형식과 정확히 일치시키는가"에 크게 좌우됩니다. 채팅 템플릿을 직접 관리하던 팀은 이제 공식 인코더를 쓸 수 있고, 그 대신 모델·서버 쪽에 대한 의존이 생깁니다. 어느 쪽이든, 도구 호출 형식이 바뀌면 벤치마크 점수도 흔들립니다.

스펙을 짚고 가자

1017은 아키텍처를 바꾼 릴리스가 아니라 V4.1 Flash 계열의 학습·후처리 업데이트입니다. 계열의 기본 스펙은 이렇습니다.

DeepSeek V4.1 Flash 계열 (공식 카드·커뮤니티 집계)

- 백본: 552B 파라미터 MoE
  (여기에 196B 규모의 Engram 조건부 메모리가 더해져
   일부 집계에서는 합산 약 748B로 표기됨)
- 활성 파라미터: prefill 8B / decode 16B
- 컨텍스트: 최대 1M 토큰
- 최대 출력: 256K 토큰 이상
- KV 캐시: 토큰당 약 890바이트
- 성격: 텍스트 + 이미지 입력, 텍스트 출력 (멀티모달)
- 라이선스: MIT
- 추천 샘플링: temperature 1.0, top_p 1.0

1M 컨텍스트와 MIT 라이선스는 그대로 유지됩니다. 즉 이번 업데이트의 실질은 "같은 그릇에 더 잘 채워 넣은 것"입니다.

전: 그래서 어떻게 써야 하나

세 가지 함정을 짚고 마무리하겠습니다.

첫째, 하네스 종속입니다. 앞서 봤듯 점수는 하네스의 함수입니다. 내가 쓰는 하네스가 벤치마크와 다르면, 벤치마크 순위가 내 작업 성능을 보장하지 않습니다. 벤치마크를 읽는 일반 원칙은 AI 벤치마크, 어떻게 읽어야 할까에 정리해 두었습니다.

둘째, 자기 발표라는 점입니다. 표의 모든 값은 DeepSeek가 측정해 공개한 값입니다. 측정 조건이 공개됐다는 점은 신뢰를 높이지만, 독립 검증과는 다릅니다. 특히 벤치마크 버전이 바뀌면 점수 자체가 달라지므로, 이전 글의 숫자와 직접 비교할 때는 주의해야 합니다(벤치마크 버전에 따라 점수가 바뀌는 이유).

셋째, 개선 폭의 착시입니다. 31.2에서 42.3은 큰 폭이지만, 이 벤치마크가 얼마나 포화됐는지, 어떤 과제로 구성됐는지에 따라 체감은 달라집니다. 숫자는 방향을 알려줄 뿐 크기를 보장하지 않습니다.

결론: 비교는 '같은 조건'에서만 의미가 있다

브리핑의 액션을 그대로 실험으로 옮기면 이렇습니다.

[1017 vs 이전 버전, 공정 비교 미니 프로토콜]

1. 내 저장소에서 실제 작업 10개를 고른다
   (버그 수정, 테스트 추가, 리팩터링, 문서 갱신 등)

2. 두 모델을 같은 조건에서 돌린다
   [ ] 같은 하네스 (예: Claude Code 또는 자체 하네스)
   [ ] 같은 도구 정의와 프롬프트 형식
   [ ] 같은 재시도 정책, 같은 타임아웃
   [ ] 같은 reasoning effort

3. 네 가지를 기록한다
   [ ] 작업 완료율
   [ ] 총 토큰 수 (입력·출력 분리)
   [ ] 작업 하나당 비용($)
   [ ] 사람 손이 들어간 횟수와 시간

4. 결론은 '성공 1건당 비용'으로 낸다

핵심은 이 문장으로 요약됩니다.

모델 성능은 모델 카드에 있고,
실제 성능은 하네스에 있다.

새 버전이 나올 때마다 "더 좋아졌다"는 말에 흔들리지 않으려면, 내 작업·내 하네스·내 비용 기준으로 직접 재는 습관이 결국 가장 빠른 길입니다. 1017은 그 측정을 시작하기 좋은 변곡점입니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

"같은 모델을 다른 하네스에 얹으면 결과가 달라진다"는 감각은 직접 루프를 설계해 볼 때 가장 빨리 붙습니다. 도구 정의, 실행 순서, 검증 지점을 손으로 짜보면 벤치마크 숫자가 왜 그렇게 흔들리는지 몸으로 이해하게 됩니다.