크롤링 with Scrapy

1. 웹 구조

 

웹 환경의 핵심은 서버–클라이언트 구조

클라이언트가 서버에 요청(request)을 보내고 서버가 응답(response)을 주는 방식으로 이루어진다.

 

클라이언트가 서버에 접속할 때 사용하는 주소가 바로 URL이며, 이는 내부적으로 IP 주소와 포트 번호로 변환된다. IP 주소는 물리적인 서버의 위치를 의미하고, 포트 번호는 그 서버 안에서 어떤 서비스(웹 서버, 데이터베이스 서버 등)에 접근할지를 구분하는 역할을 한다. 

서버와 클라이언트가 대화하기 위해서는 공통된 약속인 HTTP 프로토콜이 필요하다. 웹에서 이루어지는 모든 통신은 이 HTTP 규칙을 기반으로 하며, 이 안에서 가장 중요한 개념이 바로 Request와 Response다. 브라우저가 서버에 요청을 보내면 서버는 그 요청에 맞는 데이터를 다시 브라우저로 전달한다. 웹은 결국 이 요청과 응답의 반복으로 구성되어 있다고 볼 수 있다.

 

프론트앤드

 

프론트엔드는 사용자가 직접 보고 상호작용하는 영역

• HTML은 페이지의 구조와 내용을 정의하고, CSS는 그 내용을 어떻게 꾸밀지를 결정한다. JavaScript는 버튼 클릭, 팝업 표시, 화면 변화 같은 동적인 동작을 담당한다. 서버에서 HTML과 CSS, JavaScript 파일을 함께 전달하면 브라우저는 이를 조합해 우리가 보는 웹 페이지를 만들어낸다.
• 백엔드는 사용자의 요청을 받아 적절한 데이터를 조회 및 가공해 다시 프론트엔드로 전달하는 역할을 한다. 사용자가 어떤 게시글을 보고 싶다고 요청하면, 백엔드는 데이터베이스에서 해당 정보를 가져와 HTML 형태로 만들어 응답한다. 이 과정에서 프론트엔드와 백엔드는 HTTP를 통해 유기적으로 연결된다.
• 브라우저에서 요소 검사 기능을 사용하면 HTML 구조를 확인할 수 있고, 이를 통해 뉴스 제목, 링크 같은 반복적인 데이터가 어떤 태그와 경로로 구성되어 있는지를 파악할 수 있다. 크롤링은 이 HTML 구조를 기반으로 동작하기 때문에, 어떤 데이터를 가져올지 사전에 명확히 정의하는 과정이 필요하다.

 

백앤드

 

웹 서비스의 백엔드는 기본적으로 웹 서버와 데이터베이스 서버로 구성된다. 서버의 역할은 크게 두 가지다.

첫째는 정보를 저장하는 것이고, 둘째는 저장된 정보를 사용자의 요청에 맞게 가공해 웹 페이지 형태로 전달하는 것이다. 데이터베이스는 사용자 정보, 게시글, 로그 같은 방대한 데이터를 저장하고 관리하며, 웹 서버는 사용자의 요청을 받아 데이터베이스에서 필요한 데이터를 가져와 HTML, CSS, 이미지 등의 형태로 클라이언트에게 전송한다. 

 

• 웹 서버는 클라이언트와 가장 가까운 앞단에서 요청을 받아 정적 리소스를 처리하고 동적 요청을 뒤로 넘기는 역할
  • 초기의 웹 서버는 매우 단순했다. Apache HTTP Server나 Nginx 같은 웹 서버는 브라우저로부터 HTTP 요청을 받으면, 서버에 존재하는 HTML·CSS·이미지 같은 정적 파일을 그대로 읽어 응답으로 내려주는 역할만 수행했다. 이 단계의 웹 서버는 “요청을 받아 파일을 전달하는 것”에 최적화된 존재였고, 빠른 응답과 안정적인 연결 처리에 강점이 있었다.
• WAS는 그 요청을 받아 애플리케이션 코드를 실행하는 실행 엔진
  • 하지만 사용자의 요청이 단순한 “페이지 요청”을 넘어 데이터 조회, 조건에 따른 처리, 사용자별 맞춤 응답으로 확장되면서 정적 파일만으로는 한계가 생겼다. 이때 등장한 것이 WAS.
  • Tomcat 같은 WAS는 웹 서버가 전달한 요청을 받아 내부의 애플리케이션 코드를 실행하고, 데이터베이스와 연동해 결과를 만든 뒤 다시 웹 서버 또는 클라이언트에게 응답을 돌려준다. WAS는 단순 전달이 아니라 비즈니스 로직 실행, 트랜잭션 관리, 세션 관리 같은 “애플리케이션 실행 환경”을 제공한다는 점에서 웹 서버와 본질적으로 다르다.
