뉴스 발행 진행률을 소스별로 분리 추적하도록 개선

서비스에서 콘텐츠를 정기적으로 발행하는 작업은 단순해 보이지만, 실제로는 여러 데이터 소스에서 동시에 들어오는 정보를 조율해야 한다. 이번에 발행 진행 상황을 추적하는 스크립트를 개선하면서 깨달은 게, 단순히 "전체 진행률"만 보는 것으로는 문제를 빠르게 진단할 수 없다는 점이었다.

한 지표로는 부족했던 이유

예를 들어 일반 뉴스와 K-pop 뉴스가 별도의 파이프라인으로 들어온다고 가정하자. 둘 다 최종 발행 단계를 거치지만, 수집 소스가 다르고, 처리 시간도, 오류 패턴도 다를 수 있다. 그런데 진행률을 하나로 봤을 때 "70% 진행 중"이라는 수치만 떠서는 어디가 막혔는지 알 수 없다.

• K-pop 뉴스는 이미 95% 진행됐는데
• 일반 뉴스가 40%에서 멈춰 있을 수도 있고
• 반대일 수도 있다.

이렇게 되면 온콜 상황에서 원인 파악에만 10분 이상 걸린다. 발행 파이프라인은 정시성이 중요한데, 지표가 뭉뚱그려져 있으면 반응 시간이 늘어난다.

소스별 분리 집계로 개선한 방식

이번 변경에서는 K-pop 뉴스를 별도의 집계 대상으로 구분하고, sentinel id 99를 사용해서 이를 표시했다. 핵심 아이디어는 이렇다:

Sentinel id 패턴은 "이건 일반적인 데이터 흐름이 아니다"를 코드 수준에서 명시하는 방식이다. id=99처럼 예약된 값을 사용하면, 나중에 코드를 읽는 사람도 "이 조건은 특수하다"를 한눈에 알 수 있다.

# 의사 코드로 보면 이런 느낌
if source_id == SENTINEL_SPECIAL_NEWS_ID:  # id=99
    # K-pop 뉴스는 별도 처리
    aggregate_kpop_news_progress()
else:
    # 일반 뉴스 처리
    aggregate_general_news_progress()

왜 이렇게 구조화했나

팀 논의에서 고민했던 부분은 이거였다:

옵션 1. 데이터베이스에 source_type 컬럼을 추가하고 정규화하기
- 장점: 확장성이 좋음, 나중에 소스가 늘어나도 쉬움
- 단점: 스키마 변경 필요, 기존 데이터와의 호환성 처리 필요, 배포 시간 증가

옵션 2. 스크립트 레벨에서 특정 id를 예약값으로 사용하기 (선택한 방식)
- 장점: 즉시 배포 가능, 기존 시스템 영향 최소, 빠른 개선
- 단점: 이 규약을 알아야만 이 스크립트를 유지보수할 수 있음

지금은 옵션 2가 맞다고 판단했다. 왜냐하면:
1. 발행 진행률 추적은 모니터링 목적이지, 핵심 데이터 구조는 아니다
2. 지금 즉시 배포해야 온콜 이슈 응대 시간을 줄일 수 있다
3. 향후 스스로를 유지보수할 때 문서화나 주석으로 충분하다

배운 점

이번 작업에서 느낀 게, "좋은 모니터링"은 시스템을 빠르게 진단할 수 있게 설계되어야 한다는 것. 지표 하나가 여러 가지를 뭉뚱그려서 표시하면, 오히려 문제를 숨기는 꼴이 된다.

또한 코드 수준의 작은 규약(sentinel id 같은 것)이 문서나 위키보다 훨씬 실용적일 수 있다는 걸 다시 확인했다. 개발자들은 코드를 읽고, 코드가 가장 신뢰할 수 있는 정보원이기 때문이다.

다음에 비슷한 상황이 오면, 처음부터 "단일 지표로 충분한가?"를 더 일찍 물어봐야겠다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 커피머신 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.