앱 스크린샷 200장을
하나의 구조화된 스프레드시트로 만드는 방법

일대일 처리 방식이 대규모에서 무너지는 이유

스크린샷 하나를 처리하는 것은 간단합니다. 데이터를 보고 스프레드시트에 입력하면 됩니다. 스크린샷 5개는 5배의 시간이 걸립니다. 하지만 200개의 스크린샷은 5개나 10개일 때는 없던 비용을 발생시키며, 그 비용은 선형적으로 증가하지 않습니다.

IOFM의 AP 처리 비용 연구에 따르면 페이지당 수동 데이터 입력 기준인 스크린샷당 3분을 적용하면, 200개의 스크린샷은 순수 타이핑 시간만 10시간에 달합니다. 하지만 그 숫자는 단순히 입력하는 시간만을 반영합니다. 어떤 스크린샷에 어떤 레코드가 있는지 찾는 시간, 방금 입력한 행이 올바른 출처와 일치하는지 확인하는 시간, 또는 스크린샷 #47이 잘못된 폴더에 정리되어 있어 이미 43개 항목을 잘못된 열 순서로 입력했다는 사실을 깨닫고 되돌아가는 시간은 포함되지 않습니다.

이것이 단일 스크린샷 추출과 배치 처리의 차이점입니다. 전자는 타이핑 문제입니다. 후자는 타이핑을 수반하는 조직화 문제입니다. 실제 병목 현상은 손가락 속도가 아니라 각 스크린샷을 출력 행에 연결하고, 여러 출처의 결과를 하나의 일관된 표로 병합하며, 모든 행을 수동으로 감사하지 않고도 재확인이 필요한 항목을 알려주는 시스템의 부재입니다.

r/dataengineering의 한 Reddit 사용자가 각각 100개의 리드가 포함된 3,000개의 스크린샷을 Excel 파일로 추출하는 방법을 물었을 때, 답변은 속도에 관한 것이 아니었습니다. 파이프라인 아키텍처, 즉 ETL 도구, 오케스트레이션, 품질 검사에 관한 것이었습니다. 그 직감은 정확했습니다. 그 정도 볼륨에서는 더 이상 데이터를 복사하는 것이 아닙니다. 소스 형식이 PNG 파일인 데이터 통합 프로젝트를 관리하는 것입니다.

대부분의 스크린샷-스프레드시트 도구가 일괄 처리에 대해 알려주지 않는 것

단일 스크린샷을 Excel로 변환하는 문제는 이미 여러 번 해결되었습니다. Microsoft Excel의 '그림에서 데이터 가져오기' 기능은 표 형식의 스크린샷을 직접 셀로 읽어들입니다. ChatGPT와 Microsoft 365 Copilot은 이미지 업로드를 받아 요청 시 구조화된 데이터를 추출합니다. 하지만 이러한 각 솔루션은 대량 처리 시 한계를 드러내는 가정을 하고 있습니다.

Excel의 '그림에서 데이터 가져오기'는 스크린샷에 표가 포함되어 있다고 가정합니다. 즉, 눈금선, 열 경계, 행 구분선을 찾습니다. 단일 레코드 카드(고객 이름, 전화번호, 이메일, 마지막 예약 날짜가 표 격자가 아닌 레이블 필드로 표시된 앱 UI 스크린샷)를 보여주는 경우 아무것도 반환하지 않습니다. 이 도구는 이미지 형태의 스프레드시트를 위해 설계되었을 뿐, 앱 인터페이스에서 필드를 추출하도록 설계되지 않았습니다. 또한 한 번에 하나의 파일만 처리합니다. 이미지를 선택하고, 처리를 기다리고, 결과를 검토하고, 삽입합니다. 200번 반복하면 파일별 상호작용의 번거로움으로 인해 OCR이 절약해주는 시간이 대부분 사라집니다.

