카카오 「잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정」 리뷰 — 벤더가 8ms 만에 리포트를 보냈고, 우리는 101ms짜리 트랜잭션 안에 있었다

원문: 잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정 — kakao tech, ravae.c 최지원(커넥티비티 플랫폼), 2026-02-09

한 줄 요약

사내 SMS 플랫폼 KIMS(하루 약 100만 건)에서 벤더의 전송 결과 리포트가 분명히 수신됐는데 DB의 메시지 상태가 SENT에 멈춰 있는 일이 0.02%에서 났다. 원인은 어떤 벤더가 API 호출 후 평균 20ms(누락 건은 8ms) 만에 리포트를 보내는데, API 서버는 벤더 호출부터 과금 이벤트 발행까지를 하나의 @Transactional(평균 101ms)로 묶어 놓아 리포트가 도착했을 때 메시지 레코드가 아직 커밋되지 않았기 때문이다. 트랜잭션을 줄이고(누락 40% 감소), 아예 제거하고(커넥션 점유 101ms → 4~6ms), Outbox를 넣었더니 이번엔 실시간 경로와 재처리 경로가 충돌해 과금 이벤트가 빠졌다. 최종 답은 Single Writer: 리포트 서버는 Outbox에 적재만 하고, Replayer 하나가 상태 전이와 과금 발행을 모두 맡는다.

배경: 흐름과 증상

요청이 오면 ① API 서버가 실시간 품질 지표로 벤더를 골라 호출하고 ② SENT로 DB에 기록하며 ③ 단말에 전달되면 ④ 벤더가 결과 리포트를 보내고 ⑤ Report 서버가 REPORTED로 갱신한다. 각 단계는 비동기로 분리된 컴포넌트다. “모든 단계가 기대한 순서로 동작한다면” 문제없다.

모니터링에서 일부 메시지가 SENT에 머물렀다. 벤더가 안 보냈나 싶었지만 Report 서버 로그에 수신 기록이 있었다. 리포트가 중간에 사라진 것처럼 보였다. 동시성 버그는 타이밍에 의존해 로컬에서 재현되지 않지만, 다행히 누락 건이 충분히 쌓여 패턴이 보였다.

• Problem 1: 특정 벤더로 보낸 메시지에서만
• Problem 2: 무료가 아닌 과금 대상 유료 메시지에서 주로

원인: 8ms와 101ms

로그를 시간순으로 놓으니 결정적 단서가 나왔다. 벤더 API 호출 성공(21.362초) → 과금 Kafka 이벤트 발행(여전히 DB 미영속) → 벤더 리포트 진입(21.370초) → 메시지 조회 실패, 저장 실패 → 그 뒤 어느 시점에 레코드 영속화. 호출부터 리포트까지 8ms. 다른 벤더는 평균 1초 이상인데 이 벤더는 평균 20ms였고, 누락 건만 모으면 8ms였다. 쓰기 경로와 읽기 경로가 같은 순간에 교차했다.

Problem 2는 구조에서 나왔다. 유료 메시지는 과금 이벤트 발행이라는 후처리가 붙고, 벤더 호출부터 그 후처리까지가 하나의 @Transactional이었다. 트랜잭션이 길어져 커밋이 늦어졌고, 리포트가 커밋보다 먼저 올 확률이 커졌다. 과금을 정확히 하려고 넣은 로직이 과금 메시지에서 문제를 만든 셈이다. 게다가 JPA의 Dirty Checking 때문에 상태 변경(→ SENT)은 영속성 컨텍스트에만 있다가 트랜잭션 종료 시점에야 DB에 쓰였다.

조치 1: 트랜잭션 다이어트

Kafka 발행처럼 트랜잭션 안에 있을 필요 없는 것을 @Async + @TransactionalEventListener로 커밋 이후 별도 스레드에서 실행하게 뺐다. 커밋이 평균 약 10ms 앞당겨졌고 누락이 눈에 띄게 줄었다. 부수 효과로, 롤백될 수 없는 외부 이벤트 발행을 트랜잭션 안에 두던 dual-write 문제도 사라졌다.

그리고 근본적인 질문이 나왔다. 우리는 트랜잭션을 정말 잘 쓰고 있나?

조치 2: 트랜잭션 제거

REPEATABLE READ에서 트랜잭션을 쓰는 이유 세 가지를 하나씩 점검했다.

