프로그래머스 데브코스 과정 수료 혜택 중 프로그래머스 인증시험 1회 무료 응시권이 주어졌고, 필자는 그 중 PCCP를 선택하였다.   실제 코딩테스트 경험도 추가하고 싶었고, 현재 내 코딩테스트 실력 및 알고리즘 활용도가 어느 정도까지 올라와있는지 확인해보고 싶었다.

 이번 포스팅에는 간단하게 PCCP 응시 후기를 남겨보고자 한다.

🎯 시험 준비

 먼저 필자는 몇 달 전부터, 코딩테스트를 하루에 한 문제씩 풀고 있다.   이전까지는 프로그래머스에 제공된 코딩테스트를 해결하며 실력을 키웠고, 다시 하루에 한 문제씩 풀기 시작한 시점부터는 백준에 제공된 코딩테스트 문제들을 풀이하고 있다.

 개인적으로 코딩테스트 문제들을 풀이할 때 적용하는 몇 가지 시간 관련 규칙이 있다. 코딩테스트에만 시간을 전부 투자할 수는 없기 때문에 개인적으로 세워둔 규칙이다.

 첫 번째로, 문제 풀이 시작 10분 전까지는 알고리즘을 반드시 도출해야한다.   만약 10분이 지났는데도 알고리즘을 도출하지 못하면, 해당 문제에서 사용되는 알고리즘을 문제 분류, AI 등을 통해 먼저 확인한다. '해당 시간을 지나면 웬만해서는 해당 문제 풀이 방법을 도출할 수 없다'는 지론이다.

 두 번째로, 문제 풀이 시간은 1시간을 넘기지 않는다.   물론 문제 난이도에 따라 다르겠지만, 난이도가 그 정도로 높다고 판단되는 문제가 아니라면 문제 풀이에 1시간 이상을 소요하지 않는 편이다.   만약 1시간이 지났음에도 문제를 풀이하지 못하거나 반례를 찾아내지 못하면, 마찬가지로 AI를 통해 풀이 방법, 반례 등을 확인해본다.

 중요한 것은 해당 문제 풀이 방식을 이해하고, 이후 비슷한 유형의 문제가 출제되었을 때 사용 알고리즘 및 풀이 방식을 떠올릴 수 있어야 한다는 것이다. 그러므로 풀이를 확인하더라도 코드를 하나하나 확인하고, 해당 코드를 보지 않고 직접 구현해보는 방식으로 코딩테스트를 준비하고 있다.

 이후 다시 확인해보는 게 좋을 것 같은 문제들은 즐겨찾기에 걸어두고, 특정 문제 유형에 대한 공통적인 알고리즘 혹은 재확인이 필요할 것 같은 알고리즘 등은 개인 노션 페이지에 정리하여, 추후 재확인할 수 있도록 하고 있다.   정리를 해둬야만 한다고 판단될 경우에만 기록하기 때문에, 알고리즘이 추가되는 빈도는 낮은 편이다.

 그럼에도, 아직 어려운 단계까지 풀이 가능한 수준은 아니다. 현재 프로그래머스 Level 23, 백준 Gold 31 정도가 풀이 가능한 최대 선인 것 같다. 당연하게도 문제 난이도에 따라 풀이 성공률이 많이 낮아진다.

 그렇게 다음과 같이 프로그래머스 및 백준 코딩테스트를 준비한 상태에서 PCCP에 응시하였다.

$$ \small{\text{〈 프로그래머스 〉}} $$

$$ \small{\text{〈 백준 〉}} $$

🔎 PCCP 체감 난이도

 문제는 총 4문제가 주어지며, 제한 시간은 2시간이다.

 1, 2번 문제는 그렇게 난이도가 높지는 않았다. 개인적인 체감 난이도는 둘 다 백준 Silver 3 ~ 1 정도였다.

 1번 문제는 처음 보는 유형이라 처음에는 좀 당황했는데, 그래도 어떻게 점화식을 잘 찾아낼 수 있었다. 점화식만 찾아내면 이후 구현은 간단하게 할 수 있는 수준이었다. 문제 풀이에는 약 15분 정도가 소요됐다.

 2번 문제는 개인적으로는 1번 문제보다 쉬웠다. 기존에 풀어본 다른 코딩테스트 문제들과 비슷한 유형의 문제였다. 당황했던 1번 문제와 달리 침착하게 구현할 수 있었으며, 마찬가지로 문제 풀이에는 약 15분 정도가 소요됐다.

 3번 문제부터는 확실히 난이도 상승이 체감되었다. 체감 난이도는 백준 Gold 3 ~ 1 정도였다.

 알고리즘과 풀이 방식은 비교적 빨리 찾아낼 수 있었다. 기본적으로 백준 Gold 문제를 좀 풀어본 사람들은 충분히 떠올릴 수 있는 방식이었다. 다만, 실제 구현에서 어려움을 겪었다.   구현 섹션을 약 3~4 섹션으로 나누었는데, 그 중 마지막 섹션 구현 도중, 앞에서 진행해둔 구현과 뭔가 틀어진 것을 느꼈다. 기존에 떠올려둔 구현 방식을 마지막 섹션에서 그대로 구현하기에 어려움이 존재했고, 이 과정에서 자료구조를 여러 번 변경했다. 그렇게 구현이 틀어지면서 이것저것 변경하다보니, 문제 풀이를 마무리한 시점에서 변경된 자료구조로 인한 시간복잡도 변경과 반례 및 엣지 케이스 등을 고려할 시간이 없었다. 기본으로 주어진 테스트케이스 통과만 확인한 후 문제 풀이를 마무리하였다. 문제 풀이에는 약 1시간 정도가 소요됐다.

 4번 문제는 확실히 가장 난이도가 높았다. '2시간을 모두 해당 문제 풀이에 소요해도 풀 수 있을지 확신할 수 없다'는 생각이 들었다. 체감 난이도는 백준 Gold 1 ~ Platinum 수준이었다.

 기본적으로 점화식을 알아내야만 풀 수 있는 문제였다. 문제 지문이 꽤나 길기도 했고, 문제 풀이 시작 시점에 남은 시간이 20~30분 정도밖에 없었기에, 점화식을 구해보다가 제한 시간이 끝나버렸다.   개인적으로는 완전히 처음 보는 유형이었고, 문제 복잡도도 상당해보였다. 점화식을 어찌저찌 찾아낸다고해도 '코드로 구현할 수 있었을까?' 에 대한 의문에는 여전히 물음표가 남아있다.

※ 참고로, 필자는 백준 Platinum 문제 풀이 경험이 없으므로, 해당 난이도 평가는 개인적인 체감에 가깝다.

🪪 응시 결과

PCCP 시험의 경우, 제한 시간이 종료되면 응시 결과를 해당 페이지를 통해 거의 바로 확인할 수 있다.

 취득 레벨은 Lv.0 ~ Lv.5로 구분되어 있으며, 총점 1,000점을 기준으로 성적이 구분된다.   성적 유효 기간은 취득일로부터 2년이다.

 필자의 경우, 650점을 획득하여 Lv.3 자격을 취득했다.

$$ \small{\text{〈 PCCP 성적표 〉}} $$

💬 회고

 응시 전 목표는 Lv.4 취득이었기에, 다소 아쉬움이 남는다.   문제 풀이 결과를 확인할 수 없기 때문에 확신할 수는 없지만, 3번 문제가 일부 반례로 인해 부분 점수 획득 처리되었을 것으로 예상된다. 그렇게 2.5 Solve가 아닐까 예상해본다.

 채점표가 따로 공개되어있지 않으므로 확신할 수는 없지만, 3 Solve를 했더라도 문제 난이도 분포 상 Lv.4 취득은 어렵지 않았을까 생각된다.   물론 만약 1 Solve당 250점을 받는 구조라면, 3 Solve 시 총 750점을 취득하여 Lv.4 달성이 가능할 것이다. 만약 그런 기준이라면... 더더욱 아쉬울 것 같다.

 그래도 첫 실전 코딩테스트 치고는 완전 나쁜 결과는 아니라고 생각한다. 또한, 실전 경험을 쌓을 수 있는 값진 경험이었다.   앞으로도 꾸준히 코딩테스트를 풀어나갈 생각이므로, 점점 난이도를 올려가며 더욱 더 다양한 문제 유형을 경험해봐야겠다.

 이후 기회가 된다면, 다음에는 최소 Lv.4 취득을 목표로 도전해보고 싶다.

 이전 포스팅을 통해, 캐시에 대한 이해는 어느정도 가닥이 잡혔다.   이제 본격적으로 스프링에서 캐시를 사용하기 위해 필요한 개념들을 하나하나 자세하게 살펴보자.

1. Spring Cache 추상화 인터페이스

• 스프링은 캐시를 동일한 방식으로 다룰 수 있도록 Cache Abstraction을 제공

1️⃣ Cache

• 캐시 한 덩어리

  • 일반적으로 cacheName 하나

• 핵심 메서드

  메서드	설명
  get(Object key)	키로 조회, 값이 없으면 null 반환. 캐시 hit/miss 판정 가능
  get(Object key, Class<T> type)	타입 지정 조회
  get(Object key, Callable<T> valueLoader)	캐시 미스 시 Callable 실행 후 값 저장. 동시성 제어 핵심.
  put(Object key, Object value)	캐시에 값 저장
  putIfAbsent(Object key, Object value)	이미 값이 없을 때만 저장
  evict(Object key)	특정 키 삭제
  clear()	캐시 전체 삭제

