멀티모달 LLM 실무 — 이미지·PDF 파싱 API 선택과 비용 최적화

멀티모달 LLM은 텍스트와 이미지를 함께 받아 처리하는 모델입니다. 실무에서는 언제 Vision API를 쓰고, 언제 문서 전용 파서를 선택해야 하는지의 판단이 비용과 정확도를 가릅니다. 이미지를 그대로 보내면 해상도에 따라 토큰 수가 폭발적으로 늘어나고, 반대로 전용 파서는 특정 레이아웃 유형에서 Vision API를 한참 앞섭니다. 이 글은 API 선택 기준, 해상도·토큰 비용의 관계, PDF 처리 전략, 모델별 성능 비교, 그리고 자주 발생하는 실패 케이스까지 실무 관점에서 정리합니다.

멀티모달 LLM과 문서 전용 파서 — 무엇이 다른가

GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro 같은 멀티모달 LLM은 이미지를 입력으로 받아 내용을 자연어로 이해하고 추론합니다. 단순한 OCR을 넘어 이미지 내 문맥을 파악하고, 표의 의미를 해석하며, 복잡한 질문에 답하는 것이 강점입니다. 반면 AWS Textract, Google Document AI, Azure Document Intelligence 같은 문서 전용 파서는 레이아웃 분석, 표 구조 추출, 키-값 쌍 인식, 서명·도장 감지에 특화된 전통적인 컴퓨터 비전과 ML 파이프라인입니다.

두 접근의 핵심 차이는 이해(comprehension) 대 구조(structure)입니다. 멀티모달 LLM은 “이 계약서에서 위약금 조항의 핵심 내용을 요약해”처럼 의미 이해가 필요한 작업에 강합니다. 반면 전용 파서는 “이 세금계산서에서 품목명·수량·금액을 표 형태로 추출해”처럼 정해진 필드를 정확하게 뽑아야 하는 구조적 추출에서 더 빠르고 저렴하며 일관성 있는 결과를 냅니다.

Vision API vs 문서 전용 파서 — 선택 기준

두 도구는 경쟁 관계라기보다 상호 보완 관계입니다. 아래 표는 작업 유형에 따른 권장 선택을 정리한 것입니다.

실무에서는 두 도구를 파이프라인에서 병렬로 쓰는 패턴도 흔합니다. 예를 들어 Textract로 텍스트 레이어와 표 구조를 먼저 추출한 다음, 그 결과를 LLM에 텍스트로 넘겨 의미 분석을 수행하면 Vision API에 이미지를 직접 보낼 때보다 토큰 비용이 크게 줄고 정확도도 높아집니다. 이미지를 이미지로 처리하는 것이 반드시 최선이 아닌 이유입니다.

이미지 해상도와 토큰 비용의 관계

Vision API의 비용을 좌우하는 핵심 변수는 이미지 크기입니다. 멀티모달 LLM은 이미지를 내부에서 고정 크기의 패치(tile)로 분할해 각 패치를 토큰처럼 처리합니다. 이미지가 클수록 패치 수가 많아지고, 그만큼 입력 토큰 수와 처리 비용이 증가합니다.

OpenAI GPT-4o 기준으로 이미지는 고해상도(high) 모드와 저해상도(low) 모드로 나뉩니다. 저해상도 모드는 이미지를 512×512 픽셀로 리사이즈해 고정 토큰을 사용하고, 고해상도 모드는 원본 이미지를 최대 2048×2048 내에서 가능한 한 유지하며 512×512 타일로 분할해 타일당 토큰이 발생합니다(OpenAI Vision 공식 문서). Claude Sonnet의 경우 이미지를 최대 1568픽셀 내에서 처리하며 역시 크기에 비례한 토큰을 소비합니다(Anthropic 공식 문서).

실무 최적화의 첫 단계는 용도에 맞는 최소 해상도를 정하는 것입니다. 글씨 판독이 필요 없는 레이아웃 분류 작업이라면 저해상도 모드로도 충분합니다. 반대로 세금계산서처럼 작은 숫자까지 읽어야 한다면 충분한 해상도를 유지해야 합니다. 이 판단을 자동화하려면 작업 유형별로 해상도 프로파일을 사전 정의하고, 파이프라인 진입 시 이미지를 자동으로 리사이즈하는 전처리 단계를 두면 됩니다.

PDF 처리 전략 — 페이지 분할과 텍스트 레이어 우선