• 원자성(abortability): 이 트랜잭션의 쓰기는 “초기 상태 → SENT” 하나뿐이었다. 여러 테이블에 걸친 원자성이 필요한 구조가 아니다.
• 읽기 격리: 쓰기 전에 벤더 정보와 품질 지표를 읽는데, 지표는 분 단위 갱신이라 1분 전 값이어도 되고 테이블 간 결합도 없다. 같은 스냅샷에서 읽을 이유가 없다.
• 쓰기 격리: 커밋 전까지 변경을 숨기는 것인데, 여기서는 오히려 그 숨김(Dirty Checking의 지연 쓰기)이 리포트 수신과 커밋 사이의 간극을 벌리는 원인이었다.

셋 다 필요 없다는 결론. 게다가 트랜잭션 점유 101ms는 처리량으로 환산하면 커넥션당 9.9 req/s, HikariCP 풀 10이면 이론상 최대 99 req/s다. 실제로 트래픽이 튀거나 벤더 응답이 늦으면 커넥션 대기와 타임아웃이 간헐적으로 났다. @Transactional을 제거하자 분산 트레이싱에서 커넥션 점유가 4ms, 6ms로 줄었다.

여기까지로 누락이 약 40% 줄었지만, 영속화 시간을 0으로 만들 수는 없으니 확률을 낮출 뿐 구조적 해결은 아니었다.

조치 3: Outbox, 그리고 새 문제

Report 서버가 리포트를 받으면 ① Outbox에 기록 → ② REPORTED로 전이 → ③ 과금 이벤트 발행, 그리고 ④ Report Replayer가 주기적으로 Outbox를 스캔해 미처리 리포트를 재적용. 결과는 절반만 맞았다. DB 기준 리포트 누락은 0%가 됐지만 과금 이벤트 누락이 오히려 늘었다.

벤더는 같은 리포트를 여러 번 보내기도 하므로 Report 서버에는 “SENT → REPORTED 전이에 성공한 경우에만 과금 이벤트를 발행”하는 compare-and-set 멱등성 가드가 있었다. Outbox 도입 후 Report 서버와 Replayer 두 경로가 같은 데이터를 보게 됐고, Replayer가 먼저 REPORTED로 바꿔 버리면 Report 서버의 전이가 가드에 막혀 과금 이벤트가 안 나갔다. “누가 먼저 실행될지”라는 가정을 앞서는 벤더가 깼다면, 이번엔 우리 시스템 내부가 깼다. 순서를 ② → ③ → ①로 강제하면 회피는 되지만 코드 곳곳에 암묵적 제약을 심는 위험한 설계라고 봤다.

조치 4: Single Writer

“같은 데이터에 쓰는 주체는 하나만.” Report 서버는 리포트를 받으면 아무 판단 없이 Outbox에 적재만 한다. Replayer가 주기적으로 Outbox를 돌며 메시지 상태를 반영하고 그 시점에만 과금 이벤트를 발행한다. 저장·전이·발행이 한 경로로 통합되니 경쟁이 구조적으로 사라지고, 반영과 발행 사이의 원자성이 자연히 보장되며, 재시도는 Outbox가 맡아 사실상 exactly-once가 됐다.

트레이드오프

포기한 것은 즉시성이다. 리포트 처리가 배치가 되면서 지연이 생겼다. 그러나 과금·정산 도메인에서는 “빠르지만 틀릴 수 있는 결과”보다 “늦더라도 반드시 맞는 결과”가 우선이다. 트랜잭션의 관성적 사용도 포기했다. 얻은 것은 경쟁이 없는 구조, 예측 가능한 지연, 읽기는 자유롭고 쓰기는 하나인 확장 친화적 설계다. 결론은 “동시성 문제는 코드의 미세 조정으로는 안 되고, 경쟁 자체가 없는 아키텍처로 바꿔야 근본적으로 사라진다.”

읽고 남는 질문

• Replayer의 주기가 곧 리포트 반영 지연인데 값이 없다. 초 단위인지 분 단위인지에 따라 “즉시성 희생”의 크기가 다르다.
• Replayer가 하나라는 것은 단일 장애점이자 처리량 상한이다. 여러 IDC에 분산된 MSA라 했는데 Replayer의 HA(리더 선출)와 Outbox 파티셔닝을 어떻게 했는지 궁금하다.
• 트랜잭션을 제거한 경로에서 벤더 호출은 성공했는데 SENT 저장이 실패하는 경우(DB 순단)는 어떻게 되는지. 원자성이 필요 없다고 판단한 근거가 “쓰기가 하나”였지만, 외부 호출과 그 하나의 쓰기 사이의 불일치는 여전히 남는다.

한 줄로 가져가기

트랜잭션은 “무엇을 보장받으려고 쓰는가”를 답할 수 있을 때만 써야 하고, 동시성 버그는 타이밍을 조여서가 아니라 쓰는 주체를 하나로 줄여야 사라진다. 그 대가는 즉시성이며, 과금에서는 그것이 맞는 거래다.