2편은 이 두 문제를 이어받아, 1편에서 만든 폴링 구조(V1)를 V2와 V3로 다시 손본 과정의 기록이다.

무엇이 문제였나 (V1 복기)

1편에서 만든 폴링 스케줄러를 V1이라 부르자. 구조를 다시 떠올려보면, process() 메서드가 하나의 트랜잭션 안에서 조회 → 외부 API 호출 → 삭제를 모두 처리한다.

@Transactional
public void process() {
    // 1. Outbox 조회 (SKIP LOCKED)
    List<OutboxEvent> events = outboxRepository.findByCreatedAtBeforeWithSkipLocked(threshold);
    // 2. 각 이벤트마다 Admin API 호출
    ProcessingResult result = processAllEvents(events);
    // 3. 성공한 이벤트 삭제
    deleteProcessedEvents(result.toDelete());
}

1편 마지막에서 "단일 스레드로 호출되지만 이 역시 트랜잭션 내부에서 API 호출을 한다"고 적었던 바로 그 부분이다. 이게 왜 문제인지, 이번엔 숫자로 따져봤다.

트랜잭션이 열려 있는 동안 스케줄러 스레드는 DB 커넥션을 쥐고 있다. 그런데 그 트랜잭션 한가운데에 외부 API 호출이 들어가 있으니, Admin 서버가 느려지거나 죽으면 응답(혹은 timeout)을 기다리는 내내 커넥션을 붙잡게 된다. 문제는 이 점유 시간이 조회한 이벤트 수에 비례한다는 점이다.

1편의 가정대로 미션 기록이 초당 1건씩 쌓이고, 외부 API timeout을 3초로 잡았다고 하자. 최악의 경우 한 번의 process()에서 30건을 처리하므로, 3초(timeout) × 30건, 즉 최대 90초 동안 커넥션 하나를 붙잡는다. 물론 이건 모든 호출이 timeout까지 가는 최악의 가정이다.

여기에 더 고약한 문제가 겹친다. 스케줄링 주기는 30초인데 한 번 처리에 최대 90초가 걸린다면, 이전 실행이 끝나기 전에 다음 실행이 시작된다.

0초   →  90초 : 커넥션 1번 점유
30초  → 120초 : 커넥션 2번 점유 (SKIP LOCKED로 다른 레코드 처리)
60초  → 150초 : 커넥션 3번 점유
...

SKIP LOCKED 덕분에 각 실행이 서로 다른 레코드를 잡으니 중복 처리는 없지만, 그 대신 커넥션 점유가 겹겹이 쌓인다. Admin 장애가 길어질수록 풀려나지 않는 커넥션이 늘어나고, 결국 커넥션 풀 고갈로 이어진다. 스케줄러 하나의 장애가 PeakTime 서비스 전체의 DB 커넥션을 마르게 할 수 있는 구조였던 것이다.

원인은 1편에서부터 일관되게 같았다. DB 커넥션을 쥔 채로 외부 API를 기다린다는 것. 1편에서는 @TransactionalEventListener의 즉시 발송 경로에서 이 문제를 트랜잭션 밖으로 빼는 데 성공했지만, 폴링 재시도 경로에는 여전히 트랜잭션이 남아 있었다. 이번엔 이 폴링 쪽을 손봐야 했다.

V2: 트랜잭션 밖으로 API 호출을 꺼내다

가장 직관적인 해결책은 즉시 발송 경로에서 했던 것처럼, 폴링 경로에서도 외부 API 호출을 트랜잭션 밖으로 빼는 것이었다. 그래서 하나였던 트랜잭션을 둘로 쪼갰다.

Tx1: 이벤트 조회 + 상태를 PROCESSING으로 변경 → 커밋 (커넥션 반환)
     ─ 외부 API 호출 (트랜잭션 없음, DB 커넥션 잡지 않음) ─
Tx2: 성공 시 이벤트 삭제 / 실패 시 상태를 READY로 복구

핵심은 가운데 외부 API 호출 구간이다. 이 시점에는 트랜잭션이 닫혀 있으므로, Admin 서버가 아무리 느려도 DB 커넥션을 점유하지 않는다. V1의 가장 큰 문제였던 커넥션 장기 점유는 이렇게 해결됐다.

그런데 이 구조는 새로운 문제를 데려왔다. 외부 API를 호출하기 전에 이벤트를 PROCESSING 상태로 커밋해버린다는 점이다. 만약 Tx1을 커밋한 직후 외부 API를 호출하기도 전에 서버가 다운되거나, 외부 API는 성공했는데 Tx2(삭제)가 실패한다면 어떻게 될까? 두 경우 모두 이벤트가 PROCESSING 상태에 갇혀버린다. 누가 처리 중인지 알 수 없고, 스스로 READY로 돌아오지도 못한다. 이미 커밋된 상태라 롤백으로 되돌릴 수도 없다.

그래서 갇힌 이벤트를 되살릴 복구 스케줄러(ProcessingRecoveryScheduler)가 필요해졌다. 이 복구 로직은 이벤트가 일정 시간(예: 90초) 이상 PROCESSING 상태에 머물러 있으면 멈춘 것으로 간주하고 READY로 되돌리는 방식으로 동작한다.

여기서 마음에 걸리는 지점이 있었다. 이 복구 로직은 결국 "얼마나 오래 머물렀으면 죽은 것으로 볼 것인가"라는 timeout 기준에 의존한다. 이 임계값이 너무 짧으면 정상 처리 중인 이벤트를 멋대로 되살려 중복 호출이 발생하고(1편에서 멱등성으로 고민했던 바로 그 중복 요청이다), 너무 길면 실제로 멈춘 이벤트가 한참 방치된다. 적절한 값을 찾는 건 결국 추측과 튜닝의 영역이었다.

정리하면 V2는 커넥션 점유는 해결했지만, 그 대가로 PROCESSING이라는 중간 상태와 그것을 감시하는 복구 스케줄러라는 상태 관리 복잡도를 떠안았다. 문제를 옮겨놓은 것에 가까웠다.

왜 복구 스케줄러가 필요했을까

복구 스케줄러의 timeout 임계값을 몇 초로 잡을지 고민하다가, 문득 질문이 바뀌었다. 복구 스케줄러가 왜 필요했지? PROCESSING 상태를 DB에 커밋했기 때문이다. 한번 커밋해버리니 롤백으로 되돌릴 수 없고, 그래서 갇힌 데이터를 누군가 따로 되살려야 했다.

그럼 PROCESSING을 DB에 커밋하지 않으면 되지 않을까? 처리할 이벤트 목록을 DB가 아닌 다른 곳에 잠깐 들고 있을 수만 있다면, "처리 중"이라는 상태를 영속화할 필요도, 그것을 감시할 복구 스케줄러도 필요 없어진다. 그 "다른 곳"으로 Redis를 떠올렸다.

그리고 이 발상은 1편에서 남긴 첫 번째 숙제와도 맞닿아 있었다. 1편에서는 SKIP LOCKED로 여러 인스턴스가 레코드를 나눠 가졌지만, 그러려면 인스턴스 수와 TPS에 맞춰 BATCH_SIZE를 매번 계산해 박아넣어야 했다. 만약 처리할 목록을 Redis라는 공용 공간에 올려두고 모든 인스턴스가 거기서 알아서 하나씩 집어가게 하면, 인스턴스가 몇 대든 배치 사이즈를 신경 쓸 필요가 없어진다.

Redis SET을 중간 큐로

핵심 아이디어는 DB와 외부 API 호출을 완전히 분리하고, 그 사이에 Redis SET을 중간 큐로 두는 것이다. 처리 흐름을 적재(Produce)와 소비(Consume) 두 단계로 나눴다.

폴러는 이 두 단계를 순서대로 호출하는 얇은 진입점이다. 한 인스턴스가 Redis SET에 이벤트를 장전하고, 그다음 모든 인스턴스가 그 SET을 함께 비운다.

@Slf4j
@Component
@RequiredArgsConstructor
public class OutboxPoller {

    private final OutboxProducer producer;
    private final OutboxConsumer consumer;

    @Scheduled(fixedDelay = 3_000)
    public void poll() {
        // 1. 장전 (Producer면 장전, 아니면 대기)
        producer.loadEventsToRedisWithSync();

        // 2. 소비 (모든 인스턴스가 동시에 병렬 처리)
        consumer.consumeAll();
    }
}

Produce — 분산락으로 한 인스턴스만 적재

먼저 Produce 단계에서는 분산락으로 한 인스턴스만 적재한다. 1편에서 다중 인스턴스 환경의 중복 발행을 막을 때, 분산 락을 한 번 후보로 올렸다가 "한 대만 일하게 되어 병렬성을 못 살린다"는 이유로 SKIP LOCKED를 택했었다. 이번에는 분산 락을 조회 단계에만 국한해서 쓴다. 락을 획득한 대표 인스턴스 하나만 Outbox 테이블을 조회해 SADD로 Redis SET에 적재하고, 나머지는 락 대기 상태로 빠진다.

여기서 한 가지 풀어야 할 문제가 있었다. 락을 얻지 못한 인스턴스를 단순히 대기시키기만 하면, 그 인스턴스는 적재가 끝나기도 전에 다음 소비 단계로 넘어가 텅 빈 SET을 보게 될 수 있다. 그래서 락(RLock)에 더해 카운트다운 래치(RCountDownLatch)를 함께 사용했다.