ChatGPT와 Copilot은 비표 스크린샷을 비교적 잘 처리합니다. 언어 모델이 필드 레이블을 해석할 수 있기 때문입니다. 하지만 일괄 처리 시 실질적인 장벽에 부딪힙니다. 파일 업로드 제한(ChatGPT 표준 인터페이스에서 한 번에 10개), 세션 간 일관되지 않은 출력 형식(세 번째 응답의 열 머리글이 일곱 번째 응답과 일치하지 않을 수 있음), 그리고 분할된 결과를 단일 출력 파일로 병합하는 내장 메커니즘이 없다는 점입니다. 600개의 스크린샷을 가진 한 Reddit 사용자는 이 경험을 정확히 설명했습니다: "ChatGPT에 한 번에 10개씩 이미지를 업로드하여 데이터를 추출합니다. 작동은 하지만 업로드 제한에 빠르게 도달하고 규모가 커질수록 시간이 많이 걸립니다."

일반 OCR 도구(Tesseract, ABBYY FineReader, UiPath Document OCR)는 이미지에서 텍스트를 추출하지만 구조화된 필드 수준의 출력을 생성하지 않습니다. 텍스트 블록만 얻을 수 있습니다. 해당 텍스트를 스프레드시트의 명명된 열로 변환하려면 별도의 구문 분석 단계가 필요하며, 특히 스크린샷 간 텍스트 레이아웃이 다른 경우 처음부터 직접 입력하는 것만큼 시간이 걸리는 경우가 많습니다.

세 가지 접근 방식 모두에서 누락된 부분은 동일합니다. "이것이 내가 원하는 열이다"라고 한 번만 말하면 해당 지시가 UI 레이아웃에 관계없이 모든 스크린샷에 적용되어, 실패하거나 모호한 결과는 조용히 병합되지 않고 플래그가 지정된 하나의 병합된 출력 파일을 생성하는 방법입니다.

수십 개의 스크린샷을 처리할 때만 신경 써야 할 세 가지

스크린샷을 하나씩 처리하면 배치 모드에서 피할 수 없는 세 가지 구조적 문제가 숨겨집니다. 이는 추출 정확도가 아니라 추출 주변에서 발생하는 문제입니다.

명명 및 추적 가능성 — 어떤 행이 어떤 스크린샷에서 왔는지 알기

스크린샷을 개별적으로 처리하고 데이터를 Excel에 입력할 때는 어떤 행이 어떤 출처에서 왔는지 머릿속에 맥락을 담고 있기 때문에 알 수 있습니다. 하지만 200개의 스크린샷이 되면 그 맥락이 사라집니다. 147번째 행의 주소가 잘못된 것 같다면, 200개의 소스 파일 중 어떤 파일을 열어 확인해야 할까요? 두 개의 스크린샷이 동일한 고객 레코드의 다른 뷰를 캡처했지만 필드 값이 약간 다른 경우(예: CRM의 연락처 카드와 결제 포털에서 각각 캡처한 경우) 어떤 것이 우선순위를 가져야 할까요?

해결책은 출력에 추적 가능성을 인코딩하는 명명 규칙입니다. 가장 간단한 방법: 추출 출력에 소스 파일 이름을 열로 포함시키는 것입니다. ImageToTable.ai의 사용자 정의 열 추출 — 원하는 열 이름을 입력하면 AI가 픽셀 위치가 아닌 의미를 이해하여 각 값을 찾습니다 — 배치 내보내기 시 자동으로 "소스 파일" 열을 포함하므로 병합된 스프레드시트의 모든 행이 원본 스크린샷에 대한 참조를 갖게 됩니다. 별도의 추적 시트나 수동 매핑이 필요 없습니다.

더 자세한 추적 가능성을 위해 메타데이터를 캡처하는 패턴으로 스크린샷 파일 이름을 지정하세요: 고객명_날짜_플랫폼 또는 직원ID_보고서유형. 이 파일 이름은 출력의 감사 추적의 일부가 되며 대량 확인을 추측 게임이 아닌 필터링 작업으로 만듭니다.

결과 병합 — 200개의 개별 추출에서 하나의 깔끔한 테이블로

