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

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

AI 추출 작업을 해본 사람이라면 누구나 한 번쯤 겪는 상황이 있습니다. 또렷하게 읽히는 송장을 업로드하고, 도구가 모든 필드를 자신 있게 반환하는 것을 확인한 순간, 문제를 발견합니다. "Total" 열에 $1,247.30이 표시되는데 실제 송장 합계는 $1,447.30인 경우입니다. Subtotal, Tax, 품목별 금액은 모두 정확해 보입니다. 그런데 가장 중요한 숫자 하나가 $200 차이로 틀린 것입니다.

잘못 추출된 합계는 우연이 아닙니다. 예측 가능한 패턴을 따르기 때문에 도구를 바꾸지 않고도 문제를 진단하고 해결할 수 있는 경우가 대부분입니다. 저희가 처리하는 문서들을 살펴보면, 잘못된 숫자의 거의 모든 원인은 동일한 세 가지로 귀결됩니다.

그 비용은 결국 후속 작업으로 이어집니다. 이미 반영된 잘못된 합계를 추적하고 수정하는 데는 몇 분이 걸리며, 자동화 프로세스가 절약한 시간보다 더 많은 정리 작업을 만들어냅니다. 하지만 해결책은 다른 AI 엔진이 필요한 경우가 거의 없습니다. 필요한 것은 자신의 오류가 세 가지 근본 원인 중 어느 범주에 속하는지 아는 것입니다.

맞춤 열 추출이 이 진단의 기반이 되는 메커니즘입니다. 원하는 필드 이름을 입력하면 AI가 레이블의 위치가 아니라 의미를 이해하여 페이지 어디에서든 각각의 일치 값을 찾아냅니다. 그래서 필드 설계가 그만큼 중요합니다. AI는 사용자가 지정한 정확한 레이블을 기준으로 작동하며, 정확한 레이블은 잘못된 숫자를 선택할 여지를 줄여줍니다. 아래의 세 가지 근본 원인 범주는 거의 모든 잘못된 숫자 오류를 설명하며, 각각 고유한 진단 테스트가 있습니다.

근본 원인 1: 모호한 필드 설계 — "Total"이 충분히 구체적이지 않음

증상: 추출된 합계가 기대한 합계가 아닙니다. Subtotal일 수도 있고, 인지하지 못한 할인 후 금액일 수도 있습니다. 순액을 원했는데 세금 포함 합계일 수도 있습니다. 하지만 숫자 자체는 읽을 수 있고 송장에 표시되어 있습니다. 여러 금액 중에서 잘못된 것을 고른 것뿐입니다.

발생 이유: 일반적인 송장의 합계 섹션에는 최소한 세 개의 금액 필드가 세로로 배치되어 있습니다: Subtotal, Tax, Total입니다. 많은 송장에는 같은 열에 Discount, Shipping 또는 Previous Balance 필드도 포함되어 있습니다. 추출 열 이름을 "Total"로 지정하면 AI는 이 중 어떤 금액을 의미하는지 추측해야 합니다. "Total"이라는 단어는 문서상 유효한 필드 레이블이지만, "Subtotal"에도 들어가는 단어이며 "Tax"와 "Shipping"도 위치하는 영역이기도 합니다. AI는 어떤 합계가 중요한지에 대한 기본 지식이 없습니다. 사용자가 제공한 레이블을 읽고 페이지에서 가장 적합한 의미적 일치를 찾을 뿐입니다. 하나의 레이블이 다섯 가지 가능한 값에 매핑되면 오류율이 높아집니다.

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

해결 방법: 원하는 금액을 구체적으로 지정하세요. "Total"이라는 열 이름 대신 다음 중 하나를 사용하세요:

• "Total Amount Due": 모호함이 없으며, 대부분의 송장에서 최종 지불 금액으로 표시됩니다
• "Grand Total (after tax)": 접미사가 AI에게 모든 합산 후의 최종 금액임을 알려줍니다
• "Subtotal (before tax)": 세금 포함 값을 명시적으로 제외합니다
• "Amount Paid" / "Balance Due": 명세서에서 지불 금액과 미지불 금액을 구분합니다

열 이름이 구체적일수록 AI가 선택할 후보가 줄어듭니다. 이것이 추출이 작동하는 방식이며, 우회 방법이 아닙니다. 현대 AI가 위치가 아닌 의미로 송장 필드를 구분하는 방법에서 필드 수준의 추출 정확도를 라벨의 구체성이 어떻게 직접 제어하는지 설명합니다.