public boolean loadEventsToRedisWithSync() {
    RLock lock = redissonClient.getLock(PRODUCER_LOCK_KEY);
    RCountDownLatch latch = redissonClient.getCountDownLatch(PRODUCER_LATCH_KEY);

    boolean isProducer;
    try {
        isProducer = lock.tryLock(0, 30, TimeUnit.SECONDS);
    } catch (InterruptedException e) {
        Thread.currentThread().interrupt();
        return false;
    }

    if (isProducer) {
        // 락을 잡은 인스턴스: Producer로서 Redis SET에 장전
        boolean success = false;
        try {
            latch.trySetCount(1);
            doLoadEventsToRedis();
            success = true;
        } catch (Exception e) {
            log.error("Redis 장전 실패", e);
        } finally {
            latch.countDown();   // 장전 완료를 알림
            lock.unlock();
        }
        return success;
    } else {
        // 락을 못 잡은 인스턴스: 장전이 끝날 때까지 대기
        try {
            latch.await(30, TimeUnit.SECONDS);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        return false;
    }
}

동작을 정리하면 이렇다. tryLock(0, ...)은 대기 시간을 0으로 줘서, 락을 즉시 못 잡으면 기다리지 않고 바로 실패를 반환한다. 그래서 가장 먼저 도착한 한 인스턴스만 isProducer == true가 되어 Producer가 되고, 나머지는 곧장 else 분기로 빠진다.

여기서 일반적인 락과 다른 점이 드러난다. 보통 락은 "못 잡았으면 잡힐 때까지 기다렸다가 임계 영역에 들어간다." 즉 모두가 결국 같은 작업(적재)을 차례로 수행한다. 하지만 여기서는 락을 못 잡은 인스턴스가 임계 영역(적재)에 끝내 들어가지 않는다. 적재는 오직 Producer 한 대만 하고, 나머지는 그 작업이 끝나기를 기다리기만 한다. 락을 "누가 임계 영역에 들어가느냐"가 아니라 "누가 Producer 역할을 맡느냐"를 정하는 용도로 쓴 셈이다.

그 "기다리기"를 담당하는 게 카운트다운 래치다. Producer는 적재를 시작하기 전에 래치 카운트를 1로 세팅하고, 적재가 끝나면(finally) countDown()으로 0으로 만든다. 락을 못 잡은 인스턴스들은 latch.await()에서 이 카운트가 0이 될 때까지 멈춰 있다가, Producer의 적재가 끝나는 순간 한꺼번에 풀려난다. 덕분에 모든 인스턴스가 "SET이 채워진 시점"에 맞춰 소비 단계로 진입하게 된다. 락이 "한 명만 적재하게" 만든다면, 래치는 "나머지가 그 적재를 기다리게" 만드는 셈이다.

조회를 한 인스턴스로 몰아도 병렬성이 죽지 않는 이유는, 무거운 작업인 외부 API 호출을 조회와 분리했기 때문이다. DB 조회는 짧고, 정작 오래 걸리는 API 호출은 뒤이은 Consume 단계에서 모든 인스턴스가 나눠서 한다.

여기서 Redis 자료구조로 SET을 고른 이유가 있다. SET은 같은 값을 중복으로 담지 않으므로, 혹시 같은 이벤트가 두 번 적재되려 해도 SADD가 멱등하게 동작해 중복 장전이 자연스럽게 방지된다. 분산 락으로 1차 방어, SET의 멱등성으로 2차 방어를 한 셈이다.

Consume — 모든 인스턴스가 SPOP으로 병렬 소비

다음으로 Consume 단계에서는 모든 인스턴스가 SPOP으로 병렬 소비한다. 래치가 풀리면 모든 인스턴스가 Redis SET에서 이벤트를 하나씩 꺼낸다. 이때 사용하는 SPOP은 SET에서 임의의 원소를 꺼내면서 동시에 제거하는 원자적 연산이다. 덕분에 여러 인스턴스가 동시에 SPOP을 호출해도 같은 이벤트를 두 번 꺼내가는 일이 없다. 1편에서 SKIP LOCKED로 얻었던 "서로 겹치지 않게 나눠 가져간다"는 성질을, 이번엔 Redis가 대신 보장해주는 것이다.

각 인스턴스는 꺼낸 이벤트로 Admin API를 호출한다. 이 호출 과정에는 트랜잭션도, DB 커넥션도 전혀 관여하지 않는다. Admin 서버가 아무리 느려도 DB 커넥션 풀에는 영향이 없다.

이 구조가 가져다준 변화는 세 가지다.

첫째, 외부 API 호출 시 DB 커넥션을 전혀 잡지 않는다. 1편부터 이어진 커넥션 장기 점유 문제가 구조적으로 사라졌다. 폴링 경로에 남아 있던 마지막 트랜잭션까지 걷어낸 것이다. 1편의 두 번째 숙제가 여기서 해결됐다.

둘째, 복구 스케줄러가 필요 없다. "처리 중" 상태를 DB에 커밋하지 않기 때문이다. 이벤트는 Redis SET에 있거나(아직 처리 전), SPOP으로 꺼내져 처리되거나 둘 중 하나다. V2에서 가장 거슬렸던 timeout 임계값 고민이 문제의 근원과 함께 통째로 사라졌다.

셋째, 인스턴스 수와 무관하게 자동으로 분산 처리된다. SPOP이 원자적으로 분배해주므로, 인스턴스를 늘리면 늘린 만큼 병렬로 소비한다. 1편에서 BATCH_SIZE를 인스턴스 수와 TPS로 계산해 박아야 했던 부담이 사라졌다. 1편의 첫 번째 숙제가 여기서 해결됐다.

세 버전 비교

표를 보면 V1에서 V3로 가면서 점유, 트랜잭션, 복구 로직이 차례로 줄어든다. 특히 V3에 와서는 트랜잭션과 복구 로직이 모두 사라졌다. 복잡도를 더해 문제를 막는 게 아니라, 문제의 원인 자체를 구조에서 걷어낸 결과다. 그리고 그 과정에서 1편 말미에 남겼던 두 숙제, 배치 사이즈 수동 조정과 폴링 경로의 트랜잭션도 함께 정리됐다.

정리하며

1편을 마치며 "이 두 가지 문제점에 대해서는 추가로 고민해봐야겠다"고 적었는데, 그 고민을 따라온 것이 이번 2편이었다.

이번 개선에서 가장 인상 깊었던 건 V2에서 V3로 넘어가는 발상의 전환이었다. V2 단계에서 나는 "복구 스케줄러의 timeout을 몇 초로 잡아야 할까"를 고민하고 있었다. 그건 주어진 구조 안에서 더 나은 파라미터를 찾는 질문이었다. 하지만 한 발 물러서서 "애초에 이 복구 스케줄러가 왜 필요하지?"라고 물었을 때, 비로소 진짜 원인이 보였다. PROCESSING 상태를 DB에 커밋한다는 결정이었다. 그 결정을 바꾸자, 그 위에 쌓아 올렸던 복구 로직과 timeout 고민이 한꺼번에 사라졌다.

돌이켜보면 1편의 BATCH_SIZE 튜닝도, 2편 V2의 timeout 튜닝도 결국 같은 종류의 고민이었다. 주어진 구조를 그대로 둔 채 "숫자를 얼마로 맞출까"를 묻는 것. 문제를 만났을 때 "이걸 어떻게 막을까"를 먼저 떠올리기 쉽고, 그래서 보호 장치를 덧대거나 매직 넘버를 조정하는 방향으로 가게 된다. 하지만 때로는 "이 문제가 왜 생기는 구조지"를 묻고 그 원인을 제거하는 편이 훨씬 단순하고 단단한 답을 준다는 걸 이번에 배웠다. 좋은 설계는 더 정교한 방어막을 쌓는 게 아니라, 방어할 필요 자체를 없애는 쪽에 가깝다는 생각이 들었다.

문제 상황

PeakTime의 주요 기능은 미션을 수행하고 그 기록을 남기는 것이다. 아래 코드는 미션을 수행할 때마다 호출되는데, 미션이 수행될 때마다 @Transactional 내부에서 Admin 서버로 미션 완료 기록을 요청한다.

@Transactional
public UserMissionCompletionResponse completeDailyMission(Long userId, Long missionId, UserMissionCompletionRequest request) {
    User user = findUser(userId);
    LocalDate today = LocalDate.now();

    DailyMission dailyMission = getDailyMission(missionId, today);
    Mission mission = dailyMission.getMission();

    validateSameMission(missionId, user);

    SolarTerm solarTerm = getCurrentSolarTerm(today);

    UserMissionCompletion completion = userMissionCompletionRepository.save(
            UserMissionCompletion.create(user, mission, solarTerm, MissionType.DAILY,
                    request.objectKey(), request.memo())
    );

    dailyMissionRepository.incrementParticipantCount(dailyMission.getId());

    // 문제: @Transactional 내부에서 HTTP 호출
    // → DB 커넥션을 계속 점유한 채로 외부 API 응답 대기
    // → 커넥션 풀 고갈 위험
    sendMissionLogToAdmin(user, missionId, solarTerm, completion);

    return UserMissionCompletionResponse.from(completion);
}

그렇다면 트랜잭션 안에서 Admin으로 API를 호출하면 어떤 문제가 발생할까? 크게 두 가지다. 하나는 외부 API 호출에는 성공했지만 이후 트랜잭션이 롤백되는 경우이고, 다른 하나는 외부 API 응답이 지연될 때 커넥션이 고갈되는 경우다.

PeakTime은 사용자마다 미션 기록 횟수를 Admin 페이지에서 순위에 맞게 보여줘야 한다. 그런데 사용자가 미션 기록을 수행해 Admin 서버 요청에는 성공했지만 이후 트랜잭션 내에서 롤백이 일어나면, Admin에 보이는 횟수와 실제 사용자 기록 횟수의 정합성이 깨진다.

또한 미션 기록은 PeakTime의 핵심 기능이다. 기록이 많아져 트랜잭션 호출이 잦아지는데 그때마다 @Transactional 내부에서 커넥션을 장기간 점유한다면, 커넥션이 고갈될 수 있다.

문제 상황을 다시 정리하면 두 가지다. API 호출과 트랜잭션 안의 도메인 로직이 원자적으로 묶여 있지 않다는 것, 그리고 Admin 서버 상황에 따라 DB 커넥션을 장기간 점유한다는 것이다.

그렇다면 어떻게 원자적으로 묶을 수 있을까? 여기서 Transactional Outbox 패턴이 등장한다.

Transactional Outbox 패턴이란

핵심 아이디어는 데이터베이스의 원자성을 활용하는 것이다.

하나의 트랜잭션은 원자성을 보장하기 때문에 반드시 전부 롤백되거나 전부 커밋된다. 따라서 핵심 비즈니스 로직과 외부로 보낼 데이터(이벤트)를 하나의 트랜잭션으로 묶어 처리하면 된다.

구체적으로는, 외부로 보내야 할 데이터나 이벤트를 메인 데이터베이스의 별도 테이블(Outbox)에 함께 저장하고, 별도의 워커(Worker)가 그 테이블의 레코드를 읽어 외부로 요청을 보내는 방식이다.

Before (트랜잭션 내 HTTP 호출):
completeMission() → DB 저장 + HTTP 호출 (Admin 서버)  ← DB 커넥션 점유한 채 대기

After (이벤트 + Outbox):
completeMission() → DB 저장 + Outbox 저장 + 이벤트 발행 (같은 트랜잭션)

API 요청은 언제 하는 게 좋을까

API를 보내는 방법은 두 가지가 있다. 하나는 커밋 이후 비동기로 해당 이벤트를 조회해 API를 요청하는 방법이고, 다른 하나는 주기적으로 Outbox 테이블을 조회해 API를 요청하는 방법이다.

커밋 직후 비동기로 호출하면, 주기적으로 폴링해서 보내는 것보다 결과를 더 빨리 알 수 있다. 그래서 비동기 호출을 마다할 이유는 없다고 판단했다. 그리고 여기서 실패한 경우는 스케줄링을 통해 Outbox를 조회한 뒤 다시 처리하면 되지 않을까? 우선 비동기 요청을 처리하기 위한 로직을 구현해보았다.

@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
@Async
public void handle(MissionCompletedEvent event) {
    UserMissionCompletion completion = findCompletion(event.getCompletionId());
    MissionLogPayload payload = createPayload(completion);

    SendResult result = adminClient.sendMissionLog(payload, event.getOutboxId());

    handleSendResult(event, result, completion);
}

이 메서드에는 의도적으로 @Transactional을 붙이지 않았다. 이벤트를 조회해 페이로드를 만들고, Admin으로 전송한 뒤 그 결과(SendResult)에 따라 Outbox를 삭제하거나 재시도를 예약하는 것이 전부라, 별도의 트랜잭션이 없어도 괜찮다고 판단했다. 만약 트랜잭션이 있다면, 앞서 본 "메서드 내부에서 API를 호출하는" 것과 똑같은 문제가 발생한다. 이 이벤트 리스너는 커밋 이후에 실행되므로 요청 수와 동일한 횟수로 호출되는데, 요청이 많아지면 결국 트랜잭션 내부에서 외부 API를 호출하는 꼴이 되어 커넥션 고갈로 이어질 수 있다.

전송 결과 분기는 앞서 정의한 실패 케이스(영구/일시)에 따라 handleSendResult에서 처리한다. 성공이나 영구적 실패라면 더 이상 재시도가 무의미하므로 Outbox에서 삭제하고, 일시적 실패라면 레코드를 남겨 폴링 스케줄러가 나중에 다시 시도하도록 둔다.

위 코드에서는 @Async로 별도의 스레드 풀에서 비동기로 처리된다. 만약 여기에 트랜잭션이 걸려 있다면, 작업 중인 워커 스레드는 커넥션과 1대1로 묶일 수밖에 없다. 그러면 스레드 풀이 고갈되기 전에 커넥션 풀이 먼저 고갈될 가능성이 생긴다. 문득 든 생각은, 그렇다면 스레드 풀의 개수로 커넥션 소모량을 제어할 수 있지 않을까 하는 것이었다. 다만 지금 구조에서는 트랜잭션이 필요하지 않으니 이 고민은 넘어가기로 했다.

그런데 이 비동기 구조에서는 다음과 같은 상황들이 발생할 수 있다.

• sendLogToAdmin에서 외부 API 요청은 성공했지만, Outbox 테이블에서 delete에 실패한 경우
• Admin 쪽 로직에서 통계 기록은 성공했지만, 네트워크 문제로 알 수 없는 예외가 발생한 경우
• 실제로 API 요청이 실패해 Outbox 테이블에 레코드가 그대로 남은 경우

실패 케이스 나누기

Admin 서버에 요청을 보낸 뒤, API 서버 입장에서는 그 요청이 실제로 성공했는지 알 수 없을 때가 있다. 외부 서버는 정상적으로 처리했더라도 응답이 돌아오는 과정에서 네트워크 문제로 예외가 날 수 있고, 타임아웃으로도 예외가 발생할 수 있다. 흔히 이런 경우를 "알 수 없는 예외 상황"이라 부른다.

알 수 없는 예외 상황을 어떻게 다룰지는 정책에 따라 다르겠지만, 정합성이 중요한 상황에서는 재시도가 필수적이다. PeakTime은 Admin 서버로 보낸 미션 기록을 집계해 순위를 매기고 그것을 기반으로 보상을 제공하기 때문에, 재시도가 반드시 필요하다고 판단했다. 그래서 실패 상황을 두 가지로 정의했다.

먼저 영구적 실패(Permanent Failure)는 비즈니스 로직이나 검증에 의한 실패다. Admin 서버의 도메인 규칙을 위반했거나 요청 페이로드가 잘못되어 4xx 에러(Client Error)를 반환하는 경우가 여기에 해당한다. 이 케이스는 같은 요청을 아무리 재시도해도 계속 같은 실패 응답을 받기 때문에, 재시도할 이유가 없다.

다음으로 일시적 실패(Transient Failure)는 일시적인 네트워크 오류나 타임아웃에 의한 실패다. 네트워크 단절, 커넥션 타임아웃, 혹은 Admin 서버 자체의 일시적인 문제로 인한 5xx 에러(Server Error)가 이에 해당한다. 시스템 환경이 정상화되면 재시도를 통해 성공할 가능성이 있는 케이스다.

이 분류에 맞게 RestClient로 예외 처리를 구현했다. 아래는 Admin 서버로 요청을 보낸 뒤, 예외의 성격에 따라 실패 케이스를 분류하는 메서드다. 기본적으로 4xx 에러는 재시도가 무의미한 영구적 실패로 분류하지만, 충돌 등으로 일시적으로 발생할 수 있는 409 Conflict만큼은 예외적으로 일시적 실패로 간주해 재시도 대상에 포함했다.

public SendResult sendMissionLogWithResult(MissionLogPayload payload, Long eventId) {
    try {
        AdminApiResponse response = adminRestClient.post()
                .uri("/api/stats/mission-log")
                .contentType(MediaType.APPLICATION_JSON)
                .body(payload)
                .retrieve()
                .body(AdminApiResponse.class);

        log.info("미션 로그 전송 성공: missionId={}", payload.missionId());
        return new SendResult.Success(eventId);

    } catch (HttpClientErrorException.Conflict e) {
        // 409 Conflict: 동시에 같은 요청이 처리 중 → 일시 실패 (재시도 필요)
        log.info("미션 로그 처리 중 (409 Conflict): missionId={}", payload.missionId());
        return new SendResult.TransientFailure(eventId, "409 Conflict: 처리 중");

    } catch (HttpClientErrorException e) {
        // 4xx (409 제외): 클라이언트 에러 → 영구 실패 (재시도 무의미)
        log.warn("미션 로그 클라이언트 에러 (영구 실패): missionId={}, status={}",
                payload.missionId(), e.getStatusCode());
        return new SendResult.PermanentFailure(eventId, "4xx: " + e.getStatusCode());

    } catch (HttpServerErrorException e) {
        // 5xx: 서버 에러 → 일시 실패 (재시도 가능)
        log.warn("미션 로그 서버 에러 (일시 실패): missionId={}, status={}",
                payload.missionId(), e.getStatusCode());
        return new SendResult.TransientFailure(eventId, "5xx: " + e.getStatusCode());

    } catch (Exception e) {
        // 네트워크 오류, 타임아웃 등 → 일시 실패 (재시도 가능)
        log.error("미션 로그 전송 실패 (일시 실패): {}", e.getMessage());
        return new SendResult.TransientFailure(eventId, e.getMessage());
    }
}

각 예외의 성격에 맞게 SendResult 내부 클래스에 상태와 이벤트 ID를 담아 반환하고, 이후 스케줄러나 배치 영역에서 이 반환값을 기반으로 Outbox 테이블의 데이터를 삭제하거나 다음 재시도를 예약한다.

AFTER_COMMIT + 폴링 재시도

정리하면, 커밋 이후 비동기로 API 요청을 보내고(즉시 발송), 여기서 실패해 Outbox 테이블에 남은 레코드는 30초마다 폴링 재시도로 다시 요청을 보낸다. 동작 흐름은 아래와 같다.

먼저 재시도를 담당하는 스케줄러다. 스케줄러에서 커넥션 점유 시간을 측정하기 위해, 실제 처리는 별도의 빈으로 분리해 호출하는 형태로 구현했다.

@Scheduled(fixedDelay = 30000)  // 30초마다
public void pollAndProcess() {
    long startTime = System.currentTimeMillis();
    log.info("[Task Start] 시작 시각: {}", LocalDateTime.now());

    // @Tx 시작
    processer.process();

    long endTime = System.currentTimeMillis();
    log.info("[Task End] 끝 시각: {}", LocalDateTime.now());

    // 소요 시간 계산 (끝 시각 - 시작 시각)
    long duration = endTime - startTime;
    log.info("[Performance Result] 작업 완료! 소요 시간: {} ms (약 {} 초)", duration, duration / 1000.0);
}

그리고 실제 외부 요청을 처리하는 부분이다.

@Transactional
public void process() {
    LocalDateTime threshold = LocalDateTime.now().minusSeconds(3);
    List<OutboxEvent> events = outboxRepository.findByCreatedAtBeforeWithSkipLocked(threshold);

    if (events.isEmpty()) {
        log.info("기록해야 하는 미션이 존재하지 않습니다.");
        return;
    }

    log.info("Outbox 폴링: {}건 처리 시작", events.size());
    ProcessingResult result = processAllEvents(events);

    // TX: 성공 시 Outbox 테이블에서 삭제
    deleteProcessedEvents(result.toDelete());
    logUnknownEvents(result.unknownCount());
}

중복 요청은 언제 발생할까 (멱등성)

앞서 말했듯이 클라이언트 입장에서는 서버 쪽에서 네트워크 에러나 타임아웃이 발생하면 재시도를 해야 한다. 그런데 재시도를 하다 보면 한 번만 수행되어야 할 작업이 여러 번 수행될 수 있다. 현재 구조에서도 이런 중복이 발생할 여지가 있었다.

위에서 살펴본 상황들 외에도, 즉시 발송하는 비동기 이벤트와 폴링 스케줄러가 동시에 실행되어 같은 요청이 두 번 나가는 경우도 가능하다. 근본적으로는 Admin 서버에서 멱등성 키로 중복 요청을 막아야 하지만, 불필요한 요청 자체를 줄이기 위해 Outbox 테이블에서 생성된 지 3초 이상 지난 레코드만 조회하도록 했다. 즉시 발송이 처리 중인 따끈따끈한 레코드를 폴링이 곧바로 집어가지 않도록 한 것이다.

LocalDateTime threshold = LocalDateTime.now().minusSeconds(3);
List<OutboxEvent> events = outboxRepository.findByCreatedAtBeforeWithSkipLocked(threshold);

다중 인스턴스 환경에서의 중복 발행

서버를 2대 이상으로 스케일 아웃한 다중 인스턴스 환경에서는, 각 서버의 @Scheduled 메서드가 동시에 실행되면서 동일한 Outbox 이벤트를 중복으로 조회하고 API를 중복 요청하는 문제가 생길 수 있다.

이런 스케줄러 중복 실행을 막기 위해, 흔히 한 인스턴스만 작업을 수행하도록 고정하는 분산 락을 떠올리곤 한다. 하지만 분산 락을 쓰면 특정 시점에 오직 한 대의 서버만 스케줄러를 실행할 수 있어서, 다중 인스턴스 구조가 가진 병렬 처리의 이점을 살리지 못하고 나머지 서버의 리소스가 놀게 된다는 아쉬움이 있었다.

고민 끝에 선택한 해결책은 MySQL의 SELECT ... FOR UPDATE SKIP LOCKED 구문이다.

@Query(value = "SELECT * FROM outbox_event WHERE created_at < :threshold ORDER BY created_at LIMIT 5 FOR UPDATE SKIP LOCKED",
        nativeQuery = true)
List<OutboxEvent> findByCreatedAtBeforeWithSkipLocked(@Param("threshold") LocalDateTime threshold);

이 쿼리는 다른 트랜잭션이 이미 락을 획득한 행이 있으면, 그 행을 얻으려 대기하지 않고 그냥 건너뛴 뒤 락이 걸리지 않은 다음 행을 즉시 가져온다.

이를 Outbox 이벤트 조회에 적용하면 세 가지 이점을 얻는다. 첫째, 각 서버 인스턴스가 서로 겹치지 않는 레코드를 나눠 가져가므로 동일한 이벤트에 대한 중복 API 요청이 원천적으로 차단된다. 둘째, 모든 서버 인스턴스가 대기 없이 동시에 자기 할당량을 가져와 처리하므로 병렬 스케줄러를 제대로 구현할 수 있다. 셋째, 행 단위 락 경쟁으로 인한 스케줄러 간 대기가 없고, 분산 시스템의 고질적인 문제인 데드락 위험에서도 자유로워진다.

조회 건수는 트래픽을 기준으로 정했다. 미션 기록 요청이 1초에 1번 온다고 휴리스틱하게 가정하면, 스케줄러 주기인 30초 동안 최악의 경우 Outbox 테이블에 30건의 레코드가 쌓인다. 서버가 2대라면 이 30건을 병렬로 나눠 처리해야 하므로, 한 인스턴스당 BATCH_SIZE를 15건씩 조회하도록 설정했다.

정리

이번 작업을 통해 Transactional Outbox 패턴과 실패 케이스 분류 등, 서버 간 API 통신에서 발생할 수 있는 문제들을 처음으로 깊이 고민해볼 수 있었다.

다만 아쉬운 점도 남았다. 다중 서버 환경에서 병렬로 처리하기 위해 TPS와 서버 개수를 기준으로 배치 사이즈를 정했는데, 이 방식은 서버 인스턴스를 증설할 때마다 배치 사이즈를 다시 손봐야 한다. 또한 TPS가 올라가 최악의 상황에 Outbox 테이블에 쌓이는 레코드가 많아질 때도 마찬가지로 배치 사이즈를 조정해야 한다.

그리고 현재 스케줄러는 30초마다 호출되는데, 단일 스레드로 동작하긴 하지만 이 역시 트랜잭션 내부에서 API를 호출한다. 이 두 가지 문제점은 다음 글에서 이어서 고민해보려 한다.

학교 API 응답시간 분석

운영 서버에서 학교 포털 서버로 curl 명령어를 통해 응답 시간을 분석해 보았다.

{
  "DNS 조회 시간": 0.001779s,
  "TCP 연결 시간": 0.012955s,
  "SSL/TLS 핸드쉐이크": 0.030608s,
  "첫 데이터 수신(TTFB)": 0.039398s,
  "-----------------": "-----------------",
  "전체 소요 시간": 0.039451s
}

위 결과는 누적 시간이므로, 이전 단계까지 걸린 시간을 빼서 각 구간의 순수 소요 시간을 구하고, 전체 소요 시간에서 차지하는 비율을 계산해 보았다.

전체 시간 39.4ms 중 데이터를 주고받기 위한 준비 단계(DNS + TCP + SSL)에만 30.6ms가 소요되었다. 즉, 전체 요청 시간의 약 77%가 네트워크 연결을 맺는 데 쓰이고 있다. 실제 서버가 비즈니스 로직을 처리하는 시간(8.7ms)보다 연결을 만드는 시간이 약 3.5배 더 길다는 것을 알 수 있다.

물론 순수 서버 처리 시간(TTFB)에는 실제 데이터를 주고받는 네트워크 시간이 일부 포함되어 있다. 하지만 그 부분을 감안하더라도, 대부분의 시간이 커넥션을 맺는 데 쓰이고 있다는 사실은 분명했다.

학교 서버는 커넥션을 유지할까?

HTTP/1.1부터는 지속적인 연결(persistent connection)을 지원한다. Connection: keep-alive 헤더를 통해 커넥션을 재사용할 수 있다는 것을 알 수 있다. 그런데 HTTP/1.1부터는 keep-alive가 기본값이라 헤더를 생략해도 된다고 하는데, 왜 학교 서버는 굳이 헤더에 명시적으로 넣어줄까? 찾아보니 서버 앞단의 보안 장비나 로드밸런서에서 이 헤더를 명시적으로 붙여주는 경우가 있다고 한다.

curl -i -s -A "Mozilla/5.0" \
-e "https://portal.sej****.ac.kr" \
--data-urlencode "mainLogin=N" \
--data-urlencode "id=*******" \
--data-urlencode "password=*********" \
"https://***********************" | head -n 25
HTTP/1.1 200 OK
Server: Apache
Date: Mon, 27 Apr 2026 10:27:11 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 2060
Connection: keep-alive
X-ORACLE-DMS-ECID: aa7c22e1-262d-48bd-abe4-24bf5a67be31-0097724e
X-ORACLE-DMS-RID: 0

응답 헤더를 보면 학교 서버가 커넥션을 유지한다는 것은 알 수 있다. 하지만 몇 초 동안 유지하는지는 알 수 없다. 만약 커넥션을 1초만 유지한다고 가정하면, 그 짧은 시간 안에 다음 요청이 들어와 커넥션을 재사용할 일은 거의 없을 것이다. 트래픽이 아주 많다면 1초 동안에도 많은 요청이 커넥션을 재사용하겠지만, 현재 미팀 서비스의 트래픽 규모에서는 사실상 무의미한 유지 시간이 된다.

Keep-Alive: timeout=5, max=100처럼 헤더에 timeout과 max 요청 수를 명시적으로 알려주는 경우도 있지만, 학교 서버는 이를 생략했거나 의도적으로 공개하지 않은 것으로 보인다. 결국 미팀 서버에서 의미 있는 성능 개선을 하려면, 학교 서버가 커넥션을 얼마나 유지하는지를 먼저 알아야 커넥션을 안정적으로 재사용할 수 있다고 판단했다.

학교 서버의 timeout 측정하기

학교 서버와의 커넥션 유지 시간을 직접 측정해 보기로 했다. 터미널 1에서는 openssl 명령어로 443 포트에 연결을 맺어 유지하고, 터미널 2에서는 while 스크립트로 1초마다 그 연결이 살아있는지 확인했다.

while true; do
  # openssl이 443 포트로 연결을 맺고 있는지 확인
  STATUS=$(lsof -i :443 | grep openssl)

  if [ -z "$STATUS" ]; then
    echo "---------------------------------------"
    echo "X [$(date +%T)] 커넥션이 끊겼습니다. (실험 종료)"
    echo "---------------------------------------"
    break
  fi

  echo "O [$(date +%T)] 연결 유지 중..."
  sleep 1
done
O [19:50:33] 연결 유지 중...
O [19:50:34] 연결 유지 중...
O [19:50:35] 연결 유지 중...
O [19:50:36] 연결 유지 중...
O [19:50:38] 연결 유지 중...
--- 생략
O [19:55:49] 연결 유지 중...
O [19:55:50] 연결 유지 중...
---------------------------------------
X [19:55:51] 커넥션이 끊겼습니다. (실험 종료)
---------------------------------------

대략 5분 20초(320초) 동안 커넥션이 유지되는 것을 확인할 수 있었다. 예상보다 학교 서버는 꽤 오랜 시간 동안 커넥션을 유지하도록 설정되어 있었다. 재사용 가능한 시간이 충분히 길기 때문에, 학교 서버로 요청이 많이 몰리더라도 커넥션을 재사용해 연결 비용을 줄일 수 있겠다고 판단했다.

짧은 시간 안에 요청이 많을 경우

그렇다면 짧은 시간 안에 로그인 요청이 한꺼번에 몰리면 어떻게 될까? 요청 속도 > 커넥션 반환 속도인 상황이라면, 앞선 요청이 커넥션을 반납하기 전에 다음 요청이 들어오므로 커넥션을 재사용할 수 없다.

이런 상황에서는 커넥션을 재사용하지 못하고 매번 새로운 커넥션을 만들어 요청을 보내게 된다. 물론 지금은 한 요청이 커넥션을 점유하는 시간이 짧기 때문에 이런 상황은 비교적 낮은 확률로 발생한다. 위 그림의 요청1, 요청2, 요청3처럼 동시 요청이 들어오면, 그 동시 요청 수만큼 외부 서버와 커넥션을 새로 맺게 된다.

이는 문제가 될 수 있다. 짧은 시간에 다량의 커넥션 생성과 요청이 발생하면 외부 API 서버 입장에서는 DDoS 공격처럼 보일 수 있고, 끊긴 커넥션이 TIME_WAIT 상태로 쌓이면서 포트 자원이 고갈되는 문제도 생길 수 있다. 따라서 외부 서버와 소통하는 커넥션을 잘 관리하는 것이 중요하다.

실제로 동시 요청이 발생했을 때 서버가 새로운 커넥션을 생성해 병렬로 처리하는지 확인하기 위해 실험을 진행했다. Apache Bench로 10명의 사용자가 동시에 로그인을 시도하는 상황을 시뮬레이션했고, netstat 명령어로 실시간 ESTABLISHED 상태의 TCP 커넥션 개수를 확인했다.

ab -n 200 -c 10 -k -p post_data.txt -T "application/json" http://localhost:8080/api/v1/auth/login/sejong & sleep 0.2; netstat -an | grep 8080 | grep ESTABLISHED

Benchmarking localhost (be patient)
tcp6       0      0  ::1.8080               ::1.53425              ESTABLISHED
tcp6       0      0  ::1.53425              ::1.8080               ESTABLISHED
tcp6       0      0  ::1.8080               ::1.53424              ESTABLISHED
tcp6       0      0  ::1.53424              ::1.8080               ESTABLISHED
tcp6       0      0  ::1.8080               ::1.53423              ESTABLISHED
tcp6       0      0  ::1.8080               ::1.53422              ESTABLISHED
tcp6       0      0  ::1.53423              ::1.8080               ESTABLISHED
tcp6       0      0  ::1.53422              ::1.8080               ESTABLISHED
tcp6       0      0  ::1.8080               ::1.53421              ESTABLISHED
tcp6       0      0  ::1.8080               ::1.53420              ESTABLISHED
tcp6       0      0  ::1.53421              ::1.8080               ESTABLISHED
tcp6       0      0  ::1.53420              ::1.8080               ESTABLISHED
tcp6       0      0  ::1.8080               ::1.53419              ESTABLISHED
tcp6       0      0  ::1.8080               ::1.53418              ESTABLISHED
tcp6       0      0  ::1.53419              ::1.8080               ESTABLISHED
tcp6       0      0  ::1.53418              ::1.8080               ESTABLISHED
tcp6       0      0  ::1.8080               ::1.53417              ESTABLISHED
tcp6       0      0  ::1.8080               ::1.53416              ESTABLISHED
tcp6       0      0  ::1.53417              ::1.8080               ESTABLISHED
tcp6       0      0  ::1.53416              ::1.8080               ESTABLISHED

예상대로 동시 요청을 보낼 경우 새로운 커넥션을 생성해 학교 로그인 API로 요청을 보낸다. 이렇게 동시 요청이 많으면 학교 서버 쪽에서 DDoS 공격으로 인지할 수 있기 때문에, 학교 서버와 맺는 커넥션 수를 제한하고 재사용하는 편이 좋겠다고 판단했다.

커넥션 풀을 사용하자

학교 서버는 대략 320초 동안 커넥션을 유지한다는 것을 확인했다. 그렇다면 클라이언트(미팀 서버)에서 320초 이상 커넥션을 붙들고 있으면 어떻게 될까? 이미 서버 쪽에서 끊어버린 커넥션을 들고 요청을 보내봤자 오류가 발생할 것이다. 즉, 클라이언트만 연결이 살아있다고 착각한 채로 요청을 보내고, 결국 사용자에게 오류 응답을 내려주게 된다. 게다가 앞선 그림처럼 커넥션 풀 없이 동시 요청이 들어오면 keep-alive의 이점을 전혀 누릴 수 없다.

커넥션을 효율적으로 유지하기 위해 두 가지 방법을 생각해 보았다.

1. keep-alive가 끝나기 전(약 320초)에 주기적으로 API를 재요청해서 커넥션을 살려두기
2. 커넥션 풀을 미리 만들어 두고, 320초가 되기 전에 유휴 커넥션을 정리하며 관리하기

1번은 주기적으로 요청을 보내 커넥션을 계속 살려두는 방식인데, 처음에는 이 방법을 시도하려 했다. 하지만 학교 서버의 keep-alive max 값(커넥션당 허용 요청 수)을 알 수 없기 때문에, 계속 요청을 보내다 보면 허용 요청 수를 초과해 오히려 연결이 끊어질 수 있다. 게다가 320초가 되기 전마다 빠짐없이 요청을 보내야 한다는 부담도 있었다.

학교 서버는 keep-alive 헤더에 timeout과 max 값을 함께 내려주지 않기 때문에 max 값은 알 수 없고, timeout은 직접 실험했을 때 약 320초로 측정되었다. 이 값을 기준으로 커넥션 풀 파라미터를 설정하기로 했다.

HikariCP에서 idleTimeout은 유휴 커넥션이 사용되지 않을 때 풀에서 제거하기까지의 시간을 뜻한다. 같은 맥락으로, 외부 HTTP 통신에 사용하는 Apache HttpClient에서는 evictIdleConnections()로 유휴 커넥션의 타임아웃을 지정할 수 있다. 현재 학교 서버의 keep-alive timeout이 약 320초로 측정되었으므로, 그보다 짧은 시간 안에 미팀 서버(클라이언트)가 먼저 커넥션을 끊어줘야 죽은 커넥션으로 요청을 보내는 상황을 막을 수 있다.

또한 DDoS로 오인되는 상황을 방지하기 위해 최대 커넥션 개수를 5개로 제한했다. 학교 서버로의 로그인 요청 평균 응답 시간이 약 200ms로 측정되었으므로, 커넥션 1개당 초당 약 5건(1000 / 200)을 처리할 수 있다. 따라서 5개의 커넥션이면 초당 약 5 × 5 = 25건의 로그인 요청을 감당할 수 있고, 현재 미팀 서비스의 규모에서는 이 정도면 충분하다고 판단했다.

배포 직후 학교 서버 API 요청 시

커넥션 풀을 사용하더라도 기본적으로 keep-alive로 커넥션이 유지되고 있는 상태라면, 평상시 성능에는 큰 변화가 없을 것이다. 그래서 변화가 두드러질 만한 배포 직후 상황을 들여다보기로 했다. 배포 직후 학교 API로 2번씩, 총 10번 요청을 보내 보았다. 그런데 첫 번째 요청이 두 번째 요청보다 약 6배 이상 느린 상황을 확인할 수 있었다.

위 그래프에서 볼 수 있듯이, 첫 요청은 약 1500ms, 두 번째 요청은 약 250ms가 소요되었다.

첫 요청 시에는 학교 서버와 아직 커넥션을 맺지 않은 상태이므로, 두 번째 요청과 달리 TCP 연결 + SSL 핸드셰이크 비용이 전체 응답 시간에 포함된다. 여기까지는 자연스럽다. 하지만 그 비용이 두 요청의 차이인 1500 - 250 = 1250ms나 된다는 점이 이상했다. 커넥션 수립에만 1초가 넘게 걸린다는 건 상식적으로 너무 컸다.

그래서 미팀 서버(클라이언트)에서 학교 서버로 curl 명령어를 보내, TCP 연결 + SSL 핸드셰이크에 실제로 걸리는 지연 시간을 직접 측정해 보았다.

• 첫 요청

DNS: 0.083265s
TCP: 0.091098s
SSL: 0.119399s
Total: 0.127828s

• 두 번째 요청

DNS: 0.002056s
TCP: 0.018932s
SSL: 0.046125s
Total: 0.054546s

물론 그래프는 내 로컬 → 미팀 서버 → 학교 서버로 요청한 상황이고, curl은 미팀 서버 내부에서 학교 서버로 직접 보낸 것이라 경로가 다르다. 즉 내 로컬과 미팀 서버 사이의 네트워크 비용은 빠져 있다. 하지만 그 차이를 감안하더라도, 커넥션 수립과 SSL 핸드셰이크에 1250ms가 걸렸을 가능성은 0에 가깝다. 첫 요청의 커넥션 비용은 길어야 100~200ms 수준이었다.

그렇다면 나머지 시간은 어디로 갔을까? 적어도 커넥션 수립 비용만큼은, 배포 직후에 미리 커넥션을 만들어 두면 첫 요청에서 조금이나마 줄일 수 있을 것이다.

커넥션 풀 워밍업 해보기

직접 눈으로 확인하고 싶어, 배포 시점에 ApplicationRunner를 통해 학교 API로 요청을 보내 커넥션을 미리 만들어 두었다.

@Slf4j
@Component
@RequiredArgsConstructor
public class WarmUpRunner implements ApplicationRunner {

    private final SejongPortalClient sejongPortalClient;

    @Value("${app.warmup.enabled:true}")
    private boolean warmupEnabled;

    @Override
    public void run(ApplicationArguments args) {
        if (!warmupEnabled) {
            log.info("=== Warm-up 비활성화됨 (app.warmup.enabled=false) ===");
            return;
        }

        log.info("=== 애플리케이션 Warm-up 시작 ===");
        long startTime = System.currentTimeMillis();

        try {
            // 세종대 포털 커넥션 풀 워밍업
            sejongPortalClient.warmUp();
            log.info("세종대 포털 커넥션 풀 Warm-up 완료");
        } catch (Exception e) {
            log.warn("세종대 포털 Warm-up 실패 (서비스는 정상 동작): {}", e.getMessage());
        }

        long elapsed = System.currentTimeMillis() - startTime;
        log.info("=== 애플리케이션 Warm-up 완료 ({}ms) ===", elapsed);
    }
}

커넥션을 미리 만들어 둔 뒤, 앞과 같은 조건으로(2번씩 총 10번) 학교 서버에 요청을 보내 보았다.

HTTP 커넥션을 미리 생성해 두자 첫 요청이 눈에 띄게 줄었다. 기존에는 첫 요청이 두 번째 요청보다 약 6배 이상 느렸지만, 약 4.5배로 단축되었다.

분명 개선이긴 하지만, 여전히 첫 요청은 두 번째 요청보다 4.5배나 느리다. 커넥션 비용을 미리 지불했는데도 격차가 이만큼 남아 있다는 건, 첫 요청을 무겁게 만드는 진짜 원인이 네트워크가 아니라 다른 곳에 있다는 뜻이었다.

배포 이후 사용되는 클래스 Warm-up

남은 비용은 네트워크가 아니라 애플리케이션 내부, 정확히는 스프링 초기화와 JVM에 있었다.

JVM은 애플리케이션이 실행되는 도중에 필요한 클래스를 그때그때 로딩한다(lazy class loading). 또한 자주 실행되는 코드를 JIT 컴파일러가 기계어로 최적화하기 전까지는 바이트코드를 인터프리터 방식으로 한 줄씩 느리게 실행한다. 즉, 처음 실행되는 코드 경로는 항상 가장 느리다.

로그인 요청 하나가 처리되는 과정을 떠올려 보면, 컨트롤러 → 서비스 → HTTP 클라이언트로 이어지는 동안 수많은 클래스가 처음으로 로딩되고 초기화된다. 요청 바디를 직렬화·역직렬화하는 Jackson, 검증 로직, 트랜잭션/AOP 프록시 객체 생성, HttpClient 내부 클래스들까지. 첫 요청은 커넥션 비용뿐 아니라 이 모든 "처음" 비용을 혼자서 떠안는다. 커넥션 풀만 미리 데웠을 때 첫 요청이 여전히 4.5배나 느렸던 이유가 바로 여기에 있었다. 네트워크 지연을 걷어내고 보니, 남은 실질적인 원인은 첫 요청 시점에 발생하는 스프링 내부 초기화 + JVM 클래스 로딩 오버헤드였다.

그래서 워밍업의 범위를 넓혔다. 단순히 커넥션만 미리 맺는 것이 아니라, 배포 시점에 실제 로그인 API 로직을 모의로 한 번 호출하도록 했다. 이렇게 하면 커넥션 풀이 채워지는 동시에, 로그인 경로에서 사용되는 클래스들이 미리 로딩되고 JIT가 핫스팟을 데워두게 된다. 사용자가 처음 로그인할 때 떠안던 "처음" 비용을, 사용자가 도착하기 전에 서버 스스로 미리 치르게 한 것이다.

결과는 명확했다. 실제 로그인 로직까지 워밍업하자 첫 요청 응답 시간이 약 1500ms → 320ms로 단축되었다. 두 번째 요청(약 250ms)과의 격차도 기존 약 6배에서 약 1.2배 수준까지 좁혀졌다. 배포 직후 첫 사용자가 마주하던 1초 이상의 지연이, 후속 요청과 거의 차이 없는 수준으로 사라진 것이다.

결국 첫 요청을 무겁게 만들던 비용은 네트워크 커넥션 비용 + 스프링 초기화·JVM 클래스 로딩 비용 두 갈래였고, 실제 로그인 로직을 모의 호출하는 한 번의 워밍업으로 두 가지를 모두 미리 데워둠으로써 사용자가 처음 마주하는 응답을 후속 요청 수준으로 끌어올릴 수 있었다.

마치며

이번 작업은 "학교 API 응답이 느린데, 그 시간이 정확히 어디서 새는 걸까?"라는 단순한 궁금증에서 시작했다. 그 궁금증을 따라가다 보니 다음과 같은 흐름으로 정리되었다.

• 측정: 학교 API 응답 시간의 약 77%가 비즈니스 로직이 아니라 커넥션을 맺는 데(DNS + TCP + SSL) 쓰이고 있었다.
• 확인: 학교 서버는 커넥션을 약 320초간 유지하므로, 재사용 가치가 충분했다.
• 관리: 다만 동시 요청이 몰리면 커넥션이 우후죽순 생겨 DDoS로 오인되거나 TIME_WAIT이 쌓일 수 있어, 커넥션 풀로 최대 5개까지만 재사용하도록 제한하고 320초보다 짧게 유휴 커넥션을 정리하도록 설정했다.
• 워밍업: 배포 직후 첫 요청이 후속 요청보다 약 6배 느린 문제를 파고든 결과, 원인이 네트워크 커넥션과 스프링 초기화·JVM 클래스 로딩 두 갈래임을 확인했다. 커넥션 풀만 데웠을 땐 여전히 4.5배가 남았지만, 배포 시점에 실제 로그인 API를 모의 호출해 커넥션과 클래스를 함께 워밍업하자 첫 요청이 1500ms → 320ms로 줄며 후속 요청과 약 1.2배 차이까지 좁혀졌다.

돌아보면 가장 의미 있었던 건 성능 수치 자체보다, "느리다"를 "어느 구간이 몇 ms 느리다"로 쪼개어 본 과정이었다. 막연히 "커넥션이 비싸겠지"라고 짐작하고 끝냈다면, 첫 요청의 1250ms 격차가 사실은 커넥션이 아니라 스프링·JVM 워밍업 문제였다는 사실은 끝내 몰랐을 것이다. 직접 curl로 커넥션 비용을 재보고 "이 숫자로는 1250ms가 설명이 안 된다"고 의심한 덕분에 진짜 원인에 닿을 수 있었다.

물론 현재 미팀의 트래픽 규모에서 이 차이가 체감될 일은 많지 않다. 하지만 외부 의존성과 통신하는 구간을 측정하고, 의심하고, 근거를 가지고 파라미터를 정하는 이 습관 자체가, 트래픽이 커졌을 때 흔들리지 않는 서비스를 만드는 밑바탕이 된다고 생각한다.

미팀 프로젝트에서는 사용자가 프로젝트에 좋아요를 토글 형식으로 누르는 상황이다. 좋아요는 한번만 누를수 있고, 한번더 누를 경우 좋아요가 취소가 된다. 하나의 프로젝트에 대해서 좋아요 요청시 동시성 문제가 발생한다고 판단했고, 이를 해결하기 위해 낙관적 락, 비관적 락의 성능비교를 통해 비관적 락을 선택하였다. 충돌이 적은 상황에서는 당연하게도 무의미한 성능차이가 발생하였고, 충돌이 많은 상황에서는 비관적 락 81.03ms, 낙관적 락 103.99ms로 측정되어 비관적 락이 더 안정적인 성능을 보였다. 하지만 여기서 좋아요 post 요청시 동시성 문제가 발생한 이유는 조회 시점과 업데이트 시점의 차이가 존재하여 발생하는 문제였고, 굳이 조회를 하지않고 DB 에서 원자적 쿼리를 통해 해결할 수 있지 않을까? 라는 생각이 들었다. update 시점에 where절을 사용하여 조회와 동시에 update를 진행하면, select for update 시점에 얻는 LOCK 보다 LOCK 소유시간이 적기 때문에 처리량이 올라가는것은 당연할 것이다.

DB 배타적 락(X락) 은 언제 걸까

write 쿼리(INSERT, UPDATE, DELETE)는 기본적으로 X락(Exclusive Lock)을 획득한다.데이터베이스에서 write 를 한 시점에 해당 row(레코드)에 대한 X Lock 을 획득한다. 이후 commit 일이 일어나기 전까지 소유하고 있다가 commit 이후에 Lock을 반납한다.

만약 트랜잭션A 가 Lock을 획득하면 commit 이 일어나기 전까지 다른 트랜잭션B는 Lock 을 획득하기 위해 대기한다. 트랜잭션 B는 설정한 LOCK_TIMEOUT 동안에 Lock 을 소유하기 위해 대기하고, LOCK_TIMEOUT 이후에는 타임아웃 오류가 발생한다.

조회시점에 X락을 획득하는 쿼리도 존재한다. SELECT FROM UPDATE 쿼리가 X락을 획득하는 쿼리이다.

// ProjectLikeService.java (현재)

@Transactional
public ToggleLikeResponse toggleWithPessimistic(Long projectId, String email) {

    // 1. Project 조회 (SELECT FOR UPDATE)
    Project project = projectRepository.findByIdForUpdate(projectId)  // ← X Lock 획득
            .orElseThrow(...);

    Member member = memberRepository.findByEmail(email)
            .orElseThrow(...);

    Optional<ProjectLike> existing =
            projectLikeRepository.findByMemberAndProject(member, project);

    if (existing.isPresent()) {
        projectLikeRepository.delete(existing.get());
        project.decreaseLike();  // like_count - 1

        return new ToggleLikeResponse(
                projectId,
                false,
                project.getLikeCount()
        );
    }

    projectLikeRepository.save(ProjectLike.create(member, project));
    project.increaseLike();  // like_count + 1

    return new ToggleLikeResponse(
            projectId,
            true,
            project.getLikeCount()
    );
}

// COMMIT 시점에 X Lock 해제

여기서 그럼 원자적 쿼리 방식으로 Race Condition을 해결할 수 있을것 같다는 생각을 했다. 이렇게 할 경우 X Lock 의 소유 시점이 위의 select 시점에 X Lock 의 소유시점보다 짧기 때문에 DB에서의 처리량이 올라갈 것이라고 판단했다. 아래의 코드는 위의 비관적 락에서 원자적 쿼리 방식으로 진행한 코드이다.

// ProjectLikeService.java (원자적 쿼리 방식)

@Transactional
public ToggleLikeResponse toggleWithAtomicQuery(Long projectId, String email) {

    // 1. Project 존재 확인 (Lock 없음)
    if (!projectRepository.existsById(projectId)) {
        throw new CustomException(ErrorCode.PROJECT_NOT_FOUND);
    }

    Member member = memberRepository.findByEmail(email)
            .orElseThrow(() -> new CustomException(ErrorCode.MEMBER_NOT_FOUND));

    // 2. 좋아요 존재 여부 확인
    boolean exists =
         projectLikeRepository.existsByMemberIdAndProjectId(
                    member.getId(),
                    projectId
            );

    if (exists) {
        // 삭제 + 원자적 감소
        projectLikeRepository.deleteByMemberIdAndProjectId(
                member.getId(),
                projectId
        );

        projectRepository.decreaseLikeCount(projectId);  // X Lock 최소

        int likeCount = projectRepository.countLikeById(projectId);

        return new ToggleLikeResponse(
                projectId,
                false,
                likeCount
        );
    }

    // 삽입 + 원자적 증가
    projectLikeRepository.save(
            ProjectLike.create(member.getId(), projectId)
    );

    projectRepository.increaseLikeCount(projectId);  // X Lock 최소

    int likeCount = projectRepository.countLikeById(projectId);

    return new ToggleLikeResponse(
            projectId,
            true,
            likeCount
    );
}

원자적 쿼리를 사용함으로 Project를 조회하는 쿼리는 존재하지 않는다. countLikeById(projectId) 를 통해서 DB 내에서 조회와 업데이트를 진행할수 있다. 아래 코드는 원자적 쿼리이다.

// ProjectRepository.java

public interface ProjectRepository extends JpaRepository<Project, Long> {

    // 원자적 증가 (like_count + 1)
    @Modifying
    @Query("""
        UPDATE Project p
        SET p.likeCount = p.likeCount + 1
        WHERE p.id = :projectId
    """)
    void increaseLikeCount(@Param("projectId") Long projectId);

    // 원자적 감소 (like_count - 1)
    @Modifying
    @Query("""
        UPDATE Project p
        SET p.likeCount = p.likeCount - 1
        WHERE p.id = :projectId
    """)
    void decreaseLikeCount(@Param("projectId") Long projectId);
}

원자적 쿼리에서 발생할 수 있는 문제점

사용자가 매우 빠르게 좋아요 요청을 두번을 보내거나, 네트워크 끊김으로 인해 좋아요가 빠르게 2번 요청이 왔다고 가정하자. 실수로 중복 요청(일명 ‘따닥’)이 발생했을때를 말한다. 이미 좋아요를 한 상태로 좋아요를 취소하려고 POST 요청을 보냈지만 2번의 요청이 빠른 찰나에 온 상황이다.

먼저 온 요청을 요청1, 두번째로 온 요청을 요청2라고 하자.

먼저 요청1은 아래와 같이 좋아요 존재 여부를 ProjectLike 테이블에서 확인할것이다. ( 해당 ROW 가 존재 유무 확인)

 // 2. 좋아요 존재 여부 확인
    boolean exists =
         projectLikeRepository.existsByMemberIdAndProjectId(
                    member.getId(),
                    projectId
            );

요구사항은 좋아요를 취소하는(토글 방식) 상황이므로 TRUE 를 return 할 것이다. TRUE이므로 아래와 같이 if 문에 진입을 하고 DELETE 를 통해서 해당 ROW을 삭제를 할것이다. 그 후 원자적 쿼리를 수행한다.( X LOCK 획득)

if (exists) {
        // 삭제 + 원자적 감소
        projectLikeRepository.deleteByMemberIdAndProjectId(
                member.getId(),
                projectId
        );
        projectRepository.decreaseLikeCount(projectId);  // X Lock 최소

        int likeCount = projectRepository.countLikeById(projectId);
        return new ToggleLikeResponse(
                projectId,
                false,
                likeCount
        );
    }

여기서 요청1이 DELETE 를 수행하기 전에 요청2가 좋아요 존재 여부 확인을 한다고 가정해보자. 빠른 2번의 요청이 올 경우 충분히 발생 가능한 상황이라고 판단했기 때문이다.

 // 2. 좋아요 존재 여부 확인
    boolean exists =
         projectLikeRepository.existsByMemberIdAndProjectId(
                    member.getId(),
                    projectId
            );

요청 1이 DELETE 를 하기 전 이므로 요청 2는 LIKE 테이블에 ROW가 존재한다고 판단하고 TRUE를 return 할 것이다. 그 후, 요청 2 역시 if (exists) 절에 진입을 할것이다. 여기서 요청1의 DELETE 여부와 상관없이 요청2 는 decreaseLikeCount 쿼리를 날릴것이다. 이 상황에서 원자적 쿼리로 count = count - 1 을 총 2번 수행을 하기 때문에 총 count 값이 2가 감소할것이다. 요청을 2번 보내면, 좋아요 수가 -1 이 되고, 한번 더 누를경우 다시 +1 이 되어 결과론 적으로는 좋아요 수 변화가 있으면 안되지만, 빠른 요청이 2번 올 경우 위 요구사항을 만족하지 못한다. 비록 좋아요 수가 비니지스 적으로 정확하게 일치하지 않아도 사용자 경험이 저하되지 않지만, 이러한 문제는 좋아요 뿐만 아니라 사용자에게 보상을 주거나 포인트가 차감될 경우 충분히 발생할수 있는 문제라고 생각했다.

1. 시스템 개요

절기가 변경될 때마다 사용자에게 미션을 제공하고 알림을 발송하는 시스템

1.1 미션 유형

1.2 핵심 설계 원칙 (MVP)

• 오늘의 미션: 관리자가 절기별 15일치 사전 지정 (수동 큐레이션)
• 개인화 미션: 태그 기반 매칭 (45개 미션 풀)
• LLM: 미션 생성 보조 (LLM이 리스트 생성 → 관리자가 선별)
• 날씨 API: MVP 제외 → 2차 고도화

2. 전체 아키텍처

2.1 MVP 아키텍처

┌─────────────────────────────────────────────────────────────────────────────┐
│                                                                             │
│                        ┌─────────────────────┐                              │
│                        │      Client App     │                              │
│                        │   (iOS / Android)   │                              │
│                        └──────────┬──────────┘                              │
│                                   │                                         │
│                                   ▼                                         │
│                        ┌─────────────────────┐                              │
│                        │    Load Balancer    │                              │
│                        │      (Nginx)        │                              │
│                        └──────────┬──────────┘                              │
│                                   │                                         │
│                 ┌─────────────────┼─────────────────┐                       │
│                 ▼                 ▼                 ▼                       │
│       ┌──────────────┐  ┌──────────────┐  ┌──────────────┐                  │
│       │  API Server  │  │  API Server  │  │ Admin Server │                  │
│       │  (Spring)    │  │  (Spring)    │  │  (Spring)    │                  │
│       └───────┬──────┘  └───────┬──────┘  └───────┬──────┘                  │
│               │                 │                 │                         │
│               └─────────────────┼─────────────────┘                         │
│                                 │                                           │
│         ┌───────────────────────┼───────────────────────┐                   │
│         ▼                       ▼                       ▼                   │
│  ┌─────────────┐        ┌─────────────┐        ┌──────────────┐             │
│  │    MySQL    │        │    Redis    │        │   LLM API    │             │
│  │  (Main DB)  │        │  (Cache)    │        │ (Claude/GPT) │             │
│  └─────────────┘        └─────────────┘        └──────────────┘             │
│                                                       ↑                     │
│                                                       │                     │
│                                              Admin Server에서 호출           │
│                                              (미션 생성 보조용)              │
│                                                                             │
│  ┌──────────────────────────────────────────────────────────────┐           │
│  │                      Scheduler (Batch)                       │           │
│  │                                                              │           │
│  │  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐          │           │
│  │  │ 오늘의미션  │  │ 절기 체크   │  │ 알림 발송   │          │           │
│  │  │ 활성화 Job  │  │ Job        │  │ Job        │          │           │
│  │  └─────────────┘  └─────────────┘  └─────────────┘          │           │
│  └──────────────────────────────────────────────────────────────┘           │
│                                 │                                           │
│                                 ▼                                           │
│                        ┌──────────────┐                                     │
│                        │  FCM / APNs  │                                     │
│                        │ (Push 알림)  │                                     │
│                        └──────────────┘                                     │
│                                                                             │
└─────────────────────────────────────────────────────────────────────────────┘

2.2 2차 고도화 아키텍처 (추가 요소)

┌─────────────────────────────────────────────────────────────────┐
│                     2차 고도화 시 추가                           │
│                                                                 │
│   ┌─────────────┐                                               │
│   │ Weather API │                                               │
│   │ (날씨 조회) │                                               │
│   └──────┬──────┘                                               │
│          │                                                      │
│          ▼                                                      │
│   ┌─────────────────────────────────────────┐                  │
│   │            Scheduler 추가 Job            │                  │
│   │  - WeatherCheckJob (06:00)              │                  │
│   │  - 날씨 기반 미션 자동 교체              │                  │
│   └─────────────────────────────────────────┘                  │
└─────────────────────────────────────────────────────────────────┘

3. 핵심 프로세스

3.1 Phase 1: 미션 사전 준비 (관리자 작업)

LLM으로 미션 리스트 생성 → 관리자가 선별/검수 → DB 저장

┌─────────────────────────────────────────────────────────────────┐
│                      Admin Server Flow                          │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │                 1. LLM으로 미션 리스트 생성               │   │
│  │                                                          │   │
│  │   관리자가 절기 + 조건 입력                               │   │
│  │   ┌─────────────────────────────────────────────────┐   │   │
│  │   │ "청명 절기에 맞는 미션 50개 생성해줘"            │   │   │
│  │   │ "조건: 날씨에 덜 민감하고, 감성적인 미션"        │   │   │
│  │   └─────────────────────────────────────────────────┘   │   │
│  │                          │                               │   │
│  │                          ▼                               │   │
│  │   ┌─────────────────────────────────────────────────┐   │   │
│  │   │              LLM API 호출                        │   │   │
│  │   │         (Claude / GPT 등)                       │   │   │
│  │   └─────────────────────────────────────────────────┘   │   │
│  │                          │                               │   │
│  │                          ▼                               │   │
│  │   ┌─────────────────────────────────────────────────┐   │   │
│  │   │           미션 후보 리스트 50개 반환             │   │   │
│  │   └─────────────────────────────────────────────────┘   │   │
│  └─────────────────────────────────────────────────────────┘   │
│                           │                                     │
│                           ▼                                     │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │                  2. 관리자 선별/검수                     │   │
│  │                                                          │   │
│  │   LLM이 생성한 50개 중 45개 선별                         │   │
│  │   ┌─────────────────────────────────────────────────┐   │   │
│  │   │ [✓] 맑은 하늘 아래 심호흡하기                    │   │   │
│  │   │ [✓] 봄 향기 느끼기                              │   │   │
│  │   │ [✗] 벚꽃 축제 가기        ← 날씨 민감, 제외     │   │   │
│  │   │ [✓] 제철 음식 먹어보기                          │   │   │
│  │   │ ...                                             │   │   │
│  │   └─────────────────────────────────────────────────┘   │   │
│  │                                                          │   │
│  │   - 부적절한 미션 삭제                                   │   │
│  │   - 미션 문구 수정                                       │   │
│  │   - 태그 부여 (장소/활동/강도)                           │   │
│  └─────────────────────────────────────────────────────────┘   │
│                           │                                     │
│                           ▼                                     │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │               3. 오늘의 미션 스케줄 지정                 │   │
│  │                                                          │   │
│  │   선별된 45개 중 15개를 오늘의 미션으로 지정             │   │
│  │   ┌──────┬─────────────────────────┐                    │   │
│  │   │ 날짜 │ 오늘의 미션              │                    │   │
│  │   ├──────┼─────────────────────────┤                    │   │
│  │   │ 4/4  │ 맑은 하늘 아래 심호흡    │                    │   │
│  │   │ 4/5  │ 봄 향기 느끼기           │                    │   │
│  │   │ ...  │ ...                     │                    │   │
│  │   └──────┴─────────────────────────┘                    │   │
│  └─────────────────────────────────────────────────────────┘   │
│                           │                                     │
│                           ▼                                     │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │                     4. DB 저장                           │   │
│  │                                                          │   │
│  │   - Mission 테이블: 미션 풀 (45개)                       │   │
│  │   - MissionTag 테이블: 태그 정보                         │   │
│  │   - DailyMissionSchedule 테이블: 오늘의 미션 스케줄      │   │
│  └─────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────┘

미션 선별 가이드라인:

3.2 Phase 2: 오늘의 미션 활성화 (매일 00:00)

┌─────────────────────────────────────────────────────────────────┐
│                  Daily Mission Scheduler Flow                   │
│                                                                 │
│  ┌───────────────┐                                              │
│  │ 매일 00:00    │                                              │
│  │ DailyMission  │                                              │
│  │ ActivateJob   │                                              │
│  └───────┬───────┘                                              │
│          │                                                      │
│          ▼                                                      │
│  ┌───────────────────────────────────────────┐                  │
│  │ 1. DailyMissionSchedule에서 오늘 날짜 조회 │                  │
│  │ 2. 해당 미션을 "오늘의 미션"으로 활성화    │                  │
│  │ 3. Redis 캐시 갱신                        │                  │
│  └───────────────────────────────────────────┘                  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

3.3 Phase 3: 절기 변경 감지 및 알림 발송

┌─────────────────────────────────────────────────────────────────┐
│                   Solar Term Scheduler Flow                     │
│                                                                 │
│  ┌───────────────┐                                              │
│  │ 매일 00:00    │                                              │
│  │ SolarTermCheck│                                              │
│  │ Job           │                                              │
│  └───────┬───────┘                                              │
│          │                                                      │
│          ▼                                                      │
│  ┌───────────────┐     NO                                       │
│  │ 오늘 = 절기   │ ──────────→ 종료                             │
│  │ 시작일?      │                                               │
│  └───────┬───────┘                                              │
│          │ YES                                                  │
│          ▼                                                      │
│  ┌───────────────────────────────────────────┐                  │
│  │ 절기 변경 알림 발송                        │                  │
│  │                                           │                  │
│  │ "청명이 시작됐어요! 새로운 미션을 확인하세요" │                  │
│  └───────────────────────────────────────────┘                  │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

3.4 Phase 4: 개인화 미션 조회 (실시간)

┌─────────────────────────────────────────────────────────────────┐
│              Personalized Mission Recommendation                │
│                                                                 │
│  ┌─────────┐         ┌─────────────────────────────────────┐   │
│  │ Client  │ ──────→ │           API Server                │   │
│  │ 요청    │ GET     │                                     │   │
│  │         │/missions│  1. 사용자 온보딩 태그 조회          │   │
│  └─────────┘         │  2. 현재 절기 미션 풀 조회           │   │
│                      │  3. 태그 매칭 점수 계산              │   │
│                      │  4. 이미 완료/스킵한 미션 제외       │   │
│                      │  5. 상위 N개 반환                   │   │
│                      └─────────────────────────────────────┘   │
│                                                                 │
│  [태그 매칭 로직]                                               │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │ score = 0                                               │   │
│  │ if (user.location == mission.location) score += 2       │   │
│  │ if (user.activity == mission.activity) score += 3       │   │
│  │ if (user.intensity == mission.intensity) score += 1     │   │
│  │ return missions.sortByScore().limit(N)                  │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

4. 미션 제공 구조

4.1 화면별 미션 구성

┌─────────────────────────────────────────────────────────────────┐
│                        메인 화면                                │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │              오늘의 미션 (큐레이터 픽)                    │   │
│  │                                                          │   │
│  │   "맑은 하늘 아래 심호흡하기"                             │   │
│  │                                                          │   │
│  │   - 모든 유저 동일                                       │   │
│  │   - 관리자가 미리 지정한 미션                            │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
│  ┌─────────────────────────────────────────────────────────┐   │
│  │              개인화 미션 (A/B 테스트)                     │   │
│  │                                                          │   │
│  │   [A안] 리스트로 여러 개                                  │   │
│  │   ┌─────────────────────────────────────┐               │   │
│  │   │ - 봄나물 비빔밥 만들기               │               │   │
│  │   │ - 창문 열고 환기하기                 │               │   │
│  │   │ - 산책하며 새소리 듣기               │               │   │
│  │   └─────────────────────────────────────┘               │   │
│  │                                                          │   │
│  │   [B안] 1개 + 새로고침                                   │   │
│  │   ┌─────────────────────────────────────┐               │   │
│  │   │ 봄나물 비빔밥 만들기          🔄    │               │   │
│  │   └─────────────────────────────────────┘               │   │
│  └─────────────────────────────────────────────────────────┘   │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

4.2 미션 데이터 흐름

┌───────────────────────────────────────────────────────────────────────────┐
│                           미션 데이터 흐름                                 │
│                                                                           │
│  [사전 준비]                              [실시간]                         │
│                                                                           │
│  ┌──────────┐                                                            │
│  │  LLM     │                                                            │
│  │  API     │                                                            │
│  └────┬─────┘                                                            │
│       │ 미션 후보 50개 생성                                               │
│       ▼                                                                   │
│  ┌──────────┐                                                            │
│  │ 관리자   │                                                            │
│  │ 선별/검수│                                                            │
│  └────┬─────┘                                                            │
│       │ 45개 선정 + 태그 부여                                             │
│       ▼                                                                   │
│  ┌──────────┐                                                            │
│  │ Mission  │                                                            │
│  │ 테이블   │                                                            │
│  │ (풀)     │                                                            │
│  └────┬─────┘                                                            │
│       │                                                                   │
│       ├────────────────┐                                                  │
│       │                ▼                                                  │
│       │         ┌───────────────┐                                        │
│       │         │ DailyMission  │                                        │
│       │         │ Schedule      │                                        │
│       │         │ (15일치 지정) │                                        │
│       │         └───────┬───────┘                                        │
│       │                 │                                                 │
│       │                 │ 매일 00:00                                      │
│       │                 ▼                                                 │
│       │         ┌───────────────┐      ┌──────────┐                      │
│       │         │ 오늘의 미션   │ ───→ │ 모든유저 │                      │
│       │         │ 활성화        │      └──────────┘                      │
│       │         └───────────────┘                                        │
│       │                                                                   │
│       │ 사용자 요청 시                                                    │
│       ▼                                                                   │
│  ┌──────────────┐    ┌──────────────┐    ┌──────────┐                    │
│  │ 태그 매칭    │ ─→ │ 개인화 미션  │ ─→ │ 해당유저 │                    │
│  │ (실시간)     │    │ 추천         │    └──────────┘                    │
│  └──────────────┘    └──────────────┘                                    │
│                                                                           │
└───────────────────────────────────────────────────────────────────────────┘

5. 서버 구성

5.1 API Server

5.2 Admin Server

5.3 Scheduler (Batch Server)

6. 데이터 모델

6.1 핵심 테이블

-- 미션 풀
CREATE TABLE mission (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    title VARCHAR(200) NOT NULL,
    description TEXT,
    solar_term VARCHAR(20),          -- 절기 (청명, 곡우 등)
    season VARCHAR(20),              -- 계절 (봄, 여름 등)
    status ENUM('DRAFT', 'ACTIVE') DEFAULT 'DRAFT',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 미션 태그 (개인화 매칭용)
CREATE TABLE mission_tag (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    mission_id BIGINT NOT NULL,
    tag_category VARCHAR(50),        -- location, activity, intensity
    tag_value VARCHAR(50),           -- indoor/outdoor, cooking/exercise, light/active
    FOREIGN KEY (mission_id) REFERENCES mission(id)
);

-- 오늘의 미션 스케줄 (관리자 지정)
CREATE TABLE daily_mission_schedule (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    solar_term VARCHAR(20) NOT NULL,
    target_date DATE NOT NULL,       -- 노출 날짜
    mission_id BIGINT NOT NULL,
    created_by BIGINT,               -- 지정한 관리자
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (mission_id) REFERENCES mission(id),
    UNIQUE KEY (target_date)
);

-- 사용자 온보딩 프로필
CREATE TABLE user_profile (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    location_pref VARCHAR(20),       -- indoor / outdoor / both
    activity_pref VARCHAR(50),       -- cooking / exercise / culture / rest
    intensity_pref VARCHAR(20),      -- light / moderate / active
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (user_id) REFERENCES user(id)
);

-- 사용자 미션 이력
CREATE TABLE user_mission (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    user_id BIGINT NOT NULL,
    mission_id BIGINT NOT NULL,
    mission_type ENUM('DAILY', 'PERSONALIZED'),
    status ENUM('RECOMMENDED', 'COMPLETED', 'SKIPPED'),
    recommended_at TIMESTAMP,
    completed_at TIMESTAMP,
    FOREIGN KEY (user_id) REFERENCES user(id),
    FOREIGN KEY (mission_id) REFERENCES mission(id)
);

-- 절기 정보
CREATE TABLE solar_term (
    id BIGINT PRIMARY KEY AUTO_INCREMENT,
    name VARCHAR(20) NOT NULL,       -- 청명, 곡우 등
    start_date DATE NOT NULL,
    end_date DATE NOT NULL,
    season VARCHAR(20),              -- 봄, 여름 등
    year INT NOT NULL
);

6.2 태그 체계

7. API 목록

7.1 Client API

7.2 Admin API

8. 타임라인

┌───────────────────────────────────────────────────────────────────────────┐
│                              운영 타임라인                                 │
│                                                                           │
│  [절기 시작 전 - 관리자 작업]                                              │
│  ┌─────────────────────────────────────────────────────────────────────┐ │
│  │ 1. Admin에서 LLM 호출 → 미션 후보 50개 생성                         │ │
│  │ 2. 관리자가 선별/검수 → 45개 확정                                   │ │
│  │ 3. 태그 부여 (장소/활동/강도)                                       │ │
│  │ 4. 오늘의 미션 15일치 스케줄 지정                                   │ │
│  │                                                                     │ │
│  │ ※ 1년치 한번에 작업 가능 (24절기 × 45개 = 1,080개)                 │ │
│  │ ※ 이후 매년 재사용 (필요시 일부 수정)                               │ │
│  └─────────────────────────────────────────────────────────────────────┘ │
│                                                                           │
│  [매일 00:00]                                                             │
│  ┌─────────────────────────────────────────────────────────────────────┐ │
│  │ 1. 오늘의 미션 활성화 (DailyMissionActivateJob)                     │ │
│  │ 2. 절기 변경 체크 (SolarTermCheckJob)                               │ │
│  │    → 변경 시 푸시 알림 발송                                         │ │
│  └─────────────────────────────────────────────────────────────────────┘ │
│                                                                           │
│  [사용자 앱 실행 시]                                                      │
│  ┌─────────────────────────────────────────────────────────────────────┐ │
│  │ 1. 오늘의 미션 조회 (캐시)                                          │ │
│  │ 2. 개인화 미션 조회 (실시간 태그 매칭)                               │ │
│  └─────────────────────────────────────────────────────────────────────┘ │
│                                                                           │
└───────────────────────────────────────────────────────────────────────────┘

9. 기술 스택

10. 장애 대응

11. 2차 고도화 계획

11.1 날씨 연동 시 변경 사항

┌─────────────────────────────────────────────────────────────────┐
│                      날씨 연동 추가 시                           │
│                                                                 │
│  [테이블 추가]                                                   │
│  - mission_tag에 weather 카테고리 추가 (sunny/rainy/all)        │
│  - daily_mission_schedule에 fallback_mission_id 추가           │
│                                                                 │
│  [스케줄러 추가]                                                 │
│  - WeatherCheckJob (06:00)                                     │
│    → 날씨 API 조회 → Redis 캐싱                                 │
│    → 비 예보 시 오늘의 미션 자동 교체                            │
│                                                                 │
│  [개인화 미션 로직 수정]                                         │
│  - 태그 매칭 시 날씨 태그도 고려                                 │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘

12. 결정된 사항

13. 미결 사항 (TBD)

기존 workflow는 기존 도커 컨테이너를 중단 후 ECR로 부터 pull 을 받아서 재실행하는 구조였다. workflow 는 다음과 같다.

  name: Deploy to EC2                                                                                                                            

  on:                                                                                                                                            
    push:                                                                                                                                        
      branches:                                                                                                                                  
        - master                                                                                                                                 
  jobs:                                                                                                                                          
    Deploy:                                                                                                                                      
      runs-on: ubuntu-latest                                                                                                                     
      steps:                                                                                                                                     
        - name: Github Repository 파일 불러오기                                                                                                  
          uses: actions/checkout@v4                                                                                                              

        - name: JDK 17버전 설치                                                                                                                  
          uses: actions/setup-java@v4                                                                                                            
          with:                                                                                                                                  
            distribution: temurin                                                                                                                
            java-version: 17                                                                                                                     

        - name: Grant execute permission for gradlew                                                                                             
          run: chmod +x ./gradlew                                                                                                                

        - name: 테스트 및 빌드하기                                                                                                               
          run: ./gradlew clean build                                                                                                             

        - name: AWS Resource 에 접근할 수 있게 AWS credentials 설정                                                                              
          uses: aws-actions/configure-aws-credentials@v4                                                                                         
          with:                                                                                                                                  
            aws-region: ap-northeast-2                                                                                                           
            aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}                                                                                  
            aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}                                                                          

        - name: ECR에 로그인                                                                                                                     
          id: login-ecr                                                                                                                          
          uses: aws-actions/amazon-ecr-login@v2                                                                                                  

        - name: Docker 이미지 생성                                                                                                               
          run: docker build -t meeteam-server .                                                                                                  

        - name: Docker 이미지에 Tag 붙이기                                                                                                       
          run: docker tag meeteam-server ${{ steps.login-ecr.outputs.registry }}/meeteam-server:latest                                           

        - name: ECR에 Docker 이미지 Push                                                                                                         
          run: docker push ${{ steps.login-ecr.outputs.registry }}/meeteam-server:latest                                                         

        - name: SSH 로 EC2 에 접속하기                                                                                                           
          uses: appleboy/ssh-action@v1.0.3                                                                                                       
          with:                                                                                                                                  
            host: ${{ secrets.EC2_HOST }}                                                                                                        
            username: ${{ secrets.EC2_USERNAME }}                                                                                                
            key: ${{ secrets.EC2_PRIVATE_KEY }}                                                                                                  
            script_stop: true                                                                                                                    
            script: |                                                                                                                            
              set -e                                                                                                                             
              cd /home/ubuntu/meeteam                                                                                                            
              docker stop meeteam-server || true                                                                                                 
              docker rm meeteam-server || true                                                                                                   
              docker compose pull meeteam-server                                                                                                 
              docker compose up -d meeteam-server 

