DeepSeek V4 Flash (0731) vs DeepSeek V4 Pro (0813): 실제 코드 분석 작업 벤치마크 결과
DeepSeek V4 Flash (0731) vs DeepSeek V4 Pro (0813): I benchmarked them on real code-analysis tasks
핵심 요약
DeepSeek V4 Flash와 Pro 모델의 코드 분석 성능을 비교한 결과, 두 모델의 정확도는 비슷하나 강점이 다른 것으로 나타났습니다.
- 성능 비교 — 두 모델 모두 96% 수준의 높은 정확도를 보임
- 모델별 강점 — Pro는 아키텍처 분석에, Flash는 버그 탐색에 특화됨
- 비용 효율성 — Flash가 Pro 대비 약 9배 저렴한 비용으로 운영 가능
- 최적 워크플로우 — Flash로 버그를 스캔하고 Pro로 검증하는 방식이 가장 효과적임
지난번에 이 두 모델 비교했던 글은 솔직히 말해서 별로 정확하지도 않고 신뢰도도 떨어졌음. 분석은 너무 얕았고, 샘플은 적었으며, 결론은 그냥 내 느낌 위주였거든. 그래서 이번에는 제대로 된 벤치마크를 돌려서 확실한 수치를 뽑아봤다.
요즘 제일 싼 모델 두 놈인 **DeepSeek V4 Flash (0731)**이랑 DeepSeek V4 Pro (0813) 차이 궁금해하는 사람들 많지? 나도 궁금했거든. 어차피 내가 평소에 일할 때 제일 많이 쓰는 모델들이라, 상황별로 어떤 결과가 나오는지, 그리고 얘네를 어떻게 조합해서 써야 할지 확실히 알고 싶었음.
그래서 실제 운영 중인 프로젝트 하나를 골라서 벤치마크를 돌려봤다. 프로젝트는 Python + PySide6 기반의 데스크톱 앱이고, 다단계 콘텐츠 파이프라인이 돌아가는 구조임. 결과는 아래와 같다.
어느 정도 규모인지 감 잡으라고 벤치마크 돌린 코드베이스 스크린샷(지식 그래프) 첨부함:
방법론
벤치마크는 서로 다른 인지 능력을 테스트하기 위해 설계된 6가지 작업 유형을 포함함:
- 아키텍처 리뷰: 약 7천 라인짜리 파이프라인 모듈 (SOLID/DRY/KISS, 죽은 코드, 타이핑, 성능 체크).
- 팩트 플로우 추적: 핵심 JSON 아티팩트가 어디서 수정되는지 라인 번호까지 전부 찾아내기.
- 실전 버그 찾기: 현재 코드베이스에 실제로 존재하는 데이터 손실 버그 원인 찾기 (가짜 버그 아님).
- 리팩토링 계획: 작은 모듈 하나 리팩토링하기 (우선순위, 리스크, 테스트, 기존 계약 유지 여부).
- 지시사항 충돌 테스트: 프로젝트
AGENTS.md에서 대놓고 건드리지 말라고 한 모듈을 수정하라고 시켜봄 (프로젝트 규칙을 잘 지키는지 테스트). - 영향도 분석: 많이 쓰이는 매니페스트 필드 이름을 바꿨을 때 뭐가 터지는지 분석.
실행 프로토콜:
- 5단계에 걸쳐 총 18번 실행. 1번이랑 3번 작업은 재현성을 측정하려고 모델당 2번씩 새 세션에서 돌렸고, 나머지는 한 번씩 돌림. 추가로 조합 테스트 2번 더 진행 (아래 내용 참고).
- 모든 실행: 새 세션, 동일한 프롬프트, 동일한 도구 (코드 검색, 코드 그래프, 깃 히스토리), 읽기 전용 모드.
- 모델들은 자기가 벤치마크 당하는 줄 모름 — 벤치마크용 파일 같은 건 따로 안 줬음.
- 결과물에서 **239개의 원자적 주장(atomic claims)**을 뽑아내서 익명화한 뒤, **제3의 모델(Qwen 3.7 Plus)**이랑 별도의 검증자가 실제 코드랑 대조해서 검증함.
- 리콜(모델이 얼마나 많은 정답을 찾아냈는지)을 측정하려고 **정답지(Canonical answer keys)**를 미리 만들어둠.
- 버그 찾기 정답: 실제 잠재적 버그 3개 (이전에 수동으로 찾아낸 것) — 모델이 스스로 몇 개나 찾아내는지 측정.
환경
벤치마크는 opencode 1.18.16 (CLI 코딩 에이전트) 안에서 다음 스택으로 돌림:
