다국어 문서 추출 정확도가 떨어지는 이유는?
3가지 시나리오와 구체적인 해결책

패턴은 항상 같습니다. 영어 문서로 테스트하면 마법 같은 결과를 얻고, 실제 문서(세 국가에서 온 공급업체의 인보이스, 두 가지 문자 체계로 된 주소가 적힌 배송 라벨, 중간에 언어가 바뀌는 계약서)로 전환하면 정확도가 떨어집니다. 치명적이지는 않지만, 도구가 실제로 작동하는지 의심이 들 정도입니다.

작동은 합니다. 문제는 무엇을 요구하느냐입니다. 영어 인보이스 하나는 균일한 입력입니다. 언어, 문자, 읽는 방향이 모두 하나입니다. 프랑스어 품목과 스페인어 결제 조건이 포함된 독일어 인보이스는 같은 유형의 문제가 아니며, 정확도는 이를 반영합니다. 세 가지 시나리오 중 어떤 상황에 직면했는지 이해하는 것이 무엇을 고쳐야 할지 아는 것과 잘못된 원인을 탓하는 것의 차이를 만듭니다.

이 가이드에서는 정확도가 떨어지는 가장 흔한 세 가지 시나리오, 문서에서 어떤 상황이 발생하는지 파악하는 방법, 그리고 각각에 대한 해결책을 다룹니다. 비전 AI가 아키텍처 수준에서 여러 언어를 처리하는 방법에 대한 개요는 AI가 하나의 문서에서 여러 언어를 읽을 수 있나요?를 참조하세요. 이 글은 해당 배경 지식을 바탕으로 문제 해결 측면에 초점을 맞춥니다.

시나리오 1: 단일 문서, 여러 언어

정확도 저하의 가장 흔한 원인이지만, 사용자들이 보통 자신이 이 상황에 처해 있다는 것을 깨닫지 못합니다. 문서가 "독일어"로 되어 있지만, 헤더는 영어(회사명과 주소)이고, 품목에는 독일어 제품 설명과 프랑스어 재료명이 섞여 있으며, 바닥글에는 법무팀이 지난 분기에 선택한 언어로 된 법적 표준 문구가 있습니다.

대부분의 AI 비전 모델은 전체 페이지를 단일 시각적 맥락으로 처리합니다. 기존 OCR처럼 언어를 "전환"하지 않고, 모든 것을 한 번에 읽고 동일한 추론 과정의 일부로 각 문자의 스크립트를 파악합니다. 이는 사전 선택된 언어 팩이 필요한 OCR 엔진보다 유리한 점이지만, 미묘한 문제를 만듭니다. 다른 언어의 텍스트가 동일한 시야에 나타나면, 모델이 스크립트 경계, 특수 문자(é, ü, ñ, ß), 그리고 문맥에 의존하는 글자 형태를 동시에 해결해야 하므로 문자 신뢰도가 떨어집니다.

단일 다국어 인보이스에서 실제로 일어나는 일은 다음과 같습니다.

• 영어 헤더 (회사명, 주소) — 96% 정확도. 모델이 가장 강력한 영역입니다.
• 독일어 본문 (움라우트가 있는 품목 설명, "€" 통화, 독일어 날짜 형식) — 88–91% 정확도. 움라우트(ä, ö, ü)가 누락되거나 대체됩니다. "14.03.2026"이 영어 "03/14/2026"과 혼동됩니다.
• 프랑스어 품목 (악센트 문자: é, è, ê, œ) — 85–88% 정확도. 혼합 글리프 행의 악센트 오류가 누적됩니다. "générique"와 같은 단어가 "generique" 또는 "g6n6rique"가 됩니다.
• 스페인어 결제 조건 (ñ 및 역구두점) — 82–87% 정확도. 모델이 바닥글에 도달할 때쯤이면 이미 독일어 및 프랑스어 섹션에서 문자 해상도 예산을 소진했습니다.

