스크린샷 데이터 추출
되는 것과 안 되는 것

압축이 문자 단위에서 텍스트를 망치는 이유

동일한 내용의 200KB JPEG 스크린샷이 1.2MB PNG보다 추출 결과가 나쁜 이유는 파일 크기 때문이 아닙니다. 압축 과정에서 어떤 정보가 살아남는지에 달려 있습니다.

ISO/IEC 10918 표준으로 정의된 JPEG 압축은 이미지를 8×8 픽셀 블록으로 나누고, 각 블록에 이산 코사인 변환(DCT)을 적용하여 주파수 계수로 변환한 후, 해당 계수를 양자화(더 적은 값으로 반올림)합니다. 압축률이 높을수록 반올림이 더 과격해집니다. 버려지는 주파수는 인간의 시각 시스템이 자연 사진에서 덜 민감하게 반응하는 것들입니다. 하지만 텍스트는 자연 사진이 아닙니다. 문자는 고대비, 고주파 경계선이며, JPEG의 양자화 단계에서 바로 그 경계선의 선명도가 사라집니다.

텍스트 추출에 영향을 미치는 세 가지 특정 아티팩트는 다음과 같습니다.

• 블록화 아티팩트 — 각 8×8 블록이 독립적으로 처리되므로 인접 블록의 경계에서 평균값이 눈에 띄게 달라질 수 있습니다. 문자가 블록 경계에 걸쳐 있으면 양쪽 세그먼트가 더 이상 연결되지 않을 수 있습니다. 소문자 "l"이 두 블록에 나뉘어 있으면 두 개의 분리된 표시가 되거나, "B"의 왼쪽 세로 획이 완전히 사라질 수 있습니다.
• 후광/링잉 — 문자 윤곽선과 같은 날카로운 가장자리 주변에서 DCT 근사는 진동을 생성합니다. 즉, 잘못된 색상의 희미한 유령 같은 픽셀 고리입니다. "E" 주변에서 이러한 후광은 세로 획과 위쪽 가로 막대 사이의 간격을 채워 추출 출력에서 "F"로 바꿀 수 있습니다. 품질 설정이 낮을수록 위험이 연쇄적으로 발생합니다: E → F → C → 오독.
• 크로마 노이즈 — JPEG는 일반적으로 휘도보다 색상 채널에 더 강한 압축을 적용합니다. 색상 배경의 컬러 텍스트(어두운 모드 UI의 파란색 라벨 생각)는 문자 가장자리 주변에 색상 노이즈를 축적하여 인식을 더욱 혼란스럽게 만듭니다.

반면 PNG는 ISO/IEC 15948:2004에 정의된 deflate 압축 알고리즘을 사용합니다. 이는 무손실 방식으로 모든 픽셀을 캡처된 그대로 정확하게 보존합니다. 블록 경계, 후광, 크로마 서브샘플링 아티팩트가 없습니다.

이러한 품질 문제가 다양한 추출 시도에서 어떻게 나타나는지 더 자세히 알아보려면, 일반적인 스크린샷 추출 실수 가이드를 참조하세요. 이 글의 자매 기사로, 실패 패턴을 정리해 놓았습니다.

캡처 전에 제어할 수 있는 세 가지

스크린샷 추출 정확도를 높이려면 캡처 단축키를 누르기 전부터 준비해야 합니다. 가장 효과적인 세 가지 조정은 기술 지식이 전혀 없어도 가능합니다.

1. 형식: 항상 PNG

Windows에서는 캡처 도구를 열고 설정으로 이동한 후 "캡처 저장 형식"을 PNG로 전환하세요. macOS에서는 터미널에서 defaults write com.apple.screencapture type png를 실행하세요. iOS와 Android에서는 스크린샷이 기본적으로 PNG로 저장되니 변경하지 마세요. 파일 크기는 JPEG보다 크겠지만, 모든 바이트가 추출 엔진이 의존하는 문자 가장자리 데이터를 보존합니다.

표준 화면 디스플레이 해상도는 약 72~96 DPI로, 일반적으로 문서 OCR에 권장되는 최소 300 DPI에 훨씬 못 미칩니다. 화면의 픽셀 밀도를 변경할 수는 없지만, 어떤 픽셀이 중요한지는 제어할 수 있습니다.

