카카오뱅크 「하루 N억 건의 알림 시스템 구축기 (1)」 리뷰 — P99의 80%가 대기였다는 진단, Age 기반 Work-Stealing, 그리고 큐를 나누는 순간 순서를 잃는 문제

원문: 하루 N억 건의 알림 시스템 구축기 (1): 카카오뱅크는 어떻게 발송 플랫폼의 새로운 뼈대를 세웠나 — 카카오뱅크 기술블로그, 알림경험엔지니어링팀 Remy·Kenneth·Jett, 2026-09-07

이 글은 발행된 지 열흘 된 글이다. 고른 이유는 원문의 진단 한 줄 때문이다. 레거시 발송기의 P99 지연 중 80%가 처리 시간이 아니라 대기 시간이었다. 같은 문장을 나는 monticker 24편의 핫 종목 실험에서 썼다. 핫 종목이 스레드의 90%를 먹으면 같은 파티션의 다른 종목이 p99 13초로 함께 밀린다. 원문은 그 문제를 은행의 알림 규모에서 풀었다.

원문이 말하는 것

카카오뱅크 UMS 발송기는 Push·Email·SMS·알림톡을 하루 N억 건 보낸다. 레거시의 문제는 둘이었다.

성능. 요청마다 새 스레드를 만들었다. 요청 1,000개면 스레드 1,000개, 컨텍스트 스위칭, 고갈, OOM. 그리고 단일 큐라 느린 작업(2,000ms) 뒤의 빠른 작업(100ms)들이 2,000ms를 기다렸다. 다른 워커는 유휴였다. 프로파일링 결과 P99의 80%가 이 대기였다. 목표는 10,000 TPS 이상과 낮은 P99.

멘탈 모델. 채널 하나를 추가하려면 스레드 관리, 큐 처리, 재시도 로직을 전부 이해해야 했다. “광고 시간 체크는 어디에 넣지?”를 개발자마다 다르게 답했다. 구조가 없으니 의사결정이 느렸다.

해법은 두 층이다. Service Layer는 개발자가 보는 세상이다. RequestHandler(메서드 3개: 처리 가능한가, 처리하라, 이름)와 Sender(외부 API 호출 하나)만 구현한다. 재시도·타임아웃·동시성은 몰라도 된다. Core Layer가 그것을 숨긴다. 핵심은 WorkStealQueue다. 큐를 채널 기준으로 나누고(Push 큐, Email 큐, SMS 큐), 각 큐 안에서는 순차, 큐들 사이는 병렬. 그런데 부하가 한 큐에 몰리면 다시 단일 큐의 문제가 된다. 그래서 Work-Stealing인데, 원문은 일반적인 자원 중심(노는 워커가 없게)이 아니라 데이터 중심(오래 기다리는 메시지가 없게)이어야 한다고 본다. 중앙 관리자가 100ms마다 모든 큐를 스캔해 Age(큐 생성 시각 기준)가 500ms를 넘은 큐를 반으로 나눠 유휴 워커에 준다. 구현은 CAS로 분할 시점을 원자적으로 잡고 Barrier로 경계를 표시하는 Lock-Free, 배열 복사 없이 인덱스만 조정하는 Zero-Copy, 고정 크기 배열로 GC 압박을 줄이는 것. 초당 200번의 steal에도 새 배열을 만들지 않는다.

같은 곳: 느린 것 하나가 뒤를 막는다

이 진단을 세 번 만났다.

• monticker 24편: 파티션 하나에 핫 종목과 30개 종목이 같이 있다. 핫 종목 처리 비용이 스레드의 90%가 되자 같은 파티션 종목이 p99 12.8~14.3초로 함께 밀렸고, 다른 파티션은 39~46ms로 무영향이었다.
• parity-pay 5편: Outbox 발행기가 순서를 위해 파티션 키별 선두만 집어가자, 적체가 한 지갑에 몰리면 배치가 1건이 되어 처리량이 110배 떨어졌다. head-of-line 대기가 순서 보장의 대가였다.
• parity-pay 9편: 외부 호출이 Tomcat 스레드 200개를 24초 만에 다 잡자 무관한 API가 멈췄다. 원문의 “요청마다 스레드 생성”과 반대 방향(풀은 있으나 상한이 없음)이지만 결과는 같다.

원문은 이것을 “P99의 80%가 대기”라는 숫자로 진단했고, 그 숫자가 설계의 출발점이다. 진단이 없으면 “Lock-Free로 빠르게”가 목표가 되고, 진단이 있으면 “오래 기다린 메시지가 없게”가 목표가 된다. 원문이 자원 중심 대신 데이터 중심을 택한 것은 이 진단에서 나온다.

갈리는 곳: 큐를 나누면 순서를 잃는다