📌 get(Object key, Callable<T> valueLoader 사용 예시

Cache cache = cacheManager.getCache("user");
User user = cache.get(userId, () -> userRepository.findById(userId));

• 캐시에 "user" 값이 존재하면 즉시 반환
• 존재하지 않으면 Callable 실행
  • 결과를 캐시에 저장 후 반환
• 캐시가 없는 키에 대해 여러 스레드가 동시에 Callable 함수를 실행하지 않도록 동시성 제어 가능
  

2️⃣ CacheManager

• 여러 개의 Cache를 관리, 생성, 조회하는 역할

• 핵심 메서드

  메서드	설명
  getCache(String name)	이름으로 Cache 인스턴스 반환
  getCacheNames()	등록된 Cache 이름 목록 반환

• 구현체 예시

  • CaffeineCacheManager -> JVM 메모리 기반 로컬 캐시
  • RedisCacheManager -> 분산 캐시
  • SimpleCacheManager -> 여러 Cache를 직접 등록 가능
    

3️⃣ CacheResolver

• 호출에서 어떤 캐시를 쓸지 결정

• 일반적으로 cacheName으로 찾은 후 반환

• 멀티테넌시, 환경별 캐시, 요청별 캐시 선택 시 커스텀 가능

  • 멀티테넌시 -> 하나의 애플리케이션이나 시스템 인스턴스를 여러 독립 고객(tenant)이 공유하면서도, 각 고객의 데이터와 설정은 격리하는 구조

• 핵심 메서드

  메서드	설명
  Collection<? extends Cache> resolveCaches(CacheOperationInvocationContext<?> context)	호출 컨텍스트에서 캐시 결정

4️⃣ KeyGenerator

• 캐시 키 생성 정책

• 기본적으로는 메서드 파라미터 기반

• 성능 및 정합성 문제로 인해, 정말 간단한 경우가 아니라면 대부분 커스텀 키 사용

• 사용 예시

  @Override
  public Object generate(Object target, Method method, Object... params) {
    return method.getName() + "#" + Arrays.deepHashCode(params);
  }

• 메서드 이름 + 파라미터 Hash로 키 생성

• 멀티테넌시, 특정 필드만 Key로 하고 싶을 때 커스텀

  
  

5️⃣ CacheErrorHandler

• 캐시 백엔드(Redis 등) 장애 발생 시의 동작 정의

• 기본적으로는 예외를 던짐

• 캐시 장애 시 DB 조회로 폴백하는 방식으로 주로 커스텀

  메서드	설명
  handleCacheGetError(RuntimeException exception, Cache cache, Object key)	get 시 예외 처리
  handleCachePutError(RuntimeException exception, Cache cache, Object key, Object value)	put 시 예외 처리
  handleCacheEvictError(RuntimeException exception, Cache cache, Object key)	evict 시 예외 처리
  handleCacheClearError(RuntimeException exception, Cache cache)	clear 시 예외 처리

• 사용 예시

  @Override
  public void handleCacheGetError(RuntimeException exception, Cache cache, Object key) {
    log.error("Redis 에러: DB 폴백", exception);
    // DB 조회
  }

  
  

2. @EnableCaching

• 내부적으로 CachingConfigurationSelector 를 통해 캐시 인프라 구성을 import하여 어노테이션 기반 캐싱 활성화

• 기본적으로 Proxy 기반이므로, 주의할 점 존재

  • Self-Invocation -> 같은 클래스 내부에서 내부 메서드 호출 시, 프록시를 거치지 않으므로 캐시 미동작

    public class CacheMain {
        @Cacheable("user")
        public User getUser(Long id) { ... }
    
        public User getUser2(Long id) {
            return getUser(id);    // 내부 호출, 프록시를 안 거침 -> 캐시 미적용
        }
    }

  • final/private 메서드 -> 프록시가 가로채지 못하는 경우가 많음

    
    ## 🌊호출 흐름

• @Cacheable 기준, 호출 흐름

  클라이언트 요청
    ↓
  Service (프록시)
    ↓ (Advisor / Interceptor 가로채기)
  CacheInterceptor
    ├─ CacheOperation 조회 (OperationSource)
    ├─ CacheManager로 Cache 조회
    ├─ Cache Hit → 바로 반환
    └─ Cache Miss → 실제 Service 메서드 실행 → 결과 캐시에 저장 → 반환

• 메서드 호출이 비즈니스 서비스 로직에 도달하기 이전, CacheInterceptor가 먼저 Hit/Miss 체크 수행

  
  ## 🫘 인프라 빈 관점

• 프록시 기반 캐시는 스프링 내부에서 다음과 같은 구조로 이해 가능

  구성 요소	역할
  Advisor	어떤 메서드에 캐시 어드바이스를 적용할지 결정 ( @Cacheable , @CachePut , @CacheEvict 등 )
  Interceptor (=Advice)	실제 캐시 동작 수행 ( CacheInterceptor )
  OperationSource	@Cacheable 등의 어노테이션을 CacheOperation 객체로 변환 -> 캐시 동작 정의 생성
  CacheManager / KeyGenerator / CacheResolver / ErrorHandler	실제 캐시 조회, 키 생성, 선택, 예외 처리 등을 담당
  ### 1️⃣ Advisor

• AOP에서는 어떤 시점에 어떤 Advice를 적용할지 결정

• 스프링 캐시에서는 CacheOperationSource, CacheInterceptor를 묶어서 Advice로 등록

• 메서드에 @Cacheable 이 있으면 CacheInterceptor 실행을 알려주는 중간 관리자 역할

  
  ### 2️⃣ OperationSource

• @Cacheable , @CachePut , @CacheEvict 같은 어노테이션을 내부적으로 CacheOperation 객체로 변환

• 다음과 같은 코드를

  @Cacheable(value = "users", key = "#id")
  public User find(Long id)

  다음과 같은 구조로 변환

  CacheOperation:
  - cacheName: users
  - key: #id
  - condition: null
  - unless: null

• 어노테이션을 기계가 이해할 수 있는 메타데이터로 바꿔주는 역할

  
  ### 3️⃣ Interceptor

• 실제 캐시 로직 수행자

• 동작 흐름

  1. 캐시 키 생성
   2. CacheManager에서 캐시 가져오기
   3. 캐시에 값이 있는지 체크
     → 있으면 바로 반환 (메서드 미실행)
     → 없으면 실제 메서드 실행
   4. 결과를 캐시에 저장
   5. 반환

  
  # 3. 스프링 캐시 어노테이션

1️⃣ @Cacheable

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@Reflective
public @interface Cacheable {

    // cacheNames: 사용할 캐시 이름들 지정
    String[] cacheNames() default {};
    // value: cacheNames와 동일.cacheNames의 별칭
    String[] value() default {};

    // key: 캐시 키를 SpEL로 지정
    String key() default "";

    // keyGenerator: KeyGenerator 빈 이름 지정
    String keyGenerator() default "";

    // cacheManager: CacheManager 빈 이름 지정(Resolver 대신 직접 지정하는 느낌)
    String cacheManager() default "";

    // cacheResolver: CacheResolver 빈 이름 지정(여러 캐시에서 동적 선택 시)
    String cacheResolver() default "";

    // condition: 캐시 적용 여부(SpEL). true일 때만 캐시 로직 동작
    String condition() default "";

    // unless: 캐시 저장 여부(SpEL). true면 put 스킵
    // 일반적으로 '결과 기반'으로 평가
    String unless() default "";

    // sync: stampede 방지용 동기화 모드(같은 key에 대한 동시 로딩 방지)
    boolean sync() default false;
}

• 조회 캐싱의 기본

  • 캐시에 값이 있으면 메서드 실행 없이 캐시 값을 반환하고, 없으면 메서드 실행 후 캐시에 저장

• cacheNames

  • 사실상 데이터 구조 및 정책 단위
  • TTL, size, serializer를 cacheName별로 다르게 주는 게 일반적

• key

  • 키를 SpEL로 직접 만들면 강력하지만, 문자열 키를 남발하게 되어 충돌 가능성과 관리 난이도 증가
  • 일반적으로 '규칙화된 prefix + 식별자' 정도만 SpEL로 사용
    • 복잡해지면 KeyGenerator 구현

• condition

  • 사전 조건
  • 일반적으로 메서드 실행 전 평가
  • true 일 때만 캐시 로직 적용
  • false 면 캐시 무시 후 메서드 호출

• unless

  • 사후 거부 조건(veto)
  • 메서드 실행 후 평가
  • 반환값( #result )을 보고 캐싱하지 않을 결과 결정
  • true 일 시 캐시에 저장하지 않음

• sync=true

  • Stampede 방지에 매우 중요

  • 캐시 구현체가 동시 로딩을 잘 지원해야 좋은 효과 발휘

  • 모든 기능과 조합 시 제약이 생길 수 있어, 핵심 키 몇 개에만 제한적으로 적용하는 경우가 많음

    • unless 와는 같이 사용 불가능
    
    

2️⃣ @CachePut

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Inherited
@Documented
@Reflective
public @interface CachePut {
    String[] cacheNames() default {};
    String[] value() default {};
    String key() default "";
    String keyGenerator() default "";
    String cacheManager() default "";
    String cacheResolver() default "";
    String condition() default "";
    String unless() default "";
}

• 항상 메서드 실행 후 캐시 갱신

  • 쓰기 후 캐시 갱신을 메서드와 묶을 때 유용

• DB 트랜잭션과의 순서 및 실패를 조심해야 함

  • 안정성 측면에서 @CacheEvict 가 더 선호되기도 함

    
    ## 3️⃣ @CacheEvict ```java @Target({ElementType.TYPE, ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Inherited @Documented @Reflective public @interface CacheEvict { String[] cacheNames() default {}; String[] value() default {}; String key() default ""; String keyGenerator() default ""; String cacheManager() default ""; String cacheResolver() default ""; String condition() default "";

    // allEntries=true 시, 해당 캐시의 모든 엔트리 drop boolean allEntries() default false;

    // beforeInvocation=true 시 메서드 실행 전에 evict // 따라서, 메서드가 예외를 던져도 evict 수행 boolean beforeInvocation() default false; } ```

• 메서드 실행 전/후에 캐시 항목 제거(무효화)

• allEntries=true 는 매우 위험할 수 있으므로, 정말 필요할 때만 사용

• beforeInvocation=true 는 실패하더라도 반드시 캐시를 무효화해야 하는 상황에만 사용

  
  ## 4️⃣ @Caching ```java @Target({ElementType.TYPE, ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Inherited @Documented @Reflective public @interface Caching { Cacheable[] cacheable() default {}; CachePut[] put() default {}; CacheEvict[] evict() default {}; } ```

• 여러 캐시 동작을 한 메서드에 조합

• 1번 업데이트에서

  • A 캐시는 evict
  • B 캐시는 put
  • 둘을 동시에 해야되는 상황 같은 때 사용
    ## 5️⃣ @CacheConfig ```java @Target(ElementType.TYPE) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface CacheConfig { String[] cacheNames() default {}; String keyGenerator() default ""; String cacheManager() default ""; String cacheResolver() default ""; } ```

• 클래스 레벨 기본값

  • 클래스에 공통 설정(cacheNames, keyGenerator, cacheManager, cacheResovler ...)을 걸어 중복 제거

• @CacheConfig 만 붙인다고 캐시가 켜지는 게 아니고, 오직 기본값만 제공

• 코드 예시

  @CacheConfig(cacheNames = "user", keyGenerator = "userKeyGenerator")
  public class UserService {
    @Cacheable    // 메서드별 적용
    public User get(long id) { ... }
  }

  
  # 4. SpEL과 평가 컨텍스트

• 스프링 캐시 어노테이션은 SpEL을 사용해 다음을 제어 가능
  • key: 캐시 키를 어떻게 만들 것인가
  • condition: 캐시 동작을 적용할 것인가 (사전 조건)
  • unless: 결과를 보고, 캐시 저장을 거부할 것인가 (사후 거부 조건)
    ## 🔭 어노테이션별 평가 시점 차이

1️⃣ @Cacheable 평가 순서

• 코드

  @Cacheable(
    cacheNames = "items",
    key = "#id",
    condition = "#id > 0",        // (1) 먼저 평가
    unless = "#result == null"    // (2) 메서드 실행 후 평가
  )
  public Product find(long id) {
     return productRepository.findById(id).orElse(null);
  }

  • Cache Hit인 경우
    • 메서드 비호출
    • 따라서 #result 자체가 없음
    • 즉, unless 는 Cache Hit 판단 조건에서 제외
      ### 2️⃣ @CachePut 평가 순서

• 코드

  @CachePut(
    cacheNames = "products",
    key = "#result.id",                // 생성 후 id 생기는 경우 유용
    condition = "#result != null",    // 결과 기반 condition 가능
    unless = "#result.delete == true"    // 결과에 따라 캐시 put 거부
  )
  public Product updateProduct(ProductUpdateDto response) {
     return productService.update(response);
  }

• @CachePut 은 메서드가 항상 실행
• condition , unless 모두 사용 및 제어 가능
• @CachePut 에서는 condition 또한 메서드 호출 후 평가되며, 여기서 #result 참조 또한 가능
  ### 3️⃣ @CacheEvict 평가 순서

  

• 코드 ( beforeInvocation = false )

  @CacheEvict(cacheNames = "products", key = "#id")
  public void deleteProduct(Long id) {
     productRepository.deleteById(id);    // 성공 후 evict
  }

  • 메서드 성공 후 무효화
  • #result 사용 가능

• 코드 ( beforeInvocation = true )

  @CacheEvict(cacheNames = "products", key = "#id", beforeInvocation = true)
  public void deleteProduct(Long id) {
     productRepository.deleteById(id);    // 실행 전 evict
  }

  • 메서드 실행 전 무효화
  • 아직 결과가 없기 때문에 #result 사용 불가
    ## 🔖 자주 사용되는 값

1. #root.methodName

• 호출된 메서드 이름

  key = "#root.methodName + ':' + #id"

  
  

2. #root.method

• 호출된 메서드

  key = "#root.method.name + ':' + #id"

  
  

3. #root.target

• 대상 객체 (빈 인스턴스)

  key = "#root.targetClass.simpleName + ':' + #id"

  
  

4. #root.targetClass

• 대상 클래스

  key = "#root.targetClass.name + ':' + #id"

  
  

5. #root.args

• 인자 배열

  key = "#root.args[0]"

  
  

6. #root.caches

• 현재 적용 대상 캐시 컬렉션

  key = "#root.caches[0].name + ':' + #id"

  
  

7. 파라미터 이름 기반 참조 ( #id , #request.userId )

   key = "#id"
    key = "#request.userId + ':' + #request.page"

• -parameters 컴파일 옵션 필요
  

8. 인덱스 기반 참조 ( #a0 , #p0 , #root.args[0] )

• 파라미터 이름을 못 가져오는 상황에서도 안전한 방식
• 스프링 공식 문서에 따르면, 파라미터 이름이 없을 시 #a0 , #p0 같은 인덱스 접근을 쓰라고 안내
  • Spring Cache 공식 문서

    key = "#a0"        // 첫 번째 인자
    key = "#p1"        // 두 번째 인자

    
    

9. #result

• 메서드 결과값

• @Cacheable : unless 에서 사용 가능

• @CachePut : key , condition , unless 에서 결과 기반으로 사용 가능

• @CacheEvict : beforeInvocation=false 일 때 사용 가능

  
  ## 📒 코드 예시 ### 1️⃣ 입력 조건 + null 결과 제외 ```java @Service @RequiredArgsConstructor public class ProductService {

  private final ProductRepository productRepository;

  / **

  * id가 0 이하면 캐시 미사용 (condition)
  * 조회 결과가 null이면 캐시에 미저장 (unless)
  */

  @Cacheable(

    cacheNames = "products",
    key = "#id",
    condition = "#id != null && #id > 0",
    unless = "#result == null"

  ) public Product findById(Long id) {

    // 캐시 miss일 때만 실행
    return findByIdFromDb(id);

  }

  private Product findByIdFromDb(Long id) {

    return productRepository.findById(id).orElse(null);

  } }

  <br>
  

2️⃣ 검색 캐시 (문자열 정규화 + 페이지 제한)

@Service
@RequiredArgsConstructor
public class ProductSearchService {

    private final ProductSearchRepository productSearchRepository;

    /**
     * 검색 캐시는 폭발하기 쉬움
     * page가 너무 크면 캐시 제외 (condition)
     * 결과가 비어있으면 캐시 저장 제외 (unless)
     * keyword는 trim과 lowercase로 키 정규화
     */
    @Cacheable(
        cacheNames = "searchProducts",
        key = "'keyword=' + #keyword.trim().toLowerCase() + ':page=' + #page + ':size=' + #size",
        condition = "#page >= 0 && #page < 20 && #size <= 100",
        unless = "#result == null || #result.isEmpty()"
    )
    public List<Product> searchProduct(String keyword, int page, int size) {
        return searchProductFromDb(keyword, page, size);
    }

    private List<Product> searchProductFromDb(String keyword, int page, int size) {
        return productSearchRepository.search(keyword, page, size);
    }
}

3️⃣ @CachePut에서 결과 기반 키/조건 사용

@Service
@RequiredArgsConstructor
public class ProudctService {

    private final ProductRepository productRepository;

    /**
     * @CachePut은 항상 메서드 실행
     * 저장/수정 후 반환된 결과(result)를 기준으로 캐시에 저장
     */
    @CachePut(
        cacheNames = "products",
        key = "#result.id",                // 결과 id 값으로 키 추출
        condition = "#result != null",    // 결과가 있어야만 put
        unless = "#result.notSale"        // notSale 상태면 put 금지
    )
    public Product save(ProductCreateDto request) {
        return saveProduct(request);
    }

    private Product saveProduct(ProductCreateDto request) {
        return productRepository.save(request.id, request.notSale);
    }
}

4️⃣ @CacheEvict - beforeInvocation 차이

@Service
@RequiredArgsConstructor
public class ProductService {

    private final ProductRepository productRepository;

    /**
     * 기본값 (beforeInvocation = false)
     * 메서드가 성공해야만 그 후에 캐시 제거
     * 예외 발생 시 캐시가 삭제되지 않음
       - 트랜잭션 롤백 가능성이 존재할 때, 일관성 측면에서 더 안전한 편
     */
    @CacheEvict(cacheNames = "products", key = "#id")
    public void deleteProduct(Long id) {
        deleteProductFromDb(id);
    }

    /**
     * beforeInvocation = false
     * 메서드 호출 전, 미리 캐시 제거
     * 예외가 발생하더라도 그 전에 캐시는 제거된 상태
     */
    @CacheEvict(cacheNames = "products", key = "#id", beforeInvocation = true)
    public void deleteProductForce(Long id) {
        deleteProductFromDb(id);
    }

    private void deleteProductFromDb(Long id) {
        productRepository.delete(id);
    }
}

5. 키 설계

캐시는 "같은 키면 같은 값" 이라는 강한 가정을 전제로 동작

• 키가 잘못되면 아래와 같은 문제 발생 가능

  1. 잘못된 데이터 반환(오염): 서로 다른 요청이 같은 키로 매핑(충돌)

• 2. 정보 누출*: 권한/테넌트별 결과가 다름에도, 키에 scope가 없어서 남의 데이터 노출 가능

• 3. 캐시 무용지물*: 동일 요청임에도 키가 계속 달라져 Cache Miss 발생

• 4. 운영 통제 불가*: 키의 prefix나 버전이 없으면 롤백/배포 때 전체 캐시를 제거해야 함

  
  

📌 키 설계 규칙

1. 짧고 결정적

• 같은 입력이면 항상 같은 키
• 리스트 검색에서, 리스트 파라미터가 있으면 정규화 필수
  • 정렬, 중복 제거, 공백 제거 및 소문자 통일
• 키 정규화 예시:
  • 입력

    [solo, male]
    [male, solo]

  • 정규화

    [male, solo]

  • 정규화된 키

    games:tags=male,solo

    
    ### 2. 충돌 방지
• 결과를 바꾸는 모든 요소는 키에 포함
  • 아닐 시 오염 발생
• 필드가 결과에 영향을 주는지 항상 체크
  • page, pageSize, orderBy 등
    ### 3. 버전
• 캐시는 스키마나 응답, 직렬화 방식이 바뀌면, 이전 캐시가 틀린 값이 될 가능성 존재
  • 캐시는 원본 DB가 아닌 복제본
  • 버전 업데이트 배포 후, 같은 요청의 응답 구조가 달라질 수 있음
• 버저닝을 통해서 이를 관리 가능
  • playon:v2:partyDetail:{partyId}
• 장점
  • 배포 직후 이전 캐시의 자동 무효화
• 단점
  • 배포 직후 Cold Start 문제 발생
  • 이는 TTL 조절, 워밍업, 스태거 배포 등의 방법으로 완화 가능
    ### 4. 멀티테넌시/권한/사용자별 결과는 Key Scope로 강제
• 캐시는 기본적으로 같은 키는 같은 값으로 반환
• 테넌시/권한/사용자에 따라 달라 결과가 달라짐에도 같은 키를 사용하면, 다른 사람의 데이터를 그대로 재사용하는 심각한 버그 발생
  • 이는 단순한 캐시 버그를 넘어선 데이터 유출 문제
• 다음과 같은 캐시 스코프를 포함
  • 테넌트별 데이터 분리 : tenantId
  • 권한별 노출 필드 차이 : role
  • 사용자별 결과 차이 : userId
    ### 5. 키 길이 제한 관리 ``` 📑 Redis 사용 중이라고 가정 ```
• Redis는 긴 키도 저장 가능하지만, 다음과 같은 문제 발생 가능

1. 네트워크 비용 증가

• Redis는 요청 시마다 키 문자열을 그대로 전송
  • QPS가 높을수록 네트워크 트래픽 급격히 증가
    • QPS : 초당 처리 요청 수 ( Query Per Second )

2. 메모리 오버헤드

• Redis는 키 자체도 메모리에 저장
• 키가 길어지면, 특히 필터 검색이 많은 API에서 메모리 낭비 급증

3. 필터 폭발 문제 발생 및 운영 난이도 증가

• 필터 수가 많아질수록 키에 포함되는 디멘전 증가
  • 이로 인해 키 길이 및 캐시 엔트리 수 급증
  • 이를 해결하기 위해 필터 정규화 후 해시로 압축하는 방식 주로 사용
  • 반드시 정규화 후 해싱
  • SHA-256 알고리즘을 사용하면 낮은 충돌 확률, 고정된 길이 보장 가능
    

🔑 키 생성 방식 3단계

🎯 키 설계 규칙을 단계적으로 고도화해가며, 캐시 키 설계 규칙을 확장해보자.

1️⃣ 전역 KeyGenerator

​@Bean
public KeyGenerator globalKeyGenerator() {
    return (target, method, params) ->
        method.getName() + "::" + Arrays.deepToString(params);
}

• 매우 단순한 형태의 KeyGenerator 구현 방식
• 장점
  • 빠른 구현
  • 직관적인 규칙
    ``` 🔎 현재 키 설계 원칙 관점에서는 여러 문제 존재 ```
• 1. 키가 결정적이지 않음*
• 필터에 컬렉션이 포함할 경우, 순서가 매번 변경될 수 있음
  • 같은 의미의 요청임에도 서로 다른 키 생성
  • 이로 인해 Cache Miss 발생 가능성 증가
• DTO의 toString() 포맷 등이 바뀌면 키 변경

2. 충돌을 방지하지 못함

• method.getName() 의 경우, 동일한 메서드명(오버로드 등)으로 인한 충돌 위험 존재
• Arrays.deepToString() 의 경우, 서로 다른 파라미터가 동일한 문자열이 나오는 등 충돌 위험 존재

3. 버전별 캐시 무효화 어려움

• 응답 스키마나 정규화 로직이 변경되면, 잘못된 이전 캐시값 사용 가능

4. 캐시 스코프 누락 가능성 존재

• user, tenant, role 등 캐시 스코프 정보가 파라미터에 포함되지 않으면 키에 미반영
• 이로 인해 잘못된 캐시 재사용이나 정보 누출 위험 발생

5. 키 길이가 길어질 수 있음

• 필터가 많아지면 키가 길어져 네트워크 및 메모리 비용 증가
  ### 2️⃣ 전역 정규화 + 해시로 압축

​@Bean
public KeyGenerator hashKeyGenerator() {
    return (target, method, params) -> {
        String signature = method.getDeclaringClass().getSimpleName() + "#" + method.getName();

        String normalized = Canonicalizer.canonicalize(params);        // 컬렉션 정규화
        String digest = sha256Hex(signature + ":" + normalized);

        return signature + ":" + digest;
    }
}

static class Canonicalizer {
    static String canonicalize(Object... params) {
        if (params == null || params.length == 0) {
            return "[]";
        }

        return Arrays.stream(params)
                     .map(Canonicalizer::normalize)
                     .collect(Collectors.joining(",", "[", "]"));
    }

    // 정규화
    static String normalize(Object p) {
        if (p == null) {
            return "null";
        }

        if (p instanceof CharSequence s) {
            return s.toString().trim();
        }

        if (p instanceof Number || p instanceof Boolean) {
            return String.valueOf(p);
        }

        if (p instanceof Enum<?> e) {
            return e.name();
        }

        // Map -> key 기준으로 정렬
        if (p instanceof Map<?, ?> m) {
            return m.entrySet().stream()
                    .map(e -> normalize(e.getKey()) + "=" + normalize(e.getValue()))
                    .sorted()
                    .collect(Collectors.joining("&", "{", "}"));
        }

        // Set -> 정렬
        if (p instanceof Set<?> s) {
            return s.stream()
                    .map(Canonicalizer::normalize)
                    .sorted()
                    .collect(Collectors.joining(",", "S[", "]"));
        }

        // List -> 값 순서 유지
        if (p instanceof List<?> l) {
            return l.stream()
                    .map(Canonicalizer::normalize)
                    .collect(Collectors.joining(",", "L[", "]"));
        }

        return p.toString().trim();
    }
}

• 전역 KeyGenerator를 유지하되, 결정적 키 생성과 키 길이 제한 문제 해결
  • 같은 의미면 같은 키 생성
  • 컬렉션 정규화 후 SHA-256 알고리즘을 통해 고정 길이 키 생성
    

🔎 여전히 남아있는 문제

1. 도메인별 키 정책 차이

• 일부 List 는 순서 유지 필요, 일부는 정렬 후 키 생성이 효율적일 수 있음
• 기본값 필드는 키에서 제외 가능

2. 캐시 스코프 누락 가능성 존재

• 캐시 스코프 존재 시, 여전히 누락 가능성 존재

3. 버전별 캐시 무효화 어려움

• 전역 KeyGenerator만으로는 특정 캐시 버전 관리 불가능

4. DTO 구조 변경에 따른 문제

• 필드 추가나 포맷 변경 등의 구조 변경 시, 키 변경 가능
• 동일한 의미임에도 불필요한 Cache Miss 발생
  ### 3️⃣ 전역 KeyGenerator 최소화 + 키 중앙 집중화
• 간단한 키는 @CacheConfig + KeyGenerator 방식을 사용
• 복잡한 키의 경우, Prefix 는 Redis 설정으로, 정규화 등의 키 정책은 CacheKeys 로 중앙집중화
• 이를 통해 전역 KeyGenerator 방식의 한계를 해결
  

1. Prefix는 RedisCacheConfiguration으로 등록

​@Bean
public RedisCacheConfiguration redisCacheConfiguration() {
    return RedisCacheConfiguration.defaultCacheConfig()
                .computePrefixWith(cacheName -> "playon:" + cacheName + "::");
}

• Prefix 설정을 통해 캐시 그룹 단위로 분석 및 삭제 가능
• 환경 분리가 필요하다면, Environment를 통해 profile을 받아서 prefix에 추가
  

2. CacheNames에 캐시 이름 상수화

​@NoArgsConstructor(access = AccessLevel.PRIVATE)
public final class CacheNames {
    public static final String PARTY_LIST = "partyList";
    public static final String PARTY_DETAIL = "partyDetail";
}

• 사용할 cacheNames들을 중앙 집중적으로 관리 가능
  

3. CacheKeys로 도메인별 키 정책을 캐시별로 명시

​@NoArgsConstructor(access = AccessLevel.PRIVATE)
public final class CacheKeys {
    private static final String VERSION = "v1";

    public static String partyListKey(
        int page, int pageSize, String orderBy, boolean isMacSupported, String partyAt,
        Long appId, Collection<String> genres, Collection<String> tags
    ) {
        // 1. 정규화 진행
        Set<String> g = normalize(genres);
        Set<String> t = normalize(tags);

        // 2. 필터 및 디멘전 추가
        String payload =
            "page=" + page +
            "&size=" + pageSize +
            "&orderBy=" + trim(orderBy) +
            "&mac=" + isMacSupported +
            "&partyAt=" + trim(partyAt) +
            "&appId=" + (appId == null ? "" : appId) +
            "&genres=" + String.join(",", g) +
            "&tags=" + String.join(",", t);

        // 3. 해시로 압축
        return VERSION + ":" + sha256Hex(payload);
    }

    // 컬렉션 -> 정렬을 통한 정규화
    private static Set<String> normalize(Collection<String> c) {
        TreeSet<String> ts = new TreeSet<>();

        if (c == null) {
            return ts;
        }

        for (String v : c) {
            String trimV = trim(v);

            if (!trimV.isEmpty()) {
                ts.add(trimV);
            }
        }

        return ts;
    }

    // SHA-256 알고리즘을 통한 해싱
    private static String sha256Hex(String s) {
        try {
            byte[] digest = MessageDigest.getInstance("SHA-256")
                            .digest(s.getBytes(StandardCharsets.UTF_8));

            StringBuilder sb = new StringBuilder(digest.length * 2);

            for (byte b : digest) {
                sb.append(String.format("%02x", b));
            }

            return sb.toString();
        } catch (Exception e) {
            throw new IllegalArgumentException(e);
        }
    }

    // 빈 값 체크 및 공백 제거 + 대소문자 통일
    private static String trim(String s) {
        return s == null ? "" : s.trim().toLowerCase(Locale.ROOT);
    }
}

• 결정성 준수
  • 각 캐시에 맞게 정규화 진행
• 충돌 방지
  • 결과를 바꾸는 필드를 반드시 포함
• 버전 관리
  • 버전 변경 시, 이전 캐시 자동 무효화
• 캐시 스코프
  • 현재 코드에는 추가하지 않았지만, 캐시 스코프 존재 시 필요한 캐시에만 포함
• 키 길이 제한 준수
  • payload가 아무리 길어지더라도, SHA-256 해싱을 통해 고정 길이로 제한
    

4. @Cacheable에서 CacheKeys 호출

​@Cacheable(
    cacheNames = CacheNames.PARTY_LIST,
    key = "T(패키지명.CacheKeys).partyListKey(#page, #pageSize, #orderBy, #isMacSupported, #partyAt, #request.appId(), #request.genres(), #request.tags())"
)
public PartyListResponse list(int page, int pageSize, String orderBy, boolean isMacSupported, String partyAt, GetAllPartiesRequest request) {
    // 구현 생략
}

• 캐시를 사용할 메서드에서, 어노테이션의 각 필드에 구현 클래스 사용
• 결과적으로 다음과 같은 키 저장
  • playon:partyList::v1:{sha256hex}

 백엔드 개발자에게 가장 필요한 능력이자, 가장 관심있게 봐야할 부분이 무엇일까? 필자는 '성능 최적화' 가 반드시 그 중 하나라고 생각한다.

 지금까지 학습을 하고 프로젝트를 진행해가면서, 이러한 '성능 최적화' 를 위해 여러 시도를 했다. 대표적으로 '쿼리 튜닝' 및 '인덱싱' 이 있다.

 이러한 작업들을 어느 정도 만족스럽게 마무리한 이후, 성능을 더욱 극대화하고 싶다는 생각이 들어 찾아보던 중, 캐싱을 적용하면 이러한 목적을 달성할 수 있다는 것을 알게 되었다.

 당연히 캐시의 개념과 목적 정도는 알고 있었지만, 이를 더욱 자세하게 이해하고 코드로 녹여내는 것은 별개의 일이다. 당장 내 프로젝트에 캐싱을 적용하고 싶어도, 그러기 위해서는 캐시에 대한 개념과 확실한 이해가 필요하다.

 그렇기에, 당분간 캐시의 개념부터 시작해, 스프링에서 캐시를 사용하기 위해 알아야할 지식들을 점차적으로 포스팅할 예정이다.   이번 포스팅은 캐시를 이해하기 위한, 캐시의 개념에 대한 내용이다.

1. 캐시란?

캐시

• 비싼 계산 및 조회 결과를 더 빠른 저장소에 잠시 저장해, 같은 요청이 다시 오면 원본 대신 그 값을 재활용하여 돌려주는 것
• 이를 통해 지연시간(latency)를 감소시키고, 처리량(throughput)을 증가
• 캐시는 원 저장소가 아닌 성능을 위한 복제본이므로 데이터 일관성 문제가 항상 존재
  • 캐시에 남아있는 값이 최신 값이 아닐 수 있음
    ## 캐시 핵심 요소

1️⃣ Key 설계

• 캐시는 기본적으로 key -> value 맵

  • 성능을 가르는 건 키 설계가 절반이라고 봐도 무방

• 키는 정규화 필수

  • ex) tags 를 정렬해서 키에 추가

• 키 길이는 너무 길면 네트워크/메모리 측면에서 비효율적

  • sha256 같은 해시를 통해 줄이기도 함
    ### 2️⃣ Value (저장 전략)

• 실제 캐싱 대상 데이터

  • 캐시에 무엇을 저장할지에 대한 설계 영역
  • 단순 DTO뿐 아니라 저장 단위 + 표현 방식 + 크기 전략까지 모두 포함

• 직렬화 전략 선택 필요 (분산 캐시에서는 필수)

  • JSON -> 디버깅이 쉽지만 크기가 큼
  • Kryo -> 빠르고 작지만 설정이 필요
  • JDK Serialization -> 구현이 간단하지만 성능 및 보안 이슈 존재
  • 트래픽이 많아질수록, 직렬화 비용이 병목이 될 가능성 존재

• 크기 관리 중요

  • 크기가 큰 객체는 네트워크 및 메모리 부담 증가
  • 따라서 모두 다 캐싱하는 방법은 안티패턴

• 캐싱 단위 선택

  • 통째로 캐싱(Object-level caching)
    • 단순하고 빠름
    • 일부 필드만 바뀌어도 전체 무효화 필요

      party:123 -> PartyDetailResponse

  • 부분 캐싱(Fragment/Field caching)
    • 변경 범위를 최소화
    • 조립 비용이 증가하고 일관성 관리 어려움

      party:123:game
      party:123:member
      party:123:total

• 캐시 객체는 가급적 불변으로 설계

  • 참조 객체 수정은 캐시 오염으로 번질 수 있음
    ### 3️⃣ TTL (Time To Live)

• 자동 만료 시간

• 무효화가 어려운 데이터도 시간 단위로 해결 가능

• TTL이 너무 길면 stale 리스크 증가

  • 데이터 정합성 문제 발생 가능

• TTL이 너무 짧으면 cache miss 확률이 증가하여 효과 감소

• Redis 기반 Spring Cache는 엔트리 TTL을 지원하며, 고정 Duration 및 엔트리별 TTL 함수도 지원

  
  ### 4️⃣ Eviction 정책

• 캐시가 무한대로 커지면 메모리 및 성능 문제 발생

  • 정책 필요

• Caffeine 같은 로컬 캐시는 보통, maximumSize, expireAfterWrite, expireAfterAccess 같은 정책을 조합

  
  ## 캐시 용어

• Cache Hit / Miss

  • 키로 조회했을 때 값이 존재하면 Hit, 없으면 Miss

• TTL(Time To Live)

  • 값이 캐시에 살아있는 최대 시간
  • 생성 시점 기준, 고정된 만료 시간

• TTI(Time To Idle)

  • 마지막 접근 이후 유휴 시간이 일정 시간 지나면 만료
  • 값을 조회하면 만료 시간 리셋

• Eviction

  • 용량 제한 및 정책에 의해 일부 키를 제거
  • 예시 알고리즘 -> LRU, LFU, FIFO, Random

• Warmup / Preload

  • 캐시를 미리 채워서 Cold Start를 완화

• Negative Caching

  • NULL(없는 값)도 캐싱해서 침투 방지

• Jitter

  • TTL에 랜덤 편차를 주어 동시 만료 방지

• Stampede / Thundering herd

  • 특정 키가 만료되는 순간, 방대한 요청이 동시에 Cache Miss 발생
  • 이로 인한 DB 과부하 발생
    
    

    2. 캐시 전략

1️⃣ Cache-Aside

애플리케이션이 캐시 조회
- Cache Hit -> 반환
- Cache Miss -> DB 조회
  - DB 결과를 캐시에 저장
  - 클라이언트에 반환

• 읽기:
  • 캐시 조회 -> Miss 시 DB 조회 -> 캐시에 추가 후 반환
• 쓰기:
  • DB에 저장 -> 캐시 Evict(무효화) 또는 Update(갱신)
• 가장 흔한 방식
• @Cacheable 어노테이션은 기본적으로, 이 모델을 메서드 단위로 편하게 쓰는 느낌
• 장점
  • 간단한 구현
  • 필요한 데이터만 캐싱
  • 메모리가 효율적
• 단점
  • 첫 요청 시 Cold Miss
  • 캐시 만료 시 Stampede 위험성 존재
    ## 2️⃣ Read-Through ``` App -> Cache -> DB ```
• 캐시가 DB 접근을 대신해서 수행
  • 애플리케이션은 캐시만 호출
• Cache Miss 시, DB에서 데이터를 가져와 자동으로 저장
• 장점
  • 단순한 코드
  • 데이터 접근 경로를 캐시로 통일
• 단점
  • 캐시 시스템 복잡
  • 특정 DB 로직 제어의 어려움
    ## 3️⃣ Write-Through ```

1. 데이터 쓰기 요청
2. 캐시에 기록
3. DB에 기록 ```

• 쓰기 시점에 캐시와 DB를 함께 갱신
• 장점
  • 캐시와 DB 간의 일관성을 항상 유지
  • 읽기 시 Cache Miss 확률 적음
• 단점
  • 쓰기 비용 증가
  • 잘 안 쓰이는 데이터도 캐시에 적재
    ## 4️⃣ Write-Behind (Write-Back) ```

1. 캐시에 기록
2. 즉시 응답
3. 배치/비동기로 DB에 반영 ```

• 캐시에 먼저 쓰고, DB에는 비동기로 나중에 반영
• 로그, 통계 등에서 주로 사용
• 장점
  • 쓰기 성능 향상
  • 배치 처리로 DB 부하 감소 가능
• 단점
  • 장애 시, 데이터 유실로 인한 정합성 이슈
  • 따라서, 강한 일관성을 보장하기 어려움
    ## 5️⃣ Refresh-Ahead
• 만료 이전에 미리 갱신
  • TTL 만료 이전, 백그라운드 갱신을 통해 히트율과 안정성을 높임
• 장점
  • Cache Stampede 방지
  • 일정한 응답 속도
• 단점
  • 불필요한 갱신 가능성 존재
    ## 6️⃣ Stale-While-Revalidate ```

1. 캐시 만료
2. 기존 값 응답
3. 비동기 갱신 ```

• 만료 시에도 오래된 값 먼저 응답
  • 동시에 백그라운드 갱신
• 데이터의 정합성 보다는, 가용성과 지연을 우선시하는 선택
  • 따라서, 확실한 데이터 정합성 보장 불가
• Cloudflare 같은 대규모 CDN에서 많이 사용
• 장점
  • 사용자 지연 최소화
  • 고트래픽 환경에 적합

‼️ 문제 상황

TTL 만료
-> 사용자 요청 1만 건이 동시에 발생
-> DB 조회 폭주
-> 지연/장애

• 이를 해결할 방법으로, 보통 2가지 선택지 존재

1. 최신성 보장
   • TTL이 만료되었으므로 DB에서 조회
   • 그동안 사용자 대기
   • 트래픽이 많으면 장애 위험 존재
2. Stale 허용
   • 일단 예전 값 응답
   • 백그라운드에서 새로 갱신
   • 이로 인한 사용자 지연은 0에 수렴

📌 대규모 트래픽 시스템은 보통 Stale 허용 방식을 선택

• 사용자는 느린 최신 데이터보다, 빠르고 조금 지난 데이터를 더 선호한다는 철학
• 특히 트래픽 폭주 상황에서는, 잠깐의 Stale 데이터보다 잠깐의 장애 발생이 훨씬 크리티컬
• 상품 목록, 통계, 조회수 등에서 사용 가능
  • 조금의 시간적 차이가 존재해도 치명적이지 않은 데이터
• 계좌 잔액, 재고 수량, 결제 상태 등에서는 사용하면 안됨
  • 강한 일관성이 필요한 부분이기 때문
    

💡 일반적으로 정합성 유지를 위해 다음과 같이 설계

Soft TTL -> 60초 (Stale 허용)
Hard TTL -> 5분 (Deadline)

• Soft TTL 초과 -> Stale 응답 + 백그라운드 갱신
• Hard TTL 초과 -> 무조건 DB 조회
• 이러한 방식으로 너무 오래된 데이터는 방지

캐시 전략 요약

  최근 데브코스 단기 심화 과정을 수료하며 여러 새로운 기술들과 개념들을 학습하고 있다. 약 한 달 여의 기간 동안 카프카를 비롯해 DDD(헥사고날 아키텍쳐) 와 MSA, 스프링 배치, 엘라스틱 서치 등의 개념들을 배우고 실습을 진행했다.

  현재는 이러한 기술들을 적용한 새로운 프로젝트를 진행하고 있으며, 필자는 현재 이 중 카프카, 엘라스틱 서치를 사용하고 있다. 이후 MS 분리 및 헥사고날 아키텍쳐로 마이그레이션을 진행할 예정이다.

  1차 스프린트가 종료되고 새로운 개념을 추가로 배웠는데, 해당 내용이 바로 AI 및 LLM과 RAG에 관한 내용이다. 이 지식들을 기반으로 프로젝트에 AI 기능을 추가해나갈 예정이다.

  원할하게 프로그램에에 해당 기능을 추가하기 위해서는 당연히, 적용하려는 AI에 대한 개념이 확실하게 잡혀있어야 한다. 강의를 통해 배운 내용을 토대로, 해당 개념을 정리해두기로 결정했다.

🤖 인공 지능

1. 약 인공지능

• 특정한 작업을 수행할 수 있도록 설계되어 있는 AI
• ChatGPT, 스팸 필터링, 얼굴 인식, 체스 바둑 등
• 범위를 벗어나면 작업 수행 불가능

2. 강 인공지능

• 사람이 가질 수 있는 지능, 지성 등을 컴퓨터의 정보처리 능력으로 구현한 시스템
  • 사람처럼 다양한 범위의 문제를 해결할 수 있는 범용 AI
• 아직 구현되지 않은 기술
  • 현재는 이론적으로만 존재
  • 아직 연구 단계

🪧 AI의 작동 방식

1. 규칙 기반 AI

• 사람이 명시적으로 정의한 규칙에 따라 작동하는 AI
  • ex) 나이에 따른 할인 적용
• 예측 가능한 범위 내에서 명확하고 정확한 결과 제공
  • 예측을 범어난 경우, 이러한 것들이 어려움

2. 학습 기반 AI

• 데이터로부터 스스로 학습하는 AI
  • 패턴을 찾아냄
  • ex) ChatGPT 같은 생성형 AI
• 굉장히 많은 데이터를 필요로 하며, 이를 처리하고 학습해야 하기 때문에 물리적인 리소스 많이 사용

3. 머신 러닝

• 데이터에서 패턴을 학습하여 명시적 규칙 없이 스스로 예측/분류 등을 수행하는 모델
• 텍스트 분류, 이미지 분류, 예측 모델, 추천 시스템 등 다양한 패턴 학습 문제를 해결
  • ex) 키워드 추출
    • 정해진 패턴에 따라 키워드를 추출
  • 결과를 나열
    • 정보를 전달해주기만 함

4. 생성형 AI

• 질문에 대한 대답을 넘어서서 맥락을 이해하고 부연 설명을 추가
  • 머신 러닝 중에서도 새로운 데이터를 생성하는 모델에 속하는 분야

5. 정통적 AI vs 생성형 AI

1️⃣ 정통적 AI

• 분석을 통해 일어날 일을 예측
• 특정 작업을 위해서 훈련이 되어있으므로, 그 작업에 대한 수행만 가능
  • 다른 작업을 위해서는 반드시 해당 작업에 대한 훈련이 다시 필요
• 입력 구조가 고정
  • ex) 정형화된 데이터, 특정 포맷의 이미지
  • 자연어처럼 자유로운 입력을 직접 다루는 건 불가능

2️⃣ 생성형 AI

• 존재하지 않는 텍스트, 이미지 등을 생성 가능
• 하나의 모델만으로 질문, 답변, 요약, 답변, 코드 생성 등 다양한 작업 가능
• 자연어로 구성된 문장만으로 작업을 수행 가능

🦖 LLM(Large Language Model)

1. LLM의 기본 원리

• 대규모 언어 모델
• 학습에 사용한 데이터의 패턴, 통계적 관계를 바탕으로 다음 단어를 예측
• 크게 2가지의 학습 단계로 구분
  • 그 외 다양한 단계들도 존재
• 하나의 문장을 여러 개의 토큰으로 분리 (토크나이징)
  • 각각의 토큰은 고유한 ID로 변환
• Attention Mechanism → 어떤 문장이 주어졌을 때 토큰 간 관계를 파악하여 문맥을 파악
• Temperature 값이 낮으면 토큰 다음 값이 확률이 낮으면 포함하지 않고, 높으면 토큰 다음 값의 확률이 낮아도 포함
  • ex) OpenAI Default → 0.8
• 확률을 통한 대답 생성을 수행

2. LLM의 학습 단계

1️⃣ 사전 학습

• 웹 페이지, 논문,공개된 코드 등 텍스트 데이터 활용
• 다음 데이터 예측 과제 제공
• 많은 컴퓨팅 자원 필요
• 모델이 커질수록 원천 데이터 양도 증가
• 데이터 중에는 부정확한 정보도 포함
• 데이터 규모가 커지면서 오류가 포함될 가능성 또한 존재

2️⃣ 미세 조정

• 사전 학습 이후 다시 한 번 학습시키는 과정
  • 강화 학습 (RLHF - Reignforcement Learning Human Feedback) 이후 이를 반영해 미세 조정

3. LLM의 구조적 한계

• LLM은 정확한 정보를 저장하고 검색하지 않고, 통계적으로 가장 그럴듯한 문장을 만들어내는 시스템
• 좋은 성능과 동시에 근본적인 한계점 존재
• 이를 환각(Hallucination) 효과라고 함

👁️ 환각(Hallucination)

1. 환각(Hallucination)

• LLM이 사실이 아닌 정보를 마치 사실인 양 자신있게 포함시키는 것
  • LLM은 질문을 받으면 항상 무언가를 생성
  • 학습했던 패턴을 조합하여 그럴듯한 대답을 생성
  • 하지만 사실 여부를 판단하지는 않으므로 정확하지 않은 정보 포함 가능
  • 또한 LLM은 본인이 학습한 시점까지의 데이터만을 가지고 있음
• 모르는 정보의 경우, 모른다고 이야기하지 않고 아는 지식의 조합을 통해 대답을 생성
  • 이로 인해 소비자는 정확하지 않은 정보를 정확한 정보인 양 전달 받는 경우가 있음
  • 버전이 올라가면서 없는 정보는 검색을 해보기 때문에, 비교적 적은 할루시네이션 효과 발생 (아예 발생하지 않지는 않음)
• Temperature 값이 높을수록 이러한 환각 효과가 더 자주 발생
• 맥락의 제한이 존재할 경우에도 발생
  • 윈도우 길이의 한계가 있기 떄문에 이 경우 오해 발생
• 학습 데이터의 편향과 오류가 존재하기 때문에, 이로 인해 환각 발생
  • 의도적으로 왜곡된 데이터도 존재하므로 위험성 또한 존재
• 기술적인 면에서 또한 이런 할루시네이션 현상이 존재
  • 존재하지도 않는 라이브러리 임포트
  • 그 외 존재하지 않거나 Deprecated된 클래스, 메서드, 잘못된 오버라이딩 등
  • 최신 버전일 *경우 모델이 *아직 학습하지 못했을 가능성이 있으므로, 더 자주 발생
• 이러한 환각 효과는 LLM의 구조적인 영향이므로 완전히 없앨 수는 없음
  • 이를 줄여가는 것이 최선책

2. Hallucination 감소 방법

• 구체적인 프롬프트 제공

  • ex)

    Spring Boot 3.4 버전에서,
    RestTemplate 대신 WebClient를 사용하는 방법을 예제 코드와 함께 설명해줘.
    
    모르면 모른다고 대답하고, 추측하지 말고 확실한 정보만 제공해

• RAG (Retrieval Augmented Generation)

  • 검색과 생성을 결합한 접근 방법

• 적절한 Temperature 생성

  • Temperature가 높을수록 할루시네이션 효과 발생 확률 증가
  • 그러므로, 적절한 Temperature 설정이 중요
  • ex) 사실적 정보가 중요하면 Temperature 값을 감소

🔩 프롬프트 엔지니어링

1. 프롬프트 엔지니어링

• 프롬프트를 설계하고 최적화하는 과정
  • 프롬프트 → 원하는 결과를 얻기 위해서 입력하는 텍스트
• 이렇게 최적화한 프롬프트를 통해 원하고자 하는 보다 정확한 결과를 얻고자 하는 것

2. 프롬프트 엔지니어링의 3원칙

• 프롬프트 엔지니어링의 기본 원칙은 크게 3가지가 존재

1️⃣ 명확성

• 프롬프트를 작성할 거면 모호한 표현은 피하고 원하는 표현을 구체적으로 작성

2️⃣ 맥락 제공

• LLM이 필요한 정보와 맥락을 충분히 제공해야 함

3️⃣ 구체화

• 복잡한 작업의 경우 단계별로 나누거나 정확한 정보를 제공해야 함

3. 프롬프트 템플릿

• 미리 정의된 프롬프트에 변수를 넣을 수 있도록 만들어둔 틀
  • 이를 통해 검증된 프롬프트를 표준화
• ex1)

• ex2)

• 크게 4가지 세션으로 구성

1️⃣ System Message

• LLM의 역할 및 기본 동작 방식 정의

2️⃣ Context

• 도메인 특화 정보
• 검색된 문서의 내용

3️⃣ User Input

• 사용자 입력 세션
• 사용자의 질문 및 요청 포함

4️⃣ Instructions

• 구체적인 명령

혹은 Instructions와 Output Format을 분리 가능

4. 프롬프트 템플릿 주의사항

• 변수 주입
  • 프롬프트 인젝션을 고려
    • 프롬프트 인젝션 → 악의적인 사용자가 시스템 지시사항을 무시하거나 변경시키는 것
• 토큰 제한
  • LLM이 처리할 수 있는 토큰의 총량
  • 토큰을 제한하여 시간당 사용할 수 있는 토큰 개수 부여
  • 문장이 길수록 토큰 사용량 증가
• 템플릿 관리 (=버전 관리)
  • 프롬프트를 관리할 수 있고 변경 이력을 추적할 수 있도록 설계
  • 템플릿에 변수 지정 및 런타임 시점에 실제 값을 바인딩

🔎 RAG(Retrieval Argmented Generation)

1. RAG

• 검색 증강 생성 (Retrieval Argmented Generation)
  • LLM이 답변을 생성하기 전에 먼저 검색과 자료를 참고하고, 그 이후 답변을 생성
• LLM은 한계점이 존재
  • 학습 시점 데이터 활용
  • 비공개 정보 활용 불가
  • 전문 도메인 지식 부재
  • 모델 학습의 요구 비용
• 모델 자체를 재학습시키지 않고도 외부 지식을 활용할 수 있는 방법
  • 사용자 질문 → 관련 문서 및 정보 검색 → 프롬프트에 포함 → LLM에 전달
  • 이를 통해 환각 효과를 크게 감소
    • 신뢰할 수 있는 결과 제공
    • 물론 환각 효과를 완전히 없애는 것은 현재로선 불가능

2. RAG 단계도

• 준비 단계 (Indexing)
  • 임베딩을 통해 데이터를 벡터로 변환
  • 벡터는 벡터 DB에 저장
• 검색 (Retrieval)
  • 벡터 DB의 벡터와 유사한 문서를 검색
    • 유사도 검색
  • 유사도가 높은 몇 문서들을 Chunk로 가져옴
    • 생성 시의 근거 자료
• 생성 (Creation)
  • 이전의 Chunk들을 기반으로 답변을 생성

3. 벡터 저장소

• 텍스트를 임베딩 벡터로 변환하여 저장하고, 필요할 때 의미적으로 유사한 데이터를 빠르게 검색할 수 있도록 도와주는 저장소
  • 고차원 공간에 배치된 벡터 간 거리를 계산하여 의미적으로 가까운 정보 획득
  • ex) Pincone, Weaviate, Chroma
• 일바적인 RDB로는 벡터 저장을 효율적으로 하기 어려움
  • 유사도 기반으로 빠르게 검사하기 어려움

4. 청킹

• 긴 문서를 작은 조각으로 나누는 과정
  • 임베딩 모델에는 토큰 제한이 있으므로, 나눠서 처리할 필요가 있음
• 섹션 별로 나눠서 임베딩 할 시 각 세션에 구체적인 내용이 비교적 잘 드러날 수 있음
• 고정 길이 방식
  • 몇 글자마다 잘라서 청크를 나누는 방식
  • 문단이나 문장의 경계를 무시
  • 문맥상 문제가 발생할 수 있으므로, 임베딩 시 원하는 결과가 담기지 않을 확률 존재
• 문장/문단 경계 방식
  • 자연스러운 단위로 청크를 나누는 방식
  • 자연스러운 문맥을 고려하여 임베딩하므로, 비교적 정교한 결과 제공
• 청크를 일정 부분 겹치게 만들면(Overwrap), 문맥 설치 방지 가능
  • 200 ~ 500 토큰 정도 오버랩이 적당하다고 알려져는 있으나, 비즈니스마다 달라질 수 있음

💾 임베딩(Embedding)

1. 임베딩(Embedding)

• 텍스트 데이터를 고차원 벡터로 변환
  • 단어나 문장의 의미를 숫자로 변환
  • 벡터는 간략하게, 여러 개의 숫자로 이루어진 배열 정보
• 의미가 비슷한 단어들은 비교적 비슷한 벡터로 치환
  • 이 벡터 간의 거리를 통해 단어 간의 유사도 측정 가능
• 임베딩은 딥러닝 모델을 통해 학습
• 임베딩 추론 예시

• 이러한 벡터 값들을 통해 유사도 검색을 진행 가능

• 유사도 보존

  • 단어 간의 의미 관계를 벡터 공간에서 근사적으로 보존

• 문맥 의존성

  • 같은 단어도 문맥에 따라 다른 벡터를 가질 수 있음
  • ex) 과일 사과 / 잘못이라는 의미의 사과

• 다국어 지원

  • 여러 언으의 단어들을 동일한 단어로 취급 가능

• 관계 표현 능력

  • 임베딩 된 단어 간의 산술 연산이 가능
  • 이로 인한 단어들의 관계 표현도 가능

• 불변성

  • 짧든 길든, 임베딩 결과는 모델이 표현 가능한 같은 차원의 벡터로 차원의 벡터로 치환
    • 1개의 단어든 100개의 단어든 모두 동일한 차원의 벡터로 치환

• 임베딩 모델

  • 임베딩을 수행하는 모델
    • Open AI → 텍스트 임베딩 3
    • 구글 → Gecko

2. 임베딩 유사도

1️⃣ 코사인 유사도

• 두 벡터가 가리키는 방향이 얼마나 비슷한지 측정
• 스프링 AI가 Default로 사용
• 장점
  • 벡터의 크기에 영향을 받지 않고 방향만 영향을 받음
  • 짧은 단어일수록 효과적인 반영 가능

2️⃣ 유클리디안 거리

• 두 벡터 사이의 직선 거리 측정
  • 두 점 사이의 거리를 구하는 피타고라스 정리를 고차원으로 확장한 것
• 벡터 크기에 영향을 받음

3. 인덱싱

• 벡터, 원본 텍스트 및 그 메타데이터들을 벡터 저장소에 저장하는 행위

4. 스프링 AI

• 임베딩과 Vector Store 기능을 이용해 RAG 구조를 구현
• 문서 길이가 길면 토큰 길이 제한에 걸리고, 너무 없으면 유사도가 낮으므로 적절한 개수로 가져오는 것이 중요
• 가장 간단한 RAG → 챗봇

  이전에 레디스 레플리케이션에 관한 실습 내용을 남겼다. 실습을 하고 기록을 남기면서도 느꼈지만, 확장을 위한 과정이기 때문에 반드시 알아야 하는 내용이었다.    그렇게 레플리케이션 내용을 마무리하고 나니, 연달아 중요한 내용이 나왔다. 레디스 클러스터라는 기능이다.

  레디스 클러스터는 일종의 샤딩으로, 노드별 슬롯 분배 뿐만 아니라, 내부 채널인 클러스터 포트(기본 포트 + 10,000)를 통해 클러스터 노드간의 메시지 교환, 슬롯 이동 등을 지원한다.    클러스터 내 각 샤드는 일반 레디스 노드와 마찬가지로 1개 이상의 마스터와 0개 이상의 레플리카를 가지고 있으며, 클러스터 노드 또한 마스터-레플리카 구조로 구성된다.

  실습을 위한 레디스 클러스터 관련 내용은 이 정도만 알고 있어도 큰 어려움이 없을 것이다. 이제 실습을 진행해보자.

📌 본 실습은 Windows 환경에서 WSL 을 통해 경량 가상 머신을 이용한 Linux 환경에서 진행

⌨️ 실습 진행

1. 레디스 클러스터 실습용 conf 파일 생성

• 클러스터용 디렉토리 cluster 로 이동
• 기존에 받아놨던 redis.conf 를 복사하여 redis-cluster.conf 생성
  

2. redis-cluster.conf 파일 수정

• cluster-enabled yes 를 통해 클러스터 모드 사용 허용
  

• requirepass {passwd} 로 비밀번호 설정
  

• enable-debug-command yes 를 통해 디버그 허용
  

• bind 0.0.0.0 을 통해 외부 컨테이너(서비스) 접근 허용
  

3. docker-compose.yml 작성

• docker-compose.yml 생성 및 작성
• 네트워크는 redis_network 로 지정
  • 부모 디렉토리가 cluster이므로, cluster_redis_network 라는 네트워크 생성 및 공유
    

4. docker-compose 이용해 6개의 node 서비스 시작

• 6개의 컨테이너 생성 확인
  

• docker-compose ps 명령어로 docker-compose로 실행중인 서비스 확인
  

• 컨테이너 실행 즉시 상태는 슬롯 미할당 상태
  

5. 클러스터 생성 및 레플리카 1개씩 지정

• redis-cli --cluster create [{ip(container_name)/port}..] --cluster-replica 1 -a {passwd} 명령어 사용
  • 클러스터 생성
    • 클러스터로 사용할 노드들 등록
  • 각 클러스터 노드 중 1대씩을 레플리카로 설정
  • 해당 컨테이너 접속을 위한 비밀번호 제출
    

• 총 16384개의 슬롯 생성 확인
  
  
  

🎯 트러블 슈팅 - 인증 실패 발생

TS1-1. 인증을 했음에도 NOAUTH(인증 실패) 발생

• -a {passwd} 로 비밀번호 입력을 했음에도 불구하고, 인증 실퍠 발생
  

TS1-2. 해결 - redis-cluster.conf 파일에서 masterauth 지정

• 클러스터 생성 및 분배는 문제 없지만, 레플리케이션 작업에서 문제 발생
• 마스터-레플리카 간의 레플리케이션에서는 마스터 데이터 동기화를 위해 레플리카에서 마스터의 비밀번호 인증이 필요하기 때문
• 따라서, redis-cluster.conf 파일에 masterauth {passwd} 지시자를 지정하여 레플리케이션 인증 문제 해결
  

TS1-3. 확인 - 각 클러스터 노드 정보 할당 확인

• 각 클러스터 노드에 epoch 번호, ip 등이 잘 할당됨을 확인
  

TS1-4. 확인 - 마스터-레플리카 간 데이터 동기화 확인

• 클러스터 마스터-레플리카 노드 간의 레플리케이션 동기화 완료 확인
  
  
  

6. 마스터 노드 레플리케이션 정보 확인

• cluster-node-1 마스터 노드로 클라이언트 접속
• info replication 으로 레플리케이션 정보 확인
• 레플리카 1대 존재 확인 및 레플리카 노드 관련 정보 확인 가능
  

7. 레플리카 노드 레플리케이션 정보 확인

• cluster-node-6 레플리카 노드로 클라이언트 접속
• info replication 으로 레플리케이션 정보 확인
• 레플리카 노드라는 것과 마스터 노드 관련 정보 확인 가능
  

8. 클러스터 노드 정보 확인

• cluster nodes 로 클러스터 노드 정보 확인
• 현재 총 3대의 마스터, 3대의 레플리카가 존재함을 확인
  • 슬롯 또한 다 분배되어있음을 확인
    

9. 클러스터 샤드 정보 확인

• 현재 클러스터 샤드 정보 확인
• 사진에는 나오지 않았지만, 총 3개의 샤드 존재
  

10. 클러스터 노드 8개로 확장

• docker-compose down 후 docer-compose up --scale node=8 로 노드를 8개로 확장
  

• 기존 노드들은 정상 상태이지만 node-7 과 node-8 은 슬롯 미할당 상태임을 확인
  

11. 새로 생성된 노드7의 현재 노드 정보 확인

• cluster-node-7 컨테이너 접속 후 cluster nodes 로 노드 정보 확인
• 현재 노드는 마스터이지만 슬롯 미할당 상태임을 확인
  • 원래대로면 connected 옆에 할당된 슬롯 번호들이 있어야 함
  • 8번 항목 참고
    

12. 노드7을 기존 노드1의 클러스터에 추가

• --cluster add-node {addedNode} {orgNode} 명령어로 기존 클러스터에 레디스 노드 추가
  • 새로운 노드가 클러스터에 추가
    

• 7번 노드가 정상적으로 클러스터에 등록됨을 확인 가능
• 하지만 여전히 8번 노드는 클러스터에 등록되지 않음
  • <search> Got no slots in CLUSTER SLOTS -> 아직 클러스터에 속하지 않았다는 의미
  • 해당 노드는 현재 자신 외 다른 노드나 슬롯 정보를 알 수 없음
  • 따라서 CLUSTER SLOTS 명령 시 빈 배열 반환
  • 그래서 슬롯 정보가 없다는 메시지를 출력하는 것
    

• 7번 마스터 노드가 클러스터에 추가
  • 하지만 여전히 슬롯은 미할당 상태
    

13. 노드8을 노드7의 클러스터에 추가

• 8번 노드를 7번 노드에 추가
• --cluster-slave 지시자를 추가하여 8번 노드가 7번 노드의 레플리카임을 지시
  

• 8번 레플리카 노드가 클러스터에 추가
• 7번-8번노드 간의 레플리케이션 정상 동작
  • 데이터 동기화 완료 확인
    

• 7번 노드에서 info replication 으로 레플리케이션 정보 확인 가능
  

• 7번 노드에서 cluster info 로 클러스터 정보 확인
• cluster_known_nodes:8 을 보아, 노드는 8개로 확장됨이 확인
• 하지만 cluster_size:3 을 보면, 현재 클러스터의 샤드는 4개로 확장되지 않고 여전히 기존의 3개임을 확인 가능
  

• 7번 노드에서 cluster nodes 로 클러스터 내 노드 정보 확인
• 클러스터에 총 8개의 노드가 존재
  • 하지만 여전히 7번 마스터 노드에는 슬롯 미할당
    

14. 노드7에 슬롯을 할당하고 샤드 슬롯 재분배

• reshard {desIP/desPort} 를 통해 샤드 슬롯 재분배 진행
• 총 3가지 질문에 대답
  • How many slots do you want to move (from 1 to 16384)? :
    • 대상 노드에 분배할 슬롯의 양
    • 존재하는 슬롯 개수 16384를 분배될 샤드 4개로 나눈 4096으로 지정
  • What is the receiving node ID? :
    • 분배받을 노드 ID
    • cluster nodes 에서 확인한 7번 노드의 ID 입력
  • Please enter all the source node IDs :
    • 노드에 슬롯을 분배하기 위해 슬롯을 일부 가져올 노드의 ID
    • all 을 입력하여 나머지 모든 노드 슬롯 재분배
      

• cluster nodes 를 통해 클러스터 내 노드 정보 확인
• 기존 노드들에서 4096 / 3 만큼의 슬롯이 차감됨을 확인
• 7번 노드는 나머지 3개의 노드들로부터 가져온 슬롯들을 분배 받음을 확인 가능
  • 0-1364 5461-6826 10923-12287
    

Reference :

• 실전 레디스 : 기초, 실전, 고급 단계별로 배우는 레디스 핵심 가이드

• ChatGPT ( https://chatgpt.com/ )

  최근 레디스 개념 및 원리, 핵심 기능 등을 확실하게 이해하고 자바 스프링에 녹여넣을 수 있도록, 실전 레디스 : 기초, 실전, 고급 단계별로 배우는 레디스 핵심 가이드 라는 도서를 읽고 있다.

 본 도서를 읽으면서 스냅샷, AOF 등의 영속성이나 레디스의 각종 자료형과 명령어, 보안 기능이나 트랜잭션처럼 일관 처리(레디스의 경우에는 롤백은 불가능) 등 여러 개념들을 알게 되었다.

 그렇게 책을 읽으며 실습하던 중, 마스터-레플리카(마스터-슬레이브 구조와 동일하지만, 최근에는 슬레이브라는 단어가 노예라는 말을 뜻하기 때문에 사용하지 않으려는 추세라고 함) 레플리케이션 파트에 돌입했다.    해당 파트는 자바 스프링 백엔드 개발자로서의 스택을 쌓고 있는 필자가 레디스를 사용한다면 반드시 알아둬야 할 부분이라고 생각하여, 진행한 실습을 블로그에 정리해두기로 결정했다.

📌 본 실습은 Windows 환경에서 WSL 을 통해 경량 가상 머신을 이용한 Linux 환경에서 진행

⌨️ 실습 진행

1. wget을 통한 redis.conf 설치

• wsl 환경에서 redisDocker 라는 프로젝트 디렉토리 생성
• redis-server --version 을 통해, 설치된 레디스의 버전을 확인
  • 노트북에서 apt install redis 로 설치한 레디스 버전이 7.4.1임을 확인
  • 데스크탑에서는 8.2.2 버전이 설치된 것으로 보아, 최신 버전으로 설치되지는 않았음을 확인
  • 사실상 레디스 7 버전부터는 기능 사용에 큰 차이가 없으므로, 그대로 진행
• wget https://raw.githubusercontent.com/redis/redis/{version}/redis.conf 로 레디스 기본값으로 사용되는 redis.conf 파일 다운로드
  • 레디스 버전(7.4.1)을 {version} 에 적용
    
• ls 명령어로 redis.conf 파일이 제대로 다운로드 되었음을 확인
  

2. 기존 설정 파일을 복사하여 마스터용 conf 파일과 레플리카용 conf 파일 생성

• cp {src} {dest} 명령어를 통해 기존 redis.conf 파일을 그대로 복사
• ls 명령어로 복사 확인
  

3. 마스터용 conf 파일에 requirepass로 비밀번호 지정

• vi redis-master.conf 로 문서 편집
• requirepass {passwd} 를 추가하여, Auth 보안 인증에 사용할 패스워드 적용
  • 이후부터 마스터 클라이언트에서 명령어를 사용하려면 해당 패스워드를 통한 인증 필요
    

4. 마스터용 conf 파일에 debug-command 허용

• 이후 debug 기능을 사용하기 위해, enable-debug-command 를 변경
  • no -> yes
    

5. 레플리카용 conf 파일에 masterauth 지정

• vi redis-replica.conf 로 문서 편집
• masterauth {passwd} 를 추가하여, 마스터 노드 접근을 위해 필요한 인증 비밀번호 추가
  • redis-master.conf 에서 설정한 비밀번호와 동일
    

6. 레플리카용 conf 파일에 replicaof 지정

• replicaof {master-name} {port} 지정
  • 추후 마스터 컨테이너 이름을 redis-master 로 지정할 예정이므로 해당 이름 지정
  • 레디스 기본 포트인 6379 지정
    

7. docker-compose.yml 파일 작성

• 로컬 환경에서 여러 컨테이너 기반 서비스를 동시에 구성하기 위해서 docker-compose 사용
  • docker-compose -> 여러 컨테이너를 정의하고 한꺼번에 실행/관리할 수 있는 도구
• vi docker-compose.yml 명령어로 파일 편집 및 파일 생성
  • services: -> 사용할 서비스 명시
  • master: , replica: -> 각 서비스명, container_name: 을 명시하지 않으면 컨테이너 이름이 {프로젝트명}_{서비스명}_{번호} 형식으로 설정
  • image: -> 사용할 컨테이너 이미지
  • ports: -> 사용할 포트
    • {로컬 포트}:{컨테이너 포트}
    • 로컬에서 접속할 포트:컨테이너 내부에서 서비스가 리스닝하는 포트
  • volumes: -> 볼륨 마운트를 통한 파일/디렉토리 동기화
    • {동기화 할 파일 및 경로}:{컨테이너에 동기화되어 저장될 파일 및 경로}
    • $PWD 로 현재 docker-compose.yml 이 있는 디렉토리를 절대 경로로 치환
  • command: -> 컨테이너 시작 시 실행할 명령어
    • redis-server {사용 설정 파일 및 경로} -> 컨테이너 시작 시 마운트된 볼륨 설정 파일을 기반으로 레디스 서버 시작

🎯 트러블 슈팅 - 레디스 서버 포트 충돌

TS1-1. 포트 충돌 발생

• 6379 포트가 사용중이라는 메시지와 함께 에러 발생
  

TS1-2. 레디스 서버 종료 시에도 자동 재시작

• sudo lsof -i :6379 명령어로 현재 6379 포트를 사용하고 있는 프로세스 목록 추출
• sudo kill {PID} 명령어로 해당 프로세스 강제 종료
• 새로운 PID로 레디스 서버가 다시 띄워져있는 것을 확인
  

TS1-3. systemd 내부의 레디스 서비스 파일 확인

• /etc/systemd/system/redis.service 파일을 확인
  

TS1-4. 레디스 서비스 파일의 Restart 옵션 변경

• Restart 옵션은 서버 종료 시 자동 재시작 여부
  • Restart=always 가 초기값으로 설정되어 있음
  • Restart=no 로 변경하여 서버 종료 시 자동 재시작 거부
    

TS1-5. 해결 - 레디스 서버 자동 재시작 미진행 확인

• systemd 변경 적용을 위해 sudo systemctl daemon-reload 진행
• 레디스 설정을 변경했으므로, sudo systemctl restart redis 로 레디스 서버도 재시작
• sudo systemctl status redis-server 로 현재 레디스 서버 상태 확인
  • Active: active (running) 확인 (동작 중)
• 해당 프로세스 확인 및 강제종료
• 6379 포트 사용 프로세스 재확인
  • 사용되지 않음을 확인!
    
    
    

8. docker-compose up 정상 실행 확인

• docker-compose up 명령어로 docker-compose.yml 파일 기반 도커 엔진 실행
  • 도커 엔진은 디렉터리명을 프로젝트명으로 사용하여, 각 서비스에 대한 컨테이너 생성 및 실행
    

9. Docker Desktop 에서 컨테이너 생성 확인

• redisDocker 의 docker-compose.yml 파일을 이용했으므로, 해당 디렉토리명을 프로젝트명으로 삼아 각 서비스 컨테이너 생성 및 실행
  • 지정해준 컨테이너명과 포트 등이 잘 적용되어 서버가 실행되고 있음을 확인
    
    
    

🎯 트러블 슈팅 - 마스터-레플리카 커넥션 거부

TS2-1. 레플리케이션에서 마스터-레플리카 간의 커넥션 거부

• 각 서비스는 잘 실행되었으나 커넥션 관련 에러 발생
  • ERROR condition on socket for SYNC: Connection refused
  • RDB파일 동기화를 위한 소켓 연결 자체가 거절되었다고 유추됨
    

TS2-2. 마스터용 conf 파일에서 bind 지시자 확인

• bind 127.0.0.1 확인
• 로컬과의 연결만 허용하는 것이기 때문에, 외부 컨테이너에서의 연결은 비허용
  • 따라서, 마스터-레플리카 간의 연결은 서로 다른 컨테이너(서비스)이기 때문에 연결 비허용
  • 둘은 같은 네트워크 상에 있음에도 불구하고, 127.0.0.1 은 각 컨테이너의 내부 주소이므로 컨테이너 자신을 제외한 외부 컨테이너는 접근 불가능
    

TS2-3. 해결 - 마스터용 conf 파일 bind 지시자 수정

• bind 0.0.0.0 으로 수정하여 외부 컨테이너의 접속 허용
  

TS2-4. 해결 - 마스터용 conf 파일 protected-mode 지시자 확인

• protected-mode yes 인 경우, 보안 강화 모드로 작동하기 때문에, 기본적으로 외부 컨테이너 접속을 차단
  • 컨테이너 내부 접속이거나 requirepass 혹은 ACL이 설정되어 있는 경우 동작 허용
  • 그 외의 경우 연결 모두 거부
  • 즉, 외부 연결을 오픈했는데 비밀번호도 없는 경우에는 연결 거부
  • protected-mode yes 가 기본값
• 현재 bind 0.0.0.0 으로 외부 컨테이너 접속 허용 상태이므로 protected-mode yes 설정을 통해, 반드시 인증을 진행해야만 접속할 수 있도록 설정
  
  
  

10. 마스터-레플리카 정상 연결 및 데이터 복사 확인

• 마스터-레플리카 간의 연결이 제대로 성사되었음을 확인
• RDB 동기화가 성공적으로 되었음을 확인
  • Synchronization with replica 172.18.0.3:6379 succeeded
  • 레플리카는 기본적으로 마스터의 스냅샷인 RDB 파일을 비동기적으로 복사하는 방식으로 데이터 동기화 진행
  • AOF 파일을 통해서도 레플리케이션이 가능하지만, 기본적으로 RDB 스냅샷 파일을 통한 레플리케이션 진행
    

11. 마스터에서 레플리카로 핑을 보내는지 확인

• 레플리카 쉘에 접속 후, 레디스 클라이언트에서 monitor 명령
• 기본값인 10초 간격으로 마스터인 172.18.0.2:6379 로부터 ping 이 호출되고 있음을 확인 가능
  

12. 마스터에서 레플리케이션 관련 정보 확인

• 마스터 클라이언트 접속 후 info replication 명령 수행
  • 인증 없이 명령 불가능하므로, auth {passwd} 를 사용하여 인증 수행
• role:master 를 통해 마스터 노드임을 확인 가능
• connected_slaves:1 을 통해, 연결된 레플리카가 1대임을 확인
  • 해당 레플리카 관련 정보 또한 표시
• 그 외, 페일오버 전략 등 레플리케이션 관련 정보들을 확인 가능
  • 페일오버 : 마스터 노드 연결 문제 발생 시, 보유하고 있는 레플리카로 마스터 역할을 승격 작업
  • no-failover 이므로, 페일오버 전략은 따로 설정되지 않음
    

13. 레플리카에서 레플리케이션 관련 정보 확인

• 레플리카 클라이언트 접속 후 info replication 명령 수행
• role:slave 를 통해 레플리카 노드임을 확인 가능
• 해당 레플리카의 마스터 관련 정보들 확인 가능
  • 호스트, 포트, 상호 연결 상태 등
• slave_read_only:1 을 통해 레플리카가 읽기 전용 모드인지 확인 가능
  • 1은 읽기 전용, 0은 읽기/쓰기 모두 가능
• 마찬가지로 페일오버 전략 또한 확인 가능

Reference :

• 실전 레디스 : 기초, 실전, 고급 단계별로 배우는 레디스 핵심 가이드

• ChatGPT ( https://chatgpt.com/ )

  최근 레디스에 대한 개념을 확실하게 이해하고 개발에 사용하기 위해서, 실전 레디스 : 기초, 실전, 고급 단계별로 배우는 레디스 핵심 가이드 도서를 읽으며 내용을 이해하고, 실습하고 있다.

  여러 개념들을 알아가던 중, 굉장히 눈에띄는 문구가 있었다.

레디스 최악의 사례 7가지

  이 얼마나 폭력적인 문장인가. 딱 봐도 레디스 기술 사용에 있어서 굉장히 중요한 요소임을 강조하는 듯하다.

  그런 의미에서, 해당 내용을 블로그에 정리해두기로 결정했다.

1️⃣ 비밀번호 미설정

• 많은 경우, 레디스에서 비밀번호를 설정하지 않음
• 비밀번호를 따로 설정하지 않는다면, 해당 레디스에 접속한 어떤 사람이든지 레디스 명령어 사용 가능
  • 레디스 설정을 바꾸거나, 데이터 삭제, 디도스 공격 등 일어나서는 안 되는 일들이 벌어질 수 있음
  • 해킹에 매우 취약

💡 반드시 비밀번호를 설정하자

# redis.conf
requirepass {passwd}

• 사용하는 conf 설정 파일에서 requirepass 를 반드시 지정
  • 해당 비밀번호를 통해 인증해야만, 레디스 명령어 사용 가능
    

# redis-cli 에서 명령어 실행하려면
AUTH {passwd}

• redis-cli 등 클라이언트에서 명령어를 실행하기 위해서는, 반드시 AUTH 를 통해 인증이 완료되어야 함
  • 비밀번호 없이는 레디스 명령어 사용 금지
    

2️⃣ KEYS 명령어 사용 금지

• KEYS {pattern} : 레디스 서버에서 사용 중인 키들을 전부 확인하는 명령어
• 키의 개수가 많아지면 많아질수록 성능에 큰 영향

🤔 WHY

• 레디스는 기본적으로 단일 스레드 구조
  • KEYS 실행 중 다른 작업들은 전부 블로킹
• KEYS 의 시간복잡도는 O(N)
• 최대 2의 32승개의 키를 저장 가능
  • 최악의 경우 2의 32승의 시간복잡도
• 운영 환경에서 잘못 사용한다면, 한 번의 KEYS 명령으로 레디스 서버 전체가 몇 초 ~ 수십 초간 블로킹될 가능성 존재

💡 SCAN 명령어를 사용하자

SCAN 0 MATCH user:* COUNT 100

• SCAN 명령어는 기본적으로 비동기적 조회
  • 서버를 블로킹하지 않음
• SCAN 명령어와 인덱스, 카운트 개수를 여러 번 호출하여, 전체 키를 천천히 순회
• 배치 처리와 유사
  

3️⃣ SELECT - 번호 기반 DB 사용

• SELECT {번호} 명령을 사용하면 레디스 내의 각자 다른 데이터베이스를 사용할 수 있음
  • ex) SELECT 0 , SELECT 1
  • 0-based-index
• 하지만 이런 번호 기반 데이터베이스들은 완전 부리된 데이터베이스가 아님
  • 논리적으로만 다른 데이터베이스

🤔 WHY

• 같은 키:값이 DB 0, DB 1에서 각각 별도로 존재할 수 있지만, 내부적으로는 동일한 레디스 인스턴스 자원(CPU, 메모리, 이벤트 루프 등)을 공유
  • DB 0에서 KEYS 명령을 사용하면, 이 명령은 레디스 인스턴스의 이벤트 루프를 블로킹하므로, 같은 인스턴스 내 데이터베이스 또한 모두 블로킹
  • 즉, 독립적인 것처럼 보여도 실제 격리/스케일링 측면에서는 전혀 독립적이지 않음
• 기술적인 면에서 또한, 클러스터 환경에서는 번호 기반 데이터베이스 미지원
  • 단일 노드에서만 정상 동작 가능
  • 확장 불가
• 즉, 확장성, 안정성 측면에서 심각한 제약 초래
• 레디스 창시자 Salvatore Sanfilippo 또한, "레디스에서 만든 최악의 디자인 실수" 라고 평가할 정도

💡 번호 기반 DB 대신, 레디스 인스턴스를 새로 띄워 분리하여 운영하자

• 레디스는 인스턴스 하나당 메모리 오버헤드가 낮음
• 따라서 레디스 서버를 따로 띄워 인스턴스를 추가하고 클러스터 버스라는 내부 채널 안에서 노드 간 통신을 하는 레디스 클러스터 방식을 사용하면, 샤딩을 통한 데이터 분리 및 MOVED 명령을 통한 해당 데이터 소유 캐시 노드로의 자동 리다이렉션 또한 가능
  

4️⃣ HGETALL, LRANGE 같은 무제한 반환 주의

• 레디스 명령어 중 일부는 모든 데이터를 한 번에 반환
  • HGETALL : Hash 자료형의 모든 field/value 반환
  • LRANGE 0 -1 : List 자료형의 모든 요소 반환
    • 레디스에서 오프셋에 사용되는 0 은 시작 인덱스이며, -1 은 마지막 인덱스
  • SMEMBERS : Set 자료형의 모든 요소 반환
  • ZRANGE 0 -1 : Sorted Set 자료형의 모든 요소 반환
  • etc)...

🤔 WHY

• 매우 큰 데이터 구조
  • Hash : 필드 수 최대 2의 32승, 값 최대 512MB
  • List : 요소 수 최대 2의 32승, 값 최대 512MB
  • Set / Sorted Set : 요소 수 매우 많을 수 있음
• 사용 데이터가 누적된다면 기존 예상보다 훨씬 큰 데이터 구조가 될 가능성 존재
• 이러한 데이터를 한꺼번에 모두 가져온다면, 최악의 경우레디스 서버 자체가 다운

💡 크기를 먼저 체크한 후, 필요한 범위 내에서만 조회하자

• 데이터 크기 확인
  • Hash : HLEN {key}
  • List : LLEN {key}
  • Set : SCARD {key}
  • Sorted Set : ZCARD {key}
• 필요한 만큼만 부분 조회
  • List : LRANGE {startIdx} {endIdx}
  • 그 외 : {Xxx}SCAN ...
    

5️⃣ 하나의 커넥션 당 하나의 명령은 비효율적

• 대부분의 네트워크 통신 사용 기술에서 공통적으로 명시되는 명제
• 레디스는 지속 연결 활용을 전제로 설계
  • 레디스 클러스터 사용 시 :
    • OSS Cluster API -> 클라이언트가 노드별 연결 유지
    • Redis Enterprise -> 프록시를 통한 연결 관리, 클러스터 복잡성은 숨김 처리
• 매 연결 생성 및 해제 시 오버헤드 발생
  • 지속 연결 활용 불가능

💡 지속 연결을 활용하자

• 연결은 열어둔 채 여러 명령을 수행
• 필요 시 커넥션 풀 활용
• REST 스타일 연결 패턴은 피할 것
  • 요청마다 연결 및 해제하기 때문
    

6️⃣ Hot Keys 문제

• 레디스는 자주 접근되는 핵심 데이터를 저장할 때 효율 상승
• 그렇지만 특정 몇 개의 키만 반복해서 접근하게 되면 Hot Keys 문제 발생

🤔 WHY

• 레디스 클러스터 구조에서는 키가 데이터 저장 위치를 결정
  • 키 해싱을 통해 슬롯 위치를 판단하고, 해당 슬롯을 어느 샤드에 분배할지 결정
• 하나의 키에 요청 집중 시 :
  • 해당 특정 노드에 모든 트래픽 집중
  • 클러스터 내의 나머지 노드는 미활용
  • 병목 현상 발생

💡 작은 수의 자주 쓰는 키 집중을 피하자

• 설계 단계에서 Hot Key 패턴을 방지
  • 키 분산 설계
  • 동일 데이터를 여러 키에 분산 저장
  • 즉, 서로 다른 샤드에 배치
  • etc)...
    

7️⃣ 레디스를 주 DB 로 사용할 때 주의

• 레디스를 주 DB로 사용하는 경우, 다운되면 전체 애플리케이션 중단
• 단순한 레디스 기본 설정으로는 안정적인 주 DB 역할은 기대하기 어려움

💡 적절한 HA와 Durability를 설정하자

• 고가용성 (High Availability)
  • OSS Redis -> Redis Sentinel 설정
    • 모니터링을 통해 마스터 서버 정상 연결 유무 확인
    • 페일오버를 통해 마스터 서버 장애 시 레플리카를 마스터로 자동 승격
    • 클라이언트에게 승격된 마스터 IP를 마스터 서버로 알림
    • 이러한 과정을 통해, 한 대의 레디스 서버가 죽더라도 서비스 미중단
• 영속성 (Durability / Persistence)
  • OSS Redis -> RDB 스냅샷 또는 AOF 파일 사용
    • 해당 파일들이 일종의 백업 DB 파일
    • 레디스는 기본적으로 인-메모리 방식이므로 휘발성 메모리(RAM)를 사용하지만, 해당 파일들로부터 데이터를 불러오는 것이 가능
      

📌 Redis Enterprise 를 사용하는 경우, 별도의 설정 없이도 멀티 노드 클러스터, 복구, 백업이 모두 자동화되므로 바로 주 DB로 사용 가능

Reference :

• https://redis.io/blog/7-redis-worst-practices

• 실전 레디스 : 기초, 실전, 고급 단계별로 배우는 레디스 핵심 가이드
• ChatGPT ( https://chatgpt.com/ )

 본 포스트는 학습 중 생긴 궁금증 해결 및 아이디어 검증에 관한 내용을 정리 및 공유용도가 아닌 기록 용도로 작성하였습니다. 학습 Q&A 태그 포스팅은 동일하게 아래와 같이 진행될 예정입니다.

• 학습 중 생긴 여러 아이디어가 실현 가능한지 확인한 결과를 보관

• 학습 중 생긴 궁금증을 해소한 과정 및 결과를 보관
• 추후 개발에 해당 아이디어들을 참고하기 위한 기록 용도이므로 구조가 자유롭고 다소 두서없을 수 있으며, 자유롭게 작성

Q1. @Scheduled 메서드는 동기로 실행될까, 비동기로 실행될까?

A1. 동기 로 실행

• 기본적으로 @Scheduled 메서드는 동기로 실행
  
  

Q2. @Scheduled 메서드를 사용할 때의 기본 스레드풀 타입 과 생성 전략 은 무엇일까?

A2. DefaultManagedTaskScheduler 사용

• 별도의 설정이 없다면, DefaultManagedTaskScheduler 를 생성
• 내부적으로 SingleThreadScheduledExecutor 를 스레드풀로 사용
  • 오직 하나의 스레드만 생성
  • 해당 스레드만 스레드풀에 저장 후 재사용
• 모든 @Scheduled 메서드는 해당 스레드풀에서 관리
  
• 따라서 @Scheduled 메서드는 기본적으로 동기로 실행되므로, 한 @Scheduled 메서드가 실행 중이면 완료시까지 다른 메서드들은 실행되지 못함
  • @Scheduled 메서드가 비슷한 시간에 여러 개 작성되어 있을 경우, 문제가 발생할 수 있음
    
    

Q3. @Scheduled 용 스레드풀을 만들 때 반환 타입 은?

A3. TaskScheduler 인터페이스, 혹은 ThreadPoolTaskScheduler

• @Scheduled 메서드는 내부적으로 ScheduledAnnotationBeanPostProcessor -> TaskScheduler 인터페이스를 기준으로 동작
• ThreadPoolTaskScheduler 는 TaskScheduler 인터페이스의 구현체
• 보통 ThreadPoolTaskScheduler 타입으로 반환
  • 빈 등록 시 인터페이스 타입으로 반환하는 것이 일반적
  • 하지만 TaskScheduler 는 기능이 제한적
  • ThreadPoolTaskScheduler 를 사용하면 구체 클래스 설정 편리
    

@Scheduled 메서드가 자동으로 등록하는 스레드풀 빈 이름

• @Scheduled 메서드는 taskScheduler 라는 이름의 스레드풀 빈을 먼저 탐색 후 사용
• 메서드명을 taskScheduler 로 설정하여 빈으로 등록하면, @Scheduled 메서드에서 이 스레드풀 빈을 자동으로 DI 받아서 사용

Q4. @Async 메서드의 기본 스레드풀 타입 과 생성 전략 은 무엇일까?

A4. SimpleAsyncTaskExecutor 사용

• 별도의 설정이 없다면, SimpleAsyncTaskExecutor 를 기본 스레드풀로 지정
• 매번 새로운 스레드를 생성
  • 즉, 스레드를 재사용하지 않음
  • 요청이 많을 경우, 그만큼의 스레드를 새로 생성하여 작업하므로 성능 저하 또는 OOM 발생 가능
  • 매 스레드는 작업 종료 시 반납되어 GC 에 의해 처리가 되기는 함
    
    

Q5. @Async 용 스레드풀을 만들 때 반환 타입 은?

A5. Executor 사용

• @Async 메서드는 내부적으로 AsyncExecutionAspectSupport -> Executor 인터페이스를 기준으로 동작
• 보통 Executor 타입으로 반환
  • 일반적으로 빈 등록 시 인터페이스 타입으로 반환
  • 해당 인터페이스 타입 그대로 반환해도 충분
    

@Async 메서드가 자동으로 등록하는 스레드풀 빈 이름

• @Async 메서드는 taskExecutor 라는 이름의 스레드풀 빈을 먼저 탐색 후 사용
• 메서드명을 taskExecutor 로 설정하여 빈으로 등록하면, @Async 메서드에서 이 스레드풀 빈을 자동으로 DI 받아서 사용
  
  

Q6. @Async 스레드풀에는 QueueSize 를 정의하고, @Scheduled 스레드풀에는 QueueSize 및 MaxPoolSize 를 정의하지 않는 이유

A6. 자체 관리 및 예측 가능 하기 때문

• 사용자 요청으로 인한 @Async 메서드와는 달리, @Scheduled 메서드 실행 수는 개발자가 충분히 예측 가능
• 따라서 CorePoolSize 만 설정해줘도 충분
  • 문제 발생 시 CorePoolSize 만 조금씩 증가
• QueueSize 의 경우, ThreadPoolTaskScheduler 는 내부적으로 ScheduledThreadPoolExecutor 사용
  • ScheduledThreadPoolExecutor 는 대기 큐를 자체적으로관리
    

🎯 따라서 별도의 큐 설정은 불필요하며, setPoolSize() 로 풀 사이즈만 조정해주면 된다.

💡 관련 토픽 아이디어

📌 @Async 메서드용 커넥션풀_과 _@Scheduled 메서드용 커넥션풀 을 직접 지정하여 사용

@Configuration
@EnableAsync
@EnableScheduling
public class ThreadPoolConfig {

    private final int core = Runtime.getRuntime().availableProcessors();

    @Bean
    public Executor taskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        executor.setCorePoolSize(core);
        executor.setMaxPoolSize(core * 10);
        executor.setQueueCapacity(1000);
        executor.setThreadNamePrefix("async-");

        return executor;
    }

    @Bean
    public ThreadPoolTaskScheduler taskScheduler() {
        ThreadPoolTaskScheduler scheduler = new ThreadPoolTaskScheduler();
        scheduler.setPoolSize(core * 2);
        scheduler.setThreadNamePrefix("scheduler-");

        return scheduler;
    }
}

• taskExecutor 빈은 @Async 메서드에서 자동으로 사용
• @Async 메서드는 일반적으로 I/O 바운드 작업일 확률이 높으므로, maxPoolSize 를 core * 10 으로 설정
  • 일반적으로 코어 수 * 10 까지는 안전하게 실행 가능
  • 그럼에도, 스레드풀 관련 작업은 모니터링 및 성능 테스트 진행 권장
• queueCapacity 는 1,000 으로 설정
  • 해당 큐에는 스레드가 바쁠 때 대기할 작업들을 보관
  • I/O 바운드 작업일 확률이 높으므로, 어느정도 넉넉하게 1,000개로 설정
  • 마찬가지로 모니터링 및 성능 테스트 권장
• taskScheduler 빈은 @Scheduled 메서드에 자동으로 사용
• @Scheduled 메서드는 예약 작업이므로, 개발자가 어느 정도 실행될지 예상 가능
  • corePoolSize 를 core 수 만큼, 혹은 넉넉하게 core * 2 로 설정
  • @Scheduled 로 설정한 작업이 많다면 그에 비례해 성능 테스트 및 부하 테스트 진행해가며 조율
• ThreadNamePrefix 를 async-, scheduler-로 구분
  • 디버깅 편리
    
    

📌 각 용도의 스레드풀을 명시적으로 지정하는 방법

// ...
public class ThreadPoolConfig implements AsyncConfigurer, SchedulingConfigurer {
    // ...

    // @Async 전용 스레드풀 지정
    @Override
    public Executor getAsyncExecutor() {
        return taskExecutor();
    }

    // @Scheduled 전용 스레드풀 지정
    @Override
    public void configureTasks(ScheduledTaskRegistrar registrar) {
        registrar.setScheduler(taskScheduler());    // taskScheduler() 반환 타입을 Executor 로 변경
    }
}

• 각 인터페이스를 구현
• getAsyncExecutor() 에서 생성한 스레드풀 반환
  • @Async 메서드 전용 스레드풀로 사용
• configureTasks() 에서 스케쥴러에 사용할 스레드풀 지정
  • taskScheduler() 반환 타입을 기존 ThreadPoolTaskScheduler -> Executor 로 변경
    • 사용될 스레드풀을 지정해주기 위함
  • registrar.setScheduler 에서 해당 스레드풀 사용하도록
    
    

‼️ 처음 방식으로 충분히 구현할 수 있으므로, 추천하는 방식은 아님

💡 설정에 사용될 코어 수 제한 등의 값들은 설정 파일과 @ConfigurationProperties 조합을 이용해 설정해두는 것이 효율적일 수 있다.

• ex)

  custom:
  thread-pool:
    async:
      core: #{T(java.lang.Runtime).getRuntime().availableProcessors()}
      max: #{T(java.lang.Runtime).getRuntime().availableProcessors() * 10}
      queue-capacity: 1000
    scheduler:
      pool: #{T(java.lang.Runtime).getRuntime().availableProcessors() * 2}

• SpEL 식을 이용해서 동적으로 CPU 코어 수 환산

@Getter
@Setter
@Component
@ConfigurationProperties(prefix = "custom.thread-pool")
public class ThreadPoolProperties {
    private Async async = new Async();
    private Scheduler scheduler = new Scheduler();

    @Getter
    @Setter
    public static class Async {
        private int core;
        private int max;
        private int queueCapacity;
    }

    @Getter
    @Setter
    public static class Scheduler {
        private int pool;
    }
}

• 설정 파일을 읽어 프로퍼티 빈으로 등록
• 이후 ThreadPoolConfig 에서 해당 빈을 주입 받아서 사용

  JPA 에 대한 학습을 하던 중, @Modifying 어노테이션을 마주쳤다.

  기존에 @Modifying 어노테이션을 사용하여 DB 삭제 작업을 처리해본 경험이 있다. 생각해보면, 이 때 동작 방식이나 원리를 확실하게 이해하지 못하고

'이걸 사용하면 DB 수정/삭제 쿼리를 날릴 수 있다'

정도만 알고 사용했다.

  @Modifying 에 대해 알게 되면서, 궁금한 게 생겼다.

_ JPA 더티체킹 과 @Modifying 이 함께 사용되면 어떻게 처리될까?_

  @Modifying 에 관한 간단한 정리와 더불어, 해당 부분에 대해서도 추가로 작성해보고자 한다.

1️⃣ 벌크 연산

• 여러 데이터를 하나의 쿼리로 일괄 변경하는 것
• update , delete 가 이에 해당
  

❓ 필요한 이유

• JPA 는 더티 체킹에 의한 데이터 변경을 기본 전략으로 사용
  • 이러한 전략은 데이터의 변경이 없을 경우, 불필요한 변경 쿼리를 발생시키지 않음
• 하지만 변경할 엔티티가 여러 개인 경우, 해당 엔티티에 대한 변경 쿼리를 각각 1번씩 실행
  • 변경 데이터가 N개일 경우 : 총 N+1 만큼의 쿼리가 실행 (SELECT 1번 + 변경 쿼리 N번)
  • 네트워크 전송량의 증가로 인한 성능 저하 발생 가능
• 벌크 연산을 사용하면, 단 1번의 추가 쿼리로 여러 데이터 변경 가능
  • 영속성 컨텍스트와 DB 상태 동기화 작업 필요
    

2️⃣ @Modifying

• JPA 에서 사용 가능한 벌크 연산 어노테이션
• @Query 와 함께 사용함으로 벌크 연산 구현 가능
• 더티 체킹을 거치지 않고, 바로 DB 쿼리 요청
  

✍️ Learn With

1️⃣ @Query 어노테이션

• @Query 어노테이션은 JPA 의 조회용 JPQL 생성 어노테이션
  • JPA 의 데이터 변경 전략은 앞서 말했듯, 더티 체킹에 의한 변경
  • 따라서 직접적으로 사용되는 쿼리는 일반적으로 조회용 쿼리
• 단순히 @Query 에 update 나 delete 쿼리를 등록할 경우, 쿼리 자체가 비실행
  • @Query 는 JPQL 을 항상 생성
  • @Modifying 이 없다면, JPQL 을 조회 쿼리처럼 사용하려고 시도
  • 오류 발생
• @Modifying 어노테이션은 @Query 와 함께 사용함으로, 해당 JPQL 쿼리는 DB 변경 쿼리임을 표시
• 반환 타입
  • void : 변경 쿼리만 실행
  • int : 변경 쿼리 적용 개수 반환
    

2️⃣ 속성

• clearAutomatically
  • @Modifying(clearAutomatically = true) 같이 사용
  • 쿼리 실행 후, 영속성 컨텍스트 초기화 자동 실행
  • == em.clear()
• flushAutomatically
  • @Modifying(flushAutomatically = true) 같이 사용
  • 쿼리 실행 전, 영속성 컨텍스트 동기화 자동 실행
  • == em.flush()
    

3️⃣ Hibernate 와 Flush

• Hibernate 는 em.flush() 가 호출되면, 쓰기 지연 버퍼에 저장된 쿼리를 SQL 로 변환 후 DB 로 요청
• Hibernate 에는 실행 전, 자동 플러시를 실행하는 몇 시점이 존재
  

1. 명시적 플러시 호출

• em.flush()
  

2. 트랜잭션 커밋 시점

• @Transactional 내의 모든 로직 실행 후, tx.commit() 직전
  
  

3. JPQL 등 쿼리 실행 직전

• DB 쿼리 실행 시 영속성 컨텍스트와 DB 상태 정합성 유지를 위해
  
  

4. em.persist() 시점

• GeneratedValue(strategy = GenerationType.IDENTITY) 전략 한정)
  • 나머지 전략은 마찬가지로 쓰기 지연 버퍼에 작업을 쌓고, 바로 Flush는 실행하지 않음
• 엔티티에는 ID 값 필드가 기본적으로 존재
• 해당 전략은 INSERT 후에야 ID 가 DB 에 의해 자동으로 생성되는 전략
• 따라서 INSERT 실행 후 ID 를 가져와야, 엔티티 생성 시 초기화 가능
  

💡 Hibernate 의 Flush 모드

1. FlushModeType.AUTO :
   • Hibernate 기본값
   • 쿼리 실행 전 flush
2. FlushModeType.COMMIT :
   • 트랜잭션 커밋 시에만 flush
3. FlushModeType.MANUAL :
   • 직접 flush 호출해야만 flush
     

• 사용 방법

1. EntityManager 단위

   EntityManager em;
   
   em.setFlushMode(FlushModeType.COMMIT);    // COMMIT 모드로 변경

2. 트랜잭션 단위

   @Transactional(flushMode = FlushModeType.COMMIT)

3. 전역 설정

   spring:
   jpa:
     properties:
       jakarta.persistence.flushMode: COMMIT

   
   

📌 기본 모드가 AUTO 이므로, flushAutomatically 속성을 사용하지 않아도 쿼리 실행 전 flush 호출

3️⃣ 더티 체킹 ➕ @Modifying

🔗 '사실상 이번 정리글 작성의 이유'

• 그렇다면 더티 체킹과 @Modifying 을 함께 사용하면 어떻게 동작할까? 간단한 테스트 코드와 함께 확인해보자.

• 최초 코드

  @SpringBootTest
  @Transactional
  public class TempTest {
  
    @Autowired
    EntityManager em;
  
    @Autowired
    Repo repo;
  
    @Test
    @Rollback(value = false)    // DB 확인을 위한 롤백 미실시
    void t1() {
        Member member = new Member();
        member.setName("A");
        repo.save(member);
  
        // == member
        Member findMember = repo.findById(1L).get();
        findMember.setName("B");
  
        repo.update("C", findMember.getId());
        em.flush();
        em.clear();
        System.out.println("===================");
  
        Member dbMember = repo.findById(1L).get();
        System.out.println("findMember.getName() = " + findMember.getName());
        System.out.println("dbMember.getName() = " + dbMember.getName());
    }
  }
  

interface Repo extends JpaRepository<Member, Long> {

@Modifying
@Query("update Member m set m.name = :name where m.id = :id")
void update(@Param("name") String name, @Param("id") Long id);

}

- __벌크연산__을 수행하기 위한 `Repo`
  - `id` 에 해당하는 `Member` 의 __이름 변경__ 쿼리 실행
- 이름이 __"A"__ 인 `member` 등록
- `member` 의 이름을 __"B"__ 로 변경
  - `JPA` __더티체킹 대기__
- `repo.update()` 실행
  - `member` 의 이름을 __"C"__ 로 변경
- `em.flush()` 로 __영속성 컨텍스트 동기화(더티 체킹 업데이트 실행)__ 및 `em.clear()` 로 __영속성 컨텍스트 초기화__
- __1차 캐시__가 아닌 `DB` 에서 __최신화된 Member 조회__
- __영속성 컨텍스트 멤버__의 이름과 __최신화된 멤버__의 이름 출력
<br>

## 1️⃣ 최초 코드 실행
- __이름__만 변경하는 최초 코드 실행
- __실행 결과__
<div style="text-align:center">
<img src="https://velog.velcdn.com/images/riverpower6_g/post/78eb91f6-1e9b-4365-a49f-5a52346089ae/image.png" width="1000" height="1000"/></div>
- `INSERT` 1번 + `UPDATE` 2번 + `SELECT` 1번
  - `em.clear()` 로 인한 __1번의 추가__ `SELECT`
- `name='B'` __업데이트__ 실행 후 `name='C'` __업데이트__ 실행
  - __더티 체킹 업데이트__ 먼저 실행
  - __벌크 연산__ 추가 실행
- `dbMember.getName()` 결과 : __"C"__
<br>

### 📌 결과
<div style="text-align:center">
<img src="https://velog.velcdn.com/images/riverpower6_g/post/1f727df3-adac-48a7-a24b-8acf327e373f/image.png" width="1000" height="1000"/></div>

- `NAME` 컬럼이 __"C"__ 로 잘 반영
<br>

## 2️⃣ 벌크 연산 이전, 다른 필드 변경 코드 실행
- `setTempCnt` 로 __이름이 아닌__ 필드 변경
- `repo.update()` 호출 이전에 `findMember.setTempCnt(100)` 실행
```java
// ...

Member member = new Member();
member.setName("A");
// setTempCnt 필드 추가
member.setTempCnt(0);
repo.save(member);

Member findMember = repo.findById(1L).get();
findMember.setName("B");
// update 호출 전, setTempCnt 필드 변경
findMember.setTempCnt(100);

repo.update("C", findMember.getId());
em.flush();
em.clear();

// ...

• 실행 결과
  
• INSERT 1번 + UPDATE 2번 + SELECT 1번
  • em.clear() 로 인한 1번의 추가 SELECT
• 1번 실행 결과와 마찬가지로, 더티 체킹 업데이트 이후 벌크 연산 수행
• dbMember.getName() 결과 : "C"
  

📌 결과

• NAME 컬럼은 "C" , TEMP_CNT 컬럼은 100이 잘 반영
  ## 3️⃣ 벌크 연산 이후, 다른 필드 변경 코드 실행
• repo.update() 호출 이후에 findMember.setTempCnt(100) 실행

  // ...
  

Member findMember = repo.findById(1L).get(); findMember.setName("B");

repo.update("C", findMember.getId()); // update 호출 후, setTempCnt 필드 변경 findMember.setTempCnt(100); em.flush(); em.clear();

// ...

```

• 실행 결과
  
• INSERT 1번 + UPDATE 3번 + SELECT 1번
  • em.clear() 로 인한 1번의 추가 SELECT
• name='B' 업데이트 실행 후 name='C' 업데이트 실행
  • 최초 더티 체킹 업데이트 실행
  • 벌크 연산 추가 실행
• name='B' 와 temp_cnt=100 업데이트가 추가 실행
  • tempCnt 로 인한 더티 체킹 업데이트 추가 실행
• dbMember.getName() 결과 : "B"

📌 결과

• TEMP_CNT 컬럼은 100이 잘 반영
• NAME 컬럼은 "C" 가 아닌, "B"가 최종 반영
  
  

‼️ dbMember.getName() 이 C가 아닌 B로 변경됨

• @Modifying 쿼리 실행 시점에 NAME 컬럼을 "C"로 업데이트
• findMember.setTempCnt(100) 으로 기존 영속성 컨텍스트에 존재하는 엔티티의 tempCnt 속성 변경
  • 해당 엔티티는 더티 체킹에 의한 업데이트 대상으로 변경
  • 이 때 영속성 컨텍스트의 name 은 여전히 "B"
  • 아직 em.clear() 를 하지 않아서 기존 영속성 컨텍스트에 엔티티가 남아있기 때문
• 원했던 변경된 이름 : "C"
• 최종 변경된 이름 : "B"

_ 영속성 컨텍스트가 제 때 초기화되지 않으면 원하지 않는 결과를 초래할 수 있다!_

🔨 결론

• @Modifying 과 영속성 컨텍스트 변경 작업을 같은 트랜잭션 내에서 진행하면 원하지 않은 결과를 초래할 수 있음
• 추가 비즈니스 로직 작성 시, clearAutomatically = true 속성을 반드시 추가해서 사용
• 혹시 모를 Side Effect가 불안하다면, 애초에 트랜잭션을 분리해서 작업을 진행하도록 하자.

벌크 연산을 사용하려면 반드시 영속성 컨텍스트와 DB 상태를 잘 고려하여 사용하자!

검수)

• Google Gemini ( https://gemini.google.com/app )
• ChatGPT ( https://chatgpt.com/ )

  JPA 에 대한 학습을 진행하던 중, @OneToMany 의 cascade 속성에 대한 복습을 진행 중이었다.

  보통 @OneToMany 에서 주로 사용되는 속성 연계는 @OneToMany(mappedBy = "fieldName", cascade = CascadeType.??, orphanRemoval = true) 이다. 데이터 삭제 시 이후에 객체의 양방향 연관관계를 끊어주면, DB 에서 부모와 자식들의 삭제를 외래키 제약 조건 위반 없이 제대로 제거할 수 있다.

  근데 여기서 궁금증이 하나 생겼다. 예를들어 Member와 Team 엔티티가 있을 경우, Team을 삭제한다고 Member도 삭제해버릴 수는 없을 것이다. Member의 Team 참조를 NULL 로 변경하던가 하는 식으로 진행해야 한다. 이러한 경우는 cascade 속성으로 처리할 수 없다. cascade 는 사실상 부모에 따른 자식의 CRUD 처리일 뿐, 자식의 FK 변경에 대한 관여는 없다. 즉, 자식의 생명주기가 부모에 종속될 때만 사용해야 하는 속성이다.

  그렇다면 어떻게 해야 할까? 가장 간단한 방법은 @OneToMany 에서 별다른 속성 사용 없이 비즈니스 로직에서 member.setTeam(null) 과 Team 삭제 로직을 혼합해서 사용하는 것이다.

  그런데 방법을 고민하며 찾아보던 중, Hibernate 에 흥미로운 기능이 있었다. @OnDelete 라는 어노테이션이었다. 이 어노테이션을 사용하면 외래키 제약 조건 기능을 활용하며, 부모, 자식 삭제 관련 여러 가지 작업을 아주 편리하게 할 수 있었다.

  처음보는 신기한 기능이기에 공부 내용을 잘 정리해서 남겨놓기로 결정했다.

1️⃣ @OnDelete

• Hibernate 에서 제공하는 어노테이션으로, 엔티티 삭제 시 연관된 엔티티에 어떤 동작을 수행할지 DB 레벨에서 정의
  • DDL 에서 직접 정의하거나, ddl-auto 옵션을 사용하는 경우 Hibernate 가 자동 설정하며, 이 경우 1번만 실행
  • JPA 표준이 아닌 Hibernate 구현체의 기술
• 외래키 제약 조건을 위반하지 않으며, DB 의 참조 무결성을 반드시 유지
• @ManyToOne 어노테이션과 함께 사용하여, 연관 필드를 FK 를 가진 주인 쪽에서 어떻게 처리할지 세팅 가능
• DB 에서 반영하므로, 영속성 컨텍스트에는 바로 반영되지 않음
  • 영속성 컨텍스트와 DB 상태 불일치 가능
    

➕ 옵션

1. OnDeleteAction.NO_ACTION (OnDeleteAction.RESTRICT)

• 부모 엔티티 삭제 시, 연관된 자식 엔티티가 존재하면 삭제 불가
• @OnDelete 어노테이션의 기본값
• 두 옵션이 완전히 동일한 옵션은 아니지만, 대부분 DB 에서 동일하게 동작
  • DB 별 미묘한 차이는 존재
• DDL Constraint : ON DELETE NO ACTION 또는 ON DELETE RESTRICT
  

2. OnDeleteAction.CASCADE

• 부모 엔티티 삭제 시, 자동으로 연관된 자식 엔티티 함께 삭제
• @OneToMany(cascade = CascadeType.REMOVE) 를 지정해주지 않아도, DB 레벨에서 외래키 제약 조건 위반 없이 부모, 자식을 모두 삭제
  • cascade 속성과는 별개로 동작
  • CascadeType.REMOVE : JPA 가 DELETE 쿼리를 실행하며, 쓰기 지연 버퍼에는 자식 -> 부모 순으로 쿼리 등록
• DDL Constraint : ON DELETE CASCADE
  

3. OnDeleteAction.SET_NULL

• 부모 엔티티 삭제 시, 연관된 자식 엔티티의 FK 값을 NULL 로 설정
• 반드시 해당 컬럼의 nullable 제약 조건이 true 여야 사용 가능
• DDL Constraint : ON DELETE SET NULL
  

4. OnDeleteAction.DEFAULT

• 부모 엔티티 삭제 시, 연관된 자식 엔티티의 FK 값을 기본값으로 설정
• 반드시 해당 컬럼의 기본값이 미리 정의되어 있어야 가능
• MySQL 에서는 해당 옵션 사용 불가능
• DDL Constraint : ON DELETE SET DEFAULT
  

2️⃣ cascade 와의 쿼리 실행 횟수 비교

• @OnDelete 기능은 DB 에서 직접 데이터 삭제를 조작
• cascade 속성 사용과 비교했을 때, 쿼리 횟수 압도적 감소
  • 네트워크 통신 비용의 대량 감소
  • 성능 압도적 향상
    
    

⚒️ 실습을 통해 알아보자

📌 기본 엔티티

@Entity(name = "newMember")
public class Member {
    @Id
    @GeneratedValue
    private Long id;

    @ManyToOne
    private Team team;

    public void setTeam(Team team) {
        this.team = team;
    }
}

@Entity
public class Team {
    @Id
    @GeneratedValue
    private Long id;

    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<>();
}

• Member 와 Team 은 N:1(다대일) 관계
• 양방향 참조 가능
  

📌 실행 메서드

public static void main(String[] args) {
    EntityManagerFactory emf = Persistence.createEntityManagerFactory("hello");
    EntityManager em = emf.createEntityManager();
    EntityTransaction tx = em.getTransaction();

    tx.begin();
    try {
        Team team = new Team();
        em.persist(team);
        Member member = new Member();
        member.setTeam(team);
        Member member2 = new Member();
        member2.setTeam(team);
        em.persist(member);
        em.persist(member2);

        tx.commit();
    } catch (Exception e) {
        tx.rollback();
    } finally {
        em.close();
    }

    em = emf.createEntityManager();
    tx = em.getTransaction();
    tx.begin();
    try {
        Team team = em.find(Team.class, 1L);
        em.remove(team);

        tx.commit();
    } catch (Exception e) {
        tx.rollback();
        e.printStackTrace();
    } finally {
        em.close();
    }
    emf.close();
}

• 1번째 트랜잭션
  • Team 을 1개 생성 후 DB 반영
  • Member 를 2개 생성 후 team 과 매핑 후 DB 반영
• 2번째 트랜잭션
  • 1번 Team 데이터 조회
  • 1번 Team 삭제
    

최초 실행 결과

• 1번의 SELECT 와 1번의 DELETE
• Team 삭제 중 예외 발생
  • Caused by: org.h2.jdbc.JdbcSQLIntegrityConstraintViolationException: Referential integrity constraint violation: "FKA84Y4NUL9OTEXFOY22AFBG081: PUBLIC.NEWMEMBER FOREIGN KEY(TEAM_ID) REFERENCES PUBLIC.TEAM(ID) (CAST(1 AS BIGINT))"; SQL statement:
  • 즉, 외래키 제약 조건 위반으로 인한 데이터 삭제 불가능
    
• 데이터베이스 데이터 확인
  
• 2개의 Member 와 1개의 Team 모두 삭제되지 않음
  

🥇 부모 삭제 시 자식 삭제 제약 조건

1️⃣ cascade 속성만 사용

@Entity
public class Team {
    ...

    // cascade 속성 적용
    @OneToMany(mappedBy = "team", cascade = CascadeType.REMOVE)
    private List<Member> members = new ArrayList<>();
}

• 메서드 실행 결과

  

• 2번의 SELECT 와 3번의 DELETE

  • Team 에 해당된 Member 를 찾기 위한 1번의 추가 SELECT 발생
  • 2명의 연관된 Member 를 삭제하는 DELETE 쿼리 추가 발생
  • 이 때, Member (자식) -> Team (부모) 순서로 DELETE 쿼리 발생

• JPA 는 총 5번의 쿼리 요청

  
  

• 데이터베이스 데이터 확인

  

• 문제 없이 모두 정상 삭제

  
  

2️⃣ @OnDelete(action = OnDeleteAction.CASCADE) 만 사용

@Entity(name = "newMember")
public class Member {
    ...

    // @OnDelete 와 CASCADE 옵션 사용
    @ManyToOne
    @OnDelete(action = OnDeleteAction.CASCADE)
    private Team team;

    ...
}

• 메서드 실행 결과

  

• 1번의 SELECT 와 1번의 DELETE

  • 부모인 Team 객체만 조회
  • JPA 는 이 Team 의 DELETE 쿼리 1개만 DB 로 요청

• JPA 는 총 2번의 쿼리 요청

  
  

• 데이터베이스 데이터 확인

  

• 문제 없이 모두 정상 삭제

  
  

🥈 부모 삭제 시 자식 FK를 NULL로 변경

1️⃣ 비즈니스 로직에서 NULL 지정

@Entity
public class Team {
    ...

    // mappedBy 를 제외한 속성 제거
    @OneToMany(mappedBy = "team")
    private List<Member> members = new ArrayList<>();

    // Getter 추가
    public List<Member> getMembers() {
        return this.members;
    }
}

...

Team team = em.find(Team.class, 1L);

// Member의 Team을 NULL로 변경
for (Member member : team.getMembers()) {
    member.setTeam(null);
}
em.remove(team);

tx.commit();

...

• main() 메서드의 2번째 트랜잭션에서 각 Member 의 Team 을 NULL 로 변경

  
  

• 메서드 실행 결과

  

• 2번의 SELECT , 2번의 UPDATE , 1번의 DELETE

  • Team 의 Member 조회를 위한 1번의 추가 SELECT 발생
  • Member 의 FK를 NULL 로 지정하기 위한 2번의 추가 UPDATE 발생

• JPA 는 총 5번의 쿼리 요청

  
  

• 데이터베이스 데이터 확인

  

• Team 삭제 성공
• Member 의 FK를 NULL 로 변경 성공
  

2️⃣ @OnDelete(action = OnDeleteAction.SET_NULL) 사용

@Entity(name = "newMember")
public class Member {
    ...

    // @OnDelete 와 SET_NULL 옵션 사용
    @ManyToOne
    @OnDelete(action = OnDeleteAction.SET_NULL)
    private Team team;

    ...
}

Team team = em.find(Team.class, 1L);
// setNull 제거
em.remove(team);

tx.commit();

• 최초 메인 메서드로 롤백

  
  

• 메서드 실행 결과

  

• 1번의 SELECT 와 1번의 DELETE

  • 부모인 Team 객체만 조회
  • JPA 는 이 Team 의 DELETE 쿼리 1개만 DB 로 요청

• JPA 는 총 2번의 쿼리 요청

  
  

• 데이터베이스 데이터 확인

  

• Team 삭제 성공
• Member 의 FK를 NULL 로 변경 성공
  

💡 @OnDelete 와 cascade 속성을 함께 사용한다면?

• @OneToMany(cascade = CascadeType.REMOVE) 사용했을 때 만큼의 쿼리 실행
  • @OnDelete 의 이점인 쿼리 최소화를 전혀 살릴 수 없음
    

📋 정리

3️⃣ @OnDelete 🆚 Cascade

❗ @OnDelete 의 문제점

1. 비즈니스 로직 추가 수행의 어려움

• @OnDelete 는 모든 삭제 로직을 DB 내부에서 수행하도록 위임
  • 비즈니스 로직 내에서 별도의 연관관계 제거 메서드를 호출하지 않고도, 단순히 레포지터리의 메서드 delete 호출 만으로 간편하게 연관된 모든 데이터 삭제 가능
  • 단 트랜잭션 종료 직전에야 삭제 쿼리 실행이 가능하므로, 트랜잭션 내에서는 삭제가 즉시 반영되지는 않음
• @OneToMany + cascade 속성 방식은 연관관계 제거 메서드가 필수
  • 이를 통해 영속성 컨텍스트 와 최종 DB 의 일관성 유지 가능
• @OnDelete 방식은 영속성 컨텍스트가 제거 상태를 반영하지 않으므로, 이후 작업에서 DB 와의 일관성에서 문제 발생 가능

2. JPA 표준이 아님

• @OnDelete 는 Hibernate 구현체의 확장 기능
• 만약 JPA 구현체를 변경하게 되면, 해당 코드 변경 필요
• 단, 일반적으로 JPA 를 사용한 스프링 개발 시 Hibernate 를 사용하기는 함
  

💡 비즈니스 로직 추가 수행 방법

• @OnDelete + EntityManager.flush() 사용
  • 레포지터리의 delete 메서드 호출 후, 영속성 컨텍스트와 DB 의 일관성 유지를 위한 em.flush() 호출
  • 이후부터는 영속성 컨텍스트와 DB 의 일관성이 유지
• 단, 매 삭제 메서드 호출 후에 반드시 flush() 호출이 필요하다는 단점 존재
  • 코드의 복잡성 증가
    

🔗 @OnDelete 🆚 Cascade

1. 성능

1️⃣ @OnDelete

• 애플리케이션 레벨에서 추가 로직 작업 필요 없음
  • 빠르고 효율적
• JPA 가 부모 삭제 쿼리만 호출
  • 네트워크 통신 비용 절약

2️⃣ Cascade

• 애플리케이션 레벨에서 추가 로직 필요
  • 양방향 연관관계 제거 메서드 필요
• 모든 자식 삭제 쿼리를 JDBC API로 요청
  • 네트워크 통신 비용 증가

🎉 OnDelete() 승리

• 단, 자식 객체의 수에 따른 DB 부하 고려
• 네트워크 통신 비용 절약 VS DB 부하 감소
• 자식 객체가 엄청나게 많은 게 아니라면, OnDelete() 가 더 좋은 성능 발휘
  

2. 유연성 (후속 작업, 개별 작업)

1️⃣ @OnDelete

• 삭제되는 자식 객체의 개별 작업 불가능
  • JPA 는 부모 삭제 쿼리 만 JDBC API에 전달
  • @OnDelete 는 DB 에서 자식을 한 번에 삭제
  • 삭제되는 개별 자식 객체 정보는 획득 불가능
  • 삭제되는 자식 객체 대상 추가적인 작업 불가능

2️⃣ Cascade

• 삭제되는 자식 객체의 개별 작업 가능
  • JPA 는 자식 삭제 쿼리를 모두 전달
  • try-catch 나 반복문 등을 활용하여, 삭제되는 객체 대상 추가적인 작업 가능

🎉 @OneToMany(cascade) 승리

• @Transactional 과 함께 사용하면, 양쪽 다 롤백 관련 문제는 발생하지 않음

3. 유지보수성

1️⃣ @OnDelete

• 레포지터리의 delete 호출마다 em.flush() 필수
  • 영속성 컨텍스트와 최종 DB의 일관성 유지를 위해 반드시 필요
• 매번 em.flush() 호출이 반드시 필요하므로, 코드의 복잡성 및 실수 확률 증가

2️⃣ Cascade

• 양방향 연관관계 제거 메서드 필수
  • 영속성 컨텍스트와 최종 DB의 일관성 유지
• 매번 연관관계 제거 메서드 호출이 반드시 필요하지만, 논리적으로 추가할 수밖에 없음
  • @OnDelete 방식에 비해 낮은 실수 확률
  • 직접적인 EntityManager 호출이 필요 없으므로, 비교적 더 간결한 복잡성

🎉 @OneToMany(cascade) 승리

• 실수할 확률, 다른 의존관계 사용 여부 등에서 @OneToMany 가 더 낫다고 생각
  

📓 결론

• 개별 작업이 전혀 필요 없고, 엔티티의 삭제만 최대한의 성능으로 처리하고 싶다면 @OnDelete 를 사용
  • 하지만 사실상, 이런 경우는 거의 없다고 봐도 무방할 것으로 예상됨
• 그 외의 경우 @OneToMany(cascade = CascadeType.REMOVE) 사용이 더 유리

‼️ 웬만해서 @OneToMany(cascade = CascadeType.REMOVE) 를 사용하자

검수)

• Google Gemini ( https://gemini.google.com/app )
• ChatGPT ( https://chatgpt.com/ )

 트랜잭션은 데이터를 다루는 개발자에게는 뗄레야 뗄 수 없는 핵심 요소이다. 필자 역시 트랜잭션의 중요성을 알기에, 트랜잭션의 이해와 활용 방식 등에 대해서 시간을 적지 않게 소요했었다.

 그렇게 트랜잭션에 대한 이해도가 상당히 올라왔다고 생각하고 이전 프로젝트들을 진행했었다. 도중에 헷갈리는 부분들도 있었지만, 그래도 프로젝트 진행중 추가적으로 공부해나가며 부족한 부분을 잘 메꿀 수 있었다.

 최근, 스프링을 더욱 더 깊이 이해하고 기술을 사용하기 위해서 유명한 김영한님의 스프링 강의를 들으며 이해하고 있다. 학습 내용 중 트랜잭션에 대한 내용이 나왔는데, 기존에 알고 있던 것들이 생각보다 더 얕은 지식들이었다는 걸 느끼게 되었다.

 트랜잭션의 동작 원리와 흐름, 그 안에서 작동하는 것들에 대해서 좀 더 깊게 공부하였고, 그 부분에 대해서 정리하는 시간을 가져보려고 한다.

1️⃣ PlatformTransactionManager

• 트랜잭션 매니저 인터페이스
• 여러 DB 드라이버에서 트랜잭션과 관련된 기능들을 사용할 수 있도록 설계된 스프링 인터페이스
  • JDBC , JPA 등 특정 기술에 종속되지 않고 일관된 방식으로 트랜잭션 관리 가능
  • JDBC 만 사용하면 DataSourceTransactionManager 가, JPA 를 사용하면 JpaTransactionManager 가 자동으로 스프링 빈에 등록되고 사용
• 실제 트랜잭션의 시작 및 생성, 커밋, 롤백을 담당하는 그야말로 핵심 인터페이스
• 물리 트랜잭션(외부 트랜잭션)에 대한 관리를 진행
  ## 💪 역할

1. 트랜잭션 시작

• getTransaction() 메서드를 호출하여 트랜잭션을 새로 생성하고, 해당 커넥션의 autoCommit(false)를 호출
  • getTansaction() 메서드 생성 시, 트랜잭션에 대한 전파, 격리 수준 등의 추가적인 조건을 설정한 트랜잭션을 생성 가능
• 이 커넥션을 TransactionSynchronizationManager 에 등록
• 이후 DB 작업 호출이 필요할 땐 등록된 커넥션을 사용함으로 autoCommit(false) 상태 유지

2. 커밋

• commit() 메서드로 트랜잭션 내의 모든 작업을 DB 에 영구 반영
• 물리적 DB 커밋

3. 롤백

• rollback() 메서드로 트랜잭션 내의 모든 작업 롤백
• 물리적 DB 롤백

4. 자원 관리

• 커밋, 롤백 이후, 커넥션의 autoCommit(true) 를 호출
• 트랜잭션 동기화 매니저에 등록된 현재 커넥션을 커넥션 풀로 반환
  

2️⃣ TransactionSynchronizationManager

• 트랜잭션 동기화 매니저
• 현재 스레드에서 진행 중인 트랜잭션에 대한 정보를 관리하고, 해당 커넥션을 동기화하는 역할 담당
  • 해당 트랜잭션 정보들은 ThreadLocal 을 통해 따로 보관
  • @Component 같은 어노테이션으로 직접 등록하는 일반적인 빈이 아니라, 스프링 자체에서 내부적으로 관리하는 유틸리티 클래스에 근접
• 논리 트랜잭션(내부 트랜잭션)에 대한 관리를 진행
  • 트랜잭션 컨텍스트를 스레드 단위로 관리
    

💪 역할

1. ThreadLocal 관리

• 현재 스레드의 트랜잭션 관련 정보 바인딩 및 해제
  • 트랜잭션 객체, 커넥션, rollbackOnly 플래그 ...

2. 롤백 전용 플래그 관리

• 메서드에서 예외 발생 시 setRollbackOnly() 메서드로 현재 트랜잭션을 롤백 전용 트랜잭션으로 마킹
  • 이후 트랜잭션 매니저는 rollbackOnly 플래그 유무를 확인한 후 커밋 또는 롤백 진행

3. 트랜잭션 정보 확인

• isActualTransactionActive() , isNewTransaction() 등, 현재 작업 중인 트랜잭션에 대한 정보를 확인 가능
  

💾 TreadLocal 저장 필드

1. TransactionStatus

• 현재 트랜잭션의 상태를 저장하는 객체
• 트랜잭션의 활성 상태, 롤백 전용 표시, 커밋/롤백 여부, 새로운 트랜잭션인지 여부 등의 정보 포함

2. Connection

• DB 와의 실제 연결을 진행하는 Connection 객체
  • 스프링은 기본적으로 HikariCP 커넥션 풀을 사용
  • 커넥션 풀에서 임의의 커넥션을 선택 후 등록
• 하나의 트랜잭션 내에서는 반드시, 모든 DB 작업에서 이 동일한 커넥션 사용
  • 데이터 정합성 보장

3. EntityManager

• 트랜잭션이 시작될 때, 트랜잭션 동기화 매니저는 EntityManagerFactory 에서 새로운 Entitymanager 인스턴스 생성
  • EntityManagerFactory 는 싱글톤 빈으로 등록된 객체
  • 여기서 매 요청마다 새로운 EntityManager 를 생성하므로, EntityManager 는 싱글톤이 아님
• 생성된 EntityManager 를 ThreadLocal 에 저장
  • EntityManager 는 해당 트랜잭션의 영속성 컨텍스트 담당
  • JPA 에서 EntityManager 는 영속성 컨텍스트와 기본적으로 1:1로 매칭되기 때문
    

💡 전파 수준에 따른 rollbackOnly 플래그

• rollbackOnly 플래그는 '현재 트랜잭션이 새로운 트랜잭션인가' 를 기준으로 작동
  • isNewTransaction() == true :
    • 독립적인 트랜잭션, 즉 하나의 물리적 트랜잭션 으로 판단
    • 해당 트랜잭션이 커밋되면, rollbackOnly 플래그 체크 후 실제 커밋 진행
    • 해당 트랜잭션이 롤백되면, setRollbackOnly() 를 하지 않고 바로 물리 DB 롤백 진행
  • isNewTransaction() == false :
    • 기존에 존재하던 트랜잭션에 합류, 새로운 논리적 트랜잭션
    • 해당 트랜잭션이 커밋되면, 바로 다음 시퀀스 진행
    • 해당 트랜잭션이 롤백되면, 트랜잭션 동기화 매니저에 rollbackOnly() 플래그를 true 로 변경, 이후 해당 논리 트랜잭션이 포함된 물리 트랜잭션 전체를 롤백
      

3️⃣ 트랜잭션 동기화 매니저 - REQUIRES_NEW

1. 트랜잭션 동기화 매니저는 기본적으로 1개의 커넥션만을 관리
   
2. REUIQRES_NEW 로 새로운 트랜잭션이 실행되면, ThreadLocal 에 저장된 기존 트랜잭션 정보를 내부 스택에 임시로 저장
   • 해당 트랜잭션은 Thread 에서의 블로킹 처럼, 이후 트랜잭션이 종료되기 전까지 대기
   • 이후 트랜잭션이 종료되지 않으면 이후 작업 불가능
     
3. 트랜잭션 매니저가 새로운 커넥션을 생성, 동일하게 autoCommit(false) 로 설정 후 트랜잭션 동기화 매니저의 ThreadLocal 에 바인딩
   • 이 과정에서 기존 ThreadLocal 트랜잭션 정보를 새로운 커넥션의 트랜잭션 정보로 오버라이딩
   • 이후 진행되는 DB 작업은, 이 새로 할당된 커넥션을 통해 진행
     
4. 새로운 트랜잭션이 커밋, 롤백되면 이는 하나의 독립적인 트랜잭션이므로 바로 DB 에 반영, 이후 커넥션 풀로 커넥션 반환
   
5. 트랜잭션 동기화 매니저는 임시 스택에 저장되어 있던 기존 트랜잭션 정보를 ThreadLocal 에 리바인딩 후 대기 중이던 이전 트랜잭션 진행
   

4️⃣ TransactionDefinition

• 트랜잭션 행동 규칙 정의 인터페이스
• 트랜잭션 매니저의 getTransaction() 메서드의 파라미터에 등록하여, 원하는 트랜잭션 속성을 적용시킬 수 있음
• 일반적으로 기본 구현체인 DefaultTransactionDefinition 혹은 몇 가지 기능이 추가된 DefaultTransactionAttributes() 구현체를 등록

• ex)

  // 트랜잭션 행동 규칙 객체 (현재 기본 구현체)
  DefaultTransactionDefinition definition = new DefaultTransactionAttributes();
  
  // 트랜잭션 매니저는 해당 규칙이 적용된 트랜잭션 생성
  PlatformTransactionManager txManager = new JpaTransactionManager(definition);

  
  

🗂️ 등록 속성

1. 전파(Propagation)

// 전파 속성 변경 (Default : PROPAGATION_REQUIRED)
definition.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRES_NEW);

2. 격리 수준(Isolation Level)

 // 격리 수준 변경 (DEFAULT :
 //        MySQL : ISOLATION_REPEATABLE_READ    트랜잭션 내에서 같은 데이터를 몇 번 읽어도 동일한 결과 보장
 //        일반 DB : ISOLATION_READ_COMMITED       커밋된 데이터만 읽기 가능
 definition.setIsolationLevel(TransactionDefinition.ISOLATION_READ_COMMITED)

3. 타임아웃(Timeout)

 // 트랜잭션 완료까지의 최대 허용 시간 변경 (Default : -1, 타임아웃 없음)
 definition.setTimeout(30);        // 트랜잭션이 30초를 촉과하면 롤백

• 트랜잭션이 지정된 시간을 넘으면 롤백
  

4. 읽기 전용(Read-Only)

 // 읽기 전용 트랜잭션임을 명시 (Default : false)
 // @Transactional(readOnly = true) 과 동일
 definition.setReadOnly(true);

• 읽기 전용 트랜잭션은 조회에 특화된 트랜잭션
• 데이터 변경이 불가능하며, 그만큼 조회에서 성능상 유리
  

💡 읽기 전용 트랜잭션의 조회 성능 최적화

1. JPA/Hibernate 최적화

• ORM 프레임워크는 스냅샷을 유지하고 더티 체킹을 수행하는 것이 기본
• 읽기 전용 트랜잭션은 스냅샷을 생성하지 않고 더티 체킹도 생략
  • 스냅샷 미생성으로 인한 메모리 절약
  • 더티 체킹 생략으로 인한 처리 속도 향상
    

2. DB 드라이버 최적화

• Write Lock 생략
  • 일반적인 트랜잭션은 동시성을 고려하여, 데이터 변경 시 Write Lock을 획득해야 함
  • 읽기 전용 트랜잭션은 Lock 획득 과정을 생략 가능
  • 병목 현상 저하 및 트랜잭션 처리 속도 향상
• 캐싱 최적화
  • 내부 캐싱 메커니즘 최적화 가능
  • 커넥션 풀 리소스를 더 효율적으로 관리하여 시스템 성능 향상 가능
    

3. 복제 환경(Replication) 최적화

• 읽기 부하 분산
  • Master-Slave 구조의 DB 복제 환경에서는 일반적으로, Master DB 는 쓰기 담당만, Slave DB 는 읽기 담당만 하도록 분산 처리
  • 읽기 전용 트랜잭션은 요청을 Slave DB 로 자동 라우팅 가능
• Master DB 부하 감소
  • 읽기 요청을 Slave DB 로 분산시킴으로, Master DB 는 오직 변경 작업에만 집중 가능
  • Master DB 의 부하를 크게 줄임으로써, DB 의 안정성을 높이고, 쓰기 성능의 향상을 보장 가능
• 확장성 향상
  • 조회 요청이 많아지더라도, Slave DB 서버 추가만으로 서버 안정화 및 성능 확장 가능
    

검수) Google Gemini ( https://gemini.google.com/app )

 Next.js 를 이용해 프론트엔드 실습을 진행 중, 헷갈리는 부분이 생겼다. 필자가 알고 있는 SSR 과 CSR 의 개념이 실습 중 혼동을 일으키기 시작했다.

 서버 사이드 렌더링은 서버 측에서 렌더링을 해서 보여주는 거고, 클라이언트 사이드 렌더링은 브라우저에서 렌더링을 해서 보여준다 라고만 이해하고 있었다. 그러다보니, ' Next.js 에서 JSX 와 JavaScript 를 사용해서 코드를 작성하면 CSR 이다' 라고 잘못 이해하고 있었다.

 잘못된 정보에 대한 인식을 개선한 김에, 이후에는 절대 헷갈리지 않도록 관련 개념에 대한 기록을 남겨두기로 했다.

1️⃣ SSR

• Server-Side Rendering - 서버 사이드 렌더링
• 서버에서 웹 페이지 렌더링을 담당
• 클라이언트로부터 페이지를 요청받으면 완성된 정적 + 동적 HTML 파일을 클라이언트에게 반환
  • 기본적인 정적 데이터인 HTML , JSX 파일은 그대로 반환
  • 서버에 동적인 데이터를 요청한 경우, 해당 API 를 호출한 후의 응답값(동적 데이터) 또한 HTML, JSX 파일에 담아서 반환
  • 즉, 데이터를 모두 채워 넣은 완전한 HTML 파일 반환
• 서버 데이터 기반 UI 구성 담당
  

❓ 장점

1. 빠른 초기 로딩 성능
   • HTML 파일 자체가 모든 컨텐츠를 이미 포함
   • 클라이언트(브라우저)는 이 페이지를 바로 렌더링하기만 하면 됨
2. SEO 최적화
   • 검색 엔진 크롤러가 페이지의 모든 콘텐츠를 쉽게 읽을 수 있음
   • 특정 키워드에 대한 검색 결과 노출에 유리
     

❗ 단점

1. 느린 페이지 전환 속도
   • 페이지 이동 시마다, 서버는 HTML 을 새로 렌더링 후 전송
   • 로직 처리에 시간이 다소 소요된다면, 응답받기 전까지 페이지 로딩
   • 이는 불쾌한 사용자 경험을 초래
2. 서버 부하의 증가
   • 매번 서버 API 를 호출하므로, 서버 호출 횟수 증가
   • 트래픽이 많을수록 서버 자원은 많이 소모
   • 서버 부하로 인한 성능 저하, 심하면 서버 다운까지 초래

2️⃣ CSR

• Client-Side Rendering - 클라이언트 사이드 렌더링
• 클라이언트(브라우저)에서 페이지 렌더링을 담당
• 웹 페이지의 모든 구성 요소가 JavaScript 에 의해 동적으로 생성
• UX 및 사용자 인터렉션 담당
  

❓ 장점

1. 빠른 페이지 전환
   • 서버 API 호출 이전에 페이지를 먼저 렌더링
   • 즉, 서버에 데이터가 저장되기도 이전에, 바로 UI 에 먼저 적용
   • 낙관적 업데이트
2. 풍부한 사용자 경험
   • 사용자에게 즉각적인 피드백을 제공
   • 사용자의 UX 극대화
     

❗ 단점

1. 초기 로딩 속도 저하
   • CSR 은 사용자에게 해당 컴포넌트의 JavaScript 를 모두 전송
     • 컴포넌트가 많아질수록 초기 다운로드 용량 증가
   • 서버로부터 받은 HTML 에 JavaScript 를 연결하여 이벤트 리스너를 등록
     • 이를 하이드레이션 이라고 함
     • 하이드레이션에 필요한 작업 증가로 인한 인터랙션 소요 시간 증가
2. SEO 효율성 감소
   • JavaScript 기반이므로, 완성된 HTML 파일을 제공하는 SSR 방식에 비해 낮은 효율
     

💡 낙관적 업데이트의 이면

• 가상 시나리오 1) 사용자가 좋아요 버튼 클릭 2) 좋아요 숫자 증가 및 버튼 액티브 UI 제공 3) 서버 API 호출 4) API 는 10분 대기 후 해당 로직 실행 5) 10분 후 해당 로직 수행 중 에러 발생 6) 좋아요 클릭 인터랙트 초기화 및 에러 메시지 표시

• 이처럼, 빠른 반응성을 제공하는 낙관적 업데이트이지만 추후 에러 발생 시 뒤늦은 에러 응답 발생
• 이에 따른 불쾌환 사용자 경험 제공
  

⚒️ 해결 방안

1. 타임아웃 설정
   • 서버 응답을 기다리는 최대 시간 설정
   • UX 저하 방지를 위해, 납득할 정도의 처리 시간 한도 설정
2. 로딩 상태 사용
   • 서버 응답이 오기 전까지, 페이지에 로딩 중임을 알리는 상태 추가
   • 빠른 응답성이라는 장점을 로딩 중 상태 표시에 사용하지만, 그만큼 안정적인 사용자 경험 제공
3. 백그라운드 재시도
   • 서버 요청 실패시, 에러 표시 대신 백그라운드로 요청 자동 재시도

3️⃣ SPA (Single-Page Application)

• 단일 페이지 어플리케이션
• 페이지 이동 시마다 서버에 전체 페이지를 요청하는 기본 방식과 달리, 최초 페이지 접근 한 번만 정적 리소스를 다운로드
  • 이후 상호작용 발생시, 페이지 새로고침을 하지 않고 JavaScript 로 필요한 데이터만 서버에서 비동기적으로 호출
  • 브라우저 캐싱을 통해 다운로드 리소스들은 재활용
  • 첫 로딩은 느릴 수 있어도, 이후 페이지 전환은 매우 빠름
• 이렇게 동적 업데이트 렌더링 수행
• CSR 방식을 극대화한 웹 애플리케이션 형태
  

4️⃣ Next.js 에서의 렌더링

• Next.js 는 SSR 과 CSR 을 함께 사용하는 하이브리드
• "use client" 사용 유무에 따라 SSR 과 CSR 을 구분
  • "use client" 사용 : CSR - 클라이언트 컴포넌트 렌더링
  • "use client" 미사용 : SSR - 서버 컴포넌트 렌더링
    

📌 "use client"

• 클라이언트 컴포넌트로 정의한다는 의미
• 브라우저만 사용할 수 있는 기능을 사용할 때 사용
• React Hooks을 사용하는 경우
  • ex) use() , useEffect() , useRouter() ...
• JavaScript 로 등록된 이벤트 핸들러가 존재하는 경우
  • ex) onClick() , onSubmit() , onChange() ...
• 브라우저 API를 사용하는 경우
  • ex) window.scrollTo() , document.title ...
    

💡 a 🆚 router 🆚 Link

• JavaScript 에서는 Link 나 <a> , router 등으로 페이지 이동 지원
  

🥇 <a>

• 브라우저 기본 링크 동작
• 클릭 시 서버에 새로운 페이지 요청
• 서버는 해당 페이지의 새로운 HTML 응답

• SSR

• 페이지 이동 이후, 해당 페이지의 "use client" 유무에 따라 CSR 추가
• 즉, SSR 로 시작하여 필요에 따라 CSR 추가로 사용자 인터랙션 제공
  

🥈 router

• JavaScript 이벤트 핸들러 내부에서 사용
• 페이지 전체를 새로고침하는 게 아니라, 필요한 데이터만 호출하여 페이지 업데이트

• CSR

• 즉, CSR 로 시작하여 사용자 인터랙션으로 인해 페이지가 이동되고, 이후 SSR 로 새로운 콘텐츠 응답
  

🥉 <Link>

• SPA 방식의 페이지 이동 지원
• 클릭 시 새로운 페이지 요청이 아닌, Next.js 가 미리 다운로드해 둔 필요한 JavaScript 및 데이터만으로 페이지 업데이트
  • 이렇게 다운로드 리소스를 미리 가져오는 것을 프리패칭(Prefetching) 이라고 함
• router 와 마찬가지로 새로고침 없이 페이지 전환

• SSR + CSR (하이브리드)

• SSR 로 초기 페이지 렌더링 이후, <Link> 페이지 이동 시에는 CSR 로 부드러운 페이지 전환
• Next.js 의 기본 제공 렌더링 방식으로, SPA 의 장점들을 모두 누릴 수 있음

검수) Google Gemini ( https://gemini.google.com/app )

  필자는 AOP 에 관심이 많다. 공부해오고 프로젝트를 진행해오면서 조금씩 AOP 관련 지식을 쌓아가며 AOP 기술을 점진적으로 발전시키며 활용해왔고, 프로젝트 중 하나에는 어노테이션을 이용해서 AOP 처리를 통해 인가를 적용한 후 코드 및 DB 호출의 중복을 방지하기 위해 ThreadLocal에 관련 정보를 저장해서 비즈니스 로직으로 전달하는 코드까지 구현해보았다.

  어느정도 AOP 에 대한 지식이 있다고 생각하고 있던 찰나, 최근 스프링 관련 강의를 들으며 공부를 하다보니 문득 궁금증이 생겼다.

'내가 구현한 AOP를 처리하는 프록시 객체는 뭘까?' '어떤 건 프록시고 어떤 건 실제 객체네? 뭐지?'

최근 스프링의 원리를 확실하게 이해하기 위해 강의를 들으며, 궁금한 부분은 바로바로 조사하고 공부하는 습관이 들어있다. 이번에 공부한 내용을 기록으로 남겨두면 여러모로 도움이 많이 될 것 같아서, 관련 내용을 따로 정리해보았다.

1️⃣ AOP 와 프록시

AOP

• 프로그래밍 패러다임
• 횡단 관심사를 중심으로 프로그램을 설계하는 방법
  • 여러 객체에 걸쳐 공통적으로 적용되는 기능
  • ex) 로깅, 트랜잭션, 캐싱 ...
• SOLID 중 OCP 원칙을 준수
  • AOP 는 기존 기능을 전혀 수정하지 않고, 로깅, 트랜잭션 등 부가기능을 추가
  • 즉, 일종의 확장에 해당
• 횡단 관심사를 하나로 모아 관리함으로, 코드의 유지보수성을 높이고 비즈니스 로직과 횡단 관심사를 분리하는 곳이 목표
  

프록시

• 디자인 패턴
• AOP 가 제시한 패러다임을 수행할, 대리자 역할의 객체를 생성하여 사용
• 프록시 객체를 통해, 타겟(실제 객체) 전후에 횡단 관심사를 처리 가능

2️⃣ 스프링 빈과 프록시 - @Component, @Configuration

@Component 과 프록시

• @Component 로 등록된 스프링 빈은 원칙적으로 실제 객체
  • 실제 객체가 스프링 컨테이너의 빈으로 등록
  • @Component 를 포함하고 있는 @Controller , @Service 등도 마찬가지
• 만약 컴포넌트 내에서 AOP 를 구현한 로직이 하나라도 존재할 경우, 실제 객체가 아닌 프록시 객체가 빈으로 등록
  • @Transactional 또한 내부에서 AOP 를 구현
  • 따라서 클래스 또는 내부 메서드에 @Transactional 이 하나라도 존재할 경우, 스프링 빈 등록 시 이를 탐지하여 타겟(실제 인스턴스)를 감싸고 있는 프록시 객체로 등록
• 프록시 객쳬 또한 실제 객체와 마찬가지로 @Component 로 등록되어 있으므로, 싱글톤 객체로 빈에 등록
  

@Configuration 과 프록시

• @Configuration 으로 등록된 클래스는, 프록시 객체가 스프링 빈으로 등록
  • CGLIB 라이브러리를 사용하여 바이트코드가 조작 된 프록시 객체
• @ComponentScan 진행 시, @Configuration 내의 모든 @Bean 을 찾아서 메서드명을 이름으로, 스프링 컨테이너에 스프링 빈으로 등록

3️⃣ 프록시 동작 흐름

@Component

• AOP 를 한 번이라도 구현한 경우 프록시 객체가 스프링 빈으로 등록
• 해당 비즈니스 로직이 호출되면 프록시 객체가 로직을 처리
  ### 🌊 FLOW
• 프록시 객체로 등록되었을 경우 :
  • Case1 -> @Transactional , @Aspect 등 AOP 가 적용된 경우
    • 프록시 객체가 해당 로직 실행 전후로 AOP 에 등록된 코드를 수행 후 proceed() 로 타겟 메서드 실행
  • Case2 -> @Transactional , @Aspect 등 AOP 가 적용되지 않은 경우
    • 프록시 객체는 AOP 를 적용하지 않고 바로 proceed() 로 타겟 메서드 실행

@Configuration

• 일반적으로 서버가 시작될 때, 스프링 빈 초기화 -> 스프링 의존관계 주입(DI) 순서로 진행
• @Configuration 으로 등록된 CGLIB 프록시 객체의 역할을 여기서 확인 가능
  ### 🌊 FLOW

1. 애플리케이션 시작 시 스프링 빈을 등록하고 초기화하는 과정에서, @Configuration 의 @Bean 메서드를 모두 호출
2. 해당 메서드가 다른 객체의 주입을 필요로 할 경우:
   • Case1 -> 해당 객체가 스프링 빈으로 등록되어 있다면, 해당 싱글톤 객체를 주입
   • Case2 -> 해당 객체가 아직 스프링 빈으로 등록되어 있지 않다면, 새로운 싱글톤 객체를 생성하여 스프링 빈으로 등록 후 해당 객체를 주입
3. 과정을 반복하여 모든 @Configuration 의 @Bean 메서드를 스프링 빈으로 등록
   

• 즉, @Configuration 의 가장 큰 역할은, 해당 클래스 내 모든 스프링 빈 객체의 싱글톤화

💡 @Configuration 또는 @Bean 이 없다면?

1️⃣ @Bean 만 단독으로 사용

• 컴포넌트 스캔 자체가 불가능
• 따라서 스프링 빈 등록 과정에서 @Bean 메서드 자체가 호출 불가능
• 스프링 빈 등록 실패
  

2️⃣ @Configuration 만 단독으로 사용

• 컴포넌트 스캔은 가능
• 따라서 CGLIB 프록시 객체가 스프링 빈으로 등록
• 하지만 @Bean 이 없으므로, 스프링 빈 등록 과정에서 메서드를 호출 불가능
• 내부의 메서드들은 스프링 빈 등록 실패
  

3️⃣ @Component + @Bean 조합으로 사용

• @Component 로 인해 실제 객체가 스프링 빈으로 등록
• 스프링 빈 등록 과정에서 @Bean 메서드 또한 호출 가능
• 하지만 @Bean 메서드 내부에서 다른 빈의 주입이 필요할 경우, 해당 메서드를 매번 호출
• TypeA 라는 빈을 여러 @Bean 메서드에서 DI 할 경우, 매번 다른 TypeA 인스턴스가 생성
• 따라서 빈 객체의 싱글톤이 보장되지 않음

⚒️ JDK Dynamic Proxy

• 타겟 클래스가 인터페이스의 구현체인 경우, AOP 적용 시 항상 JDK Dynamic Proxy 를 사용
  • 인터페이스 메서드만 가로챌 수 있음
  • 확장된 기능은 가로챌 수 없음
  • 메인 메서드 실행 클래스에 @EnableAspectJAutoProxy(proxyTargetClass = true) 설정을 해줌으로, 항상 CGLIB 프록시를 사용하도록 변경할 수 있음

  • 스프링부트 2.0 이상 버전부터는 proxyTargetClass = true 가 기본값으로 설정되어, 사실상 JDK 동적 프록시는 사용되지 않음

    public interface UserService {
    void findById(Long userId);
    void findByUsername(String username);
    }
    

@Service public class UserServiceImpl implements UserService {

@Override
void findById(Long userId) {
// 구현
}

@Override
void findByUsername(String username) {
// 구현
}

void findByEmail(String email) {
// 구현
}

}

```

• 현재 시나리오 :
  1. 인터페이스 UserService 가 존재
  2. 인터페이스 구현체 UserServiceImpl 이 존재
  3. @Service 로 이 클래스를 스프링 빈으로 등록
     

➡️ 스프링 빈 등록 구성

1️⃣ AOP 미적용 시

• 빈이름 : userServiceImpl
• 빈타입 : UserServiceImpl
• 빈실체 : new UserServiceImpl()
  
• AOP 미적용 시, 프록시 객체가 아닌 실제 인스턴스를 스프링 빈으로 등록
• 따라서 @Service 가 붙어있는 UserserviceImpl 을 대상으로 스프링 빈 등록
  

2️⃣ AOP 적용 시

• 빈이름 : userServiceImpl
• 빈타입 : UserService
• 빈실체 : UserService 구현 프록시 객체
  
• 현재 UserServiceImpl 의 경우, 인터페이스의 구현체
• 인터페이스 구현체에 AOP 를 적용하면, 반드시 JDK 동적 프록시에 의해 프록시 객체 생성
• JDK 동적 프록시는 인터페이스 대상 프록시
• 따라서 빈타입과 빈실체는 인터페이스 타입으로 등록
  

🥷 UserServiceImpl DI 🆚 UserService DI

1) UserServiceImpl DI :

• JDK 동적 프록시는 인터페이스 주입 시에만 사용
• UserServiceImpl 에 대해 AOP 를 적용했더라도, UserServiceImpl 를 DI 받으면 실제 UserServiceImpl 인스턴스가 주입

2) UserService DI:

