지인 추천으로 들어갔다. 패X 재직자 부트캠프도 들어봤던 4년차 개발자가 왜 또 부트캠프냐는 질문을 몇 번 받았는데, 다 듣고 난 지금은 짧게 답할 수 있다. 1도 후회하지 않는다.

리뷰를 쓰려니 한 가지가 걸렸다. 루퍼스 후기를 찾아본 사람이라면 알겠지만 칭찬이 많다. 나도 처음엔 좀 의심했다. 그래서 이 글은 감상보다 기록에 가깝게, 주차별로 내 코드와 생각이 어떻게 바뀌었는지 남기려고 한다.

왜 루퍼스였고, 뭐가 얼마나 달랐나

“다른 부트캠프랑 뭐가 다르냐”를 가장 많이 들었다. 10주 내내 느낀 걸 네 가지로 추리면 이렇다.

첫째, 과제 스케일이 실무급이다. 문법 예제가 아니라 10만 건 상품 조회, 10만 명 동시 주문, 일간·주간·월간으로 쪼개진 랭킹을 실제로 만든다. “예제라서 10만이지 진짜는 달라요”가 아니라, 예제 자체를 현실 규모로 깐다. 회사로 돌아가서 비슷한 문제를 만났을 때 “그거 해봤다”가 된다.

둘째, “정상 동작”이 아니라 “장애에서도 돈이 맞는” 코드를 목표로 한다. PG가 터질 때, Redis가 흔들릴 때, 동시성 경합이 터질 때 — 커리큘럼이 이 지점을 피하지 않는다. Circuit Breaker를 교재로 읽는 것과, 실제로 장애를 복구해보며 쓴 Circuit Breaker는 다르다.

셋째, 답이 아니라 질문이 돌아오는 멘토링이다. 내 코드를 들고 가면 “이 선택의 반대편엔 뭘 포기한 거죠?” 같은 질문이 돌아온다. 처음엔 답답하다. 그런데 이 형식에 익숙해지면 코드 짜기 전에 스스로 그 질문을 하게 된다. 회사로 돌아가서 이게 가장 오래 간다.

넷째, 10주 뒤에 “글”이 남는다. 주차마다 정리글을 쓰게 되는 구조라, 10주 후엔 10개의 케이스 스터디가 손에 남는다. 이력서에 “Redis ZSET + Spring Batch 랭킹 시스템 설계” 한 줄이 아니라, 왜 그렇게 설계했는지 직접 쓴 글이 같이 있다.

3기 동기의 약 96%가 끝까지 남았다. 중간에 그만두기 어려운 구조라서가 아니다. 뒷 주차가 앞 주차 위에 쌓여서, 7주차에 배운 이벤트 아키텍처가 8~10주차의 뼈대가 된다. 한 주를 버리면 다음 주가 없다는 감각이 자연스럽게 생긴다.

수강 전과 수강 후, 내 머릿속이 바뀐 자리들

트랜잭션 경계: “묶는 게 안전”에서 “나누는 게 안전”으로

수강 전의 나는 주문 취소 로직을 한 트랜잭션에 다 묶어 놓고 있었다. 재고 복구, 쿠폰 복원, PG 환불까지. 그래야 안전하다고 생각했다.

문제는 PG가 5초 타임아웃을 내는 순간이었다. 재고와 쿠폰 복구까지 같이 롤백된다. 외부 시스템 하나가 내 비즈니스 로직 전체를 인질로 잡는 구조였다.

수강 후에는 코드를 짜기 전에 먼저 나눈다. 실패해도 되는 것과, 반드시 같이 성공해야 하는 것을.

@EventListener
public void handle(OrderCancelledEvent event) {
    restoreStock(event);
    restoreCoupon(event);
}

@TransactionalEventListener(phase = AFTER_COMMIT)
public void handle(OrderCancelledEvent event) {
    refundPaymentUseCase.refundPayment(event.orderId());
}

이렇게 나누고 나니 PG가 10초간 먹통이어도 주문 취소는 정상적으로 끝난다. 재고와 쿠폰은 정확히 돌아오고, 환불은 나중에 재시도하면 된다. 자세한 과정은 7주차 글에 적어뒀다.

성능 개선에도 순서가 있다

조회가 느리다는 얘기를 들으면 나는 늘 캐시부터 떠올렸다. 그게 제일 빠른 카드인 줄 알았다.

5주차 과제에서 10만 건 상품 데이터를 실제로 만져보며 생각이 바뀌었다. 길부터 닦고, 짐을 줄이고, 그 다음에 지름길을 뚫는다. 먼저 인덱스, 쿼리 플랜부터 본다. 그 다음이 비정규화, 정말 매 요청마다 조인이 필요한지 다시 본다. 캐시는 마지막이다.

지금은 캐시를 꺼내기 전에 먼저 의심부터 한다. 자세한 수치는 5주차 글에 있다.

“실시간으로 할 수 있다”와 “실시간으로 해야 한다”는 다르다

9주차에 Redis ZSET으로 일간 랭킹을 만들었다. 10주차에 주간, 월간 랭킹이 과제로 나왔을 때 처음 든 생각은 단순했다. ZUNIONSTORE로 7일치, 30일치 합치면 되는 거 아닌가.

하지만 “이번 주 인기 상품”에 3초 전 좋아요가 반영되지 않아도 아무도 모른다. 경영진 리포트에 초 단위 실시간성이 필요한 경우는 드물다. 일간은 Redis 실시간으로, 주간·월간은 Spring Batch와 Materialized View로 분리하면서 배운 가장 큰 감각이 이거였다.

이 주차가 수강 전과 수강 후를 가장 크게 가른 지점이라, 다음 섹션에서 따로 적는다.

가장 인상 깊었던 프로젝트 — 랭킹 시스템 설계 (9~10주차)

여러 주차가 좋았지만 9~10주차의 랭킹 시스템 설계를 꼽고 싶다. 이유는 세 가지다.

첫째, 과제가 “기능 구현”이 아니라 “설계 판단”이었다. 랭킹의 본질은 정렬이 아니라 “어떤 시간 범위의 이벤트를 어떤 가중치로 합산할 것인가”라는 정책이었다. 같은 도메인인데 일간과 주간·월간의 요구사항이 다르다는 걸, 실제로 구현하면서 체감했다.

둘째, 한 번 잘못된 인터페이스를 잡았다가 되돌리는 경험을 했다. 처음엔 “랭킹”이라는 이름 하나로 모든 걸 풀려고 했는데, 실시간 로직과 배치 로직이 같이 들어가면서 인터페이스가 뚱뚱해졌다. ISP(Interface Segregation Principle)를 교과서가 아니라 내 손으로 확인한 순간이었다.

셋째, 우아한형제들 기술블로그의 한 문장이 과제 한복판에서 떠올랐다. “실시간으로 처리할 수 있다고 해서 실시간으로 처리해야 하는 것은 아니다.” 이 문장을 이해하는 것과, 이 문장대로 코드를 짜고 시스템을 분리하는 건 완전히 다른 일이었다. 루퍼스는 이 간극을 직접 좁혀보게 해줬다.

4기를 고민 중이시라면, 이런 “기술을 쓸지 말지 판단하는 훈련”을 한다는 점에서 추천하고 싶다. 전체 과정은 9주차와 10주차 글에 있다.

강의와 멘토링에서 좋았던 점

솔직히 커리큘럼 그 자체보다 멘토링 시간이 더 컸다.

멘토님들이 여러 관점에서 적극적으로 질문을 던져주시는데, 그때마다 놀랐다. 내가 이만큼 생각할 때 누군가는 완전히 다른 시야에서 이런 질문을 할 수 있구나. 답을 얻은 것보다 질문을 받아본 경험 자체가 더 오래 남는다.

그러고 나니 코드를 짤 때 두 가지가 자동으로 돌아가기 시작했다. 하나는 “이 선택의 반대편엔 뭘 포기한 거지”라는 trade-off. 다른 하나는 “이 비즈니스가 뭘 원하는지”부터 다시 보는 도메인 감각. 위에 적은 Before/After 세 가지도 실은 이 두 습관의 결과물이다.

강의는 강의대로 좋았다. 6주차 PG 장애 복구, 8주차 선착순 주문 10만 명 — 이런 주제를 교재 수준이 아니라 진짜 장애 상황에서 돈이 맞는 코드를 목표로 다룬다. 6주차와 8주차 글에 기록해뒀다.

그래도 단점은 있다

후기 글에 단점이 없으면 광고가 되어버리니까, 몇 가지 적어둔다.

회사가 바쁠 때는 잠을 줄여야 한다. 업무 바쁜 주와 과제 마감이 겹치면 수면 시간이 연료가 된다. 재직자로 들어오시는 분은 이 각오가 필요하다.

멘토링 시간이 겹치면 다른 멘토님 세션을 놓친다. 멘토마다 보는 시야가 다른데, 내 시간대와 겹친 분의 관점은 그대로 못 챙기게 된다. 이 부분이 개인적으로 제일 아쉬웠다.

그래도 남는다. 위에 적은 Before/After 세 가지와 질문하는 습관이 내 것으로 남았으니까.

마지막으로

AI로 코드를 생성하는 시대라고 개발자 사이의 간격이 좁혀지진 않는다. AI는 답은 잘 하지만 질문은 잘 하지 못한다. 어느 트랜잭션 경계에서 끊을지, 언제 실시간을 포기할지, 어느 순서로 성능을 풀지 — 결국 질문은 사람의 몫이다.

루퍼스 10주는 그 질문을 조금 더 정확히 던질 수 있게 된 시간이었다. 시작할 때 있던 동기 중 약 96%가 끝까지 남았다. 그 이유가 이 글 어딘가에 있었으면 좋겠다.

3기 여러분 고생하셨고, 4기를 고민 중이신 분들께 이 글이 참고가 되었으면 한다.

— 던킨

#루퍼스부트캠프 #루퍼스 #루프팩 #백엔드 #LOOPPAK #루프팩백엔드3기

TL;DR: 일간 랭킹은 Redis ZSET으로, 주간/월간 랭킹은 Spring Batch + Materialized View로 풀었다. “랭킹”이라는 같은 도메인인데 왜 인프라를 나눴는지, 그 과정에서 인터페이스를 한 번 잘못 설계했다가 되돌린 이야기를 정리했다.

1. 시작은 단순한 질문이었다

9주차에 Redis ZSET 기반 실시간 일간 랭킹을 만들었다. Kafka Consumer가 좋아요/주문 이벤트를 받아 ZINCRBY로 점수를 갱신하고, API에서 ZREVRANGE로 조회하는 구조다.

잘 돌아갔다. 그런데 10주차 과제가 떨어졌다.

“주간, 월간 랭킹도 만들어보세요.”

처음 든 생각은 단순했다. “일간을 7개 합치면 주간이고, 30개 합치면 월간 아닌가?”

Redis의 ZUNIONSTORE로 7일치 키를 합산하면 될 것 같았다. 그런데 이 생각이 틀렸다는 걸 금방 깨달았다.

2. 왜 Redis로 주간/월간을 풀면 안 되는가

ZUNIONSTORE의 시간복잡도는 O(N) + O(M log M)이다. N은 입력 키들의 총 원소 수, M은 결과 집합의 크기다. 상품이 10만 건이고 7일치를 합산하면 N은 최대 70만이다.

하지만 진짜 문제는 성능이 아니었다.

주간/월간 랭킹은 실시간일 필요가 없다. 사용자가 “이번 주 인기 상품”을 볼 때, 3초 전에 발생한 좋아요가 반영되지 않아도 아무도 모른다. 경영진이 보는 주간 리포트에 수 초 단위의 실시간성이 필요한 경우는 거의 없다.

이 시점에서 우아한형제들 기술블로그의 배치 경험기에서 읽었던 문장이 떠올랐다.

“실시간으로 처리할 수 있다고 해서 실시간으로 처리해야 하는 것은 아니다.”

정확히 이 상황이었다. 실시간으로 풀 수는 있지만, 풀 필요가 없다. 오히려 매 요청마다 7일치를 합산하면 Redis에 불필요한 부하를 주는 셈이다.

그래서 결론을 내렸다. 일간은 Redis, 주간/월간은 배치로 분리한다.

3. Materialized View라는 선택

주간/월간 랭킹은 “미리 계산해둔 조회 전용 테이블”에 넣기로 했다. MySQL에는 PostgreSQL 같은 네이티브 MV 기능이 없으므로, 별도 테이블 + 배치 적재 방식을 사용한다.

-- 주간 랭킹 MV
mv_product_rank_weekly (
  product_id, year_week, 
  like_count, order_count, view_count, 
  score, ranking,  -- 순위를 미리 계산해서 저장
  updated_at
)

-- 월간 랭킹 MV
mv_product_rank_monthly (
  product_id, year_month, 
  like_count, order_count, view_count, 
  score, ranking,
  updated_at
)

여기서 한 가지 고민이 있었다. ranking(순위)을 테이블에 저장할 것인가, 조회할 때 계산할 것인가?

조회 시 ORDER BY score DESC로 정렬해서 순위를 매기는 것도 방법이다. 하지만 MV의 본질은 “복잡한 집계를 미리 계산해두는 것”이다. 조회할 때마다 정렬하면 MV의 의미가 반감된다. 배치에서 TOP 100만 뽑으면서 순위를 미리 매겨두면, 조회는 WHERE year_week = ? ORDER BY ranking ASC로 인덱스 스캔만 하면 끝이다.

4. Spring Batch Job 설계 — Chunk가 맞는 이유

배치 처리 모델을 정할 때 세 가지 선택지가 있었다.

선택지 A: Tasklet에서 Native Query 한 방

// Tasklet 안에서 SQL 한 줄로 끝내기
@Override
public RepeatStatus execute(...) {
    jdbcTemplate.update("""
        INSERT INTO mv_product_rank_weekly (...)
        SELECT product_id, ..., RANK() OVER (ORDER BY score DESC)
        FROM product_metrics
        LIMIT 100
    """);
    return RepeatStatus.FINISHED;
}

단순하고 빠르다. 하지만 상품이 100만 건이 되면? SQL 한 방에 100만 건을 정렬하고, 트랜잭션 하나에 묶이고, 실패하면 전체 롤백이다.

선택지 B: Chunk-Oriented Processing

Reader(product_metrics에서 score순 읽기)
  → Processor(순위 부여 + MV 엔티티 변환)
    → Writer(MV 테이블 저장)

청크 단위로 트랜잭션이 관리되고, 실패 시 해당 청크만 재시도할 수 있다. Spring Batch의 StepExecution으로 읽은 건수, 쓴 건수를 자동 추적한다.

선택지 C: Tasklet 안에서 Chunk를 수동 구현

// Tasklet 안에서 직접 페이징하며 처리
int offset = 0;
while (offset < total) {
    List<Metrics> chunk = repository.findAll(PageRequest.of(offset, 1000));
    // 직접 처리...
    offset += 1000;
}

자유도는 높지만, Batch 프레임워크의 재시작/모니터링 메커니즘을 전부 포기하게 된다.

우아한형제들의 Spring Batch와 Querydsl 글에서 대규모 데이터 처리 시 JpaPagingItemReader의 한계와 최적화 방법을 참고했다. 현재 규모에서는 표준 JpaPagingItemReader로 충분하지만, 데이터가 커지면 offset 없는 커서 기반 Reader로 전환이 필요하다는 점을 인지하고 있다.

최종적으로 B를 선택했다. 이유는 두 가지다.

1. TOP 100만 읽으면 되므로 maxItemCount(100)과 pageSize(100)을 맞추면 DB에서 딱 100건만 가져온다. A의 “SQL 한 방”과 성능 차이가 없으면서, 프레임워크의 이점(모니터링, 재시작)을 그대로 쓸 수 있다.
2. 이번 과제의 학습 목표 자체가 “Chunk-Oriented Processing”이다. 실무에서도 이 패턴을 알아야 한다.

그리고 Job 구조는 두 단계로 나눴다.

Step 1: Cleanup Tasklet  → 해당 주차/월의 기존 데이터 삭제
Step 2: Aggregate Chunk  → Reader → Processor → Writer

Cleanup은 단발성 DELETE 쿼리 하나이므로 Tasklet이 적합하고, 집계는 Chunk가 적합하다. 하나의 Job 안에서 각 Step의 성격에 맞는 처리 모델을 혼합한 것이다.

5. 인터페이스를 한 번 잘못 설계했다

API에서 주간/월간 랭킹을 제공하려면, 기존 RankingRepository에 주간/월간 메서드를 추가해야 했다.

처음에는 단순하게 기존 인터페이스를 확장했다.

// 처음 시도: 기존 인터페이스에 추가
public interface RankingRepository {
    // 기존 (일간, Redis)
    List<RankedProduct> getTopRankings(LocalDate date, int offset, int size);
    long getTotalCount(LocalDate date);
    
    // 추가 (주간/월간, JPA)
    List<RankedProduct> getWeeklyRankings(LocalDate date, int offset, int size);
    List<RankedProduct> getMonthlyRankings(LocalDate date, int offset, int size);
}

컴파일은 됐다. 하지만 구현체를 보는 순간 위화감을 느꼈다.

@Repository
public class RedisRankingRepository implements RankingRepository {
    
    private final RedisTemplate<String, String> redisTemplate;
    private final ProductRankWeeklyJpaRepository weeklyJpaRepository;  // ← ?!
    private final ProductRankMonthlyJpaRepository monthlyJpaRepository; // ← ?!
    
    // Redis로 일간 조회...
    // JPA로 주간/월간 조회...
}

이름은 “Redis”인데 JPA를 주입받고 있었다. 이건 명백한 SRP(단일 책임 원칙) 위반이다.

왜 이런 일이 발생했는지 생각해보면, 하나의 인터페이스에 두 가지 변경 원인을 밀어넣었기 때문이다.

• RankingRepository의 일간 메서드들은 Redis ZSET이 변경되면 바뀐다.
• 주간/월간 메서드들은 MV 테이블 스키마가 변경되면 바뀐다.

변경 원인이 다르면 인터페이스도 달라야 한다. SOLID의 I(Interface Segregation Principle)가 말하는 바로 그것이다.

수정: 인터페이스 분리

// 일간 랭킹 (Redis) — 기존 그대로
public interface RankingRepository {
    List<RankedProduct> getTopRankings(LocalDate date, int offset, int size);
    long getTotalCount(LocalDate date);
    Long getRank(LocalDate date, Long productId);
    Double getScore(LocalDate date, Long productId);
}

// 기간별 랭킹 (DB MV) — 신규
public interface PeriodRankingRepository {
    List<RankedProduct> getWeeklyRankings(LocalDate date, int offset, int size);
    long getWeeklyTotalCount(LocalDate date);
    List<RankedProduct> getMonthlyRankings(LocalDate date, int offset, int size);
    long getMonthlyTotalCount(LocalDate date);
}

구현체도 깔끔하게 분리됐다.

// Redis만 아는 구현체
@Repository
public class RedisRankingRepository implements RankingRepository { ... }

// JPA만 아는 구현체
@Repository
public class JpaPeriodRankingRepository implements PeriodRankingRepository { ... }

Service에서는 두 인터페이스를 주입받아 period에 따라 라우팅한다.

@Service
public class RankingQueryService {
    private final RankingRepository rankingRepository;           // 일간 (Redis)
    private final PeriodRankingRepository periodRankingRepository; // 주간/월간 (JPA MV)
    
    public PageResult<RankingItemInfo> getRankings(LocalDate date, int page, int size, RankingPeriod period) {
        return switch (period) {
            case WEEKLY  -> /* periodRankingRepository.getWeeklyRankings(...) */
            case MONTHLY -> /* periodRankingRepository.getMonthlyRankings(...) */
            default      -> /* rankingRepository.getTopRankings(...) */
        };
    }
}

처음에 하나로 합쳤을 때 “이게 맞나?” 싶은 위화감이 있었는데, 그 감각이 맞았다. 이름과 책임이 안 맞으면 뭔가 잘못된 것이다.

6. 전체 구조 — 실시간과 배치의 공존

최종적으로 만들어진 구조는 이렇다.

[일간 랭킹 — 실시간]
Kafka Event → Commerce Streamer → Redis ZSET (ZINCRBY)
                                        ↓
                              API (ZREVRANGE) → 사용자