docker stop meeteam-server || true 여기서 서비스가 중단되고 docker compose up -d meeteam-server 에서 서비스가 다시 시작되는 구조이다.

해당 타임에는 중단타임이 존재하여 사용자는 서비스 이용을 못하는 구조였다. 중단타임을 측정해보니 대략 5분 정도의 시간 동안은 서버에 내려가 있다.

Blue/ Green 무중단 배포로 전환

무중단 배포 방식에는 여러 방식이 존재하지만, 미팀에서는 단일 인스턴스를 사용하므로 Blue / Green 배포를 통해 무중단 배포로 전환을 하기로 했다.

배포 전에는 443포트에 바인딩된 Nginx 프로세스와 8080 포트에 바인딩된 톰캣 프로세스가 실행중이다. Nginx로 들어온 요청은 8080 포트로 포트포워딩 한다. 배포가 시작되고, 새로운 톰캣 프로세스를 실행하고 8081로 바인딩한다. 이후 Nginx 는 포트포워딩을 8080 포트에서 8081 포트로 전환한다.

Nginx 가 포트전환을 위해서는 설정 변경이 필요하다. 설정 변경을 위해서 Nginx 가 Reload를 해야한다. Reload는 ReStart 와 다르게 설정만 다시 읽는 과정으로 서비스는 끊기지 않고 설정만 바뀐다.