• UserServiceImpl 에 대해 AOP 를 적용하면, UserService 를 DI 받아서 UserService 내의 모든 기능은 AOP 가 적용
• UserService 인터페이스가 특정 인터페이스를 상속받고, 그 인터페이스는 다른 특정 인터페이스를 상속받는 구조라도, AOP 가 UserServiceImpl 을 대상으로 적용되면 UserService 내의 모든 기능에서는 AOP 가 적용
• 확장된 기능은 사용할 수 없음

📋 즉, JDK 동적 프록시를 사용하면 확장된 기능에 대한 AOP 처리가 불가능하다.

📌 CGLIB

• 클래스 기반 프록시
• 인터페이스 구현체가 아닌 클래스에 AOP 적용 시, 해당 클래스 타입의 프록시 객체를 스프링 빈으로 등록
• UserService 관련 동일한 시나리오를 가정:
  

➡️ 스프링 빈 등록 구성

1️⃣ AOP 미적용 시

• 빈이름 : userServiceImpl
• 빈타입 : UserServiceImpl
• 빈실체 : new UserServiceImpl()
  
• @Component 클래스이므로, 동일하게 실제 객체 생성
  

2️⃣ AOP 적용 시

• 빈이름 : userServiceImpl
• 빈타입 : UserServiceImpl
• 빈실체 : UserServiceImpl 상속 프록시 객체
  