[주간/월간 랭킹 — 배치]
product_metrics → Spring Batch Job → MV 테이블 (saveAll)
  (일간 누적)     (Chunk Processing)       ↓
                                   API (JPA 조회) → 사용자

같은 “랭킹”이지만, 갱신 주기와 핵심 가치가 다르면 인프라도 달라야 한다. 일간은 이벤트 하나하나가 즉시 반영되어야 UX가 살아나고, 주간/월간은 하루 한 번 정확하게 집계되면 그만이다.

API 엔드포인트는 하나로 통합했다.

GET /api/v1/rankings?period=DAILY&date=20260417&page=0&size=20
GET /api/v1/rankings?period=WEEKLY&date=20260417&page=0&size=20
GET /api/v1/rankings?period=MONTHLY&date=20260417&page=0&size=20

클라이언트 입장에서는 period 파라미터 하나만 바꾸면 된다. 뒤에서 Redis를 보는지 DB를 보는지는 알 필요가 없다.

7. 회고 — 10주간 달라진 사고방식

이번 과제를 하면서 가장 많이 바뀐 건, “이걸로 풀 수 있다”에서 “이걸로 풀어야 하는가”로 질문이 바뀐 것이다.

10주 전이었다면 “Redis로 주간도 만들 수 있으니까 Redis로 하자”고 했을 것이다. 지금은 “주간 랭킹의 갱신 주기와 정확성 요구사항이 뭔지”를 먼저 본다. 기술이 아니라 요구사항이 아키텍처를 결정한다.

10주간의 흐름을 돌아보면:

• 1~3주차: 도메인 모델링과 계층 분리. “테이블 먼저”에서 “도메인 먼저”로 사고가 바뀌었다.
• 4~6주차: 트랜잭션과 동시성, 외부 시스템 연동. @Transactional 하나면 충분하다고 생각했는데, 분산 환경에서는 전혀 아니었다.
• 7주차: 이벤트와 Kafka. 동기 호출로 엮인 시스템을 이벤트로 분리하는 순간, 확장성에 눈이 떠졌다.
• 8주차: 대기열 큐. Redis의 다른 자료구조 활용.
• 9주차: Redis ZSET 기반 실시간 집계. “쓰기 최적화”를 고민하기 시작했다.
• 10주차: Spring Batch와 MV. 같은 도메인에서 실시간과 배치를 나누는 판단을 했다.

가장 큰 전환점을 꼽자면, 9주차에서 10주차로 넘어오는 지점이다. 같은 “랭킹”인데 다른 도구를 쓴다는 결정을 하려면, 기술의 장단점만으로는 부족하다. 이 데이터가 얼마나 자주 바뀌어야 하는가, 누가 소비하는가, 틀려도 되는가 — 이런 질문을 할 수 있어야 한다.

8. 남은 과제

현재 product_metrics는 날짜 구분 없는 누적 카운터다. 주간 배치와 월간 배치가 같은 시점의 스냅샷을 읽으므로, 엄밀히 말하면 “이번 주에 새로 발생한 좋아요 수”를 구분하지 못한다.

이를 해결하려면 일별 스냅샷 테이블(product_metrics_daily)을 도입해야 한다. 주간 집계 = 이번 주 7일치 daily의 SUM, 월간 집계 = 이번 달 daily의 SUM. 이렇게 되면 진정한 기간별 차분 집계가 가능하다.

지금은 “현재 누적 상태의 주기적 스냅샷”이라는 한계를 인지하고 있다. 하지만 데이터 파이프라인은 한 번에 완성하는 게 아니라, 요구사항이 구체화되면서 점진적으로 발전시키는 것이라고 생각한다.

참고

• 우아한형제들 - Spring Batch와 Querydsl — 대규모 데이터 처리 시 JpaPagingItemReader의 한계와 offset 없는 Reader 전략
• 우아한형제들 - 파일럿 프로젝트를 통한 배치경험기 — 300만 건 데이터 처리와 배치 Job 설계 패턴
• 우아한형제들 - 회원시스템 이벤트기반 아키텍처 구축하기 — 이벤트 분리와 도메인 간 의존성 관리
• Spring Docs - Spring Batch Reference — Chunk-Oriented Processing 공식 문서

TL;DR
랭킹 시스템의 본질은 정렬이 아니라 “어떤 시간 범위의 이벤트를, 어떤 가중치로 합산할 것인가라는 정책 결정이다. Redis ZSET은 그 정책을 서빙하는 도구일 뿐이다. 이 글에서는 이벤트 집계의 시간축 설계, 텀블링/슬라이딩 윈도우의 트레이드오프, 콜드 스타트와 Score Carry-Over의 진짜 의미, 그리고 실무에서 ZSET만으로는 부족한 이유까지를 다룬다.

0. 랭킹의 SOT(Source of Truth)는 이벤트다

랭킹 시스템을 처음 설계할 때 흔히 “어떤 DB에 저장하지?”부터 고민한다. Redis? Elasticsearch? RDB? 하지만 이 질문은 순서가 틀렸다.

랭킹은 특정 기간 동안 누적된 값을 가지고 줄 세우는 시스템이다. 그리고 그 “누적된 값”의 원천은 유저의 행동 이벤트다. 조회, 좋아요, 주문 — 이 이벤트들이 랭킹의 SOT(System of Record)이며, 이벤트를 어떻게 집계하고 저장하느냐에 따라 랭킹의 표현력과 정확성이 완전히 달라진다.

저장소 선택은 그 다음 문제다. 먼저 물어야 할 질문은 이것이다:

“우리는 어떤 시간 범위의 이벤트를, 어떤 기준으로 합산해서 보여줄 것인가?”

1. 시간축에 대한 감각 — 집계 단위가 랭킹의 표현력을 결정한다

이벤트를 집계하는 시간 단위는 곧 랭킹이 표현할 수 있는 최소 해상도다. 이것을 이해하지 못하면 “왜 우리 랭킹은 트렌드를 못 따라가지?”라는 질문에 답할 수 없다.

집계 단위별 표현력

일 단위로 집계하면, 하루가 하나의 버킷이 된다. 1년이면 365개의 버킷이고, 이 버킷들을 조합하면 7일 랭킹도, 30일 랭킹도, 90일 랭킹도 만들 수 있다.

시간 단위로 집계하면, 1시간이 하나의 버킷이다. “최근 1시간 급상승 상품”이라는 표현이 가능해진다. 하지만 1분 단위 버킷을 만들면? 하루에 1,440개, 이건 현실적으로 운영이 어렵다.

결국 집계 단위는 비즈니스 요구사항(BGC)에 따라 결정되며, 대부분의 이커머스는 일 단위로 시작하는 것이 합리적이다. 이번 설계에서도 일 단위를 기본으로 가져갔다.

데이터 규모 감각 잡기

집계 단위를 정했으면, 데이터 규모를 가늠해봐야 한다. 대략적인 계산을 해보자:

• DAU 1억 명(10^8)이라 가정
• 하루 86,400초 ≈ 약 10만 초로 라운딩
• 인당 평균 10개 이벤트 발생 → QPS ≈ 10,000
• 이벤트 하나당 약 20바이트

하루 데이터량: 20bytes × 10,000 QPS × 86,400초 ≈ 약 17GB

365일이면 약 6TB. 트래픽 피크를 3~6배 여유로 잡으면 연간 수십 TB. 이 규모에서는 RDB의 GROUP BY + ORDER BY가 왜 안 되는지 체감이 온다.

2. 왜 RDB의 ORDER BY로는 안 되는가

가장 먼저 떠오르는 접근은 당연히 SQL이다.

SELECT product_id, SUM(score) as total
FROM product_metrics
GROUP BY product_id
ORDER BY total DESC
LIMIT 20;

초기에는 동작한다. 상품 1,000개, 일일 이벤트 10,000건 수준이라면 문제없다. 하지만 이 쿼리가 어떤 맥락에서 호출되는지를 생각하면 이야기가 달라진다:

• 홈 메인 진입 시마다 호출 — DAU 10만이면 하루 수십만 회
• 상품 상세 페이지에서 “이 상품은 현재 N위” — 상품 수만큼 곱연산
• 카테고리별, 시간대별 랭킹까지 확장되면 쿼리 조합이 폭발

읽기 빈도가 압도적으로 높은 랭킹이라는 도메인 특성에서, 쓰기 시점에 정렬을 완료해두는 구조가 필요하다. 이것이 Redis ZSET을 선택한 핵심 이유다.

3. Redis ZSET — “삽입이 곧 정렬”이지만, 만능은 아니다

Redis Sorted Set은 (member, score) 쌍을 score 기준으로 항상 정렬된 상태로 유지한다. 삽입/수정 O(log N), Top-N 조회 O(log N + M).

ZINCRBY ranking:all:20260410 0.7 product:101   // 점수 누적
ZREVRANGE ranking:all:20260410 0 19 WITHSCORES  // Top 20 조회
ZREVRANK ranking:all:20260410 product:101       // 특정 상품 순위

ZSET의 실무적 한계 — 필터링이 안 된다

여기서 솔직하게 짚고 넘어갈 것이 있다. ZSET은 정렬된 데이터를 제공하는 데는 탁월하지만, 그 안에서 조건 필터링을 할 수 없다.

예를 들어, 100만 개 상품이 ZSET에 있는데 “여성 의류 카테고리만” 보고 싶다면? ZSET에는 그런 기능이 없다. 전체를 꺼내서 애플리케이션에서 필터링해야 한다.

실무에서 랭킹이 단순한 “전체 Top-N”을 넘어서는 순간 — 카테고리별, 성별, 연령대별 랭킹이 필요해지는 순간 — Redis ZSET만으로는 부족해진다. 실제로 현업에서는 Elasticsearch, NoSQL, 혹은 전용 검색/추천 엔진을 함께 사용하는 경우가 많다.

그럼에도 ZSET을 선택한 이유는, 이번 설계의 스코프가 “전체 상품 일간 랭킹”이라는 단일 차원이고, 이 범위에서는 ZSET이 가장 심플하면서도 성능이 보장되는 선택이기 때문이다. 가장 중요한 것은 스케일이 늘어났을 때 교체할 수 있는 구조로 만드는 것이다.

4. 아키텍처 — 이벤트가 랭킹이 되기까지

[유저 행동]
    │
    ▼
[commerce-api] ── 조회/좋아요/주문 이벤트 발행 ──▶ [Kafka Topic]
                                                        │
                                                        ▼
                                                [commerce-collector]
                                                    │         │
                                                    ▼         ▼
                                            product_metrics   Redis ZSET
                                              (R7 구축)       (이번 주차)
                                                              │
                                                              ▼
                                                [commerce-api]
                                                GET /rankings/top
                                                GET /products/{id}/rank

collector가 이벤트를 소비하면서 두 저장소에 동시 반영한다. product_metrics는 장기 분석용 원본, Redis ZSET은 실시간 서빙용 뷰. 이 분리가 주는 이점:

• ZSET이 날아가도 product_metrics에서 재구축 가능 (복원력)
• API 서버는 Redis만 바라보면 됨 (성능 격리)
• 각 저장소는 자신의 도메인에 최적화 (관심사 분리)

실시간 vs 준실시간 — ETL 파이프라인의 두 가지 스타일

여기서 잠깐, 데이터 처리 방식에 대해 넓은 시야로 보자.

실시간 이벤트 처리: Kafka Consumer가 이벤트를 즉시 소비하고 Redis에 반영. 우리가 이번에 구현한 방식이다.

준실시간/배치 처리: Spark 같은 도구로 S3에 쌓인 로그를 주기적으로(5분, 10분) 읽어 집계. 무신사가 이 방식이라고 한다.

어떤 방식이 맞는지는 비즈니스 요구에 달렸다. 29cm처럼 완전 초실시간이 필요한 곳도 있고, 5분 갱신으로 충분한 곳도 있다. 다만 데이터 규모가 커지면 로그성 데이터를 RDB에 직접 넣으면 터질 수 있으므로, 오프라인 파이프라인(Spark 등)을 통한 처리가 필수가 된다.

Kafka vs Redis — 쓰기 처리량의 차이

한 가지 더 짚자면, 쓰기 처리량에서 Kafka가 Redis보다 월등히 높다. Kafka는 프로듀서가 데이터를 벌크로 모아 보내는 구조이기 때문이다. 만 건의 이벤트를 Redis에 하나씩 쏘는 것과, Kafka에 벌크로 한 번에 보내는 것은 차원이 다르다.

그래서 이벤트 수집 단계에서 Kafka를 거치고, Consumer에서 Redis에 쓰는 구조가 합리적인 것이다. Consumer 쪽에서도 배치 리스너를 통해 100~200건씩 모아 처리하면 Redis에 대한 네트워크 RTT를 크게 줄일 수 있다.

5. “인기”를 수치화하기 — 정규화와 가중치의 설계

왜 단순 합산이 안 되는가

“인기 있는 상품”이란 무엇인가? 조회수가 높으면? 주문수가 높으면?

문제는 각 지표의 스케일이 다르다는 것이다. 조회수는 수만 단위, 주문수는 수십 단위. 이걸 단순히 더하면 조회수가 전체 스코어를 잡아먹는다. 클릭 100과 조회 100만을 더하면, 클릭의 의미가 완전히 사라진다.

정규화 — 서로 다른 스케일을 같은 척도로

각 지표를 0~1 사이의 값으로 변환해야 비교와 합산이 의미를 갖는다.

Min-Max 정규화가 흔히 쓰이지만, 실무에서는 함정이 있다. 대부분의 상품 가격이 10만원 이하인데 2,400만원짜리 가구가 하나 있다면? Min-Max 기준으로 나머지 상품은 전부 0에 수렴한다. 낮은 가격대의 변별력이 완전히 사라지는 것이다.

이런 경우 Saturation 방식이 더 적합하다. Max 값을 몰라도 적용 가능하고, 극단적인 아웃라이어에 의해 나머지 데이터가 뭉개지지 않는다.

가중치 — 비즈니스 중요도의 수치화

정규화된 지표에 서비스 전략에 맞는 가중치를 곱한다:

Score(product) = W(view) × Norm(view) 
              + W(like) × Norm(like) 
              + W(order) × Norm(order)

총합을 1.0으로 맞춘 것은 의도적이다. 새로운 시그널(장바구니 담기, 공유, 리뷰 등)이 추가될 때 기존 가중치를 비례적으로 재분배하기 쉬운 구조를 유지하기 위해서다.

솔직히 이 가중치가 “정답”인지는 모른다. 실제 운영이라면 A/B 테스트로 CTR, CVR을 모니터링하며 튜닝해야 한다. 다만 “왜 이 비율인가”에 대한 논리적 근거를 갖추고 시작하는 것과, 감으로 때려 넣는 것은 완전히 다르다.

랭킹 스코어의 고도화 — 실무에서는 여기서 끝이 아니다

현업의 랭킹 스코어에는 훨씬 많은 요소가 들어간다:

• 유저 이벤트 (클릭, 조회, 구매 — 우리가 이번에 구현한 것)
• LLM 판단 스코어 (상품 품질, 이미지 매력도 등의 AI 평가)
• 객단가 부스팅 (매출 기여도 가중)
• 어뷰징 방지 로직 (비정상 클릭 패턴 필터링)
• 광고 비딩 스코어 (광고 시스템과 연동 시)

특히 광고 시스템에서는 단순히 돈을 많이 낸 순서가 아니라 타겟팅 적합성까지 고려한 비딩이 이루어진다. 남성 속옷 광고를 여성에게 보여주면 ROAS(Return On Ad Spend)가 나오지 않아 광고주가 이탈하기 때문이다. 랭킹과 광고 시스템은 결국 같은 뿌리에서 나온다.

6. 시간의 양자화 — 텀블링 윈도우와 슬라이딩 윈도우

누적만 하면 왜 문제인가

처음에는 모든 점수를 하나의 ZSET에 누적했다. 며칠 지나니 문제가 보였다: 초기에 대량 이벤트가 발생한 상품이 영원히 상위를 독점한다.

이것이 롱테일(Long Tail) 문제다. 이미 상위에 있는 상품은 더 많은 노출 → 더 많은 클릭과 구매 → 격차 확대. 신상품은 아무리 좋아도 이 벽을 넘기 어렵다.

해법은 시간을 양자화하는 것이다. 두 가지 방식이 있다.

텀블링 윈도우 (Tumbling Window)

특정 시간 단위로 딱 끊어서 집계하는 방식이다. 우리가 구현한 일별 키 전략이 이것이다.

ranking:all:20260410   // 4월 10일의 이벤트만 집계
ranking:all:20260411   // 4월 11일의 이벤트만 집계

장점: 구현이 심플하고 키 관리가 명확하다.
단점: 윈도우가 넘어가는 순간 데이터가 0이 된다 → 콜드 스타트 발생.

슬라이딩 윈도우 (Sliding Window)

데이터가 들어오고 뒤에서 빠지며, 최근 N시간/N일의 데이터가 항상 유지되는 방식이다. 프로메테우스 같은 모니터링 시스템이 이 방식을 쓴다.

[현재 시점]
◀──────── 최근 24시간 ────────▶
항상 24시간분의 데이터가 유지됨

장점: 콜드 스타트가 발생하지 않는다.
단점: 구현이 복잡하다. 슬라이딩 윈도우의 데이터는 라운딩되어 있어 정확한 데이터가 아닐 수 있으며, 확대해서 보면 평탄화된 그래프가 보인다.

실무에서의 선택

29cm에서는 1시간짜리 버킷을 사용해서 일간/주간/월간 실시간 급상승 랭킹을 만들었다고 한다. 1시간 버킷 24개를 합산하면 일간, 168개면 주간이 되는 구조다. 하지만 이 계산 로직은 상당히 복잡해지며, 이런 수준의 테크닉을 사용하는 커머스 회사는 드물다.

우리는 일 단위 텀블링 윈도우 + Score Carry-Over라는 조합을 선택했다. 구현 복잡도와 표현력 사이의 합리적인 트레이드오프다.

7. 키 설계 — TTL과 네이밍 컨벤션

ranking:{scope}:{yyyyMMdd}

TTL은 왜 2일인가

일간 키이므로 이론적으로 24시간이면 충분하지만, 48시간(2일)으로 설정했다:

• Score Carry-Over 시 전날 키를 참조해야 하므로, 전날 키가 살아 있어야 한다
• 운영 중 디버깅이나 보정이 필요할 때 여유분이 필요하다
• 시간 윈도우의 1.5~2배가 안정적인 TTL 전략이라는 것은 실무에서 반복적으로 확인한 패턴이다

scope를 넣은 이유

지금은 all만 있지만, 카테고리별(ranking:electronics:20260410), 지역별 랭킹이 추가될 때 키 구조를 변경하지 않아도 된다.

8. 콜드 스타트와 Score Carry-Over — 생각보다 깊은 주제

단순한 “0점 시작” 문제가 아니다

콜드 스타트 문제를 “자정에 점수가 0이 되니까 랭킹이 비어 보인다”로만 이해하면 절반만 아는 것이다.

Score Carry-Over를 하는 이유는 두 가지다:

첫째, 콜드 스타트 완화. 텀블링 윈도우 방식에서 새 날이 시작되면 모든 상품이 0점이다. 새벽 1시에 앱을 켠 유저는 텅 빈 랭킹을 본다. 어제 1위였던 상품도, 신규 상품도 같은 출발선이다.

둘째, 랭킹의 표현력 향상. 이것이 더 중요한 이유인데, 특히 패션 커머스처럼 트렌드 반영이 핵심인 도메인에서 그렇다.

주간 랭킹을 만든다고 생각해보자. 7일치 일간 버킷을 동일한 비중으로 합산하면, 6일 전의 데이터와 오늘의 데이터가 같은 무게를 갖는다. 한국의 4계절처럼 시즌이 빠르게 바뀌는 패션 커머스에서, 일주일 전 인기였던 봄 아우터와 오늘 급부상 중인 여름 린넨 셔츠가 같은 가중치라면? 최신 트렌드가 묻힌다.

Score Carry-Over에 감쇠 계수를 적용하면, 오래된 데이터일수록 영향력이 줄어들면서 자연스럽게 최신 트렌드가 부각된다. 이것이 단순 합산 대비 Carry-Over가 갖는 진짜 가치다.

ZUNIONSTORE로 구현하기

