DeepSeek V4-Flash-0731에서 볼 건 ‘더 큰 모델’이 아니다. 같은 계열 모델을 재학습해 도구 사용과 코딩 같은 에이전트 작업을 개선했다는 점이다. 벤치마크 점수만 보기보다 내 작업 흐름에서 이전 버전과 직접 비교해야 한다.
모델 선택의 단위가 더 작아졌다
7월 31일 DeepSeek는 DeepSeek-V4-Flash-0731 가중치를 공개하고 V4-Flash API 정식 버전을 공개 베타로 전환했다. Hugging Face의 공식 저장소에는 MIT 라이선스와 약 167GB 규모의 파일로 확인된다. 즉, 공개 가중치라는 말이 곧 개인 PC에서 가볍게 돌릴 수 있다는 뜻은 아니다. 하지만 API로는 비교적 쉽게 시험할 수 있고, 필요하다면 자체 인프라에 배포할 수 있는지도 검토해 볼 수 있다.
내가 이번 업데이트에서 눈여겨본 건 모델의 구조와 크기를 바꾼 릴리스가 아니라는 점이다. TechNode가 DeepSeek API 문서를 인용해 정리한 내용에 따르면, 0731은 미리보기 버전과 같은 구조·크기를 유지하면서 재학습됐고, 변경 범위는 V4-Flash API다. V4-Pro API나 DeepSeek 앱·웹에 쓰이는 모델이 함께 바뀐 것은 아니다.
AI를 도입할 때 우리는 종종 ‘새 모델 출시’만 사건으로 인식한다. 하지만 실제 운영비와 품질을 바꾸는 것은 추론·도구 호출·코딩 과제에 맞춘 후속 학습일 수 있다. 모델 이름이 크게 바뀌지 않아도, 에이전트가 실패하는 지점이 달라질 수 있다는 뜻이다.
재학습과 API 호환성, 외부 평가
공개 자료에서 확인할 수 있는 내용은 다음과 같다.
- 공식 공개: DeepSeek의 Hugging Face 조직은 V4-Flash-0731 저장소를 공개했다. 저장소에는 MIT 라이선스와 모델 파일, 설정 파일, 모델 카드가 제공된다.
- 제품 범위: 공개 베타가 된 것은 V4-Flash API이며, Responses API 지원과 Codex 적응이 추가됐다. Responses API는 단순히 텍스트 한 번을 주고받는 방식보다 도구 호출과 여러 단계의 응답 상태를 다루도록 설계된 인터페이스다. 기존 에이전트 프레임워크를 옮길 때도 ‘모델이 좋아졌다’보다 요청·응답 형식, 도구 호출, 오류 처리의 호환성을 따로 확인해야 한다.
- 독립 평가: Artificial Analysis는 해당 모델의 Intelligence Index를 50점으로 기록했고 이전 V4-Flash의 40점보다 10점 높다고 보고했다. 이 기관의 설명상 일부 에이전트·현실 작업 평가도 개선됐다. 다만 이 수치는 그 기관의 과제 구성과 채점 방식에 대한 결과이지, 모든 조직의 업무 품질을 보증하는 점수는 아니다.
벤치마크 숫자는 그대로 받아들이면 안 된다. 반복 가능한 비교에는 유용하지만, ‘우리의 고객 문의 분류가 좋아지는가’, ‘배포 스크립트의 위험한 변경을 줄이는가’, ‘사내 문서를 근거와 함께 답하는가’와 같은 질문을 그대로 대신해 주지 않는다. 또한 다른 매체에서 인용하는 벤치마크 수치가 평가 버전·설정에 따라 달라질 수 있으므로, 숫자 하나만으로 모델 교체를 결정하면 안 된다.
‘재학습’이 실무에서 뜻하는 것
재학습은 기존 기본 모델의 구조를 완전히 바꾸지 않고, 추가 데이터와 피드백으로 특정 행동을 조정하는 과정이다. 에이전트 맥락에서는 다음 같은 차이가 나타날 수 있다.
- 도구를 호출해야 할 때와 답변만 해도 될 때를 더 잘 구분한다.
- 코드를 수정한 뒤 테스트·로그·오류 메시지를 다시 읽는 순서가 더 안정적일 수 있다.
- 긴 작업에서 중간 결과를 잃지 않고 다음 단계로 넘기는 능력이 나아질 수 있다.
다만 재학습이 곧 성능 향상을 보장하지는 않는다. 재학습이 어떤 업무에는 이득이지만 다른 업무에서는 형식이나 말투, 예외 처리, 한국어 문서의 근거 연결을 바꿀 수도 있다. 같은 모델 계열 안의 교체도 회귀 테스트가 필요한 이유다.
앞서 공개한 가중치의 규모도 현실적인 제약이다. 저장소가 약 167GB로 표시되는 모델을 직접 내려받아 운영하려면 디스크만이 아니라 추론 서버, 메모리·가속기 구성, 배포와 관찰 체계까지 검토해야 한다. 소규모 팀이나 개인 학습자에게는 먼저 API 샌드박스에서 과제를 비교하는 편이 더 안전하고 비용도 예측하기 쉽다.
도입 판단은 ‘점수표’가 아니라 작은 평가 세트에서
이번 릴리스를 보면서 모델 평가 방식부터 다시 생각해 봤다. 한 번의 프롬프트 대결보다 업무 흐름 전체의 품질을 봐야 한다. 예를 들어 코딩 에이전트를 쓰는 팀이라면 성공한 코드 생성만 세지 말고, 다음 항목을 함께 기록할 수 있다.
- 요구사항을 놓치지 않고 필요한 파일만 바꿨는가
- 테스트 실패 뒤 원인을 추적하고, 검증 없이 수정 완료라고 말하지 않았는가
- 외부 명령·배포·삭제처럼 되돌리기 어려운 행동 전에 멈추거나 승인을 요청했는가
- 성공까지 걸린 시간뿐 아니라 재시도 횟수와 사람의 검토 시간을 줄였는가
이 기준은 특정 공급자에만 해당하지 않는다. 낮은 비용이나 높은 벤치마크 점수는 후보를 좁히는 신호일 뿐, 실제 도입의 근거는 아니다. 특히 공개 모델과 API 모델을 함께 검토한다면 데이터가 어디로 가는지, 호출량 제한은 무엇인지, 모델 버전이 고정되는지까지 별도로 확인해야 한다.
직접 비교해 보는 방법
1. 기존 과제 10개로 전·후 버전을 비교한다
새 데모 프롬프트를 만들기보다, 이미 실패 이력이 있는 과제와 성공해야 하는 과제를 섞어 10개 정도 고른다. 각 과제에 입력, 기대 결과, 도구 사용 허용 범위, 사람이 확인할 항목을 적는다. 기존 모델과 0731을 같은 조건에서 실행해 성공률만이 아니라 위험한 행동·근거 누락·재시도도 기록한다.
2. Responses API 전환은 인터페이스 테스트로 분리한다
새 API를 쓴다면 모델 품질 평가와 연결 규격 전환을 한 번에 하지 않는 편이 좋다. 먼저 도구 호출 결과, 타임아웃, 재시도, 대화 상태 보존, 오류 로그가 기존 운영 방식과 맞는지 작은 샌드박스에서 확인한다. 모델의 장점처럼 보였던 것이 사실은 클라이언트 구현 차이였는지 분리할 수 있다.
3. 로컬 배포 논의에는 총비용 표를 붙인다
MIT 라이선스와 공개 가중치는 선택지를 넓히지만 운영을 공짜로 만들지는 않는다. 저장 공간, 가속기, 전력, 관찰 도구, 업데이트와 보안 패치, 담당 시간까지 포함한 표를 만든다. 그 뒤 API 사용료와 비교하면 ‘직접 운영’이 학습 실험인지, 실제 비용 절감인지 더 분명해진다.
내가 가져갈 기준
DeepSeek V4-Flash-0731 사례를 보면 같은 계열 모델도 재학습 뒤 에이전트의 행동이 달라질 수 있다. 공개 베타와 외부 벤치마크만으로는 도입을 결정하기 어렵다. 내 작업에서 허용할 실패와 비용을 먼저 정한 뒤 작은 비교 평가를 해보는 편이 낫다. 모델이 자주 바뀌어도 이 기준은 그대로 남는다.