• CGLIB 는 빈 등록 시 모든 것을 클래스 기반으로 등록
• 따라서 UserServiceImpl 를 DI 받을 수 있으므로, 해당 클래스의 모든 기능에 AOP 를 적용 가능
  

🖇️ JDK Dynamic Proxy 🆚 CGLIB

1️⃣ JDK 동적 프록시

• 인터페이스 정의 메서드만 가로챌 수 있다는 명확한 한계
• AOP 를 구현체 대상으로 설정했을 때, 인터페이스 DI는 AOP 가 작동할 수 있지만 구현체 DI는 프록시 객체가 아닌 실제 구현체 인스턴스가 등록되므로 AOP 작동 불가능
  

🔗 SOLID

1) ISP 준수

• JDK 동적 프록시 특성상, AOP 적용을 위해서는 인터페이스 DI를 강제

2) OCP 위반

• 기능 확장의 경우, 인터페이스 구현체에서 추가적으로 구현하는 것이 일반적
• 하지만 AOP 를 적용하기 위해서는 앞서 말했듯, 인터페이스 DI가 강제
  • 인터페이스 구현체에서 기능을 확장하더라도, 해당 기능에 대한 AOP 적용 불가능
• 기능 확장에 AOP 를 적용하기 위해서는, 기존 인터페이스 수정이 필수불가결
  

