OCR이 오류 대신 틀린 단어를 돌려주는 이유

문자 인식은 실패했다고 거의 말하지 않습니다. 중요한 한 글자만 틀린 문장을 그대로 돌려주죠. 어디서 일어나는지, 어떻게 잡아내는지 정리했습니다.
스크린샷에서 텍스트를 복사하는 일은 대개 잘 되고, 그게 문제입니다. 실패할 때도 요란하게 실패하지 않습니다. 빨간 밑줄도, "텍스트를 인식할 수 없습니다"도, 빈 상자도 없습니다. 완벽하게 읽히는 문장이 나옵니다. 다만 한 글자가 틀렸고, 그 글자가 의미를 바꿉니다.
그래서 사람들은 한 자리 틀린 주문 번호를, 글자 하나 틀린 설정 키를, 원래 없던 글자가 섞인 문장을 붙여 넣게 됩니다. 인식이 망가진 게 아닙니다. 자신 있게 추측한 것입니다.
인식은 분류기이지 파서가 아닙니다
엔진이 실제로 무엇을 하는지 알면 도움이 됩니다. 문자 인식은 이미지를 줄로 나눈 뒤 글자 모양 영역으로 나누고, 각 영역을 분류기에 통과시켜 가장 가능성 높은 글자를 받습니다. 그 분류기는 "모르겠다"고 절대 말하지 않습니다. 언제나 찾을 수 있는 가장 가까운 답을 돌려줍니다.
입력 품질이 좋으면 그 가장 가까운 답은 거의 어디서나 맞습니다. 품질이 나쁘면 가장 가까운 답이 우연히 비슷하게 생긴 다른 글자입니다. o일 수도 있는 a, l일 수도 있는 1, 구성 요소를 공유해 얼핏 이웃 글자로 오인하기 쉬운 한자 같은 것들이죠. 엔진은 자신이 틀렸다는 사실을 모릅니다.
입력을 "나쁘게" 만드는 것
대략 이 순서로 네 가지가 중요합니다.
- 픽셀 단위 텍스트 높이. 작은 텍스트는 분류할 픽셀이 더 적습니다. 이게 가장 큰 요인입니다.
- 문자 집합. 중국어, 일본어, 한국어 글자는 밀도가 높아 몇 픽셀을 잃는 것만으로 모양과 정체성이 모두 바뀝니다. 라틴 문자는 더 단순해서 더 오래 버팁니다.
- 안티앨리어싱과 크기 조정. 크기를 조정할 때마다 모든 획의 가장자리가 섞입니다. 한 번은 괜찮습니다. 세 번 쌓이면 모양을 잃습니다.
- 대비와 배경. 흰 바탕의 회색 글자와 어두운 바탕의 밝은 글자 모두 가장자리 세기를 떨어뜨립니다. 텍스트 뒤의 그라디언트와 사진도 마찬가지입니다.
실패 보고의 대부분은 첫 번째에서 오고, 해결책은 보통 더 애쓰는 게 아니라 픽셀을 더 캡처하는 것입니다.
InSnap에는 별도의 정확도 설정이 없습니다. 선택한 픽셀에서 작동합니다. 밀도 높은 UI의 1x 스크린샷은 각 줄이 화면이 그린 높이 그대로이고, 2x Retina 캡처는 그 두 배입니다. 특정 문단에서 이 둘의 차이는 종종 "맞음"과 "그럴듯하지만 틀림"의 차이입니다.

실질적인 경계선
짐작하지 않고 경계를 보려면 작고 반복 가능한 테스트를 만들어 보는 게 좋습니다. 같은 문장을 여러 텍스트 높이로 렌더링하고 각각 인식을 돌린 뒤 출력과 입력을 글자 단위로 비교하는 겁니다. 아래 두 이미지가 정확히 그렇게 한 것입니다. 꾸며 낸 예시가 아니라 로컬 엔진의 실제 출력을 썼습니다.
중국어 줄과 영어 줄을 다섯 가지 높이로 렌더링하고 매번 새로 인식했습니다. 원본과 다른 글자는 빨간색으로 표시했습니다.

여기서 두 가지가 나옵니다. 첫째, 그 줄은 맞다가 갑자기 틀립니다. 점진적 저하가 없고, 특정 크기 아래로 내려가면 틀린 글자가 나타납니다. 둘째, 두 문자 체계가 서로 다른 지점에서 무너집니다. 여기서는 라틴 텍스트가 먼저 흔들렸고 중국어는 더 오래 버텼습니다. "중국어가 더 어렵다"는 대부분의 통념과 반대입니다.
같은 문장을 더 작은 크기로 인식하면 출력은 다른 종류의 틀로 바뀝니다. 비어 있지도, 횡설수설하지도 않습니다. 실제 단어이되 틀린 글자가 섞인 진짜 문장입니다.

