IBM이 "Granite 4.0 3B Vision"을 공개하며, 기업 문서(청구서·리포트·스캔본)에서 표·차트·핵심항목을 뽑아내는 멀티모달 AI를 더 작고 실무형으로 밀어붙였습니다1. 중요한 건 "거대 모델만이 답"이라는 분위기에서, 운영비와 배포 현실을 정면으로 다뤘다는 점이에요.
이 글에서는 Granite 4.0 3B Vision이 정확히 어떤 문서 업무에 강한지, 왜 '3B급'이 실무에서 매력적인지, 그리고 바로 써먹는 적용 팁까지 한 번에 정리해봅니다.
Granite 4.0 3B Vision이 잘하는 문서 업무 3가지(표·차트·KVP)
현업 문서 자동화가 막히는 지점은 의외로 "글을 읽는 일"이 아니라 "구조를 복원하는 일"입니다. 표는 셀이 합쳐지고, 차트는 축과 범례가 있고, 청구서는 회사마다 레이아웃이 다르죠. Granite 4.0 3B Vision은 이 세 부류를 정면으로 겨냥합니다.
첫째, 차트를 CSV로 바꾸거나 요약하고, 심지어 차트를 재현하는 파이썬 코드로도 변환합니다. 단순 설명이 아니라 "데이터화"가 목적이라, 분석 파이프라인에 곧장 태울 수 있는 형태를 노립니다2.
둘째, 표 추출은 HTML·JSON·OTSL 같은 구조 포맷으로 뽑는 데 초점이 있습니다. 특히 '페이지 전체'에서 표만 찾아 구조를 맞추는 평가까지 별도로 다뤄서, 스캔 PDF 같은 현실 입력을 의식한 설계라는 인상을 줍니다2.
셋째, KVP(Key-Value Pair) 추출은 "송장번호/발행일/세금ID"처럼 우리가 원하는 필드를 스키마로 정의해두고, 문서 레이아웃이 달라도 값을 찾아 채우는 방식입니다. VAREX 벤치마크에서 제로샷 exact-match 85.5%를 기록했다고 공개됐는데2, 이는 "규칙 기반 템플릿이 깨지는 순간"을 AI로 메우려는 팀에 꽤 설득력 있는 숫자입니다.
'LoRA 어댑터' 전략: 배포가 가벼워지는 설계 포인트
Granite 4.0 3B Vision의 재미있는 지점은 모델이 "통째로 멀티모달"이 아니라는 데 있습니다. 기본은 Granite 4.0 Micro(3.5B급)이고, 비전 쪽 능력은 LoRA 어댑터(0.5B)를 얹는 구조로 제공됩니다2.
이 방식이 실무에서 좋은 이유는 간단합니다. 문서 파이프라인은 생각보다 "이미지 입력"만 있는 게 아니라, 텍스트-only 처리(분류, 요약, 규정 QA 등)도 같이 굴러가거든요. 이때는 어댑터를 굳이 로드하지 않고도 기본 모델로 처리할 수 있어, 한 배포물로 멀티모달과 텍스트 업무를 같이 커버하는 그림이 나옵니다2.
또 하나의 포인트는 '태그 기반 태스크 호출'입니다. <chart2csv>, <tables_html> 같은 짧은 태그로 작업이 시작되도록 설계되어 있어2, 프롬프트 장문 튜닝에 드는 커뮤니케이션 비용을 줄여줍니다. 운영팀 입장에서는 "프롬프트 표준화"가 곧 장애를 줄이는 길이라, 이 부분이 은근히 큽니다.
로컬·엣지에 왜 3B급 VLM이 유리할까? (속도·비용·보안)
문서 AI는 민감정보(계약, 급여, 세금)가 자주 섞이니 "가능하면 내부망에서 끝내자"는 요구가 강합니다. 하지만 대형 VLM은 GPU 비용과 지연시간이 발목을 잡죠. 그래서 요즘은 '작지만 전문적인 모델'이 문서 자동화에서 더 자주 이깁니다.
Granite 4.0 계열은 하이브리드 Mamba 아키텍처로 "더 빠르고 메모리 효율적"을 강조하고 있고3, 긴 컨텍스트(최대 128K) 운용도 전제로 합니다3. 문서 업무는 한 번에 많은 페이지를 다루거나, 추출 결과를 근거와 함께 장문으로 남겨야 할 때가 많아 컨텍스트 여유가 곧 안정성으로 이어집니다.
그리고 실행 생태계도 무시 못 합니다. Granite 4.0는 Ollama나 llama.cpp 같은 로컬 실행 흐름으로 이어지기 쉬운 튜토리얼과 배포 형태가 꾸준히 정리되고 있어3, "연구용 데모에서 끝나지 않게" 만드는 길이 보입니다. 즉, 문서 자동화 PoC를 빠르게 돌리고 운영으로 넘기려는 팀일수록 3B급 전략이 현실적입니다.
시사점
Granite 4.0 3B Vision을 한 줄로 요약하면 "기업 문서에서 돈 되는 추출을, 작게 패키징한 멀티모달"입니다. 도입을 고민한다면, 먼저 차트·표·KVP 중 우리 병목이 어디인지 정하고(예: 표가 무너지는 PDF가 제일 문제인지), 그 출력 포맷(HTML/JSON/CSV)을 다운스트림 시스템이 바로 먹을 수 있게 맞추는 게 1순위입니다.
그다음은 운영 전략입니다. 이미지 입력이 많은 구간에만 LoRA 어댑터를 켜고, 나머지는 텍스트-only로 처리하도록 라우팅하면 비용이 눈에 띄게 안정됩니다. 마지막으로, 태그 기반 태스크를 팀 표준으로 고정해두면 "사람마다 다른 프롬프트"에서 생기는 품질 편차도 줄일 수 있습니다. 작은 모델의 강점은 결국, 기술이 아니라 운영에서 더 크게 터지니까요.
참고
1Granite 4.0 3B Vision: Compact Multimodal Intelligence for Enterprise Documents
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.