웹은 사람이 직접 브라우저로 탐색하는 것뿐만 아니라 프로그램이 자동으로 탐색하기도 한다. 이 자동 탐색 프로그램을 웹 로봇(Web Robot), 혹은 크롤러(Crawler), 스파이더(Spider)라고 부른다. 검색 엔진의 핵심은 바로 이 로봇이며 단순 데이터 수집부터 자동화 트랜잭션까지 다양한 분야에서 활용된다. 하지만 로봇은 잘못 설계되면 서버에 부하를 주거나 민감한 데이터를 노출시킬 수도 있다.
이번 장에서는 웹 로봇의 개념, 동작 원리, 규칙, 문제점과 차단 방법까지 정리했다.
웹 로봇(Web Robot)
웹 로봇은 사람 대신 웹을 탐색하는 자동화 프로그램이다. 브라우저처럼 HTTP 요청을 보내지만 사용자가 직접 클릭하지 않아도 규칙에 따라 자동으로 동작한다.
- 검색 엔진 로봇(Googlebot, Naverbot 등): 웹 페이지를 수집해 검색 인덱스를 만든다.
- 데이터 마이닝 로봇: 뉴스/상품/소셜 데이터를 자동으로 수집한다.
- 사이트 관리 로봇: 링크 깨짐 탐지, 모니터링, 보안 검사 등을 수행한다.
- 트랜잭션 로봇: 항공권 예약, 가격 비교, 티켓팅 자동화처럼 실제 행동을 수행한다.
핵심은 로봇은 자동화된 HTTP 클라이언트이다.
크롤링과 인덱싱
- 크롤링(Crawling): 웹을 따라다니며 링크를 수집하고 문서를 모으는 과정
- 인덱싱(Indexing): 수집한 문서를 분석하고 검색용으로 구조화하는 과정
즉, 크롤링은 모으기, 인덱싱은 정리하기이다.
검색 엔진 동작 흐름
[크롤링] 웹 페이지 수집 → [인덱싱] 색인 생성 → [검색] 사용자가 질의 시 색인에서 검색웹 로봇의 동작 원리
로봇은 다음과 같은 순환 구조로 작동한다.
- Seed URL 목록에서 시작
- 해당 URL에 HTTP 요청 → HTML 문서 수신 후 파싱
- 문서에서 새 링크 추출 → Frontier(대기 큐)에 추가
- 이미 방문했는지 검사 → 방문하지 않은 경우만 실행
- 이 과정을 반복
[Seed URL]
↓
[Fetch & Parse]
↓
[Extract Links]
↓
[Frontier Queue] → [Check Visited?] ──No──→ [다음 방문]
└─Yes─┘이 순환 과정을 통해 로봇은 웹 전체를 점진적으로 탐색해 나간다.
Frontier(방문 후보 큐) 설계 이슈
Frontier는 "다음에 방문할 URL"을 관리하는 큐다. 단순히 넣고 빼는 것 이상으로 설계 전략이 중요하다.
- URL 중복 제거: 동일 페이지를 여러 번 긁지 않도록 방문 집합(visited set) 유지
- 우선순위 정책
- 인기 페이지(많이 링크된 페이지)를 먼저 방문
- 깊이 제한(Depth limit)으로 너무 깊은 경로는 탐색하지 않음
- 도메인별 균형: 특정 사이트만 집중 크롤링하지 않고 여러 사이트를 고르게 방문
Frontier 전략이 검색 품질과 서버 부하에 직접적인 영향을 준다.
로봇이 지켜야 할 규칙
웹 로봇이 제멋대로 동작하면 서비스 장애나 정보 유출이 발생할 수 있다. 따라서 로봇은 반드시 예의 있는 크롤링(Polite Crawling)을 실천해야 한다.
1. robots.txt (Robots Exclusion Protocol)
서버 루트에 위치한 robots.txt 파일은 “이 경로는 긁지 마라”라는 규약이다. 보안 장치는 아니며, 선량한 로봇만 이를 따른다.
예시 (https://example.com/robots.txt)
User-agent: *
Disallow: /private/
Allow: /public/User-agent: 어떤 로봇에 적용할지Disallow: 접근 금지 경로Allow: 접근 허용 경로
robots.txt의 한계
강제력이 없고 악성 로봇은 무시할 수 있다.
오히려 민감한 디렉토리 위치를 노출시키는 단서가 되기도 한다.
2. User-Agent 헤더
로봇은 반드시 자신을 밝히는 User-Agent 헤더를 넣어야 한다.
GET /index.html HTTP/1.1
Host: example.com
User-Agent: MyCrawler/1.0이를 통해 서버 관리자는 트래픽을 분석하고 필요시 특정 로봇을 차단할 수 있다.
3. 요청 속도 제어
로봇은 서버에 과부하를 주지 않도록 요청 간격을 둬야 한다.
- 병렬 요청 수 제한
- 일정한 지연 시간 삽입
crawl-delay옵션 준수
이를 지키지 않으면 정상적인 사용자 접속을 방해하고 서비스 거부 공격(DoS)처럼 보일 수 있다.
트래픽과 부하 관리
웹 로봇은 대규모 요청을 보낼 수 있기 때문에 잘못 설계되면 서비스 거부(DoS) 상황을 초래할 수 있다. 검색 엔진 같은 대형 로봇들은 분산 크롤링, 요청 스케줄링, 캐시 활용 등 다양한 전략으로 서버에 부담을 최소화한다. 반대로 조율되지 않은 로봇은 정상적인 사용자의 접속을 방해할 수 있어 관리자가 반드시 모니터링해야 한다.
부적절한 로봇의 문제
- 스팸봇: 게시판, 블로그 등에 광고 글 자동 등록
- 이메일 수집기: 페이지에서 이메일 주소만 긁어 스팸 메일 발송에 활용
- 가격 크롤러: 전자상거래 사이트에서 가격만 무단 수집해 경쟁사 비교용으로 사용
- 과부하 크롤러:
robots.txt무시 + 무차별 요청 → 서비스 불능 상태 유발
검색 로봇의 전략
검색 엔진 로봇은 단순히 긁어오기만 하는 게 아니라 효율적인 탐색 정책을 가진다.
- 탐색 방식
- 깊이 우선(DFS): 링크를 따라 깊게 들어가 탐색
- 너비 우선(BFS): 모든 링크를 일정 깊이까지 폭넓게 탐색
- 재방문 정책
- 페이지 갱신 빈도를 학습해서, 자주 바뀌는 페이지는 더 자주 방문
- 예: 뉴스 사이트(수 분 단위) vs 소개 페이지(몇 달 단위)
- 중복 콘텐츠 제거
- 동일하거나 유사한 페이지는 하나로 취급
- canonical 태그를 활용해 대표 URL만 인덱싱
검색 로봇 vs. 트랜잭션 로봇
| 구분 | 특징 | 예시 |
|---|---|---|
| 검색 로봇 | 콘텐츠를 수집해 검색 인덱스 생성 | Googlebot |
| 트랜잭션 로봇 | 사용자를 대신해 특정 행동 수행 | 항공권 가격 비교, 예약 자동화 |
로봇 차단 방법
robots.txt로 크롤링 범위 제한robots메타 태그 (<meta name="robots" content="noindex, nofollow">)- 로그인/세션 인증 적용
- 트래픽 모니터링 후 특정 User-Agent/IP 차단
📝 배운점
이번 장을 통해 웹 로봇이 단순히 데이터를 긁어오는 도구에 그치지 않고 검색, 자동화, 운영까지 아우르는 웹 생태계의 핵심 인프라라는 사실을 배웠다. 특히 robots.txt와 User-Agent는 서버와 로봇이 서로를 존중하며 동작하기 위한 신뢰 협약이라는 점이 인상 깊었다. 하지만 이는 어디까지나 권고 사항일 뿐 악성 로봇은 이를 무시할 수 있다는 한계도 존재한다.
또한 Frontier 설계, 재방문 정책, 중복 제거 등 검색 엔진 로봇의 내부 전략을 알게 되면서 단순히 URL을 순회하는 수준을 넘어 “어떻게 하면 효율적으로 수집하면서도 서버에 부담을 최소화할 수 있을까”라는 고민이 필요하다는 점을 배웠다. 앞으로 내가 크롤러를 구현하거나 외부 로봇의 접근을 허용할 때도 이러한 원칙을 반드시 준수해 서비스 안정성과 보안을 동시에 확보해야겠다고 느꼈다.
참고
