ioh's Development

외부 API 호출이 낀 트랜잭션 비관적 락이 답이 아닌 이유

ioh'sDeveloper — Sun, 17 May 2026 18:47:55 +0900

혹시 이런 상황, 생각해본 적 있으신가요?

이커머스에서 결제를 처리한다고 해보자. 요구사항은 한 줄이다.

"결제가 완료되면 PG에 거래 확정 API를 호출하고, 주문 상태를 PAID로 업데이트해줘"

코드로 옮기면 보통 이렇게 시작한다.

@Transactional
public void completePayment(Long orderId) {
    Order order = orderRepository.findById(orderId).orElseThrow();
    pgClient.confirm(order.getPgKey());   // 외부 HTTP 호출
    order.markPaid();                      // DB 상태 변경
}

이 코드를 본 동료가 묻는다.

"동시성 문제가 있을 것 같은데, 비관적 락 추가하면 어때요? SELECT ... FOR UPDATE 걸어두면 안전하지 않나요?"

직관적으로는 맞는 말처럼 들린다. 락 걸면 동시 수정 못 하니까 안전해 보인다. 근데 이게 이 문제의 본질일까?

이 글은 "외부 API 호출이 끼어든 트랜잭션"에서 락이 왜 적절한 도구가 아닌지, 그럼 뭘 써야 하는지 정리한 내용이다.

TL;DR

동시성과 정합성은 다른 문제다. 락은 동시성 도구이고, 분산 정합성은 다른 차원의 문제다.
DB 트랜잭션은 외부 HTTP 호출을 enlist하지 않는다. @Transactional 롤백으로 PG 호출을 되돌릴 수 없다.
비관적 락 + 외부 HTTP 호출 = 락 점유 시간이 HTTP 타임아웃에 따라붙는다. 가용성이 망가진다.
써야 할 도구는 따로 있다: 호출 순서 설계, 멱등성, Outbox, Saga.

1. 한 줄 요구사항이 왜 분산 트랜잭션 문제가 되는가

위 코드의 트랜잭션 경계를 그려보자.

@Transactional이 통제하는 건 왼쪽 박스뿐이다. HTTP 화살표를 타고 넘어간 순간, 그 결과는 우리 트랜잭션의 손이 닿지 않는다.

트랜잭션 경계가 두 개라는 얘기다.

우리 DB: JDBC/JPA 트랜잭션 매니저가 통제. @Transactional 롤백으로 되돌릴 수 있음
외부 PG: 자기들의 트랜잭션 경계. 우리 트랜잭션에 enlist되지 않음

