콘텐츠 자동화의 첫 단추는 소재 수집입니다. 자산·금융 뉴스를 다루는 이 시스템은 여섯 개 매체에서 기사를 긁어 와야 했는데, 매체마다 사이트 구조와 렌더링 방식이 제각각이었습니다. 소스가 여섯이라고 크롤러를 여섯 벌 따로 짜면 매체가 늘 때마다 코드가 같이 늘어나고 유지보수가 곧 감당이 안 됩니다. 이 문제를 팩토리 패턴으로 풀었습니다.
정적 사이트와 동적 사이트를 가른다
먼저 수집 방식을 두 갈래로 나눴습니다. 서버가 HTML을 완성해서 내려주는 정적 사이트는 Cheerio로 파싱합니다. 브라우저를 띄우지 않고 HTML만 받아 선택자로 긁으니 빠르고 가볍습니다. 반대로 자바스크립트로 목록과 본문을 그려 내는 사이트는 Cheerio로는 빈 껍데기만 잡히므로 Playwright로 실제 브라우저를 띄워 렌더링이 끝난 화면에서 수집합니다.
여섯 매체를 이 기준으로 갈라 보니 대부분은 Cheerio로 충분했고 스크립트 의존이 강한 몇 곳만 Playwright가 필요했습니다. 무거운 브라우저 방식을 꼭 필요한 소스에만 쓰니 전체 수집이 빨라지고 자원도 아꼈습니다.
전용 크롤러와 범용 크롤러
수집 전략만으로는 부족했습니다. 같은 Cheerio라도 매체마다 목록 페이지의 생김새와 본문 선택자가 다르기 때문입니다. 그래서 소스 아이디에 맞는 전용 크롤러가 있으면 그것을 쓰고 없으면 수집 전략에 따라 범용 크롤러로 떨어지는 팩토리를 만들었습니다.
팩토리는 소스 정보를 받아 크롤러 인스턴스를 돌려주는 하나의 함수입니다. 전용 크롤러 목록에 아이디가 있으면 그 클래스로 만들고 없으면 Cheerio냐 Playwright냐에 따라 범용 크롤러를 만듭니다. 매체를 붙이는 방법이 두 가지로 정리됐습니다. 구조가 특이하면 전용 크롤러 클래스를 하나 추가하고 평범하면 소스만 등록하면 됩니다. 어느 쪽이든 팩토리와 파이프라인의 다른 코드는 건드리지 않습니다.
공통 뼈대는 베이스 크롤러에
전용이든 범용이든 모든 크롤러는 하나의 베이스 크롤러를 상속합니다. 베이스는 수집의 공통 흐름을 정의합니다. 목록을 파싱해 후보 링크를 뽑고 이미 수집한 링크는 걸러 내고 남은 항목의 본문을 하나씩 파싱하는 순서입니다. 각 크롤러는 목록 파싱과 본문 파싱이라는 두 부분만 자기 매체에 맞게 구현하면 됩니다.
이미 수집한 링크를 걸러 내는 로직을 베이스에 두니 중복 수집이 소스와 무관하게 한곳에서 처리됩니다. 상대 경로 링크를 절대 경로로 바꾸는 것처럼 매체를 가리지 않는 잡일도 베이스가 맡아, 개별 크롤러는 정말 그 매체에만 해당하는 선택자 로직에 집중합니다.
한 곳이 막혀도 전체는 돈다
수집에서 가장 흔한 사고는 한 매체의 사이트 개편이나 일시 장애로 크롤러가 멈추는 일입니다. 이때 전체 수집이 함께 죽으면 그날 콘텐츠 생산이 통째로 밀립니다. 그래서 본문 파싱 단계의 실패를 항목 단위로 잡아 에러 목록에 담고 나머지 항목은 계속 처리하게 했습니다. 매체 단위로도 연속 실패 횟수를 기록해, 어느 소스가 반복해서 문제를 일으키는지 골라낼 수 있게 했습니다.
이렇게 실패를 격리해 두면 한 매체가 개편돼도 그 소스만 수집이 빠지고 나머지는 평소처럼 돕니다. 어느 소스가 왜 멈췄는지는 기록으로 남으므로, 문제를 나중에 몰아서 고쳐도 그 사이 콘텐츠 생산은 이어집니다.
수집 다음은 생성
이렇게 모은 기사는 원본으로 쌓이고 그다음부터는 AI 파이프라인이 이어받아 토픽을 고르고 글을 씁니다. 수집과 생성을 잇는 전체 그림은 AI SEO 콘텐츠 생성·발행 자동화 사례에, 수집된 기사가 어떻게 콘텐츠가 되는지는 AI 콘텐츠 생성 5단계 파이프라인 설계에 정리했습니다.
자주 묻는 질문
Cheerio와 Playwright는 어떻게 나눠 쓰나요?
서버가 HTML을 완성해 내려주는 정적 사이트는 Cheerio로 파싱하고 자바스크립트로 화면을 그려 내는 동적 사이트는 Playwright로 브라우저를 띄워 수집합니다. 무거운 브라우저 방식은 꼭 필요한 소스에만 쓰는 편이 전체 수집 속도와 자원 면에서 유리합니다.
새 매체를 추가하려면 무엇을 해야 하나요?
구조가 특이한 매체는 베이스 크롤러를 상속한 전용 크롤러를 하나 추가하고 평범한 매체는 소스 정보만 등록하면 팩토리가 알아서 범용 크롤러로 처리합니다. 어느 쪽이든 팩토리와 파이프라인의 나머지 코드는 수정하지 않습니다.
한 매체가 사이트를 개편하면 수집이 다 멈추나요?
아니요. 실패를 항목과 소스 단위로 격리해 두어, 문제가 생긴 매체만 그날 수집에서 빠지고 나머지는 계속 돕니다. 어떤 소스가 왜 실패했는지는 기록에 남아 나중에 몰아서 복구할 수 있습니다.