2️⃣ CGLIB

• 클래스를 대상으로 프록시 객체 생성
• 구현체를 스프링 빈에 등록할 수 있으므로, AOP 작동에 관해서 자유로움

🔗 SOLID

1) ISP , DIP 위반 가능

• CGLIB 는 인터페이스 DI와 인터페이스 구현체 DI가 모두 가능
• 인터페이스 DI의 경우에는 JDK 동적 프록시와 마찬가지로, ISP 와 DIP 를 준수
• 단, 기능 확장 후 AOP 적용을 위해 구현체 DI를 할 경우, ISP 와 DIP 를 위반
• 하지만 JDK 동적 프록시 사용 시 기존 인터페이스 수정 없이는 확장된 기능 AOP 적용 불가능 이라는 큰 단점을 해소 가능

2) OCP 준수

• 기존 인터페이스 코드의 수정이 필요 없으므로 변경에는 확실히 닫혀있음
• CGLIB 는 프록시 객체가 구현체를 상속하기 때문에, 기능 확장 후 AOP 적용이 얼마든지 가능
• 단 이 경우 구현체 DI가 필요할 수 있으므로, ISP 와 DIP 를 위반

• CGLIB 가 훨씬 유연한 방식을 제공하므로, 현재 스프링 2.0 이상 버전부터는 프록시 객체 사용 시 CGLIB 사용이 기본값으로 변경

