목차
스캔된 PDF/이미지 문서를 OCR로 텍스트화한 뒤 RAG(검색 증강 생성)으로 연결해, 사내 문서 검색·요약·업무 자동화를 실무 수준으로 구현하는 단계별 가이드.
- 스캔→OCR→전처리→임베딩→벡터DB→검색→LLM 응답 흐름의 핵심 병목 3곳.
- 실무 비용·성능 비교표와 보안·정합성 체크리스트로 PoC부터 프로덕션 전환까지 로드맵 제공.
- 현업 사례 기반 아키텍처와 설정 팁으로 엔지니어·기획자가 바로 적용 가능한 체크포인트 수록.
매일 엑셀 반복 작업에 시달리던 실무자 A씨는, 스캔 보관된 계약서·회의록을 찾는 데 평균 15분을 소비했다. AI 서비스 도입을 고민하던 기획자 B씨는 ‘검색봇이 문서 안 표와 손글씨까지 이해할 수 있을까’라는 질문으로 팀을 멈추게 했다.
스캔문서 기반 RAG(검색 증강 생성) 챗봇을 실무에 도입하는 방법을 단계별로 정리한다.
스캔문서→RAG: 실무자 A씨의 하루 흐름을 재설계하기
우선 전체 파이프라인을 한 문장으로 정리하면 다음과 같다. 스캔(이미지/PDF) → 전처리(기울기·노이즈 제거) → OCR(텍스트 추출) → 구조화(메타데이터, 표·이미지 분리) → 토큰화·임베딩 → 벡터DB 저장 → 검색(유사도, 페이징) → LLM 질의 응답(컨텍스트 윈도잉/응답 검증). 각 단계에서 품질·비용·보안 트레이드오프가 발생한다.
실무 요구사항을 빠르게 확인하는 체크리스트: (1) 문서 유형(스캔·디지털), (2) 글자체·언어·손글씨 비율, (3) 표·양식/비정형 텍스트 비율, (4) 검색 응답 SLA(초), (5) 보안·로그 보관 정책. 이 중 손글씨·표 인식과 개인정보(PII) 마스킹이 가장 비용과 시간 소요가 크다.
OCR 선택 시 고려 요소는 인식률(특히 한글), 표/레이아웃 복원력, API 지연, 로컬 배포 가능성, 비용 모델(요금/문서당/문자량)이다. 오픈소스(Tesseract 등)는 커스터마이징과 비용 절감 장점이 있지만, 표·레이아웃 복원 및 한글 정확도는 상용 서비스에 비해 떨어지는 경우가 많다.
초기 PoC 권장 조합(속도·비용 균형): 상용 OCR(예: Google Vision/Azure OCR)로 품질 검증 후, 임베딩은 비용 효율적인 오픈 임베딩(혹은 클라우드 임베딩)으로 테스트, 벡터DB는 관리 편의성을 고려해 Faiss/Weaviate/PGVector 중 선택한다.
OCR·임베딩 툴 성능과 비용 비교 – 실무 기준 표
| 툴/서비스 | 한글 OCR 정확도(대체평가) | 표/레이아웃 복원 | 임베딩 연결성 | 추정 비용(중규모 월) |
|---|---|---|---|---|
| Google Cloud Vision | 높음 | 상(구조 추출 API 제공) | OpenAI/Google 임베딩 연동 쉬움 | 중간~높음 |
| Azure Cognitive Services | 높음 | 상(포맷·표 추출 지원) | Azure OpenAI/타임스탬프 연동 | 중간 |
| AWS Textract | 중간~높음 | 상(양식·표에 최적) | AWS SageMaker/임베딩 연동 | 중간 |
| Tesseract (오픈소스) | 중간(튜닝 필요) | 낮음(추가 파서 필요) | 자체 파이프라인 필요 | 낮음(인프라 비용) |
| 임베딩(예: OpenAI / Mistral 계열) | – | – | 높음(플러그인/SDK 다양) | 요청량 기반 |
위 표는 실무 수치가 아니라 비교 판단의 기준을 제공한다. 실제 성능은 문서 품질·언어·레이아웃에 따라 달라진다.
벡터DB 선택은 검색 지연·확장성·운영 편의성(관리형 vs 자체 호스팅)에 따라 달라지므로, PoC에서 미리 벤치마크가 필요하다.
🔗 Google Cloud Vision 공식 문서 바로가기
🔗 Azure Cognitive Services OCR 안내
OCR 단계에서 텍스트 추출 품질이 낮으면 이후 임베딩/검색 성능은 회복 불가능하다. PoC 초기에 다양한 스캔 품질 케이스(저해상도, 기울기, 손글씨)를 준비해 OCR 모델별 정합성을 측정하라.
스캔·RAG 도입 단계별 구현 및 주의 포인트
단계별 구현 권장 방식(핵심 기술만 요약):
- 수집: 스캔 표준(300dpi 이상, 흑백/그레이스케일 정책) 수립, 파일 네이밍·메타데이터 규칙 정의.
- 전처리: 이미지 정렬·기울기 보정, 노이즈 제거, 페이지 분리·합치기 규칙 적용.
- OCR: 샘플 기반 엔진 비교, 표/양식은 전용 라인(예: AWS Textract) 고려.
- 구조화: 표·이미지·주석·각주 분리 후 JSON 스키마로 저장(문서ID, 페이지, 영역, confidence 포함).
- 임베딩: 문서 단위를 너무 크게 잡지 말 것(단락·문단 단위 권장), 키워드 인덱스와 결합해 검색 성능 개선.
- 벡터DB: 유사도 검색 + 페이징·재랭크(LLM) 조합으로 재현성 확보.
- LLM 응답: 소스 문서 근거() 포함·출처 표기, 확신도 임계값 설정.
생산 환경 전환 시 반드시 점검할 보안·정합성 항목
사내 문서에는 고객정보·계약상 세부조항 등 민감데이터가 포함된다. RAG 시스템은 LLM 생성 과정에서 ‘hallucination’이 발생할 수 있으므로, 다음 항목을 반드시 설계에 반영해야 한다.
- 데이터 거버넌스: 어떤 문서가 외부 API로 유출되는가(데이터 레지스트리 작성).
- PII 식별·마스킹: OCR 후 자동 PII 스캐너로 민감정보 마스킹 또는 접근 제어.
- 로그·감사: 사용자 질의·응답·참조 문서 이력 저장(규정 준수 목적).
- 응답 검증: LLM 응답에 소스 을 붙이고, 확신도 미만은 ‘참고용’ 표기 또는 인간 리뷰 루프 적용.
- 접근 통제: 벡터DB/스토리지/LLM 토큰·네트워크 접근을 IAM으로 엄격 관리.
임베딩 생성 전 텍스트 정규화(특수문자·공백·줄바꿈 제거)는 검색 일관성을 크게 개선한다. 문서 단위가 아니라 ‘문단 단위’ 임베딩을 기본으로 하되, 표·양식은 별도 인덱스로 관리하라.
현업 도입을 앞둔 엔지니어·기획팀을 위한 전문가 팁
로드맵(단계·소요기간·검증 포인트):
- PoC(2-4주): 100~500문서로 OCR+임베딩+기본 검색 검증(정확도·응답시간 측정).
- 확장성 테스트(4주): 벡터DB 100k~1M 임베딩으로 쿼리 지연 및 비용 시뮬레이션.
- 보안·규정 확인(2주): PII 검출률·로그 정책·내부 감사 프로세스 수립.
- 사용성 개선(2-4주): 검색 질의 템플릿, 페르소나 기반 프롬프트, 응답 요약 스타일 설정.
- 데브옵스·모니터링(지속): 임베딩 재생성 정책, 임계값 기반 재색인, 에러·품질 대시보드 구축.
비용 산정 팁: OCR 비용 = 페이지 수 × OCR 단가, 임베딩 비용 = 임베딩 요청량 × 임베딩 단가, LLM 재랭크 비용 = 재랭크 호출 빈도 × 모델 단가. 대용량 환경에서는 임베딩 캐시와 쿼리 필터(메타데이터)로 API 호출을 줄이는 것이 핵심이다.
🤖 팀즈·아웃룩 업무흐름 자동화
운영 지표와 실패 사례로부터 얻는 실무 교훈
실패 사례 요지: 표·양식이 많은 문서를 그대로 임베딩해버리면 의 관련성이 급격히 떨어진다. 또, OCR confidence를 무시하고 임베딩을 생성하면 벡터DB에 잡음이 쌓여 재색인을 해야만 문제 해결이 가능하다.
운영 지표(예시): 검색 응답시간(95p) < 500ms, 문서 검색 정답률(Top3) ≥ 85%, LLM hallucination 비율 < 3% (감사 케이스 기준). 이 지표는 SLA와 법규 준수 요건에 따라 조정해야 한다.
개선 루프 권장: 주기적 샘플링(주간) → OCR 오류 유형 분류 → 템플릿·전처리 규칙 추가 → 재학습(임베딩 재생성) → 성능 비교. 이 사이클을 자동화하면 운영 비용이 대폭 줄어든다.
실무 도입 시 흔히 묻는 질문 3가지(간단 답변)
- Q: 손글씨도 되나? A: 제한적 가능-손글씨 비중이 높다면 별도 OCR(손글씨 전용) 모델 또는 인력 검수 워크플로가 필요.
- Q: 벡터DB는 자체 호스팅이 좋은가? A: 초기에는 관리형 서비스로 속도·운영 부담을 낮추고, 트래픽·비용이 확실해지면 자체 호스팅 고려.
- Q: LLM이 잘못된 정보를 만들어도 되나? A: 반드시 ‘출처 표기 + 확신도 임계값’으로 위험을 통제해야 한다.
시작 팁: PoC에서 ‘문단 단위 임베딩’과 ‘표/양식의 별도 인덱스’라는 두 규칙만 지켜도 검색 품질이 크게 개선된다. 또한, 사용자 인터페이스에 ‘원문 보기’ 기능을 넣어 LLM 응답에 대한 신뢰도를 높여라.