세션 방식으로 구현되어 있던 로그인 방식을 JWT로 전환하고 Redis 적용하는 과정을 기록해보고자 한다.

1. 세션에서 JWT로 전환

세션은 브라우저에 세션 ID를 저장하고 서버 메모리에 사용자 정보를 저장하는 stateful 방식이다. 이 구조는 두 가지 문제가 있다.

1. 서버를 재시작하면 메모리에 저장된 세션이 모두 사라져 전체 로그아웃이 발생한다.

2. 서버가 여러 대로 확장될 경우 서버마다 세션이 따로 존재하기 때문에 로드밸런서가 다른 서버로 요청을 보내면 로그인 상태가 유지되지 않는다.

JWT는 서버가 아무것도 저장하지 않는 stateless 방식이다. 토큰 자체에 사용자 정보가 담겨 있어 어느 서버로 요청이 가든 토큰 검증만으로 인증이 가능하다.

그리고 서버가 상태를 저장하지 않기 때문에 유저가 늘어나도 서버 메모리 부담이 없다.

현재는 단일 서버 환경이지만 실제 서비스 운영을 고려했을 때 확장성을 고려한 구조를 선택하고자 JWT로 전환하기로 했다.

2. 토큰 저장 전략

JWT는 Access Token과 Refresh Token 두 가지로 구성된다.

• Access Token : API 요청 시 인증에 사용, 탈취 피해를 최소화하기 위해 만료 시간을 짧게 설정
• Refresh Token : Access Token 만료 시 재로그인 없이 재발급받기 위한 토큰, 만료 시간이 길어 탈취 시 피해가 크다

짧은 토큰으로 보안을 챙기고 긴 토큰으로 편의성을 챙기는 역할 분리다.

토큰 저장 위치는 두 가지 공격을 기준으로 결정했다.

• XSS : 악성 스크립트로 JS에 접근해 토큰을 탈취하는 공격
• CSRF : 브라우저의 쿠키 자동 전송을 악용해 피해자 권한으로 요청을 위조하는 공격

Access Token → 클라이언트 메모리 localStorage는 XSS에 취약하고, 쿠키는 CSRF 위험이 있다. 클라이언트 메모리도 XSS에 완전히 안전하진 않지만, XSS 방어는 토큰 저장 위치가 아닌 입력값 검증 등 별도 레이어에서 처리해야 할 문제다. 클라이언트 메모리에 저장하고 Authorization 헤더로 직접 전송하면 브라우저 자동 전송이 없어 CSRF를 원천 차단할 수 있다는 점에서 이 방식을 선택했다.

Refresh Token → HttpOnly 쿠키 + Redis 수명이 길어 탈취 시 피해가 크기 때문에 JS 접근을 차단하는 HttpOnly 쿠키에 저장하기로 했다. CSRF 위험은 CORS 정책으로 공격자가 응답을 읽을 수 없어 방어된다. 하지만 쿠키는 브라우저가 들고 있어서 서버가 직접 삭제할 수 없다. 로그아웃해도 공격자가 복사해둔 토큰으로 재발급이 가능하다는 문제가 있기 때문에 Redis에 함께 저장하기로 했다. 재발급 요청했을 때 쿠키 값과 Redis 값을 비교하고, 로그아웃 시 Redis에서 삭제해서 토큰을 즉시 무효화할 수 있도록 했다.

3. 로그인 / 토큰 발급 / 로그아웃 플로우

4. 구현 : 핵심 코드 설명

(1) JwtProvider (토큰 생성/파싱)

액세스 토큰과 리프레시 토큰을 생성하는 코드이다.

두 토큰은 access/refresh 라는 타입명으로 구별하고 각각의 만료시간을 관리한다.

타입을 구별하는 이유는 Refresh Token으로 API를 호출하거나 Access Token으로 재발급을 요청하는 것을 방지하기 위해서이다.

(2) JwtAuthenticationFilter (요청마다 검증)

모든 API 요청이 들어올 때마다 Access Token을 검증하는 필터이다.

우선 Redis 블랙리스트를 확인하여 로그아웃된 토큰인지 확인하고, 정상 토큰이면 CustomOAuth2User 객체에 사용자 정보를 담아 SecurityContext에 인증 정보를 저장한다.

(3) RefreshTokenRepository (Redis CRUD)

Redis에 Refresh Token을 저장하고 삭제하는 로직이다.

만료시간은 14일로 설정했다. 독서기록 플랫폼 특성상 기록을 남기거나 모임이 있을 때만 접속하는 서비스라 매일 사용하지 않는 경우가 많다.

그래서 만료시간을 길게 잡아도 무방하다고 생각했고, 금융 서비스처럼 민감한 데이터를 다루지 않기 때문에 14일이 적절하다고 판단했다.

그리고 HttpOnly 쿠키만으로는 서버가 토큰을 직접 무효화할 수 없다. 쿠키는 클라이언트가 들고 있기 때문에 로그아웃을 해도 공격자가 복사해둔 토큰은 여전히 유효하기 때문이다. 이를 해결하기 위해 Redis에 함께 저장해 로그아웃 시 삭제함으로써 복사된 토큰도 재발급 요청에서 거부할 수 있도록 했다.

(4) AuthService (토큰 재발급 및 블랙 리스트 등록)

Access Token이 만료되었을 때 Refresh Token을 통해 재발급하고, 로그아웃 시 해당 Access Token을 블랙리스트에 등록하여 만료 전 탈취된 토큰이 사용되는 것을 방지한다.

Access Token은 stateless 특성상 서버가 직접 무효화할 수 없다. 그래서 로그아웃 시점에 남은 유효시간만큼 Redis에 블랙리스트로 등록하고, 이후 요청에서 해당 토큰이 감지되면 거부하는 방식으로 구현했다.

재발급 시에는 Refresh Token도 함께 새로 발급하는 Rotation 방식을 적용했다. Refresh Token은 HttpOnly 쿠키라 탈취 가능성이 낮지만, 탈취됐을 경우 공격자가 재발급을 시도하면 기존 토큰과 불일치로 감지되어 차단할 수 있다. 재발급 비용이 크지 않아 부담 없이 추가할 수 있었다.

5. STATELESS에서 OAuth2 state 문제와 해결

JWT 기반 stateless 환경에서는 세션이 없기 때문에 OAuth2 로그인 시 생성되는 state 값을 저장할 공간이 없다.

스프링 시큐리티는 기본적으로 세션에 저장하는데 세션을 사용하지 않으면 콜백 시점에 state 값을 비교할 수 없어서 CSRF 방어가 불가능해진다.

이를 해결하기 위해 CookieOAuth2AuthorizationRequestRepository를 구현해 state 값을 HttpOnly 쿠키에 저장했다.

로그인 시작할 때 저장하고, 카카오 콜백이 오면 쿠키에서 꺼내 비교한 뒤 즉시 삭제한다. TTL은 3분으로 설정해 로그인 완료 전 만료되지 않도록 했다.

6. 결론 / 아쉬운 점

JWT + OAuth2 + Redis를 조합해 stateless 환경에서 보안을 챙기는 인증 구조를 구현했다.

독서 모임/기록 플랫폼은 금융 서비스처럼 즉각적인 금전 피해가 발생하는 서비스는 아니지만, 개인의 독서 기록과 감상이 담긴 플랫폼인 만큼 개인정보 보호 측면에서 보안을 소홀히 할 수 없다고 판단했다.

Rotation을 적용해 탈취 감지까지 고려했지만, 자주 접속하는 유저의 경우 Refresh Token 만료시간이 사실상 의미없어지는 한계가 있다.

추후 접속 빈도에 따라 만료시간을 동적으로 조정하거나, IP/디바이스 검증을 추가하는 방향으로 개선을 해야할지 고민이 필요할 것 같다.

독크독크 플랫폼에서 개선 포인트를 찾는 중에 데이터 양이 증가할수록 성능 저하를 유발할 수 있는 비효율적인 로직을 발견했다.

특히 페이지네이션 처리 방식에서 개선할 지점을 포착하게 되었고, 이에 대한 고민과 해결 과정을 기록해보고자 한다.

1. 문제 상황 및 분석

1.1 페이지 특성

독크독크 플랫폼에서는 사용자가 읽은 책을 기록하고 관리할 수 있는 ‘내 책장’ 기능을 제공한다.

사용자가 직접 등록한 도서는 한 권 단위로 정리되어 표시되며, 해당 페이지에서는 다양한 조건에 따라 목록을 조회할 수 있다.

• 기록 상태별 조회: 기록 중 / 기록 완료
• 별점 기준 조회: 1점 ~ 5점
• 모임별 조회
• 정렬 기준 선택: 최신순 / 오래된 순

이 기능을 통해 사용자는 자신의 독서 기록을 목적에 맞게 정리하고 효율적으로 관리할 수 있다.

1.2 코드로 살펴보기

코드를 통해 흐름을 조금 더 정리해보자.

우선 내 책장 페이지의 Repository 계층을 보면 해당 쿼리에는 커서 페이지네이션에 필요한 ORDER BY, 커서 조건, LIMIT이 포함되어 있지 않다.

즉, DB 레벨에서는 단순 조회만 수행하고 있다.

반면 Service 계층을 살펴보면 정렬 기준(시간순/평점순 × 오름차순/내림차순)이 동적으로 변경된다는 이유로,

• 정렬 처리
• 커서 조건 필터링
• 조회 개수 제한(LIMIT)

이 모든 로직을 애플리케이션 레벨에서 처리하고 있다.

그 결과 실제로는 10건만 필요한 요청임에도 불구하고, 사용자가 보유한 책 전체 데이터를 DB에서 모두 조회한 뒤

• 메모리에서 정렬하고
• 커서를 기준으로 잘라내고
• 필요한 개수만 반환하는 방식으로 동작하고 있다.

결국 정렬이 동적이라는 이유로 페이지네이션을 애플리케이션 계층으로 올려버리면서, DB가 가장 잘할 수 있는 작업(정렬 + 제한)을 활용하지 못하고 있는 구조라고 볼 수 있다.

이 부분은 동적 정렬을 SQL 레벨에서 처리하도록 개선하면, 불필요한 전체 조회 없이 필요한 데이터만 효율적으로 가져올 수 있다고 생각했다.

2. 해결 과정

2.1 애플리케이션 레벨 → DB 레벨

우선 정렬, 필터링, LIMIT과 같은 작업을 애플리케이션이 아니라 데이터베이스 레벨에서 수행하도록 구조를 변경하는 것을 목표로 했다.

기존 쿼리는 GROUP BY를 통해 책 단위의 집계 결과를 생성하고 있었다. 이 과정에서 다음과 같은 집계 컬럼들이 만들어진다.

• rating (max(br.rating))
• addedAt (max(pb.added_at))
• bookReadingStatus (array_agg)
• gatherings (json_agg)

문제는 이러한 값들이 GROUP BY로 그룹이 만들어진 뒤, 집계 함수에 의해 계산되어 생성되는 컬럼이라는 점이다.

따라서 기존 구조에서는 이 값들을 WHERE 절에서 바로 활용할 수 없어, 페이지네이션이나 추가 필터링을 데이터베이스에서 처리하기 어려웠다.

그래서 집계 결과를 먼저 생성한 뒤, 그 결과를 기준으로 필터링과 페이지네이션을 수행하는 구조로 쿼리를 재구성하기로 했다.

이를 위해 CTE(Common Table Expression)를 사용하여 다음과 같이 쿼리를 분리했다.

1. CTE 단계
   • GROUP BY를 통해 책 단위의 집계 결과 생성

2. 외부 SELECT 단계
   • 집계된 결과를 기준으로 rating 필터링
   • 커서 기반 페이지네이션 적용
   • ORDER BY 및 LIMIT 처리

이렇게 구조를 분리함으로써 집계 → 필터링 → 정렬 → 페이지네이션의 흐름을 명확하게 만들 수 있었고, 애플리케이션 레벨이 아니라 DB 레벨에서 데이터 양을 줄일 수 있게 되었다.

2.2 테스트 코드

테스트 환경

• DB : PostgreSQL
• 데이터 수: 200 books
• 테스트 방식: warm-up 5회 + 측정 10회 평균

우선 내 책장에 200권의 책을 등록한 사용자를 가정하여 테스트를 진행하였다.

초기 실행에서 발생할 수 있는 캐시 미적중이나 JVM 워밍업 등의 영향을 최소화하기 위해 5회의 웜업 실행을 먼저 수행하였다.

이후 동일한 요청을 10회 반복 실행하여 평균 응답 시간을 측정하였다.

또한 쿼리 변경 전후의 차이를 보다 명확히 확인하기 위해 데이터베이스에서 실제로 반환되는 row 수를 함께 출력하도록 구성하였다.

3. 개선 결과

기존에는 데이터베이스에서 200개의 row를 모두 조회한 뒤 애플리케이션 레벨에서 필터링을 수행하고 있었다. 쿼리를 개선한 이후에는 필요한 11개의 row만 반환하도록 변경되었다.

그 결과 평균 응답 시간이 24.66ms → 17.99ms로 감소하였다.

데이터가 많아질수록 전체 조회 비용이 증가하기 때문에, 이러한 구조 개선의 효과는 더욱 커질 것으로 예상된다.

4. 배운점

이번 개선의 핵심은 단순한 응답 시간 단축보다 애플리케이션 레벨에서 처리하던 필터링과 페이지네이션을 데이터베이스 레벨로 이동시켜 구조를 개선했다는 점에 있다.

그동안 성능 개선이라고 하면 응답 시간과 같은 수치적인 변화에만 집중하는 경향이 있었다.

하지만 이번 작업을 통해 좋은 코드는 단순한 성능 수치뿐 아니라 코드의 흐름과 구조를 개선하는 과정에서도 만들어질 수 있다는 점을 배울 수 있었다.

현재 나는 독크독크라는 독서모임 플랫폼을 개발하는 프로젝트에 참여하고 있다.

독크독크는 독서모임을 진행하는 사람들을 위한 플랫폼으로, 모임 중 나눈 대화와 생각들이 모임이 끝난 뒤 단순한 기억으로 사라지지 않고 개인과 모임의 기록으로 남을 수 있도록 돕는 서비스이다.

사용자는 독서모임에 참여할 수 있고, 각 모임에서는 여러 회차별 약속이 생성된다. 모임원들은 자신이 원하는 회차에 신청해 참여할 수 있다.

이번 포스팅에서는 서비스에서 생성되는 약속 단위의 상세 정보를 조회하는 API를 중심으로 살펴보려고 한다.

1. 문제 상황 및 분석

1.1 페이지 특성

아래 이미지는 약속 상세 정보를 조회하는 API에 대한 페이지이다.

사용자는 이 페이지에서 약속의 전반적인 정보와 함께 참여 멤버들의 프로필 정보를 한눈에 확인할 수 있다.

이 페이지의 특징은 다음과 같다.

• 약속 상세 정보 조회 API
• 페이지 진입 시 단 한 번 호출되는 API
• 약속에 참여한 모든 멤버의 프로필 이미지가 함께 노출
• 멤버 수는 보통 10명 내외, 최대 약 15명 수준

이 페이지에서 성능상 문제가 될 수 있는 부분은 약속 멤버들의 프로필 이미지 presigned URL 생성 로직이다.

독크독크 플랫폼에서는 사용자 프로필 이미지를 MinIO 기반의 외부 스토리지에 저장하고 있으며, 클라이언트에서 이미지를 직접 조회할 수 있도록 서버에서 presigned URL을 생성해 전달하는 방식을 사용하고 있다.

1.2 코드로 살펴보기

이제 어떤 부분이 문제라고 느꼈는지 실제 코드 흐름을 통해 살펴보자.

멤버들의 정보를 가져오기 위해 약속ID 기준으로 멤버 정보를 가져오고 프로필 이미지 프로필 이미지 presigned URL을 생성하는 순서이다.

