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 | Latin-1 / Windows-1252 |
’ (원래 ') | UTF-8 | Windows-1252 |
– (원래 –, 반각 대시) | UTF-8 | Windows-1252 |
日本 (원래 日本) | Shift-JIS | UTF-8 또는 Latin-1 |
네모 ▯▯▯ 또는 ???? | 유니코드 | 시스템 폰트 누락 / 인코딩 오류 |
인코딩 불일치 해결 방법
방법 1: 올바른 인코딩으로 다시 저장. VS Code나 Notepad++처럼 인코딩을 명시적으로 변경할 수 있는 텍스트 편집기에서 원본 문서를 엽니다. 다른 이름으로 저장 → 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 파일에는 두 가지 "텍스트" 레이어가 있습니다. 시각적 글리프와 문자-글리프 매핑입니다. 일반적으로 이 두 레이어는 일치합니다. 하지만 제대로 생성되지 않은 PDF에서는 글꼴 파일에 사용자 지정 글리프 인코딩이 포함될 수 있습니다. 글리프 모양은 올바르므로 매핑되는 문자 코드가 비표준이거나 Unicode 매핑이 완전히 누락된 경우입니다.
이 상황은 의외로 흔합니다. 문서에 사용된 정확한 문자만 포함하는 서브셋 글꼴은 내부 매핑에 비표준 문자 ID(CID)를 사용하는 경우가 많습니다. 텍스트 추출기가 표준 인코딩 테이블로 해당 CID를 해석하려고 하면 깨진 결과가 나옵니다. Docling 프로젝트에 보고된 이슈에서 정확히 이 문제를 보여줍니다. PDF가 정상적으로 표시되고 OCR이 do_ocr=True로 설정되었는데 출력이 '() +,- .+.. /01 02034567638469:; 4<8:=>였습니다. 글꼴의 내부 인코딩이 표준 Unicode에 매핑되지 않았기 때문입니다.
글꼴 인코딩 깨짐이 가장 흔한 시나리오:
- 전문 소프트웨어로 생성된 PDF: CAD 도구(AutoCAD, Archicad), ERP 보고서 생성기 또는 레거시 인쇄- PDF 드라이버는 사용자 지정 인코딩 테이블이 있는 글꼴을 포함하는 경우가 많습니다. Adobe 포럼의 커뮤니티 토론에서는 Segoe UI가 포함된 PDF에서도 여전히 깨진 텍스트가 생성된 Archicad 사용자 사례를 설명합니다. 포함만으로는 표준 문자 매핑이 보장되지 않기 때문입니다.
- 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 파일로 내보낸 다음 해당 이미지에서 OCR을 실행하세요. 이렇게 하면 손상된 글꼴 인코딩 메타데이터가 모두 제거되고 OCR 엔진에 깨끗한 시각적 소스가 제공됩니다. 일본어 문자 깨짐에 관한 Adobe Acrobat 커뮤니티 스레드에서 직접 PDF OCR이 실패한 경우 TIFF로 내보낸 후 다시 OCR을 실행하면 문제가 해결된다는 것을 확인했습니다.
옵션 3: Preflight로 글꼴 포함 여부 확인. Adobe Acrobat Pro에서 도구 → 인쇄물 제작 → Preflight로 이동하여 글꼴 분석 프로필을 실행하세요. 이를 통해 글꼴이 완전히 포함되었는지, 하위 집합으로 포함되었는지, 누락되었는지, 유니코드 문자 맵이 포함되어 있는지 확인할 수 있습니다. 글꼴이 적절한 /ToUnicode 테이블 없이 하위 집합으로 포함된 경우, 그것이 바로 문제의 결정적 증거입니다.
원인 3 — 해상도와 문자 혼동: 이미지 품질이 OCR을 실패하게 만들 때
증상: 개별 문자가 그럴듯한 대체 문자로 잘못 인식됩니다: 5가 S로, 0이 O로, 1이 l로, rn이 m으로 바뀝니다. 구두점이 사라집니다. e나 a 같은 문자의 가는 획이 누락되어 단어가 축약된 것처럼 보입니다. 출력이 완전히 깨진 것은 아니지만 미묘하게, 답답할 정도로 잘못된 결과입니다.
발생 이유: OCR 엔진은 알려진 글리프 모델과 문자 모양을 대조하여 작동합니다. 입력 이미지의 해상도가 충분하지 않으면 사용 가능한 픽셀만으로는 시각적으로 유사한 문자를 구분할 수 없습니다. 72 DPI에서 문자 S는 세로로 약 10~12픽셀을 차지합니다 — 이 해상도에서는 5의 세리프와 S의 곡선이 동일하게 보일 수 있습니다. 이것은 인코딩 문제가 아니라 근본적인 정보 이론의 제약입니다. 이미지에 각 문자의 구별 특징을 표현할 충분한 픽셀이 포함되어 있지 않으면, 아무리 고급 OCR 엔진이라도 매번 완벽하게 추측할 수는 없습니다.
이러한 유형의 오류는 특히 다음 경우에 자주 발생합니다:
- 저조도 또는 비스듬한 각도에서 촬영한 문서의 휴대폰 사진
- 팩스 또는 반복 복사된 페이지로 각 세대마다 세부 정보가 손실되는 경우
- 역사 기록의 오래된 마이크로필름 스캔
- 작은 글꼴 크기의 문서를 200 DPI 이하로 스캔한 경우
해상도 관련 문자 깨짐을 해결하는 방법
옵션 1: 입력 해상도를 높입니다. OCR의 업계 표준은 최소 300 DPI이며, 작거나 빽빽한 텍스트의 경우 400–600 DPI를 권장합니다. 휴대폰 사진으로 작업하는 경우, 이미지 전처리 단계에서 업스케일링, 선명화, 기울기 보정을 통해 OCR 엔진에 보내기 전에 이미지를 개선할 수 있습니다.
옵션 2: 기존 OCR 대신 비전 기반 추출 도구를 사용합니다. 이것이 구조적인 해결책입니다. 기존 OCR 엔진(Tesseract, ABBYY, Adobe OCR)은 문자 단위 패턴 매칭에 의존합니다. 그래서 픽셀 하나가 누락되면 5가 S로 바뀔 수 있는 것입니다. 최신 비전-언어 모델(VLM) 추출은 전체 단어와 문장을 시각적 객체로 읽고, 의미론적 맥락을 사용하여 모호성을 해결합니다. 엔진이 "Order S units"을 보고 주변 맥락이 인보이스임을 인식하면, S가 5일 가능성이 높다고 이해합니다. 문자 모양을 더 잘 인식해서가 아니라 "Order 5 units"가 "Order S units"보다 의미가 통하기 때문입니다. 이것이 기존 OCR과 어떻게 다른지에 대한 설명은 OCR이 무엇이고 그 한계가 어디에서 오는지를 읽어 보세요.
옵션 3: OCR 전에 이미지 전처리를 적용합니다. 간단한 전처리만으로도 문자 혼동을 크게 줄일 수 있습니다. 그레이스케일 변환, 적응형 임계값을 적용한 텍스트 이진화, 노이즈 제거는 OCR 엔진에 더 깨끗한 신호를 제공합니다. 현장 검증된 전처리 워크플로우는 OCR 정확도 향상 가이드를 참조하세요.
해결책이 모두 효과가 없을 때: 대처 방법
인코딩을 확인하고, 글꼴을 점검하고, 이미지를 전처리했는데도 출력이 여전히 깨져 있다면, 해당 도구가 문서 유형에 적합하지 않을 수 있습니다. 혼합 스크립트, 장식용 글꼴, 수학 표기법, 또는 과도한 스탬프 오버레이가 있는 문서는 기존 OCR의 설계 한계를 넘어섭니다.
이러한 경우 실용적인 해결책은 문서를 전체적으로 읽는 템플릿 불필요 비전 AI 추출 도구로 전환하는 것입니다. ImageToTable.ai와 같은 도구는 페이지의 시각적 렌더링에서 의미를 추출하기 때문에 인코딩 및 글꼴 문제를 완전히 우회합니다. 문서를 업로드하고 원하는 열 이름을 지정하면 AI가 문서의 시각적 및 의미론적 구조를 이해하여 데이터를 추출합니다. 글꼴에 의존하는 텍스트 레이어도, 걱정할 인코딩 테이블도 없습니다.
자주 묻는 질문
화면에서 PDF가 정상적으로 보이는데 복사하면 글자가 깨지는 이유는 무엇인가요?
거의 항상 글꼴 인코딩 문제입니다. PDF의 시각적 레이어는 올바르게 렌더링된 글리프를 사용하지만, 문자-유니코드 매핑이 손상되었거나 비표준입니다. PDF 리더는 글리프를 완벽하게 표시하지만, 텍스트를 복사하거나 OCR 엔진이 숨겨진 텍스트 레이어를 읽을 때 손상된 매핑을 따라가며 깨진 텍스트가 생성됩니다. 해결 방법은 기존 텍스트 레이어를 무시하고 이미지 레이어에서 직접 OCR을 수행하는 것입니다.
깨진 OCR 텍스트를 소프트웨어로 자동 수정할 수 있나요?
네, 인코딩 불일치 모지바케의 경우 ftfy(Python), iconv(Linux/macOS), VS Code와 같은 편집기의 '인코딩 감지' 기능을 사용하여 손상을 자동으로 식별하고 되돌릴 수 있습니다. 글꼴 인코딩 및 해상도 문제의 경우, 문제가 바이트-문자 매핑이 아닌 원본 데이터 자체에 있기 때문에 자동 복구의 신뢰도가 낮습니다. 이러한 경우에는 다른 설정이나 다른 추출 방식으로 재처리해야 합니다.
DPI가 높으면 항상 깨진 OCR이 수정되나요?
높은 DPI는 해상도 관련 문자 혼동을 해결하지만, 인코딩 불일치나 글꼴 인코딩 문제에는 영향을 미치지 않습니다. 원본 파일이 손상된 /ToUnicode 테이블이 있는 PDF인 경우 600 DPI로 스캔해도 도움이 되지 않습니다. 단지 동일한 근본 문제의 고해상도 버전을 생성할 뿐입니다. 재스캔에 투자하기 전에 근본 원인을 진단하세요.
ImageToTable.ai가 기존 OCR보다 깨진 텍스트를 더 잘 처리하나요?
ImageToTable.ai는 중간 텍스트 레이어가 아닌 문서의 시각적 콘텐츠를 읽는 비전-언어 모델을 사용하기 때문에 인코딩 불일치 및 글꼴 인코딩으로 인한 깨진 텍스트 문제를 모두 우회합니다. AI가 렌더링된 페이지 이미지를 직접 처리하므로 사용자 정의 CID 매핑, 서브셋 글꼴, 누락된 /ToUnicode 테이블이 간섭하지 않습니다. 해상도 관련 모호성의 경우, 문서 컨텍스트에 대한 모델의 의미론적 이해는 문자 기반 OCR이 부족한 추가적인 보정 계층을 제공합니다. 그러나 원본 이미지 자체가 심각하게 손상된 경우, 비전 AI를 포함한 어떤 접근 방식도 캡처되지 않은 정보를 복구할 수 없습니다.
깨진 OCR 텍스트는 무작위가 아닙니다 — 이제 이렇게 대처하세요
OCR 결과가 알파벳을 뒤섞은 듯 보일 때, 소프트웨어 탓하고 넘어가고 싶어집니다. 하지만 여기서 다룬 세 가지 원인 — 인코딩 불일치, 폰트 인코딩 문제, 해상도 기반 문자 혼동 — 각각은 고유한 특징과 해결책이 있습니다. 이를 구분하는 법을 익히면 답답한 미스터리를 반복 가능한 진단으로 바꿀 수 있습니다.
증상부터 시작하세요: 악센트 주변의 여러 문자 깨짐 → 인코딩 불일치, 재인코딩 또는 ftfy로 해결. 화면 표시는 완벽하지만 OCR이 엉뚱한 글자를 출력 → 폰트 인코딩 문제, 이미지 레이어 OCR 강제로 해결. 개별 문자가 비슷한 모양으로 바뀜(5→S) → 해상도 문제, 전처리 또는 문맥 인식 도구로 해결.
마지막 옵션 — 문자 기반 OCR에서 비전 기반 추출로 전환 — 은 문서를 사람처럼 읽음으로써 근본 원인을 완전히 우회합니다. 즉, 픽셀 패턴을 매칭하거나 인코딩 테이블을 탐색하는 대신 의미를 이해하는 방식입니다.
직접 깨진 문서로 테스트해 보세요. 엔진이 더 이상 텍스트 레이어에 의존하지 않을 때 문제가 사라지는지 확인하십시오.