때로는 오버엔지니어링이 필요합니다

문제 상황

• 초당 1건 미만의 낮은 평균 발송량이지만 순간적으로는 10분에 1만 건이 몰리는 메시지 발송 시스템 전환 필요
• 레거시 데몬이 WAS와 자원을 공유하고, 표준 모니터링이 없고, 중복 발송 규칙이 구두로만 전해지는 운영 부채 존재
• 수십 개 서비스가 발송 대상 테이블과 저장 프로시저에 강하게 묶여 있어 한 번에 API 직접 호출 구조로 바꾸기 어려운 상황

원인 분석

• 발송 대상 INSERT를 유일한 공통 지점으로 삼는 레거시 구조 때문에 전면 개편 시 누락 위험이 큼
• 발송이 되돌릴 수 없는 작업이라 순서, 중복, 실패 처리에서 조용한 장애가 발생하기 쉬움
• 폴링 축소나 단순 배치, 직접 큐 구현만으로는 격리, 관측성, 재처리, 중복 방지 문제를 동시에 해결하기 어려움

해결 방법

• Strangler Fig 패턴으로 레거시 INSERT를 CDC와 Kafka로 가로채고, 별도 워커가 통합 메시지 서버 경로로 발송하도록 과도기 구조 구성
• 큐에는 메시지 ID만 싣고 원본은 DB에서 다시 조회하는 Claim Check 방식 적용
• 발송 후 이력 저장과 원본 삭제를 트랜잭션으로 묶고, 4xx는 즉시 실패 처리, 5xx와 네트워크 오류만 제한적으로 재시도
• 기능 플래그로 워커를 먼저 배포한 뒤 검증 후 발송을 열고, 전환 종료 기준을 INSERT 0건으로 설정