5개월간 아무도 몰랐던 죽은 RSS 피드 2개

배경

Project Lighthouse는 내가 운영하는 콘텐츠 파이프라인으로, 몇 개의 RSS 피드와 학술 논문 검색에서 소스 자료를 가져와 특정 주제 영역과의 관련성을 필터링하고, 유망한 항목을 검토용 큐에 넣는다. 뭔가 발견되지 않는 한 사람 개입 없이 스케줄대로 돌아간다.

증상

파이프라인 실행 이력을 확인했다: 약 5개월에 걸쳐 연속된 다섯 번의 예약 실행 전부 new_items: 0으로 기록돼 있었다. 출력 큐는 그 내내 빈 배열이었다.

왜 아무도 눈치채지 못했나

설계상 이 파이프라인은 아무것도 발견하지 못하면 조용히 있는다 — 알림 이메일도, 경고도 없이 그냥 로그 한 줄뿐이다. "오늘은 새로운 게 없다"가 완전히 정상적이고 흔한 결과인 우선순위 낮은 발굴 파이프라인에는 합리적인 설계다. 문제는 "세 개 피드와 학술 검색을 통틀어 5개월간 아무것도 없다"는 정상적인 결과가 아니라는 것이다 — 밖에서 보면 "지금은 정말로 관련된 게 없다"와 "소스 자체가 고장 났다"가 구분이 안 되고, 이 설계에는 둘 중 실제로 어느 쪽인지 드러낼 방법이 없었다.

조사

파이프라인 자체의 성공/실패 판단을 신뢰하는 대신, 설정된 각 소스를 하나씩 직접 테스트했다.

• 소스 1(잘 알려진 심리학 매체의 RSS 피드): HTTP 404 — 피드 URL 자체가 더 이상 아무것도 가리키지 않았다.
• 소스 2(경영 전문 매체의 RSS 피드): SSL 핸드셰이크 실패(핸드셰이크 도중 연결 종료) — 도메인이 사실상 이 피드 서빙을 완전히 중단했거나 재구성한 것과 일치하는 증상.
• 소스 3(과학 전문 비영리단체의 RSS 피드): 실제로 살아있음, HTTP 200, 실제 최신 기사 50건 반환.
• 학술 검색 API: 이것도 살아있고 실제로 정상 형식의 결과를 반환.

즉 세 RSS 소스 중 둘이 완전히 죽어있었다 — 속도제한도 아니고 일시적 다운도 아니라, 그냥 사라진 것이었다. 이것만으로도 급격한 물량 감소는 설명되지만, 실제 피드 하나와 실제 검색 API 하나가 그 내내 콘텐츠를 계속 반환하고 있었으므로 5개월 내내 문자 그대로 0건이라는 건 그것만으로 설명되지 않았다.

두 번째 층위 — 엉뚱한 도메인에 맞춰진 관련성 필터

살아남은 유일한 RSS 피드의 실제 기사들은 키워드 기반 관련성 점검에 의해 걸러지고 있었다 — 이 파이프라인의 주제 영역에는 합리적인 단어들이었지만, 이 기간 동안 그 소스의 최신 기사들이 하필 그 단어들과 매치되지 않았다. 별개로, 학술 검색은 실제로 정상 파싱된 결과를 반환하고 있었지만, 관련성 점수 임계값(키워드 최소 2개 매치 요구)이 이 주제의 일상어 어휘를 쓰는 논문들을 걸러내면서, 우연히 같은 표제 용어를 쓰는 무관한 기술 분야는 통과시키는 방식으로 조정돼 있었다 — 점수 로직이 같은 단어를 서로 다른 개념으로 쓰는, 완전히 다른 두 문헌 집단을 구분하지 못하고 있었다.

한 일 — 그리고 명시적으로 하지 않은 일

정확한 실패 유형과 정량화된 근거(죽은 피드 URL, 실제 200 응답으로 확인한 대체 후보, 구체적으로 과도하게 엄격한 임계값 동작)를 파이프라인을 조용히 패치하는 대신 문서로 남겼다. 죽은 소스 둘은 실제로 살아있음을 검증한 대체재로 교체해야 하고, 관련성 임계값은 신중한 재조정이 필요하다 — 둘 다 순수한 기계적 수정이 아니라 파이프라인이 앞으로 무엇을 우선해야 하는지에 대한 판단의 문제라서, 감사 도중 일방적으로 해결하는 대신 명시적 결정을 위해 표시해뒀다. 파이프라인의 "아무것도 못 찾으면 조용히 있는다"는 설계도 그대로 뒀다 — 우선순위 낮은 발굴 피드에는 옳은 동작이고, 실제 공백은 그 설계 자체가 아니라 "아무것도 못 찾음"과 "소스가 죽었음"이 같은 겉보기 침묵을 만들어낸다는 걸 한 번도 검증한 적이 없었다는 것이었다.