• WAS 위에서 애플리케이션을 효율적이고 일관되게 개발하도록 도와주는 개발 도구
  • 웹 프레임워크는 WAS 위에서 동작하면서 개발자가 웹 애플리케이션을 더 쉽게 만들 수 있도록 구조와 규칙을 제공하는 도구다.
  • URL 라우팅, 요청/응답 처리, 데이터 검증, 예외 처리 같은 반복적인 작업을 미리 정형화해 준다. 덕분에 개발자는 HTTP 처리나 서버 내부 동작을 일일이 신경 쓰지 않고, 비즈니스 로직 자체에 집중할 수 있다.
  • 중요한 점은 웹 프레임워크가 “서버 그 자체”는 아니라는 것이다. 실제로 네트워크 포트를 열고 요청을 받아들이는 역할은 여전히 WAS(예: Tomcat, Uvicorn)가 담당하고, 웹 프레임워크는 그 안에서 실행되는 애플리케이션 코드의 구조를 정의한다.
  • 웹 프레임워크는 웹 서버, 데이터베이스 연동, 스크립트 처리 같은 기능을 하나로 묶어 개발 생산성을 크게 높여준다.
  • 웹 프레임워크는 요청을 처리하는 애플리케이션 구조를 제공하고, WAS는 해당 프레임워크로 작성된 애플리케이션을 실제로 실행하고 관리하는 서버 환경이다.

[WAS]
 ├ 웹 요청 처리
 ├ 스크립트 실행
 ├ DB 연결
 ├ 트랜잭션
 └ 보안

[ Client ]
    ↓
[ Web Server (Nginx) ]
    ↓
[ WAS ]
    ↓
[ Web Framework ]
    ↓
[ Application Code ]
    ↓
[ Database ]

 

 

크롤링 라이브러리/프레임워크 비교

 

구분	BeautifulSoup	Scrapy	Selenium
성격	HTML 파서(Parser)	웹 크롤링 프레임워크	브라우저 자동화 도구
주 용도	정적 HTML 파싱	대규모·고속 크롤링	JS 렌더링 페이지
JS 처리	불가	불가	가능
비동기 처리	불가	가능	불가
속도	느림	매우 빠름	가장 느림
병렬 크롤링	불가	가능	불가
페이지네이션	수동 구현	자동 구조화 용이	수동
데이터 파이프라인	불가	Item / Pipeline	불가
robots.txt	불가	기본 지원	불가
대표 사용 예	간단한 HTML 분석	쇼핑몰·뉴스·카테고리 수집	SPA, 무한 스크롤

 

Scrapy는 대규모 크롤링, 스케줄링, 데이터 파이프라인 구성 등에서 강력한 기능을 제공하기 때문에, 실무적인 크롤링 작업에서는 BeuatifulSoup보다 더 적합하다.

• Spider(크롤링 로직)
• Item(수집 데이터 구조 정의)
• Pipeline(수집 후 데이터 정제·필터링·DB 저장)
• Logging, 통계, 에러 처리

추출한 데이터는 단순 출력뿐 아니라, Item 객체에 담아 yield함으로써 Scrapy 파이프라인으로 전달된다. 이 구조 덕분에 데이터가 하나씩 스트림 형태로 쌓이며, 이후 JSON 파일 저장이나 데이터베이스 적재 같은 후처리를 유연하게 확장할 수 있다. 

HTML 파일 분석	BeautifulSoup
정적 웹 대량 수집	Scrapy
JS 필수, 무한스크롤	Selenium
로그인 후 데이터	Selenium → Scrapy
속도·안정성 중요	Scrapy
단발성 크롤링	BeautifulSoup

 

웹 데이터 저작권, 크롤링 정책

 

웹 데이터 활용에서 가장 먼저 고려해야 할 것은 저작권 문제다. 

단순히 사이트 메인 주소나 특정 게시물 URL로 이동시키는 단순 링크·직접 링크는 보통 저작권 침해로 보지 않지만, 게시물 내용을 그대로 노출하거나 iframe으로 원본을 통째로 보여주는 프레임 링크·임베드 링크는 침해 소지가 크다. 

즉, 크롤링한 데이터를 재게시하는 행위는 매우 신중해야 하며, “원문으로 이동하는 링크 제공”이 상대적으로 안전하다.

크롤링 전에는 반드시 robots.txt를 확인해야 한다. robots.txt는 크롤러별 접근 허용 범위를 명시한 운영자의 공식 정책으로, 법적 강제력은 없지만 이를 무시하면 윤리적·법적 문제가 될 수 있다. 사이트마다 특정 게시판만 제한하거나, 딜레이를 요구하거나, 아예 전면 차단하는 등 정책이 다르다.

 

Scrapy

 

scrapy startproject 명령으로 프로젝트를 생성하면 기본적인 디렉토리 구조가 만들어진다.

여기에는 settings.py, spiders/, items.py, pipelines.py, 그리고 scrapy.cfg 같은 파일들이 포함된다.

프로젝트가 생성되면 기본 디렉토리 구조가 만들어지고, 크롤링할 내용을 정한 뒤에, 이러한 필드들은 items.py에서 Item 클래스로 미리 정의한다. 안하고 spiders/에서 진행해도 되지만, 이때, 데이터를 구조화해 두면 이후 처리와 저장이 수월해진다.

 

items.py

 

