AI에게 문서를 읽히는 법
PDF·엑셀·긴 보고서를 다룰 때 실제로 일어나는 일
① "문서를 읽는다"는 건 사람처럼 훑어보는 게 아니라 문서 전체를 토큰으로 쪼개 한 번에 입력으로 밀어넣는 것이다. 그래서 문서의 형태(텍스트냐 스캔본이냐, 표가 많냐)에 따라 결과가 크게 갈린다.
② 가장 흔한 두 가지 실패는 긴 문서 중간부를 놓치는 것과 표의 구조가 깨지는 것이다. 둘 다 원인을 알면 피해가는 방법이 있다.
③ 문서에서 뽑아낸 숫자라고 안전하지 않다. 표에서 읽었든 대화로 물어봤든, 숫자는 여전히 예측의 산물이라는 사실은 바뀌지 않는다.
① "읽어줘"에는 두 가지 완전히 다른 상황이 섞여 있다
PDF 하나를 올리고 "읽어줘"라고 하면 겉보기엔 같은 요청 같지만, 실제로는 문서가 어떤 종류냐에 따라 전혀 다른 일이 일어난다.
텍스트 PDF(워드나 한글에서 바로 변환한 문서, 문서 안 글자를 마우스로 드래그해 선택할 수 있는 경우)는 글자 정보가 그대로 들어 있어서, 이 텍스트를 그대로 뽑아 토큰으로 쪼개 입력에 넣으면 된다. 스캔 PDF(종이를 스캔했거나 사진을 찍어 만든 문서, 글자를 드래그할 수 없는 경우)는 처음부터 이미지다. 글자를 읽으려면 OCR(광학 문자 인식)이라는 별도 단계를 거쳐 이미지 속 글자를 텍스트로 변환해야 한다.
스캔 PDF는 OCR 정확도가 그대로 최종 품질의 한계가 된다. 표·손글씨·흐릿한 인쇄·기울어진 스캔이 있으면 글자를 잘못 읽는다. 이 오류는 뒤 단계로 그대로 넘어가고, 모델은 잘못 인식된 글자를 원래 맞는 글자인 것처럼 이어서 처리한다. 결과가 이상하면 가장 먼저 "이게 텍스트 PDF인가 스캔 PDF인가"부터 확인하는 게 맞다.
참고로 최신 모델에서는 이 OCR이 완전히 별도의 프로그램이 아니라, 이미지를 좌표로 바꿔 처리하는 멀티모달 파이프라인의 일부로 통합돼 있는 경우가 많다. 다만 통합됐다고 해서 스캔 품질이 낮을 때 오류가 줄어드는 건 아니다 — 위 주의사항은 그대로 유효하다.
② 긴 문서일수록 중간이 흐려진다
AI 도구 비교에서 다뤘던 "축 1"이 바로 이 문제다. 컨텍스트 윈도우가 아무리 커도, 문서의 앞부분과 뒷부분은 잘 기억하는 반면 중간 내용은 놓치는 경향이 여러 모델에서 공통적으로 나타난다. "롱 컨텍스트의 중간 소실(lost in the middle)"이라 부르는 현상이다.
왜 이런 일이 생기나. 어텐션은 모든 토큰이 모든 토큰을 참조하는 구조지만, 학습 데이터에서 정말 긴 문서를 처음부터 끝까지 정밀하게 참조해야 하는 사례 자체가 상대적으로 적다. 그래서 "이 근처에 중요한 내용이 있을 확률이 높다"는 학습된 편향이 문서의 시작과 끝에 쏠리기 쉽다.
| 문서 내 위치 | 정확도 경향 | 실무 함의 |
|---|---|---|
| 도입부 | 높음 | 핵심 요약·목차를 앞에 배치한 문서가 유리 |
| 중간부 | 낮아지는 경향 | 세부 조항·각주·부록이 여기 있으면 누락 위험 |
| 마지막부 | 비교적 높음 | 결론·서명란이 있는 경우 잘 잡히는 편 |
직접 확인하는 방법이 있다. 긴 문서 중간쯤에 일부러 특이한 문장 하나를 심어두고("이 문장을 발견하면 '체크포인트'라고 답하라" 같은) 그 내용을 물어본다. 못 찾으면 그 문서 길이에서 신뢰도가 떨어진다는 뜻이고, 실제 중요한 작업이라면 문서를 쪼개서 나눠 넣는 편이 안전하다.
① 문서가 길면 섹션별로 나눠서 따로 요약시킨 뒤 마지막에 종합한다.
② 특히 중요한 조항이 있으면 "N페이지 O번째 조항을 인용해줘"처럼 위치를 직접 지정해 물어본다 — 전체 검색보다 정확도가 훨씬 높다.
③ 요약이 끝나면 "이 문서에 언급되지 않은 내용은 답에 포함하지 마"라는 제약을 걸어 환각을 줄인다.
③ 표는 왜 깨지는가
표가 있는 문서는 특히 조심해야 한다. 사람 눈에는 행과 열이 또렷하지만, 텍스트로 추출되는 순간 표의 구조 정보(어느 칸이 어느 칸과 같은 행인지)가 사라지기 쉽다. PDF 안에서 표는 실제로는 "이 위치에 이 글자, 저 위치에 저 글자"라는 좌표 정보의 나열일 뿐, "이건 표다"라는 표시가 따로 있는 게 아니기 때문이다.
| 깨지는 패턴 | 왜 생기나 |
|---|---|
| 병합된 셀 | 병합 정보가 사라지고 텍스트만 남아 열이 밀린다 |
| 여러 페이지에 걸친 표 | 페이지가 넘어가며 헤더가 반복되거나 끊긴다 |
| 가로로 긴 표 | 열 순서가 읽는 방향과 다르게 재배치될 수 있다 |
| 이미지로 삽입된 표 | OCR을 거쳐야 하므로 오류가 누적된다 |
표가 중요한 문서라면, 표 부분만 따로 캡처해서 "이 표를 마크다운 표로 다시 옮겨 적어줘. 원본과 한 칸씩 대조해서 확인해줘"라고 별도로 요청하는 게 전체 문서를 한 번에 밀어넣는 것보다 정확도가 높다. 표 하나에 집중시키면 검증할 범위도 줄어든다.
운용보수·추적오차·거래량처럼 비교표가 핵심인 문서(예: ETF 상품설명서)를 AI로 요약시킬 계획이라면, 표 하나하나를 이 방식으로 검증하는 습관이 특히 중요하다. 실제 비교 기준이 무엇인지는 ETF 입문 가이드에서 정리했다.
④ 엑셀·재무제표 숫자를 다룰 때 — 원칙은 바뀌지 않는다
엑셀 파일이나 재무제표를 넣고 "매출 추이 정리해줘"라고 하면 표 형태로 깔끔한 결과가 나온다. 그런데 이게 계산기로 뽑은 숫자가 아니라는 사실은 여전하다. AI가 숫자를 틀리는 이유에서 다뤘듯, 모델은 숫자도 텍스트와 같은 방식으로 예측한다 — 표에서 읽어온 숫자라고 이 구조가 달라지지 않는다.
여기에 문서 처리 특유의 위험이 하나 더 붙는다. ③에서 본 표 붕괴가 재무제표에서 일어나면, "매출"과 "영업이익" 열이 서로 밀려서 엉뚱한 숫자에 엉뚱한 이름표가 붙는 사고가 생길 수 있다. 숫자 자체는 문서에 실제로 있던 숫자인데, 어느 항목의 숫자인지가 틀리는 것이다.
분기 실적 PDF를 AI로 요약시켜서 투자 판단에 쓰는 경우가 늘고 있다. 편리하지만 표가 깨진 채로 요약되면 오답인 줄도 모르고 쓰게 된다는 게 진짜 위험이다. 매출·이익·마진 같은 핵심 수치는 요약본이 아니라 원문 표를 직접 눈으로 대조해야 한다 — 실제 공시 기반 수치는 빅테크 실적 해석 가이드처럼 검증된 자료를 기준으로 삼는 게 안전하다.
⑤ 실전 워크플로 — 문서 종류별 체크리스트
| 문서 종류 | 넣기 전에 할 일 | 결과 확인 방법 |
|---|---|---|
| 텍스트 PDF, 짧은 문서 | 그대로 업로드 | 일반적인 검증으로 충분 |
| 스캔 PDF | 스캔 품질 확인 — 흐릿하면 재스캔 고려 | 원문과 몇 문단 직접 대조 |
| 긴 문서(수십 페이지) | 섹션별로 나눠서 넣기 | 중간 특정 조항 인용 요청으로 테스트 |
| 표 위주 문서 | 표만 별도로 캡처해 요청 | 표 전체를 원본과 칸별 대조 |
| 재무제표·엑셀 | 표 붕괴 여부 우선 확인 | 핵심 수치는 원문에서 직접 재확인 필수 |
이 워크플로는 AI로 리서치하는 법의 4단계(조사→요약→대조→출처확인) 중 "출처확인" 단계를 문서 처리에 특화시킨 버전이라고 보면 된다. 리서치 전체 흐름은 그 글을, 문서 하나를 정확히 다루는 법은 이 글을 참고하면 된다.
AI에게 문서를 맡길 때 물어야 할 건 "얼마나 정확한가"가 아니라 "이 문서의 어느 부분이 놓치기 쉬운 구조인가"다. 스캔 여부, 문서 길이, 표의 존재 — 이 세 가지만 미리 점검해도 대부분의 실패를 피할 수 있다.
※ 본 글은 2026년 8월 기준 공개된 문서 처리 AI 기술의 일반적인 구조를 설명합니다. 개별 상용 도구의 구현 방식은 다를 수 있으며, 본문의 기업 언급은 구조 설명을 위한 예시로 투자 권유가 아닙니다.
※ 본 가이드는 일반 교육 목적의 참고 자료이며, 이해를 돕기 위해 기술적 세부사항을 단순화했습니다.
새 가이드가 나오면 알려드립니다
AI 리터러시 가이드는 주 2회 발행합니다. 구독하시면 다음 편을 메일로 보내드립니다. 무료이고 언제든 해지할 수 있습니다.