DeepSeek API, 7월 24일 이후 조용히 성능이 떨어질 수 있다
reasoner가 Flash로 몰래 매핑
DeepSeek가 7월 24일 15시59분(UTC)에 구모델을 완전히 끈다. deepseek-reasoner 별칭이 V4-Pro가 아니라 V4-Flash로만 연결돼 있어 값은 그대로인데 품질만 조용히 떨어질 수 있다.
DeepSeek가 7월 24일 15시59분(UTC)에 구모델 deepseek-chat과 deepseek-reasoner를 완전히 끈다. 마감일 자체보다 무서운 건 그 사이에 숨어 있는 별칭 매핑이다. 많은 개발자가 deepseek-reasoner를 V4-Pro로 연결한다고 생각하는데 실제로는 V4-Flash로만 이어진다. 이름만 보면 추론(reasoner)이니 상위 모델로 옮겨 갈 것 같지만 실제 라우팅은 그렇지 않다.
이 문제가 처음 알려진 건 개발자 커뮤니티에서 마이그레이션 가이드를 따라 하던 이들이 결과물 품질 저하를 뒤늦게 눈치채면서다. 가이드 자체는 틀린 정보를 담고 있지 않지만 "이름을 신버전으로 바꾸기만 하면 된다"는 인상을 주는 서술 때문에 reasoner를 Pro로 오해하는 사례가 반복해서 나왔다. 표면적인 절차와 실제 라우팅 사이의 간극이 이번 마이그레이션 전체를 관통하는 핵심 문제다.
DeepSeek는 지금까지 값싼 추론 성능으로 개발자 사이에서 입지를 넓혀 왔다. 이번 마감은 단순한 이름 정리처럼 보이지만 실제로는 그 값싼 추론을 계속 받을 수 있는지 아닌지를 가르는 분기점이다.
한눈에 보기
| 시점 | 상태 |
|---|---|
| 지금부터 7월 24일까지 | 구 별칭을 그대로 호출해도 자동으로 V4-Flash로 라우팅됨 |
| 7월 24일 15:59 UTC | deepseek-chat, deepseek-reasoner 완전 폐기, 이후 요청 전부 실패 |
| 이후 | deepseek-v4-pro, deepseek-v4-flash를 모델 파라미터에 직접 지정해야 함 |
베이스 URL과 API 키는 마이그레이션 전후로 바뀌지 않는다. 오직 요청 본문에 넣는 모델 이름 문자열 하나만 손보면 되는데 그 한 줄이 하필 가장 헷갈리는 지점이다.
에러가 안 난다는 게 진짜 문제
지금 당장 코드를 한 줄도 안 고쳐도 요청은 계속 성공한다. 그래서 마감을 여유롭게 보는 개발자가 많다. 그런데 이미 지금부터 deepseek-reasoner로 보낸 요청은 V4-Flash 등급 추론 결과를 받고 있다. 추론 품질이 필요해서 reasoner를 골랐던 사람이 사실은 진작에 Flash로 강등된 채 같은 값을 내는 중이었다는 뜻이다. 베이스 URL과 API 키는 그대로라 겉보기엔 아무 문제가 없다. 모델 파라미터 하나만 잘못 짚었을 뿐인데 결과물 품질이 통째로 바뀐다. 요청이 200으로 떨어지고 응답도 형식대로 나오니 모니터링 대시보드에는 아무 이상 신호가 잡히지 않는다. 결과물 자체를 사람이 읽고 비교하지 않는 이상 강등 사실을 알아챌 방법이 없다.
가격 구조를 보면 이 함정이 왜 더 위험한지 드러난다. V4-Flash와 V4-Pro는 토큰당 가격이 다르게 책정돼 있어서 정상적인 경우라면 더 비싼 추론을 쓰면 청구서도 그만큼 올라가야 맞다. 그런데 구 별칭으로 우회 라우팅되는 지금 구간에서는 가격도 예전 그대로 청구되면서 실제 처리 등급만 낮은 쪽으로 새어 나간다. 청구서만 보고 있으면 오히려 비용이 안정적으로 유지되는 것처럼 보이니 이상 신호를 눈치챌 단서가 하나 더 사라지는 셈이다.
누가 이 함정에 걸리나
DeepSeek의 값싼 추론 비용에 기대 에이전트 파이프라인을 짠 1인 개발자, 콘텐츠 자동화를 돌리는 AI 에이전시가 정확히 이 자리에 있다. 마이그레이션 가이드 대부분이 "이름만 바꾸면 된다"고 안내하지만 reasoner를 V4-Pro로 그대로 옮겨 적으면 틀린다. deepseek-v4-pro를 명시적으로 지정하지 않으면 코드는 멀쩡히 돌아가면서 추론 결과물만 한 단계 낮은 등급으로 계속 나온다. 배치로 돌리는 요약, 분류, 코드 리뷰 자동화 어디든 이 함정이 숨어 있을 수 있다. 특히 매일 자동으로 콘텐츠를 뽑아 발행하는 무인 파이프라인이라면 하루 이틀이 아니라 몇 주치 결과물이 통째로 한 단계 낮은 품질로 쌓일 수 있다.
DeepSeek만의 문제도 아니다. 오픈AI와 앤트로픽도 구형 모델 별칭을 주기적으로 폐기하거나 다른 버전으로 조용히 재라우팅해 왔다. API에 기대 돌아가는 자동화라면 이런 이름 변경이 정기적으로 일어난다고 전제하고 설계해야 한다. 문제는 대개 이런 폐기 공지가 개발자 문서 한구석에 짧은 안내문으로만 올라온다는 점이다. 서비스 하나를 여러 벤더 API로 엮어 돌리는 소규모 팀일수록 이런 공지를 놓치기 쉽고 그 결과가 드러나는 시점도 훨씬 늦다.
anyAX 관점
무인으로 돌아가는 파이프라인일수록 이런 사고가 더 무섭다. 서버가 죽거나 요청이 에러를 뱉으면 알림이 바로 온다. 그런데 품질이 한 단계 낮은 채로 몇 주째 조용히 돌아가는 건 결과물을 하나하나 다시 읽어보지 않는 이상 티가 나지 않는다. 자동화를 설계할 때 "실패하면 알림"은 대부분 챙기지만 "품질이 조용히 낮아지면 알림"은 빠뜨리기 쉽다. 이번 DeepSeek 마감은 딱 그 빈틈을 찌른다.
실무적으로 잡을 방법은 있다. API 응답에 실제로 어떤 모델 버전이 처리했는지 기록하는 필드가 있다면 그 값을 로그에 남기고 주기적으로 점검하면 된다. 결과물 샘플을 매주 몇 건씩 사람이 직접 읽어 품질 저하가 없는지 확인하는 절차도 도움이 된다. 비용만 보고 자동화를 짜면 비용은 관리되는데 품질은 아무도 안 보는 사각지대가 생긴다. API에 기대 돌아가는 모든 무인 파이프라인은 모델 이름을 문자열로만 체크하지 말고 실제로 어떤 버전에 연결됐는지 주기적으로 확인하는 절차가 필요하다. 저렴한 API에 의존할수록 그 저렴함이 언제 어떻게 재조정되는지 추적하는 일이 곧 사업의 신뢰도를 지키는 일이 된다.
캘린더에 마감일 하나만 적어 두는 걸로는 부족하다. 지금부터 7월 24일까지 남은 며칠 동안 모델 파라미터를 deepseek-v4-pro와 deepseek-v4-flash로 명시적으로 바꾸고 실제 응답에서 어느 버전이 처리했는지 한 번은 직접 확인하고 넘어가야 한다. 그 확인 한 번이 몇 주 뒤 결과물 품질을 둘러싼 원인 모를 불만을 막아 준다.
값싼 API를 골라 쓰는 판단 자체는 잘못이 아니다. 비용을 아끼는 건 1인 개발자와 AI 에이전시가 대기업과 경쟁할 수 있는 몇 안 되는 무기 중 하나다. 다만 그 무기를 쓰는 대가로 벤더가 조용히 바꾸는 것들을 계속 확인해야 하는 책임이 따라온다는 걸 이번 마감이 다시 확인시켜 준다. 자동화가 늘어날수록 그 확인 절차 자체도 자동화해 두는 편이 안전하다.
7월 24일이 지나면 늦다. 지금 이 글을 읽는 시점에 파이프라인 코드를 한 번 열어 모델 파라미터가 정확히 무엇으로 지정돼 있는지 확인하는 게 가장 확실한 예방이다.