이것이 문제인지 테스트하려면: 추출 출력과 함께 송장을 살펴보세요. AI가 "Total"에 대해 반환한 값과 문서에서 일치하는 값을 찾으세요. 두 값이 같지만 그 값이 하위 합계나 세금 포함 합계라면 모호성 문제가 있는 것이며, 해결책은 더 구체적인 열 이름을 사용하는 것뿐입니다. 이름이 올바르게 지정되면 특정 송장 필드를 Excel로 추출하는 것이 다음 단계입니다.

근본 원인 2: 문자 혼동 — 5가 S로, 0이 O로 바뀔 때

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

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

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

해결 방법: 문자 혼동은 추출 중이 아닌 추출 후에 잡는 것이 가장 좋습니다. 추출된 값을 예상 패턴과 대조하여 확인하는 필드 수준 검증 규칙을 구현하세요:

• 숫자 전용 필드: 필드에 숫자만 포함되어야 하는 경우, 간단한 정규식 검사를 실행하세요. 숫자 전용 필드에서 숫자가 아닌 문자로 추출된 것은 거의 확실히 오독입니다. 해당 컨텍스트에서 "S"를 "5"로, "O"를 "0"으로, "l"을 "1"로 바꾸세요.
• 범위 검사: 추출된 Total이 $5,000.00인데 해당 공급업체의 다른 모든 송장이 $200–$800 범위라면 검토용으로 표시하세요. 단일 이상값은 종종 잘못된 소수점 위치나 문자 오독으로 값이 한 자릿수 단위로 부풀려진 결과입니다.
• 교차 필드 수학 검증: Subtotal + Tax = Total인지 확인하세요. 작은 허용 오차 내에서 수학이 맞지 않으면 세 숫자 중 하나 이상에 문자 수준 오류가 있는 것입니다. 이 단일 검사는 문자 혼동 오류의 대부분을 잡아냅니다. 세 Total 중 하나라도 숫자가 잘못 읽히면 산술 관계가 깨지기 때문입니다.

ImageToTable.ai의 지능형 데이터 후처리는 이 중 형식 부분을 자동으로 처리하여 날짜, 금액, 일련번호를 표준화해 값이 일관된 형태로 도착하게 합니다. 수학 부분은 스프레드시트 대신 추출 중에 실행할 수 있습니다: 열 이름에 계산을 설명하세요(예: "Tax Check (Subtotal + Tax = Total)"). 그러면 ImageToTable.ai가 문서를 읽으면서 계산을 수행하고 통과, 실패 또는 차이를 출력합니다. Subtotal + Tax가 인쇄된 Total과 일치하지 않으면 그 불일치가 직접 만들어야 할 수식이 아니라 해당 행의 값으로 도착합니다.

근본 원인 3: 형식 변동 — 1.234,56 vs 1,234.56

증상: 추출된 숫자가 세 자릿수 단위로 차이가 납니다. 유럽 송장의 €1.234,56 합계가 1.234로 추출되거나, 더 나쁘게는 1,234.56으로 추출됩니다. 날짜도 영향을 받습니다: 03/04/2026은 송장이 분명히 4월 3일을 의미하는데 미국 기반 시스템에서는 3월 4일로 읽힙니다.

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

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

해결 방법: 추출 후 검증 규칙이 형식 변동에 대한 실제 작업을 수행합니다. AI의 시각적 이해는 문화적이지 시각적이지 않은 모호성을 해결할 수 없기 때문입니다.

• 문서 소스별로 소수 구분 기호 규칙을 설정하세요. 독일 공급업체의 송장을 처리한다면 해당 문서 그룹에 대해 쉼표를 소수 구분 기호로 정의하세요. ImageToTable.ai의 데이터 후처리는 출력의 일부로 날짜, 금액, 일련번호 형식을 표준화하므로 내보낸 값은 설정한 규칙을 따릅니다.
• 범위 기반 타당성 검사를 적용하세요. 추출된 "Total"이 1.234인데 품목 합계가 약 1.234,56이라면 AI가 소수 부분을 놓쳤을 가능성이 높습니다. 추출된 합계를 품목 합계와 비교하는 범위 검사는 이를 즉시 포착합니다.
• 수학적 일관성 검사를 사용하세요. 원인 2와 동일합니다: 소계 + 세금 = 합계. 소수 구분 기호를 잘못 해석했다면 계산이 맞지 않으며, 오류가 전파되기 전에 형식을 다시 확인해야 한다는 것을 알 수 있습니다.

더 강력한 OCR 엔진으로는 이 문제를 해결할 수 없습니다. 모호함이 시각적 문제가 아니라 문화적 문제이기 때문입니다. 효과가 있는 것은 값이 이동하기 전에 파싱된 숫자를 문서의 나머지 부분과 대조하는 검증 레이어입니다.