아래는 약속 상세 페이지 조회 시 실행되는 서비스 코드 중 약속 멤버들의 프로필 이미지 presigned URL을 생성하는 로직이다.

해당 메서드는 다음과 같은 흐름으로 동작한다.

  1. 약속에 참여한 모든 멤버를 순회한다.    2. 각 멤버의 프로필 이미지 경로를 조회한다.    3. MinIO에 presigned URL 생성을 요청한다.    4. 생성된 URL을 사용자 ID 기준으로 Map에 담아 반환한다.

1.3 구조적 문제점

앞서 살펴본 코드 흐름을 성능 관점에서 분석해보면 몇 가지 주목할 만한 구조적 특징이 있다.

프로필 이미지 presigned URL 생성은 외부 스토리지(MinIO)에 대한 네트워크 I/O 작업이다.

이 작업은 멤버 수만큼 반복 호출되는데 각 호출은 서로 독립적이고, 실행 순서에 의존하지 않는다.

즉, 현재 구조는 순서가 필요 없는 외부 I/O 작업을 N번 순차적으로 실행하는 형태라고 볼 수 있다.

그럼 굳이 순차 처리할 필요가 있을까 ? 이 지점을 병렬 처리로 개선하면, 실제 사용자 체감 성능에도 차이가 날 수 있다는 생각이 들었다.

이러한 문제 인식을 바탕으로, 해당 로직을 비동기로 전환했을 때 어느 정도 성능 향상이 발생하는지, 그리고 사용자 경험 측면에서 의미 있는 개선으로 이어질 수 있는지를 직접 확인해보았다.

2. 해결 과정

각 URL 생성 요청은 서로 의존성이 없는 독립적인 외부 I/O 작업이기 때문에, 동기 → 비동기 전환에 대표적인 방법인 @Async와 CompletableFuture를 활용해 병렬 처리 구조로 개선할 수 있다.

이를 적용하기 전 개선의 핵심이 되는 두 가지 개념을 간단히 정리해보자.

2.1 @Async와 CompletableFuture

@Async

Spring에서 제공하는 비동기 처리 어노테이션으로, 메서드에 적용하면 별도의 스레드에서 비동기로 실행된다.

해당 메서드는 호출 즉시 반환되고 실제 로직은 Spring이 관리하는 스레드 풀에서 수행된다.

여러 개의 독립적인 작업을 동시에 실행하고 싶을 때 유용하다.

CompletableFuture

비동기 작업의 결과를 담는 객체로, 작업 완료 시점을 기준으로 후속 처리를 연결할 수 있다.

비동기 작업의 완료를 기다릴 수 있고, 여러 비동기 작업을 조합할 수 있으며, 모든 작업이 끝난 시점을 한 번에 처리할 수 있다

2.2 동기 → 비동기 전환

(1) @Async 적용

각 기록 타입을 조회하는 서비스 메서드에 @Async를 적용하여 동기 방식으로 실행되던 로직을 비동기 방식으로 변경한다.

@Async를 지정함으로써 해당 메서드는 비동기적으로 실행된다.

이로 인해 호출하는 쪽에서는

• 메서드의 실행이 끝날 때까지 기다리지 않고
• 즉시 다음 로직을 수행할 수 있다.

(2) CompletableFuture 적용

각 비동기 메서드는 CompletableFuture를 반환하도록 변경하였다.

생성한 CompletableFuture를 Map에 저장한 뒤, CompletableFuture.allOf()를 사용해 한 번에 실행하고 결과를 취합한다.

이를 통해 여러 비동기 작업을 동시에 수행하고, 모든 작업이 완료된 시점에 결과를 한 번에 처리할 수 있다.

결과적으로 이전에는 순차적으로 수행되던 프로필 presigned URL 생성 로직이 병렬로 실행되도록 개선되었다.

2.3 테스트 코드

(1) 테스트 데이터 설정

이번 테스트에서는 실제 서비스에서 발생할 수 있는 상황을 최대한 가깝게 가정하여 테스트 데이터를 구성하고자 했다.

독서모임이라는 도메인 특성상, 한 번의 모임에 수백 명이 동시에 참여하는 경우는 현실적으로 드물다고 판단했다.

따라서 단순히 데이터 양을 늘리기 위해 100명, 200명 단위의 데이터를 사용하는 것은 이번 테스트의 목적과는 맞지 않다고 생각했다.

실제 독서모임에서 원활한 대화와 참여가 가능할 만한 규모를 기준으로 고민한 결과, 약속에 참여하는 멤버 수를 최대 15명으로 설정하고 관련 데이터를 구성하였다.

테스트에 사용한 데이터 구성은 다음과 같다.

• Book : 1권
• Gathering : 1개
• Gathering Member : 15명
• Meeting : 1건
• Meeting Member : 15명

이와 같은 설정을 통해 실제 서비스 환경에서 충분히 발생할 수 있는 조건에서 약속 상세 조회 API의 동작과 성능을 확인하고, 동기 처리와 비동기 처리 방식의 차이를 비교해보고자 했다.

(2) 측정 환경 설정

네트워크 상태는 항상 일정하지 않기 때문에 실제 외부 스토리지를 그대로 호출할 경우, 동기 방식과 비동기 방식의 성능을 안정적으로 비교하기 어렵다.

요청 시점이나 네트워크 상황에 따라 응답 시간이 매번 달라질 수 있어, 측정 결과가 구조 차이가 아닌 외부 환경의 영향을 받게 되기 때문이다.

그렇기 때문에 이번 테스트에서는 네트워크 환경에 따른 변수를 최대한 제거하고, 순차 실행과 병렬 실행 구조의 차이만을 검증하는 데 초점을 맞췄다.

이를 위해서 Presigned URL 생성 로직을 Mock 처리하고, 모든 요청이 네트워크 I/O 비용이 50ms인 상황을 가정하도록 동일한 지연 시간을 부여했다.

이렇게 함으로써, 동기 방식과 비동기 방식 간의 성능 차이를 보다 명확하고 일관되게 비교할 수 있도록 하였다.

*(3) 워밍업 + 반복 측정 *

성능 측정 시 초기 실행 비용에 영향 받지 않기 위해 워밍업 5회, 반복 측정 10회로 테스트를 구성했다.

• 최초 5회는 워밍업 용도로 실행
• 이후 10회를 실제 측정 대상으로 삼아 평균 응답 시간을 계산

이를 통해 일시적인 편차를 줄이고, 안정적인 평균 성능을 비교할 수 있도록 했다.

동기 방식 테스트에서는 기존의 순차 실행 메서드를 호출하고, 비동기 방식 테스트에서는 비동기 처리를 적용한 메서드를 호출한다.

응답 시간 측정은 Micrometer의 Timer를 사용하여 각 방식별 평균 실행 시간(mean)을 기준으로 비교했다.

3. 개선 결과

동기 방식에서 비동기 방식으로 개선한 결과, 약속 상세 조회 API의 평균 응답 시간이 약 917ms → 153ms로 단축되었다.

비동기 방식이 동기 방식 대비 약 17% 시간만 소요한 것으로 약 83% 응답 시간 감소했다.

presigned URL 생성 로직이 멤버 수만큼 순차적으로 실행되던 구조에서 여러 개의 외부 I/O 요청이 병렬로 처리되도록 변경되면서 외부 스토리지 응답 대기 시간이 전체 응답 시간에 미치는 영향을 크게 줄일 수 있었다.

단일 요청 내에서 다수의 외부 I/O가 포함된 구조에서는
비동기 처리만으로도 충분히 의미 있는 성능 개선이 가능함을 확인할 수 있었다.

3.1 이외 고려했던 방안 : 캐시

비동기 처리는 기존에 순차적으로 수행되던 작업을 동시에 얼마나 효율적으로 처리할 수 있는지를 고민하는 접근이다.

반면 캐시는 해당 작업을 사용자 요청마다 반복 수행해야 하는지, 재사용 가치가 있는지를 먼저 판단하는 방식이다.

이번 케이스에서 내가 비동기를 선택한 이유는 presigned URL 생성 자체의 연산 비용이 크다기보다는 직렬 구조에서 발생하는 불필요한 대기 시간이 병목의 핵심이라고 판단했기 때문이다.

Presigned URL은 본질적으로 만료 시간을 가지는 값이며, 만료 이후에는 반드시 재생성이 필요하다. 따라서 캐시를 적용하더라도 TTL 관리, 만료 시점 동기화 등의 추가적인 고려가 필요하다.

또한 약속 상세 페이지의 특성상 동일 약속을 짧은 시간 내에 반복적으로 조회할 가능성은 높지 않다고 보았다. 이 경우 캐시 히트율이 충분히 높지 않을 수 있으며, 결국 상당수 요청은 여전히 URL을 새로 생성해야 한다.

이러한 점을 종합했을 때, 이번 문제는 “계산을 줄이는 문제”라기보다 “대기 시간을 줄이는 문제”에 가까웠다고 판단했다.

따라서 캐싱보다는 직렬 I/O 구조를 병렬화하는 비동기 전환이 더 본질적인 개선 방향이라고 생각했다.

4. 배운점

이번 포스팅을 위해 비동기에 대해 공부하면서 코드 상에서는 단순한 반복 작업처럼 보이더라도 "이 작업이 서로의 결과를 기다릴 필요가 있을까?" 라는 질문 하나로 개선 포인트를 발견할 수 있었다.

외부 I/O처럼 순서에 의존하지 않는 작업은 순차 실행할 이유가 없고, 비동기 전환만으로도 충분히 의미 있는 성능 개선이 가능하다는 것을 직접 수치로 확인할 수 있었다.

5. 추가 고찰

이 글을 작성하고 나서 구현 방식 자체를 재검토하게 되었다.

외부 스토리지에 대한 이해가 부족한 상태에서 성능 개선에만 집중했던 것인데, 돌아보니 프로필 이미지에는 애초에 공개 URL 방식이 더 적합했다.

presigned URL은 외부에 직접 노출하기 어려운 리소스에 일시적인 접근 권한을 위임하기 위한 방식이다.

그런데 독크독크의 프로필 이미지는 특정 사용자에게만 접근을 제한할 필요가 없는 공개 리소스다. 이 점을 뒤늦게 인식하고, 고정 URL을 직접 반환하는 방식으로 전환했다. 결과적으로 매 요청마다 URL을 생성하는 로직 자체가 사라졌다. 클라이언트가 고정 URL로 스토리지에 직접 접근하는 방식이라 URL 생성으로 인한 병목도 함께 제거되었다.

이번 경험을 통해 두 가지를 배웠다.

1. 기술을 적용하기에 앞서 그 기술이 현재 요구사항에 적합한지를 먼저 따졌어야 했다는 것
2. 그리고 때로는 코드를 개선하는 것보다 불필요한 로직을 없애는 것이 더 나은 최적화일 수 있다는 것이다.

이전 포스팅에서는 카테고리 데이터에 로컬 캐시를 적용해 상품 조회 성능을 개선했었다.

당시에는 변경은 드물지만 조회는 잦은 데이터를 대상으로, TTL과 명시적 무효화를 함께 쓰는 전략을 선택했다.

이번에는 조금 다른 케이스였다. 관리자 대시보드에는 일별/주별/월별 포스팅 발행 통계가 노출된다.

이 데이터는 단순히 잘 안 바뀌는 수준이 아니라, 과거 구간은 아예 바뀌지 않는 불변 데이터다.

집계가 완료된 이상 지난달 통계가 달라질 일은 없다. 이 불변성에 주목하면 캐시 전략 자체를 다르게 가져갈 수 있겠다는 생각이 들었고, TTL 없이 condition만으로 캐시를 설계해보기로 했다.

1. 문제 상황

관리자 대시보드에서 주별 포스팅 통계를 조회할 때마다 통계 메서드를 호출하여 매번 DB에 접근하는 구조였다.

문제는 조회 대상이 과거 구간인 경우에도 동일하게 DB를 조회한다는 점이다. 지난주, 지난달처럼 이미 집계가 완료된 과거 통계는 이후에 값이 바뀔 일이 없다.

동일한 파라미터로 반복 조회해도 항상 같은 결과를 반환하는 구간임에도 매 요청마다 불필요한 DB I/O가 발생하고 있었다.

관리자가 대시보드를 반복적으로 확인하는 상황에서는 이러한 불필요한 조회가 누적되어 서비스 부하로 이어질 수 있다. 이 문제를 해결하기 위해 과거 통계처럼 불변성이 보장되는 데이터에 한해 로컬 캐시를 적용하는 방향을 고려하게 되었다.

2. 해결 과정

간단 개념 정리 : https://velog.io/@se0o_129/cache-strategy

2.1 캐시 선택

통계 데이터에는 로컬 캐시를 선택했다.

로컬 캐시를 선택할 때 가장 먼저 고려한 것은 데이터의 특성이었다.

과거 통계는 집계가 완료된 시점부터 값이 고정된다. 즉, 캐시에 저장된 데이터와 DB의 데이터가 달라질 여지가 구조적으로 없다.

글로벌 캐시(Redis 등)는 여러 인스턴스 간 정합성을 맞춰야 할 때 진가를 발휘하지만, 데이터 자체가 불변인 경우에는 정합성 문제가 애초에 발생하지 않는다. 네트워크 비용을 감수하면서까지 외부 캐시 서버를 거칠 이유가 없다고 생각했다. 로컬 캐시는 애플리케이션 내부 메모리에서 바로 응답하기 때문에 이 케이스에 가장 잘 맞는 선택이었다.

2.2 캐시 만료 전략 선택

이번 캐시 설계에서 가장 고민했던 부분은 만료 전략이었다.

일반적으로 캐시 만료는 TTL을 통해 일정 시간이 지나면 자동으로 제거하는 방식을 사용한다. 하지만 이번 경우에는 TTL을 설정하지 않았다.

그 이유는 과거 통계 데이터의 불변성에 있다. 이미 집계가 완료된 과거 구간의 통계는 이후에 값이 바뀌지 않는다. 만료 시점을 두는 것 자체가 의미 없고, 오히려 만료 후 동일한 데이터를 다시 DB에서 불러오는 낭비가 생긴다.

대신 @Cacheable의 condition 옵션을 활용하여 이번 달 이전 데이터만 캐시에 적재되도록 제한하기로 했다. 현재 달의 통계는 아직 집계 중인 실시간 데이터이므로 캐시 대상에서 제외했다.

Caffeine 캐시는 TTL 대신 maximumSize만 설정하여 메모리 상한선만 관리했다.

2.3 캐시 읽기 전략 선택

캐시 읽기 전략으로는 Cache-Aside를 선택했다. 캐시에 데이터가 있으면 그대로 반환하고, 없으면 DB를 조회한 뒤 결과를 캐시에 저장하는 방식으로, @Cacheable 어노테이션이 이 흐름을 자동으로 처리해준다. 관리자의 대시보드 조회가 반복될수록 캐시 히트율이 높아지고, 과거 데이터는 불변이므로 캐시와 DB 간의 정합성 문제도 발생하지 않는다.

2.4 코드 개선

1. CacheManager 설정

TTL 없이 maximumSize만 설정한 Caffeine 기반의 CacheManager를 구성했다. 캐시에 적재되는 데이터는 불변 통계이므로 만료 시점이 불필요하고, 메모리 상한선만 두어 무한 증가를 방지했다.

2. @Cacheable + condition 적용

@Cacheable의 condition 옵션을 활용하여 이번 달 이전 데이터만 캐시에 적재되도록 했다. condition 옵션은 조건이 true일 때만 캐싱을 적용하고, false면 캐시를 사용하지 않는다. 현재 달의 통계는 실시간성이 필요하므로 캐시 대상에서 제외했다.

2.5 테스트 코드

캐시 적용 전후를 두 단계로 검증했다. 첫 번째 호출에서 DB 조회가 발생하는 것을 확인하고, 동일한 파라미터로 두 번째 호출 시 캐시 히트로 DB 조회가 생략됨을 @SpyBean으로 repository 호출 횟수를 검증해 확인했다.

