배치 정산 리포트 알림 노이즈 제거

일일 정산 리포트를 생성하는 배치 작업에서 모든 완료 메시지가 디스코드로 나가고 있었다. 문제는 이 리포트가 정산 시스템 내부에서 자동 처리되는 데이터일 뿐이라는 점이었다. 팀이 매번 그 결과를 디스코드에서 눈으로 확인해야 할 필요가 없었고, 오히려 정말 중요한 알림들 사이에 묻혀 신호대잡음비가 떨어지고 있었다.

배치 리포트 알림의 진짜 문제

처음엔 "배치 작업 완료했으니 다 알려주자"는 좋은 의도였을 거다. 하지만 운영 규모가 커지면서 그 부작용이 명확해졌다:

• 알림 폭주: 일일 정산은 여러 건이 발생하고, 각각이 모두 디스코드 메시지가 된다
• 신호 소실: 정말 중요한 에러 알림이나 수동 개입이 필요한 케이스가 실시간 알림 더미 속에 섞인다
• 팀 피로도: 팀원들이 알림에 대한 피로감을 느끼고, 진짜 중요한 것도 놓치게 된다

이건 단순한 "로그 레벨" 문제가 아니라, 어떤 이벤트를 팀에게 "방송"할 것인가에 대한 의사결정이다. 자동 처리되는 정상 케이스와 수동 개입이 필요한 예외 상황을 명확히 구분해야 한다.

해결 방법: 리포트 타입별 필터링

NO_DISCORD 타입을 추가해서 배치 처리 단계에서 이미 디스코드 발송 여부를 제어하도록 했다. 배치 영역과 유틸리티 영역을 함께 손대서, 리포트 생성부터 발송까지 전체 흐름을 일관되게 만들었다.

발송 로직은 이제 이렇게 간단하다:

if (report.getType() != ReportType.NO_DISCORD) {
    sendToDiscord(report);
}

배치 결과는 여전히 DB에 쌓이고(감사/통계용), 대시보드나 모니터링 시스템에서는 조회 가능하지만, 불필요한 팀 알림은 줄일 수 있다.

배치 작업과 알림 전략의 경계

이 fix를 진행하면서 배운 것들:

• 배치 = 자동화이지만, 결과 보고 ≠ 자동 알림이어야 한다. 특히 대량 처리에서는 더욱. 성공 케이스까지 일일이 알릴 필요는 없다.
• 필터링은 발송층에서: 유틸리티의 발송 로직에서 타입을 체크하는 게 더 안전하다. 배치층에서 조건부로 리포트를 안 만드는 것보다는, 만들되 발송을 제어하는 게 추적과 감사 관점에서 낫다. 나중에 "어제 정산 리포트 몇 건이었지?" 할 때 데이터가 남아 있어야 한다.
• 타입의 명확성: NO_DISCORD, SILENT 같은 명시적 타입명이 다음 개발자나 코드 리뷰어에게 의도를 전달한다. 주석만으로는 놓친다.

이런 류 개선은 흔히 "작은 fix"로 취급받지만, 팀의 일상 워크플로우에는 실제로 큰 영향을 미친다. 매일 받는 알림 5개가 2개로 줄면, 그 3개의 노이즈 때문에 놓칠 확률도 없어진다. 알림 피로는 누적된다.

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

• 모니터 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →
• 사무의자 쿠팡에서 보기 →

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