멀티모달 입력의 핵심은 "파일을 올리는 순간"이 아니라 "올린 파일을 질문 가능한 자료로 바꾸는 순간"에 시작됩니다. 검색은 공개된 웹을 대상으로 하지만, Gemini는 내가 가진 자료(스크린샷·PDF·표)를 대상으로 읽고, 뽑고, 비교하고, 형식화할 수 있습니다.1
이 챕터에서는 이미지 이해/OCR, 문서(PDF) 처리, 표·데이터 요약 및 시각화 요청법을 한 번에 묶어, 실무에서 바로 쓰는 흐름으로 정리합니다.
멀티모달 작업을 "질문"으로 설계하는 관점
멀티모달 모델이 하는 일은 크게 두 갈래로 나뉩니다. 사진을 보고 답하는 VQA(Visual Question Answering), 그리고 문서 이미지(스캔·캡처된 PDF 등)를 보고 레이아웃까지 고려해 답하는 DocVQA(Document Visual Question Answering)입니다.2
여기서 중요한 포인트는, 문서/스크린샷에서는 '텍스트만'이 아니라 표, 그래프, 아이콘, 레이아웃이 정보라는 점입니다. 최근 문서 이해 연구는 텍스트 중심 OCR을 넘어서 차트·도형·표 같은 비텍스트 요소까지 구조화해 재구성하려는 방향으로 가고 있습니다.3 여러분이 Gemini에게 원하는 것도 결국 이겁니다.
화면/문서를 "텍스트 덩어리"로 취급하지 않고
"구조(섹션, 표, 축, 범례, 관계)"로 읽게 만들고
결과를 다시 "재사용 가능한 데이터(JSON/CSV/표)"로 받기
업로드 품질이 결과를 결정한다: 파일 올리기 체크리스트
Gemini 앱에서는 한 프롬프트에 최대 10개 파일을 올려 함께 물을 수 있고, 대부분의 파일은 개별 100MB까지 업로드할 수 있습니다.1 영상·오디오처럼 길이/용량이 큰 입력은 제한이 더 빡빡하니(예: 영상 2GB, 길이 제한 등) 문서/이미지 위주 작업과는 운영을 다르게 가져가세요.1
업로드 전/후에 아래를 점검하면 "모델이 못 해서"가 아니라 "입력이 애매해서" 생기는 오류를 크게 줄일 수 있습니다.
(1) 문서/이미지 준비 요령
먼저, 한 장에 너무 많은 정보가 들어가면 모델이 중요한 부분을 놓치기 쉽습니다. 특히 대시보드 스크린샷, 회의 자료 캡처, 법무 PDF처럼 '여기저기 흩어진 디테일'을 찾는 문제라면 더 그렇습니다. 이럴 때는 한 번에 끝내려 하지 말고 "쪼개기"가 답입니다.
스크린샷은 핵심 영역(표/그래프/에러 메시지/설정 화면)을 크롭한 이미지를 함께 올립니다.
PDF는 가능하면 필요 페이지만 분리해 올립니다(또는 페이지 범위를 명시해 질문합니다).
표는 이미지로만 올리지 말고, 가능하면 CSV/스프레드시트도 같이 올려 "교차 검증"합니다.
(2) 실패했을 때의 1차 처방
파일 분석이 실패하거나 결과가 엉뚱할 때, 구글 도움말이 제안하듯 재업로드가 은근히 효과적입니다.1 하지만 재업로드만으로 해결되지 않으면 대개 원인이 다음 중 하나입니다.
해상도/압축 문제: 작은 글자, 흐릿한 스캔, 과한 JPEG 압축
범위 문제: 질문 대상 영역이 넓어 모델의 주의가 분산됨
과업 문제: "요약해줘"처럼 목표가 모호해 추출 기준이 흔들림
따라서 재업로드 + 크롭 + 과업 재정의(출력 형식 고정)를 한 세트로 잡는 게 좋습니다.
이미지·스크린샷을 '질문 가능한 자료'로 만드는 3단계
스크린샷은 사람에게는 '상황'이지만, 모델에게는 '픽셀'입니다. 그래서 질문을 3단으로 나누면 정확도가 좋아집니다.
1단계: 화면을 텍스트+구조로 "파싱"시키기
먼저 화면을 무엇으로 구성했는지 구조를 잡아 줍니다.
프롬프트 예시
"이 이미지(스크린샷)를 구성 요소 단위로 분해해 설명해줘.
화면 제목/섹션, 2) 표/그래프/카드의 이름, 3) 각 요소가 말하는 지표(단위 포함)를 목록으로 정리해줘."
이 단계는 '정답'을 얻기보다, 질문 가능한 좌표계를 만든다는 의미가 큽니다.
이런식으로 화면의 구성 요소들을 분석해서 대답한다.
2단계: 원하는 결과를 "추출 작업"으로 바꾸기(OCR/데이터화)
다음은 실제로 뽑아내는 단계입니다. 여기서부터는 출력 형식이 핵심입니다.
프롬프트 예시(대시보드 KPI 추출 → JSON)
"이 스크린샷에서 KPI 카드에 보이는 숫자를 추출해 JSON으로만 답해줘. 스키마: {kpis: [{name: string, value: number, unit: string|null, period: string|null}]} 숫자는 쉼표를 제거하고 실수로 정규화해줘."
프롬프트 예시(에러 화면 → 재현 조건 정리)
"이 에러 스크린샷에서 (1) 에러 메시지 원문, (2) 에러 코드, (3) 발생 위치(메뉴/버튼 이름), (4) 사용자 행동 흐름(추정 가능)을 추출해줘. 마지막에 '추가로 확인해야 할 스크린샷 3장'을 제안해줘."
3단계: 의미를 붙여 "의사결정 문장"으로 만들기
데이터를 뽑았으면, 마지막은 해석입니다. 이때는 '그럴듯한 코멘트'가 아니라, 근거가 무엇인지를 붙이게 해야 합니다.
프롬프트 예시(근거 포함 요약)
"방금 추출한 KPI를 바탕으로,
상승/하락/정체를 판정하고(판정 기준을 먼저 선언),
원인 가설 2개와 확인 질문 5개를 제시해줘. 단, 각 판정은 '스크린샷에서 읽은 값'에 기반해 근거를 괄호로 달아줘."
PDF/문서를 통째로 던지지 말고, '문서 질의'로 바꾸기
Gemini는 PDF를 네이티브 비전으로 처리하며, 텍스트뿐 아니라 이미지·다이어그램·차트·표까지 문서 맥락에서 분석할 수 있습니다.4 (API 기준으로는 긴 문서도 다룰 수 있는 것으로 안내됩니다.)4
하지만 실무에서는 문서를 '통째로' 이해시키려는 욕심 때문에 결과가 흔들립니다. 문서 질의는 다음 순서로 안정화하세요.
(1) 문서 지도 만들기(목차·섹션·정의)
프롬프트 예시
"이 PDF를 1페이지 요약이 아니라 '문서 지도'로 만들어줘.
섹션/부록/표 목록을 먼저 추출하고,
각 섹션의 목적을 한 문장으로 정의해줘.
마지막에 '자주 물을 질문 10개'를 만들어줘(계약/보고서/논문 중 무엇인지 추정해서)."
이렇게 해두면 이후 질문이 "어디를 봐야 하는지" 명확해집니다.
(2) 추출은 '표준 포맷'으로: Markdown/CSV/JSON
문서에서 표, 조항, 요구사항, 일정 같은 것은 요약보다 "추출"이 먼저입니다.
프롬프트 예시(계약서 조항 추출 → JSON)
"이 PDF에서 '해지/위약/갱신' 관련 조항을 찾아 JSON으로만 출력해줘. 스키마: {clauses: [{topic: string, quote: string, page: number, risk: "low"|"medium"|"high"}]} 반드시 조항 원문 일부를 quote에 넣고, page를 적어줘."
프롬프트 예시(표 추출 → CSV)
"PDF의 'Quarterly Revenue by Region' 표를 CSV로 변환해줘.
첫 행은 헤더
통화 기호 제거
빈 칸은 null
숫자 천단위 구분기호 제거 CSV만 출력해줘."
(3) 문서 Q&A는 '근거 요구'가 기본
DocVQA 성격의 질문("이 보고서에서 비용 증가 원인은 뭐야?")은 대답이 그럴듯해도 근거가 없으면 위험합니다.2 그러니 아래 두 가지를 기본 옵션처럼 붙이세요.
"답변마다 근거 문장(인용)을 1~2개 포함"
"근거가 있는 페이지 번호/표 번호/그림 번호를 명시"
표·데이터: '표를 요약'이 아니라 '표를 계산 가능한 상태로'
표 이미지는 보기엔 쉬워도, 모델 입장에서는 레이아웃이 빽빽한 OCR 문제입니다. 최근 문서 파싱은 표 구조를 보존하고(행/열, 관계) 그래프까지 포함해 구조화하려는 흐름이 강합니다.3 그래서 표 작업은 "텍스트 뽑기"가 아니라 "구조 뽑기"로 접근해야 합니다.
(1) 표 요약의 정석: 관찰 → 비교 → 예외
프롬프트 예시(표 요약 템플릿)
"이 표를 요약하되, 다음 순서로 써줘.
표의 목적(무엇을 비교하는 표인지)
가장 큰 값/가장 작은 값과 그 의미
상위 2개 카테고리 vs 나머지의 차이
예외치(튀는 값) 2개와 원인 가설
다음에 확인할 추가 데이터 3개"
(2) 표를 '분석 친화형'으로 정규화
표에서 바로 분석을 하려면 정규화가 필요합니다. 여기서 Gemini에게 맡길 작업은 '통계'가 아니라 데이터 전처리 규칙 적용입니다.
프롬프트 예시(정규화 + 파생 컬럼 생성)
"이 표를 CSV로 변환하고, 아래 규칙을 적용해줘.
날짜는 ISO(YYYY-MM-DD)
퍼센트는 0~1 실수로 변환
통화는 숫자만 남기고 통화 단위는 별도 컬럼 currency에 넣기
파생 컬럼: yoy_change = (this_year - last_year) / last_year 출력은 (1) 정규화된 CSV, (2) 변환 규칙 적용 로그 5줄(무엇을 어떻게 바꿨는지) 순서로."
시각화 요청: "차트를 그려줘" 대신 '설계도'를 달라
Gemini 앱은 업로드한 데이터를 바탕으로 차트 같은 시각적 표현을 생성할 수 있다고 안내합니다.1 다만 여러분이 원하는 게 "예쁜 그래프"인지 "의사결정용 그래프"인지에 따라 지시가 달라야 합니다.
실무에서는 다음처럼 요청하는 편이 안전합니다.
(1) 먼저 '어떤 차트가 맞는지' 추천받기
프롬프트 예시
"이 표(또는 추출한 CSV)를 보고, 내 목적은 '분기별 추세와 지역별 차이'를 한 화면에서 보여주는 거야.
추천 차트 2개(왜 그 차트인지)
각 차트에 들어가야 할 축/범례/단위
주석(강조해야 할 포인트) 3개 를 설계 문서처럼 써줘."
(2) 그다음 '코드/스펙'으로 고정
조직에서 재현 가능한 결과가 필요하면, 최종 산출을 이미지가 아니라 스펙으로 남겨야 합니다.
프롬프트 예시(Vega-Lite 스펙)
"아래 CSV로 대시보드용 차트 1개를 만들 Vega-Lite spec을 작성해줘. 요구사항:
시간축은 분기, 값은 매출, 색상은 지역
툴팁에 (지역, 분기, 매출, YoY)
색각 이상 친화 팔레트
차트 요약 alt-text도 함께 제공 출력: (1) Vega-Lite JSON, (2) alt-text 1문단"
검증 루틴: 멀티모달 결과를 '보고서 품질'로 끌어올리기
멀티모달 작업은 "읽기"보다 "검증"이 실력 차이를 만듭니다. 다음 루틴을 습관화하면, Gemini가 분석 비서가 되는 순간이 빨라집니다.
근거 강제: 인용(quote) + 페이지/표/그림 번호를 함께 요구
교차 확인: PDF 표 vs 스프레드시트 값, 스크린샷 숫자 vs 원본 데이터
모호함 처리: 확신이 낮은 항목은
unknown으로 두고, 추가 자료 요청을 받기
프롬프트 예시(검증용)
"방금 답변을 검증해줘.
답변의 핵심 주장 5개를 뽑고
각 주장에 대해 '근거(인용/페이지)'가 있는지 체크하고
근거가 없는 주장은 '추정'으로 표시한 뒤, 필요한 추가 자료(페이지/스크린샷 종류)를 제안해줘. 마지막에 신뢰도(0~100)와 그 이유를 써줘."
마무리: 파일을 잘 올리고, 잘 묻는 사람이 승리한다
멀티모달 입력은 "기능"이 아니라 "업무 방식"입니다. 파일 업로드 한 번으로 끝내려 하지 말고, 파싱 → 추출 → 해석 → 검증으로 쪼개면 결과는 훨씬 견고해집니다. 그리고 표·그래프·스크린샷 같은 '내부 자료'가 쌓일수록, Gemini는 검색보다 강한 분석 비서가 됩니다.1
참고
1Upload & analyze files in Gemini Apps - Google Help
2Multimodal Tasks and Models · Hugging Face
3Multimodal OCR: Parse Anything from Documents (arXiv:2603.13032v1)
4Document understanding | Gemini API | Google AI for Developers
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.