• CGLIB 를 사용함으로 얻을 수 있는 이점이 더 많다!

검수) Google Gemini ( https://gemini.google.com/app )

  스프링의 원리를 공부하던 도중, 익숙한 단어가 나왔다. SOLID , 좋은 객체 지향 설계의 5가지 원칙이다. 기존에도 당연히 알고 있던 개념이지만 사실상 원리를 이해하기 보다는 단순히 외우고만 있었던 개념이었으므로, 확실하게 알고 있다고는 단정할 수 없었다. SOLID 는 개발자라면 반드시 알고 실무에서 제대로 사용할 수 있어야 하는 개념이다. 이번 기회에, 보다 좋은 개발자가 될 수 있도록 SOLID 에 대한 확실한 이해를 목표로 학습 및 정리해보았다.

📕 SOLID

• 객체 지향 프로그래밍 및 설계에서 사용되는 5가지 기본 원칙
• 소프트웨어의 유지보수성, 가독성, 확장성을 향상시키는 것이 목표
  
  

📌 5가지 원칙

1️⃣ SRP (Single Responsibility Principle)

• 단일 책임 원칙

• 하나의 클래스는 반드시 하나의 책임만 가져야 함

  • 책임은 하나의 기능이라기보다는, 해당 클래스가 변경되어야 할 단 하나의 이유
  • 여러 이유로 변경될 수 있다면 SRP 위반
  • 한 가지 책임에 집중할 수 있도록, 클래스를 적절히 분리해서 설계해야 한다는 원칙

• 책임의 기준 및 범위는 개발자마다 다를 수 있음

  • MemberService 에 회원 도메인에 대한 로직을 모아두어도 (하나의 클래스에 하나의 기능만 존재하지 않더라도), 회원이라는 일관된 책임 내에서 동작하므로 SRP 위반이 아님

    // SRP 위반
    public class memberService {
    public void join(Member member) {
        // 회원 저장
    }
    
    public void sendMail(Member member) {
        // 이메일 발송
    }
    }

• 회원 저장과 이메일 발송이라는 서로 다른 두 가지 책임을 가지고 있으므로, SRP 위반

  // SRP 준수
  public class MemberService {
    public void join(Member member) {
        // 회원 저장
    }
  }
  

public class EmailService { public void sendMail(Member member) { // 이메일 발송 } }

- `MemberService` 는 __회원 도메인__에만, `EmailService` 는 __이메일 도메인__에만 집중하므로, `SRP` 준수
<br>

### 2️⃣ OCP (Open Closed Principle)
- __개방-폐쇄 원칙__
- 소프트웨어는 __확장에는 열려있고 변경에는 닫혀있어야 함__
  - 기능 추가 및 변경 시 __클래스 확장__을 통해 쉽게 구현할 수 있도록 하되, __기존 클래스의 수정은 최소화__할 수 있도록 설계
  - __역할__과 __구현__의 분리
- __다형성__을 활용
  - __인터페이스__를 활용하고, 정책에 따라 다양한 __구현체__를 제공
  - __객체지향__의 장점을 __극대화__할 수 있음
- __스프링__은 `IOC` 및 `DI` 를 통해 __해당 원칙을 준수__할 수 있도록 설계되어있음
```java
// OCP 위반
public class DiscountService {
    public int getNormalDiscountRate() {
        // 할인율 로직
    }
}

• VIP , GOLD 등 새로운 정책 추가 시 클래스 수정 필요

  // OCP 준수
  public interface DiscountPolicy{
    int getDiscountRate();
  }
  

public class VipDiscountPolicy implements DiscountPolicy { public int getDiscountRate() { // VIP 할인율 로직 } }

public class NormalDiscountPolicy implements DiscountPolicy { public int getDiscountRate() { // 일반 할인율 로직 } }

public class DiscountService { private final DiscountPolicy discountPolicy;

public DiscountService(DiscountPolicy discountPolicy) {
    this.discountPolicy = discountPolicy;
}

public int discount() {
    return discountPolicy.getDiscountRate();
}

}

- 새 정책 추가 시, `DiscountPolicy` 구현체만 추가하여 주입하면 됨
<br>

### 3️⃣ LSP (Liskov Substitution Principle)
- __리스코프 치환 원칙__
- __하위 타입__은 언제나 __상위 타입__으로 교체할 수 있어야 함
  - __다형성__을 제대로 활용하기 위한 __원칙__
  - __상위 클래스 타입__으로 __하위 클래스 객체__를 받더라도 (업캐스팅), __기능__이 원하는대로 동작해야 한다는 의미
  - __기능적 의미를 해치는, 부적절한 오버라이딩__을 하지 않도록 설계
  - __부모__의 `sleep()` 이라는 __잠자는 의미__의 메서드를, __자식__이 __달리기__라는 의미로 __오버라이딩__하면 `LSP` 원칙을 위반
```java
// LSP 위반
class Parent {
    int[] location = {0, 0};

    void sleep() {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {}
    }
}

class Child extends Parent {
    @Override
    void sleep() {
        location[0]++;
    }
}

• 부모는 쓰레드 대기의 의미로 sleep() 메서드를 구현했지만, 자식은 움직이기의 의미로 sleep() 메서드를 오버라이딩

  • 메서드의 의도와 의미가 전혀 달라지므로 LSP 위반

    // LSP 준수
    class Parent {
    int[] location = {0, 0};
    
    void sleep() {
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {}
    }
    }
    

class Child extends Parent { @Override void sleep() { try { Thread.sleep(2000); } catch (InterruptedException e) {} } }

- 부모와 자식 모두 __쓰레드 대기__의 의미로 `sleep()` 메서드를 구현
<br>

### 4️⃣ ISP (Interface Segregation Principle)
- __인터페이스 분리 원칙__
- __인터페이스 하나__에 많은 기능을 담기보다는, 각각의 사용처에 맞게 __여러 개로 분리__해야 함
  - `SRP` 는 __클래스 분리__의 원칙이라면, `ISP` 는 __인터페이스 분리__의 원칙
- __특정 클라이언트__를 위해 __적합한 인터페이스__만을 제공하는 것이 목표
- 인터페이스를 한 번 __구성해뒀으면__ 웬만해서는 __변경시키면 안됨__
- __인터페이스가 보다 명확해지고, 대체 가능성의 증가로 유지보수성 향상__
```java
// ISP 위반
interface Machine {
    void print();
    void scan();
    void fax();
}

class PrintMachine implements Machine {
    public void print() {
        // 프린트
    }

    public void scan() {
        throw new RuntimeException("스캔은 사용할 수 없음");
    }

    public void fax() {
        throw new RuntimeException("팩스는 사용할 수 없음");
    }
}

• PrintMachine 은 프린트 기능만 필요하지만, scan() , fax() 도 반드시 구현해야 하므로 ISP 위반

  // ISP 준수
  interface Printer {
    void print();
  }
  

interface Scanner { void scan(); }

class PrintMachine implements Printer { public void print() { // 프린트 } }

- `PrintMachine` 은 __프린트__에 필요한 `Printer` 인터페이스만 구현하면 됨
<br>

### 5️⃣ DIP (Dependency Inversion Principle)
- __의존관계 역전 원칙__
- __구체화__에 의존해선 안되고, __추상화__에 의존해야 함
  - __구현 클래스__에 의존하지 말고, __인터페이스__에 의존할 것
  - __역할__에 의존하도록 설계
  - __변경되기 쉬운 것__보다 __변경되기 어려운 것__에 의존하도록 설계
- __클래스__간의 __결합도__를 낮추는 것이 목표
- __스프링__은 `IOC` 및 `DI` 를 통해 __해당 원칙을 준수__할 수 있도록 설계되어있음
```java
// DIP 위반
public class OrderService {
    private final DiscountPolicy discountPolicy = new VipDiscountPolicy();

    public int order() {
        return discountPolicy.getDiscountRate();
    }
}

• VipDiscountPolicy 에 의존하고 있으므로, 다른 정책으로 변경을 원하면 해당 클라이언트 코드의 수정이 필요

  // DIP 준수
  public class OrderService {
    private final DiscountPolicy discountPolicy;
  
    public OrderService(DiscountPolicy discountPolicy) {
        this.discountPolicy = discountPolicy;
    }
  
    public int order() {
        return discountPolicy.getDiscountRate();
    }
  }

• 외부에서 DiscountPolicy 구현체를 주입하므로, 정책에 따라 자유롭게 교체할 수 있음

• 스프링에서는 @Component , @Autowired 등의 기능을 통해 이 구조를 쉽게 구현 가능

참고) OpenAI. (2024).ChatGPT(4o)[Large language model].https://chatgpt.com/

 스프링으로 프로그래밍을 하다보면, 디버깅할 때나 실행할 때나 지긋지긋하게 보이는 것이 있다. 바로 DispatcherServlet 이다.

  이토록 지겹게 마주치는 서블릿이지만, 이 서블릿이 하는 일을 설명해보라 했을 때 자세하게 설명할 수 있는 자신은 없다.   물론 대강 어떤 역할을 하는지는 어렴풋이 눈치채고 있지만, 눈치껏 아는 것과 확실히 개념을 알고 이해하고 있는 것은 하늘과 땅 차이이다.

  서블릿은 사실상, 웹 개발에서 떼려야 뗄 수 없는 관계이다. 그렇기 때문에 더더욱, 서블릿의 역할과 하는 일들은 확실하게 이해하고 있어야 한다.   그런 이유로, 금일은 서블릿에 대해서 학습하고 이를 정리하는 시간을 가져보고자 한다.

📑 서블릿 (Servlet)

• 자바 기반의 웹 애플리케이션을 개발할 때 사용되는 서버 측 기술
• 클라이언트로부터 __ HTTP 요청을 받아 이를 처리한 후, __응답을 반환하는 역할을 하는 자바 기반의 웹 컴포넌트
• 웹 서버에서 실행되는 Java 프로그램이며, Java EE (= Jakatra EE)의 표준 기술
  
  

🗒️ 서블릿의 특징

1. Java 기반

   • Java 로 작성되므로, 플랫폼 독립성이 뛰어남
     

2. HTTP 요청 및 응답 처리

   • HttpServlet 을 상속 받아 GET 이나 POST 같은 HTTP 요청을 처리
     

3. 멀티스레드 환경

   • 서블릿 컨테이너가 1개의 서블릿 인스턴스를 여러 요청에 대해 재사용
   • 각 요청마다 스레드 풀 내에서 해당 서블릿의 스레드를 생성
   • Tomcat 의 경우, 기본값으로 200개의 작업 스레드가 존재
     

4. MVC 패턴의 컨트롤러 역할

   • JSP 나 템플릿 엔진과 결합해 View 를 렌더링 후 응답으로 반환
     
     

➡️ 서블릿의 동작 방식 및 생명주기

1. 서블릿 클래스 로드

   • 서블릿 컨테이너는 웹 애플리케이션이 시작될 때나 서블릿에 요청이 처음 들어왔을 때, 서블릿 클래스를 메모리에 로드
   • 서블릿 클래스는 web.xml 혹은 @WebServlet 을 통해 URL 과 매핑되며, 클라이언트의 요청이 해당 서블릿에 전달될 수 있도록 설정됨
     

2. 서블릿 인스턴스화

   • 서블릿 클래스가 로드되면, 서블릿 컨테이너는 해당 클래스로부터 서블릿 인스턴스 생성
   • 서블릿 생성자는 단 한 번만 호출되며, 이 때 객체가 초기화됨
     

3. 초기화 메서드 호출 - init()

   • 서블릿 인스턴스 생성 후, 서블릿 컨테이너는 init() 를 호출하여 서블릿 초기화
   • 서블릿 초기화 시 설정 정보를 불러오거나, 자원을 할당하는 작업 등을 수행 가능
   • 마찬가지로 init() 메서드 또한 단 한 번만 호출되며, 이 서블릿은 종료될 때까지 유지됨
     

4. 요청 처리 메서드 호출 - service()

   • 클라이언트가 요청을 보내면, 서블릿 컨테이너는 해당 요청을 서블릿에 전달한 후 service() 메서드 호출
   • service() 메서드는 클라이언트의 요청을 처리하며, HTTP 요청 방식에 따라 doGet() , doPost() 등 적절한 메서드 호출
   • 각 메서드는 클라이언트의 요청을 처리한 후 응답을 생성
     

5. 응답 반환

   • 서블릿은 HttpServletResponse (응답 객체) 를 사용하여 클라이언트에게 응답을 반환
     

6. 서블릿 종료 메서드 호출 - distroy()

   • 웹 애플리케이션 또는 서블릿 컨테이너가 종료되거나 서블릿을 제거하려 할 때 distroy() 메서드 호출
   • 서블릿이 종료되기 전에 정리 작업 진행
   • ex) 열린 자원 닫기, 데이터 정리 ...

📖 서블릿 컨테이너 와 서블릿 컨텍스트

1️⃣ 서블릿 컨테이너 (Servlet Container)

• 서블릿을 실행하고 관리하는 환경
• Apache Tomcat , Jetty , WildFly , GlassFish 등의 웹 애플리케이션 서버(WAS) 안에 포함되어 있음
  • WAS 는 서블릿 컨테이너의 역할 뿐만 아니라, JSP 실행, 트랜잭션 관리, 데이터 소스 관리 등의 기능 또한 제공
  • 즉, 서블릿 컨테이너 + α
  • Spring MVC 같은 프레임워크도 실행할 수 있도록 지원
• 위와 같은 WAS 내에서 서블릿을 실행할 수 있도록 도와주는 역할
• 단독으로 실행될 수도 있음
  

🦾 서블릿 컨테이너의 역할

• 서블릿의 생명주기 관리
• HTTP 요청 및 응답 처리
• 멀티스레드 지원
• 세션 및 쿠키 관리
• JSP 컴파일 및 실행
• 서블릿 컨텍스트 제공
  
  

2️⃣ 서블릿 컨텍스트 (Servlet Context)

• 웹 애플리케이션 전체에서 공유되는 정보와 리소스를 관리하는 객체
• 애플리케이션 전역에서 사용되는 설정 정보나 공유 자원을 제공하는 역할
• getServletContext() 로 접근 가능
  

🦾 서블릿 컨텍스트의 역할

• 애플리케이션 전역에서 공유할 데이터 저장
  • setAttribute() , getAttribute() ...
• 초기화 파라미터 관리
  • web.xml 에서 설정한 파라미터
• 웹 애플리케이션 내의 리소스 접근
  • getResourceAsStream()
• 로깅 지원
  • log()
• 다른 서블릿과의 통신
  • getRequestDispatcher()

⭐ DispatcherServlet

• Spring MVC , 즉 Spring 프레임워크에서 사용되는 서블릿
• Spring Boot 와 함께 가장 많이 사용됨
• 서블릿 컨테이너는 모든 HTTP 요청을 DispatcherServlet 으로 전달
• 하나의 DispatcherServlet 이 여러 컨트롤러의 액션 메서드를 라우팅하여 실행

@RestController
@RequireMapping("/api/hotels")
public class HotelController {
    @GetMapping
    public List<Hotel> getHotels() {
        // ...
    }
}

• /api/hotels 경로로 요청이 오면 DispatcherServlet 이 HandlerMapping 을 통해 해당 컨트롤러의 getHotels() 메서드 호출
  
  

➡️ Spring MVC 에서의 서블릿 실행 흐름

1. 클라이언트가 HTTP 요청 보냄
   
2. 서블릿 컨테이너가 요청을 받음
   • web.xml 또는 Spring Boot 설정을 통해 DispatcherServlet 이 요청을 받도록 설정
   • Spring Boot 는 별도의 설정없이 자동으로 DispatcherServlet 을 등록
   • 서블릿 컨테이너는 요청을 DispatcherServlet 으로 전달
     
3. DispatcherServlet 이 요청을 분석하고 핸들러(Controller)를 찾음
   • HandlerMapping 을 사용하여, 어떤 컨트롤러 및 메서드가 요청을 처리할지 결정
     
4. 액션 메서드를 실행하고 결과를 반환
   • HandlerAdapter 가 HandlerMapping 이 찾아낸 컨트롤러의 액션 메서드를 실행한 후 결과를 반환
     
5. DispatcherServlet 이 View 를 선택하거나 JSON 응답을 반환
   • ViewResolver 를 사용해 적절한 JSP , Thymeleaf 같은 View 를 선택
   • 또는, JSON 응답 반환

💡 HandlerMapping 과 HandlerAdapter

- Spring MVC에서 요청을 적절한 컨트롤러로 연결하고 실행하는 핵심 컴포넌트
- DispatcherServlet이 서블릿 컨테이너 내에서 요청을 처리할 때 사용하는 핵심 인터페이스

1️⃣ HandlerMapping

• 요청 URL을 보고, 해당 요청을 처리할 컨트롤러(핸들러)를 찾아서 라우팅해주는 역할
  

2️⃣ HandlerAdapter

• HandlerMapping 이 찾아낸 컨트롤러의 액션 메서드를 실제로 실행하는 역할
• 컨트롤러의 타입 ( @RequestMapping , @RestController , @Controller )를 확인하고, 적절한 방식으로 호출

🤔 HandlerMapping 과 HandlerAdapter 가 없으면?

• DispatcherServlet 은 컨트롤러로 연결할 방법을 알 수 없음
  • HTTP 요청이 오더라도, 이를 어떤 컨트롤러가 처리해야 할지 판단 불가
• 만약 컨트롤러를 찾더라도, 이를 실행할 방법을 알지못함
  

- 즉, HandlerMapping 과 HandlerAdapter 는 DispatcherServlet 이 요청을 적절한 컨트롤러의 메서드로 연결하고 실행하는 핵심 역할을 함

참고) OpenAI. (2024).ChatGPT(4o)[Large language model].https://chatgpt.com/

  스프링 시큐리티를 복습하던 도중, '추후 학습해야지' 하고 넘어갔던 부분을 발견했다.

 스프링 시큐리티에서 CustomFilter 를 생성할 때, OncePerRequestFilter 라는 것을 상속받는다.   이름만 보고도 요청마다 단 한 번만 실행되는 필터라는 것은 알 수 있을 것이다.   하지만 이 필터가 언제 주로 사용되는 것이고, 정확히 어떤 것인지는 확실히 알지 못한다.

  이번 기회에 이전에 넘겼던 이 OncePerRequestFilter 를 메인으로, 필터에는 어떤 것들이 있고 어떻게 주로 사용되는지 등을 정리해보는 시간을 가져보고자 이 포스팅을 작성하게 되었다.