200개의 스크린샷을 개별적으로 추출하면 200개의 개별 출력이 생성됩니다 — 200개의 CSV 파일, 200개의 스프레드시트 탭 또는 형식이 약간 다른 200개의 채팅 응답. 수동으로 병합하면 피하려고 했던 데이터 입력 부담이 다시 발생합니다.

진정한 배치 처리는 열 이름을 한 번 정의하고 — "고객명", "이메일", "전화번호", "등록일", "마지막 예약" — 200개의 스크린샷을 모두 함께 업로드하고 각 스크린샷이 동일한 테이블에 하나의 행을 기여하는 단일 병합 출력을 받는 것을 의미합니다. 열 정의는 계약 역할을 합니다: 모든 스크린샷이 동일한 필드 이름 세트에 대해 처리되므로 후처리 없이 출력이 일관됩니다. 이것이 열 이름 추출의 기본 접근 방식입니다: 입력한 필드 이름이 추출 명령과 병합된 출력의 열 헤더가 되므로 업로드와 내보내기 사이에 재매핑이 필요 없습니다.

이는 스크린샷이 다른 소스 애플리케이션에서 올 때 가장 중요합니다. 고객 이름은 CRM 스크린샷의 레이블이 지정된 필드, 결제 포털의 카드 레이아웃 상단, Slack을 통해 전달된 채팅 메시지에 나타납니다. 각 앱은 동일한 정보를 다른 시각적 위치에 배치합니다 — 하지만 AI가 "고객명"이 공간적 위치가 아닌 의미론적으로 무엇을 의미하는지 이해한다면 세 스크린샷 모두 올바른 값을 동일한 열에 매핑합니다.

예외 처리 — 스크린샷이 제대로 작동하지 않을 때 대처 방법

단일 스크린샷 규모에서는 추출 실패가 불편할 뿐입니다. 다시 시도하거나 수동으로 입력하면 됩니다. 그러나 200개의 스크린샷 규모에서는 5%의 실패율만으로도 10개 행의 데이터가 누락되거나 손상될 수 있으며, 이는 처리가 완료된 것으로 간주된 지 몇 주 후에 조정 과정에서 오류로 드러납니다.

일괄 추출 도구는 예외를 세 가지 기본 방식으로 처리합니다:

• 오류 시 중단: 하나의 파일이 실패하면 전체 배치를 중단합니다. 안전하지만 대량 처리에는 비현실적입니다. 5개의 불량 파일 때문에 195개의 성공적인 추출 결과를 잃게 됩니다.
• 무음 건너뛰기: 처리를 계속하고, 실패한 행은 알림 없이 생략합니다. 빠르지만 위험합니다. 200행 스프레드시트에서 10개의 누락된 행은 수동으로 개수를 교차 확인하지 않는 한 완전한 데이터처럼 보입니다.
• 건너뛰기 및 표시: 모든 파일을 처리하고, 신뢰도가 낮거나 실패한 필드는 검토를 위해 표시합니다. 이것이 확장 가능한 접근 방식입니다. 신뢰도 표시와 함께 전체 출력을 얻을 수 있으며, 검토 시간은 모든 행이 아닌 의심스러운 항목에만 집중됩니다.

이러한 모드 간의 효율성 차이는 상당합니다. 오류 시 중단 또는 무음 건너뛰기 방식에서는 배치 완전성을 확인하기 위해 수동으로 한 줄씩 감사해야 합니다. 표시 방식에서는 검토 단계가 표시된 행당 몇 초밖에 걸리지 않습니다. AI가 불확실하다고 표시한 필드를 확인하고 승인 또는 수정하기만 하면 되며, 행당 전체 필사 시간(몇 분)이 필요하지 않습니다. 당사의 추출 엔진 벤치마크인 99%의 인쇄 테이블 정확도에서 200개의 스크린샷 배치는 약 2개의 주의가 필요한 행을 생성합니다. 2개 행을 검토하는 것은 200개를 입력하는 것과는 다른 작업입니다.

스크린샷이 다섯 가지 앱에서 왔을 때

