모델 이름은 그대로인데 운영 계약은 바뀌었다: DeepSeek V4 Pro GA를 읽는 법

원문 링크: WordPress 원문

AI NOTES · KO KOREAN EDITION

KO · 한국어 / EN · English BILINGUAL PAIR

2026년 8월 13일 딥시크는 DeepSeek-V4-Pro-0813을 정식 출시(GA)했다. 여기서 정작 눈에 띄는 것은 “더 강해진 모델”이라는 문구가 아니라, API를 호출하는 이름 deepseek-v4-pro 가 그대로 유지된다는 문장이다. 이름이 고정된 채로 실제 모델 버전, 추론 강도 기본값, 지원 프로토콜, 가격 구조, 캐시 격리 규칙이 동시에 움직인다면, 그 요청을 운영하는 쪽이 해야 할 일은 “새 모델 써보기”가 아니라 “바뀐 운영 계약을 다시 읽기”다. 이 글의 결론은 단순하다. V4 Pro GA는 성능 발표가 아니라 운영 릴리스로 취급해야 하고, 프로덕션에 반영하기 전에 별칭-버전 영수증, 프로토콜 스모크 테스트, 비용 시간대 라우팅, 사용자 단위 캐시 격리, Flash/Pro 에스컬레이션 규칙을 하나의 배포 게이트로 묶어야 한다. 이 다섯 가지를 건너뛰면, 같은 코드가 어제와 다른 비용과 다른 실패 모드로 응답하는 상황을 겪게 된다.

GA가 실제로 바꾼 것

딥시크 API 문서의 “DeepSeek-V4-Pro GA Release” (2026년 8월 13일)는 V4 Pro의 정식 출시를 알리면서 몇 가지를 동시에 명시한다. 에이전트 관련 기능이 크게 개선되었다고 밝히고, V4 Pro와 V4 Flash 양쪽에서 낮음/높음/최대(low/high/max) 세 단계의 추론 강도를 선택할 수 있다고 안내하며, Codex에 최적화된 OpenAI Responses API를 네이티브로 지원한다고 명시한다. 앱과 웹 접근은 Expert Mode를 통해 이루어지고, API에서 부르는 모델 이름은 바뀌지 않는다고도 적혀 있다. 마지막으로 8월 16일 16:00 UTC부터 피크/오프피크 가격 체계가 적용되며 오프피크 가격은 피크 가격의 50%라고 예고한다.

이 다섯 가지 항목을 나열한 이유는 각각이 서로 다른 운영 층위에 속하기 때문이다. 에이전트 기능과 추론 강도는 모델의 동작을 바꾸고, Responses API 지원은 클라이언트가 어떤 프로토콜로 통신하는지를 바꾸고, 가격 시간대는 같은 요청의 청구서를 바꾼다. 셋 중 하나만 확인하고 나머지를 어제와 같다고 가정하면 배포 이후에 문제를 발견하게 된다. 특히 “major agent upgrades”라는 문구는 정성적 표현이며, 이 글이 접근할 수 있는 출처 텍스트에는 독립적으로 검증할 수 있는 벤치마크 방법론이 함께 제시되어 있지 않다. 따라서 이 글은 성능이 실제로 얼마나 개선되었는지를 자체적으로 판정하지 않는다. 판정할 수 있는 것은 운영 계약이 바뀌었다는 사실과 그 계약을 어떻게 다뤄야 하는지이지, 벤치마크 우위가 아니다.

이 다섯 항목을 왜 “운영 계약”이라는 하나의 표현으로 묶는지도 짚어둘 필요가 있다. 계약이라는 단어를 쓰는 이유는, 각 항목이 클라이언트와 서버 양쪽이 동시에 지켜야 성립하는 약속이기 때문이다. 추론 강도는 클라이언트가 지정하지 않으면 서버 기본값이 적용되고, 도구 호출 상태는 클라이언트가 다음 요청에 되돌려주지 않으면 서버가 오류를 낸다. 가격 시간대는 클라이언트가 실행 시각을 통제하지 않으면 서버가 정한 시간대별 요율이 그대로 적용된다. 즉 이 계약의 절반은 서버 쪽 문서에, 나머지 절반은 클라이언트 쪽 구현에 놓여 있다. 문서를 읽는 것만으로는 계약의 절반만 확인한 셈이고, 실제 요청·응답을 스모크 테스트로 확인해야 나머지 절반이 채워진다.

