데이터 추출 vs 데이터 스크래핑
청구서에 URL이 없을 때

정의는 달라도 출처는 달라지지 않습니다

두 용어에는 합의된 정의가 없습니다. 그래서 이 비교가 계속 처음으로 되돌아갑니다. 텍스트 및 데이터 마이닝에 관한 Bodleian Libraries 가이드는 웹 스크래핑과 화면 스크래핑을 데이터 스크래핑 아래, 데이터베이스 및 문서와 나란히 분류합니다. 수십 개의 벤더 설명 자료는 데이터 추출을 상위 개념으로 보고 스크래핑을 그 아래에 둡니다. 어떤 표준 기관도 이 용어를 확정한 적이 없습니다.

이견이 있어도 지금 앞에 놓인 결정은 달라지지 않습니다. 웹 스크래핑은 살아 있는 웹 인터페이스에서 데이터를 수집합니다. 도구가 URL을 요청하거나 브라우저를 구동해 HTML, 렌더링된 DOM 또는 내장 JSON을 받고, 그 구조에서 값을 뽑아냅니다. 문서 추출은 이미 가지고 있는 파일에서 이름이 붙은 값을 읽습니다. PDF, 스캔, 영수증을 찍은 휴대폰 사진, 스크린샷, 이메일 첨부 파일 모두 해당합니다. 요청할 것도, 살펴볼 마크업도 없습니다.

정의 문제를 우회하는 지름길은 데이터가 지금 어디에 있는지 묻는 것입니다. 위치를 요청해 얻을 수 있다면 스크래핑 문제이고, 사이트가 API를 제공한다면 API 문제입니다. 이미 파일 안에 들어 있다면 문서 문제입니다.

스크래퍼가 읽는 것

스크래퍼는 브라우저가 받은 마크업을 읽습니다. 그래서 빠르고 저렴하면서 동시에 정확할 수 있습니다.

URL로 요청이 가고, 서버가 문서를 반환하고, 문서가 요소 트리로 파싱되고, 선택자가 값을 담고 있는 요소를 골라내고, 이 작업이 일정에 따라 여러 페이지에서 반복됩니다. JavaScript가 많은 사이트에서는 먼저 헤드리스 브라우저를 구동할 수 있어, 무언가를 선택하기 전에 트리가 존재하게 됩니다.

선택자가 작동하는 이유는 놓치기 쉽습니다. 가격을 표시하는 페이지는 데이터에서 생성되었기 때문에 레이블과 값이 같은 행에, 같은 템플릿으로 작성되어 있습니다. 클래스 .amount가 있는 셀을 복사하는 것은 사이트 자체 코드가 렌더링에 사용한 필드를 읽는 것입니다.

선택자는 페이지가 데이터에서 생성되었기 때문에 작동하는 지름길입니다. 소스가 더 이상 생성된 마크업이 아니게 되면 이 지름길은 살아남지 못합니다.

그래서 스크래핑은 특정한 방식으로 깨집니다. 리디자인에서 클래스 이름이 바뀌면 선택자가 빈 목록을 반환합니다. 테이블이 캔버스나 이미지 안으로 이동하면 값이 더 이상 텍스트가 아닙니다. 로그인 벽이나 봇 검사가 파싱이 시작되기도 전에 요청을 막습니다. 이는 접근과 구조의 문제이며, 해결책은 엔지니어링 시간입니다.

같은 속성이 혼합 프로젝트에서 가장 흔한 실수를 설명해 줍니다. 페이지를 처리하는 도구가 그 페이지에 첨부된 파일도 처리할 것이라고 가정하는 것입니다. 한 개발자는 그 벽을 이렇게 명확히 표현했습니다. "대부분의 스크래퍼(BeautifulSoup, Playwright 등)는 HTML을 돕지만, 크롤링 중 PDF를 처리하려면 추가 레이어가 필요합니다."

문서 추출이 대신 읽는 것

PDF에는 표 객체도, 행도, 셀도 없습니다. 페이지 좌표에 글리프를 배치하라는 지시만 있을 뿐입니다.

이는 문자 그대로입니다. PDF 사양인 ISO 32000은 텍스트를 일련의 변환 행렬 내부에서 텍스트 표시 연산자로 배치된 글리프로 설명합니다. 화면에서 구조화되어 보이는 표는 우연히 정렬된 문자 집합일 뿐입니다. 파일은 관계가 아니라 정렬을 기록하므로, 파서는 네 개의 값이 한 행에 속한다는 것과 가장 오른쪽 값이 두 번째 금액이 아니라 잔액이라는 것을 추론해야 합니다. 스캔은 한 단계 더 멀리 있습니다. 텍스트 레이어가 없는 이미지입니다.

