PDF, 스캔 이미지, 양식에서 필요한 정보를 자동으로 찾아 정리된 데이터로 꺼내는 AI 기술로, 글자만 읽는 OCR과 달리 표·머리글·서명란 같은 문서 구조를 이해해 금액·날짜·공급자명 같은 항목을 뽑아낸다. 계약서, 청구서, 신청 양식을 사람이 일일이 읽고 입력하는 일을 줄이고 싶을 때 쓴다.
| 방식 | 하는 일 | 이럴 때 쓴다 |
|---|---|---|
| OCR | 이미지 속 글자를 텍스트로 | 검색용 텍스트만 필요할 때 |
| 문서 AI 전용 서비스 | 정해진 양식에서 항목 추출 | 청구서·신분증 같은 대량 정형 문서 |
| 멀티모달 LLM | 문서를 보고 질문에 답하거나 요약 | 형식이 제각각인 계약서, 일회성 질문 |
Claude나 GPT-4o 같은 멀티모달 모델에는 PDF나 이미지를 그대로 올리고 "이 계약서의 계약 기간과 해지 조건을 찾아줘"라고 물으면 된다. 따로 학습시키거나 설정하지 않아도 형식이 제각각인 문서를 다룰 수 있는 게 장점이다.
결과를 다른 시스템에 넣을 거라면 "계약기간, 해지조건을 JSON으로 줘"처럼 출력 형식을 정해 주는 게 좋다. 그래야 매번 같은 모양으로 받아 바로 저장할 수 있다.
Google Document AI, AWS Textract 같은 서비스는 세금계산서, 운전면허증처럼 특정 문서 유형에 맞춘 파서를 제공한다. 형식이 일정한 문서를 대량으로 처리할 때 결과가 안정적이고, 항목마다 신뢰도 점수를 함께 돌려준다. Mistral OCR처럼 문서를 표와 구조를 살린 텍스트로 바꿔 주는 OCR 모델을 앞에 두고, 그 결과를 LLM에 넘겨 해석하게 하는 조합도 쓴다.
문서가 많으면 한 장씩 대화로 처리하지 말고 처리 흐름(파이프라인)을 만든다. 순서는 대략 이렇다.
| 단계 | 하는 일 |
|---|---|
| 1. 입력 | 스캔·PDF를 모으고 문서 유형을 분류 |
| 2. 추출 | 배치 API와 비동기 처리로 항목 뽑기 |
| 3. 검증 | 합계가 맞는지, 날짜 형식이 맞는지 규칙으로 확인 |
| 4. 검토 | 신뢰도가 낮은 건만 사람이 확인 |
흐린 스캔, 손글씨, 여러 페이지에 걸친 표에서는 숫자를 잘못 읽기 쉽고, LLM은 문서에 없는 값을 채워 넣기도 한다. 금액이나 계좌번호처럼 틀리면 곤란한 항목에는 규칙 검사와 사람 검토를 꼭 붙인다. 개인정보가 담긴 문서는 외부 서비스로 보내기 전에 데이터 보관과 학습 활용 정책부터 확인해야 한다.
가장 흔한 건 사람이 서류를 보고 시스템에 옮겨 적던 일을 대신하는 방식이다. 형식이 일정한 대량 문서는 전용 서비스와 파이프라인으로, 형식이 제각각인 문서는 LLM에 직접 물어 처리한다.
| 어디서 | 어떻게 쓰나 |
|---|---|
| 청구서·영수증 처리 | 금액·날짜·공급자명을 뽑아 회계 시스템에 바로 입력하고, 합계가 안 맞는 건만 사람이 확인 |
| 계약서 검토 | PDF를 LLM에 올려 계약 기간·해지 조건을 찾고 요약 |
| 신청서·신분증 접수 | 양식에서 이름·번호 같은 항목을 추출하고 신뢰도가 낮은 건만 검토 |
| 사내 문서 검색 | 스캔 문서를 표와 구조를 살린 텍스트로 바꿔 검색·질의응답에 활용 |