2. 확대: 캡처 전에 먼저 확대하세요

텍스트가 더 많은 화면 픽셀을 차지할수록 각 문자가 추출 엔진에 더 많은 픽셀 데이터를 제공합니다. 표를 캡처하기 전에 브라우저나 앱을 150%로 확대하세요. 은행 명세서 스크린샷을 확대하면 개별 숫자가 획당 2~3개의 흐릿한 픽셀이 아닌 선명한 가장자리를 갖게 됩니다. 이 한 가지 단계만으로도 추출 도구를 바꾸는 것보다 더 큰 정확도 향상을 얻을 수 있습니다.

300 DPI로 스캔된 문서는 OCR 엔진에 선형 인치당 약 300개의 샘플 포인트를 제공합니다. 기본 확대 상태에서 96 DPI의 스크린샷은 그 약 1/3만 제공합니다. 확대하면 화면의 사용 가능한 픽셀을 실제로 필요한 텍스트에 더 많이 할당하여 불리함을 줄입니다.

3. 자르기: 노이즈 제거

필요한 데이터 테이블 하나가 포함된 전체 ERP 대시보드의 스크린샷은 추출 엔진에 약 80%의 노이즈(탐색 모음, 필터 드롭다운, 알림 배지, 광고 배너, 상태 표시기)를 전송합니다. 모든 UI 요소는 잠재적인 오탐지입니다. "제출"이라고 표시된 버튼이 데이터 필드로 읽히거나 아이콘이 잘못된 문자로 해석될 수 있습니다.

업로드 전에 데이터 영역으로 자르세요. 추출 도구가 선택적 필드 추출을 지원하는 경우 이 단계는 덜 중요하지만, 처리 시간을 줄이고 엔진이 관련 없는 UI 텍스트에서 잘못된 일치 항목을 찾을 위험을 제거합니다. 저해상도 스크린샷에서는 제거하는 모든 노이즈 픽셀이 방지하는 혼란의 픽셀입니다.

스크린샷이 이미 존재하는 경우 — 실용적인 복구

실무에서 가장 흔한 시나리오는 대부분의 가이드가 완전히 생략하는 바로 그 경우입니다. 스크린샷이 이미 저하된 상태로 도착했고, 원본 페이지, 앱 또는 대화가 사라진 경우입니다.

WhatsApp, WeChat, Slack 등 메신저로 전달된 스크린샷은 이미 한 차례 강력한 압축을 거쳤습니다. 이메일 본문에 삽입된 스크린샷은 이메일 클라이언트가 재인코딩했을 수 있습니다. 공유 드라이브에서 다운로드한 스크린샷은 원본 전송자가 JPEG로 저장했을 가능성이 있습니다. 어떤 경우든 원본 픽셀 데이터는 사라집니다.

다시 저장하지 마세요. 이 단계에서 가장 흔한 실수는 스크린샷을 열고 빠르게 자른 후 JPEG로 다시 저장하는 것입니다. JPEG를 다시 저장할 때마다 기존 블록 아티팩트 위에 새로운 8×8 블록 아티팩트가 생기며, 연속 저장 시 블록 격자가 정렬되지 않을 수 있습니다(1픽셀만 잘라도 전체 격자가 어긋납니다). 품질 80으로 5~10회 재저장하면 열화가 눈에 띄고, 20~30회 반복하면 압축 아티팩트 연구에서 보고된 대로 이미지가 "젖빛 유리를 통해 찍은 듯" 보입니다. 편집이 필요하다면 PNG로 저장하세요.

스크린샷이 메신저에서 온 것이고 발신자가 원본에 접근할 수 있다면, 이메일 첨부 파일이나 클라우드 저장소 링크로 파일 공유를 요청하세요. 메신저는 일반적인 파이프라인 중 가장 강력한 압축을 적용합니다. Google Drive나 OneDrive를 통해 공유된 동일한 콘텐츠는 일반적으로 원본 PNG 충실도를 유지한 채 도착합니다.

