DeepSeek가 이미지 입력을 열었다: V4 Flash Vision과 Files API를 운영에 넣는 법

원문 링크: WordPress 원문

AI NOTES · KO KOREAN EDITION

KO · 한국어 / EN · English BILINGUAL PAIR

DeepSeek가 2026년 8월 21일 deepseek-v4-flash-vision-exp 를 공개하며 API 플랫폼에 이미지 입력을 추가했다. DeepSeek V4 Flash Vision은 이름 그대로 V4 Flash에 시각 입력을 붙인 실험형 멀티모달 모델이다. Chat Completions, Anthropic 호환 Messages, Responses API에서 이미지와 텍스트를 함께 받을 수 있다. 겉으로 보이는 변화는 “DeepSeek도 이미지를 본다”는 한 문장이지만, 운영팀이 실제로 다뤄야 할 변화는 더 크다. 스크린샷, 차트, 스캔 문서, 도구가 반환한 화면을 기존 텍스트·에이전트 흐름에 바로 넣을 수 있게 되면서 전송 방식, 보존 기간, 검증, 비용, 실패 시 폴백을 하나의 계약으로 묶어야 한다.

따라서 도입 질문도 달라져야 한다. “모델이 이미지를 인식하는가?”만 물으면 부족하다. “어떤 이미지가 들어오는지 추적할 수 있는가, 업로드한 파일이 언제 삭제되는가, 시각 판단이 틀렸을 때 무엇을 멈추는가, 사람 확인 없이 실행해도 되는 범위가 어디까지인가?”를 함께 물어야 한다. DeepSeek가 제품명에 붙인 exp, 즉 실험형이라는 경계는 출시 소개에만 남겨 둘 단어가 아니다. API 호환성은 개발 시간을 줄여 주지만, 특정 업무의 정확도·보안 적합성·운영 안정성을 증명하지는 않는다.

이번 출시는 이미지 처리가 에이전트 흐름 안으로 들어왔다는 뜻이다

DeepSeek는 공식 출시 발표 에서 V4 Flash Vision의 텍스트 능력이 에이전트, 추론, 세계 지식 등을 포함해 V4 Flash와 비슷하다고 설명한다. 멀티모달 에이전트 벤치마크에서는 Opus 4.8에 가까운 성능이라고도 주장한다. 다만 이 비교는 DeepSeek의 자체 발표다. 발표문에는 개별 벤치마크 이름, 점수, 평가 세트, 독립 재현 결과가 충분히 제시되지 않았다. 따라서 “특정 차트나 스크린샷 업무에서도 Opus 4.8과 비슷하다”고 확장해서 말할 수 없다.

그 경계를 지키더라도 변화의 실무적 의미는 분명하다. DeepSeek의 Vision 가이드 는 이미지를 base64, 외부 URL, Files API의 file_id 로 넣는 세 가지 경로를 문서화했다. Responses API 가이드 에서는 함수 호출이나 사용자 정의 도구가 반환한 이미지도 다음 모델 입력으로 전달할 수 있다. 화면 캡처 도구가 페이지를 찍고, 모델이 그 이미지를 읽고, 에이전트가 다음 단계를 고르는 흐름을 같은 API 안에서 구성할 수 있다는 뜻이다.

이 구조는 인터페이스 이상 징후 분류, 시각 QA, 차트 정보 추출, 문서 라우팅에 유용하다. 동시에 도구가 만든 픽셀도 신뢰하지 않은 입력으로 취급해야 한다. 잘린 화면, 오래된 캡처, 엉뚱한 창, 이미지 안의 오해를 유도하는 문구가 다음 행동에 영향을 줄 수 있다. 모델의 설명은 검증을 기다리는 관찰 후보이지, 사실 확인서나 실행 허가가 아니다.

세 API가 이미지를 받지만 동작까지 완전히 같은 것은 아니다

V4 Flash Vision은 Chat Completions, Anthropic 호환 Messages, Responses에서 동작한다. 이미 해당 형식의 클라이언트를 쓰는 팀은 새 공급자를 연결하기 쉬워진다. 하지만 ‘호환’과 ‘동일’은 다르다. 본문 블록 모양, 필요한 헤더, 페이지네이션 필드, 지원하지 않는 옵션이 서로 다르다.