작업 순서가 뒤바뀝니다. 스크래퍼는 어느 요소가 가격을 담고 있는지 묻습니다. 문서 추출기는 어떤 영역이 표인지, 헤더가 어디서 끝나는지, 값이 위 행에 속하는지 아래 행에 속하는지, 그리고 어느 숫자가 소계나 세금이 아니라 합계인지를 판단해야 합니다. 광학 문자 인식은 읽기 순서대로 문자를 반환하고 거기서 멈추는데, 이것이 전사와 추출의 차이입니다.

의미 계층은 공급자별 규칙 문제를 제거합니다. ImageToTable.ai는 맞춤 열 추출을 중심으로 구축되었습니다. "Statement Date"와 "Amount"처럼 원하는 열 이름을 입력하면, 모델이 지난 명세서에서 어디에 있었는지가 아니라 레이블이 무엇을 의미하는지 이해하여 각 값을 찾아냅니다. 공급자가 레이아웃을 바꾸는 것은 이런 종류의 도구에게 이벤트가 아닙니다. 찾는 기준이 위치가 아니었기 때문입니다.

두 접근법이 실제로 갈라지는 지점

갈라짐은 한 곳에서 나타납니다. 필요한 값을 담고 있는 소스의 계층입니다.

포털에 게시된 은행 거래 명세서는 그것을 보이게 만듭니다. 페이지에는 요약 블록이 표시됩니다. 기초 잔액, 기말 잔액, 입금액, 출금액, 그리고 명세서를 PDF로 다운로드하는 버튼입니다. 그 페이지를 향한 스크래퍼는 몇 초 만에 수치를 반환합니다. 거래 내역은 그 버튼이 생성하는 PDF 안에 있고, 페이지의 어느 것도 그것을 담고 있지 않습니다. 이것이 이 실수의 흔한 형태이며, 오류 메시지 하나 없이 매달 반복됩니다.

같은 PDF를 위치 기반 파서로 읽으면 두 번째 실패가 나타납니다. 잔액 열은 오른쪽 정렬이므로 그 숫자들이 금액 열에 가깝게 위치합니다. 공백으로 텍스트를 그룹화하면 열이 병합될 수 있고, 천 단위 구분 기호에서 텍스트 런에 걸쳐 분할된 숫자는 두 조각으로 도착할 수 있습니다. 출력은 올바른 행 수와 그럴듯한 합계를 가진 유효한 스프레드시트입니다. 오류는 누군가 거래 내역의 합이 기말 잔액에서 기초 잔액을 뺀 값과 일치하는지 확인할 때에만 드러납니다.

세 번째 경우는 가장 단순하고 가장 흔합니다. 이메일 첨부 파일로 도착하는 청구서에는 가져올 페이지가 없습니다. 공급자가 PDF를 생성해서 보냈습니다. URL도 마크업도 없으므로, 누군가 문서 단계를 추가하기 전까지 스크래핑 스택은 할 일이 없습니다.

요약 페이지만 반환하는 스크래퍼는 오작동한 것이 아닙니다. 요청받은 일을 정확히 했지만, 소스의 잘못된 계층에서 했을 뿐입니다.

빠져나가는 것은 대개 핵심 숫자가 아닙니다. 데이터를 쓸 수 있게 만드는 세부 정보입니다:

• 요약 페이지에는 합계가 나오고 청구서 PDF에는 그 합계가 무엇으로 구성되는지 나오기 때문에, 항목별 내역이 빠집니다.
• 첫 페이지에 요약 블록이 있기 때문에, 명세서의 두 번째 페이지부터가 빠집니다.
• 크레딧이 괄호로 인쇄되어 텍스트로 복사될 때, 금액의 부호가 빠집니다.
• 배송 주소처럼 보이는 블록에 들어 있는 청구 주소가 빠집니다.
• 페이지들을 하나의 레코드로 다시 결합할 수 있게 해주는 식별자가 빠집니다.

스크린샷은 웹사이트를 보여줘도 문서입니다

은행 대시보드의 스크린샷은, 그 안의 모든 픽셀이 웹 페이지에서 시작되었더라도, 문서입니다.