재캡처가 정말 불가능하고 스크린샷이 이미 열화된 경우, 다음 전략은 전체 페이지 OCR 엔진에 통과시키는 것이 아니라 추출 도구가 찾도록 요청하는 대상을 변경하는 것입니다.

스크린샷에서 전체 페이지 OCR보다 부분 추출이 더 나은 이유

스크린샷에 UI 크롬, 압축된 텍스트, 다양한 시각적 요소가 섞여 있을 때, 페이지의 모든 단어를 인식하려는 것은 비효율적인 전략입니다. 모든 단어가 필요한 것이 아니라, 5~10개의 특정 데이터 포인트가 필요합니다. 사용하는 도구는 이러한 현실에 맞아야 합니다.

페이지의 모든 문자를 왼쪽에서 오른쪽으로 인식하려는 기존 OCR 도구와 달리, ImageToTable.ai는 열 이름 추출 방식을 사용합니다. "송장 번호", "마감일", "총 금액" 등 원하는 필드를 입력하면, AI가 픽셀을 한 줄씩 읽는 대신 의미를 이해하여 이미지에서 해당 값을 찾습니다. 입력한 열 이름은 출력 스프레드시트의 헤더가 됩니다. 이는 각 필드 주변에 경계 상자를 그려야 하는 템플릿 기반 도구나 모든 내용을 구분 없는 텍스트 블록으로 덤프하는 OCR 엔진과 근본적으로 다릅니다.

이 기능의 핵심에는 비주얼 대규모 모델(VLM)이 있습니다. 이 AI는 사람처럼 문서 이미지의 내용과 레이아웃을 이해하도록 훈련되어, 픽셀 패턴을 문자 템플릿과 매칭하는 대신 의미론적 역할로 필드를 인식합니다. 기존 OCR이 픽셀 그리드를 보고 각 영역을 문자에 매핑하려는 반면, VLM은 문서를 인식합니다. "Invoice #" 옆의 숫자가 식별자임을, 오른쪽 하단 모서리에 통화 기호가 있는 값이 총계일 가능성이 높음을, DD/MM/YYYY 형식의 날짜가 날짜 열에 속함을 이해합니다.

열화된 스크린샷에서 이 점이 중요한 이유: 저작권 표시의 소문자 "l"이 "1"로 바뀌는 JPEG 아티팩트는, 엔진에 저작권 표시 추출을 요청하지 않았다면 무의미합니다. 열 이름 추출은 오류 가능성을 사용자가 관심 있는 필드로만 제한합니다. 엔진이 페이지의 모든 픽셀을 완벽히 해석할 필요는 없습니다. 노이즈 속에서 의미 있는 소수의 값을 찾아내면 됩니다. "합계" 필드 근처의 국부적 압축 아티팩트는 주변 맥락(위치, 통화 기호, 숫자 전용 형식)이 모델에 충분한 신호를 제공한다면 여전히 해독 가능할 수 있습니다.

단, 명확한 한계는 있습니다. 대상 필드의 텍스트가 진정으로 판독 불가능한 경우(약 6포인트 이하로 흐려짐, 여러 번의 압축으로 손상됨, 복잡한 배경 패턴 위에 겹쳐짐) 어떤 의미론적 모델도 존재하지 않는 데이터를 재구성할 수 없습니다. 이 경우 이전 섹션의 복구 단계를 참조하고 해당 필드를 수동 검토 항목으로 처리하십시오. 정확도는 도구가 할 수 있는 것을 극대화하는 것이지, 한계가 없는 척하는 것이 아닙니다.

특정 데이터 포인트에 대한 선택적 추출을 설정하는 전체 과정은 스크린샷에서 특정 데이터 필드 추출 가이드를 참조하십시오.

정확도 수치의 실제 의미 — 유용한 기대치 설정하기

"99% 정확도"를 주장하는 업체는 인쇄된 텍스트에 대한 이야기일 뿐, 여러분이 찍은 뱅킹 앱 대시보드의 WhatsApp 압축 스크린샷에서는 어떤 일이 벌어질지 알려주지 않습니다. 진짜 중요한 숫자는 실제 입력 데이터에 대한 필드 수준 정확도입니다.