Chat Completions는 사용자 메시지 안에 텍스트와 이미지 블록을 섞는다. Anthropic 호환 경로는 source 구조를 쓰며 Files API 참조에는 별도 베타 헤더가 필요하다. Responses는 input_image 를 사용하고 사용자·개발자 메시지와 일부 도구 출력에 이미지를 넣을 수 있다. 현재 DeepSeek Responses 구현은 상태를 저장하지 않으며 previous_response_id 와 대화 저장을 지원하지 않는다. 일부 미지원 필드는 오류 대신 조용히 무시된다고 공식 문서에 적혀 있다.

이 차이는 운영상 중요하다. HTTP 응답이 성공했다고 해서 요청한 모든 제어가 적용됐다고 가정하면 안 된다. 기존 애플리케이션이 의존하는 필드를 목록으로 만들고 DeepSeek 호환성 표와 대조해야 한다. 특히 상태 저장, 도구, 병렬 호출, 메타데이터에 의존하는 부분은 실제 요청 테스트가 필요하다. 공급자 어댑터는 차이를 숨겨서 모두 같은 것처럼 보이게 하기보다, 적용되지 않은 기능을 상위 애플리케이션에 명시적으로 알려야 한다.

base64·외부 URL·Files API는 편의가 아니라 거버넌스 선택이다

base64·외부 URL·Files API는 편의가 아니라 크기, 재사용, 공개 범위, 만료에 따른 선택이다.

세 입력 방식은 서로 다른 문제를 푼다. base64는 작은 로컬 이미지를 가끔 보낼 때 가장 단순하다. 이미지 바이트가 요청 안에 함께 들어가기 때문에 별도 업로드 단계가 없다. 대신 인코딩된 데이터가 48 MiB 요청 본문 한도에 포함된다. base64와 외부 URL 경로의 단일 이미지는 32 MiB를 넘을 수 없다. 요청 로그가 안전하게 관리되고 파일이 작으며 재사용하지 않는다면 base64가 합리적이다.

외부 URL은 요청 본문에 이미지 바이트를 넣지 않지만 DeepSeek 서버가 해당 주소에 접근할 수 있어야 한다. URL 길이는 최대 8,192자이고, 다운로드는 60초 안에 끝나야 하며, 이미지 하나는 32 MiB 이하여야 한다. 더 중요한 차이는 공개 범위다. 모델이 읽기 편하다는 이유로 내부 객체를 공개 주소로 바꾸면 안 된다. 만료되는 서명 URL도 로그, 추적 시스템, 진단 기록에 남을 수 있다. 외부 URL은 원래부터 외부 접근이 허용되고 수명과 노출 범위를 통제할 수 있는 객체에만 써야 한다.

Files API는 같은 이미지를 반복 사용하거나 인라인 한도를 넘는 파일을 다룰 때 적합하다. 한 번 업로드한 뒤 여러 요청에서 file_id 를 재사용한다. 이 경로의 이미지는 최대 64 MiB까지 가능하다. 요청 대역폭은 줄지만 공급자 측에 저장 객체가 생긴다. 따라서 최선의 경로는 하나가 아니다. 민감도, 크기, 재사용 횟수, 감사 요구, 삭제 정책에 따라 이미지 등급별로 미리 정해야 한다.

Files API는 파일 수명주기를 애플리케이션 책임으로 만든다

DeepSeek의 Files API 문서 는 업로드, 목록 조회, 메타데이터 조회, 삭제를 지원한다. 업로드 목적은 user_data 로 지정한다. 만료 시간은 최소 1시간에서 최대 30일까지 설정할 수 있다. 두 만료 필드를 모두 생략하면 파일은 영구 보관된다. 현재 문서상 사용자당 저장 한도는 25 GiB와 10,000개 파일이며, 파일 하나의 업로드 한도는 64 MiB다.

출시 발표는 Files API를 무료라고 표현한다. 이는 파일 서비스에 관한 설명이지 이미지 추론이 무료라는 뜻이 아니다. 모델이 파일을 참조하면 이미지는 입력 토큰으로 바뀌고 과금된다. 별도 저장 비용이 보이지 않더라도 보존 기간과 삭제 책임은 사라지지 않는다.

