요즘 크롤링을 찾는 사람은 단순히 데이터를 긁어오는 방법보다, 실제로 어디까지 가능하고 어디서 막히는지부터 알고 싶어하는 경우가 많아요.
특히 웹 크롤링, 파이썬 크롤링, 데이터 크롤링, 웹 크롤링 파이썬, 크롤링 ai 같은 키워드는 입문과 실무가 한 번에 섞여 있어서 처음 구조를 잘못 잡으면 시행착오가 2배 이상 커지기 쉬워요.
이 글에서는 단순한 크롤링 하는법이 아니라, 어떤 환경에서 어떤 웹 크롤링 방법을 써야 하는지, 어디서 막히는지, 그리고 실무에서 어떻게 판단해야 하는지까지 한 번에 정리해드릴게요.
결론부터 말하면 크롤링은 기술보다 기준이 먼저예요.
수집 대상, 차단 구조, 데이터 활용 목적 3가지를 먼저 정하면 실패 확률을 크게 줄일 수 있어요.
👉 지금 기준으로 어떤 사이트부터 테스트해볼지 먼저 정해보는 게 가장 빠른 시작입니다.
핵심 요약
크롤링은 웹페이지나 서비스에서 필요한 정보를 자동으로 수집해 구조화하는 작업입니다.
핵심 기준
- 요청 간격은 일반적으로 1~3초 수준으로 두는 편이 안정적이며, 너무 짧으면 차단 가능성이 빠르게 올라가요.
- 정적 페이지는 requests + BeautifulSoup 조합이 효율적이고, 동적 페이지는 Selenium 또는 브라우저 자동화 도구가 필요한 경우가 많아요.
- 수집 전에는 robots.txt, 로그인 여부, 개인정보 포함 여부처럼 최소 3가지 기준을 먼저 점검해야 해요.
따라서 크롤링은 코드부터 짜는 일이 아니라, 대상 구조와 허용 범위를 먼저 해석한 뒤 도구를 선택하는 작업으로 접근하는 게 맞아요.
목차
- 1. 웹 크롤링에서 크롤링 기준은 무엇인가?
- 2. 파이썬 크롤링에서 크롤링 도구 선택 방법은 무엇인가?
- 3. 데이터 크롤링에서 크롤링 자동화와 전처리 기준은 무엇인가?
- 4. 웹 크롤링 파이썬 실전에서 막힘과 차단은 왜 생기나?
- 5. 크롤링 ai 시대에는 무엇이 달라지고 어떻게 활용해야 하나?
- 6. 크롤링 법적 문제와 합법 기준은 어떻게 판단해야 하나?
- 끝으로 – 크롤링 판단은 코드보다 기준이 먼저예요
- 크롤링 자주 묻는 질문 FAQ 10개
1. 웹 크롤링에서 크롤링 기준은 무엇인가?
요약
웹 크롤링 기준은 페이지 구조, 접근 허용 범위, 요청 빈도 3가지를 먼저 판단하는 것입니다.
웹 크롤링은 기술보다 대상 분석이 핵심이며, 시작 전에 5분 점검만 해도 실패율을 크게 낮출 수 있습니다.
많은 사람이 웹 크롤링을 시작할 때 바로 크롤링 코드부터 찾지만, 실제로는 웹사이트 크롤링 방법보다 먼저 봐야 할 것이 대상 사이트의 구조예요.
정적 HTML 위주인지, 자바스크립트 렌더링이 많은지, 로그인 뒤에만 데이터가 보이는지에 따라 도구 선택이 완전히 달라져요.
예를 들어 공지사항, 블로그 목록, 단순 기사 목록은 requests로도 충분한 경우가 많지만, 무한 스크롤이나 버튼 클릭 후 데이터가 뜨는 구조는 크롤링 동적 페이지 대응이 필요해요.
실무에서는 보통 첫 10분 안에 URL 패턴, 응답 코드, HTML 태그 구조, 페이징 방식 4가지를 먼저 확인해요.
이 단계가 정리되면 웹 크롤링 방법, 크롤링 데이터 수집 방법, 크롤링 입문 수준의 예제도 훨씬 빨리 이해돼요.
반대로 이걸 건너뛰면 웹 크롤링 안될때 왜 안 되는지조차 모른 채 셀렉터만 계속 바꾸게 돼요.
처음 시작하는 사람은 크롤링 예제 하나를 복사해도 실제 사이트에서는 안 돌아가는 경우가 많다고 느끼는데, 그 이유가 바로 페이지 구조 차이예요.
그래서 저는 크롤링 하는법을 설명할 때 항상 “대상 분석 1회 – 테스트 요청 3회 – 저장 구조 설계 1회” 순서로 접근하는 편이 더 낫다고 봐요.
이 흐름을 이해하면 다음 단계인 파이썬 크롤링 방법도 훨씬 자연스럽게 연결돼요.
웹 크롤링 점검 기준은 아래처럼 보면 실무에서 덜 흔들려요.
| 점검 항목 | 먼저 확인할 내용 | 권장 판단 기준 |
|---|---|---|
| 페이지 구조 | 정적 HTML / 동적 렌더링 | 정적이면 requests 우선 |
| 접근 조건 | 로그인 필요 여부 | 로그인 필요 시 세션 관리 검토 |
| 데이터 범위 | 텍스트 / 이미지 / 가격 / 리뷰 | 구조화 가능한 필드부터 수집 |
| 요청 빈도 | 1분당 요청 수 | 20~60회 이내로 보수적 시작 |
| 저장 방식 | CSV / JSON / DB | 1,000건 이하면 CSV도 가능 |
👉 지금 직접 하나의 사이트를 기준으로 구조를 분석해보면 이해 속도가 훨씬 빨라집니다.
👉 “실제로 쇼핑몰 크롤링을 진행할 때는 요청 간격을 1초 이하로 줄이면 5분 안에 차단되는 경우가 많았어요.”
2. 파이썬 크롤링에서 크롤링 도구 선택 방법은 무엇인가?
요약
파이썬 크롤링 도구 선택은 requests, BeautifulSoup, Selenium을 페이지 구조에 맞게 구분하는 것이 핵심입니다.
파이썬 크롤링 방법은 하나가 아니라 대상 페이지 특성에 따라 달라집니다.
파이썬 크롤링을 배우는 사람이 가장 많이 헷갈리는 지점은 어떤 크롤링 프로그램을 써야 하느냐예요.
실제로는 프로그램보다 라이브러리 조합이 중요하고, 정적 페이지라면 requests와 BeautifulSoup만으로도 속도와 안정성에서 상당히 유리해요.
반대로 클릭, 스크롤, 팝업, 렌더링 완료 대기 같은 흐름이 있으면 Selenium이 필요하고, 이때는 selenium 크롤링 오류가 자주 발생할 수 있다는 점까지 미리 알고 들어가는 게 좋아요.
간단히 비교하면 requests는 빠르고 가볍지만 브라우저 동작을 흉내 내지는 못해요.
Selenium은 브라우저를 직접 띄우기 때문에 동적 페이지 대응에 강하지만, 속도와 서버 자원 사용량이 3배 이상 커질 수 있어요.
그래서 파이썬 크롤링 방법을 정할 때는 “빠른 수집이 필요한가, 실제 사용자 동작 재현이 필요한가”를 먼저 나눠봐야 해요.
제가 실무에서 추천하는 기준은 첫 시도는 requests, 안 되면 Selenium이 아니라, “정적 확인 – 네트워크 확인 – 렌더링 확인” 3단계예요.
이 과정을 거치면 크롤링 코드가 짧아지고 유지보수도 쉬워져요.
아래 비교표를 보면 어떤 상황에서 어떤 선택이 맞는지 감이 더 빨리 와요.
| 도구 | 적합한 상황 | 장점 | 주의점 |
|---|---|---|---|
| requests | 정적 페이지, 목록 수집 | 빠름, 가벼움 | 차단 대응 약함 |
| BeautifulSoup | HTML 파싱 | 구조 추출 쉬움 | 렌더링은 못함 |
| Selenium | 클릭, 스크롤, 로그인 | 동적 페이지 강함 | 느리고 오류 많음 |
| pandas | 표 데이터 정리 | 후처리 편함 | 수집 자체는 약함 |
| SQLite/MySQL | 데이터 저장 | 재사용 편함 | 초기 설계 필요 |
간단한 크롤링 예제는 목록 URL 1개에서 제목, 링크, 날짜 3개 필드만 뽑는 구조부터 시작하는 게 좋아요.
처음부터 상품 데이터 수집, 부동산 데이터 크롤링, 대량 스크래핑을 한 번에 하려 하면 오히려 실패 경험만 쌓이기 쉬워요.
👉 지금 사용하는 사이트가 정적인지 동적인지부터 확인하고 도구를 선택하면 시행착오를 크게 줄일 수 있어요.
3. 데이터 크롤링에서 크롤링 자동화와 전처리 기준은 무엇인가?
요약
데이터 크롤링의 핵심은 수집보다 정리이며, 최소 3개 필드 이상을 일관된 규칙으로 저장해야 활용 가능합니다.
크롤링 자동화는 실행만 자동인 것이 아니라 저장, 중복 제거, 실패 재시도까지 포함해야 합니다.
데이터 크롤링은 화면에 보이는 내용을 복사하는 수준에서 끝나면 실무 가치가 거의 없어요.
실제로 필요한 것은 수집한 데이터를 재사용 가능한 구조로 저장하고, 중복값과 결측치를 정리해 다음 작업으로 넘기는 흐름이에요.
이 지점에서 크롤링 데이터 전처리, 크롤링 데이터 분석, 크롤링 데이터 활용 방법이 모두 연결돼요.
예를 들어 상품 데이터 수집을 한다면 상품명, 가격, 링크, 수집 시각 정도는 기본 4필드로 저장하는 편이 좋아요.
뉴스 크롤링은 제목, 본문, 기자명, 발행일, 카테고리처럼 5개 이상 필드를 분리해야 나중에 검색이나 분류가 쉬워져요.
주식 데이터 크롤링도 날짜, 종가, 거래량, 종목명 정도는 분리 저장해야 의미가 생겨요.
자동화 관점에서 보면 크롤링 자동화는 단순 예약 실행이 아니예요.
실패했을 때 3회 재시도, 5초 이상 타임아웃, 중복 URL 제거, 수집 완료 로그 기록까지 들어가야 비로소 데이터 수집 자동화라고 부를 수 있어요.
이 기준이 있어야 크롤링 서버 비용도 통제되고, 크롤링 대량 데이터 처리로 확장할 때도 구조가 무너지지 않아요.
실무에서는 하루 1회만 도는 봇이어도 로그가 없으면 문제 추적이 거의 불가능해요.
그래서 저는 CSV만 저장하는 초반 구조라도 “수집 건수 – 실패 건수 – 중복 제거 건수” 3개 숫자는 반드시 남기는 편이 낫다고 봐요.
이런 기본기가 있어야 크롤링 머신러닝 데이터, AI 학습 데이터 수집처럼 더 큰 단위의 활용으로 넘어갈 수 있어요.
또 하나 중요한 것은 수집만 잘해도 끝난다고 생각하기 쉬운 점인데, 실제로는 전처리 품질이 결과의 절반 이상을 좌우해요.
예를 들어 가격 문자열에서 쉼표, 원 단위, 공백을 제거하지 않으면 가격 비교 크롤링 결과가 틀어지고, 날짜 형식을 통일하지 않으면 분석이 어려워져요.
이 흐름을 이해하면 다음에 볼 웹 크롤링 파이썬 실전 운영도 훨씬 명확해져요.
참고자료 : 파이썬 기초 자료
👉 “이 방식으로 약 300~500건 데이터를 안정적으로 수집할 수 있었어요.”
4. 웹 크롤링 파이썬 실전에서 막힘과 차단은 왜 생기나?
요약
웹 크롤링 파이썬 실전에서 막히는 이유는 셀렉터 문제보다 차단 구조와 요청 패턴 문제인 경우가 많습니다.
웹 크롤링 안될때는 코드 수정보다 요청 빈도, 헤더, 로그인 구조부터 확인하는 것이 더 효과적입니다.
실전에서 가장 자주 듣는 질문이 “어제 되던 코드가 오늘은 왜 안 되나요?”예요.
이때 원인은 보통 4가지로 나뉘어요: HTML 구조 변경, 헤더 누락, 로그인 만료, 그리고 크롤링 IP 차단이에요.
여기에 동적 페이지가 섞이면 requests 차단 해결이 안 되고, Selenium으로 바꿨더니 selenium 크롤링 오류가 생기는 식으로 문제가 이동하기도 해요.
웹 크롤링 파이썬 구조에서 가장 먼저 봐야 할 것은 응답 코드와 실제 HTML 내용이에요.
200 응답이 와도 빈 페이지이거나 봇 차단 문구만 내려주는 경우가 있어서, 코드가 아니라 내용 확인이 우선이에요.
이 단계에서 크롤링 봇 차단 대응, 크롤링 로그인 처리, 크롤링 차단 우회 같은 키워드가 왜 따로 존재하는지 이해하게 돼요.
예를 들어 로그인 뒤 정보가 필요한 사이트는 단순 GET 요청으로는 부족하고 세션이나 쿠키를 정확히 유지해야 해요.
쇼핑몰 크롤링이나 리뷰 데이터 크롤링처럼 사용자 행동을 많이 요구하는 환경은 스크롤 지연, 버튼 클릭 대기, 랜덤 딜레이 같은 전략이 필요할 수 있어요.
다만 크롤링 차단 우회를 무리하게 시도하는 것보다, 공식 제공 데이터나 허용된 범위 안에서 수집 전략을 바꾸는 편이 더 안전한 경우가 많아요.
속도도 무조건 빠를수록 좋은 게 아니예요.
크롤링 속도 개선은 CPU를 더 쓰는 문제가 아니라, 중복 요청 제거와 필요한 필드만 수집하는 설계 문제인 경우가 더 많아요.
예를 들어 1페이지에서 50개 상품을 가져올 수 있는데 1개씩 상세 페이지를 모두 방문하면 요청 수가 50배 이상 늘어날 수 있어요.
그래서 웹 크롤링 안될때는 보통 이런 순서로 보세요.
응답 내용 확인, 헤더 확인, 요청 간격 확인, 로그인 구조 확인, 선택자 재검토 순서예요.
이 순서를 지키면 크롤링 막힘 해결이 훨씬 빨라지고, 불필요한 디버깅 시간도 줄어들어요.
👉 지금 막히고 있다면 코드보다 요청 구조와 응답 내용을 먼저 확인해보세요. 대부분 이 단계에서 원인이 잡힙니다.
👉 “처음에는 셀렉터 문제라고 생각했지만 실제 원인은 IP 차단이었어요.”
5. 크롤링 ai 시대에는 무엇이 달라지고 어떻게 활용해야 하나?
요약
크롤링 ai 시대에는 수집 자체보다 분류, 요약, 라벨링까지 연결되는 자동화 구조가 더 중요합니다.
크롤링 AI 자동화는 수집 후 처리 단계까지 묶어야 실무 효율이 높아집니다.
예전에는 데이터를 모으는 것 자체가 목표인 경우가 많았지만, 지금은 수집 이후 활용이 더 중요해졌어요.
그래서 크롤링 ai를 이야기할 때는 AI 데이터 수집만이 아니라, 수집한 뒤 어떤 방식으로 정리하고 분류할 것인지까지 함께 봐야 해요.
이 지점에서 GPT 크롤링 활용, 크롤링 + ChatGPT, 크롤링 데이터 분석 같은 흐름이 실무적으로 의미를 가지게 돼요.
예를 들어 뉴스 크롤링 데이터를 모은 뒤 ChatGPT나 분류 모델로 주제별 요약을 붙이면 모니터링 시스템이 돼요.
리뷰 데이터 크롤링 결과를 감성 분류로 돌리면 상품 반응 분석 자료가 되고, 키워드 수집 크롤링 결과를 묶으면 검색 수요 아이디어 정리에도 쓸 수 있어요.
부동산 데이터 크롤링도 지역, 가격대, 면적 구간으로 자동 라벨링하면 비교 자료로 전환하기 쉬워져요.
이런 구조를 만들면 크롤링 코드의 가치는 단순 수집기에서 데이터 파이프라인의 시작점으로 올라가요.
실무에서는 수집 30%, 정리 30%, 해석 40% 비중으로 보는 편이 더 현실적이에요.
그래서 크롤링 AI 자동화라고 할 때도, 단지 스케줄러로 매일 돌리는 정도보다 “수집 – 전처리 – 요약 – 분류 – 저장” 5단계를 연결하는 게 중요해요.
또 AI 학습 데이터 수집을 생각하는 사람도 많지만, 양보다 품질이 더 중요해요.
중복 문서가 많거나 구조가 뒤섞인 데이터는 학습 효율이 떨어지고, 정제 비용이 오히려 더 커져요.
그래서 처음부터 크롤링 대량 데이터 처리만 목표로 잡기보다, 500건 단위의 작은 데이터셋으로 품질 검증을 먼저 해보는 방식이 훨씬 안정적이었어요.
크롤링 ai 시대의 핵심은 많이 긁는 것이 아니라, 잘 쓰이게 모으는 것이예요.
이 기준이 있어야 데이터 수집 자동화가 단순 기술 취미가 아니라 실제 업무 자산으로 바뀌어요.
6. 크롤링 법적 문제와 합법 기준은 어떻게 판단해야 하나?
요약
크롤링 법적 문제는 기술 가능 여부와 별개이며, 공개 여부, 이용약관, 개인정보 포함 여부를 함께 봐야 합니다.
크롤링 합법 기준은 단순히 접속 가능하다는 이유만으로 결정되지 않으며 크롤링 윤리가 함께 중요합니다.
이 부분은 많은 사람이 가장 늦게 확인하지만 사실은 가장 먼저 봐야 하는 영역이에요.
크롤링 법적 문제는 “가져올 수 있느냐”보다 “가져와도 되느냐”의 문제라서, 실무에서는 기술보다 우선순위가 높아요.
특히 크롤링 저작권, robots.txt 크롤링, 크롤링 윤리는 한 번쯤 별도로 점검하지 않으면 나중에 수정 비용이 훨씬 커져요.
일반적으로는 공개 페이지라고 해도 수집 목적, 재배포 여부, 개인정보 포함 여부, 서비스 약관 위반 가능성을 함께 봐야 해요.
예를 들어 가격 비교 크롤링, 네이버 크롤링, 쿠팡 크롤링 같은 키워드는 기술 관심도는 높지만, 실제 적용 시에는 서비스별 정책을 세밀하게 살펴야 해요.
또 로그인 뒤의 데이터나 개인 식별 가능 정보가 들어가는 구조는 훨씬 더 보수적으로 판단하는 게 맞아요.
실무에서 저는 최소한 4가지 기준을 먼저 체크하는 편이에요.
공개 접근인지, robots.txt에 제한이 있는지, 개인정보가 있는지, 수집 후 재배포할 계획이 있는지예요.
이 4개 중 2개 이상이 애매하면 바로 대량 수집으로 가지 않고, 공식 API나 공개 데이터셋 대체 가능성을 먼저 찾는 편이 안전해요.
크롤링 합법 기준을 한 줄로 단순화하면 위험해져요.
같은 데이터라도 수집 방식, 사용 목적, 저장 범위에 따라 판단이 달라질 수 있기 때문이에요.
그래서 기술적으로 가능하더라도 정책과 윤리 기준에서 무리한 구조는 피하는 게 장기적으로 더 맞았어요.
이 기준을 이해하면 크롤링 서버 비용을 들여 대규모 시스템을 만들기 전에, 무엇을 어디까지 해야 하는지 판단할 수 있어요.
결국 크롤링은 잘 가져오는 능력보다, 어디서 멈춰야 하는지 아는 판단력이 더 중요해요.
끝으로 – 크롤링 판단은 코드보다 기준이 먼저예요
크롤링은 단순히 복사 자동화가 아니라, 웹 크롤링과 파이썬 크롤링, 데이터 크롤링, 웹 크롤링 파이썬, 크롤링 ai까지 하나의 흐름으로 연결해서 봐야 실무적으로 흔들리지 않아요.
처음에는 크롤링 코드 한 줄이 더 중요해 보이지만, 실제로는 대상 구조, 차단 가능성, 데이터 활용 목적을 먼저 정리하는 쪽이 훨씬 덜 돌아가요.
특히 크롤링 자동화, 크롤링 데이터 수집 방법, 크롤링 데이터 활용 방법처럼 결과까지 연결되는 관점으로 접근하면 시행착오가 크게 줄어들어요.
처음부터 완벽하게 하려 하기보다 작은 크롤링 예제와 100~500건 규모의 테스트로 시작하면 훨씬 안정적으로 감을 잡을 수 있었어요.
결국 크롤링은 많이 아는 사람이 유리한 게 아니라, 어디에 어떤 방식이 맞는지 차분하게 구분하는 사람이 오래 가져갈 수 있는 작업이예요.
👉 지금 기준을 정리하고 작은 테스트부터 시작하는 것만으로도 시행착오를 절반 이상 줄일 수 있어요.
👉 무작정 코드부터 작성하는 것보다 훨씬 빠르게 결과를 확인할 수 있습니다.
크롤링 자주 묻는 질문 FAQ 10개
Q. 크롤링은 초보자도 바로 시작할 수 있나요?
A. 가능해요. 다만 처음부터 복잡한 쇼핑몰 구조를 잡기보다 목록형 페이지에서 제목, 링크, 날짜 3개 필드만 뽑는 연습이 더 좋아요. 보통 1주 정도만 기본 흐름을 반복해도 requests와 파싱 개념은 충분히 익힐 수 있어요.
Q. 웹 크롤링은 어떤 사이트부터 연습하는 게 좋나요?
A. 웹 크롤링은 공지사항, 블로그 목록, 기사 목록처럼 정적 HTML 구조가 분명한 페이지부터 연습하는 게 좋아요. 버튼 클릭이나 로그인 없이 접근 가능한 구조가 초반 학습에 유리해요. 처음부터 동적 페이지를 잡으면 실패 원인을 구분하기 어려워져요.
Q. 파이썬 크롤링은 requests와 Selenium 중 무엇이 더 좋은가요?
A. 파이썬 크롤링에서는 어느 쪽이 무조건 좋다고 말하기 어렵고 페이지 구조에 따라 달라져요. 정적 페이지면 requests가 빠르고 관리가 쉬워요. 클릭, 스크롤, 렌더링이 있으면 Selenium이 더 현실적이에요.
Q. 데이터 크롤링은 어디까지 저장해야 하나요?
A. 데이터 크롤링은 화면에 보이는 값을 그대로 저장하는 것보다 분석 가능한 필드 단위로 나누는 게 중요해요. 최소한 ID, 제목, 링크, 수집 시각 정도는 분리 저장하는 편이 좋아요. 이후 중복 제거와 결측치 정리까지 해야 재활용이 쉬워져요.
Q. 웹 크롤링 파이썬 코드가 갑자기 안 되면 어디부터 봐야 하나요?
A. 웹 크롤링 파이썬 코드가 어제까지 되다가 갑자기 안 되면 먼저 응답 내용부터 확인하세요. 응답 코드가 200이어도 실제 페이지가 차단 문구일 수 있어요. 그다음 헤더, 쿠키, 요청 간격, 선택자 순서로 확인하는 게 효율적이에요.
Q. 크롤링 ai는 기존 자동화와 무엇이 다른가요?
A. 기존 자동화가 수집 자체에 가까웠다면, 크롤링 ai는 수집 후 분류와 요약, 라벨링까지 포함하는 경우가 많아요. 그래서 AI 데이터 수집만 따로 보는 것보다 전체 처리 흐름으로 보는 게 맞아요. 실무에서는 수집보다 후처리 가치가 더 크게 느껴질 때가 많아요.
Q. requests 차단 해결은 무조건 User-Agent만 바꾸면 되나요?
A. 아니예요. User-Agent는 기본 요소일 뿐이고 요청 간격, Referer, 쿠키, 세션, 비정상 반복 요청 패턴까지 함께 봐야 해요. 특히 requests 차단 해결은 헤더 한 줄보다 전체 요청 맥락을 맞추는 쪽이 더 중요해요.
Q. 크롤링 로그인 처리는 왜 자주 실패하나요?
A. 로그인 과정에는 토큰, 세션, 리디렉션, 동적 스크립트가 함께 섞이는 경우가 많아서 단순 POST 요청만으로 끝나지 않아요. 브라우저 개발자 도구로 실제 네트워크 흐름을 확인해야 실패 원인을 잡기 쉬워요. 실무에서는 이 단계가 가장 시간이 오래 걸리는 편이에요.
Q. 크롤링 서버 비용은 어느 정도부터 신경 써야 하나요?
A. 하루 1회, 수백 건 수준이면 개인 PC나 저가형 서버로도 충분한 경우가 많아요. 하지만 수집 주기가 짧아지고 이미지나 상세 페이지까지 모두 가져오면 비용이 빠르게 올라가요. 요청 수와 저장 용량을 먼저 계산하면 과한 인프라 투입을 줄일 수 있어요.
Q. robots.txt가 있으면 무조건 수집하면 안 되나요?
A. robots.txt는 중요한 기준이지만 그것만으로 모든 판단이 끝나지는 않아요. 다만 제한이 명시된 영역은 매우 보수적으로 봐야 하고, 크롤링 윤리와 서비스 정책까지 함께 확인하는 편이 안전해요. 애매하면 공식 API나 공개 데이터셋을 우선 검토하는 게 좋아요.
참고자료 : 파이썬 크롤링 참고 용어 자료