3. 결과

캐시 적용 전에는 동일 파라미터 조회 시 263ms(DB 1회) 가 소요되었지만, 캐시 적용 후에는 6ms(DB 0회) 로 줄어드는 것을 확인할 수 있었다.

결과적으로 약 44배의 응답 속도 개선 효과를 확인할 수 있었다.

불변성이 보장된 데이터는 캐시 히트 시 DB 접근 자체가 사라지기 때문에 성능 개선 효과가 뚜렷하게 나타난다.

4. 배운점

두 번의 캐시 적용을 통해 공통적으로 느낀 것은 캐시 전략은 데이터의 특성을 우선적으로 고려해야한다는 점이었다.

이전 카테고리 캐시에서는 잘 안 바뀌는 데이터라 TTL로 안전망을 깔자는 접근이었다면, 이번에는 아예 안 바뀌는 데이터라 만료 자체가 필요 없었다.

데이터를 먼저 이해하고 나면 전략은 자연스럽게 따라온다는 걸 알 수 있었다.

또한 이번 달 데이터처럼 실시간성이 필요한 경우는 캐시 대상에서 명시적으로 제외해야 정합성이 깨지지 않는다는 점도 다시 한번 확인할 수 있었다.

이 프로젝트는 상품 홍보 블로그 포스팅 자동화 플랫폼이다.

사용자가 상품 홍보를 위해 반복적으로 글을 작성하여 발행하는 과정을 자동화할 수 있다. 예약 시간을 지정하여 워크플로우를 생성하면, 예약한 시간에 맞춰 다음 과정이 자동 실행된다.

• 트렌드 키워드 선정
• 상품 선택
• AI 콘텐츠 생성
• 블로그 업로드

주요 개념

• Workflow(워크플로우): 글 발행 설정 단위 (블로그, 주제, 발행 주기 정의)
• Work(워크): 실제 발행 작업 단위, Workflow가 생성함

관리자는 관리자 페이지에서 Work 실행 상태 조회와 복합 조건 검색이 가능하다.

이번 글에서는 복합 조건 기반 검색 쿼리에 대한 병목(성능 저하)과 이를 해결하는 과정, 결과까지 다뤄보려고 한다.

1. 문제 상황 및 분석

관리자 워크 검색 API에선 워크플로우 이름, 워크 상태, 생성일, 사용자 이메일로 선택적으로 검색할 수 있다.

API 호출 시 다음과 같은 쿼리가 실행된다.

 select
        w1_0.work_id,
        w1_0.workflow_id,
        w2_0.name,
        w2_0.user_id,
        u1_0.email,
        ac.title,
        w1_0.posting_url,
        w1_0.status,
        w1_0.created_at 
    from
        work w1_0 
    join
        workflow w2_0 
            on w2_0.workflow_id=w1_0.workflow_id 
    join
        user u1_0 
            on u1_0.user_id=w2_0.user_id 
    left join
        ai_content ac1_0 
            on w1_0.work_id=ac1_0.work_id 
    where
        (
            ? is null 
            or w2_0.name like concat('%', ?, '%') escape ''
        ) 
        and (
            ? is null 
            or w1_0.status=?
        ) 
        and (
            ? is null 
            or w1_0.created_at>=?
        ) 
        and (
            ? is null 
            or w1_0.created_at<=?
        ) 
        and (
            ? is null 
            or u1_0.email like concat('%', ?, '%') escape ''
        ) 
    order by
        w1_0.created_at desc
    limit
        ?

쿼리 구조상 병목 가능성

API 호출 시 위와 같은 쿼리가 나오는데 데이터 규모가 적을 때는 큰 문제가 발생하지 않았다.

하지만 이 쿼리는 여러 조건이 선택적으로 적용되고, LIKE 검색과 최신순 정렬, 다수의 JOIN이 함께 사용된다.

이러한 구조는 조건 조합이 다양해 하나의 인덱스로 조회 범위를 초기에 좁히기 어렵다.

LIMIT이 있으면 정렬 비용도 자연스럽게 줄어들 것이라 막연히 생각했지만, ORDER BY 대상 컬럼이 인덱스로 처리되지 않는다면 정렬이 먼저 수행될 수도 있지 않을까 하는 생각이 들었다.

인덱스 적용 전·후의 성능 차이를 보다 명확하게 확인할 수 있도록 work 테이블은 약 50만 건으로 설정했고, 연관된 테이블들 역시 유사한 비율로 데이터 수를 맞춰 구성했다.

1.1 검색 패턴별 케이스 설정

모든 조건을 조합한 검색은 실제 사용 빈도가 높지 않다고 생각한다.

그래서 관리자 화면에서 실제로 자주 활용될 가능성이 높은 검색 패턴을 기준으로 대표적인 케이스를 세 가지로 나누어 분석해보기로 했다.

세 가지 케이스 모두 기본적으로 최신순 정렬을 기준으로 수행된다.

Case 1. 특정 상태 + 최신순

관리자 페이지의 검색은 일반 사용자 검색과 달리 최근 발생한 작업을 빠르게 파악하고 상태를 추적하는 목적이 크다.

그래서 status 필터와 최신순 정렬을 조합한 특정 상태 + 최신순 조회가 가장 기본적이고 빈번한 케이스라고 판단했다.

Case 2. 특정 상태 + 날짜 범위 + 최신순

이번 케이스는 특정 상태에 대해 기간 조건이 추가된 조회이다.

운영 과정에서는

• 특정 기간 동안 발생한 장애 이력 확인
• 월별/주별 작업 처리 현황 점검

과 같이 기간 단위로 데이터를 확인해야 하는 상황이 자주 발생한다고 생각한다.

그래서 특정 상태 + 날짜 범위 + 최신순 케이스를 통해 기간 조건이 추가되었을 때 실행 계획과 성능이 어떻게 달라지는지 확인하고자 했다.

Case 3. 사용자 이메일 + 최신순

마지막으로는 특정 사용자를 기준으로 한 조회이다.

관리자 페이지에서는

• 사용자 문의 대응
• 특정 사용자 작업 이력 추적
• 이상 동작 여부 확인

과 같은 목적으로 사용자 단위의 조회가 필요해지는 경우가 많다.

이때 사용자 기준으로 검색할 때 가장 직관적인 검색 조건이 사용자 이메일이며, 최근 작업부터 확인하는 흐름이 일반적이기 때문에 사용자 이메일 + 최신순 케이스를 별도로 분리하였다.

위 세 가지 케이스를 토대로 API 호출 속도를 확인해보자.

Case 1. 특정 상태 + 최신순 은 2473ms Case 2. 특정 상태 + 기간 + 최신순 은 811ms Case 3. 이메일 + 최신순 은 1227ms

모든 케이스에서 수백 밀리초에서 수 초 단위의 응답 시간이 발생하고 있다.

특히 Case 1의 경우 가장 기본적인 검색 패턴임에도 2.5초에 가까운 응답 시간이 소요되어 우선적인 최적화가 필요하다.

1.2 실행 계획 분석

이제 EXPLAIN 실행 계획 분석을 통해 해당 쿼리의 수치로 확인해보자.

EXPLAIN 명령어는 ** 옵티마이저의 예상 실행 계획을 의미하고, **EXPLAIN ANALYZE 명령어는 ** 실제 실행 결과 기반으로 성능 분석**한 것을 보여준다.

Case 1. 특정 상태 + 최신순

WHERE w.status='COMPLETED'
ORDER BY w.created_at DESC
LIMIT 100

[ 예상 실행 계획 ]

쿼리 조인 순서와 마찬가지로 실행계획 상에서도 work(w) -> workflow(wf) -> user(u) -> ai_content(ac) 순으로 조인할 것으로 예상된다.

현재 병목인 work 테이블의 주요 문제점을 살펴보자.

• type = ALL : 전체 테이블 스캔(Full Table Scan)

• key = NULL : 사용할 인덱스가 없음

• *Extra = Using filesort * : ORDER BY 절을 위한 추가 정렬 작업 필요

status, created_at 컬럼에 인덱스가 없어 work 테이블에서 전체 스캔과 정렬이 발생할 것으로 예상된다.

반면 work 이후에 조인되는 workflow, user, ai_content 테이블은 모두 PK·UK 기반의 eq_ref 조인으로, 성능상 병목이 되지 않는다.

• type = eq_ref

• key = PRIMARY / UNIQUE

• rows = 1

결국 이 쿼리의 핵심 문제는 조인 자체가 아니라, 조인에 들어가기 전에 work 테이블에서 데이터를 충분히 줄이지 못한다는 점이다.

** [ 실제 실행 결과 기반 성능 분석 ] **

-> Limit: 100 row(s)  (cost=292472 rows=100) (actual time=471..477 rows=100 loops=1)
    -> Nested loop left join  (cost=292472 rows=496391) (actual time=471..477 rows=100 loops=1)
        -> Nested loop inner join  (cost=180815 rows=496391) (actual time=470..472 rows=100 loops=1)
            -> Nested loop inner join  (cost=115664 rows=496391) (actual time=470..471 rows=100 loops=1)
                -> Sort: w.created_at DESC  (cost=50513 rows=496391) (actual time=470..470 rows=100 loops=1)
                    -> Filter: (w.`status` = 'COMPLETED')  (cost=50513 rows=496391) (actual time=0.99..241 rows=325000 loops=1)
                        -> Table scan on w  (cost=50513 rows=496391) (actual time=0.912..180 rows=500000 loops=1)
                -> Filter: (wf.user_id is not null)  (cost=0.25 rows=1) (actual time=0.0164..0.0165 rows=1 loops=100)
                    -> Single-row index lookup on wf using PRIMARY (workflow_id=w.workflow_id)  (cost=0.25 rows=1) (actual time=0.0162..0.0163 rows=1 loops=100)
            -> Single-row index lookup on u using PRIMARY (user_id=wf.user_id)  (cost=0.25 rows=1) (actual time=0.0123..0.0123 rows=1 loops=100)
        -> Single-row index lookup on ac using UKk2kvwlai7l0sa9n5dp448f9oo (work_id=w.work_id)  (cost=1 rows=1) (actual time=0.0457..0.0457 rows=1 loops=100)

(1) work 테이블에서 실제로 발생한 일

Table scan on w  
(cost=50513 rows=496391) 
(actual time=0.912..180 rows=500000 loops=1)

Filter: (w.`status` = 'COMPLETED')  
(cost=50513 rows=496391) (actual time=0.99..241 rows=325000 loops=1)

Sort: w.created_at DESC  (cost=50513 rows=496391) 
(actual time=470..470 rows=100 loops=1)

예상대로 work 테이블의 약 50만 건 데이터를 전체 스캔하였고, 필터링 이후에도 약 32.5만 건의 대량 데이터에 대해 created_at DESC 기준 정렬(filesort)이 수행되었다.

이 과정에서 실행 시간의 대부분이 소모되었다.

(2) 조인 비용은 실제로도 작았다

Single-row index lookup on wf using PRIMARY (workflow_id=w.workflow_id)  
(cost=0.25 rows=1) 
(actual time=0.0162..0.0163 rows=1 loops=100)

Single-row index lookup on u using PRIMARY (user_id=wf.user_id)  
(cost=0.25 rows=1) 
(actual time=0.0123..0.0123 rows=1 loops=100)

Single-row index lookup on ac using UKk2kvwlai7l0sa9n5dp448f9oo (work_id=w.work_id)  
(cost=1 rows=1) 
(actual time=0.0457..0.0457 rows=1 loops=100)

workflow / user / ai_content 모두 PK·UK 기반 단건 조회하여 조인 단계에서 유의미한 비용 증가 없었다.

(3) LIMIT은 생각보다 늦게 적용됐다.

Limit: 100 row(s)  
(cost=292472 rows=100) 
(actual time=471..477 rows=100 loops=1)

LIMIT 100이 존재함에도 불구하고, 전체 스캔과 정렬이 모두 끝난 이후에야 LIMIT이 적용되면서 실행 시간의 대부분이 LIMIT 이전 단계에서 소모되었다.

결과적으로 이 쿼리의 성능 병목은 조인이 아니라, LIMIT이 적용되기 전에 얼마나 많은 데이터를 처리하느냐에 달려 있음을 확인할 수 있다.

Case 2. 특정 상태 + 날짜 범위 + 최신순

이번 케이스는 특정 상태 + 날짜 범위 + 최신순이다.

특정 기간의 특정 상태를 검색하는 쿼리인 것이다.

WHERE w.status='COMPLETE'
    AND w.created_at BETWEEN '2025-01-01' AND '2025-01-31'
ORDER BY w.created_at DESC
LIMIT 100

** [ 예상 실행 계획 ] **

상태 + 최신순 조건에 기간 조건을 추가했지만, 실행 계획 상에서는 접근 방식(type), 조인 순서, 사용 인덱스에 변화가 없었다. 이는 기간 조건이 인덱스 스캔으로 이어지지 못하고 Full Table Scan 이후 WHERE 절에서 처리되었기 때문이다.

하지만 조건의 선택도가 높아지면서, 옵티마이저가 예상하는 필터링 비율(filtered)은 이전 케이스보다 감소했다.

** [ 실제 실행 결과 기반 성능 분석 ] **

-> Limit: 100 row(s)  (cost=210347 rows=100) (actual time=254..258 rows=100 loops=1)
    -> Nested loop left join  (cost=210347 rows=496391) (actual time=254..258 rows=100 loops=1)
        -> Nested loop inner join  (cost=153897 rows=496391) (actual time=254..257 rows=100 loops=1)
            -> Nested loop inner join  (cost=102535 rows=496391) (actual time=254..257 rows=100 loops=1)
                -> Sort: w.created_at DESC  (cost=50513 rows=496391) (actual time=254..254 rows=100 loops=1)
                    -> Filter: ((w.`status` = 'COMPLETED') and (w.created_at >= TIMESTAMP'2025-01-01 00:00:00') and (w.created_at <= TIMESTAMP'2025-01-31 00:00:00'))  (cost=50513 rows=496391) (actual time=0.426..241 rows=6045 loops=1)
                        -> Table scan on w  (cost=50513 rows=496391) (actual time=0.383..169 rows=500000 loops=1)
                -> Filter: (wf.user_id is not null)  (cost=0.346 rows=1) (actual time=0.028..0.0282 rows=1 loops=100)
                    -> Single-row index lookup on wf using PRIMARY (workflow_id=w.workflow_id)  (cost=0.346 rows=1) (actual time=0.0277..0.0278 rows=1 loops=100)
            -> Single-row index lookup on u using PRIMARY (user_id=wf.user_id)  (cost=0.25 rows=1) (actual time=0.00614..0.00617 rows=1 loops=100)
        -> Single-row index lookup on ac using UKk2kvwlai7l0sa9n5dp448f9oo (work_id=w.work_id)  (cost=0.988 rows=1) (actual time=0.00904..0.00907 rows=1 loops=100)

Filter: ((w.`status` = 'COMPLETED') 
    and (w.created_at >= TIMESTAMP'2025-01-01 00:00:00') 
    and (w.created_at <= TIMESTAMP'2025-01-31 00:00:00'))  
(cost=50513 rows=496391) 
(actual time=0.426..241 rows=6045 loops=1)

상태 조건만 적용했던 Case 1에서는 정렬 단계에서 약 32만 건의 row를 처리해야 했지만, 기간 조건을 추가하자 정렬 대상이 약 6천 건으로 줄어들었고, 조회 시간은 258ms로 이전 케이스와 큰 차이를 보였다.

비록 Table Scan 자체는 동일하게 발생했지만, 정렬 단계에서 처리해야 하는 데이터 양의 차이가 성능에 영향을 미칠 수 있다는 것을 알 수 있었다.

Case 3. 사용자 이메일 + 최신순

WHERE userEmail LIKE '%testuser1219%'
ORDER BY w.created_at DESC
LIMIT 100

** [ 예상 실행 계획 ] **

