잘못 추출된 숫자 수정 방법:
직접 진단할 수 있는 3가지 근본 원인

AI가 숫자를 못하는 게 아닙니다 — 필드 이름이 문제입니다

AI 추출을 다루는 대부분의 사람이 한 번쯤 겪는 상황입니다: 읽기 쉬운 인보이스를 업로드하고, 도구가 모든 필드를 자신 있게 반환했는데, "합계" 열에 실제 인보이스 합계인 $1,447.30 대신 $1,247.30이 표시된 것을 발견합니다. 소계, 세금, 품목은 모두 정확해 보입니다. 하지만 가장 중요한 숫자가 $200 차이 납니다.

세 개의 엔지니어링 팀이 4,149개의 실제 인보이스에서 이 정확한 오류 패턴을 연구했으며, 그 결과는 많은 실무자가 의심하는 바를 확인해 줍니다: 대부분의 추출 오류는 무작위 OCR 노이즈가 아니라 예측 가능한 근본 원인 패턴을 따르며, 도구를 바꾸지 않고도 진단하고 수정할 수 있습니다.

같은 연구에 대한 Reddit 토론에서는 더 솔직한 평가가 나왔습니다: "잘못된 합계가 기재된 거래를 수정하는 데 10분이 걸립니다. 플래그에서 공급업체 오류와 데이터 입력 오류를 분리하세요." 함의는 명확합니다 — 추출된 숫자가 틀리면, 자동화된 프로세스가 저장하는 것보다 더 많은 후속 작업을 만듭니다. 하지만 수정에는 다른 AI 엔진이 거의 필요하지 않습니다. 오류가 속한 세 가지 뚜렷한 근본 원인 범주 중 어느 것인지 이해하는 것이 필요합니다.

사용자 정의 열 추출 — ImageToTable.ai의 메커니즘으로, 원하는 필드 이름을 입력하면 AI가 위치가 아닌 의미로 일치하는 값을 찾습니다 — 이 진단 현실을 기반으로 설계되었습니다. 하지만 최고의 AI조차도 열 정의에서 깨끗한 신호가 필요합니다. 다음은 거의 모든 잘못된 숫자 오류를 설명하는 세 가지 근본 원인 범주와 각각을 정확히 진단하는 방법입니다.

근본 원인 1: 모호한 필드 설계 — "합계"는 너무 구체적이지 않습니다

증상: 추출된 합계가 예상한 합계가 아닙니다. 소계일 수 있습니다. 눈치채지 못한 할인 후 금액일 수 있습니다. 세금 포함 합계일 때 순 금액을 원했을 수 있습니다. 하지만 숫자 자체는 읽을 수 있고 인보이스에 표시됩니다 — 단지 여러 사용 가능한 금액 중 잘못된 것입니다.

발생 이유: 일반적인 인보이스의 합계 섹션에는 세로로 쌓인 최소 세 개의 금액 필드가 있습니다: 소계, 세금(또는 부가세/GST), 합계. 많은 인보이스에는 같은 열에 할인, 배송비 또는 이전 잔액 필드도 포함됩니다. 추출 열 이름이 "합계"이면, AI는 이 중 어떤 금액을 의미하는지 추측해야 합니다. "합계"라는 단어는 문서상 유효한 필드 레이블이지만, "소계"에도 나타나는 단어이며 "세금"과 "배송비"도 있는 일반 영역입니다. AI는 어떤 합계를 원하는지 본래 알지 못합니다 — 사용자가 제공한 레이블을 읽고 페이지에서 가장 좋은 의미적 일치를 찾습니다. 하나의 레이블이 다섯 개의 가능한 값에 매핑되면 오류율이 높아집니다.

이는 특정 AI 엔진에만 국한된 한계가 아닙니다. 모호한 열 요청을 처리할 때 비전-언어 모델 내부에서 일어나는 일은 다음과 같습니다: 열 정의에서 "합계"라는 단어를 보고, 합계 섹션을 스캔하여 모두 그럴듯하게 일치하는 세 네 개의 숫자를 찾습니다 — 소계는 세금 한 줄 위에, 총합계는 그 한 줄 아래에 있습니다 — 그리고 가장 강한 의미적 및 위치적 신호를 가진 것을 선택합니다. 대부분의 인보이스에서는 잘 작동합니다. 소계와 합계의 글꼴 크기가 비슷하고 한 줄의 공백만으로 분리된 인보이스에서는, 모델의 두 옵션에 대한 신뢰도가 거의 동일할 수 있습니다. 결과는 출력에서 자신 있는 잘못된 답변처럼 보이는 동전 던지기입니다.