별칭은 고정, 버전은 이동한다

“Models & Pricing” 문서는 deepseek-v4-pro 가 가리키는 실제 모델을 DeepSeek-V4-Pro-0813으로, deepseek-v4-flash 가 가리키는 모델을 DeepSeek-V4-Flash-0731로 명시한다. 여기서 핵심은 클라이언트 코드가 호출하는 문자열은 deepseek-v4-pro 로 고정되어 있지만, 그 문자열이 실제로 가리키는 학습 버전은 날짜가 박힌 스냅샷이라는 점이다. 이것은 “안정적인 별칭”이지 “불변 버전”이 아니다. 오늘 같은 이름으로 보낸 요청이 다음 갱신 이후에는 다른 가중치, 다른 기본 동작을 가진 모델로 응답할 수 있다는 뜻이다.

이 구분이 운영에 미치는 영향은 구체적이다. 회귀 테스트를 “모델 이름이 같으니 통과”로 판정하면 안 된다. 배포 파이프라인에는 응답 헤더나 API가 노출하는 버전 필드를 확인해서 실제로 어떤 날짜 스냅샷이 응답했는지 기록하는 절차, 즉 버전 영수증이 필요하다. 이 영수증이 있어야 이후 장애나 회귀가 발생했을 때 “언제부터 어떤 버전으로 바뀌었는가”를 추적할 수 있다. 별칭이 그대로라는 안내를 “아무것도 바뀌지 않았다”로 오독하는 것이 이 절에서 가장 피해야 할 실수다.

추론 강도를 라우팅 변수로 다루기

“Thinking Mode” 문서에 따르면 사고(thinking)는 기본적으로 높음(high) 강도로 켜져 있다. OpenAI 형식 클라이언트는 thinking 을 켜고 끄는 값과 reasoning_effort 를 low/high/max로 지정하는 값을 함께 쓰고, Anthropic 형식 클라이언트는 effort를 none/low/high/max로 지정하며 none은 사고를 끈다. 사고 모드가 켜진 상태에서는 temperature, top_p, presence_penalty, frequency_penalty 값을 서버가 조용히 무시한다. 이 조합은 실무에서 두 가지를 의미한다. 첫째, 같은 요청 본문을 그대로 재사용하면 추론 강도의 기본값이 바뀌는 순간 응답 길이와 지연 시간이 함께 바뀔 수 있다. 둘째, 샘플링 파라미터로 출력을 조정하던 기존 파이프라인은 사고 모드에서 그 조정이 무효화된다는 사실을 알아야 한다.

에이전트 운영의 관점에서 추론 강도는 “품질 다이얼”이 아니라 라우팅 변수로 다뤄야 한다. 짧고 결정적인 도구 호출에는 낮은 강도를, 다단계 계획이 필요한 작업에는 높은 강도를, 검증이 중요한 최종 단계에는 최대 강도를 배정하는 식으로 요청 유형별로 강도를 명시적으로 지정해야 한다. 강도를 지정하지 않고 기본값에 의존하면, 딥시크 쪽 기본값이 바뀔 때마다 자신의 파이프라인 동작도 함께 흔들린다. 에이전트 운영은 결국 모델 하나를 고르는 일회성 선택이 아니라, Flash와 Pro, 추론 강도, 검증 게이트를 연결하는 라우팅 문제로 봐야 한다.

에이전트 운영은 모델 선택 한 번이 아니라 Flash와 Pro, 추론 강도, 검증 게이트를 연결하는 라우팅 문제다.

도구 호출과 reasoning_content 상태 계약