ZUNIONSTORE ranking:all:20260411 1 ranking:all:20260410 WEIGHTS 0.1 AGGREGATE SUM

• ranking:all:20260410의 모든 멤버와 스코어를 가져온다
• 각 스코어에 0.1(10%)을 곱한다
• 결과를 ranking:all:20260411에 저장한다

왜 10%인가

[4월 10일 최종]               [4월 11일 시작 (Carry-Over)]
product:101 → 1000점    →    product:101 → 100점
product:202 → 500점     →    product:202 → 50점
product:303 → 200점     →    product:303 → 20점

오전 중으로 실제 이벤트가 쌓이면 Carry-Over 점수의 영향은 자연스럽게 희석된다.

만약 슬라이딩 윈도우였다면?

시간 단위 버킷을 24개 유지하는 슬라이딩 윈도우 방식이었다면 Carry-Over가 필요 없었을 수 있다. 항상 최근 24시간의 데이터가 존재하니까.

하지만 그 방식은 계산 로직이 복잡해지고, 정확히 24시간이 아닌 23시간 10분 같은 어중간한 데이터가 될 수 있다. 1분짜리 버킷을 만들면 하루에 1,440개 — 현실적이지 않다. 결국 라운딩이 들어가고, 이 라운딩이 랭킹의 대수 법칙에 큰 영향을 주지 않는다는 합의 하에 적절한 단위를 선택하게 된다.

개발에 “정답”이란 없다. 항상 다른 선택지가 있고, 트레이드오프가 있다.

실행 시점 — 스케줄러

Carry-Over는 매일 23:50에 실행하는 것이 이상적이다:

@Scheduled(cron = "0 50 23 * * *")
public void prepareNextDayRanking() {
    String today = LocalDate.now().format(DateTimeFormatter.BASIC_ISO_DATE);
    String tomorrow = LocalDate.now().plusDays(1).format(DateTimeFormatter.BASIC_ISO_DATE);
    
    String srcKey = "ranking:all:" + today;
    String destKey = "ranking:all:" + tomorrow;
    
    // ZUNIONSTORE를 통해 전날 점수의 10%를 시드
    // TTL 2일 설정
    redisTemplate.expire(destKey, Duration.ofDays(2));
}

9. 상품 삭제와 랭킹 정합성 — 이벤트 드리븐의 현실

실무에서 반드시 마주치는 문제가 있다: “랭킹에 있는 상품이 삭제되면?”

상품팀에서 상품을 삭제하거나 품절 처리했는데, 랭킹에는 여전히 노출된다. 유저가 클릭하면 404. 이건 심각한 UX 문제다.

이 문제를 해결하려면 상품 삭제 이벤트가 전사적으로 전파되어야 한다. 이벤트 드리븐 아키텍처가 필수적인 이유 중 하나다. 하지만 각 팀(랭킹, 검색, 추천, 전시)의 데이터 처리 타이밍이 다를 수 있어 일관성 유지가 어렵다.

규모가 커지면 이 문제를 전담하는 “전시팀”이 생긴다. 모든 데이터가 전시 레이어를 통해 노출되면 일관성을 유지할 수 있다.

한 가지 더 — 품절/삭제된 상품을 랭킹에서 즉시 제거할지, “판매 종료”로 표시할지는 개발자가 아니라 PO(Product Owner)의 결정이다. 개발자가 할 일은 어떤 결정이 내려와도 쉽게 변경할 수 있는 구조를 미리 만들어두는 것이다. 이런 변경 가능성을 예측하고 준비해두면 높은 평가를 받는다.

10. API 설계 — 랭킹을 어떻게 서빙할 것인가

Top-N 조회

GET /api/v1/rankings?date=20260410&size=20&page=1

ZREVRANGE로 Top-N을 가져온 뒤, 상품 ID 목록으로 상세 정보를 조회해서 합쳐 응답한다.

개별 상품 순위 조회

GET /api/v1/products/{id}/rank

ZREVRANK로 O(log N)에 조회. 랭킹 미진입 상품은 null 반환.

View와 Impression의 구분 — 이벤트 로그 설계의 디테일

랭킹에 쓰이는 “조회 이벤트”를 설계할 때 한 가지 더 고민해야 할 것이 있다.

상품 목록이 3열로 나올 때, 핸드폰 기종에 따라 마지막 열이 화면에 잘릴 수 있다. 이걸 “조회”로 칠 것인가? 이미지의 몇 퍼센트가 노출되어야 “봤다”고 칠 것인가?

이 기준을 Impression 비율이라 하며, 이 기준에 따라 조회 이벤트의 정의 자체가 달라진다. 단순해 보이지만, 이 기준이 랭킹 스코어의 정확도에 직접적으로 영향을 미친다.

11. 돌아보며 — 기술적 판단은 항상 트레이드오프다

이번에 내린 판단들의 기록

로직보다 중요한 것은 “로직을 쉽게 바꿀 수 있는 구조”

멘토링에서 가장 인상 깊었던 말이 있다:

“로직 질문이 많을수록, 로직 자체보다 로직을 쉽게 변경할 수 있는 테스트 가능한 구조로 아키텍처를 짜야 한다.”

가중치가 바뀔 수 있다. 집계 단위가 바뀔 수 있다. Carry-Over 비율이 바뀔 수 있다. 랭킹은 “정답이 없기에 계속 튜닝해 나가는” 시스템이다. 그래서 각 정책 값이 외부에서 주입 가능하고, 변경 시 테스트로 검증할 수 있는 구조가 코드의 정교함보다 중요하다.

랭킹은 “정적 vs 동적”의 줄다리기

랭킹은 정적이어야 한다는 관점이 있다 — 유저가 볼 때마다 순위가 바뀌면 신뢰를 잃는다. 반대로, 유저가 원하는 것에 따라 실시간으로 변해야 한다는 관점도 있다 — 지금 이 순간 핫한 것을 보여줘야 구매가 일어난다.

정답은 없다. 서비스의 성격, 유저의 기대, 비즈니스 목표에 따라 그 줄다리기의 균형점이 달라질 뿐이다.

이번 글은 “어떻게 만들었는가”보다 “왜 그렇게 판단했는가”에 집중했다. 코드는 6개월이면 레거시가 되지만, 판단의 근거는 다음 시스템을 설계할 때도 유효하다. 그래서 기록한다.

TL;DR: 선착순 주문에 10만 명이 몰리는 상황을 Redis 대기열로 풀었다. 처음에는 “Redis니까 빠르겠지”로 시작했는데, 동시성 구멍이 줄줄이 터졌다. Lua 스크립트로 원자성을 확보하고, 100ms 단위 분산 발급으로 Thundering Herd를 완화하고, 토큰 소비를 원자 연산으로 바꾸기까지의 과정을 정리했다.

1. 문제: “선착순 주문”이라는 폭탄

이커머스에서 선착순 주문은 늘 문제다. 평소 TPS가 50인 서비스에 갑자기 10만 명이 동시에 POST /orders를 누른다. DB 커넥션 풀은 40개다. 나머지 99,960명의 요청은 어디로 가는가?

답은 간단하다. 커넥션 풀이 고갈되고, 타임아웃이 연쇄하고, 서비스 전체가 멈춘다.

선착순 주문뿐만이 아니다. 타임세일, 한정판 드랍, 쿠폰 발급 — 트래픽이 순간적으로 폭증하는 시나리오는 실무에서 반복적으로 나타난다. 이 문제를 풀기 위해 대기열 시스템을 설계했다.

2. 핵심 아이디어: “줄 세우기”

대기열의 본질은 단순하다. 서버가 처리할 수 있는 속도로만 사용자를 들여보내는 것.

[사용자 10만명] → [대기열 (FIFO)] → [토큰 발급 (18명/100ms)] → [주문 API]

1. 사용자가 POST /queue/enter로 대기열에 진입한다.
2. 스케줄러가 100ms마다 앞에서 18명씩 꺼내서 입장 토큰을 발급한다.
3. 토큰을 받은 사용자만 POST /orders를 호출할 수 있다.
4. 토큰이 없으면 인터셉터에서 403으로 차단한다.

이렇게 하면 주문 API에 도달하는 트래픽이 초당 ~180명으로 제한된다. DB 커넥션 풀(40개)이 감당할 수 있는 수준이다.

3. 숫자를 먼저 정했다

설계 전에 시스템이 감당할 수 있는 한계를 먼저 계산했다. 감(感)이 아니라 숫자로 시작해야 한다.

하류 시스템 처리량 역산

DB 커넥션 풀 (HikariCP max)     = 40개
주문 1건 평균 처리 시간           = ~200ms (비관적 락 + 쿠폰 검증 + 저장 + 이벤트)
이론적 최대 TPS                  = 40 / 0.2 = 200 TPS
안전 마진 적용 (70%)             = 200 × 0.7 = 140 TPS

실제 설정에서는 175 TPS로 잡았다. Tomcat max threads(200)는 커넥션 풀(40)보다 넉넉하므로 병목은 DB 커넥션이다. 커넥션 풀이 병목이라는 사실을 먼저 파악한 것이 나머지 설계의 출발점이 되었다.

Thundering Herd 완화

여기서 중요한 판단이 있었다. 175명을 1초에 한 번 발급할 것인가, 100ms마다 나눠서 발급할 것인가?

AS-IS: 1초마다 175명 동시 발급 → 175명이 동시에 POST /orders → 커넥션 풀 순간 고갈
TO-BE: 100ms마다 ~18명씩 발급 → 10회에 걸쳐 분산 → 순간 부하 10배 감소

9.5분이 넘으면 사용자 이탈률이 급격히 올라가므로, 10만 명을 넘으면 QUEUE_FULL로 거절하기로 했다. “모두 받아주겠다”는 것보다 “솔직하게 거절하겠다”는 것이 더 나은 UX라고 판단했다.

4. Redis를 선택한 이유 — 그리고 처음에 잘못 쓴 이유

대기열 저장소로 Redis Sorted Set을 선택했다. 이유는 명확하다.

• ZADD: O(log N) 삽입 + FIFO 보장 (score 기반 정렬)
• ZPOPMIN: O(log N) + O(M) 으로 앞에서 N명 추출
• ZRANK: O(log N) 으로 내 순번 조회
• 인메모리이므로 10만 명 수준은 메모리 수 MB로 처리 가능

하지만 “Redis니까 빠르고 안전하겠지”는 착각이었다.

처음 구현은 이랬다.

// 처음 구현 — 원자성이 없다
public long enter(Long userId) {
    if (entryTokenRepository.exists(userId)) throw ALREADY_HAS_TOKEN;   // ① 토큰 확인
    if (waitingQueueRepository.getTotalSize() >= maxSize) throw FULL;   // ② 크기 확인
    double score = System.currentTimeMillis();                          // ③ score 생성
    waitingQueueRepository.add(userId, score);                          // ④ ZADD
    return waitingQueueRepository.getRank(userId);                      // ⑤ 순번 반환
}

이 코드에는 세 가지 동시성 구멍이 있었다.

구멍 1: 크기 검사와 삽입 사이의 틈

Thread A: ② getTotalSize() → 99,999 (OK)
Thread B: ② getTotalSize() → 99,999 (OK)
Thread A: ④ ZADD → 100,000번째
Thread B: ④ ZADD → 100,001번째 ← maxQueueSize 초과!

크기 확인과 삽입이 별도 명령이므로, 두 스레드가 동시에 통과할 수 있다.

구멍 2: System.currentTimeMillis() 충돌

같은 밀리초에 두 명이 진입하면 score가 동일하다. Redis Sorted Set은 동일 score일 때 member를 사전순으로 정렬하므로, 먼저 요청한 사람이 뒤로 밀릴 수 있다. FIFO가 깨진다.

구멍 3: 토큰 확인과 진입 사이의 틈

Thread A: ① exists(userId) → false
Scheduler: 토큰 발급 (userId에게 토큰 발급)
Thread A: ④ ZADD → 대기열에도 있고 토큰도 있는 상태!

5. Lua 스크립트로 원자성 확보

위 세 가지 구멍을 모두 막으려면, 토큰 확인 → 크기 검사 → score 생성 → 삽입 → 순번 반환을 하나의 원자 연산으로 묶어야 한다. Redis의 Lua 스크립트가 정확히 이 용도다.

-- ENTER_SCRIPT: 대기열 진입 (원자적)
-- KEYS: [waiting-queue, waiting-queue:seq]
-- ARGV: [userId, maxQueueSize, tokenKeyPrefix]

-- 1. 토큰 보유 여부 확인
if redis.call('EXISTS', ARGV[3] .. ARGV[1]) == 1 then
    return -2  -- ALREADY_HAS_TOKEN
end

-- 2. 이미 대기열에 있는지 확인 (멱등성)
local rank = redis.call('ZRANK', KEYS[1], ARGV[1])
if rank then return rank end

-- 3. 대기열 크기 확인
if tonumber(redis.call('ZCARD', KEYS[1])) >= tonumber(ARGV[2]) then
    return -1  -- QUEUE_FULL
end

-- 4. 단조 증가 score 생성 (INCR로 충돌 불가)
local seq = redis.call('INCR', KEYS[2])

-- 5. 삽입 + 순번 반환
redis.call('ZADD', KEYS[1], 'NX', seq, ARGV[1])
return redis.call('ZRANK', KEYS[1], ARGV[1])

Redis는 Lua 스크립트를 단일 스레드에서 원자적으로 실행한다. 스크립트 실행 중에는 다른 명령이 끼어들 수 없다. 이 한 가지 특성이 위의 세 가지 구멍을 모두 막는다.

System.currentTimeMillis() 대신 INCR로 단조 증가하는 시퀀스를 score로 사용한 것도 핵심이다. 같은 밀리초에 100명이 진입해도 score가 전부 다르므로 FIFO가 보장된다.

같은 원리로 토큰 발급(pop + save)과 토큰 소비(검증 + 삭제)도 Lua로 원자화했다.

-- CONSUME_IF_MATCHES_SCRIPT: 토큰 검증 + 삭제를 한 번에
local stored = redis.call('GET', KEYS[1])
if not stored then return -1 end           -- 토큰 없음 (만료)
if stored == ARGV[1] then
    redis.call('DEL', KEYS[1])
    return 1                                -- 소비 성공
end
return 0                                    -- 토큰 불일치

이 스크립트 하나로 동일 토큰으로 동시에 두 번 주문하면 정확히 한 번만 성공하는 것을 보장한다.

6. 토큰 생명주기 — 실패해도 괜찮은 구조

토큰의 생명주기를 설계할 때 가장 고민한 부분은 “주문이 실패하면 토큰은 어떻게 되는가?”였다.

[진입] → [대기] → [토큰 발급 (TTL 5분)] → [토큰 소비] → [주문 생성]
                                              ↓ (주문 실패 시)
                                          [토큰 복원]

처음에는 OrderService 안에서 @Transactional 경계 내에 토큰 삭제를 넣었다. 하지만 Redis 삭제와 DB 트랜잭션은 서로 다른 시스템이므로 원자성이 보장되지 않는다.

• Redis 삭제 성공 → DB 커밋 실패 → 토큰은 사라졌는데 주문은 없는 상태
• Redis 삭제 실패 → DB 커밋 성공 → 주문은 됐는데 토큰이 남아서 중복 주문 가능

이 문제를 인터셉터 패턴으로 풀었다.

public class EntryTokenInterceptor implements HandlerInterceptor {
    
    @Override
    public boolean preHandle(...) {
        String token = request.getHeader("X-Entry-Token");
        // Lua 스크립트로 검증 + 삭제를 원자적으로 수행
        validateEntryTokenUseCase.consume(userId, token);
        // 복원용으로 저장
        request.setAttribute("consumed-token", token);
        return true;
    }
    
    @Override
    public void afterCompletion(..., Exception ex) {
        if (ex != null) {
            // 주문 실패 시 토큰 복원 (TTL 유지)
            String token = (String) request.getAttribute("consumed-token");
            entryTokenRepository.save(userId, token, remainingTtl);
        }
    }
}

• preHandle: 주문 API 진입 전에 토큰을 원자적으로 소비(Lua로 검증+삭제 동시 수행)
• afterCompletion: 주문이 실패하면 토큰을 복원

이렇게 하면 토큰 소비가 OrderService의 트랜잭션 경계 밖에서 일어나므로, DB 트랜잭션 실패와 Redis 상태 불일치 문제가 해소된다. 최악의 경우에도 토큰 TTL(5분)이 안전망 역할을 한다.

7. 동시성 테스트 — “되겠지”는 테스트가 아니다

대기열 시스템에서 단위 테스트만으로는 부족하다. 동시에 50명이 진입하고, 동시에 같은 토큰으로 주문하고, 스케줄러가 동시에 돌아가는 상황을 테스트해야 한다.

@Test
void 동일_토큰으로_동시_주문시_정확히_1건만_성공한다() {
    // 50 threads가 동시에 같은 토큰으로 consume 시도
    CountDownLatch startLatch = new CountDownLatch(1);
    CountDownLatch doneLatch = new CountDownLatch(50);
    ConcurrentLinkedQueue<Throwable> errors = new ConcurrentLinkedQueue<>();
    AtomicInteger successCount = new AtomicInteger(0);
    
    for (int i = 0; i < 50; i++) {
        executor.submit(() -> {
            startLatch.await();  // 모든 스레드가 동시에 시작
            try {
                queueService.consume(userId, token);
                successCount.incrementAndGet();
            } catch (Exception e) {
                errors.add(e);
            } finally {
                doneLatch.countDown();
            }
        });
    }
    
    startLatch.countDown();  // 동시 출발
    assertThat(doneLatch.await(10, SECONDS)).isTrue();
    assertThat(successCount.get()).isEqualTo(1);  // 정확히 1건
    assertThat(errors).hasSize(49);                // 나머지는 전부 실패
}

여기서 중요한 건 ConcurrentLinkedQueue로 실패를 수집하는 것이다. 처음에는 예외를 그냥 삼키고 doneLatch만 확인했는데, 이러면 스레드 일부가 예상과 다른 이유로 실패해도 테스트가 녹색이 된다. 거짓 양성(false positive)은 동시성 테스트에서 가장 위험한 결과다.

8. 코드 리뷰에서 배운 것

이 시스템은 처음 PR을 올린 뒤 코드 리뷰에서 상당한 지적을 받았다. 그 과정에서 배운 것들을 정리한다.

배운 것 1: “나중에 Lua로 바꿔야지”는 없다

처음에는 Java에서 여러 Redis 명령을 순차 호출하고, “성능 이슈가 생기면 Lua로 바꾸자”고 생각했다. 하지만 성능이 아니라 정합성이 문제였다. 동시성 버그는 “나중에”가 아니라 트래픽이 폭증하는 바로 그 순간에 터진다. 대기열 시스템은 트래픽 폭증을 전제로 만드는 것이므로, 원자성은 최초 설계부터 확보해야 했다.

배운 것 2: validate()와 consume()은 분리하면 안 된다

처음에는 인터셉터에서 validate(token) → OrderService에서 delete(token)으로 분리했다. “검증은 검증, 삭제는 삭제”라는 깔끔한 분리처럼 보였다. 하지만 그 사이에 같은 토큰으로 두 번째 요청이 들어오면 둘 다 검증을 통과한다. 검증과 소비는 반드시 원자 연산이어야 한다. consumeIfMatches Lua 스크립트가 이 교훈의 결과물이다.

배운 것 3: Master/Replica 분리는 대기열에서 독이 될 수 있다

읽기 성능을 위해 Redis Master/Replica를 분리했는데, 토큰 발급(Master 쓰기) 직후 토큰 검증(Replica 읽기)을 하면 복제 지연 때문에 “토큰 없음”이 나올 수 있다. Read-your-writes가 필요한 경로에서는 Replica가 아니라 Master에서 읽어야 한다. “읽기는 무조건 Replica”라는 규칙은 대기열에서는 틀렸다.

9. 이 경험이 실무에서 어떻게 쓰일까

이번에 배운 것의 핵심은 기술이 아니라 사고방식이다.

“이 시스템에 10만 명이 동시에 몰리면 어디가 먼저 터지는가?”

이 질문을 먼저 하고, 숫자를 먼저 계산하고, 병목을 먼저 파악한 뒤에 코드를 짜야 한다. DB 커넥션 풀 40개라는 제약을 모른 채 대기열을 설계하면, 대기열을 통과한 뒤에 결국 같은 문제가 터진다.