📑 OncePerRequestFilter

• Spring 에서 제공하는 Filter 로, 한 요청 당 한 번만 실행되는 것을 보장하는 필터
  • 기본적으로 서블릿 필터를 직접 구현하면, 하나의 요청이 여러 번 필터 체인을 통과할 수도 있음
  • OnceperRequestFilter 의 경우 이러한 것을 미연에 방지하고, 한 요청에 대해 딱 한 번만 실행되도록 자동으로 처리
• 내부적으로 isAsyncDispatch() 와 shouldNotFilter() 를 활용하여 비동기 요청 이나 특정 조건에 따른 필터 실행 제외 도 가능

public abstract class OncePerRequestFilter implements Filter {
    @Override
    public final void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        HttpServletRequest httpRequest = (HttpServletRequest) request;
        HttpServletResponse httpResponse = (HttpServletResponse) response;

        // 비동기 요청은 필터를 실행하지 않도록 설정
        if (isAsyncDispatch(httpRequest)) {
            filterchain.doFilter(request, response);
            return;
        }

        doFilterInternal(httpRequest, httpResponse, filterChain);
    }
}

• 인증과 인가의 경우, 요청 당 한 번만 실행되면 되기 때문에(ex: JWT 토큰 검사), 인증, 인가에서 주로 사용

  @Component
  public class JwtAuthenticationFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        String token = request.getHeader("Authorization");
  
        if (token != null && token.startsWith("Bearer ")) {
            String jwt = token.substring(7);
        }
  
        // jwt 활용
  
        filterChain.doFilter(request, response);
    }
  }

• 모든 요청에 대한 한 번의 로깅만 필요한 경우도 사용

  @Component
  @Slf4j
  public class LoggingFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        log.info("필터 로그");
        filterChain.doFilter(request, response);
    }
  }

• 특정 요청에 대해서 헤더 변경 시에도 사용

  @Component
  public class CustomHeaderFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        response.setHeader("newHeader", "header_value")
        filterChain.doFilter(request, response);
    }
  }

• CORS (Cross-Origin Resource Sharing) 필터 로도 사용이 가능

• 다른 도메인(출처)에서 요청이 올 경우, 이에 따른 CORS 규칙을 적용

• 이러한 경우에도 모든 요청에 대해서 한 번만 적용하면 되므로, OncePerRequestFilter 사용

  @Component
  public class CustomCorsFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        response.setHeader("Access-Control-Allow-Origin", "*");
        response.setHeader("Access-Control-Allow-Methods", "GET");
        response.setHeader("Access-Control-Allow-Headers", "Authorization, Content-Type");
  
        filterChain.doFilter(request, response);
    }
  }

  모든 GET 요청에 대한 CORS 정책 사용

🤔 OncePerRequestFilter 를 사용하는 이유

1. 중복 실행 방지

• 앞서 언급했듯, 스프링 시큐리티 필터 체인은 다양한 필터를 거치며 요청을 처리하는데, 같은 요청이 여러 번 동일한 필터를 통과할 수도 있음
• RequestDispatcher.forward() 나 include() 메서드를 사용하면 같은 요청이 필터를 다시 탈 수 있음
• 이러한 중복 실행을 방지하고자 OncePerRequestFilter 를 사용

2. 요청 스레드의 일관성 유지

• 필터 내부에서 SecurityContext 같은 요청 관련 정보를 설정하고 사용하게 되면, 필터가 여러 번 실행될 경우 정보가 덮어씌워질 수도 있음
• OncePerRequestFilter 를 사용하면 필터가 단 한 번만 실행되므로 정보를 일관되게 유지할 수 있음

3. 스프링 시큐리티

• 보완 관련 필터를 만들 때 가장 많이 사용
• UsernamePasswordAuthenticationFilter 같은 기본 필터들이 내부적으로 OncePerRequestFilter 를 상속받아 사용

⭐ 필터에서 자주 쓰이는 기능

1. forward

• 현재 요청을 새로운 URL로 이동시킴
• 단, 클라이언트도 이동 사실을 모르게 실행
• 요청을 다른 Servlet 및 JSP 로 전달할 때 사용
• 새로운 요청을 생성하지 않음 (기존 요청 객체 유지)
• 클라이언트는 URL이 바뀌지 않음

  request.getRequestDispatcher("/").forward(request, response);

  
  

2. redirect

• 현재 요청을 클라이언트에게 새로운 URL로 이동하라고 응답
• 클라이언트는 이를 통해 새로운 요청을 보냄
• 따라서 새로운 요청이 생성됨
• 클라이언트가 새로운 URL을 요청하도록 유도 (브라우저의 URL도 변경)
• 일반적으로 POST 요청 후 redirect 를 통해 GET 요청으로 반환

response.sendRedirect("/");

3. include

• 현재 요청을 처리하는 동안 다른 서블릿 또는 JSP의 출력을 포함
• 공통 헤더, 푸터를 여러 페이지에서 포함할 때 주로 사용
• 기존 요청을 유지하면서 일부 응답 포함
• forward 와의 차이점은, 기존 페이지 일부에 다른 서블릿 내용을 포함한다는 점

  RequestDispatcher dispatcher = request.getRequestDispatcher("/header.jsp");
  dispatcher.include(request, response);

  
  

4. setAttribute

• 요청에 데이터를 저장하여 다른 서블릿/JSP에서 사용할 수 있게 만듦
• request.setAttribute() 로 저장한 데이터는 요청이 유지되는 동안 사용 가능
• forward 와 함께 사용하면 유용함

  request.setAttribute("userRole", "ADMIN");

📖 그 외 필터의 종류

1. GenericFilterBean

• 스프링에서 제공하는 일반적인 필터
• 스프링의 Bean 으로 등록되어 DI 를 쉽게 가능
• 요청당 한 번 실행을 보장하지 않음
• 필요하다면 직접 실행 횟수 조절이 필요

  @Component
  public class CustomFilter extends GenericFilterBean {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws ServletException, IOException {
        filterChain.doFilter(request, response);
    }
  }

  
  

2. CharacterEncodingFilter

• 요청과 응답의 문자 인코딩을 설정하는 필터

• 일반적으로 UTF-8 인코딩을 적용할 때 사용

• 웹 애플리케이션이 해당 인코딩을 강제하도록 설정 가능

  @Bean
  public FilterRegistrationBean<CharacterEncodingFilter> encodiginFilter() {
    CharacterEncodingFilter filter = new CharacterEncodingFilter();
    filter.setEncoding("UTF-8");
    filter.setForceEncoding(true);
  
    FilterRegistrationBean<CharacterEncodingFilter> registrationBean = new FilterRegistrationBean<>();
    registrationBean.setFilter(filter);
    return registrationBean;
  }

  
  

3. CorsFilter

• CORS 설정을 담당하는 필터

• 다른 도메인의 요청을 허용할지 결정

• @CrossOrigin 과 함께 사용 가능

• 특정 도메인에서만 요청을 허용하도록 설정도 가능

  @Bean
  public CorsFilter corsFilter() {
    UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
    CorsConfiguration config = new CorsConfiguration();
  
    config.setAllowCredentials(true);
    config.addAllowedOrigin("*")    // 모든 도메인에 대한 요청 허용
    config.addAllowedMethod("*")    // 모든 HTTP 메서드 요청 허용
    config.addAllowedHeader("*")    // 모든 헤더 요청 허용
  
    source.registerCorsConfiguration("/**", config);
    return new CorsFilter(source);
  }

  
  

4. HiddenHttpMethodFilter

• PUT , DELETE HTTP 메서드를 POST 요청에서 사용할 수 있게 해줌
• <form> 태그는 기본적으로 GET 과 POST 만 지원하므로, 이를 해결할 때 유용

📚 doFilter()와 doFilterInternal()

1. doFilter()

• javax.servlet.Filter 인터페이스에서 제공하는 기본 메서드
• 모든 서블릿 필터는 doFilter() 의 직접 구현이 필요
• 요청 시 doFilter() 가 실행되고, 다음 필터로 전달하기 위해서는 filterChain.doFilter(request, response) 를 호출해야 함
• 즉, Filter 인터페이스를 직접 구현하는 경우에는 doFilter() 메서드를 반드시 오버라이드 해야 함

2. doFilterInternal()

• OncePerRequestFilter 에서 제공하는 추상 메서드
• doFilter() 의 내부에서 doFilterInternal() 이 호출
• 따라서, 개발자는 doFilter() 대신 doFilterInternal() 만 구현하면 됨
• doFilter() 는 OncePerRequestFilter 가 자동으로 관리하며, 요청이 여러 번 필터 체인을 통과하는 것을 미연에 방지
  

✒️ 정리

• 일반적인 Filter 인터페이스에서는 doFilter() 를 구현
• OncePerRequestFilter 를 상속받는다면, 대신 doFilterInternal() 만 구현

참고) OpenAI. (2024).ChatGPT(4o)[Large language model].https://chatgpt.com/

 3주간의 프로젝트가 종료되었다. 이번 프로젝트는 스스로 굉장히 얻은 게 많은 프로젝트였다. 이후 프로젝트 회고에서 다룰 예정이지만, 어렵고 힘든 일들도 많았으나 결과적으로 어느정도 괜찮은 퀄리티의 결과물을 뽑아낸 듯하여 조금 마음이 놓인다.

&nbsp 이번 우리 팀 프로젝트 주제는 호텔 예약이다. 이 프로젝트에서 필자는 호텔 및 객실 도메인의 작업을 맡아서 진행하였다. 그러다보니 가장 많이 생각해본 부분이 바로 성능이다. 호텔과 객실이라는 굉장히 많은 양의 데이터들을 어떻게 하면 좀 더 효과적으로 다룰 수 있을까.

  지금 프로젝트에는 default_batch_fetch_size 가 적용되어있다. 처음에는 이거 하나로 N+1 문제를 전부 해결할 수 소리를 듣고 더욱 최적화할 수 있는 쿼리 생성에 집중했지만, 강사님과의 Q&A 이후로 배치를 적용하기로 결정했다.

&nbsp 추가로, 1:N 의 데이터를 가져오기 위해서 어떤 방법이 가장 좋을까에 대해서도 많은 고민이 있었다. JOIN 을 여러 번 사용하는 것과 Batch Fetching 중 어떤 것이 더 좋은 성능을 발휘할 수 있을까. DB에서 일부 데이터만 가져오고 내부 메모리에서 변환 과정을 거치는 것이 좋을까, DB 에서 모든 작업을 끝내고 가져오는 것이 더 좋을까. 지금 이 프로젝트에는 어떤 것이 더 좋을까.

&nbsp 현재는 호텔의 정보를 가져올 때 호텔 이미지의 썸네일을 가져오기 위해, 이미지 DB의 첫번째 값을 가져오기 위해서 조건문에 서브쿼리를 추가하였다. 지금 당장은 싱글 서버의 소규모 데이터셋을 가지고 진행하는 프로젝트이기 때문에 이러한 방법을 적용했지만, 지금의 이러한 방식은 이후 데이터가 늘어남에 따라 성능저하를 일으킬 수 있는 원인이 되기에 수정해야할 부분이다.