“Thinking Mode” 문서는 도구 호출이 발생했을 때 reasoning_content 를 다음 요청에 그대로 되돌려주지 않으면 API가 400 오류를 반환한다고 명시한다. 이는 상태를 다루는 계약이며, 무시하면 멀티턴 도구 호출 체인이 중간에 끊어진다. 여기서 분명히 해둘 것은, 이 글이 설명하는 것은 숨겨진 추론 내용을 재사용자에게 노출하거나 로그로 남기라는 권고가 아니라는 점이다. reasoning_content 를 다음 요청 본문에 포함시켜야 한다는 것은 상태 전달의 기술적 요구사항일 뿐이며, 이 필드의 내용을 사람이 읽거나 저장·재현하도록 만드는 것과는 별개의 문제다.

에이전트 프레임워크를 직접 연결하는 팀이라면 도구 호출 루프를 구현할 때 이 필드를 세션 상태의 일부로 취급하고, 세션 저장소나 캐시 무효화 로직이 이 필드를 실수로 잘라내지 않는지 확인해야 한다. 특히 재시도 로직에서 요청 본문을 새로 구성할 때 이 필드가 누락되는 경우가 흔한 실패 지점이다. 400 오류가 간헐적으로 발생한다면 가장 먼저 의심할 지점이 바로 이 상태 전달 누락이다.

프로토콜 호환과 조용한 매핑

딥시크는 여러 프로토콜을 동시에 지원한다. “Integrate with OpenCode” 문서는 OpenCode 1.14.24 이상에서 DeepSeek-V4-Pro를 선택하도록 안내한다. OpenCode는 코딩 작업에 특화된 에이전트 클라이언트로, 이 안내는 딥시크가 자사 모델을 기존 에이전트/코딩 클라이언트의 백엔드로 쓰도록 의도했음을 보여준다. “Integrate with Hermes Agent” 문서는 Hermes를 Nous Research가 공개한 오픈소스 에이전트로 소개하고, 딥시크 API 기본 URL과 deepseek-v4-pro 모델로 연결하는 절차를 보여준다. 두 문서 모두 딥시크가 자체 챗 인터페이스뿐 아니라 제3자 에이전트 클라이언트의 백엔드로 쓰이는 것을 전제로 문서를 구성했다는 신호다.

더 주의 깊게 봐야 할 것은 “Using the Anthropic API” 문서다. Anthropic 호환 기본 URL은 https://api.deepseek.com/anthropic 이며, 지원하지 않는 모델 이름은 자동으로 V4 Flash로 매핑될 수 있다. 클로드 계열 이름 매핑에서는 Opus로 시작하는 이름이 V4 Pro로, Haiku·Sonnet으로 시작하는 이름이 V4 Flash로 연결된다. 이 지점에서 반드시 짚어야 할 경계가 있다. 이 매핑은 어디까지나 호환성 편의 기능이며, 클로드 형식의 이름을 요청에 넣었다고 해서 실제로 앤스로픽의 클로드 모델이 그 요청을 실행했다는 증거가 되지 않는다. 이미지, 문서, MCP 도구 사용/결과, 코드 실행 도구 결과 등 여러 필드는 이 호환 계층에서 지원되지 않거나 무시된다. 클로드 이름으로 라우팅되는 파이프라인을 딥시크로 이전하려는 팀은 이름이 통과된다는 사실과 요청이 온전히 처리된다는 사실을 반드시 분리해서 확인해야 한다.

또한 문서 간 시점 차이도 경계해야 한다. GA 발표와 가격 문서는 V4 Pro가 Responses API를 지원한다고 명시하지만, 개별 통합 안내 문서 중 일부는 더 이른 시점에 작성되어 “지원 예정”이라는 표현을 여전히 담고 있을 수 있다. 날짜가 명시된 GA·가격 문서를 더 최신 공지로 취급하되, 실제 프로덕션 라우팅에 반영하기 전에는 반드시 엔드포인트 단위의 스모크 테스트로 실제 동작을 확인해야 한다. 문서 페이지들이 서로 동기화되어 있다고 가정하는 것 자체가 위험 요소다.

100만 토큰 컨텍스트와 38.4만 출력의 경계

