RSS → LLM → 저장 파이프라인을 제대로 만드는 법

Scope

핵심 질문

RSS item을 수집해 LLM으로 요약·번역하고 저장하는 파이프라인을 재시도와 중복 없이 어떻게 구성하는가?

Research

핵심 근거

RSS 수집과 원문 fetch, LLM 처리, 저장은 실패 특성이 서로 다르므로 단계별 상태를 분리해야 한다.
LLM 호출은 비용이 발생하므로 item identity와 처리완료 상태를 먼저 확인해야 한다.
prompt version과 model version을 저장하면 재처리 결과를 추적하기 쉽다.

Draft

RSS → LLM → 저장 흐름에서 가장 중요한 것은 LLM prompt보다 item 단위 상태관리다.

1. 수집

Feed를 읽어 guid, URL, publication time을 기준으로 새로운 item을 등록한다. 이 단계에서는 아직 LLM을 호출하지 않는다.

2. 원문 fetch

원문이 필요할 때만 article URL을 가져와 본문을 추출한다. feed URL은 비신뢰 입력이므로 HTTP(S)와 허용된 공개 목적지·포트만 허용하고 모든 DNS 응답 IP에서 내부·loopback·link-local·metadata 대상을 차단한다. 검사 이후 클라이언트가 hostname을 다시 해석해 연결하면 우회될 수 있다. 실제 요청은 검증한 공개 IP로 연결을 고정하고 원래 hostname의 HTTP Host, TLS SNI 및 인증서를 검증해야 한다. 자동 redirect를 끄고 매 Location, 재시도와 대체 연결에도 같은 검사와 연결 고정을 반복하며 hop·시간·응답 크기·egress를 제한한다. 이 연결 보장을 제공할 수 없으면 원문 자동 fetch를 하지 않는다. 거부한 URL은 민감정보 없이 기록한다. robots, paywall, timeout 등 fetch 실패는 RSS 수집 성공과 별도 상태로 기록한다. OWASP SSRF 예방 지침을 참고한다.

3. LLM 처리

원문이 확보된 item만 요약·번역한다. 가져온 기사와 feed 텍스트는 출처가 있는 비신뢰 자료로 구분해 모델에 전달하고, 그 안의 지시가 도구 호출·새 URL 접근·권한 변경이나 쓰기 작업을 승인하지 못하게 실행환경에서 강제한다. 결과에는 원문 링크와 근거를 남기고, prompt template과 model version을 함께 저장하면 나중에 선택적으로 재처리할 수 있다.

4. 저장

최종 결과를 upsert 방식으로 저장하면 같은 item을 다시 처리해도 중복 row가 생기지 않는다.

재시도

fetch 실패와 LLM rate limit은 재시도 전략이 다르다. 모든 단계를 하나의 workflow retry로 묶기보다 item 상태별로 재시도하는 편이 안전하다.

핵심

이 파이프라인은 하나의 직선 workflow가 아니라 상태머신으로 보는 것이 좋다. 새 item, fetched, processed, stored, failed 상태를 명확히 두면 중복비용과 복구문제가 크게 줄어든다.