샤플앤컴퍼니

문제를 나눈 기준

기존 네이버웍스 메일 API는 서버에서 메일을 일괄 발송하는 방식에 적합하지 않았습니다. 전송 수단을 바꾸는 것과 별개로 배치가 중단되거나 다시 실행될 수 있었고, SQS 메시지도 중복 전달될 수 있었습니다.

따라서 다음 문제를 하나의 중복 처리로 합치지 않았습니다.

1. 메일을 받을 대상을 결정하는 업무 조건
2. 동일 기준의 배치가 다시 실행되는 경우
3. 동일한 메시지가 메일 서버에 다시 전달되는 경우

대상 선정과 전송의 책임 분리

배치 서버는 발송 대상자를 선별하고 발송 요청을 기록한 뒤 SQS 메시지를 발행합니다. 메일 서버는 메시지를 소비해 중복 처리 여부를 확인하고 AWS SES로 메일을 전송합니다.

이 분리로 온보딩 상태를 추적하는 조건과 실제 메일 발송 조건을 구분했습니다. 같은 전송 구조는 인보이스 메일 발송에도 재사용했습니다.

서로 다른 두 중복 방어선

1. 방어선 1

   배치 재실행 방어

   발생 조건

   동일 기준일의 배치가 다시 실행되는 경우

   중복 키

   발송 기준일과 대상 기준

   보장 범위

   동일 대상의 발송 요청이 중복 생성되는 것을 방지

2. 방어선 2

   메시지 중복 전달 방어

   발생 조건

   동일 SQS 메시지가 메일 서버에 다시 전달되는 경우

   중복 키

   메일 트랜잭션 키

   보장 범위

   메일 서버에서 동일 메시지를 중복 처리하는 것을 방지

두 제약은 서로 다른 시점의 중복을 방어합니다. 이 범위를 전체 시스템의 멱등성이나 Exactly-once 메일 전송 보장으로 확대하지 않습니다. 재처리와 외부 전송 실패 복구의 전체 범위도 확인되지 않아 자동 복구로 표현하지 않습니다.

구조적 결과

• 대상자 선별과 메일 전송의 책임을 배치 서버와 메일 서버로 분리했습니다.
• 배치 재실행과 메시지 중복 전달을 서로 다른 DB UNIQUE 제약으로 방어했습니다.
• 같은 발송 구조를 인보이스 메일에 재사용했습니다.

운영 발송량, 실패율과 메일 유실률은 공개 가능한 측정 근거가 없어 결과에 포함하지 않습니다.

문제와 변경

Apache POI 기반 점검 보고서 생성에서 지연이 발생했고, 보고서마다 Workbook·Sheet·Row·Cell을 다루는 코드가 반복됐습니다. 엑셀 라이브러리 API도 보고서 로직에 직접 노출돼 있었습니다.

생성 방식을 FastExcel 기반으로 전환하고 Kotlin DSL을 사용해 반복되는 생성 흐름을 공통 빌더로 분리했습니다. 보고서별 로직에서는 엑셀 라이브러리 종속 코드를 직접 다루지 않도록 공통 영역에 제한했습니다.

확인 가능한 결과

• POI 기반 생성 방식을 FastExcel 기반으로 전환했습니다.
• Kotlin DSL을 사용해 반복되는 보고서 생성 흐름을 공통 빌더로 분리했습니다.
• 보고서 로직과 엑셀 라이브러리 종속 영역을 구분했습니다.

당시 운영 환경의 원본 측정 근거가 확인되지 않아 생성 시간 개선 수치는 사용하지 않습니다. 회사에서 KExcel의 ExcelDriver, JMH 벤치마크나 동시 쓰기 Fail-Fast를 구현한 것으로도 표현하지 않습니다.