배경 및 목표
도메인별로 알림 설정과 발송 로직이 곳곳에 흩어져 있었습니다.
- 도메인 A, B, C 마다 별도의 알림 테이블(N개)이 존재해, 알림을 한 곳에서 조회하고 관리하기 어려웠습니다.
- 도메인 로직이 알림을 직접(동기) 호출해 발송까지 책임지면서, 알림 로직에 강하게 결합, 종속되어 알림 변경이 도메인 코드로 번졌습니다.
- 발송 플로우(메일, 슬랙, 인앱)도 도메인마다 중복 구현(N개)되어, 새 알림을 추가할 때마다 채널별 발송 코드를 다시 작성해야 했습니다.
- 새로운 알림 유형이나 발송 채널을 추가할 때마다 테이블과 발송 코드를 계속 늘려야 하는 구조였습니다.
목표
- 도메인별로 흩어진 알림 테이블을 단일 테이블로 통합해 일관되게 관리한다.
- 도메인 이벤트를 받아 채널로 발송하는 공통 알림 워크플로우를 만든다.
- 새 알림 워크플로우를 기존 코드 수정 없이 확장할 수 있는 인터페이스를 설계한다.
해결 방법과 해결 후보군
후보군 비교
| 방식 | 설명 | 한계 |
|---|---|---|
| 도메인별 개별 유지 | 각 도메인이 자체 테이블과 발송 로직 보유 | 중복 심화, 신규 알림마다 재구현 |
| 채널별 서비스만 분리 | 메일, 슬랙, 인앱 발송만 서비스로 분리 | 도메인 x 채널 조합 폭발, 트리거 일관성 부족 |
| 공통 워크플로우 + 테이블 통합 (채택) | 단일 테이블 + 이벤트 기반 공통 플로우 + 구독자 인터페이스 | 초기 설계와 마이그레이션 비용은 있으나 확장 비용 최소 |
기존 테이블을 통합 테이블로 흡수하려면 마이그레이션 비용이 들지만, 여러 알림 유형을 하나의 스키마와 플로우로 표현하면 이후 알림 유형과 채널 확장 비용이 크게 줄어든다고 판단해 통합안을 채택했습니다.
1. 알림 테이블 단일화
도메인 A, B, C의 개별 알림 테이블을 하나의 통합 알림 테이블로 합쳤습니다. 도메인 구분은 컬럼(유형, 범위 등)으로 표현하고, 설정, 수신자, 발송 조건, 예약, 이력을 공통 스키마로 정규화했습니다.
수신자 그룹도 하나의 유형 컬럼으로 여러 그룹을 표현하고, 유형별로 실제 대상을 다르게 확장합니다.
| 수신자 유형 | 확장 방식 |
|---|---|
| 개인 | 지정된 사용자 목록을 그대로 조회 |
| 그룹 전체 | 그룹 구성원 전체로 확장 |
| 담당자 | 배정 관계를 따라 담당자로 확장 |
| 역할 | 해당 역할 보유자로 확장 |
2. 이벤트 기반 공통 워크플로우 (Workflow 인터페이스)
도메인은 알림을 직접 발송하지 않고 도메인 이벤트만 발행합니다. 최상위 Workflow 인터페이스가 도메인 이벤트를 구독(consume)하고, 이를 구현한 AWorkflow, BWorkflow 등으로 확장합니다. 워크플로우는 이벤트를 받아 알림 설정 조회부터 콘텐츠 구성, 발송까지 공통 플로우로 처리합니다. 새 워크플로우는 Workflow 인터페이스를 구현해 등록하기만 하면 됩니다.
sequenceDiagram participant D as 도메인 (A/B/C) participant W as AWorkflow participant SET as 알림 설정 조회 participant CT as 콘텐츠 구성자 participant SEND as 발송자 D->>W: 도메인 이벤트 발행 W->>SET: 유형/수신자/조건/시점/채널 조회 SET->>CT: 발송 조건 통과분만 콘텐츠 구성 CT->>SEND: 채널별 발송
발송자는 채널별 발송 전략(메일, 슬랙, 인앱)으로 분리해, 새 채널을 독립적으로 추가할 수 있게 했습니다.
3. 즉시 발송과 예약 발송 분리
발송 시점을 즉시와 예약으로 나눕니다. 즉시는 단건 콘텐츠 구성자로 바로 발송하고, 예약은 예약 테이블에 적재한 뒤 정각 배치가 처리합니다. 배치는 예약 데이터를 최신 상태로 클렌징한 후 복수 콘텐츠 구성자로 묶어 발송합니다.
결과
| 항목 | 기존 | 개선 |
|---|---|---|
| 알림 테이블 | 도메인별 N개 | 단일 1개 |
| 발송 플로우 | 도메인마다 중복 구현 | 공통 워크플로우 1개 |
| 신규 알림 추가 | 채널별 코드 재작성 | 구독자 인터페이스 구현체 등록 |
| 채널 확장 | 도메인마다 수정 | 채널 전략 추가로 독립 확장 |
| 벌크 발송 | 건별 N회 발송 | 커밋 후 묶음 1회 발송 |
도메인과 발송을 이벤트로 분리하고 워크플로우를 인터페이스화하여, 새 알림과 채널을 최소 비용으로 확장할 수 있는 구조를 확보했습니다. 위 지표는 설계 기준 구조 변화이며, 발송 지연이나 처리량 같은 런타임 실측치는 아직 포함하지 않았습니다.
모니터링
- 알림 생성, 발송의 성공 및 실패 건수를 채널(메일, 슬랙, 인앱)별로 관측한다.
- 예약 배치의 처리 시간을 관측하고, 임계치 초과 시 멀티스레드 전환을 판단한다.
- 워크플로우별 이벤트 소비 지연과 예약 적체량을 관측한다.