장인환

⭐ Main Project

실무 역량 강화 프로젝트

득근대란 Protein Show

Live Demo GitHub

특정 시간에 단백질 상품 한정 수량을 선착순으로 판매하는 고부하 커머스 플랫폼

Overview

Type 개인 프로젝트

AI Tool Claude Code

Period 2026.03 ~ 2026.04

Domain 타임 세일 기반의 커머스 특정시간 · 최저가 · 선착순

Focus 3가지 고가용성 문제 트래픽 폭주 · 재고 동시성 · 장애 격리

Tech Stack

Backend

Java 21 Spring Boot 4 Spring Security + JWT Gradle (Multi-Module)

MariaDB JPA + QueryDSL Redis (String / Streams)

Frontend

Next.js TypeScript

Infra

Docker Nginx

Architecture

CI/CD Pipeline GitHub Actions

Push to main

Docker Build

GHCR Push

SSH Deploy

Production AWS EC2 · Ubuntu

Nginx

: 80 / : 443 · 외부 요청 수신 및 라우팅

↓

ps-front

: 3000

ps-order

: 8080

ps-point

: 8081

Data Stores

MySQL

: 3306

Redis

: 6379

Problems Solved

풀어낸 문제들

플래시 세일에서 반드시 마주치는 핵심 문제들과 해결 접근

조회 성능 향상

Redis 캐싱 전략

트래픽 폭주를 대비하여 조회 경로를 Redis로 끊어내 DB 커넥션 고갈 방지

상세 보기

재고 동시성 제어

Redis DECR + Fail-Fast

Redis의 원자 연산으로 경합을 해소하여 선착순 초과 판매 차단

상세 보기

선착순에서 가장 골치 아픈 게 초과 판매입니다. 일반적인 DB 비관적 락으로 막으면 경쟁이 심할수록 커넥션이 묶여 응답이 뭉쳐버립니다. Redis의 원자 연산(DECRBY) 으로 DB 진입 전에 재고를 먼저 선점하고, 음수가 나오면 DB까지 가지 않고 즉시 거절(Fail-Fast)하도록 처리했습니다.

재고는 DB에 컬럼을 두지 않고 stock:{id}에서만 관리합니다. DB products 테이블에는 initial_stock (불변)만 두고, 실제 판매 수량은 orders 레코드로 역산합니다. "재고의 단일 진실 원천"을 Redis로 못 박으면서 동기화 이슈를 애초에 없앤 설계입니다.

// ps-order/service/impl/OrderServiceImpl.java
@Transactional
public OrderResponse placeOrder(String userId, OrderRequest orderRequest) {
    Long productId = orderRequest.getProductId();
    int quantity = orderRequest.getQuantity();
    String stockKey = STOCK_CACHE_KEY + productId;

    // 1. Redis DECRBY — 원자적 재고 선점
    Long remaining = stringRedisTemplate.opsForValue().decrement(stockKey, quantity);

    if (remaining == null || remaining < 0) {
        // 재고 부족 — 선점했던 수량 되돌리고 즉시 거절
        stringRedisTemplate.opsForValue().increment(stockKey, quantity);
        int remainingStock = remaining == null ? 0 : (int) Math.max(0, remaining + quantity);
        throw new OutOfStockException(remainingStock);
    }

    // 2. DB 트랜잭션 — 실패 시 Redis 재고 복구
    try {
        // 주문 + Outbox 저장 ...
    } catch (BusinessException e) {
        throw e; // 이미 복구 완료
    } catch (Exception e) {
        stringRedisTemplate.opsForValue().increment(stockKey, quantity);
        throw e;
    }
}

검증

CountDownLatch로 200개 스레드를 같은 순간 출발시켜 재고 100개 상품을 두고 경쟁시키는 테스트로 확인했고, 성공 100건 / 실패 100건 / DB 주문 100건 / Redis 잔여 0개가 정확히 맞아떨어지는 것을 회귀 테스트로 고정했습니다.

장애 격리

Transactional Outbox + Redis Streams

주문 서버와 포인트 서버 간 장애 전파 차단

상세 보기

적립 로직을 주문 트랜잭션 안에 두면, 포인트 서버가 느려지는 순간 주문 응답 시간도 같이 늘어납니다. 반대로 완전히 비동기로 던지면 메시지가 유실될 위험이 있어, Transactional Outbox 패턴으로 DB에 "보낼 메시지"를 먼저 기록하고 → 스케줄러가 Redis Streams로 발행하는 구조를 택했습니다.

[ps-order]                          [ps-point]
  주문 + Outbox(PENDING) 저장
  → 클라이언트 즉시 응답
       │
       │ (5초 스케줄러)
       ▼
  Outbox 조회 → XADD → DONE 업데이트
                  │
                  ▼
             Redis Streams
                  │
                  │ XREADGROUP
                  ▼
                          주문 ID 중복 확인 → 적립 → XACK
                          (실패 시 PEL에 남아 30초마다 재처리)

중복 메시지가 유입될 수 있는 포인트(XADD 성공 후 DONE 업데이트 실패 시 재발행)는 points.order_id에 UNIQUE 제약을 걸고, 애플리케이션 레벨에서도 existsByOrder_Id로 한 번 더 확인하는 이중 방어로 막았습니다.

