한국어 OCR이 까다로운 이유

2026년 기준으로 영어 OCR은 사실상 한계 정확도에 가까워졌습니다. 그러나 한국어처럼 한글이라는 음절 단위 문자, 한자, 영어 약어, 숫자가 빈번히 섞이는 언어는 여전히 도전적인 영역입니다. 한국어 OCR을 다룰 때 자주 부딪히는 어려움은 다음과 같습니다.

다행히 Apple Vision은 한국어 인식에 충분한 노력을 들였고, macOS 14 이후 한국어는 라이브 텍스트의 1급 지원 언어가 되었습니다. 다만 “지원한다”는 것이 “모든 자료에서 완벽하게 읽힌다”는 뜻은 아닙니다. 본 글에서는 한국어 사용자가 Mac에서 자주 마주치는 시나리오별로 라이브 텍스트로 충분한 경우와 다른 도구가 필요한 경우를 구체적으로 정리합니다.

macOS 라이브 텍스트의 한국어 지원 현황

Apple의 공식 지원 목록에 따르면 라이브 텍스트의 한국어 지원은 macOS 14 Sonoma부터 정식으로 추가되었습니다. macOS 13 Ventura 이하에서는 한국어 인식이 제공되지 않거나 안정적이지 않으므로 한국어 OCR을 본격적으로 사용하려면 Sonoma 이상을 권장합니다.

Apple Vision의 가장 실용적인 특징 중 하나는 사용자가 언어를 미리 지정할 필요가 없다는 점입니다. 한 단락에 한글, 영어 약어, 숫자가 섞여 있어도 자동으로 구분해 한 번의 인식으로 처리합니다. 회사 슬랙에 공유된 “이번 주 OKR 회의는 14:00에 진행합니다. 자료는 Notion에서 확인 부탁드립니다.”와 같은 캡처도 영어 약어와 시간 표기까지 포함해 자연스럽게 추출됩니다.

기본 사용 방법은 다음과 같습니다.

라이브 텍스트로 부족한 부분

라이브 텍스트는 Apple 기본 앱 안에서 가장 자연스럽게 동작합니다. 한국 사용자의 일상 작업이 카카오톡·네이버·웹툰·웹사이트·외부 PDF 뷰어에서 일어난다는 점을 생각하면, 라이브 텍스트만으로 부족한 상황이 의외로 많습니다.

카카오톡, 슬랙, Notion 등 외부 앱 창

업무 슬랙에 올라온 회의 자료 캡처, 카카오톡으로 받은 긴 텍스트 스크린샷, Notion 페이지에 삽입된 이미지, Zoom 회의에서 공유된 슬라이드는 모두 라이브 텍스트의 직접 호출 범위에 들어가지 않습니다. 일단 스크린샷을 찍고, 사진이나 미리보기에서 다시 열고, 그 안에서 텍스트를 선택하는 절차가 필요합니다. 하루에 십여 번 반복하면 시간 손실이 명백히 누적됩니다.

전역 단축키 OCR 도구가 가장 실질적인 차이를 만드는 지점이 바로 여기입니다. 카카오톡 창 위에서 ⇧⌘E를 누르고 사각형 영역을 끌면 인식 결과가 바로 클립보드에 들어갑니다. 별도 저장과 재오픈이 필요 없습니다.

다단 스캔 PDF와 학술 자료

한국어 학술지, 정부 백서, 연구 보고서, 의학 논문은 2단·3단 편집의 PDF가 일반적입니다. 본문 레이어가 들어 있는 네이티브 PDF는 OCR 자체가 불필요하며 복사로 해결됩니다. 그러나 복합기로 스캔된 PDF는 텍스트가 이미지로만 존재하므로 OCR이 필요합니다. 라이브 텍스트는 페이지를 이미지 순서대로 읽기 때문에 다단 편집에서는 “왼쪽 단 1행 → 오른쪽 단 1행 → 왼쪽 단 2행 …” 식으로 읽기 순서가 흐트러집니다.

실용적인 해결책은 페이지 전체가 아니라 단 단위로 영역을 지정해 OCR을 수행하는 것입니다. Cheese! OCR처럼 사각형 드래그 방식의 도구는 이러한 단별 캡처에 적합하며, 결과를 메모에 붙여 넣으면 본래 단 흐름이 유지된 텍스트를 얻을 수 있습니다.

웹툰의 효과음과 손글씨체

웹툰은 한국어 OCR에서 가장 까다로운 콘텐츠 중 하나입니다. 표준 폰트로 식자된 말풍선 대사는 무리 없이 인식됩니다. 그러나 다음 요소는 정확도가 떨어집니다.

웹툰을 번역하거나 학습 자료로 쓰기 위해 대사만 추출하는 용도라면 라이브 텍스트와 Cheese! OCR 모두 충분히 실용적입니다. 효과음까지 완전히 옮겨야 하는 경우라면 사람이 보완하는 단계를 전제로 두는 편이 안전합니다.

옛 활자, 사료, 한자 혼용 학술 자료

