두 단의 실제 OCR 출력 — 공백·줄바꿈 유지
Apple 120 3 Cherry 360 5 Banana 250 4 Orange 480 6
같은 글자·숫자를 한 단, 두 단, 표로 배치해 실제 OCR 결과를 비교했습니다. 읽는 순서가 섞이는 사례와 엑셀에 붙여넣기 전 확인할 기준을 설명합니다.
표 사진에서 글자를 추출했는데 엑셀에 붙여넣으니 항목과 숫자가 한 칸에 몰리거나 순서가 어긋날 때가 있습니다. 글자를 잘못 읽은 것이 아니라 배치를 다르게 읽은 경우도 있습니다.
같은 항목과 숫자를 한 단·두 단·표로 놓고 결과를 비교했습니다. 아래 원본과 추출 문장에서 Apple 다음에 무엇이 오는지부터 보세요. 두 단 전체는 순서가 섞였고, 단별로 나누자 의도한 순서가 남았습니다. 툴릿 OCR은 글자 추출 도구이며 엑셀 표를 복원하는 도구는 아닙니다.
두 단 전체에서는 Apple 다음에 Banana가 아니라 오른쪽 단의 Cherry가 이어졌습니다.
이 샘플을 왼쪽·오른쪽으로 따로 추출한 뒤 연결하니 원래 목록 순서와 일치했습니다.
네 행의 항목 관계는 유지됐지만 칸 사이에 여러 공백이 들어갔고 셀 구분용 탭은 없었습니다.
왼쪽 단을 끝까지 읽은 다음 오른쪽으로 넘어가길 기대했지만, 전체 이미지의 결과는 같은 높이의 항목을 이어 붙였습니다. Apple 다음에 Cherry가 오는 것을 아래 원본과 출력에서 바로 확인할 수 있습니다. 이 순서는 설명을 위해 편집한 문장이 아니라 공개 측정 자료에 남은 실제 결과입니다.
두 단의 실제 OCR 출력 — 공백·줄바꿈 유지
Apple 120 3 Cherry 360 5 Banana 250 4 Orange 480 6
표의 실제 OCR 출력 — 공백·줄바꿈 유지
Apple 120 3 Banana 250 4 Cherry 360 5 Orange 480 6
원본 세 장 모두 항목명 네 개와 숫자 여덟 개가 정확하게 포함됐습니다. 하지만 두 단 전체의 출력 순서는 기대한 목록 순서와 달랐습니다. 아래의 12/12는 이 작은 샘플의 항목·숫자 일치 개수이며 일반적인 OCR 정확도 100%라는 뜻이 아닙니다.
| 입력 | 항목·숫자 일치 | 의도한 순서 | 관찰 |
|---|---|---|---|
| 한 단 목록 | 12/12 | 일치 | 한 항목씩 네 줄 |
| 두 단 전체 | 12/12 | 불일치 | Apple→Cherry→Banana→Orange |
| 단순 표 | 12/12 | 일치 | 네 행 유지, 칸 사이 다중 공백 |
| 두 단을 따로 추출 후 연결 | 12/12 | 일치 | Apple→Banana→Cherry→Orange |
원래 왼쪽에는 Apple 120 3, Banana 250 4가 있고 오른쪽에는 Cherry 360 5, Orange 480 6이 있습니다. 전체 추출의 첫 줄은 ‘Apple 120 3 … Cherry 360 5’, 둘째 줄은 ‘Banana 250 4 … Orange 480 6’이었습니다. 왼쪽 단을 다 읽은 뒤 오른쪽 단으로 가는 대신 같은 높이의 내용을 붙였습니다.
왼쪽과 오른쪽을 각각 500×220픽셀로 잘라 같은 엔진에 넣었더니 각 단에서 두 항목씩 추출됐습니다. 왼쪽 결과 뒤에 오른쪽 결과를 연결하자 기대한 순서가 맞았습니다. 모든 두 단 문서에서 전체 추출이 실패한다는 뜻은 아닙니다. 문장 길이, 간격, 제목 배치에 따라 결과는 달라질 수 있습니다.
이 단순 표는 네 행의 순서와 각 행의 항목·숫자 관계가 유지됐습니다. 결과는 ‘Apple [여러 공백] 120 [여러 공백] 3’처럼 나왔고 탭 문자는 0개였습니다. 인식 결과에는 이 값이 몇 번째 셀인지 알려주는 표 구조가 없습니다.
탭과 줄바꿈은 스프레드시트에 붙여넣을 때 열·행 구분에 쓰일 수 있지만, 이번 결과처럼 간격을 여러 공백으로 표현한 텍스트는 그대로 세 열이 된다고 기대할 수 없습니다. 병합 셀, 여러 줄 항목명, 빈 칸, 통화 기호가 있는 표는 별도 검증이 필요합니다. 이번 시험에서 엑셀 앱에 직접 붙여넣는 과정은 수행하지 않았습니다.
먼저 전체 추출 후 첫 두세 줄을 원본과 대조하세요. 줄을 따라 읽어야 하는 표인지, 단을 따라 읽어야 하는 본문인지부터 정하면 순서 오류를 찾기 쉽습니다.
| 문서 상황 | 먼저 할 일 | 확인할 항목 |
|---|---|---|
| 한 단 본문 | 전체 이미지 추출 | 문장과 줄 순서 |
| 두 단 논문·뉴스 | 전체 결과가 섞이면 단별 이미지로 추출 | 왼쪽 끝과 오른쪽 시작 연결 |
| 짧은 단순 표 | 각 행을 원본과 대조해 열 구분 정리 | 항목·금액·수량의 짝 |
| 빈 칸·병합 셀이 있는 표 | 셀 구조를 보존하는 전용 표 인식 검토 | 빈 값의 위치와 열 이동 |
| 회계·제출용 수치 | 최종 파일에서 원본과 다시 대조 | 소수점·부호·합계 |
문장에는 연속 공백을 하나로 줄이는 정리가 편리하지만 표에서는 칸 사이 간격 단서가 사라집니다. 모든 줄을 연결하면 행 구분까지 없어집니다. 텍스트 정리기가 이미 뒤섞인 단의 순서나 사라진 빈 셀을 자동 복원해 주지는 않습니다.
표라면 원래 OCR 결과를 먼저 저장하고, 한 행의 세 값을 대조한 뒤 필요한 구분자를 넣으세요. ‘Red Apple’처럼 항목명 자체에 공백이 있으면 공백을 모두 탭으로 바꾸는 방식도 잘못된 열을 만듭니다. 실제 최종 붙여넣기 결과에서 열 개수를 다시 확인하는 편이 안전합니다.
아래 PNG를 열어 배치를 확인하거나 저장해 추출해 볼 수 있습니다. JSON에는 기대한 원문, 실제 출력의 공백과 줄바꿈, 판정, 원본 해시와 모델 해시가 들어 있습니다. 다른 글꼴로 다시 이미지를 생성하면 결과가 달라질 수 있으므로 같은 입력을 비교하려면 공개 PNG를 사용하세요.
표본은 합성 이미지 세 장과 그중 두 단의 잘라낸 이미지 두 장뿐입니다. 촬영 각도, 흐림, 한글 본문, 긴 표, 각주, 병합 셀, 브라우저별 성공률은 측정하지 않았습니다. 별도 표 복원 서비스와의 성능 비교도 아닙니다.
Tesseract 공식 문서는 표 인식에 별도 영역 분리나 배치 분석이 필요할 수 있다고 설명합니다. 이는 이번 현상을 이해하는 배경일 뿐 모든 OCR 제품이 같은 출력이나 같은 한계를 가진다는 근거는 아닙니다.
2026년 10월 1일, 흰 바탕·검은 32픽셀 Arial 글자의 1000×440 PNG 세 장을 생성했습니다. 내용은 Apple 120 3 / Banana 250 4 / Cherry 360 5 / Orange 480 6입니다. 실제 영수증이나 사용자 파일은 쓰지 않았습니다.
한 단은 위에서 아래, 두 단은 왼쪽 위→왼쪽 아래→오른쪽 위→오른쪽 아래를 의도한 순서로 정했습니다. 표는 항목·가격·수량에 해당하는 세 칸을 네 행으로 배치했습니다. 일부러 같은 높이에 배치한 두 단 목록은 읽는 방향을 쉽게 잘못 해석할 수 있는 조건입니다.
도구와 같은 Tesseract.js 7.0.0, 한국어+영어 모델과 기본 인식 설정으로 실행했습니다. Node.js v24.14.1에서 엔진을 호출한 시험이며 브라우저 UI를 통한 통합 시험은 아닙니다. 영문·숫자로 배치 효과를 분리했으므로 한국어 논문이나 실제 촬영 사진 전체의 정확도를 뜻하지 않습니다.
원본 세 장과 두 단을 자른 두 장을 각각 한 번 인식했습니다. 공백·줄바꿈을 한 공백으로 바꾼 뒤 전체 항목 순서를 비교했습니다. 이 판정은 표의 칸 구조가 보존됐는지 평가하지 않으므로 원문 출력도 함께 공개합니다. 재현 스크립트는 scripts/measure-ocr-layout.mjs입니다.
위 본문에 주요 결과를 정리했습니다. 아래는 처리 조건과 파일 확인값을 담은 원본 기록입니다. 열면 설명 페이지가 아닌 JSON 텍스트가 표시됩니다.
이번 샘플에서는 같은 글자가 모두 맞아도 두 단 전체의 순서는 달랐고, 단별 추출은 기대한 순서를 유지했습니다. 단순 표는 행 관계가 남았지만 스프레드시트의 셀 구조까지 만들어지지는 않았습니다.
본문은 문장 연결을, 표는 항목과 숫자의 짝을 우선 확인하세요. 글자 추출 결과를 곧바로 완성된 문서나 검증된 엑셀 데이터로 여기지 않는 것이 재작업을 줄이는 출발점입니다.