사전 예약 이벤트 당첨 안내, 월별 청구서 발송, 서비스 점검 공지처럼 알림톡을 한 번에 5만 건, 10만 건씩 보내야 하는 상황이 있습니다. 1건씩 보낼 때는 문제없던 알림톡 API가 이런 대량 발송에서는 전혀 다른 양상을 보이죠. TPS와 Rate Limit을 고려하지 않고 설계하면 같은 고객에게 메시지가 수십 건씩 중복 발송되거나 자사 서버가 다운되는 사고로 이어질 수 있습니다. 이 글에서는 대량 발송 설계 시 반드시 체크해야 할 포인트를 정리합니다.
⚙️ TPS와 Rate Limit의 중요성
TPS와 Rate Limit의 차이
TPS(Transactions Per Second)는 서버가 1초에 처리할 수 있는 요청 수를 뜻합니다. Rate Limit은 API 제공자가 클라이언트에게 허용하는 초당 또는 분당 최대 호출 횟수예요. TPS가 서버의 물리적 처리 능력이라면 Rate Limit은 그 능력 안에서 클라이언트별로 배분하는 정책적 한도입니다.
알림톡 API에서 주의해야 할 구간
알림톡 API는 자사 서버 → 딜러사 → 카카오 서버 → 수신자까지 여러 구간을 거칩니다. 이 중 TPS 문제가 실제로 터지는 구간은 두 곳이에요.
TPS와 Rate Limit을 고려하지 않고 발송 구조를 설계하면 다음과 같은 사고로 이어질 수 있습니다.
TPS를 고려하지 않으면 실제로 일어나는 일
1) 중복 발송
🔴 원인: 발송 기록과 API 호출이 하나의 트랜잭션에 묶여 있어서 에러 발생 시 성공 기록까지 롤백됨
🖥️ 결과: 같은 수신자에게 같은 메시지가 수십 건 이상 반복 발송
API 호출 중 에러가 발생하면 트랜잭션 전체가 롤백되면서 이미 성공한 수신자의 ‘발송 완료’ 기록까지 함께 사라집니다. 다음 배치가 실행되면 이 수신자들을 ‘미발송’으로 인식하고 같은 메시지를 또 보내게 돼요. 이 사이클이 배치 주기마다 반복되면 걷잡을 수 없이 커집니다. 10만 건 규모의 발송이라면 수신자 수십 명에게 같은 메시지가 10건 넘게 중복 발송되는 상황도 충분히 발생할 수 있어요.
2) 서버 다운
🔴 원인: Webhook 리포트가 발송 건수에 비례해서 자사 서버에 유입되어 DB 부하 초과
🖥️ 결과: 데이터베이스 서버 CPU 폭주, 서버 응답 불능
Webhook 리포트는 1건당 1회씩 전달됩니다. 자사 서버가 제시간에 응답하지 못하면 재시도 요청까지 쌓이면서 부하가 더 커지죠. 리포트를 받을 때마다 DB에 발송 상태를 기록하는 작업이 실행되면서 데이터베이스 서버의 CPU가 급격히 치솟고 서버가 응답 불능 상태에 빠질 수 있어요. 발송 서버와 Webhook 수신 서버가 같은 DB를 공유하고 있다면 발송 자체도 함께 멈추게 됩니다.
3) 발송 유실
🔴 원인: 429 응답을 받았을 때 재시도 로직이 없어서 해당 건이 처리되지 않은 채 넘어감
🖥️ 결과: 주문 확인, 결제 알림 등 필수 메시지 미도달
발송 대상 목록에서는 ‘처리 완료’로 넘어갔는데 실제로는 딜러사에 요청조차 전달되지 않은 상태예요. 주문 확인이나 결제 알림처럼 반드시 도달해야 하는 메시지에서 이런 유실이 발생하면 고객 CS로 이어지게 됩니다.
✅ 대량 발송 설계 시 체크해야 할 5가지
1) 자사 서버 처리 능력을 먼저 파악하기
딜러사가 제공하는 Rate Limit이 초당 200건이라고 해서 자사 서버도 200건을 감당할 수 있는 건 아닙니다. 특히 리포트를 Webhook으로 수신하는 경우 리포트 수신 서버의 처리 능력이 발송 속도의 상한선이 돼요. 발송 속도는 딜러사 Rate Limit이 아니라 자사 서버가 안정적으로 처리할 수 있는 TPS를 기준으로 결정해야 합니다.
예를 들어 딜러사 Rate Limit이 200TPS인데 자사 리포트 수신 서버가 부하 테스트 결과 100TPS까지만 안정적이라면 발송 속도를 100TPS로 제한하는 게 맞아요. 딜러사 API가 Webhook 외에 Polling 방식도 지원한다면 자사 서버가 원하는 주기에 맞춰 결과를 조회할 수 있어서 Webhook 유입 폭주 자체를 피할 수 있습니다. 발송량이 많은 환경에서는 Polling 방식을 검토하는 것도 방법이에요.
2) API 호출 횟수를 줄이는 배치 설계
10만 명에게 1명씩 API를 호출하면 10만 번의 요청이 필요합니다. 딜러사 API가 1회 호출로 여러 수신자에게 동시 발송하는 동보 발송을 지원한다면 호출 횟수 자체를 줄일 수 있어요. 1회에 200명씩 동보 발송이 가능하다면 10만 명 기준으로 500회 호출이면 됩니다. 10만 회와 500회는 Rate Limit에 미치는 부담이 완전히 다르죠.
3) 429 응답에 대비한 재시도 로직
Rate Limit 초과로 429 응답을 받았을 때는 즉시 재시도하지 않는 것이 좋습니다. 같은 속도로 다시 요청하면 또 429를 받을 뿐이기 때문이에요. 지수 백오프(Exponential Backoff) 패턴을 적용해서 재시도 간격을 점진적으로 늘려야 합니다. 첫 번째 재시도는 1초 후, 두 번째는 2초 후, 세 번째는 4초 후 같은 식으로 대기 시간을 두 배씩 늘려가는 거예요.
4) 멱등성 키로 중복 발송 방지하기
재시도 시 주의할 점이 하나 더 있어요. 네트워크 타임아웃으로 응답을 못 받았을 때 같은 요청을 다시 보내면 실제로는 두 번 발송될 수 있습니다. 이런 상황을 API 레벨에서 막아주는 것이 멱등성(Idempotency) 키예요. 멱등성이란 같은 요청을 여러 번 보내도 결과가 한 번만 반영되는 것을 뜻합니다.
딜러사 API가 멱등성 키를 지원한다면 주문번호나 인증 트랜잭션 번호 같은 업무 단위 식별값을 키로 설정해서 같은 키로 재요청해도 중복 발송을 방지할 수 있어요. 비즈고 API에서 멱등성 키를 적용하는 예시입니다.
idempotencyKey에 주문번호 같은 업무 식별값을 넣으면 네트워크 타임아웃 등으로 같은 요청을 재전송해도 서버에서 중복 처리를 방지합니다. idempotencyTtl은 이 키의 유효 시간(초)이에요. 위 예시에서는 3,600초, 즉 1시간 동안 같은 키로 들어온 요청을 중복으로 판단합니다.
5) 발송 기록과 API 호출을 트랜잭션에서 분리하기
외부 API 호출은 실패 가능성이 높은 작업이기 때문에 ‘발송 대상으로 지정된 기록’과 ‘API 호출’을 같은 트랜잭션에 묶으면 안 됩니다. 발송 대상을 먼저 ‘처리 중’ 상태로 변경한 뒤 API를 호출하고 결과에 따라 ‘성공’ 또는 ‘재시도 대기’로 업데이트하는 상태 머신 방식이 안전합니다.
2번에서 트랜잭션을 먼저 끊는 게 핵심이에요. 이렇게 하면 3번에서 API 호출이 실패해도 ‘처리 중’ 기록은 남아 있어서 다음 배치가 이 수신자를 ‘대기’ 상태로 착각하고 또 보내는 일이 생기지 않습니다.
대량 발송 설계 체크리스트
- 자사 리포트 수신 서버가 안정적으로 처리할 수 있는 TPS를 파악했는가?
- 동보 발송을 활용해 API 호출 횟수를 줄이는 배치 구조인가?
- 429 응답 시 지수 백오프 재시도 로직이 적용되어 있는가?
- 멱등성 키로 재시도 시 중복 발송을 방지하고 있는가?
- 발송 기록과 API 호출이 같은 트랜잭션에 묶여 있지 않은가?
🔍 알림톡 API 업체 선택 시 Rate Limit 외에 함께 확인할 것
대량 발송 설계에서 스레드풀 관리, 재시도 로직, 트랜잭션 분리는 자사 서버에서 해야 할 일입니다. 하지만 딜러사 API가 잘 설계되어 있으면 개발자의 설계 부담이 줄어들어요. 딜러사를 비교할 때 Rate Limit 외에 함께 확인하면 좋은 항목을 정리합니다.
리포트 수신 방식 선택 가능 여부
딜러사가 Webhook 방식만 지원하는지, 자사 서버가 원하는 주기에 맞춰 결과를 조회하는 Polling 방식도 선택할 수 있는지 확인이 필요해요. Webhook 방식은 대량 발송 시 리포트 수신 서버의 TPS 설계가 필수입니다. 두 방식을 모두 지원하는 딜러사라면 발송량에 따라 유연하게 전환할 수 있어요.
동보 발송 지원 및 최대 건수
1회 API 호출로 몇 명에게 동시 발송할 수 있는지에 따라 전체 호출 횟수가 크게 달라집니다. 동보 발송 최대 건수가 크면 Rate Limit에 도달할 확률이 낮아지고 스레드풀 설계도 단순해져요.
Rate Limit 상향 협의 가능 여부
발송량이 늘어나면 기본 Rate Limit으로는 부족할 수 있습니다. 예를 들어 서비스 점검 공지처럼 대량의 알림을 동시에 보내야 하는 경우 목표 발송 시간에 맞춰 Rate Limit 조정이 필요할 수 있어요. 딜러사와 협의를 통해 Rate Limit을 상향할 수 있는지 미리 확인해 두면 운영 중 대응이 수월합니다.
멱등성 키 지원 여부
재시도 시 중복 발송을 API 레벨에서 방지할 수 있는지 확인이 필요합니다. 멱등성 키를 지원하지 않는 딜러사라면 자사 서버에서 중복 방지 로직을 직접 구현해야 하므로 개발 부담이 커지게 됩니다.
