DeepSeek V4 Preview는 V3.2와 무엇이 다를까

DeepSeek V4 Preview는 분명 큰 업그레이드 후보입니다. 다만 “V4가 항상 V3.2보다 낫다”는 식으로 단순하게 받아들이기보다는, 내가 운영하는 서비스의 프롬프트·지연시간·비용·품질 기준에서 다시 검증해야 합니다. 공식 V4 Preview 공지, V3.2 릴리스, API 문서를 기준으로 보면 핵심 차이는 다섯 가지입니다. 긴 컨텍스트, 모델 라인업 분리, 에이전트형 코딩, 벤치마크 해석, 그리고 API 전환 계획입니다.

한눈에 보는 차이

항목	DeepSeek V3.2	DeepSeek V4 Preview	업그레이드 관점
릴리스 상태	DeepSeek-V3.2는 2025년 12월 1일 릴리스로 올라와 있습니다.	DeepSeek-V4는 2026년 4월 24일 변경 로그와 별도 Preview Release 페이지에 등장합니다.	V4가 더 최신이지만, 이름 그대로 preview로 보고 검증하는 편이 안전합니다.
주된 초점	V3.2는 reasoning, thinking, tool-use를 결합한 에이전트 활용에 초점이 맞춰져 있습니다.	V4는 1M 토큰 컨텍스트, V4-Pro/V4-Flash 2개 라인, agentic coding을 강조합니다.	대형 코드베이스, 긴 문서, 여러 단계의 에이전트 작업에서 먼저 시험해볼 만합니다.
긴 컨텍스트	DeepSeek-V3.2-Exp는 긴 컨텍스트에서 학습·추론 효율을 높이기 위한 DeepSeek Sparse Attention을 소개했습니다.	V4 Preview는 1M 토큰 컨텍스트를 핵심 특징으로 내세웁니다.	한 번의 호출에 많은 문맥을 넣어야 하는 애플리케이션에서 의미가 큽니다.
모델 라인업	변경 로그에는 DeepSeek-V3.2와 DeepSeek-V3.2-Speciale가 표시됩니다.	V4는 DeepSeek-V4-Pro와 DeepSeek-V4-Flash로 나뉩니다.	고성능 후보와 경량·효율 후보를 나눠 실험하기 쉽습니다.
API 영향	API 문서에서는 deepseek-chat과 deepseek-reasoner가 DeepSeek-V3.2에 대응한다고 설명합니다.	V4 Preview는 두 별칭이 현재 deepseek-v4-flash로 라우팅되며 2026년 7월 24일 15:59 UTC 이후 중단된다고 안내합니다.	기존 별칭에 장기 의존하면 모델 동작이 의도치 않게 바뀔 수 있습니다.

1. 가장 눈에 띄는 변화는 1M 토큰 컨텍스트

DeepSeek V4 Preview의 가장 큰 표면적 변화는 1M 토큰 컨텍스트입니다. 애플리케이션 관점에서는 한 번의 모델 호출에 대량의 저장소 파일, 긴 기술 문서, 시스템 로그, 긴 대화 이력, 여러 단계의 에이전트 작업 맥락을 넣어야 할 때 의미가 큽니다.

다만 긴 컨텍스트가 V4에서 처음 시작된 것은 아닙니다. 앞서 DeepSeek-V3.2-Exp는 긴 컨텍스트에서 더 빠르고 효율적인 학습·추론을 위한 DeepSeek Sparse Attention을 도입했다고 설명했습니다. 따라서 정확한 해석은 이렇습니다. V3.2-Exp가 긴 컨텍스트 효율화의 중요한 실험 축이었다면, V4는 이를 새 세대 모델의 중심 기능으로 끌어올린 버전입니다.

2. V4-Pro와 V4-Flash로 “성능형”과 “효율형”을 나눠 보기 쉬워졌다

V3.2 세대에서 DeepSeek는 변경 로그에 DeepSeek-V3.2와 DeepSeek-V3.2-Speciale를 올렸습니다. V4 Preview에서는 라인업이 DeepSeek-V4-Pro와 DeepSeek-V4-Flash로 정리됩니다.

V4 Preview 페이지에 따르면 V4-Pro는 총 1.6T 파라미터, 49B active parameters를 갖고, V4-Flash는 총 284B 파라미터, 13B active parameters를 갖습니다. 실무적으로는 평가 방식이 더 명확해집니다. 어려운 추론이나 고품질 응답이 중요한 작업에는 V4-Pro를, 요청량이 많고 지연시간·비용·처리량의 균형이 중요한 작업에는 V4-Flash를 비교 후보로 둘 수 있습니다.

다만 모델 이름만 보고 기본 모델을 바꾸는 것은 위험합니다. 같은 프롬프트, 같은 데이터, 같은 토큰 제한, 같은 채점 기준으로 V3.2, V4-Flash, V4-Pro를 함께 돌려본 뒤 결정하는 편이 낫습니다.

3. 에이전트형 코딩이 더 큰 전면 과제가 됐다

DeepSeek V3.2도 에이전트 관점에서는 중요한 릴리스였습니다. V3.2 릴리스는 thinking과 tool-use의 결합을 강조합니다. 즉 V3.2는 한 번에 답을 생성하는 모델이라기보다, 추론하고 도구를 호출하고 결과를 읽은 뒤 다음 단계를 이어가는 워크플로까지 염두에 둔 모델로 제시됐습니다.

