온디바이스 OCR은 어떻게 작동하나: Apple Vision 프레임워크 해설

"온디바이스"는 정확히 무엇을 의미합니까

"온디바이스 OCR"이라는 표현은 마케팅 카피에서 자주 쓰이기 때문에, Apple Vision의 맥락에서 무엇을 의미하는지 정확히 정리해 둘 필요가 있습니다. macOS 앱이 Vision에게 이미지 안의 텍스트 인식을 요청하면, 이미지 전처리, 글자 모양을 검출·디코딩하는 합성곱 및 트랜스포머 네트워크, 모호함을 해소하는 언어 모델까지 전체 파이프라인이 사용자의 Mac 내부 하드웨어에서 실행됩니다. CPU, 통합 GPU, 그리고 Apple Silicon이라면 Neural Engine이 모든 작업을 처리합니다. 단 한 바이트도 기기 밖으로 나가지 않습니다.

클라우드 OCR은 완전히 다른 구조입니다. Google Cloud Vision, AWS Textract, Azure Computer Vision은 모두 이미지를 base64 형태로 HTTPS를 통해 업로드하는 것을 전제로 설계되어 있습니다. 이미지는 공급업체의 데이터센터에 도달해 그쪽 모델을 거쳐 처리되고, 인식 결과가 응답으로 돌아옵니다. 이 왕복은 빛의 속도, 사용자의 네트워크, 공급업체의 큐가 정하는 하한이 있습니다. 아울러 그 이미지가 — 아주 잠깐이라도 — 누군가의 디스크에 머무르며 해당 시점의 로깅·보관·ML 학습 정책을 따르게 됩니다.

온디바이스는 이 모든 것을 우회합니다. 업로드 단계가 없고, 앱에 네트워크 권한이 필요하지 않으며, 관리할 API 키도, 모니터링할 할당량도, 호출당 청구도, 읽어야 할 개인정보 처리방침도 없습니다. 대가는 OS가 출시한 모델과 사용자가 산 칩셋에 묶인다는 점입니다. 스크린샷 OCR에 한해서는 대부분의 Mac 사용자가 받아들일 수 있는 거래입니다.

Apple Vision 프레임워크의 짧은 역사

Apple Vision은 2017년 WWDC에서 iOS 11과 macOS 10.13 High Sierra와 함께 등장했습니다. 첫 버전은 얼굴 검출, 사각형 검출, 바코드 인식 정도를 다뤘고 — 유용했지만 아직 OCR은 아니었습니다. 본격적인 텍스트 인식은 2019년 iOS 13 / macOS 10.15 Catalina에서 VNRecognizeTextRequest가 추가되면서 도입되었습니다. "Vision이 글자를 읽을 수 있다"가 마케팅 문구에서 Swift 몇 줄로 호출 가능한 API로 바뀐 시점입니다.

대부분의 사용자가 Apple의 온디바이스 OCR을 체감하는 Live Text(라이브 텍스트)는 그로부터 2년 뒤 iOS 15와 macOS Monterey에서 등장했습니다. Live Text는 프레임워크를 대체한 것이 아니라 그 위에 UI를 얹은 것입니다. 메시지 앱에서 사진을 길게 누르든, Safari에서 텍스트 위에 마우스를 올리든, Cheese! OCR 같은 외부 앱을 쓰든, 내부에서 작동하는 것은 동일한 VNRecognizeTextRequest입니다. Ventura, Sonoma, Sequoia를 거치며 Apple은 인식 모델을 꾸준히 개선하고 지원 언어도 확장해 왔습니다.

2026년 시점에 프레임워크는 수십 가지 언어를 지원하며, 역사적으로 OCR 엔진이 가장 어려워했던 한·중·일 문자도 포함됩니다. Vision은 사진 검색("텍스트가 있는 사진 보여줘"), VoiceOver의 이미지 설명, 비주얼 룩업 같은 기능의 기반 부품으로도 쓰입니다.

VNRecognizeTextRequest API의 구성

개발자가 실제로 호출하는 클래스는 VNRecognizeTextRequest입니다. 입력 이미지, 설정값, completion handler를 받고, 인식 후보와 바운딩 박스가 담긴 VNRecognizedTextObservation 배열을 반환합니다.

