핵심 요약 정적·반복 페이지는 전통 크롤러가 더 빠르고 정확하며, 브라우저 에이전트는 로그인·동적 UI처럼 전통 크롤러가 실패하는 구간에서만 검토 대상이다. 요약은 수집·정제 단계와 분리해 주장-근거 구조로 설계해야 사실 오류와 비용을 동시에 줄일 수 있다. 성공률은 ‘생산 품질’과 다르므로, 평가는 요약문 하나가 아니라 수집부터 검증까지 단계별로 측정해야 한다.

크롤링 후 요약 자동화, 어디서부터 함정이 시작될까?

함정은 대부분 "일단 에이전트에게 페이지를 맡기고 요약까지 통째로 시킨다"는 선택에서 시작된다. 2026년 공개된 35개 사이트 벤치마크를 보면, 단순 HTML 추출에서 BeautifulSoup는 93%, Scrapy는 82% 성공률을 기록했고 처리 시간은 2초 미만이었다. 반면 Claude와 Simular.ai 에이전트는 성공률 100%였지만 10~20초가 걸렸다. 정적 페이지에 에이전트를 붙이면 성능은 큰 차이가 없는데 실행 시간만 15~20배 늘어날 수 있다(출처).

  • 정적·반복 페이지는 전통 크롤러를 기본값으로 둔다
  • 로그인·동적 UI·보호 페이지에서만 에이전트를 검토한다
  • 수집과 요약은 분리된 단계로 설계한다
  • 요약 출력은 주장-근거 구조로 고정해 검증 가능하게 만든다
  • 비용은 모델 호출료가 아니라 ‘유효 레코드당 총비용’으로 계산한다

흔한 함정은 "뉴스 100개 긁어서 각각 요약해줘" 같은 작업을 에이전트 하나에 통째로 맡기는 설계다. 이 경우 정적 페이지 비중이 높아도 에이전트가 매 페이지마다 DOM을 다시 해석하면서 시간과 토큰이 선형으로 늘어난다. 게다가 요약까지 같은 호출에서 처리하면 수집 실패와 요약 실패를 구분할 수 없어, 문제가 생겼을 때 어느 단계가 원인인지 추적하기 어렵다.

정적 페이지에도 브라우저 에이전트를 써야 할까?

필요하지 않다. 정적 HTML 페이지는 전통적 크롤러만으로 93%(BeautifulSoup), 82%(Scrapy) 수준의 성공률을 2초 미만에 달성하므로, 같은 결과를 10~20배 느린 에이전트로 다시 확인할 이유가 적다(출처). 에이전트가 의미 있어지는 지점은 로그인·동적 UI·보호 페이지다. 같은 벤치마크에서 Simular.ai는 단순 인증 페이지 63%, 복잡한 인증 페이지 70% 성공률을 보였지만 CAPTCHA 페이지에서는 성공률이 낮았다. 즉 "에이전트가 더 똑똑하다"는 이유로 모든 페이지를 에이전트에 맡기면, 실제로는 보호 수준이 낮은 페이지에서 불필요한 지연과 비용만 추가된다. 페이지 유형별로 분기하는 규칙—정적은 전통 크롤러, 동적은 Playwright/Selenium, 로그인·복잡한 상호작용만 브라우저 에이전트—을 먼저 세우는 편이 안전하다.

요약 전에 꼭 거쳐야 하는 단계는 무엇일까?

LLM을 바로 호출하지 않고 수집과 요약을 분리하는 파이프라인이다. 권장 순서는 URL 범위 제한 → robots.txt·이용약관 확인 → HTML 수집 → 본문·제목·날짜 추출 → 중복 제거 → 구조화 저장 → 요약 → 근거 검증이다(출처). 요약 모델에 넘기는 입력도 원문 전체가 아니라 정제된 문서 객체로 고정해야 한다. 최소 필드는 url, title, published_at, author, source_domain, main_text, retrieved_at, content_hash이며, 중복 제거에는 콘텐츠 해시를 사용하고 페이지 수·깊이·URL 정규화로 크롤링 범위를 제한하는 설계가 재현 가능한 테스트베드에 쓰였다(출처). 이 단계를 생략하고 원문 전체를 통째로 요약 모델에 넣으면 토큰 비용이 커질 뿐 아니라, 어느 문장이 어느 출처에서 왔는지 추적이 끊겨 검증이 어려워진다.

반복되는 목록 페이지는 매번 에이전트로 다시 읽어야 할까?

