OCR이 깨진 텍스트를 생성하는 이유?
3가지 근본 원인과 해결 방법
문서를 OCR로 처리했지만, 깔끔한 텍스트 대신 é, ’, 물음표로 가득 찬 상자, 또는 키보드를 계단에서 떨어뜨린 듯한 문자열을 얻었습니다. 이 현상 — 모지바케(文字化け, 일본어로 "문자 변형")라고 함 — 에는 기술적인 근본 원인이 있으며, 이를 이해하면 수정이 간단해집니다.
핵심 요약
é가 있어야 할 곳에 보이는é는 손상된 데이터가 아니라 Windows-1252 렌즈를 통해 해석된 UTF-8 바이트이며, 읽기 렌즈를 전환하면 파일의 모든 문자가 즉시 복원됩니다.- 깨진 OCR을 생성하는 세 가지 뚜렷한 원인(인코딩 불일치, 손상된 글꼴 맵, 저해상도 문자 교체)이 있으며, 각각은 도구를 열기 전에 어떤 수정 방법을 사용해야 하는지 알려주는 진단 지문을 남깁니다.
- 가장 고질적인 깨진 텍스트 사례는 OCR이 시각적 이미지가 아닌 PDF 내부의 손상된 숨겨진 텍스트 레이어를 읽기 때문에 발생합니다. OCR이 렌더링된 페이지를 직접 읽도록 강제하면 깨짐이 사라집니다.
깨진 텍스트가 보인다면, 당신만 그런 게 아닙니다. 레딧 커뮤니티는 사람들이 자신의 모지바케가 "어떤 언어일지" 알아내기 위해 존재합니다. Adobe Acrobat 커뮤니티 포럼에는 일본어 OCR에서 蟷エ莉」繧「繧ク繧「縺ォ縺翫¢繧九げ繝ュ繝シ繝舌Ν蛹悶� 같은 문자열이 나와 읽을 수 없는 텍스트 대신 출력된 사용자들의 수십 개의 미해결 스레드가 있습니다. Python ftfy 라이브러리 — 모지바케를 수정하는 전용 도구 — 는 이 문제가 반복적이고 업계 전반적인 문제이기 때문에 수백만 번 다운로드되었습니다.
좋은 소식: 깨진 OCR 텍스트는 무작위 손상이 아닙니다. 세 가지 근본 메커니즘 중 하나로 인해 예측 가능한 패턴을 따릅니다. 패턴을 식별하면 수정도 반복 가능합니다.
원인 1 — 인코딩 불일치: 가장 흔한 원인
증상: 악센트 문자, 통화 기호, 스마트 따옴표가 여러 문자로 깨집니다. 스페인어 corazón은 corazón이 됩니다. 유로 기호 €는 €로 나타납니다. 곱슬 따옴표는 “이렇게 보입니다â€. 문서는 대부분 읽을 수 있지만, 모든 비ASCII 문자가 잘못 표시됩니다.
발생 이유: 문자 인코딩은 파일과 리더 간의 바이트를 문자로 매핑하는 규칙입니다. OCR 엔진이 파일을 한 인코딩(예: UTF-8)으로 읽지만 파일이 다른 인코딩(예: Windows-1252)으로 생성된 경우, 동일한 바이트가 완전히 다른 문자로 매핑됩니다. 결과는 체계적인 손상입니다 — 인치 단위로 그린 지도를 센티미터로 읽는 것과 같습니다. 모든 측정값이 동일한 비율로 어긋나며, 잘못된 패턴이 어떤 변환이 적용되었는지 정확히 알려줍니다.
어떤 인코딩 불일치 문제인지 확인하는 방법
특정 모지바케 패턴은 출력 결과만 보고도 인코딩 오류를 진단할 수 있을 정도로 독특합니다:
| 이렇게 보인다면 | 원본 인코딩 | 잘못 읽힌 인코딩 |
|---|---|---|
é (원래 é) | UTF-8 | Latin-1 / Windows-1252 |
’ (원래 ') | UTF-8 | Windows-1252 |
– (원래 –, 반각 대시) | UTF-8 | Windows-1252 |
日本 (원래 日本) | Shift-JIS | UTF-8 또는 Latin-1 |
네모 ▯▯▯ 또는 ???? | 유니코드 | 시스템 폰트 누락 / 인코딩 오류 |
인코딩 불일치 해결 방법
방법 1: 올바른 인코딩으로 다시 저장. VS Code나 Notepad++처럼 인코딩을 명시적으로 변경할 수 있는 텍스트 편집기에서 원본 문서(또는 OCR 출력)를 엽니다. 다른 이름으로 저장 → UTF-8을 선택하세요. 파일이 원래 Windows-1252였다면, 문자 감지를 제대로 하여 UTF-8로 다시 저장하면 대부분 해결됩니다.
방법 2: 모지바케 복구 도구 사용. 대량 또는 자동 수정의 경우 ftfy Python 라이브러리(pip install ftfy)가 일반적인 인코딩 오류를 자동으로 감지하고 되돌립니다. 여기에는 텍스트가 잘못된 인코딩으로 디코딩된 후 다시 인코딩되고 두 번째로 잘못 디코딩되는 다중 계층 손상도 포함됩니다. ftfy.fix_text() 한 번 호출로 대부분의 단일 및 이중 인코딩 오류를 처리할 수 있습니다.
방법 3: OCR 엔진이 텍스트 레이어 대신 이미지 레이어를 다시 읽도록 강제. PDF에서 깨진 텍스트 문제는 대개 PDF 자체의 텍스트 레이어가 손상되었거나 사용자 지정 인코딩으로 되어 있는 반면, 시각적 이미지 레이어는 완벽할 때 발생합니다. OCR 도구를 페이지를 이미지로 처리하도록 설정하면(기존 텍스트 레이어에서 추출하는 대신) 렌더링된 글리프에서 모든 문자를 다시 인식하여 인코딩 손상을 우회합니다. Adobe Acrobat에서는 OCR 설정에서 "Searchable Image (Compact)" 대신 "ClearScan" 또는 "Searchable Image (Exact)"를 선택하면 됩니다.
핵심 포인트: 인코딩 불일치 모지바케는 가장 쉽게 복구할 수 있는 유형입니다. 데이터가 손실된 것이 아니라 잘못된 키로 읽힌 것이기 때문입니다. 올바른 키를 찾으면 모든 문자가 원래대로 복원됩니다.
원인 2 — 글꼴 인코딩: 글리프는 올바르지만 문자 코드가 잘못된 경우
증상: PDF가 화면에 완벽하게 렌더링되어 모든 문자가 올바르게 보이지만, 텍스트를 복사하거나 OCR을 실행하면 GLYPH<38>, 9%)A:\2A 또는 의미 없는 문자 시퀀스가 반복됩니다. 화면상의 페이지는 깨끗하지만 텍스트 레이어는 엉망입니다.
발생 원인: PDF 파일에는 "텍스트"의 두 가지 레이어가 있습니다. 시각적 글리프(화면에 렌더링되어 보이는 것)와 문자-글리프 매핑(텍스트 추출기나 OCR 엔진이 읽는 것)입니다. 일반적으로 이 두 레이어는 일치합니다. 하지만 제대로 생성되지 않은 PDF에서는 글꼴 파일에 사용자 정의 글리프 인코딩이 포함될 수 있습니다. 글리프 모양은 올바르므로(페이지가 정상적으로 보임) 매핑되는 문자 코드가 비표준이거나 유니코드 매핑이 완전히 누락된 경우입니다.
이 상황은 놀랍도록 흔합니다. 문서에 사용된 정확한 문자만 포함하는 서브셋 글꼴은 내부 매핑에 비표준 문자 ID(CID)를 사용하는 경우가 많습니다. 텍스트 추출기가 표준 인코딩 테이블을 사용하여 해당 CID를 해석하려고 하면 쓰레기 값이 생성됩니다. Docling 프로젝트에 보고된 이슈에서 정확히 이 현상이 나타났습니다. PDF는 정상적으로 표시되고 OCR은 do_ocr=True로 설정되었지만 출력은 '() +,- .+.. /01 02034567638469:; 4<8:=>였습니다. 이는 글꼴의 내부 인코딩이 표준 유니코드에 매핑되지 않았기 때문입니다.
글꼴 인코딩 문제로 인한 쓰레기 값이 가장 자주 발생하는 시나리오:
- 전문 소프트웨어로 생성된 PDF: CAD 도구(AutoCAD, Archicad), ERP 보고서 생성기 또는 레거시 인쇄-PDF 드라이버는 종종 사용자 정의 인코딩 테이블이 포함된 글꼴을 포함합니다. Adobe 포럼의 커뮤니티 토론에서는 Archicad 사용자의 PDF에 Segoe UI가 포함되어 있었지만 여전히 깨진 텍스트가 생성되었다고 설명합니다. 포함만으로는 표준 문자 매핑이 보장되지 않기 때문입니다.
- PDF/A 또는 디지털 서명된 문서: 규정 준수 지향 문서 형식은 변환 과정에서 문자 매핑 정보를 제거하거나 수정하는 경우가 있습니다.
- 이전 OCR 패스에서 숨겨진 텍스트 레이어가 추가된 스캔 문서: 이전 OCR이 잘못된 문자를 생성했고 PDF가 해당 텍스트 레이어와 함께 저장된 경우, 이후 추출 시 새로운 인식 대신 캐시된 잘못된 텍스트를 읽습니다.
- 비라틴 문자를 사용하는 문서: 일본어 Shift-JIS 글꼴, 한국어 EUC-KR 글꼴, 중국어 GB 인코딩 글꼴은 PDF 뷰어나 OCR 엔진이 다른 코드 페이지를 기본값으로 사용할 때 인코딩 불일치의 빈번한 원인입니다.
글꼴 인코딩 깨짐 해결 방법
방법 1: 이미지 레이어에서 강제로 새 OCR 실행. 가장 확실한 방법입니다. OCR 도구가 기존 텍스트 레이어를 무시하고 페이지 이미지에서 직접 읽도록 설정하세요. Acrobat Pro에서는 도구 → 스캔 및 OCR → 텍스트 인식 → 이 파일에서로 이동하여 OCR 엔진이 문서를 스캔된 이미지로 처리하도록 하세요. ocrmypdf에서는 --force-ocr 플래그를 사용하여 기존 텍스트 레이어를 완전히 덮어씁니다.
방법 2: 무손실 이미지 형식으로 변환 후 재OCR. PDF 페이지를 고해상도 TIFF 또는 PNG 파일(최소 300 DPI)로 내보낸 후 해당 이미지에서 OCR을 실행하세요. 이렇게 하면 깨진 글꼴 인코딩 메타데이터가 모두 제거되고 OCR 엔진에 깨끗한 시각적 원본이 제공됩니다. Adobe Acrobat 커뮤니티의 일본어 모지바케 관련 게시글에 따르면, TIFF로 내보낸 후 재OCR하면 직접 PDF OCR이 실패했던 문제가 해결되었습니다.
방법 3: Preflight로 글꼴 포함 여부 확인. Adobe Acrobat Pro에서 도구 → 인쇄물 제작 → Preflight로 이동하여 글꼴 분석 프로필을 실행하세요. 이를 통해 글꼴이 완전 포함되었는지, 하위 집합으로 포함되었는지, 누락되었는지, 유니코드 문자 맵이 포함되었는지 확인할 수 있습니다. 글꼴이 적절한 /ToUnicode 테이블 없이 하위 집합으로 포함되어 있다면 그것이 바로 문제의 원인입니다.
원인 3 — 해상도와 문자 혼동: 이미지 품질이 OCR을 실패하게 할 때
증상: 개별 문자가 합리적으로 보이는 대체 문자로 잘못 인식됩니다: 5가 S로, 0이 O로, 1이 l(소문자 L)로, rn이 m으로 바뀝니다. 구두점이 사라집니다. e나 a 같은 문자의 가는 획이 누락되어 단어가 축약된 것처럼 보입니다. 출력이 완전히 엉망인 것은 아니지만 미묘하고 답답하게 틀립니다.
발생 이유: OCR 엔진은 알려진 글리프 모델과 문자 모양을 일치시켜 작동합니다. 입력 이미지의 해상도가 충분하지 않으면 사용 가능한 픽셀 수가 시각적으로 유사한 문자를 구분하기에 부족합니다. 72 DPI에서 문자 S는 세로로 약 10~12픽셀을 차지합니다. 이 해상도에서는 5의 세리프와 S의 곡선이 동일하게 보일 수 있습니다. 이는 인코딩 문제가 아니라 근본적인 정보 이론의 한계입니다. 이미지에 각 문자의 구별되는 특징을 표현할 충분한 픽셀이 포함되어 있지 않다면, 아무리 고급 OCR 엔진이라도 매번 완벽하게 추측할 수 없습니다.
이러한 유형의 오류는 특히 다음에서 흔히 발생합니다:
- 저조도나 비스듬한 각도에서 촬영한 문서의 휴대폰 사진
- 세대를 거듭할수록 세부 정보가 손실되는 팩스 또는 반복 복사된 페이지
- 역사 기록의 오래된 마이크로필름 스캔
- 200 DPI 이하로 스캔된 작은 글꼴 크기(8포인트 이하)의 문서
해상도 관련 글자 깨짐 해결 방법
방법 1: 입력 해상도 높이기. OCR의 업계 표준은 최소 300 DPI이며, 작거나 빽빽한 텍스트의 경우 400–600 DPI를 권장합니다. 휴대폰 사진으로 작업하는 경우, OCR 엔진에 이미지를 보내기 전에 이미지 전처리 단계(업스케일링, 선명화, 기울기 보정 등)가 도움이 될 수 있습니다.
방법 2: 기존 OCR 대신 비전 기반 추출 도구 사용. 이는 구조적인 해결책입니다. 기존 OCR 엔진(Tesseract, ABBYY, Adobe OCR)은 문자 단위 패턴 매칭에 의존합니다. 그래서 픽셀 하나가 누락되면 5가 S로 바뀔 수 있습니다. 최신 비전-언어 모델(VLM) 추출(ImageToTable.ai 및 유사 도구에서 사용하는 방식)은 단어와 문장 전체를 시각적 객체로 읽고, 의미적 맥락을 사용하여 모호성을 해결합니다. 엔진이 "Order S units"를 보고 주변 맥락이 인보이스라면, S가 5일 가능성이 높다고 이해합니다. 문자 모양을 더 잘 인식해서가 아니라, "Order 5 units"가 "Order S units"보다 말이 되기 때문입니다. 이것이 기존 OCR과 어떻게 다른지에 대한 설명은 OCR이 무엇이고 그 한계가 어디에서 오는지를 읽어보세요.
방법 3: OCR 전에 이미지 전처리 적용. 간단한 전처리만으로도 문자 혼동을 크게 줄일 수 있습니다. 회색조 변환, 적응형 임계값 적용으로 텍스트 이진화, 노이즈(얼룩, 배경 패턴) 제거는 OCR 엔진에 더 깨끗한 신호를 제공합니다. 현장에서 검증된 전처리 워크플로우는 OCR 정확도 향상 가이드를 참조하세요.
해결되지 않을 때: 모든 방법이 실패한 경우 대처법
인코딩을 확인하고, 글꼴을 점검하고, 이미지를 전처리했는데도 출력이 여전히 깨진다면, 해당 도구가 문서 유형에 적합하지 않을 수 있습니다. 혼합 스크립트, 장식용 글꼴, 수학 기호, 또는 심한 스탬프 오버레이가 있는 문서는 기존 OCR의 설계 한계를 넘어섭니다.
이런 경우, 실용적인 해결책은 문서를 전체적으로 읽는 템플릿 없는 비전-AI 추출 도구로 전환하는 것입니다. ImageToTable.ai와 같은 도구는 인코딩 및 글꼴 문제를 완전히 우회합니다. 페이지의 시각적 렌더링에서 의미를 추출하기 때문입니다. 문서를 업로드하고, 원하는 열 이름을 지정하면, AI가 문서의 시각적 및 의미적 구조를 이해하여 데이터를 추출합니다. 글꼴에 의존하는 텍스트 레이어나 인코딩 테이블에 대해 걱정할 필요가 없습니다.
자주 묻는 질문
화면에서 PDF가 정상적으로 보이는데 복사하면 글자가 깨지는 이유는 무엇인가요?
거의 항상 글꼴 인코딩 문제(원인 2)입니다. PDF의 시각적 레이어는 올바르게 렌더링된 글리프를 사용하지만, 문자-유니코드 매핑이 손상되었거나 비표준입니다. PDF 리더는 글리프를 완벽하게 표시하지만, 텍스트를 복사하거나 OCR 엔진이 숨겨진 텍스트 레이어를 읽을 때 손상된 매핑을 따라가며 깨진 텍스트가 생성됩니다. 해결 방법은 기존 텍스트 레이어를 무시하고 이미지 레이어에서 직접 OCR을 수행하는 것입니다.
깨진 OCR 텍스트를 소프트웨어로 자동 수정할 수 있나요?
네, 인코딩 불일치 모지바케(원인 1)의 경우 ftfy(Python), iconv(Linux/macOS), VS Code와 같은 편집기의 '인코딩 감지' 기능을 사용하여 손상을 자동으로 식별하고 되돌릴 수 있습니다. 글꼴 인코딩 및 해상도 문제의 경우, 문제가 바이트-문자 매핑이 아닌 원본 데이터 자체에 있기 때문에 자동 복구의 신뢰도가 낮습니다. 이러한 경우에는 다른 설정이나 다른 추출 방식으로 재처리해야 합니다.
DPI가 높으면 항상 깨진 OCR이 수정되나요?
높은 DPI는 해상도 관련 문자 혼동(원인 3)을 해결하지만, 인코딩 불일치(원인 1)나 글꼴 인코딩 문제(원인 2)에는 영향을 미치지 않습니다. 원본 파일이 손상된 /ToUnicode 테이블이 있는 PDF인 경우 600 DPI로 스캔해도 도움이 되지 않습니다. 단지 동일한 근본 문제의 고해상도 버전을 생성할 뿐입니다. 재스캔에 투자하기 전에 근본 원인을 진단하세요.
ImageToTable.ai가 기존 OCR보다 깨진 텍스트를 더 잘 처리하나요?
ImageToTable.ai는 중간 텍스트 레이어가 아닌 문서의 시각적 콘텐츠를 읽는 비전-언어 모델을 사용하기 때문에 인코딩 불일치 및 글꼴 인코딩으로 인한 깨진 텍스트 문제를 모두 우회합니다. AI가 렌더링된 페이지 이미지를 직접 처리하므로 사용자 정의 CID 매핑, 서브셋 글꼴, 누락된 /ToUnicode 테이블이 간섭하지 않습니다. 해상도 관련 모호성의 경우, 문서 컨텍스트에 대한 모델의 의미론적 이해는 문자 기반 OCR이 부족한 추가적인 보정 계층을 제공합니다. 그러나 원본 이미지 자체가 심각하게 손상된 경우(흐릿함, 매우 낮은 해상도, 부분적으로 판독 불가), 비전 AI를 포함한 어떤 접근 방식도 캡처되지 않은 정보를 복구할 수 없습니다.
깨진 OCR 텍스트는 무작위가 아닙니다 — 이제 이렇게 대처하세요
OCR 결과가 알파벳을 뒤섞은 듯 보일 때, 소프트웨어 탓하고 넘어가고 싶어집니다. 하지만 여기서 다룬 세 가지 원인 — 인코딩 불일치, 폰트 인코딩 문제, 해상도 기반 문자 혼동 — 각각은 고유한 특징과 해결책이 있습니다. 이를 구분하는 법을 익히면 답답한 미스터리를 반복 가능한 진단으로 바꿀 수 있습니다.
증상부터 시작하세요: 악센트 주변의 여러 문자 깨짐(예: é) → 인코딩 불일치, 재인코딩 또는 ftfy로 해결. 화면 표시는 완벽하지만 OCR이 엉뚱한 글자를 출력 → 폰트 인코딩 문제, 이미지 레이어 OCR 강제로 해결. 개별 문자가 비슷한 모양으로 바뀜(5→S) → 해상도 문제, 전처리 또는 문맥 인식 도구로 해결.
마지막 옵션 — 문자 기반 OCR에서 비전 기반 추출로 전환 — 은 문서를 사람처럼 읽음으로써 근본 원인을 완전히 우회합니다. 즉, 픽셀 패턴을 매칭하거나 인코딩 테이블을 탐색하는 대신 의미를 이해하는 방식입니다.
직접 깨진 문서로 테스트해 보세요. 엔진이 더 이상 텍스트 레이어에 의존하지 않을 때 문제가 사라지는지 확인하십시오.