이는 최악의 수치가 아닙니다. 동일한 알파벳을 공유하지만 특수 문자, 날짜 형식 및 통화 표기법이 다른 세 개의 라틴 문자 언어 사이를 전환하는 문서의 일반적인 수치입니다.

진단: 동일한 문서 내에서 필드별 정확도가 다른 경우(날짜가 공급업체명보다 더 신뢰할 수 있거나, 숫자는 깨끗하지만 악센트 문자가 손상된 경우) 시나리오 1에 해당할 가능성이 높습니다.

해결 방법: 전체 페이지 OCR 대신 사용자 정의 열 추출을 사용하세요. 특정 출력 열(예: "공급업체명", "송장 날짜", "총 금액")을 정의하면 AI는 페이지의 모든 문자를 동등하게 처리하려고 시도하는 대신 의미적 의미를 기준으로 해당 값을 찾는 데 집중합니다. "총 금액(EUR)"이라는 열은 주변 텍스트가 독일어, 프랑스어, 스페인어인지와 관계없이 통화 기호 근처의 숫자를 찾도록 모델에 지시합니다. 문서 유형별 열 기반 추출이 어떻게 작동하는지 자세히 알아보려면 AI 문서 추출 작동 방식과 열 정의가 중요한 이유를 참조하세요.

시나리오 2: 문자 체계 차이 — 라틴어 vs. CJK vs. 아랍어

이 경우 정확도 저하가 "짜증나는 수준"에서 "워크플로우를 망가뜨리는 수준"으로 넘어갑니다. 영어 송장은 96%로 추출되고 일본어 송장은 82%로 추출됩니다. 이는 일본어 문서의 품질이 낮기 때문이 아니라, 문자 체계군이 비전 모델에 도전하는 방식이 근본적으로 다르기 때문입니다.

라틴 문자(영어, 프랑스어, 독일어, 스페인어, 포르투갈어, 이탈리아어, 네덜란드어)는 26자 알파벳, 왼쪽에서 오른쪽으로 읽는 방향, 풍부한 학습 데이터를 공유합니다. 이들은 현대 비전 AI에게 해결된 문제입니다. 깨끗하게 인쇄된 라틴 텍스트의 정확도는 지속적으로 95–99%에 도달합니다.

CJK 문자(중국어, 일본어, 한국어)는 난이도가 다른 계층입니다. 단일 일본어 문장에는 한자(수천 개의 중국어 기원 문자), 히라가나(46개의 음성 문자), 가타카나(46개의 외래어 음성 문자), 영어 용어를 위한 라틴 문자, 아라비아 숫자가 모두 한 줄에 포함될 수 있습니다. 동일한 의미 콘텐츠가 일본어로 표현되면 영어에 비해 약 2배의 토큰을 소비하므로, 모델이 CJK 문서에서 컨텍스트 창을 더 빨리 채우고 필드당 사용 가능한 정보가 줄어듭니다. 이 밀도 문제에 대한 실제 예는 일본어 영수증 데이터를 Excel로 추출에 대한 내용을 참조하세요.

아랍어와 히브리어는 오른쪽에서 왼쪽으로 읽는 방향이라는 도전 과제를 추가합니다. 모델은 읽기 방향이 반대임을 감지하고, 텍스트 블록별로 올바르게 적용하며, 아랍어의 네 위치 문자 형태(단어의 시작, 중간, 끝, 단독 위치에 따라 문자의 모양이 변경됨)를 처리해야 합니다. 인쇄된 아랍어 문서의 정확도는 75–85% 범위입니다. 이는 모델이 아랍어 문자 자체에 약해서가 아니라, RTL 타이포그래피 관례가 왼쪽에서 오른쪽으로 쓰는 문자와는 다른 시각적 구문 분석 문제를 만들기 때문입니다.

진단: 영어 문서가 95% 이상으로 추출되고 비라틴 문서가 여러 문서에 걸쳐(단 하나의 문서가 아닌) 지속적으로 10–20% 낮게 추출된다면, 시나리오 2에 해당합니다.