그리고 동시성 문제는 “일어날 수 있다”는 건 “반드시 일어난다”와 같다. 특히 트래픽이 몰리는 순간에. “확률이 낮으니까 괜찮겠지”는 선착순 주문에서 가장 위험한 생각이다.

10. 남은 과제

현재 구현에는 인지하고 있는 한계가 있다.

• 토큰 복원의 불완전함: 인터셉터의 afterCompletion에서 토큰을 복원하지만, 서버 프로세스 자체가 죽으면 복원이 불가능하다. 최종 안전망은 TTL(5분)이지만, 그 사이 해당 슬롯은 사실상 낭비된다.
• 단일 Redis 의존: Redis 장애 시 대기열 전체가 멈춘다. Redis Sentinel이나 Cluster로 HA를 확보하거나, 대기열 장애 시 직접 주문을 허용하는 폴백 정책이 필요하다.
• 대기 시간 추정의 한계: 순번 / 초당 처리량은 순수 추정치다. 토큰 미사용(만료)이 많으면 실제 대기 시간은 더 짧고, 하류 시스템 장애가 나면 더 길어진다.

이런 한계를 인식하고 있다는 것 자체가, 10주 전의 나와 다른 점이라고 생각한다. 예전에는 “동작하면 끝”이었다면, 지금은 “이게 어떤 상황에서 깨지는가”를 먼저 본다.

참고

• 우아한형제들 - 선착순 이벤트 서버 생존기 — 대규모 트래픽 처리를 위한 대기열 설계와 정산 배치
• 우아한형제들 - Spring Batch와 Querydsl — 대규모 데이터 처리 성능 최적화
• 카카오 - Redis, 잘못 쓰면 망한다 — Redis 안티패턴과 주의사항
• Redis Sorted Set을 활용한 랭킹 시스템 개발하기 — ZSET 기반 실시간 랭킹 구현 사례

TL;DR: 이커머스에 이벤트 기반 아키텍처를 도입했다. 이벤트를 발행하는 코드는 한 줄이었지만, @EventListener와 @TransactionalEventListener 중 뭘 쓸지, DB 커밋과 Kafka 발행 사이의 이벤트 유실을 어떻게 막을지, 선착순 쿠폰에서 중복 발급을 어떻게 막을지 — 진짜 어려운 건 “경계”를 정하는 일이었다.

1. 왜 이벤트가 필요했나

주문 취소 하나에 재고 복구, 쿠폰 복원, PG 환불이 엮여 있었다. 코드로 보면 이랬다.

@Transactional
public void cancelOrder(Long orderId) {
    Order order = orderRepository.findById(orderId);
    order.cancel();
    stockService.restore(order);         // 재고 복구
    couponService.restore(order);        // 쿠폰 복원
    pgClient.refund(order);              // PG 환불 ← 외부 API
}

이 코드의 문제는 PG 환불이 5초 타임아웃을 내면 재고 복구와 쿠폰 복원까지 롤백된다는 것이다. PG가 장애면 주문 취소 자체가 불가능해진다. 외부 시스템 하나가 내부 비즈니스 로직 전체를 인질로 잡는 구조다.

이벤트 기반 아키텍처를 도입한 이유는 간단하다. “실패해도 괜찮은 것”과 “반드시 함께 성공해야 하는 것”을 분리하기 위해서.

2. 첫 번째 판단 — 같은 트랜잭션 vs 커밋 후 분리

Spring에서 이벤트 리스너는 두 가지다.

• @EventListener: 같은 트랜잭션에서 동기 실행. 리스너가 실패하면 원래 트랜잭션도 롤백.
• @TransactionalEventListener(AFTER_COMMIT): 커밋 성공 후 실행. 리스너가 실패해도 원래 트랜잭션은 이미 커밋됨.

어느 것을 쓸지는 “이 로직이 실패하면 원래 작업도 실패해야 하는가?”로 결정했다.

// 핵심 로직 — 같은 트랜잭션 (데이터 정합성 필수)
@EventListener
public void handle(OrderCancelledEvent event) {
    restoreStock(event);
    restoreCoupon(event);
}

// 부가 로직 — 커밋 후 별도 처리 (외부 API, 재시도 가능)
@TransactionalEventListener(phase = AFTER_COMMIT)
public void handle(OrderCancelledEvent event) {
    refundPaymentUseCase.refundPayment(event.orderId());
}

이렇게 나누니까 PG가 10초간 장애를 내도 주문 취소는 정상적으로 완료되고, 재고와 쿠폰은 정확하게 복구된다. PG 환불은 나중에 재시도하면 된다.

3. 좋아요 집계에서 배운 것 — 집계 실패가 좋아요를 롤백시켰다

비슷한 문제가 좋아요에서도 터졌다.

// 처음 코드
@EventListener  // ← 같은 트랜잭션
public void handle(ProductLikedEvent event) {
    productRepository.incrementLikeCount(event.productId());
}

incrementLikeCount에서 예외가 발생하면 좋아요 등록 자체가 롤백된다. 사용자 입장에서는 하트를 눌렀는데 아무 반응이 없는 상황이다. 좋아요 수 집계가 1초 늦어도 비즈니스에 문제없지만, 좋아요 자체가 안 되면 UX가 깨진다.

// 수정 후
@Transactional  // 독립 트랜잭션 (AFTER_COMMIT이므로 기존 TX 밖)
@TransactionalEventListener(phase = AFTER_COMMIT)
public void handle(ProductLikedEvent event) {
    productRepository.incrementLikeCount(event.productId());
}

핵심 변경은 두 가지다.

1. AFTER_COMMIT → 좋아요가 커밋된 후에 실행. 집계가 실패해도 좋아요는 성공.
2. @Transactional on method → AFTER_COMMIT 핸들러는 기존 트랜잭션이 끝난 뒤 실행되므로, 별도 트랜잭션을 열어야 DB에 쓸 수 있다.

이 경험에서 얻은 기준이 하나 생겼다.

“이 부가 로직이 실패해서 사용자의 핵심 행위가 취소되는 게 말이 되는가?”

말이 안 되면 AFTER_COMMIT이다.

4. Outbox Pattern — DB는 커밋됐는데 Kafka는 실패하면?

좋아요가 성공하면 Kafka를 통해 product_metrics의 좋아요 수를 갱신해야 한다. 처음에는 단순하게 했다.

1. BEGIN TRANSACTION
2. INSERT INTO likes (...)           ← DB 저장
3. COMMIT                            ← 성공
4. kafkaTemplate.send(...)           ← 네트워크 타임아웃 → 이벤트 유실!

DB 커밋은 됐는데 Kafka 발행이 실패하면, 좋아요는 등록됐지만 메트릭스에는 반영 안 된다. 반대로 Kafka를 트랜잭션 안에 넣으면, Kafka 장애 시 좋아요 자체가 실패한다. 어느 쪽이든 문제다.

이걸 Transactional Outbox Pattern으로 풀었다.

[같은 트랜잭션 — 원자성 보장]
1. BEGIN TRANSACTION
2. INSERT INTO likes (...)           ← 비즈니스 데이터
3. INSERT INTO outbox_events (...)   ← 이벤트를 DB 테이블에 저장
4. COMMIT                            ← 둘 다 성공하거나 둘 다 실패

[별도 프로세스 — OutboxEventPublisher @Scheduled(1초)]
5. SELECT * FROM outbox_events WHERE status = 'PENDING'
6. kafkaTemplate.send(topic, key, message)
7. UPDATE outbox_events SET status = 'PUBLISHED'
   → 실패 시 다음 폴링에서 재시도 → At Least Once 보장

비즈니스 데이터와 이벤트가 같은 DB 트랜잭션에 저장되므로 “데이터는 있는데 이벤트는 없는” 상태가 불가능하다. 발행은 별도 프로세스가 폴링으로 처리하고, 실패하면 다음 번에 재시도한다.

대안으로 Debezium CDC를 검토했지만, 학습 목적과 현재 규모에서는 폴링이 적절하다고 판단했다. 1초 지연은 product_metrics 갱신에서 허용 가능한 수준이다.

어떤 이벤트를 Kafka로 보내는가?

이벤트를 무조건 Kafka로 보내는 게 아니다. “다른 시스템(commerce-streamer)이 이 이벤트를 알아야 하는가?”로 판단했다.

5. 선착순 쿠폰 — Redis INCR만 믿으면 중복이 난다

선착순 쿠폰 발급은 Kafka를 통한 비동기 처리로 설계했다.

사용자 → POST /coupons/{id}/issue
         → 202 Accepted (requestId 반환, 즉시 응답)
         → Outbox → Kafka → CouponIssueConsumer → 실제 발급
         → GET /coupons/{id}/issue-status (폴링으로 결과 확인)

문제는 Consumer에서의 중복 방어였다. Kafka는 At Least Once를 보장하므로, 같은 메시지가 두 번 올 수 있다. 게다가 같은 사용자가 버튼을 연타하면 여러 요청이 들어온다.

처음에는 Redis INCR로 수량만 체크했다.

// 처음 코드 — 구멍이 있다
Long count = redisTemplate.opsForValue().increment(key);
if (count > maxIssuance) {
        redisTemplate.opsForValue().decrement(key);  // 롤백
    return;
            }
            userCouponRepository.save(...);  // 발급

이것만으로는 같은 유저가 2개 받는 걸 막지 못한다. Kafka 메시지가 2번 도착하면 INCR이 2번 성공하고, 같은 유저에게 쿠폰이 2장 발급된다.

3중 방어로 해결

// Layer 1: Kafka 메시지 멱등 — 같은 eventId 재처리 방지
if (eventHandledRepository.existsById(eventId)) return;

// Layer 2: 유저 중복 방지 — 이미 발급받은 유저 차단
        if (userCouponRepository.existsByCouponIdAndUserId(couponId, userId)) {
        request.markRejected("Already issued");
    return;
            }

// Layer 3: 수량 제한 — Redis INCR 원자적 카운터
Long count = redisTemplate.opsForValue().increment(key);
if (count > maxIssuance) {
        redisTemplate.opsForValue().decrement(key);
    request.markRejected("Quota exceeded");
    return;
            }

// 모든 체크 통과 → 발급
            userCouponRepository.save(...);
request.markSuccess();

동시성 테스트로 검증했다: 200명 동시 요청 + 100개 수량 제한 → 정확히 100개만 발급, 같은 유저 5번 요청 → 1장만 발급.

6. 안티패턴 6개를 고쳤다

PR을 올리고 나서 코드 리뷰에서, 그리고 스스로 돌아보면서 발견한 안티패턴들이 있었다.

6-1. 클래스 레벨 @Transactional

// Before — 읽기 전용 메서드도 트랜잭션이 열린다
@Service
@Transactional
public class OrderService { ... }

// After — 쓰기 메서드에만 명시
@Service
public class OrderService {
    @Transactional
    public void createOrder(...) { ... }

    // 읽기 메서드는 @Transactional 없음
    public Order getOrder(...) { ... }
}

13개 서비스에서 클래스 레벨 @Transactional을 제거했다. 불필요한 트랜잭션은 커넥션 점유 시간을 늘린다.

6-2. Consumer의 protected @Transactional이 동작 안 함

// Before — Spring 프록시가 protected 메서드를 가로채지 못함
@Transactional
protected void processRecord(ConsumerRecord<...> record) { ... }

// After — TransactionTemplate으로 프로그래밍 방식 트랜잭션
records.forEach(record ->
        transactionTemplate.executeWithoutResult(status -> processRecord(record))
        );

@Transactional은 Spring AOP 프록시 기반이라 public 메서드에서만 동작한다. protected에 붙이면 트랜잭션 없이 실행된다. 3개 Consumer에서 모두 TransactionTemplate으로 교체했다.

6-3. Outbox 루프에서 break → continue

// Before — 하나 실패하면 나머지 전부 발행 중단
for (OutboxJpaEntity event : pendingEvents) {
        try { send(event); }
        catch (Exception e) { break; }  // ← 전체 중단!
        }

// After — 실패한 건만 건너뛰고 계속 진행
        for (OutboxJpaEntity event : pendingEvents) {
        try { send(event); }
        catch (Exception e) {
        log.warn("발행 실패: {}", event.getId());
        continue;  // ← 나머지는 계속 발행
        }
        }

이벤트 A의 발행 실패가 이벤트 B, C, D의 발행까지 막으면 안 된다. A는 다음 폴링에서 재시도하면 된다.

7. 이번 주에 가장 많이 바뀐 사고방식

이벤트를 도입하기 전에는 모든 로직이 하나의 @Transactional 안에 있었다. 재고 차감, 쿠폰 검증, 주문 저장, PG 결제, 이벤트 발행 — 전부 한 트랜잭션이다. 하나가 실패하면 전부 롤백된다. 단순하고 안전해 보였다.

하지만 외부 시스템이 하나만 추가되면 이 “단순함”은 “취약함”이 된다. PG 타임아웃 하나가 모든 걸 멈춘다.

이벤트 기반 아키텍처를 도입하면서 배운 건 “모든 걸 한 번에 성공시키려 하지 마라”는 것이다. 핵심은 같은 트랜잭션에서 확실히 성공시키고, 부가적인 것은 커밋 후에 최선을 다해 처리하되 실패하면 재시도한다. 이것이 Eventually Consistent의 본질이라는 걸 코드로 체감했다.

Before: "모든 게 성공하거나, 모든 게 실패하거나"
After:  "핵심은 반드시 성공. 부가는 최선을 다하되, 실패하면 나중에"

이게 “이벤트를 발행하는 건 쉬웠다”고 한 이유다. 진짜 어려운 건 어디까지를 “핵심”으로 볼 것인가, 어디서부터 “부가”로 분리할 것인가를 판단하는 일이었다.

참고

• 우아한형제들 - 회원시스템 이벤트기반 아키텍처 구축하기 — 3가지 이벤트 종류와 3가지 구독자 계층 정의
• 우아한형제들 - 잊을만 하면 돌아오는 정산 신병들 — 대규모 정산 배치와 이벤트 흐름
• Spring Docs - Application Events — @EventListener, @TransactionalEventListener 공식 문서

결제 시스템에서 가장 중요한 건 “정상 동작하는 코드”가 아니라 “장애 상황에서도 돈이 맞는 코드”입니다. 이 글은 외부 PG사 연동 과정에서 겪은 동시성 버그, Circuit Breaker 설정 시행착오, 그리고 “멱등성이 만능이 아니었다”는 깨달음을 기록합니다.

들어가며: 장애는 전파된다

커머스 서비스에서 주문과 결제는 분리된 시스템입니다. 주문 서비스(Commerce API)가 외부 PG사에 결제를 요청하고, PG가 카드사와 통신하여 승인/거절 결과를 돌려줍니다.

[사용자] → [Commerce API] → [PG사] → [카드사]

출처: Martin Fowler - Circuit Breaker Pattern

이 구조에서 PG가 장애가 나면 어떻게 될까요?

PG 장애 발생
  → Commerce API가 PG 응답을 5초간 대기 (타임아웃)
  → 스레드가 대기 상태로 점유됨
  → 다른 사용자의 요청도 처리 못함
  → Commerce API도 장애 💥  (장애 전파)

PG 하나가 죽었을 뿐인데, 주문 조회, 상품 목록 등 결제와 무관한 기능까지 전부 멈춥니다. 이것이 장애 전파(Cascading Failure)입니다.

처음에는 단순하게 생각했습니다. “PG 호출 실패하면 에러 반환하면 되지 않나?” 하지만 실제로 구현하면서 마주치는 질문들은 훨씬 복잡했습니다.

• PG가 응답을 안 주면? → 타임아웃까지 스레드가 묶임
• 응답은 왔는데 타임아웃으로 처리되면? → 결제는 됐는데 우리는 실패로 인식
• 콜백이 유실되면? → 주문이 영원히 “결제 대기중”
• 콜백과 스케줄러가 같은 주문을 동시에 처리하면? → 재고 이중 복구
• PG가 장애인데 계속 요청을 보내야 하나? → 장애를 악화시킴

이 글에서는 Spring Boot + OpenFeign + Resilience4j 환경에서 이 질문들에 하나씩 답을 찾아간 과정을 공유합니다. 화해 기술 블로그의 “내부통신에 서킷브레이커 적용하기” 글에서도 비슷한 고민과 해결 과정을 확인할 수 있습니다.

PG Simulator — 왜 가상 서비스를 만들었는가

실제 PG사(토스페이먼츠, NHN KCP 등)를 연동하면 장애 상황을 재현할 수 없습니다. “PG가 40% 확률로 실패하는 상황”을 실제 PG로 테스트할 수는 없으니까요.

그래서 PG의 핵심 동작을 시뮬레이션하는 PG Simulator를 Kotlin으로 직접 만들었습니다.

Commerce API (Java, port 8080) ←→ PG Simulator (Kotlin, port 8082)

PG Simulator는 실제 PG사의 동작을 모사합니다:

특히 40% 실패율은 의도적으로 높게 설정한 것입니다. 이 환경에서 Circuit Breaker, Retry, Fallback이 정상 동작하면, 실제 PG(실패율 1% 미만)에서는 더 안정적으로 동작할 것이라는 판단입니다.

이후 글에서 “PG”라고 표현하는 것은 모두 이 PG Simulator를 의미합니다. 실제 PG사 연동 시에는 인증(API Key), 서명 검증, 멱등키 등 추가 고려 사항이 있습니다.

0장. Resilience4j — 외부 서비스 장애에 대비하는 도구 상자

왜 Resilience4j인가?

장애 전파를 막기 위한 패턴으로 가장 유명한 것이 Netflix의 Hystrix입니다. 하지만 Hystrix는 2018년에 유지보수 모드에 들어갔고, Netflix 스스로 Resilience4j를 대안으로 권장합니다.

Resilience4j는 경량이고 Spring Boot와의 통합이 깔끔합니다. 어노테이션 하나(@CircuitBreaker, @Retry)로 적용할 수 있고, yaml로 설정을 외부화할 수 있어 운영 중 튜닝이 용이합니다.

Sliding Window — 장애를 어떻게 감지하는가?

Circuit Breaker가 “장애 상태”를 판단하려면 최근 요청의 성공/실패를 추적해야 합니다. 이를 위해 슬라이딩 윈도우(Sliding Window) 알고리즘을 사용합니다.

Resilience4j는 두 가지 방식을 제공합니다:

화해 기술 블로그에서는 실시간 트래픽 관찰이 적합하다고 판단하여 Time-Based를 선택했습니다. 저는 PG Simulator 환경에서 트래픽이 일정하지 않으므로 Count-Based(최근 10건 기준)를 선택했습니다. 10건이면 정상 거절률(~30%)과 시스템 장애를 구분하기에 충분한 샘플입니다.

Sliding Window에 대한 자세한 설명은 Resilience4j 공식 문서 - CircuitBreaker에서 확인할 수 있습니다.

이제 Resilience4j의 핵심 패턴 3가지를 설명하고, 이후 장에서 이것들을 실전에 적용하면서 어떤 문제를 만났고 어떻게 해결했는지 이야기합니다.

Retry — 실패하면 다시 시도한다

네트워크는 완벽하지 않습니다. 일시적인 패킷 유실, 서버의 순간적인 과부하 등으로 요청이 실패할 수 있습니다. 이런 일시적 장애는 다시 시도하면 성공하는 경우가 많습니다.

1회차: PG 호출 → 타임아웃 ❌
       500ms 대기
2회차: PG 호출 → 타임아웃 ❌
       1000ms 대기 (Exponential Backoff: 대기 시간이 2배씩 증가)
3회차: PG 호출 → 성공 ✅

Spring에서는 어노테이션 하나로 적용할 수 있습니다.

@Retry(name = "pg-simulator")
public PaymentResult requestPayment(...) {
    return pgClient.createPayment(request);
}

# application.yml
resilience4j:
  retry:
    instances:
      pg-simulator:
        max-attempts: 3                      # 최대 3회 시도
        wait-duration: 500ms                 # 초기 대기 500ms
        enable-exponential-backoff: true     # 점진적 증가
        exponential-backoff-multiplier: 2    # 500ms → 1s → 2s

