멀티모달 컨텍스트는 왜 이미지 첨부가 아니라 토큰 예산 설계일까

• 카테고리: ai_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 이미지·PDF·비디오를 LLM에 넣을 때, 우리는 어떤 해상도와 페이지·프레임을 모델에게 실제로 읽히고 있을까?
• 핵심 출처:
  • Video understanding | Gemini API - 게시일 미표기, 확인일 2026-07-14
  • Document understanding | Gemini API - 게시일 미표기, 확인일 2026-07-14
  • Images and vision | OpenAI API - 게시일 미표기, 확인일 2026-07-14
  • Vision - Claude Platform Docs - 게시일 미표기, 확인일 2026-07-14
  • PDF support - Claude Platform Docs - 게시일 미표기, 확인일 2026-07-14

1. 왜 지금 봐야 하나

LLM 앱에 이미지, PDF, 화면 캡처, 짧은 동영상을 붙이는 일은 이제 특별한 기능이 아니다. 고객지원 봇은 영수증 사진을 읽고, 사내 검색은 PDF 보고서를 분석하고, 코딩 에이전트는 스크린샷에서 UI 버그를 찾는다. 겉으로 보면 “텍스트 대신 파일도 넣을 수 있다” 정도로 보인다.

하지만 운영 관점에서는 전혀 다르다. 멀티모달 입력은 공짜 첨부파일이 아니라 토큰으로 변환되는 컨텍스트다. Gemini 비디오 문서는 기본 해상도에서 비디오 1초가 대략 300토큰, 낮은 해상도에서는 대략 100토큰이 될 수 있다고 설명한다. Gemini 문서 처리 문서는 PDF 페이지가 페이지당 258토큰으로 계산된다고 설명한다. Claude PDF 문서는 PDF가 텍스트 추출 비용과 페이지 이미지 비용을 함께 만들며, 페이지당 보통 1,500~3,000 텍스트 토큰이 들 수 있다고 설명한다. OpenAI 이미지 문서도 low, high, original, auto 같은 detail 수준에 따라 이미지 리사이징과 토큰 비용이 달라진다고 안내한다.

즉 “이미지를 넣었다”는 말은 충분하지 않다. 개발자는 어떤 프레임을 샘플링했는지, 어떤 해상도로 보냈는지, PDF의 어떤 페이지를 넣었는지, 모델이 보지 못한 작은 글자나 차트를 답변에 요구하고 있지는 않은지 알아야 한다. 오늘 글은 멀티모달 LLM을 모델 신기능이 아니라 컨텍스트 예산, 근거 보존, 실패 모드의 문제로 정리한다.

2. 핵심 개념

멀티모달 입력을 다룰 때 가장 먼저 버려야 할 생각은 “파일을 통째로 모델에게 줬다”는 표현이다. 실제로는 입력이 모델이 처리할 수 있는 내부 표현으로 바뀐다. 텍스트는 토큰이 되고, 이미지는 패치나 리사이즈된 시각 토큰이 되고, 비디오는 프레임과 오디오 조각으로 나뉘고, PDF는 텍스트와 페이지 이미지의 조합으로 처리된다.

이 변환에는 세 가지 계약이 숨어 있다.

첫째, 해상도 계약이다. OpenAI 문서는 low detail이 빠르고 저비용인 이해에 적합하며 512px x 512px 저해상도 이미지를 사용한다고 설명한다. 반대로 세밀한 위치, 작은 글자, 컴퓨터 사용 화면처럼 공간 정보가 중요한 경우에는 더 높은 detail이 필요하다. Claude 문서도 이미지를 픽셀이 아니라 28×28 픽셀 패치 기반의 visual token으로 본다고 설명한다. 큰 이미지는 더 많은 시각 토큰과 지연을 만들 수 있다.