해결 방법: 두 가지 접근 방식이 있습니다. 첫째, 처리하려는 특정 스크립트에 대한 도구의 언어 지원을 확인하세요. "100개 이상 언어 지원"을 주장하는 모든 도구가 모든 스크립트에 대해 동등하게 학습된 것은 아닙니다. 일부 비전 모델은 라틴어 데이터에 불균형적으로 학습되고 CJK와 아랍어는 더 작은 보조 코퍼스로 추가됩니다. 모델의 학습 데이터에 필요한 스크립트 계열이 포함되어 있는지 구체적으로 물어보세요. 둘째, 도구의 데모 이미지가 아닌 실제 문서의 대표 샘플로 테스트하세요. 공급업체의 일본어 데모 인보이스는 완벽한 대비를 가진 깨끗하고 디지털로 생성된 이미지일 것입니다. 2019년에 스캔한 일본어 인보이스로 공급업체 이름 위에 희미한 도장이 있는 것은 매우 다른 인식 문제입니다.

시나리오 3: 동일 필드 내 혼합 스크립트

이것이 가장 어려운 경우이며, 대부분의 문서가 건너뛰는 부분입니다. 문서의 단일 필드에 여러 스크립트의 문자가 포함되어 있습니다. "ABC-1234-안전밸브"(영문자, 아라비아 숫자, 한글)와 같은 부품 번호. "株式会社Yamada (Osaka Branch)"로 읽히는 공급업체 이름 필드. "2026年03月14日"로 작성된 날짜 필드 — CJK 텍스트에 포함된 아라비아 숫자.

비전 모델은 각 문자 클러스터를 독립적으로 인식하고 이를 일관된 문자열로 조합하여 혼합 스크립트 필드를 처리합니다. 그러나 이 프로세스는 혼합 스크립트 시나리오에 특화된 여러 실패 모드를 도입합니다:

• 스크립트 경계 오감지: 모델이 한 스크립트가 끝나고 다른 스크립트가 시작되는 위치를 잘못 판단합니다. CJK 표의 문자와 시각적으로 유사한 한글 문자가 잘못된 스크립트 그룹으로 분류되어 이후 문자들이 잘못된 인식 컨텍스트로 파싱될 수 있습니다.
• 문자 대체: 스크립트 간 유사 문자(동형이의자)가 서로 바뀝니다. 라틴 문자 "A", 키릴 문자 "А", 그리스 문자 "Α"는 시각적으로 거의 동일하지만 다른 유니코드 문자입니다. 라틴 문자 "A"를 포함하는 제품 코드가 키릴 문자 "А"로 출력될 수 있습니다 — 시각적으로는 동일하지만 의미상으로는 틀리며, 올바르게 보이기 때문에 현장 점검에서 감지할 수 없습니다.
• 혼합 LTR/RTL 필드의 방향 혼동: 괄호 안에 영문 등록 번호가 뒤따르는 아랍어 회사 이름은 모델이 올바르게 정렬해야 하는 양방향 문자열을 생성합니다. "شركة (ABC-1234)" 대신 "(ABC-1234 شركة)"와 같은 출력이 일반적입니다 — 두 문자 모두 존재하지만 읽기 순서가 반대입니다.

진단: 추출된 데이터가 시각적으로 그럴듯해 보이지만 알려진 참조와 일치하지 않는 경우 — 올바른 문자를 모두 가지고 있는 것처럼 보이지만 ERP와 일치하지 않는 부품 번호, 또는 사람이 훑어보기에는 통과하지만 조회 실패를 유발하는 공급업체 이름 — 시나리오 3이 원인일 가능성이 높습니다.