핵심 설정은 두 가지입니다. 첫째는 recognitionLevel이며 모드가 두 가지 있습니다. .fast는 속도에 최적화된 작은 모델로, 라이브 카메라 프레임이나 스크롤 중인 동영상에 적합합니다. .accurate는 더 큰 모델로 정지 스크린샷이나 PDF 페이지에 적합합니다. Cheese! OCR을 포함해 대부분의 Mac OCR 도구는 기본값을 .accurate로 두는데, 사용자가 보고 있는 것은 정지 이미지이고 수백 밀리초 차이는 사람이 인지하지 못하기 때문입니다.

둘째는 recognitionLanguages로, BCP-47 언어 태그를 우선순위 순으로 나열한 배열입니다. 예를 들어 "en-US", "zh-Hans", "ja-JP", "ko-KR"입니다. 순서는 모호한 글자 모양을 해소할 때 언어 모델에 힌트로 전달됩니다. 예를 들어 라틴 문자 "o"와 숫자 "0", 키릴 문자 "о"를 구별하는 데 도움이 됩니다. 카카오톡 스크린샷, 한국어 PDF, 영어 논문 등 무엇이든 던져질 수 있는 범용 도구라면 한·중·일·영 네 가지를 기본값으로 켜 두는 것이 합리적입니다.

또 하나, usesLanguageCorrection이라는 Bool 설정이 있어 인식 후 언어 모델 보정을 켜고 끌 수 있습니다. 켜 두면 "teh"가 "the"로 교정되고, 결과가 어휘 통계에 따라 다듬어집니다. 끄면 픽셀 그대로 반환되므로 코드, 차량 번호판, 제품 SKU에 더 적합할 수 있습니다.

최소 구성의 Swift 예제

아래는 CGImage에 대해 Apple Vision OCR을 실행하고 결과를 출력하는 가장 작은 Swift 코드입니다. Cheese! OCR이 내부에서 사용하는 호출 경로에서 오류 처리와 UI 부분을 걷어낸 형태입니다.

import Vision

func recognizeText(in cgImage: CGImage) {
    let request = VNRecognizeTextRequest { request, error in
        guard let observations = request.results as? [VNRecognizedTextObservation] else {
            return
        }
        let lines = observations.compactMap { $0.topCandidates(1).first?.string }
        print(lines.joined(separator: "\n"))
    }

    request.recognitionLevel = .accurate
    request.recognitionLanguages = ["en-US", "zh-Hans", "ja-JP", "ko-KR"]
    request.usesLanguageCorrection = true

    let handler = VNImageRequestHandler(cgImage: cgImage, options: [:])
    try? handler.perform([request])
}

몇 가지 짚어 볼 점이 있습니다. completion handler는 백그라운드 큐에서 실행되므로, UI 앱이라면 클립보드 갱신이나 토스트 표시 전에 메인 스레드로 돌아와야 합니다. topCandidates(1)은 최상위 후보만 반환하지만, 인자를 늘리면 사용자에게 여러 후보를 노출할 수 있습니다. 여기서는 VNImageRequestHandler가 CGImage를 받지만, CVPixelBuffer, CIImage, 파일 URL도 받습니다. 동영상 프레임이나 PDF 페이지를 흘려보낼 때 유용합니다.

일반적인 사용 사례에서 만지는 API는 이게 전부입니다. 설치할 SDK도, 번들에 넣을 모델 파일도, 인증 흐름도, 사용량 대시보드도 없습니다. OS가 모델을 제공하고, 칩셋이 실행하고, 앱은 함수 하나를 호출합니다.

Apple Silicon에서 Neural Engine이 중요한 이유

Neural Engine은 Apple Silicon 칩 안에 들어 있는 전용 머신 러닝 가속기입니다. M1은 16개 코어로 시작했고 M2와 M3도 같은 코어 수를 유지했으며, M4는 처리량과 공유 메모리 대역폭에서 아키텍처 개선이 있었습니다. Apple Silicon Mac에서는 Vision의 텍스트 인식 모델이 기본적으로 Neural Engine용으로 컴파일되어 실행되며, Neural Engine이 처리하지 못하는 부분은 GPU가 백업합니다.