Reload 하는 과정에서는 프로세스 내부에서

기존 worker ---- 요청 처리 중 ↓ 새 설정 로드 ↓ 새 worker 생성 ↓ 기존 worker 종료 (요청 끝나면)

다음과 같은 과정이 일어난다. 여기서 worker 교체 순간이 완전 0ms 는 아니다. 즉 아주 짧은 타이밍에 실패가 발생할 수 있다. 아주 찰나에 순간이지만 다운 타임이 얼마나 발생하고, 사용자의 요청이 얼마나 실패하는지 확인하기 위해 테스트를 진행해 보았다. 테스트는 Jmeter 를 이용하여 300개의 동시 요청을 배포 전부터 배포 후까지 무한히 반복했다.

빨간색 점은 성공한 요청이고 초록색은 실패한 요청이다. 아주 짧은 찰나의 순간에 하나의 요청만 실패했다. 이는 사용자 경험에 크게 영향을 미치지 않을것이라고 생각했다. 단 하나의 요청만 실패한 요청이였기에, 언제 사용자의 요청을 실패하는지 찾아보았지만, 너무 많은 요청이 존재해서 찾지 못했다.

추가적인 고민

프로세스가 전환되는 과정에서 새로운 톰캣 프로세스가 올라가고 기존 프로세스는 종료 될때, 순간적으로 N개 의 톰캣이 올라가 있다. 여기서 DB 의 Connection 이 부족해 새로운 프로세스가 올라갈때 커넥션풀을 생성하지 못할수도 있을것이다.

예를들어, DB의 Max connection 이 40 일때, 각각의 커넥션 풀의 기본값이 30이면 2개의 프로세스가 올라가 있는 동안, 일시적인 순간에는 60개의 커넥션이 필요할텐데, 그럼 30 * 2 < 50 이므로 새로운 프로세스가 커넥션 풀 생성에 실패할수도 있을것이다. 미팀 프로젝트에서는 minimum pool size 가 크지 않고, 배포시에 2개의 프로세스 밖에 존재하지 않으므로 문제가 없을것이지만, 많은 프로세스가 올라갈 경우에는 스레드풀의 개수또한 신경써야할것이라고 생각한다.

몇개월 전 진행했던 프로젝트인 미팀을 몇개월 만에 다시 살려보고자 남아있는 팀원들이랑 방향성에 대해 논의해 보았다. 우선적으로 테스트 코드가 전무하니, 테스트를 구축과 동시에 프로덕션 코드를 리펙토링 하기로 하였다. 팀원이 많이 이탈했기 때문에, 팀원들이 작성한 코드마저 현재 남은 인원으로 리펙토링을 진행해야 했고 이 방대한 양의 프로덕션 코드를 리펙토링을 할 생각을 하니 시작하기도 전에 막막함과 피로감이 스멀스멀 올라왔다. 현재 우리 서비스는 전혀 예상하지 못한 곳에서 장애가 존재했고, 프로젝트 기간중 상당한 시간을 예상하지 못한 장애를 해결하는데 시간을 보냈다. 예상하지 못한 장애를 미리 예방하고 싶고, 그러기 위해서는 단위테스트와 통합테스트가 구축이 되어야 한다고 판단했다. 하지만 현재 미팀 서비스의 프로덕션 코드에 단위테스트와 통합테스트를 도입하기에는, 클래스마다 역할과 책임은 분리 되어있지 않았기에, 테스트를 구축하는 작업 역시 많이 리소스가 필요했다.

인수테스트를 통한 안정망 구축

이를 해결하기위해 먼저 API 기반의 E2E 인수테스트를 우선적으로 구축하고, 구축한 안정망을 통하여 프로덕션 코드를 리펙토링을 진행하기로 결심했다. 현재 상황에서는 프로덕션 코드와 관계 없이 테스트를 구축할수 있고 이 구축한 테스트의 보호 안에서 하나의 모듈의 대한 리펙토링을 진행후에 수시로 테스트를 진행하여 회귀 버그 또한 테스트를 통해 확인할 수 있다고 판단했다. 위의 사진과 같이 우선적으로 테스트를 통과를 목표를 잡고 모든 인수테스트가 통과하면 그 이후로는 자신감있게 리펙토링을 진행할 수 있다. 내가 생각한 작업 순서를 다음과 같다

• 현재 프로젝트 시스템 분석
• 시스템 분석을 통한 리스크 분석 및 리스크 매트릭스 작성
• 리스크 매트릭스를 바탕으로 인수조건 도출
• 인수조건을 바탕으로 Gherkin 시나리오 작성
• Gherkin 시나리오를 바탕으로 인수테스트 구축
• 인수테스트 통과를 목표로 프로덕션 코드 수정
• 프로덕션 코드 리펙토링

시스템 분석 & 리스크 분석

프로젝트를 진행하지 몇개월의 시간이 흘렀고, AI 도구 또한 많이 발전되었다고 생각해 AI 에이전트의 도움을 받아 시스템을 분석하고, 이를 바탕을 리스크를 분석해 보았다. 먼저 리스크 평가 기준으로 비즈니스 임팩트, 변경 빈도, 버그 발생 가능성 등을 종합적으로 고려하여 리스크 매트릭스를 작성하였다.

인수 조건 도출하기 & Gherkin 시나리오 작성하기

먼저 우선순위가 높은 순서에 맞게 인수조건을 도출하였다. 인수조건을 바탕으로 Gherkin 시나리오를 작성할 계획이라 인수조건을 명확하게 작성 해야한다고 판단했다. 인수조건들은 5W1H(누가, 무엇을, 언제, 어디서, 왜, 어떻게) 원칙으로 구체화하여 명확한 인수 조건을 정의했다.

이 정의한 인수조건을 바탕으로 Gherkin 시나리오를 작성했다.

feature 파일

• 내부 구현과 관련된 용어
• 비개발 용어
• 시나리오 자체가 지나치게 세부적

feature 파일은 목적에 따라 사용 범위가 다르겠지만, 이 문서는 팀 전체가 공유할 수 있는 팀 컨벤션으로서 역할을 할 수도 있다고 생각한다. 나는 이 문서를 통해 프론트엔드 개발자와 요구사항에 대한 싱크를 맞추는데 사용하였다. 위에 작성한 것이 항상 문제가 되는건 아니지만, feature 파일의 역할에 따라 문제가 될수도 있다고 생각한다. 또한, 지나치게 세부적인 시나리오를 만들어서 테스트를 작성해야하는지도 의문이다. 인수테스트의 목적은 결국 사용자 시나리오에 맞게 검증하는 용도라는 생각이 드는데, 모든 예외케이스에 대해서 작성한다거나 동시성 문제와 같은 문제는 오히려 통합테스트 or 단위테스트 or 슬라이스 테스트가 더 역할에 부합할것이다.

Cucumber 라이브러리를 통해서 시나리오의 하나의 스텝마다 메서드를 1대1 대응 시켜서 테스트 코드를 작성할수 있었다. 이 라이브러리는 feature 에서 작성한 "값"들을 메서드 파라미터로 넘겨서 사용할수 있고, feature 파일 내부에서 곧 바로 테스트를 실행시킬수 있다.(플러인 설치)

시나리오를 작성할때는 비개발 용어와, 내부 구현과 관련없는 시나리오로 작성하려고 노력하였다.

"인증 토큰을 발급받는다" 와 같은 스텝은 개발을 모르는 사람이라면 이해하기 어렵지만, 현재 미팀에서는 인가/인증과 관련된 로직에 알수 없는 버그들이 존재하기 때문에 해당 도메인에는 최대한 구체적으로 시나리오를 작성하려고 노력하였다. 또한, 내부 개발과 관련된 용어를 사용할경우에 프로덕션 코드의 수정이 발생할 경우 시나리오의 수정 또한 발생할수 있기 때문에 최대한 비지니스 용어를 이용하여 시나리오를 작성하는게 좋을것이다.

인수테스트 작성하기

인수테스트를 작성할때는 RestAssured 를 이용하여 테스트를 작성하였다. 추후에 프로덕션 코드를 리펙토링을 해야하기 때문에 E2E 기반 블랙박스 테스트를 하는것이 좋다고 판단하였고, 리펙토링을 하는 과정에서 코드가 수정되어도 영향을 받지 않기 때문에 이 방법을 선택하였다.