대부분의 일괄 추출 튜토리얼은 동일한 애플리케이션, 동일한 레이아웃, 동일한 데이터 필드를 보여주는 200개의 스크린샷이라는 균일한 출처를 가정합니다. 실제 일괄 작업 시나리오는 거의 그렇지 않습니다.

일반적인 주간 운영 보고서는 다음과 같은 스크린샷을 가져올 수 있습니다: 파이프라인 지표를 보여주는 Salesforce 대시보드, 주간 지원 티켓 볼륨을 나타내는 Tableau 그래프, 미결제 청구서 요약이 있는 QuickBooks, 지역 관리자가 2분기 선적 수치를 게시한 Slack 스레드, 직원 활용률을 보여주는 내부 포털 페이지. 다섯 가지 다른 앱, 다섯 가지 다른 UI 레이아웃, 데이터 표시를 위한 다섯 가지 다른 시각적 규칙. QuickBooks에서 "총 미납액"으로 표시된 개체는 내부 포털의 "미결제 잔액" 필드와 Slack에 "아직 우리에게 빚진" 텍스트 앞에 입력된 숫자와 의미상 동일합니다.

템플릿 기반 추출 도구는 여기서 작동하지 않습니다. 공간적 위치에 의존하기 때문입니다: Salesforce 스크린샷의 "금액" 필드 주위에 사각형을 그리고, 도구는 이후 모든 스크린샷에서 동일한 사각형을 찾습니다. 여기에는 해당 좌표가 그래프 축 레이블에 있는 Tableau 스크린샷도 포함됩니다. 이것이 좌표 기반 추출의 근본적인 한계입니다: 파일 간 레이아웃 일관성을 가정합니다.

열 이름 추출은 다르게 작동합니다. 도구에 데이터가 페이지의 어디에 있는지 알려주는 대신, 데이터가 무엇을 의미하는지 알려줍니다. "수익"이라는 열 이름을 정의하면 — AI는 Salesforce 카드의 왼쪽 상단, QuickBooks 테이블의 강조 표시된 셀, 또는 채팅 메시지에서 달러 기호 앞에 나타나든 관계없이 각 스크린샷에서 해당 개념과 연결된 값을 찾습니다. 이것이 교차 앱 일괄 처리를 가능하게 하는 메커니즘입니다: 추출 로직은 첫 번째로 처리한 스크린샷의 좌표가 아닌 데이터의 의미와 함께 이동합니다.

혼합 소스 배치의 경우 추론된 열이 두 번째 지능 계층을 추가합니다. 스크린샷에 있는 내용을 추출하는 것 외에도 "소스 플랫폼 (옵션: Salesforce / QuickBooks / Tableau / Slack / Portal)"과 같은 열을 정의할 수 있습니다. 그러면 AI는 시각적 특성을 분석하여 각 스크린샷이 어떤 플랫폼에서 왔는지 판단하고 값을 자동으로 채웁니다. 이렇게 하면 혼합 소스 스크린샷 더미가 수동 태깅 없이 분류되고 분석 준비가 된 테이블로 바뀝니다.

실제 200개 스크린샷 워크플로우는 이렇게 생겼습니다

배치 스크린샷을 처리하는 워크플로우는 다섯 단계로 구성되며, 그중 AI를 기다리는 단계는 단 하나뿐입니다. PNG 파일이 가득한 폴더에서 다음 회의에 제출할 수 있는 구조화된 스프레드시트까지의 전체 과정을 소개합니다.

지금까지 스크린샷을 하나씩 처리하거나, 10개씩 챗봇에 업로드한 후 결과를 수동으로 이어 붙였다면, 이 워크플로우는 단순한 속도 향상이 아닌 구조적 변화를 의미합니다. 즉, 시간을 쓰는 방식의 변화입니다. 전사에서 검토로. "내가 제대로 입력했나?"에서 "플래그된 두 행이 맞나?"로 바뀝니다.