“Models & Pricing” 문서는 deepseek-v4-pro 와 deepseek-v4-flash 모두 100만 토큰 컨텍스트와 최대 38.4만 토큰 출력을 지원한다고 명시한다. 아울러 JSON 출력, 도구 호출, Responses API, Anthropic API, 프리픽스 완성(prefix completion), FIM(fill-in-the-middle)을 지원하며 FIM은 비사고(non-thinking) 모드에서만 쓸 수 있다고 안내한다. 이 숫자들은 API가 허용하는 상한이지, 실제 애플리케이션이 그 상한을 그대로 활용할 수 있다는 보장이 아니다. 클라이언트 쪽의 컨텍스트 압축(compaction) 로직, 요청 지연 시간 목표, 메모리 예산, 애플리케이션별 토큰 예산이 실제 사용 가능한 컨텍스트와 출력 길이를 100만 토큰과 38.4만 토큰보다 훨씬 낮게 제한하는 경우가 흔하다. 100만 토큰 컨텍스트라는 숫자를 그대로 “우리 서비스가 100만 토큰짜리 대화를 다룰 수 있다”로 번역하면 안 된다.

FIM이 비사고 모드로 제한된다는 조건도 실무에 영향을 준다. 코드 자동완성처럼 FIM을 쓰는 워크로드는 추론 강도를 명시적으로 끄거나 낮춰야 하며, 앞서 다룬 추론 강도 기본값(높음)을 그대로 두면 FIM 요청이 의도와 다르게 처리될 수 있다. 컨텍스트 상한, 출력 상한, FIM 제약은 서로 독립적인 항목처럼 보이지만 실제로는 같은 요청 설계 안에서 함께 맞춰야 하는 조건들이다.

피크/오프피크 가격 계산

가격 변경은 8월 16일 16:00 UTC부터 적용되며, 그 이전까지 문서에 나온 Pro 가격은 100만 토큰당 캐시 히트 $0.003625, 캐시 미스 $0.435, 출력 $0.87이다. 변경 이후 Pro 오프피크 가격은 캐시 히트 $0.022, 캐시 미스 $0.66, 출력 $1.98이며, Pro 피크 가격은 캐시 히트 $0.044, 캐시 미스 $1.32, 출력 $3.96이다. 피크 시간대는 01:00–04:00 UTC와 06:00–10:00 UTC로 정의되고, 그 외 모든 시간은 오프피크다. 한국 독자를 기준으로 환산하면 이 두 피크 구간은 각각 10:00–13:00 KST와 15:00–19:00 KST에 해당하고, 그 외 시간은 오프피크다. 여기서 분명히 해둘 점은 이 가격은 8월 16일 16:00 UTC 이전에는 적용되지 않는다는 것이다. 이 글을 그 시점 이전에 읽는다면, 위에 적은 오프피크·피크 가격은 “예정된” 가격이지 “현재” 가격이 아니다.

같은 V4 Pro 요청도 입력 캐시, 출력량, 실행 시간대에 따라 비용 구조가 달라진다.

가격 변화가 실제로 어떤 의미인지 확인하려면 계산이 필요하다. 캐시 미스 입력 1억 토큰, 출력 2천만 토큰짜리 가상의 배치 작업을 예로 들어 본다. 변경 이전 요금은 100 × $0.435 + 20 × $0.87 = $60.90 이다. 변경 이후 오프피크 요금은 100 × $0.66 + 20 × $1.98 = $105.60 이다. 변경 이후 피크 요금은 100 × $1.32 + 20 × $3.96 = $211.20 이다. 오프피크 요금은 피크 요금의 정확히 절반이지만, 이 워크로드 기준으로는 변경 전 요금보다 오히려 약 73.4% 더 비싸다. 피크 요금은 변경 전 요금보다 약 246.8% 더 비싸다. 이 숫자들은 “오프피크 시간대로 옮기면 무조건 할인”이라는 해석을 반박한다. 오프피크는 피크 대비 절반일 뿐, 변경 전 가격 대비 절반이 아니다. 캐시 미스 비중이 높은 배치 워크로드일수록 이 차이가 청구서에 직접 반영된다. 가격 시간대를 비용 절감 수단으로 홍보하기 전에, 자신의 실제 캐시 히트율과 워크로드 시간 분포를 이 계산식에 대입해 봐야 한다.

동시성과 사용자 격리