위의 사진과 같은 API 호출을 통한 부분은 별도의 도메인과 관련된 API 클래스에서 호출할수 있도록 위임을 하였다. API 호출에 대한 부분을 스텝 메서드에 둘 경우 가독성 또한 떨어진다고 판단하였고, 테스트 코드를 보는 입장에서는 로그인 요청 구현방식 보다는 로그인 요청을 한다는 사실이 더 중요할것이다. 즉, 스텝에서는 한글 메서드명을 통해서 해당 메서드가 로그인을 요청한다는 사실만 알도록 하였다.

TestContext 이용하기

Cucumber 를 사용하지 않고 하나의 테스트 메서드에 인수 테스트를 작성할 경우 지역변수를 사용하여 값을 공유하면 될것이다. 하지만 Cucumber 를 사용할 경우 스텝 별로 메서드를 작성하기 때문에 값을 공유할 무언가가 필요하다. Context 라는 개념은 무엇인가를 담아서 저장하는 개념으로 사용한다. 나는 TestContext 를 이용하여 스텝 간의 값을 전달거나 공유하도록 하였다.

Cucumber 에서는 @ScenarioScope 를 이용하여 하나의 시나리오가 끝나면 TestContext 를 초기화를 해준다. 별도의 clear 해주는 작업없이 이용가능한다. 도메인 별로 공유하는 값들은 이너 클래스를 이용하여 내부적으로 공유하도록 해주었다.

도메인 별로 inner 클래스를 이용하여 값을 저장하도록 구현하였지만, 도메인 별로 저장해야할 값이 많아질 경우에는 별로의 클래스로 분리하는것이 좋아보인다.

최소한의 수정으로 인수테스트 통과하기

프로젝트 지원 기능은 서비스의 핵심 기능이기 때문에, 비교적 다양한 시나리오를 작성했다. 다만 처음부터 모든 시나리오를 검증하기보다는, Happy Case 23개, Error Case 23개, Edge Case 2~3개 정도로 시작하는 것이 적절하다고 판단했다.

    @Counted("project.apply")
    @Override
    public ApplicationResponse apply(Long projectId, Long memberId, ApplicationRequest request) {
        Project project = projectRepository.findActiveById(projectId)
                .orElseThrow(() -> new CustomException(ErrorCode.PROJECT_NOT_FOUND));

        validateProjectNotCompleted(project);

        // 프로젝트 리더는 자신의 프로젝트에 지원 불가
        if (project.getCreator().getId().equals(memberId)) {
            throw new CustomException(ErrorCode.APPLICATION_SELF_PROJECT_FORBIDDEN);
        }

        Member member = memberRepository.findById(memberId)
                .orElseThrow(() -> new CustomException(ErrorCode.MEMBER_NOT_FOUND));

        if (applicationRepository.existsByProjectAndApplicant(project, member)) {
            throw new CustomException(ErrorCode.PROJECT_APPLICATION_ALREADY_EXISTS);
        }

        if (projectMemberRepository.existsByProjectIdAndMemberId(projectId, memberId)) {
            throw new CustomException(ErrorCode.PROJECT_MEMBER_ALREADY_EXISTS);
        }

        JobPosition jobPosition = jobPositionRepository.findByCode(request.jobPositionCode())
                .orElseThrow(() -> new CustomException(ErrorCode.JOB_POSITION_NOT_FOUND));

        // 해당 프로젝트에서 해당 포지션으로 모집 중인지 확인
        recruitmentStateRepository.findAvailableByProjectIdAndJobPosition(projectId, jobPosition)
                .orElseThrow(() -> new CustomException(ErrorCode.RECRUITMENT_POSITION_NOT_AVAILABLE));

        ProjectApplication application = ProjectApplication.create(
                project,
                member,
                jobPosition,
                request.motivation()
        );

        ProjectApplication savedApplication = applicationRepository.save(application);

        Long receiverId = project.getCreator().getId();
        Long actorId = member.getId();

        // 1. 팀장에게 지원 알림 저장
        Notification applyNotification = createNotification(
                project.getCreator(), project, actorId, NotificationType.PROJECT_APPLY, savedApplication.getId()
        );
        notificationRepository.save(applyNotification);

        // 2. 지원자에게 지원 완료 알림 저장
        Notification myApplyNotification = createNotification(
                member, project, actorId, NotificationType.PROJECT_MY_APPLY, savedApplication.getId()
        );
        notificationRepository.save(myApplyNotification);

        // 프로젝트 리더 알림 발행 (SSE)
        eventPublisher.publishEvent(new NotificationEvent(
                receiverId,
                project.getId(),
                actorId,
                NotificationType.PROJECT_APPLY,
                savedApplication.getId()
        ));

        // 지원자 알림 발행 (SSE)
        eventPublisher.publishEvent(new NotificationEvent(
                actorId,
                project.getId(),
                actorId,
                NotificationType.PROJECT_MY_APPLY
        ));

        log.info("프로젝트 지원 완료 - projectId: {}, applicantId: {}, jobPositionCode: {}",
                projectId, memberId, request.jobPositionCode());

        return ApplicationResponse.from(savedApplication);
    }

프로젝트 지원 메서드를 보면 하나의 메서드에서 너무 많은 역할을 수행하고 있다. 프로젝트 지원 처리뿐만 아니라, 검증 로직과 알림 처리까지 함께 포함되어 있어 책임이 과도하게 집중된 상태였다.

이러한 구조를 안정망 없이 리팩토링한다고 생각하면 상당히 부담스러운 작업이다. 하지만 인수 테스트라는 안정망을 구축해두었기 때문에, 기능이 깨지더라도 빠르게 버그를 탐지하고 수정할 수 있는 환경을 만들 수 있었다. AI 에이전트에게 리팩토링을 맡기기 전에, 먼저 내가 원하는 방향을 정리한 컨벤션 문서를 작성하고 이를 Claude.md에 포함시켰다. Claude Code에서는 @Convention.md와 같은 방식으로 컨텍스트에 포함된 문서를 참조할 수 있도록 구성했다. 처음에는 하나의 endpoint를 직접 리팩토링한 뒤,그 결과를 문서화하고 이를 기반으로 전체 리팩토링을 진행했다. 컨벤션 문서를 작성할 때는 단순한 설명보다 원하는 구조를 담은 예시 코드를 함께 제공하는 것이 가장 중요하다고 생각한다.

이후 해당 컨벤션을 기반으로 리팩토링을 진행했다. 아래는 프로젝트 지원 메서드를 리팩토링한 결과이다.

    @Counted("project.apply")
    @Override
    public ApplicationResponse apply(Long projectId, Long memberId, ApplicationRequest request) {
        // 1단계: 엔티티 조회
        Project project = projectRepository.findActiveById(projectId)
                .orElseThrow(() -> new CustomException(ErrorCode.PROJECT_NOT_FOUND));
        Member member = memberRepository.findById(memberId)
                .orElseThrow(() -> new CustomException(ErrorCode.MEMBER_NOT_FOUND));
        JobPosition jobPosition = jobPositionRepository.findByCode(request.jobPositionCode())
                .orElseThrow(() -> new CustomException(ErrorCode.JOB_POSITION_NOT_FOUND));

        // 2단계: 권한 검증
        validateNotSelfApplication(project, memberId);

        // 3단계: 비즈니스 규칙 검증
        validateApplyPrecondition(project, member, projectId, memberId);
        validateRecruitmentPosition(projectId, jobPosition);

        // 4단계: 지원서 생성 및 저장
        ProjectApplication savedApplication = createAndSaveApplication(project, member, jobPosition, request.motivation());

        // 5단계: 알림 발행 및 응답
        publishApplyNotifications(project, member, savedApplication);

        log.info("프로젝트 지원 완료 - projectId: {}, applicantId: {}, jobPositionCode: {}",
                projectId, memberId, request.jobPositionCode());

        return ApplicationResponse.from(savedApplication);
    }

역할을 분리하고 각 책임을 위임하면서,기존보다 훨씬 가독성이 좋아지고 구조가 명확해졌다.다만 이 과정에서 private 메서드가 많이 생성되었는데, 이는 하나의 클래스가 너무 많은 책임을 가지고 있다는 신호일 수도 있다.

따라서 메서드가 더 늘어난다면,관련된 책임을 별도의 클래스로 분리하는 방향도 고려해야 한다. 리펙토링을 완료했으니, 프로젝트 지원과 관련된 인수테스트를 돌려보자.

모든 테스트가 성공적으로 통과하는 것을 확인할 수 있었다.만약 인수 테스트가 없었다면,Swagger를 통해 다음과 같은 과정을 모두 수동으로 검증해야 했을 것이다.

• 지원 요청
• 지원 결과 확인
• 프로젝트 리더 알림 확인
• 지원자 알림 확인
• 프로젝트 인원 변화 확인

이 과정을 매번 반복하는 것은 상당한 시간과 비용이 드는 작업이며,생각만 해도 부담스러운 과정이다.이전까지는 배포 전 수동 테스트에 많은 시간을 투자했지만,인수 테스트를 도입하면서 검증 시간을 크게 줄일 수 있었다.이번 작업의 목적은 프로덕션 코드 리팩토링이었지만,테스트 코드 또한 하나의 코드이기 때문에 유지보수가 가능한 형태로 작성하는 것이 매우 중요하다.그렇지 않으면 테스트 코드 역시 결국 방치되고 버려질 수 있기 때문에,테스트 코드 작성에도 많은 시간을 투자했다.테스트 코드 작성 과정은 다음 글에서 정리해보려고 한다.

MockitoBean 은 Application Context 이미 존재하는 빈이면 Mock 빈 으로 대체한다. 존재하지 않으면 Mock 빈 으로 새로 등록한다.

가짜 객체를 빈으로 등록하고, 그 빈이 어떤 상태를 반환할지 정하면 된다.

위와 같이 Mock 빈과 같은 Mock 객체는 언제 사용하는것일까?

@Transactional
@SpringBootTest
@ActiveProfiles(value = "test")
class OrderStatisticsServiceTest {


    @Autowired
    private OrderStatisticsService orderStatisticsService;

    @Autowired
    private OrderProductRepository orderProductRepository;

    @Autowired
    private OrderRepository orderRepository;

    @Autowired
    private ProductRepository productRepository;

    @Autowired
    private MailSendHistoryRepository mailSendHistoryRepository;

    @MockitoBean
    private MailSendClient mailSendClient;


    @AfterEach
    void tearDown() {
        orderProductRepository.deleteAllInBatch();
        orderRepository.deleteAllInBatch();
        productRepository.deleteAllInBatch();
        mailSendHistoryRepository.deleteAllInBatch();
    }


    @DisplayName("결제완료 주문들을 조회하여 매출 통계 메일을 전송한다.")
    @Test
    void sendOrderStatisticsMail() {
        //given
        LocalDateTime now = LocalDateTime.of(2023, 3, 5, 0, 0);
        Product product1 = createProduct(HANDMADE, "001", 1000);
        Product product2 = createProduct(HANDMADE, "002", 2000);
        Product product3 = createProduct(HANDMADE, "003", 3000);
        List<Product> products = List.of(product1, product2, product3);
        productRepository.saveAll(products);


        Order order1 = createPaymentCompletedOrder(LocalDateTime.of(2023, 3, 4, 23, 59, 59), products);
        Order order2 = createPaymentCompletedOrder(now, products);
        Order order4 = createPaymentCompletedOrder(LocalDateTime.of(2023, 3, 5, 23, 59, 59), products);
        Order order3 = createPaymentCompletedOrder(LocalDateTime.of(2023, 3, 6, 0, 0), products);

        // stubbing : 목 객체에 원하는 행위를 정의하는 것
        when(mailSendClient.sendEmail(any(String.class), any(String.class), any(String.class), any(String.class)))
                .thenReturn(true);

        // when
        boolean result = orderStatisticsService.sendOrderStatisticsMail(LocalDate.of(2023, 3, 5), "test@test.com");

        //then
        assertThat(result).isTrue();

        List<MailSendHistory> histories = mailSendHistoryRepository.findAll();
        assertThat(histories).hasSize(1)
                .extracting("content")
                .contains("총 매출 합계는 12000원입니다.");
    }

    private Order createPaymentCompletedOrder(LocalDateTime now, List<Product> products) {
        Order order = Order.builder()
                .products(products)
                .orderStatus(PAYMENT_COMPLETED)
                .registeredDateTime(now)
                .build();
        orderRepository.save(order);

        return order;
    }


    private Product createProduct(ProductType type, String productNumber, int price) {
        return Product.builder()
                .type(type)
                .productNumber(productNumber)
                .price(price)
                .sellingStatus(SELLING)
                .name("메뉴 이름")
                .build();
    }

}

테스트 클래스의 필드를 보면 @Autowired 를 통해서 의존관계 주입을 해주었다.

하지만 하나의 클래스는 @Autowired 를 사용하지 않은것을 확인할 수 있다.

    @MockitoBean
    private MailSendClient mailSendClient;

이건 왜 @Autowired 를 통해서 DI 를 하는것이 아닌 @MockitoBean 으로 가짜 빈을 Application Context 에 등록하는것일까

public boolean sendOrderStatisticsMail(LocalDate orderDate, String email) {

        // 해당 일자에 결제완료된 주문들을 가져와서
        List<Order> orders = orderRepository.findOrdersBy(
                orderDate.atStartOfDay(),
                orderDate.plusDays(1).atStartOfDay(),
                PAYMENT_COMPLETED
        );

        // 총 매출 합계를 계산하고

        int totalPrice = orders.stream()
                .mapToInt(order -> order.getTotalPrice())
                .sum();

        // 메일 전송
        boolean result = mailService.sendMail(
                "no-reply@cafekiosk.com",
                email,
                String.format("[매출통계] %s", orderDate),
                String.format("총 매출 합계는 %s원입니다.", totalPrice)
        );

        if (!result) {
            throw new IllegalArgumentException("매출 통계 메일 전송에 실패했습니다.");
        }

        return true;
    }

sendEmailService 내부에서 메일 전송을 한다.

package sample.cafekiosk.spring.api.service.mail;


import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import sample.cafekiosk.spring.client.mail.MailSendClient;
import sample.cafekiosk.spring.domain.history.MailSendHistory;
import sample.cafekiosk.spring.domain.history.MailSendHistoryRepository;

@RequiredArgsConstructor
@Service
public class MailService {

    private final MailSendClient mailSendClient;
    private final MailSendHistoryRepository mailSendHistoryRepository;


    public boolean sendMail(String fromMail, String toEmail, String subject, String content) {

        boolean result = mailSendClient.sendEmail(fromMail, toEmail, subject, content);

        if (result) {
            mailSendHistoryRepository.save(MailSendHistory.builder()
                    .fromEmail(fromMail)
                    .toEmail(toEmail)
                    .subject(subject)
                    .content(content)
                    .build()
            );
            return true;
        }

        return false;
    }
}

여기서 실제로 메일을 전송하는 객체는 MailSendClient 가 담당한다.

그럼 MailSendClient 에서 외부 네트워크를 사용해서 매번 테스트를 진행하는건 매우 비효율적일것이다. 테스트를 할때마다 실제로 메일을 전송하는건 바람직하지 않다.

이런 경우에 Mock 객체를 사용해서 메일 전송 로직을 작동한다고 가정하고 테스트를 진행할 수 있다.

테스트 코드에서는 실제 객체가 아닌 가짜 객체를 등록해 사용하기 위해서

@MockitoBean private MailSendClient mailSendClient;

으로 Mock 빈으로 등록하는것이다.

Mock 빈을 이용해서 반환하도록 하는것을 Stubbing 이라고 한다.

// stubbing : 목 객체에 원하는 행위를 정의하는 것
 when(mailSendClient.sendEmail(any(String.class), any(String.class), any(String.class), any(String.class)))
                .thenReturn(true);

원하는 행위를 정의하고 사용하면 된다.

참고로 위와 같은 과정은 Given 에서 진행하는것이 맞다.

@Service
@RequiredArgsConstructor
public class ProjectApplicationService {

    private final ProjectRepository projectRepository;
    private final MemberRepository memberRepository;
    private final JobPositionRepository jobPositionRepository;
    private final ApplicationRepository applicationRepository;
    // 이벤트를 발행하는 대신, 알림 서비스를 직접 의존합니다.
    private final NotificationService notificationService; 

    @Transactional
    public ApplicationResponse apply(Long projectId, Long memberId, ApplicationRequest request) {
        // 1단계: 엔티티 조회
        Project project = projectRepository.findActiveById(projectId)
                .orElseThrow(() -> new CustomException(ErrorCode.PROJECT_NOT_FOUND));
        Member member = memberRepository.findById(memberId)
                .orElseThrow(() -> new CustomException(ErrorCode.MEMBER_NOT_FOUND));
        JobPosition jobPosition = jobPositionRepository.findByCode(request.jobPositionCode())
                .orElseThrow(() -> new CustomException(ErrorCode.JOB_POSITION_NOT_FOUND));

        // 2단계: 권한 및 비즈니스 검증
        validateNotSelfApplication(project, memberId);
        validateApplyPrecondition(project, member, projectId, memberId);
        validateRecruitmentPosition(projectId, jobPosition);

        // 3단계: 지원서 생성 및 저장
        ProjectApplication application = ProjectApplication.builder()
                .project(project)
                .member(member)
                .jobPosition(jobPosition)
                .motivation(request.motivation())
                .build();
        ProjectApplication savedApplication = applicationRepository.save(application);

        // 4단계: 알림 서비스 직접 호출 (동기 방식의 핵심)
        // 알림 전송이 완료될 때까지 아래 로그와 리턴문은 실행되지 않고 대기합니다.
        notificationService.sendApplyNotification(project.getOwner(), member, savedApplication);

        log.info("프로젝트 지원 완료 - projectId: {}, applicantId: {}, jobPositionCode: {}",
                projectId, memberId, request.jobPositionCode());

        return ApplicationResponse.from(savedApplication);
    }
}

이 코드는 전형적인 동기 방식을 따른다. 동기 방식은 프로그램의 흐름을 직관적으로 이해할 수 있다. 하지만 동기 방식에서, 알림 전송과 같은 부가적인 기능을 만나면 고려할 부분이 있다. 먼저, 위의 요구사항에서 사용자가 지원을 완료하고 알림 전송을 받을때, 알림 전송을 하는 과정에서 Exception 이 발생하면 프로젝트 지원절차 역시 실패한다. 이게 맞는걸까? 생각을 해보면, 알림 전송을 실패했다고 지원까지 실패하는건 사용자가 원하지 않은 결과일것이다. 또한, 알림 전송을 완료하고 사용자에게 프로젝트 지원에 대한 응답을 보낼경우 응답시간 또한 지연될 것이다. 위와 같은 이유로 반드시 알림이 전송되고 지원이 완료되어야 하는게 아니라면, 동기 방식 대신 비동기 방식으로 연동하는 것을 고민해 볼 필요가 있다. 현재 구조에서 비동기 방식으로 구현할 경우, 알림전송에 대한 로직이 끝날때까지 기다리지 않고, 바로 프로젝트 지원 성공을 사용자에게 응답할 수 있다.

알림 발송 로직을 비동기로 호출

@Service
@RequiredArgsConstructor
public class ProjectApplicationService {

    private final ProjectRepository projectRepository;
    private final MemberRepository memberRepository;
    private final JobPositionRepository jobPositionRepository;
    private final ApplicationRepository applicationRepository;

    // 알림 서비스를 직접 의존 (결합 발생)
    private final NotificationService notificationService; 

    @Transactional
    public ApplicationResponse apply(Long projectId, Long memberId, ApplicationRequest request) {
        // 1단계: 엔티티 조회
        Project project = projectRepository.findActiveById(projectId)
                .orElseThrow(() -> new CustomException(ErrorCode.PROJECT_NOT_FOUND));
        Member member = memberRepository.findById(memberId)
                .orElseThrow(() -> new CustomException(ErrorCode.MEMBER_NOT_FOUND));
        JobPosition jobPosition = jobPositionRepository.findByCode(request.jobPositionCode())
                .orElseThrow(() -> new CustomException(ErrorCode.JOB_POSITION_NOT_FOUND));

        // 2단계: 권한 및 비즈니스 검증
        validateNotSelfApplication(project, memberId);
        validateApplyPrecondition(project, member, projectId, memberId);
        validateRecruitmentPosition(projectId, jobPosition);

        // 3단계: 지원서 생성 및 저장
        ProjectApplication application = ProjectApplication.builder()
                .project(project)
                .member(member)
                .jobPosition(jobPosition)
                .motivation(request.motivation())
                .build();
        ProjectApplication savedApplication = applicationRepository.save(application);

        // 4단계: 단순 비동기 호출 (Direct Async Call)
        // @Async가 붙은 메서드를 직접 호출합니다. 
        // 이 시점에 별도의 스레드에서 알림 발송 로직이 즉시 시작됩니다.
        notificationService.sendApplyNotification(project.getOwner(), member, savedApplication);

        // 5단계: 의도적인 예외 발생 (블로그 예시용)
        // 만약 여기서 알 수 없는 에러가 발생하여 트랜잭션이 롤백된다면?
        if (someErrorCondition) {
            throw new RuntimeException("DB 커밋 직전 에러 발생!");
        }

        log.info("프로젝트 지원 완료 - projectId: {}, applicantId: {}", projectId, memberId);
        return ApplicationResponse.from(savedApplication);
    }
}

@Async 를 이용하여 non-blocking 비동기로 알림 발송 로직을 실행했다. 하지만 이 과정에서는 전의 상황보다 더 심각한 상황이 발생할것이다. 비동기 처리를 하기 위해 스레드풀에서 스레드를 할당받고 알림을 보낸다. 하지만, 핵심 로직인 프로젝트 지원 스레드가 예외가 터지면, 롤백이 발생할것이고 결국 지원은 실패한다. 결과적으로 사용자는 "지원이 실패했는데 지원 완료 알림을 받는" 당황스러운 경험을 하게 된다. 이 문제를 어떻게 해야할까? 쉽게 생각하면 프로젝트 지원이 완료되고 알림 발송 로직이 실행되면 된다. 프로젝트 지원후 commit이 완료 되고 나서, 알림전송을 하기 위해서 다음과 같은 방식으로 구현을 하였다.

Facade 클래스로 commit 이후에 비동기 호출하기

// 상위 Facade 클래스
public void applyAndNotify(...) {
    applicationService.apply(...); // 여기서 트랜잭션 커밋 완료
    notificationService.sendAsync(...); // 커밋 완료 후 비동기 호출
}

Fascade 상위 클래스에서는 apply 이후에 commit 이 완료되고 나서 비동기로 비동기 호출을 하면 된다. 위에서 발생할수 있는 문제를 해결할수 있다. 하지만 나는 미팀에서는 Facade 클래스를 이용하지 않고, Spring Event 를 이용하여 비동기를 호출하였다. 현재 요구사항에서는 지원이 완료시에 알림전송만 하면된다. 하지만 추후에 지원후 외부 시스템을 이용하여 알림톡 전송을 하는등, 추가적인 요구사항이 생길경우 Facade 클래스가 의존하는 클래스가 많아질 것이다. 또한, 다른 개발자가 Facade 를 거치지 않고 applicationService.apply()를 직접 호출하면? 알림이 영영 가지 않을수 있다. 현재 상황에서는 위의 방식이 전혀 문제는 없다. 하지만 Spring Event에서의 TransactionEventListener는 다양한 케이스들에서 동작할수 있도록 제어가 가능하다. After commit만 있는게 아니라 beforeCommit, beforeCompletion, AflterCompletion도 가능하고, 나는 commit 이후에 알림 발송을 하면 되었기에 아래와 같이 @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)와 @Async 를 이용했다.

@Async
@TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT)
public void on(NotificationEvent e) {
      // 엔티티 조회를 SSENotificationService로 위임
      notificationService.notify(e);
}