위 케이스들과 다르게 조인 순서가 user(u) -> workflow(wf) -> work(w) -> ai_content(ac) 순으로 user 테이블이 드라이빙 테이블로 선택되었다.

(드라이빙 테이블은 조인을 시작할 기준 테이블을 의미한다.)

조건절에 있는 이메일 컬럼이 user 테이블에 있기 때문으로 보인다.

user 테이블 기준으로 봤을 때,

• type = ALL : 전체 테이블 스캔

• key = NULL : 사용할 인덱스가 없음

• Extra = Using temporary : 임시 테이블 생성

• Extra = Using filesort : ORDER

이메일 LIKE 조건으로 필터링하는데, 옵티마이저는 드라이빙 테이블인 user 테이블에 정렬(ORDER BY) 대상 컬럼인 w.created_at 컬럼이 없어 임시테이블을 만들고(Using temporary) 정렬하도록 실행계획을 세웠다.

** [ 실제 실행 결과 기반 성능 분석 ] **

-> Limit: 100 row(s)  (actual time=71.9..71.9 rows=23 loops=1)
    -> Sort row IDs: w.created_at DESC, limit input to 100 row(s) per chunk  (actual time=71.8..71.8 rows=23 loops=1)
        -> Table scan on <temporary>  (cost=87935..88604 rows=53257) (actual time=71.6..71.6 rows=23 loops=1)
            -> Temporary table  (cost=87935..87935 rows=53257) (actual time=71.6..71.6 rows=23 loops=1)
                -> Nested loop left join  (cost=82610 rows=53257) (actual time=19.5..71.1 rows=23 loops=1)
                    -> Nested loop inner join  (cost=24505 rows=53257) (actual time=15.5..41.3 rows=23 loops=1)
                        -> Nested loop inner join  (cost=5865 rows=10822) (actual time=11.6..23 rows=7 loops=1)
                            -> Filter: (u.email like <cache>(concat('%','testuser1219','%')))  (cost=1023 rows=1109) (actual time=3.36..14.7 rows=1 loops=1)
                                -> Table scan on u  (cost=1023 rows=9984) (actual time=1.88..6.77 rows=10000 loops=1)
                            -> Index lookup on wf using FKav9n48jp20yik7vh3wgxcac3p (user_id=u.user_id)  (cost=3.39 rows=9.76) (actual time=8.21..8.26 rows=7 loops=1)
                        -> Index lookup on w using FKbhtldpqf1j34o02ycd4154e6t (workflow_id=wf.workflow_id)  (cost=1.23 rows=4.92) (actual time=2.27..2.62 rows=3.29 loops=7)
                    -> Single-row index lookup on ac using UKk2kvwlai7l0sa9n5dp448f9oo (work_id=w.work_id)  (cost=0.991 rows=1) (actual time=1.29..1.29 rows=1 loops=23)

*(1) user 테이블 : 필터링 -> 조인 *

Table scan on u  
(cost=1023 rows=9984) 
(actual time=1.88..6.77 rows=10000 loops=1)

Filter: (u.email like <cache>(concat('%','testuser1219','%')))  
(cost=1023 rows=1109) 
(actual time=3.36..14.7 rows=1 loops=1)

email LIKE '%testuser1219%' 조건으로 인해 이번 실행계획에서는 user 테이블이 드라이빙 테이블로 선택되었다.

하지만 선행 와일드카드가 포함된 LIKE 조건으로 인해 user 테이블에서 인덱스를 활용하지 못하고 전체 테이블 스캔이 발생했다.

(2) 임시테이블 생성

Temporary table  
(cost=87935..87935 rows=53257) 
(actual time=71.6..71.6 rows=23 loops=1)

Table scan on <temporary>  
(cost=87935..88604 rows=53257) 
(actual time=71.6..71.6 rows=23 loops=1)

Sort row IDs: w.created_at DESC, limit input to 100 row(s) per chunk  
(actual time=71.8..71.8 rows=23 loops=1)

드라이빙 테이블인 user에 정렬 컬럼 w.created_at이 없어, 조인 이후 임시 테이블을 생성한 뒤 정렬(filesort)을 수행되었다.

(3) LIMIT 적용

Limit: 100 row(s)  
(actual time=71.9..71.9 rows=23 loops=1)

LIMIT은 모든 필터링과 정렬 이후에 적용되었다.

이 케이스를 수행하기 위해 총 71.9ms가 소요되었다.

결과적으로 Case1과 마찬가지로 LIMIT 100이 존재함에도 불구하고, 필터링과 정렬이 모두 완료된 이후에야 LIMIT이 적용되어 정렬 비용이 쿼리 성능을 차지하게 되었다.

2. 해결 방안

2.1 인덱스 설계 전략

각 케이스의 실행 계획을 바탕으로, 아래 세 가지 내용을 고려하여 설계하기로 했다.

• WHERE 조건 컬럼의 인덱스를 생성하여 Full Scan 제거
• ORDER BY 컬럼의 인덱스에 생성하여 filesort 제거
• 다중 컬럼 인덱스의 순서는 컬럼의 카디널리티와 쿼리 패턴을 고려

work 테이블은 블로그 포스팅 작업 단위로 데이터가 계속 누적되며, 작업 생성, 상태 변경, 완료 처리 과정에서 INSERT와 UPDATE가 매우 빈번하게 발생하는 테이블이다.

이러한 특성에도 불구하고 모든 조건에 만족하는 인덱스를 생성하게 된다면, 인덱스 수가 증가하면서 성능 저하로 이어질 수 있다.

따라서 이번 인덱스 적용에서는 모든 경우를 최적화하기보다, 실제 사용 빈도가 가장 높은 조회 시나리오를 기준으로 성능 개선 효과가 큰 인덱스를 우선 적용하는 방향으로 설계하기로 했다.

2.2 인덱스 적용

Case 1. 특정 상태 + 최신순

1번 케이스의 문제점은 아래와 같다.

• status 조건이 있지만 50만 건에 대한 Full Scan
• ORDER BY 컬럼의 인덱스 부재로 인한 filesort

이를 토대로 아래와 같은 복합 인덱스를 적용하려고 한다.

CREATE INDEX idx_work_status_created
ON WORK(status, created_at DESC)

왜 status를 선두 컬럼으로 선택했는가?

일반적으로 카디널리티가 높은 컬럼을 둬야 인덱스 효과를 볼 수 있는데, 둘 중 비교했을 때 카디널리티가 더 높은 created_at이 아닌 카디널리티가 낮은 status를 인덱스의 선두 컬럼으로 둔 이유는 status가 모든 검색에 필수 조건은 아니지만 관리자 검색에서 빈번하게 사용되는 검색 조건이기 때문이다.

created_at을 선두로 둘 경우

• 최신 데이터부터 인덱스를 탐색한다.
• 각 row마다 status를 검사한다.
• 이때 원하는 status 값이 아닐 경우 계속 스킵하게 된다.
• LIMIT 100을 채우기 위해 많은 row를 탐색하게 될 수 있다.

status를 선두로 둘 경우

• 원하는 status에 해당하는 row들로 범위를 좁힌다.
• created_at 기준으로 정렬이 되어있다.
• 거기서 100개만 읽고 종료하면 된다.

그래서 카디널리티보다 쿼리 패턴과 LIMIT의 특성을 우선으로 하여 status는 선두 컬럼, created_at은 후행 컬럼으로 선택했다.

Case 2. 특정 상태 + 날짜 범위 + 최신순

2번 케이스의 문제점은 아래와 같다.

• status + created_at 두 가지 조건으로 검색 범위는 줄었지만 인덱스 미사용
• 50만 건 모두 Full scan 후 6천 건 filesort

하지만 이 경우는 Case 1에서 설계한 idx_work_status_created 인덱스로 커버가 가능하다.

status + created_at 이번 케이스와 같은 조건으로 설계된 인덱스이기 때문에 별도의 인덱스 생성 없이 해결할 수 있다.

Case 3. 사용자 이메일 + 최신순

3번 케이스의 문제점은 아래와 같다.

• 선행 와일드카드가 존재하는 LIKE 조건절로 인덱스 활용 불가능
• user 테이블의 Full Scan이 불가피하게 발생
• 임시 테이블 생성 및 정렬 작업 발생

이번 케이스의 한계는 LIKE 조건절이 인덱스 활용이 불가능하여 인덱스 생성이 불가능하다.

3. 결과

이제 인덱스 적용 후 예상 실행 계획과 실제 실행 결과를 비교해보자.

Case 1. 특정 상태 + 최신순

[ 예상 실행 계획 ]

type : ALL -> ref key : NULL -> idx_work_status_created Extra : Using filesort -> NULL

실행 계획을 보면, 기존의 Full Table Scan 대신 인덱스를 이용한 동등 조건 탐색으로 변경되었고, 정렬 또한 인덱스 순서를 활용하면서 filesort가 제거되었다.

[ 실제 실행 결과 기반 성능 분석 ]

-> Limit: 100 row(s)  (cost=473200 rows=100) (actual time=0.48..1.81 rows=100 loops=1)
    -> Nested loop left join  (cost=473200 rows=248195) (actual time=0.478..1.8 rows=100 loops=1)
        -> Nested loop inner join  (cost=201176 rows=248195) (actual time=0.452..1.27 rows=100 loops=1)
            -> Nested loop inner join  (cost=114308 rows=248195) (actual time=0.44..0.955 rows=100 loops=1)
                -> Index lookup on w using idx_work_status_created (status=''COMPLETED'')  (cost=27440 rows=248195) (actual time=0.415..0.455 rows=100 loops=1)
                -> Filter: (wf.user_id is not null)  (cost=0.25 rows=1) (actual time=0.00458..0.00471 rows=1 loops=100)
                    -> Single-row index lookup on wf using PRIMARY (workflow_id=w.workflow_id)  (cost=0.25 rows=1) (actual time=0.00435..0.00439 rows=1 loops=100)
            -> Single-row index lookup on u using PRIMARY (user_id=wf.user_id)  (cost=0.25 rows=1) (actual time=0.00289..0.00293 rows=1 loops=100)
        -> Single-row index lookup on ac using UKk2kvwlai7l0sa9n5dp448f9oo (work_id=w.work_id)  (cost=0.996 rows=1) (actual time=0.00494..0.00498 rows=1 loops=100)

Index lookup on w using idx_work_status_created (status='COMPLETED')  
(cost=27440 rows=248195) 
(actual time=0.331..0.363 rows=100 loops=1)

새로 인덱스를 추가한 인덱스도 정상적으로 사용하며 LIMIT 100에 도달하자 추가 탐색 없이 바로 종료되는 것을 확인할 수 있었다.

결과적으로 쿼리 실행 속도는 447ms -> 1.81ms, API 호출 속도는 2473ms -> 270ms 로 개선되었다.

Full Table Scan과 filesort가 제거되면서 처리해야 할 레코드 수와 정렬 비용이 줄어든 것으로 보인다.

Case 2. 특정 상태 + 날짜 범위 + 최신순

[ 예상 실행 계획 ]

type : ALL -> range key : NULL -> idx_work_status_created Extra : Using filesort -> NULL

두 번째 케이스는 Full Table Scan에서 범위 탐색으로 변경되었고, 동일하게 정렬 또한 인덱스 순서를 활용하면서 filesort가 제거되었다.

[ 실제 실행 결과 ]

-> Limit: 100 row(s)  (cost=13539 rows=100) (actual time=0.276..1.62 rows=100 loops=1)
    -> Nested loop left join  (cost=13539 rows=6045) (actual time=0.275..1.61 rows=100 loops=1)
        -> Nested loop inner join  (cost=6952 rows=6045) (actual time=0.264..1.09 rows=100 loops=1)
            -> Nested loop inner join  (cost=4836 rows=6045) (actual time=0.243..0.757 rows=100 loops=1)
                -> Index range scan on w using idx_work_status_created over (status = 'COMPLETED' AND '2025-01-31 00:00:00.000000' <= created_at <= '2025-01-01 00:00:00.000000'), with index condition: ((w.`status` = 'COMPLETED') and (w.created_at >= TIMESTAMP'2025-01-01 00:00:00') and (w.created_at <= TIMESTAMP'2025-01-31 00:00:00'))  (cost=2721 rows=6045) (actual time=0.228..0.319 rows=100 loops=1)
                -> Filter: (wf.user_id is not null)  (cost=0.25 rows=1) (actual time=0.00385..0.00402 rows=1 loops=100)
                    -> Single-row index lookup on wf using PRIMARY (workflow_id=w.workflow_id)  (cost=0.25 rows=1) (actual time=0.00356..0.00362 rows=1 loops=100)
            -> Single-row index lookup on u using PRIMARY (user_id=wf.user_id)  (cost=0.25 rows=1) (actual time=0.00292..0.00298 rows=1 loops=100)
        -> Single-row index lookup on ac using UKk2kvwlai7l0sa9n5dp448f9oo (work_id=w.work_id)  (cost=0.99 rows=1) (actual time=0.00465..0.00471 rows=1 loops=100)

-> Index range scan on w using idx_work_status_created over 
(status = 'COMPLETED' AND '2025-01-31 00:00:00.000000' <= created_at <= '2025-01-01 00:00:00.000000'), 
with index condition: ((w.`status` = 'COMPLETED') and (w.created_at >= TIMESTAMP'2025-01-01 00:00:00') and (w.created_at <= TIMESTAMP'2025-01-31 00:00:00'))  
(cost=2721 rows=6045) 
(actual time=0.228..0.319 rows=100 loops=1)

Case 1에서 생성했던 idx_work_status_created 인덱스를 잘 사용하는 걸 확인할 수 있었다.

created_at 범위가 역순으로 보이는 이유

그런데 created_at 범위가 역순(끝 <= created_at <= 시작)으로 표시되어 잘못 조회하는 것은 아닌지 의문이 들 수 있다. 내가 그랬다 ..

하지만 이건 인덱스가 (status, created_at DESC)로 정의되어 있어 MySQL은 인덱스를 역방향으로 스캔한다.

EXPLAIN에서 끝 <= created_at <= 시작 형태로 표시되는 것은 역방향 스캔의 시작점과 끝점을 보여주는 것일 뿐, 실제 WHERE 조건(2025-01-01 ~ 2025-01-31)은 정상적으로 적용된다.

결과적으로 쿼리 실행 속도는 258ms -> 1.62ms, API 호출 속도는 811ms -> 116ms 로 개선되었다.

Case 3. 사용자 이메일 + 최신순

세 번째 케이스는 인덱스를 통한 성능 개선은 어렵다고 생각되어 이번 포스팅의 개선 대상에서 제외하였다.

이미 실행 계획 분석 단계에서 확인했듯이, 이 병목은 인덱스 설계로 해결할 수 있는 문제가 아니라 쿼리 구조 자체의 제약으로 인한 문제라고 생각된다.

따라서 인덱스 추가보다는 검색 방식 변경이나 조회 구조 분리 등 다른 방향의 개선이 필요할 것으로 보인다.

본 포스팅에서는 인덱스 적용을 통한 성능 개선에 초점을 두고 있기 때문에, 이 케이스의 추가적인 개선 방안은 추후 검토해볼 예정이다.

개선 전 후 비교표

4. 배운점

인덱스 설계는 이론만으로 결정되지는 않는다는 걸 느꼈다.

원래는 "인덱스 설계는 정해진 원칙대로만 하면 되는 것 아닐까" 라는 생각을 가지고 있었다. 하지만 이번 포스팅을 작성하면서 직접 쿼리를 분석하고 정리해보니, 쿼리 패턴이나 실제 사용 용도에 따라 이론이 항상 그대로 적용되지는 않는다는 걸 느끼게 되었다.

중요한 것은 인덱스 원칙 자체보다, 이 쿼리가 어떤 상황에서, 어떤 데이터를 가장 많이 조회하는지를 먼저 이해하고 그에 맞게 인덱스를 설계하는 것이라는 생각이 들었다.

