프로젝트에 웹에서 데이터가 필요할 때, 첫 번째 갈림길은 간단하게 정리할 수 있다. 소스의 공식 API를 사용할 것인가, 아니면 웹 페이지에서 데이터를 수집할 것인가. 둘 다 데이터를 얻는 정당한 방법이며, 팀들은 종종 원칙적으로 한쪽을 주장하곤 한다. 하지만 실제로 어느 쪽이 맞는지는 API가 실제로 무엇을 제공하는지, 페이지에 무엇이 보이는지, 프로젝트에 무엇이 필요한지에 달려 있다.
이 가이드는 실제 프로젝트를 좌우하는 요소들을 기준으로 두 방법을 비교하고, 각각이 유리한 지점을 설명하며, 둘을 결합하는 일반적인 중간 경로도 다룬다. 여기에는 페이지를 공식 API처럼 구조화된 데이터로 바꿔주는 web scraping API 사용도 포함된다.
요약
| 요소 | 공식 API | 웹 스크레이핑 |
|---|---|---|
| 사용 가능한 데이터 | 제공자가 공개하기로 선택한 것만 | 공개 페이지에 보이는 모든 것 |
| 형식 | 구조화됨(보통 JSON), 문서화됨 | 파싱하거나 추출해야 하는 HTML |
| 안정성 | 버전 관리됨, 변경 사항 공지됨 | 페이지 레이아웃이 바뀌면 깨짐 |
| 제한 | 속도 제한, 쿼터, 때로는 유료 등급 | 자신의 수집 능력, 사이트의 허용 범위와 약관 |
| 약관 | 무엇을 할 수 있는지 명시한 명확한 라이선스 | 사이트 약관과 법률에 따라 다름 |
| 범위 | API당 제공자 하나 | 모든 사이트, 모든 시장을 동일한 방법으로 |
| 보이는 것 | 제공자의 데이터 모델 | 특정 위치의 방문자가 보는 것 |
공식 API가 필요한 필드를 필요한 물량만큼, 사용 목적을 허용하는 약관 아래 제공한다면 그것부터 시작하라. 스크레이핑은 이 세 가지 조건 중 하나라도 충족되지 않을 때 자리를 차지한다.
공식 API가 더 나은 선택인 경우
- 필요한 데이터가 API에 있는 경우. 많은 API는 관대하다. 카탈로그 데이터, 공개 프로필, 재무 공시, 공공 데이터셋 등이다. 언제 레지덴셜 프록시가 필요 없는지에 대한 테스트에서 우리가 시도한 모든 공개 API는 프록시 없이도 안정적으로 작동했다.
- 범위보다 안정성이 더 중요한 경우. 변경 공지가 따르는 버전 관리 API는 페이지 레이아웃을 추적하는 파서보다 유지 관리가 훨씬 적게 든다.
- 라이선스가 중요한 경우. 데이터를 공개하거나 재판매하거나 그 위에 제품을 만들 계획이라면, API의 약관은 무엇이 허용되는지를 정확히 알려준다. 스크레이핑한 데이터의 경우 이를 직접 알아내야 한다.
- 어떤 페이지에도 없는 데이터가 필요한 경우. 일부 API는 어떤 웹 페이지에도 나타나지 않는 이력, 식별자, 대량 내보내기를 제공한다.
웹 스크레이핑이 더 나은 선택인 경우
- API가 아예 존재하지 않는 경우. 이는 여전히 웹 대부분에 해당한다. 대부분의 소매업체, 지역 업체, 뉴스 사이트, 디렉토리는 공개 데이터 API가 없다.
- API가 필요한 것을 빠뜨리는 경우. API는 현재 진행 중인 프로모션, 재고 메시지, 리뷰, 쇼핑객에게 실제로 보여지는 정확한 가격 등 페이지에 있는 필드를 종종 생략한다.
- 사용자가 실제로 보는 것이 필요한 경우. 가격, 순위, 광고, 재고 상태는 흔히 위치, 기기, 언어에 따라 달라진다. API는 제공자의 표준 데이터를 주지만, 페이지는 특정 시장에서의 경험을 보여준다. 이러한 뷰를 수집하려면 보통 시장 내부에서 페이지를 요청해야 하는데, 이때 레지덴셜 프록시가 필요해진다.
- 여러 소스를 동일한 방식으로 다뤄야 하는 경우. 하나의 스크레이핑 설정으로 백 개의 소매업체를 처리할 수 있지만, 백 개의 API라면 백 개의 통합, 키, 속도 제한 체계가 필요하며, 애초에 API가 존재하지 않을 수도 있다.
- API의 제한이 맞지 않는 경우. 쿼터, 가격 정책, 승인 절차 등으로 인해 필요한 물량에서는 API가 비현실적일 수 있다.
중간 경로들
선택은 양자택일인 경우가 드물다.
둘 다 사용하기. 흔한 패턴은 안정적인 핵심 데이터(제품 식별자, 카탈로그 구조)는 API로, API에 없는 것(실시간 가격, 프로모션, 지역별 재고)은 스크레이핑으로 처리하는 것이다. 각각 가장 잘하는 일을 맡는다.
페이지 자체의 API 사용하기. 많은 현대 웹사이트는 내부 JSON 엔드포인트에서 콘텐츠를 불러온다. 이를 사용하는 것이 적절한 경우, 스크레이핑의 범위와 API의 깔끔한 형식을 결합할 수 있다. 페이지 뒤의 API 찾기에 대한 우리의 연구는 이러한 데이터가 얼마나 자주 존재하는지, 그리고 이를 신뢰하기 전에 무엇을 확인해야 하는지를 보여준다.
페이지에 이미 있는 구조화된 데이터 사용하기. 많은 페이지는 검색 엔진을 위해 JSON-LD를 포함한다. 제품명, 가격, 평점, 영업시간 등이다. 이를 읽는 것은 보이는 레이아웃을 파싱하는 것보다 훨씬 견고하다. HTML 파싱 대신 JSON-LD 추출하기를 참고하라.
web scraping API 사용하기. web scraping API는 URL을 받아 페이지 자체 또는 추출된 필드를 JSON으로 반환하며, 프록시, 브라우저, 재시도를 대신 처리해준다. 여러분의 코드 입장에서는 공식 API와 거의 비슷하게 동작한다. 요청 하나를 보내면 구조화된 데이터가 나온다. 소스 자체의 API가 맞는 상황이라면 이를 대체하지는 않지만, 스크레이핑의 유지보수 부담 대부분을 없애준다. web scraping API 사용을 위한 초보자 가이드가 이를 단계별로 안내하며, 직접 구축할지 구매할지에 대한 가이드는 자체 스크레이핑 인프라를 운영하는 것이 여전히 합리적인 경우를 다룬다.
단계별 결정 방법
- 필요한 필드를 나열하고, 각각에 대해 API에 있는지, 페이지에 있는지, 아니면 둘 다에 있는지 기록한다.
- API의 약관과 제한을 자신의 사용 목적 및 물량과 대조해 확인한다.
- 페이지의 뷰를 확인한다. 필요한 것이 위치나 기기에 따라 달라지는가? 그렇다면 API에는 나타나지 않을 수 있다.
- 소스 수를 센다. 좋은 API를 가진 소스가 한두 개뿐이라면 API가 유리하고, 소스가 많다면 스크레이핑 방식이 유리하다.
- 유지보수를 추정한다. API 통합은 대체로 한 번 구축하면 끝이지만, 스크레이퍼는 페이지가 바뀜에 따라 모니터링과 간헐적인 수정이 필요하다.
- 프로젝트 단위가 아니라 필드 단위로 선택한다. 일부 필드는 API에서, 다른 필드는 페이지에서 가져오는 것은 자연스러운 일이다.
두 경로 모두에 따르는 책임
API를 사용한다는 것은 그 약관, 즉 쿼터, 출처 표기, 허용된 사용 범위를 따른다는 뜻이다. 페이지에서 수집한다는 것은 해당되는 범위 내에서 사이트 약관을 따르고, robots.txt와 속도 제한을 준수하며, 로그인 뒤의 콘텐츠에는 접근하지 않고, 적용 법률에 따라 개인 데이터를 다룬다는 뜻이다. 어느 경로도 책임에서 자유롭지 않다. 다만 그 책임이 각기 다른 곳에 쓰여 있을 뿐이다.
자주 묻는 질문
API를 사용하는 것이 나을까, 웹사이트를 스크레이핑하는 것이 나을까?
공식 API가 필요한 데이터를 필요한 물량만큼, 사용 목적을 허용하는 약관 아래 제공한다면 그것을 사용하라. API가 없거나, API가 필요한 것을 빠뜨리거나, 특정 시장의 사용자가 보는 그대로의 데이터가 필요할 때는 스크레이핑하라.
웹 스크레이핑이 API보다 더 신뢰할 수 있는가?
대개는 그렇지 않다. 페이지 레이아웃은 예고 없이 바뀌지만 API는 버전 관리가 되기 때문이다. 추출 규칙, 페이지의 구조화된 데이터, 모니터링을 활용하면 그 격차를 줄일 수 있으며, web scraping API는 유지보수의 상당 부분을 대신 처리해준다.
API와 웹 스크레이핑을 함께 사용할 수 있는가?
그렇다. 많은 팀이 그렇게 한다. 데이터의 안정적인 핵심 부분은 API로, 실시간 가격, 프로모션, 지역별 재고처럼 API가 제공하지 않는 필드는 스크레이핑으로 처리한다.
web scraping API란 무엇인가?
자체 프록시와 브라우저를 통해 웹 페이지를 대신 가져와 HTML이나 추출된 필드를 JSON으로 반환해주는 서비스다. 여러분의 코드 입장에서는 스크레이핑이 API 호출처럼 보이게 만들어주지만, 사이트 자체의 공식 API를 대체하지는 않는다.
결론
필요한 것을 맞는 약관 아래 제공해 준다면 공식 API부터 시작하라. API가 없는 소스, API가 빠뜨린 필드, 그리고 가격과 재고에 대한 지역별, 실제로 보이는 그대로의 뷰가 필요할 때는 스크레이핑으로 눈을 돌려라. 실제 프로젝트 대부분은 결국 둘 다를 사용하게 되며, 프로젝트 단위가 아니라 필드 단위로 선택하게 된다. 그리고 web scraping API는 스크레이핑 쪽을 API 쪽과 훨씬 비슷하게 느껴지도록 만들어준다.