안전한 구현은 실수로 만료 값을 빼는 일이 없도록 해야 한다. DeepSeek가 만료 필드를 선택 사항으로 두더라도 내부 요청 스키마에서는 필수로 만들 수 있다. 내부 원본 ID, file_id, 생성 시각, 사용 목적, 만료 시각, 삭제 확인값을 함께 저장해야 한다. 업무 종료와 함께 삭제해야 하는 정책이라면 삭제 API를 호출한 뒤 반환 상태까지 확인한다. 영구 보관은 누락된 기본값이 아니라 별도 승인과 기록이 필요한 예외가 되어야 한다.

스크린샷과 스캔 문서는 특히 주의가 필요하다. 선택한 사람이 미처 보지 못한 이름, 계정 식별자, 내부 URL, 알림, 개인 정보가 모서리나 배경에 들어갈 수 있다. 데이터 분류는 모델 처리 후가 아니라 업로드 전에 해야 한다. 필요 영역만 자르되, 잘라낸 위치와 원본의 관계도 증거 추적이 필요한 업무에서는 보존해야 한다.

이미지 토큰 상한은 비용을 보여 주지만 품질을 예측하지는 않는다

DeepSeek는 추론 전에 모든 이미지를 자동으로 리사이즈한다. 전체 픽셀이 대략 384×384보다 작은 이미지는 종횡비를 유지하며 키우고, 큰 이미지는 전체 픽셀이 대략 800×800 수준이 되도록 줄인다. 문서상 이미지 하나의 입력 토큰 상한은 384개다. 여러 이미지를 보내면 각 이미지를 독립적으로 계산한다.

상한을 이용한 비용 예시는 투명하게 계산할 수 있다. 이미지 100장에 장당 384토큰을 적용하면 이미지 입력은 38,400토큰이다. 이 글을 준비할 때 DeepSeek 가격 페이지 에 표시된 V4 Flash Vision 캐시 미스 입력 단가를 적용하면 이미지 부분은 비혼잡 시간 0.008448달러, 혼잡 시간 0.016896달러다. 텍스트 입력과 출력 토큰은 포함하지 않은 값이다. 실제 이미지 토큰은 크기와 리사이즈 결과에 따라 달라지며, DeepSeek는 가격을 조정할 수 있다고 명시한다. 따라서 이 수치는 청구서 예측이 아니라 계산 구조를 보여 주는 예시다.

낮아 보이는 단가는 대량 묶음 전송을 부추길 수 있다. 공식 최대치는 요청당 이미지 600장이지만, 이는 권장 작업량이 아니라 API 상한이다. 이미지가 많아지면 어느 이미지에서 나온 답인지 모호해지고, 위치 특정이 약해지며, 한 번 실패했을 때 재시도 범위가 커질 수 있다. 결정을 지지하는 최소 시각 단위부터 시작하고, 각 이미지에 안정적인 ID를 붙이며, 출력이 근거 이미지 ID를 반환하도록 설계하는 편이 낫다.

비용 평가에는 품질 비용도 포함해야 한다. 토큰이 싼 오독이 긴 사람 조사나 잘못된 자동 행동을 만들면 전체 비용은 싸지 않다. 토큰 사용량과 함께 수정 시간, 오탐률, 보류율, 사람 검토량을 측정해야 한다.

시각 에이전트에는 텍스트 채팅보다 강한 검증 루프가 필요하다

시각 에이전트는 캡처, 모델 판단, 구조 검증, 사람 승인과 폴백을 하나의 루프로 묶어야 한다.

운영 가능한 루프는 캡처, 모델 해석, 스키마 검사, 영향도에 따른 사람 검토, 검증된 폴백의 다섯 단계로 나눌 수 있다. 각 단계에는 오케스트레이터가 이해할 수 있는 실패 상태가 있어야 한다.

캡처 단계는 출처를 남긴다. 어느 시스템에서 언제 가져왔는지, 페이지나 화면의 어느 위치인지, 원본 크기와 변환 내역이 무엇인지 기록한다. 글자가 많은 이미지를 공급자 리사이즈 전에 무심코 축소하면 정보가 두 번 줄어들 수 있다. 차트나 화면 상태가 중요한 증거라면 원본을 조직의 증거 보존 정책에 따라 별도로 유지한다.

