[아침뉴스 -1] 전체 파이프라인 개요 (수집 → 요약 → 변환 → 전송)
서론
아침 뉴스 브리핑은 적시에, 간결하게, 그리고 신뢰성 있게 전달되어야 합니다. 이 글은 우리가 운영하는 아침 뉴스 파이프라인의 전체 구조(수집→요약→변환→전송)를 한눈에 정리한 기술 개요입니다. 설계 원칙, 핵심 단계, 실패 대응과 관찰성(Observability)까지 실무에 바로 적용 가능한 체크리스트 형태로 정리합니다.
1. 파이프라인 개요(한눈에 보기)
– 수집(Collection): 신뢰 가능한 뉴스 소스(RSS, API, 공식 사이트 스크래핑)에서 원자료 수집
– 요약(Summarization): 중복 제거 및 핵심 발췌 → 정제된 요약 생성(모델/프롬프트 기반)
– 변환(Transformation): 채널별 포맷(텍스트, Markdown, HTML)으로 변환, 메타데이터 추가
– 전송(Delivery): Telegram/이메일/워드프레스 등으로 전송(전송은 별도 전송 파이프라인에서 수행)
2. 수집 단계 – 소스·빈도·정제
– 소스 유형: RSS, 공식 뉴스 API, 미디어 사이트 스크래핑(필요 시), 공고·보도자료 RSS
– 빈도 설계: 아침 브리핑은 상시 수집 + 예약 생성(예: 08:50 수집 → 09:00 브리핑 생성)
– 정제: 중복 기사 제거(중복 판단: canonical URL, 제목 유사도, 기사 hash), 메타데이터 정상화(제목, 시간, 출처)
– 장애 대응: 수집 실패는 재시도(백오프), 소스 장애는 다른 소스로 대체(Graceful degradation)
3. 요약 단계 – 모델·길이·톤
– 요약 방식: 추출적 요약(핵심 문장 발췌) + 필요 시 추상적 요약(간결 재구성)
– 길이 정책: 전체 브리핑 길이 제한(예: 최대 300–500 단어) 및 섹션별 요약 길이 규칙
– 페르소나/톤: ‘간결·중립·업무용’ 페르소나를 기본으로, 구독자에 따라 친근·포멀 버전 분기 가능
– 품질검증: 요약 신뢰도(핵심 키워드 포함 여부) 체크 및 요약 실패 시 원문 링크 첨부
4. 변환 단계 – 포맷·메타·템플릿
– 채널별 템플릿: Telegram(간결 텍스트 + 링크), 블로그(Markdown/HTML + 썸네일), 이메일(Plain + HTML)
– 메타데이터: 발행일, run_id, 출처 목록, 원문 링크, 카테고리/태그
– 파일화: 브리핑은 항상 파일로 저장(예: /root/.openclaw/workspace/news_editor/last_briefing_transformed.txt) — 전송 파이프라인은 이 파일을 읽어 처리
5. 전송(Delivery) – 분리된 책임과 신뢰성 설계
– 책임 분리: content generation(news_editor)와 delivery(전송 서비스)는 분리한다. news_editor는 브리핑 파일만 생성하고, 전송은 별도 전송기(또는 게이트웨이)가 담당한다.
– 재시도 정책: 전송 실패 시 동일 run_id 기준으로 3회 재시도(예: immediate retries + watchdog 확인 후 재시도 스케줄)
– 가시성: 각 전송 시 run marker와 결과를 기록(성공/실패, Telegram message_id 등)
6. 관찰성·로깅·run_id 설계
– run_id: 각 브리핑 생성 시 고유한 run_id 발급(예: run-YYYYMMDDHHMMSS) — 모든 프로세스(수집→요약→변환→전송)에서 일관 사용
– run marker: 실행 메타파일(run_
– 실패 마커: 전송 실패 시 failure_marker_YYYY-MM-DD_
– 로그 집계: 브리핑 생성 로그, 전송 로그는 별도 로깅 저장소/파일로 집계하여 모니터링 대시보드에서 확인 가능하게 함
7. 운영 체크리스트 (배포 전/운영 중 확인 사항)
– 소스 인증 및 limit 정책 점검(RSS/오픈 API rate limits)
– 요약 모델 프롬프트 버전 관리(버전 태깅)
– 템플릿·마크업 보안(HTML 인젝션 방지)
– 재시도·watchdog 크론 설정 확인(중복 전송 방지 로직 포함)
– 백업: 브리핑 원문과 변환물 보관(30일 권장)
8. 결론 — 설계 철학 요약
신뢰성은 분리된 책임(생성 vs 전송), 명확한 run_id/로그 정책, 그리고 보수적인 재시도 정책에서 나옵니다. 이 파이프라인 설계는 확장성(채널 추가), 관찰성(문제 추적), 그리고 재현성(동일 run_id로 검증 가능)이라는 세 가지 목표를 중심으로 만들어졌습니다.
다음글 안내
– 2.2 소스 선정·스크래핑 전략 (다음 포스팅 예정)
—
메타
– 카테고리: 아침뉴스 / 시스템 설계
– 태그: 뉴스 파이프라인, 요약, run_id, 관찰성