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

게시 2026/07/26 수정 2026/10/07 작성자 August

조회 15 분 읽는 시간

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

한 줄 요약

사내 SMS 플랫폼 KIMS(하루 약 100만 건)에서 벤더의 전송 결과 리포트가 분명히 수신됐는데 DB의 메시지 상태가 SENT에 멈춰 있는 일이 0.02%에서 났다. 어떤 벤더는 API 호출 후 평균 20ms(누락 건은 8ms) 만에 리포트를 보냈다. 그런데 API 서버는 벤더 호출부터 과금 이벤트 발행까지를 하나의 @Transactional(평균 101ms)로 묶어 두었다. 그래서 리포트가 도착했을 때 메시지 레코드가 아직 커밋되지 않은 상태였다. 팀은 트랜잭션을 줄이고 아예 제거해(커넥션 점유 101ms → 4~6ms) 누락을 약 40% 줄였다. 확률만 낮출 뿐이라 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(엔티티 변경을 감지해 나중에 한꺼번에 UPDATE를 보내는 방식) 때문에 상태 변경(→ SENT)은 영속성 컨텍스트에만 있다가 트랜잭션 종료 시점에야 DB에 쓰였다. Hibernate 문서는 이 시점을 flush라 부르고, 영속성 컨텍스트의 상태를 DB와 맞추는 과정으로 정의한다.

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

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

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

조치 2: 트랜잭션 제거

MySQL 기본 격리 수준인 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를 스캔해 미처리 리포트를 재적용. 이 초기 Replayer는 DB 상태 전이만 복구하고 과금 이벤트는 복구하지 않았다. 결과는 절반만 맞았다. DB 기준 리포트 누락은 0%가 됐지만 과금 이벤트 누락이 오히려 늘었다.

벤더는 같은 리포트를 여러 번 보내기도 한다. 그래서 Report 서버에는 SENT → REPORTED 전이에 성공한 경우에만 과금 이벤트를 발행하는 compare-and-set 멱등성 가드가 있었다(status = 'SENT' 조건을 건 UPDATE). Outbox 도입 후 Report 서버와 Replayer 두 경로가 같은 데이터를 보게 됐다. 원문이 적은 순서 역전을 그리면 다음과 같다.

sequenceDiagram
    participant V as 벤더
    participant R as Report 서버
    participant O as Outbox
    participant P as Replayer
    participant DB as 메시지 테이블
    V->>R: 리포트
    R->>O: ① Outbox에 기록
    P->>O: ④ 주기 도래, 미처리 리포트 스캔
    P->>DB: SENT → REPORTED (성공)
    R->>DB: ② SENT → REPORTED 시도
    DB-->>R: 이미 REPORTED, 가드가 무시
    Note over R: ③ 과금 이벤트 발행 안 됨

Replayer가 먼저 REPORTED로 바꿔 버리면 Report 서버의 전이가 가드에 막히고, Replayer에는 과금 발행 로직이 없으니 과금 이벤트가 어디서도 나가지 않았다. “누가 먼저 실행될지”라는 가정을 앞서는 벤더가 깼다면, 이번엔 우리 시스템 내부가 깼다. 순서를 ② → ③ → ①로 강제하면 회피는 되지만 코드 곳곳에 암묵적 제약을 심는 위험한 설계라고 봤다.

조치 4: Single Writer

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

원칙의 출처인 Martin Thompson의 Single Writer Principle(2011)은 한 프로세스 안의 스레드 경합을 다룬다. 원문은 같은 생각을 서비스 경로 수준에 적용했다.

트레이드오프

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

읽고 남는 질문

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

한 줄로 가져가기

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

참고한 자료외부 출처 3

외부 출처

잃어버린 리포트를 찾아서: 카카오 메시징 시스템의 경쟁 조건 문제와 안티 패턴 제거 과정kakao tech, 2026-02-09
Hibernate ORM 6.5 User Guide: FlushingHibernate Docs
Single Writer PrincipleMartin Thompson, Mechanical Sympathy, 2011-09-22

TechBlog, Kakao

Kafka와 메시징 데이터베이스 내부와 트랜잭션 Spring과 JVM 백엔드