&nbsp이렇듯, 어떻게 보면 간단한 CRUD 작업일지라도 성능에 대한 고려를 하다보니 생각보다 많은 고민이 필요했다.

&nbsp앞으로 수없이 직면할 이러한 문제들을 더욱 더 효과적으로 해결하기 위해, N+1 에 대한 확실한 학습이 필요하다. 프로젝트가 끝난 기념으로 N+1 문제에 대해서 정리해보고자 한다.

📖 N+1 문제

• ORM 환경에서 발생하는 성능 문제로, 1개의 쿼리를 실행할 때 추가적으로 N개의 쿼리가 발생하는 현상
• 주로 JPA 와 같은 ORM 에서, 연관된 데이터를 Lazy Loading 으로 가져올 때 발생

@Entity
@Builder
public class Hotel {
    @Id
    @GeneratedValue(strategy = GenerationType.Identity) // 이후 생략
    private Long id;

    @Column
    private String hotelName;

    @OneToMany(mappedBy = "hotel")
    @Builder.Default
    private List<Room> rooms = new ArrayList<>();
}

@Entity
public class Room {
    // ...

    private String roomName;

    @ManyToOne
    private Hotel hotel;
}

• 알다시피, @OneToMany 의 기본 FetchType 은 Lazy
• hotelRepository.findAll() 로 전체 Hotel 의 정보를 가져올 시
  • 여기서 SELECT 쿼리가 1번 발생
• Hotel 에는 현재 실제 Room 들의 값이 들어있는 것이 아닌, 해당 Room 들의 주소값을 포함하고 있는 Proxy 객체를 갖고 있음
• 이후 Room 의 정보를 얻으려고 할 시
  • Room 에 대한 SELECT 쿼리를 여기서 다시 실행

결과적으로 Hotel 을 가져올 때 1번, Room 의 정보를 가져올 때 N 번, 총 N+1 번의 쿼리가 실행됨

• 쿼리의 총 개수가 적다면 크게 문제가 되지 않을 수 있지만, 큰 규모에서는 이렇게 추가로 생성된 쿼리로 인해 문제가 생길 가능성이 높음

• 즉, 성능에 큰 영향을 미칠 수 있는 아주 중요한 부분

💡 N+1 문제 해결 방법

1️⃣. Fetch Join

• 1:N 연관관계에서 연관된 엔티티를 한 번에 조회할 때 사용
• 필요할 데이터들을 모두 한 번에 가져올 수 있음
• N+1 을 해결하기 위한 가장 좋은 방법
• 단, 페이징이 되지 않는다는 단점이 있음
• 또한 Repsitory 에서 한 번에 DTO 로 반환 시 사용할 수 없음
  • 이는 Fetch Join 방식은 엔티티 그래프를 한 번에 로딩하는 방식이기 때문
  • DTO 프로젝션은 엔티티를 가져오는 게 아닌, 특정 필드만 가져오는 방식
  • Fetch Join 은 엔티티 전쳬를 조회해야 동작하므로, DTO 와 함께 사용 불가능
    ```java @Query("SELECT h FROM Hotel h JOIN FETCH h.rooms") List findAllHotels(); ```
• 실제 쿼리가 실행될 때 JOIN Room r ON h.id = r.hotel_id 가 발생
  
  

2️⃣. Batch

1. @BatchSize 를 통한 배치 사이즈 조정

   @OneToMany(mappedBy = "hotel")
   @BatchSize(size = 50)
   private List<Room> rooms;

   
   

2. Global 설정을 통한 배치 사이즈 조정

spring:
  jpa:
    properties:
      hibernate.default_batch_fetch_size: 50

• 배치 사이즈를 50으로 고정
• SELECT * FROM Room WHERE room_id IN (1, 2, 3.... 49, 50) 같이 실행 ( IN 이 사용됨)
• 한 번 Hotel 의 데이터를 가져올 때 50개의 Room 데이터를 함께 가져옴
• 50개 이후의 데이터를 가져올 때는 또 다시 N+1 문제가 발생
  
  

3️⃣. @EntityGraph

• Fetch Join 을 사용하지 않는 방법
• 복잡한 경우 한계가 존재

  @EntityGraph(attributePaths = {"Room"})
  @Query("SELECT h FROM Hotel h JOIN FETCH h.rooms")
  List<Hotel> findAllHotels();

📑 여러 개의 @OneToMany

• 하나의 Entity 에 여러개의 @OneToMany 가 달려있는 경우도 있음
• 이러한 경우에 가장 좋은 방법은 크게 2가지
  

1️⃣ BatchSize 조정

@OneToMany(mappedBy = "hotel")
@BatchSize(size = 50)
private List<Room> rooms;

@OneToMany(mappedBy = "hotel")
@BatchSize(size = 50)
private List<Review> reviews;

혹은

spring:
  jpa:
    properties:
      hibernate.default_batch_fetch_size: 50

• 마찬가지로 BatchSize 조정을 통해 한 번에 여러 개의 데이터를 가져오는 방법
  

2️⃣ 쿼리 분리

• @OneToMany 관계는 따로 조회하고, 이후에 어플리케이션 레벨에서 조립하는 방식
  

1. 기존 프로젝트에서 사용한 쿼리

@Query("""
    SELECT new com.ll.hotel.domain.hotel.hotel.dto.HotelWithImageDto(h, i)
    FROM Hotel h
    LEFT JOIN Image i
    ON i.referenceId = h.id
    AND i.imageType = :imageType
    WHERE h.hotelStatus <> 'UNAVAILABLE'
    AND (i.createdAt = (
        SELECT MIN(i2.createdAt)
        FROM Image i2
        WHERE i2.referenceId = h.id
        AND i2.imageType = :imageType
        )
    OR i is NULL)
    AND h.streetAddress LIKE %:streetAddress%
    """)
Page<HotelWithImageDto> findAllHotels(@Param("imageType") ImageType imageType,
                                          @Param("streetAddress") String streetAddress, PageRequest pageRequest);

• Image 테이블의 이미지 타입이 호텔인 이미지들 중 해당하는 첫 번째 이미지(썸네일)만 가져오기 위한 서브쿼리
• 이 쿼리는 현재는 데이터셋이 작기 때문에 큰 문제가 없음
• 하지만 이후 데이터가 커지면 매 호텔마다 서브쿼리가 발생하기 때문에 성능 문제가 생길 수 있음
  

2. 이를 분리한 쿼리

   @Query("""
    SELECT h
    FROM Hotel h
    WHERE h.hotelStatus <> 'UNAVAILABLE'
    AND h.streetAddress LIKE %:streetAddress%
    """)
   Page<Hotel> findHotels(@Param("streetAddress") String streetAddress, Pageable pageable);
   

@Query(""" SELECT i FROM Image i WHERE i.imageType = :imageType AND i.createdAt IN ( SELECT MIN(i2.createdAt) FROM Image i2 WHERE i2.referenceId IN :hotelIds AND i2.imageType = :imageType GROUP BY i2.referenceId ) """) List findFirstImages(@Param("imageType") ImageType imageType, @Param("hotelIds") List hotelIds);

```

• 조건에 맞는 호텔들을 먼저 조회
• 해당하는 호텔의 ID 를 사용하여, 해당 호텔들의 첫 번째 이미지들만 배치로 조회
• 이후 이 두 결과를 애플리케이션 레벨에서 매칭하여 HotelWithImageDto 로 변환
• 이렇게 되면, 서브쿼리가 호텔마다 중복 실행되지 않으므로 성능의 이점이 있음

• 현재는 데이터셋이 많지 않고 실제 서비스가 아닌 프로젝트 레벨이기 때문에, 쿼리를 따로 분리하지 않음

• 데이터셋이 그렇게 크지 않으므로 메모리에서 처리하는 게 더 유리하다고 판단
• 3차 프로젝트를 진행하면서 더 생각해봐야 할 것 같음
• 현대 과학의 발전으로 인해 트레이드 오프로 유지보수성을 챙기는 게 웬만해선 좋을 것으로 판단 중

참고) OpenAI. (2024).ChatGPT(4o)[Large language model].https://chatgpt.com/

  프로젝트 진행으로 한창 바쁜 요즘이다.

  1차 프로젝트가 끝나자마자 2차 프로젝트에 돌입하였다. 그러다보니 아무래도 학습 기록 일지는 꾸준히 남기고 있지만, 학습한 내용에 대한 정리나 개념에 대한 포스팅을 하기가 쉽지가 않다.

 현재는 2차 프로젝트 팀에서 주제를 정한 상태에서 다함께 프로젝트 기획 단계에 돌입하였다.   그러다보니 ERD를 작성하게 되어 처음으로 ERD Cloud에서 직접 ERD 설계를 진행해보게 되었다.   그렇게 ERD를 그려나가던 중, 갑자기 생소한 문장이 내 숨을 턱 멎게 했다.

 "식별 관계로 하시겠습니까? 비식별 관계로 하시겠습니까?"

  이게 정확히 무엇을 의미하는 것일까. 언뜻 살펴보니, 외래키에 대한 내용이었다.   당연히 @OneToMany 나 @ManyToOne 등으로 외래키를 사용할 건데, 식별 단계 아닌가? 하고 ERD를 작성해나가던 도중, 머지않아 이상함을 눈치챘다.

  외래 키가 기본 키에 들어가 있던 것이다. 세상에 이게 무슨 일이람.

  도대체 왜 이런 일이 벌어진 걸까. ERD를 제대로 작성하기 위해서 해당 부분을 공부하기로 결정했다.   이번 포스팅 내용은 짧다. 하지만 스스로 학습한 내용들을 기반으로, 개인적으로 '이렇게하면 가장 쉽게 이해할 수 있겠구나' 싶은 방향으로 정리해보고자 한다.

📑 식별 관계와 비식별 관계

1️⃣ 식별 관계

• 자식 엔티티가 부모 엔티티의 기본 키의 일부를 사용하여 식별되는 관계
• 기본 키를 복합 키로 가짐
  • 자식 엔티티의 기본 키 + 부모 엔티티의 외래 키 = 기본 키
• 부모 엔티티 없이는 독립적으로 식별 불가

@Embeddable
@EqulasAndHashCode
@AllArgsConstructor
@NoArgsConstructor
public class EmplyeeId implements Serializable {
    private long deptId;

    private long empId;
}

@Entity
@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
public class Department {
    @Id
    @GeneratedValue(strategy = GenerationType.IDNETITY)
    private long id;
}

@Entity
@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
public class Employee {
    @EmbeddedId
    private EmployeeId employeeId;

    @ManyToOne
    @JoinColumn(insertable = false, updatable = false)
    private Department department;
}

• insertable = false : Employee 테이블에 저장할 때, deptId 값이 자동으로 추가되지 않음
• updatable = false : Employee 테이블을 업데이트할 때, deptId 값은 변경되지 않음
• deptId 값은 사실, 자동으로 삽입되거나 업데이트될 일이 없음
• 위와 같은 설정으로 더 명시적으로 JPA 에게 외래 키를 자동으로 관리하지 않고 수동으로 설정된 값만 사용하겠다는 의도를 전달하는 용도
  
  

✔️ 이런 방법도 있다고 한다.

@Entity
@IdClass(EmployeeId.class)
public class Employee {
    @Id
    private long deptId;

    @Id
    private long empId;
}

• @IdClass 를 따로 지정해주어, 만들어둔 복합키 클래스인 EmployeeId 클래스의 복합키를 지정해줄 수 있음

Q. 복합키 사용시, 객체(Entity)를 생성할 때 수동으로 데이터를 일일히 다 넣어줘야하는데, 좋은 방법이 있을까? A. @PrePersist 를 사용해 자동으로 empId 를 생성할 수 있다.

@Entity
@Setter
@Getter
@AllArgsConstructor
@NoArgsConstructor
public class Employee {
    @EmbeddedId
    private EmployeeId employeeId;

    private final EntityManager em;

    @ManyToOne
    @JoinColumn(insertable = false, updatable = false)
    private Department department;

    @PrePersist
    public void prePersist() {
        if (employee.getEmpId() == 0) {
        long nextEmpId = getNextEmpId(department.getId());
        employeeId.setEmpId(nextEmpId);
    }

    private long getNextEmpId(long deptId) {
        Query query = em.createQuery("SELECT MAX(e.employeeId.empId) FROM Employee e WHERE e.department.id = :deptId");
        query.setParameter("deptId", deptId);
        Long maxEmpId = (Long) query.getSingleResult();

        return (maxEmpId == null) ? 1L : maxEmpId + 1;
    }
}

• @PrePersist 는 Employee 엔티티가 DB에 저장되기 전에 실행되는 메서드
• empId 가 0일 때만 실행, 새로운 직원이 추가될 때 부서별 empId 를 자동으로 계산하여 설정
• getNextEmpId 메서드는 해당 부서에서 가장 큰 empId 값 + 1 만큼의 값을 새 empId 로 설정
  
  

2️⃣ 비식별 관계

• 자식 엔티티가 부모 엔티티의 기본 키 참조 (외래키 보유)
• 자식 엔티티의 기본 키에 부모 엔티티의 기본 키가 포함되지는 않음
• 자식 엔티티는 부모 엔티티와 독립적으로 식별 가능
• 부모 엔티티의 기본 키는 오직 자식 엔티티의 외래 키로만 사용
• 일반적으로 @OneToMany 와 @ManyToOne 을 사용할 때, 비식별 관계로 사용됨

@Entity
public class Employee {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private long id;

    @ManyToOne
    private Department department;
}

참고) OpenAI. (2024).ChatGPT(4o)[Large language model].https://chatgpt.com/

  매일 아침, 일어나서 컴퓨터에 앉자마자 반드시 진행 중인 루틴이 하나 있다. 코딩테스트를 적어도 한 문제 진행하는 것이다. 유명한 코딩테스트 사이트인 백준, 프로그래머스, 리트코드 중 프로그래머스에서 하루에 한 문제 이상씩 풀어보며 코딩테스트에 대한 감을 유지하는 중이다.

  아직 너무 어려운 코딩테스트 풀이까지는 진입하지 않았다. 전체 문제를 정답률 높은 문제 순으로 필터링하여 차근차근 풀고 있다.   그러다보니 어느덧, 그렇게 많은 숫자는 아닐지 몰라도 432 문제를 풀었다. 매일마다 늘어나는 순위와 해결한 문제를 보며, 작은 성취감과 자존감을 채워나가고 있다.

  코딩테스트를 진행하며, 시간 복잡도 문제로 골머리를 많이 앓고 있다. 내가 생각한 시간 복잡도와 내 풀이의 시간 복잡도가 다를 때도 가끔 있고, 시간 복잡도를 줄이지 못해 런타임 에러가 터지는 경우도 왕왕 있다.   이러한 문제들을 잘 해결하기 위해서는 당연히 시간 복잡도에 대해 잘 알고 있어야 한다. 그렇기에 시간 복잡도에 대해서 간략하게나마 정리해보았다.

📕 시간 복잡도

• 알고리즘이 수행되는 데 걸리는 시간을 데이터의 크기에 따라 분석하는 방법
• 실제 실행 시간 측정 대신, 입력 크기 n이 증가할 때 연산 횟수가 어떻게 변하는지에 따라 성능을 평가
• 일반적으로 Big-O 표기법으로 표현되며, 항상 최악의 경우의 알고리즘 성능을 나타냄
  
  

✒️ 코딩테스트에서의 시간 복잡도

• 코딩테스트에서는 이 시간 복잡도를 잘 처리하여, 주어진 시간 제한 내에 알고리즘이 동작하도록 해야 함
• 일반적으로 1초에 (10^8) , 즉 1억 번의 연산을 처리할 수 있다고 가정
  

1️⃣ O(1) - 상수 시간

• n 의 크기와 상관없이, 실행 시간은 항상 일정
• n - 제한 없음
• ex) 산술 연산, 조건문, 값 접근 ...

  public int sum(int x, int y) {
    return x + y;
  }

• x 와 y 의 값에 상관 없이 항상 한 번의 계산으로 실행이 종료됨
• 따라서 시간 복잡도는 O(1)

2️⃣ O(logn) - 로그 시간

• n 의 크기에 따라 실행 시간이 로그 증가

• n - 10^18 이상도 가능, 매우 넉넉한 조건

• ex) 이진 탐색, 균형 이진 트리 탐색 ...

  public int binarySearch(int[] arr, int key) {
    int left = 0, right = arr.length - 1;
  
    while (left <= right) {
        int mid = left + (right - left) / 2;
  
        if (arr[mid] == key) {
            return mid;
        } else if (arr[mid] <= key) {
            left = mid + 1;
        } else {
            right = mid - 1;
        }
    }
  
    return -1;
  }

• while (left <= right) 일 때, 배열을 반으로 나누는 작업 반복

• n 을 반으로 나누는 횟수는 logn 에 비례

• 따라서 시간 복잡도는 O(logn)

  
  

3️⃣ O(n) - 선형 시간

• n 의 값과 비례하여 실행 시간 증가
• n <= 100,000,000 ~ 1,000,000,000
• ex) 배열, 리스트 등 컬렉션 탐색, 반복문 ...

  public int sumArr(int[] arr) {
    return Arrays.stream(arr).sum();
  }

• arr 의 크기 n 을 모두 한 번씩 순회하며 값을 더함
• 따라서 시간 복잡도는 O(n)
  

4️⃣ O(nlogn) - 선형 로그 시간

• ( n 값 * 로그 증가) 만큼의 실행 시간

• n <= 1,000,000 ~ 10,000,000

• ex) 합병 정렬, 힙 정렬 ...

  public void mergeSort(int[] arr) {
    if (arr.length < 2) {
        return;
    }
  
    int mid = arr.length / 2;
    int[] left = Arrays.copyOfRange(arr, 0, mid);
    int[] right = Arrays.copyOfRange(arr, mid, arr.length);
  
    mergeSort(left);
    mergeSort(right);
  
    merge(arr, left, right);
  }
  

public void merge(int[] arr, int left, int right) { // 두 배열을 합치는 알고리즘 // 생략 }

- `mergeSort(left)` 와 `mergeSort(right)` 에서 배열을 반으로 나누므로, `logn` 번 반복
- 나눠진 배열을 __병합__하며 올라오므로 `O(n)`
- 따라서 시간 복잡도는 둘을 곱한 `O(nlogn)`
<br>

### 5️⃣ O(n^2) - 이차 시간
- 값이 `n` 일 때, `n` * `n` 만큼 실행
- `n` <= `1,000` ~ `10,000`
- ex) __이중 반복문, 버블 정렬__ ...
```java
public void bubbleSort(int[] arr) {
    for (int i = 0; i < arr.length; i++) {
        for (int j = 0; j < arr.length - 1; j++) {
            if (arr[j] > arr[j + 1]) {
                int temp = arr[j];
                arr[j] = arr[j + 1];
                arr[j + 1] = temp;
            }
        }
    }
}

• 이중 for 루프로 인해 n * n 번 실행
• 따라서 시간 복잡도는 O(n^2)
  

6️⃣ O(n^3) - 삼차 시간

• 값이 n 일 때, n * n * n 만큼 실행

• n <= 100 ~ 300

• ex) 플로이드-워셜, 삼중 반복문 ...

  public void flodWarshall(int[][] graph) {
    int n = graph.length;
  
    for (int k = 0; k < n; k++) {
        for (int i = 0; i < n; i++) {
            for (int j = 0; j < n; j++) {
                graph[i][j] = Math.min(graph[i][j], graph[i][k] + graph[k][j]);
            }
        }
    }
  }

• 삼중 for 루프로 인해 n * n * n 번 실행

• 따라서 시간 복잡도는 O(n^3)

7️⃣ O(2^n) - 지수 시간

• 값이 n 일 때, 2 의 n 제곱 만큼 실행

• n <= 약 20

• ex) 완전 탐색 DFS, 모든 부분집합 탐색 ...

  public class Solution {
    List<Integer> list;
  
    public static void main(String[] args) {
        list = new ArrayList();
        subsetSum(new int[]{1, 2, 3, 4, 5}, 0, 0);
    }
  
    public void subsetSum(int[] arr, int sum, int idx) {
      if (idx == arr.length) {
        list.add(sum);
        return;
      }
  
      subsetSum(arr, sum + arr[idx], idx + 1);
      subsetSum(arr, sum, idx + 1);
    }
  }

• arr 의 요소를 더할 경우와 더하지 않을 경우 총 2가지 실행

• 각 subsetSum 호출시마다 2가지 경우의 수가 존재함

• 따라서 시간 복잡도는 O(2^n)

8️⃣ O(n!) - 팩토리얼 시간

• n! 만큼 실행
• n <= 약 10
• ex) 순열, Brute Force(완전 탐색) ...

public class Solution { int result; boolean[] visited;

public int solution(int k, int[][] dungeons) {
    result = Integer.MIN_VALUE;
    visited = new boolean[dungeons.length];
    dfs(k, dungeons, 0, 0);

    return result;
}

public void dfs(int k, int[][] dungeons, int depth, int count) {
    if (depth == dungeons.length) {
        result = Math.max(result, count);
        return;
    }

    for (int i = 0; i < dungeons.length; i++) {
        if (!visited[i]) {
            if (k >= dungeons[i][0]) {
                k -= dungeons[i][1];
                visited[i] = true;
                dfs(k, dungeons, depth + 1, count + 1);
                visited[i] = false;
                k += dungeons[i][1];
            }
        }
    }

    result = Math.max(result, count);
}

}

```

• 값이 n 일 경우, 재귀 호출 시마다 n - 1 개의 경우의 수 고려
• 즉, n - 1 씩 줄여가며 반복
• 따라서 시간 복잡도는 O(n!)
  
  

📚 시간 복잡도 정리

참고) OpenAI. (2024).ChatGPT(4o)[Large language model].https://chatgpt.com/

  최근, 테스트의 중요성을 여실히 느끼고 있다.   원래 처음에는 테스트 파일을 따로 생성하여 테스트를 진행하지 않았다. 이유는 간단했다. 잘 사용할 줄 몰랐기 때문에.

  최근 학습을 진행하면서 테스트 파일을 작성하는 법을 체득하고 있다. 처음에는 간단하게 @Autowired로 실제 서비스나 레포지터리를 불러오고 기능이 잘 작동하는지를 테스트하였고, 이후에는 MockMvc를 통한 컨트롤러 테스트 또한 진행하였다.

  테스트 사용법이 조금씩 익숙해지면서, TDD로 기존의 프로젝트를 재구현하는 실습을 진행하며 테스트와 좀 더 친숙해지고 있는 요즘이다.

  개인적으로 처음에 되게 생소하게 느꼈던 것이 바로 컨트롤러 테스트이며, 이를 MockMvc를 이용하여 진행하고 있다. &nbsp 이 MockMvc가 무엇이며 어떻게 작동하고, 어떻게 응답하는지 정리해보는 시간을 가져보았다.

📕 MockMvc

• 컨트롤러를 테스트할 때, Servlet Container , 즉 실제 서버를 띄우지 않고도 컨트롤러 레이어를 테스트할 수 있도록 도와주는 도구
• Spring MVC 의 요청-응답 흐름을 시뮬레이션하며, 컨트롤러가 예상대로 동작하는지 확인하는 과정
• HTTP 요청 및 응답을 Mocking해서 테스트 환경을 단순화
  
  

🔎 MockMvc를 사용한 컨트롤러 테스트의 목적

1. 요청-매핑 검증

• 클라이언트로부터 URI 요청이 올 때, 이것이 올바른 Handler Method 로 매핑되는지 확인
• ex) /api/v1/member/login URI 를 요청받았을 때, 이를 처리하는 메서드로 잘 연결되는가
  

2. 핸들러 메서드 로직 테스트

• 매핑된 컨트롤러 메서드가 올바른 결과를 반환하는지 확인하기 위함
  

3. 예외 처리 검증

• 잘못된 요청 및 비정상적 입력에 대한 예외 처리
• 정의된 에러 응답을 반환하는지 확인
  
  

🔗 Mock과 DispatcherServlet

• MockMvc 는 실제 서블릿 컨테이너는 구동하지 않지만, DispatcherServlet 의 핵심 로직을 Mock 환경에서 동작시킴
  • ServletContainer : Tomcat, Jetty 등, 실제 HTTP 요청을 처리하고 서블릿을 실행하는 환경
  • MockMvc 는 이러한 실제 HTTP 요청 대신, MockHttpServletRequest 와 MockHttpServletResponse 를 사용하여 DispatcherServlet 내부 로직 호출
• DispatcherServlet 은 서블릿 컨테이너 없이도 Spring MVC 의 요청-응답 처리 과정을 시뮬레이션 가능
  
  

➡️ 동작 방식

1. Mock 요청 생성

• MockMvc 는 실제 HTTP 요청이 아닌, MockHttpServletRequest 를 생성
  

2. DispatcherServlet 호출

• DispatcherServlet 인스턴스를 Mock 환경에서 초기화
• service() 메서드 호출
  • 서블릿 컨테이너 없이 DispatcherServlet 내부 로직 실행
    

3. 핸들러 매핑 및 실행

• DispatcherServlet 은 핸들러 매핑을 통해 요청 URL에 맞는 컨트롤러를 찾고, 해당 컨트롤러 메서드(핸들러 메서드, 액션 메서드)를 실행
  

4. Mock 응답 반환

• 컨트롤러 메서드의 반환값은 MockHttpServletResponse 에 담겨 응답 객체로 사용

✒️ MockMvc 사용

1. MockMvc 생성

@SpringBootTest
@AutoConfigureMockMvc
public class MockControllerTest() {
    @Autowired
    private MockMvc mvc;

    @Test
    void t1() {
        ResultActions resultActions = mvc.perform(...);
    }
}

• AutoConfigureMockMvc 를 통해 MockMvc 를 사용할 수 있도록 설정
• 테스트 환경에서는 AllArgsConstructor , RequiredArgsConstructor 등을 사용할 수 없으므로, @Autowired 를 통해 DI 로 MockMvc 주입
• perform() 메서드를 통해 URL 요청, 결과를 ResultActions 객체로 받아옴
  

2. HTTP 요청 메서드

resultActions = mvc.perform(
    get("/api/v1/posts")
);

resultActions = mvc.perform(
    delete("/api/v1/posts/1")
);

• HTTP 요청 메서드를 선택
• get(String url) : Get 요청
• post(String url) : Post 요청
• put(String url) : Put 요청
• delete(String url) : Delete 요청
• patch(String url) : Patch 요청
  

3. andExpect()

mvc.perform(
    delete("/api/v1/posts/1")
)
.andExpect(status().isOk());

• 요청 결과를 검증하기 위해 사용
• status() : 응답 상태 코드 검증
• header() : 응답 헤더 검증
• handler() : 응답 핸들러 검증
• jsonPath() : JSON 응답의 특정 필드 검증
  

4. andDo()

mvc.perform(
    get("/api/v1/posts")
)
.andDo(print());

• 요청 및 응답 결과를 출력하거나 추가 작업 진행
• 디버깅 용도로 주로 사용
  

5. header()

String apiKey = UUID.randomUUID().toString();

mvc.perform(
    post("/api/v1/posts")
        .header("Authorization", "Bearer " + apiKey)
);

• HTTP 헤더 추가
• 쿠키 확인 및 검증 등에 주로 사용
  

6. content(), contentType()

mvc.perform(
    post("/api/v1/posts")
        .content("""
                {
                    "title": "제목",
                    "content": "내용"
                }
                """)
        .contentType(new MediaType(MediaType.APPLICATION_JSON, StandardCharsets.UTF_8))
);

• content() : 요청에 본문 추가
• contentType() : 본문 파일 형식 및 인코딩 방식 지정

참고) OpenAI. (2024).ChatGPT(4o)[Large language model].https://chatgpt.com/