언제 에스컬레이션해야 하는가: 좋은 도구도 해결할 수 없는 경계 사례

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

상황 1: 동일한 형식의 인접한 합계 행. 송장에 "Subtotal", "Discount", "Tax", "Total"이 동일한 오른쪽 정렬 열에, 동일한 글꼴 크기와 굵기로, 시각적 구분선 없이 나열된 경우, 어떤 AI 엔진도 진정한 모호성 문제에 직면합니다. 모델이 필드를 구분하는 데 사용하는 신호는 이 경우 약하거나 모순적입니다. 이 경우 실용적인 접근 방식은 네 값을 모두 추출하고 예상 관계에 따라 다운스트림 스프레드시트에서 어느 것이 어느 것인지 결정하는 것입니다: 합계는 가장 큰 숫자, 소계는 두 번째로 큰 숫자, 할인은 가장 작은 숫자여야 합니다.

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

두 경계 사례 모두에서 도구를 탓하는 것은 요점을 놓치는 것입니다. 원본 문서 자체에 자동화된 시스템이 어려움을 겪을 모호성이 내재되어 있으므로, 작업은 이를 중심으로 검증 워크플로우를 설계하는 것으로 전환됩니다.

자주 묻는 질문

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

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

항상 총 합계를 원한다면 같은 열 이름 "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"은 1,234와 56/100을 의미합니다. 미국식 표기법으로 읽으면 마침표가 소수점이 되어 쉼표는 천 단위 구분 기호가 되어 네 자리 숫자에서는 무시됩니다. 배치를 유럽식 소수점 형식으로 구성하여 시스템에 쉼표가 소수 구분 기호임을 알린 후 다시 실행하세요.

모든 추출에 수동 검토를 추가해야 할까요, 아니면 숫자가 의심스러울 때만 해야 할까요?

전면 검토보다는 표적 검토가 낫습니다. 모든 배치에 세 가지 규칙을 적용하세요: (1) 정의된 범위를 벗어나는 추출된 Total에 플래그를 지정하고, (2) subtotal + tax ≠ total이 소정의 허용 오차를 초과하는 배치에 플래그를 지정하고, (3) 숫자만 있어야 하는 필드에 숫자가 아닌 문자가 포함된 경우 플래그를 지정하세요. 이 세 가지 규칙은 모든 행을 일일이 검토하지 않아도 대부분의 잘못된 숫자 오류를 잡아냅니다. 플래그가 지정된 항목에만 수동 검토를 적용하면 처리량을 높게 유지하면서 중요한 오류를 놓치지 않을 수 있습니다.

Custom Column Extraction은 템플릿 기반 도구와 모호한 필드 이름을 다르게 처리하는 방법은 무엇인가요?

Custom Column Extraction은 각 열 이름을 위치 기반 규칙이 아닌 의미 검색 쿼리로 취급합니다. "Total Amount Due"를 입력하면 AI는 문서 전체에서 해당 특정 의미, 즉 모든 추가 및 차감 후 최종 지불 금액과 일치하는 값을 검색합니다. 반면 템플릿 기반 도구는 페이지의 미리 기록된 좌표 영역을 봅니다. 좌표 영역 접근 방식은 Total이 이동하지 않을 때 잘 작동하지만, Custom Column Extraction은 Total이 이동해도 그 의미가 동일하게 유지될 때 잘 작동합니다.

같은 배치에 서로 다른 숫자 형식을 가진 미국 및 유럽 공급업체의 송장이 포함될 수 있나요?

가능하지만, 다운스트림에서 형식 변동을 처리해야 합니다. AI는 페이지에 표시된 대로 숫자를 추출하며 배치 내에서 형식 규칙을 자동으로 정규화하지 않습니다. 혼합 형식 배치의 경우 실용적인 접근 방식은 미국 및 유럽 문서를 별도로 처리하여 각 그룹에 해당 형식 규칙을 적용하거나, 값이 회계 시스템에 도달하기 전에 후처리 단계에서 구분 기호를 정규화하는 것입니다. 추출 도구가 직면하는 쓰기 및 문자 장애의 종류에 대해 더 자세히 알아보려면 OCR이 손글씨에 어려움을 겪는 이유와 해결 방법에 대한 관련 글을 참조하세요.

자신의 문서에서 이 접근 방식을 테스트해 보세요. 잘못된 숫자 오류를 일으킨 것으로 알고 있는 송장을 업로드하고, "Total" 대신 "Grand Total After Tax"를 사용하여 최대한 구체적으로 열을 정의한 다음 결과가 달라지는지 확인하세요. 자신의 문서에서 추출을 시도하고 문서당 3분이 10초가 되는지 확인해 보세요.