해결 방법: 언어 힌트를 사용한 사전 처리는 혼합 스크립트 오류를 크게 줄입니다. 대부분의 비전 모델이 언어를 자동 감지하지만, 추출 컨텍스트를 명시적으로 고정하는 것이 도움이 됩니다. 이를 지원하는 도구에서 "이 문서의 기본 언어는 한국어이며 영어 제품 코드가 포함되어 있습니다"와 같은 힌트를 전달하면 모델이 스크립트 경계를 인식 오류로 처리하지 않고 예상하도록 지시합니다. 정확도가 중요한 필드(세금 ID, 부품 번호, 등록 코드)의 경우 언어별 현장 점검 검증이 가장 신뢰할 수 있는 안전장치입니다: 데이터를 추출한 다음, 비라틴어 부분을 라틴어 부분과 별도로 검증하세요. 참조 데이터베이스(ERP, CRM, 공급업체 목록)가 있는 경우 추출된 값을 교차 참조하면 아무리 많은 육안 검사로도 찾을 수 없는 문자 대체 오류를 포착할 수 있습니다.

현재 상황 진단 방법

다국어 문서에서 정확도가 떨어지는 것을 발견했다면, 다른 것을 변경하기 전에 다음 세 가지 질문으로 진단하세요:

1. 정확도 저하가 언어별로 일관되지만 동일 문서 내에서 발생합니까? 영어 필드는 항상 깨끗한데, 같은 문서 내 프랑스어/움라우트 필드가 일관되게 저하된다면 → 시나리오 1. 의미 기반 필드 정의와 함께 열 기반 추출을 시도해보세요.
2. 정확도 저하가 언어군별로 전체 문서에 걸쳐 일관됩니까? 내용과 관계없이 모든 일본어 문서가 모든 영어 문서보다 추출 정확도가 낮다면 → 시나리오 2. 해당 문자 체계에 대한 도구의 학습 데이터 범위를 확인하세요.
3. 정확도 저하가 혼합 문자 콘텐츠를 포함한 특정 필드에 국한됩니까? 공급업체 이름은 괜찮지만 한자나 아랍어가 포함된 부품 번호에서 오류가 발생한다면 → 시나리오 3. 전처리 언어 힌트를 추가하고 필드별 상호 참조를 구현하세요.

이 세 가지 시나리오는 종종 중복됩니다. 한 페이지에 여러 언어(시나리오 1), 다른 문자 체계(시나리오 2), 혼합 문자 필드(시나리오 3)가 모두 포함될 수 있습니다. 진단 질문은 어떤 레이어를 먼저 수정해야 하는지 알려줍니다. 잘못된 레이어를 수정하면 시간만 낭비됩니다. 시나리오 2에 해당한다면, 아무리 열을 세분화해도(시나리오 1 해결책) 정확도 격차를 해소할 수 없습니다. 모델에는 더 나은 프롬프트가 아닌 다른 학습 데이터 범위가 필요합니다.

예방: 다국어 정확도 저하를 줄이는 세 가지 습관

자신의 시나리오를 파악했다면, 다음 방법을 통해 새로운 문서 유형과 언어에서 동일한 문제가 재발하는 것을 방지할 수 있습니다:

1. 가능하면 문서를 문자 체계별로 분리하세요. 매일 200개의 인보이스를 처리하는데, 150개는 로마자 계열 언어, 50개는 CJK(중·일·한) 언어라면, 이를 별도로 배치 처리하면 두 개의 독립적인 정확도 기준선을 확보할 수 있습니다. 로마자 추출은 95% 이상, CJK는 82%로 실행된다는 것을 알 수 있습니다. CJK 배치가 갑자기 70%로 떨어지면 즉시 인지할 수 있습니다. 하나의 배치에 섞여 있으면 전체 평균이 93%에서 90%로 떨어져도 아무도 문제를 제기하지 않습니다.

2. 언어별 검증 샘플을 유지하세요. 처리하는 각 언어군별로 대표 문서 5~10개를 선정하세요. 추출 워크플로우를 업데이트하거나 도구를 변경할 때마다 이 검증 세트를 실행하여 언어별 정확도를 비교하세요. 이렇게 하면 문제가 실제 운영 환경에 도달하기 전에 성능 저하를 발견할 수 있습니다. 로마자 정확도를 2% 향상시켰지만 CJK 정확도를 8% 저하시키는 도구는 다국어 워크플로우에 있어 순이익이 아닙니다.