실제 효과는 두 가지입니다. 첫째, OCR이 빠릅니다. 단축키를 눌러 화면 일부를 잘라내면 거의 즉시 결과가 돌아옵니다. 둘째, OCR이 에너지 효율적입니다. Neural Engine은 추론당 전력 소비가 CPU나 GPU보다 훨씬 낮아서, 수백 장의 OCR을 연속으로 돌려도 MacBook의 배터리가 눈에 띄게 줄지 않습니다. 같은 하드웨어가 Siri, 사진 검색, 음성 메모 받아쓰기, Apple Intelligence 기능도 가속하며, Vision은 그중 한 사용자일 뿐입니다.

Intel Mac에서도 프레임워크는 작동합니다. CPU와 GPU 경로로 대체되어 다소 느리지만, 일반적인 스크린샷 크기의 이미지라면 사람이 체감할 만한 차이가 잘 나오지 않습니다. Vision은 최신 하드웨어만이 아니라 Mac 라인업 전체에서 사용 가능하도록 의도적으로 설계되었습니다.

개인정보: 온디바이스가 가지는 의미

온디바이스 OCR에서 가장 자주 가볍게 다뤄지는 부분이 사실 개인정보입니다. 기술적인 주장은 단순합니다. Apple Vision으로 스크린샷을 OCR할 때, 그 스크린샷의 바이트는 Mac 밖으로 나가지 않습니다. Apple은 보지 못합니다. 사용자의 네트워크도 보지 못합니다. Vision을 호출하는 외부 앱조차 — 그 자체로는 — 그 이미지를 외부로 보내지 않습니다.

마지막 부분이 중요한 이유는 "온디바이스 OCR"이라는 용어가 때때로 느슨하게 쓰이기 때문입니다. 어떤 앱이 Apple Vision을 사용하면서도 인식 결과나 텔레메트리, 심지어 원본 스크린샷을 "학습용"으로 자사 서버에 보낼 수 있습니다. 이 사실 여부를 확인하는 방법은 App Store 샌드박스의 네트워크 권한을 보는 것입니다. Mac App Store를 통해 배포되는 앱은 사용하는 모든 네트워크 기능을 선언해야 하며, 네트워크 권한이 전혀 없는 앱은 커널 수준에서 어떤 종류의 HTTP 호출도 차단됩니다. 예외는 없습니다.

Cheese! OCR이 바로 그런 종류입니다. 네트워크 권한이 없고, 텔레메트리 SDK도, 분석 서비스도, 데이터를 외부로 보내는 크래시 리포터 종류도 없습니다. Vision 호출은 OS로 가고, 인식 결과는 시스템 클립보드로 갑니다. 데이터 흐름은 거기서 끝입니다. 회사 기밀 문서, 내부 슬랙 스레드, 개인적인 메시지 같은 스크린샷에서 OCR을 사용하는 경우 이 차이가 크게 다가옵니다.

Apple Vision vs 클라우드 OCR — 비교 표

트레이드오프를 한곳에 정리해 보겠습니다. 클라우드 가격은 공급업체가 요금 체계를 자주 재편하기 때문에 범위로 표기했습니다. 실제 단가는 사용량, 리전, 기능 플래그에 따라 달라지므로 대략적인 자릿수로만 참고하시고 정확한 수치는 공급업체 가격 페이지에서 확인하시길 바랍니다.

일반 사용자용 Mac 앱에 한해 결론은 분명합니다. 비용·지연·개인정보 세 항목에서는 Apple Vision이 우위입니다. 서버 사이드 일괄 처리, 구조화된 폼 파싱, Apple이 출시하지 않은 언어가 필요하면 클라우드 API가 우위입니다.

Apple Vision이 아직 어려워하는 영역

Apple Vision이 완벽하다고 쓰는 건 정직하지 않습니다. OCR 전략을 짤 때 알아둘 가치가 있는 한계들이 있습니다.

흘려 쓴 손글씨. 정자에 가까운 손글씨는 어느 정도 읽어내지만, 흘려 쓴 영어, 자유롭게 적은 메모, 손으로 쓴 한자나 한글은 결과가 들쭉날쭉합니다. 워크플로우의 핵심이 손글씨 노트 스캔이라면 Apple Vision 단독으로는 부족합니다. 멀티모달 LLM이나 전용 손글씨 인식 엔진이 더 잘 맞습니다.