LIMIT은 만능이 아니며, 인덱스와 함께 사용할 때 의미가 있다.

LIMIT으로 조회 건수를 줄이면 성능도 자연스럽게 좋아질 것이라고 막연하게 생각했던 적이 있다.

하지만 대량의 데이터를 만들어 직접 실행해보니, LIMIT 자체보다 LIMIT이 언제 적용되느냐가 훨씬 중요하다는 걸 체감할 수 있었다.

정렬과 필터링이 끝난 이후에 LIMIT이 적용되는 구조라면, LIMIT이 있어도 이미 대부분의 비용이 발생한 뒤였다. 결국 LIMIT은 인덱스와 함께 사용될 때에만 실제로 성능 개선 효과를 낼 수 있다는 점을 알게 되었다.

모든 성능 문제를 인덱스로 해결할 수 있는 것은 아니었다.

처음에는 세 번째 케이스 역시 인덱스를 통해 개선할 수 있을 것이라 생각하고 분석 대상으로 포함했다.

하지만 실행 계획을 살펴보고 실제로 인덱스 적용을 검토하는 과정에서, 이 경우에는 인덱스로 해결하기 어려운 구조라는 점을 확인할 수 있었다.

이번 분석을 통해 성능 이슈라고 해서 항상 인덱스 추가가 정답은 아니며, 문제의 원인이 어디에 있는지를 먼저 파악하는 것이 더 중요하다는 점을 느꼈다.

카페 주문 플랫폼 프로젝트를 리팩토링하던 중 장바구니 조회 페이지에서 예상보다 많은 쿼리가 실행되고 있는 것을 로그를 통해 발견했다.

특히 장바구니에 음료를 하나씩 추가할수록 조회 시 실행되는 쿼리 수가 함께 증가하는 현상이 나타났다.

이러한 패턴을 보며 성능 병목이 발생할 수 있는 API라고 생각했고, 문제의 원인을 명확히 확인해보기로 했다.

이번 포스팅에서는 N+1 문제를 분석하고 개선한 과정까지 작성해보려 한다.

1. 문제 상황 및 분석

1.1 문제 상황 확인

장바구니 조회 API를 기준으로 랜덤으로 각 상품에 3개의 옵션을 선택한 뒤 상품을 하나씩 장바구니에 담아가며 API를 호출해보았다.

그 결과 상품을 하나 추가할 때마다 쿼리 로그가 상품 수가 증가함에 따라 쿼리 수 역시 함께 증가하는 것을 발견했다.

이를 통해서 연관 관계 조회 과정에서 불필요한 쿼리가 반복적으로 발생하고 있을 가능성을 의심하게 되었다.

먼저 대시보드를 통해 전반적인 흐름을 파악한 뒤, 테이블 구조를 정리하고 테스트 코드를 통해 쿼리 수를 정확히 확인해보겠다.

1.2 장바구니 도메인 구조

현재 ERD 구조

Cart
 └─ CartItem
     ├─ Product
     └─ CartOption
         └─ ProductOption
             └─ OptionStyle

• Cart / CartItem

  • Cart는 회원당 하나의 장바구니를 가지며, CartItem은 장바구니에 담긴 상품 단위이다.

• CartOption

  • CartOption은 CartItem에 대해 사용자가 실제로 선택한 옵션을 저장하는 테이블이다.
  • 하나의 상품에는 여러 옵션이 선택될 수 있으며, 이로 인해 CartItem ↔ CartOption은 1:N 관계를 가진다.

• ProductOption / OptionStyle

  • 옵션 정보는 ProductOption과 OptionStyle로 분리되어 있다.
  • ProductOption : 상품에 어떤 옵션이 존재하는지
  • OptionStyle : 옵션명과 추가 가격 등 실제 표시/계산에 필요한 정

이러한 구조에서는 CartItem 하나를 조회하더라도 선택된 옵션 수에 따라 연관 엔티티 조회가 반복적으로 발생할 가능성이 있다.

1.3 문제가 발생하는 Service 코드

N+1 문제가 발생하는 API의 서비스 코드를 살펴보자.

우선 멤버 아이디를 기준으로 장바구니 엔티티를 조회하면서 Fetch Join을 통해 장바구니 상품과 상품 엔티티까지 함께 조인하고 있다.

하지만 상품 조회 페이지에서는 상품 정보뿐만 아니라, 해당 상품에 대한 옵션 정보도 필요함에도 불구하고 상품 옵션 엔티티에 대해서는 Fetch Join을 사용하지 않고 있었다.

Fetch join으로 가져오지 않은 cartOption, optionStyle, member 엔티티의 데이터를 메서드를 통해 연관관계를 따라 체이닝 방식으로 접근하면서, 각 상품마다 그에 해당하는 데이터를 가져오기 위해서 추가 쿼리가 발생하고 있었다.

결과적으로 상품과 선택한 옵션 수만큼 추가 쿼리가 실행되면서 N+1 문제가 발생하고 있음을 확인할 수 있었다.

1.4 N+1 문제 탐지 결과

테스트 코드 기반으로 정확한 수치를 확인해보겠다.

테스트 환경

• 데이터베이스 : MySQL (HikariCP 커넥션 풀)
• 테스트 데이터 : 옵션 3개 이상인 상품 10개 선택, 각 상품당 3개 옵션 선택 (총 30개)
• JPA 1차 캐시 : 매 측정마다 EntityManager.clear()로 초기화하여 캐시 영향 제거

측정 방법:

• 워밍업 : 3회 실행 (JVM 최적화 및 DB 준비)
• 실제 측정 : 10회 반복 후 평균값 산출
• 수집 지표 : 쿼리 실행 횟수, 응답 시간(평균/최대/P95), 테이블별 쿼리 분포

테스트 데이터로 옵션이 3개 이상 등록된 상품 10개를 조회하여 사용하였다.

내부적으로는 실행 시간, 쿼리 수을 수집하였고 응답시간은 평균, 최대, P95 기준으로 비교하였다.

P95 기준 응답 시간은 약 475ms 정도였고, 동일 조건에서 더 다양한 옵션을 선택할 경우 option_style에 대한 쿼리 수가 증가하면서 응답 시간 또한 함께 증가할 것으로 예상된다.

옵션 3개씩 적용된 상품 10개가 담긴 장바구니를 조회한 결과 총 46개의 쿼리가 발생한 것을 확인할 수 있었다.

• product_option : 3 × 10 = 30회
• nutrition_info : 10회
• option_style : 4회
• cart_option, cart : 각각 1회

그런데 여기서 추가로 발견한 문제점이 있다.

product와 1:1 연관관계를 맺고 있는 nutrition_info(영양 정보) 엔티티에서 10개의 추가 쿼리가 발생하고 있었다.

처음에는 단순한 로딩 전략 문제라고 생각했다. 하지만 원인을 찾아보니 @OneToOne 연관관계에서 FK의 위치로 인해 발생한 문제였다.

nutrition_info는 product를 참조하고 있으며, FK는 nutrition_info 테이블에 존재한다.

장바구니 조회에서는 nutrition_info 데이터를 전혀 사용하지 않음에도 불구하고, product 엔티티를 로딩하는 과정에서 nutrition_info에 대한 추가 조회 쿼리가 발생하고 있었다.

이는 FK가 존재하지 않는 쪽(product)에서 @OneToOne(fetch = LAZY) 연관관계를 사용할 경우 발생하는 JPA의 특성 때문이다.

JPA는 프록시를 생성하기 위해 연관 엔티티의 식별자(ID)를 알아야 하지만, 이 경우 product 엔티티만으로는 nutrition_info의 ID를 알 수 없다. 따라서 nutrition_info가 실제로 존재하는지, 혹은 null인지 판단하기 위해 즉시 조회 쿼리를 실행할 수밖에 없다.

그 결과, fetch = LAZY로 설정했음에도 실제로는 즉시 로딩처럼 동작하게 되며, 이 조회가 상품 수만큼 반복되면서 N+1 문제가 발생하게 된다.

이는 단순한 Fetch 전략 변경으로 해결할 수 있는 문제가 아니라 연관관계 매핑 설계 자체에서 발생한 문제라고 볼 수 있다.

2. N+1 문제 해결 전략

2.1 대표적인 세 가지 전략

N+1 문제를 해결하는 대표적인 세 가지 전략을 간단하게 살펴보자.

Fetch Join

패치 조인을 사용할 경우, 연관관계에 해당하는 엔티티를 하나의 쿼리로 한 번에 조회할 수 있다. 이렇게 조회된 엔티티는 이후 접근 시에도 추가 쿼리가 발생하지 않는다.

목록 조회에서 항상 함께 사용하는 연관 엔티티가 명확하고, 데이터 양이 많지 않을 때 가장 확실한 해결 방법이다.

@BatchSize

하나의 쿼리 수행 시, IN 절을 사용해 여러 연관 엔티티를 묶어서 조회하도록 설정하는 어노테이션이다. 지정한 배치 사이즈만큼 데이터를 한 번에 가져오며, 이를 초과할 경우 다음 쿼리를 통해 동일한 방식으로 조회한다.

Fetch Join을 사용하기 어렵거나, 여러 연관 엔티티가 선택적으로 사용되는 경우에 유용하다.

@EntityGraph

조회 시 함께 가져올 연관 엔티티를 어노테이션으로 명시하여 필요한 연관 데이터만 즉시 로딩하도록 설정할 수 있다.

JPQL을 수정하지 않고, 메서드 단위로 Fetch 전략을 제어하고 싶을 때 사용한다.

2.2 나의 해결 방안

우선 하나의 쿼리로 가져오던 데이터를 두 개의 쿼리로 나눠서 가져오기로 했다.

장바구니 조회에서 실제로 필요한 데이터는 Cart가 아니라 CartItem이었고, Cart를 기준으로 fetch join 을 해서 DISTINCT를 통해 이를 다시 하나의 Cart 엔티티로 합치는 과정이 불필요하다고 생각했다.

그래서 Cart는 식별자 조회로 분리하고, CartItem을 루트로 필요한 연관 데이터만 fetch join 하는 두 단계 조회 방식을 선택했다.

*1. 조회 방식 선택 : Fetch join vs Projection *

장바구니 조회 API에서 N+1 문제를 해결하기 위해 Fetch Join과 Projection 중 어떤 방식을 사용할지 고민했다.

먼저 두 방식의 특징을 간단히 정리해보았다.

Projection

• 필요한 컬럼만 조회하므로 가져오는 데이터 양이 줄어든다.
• 엔티티를 생성하거나 영속성 컨텍스트에 등록하지 않기 때문에 엔티티 로딩 및 관리 비용이 발생하지 않는다.
• 이러한 특성으로 인해 대량 조회 시 메모리 및 CPU 사용량을 줄이는 데 효과적이다.

Fetch Join

• 연관된 엔티티를 한 번의 쿼리로 함께 조회할 수 있어 N+1 문제를 방지할 수 있다.
• 엔티티를 그대로 조회하므로 연관 관계 탐색, 옵션 조합, 금액 계산 등 도메인 로직을 자연스럽게 처리할 수 있다.
• 컬렉션 구조가 유지된 상태로 로딩되기 때문에 Projection처럼 결과를 다시 그룹핑하거나 가공할 필요가 없다.

두 방식을 비교해보았을 때,

장바구니 조회는 한 사용자 기준의 데이터로 규모가 크지 않고, 옵션과 같은 중첩된 연관 구조를 그대로 활용해야 하는 특성을 가지고 있었다.

이러한 구조를 Projection으로 조회할 경우 서비스 계층에서 결과를 다시 그룹핑하고 가공하는 추가 로직이 필요해져 오히려 코드 복잡도가 증가할 수 있다고 생각했다.

그리고 성능적 측면에서도 대량 데이터 조회에 효과 큰 Projection의 이점을 장바구니 조회 에선 효과가 크지 않을 것 같았다.

반면 Fetch Join을 사용하면 연관 데이터를 한 번에 조회하면서도 엔티티 구조를 그대로 활용할 수 있어 도메인 로직을 단순하게 유지하고, 유지보수성 측면에서도 유리하다고 생각했다.

따라서 이번 장바구니 조회 API에서는 Projection 이 아닌 Fetch Join 방식을 선택했다.

2. Fetch join 전략 활용

Fetch Join 을 활용하여 장바구니 조회에 필요한 연관 데이터를 한 번의 쿼리로 가져오도록 수정하였다.

장바구니 도메인에는 다음과 같은 다양한 상태가 존재한다.

• 장바구니는 존재하지만 상품이 없는 경우
• 상품은 존재하지만 옵션이 선택되지 않은 경우
• 옵션 조합이 부분적으로만 선택된 상태

이러한 특성상 INNER JOIN FETCH를 사용할 경우, 연관 데이터가 존재하지 않는 시점에서는 장바구니 또는 장바구니 아이템 자체가 조회되지 않는 문제가 발생할 수 있다고 생각했다.

그래서 연관 데이터의 존재 여부와 관계없이 장바구니 정보를 안정적으로 조회하기 위해 모든 연관 관계를 LEFT JOIN FETCH로 조회하는 방식을 선택하였다.

*3. 비효율적인 OneToOne 연관 관계 설계 개선 *

두 번째로 문제였던 부분은 실제로는 필요하지 않은 nutritionInfo 데이터가 조회되고 있다는 점이었다.

일반적으로 1:1 연관관계를 양방향으로 매핑하는 경우는 해당 데이터가 여러 곳에서 사용되거나, 추후 확장 가능성을 고려하는 경우가 많다.

하지만 현재 도메인 구조를 살펴보면 영양정보(nutritionInfo)를 조회하는 API는 상품 상세 조회 API 하나뿐이었다.

이 상태를 그대로 유지할 경우 N+1 문제를 해결하기 위해 장바구니 조회 API에서는 사용하지도 않는 영양정보까지 fetch join으로 함께 조회해야 하는 상황이 발생한다.

실제로 다른 곳에서 영양정보를 조회하는 경우가 없었기 때문에 양방향 연관관계를 제거하고 단방향 구조로 수정하였다.

결과적으로 상품 상세 조회 API에서는 영양정보를 별도의 쿼리로 조회하도록 분리했고

장바구니 조회 API에서는 영양정보를 fetch join 하지 않고도 필요한 데이터만 조회할 수 있도록 구조를 개선할 수 있었다.

3. 개선 결과

개선한 장바구니 조회 API(/users/cart)를 기준으로, 개선 전과 동일한 조건으로 상품을 장바구니에 담아 API를 호출해보았다.

그 결과, 상품 개수와 상관없이 총 2개의 쿼리만 수행되는 것을 확인할 수 있었다.

Hibernate: 
    select
        c1_0.cart_id 
    from
        cart c1_0 
    where
        c1_0.member_id=?
Hibernate: 
    select
        distinct ci1_0.cart_item_id,
        ci1_0.cart_id,
        co1_0.cart_item_id,
        co1_0.cart_option_id,
        co1_0.product_option_id,
        po1_0.product_option_id,
        os1_0.option_style_id,
        os1_0.extra_price,
        os1_0.option_name_id,
        os1_0.option_style,
        po1_0.product_id,
        ci1_0.price,
        ci1_0.product_id,
        p1_0.product_id,
        p1_0.category_id,
        p1_0.favorite_count,
        p1_0.price,
        p1_0.product_content,
        p1_0.product_name,
        p1_0.product_photo,
        p1_0.version,
        ci1_0.quantity 
    from
        cart_item ci1_0 
    left join
        product p1_0 
            on p1_0.product_id=ci1_0.product_id 
    left join
        cart_option co1_0 
            on ci1_0.cart_item_id=co1_0.cart_item_id 
    left join
        product_option po1_0 
            on po1_0.product_option_id=co1_0.product_option_id 
    left join
        option_style os1_0 
            on os1_0.option_style_id=po1_0.option_style_id 
    where
        ci1_0.cart_id=?

