업무 중 이런 상황을 겪어 본 적이 있을 것입니다. 나중에 다시 보려고 대화 스레드나 웹페이지를 스크린샷으로 남겨 두었는데, 정작 필요할 때는 그 이미지 안의 텍스트를 검색할 수 없습니다. 또는 서명과 도장이 들어간 중요한 계약서를 원본 기록으로 보관하기 위해 PDF로 스캔했지만, 나중에 내용을 찾거나 문구를 인용하려고 하면 검색도 복사도 되지 않아 페이지를 넘겨 가며 손으로 다시 입력해야 합니다.
Gety의 내장 OCR은 바로 이 문제를 해결하기 위해 만들어졌습니다.
이 문제를 얼마나 잘 해결하는지 확인하기 위해, 우리는 두 개의 공개 데이터셋(MDPBench와 OmniDocBench)의 문서 이미지를 가져와, 사용자 자신의 컴퓨터에서 실행되는 OCR에 초점을 맞춘 자체 평가를 구축했습니다. 우리는 Gety를 실제 업무 흐름에서 사용자가 접할 가능성이 큰 주요 로컬 OCR 옵션들과 비교했습니다. 오픈소스에서 가장 강력한 후보인 PaddleOCR (PP-OCRv6), 오랫동안 기준선 역할을 해 온 Tesseract, 그리고 macOS와 Windows에 기본 탑재된 OCR입니다. Gemini 같은 클라우드 OCR과 클라우드 모델은 의도적으로 제외했습니다. 이들은 업로드, API 호출, 인터넷 연결, 그리고 많은 경우 사용량 기반 비용이 필요하지만, Gety는 전적으로 온디바이스로 실행됩니다.
결과에서 두 가지 장점이 분명하게 드러났습니다.
- 로컬에서 실행되는 온디바이스 OCR 엔진 중 Gety는 다국어 정확도 1위를 차지했으며, 17개 언어 전체에서도 가장 앞선 종합 성능을 보였습니다.
- 비교 가능한 온디바이스 모델 대비 메모리 사용량이 약 5분의 1에 불과해, 장시간 백그라운드 OCR과 실시간 색인을 현실적으로 가능하게 합니다.
1. 다국어: Gety가 가장 크게 앞서는 영역
많은 엔진이 영어와 프랑스어 정도는 충분히 잘 처리합니다. 문제는 문자 체계가 바뀔 때 시작됩니다. 한국어, 러시아어, 태국어, 힌디어로 전환하면 대부분의 모델이 0.9 이상에서 0.2나 0.1까지 떨어져, 실무에서는 거의 쓸 수 없는 수준이 됩니다. MDPBench의 문서 이미지를 사용해 17개 언어에서 각 모델이 어떻게 해내는지 살펴봅니다:
| 언어 / 지표 | Gety OCR (built-in) | Apple Vision (built-in) | PP-OCRv6(small) | PP-OCRv6(tiny) | Windows OCR | Tesseract |
|---|---|---|---|---|---|---|
| 전체 (F1) | 0.903 | 0.881 | 0.724 | 0.686 | 0.609 | 0.541 |
| 라틴 문자 (평균) | 0.966 | 0.940 | 0.967 | 0.957 | 0.847 | 0.901 |
| 영어 | 0.978 | 0.962 | 0.972 | 0.972 | 0.882 | 0.919 |
| 독일어 | 0.959 | 0.967 | 0.992 | 0.991 | 0.923 | 0.962 |
| 프랑스어 | 0.947 | 0.799 | 0.982 | 0.977 | 0.795 | 0.940 |
| 스페인어 | 0.920 | 0.923 | 0.927 | 0.923 | 0.819 | 0.872 |
| 이탈리아어 | 0.980 | 0.976 | 0.985 | 0.979 | 0.887 | 0.932 |
| 포르투갈어 | 0.978 | 0.983 | 0.980 | 0.972 | 0.797 | 0.840 |
| 네덜란드어 | 0.994 | 0.924 | 0.995 | 0.995 | 0.967 | 0.974 |
| 인도네시아어 | 0.974 | 0.966 | 0.987 | 0.987 | 0.892 | 0.959 |
| 베트남어 | 0.967 | 0.958 | 0.884 | 0.814 | 0.661 | 0.716 |
| 비라틴 문자 (평균) | 0.832 | 0.814 | 0.452 | 0.382 | 0.343 | 0.136 |
| 중국어(간체) | 0.946 | 0.912 | 0.965 | 0.957 | 0.800 | 0.180 |
| 중국어(번체) | 0.924 | 0.805 | 0.939 | 0.862 | 0.853 | 0.142 |
| 일본어 | 0.916 | 0.804 | 0.924 | 0.525 | 0.454 | 0.173 |
| 한국어 | 0.970 | 0.961 | 0.276 | 0.248 | 0.211 | 0.190 |
| 러시아어 | 0.954 | 0.960 | 0.155 | 0.106 | 0.096 | 0.102 |
| 태국어 | 0.951 | 0.974 | 0.155 | 0.137 | 0.150 | 0.125 |
| 힌디어 | 0.958 | 0.136 | 0.191 | 0.178 | 0.140 | 0.147 |
| 아랍어 | 0.039 | 0.962 | 0.011 | 0.046 | 0.037 | 0.031 |
주목할 행은 비라틴 문자입니다. 바로 여기서 오픈소스 모델들이 무너져 0.1에서 0.4 범위로 떨어지지만, Gety는 0.832를 유지합니다. 사용자에게 이는 중국어, 일본어, 한국어, 러시아어 문서를 검색할 수 있느냐, 아니면 문자 체계가 바뀌었다는 이유만으로 그 내용이 검색에서 거의 보이지 않게 되느냐의 차이입니다. Gety를 쓰면 이런 언어의 문서가 검색의 사각지대가 될 가능성이 훨씬 낮아집니다.
사진은 별개의 이야기입니다. 입력이 깨끗한 디지털 파일이 아니라 흐림, 기울어짐, 빛 반사가 있는 문서 사진일 때는 모든 모델이 고전합니다:
| 모델 | 디지털 원본 (F1) | 촬영본 (F1) |
|---|---|---|
| Gety OCR (built-in) | 0.903 | 0.322 |
| Apple Vision (built-in) | 0.881 | 0.421 |
| PP-OCRv6(small) | 0.724 | 0.301 |
| PP-OCRv6(tiny) | 0.686 | 0.289 |
| PP-OCRv5 mobile | 0.707 | 0.278 |
| PaddleOCR (PP-OCRv4) | 0.630 | 0.172 |
| Windows OCR | 0.609 | 0.185 |
| Tesseract | 0.541 | 0.192 |
아직 이 부분을 정말 잘하는 모델은 없습니다. 점수는 전반적으로 0.9 범위에서 0.2에서 0.4 대역으로 떨어지며, Apple Vision의 0.421이 가장 높은 값입니다. Gety는 오픈소스 모델들보다 약간 앞서지만, 일상적인 검색에서는 이 열이 숫자만큼 중요하지 않습니다. 실제로 검색하고 싶은 파일은 삐뚤어진 사진이 아니라 깨끗한 스크린샷과 스캔본인 경우가 많으며, 그것이 바로 왼쪽 열입니다.
2. 복잡한 레이아웃: 최고의 오픈소스 모델과 같은 최상위권
언어가 한 축이라면, 레이아웃은 다른 축입니다. 다단 페이지, 표, 반복되는 머리말과 꼬리말 같은 문서에서는 약한 모델이 줄을 빠뜨리거나 순서를 뒤섞기 시작합니다. OmniDocBench는 바로 그것을 시험하도록 만들어졌습니다:
| 모델 | 레이아웃 정확도 (F1) |
|---|---|
| Gety OCR (built-in) | 0.963 |
| PP-OCRv6(small) | 0.968 |
| PP-OCRv6(tiny) | 0.963 |
| Apple Vision (built-in) | 0.948 |
| Windows OCR | 0.855 |
| Tesseract | 0.538 |
Gety의 0.963은 PP-OCRv6 small(0.968)에 0.5퍼센트포인트 뒤지는데, 이는 실사용에서 거의 느껴지지 않을 격차입니다. 두 모델은 사실상 정상에서 동률이며, 둘 다 시스템 내장 엔진들을 크게 앞섭니다.
3. 같은 정확도, 훨씬 적은 리소스
잘 읽는 것은 한 가지입니다. 하루 종일 켜 둘 만큼 가볍게 잘 읽는 것은 또 다른 이야기입니다. 같은 기기에서, 같은 입력, 같은 스레드 예산으로, CPU에서 측정했습니다:
| 모델 | 다국어 정확도 (F1) | 페이지당 중앙값 시간 | 페이지당 최대 메모리 |
|---|---|---|---|
| Gety OCR (built-in) | 0.903 | 862 ms | 908 MB |
| PP-OCRv6(tiny) | 0.686 | 607 ms | 4736 MB |
| PP-OCRv6(small) | 0.724 | 2594 ms | 6304 MB |
Gety는 페이지당 약 908 MB가 필요합니다. PP-OCRv6의 tiny와 small 빌드는 각각 4.7 GB와 6.3 GB, 다섯 배에서 일곱 배 더 많이 필요합니다. 이것이 계속 상주할 수 있는 모델과, 필요할 때 실행하는 작업에 더 어울리는 모델의 차이입니다. Gety는 가볍기 때문에 OCR을 항상 활성 상태로 둘 수 있고, 새 파일이 들어올 때마다 포착해 손 하나 까딱하지 않아도 색인합니다.
(Apple Vision과 Windows OCR은 각자의 플랫폼 안에서 다른 하드웨어로 실행되므로 메모리나 속도 비교가 동등한 조건이 될 수 없습니다. 이들은 정확도 표에만 등장합니다.)
4. 무엇을, 무엇과 비교해 테스트했는가
데이터셋
우리는 두 개의 공개 데이터셋에서 문서 이미지를 가져와 자체 평가를 구축했습니다. 각 데이터셋은 서로 다른 질문에 답하므로, 의미가 희미한 하나의 숫자로 섞기보다는 둘을 분리해 보고했습니다:
| 데이터셋 | 이 데이터셋이 답하는 질문 |
|---|---|
| MDPBench | 깨끗한 페이지와 촬영한 페이지 모두에서, 17개 언어에 걸쳐 정확도가 유지되는가? |
| OmniDocBench | 레이아웃이 복잡해져도 정확도를 유지하는가? |
분명히 해 두자면, 우리는 이 데이터셋을 실제 문서의 출처로 사용했습니다. 평가 방법, 지표, 비교한 모델 집합은 우리 자체의 것이며, 데이터셋 저자들이 발표하는 공식 평가와는 다릅니다.
채점 방법
우리는 레이아웃과 무관한 문자 수준 F1로 OCR 출력을 채점합니다. 이 지표는 레이아웃, 줄바꿈, 문단 구조, 텍스트가 페이지 어디에 있는지가 아니라, 오직 텍스트가 올바르게 인식되었는지만 측정합니다.
우리가 레이아웃과 무관하게 유지하는 이유는, 중요한 용도(검색, 복사, 색인)에서 관건은 모든 문자가 정확히 읽혔는지이지 레이아웃이 재구성되었는지가 아니기 때문입니다. 전부 정확하지만 순서가 다르거나 줄바꿈이 다른 텍스트에 불이익을 줘서는 안 됩니다. 이것은 OCR 테스트이지 레이아웃 테스트가 아닙니다.
각 페이지에 대해, 우리는 OCR 출력을 수작업으로 라벨링한 텍스트와 비교하여 다음을 계산합니다:
채점 전에, 정답과 OCR 출력은 모두 동일한 정규화를 거칩니다: Unicode 정규화, 보이지 않는 문자 제거, 공백 통일, 그리고 머리말, 꼬리말, 페이지 번호 같은 페이지 부속 요소 제거입니다.
문자 매칭은 다중집합 계수를 사용합니다. 여러 번 나타나는 문자는 나타날 때마다 계산됩니다. 이렇게 하면 읽기 순서, 줄바꿈, 문단 분할의 차이가 점수에 영향을 주지 않아, 지표가 OCR이 페이지의 문자를 올바르게 읽었는지에만 집중하게 됩니다.
최종 수치는 페이지당 F1이며, 언어와 데이터 그룹에 걸쳐 매크로 평균을 냅니다. 전체 리포트는 bootstrap 95% 신뢰 구간도 함께 제공합니다.
비교 대상
비교 대상으로는, 실제 업무 흐름에서 사용자가 접할 가능성이 큰 주요 선택지를 골랐습니다:
- PaddleOCR (PP-OCRv6), 오픈소스가 제공하는 최고. tiny, small, medium으로 출시되며, 우리는 온디바이스 빌드인 tiny와 small 두 가지를 실행했습니다. medium은 서버 GPU를 위한 34.5M 파라미터 모델로, 온디바이스 CPU 테스트에 넣는 것은 잘못된 대상을 비교하는 셈입니다.
- Tesseract, 오랜 역사를 가진 오픈소스 엔진으로, 널리 설치되어 있고 대부분이 아는 기준선입니다.
- Apple Vision과 Windows OCR, 아무것도 설치하지 않아도 이미 가지고 있는 OCR입니다.
5. 정확도는 토대이고, 쓸모가 핵심이다
숫자는 Gety가 정확하게 읽는다고 말합니다. 하지만 정확도는 출발점일 뿐, 이 모든 것이 중요한 이유 자체는 아닙니다.
평범한 OCR 도구를 어떻게 쓰는지 생각해 보세요.
이미지 찾기 -> OCR 도구로 열거나 끌어다 놓기 -> 인식을 수동으로 시작하기 -> 결과 기다리기 -> 사용할 수 있는 텍스트 얻기먼저 뽑아낼 만한 텍스트가 있다는 걸 알아채야 합니다. 그런 다음 파일을 찾고, 다른 도구로 가져가고, 인식을 시작하고, 기다린 뒤 결과를 사용해야 합니다. 거의 항상, 이 사슬은 시작조차 되지 않습니다. 스캔본, 스크린샷, 촬영한 계약서는 도착한 날부터 그냥 그 자리에 남아 검색에서 보이지 않게 됩니다.
바로 그 간극이 Gety가 없애려고 나선 문제 전부입니다. OCR은 백그라운드에서 실행되므로, 파일이 들어오는 순간 자동으로 읽히고 색인됩니다. 변환할 것도, 클릭할 것도 없습니다. 검색창에 입력하면 이미지 안의 텍스트가 그냥 거기에 있습니다.
그러니 정확도는 무언가를 찾을 수 있는지를 결정하고, 백그라운드에서 조용히 실행되는 것은 실제로 찾게 되는지를 결정합니다. 우리는 또 하나의 OCR 엔진을 내놓으려던 것이 아닙니다. “이 이미지 안의 단어는 검색되지 않는다”는 일이 사용자의 컴퓨터에서 더 이상 일어나지 않게 만들려던 것입니다.
이것은 우리 자체의 내부 결과입니다. 우리는 공개 데이터셋 MDPBench와 OmniDocBench의 문서 이미지를 테스트 자료로 사용했지만, 평가 방법과 지표는 우리 자체의 것이며 데이터셋 저자들이 발표한 공식 평가와는 다릅니다. 각 데이터셋은 고유의 라이선스와 사용 조건을 지니며 일부는 연구 전용입니다. 우리는 여기서 결과를 보고할 뿐, 어떤 샘플도 재배포하지 않습니다.