“Rate Limit & Isolation” 문서는 계정 단위 동시성 상한을 Pro 500, Flash 2,500으로 명시하고, 이를 초과하면 HTTP 429가 반환된다고 안내한다. 이 숫자는 계정이 동시에 처리할 수 있는 요청 수의 상한일 뿐이며, 특정 처리량이나 서비스 수준 협약(SLA)을 보장하는 값이 아니다. 500이라는 숫자를 “초당 500건을 항상 처리해준다”는 의미로 오해하면, 실제 부하 상황에서 429 오류를 마주하고서야 그 오해를 정정하게 된다.

같은 문서는 user_id 파라미터가 콘텐츠 안전, KV 캐시, 스케줄링 격리에 쓰인다고 설명한다. user_id 는 [a-zA-Z0-9\-_]+ 패턴을 따라야 하고 최대 512자이며 개인정보를 담아서는 안 된다. 멀티테넌트 서비스를 운영한다면 이 값을 실제 최종 사용자 단위로 일관되게 채워야 캐시 격리와 콘텐츠 안전 판단이 사용자별로 올바르게 분리된다. 이 값을 비워두거나 애플리케이션 단위로만 고정하면, 서로 다른 사용자의 요청이 같은 캐시·스케줄링 버킷에 섞일 수 있다. 또한 요청은 빈 줄이나 SSE 형태의 킵얼라이브 신호를 받을 수 있고, 추론이 시작되지 않은 요청은 10분 뒤 서버가 연결을 닫는다는 점도 장시간 대기가 발생하는 배치·에이전트 파이프라인에서는 타임아웃 설계에 반영해야 한다.

프로덕션 의사결정 프레임워크

지금까지 다룬 조건들을 하나의 배포 판단으로 모으면 다음과 같은 순서가 나온다. 먼저 요청을 보내기 전에 응답에 실린 버전 식별자를 기록해서 실제로 어떤 스냅샷이 응답했는지 확인한다. 다음으로 사용하려는 프로토콜(OpenAI 형식, Responses API, Anthropic 호환 형식) 각각에 대해 실제 엔드포인트로 스모크 테스트를 돌려서 문서상의 지원 여부와 실제 동작이 일치하는지 확인한다. 그다음 요청 유형별로 추론 강도를 명시적으로 지정하고 기본값에 의존하지 않는다. 도구 호출을 쓰는 경로에서는 reasoning_content 재전달 로직이 재시도·세션 저장 경로에서도 유지되는지 테스트로 검증한다. 가격 시간대는 워크로드의 실제 캐시 히트율과 실행 시간 분포를 대입해 오프피크로 옮기는 것이 실제로 이득인지, 아니면 단순히 피크 대비 절반일 뿐 변경 전보다 비싼지를 계산한다. 동시성 상한과 user_id 격리는 멀티테넌트 트래픽 설계 초기 단계에서 반영하고, 429 발생 시 재시도·큐잉 전략을 미리 마련한다.

마지막으로 Flash와 Pro 사이의 에스컬레이션 규칙을 명시적으로 둔다. 짧고 결정적인 작업, 높은 동시성이 필요한 작업은 Flash로 기본 라우팅하고, 다단계 계획·정밀도가 중요한 작업만 Pro로 에스컬레이션하는 규칙을 코드로 표현해야 한다. 이 규칙이 없으면 모든 요청이 기본값으로 Pro에 몰리면서 동시성 상한(500)에 먼저 부딪히거나, 피크 시간대 비용을 그대로 떠안게 된다. 이 다섯 가지 확인 항목(버전 영수증, 프로토콜 스모크 테스트, 비용 창 계산, 격리 키 설계, Flash/Pro 에스컬레이션)을 하나의 배포 체크리스트로 묶는 것이 이 글이 제시하는 실질적 결론이다.

한계와 확인되지 않은 것