하지만 재시도는 만능이 아닙니다. PG가 완전히 죽은 상태라면 아무리 재시도해도 실패합니다. 오히려 이미 과부하인 PG에 요청을 더 보내서 상황을 악화시킵니다. 그래서 Circuit Breaker가 필요합니다.

Circuit Breaker — 장애가 퍼지지 않도록 차단한다

전기의 차단기(두꺼비집) 를 생각하면 됩니다. 과전류가 흐르면 차단기가 내려가서 전기를 끊습니다. 불편하지만 화재를 막습니다.

소프트웨어에서도 같은 상황이 발생합니다:

Circuit Breaker가 없으면:
PG 장애 → 모든 요청이 5초씩 타임아웃 대기 → 스레드 풀 고갈 → 우리 서버도 장애 💥

Circuit Breaker가 있으면:
PG 장애 → 실패율 50% 초과 감지 → PG 호출 차단 → 즉시 Fallback 응답 → 우리 서버는 정상 ✅

3가지 상태를 순환합니다:

• Closed: 정상. 모든 요청이 PG로 전달됩니다.
• Open: 장애 감지. PG를 호출하지 않고 즉시 Fallback을 실행합니다. PG에 복구 시간을 줍니다.
• Half-Open: 대기 시간 후, 소수의 요청만 PG에 보내서 복구 여부를 확인합니다.

@CircuitBreaker(name = "pg-simulator", fallbackMethod = "requestPaymentFallback")
@Retry(name = "pg-simulator")
public PaymentResult requestPayment(...) {
    return pgClient.createPayment(request);
}

resilience4j:
  circuitbreaker:
    instances:
      pg-simulator:
        sliding-window-size: 10              # 최근 10건 기준
        failure-rate-threshold: 50           # 실패율 50% 초과 시 Open
        wait-duration-in-open-state: 5s      # Open 후 5초 대기
        permitted-number-of-calls-in-half-open-state: 3  # 3건만 시험

Retry와 Circuit Breaker의 실행 순서:

요청 → [Circuit Breaker] → [Retry] → 실제 PG 호출

CircuitBreaker [
    Retry [
        PG 호출 → 실패 → 재시도 → 실패 → 재시도 → 실패
    ] → Retry 소진 → 최종 실패
] → CircuitBreaker가 실패 1건으로 기록 → 누적 실패율 계산

중요한 점은 Retry가 모두 소진된 후의 최종 결과만 Circuit Breaker에 기록된다는 것입니다. 1회차 실패 후 2회차에 성공했다면, Circuit Breaker에는 “성공”으로 기록됩니다. 일시적 장애는 Retry가 처리하고, 지속적 장애만 Circuit Breaker가 감지하는 구조입니다.

Fallback — 실패해도 사용자에게 의미 있는 응답을 준다

Circuit Breaker가 Open이거나 Retry가 모두 실패하면, 원래 로직 대신 실행되는 대체 로직입니다.

// 원래 로직: PG에 결제 요청
@CircuitBreaker(name = "pg-simulator", fallbackMethod = "requestPaymentFallback")
public PaymentResult requestPayment(...) {
    return pgClient.createPayment(request);  // PG 장애 시 실패
}

// Fallback: PG 장애 시 실행
private PaymentResult requestPaymentFallback(..., Exception e) {
    // 500 에러 대신 "결제 처리 중"을 반환
    return new PaymentResult(null, PENDING, "결제 처리 중");
}

Fallback의 핵심은 “실패를 사용자에게 그대로 보여주지 않는 것”입니다. “서버 오류입니다”(500) 대신 “결제 처리 중입니다”라고 응답하면, 나중에 콜백이나 스케줄러가 실제 결과를 보정할 수 있습니다.

Fallback 전략은 도메인마다 다릅니다:

세 가지 패턴을 조합하면

사용자 결제 요청
  │
  ▼
[Retry] 일시적 장애 → 재시도로 복구 시도 (500ms → 1s → 2s)
  │
  ▼ (Retry 소진)
[Circuit Breaker] 지속적 장애 → PG 호출 차단, 장애 전파 방지
  │
  ▼ (Open 상태)
[Fallback] 사용자에게 "결제 처리 중" 응답 → 콜백/스케줄러가 나중에 보정

이론은 깔끔합니다. 하지만 실제로 적용하면서 “이론대로 안 되는 지점”들을 만났습니다. 다음 장부터 그 이야기를 합니다.

1장. 전체 구조 — 왜 3중 방어인가

결제 흐름 설계

PG 연동의 핵심은 “요청은 동기, 처리는 비동기”라는 점입니다.

[사용자] → POST /payments → [Commerce API] → POST /payments → [PG]
                                                                 ↓
                                                          비동기 결제 처리
                                                          (승인/거절 판정)
                                                                 ↓
[사용자] ← 200 OK ← [Commerce API] ← POST /callback ← [PG]

사용자가 결제 요청을 보내면 PG는 “접수했다”는 응답만 줍니다. 실제 승인/거절은 비동기로 처리되고, 결과는 콜백으로 전달됩니다.

여기서 문제가 생깁니다. 콜백이 유실되면? PG가 장애면? 이를 대비해 3중 방어 구조를 설계했습니다.

단일 방어 수단은 각각 실패할 수 있습니다:

3중 방어를 조합하면 각 계층의 약점을 다른 계층이 보완합니다.

2장. 첫 번째 시행착오 — “멱등성 가드면 충분하지 않나?”

처음 작성한 코드

주문의 결제 상태를 업데이트하는 코드를 처음 이렇게 작성했습니다.

public void failPayment(Long orderId) {
    Order order = orderRepository.findById(orderId)  // 일반 SELECT
            .orElseThrow(() -> new CoreException(ErrorType.ORDER_NOT_FOUND));

    if (order.getStatus() != OrderStatus.PAYMENT_PENDING) {
        return;  // 멱등성 가드: 이미 처리된 주문은 무시
    }

    Order failed = order.failPayment();
    orderRepository.save(failed);
    eventPublisher.publishEvents(failed);  // OrderCancelledEvent → 재고 복구
}

논리적으로는 완벽해 보입니다. PAYMENT_PENDING이 아니면 return하니까, 두 번 호출해도 안전하겠죠?

동시성 테스트에서 터진 버그

“5건의 동시 실패 콜백” 테스트를 작성했습니다. 재고가 15개인 상품에 대해 5개를 주문하고, 결제 실패 시 5개가 복구되어 20개가 되어야 합니다.

// 기대: 재고 15 + 복구 5 = 20
// 실제: 재고 15 + 복구 10 = 25  💥

재고가 25개가 됐습니다. 재고 복구가 2번 실행된 것입니다.

원인 분석

Thread A: findById(1) → PAYMENT_PENDING 읽음
Thread B: findById(1) → PAYMENT_PENDING 읽음  ← 같은 시점에 같은 상태!

Thread A: status != PENDING? → false → failPayment() → 재고 복구 ①
Thread B: status != PENDING? → false → failPayment() → 재고 복구 ②  💥

findById()는 일반 SELECT입니다. 두 스레드가 동시에 실행하면 둘 다 PAYMENT_PENDING을 봅니다. 멱등성 가드는 메모리에서만 동작하기 때문에 DB 레벨의 동시성을 제어하지 못합니다.

해결: 비관적 락

public void failPayment(Long orderId) {
    // SELECT FOR UPDATE → 행 수준 락 획득
    Order order = orderRepository.findByIdWithLock(orderId)
            .orElseThrow(() -> new CoreException(ErrorType.ORDER_NOT_FOUND));

    if (order.getStatus() != OrderStatus.PAYMENT_PENDING) {
        return;  // 이제 진짜 안전한 멱등성 가드
    }

    Order failed = order.failPayment();
    orderRepository.save(failed);
    eventPublisher.publishEvents(failed);
}

Thread A: findByIdWithLock(1) → PENDING 읽음 + 행 락 🔒
Thread B: findByIdWithLock(1) → 대기...
Thread A: failPayment() → FAILED 저장 + 재고 복구 → 커밋 → 락 해제
Thread B: findByIdWithLock(1) → FAILED 읽음 (커밋된 최신 데이터)
Thread B: status != PENDING → return ✅

배운 것

멱등성 가드는 “논리적 방어”일 뿐, DB 레벨 동시성 제어(SELECT FOR UPDATE)와 함께 써야 실제로 동작합니다.

단일 스레드에서 테스트하면 절대 발견할 수 없는 버그입니다. 결제처럼 “실패하면 돈이 안 맞는” 도메인에서는 반드시 동시성 테스트를 작성해야 합니다.

3장. 두 번째 시행착오 — Circuit Breaker 대기 시간

30초의 함정

Circuit Breaker의 wait-duration-in-open-state를 처음에 30초로 설정했습니다. Resilience4j 공식 문서의 예제가 60초였으니 절반인 30초면 적당하다고 생각했습니다.

wait-duration-in-open-state: 30s

하지만 결제 도메인의 특성을 간과했습니다.

사용자 관점에서 생각해보기

PG 장애가 발생하면 이런 일이 벌어집니다.

10:00:00 - 결제 실패율 50% 초과 → Circuit Open
10:00:00 ~ 10:00:30 - 모든 결제 요청이 Fallback으로 빠짐
                       사용자에게 "결제 처리 중" 메시지만 30초간 노출
10:00:30 - Half-Open → 3건 시험 → 성공 → Closed

30초 동안 모든 사용자가 결제를 할 수 없습니다. 쇼핑몰에서 30초는 사용자가 결제를 포기하고 다른 플랫폼으로 이동하기 충분한 시간입니다.

5초로 변경한 이유

결정적인 이유는 콜백 + 스케줄러라는 보조 수단이 있기 때문입니다. Circuit Breaker가 5초 후에 빠르게 닫혀서 PG에 요청을 보내도, 설령 다시 실패하더라도 콜백과 스케줄러가 최종적으로 상태를 보정합니다.

Circuit Breaker는 “PG를 보호하기 위한 장치”이지만, 결제 도메인에서는 “사용자를 보호하는 것”이 더 중요합니다.

4장. 세 번째 시행착오 — Retry 전략

고정 간격의 문제

# 처음 설정
max-attempts: 2
wait-duration: 1s  # 고정 간격

코드 자체는 문제없이 동작합니다. 하지만 서버가 여러 대일 때를 생각해보면:

10:00:00.000 - 서버 A: PG 호출 실패
10:00:00.005 - 서버 B: PG 호출 실패
10:00:00.010 - 서버 C: PG 호출 실패

10:00:01.000 - 서버 A: 재시도 ← 동시!
10:00:01.005 - 서버 B: 재시도 ← 동시!
10:00:01.010 - 서버 C: 재시도 ← 동시!

모든 서버가 정확히 1초 후에 동시에 재시도합니다. PG가 과부하 상태인데 여러 서버가 같은 타이밍에 몰려오면 상황이 악화됩니다. 이를 Thundering Herd 문제라고 합니다.

Exponential Backoff로 변경

max-attempts: 3
wait-duration: 500ms
enable-exponential-backoff: true
exponential-backoff-multiplier: 2
# 1회차: 500ms 대기 → 2회차: 1s 대기 → 3회차: 바로 실행

점진적으로 대기 시간을 늘려서 PG에 복구 시간을 줍니다. 완벽한 해결은 아닙니다. Jitter(랜덤 지연)를 추가하면 서버 간 재시도 타이밍을 분산할 수 있지만, 현재 Resilience4j 설정으로는 기본 Exponential Backoff까지만 적용 가능합니다.

Exponential Backoff와 Jitter 전략의 비교 분석은 AWS Architecture Blog - Exponential Backoff And Jitter에서 그래프와 함께 자세히 확인할 수 있습니다.

왜 3회인가?

결제 도메인에서 재시도 횟수를 보수적으로 잡는 이유가 있습니다.

PG가 실제로는 결제를 승인했는데 응답만 타임아웃으로 실패한 경우를 생각해보세요. 클라이언트(우리)는 실패로 판단하고 재시도합니다. PG에 멱등키(idempotency key)가 없으면 같은 카드로 같은 금액이 두 번 결제됩니다.

[Commerce API] → POST /payments (orderId=1, amount=50000) → [PG: 승인 ✅]
                ← 타임아웃 (응답 유실)
[Commerce API] → POST /payments (orderId=1, amount=50000) → [PG: 또 승인 ✅]  💥

이중 결제는 사용자 신뢰를 완전히 무너뜨리는 사고입니다. 재시도는 최소한으로 하되, 콜백과 스케줄러로 보정하는 전략이 더 안전합니다.

5장. Fallback의 구조적 모순

모순을 알면서도 남겨둔 이유

private PaymentResult requestPaymentFallback(UserId userId, PaymentCommand command, Exception e) {
    try {
        // Circuit Breaker가 열린 이유가 PG 장애인데... 또 PG를 호출?
        return toPaymentResult(getPaymentStatus(userId, command.orderId()));
    } catch (Exception ex) {
        return new PaymentResult(null, PaymentStatus.PENDING, "PG 일시적 장애로 결제 대기 중");
    }
}

PG 장애로 Circuit이 열렸는데, Fallback에서 같은 PG의 조회 API를 호출합니다. 모순입니다.

그래도 유지한 이유:

PG 내부적으로 결제 생성(POST /payments)과 조회(GET /payments)는 다른 시스템일 수 있습니다.

최악의 추가 비용은 read-timeout(5초) 1회입니다. 전면 장애 시에도 두 번째 catch에서 안전하게 PENDING을 반환하므로, 시도할 가치가 있다고 판단했습니다.

개선 방향:

조회 API에 별도 Circuit Breaker(pg-simulator-query)를 적용하면 전면 장애 시 즉시 Fallback으로 빠질 수 있습니다. 또는 Fallback에서 PG 재호출을 아예 제거하고 즉시 PENDING을 반환하는 방식도 있습니다. 어느 쪽이 맞는지는 실제 PG의 장애 패턴(부분 장애 빈도)에 따라 달라집니다.

6장. 설정값에는 근거가 있어야 한다

“왜 이 숫자인가?”라는 질문에 “다른 데서 이렇게 하길래”는 좋은 답이 아닙니다.

Circuit Breaker

sliding-window-size: 10
failure-rate-threshold: 50

왜 10건, 50%인가?

PG Simulator의 정상 거절률을 먼저 계산합니다.

• 한도 초과: 20%
• 카드 오류: 10%
• 정상 거절률: ~30%

10건 중 3건은 정상적인 거절입니다. 임계치를 30%로 설정하면 정상 상태에서도 Circuit이 열립니다. 50%로 설정하면 10건 중 5건 초과(6건 이상)가 실패해야 열리므로, 정상 거절과 시스템 장애를 구분할 수 있습니다.

정상 상태: 10건 중 3건 실패 (30%) → Closed ✅
시스템 장애: 10건 중 7건 실패 (70%) → Open ✅
경계 구간: 10건 중 5건 실패 (50%) → Closed (여유분)

운영 환경에서 바꿔야 할 것:

• TPS가 높으면 sliding-window-size를 키워야 합니다. 10건은 TPS 1~10 수준에서 적합합니다.
• 실제 PG의 거절률을 모니터링한 후 failure-rate-threshold를 (거절률 + 15%) 정도로 조정해야 합니다.

스케줄러

fixedDelay: 300_000  # 5분
BATCH_SIZE: 100
PENDING_THRESHOLD: 5분

왜 5분 주기인가?

콜백이 주된 복구 수단입니다. PG가 정상이면 콜백은 1분 내에 도착합니다. 5분은 “콜백이 정말 유실되었다”를 확인하기 충분한 시간입니다. 1분 주기는 콜백이 아직 도착 중인 건을 불필요하게 PG에 재조회하게 됩니다.

왜 100건 배치인가?

스케줄러가 PG 조회 API를 호출합니다. 100건 × read-timeout(5초) = 최악 8분 20초. 스케줄러 주기(5분)와 겹칠 수 있지만, fixedDelay(이전 실행 완료 후 5분)이므로 겹치지 않습니다.

fixedRate:  |--실행--|--5분--|--실행--|  ← 이전 실행이 끝나지 않으면 겹침
fixedDelay: |--실행--|--5분--|--실행--|  ← 이전 실행 완료 후 5분 대기

무제한 조회는 PENDING 주문이 수만 건일 때 메모리와 PG 부하를 유발하므로 100건으로 제한했습니다.

7장. 코드 리뷰에서 배운 것들

PR 제출 후 코드 리뷰에서 12건의 문제가 발견되었습니다. 처음에 “이 정도면 충분하다”고 생각했지만, 리뷰를 통해 운영 관점에서의 빈틈을 많이 발견했습니다.

“이건 진짜 위험했다” — Critical

동시성 경합으로 재고 이중 복구 (2장에서 설명)

이건 코드 리뷰가 아니라 동시성 테스트에서 발견했습니다. 만약 테스트 없이 배포했다면 사용자의 돈이 안 맞는 사고가 발생했을 것입니다.

“모르고 있었다” — Major

@RequestAttribute 속성 이름 미지정

// AS-IS: 기본값 "userId"를 찾음 → 인터셉터가 설정한 "authenticatedUserId"와 불일치
public ResponseEntity<Void> createOrder(@RequestAttribute UserId userId, ...)

// TO-BE
public ResponseEntity<Void> createOrder(@RequestAttribute("authenticatedUserId") UserId userId, ...)

인터셉터에서 request.setAttribute("authenticatedUserId", ...)로 설정하는데, @RequestAttribute에 이름을 생략하면 파라미터명(userId)으로 찾습니다. createOrder만 이 방식이고, 다른 메서드들은 request.getAttribute("authenticatedUserId")로 직접 꺼내서 문제가 없었습니다. 같은 컨트롤러 안에서 두 가지 방식이 섞여있는 것이 근본 원인입니다.

결제 상태를 String으로 관리

// AS-IS: 오타 한 글자로 결제가 틀어짐
if ("SUCESS".equals(command.status())) {  // SUCCESS 오타 → 절대 true가 안 됨
    updateOrderPaymentUseCase.completePayment(orderId);
}

// TO-BE: 컴파일 타임에 잡힘
switch (command.status()) {
    case SUCCESS -> updateOrderPaymentUseCase.completePayment(orderId);
    case FAILED -> updateOrderPaymentUseCase.failPayment(orderId);
    case PENDING -> { }
}

PaymentStatus enum을 만들고, 컨트롤러 경계에서 PaymentStatus.from(String)으로 파싱하도록 변경했습니다. 잘못된 상태값이 들어오면 서비스 내부가 아니라 컨트롤러에서 즉시 VALIDATION_ERROR를 반환합니다.

“운영에서 터질 뻔했다” — 보안/운영

카드번호 로그 노출

Java의 record는 기본 toString()이 모든 필드를 출력합니다. 장애 분석 중 로그를 그대로 남기면 카드번호가 평문으로 노출됩니다.

// record 기본 toString()
// "CreatePayment[orderId=1, cardType=VISA, cardNo=1234-5678-9012-3456, ...]"

// 오버라이드 후
// "CreatePayment[orderId=1, cardType=VISA, cardNo=****-****-****-3456, ...]"

PG 장애를 500으로 분류

// AS-IS: PG 장애 = 내부 서버 오류? → 알림 폭주, 원인 분리 불가
PAYMENT_REQUEST_FAILED(HttpStatus.INTERNAL_SERVER_ERROR, ...)

// TO-BE: 외부 서비스 장애는 502
PAYMENT_REQUEST_FAILED(HttpStatus.BAD_GATEWAY, ...)

운영 환경에서 500과 502를 분리하면 “우리 코드 문제 vs 외부 PG 문제”를 대시보드에서 즉시 구분할 수 있습니다.

8장. 아직 해결하지 못한 문제

완벽한 코드는 없습니다. 의도적으로 미적용한 부분과 그 이유를 솔직하게 남깁니다.

콜백 엔드포인트에 인증이 없다

@PostMapping("/callback")
public ResponseEntity<Void> handleCallback(@RequestBody CallbackRequest request) {
    // 누구나 호출 가능 — 결제 없이 주문 완료 가능 💥
}

공격자가 {"orderId": "1", "status": "SUCCESS"}를 보내면 결제 없이 주문이 완료됩니다. 운영 환경에서는 HMAC 서명 검증 또는 IP 화이트리스트가 필수입니다.

결제 이력이 Commerce API에 없다