이는 앞선 혼동의 반대 경우이며, 웹 콘텐츠는 웹 스크래핑을 의미한다고 막 배운 사람들을 걸리게 합니다. PNG에는 DOM도, 선택자도, 대개 접근 가능한 URL도 없습니다: 그 상태에 도달하려면 로그인과 세 번의 클릭이 필요했을 수 있습니다. 그것을 읽는 도구는 픽셀을 읽는 도구입니다. 포털에서 다운로드한 PDF도 같은 방식으로 작동합니다: 디스크에 저장되는 순간 URL은 중요하지 않아집니다. 화면 캡처는 스크린샷에서 데이터 추출하기에서 다룹니다.

법적 문제는 종류가 다릅니다

스크래핑은 데이터에 접근이 허용되었는지를 묻습니다. 문서 추출은 이미 보유한 데이터로 무엇을 할 수 있는지를 묻습니다.

스크래핑 쪽에서, 서비스 약관은 계약이며, 대부분의 실제 위험이 여기에 있습니다. 기술적 검사는 보기보다 약합니다. 2022년 RFC 9309로 표준화된 Robots Exclusion Protocol은 서문에서 그 규칙이 "접근 권한 부여의 한 형태가 아니다"라고 밝힙니다. robots.txt 파일은 운영자가 무엇을 선호하는지를 나타냅니다. 허가를 부여하지는 않습니다.

hiQ Labs v. LinkedIn은 위험이 어디에 떨어지는지를 보여줍니다. 2022년 제9순회법원은 hiQ가 공개 프로필을 계속 수집할 수 있게 한 금지 명령을 유지했는데, 그 근거는 공개 데이터 스크래핑이 그 자체로 Computer Fraud and Abuse Act상 "허가된 접근을 초과"하지 않는다는 것이었습니다. 이는 스크래퍼에게 승리처럼 보였습니다. 사건은 다르게 끝났습니다: 2022년 11월 지방법원은 hiQ가 LinkedIn의 사용자 계약을 위반했다고 판단했고, 그해 12월 동의 판결로 $500,000의 판결금이 부과되고 hiQ의 스크래핑이 영구히 금지되었습니다. 계약 청구는 그 극적인 이론보다 오래 살아남았습니다.

금융팀에게 곤란한 사례는 카테고리 비교에서 좀처럼 등장하지 않습니다. 은행 계좌의 거래는 당신의 데이터이고, 인터페이스는 은행의 것입니다. 자신의 자격 증명으로 그 인터페이스를 자동화하면 돈이 당신의 것이더라도 은행 약관을 위반할 수 있습니다. 먼저 내보내기를 요청하거나 공식 API가 있는지 확인하십시오; 영국과 EU에서는 접근이 화면 자동화를 거치지 않아도 되도록 오픈 뱅킹 규칙이 존재합니다.

문서 쪽에서는, 적법한 보유가 분석의 출발점입니다. 명세서에는 개인 데이터가 포함되므로, 보존, 접근, 그리고 처리자가 파일을 어디에 저장하는지가 모두 문제가 됩니다. 그 작업은 개인정보 보호 또는 컴플라이언스 담당자의 몫입니다. 이 섹션은 어떤 질문을 누구에게 라우팅할지에 대한 지도로 취급하시고, 법률 자문으로 받아들이지 마십시오.

데이터 소스별 결정 표

소스가 도구를 결정하며, 대부분의 팀은 같은 표의 서로 다른 행을 위해 두 도구가 모두 필요합니다.

포털이 필요한 문서를 게시할 때 작업은 둘로 나뉩니다. 무언가가 일정에 따라 파일을 가져오고, 무언가가 그것을 읽습니다. 읽기 단계가 파일이 어디서 왔는지 신경 쓰지 않도록 파이프라인을 구축하면, 은행이 API를 출시하는 날 가져오기 단계 하나를 삭제하면 됩니다.

문서 추출이 멈추는 지점

문서 추출은 파일이 존재한 뒤에 시작되므로, 파일을 확보하는 문제는 해결할 수 없습니다.

이 경계는 얼버무리지 않고 짚고 넘어갈 가치가 있습니다. ImageToTable.ai는 문서를 읽습니다. 웹사이트를 스크래핑하거나, 페이지를 크롤링하거나, 브라우저를 구동하거나, HTML을 파싱하지 않습니다. PDF, 이미지, 스크린샷을 업로드하거나 이메일 수신함 주소로 전달하면 테이블을 돌려받고, 원본 레이아웃이 필요하면 Word 파일을 받습니다. 거래 명세서가 은행 로그인 뒤에만 존재한다면, 추출은 파이프라인의 후반부일 뿐입니다.