테스트 코드로 확인한 결과 역시 동일했다. 기존에는 상품 수에 따라 쿼리가 증가하던 구조였으나, 개선 이후에는 cart 조회 1회, cart_item 조회 1회로 항상 총 2개의 쿼리만 실행되도록 개선되었다.

또한 성능 측면에서도 눈에 띄는 개선이 있었다. P95 기준 응답 시간은 472ms → 42ms로 감소했다.

개선 전 후 비교표

4. 배운점

모니터링만으로는 모든 문제를 발견할 수 없다

Grafana 대시보드를 통해 요청 수가 늘어날수록 쿼리 수가 함께 증가하는 현상은 확인할 수 있었지만, 어떤 연관 관계에서, 어떤 코드 지점에서 쿼리가 발생하는지까지는 모니터링만으로 파악하기 어려웠다.

결국 실제 서비스 코드와 쿼리 로그, 테스트 코드를 함께 보면서 문제를 추적해야 N+1이 발생하는 정확한 원인을 이해할 수 있었다.

N+1 문제는 단순한 로딩 전략 문제가 아닐 수 있다

처음에는 fetch = LAZY / EAGER 설정만의 문제라고 생각했는데 분석해보니, 연관 관계를 어떻게 설계했는지 특히 @OneToOne 관계에서 FK의 위치와 양방향 매핑 여부에 따라서도 의도하지 않은 쿼리가 발생할 수 있다는 것을 알게 되었다.

즉, N+1 문제는 단순히 fetch 전략을 바꾸는 것으로 해결되지 않고, 엔티티 매핑 설계 자체를 다시 고민해야 하는 문제일 수도 있었다.

N+1 문제는 다양한 원인과 상황에서 발생하고 Fetch Join, @BatchSize, @EntityGraph 등 여러 해결 전략이 존재한다. 각 전략의 특성을 이해하고 상황에 맞게 선택하는 것이 중요함을 배웠다.

이번 포스팅에서는 로컬 캐시를 이용한 카테고리 캐시 적용으로 상품 조회 성능 개선 과정을 다뤄보려고 한다.

카페 주문 플랫폼에서 카테고리는 사용자가 상품을 조회할 때 가장 먼저 접하는 정보 중 하나로, 조회 빈도는 높지만 변경은 드문 데이터라는 특징을 가진다.

그럼에도 불구하고 사용자의 조회 요청마다 매번 DB를 조회하는 것이 과연 효율적인지 의문이 들었고, 이에 카테고리 조회에 캐싱을 적용했을 때 어떤 성능 개선 효과를 얻을 수 있는지 직접 확인해보기로 했다.

이번 글에서는 그 적용 과정과 결과를 정리해본다.

1. 문제 상황

위 이미지는 우리 프로젝트의 상품 목록 페이지이다.

해당 페이지에는 커피, 라떼, 주스&드링크, 바나치노&스무디, 티&에이드, 디저트, 세트메뉴, MD 총 8개의 카테고리가 노출된다.

카테고리는 관리자가 직접 수정하지 않는 이상 거의 변경되지 않으며, 대부분의 경우 동일한 데이터가 지속적으로 유지된다는 특징을 가진다.

하지만 현재 구조에서는 상품 목록을 조회할 때마다 상품 데이터와 카테고리를 조인하여 함께 조회하고 있다. 카테고리 정보가 항상 동일함에도 불구하고 매 요청마다 DB 접근과 조인 연산이 반복적으로 발생하는 구조인 것이다.

이러한 구조는 사용자 수가 적을 때는 크게 문제되지 않지만, 상품 목록처럼 다수의 사용자가 반복적으로 조회하는 화면일수록 불필요한 DB I/O와 조인 비용이 누적되어 서비스 부하로 이어질 수 있다.

이 문제를 해결하기 위해, 변경 빈도는 낮고 조회 빈도는 높은 카테고리 데이터에 로컬 캐시를 적용하는 방향을 고려하게 되었다.

2. 해결 과정

간단 개념 정리 : https://velog.io/@se0o_129/cache-strategy

2.1 캐시 선택

카테고리 데이터에는 로컬 캐시를 선택했다.

카테고리는 조회는 자주 되지만 변경은 거의 없는 데이터라서, 매번 글로벌 캐시를 거쳐 외부 서버와 통신하는 것은 불필요하다고 생각했다.

로컬 캐시는 애플리케이션 내부 메모리에 데이터를 저장하기 때문에 네트워크 비용 없이 바로 조회할 수 있고, 자주 바뀌지 않는 카테고리 데이터와도 잘 맞는다고 판단했다.

또한 카테고리는 실시간 반영이 꼭 필요한 데이터가 아니기 때문에, 로컬 캐시로 인한 데이터 불일치도 크게 문제가 되지 않을 것 같았다.

2.3 캐시 읽기 전략 선택

캐시 읽기 전략으로는 Cache-Aside를 선택했다.

우선 상품 목록을 조회할 때마다 해당 메서드를 호출하지만, 카테고리 변경은 관리자만 수행하며 거의 발생하지 않는다. 조회가 많을수록 캐시를 활용했을 때 성능 개선 효과가 크다.

또한 카테고리 변경이 있어도 수십 분~몇 시간 뒤에 반영되어도 서비스에는 큰 영향을 주지 않는다. 즉시 정합성이 필요한 데이터(재고, 잔액 등)는 캐시보다는 DB 직접 조회가 적합하고 생각했다.

2.2 캐시 만료 전략 선택

캐시 만료 방식으로는 TTL과 명시적 무효화를 병합하여 사용하는 전략을 선택했다.

카테고리 데이터는 특성상 변경 빈도가 매우 낮아 데이터 변경 시점에 캐시를 직접 제거하는 명시적 무효화만으로도 충분히 관리 가능하다.

하지만 모든 변경 상황에서 무효화를 완벽하게 보장하기는 어렵기 때문에 무효화가 누락되는 경우를 대비해 TTL을 보조 수단으로 함께 적용하기로 했다.

TTL은 24시간으로 설정하여 최악의 경우에도 캐시 데이터가 하루 이상 유지되지 않도록 하였고, 이를 통해 오래된 데이터가 지속적으로 제공되는 상황을 방지하고자 한다.

2.4 코드 개선

1. cacheManager 설정

TTL을 24시간으로 설정하여, 최악의 경우에도 캐시 데이터가 하루 이상 유지되지 않도록 관리했다.

용량 초과 시에는 Caffeine의 eviction 정책(LRU 기반)에 따라 오래 사용되지 않은 데이터가 자동으로 제거되도록 구성했다.

2. @Cacheable 적용

@Cacheable 어노테이션을 카테고리를 가져오는 메서드에 적용했다. 캐시 이름은 categories로 지정하여, 메서드 호출 결과를 이 캐시 영역에 저장하고 재사용할 수 있도록 설정했다.

3. 조인 제거 및 캐시 데이터 활용

기존에는 상품 조회 시 카테고리와 조인하여 데이터를 가져왔지만, 이제는 조인을 제거하고 캐시된 카테고리 데이터를 이용해 상품과 매치하는 방식으로 개선했다.

2.5 테스트 코드

피크타임에 여러 매장에서 동시 100명이 상품 목록을 조회하는 상황을 가정하여 테스트 코드를 구성했다.

캐시 적용 전과 후를 동일한 조건으로 측정하여 성능 차이를 비교하였다.

3. 결과

캐시 적용 전에는 평균 968ms가 소요되었지만, 캐시 적용 후에는 평균 300ms로 줄어드는 것을 확인할 수 있었다.

단일 조회 시에는 큰 병목이 발생하지 않지만, 동시 접속자가 늘어나면 DB 조회 부담은 급격히 증가하게 된다.

같은 조건에서도 캐시 유무에 따라 성능 차이가 뚜렷하게 발생함을 확인할 수 있었다.

4. 배운점

이번 캐시 적용을 통해 조회 성능을 개선할 수 있었지만, 카테고리 데이터가 8개로 매우 적고 조회 비용이 크지 않았다는 점을 고려하면 필수적인 최적화는 아니었다고 생각한다.

다만 조회 빈도가 높은 데이터에 대해 캐시를 적용하고, Cache-Aside 전략과 무효화 방식(TTL + 명시적 제거)을 직접 설계해본 경험은 의미 있었다.

실제 서비스에서는 데이터 규모와 트래픽을 기준으로 캐시 도입 여부를 판단하는 것이 중요하다는 점을 배울 수 있었다.

문제 발견 지금까지 개발하면서 조회용 메서드에는 습관적으로 @Transactional(readOnly = true)를 붙였다.

조회에 @Transactional(readOnly = true) 를 설정함으로써 성능상 이점을 얻을 수 있다고 알고있지만, 정작 내부에서 어떻게 동작하는지는 제대로 이해하지 못했다.

• 왜 성능이 좋아지는 걸까?
• 내부적으로 무슨 일이 일어나는 걸까?
• 실제로 얼마나 차이가 날까?

궁금증을 해결하기 위해 직접 테스트하고 내부 동작을 분석해보았다.

테스트 환경

• Spring Boot 3.x, JPA/Hibernate
• MySQL 8.0

한계

• 실제 운영 환경의 대량 데이터(수만~수십만 건)에서는 차이가 더 클 수 있다.

1. 문제 분석

1.1 현재 코드

@Transactional
public ProductDetailResponse findByProductId(Long productId) {
    Product product = productRepo.findProductById(productId);
    long favCount = favoriteRepo.countByProductId(productId);
    List<ProductOption> options = productOptRepo.findOptionByProductId(productId);

    return productConverter.toDetailDto(product, favCount, options);
}

이 메서드는 상품 상세 조회 API의 서비스 코드로, 기본값 트랜잭션을 사용한다.

Spring의 @Transactional 기본 설정은 readOnly = false 즉, “쓰기 가능 트랜잭션” 으로 인식된다.

비록 SQL은 SELECT만 실행되지만 JPA/Hibernate는 ‘언제든 엔티티가 변경될 수 있다’고 가정한다.

1.2 무엇이 문제일까 ?

JPA는 기본적으로 다음을 전제로 동작한다.

"트랜잭션 안에서 조회한 엔티티는 변경될 수도 있으니, 끝날 때 반드시 확인해야 한다."

그래서 읽기 전용이라고 명시하지 않으면, JPA는 단순 조회도 쓰기 가능 상태로 관리한다.

문제 1 : 영속성 컨텍스트 + 스냅샷 생성

조회 메서드를 호출했을 때 아래와 같은 과정은 거친다.

1. Product 엔티티 조회
2. 영속성 컨텍스트에 엔티티 저장
3. 동시에 스냅샷(초기 상태 복사본) 생성

[ 영속성 컨텍스트 ]

• Product 엔티티
• Product 스냅샷 (변경 감지용)

스냅샷은 변경 감지를 위해서만 존재하는데 조회만 하는데도 엔티티 개수만큼 메모리를 사용하게 되고, 대량 조회시 메모리 압박이 증가하게 된다. 읽기 전용 트랜잭션에서는 전혀 필요없는 작업이다.

문제 2 : 더티 체킹(변경 감지) 수행

트랜잭션 종료시 Hibernate는

1. 현재 엔티티 상태
2. 스냅샷 상태

위 두 가지의 모든 필드를 비교한다.

for (엔티티의 모든 필드) {
    현재값 == 스냅샷값 ?
}

실제로는 변경한 적 없는 조회 전용 메서드에서 의미 없는 객체 필드 비교와 엔티티 수 * 필드 수 만큰 CPU를 사용하게 되어 낭비가 발생한다

문제 3 : 불필요한 flush 가능성

flush란 영속성 컨텍스트 내용을 DB와 동기화하는 작업을 말한다.

보통 트랜잭션 커밋 시 JPQL 실행 전 자동 발생 가능하다.

@Transactional
public List<Product> findByProductId(...) {
    // 다른 로직이 추가되면?
}

의도치 않게 엔티티 상태가 변경되면 flush 발생 → UPDATE 쿼리 실행할 수 있는 상태가 되고 조회 메서드인데 DB 변경되는 사고가 날 수 있다.

2. 해결 방법: readOnly = true

2.1 개선 코드

@Transactional(readOnly = true)
public ProductDetailResponse findByProductIdReadOnly(Long productId) {
    Product product = productRepo.findProductById(productId);
    long favCount = favoriteRepo.countByProductId(productId);
    List<ProductOption> options = productOptRepo.findOptionByProductId(productId);

    return productConverter.toDetailDto(product, favCount, options);
}

2.2 readOnly = true가 하는 일

(1) 스냅샷 저장 안 함

일반 트랜잭션에서는 조회한 엔티티의 원본 상태(스냅샷)을 영속성 컨텍스트에 저장하지만 readOnly = true에서는 스냅샷을 생성하지 않는다 (메모리 사용량 감소)

(2) 변경 감지(더티 체킹) 안 함

일반 트랜잭션 종료 시 현재 상태 vs 스냅샷 비교하여 변경 여부 판단하지만 readOnly = true에서는 비교 대상 자체가 없다. (CPU 사용 감소)

(3) 플러시 모드 변경

readOnly = true 적용 시 Hibernate FlushMode가 MANUAL 로 변경하여 트랜잭션 종료 시 자동 flush 발생하지 않는다.

(4) 데이터베이스 힌트 (DB에 따라)

@Transactional(readOnly = true)가 선언되면 Spring은 JDBC Connection에 읽기 전용(read-only) 힌트를 전달한다.

이 힌트는

“이 트랜잭션은 데이터를 변경하지 않는다” 는 의미를 DB 및 인프라 계층에 명시적으로 알리는 역할을 한다.

레플리케이션 환경에서의 동작

DB가 다음과 같은 레플리케이션 구조로 구성된 경우:

Master DB  →  Replica DB (복제본)
   (쓰기)         (읽기)

• Master DB : INSERT / UPDATE / DELETE 담당
• Replica DB : SELECT 전용 조회 담당

읽기 전용 힌트가 전달되면, DataSource 라우팅 설정이나 미들웨어(MySQL Router, Aurora Reader Endpoint 등)에 따라 해당 트랜잭션을 Read Replica로 라우팅할 수 있다.

단, readOnly = true만으로 자동 라우팅이 되는 것은 아니며 실제 라우팅은 인프라 및 애플리케이션 설정에 따라 결정된다.

결과적으로 조회 트래픽이 Replica로 분산됨으로써, Master DB 부하 감소하고 읽기 요청이 많은 서비스에서 전체 처리량 및 안정성 향상된다.

3. 성능 테스트

3.1 테스트 시나리오

Product 10건을 기준으로 연관된 엔티티인 Hashtag 55건, NutritionInfo 10건, ProductOption 179건이 함께 조회되어 총 254개의 데이터가 로딩되는 상황을 가정하였다.

동일한 조회 조건에서 @Transactional(readOnly = false) 와 @Transactional(readOnly = true) 를 각각 10회 측정하여 평균 수행 시간을 비교하였다.

테스트 코드와 레파지토리 메서드는 아래와 같다. 테스트 코드는 @Transactional의 readOnly true와 false를 적용한 메서드 사용외에 모두 동일하다.

3.2 측정 결과

소량 데이터 조회라 큰 변화는 없었지만 readOnly=true를 적용했을 때 시간이 단축된 걸 확인해볼 수 있었다.

이는 조회에는 불필요한 스냅샷 저장과 더티 채킹 과정을 생략함으로써 나올 수 있는 결과이다.

4. 주의사항

4.1 읽기 전용 트랜잭션에서 수정하면 무슨 일이 생길까 ?

@Transactional(readOnly = true)
public void updateProduct(Long productId) {
    Product product = productRepository.findById(productId);
    product.setName("변경");  // 변경 감지 안 됨
    // DB에 반영되지 않음
}

겉보기에는 문제 없는 코드처럼 보이지만 readOnly = true 트랜잭션에서는 엔티티 스냅샷을 만들지 않고, Dirty Checking(변경 감지)을 하지 않기 때문에 엔티티 값은 바뀐 것처럼 보이지만 트랜잭션 종료 시 UPDATE SQL이 실행되지 않는다.