모델 출력은 업무별 구조로 제한한다. 스크린샷 분류라면 화면 종류, 실제로 보이는 경고 문구, 신뢰도, 사람 검토 필요 여부가 포함될 수 있다. 차트 추출이라면 계열명, 단위, 기간, 값, 읽을 수 없음 상태가 필요하다. JSON 형태가 맞는다는 것은 답의 모양이 맞다는 뜻일 뿐, 픽셀을 정확히 읽었다는 뜻은 아니다.

그래서 가능한 경우 독립 신호와 비교해야 한다. OCR로 화면 글자를 확인하고, DOM이나 접근성 트리로 인터페이스 라벨을 확인하며, 원본 표로 차트 값을 확인할 수 있다. 파일 메타데이터는 페이지 순서를 검증한다. 두 경로가 다르면 그럴듯한 쪽을 자동 선택하지 말고 보류해야 한다.

사람 검토는 “필요하면 한다”는 문구보다 구체적이어야 한다. 메시지 전송, 계정 변경, 금융·의료 해석, 데이터 삭제, 공개 주장처럼 영향이 큰 행동 전에 승인을 요구한다. 낮은 위험의 분류만 대표 데이터 평가에서 정한 오류 경계를 통과한 뒤 자동화할 수 있다.

폴백도 실제로 시험해야 한다. 공급자가 이미지를 거부하거나 스키마가 깨지거나 시간 초과가 발생하거나 신뢰도가 기준보다 낮을 때 텍스트 전용 경로, OCR 전용 경로, 결정론적 파서, 사람 큐 중 하나로 넘어가야 한다. 문서에만 존재하는 폴백은 장애 대응 수단이 아니다.

도구가 돌려준 이미지는 기능과 신뢰 경계를 함께 넓힌다

Responses API는 함수 호출과 사용자 정의 도구 출력에 input_image 를 넣을 수 있다. 화면 캡처나 렌더링 도구가 이미지를 만들고 모델이 바로 읽은 뒤 흐름을 이어 가는 패턴이다. 브라우저 상태 분석, 보고서 시각 QA, 화면 기반 디버깅에서 연결 코드를 줄일 수 있다.

그러나 승인된 도구가 만들었다고 해서 출력 이미지까지 신뢰할 수 있는 것은 아니다. 스크린샷에는 제3자가 제어하는 페이지 내용이 포함될 수 있다. 렌더링 문서에는 오해를 부르는 지시가 들어 있을 수 있다. 캡처가 오래됐거나 잘렸거나 다른 창을 찍었을 수도 있다. 이미지 안의 문구를 시스템 지시보다 높은 우선순위로 올려서는 안 된다.

각 이미지를 생성한 도구 호출 ID와 결박하고, 확장자보다 실제 바이트로 미디어 형식을 확인하며, 예상하지 않은 출처·리디렉션·크기를 거부해야 한다. 관찰과 행동도 분리한다. 한 단계에서는 화면에 무엇이 보이는지만 구조화하고, 정책 계층이 그 관찰이 다음 도구 호출에 충분한지 판단한다. 영향이 큰 행동은 두 번째 독립 신호나 사람 확인을 요구한다.

DeepSeek 문서상 Responses의 이미지는 사용자·개발자 메시지와 일부 도구 출력에서 허용되지만 시스템·어시스턴트 메시지 위치에서는 오류가 난다. 클라이언트나 SDK가 바뀌었을 때 시각 문맥이 조용히 빠지거나 다른 위치로 이동하지 않도록 제한 조건을 회귀 테스트에 넣어야 한다.

운영 전에는 실제 업무 이미지로 그림자 평가를 해야 한다

일반 벤치마크는 조직이 가진 차트, 서식, 인터페이스를 정확히 읽는지 답하지 못한다. 도입하려는 업무에서 작고 대표적인 평가 세트를 만들어야 한다. 민감 정보는 제거하거나 통제하고, 원본을 보존하며, 모델을 실행하기 전에 기대 답을 정한다.