OCR 정확도를 보고하는 업계 표준은 문자 수준입니다. 즉, 개별 문자 중 올바르게 인식된 비율이죠. 문자 수준 정확도 99%는 100자당 1개의 오류를 의미합니다. 10자리 송장 번호에서 한 자리가 틀리면 문자 수준에서는 90% 정확도지만, 데이터 포인트로서는 0% 쓸모가 없습니다. 잘못된 번호로 송장을 등록할 수는 없으니까요. 필드 수준 정확도 — 요청한 필드 중 완전히 올바르게 반환된 비율 — 가 추출 워크플로우가 실제로 사용 가능한지 판단하는 지표입니다.

표준 글꼴과 명암비가 좋은 깨끗한 고해상도 PNG 스크린샷에서는 최신 시각적 대규모 모델 추출이 날짜, 금액, 식별자처럼 명확히 정의된 필드에 대해 필드 수준 정확도 95~99%에 근접할 수 있습니다. 하지만 작은 글꼴과 혼합 배경색이 있는 조밀한 표의 압축된 JPEG 스크린샷에서는 필드 수준 정확도가 낮아집니다. 이때 책임 있는 답변은 완전 자동 통과가 아닌 수동 점검을 예상하는 것입니다. 95%의 필드가 정확하고 5%가 검토 대상으로 표시되는 프로세스는 실패가 아니라 모든 것을 수동으로 옮겨 적는 것보다 여전히 약 20배의 시간을 절약해 줍니다.

이것이 바로 범용 AI 채팅 도구가 스크린샷 추출에 적합하지 않은 이유이기도 합니다. ChatGPT와 Claude는 스크린샷에서 텍스트를 읽을 수 있습니다. 멀티모달 기능은 실제로 작동하지만, 자연 장면 이해와 대화형 응답 생성에 최적화되어 있습니다. 구조화된 필드 검증 계층이 없습니다. 인식된 값이 실제로 날짜인지 확인하는 메커니즘이 없고, 배치 50개 스크린샷에 걸쳐 출력 스키마를 강제할 방법이 없으며, 스프레드시트 형식으로의 열 수준 매핑도 없습니다. 자세한 비교는 ChatGPT와 Claude가 스크린샷 데이터 추출에 최선의 선택이 아닌 이유를 참조하세요.

정확도 기준을 "첫 번째 패스에서 완벽"이 아닌 "검토와 함께 사용 가능"으로 설정하세요. WhatsApp에 도착하는 스크린샷은 이미 품질이 저하된 상태입니다. 얼마나 복구할 수 있는지는 형식, 크기 조정, 자르기, 그리고 모든 단어를 읽도록 요청하는지 아니면 필요한 5개 필드만 읽도록 요청하는지에 따라 달라집니다.

자주 묻는 질문

스크린샷 추출에서 PNG가 JPG보다 정말 그렇게 큰 차이를 만드나요?

네, 그 차이는 저해상도 스크린샷에서 더 두드러집니다. 품질 80으로 저장된 JPG는 이미 원본 픽셀 데이터의 약 10~15%를 버렸습니다. 10포인트 텍스트의 96 DPI 스크린샷에서 버려진 데이터에는 추출 엔진이 "8"과 "B" 또는 "5"와 "S"를 구분하는 데 필요한 문자 가장자리 세부 정보가 포함됩니다. PNG는 이미 제한된 해상도의 모든 픽셀을 보존합니다. 실제 테스트는 간단합니다. 동일한 스크린샷을 두 번 찍어 하나는 JPG로, 다른 하나는 PNG로 저장한 후 둘 다 추출을 실행하고 필드 수준 결과를 비교하세요.

추출을 실행하기 전에 이미 압축된 스크린샷을 개선할 수 있나요?

손실을 더 악화시키는 것은 피할 수 있지만, 손실 압축이 제거한 데이터를 복구할 수는 없습니다. JPG 스크린샷을 열어 PNG로 저장해도 손실된 픽셀 정보가 복원되지 않으며, 이후 편집 시 추가적인 품질 저하를 막을 뿐입니다. AI 업스케일링 도구도 마찬가지입니다. 사람 눈에 더 선명해 보이도록 보간된 픽셀을 추가할 수는 있지만, 이는 합성 데이터를 생성하는 것이지 원래 문자 형태를 복원하는 것이 아닙니다. 압축으로 인해 필드가 실제로 모호해진 경우, 업스케일링이 잘못된 해석에 확신을 더할 수도 있습니다.