V4 Preview는 이 방향을 이어가면서도 agentic coding, 즉 에이전트형 코딩을 더 강하게 내세웁니다. 여기서 말하는 에이전트형 코딩은 짧은 코드 조각 하나를 생성하는 수준이 아니라, 코드 문맥을 읽고 계획을 세우고 수정하며 여러 단계를 조율하는 흐름에 가깝습니다.

따라서 차이를 “V3.2는 에이전트를 못 하고 V4부터 가능하다”로 보면 곤란합니다. 더 적절한 정리는 이렇습니다. V3.2는 reasoning과 tool-use 기반을 다졌고, V4는 그 흐름을 긴 컨텍스트와 코딩 에이전트 워크플로 쪽으로 확장하려는 Preview입니다.

4. 벤치마크는 신호이지 성능 보증서가 아니다

DeepSeek는 V3.2 Release와 V4 Preview Release 모두에서 벤치마크와 성능 포지셔닝을 제시합니다. 공식 자료 외에도 DeepSeek V3부터 V3.2까지를 다룬 외부 기술 분석은 V3.2의 성능과 open-weight 제공을 주목할 만한 점으로 평가했습니다.

하지만 현재 근거의 성격을 구분해야 합니다. 여기서 확인할 수 있는 자료는 주로 릴리스 노트, API 문서, 공개 정보를 바탕으로 한 기술 분석입니다. 업그레이드 방향을 잡는 데는 유용하지만, 실제 운영 워크로드에서의 내부 벤치마크를 대체하지는 못합니다.

운영 환경에서 중요한 질문은 따로 있습니다. 내 프롬프트, 내 데이터, 내 토큰 예산, 내 지연시간 SLA, 내 품질 기준에서 어떤 모델이 더 나은가입니다. 이 질문에 대한 측정이 끝나지 않았다면 V4는 강력한 시험 후보이지, 즉시 기본값으로 바꿔야 하는 결론은 아닙니다.

5. API 변경은 반드시 점검해야 한다

V4에서 가장 실무적인 주의점은 모델 호출 방식입니다. DeepSeek는 V4 Preview에서 deepseek-chat과 deepseek-reasoner가 현재 deepseek-v4-flash의 non-thinking/thinking 모드로 라우팅되고 있으며, 두 별칭이 2026년 7월 24일 15:59 UTC 이후 완전히 중단된다고 공지했습니다.

이 점이 중요한 이유는 기존 API 문서에서 deepseek-chat과 deepseek-reasoner가 DeepSeek-V3.2에 대응한다고 설명했기 때문입니다. 운영 시스템이 구체적인 모델 ID가 아니라 별칭(alias)을 호출하고 있다면, 모델 동작이 팀이 통제하지 않는 방식으로 달라질 수 있습니다.

통합 측면에서는 DeepSeek API가 OpenAI와 호환되는 API 형식을 사용한다고 안내합니다. 엔드포인트 설정을 바꾸면 OpenAI SDK나 OpenAI API 호환 소프트웨어로 DeepSeek API에 접근할 수 있다는 설명입니다. DeepSeek는 Anthropic API 호환 문서도 제공하며, 여기에는 max_tokens, stream, system, temperature, thinking 같은 필드의 지원 상태가 정리돼 있습니다.

마이그레이션 체크리스트는 최소한 다음을 포함하는 편이 좋습니다.

1. 코드베이스, 설정 파일, 시크릿을 확인해 deepseek-chat, deepseek-reasoner 또는 구체적인 모델 ID 중 무엇을 호출하는지 점검합니다.
2. reasoning을 쓰는 워크플로라면 thinking 모드와 non-thinking 모드를 모두 다시 테스트합니다.
3. 실제 데이터로 지연시간, 비용, 오류율, 타임아웃 비율, 응답 품질을 다시 측정합니다.
4. 2026년 7월 24일 15:59 UTC 전까지 기존 별칭 의존을 제거합니다.
5. OpenAI 또는 Anthropic 호환 레이어를 쓰고 있다면 지원 필드와 무시되는 필드를 다시 확인합니다.

그래서 V3.2에서 V4로 올려야 할까?

V4를 먼저 시험해볼 만한 경우는 분명합니다. 1M 토큰급 긴 컨텍스트가 필요하거나, 코딩 에이전트를 만들고 있거나, 어려운 작업에 V4-Pro를 비교해보고 싶거나, 대량 요청 워크로드에서 V4-Flash의 효율을 확인하고 싶은 경우입니다.

반대로 현재 파이프라인이 안정적으로 돌아가고 있고, 1M 토큰 컨텍스트가 당장 필요하지 않으며, 운영 환경 변경 전에 내부 벤치마크를 더 쌓아야 한다면 V3.2를 임시 기준선으로 유지하는 선택도 합리적입니다.

짧게 정리하면, V3.2는 reasoning과 tool-use에서 중요한 단계였고 V4 Preview는 긴 컨텍스트, V4-Pro/V4-Flash 라인업, 에이전트형 코딩으로 이어지는 다음 단계입니다. 기술팀이 특히 놓치지 말아야 할 부분은 모델 품질만이 아닙니다. 기존 API 별칭에서 언제, 어떻게 빠져나올지까지 함께 계획해야 합니다.