현재 결제 정보(transactionKey, 카드번호, 금액)는 PG에만 저장됩니다. PG가 장애나면 결제 이력 조회가 불가능합니다. 운영 환경에서는 Commerce API에 Payment 엔티티를 추가하여 로컬에 결제 이력을 저장해야 합니다.

스케줄러 다중 인스턴스 중복 실행

@Scheduled는 서버가 여러 대일 때 모든 인스턴스에서 동시에 실행됩니다. 비관적 락 덕분에 정합성은 보장되지만, 불필요한 PG 호출과 DB 락 경합이 발생합니다. ShedLock(Redis 분산 락)으로 단일 인스턴스만 실행되도록 해야 합니다.

9장. 동시성 테스트 — 무엇을 증명했는가

“테스트 5종 통과”보다 중요한 것은 각 테스트가 무엇을 증명하는지입니다.

4번 테스트가 가장 중요합니다. 이 테스트가 없었다면 2장의 버그를 발견하지 못했을 것입니다.

마치며

결제 코드의 체크리스트

이번 경험을 통해 결제 도메인 코드를 작성할 때 반드시 확인해야 할 체크리스트를 정리했습니다.

동시성

• 상태 변경에 DB 레벨 락이 적용되어 있는가? (멱등성 가드만으로는 부족)
• 동시성 테스트를 작성했는가? (단일 스레드 테스트로는 발견 불가)

장애 복원력

• 외부 서비스 호출에 타임아웃이 설정되어 있는가?
• Circuit Breaker 설정값에 근거가 있는가? (정상 거절률 기반)
• Fallback이 또 다른 장애 지점이 되지 않는가?
• 모든 경로가 실패해도 사용자에게 의미 있는 응답을 반환하는가?

보안

• 카드번호가 로그에 평문으로 노출되지 않는가?
• 콜백 엔드포인트에 인증/검증이 있는가?
• 외부 입력값이 서비스 내부까지 검증 없이 전파되지 않는가?

운영

• 내부 오류(500)와 외부 장애(502)가 분리되어 있는가?
• 스케줄러가 다중 인스턴스 환경에서 안전한가?
• 설정값(Circuit Breaker, Retry, 스케줄러 주기)을 모니터링 기반으로 튜닝할 준비가 되어 있는가?

두려움의 원인은 검증 부족이었다

처음 결제 연동을 시작할 때 막연한 두려움이 있었습니다. “외부 서비스와 통신하는 코드를 내가 잘 짤 수 있을까?”, “장애 나면 어떡하지?”

화해 기술 블로그에서 비슷한 이야기를 읽었습니다.

“막연한 두려움을 가졌던 이유는 근거와 더불어 검증이 충분하지 않기 때문이라 느꼈습니다.”

돌이켜보면 맞는 말입니다. 두려움이 줄어든 시점은 코드를 완성했을 때가 아니라, 동시성 테스트에서 재고 이중 복구 버그를 발견하고 고쳤을 때였습니다. “이 테스트가 통과하면 최소한 돈은 맞는다”는 확신이 생기니 배포가 무섭지 않았습니다.

설정값도 마찬가지입니다. Circuit Breaker의 wait-duration을 30초에서 5초로 바꿀 때, “5초면 너무 짧지 않나?”라는 불안감이 있었습니다. 하지만 “콜백 + 스케줄러가 보조 수단이므로 Circuit Breaker가 빨리 닫혀도 최종 정합성은 보장된다”는 근거를 세우니 확신이 생겼습니다.

근거 없는 설정은 불안하고, 검증 없는 코드는 두렵습니다. 결제처럼 “실패하면 돈이 안 맞는” 도메인에서는 코드를 작성하는 시간보다 검증하는 시간이 더 중요하다는 것을 배웠습니다.

물론 이 프로젝트는 PG Simulator라는 가상 서비스를 만들어 연동한 것이므로, 실제 PG사 연동과는 차이가 있습니다. 실제 운영에서는 PG사의 API 인증, 서명 검증, 멱등키, 정산 연동 등 훨씬 더 많은 고려 사항이 존재합니다. 하지만 장애 복원력의 핵심 패턴(Circuit Breaker, Retry, Fallback)과 동시성 안전의 원칙은 가상 서비스든 실제 서비스든 동일합니다. 이 경험이 실제 PG 연동을 앞둔 분들에게 기초 체력이 되길 바랍니다.

긴 글 읽어주셔서 감사합니다.

참고 자료

• Martin Fowler - Circuit Breaker Pattern
• Resilience4j 공식 문서
• 화해 기술 블로그 - 내부통신에 서킷브레이커 적용하기

10만건 상품 데이터 기반 조회 성능 개선기 — 인덱스, 비정규화, 캐시를 순서대로 적용하며 배운 것들

왜 이 글을 쓰게 되었는가

살다 보면 뭘 하든 뭔가를 포기해야 한다. 점심 메뉴를 고를 때도, 이직을 결정할 때도. 코드도 별반 다를 게 없었다.

4주차까지 좋아요 수 기반 정렬, 브랜드 필터링, 인기 상품 조회를 만들고 나서 궁금해졌다. “데이터가 10만건이면 어떻게 되지?” EXPLAIN ANALYZE를 돌려보니 모든 쿼리가 Seq Scan이었다. 10ms 넘는 쿼리들이 줄줄이 나왔다.

문제를 찾고 나서 바로 답이 나오진 않았다. 인덱스를 걸까? 캐시를 넣을까? 비정규화를 할까? 셋 다 “성능 개선”이라는 같은 목표인데, 각각 잃는 게 달랐다.

문제 발견 — 고민의 시작

내가 마주한 병목은 세 가지였다.

문제를 나열하고 나니 다음 고민이 찾아왔다. 뭐부터 해야 하지?

이전 회사 솔루션으로 MAU 900만 은행 서비스를 운영할 때는, 로그인과 송금/결제 응답을 1초 이내로 줘야 해서 바로 Redis 캐싱을 도입했었다. 또한 하드웨어적으로 너무나도 빵빵해서 일반적으로 서비스회사들의 대용량 트래픽 처리하는 방식과는 거리감이 있었다.
하지만 이커머스에서 점진적으로 성장하는 단계에, 상품 10만건이 쌓였다고 바로 Redis를 쓰는 게 맞을까?

극초기 스타트업이 홍보가 잘되어서 갑자기 상품이 쏟아진 상황을 상상해봤다. 시간이 급하면 캐싱부터 때리는 게 빠른 선택일 수 있다.
하지만 시간이 있다면? 쿼리 성능부터 잡는 게 나중에 발목 안 잡히는 방법이라고 생각했다.

실무에서는 보통 slow query log를 켜놓고 문제가 되는 쿼리부터 잡아간다. PostgreSQL은 log_min_duration_statement를 설정하면 지정 시간(예: 500ms) 이상 걸린 쿼리를 전부 기록해준다. MySQL도 slow_query_log = ON으로 같은 걸 할 수 있다. 운영 중인 서비스라면 이 로그를 보고 인덱스를 보완해나가는 형태로 접근하는 게 일반적이다. 처음부터 완벽하게 인덱스를 설계하는 게 아니라, 느린 쿼리가 잡히면 그때 대응하는 거다.

결국 내가 내린 판단 기준은 이거였다.

비용이 적은 것부터 하자. 인덱스 → 비정규화 → 캐시.

길부터 닦고(인덱스), 짐을 줄이고(비정규화), 그래도 부족하면 지름길을 뚫자(캐시).

Step 1: 인덱스 — 길부터 닦자

인덱스가 뭔지 잠깐 짚고 가자

인덱스는 데이터의 위치 정보를 따로 저장해두는 거다. 책의 목차처럼 원하는 데이터가 어디 있는지 바로 찾아갈 수 있게 해준다.

인덱스가 없으면? 테이블 처음부터 끝까지 순서대로 훑어야 한다(Seq Scan). 데이터가 100건이면 상관없는데, 10만건이 되면 매번 전부 읽는 비용이 느껴지기 시작한다. 참고로 스펙이 좋아도 3만건 이상의 데이터에서 필요 없는 행까지 풀스캔하면 느릴 수밖에 없다.

복합 인덱스는 여러 컬럼을 하나의 인덱스로 묶는 건데, 여기서 컬럼 순서가 중요하다. 인덱스는 지정한 순서대로 정렬되어 있어서, 순서에 따라 타는 범위가 달라진다.

일반적으로 인덱스 컬럼 순서는 이렇게 잡는다:

1. = (등호) 조건 컬럼 → 먼저
2. range (>, <, BETWEEN) 조건 컬럼 → 다음
3. ORDER BY 컬럼 → 마지막

range 조건이 앞에 오면 그 뒤 컬럼은 인덱스를 제대로 못 탄다. 그래서 범위 비교는 뒤로 빼는 게 낫다.

그리고 인덱스에는 읽기와 쓰기의 트레이드오프가 있다. 인덱스를 걸수록 조회는 빨라지지만, INSERT/UPDATE/DELETE 때마다 인덱스도 같이 갱신해야 해서 쓰기가 느려진다. 둘 다 빠르게 만드는 건 불가능하다. 그래서 조회가 빈번한 곳에만 건다.

실무에서 인덱스 개수는 테이블 성격에 따라 다르다:

참고로 토스 같은 곳은 한 테이블에 컬럼이 40개 가까이 되는 경우도 있다고 한다. 그만큼 인덱스 설계가 복잡해진다.

인덱스 설계가 어려운 이유

인덱스 설계가 단순히 “이 컬럼에 걸까 말까” 수준이면 좋겠는데, 실제로는 그렇지 않다. 복합 인덱스에서는 컬럼의 조합뿐 아니라 순서가 성능을 결정한다.

에어비앤비가 VLDB 2025에 발표한 논문(Sam Lightstone, Ping Wang)에서 재밌는 수치를 봤다. 테이블이 12개이고 각 테이블에 인덱싱 가능한 컬럼이 10개만 있어도, 가능한 인덱스 조합의 수는 약 10^84개라고 한다. 관측 가능한 우주의 원자 수가 약 10^80개니까, 그걸 넘는 숫자다.
에어비앤비는 이 문제를 풀기 위해 SQL:Trek이라는 자동 인덱스 설계 도구를 만들었다. 프로덕션 DB를 건드리지 않고 5% 샘플링한 시뮬레이션 DB에서 후보 인덱스를 실제로 생성하고 EXPLAIN으로 평가하는 방식인데, 특정 워크로드에서 50,000배 성능 개선을 끌어냈다고 한다.

물론 내 프로젝트에서 10^84개의 조합을 고민할 일은 없다. 하지만 “인덱스는 그냥 걸면 되는 거 아니야?”라고 생각했던 내게,
이게 왜 엔지니어링인지 느끼게 해준 글이었다.
테이블 4개에 인덱스 4개 거는 것만으로도 선택도, 컬럼 순서, 쓰기 비용을 전부 따져야 했으니까.

첫 번째 시도: 일반 복합 인덱스

먼저 떠오른 건 일반 복합 인덱스였다. (deleted_at, brand_id, like_count) 같은 조합으로 걸면 되지 않을까?

EXPLAIN ANALYZE를 돌려봤다. 여전히 Seq Scan.

원인은 deleted_at IS NULL의 선택도였다. 전체 데이터의 95%가 활성 상태(deleted_at이 NULL)라서 플래너가 “어차피 거의 다 읽어야 하니 인덱스 안 타는 게 낫겠다”고 판단한 것이다.

여기서 Covering Index도 고려해봤다. 조회에 필요한 컬럼을 전부 인덱스 노드에 포함시키면, 테이블까지 갔다올 필요 없이 인덱스만으로 결과를 돌려줄 수 있다. 조회 비용을 극단적으로 낮춰야 할 때 쓰는 방법인데, 이번 케이스에서는 Partial Index로 충분했기 때문에 적용하지 않았다.
참고로 에어비앤비의 SQL:Trek도 Covering Index를 안티패턴으로 분류한다. 특정 쿼리에는 최적이지만 테이블 전체 스토리지가 두 배 가까이 늘고 쓰기 비용이 커져서, 워크로드 전체로 보면 손해인 경우가 많다는 이유다.

두 번째 시도: Partial Index

WHERE deleted_at IS NULL 조건을 인덱스 자체에 넣는 Partial Index를 적용했다.

CREATE INDEX idx_products_active_brand_likes
    ON products (brand_id, like_count DESC)
    WHERE deleted_at IS NULL;

결과:

다만 JPA의 @Index는 Partial Index의 WHERE 절을 지원하지 않는다. SQL 마이그레이션 스크립트로 따로 관리해야 했다. JPA 편의성을 포기하고 20~131배 성능을 가져갔다.

배운 점: 인덱스를 걸었는데 안 탈 수 있다. 플래너가 왜 그런 판단을 하는지(선택도)를 모르면 인덱스를 걸어놓고도 Seq Scan에 머문다. 실무에서도 인덱스를 처음부터 완벽하게 잡기보다, slow query log로 느린 쿼리를 잡아가며 조정해나가는 게 현실적인 접근이다.

Step 2: 비정규화 — 짐을 줄이자

인덱스로 조회는 해결했는데, 좋아요 쪽에 다른 문제가 있었다.

기존 방식의 문제

기존 좋아요 처리는 이랬다:

1. SELECT FOR UPDATE (Product 전체 조회 + 비관적 락)
2. 메모리에서 likeCount + 1
3. UPDATE (Product 모든 컬럼 저장)

이게 왜 문제냐면, 어드민이 동시에 상품 정보(이름, 가격)를 수정하면 한쪽 변경이 날아간다. 좋아요가 Product 전체를 읽고 전체를 덮어쓰니까, 어드민이 바꾼 가격이 사라지는 거다. Lost Update 문제.

선택지

A. 비관적 락 유지 + 좋아요 전용 테이블 분리

• 장점: 정규화 유지
• 단점: JOIN 비용, 테이블 늘어남, 락은 여전히 필요

B. 원자적 SQL UPDATE

• 장점: 락 불필요, 다른 필드에 영향 없음, 쿼리 수 줄어듦
• 단점: like_count가 products 테이블에 비정규화

@Modifying
@Query("UPDATE ProductJpaEntity p SET p.likeCount = p.likeCount + 1 WHERE p.id = :productId")
void incrementLikeCount(@Param("productId") Long productId);

B를 골랐다. DB에서 like_count = like_count + 1을 실행하면, 어드민이 상품명을 바꾸든 가격을 바꾸든 likeCount 컬럼에만 영향이 간다. 락도 필요 없어졌다.

like_count를 products 테이블에 두는 비정규화를 받아들이고, 동시성 안전과 성능을 둘 다 가져갔다. 정규화가 깔끔하긴 하지만 실제로 터지는 문제 앞에서는 실용적인 쪽을 택했다.

더 큰 트래픽이라면?

지금은 원자적 UPDATE로 충분하지만, 트래픽이 훨씬 커지면 다른 방법도 있다.

Sharded Counter 방식이 그중 하나다. 하나의 카운터 row에 모든 요청이 몰리면 row-level lock 경합이 생기는데, 카운터를 여러 조각(shard)으로 나누면 동시 처리 성능을 높일 수 있다.

product_like_counter { product_id, shard_id, count }

shard 0: count = 42
shard 1: count = 38
shard 2: count = 45
→ 총 좋아요 수 = SUM(count) = 125

쓰기 시에는 랜덤 shard에 UPDATE하고, 읽기 시에는 SUM으로 합산한다. Redis를 쓸 수 있는 환경이면 Redis에서 카운트를 모아두는 것도 방법이다. 서버가 날아가도 Redis에 남아있으니까.

또 하나는 Materialized View 같은 접근인데, 이건 스냅샷이라기보다 read model에 가깝다. 이벤트로 비동기적으로 조회용 테이블을 만들어두는 방식이다. CQRS에서 쓰는 패턴과 비슷하다.

지금 규모에서는 원자적 UPDATE가 맞지만, 이런 선택지가 있다는 걸 알아두면 나중에 대응할 때 덜 당황한다.

Step 3: 캐시 — 지름길을 뚫자

인덱스와 비정규화로 쿼리 하나하나는 빨라졌다. 그런데 같은 상품 목록을 수백 명이 동시에 요청하면? DB가 아무리 빨라도 반복 조회는 부하다.

캐시를 넣기로 했다. 근데 캐시도 종류가 있다.

로컬 캐시(Caffeine, Ehcache 등)는 애플리케이션 메모리에 데이터를 올려두는 방식이다. 네트워크를 안 타니까 빠르다. 카카오페이 기술 블로그에서 본 사례가 인상적이었는데, 카카오페이는 상품·통신사·혜택 같은 메타 정보 조회에 로컬 캐시를 쓴다. Redis까지 갔다올 필요 없이 서버 메모리에서 바로 꺼내는 거다. 대신 서버가 여러 대면 서버마다 캐시가 따로 있으니까, A 서버에선 바뀐 데이터가 B 서버에선 안 바뀌어 있는 문제가 생긴다.

글로벌 캐시(Redis)는 서버들이 하나의 캐시를 공유한다. 어느 서버에서 조회해도 같은 데이터가 나온다. 대신 매번 네트워크를 타야 한다.

나는 Redis를 골랐다. 이유는 단순하다. 이커머스에서 상품 상세 페이지는 어느 서버에서 열어도 같은 가격, 같은 좋아요 수가 보여야 한다. 서버별로 다른 값을 보여주는 건 사용자 경험 측면에서 받아들이기 어려웠다. 네트워크 비용은 있지만, 데이터 정합성을 포기하는 것보다는 낫다고 판단했다.

물론 카카오페이처럼 “변경이 거의 없는 메타 정보”라면 로컬 캐시가 더 나은 선택일 수 있다. 자주 안 바뀌니까 서버 간 불일치가 발생할 확률 자체가 낮고, 네트워크 비용을 아끼는 게 이득이다. 결국 캐시에 뭘 담느냐에 따라 답이 달라진다. 이것도 트레이드오프다.

한 가지 먼저 짚고 갈 점이 있다. 캐싱은 버전 관리가 중요하다. 상품 정보 같은 걸 캐시에만 의존하면, 실제 DB 데이터와 점점 멀어질 수 있다. 캐시는 어디까지나 “빠르게 돌려주는 복사본”이지, 원본이 아니다. 이걸 잊으면 정합성 문제가 생긴다.

고민 1: 캐시를 언제 지울 것인가

처음에는 @CacheEvict를 붙였다. 근데 이게 문제가 있었다.

@CacheEvict은 AOP 프록시에서 동작해서 트랜잭션 커밋보다 먼저 실행된다. 이런 일이 생길 수 있다:

Thread 1: 좋아요 → likeCount UPDATE (아직 미커밋)
Thread 1: 캐시 삭제 (@CacheEvict, 커밋 전 실행)
Thread 2: 캐시 조회 → MISS → DB에서 이전 값 읽음 (미커밋이니까)
Thread 2: 이전 값으로 캐시 다시 채움
Thread 1: 커밋
→ 캐시에는 이전 값이 TTL 동안 박혀있음

@TransactionalEventListener(AFTER_COMMIT) 패턴으로 바꿨다. 커밋이 끝난 다음에 캐시를 지우니까 이 문제가 없어진다.

다만 @TransactionalEventListener는 트랜잭션 없는 환경(단위 테스트)에서 안 돌아간다. isSynchronizationActive() 체크를 넣어서 트랜잭션이 없으면 바로 evict하도록 분기를 추가해야 했다.

고민 2: 좋아요 한 번에 목록 캐시를 통째로 날릴 것인가

처음에는 좋아요가 들어오면 @CacheEvict(allEntries=true)로 목록 캐시를 통째로 비웠다. 좋아요 수가 바뀌면 인기순 정렬 결과가 달라지니까 논리적으로는 맞다.

근데 트래픽이 늘면 캐시가 없을 때보다 더 느려진다.

좋아요 1회 발생
→ 목록 캐시 전체 삭제 (page 0, 1, 2, ... 모든 sort 조합)
→ 직후 수백 요청이 동시에 Cache MISS
→ 전부 DB 조회 (Cache Stampede)
→ Redis 왕복 + DB 비용 = 캐시 없을 때보다 느림

이 Cache Stampede를 막는 방법은 여러 가지가 있다. 캐시 저장 앞에 락을 걸어서 한 번에 하나의 요청만 DB를 치게 하고, 나머지는 캐시가 채워질 때까지 기다리게 하는 방법도 있다. 하지만 이번에는 더 단순하게 접근했다.

