수동 제어 없는 자율 AI 뉴스 시스템

자율 AI 뉴스 시스템: 7개 워크플로를 통합 아키텍처로 대체하는 방법

한 달 반 만에 7개의 n8n 워크플로로 구성된 파편화된 뉴스 파이프라인이 160개 소스, 11개 워커, 5개 AI 에이전트를 갖춘 안정적인 시스템으로 탈바꿈했습니다. 이제 데이터베이스에 7127개의 레코드를 처리하는 데 수동 개입이 필요 없으며, 미니 PC의 로컬 LLM이 클라우드 API를 대체합니다. 실패 지점을 제거하고 24/7 운영을 보장하는 아키텍처를 자세히 살펴보겠습니다.

7개의 실패 지점에서 하나의 시스템으로

처음에 뉴스 파이프라인은 데이터 수집, 필터링, 번역, 이미지 생성, 게시 등 7개의 독립적인 n8n 워크플로로 구성되어 있었습니다. 각 단계가 고립되어 운영되면서 연쇄적인 실패가 발생했습니다. 전형적인 문제는 워크플로가 작업을 "완료"로 표시했지만 출력이 비어 있는 경우였습니다. 단계들 사이에 통합 모니터링 시스템이 없어 진단에 몇 시간이 걸렸습니다. 핵심 취약점은 각 뉴스 아이템에 대한 단일 상태가 없다는 것이었습니다. 하나의 워크플로가 멈추면 다른 워크플로들은 계속 처리되어 데이터 불일치가 발생했습니다.

해결책은 Perplexity를 활용한 분석과 Claude Code 실험에서 나왔습니다. Python으로 로직을 수동으로 다시 작성하는 대신 AI 어시스턴트에게 소스 워크플로와 아키텍처 요구사항을 제공했습니다. 1시간 만에 책임이 명확히 분리된 컨테이너화된 애플리케이션을 생성했습니다. 핵심 변화는 트리거 기반 워크플로에서 상태 지향 파이프라인으로의 전환으로, 각 뉴스 아이템이 데이터베이스에 상태가 고정된 엄격히 정의된 단계를 거칩니다.

로컬 처리: 왜 미니 PC에서 Qwen 3.5인가

클라우드 API를 통한 뉴스 번역은 경제적으로 비효율적임이 입증되었습니다: 15분마다 업데이트되는 160개 소스는 매일 수만 건의 요청을 필요로 합니다. 해결책은 Ubuntu가 설치된 가정용 미니 PC에 로컬 LLM을 배포하고 llama.cpp를 통해 Vulkan으로 최적화하는 것입니다. 러시아어에 대한 속도와 품질의 균형으로 Qwen 3.5 모델(qwen3.5-9b-q5_k_m.gguf)을 선택했습니다.

설정에는 다음이 포함되었습니다:

• Cursor를 통한 CPU 아키텍처 파인튜닝
• 지연 최소화를 위한 스레드 수 조정
• 중간 결과 캐싱 구성

시스템은 CPU 과부하 없이 분당 최대 50건의 요청을 처리합니다. 데이터는 로컬 네트워크를 벗어나지 않으며, API 키 제한이 있는 소스에 중요합니다. 비교: 현재 처리량에서 클라우드 번역 비용은 월 ~$120, 로컬은 초기 설정 후 $0입니다.

파이프라인 아키텍처: 11개 워커의 작동 원리

"하나의 프로세스 — 하나의 작업" 원칙에 기반합니다. 각 워커가 고립되어 연쇄 실패를 제거합니다. 처리 흐름:

collector → scraper → deduplicator → ai_filter → translator
    → llm_editor → image_worker → publisher

collector는 15분마다 실행되어 160개 소스(Arxiv, TechCrunch, GitHub 포함)의 RSS/API를 파싱합니다. scraper는 로컬 Jina Reader 인스턴스를 통해 전체 텍스트를 추출합니다 — 이는 클라우드 서비스 제한을 제거했습니다. deduplicator는 정확한 텍스트 일치가 아닌 임베딩 기반 의미 비교를 사용합니다. ai_filter는 관련성 점수(relevance_score, 0-100)를 부여해 75점 미만 아이템을 필터링합니다.