현대 한국어 자료가 아닌 영역은 정확도가 더 큰 폭으로 떨어집니다. 일제강점기 신문, 1950–1970년대 활자, 한자 혼용이 빈번한 옛 학술지, 손으로 쓴 고문서는 현대 인쇄체 위주로 학습된 모델의 분포에서 벗어납니다. 라이브 텍스트도 Cheese! OCR도 이런 자료에서는 초고 수준의 결과만을 낸다고 보아야 하며, 본격적인 디지털화 작업은 한국학중앙연구원, 국사편찬위원회, 국립중앙도서관 등에서 제공하는 전용 OCR 파이프라인에 맡기는 것이 합리적입니다.

업무 문서 스캔과 사내 자료

견적서, 계약서, 회의록, 사내 매뉴얼의 스캔본 등은 한국 직장인이 가장 자주 OCR하는 자료입니다. 라이브 텍스트로도 인식 자체는 가능하지만, 대상이 보통 업무 앱 안에 있기 때문에 단축키 호출 방식이 절차상 한 단계 짧습니다. Cheese! OCR의 검색 가능한 기록 기능은 과거에 추출했던 견적서 번호나 품목 코드를 다시 찾을 때 특히 유용합니다.

Cheese! OCR을 활용하는 방법

먼저 분명히 말씀드리면, Cheese! OCR은 Apple Vision을 호출하는 도구이므로 같은 이미지에 대한 인식 정확도는 라이브 텍스트와 동일합니다. 별도의 OCR 모델을 따로 운영하지 않으며, 정확도 면에서 더 나아지는 점은 없습니다. 차이는 호출 방식, 다국어 기본값, 기록 관리, 프라이버시 보장 방식에 있습니다.

구체적인 차이는 다음과 같습니다.

실제 시나리오별 활용 팁

카카오톡 스크린샷 처리

한국 사용자가 가장 자주 받는 OCR 대상이 카카오톡 스크린샷입니다. 친구나 동료가 긴 정보를 한 장의 스크린샷으로 보내 주는 경우가 흔하기 때문입니다. 처리 흐름은 단순합니다. 카카오톡 창 위에서 ⇧⌘E를 누르고 메시지 영역을 사각형으로 끌면 텍스트가 클립보드에 들어옵니다. 그대로 메모, 노션, 번역기, 검색창에 붙여 넣으면 됩니다. 메시지 시간과 보낸 사람 이름은 보통 OCR에서 제외하면 본문 중심으로 깔끔하게 추출됩니다.

한국어 PDF—네이티브와 스캔 구분이 우선

학술 자료, 회사 보고서, 정부 보고서를 처리할 때 가장 먼저 할 일은 PDF가 네이티브인지 스캔인지를 확인하는 것입니다. 미리보기에서 Cmd+A로 텍스트가 선택되면 네이티브 PDF이며, 이때는 OCR이 필요 없고 복사로 해결됩니다. 선택이 되지 않거나 글자가 깨진 형태로 잡힌다면 스캔 PDF이므로 OCR 절차가 필요합니다. 다단 편집은 단별로, 표는 행별로 영역을 지정해 추출하면 후처리 부담이 크게 줄어듭니다.

웹툰 대사 추출

네이버 웹툰, 카카오 페이지, 레진 등 웹툰 뷰어에서 대사를 텍스트로 옮길 때는 컷 단위로 말풍선만 영역 지정하는 방식이 안정적입니다. 페이지 전체를 한 번에 OCR하면 효과음과 배경 글자가 섞여 들어와 순서가 흐트러집니다. 학습용으로 쓰거나 번역 초안을 만드는 정도라면 충분히 실용적이지만, 효과음까지 완전히 추출하려면 사람의 손이 필요합니다.

한자 혼용 학술 자료

한국어 본문 안에 한자가 섞여 있는 경우 Apple Vision은 한자를 중국어 문자로 인식해 결과 텍스트에 그대로 출력합니다. 인식 자체는 정확하지만 글자별 분류 라벨이 “중국어”로 표기되는 점만 인지하면 됩니다. 결과를 사용하는 입장에서는 차이가 거의 없습니다. 다만 한자가 변형 자체이거나 옛 활자체인 경우 정확도가 떨어지므로, 1990년대 이후 출판물 정도까지는 실용적이라고 보면 됩니다.

강의 슬라이드와 영상 캡처

온라인 강의, 유튜브 한국어 강좌, 회의 녹화 영상에서 한국어 텍스트가 포함된 슬라이드를 추출할 일이 잦습니다. 영상에서는 일시정지 후 단축키로 OCR하는 방식이 가장 효율적입니다. Zoom처럼 DRM이 적용된 회의 화면은 일반 스크린샷이 막힐 수 있는데, 이런 경우에도 화면 캡처를 OS 차원에서 허용하는 환경이라면 OCR이 가능합니다. 사내 보안 정책이 화면 캡처를 차단한다면 이는 OCR 도구의 한계가 아니라 정책의 결과이므로 사전에 확인이 필요합니다.

결론—언제 어떤 도구를 쓸지

한국어 사용자가 Mac에서 매일 마주치는 OCR 시나리오—카카오톡 스크린샷, 슬랙 자료, 학술 PDF, 웹툰 대사, 회의 슬라이드—는 대부분 위 두 도구의 조합으로 충분히 해결됩니다. 라이브 텍스트가 한국어 인식의 토대를 안정적으로 마련해 둔 덕분에, 남은 과제는 “어떻게 더 짧은 동작으로 호출할지”라는 워크플로우 설계의 문제로 좁혀집니다.