여기서 @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) 를 사용할때 조심해야한다. AFTER_COMMIT 을 보고 COMMIT 이 완료되었으니까, 새로운 @Transaction을 열면 된다고 생각하는 순간 commit 이 되지 않는다. 위의 코드는 현재 비동기로 처리되기 때문에 기존 트랜잭션과 다른 스레드를 사용하기 때문에 문제가 발생하지 않지만, 만약 동기적으로 실행할 경우에는 하나의 스레드를 계속해서 사용하기 때문에 commit이 안된다. commit 이 왜 발생하지 않을까 ? AFTER_COMMIT 이면 COMMIT 이후에 실행되기 때문에, 추가적으로 물리 트랜잭션을 새로 연다고 해도 COMMIT은 되어야 한다고 생각했다. 하지만 여기서 AOP를 통해서 connection.commit() 을 호출하여 물리적인 DB commit 을 하더라도 아직 DataSource 는 살아있고, 아직 connection을 release() 한 상태는 아니다. 즉, 자원정리는 아직 하지 않은 상태이고, DB에 commit을 보낸상태로 @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) 를 호출하는것이다. 이 어노테이션 이후에 상황은 다음과 같다

• 기존 커넥션은 살아있음
• DB에 commit 호출

그럼 알림서비스에서 @Transaction을 열고 write 연산을 진행했다고 가정하자. 그럼 이 상황에서 기존 커넥션을 이용할것이다. 메서드 종료 시점에 commit 을 하겠지만, 여기서 장애가 발생하고 commit을 하지 못한다. 그 이유는 이미 기존에 commit을 호출하였기 때문에 write 연산을 해도 의미가 없기 때문이다. 반면 기존 커넥션을 살아있으므로 read 연산을 해도 에러가 발생하지 않는다. 즉, @TransactionalEventListener(phase = TransactionPhase.AFTER_COMMIT) 는 동기적으로 실행될 경우, DB에 commit 호출 이후, 그리고 커넥션을 커넥션풀에 반납하기 전에 실행된다

물론 미팀에서 @Async 를 통해 비동기로 실행되기 때문에 별도의 스레드에서 실행되므로 문제가 발생하지 않지만, 해당 어노테이션이 일어나는 시점을 명확하게 인지할 필요가 있다.

• LocalDate: 날짜만 표현할 때 사용한다 ex) 2013-11-21

• LocalTime: 시간만을 표현할 때 사용한다. 시, 분, 초를 다룬다. ex) 08:20:30.213

• LocalDateTime: LocalDate 와 LocalTime 을 합한 개념 ex) 2013-11-21T08:20:30.213

public class LocalDateMain {
public static void main(String[] args) {

    LocalDate nowDate = LocalDate.now();
    LocalDate ofDate = LocalDate.of(2013, 11, 21);     
    System.out.println("오늘 날짜 = " + nowDate);     
    System.out.println("지정 날짜 = " + ofDate);
    //계산(불변)
    LocalDate plusDays = ofDate.plusDays(10); 
    System.out.println("지정 날짜+10d = " + plusDays);
    } 
}

실행결과

오늘 날짜 = 2024-02-09
지정 날짜 = 2013-11-21
지정 날짜+10d = 2013-12-01

생성

• now() : 현재 시간을 기준으로 생성한다.
• of(. . .) : 특정 날짜를 기준으로 생성한다. 년, 월, 일을 입력할 수 있다.

계산

• plusDays(): 특정 일을 더한다. 다양한 plusXxx() 메서드가 존재하다.

모든 날짜는 불변이므로, 변경이 발생하면 새로운 객체를 생성해서 반환한다.

LocalTime

public class LocalTimeMain {
      public static void main(String[] args) {

        LocalTime nowTime = LocalTime.now();
        LocalTime ofTime = LocalTime.of(9, 10, 30);
        System.out.println("현재 시간 = " + nowTime); 
        System.out.println("지정 시간 = " + ofTime);

         LocalTime ofTimePlus = ofTime.plusSeconds(30);
        System.out.println("지정 시간+30s = " + ofTimePlus);

    } 
}

실행결과

현재 시간 = 11:52:51.219602 
지정 시간 = 09:10:30
지정 시간+30s = 09:11:00

LocalTime은 초가 항상 나와야 하는건 아니다

LocalDateTime

LocalDateTime 클래스

public class LocalDateTime {
    private final LocalDate date;
    private final LocalTime time;
    ...
}

package time;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.LocalTime;
public class LocalDateTimeMain {
public static void main(String[] args) {

    LocalDateTime nowDt = LocalDateTime.now();

    LocalDateTime ofDt = LocalDateTime.of(2016, 8, 16, 8, 10, 1); 
    System.out.println("현재 날짜시간 = " + nowDt); 
    System.out.println("지정 날짜시간 = " + ofDt);
    //날짜와 시간 분리
    LocalDate localDate = ofDt.toLocalDate(); 
    LocalTime localTime = ofDt.toLocalTime(); 
    System.out.println("localDate = " + localDate); 
    System.out.println("localTime = " + localTime);

    //날짜와 시간 합체
    LocalDateTime localDateTime = LocalDateTime.of(localDate, localTime);
    System.out.println("localDateTime = " + localDateTime);
    //계산(불변)
    LocalDateTime ofDtPlus = ofDt.plusDays(1000); 
    System.out.println("지정 날짜시간+1000d = " + ofDtPlus);         
    LocalDateTime ofDtPlus1Year = ofDt.plusYears(1);             
    System.out.println("지정 날짜시간+1년 = " + ofDtPlus1Year);
    //비교
    System.out.println("현재 날짜시간이 지정 날짜시간보다 이전인가? " + nowDt.isBefore(ofDt));
    System.out.println("현재 날짜시간이 지정 날짜시간보다 이후인가? " +
    nowDt.isAfter(ofDt));

    System.out.println("현재 날짜시간과 지정 날짜시간이 같은가? " + nowDt.isEqual(ofDt));


}

실행 결과

현재 날짜시간 = 2024-02-09T11:54:54.389163 
지정 날짜시간 = 2016-08-16T08:10:01 localDate = 2016-08-16
localTime = 08:10:01
localDateTime = 2016-08-16T08:10:01
지정 날짜시간+1000d = 2019-05-13T08:10:01 
지정 날짜시간+1년 = 2017-08-16T08:10:01 
현재 날짜시간이 지정 날짜시간보다 이전인가? false 
현재 날짜시간이 지정 날짜시간보다 이후인가? true 
현재 날짜시간과 지정 날짜시간이 같은가? false

기간, 시간의 간격 - Duration, Period

시간의 개념은 크게 2가지

• 특정 시간의 시간(시각)

  • 이 프로젝트는 2013년 8월 16일 까지 완료해야해
  • 다음 회의는 11시 30분에 진행한다.

• 시간의 간격(기간)

  • 앞으로 4년은 더 공부해야 해
  • 이 프로젝트는 3개월 남았어
  • 라면은 3분 동안 끓어야 해

Period, Duration 은 시간의 간격 을 표현하는데 사용된다. 시간의 간격은 영어로 amount of time(시간의 양)으로 불린다.

Period 두 날짜 사이의 간격을 년, 월, 일 단위로 나타낸다.

• 이 프로젝트는 3개월 정도 걸릴 것 같아
• 기념일이 183일 남았어

Duration 두 시간 사이의 간격을 시, 분, 초(나노초) 단위로 나타낸다.

• 라면을 끓이는 시간은 3분이야
• 영화 상영 시간은 2시간 30분이야
• 서울에서 부산까지는 4시간이 걸려

Period

두 날짜 사이의 간격을 년,월,일 단위로 나타낸다.

 public class Period {
      private final int years;
      private final int months;
      private final int days;
}

 package time;
  import java.time.LocalDate;
  import java.time.Period;
  public class PeriodMain {
public static void main(String[] args) { 

    //시간, 분, 초, 나노초 toHours(), toMinutes(), getSeconds(), getNano()
    //생성
    Period period = Period.ofDays(10);
    System.out.println("period = " + period);
    //계산에 사용
    LocalDate currentDate = LocalDate.of(2030, 1, 1);
    LocalDate plusDate = currentDate.plus(period);
    System.out.println("현재 날짜: " + currentDate);
    System.out.println("더한 날짜: " + plusDate);
    //기간 차이
    LocalDate startDate = LocalDate.of(2023, 1, 1);
    LocalDate endDate = LocalDate.of(2023, 4, 2);
    Period between = Period.between(startDate, endDate);
    System.out.println("기간: " + between.getMonths() + "개월 " + between.getDays() +     "일"); 
    }
}

Period 생성 방법

• of(): 특정 기간을 지정해서 Period 를 생성한다.
  • of(년, 월, 일)
  • ofDays()
  • ofMonths()
  • ofYears()

계산에 사용

• 2030 1월 1일에 10일을 더하면 2030년 1월 11일이 된다.라고 표현할 때 특정 날짜에 10일 이라는 기간을 더할수 있다.

기간 차이

• 2032년 1월 1일과 2023년 4월 2일간의 차이는 3개월 1일이다. 라고 표현할 때 특정 날짜의 차이를 구하면 기간이 된다.
• Period.between(startDate, endDate) 와 같이 특정 날짜의 차이를 구하면 Period 가 반환된다.

Duration

두 시간 사이의 간격을 시, 분, 초 단위로 나타낸다.

public class Duration {
      private final long seconds;
      private final int nanos;
 }

내부에서 초를 기반으로 시, 분, 초를 계산해서 사용한다.

• 1분 = 60초
• 1시간 = 3600초

package time;
  import java.time.Duration;
  import java.time.LocalTime;
  public class DurationMain {
    public static void main(String[] args) { 
    //생성
    Duration duration = Duration.ofMinutes(30);
    System.out.println("duration = " + duration);
    LocalTime lt = LocalTime.of(1, 0);
    System.out.println("기준 시간 = " + lt);
    //계산에 사용
    LocalTime plusTime = lt.plus(duration); 
    System.out.println("더한 시간 = " + plusTime);
    //시간 차이
    LocalTime start = LocalTime.of(9, 0);
    LocalTime end = LocalTime.of(10, 0);
    Duration between = Duration.between(start, end);
    System.out.println("차이: " + between.getSeconds() + "초");
    System.out.println("근무 시간: " + between.toHours() + "시간 " +
    between.toMinutesPart() + "분"); 
    }
}

실행 결과

duration = PT30M
기준 시간 = 01:00
더한 시간 = 01:30
차이: 3600초
근무 시간: 1시간 0분

Duration 생성 방법

• of(): 특정 시간을 지정해서 Duration을 생성한다.
  • of(지정)
  • ofSeconds()
  • ofMinutes()
  • ofHours()

계산에 사용

• 1:00에 30분을 더하면 1:30이 된다.라고 표현할 때 특정 시간에 30분이라는 시간(시간의 간격)을 더할 수 있다.

시간 차이

• 9시와 10시의 차이는 1시간이라고 표현할 때 시간의 차이를 구할 수 있다.
• Duration.between(start, end)와 같이 특정 시간의 차이를 구하면 Duration이 반환된다.

ChronoUnit VS ChrnonoField

• ChronoUnit → 시간의 간격(기간, 단위) 을 의미.

  • 예: 3일 차이 계산, 2시간 더하기

  • 즉, “기간 단위”

• ChronoField → 시간 필드의 값 을 읽고 쓸 때 사용.

  • 예: 연도 읽기, 월 읽기, 분 읽기

  • 즉, “연도/월/일/시/분 같은 필드”

ChronoUnit은 단순히 ‘시간의 단위’를 의미하는 것이고, 날짜·시간의 ‘구체적인 필드 값’을 조회하려면 ChronoField를 써야 한다.

1. ChronoUnit — 단위(기간)을 나타낸다

long days = ChronoUnit.DAYS.between(date1, date2);
long hours = ChronoUnit.HOURS.between(time1, time2);

//차이 구하기
LocalTime lt1 = LocalTime.of(1, 10, 0);
LocalTime lt2 = LocalTime.of(1, 20, 0);


//중요
long secondsBetween = ChronoUnit.SECONDS.between(lt1, lt2);
System.out.println("secondsBetween = " + secondsBetween);
long minutesBetween = ChronoUnit.MINUTES.between(lt1, lt2);
System.out.println("minutesBetween = " + minutesBetween);

여기서 DAYS, HOURS 는 필드 값이 아니라 시간 간격 단위일 뿐이다.

• long minutesBetween = ChronoUnit.MINUTES.between(lt1, lt2);
  • 이 방식은 거의 암기를 할 정도로 잘 알고 있자
  • 몇 분 차이가 나는지 확인하는 API

• “며칠 차이인지”

• “몇 시간 차이인지”

• “몇 분 차이인지”

• “plusDays(3)”이나 “plusHours(2)” 같은 연산

에 쓰인다.

✔️ 즉, ChronoUnit은 날짜·시간의 "양(수량)"을 다루는 것

2. ChronoField — 날짜·시간 "필드"를 읽고 쓸 때 사용

LocalDateTime now = LocalDateTime.now();

int year = now.get(ChronoField.YEAR);
int month = now.get(ChronoField.MONTH_OF_YEAR);
int minute = now.get(ChronoField.MINUTE_OF_HOUR);

• 올해가 몇 년인지

• 이번 달이 몇 월인지

• 현재 분(minute)이 몇 분인지

• 요일이 몇 번째 요일인지

이런 “필드 값”을 읽을 때 쓰는 게 ChronoField야.

✔️ 즉, ChronoField는 날짜·시간을 구성하는 각 조각(필드)을 의미하는 것.

날짜와 시간 문자열 파싱과 포맷팅

• 포맷팅 : 날짜와 시간 데이터를 원하는 포맷의 문자열로 변경 (Date -> String)

• 파싱: 문자열을 날짜와 시간 데이터로 변경하는 것, (String -> Date)

package time.ex;

import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.LocalTime;
import java.time.format.DateTimeFormatter;

public class FormattingMain2 {

    public static void main(String[] args) {

        //포맷팅 : 날짜와 시간을 문자로
        LocalDateTime now = LocalDateTime.of(2024, 12, 31, 13, 30, 59);

        DateTimeFormatter formatter = DateTimeFormatter.ofPattern("yyyy년MM월dd일 HH시mm분ss초");

        String format = now.format(formatter);

        System.out.println(format);



        //파싱
        String date = "2025년11월29일 09시49분32초";

        DateTimeFormatter formatter1 = DateTimeFormatter.ofPattern("yyyy년MM월dd일 HH시mm분ss초");

        LocalDateTime dateTime = LocalDateTime.parse(date, formatter1);

        LocalTime time = dateTime.toLocalTime();

        System.out.println(time);

    }

}

• 프록시 자동 생성기는 프록시를 하나만 생성한다. 프록시 팩터리가 생성하는 프록시는 내부에 여러 Advisor등을 포함 할 수 있기 때문이다.

<여러 프록시를 사용했을때>

만약에, 적용해야할 advisor가 10개라면 프록시를 10개 생성해야한다. 이 방법은 매우 비효율적이다.

Spring은 이를 해결하기위해 '프록시 팩토리' 객체를 지원한다.

아래의 코드를 보자

@Test
@DisplayName("하나의 프록시, 여러 어드바이저") void multiAdvisorTest2() {
     //proxy -> advisor2 -> advisor1 -> target
     DefaultPointcutAdvisor advisor2 
     = new DefaultPointcutAdvisor(Pointcut.TRUE,
 new Advice2());
     DefaultPointcutAdvisor advisor1 
     = new DefaultPointcutAdvisor(Pointcut.TRUE,
 new Advice1());
     ServiceInterface target = new ServiceImpl();

     ProxyFactory proxyFactory1 = new ProxyFactory(target);
     proxyFactory1.addAdvisor(advisor2);
     proxyFactory1.addAdvisor(advisor1);

     ServiceInterface proxy = (ServiceInterface) proxyFactory1.getProxy();
//실행
     proxy.save();
}

코드를 보면 proxyFactory.addAdvisor(adviosr1); , proxyFactory.addAdvisor(adviosr2); 를 통해 두개의 advisor 를 추가하는 코드를 확인할 수 있다.

자동 프록시 생성기는 모든 Advisor 빈들을 조회하고 pointcut의 프록시 적용 대상을 체크한다.

• advisor1 의 포인트컷만 만족 프록시1개 생성, 프록시에 advisor1 만 포함
• advisor1 , advisor2 의 포인트컷을 모두 만족 프록시1개 생성, 프록시에 advisor1,advisor2 모두 포함
• advisor1 , advisor2 의 포인트컷을 모두 만족하지 않음 프록시가 생성되지 않음

자동 프록시 생성기

여기서 가장 중요한것은 '빈'으로 등록되는것은 real객체가 아니라 '프록시 객체' 라는점이다.

두개의 advisor의 포인트컷을 만족 시킬 경우 다음 그림과 같다

프록시를 생성하는 '주체'는 프록시 팩토리이고 자동 프록시 생성기는 프록시 팩토리를 이용해서 프록시를 생성한다.

기존의 JVM 에 존재하는 톰캣 스레드는 커널스레드와 1대1로 매핑되어 실행이 되는 구조이다. 지금까지 CPU 코어가 톰캣 스레드를 context switching 하여 스케줄링을 하는 구조라고 알고있었지만 , 그것은 커널스레드와 Native Thread가 1대1 대응이 되기때문에 중간과정이 생력된 것이였다.

운영체제 시간에 배웠듯이 context switching 이란 스레드가 sleep, I/O 처리 등을 진행할 동안 다른 OS 커널 스레드는 다른 Thread를 점유하여 작업하는 것을 말한다.

스레드는 프로세스의 공통영역을 제외하고 만들어지기 때문에, 프로세스에 비해 크기가 작아서 생성 비용이 적고, 컨텍스트 스위칭 비용이 저렴했기 때문에 주목받아 왔다.

그러나, 요청량이 급격하게 증가하는 서버 환경에서는 갈수록 더 많은 스레드 수를 요구하게 되었다. 스레드의 사이즈가 프로세스에 비해 작다고 해도, 스레드 1개당 1MB 사이즈라고 가정하면, 4GB 메모리 환경에서도 많아야 4,000개의 스레드를 가질 수 있다. 이처럼 메모리가 제한된 환경에서는 생성할 수 있는 스레드 수에 한계가 있었고, 스레드가 많아지면서 컨텍스트 스위칭 비용도 기하급수적으로 늘어나게 되었다.

Context Switching 과정에서 발생하는 과정은 생력하겠지만,간단하게 말하면

1.커널이 개입해서 현재 스레드의 상태를 PCB(Process Control Block) 에 저장

2.새 스레드의 PCB를 불러와서 레지스터, 스택 포인터, 프로그램 카운터(PC) 복원

3.TLB flush, CPU 캐시 무효화, 유저↔커널 모드 전환

이런 전체 과정이 전부 커널 모드에서 수행되기 때문에 CPU 캐시, TLB, 커널 진입 비용이 발생합니다. 결과적으로 스위칭 하나당 수 µs 이상 걸립니다.

서버는 더 많은 요청 처리량과 컨텍스트 스위칭 비용을 줄여야 했는데, 이를 위해 나타난 스레드 모델이 경량 스레드 모델인 Virtual Thread입니다.

Virtual Thread는 기존 Java의 스레드 모델과 달리, 플랫폼 스레드와 가상 스레드로 나뉜다. 플랫폼 스레드 위에서 여러 Virtual Thread가 번갈아 가며 실행되는 형태로 동작합니다. 마치 커널 스레드와 유저 스레드가 매핑되는 형태랑 비슷하다. 가장 큰 특징은 Virtual Thread는 컨텍스트 스위칭 비용이 저렴하다는 것이다.

Thread는 기본적으로 최대 2MB의 스택 메모리 사이즈를 가지기 때문에, 컨텍스트 스위칭 시 메모리 이동량이 큽니다. 또한 생성을 위해선 커널과 통신하여 스케줄링해야 하므로, 시스템 콜을 이용하기 때문에 생성 비용도 적지 않다

하지만 Virtual Thread는 JVM에 의해 생성되기 때문에 시스템 콜과 같은 커널 영역의 호출이 적고, 메모리 크기가 일반 스레드의 1%에 불과합니다. 따라서 Thread에 비해 컨텍스트 스위칭 비용이 적다

1. 실행될 virtual thread의 작업인 runContinuation을 carrier thread의 workQueue에 push 합니다.
2. Work queue에 있는 runContinuation들은 forkJoinPool에 의해 work stealing 방식으로 carrier thread에 의해 처리됩니다.
3. 처리되던 runContinuation들은 I/O, Sleep으로 인한 interrupt나 작업 완료 시, work queue에서 pop되어 park과정에 의해 다시 힙 메모리로 되돌아갑니다.

*용어 정리 *:

Platfrom Thread : 톰캣 스레드, new Thread()로 만든 스레드, 즉 OS 커널스레드와 1대1 대응하는 스레드는 모두 Platfrom Thread이다. Carrier Thread: Platfrom Thread 의 한종류, Virtual Thread를 실행시키는 스레드이다.

JDK21 에서의 Park() 하는 과정이다. 기존의 Thread가 Virtual 인지 일반 Thread 인지 확인을 한다.

unpark()를 하는 과정을 보면 vthread.switchToCarrierThread() 함수를 볼수있다. 이 과정에서 UNPARKED 된 Virtual Thread 를 unmound()하고 다른 기존의 Carrier 스레드에게 mount()하는 과정이 발생한다.

Platform Thread VS Virtual Thread 성능 비교

context switching 비용에서 발생하는 성능테스트를 위해서 docker compose 를 비용해 CPU 코어수 1개, 스레드당 sleep(30ms) 을 가정하고 테스트를 진행하였다.

<기존 PlatFrom Thread인 경우>

<기존 Virtaul Thread인 경우>

가상의 유저를 500으로 하였을경우 위와 같은 결과가 발생하였지만 더 많은 트래픽이 발생할수록(Context Switching이 많이 발생) 할수록 성능차이가 많이 날것이다.

그래서 별도의 라이브러리 없이 사용할 수 있나보다....

클라이언트 → 서버 구독 요청

const eventSource = new EventSource("/subscribe");

GET /subscribe HTTP/1.1
Host: api.example.com
Accept: text/event-stream

브라우저는 /subscribe에 HTTP GET 요청을 보낸다. client 가 보내는 단순 GET 요청에 Accept: text/event-stream 헤더 포함만 하는것이다. (단순 요청)

서버 → 클라이언트 응답 (SseEmitter 반환)