위 데모는 사전 설정 템플릿 없이 실행됩니다. 서로 다른 앱의 스크린샷은 공통 형식을 공유하지 않기 때문입니다. 필요한 열을 직접 정의하면 AI가 업로드한 스크린샷에서 해당 열을 찾습니다. 이는 하나의 파일에서 200개까지 확장되는 동일한 추출 메커니즘입니다. 열 정의는 볼륨에 따라 변경되지 않습니다.

일괄 처리가 유용한 경우와 그렇지 않은 경우

일괄 처리가 항상 정답은 아닙니다. 매우 적은 양(예: 10개 미만의 스크린샷, 특히 단일 앱에서 가져온 경우)에서는 파일을 정리하고 열을 정의하는 오버헤드가 절약되는 시간보다 클 수 있습니다. 손익분기점은 추출의 복잡성에 따라 다르지만, 실용적인 기준은 다음과 같습니다. 최소 20개의 스크린샷에서 3개 이상의 필드를 추출하는 경우 일괄 워크플로우가 측정 가능한 시간 절약을 제공합니다. 그 이하에서는 개별 처리나 수동 입력이 더 빠를 수 있습니다.

일괄 처리는 다음과 같은 경우에 확실히 유리합니다.

• 스크린샷이 50개를 초과하는 경우. 이 임계값에서는 파일별 처리(열기, 추출, 확인, 닫기)의 조직적 오버헤드가 비생산적인 컨텍스트 전환으로 인해 몇 시간으로 누적됩니다.
• 스크린샷이 여러 소스 애플리케이션에서 오는 경우. 병합 단계(다른 도구의 추출 결과를 하나의 테이블로 결합)만으로도 수동으로 수행할 경우 추출 자체보다 더 많은 시간이 소요될 수 있습니다.
• 동일한 추출을 주기적으로 반복해야 하는 경우. 주간 대시보드 스냅샷, 월간 클라이언트 데이터 수집, 분기별 조정 스크린샷 등 열 정의를 재사용 가능한 목록으로 저장하면 후속 실행에서 설정 비용이 거의 0에 가깝게 떨어집니다.
• 감사 또는 조정을 위해 추적 가능성이 중요한 경우. 어떤 스크린샷이 어떤 데이터 행을 생성했는지 증명해야 하는 경우, 자동 소스 파일 추적 기능이 있는 일괄 처리는 수동 입력으로는 불가능한 감사 추적을 제공합니다.

스크린샷을 Excel로 추출하는 접근 방식은 하나의 스크린샷을 처리하든 200개를 처리하든 동일하게 작동합니다. 차이점은 워크플로우 설정 방식에 있을 뿐, 추출 메커니즘 자체에 있는 것이 아닙니다. 지금까지 ChatGPT, Excel의 '데이터에서 그림' 기능, 또는 기존 OCR 도구를 사용하여 스크린샷을 개별적으로 추출해 왔다면, 일괄 처리로의 전환은 새로운 도구를 배우는 것보다는 단일 파일 방식에서는 필요하지 않았던 파일 구성 규율을 채택하는 것에 더 가깝습니다.

자주 묻는 질문

같은 배치에서 다른 앱의 스크린샷을 섞어도 되나요?

네 — 각 스크린샷에서 동일한 개념적 필드를 추출하는 한 가능합니다. "고객명", "금액", "날짜" 열을 정의하면 AI가 Salesforce 스크린샷, QuickBooks 스크린샷, 은행 앱의 결제 확인 화면에서 해당 값을 찾습니다. 시각적 레이아웃이 일치할 필요는 없으며, 필드의 의미만 일치하면 됩니다. 이것이 열 이름 기반 추출과 템플릿 기반 OCR의 핵심 차이점입니다.

일부 스크린샷이 흐리거나 저해상도면 어떻게 되나요?

