Mac을 한동안 사용해 보셨다면 라이브 텍스트를 이름은 모른 채 써 보셨을 가능성이 큽니다. 사진 앱의 간판 사진이나 미리보기에 띄운 스크린샷 위로 마우스를 올리면 커서가 텍스트 커서로 바뀌고, 그대로 드래그해서 복사하면 끝입니다. 이런 기능은 워크플로우 속으로 조용히 사라지는데, 시스템 기능에 대한 가장 큰 칭찬은 그런 종류라고 생각합니다.

그렇다면 굳이 비교 글을 쓸 이유가 무엇이냐 하면, 업무에서 OCR을 쓰기 시작하는 순간 라이브 텍스트의 한계에 의외로 빨리 부딪히기 때문입니다. 카카오톡 스크린샷에서 한 단락을 뽑아내고, Zoom 슬라이드의 한 줄을 복사하고, Chrome에서 일시정지한 YouTube 강의의 명령어를 가져오고 — 다 평범한 작업이지만 라이브 텍스트만으로는 길이 끊깁니다. 이 한계는 버그가 아니라 라이브 텍스트가 macOS에 통합된 방식에서 자연스럽게 따라오는 결과입니다. 그 경계를 이해하면, 기본 도구로 충분한지 아니면 보완할 도구를 하나 더 둘 가치가 있는지 판단할 수 있습니다.

이 글은 Cheese! OCR 팀의 솔직한 시각을 담았습니다. 저희는 입장이 있으니 편향이 없을 수는 없습니다. 다만 라이브 텍스트가 더 적합한 상황은 분명히 그렇게 적었습니다. 두루뭉술하게 넘어가는 것은 읽으시는 분의 시간을 빼앗는 일이라고 생각합니다.

라이브 텍스트가 잘하는 일

Apple은 macOS 12 Monterey(2021)에서 라이브 텍스트를 도입했고, 이후 메이저 업데이트마다 다듬어 왔습니다. 핵심 아이디어는 단순합니다. Apple이 제어하는 뷰가 그리는 이미지 — 사진의 이미지, 미리보기의 페이지, QuickTime의 프레임, Safari의 이미지 — 라면 그 자리에서 분석해 텍스트를 선택 가능한 상태로 바꿔 준다는 것입니다. 명시적인 트리거가 없으며, 이미지에 커서가 닿는 시점에 백그라운드에서 동작합니다.

잘 통하는 영역은 예측 가능하고 쾌적합니다.

일상적인 OCR 사용량이 "가끔 사진에서 전화번호를 빼는" 정도라면, 이 정도면 충분히 넘칩니다.

라이브 텍스트가 닿지 않는 4가지 상황

여러 앱을 오가며 텍스트를 자주 다루기 시작하면 다음 네 가지 빈 곳이 차례로 보입니다.

1. 서드파티 앱의 자체 이미지 뷰어

라이브 텍스트는 AppKit의 이미지 렌더링에 후크되어 있지만, 자체 이미지 컴포넌트를 가진 서드파티 앱에서는 적용되지 않을 때가 있습니다. 카카오톡 이미지 뷰어, 슬랙의 이미지 라이트박스, 디스코드의 미디어 뷰어, Notion의 임베드 이미지, 텔레그램의 미디어 미리보기, 그리고 많은 사내 업무 앱이 이미지 렌더링을 자체적으로 처리하면서 시스템의 텍스트 선택 레이어를 우회합니다. 결과적으로 글자는 분명히 보이는데 선택이 되지 않는 상황이 생깁니다.

macOS 안에서의 우회책은 "이미지를 미리보기로 다시 연다"입니다. 한 번이면 괜찮지만, 매번 그럴 수는 없습니다. 마우스 오른쪽으로 저장하고, 다운로드 폴더에서 찾아서, 열고, 선택 — 이 과정을 거칠 거라면 단축키를 두 번 누르는 편이 빠릅니다.

2. 화상 회의

Zoom, Microsoft Teams, Webex, 그리고 Chrome에서 도는 Google Meet 등은 회의 창에 화면 보호 또는 DRM 유사의 플래그를 거는 경우가 많습니다. Apple의 화면 캡처와 라이브 텍스트는 일부 구성에서 이 플래그를 존중합니다. 그래서 슬라이드의 글머리 기호를 드래그해서 선택하려고 해도 아무 반응이 없고, 스크린샷이 검은 사각형으로 저장되기도 합니다.

이는 회의 앱의 악의가 아니라 민감한 발표를 염두에 둔 "기본값 보수적" 정책입니다. 그러나 "이 슬라이드의 URL만 복사하고 싶다" 같은 평범한 작업에는 사실상 벽이 됩니다. 시스템 화면 기록 API를 사용하는 스크린샷 OCR이라면, 소스 앱이 프레임을 그리는 방식에 따라 다르지만, 보이는 픽셀을 캡처해 Apple Vision으로 넘기는 데 성공하는 경우가 많습니다.