수정 방법: 원하는 금액을 구체적으로 지정하세요. "합계"라는 열 대신 다음 중 하나를 사용하세요:

• "총 청구 금액" — 명확하며, 대부분의 청구서에서 최종 지불 금액으로 표시됩니다.
• "총 합계 (세후)" — 접미사가 AI에게 모든 추가 항목을 포함한 최종 금액임을 알려줍니다.
• "소계 (세전)" — 세금 포함 값을 명시적으로 제외합니다.
• "지불 금액" / "미납 잔액" — 명세서에서 지불액과 미지불액을 구분합니다.

열 이름이 구체적일수록 AI가 선택할 후보가 줄어듭니다. 이는 임시 방편이 아니라 의미 기반 추출의 의도된 설계입니다. 최신 AI가 위치가 아닌 의미로 송장 필드를 구분하는 방법에서 레이블의 구체성이 필드 수준에서 추출 정확도를 어떻게 제어하는지 설명합니다.

이 문제가 해당하는지 확인하려면: 송장과 추출 결과를 함께 살펴보세요. AI가 "총계"에 대해 반환한 값과 문서에서 일치하는 값을 찾으십시오. 동일한 값이지만 그 값이 소계나 세금 포함 총계라면 모호성 문제가 있는 것입니다. 해결책은 더 구체적인 열 이름을 사용하는 것뿐이며 비용은 들지 않습니다.

근본 원인 2: 문자 혼동 — 5가 S로, 0이 O로 바뀌는 경우

증상: 추출된 출력의 숫자에 숫자 대신 문자가 포함됩니다. "5"가 "S"로, "0"이 "O"로, "1"이 "l" 또는 "7"로 추출됩니다. 동일 출처의 유사 문서에서 오류가 일관되게 발생합니다. 숫자가 한두 자리 잘못되었지만 크기는 대략적으로 맞습니다.

발생 이유: OCR 엔진과 비전 모델 모두 문자의 픽셀 모양을 분석합니다. 일부 문자 쌍은 일반적인 글꼴 크기와 스캔 해상도에서 거의 동일한 시각적 프로필을 공유합니다:

이는 더 나은 AI로 완전히 제거할 수 있는 문제가 아닙니다. 최첨단 비전 모델도 압축 아티팩트가 있는 9픽셀 높이의 문자에서 "5"와 "S"에 대해 거의 동등한 신뢰도를 보입니다. 인간의 뇌는 단어 수준의 맥락을 사용하여 이러한 모호성을 해결합니다. "5ales Tax"가 잘못되었다는 것을 아는 이유는 "Sales Tax"가 알려진 용어이기 때문입니다. OCR 엔진은 특정 필드에서 사전 단어를 기대하도록 특별히 훈련되지 않는 한 이러한 단어 수준 지식이 없습니다.

해결 방법: 문자 혼동은 추출 중이 아닌 추출 후에 잡는 것이 가장 좋습니다. 추출된 값을 예상 패턴과 비교하는 필드 수준 유효성 검사 규칙을 구현하십시오:

• 숫자 전용 필드: 송장번호, PO번호, 계정코드처럼 숫자만 입력되어야 하는 필드는 간단한 정규식 검사를 수행하세요. 숫자 전용 필드에서 숫자가 아닌 문자가 추출되었다면 거의 확실히 오인식입니다. 이러한 맥락에서 "S"는 "5"로, "O"는 "0"으로, "l"은 "1"로 바꾸세요.
• 범위 검사: 추출된 합계가 $5,000.00인데 해당 공급업체의 다른 모든 송장이 $200~$800 범위라면 검토 대상으로 표시하세요. 단일 이상값은 종종 소수점 위치 오류나 값이 한 자릿수만큼 부풀려진 문자 오인식의 결과입니다.
• 교차 필드 수학 검증: 소계 + 세금 = 합계가 성립하는지 확인하세요. 약간의 오차 범위 내에서 계산이 맞지 않는다면 세 숫자 중 적어도 하나에 문자 수준 오류가 있는 것입니다. 이 한 가지 검사만으로도 문자 혼동 오류의 대부분을 잡아낼 수 있습니다. 세 합계 중 어느 하나라도 숫자가 잘못 인식되면 산술 관계가 깨지기 때문입니다.