여기서 "enlist"라는 단어가 중요하다. Java의 JTA/XA 세계에서 트랜잭션 매니저는 여러 리소스(DataSource, JMS 등)를 한 트랜잭션 아래로 묶는데, 이걸 "리소스가 트랜잭션에 enlist된다"고 표현한다 (javax.transaction.Transaction#enlistResource()). HTTP 클라이언트는 enlist 대상이 아니다. PG 서버는 자기네 DB에 거래를 기록했을 뿐, 우리 트랜잭션의 일부가 아니다.

"그럼 2PC/XA를 쓰면 되지 않나요?"

이론적으로 맞다. 분산 트랜잭션의 정석은 2PC(Two-Phase Commit)다. 근데 현실은:

외부 SaaS는 XA를 지원하지 않는다. PG, 메시징, 알림, 검색 인덱스, 어느 것도 XA endpoint를 노출하지 않는다
지원한다 해도 운영 부담이 크다. 코디네이터 단일 장애점, blocking 특성, 성능 저하
마이크로서비스 시대로 넘어오면서 2PC는 사실상 사라졌다 (Pat Helland, "Life beyond Distributed Transactions", 2007)

즉, 분산 트랜잭션을 포기한 채로 정합성을 맞춰야 한다. 모든 문제의 출발점은 여기다.

2. 실패 모드 매트릭스 — 어떤 일이 벌어질 수 있나

"실패하면 어떻게 되지?"를 표 한 장으로 정리하면 문제의 전체 그림이 보인다.

	DB write	PG API	결과 상태	비즈니스 임팩트
1	성공	실패	우리: PAID / PG: 미확정	정산 시 불일치, CS 문의 다수
2	실패	성공	우리: 주문 없음 / PG: 결제 완료	PG는 돈을 받았는데 우리 시스템에 주문이 없음
3	성공	성공	정합	정상
4	?	타임아웃	API가 처리됐는지 미상	재시도 시 중복 결제 위험
5	성공	성공	클라이언트 응답 실패	사용자가 재시도 → 중복 주문

분산 정합성 글들이 보통 패턴 소개로 바로 넘어가는데, 이 표를 먼저 그려보지 않으면 패턴이 와닿지 않는다. 막아야 하는 게 정확히 뭔지 모르는 상태에서 도구를 고르는 셈이라서.

가장 까다로운 케이스 두 개

케이스 2 (DB 실패 + API 성공): PG는 돈을 받았는데 우리 DB에 주문이 없다. 사용자 입장에서 "결제는 됐는데 주문 내역이 없다"는 상황. 환불 처리 자동화도 어렵다.

케이스 4 (타임아웃): PG가 요청을 받아 처리는 끝냈는데 우리가 응답을 못 받았다. 재시도하면 케이스 5처럼 중복이 된다. 깔끔하게 푸는 방법은 멱등성 키다. (차선책으로 거래 상태 조회 API(GET /transactions/{key}/status)로 처리 여부를 확인한 뒤 분기할 수도 있지만, 조회-처리 사이의 race를 또 신경 써야 해서 멱등성 키만큼 깔끔하지 않다.)

3. 순진한 1차 시도들 — 각 안의 정합성 구멍

이제 코드로 돌아가서, 호출 순서를 어떻게 잡든 정합성 구멍이 어디에 뚫리는지 보자.

안 A: API 먼저 → DB 나중

@Transactional
public void completePayment(Long orderId) {
    pgClient.confirm(order.getPgKey());   // 1. PG 먼저
    order.markPaid();                      // 2. DB 나중
}

✅ API 실패 시 DB는 손도 안 댐
❌ API 성공 후 DB 실패 시 정합 깨짐 (케이스 2)
❌ DB write 시간만큼 정합성 깨진 윈도우 존재

안 B: DB 먼저 커밋 → API 나중

@Transactional
public void updateOrder(Long orderId) {
    order.markPaid();   // DB 먼저
}

public void completePayment(Long orderId) {
    updateOrder(orderId);                   // 트랜잭션 종료
    pgClient.confirm(order.getPgKey());     // 그 다음 API
}

✅ DB는 확정된 상태
❌ API 실패 시 우리만 PAID (케이스 1)
❌ API 실패해도 DB 롤백 불가 (이미 커밋됨)

안 B2: DB write 사이에 API 끼움

@Transactional
public void completePayment(Long orderId) {
    order.markPaid();                        // DB write 1
    pgClient.confirm(order.getPgKey());      // API
    inventoryRepo.decrement(order.itemId()); // DB write 2
    eventLogRepo.insert(...);                // DB write 3
}

이게 까다로운 패턴이다. 안 A, B의 문제를 둘 다 갖고 있어서.

API 호출 후 DB write 2/3가 실패하면 → 트랜잭션 롤백 → 그런데 PG는 이미 확정됨
결과: PG는 거래 확정, 우리는 주문이 롤백된 상태로 남음
추적도 어렵다. "어디서 API 호출했지?" 코드 중간 어딘가에 끼어있어서.

안 C: 트랜잭션 내 마지막 statement로 API, 실패 시 예외 → 롤백

@Transactional
public void completePayment(Long orderId) {
    Order order = orderRepository.findById(orderId).orElseThrow();
    order.markPaid();                        // DB write
    inventoryRepo.decrement(order.itemId()); // DB write
    eventLogRepo.insert(...);                // DB write
    
    try {
        pgClient.confirm(order.getPgKey());  // ★ 마지막 statement
    } catch (Exception e) {
        throw new PaymentConfirmException("PG 확정 실패", e); // 롤백 유도
    }
}

✅ 모든 DB write 직후, 외부 호출이 마지막. API 실패 시 RuntimeException → 트랜잭션 롤백 → DB write 모두 무효화
✅ 안 B2의 "중간 끼임" 문제 차단
❌ 타임아웃 케이스(케이스 4)는 여전히 잔존. API가 처리됐는지 모르는 상태에서 우리는 롤백한다 → PG는 확정, 우리는 무효화
❌ 케이스 2 (DB 실패 + API 성공)도 발생 가능성은 줄지만 제거되지 않음. 예: API 호출 직후 JVM crash, 커밋 직전 네트워크 단절 등

안 C가 1차 방어선으로는 합리적이다. 운영 코드에서 가장 자주 보이는 패턴이고, 단순함의 가치가 크다. 다만 이게 끝은 아니라는 게 포인트다.

4. 여기서 "락을 걸면 안전해지지 않나요?" 가 등장한다

이제 처음 동료의 질문으로 돌아온다.

"비관적 락 걸면 동시성 안전해지지 않나요?"

왜 이게 진단을 잘못 짚은 건지 보자.

진단 오류 1: 동시성 vs 정합성은 다른 문제다

락이 해결하는 문제:

같은 row를 두 트랜잭션이 동시에 수정 → Lost Update, Phantom Read 등

우리가 풀어야 하는 문제:

DB 상태와 PG 상태의 일치
한쪽이 실패했을 때 다른 쪽을 어떻게 되돌릴 것인가

락은 한 시스템 내부의 동시성을 다루고, 분산 정합성은 두 시스템 간 상태의 일치를 다룬다. 문제가 다르면 도구도 달라야 한다.

위 실패 모드 매트릭스(섹션 2)의 케이스 1~5 중 락으로 해결되는 게 하나라도 있는가? 없다. 케이스 1, 2, 4, 5 모두 동시성과 무관하다. 동일 사용자의 단일 요청에서도 발생한다.

진단 오류 2: 비관적 락 + HTTP 호출은 가용성을 갉아먹는다

오히려 이쪽이 더 큰 문제다. SELECT ... FOR UPDATE를 트랜잭션 내에 두면, 락 점유 시간이 트랜잭션 길이와 같아진다. 트랜잭션 안에 HTTP 호출이 있다면?

락 점유 시간 = DB write 시간 + HTTP 호출 시간(p99 포함)

숫자로 보자.

PG API 평균 응답: 200ms
p99 응답: 3,000ms (3초)
결제 TPS: 100

이때 비관적 락을 걸면 (Little's Law, L = λ × W):

평소 락 보유 트랜잭션 수 ≈ TPS × 평균 락 점유 시간
                          ≈ 100 × 0.2s = 20개

PG가 느려져 응답이 p99(3초)에 몰리는 구간에서는
락 점유 시간 W가 한꺼번에 늘어나면서 락 보유 트랜잭션 수가
순식간에 수십~수백 개까지 치솟는다.
(극단 가정으로 모든 요청이 3초씩 걸린다면 100 × 3.0s = 300개)

DB 커넥션 풀이 30~50이라면? PG 지연 구간에 풀이 고갈되고, 평소엔 멀쩡하던 우리 서비스가 외부 API 한 번 흔들릴 때마다 같이 쓰러진다. 락 + HTTP 조합이 가진 구조적인 문제다.

그리고 한 가지 더.

PG가 한 번 느려지면 → 락 점유 시간 ↑ → 후속 요청 대기 ↑ → 더 많은 락 점유 → 연쇄 장애
다른 트랜잭션이 동일 row를 만지러 오면 → 락 대기 → 데드락 가능성 ↑

정합성 문제를 풀어주지도 못하면서, 외부 API의 지연을 우리 시스템 전체로 옮겨오는 셈이다.

진단 오류 3: 낙관적 락도 마찬가지

"비관적 말고 낙관적 락은요?"

version 컬럼으로 충돌 감지 → 충돌 시 재시도
✅ 락 점유 시간 문제 없음
❌ 여전히 외부 API enlist 못 함. 케이스 1~5 중 어느 것도 해결 안 됨

낙관적 락은 "같은 row의 동시 수정"을 검출하는 도구일 뿐이다. PG와 우리 DB의 정합성을 보장하는 것과는 무관하다.

그래도 동시 수정이 정말 문제라면?

같은 주문을 두 요청이 동시에 처리할 우려가 정말 있다면, 그건 별도의 문제로 분리해서 풀어야 한다.

멱등성 키(Idempotency-Key)로 동일 요청 중복 차단
주문 상태 머신으로 PENDING → PAID 단방향 전이만 허용 (이미 PAID면 에러)
필요하면 짧은 application-level mutex(Redis lock 등)로 동일 orderId만 직렬화. 단, 외부 API 호출은 mutex 밖으로 빼야 한다

락은 도메인적으로 동시성 제어가 정말 필요한 곳에만, 외부 호출과 분리해서 쓴다.

5. 그럼 뭘 써야 하나 — 도구 스펙트럼

분산 트랜잭션 없이 정합성을 맞추는 데 쓰이는 패턴들을 정리해보자.

패턴 1: 호출 순서 + 즉시 실패 전파 (안 C의 본질)

@Transactional
public void completePayment(Long orderId) {
    // 1. 모든 DB write
    order.markPaid();
    inventoryRepo.decrement(order.itemId());
    eventLogRepo.insert(...);
    
    // 2. 마지막에 외부 호출, 실패 시 예외로 롤백 유도
    try {
        pgClient.confirm(order.getPgKey());
    } catch (Exception e) {
        throw new PaymentConfirmException(e);
    }
}

언제 쓰나: 외부 호출이 동기적이고 응답이 빠르며, 실패 시 트랜잭션 전체를 무효화하는 게 비즈니스적으로 자연스러울 때
장점: 단순함. 인프라 추가 없음. 안 B2의 중간 끼임 차단
한계: 타임아웃 / JVM crash 케이스 잔존. 외부 호출이 길면 트랜잭션 길이 ↑

패턴 2: 멱등성 키 + 재시도

String idempotencyKey = "order-" + orderId + "-confirm";

pgClient.confirm(
    order.getPgKey(),
    idempotencyKey   // 같은 키로 재시도해도 PG는 한 번만 처리
);

언제 쓰나: 외부 API가 멱등성 키를 지원할 때 (Stripe, Toss, PortOne 등 모던 PG는 대부분 지원)
장점: 케이스 4 (타임아웃) 해결. 재시도 안전
한계: 외부 API의 지원이 전제. 키 관리 / TTL 정책 필요

패턴 3: Outbox 패턴

@Transactional
public void completePayment(Long orderId) {
    order.markPaid();
    
    // 외부 호출 대신, "외부 호출이 필요하다"는 메시지를 같은 트랜잭션에 INSERT
    outboxRepo.insert(new OutboxMessage(
        "PG_CONFIRM",
        orderId,
        order.getPgKey()
    ));
}

// 별도 워커가 outbox를 polling/CDC로 읽어서 외부 호출
// ★ 다중 인스턴스 환경이면 SELECT ... FOR UPDATE SKIP LOCKED 또는
//    ShedLock 같은 분산 락으로 같은 메시지를 두 워커가 동시에 집지 않게 막아야 한다.
@Scheduled(fixedDelay = 1000)
public void relayOutbox() {
    outboxRepo.findUnprocessedForUpdateSkipLocked(BATCH_SIZE).forEach(msg -> {
        pgClient.confirm(msg.getPgKey(), msg.getIdempotencyKey());
        outboxRepo.markProcessed(msg.getId());
    });
}

언제 쓰나: 외부 호출을 트랜잭션과 완전히 분리하고 싶을 때. 비동기 처리 허용될 때
장점: 트랜잭션 내에서 외부 호출 사라짐. 메시지 발행이 DB 커밋과 원자적. 재시도 자유로움
한계:
- 비동기 → "결제 확정"이 즉시가 아닌 수 초 후. UX 영향
- 워커 운영 부담 + 다중 인스턴스 중복 처리 방지 장치 필요 (위 코드의 SKIP LOCKED)
- Outbox는 at-least-once delivery라, 워커 crash나 markProcessed 실패로 같은 메시지가 두 번 발행될 수 있다. 외부 API에 멱등성 키 전달이 사실상 필수인 이유다 (위 코드의 msg.getIdempotencyKey())

패턴 4: Saga / 보상 트랜잭션

여러 단계에 걸친 분산 트랜잭션을, 단계별 보상 액션과 함께 정의한다.

각 단계가 실패하면, 거기까지 진행된 단계들을 역순으로 보상한다. "원자적 롤백"이 안 되니, "수동으로 되돌리는 절차"를 코드로 정의해두는 것이다.

언제 쓰나: 단계가 많고, 일부 실패 시 앞 단계를 보상해야 할 때
장점: 명시적 보상 액션. 단계별 독립성
한계: 복잡도 ↑. 보상 액션 정의가 어려운 도메인(예: 이메일 발송) 존재. Saga orchestrator 운영

패턴 5: (참고) 2PC/XA

전통적 분산 트랜잭션. 코디네이터가 모든 참가자에게 prepare → commit을 조율한다.

언제 쓰나: 강일관성 필수 + 모든 참가자가 XA 지원할 때 (사실상 사내 RDBMS + JMS 정도)
현실: 외부 SaaS는 미지원. 마이크로서비스 시대에는 사실상 사용되지 않음

패턴 비교표

패턴	외부 API 의존	비동기 허용	복잡도	인프라
호출 순서 + 실패 전파	트랜잭션 내 동기	불가	낮음	없음
멱등성 키	키 지원 필수	둘 다	낮음	없음
Outbox	분리	필수	중간	워커 / 메시지 큐
Saga	분리	필수	높음	Orchestrator
2PC/XA	XA 지원 필수	불가	높음	코디네이터

6. 결정 트리 — 내 상황에 뭘

골라야 하나

추가 체크 항목

트래픽 수준: 결제 TPS 10 vs 1,000은 다른 세상
실패 허용도: 메시징 알림 실패는 재시도 큐로, 결제 실패는 즉시 알림
외부 API SLA: p99 500ms 이내 보장되면 패턴 1 가능, 아니면 비동기
운영 인프라: Kafka / Outbox 워커 운영 가능한 조직인가?

현실적인 시작점: 대부분의 경우 패턴 1 + 패턴 2 조합으로 시작해서, 트래픽이 늘거나 외부 API 안정성이 떨어지면 패턴 3 (Outbox)로 진화한다. 처음부터 Saga까지 가는 건 오버엔지니어링인 경우가 많다.

7. 보너스: 논블로킹 환경에서는 어떻게 달라지나

Coroutine / WebFlux 같은 논블로킹 환경에서는 트랜잭션 경계가 어떻게 동작할까?

스레드와 트랜잭션 매니저의 결합

전통적인 Spring @Transactional(= PlatformTransactionManager + JDBC/JPA)은 ThreadLocal(TransactionSynchronizationManager)에 트랜잭션 상태를 저장한다. 같은 스레드에서 실행되는 동안만 트랜잭션이 이어진다.

문제는 Coroutine이다. suspend 후 재개될 때 다른 스레드에서 실행될 수 있고, ThreadLocal 기반 트랜잭션 매니저는 이걸 따라가지 못한다.

// ⚠ PlatformTransactionManager(JDBC/JPA) 기반에서 suspend 함수와 @Transactional을
//   섞으면 트랜잭션 컨텍스트가 suspend 경계를 못 넘는다.
@Transactional
suspend fun completePayment(orderId: Long) {
    val order = orderRepository.findById(orderId)
    order.markPaid()
    pgClient.confirm(order.pgKey)   // suspend point — 스레드가 바뀔 수 있음
    eventLogRepo.insert(...)        // 재개된 스레드에 트랜잭션 컨텍스트가 없을 수 있음
}

덧붙이면, JPA 자체가 blocking API라 coroutine/WebFlux 스택과는 궁합이 나쁘다. reactive 환경에서는 보통 R2DBC를 쓴다.

R2DBC / Reactive 환경에서는 다르다

Reactive 스택(ReactiveTransactionManager + R2DBC)에서는 트랜잭션 상태가 ThreadLocal이 아니라 Reactor Context로 전파된다. Reactor Context는 비동기 경계를 따라 흐르기 때문에 suspend 후 스레드가 바뀌어도 트랜잭션이 유지된다. 이 스택에서는 @Transactional suspend fun도 정상 동작하고, 흐름을 명시적으로 제어하고 싶으면 TransactionalOperator를 쓴다.

suspend fun completePayment(orderId: Long): Order =
    transactionalOperator.executeAndAwait {
        val order = orderRepository.findById(orderId).awaitSingle()
        order.markPaid()
        pgClient.confirm(order.pgKey).awaitSingle()
        order
    }

다만 한 가지. 트랜잭션이 비동기 경계를 잘 넘어간다는 건, 거꾸로 말하면 트랜잭션이 열린 채로 외부 HTTP 호출을 기다리는 시간도 그대로 유지된다는 뜻이다. reactive로 바꾼다고 "트랜잭션 안에서 외부 API 호출"이 안전해지지는 않는다. 호출 시간만큼 R2DBC 커넥션을 잡고 있는 건 똑같다.

락은 오히려 더 까다로워진다

논블로킹 환경에서 비관적 락은 다루기 더 어려워진다.

suspend 지점(외부 I/O 대기)에서도 락은 계속 잡혀 있다. I/O 대기 시간이 곧 락 점유 시간이다. 블로킹과 본질은 같은데, "스레드는 안 쓰니까 괜찮다"는 착각이 위험을 가린다
락을 잡은 코루틴이 cancel되면 락 해제 보장이 까다로워진다. finally 블록 + 명시적 해제 + structured concurrency까지 신경 써야 한다
"적은 스레드로 많은 요청 처리"라는 논블로킹의 장점이, 락으로 직렬화되는 구간에서는 무력화된다

그래서 논블로킹 환경에서는 락보다 멱등성/Outbox 기반 설계가 자연스럽다. 외부 호출을 어차피 비동기로 처리할 거고, 트랜잭션 경계와 외부 호출을 분리하는 쪽이 패러다임과도 맞는다.

8. 마무리

처음 질문으로 돌아가자.

"비관적 락 걸면 동시성 안전해지지 않나요?"

이제 답할 수 있다. 락은 한 시스템 내부 데이터의 일관성을 다루는 도구이고, 분산 정합성은 두 시스템 간 상태의 일치를 다루는 다른 문제다. 같은 단어("안전")로 묶여 있을 뿐, 문제도 도구도 다르다.

외부 API 호출이 끼어든 트랜잭션에서 락을 먼저 꺼내드는 게 위험한 이유는 세 가지가 겹친다. 케이스 1~5 중 어느 것도 해결되지 않고, 락 점유 시간이 HTTP 타임아웃에 종속되며, 그 지연이 다른 트랜잭션으로 옮겨가면서 연쇄 장애를 만든다. 정합성도 못 잡고 가용성도 같이 잃는 셈이다.

실제로 써야 할 도구는 호출 순서 설계, 멱등성 키, Outbox, Saga 쪽이다. 시작은 호출 순서와 멱등성으로도 충분한 경우가 많고, 트래픽이 커지거나 외부 API가 불안정해지면 Outbox로 넘어가게 된다.

핵심은 도구 선택 이전이다. "동시성 문제 같으니까 락" 하고 반사적으로 넘어가지 말고, 섹션 2 같은 실패 모드 매트릭스를 한 번 그려보면 막아야 할 케이스가 보이고, 거기서부터 도구가 자연스럽게 좁혀진다.

참고 자료

Pat Helland, "Life beyond Distributed Transactions: an Apostate's Opinion" (2007)
Martin Kleppmann, Designing Data-Intensive Applications, Chapter 7~9 (Transactions, Distributed Trouble, Consistency)
Chris Richardson, Microservices Patterns — "Managing transactions with sagas" 챕터, "Transactional Outbox / Polling Publisher / Transaction Log Tailing" 패턴
microservices.io — Saga Pattern, Transactional Outbox
Stripe API Reference — Idempotent Requests

WIL - 10주차 (10주 동안 내가 단단해진 곳은 기술만이 아니었다)

ioh'sDeveloper — Sun, 19 Apr 2026 21:39:41 +0900

이번 주에 새로 배운 것

개념을 제대로 이해하면, 아키텍처가 보이기 시작한다

이번 주에 가장 크게 느낀 건 "개념을 정확히 아는 것이 아키텍처 역량과 연결된다"는 거였다. 예전엔 아키텍처를 잘 짜는 사람은 뭔가 감이 좋은 사람이라고 막연히 생각했다. 그런데 10주를 돌아보니 그게 아니었다. 개념 하나를 깊이 이해하면 그 개념이 설계 선택의 근거가 되고, 근거가 쌓이면 아키텍처가 자연스럽게 나온다.

복합 인덱스의 B+Tree 리프 노드 정렬 방식을 이해하니까 "카디널리티가 먼저가 아니라 등호 조건이 먼저"라는 실제 규칙이 보였고, 트랜잭션이 ThreadLocal에 바인딩된다는 걸 직접 코드로 부딪혀보니까 비동기 콜백에서 왜 @Transactional이 안 먹히는지가 설명이 됐다. 원리를 안 채로 설계를 하는 것과 감으로 설계를 하는 것은 결과물의 단단함이 완전히 다르다.

아키텍처를 배우러 왔는데, 결국 원리를 배우는 게 아키텍처를 배우는 길이었다. 이 순서가 반대였으면 10주가 훨씬 더 얕게 지나갔을 것 같다.

개발자에게 기술만큼 중요한 건 소통이었다

10주 동안 기술 말고 가장 많이 훈련된 건 소통이었다. 혼자 끙끙대던 문제가 한 번의 대화로 풀린 적이 정말 많았다. 팀원들과 이야기하면서 내 사고의 막힌 부분이 드러났고, 멘토님들께 질문을 던지면서 내가 뭘 모르는지가 오히려 선명해졌다. 혼자 생각하면 같은 자리를 도는데, 사람과 이야기하면 앞으로 갔다.

회사에서도 같은 걸 체감했다. 데드라인이 빠듯한 상황에서 리드분의 의견을 수용하면서도 놓칠 수 없는 부분을 문서로 정리해 제안했고, 프론트 개발자분들 질문에 하나하나 답하면서 팀이 앞으로 나아갈 수 있게 도왔다. 기술만 잘한다고 결과가 나오는 게 아니었다. 기술을 말로 옮기고, 상대방의 말을 받아들이고, 다시 내 언어로 돌려주는 능력이 결국 같이 일을 풀어내는 힘이었다.

개발은 혼자 하는 일이 아니라는 걸, 10주 내내 계속 확인한 셈이다.

모든 피드백은 재료다, 단 내 생각을 좁히지만 않으면

3주차에 "Blue Book 스타일(Domain Service → Repository 직접 호출)"을 택했을 때, 이 방식에 동의하는 의견은 많지 않았다. 솔직히 처음엔 흔들렸다. 그런데 곰곰이 생각해보니 내 선택에는 내 근거가 있었고, 다른 분들의 의견에도 각자의 근거가 있었다. 한쪽이 진리고 한쪽이 틀린 게 아니었다.

그때부터 피드백을 받는 방식이 조금씩 달라졌다. 누군가의 말을 곧바로 진리로 받아들이지도 않고, 반대로 반사적으로 밀어내지도 않는다. 일단 전부 재료로 놓고, 내 맥락에 맞는 부분은 가져가고, 맞지 않는 부분은 이유와 함께 걷어낸다. 이 태도가 되니까 피드백이 무서운 게 아니라 도움이 됐다. 기분이 상하는 일도 줄었다. "이 사람은 왜 이렇게 말했을까"를 먼저 생각하니까, 그 뒤에 내 판단을 세우는 게 편해졌다.

모든 사람의 말이 다 내 피드백이고 도움이 된다는 감각. 다만 거기서 내 생각을 좁히지 않는 것. 이 두 가지를 10주 동안 계속 연습한 것 같다.

회고 스터디는 앞으로도 계속 해보고 싶다

매주 WIL을 쓰고, 다른 개발자들과 회고를 나누고, 다른 사람의 회고를 읽으면서 얻은 게 생각보다 컸다. 회고를 쓰면 그 주에 뭘 했는지가 객관화되고, 다음 주에 뭘 바꿔야 할지가 보인다. 처음엔 기록용이었는데, 지나고 나니 회고가 성장의 축이었다.

기술 블로그도 좋지만, 회고는 다르다. 블로그는 "알게 된 것"을 정리하는 거라면, 회고는 "그 과정에서 내가 어떻게 움직였는지"를 정리한다. 움직임을 기록해두니까 패턴이 보이기 시작했다. 내가 어떤 상황에서 시간을 많이 쓰고, 어떤 순간에 돌파구를 만들어내는지가 몇 주가 쌓이니까 드러났다. 이 패턴은 블로그로는 절대 남지 않는다.

앞으로도 이 회고 습관은 가져가고 싶다. 혼자 쓰는 것도 좋지만, 함께 했던 회고 스터디가 훨씬 힘이 됐다. 다른 사람의 시선이 들어오면 내 회고도 더 날카로워진다. 끝나더라도 비슷한 형태로 이어갈 방법을 찾아보려 한다.

이런 고민이 있었어요

10주 동안 지나온 길을 돌아보면

1주차에는 TDD라는 과제로 시작했다. 테스트가 구현 뒤에 붙는 게 아니라 설계를 끌어내는 도구라는 걸 몸으로 배우면서, 첫 주부터 "왜?"를 붙이는 습관이 시작됐다. 2주차에는 유비쿼터스 언어를 먼저 정의하고 들어가니 ERD와 시퀀스 다이어그램이 같은 방향으로 따라붙었다. 용어가 설계의 출발점이 될 수 있다는 걸 이때 알았다.

3주차와 4주차는 도메인 모델링과 트랜잭션/동시성 제어였다. 순수 POJO를 끝까지 밀고 간 결정, 도메인별 Lock 전략을 근거 있게 고른 경험이 이 시기의 중심이었다. "감수와 타협은 다르다"라는 문장도 이때 생겼다. 5주차에는 읽기 성능 최적화로 넘어가면서 인덱스, 캐시, 비정규화, 파티셔닝을 원리 수준에서 파고들었고, 블로그 세 편을 이 주제로 썼다. "왜?"를 끝까지 던지면 글감이 자연스럽게 만들어진다는 걸 알게 된 시기다.

6주차 PG 연동에서는 외부 시스템의 불확실성을 처음으로 설계에 담아봤다. UNKNOWN이라는 상태를 인정하는 것이 분산 설계의 출발점이라는 것, 서킷브레이커는 재시도 도구가 아니라 장애 격리 도구라는 것이 이때 체득됐다. 7주차는 Kafka Outbox와 EDA였다. @TransactionalEventListener 동작을 세 번 시도한 끝에 가장 단순한 답에 도달했고, 이론값 500건/초와 실측값 95건/초의 격차를 분석하면서 시스템을 진짜 이해하는 경험을 했다.

8주차 대기열에서는 배치 크기 M을 방정식으로 역산했다. 숫자 하나에 근거가 생기니까 그 근거가 여러 설계 결정을 동시에 받쳐줬다. 이 경험이 회사 테이블 튜닝 권한을 받아내는 데까지 이어졌다는 게 개인적으로 가장 뿌듯한 순간이었다. 9주차는 Redis ZSET 랭킹이었는데, "best-effort"라는 단어 하나로 사고를 멈추면 안 된다는 걸 배웠다. 같은 best-effort 안에서도 over-count와 under-count는 완전히 다른 결함이다. 이 구분이 설계였다.

10주차 Spring Batch 랭킹에서는 정교하게 쌓아 올린 답이 틀린 전제 위에 있으면 통째로 무의미해진다는 걸 경험했다. AI와의 설계 대화도, 내 논리도, 코드를 먼저 읽지 않은 상태에서는 공중에 떠 있었던 셈이다. 10주의 마지막 주에 "답을 의심하기 전에 질문을 의심하라"를 배우게 된 게 의미 있었다.

10주를 쭉 이어놓고 보니, 주제는 매주 바뀌었는데 훈련된 근육은 하나였다. "왜 이 선택인가"를 설명할 수 있는 근육. 기술 하나를 배우는 게 아니라 이 근육을 키우는 10주였다.

기술적으로 나에게 남은 것

10주 동안 쌓인 기술 근육을 정리해보면 결국 몇 가지로 추려진다. 트랜잭션 경계를 스스로 설계할 수 있게 됐다는 것 — 언제 전파를 쓰고, 어디서 REQUIRES_NEW로 분리하고, 어떤 경우에 원자적 UPDATE로 가야 하는지를 근거 있게 말할 수 있게 됐다. 동시성 제어도 더 이상 "락 걸면 되겠지"가 아니다. 비관적 락, 낙관적 락, 원자적 UPDATE 중에서 도메인 특성에 맞는 걸 고르는 기준이 머릿속에 자리 잡았다.

읽기 성능 영역에서는 복합 인덱스 컬럼 순서, 커버링 인덱스, Buffer Pool과 캐시의 상호작용, readOnly 전파와 Replication Lag까지 원리 수준에서 설명할 수 있게 됐다. 캐시 도입이 오히려 p95를 악화시키는 역설까지 경험했으니, "캐시는 은탄환이 아니다"라는 문장이 체화됐다.

외부 시스템 연동은 6주차 PG에서 크게 배웠다. 성공/실패 이분법이 통하지 않는 세계가 있다는 것, UNKNOWN 상태를 명시적으로 설계에 담아야 한다는 것, 서킷브레이커·Bulkhead·Retry·Fallback이 각각 다른 관심사를 다룬다는 것. 7주차 Kafka Outbox에서는 @Transactional이 ThreadLocal에 바인딩된다는 사실이 비동기 컨텍스트에서 어떻게 깨지는지를 코드로 재현해보면서 제대로 이해했다. self-invocation 버그도 처음으로 실물로 만났다.

8주차 대기열에서는 "감으로 정한 숫자"에 근거를 대는 훈련을 했다. 커넥션 풀·점유 시간·안전 마진에서 실효 TPS를 역산하는 방법을 익히고 나니, 회사 테이블 튜닝에서 인덱스 하나를 추가할 때도 실행계획과 스캔 건수로 설명할 수 있게 됐다. 9주차와 10주차의 랭킹·배치 과제에서는 "raw fact부터 저장", "수식과 원천 데이터를 분리", "전제를 먼저 의심" 같은 설계 원칙이 자리 잡았다.

이 기술들을 다 외웠다기보다, 각 주제를 파고들면서 "왜 이 선택인가"를 설명하는 감각이 몸에 붙은 게 진짜 자산이다. 기술은 바뀌지만, 이 감각은 다음 기술에도 똑같이 쓰인다.

회사에서도 같이 성장한 10주

루퍼스 10주 동안 회사에서도 프로젝트 두 개를 끌고 갔다. 4주차에는 보험 도메인 신규 프로젝트가 들어왔고, 기획서에 정책이 빠져 있는 부분을 AI로 선제 정리해서 기획 쪽에 제안했다. 기다리는 게 아니라 먼저 움직이니까 데드라인을 앞서갈 수 있었다. 그때부터 "환경이 부족하다"는 말 대신 "지금 내가 뭘 할 수 있지?"를 먼저 묻는 습관이 생겼다.

6주차에는 손해보험 간병서비스 프로젝트에서 청구·지급·입금 세 도메인의 CRUD를 마무리했다. SFTP 연동, 입금 매칭, 상태 전이 같은 실무 로직을 구현하면서 루퍼스에서 배운 것들이 그대로 꽂혔다. "±10원 오차 허용 매칭, 5영업일 후 미해소 처리"라는 정책을 구현할 때, PG 연동에서 설계한 UNKNOWN 패턴과 같은 원리라는 게 보였다. 서로 다른 도메인에서 같은 원리를 발견하는 순간이 실무 감각을 가장 크게 넓혀줬다.

8주차에는 DBA에게 직접 설득해서 테이블 튜닝 권한을 받았다. 예전 같았으면 "이건 DBA 일"이라고 넘겼을 텐데, 5주차 읽기 성능 최적화를 공부하면서 쌓은 근거들이 그 제안을 가능하게 했다. 실행계획 기준 20만 건 스캔, 네이밍 불일치, 수동 DB 작업 반복 같은 구조적 문제를 감정이 아니라 수치로 꺼냈더니 논의가 시작됐다. 학습이 실무의 발언권을 만들어준 경험이었다.

회사와 루퍼스를 병행하면서 가장 크게 느낀 건, 둘이 경쟁 관계가 아니라는 것이다. 회사에서 부딪힌 문제가 루퍼스의 과제가 됐고, 루퍼스에서 공부한 개념이 회사의 설계가 됐다. 이 사이클이 돌아가기 시작하면서 "왜 이걸 따로 공부하지"라는 의문이 사라졌다. 같은 근육을 양쪽에서 쓰고 있었을 뿐이다.

아쉬움이 남는다는 건 욕심이 생겼다는 뜻

매주 정말 열심히 했다고 느꼈는데, 지금 돌아보면 더 파고들 수 있었던 주제들이 떠오른다. 6주차 분산 트랜잭션은 블로그 한 편으로 마무리했는데 서킷브레이커 설계 근거까지 엮어볼 수 있었고, 8주차 n8n은 개념만 알고 레포는 못 만들었다. 10주차 가중치 공식을 DB 테이블로 분리하는 아이디어도 scope 초과라는 이유로 미뤄뒀다.

아쉬움이 남는다는 건 욕심이 생겼다는 거라고 누가 그랬는데, 정확히 그 상태인 것 같다. 10주 전에는 "이 기술 써봤습니다"까지만 말할 수 있었는데, 지금은 더 파고들지 못한 지점이 아쉬움으로 남는다. 출발선이 바뀌어 있다는 뜻이다.

우리 팀이 있어서 끝까지 올 수 있었다

가장 크게 남는 건 사람이다. 기술적으로 막혔을 때 대화로 실마리를 찾았던 순간, 다른 사고방식을 가진 사람을 보면서 내 폭을 넓혔던 순간, 서로 지칠 때 밀어주고 당겨줬던 순간. 이런 게 쌓여서 10주를 버티게 했다. 혼자 있었으면 중간에 멈췄을 고비가 여러 번 있었다.

우리 팀 안에서는 누가 힘들어 보이면 자연스럽게 서기를 대신해주고, 역할이 바뀌면 반대로 기대는 분위기가 있었다. 내가 지쳐있을 때 누군가 먼저 손을 내밀어줬고, 반대로 다른 사람이 힘들어 보일 때 내가 끌어주는 순간도 있었다. 이 작은 배려들이 쌓여서 10주 내내 한 사람도 놓치지 않고 같이 왔다는 게, 끝나갈수록 더 크게 느껴진다.

커뮤니케이션에서도 10주 내내 배웠다. 질문을 많이 하는 편이라 팀에 부담이 됐을 수도 있는데, 한 번도 귀찮은 티 없이 들어주고 같이 고민해줬다. 내가 던진 질문이 다른 사람의 생각을 자극하고, 그 사람의 답이 또 내 사고를 확장시키는 순환이 자연스럽게 돌아갔다. 혼자 생각했으면 한참 돌았을 문제들이 대화 한 번으로 풀린 경험을 반복하면서, 개발자에게 커뮤니케이션이 왜 기술만큼 중요한지를 몸으로 이해했다.

멘토님들과의 대화도 빼놓을 수 없다. 질문을 많이 해서 얻어간 게 정말 많다. 서로 다른 시각을 동시에 놓고 비교하면서 "정답이 하나가 아닌 영역"이라는 감각을 얻었고, 3주차에 내 선택(Blue Book 스타일)을 흔들리지 않고 지킬 수 있었던 것도 이 감각 덕분이다. 질문을 두려워하지 않았던 게 가장 큰 자산이다.

이 시간을 그냥 "빡세게 공부한 10주"로 기억하지 않고, "같이 해낸 10주"로 기억하고 싶다.

앞으로 이렇게 하고 싶어요

개념 공부는 속도가 아니라 깊이로

5주차 이후로 확인한 건, 깊이 있게 이해한 개념 하나가 얕게 훑은 열 개보다 쓰임새가 크다는 거였다. 앞으로도 새로운 주제를 만나면 "왜 그렇게 되는지"를 원리 수준까지 파고드는 습관을 유지하고 싶다. 블로그나 문서로 풀어낼 수 있을 만큼 이해했을 때가 진짜 이해한 거라고 스스로 기준을 세워두려 한다.

소통에서 머뭇거리지 않기

10주 동안 "일단 말하기"가 늘었지만, 여전히 더 나아지고 싶은 부분이다. 틀려도 먼저 꺼내고, 상대 관점을 먼저 물어보고, 내 근거를 같이 설명하는 습관. 개발자에게 이게 기술만큼 중요한 역량이라는 걸 10주 내내 확인했으니, 앞으로도 계속 연습할 생각이다.

모든 피드백은 재료, 내 생각은 안 좁히기

누군가의 말이 진리는 아니지만 전부 참고할 가치가 있다는 태도. 이걸 놓지 않고 싶다. 다른 시각을 듣되 거기서 내 사고를 좁히지 않고, 좋은 건 가져가고 맞지 않는 건 근거와 함께 걷어내는 방식. 이 태도가 있으면 어떤 팀에 들어가도 균형을 잃지 않을 것 같다.

회고 스터디는 형태를 바꿔서라도 이어가기

루퍼스가 끝나도 회고 습관은 계속 가져가고 싶다. 혼자 쓰는 것보다 같이 쓰고 나누는 쪽이 훨씬 효과가 좋으니, 작은 규모로라도 비슷한 스터디를 이어갈 방법을 찾아보려 한다. 나중에 이력 전체를 돌아볼 때, 회고가 쌓인 개발자와 안 쌓인 개발자의 궤적은 분명 다를 거라고 생각한다.

한 줄 요약

10주 동안 단단해진 건 기술만이 아니라 사고 방식, 소통하는 태도, 피드백을 받아들이는 방식, 그리고 꾸준히 돌아보는 습관이었다. 기술은 계속 바뀌겠지만 이 근육들은 어디에 가서도 남는다. 여기까지 올 수 있었던 건 같이 고민하고 같이 버텨준 사람들 덕분이고, 그래서 이 10주가 더 뜻깊게 남는다.

한 번에 끝낼 작업에 청크를 선택했다: 배치 프레임워크를 잘못 고른 비용

ioh'sDeveloper — Fri, 17 Apr 2026 17:25:30 +0900

TL;DR
한 번에 집계해서 교체해야 하는 작업에 청크 기반 처리를 선택하면서, 프레임워크의 장점은 살리지 못하고 복잡성만 늘어났다. 그 과정에서 도구의 형식보다 문제의 본질에 맞는 선택이 더 중요하다는 것을 배웠다.

이번 글에서 다루는 문제

이커머스 서비스에서 “이번 주 인기 상품 TOP 100”을 만들어야 했다.

사용자가 상품을 조회하거나, 좋아요를 누르거나, 주문할 때마다 이벤트가 쌓인다. 이 이벤트를 주 단위로 모아 상품별 점수를 계산하고, 점수가 높은 순서대로 상위 100개 상품을 저장하면 된다.

이미 데이터베이스에는 ranking_event 테이블이 있었다.
이 테이블에는 “어떤 상품에 어떤 행동이 언제 발생했는지”라는 원본 이벤트 데이터가 저장돼 있었다. 이 데이터를 다시 읽어서 원하는 방식으로 점수를 계산할 수 있는 구조였다.

해야 할 일은 아래와 같았다.

이번 주 이벤트를 모두 읽는다.
상품별 점수를 계산한다.
점수가 높은 순서대로 상위 100개를 뽑는다.
결과를 조회용 집계 테이블에 한 번에 반영한다.

이 작업을 스프링 배치(Spring Batch)로 구현하려고 했고, 여기서 첫 번째 선택이 생겼다.
한 번에 처리할 것인가, 나눠서 처리할 것인가.

선택지: Tasklet과 Chunk

스프링 배치에는 대표적으로 두 가지 방식이 있다.

Tasklet은 작업을 한 번에 처리하는 방식이다.
하나의 메서드 안에서 읽기, 계산, 저장을 모두 끝낸다. SQL로 집계해서 바로 저장하는 작업에 잘 맞는다.

Chunk는 데이터를 일정 단위로 나눠 처리하는 방식이다.
정해진 개수만큼 읽고, 가공하고, 저장하는 흐름을 반복한다. 대량 데이터를 조금씩 처리해야 할 때 유리하다.

정리하면 이렇다.

구분TaskletChunk

처리 방식	한 번에 처리	일정 크기로 나눠 반복 처리
트랜잭션	전체 작업 기준	청크 단위 기준
장애 시 특성	전체 성공 또는 전체 롤백	이미 커밋된 청크는 남을 수 있음
잘 맞는 작업	집계, 단순 일괄 처리	대량 데이터 읽기·변환·저장

그렇다면 이번 작업의 본질은 무엇이었을까.

이번 작업은 데이터를 조금씩 처리해서 중간 결과를 계속 저장하는 작업이 아니었다.
전체 이벤트를 다 읽고 나서야 최종 순위를 계산할 수 있는 집계 작업이었다.

100위에 들어갈 상품이 무엇인지는 마지막 이벤트까지 모두 봐야 알 수 있다.
즉, 이 작업은 처음부터 끝까지 본 뒤 최종 결과를 한 번에 반영하는 방식이 더 잘 맞았다.

돌이켜보면, 이 요구사항에는 Tasklet이 더 잘 맞는 선택이었다.

그런데 왜 Chunk를 선택했을까

그럼에도 나는 Chunk를 선택했다. 이유는 두 가지였다.

첫째, 학습 목적이었다.
청크 기반 처리 방식의 구조를 직접 구현해 보면서 읽기, 가공, 저장의 책임 분리와 처리 단위를 체감해 보고 싶었다.

둘째, 자바 로직을 재사용하고 싶었다.
점수 계산 방식은 다른 실시간 처리 로직에서도 쓰고 있었기 때문에, SQL에 점수 계산식을 하드코딩하기보다 자바 계산기를 재사용하면 두 경로의 계산 규칙을 맞추기 쉽다고 생각했다.

선택 자체는 나름 합리적으로 보였다.
문제는 작업의 성격보다 도구의 학습 효과를 더 앞세웠다는 점이었다.

구현을 시작하자 바로 충돌이 났다

청크 기반 처리 방식의 일반적인 흐름은 이렇다.

데이터를 일정 크기만큼 읽는다.
읽은 데이터를 가공한다.
가공한 결과를 저장한다.
이 과정을 반복한다.

그런데 이번 랭킹 집계는 중간 결과가 노출되면 안 됐다.

예를 들어 1위부터 50위까지만 새 데이터로 바뀌고, 51위부터 100위는 이전 데이터가 남아 있으면 사용자는 반쯤 갱신된 랭킹을 보게 된다. 이건 허용할 수 없는 상태였다.

즉, 이 작업에는 전부 반영되거나 아예 반영되지 않아야 하는 원자적 교체가 필요했다.

그래서 실제 구현은 청크 방식의 장점을 살리지 못하는 구조가 됐다.

읽기와 점수 계산은 청크로 처리했다.
하지만 저장은 청크마다 하지 않았다.
각 청크 결과를 메모리에 누적해 두었다가,
작업 단계가 끝난 뒤 한 번에 삭제하고 다시 넣는 방식으로 교체했다.

겉으로는 청크 방식이었지만, 실제 핵심 저장 로직은 마지막에 한 번에 실행됐다.
즉, 형식은 Chunk였지만 결과적으로는 한 번에 처리하는 방식과 비슷하게 흘렀다.

첫 번째 대가: 실패 시 기존 데이터까지 사라질 수 있었다

문제는 작업 단계가 끝난 뒤 실행되는 afterStep() 콜백에 있었다.

처음에는 이 콜백이 작업이 성공했을 때만 실행될 것처럼 생각했다. 그런데 실제로는 성공하든 실패하든 항상 호출되는 구조였다.

이 사실을 모른 채 구현하면 어떤 일이 생기느냐.

이벤트를 읽는 도중 실패한다.
작업 단계는 실패로 끝난다.
그런데 afterStep()은 여전히 호출된다.
여기서 기존 랭킹 데이터를 삭제한다.
새로 넣을 누적 데이터는 비어 있으니 결과적으로 빈 테이블이 된다.

즉, 원래라면 실패 시 기존 데이터가 그대로 남아야 하는데,
오히려 실패 때문에 기존 정상 데이터까지 사라질 수 있는 구조가 돼 있었다.

수정 자체는 단순했다.
작업 상태가 성공일 때만 마지막 교체 로직을 실행하도록 한 줄 가드를 넣으면 됐다.

하지만 중요한 건 코드 한 줄이 아니라,
청크 기반 처리의 안전성을 믿고 있었는데 실제 구조는 그 안전성을 이미 잃고 있었다는 점이었다.

두 번째 대가: 테스트가 실제 문제를 가렸다

이 구조는 테스트에서도 문제를 만들었다.

테스트에서는 데이터베이스에 테스트 데이터를 직접 넣고 배치를 실행한 뒤 결과를 확인했다.
그런데 운영 환경에서 데이터가 들어오는 방식은 테스트와 달랐다.

운영에서는 이벤트 수신기가 데이터를 저장하는 과정에서 두 가지 변환이 있었다.

이벤트 타입 이름이 축약됐다.
시간이 표준시 기준으로 변환돼 저장됐다.

반면 테스트에서는 이 경로를 거치지 않고 직접 데이터를 넣었다.
그래서 테스트 환경에서는 문제가 드러나지 않았지만, 운영 환경에서는 다른 결과가 나올 수 있었다.

실제로는 이런 문제가 생길 수 있었다.

이벤트 타입 값이 달라 점수 계산이 되지 않는다.
시간대 차이 때문에 집계 기간 경계가 어긋난다.

즉, 테스트는 통과했지만 운영에서는 빈 랭킹이 나올 수 있는 구조였다.

이 경험을 통해 배운 건 단순히 “테스트를 더 잘 써야 한다”가 아니었다.
도구를 문제와 맞지 않게 비틀어 쓰면, 테스트가 검증해야 할 실제 경로도 함께 흐려진다는 점이었다.

만약 Tasklet으로 갔다면

만약 이 작업을 처음부터 Tasklet으로 구현했다면 구조는 훨씬 단순했을 것이다.

집계 SQL을 한 번 실행한다.
기존 랭킹을 교체한다.
성공하면 커밋한다.
실패하면 전체를 롤백한다.

이 방식에서는 마지막 단계의 별도 콜백에 의존하지 않아도 된다.
또한 저장 경로가 단순해지므로, 현재 구조에서 드러난 일부 시간대 처리 문제나 중간 저장 구조의 혼란도 줄어들 수 있다.

물론 단점이 없는 것은 아니다.

점수 계산식이 SQL에 들어가면 자바 계산 로직과 분리될 수 있다.
읽기, 가공, 저장을 분리하는 학습 효과는 줄어든다.
데이터 규모가 매우 커지면 단일 SQL 성능을 추가로 검토해야 한다.

그럼에도 이 요구사항 기준에서는,
Tasklet이 더 단순하고 더 정직한 선택이었다고 본다.

이번 경험에서 배운 것

1. 프레임워크의 형식과 본질은 다르다

읽기, 가공, 저장 컴포넌트를 나눠 놓는 것은 형식이다.
하지만 청크 단위 처리의 진짜 가치는 작은 단위로 커밋하고, 그 단위 기준으로 복구 가능성을 확보하는 데 있다.

형식만 가져오고 본질은 살리지 못하면,
프레임워크를 쓴다는 이유로 오히려 안전하다고 착각할 수 있다.

2. 도구는 문제의 본질에 맞아야 한다

이번 작업의 핵심은 대량 데이터 분산 처리보다 최종 집계 결과를 한 번에 안전하게 교체하는 것이었다.

그런데 나는 문제보다 도구의 구조를 먼저 봤고,
그 결과 맞지 않는 도구를 억지로 끼워 맞추게 됐다.

3. 학습을 위한 선택과 운영을 위한 선택은 구분해야 한다

이번 경험은 많이 배웠다.
작업 단계 종료 콜백의 동작 방식, 테스트 경로와 운영 경로의 차이, 집계 작업의 특성과 청크 처리의 한계를 실제로 체감했다.

하지만 많이 배웠다는 사실과, 좋은 선택이었다는 사실은 다르다.

학습 환경에서는 이런 우회가 가능할 수 있다.
반면 운영 환경이라면, 더 단순하고 실패 가능성이 적은 구조를 우선했어야 했다.

마무리

이번 작업을 하면서 가장 크게 느낀 건 이것이었다.

프레임워크를 사용한다고 해서 그 장점이 자동으로 따라오지는 않는다.

도구의 모양을 흉내 내는 것과, 그 도구가 전제하는 방식대로 문제를 푸는 것은 다르다.
이번에는 청크라는 형식을 선택했지만, 실제로는 그 본질을 살리지 못했다.

결국 남은 것은 프레임워크를 사용했다는 만족감이 아니라,
문제에 맞는 도구를 고르지 않았을 때 생기는 복잡성과 그 비용이었다.

루프팩 3기를 마치며 - 기술을 쓰는 개발자에서, 선택의 이유를 설명하는 개발자로

ioh'sDeveloper — Fri, 17 Apr 2026 07:54:57 +0900

기술을 쓰는 개발자에서, 선택의 이유를 설명하는 개발자로

루프팩 3기를 마치며

서론. 나는 왜 다시 배우기로 했을까

돌아보면 저는 늘 기술 가까이에 있었습니다.
백엔드 개발자로서 기능을 만들고, 운영 이슈를 해결하고, 장애를 마주하고, 다시 구조를 손보는 일을 반복해 왔습니다. 실무 안에서 많은 것을 배웠고, 그만큼 익숙해진 기술도 많았습니다. 그런데 어느 순간부터 아주 선명하게 느껴지는 한계가 있었습니다.

“써본 적은 있는데, 정말 설명할 수 있는가?”

이직을 준비하면서 그 질문이 더 크게 다가왔습니다.

왜 이 구조를 선택했는지, 왜 이 트랜잭션 경계가 필요한지, 어떤 기준으로 동기와 비동기를 나눴는지. 막상 이런 질문 앞에 서면, 구현 경험은 분명 있는데 그것을 설계 의도와 판단 근거의 언어로 풀어내는 일은 아직 부족하다고 느꼈습니다. 기술을 사용한 경험과 기술을 선택한 경험 사이에는 생각보다 큰 간극이 있었습니다.

그래서 저는 루프팩에 지원했습니다.
단순히 새로운 기술을 더 배우고 싶어서가 아니었습니다. 실무에서 써 온 기술들을 다시 설계 관점으로 정리하고, 제 선택의 이유를 분명하게 설명할 수 있는 사람으로 성장하고 싶었습니다.
특히 AI를 단순한 보조 도구가 아니라, 사고를 확장하고 작업을 분해하는 개발 에이전트처럼 활용하는 방식에도 강한 관심이 있었습니다. 이제 개발자는 혼자 모든 답을 짜내는 사람이 아니라, 더 나은 질문을 만들고 더 좋은 협업 구조를 설계하는 사람이어야 한다고 생각했기 때문입니다.

그 마음으로 시작한 10주는, 생각했던 것보다 훨씬 더 깊고 진하게 저를 바꾸어 놓았습니다.

본론. 루프팩에서 내가 다시 배운 것들

1. 구현보다 먼저, 왜를 묻는 습관

루프팩에서 가장 크게 달라진 점은 기술을 바라보는 시선이었습니다.
예전의 저는 “이 기술을 써봤다”는 설명에는 익숙했습니다. 하지만 이번 과정을 지나며 조금씩 “이 상황에서 왜 이 기술을 선택했는지”, “대안은 무엇이었고 무엇을 포기했는지”를 먼저 생각하게 되었습니다.

같은 문제를 보더라도 이제는 바로 구현으로 들어가기보다,
이 문제의 본질이 무엇인지, 어디까지를 동기로 묶어야 하는지, 어디서부터 비동기로 분리할 수 있는지, 이 선택이 운영과 장애 대응에 어떤 영향을 주는지를 먼저 떠올리게 되었습니다.

실무에서는 늘 문제를 해결해 왔지만, 루프팩에서는 한 걸음 더 나아가 해결 방식의 근거를 설명하는 훈련을 계속하게 되었습니다. 그 과정이 생각보다 훨씬 중요했습니다. 기술은 결국 코드를 넘어 판단의 결과물이라는 사실을, 이번에 더 분명하게 체감했습니다.

2. AI를 쓰는 사람이 아니라, AI와 협업하는 사람으로

이번 과정에서 또 하나 크게 달라진 것은 AI를 대하는 태도였습니다.
이전에도 AI를 활용하지 않았던 것은 아닙니다. 하지만 루프팩에서처럼 밀도 있게, 깊이 있게, 반복적으로 활용해 본 적은 없었습니다.

예전에는 AI를 빠르게 답을 얻기 위한 도구로 쓰는 순간이 더 많았다면, 지금은 조금 다릅니다.
AI는 답을 대신 내주는 존재라기보다, 제 사고를 넓혀 주는 협업자에 가깝습니다. 제가 더 좋은 질문을 던질수록 더 나은 방향으로 사고가 전개되고, 제가 놓친 관점을 다시 확인하게 해 주는 파트너처럼 느껴졌습니다.

중요했던 건 의존하지 않는 것이었습니다.
AI를 잘 쓴다는 건 생각을 맡기는 것이 아니라, 생각을 더 정교하게 밀어붙이는 것에 가깝다는 걸 배웠습니다. 질문을 분해하고, 선택지를 비교하고, 트레이드오프를 언어화하고, 다시 내 관점으로 정리하는 과정 속에서 AI는 꽤 좋은 협업자가 될 수 있었습니다.

이 감각은 앞으로도 제 개발 방식에 오래 남을 것 같습니다.
기술을 잘 아는 개발자에서 끝나는 것이 아니라, AI까지 포함한 작업 구조를 설계할 수 있는 개발자가 되고 싶다는 생각이 더 분명해졌습니다.

3. 사람과의 대화가 방향이 되어 주었던 순간들

기술적으로 가장 많이 남는 기억은, 의외로 혼자 고민하던 순간보다 함께 이야기하던 순간들입니다.
방향을 잃고 같은 자리에서 계속 맴돌 때, 팀원들이나 함께 과정을 듣는 분들과의 대화 속에서 다시 실마리를 찾았던 경험이 많았습니다. 혼자였다면 훨씬 오래 헤맸을 고민들이, 누군가의 한마디로 정리되곤 했습니다.

무엇보다 좋았던 점은, 저와 다른 방식으로 사고하는 사람들을 가까이에서 볼 수 있었다는 것입니다.
같은 문제를 전혀 다른 각도에서 바라보는 사람을 보면 처음에는 감탄하게 됩니다. 그런데 그 다음부터는 궁금해집니다. 저 사람은 왜 저 지점이 먼저 보였을까. 어떤 흐름으로 저 선택에 도달했을까. 그렇게 타인의 사고를 따라가 보려는 노력이 제 사고의 폭도 함께 넓혀 주었습니다.

그리고 팀 안에서는 자연스럽게 서로를 받쳐 주는 시간들이 있었습니다.
누군가가 지치면 다른 사람이 끌어 주고, 또 역할이 바뀌면 반대로 기대며 버텨 내는 흐름이 있었습니다. 제가 누군가에게 힘이 되었던 순간도 있었고, 반대로 제가 흔들릴 때 손을 내밀어 준 순간도 있었습니다. 지금 돌아보면 그 작은 배려들이 쌓여 이 10주를 완주하게 만든 것 같습니다.

4. 글을 쓴다는 것은, 생각을 검증하는 일

이번 과정에서 의외로 크게 배운 것은 라이팅의 힘이었습니다.
블로그를 꾸준히 써 왔다고 생각했지만, 이번처럼 오래 붙들고 고민하며 글을 써 본 적은 많지 않았습니다. 글을 쓰는 과정은 단순히 배운 것을 기록하는 일이 아니었습니다. 내 생각이 정말 맞는지, 논리가 비어 있지는 않은지, 설명이 충분히 설득력 있는지를 스스로 검증하는 시간이었습니다.

PR을 쓰는 방식도 달라졌고, 생각을 문장으로 정리하는 태도도 달라졌습니다.
머릿속에서는 그럴듯해 보이던 판단도, 막상 글로 쓰려 하면 근거가 빈약한 경우가 많았습니다. 반대로 글로 정리하면서 비로소 제 선택이 더 선명해지는 순간도 있었습니다.

결국 잘 쓰는 사람은, 잘 생각하는 사람이라는 말을 조금은 이해하게 되었습니다.
개발자에게 글쓰기는 부가적인 능력이 아니라, 사고를 구조화하는 핵심 역량 중 하나라는 걸 이번에 아주 크게 배웠습니다.

5. 아쉬움까지 포함해서, 나를 더 단단하게 만든 시간

물론 아쉬움이 없었던 것은 아닙니다.
그때그때는 분명 최선을 다했고, 정말 끝까지 몰입했던 순간도 많았습니다. 그런데 돌아보면 조금 더 일찍 질문해 볼 걸, 조금 더 과감하게 제 생각을 꺼내 볼 걸, 조금 더 끝까지 파고들어 볼 걸 하는 아쉬움도 남습니다.

회사 업무와 병행하는 일은 쉽지 않았고, 체력적으로도 정신적으로도 버거운 날이 있었습니다. 생각을 너무 오래 붙들다가 스스로 소진되는 순간도 있었습니다. 하지만 이상하게도, 그 시간들까지 지나고 나니 남는 것은 후회보다 확신에 가깝습니다.

나는 힘들어도 계속 생각하는 사람이고,
쉽게 답을 정하기보다 끝까지 이유를 찾으려는 사람이며,
혼자만의 정답보다 함께 더 좋은 답을 만드는 쪽으로 조금씩 이동하고 있다는 것.

그걸 확인한 것만으로도, 이 10주는 충분히 값졌습니다.

6. 가장 인상 깊었던 프로젝트

가장 인상 깊었던 프로젝트는 Kafka 기반 EDA 과제였습니다.
이 과제가 특히 오래 기억에 남는 이유는, 단순히 메시지를 발행하고 소비하는 구현에서 끝나지 않았기 때문입니다. 메시지를 언제 발행할지, 트랜잭션 경계를 어디에 둘지, 어떤 흐름을 동기에서 비동기로 분리할지, 그리고 컨슈머가 실패했을 때 재시도와 DLQ, 보상 처리를 어떻게 설계해야 하는지까지 함께 고민해야 했습니다.

무엇보다 좋았던 점은, 문제를 해결하는 데서 멈추지 않고 왜 이 구조를 선택했는지 스스로 끝까지 설명해 보게 만들었다는 점입니다. 구현 자체보다도 설계 의도와 트레이드오프를 더 깊게 생각하게 해 준 과제였고, 그래서 저에게는 루프팩의 강점을 가장 잘 보여준 프로젝트로 남았습니다.

루프팩을 고민하는 분이 있다면, 저는 이 과제 경험을 특히 추천하고 싶습니다.
실무에서도 계속 마주치게 될 메시징, 비동기 처리, 장애 대응, 정합성 같은 주제를 한 번에 밀도 있게 고민해 볼 수 있었고, 그 과정에서 단순한 기술 습득이 아니라 설계 관점 자체를 넓히는 경험을 할 수 있었기 때문입니다.

7. 추천하고 싶은 글과 기록

루프팩을 지나며 제가 특히 오래 붙들고 고민했던 주제들은 자연스럽게 글과 기록으로도 남게 되었습니다.
돌아보면 이 과정은 과제를 수행하는 시간인 동시에, 제 생각을 글로 검증하는 시간이기도 했습니다. 그래서 루프팩을 통해 어떤 고민을 했는지 더 궁금하신 분이 있다면, 아래 글들도 함께 보셔도 좋겠습니다.

1. 타임아웃은 실패가 아니다 외부 API 연동에서 모르는 상태를 다루는 법

이 글에서는 외부 PG 연동에서 타임아웃을 곧바로 실패로 단정하면 안 된다는 점을 중심으로, 응답을 받지 못한 상태를 “모른다”로 다루고 UNKNOWN 상태와 대사 배치까지 포함해 설계를 풀어냈습니다. 외부 시스템 연동에서 정합성을 어떻게 바라봐야 하는지에 대한 고민이 담긴 글입니다.

2. 락을 잘 골랐는데 왜 더 위험해졌을까

이 글은 주문 트랜잭션에서 도메인별로 락 전략을 각각 최적화했지만, 결과적으로는 비관적 락 2개와 낙관적 락 1개가 한 트랜잭션에 공존하면서 오히려 데드락 위험과 락 보유 시간이 커졌던 경험을 다룹니다. 결국 “락을 잘 고르는 것”보다 “공유 자원 자체를 줄이는 것”이 더 근본적인 해법일 수 있다는 점이 인상 깊었습니다.

3. DIP를 끝까지 적용해본 경험 — 순수 POJO 도메인 설계의 트레이드오프

이 글에서는 Entity-level DIP를 끝까지 밀어붙여 보면서, 순수 POJO 도메인을 유지하는 대신 Dirty Checking을 포기하고 명시적 save() 호출을 감수했던 경험을 정리했습니다. “과하다”는 말을 쉽게 하기보다, 실제로 끝까지 적용해 보고 무엇을 얻고 무엇을 잃는지 체감해 본 기록이라 저에게도 의미가 컸습니다.

4. 대기열 시스템 구현 PR

대기열 구현 PR에는 Redis Sorted Set 기반 대기열, Lua Script를 통한 원자적 토큰 발급, CircuitBreaker와 RateLimiter를 활용한 장애 대응, 이벤트 기반 토큰 정리, 그리고 배치 크기 산정 근거까지 포함해 설계 의사결정을 상세히 정리해 두었습니다. 단순 구현 결과물이라기보다, 왜 이렇게 설계했는지를 문서로 설명하려고 노력했던 기록이라 더 애착이 갑니다.

결론. 이제 나는 무엇을 가져가려 하는가

루프팩을 시작할 때 저는 설계 의도와 선택의 근거를 설명할 수 있는 개발자가 되고 싶었습니다.
지금의 저는 아직 완성된 사람이라고 말할 수는 없습니다. 여전히 부족한 것도 많고, 더 깊게 들어가야 할 주제도 많습니다. 다만 분명한 것은, 이제는 그 방향으로 가는 방법을 조금은 알게 되었다는 점입니다.

기술을 나열하는 사람이 아니라,
왜 이 선택을 했는지 말할 수 있는 사람.
감이 아니라 근거로 설명하려는 사람.
혼자 답을 만드는 데서 멈추지 않고, 질문과 대화, 라이팅과 AI 협업을 통해 더 나은 판단을 만들어 가는 사람.

저는 앞으로 그런 개발자가 되고 싶습니다.

그리고 무엇보다, 사람 덕분에 여기까지 올 수 있었다는 사실을 오래 기억하고 싶습니다.
좋은 질문을 던져 준 멘토님들, 함께 고민해 준 팀원들, 각자의 방식으로 치열하게 몰입하던 동료들 덕분에 저는 혼자서는 얻기 어려웠을 시야를 얻었습니다.

그래서 루프팩 3기는 저에게 단순한 부트캠프가 아니었습니다.
개발자로서의 철학을 다시 정리하게 해 준 시간이었고, 처음의 도전이 어떤 변화로 이어질 수 있는지를 몸으로 확인한 시간이었습니다.

끝나서 아쉽지만, 이상하게도 이전보다 더 기대됩니다.
이제는 조금 더 분명한 언어로 제 선택을 말할 수 있을 것 같고,
조금 더 단단한 시선으로 다음 문제를 마주할 수 있을 것 같습니다.

늦게 시작한 것이 아쉬울 만큼, 정말 값진 시간이었습니다.
그리고 저는 이 10주를, 앞으로 더 좋은 개발자가 되기 위한 꽤 단단한 출발선으로 오래 기억할 것 같습니다.

에필로그. 결국, 사람을 남기는 시간이었다

그리고 마지막으로, 꼭 남기고 싶은 이야기가 있습니다.

이번 루프팩을 지나며 저는 앞으로 어떤 개발자가 되고 싶은지도 조금 더 선명해졌습니다.
기술적으로 좋은 영향을 줄 수 있는 사람이 되고 싶고, 멘토님들처럼 누군가에게 실질적인 도움이 되는 기여를 할 수 있는 개발자가 되고 싶습니다. 동시에 이제 막 시작하는 주니어에게는 힘이 되어 주는 사람이고 싶습니다. 저 역시 제 나름의 개발자 철학을 만들어 가고 싶고, 이 AI 시대 안에서 흐름에 휩쓸리는 사람이 아니라 제대로 이해하고 잘 활용하는 사람이 되고 싶습니다.

그런 의미에서 루프톡도 저에게 참 특별했습니다.
좋은 사람들과 기술 이야기, 커리어 이야기, 고민과 응원을 함께 나눌 수 있다는 것이 얼마나 큰 힘이 되는지 다시 느끼게 해 준 자리였습니다.

그리고 이 자리를 빌려 감사한 분들을 꼭 남기고 싶습니다!

우리 애니 매니저님, 늘 뒤에서 묵묵히 지원해 주시고 챙겨 주셔서 감사했습니다.

항상 유익한 내용들을 알려 주시고, 편하게 웃고 장난칠 수 있는 분위기를 만들어 주셨던 멘토님들!!

앨런 멘토님, 케브 멘토님, 렌 멘토님, 데빈 멘토님들께도 정말 감사드립니다. 쉬운 발제라고 말씀하셨지만, 듣는 사람 입장에서는 결코 가볍게 넘길 수 없는 깊이가 있었고, 그만큼 많이 배우고 많이 고민할 수 있었습니다.

또 각자의 회사 생활로도 바쁘셨을 텐데, 언제나 우리를 챙겨 주고 도와주고, 오프라인 스터디까지 잘 이끌어 주시고, 늘 먼저 걱정해 주셨던 엔젤분들께도 진심으로 감사드립니다.
특히 5팀 재인님께는 정말 큰 감사의 마음이 있습니다. 따뜻하게 챙겨 주시고, 분위기를 이끌어 주시고, 힘든 순간마다 자연스럽게 손 내밀어 주셨던 기억이 오래 남을 것 같습니다.

서포터분들께도 감사한 마음이 큽니다.
새벽마다 퀴즈를 내 주시던 준서님 (엄퀴즈), 열품타와 여러 방식으로 분위기를 만들어 주신 기현님(박박기기현현)

늘 편안하고 재미있는 분위기로 긴장을 풀어 주신 지웅님과 상일님까지

아!! 루프톡도 정말 재미있었고, 뜻깊었습니다.

단순히 프로그램의 한 코스처럼 지나간 시간이 아니라, 함께 듣는 수강생의 기쁜 일을 같이 기뻐하고, 서로의 고민을 함께 나누고, 기술 이야기로 깊게 연결될 수 있었던 시간으로 기억에 남습니다. 그래서 더 오래 마음에 남는 것 같습니다. 루프톡 덕분에 이 과정 전체가 더 즐겁고 가까운 시간으로 남을 수 있었던 건 덕분이었다고 생각합니다.

무엇보다 가장 크게 감사한 분들은 3기 멘티분들입니다.
정말 여러분과 함께한 10주는 오래 기억에 남을 것 같습니다. 밤늦게까지 같이 고민하고, 스터디를 만들고, 오프라인에서 만나 이야기를 나누고, 노래도 듣고, 사진도 찍고, 함께 웃고 버텼던 순간들이 너무 소중했습니다. 실력 있는 분들과 가까이에서 이야기하며, 제가 몰랐던 관점들을 보고, 다른 사고방식을 따라가 보고, 제 사고의 폭도 많이 넓힐 수 있었습니다.

혼자였다면 절대 이렇게까지 깊게 생각하지 못했을 것 같습니다.
혼자였다면 금방 포기했을 고민들도, 함께였기 때문에 끝까지 붙들 수 있었습니다. 그래서 더 감사하고, 더 애정이 남습니다.

이번 루프팩은 제게 기술만 남긴 것이 아니었습니다.
함께 고민할 수 있는 사람들, 같이 성장할 수 있는 동료들, 그리고 앞으로도 계속 연결되고 싶은 인연들을 남겨 준 시간이었습니다.

그래서 혹시 지금 이 글을 읽으면서 루퍼스를 들을까 말까 고민하는 분이 있다면, 저는 분명하게 말하고 싶습니다.
주니어 개발자든, 이미 실무 경험이 있는 시니어 개발자든, 이 과정은 충분히 값진 시간이 될 수 있다고 생각합니다.

물론 과정 안에는 분명 힘든 순간도 있습니다.

하지만 그 힘든 순간을 혼자 버티게 두지 않는 사람들이 있습니다. 막히는 지점이 있을 때 함께 고민해 주는 사람들, 지칠 때 공감해 주는 사람들, 그리고 혼자 끙끙 앓던 문제를 함께 이야기하며 풀어갈 수 있게 도와주는 환경이 있습니다. 멘토님들의 멘토링을 듣고, 사람들과 토론하고, 내 생각을 부딪쳐 보는 과정 안에서 정말 좋은 인사이트를 많이 얻을 수 있습니다.

저 역시 이 안에서 정말 많은 것을 얻었습니다.
기술적으로도, 사고 방식에서도, 개발자로서의 태도와 철학의 면에서도 분명히 성장할 수 있었습니다. 그래서 앞으로도 더 많은 분들이 루퍼스와 백엔드 루프팩을 통해 기술적으로 성장하고, 자기만의 개발자 철학을 만들어 갈 기회를 만나면 좋겠습니다.

정말 모두 고생 많으셨습니다.
함께해서 즐거웠고, 많이 배웠고, 오래 기억할 것 같습니다.

최강 5팀 만세

그리고 이 좋은 경험을 누군가와 나누고 싶어서, 추천 코드도 함께 남깁니다.
필요하신 분이 있다면 편하게 사용하셔도 좋겠습니다.

테스트는 전부 통과했는데 배치가 빈 테이블을 만든 이유

ioh'sDeveloper — Fri, 17 Apr 2026 07:29:52 +0900

Spring Batch 실전에서 만난 3가지 함정

한 줄 요약:

Spring Batch로 주간 랭킹 집계를 만들고, 테스트 4개를 짰고, 전부 통과했다. 그런데 실제로 돌리면 결과 테이블이 매번 비어있었다. 원인을 추적하니, 테스트 자체가 3개의 치명적 결함을 구조적으로 숨기고 있었다. 이 글은 그 3가지 함정을 발견하고 수정한 기록이다.

배경: 뭘 만들었나

이커머스 서비스에서 "이번 주 인기 상품 TOP 100" 같은 랭킹을 보여주려면, 사용자의 행동(상품 조회, 좋아요, 주문)을 모아서 점수를 매기고, 높은 순서대로 정렬해야 한다.

기존에는 실시간 일간 랭킹이 있었다. 사용자가 상품을 조회하면 Kafka(메시지 큐)를 통해 이벤트가 전달되고, Consumer(이벤트 수신기)가 이를 받아 Redis라는 인메모리 저장소에 점수를 실시간으로 누적한다. "오늘 인기 상품"은 이걸로 충분하다.

하지만 Redis에는 시간 정보가 없다. 점수만 쌓일 뿐, "이 점수가 언제 발생했는지"를 알 수 없다. 그래서 "지난 주 인기 상품"이나 "이번 달 인기 상품"처럼 특정 기간을 기준으로 집계하는 건 불가능하다.

이걸 해결하기 위해, Consumer가 Redis에 점수를 적재하면서 동시에 DB에도 원천 이벤트를 날것 그대로 저장해두도록 설계했다. 이 ranking_event 테이블에는 "어떤 상품에, 어떤 행동이, 언제 발생했는지"가 기록되어 있다. Spring Batch가 이 테이블에서 원하는 기간의 이벤트를 꺼내 집계하고, 결과를 조회 전용 테이블(MV, Materialized View)에 적재하는 구조다.

사용자 행동 → Kafka → Consumer → DB(원천 이벤트) + Redis(실시간 점수)
                                      ↓
                               Spring Batch → MV(주간/월간 TOP 100)

배치를 구현하고, 통합 테스트 4개를 작성했다:

테스트 뭘 검증하나

happyPath	조회×0.1 + 좋아요×0.2 + 주문×0.6 가중치로 집계해서 TOP N을 뽑는다
tieBreak	같은 점수면 상품 ID가 작은 순서대로 랭크한다
idempotent	같은 날짜로 2번 돌려도 결과가 동일하다 (멱등성)
periodIsolation	이번 주 배치가 지난 주 데이터를 건드리지 않는다

4개 전부 통과. 안심하고 배치를 돌렸다.

결과 테이블이 비어있었다. 매번.

함정 1: 테스트 데이터가 운영 환경과 다른 값을 넣고 있었다

뭐가 문제였나

배치가 이벤트를 읽어 점수를 계산하는 과정을 디버깅했더니, 모든 이벤트의 점수가 0점이었다. 0점이면 "의미 없는 이벤트"로 간주돼 전부 필터링된다. 결과 테이블이 빈 건 당연한 결과였다.

원인은 이벤트 타입 이름이 안 맞는 것이었다.

이 시스템에서 이벤트는 두 번 변환된다. Kafka에서 들어올 때는 "ProductViewedEvent"(상품 조회 이벤트)라는 긴 이름이지만, Consumer가 DB에 저장할 때 "VIEW"라는 짧은 코드로 바꿔서 넣는다:

Kafka 원본: "ProductViewedEvent"  →  DB 저장: "VIEW"
Kafka 원본: "ProductLikedEvent"   →  DB 저장: "LIKE"
Kafka 원본: "OrderItemSoldEvent"  →  DB 저장: "ORDER"

그런데 배치의 점수 계산기(Scorer)는 DB에 저장된 짧은 코드가 아니라, Kafka 원본 이름을 기대하고 있었다:

// 점수 계산기 — 수정 전 (버그)
return switch (eventType) {
    case "ProductViewedEvent" -> 0.1;   // DB에는 "VIEW"가 들어있는데...
    case "ProductLikedEvent"  -> 0.2;   // DB에는 "LIKE"가 들어있는데...
    case "OrderItemSoldEvent" -> 0.6;   // DB에는 "ORDER"가 들어있는데...
    default -> 0.0;                      // ← 전부 여기로 빠져서 0점
};

DB에서 "VIEW"를 읽어왔는데, 계산기는 "ProductViewedEvent"만 알아듣는다. 매칭 실패 → 0점 → 전부 필터링 → 빈 테이블.

왜 테스트에서는 안 보였나

테스트는 DB에 테스트 데이터를 직접 넣는다(seed). 이때 Consumer를 거치지 않고 직접 insert하는데, Kafka 원본 이름 "ProductViewedEvent"를 그대로 넣고 있었다:

// 테스트 데이터 시드 — 수정 전
seedEvent("ob-p1-v0", 1L, "ProductViewedEvent", eventTime);  // ← Kafka 원본명!

테스트 환경에서는 DB에 "ProductViewedEvent"가 들어가고, 계산기도 "ProductViewedEvent"를 기대하니까 매칭이 된다. 테스트는 통과한다.

운영 환경에서는 Consumer가 "VIEW"로 바꿔서 저장하니까, 계산기가 매칭에 실패한다.

핵심은 이거다: 테스트 데이터를 만들 때 실제 운영에서 데이터가 어떤 경로를 거치는지를 재현하지 않으면, 테스트는 "다른 세계"를 검증하게 된다.

수정

계산기의 매칭 기준을 DB에 실제로 저장되는 코드("VIEW", "LIKE", "ORDER")로 바꾸고, 테스트 데이터도 동일하게 맞췄다.

함정 2: 시간이 9시간 밀려 있었는데 테스트에서는 안 보였다

뭐가 문제였나

함정 1을 수정한 뒤에도, 실제 환경에서 "이번 주" 집계를 돌리면 주 시작과 끝에서 이벤트가 빠지거나 다음 주 이벤트가 섞이는 현상이 있었다. 1~2건이 아니라 9시간 분량이었다.

원인은 시간대(timezone) 처리 경로가 달랐기 때문이다.

이 시스템에서 같은 event_time 컬럼을 두 가지 방식으로 접근한다:

저장할 때 (Consumer → Hibernate/JPA): 한국 시간(KST)을 세계 표준시(UTC)로 변환해서 저장한다. 예: KST 4월 13일 00:00 → UTC 4월 12일 15:00으로 DB에 기록
읽을 때 (Batch Reader → 순수 JDBC): Hibernate를 거치지 않고 직접 DB에 쿼리한다. 이때 JDBC 드라이버는 JVM의 기본 시간대(한국 시간)를 사용한다

같은 시점인데 저장할 때는 UTC로 넣고, 읽을 때는 한국 시간으로 해석하니까 9시간 차이가 생긴다:

저장: KST 4월 13일 00:00 → DB에 "4월 12일 15:00"으로 기록 (UTC)
읽기: "4월 13일 00:00 이후 이벤트를 찾아줘" → DB가 UTC 기준 4월 13일 00:00으로 해석
비교: DB에 있는 "4월 12일 15:00" < 쿼리의 "4월 13일 00:00" → 이 이벤트는 누락됨!

결과적으로 집계 기간 전체가 9시간 밀려있다. 데이터는 있고 정렬도 맞지만, 경계가 틀리다. 이런 결함은 눈으로 봐서는 거의 발견할 수 없다.

왜 테스트에서는 안 보였나

테스트 데이터를 넣을 때도 Hibernate를 거치지 않고 순수 JDBC로 직접 insert한다. 배치가 읽을 때도 순수 JDBC다. 넣는 쪽과 읽는 쪽이 같은 시간대 처리 방식을 쓰니까, 9시간 밀림이 양쪽에 동일하게 적용되어 서로 상쇄된다.

테스트:  순수 JDBC(한국 시간)로 저장 → 순수 JDBC(한국 시간)로 읽기 → 밀림이 상쇄 → 안 보임
운영:    Hibernate(UTC)로 저장     → 순수 JDBC(한국 시간)로 읽기  → 밀림 발생 → 9시간 어긋남

수정

모든 JDBC 연결의 시간대를 UTC로 통일했다. DB 접속 URL에 serverTimezone=UTC를 추가해서, Hibernate 경로든 순수 JDBC 경로든 같은 시간대 기준으로 동작하게 만들었다.

함정 3: 성공만 테스트했더니, 실패할 때 기존 데이터가 날아갔다

뭐가 문제였나

함정 1, 2를 수정한 뒤, "이 배치가 중간에 실패하면 어떻게 되지?"를 생각해봤다. DB 연결이 끊기면? 메모리가 부족하면?

Spring Batch의 Chunk-Oriented Processing은 원래 이런 상황에 대비하도록 설계되어 있다. 데이터를 일정 단위(chunk)로 나눠서 처리하고, 한 chunk가 끝날 때마다 커밋한다. 중간에 실패하면 마지막으로 성공한 chunk까지는 보존된다.

하지만 이번 구현은 이 설계를 따르지 못했다. 랭킹 테이블은 "전부 바꾸거나, 아무것도 안 바꾸거나(all-or-nothing)"가 필요하다. chunk 단위로 중간에 넣으면 사용자가 반만 갱신된 랭킹을 볼 수 있기 때문이다. 그래서 Writer는 DB를 건드리지 않고 메모리에만 점수를 누적하고, Step(작업 단위)이 끝난 뒤 afterStep()이라는 콜백에서 한 번에 삭제+삽입하는 구조로 만들었다.

문제는 afterStep()의 동작 방식이다. Spring Batch의 규칙상, 이 콜백은 Step이 성공하든 실패하든 항상 호출된다. 그런데 코드에서 Step의 성공/실패 여부를 확인하지 않고 무조건 삭제+삽입을 실행하고 있었다.

최악의 시나리오

1. 데이터를 읽는 중에 DB 연결이 끊김
2. Spring Batch가 이 Step을 "실패"로 기록
3. afterStep() 호출 — 실패인데 코드가 확인하지 않음
4. 기존 정상 랭킹 100건 삭제 (DELETE)
5. 누적된 데이터가 없으니 새로 넣을 것도 없음 (INSERT 0건)
6. 결과: 랭킹 테이블 완전 소실. 빈 테이블.

정리하면: 프레임워크는 "실패하면 기존 데이터를 보존한다"를 보장하려고 설계됐는데, 이 구조에서는 "실패하면 기존 데이터가 파괴된다" — 프레임워크가 보장하려던 것의 정반대.

왜 테스트에서는 안 보였나

테스트 4개를 다시 보면 전부 정상적으로 처리되는 경우만 검증한다. "중간에 실패하면 기존 데이터는 어떻게 되는가?"를 묻는 테스트가 하나도 없었다.

수정

afterStep() 첫 줄에 가드를 추가했다:

public ExitStatus afterStep(StepExecution stepExecution) {
    if (stepExecution.getStatus() != BatchStatus.COMPLETED) {
        log.warn("Step 실패 — 기존 랭킹 보존. status={}", stepExecution.getStatus());
        return stepExecution.getExitStatus();
    }
    // Step이 성공했을 때만 삭제+삽입 실행
}

1줄의 가드로, 실패 시 기존 데이터를 보존한다.

세 가지 함정이 동시에 숨을 수 있었던 이유

세 가지를 정리하면, 테스트가 운영 환경을 재현하지 못하는 구조적 패턴이 보인다:

왜 숨었나 가려진 함정 테스트 vs 운영의 차이

테스트 데이터가 실제 생산자를 우회	이벤트 타입 불일치	테스트는 DB에 직접 넣으니까 Consumer의 변환 과정이 빠짐
저장과 읽기가 같은 경로를 탐	시간대 9시간 밀림	테스트는 둘 다 순수 JDBC라 밀림이 상쇄됨
성공 케이스만 검증	실패 시 데이터 파괴	정상 처리 4개, 장애 시나리오 0개

이 세 가지가 동시에 작용한 결과, 테스트는 전부 통과했는데 배치는 빈 테이블을 만드는 상태가 됐다.

공통된 원인은 하나다: 테스트의 범위가 배치 모듈 안에 갇혀 있었다.

Consumer → DB → Batch Reader까지의 전체 경로를 테스트했다면 함정 1이 드러났을 것이다
Hibernate로 저장하고 순수 JDBC로 읽는 경로를 재현했다면 함정 2가 드러났을 것이다
실패 시나리오를 추가했다면 함정 3이 드러났을 것이다

테스트가 진짜 "통합"이 되려면, 모듈 경계를 넘는 약속(Consumer가 저장하는 값의 형태, 시간대 처리 방식, 프레임워크가 호출하는 생명주기)까지 범위에 포함해야 한다. 하지만 범위를 넓히면 테스트 환경 구성 비용이 올라간다. 여기에 트레이드오프가 있다.

내가 배운 것

테스트를 많이 짜는 것보다 "이 테스트가 뭘 검증하지 못하는가"를 아는 게 중요하다.

4개의 통합 테스트를 작성했을 때, "4개면 꽤 짰다"는 안도감이 있었다. 정상 처리, 동점 순서, 멱등성, 기간 격리 — 나쁘지 않은 커버리지였다. 하지만 이 4개가 어떤 경로를 타는지, 그 경로가 실제 운영과 같은 경로인지를 따져보지 않았다.

테스트가 전부 통과한다는 건 "이 테스트들이 검증하는 범위 안에서는 안전하다"라는 뜻이지, "안전하다"라는 뜻이 아니다. 그 차이를 체감한 건 이번이 처음이었다.

돌아보면, 이 구현에서 가장 깊이 배운 건 Spring Batch 프레임워크의 사용법이 아니라, 프레임워크를 빌려 쓸 때 형식과 본질을 구분하는 감각이었다. Reader/Processor/Writer를 채우는 건 형식이고, chunk 단위 커밋과 실패 복구가 본질이다. 형식만 빌리고 본질을 안 따라가면, 테스트가 가리는 곳에서 프레임워크가 보장하려던 것의 정반대가 벌어진다.

아직 부족하다. 결함 3개를 만들고 나서야 발견했고, 그중 2개는 다른 관점의 코드 리뷰에서 힌트를 얻었다. 처음부터 "이 테스트가 뭘 놓치고 있지?"를 질문할 수 있었다면 더 좋았을 것이다. 다음에는 그렇게 시작하고 싶다.

WIL - 9주차 (같은 best-effort라도, 어떤 방향으로 깨지는지가 설계다)

ioh'sDeveloper — Sat, 11 Apr 2026 00:40:30 +0900

이번 주에 새로 배운 것

"best-effort니까 괜찮다"는 설계가 아니다

Kafka Consumer에서 DB에 메트릭을 적재하는 기존 파이프라인에 Redis ZSET 랭킹 점수를 추가해야 했다. try-catch로 감싸면 Redis가 죽어도 DB 트랜잭션은 안 깨진다. "best-effort니까 이 정도면 충분하지 않을까?"

이 판단이 틀렸다. 같은 best-effort인데 ZINCRBY를 TX 안에 넣느냐, TX 커밋 후에 넣느냐에 따라 결함의 방향이 달랐다.

TX 안에서 ZINCRBY → TX COMMIT 실패 시 → Redis에는 반영됨, DB에는 안 됨
                 → 재처리 시 → double increment (over-count)

TX 커밋 후 ZINCRBY → COMMIT 성공 후 크래시 시 → DB에는 반영됨, Redis에는 안 됨
                   → 1건 영구 누락 (under-count)

over-count는 인기가 아닌 상품이 랭킹에 올라가는 것이고, under-count는 인기 상품의 점수가 0.1점 낮아지는 것이다. 사용자 관점에서 무게가 다르다. 게다가 over-count는 부하에 비례해서 반복 발생하고(데드락, 커넥션 타임아웃), under-count는 commit 직후 수 ms 안에 프로세스가 죽어야 하니 극히 드물다.

이 프로젝트에서 이미 ProductCacheManager가 동일한 afterCommit 패턴을 5곳에서 쓰고 있었다는 것도 판단을 뒷받침했다. 새로운 패턴을 도입한 게 아니라 기존 패턴을 확장한 것이다.

"best-effort"라는 단어로 사고를 멈추면 안 된다. 같은 best-effort 안에서도 over-count와 under-count는 완전히 다른 결함이다.

afterCommit의 구조적 한계를 발견하고 리팩터링한 과정

at-most-once를 afterCommit으로 구현했는데, 배치 리스너(MAX_POLL=3000)에서 건별로 afterCommit이 실행되니 ZINCRBY가 3000번, RTT가 3000회 발생했다. Docker 환경에서 Redis PING이 약 0.215ms였으니, 단순 계산으로 약 600ms. 동작은 했지만, 3000건을 한 번에 가져와 건별 RTT를 발생시키는 구조는 배치 처리의 이점을 거의 살리지 못했다.

더 큰 문제는 같은 배치 안에서 동일 상품의 이벤트를 합산할 수 없다는 것이었다. afterCommit은 각 process() 호출 끝에 독립적으로 실행되므로, "이 배치에 같은 상품이 또 있는지"를 알 수 없다.

process()가 ProcessResult(deltas) record를 반환하도록 바꾸고, Consumer에서 Map<Long, Double>로 합산한 뒤 Pipeline으로 일괄 전송하는 구조로 리팩터링했다. RTT가 3000회에서 2회(daily + hourly)로 줄었다. 정합성 모델(at-most-once)은 유지하면서.

정합성을 먼저 고정해두니까, 성능 최적화가 훨씬 다루기 쉬웠다. "이 변경이 at-most-once를 깨뜨리는가?"만 확인하면 됐으니까.

ZSET score는 역산할 수 없다 이걸 깨닫는 데 시간이 걸렸다

ZSET에 점수를 쌓으면서 score = 84.7이라는 숫자를 보고 있었는데, 문득 깨달았다. 이게 조회 몇 건, 좋아요 몇 건, 주문 몇 건의 합인지 분해할 수 없다. 가중합의 최종 결과만 남아있으니까.

가중치를 0.6에서 0.8로 바꾸고 싶으면? 기존 데이터 재계산 불가. 주간 랭킹을 만들고 싶으면? 이벤트 타입별 분해 불가. 그리고 Kafka retention이 7일이니까, 9주차에 원천 데이터 적재를 시작하지 않으면 9주차 이벤트가 10주차 전에 사라진다.

ranking_event 테이블을 만들면서, score_delta(0.1, 0.2 같은 계산된 값)가 아니라 raw fact(product_id, event_type, event_time)만 저장하기로 했다. delta는 가중치에 의존하지만, fact는 가중치와 무관하므로 나중에 어떤 가중치로든 재계산할 수 있다.

데이터는 한번 잃으면 다시 만들 수 없다. "나중에 하자"가 통하지 않는 영역이 있다.

이런 고민이 있었어요

회사에서 "비즈니스 가치를 만드는 개발"이 뭔지를 숫자로 보게 됐다

이번 주에 회사에서 내가 담당하는 이커머스 도메인의 수익 규모를 알게 됐다. 약 60억 원. 그런데 이 60억을 운영하는 사람들 정산팀, 상품 MD, 재고관리이 쓰는 백오피스는 운영 효율 관점에서 개선 여지가 컸다.

8주차에 DBA를 설득해서 테이블 튜닝 권한을 받았던 것처럼, 이번에도 리버스 엔지니어링으로 기존 시스템을 분석하면서 개선 포인트를 찾고 있다. 8주차에서는 "20만 건 스캔을 줄이겠다"는 구체적 수치로 설득했는데, 이번에도 같은 접근을 쓸 수 있을 것 같다. "이 수동 작업을 자동화하면 OO팀이 하루 N시간을 아낀다"는 수준으로 정량화할 수 있는 것부터 시작하려 한다.

과제에서 원천 데이터 적재를 고민한 것이 여기서도 연결됐다. 회사 시스템에도 상품 조회 수, 좋아요 같은 핵심 액션 데이터가 집계된 숫자로만 존재하는 경우가 많다. "조회 수 1 올리기"는 간단하지만, "이 상품이 언제, 어떤 유저에게 조회되었는가"를 시계열로 분석하려면 원천 데이터가 필요하다. MD가 "이 상품 왜 안 팔려?"라고 물었을 때 숫자로 답하려면, 집계값이 아니라 원천 이벤트가 있어야 한다. 이번 주에 ZSET의 역산 불가능 한계에서 출발한 "raw fact 저장" 원칙이, 회사 시스템을 바라보는 렌즈가 되고 있다.

가중치 0.1 차이로 순위가 뒤집히는 걸 직접 확인했다

설계 초기에 order 가중치를 0.7로 쓰려 했다. "0.1 + 0.2 + 0.7 = 1.0, 깔끔하니까." 그런데 발제 원문이 0.6이어서 반례를 만들어봤다.

상품 A: 주문 10건 → W=0.6이면 6.0, W=0.7이면 7.0
상품 B: 조회 7건 + 주문 9건 → W=0.6이면 6.1, W=0.7이면 7.0

0.6에서는 B가 이기고, 0.7에서는 동점이다. 숫자 하나로 순위가 바뀌었다. "합이 1이면 깔끔하다"는 심리적 편안함이지 설계 근거가 아니었다. ZINCRBY 점수는 확률이 아니니까 합이 1일 필요도 없고, unlike(-0.2)을 포함하면 이벤트 조합마다 "합"이 달라져서 전제 자체가 성립하지 않는다.

"비슷하겠지"로 넘어가지 않고 반례를 만들어 확인하는 습관이 이번 주에 생겼다.

아쉬웠던 점 & 다음에 해보고 싶은 것

정합성 요구 수준이 다른 것들은 더 일찍 분리했어야 했다

처음에는 CatalogMetricsConsumer 안에서 metrics와 ranking을 함께 처리해도 된다고 생각했다. 둘 다 같은 이벤트를 소비하고, 같은 시점에 계산되니 한곳에 두는 편이 단순해 보였기 때문이다.

그런데 Redis 타임아웃이 metrics 파이프라인까지 밀리게 되는 걸 보면서, 같은 입력을 받는다는 이유만으로 같은 경계 안에 둘 수는 없다는 걸 배웠다. 정확성이 중요한 도메인과 근사치를 허용하는 도메인은 장애의 전파 방식도, 보호해야 할 기준도 다르다.

이번 주의 아쉬움은 구현이 틀린 것이 아니라, 이 차이를 장애를 겪고 나서야 구조로 분리했다는 점이다. 다음부터는 기능이 비슷해 보여도 먼저 "이 로직은 얼마나 틀릴 수 있는가", "어디까지 지연을 허용할 수 있는가"를 기준으로 경계를 나누는 쪽으로 설계해보고 싶다.

회사 백오피스 개선을 구체화하고 싶다

60억 수익을 만드는 이커머스 도메인에서, 운영 도구 개선이 비즈니스 가치로 연결되는 개선 기준이 보이기 시작했다. 다음 주에는 "이 수동 작업을 자동화하면 하루 N시간 절약"이라는 수준으로 정량화할 수 있는 개선 포인트를 하나 구체화해보고 싶다. 8주차에 n8n을 알게 됐으니, 이걸 활용할 수 있는 시나리오가 있는지도 같이 검토할 예정이다.

KPT

Keep & Lesson

dual-write에서 결함 방향(over-count vs under-count)까지 따져서 at-most-once를 선택한 것. "best-effort"는 전제 조건이지 설계 판단이 아니다. 그 안에서 결함 방향을 정하는 것이 설계다 — 이건 캐시 무효화, 알림 발송 등 다른 dual-write 상황에서도 동일하게 적용 가능한 기준이다.
정합성을 먼저 고정한 뒤 성능을 최적화한 것. 순서가 반대였으면 매 변경마다 정합성을 처음부터 다시 따져야 했다.
ZSET 역산 불가능 한계를 인식하고, Kafka retention 7일을 의식해서 원천 데이터 적재를 선제적으로 시작한 것. 데이터는 한번 잃으면 다시 만들 수 없다.
가중치 0.6 vs 0.7의 차이를 반례로 확인한 것. 유사할 것이라 가정하지 않고, 반례 하나로 검증하는 습관.

Problem

Consumer 분리 판단이 늦었다. Redis 타임아웃 이슈를 겪은 후에야 장애 격리의 필요성을 인식했다
같은 이벤트를 소비한다는 이유로 metrics와 ranking을 한 경계에 두었다. 정합성 요구 수준이 다른 로직은 더 일찍 분리했어야 했다

Try

다음 과제에서는 구현 시작 전에 "정확성이 필요한가, 근사치를 허용할 수 있는가, 지연을 어디까지 허용할 수 있는가"를 먼저 분류하기
정합성 요구 수준이 다른 로직이 한 Consumer나 한 처리 경계 안에 같이 들어가 있지 않은지 먼저 확인하기
회사 백오피스 개선 포인트를 하나 정량화해서 제안하기

9주차 여정 요약

R7 Kafka 파이프라인 + R8 Redis 인프라 위에 랭킹 시스템 구축
    ↓
"ZINCRBY 한 줄 추가하면 되지?"
    → dual-write 문제 발견. best-effort 안에서도 결함 방향이 다르다.
    → over-count vs under-count → at-most-once(afterCommit) 선택.
    ↓
"afterCommit이면 끝 아닌가?"
    → 3000건 배치에서 건별 RTT 3000회 발생. 배치 합산 불가.
    → ProcessResult + Pipeline → RTT 3000→2회. 정합성 유지.
    ↓
"ZSET에 점수만 쌓으면 되는 거 아닌가?"
    → score = 84.7에서 조회/좋아요/주문 역산 불가.
    → ranking_event에 raw fact 적재. 가중치 독립적 재계산 가능.
    → Kafka retention 7일 → 지금 안 하면 이벤트 소실.
    ↓
회사에서 60억 이커머스 도메인의 백오피스를 보며
    → "비즈니스 가치를 만드는 개발"이 뭔지 고민 시작.
    → 과제에서 배운 원천 데이터 사고방식이 회사에서도 적용 가능.

지난 8주가 문제를 더 정확히 정의하고, 숫자로 근거를 세우는 훈련이었다면 9주차는 같은 best-effort 안에서도 어떤 결함 방향을 선택할지 판단하는 것이 설계라는 걸 배운 주였다. 그리고 데이터는 한번 잃으면 다시 만들 수 없다는 것. 이 두 가지가 이번 주의 핵심이다.

best-effort니까 괜찮지 않나? Kafka 랭킹 파이프라인에 afterCommit 대신 배치 구조를 선택한 이유

ioh'sDeveloper — Fri, 10 Apr 2026 02:41:50 +0900

best-effort니까 괜찮지 않나? Kafka 랭킹 파이프라인에 afterCommit 대신 배치 구조를 선택한 이유

TL;DR:

MySQL과 Redis에 동시에 쓰는 dual-write 문제에서, 이 랭킹 시나리오에서는 "가짜 인기를 만드는 것"보다 "인기를 살짝 놓치는 것"이 낫다고 판단해 at-most-once를 선택했다. afterCommit 패턴을 검토했지만 배치 최적화를 막는 구조적 한계를 발견하고, Consumer를 분리해 배치 수집 + Pipeline flush 구조를 설계했다. 정합성 모델은 유지하면서 Redis 네트워크 왕복을 건별 호출에서 배치 2회로 줄인 과정.

시작: 기존 파이프라인에 ZINCRBY 적용

이전에 Kafka 기반 이벤트 파이프라인을 구축해둔 상태였다. 상품 조회·좋아요·주문 이벤트를 Kafka 토픽(catalog-events-v1)으로 발행하고, Consumer가 배치로 소비해서 product_metrics 테이블에 집계하는 구조다.

[Kafka] catalog-events-v1
  → CatalogMetricsConsumer (배치 리스너, MAX_POLL=3000)
    → CatalogMetricsProcessor.process() — @Transactional
      → 멱등성 체크 (event_handled)
      → product_metrics upsert
      → event_handled INSERT
      → TX COMMIT

여기에 실시간 인기 상품 랭킹 기능을 추가해야 했다. Redis ZSET에 점수를 쌓는 것이 목표였고, 해야 할 일은 간단해 보였다. 기존 process() 안에서 rankingRepository.incrementScore(productId, delta)를 호출하면 된다. try-catch로 감싸면 Redis가 죽어도 DB 트랜잭션은 안 깨진다. best-effort니까 이 정도면 충분하지 않나?

문제는 best-effort 자체가 아니었다. 같은 best-effort라도 어떤 방향으로 실패하느냐에 따라, 랭킹이 왜곡되는 양상이 완전히 달랐다.

첫 번째 판단 : ZINCRBY를 TX 안에 넣을 것인가, 밖에 넣을 것인가

문제의 본질: Dual-Write

CatalogMetricsProcessor.process()는 @Transactional 안에서 DB 작업을 수행한다. 여기에 Redis ZINCRBY를 추가하면, 하나의 이벤트가 MySQL과 Redis 두 스토어에 써야 하는 상황이 된다.

MySQL과 Redis는 동일한 트랜잭션에 참여할 수 없다. 둘 중 하나만 성공하는 시나리오가 존재한다. 이게 dual-write 문제다.

두 가지 선택지

선택지 A: TX 내부 (try-catch 격리)

@Transactional process():
  1. 멱등성 체크
  2. DB metrics increment
  3. try { ZINCRBY } catch { log.warn }  ← Redis 실패해도 TX 안 깨짐
  4. event_handled 저장
  5. TX COMMIT

선택지 B: TX 커밋 후

@Transactional process():
  1. 멱등성 체크
  2. DB metrics increment
  3. event_handled 저장
  4. TX COMMIT

커밋 확인 후:
  5. try { ZINCRBY } catch { log.warn }

둘 다 Redis 실패를 try-catch로 무시한다. "best-effort니까 둘 다 괜찮지 않나?"라고 생각할 수 있다.

같은 best-effort 안에서도 결함의 방향이 다르다

두 선택지가 같은 best-effort라도 어떤 식으로 깨지는지, 코드보다 시퀀스로 비교하면 더 빠르게 보인다.

실패 시나리오	A (TX 내부)	B (커밋 후)
Redis 다운 → ZINCRBY 실패	1건 누락	1건 누락
ZINCRBY 성공 → TX COMMIT 실패	phantom increment	불가능 (아직 ZINCRBY 안 함)
TX COMMIT 실패 → 재처리	double increment	정상 (ZINCRBY 미실행)
COMMIT 성공 → 크래시 → ZINCRBY 미실행	불가능	1건 영구 누락

phantom increment를 풀어서 설명하면 이렇다: Redis에는 ZINCRBY로 점수가 올라갔지만 DB TX가 롤백되면서 event_handled에 기록이 남지 않는다. Kafka offset도 커밋되지 않으므로 같은 이벤트가 재소비되고, 멱등성 체크를 통과해서 ZINCRBY가 한 번 더 실행된다. 한 건의 이벤트가 Redis 점수를 두 번 올리는 것이다.

A는 과잉 반영(over-count) 방향으로 실패하고, B는 누락(under-count) 방향으로 실패한다.

어느 쪽이 더 나은가?

"가짜 인기"와 "놓친 인기"

랭킹은 사용자에게 "지금 뭐가 인기 있는지"를 알려주는 발견(discovery) 도구다.

over-count (A): DB에는 기록이 없는데 랭킹에는 올라가 있다. 인기가 아닌 상품이 상위에 노출된다. → 사용자 신뢰 훼손
under-count (B): DB에는 기록이 있는데 랭킹 점수가 살짝 낮다. 실제 인기보다 0.1점 낮을 뿐. → 순위에 미미한 영향

"없는 인기를 만드는 것"이 "있는 인기를 살짝 놓치는 것"보다 나쁘다.

발생 확률까지 따져보면

A의 결함(TX COMMIT 실패 후 재처리): 데드락, 커넥션 타임아웃 등 부하에 비례해 반복적으로 발생. 부하가 높을수록 축적됨
B의 결함(commit 직후 크래시): commit과 ZINCRBY 사이 수 ms 안에 정확히 프로세스가 죽어야 함. 극히 희귀하고 반복 패턴 없음

반복되는 결함은 축적되어 랭킹 왜곡이 점점 심해진다. 무작위적이고 드문 결함은 일간 리셋으로 자연 보정된다.

분산 시스템 용어로 정리하면

패턴	의미론	결함 방향
A (TX 내부)	at-least-once (Redis 관점)	중복 반영 가능
B (커밋 후)	at-most-once (Redis 관점)	누락 가능

이 랭킹 시나리오는 일일 리셋 + 근사치 허용이라는 특성이 있어서, at-most-once(B)가 더 맞다고 판단했다.

두 번째 판단 :afterCommit으로 충분한가

at-most-once를 결정했으니, "DB 커밋 후에만 Redis에 쓴다"를 어떻게 구현할 것인가. 가장 먼저 떠오른 건 TransactionSynchronization.afterCommit()이었다.

프로젝트에 이미 있는 afterCommit 패턴

이 프로젝트에서는 캐시 무효화에 이미 afterCommit을 5곳에서 사용하고 있었다.

// ProductCacheManager — DB 커밋 후 캐시 무효화
public void registerEvictAfterCommit(Long productId) {
    TransactionSynchronizationManager.registerSynchronization(
        new TransactionSynchronization() {
            @Override
            public void afterCommit() {
                redisTemplate.delete(DETAIL_KEY_PREFIX + productId);
            }
        }
    );
}

기존 (캐시 무효화)	랭킹
DB 커밋 후 Redis DEL	DB 커밋 후 Redis ZINCRBY
ProductCacheManager 4곳	—
OrderCacheManager 1곳	—

같은 Spring TX API, 같은 dual-write 문제, 같은 at-most-once 의미론. 랭킹에도 afterCommit을 쓰면 패턴 확장이지 새로운 도입이 아니다. 자연스러운 선택처럼 보였다.

하지만 캐시 무효화와 랭킹 점수 적재는 호출 빈도가 근본적으로 다르다.

afterCommit의 구조적 한계: 배치와 맞지 않는다

CatalogMetricsConsumer는 배치 리스너다. 한 번에 최대 3000건을 받아서 for문으로 건건이 processor.process()를 호출한다. 여기에 afterCommit을 붙이면 이렇게 된다:

배치 3000건 수신
→ for (record : records)
    → processor.process()        — @Transactional, DB 작업
      → afterCommit 콜백 등록
    → TX COMMIT
    → afterCommit 실행 → ZINCRBY  ← 1건마다 Redis RTT 1회

3000건이면 ZINCRBY 3000회, Redis RTT 3000회.

캐시 무효화는 상품 수정·삭제 같은 저빈도 이벤트에서 발생한다. 한 번에 수천 건씩 캐시를 날리는 일은 없다. afterCommit이 건별로 실행돼도 문제가 없다.

하지만 랭킹 이벤트는 조회·좋아요·주문이다. 배치 한 번에 3000건이 들어온다. 건별 afterCommit은 배치의 의미를 없앤다.

더 큰 문제: 배치 정제가 불가능

같은 배치 안에서 동일 상품에 대한 이벤트가 여러 건 있을 수 있다.

배치 3000건 중:
  product:42에 대한 조회 이벤트 50건 → delta 합산 = 50 × 0.1 = 5.0
  product:42에 대한 좋아요 이벤트 3건 → delta 합산 = 3 × 0.2 = 0.6
  → product:42에 대해 ZINCRBY 1회 (5.6)로 충분

하지만 afterCommit은 각 process() 호출 끝에 독립적으로 실행된다.

process() 안에서는 "이 배치에 같은 상품이 또 있는지" 알 수 없다. 배치 레벨 합산이 구조적으로 불가능하다.

afterCommit은 "TX 커밋 후 실행"이라는 정합성은 보장하지만, 호출 단위가 이벤트 1건에 묶여 있어서 배치 최적화를 구조적으로 막는다. 캐시 무효화에는 맞지만, 대량 이벤트를 집계하는 랭킹에는 맞지 않았다.

해결: Consumer 분리 + 배치 수집

afterCommit의 한계는 "process() 안에서 Redis 쓰기를 결정하는 구조" 자체에 있었다.

이벤트 1건 단위로 process()가 호출되는 이상, afterCommit이든 반환값이든 건별 처리에서 벗어날 수 없다.

해결책은 랭킹 책임을 별도의 Consumer로 분리하는 것이었다.

같은 토픽, 다른 Consumer Group

[Kafka] catalog-events-v1
  ├─ catalog-metrics-group → CatalogMetricsConsumer
  │   → CatalogMetricsProcessor.process() — 기존 메트릭 집계 (DB만)
  │
  └─ ranking-group → RankingConsumer (신규)
      → 배치 수집 + Redis flush

기존 CatalogMetricsConsumer는 건드리지 않았다. 같은 토픽을 다른 Consumer Group으로 독립 소비하는 RankingConsumer를 추가했다. 메트릭 집계와 랭킹 점수 적재가 서로 영향을 주지 않는다.

saveAndCollectDelta: DB INSERT 성공 후에만 delta 수집

RankingConsumer의 핵심은 saveAndCollectDelta()다.

// RankingConsumer.java
private void saveAndCollectDelta(String outboxId, long productId, String eventType,
                                  ZonedDateTime eventTime, double delta,
                                  Map<Long, Double> batchScores) {
    RankingEventEntity event = RankingEventEntity.of(outboxId, productId, eventType, eventTime);

    try {
        rankingEventRepository.save(event);
    } catch (DataIntegrityViolationException e) {
        log.debug("[Ranking] 중복 스킵 — outboxId={}, productId={}", outboxId, productId);
        return;
    }

    // INSERT 성공 = 신규 이벤트 → delta 수집
    if (delta != 0.0) {
        batchScores.merge(productId, delta, Double::sum);
    }
}

동작 방식:

ranking_event 테이블에 INSERT를 시도한다. 이 테이블의 유니크 제약이 멱등성을 보장한다.
DataIntegrityViolationException이 발생하면 중복 이벤트이므로 delta를 수집하지 않고 스킵한다.
INSERT가 성공하면 — DB에 커밋된 이벤트만 — delta를 batchScores Map에 합산한다.

rankingEventRepository.save()는 Spring Data의 기본 트랜잭션으로 개별 커밋된다.

Consumer 메서드(consume())에는 @Transactional이 없다. 따라서 save()가 반환되는 시점에 DB 커밋은 이미 완료된 상태다. delta 수집은 커밋 이후에 일어난다.

이 구조가 afterCommit과 같은 at-most-once 보장을 제공하면서도, delta를 반환값으로 올릴 수 있는 이유다.

Consumer 배치 루프

// RankingConsumer.java — consume()
@KafkaListener(topics = "catalog-events-v1", groupId = "ranking-group",
               containerFactory = "BATCH_LISTENER_DEFAULT")
public void consume(List<ConsumerRecord<Object, Object>> records, Acknowledgment ack) {
    Map<Long, Double> batchScores = new HashMap<>();

    for (ConsumerRecord<Object, Object> record : records) {
        // 이벤트 파싱 → saveAndCollectDelta() 호출
        // batchScores에 동일 상품 delta가 자동 합산됨
        processEvent(eventType, idempotencyKey, payload, eventTime, batchScores);
    }

    rankingScoreUpdater.flushBatch(batchScores);
    ack.acknowledge();
}

핵심: batchScores는 Consumer의 배치 루프가 소유한다. 3000건의 for문이 끝난 후, 합산된 Map 하나를 flushBatch()에 넘긴다. 동일 상품에 대한 이벤트가 50건이든 100건이든, Map에서 하나의 엔트리로 합쳐진다.

flushBatch(): Pipeline으로 일괄 적재

// RankingScoreUpdater.java
public void flushBatch(Map<Long, Double> scores) {
    if (scores.isEmpty()) return;
    try {
        String dailyKey = generateDailyKey();
        rankingRedisRepository.incrementScoreBatch(dailyKey, scores, dailyTtl);

        String hourlyKey = generateHourlyKey();
        rankingRedisRepository.incrementScoreBatch(hourlyKey, scores, hourlyTtl);
    } catch (Exception e) {
        log.warn("[Ranking] 배치 flush 실패 — products={}건, best-effort 누락",
                scores.size(), e);
    }
}

// RankingRedisRepository.java
public void incrementScoreBatch(String key, Map<Long, Double> scores, long ttlSeconds) {
    redisTemplate.executePipelined((RedisCallback<Object>) connection -> {
        byte[] rawKey = redisTemplate.getStringSerializer().serialize(key);
        for (Map.Entry<Long, Double> entry : scores.entrySet()) {
            byte[] member = redisTemplate.getStringSerializer()
                    .serialize(String.valueOf(entry.getKey()));
            connection.zSetCommands().zIncrBy(rawKey, entry.getValue(), member);
        }
        return null;
    });
    setTtlIfAbsent(key, ttlSeconds);
}

성능 변화

Before (afterCommit 구조를 적용했다면):
  3000건 → ZINCRBY 3000회 → Redis RTT 3000회

After (Consumer 분리 + 배치 수집):
  3000건 → 합산 → 유니크 상품 약 150건 (테스트 배치 기준) → Pipeline 2회 (daily + hourly)

RTT 횟수 기준으로 3000회에서 2회. Pipeline 내부에서 150개의 ZINCRBY 커맨드가 실행되지만, 이건 하나의 네트워크 왕복 안에서 처리된다. 합산 연산(Map.merge)은 메모리 내 O(N)이라 무시할 수 있는 수준이다.

at-most-once는 유지되는가?

Consumer를 분리하고 배치 수집 구조로 바꾸면서, 정합성 모델이 달라지지 않았는지 확인해야 한다.

실제 보장 구조

정상 흐름:
  save() 성공 (DB 커밋) → delta 수집 → flushBatch() 성공 → ack
  → Redis 반영 ✓, DB 반영 ✓

save() 중복:
  save() → DataIntegrityViolationException → delta 미수집 → Redis 미반영
  → 멱등성 보장 ✓

flush 실패 (Redis 장애):
  save() 성공 → delta 수집 → flushBatch() 실패 → 로그 경고 → ack
  → DB에는 기록 있음, Redis에는 없음 (under-count) ✓

배치 중간 크래시:
  records 1~500: save() 성공, delta 수집 (메모리)
  record 501: 크래시
  → flushBatch() 미실행 → Redis 미반영 (under-count)
  → 재처리 시: records 1~500은 중복으로 스킵, 501~3000은 정상 처리

모든 실패 시나리오에서 over-count가 발생하지 않는다.
DB INSERT(ranking_event)가 delta 수집의 게이트이고, Redis flush는 항상 INSERT 이후에 실행된다. INSERT가 성공했지만 flush 전에 실패하면 under-count, flush까지 성공하면 정확히 반영된다.

재처리 시에도 DataIntegrityViolationException이 중복 INSERT를 막으므로, 같은 이벤트에 대해 ZINCRBY가 두 번 실행되는 경로가 없다.

새로운 트레이드오프: 유실 단위

방식	유실 단위	유실 시 영향
afterCommit (건별)	이벤트 1건	0.1~0.6점 누락
Consumer 분리 + 배치	배치 전체 (최대 3000건)	수십~수백 점 누락

배치 flush가 실패하면 건별이 아니라 배치 단위로 날아간다.

afterCommit 방식이었다면 3000건 중 1500건까지 성공하고 나머지만 실패하는 partial failure가 가능했겠지만, 배치 flush는 all-or-nothing이다.

이 트레이드오프를 수용한 근거는 두 가지다:

발생 조건: flush 실패는 Redis 장애(다운, 네트워크 타임아웃, 커넥션 끊김) 상황에서만 발생한다. 이 상황에서는 afterCommit 방식도 전건 실패할 가능성이 높다.
복구 메커니즘: 랭킹은 일일 리셋된다. 배치 단위 유실이 발생해도 다음 리셋 주기에 자연 보정된다. 그리고 ranking_event 테이블에 원본이 남아 있으므로, 필요하면 DB 기반으로 점수를 재계산할 수 있다.

정리 : 파이프라인 설계 과정

1단계: "ZINCRBY 끼워 넣으면 되지?"
  → dual-write 문제 발견

2단계: TX 안 vs TX 밖 → at-most-once 선택
  → 결함의 방향(over-count vs under-count)으로 판단

3단계: afterCommit 검토 → 배치 최적화를 막는 구조적 한계 발견
  → Consumer 분리 + 배치 수집으로 설계

4단계: at-most-once 유지 확인 + 유실 단위 변경 인식

판단	선택	근거
정합성 모델	at-most-once	over-count가 under-count보다 위험
구현 방식	Consumer 분리 (ranking-group)	afterCommit은 건별 실행으로 배치 최적화 불가
멱등성	ranking_event INSERT + 유니크 제약	DataIntegrityViolationException으로 중복 차단
배치 최적화	Map 합산 + Pipeline flush	동일 상품 delta 합산 → 유니크 상품 수만큼만 ZINCRBY
Redis 쓰기 대상	Master 전용 template	쓰기 연산은 반드시 Master에서

단순한 Redis 호출 추가가 아니라 "파이프라인을 어떻게 확장할 것인가"의 문제였다. 정합성 모델을 먼저 정하고, 구현 방식을 나중에 결정했다. 순서가 반대였으면 배치 성능을 먼저 잡고 정합성을 나중에 끼워 넣으면 구조가 훨씬 복잡해졌을 거다.

이번 경험에서 가장 크게 느낀 건, 결함의 방향을 먼저 고정해두면 이후 설계가 훨씬 다루기 쉬워진다는 점이다.

at-most-once라는 기준이 먼저 서 있으니까, Consumer 분리와 배치 구조를 설계할 때도 "이 변경이 over-count를 만드는가?"만 확인하면 됐다. 순서가 반대였다면 성능을 먼저 잡고 정합성을 나중에 끼워 넣었다면 매 변경마다 정합성을 처음부터 다시 따져야 했을 거다.

Redis 키 설계 전략이 중요한 이유 시간의 양자화와 롱테일

ioh'sDeveloper — Fri, 10 Apr 2026 02:39:59 +0900

TL;DR:

랭킹 ZSET의 키 하나가 "무엇을 측정하는가"를 결정한다. 누적 키는 롱테일을 만들고, 일간 키는 콜드 스타트를 만든다. 키를 자르는 순간 정보가 손실되고, 그 손실을 carry-over와 fallback으로 메운다. 키 설계는 네이밍이 아니라 데이터 모델링이다.

랭킹 키 하나의 무게

이커머스 인기 상품 랭킹을 만들면서 가장 먼저 마주친 질문은 이거였다.

ranking:{productId} → score

이 ZSET의 키 이름을 어떻게 지을 것인가.

처음에는 네이밍 문제라고 생각했다. ranking:all이든 ranking:daily든, 어차피 ZINCRBY로 점수를 올리는 건 같으니까. 키 이름은 규칙만 맞추면 되는 거 아닌가?

이 생각이 틀렸다. 키 이름이 결정하는 건 "어디에 저장하는가"가 아니라 "무엇을 측정하는가"였다.

ranking:all → 역대 누적 인기
ranking:all:20260408 → 2026년 4월 8일의 인기
ranking:hourly:2026040814 → 오후 2시~3시 사이의 인기

같은 ZSET, 같은 ZINCRBY, 같은 상품인데 키가 다르면 "인기"의 의미 자체가 달라진다.

누적의 함정 롱테일이 생기는 이유

처음에는 키 하나에 모든 점수를 누적하는 게 가장 단순해 보였다.

ranking:all → ZINCRBY 0.1 product:42  (조회)
ranking:all → ZINCRBY 0.2 product:42  (좋아요)
ranking:all → ZINCRBY 0.6 product:42  (주문)

그런데 이 구조를 며칠 운영하면 벌어지는 일:

Day 1~100: 상품 A가 매일 100건 조회 → score 1,000
Day 101:   상품 B가 바이럴 → 하루에 5,000건 조회

누적 랭킹:  상품 A (1,000) < 상품 B (5,000)  ← 아직은 괜찮음

Day 1~365: 상품 A가 꾸준히 → score 36,500
Day 366:   상품 C가 바이럴 → 하루에 10,000건

누적 랭킹:  상품 A (36,500) > 상품 C (10,000)  ← 문제 발생

상품 C가 오늘 압도적으로 뜨거운데, 1년간 꾸준히 팔린 상품 A를 이길 수 없다.

이걸 롱테일(Long Tail) 현상이라 한다 소수의 오래된 상품이 상위를 독점하고, 신상품은 아무리 화제여도 노출 기회가 없다.

비유하면

음악 차트를 생각해보자. 빌보드 Hot 100은 주간 차트다. 역대 누적 차트라면 비틀즈가 아직도 1위일 거다. 그러면 이번 주에 뭐가 유행하는지 아무도 모른다.

랭킹의 가치는 "지금 뭐가 핫한가"를 알려주는 데 있다. 누적은 그 가치를 파괴한다.

시간을 자르다 양자화(Quantization)

해법은 시간 윈도우를 자르는 것이다.

연속적인 시간: ─────────────────────────────────→
               00:00  06:00  12:00  18:00  24:00

일간 양자화:   |<──────── 하루 한 버킷 ──────────>|

시간별 양자화: |<─1H─>|<─1H─>|  ...  |<─1H─>|
               버킷 24개

"양자화"라는 단어가 거창해 보이지만, 본질은 연속적인 시간을 불연속적인 구간으로 나누는 것이다. 물리학에서 빌려온 개념인데, 에너지가 연속이 아니라 특정 단위(양자)로만 존재하는 것처럼 우리의 랭킹 데이터도 "오늘", "어제" 같은 단위로만 존재하게 만드는 거다.

Redis 키로 표현하면:

ranking:all:20260408  → 오늘의 인기
ranking:all:20260407  → 어제의 인기

매일 자정에 새 키가 시작된다. 모든 상품이 동일한 출발선에서 경쟁한다.

어떤 윈도우를 선택할 것인가

시간을 자르는 방식은 크게 세 가지다.

Tumbling Window (우리 선택):
|<── Day 1 ──>|<── Day 2 ──>|<── Day 3 ──>|
겹치지 않는 고정 구간. 경계에서 "딱" 리셋된다.

Sliding Window:
T=10시: |<── 최근 24시간 ──>|  (어제 10시 ~ 오늘 10시)
T=11시:   |<── 최근 24시간 ──>|  (어제 11시 ~ 오늘 11시)
매 순간 "최근 N시간"을 계산. 경계가 없다.

Hopping Window:
|<──── 2시간 ────>|
     |<──── 2시간 ────>|
윈도우가 겹친다. Tumbling과 Sliding의 중간.

왜 Tumbling을 선택했는가:

Redis ZSET의 score는 하나의 숫자다. 인기 점수로 쓰고 있으면, 같은 score에 타임스탬프를 넣을 수 없다. Sliding Window를 구현하려면 개별 이벤트의 시각을 저장하고 매번 범위 조회를 해야 하는데 그러면 score를 인기 점수와 타임스탬프에 동시 사용할 수 없으므로 ZINCRBY 누적 구조를 변경해야 한다.

방식	구현 난이도	경계 문제	Redis ZSET 적합성
Tumbling	낮음	있음 (자정 리셋)	높음 — 일간 키 분리로 자연 구현
Sliding	높음	없음	낮음 — score를 점수와 시간에 동시 사용 불가
Hopping	중간	완화	중간 — Kafka Streams 등 스트림 엔진에서 주로 사용

Tumbling은 경계 문제가 있다. 23:59에 1위였던 상품이 00:00에 사라진다. 이 문제를 다음 장에서 다룬다.

자르면 깨지는 것 콜드 스타트

시간을 자르면 롱테일은 해결된다. 여기서 끝난 줄 알았다. 일간 키로 나누면 매일 공정한 경쟁이 시작되니까, 이제 키 설계는 끝 아닌가?

그런데 자르면 반드시 깨지는 것이 있었다.

23:59:59  상품 A는 오늘 1위. score 847.3
00:00:00  새 키 시작. 상품 A의 score: 0

사용자: "인기 상품" 클릭 → 빈 목록

콜드 스타트 시스템에 충분한 데이터가 없는 상태. 방금 전까지 1위였던 상품이 자정을 기점으로 사라진다.

이중 방어: carry-over + API fallback

이 문제를 하나의 장치가 아니라 두 가지 장치로 해결했다.

장치 1: Score Carry-Over (능동적 해결)

매일 23:50에 스케줄러가 실행된다.

@Scheduled(cron = "0 50 23 * * *", zone = "Asia/Seoul")
public void carryOver() {
    // ZUNIONSTORE ranking:all:{내일} 1 ranking:all:{오늘} WEIGHTS 0.1
    rankingRedisRepository.carryOver(tomorrowKey, todayKey, 0.1, ttlSeconds);
}

오늘 점수의 10%를 내일 키에 미리 복사한다. 자정이 되면 빈 목록이 아니라, 어제의 인기 상품이 낮은 점수로 대기하고 있다.

carry-over를 Lua Script로 감쌌다. 소스 키가 없으면 skip, destination에 TTL이 없으면 설정 이 전체를 원자적으로:

local exists = redis.call('EXISTS', KEYS[2])
if exists == 0 then return 0 end
redis.call('ZUNIONSTORE', KEYS[1], 1, KEYS[2], 'WEIGHTS', ARGV[1])
local ttl = redis.call('TTL', KEYS[1])
if ttl == -1 then redis.call('EXPIRE', KEYS[1], ARGV[2]) end
return redis.call('ZCARD', KEYS[1])

왜 0.1인가? 이건 감이 아니라 숫자로 검증했다.

Day 1: score 1000 (원본)
Day 2: 1000 × 0.1     = 100
Day 3: 1000 × 0.1²    = 10
Day 4: 1000 × 0.1³    = 1
Day 5: 1000 × 0.1⁴    = 0.1  ← 사실상 소멸

지수 감쇠 패턴이다. 0.1이면 4~5일 내에 영향이 사라진다. 너무 크면 롱테일이 다시 나타나고, 너무 작으면 carry-over 효과가 미미하다.

weight	Day 2	잔존 사실상 소멸	효과
0.01	1%	2일	carry-over 의미 거의 없음
0.1	10%	4~5일	자정 전환 완화 + 빠른 감쇠
0.3	30%	7~8일	전날 영향이 오래 남음
0.5	50%	10일+	롱테일 재발 위험

장치 2: API Fallback (방어적 해결)

스케줄러가 실패할 수도 있다 서버 재시작, Redis 장애, 배포 타이밍. 그래서 API 레벨에서 한 번 더 방어한다.

// 오늘 키가 비어있으면 어제 키로 대체
if (totalCount == 0 && (date == null || date.isBlank())) {
    String fallbackKey = buildFallbackKey(isHourly);
    long fallbackCount = rankingRedisRepository.getSize(fallbackKey);
    if (fallbackCount > 0) {
        key = fallbackKey;
        totalCount = fallbackCount;
    }
}

왜 둘 다 필요한가

시나리오 1: 정상 동작
  23:50 carry-over ✅ → 00:00 데이터 있음 → fallback 불필요

시나리오 2: carry-over 실패
  23:50 서버 다운 → 00:00 빈 키 → fallback ✅ 어제 키 조회

시나리오 3: 둘 다 없으면
  00:00 빈 키 → API 빈 배열 반환 → 사용자 이탈 ❌

carry-over는 미리 준비하는 것이고, fallback은 실패했을 때 대응하는 것이다. 비용이 거의 없고, 서로 독립적이며, 둘 다 있으면 더 견고하다.

실측: 이 설계가 메모리를 얼마나 쓰는가

설계를 마치고, "상품 10만 개면 실제로 얼마나 쓸까?"를 측정했다.

측정 환경: Docker Redis 7.4 컨테이너, maxmemory 512MB

ZSET 1개 (10만 멤버):  9.24 MB  (멤버당 96.8 bytes)  ← 실측

일간 키 2개(오늘 + 어제) + 시간 키 4개가 동시에 존재하는 최악의 경우:

전체 키 동시 존재 시:  33.71 MB  (maxmemory 512MB의 6.6%)  ← 실측

여유 있다. 상품이 100만 개로 늘어나면? 별도로 100만 멤버 ZSET도 측정했다.

100만 멤버 ZSET:  84.3 MB  (멤버당 88.3 bytes)  ← 실측. jemalloc 최적화로 대량일수록 효율적

100만 상품이라도 일간 키 1개가 약 84MB. TTL 2일이면 약 168MB 이건 실측에서 역산한 추정값이다. 이 프로젝트의 Redis maxmemory(512MB) 기준으로는 운영 가능한 수준이다. 상품 수가 이보다 훨씬 많거나 Redis 메모리가 작다면 Top-N 전략(하위 멤버 주기적 제거)을 검토해야 한다.

키는 계약이다

마지막으로 간과하기 쉬운 것 — 키 포맷은 시스템 구성요소 간의 계약이다.

이 프로젝트에서 랭킹 키를 읽고 쓰는 주체가 3개 있다:

[commerce-streamer]   ZINCRBY ranking:all:20260408 0.6 42  (쓰기)
[commerce-api]        ZREVRANGE ranking:all:20260408 0 19  (읽기)
[carry-over 스케줄러] ZUNIONSTORE ranking:all:20260409 ... (쓰기+읽기)

이 셋이 같은 키 패턴을 사용해야만 데이터가 연결된다. 키 prefix나 날짜 포맷이 하나라도 다르면, 쓰기는 성공하는데 읽기에서 빈 결과가 나온다 에러 없이, 조용히.

그래서 키 prefix를 코드에 하드코딩하지 않고 @ConfigurationProperties로 외부화했다.

ranking:
  key-prefix: "ranking:all"
  ttl-days: 2
  hourly-key-prefix: "ranking:hourly"
  hourly-ttl-hours: 4

키가 바뀌면 양쪽이 동시에 깨진다. 설정을 공유함으로써 한 곳을 바꾸면 양쪽이 함께 바뀌게 만든 거다.

타임존: "오늘"은 누구의 오늘인가

LocalDate today = LocalDate.now(ZoneId.of("Asia/Seoul"));

이 ZoneId.of("Asia/Seoul")이 빠지면, 서버가 UTC로 설정되어 있을 때 한국 시간 오전 8시에 "오늘"이 달라진다. 사용자는 "오늘의 인기 상품"을 눌렀는데 어제 데이터를 보게 된다.

한국 대상 서비스라면 KST 기준이 자연스러운 선택이다. 사용자의 "오늘"과 시스템의 "오늘"이 일치해야 한다. 다만 글로벌 서비스라면 유저별 타임존이나 UTC 기준 + 클라이언트 변환을 고려해야 한다.

정리 키 설계에서 내린 판단들

판단	선택	근거
키 단위	일간 Tumbling Window	ZSET score와 시간 분리, 롱테일 방지
TTL	2일	오늘 + 어제 유지, fallback + carry-over 대비
타임존	KST	사용자의 "오늘"과 일치
콜드 스타트	carry-over + fallback	능동 + 방어, 이중 장치
감쇠율	0.1 (지수 감쇠)	4~5일 소멸, 롱테일 재발 방지
키 공유	ConfigurationProperties	쓰기/읽기 주체 간 계약을 설정으로 보장

키 하나의 이름이 "무엇을 측정하는가"를 결정하고, TTL이 "얼마나 기억하는가"를 결정하고, carry-over가 "얼마나 부드럽게 전환하는가"를 결정한다.

키 설계는 네이밍이 아니라 데이터 모델링이다. 키를 정하는 순간 "무엇을 측정하고, 얼마나 기억하고, 무엇을 잃어도 되는가"가 결정된다. 이 판단을 코드가 아니라 키 이름이 먼저 내린다.

@Transactional이 삼킨 커넥션, BCrypt가 놓아주지 않은 150ms

ioh'sDeveloper — Wed, 8 Apr 2026 02:51:02 +0900

@Transactional(readOnly = true)를 습관적으로 붙이면 안전한 줄 알았다. 그런데 인증 메서드 안에 BCrypt가 있으면, DB가 아무 일도 안 하는 150ms 동안 커넥션을 잡고 놓아주지 않는다. 커넥션 40개짜리 풀에서 동시 30명이 인증하면, 다른 API는 커넥션을 기다리다 죽는다. 어노테이션 한 줄 지우는 것이 성능 최적화의 전부였다.

발견: "readOnly면 가볍다"는 착각

이커머스 프로젝트에서 인증 메서드를 작성하면서, 읽기 전용 메서드에는 습관적으로 @Transactional(readOnly = true)를 붙였다. 읽기 전용이면 flush도 안 하고, 스냅샷도 안 만들고, 최적화만 해주는 거라고 알고 있었으니까.

그런데 부하 테스트 시나리오를 설계하면서 커넥션 풀 사용률을 계산하다가 이상한 점을 발견했다. 인증 메서드의 커넥션 점유 시간이 예상보다 훨씬 길었다. DB 쿼리는 5ms면 끝나는데, 커넥션은 155ms 동안 잡혀 있었다. readOnly여도 커넥션은 점유한다. 그리고 그 점유 시간의 대부분은 DB가 아닌 BCrypt가 차지하고 있었다.

이게 실제로 문제가 되는 상황인지 확인하기 위해 코드를 추적했다.

현장: 우리 코드의 인증 흐름

프로젝트의 인증은 @AuthUser라는 커스텀 어노테이션으로 동작한다. Controller 메서드의 파라미터에 @AuthUser를 붙이면, Spring이 요청 헤더에서 아이디와 비밀번호를 꺼내 인증한 뒤 User 객체를 주입한다.

// OrderController.java
@PostMapping("/api/v1/orders")
public ApiResponse<OrderResponse> createOrder(@AuthUser User user, ...) {
    // user는 이미 인증 완료된 상태
}

이 @AuthUser가 붙은 엔드포인트가 프로젝트 전체에 35개 이상이다. 주문, 결제, 장바구니, 쿠폰, 포인트, 좋아요, 대기열 인증이 필요한 거의 모든 API.

실제 인증을 수행하는 코드는 이렇다.

// UserService.java
@Transactional(readOnly = true)  // ← 이게 문제
public User authenticateUser(String rawLoginId, String rawPassword) {
    User user = this.userRepository.findByLoginId(rawLoginId)      // DB 조회
            .orElseThrow(() -> new CoreException(UserErrorType.UNAUTHORIZED));

    if (!this.passwordEncryptor.matches(rawPassword, user.getPassword())) {  // BCrypt
        throw new CoreException(UserErrorType.UNAUTHORIZED);
    }
    return user;
}

두 줄이다. findByLoginId()로 사용자를 찾고, passwordEncryptor.matches()로 비밀번호를 비교한다. 간단해 보인다. 그래서 @Transactional(readOnly = true)를 붙여놓고 "읽기 전용이니까 안전하겠지"라고 넘어갔었다.

하지만 이 두 줄의 실행 시간은 전혀 다르다.

측정: 두 줄의 시간 차이

findByLoginId(): 단일 SELECT 쿼리. 인덱스가 걸려 있으니 ~1-5ms.
BCrypt.matches(): 비밀번호 해시를 비교하는 순수 CPU 연산. 하드웨어에 따라 다르지만, 일반적인 서버 환경에서 strength=10(기본값) 기준 대략 100ms 전후. 고성능 CPU에서는 ~50ms, 저사양 클라우드 인스턴스에서는 ~300ms까지 걸릴 수 있다.

DB가 일하는 시간은 5ms. BCrypt가 CPU를 점유하는 시간은 150ms. 그런데 @Transactional 때문에 이 155ms 전체 동안 DB 커넥션이 잡혀 있다.

커넥션 효율: 5ms / 155ms = 3.2%.

96.8%의 시간 동안 커넥션은 아무것도 하지 않으면서 풀에서 빠져 있다.

추적: @Transactional이 커넥션을 잡는 정확한 시점

"readOnly면 커넥션을 안 잡는 것 아닌가?"라는 생각이 틀린 이유를 확인하기 위해, Spring 소스 코드의 호출 스택을 따라갔다.

핵심은 TransactionManager가 트랜잭션을 시작하는 시점에 있다. 이 프로젝트는 Spring Boot + JPA 구성이므로 실제 TransactionManager는 JpaTransactionManager다 (순수 JDBC 환경의 DataSourceTransactionManager와 다르다).

JpaTransactionManager는 Hibernate의 "delayed connection acquisition"을 지원해서, 경우에 따라 첫 번째 SQL 실행 시점까지 물리 커넥션 획득을 지연할 수 있다. 하지만 readOnly=true일 때는 다르다. Connection.setReadOnly(true)를 JDBC 레벨에서 호출해야 하기 때문에, 트랜잭션 시작 시점에 물리 커넥션을 즉시 획득한다.

// JpaTransactionManager → HibernateJpaDialect.beginTransaction() 내부 흐름
// 1. EntityManager 생성
// 2. prepareConnection=true (기본값) 이고 readOnly=true이면
//    → 물리 커넥션 즉시 획득
//    → DataSourceUtils.prepareConnectionForTransaction() 호출
//      → Connection.setReadOnly(true)  ← 이것 때문에 커넥션이 필요
// 3. 커넥션은 트랜잭션 종료 시점까지 유지

readOnly 플래그를 설정하려면 커넥션이 이미 획득되어 있어야 한다. readOnly=true는 커넥션 획득을 생략하는 것이 아니라, 획득한 커넥션에 대한 힌트를 설정하는 것이다. "readOnly이면 가볍다"는 건 flush와 스냅샷에 대한 이야기지, 커넥션에 대한 이야기가 아니었다.

참고: readOnly=false이고 isolation 커스터마이징이 없는 경우에는, JpaTransactionManager가 Hibernate의 delayed connection acquisition으로 커넥션 획득을 첫 SQL 시점까지 지연할 수 있다. 하지만 이번 케이스는 readOnly=true이므로 즉시 획득이 발생한다.

계산: 대기열과 만나면 어떻게 되는가

이 프로젝트에는 대기열 시스템이 있다. 스케줄러가 1초마다 30명씩 활성화하고, 활성화된 사용자가 주문 API를 호출한다. 주문 API에는 @AuthUser가 붙어 있다.

시나리오: 스케줄러가 30명에게 토큰을 발급한다. 30명이 거의 동시에 주문 API를 호출한다.

프로젝트의 HikariCP 설정:

설정	값
maximum-pool-size	40
minimum-idle	30
connection-timeout	3000ms (3초)

@Transactional이 있을 때:

항목	계산
동시 인증 요청	30개
커넥션 점유 시간	~155ms (findByLoginId 5ms + BCrypt 150ms)
점유 커넥션 수	30개
남는 커넥션	40 - 30 = 10개
주문+결제+조회 처리 여유	10개로 모든 걸 감당

@Transactional을 제거하면:

항목	계산
동시 인증 요청	30개
커넥션 점유 시간	~5ms (findByLoginId만)
점유 커넥션 수	거의 0 (5ms면 즉시 반환)
남는 커넥션	40개 전부 가용
BCrypt 실행 환경	커넥션 없이 CPU만 사용

Little's Law로 검증하면:

L = λ × W  (평균 점유 = 도착률 × 체류시간)

■ 수정 전: L = 30 req/s × 0.155s = 4.65개 커넥션 평균 점유
■ 수정 후: L = 30 req/s × 0.005s = 0.15개 커넥션 평균 점유

→ 커넥션 평균 점유가 31배 감소

탐구: readOnly=true가 실제로 하는 일

"readOnly가 커넥션과 무관하다면, 그럼 대체 뭘 하는 건가?" 이 질문에 답하기 위해 readOnly가 동작하는 3개 레이어를 추적했다.

각 최적화가 authenticateUser()에 효과가 있는지 판단했다.

최적화	효과가 큰 상황	authenticateUser()에서의 효과
스냅샷 생략	대량 엔티티 조회 (수백 건 이상)	무의미 — 이 프로젝트는 Entity-level DIP 적용. JPA Entity를 POJO로 변환 후 반환하므로 영속성 컨텍스트에 엔티티가 남지 않음
Flush 생략	읽기+쓰기가 섞인 트랜잭션	무의미 — 순수 읽기 메서드. flush할 변경이 없음
JDBC readOnly	Master-Slave 분리 환경	무의미 — 단일 DataSource 구성. Slave 라우팅 없음

세 가지 최적화 모두 이 메서드에서는 실질적 이득을 주지 않는다. @Transactional(readOnly = true)는 커넥션만 잡고, 최적화는 제공하지 않는 상태였다.

탐구: BCrypt는 왜 이렇게 느린가

이쯤에서 "BCrypt가 150ms나 걸리는 게 정상인가?"라는 의문이 생긴다. 결론부터 말하면, 의도적으로 느리게 설계된 것이다.

BCrypt의 시간 복잡도는 O(2^strength). 프로젝트의 BCryptPasswordEncoder는 기본 strength인 10을 사용하므로 1,024 라운드의 Blowfish 키 스케줄링이 실행된다.

이렇게 느린 이유는 단순하다. brute-force 공격 방어. 해커가 초당 10억 개의 MD5 해시를 시도할 수 있다면, BCrypt(strength=10)로는 초당 5~10개만 시도할 수 있다. 느린 것이 목적이다.

그런데 이 "의도적 느림"이 DB 커넥션과 만나면 문제가 된다. BCrypt는 순수 CPU 연산이다. 네트워크도 안 타고, 디스크도 안 읽고, DB도 안 건드린다. 그냥 CPU 코어 하나를 150ms 동안 점유할 뿐이다. 그런데 @Transactional 안에 있다는 이유만으로 DB 커넥션까지 같이 점유하고 있었다.

해결: 어노테이션 한 줄 제거

// 수정 전
@Transactional(readOnly = true)
public User authenticateUser(String rawLoginId, String rawPassword) { ... }

// 수정 후
public User authenticateUser(String rawLoginId, String rawPassword) { ... }

수정은 이게 전부다. 58행의 어노테이션 한 줄을 지웠다.

검증: 왜 이게 안전한가

어노테이션을 지우면 트랜잭션이 없어진다. "DB 조회에 트랜잭션이 없어도 되는가?"라는 질문이 자연스럽게 따라온다.

검증 1: Spring Data JPA의 암묵적 트랜잭션

findByLoginId() 호출 체인을 끝까지 따라가면:

authenticateUser() — @Transactional 없음
  → UserRepository.findByLoginId() — 도메인 포트 (인터페이스)
    → UserRepositoryImpl.findByLoginId() — 어댑터 (구현체)
      → UserJpaRepository.findByLoginId() — Spring Data JPA 인터페이스
        → SimpleJpaRepository — Spring의 기본 구현

Spring Data JPA의 SimpleJpaRepository 소스를 보면:

// Spring Data JPA 소스: SimpleJpaRepository.java
@Repository
@Transactional(readOnly = true)  // ← 클래스 레벨에 이미 선언
public class SimpleJpaRepository<T, ID> implements JpaRepositoryImplementation<T, ID> {
    // findById, findAll, findByLoginId 등 모든 조회 메서드에 적용
}

호출자가 트랜잭션을 열지 않아도, Spring Data JPA가 자체적으로 readOnly 트랜잭션을 열고 닫는다. findByLoginId() 실행 중에만 커넥션을 잡고, 반환 즉시 놓아준다.

차이가 명확하다. 수정 전에는 전체 155ms 동안 커넥션을 잡았지만, 수정 후에는 5ms만 잡고 BCrypt 150ms는 커넥션 없이 실행된다.

검증 2: Entity-level DIP LazyInitializationException 없음

일반적인 JPA 프로젝트에서 @Transactional을 지우면 위험한 이유가 있다. 트랜잭션이 끝나면 영속성 컨텍스트가 닫히고, 그 후에 Lazy Loading된 연관 엔티티에 접근하면 LazyInitializationException이 터진다.

그런데 이 프로젝트는 Entity-level DIP를 적용하고 있다. JPA Entity와 도메인 객체가 분리되어 있다.

Infrastructure: UserEntity (JPA Entity)
        ↓ UserMapper.toDomain()
Domain: User (순수 POJO) ← 이것을 반환

여기서 한 가지 미세한 동작 변화가 있다. @Transactional을 제거하면 영속 상태가 달라진다.

수정 전: authenticateUser() 전체가 하나의 트랜잭션. findByLoginId()가 반환한 UserEntity는 managed(영속) 상태에서 toDomain() 호출.
수정 후: findByLoginId() 내부의 Spring Data JPA 자체 트랜잭션이 끝난 후 UserEntity는 detached(준영속) 상태에서 toDomain() 호출.

만약 UserEntity에 Lazy Loading 연관(@OneToMany(fetch = LAZY) 등)이 있고, toDomain()에서 그 연관을 접근한다면 LazyInitializationException이 발생할 수 있다. 하지만 이 프로젝트의 UserEntity는 단순 필드만 가지고 있고, toDomain()은 필드 값 복사만 수행한다. Lazy 연관이 없으므로 detached 상태에서도 안전하다. 반환되는 User 객체는 JPA와 아무 관계 없는 순수 POJO다.

검증 3: 테스트 통과

./gradlew :apps:commerce-api:test --tests "*UserService*"

BUILD SUCCESSFUL in 2m 29s

기존 테스트 전체 통과. 동작 변경이 없으므로 당연한 결과다.

일반화: @Transactional 범위에 들어오면 안 되는 것들

이번 케이스에서 배운 원칙을 일반화하면 이렇다.

트랜잭션 범위에 들어오면 안 되는 것들:

유형	예시 커넥션	낭비 시간
CPU-bound 연산	BCrypt, 압축, JSON 직렬화	~100-500ms
외부 API 호출	PG 결제, 알림 서비스, 파일 업로드	~200-5000ms
동기적 대기	Thread.sleep, 폴링 루프	~수초
대용량 메모리 처리	대용량 CSV 파싱, 이미지 리사이징	~수초

이 작업들이 트랜잭션 안에 있으면, 해당 시간 동안 커넥션이 아무것도 하지 않으면서 풀에서 빠져 있다. 커넥션 풀 크기를 아무리 늘려도, 이런 구조에서는 커넥션이 "일하는 시간"보다 "노는 시간"이 길어서 처리량이 올라가지 않는다.

수정 전후 비교

지표	수정 전	수정 후	개선
커넥션 점유 시간	~155ms	~5ms	31배 단축
커넥션 효율	3.2%	100%	-
동시 30명 인증 시 풀 점유	30/40개 (75%)	~0/40개	사실상 0%
다른 API 가용 커넥션	10개	40개	4배 확보
Little's Law 평균 점유	4.65개	0.15개	31배 감소

결론: 습관이 만든 병목

@Transactional(readOnly = true)는 "읽기 메서드에는 무조건 붙이는 것"이라고 습관적으로 생각했다. 그 습관 자체가 틀린 건 아니다. 대부분의 읽기 메서드에서는 readOnly가 최적화를 제공한다.

하지만 이 습관이 BCrypt 같은 CPU-bound 연산과 만나면 이야기가 달라진다. readOnly의 최적화 효과(스냅샷 생략, flush 생략)는 이 메서드에서 아무 의미가 없었고, 대신 커넥션을 150ms 동안 불필요하게 잡아두는 부작용만 남았다.

readOnly = true는 "커넥션을 가볍게 쓴다"가 아니라 "커넥션을 잡되, flush만 안 한다"일 뿐이다. 이 사실을 인지하는 것만으로, 코드 한 줄을 지우고 커넥션 점유를 31배 줄일 수 있었다.

어노테이션을 붙이기 전에 물어야 할 질문은 "이 메서드가 읽기인가 쓰기인가"가 아니다. "이 메서드가 커넥션을 점유하는 전체 시간 동안, DB가 실제로 일하고 있는가"가 맞는 질문이다.

SSE를 실무에 도입하면서 마주친 것들 Polling에서 SSE로, 다시 Polling으로

ioh'sDeveloper — Fri, 3 Apr 2026 21:50:31 +0900

처음에는 Polling이 싫었다

법률 번역 플랫폼을 만들 때의 일이다. 법률 문서를 업로드하면 AI가 문단별로 번역하는 시스템이었다. 원래 구조는 단순했다. 클라이언트가 5초마다 번역 상태를 폴링하고, 서버는 DB에서 현재 진행률을 읽어서 응답한다.

// 원래 구조: 5초 폴링
@GetMapping("/translation/{taskId}/status")
public TranslationStatus getStatus(@PathVariable String taskId) {
    return translationRepository.findStatus(taskId);
}

문제가 세 가지 있었다.

첫째, 5초 간격이 너무 느렸다. 번역이 문단 단위로 진행되는데, 문단 하나가 1~2초면 끝난다. 그런데 폴링이 5초라 진행률 바가 0% → 30% → 60% → 100%처럼 뚝뚝 끊겨 보였다. 사용자 입장에서 "이거 동작하고 있는 건가?"라는 불안감이 생겼다.

둘째, 번역이 끝난 뒤에도 폴링이 계속됐다. 100% 완료를 감지하기 전까지 불필요한 요청이 계속 서버에 찍혔다. 물론 완료 후 폴링을 멈추는 로직을 넣으면 되지만, 페이지를 안 닫고 놔두는 사용자가 있으면 여전히 빈 폴링이 날아온다.

셋째, 진행률의 해상도가 폴링 주기에 묶였다. 실제로는 20개 문단이 1개씩 완료되는데, 폴링 5초 사이에 3개가 완료되면 클라이언트는 중간 과정을 못 본다. 5% → 20%로 점프하는 것이다.

그래서 SSE(Server-Sent Events)를 도입했다. 서버가 번역 진행률을 실시간으로 클라이언트에 밀어주는 구조다.

SSE의 기본 구조

SSE는 HTTP 위에서 동작하는 단방향 스트리밍 프로토콜이다. 서버가 클라이언트에게 이벤트를 보내는 것만 가능하고, 클라이언트가 서버에 메시지를 보내려면 별도의 HTTP 요청을 사용해야 한다.

프로토콜 레벨에서 보면, SSE는 특별한 것이 아니다. 일반 HTTP 응답인데, Content-Type: text/event-stream이고 응답이 끝나지 않는다. 서버가 응답 바디에 데이터를 계속 추가해나가는 것이다.

HTTP/1.1 200 OK
Content-Type: text/event-stream
Cache-Control: no-cache
Connection: keep-alive

data: {"progress": 5, "paragraph": 1}\n\n
data: {"progress": 10, "paragraph": 2}\n\n
data: {"progress": 15, "paragraph": 3}\n\n

각 이벤트는 data: 접두사로 시작하고, 빈 줄(\n\n)로 구분된다. 이게 전부다. HTTP 위에서 동작하기 때문에 프록시, 로드밸런서, 방화벽을 대부분 그대로 통과한다. (대부분이라고 한 이유는 뒤에서 설명한다.)

Spring에서의 구현은 SseEmitter를 사용한다.

@GetMapping(value = "/progress/{taskId}", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
public SseEmitter streamProgress(@PathVariable String taskId) {
    // 5분 타임아웃. 번역이 5분 내에 끝나지 않으면 연결 종료.
    SseEmitter emitter = new SseEmitter(300_000L);

    // 이 emitter를 서비스에 등록 → 번역 진행 시 이벤트 전송에 사용
    progressService.register(taskId, emitter);

    // emitter 생명주기 관리
    emitter.onCompletion(() -> progressService.unregister(taskId));
    emitter.onTimeout(() -> progressService.unregister(taskId));
    emitter.onError(e -> progressService.unregister(taskId));

    return emitter;
}

// 번역 완료 콜백에서 진행률 전송
public void onParagraphTranslated(String taskId, int paragraph, int total) {
    SseEmitter emitter = emitterStore.get(taskId);
    if (emitter != null) {
        int progress = (int) ((paragraph / (double) total) * 100);
        emitter.send(SseEmitter.event()
            .name("progress")
            .data(Map.of("progress", progress, "paragraph", paragraph)));
    }
}

도입 직후에는 만족스러웠다. 진행률 바가 매끄럽게 올라갔다. 문단이 하나 번역될 때마다 즉시 반영됐다. 5초 폴링의 뚝뚝 끊기는 느낌이 사라졌다. 불필요한 폴링도 없어졌다.

그런데 운영 환경에 올리고 나서 문제가 시작됐다.

실무에서 마주친 6가지 문제

문제 1: 비동기 AI 서비스의 비순차 콜백

법률 문서 번역은 문단별로 AI 서비스에 요청을 보낸다. 20개 문단이 있으면 20개의 비동기 요청이 나간다. 문제는 응답 순서가 보장되지 않는다는 것이다.

요청 순서: 문단 1 → 문단 2 → 문단 3 → 문단 4 → 문단 5
응답 순서: 문단 1 → 문단 3 → 문단 2 → 문단 5 → 문단 4

AI 서비스 내부에서 각 문단의 번역 난이도가 다르기 때문이다. 짧은 문단은 빨리 끝나고 긴 문단은 오래 걸린다. 그런데 SSE로 이벤트를 보내는 쪽은 콜백이 오는 순서대로 보낸다. 결과적으로 클라이언트의 진행률 바가 이렇게 된다:

5% → 15% → 10% → 25% → 20% → ...

진행률이 올라갔다가 내려가는 것이다. 기술적으로는 "문단 3이 문단 2보다 먼저 완료됐다"는 정확한 정보지만, 사용자 입장에서는 버그처럼 보인다.

해결: 서버측 최대값 추적

// 서버에서 최대 진행률을 추적하여 후퇴 방지
private final ConcurrentHashMap<String, AtomicInteger> maxProgress = new ConcurrentHashMap<>();

public void onParagraphTranslated(String taskId, int paragraph, int total) {
    int progress = (int) ((paragraph / (double) total) * 100);

    // 최대 진행률보다 클 때만 이벤트 전송
    AtomicInteger max = maxProgress.computeIfAbsent(taskId, k -> new AtomicInteger(0));
    int previousMax = max.getAndUpdate(current -> Math.max(current, progress));

    if (progress > previousMax) {
        SseEmitter emitter = emitterStore.get(taskId);
        if (emitter != null) {
            emitter.send(SseEmitter.event()
                .name("progress")
                .data(Map.of("progress", progress, "paragraph", paragraph)));
        }
    }
    // progress <= previousMax 이면 이벤트를 보내지 않음 → 후퇴 방지
}

이 방법은 서버에서 처리한다. 클라이언트측 재정렬 버퍼를 둘 수도 있지만, 서버에서 "최대값보다 작은 진행률은 이벤트 자체를 보내지 않는" 방식이 더 깔끔했다. 클라이언트는 받은 진행률이 항상 단조증가한다고 가정할 수 있다.

대안으로, 완료된 문단 수 자체를 보내는 방법도 있었다. "5번 문단이 완료됐다"가 아니라 "현재까지 완료된 문단 수: 3개"를 보내면 순서 문제가 자연스럽게 해결된다. 하지만 이 경우 "어떤 문단이 완료됐는지"의 정보가 유실된다. 우리 시스템에서는 완료된 문단을 하이라이트 하는 UI가 있었기 때문에, 문단 번호를 보내되 서버에서 최대값을 추적하는 방식을 선택했다.

문제 2: 중복 메시지 경로

번역 시스템의 아키텍처가 문제였다. AI 서비스의 번역 결과를 두 가지 경로로 받고 있었다.

경로 1: AI 서비스 → HTTP 콜백 → 서버 → DB 저장 + SSE 이벤트 전송
경로 2: AI 서비스 → Kafka → Consumer → DB 저장 + SSE 이벤트 전송

HTTP 콜백은 즉시성을 위해, Kafka Consumer는 안정성(콜백 유실 시 보장)을 위해 둘 다 유지하고 있었다. 문제는 두 경로 모두 SSE 이벤트를 발행한다는 것이다. 같은 문단 완료 이벤트가 두 번 전송된다.

해결: 이벤트 ID 기반 중복 제거

// 이벤트 ID를 포함해서 SSE 전송
public void sendProgressEvent(String taskId, int paragraph, String eventId) {
    // 이미 보낸 이벤트인지 확인
    Boolean isNew = redisTemplate.opsForValue()
        .setIfAbsent("sse:sent:" + eventId, "1", Duration.ofMinutes(5));

    if (Boolean.FALSE.equals(isNew)) {
        return; // 이미 전송된 이벤트 → 무시
    }

    SseEmitter emitter = emitterStore.get(taskId);
    if (emitter != null) {
        emitter.send(SseEmitter.event()
            .id(eventId) // SSE 표준의 id 필드 — 재연결 시 Last-Event-ID로 사용됨
            .name("progress")
            .data(Map.of("paragraph", paragraph)));
    }
}

이벤트 ID는 taskId + "-" + paragraph 조합으로 생성했다. 같은 문단의 완료 이벤트는 같은 ID를 가지므로, 어떤 경로로 먼저 도착하든 한 번만 전송된다.

SSE 표준에는 id 필드가 있다. 이 필드에 이벤트 ID를 넣으면, 클라이언트가 재연결할 때 Last-Event-ID 헤더로 마지막으로 받은 이벤트 ID를 보내온다. 서버는 이 ID 이후의 이벤트만 다시 보내면 된다. 중복 제거와 재연결 복구가 하나의 메커니즘으로 해결된다.

문제 3: 트랜잭션 커밋 전 읽기 (Stale Read)

이 문제는 발견하기 어려웠다. 간헐적으로 진행률이 갱신되지 않는 현상이 있었는데, 재현이 어려웠다.

원인은 이랬다. 번역 결과 콜백이 들어오면 트랜잭션 안에서 DB에 번역 결과를 저장한다. 그리고 같은 트랜잭션 안에서 SSE 이벤트를 보내려고 DB에서 최신 진행률을 다시 읽는다. 문제는 이 시점에 트랜잭션이 아직 커밋되지 않았다는 것이다.

// 문제가 된 코드 (단순화)
@Transactional
public void handleTranslationCallback(String taskId, int paragraph, String result) {
    // 1. 번역 결과 저장 (아직 커밋 안 됨)
    translationRepository.saveParagraph(taskId, paragraph, result);

    // 2. 현재 진행률 조회 — 같은 트랜잭션이므로 자신의 변경은 보인다
    //    하지만 다른 스레드의 콜백이 저장한 건 커밋 전이라 안 보일 수 있다
    int completedCount = translationRepository.countCompleted(taskId);
    int totalCount = translationRepository.countTotal(taskId);

    // 3. SSE 이벤트 전송
    sseService.sendProgress(taskId, completedCount, totalCount);
}
// 4. 메서드 종료 후 트랜잭션 커밋

문단 2와 문단 3의 콜백이 거의 동시에 들어오면:

스레드 A: 문단 2 저장 → 완료 수 조회 (문단 3은 아직 스레드 B에서 커밋 안 됨) → 진행률 10%
스레드 B: 문단 3 저장 → 완료 수 조회 (문단 2는 아직 스레드 A에서 커밋 안 됨) → 진행률 10%

두 이벤트 모두 10%를 보낸다. 실제로는 두 문단이 완료되어 15%여야 하는데.

해결: DB를 다시 읽지 않고 이벤트 데이터를 직접 전달

@Transactional
public void handleTranslationCallback(String taskId, int paragraph, String result) {
    translationRepository.saveParagraph(taskId, paragraph, result);
    // DB를 다시 읽지 않는다. 콜백에서 받은 정보만으로 이벤트를 구성한다.
}

// @TransactionalEventListener(AFTER_COMMIT) — 커밋 후에 이벤트 전송
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void onParagraphSaved(ParagraphSavedEvent event) {
    // 커밋이 완료된 후에 진행률을 조회 → 정확한 값
    int completedCount = translationRepository.countCompleted(event.getTaskId());
    int totalCount = translationRepository.countTotal(event.getTaskId());
    sseService.sendProgress(event.getTaskId(), completedCount, totalCount);
}

@TransactionalEventListener(AFTER_COMMIT)를 사용하면, 트랜잭션이 커밋된 후에 이벤트 핸들러가 실행된다. 이 시점에서 DB를 읽으면 커밋된 최신 상태를 볼 수 있다.

다만 이것도 완벽하지는 않다. 두 트랜잭션이 거의 동시에 커밋되면, AFTER_COMMIT 핸들러가 실행되는 시점에 상대방의 커밋이 아직 완료되지 않았을 수 있다. 하지만 확률이 크게 줄고, SSE에서 약간의 진행률 지연은 치명적이지 않았다. 어차피 다음 이벤트에서 보정된다.

궁극적 해결은 DB를 아예 읽지 않는 것이다. 완료된 문단 번호만 이벤트로 보내고, 클라이언트가 로컬에서 완료 수를 추적하게 한다. 서버는 "문단 N 완료"라는 사실(fact)만 전달하고, 진행률 계산은 클라이언트의 책임으로 둔다.

문제 4: 로드밸런서의 유휴 연결 종료

운영 환경에서 가장 당혹스러웠던 문제다. 로컬에서는 완벽하게 동작하는데, 스테이징 환경에 올리면 SSE 연결이 가끔 죽었다.

원인은 AWS ALB(Application Load Balancer)였다. ALB는 기본적으로 60초 동안 데이터가 오가지 않는 유휴(idle) 연결을 종료한다. SSE 연결에서 60초 동안 보낼 이벤트가 없으면, ALB가 "이 연결은 죽었다"고 판단하고 끊어버린다.

문제의 심각성은, 클라이언트가 연결 종료를 감지하지 못할 수 있다는 것이다. ALB가 TCP RST를 보내지 않고 조용히 연결을 drop하면, 클라이언트의 EventSource 객체는 연결이 살아있다고 생각한다. 새 이벤트가 와야 "연결이 끊겼다"는 걸 알 수 있는데, 이벤트가 안 오니까 알 수가 없다.

해결: 하트비트

// 30초마다 하트비트 전송
@Scheduled(fixedRate = 30_000)
public void sendHeartbeats() {
    emitterStore.forEach((taskId, emitter) -> {
        try {
            // SSE 주석(comment) 형식 — 클라이언트에서 이벤트로 처리되지 않음
            emitter.send(SseEmitter.event().comment("heartbeat"));
        } catch (IOException e) {
            // 전송 실패 → 연결이 이미 끊김 → 정리
            emitterStore.remove(taskId);
        }
    });
}

SSE 표준에는 주석(comment) 형식이 있다. : 으로 시작하는 줄은 클라이언트에서 무시된다. emitter.send(SseEmitter.event().comment("heartbeat"))는 : heartbeat\n\n를 보내는데, 이것은 데이터가 아니라 주석이므로 클라이언트의 onmessage 핸들러를 트리거하지 않는다. 하지만 네트워크상으로는 데이터가 오간 것이므로 ALB의 유휴 타이머가 리셋된다.

30초 간격을 선택한 이유: ALB 기본 유휴 타임아웃이 60초이므로, 30초마다 하트비트를 보내면 타임아웃에 걸리지 않는다. 15초는 불필요하게 잦고, 45초는 네트워크 지연을 고려하면 위험하다.

ALB의 유휴 타임아웃을 늘리는 것도 방법이다. AWS 콘솔에서 최대 4000초까지 설정할 수 있다. 하지만 이건 ALB 전체에 적용되므로, SSE가 아닌 일반 HTTP 요청에서 느린 클라이언트가 커넥션을 오래 잡아먹는 부작용이 생길 수 있다. 하트비트가 더 정밀한 해법이다.

문제 5: 클라이언트 종료 시 연결 누수

Spring의 SseEmitter는 생명주기 관리가 수동이다. 클라이언트가 정상적으로 연결을 종료하면 onCompletion 콜백이 호출되지만, 브라우저를 갑자기 닫거나 네트워크가 끊기면 어떻게 될까?

SseEmitter emitter = new SseEmitter(300_000L);

// 이 세 가지 콜백을 모두 등록해야 한다
emitter.onCompletion(() -> {
    log.info("SSE 연결 정상 종료: {}", taskId);
    cleanup(taskId);
});

emitter.onTimeout(() -> {
    log.warn("SSE 연결 타임아웃: {}", taskId);
    cleanup(taskId);
});

emitter.onError(e -> {
    log.error("SSE 연결 오류: {}", taskId, e);
    cleanup(taskId);
});

onCompletion, onTimeout, onError — 세 개 다 등록해야 안전하다. 하나라도 빠지면 특정 종료 경로에서 emitter가 정리되지 않는다.

하지만 이것만으로는 부족하다. 클라이언트가 TCP 연결을 깨끗하게 닫지 않으면(브라우저 강제 종료, 네트워크 단절), 서버는 연결이 끊긴 것을 즉시 알 수 없다. TCP keepalive 프로브가 실패할 때까지 기다려야 한다. 기본 TCP keepalive 시간은 OS에 따라 다르지만, 대부분 수십 초에서 수 분이다.

그 동안 emitter는 메모리에 남아있고, 하트비트 전송을 시도할 때마다 IOException이 발생한다. IOException이 발생하면 onError가 호출되면서 정리된다. 결과적으로 하트비트가 "연결 상태 감지" 역할도 겸한다.

// 하트비트가 연결 감지 + ALB 유지 두 가지 역할을 한다
emitterStore.forEach((taskId, emitter) -> {
    try {
        emitter.send(SseEmitter.event().comment("heartbeat"));
        // 전송 성공 → 연결 살아있음 → ALB 타이머 리셋
    } catch (IOException e) {
        // 전송 실패 → 연결 끊김 → 정리
        emitterStore.remove(taskId);
        // onError 콜백도 트리거됨
    }
});

실제 운영에서 측정해보니, 하트비트 없이는 브라우저 종료 후 emitter가 최대 5분(SseEmitter 타임아웃 설정)까지 메모리에 남아 있었다. 하트비트를 30초마다 보내면 최대 30초 후에 감지되어 정리된다.

문제 6: 동시 연결 수의 확장성 한계

법률 번역 시스템에서 SSE는 잘 동작했다. 동시 번역 세션이 최대 50개 정도였기 때문이다. 50개의 SseEmitter는 JVM 힙에서 무시할 수 있는 수준이다.

하지만 대기열 시스템을 설계할 때, 같은 접근을 적용하려고 하니 숫자가 달라졌다.

법률 번역 시스템:
- 동시 번역 세션: ~50개
- SseEmitter 수: ~50개
- 메모리: 무시 가능
- 연결 수명: 번역 완료까지 (1~5분)

대기열 시스템:
- 동시 대기 사용자: 최대 10,000명
- SseEmitter 수: 최대 10,000개
- 메모리: 무시할 수 없음
- 연결 수명: 대기 완료까지 (수 분 ~ 수십 분)

SseEmitter 하나가 차지하는 리소스:

HTTP 연결: 톰캣의 NIO 커넥터에서 소켓 하나를 점유한다. 기본 maxConnections는 8192다.
응답 버퍼: 각 emitter는 응답을 쓰기 위한 버퍼를 유지한다.
타임아웃 스케줄러: 각 emitter에 대해 타임아웃 타이머가 등록된다.
emitterStore 엔트리: ConcurrentHashMap의 엔트리.

하나하나는 작지만, 10,000개가 되면 다르다. 특히 HTTP 연결 수가 문제다. 톰캣의 maxConnections 8192개 중 10,000개를 SSE가 잡아먹으면, 일반 API 요청을 처리할 연결이 없다.

물론 maxConnections를 늘릴 수 있다. 하지만 연결 수가 늘어나면 OS의 파일 디스크립터 한도, 메모리, context switching 오버헤드 등 다른 병목이 따라온다.

대기열에서 SSE를 쓰면:
- 10,000 대기 사용자 → 10,000 SSE 연결
- 각 연결에서 30초마다 하트비트 → 초당 ~333 하트비트 이벤트
- 순번 변경 이벤트: 배치(30개)마다 → 초당 ~30 이벤트
- 총 이벤트: 초당 ~363개 → 관리 가능하지만...
- 문제는 이벤트가 아니라 연결 자체다

대기열에서 폴링을 쓰면:
- 10,000 대기 사용자 × 동적 폴링 (3~10초)
- 초당 요청: 1,000 ~ 3,333 QPS
- 각 요청은 즉시 응답 후 연결 반환
- 동시 연결 수: 응답 시간이 50ms라면 → 50~167개

숫자가 말해준다. 폴링은 동시 연결 수가 QPS × 응답시간으로 결정된다. SSE는 동시 연결 수가 접속 사용자 수로 결정된다. 대기열에서는 접속 사용자 수가 통제 불가능한 변수다.

SSE vs WebSocket vs Polling: 아키텍처 레벨 비교

세 기술을 표면적 기능이 아니라 아키텍처 특성으로 비교한다.

연결 모델

차원	Polling	SSE	WebSocket
연결 모델	요청-응답 (무상태)	지속 연결 (서버→클라이언트)	지속 연결 (양방향)
프로토콜	HTTP	HTTP (text/event-stream)	WS (HTTP에서 업그레이드)
서버 메모리	요청 간 없음	SseEmitter / 연결당	WebSocketSession / 연결당
로드밸런서	표준 HTTP 라우팅	Sticky Session 또는 Connection Affinity 필요	WS 인지 프록시 필요
자동 재연결	클라이언트 제어	EventSource API 내장	직접 구현 필요
바이너리 데이터	지원 (any content-type)	미지원 (텍스트 전용)	지원 (binary frame)
확장 병목	요청 빈도 (QPS)	동시 연결 수	동시 연결 수
Spring 지원	표준 @GetMapping	SseEmitter (수동 생명주기)	@MessageMapping (STOMP)

비용 모델의 차이 핵심

이 비교에서 가장 중요한 행은 "확장 병목"이다.

Polling의 비용 = f(요청 빈도)

폴링 간격을 조절하면 비용을 제어할 수 있다. 대기열 시스템에서 동적 폴링을 구현한 것이 이 특성을 활용한 것이다. 대기 순번이 멀면 10초 간격, 가까우면 3초 간격으로 줄인다. 비용이 서버 운영자의 통제 하에 있다.

// 동적 폴링 간격 — 서버가 클라이언트에게 다음 폴링 시간을 지시
public QueueStatusResponse getQueueStatus(String userId) {
    Long rank = getQueueRank(userId);
    int pollInterval;
    if (rank > 500) {
        pollInterval = 10; // 멀리 있으면 10초
    } else if (rank > 100) {
        pollInterval = 5;  // 중간이면 5초
    } else {
        pollInterval = 3;  // 가까우면 3초
    }
    return new QueueStatusResponse(rank, pollInterval);
}

SSE/WebSocket의 비용 = f(동시 연결 수)

동시 연결 수는 제어할 수 없다. 대기열에 10,000명이 있으면 10,000개의 연결이 열린다. 대기열 크기를 제한할 수는 있지만, 그건 비즈니스 제약이지 인프라 최적화가 아니다.

시나리오: 인기 상품 오픈, 50,000명 동시 대기

Polling:
- 동적 간격 적용 (평균 7초)
- QPS = 50,000 / 7 ≈ 7,143
- 응답 시간 50ms → 동시 연결 ≈ 357개
- 톰캣 기본 설정으로 처리 가능

SSE:
- 동시 연결 = 50,000개
- 톰캣 maxConnections 기본값(8192) 초과
- 일반 API 요청 처리 불가
- NIO를 써도 OS 파일 디스크립터 한도 이슈

재연결 동작의 차이

SSE의 EventSource API는 자동 재연결을 내장하고 있다. 연결이 끊기면 브라우저가 자동으로 재연결을 시도한다. 서버는 retry: 필드로 재연결 간격을 지정할 수 있다.

retry: 3000\n
data: {"progress": 50}\n\n

이 경우 연결이 끊기면 3초 후 자동 재연결한다. 재연결 시 Last-Event-ID 헤더로 마지막 이벤트 ID를 보내므로, 서버는 누락된 이벤트만 다시 보낼 수 있다.

WebSocket은 자동 재연결이 없다. 연결이 끊기면 클라이언트 코드에서 재연결 로직을 직접 구현해야 한다. exponential backoff, 재연결 횟수 제한, 상태 복구 등을 모두 직접 처리해야 한다.

Polling은 재연결이라는 개념 자체가 없다. 매 요청이 독립적이므로, 이전 요청이 실패해도 다음 요청은 정상 동작한다. 가장 단순하고 견고하다.

시나리오별 기술 선택

실무 경험과 위의 분석을 종합한 기술 선택 가이드다.

시나리오	추천	이유
번역/변환 진행률 (소규모)	SSE	동시 연결 수 제한적, 서버→클라이언트 단방향, 자동 재연결
대기열 순번 (대규모)	Polling (동적 간격)	동시 사용자 수 통제 불가, 연결 비용이 선형 증가하면 위험
채팅	WebSocket	양방향 통신 필수
주식 시세	WebSocket 또는 SSE	빈도에 따라. 초당 수십 건이면 WebSocket, 수 건이면 SSE
알림 벨	SSE	서버→클라이언트 단방향, 클라이언트 메시지 불필요
파일 업로드 진행률	불필요	XMLHttpRequest/fetch의 progress 이벤트 사용
대시보드 실시간 갱신	SSE 또는 Polling	접속 사용자 수에 따라 결정

판단 기준 체크리스트

Q1. 클라이언트에서 서버로 메시지를 보내야 하는가?
  ├─ Yes → WebSocket
  └─ No → Q2

Q2. 동시 접속 사용자 수가 예측 가능하고 제한적인가?
  ├─ Yes (수백 이하) → SSE
  └─ No (수천~수만, 또는 예측 불가) → Q3

Q3. 실시간성이 얼마나 중요한가?
  ├─ 1초 이하 지연 필요 → SSE (연결 수 관리 가능한 아키텍처 필요)
  └─ 수 초 지연 허용 → Polling (동적 간격)

두 시스템의 아키텍처 비교

법률 번역 시스템 (SSE)

동시 연결: ~50개 (활성 번역 세션 수)
연결 수명: 1~5분 (번역 완료까지)
이벤트 빈도: 문단당 1개, 문서당 10~30개
적합 이유: 연결 수가 적고 예측 가능, 실시간 피드백이 UX에 직접 영향

대기열 시스템 (Polling)

동시 연결: 요청 시점에만 (응답 후 해제)
QPS: 사용자 수 / 평균 폴링 간격
이벤트 빈도: 해당 없음 (클라이언트가 pull)
적합 이유: 동시 사용자 수가 통제 불가, 연결 비용을 폴링 간격으로 제어 가능

SSE 문제 해결 요약표

법률 번역 시스템에서 겪은 6가지 문제와 해결책을 정리한다.

문제	원인	증상	해결	비용
비순차 콜백	AI 서비스의 비동기 응답 순서 미보장	진행률이 후퇴	서버측 최대값 추적 (AtomicInteger)	메모리: taskId당 int 1개
중복 메시지	콜백 + Kafka 두 경로에서 동일 이벤트 발행	같은 이벤트 2번 수신	이벤트 ID 기반 중복 제거 (Redis SET NX)	Redis 키: 이벤트당 1개 (5분 TTL)
트랜잭션 커밋 전 읽기	SSE 이벤트 시점에 트랜잭션 미커밋	진행률 갱신 누락	@TransactionalEventListener(AFTER_COMMIT)	이벤트 지연: 커밋 후 처리
ALB 유휴 연결 종료	ALB 60초 idle timeout	SSE 연결 무통보 종료	30초 하트비트 (SSE comment)	네트워크: 30초마다 수십 바이트
클라이언트 종료 시 누수	SseEmitter 수동 생명주기 관리	메모리 누수	onCompletion/onTimeout/onError 3중 등록 + 하트비트 감지	코드 복잡도 증가
동시 연결 수 확장성	사용자 수 = 연결 수	톰캣 maxConnections 초과	대기열에서는 Polling 선택	설계 변경

운영에서 배운 원칙들

1. SSE는 "더 나은 Polling"이 아니다 — 다른 비용 모델이다

이것이 가장 중요한 교훈이다. SSE를 처음 도입할 때 나는 "Polling의 상위호환"이라고 생각했다. 실시간이니까 당연히 더 좋은 거 아닌가? 아니다.

Polling의 비용은 요청 빈도에 비례한다. 빈도는 제어 가능하다.
SSE의 비용은 동시 연결 수에 비례한다. 동시 연결 수는 대부분의 경우 제어 불가능하다.

"제어 가능한 비용"과 "제어 불가능한 비용" 사이의 선택이다. 동시 연결 수가 작고 예측 가능하면 SSE가 낫다. 동시 연결 수가 크거나 예측 불가능하면 Polling이 안전하다.

2. SseEmitter의 생명주기는 발로 짠 것처럼 느껴진다

Spring의 SseEmitter는 생성, 등록, 이벤트 전송, 타임아웃, 에러, 완료의 모든 단계를 개발자가 수동으로 관리해야 한다. 자동으로 해주는 것이 거의 없다. onCompletion을 안 걸면 완료 시 정리가 안 되고, onTimeout을 안 걸면 타임아웃 시 정리가 안 되고, onError를 안 걸면 에러 시 정리가 안 된다.

WebFlux의 Flux<ServerSentEvent>를 쓰면 이 문제가 상당히 개선된다. 리액티브 스트림의 구독 취소가 자동으로 정리를 처리하기 때문이다. 하지만 WebFlux를 도입하는 것은 SseEmitter의 불편함을 해결하기 위한 것 치고는 너무 큰 변경이다.

3. 로드밸런서는 HTTP가 짧게 끝난다고 가정한다

HTTP는 "요청 → 응답 → 끝"의 프로토콜이다. 대부분의 인프라(로드밸런서, 프록시, CDN, 방화벽)가 이 가정 위에 설계되어 있다. SSE는 이 가정을 깨뜨린다. 응답이 끝나지 않으니까.

그래서 SSE를 운영 환경에 도입하면, "로드밸런서 유휴 타임아웃", "프록시 버퍼링", "CDN 캐싱" 등 평소에 신경 쓸 필요 없던 인프라 설정을 하나하나 확인해야 한다. nginx의 기본 설정으로는 SSE가 동작하지 않는다(proxy_buffering off를 설정해야 한다). CloudFront 같은 CDN은 SSE를 아예 지원하지 않을 수 있다.

이런 인프라 호환성 이슈는 개발 환경에서는 발견되지 않고 스테이징이나 운영에서만 나타난다. 로컬에서는 로드밸런서가 없으니까.

4. 동시 연결 수가 바운디드(bounded)이고 작으면 SSE가 아름답게 동작한다

법률 번역 시스템이 그랬다. 동시 번역 세션이 50개 이하로 제한되어 있었고, 각 세션이 1~5분이면 끝났다. 이런 환경에서 SSE는:

실시간 진행률 업데이트로 UX를 크게 개선했다
불필요한 폴링 트래픽을 제거했다
EventSource의 자동 재연결로 안정성도 확보했다

"바운디드이고 작다"는 조건이 핵심이다. 이 조건이 충족되면 SSE의 모든 장점을 누리면서 단점은 최소화할 수 있다.

5. 동시 연결이 사용자 수에 따라 선형 증가하면 Polling이 맞다

대기열 시스템이 그렇다. 대기 사용자가 100명일 수도, 50,000명일 수도 있다. 이런 상황에서 동시 연결 수가 사용자 수와 1:1로 묶이는 SSE/WebSocket은 위험하다.

Polling에 동적 간격을 적용하면, 비용을 서버 운영자가 제어할 수 있다. "QPS가 너무 높으면 간격을 늘린다"는 단순한 전략으로 인프라를 보호할 수 있다. SSE에서는 이런 제어 수단이 없다. 연결은 사용자가 열고, 사용자가 닫는다.

원칙으로 돌아오면

기술 선택의 기준은 "어떤 것이 더 좋은가"가 아니라 "어떤 비용 모델이 이 시스템에 맞는가"다.

Polling은 요청 빈도를 비용의 축으로 삼는다. SSE와 WebSocket은 동시 연결 수를 비용의 축으로 삼는다. 두 축 중 어떤 것이 제어 가능한지가 기술 선택을 결정한다.

법률 번역 시스템에서는 동시 연결 수가 제어 가능했다 (바운디드, 소규모). 그래서 SSE가 적합했다.
대기열 시스템에서는 동시 사용자 수가 제어 불가능했다 (언바운디드, 대규모). 그래서 Polling이 적합했다.

"Polling에서 SSE로 갔다가 다시 Polling으로 돌아왔다"는 이야기가 퇴보처럼 들릴 수 있다. 하지만 같은 Polling이 아니다. SSE의 문제를 직접 겪어봤기 때문에, 대기열에서 Polling을 선택한 것은 무지가 아니라 판단이다. "왜 SSE를 안 쓰셨어요?"라는 질문에 30초 안에 명확하게 대답할 수 있다. 그게 기술 선택의 깊이다.

가장 경계해야 할 것은 "새로운 기술은 항상 더 낫다"는 가정이다. Polling은 낡은 기술이 아니라, 특정 비용 모델에 최적화된 패턴이다. SSE는 새로운 기술이 아니라, 다른 비용 모델에 최적화된 프로토콜이다. 각자의 자리가 있다.