안정적인 추출을 위해 스크린샷은 어떤 해상도가 필요한가요?

스크린샷은 전통적인 의미의 DPI 설정이 없으며, 현재 표시되는 픽셀을 그대로 캡처합니다. 유효 해상도는 화면의 픽셀 밀도와 텍스트가 화면에 표시되는 크기에 따라 달라집니다. 1920×1080 해상도의 13인치 노트북은 인치당 약 141픽셀을 표시하지만, 보이는 텍스트는 물리적 문서에서 캡처된 것이 아니라 OS에서 렌더링된 것입니다. 실용적인 기준은 다음과 같습니다. 화면에서 텍스트를 눈을 찡그리지 않고 편안하게 읽을 수 있고, 기본 확대율 이상으로 PNG로 캡처했다면 추출이 가능해야 합니다. 숫자를 읽기 위해 직접 200%로 확대해야 한다면, 추출 엔진도 같은 어려움에 직면하게 됩니다.

기존 OCR 도구가 읽을 수 없는 스크린샷에서도 비주얼 대형 모델이 데이터를 추출할 수 있나요?

종종 그렇습니다. 하지만 VLM이 더 선명한 픽셀을 보기 때문은 아닙니다. 동일한 픽셀을 보지만 다르게 해석합니다. 기존 OCR 엔진은 통계 모델을 사용하여 픽셀 패턴을 개별 문자에 매핑합니다. VLM은 이미지를 전체적으로 읽습니다. 흐릿한 덩어리가 달러 기호 옆에 있으면 금액일 가능성이 높고, 슬래시나 대시로 구분된 숫자 문자열은 날짜일 가능성이 높으며, "계좌명" 아래의 값은 일부 문자가 모호하더라도 텍스트임을 이해합니다. 이러한 의미론적 맥락을 통해 VLM은 문자 단위 OCR 엔진이 오류로 남길 공백을 채울 수 있습니다. 하지만 모델이 초능력자는 아닙니다. 압축이나 흐림으로 대상 값이 완전히 지워지면 출력은 틀릴 것입니다. 장점은 기적을 행하는 것이 아니라 부분적인 손상을 탐색하는 데 있습니다.

저품질 스크린샷에서 몇 개의 필드를 추출해야 하나요?

워크플로에 중요한 5~10개 필드부터 시작하세요. 해당 필드가 깔끔하게 나오면 더 추가할 수 있습니다. 5개 필드조차 일관성이 없다면 스크린샷 품질이 실행 가능한 임계값 아래일 가능성이 높으므로 다시 시도하기 전에 원본(형식, 크기 조정 또는 재캡처)을 해결해야 합니다. "일단 모두 추출하고 나중에 정리하자"는 본능은 품질이 낮은 입력에서는 역효과를 냅니다. 출력을 노이즈로 가득 채우고 검증을 더 느리게 만들 뿐입니다.

실제로 작동하는 스크린샷 추출 워크플로는 다음과 같습니다: 편안한 확대/축소 비율로 PNG로 캡처하고, 데이터 영역을 자르고, 필요한 필드만 지정한 후, 완벽한 결과를 신뢰하기보다는 저품질 입력에 대해 결과를 점검할 준비를 하는 것입니다. 직접 테스트해 보세요. 동일한 데이터 테이블을 PNG와 JPG로 각각 캡처하여 추출을 실행한 후 차이를 비교해 보세요. 그런 다음 전체 페이지를 요청하는 대신 5개의 특정 필드를 추출해 보세요. 이 두 접근 방식의 차이는 미미한 수준이 아닙니다. 신뢰할 수 있는 워크플로와 수정하는 데 시간을 더 많이 소비하게 되는 워크플로의 차이입니다.

스크린샷을 Excel로 변환하는 초보자용 단계별 가이드는 스크린샷에서 Excel로 데이터 가져오기 가이드를 참조하세요. 업종별 추출 템플릿은 스크린샷을 Excel로 변환 도구 페이지에서 확인하세요.