둘째, 샘플링 계약이다. 비디오는 모든 순간을 사람이 보는 방식 그대로 읽히지 않는다. Gemini 비디오 문서는 프레임이 1 FPS로 샘플링되고, 낮은 해상도에서는 프레임당 66토큰, 그 외에는 프레임당 258토큰으로 계산되며 오디오는 초당 32토큰이라고 설명한다. 이 말은 30초짜리 영상도 “짧다”고만 볼 수 없고, 빠르게 지나가는 화면 변화나 자막은 샘플링에서 빠질 수 있다는 뜻이다.

셋째, 페이지·영역 선택 계약이다. PDF나 긴 문서는 페이지 수와 밀도에 따라 비용과 오류 가능성이 달라진다. Gemini 문서 처리 문서는 PDF가 최대 50MB 또는 1000페이지까지 가능하고 페이지당 258토큰으로 계산된다고 설명한다. Claude PDF 문서는 최대 요청 크기와 최대 페이지 수 제한을 제시하며, 큰 PDF는 Files API 사용을 권한다. 중요한 건 “PDF 전체를 넣었다”가 아니라 “어느 페이지와 어느 표·차트를 근거로 답하게 할 것인가”다.

3. 최신 이슈와 연결

최근 멀티모달 API 문서들이 공통적으로 강조하는 방향은 단순 지원 여부가 아니라 입력 제어 옵션이다. Gemini는 비디오 입력 방식으로 File API, Cloud Storage, inline data, YouTube URL을 나누고, 긴 비디오나 재사용 파일에는 File API를 권장한다. OpenAI는 이미지 detail 수준을 통해 비용·지연·정밀도 사이의 선택지를 제공한다. Claude는 이미지 크기와 PDF 페이지 제한, token counting을 통해 요청 전에 비용을 추정하라고 안내한다.

이 변화는 AI 기능 설계에 중요한 신호다. 멀티모달 품질은 “가장 최신 모델을 쓰면 된다”로 해결되지 않는다. 제품이 필요한 질문이 영수증 총액인지, 차트의 작은 범례인지, 화면 좌표인지, 영상의 17초 지점 행동인지에 따라 입력 전략이 달라진다.

예를 들어 영수증 총액 추출은 저해상도 이미지와 structured output 검증으로 충분할 수 있다. 반대로 UI 자동화 에이전트가 버튼 위치를 클릭해야 한다면 원본 해상도, crop 전략, 좌표 검증이 중요하다. 회의 녹화 요약은 전체 영상을 넣기보다 음성 transcript와 주요 화면 캡처를 분리하는 편이 나을 수 있다. PDF 리서치 도우미는 모든 페이지를 한 번에 던지는 대신 목차, 검색, 페이지별 근거 ID를 만들어야 hallucination을 줄일 수 있다.

4. 개발자 관점 해석

멀티모달 LLM의 실패는 대개 모델이 “멍청해서”가 아니라 입력 계약이 불명확해서 생긴다.

첫 번째 실패 모드는 보이지 않는 것을 물어보는 것이다. 저해상도 detail로 보낸 스크린샷에서 작은 오류 메시지, 표의 각주, 흐릿한 숫자를 읽으라고 하면 모델은 추측하기 쉽다. 이때 해결책은 프롬프트를 길게 쓰는 것이 아니라 crop, OCR, 고해상도 detail, 원문 텍스트 추출 중 무엇이 필요한지 고르는 것이다.

두 번째 실패 모드는 전체 문맥과 근거 위치가 섞이는 것이다. PDF 전체 요약을 시키면 그럴듯한 답은 나오지만, 어떤 페이지의 어떤 표에서 나온 주장인지 추적하기 어렵다. RAG에서 chunk ID가 필요하듯 멀티모달 입력에도 page number, frame timestamp, image region, source file ID가 필요하다.

세 번째 실패 모드는 비용이 뒤늦게 폭발하는 것이다. 동영상 5분, PDF 300페이지, 고해상도 스크린샷 여러 장은 제품 화면에서는 “파일 몇 개”처럼 보이지만 모델 입장에서는 긴 컨텍스트다. 특히 사용자가 반복적으로 같은 파일을 올리는 서비스라면 파일 업로드, 캐싱, 요약본, 페이지별 인덱스, 재사용 정책을 함께 설계해야 한다.