llm_editor 단계에 특별한 주의가 필요합니다. 여기서 MiniMax M2.7은 채널 스타일로 텍스트를 포맷합니다: 헤드라인에 이모지 추가, 콘텐츠 구조화, 출처 표기. 모델은 과거 채널 데이터로 훈련되어 일관된 포맷을 보장합니다. 모든 워커는 전달 보장을 가진 메시지 큐를 통해 상호작용하며, 마지막 체크포인트부터 재개할 수 있습니다.

AI 에이전트를 통한 관리: Telegram 명령에서 액션으로

OpenClaw 기반 코디네이터가 수동 관리를 대체합니다. 동일한 미니 PC에서 실행되며 API를 통해 도구에 접근합니다. 시스템은 5개의 전문 에이전트를 사용합니다:

• AgentLLMEditor: 20분마다 텍스트 수정
• AgentPipelineManager: 하루 4회 포스트를 슬롯에 분배
• AgentSourceAuditor: 매주 작동하지 않는 소스 비활성화
• AgentAnalyst: 21:05에 분석 생성
• Coordinator: 다른 에이전트 관리

"Coordinator, 게시 한도를 하루 8개로 줄여" 같은 Telegram 명령이 파이프라인 매니저의 API 호출로 변환됩니다. 에이전트는 현재 설정을 확인하고 변경 후 실행을 확인합니다. 이는 SSH 접근이나 설정 파일 문법 지식을 필요로 하지 않습니다. 핵심 작업(예: 소스 비활성화)의 경우 human-in-the-loop (hitl) 워커를 통한 확인이 필요합니다.

대시보드: 실시간 모니터링

인터페이스는 9개 탭으로 구성: 개요, 에이전트, 소스, 큐, 워커, 슬롯, 게시됨, 설정, GitHub Discovery. 주요 지표:

• 소스별 통과율: Anthropic News (100%) vs iXBT.com (14%)
• 단계 처리 시간: 번역 (4분) vs 필터링 (2분)
• 워커 상태: 활성/대기 프로세스

이상 징후(예: 멈춘 번역 큐) 감지 시 대시보드가 Telegram 작업 그룹에 자동으로 작업을 생성합니다. GitHub Discovery와의 통합은 스타 급증 저장소를 추적하며 — 이 데이터는 활동 그래프와 함께 별도 탭에 표시됩니다. 시스템은 게시물에 영향을 주기 전에 문제를 경고합니다: 예를 들어 소스 통과율이 일주일 동안 10% 미만으로 떨어지면.

선택을 통한 절감: 주 1000개 뉴스에서 하루 8개 게시로

시스템은 모든 것을 게시하지 않습니다. 주당 ~1000개 아이템 처리되지만 실제 게시되는 것은 56개(하루 8개)뿐입니다. 선택 기준:

• relevance_score ≥ 80 (ai_filter)
• LLM 에디터 승인 (status approved)
• 시간대 슬롯 일치

시간대에 맞춘 스케줄:

• 아침 (08:00–11:00): 2개
• 낮 (12:00–16:00): 2개
• 저녁 (18:00–22:00): 2개
• 밤 (00:00–06:00): 2개

이전에는 하루 28개 게시했지만 분석 결과 사용자는 마지막 1-2개만 읽었습니다. 이제 양을 줄여 슬롯 내 모든 게시물을 보는 유지율이 37% 증가했습니다. 소스 통과율로 매주 목록 조정: 이미 20개 저효율 RSS 피드를 비활성화했습니다.

핵심 사항

• 통합 상태 시스템이 고립된 워크플로를 대체: 각 뉴스에 명확한 상태로 실패 진단 속도가 5배 빨라짐.
• 로컬 LLM으로 번역 및 편집 비용 월 최대 $120 절감, 50개 병렬 작업당 지연 4분 초과 없음.
• AI 에이전트가 수동 관리를 제거: Telegram 명령이 운영자 개입 없이 API 호출로 변환.
• 엄격한 콘텐츠 선택 (하루 28개 → 8개)이 노이즈 감소로 청중 유지율 37% 향상.

— Editorial Team