ImageToTable.ai의 지능형 데이터 후처리는 이러한 종류의 검증 규칙을 자동으로 적용합니다. 날짜, 금액, 일련번호를 표준화하여 수동 확인 단계 없이 바로 사용할 수 있는 출력을 제공합니다. 하지만 내장된 후처리기가 없더라도 다운스트림 워크플로우에 세 가지 검증 규칙(숫자 검사, 범위 검사, 수학 검사)을 추가하면 문자 혼동 오류의 80%가 회계 시스템에 도달하기 전에 걸러집니다.

근본 원인 3: 형식 차이 — 1.234,56 vs 1,234.56

증상: 추출된 숫자가 세 자릿수만큼 차이 납니다. 유럽 송장의 €1.234,56 합계가 1.234로 추출되거나, 더 나쁜 경우 1,234.56(유럽 표기법으로는 1,234와 56/100을 의미)으로 추출됩니다. 날짜도 영향을 받습니다. 03/04/2026이 송장에 명확히 4월 3일임을 의도했는데 미국 기반 시스템에서 3월 4일로 읽힙니다.

발생 이유: 유럽 대륙 전체, 남미 대부분, 아프리카와 아시아의 상당 부분을 포함한 전 세계 약 60%가 쉼표를 소수 구분 기호로, 마침표를 천 단위 구분 기호로 사용합니다. 미국, 영국 및 소수의 다른 국가에서는 이 규칙이 반대입니다. 독일 송장(€1.234,56)과 미국 송장($1,234.56)을 동일 배치에서 처리하는 AI 추출 엔진은 구조적으로 동일해 보이지만 완전히 다른 의미를 가진 두 숫자를 보게 됩니다.

여기서 미묘한 점이 있습니다: AI는 문서가 어떤 규칙을 따르는지 알려주지 않으면 알 수 없습니다. 시각적 패턴이 동일하기 때문입니다. 즉, 두 개의 구분 기호가 있는 숫자입니다. 모델은 "1.234,56"을 보고 마침표가 천 단위 구분 기호(유럽식)인지 소수점(드물지만 일부 형식에서 가능)인지 본질적으로 알 방법이 없습니다.

해결 방법: 추출 후 검증 규칙이 형식 차이에 대한 가장 신뢰할 수 있는 해결책입니다. AI의 시각적 이해는 근본적으로 문화적이지 시각적이지 않은 모호성을 해결할 수 없기 때문입니다.

• 문서 출처별로 소수점 구분자 규칙을 설정하세요. 독일 공급업체의 송장을 처리하는 경우, 해당 배치에서 쉼표가 소수점 구분자임을 시스템에 알리십시오. ImageToTable.ai의 데이터 후처리를 포함한 대부분의 추출 도구는 배치 수준에서 이를 설정할 수 있습니다.
• 범위 기반 정합성 검사를 적용하세요. 추출된 "합계"가 1.234(유럽 형식 기준 천이백삼십사)인데 개별 항목 합계가 약 1.234,56(천이백삼십사와 56센트)이라면, AI가 소수 부분을 누락했을 가능성이 높습니다. 추출된 합계를 항목 합계와 비교하는 범위 검사로 즉시 이를 발견할 수 있습니다.
• 수학적 일관성 검사를 활용하세요. 원인 2와 동일하게 — 소계 + 세금 = 합계입니다. 소수점 구분자가 잘못 해석되면 계산이 맞지 않으며, 오류가 확산되기 전에 형식을 재검토해야 함을 알 수 있습니다.

여기서 해결책은 더 나은 OCR이 아닙니다. 숫자에 문화적 관습이 있으며, 동일한 시각적 패턴이 문서 출처에 따라 다른 의미를 가진다는 점을 이해하는 검증 계층이 필요합니다.

에스컬레이션 시점: 좋은 도구도 해결 못 하는 예외 사례