원문의 Work-Stealing은 큐를 반으로 나눠 다른 워커에 준다. 그 순간 그 큐 안에 있던 메시지들은 두 워커에서 병렬로 처리되고, 큐 안의 순서는 사라진다. 원문도 안다. “현재는 모든 요청을 병렬로 처리하지만, 동일 사용자의 연속된 요청은 순서 보장이 필요할 수 있다”를 미래 요구사항으로 적고, 그때는 큐 분리 기준을 사용자로 바꾸면 Handler 코드는 안 바뀐다고 말한다.

여기가 내 경험과 만나는 곳이다. monticker에서 파티션 키 = 종목 ID는 순서를 주지만 핫 종목의 이웃을 인질로 잡는다. 순서와 격리는 같은 자원(파티션, 큐)을 두고 반대 방향으로 당긴다. 순서를 지키려면 같은 키를 한 곳에 모아야 하고, 격리하려면 느린 것을 다른 곳으로 보내야 한다. 원문의 Age 기반 steal은 격리 쪽을 택한 것이고, 그것이 가능한 이유는 지금 알림에는 순서 요구가 없기 때문이다. 사용자별 순서가 요구되는 순간 steal은 “같은 사용자의 메시지는 나누지 않는다”는 제약을 받아야 하고, 그러면 한 사용자에게 알림이 몰릴 때 그 사용자의 큐는 다시 head-of-line이 된다. 5편의 26.6건/초가 그것이다.

원문이 “Handler 코드는 안 바뀐다”고 한 것은 맞지만, Core Layer의 steal 규칙은 바뀌어야 한다. 그 변경이 얼마나 큰지는 2편에서 다뤄지길 기대한다.

갈리는 곳: 상한은 어디에 있는가

원문의 레거시는 요청마다 스레드를 만들어 OOM이 났고, 신규는 워커 풀 + 큐로 바꿨다. 그런데 원문에는 큐의 길이 상한이나 거절 정책이 없다. 고정 크기 배열(1024)이 있으니 상한이 있을 텐데, 가득 찼을 때 무엇이 되는지는 1편에 없다. parity-pay 9편에서 벌크헤드의 계약은 “느린 상대 때문에 잃는 것을 일부로 한정한다”였고, 그 일부(거절된 601건)를 표에 같이 실어야 격리를 평가할 수 있었다. 알림은 거절보다 지연이 낫다고 볼 수 있지만(재시도하면 되므로), 그렇다면 큐가 무한히 자라는 것을 무엇이 막는지가 있어야 한다. 2편의 몫일 것이다.

원문이 잘한 것

멘탈 모델을 성능과 같은 무게로 다룬 것이다. 대부분의 고성능 시스템 글은 Lock-Free와 GC 최적화를 자랑하고 끝난다. 원문은 그것을 숨기는 것이 플랫폼의 일이라고 말한다. “동시성 처리 및 큐 분배 메커니즘을 여러 번 크게 변경했지만 Handler 코드는 단 한 줄도 수정하지 않았다”는 문장이 이 글의 실제 성과다. Spring의 @Transactional, JPA의 save(), Kafka Streams의 선언적 API를 예로 든 것도 정확하다. 셋 다 “어떻게”를 숨기고 “무엇을”만 남긴다.

7편에서 원장 규칙을 Money·Journal·DB 세 층에 둔 것과 같은 구조다. 개발자가 만지는 층은 얇고, 규칙을 지키는 층은 아래에 있다.

원문이 답하지 않는 것

10,000 TPS와 P99 목표를 달성했는지의 수치가 1편에는 없다. “P99의 80%가 대기”라는 전의 수치는 있고, 후의 수치는 2편으로 넘겼다. 그리고 Age 500ms·스캔 100ms·배열 1024라는 상수를 어떻게 정했는지도 없다. 500ms는 “알림에서 수 초도 긴 시간”이라는 도메인 판단에서 나왔을 텐데, 그 판단과 상수의 연결이 적혀 있으면 다른 도메인에서 옮겨 쓸 때 기준이 된다.

가져갈 것

• P99를 처리 시간과 대기 시간으로 나눠 재라. 80%가 대기면 병목은 알고리즘이 아니라 큐 구조다.
• 순서와 격리는 같은 자원을 반대로 당긴다. 순서 요구가 없을 때만 자유롭게 steal할 수 있고, 생기는 순간 steal 규칙이 바뀐다.
• 큐에는 상한과 거절 정책이 있어야 하고, 거절된 것을 살린 것과 같은 표에 놓아야 격리를 평가할 수 있다.
• 성능 최적화는 숨기는 것까지가 일이다. “Handler 코드 한 줄도 안 바뀜”이 성과다.