목록 캐시는 좋아요/주문 시 안 지우고 TTL 1분으로 알아서 갱신되게 했다. 상품 상세는 바로 evict해서 정확한 값을 주고, 목록의 좋아요 수는 최대 1분 늦을 수 있다.

이걸 분산 시스템에서는 Eventual Consistency라고 부른다. 각 시점에서는 데이터가 다를 수 있지만, 시간이 지나면 결국 같아진다는 거다. 카카오페이도 로컬 캐시에서 같은 판단을 했다. 서버 간 데이터 불일치를 허용하되 TTL 1시간으로 최종적으로 맞춰지게 한 거다. 그쪽은 메타 정보라 1시간이 괜찮았고, 나는 상품 목록이라 1분으로 잡았다. 숫자는 다르지만 판단의 뼈대는 같다 — “실시간 정확성 vs 시스템 안정성” 사이에서 후자를 골랐다.

“목록에서 좋아요 수가 1분 늦을 수 있다”를 받아들이고, Stampede를 막았다. 커머스에서 목록의 좋아요 수가 1분 차이 나는 건 사용자가 알기 어렵다. 근데 Stampede로 페이지가 느려지면 바로 느낀다.

고민 3: Redis가 죽으면?

캐시는 성능을 위해 얹은 거지, 핵심이 아니다. Redis가 죽었다고 서비스가 멈추면 안 된다.

SafeCacheErrorHandler를 만들어서 Redis 예외를 잡고 DB로 넘어가게 했다. 예외를 잡으면 장애를 모를 수 있어서 Micrometer 카운터(cache.errors)로 모니터링을 붙였다.

처음에는 로그에 exception.getMessage()만 남겼는데, 이러면 연결 오류인지 직렬화 오류인지 모른다. exception 자체를 넘겨서 stack trace를 남기도록 고쳤다. 대신 캐시 key는 로그에서 뺐다. key에 userId 같은 게 들어갈 수 있어서.

// AS-IS: 메시지만, key 노출
log.warn("캐시 조회 실패 - cache: {}, key: {}, error: {}", cache.getName(), key, exception.getMessage());

// TO-BE: stack trace 보존, key 제거
log.warn("캐시 조회 실패 - cache: {}", cache.getName(), exception);

로그를 자세히 남기고 싶은데 보안 때문에 못 남기는 것도 결국 트레이드오프다.

고민 4: afterCommit에서 캐시 삭제가 실패하면?

코드 리뷰에서 나온 지적이다. afterCommit() 안에서 Cache.evict()가 터지면 예외가 올라가서 클라이언트에 500이 간다. 근데 주문이랑 재고는 이미 DB에 들어간 상태다. 고객은 주문이 됐는데 에러 화면을 보는 셈이다.

CacheErrorHandler는 @CacheEvict 같은 어노테이션에만 동작하고, 직접 호출한 Cache.evict()는 안 잡아준다. 그래서 afterCommit 블록마다 try-catch를 넣었다. 캐시 실패해도 로그만 남기고 응답은 정상으로 내보낸다.

고민 5: 브랜드 삭제할 때 전체 캐시를 밀어야 하나

브랜드를 삭제하면 그 브랜드 상품들이 soft-delete된다. 처음에는 detailCache.clear()로 상품 상세 캐시를 전부 비웠다.

브랜드 A 하나 지웠을 뿐인데 브랜드 B, C 상품 캐시까지 다 날아간다. 목록 캐시에서 Stampede 막아놓고, 상세 캐시에서 같은 걸 반복하고 있었다.

BrandProductsDeletedEvent를 만들어서 삭제된 상품의 productId 목록을 이벤트에 담았다. 캐시 핸들러는 그 ID만 evict한다.

// AS-IS: 브랜드 A 삭제 → 모든 상품 캐시 소멸
detailCache.clear();

// TO-BE: 브랜드 A 삭제 → A 상품만 evict, B/C 캐시는 그대로
event.deletedProductIds().forEach(this::evictProductDetail);

고민 6: 다음 단계는 뭘까

지금은 단일 서버에 Redis 한 대다. 캐시 무효화가 단순하다. 이벤트 발행하고, 같은 서버 안에서 evict하면 끝이다.

근데 카카오페이 기술 블로그를 보면서 “서버가 여러 대가 되면 어떻게 되지?”를 생각해봤다. 카카오페이는 상품·통신사·혜택 같은 메타 정보를 로컬 캐시에 담는다. 네트워크를 안 타니까 빠른데, 서버가 여러 대면 서버마다 캐시가 따로라서 불일치가 생긴다. 이걸 Redis Pub/Sub으로 풀었다.

서버 A: 상품 수정 → Redis Pub/Sub에 이벤트 발행
서버 B: 이벤트 수신 → 로컬 캐시 evict
서버 C: 이벤트 수신 → 로컬 캐시 evict

여기서도 트레이드오프가 있다. Redis Pub/Sub은 메시지를 저장하지 않는다. 구독 시점에 서버가 잠깐 죽어있으면 그 이벤트는 날아간다. 카카오페이는 이걸 받아들였다. 어차피 TTL이 있으니 최악의 경우에도 TTL 지나면 갱신된다. 메시지 유실이 걱정되면 Kafka나 RabbitMQ를 쓰면 되지만, 그만큼 인프라 복잡도가 올라간다. 카카오페이는 “메타 정보는 자주 안 바뀌니까 유실돼도 괜찮다”고 판단한 거다.

내 프로젝트는 단일 서버에 Redis 글로벌 캐시라서 이 문제를 직접 겪진 않는다. 하지만 나중에 트래픽이 늘어서 서버를 늘리고, 네트워크 비용을 줄이려고 로컬 캐시를 도입하게 되면 이 구조가 필요해진다. Sharded Counter를 언급한 것과 같은 이유다 — 지금 당장은 아니지만, 다음 단계가 뭔지 알아두면 그때 가서 덜 당황한다.

테스트 환경

최종 결과

쿼리 성능 (EXPLAIN ANALYZE)

좋아요 동시성

캐시 정합성

273개 테스트 전체 통과.

회고

이번에 제일 많이 한 생각은 “정답이 없다”는 거였다.

• Partial Index는 JPA 편의성을 포기하고 131배 성능을 가져갔다.
• 비정규화는 정규화의 깔끔함을 포기하고 동시성 안전을 가져갔다.
• 캐시 TTL은 실시간 정확도를 포기하고 Stampede를 막았다.
• Redis 글로벌 캐시는 네트워크 비용을 받아들이고 데이터 정합성을 가져갔다.
• 예외를 잡는 건 디버깅 편의를 포기하고 서비스 안정성을 가져갔다.

뭘 선택하든 뭔가를 잃었고, 중요한 건 뭘 포기하고 뭘 가져가는지 알고 고르는 것이었다.

카카오페이 기술 블로그를 보면서 비슷한 걸 느꼈다. 카카오페이는 로컬 캐시를 쓰면서 서버 간 불일치를 Eventual Consistency로 받아들였고, 나는 Redis 글로벌 캐시를 쓰면서 네트워크 비용을 받아들였다. 둘 다 “완벽한 정합성”을 포기한 건 같은데, 포기한 지점이 다르다. 캐시에 뭘 담느냐, 서비스 특성이 뭐냐에 따라 같은 문제에도 답이 달라지는 거다.

실무에서도 마찬가지일 거다. 시간이 급하면 캐싱부터 때릴 수도 있다. 시간이 있으면 인덱스부터 닦는 게 나중에 안 물린다. 어떤 순서가 맞느냐가 아니라, 지금 내 상황에서 뭘 포기하는 게 제일 덜 아픈지 판단할 수 있으면 된다고 생각한다.

코드도 인생처럼, 완벽한 선택은 없다. 다만 알고 고른 선택이 있을 뿐이다.

10만건 데이터 기반 상품 목록/상세 API 성능 개선 전과정

테스트 환경

목차

1. 배경 및 목표
2. Step 1: 인덱스 최적화
3. Step 2: 좋아요 동기화 구조 개선
4. Step 3: Redis 캐시 적용
5. 테스트 검증
6. 최종 성능 비교
7. 회고

1. 배경 및 목표

커머스 서비스의 상품 목록/상세 조회 API에서 다음과 같은 성능 병목이 확인되었습니다.

목표: 인덱스 → 비정규화(원자적 UPDATE) → 캐시를 순차 적용하며, 각 단계별 AS-IS / TO-BE를 비교합니다.

환경

2. Step 1: 인덱스 최적화

분석 대상 쿼리 4가지

AS-IS: 인덱스 없음 (PK만 존재)

모든 쿼리가 Seq Scan + in-memory heapsort로 동작합니다.

-- Q1: 브랜드 필터 + 좋아요순
Seq Scan on products  (cost=0.00..3230.00 rows=4514)
  Filter: ((deleted_at IS NULL) AND (brand_id = 1))
  Rows Removed by Filter: 95247
  Buffers: shared hit=1980
Execution Time: 10.757 ms

• 10만건 전체를 스캔한 뒤 95,247건을 필터링으로 버림
• 남은 4,753건을 메모리에서 heapsort

-- Q3: 최신순 정렬
Parallel Seq Scan on products  (cost=0.00..2568.24 rows=55825)
  Filter: (deleted_at IS NULL)
  Sort Method: top-N heapsort  Memory: 33kB
Execution Time: 11.774 ms

첫 시도: 일반 복합 인덱스 (실패)

CREATE INDEX idx_products_deleted_price ON products (deleted_at, price);
CREATE INDEX idx_products_deleted_likes ON products (deleted_at, like_count DESC);

결과: Q2~Q4에서 여전히 Seq Scan. deleted_at IS NULL의 선택도가 95%로 너무 높아 플래너가 인덱스를 선택하지 않음.

일반 복합 인덱스에서 deleted_at을 선두 컬럼으로 놓으면, NULL 값의 비율이 95%이므로 인덱스로 필터링해도 거의 전체를 읽어야 합니다. PostgreSQL 플래너는 이 경우 Seq Scan이 더 효율적이라고 판단합니다.

TO-BE: Partial Index 적용

-- 활성 상품만 인덱싱 (WHERE deleted_at IS NULL)
CREATE INDEX idx_products_active_brand_likes
    ON products (brand_id, like_count DESC) WHERE deleted_at IS NULL;

CREATE INDEX idx_products_active_price
    ON products (price ASC) WHERE deleted_at IS NULL;

CREATE INDEX idx_products_active_likes
    ON products (like_count DESC) WHERE deleted_at IS NULL;

CREATE INDEX idx_products_active_created
    ON products (created_at DESC) WHERE deleted_at IS NULL;

Partial Index를 선택한 이유:

1. 인덱스 크기 축소: 5% soft-deleted 행 제외
2. 정렬 키 직접 노출: (price) WHERE deleted_at IS NULL로 인덱스 자체가 정렬 순서 반영
3. 플래너 친화적: WHERE deleted_at IS NULL 조건이 인덱스 조건과 정확히 매칭 → Index Scan 유도
4. JPA @Index 미사용 사유: Partial Index의 WHERE 절은 JPA 표준으로 표현 불가 → SQL 마이그레이션 스크립트로 관리

적용 후 EXPLAIN ANALYZE:

-- Q1: 브랜드 필터 + 좋아요순
Index Scan using idx_products_active_brand_likes on products
  Index Cond: (brand_id = 1)
  Buffers: shared hit=22 read=2
Execution Time: 0.082 ms    ← 10.757ms → 0.082ms (131x 개선)

전후 비교

버퍼(I/O) 사용량:

인덱스 오버헤드:

3.5MB의 인덱스 추가로 모든 핵심 쿼리에서 20~131배 성능 개선을 달성했습니다.

3. Step 2: 좋아요 동기화 구조 개선

AS-IS: Read-Modify-Write 안티패턴

기존 좋아요 처리 흐름:

LikeService.like()
  ├─ findProductWithLock(productId)     ← 1차 비관적 락 (SELECT FOR UPDATE)
  ├─ existsByUserIdAndProductId()       ← 중복 체크
  ├─ Like.create() → save()            ← likes 테이블 INSERT
  └─ publishEvents(like)
      └─ LikeEventHandler.handle()
          ├─ findActiveByIdWithLock()   ← 2차 비관적 락 (동일 트랜잭션)
          ├─ product.increaseLikeCount()← 메모리에서 likeCount + 1
          └─ productRepository.save()   ← 전체 엔티티 UPDATE

문제 1: Lost Update

-- 실제 발생하는 SQL: 모든 필드를 덮어씀
UPDATE products SET brand_id=?, name=?, price=?, sale_price=?,
    stock_quantity=?, like_count=?, description=?, updated_at=?, deleted_at=?
WHERE id = ?

시간   Thread A (좋아요)                Thread B (어드민 수정)
─────────────────────────────────────────────────────────
t1     READ product (price=100k)
t2                                     READ product (price=100k)
t3                                     price=120k → SAVE (전체 UPDATE)
t4     likeCount+1 → SAVE (전체 UPDATE)
       → price가 100k로 복원됨 ← Lost Update!

문제 2: 이중 비관적 락

같은 트랜잭션 내에서 동일 row에 대해 2번 SELECT FOR UPDATE → 불필요한 오버헤드.

TO-BE: 원자적 SQL UPDATE

LikeService.like()
  ├─ validateProductExists(productId)    ← 단순 조회 (락 없음)
  ├─ existsByUserIdAndProductId()        ← 중복 체크
  ├─ Like.create() → save()
  └─ publishEvents(like)
      └─ LikeEventHandler.handle()
          └─ productRepository.incrementLikeCount(productId) ← 원자적 UPDATE

핵심 변경: JPA Repository에 원자적 쿼리 추가

// ProductJpaRepository
@Modifying
@Query("UPDATE ProductJpaEntity p SET p.likeCount = p.likeCount + 1 WHERE p.id = :productId")
void incrementLikeCount(@Param("productId") Long productId);

@Modifying
@Query("UPDATE ProductJpaEntity p SET p.likeCount = p.likeCount - 1 WHERE p.id = :productId AND p.likeCount > 0")
void decrementLikeCount(@Param("productId") Long productId);

발생하는 SQL:

-- AS-IS: 전체 엔티티 덮어쓰기 (11개 컬럼)
UPDATE products SET brand_id=?, name=?, price=?, sale_price=?,
    stock_quantity=?, like_count=?, description=?, updated_at=?, deleted_at=?
WHERE id = ?

-- TO-BE: 단일 컬럼 원자적 업데이트
UPDATE products SET like_count = like_count + 1 WHERE id = ?

도메인 인터페이스에 의도 표현 (DDD)

// ProductRepository (도메인 레이어)
void incrementLikeCount(Long productId);
void decrementLikeCount(Long productId);

도메인 인터페이스에 incrementLikeCount라는 메서드명으로 비즈니스 의도를 표현하고, 원자적 SQL은 인프라 레이어의 구현 세부사항으로 캡슐화했습니다.

LikeService — 비관적 락 제거

// AS-IS: 비관적 락으로 상품 조회
private Product findProductWithLock(Long productId) {
    return productRepository.findActiveByIdWithLock(productId)
            .orElseThrow(() -> new CoreException(ErrorType.PRODUCT_NOT_FOUND));
}

// TO-BE: 단순 존재 확인 (락 불필요)
private void validateProductExists(Long productId) {
    productRepository.findActiveById(productId)
            .orElseThrow(() -> new CoreException(ErrorType.PRODUCT_NOT_FOUND));
}

전후 비교

4. Step 3: Redis 캐시 적용

AS-IS: 캐시 없음

모든 요청이 DB 직접 조회:

GET /api/v1/products/1
    → ProductQueryService.getProduct()
    → DB SELECT (매번 실행)
    → 응답

TO-BE: Redis 캐시 레이어

GET /api/v1/products/1
    → @Cacheable("product", key="#productId")
    ├─ Cache HIT → Redis GET → 즉시 반환 (sub-ms)
    └─ Cache MISS → DB SELECT → Redis SET (TTL 5분) → 반환

캐시 키 설계 및 TTL

CacheConfig 핵심 구현

@Configuration
@EnableCaching
public class CacheConfig implements CachingConfigurer {

    @Bean
    public CacheManager cacheManager(RedisConnectionFactory connectionFactory) {
        // 캐시 전용 ObjectMapper (PROPERTY 방식 타입 정보)
        ObjectMapper redisObjectMapper = new ObjectMapper();
        redisObjectMapper.registerModule(new JavaTimeModule());
        redisObjectMapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
        redisObjectMapper.activateDefaultTyping(
                BasicPolymorphicTypeValidator.builder()
                        .allowIfBaseType(Object.class).build(),
                ObjectMapper.DefaultTyping.EVERYTHING,
                JsonTypeInfo.As.PROPERTY   // ← WRAPPER_ARRAY가 아닌 PROPERTY 방식
        );

        // 캐시별 독립 TTL
        Map<String, RedisCacheConfiguration> cacheConfigs = Map.of(
            PRODUCT_DETAIL, defaultConfig.entryTtl(Duration.ofMinutes(5)),
            PRODUCT_LIST,   defaultConfig.entryTtl(Duration.ofMinutes(1)),
            BRAND_LIST,     defaultConfig.entryTtl(Duration.ofMinutes(10))
        );

        return RedisCacheManager.builder(connectionFactory)
                .cacheDefaults(defaultConfig.entryTtl(Duration.ofMinutes(5)))
                .withInitialCacheConfigurations(cacheConfigs)
                .build();
    }

    @Override
    public CacheErrorHandler errorHandler() {
        return new SafeCacheErrorHandler();  // Redis 장애 시 DB fallback
    }
}

ObjectMapper 설정 포인트:

• DefaultTyping.EVERYTHING + JsonTypeInfo.As.PROPERTY: Record 타입도 정확한 역직렬화 보장
• JavaTimeModule: LocalDateTime 직렬화 지원
• 애플리케이션 메인 ObjectMapper와 분리하여 캐시 전용으로 사용

캐시 무효화 전략

상품 CRUD:

// ProductService
@CacheEvict(value = PRODUCT_LIST, allEntries = true)
public void createProduct(ProductCreateCommand command) { ... }

@Caching(evict = {
    @CacheEvict(value = PRODUCT_DETAIL, key = "#command.productId()"),
    @CacheEvict(value = PRODUCT_LIST, allEntries = true)
})
public void updateProduct(ProductUpdateCommand command) { ... }

@Caching(evict = {
    @CacheEvict(value = PRODUCT_DETAIL, key = "#productId"),
    @CacheEvict(value = PRODUCT_LIST, allEntries = true)
})
public void deleteProduct(Long productId) { ... }

좋아요 이벤트:

// LikeEventHandler
@EventListener
@Caching(evict = {
    @CacheEvict(value = PRODUCT_DETAIL, key = "#event.productId()"),
    @CacheEvict(value = PRODUCT_LIST, allEntries = true)
})
public void handle(ProductLikedEvent event) {
    productRepository.incrementLikeCount(event.productId());
}

주문 (재고 감소):

// OrderService
@Caching(evict = {
    @CacheEvict(value = PRODUCT_DETAIL, allEntries = true),
    @CacheEvict(value = PRODUCT_LIST, allEntries = true)
})
public void createOrder(UserId userId, OrderCommand command) { ... }

브랜드 삭제 cascade:

// BrandDeletedEventHandler
@EventListener
@Caching(evict = {
    @CacheEvict(value = PRODUCT_DETAIL, allEntries = true),
    @CacheEvict(value = PRODUCT_LIST, allEntries = true)
})
public void handle(BrandDeletedEvent event) {
    // 브랜드 하위 모든 상품 soft-delete
}

Redis 장애 대응: SafeCacheErrorHandler

public class SafeCacheErrorHandler implements CacheErrorHandler {
    @Override
    public void handleCacheGetError(RuntimeException exception, Cache cache, Object key) {
        log.warn("Redis 캐시 조회 실패 - cache: {}, key: {}", cache.getName(), key);
        // 예외를 던지지 않음 → @Cacheable이 Cache MISS로 처리 → DB fallback
    }
    // put, evict, clear도 동일하게 경고 로그만 남기고 무시
}

Redis 정상 → Cache HIT → 즉시 반환 (DB 부하 0)
Redis 장애 → SafeCacheErrorHandler → warn 로그 → DB fallback (서비스 정상)