PDF는 멀티모달 LLM에 직접 넣을 수 없습니다. PDF를 처리하는 방법은 크게 세 가지입니다: 페이지별 이미지 변환, 텍스트 레이어 추출, 그리고 혼합 방식입니다. 어떤 방법을 택하느냐에 따라 비용이 수십 배 차이 납니다.

텍스트 레이어 우선 원칙

디지털로 생성된 PDF(Word 출력, 웹 PDF 등)에는 이미 파싱된 텍스트 레이어가 내장돼 있습니다. 이 경우 pdfplumber나 PyMuPDF 같은 라이브러리로 텍스트를 직접 추출하면 이미지 변환 없이 토큰 비용을 최소화할 수 있습니다. 이미지 파싱은 텍스트 레이어가 없거나(스캔 PDF), 레이아웃·차트의 시각적 구조가 의미를 가지는 경우에만 필요합니다.

import fitz  # PyMuPDF

def extract_or_image(pdf_path: str, page_num: int) -> dict:
    doc = fitz.open(pdf_path)
    page = doc[page_num]
    text = page.get_text("text").strip()

    if len(text) > 100:
        # 텍스트 레이어가 충분 → 이미지 변환 없이 반환
        return {"type": "text", "content": text}
    else:
        # 스캔 PDF 또는 도표 위주 → 이미지로 변환
        pix = page.get_pixmap(dpi=150)
        return {"type": "image", "content": pix.tobytes("png")}

페이지별 분할 전략

이미지 변환이 필요한 경우에도 PDF 전체를 한 번에 넣는 것은 위험합니다. 페이지 수가 많으면 컨텍스트 창 한계에 걸리고, 비용도 선형으로 증가합니다. 페이지별로 분할해 처리한 뒤 결과를 합치는 방식이 안전합니다. 다만 페이지 경계에서 표나 문단이 잘릴 수 있으므로, 인접 페이지를 겹쳐서 처리하는 슬라이딩 윈도우 방식을 쓰거나, 먼저 목차·섹션 구조를 파악해 논리적 단위로 분할하는 편이 정확도에 유리합니다.

모델별 이미지 파싱 성능 비교

2024년 공개 벤치마크와 실무 사례를 기반으로 주요 Vision API의 특성을 정리합니다. 구체적 수치는 테스트 조건과 문서 유형에 따라 달라지므로 방향성 참고 용도로 활용하고, 실제 도입 전에는 대상 문서로 직접 평가를 권장합니다.

Gemini 1.5 Pro는 Files API를 통해 PDF를 직접 업로드하면 내부에서 페이지별로 처리하므로, 별도의 이미지 변환 파이프라인 없이 최대 1,000페이지까지 처리할 수 있습니다(Google Gemini API 문서). 대용량 PDF 파싱을 단순화하고 싶다면 현시점에서 유력한 선택지입니다.

자주 실패하는 케이스와 대응

멀티모달 LLM이 이미지 파싱에서 가장 많이 실패하는 케이스는 크게 네 가지입니다. 각 케이스를 미리 파악하고 대응 전략을 파이프라인에 심어 두는 것이 안정적인 운영의 핵심입니다.

복잡한 병합 셀 표

행·열이 병합된 복잡한 표는 멀티모달 LLM이 가장 자주 잘못 파싱하는 구조입니다. Liu et al.(2023)의 MMC 벤치마크에 따르면 복잡한 표와 차트 이해에서 GPT-4V 조차 전용 파서 대비 낮은 정확도를 보이는 경우가 있습니다. 대응 전략은 Textract의 Tables 기능으로 구조를 먼저 추출한 다음 Markdown 표로 변환해 LLM에 텍스트로 전달하는 것입니다.

차트·그래프의 수치 읽기

막대 그래프, 꺾은선 그래프, 원형 차트에서 정확한 수치를 추출하는 것은 Vision API의 전통적인 약점입니다. 눈으로 보기에 명확한 차트도 LLM은 수치를 추정하거나 범례를 잘못 연결하는 경우가 빈번합니다. 차트 수치가 중요하다면 LLM 출력을 그대로 신뢰하지 말고, 원본 데이터 소스를 함께 제공하거나, 차트 이해 전용 모델(예: ChartQA 파인튜닝 모델)을 별도로 검토해야 합니다.

저해상도·기울어진 스캔

DPI 100 이하의 저해상도 스캔이나 5도 이상 기울어진 문서는 Vision API와 전용 파서 모두 성능이 급격히 저하됩니다. 파이프라인에 전처리 단계로 기울기 보정(deskew)과 최소 해상도 보장 로직을 넣는 것이 안전합니다. OpenCV의 getRotationMatrix2D나 imutils.rotate_bound를 활용할 수 있습니다.