정직함이 중요합니다. 모든 잘못된 숫자 오류에 필드명 수준의 해결책이 있는 것은 아닙니다. 가장 구체적인 열 이름과 철저한 후처리를 갖춘 최고의 AI 추출조차도 일부 빈도로 잘못된 결과를 출력하는 두 가지 상황이 있습니다.

상황 1: 동일한 형식의 인접한 합계 행. 송장에 "소계", "할인", "세금", "합계"가 동일한 오른쪽 정렬 열에, 동일한 글꼴 크기와 굵기로, 시각적 구분선 없이 나열된 경우, 모든 AI 엔진은 진정한 모호성 문제에 직면합니다. 모델이 필드를 구분하는 데 사용하는 신호(글꼴 크기, 공백, 레이블 위치)가 모두 없거나 신뢰할 수 없습니다. 이 경우 가장 신뢰할 수 있는 방법은 네 값을 모두 추출하고(각각에 열 정의), 다운스트림 스프레드시트에서 예상 관계(합계는 가장 큰 숫자, 소계는 두 번째로 큰 숫자, 할인은 가장 작은 숫자)를 기반으로 해결하는 것입니다.

상황 2: 단일 문서 내 일관되지 않은 소수점 관습. 일부 송장은 한 섹션에서 마침표를 소수점 구분자로 사용하고 다른 섹션에서 쉼표를 사용하는 등 형식을 혼합합니다. 드물지만 존재하며, 일반적으로 여러 지역 템플릿에서 문서 레이아웃이 조합된 국경 간 송장에서 발생합니다. 이러한 경우 단일 형식 규칙이 전체 문서에 적용되지 않습니다. 해결책은 형식 혼합이 나타나는 필드의 수동 검토와, 항목과 합계가 다른 구분자 패턴을 사용할 때 경고하는 플래그 규칙을 결합하는 것입니다.

이 두 예외 사례 모두에서 올바른 대응은 도구를 비난하는 것이 아닙니다. 원본 문서 자체에 자동화 시스템이 어려움을 겪을 모호성이 포함되어 있음을 인식하고, 그에 따라 검증 워크플로우를 설계하는 것입니다.

자주 묻는 질문

추출된 합계가 틀렸을 때, AI가 무작위 오류를 냈다고 생각해야 하나요?

아니요. 숫자 필드의 추출 오류는 예측 가능한 패턴을 따릅니다. 먼저 열 이름의 구체성을 확인하세요. "Total"은 대부분의 인보이스에서 모호합니다. 올바른 숫자가 문서에 있지만 AI가 반환한 값이 아니라면, 원인은 거의 확실히 필드 모호성(원인 1)입니다. 숫자 자체에 예상치 못한 문자가 포함되어 있다면(숫자 대신 문자가 있는 경우) 문자 혼동(원인 2)입니다. 값의 크기가 약 1,000배 차이난다면 소수점 구분자 문제(원인 3)입니다. 각각 다른 해결 방법이 있지만, 어느 것도 무작위 노이즈로 취급해서는 안 됩니다.

항상 총합계를 원한다면 "Total"이라는 동일한 열 이름을 사용해도 되나요?

사용할 수는 있지만, 합계가 모호한 인보이스에서는 잘못된 결과를 얻게 됩니다. "Total"은 문서 추출에서 가장 과부하된 필드 이름입니다. "Total Amount Due" 또는 "Grand Total (after tax)"와 같은 열 이름은 추가 노력 없이 모호성을 제거합니다. AI는 열 이름을 기본 검색 신호로 사용합니다. 신호가 정확할수록 해석의 여지가 줄어듭니다.

더 나은 AI 하드웨어가 5/S 또는 0/O 간의 문자 혼동을 해결하나요?

아니요. 문자 혼동은 하드웨어 한계가 아닌 근본적인 시각적 모호성입니다. 최첨단 비전 모델과 기본 OCR 엔진 모두 압축된 스캔에서 문자가 9픽셀 높이일 때 동일한 5/S 모호성에 직면합니다. 해결책은 더 나은 모델이 아니라 추출 후 검증입니다. 숫자 전용 필드에 숫자만 포함되어 있는지 확인하고, 범위 검사를 적용하며, 교차 필드 계산을 사용하여 일관성 없는 값을 찾아내는 것입니다. 모델이 좋을수록 그럴듯해 보이는 잘못된 값을 더 확신하며 반환할 수 있습니다.