그렇기 때문에 readOnly 트랜잭션에서는 절대로 엔티티 상태를 변경하면 안 된다.

4.2 언제 사용해야 할까 ?

사용해야 할 때 :

• 단순 조회 API
• 리포트 생성
• 통계 조회
• 검색 기능

사용하면 안 될 때 :

• 데이터 수정이 필요한 경우
• CUD(Create, Update, Delete) 작업

5. 적용 팁

5.1 Service 계층 패턴

@Service
@Transactional(readOnly = true)  // 클래스 레벨 기본값
public class ProductService {

    // 조회 - readOnly 상속
    public List<Product> findAll() { ... }

    // 수정 - 메서드에서 오버라이드
    @Transactional  // readOnly = false
    public void updateProduct(Long id, String name) { ... }
}

조회 메서드가 대부분인 서비스의 경우, 클래스 레벨에 @Transactional(readOnly = true)를 두고 변경이 필요한 메서드에서만 트랜잭션을 오버라이드하는 것이 가장 자연스럽다.

5.2 복제(Replication) 환경

Master/Replica 구조를 사용하는 경우, readOnly 트랜잭션은 조회 요청을 읽기 전용 DB로 분리하기 위한 기준으로 활용될 수 있다.

# application.yml
spring:
  datasource:
    hikari:
      data-source-properties:
        readOnlyRoutingDataSource: true

그러나 실제 라우팅 동작 여부는 DataSource 구성 및 인프라 설정에 따라 달라진다.

6. 배운 점

이번 테스트로 얻은 성능 차이는 크지 않았다.

하지만 막연하게 사용하던 readOnly = true 설정이 단순한 성능 수치 이상의 의미를 가지며 내부 동작을 제어하는데 큰 차이를 만들어냄을 확인할 수 있었다.

조회 로직을 쓰기 가능 트랜잭션으로 조회한다는 것은 변경이 필요하지 않음에도 불구하고 변경에 대비한 불필요한 과정을 거침으로써 불필요한 메모리 사용과 비용을 감수할 수 있었다는 것을 알게 되었다.

이번 포스팅을 통해, 어떤 기능을 사용할 때 어떤 과정을 통해 이루어지고 어떤 이점이 있어 사용하는지 이해한 상태에서 사용하는 것이 중요하는 점을 다시 한번 느낀다.

끊임없이 의문을 던지면서 의식하고 공부하는 것이 중요하다고 느꼈다.

카페 주문 플랫폼 장바구니 비우기 기능을 테스트하던 중, 로그에서 이상한 점을 발견했다.

단 10개의 상품을 삭제하는데 DELETE 쿼리가 11번이나 실행되고 있었다.

처음에는 단순히 비효율적인 구현 때문이라고 생각했다. 하지만 원인을 하나씩 살펴보면서, JPA에서의 삭제 방식과 트랜잭션 처리에 대해 다시 고민하게 되었다.

이 글에서는 원인 분석과 여러 삭제 방식(Bulk Delete, Cascade 등)을 비교하며 직접 측정해본 과정을 정리해보려고 한다.

1. 문제 케이스 : 트랜잭션 범위 내 반복 쿼리

문제 상황 분석

현재 ERD 구조

장바구니 관련 테이블은 다음과 같이 구성되어 있다:

• cart: 회원별 장바구니 정보를 저장하는 테이블
• cart_item: 장바구니에 담긴 상품 정보를 저장하는 테이블
• cart_option: 각 상품의 옵션 정보를 저장하는 테이블

문제 코드

사용자가 장바구니 "전체 비우기" 버튼을 클릭했을 때 실행되는 메서드이다.

@Transactional
public void clearCart(Long memberId, Long cartId) {
    List<CartItem> items = cartItemRepository.findByCartId(cartId);

    for (CartItem ci : items) {
        cartOptionRepository.deleteByCartItemId(ci.getId()); 
        // 반복문 안에서 매번 개별 DELETE 실행
    }

    cartItemRepository.deleteAllInBatch(items);
}

문제점 : 장바구니 상품의 옵션을 삭제할 때, 반복문 안에서 각 CartItem에 대해 매번 개별 DELETE 쿼리가 실행되고 있다.

실행된 쿼리 로그 분석

-- 1. 장바구니 조회
SELECT c1_0.cart_id, c1_0.member_id 
FROM cart c1_0 
WHERE c1_0.cart_id=?

-- 2. 장바구니 상품 조회
SELECT ci1_0.cart_item_id, ci1_0.cart_id, ci1_0.price, ci1_0.product_id, ci1_0.quantity 
FROM cart_item ci1_0 
JOIN cart c1_0 ON c1_0.cart_id=ci1_0.cart_id 
WHERE c1_0.cart_id=?

-- 3. 장바구니 옵션 개별 삭제 (10번 반복)
DELETE FROM cart_option WHERE cart_item_id=?
DELETE FROM cart_option WHERE cart_item_id=?
DELETE FROM cart_option WHERE cart_item_id=?
DELETE FROM cart_option WHERE cart_item_id=?
DELETE FROM cart_option WHERE cart_item_id=?
DELETE FROM cart_option WHERE cart_item_id=?
DELETE FROM cart_option WHERE cart_item_id=?
DELETE FROM cart_option WHERE cart_item_id=?
DELETE FROM cart_option WHERE cart_item_id=?
DELETE FROM cart_option WHERE cart_item_id=?

-- 4. 장바구니 상품 일괄 삭제
DELETE FROM cart_item 
WHERE cart_item_id IN (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)

쿼리 실행 결과 :

• CartOption 개별 삭제: 10번
• CartItem 일괄 삭제: 1번
• 총 DELETE 쿼리: 11번

장바구니 상품이 10개일 때, DELETE 쿼리가 11번 실행되는 비효율이 발생했다.

트랜잭션 관점의 문제

불필요한 네트워크 왕복으로 인한 트랜잭션 보유 시간 과다

• 트랜잭션은 DB 커넥션을 점유하는데 트랜잭션 실행 시간이 길어지면 DB 커넥션 점유 시간이 길어진다.
  • 커넥션 풀의 크기가 제한적이므로, 트랜잭션이 길어지면 다른 트랜잭션들의 대기 시간도 길어지게 된다.
  • 대용량 트래픽이 몰리는 상황에서 1번의 쿼리로 수행할 수 있는 작업을 11번의 쿼리로 수행하는 것은 매우 비효율적이다.

2. 해결 방법

2.1 벌크 삭제 (Bulk Delete)

반복문으로 개별 DELETE를 수행할 때 발생하는 N+1 삭제 문제는 벌크 삭제를 통해 해결할 수 있다.

벌크 삭제는 여러 개의 데이터를 한 번의 쿼리로 한꺼번에 삭제하는 방식을 말한다.

영속성 컨텍스트를 거치는 단계를 모두 건너뛰고 데이터베이스에 직접 delete sql을 실행하기 때문에 빠르다.

벌크 삭제 방식에는 두 가지 방법이 있다.

1. deleteAllInBatch() 메서드로 삭제 수행

deleteAllInBatch는 Spring Data JPA가 기본 제공하는 메서드이다.

먼저 엔티티를 조회하고 엔티티 컬렉션을 받아서 IN절로 삭제를 수행한다. (SELECT + DELETE, 총 두 번의 쿼리)

SELECT * FROM cart_item WHERE cart_id = ?;  -- 먼저 조회
DELETE FROM cart_item WHERE cart_item_id IN (?, ?, ...);  -- 그 다음 삭제

** 2. Repository에 벌크 삭제 쿼리 추가 (@Query + @Modifying)**

@Query + @Modifying 방식은 조회 없이 바로 DELETE 쿼리를 실행하는 특징이 있다.

영속성 컨텍스트를 거치지 않고 SQL을 직접 실행하여, 엔티티 로딩 없고 메모리 사용 최소화할 수 있는 방식이다.

@Modifying
@Query("DELETE FROM CartOption co WHERE co.cartItem.cart.id = :cartId")
void deleteByCartId(@Param("cartId") Long cartId);

deleteAllInBatch()와 비교했을 때 조회 없이 바로 삭제가 가능하다는 장점이 있지만, Repository에 쿼리를 직접 작성한 메서드를 추가해야 한다.

DELETE FROM cart_item WHERE cart_id = ?;  -- 바로 삭제 (조회 없음)

2.2 Cascade 설정

Cascade는 부모 엔티티의 작업이 자식의 엔티티에게 전파되는 기능을 말한다.

부모를 삭제하면 자식도 자동으로 삭제돼서, 외래키 제약 조건 문제를 자동으로 해결해준다.

@OneToMany(mappedBy = "cartItem", cascade = CascadeType.ALL)  // 모든 작업 전파
private List<CartOption> options = new ArrayList<>();

3. 성능 테스트

3.1 테스트 시나리오

한 명의 사용자가 3개의 옵션이 적용된 10개의 상품이 들어있는 장바구니를 비우는 상황을 가정했다.

개선 전 방식과 3가지 개선 방식(벌크 삭제 2가지, Cascade)을 비교하여 각각 10회씩 반복 측정한 후 평균 실행 시간을 비교했다.

3.2 테스트 환경

• 테스트 사용자 : memberId = 1
• 상품 데이터 : 기존 DB의 186개의 상품 중 옵션이 3개 이상인 상품 10개 선택
• 장바구니 구성
  • CartItem : 10개
  • CartOption : 30개 (상품당 3개씩)
• *반복 측정 *: 각 방식당 10회

각 측정마다 entityManager.clear()로 캐시를 초기화하여 정확한 성능을 측정했다.

3.3 개선 전 : 반복문 + deleteAllInBatch

반복문으로 CartOption을 개별 삭제한 후, CartItem을 일괄 삭제하는 기존 방식에 대한 메서드이다.

총 11번의 DELETE 쿼리 수행으로 매우 비효율적으로 장바구니를 비우고 있다.

3.4 벌크 삭제 적용 : @Query+@Modifying

@Query+@Modifying 방식은 JPQL로 직접 작성한 벌크 삭제 쿼리를 사용한다.

조회 없이 바로 벌크 삭제하고 쿼리 개수가 가장 적게 발생한 방식이다.

개선 전 대비 367ms 빠른 방식이라는 것을 알 수 있었다. *(13.5% 향상) *

3.5 벌크 삭제 적용 : deleteAllInBatch

deleteAllInBatch는 엔티티를 먼저 조회하고 조회한 엔티티들을 메모리에 로딩하여 일괄 삭제하는 방식이다.

CartOption과 CartItem 엔티티를 각각 한번씩 조회하여 두 번의 SELECT문과 두 번의 DELETE문이 발생하였다.

네가지 방식 중 가장 짧은 평균 실행시간을 보였고, 개선 전 대비 446ms 빠른 방식이었다. (16.8%)

@Query + @Modifying 방식보다는 31ms 빠르게 측정되었다.

3.6 cascade = CascadeType.ALL

CartItem의 options를 cascadeType.ALL을 적용하여 JPA가 연관관계에 따라 자동 삭제하도록 하였다.

N+1 문제로 쿼리 많이 발생하지만, 그럼에도 개선 전과 비교했을 때 75ms 더 빨랐다는 걸 알 수 있었다. (2.8% 향상)

3.7 성능 테스트 종합 분석

이론적으로 @Query + @Modifying 방식이 조회없이 바로 삭제하기 때문에 가장 빠를 것으로 예상했다.

하지만 예상과 달리 실제 테스트 결과는 deleteAllInBatch 방식이 가장 빠른 성능을 보였다.

왜 예상과 다를까 ?

내가 실행한 테스트에서는 소량 데이터(상품 10개, 옵션 30개)가 이러한 결과를 보인 가장 큰 요인으로 예상된다.

deleteAllInBatch 는 먼저 엔티티를 조회한 후 삭제하는 2단계 과정을 거친다.

List options = cartOptionRepository.findByCartId(cartId);
// 30개 엔티티 조회

DELETE FROM cart_option 
WHERE cart_option_id IN (1, 2, 3, 4, 5, ..., 30); // IN절로 삭제

MySQL은 이 IN 절을 처리할 때 매우 효율적으로 동작한다.

1. IN 절의 값들을 정렬
2. 인덱스를 한 번만 순차 스캔하여 해당 값들을 찾음
3. 실제 삭제

이러한 과정을 거쳐 삭제 처리가 완료된다.

반면 @Query + @Modifying 방식은 조회 없이 바로 삭제하지만, 서브쿼리를 실행해야 한다.

DELETE FROM cart_option 
WHERE cart_item_id IN (
    SELECT cart_item_id FROM cart_item WHERE cart_id = 1
);

MySQL이 위 쿼리를 처리하는 방법은 다음과 같다.

1. 서브쿼리 실행

SELECT cart_item_id FROM cart_item WHERE cart_id = 1
→ 결과: [101, 102, 103, 104, 105, 106, 107, 108, 109, 110]


이 과정에서 아래와 같은 과정이 이루어진다.
- cart_item 테이블 스캔
- WHERE 조건 평가
- 결과 10개 추출
- 임시 메모리 영역에 저장

2. 임시 테이블 생성 MySQL은 서브쿼리 결과를 임시 테이블(derived table)에 저장하고, 메모리 또는 디스크에 임시 공간 할당한다.

3. 메인 쿼리와 조인 cart_option 테이블과 임시 테이블을 조인한다.

   조인 조건 : cart_option.cart_item_id = 임시테이블.cart_item_id

4. 삭제 실행 : 조인 결과로 매칭된 행들을 삭제한다.

이처럼 @Query + @Modifying 방식은 서브쿼리 실행, 임시 테이블 생성, 조인 처리 등의 구조적 오버헤드가 발생한다.

이러한 오버헤드는 데이터 개수와 무관하게 항상 발생하는 준비 작업이다.

소량 데이터에서는 실제 데이터를 삭제하는 시간보다 이런 준비 작업 시간이 더 오래 걸려서 비효율적이다.

deleteAllInBatch의 IN 절 방식은 임시 테이블 생성 X, 서브쿼리 실행 X, 단순 인덱스 스캔으로 빠른 처리하기 때문에

30개 정도의 소량 데이터에서는 조회 비용을 감안하더라도, MySQL의 IN 절 최적화가 매우 효과적으로 작동하여 서브쿼리 방식보다 빠른 성능을 보인다.

테스트 결과의 한계

이번 테스트는 소량 데이터(상품 10개 + 옵션 30개)로만 진행했다.

deleteAllInBatch가 가장 빨랐지만, 대량 데이터에서는 결과가 달라질 수 있다.

deleteAllInBatch는 데이터가 적을 땐 부담이 없지만 1000개가 되면 1000개 객체를 메모리에 로딩하고, 긴 IN 절 (1000개) 파싱해야 하기 때문에 부담이 크다.

반면 @Query + @Modifying 는 조회 없이 서브쿼리로 바로 삭제하므로 데이터가 많아져도 안정적일 것으로 예상된다.

4. 배운점

이론대로만 생각하면 놓치는 것들이 있다

처음에는 @Query + @Modifying 방식이 쿼리를 한 번만 실행하니 당연히 가장 빠를 것이라고 생각했다.

하지만 실제로 테스트해보니 deleteAllInBatch가 더 빠른 결과가 나와 예상과 달라서 꽤 당황했다.

이 경험을 통해 이론에서 배운 내용만으로 성능을 판단하는 데에는 한계가 있다는 것을 느꼈다. 특히 데이터 개수나 실행 상황에 따라 결과가 달라질 수 있다는 점을 직접 확인할 수 있었다.

데이터가 많지 않은 경우에는 deleteAllInBatch 방식이 더 효율적으로 동작했고

데이터가 많아질 경우에는 다른 방식이 더 적합할 수도 있다는 가능성을 알게 되었다

앞으로는 “이 방식이 더 좋다”라고 단정하기보다, 지금 상황에서는 왜 이 방식이 맞는지 고민해봐야겠다고 느꼈다.