3. 보호된 PDF와 일부 사내 문서

텍스트 레이어가 있는 네이티브 PDF는 어느 도구로든 복사할 수 있고 라이브 텍스트도 잘 동작합니다. 스캔 PDF는 약간 까다롭지만 미리보기의 라이브 텍스트가 대개 처리합니다. 까다로운 쪽은 그 사이에 있는 다음 같은 경우들입니다.

"읽는 것은 허용되지만 복사 동작만 UI에서 막힌" 상황의 OCR은 접근 통제를 우회하는 일이 아닙니다. 이미 손에 있는 문서의 UI 제한을 넘는 정당한 수단이라고 봅니다. Cheese! OCR은 이미 렌더링된 픽셀을 읽어 인식할 뿐이므로, 원리적으로는 그 부분을 직접 타이핑하는 것과 같은 행위입니다.

4. Safari 외에서 재생 중인 영상 프레임

라이브 텍스트는 Safari에서 일시정지한 영상에는 잘 동작하지만, Chrome·Firefox·Edge에서는 동작하지 않습니다. 이 브라우저들은 자체 렌더링 엔진을 사용하기 때문에 프레임을 AppKit의 라이브 텍스트 후크에 노출하지 않습니다. IINA, VLC를 비롯한 대부분의 로컬 플레이어도 마찬가지입니다. Chrome으로 본 강의에서 강사가 터미널에 명령을 입력하는 장면이라면, 라이브 텍스트로는 답이 나오지 않습니다.

같은 문제, 같은 해법입니다. 스크린샷 OCR은 어느 앱이 그 픽셀을 그렸는지 따지지 않습니다.

Cheese! OCR이 메우는 부분

Cheese! OCR은 메뉴 바 앱이며, 한 가지 일을 합니다. 전역 단축키(기본값 ⇧⌘E, 변경 가능)를 누르면 화면이 어두워지고 커서가 십자 모양으로 바뀝니다. 인식할 영역을 드래그로 둘러싸면 결과 텍스트가 클립보드에 들어갑니다. 어디에든 붙여 넣으면 끝입니다. 손에 익으면 약 2초짜리 동작입니다.

이번 비교에서 중요한 디테일은 다음과 같습니다.

각 항목은 단독으로 보면 특별하지 않습니다. 그러나 조합되면 위의 네 가지 빈 곳이 컨텍스트 전환 없이 메워진다는 점이 핵심입니다.

라이브 텍스트만으로 충분한 경우

반대로, 굳이 두 번째 도구를 둘 필요가 없는 경우도 분명히 적어 두는 편이 좋겠습니다.

이 중 하나라도 본인의 상황과 맞으면 더 읽지 않으셔도 됩니다. 이미 가진 도구를 그대로 쓰시면 됩니다. 진심입니다.

비교표

항목 macOS 라이브 텍스트 Cheese! OCR
가격 무료, macOS 12 이상에 내장 5.99 USD 일회 구매, 구독 없음
커버리지 Apple 자체 앱과 WebKit 뷰 화면에 보이는 모든 것
실행 방식 이미지 위에 커서를 올려 선택 전역 단축키 + 드래그 선택
언어 Apple Vision(다국어, 필요 시) 영·간체·일·한 자동 인식
히스토리 없음 로컬, 검색 가능
엔진 Apple Vision, 온디바이스 Apple Vision, 온디바이스
네트워크 사용 안 함 샌드박스 권한 0, 검증 가능
적합한 사용 앱 안에서 가끔 텍스트 추출 앱 횡단·반복·대량

간단한 판단 기준

세 가지 규칙으로 대부분의 상황은 정리됩니다.

  1. 이미지 위에 커서를 올렸을 때 텍스트 커서로 바뀐다면 라이브 텍스트를 사용합니다. 이미 그 자리에 준비되어 있습니다.
  2. 소스가 서드파티 앱·화상 회의·Safari 외 브라우저·보호된 문서라면 단축키로 전환합니다.
  3. 이런 작업을 한 주에 여러 번 한다면 단축키를 손에 익히기 좋은 조합으로 설정해 두고, 판단을 근육 기억에 맡깁니다. 하루 이틀이면 두 도구의 전환이 무의식적으로 일어납니다.

저희는 평소에 두 도구 모두 켜 두고 사용합니다. 라이브 텍스트가 "얌전히" Apple 앱 안의 일을 처리하고, Cheese! OCR이 그 외를 맡는 분담입니다. 이 후반부 역할을 직접 시험해 보시려면 Mac App Store의 페이지를 살펴보시면 됩니다. FAQ 아래에는 관련 글도 정리해 두었습니다. 특히 PDF 가이드와 스크린샷 가이드는 여기서 다룬 이야기를 한 단계 더 깊게 풀어냅니다.