또한 어떤 숫자가 맞는지도 알지 못합니다. 페이지에 적힌 대로 읽을 뿐입니다. 깔끔하게 인쇄된 표는 쉬운 경우이고, 저희 문서에서도 인쇄된 표 데이터에 대해 최대 99% 정확도를 언급하고 있습니다. 책상 스탠드 아래에서 구겨진 영수증을 찍은 사진은 그 경우가 아닙니다. 빽빽한 손글씨와 특이한 레이아웃에서야 처리 티어와 검토 단계가 제 역할을 합니다. OCR, 추출, 완전한 IDP 플랫폼의 차이는 AI 문서 추출이 실제로 무엇인지에서 다룹니다.

실제로 견고한 것은 배치 워크플로입니다. 열 이름을 정하고, 서로 다른 공급업체의 파일 폴더를 하나의 배치에 넣으면, 같은 필드가 같은 순서로 담긴 하나의 테이블을 얻습니다. 입력하는 데 3분 걸리던 페이지가 몇 초 만에 처리됩니다. 이 이득은 실재하며, 하나의 도구가 스크래핑 스택과 문서 파이프라인을 동시에 대체한다는 주장보다는 작습니다.

자주 묻는 질문

OCR은 웹 스크래핑과 같은 건가요?

아닙니다. OCR은 픽셀에서 문자를 읽고, 웹 스크래핑은 라이브 페이지에서 마크업을 읽습니다. 둘이 만나는 경우는 아주 좁습니다. 일부 사이트는 스크래퍼를 막으려고 텍스트를 이미지로 렌더링하는데, 스크래핑 파이프라인이 그 이미지에 OCR을 대체 수단으로 돌릴 수 있습니다. OCR은 스크래핑 작업 안의 한 구성 요소이지, 그 동의어가 아닙니다.

웹 스크래퍼가 PDF 청구서를 읽을 수 있나요?

PDF를 다운로드할 수는 있습니다. 청구서를 읽는 부분은 문서 파서입니다. PDF에는 선택할 요소가 없기 때문입니다. 파일에 텍스트 레이어가 있으면 파서가 읽을 수 있고, 스캔이라면 OCR이나 비전 모델이 먼저 페이지 이미지를 읽어야 합니다. 스크래핑 프레임워크는 파일을 가져오고, 그 선택자 중 어느 것도 열 수 없는 바이너리만 남깁니다.

제 은행의 인터넷 뱅킹 사이트를 스크래핑해도 되나요?

먼저 거래 명세서 내보내기나 공식 API가 있는지 확인하십시오. 데이터는 본인의 것이지만 인터페이스는 은행의 것이며, 이를 자동화하는 것은 대개 은행 약관의 적용을 받습니다. 화면 자동화는 은행이 페이지를 개편할 때마다 깨지기도 합니다. 거래 명세서를 내보낸 뒤 파일에서 추출하십시오.

대시보드 스크린샷에는 어느 쪽이 필요한가요?

문서 추출입니다. 스크린샷은 DOM이 없고 접근 가능한 URL도 대개 없는 래스터 이미지이므로, 스크래퍼가 선택할 것이 없습니다. 스캔처럼 다루시고, 원본 이미지가 정확도의 상한을 정한다고 보십시오.

둘 중 하나에 개발자가 필요한가요?

스크래핑은 대개 개발자가 필요하고 계속 필요합니다. 선택자, 프록시, 안티봇 대응이 지속적인 유지보수이기 때문입니다. 문서 추출은 노코드 도구를 쓰면 코드가 필요 없고, 이 단계를 자체 시스템 안에 두고 싶다면 API가 있습니다.

공개 데이터 스크래핑은 합법인가요?

관할 지역, 사이트 약관, 데이터 유형, 수집 방식에 따라 달라집니다. 공개되었다고 해서 제한이 없는 것은 아닙니다. 개인정보는 페이지가 공개되어 있었는지와 무관하게 개인정보보호법을 적용받으며, 사이트 약관을 무시하면 접근 자체가 불법이 아니더라도 계약상 책임이 발생할 수 있습니다. 해당 시장을 잘 아는 변호사에게 문의하십시오.

구매를 결정짓는 질문

위의 모든 내용은 하나의 질문으로 귀결됩니다. 데이터가 언제 파일에서 페이지로 바뀌는가? 이 질문에 답하면 비교표가 쇼핑 목록으로 바뀝니다. 실시간 페이지에 있는 행에는 스크래퍼, 청구서·명세서·영수증으로 도착하는 행에는 문서 추출기, 로그인 뒤에 파일을 게시하는 포털에는 그 사이의 가져오기 단계가 필요합니다.