RSS 파이프라인

RSS 파이프라인

RSS 수집·중복제거·가공·저장을 자동화하는 구조는 어떻게 설계하는가.

Scope

핵심 질문

RSS 수집부터 중복제거·가공·저장까지 안정적인 파이프라인을 어떻게 구성하는가?

Research

핵심 근거

• RSS/Atom item에는 guid/id가 있을 수 있지만 모든 feed가 안정적인 identifier를 제공하지는 않는다.
• 중복제거는 guid, canonical URL, content hash 등을 조합할 수 있다.
• 외부 feed 장애와 downstream 처리 실패를 분리하면 재시도가 쉬워진다.

참고 자료

• RSS 2.0 specification: https://www.rssboard.org/rss-specification

Draft

RSS 파이프라인은 feed를 주기적으로 읽고 새로운 item을 판별해 가공한 뒤 저장하거나 다른 시스템으로 전달하는 데이터 흐름이다.

수집

가장 먼저 feed 자체의 마지막 성공 시각과 HTTP 상태를 기록하는 것이 좋다. 일시적인 5xx나 timeout은 정상적인 외부 장애로 취급하고 재시도할 수 있어야 한다.

중복제거

가능하면 item의 guid/id를 사용한다. 하지만 feed마다 구현품질이 달라 URL, publication time, title, content hash를 보조키로 사용할 수 있다.

중복제거 상태는 workflow 실행이력과 분리된 영속 저장소에 두는 편이 안정적이다.

처리단계 분리

수집, 본문 fetch, LLM 요약, 번역, 저장을 각각 독립 단계로 만들면 특정 단계 실패 시 전체 feed를 다시 읽을 필요가 없다.

Queue나 상태 table에 item 단위 상태를 저장하면 재시도와 병렬처리도 쉬워진다.

Idempotency

같은 item이 다시 들어와도 동일한 결과를 덮어쓰거나 무시할 수 있어야 한다. 외부 서비스 호출처럼 비용이 발생하는 단계는 처리완료 상태를 먼저 확인한다.

핵심

안정적인 RSS 파이프라인의 핵심은 feed parsing보다 item identity와 단계별 상태관리다. 수집과 가공을 분리하고 모든 단계가 재시도 가능하게 만들어야 운영이 쉬워진다.