이 글이 다루지 않거나 판정하지 않는 부분을 분명히 해둔다. “major agent upgrades”라는 문구가 실제로 어떤 벤치마크에서 얼마나 개선되었는지는 공개된 출처만으로는 독립적으로 검증할 수 없으므로 이 글은 성능 우위를 주장하지 않는다. 안정적인 모델 별칭은 불변 버전이 아니라는 점을 다시 강조한다. 가격 문서가 표시하는 실제 버전은 V4-Pro-0813이고, 클라이언트는 계속 deepseek-v4-pro 라는 이름을 부른다. 모든 프로토콜 문서가 서로 동기화되어 있다고 가정하지 않는다. GA·가격 문서가 Responses API 지원을 명시하더라도, 일부 개별 통합 문서는 더 이른 시점의 “지원 예정” 표현을 담고 있을 수 있으므로 엔드포인트 스모크 테스트가 먼저다. 앤스로픽 호환 형식 지원과 실제 앤스로픽·클로드 모델 실행을 같은 것으로 보지 않는다. 이 글은 숨겨진 사고 과정을 보존하거나 노출하라고 권하지 않으며, reasoning_content 재전달은 상태 관리 계약일 뿐이라는 선을 유지한다. 피크/오프피크 가격 변화를 전반적인 할인으로 부르지 않는다. 오프피크는 피크 가격의 절반일 뿐이며, 계산 예시에서 보였듯 변경 전 가격보다 비쌀 수 있다. 100만 토큰 컨텍스트와 38.4만 토큰 출력은 API 상한이지 모든 클라이언트에서 실사용 가능한 값이라고 약속하지 않는다. 500·2,500 동시성 수치는 처리량이나 SLA 보장이 아니라 계정 단위 상한이다. 이 글은 API 키, 자격 증명, 개인 식별 정보, 내부 경로, 단계별 비밀 설정 방법을 포함하지 않는다.

운영 전에는 별칭 버전 영수증, 프로토콜 스모크 테스트, 비용 창, 격리 키, 회귀 평가를 한 묶음으로 잠근다.

다음 행동

프로덕션에 V4 Pro GA를 반영하기 전에 실행할 수 있는 구체적인 순서는 다음과 같다. 첫째, 현재 파이프라인이 부르는 deepseek-v4-pro 응답에서 버전 식별자를 추출해 로그로 남기고, 이후 갱신 시점을 추적할 수 있는 영수증 체계를 만든다. 둘째, 실제로 사용할 프로토콜(OpenAI 형식, Responses API, Anthropic 호환)마다 최소한의 요청·응답 스모크 테스트를 작성해 문서와 실제 동작의 격차를 미리 잡아낸다. 셋째, 요청 유형별 추론 강도 매핑표를 코드 안에 명시적으로 박아 넣고, 도구 호출 경로의 reasoning_content 재전달을 통합 테스트로 검증한다. 넷째, 자신의 실제 캐시 히트율과 트래픽의 시간대 분포를 이 글의 계산식에 대입해 오프피크 라우팅이 실제로 이득인지 직접 확인하고, 8월 16일 16:00 UTC 이전에는 이 가격을 적용하지 않는다. 다섯째, user_id 격리 설계와 429 대응 재시도 전략을 멀티테넌트 트래픽 설계에 포함시키고, Flash/Pro 에스컬레이션 규칙을 코드 리뷰 대상으로 명시한다. 이 다섯 단계를 하나의 배포 게이트로 통과시킨 뒤에야 “같은 모델 이름”이 실제로 “같은 운영 조건”을 의미하는 상태가 된다.

Sources

• DeepSeek API Docs, “DeepSeek-V4-Pro GA Release” — https://api-docs.deepseek.com/news/news260813/

• DeepSeek API Docs, “Models & Pricing” — https://api-docs.deepseek.com/quick_start/pricing

• DeepSeek API Docs, “Thinking Mode” — https://api-docs.deepseek.com/guides/thinking_mode

• DeepSeek API Docs, “Rate Limit & Isolation” — https://api-docs.deepseek.com/quick_start/rate_limit

• DeepSeek API Docs, “Using the Anthropic API” — https://api-docs.deepseek.com/guides/anthropic_api

• DeepSeek API Docs, “Integrate with OpenCode” — https://api-docs.deepseek.com/quick_start/agent_integrations/opencode

• DeepSeek API Docs, “Integrate with Hermes Agent” — https://api-docs.deepseek.com/quick_start/agent_integrations/hermes