Indra OCR로 한글 PDF를 처리하려면 먼저 페이지에 쓸 수 있는 텍스트 레이어가 있는지 구분해야 합니다. 디지털 PDF의 한글을 가져오는 기능은 있지만, 스캔 이미지에서 한글을 인식하는 기능은 지원하지 않습니다. 한글 본문이 잘 나와도 삽입된 화면 캡처가 빠질 수 있고, --mode text를 지정해도 OCR로 넘어가는 경우가 있습니다. 한국어 문서를 검색 증강 생성(RAG)에 넣는 작은 팀이라면 처리 속도보다 이 경계를 먼저 확인하는 편이 좋습니다.
확인일: 2026년 10월 16일. 검토 대상: indra-ocr 0.3.2, 소스 커밋 3d773ae, 기본 모델 태그 v3.1.1. 공식 문서와 소스 코드를 검토한 도입 가이드입니다. 프로젝트 설치, OCR 실행, 성능 측정은 하지 않았습니다. 아래 네 가지 상황은 실제 실행 결과가 아닌 코드 경로에 따른 판단 예시입니다. 자료 조사와 정리에 AI를 활용했습니다.
Indra OCR은 어떤 도구인가요?
Indra OCR은 Datalab이 만든 CPU 중심 문서 처리 도구입니다. 글줄을 찾고 문자를 읽는 작업에 더해, 읽기 순서와 제목·목록·표 같은 구조를 추정하여 Markdown, 일반 텍스트, JSON으로 내보냅니다. 줄과 문서 블록의 좌표도 얻을 수 있어, 검색용 텍스트를 원문 위치와 연결하려는 경우에 검토할 만합니다.
공식 발표는 2026년 10월 13일이며, 확인 시점의 PyPI 패키지는 10월 15일 올라온 0.3.2입니다. GitHub Releases에 보이는 0.3.1과 구분해야 합니다. Python 3.10 이상을 요구하며, 프로젝트가 밝힌 테스트 범위는 Linux x86_64·aarch64의 Python 3.10~3.13과 Apple Silicon macOS입니다. 이 글에서 해당 환경을 직접 검증한 것은 아닙니다.
관심이 붙는 신생 프로젝트라는 근거도 있습니다. 10월 16일 14:29 UTC에 확인한 Trendshift의 날짜별 집계는 10월 14일 +168개, 15일 +149개의 스타 증가를 표시했습니다. 같은 날 확인한 GitHub 누적 스타는 387개였고, Hacker News의 공식 발표 링크는 37점을 기록했습니다. 집계 서비스의 날짜 구간이며 정확한 최근 24시간 측정은 아닙니다. 관심 신호일 뿐, 품질이나 운영 안정성을 입증하지는 않습니다.
한글을 ‘가져오는 것’과 ‘인식하는 것’은 다릅니다
텍스트 레이어는 PDF 안에 문자와 위치 정보로 저장된 내용입니다. OCR은 이미지의 픽셀을 보고 문자를 추정합니다. Indra의 공식 지원 범위에서 한글은 전자에 해당합니다. 이미지 OCR의 지원 문자에는 중국어가 포함되지만 한글은 포함되지 않습니다. 파일이나 모델 이름에 CJK가 있다고 해서 한·중·일 인식이 모두 되는 것으로 해석하면 안 됩니다.
기본값인 auto는 텍스트 레이어를 확인한 뒤 사용할 경로를 고릅니다. ocr는 텍스트 레이어를 읽지 않습니다. text는 얻어 놓은 텍스트가 있으면 일부 검사를 통과하지 못해도 사용하는 옵션입니다. 마지막 옵션이 어떤 입력에서도 OCR을 금지한다는 뜻은 아닙니다. 이 차이는 다음 네 상황에서 드러납니다.
같은 한글 PDF라도 네 가지로 나누기
1. 문서 편집기에서 만든 한글 PDF
문자 매핑이 정상이고 글줄을 찾을 수 있는 디지털 PDF라면, Indra는 한글을 이미지에서 다시 인식하지 않고 텍스트 레이어에서 가져올 수 있습니다. 이런 문서에서 좌표·읽기 순서·Markdown까지 필요하다면 도입 후보가 됩니다.
다만 텍스트 레이어가 있다는 사실만으로 모든 글자가 보존되는 것은 아닙니다. 소스에서는 문자를 검출된 글줄의 영역에 배정합니다. 영역 밖으로 빠진 문자가 있으면 note에 그 수를 남기는 경로가 있습니다. 따라서 제목 한 줄이 잘 나오는지보다, 본문 중간과 작은 주석까지 원문과 대조해야 합니다. 텍스트 페이지 처리 코드에서 확인할 수 있습니다.
2. 텍스트 레이어가 없는 한글 스캔
스캔 PDF나 이미지에는 가져올 한글 문자가 없으므로 OCR이 필요합니다. 이때 --mode text를 붙여도 한글 인식 기능이 생기지 않습니다. 페이지 분기 코드는 사용할 텍스트가 없으면 OCR 경로로 넘어갑니다.
이 유형은 현재 Indra만으로 처리하는 한국어 파이프라인에서 제외하는 편이 타당합니다. 잘못 읽힌 글자가 문장처럼 보인다는 이유로 검색 색인에 넣으면 이후 답변이 그 오류를 근거로 삼을 수 있습니다. 원문 페이지를 보관하고 한국어 인식을 지원하는 다른 경로에서 검증해야 합니다.
3. 한글 본문에 한국어 화면 캡처가 들어간 PDF
가장 놓치기 쉬운 경우입니다. 본문은 텍스트 레이어에서 가져오지만, 화면 캡처 안의 오류 메시지는 이미지로 남아 있습니다. Indra는 텍스트가 배정되지 않은 글줄에 OCR을 시도할 때, 기존 텍스트의 문자들을 인식기 어휘로 읽을 수 있는지도 확인합니다. 한글 본문에서 이 조건을 충족하지 못하면 이미지 안의 글줄은 OCR 대상에서 빠질 수 있습니다.
그 결과 source=text로 표시되어도 “본문은 있고 캡처 속 핵심 문장은 없는” 페이지가 가능합니다. 반대로 영문 본문에 한글 캡처가 붙었다면 OCR이 시도될 수도 있지만, 그것이 한글 지원을 뜻하지는 않습니다. 이미지 글줄을 처리하는 조건은 페이지 전체의 완전성을 검사하는 장치가 아닙니다.
검색에 필요한 내용이 캡처에 있다면 그 영역을 별도로 검토해야 합니다. --no-image-ocr는 해당 보조 OCR을 끄는 옵션일 뿐, 이미지 내용을 보존하거나 페이지 전체의 OCR 전환을 막아 주지는 않습니다.
4. 글자는 선택되지만 실체는 스캔과 숨겨진 OCR 레이어인 PDF
이미 OCR을 거친 스캔은 보이는 이미지 뒤에 인식된 텍스트를 숨겨 둘 수 있습니다. 복사·붙여넣기가 된다고 해서 새로 만든 디지털 문서와 같은 입력은 아닙니다.
Indra의 텍스트 레이어 검사가 숨겨진 OCR 레이어로 분류하는 경우에는 글줄을 추출하기 전에 빈 목록을 반환합니다. 그러면 --mode text에서도 사용할 줄이 없어 OCR 경로로 넘어갈 수 있습니다. 모든 검색 가능한 PDF가 이 조건에 해당한다는 뜻은 아닙니다.
이미 검증한 한국어 OCR 텍스트가 있다면 그것을 별도 추출 경로에서 보존하는 편이 낫습니다. 기존 텍스트의 품질도 불분명하다면 한국어 OCR로 다시 검토해야 합니다. 전 페이지를 --mode ocr로 강제하는 방식은 이 문제의 해결책이 되지 않습니다.
시작할 때는 Markdown보다 페이지별 JSON부터
처음에는 민감 정보가 없는 자체 샘플을 위 네 유형으로 준비하고, 중요한 한글 문구와 이미지 속 문구를 미리 적어 두는 방법을 권합니다. 다음은 공식 CLI와 소스를 기준으로 작성한 미실행 명령 예시입니다. Python 3.10 이상 환경에서 패키지와 모델의 이용 조건을 먼저 확인한 뒤 사용할 수 있습니다. sample.pdf는 직접 준비해야 하며, 앞 네 페이지만 보는 샘플 확인입니다.
python -m pip install 'indra-ocr==0.3.2'
indra-ocr sample.pdf --mode auto --format json \
--cores 2 --max-pages 4 --out review-json --timings문서화된 예상 산출물은 review-json/sample.jsonl입니다. 페이지마다 JSON 한 줄이 기록되며, page는 0부터 시작합니다. source는 텍스트 레이어, OCR, 혼합 또는 오류 경로를 나타내고, note와 lines, blocks, markdown을 함께 볼 수 있습니다. 실제 출력 파일을 생성해 확인한 예시는 아닙니다. JSON 출력 구현을 근거로 합니다.
여기서 source=text는 처리 경로를 알려 주며, 내용이 모두 들어왔다는 합격 표시는 아닙니다. 텍스트 레이어에서 가져온 줄에는 코드가 신뢰도 1.0을 부여하므로, 이 값도 “한글 OCR 정확도 100%”로 읽으면 안 됩니다. 첫 검토에서는 수식 인식을 켜지 않은 기본 조건을 유지하여, 어떤 글자가 어디에서 왔는지부터 확인하는 편이 단순합니다.
RAG에 연결할 때는 변환 결과를 바로 색인하지 말고 검토 대기 상태로 보관하는 구조를 제안합니다. 원문 파일·페이지와 JSON을 연결하고, 필수 문구나 이미지 속 핵심 내용이 빠진 페이지는 제외합니다. source=error인 페이지도 마찬가지입니다. 다른 추출기나 한국어 OCR로 보완한 뒤 같은 원문과 다시 대조하여, 통과한 페이지의 검색 조각만 교체합니다. 기존 색인이 있다면 새 변환이 끝나기 전에 덮어쓰지 않는 편이 복구하기 쉽습니다. 이 절차는 이 글의 운영 제안이며 Indra에 내장된 승인 기능이 아닙니다.
설치 전에 따로 봐야 할 모델 조건
코드는 Apache 2.0이지만, 모델 가중치는 수정된 OpenRAIL-M 라이선스입니다. 코드의 라이선스만 보고 상업 이용을 결정하면 안 됩니다. 모델 라이선스에는 사용자·고용주·소속 조직의 전년도 총매출 또는 누적 지분·부채 조달액이 각각 2천만 달러를 초과하는 경우의 제한이 있습니다. 이 두 항목에는 개인 이용·연구 목적 예외가 있지만, 별도로 제공자나 그 계열사의 제품·서비스와 경쟁하는 제품·서비스를 제공하는 경우도 제한합니다.
또한 7조는 출력물에 관한 출처 표시를, 8조는 출력물과 그 파생물까지 포함하는 동일 라이선스 적용 조건을 명시합니다. RAG 자료나 고객 제공 결과물에 어떻게 적용할지는 원문을 확인하고, 불명확하면 제공자와 법률 검토를 통해 정리해야 합니다. “작은 팀이니 자유롭게 상용화해도 된다”는 결론을 이 글에서 내리지 않습니다.
기본 모델은 첫 실행 때 Hugging Face에서 내려받습니다. 0.3.2의 모델 로딩 코드는 캐시를 사용하면서 주기적으로 Hub를 확인하고, 명시한 로컬 모델 폴더를 사용하는 경로도 제공합니다. 로컬 문서 처리와 네트워크 요청이 전혀 없다는 조건은 구분해야 합니다. CPU 실행도 처리 시간과 메모리 비용이 들며, 이 글에서는 이를 측정하지 않았습니다.
어떤 경우에 도입할까요?
디지털 PDF의 텍스트만 필요하다면 pypdf 같은 기존 추출기로 충분한지 먼저 볼 수 있습니다. pypdf는 이미지 OCR 도구가 아니므로 한글 스캔을 해결해 주지는 않습니다. 한글 스캔에는 한국어 모델 kor를 제공하는 Tesseract 같은 별도 OCR 후보를 실제 샘플로 평가할 수 있습니다. 언어 모델이 존재한다는 사실과 내 문서에서 충분한 정확도가 나온다는 판단은 별개입니다.
Indra가 더 흥미로운 경우는 입력이 지원 범위에 맞고, 텍스트뿐 아니라 글줄 좌표·읽기 순서·문서 구조가 필요한 때입니다. 다만 복잡한 병합 표, 손글씨, 저화질 스캔은 프로젝트도 한계로 밝힙니다. 공개된 지 며칠 된 프로젝트이므로 작은 샘플에서 시작하고 기존 추출 경로를 남겨 두는 편이 좋습니다.
한글 PDF 한 장이 잘 변환됐다는 사실을 한국어 문서 전체에 대한 지원으로 확대하지 않는 것이 핵심입니다. 페이지가 디지털 텍스트인지, 스캔인지, 이미지가 섞였는지에 따라 처리 경로를 나누고, 불확실한 페이지를 검색에 넣지 않을 수 있을 때 도입 가치가 분명해집니다.
댓글
댓글 쓰기