새로운 뉴스 카테고리를 소스 코드 수정 없이 추가하다
목차
기사 수집 봇의 카테고리 시스템을 리팩토링해서 토픽 소스를 동적으로 관리하고, 긴 기사도 처리 가능하도록 개선했다. 특히 AI News 같은 새 카테고리를 추가할 때 generate.py를 건드릴 필요 없도록 했는데, 이런 변경이 서비스 운영에서 왜 중요한지 회고해본다.
카테고리 추가 시마다 봇 코드를 수정해야 했던 이유
기사 수집 봇은 여러 토픽(예: 기술 뉴스, 비즈니스, 스타트업 등)별로 각기 다른 소스(RSS 피드, API 엔드포인트, 뉴스 집계 서비스 등)에서 데이터를 긁어온다. 문제는 새 카테고리(예: AI News)를 추가할 때마다 생성 로직 자체를 수정해야 했다는 것.
기존 구조를 상상해보면:
# generate.py (이전 방식)
def fetch_articles(category):
if category == "tech":
sources = [TECH_SOURCE_1, TECH_SOURCE_2]
elif category == "business":
sources = [BIZ_SOURCE_1]
elif category == "startup":
sources = [STARTUP_RSS]
# 새 카테고리 추가하려면 여기에 elif 추가 필요
return sources
코드상 하드코딩된 조건문이 점점 늘어나고, 매번 deploy 필요했다. 마음은 단순 설정 추가인데 파이프라인 전체를 돌려야 하는 답답함.
설정 기반 구조로 개선
이제는 categories.ts에 카테고리와 소스를 선언적으로 정의하고, generate.py는 그 설정을 읽어서 동작하는 구조로 변경했다.
| 변경 항목 | 이전 | 이후 |
|---|---|---|
| 카테고리 정의 | generate.py 내 하드코딩 | categories.ts 설정 파일 |
| 새 카테고리 추가 시 | generate.py 수정 필요 | categories.ts만 추가 |
| 배포 필요성 | 매번 필요 | 설정만으로 완료 |
| 토픽 소스 관리 | 고정된 매핑 | 동적 로드 |
예를 들어, AI News 카테고리를 추가하려면:
// src/lib/categories.ts에만 추가
export const categories = {
// 기존 카테고리들...
aiNews: {
name: "AI News",
sources: [
"https://api.example.com/ai-news",
"https://another-source.com/ai-feed"
],
maxArticleLength: null // 긴 기사도 수용
}
};
generate.py는 이 설정을 읽어서 자동으로 처리한다. 코드 수정 없이 운영자 레벨에서 설정만 추가하면 된다.
"매우 긴 기사" 지원이 의미하는 것
기존에는 아마도 기사 길이에 제한이 있었을 것 같다. 저장 공간, 처리 시간, UI 렌더링 등의 이유로 특정 글자 수 이상은 잘라내거나 거절했을 수 있다.
이번 변경으로:
- 기사 길이 제약 제거 — 긴 리포트, 심층 분석 기사도 그대로 수집 가능
- 소스별 설정 독립 — 어떤 카테고리는 3000자 이상, 어떤 카테고리는 무제한 같이 세밀한 조정 가능
특히 AI News처럼 기술 심화 콘텐츠가 필요한 카테고리일수록 긴 기사가 중요하다.
팀 영향과 학습
이 리팩토링을 통해 깨달은 점들:
1. 운영 효율성
- 개발팀의 병목을 줄인다. 새 뉴스 소스나 카테고리 추가가 이제 운영팀에서 자율적으로 할 수 있다.
- 급하게 새 소식 카테고리를 런칭해야 할 때, 코드 리뷰와 배포를 기다릴 필요가 없다.
2. 확장성 설계의 중요성
- 처음부터 "설정 가능하게" 설계하려는 의도가 없으면, 기능 추가가 늘어날수록 코드는 스파게티가 된다.
- 하드코딩은 단기엔 빠르지만, 중장기 유지보수 비용이 급증한다.
3. 프론트와 백의 분리
- categories.ts는 프론트(또는 공유 설정)이고, generate.py는 백엔드 로직이다.
- 설정과 로직을 분리하면, 팀 간 협업도 명확해진다. "UI에서 보여줄 카테고리 목록"과 "실제 수집 로직"이 동일한 소스에서 나온다.
4. 테스트와 모니터링
- 새 카테고리를 추가할 때 코드 변경이 없으면, 회귀 테스트 범위도 줄어든다.
- 설정 변경만으로 동작하므로, 설정 검증 로직만 강하게 가져가면 된다.
시스템이 커질수록 "누가 쉽게 변경할 수 있는가"가 중요해진다. 개발자뿐 아니라 운영자, 때론 비기술 팀원도 새로운 요청을 빠르게 반영해야 하는 현실을 감안하면, 이런 설정 기반 구조로의 전환은 단순 코드 정리가 아니라 조직 차원의 확장성 투자다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.