3. 언어별로 다른 필드 수준 신뢰도 임계값을 사용하세요. 동일 문서의 영어 필드와 아랍어 필드에 동일한 "신뢰도 90% 이상이면 수락" 규칙을 적용하지 마세요. 영어에 90% 임계값은 너무 엄격할 수 있지만(모두 통과), 동일한 임계값을 아랍어에 적용하면 모든 추출이 거부될 수 있습니다. 검증 샘플 결과를 바탕으로 언어별 임계값을 설정하세요(아랍어 75%, 로마자 90%, CJK 80%). 임계값 미만의 항목은 자동 수락하지 않고 수동 검토로 보내세요.

에스컬레이션 시점 — 수동 처리가 필요한 경우

이 글에서 가장 중요한 부분은 정직함입니다. Vision AI는 다양한 언어에서 놀라운 성능을 보이지만, 프롬프트 튜닝이나 전처리로도 생산 수준의 정확도에 도달할 수 없는 경계 조건이 존재합니다.

• 서로 다른 문자 체계를 가진 4개 이상의 언어가 포함된 문서. 한 페이지에 영어(로마자), 아랍어(RTL), 일본어(CJK 세로+가로), 한국어(CJK 가로)가 모두 포함된 문서는 현재 비전 모델의 성능 한계에 가깝습니다. 단일 언어 기준 대비 5~15%의 정확도 하락이 예상됩니다.
• 같은 문장이나 표 셀 내에서 RTL/LTR이 혼합된 경우. 계약 조항에서 "البند (Item) 4.2"와 같이 아랍어와 영어가 괄호 관계로 같은 줄에 나타나면, 양방향 구문 분석에서 구조적 오류가 발생하며 전처리 힌트로는 일부만 수정 가능합니다.
• 비로마자 필기체 콘텐츠. 필기체만으로도 인쇄체 대비 정확도가 15~30% 하락합니다. 여기에 두 번째 언어(예: 일본어 필기체에 아랍어 숫자 필기체)가 추가되면 복합 효과로 대부분의 추출 결과가 사용 가능한 임계값 아래로 떨어집니다. 이러한 문서는 인쇄된 부분에 대해 AI 추출의 이점을 누릴 수 있지만, 필기 필드는 예외가 아닌 기본 워크플로우로 수동 입력 경로로 라우팅되어야 합니다.
• 저자원 언어 쌍. 태국어/아랍어, 스와힐리어/키릴 문자, 버마어/영어와 같이 비전 모델 훈련에서 개별 언어가 고자원이 아닌 쌍입니다. 이러한 문서의 정확도 기준은 영어/스페인어 또는 영어/중국어와 같은 잘 지원되는 쌍보다 낮습니다.

실용적인 워크플로우: AI 추출은 다국어 데이터의 80~90%를 자동으로 처리합니다. 나머지 10~20% — 혼합 문자 문서의 고위험 필드, RTL/LTR 혼합 텍스트의 중요 숫자 필드, 비로마자 필기 항목 — 은 완전 수동 입력보다 빠르고 가장 어려운 경우에 AI를 신뢰하는 것보다 더 신뢰할 수 있는 인간 검토 단계로 라우팅됩니다.

자주 묻는 질문

AI 추출 도구가 영어 인보이스에서는 잘 작동하는데, 독일어나 프랑스어에서는 왜 성능이 떨어지나요?

이는 일반적으로 시나리오 1에 해당합니다. 영어 문서는 스크립트 모호성이 없는 단일 언어 입력입니다. 독일어나 프랑스어 문서에는 특수 문자(움라우트, 악센트)가 포함될 가능성이 높으며, 비전 모델은 이를 표준 라틴 문자의 변형으로 처리합니다. 이러한 변형은 악센트 없는 문자보다 학습 데이터에 덜 자주 등장하기 때문에 신뢰도가 낮습니다. 영어와 기타 라틴 문자 언어 간의 정확도 차이는 일반적으로 5~8%로 눈에 띄지만, 전체 페이지 OCR 대신 특정 필드에 모델을 집중시키는 열 기반 추출을 통해 해결할 수 있습니다.

