멀티모달 입력 실무 — 이미지 토큰 과금과 문서 처리
스크린샷·PDF·차트를 모델에 넣기 전에 연다. "이 이미지가 토큰을 얼마나 먹고, 어떻게 넣어야 안 깨지나"에 답한다.
핵심: 해상도가 곧 비용
이미지는 텍스트로 변환되어 입력 토큰으로 과금된다. 픽셀 수가 토큰 수를 결정하므로, 해상도를 줄이면 곧바로 비용이 준다. 고해상도 이미지 1장은 텍스트 2,000~3,000단어(약 2,048~16,384토큰)에 맞먹고, 4K 사진 한 장이 5,000토큰을 넘기도 한다 (재확인 필요, aggregator [MED]).
프로바이더마다 토큰 산정 공식이 다르다. 크게 세 계열이다.
| 계열 | 산정 방식 | 공식 |
|---|---|---|
| Claude (면적) | 넓이 비례 | 토큰 ≈ (width × height) / 750 |
| GPT (타일) | 512×512 타일 분할 | base 85 + 타일당 ~170 |
| GPT 신세대 (패치) | 32×32 픽셀 패치 | ceil(w/32) × ceil(h/32) |
| Gemini (고정 타일) | 384/768 기준 | ≤384px 양변이면 flat 258, 크면 258 × ceil(w/768) × ceil(h/768) |
위 공식은 모두 aggregator 요약 [MED]이며, Claude의 (w×h)/750 공식은 과거 Anthropic 문서와 일치하나 2026-07 현행 여부는 1차 재확인 못 함 (재확인 필요). GPT 패치 계열의 모델명, 벤더별 정확 단가는 원자료가 미래 모델명을 섞어 써서 신뢰 불가 — 과금 메커니즘(공식)만 참고하고 단가는 인용하지 않는다.
비용 감각 (Claude 기준): 1024×1024 이미지 ≈ 1,398토큰. claude-family의 Claude Opus 5 입력가 $5/1M (verified 2026-07)로 계산하면 이미지 한 장 약 $0.007. 스크린샷 수십 장을 루프에 넣으면 이 값이 곱절로 쌓인다. 저해상도로 충분한 태스크에 원본 4K를 넣지 마라.
- GPT 계열은
detail: "low"로 넣으면 타일 계산 없이 85토큰 고정 — 대략적 판독만 필요할 때의 비용 절감 레버다 (재확인 필요). - 관련 토큰 기본기는 tokens-and-context-windows 참고.
문서·스크린샷 처리 전략
| 상황 | 권장 |
|---|---|
| UI 스크린샷 판독 | 필요한 영역만 크롭. 전체 4K를 통째로 넣지 말 것 |
| 여러 페이지 문서 | 페이지를 개별 이미지로 쪼개 필요한 것만 선별 투입 |
| 텍스트 위주 문서 | 이미지보다 추출된 텍스트가 싸고 정확 → OCR 우선 검토 |
| 표·차트·손글씨·레이아웃 | 비전 모델이 유리 (구조를 함께 읽음) |
| 대량 반복 판독 | 저해상도/detail: low로 토큰 압축 |
핵심 원칙은 "모델이 봐야 하는 최소 픽셀만 보낸다"이다. 스크린샷은 관련 영역을 크롭하고, 문서는 페이지 단위로 쪼개 선별한다. 이미지 결과를 구조화해 받고 싶으면 structured-output의 스키마 강제를 쓴다.
OCR vs 비전 모델 판단표
| 판단 기준 | OCR (전용 엔진) | 비전 모델(VLM) |
|---|---|---|
| 깔끔한 인쇄 텍스트 대량 | ✅ 싸고 빠름 | 과잉 |
| 표·차트·다이어그램 의미 해석 | ❌ 구조 못 읽음 | ✅ |
| 레이아웃·손글씨·저품질 스캔 | 약함 | ✅ (native 해상도 유지 시 정확도 유리) |
| 텍스트 추출 후 질의응답 | 추출→텍스트 파이프라인이 저렴 | 토큰 비용 급증 |
| 좌표·bounding box 필요 | OCR이 좌표 제공 | 모델 좌표 신뢰도 재확인 필요 |
전용 dynamic-tiling VLM은 원해상도를 유지해 OCR 정확도에서 유리하지만 토큰 비용이 급증하는 트레이드오프가 있다 [MED]. 텍스트만 뽑아 쓰면 되는 태스크는 OCR로 추출 후 텍스트로 넣는 편이 거의 항상 싸다. 표의 의미·차트 추세·레이아웃 관계를 읽어야 하면 비전 모델이 낫다.
최신 VLM은 dynamic resolution(원해상도 서브이미지 타일링)으로 OCR·소객체에 강하다 [MED]. 세대별 처리 차이는 openai-gpt-family · google-gemini-family 참고.
오디오·비디오 현황
원자료에 정량 수치가 부족해 정성 수준만 정리한다.
- 비디오: 프레임 샘플링(초당 N프레임)으로 뽑아 이미지 토큰처럼 과금된다는 것이 통념이나, 구체 수치는 미확인 (재확인 필요).
- 오디오: 토큰 과금 방식의 명시 수치를 원자료에서 확인 못 함 (재확인 필요).
- Anthropic 쪽 오디오·비디오 입력 지원 현황은 규격 §6 범위 밖 — 최신 anthropic-messages-api 문서로 직접 확인해야 한다.
수치를 인용해야 하면 프로바이더 1차 문서를 다시 열어 확인하라.
함정
- 다운샘플링 손실: 긴 변이 프로바이더 상한을 넘으면 자동 리사이즈된다 [MED]. 작은 글씨·가는 선·촘촘한 표는 이 과정에서 뭉개져 판독 실패로 이어진다. 상한 안에 들어오도록 미리 크롭·분할해서 세부를 살려라.
- 좌표계 어긋남: 모델이 돌려준 bounding box 좌표를 원본 이미지에 그대로 매핑하면 리사이즈·타일 분할 때문에 어긋날 수 있다. 정확한 좌표가 필요하면 OCR 좌표를 쓰거나 스케일 보정을 검증하라 (원자료 근거 없음, 재확인 필요).
- 대용량 PDF 페이지 한도: 프로바이더별 이미지/페이지 개수·총 용량 상한이 있어 대용량 PDF는 통째로 못 넣는 경우가 많다. 페이지 단위로 쪼개 선별 투입하라. 정확한 한도 수치는 프로바이더 문서 재확인 필요 (원자료 근거 없음).
- 버전 간 토크나이저 변경: 모델 버전이 오르면 같은 이미지가 더 많은 토큰으로 계산될 수 있다 [MED]. 명목 단가가 같아도 실비용이 오를 수 있으니, 마이그레이션 시 이미지 토큰 사용량을 재측정하라. (특정 모델명·배수는 원자료가 미확인 표기라 인용하지 않음.)
- 비용 폭증: 에이전트가 스크린샷을 매 스텝 찍어 넣으면 이미지 토큰이 대화 내내 누적된다. context-engineering의 컨텍스트 정리·tokens-and-context-windows의 비용 감각과 함께 관리하라.
- 환각 유발: 저품질·저해상도 이미지는 모델이 없는 내용을 지어내게 만든다 — hallucination의 근거-기반 검증을 병행하라.
참고
- tokens-and-context-windows — 이미지가 소비하는 입력 토큰과 컨텍스트 예산 기본기
- claude-family — Claude 모델별 입력 단가로 이미지 비용 환산
- google-gemini-family — Gemini 계열 이미지 타일 과금과 세대별 처리
- openai-gpt-family — GPT 타일/패치 과금 방식과
detail옵션 - structured-output — 이미지 판독 결과를 스키마로 강제해 받기
- hallucination — 저품질 이미지가 유발하는 환각 완화
출처: 이미지 과금 공식·처리 전략은 aggregator 요약 [MED], 단가는 §6(Anthropic first-party [HIGH])로 환산. 오디오·비디오·좌표·PDF 한도는 원자료 근거 부족으로 재확인 필요. 원본 → 2026-07-25-concepts-retrieval-quality