다국어 혼합 문서

한국어·영어·한자가 섞인 문서는 OCR 성능이 불안정합니다. 멀티모달 LLM은 대체로 다국어에 강하지만, 한국어가 섞인 레이아웃에서 특히 Textract는 기본 언어 설정이 영어라 한국어 인식이 떨어질 수 있습니다. Document AI의 경우 한국어 지원 프로세서를 명시적으로 선택해야 합니다.

비용 최적화 체크리스트

• 텍스트 레이어가 있는 PDF는 이미지 변환 없이 텍스트 추출로 처리
• 작업 유형별 최소 해상도 프로파일 정의 — 분류는 저해상도, 정밀 추출은 고해상도
• 전체 페이지 Vision API 적용 전 1차 분류(Haiku·Flash 등 저비용 모델)로 처리 대상 필터링
• 정형 필드 추출(영수증·세금계산서)은 Textract·Document AI로 전환, Vision API는 비정형에만
• 응답 usage에서 이미지 토큰 수 측정 후 예상 대비 2배 이상이면 해상도·모드 점검
• 대량 처리 시 Batch API 활용 — OpenAI Batch API는 동기 호출 대비 입력 비용 50% 절감
• 동일 문서를 반복 파싱하는 경우 결과를 캐시(Redis·S3)에 저장해 재처리 방지
• 실패율 높은 문서 유형 분류 → 전용 파서 또는 수동 검토 큐로 라우팅

자주 묻는 질문

Vision API와 Textract를 동시에 써야 하나요?

작업이 의미 이해(요약·QA)와 구조 추출(필드 파싱)을 모두 필요로 한다면 파이프라인에서 두 도구를 병렬로 사용하는 것이 효율적입니다. Textract로 구조를 뽑고, 그 텍스트를 LLM에 전달하면 이미지를 직접 보내는 것보다 비용이 적고 정확도가 높은 경우가 많습니다.

이미지를 Base64로 보내야 하나요, URL로 보내야 하나요?

URL 방식은 API 서버가 직접 이미지를 가져오므로 공개 접근 가능한 URL이어야 합니다. Base64는 어느 이미지든 전송 가능하지만 요청 페이로드 크기가 커집니다. 내부 시스템 이미지나 인증이 필요한 경우 Base64가 안전하고, 공개 이미지·CDN URL은 URL 방식이 간편합니다.

PDF를 Gemini에 직접 업로드하면 페이지마다 따로 처리하지 않아도 되나요?

Gemini Files API를 이용하면 PDF를 통째로 업로드해 최대 1,000페이지까지 한 번의 요청으로 처리할 수 있습니다. 내부적으로 페이지별로 변환해 처리하므로 페이지 수에 비례한 토큰이 소비됩니다. 대용량 PDF 파이프라인을 단순화하고 싶을 때 유용합니다.

손글씨 메모를 Vision API로 파싱하면 얼마나 정확한가요?

필기 서체와 이미지 품질에 따라 편차가 큽니다. 깔끔한 필기체는 GPT-4o·Claude 3.5 기준으로 실용적인 수준이지만, 초서체·악필·겹쳐 쓴 글씨는 여전히 불안정합니다. 중요한 필기 문서라면 Vision API 출력에 사람이 검토하는 Human-in-the-loop 단계를 두는 것을 권장합니다.

비용을 줄이려면 어떤 모델부터 시도해야 하나요?

Gemini 1.5 Flash나 GPT-4o mini처럼 소형 멀티모달 모델로 먼저 시도합니다. 정확도가 충분하면 그대로 사용하고, 부족한 경우에만 대형 모델로 에스컬레이션하는 2단계 파이프라인이 비용 대비 효율이 좋습니다. 정형 문서는 Textract·Document AI로 전환하는 것이 가장 확실한 절감 방법입니다.

모델별 토큰 단가와 이미지 처리 방식, 벤치마크 수치는 2026년 기준이며 자주 바뀌므로, 실제 적용 전 OpenAI 공식 문서에서 최신 비전 API 사양과 가격을 확인하세요.

이 글은 OpenAI Vision 공식 문서, Anthropic Claude 공식 문서, Google Document AI 문서, AWS Textract 개발자 가이드, 그리고 공개 벤치마크 연구를 바탕으로 작성했습니다. 모델별 토큰 단가·처리 방식은 자주 업데이트되므로 실제 적용 전 각 API의 최신 공식 문서와 가격 페이지를 반드시 확인하시기 바랍니다.