    @GetMapping(value = "/api/subscribe", produces = MediaType.TEXT_EVENT_STREAM_VALUE)
    @ResponseStatus(HttpStatus.OK)
    public SseEmitter subscribe(@AuthenticationPrincipal UserDetails userDetails,
                                // Last-Event-ID 헤더는 마지막으로 받은 이벤트부터 이벤트 스트리밍을 재개하는 데 사용됩니다.
                                @RequestHeader(value = "Last-Event-ID", required = false, defaultValue = "")
                                String lastEventId) {

        return sseNotificationService.subscribe(userDetails.getUsername(), lastEventId);

    }

HTTP/1.1 200 OK
Content-Type: text/event-stream;charset=UTF-8
Cache-Control: no-cache
Connection: keep-alive
Transfer-Encoding: chunked

이때 컨트롤러가 SseEmitter를 반환하면 Spring MVC가 HTTP 응답을 끊지 않고 열린 스트림으로 바꿔줍니다.

• SseEmitter 는 간단하게 말하면 Event-stream 의 파이프역할(통로) 을 한다고 생각하면 쉽다.
• Client 는 최초에 받은 SseEmitter(파이프) 를 통해서 이벤트를 통해서 받으면 된다.

여기서 궁금한게 컨트롤러에서 단순하게 SSeEmitter 를 반환했을 뿐인데 헤더에 Content-Type: text/event-stream을 반환 하는것일까 ?

Spring MVC 가 요청응답의 헤더를 추가해주는 과정을 찾아보았다.

1. DispatcherServlet

// DispatcherServlet 내부
returnValueHandler.handleReturnValue(returnValue, returnType, mavContainer, webRequest);

2. Handler 선택

• SseEmitter는 ResponseBodyEmitter를 상속
• 그래서 ResponseBodyEmitterReturnValueHandler가 선택됨

public class ResponseBodyEmitterReturnValueHandler implements HandlerMethodReturnValueHandler {
    @Override
    public boolean supportsReturnType(MethodParameter returnType) {
        return ResponseBodyEmitter.class.isAssignableFrom(returnType.getParameterType());
    }
}

3. ResponseBodyEmitterReturnValueHandler 실행

@Override
public void handleReturnValue(Object returnValue, MethodParameter returnType,
        ModelAndViewContainer mavContainer, NativeWebRequest webRequest) throws Exception {

    mavContainer.setRequestHandled(true); // DispatcherServlet이 view 렌더링 안 함

    HttpServletResponse response = webRequest.getNativeResponse(HttpServletResponse.class);
    response.setHeader("Cache-Control", "no-store");
    response.setContentType("text/event-stream;charset=UTF-8"); // 🔹 여기서 헤더 세팅

    ResponseBodyEmitter emitter = (ResponseBodyEmitter) returnValue;
    emitter.initialize(response); // Emitter와 응답 OutputStream 연결
}

4. Emitter 동작

• 이제 컨트롤러에서 반환한 SseEmitter 객체는 응답 OutputStream에 바인딩됨

• 이후 다른 스레드에서 emitter.send(...) 하면 → response stream에 바로 쓰여 나갑니다.

• HTTP 응답은 200 OK 상태로 열려 있고, 끊어지지 않음

SseEmitter.send()가 내부적으로 ServletResponse.getOutputStream().write(...) 까지 이어지는 실제 I/O 플로우는 나중에 자바 입출력을 공부하고 복습해보자.

이제 이벤트가 발생했을때 (emitter.send를 했을때) Client 에 어떤 형태로 응답이 보내질까? SSE 는 서버 -> Client 니까 매번 새로운 HTTP 응답이 발생하는것인줄 알았다.

하지만 그게 아니라 최초의 응답의 헤더를 그대로 사용하는것이였다.

HTTP/1.1 200 OK
Content-Type: text/event-stream;charset=UTF-8
Cache-Control: no-cache
Connection: keep-alive
Transfer-Encoding: chunked

응답 body (계속 append 됨)

data: hello world
id: 1

event: notification
data: {"msg":"새 알림"}
id: 2

data: ping

정리하면

• 헤더는 최초 한 번 내려가고 그 상태에서 연결 유지됨.

• 이벤트가 생길 때마다 body에 줄 단위로 append.

• 클라이언트(EventSource)는 이 body 스트림을 읽어서 이벤트로 파싱.

SseEmitter.send() 를 통한 Event 전달 과정

1. Emitter와 HTTP 응답 OutputStream 연결

• 컨트롤러에서 return new SseEmitter() 하면 Spring MVC(ResponseBodyEmitterReturnValueHandler)가 이 emitter를 현재 HTTP 응답 스트림(ServletResponse.getOutputStream())과 연결해둡니다. 다시 말하면, HttpServletResponse.getOutputStream()을 얻어와서 emitter와 연결해둡니다.

• 즉, emitter 객체가 내부적으로 response outputStream을 가지고 있고, 그걸 통해 write 가능한 상태가 됩니다.

즉, emitter 객체가 내부적으로 response outputStream을 가지고 있고, 그걸 통해 write 가능한 상태가 됩니다.

2. **emitter.send() 호출 순간

**

• 내부적으로는 이렇게 처리돼요:

  outputStream.write("data: ...\n\n".getBytes());
  outputStream.flush();

  즉, 호출 즉시 응답 body에 write + flush가 일어납니다. 메서드 종료와 무관 일반적인 @ResponseBody 응답은 메서드가 return 할 때 한 번에 body를 만들어 내려주죠. SSE는 다릅니다. SseEmitter가 응답을 열어둔 상태라, 메서드가 끝났든 말든 send() 하는 순간 body에 즉시 append됩니다.

3. 클라이언트 수신 시점

• 서버에서 flush()까지 호출되면 TCP 버퍼를 통해 바로 클라이언트로 흘러갑니다. 클라이언트는 이걸 이벤트 블록 단위로 파싱해서 onmessage 또는 addEventListener로 전달받죠.

정리

1.SseEmitter.send() 호출

• 서버 쪽에서 이벤트 데이터를 준비 (data: ..., id: ..., event: ... 같은 문자열) 이걸 Spring 내부가 비동기 TaskExecutor를 통해 HTTP 응답 body에 write + flush

2.응답 body는 이미 열려 있는 HTTP 스트림 (Content-Type: text/event-stream)

• 즉, send()가 호출될 때마다 body에 append 됨 헤더는 최초 한 번만 내려갔기 때문에 이후엔 body만 계속 이어짐

3.네트워크 전송

• flush 된 데이터는 OS의 TCP 버퍼로 흘러가고 연결이 살아있는 클라이언트(EventSource)는 즉시 그 데이터를 수신

4.클라이언트 쪽 이벤트 발생

• 브라우저의 EventSource는 body에 새 블록이 append 될 때마다 파싱 → 이벤트 발생

데이터가 뻥튀기 되지 않게 할수 없을까???

[
    {
        "orderId": 1,
        "name": "userA",
        "orderDate": "2025-07-30T18:23:28.899788",
        "orderStatus": "ORDER",
        "address": {
            "city": "서울",
            "street": "1",
            "zipcode": "1111"
        },
        "orderItems": [
            {
                "itemName": "JPA1 BOOK",
                "orderPrice": 10000,
                "count": 1
            },
            {
                "itemName": "JPA2 BOOK",
                "orderPrice": 20000,
                "count": 2
            }
        ]
    },
    {
        "orderId": 2,
        "name": "userB",
        "orderDate": "2025-07-30T18:23:28.945129",
        "orderStatus": "ORDER",
        "address": {
            "city": "진주",
            "street": "2",
            "zipcode": "2222"
        },
        "orderItems": [
            {
                "itemName": "SPRING1 BOOK",
                "orderPrice": 20000,
                "count": 3
            },
            {
                "itemName": "SPRING2 BOOK",
                "orderPrice": 40000,
                "count": 4
            }
        ]
    }
]

이렇게 order 를 기준으로 페이징을 할 경우는 어떻게 해야할까 쉽게 말해서 Order 엔티티는 OrderItem 과 일대다 관계이기 때문에 fetch join 을하고 페이징이 불가능하다.

• 먼저 ToOne(OneToOne, ManyToOne) 관계를 모두 페치조인 한다. ToOne 관계는 row수를 증가시키지 않 으므로 페이징 쿼리에 영향을 주지 않는다.
• 컬렉션은 지연 로딩으로 조회한다
• 지연 로딩 성능 최적화를 위해 hibernate.default_batch_fetch_size , @BatchSize 를 적용한다. -hibernate.default_batch_fetch_size: 글로벌 설정
  • @BatchSize: 개별 최적화
  • 이 옵션을 사용하면 컬렉션이나, 프록시 객체를 한꺼번에 설정한 size 만큼 IN 쿼리로 조회한다

spring:
   jpa:
     properties:
       hibernate:
         default_batch_fetch_size: 1000

*장점 *

• 쿼리 호출 수가 1 + N 1 + 1 로 최적화 된다

• 조인보다 DB 데이터 전송량이 최적화 된다. (Order와 OrderItem을 조인하면 Order가 OrderItem 만큼 중복해서 조회된다. 이 방법은 각각 조회하므로 전송해야할 중복 데이터가 없다.)

  • 페치 조인 방식과 비교해서 쿼리 호출 수가 약간 증가하지만, DB 데이터 전송량이 감소한다.
  • 컬렉션 페치 조인은 페이징이 불가능 하지만 이 방법은 페이징이 가능하다.

• 결론*

• ToOne 관계는 페치 조인해도 페이징에 영향을 주지 않는다. 따라서 ToOne 관계는 페치조인으로 쿼리 수 를 줄이고 해결하고, 나머지는 hibernate.default_batch_fetch_size 로 최적화 하자. 객체 그래프 탐색을 하다보면 알아서 batch fetch size 에 따라서 쿼리가 in 쿼리로 한꺼번에 가져올 것이다.

XXToOne -> DTO로 바로 조회, Fetch Join XXToMany -> 페이징 필요없고 하나만 하는거면 컬렉션 페치조인 (최소한개만), 페이징할꺼면 다 XXXToOne Fetch 로 다가져오고, 나머지는 그냥 객체 그래프 탐색으로 지연로딩 + batch fetch size

참고로 컬렉션 페치 조인일때는 DTO 로 해결하지말자. 그리고 DTO 로 조회역시 SQL 을 짜는것과 유사하기 때문에 select 절에 컬렉션이 오는것 자체가 불가능해서 다른 방법을 해야한다.

대부분의 문제는 위에서 말한 엔티티를 직접 조회해서 DTO 로 변환하자. 그리고 컬렉션 fetch join 은 페이징을 안할꺼면 상관이 없지만 , 1개만 사용하자. 그리고 2개 이상사용해야하거나, 페이징을 해야되는 상황이면 ToOne 만 fetch join 하고 ToMany 는 default_batch_fetch_size 로 해결하자.

먼저 Fetch join 을 하지 않을때 어떤 문제점이 발생하는지 알아야 Fetch join 을 잘 사용할 수 있다

@GetMapping("/api/v2/orders")
    public List<OrderDto> ordersV2() {
        List<Order> orders = orderRepository.findAllByString(new OrderSearch());
        List<OrderDto> result = orders.stream()
                .map(o -> new OrderDto(o))
                .collect(Collectors.toList());

        return result;
    }

@Data
    static class OrderDto {

        private Long orderId;
        private String name;
        private LocalDateTime orderDate;
        private OrderStatus orderStatus;
        private Address address;
        //속에 있는것도 DTO로 감싸자..!
        private List<OrderItemDto> orderItems;//DTO 안에도 엔티티 관련된 리스트가 있으면 안되고 모든걸 DTO
        //private List<OrderItem> orderItems -> 이렇게 하지 말아라 , OrderItem이 엔티티라서 이렇게 하면 안됨

        public OrderDto(Order order) { // order 의 개수만큼 호출된다.
            orderId = order.getId();
            name = order.getMember().getName();//lazy 로딩 초기화 -> Order 객체의 Member 자체가 실제 엔티티를 가진다.
            orderDate = order.getOrderDate();
            orderStatus = order.getStatus();
            address = order.getDelivery().getAddress();
            //여기서 루프를 돌면서 orderItems 의 select 문이 나간다
            System.out.println("===== OrderItems 루프 시작 ======");
            orderItems = order.getOrderItems().stream()
                    .map(orderItem -> new OrderItemDto(orderItem))
                    .collect(Collectors.toList());
        }

@Data
    static class OrderItemDto {
        //프론트(client)가 요구하는 api 스펙
        private String itemName;//상품명
        private int orderPrice;//주문 가격
        private int count;//주문 수량

        //private Item item -> 그냥 OrderItem 인 경우 이런 엔티티까지 있었다. 필요한것만 가져와서 사용

        public OrderItemDto(OrderItem orderItem) {
            System.out.println("=======Item ====== ");
            itemName = orderItem.getItem().getName();// depth 가 줄어든다.
            System.out.println("=====Item 끝 =====");
            orderPrice = orderItem.getOrderPrice();
            count = orderItem.getCount();
        }
    }

여기서 먼저 Lazy 로딩이 뭔지 알아보자.

엔티티를 접근해서 특정 필드에 접근하면 그때 연관관계에 있는 엔티티가 실제로 주입이 된다. 즉 order.getMember().getName() 다른 필드도 상관없음, 필드에 접근 getName() 을 한 경우 Order 의 Member 가 실제 엔티티가 주입인된다. 이렇게 주입이 어떻게 되는것이가?

기존에 Order 의 Member 은 프록시로 존재한다. 하지만 위와 같이 접근시 Member 엔티티를 select 하는 조회 쿼리가 추가로 발생한다.

쉽게 말하면, 객체 그래프 탐색을 하면 프록시로 객체가 존재하기 때문에 필드에 접근시 추가 쿼리가 생긴다는 것이다. 이건 매우 비효율적이다.

그럼 어떻게 하면 좋을까?? 복잡한거 없다. 그냥 쿼리 조회할때 내가 필요한 엔티티 즉, client 에게 반환할 정보... 등 요구 사항에 맞춰서 필요한 데이터를 전부 쿼리를 통해서 한번에 가져오면 된다. 이렇게 가져오게 되면 Order 입장에서 Member 는 진짜 엔티티 Member 입장에서 Item 은 진짜 엔티티 이다. 이러면 추가 쿼리가 안생긴다.

public List<Order> findAllWithItem() {
        return em.createQuery(
                "select o from Order o" +
                        " join fetch o.member m" + // member : xxToOne
                        " join fetch o.delivery d" + // delivery : xxToOne
                        " join fetch o.orderItems oi" +// -> 데이터 뻥튀기 : xxToMany
                        " join fetch oi.item i", Order.class)
                //.setFirstResult(1)
                //.setMaxResults(100) -> 페이징 쿼리가 sql 이 발생하지 않고 메모리에서 처리하게 된다.
                .getResultList();//
    }

다 가져오기 위해 fetch join 으로 다 가져왔다. 매우 간단하다. 이렇게 가져온 엔티티를 객체 그래프 탐색을 그냥 하면된다.

여기서 중요한것이 있다. 컬렉션 fetch join 을 할 경우 데이터가 row 에 중복이 생긴다는것이다. 즉 . Order 기준으로 OrderItem 은 List 로 존재한다. 그럼 둘이 join 을 해서 내가 Order 를 가져오면 어떻게 될까?? 데이터가 뻥튀기 된다. 직접 확인해 보자.

위의 findAllWithItem 을 컬렉션 fetch join을 통해서 한 결과이다ㅏ. OrderId 를 보면 2개가 아니라 4개이다. 역시 뻥튀기 되었다.

그럼 어플리케이션 단에서 List<Order> order 으로 받을때도 중복 Order 가 생기는지 직접 확인해 보았다

@GetMapping("/api/v3/orders")
    public List<OrderDto> ordersV3() {
        List<Order> orders = orderRepository.findAllWithItem();
        for (Order order : orders) {
            System.out.println("order ref = " + order + " id = " + order.getId() );
        }
        List<OrderDto> result = orders.stream()
                .map(o -> new OrderDto(o))
                .collect(Collectors.toList());

        return result;

    }

결과는 이상하게 2개만 나왔따.

order ref = Order{id=1, member=jpabook.jpashop.domain.Member@765d8449, orderItems=[jpabook.jpashop.domain.OrderItem@610ff2f9, jpabook.jpashop.domain.OrderItem@7ca043fb], delivery=jpabook.jpashop.domain.Delivery@c07844, orderDate=2025-07-30T17:30:30.501906, status=ORDER} id = 1
order ref = Order{id=2, member=jpabook.jpashop.domain.Member@49dbc5cb, orderItems=[jpabook.jpashop.domain.OrderItem@3569594c, jpabook.jpashop.domain.OrderItem@2688a90d], delivery=jpabook.jpashop.domain.Delivery@682a17f8, orderDate=2025-07-30T17:30:30.576967, status=ORDER} id = 2

이게 어떻게 된것인가. 하이버네이버 6이전에는 이렇게 중복된 Order 와 같이 데이터가 뻥튀기 되었을때 중복을 제거하기 위해서 distinct 를 select 절 뒤에 추가하였다. 즉

1. DB SQL -> distinct 쿼리 발생
2. 어플리케이션 단에서 중복 루트 엔티티 제거 두가지 기능을 지원하였다.

하지만 지금은 distinct 없이도 컬렉션 fetch join 시에 알아서 distinct 를 추가해서 중복을 제거해준다고 한다. 매우 편해졌다.

컬렉션 Fetch join 의 문제점

컬렉션 페치 조인을 하면 1 대 다 관계로 인해 데이터가 뻥튀기 된다( row 수 증가) 위에서 본것처럼 row 가 여러개 발생하기 때문에 페이징 쿼리가 발생하지 않는다 내가 Order 를 OrderItem 과 fetch join 을 하면 OrderItem 의 개수만큼 row 가 생긴다. 아래 코드를 보자

 public List<Order> findAllWithItem() {
        return em.createQuery(
                "select o from Order o" +
                        " join fetch o.member m" + // member : xxToOne
                        " join fetch o.delivery d" + // delivery : xxToOne
                        " join fetch o.orderItems oi" +// -> 데이터 뻥튀기 : xxToMany
                        " join fetch oi.item i", Order.class)
                .setFirstResult(1)
                .setMaxResults(100) //-> 페이징 쿼리가 sql 이 발생하지 않고 메모리에서 처리하게 된다.
                .getResultList();//
    }

아래가 발생한 실제 sql

 select
        o1_0.order_id,
        d1_0.delivery_id,
        d1_0.city,
        d1_0.street,
        d1_0.zipcode,
        d1_0.status,
        m1_0.member_id,
        m1_0.city,
        m1_0.street,
        m1_0.zipcode,
        m1_0.name,
        o1_0.order_date,
        oi1_0.order_id,
        oi1_0.order_item_id,
        oi1_0.count,
        i1_0.item_id,
        i1_0.dtype,
        i1_0.name,
        i1_0.price,
        i1_0.stock_quantity,
        i1_0.artist,
        i1_0.etc,
        i1_0.author,
        i1_0.isbn,
        i1_0.actor,
        i1_0.director,
        oi1_0.order_price,
        o1_0.status 
    from
        orders o1_0 
    join
        member m1_0 
            on m1_0.member_id=o1_0.member_id 
    join
        delivery d1_0 
            on d1_0.delivery_id=o1_0.delivery_id 
    join
        order_item oi1_0 
            on o1_0.order_id=oi1_0.order_id 
    join
        item i1_0 
            on i1_0.item_id=oi1_0.item_i

나는 페이징 쿼리를 날렸는데 페이징 쿼리는 전혀 발생하지 않았다.

즉 jpa 는 데이터 뻥튀기가 발생한것을 알고 페이징 쿼리 자체를 db 로 보내지 않는다. 만약 보낸다고 해도 큰일이 발생한다.페이징이 안될것이다. 데이터 뻥튀기로인해서

여기서 어플리케이션 단에서 메모리위에서 페이징을 하지만 데이터가 엄청 많으면 메모리가 터질수도 있기때문에

절대 , 일대다 fetch join 에서는 페이징을 하지말자. 페이징이 없으면 그냥 사용해도 된다 어차피 중복을 제거해주니까

  BasicInteger: ms=39
  VolatileInteger: ms=455
  SyncInteger: ms=625
  MyAtomicInteger: ms=367

이런 결과가 왜 이러난 것일까?

예를 들어 스레드 100개를 동시에 실행했을때 한 쓰레드가 Lock 을 소유하게 되면 다른 스레드 99개는 전부 CPU 자원을 사용하지 않는 상태가 된다.(BLOCKING , WAITING)

하지만 AtomicInteger 와 같은 클래스는 내부적으로 CAS( Compare and swap) 을 사용한다. 다음 코드를 보자. 실제 AtomicInteger 클래스는 아니고 같은 원리로 구현해 보았다.

package thread.cas;

import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.atomic.AtomicInteger;

import static util.MyLogger.log;
import static util.ThreadUtils.sleep;

public class CasMainV3 {

    private static final int THREAD_COUNT = 2;

    public static void main(String[] args) throws InterruptedException {

        AtomicInteger atomicInteger = new AtomicInteger(0);

        System.out.println("start value = " + atomicInteger.get());


        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                incrementAndGet(atomicInteger);
            }
        };

        List<Thread> threads = new ArrayList<>();

        for (int i = 0;i < THREAD_COUNT; i++) {
            Thread thread = new Thread(runnable);
            threads.add(thread);
            thread.start();
        }

        for (Thread thread : threads) {
            thread.join();
        }

        int result = atomicInteger.get();
        System.out.println(atomicInteger.getClass().getName() + " result = " + result);


    }


    private static int incrementAndGet(AtomicInteger atomicInteger) {

        int getValue;
        boolean result;

        do {
            getValue = atomicInteger.get();
            log("getValue" + getValue);
            sleep(100);
            //  (CAS 연산의 핵심은 값이 바뀌었어(값이 읽은거랑 다르네)? -> 그럼 난 값을 바꾸지 않을꺼야 )
            //  ( 다르면 다시 시도)
            // 결국 내가 읽은 값과 같으면 값을 바꿔라 ㅎㅎ
            result = atomicInteger.compareAndSet(getValue, getValue + 1);
            log("result: " + result);

        } while (!result);

        return getValue + 1; // atomicInteger.get() 을 하면 다른 쓰레드가 값을 덮어 씌어버릴수도있어서 그러지마.
    }
}

sleep(100) 아래 주석을 달았지만, CAS 연산의 핵심은 result = atomicInteger.compareAndSet(getValue, getValue + 1); 이 부분이다.

읽은 값이랑 같으면 값을 바꾸고, 다르면 do-while 문을 반복한다.(CPU자원소모)

CompareAndSet은 참고로 비교하고 값을 연산하고 저장까지 하지만 CPU 하드웨어적으로 원자적 연산으로 취급한다. 여기서 동시성을 제어하기 위해서 CPU 자원을 소모하면 안좋은거 아닌가? 라는 생각이 들지만, 동시문 문제( 스레드 충돌) 은 간단한 원자적 연산 ( value ++ ) 일때는 CPU 의 연산속도가 매우매우 빠르게 때문에 충돌은 드물게 발생한다.

즉, 충돌이 드물게 발생을 하는데 LOCK 을 걸어서 싱글 스레드만 접근이 가능하게 하면 성능상 CAS 연산보다 안좋을 수 밖에 없다. 또한 LOCK 을 걸면 스레드의 상태가 변하기 때문에 거기서 발생하는 오버헤드 또한 크기 때문에 아무래도 성능상 좋지 않다.

하지만 위에서 말한것 처럼 CAS 연산은 , 스레드의 상태 변화가 없다. 100개의 스레드가 동시에 실행한다고 가정하면, 100개의 스레드가 모두 멀티스레드로 CPU 를 사용해 연산을 한다.

정리해보면 CAS(Compare-And-Swap)와 락(Lock) 방식의 비교

락(Lock) 방식

• 비관적(pessimistic) 접근법
• 데이터에 접근하기 전에 항상 락을 획득 다른 스레드의 접근을 막음
• "다른 스레드가 방해할 것이다"라고 가정

CAS(Compare-And-Swap) 방식

• 낙관적(optimistic) 접근법
• 락을 사용하지 않고 데이터에 바로 접근 충돌이 발생하면 그때 재시도
• "대부분의 경우 충돌이 없을 것이다"라고 가정

이를 학습한 경험으로 스레드간 충돌이 적으면(ex: value++) CAS 방식 즉 낙관적 락을 사용하는것이 좋을것이고, 충돌이 많이 발생하게 된다면, 락 방식을 고민해 볼 필요가 있다.

아래는 Thread 1000개 를 1를 증가하는 연산을 동시에 실행했을때 결과

BasicIntegerresult: 973 //충돌횟수 여기서는 37회정도발생
VolatileIntegerresult: 984 // 충돌 발생
SyncIntegerresult: 1000 //충돌 x
MyAtomicIntegerresult: 1000 // 충돌 x

앞서 스레드를 1000개를 동시에 실행했을때 중간에 sleep(100)을 줬음에도 불구하고 충돌이 1000번중 대략50번 밖에 발생하지 않았다.

정리하자면 , 간단한 cpu 연산에서는 lock 보다는 CAS 연산을 사용하는것이 효과적이다.

1. 비차단(Non‑Blocking) 알고리즘

CAS는 비차단 알고리즘의 대표격입니다.

• 스레드는 공유 변수의 예상 값(expected)과 실제 메모리 값을 비교하고, 같을 때만 새로운 값으로 교체합니다.
• 다른 스레드가 변수 값을 바꾸고 있더라도 해당 스레드는 대기(block)하지 않고 즉시 재시도(retry)할 뿐입니다.
• 반면 synchronized나 ReentrantLock은 차단(blocking) 방식으로, 락을 얻지 못하면 스레드를 대기 큐에 넣고 문맥 전환(context switch)이 발생합니다.