소비자 쪽에서는 실패 유형에 따라 XACK 전략을 분기했습니다. DB 저장 같은 일시적 실패는 XACK하지 않고 PEL(Pending Entry List)에 남겨 30초 주기로 재처리, 반대로 "주문이 존재하지 않음" 같은 복구 불가 에러는 무한 재시도를 막기 위해 XACK + 에러 로그로 종결시켰습니다.

// ps-point/consumer/PointStreamConsumer.java
private void processMessages(List<MapRecord<String, Object, Object>> messages) {
    for (MapRecord<String, Object, Object> message : messages) {
        try {
            pointService.savePoint(orderId, userId, totalPrice);
            acknowledge(message); // 정상 처리 → XACK

        } catch (BusinessException e) {
            // 복구 불가 (User/Order 없음) → 무한 retry 방지를 위해 XACK
            log.error("[Point] 복구 불가 오류, XACK 처리. orderId={}", orderId);
            acknowledge(message);

        } catch (Exception e) {
            // DB 저장 실패 등 → XACK 안 함, PEL에 남겨 30초 주기 재처리
            log.error("[Point] 처리 실패, PEL 유지. orderId={}", orderId);
        }
    }
}

Consumer Group이 사라졌을 때(스트림 키 TTL 만료 후 재생성 등)의 NOGROUP 예외도 메시지 체인까지 파고들어 잡아내서 그룹을 재생성하도록 처리했습니다.

Design Decisions

설계하면서 의도적으로 내린 결정들

재고를 DB에 두지 않는다

동기화 포인트를 없애기 위해 Redis를 단일 진실 원천으로 고정

Redis 장애 대비는 범위 밖으로 뺀다

fallback을 만들면 사실상 별도 시스템이 되고, 플래시 세일에서는 "재고 불일치보다 주문 중단이 안전"하다는 판단

캐시 워밍 시점에 Redis Streams MAXLEN을 미리 계산해 둔다

stream:point:maxlen 키에 총 재고 × 2를 넣어 두고 발행 스케줄러가 이 값으로 trim하도록 위임 — 스트림이 무한정 커지는 걸 이벤트 단위로 자동 제어

Takeaways

배운 것 / 달라진 것

▸ 공부로 알던 Transactional Outbox + Stream Consumer Group을, 실제로 "어느 단계에서 중복이 발생할 수 있는가"를 코드 레벨로 따라가면서 추상 개념이 현실 코드와 붙는 지점을 체감했습니다

▸ "복구 가능한 실패"와 "복구 불가 실패"를 분리해 XACK 전략을 나누는 것이 Streams 소비자 설계의 핵심이라는 감을 잡았습니다

▸ 1.5년의 공백 기간 동안 오히려 왜 이렇게 짜는가 를 말로 풀어 쓰는 습관이 생겼고, 이 프로젝트에서도 plan.md / tasks.md / ui-logic.md로 의사결정 근거를 남기며 진행했습니다

Portfolio

기타 경력 프로젝트

상세 보기

마켓해머

제조업체 전문 파트너 매칭 및 온라인 계약·관리 플랫폼

기여 30%

배경 반복적인 기능 추가/수정으로 인해 유지보수가 힘들어진 레거시 프로젝트 재구축

Java Spring Boot MariaDB MyBatis WebSocket STOMP JavaScript jQuery

3인 팀 (Backend & Frontend)

상세 보기

SAFFY

안전 작업 허가서 작성부터 다단계 승인, 문서 조회/출력까지 관리하는 통합 결재 시스템

기여 70%

배경 기존 시스템의 복잡하고 불필요한 기능 제거 및 실무자 요구사항을 반영한 전면 재구축

Java Spring Boot MariaDB JPA QueryDSL JavaScript jQuery

2인 팀 (Backend & Frontend)

상세 보기

해리티지 산후조리원

산후조리원 세부 일정 및 현황을 관리하는 관리자 전용 시스템

기여 40%

배경 현행 시스템의 분석 불능 상태 해결 및 신규 비즈니스 요구사항 수용을 위한 전면 재구축

Java Spring Boot MariaDB MyBatis JavaScript jQuery

2인 팀 (Backend & Frontend)

상세 보기

Fashion & Style

글로벌 패션 트렌드 및 셀럽 스타일 정보를 제공하는 매거진 형식의 패션 정보 플랫폼

기여 90%

배경 고객사 개발팀이 백엔드 API를 선구축, 이후 React 기반 프론트엔드 전담 개발

React JavaScript

1인 (Frontend 전담)

Backend Developer

코드아이디어

OK 인베스트먼트파트너스

유엔비즈

Main Stack

Sub Stack

자격증

학력 / 교육

실무 역량 강화 프로젝트

득근대란 Protein Show

풀어낸 문제들

조회 성능 향상

재고 동시성 제어

장애 격리

설계하면서 의도적으로 내린 결정들

배운 것 / 달라진 것

기타 경력 프로젝트

마켓해머

SAFFY

해리티지 산후조리원

Fashion & Style