성능은 생각이 아니라 직접 재봐야 알 수 있다

기존 코드에서 DELETE 쿼리가 여러 번 실행되는 것을 보고 “쿼리가 많으니까 무조건 느릴 것 같다”라고 생각했다.

그래서 쿼리 수를 줄이는 데 집중했는데, 막상 측정해보니 쿼리 수가 더 많았던 Cascade 방식이 오히려 전체 실행 시간은 조금 더 빠른 결과를 보였다.

이 결과를 통해 쿼리 개수가 적다고 해서 항상 빠른 것은 아니라는 점을 배웠다. 각 쿼리가 어떤 방식으로 실행되는지, 그 과정에서 어떤 비용이 드는지도 함께 봐야 한다는 것을 알게 되었다.

앞으로는 추측으로 결론을 내리기보다, 반드시 로그와 측정 결과를 먼저 확인하는 습관을 들여야겠다고 느꼈다.

이번 글에서는 카페 주문 시스템을 개발하며 경험한 동시성 이슈 중 하나인 즐겨찾기 동시성 문제에 대한 원인과 해결 과정을 정리해보고자 한다.

1. 문제 발견

프로젝트에서 즐겨찾기 기능을 구현하고 로컬에서 테스트할 때는 문제가 없었다. 클릭하면 즐겨찾기가 잘 추가되고, 카운트도 정상적으로 올라는데

하지만 출근 시간대에 많은 사람들이 카페를 정말 많이 이용하는데 "실제로 피크타임에 여러 사용자가 하나의 상품에 대해서 동시에 즐겨찾기를 하면 어떻게 될까?"라는 의문이 들었다.

실제 서비스 환경에서는 다수의 사용자가 동시에 같은 기능을 사용할 수 있다.

특히 프로모션이나 인기 상품의 경우, 순간적으로 집중된 트래픽이 발생할 수 있다고 생각한다.

이런 상황을 시뮬레이션하기 위해 1000명의 동시 요청을 테스트 시나리오로 설정했다.

(실제로는 100명만 동시 접속해도 충분히 문제가 발생할 수 있지만, 여유를 두고 더 극단적인 상황을 가정했다.)

2. 원인 분석

Race Condition이란?

여러 사용자가 동시에 같은 데이터를 읽고 쓸 때, 실행 순서에 따라 결과가 달라지는 상황을 말한다.

즐겨찾기 카운트를 증가시키는 것을 아래 3단계로 나뉜다.

1. 현재 값 읽기 (Read)
2. 1 증가시키기 (Modify)
3. 증가한 값 저장하기 (Write)

문제는 여러 사용자가 동시에 이 과정을 실행할 때 발생한다.

사용자 A : count = 5 읽기 → 6으로 변경 → 저장
사용자 B : count = 5 읽기 → 6으로 변경 → 저장
                   ↑ 둘 다 5 를 읽어버린다 !

두 사용자가 모두 "5"_를 읽고 **"6"_**으로 저장하면서, 실제로는 2번 증가해야 하는데 1번만 증가하게 된다.

이것을 바로 Race Condition(경쟁 상태)라고 말한다.

Race Condition의 발생 조건은 아래와 같다.

1. 공유 자원 (Shared Resource)
여러 스레드가 접근하는 데이터 (예: DB의 count)

2. 동시 접근 (Concurrent Access)
여러 스레드가 동시에 접근

3. 최소 하나의 쓰기 (At Least One Write)
읽기만 하면 문제 없음, 쓰기가 있어야 문제 발생

이를 해결하기 위해 낙관적 락 / 비관적 락 / 원자적 UPDATE 방식을 비교하여 최선의 해결 방안을 찾아보려고 한다.

3. 테스트 환경

개발 환경

• Java: 21 (LTS)
• Spring Boot: 3.2.x
• ORM: Spring Data JPA (Hibernate 6.x)
• Database: MySQL 8.0 (로컬 환경)

테스트 구성

• 테스트 프레임워크 : JUnit 5
• 동시성 제어 : CountDownLatch + ExecutorService
• 시나리오 : 1000명이 동시에 아이스 아메리카노 즐겨찾기 추가
• Thread Pool 크기 : 100개 스레드
• 반복 횟수 : 각 테스트 1회 실행

테스트 코드 전체적인 공통 틀

private static final int THREAD_COUNT = 1000;
private static final int POOL_SIZE = 1000;

@Test
void 낙관적_락_동시성_테스트() {
    ExecutorService executorService = Executors.newFixedThreadPool(POOL_SIZE);
    CountDownLatch latch = new CountDownLatch(THREAD_COUNT);

    long productId = 1; // 아이스아메리카노에 대한 product id

    for (int i = 0; i < THREAD_COUNT; i++) {
        final long memberId = i + 1L; // 1 ~ 1000번 memberId를 사용자
        executorService.execute(() -> {
            try {
                favoriteService.addFavorite(1L);
            } catch (Exception e) {

            } finally {
                latch.countDown();
            }
        });
    }

    latch.await();
}

즐겨찾기 count를 해야하는 product 엔티티

public class Product {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    @Column(name = "product_id")
    private Long id;

    @Column(name = "product_name")
    private String productName;

    @Column(name = "product_content")
    private String productContent;

    @Column(name = "product_photo")
    private String productPhoto;

    private Integer price;

    @Column(name = "favorite_count", nullable = false, columnDefinition = "bigint default 0")
    @Builder.Default
    private Long favoriteCount = 0L;

    @Column(name = "version", columnDefinition = "bigint default 0")
    private Long version = 0L;

    // 1:N
    @OneToMany(mappedBy = "product", cascade = CascadeType.ALL, orphanRemoval = true)
    private List<ProductOption> options = new ArrayList<>();

    // 1:1
    @OneToOne(mappedBy = "product", cascade = CascadeType.ALL, orphanRemoval = true)
    private NutritionInfo nutritionInfo;

    // 1:N
    @OneToMany(mappedBy = "product", cascade = CascadeType.ALL, orphanRemoval = true)
    private Set<Allergen> allergens = new HashSet<>();

    // 1:N - Category
    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "category_id", nullable = false)
    private Category category;

    // 1:N 관계 매핑 (즐겨찾기만)
    @OneToMany(mappedBy = "product", cascade = CascadeType.ALL, fetch = FetchType.LAZY)
    private List<Favorite> favorites = new ArrayList<>();

    // 1:N - Hashtag
    @OneToMany(mappedBy = "product", cascade = CascadeType.ALL, orphanRemoval = true)
    private Set<Hashtag> hashtags = new HashSet<>();

    public void increaseFavoriteCount() {
        if(this.favoriteCount == null) {
            this.favoriteCount = 1L;
        } else {
            this.favoriteCount++;
        }
    }

    public void decreaseFavoriteCount() {
        if(favoriteCount > 0) {
            this.favoriteCount--;
        }
    }
}

4. 해결 방법 탐색

위에서 말했던 세 가지 방안을 테스트하기 앞서 우선 락 없이 1000명이 동시에 즐겨찾기 하는 상황을 테스트해보았다.

4.1 락 없음 (문제 상황)

Respository Service

이 코드는 3단계로 동작한다 :

1. Product 조회 (favoriteCount 읽기)
2. Favorite 생성 및 저장
3. Product의 favoriteCount 증가 및 저장

Race Condition 발생 시나리오 :

초기 상태 : Product의 favoriteCount = 100

[Thread A]                          [Thread B]
1. count = 100 읽기                 
                                    1. count = 100 읽기  ← 동시에 같은 값!
2. Favorite 저장                    
                                    2. Favorite 저장
3. count = 101로 증가               
                                    3. count = 101로 증가 ← 둘 다 101!
4. count = 101 저장                 
                                    4. count = 101 저장   ← 덮어씀!

결과 : favoriteCount = 101 (기대값: 102)

두 사용자가 모두 즐겨찾기를 추가했지만, 카운트는 "1"만 증가한다 !

실제로 1~1000번의 memberId를 돌았는데도 불구하고 처참한 테스트 결과가 나왔다.

테스트 결과 : 1540ms, 실패율 5.7% 1000개의 요청 모두 성공적으로 요청되었지만 실제로 DB에 반영된 즐겨찾기는 265개 밖에 되지 않았다. 1000명이 즐겨찾기를 시도했을 때 265명을 제외한 나머지 사람들은 즐겨찾기에 실패했다는 것이다. 실제 서비스에서는 절대 이런 일이 일어나선 안된다는 것을 체감했다.

4.2 낙관적 락 (@Version)

데이터 충돌이 자주 발생하지 않을 것이라 낙관적으로 가정하고, 충돌이 발생하면 그때 충돌을 처리하는 방식을 말한다.

장점

• 동시에 여러 트랜잭션이 데이터에 접근하고 변경할 수 있기 때문에 동시성이 높아지고, 시스템의 처리량이 향상된다. (반드시 되는 건 아님)
• 락을 사용하지 않기 때문에 다른 트랜잭션에서 데이터를 읽을 수 있다.
• 충돌이 발생했을 때 롤백을 피하고 충돌을 해결할 수 있는 기회를 제공한다.

단점

• 충돌이 발생할 경우 롤백이 발생할 수 있다. 다른 트랜잭션에서 변경한 데이터와 충돌이 발생하면 예외가 발생하고 롤백 발생

Entity 낙관적 락을 수행하기 위해 JPA에서 제공하는 @Version 애너테이션을 사용한 Version 컬럼을 추가해주었다.

Respository product 엔티티를 조회하는 쿼리에는 @Lock 애너테이션을 이용하여 Entity 수정시에만 발생하는 낙관적 잠금이 읽기 시에도 발생하도록 설정하였다. 이는 읽기시에도 버전을 체크하고 트랜잭션이 종료될 때까지 다른 트랜잭션에서 변경하지 않음을 보장한다. Service 낙관적 락은 비관적 락과 달리 충돌에 낙관적이기 때문에 충돌 했을 때 재시도할 수 있도록 재시도 로직을 구현하였다. 초반엔 최대 재시도 횟수를 작성하지 않았었는데 제한을 두지 않으면 테스트가 무한 루프에 빠져 종료되지 않는 문제가 발생했다. 그래서 제한 횟수를 정하기로 하였고, 약간 여유를 두고 10번으로 지정하였다. 10번을 재시도했는데도 불구하고 최대 재시도 횟수를 초과하여 실패하는 경우가 발생했다.

테스트 결과: 3781ms 낙관적 락 적용 시, 비동기 환경에서도 충돌 빈도가 감소하며 전반적인 성공률이 향상되었다. 다만 일부 요청에서는 여전히 버전 충돌이 발생했으며, 재시도 횟수를 늘릴 경우 100% 성공을 달성할 수 있었지만, 운영 환경에서의 성능 부담을 고려해 최대 재시도 횟수는 10회로 제한하였다. 10번의 재시도에도 실패하는 테스트 결과를 보니 충돌이 너무 심한 상황에서는 낙관적 락의 한계를 보였다.

4.3 비관적 락 (PESSIMISTIC_WRITE)

동시에 누가 수정할 것이라 비관적으로 가정하고, 데이터를 읽는 시점 부터 다른 트랜잭션이 건들지 못하도록 잠그는 방식이다. 이로 인해 데이터를 수정할 땐 다른 트랜잭션이 접근하여 읽거나 수정할 수 없다.

장점

• 데이터를 접근하는 동안 다른 트랜잭션이 접근하지 못하도록 제어할 수 있다. 데이터의 일관성과 동시성을 보장할 수 있다.
• 데이터에 대한 잠금을 설정하여 다른 트랜잭션의 변경을 차단함으로써 충돌을 방지할 수 있다.

단점

• 동시성이 낮아진다. 데이터를 잠그기 때문에 다른 트랜잭션에서 해당 데이터에 접근하거나 변경하는 것이 제한된다.
• 락을 사용하므로 다른 트랜잭션이 해당 데이터를 읽을 수 없다.
• 잠금을 설정한 상태에서 해당 트랜잭션의 작업이 오래 걸리면 다른 트랜잭션들이 대기하게 되어 시스템 성능이 저하될 수 있다.

Repository 비관적 락의 LockModeType은 다른 트랜잭션이 읽고 쓰는 동안 읽는 걸 막기 위해 PESSIMISTIC_WRITE로 걸었다. ** Service** 서비스 코드는 락 없이 테스트 했을 때와 동일하게 작성하였다.

테스트 결과: 2274ms, 성공률 100% 성공률 100%를 확인했고 낙관적 락에 비해 실행시간이 적게 걸렸지만 여전히 느린 속도였다.

4.4 원자적 UPDATE

여러 스레드나 트랜잭션이 동시에 같은 데이터를 수정하더라도 데이터가 꼬이지 않도록 보장하는 갱신 방식이다.

읽기-수정-쓰기를 데이터베이스 레벨에서 한 번에 처리하여 중간에 다른 작업이 끼어들 수 없다.

Respository JPA에서는 @Modifying과 JPQL UPDATE를 사용해 한 번의 SQL로 수정 연산을 처리할 수 있다. 이 방식으로 원자적 UPDATE 방식을 수행했다.

테스트 결과: 954ms, 성공률 100% 테스트 결과 모든 테스트 케이스 중에서 가장 짧은 실행시간을 보였고 100% 성공률을 확인했다.

5. 성능 비교

6. 최종 선택과 이유

세 가지 동시성 제어 방식을 비교 분석한 결과, 최종적으로 원자적 UPDATE 방식을 선택했다.

선택 근거

1. 단순성과 효율성의 균형

   • 별도의 버전 관리 필드나 락 획득 로직이 필요 없어 코드가 간결하다.
   • 데이터베이스 수준에서 원자성이 보장되므로 추가적인 동시성 제어 로직이 불필요하다.

2. 성능상의 이점

   • 낙관적 락처럼 재시도 로직이 필요 없어 불필요한 오버헤드가 없다.
   • 비관적 락보다 락 대기 시간이 짧아 처리량이 높다.
   • 단일 쿼리로 조회와 업데이트를 동시에 처리할 수 있다.

3. 좋아요 기능의 특성에 적합

   • 좋아요 카운트는 단순 증감 연산이므로 복잡한 비즈니스 로직이 필요 없다.
   • 높은 동시성 환경에서도 안정적으로 동작한다.
   • 일시적인 정확도보다 최종적인 일관성이 더 중요한 요구사항에 부합한다.

7. 배운 점

이번에 다양한 락 전략을 직접 테스트해보면서, 이론으로만 알고 있던 개념들이 실제 환경에서 어떻게 다른 결과를 만드는지 체감할 수 있었다.

특히 세 가지 방식을 동일한 조건에서 비교해보니 생각보다 차이가 분명했다.

락 없이 동작하던 코드는 실제 동시 요청 상황에서 데이터 손실이 발생했고, 테스트에서도 1000명 중 265명만 정상 반영되었다. 이를 통해 동시성 제어가 선택이 아니라 필수라는 점을 다시 느꼈다.

낙관적 락은 충돌이 적을 때는 효율적이지만, 충돌이 많아지면 재시도 비용이 빠르게 증가했다. 재시도 횟수를 늘리면 성공률을 높일 수 있었지만 그만큼 시스템 부하도 커졌다.

반면 비관적 락은 안정적으로 동시성을 제어했지만, 처리량이 줄어 전체 실행 시간이 가장 오래 걸렸다.

흥미로웠던 점은 원자적 UPDATE 방식이 가장 빠르고 안정적인 결과를 보였다는 것이었다. 복잡한 락 없이도 DB의 원자성을 활용하면 애플리케이션 부담을 줄이면서 문제를 해결할 수 있다는 점을 직접 확인할 수 있었다.

이번 테스트를 통해 단순히 기능이 동작하는지를 넘어, 동시 요청과 높은 부하 상황에서 어떤 문제가 발생할 수 있는지까지 고려하는 시각이 중요하다는 것을 배웠다.