AI는 신뢰도가 낮은 필드를 조용히 입력하는 대신 검토를 위해 표시합니다. 스크린샷은 종이를 촬영한 것이 아니라 기계가 렌더링한 픽셀이므로 품질 문제는 드뭅니다. 스크린샷 추출에서 신뢰도가 낮은 가장 흔한 원인은 이미지 손상이 아니라 캡처 가장자리에서 필드 값이 일부 잘린 경우입니다. 문제가 있는 스크린샷이 있다면 처리하고, 표시된 행을 검토한 후 필요시 다시 캡처하세요 — 나머지 배치에는 영향을 주지 않습니다.

스크린샷 200장 배치는 실제로 얼마나 걸리나요?

처리 시간은 스크린샷 수와 각 추출의 복잡성에 비례합니다. 레이블이 명확한 앱 UI 스크린샷의 경우 파일당 약 5~10초가 소요됩니다. 200장 전체 배치는 약 15~30분의 AI 처리 시간 내에 완료되며, 그동안 다른 작업을 할 수 있습니다. 파일 업로드 시간은 연결 속도와 파일 크기에 따라 다릅니다. 검토 시간은 표시된 행 수에 따라 달라지며, 깨끗한 기계 렌더링 텍스트의 정확도가 99% 이상이므로 200장 배치에서 표시되는 행은 5개 미만입니다.

표가 포함된 스크린샷에서도 작동하나요?

네. 대시보드 그리드, 내보낸 보고서 미리보기, 스프레드시트 캡처 등 표 스크린샷도 동일한 열 이름 기반 추출로 처리됩니다. 다만 표는 구조적 결정이 필요합니다: 표의 각 행을 출력의 각 행으로 만들지(스크린샷 1개 = 출력 행 여러 개), 아니면 표에서 집계된 값을 가져올지 선택해야 합니다. 이 도구는 두 모드를 모두 지원합니다. 스크린샷 간 표 구조가 일관된 배치 시나리오의 경우 스크린샷-스프레드시트 파이프라인이 다중 행 추출을 기본적으로 처리합니다.

열 정의를 저장해 반복 사용할 수 있나요?

네. 열 정의를 재사용 가능한 템플릿으로 저장할 수 있습니다. 반복 작업(주간 대시보드 지표 추출, 월간 고객 데이터 내보내기)에 맞게 추출 필드를 한 번 설정하면, 새 스크린샷 배치마다 열 이름을 다시 입력할 필요 없이 적용할 수 있습니다. 이것이 배치 처리의 효율성이 극대화되는 지점입니다. 두 번째, 세 번째 동일한 추출을 실행할 때 설정 단계가 완전히 사라집니다.

스크린샷 배치에 지원되는 파일 형식은 무엇인가요?

PNG, JPG, WebP, AVIF — Windows, Mac, iOS, Android의 스크린샷 도구에서 생성되는 표준 이미지 형식입니다. 스크린샷이 포함된 PDF 파일(예: 대시보드 캡처를 모은 PDF 포트폴리오)도 지원됩니다. 핵심 요구 사항은 이미지에 화면에 표시된 사람이 읽을 수 있는 데이터가 포함되어야 한다는 점이며, 정확한 파일 형식은 중요하지 않습니다.

배치당 파일 제한이 있나요?

배치당 엄격한 파일 개수 제한은 없습니다. 실질적인 제약은 업로드 크기와 처리 시간입니다. 배치가 클수록 처리 시간이 비례하여 늘어나지만, 추가 설정이 필요하지는 않습니다. 500개 파일을 초과하는 배치는 200~300개씩 하위 배치로 나누면 검토 단계를 더 관리하기 쉬워집니다. 열 정의가 하위 배치 간에 유지되므로 의미 있는 오버헤드가 추가되지 않습니다.

출력 행이 어떤 원본 스크린샷에 해당하는지 어떻게 알 수 있나요?

배치 내보내기에는 각 원본 스크린샷의 파일명을 기록하는 "원본 파일" 열이 포함됩니다. 파일명이 2026-05-15_salesforce_q1-pipeline.png와 같이 일관된 명명 규칙을 따른다면, 이 열은 즉각적인 감사 추적을 제공합니다. 연결은 자동으로 이루어지므로 행과 파일을 수동으로 매핑할 필요가 없습니다.