세로쓰기 한·중·일 텍스트. 일본 서적, 한문 고전, 전통 포스터는 위에서 아래로, 오른쪽에서 왼쪽으로 흐르는 경우가 많습니다. Vision의 텍스트 검출기는 가로쓰기 좌→우 라인에 강하게 편향되어 있어, 세로 단을 잘게 쪼개거나 읽는 순서를 잘못 잡는 경우가 잦습니다. "이건 세로쓰기"라고 알리는 공개 플래그도 없습니다.

심한 기울임이나 왜곡. 책등 부근에서 굽은 페이지, 비스듬히 찍은 간판, 원근 변형이 들어간 스크린샷은 검출기를 혼란스럽게 만듭니다. Vision도 어느 정도 보정을 하지만, 일부 클라우드 서비스만큼 적극적이지는 않습니다.

장식 글꼴. 게임 UI의 꾸민 글자, 서예, 복고풍 간판, 자간이 극단적인 로고는 정확도가 떨어집니다. 모델은 일반 서체에 맞춰 학습되어 있고, 장식 글꼴 롱테일은 알려진 약점입니다.

수학·화학 표기. 방정식, 적분 기호, 화학 구조식, 읽는 순서대로 배열되지 않은 2차원 레이아웃은 일렬 문자열로 평탄해집니다. LaTeX나 MathML 출력이 필요하면 전용 모델이 필요하며, Mathpix가 존재하는 이유가 정확히 그 때문입니다.

이런 한계가 온디바이스 OCR이 일반 용도에 부적합하다는 뜻은 아닙니다. 만능 용제가 아니라는 의미일 뿐입니다.

Cheese! OCR 같은 도구에 이것이 어떤 의미인가

이런 기반 이야기가 Mac OCR 유틸리티에 의미를 가지는 이유는, 프레임워크 선택이 그 앱이 약속할 수 있는 것과 약속할 수 없는 것을 결정하기 때문입니다. 클라우드 기반 OCR 앱이 "초고속 OCR"을 내세우더라도, 네트워크 지연이라는 바닥과 사라지지 않는 개인정보 각주가 따라옵니다. Apple Vision 위에 만든 완전 로컬 OCR 앱은 프레임워크의 바닥(매우 빠름)과 그 천장(Apple이 출시한 언어와 정확도)을 그대로 물려받습니다.

Cheese! OCR은 Apple Vision 위에 직접 구축되어 있습니다. 단축키를 누르고 화면의 영역을 드래그로 선택하면, 그 결과 CGImage가 한·중·일·영 네 가지 언어를 기본 활성화한 채 VNRecognizeTextRequest로 전달됩니다. 잠시 후 인식 결과가 클립보드에 들어가고, 로컬 SQLite 기록 데이터베이스에 저장됩니다. 서버는 없습니다. 네트워크 권한도 없습니다. 텔레메트리도 없습니다. 이 앱은 Live Text와 동일한 모델을, 다른 — 솔직히 더 손에 익는 — UI로 돌리고 있을 뿐입니다.

이 선택은 사용자가 체감할 수 있는 결과를 만듭니다. 비행기 안에서도 작동합니다. 인터넷의 절반을 차단하는 사내 VPN 안에서도 작동합니다. Google 서비스가 닿지 않는 지역에서도 작동합니다. 집 Wi-Fi가 흔들려도 느려지지 않습니다. 기밀 계약서나 개인 메시지의 스크린샷을 OCR할 때, "이 이미지를 지금 어느 제3자가 봤을까"를 더 이상 신경 쓰지 않아도 됩니다.

자기 Mac에서 쓸 OCR을 고를 때 가장 먼저 정리해야 할 것은 프레임워크 레이어 이야기입니다. 클라우드와 로컬 둘 다 정당한 사용처가 있습니다. 개인 Mac에서 일상 스크린샷 OCR을 한다는 전제라면, 온디바이스 Apple Vision을 이기기는 어렵습니다 — 그리고 자주 받는 질문은 아래 FAQ에 정리해 두었습니다.