LLM·RAG 지식베이스용 웹 크롤러로 HTML을 정제해 마크다운으로 변환하는 도구

작성자가 벤치마크 수치와 구현 스택을 함께 제공했기 때문에 게시물은 실무적 관심을 끌었다. 공개된 Apify Actor 링크로 인해 바로 테스트할 수 있다는 점이 긍정적인 피드백 근거로 작용했다. 반면 재현성, 특정 사이트 구조에서의 한계, 대규모 비정형 문서에 대한 적용성 등 추가 검증을 요구하는 의견도 예상되는 분위기이다.

• 크롤링 단계에서 비동기 처리 프레임워크인 asyncio를 사용해 네트워크 IO를 병렬화하면 여러 페이지를 효율적으로 수집할 수 있으며 이는 전체 파이프라인의 처리 속도를 크게 개선한다. trafilatura를 본문 추출기로 사용하면 네비게이션 바나 배너 등 HTML 잡음을 보다 효과적으로 분리해낼 수 있으므로 후속 임베딩 품질 향상에 기여한다. 수집된 텍스트는 MarkdownTextSplitter와 같은 마크다운 특화 분할기로 넘겨 토큰 낭비를 줄이고 RAG 검색 정확도를 높여야 한다.
• 대규모 문서 사이트를 처리할 때는 크롤링 비용과 토큰 비용을 분리해서 평가해야 하며, 원문 사례처럼 페이지 수와 실제 처리 비용을 벤치마크해 비용-효율성을 정량적으로 검증하는 절차가 필요하다. 크롤러 실행 시 불필요한 리소스(이미지, 비디오, 스크립트)를 최소화하고 텍스트만 추출하는 옵션을 활용하면 전송 비용과 저장 비용을 줄일 수 있다. 또한 크롤링 결과를 검증용 샘플셋으로 먼저 처리해 마크다운 변환 품질을 점검하면 전체 파이프라인 오류를 조기에 발견할 수 있다.
• 완성된 파이프라인을 Apify 같은 플랫폼에 Actor 형태로 배포하면 인프라 구성 부담을 줄이고 재현 가능한 실행 환경을 제공할 수 있다. 외부에서 접근 가능한 Actor는 팀 내 공유와 피드백 수집을 용이하게 하며, 테스트 기반으로 전처리 규칙을 개선할 수 있는 운영적 이점을 제공한다. 다만 플랫폼별 비용 구조와 실행 제한을 사전에 확인해 지속적 사용의 비용 효과를 따져야 한다.

TextSplitter

— 문서나 마크다운을 LLM의 컨텍스트 윈도우에 맞춰 일정 길이의 청크로 나누는 도구로서 입력 토큰 수와 문맥 일관성에 직접 영향을 미친다. 입력 텍스트를 문장 경계나 토큰 수 기준으로 분할하고 각 청크를 임베딩·검색용으로 저장하는 과정이 핵심이다. 분할 방식에 따라 임베딩 품질과 검색 정확도가 달라져 RAG 파이프라인 성능에 결정적이다.

HTML noise

— 네비게이션 바, 푸터, 쿠키 배너, 스크립트 태그 등 문서 본문과 무관한 HTML 요소로서 토큰 낭비와 임베딩 왜곡을 초래한다. 이러한 요소는 텍스트 전처리 단계에서 제거되지 않으면 TextSplitter와 임베딩 생성 과정에서 불필요한 컨텍스트로 작용한다. 잡음 제거는 임베딩 품질을 높이고 RAG 시스템의 환각률을 낮추기 위해 필수적이다.

Context window

— LLM이 한 번에 참조할 수 있는 최대 토큰 범위를 의미하며 문서 청크 크기와 검색 전략을 결정한다. 컨텍스트 윈도우를 초과하는 텍스트는 외부 검색·요약·분할로 처리해야 하므로 토큰 효율성이 중요해진다. RAG 파이프라인에서는 검색된 문서 조각들이 이 윈도우 안에 적절히 배치되어야 응답 품질과 비용 효율이 유지된다.

Embeddings

— 문장이나 문서 조각을 고정 길이 벡터로 변환하는 표현 방식으로 검색·유사도 계산의 기초가 된다. 원문에서 불필요한 HTML 잡음이 포함되면 벡터가 왜곡되어 검색 결과가 부정확해지고 RAG 응답의 질이 저하된다. 임베딩 품질 관리는 전처리·토크나이제이션·모델 선택 측면에서 다각도로 접근해야 한다.