네 번째 실패 모드는 텍스트 파이프라인과 시각 파이프라인을 섞는 것이다. PDF 안의 텍스트는 추출 가능한 텍스트일 수도 있고, 스캔 이미지일 수도 있고, 표·차트처럼 시각 이해가 필요한 요소일 수도 있다. 같은 PDF라도 “본문 검색”과 “차트 해석”은 다른 문제다. 가능하면 텍스트 추출, OCR, 이미지 이해, 표 파싱을 분리하고, 최종 답변에는 어떤 경로의 근거인지 남겨야 한다.

5. 내 프로젝트에 적용할 체크포인트

1. 멀티모달 입력을 받을 때 file_id, page, timestamp, region, detail, media_resolution 같은 메타데이터를 로그에 남기는가?
2. 이미지 질문을 “대략적 분류”, “작은 텍스트 읽기”, “좌표·위치 판단”, “표·차트 해석”으로 나눠 detail 수준을 다르게 정했는가?
3. 비디오 입력은 전체 파일을 넣기 전에 transcript, key frame, timestamp 질문으로 나눌 수 있는가?
4. PDF 입력은 전체 요약과 근거 인용을 분리했는가? 답변에 페이지 번호나 영역 ID를 붙일 수 있는가?
5. 요청 전에 토큰·페이지·파일 크기 제한을 계산해 사용자에게 “일부 페이지만 처리됨”, “저해상도 분석”, “긴 처리 시간”을 설명하는가?
6. 모델이 작은 글자나 흐릿한 영역을 확신하는 답변을 내지 않도록 “보이지 않으면 보이지 않는다고 말하기”와 근거 확인을 eval에 넣었는가?

6. 오늘 10분 액션

오늘은 코드보다 표 하나를 만든다. 내 서비스의 멀티모달 입력 후보 3개를 고르고 아래처럼 채워보자.

입력	사용자가 원하는 답	필요한 시각 정밀도	권장 전처리	반드시 남길 근거
영수증 사진	총액/날짜/가맹점 추출	작은 텍스트	crop 또는 OCR + 이미지 검증	이미지 ID, 필드별 confidence
PDF 보고서	특정 수치의 근거 설명	페이지·표 정확도	목차/검색 후 관련 페이지만 투입	file ID, page, 표 제목
짧은 화면 녹화	어느 단계에서 오류가 났는지	timestamp 중심	key frame + transcript	timestamp, frame ID

그다음 현재 프롬프트에 한 문장을 추가한다.

이미지·PDF·비디오에서 직접 확인되지 않는 내용은 추측하지 말고, 근거가 된 페이지·시간·영역을 함께 말한다.

이 한 문장은 만능 guardrail은 아니지만, 멀티모달 입력을 “첨부파일”이 아니라 “근거가 필요한 컨텍스트”로 다루기 시작하는 좋은 출발점이다.

7. 더 볼 자료

• Video understanding | Gemini API
• Document understanding | Gemini API
• Images and vision | OpenAI API
• Vision - Claude Platform Docs
• PDF support - Claude Platform Docs

중복 회피 메모

로컬 content/generated와 Supabase 최근 ai_dev 글을 확인했다. 최근 글은 LLM 서비스 티어, 프롬프트 인젝션 신뢰 경계, Programmatic Tool Calling, RAG citation/grounding, 에이전트 trace, token counting, structured outputs, prompt caching, prefill/decode, KV cache 양자화를 다뤘다. 이번 글은 일반 token counting이나 RAG 근거 계약 반복이 아니라 이미지·PDF·비디오가 모델 안에서 해상도, 프레임, 페이지 단위의 멀티모달 컨텍스트 예산으로 변환되는 과정과 그 실패 모드에 집중한다.