유럽 인보이스에 €1.234,56이 있지만 추출 결과 1.234가 반환되었습니다. 무슨 일인가요?

AI가 마침표를 소수점으로, 쉼표를 천 단위 구분자(미국 관례)로 해석하여 소수 부분이 완전히 잘렸을 가능성이 높습니다. 유럽 형식의 "1.234,56"은 천이백삼십사와 100분의 56을 의미합니다. 미국 형식으로 읽으면 마침표가 소수점(값을 1.234, 즉 약 1.25로 만듦)이 되고 쉼표는 천 단위 구분자(네 자리 숫자에서는 무시됨)가 됩니다. 배치를 유럽 소수점 형식(쉼표가 소수 구분자임을 시스템에 알림)으로 구성하고 다시 실행하세요.

모든 추출 건에 수동 검토를 적용해야 하나요, 아니면 숫자가 의심스러운 경우에만 적용해야 하나요?

전수 검토보다는 표적 검토가 효과적입니다. 모든 배치에 세 가지 규칙을 적용하세요: (1) 정의된 범위를 벗어난 추출 총액(예: 공급업체 과거 평균에서 표준편차 3배 이상) 플래그 지정, (2) 소계 + 세금 ≠ 총액의 차이가 허용 오차(예: $0.50)를 초과하는 배치 플래그 지정, (3) 숫자만 있어야 하는 필드에 숫자가 아닌 문자가 포함된 경우 플래그 지정. 이 세 가지 규칙으로 대부분의 오류를 잡아내므로 모든 행을 일일이 검사할 필요가 없습니다. 플래그가 지정된 항목에만 수동 검토를 적용하면 처리량은 유지하면서 중요한 오류만 잡을 수 있습니다.

Custom Column Extraction은 템플릿 기반 도구와 모호한 필드명을 처리하는 방식이 어떻게 다른가요?

Custom Column Extraction은 각 열 이름을 위치 기반 규칙이 아닌 의미 검색 쿼리로 처리합니다. "Total Amount Due"를 입력하면 AI는 문서 전체에서 해당 특정 의미(모든 추가 및 차감 후 최종 지불 금액)와 일치하는 값을 검색합니다. 반면 템플릿 기반 도구는 페이지에서 미리 기록된 좌표 영역을 찾습니다. 좌표 영역 방식은 총액 위치가 절대 변하지 않을 때 잘 작동합니다. Custom Column Extraction은 총액 위치는 변하지만 그 의미는 동일할 때 잘 작동합니다. 이 패러다임 전환이 추출 신뢰성을 어떻게 바꾸는지 자세히 알아보려면 AI가 송장 필드를 위치가 아닌 의미로 구분하는 방법을 참조하세요.

동일한 배치에 미국과 유럽 공급업체의 송장(숫자 형식이 다른)을 함께 넣을 수 있나요?

가능하지만, 다운스트림에서 형식 차이를 처리해야 합니다. AI는 페이지에 보이는 그대로 숫자를 추출하며, 배치 내 형식 규칙을 자동으로 정규화하지 않습니다. 혼합 형식 배치의 경우 가장 신뢰할 수 있는 방법은 미국과 유럽 문서를 별도로 처리하고 각 하위 배치에 형식 규칙을 적용하거나, ImageToTable.ai의 후처리 레이어를 사용하여 문서별로 소수점 구분 기호를 감지하고 정규화하도록 구성하는 것입니다. 추출 도구가 직면하는 다양한 필기체 및 문자 장애물에 대한 자세한 내용은 관련 글 OCR이 필기체에 취약한 이유와 해결 방법을 참조하세요.

자신의 문서로 이 접근 방식을 테스트해보세요. 이전에 숫자 오류를 일으켰던 송장을 업로드하고, "Total"이 아닌 "Grand Total After Tax"와 같이 최대한 구체적으로 열을 정의한 후 결과가 어떻게 달라지는지 확인해보세요. 직접 문서로 추출을 테스트하고 문서당 3분이 10초로 단축되는지 확인해보세요.