평가 세트에는 정상 사례뿐 아니라 실패가 중요한 사례가 포함돼야 한다. 작은 글자, 빽빽한 표, 잘린 스크린샷, 다크 모드, 특이한 종횡비, 여러 이미지, 회전된 스캔, 불필요한 오버레이, 정답이 “정보 부족”인 이미지가 필요하다. 추출 정확도와 의사결정 정확도도 따로 본다. 라벨을 맞게 읽고도 운영 상태를 잘못 해석할 수 있기 때문이다.

정확히 일치해야 하는 필드, 허용 오차가 있는 숫자, 근거 없는 단정, 보류, 지연 시간, 토큰, 사람 수정 시간을 기록한다. 전체 평균 하나로 뭉개지 말고 이미지 유형별 결과를 분리한다. 깨끗한 화면에서의 높은 점수가 차트나 스캔 실패를 가리면 안 된다.

첫 단계는 그림자 모드가 적합하다. 모델 답을 기록하되 행동을 일으키지 않고 기존 경로와 비교한다. 불일치 사례를 사람이 검토한 뒤 승인된 업무, 이미지 종류, 임계값, 보존 설정, 폴백을 명시한다. “비전 기능 활성화”는 너무 넓어서 배포 기준이 될 수 없다.

첫 배포 계약은 좁고 되돌릴 수 있어야 한다

첫 운영 범위는 오독의 결과가 제한적인 업무로 잡는 편이 안전하다. 예를 들어 장애를 자동 해결하는 대신 스크린샷을 사람 검토 큐로 분류하는 작업부터 시작할 수 있다. 요청 모델 ID를 실험형 모델로 고정하고, 요청·응답 사용량을 기록하며, 공급자 오류를 일반 성공 상태 뒤에 숨기지 않는다.

전송 정책은 이미지 등급과 연결한다. 작고 통제된 이미지는 base64, 의도적으로 접근 가능하게 만든 객체만 외부 URL, 크기나 반복 사용이 저장을 정당화할 때만 Files API를 쓴다. 업로드마다 만료 시간을 요구하고 삭제 여부를 관측 가능하게 만든다. 공급자 자격증명을 브라우저 코드나 공개 산출물에 넣어서는 안 된다.

해석 정책에는 안정적인 이미지 ID, 구조화 출력, 보류 필드, 출처별 검증을 포함한다. 불확실하거나 영향이 큰 사례는 사람에게 보낸다. 출시 전과 운영 중에 폴백을 시험한다. 모델 제한과 가격은 바뀔 수 있으므로 문서에서 읽은 값을 코드 상수로 영구 고정하지 말고 버전이 있는 구성으로 관리한다.

거버넌스에는 금지 데이터 등급, 새 이미지 출처 승인자, 추적 로그 위치, 사고 발생 시 시각 경로를 끄는 방법을 적는다. 실험형이라는 표기는 소개 문구가 아니라 배포 범위를 제한하는 운영 조건이다.

지금 팀이 실행할 다섯 단계

작게 측정하고 명시적으로 만료하며 실패 시 텍스트·사람 검토 경로로 전환한다.

첫째, 실제 업무가 다루는 이미지 목록을 만들고 민감도, 크기, 재사용 여부를 분류한다. 둘째, 개발자가 임의로 고르지 않도록 이미지 등급마다 base64·외부 URL·Files API 경로를 지정한다. 셋째, 첫 Files API 업로드 전에 만료와 삭제 확인 구조를 만든다. 넷째, 대표 평가 세트로 그림자 실행을 하고 보류·사람 검토 기준을 정한다. 다섯째, 공급자 장애와 낮은 신뢰도 상황에서 텍스트·OCR·사람 경로로 전환되는지 실제로 시험한다.

DeepSeek V4 Flash Vision은 시각 에이전트의 통합 장벽을 낮춘다. 하지만 어려운 부분을 없애지는 않는다. 캡처 출처, 파일 수명, 구조 검증, 독립 확인, 폴백을 한 운영 계약으로 연결해야 새 기능을 안전하게 시험할 수 있다. 편리한 API가 검증된 의사결정 시스템과 같다고 착각하지 않는 팀이 이 출시를 더 오래 쓸 수 있다.

Sources

• DeepSeek — DeepSeek-V4-Flash-Vision-Exp Release: Multimodal API Now Live

• DeepSeek — Vision guide

• DeepSeek — Files API guide

• DeepSeek — Models & Pricing

• DeepSeek — Responses API guide