두 번째 이미지가 유용한 쪽입니다. 틀린 결과가 실제로 어떻게 생겼는지 보여 주니까요. 눈에 띌 만큼 뻔하지도, 무시할 만큼 미묘하지도 않습니다.
문서에 들어가기 전에 잡아내는 방법
인식은 자신이 불확실하다고 말해 주지 못하므로, 틀린 글자가 비싼 곳에서는 직접 확인해야 합니다.
- 숫자나 식별자가 있는 것은 모두 확인하세요. 주문 ID, 라이선스 키, 버전 문자열, 인보이스 합계 등입니다. 한 자리 틀린 숫자는 문맥 속에서는 보이지 않고 하위 단계에서 치명적입니다.
- 길이를 확인하세요. 두 글자 식별자가 세 글자로 돌아오거나 그 반대라면 뭔가 잘못됐다는 확실한 신호입니다.
- 특이한 글자를 확인하세요. 파이프, 공백, 줄바꿈 없는 공백, 키릴 문자와 라틴 문자의 혼동 등입니다. 코드라면 고정폭 뷰에 붙여 넣으면 바로 드러납니다.
- 가장자리를 확인하세요. 줄의 처음이나 끝 글자는 탐지 중 가장 먼저 잘립니다. 줄이 갑자기 끝나면 마지막 한두 글자를 보세요.
- 더 큰 크기로 다시 캡처하세요. 업스케일하지 마세요. 흐릿한 줄을 업스케일해도 디테일이 생기지 않고, 틀린 글자를 고치는 경우도 드뭅니다. 같은 영역을 2x로 다시 캡처하거나, 캡처 전에 원본을 확대하세요.
실용적인 따름정리로, 좋은 해상도에서 넓게 선택한 스크린샷이 빡빡하게 자른 작은 스크린샷보다 인식이 쉽습니다. 자르면 노이즈가 줄지만 정보도 줄고, 정보는 분류기가 먹는 것입니다.
무엇을 믿을 수 있을까
솔직한 요약입니다.
| 상황 | 보통 잘 됨 | 보통 안 됨 |
|---|---|---|
| 일반 UI 크기의 영어 및 라틴 문자 텍스트 | 예 | — |
| 일반 UI 크기의 중국어 | 예 | — |
| 대략 10 px 미만의 텍스트 | — | 아니요 |
| 일본어 가나, 한국어, 러시아어 | — | 아니요 |
| 사진이나 그라디언트 위의 텍스트 | 때때로 | 때때로 |
| 크게 크기 조정된 스크린샷 | — | 아니요 |
InSnap의 로컬 인식은 중국어, 영어, 라틴 문자 언어를 강세 부호까지 포함해 잘 처리합니다. 일본어 가나, 한국어, 러시아어는 신뢰할 수 없습니다. 이는 번들 모델의 특성이지 설정이 아니므로, 그런 문자 체계라면 복사한 내용을 반드시 확인하는 것이 정직한 태도입니다.
자주 묻는 질문
문자 인식기는 불확실할 때 알려 주나요?
아니요. 글자 분류기는 언제나 최선의 추측을 돌려주고, 인터페이스에는 복사용 신뢰도 표시가 따로 없습니다. 돌려준 글자는 보장된 정답이 아니라 가장 가능성 높은 답이라고 가정하는 것이 안전합니다.
다시 실행하면 틀린 글자를 고칠 수 있나요?
보통은 아닙니다. 입력이 바뀌지 않았고, 모델은 같은 픽셀에 대해 결정적이기 때문입니다. 고치는 방법은 입력을 바꾸는 것입니다. 같은 영역을 더 큰 크기로 다시 캡처하거나, 캡처 전에 원본을 확대한 뒤 다시 인식하세요.
같은 페이지인데 어떤 스크린샷은 되고 어떤 것은 안 되는 이유는 무엇인가요?
대개 픽셀 단위 텍스트 크기 때문입니다. 이는 디스플레이 배율과 캡처가 1x였는지 2x였는지에 달려 있습니다. 같은 페이지라도 확대 수준이 다르거나 다른 디스플레이에 있으면 크기 경계를 넘을 수 있습니다.
이미지와 사진 속 텍스트도 읽나요?
텍스트가 크고 단조로운 배경 위에서 선명할 때만 읽습니다. 사진, 그라디언트, 복잡한 일러스트 위의 텍스트는 틀린 글자가 가장 자주 나오는 곳입니다.
이 기능을 쓰려면 인터넷 연결이 필요한가요?
아니요. 인식은 복사 단계를 포함해 로컬에서 실행됩니다. 아무것도 업로드되지 않고, 오프라인에서도 정확도는 같습니다.
블로그의 다른 글

스크린샷 OCR 인식률 높이는 방법
텍스트 인식은 넣어 주는 픽셀만큼만 정확합니다. 타이트하게 자르고 해상도를 지키며 기울기와 복잡한 배경을 피하고, 언어 한계를 아는 요령을 정리했습니다.
2026년 10월 25일
스크린샷·이미지에서 텍스트 복사하는 방법 (Mac, Windows)
스크린샷 속 글자를 복사할 수 있는 텍스트로 바꾸는 방법. Mac과 Windows 기본 기능부터 InSnap의 빠른 온디바이스 OCR 워크플로까지 정리했습니다.
2026년 10월 23일
동영상에서 텍스트 복사하는 방법
자막, 슬라이드, 오류 메시지도 영상 안의 픽셀일 뿐입니다. 프레임을 멈추고 영역을 캡처해 OCR로 텍스트를 꺼내는 방법과 한계를 정리했습니다.
2026년 10월 25일
InSnap 업데이트 방식과 수동 확인 방법
자동 확인과 수동 메뉴 항목, Windows 설치 버전과 포터블 버전의 차이를 설명합니다. 업데이트가 유지하는 데이터와 실패했을 때의 대처법을 정리합니다.
2026년 10월 25일