문서를 먼저 단일 언어로 변환하면 다국어 추출 정확도를 높일 수 있나요?

신뢰할 수 있는 방법이 아닙니다. 추출 전 기계 번역은 별도의 오류 계층을 추가합니다. 번역된 텍스트에서 추출하게 되면 필드 레이블, 숫자 형식, 문서 구조가 손실될 수 있습니다. 원본 문서에는 작성자가 의도한 레이아웃과 데이터가 포함되어 있습니다. 추출은 번역된 버전이 아닌 원본을 읽을 때 가장 잘 작동합니다. 더 나은 방법은 의미론적 열 정의를 사용하여 원본 문서에서 추출한 다음, 다운스트림 시스템에 필요한 언어와 관계없이 추출된 데이터의 유효성을 검사하는 것입니다.

AI가 문서를 처리하기 전에 문서에 어떤 언어가 있는지 알아야 하나요?

감지 측면에서는 아닙니다. 최신 비전 모델은 페이지를 읽는 과정의 일부로 스크립트와 언어를 자동으로 감지합니다. 하지만 컨텍스트 측면에서는 그렇습니다. 문서에 희귀한 언어 쌍이나 혼합 스크립트 필드가 포함된 경우, 언어 힌트(예: "이 문서에는 한국어와 영어, 그리고 아라비아 숫자가 포함되어 있습니다")를 제공하면 보조 언어 부분의 정확도가 3~7% 향상됩니다. 이는 모델이 인식 리소스를 더 효율적으로 할당하기 때문입니다.

동일한 도구를 사용할 때 라틴 문자 문서와 CJK 문서 간 예상 정확도 차이는?

비슷한 품질의 깨끗한 인쇄 문서에서 동일한 도구를 사용할 경우, CJK 정확도는 라틴 문자보다 8~15% 낮을 것으로 예상됩니다. 이는 도구 품질 문제가 아니라 문자 집합(26자 대 수천 자), 의미 단위당 토큰 소비량(2배), 학습 데이터 양의 근본적인 차이를 반영합니다. 영어에서 97%를 기록하는 도구가 일본어에서 83%를 기록한다면, 현재 비전 AI 수준에서는 정상적인 성능입니다.

언어별로 다른 AI 추출 도구를 사용해야 하나요?

문서 구성이 여러 문자 체계(동일 문자 체계 내 여러 언어가 아닌)에 걸쳐 있다면, 특정 지역 문자에 최적화된 도구를 사용하여 언어별 정확도를 높일 수 있습니다. 예를 들어 PaddleOCR은 학습 데이터가 CJK에 집중되어 있어 범용 비전 모델보다 CJK 문서에서 더 나은 성능을 보입니다. 그러나 여러 도구를 관리하면 워크플로우 복잡성이 증가하여 대부분의 팀에게 정확도 향상 효과가 상쇄될 수 있습니다. 효과적인 한 가지 접근 방식은 모든 언어에 대해 범용 비전 AI 도구를 기본 추출기로 사용하고, 기본 도구의 신뢰도가 임계값 아래로 떨어질 때만 특정 문자에 특화된 대체 엔진으로 문서를 라우팅하는 것입니다.

단일 라틴 문자 문서와 다국어 문서 간의 정확도 차이는 기술의 실패가 아니라 예측 가능하고, 진단 가능하며, 대부분 수정 가능한 격차입니다. 진단 질문부터 시작하여 해당 시나리오에 맞는 수정을 적용하고, 현재 비전 모델이 여전히 학습 중인 예외 사례에 대해서만 수동 검토를 남겨두세요. 자신의 다국어 문서로 테스트하여 어떤 시나리오가 워크플로우에 적용되는지 확인하십시오.