그럴 필요는 크지 않다. WebLists 연구는 50개 웹사이트, 200개 데이터 추출 작업으로 구성됐는데, 재사용 가능한 선택자 기반 방식(BardeenAgent)의 전체 recall은 66%, precision은 72%로, 기존 최고 성능 웹 에이전트보다 recall이 36% 개선됐고 출력 행당 비용은 3배 낮았다(출처). 구조가 반복되는 페이지—상품 목록, 뉴스 리스트, 게시판—라면 한 번 선택자를 정의해두고 재사용하는 편이, 매번 에이전트가 레이아웃을 다시 해석하는 것보다 비용과 재현성 측면에서 유리하다. 에이전트는 구조가 자주 바뀌거나 처음 보는 사이트에서 빛을 발하지, 이미 패턴이 파악된 반복 작업에서는 추가 비용만 쌓이기 쉽다.

요약 결과를 어떻게 설계해야 검증하기 쉬울까?

‘요약문’보다 ‘주장-근거 구조’를 요구하는 출력 스키마가 검증에 유리하다. 실사용 스키마는 summary, key_points(claim·evidence_quote·source_url), uncertainties, not_found 필드로 제한하는 편이 좋다. 여기에 원문에 없는 수치·날짜·인과관계를 만들지 말 것, 확인되지 않은 항목은 not_found에 기록할 것, 각 핵심 주장에 URL 또는 문서 구간을 연결할 것, 의견과 사실을 분리할 것 같은 금지 조건을 명시해야 한다. 크롤링 후 요약 연구에서는 사실성·문맥 관련성·필드 정확도와 함께 사람 검증을 병행하며, 단일 ROUGE 점수로 품질을 판단하지 않고 주장별 근거 일치 여부를 따로 검사한다(출처). 이 구조가 없으면 요약이 매끄러워 보여도 원문에 없는 내용이 섞였는지 확인할 방법이 없다.

에이전트 성공률이 높으면 바로 운영에 써도 될까?

성공률과 생산 품질은 다른 지표라서, 높은 성공률만 보고 바로 운영에 투입하는 건 오해다. MacroBench는 681개 작업과 2,636회 모델-작업 실행을 평가했고, GPT-4o-mini 96.8%, GPT-4o 95.3%, Gemini 89.0%, DeepSeek 83.4%의 기능 성공률을 보고했다. 그런데 단순 작업 성공률은 91.7%로 높았던 반면, 복잡한 워크플로—로그인 후 필터 변경, 페이지 이동, 전체 목록 추출 같은 다단계 작업—에서는 성공률이 0%까지 떨어졌고, 기능적으로 완료된 경우에도 생산 수준의 코딩 관행을 충족한 모델은 없었다(출처). 즉 "간단한 페이지에서 95% 성공했다"는 숫자를 복잡한 크롤링·요약 워크플로 전체의 신뢰도로 확대 해석하면 운영 위험을 숨기게 된다. 단순 작업과 복잡한 작업의 평가 셋을 반드시 분리해서 봐야 한다.

크롤링 후 요약, 실제 비용은 어떻게 계산해야 할까?

모델 호출료만 보면 실제 비용을 과소평가하게 된다. Zyte의 2025 산업 보고서는 GPT-3.5 기반 추출이 자사 비LLM 방식보다 최대 50배 비쌌다고 보고했다(출처). 여기에 브라우저 실행, 프록시, CAPTCHA·차단 재시도, 저장·검증 비용까지 더해야 하며, 비교 기준은 총비용 ÷ 유효하게 검증된 레코드 수로 잡는 편이 현실적이다. 평가 항목으로는 페이지 수집 성공률, 필드별 precision·recall·F1, 중복률, 요약의 근거 포함률, 사실 오류율, 누락률, 처리 시간, 페이지당 비용, 재시도율을 함께 기록해야 한다(출처). 자동화에 맡길 단계는 HTML 수집, 본문 정제, 중복 제거, 형식 변환, 1차 요약, 근거 링크 첨부이고, 법적·의학적·재무적 결론, 상충하는 출처의 조정, 발행일·저자·수치의 최종 승인은 사람이 확인하도록 남겨야 한다. 모델명, API 버전, 프롬프트 버전, 크롤러 라이브러리, 실행일, 대상 도메인, 인증 상태, CAPTCHA 여부, 입출력 토큰은 함께 기록해야 "2026년 기준, 어떤 버전에서 나온 결과인지"를 나중에 재현할 수 있다.

핵심 정리

  • 정적·반복 페이지는 전통 크롤러(BeautifulSoup 93%, Scrapy 82%, 2초 미만)를 우선 검토한다
  • 브라우저 에이전트는 로그인·동적 UI·보호 페이지처럼 전통 크롤러가 약한 구간에만 투입한다
  • 요약은 수집·정제와 분리하고, 입력은 정제된 문서 객체·출력은 주장-근거 구조로 고정한다
  • 에이전트 성공률(단순 작업 91.7%, 복잡한 워크플로 0%)은 생산 품질과 동일하지 않다
  • 비용은 모델 호출료가 아니라 총비용 ÷ 유효 검증 레코드 수로 계산한다