• items.py는 크롤링 결과로 수집하고 싶은 데이터의 구조를 정의하는 파일
  • ex) 게시글의 제목, 작성자, URL 같은 필드를 미리 선언해 두는 역할
• 이후 Spider가 데이터를 수집하면, 그 결과는 Item 형태로 정리되어 Pipeline으로 전달된다.
• 이렇게 완성된 Item들은 yield를 통해 차곡차곡 쌓이며, 크롤링 실행 시 콘솔 출력이나 파일 저장을 통해 결과를 확인할 수 있다. 

 

spiders/

 

어떤 사이트를 어떻게 크롤링할지에 대한 코드가 이곳에 작성된다.

Spider에서 크롤링의 시작 지점을 지정하는데, 이는 두 가지 방식이 있다.

• start_urls 리스트에 URL 문자열들을 직접 나열하는 방식
• start_requests 메서드를 정의해 URL과 콜백 함수를 함께 지정하는 방식 
  • 여러 시작 URL을 유연하게 관리할 수 있고, 사이트별로 다른 파서를 연결할 수 있다는 장점이 있다.
  • 페이지네이션 처리에서 URL 구조를 분석해 페이지 번호만 바꿔가며 여러 페이지를 순회하도록 Request를 반복 생성한다. 이렇게 하면 “1페이지부터 N페이지까지” 원하는 범위만큼 안정적으로 크롤링할 수 있다.

크롤링이 시작되면, 각 요청에 대해 콜백 함수(보통 parse)가 호출된다. 이 콜백 함수는 서버로부터 받은 response 객체를 인자로 받으며, 이 안에는 HTML 문서 전체가 들어 있다. 개발자는 이 response를 분석해 필요한 데이터를 추출하게 된다.

이때 사용하는 도구가 Selector이며, Scrapy는 두 가지 선택 방식을 제공한다. 하나는 XPath, 다른 하나는 CSS Selector다.

• XPath: HTML 구조를 트리 형태로 따라가며 노드를 선택하는 방식
• CSS Selector: 웹 프론트엔드에서 사용하는 선택자 문법과 유사해 직관적

태그가 여러 개일 경우 결과는 리스트 형태로 반환되며, .extract() 또는 .getall() 같은 메서드를 통해 실제 문자열 데이터를 얻는다. 이미지 태그, 링크 태그처럼 중첩된 구조에서도 XPath나 CSS Selector 조건을 잘 조합하면 원하는 데이터만 정확히 뽑아낼 수 있다.

이렇게 Selector로 추출한 데이터는 Item 객체에 담겨 yield 되고, 이후 Pipeline으로 전달된다.

실제 데이터 추출 과정에서는 브라우저의 요소 검사를 통해 HTML 구조를 분석하고, 게시글 한 줄을 감싸는 tr 태그를 기준으로 반복 처리한다. 각 tr 안에서 XPath를 이용해 제목, 링크, 날짜, 조회수 등을 하나씩 추출해 Item에 채워 넣는다.

 

pipelines.py

 

• 크롤링이 끝난 뒤의 후처리 단계를 담당
• 중복 검사, 필터링, DB 저장 작업 수행
• 수집 → 가공 → 저장이 명확히 분리된 파이프라인 구조
•  여기서 데이터의 유효성을 검사하거나, 중복 데이터를 제거하거나, 데이터베이스에 저장하는 등의 작업을 수행할 수 있다. 또한 특정 조건에 맞지 않는 아이템을 필터링해 버리는 것도 Pipeline에서 처리한다.
• Pipeline은 여러 개를 만들 수 있으며, 실행 순서는 settings.py에서 숫자로 지정한다. 숫자가 낮을수록 먼저 실행되기 때문에, 예를 들어 “중복 제거 → DB 저장” 같은 순서를 명확히 제어할 수 있다.
• 특정 단어가 포함된 게시글을 필터링하는 Pipeline을 만들고, 금지 단어 목록에 해당하는 제목이 들어오면 DropItem 예외를 발생시켜 데이터를 버리도록 구현할 수 있다. 

ITEM_PIPELINES = {
   "books_scraper.pipelines.BooksScraperPipeline": 300,
}

 

settings.py

 

• 프로젝트 전체 설정
• 어떤 Pipeline을 사용할지, 로그 파일은 어디에 저장할지, 로그 레벨은 어느 정도로 할지
• 로그 파일의 경로와 로그 레벨 역시 settings.py에서 지정할 수 있으며
• 로그 레벨은 DEBUG, INFO, WARNING, ERROR, CRITICAL의 단계로 나뉜다. 

LOG_LEVEL = "INFO"

 

scrapy.cfg

• 프로젝트 배포나 실행과 관련된 메타 설정 파일
• Scrapy가 이 프로젝트를 하나의 작업 단위로 인식하도록 돕는다.

 

 

참고

 

https://python-world.tistory.com/entry/Simple-Scrapy

https://www.inflearn.com/course/%EC%9B%B9-%ED%81%AC%EB%A1%A4%EB%A7%81web-crawling-%EC%96%B4%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98-%EB%A7%8C%EB%93%A4%EA%B8%B0/dashboard

https://docs.scrapy.org/en/latest/topics/items.html