5. 테스트 검증

테스트 결과: 273개 전체 통과

모든 변경 후 전체 테스트를 실행하여 273개 테스트가 100% 통과했습니다.

발견한 문제와 수정

문제 1: DatabaseCleanUp MySQL 문법 오류

// AS-IS (MySQL 전용): PostgreSQL에서 PSQLException 발생
entityManager.createNativeQuery("SET FOREIGN_KEY_CHECKS = 0").executeUpdate();
entityManager.createNativeQuery("TRUNCATE TABLE `" + table + "`").executeUpdate();
entityManager.createNativeQuery("SET FOREIGN_KEY_CHECKS = 1").executeUpdate();

// TO-BE (PostgreSQL 호환): CASCADE로 FK 제약 무시
entityManager.createNativeQuery(
    "TRUNCATE TABLE " + table + " RESTART IDENTITY CASCADE"
).executeUpdate();

문제 2: LikeServiceTest mock 불일치

비관적 락 제거 후 findActiveByIdWithLock 대신 findActiveById를 사용하므로, 단위 테스트의 mock stubbing을 일괄 수정했습니다.

// AS-IS
when(productRepository.findActiveByIdWithLock(1L)).thenReturn(Optional.of(product));

// TO-BE
when(productRepository.findActiveById(1L)).thenReturn(Optional.of(product));

문제 3: 캐시 무효화 누락 (StockConcurrencyTest, ProductApiE2ETest)

캐시를 도입할 때 모든 데이터 변경 경로에서 무효화가 누락되지 않았는지 확인해야 합니다. 상품 CRUD에만 evict를 적용하고, 주문(재고 감소)과 브랜드 삭제(cascade) 경로를 놓친 것이 원인이었습니다.

문제 4: CacheConfig JSON 역직렬화 오류

// 초기 설정: WRAPPER_ARRAY 방식 (기본값)
objectMapper.activateDefaultTyping(..., DefaultTyping.NON_FINAL)

// 오류: PUT은 성공하지만 GET에서 역직렬화 실패
// "Unexpected token (START_OBJECT), expected START_ARRAY"

원인: NON_FINAL + 기본 WRAPPER_ARRAY 방식은 JSON을 ["타입", {데이터}] 배열로 저장하는데, Record 타입과 호환되지 않았습니다.

// 수정: EVERYTHING + PROPERTY 방식
redisObjectMapper.activateDefaultTyping(
    BasicPolymorphicTypeValidator.builder()
        .allowIfBaseType(Object.class).build(),
    ObjectMapper.DefaultTyping.EVERYTHING,
    JsonTypeInfo.As.PROPERTY    // {"@class":"...", "field":"value"} 방식
);

6. 최종 성능 비교

Phase별 전체 비교

쿼리 성능

캐시 적용 후 기대 성능

좋아요 동기화

7. 아키텍트 리뷰 기반 구조 개선

초기 캐시 구현 후 대규모 트래픽 관점에서 구조적 리스크를 점검한 결과, 3가지 핵심 문제를 발견하고 수정했습니다.

문제 1: @CacheEvict과 @Transactional의 실행 순서 불일치

AS-IS 문제:

t1: LikeService.like() → 트랜잭션 시작
t2: Like INSERT + incrementLikeCount() 실행
t3: @CacheEvict 실행 → Redis에서 캐시 삭제됨
t4: (다른 스레드) Cache MISS → DB 조회 → 아직 커밋 전이므로 이전 값으로 캐시 재생성
t5: 트랜잭션 커밋 → DB 값 변경 확정
    → 캐시에는 이전 값이 TTL 동안 고정됨

@CacheEvict은 AOP 프록시 레벨에서 동작하므로 트랜잭션 커밋보다 먼저 실행됩니다. 이 사이에 다른 스레드가 캐시를 다시 채우면 stale 데이터가 TTL 동안 고정됩니다.

TO-BE 해결:

@EventListener(DB 작업) + @TransactionalEventListener(AFTER_COMMIT)(캐시 무효화)로 책임을 분리했습니다.

// LikeEventHandler — DB 작업만 수행 (트랜잭션 내)
@EventListener
public void handle(ProductLikedEvent event) {
    productRepository.incrementLikeCount(event.productId());
}

// ProductCacheEvictHandler — 커밋 후 캐시 무효화 (신규)
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void handleLiked(ProductLikedEvent event) {
    Cache cache = cacheManager.getCache(CacheConfig.PRODUCT_DETAIL);
    if (cache != null) cache.evict(event.productId());
}

t1: 트랜잭션 시작
t2: @EventListener → incrementLikeCount() 실행
t3: 트랜잭션 커밋 ← DB 값 확정
t4: @TransactionalEventListener(AFTER_COMMIT) → 캐시 삭제
t5: (다른 스레드) Cache MISS → DB 조회 → 커밋된 최신 값으로 캐시 생성 ✅

ProductService, OrderService에도 동일하게 TransactionSynchronizationManager.registerSynchronization(afterCommit)을 적용하여 모든 캐시 evict가 트랜잭션 커밋 이후에 실행되도록 변경했습니다.

문제 2: PRODUCT_LIST allEntries=true — Cache Stampede 위험

AS-IS 문제:

좋아요 1회 → products::* 전체 캐시 삭제 → 수백 개의 목록 조회 요청이 동시에 Cache MISS → DB에 동시 쿼리 폭증 (Cache Stampede).

트래픽이 증가하면 좋아요 TPS도 증가하므로, 목록 캐시의 실효성이 사라지고 stampede가 반복됩니다.

TO-BE 해결:

좋아요/주문 경로에서 PRODUCT_LIST 전체 무효화를 제거했습니다.

• 목록 캐시의 좋아요 수/재고는 TTL 1분 이내에 자연 갱신 (eventual consistency)
• 상품 상세 캐시는 변경 즉시 evict하여 정확한 값 보장
• 상품 CRUD, 브랜드 삭제는 어드민 작업(빈도 낮음)이므로 allEntries=true 유지

이 설계는 “좋아요 count가 목록에서 최대 1분 지연될 수 있다”는 비즈니스 트레이드오프를 수용합니다. 대신 Cache Stampede 위험을 근본적으로 제거합니다.

문제 3: 캐시 장애의 가시성 부재

AS-IS 문제:

SafeCacheErrorHandler가 모든 예외를 warn 로그로 삼키므로, Redis가 반쯤 죽어도 서비스는 “정상”으로 보입니다. 적중률 저하, evict 실패를 인지하는 시점이 “고객이 느린 응답을 체감할 때”가 됩니다.

TO-BE 해결:

// SafeCacheErrorHandler — Micrometer 메트릭 추가
public class SafeCacheErrorHandler implements CacheErrorHandler {

    private final MeterRegistry meterRegistry;

    @Override
    public void handleCacheGetError(RuntimeException exception, Cache cache, Object key) {
        log.warn("Redis 캐시 조회 실패 - cache: {}, key: {}", cache.getName(), key);
        Counter.builder("cache.errors")
                .tag("cache", cache.getName())
                .tag("operation", "get")
                .register(meterRegistry)
                .increment();
    }
    // put, evict, clear도 동일
}

// CacheConfig — 통계 활성화
return RedisCacheManager.builder(connectionFactory)
        .cacheDefaults(defaultConfig)
        .withInitialCacheConfigurations(cacheConfigs)
        .enableStatistics()   // ← Micrometer 캐시 통계 노출
        .build();

Prometheus /actuator/prometheus 엔드포인트에서 확인 가능한 메트릭:

8. 회고

적용한 원칙

DDD:

• 도메인 레이어의 ProductRepository 인터페이스에 incrementLikeCount 의도 표현
• 원자적 SQL, 캐시 설정은 인프라 레이어의 구현 세부사항으로 캡슐화
• Like → ProductLikedEvent → LikeEventHandler(DB) / ProductCacheEvictHandler(캐시) 관심사 분리

SOLID:

• SRP: LikeEventHandler(DB 변경), ProductCacheEvictHandler(캐시 무효화) 각각 단일 책임
• OCP: 새로운 캐시 대상 추가 시 @Cacheable 어노테이션만 추가
• DIP: 도메인 인터페이스에 의존, 구현은 인프라 레이어

안티패턴 해결:

• Read-Modify-Write → 원자적 SQL UPDATE
• 이중 비관적 락 → 락 제거
• 전체 엔티티 덮어쓰기 → 단일 컬럼 UPDATE
• 캐시 evict 타이밍 불일치 → AFTER_COMMIT 패턴
• Cache Stampede 위험 → 목록 캐시의 TTL 기반 갱신

배운 점

1. Partial Index의 위력: 일반 복합 인덱스가 실패한 곳에서 Partial Index가 성공. 선택도가 높은 조건(deleted_at IS NULL = 95%)에서는 해당 조건 자체를 인덱스 필터로 분리하는 것이 효과적.

2. 캐시 무효화는 모든 변경 경로를 커버해야 한다: CRUD에만 evict를 적용하고 주문(재고 감소), 브랜드 삭제(cascade) 경로를 놓쳐 테스트 실패. 캐시를 도입할 때 데이터가 변경되는 모든 진입점을 파악하는 것이 핵심.

3. @CacheEvict과 @Transactional은 같은 AOP 레벨: 캐시 evict이 트랜잭션 커밋보다 먼저 발생할 수 있다. @TransactionalEventListener(AFTER_COMMIT) 또는 TransactionSynchronizationManager를 사용하여 커밋 후 evict을 보장해야 한다.

4. allEntries=true는 트래픽에 비례하는 시한폭탄: 좋아요 1회 = 목록 캐시 전체 소멸. 트래픽이 증가하면 캐시가 없는 것보다 나쁜 상태(Redis 왕복 + DB 쿼리)가 된다. 비즈니스 관점에서 어느 수준의 eventual consistency를 허용할지 결정하는 것이 기술적 해결보다 선행되어야 한다.

5. 모니터링 없는 SafeCacheErrorHandler는 위험: 예외를 삼키는 패턴은 장애 격리에 유효하지만, 메트릭 없이 사용하면 문제를 은폐한다. 캐시 적중률과 오류율에 대한 가시성은 운영의 전제 조건이다.

6. ObjectMapper 분리: 애플리케이션 메인 ObjectMapper와 Redis 캐시용 ObjectMapper를 분리해야 함. 캐시는 타입 정보(@class)를 포함해야 역직렬화가 가능하지만, API 응답에는 타입 정보가 불필요.

파일 변경 요약

AI가 일을 해줬다. 그런데 그게 괜찮은 건가?

이번 주 회사에서 네이버 금융 클라우드 기반 eKYC 개발을 맡았다. 한국 이용자의 2차 인증 — 신분증, 운전면허증, 여권, 외국인등록증으로 진위여부를 판별하는 기능이다. eKYC + ApiGateway + Object Storage를 연동해서 minimum PoC를 진행했고, 결과적으로 잘 돌아갔다.

문제는 이 과정에서 내가 한 게 뭔지 모르겠다는 거다.

Java+Spring만 쓰다가 TypeScript+Nest.js 환경으로 바뀌니 시간 안에 끝내기가 어려웠다. 그래서 클로드 코드에 거의 전부를 맡겨버렸다. 코드는 나왔고, PoC는 통과했다. 하지만 그 코드가 왜 그렇게 작성되었는지, Nest.js의 어떤 패턴이 적용된 건지 나는 제대로 설명할 수 없다.

결과물만 놓고 보면 성공이다. 그런데 이걸 “내가 해냈다”고 말할 수 있나? 만약 다음에 비슷한 걸 AI 없이 해야 한다면, 나는 할 수 있나? 이 질문에 자신 있게 “예”라고 답하지 못하는 게 찝찝하다.

남은 과제들

eKYC 자체는 거의 끝났지만, 아직 남은 게 있다.

• OCR을 통한 개인정보 추출 → admin 페이지 노출: 어느 정도 방향은 잡았지만 마무리가 필요하다.
• 코드리뷰: 동료들의 리뷰가 남아 있다. AI가 짠 코드를 리뷰 받는다는 게 조금 묘한 기분이다. 내가 설명할 수 있어야 하니까, 리뷰 전에 코드를 한 줄씩 다시 읽어봐야겠다.
• CI/CD: CI는 GitHub Actions로 결정했지만, CD는 회사 정책상 Jenkins를 써야 한다고 했다. Jenkins는 써본 적이 없어서 고민하다가 개발자 커뮤니티에 물어봤더니 NCP의 SourcePipeline을 쓰면 된다는 답을 얻었다. 팀장님께 보고하니 그렇게 진행하라고 했다.
• DB 마이그레이션: NCP PostgreSQL로 올리는 것도 남아 있다.

할 일이 많지만, 하나씩 쳐내면 된다. 급하게 동시에 하려다 보면 또 AI한테 다 던지게 될 거다.

협업에 대한 생각

2월 말에 새로운 동료가 합류했다. 3년 차 개발자인데, 업무 소통이 거의 없다. 말수가 적은 건 성격이니 상관없다. 하지만 업무 진행 상황을 공유하지 않는 건 다른 문제다.

데드라인도 주고, 가이드라인도 문서로 만들어서 전달했다. 그런데 묻기 전까지는 진행 상황을 말하지 않는다. 내가 하나하나 물어봐야 어디까지 했는지 알 수 있다. 이게 반복되니 소모적이다.

그런데 여기서 한 발 더 생각해봤다. 나도 처음 어딘가에 합류했을 때 이랬을 수도 있지 않나? 환경이 낯설면 먼저 말을 꺼내기가 어렵다. “좋은 동료가 좋은 환경을 만든다”고 믿는다면, 내가 먼저 소통 구조를 만들어줘야 하는 건 아닐까. 예를 들어 매일 10분 스탠드업을 제안한다거나, 진행 상황 공유 템플릿을 만든다거나. 불만만 가지고 있으면 아무것도 바뀌지 않을 거다.

물론 쉬운 일은 아니다. 나도 4년 차일 뿐이고, 리드 역할이 익숙하지 않다. 하지만 “이 사람이 바뀌어야 한다”고만 생각하면 끝이 없다.

지금 내 상태를 정직하게 보면

이번 주도 솔직히 게으르게 보낸 시간이 많았다. 공부해야 할 때 안 했고, 해야 한다는 걸 알면서도 미뤘다.

지금 내 앞에 놓인 것들:

• 월요일마다 “JVM 밑바닥부터 파헤치기” 스터디
• 루퍼스 과제와 학습
• 회사 업무 (eKYC 마무리, CI/CD, DB)

양이 많은 건 사실이다. 하지만 “많아서 못 한다”는 말은 결국 우선순위를 못 정하고 있다는 뜻이기도 하다. 전부 다 똑같은 무게로 안고 가니까 어느 것도 깊게 못 하는 거다.

다음 주에는 하나를 정해서 깊게 파보려고 한다. 전부 다 조금씩 하는 것보다, 하나라도 “이건 내가 확실히 안다”고 말할 수 있는 게 낫다. 그게 뭔지는 아직 정하지 못했지만, 적어도 이렇게 글로 써놓으면 다음 주의 내가 기억하겠지.

앞으로 한주 동안 내가 해야될것들은??

이번주는 레디스를 어느정도 습득하고 공부해야된다. TypeScript + Nest.js를 공부해야된다.

“왜 비관적 락을 사용하셨나요?” 면접에서 이 질문을 들을 때마다 늘 외운 대답을 했었다. 근데 이렇게 하면 설득이 안 되더라. 진지하게 고민하지 않고, 왜 그 선택을 했는지 스스로 납득하지 못한 채 답하니까 당연한 결과였다.

이번 주에 새로 배운 것

동시성 제어와 낙관적 락/비관적 락, 그리고 JDK에서 제공하는 동시성 도구들

JDK 동시성 도구들

이번 주에 렌 멘토님의 멘토링을 듣고 JDK가 제공하는 동시성 관련 도구들을 쭉 훑었다. notify()/wait(), synchronized, Lock, 세마포어, 뮤텍스, volatile, ThreadLocal, Atomic Class, CAS 알고리즘 등등. 사실 키워드 자체는 이전에도 들어봤지만, 이것들이 각각 어떤 문제를 해결하기 위해 존재하는지 관점에서 정리해본 건 이번이 처음이었다.

가상스레드와 pinning 문제

이번에 인상 깊었던 건 가상스레드 관련 내용이다.

• 가상스레드: JVM 안에서 동작하는 스레드로, 캐리어스레드 위에서 실행된다.
• 플랫폼스레드(커널스레드): OS에서 관리하는 스레드.

과거의 고민이 “N개의 스레드를 어떻게 효율적으로 쓰지?”였다면, 지금은 “무한개의 가상스레드에서 안 터지고 잘 사용할 수 있을까?”로 바뀌었다는 게 재밌었다.

특히 synchronized가 OS 단에서 동작하기 때문에, 가상스레드 위에서 실행하더라도 캐리어스레드에 고정(pinning)되는 현상이 생긴다는 걸 처음 알았다. 실무에서 가상스레드를 도입할 때 이걸 모르면 오히려 성능이 나빠질 수 있겠다고 느꼈다.

이런 고민이 있었어요

처음엔 “결제할 때는 무조건 비관적 락”이라고 생각했다. 낙관적 락은 버전으로 관리하니까 돈 관련 로직에는 안 맞다고 믿었다. 돈 = 비관적 락이라는 고정관념이 박혀 있었다.

• 돈이란 비용, 즉 쿠폰이든 송금, 결제 등 돈에 관련된것들

근데 배워보니까 루퍼스에서는 “락을 쓸 때 절대 정답은 없다”고 했다. 도메인별로, 적재적소에 잘 섞어서 사용하는 거라고. 예를 들어 쿠폰 발급처럼 충돌이 드문 경우엔 낙관적 락이 더 효율적일 수 있고, 실시간 잔액 차감처럼 충돌이 잦은 경우엔 비관적 락이 맞을 수 있다.

그래서 지금 고민하는 건 “어떤 상황에서 어떤 락을 선택해야 하는가”에 대한 나만의 기준을 만드는 것이다. 아직 명확한 답은 없지만, 최소한 “무조건 비관적 락”이라는 생각에서는 벗어났다.

앞으로 실무에서 써먹을 수 있을 것 같은 포인트

• 지금 해외송금 스타트업에 다니고 있는데, 송금 로직에서 동시성 제어와 정합성이 핵심이다. 이번에 배운 락 선택 기준을 실제 송금 플로우에 적용해볼 수 있을 것 같다.
• 서비스 런칭 때 신규 고객 대상 쿠폰 발급이 있을 텐데, 동시성 제어를 어떻게 가져갈지 이번 학습 내용을 바로 적용해볼 수 있겠다.
• 멘토가 “전략 패턴을 활용해서 각각의 할인 정책을 어떻게 도메인에 녹일 수 있는지 고민해보라”고 했다. 단순히 락만 고르는 게 아니라, 할인 정책 자체를 유연하게 설계하는 것도 함께 고민해봐야겠다.

이번 주 메타 회고 — AI 의존과 집중도

솔직히 이번 주는 AI에 너무 의존했다. AI에게 물어보고 답을 받으면 “아 그렇구나” 하고 넘어가는 패턴이 반복됐다. 코드를 타이핑하는 속도가 느려지는 건 괜찮지만, 개념이 헷갈리거나 트레이드오프를 스스로 판단 못 하는 건 문제다.

이직한 지 얼마 안 돼서 새 환경 적응에 에너지를 많이 쓴 것도 사실이다. 스타트업이고 언어도 다르다 보니 루퍼스에 온전히 집중하기 어려웠다.

하지만 “바빠서”를 이유로 매주 같은 고민만 반복하고 있다는 걸 인식했다. 그래서 다음 주부터는 구체적으로 이렇게 해보려 한다:

다음 주에 해보고 싶은 것

• 하루 30분 개념 정리 시간 확보: AI 없이, 이번 주 배운 동시성 도구들을 직접 정리해본다.
• 낙관적 락 vs 비관적 락 판단 기준표 만들기: 충돌 빈도, 트랜잭션 길이, 데이터 중요도 등 기준을 잡아보고, 실무 송금 도메인에 대입해본다.
• 멘토 피드백 반영: 전략 패턴으로 할인 정책을 분리하는 구조를 간단하게라도 설계해본다.