2. 커널 모드 전환 및 스케줄링 오버헤드 제거

락(synchronized/Lock)을 획득·해제할 때는 JVM 내부에서

1. 스핀 혹은 OS futex(fast userspace mutex) 호출
2. 대기 스레드를 OS 스케줄러에 등록
3. 컨텍스트 전환 및 스케줄링
   과 같은 일이 일어납니다.
   이 과정에서 발생하는 수백~수천 사이클의 오버헤드는,
   CAS의 한두 개의 기계어 명령다.

3. 캐시 일관성 프로토콜 최적화

모던 멀티코어 시스템은 캐시 일관성 프로토콜(MESI, MOESI 등)을 통해 캐시라인 단위로 동기화합니다.

• CAS는 한 캐시라인에서 해당 필드만 교체하며, 다른 라인에는 영향을 주지 않습니다.
• 락 해제/획득 시 JVM과 OS는 관련 캐시라인을 플러시(flush) 또는 무효화(invalidate)해야 하는데,
  이는 불필요한 메모리 대역폭 및 추가 지연을 초래합니다.

4. 스케일 아웃(Scale-Out) 시 컨텐션(Contention) 감소

• 낮은 컨텐션: 스레드가 짧은 주기로 재시도만 하기 때문에, 다른 스레드와 경쟁이 발생해도 전체 처리량이 급격히 떨어지지 않습니다.
• 높은 컨텐션: 락의 경우 한 번 락 보유자가 길게 작업 중이면, 다른 모든 스레드는 대기상태로 빠지며 CPU 자원을 활용하지 못합니다.

예를 들어 100개의 스레드가 동시에 increment()를 호출하는 상황에서,

• CAS는 각 스레드가 독립적으로 compareAndSet()을 재시도하며 진행
• 락은 1개의 스레드만 진입 후 나머지는 전부 블록 → CPU 유휴 증가

5. JVM과 하드웨어의 협업

• java.util.concurrent.atomic 패키지의 AtomicInteger나 AtomicReference는 Unsafe API를 통해 네이티브 CAS 명령어와 직접 연동합니다.
• JVM은 메모리 배리어(memory barrier)를 적절히 삽입해, 메모리 가시성을 확보하면서도 불필요한 배리어 비용은 최소화합니다.

결론 및 실제 벤치마크 결과

본 벤치마크(COUNT = 100_000_000) 환경에서 측정된 실행 시간:

• BasicInteger(락/동기화 없이 순수 연산): 최상의 성능
• MyAtomicInteger(CAS): 락 기반 방식보다 약 2배 빠른 처리
• SyncInteger/ReentrantLock(락): 커널 전환과 스케줄링 오버헤드로 크게 느림
• VolatileInteger(volatile만): 메모리 배리어 비용으로 CAS보다 빠르지만 쓰기 비용 증가

CAS 연산이 빠른 이유는 “작고 단일한 하드웨어 원자 명령” + “락을 얻기 위한 시스템 콜 불필요” + “캐시 일관성만 최소한으로 유지”하기 때문입니다.
락 기반 동기화가 필요한 복잡한 임계영역이 아니라, 단일 변수 증감처럼 간단한 동시성 제어에는 CAS가 훨씬 더 적합합니다.

아래 코드는 실제 테스트해본 코드입니다.

package thread.cas.increment;


public class IncrementPerformanceMain {

    public static final long COUNT = 100_000_000;

    public static void main(String[] args) {

        test(new BasicInteger());
        test(new VolatileInteger());
        test(new SyncInteger());
        test(new MyAtomicInteger());

    }

    private static void test(IncrementInteger incrementInteger) {
        long startMs = System.currentTimeMillis();

        for (int i = 0; i < COUNT; i++) {
            incrementInteger.increment();
        }

        long endMs = System.currentTimeMillis();

        System.out.println(incrementInteger.getClass().getSimpleName() + ": ms=" + (endMs - startMs));

    }
}

• 레디스 주요 특징
  • key-value로 구성된 단순화된 데이터 구조로 sql 쿼리 사용 불필요
  • 빠른 성능
    • 인메모리 NoSQL 데이터베이스로서 빠른 성능
      • rdb는 기본적으로 disk에 저장이고 필요시에 메모리에 캐싱하는 것이므로, rdb보다 훨씬 빠른 성능
      • redis의 메모리상의 데이터는 주기적으로 스냅샷 disk에 저장
    • key-value는 구조적으로 해시 테이블을 사용함으로서 매우 빠른 속도로 데이터 검색 가능
  • Single Thread 구조로 동시성 이슈 발생X
  • 윈도우 서버에서는 지원하지 않고, linux서버 및 macOS등에서 사용 가능

레디스 명령어를 직접 이용할 일은 없지만 한번 쯤 사용해 보자

# redis설치(linux)
sudo apt-get install redis-server
# redis접속
redis-cli

# redis도커설치(윈도우, mac)
docker run --name redis-container -d -p 6379:6379 redis
# docker 컨네이너 조회
docker ps
# redis도커 접속
docker exec -it <containerID> redis-cli

# redis는 0~15번까지의 database로 구성(default는 0번 db)
# 데이터베이스 선택
select db번호

# 데이터베이스내 모든 키 조회
keys *

# 일반적인 String 자료구조

# set을 통해 key:value 세팅.
set user:email:1 hong1@naver.com
set user:email:2 "hong2@naver.com"
# nx : 이미존재하면 pass, 없으면 set 
set user:email:1 hong1@naver.com nx
# ex : 만료시간(초단위) - ttl(time to live)
set user:email:1 hong1@naver.com ex 10
# redis활용 : refresh토큰등 사용자 인증정보 저장
set user:1:refresh_token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 ex 10000
# get을 통해 value값 얻기
get user:1:refresh_token

# 특정 key삭제
del user:email:1
# 현재 DB내 모든 key삭제
flushdb

# redis활용 : 좋아요기능 구현
set likes:posting:1 0
incr likes:posting:1 #특정 key값의 value를 1만큼 증가
decr likes:posting:1 #특정 key값의 value를 1만큼 감소
get likes:posting:1
# redis활용 : 재고관리(동시성이슈 해결)
set stocks:product:1 100
decr stocks:product:1
get stocks:product:1

# redis활용 : 캐싱 기능 구현
# 1번 member 회원 정보 조회
# select name, email, age from member where id=1;
# 위 데이터의 결과값을 redis로 캐싱 -> json형식으로 저장 {"name":"hong", "email":"hong@daum.net", "age":30}
set member:info:1 "{\"name\":\"hong\", \"email\":\"hong@daum.net\", \"age\":30}" ex 20

# list자료구조
# redis의 list는 deque와 같은 자료구조, 즉 doueble-ended queue구조

# lpush : 데이터를 왼쪽에 삽입
# rpush : 데이터를 오른쪽에 삽입
# lpop : 데이터를 왼쪽에서 꺼내기
# rpop : 데이터를 오른쪽에서 꺼내기
lpush hongildongs hong1
lpush hongildongs hong2
rpush hongildongs hong3
rpop hongildongs
lpop hongildongs

# list조회
# -1은 리스트의 끝자리를 의미. -2는 끝에서 2번째를 의미.
lrange hongildongs 0 0 #첫번째값
lrange hongildongs -1 -1 #마지막값
lrange hongildongs 0 -1 #처음부터마지막
lrange hongildongs -3 -1 #마지막3번째부터 마지막까지
lrange hongildongs 0 2

# 데이터 개수 조회
llen hongildongs
# ttl 적용
expire hongildongs 20
# ttl 조회
ttl hongildongs
# pop과 push를 동시에
# A리스트에서 POP하여 B리스트로 PUSH
rpoplpush A리스트 B리스트

# redis활용 : 최근 방문한 페이지
# 5개정도 데이터 push
# 최근방문한 페이지 3개만 보여주는
rpush mypages www.naver.com
rpush mypages www.google.com
rpush mypages www.daum.net
rpush mypages www.chatgpt.com
rpush mypages www.daum.net
lrange mypages -3 -1

# set자료구조 : 중복없음. 순서없음.
sadd memberlist member1
sadd memberlist member2
sadd memberlist member1

# set 조회
smembers memberlist
# set멤버 개수 조회
scard memberlist 
# set에서 멤버 삭제
srem memberlist member2
# 특정 멤버가 set안에 있는지 존재여부 확인
sismember memberlist member1

# redis활용 : 좋아요 구현
sadd likes:posting:1 member1
sadd likes:posting:1 member2
sadd likes:posting:1 member1
scard likes:posting:1
sismember likes:posting:1 member1

# zset : sorted set
# 사이에 숫자는 score라고 불리고, score를 기준으로 정렬
zadd memberlist 3 member1
zadd memberlist 4 member2
zadd memberlist 1 member3
zadd memberlist 2 member4

# 조회방법
# score기준 오름차순 정렬
zrange memberlist 0 -1
# score기준 내림차순 정렬
zrevrange memberlist 0 -1

# zset삭제
zrem memberlist member4

# zrank : 특정 멤버가 몇번째(index 기준) 순서인지 출력
zrank memberlist member4

# redis 활용 : 최근 본 상품목록
# zset을 활용해서 최근시간순으로 정렬
# zset도 set이므로 같은 상품을 add할 경우에 시간만 업데이트되고 중복이 제거
# 같은 상품을 더할경우 시간만 마지막에 넣은 값으로 업데이트(중복제거)
zadd recent:products 151930 pineapple
zadd recent:products 152030 banana
zadd recent:products 152130 orange
zadd recent:products 152230 apple
zadd recent:products 152330 apple
# 최근본 상품목록 3개 조회
zrevrange recent:products 0 2
zrevrange recent:products 0 2 withscores

# redis활용사례 : 주식시세저장
# 종목명: 삼성전자, 시세: 72000원, 시간: 1672527600 (유닉스 타임스탬프) -> 년월일시간을 초단위로 변환한것.(밀리초 단위도 가능능)
zadd stock:prices:samsung 1672527600 "53000"
# 종목명: LG전자, 시세: 95000원, 시간: 1672527660
zadd stock:prices:lg 1672527660 "95000"
# 종목명: 삼성전자, 시세: 72500원, 시간: 1672527720
zadd stock:prices:samsung 1672527720 "72500"
# 종목명: LG전자, 시세: 94500원, 시간: 1672527780
zadd stock:prices:lg 1672527780 "94500"
# 삼성전자의 최신 시세 조회 (최대 1개)
zrevrange stock:prices:samsung 0 0 withscores

# hashes : map형태의 자료구조(key:value key:value ... 형태의 자료구조)
hset author:info:1 name hong email hong@naver.com age 30
# 특정값 조회
hget author:info:1 name
# 모든 객체값 조회
hgetall author:info:1
# 특정 요소값 수정
hset author:info:1 name kim

# 

Redis 를 공부하고 나서 실제로 Redis 를 구현했을때 얼마나 더 빠른지 직접 확인해보자.

package com.example.redisTest.service;

import com.example.redisTest.ArticleCacheDto;
import com.example.redisTest.RequestDto;
import com.example.redisTest.entity.Article;
import com.example.redisTest.repository.ArticleRepository;
import jakarta.persistence.EntityNotFoundException;
import lombok.RequiredArgsConstructor;
import org.springframework.cache.annotation.*;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import java.util.List;
import java.util.stream.Collectors;

@Service
@RequiredArgsConstructor
@CacheConfig(cacheNames = "article")
public class ArticleService {

    public final ArticleRepository repo;


    @Transactional(readOnly = true)
    @Cacheable(key = "'all'")
    public List<ArticleCacheDto> findAll() {
        return repo.findAll()
                .stream()
                .map(a -> new ArticleCacheDto(a.getId(), a.getTitle(), a.getBody()))
                .collect(Collectors.toList());
    }

    /** 조회: @Cacheable → 캐시에 있으면 캐시에서 가져오고 없으면 DB에서 가져옴과 동시에 캐시에 올려둔다.(만료시간) */
    @Transactional
    @Cacheable(key = "#id")
    public ArticleCacheDto getById(Long id) {

        long start = System.currentTimeMillis();
        Article article = repo.findById(id)
                .orElseThrow(() -> new RuntimeException());

        return new ArticleCacheDto(article.getId(), article.getTitle(), article.getBody());

    }

    @Transactional
    public ArticleCacheDto getById2(Long id) {

        long start = System.currentTimeMillis();
        Article article = repo.findById(id)
                .orElseThrow(() -> new RuntimeException());

        return new ArticleCacheDto(article.getId(), article.getTitle(), article.getBody());

    }

    /** DB 반영: 메서드 로직(repo.save())으로 처리
     캐시 반영: 메서드 반환값을 무조건 캐시에 저장 */
    @Transactional
    @CachePut(key = "#result.id")
    @CacheEvict(key = "'all'") // -> redis-cli : DEL article::all
    public ArticleCacheDto create(RequestDto articleDto) {

        Article article = new Article(articleDto.getTitle(), articleDto.getBody());
        repo.save(article);

        return new ArticleCacheDto(article.getId(), article.getTitle(), article.getBody());
    }


    @Transactional
    @CachePut(key = "#articleDto.id")
    @CacheEvict(key = "'all'")
    public ArticleCacheDto update(RequestDto articleDto) {
        Article article = repo.findById(articleDto.getId())
                .orElseThrow(() -> new EntityNotFoundException("not found"));
        article.setTitle(articleDto.getTitle());
        article.setBody(articleDto.getBody());
        // 변경 감지 → save 호출 안 해도 됨
        return new ArticleCacheDto(article.getId(), article.getTitle(), article.getBody());
    }

    /** 삭제: @CacheEvict → DB 삭제 후 캐시에서 해당 키 제거 */
    @Transactional
    @Caching(evict = {
            @CacheEvict(key = "#id"),       // article::{id} 삭제
            @CacheEvict(key = "'all'")      // article::all 삭제
    })
    public void delete(Long id) {
        repo.deleteById(id);
    }


}

여기서 중요한게 Spring AOP 이다. 저 서비스 빈 클래스 내부에서는 해당 @Cacheable 과 같은 내부 메서드를 호출해도 캐싱이 안된다. 이것 마치 @Transactional 과 같이 Spring AOP 때문이다.

결국 캐시관련 서비스 클래스나 따로 빈을 만들어서 도메인 서비스 빈 -> 캐시관련 빈 클래스를 호출해서 사용하자.

정의: 스프링이 제공하는 범용 Redis 접근 객체. 특징:

• opsForValue(), opsForHash(), opsForList(), opsForSet(), opsForZSet(), opsForStream() 등 → Redis 자료구조 전부 다룸
• 직렬화 전략을 네가 Bean 등록 시 지정 (String, JSON, Kryo 등)
• 멱등/파이프라인/트랜잭션, Pub/Sub 모두 가능

언제 주로 사용?

• 객체를 JSON 으로 저장
• List/Set/ZSet/Stream 같은 구조 직접 활용
• 캐시라기보다 “실시간 상태 저장소” “이벤트 큐” 로 쓸 때

간단 커스터마이징 예 (JSON 값):

@Bean
public RedisTemplate<String, Object> redisTemplate(RedisConnectionFactory cf) {
    RedisTemplate<String, Object> t = new RedisTemplate<>();
    t.setConnectionFactory(cf);
    t.setKeySerializer(new StringRedisSerializer());
    t.setValueSerializer(new GenericJackson2JsonRedisSerializer());
    t.setHashKeySerializer(new StringRedisSerializer());
    t.setHashValueSerializer(new GenericJackson2JsonRedisSerializer());
    t.afterPropertiesSet();
    return t;
}

2-2. StringRedisTemplate

정의: RedisTemplate<String, String> 을 편하게 쓸 수 있도록 Spring Boot 가 자동으로 만들어 주는 특수 버전.

특징:

• Key / Value / Hash Field / Hash Value / Set Member 전부 UTF-8 String 직렬화
• 별도 Bean 선언 필요 없음 (의존성 + Redis 설정만 있으면 자동)
• CLI 로 값 보면 그대로 읽힘 → 디버깅 최고
• 객체를 넣고 싶으면 직접 JSON 변환 (ObjectMapper)

stringRedisTemplate.opsForValue().set("greeting", "hello");
stringRedisTemplate.opsForSet().add("likes:post:1", "user123");
Long size = stringRedisTemplate.opsForSet().size("likes:post:1");

언제?

• 값이 정말 싹 다 문자열 / 숫자(문자열로 변환 가능)
• 빠르게 프로토타입
• 카운터, 토큰, 플래그, Set 기반 중복체크 등

2-3. RedisCacheManager

정의: Spring Cache 추상화를 Redis 로 “백엔드” 매핑해 주는 관리자. → 네가 @Cacheable, @CachePut, @CacheEvict 를 붙이면 AOP 가 메서드 호출 전후로 자동으로 Redis 접근.

흐름 ( @Cacheable ):

1. 메서드 호출 직전 키 생성 (cacheName + 파라미터)
2. Redis 에 “이미 값 있으면” → 메서드 본문 안 타고 바로 반환
3. 없으면 메서드 실행 → 결과 직렬화해서 Redis 저장 → 반환

장점:

• 코드에 캐시 로직 if/else 안 섞임
• TTL, 직렬화 정책 중앙 관리
• 로컬/Redis 다른 구현으로 쉽게 교체

기본 설정 예:

@EnableCaching
@Configuration
public class CacheConfig {

    @Bean
    public RedisCacheManager redisCacheManager(RedisConnectionFactory cf) {
        RedisCacheConfiguration config = RedisCacheConfiguration.defaultCacheConfig()
            .entryTtl(Duration.ofMinutes(10))
            .serializeKeysWith(RedisSerializationContext.SerializationPair
                .fromSerializer(new StringRedisSerializer()))
            .serializeValuesWith(RedisSerializationContext.SerializationPair
                .fromSerializer(new GenericJackson2JsonRedisSerializer()));
        return RedisCacheManager.builder(cf)
                .cacheDefaults(config)
                .withInitialCacheConfigurations(Map.of(
                   "article", config.entryTtl(Duration.ofMinutes(5)),
                   "userProfile", config.entryTtl(Duration.ofHours(1))
                ))
                .build();
    }
}

사용 예:

@Cacheable(value = "article", key = "#id")
public ArticleDto getArticle(Long id) { ... }

@CacheEvict(value = "article", key = "#id")
public void deleteArticle(Long id) { ... }

@CachePut(value = "article", key = "#result.id")
public ArticleDto updateArticle(ArticleDto dto) { ... }

3

4

Controller
  ↓
Service
  ├─ @Cacheable getArticle(id)  ← RedisCacheManager (자동)
  ├─ likePost(postId, userId)   ← StringRedisTemplate (Set: 중복방지)
  ├─ feedRecent()               ← RedisTemplate (ZSet or Stream 소비)

• 읽기 많은 엔드포인트 → @Cacheable
• 실시간 상태(좋아요 중복, 카운트) → StringRedisTemplate
• 복잡 구조(ZSet 정렬, Stream 이벤트) → RedisTemplate (JSON 직렬화)

5

6

7

시나리오: 게시글 상세 + 좋아요 기능

8. 한눈에 흐름 그림

[Client] ──HTTP──> [Service]

[Service.getArticle(id)]
   └─ AOP: CacheInterceptor
        ├─ Redis GET (cache key: article::id)
        ├─ 없으면 -> DB 조회 -> Redis SET (TTL)
        └─ 반환

[Service.like(postId,userId)]
   ├─ StringRedisTemplate SADD likes:post:1 user123
   ├─ (added==1) => INCR likes:post:1:count
   └─ RedisTemplate XADD stream:like {...}

9

1. StringRedisTemplate: 기본 Redis 명령 감각 익히기
2. RedisTemplate (JSON 커스터마이징): ZSet, Hash, Stream 활용
3. RedisCacheManager + @Cacheable: 서비스 레이어 캐싱 구조화
4. (추가) TTL 전략, 캐시 스탬피드 방지, 분산락, 비동기 이벤트

10

1. @Cacheable 썼는데 Redis 에 값이 안 생김. 가능한 원인 2가지?
2. Set 중복 방지를 위해 어떤 템플릿과 명령?
3. 객체를 JSON 으로 넣고 싶다. 어느 Bean 에 어떤 Serializer?
4. Stream 으로 이벤트 소비 시 ACK 안 하면 어디에 남나?

(필요하면 답도 알려줄게.)

• RedisTemplate: “원하는 방식으로 직렬화 설정해서 Redis 자료구조를 직접 건드리는 범용 도구”
• StringRedisTemplate: “전부 문자열로 단순·가볍게 Redis 명령 쓰는 빠른 스타터”
• RedisCacheManager: “@Cacheable 같은 선언형 애노테이션을 Redis 저장/조회로 연결해 주는 캐시 관리자”

각각의 스레드가 하는 작업은 크게 2가지로 구분할 수 있다.

• CPU-바운드 작업
  • cpu의 연산 능력을 많이 요구하는 작업을 의미한다.
  • 이러한 작업은 주로 계산, 데이터 처리, 알고리즘 실행 등 cpu의 처리속도가 작업 완료 시간을 결정하는 경우다.
  • 예시 : 복잡한 수학 연산, 데이터 분석, 비디오 인코딩, 과학적 시뮬레이션 등

• I / O 바운드 작업
  • 디스크 , 네트워크, 파일 시스템 등과 같은 입출력 작업을 많이 요구하는 작업을 의미한다.
  • 이러한 작업은 I/O 작업이 완료될 때가지 대기 시간이 많이 발생하며 , CPU 는 상대적으로 대기 상태에 있는 경우가 많다. 쉽게 이야기 해서 스레드가 CPU 를 사용하지 않고 I /O 작업이 완료될 때 까지 대기한다.
  • 예시 : 데이터베이스 쿼리 처리 , 파일 읽기 / 쓰기, 네트워크 통신, 사용자 입력 처리 등.

현대 웹 어플리케이션 서버는 주로 CPU 바운드 작업 보다는 I / O 바운드 작업이 많다. 예를들어 백앤드 개발자의 경우 주로 웹 애플리케이션 서버를 개발하는데, 스레드가 1- 10000까지 더하는 CPU 연산이 필요한 작업보다는, 대부분 사용자의 입력을 기다리거나, 데이터베이스를 호출하고 그 결과를 기다리는 등, 기다리는 일이 많다. 쉽게 이야기 해서 스레드가 CPU 를 사용하지 않는 I / O 바운드 작업이 많다는 뜻이다.

일반적인 자바 웹 애플리케이션 서버의 경우 사용자가 요청 하나를 처리하는데 1개의 스레드가 필요하다. 사용자 4명이 동시에 요청하면 4개의 스레드가 작동하는 것이다. 그래야 4명의 사용자의 요청을 동시에 처리 할 수 있다.

사용자의 요청 하나를 처리하는데, 스레드는 CPU 를 1% 정도 사용하고 있고 , 대부분 데이터베이스 서버에 어떤 결과를 조회하면서 기다린다고 가정하자. 이대 스레드는 CPU 코어 즉 CPU 를 거의 사용하지 않고 대기한다. 바로 이것이 I / O 바운드 작업이 많다는 것이다. 여기서 1% 라는 가정을 한 이유는 스레드는 I / O 작업이 많기 때문이다.

정리하면 스레드의 숫자는 CPU-바운드 작업이 많은가, 아니면 I/O-바운드 작업이 많은가에 따라 다르게 설정해야 한다.

CPU-바운드 작업: CPU 코어 수 + 1개 CPU를 거의 100% 사용하는 작업이므로 스레드를 CPU 숫자에 최적화

I/O-바운드 작업: CPU 코어 수 보다 많은 스레드를 생성, CPU를 최대한 사용할 수 있는 숫자까지 스레드 생성 CPU를 많이 사용하지 않으므로 성능 테스트를 통해 CPU를 최대한 활용하는 숫자까지 스레드 생성 단 너무 많은 스레드를 생성하면 컨텍스트 스위칭 비용도 함께 증가 - 적절한 성능 테스트 필요