목표 단순 기능 구현을 넘어서, 왜 이런 구조를 선택했는지, 어떤 문제를 겪었고 어떻게 해결했는지를 기록하기 위한 글이다.

1. 프로젝트 배경

이 프로젝트는 공연 예매 서비스로,

• 동시성 이슈가 명확한 좌석 선택 도메인
• JWT 기반 인증/인가
• Redis를 활용한 캐싱과 분산 락 을 핵심 기술 포인트로 삼았다.

특히 튜터님·코드리뷰 상황에서

“왜 이렇게 설계했나요?” 라는 질문에 답할 수 있는 구조를 만드는 것을 목표로 했다.

2. 인증 / 인가 설계 (JWT)

2-1. 왜 세션이 아닌 JWT인가?

• 서버 확장에 유리한 Stateless 구조
• 모바일/프론트엔드와의 연동 용이
• 인증 정보를 토큰 자체에 포함 가능

단점으로는 앞으로 구현할 로그아웃과 토큰 무효화가 어렵다는 점이었다.

2-2. AuthenticationManager를 사용한 이유

AuthenticationManager는 인증의 진입점 역할을 한다.

• Controller → Service가 인증을 직접 처리하지 않게 함
• 인증 로직을 Spring Security에게 위임

인증 책임을 프레임워크에 맡기고, 비즈니스 로직과 분리

2-3. JWT 인증 필터를 UsernamePasswordAuthenticationFilter 앞에 둔 이유

• JWT는 로그인 이후 요청을 검증
• UsernamePasswordAuthenticationFilter는 로그인 요청 전용

[JWT 인증 필터] → [UsernamePasswordAuthenticationFilter]

이미 토큰이 있는 요청은 굳이 로그인 필터를 탈 필요가 없다..!

2-4. UserDetails / UserDetailsService를 분리한 이유

도메인 User와 보안 User를 분리해 결합도 감소

3. 로그아웃과 Blacklist 설계

3-1. JWT 로그아웃의 근본적인 문제

• JWT는 서버에 저장되지 않음(Stateless 특성)
• 한 번 발급되면 만료 전까지 유효

단순히 "로그아웃" API 호출로는 토큰을 무효화할 수 없음

3-2. Blacklist를 도입한 이유

이미 발급된 토큰을 서버 기준으로 차단하기 위함

• 로그아웃 시 토큰을 Blacklist에 저장
• 이후 요청마다 Blacklist 확인
• 존재하면 인증 실패

Stateless 구조를 유지하면서도 즉시 무효화 보장

3-3. User 테이블과 분리한 이유

• 인증 상태 ≠ 사용자 정보
• 인증 관련 데이터는 조회 빈도가 높음
• Redis 전환을 고려한 구조

책임 분리 + 확장성 확보

3-4 위 설계로 인한 차후 생각해야될 모델

수많은 유저가 로그아웃을 거치기 때문에 이에따른 병목 현상에 대해 고려

• 일정 데이터가 쌓이면 삭제하도록 설계
• 다른 방도가 별도로 필요할 것으로 보임..（；´д｀）ゞ

4. 동시성 문제와 Redis 분산 락

4-1. 좌석 선택에서 발생하는 문제

• 동시에 같은 좌석을 선택하는 요청
• DB 트랜잭션만으로는 한계

4-2. Redis 분산 락을 선택한 이유

• 멀티 인스턴스 환경 대응
• DB 락보다 빠른 처리
• TTL로 데드락 방지 가능

4-3. 락 구현 방식

SETNX + TTL
Lua Script로 안전한 해제

• 락 획득 실패 시 즉시 예외
• 락은 반드시 finally에서 해제

5. AOP로 락 로직 분리

5-1. 왜 AOP인가?

• 락 로직은 횡단 관심사
• 서비스 코드가 지저분해지는 문제

비즈니스 로직에서 락 코드 제거

5-2. @RedisLock 어노테이션 설계

• SpEL을 활용한 동적 key 생성 (SpEL에 대해서는 차후 따로 다뤄볼 계획이다!!(⌐■_■))
• TTL 정책을 어노테이션으로 명시

@RedisLock(key = "'seat:' + #seatId", ttl = 3000)

5-3. RuntimeException 문제와 개선 포인트

초기에는 AOP 내부에서 RuntimeException으로 감싸며 예외를 던졌다.

문제점:

• 서비스 레벨의 CustomException이 그대로 전달되지 않음

개선 방향:

• AOP에서는 예외를 감싸지 않고 그대로 throw
• 또는 공통 인터페이스 기반 예외 처리

6. Scheduler + 분산 락

6-1. 왜 스케줄러에도 락이 필요한가?

• 서버가 여러 대일 경우
• 동일 스케줄이 중복 실행 가능

6-2. RedisSchedulerLockAspect 도입

• @Scheduled 메서드에 어노테이션 적용

• 이미 실행 중이면 그냥 종료

  중복 실행 방지 + 안정성 확보

7. 트러블슈팅 요약

8. 마무리

이번 프로젝트를 통해 느낀 점은

기술 선택의 이유를 설명할 수 있어야 진짜 내 코드가 된다

라는 것이었다.

단순 구현이 아니라,

• 왜 이 구조인지
• 어떤 대안이 있었는지
• 왜 이걸 선택했는지

를 계속 고민한 경험이 큰 자산이 되었다.

다음으로 정리하고 싶은 주제

• Redis vs DB Lock 비교 실험
• JWT + Refresh Token 고도화
• 트래픽 테스트와 병목 분석

꼭 해보고 싶다!!!!!!!(≧▽≦)/ 프로젝트 마무리한 모두 고생했고 좋은 결과만 있기를 (❁´◡`❁)

왜 Redis Lock이 필요한가?

• 문제 상황

  • 좌석 예매, 쿠폰 발급, 포인트 차감처럼
  • 여러 요청이 동시에 같은 자원을 수정하는 상황 발생

• 단순 조회 후 수정 방식에서는 두 요청이 동시에 isSelected == false 확인

• 동시에 true로 변경 → 중복 선택 발생

요구사항

• 단 하나의 요청만 자원을 수정

• 나머지는 즉시 실패 또는 대기

Redis Lock을 선택한 이유

• Redis Lock 특징

  • 분산 환경에서도 동시성 제어 가능

  • DB Lock보다 빠르고 부담이 적음

  • 서버가 여러 대여도 하나의 Redis를 통해 락 공유

DB Lock만으로 부족한 이유

• 트랜잭션 범위가 길어질수록 DB 부하 증가

• API 서버 확장 시 제어 어려움

“분산 락”이 필요했기 때문에 Redis 선택

AOP로 Lock을 분리한 이유

• 서비스 코드에 락을 직접 쓰면?

  lock();
  try {
    비즈니스 로직
  } finally {
    unlock();
  }

모든 메서드에 반복됨

• 가독성 ↓

• 실수로 unlock 누락 위험

• AOP 적용 후

  @RedisLock(key = ...)
  public void businessLogic() { ... }

• 락 로직 완전 분리

• 비즈니스 로직에 동시성 코드 없음

• 선언적으로 락 적용 가능

락은 횡단 관심사(Cross-cutting concern)

AOP로 분리하는 게 가장 적합

핵심 키워드 정리

• AOP 관련

  • @Aspect

  • @Around

  • ProceedingJoinPoint

  • 횡단 관심사 (Cross-cutting Concern)

• Redis Lock 관련

  • SETNX (setIfAbsent)

  • TTL (Time To Live)

  • 분산 락 (Distributed Lock)

  • Lua Script (원자적 해제)

• 설계 관련

  • SRP (단일 책임 원칙)

  • DIP (의존성 역전 원칙)

  • 선언적 프로그래밍

  • 관심사 분리 (Separation of Concerns)

RedisLock 어노테이션 설계

@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface RedisLock {
    String key();
}

왜 이렇게 설계했는가?

• METHOD 단위 → 락은 로직 실행 범위에 적용

• RUNTIME 유지 → AOP 실행 시 접근 필요

• key를 SpEL로 받음 → 동적 락 키 생성

SpEL을 이용한 Lock Key 생성

@RedisLock(key = "'seat:' + #request.scheduleId + ':' + #request.seatNo")

SpEL을 쓴 이유

• 메서드 파라미터 기반으로 자원 단위 락 구현 가능

• 예시 결과

  lock:seat:3:15

전체 좌석이 아닌 특정 좌석만 잠그는 최소 범위 락

RedisLockAspect의 역할

• 역할 요약

  • 어노테이션 감지

  • SpEL 파싱

  • LockService 호출

  • 비즈니스 메서드 실행 제어

• 핵심 흐름

  • @RedisLock 감지

  • Lock Key 생성

  • Redis Lock 획득

  • joinPoint.proceed() 실행

  • finally에서 락 해제

LockService의 책임 분리

public <T> T executeWithLock(String key, Supplier<T> action)

• 책임

  • 락 획득 / 해제

  • TTL 설정

  • 락 실패 시 즉시 예외 처리

• 왜 Supplier?

  • 비즈니스 로직을 함수로 전달

  • 락 범위를 명확히 제어

RedisLockRepository 구현 포인트

• 락 획득

  SET key value NX PX ttl

• 한 요청만 성공

• TTL로 데드락 방지

• 락 해제 (Lua Script)

  if redis.call('get', key) == value then
    del key
  end

락을 건 주체만 해제 가능

안전한 분산 락 구현

왜 @Around를 사용했는가?

• 락은 메서드 실행 전 필요

• 메서드 실행 후 반드시 해제

• try-finally 구조 필요

@Around만 가능

이 구조의 장점 정리

• 비즈니스 코드가 깔끔
• 락 적용 여부를 어노테이션으로 제어
• 재사용 가능
• 테스트/확장 용이

요약

Redis 기반 분산 락을 AOP로 분리하여

비즈니스 로직과 동시성 제어를 분리했고,

SpEL을 활용해 자원 단위의 최소 범위 락을 구현했다!!

공부할게 산더미!!!!!!!!!!!!!!!（；´д｀）ゞ

• JDBC를 이용해 유저 데이터 500만 건 Bulk Insert

• 닉네임으로 유저를 검색하는 API 구현

• 검색 성능 병목을 분석하고 인덱스를 통해 개선

• 성능 개선을 정량적 근거(EXPLAIN) 로 비교

대용량 데이터 생성 (JDBC Bulk Insert)

• 구현 방식

• JPA가 아닌 순수 JDBC + Batch Insert

• PreparedStatement + executeBatch()

• rewriteBatchedStatements=true 옵션 사용

• 10,000건 단위 commit

  String sql = "INSERT INTO users (nick_name) VALUES (?)";
  PreparedStatement ps = con.prepareStatement(sql);
  

for (int i = 1; i <= 5_000_000; i++) { ps.setString(1, "nick_" + UUID.randomUUID()); ps.addBatch();

if (i % 10_000 == 0) {
    ps.executeBatch();
    con.commit();
    ps.clearBatch();
}

}

>### 깨달은 점
#### JPA로 500만 건 insert는 사실상 불가능
#### JDBC Batch + 옵션이 없으면 속도 & 메모리 문제 발생
#### 테스트 코드로 데이터 생성하는 것은 “한 번 실행용”

---

>## 테스트 환경 트러블 슈팅

- ❌ OutOfMemoryError 발생

java.lang.OutOfMemoryError: Java heap space

- 원인

   - batch size 과도

   - MySQL batch rewrite 미적용

   - Test JVM Heap 부족

- 해결

  - batchSize 조절

  - rewriteBatchedStatements=true

  - 테스트는 한 번만 실행

  - ❌ 테스트 데이터가 사라지는 문제

- 현상

  - 테스트에서 500만 건 생성

  - 애플리케이션 실행 시 데이터 사라짐

- 원인

spring.jpa.hibernate.ddl-auto: create-drop

#### 애플리케이션 실행 시 테이블 DROP

---

>###정리
#### 테스트 = 데이터 생성
#### 애플리케이션 실행은 불필요
#### DB 확인은 SQL로 직접

---

>## 닉네임 검색 API 구현

```java
@GetMapping("/users")
public ResponseEntity<List<UserResponse>> search(@RequestParam String nickName) {
    return ResponseEntity.ok(userService.findByNickName(nickName));
}

List<User> findByNickName(String nickName);

• 정확히 일치 검색 (=)

• 랜덤 닉네임 → 실제 존재하는 값으로 테스트 필요

성능 병목 분석 (인덱스 적용 전)

EXPLAIN SELECT * FROM users WHERE nick_name = 'nick_xxxxx';

• 결과

• 의미

  • Full Table Scan

  • 모든 행을 순차 비교

  • 데이터 증가 시 성능 선형 악화

인덱스 적용

CREATE INDEX idx_users_nick_name ON users (nick_name);

• 서비스 코드 변경 없이 SQL 인덱스만 추가

성능 개선 결과 (EXPLAIN 기준)

• 핵심 변화

  • ALL → ref

  • Full Scan 제거

  • B-Tree 인덱스 기반 탐색

ms보다 EXPLAIN이 중요한 이유

• ms는 캐시·환경 영향 큼

• 로컬 환경에서는 체감 어려움

• EXPLAIN은 DB의 실행 전략 자체

• 성능 개선의 증거는 “몇 ms 줄었다” 가 아닌 “접근 방식이 ALL → ref로 바뀌었다”

핵심 정리

500만 건 데이터 환경에서 닉네임 검색 시

인덱스 미적용 시 Full Table Scan이 발생했으며,

단일 컬럼 인덱스 적용만으로 조회 범위를 500만 → 1건으로 줄일 수 있었다.

느낀 점

대용량 데이터에서는 “동작함”보다 “어떻게 접근하는지”가 중요

성능 개선은 코드보다 DB 구조 설계가 핵심

인덱스는 단순하지만 가장 강력한 최적화 수단이다!!

빠이팅w(ﾟДﾟ)w

트러블 슈팅(1)

날짜 검색에서 LocalDate vs LocalDateTime

왜 LocalDate로 입력을 받았을까?

• 사용자는 날짜만 신경 쓰지, 시:분:초까지 직접 입력할 필요가 없음

• UI/UX 관점에서 날짜 입력이 훨씬 직관적임

그런데 응답은 왜 LocalDateTime일까?

• DB에는 생성 시점이 LocalDateTime으로 저장됨

• 응답 DTO는 정확한 생성 시각을 보여주는 게 맞음

입력은 단순하게(LocalDate), 출력은 정확하게(LocalDateTime)

역할에 맞게 타입을 분리하는 것이 설계적으로 더 좋다.

@DateTimeFormat + atStartOfDay / LocalTime.MAX를 쓰는 이유

• @DateTimeFormat(iso = DateTimeFormat.ISO.DATE)
• LocalDate startDate;

왜 이런 변환 로직이 필요한가?

• LocalDate는 시간 정보가 없음

• DB 컬럼은 LocalDateTime

  • 그래서:

  • 시작일 → 00:00:00

  • 종료일 → 23:59:59.999999999

코드가 지저분한데 다른 방법은?

• 이 방식이 의도가 가장 명확하다고 함.

• QueryDSL/JPA에서 시간 경계 버그를 가장 확실히 방지

“지저분해 보여도, 명시적인 코드가 가장 안전하다”

QueryDSL에서 BooleanExpression이 null인데도 동작하는 이유

private BooleanExpression titleContains(String keyword) {
    return keyword == null ? null : todo.title.contains(keyword);
}

null 반환인데 왜 검색 조건이 적용될까?

• QueryDSL의 where()는 null 조건을 자동으로 무시한다.

• 조건이 있으면 AND로 결합하고, 없으면 제외한다고 한다.

  query.where(
    titleContains(keyword),
    createdAtBetween(start, end)
  );

null-safe 동적 쿼리를 위한 의도된 설계

• 장점

  • if-else 지옥 방지

  • 조건 조합 폭발 방지

  • 가독성, 유지보수성 ↑

fetchOne() vs fetch() 차이 (강의내용 중복)

왜 fetchOne을 함부로 쓰면 안 될까?

fetchOne()

• 결과가 1개일 거라 확신할 때만

• 2개 이상이면 예외 발생

  fetch()

• 리스트 조회

• 결과 개수와 무관

“단건 조회가 보장될 때만 fetchOne”

Optional을 쓰는 이유 & orElseThrow 자동완성

Optional을 왜 쓰는가?

• null 반환 → 실수로 NPE 발생

• Optional → “없을 수도 있음”을 타입으로 강제

  userRepository.findById(id)
    .orElseThrow(...)

  Optional 안 쓰면 orElseThrow 자동완성이 안 뜬 이유?

• orElseThrow()는 Optional 전용 메서드

• 엔티티 자체에는 존재하지 않음

Optional은 단순 편의가 아니라

null 가능성을 코드 레벨에서 드러내는 장치

N+1 문제가 발생한 이유와 해결 방식

왜 N+1이 발생했을까?

• 연관 엔티티가 LAZY 로딩

• 반복 접근 시 쿼리가 추가로 실행됨

해결 방법은?

fetch join

• QueryDSL에서 join + fetch

• 필요한 필드만 Projections로 조회

“조회용 쿼리는 엔티티 조회가 아니라 DTO 조회가 더 적합한 경우가 많다”

SecurityConfig에 permitAll이 있는데 JWT 필터에서 또 체크하는 이유

SecurityConfig면 끝 아닌가?

.anyRequest().authenticated()

• 이건 인가(Authorization) 단계

• JwtFilter는 그보다 앞단의 인증(Authentication) 필터

그래서 필터에서도 분기 처리가 필요한 이유

• 필터는 무조건 실행됨

• /auth/** 요청에서도 JWT 검사하면 오류 발생

  @Override
  protected boolean shouldNotFilter(HttpServletRequest request) {
    return request.getRequestURI().startsWith("/auth");
  }

필터 책임: 인증 정보 생성

SecurityConfig 책임: 접근 허용/차단

UsernamePasswordAuthenticationFilter 앞에 JWT 필터를 두는 이유

이 필터는 뭐 하는 놈인가?

• 폼 로그인 기반

• ID/PW 인증 처리

왜 JWT 필터가 앞에 있어야 할까?

• JWT는 이미 인증된 사용자

• UsernamePasswordAuthenticationFilter까지 갈 필요 없음

JWT 인증이 먼저 끝나야

SecurityContext가 채워지고

이후 인가 로직이 정상 동작

정리

“Spring / JPA / Security에서의 설정과 패턴은

‘될 때까지 맞추는 코드’가 아니라

왜 이 레이어에서 이 책임을 가지는지를 이해하는 게 중요하다!!!”

트러블 슈팅(2)

궁금궁금(feat.QueryDsl)

Long total = queryFactory
    .select(todo.id.count())
    .from(todo)
    .where(
        todo.title.contains(keyword),
        todo.createdAt.between(start, end)
    )
    .fetchOne();

페이징 응답을 만들기 위해 “전체 데이터 개수”를 구하는 쿼리이다.

왜 이 코드가 추가로 필요할까?

• 페이징 응답에는 보통 이 정보들이 필요합니다

• 현재 페이지의 데이터 목록 (content)

• 전체 데이터 개수 (totalElements)

• 전체 페이지 수 (totalPages)

• 현재 페이지 번호

그런데 !!!

• limit, offset이 들어간 조회 쿼리로는 전체 개수를 알 수 없다.

• 목록 조회 쿼리만 있으면 생기는 문제

  List<TodoSearchResponse> content = queryFactory
    .select(...)
    .from(todo)
    .where(...)
    .orderBy(todo.createdAt.desc())
    .offset(pageable.getOffset())
    .limit(pageable.getPageSize())
    .fetch();

• “현재 페이지 데이터”만 조회

• DB에는 총 몇 건이 있는지 모름!!

• 프론트 입장에서는

  “다음 페이지가 있는지?”,

  “총 몇 페이지인지?”를 알 수 없음

그래서 count 쿼리가 필요함

select count(todo.id) from todo ...

• 페이징 조건 ❌ (limit/offset 없음)

• 검색 조건만 동일하게 적용

• 전체 검색 결과 개수만 조회

  • 이 값으로:

    PageImpl<>(content, pageable, total)

• 프론트에서 정확한 페이지 계산 가능

왜 목록 조회랑 쿼리를 분리했을까?

성능 이유

• count는 필요한 컬럼이 id 하나뿐

• projection / join / orderBy 필요 없음

책임 분리

• 조회 쿼리 → 데이터 가져오기

• count 쿼리 → 개수 계산

  • JPA & QueryDSL에서 권장되는 패턴

왜 fetchOne()을 쓰는가?

.select(todo.id.count())

• count()는 결과가 항상 1행

• 리스트가 아니라 단일 값

  • 그래서:

    fetch() ❌ (List<Long>)
    

fetchOne() ✅ (Long)

---

>### 왜 keyword, start, end 조건을 똑같이 넣어야 할까?

#### “검색 조건이 다르면 total이 의미 없어짐”

- 목록 조회 결과: 5개

- total: 전체 100개 (이러면 안됨)

#### 목록 쿼리와 count 쿼리는 조건이 반드시 동일해야 함!!

---

>### 요약
#### 페이징 처리에서는 현재 페이지의 데이터 조회와
#### 전체 데이터 개수 조회를 분리해야 하며,
#### 이를 위해 QueryDSL에서 count 전용 쿼리를 추가로 작성한다.


---

### 실전 코드 적용

```java
// 실제 목록 조회 쿼리 (페이징 대상)
List<TodoSearchResponse> content = queryFactory
        // TodoSearchResponse DTO로 바로 매핑하기 위해 Projections.constructor 사용
        // 엔티티 전체가 아니라 "필요한 필드만" 조회해서 성능 최적화
        .select(Projections.constructor(
                TodoSearchResponse.class,

                // 일정 제목
                todo.title,

                // 해당 일정의 담당자 수
                // JOIN으로 인해 중복 row가 생길 수 있으므로 countDistinct 사용
                manager.id.countDistinct(),

                // 해당 일정의 댓글 수
                // 댓글도 JOIN으로 중복될 수 있으므로 countDistinct 사용
                comment.id.countDistinct()
        ))
        // 기준 테이블은 todo
        .from(todo)

        // 일정과 담당자 관계 LEFT JOIN
        // 담당자가 없는 일정도 검색 결과에 포함시키기 위해 LEFT JOIN
        .leftJoin(todo.managers, manager)

        // 담당자와 유저 JOIN (닉네임 검색을 위함)
        .leftJoin(manager.user, user)

        // 일정과 댓글 LEFT JOIN
        // 댓글이 없는 일정도 검색 결과에 포함
        .leftJoin(todo.comments, comment)

        // 검색 조건
        .where(
                // 제목 키워드 부분 일치 검색
                todo.title.contains(keyword),

                // 담당자 닉네임 부분 일치 검색
                manager.user.nickName.contains(managerNickname),

                // 일정 생성일 범위 검색
                todo.createdAt.between(start, end)
        )

        // todo 기준으로 집계해야 하므로 groupBy 필수
        // count(), countDistinct()를 사용했기 때문
        .groupBy(todo.id)

        // 최신 일정이 먼저 나오도록 정렬
        .orderBy(todo.createdAt.desc())

        // 한 페이지에 가져올 데이터 개수 제한
        .limit(pageable.getPageSize())

        // 실제 데이터 조회
        .fetch();

// 전체 데이터 개수 조회 쿼리 (count 쿼리)
Long count = queryFactory
        // 전체 검색 결과 개수를 구하기 위한 count 쿼리
        .select(todo.id.count())

        // 기준 테이블은 동일하게 todo
        .from(todo)

        // 목록 조회와 "동일한 검색 조건"을 사용해야 함
        // 그래야 페이지 수(totalPages)가 정확해짐
        .where(
                todo.title.contains(keyword),
                todo.createdAt.between(start, end)
        )

        // count는 항상 단일 결과이므로 fetchOne 사용
        .fetchOne();

이 코드에서 꼭 이해해야 할 핵심 포인트

• 목록 조회 쿼리와 count 쿼리를 분리한 이유

  • 목록 조회: limit, groupBy, join → 데이터 표현용

  • count 쿼리: 단순한 구조 → 전체 개수 계산용

페이징에서 정확한 total 값을 얻기 위한 필수 구조

왜 countDistinct를 쓰는가?

manager.id.countDistinct()
comment.id.countDistinct()
JOIN이 들어가면 하나의 todo가 여러 row로 늘어남

• 그냥 count() 쓰면 중복 카운트 발생

• countDistinct()로 실제 개수만 집계

왜 groupBy(todo.id)가 필요한가?

• count / countDistinct는 집계 함수

• 집계 대상이 todo 기준이므로 groupBy(todo.id) 필수

• 없으면 SQL 에러 발생

왜 count 쿼리에는 JOIN이 없는가?

• 전체 개수만 알면 됨

• JOIN은 성능 저하만 유발

의도적으로 단순한 count 쿼리 작성 = 성능 최적화

요약

QueryDSL 페이징에서는

목록 조회 쿼리와 전체 개수(count) 쿼리를 분리하고,

목록 조회는 Projection + groupBy로 최적화하며

count 쿼리는 조건만 동일하게 유지한 채 최대한 단순하게 작성한다.

전체 코드

package org.example.expert.domain.todo.searchRepository;

import com.querydsl.core.types.Projections;
import com.querydsl.core.types.dsl.BooleanExpression;
import com.querydsl.jpa.impl.JPAQueryFactory;
import lombok.RequiredArgsConstructor;
import org.example.expert.domain.todo.dto.response.TodoSearchResponse;
import org.springframework.data.domain.Page;
import org.springframework.data.domain.PageImpl;
import org.springframework.data.domain.Pageable;

import java.time.LocalDateTime;
import java.util.List;

import static org.example.expert.domain.comment.entity.QComment.comment;
import static org.example.expert.domain.manager.entity.QManager.manager;
import static org.example.expert.domain.todo.entity.QTodo.todo;
import static org.example.expert.domain.user.entity.QUser.user;

@RequiredArgsConstructor
public class SearchRepositoryImpl implements SearchRepository {

    private final JPAQueryFactory queryFactory;


    @Override
    public Page<TodoSearchResponse> search(
            String keyword,
            String managerNickname,
            LocalDateTime start,
            LocalDateTime end,
            Pageable pageable
    ) {
        List<TodoSearchResponse> content = queryFactory
                .select(Projections.constructor(
                        TodoSearchResponse.class,
                        todo.title,
                        manager.id.countDistinct(),
                        comment.id.countDistinct()
                ))
                .from(todo)
                .leftJoin(todo.managers, manager)
                .leftJoin(manager.user, user)
                .leftJoin(todo.comments, comment)
                .where(
                        todo.title.contains(keyword),
                        manager.user.nickName.contains(managerNickname),
                        todo.createdAt.between(start, end)
                )
                .groupBy(todo.id)
                .orderBy(todo.createdAt.desc())
                .limit(pageable.getPageSize())
                .fetch();

        Long total = queryFactory
                .select(todo.id.count())
                .from(todo)
                .where(
                        todo.title.contains(keyword),
                        todo.createdAt.between(start, end)
                )
                .fetchOne();

        return new PageImpl<>(content, pageable, total == null ? 0 : total);
    }

“서비스 → 서비스 DI”는 별로인가?(feat.Transactional의 옵션)

• 보통 사람들이 꺼리는 이유:

  • ❌ 안 좋은 경우

  • 서비스끼리 순환 의존성

  • 한 서비스가 다른 서비스의 비즈니스 로직을 대신 수행

    ServiceA -> ServiceB
    ServiceB -> ServiceC
    ServiceC -> ServiceA ❌

이건 설계 붕괴

괜찮은 경우는?

• 핵심 차이

• ManagerService는 비즈니스 로직 담당

• LogService는 기술적 관심사(로깅) 담당

즉, 역할이 명확하게 분리되어 있음

이 구조가 “맞는 이유”를 한 줄씩 뜯어보면

책임 분리가 명확하다 (SRP)

• 서비스 : 책임
• ManagerService : 매니저 등록 비즈니스 규칙
• LogService : 요청 기록을 DB에 안전하게 남김

ManagerService가 로그 테이블 직접 만지면 책임이 섞임

트랜잭션 경계를 분리하기 위함

• 핵심 목적은 이거 👇

“매니저 등록이 실패해도 로그는 반드시 저장”

• 이건

  @Transactional(REQUIRES_NEW)

• 메서드 단위 트랜잭션 분리가 필요하고,

• 클래스 안에서는 불가능

• Spring AOP 프록시 특성

그래서 별도 서비스로 분리 + DI 가 올바른 구조.

중요한 포인트 (많이 놓친다고함.)

@Transactional(propagation = REQUIRES_NEW)
public void saveLog() { ... }

• 이걸 같은 서비스 클래스에서 호출하면 적용 안 됨

• 왜냐하면:

  • Spring의 @Transactional은 프록시 기반

  • 자기 자신 메서드 호출(self-invocation)은 프록시를 안 탐

그래서 무조건 다른 Bean이어야 함

LogService 분리는 필수

생각보다 실무에서 흔한 패턴이라고 한다!(feat.튜터님!)

실무 예시들:

OrderService → PaymentLogService

UserService → LoginHistoryService

ReservationService → AuditLogService

“비즈니스 서비스 → 로그/이력 서비스”

매우 정상적인 구조

그럼 언제 서비스 → 서비스 DI가 안 좋을까?

• 피해야 할 경우 체크리스트

  • 서로가 서로를 호출한다 (순환 참조)

  • A 서비스가 B 서비스의 도메인 규칙을 대신 처리

  • “편해서” 그냥 갖다 쓴 경우

  • 공통 로직이라고 다 서비스로 빼버린 경우

요약

이 구조는 비즈니스 로직과 기술적 관심사를 분리하고,

트랜잭션 전파 옵션(REQUIRES_NEW)을 적용하기 위한 의도적인 서비스 분리로

Spring AOP 특성을 고려한 올바른 설계였다!

요약2

서비스 간 DI는 무조건 나쁜 설계가 아니라,

책임이 명확히 분리되고 트랜잭션/기술적 관심사를 분리하기 위한 경우에는 권장되는 구조다.

특히 @Transactional(REQUIRES_NEW)는 자기 자신 호출로는 동작하지 않기 때문에

별도의 서비스 분리가 필수적이다.

트러블 슈팅(3)

Spring Boot 서버를 AWS EC2 + RDS로 배포하고 Health Check API까지 연결하기

목표

• Spring Boot 애플리케이션을 AWS EC2에 배포한다

• RDS(MySQL) 와 연동한다

• 서버가 살아있는지 확인할 수 있는 Health Check API를 만든다

• Health API는 누구나 접근 가능해야 한다

• 배포 과정에서 발생한 문제를 직접 해결하며 AWS 네트워크 / 보안 흐름을 이해한다

로컬 환경과 서버 환경의 차이 인식

• 처음에는 IntelliJ에서 실행하면 잘 되는데, EC2에 배포한 JAR를 실행하면 다음과 같은 문제가 발생했다.

  • 403 Forbidden

  • JWT 관련 에러

  • jar 파일 최신화 오류

  • DB 연결 실패

  • Hibernate Dialect 오류

이 과정에서 “로컬과 서버는 완전히 다른 환경”이라는 걸 명확히 인식하게 됐다.

health 403에러 문제 해결 과정

• 문제 1: EC2연결 후 RDS 연동까지 성공했음에도 health를 연결하였을 때 403 에러가 나는 것을 식별, 코드 수정을 했음에도 불구하고 403에러가 나는 것을 식별

• 원인

  • 어플리케이션 내 코드에 /health 경로를 필터에 통과시키도록 설정해주지 않았음.
  • 코드를 수정한 후에 수정된 jar파일을 EC2에 재빌딩을 해주지 않았음.

• 해결

  • 애플리케이션 코드에 JwtFilter와 SecurityConfig에 /health 경로를 예외처리 해주었음.
  • 수정된 코드를 다시 jar파일로 빌드 후 EC2에 다시 재빌딩 해주었더니 정상 작동 되었음.

JWT 관련 문제 해결 과정

• 문제 2: EC2에서 서버가 아예 안 뜸

  WeakKeyException: key byte array is not secure enough

• 원인

  • JWT Secret Key 길이가 256bit 미만

  • Base64 디코딩을 시도했지만, 실제로는 Base64 문자열이 아니었음

• 해결

  • Base64 인코딩된 256bit 이상 키 사용

  • EC2 환경 변수로 주입

    export JWT_KEY=Base64로_인코딩된_충분히_긴_키

    jwt:
    secret:
    key: ${JWT_KEY}

JPA / RDS 연결 문제 해결

• 문제 3: Hibernate Dialect 오류

  Unable to determine Dialect without JDBC metadata

• 원인

  • EC2에 DB 환경 변수가 없었음

  • Spring Boot가 DB 정보를 아예 못 읽음

• 확인

  env | grep DB

• 해결

  export DB_URL=jdbc:mysql://RDS엔드포인트:3306/mydb
  export DB_USERNAME=admin
  export DB_PASSWORD=비밀번호

  spring:
  datasource:
    url: ${DB_URL}
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}

EC2 ↔ RDS 네트워크 & 보안 그룹 이해

• 핵심 구조

  [인터넷]
   ↓ 8080
  [EC2 - Spring Boot]
   ↓ 3306
  [RDS - MySQL]

사용한 보안 그룹

• EC2 보안 그룹 (launch-wizard-1)

  • 22 (SSH)

  • 8080 (Spring Boot API)

  • 외부에서 서버 접근 허용

• RDS 보안 그룹 (rds-ec2-1)

  • 3306 포트

  • 소스: EC2 보안 그룹

  • IP가 아닌 보안 그룹 기반 연결

이 설정 덕분에 EC2 → RDS 연결 성공

JAR 재빌드 & 배포 과정

• 로컬에서

  ./gradlew clean bootJar

• EC2로 전송

  scp -i key.pem build/libs/expert-0.0.1-SNAPSHOT.jar ubuntu@EC2_IP:/home/ubuntu

• EC2 실행

  java -jar expert-0.0.1-SNAPSHOT.jar

• 정상 실행 로그

  Tomcat started on port 8080
  Started ExpertApplication

Health Check 최종 확인

• 브라우저에서 접속:

  http://EC2_PUBLIC_IP:8080/health

• 응답:

  OK

• 서버 실행 확인

• 인증 없이 접근 가능

• 과제 요구사항 충족

얻은 것

• AWS 배포에서 가장 중요한 건 코드보다 환경

• 보안 그룹은 “열어두는 설정”이 아니라 누구에게 열어두는지가 핵심

• JWT / DB / 서버는 모두 환경 변수 기반으로 관리해야 안전하다!!

• “된다”보다 “왜 되는지 설명할 수 있는 상태”가 중요함....

정리 한 줄

Spring Boot 서버를 AWS EC2에 배포하고,

RDS와 보안 그룹 기반으로 연동한 뒤

인증 없이 접근 가능한 Health Check API를 통해

서버의 Live 상태를 확인할 수 있도록 구성했다.

Spring Boot 서버를 AWS EC2 + RDS로 배포하고 Health Check API까지 연결하기

목표

• Spring Boot 애플리케이션을 AWS EC2에 배포한다

• RDS(MySQL) 와 연동한다

• 서버가 살아있는지 확인할 수 있는 Health Check API를 만든다

• Health API는 누구나 접근 가능해야 한다

• 배포 과정에서 발생한 문제를 직접 해결하며 AWS 네트워크 / 보안 흐름을 이해한다

로컬 환경과 서버 환경의 차이 인식

• 처음에는 IntelliJ에서 실행하면 잘 되는데, EC2에 배포한 JAR를 실행하면 다음과 같은 문제가 발생했다.

  • 403 Forbidden

  • JWT 관련 에러

  • DB 연결 실패

  • Hibernate Dialect 오류

이 과정에서 “로컬과 서버는 완전히 다른 환경”이라는 걸 명확히 인식하게 됐다.

Health Check API 설계

• 요구사항

  • 인증 없이 접근 가능

  • 서버가 살아있다는 것만 확인하면 됨

• 구현

  @GetMapping("/health")
  public ResponseEntity<String> health() {
    return ResponseEntity.ok("OK");
  }
  

Security 설정 .requestMatchers("/health").permitAll()

#### /auth/** 와 /health 는 JWT 없이 접근 가능하도록 설정

---

### JWT 관련 문제 해결 과정
- 문제 1: EC2에서 서버가 아예 안 뜸

WeakKeyException: key byte array is not secure enough

- 원인

  - JWT Secret Key 길이가 256bit 미만

  - Base64 디코딩을 시도했지만, 실제로는 Base64 문자열이 아니었음

- 해결

  - Base64 인코딩된 256bit 이상 키 사용

  - EC2 환경 변수로 주입

export JWT_KEY=Base64로_인코딩된_충분히긴키

jwt: secret: key: ${JWT_KEY}

---

### JPA / RDS 연결 문제 해결
- 문제 2: Hibernate Dialect 오류

Unable to determine Dialect without JDBC metadata

- 원인

  - EC2에 DB 환경 변수가 없었음

  - Spring Boot가 DB 정보를 아예 못 읽음

- 확인

env | grep DB

- 해결

export DB_URL=jdbc:mysql://RDS엔드포인트:3306/mydb export DB_USERNAME=admin export DB_PASSWORD=비밀번호

spring: datasource: url: ${DB_URL} username: ${DB_USERNAME} password: ${DB_PASSWORD}

---

### EC2 ↔ RDS 네트워크 & 보안 그룹 이해
- 핵심 구조

[인터넷] ↓ 8080 [EC2 - Spring Boot] ↓ 3306 [RDS - MySQL]

> #### 사용한 보안 그룹

- EC2 보안 그룹 (launch-wizard-1)

  - 22 (SSH)

  - 8080 (Spring Boot API)

  - 외부에서 서버 접근 허용

- RDS 보안 그룹 (rds-ec2-1)

  - 3306 포트

  - 소스: EC2 보안 그룹

  - IP가 아닌 보안 그룹 기반 연결

#### 이 설정 덕분에 EC2 → RDS 연결 성공

---

### JAR 재빌드 & 배포 과정
- 로컬에서

./gradlew clean bootJar

- EC2로 전송

scp -i key.pem build/libs/expert-0.0.1-SNAPSHOT.jar ubuntu@EC2_IP:/home/ubuntu

- EC2 실행

java -jar expert-0.0.1-SNAPSHOT.jar

- 정상 실행 로그

Tomcat started on port 8080 Started ExpertApplication

---

### Health Check 최종 확인

- 브라우저에서 접속:

http://EC2_PUBLIC_IP:8080/health

- 응답:

OK

```

• 서버 실행 확인
• 인증 없이 접근 가능
• 과제 요구사항 충족

이번 경험에서 얻은 것

• AWS 배포에서 가장 중요한 건 코드보다 환경

• 보안 그룹은 “열어두는 설정”이 아니라 누구에게 열어두는지가 핵심

• JWT / DB / 서버는 모두 환경 변수 기반으로 관리해야 안전하다!!

• “된다”보다 “왜 되는지 설명할 수 있는 상태”가 중요함....

정리 한 줄

Spring Boot 서버를 AWS EC2에 배포하고,

RDS와 보안 그룹 기반으로 연동한 뒤

인증 없이 접근 가능한 Health Check API를 통해

서버의 Live 상태를 확인할 수 있도록 구성했다.

셋팅하고 이해하는데 오랜 시간이 걸렸지만 얼추 감이 잘 잡혔고, 왜 사용해야하는지를 알 수 있게 되었다 야호 ( •̀ ω •́ )y

컴퓨터 구조

• 컴퓨터가 어떻게 동작하는지, 어떤 부품으로 구성되어 있는지 이해하는 학문/관점.

• 소프트웨어가 실행되는 기반 구조를 이해하면 문제 해결, 성능/비용 최적화에 강해진다.

컴퓨터가 이해하는 정보

• 컴퓨터는 모두 이진수(0과 1)로 정보를 이해합니다.

데이터 (Data)

• 숫자, 문자, 이미지, 동영상 등 정적인 정보

• 컴퓨터가 처리하는 값들의 기본 형태

명령어 (Instruction)

• 컴퓨터를 실제로 움직이게 하는 정보

• 데이터가 명령어의 재료라면, 명령어는 컴퓨터가 수행할 행동 자체

• 예: 1과 2를 더하라 → 1, 2는 데이터, → 더하라(add)는 명령어

컴퓨터의 4가지 핵심 부품

• 컴퓨터는 네 가지 주요 부품으로 구성되어 있고, 이들이 함께 작동해 프로그램을 수행합니다.

CPU (중앙처리장치)

• 컴퓨터의 두뇌

• 메모리에서 명령어/데이터를 읽고 해석하고 실행

• 내부 주요 구성 요소:

• ALU (산술논리연산장치): 계산 처리

  • 레지스터: CPU 내부 임시 저장

  • 제어장치 (CU): 동작 제어 신호 전송 및 명령 해석

메모리 (주기억장치, RAM)

• 실행 중인 프로그램의 명령어와 데이터를 저장

• 프로그램이 실행되기 위해서는 반드시 메모리에 올라가 있어야 함

보조기억장치

• 대용량 저장 장치

• 전원이 꺼져도 데이터 유지

• 예: SSD, HDD, USB 등

입출력장치 (I/O)

• 외부와 정보 교환 장치

• 예: 키보드, 마우스, 모니터, 프린터 등

메인보드 & 시스템 버스

• 컴퓨터 안의 부품들이 서로 통신하기 위해 꼭 필요한 것들입니다.

메인보드

• 컴퓨터의 중앙 회로판

• CPU, 메모리, 보조기억장치, I/O 장치 등 모든 핵심 부품이 연결됩니다.

시스템 버스

• 컴퓨터 부품 간의 통신 통로 역할

컴퓨터 동작 흐름 개념

• 강의에서 자주 설명되는 컴퓨터 동작의 큰 흐름은 다음과 같습니다:

  • 프로그램과 데이터는 보조기억장치에 저장

  • 실행을 위해 메모리로 로딩

  • CPU가 명령어를 하나씩 읽어 해석 → 실행

  • 결과는 메모리에 저장되거나 I/O로 출력

• 이 과정을 이해하면 컴퓨터가 어떻게 코드를 실제로 해석·실행하는지 큰 그림이 잡힌다.

요약

컴퓨터 구조의 큰 그림은

‘컴퓨터가 어떤 정보(데이터/명령어)를 어떻게 처리하는가’와

‘CPU, 메모리, 보조기억장치, 입출력장치가 어떻게 협력하는가’의 전체 틀을 이해하는 것입니다.

Long total = queryFactory
    .select(todo.id.count())
    .from(todo)
    .where(
        todo.title.contains(keyword),
        todo.createdAt.between(start, end)
    )
    .fetchOne();

페이징 응답을 만들기 위해 “전체 데이터 개수”를 구하는 쿼리이다.

왜 이 코드가 추가로 필요할까?

• 페이징 응답에는 보통 이 정보들이 필요합니다

• 현재 페이지의 데이터 목록 (content)

• 전체 데이터 개수 (totalElements)

• 전체 페이지 수 (totalPages)

• 현재 페이지 번호

그런데 !!!

• limit, offset이 들어간 조회 쿼리로는 전체 개수를 알 수 없다.

• 목록 조회 쿼리만 있으면 생기는 문제

  List<TodoSearchResponse> content = queryFactory
    .select(...)
    .from(todo)
    .where(...)
    .orderBy(todo.createdAt.desc())
    .offset(pageable.getOffset())
    .limit(pageable.getPageSize())
    .fetch();

• “현재 페이지 데이터”만 조회

• DB에는 총 몇 건이 있는지 모름!!

• 프론트 입장에서는

  “다음 페이지가 있는지?”,

  “총 몇 페이지인지?”를 알 수 없음

그래서 count 쿼리가 필요함

select count(todo.id) from todo ...

• 페이징 조건 ❌ (limit/offset 없음)

• 검색 조건만 동일하게 적용

• 전체 검색 결과 개수만 조회

  • 이 값으로:

    PageImpl<>(content, pageable, total)

• 프론트에서 정확한 페이지 계산 가능

왜 목록 조회랑 쿼리를 분리했을까?

성능 이유

• count는 필요한 컬럼이 id 하나뿐

• projection / join / orderBy 필요 없음

책임 분리

• 조회 쿼리 → 데이터 가져오기

• count 쿼리 → 개수 계산

  • JPA & QueryDSL에서 권장되는 패턴

왜 fetchOne()을 쓰는가?

.select(todo.id.count())

• count()는 결과가 항상 1행

• 리스트가 아니라 단일 값

  • 그래서:

    fetch() ❌ (List<Long>)
    

fetchOne() ✅ (Long)

---

>### 왜 keyword, start, end 조건을 똑같이 넣어야 할까?

#### “검색 조건이 다르면 total이 의미 없어짐”

- 목록 조회 결과: 5개

- total: 전체 100개 (이러면 안됨)

#### 목록 쿼리와 count 쿼리는 조건이 반드시 동일해야 함!!

---

>### 요약
#### 페이징 처리에서는 현재 페이지의 데이터 조회와
#### 전체 데이터 개수 조회를 분리해야 하며,
#### 이를 위해 QueryDSL에서 count 전용 쿼리를 추가로 작성한다.


---

### 실전 코드 적용

```java
// 실제 목록 조회 쿼리 (페이징 대상)
List<TodoSearchResponse> content = queryFactory
        // TodoSearchResponse DTO로 바로 매핑하기 위해 Projections.constructor 사용
        // 엔티티 전체가 아니라 "필요한 필드만" 조회해서 성능 최적화
        .select(Projections.constructor(
                TodoSearchResponse.class,

                // 일정 제목
                todo.title,

                // 해당 일정의 담당자 수
                // JOIN으로 인해 중복 row가 생길 수 있으므로 countDistinct 사용
                manager.id.countDistinct(),

                // 해당 일정의 댓글 수
                // 댓글도 JOIN으로 중복될 수 있으므로 countDistinct 사용
                comment.id.countDistinct()
        ))
        // 기준 테이블은 todo
        .from(todo)

        // 일정과 담당자 관계 LEFT JOIN
        // 담당자가 없는 일정도 검색 결과에 포함시키기 위해 LEFT JOIN
        .leftJoin(todo.managers, manager)

        // 담당자와 유저 JOIN (닉네임 검색을 위함)
        .leftJoin(manager.user, user)

        // 일정과 댓글 LEFT JOIN
        // 댓글이 없는 일정도 검색 결과에 포함
        .leftJoin(todo.comments, comment)

        // 검색 조건
        .where(
                // 제목 키워드 부분 일치 검색
                todo.title.contains(keyword),

                // 담당자 닉네임 부분 일치 검색
                manager.user.nickName.contains(managerNickname),

                // 일정 생성일 범위 검색
                todo.createdAt.between(start, end)
        )

        // todo 기준으로 집계해야 하므로 groupBy 필수
        // count(), countDistinct()를 사용했기 때문
        .groupBy(todo.id)

        // 최신 일정이 먼저 나오도록 정렬
        .orderBy(todo.createdAt.desc())

        // 한 페이지에 가져올 데이터 개수 제한
        .limit(pageable.getPageSize())

        // 실제 데이터 조회
        .fetch();

// 전체 데이터 개수 조회 쿼리 (count 쿼리)
Long count = queryFactory
        // 전체 검색 결과 개수를 구하기 위한 count 쿼리
        .select(todo.id.count())

        // 기준 테이블은 동일하게 todo
        .from(todo)

        // 목록 조회와 "동일한 검색 조건"을 사용해야 함
        // 그래야 페이지 수(totalPages)가 정확해짐
        .where(
                todo.title.contains(keyword),
                todo.createdAt.between(start, end)
        )

        // count는 항상 단일 결과이므로 fetchOne 사용
        .fetchOne();

이 코드에서 꼭 이해해야 할 핵심 포인트

• 목록 조회 쿼리와 count 쿼리를 분리한 이유

  • 목록 조회: limit, groupBy, join → 데이터 표현용

  • count 쿼리: 단순한 구조 → 전체 개수 계산용

페이징에서 정확한 total 값을 얻기 위한 필수 구조

왜 countDistinct를 쓰는가?

manager.id.countDistinct()
comment.id.countDistinct()
JOIN이 들어가면 하나의 todo가 여러 row로 늘어남

• 그냥 count() 쓰면 중복 카운트 발생

• countDistinct()로 실제 개수만 집계

왜 groupBy(todo.id)가 필요한가?

• count / countDistinct는 집계 함수

• 집계 대상이 todo 기준이므로 groupBy(todo.id) 필수

• 없으면 SQL 에러 발생

왜 count 쿼리에는 JOIN이 없는가?

• 전체 개수만 알면 됨

• JOIN은 성능 저하만 유발

의도적으로 단순한 count 쿼리 작성 = 성능 최적화

요약

QueryDSL 페이징에서는

목록 조회 쿼리와 전체 개수(count) 쿼리를 분리하고,

목록 조회는 Projection + groupBy로 최적화하며

count 쿼리는 조건만 동일하게 유지한 채 최대한 단순하게 작성한다.

전체 코드

package org.example.expert.domain.todo.searchRepository;

import com.querydsl.core.types.Projections;
import com.querydsl.core.types.dsl.BooleanExpression;
import com.querydsl.jpa.impl.JPAQueryFactory;
import lombok.RequiredArgsConstructor;
import org.example.expert.domain.todo.dto.response.TodoSearchResponse;
import org.springframework.data.domain.Page;
import org.springframework.data.domain.PageImpl;
import org.springframework.data.domain.Pageable;

import java.time.LocalDateTime;
import java.util.List;

import static org.example.expert.domain.comment.entity.QComment.comment;
import static org.example.expert.domain.manager.entity.QManager.manager;
import static org.example.expert.domain.todo.entity.QTodo.todo;
import static org.example.expert.domain.user.entity.QUser.user;

@RequiredArgsConstructor
public class SearchRepositoryImpl implements SearchRepository {

    private final JPAQueryFactory queryFactory;


    @Override
    public Page<TodoSearchResponse> search(
            String keyword,
            String managerNickname,
            LocalDateTime start,
            LocalDateTime end,
            Pageable pageable
    ) {
        List<TodoSearchResponse> content = queryFactory
                .select(Projections.constructor(
                        TodoSearchResponse.class,
                        todo.title,
                        manager.id.countDistinct(),
                        comment.id.countDistinct()
                ))
                .from(todo)
                .leftJoin(todo.managers, manager)
                .leftJoin(manager.user, user)
                .leftJoin(todo.comments, comment)
                .where(
                        todo.title.contains(keyword),
                        manager.user.nickName.contains(managerNickname),
                        todo.createdAt.between(start, end)
                )
                .groupBy(todo.id)
                .orderBy(todo.createdAt.desc())
                .limit(pageable.getPageSize())
                .fetch();

        Long total = queryFactory
                .select(todo.id.count())
                .from(todo)
                .where(
                        todo.title.contains(keyword),
                        todo.createdAt.between(start, end)
                )
                .fetchOne();

        return new PageImpl<>(content, pageable, total == null ? 0 : total);
    }

“서비스 → 서비스 DI”는 별로인가?(feat.Transactional의 옵션)

• 보통 사람들이 꺼리는 이유:

  • ❌ 안 좋은 경우

  • 서비스끼리 순환 의존성

  • 한 서비스가 다른 서비스의 비즈니스 로직을 대신 수행

    ServiceA -> ServiceB
    ServiceB -> ServiceC
    ServiceC -> ServiceA ❌

이건 설계 붕괴

괜찮은 경우는?

• 핵심 차이

• ManagerService는 비즈니스 로직 담당

• LogService는 기술적 관심사(로깅) 담당

즉, 역할이 명확하게 분리되어 있음

이 구조가 “맞는 이유”를 한 줄씩 뜯어보면

책임 분리가 명확하다 (SRP)

• 서비스 : 책임
• ManagerService : 매니저 등록 비즈니스 규칙
• LogService : 요청 기록을 DB에 안전하게 남김

ManagerService가 로그 테이블 직접 만지면 책임이 섞임

트랜잭션 경계를 분리하기 위함

• 핵심 목적은 이거 👇

“매니저 등록이 실패해도 로그는 반드시 저장”

• 이건

  @Transactional(REQUIRES_NEW)

• 메서드 단위 트랜잭션 분리가 필요하고,

• 클래스 안에서는 불가능

• Spring AOP 프록시 특성

그래서 별도 서비스로 분리 + DI 가 올바른 구조.

중요한 포인트 (많이 놓친다고함.)

@Transactional(propagation = REQUIRES_NEW)
public void saveLog() { ... }

• 이걸 같은 서비스 클래스에서 호출하면 적용 안 됨

• 왜냐하면:

  • Spring의 @Transactional은 프록시 기반

  • 자기 자신 메서드 호출(self-invocation)은 프록시를 안 탐

그래서 무조건 다른 Bean이어야 함

LogService 분리는 필수

생각보다 실무에서 흔한 패턴이라고 한다!(feat.튜터님!)

실무 예시들:

OrderService → PaymentLogService

UserService → LoginHistoryService

ReservationService → AuditLogService

“비즈니스 서비스 → 로그/이력 서비스”

매우 정상적인 구조

그럼 언제 서비스 → 서비스 DI가 안 좋을까?

• 피해야 할 경우 체크리스트

  • 서로가 서로를 호출한다 (순환 참조)

  • A 서비스가 B 서비스의 도메인 규칙을 대신 처리

  • “편해서” 그냥 갖다 쓴 경우

  • 공통 로직이라고 다 서비스로 빼버린 경우

요약

이 구조는 비즈니스 로직과 기술적 관심사를 분리하고,

트랜잭션 전파 옵션(REQUIRES_NEW)을 적용하기 위한 의도적인 서비스 분리로

Spring AOP 특성을 고려한 올바른 설계였다!

요약2

서비스 간 DI는 무조건 나쁜 설계가 아니라,

책임이 명확히 분리되고 트랜잭션/기술적 관심사를 분리하기 위한 경우에는 권장되는 구조다.

특히 @Transactional(REQUIRES_NEW)는 자기 자신 호출로는 동작하지 않기 때문에

별도의 서비스 분리가 필수적이다.

과제를 하면서 딥한 지식들이 점점 늘어난다. 재밌으면서도 항상 부족한 느낌을 받아서 아쉽기도 하다..（；´д｀）ゞ

날짜 검색에서 LocalDate vs LocalDateTime

왜 LocalDate로 입력을 받았을까?

• 사용자는 날짜만 신경 쓰지, 시:분:초까지 직접 입력할 필요가 없음

• UI/UX 관점에서 날짜 입력이 훨씬 직관적임

그런데 응답은 왜 LocalDateTime일까?

• DB에는 생성 시점이 LocalDateTime으로 저장됨

• 응답 DTO는 정확한 생성 시각을 보여주는 게 맞음

입력은 단순하게(LocalDate), 출력은 정확하게(LocalDateTime)

역할에 맞게 타입을 분리하는 것이 설계적으로 더 좋다.

@DateTimeFormat + atStartOfDay / LocalTime.MAX를 쓰는 이유

• @DateTimeFormat(iso = DateTimeFormat.ISO.DATE)
• LocalDate startDate;

왜 이런 변환 로직이 필요한가?

• LocalDate는 시간 정보가 없음

• DB 컬럼은 LocalDateTime

  • 그래서:

  • 시작일 → 00:00:00

  • 종료일 → 23:59:59.999999999

코드가 지저분한데 다른 방법은?

• 이 방식이 의도가 가장 명확하다고 함.

• QueryDSL/JPA에서 시간 경계 버그를 가장 확실히 방지

“지저분해 보여도, 명시적인 코드가 가장 안전하다”

QueryDSL에서 BooleanExpression이 null인데도 동작하는 이유

private BooleanExpression titleContains(String keyword) {
    return keyword == null ? null : todo.title.contains(keyword);
}

null 반환인데 왜 검색 조건이 적용될까?

• QueryDSL의 where()는 null 조건을 자동으로 무시한다.

• 조건이 있으면 AND로 결합하고, 없으면 제외한다고 한다.

  query.where(
    titleContains(keyword),
    createdAtBetween(start, end)
  );

null-safe 동적 쿼리를 위한 의도된 설계

• 장점

  • if-else 지옥 방지

  • 조건 조합 폭발 방지

  • 가독성, 유지보수성 ↑

fetchOne() vs fetch() 차이 (강의내용 중복)

왜 fetchOne을 함부로 쓰면 안 될까?

fetchOne()

• 결과가 1개일 거라 확신할 때만

• 2개 이상이면 예외 발생

  fetch()

• 리스트 조회

• 결과 개수와 무관

“단건 조회가 보장될 때만 fetchOne”

Optional을 쓰는 이유 & orElseThrow 자동완성

Optional을 왜 쓰는가?

• null 반환 → 실수로 NPE 발생

• Optional → “없을 수도 있음”을 타입으로 강제

  userRepository.findById(id)
    .orElseThrow(...)

  Optional 안 쓰면 orElseThrow 자동완성이 안 뜬 이유?

• orElseThrow()는 Optional 전용 메서드

• 엔티티 자체에는 존재하지 않음

Optional은 단순 편의가 아니라

null 가능성을 코드 레벨에서 드러내는 장치

N+1 문제가 발생한 이유와 해결 방식

왜 N+1이 발생했을까?

• 연관 엔티티가 LAZY 로딩

• 반복 접근 시 쿼리가 추가로 실행됨

해결 방법은?

fetch join

• QueryDSL에서 join + fetch

• 필요한 필드만 Projections로 조회

“조회용 쿼리는 엔티티 조회가 아니라 DTO 조회가 더 적합한 경우가 많다”

SecurityConfig에 permitAll이 있는데 JWT 필터에서 또 체크하는 이유

SecurityConfig면 끝 아닌가?

.anyRequest().authenticated()

• 이건 인가(Authorization) 단계

• JwtFilter는 그보다 앞단의 인증(Authentication) 필터

그래서 필터에서도 분기 처리가 필요한 이유

• 필터는 무조건 실행됨

• /auth/** 요청에서도 JWT 검사하면 오류 발생

  @Override
  protected boolean shouldNotFilter(HttpServletRequest request) {
    return request.getRequestURI().startsWith("/auth");
  }

필터 책임: 인증 정보 생성

SecurityConfig 책임: 접근 허용/차단

UsernamePasswordAuthenticationFilter 앞에 JWT 필터를 두는 이유

이 필터는 뭐 하는 놈인가?

• 폼 로그인 기반

• ID/PW 인증 처리

왜 JWT 필터가 앞에 있어야 할까?

• JWT는 이미 인증된 사용자

• UsernamePasswordAuthenticationFilter까지 갈 필요 없음

JWT 인증이 먼저 끝나야

SecurityContext가 채워지고

이후 인가 로직이 정상 동작

오늘의 핵심 정리

“Spring / JPA / Security에서의 설정과 패턴은

‘될 때까지 맞추는 코드’가 아니라

왜 이 레이어에서 이 책임을 가지는지를 이해하는 게 중요하다!!!”

• 인덱스는 데이터 조회 속도를 높이기 위한 ‘검색용 지도’이다.

인덱스 핵심 개념 정리

• 원하는 데이터를 빠르게 조회하기 위한 자료구조

• 테이블과는 별도로 저장됨

• 일반적으로 B-Tree 구조 사용

• PRIMARY KEY, UNIQUE 제약 조건 컬럼에는 자동 생성

인덱스 적용 전 / 후 차이

조회 성능은 크게 향상되지만, 쓰기 성능과 공간 비용은 증가

인덱스 실습

• 사용자 테이블에 대량 데이터(천만 건) 생성

• 인덱스 미적용 상태에서 조회 시 전체 테이블 스캔 발생

• name 컬럼에 인덱스 생성 후 → 동일 조건 조회가 인덱스 탐색으로 전환되어 속도 개선

  CREATE INDEX idx_user_name ON user(name);

정리

인덱스는 조회 성능을 비약적으로 향상시키지만,

무분별하게 사용하면 쓰기 성능 저하와 공간 낭비를 유발한다.

자주 조회되는 컬럼에만 전략적으로 적용하는 것이 중요✨

인덱스는 단순한 정렬이 아님

인덱스는 단순한 가나다순 정렬이 아니라,

데이터를 빠르게 찾기 위한 B-Tree 기반의 탐색 지도이다.

• 단순 정렬: 처음부터 끝까지 순차 탐색

• B-Tree 인덱스: 분기(branch)를 따라 필요한 범위만 탐색

• 탐색 비용은 트리 높이에 비례 → O(log n)

B-Tree 인덱스 동작 원리

• 루트 → 중간 노드 → 리프 노드 순으로 비교

• 불필요한 데이터는 건너뛰고 정확한 경로만 탐색

• Full Scan 대비 수백~수천 배 빠름

  • WHERE id = 60 같은 조회도

    몇 단계 비교만으로 실제 레코드 위치 도달

인덱스 스캔 종류 요약

Unique Scan

• PK / UNIQUE 컬럼 조회

• 정확히 한 건 탐색

• 가장 빠름

• SELECT * FROM users WHERE id = 10;

Range Scan

• 범위 조건 조회

• 시작 위치 탐색 후 연속 읽기

• 정렬된 인덱스 덕분에 ORDER BY 효율적

  WHERE age BETWEEN 20 AND 30
  WHERE name LIKE 'abc%'

Full Index Scan

• 인덱스 전체를 순서대로 탐색

• WHERE 조건은 없지만 ORDER BY 최적화 가능

  SELECT * FROM users ORDER BY name;

Index Condition Pushdown (ICP)

• 조건 일부를 인덱스 단계에서 미리 필터링

• 테이블 접근 횟수 감소 → 디스크 I/O 절약

  WHERE status = 'PAID' AND order_date > '2025-11-01'

Table Full Scan

• 인덱스를 전혀 사용하지 못하는 경우

• 모든 행을 직접 비교 → 가장 느림

  WHERE city = 'Seoul' -- 인덱스 없음

옵티마이저 역할

• DB가 가장 효율적인 실행 계획을 자동 선택

• 개발자는 인덱스 설계만 신경 쓰면 됨

• 실제 사용 여부는 옵티마이저 판단

• 인덱스의 한계

  • 잦은 변경 컬럼 : 삽입/삭제 시 트리 재정렬 비용
  • 과도한 인덱스 쓰기 : 성능 저하
  • 메모리/디스크 사용 : 인덱스도 별도 저장 구조

결론

• 인덱스 유무에 따라 실행 계획(EXPLAIN)이 완전히 달라짐

• PK → Unique Scan

• 범위 조건 → Range Scan

• 인덱스 없음 → Full Table Scan

요약

인덱스는 단순 정렬이 아닌 B-Tree 기반 탐색 구조이며,

조회 성능을 극적으로 개선하지만 쓰기 비용과 공간을 고려해 설계해야 한다.

복합 인덱스(Composite Index) 정의

복합 인덱스는 여러 컬럼을 하나의 인덱스로 묶어,

자주 함께 사용되는 조건을 빠르게 탐색하기 위한 인덱스다.

왜 복합 인덱스가 필요한가?

• 단일 인덱스는 하나의 컬럼 기준 정렬만 가능

• 실무에서는 보통 여러 조건을 함께 조회

• 예: start_date + end_date

이 경우 단일 인덱스 여러 개보다 복합 인덱스 하나가 훨씬 효율적

복합 인덱스의 핵심 규칙

• 왼쪽 접두어 규칙 (Leftmost Prefix Rule)

• 복합 인덱스는 왼쪽(선두) 컬럼부터 순서대로만 사용된다.

  (start_date, end_date)

• start_date 기준으로 먼저 정렬

• 같은 start_date 내에서 end_date 정렬

인덱스 사용 가능 여부 요약

• 복합 인덱스 (a, b, c) 기준

선두 컬럼(a)이 빠지면 인덱스 사용 불가

포인트

• (start_date, end_date) 인덱스

  • start_date + end_date 조건 → ✅ 인덱스 사용

  • end_date 단독 조건 → ❌ Full Table Scan

• 인덱스 순서를 바꾸면 사용은 되더라도

• 쿼리 패턴과 맞지 않으면 비효율적

WHERE 조건과 인덱스 순서는 일치시키는 게 가장 안전

복합 인덱스가 특히 유용한 경우

• 항상 함께 조회되는 컬럼들

• WHERE + ORDER BY를 동시에 만족해야 할 때

• 페이징 쿼리 성능이 중요한 경우

• 대표 예시

  • (category_id, price) → 상품 목록 + 정렬

  • (user_id, order_date) → 사용자별 기간 조회

  • (board_id, created_at) → 게시판 최신글

  • (region, district) → 지역 기반 검색

단일 인덱스 여러 개 vs 복합 인덱스

• 단일 인덱스 여러 개: 옵티마이저 조합 필요, 효율 낮음

• 복합 인덱스 하나: 한 번의 탐색으로 범위 축소

두 컬럼 이상이 항상 함께 쓰이면 복합 인덱스가 정답

요약

복합 인덱스는 자주 함께 조회되는 컬럼을 하나의 B-Tree로 묶어,

왼쪽 접두어 규칙을 기반으로 조회·정렬 성능을 동시에 최적화한다.

목표

• JOIN + GROUP BY 쿼리에서 인덱스 유무에 따른 실행 계획과 성능 차이를 확인한다.

• 테이블 구조 요약

• users

  • id (PK)

  • username (UNIQUE → 자동 인덱스)

• posts

  • id (PK)

  • user_id (FK 성격, 인덱스 없음)

• comments

  • id (PK)

  • post_id (FK 성격, 인덱스 없음)

JOIN 대상 컬럼(posts.user_id, comments.post_id)에 인덱스가 없는 상태

실행 쿼리

• 특정 username의 게시글 목록 조회

• 게시글별 댓글 수 집계

• users → posts → comments LEFT JOIN + GROUP BY post.id

인덱스 없이 실행했을 때

• 문제점

  • posts, comments 모두 Full Table Scan

  • JOIN 컬럼에 인덱스가 없어 모든 행 탐색

  • 전체 스캔량: 11 × 8 = 88행

데이터가 커질수록 기하급수적으로 느려짐

EXPLAIN에서 꼭 볼 3가지

JOIN 컬럼에 인덱스 추가

인덱스 추가 후 실행 계획

• 개선 효과

  • Full Scan 제거

  • JOIN 대상만 정확히 탐색

  • 전체 스캔량: 약 3~4행 수준

  • 실행 시간: 100200ms → 13ms

요약

JOIN 성능의 핵심은 WHERE 조건뿐 아니라

JOIN 컬럼(user_id, post_id)에 인덱스가 있는가이다.

EXPLAIN에서 ALL + NULL + rows 많음이면 → 인덱스 설계부터 의심하자.

공부하자...이제 쿼리 성능을 개선하는 법도 알게 되었다..! ( •̀ ω •́ )y

자주 사용하는 데이터를 메모리(In-memory)에 임시로 저장해,

DB나 외부 API 호출 없이 빠르게 응답하기 위한 기술이다.

캐시의 핵심 목적

• 응답 속도 향상

• DB 부하 감소

• 트래픽 및 외부 API 비용 절감

• 캐시 히트(Hit) 시에는 메모리에서 바로 응답하므로 매우 빠름.

• 캐시 미스(Miss) 시에만 DB를 조회한다.

캐시 기본 구조

요청(Request)
   ↓
[ Cache ] → HIT → 즉시 응답
   ↓
 MISS
   ↓
[ DB ] → 조회 후 캐시에 저장 → 응답

처음 요청은 느리지만(Cache Miss),

이후 요청은 빠르다(Cache Hit)

DB와 캐시의 역할 차이

• DB는 신뢰성 중심,
• 캐시는 성능 최적화를 위한 보조 수단

실무에서는 DB + Cache를 함께 사용하는 구조가 기본이다.

비유로 이해하기

• DB = 책상 서랍 → 안전하지만 꺼내는 데 시간이 걸림

• Cache = 책상 위 → 바로 사용 가능하지만 오래되면 다시 확인 필요

실무 시스템은 “서랍에서 꺼내 자주 쓰는 것을 책상 위에 올려두는 구조”

Cache Hit / Miss

• 예시

  • DB 응답: 약 50ms

  • Cache 응답: 13ms ➡ 약 1550배 성능 차이

캐시가 필요한 이유

• 캐시가 없을 때

  • 반복적인 DB 조회

  • 외부 API 호출 지연

  • 트래픽 증가 시 서버 병목 발생

• 캐시 도입 효과

  • 응답 속도 대폭 향상

  • DB 및 외부 API 부하 감소

  • 대량 트래픽 대응 가능

특히 조회(Read)가 많은 API에서 효과가 크다.

캐시 유형

로컬 캐시 : 애플리케이션 내부 메모리 [ConcurrentHashMap, Caffeine] 분산 캐시 : 외부 서버에서 공유 [Redis, Memcached]

• 로컬 캐시

  • 매우 빠름

  • 서버 간 데이터 공유 불가

• 분산 캐시

  • 네트워크 비용 존재

  • 여러 서버에서 캐시 공유 가능

캐시 전략(Cache Strategy)

• 대표 전략

• Cache-aside 흐름

  요청 → 캐시 확인
   ↓
  없음 → DB 조회
   ↓
  캐시에 저장 (TTL 설정)
   ↓
  응답 반환

장점: 단순하고 범용적

단점: 최초 요청은 느림

캐시 일관성 문제

• 문제 상황

  • DB는 최신인데, 캐시는 이전 데이터

• 주요 원인

  • TTL이 너무 김

  • DB 업데이트 시 캐시 무효화 누락

캐시의 가장 큰 기술적 과제는 “성능과 정확성 사이의 균형”

TTL & Eviction Policy

• TTL (Time-To-Live)

  • 캐시 데이터의 유효 시간

  • 만료 시 자동 삭제

    SET key value EX 300   # 300초 유지

• Eviction Policy (삭제 정책)

  • LRU: 최근 사용 안 한 데이터 제거

  • LFU: 사용 빈도 낮은 데이터 제거

  • FIFO: 먼저 들어온 데이터 제거

• 실무 캐시 활용 사례

• 캐싱 설계 시 주의점

  • 캐시는 DB의 보조 수단

  • TTL은 너무 짧아도, 길어도 문제

  • 변경 잦은 데이터보다 조회 많은 데이터에 적용

  • 캐시 Key 설계 명확히

    user:42
    post:1001

• 캐시 장애 시 DB fallback 처리 필수

요약

캐시는 “정확성을 희생하지 않는 선에서 성능을 극대화하기 위한 도구”이며,

읽기 많은 시스템에서 필수적인 인프라이다.

Spring Cache 개념과 사용법 정리

Spring Cache

Spring이 제공하는 캐싱 추상화(Cache Abstraction) 기능으로,

캐시 로직을 직접 구현하지 않고 어노테이션 기반으로 캐시를 제어할 수 있게 해준다.

• 핵심 포인트

  • 캐시 구현체와 비즈니스 로직 분리

  • 동일한 코드로 로컬 캐시 ↔ Redis 전환 가능

  • 캐시 접근 로직을 AOP 방식으로 처리

• 구조 개념

  @Cacheable / @CacheEvict / @CachePut
        ↓
  [ Spring Cache Abstraction ]
        ↓
  CacheManager
        ↓
  Cache 구현체 (Caffeine, Redis 등)

캐시 기술이 바뀌어도 서비스 코드는 그대로 유지

기본 설정

• 의존성 추가 (Caffeine 로컬 캐시 예시)

  implementation 'org.springframework.boot:spring-boot-starter-cache'
  implementation 'com.github.ben-manes.caffeine:caffeine'

• 캐시 활성화

  @SpringBootApplication
  @EnableCaching // 캐시 기능 활성화
  public class Application {
    public static void main(String[] args) {
        SpringApplication.run(Application.class, args);
    }
  }

• @EnableCaching 없으면 → 어노테이션이 있어도 캐시 동작 안 함

• 캐시 설정 (application.yml)

  spring:
  cache:
    caffeine:
      spec: maximumSize=100,expireAfterWrite=10s

• 최대 캐시 엔트리: 100개

• 데이터 생성 후 10초 뒤 만료

TTL 동작 시나리오 이해

• expireAfterWrite 기준

  • 조회를 계속해도 TTL은 연장되지 않음

  • 만료 후 접근 시 새 캐시 생성

@Cacheable — 조회 결과 캐싱

@Cacheable(value = "postCache", key = "#postId")
public PostDto getPostById(long postId) {
    log.info("캐시에 없으니 DB에서 직접 조회");
    Post post = postRepository.findById(postId)
        .orElseThrow(() -> new IllegalArgumentException("등록된 포스트가 없습니다."));
    return PostDto.from(post);
}

• 동작 방식

  • 첫 호출 → DB 조회 후 캐시에 저장

  • 동일 파라미터 재호출 → DB 접근 없이 캐시 반환

두 번째 호출부터는 로그조차 찍히지 않음 = 캐시 정상 동작

@Cacheable의 value & key 구조

• value (Cache Name)

  • 캐시 저장소의 이름

  • 하나의 캐시 그룹(namespace)

    @Cacheable(value = "postCache", key = "#postId")

"postCache"라는 캐시 영역 생성

• key (Entry Key)

  • 캐시 내부에서 데이터를 구분하는 식별자

  • 메서드 파라미터 기반으로 생성

Cache name: postCache Key: 1 Value: PostDto(...)

- 전체 캐시 구조 예시

CacheManager ┣━━ userCache │ ┗━━ key: 1 → UserDto ┣━━ postCache │ ┣━━ key: 10 → PostDto │ ┗━━ key: 11 → PostDto ┗━━ commentCache ┗━━ key: 101 → CommentDto

#### value = 캐비닛 이름, key = 서류 번호

---

>## value & key 설계 기준

- 같은 도메인은 같은 value 사용
```java
@Cacheable(value = "postCache", key = "#postId")
@Cacheable(value = "postCache", key = "#username")

같은 캐시 그룹, 다른 key

• key 충돌 주의

postCache::1 postCache::"1"

#### username이 "1"이면 충돌 가능성 발생

- 해결 방법: prefix 사용
```java
@Cacheable(value = "postCache", key = "'id:' + #postId")
@Cacheable(value = "postCache", key = "'username:' + #username")

• 결과

  postCache::id:1
  postCache::username:kim

캐시 Key 네이밍 규칙

• 기본 원칙

  • 고유하고 일관된 형식

  • 도메인 중심 설계

    user:1
    post:1001
    search:keyword:page

• 실무 팁

  • : 또는 :: 구분자 사용

  • Redis 사용 시 prefix 기반 관리

  • 운영 환경에서는 짧지만 의미 명확하게

@CacheEvict — 캐시 삭제

@CacheEvict(value = "postCache", key = "#postId")
public void deletePost(long postId) {
    // 게시글 삭제 로직
}

• 사용 시점

  • 삭제

  • 상태 변경

  • 더 이상 캐시가 유효하지 않을 때

@CachePut — 캐시 갱신

@CachePut(value = "postCache", key = "#postId")
public PostDto updatePost(long postId) {
    // 게시글 수정 로직
}

• 특징

  • 항상 메서드 실행

  • 실행 결과를 캐시에 강제로 갱신

  • 조회용(@Cacheable)과 역할 분리

요약

Spring Cache는 캐시 구현체와 비즈니스 로직을 분리해

어노테이션만으로 일관성 있고 안전한 캐싱을 가능하게 해준다.

Redis

Redis(Remote Dictionary Server) 는

모든 데이터를 메모리(RAM)에 저장하는 초고속 Key-Value 데이터베이스이다.

• 디스크가 아닌 메모리 기반 → 매우 빠른 읽기/쓰기

• 주 용도: 캐시, 세션, 실시간 데이터 처리

실무에서는 보통

DB의 보조 저장소(Cache Server) 로 사용된다.

RDB vs Key-Value DB (Redis)

DB = 정확성 / Redis = 속도

Redis가 빠른 이유

Redis는디스크 I/O가 없기 때문에 압도적으로 빠르다.

Redis의 주요 특징

단순 캐시를 넘어 자료구조 서버 역할까지 수행 가능

Redis 자료형과 활용 사례

• String

  • 가장 기본적인 타입

  • 문자열, 숫자 모두 저장 가능

• 활용

  • 게시글/상품 캐싱

  • 로그인 토큰

  • 조회수, 좋아요 수 카운팅

    set viewCount 10
    incr viewCount

• List

  • 순서가 있는 데이터 구조

  • Queue / Stack 용도로 활용 가능

• 활용

  • 실시간 채팅 메시지

  • 최근 본 상품 목록

  • 주문 대기열

    lpush recent_posts "post1"
    rpush recent_posts "post2"
    lrange recent_posts 0 -1

• Set

  • 중복 없는 집합

• 활용

  • 좋아요 누른 사용자 목록

  • 태그 관리

  • 팔로워 / 팔로잉 관계

    sadd tags "spring"
    sadd tags "redis"
    smembers tags

• Hash

  • 하나의 Key에 여러 필드-값 저장 (Map 구조)

• 활용

  • 사용자 정보 캐싱

  • 상품 상세 정보

  • 로그인 세션 데이터

hset user:1 name "Ravi" age 30
hgetall user:1

RDB의 한 Row를 Redis Hash로 표현하는 경우가 많다.

• Sorted Set (ZSet)

  • score 기반 자동 정렬

• 활용

  • 랭킹 시스템

  • 인기 게시글 순위

  • 실시간 순위 갱신

    zadd ranking 100 "ravi"
    zrevrange ranking 0 -1 WITHSCORES

Redis 데이터 영속성 (Persistence)

Redis는 기본적으로 휘발성이지만,

옵션을 통해 디스크에 저장 가능하다.

그래도 RDB만큼의 안정성은 아님

Redis 사용 시 주의사항

• Redis는 주 저장소가 아니다

• 메모리 기반 → 장애 시 데이터 유실 가능

• 반드시 DB와 함께 사용해야 안정적

• 이상적인 구조

• 원본 데이터 : MySQL, PostgreSQL

• 빠른 접근 : Redis

• 조합 : DB는 진실, Redis는 복사본

요약

Redis는 초고속 메모리 기반 Key-Value 저장소로,

DB의 부하를 줄이고 실시간 처리를 가능하게 해주는 캐시 서버이다.

RedisTemplate과 Cache-Aside 패턴 정리

RedisTemplate

Spring이 제공하는 Redis 전용 클라이언트로,

Java 코드로 Redis 명령어를 실행할 수 있게 해주는 도구이다.

즉,

우리는 Java 코드로 set, get을 호출하고

RedisTemplate이 이를 Redis 명령어(SET, GET 등) 로 변환해 서버에 전달한다.

Redis에서 받은 결과는 다시 Java 객체로 변환되어 반환된다.

RedisTemplate 동작 흐름

[ Java 코드 ]
   "user:1 = Ravi" 저장 요청
        ↓
[ RedisTemplate ]
   SET user:1 "Ravi"
        ↓
[ Redis 서버 ]
   메모리에 저장
        ↓
[ 결과 반환 ]

Redis 명령어를 직접 쓰지 않아도 되는 이유

간단한 예제

redisTemplate.opsForValue().set("user:1", "Ravi");
String name = (String) redisTemplate.opsForValue().get("user:1");
System.out.println(name); // Ravi

• 내부적으로 실행되는 Redis 명령:

  SET user:1 "Ravi"
  GET user:1

• opsForValue() → Redis의 String 타입을 다루는 도우미 객체

RedisTemplate 주요 역할 정리

Redis의 모든 자료구조를 Java API로 다룰 수 있음

TTL(Time To Live) 설정

redisTemplate.opsForValue()
    .set("temp:data", "123", 10, TimeUnit.MINUTES);

• Redis 내부 명령:

  SET temp:data "123" EX 600

• TTL이 지나면 자동 삭제 ➡ 캐시 데이터 최신성 유지

Cache-Aside 패턴 (읽기 캐싱)

읽을 때는 캐시를 먼저 확인하고,

없으면 DB에서 조회한 뒤 캐시에 저장하는 방식이다.

• 기본 원칙

  • Read: 캐시 → DB → 캐시 저장

  • Write: DB 변경 후 캐시 삭제(Evict)

• 캐시 없는 버전

  public Post getPost(Long postId) {
    return postRepository.findById(postId)
        .orElseThrow(() -> new RuntimeException("Post not found"));
  }

• Redis 적용 버전 (Cache-Aside)

  public Post getPost(Long postId) {
    String key = PREFIX + postId;
  
    // 1. 캐시 확인
    Post cached = (Post) redisTemplate.opsForValue().get(key);
    if (cached != null) {
        System.out.println("Cache Hit");
        return cached;
    }
  
    // 2. 캐시 미스 → DB 조회
    Post post = postRepository.findById(postId)
        .orElseThrow(() -> new RuntimeException("Post not found"));
  
    // 3. 캐시에 저장
    redisTemplate.opsForValue().set(key, post, 10, TimeUnit.MINUTES);
    return post;
  }

• 핵심 포인트

  • 캐시에 있으면 DB 접근 ❌

  • 없을 때만 DB 조회

  • 조회 결과를 캐시에 저장

Redis 캐시 Key 네이밍 전략

Redis는 모든 데이터가 Key 기반이기 때문에

Key 설계가 곧 운영 안정성이다.

• 기본 규칙

  {도메인}:{리소스}:{식별자}

• 예시

• : 로 계층 구조 표현

• 고정 prefix로 역할 구분

• Key만 봐도 의미 파악 가능하게

• 코드에서는 상수로 관리

  private static final String USER_CACHE_PREFIX = "user:";
  private static final String POST_CACHE_PREFIX = "post:";

TTL 설계 전략

• TTL은 캐시의 생명주기다.

• 예시

  redisTemplate.opsForValue()
    .set("post:1", post, 10, TimeUnit.MINUTES);

• 10분 후 자동 만료

• 데이터별 TTL 예시

  데이터	TTL	이유
  사용자 프로필	1시간~1일	변경 적음
  게시글 상세	5~30분	수정 가능성
  실시간 인기글	1~5분	빠른 변동
  로그인 세션	10~60분	보안
  통계/대시보드	5분 이내	최신성 중요

• TTL 설계 팁

  • 변경 주기 ⬆ → TTL 짧게

  • 조회 빈도 ⬆ & 변경 적음 → 캐싱 효율 ↑

  • TTL 너무 짧음 ❌ → 캐시 효과 감소

  • TTL 너무 김 ❌ → 데이터 불일치 위험

요약

RedisTemplate은 Java 코드로 Redis 자료구조와 명령을 다룰 수 있게 해주는 도구이며,

Cache-Aside 패턴과 함께 사용하면 읽기 성능을 크게 향상시킬 수 있다.

Spring Boot와 Redis 연동 실습 정리

Spring Boot + Redis 연동 목적

• Redis를 캐시 서버로 사용해 조회 성능 개선

  • DB 부하 감소

  • 실무에서 가장 많이 쓰이는 Cache-Aside 패턴 직접 구현

의존성 추가

// Redis 연동
implementation 'org.springframework.boot:spring-boot-starter-data-redis'

• spring-boot-starter-data-redis

  • RedisConnectionFactory

  • RedisTemplate

  • Lettuce 클라이언트 기본 제공

RedisTemplate 설정 (중요 ⭐)

@Configuration
public class RedisConfig {

    @Bean
    public RedisTemplate<String, Object> redisTemplate(
            RedisConnectionFactory connectionFactory
    ) {
        RedisTemplate<String, Object> template = new RedisTemplate<>();
        template.setConnectionFactory(connectionFactory);

        // Key는 문자열
        template.setKeySerializer(new StringRedisSerializer());
        template.setHashKeySerializer(new StringRedisSerializer());

        // Value는 JSON (LocalDateTime 대응)
        template.setValueSerializer(new GenericJackson2JsonRedisSerializer());
        template.setHashValueSerializer(new GenericJackson2JsonRedisSerializer());

        template.afterPropertiesSet();
        return template;
    }
}

• 설정 이유

• StringRedisSerializer : Redis Key를 사람이 읽을 수 있게

• GenericJackson2JsonRedisSerializer : 객체(JSON) 직렬화 + LocalDateTime 대응

• Object 타입 : 다양한 도메인 객체 캐싱 가능

• 이 설정 없으면 → 직렬화 깨짐 / LocalDateTime 에러 자주 발생

Cache-Aside 기본 캐싱

• 핵심 개념

  • 읽기(Read): 캐시 → DB → 캐시 저장

  • 쓰기(Write): DB 수정 후 캐시 삭제

• 게시글 조회 흐름 ``` [Client] ↓ [Controller] ↓ [Service] ↓

1. Redis 캐시 조회 ↓
2. Cache Miss → DB 조회 ↓
3. Redis 캐시에 저장 ↓
4. 응답 반환

• 게시글 수정(업데이트) 흐름 ``` [Client PUT 요청] ↓

1. DB 데이터 수정 ↓
2. Redis 캐시 삭제 (Invalidate)

캐시는 항상 DB보다 늦게 믿는다

• 실무 포인트

수정 시 캐시를 “갱신”보다 삭제(Evict) 하는 것이 안전

다음 조회 시 최신 데이터로 재캐싱

조회수 기반 인기 게시글 (Sorted Set)

• 왜 ZSet을 쓸까?

  • 자동 정렬

  • 점수(score) 기반 순위 관리

  • 실시간 랭킹에 최적화

• 게시글 조회 시 흐름 ``` [게시글 조회 요청] ↓

1. Redis 캐시 조회 ↓
2. Cache Miss → DB 조회 후 캐시 저장 ↓
3. ZSet 조회수 +1 (ZINCRBY) ↓
4. 게시글 응답

• 조회수는 DB에 바로 반영하지 않고 → Redis에서 실시간 집계

• 인기 게시글 조회 흐름 ``` [인기글 조회 요청] ↓

1. ZSet에서 상위 N개 postId 조회 (ZREVRANGE) ↓
2. postId 기반 캐시 조회 ↓
3. 캐시 없으면 DB 조회 후 Redis 저장 ↓
4. 조회수 순서대로 PostDto 반환

• 이 구조의 장점

  • 조회수 증가 = Redis 연산 (초고속)

  • 인기글 조회 시 DB 정렬 ❌

  • 대규모 트래픽에서도 성능 유지

전체 구조 요약

• 역할 분리
  • 원본 데이터 : RDB (MySQL 등)
  • 빠른 조회 : Redis (Cache)
  • 실시간 랭킹 : Redis Sorted Set

DB는 진실, Redis는 가속기

실무 관점에서 배울 점

• RedisTemplate은 저수준 제어에 적합

• Spring Cache(@Cacheable)는 선언적 캐싱

• 랭킹, 카운팅은 Redis 자료구조가 압도적으로 유리

• 캐시 설계는 “어디까지 Redis를 믿을지” 결정하는 작업

요약

Spring Boot에서 Redis를 연동해 Cache-Aside 패턴과 Sorted Set을 활용하면,

조회 성능 개선과 실시간 랭킹을 동시에 만족하는 구조를 만들 수 있다.

공부할 양이.. 너무 많다..(；′⌒`)

• Docker는 애플리케이션과 실행 환경을 하나로 묶어
• 어디서 실행하든 동일하게 동작하도록 만들어주는 컨테이너 기술이다.

코드뿐만 아니라 실행에 필요한 OS, 라이브러리, 설정까지 함께 패키징하여

“내 컴퓨터에서는 되는데?” 문제를 해결해준다.

요약

• Docker = 실행 환경을 통째로 포장하는 기술

Docker가 필요한 이유

• 환경이 다르면 결과도 달라지기 때문이다.

• 개발자 PC: Windows / Mac

• 서버 환경: Linux

• 라이브러리 버전, 패키지 충돌, 환경 변수 차이

• DB, 포트, 경로 설정 문제

같은 코드인데도 실행 결과가 달라지는 문제가 빈번하게 발생한다.

• Docker는 동일한 환경에서 언제나 같은 결과를 보장하기 위해 존재한다.

• 기존 방식: 가상 머신(VM)

  • 예전에는 가상 머신(Virtual Machine) 을 사용했다.

  • OS 위에 또 다른 OS를 실행

  • 완전히 분리된 환경

하지만 무겁고 느리며 자원 소모가 큼

• 문제점

  • VM 1개당 OS 1개 필요

  • 부팅 시간 느림

  • CPU / RAM / 디스크 낭비 큼

컨테이너(Container)는 뭐가 다를까?

• 컨테이너는 운영체제를 새로 띄우지 않는다.

호스트 OS의 커널을 공유하고

애플리케이션 실행에 필요한 것만 격리해서 실행한다.

• VM vs Container 비교

• VM: 컴퓨터 안에 또 다른 컴퓨터

• 컨테이너: 하나의 컴퓨터에서 앱만 격리 실행

컨테이너가 빠른 이유

• OS를 새로 부팅하지 않음

• 호스트 OS의 커널을 그대로 사용

• 필요한 실행 환경만 로드

요약

필요한 환경만 꺼내 쓰기 때문에 빠르고 가볍다.

Docker의 핵심 개념

Image (이미지)

• 실행 환경을 정의한 설계도

• OS, 라이브러리, 애플리케이션, 설정 포함

읽기 전용(Immutable)

• 특징

  • 이미지는 실행되지 않음

  • 하나의 이미지로 여러 컨테이너 생성 가능

• 비유

  • 이미지 = 붕어빵 틀

Container (컨테이너)

• 이미지를 실제로 실행한 결과물

• 독립된 실행 공간

• 가볍고 빠르게 생성 / 삭제 가능

• 특징

  • 서로 간섭하지 않음

  • 필요할 때 만들고 버릴 수 있음

  • 실행 중인 애플리케이션이 여기서 동작

• 비유

  • 컨테이너 = 붕어빵
  • (같은 틀로 원하는 만큼 생성 가능)

컨테이너 하나 = 포맷된 깨끗한 컴퓨터 1대

컨테이너를 사용하는 이유

• 사람마다 다른 개발 환경 문제 해결

• OS 상관없이 동일한 실행 보장

• 환경 설정을 자동화

• 예시

  • Windows / Mac / Linux 상관 없음

  • 환경 변수 차이 없음

  • Ubuntu 설치 필요 없음

  • WSL2, VM 설치 없이도 실행 가능

이미지 하나로 모든 설정이 자동 구성

Docker Hub

• Docker Hub는 이미지 저장소이다.

• GitHub = 코드 저장소

• Docker Hub = 실행 환경(이미지) 저장소

• 특징

  • 전 세계 개발자가 만든 이미지 공유

  • 공식 이미지 다수 제공

• 예시 이미지

  • redis

  • mysql

  • kafka

  • elasticsearch

• 비유

  • Docker Hub = 붕어빵 틀 창고

• 기본 사용 흐름

  • search → pull → run

Docker 전체 흐름

Docker는 깨끗한 실행 환경을 이미지로 정의하고,

그 이미지를 컨테이너로 실행하여

어디서든 동일한 결과를 보장하는 기술이다.

Docker Hub에서 Redis 실행하기 (실습 TIL)

• Docker Hub에서 Redis 이미지 검색

  docker search redis

• Docker Hub는 전 세계 개발자들이 공유하는 도커 이미지 저장소

• OFFICIAL 표시가 있는 이미지는 Redis 공식 팀이 배포한 신뢰 가능한 이미지

• 포인트

  • 실무에서는 가급적 OFFICIAL 이미지를 사용한다.

• Redis 이미지 다운로드 (pull)

  docker pull redis:latest

• pull : Docker Hub에서 이미지를 로컬로 다운로드

• latest : Redis의 최신 버전 태그

• 다운로드된 이미지 확인

  docker images

• 출력 예시:

  REPOSITORY   TAG       IMAGE ID       CREATED        SIZE
  redis        latest    b5d3b2e6f64e   2 weeks ago    117MB

Redis 실행 환경이 이미지 형태로 내 컴퓨터에 저장됨

• Redis 컨테이너 실행

  docker run -d -p 6379:6379 --name redis-container redis:latest

• 옵션 설명 ```

• d 백그라운드(detached) 실행

• p 6379:6379 호스트 ↔ 컨테이너 포트 매핑

• -name redis-container 컨테이너 이름 지정 redis:latest 실행할 이미지

• Redis 설치

• 실행 환경 구성

• Redis 서버 실행

  • 이 모두가 자동으로 완료됨

• 컨테이너 실행 상태 확인

  docker ps

• 출력 예시:

  CONTAINER ID   IMAGE          STATUS          PORTS
  a12b3c4d5e6f   redis:latest   Up 5 seconds    0.0.0.0:6379->6379/tcp

• 확인 포인트

  • STATUS 가 Up → 정상 실행 중

  • 6379->6379 → 외부에서 Redis 접근 가능

-

5. Port(포트)

• 포트는 한 컴퓨터 안에서 프로그램을 구분하는 번호

• IP 주소: 컴퓨터(서버)의 주소

• 포트 번호: 그 컴퓨터 안에서 실행 중인 프로그램의 출입구

• 비유

  • IP = 건물 주소
  • Port = 건물 안의 문 번호

• 대표적인 포트 예시

  • 80 : 웹 서버

  • 3306 : MySQL

  • 6379 : Redis

Docker에서의 포트 매핑

컨테이너는 외부와 격리된 공간이기 때문에

외부에서 접근하려면 포트를 연결해야 한다.

-p [호스트 포트]:[컨테이너 포트]

• 예시 1

  docker run -d -p 6379:6379 redis:latest

• 왼쪽 6379 내 컴퓨터(호스트) 포트

• 오른쪽 6379 컨테이너 내부 Redis 포트

호스트 6379 → 컨테이너 6379 연결

• 예시 2

  docker run -d -p 8000:6379 redis:latest

호스트 8000 포트로 접근하면 컨테이너 내부의 Redis(6379)로 연결됨

실행 중인 Redis 컨테이너 접근하기

• 컨테이너 ID 확인

  docker ps
  

a12b3c4d5e6f redis:latest Up 30 seconds

- 컨테이너 내부 접속

docker exec -it a12b3c4d5e6f bash

- docker exec : 실행 중인 컨테이너에 명령 실행
- -it : 터미널 입출력 모드
- a12b3c4d5e6f : 컨테이너 ID (앞자리만 가능)
- bash : Bash 쉘 실행

- 접속 성공 시:

root@a12b3c4d5e6f:/data#

#### 이제 컨테이너 내부 환경

---

>### Redis CLI 실행

redis-cli

- 정상 접속 시:

127.0.0.1:6379>

#### Redis 서버에 직접 명령어 입력 가능

>### 실습 정리 한 줄 요약
#### Docker Hub에서 Redis 이미지를 내려받아
#### 컨테이너로 실행하고,
#### 포트 매핑을 통해 외부에서 Redis에 접근했다.

---

>## Docker로 MySQL 8.0 실행하기

- MySQL 이미지 다운로드

docker pull mysql:8.0

- pull : Docker Hub에서 이미지 다운로드

- mysql:8.0 : MySQL 8.0 버전 이미지

- MySQL 8.0은 현재 가장 널리 사용되는 안정적인 LTS 버전

- 이미지 다운로드 확인

docker images

- 출력 예시:

REPOSITORY TAG IMAGE ID CREATED SIZE mysql 8.0 9b51f5e3c789 2 weeks ago 595MB

#### MySQL 실행에 필요한 환경이 이미지로 준비됨

>### MySQL 컨테이너 생성 및 실행

#### 로컬 환경에서 기존 MySQL이 3306 포트를 사용 중이기 때문에 컨테이너는 3307 포트로 매핑하여 실행한다.

docker run -d
--name mysql-docker
-e MYSQL_ROOT_PASSWORD=1234
-e MYSQL_DATABASE=nbcam
-p 3307:3306
mysql:8.0

- -d : 백그라운드 실행
- --name mysql-docker : 컨테이너 이름 지정
- -e MYSQL_ROOT_PASSWORD=1234 : MySQL root 계정 비밀번호 설정
- -e MYSQL_DATABASE=nbcam : 컨테이너 시작 시 DB 자동 생성
- -p 3307:3306 : 호스트 포트 → 컨테이너 포트 매핑
- mysql:8.0 : 실행할 이미지

- 포트 구조 설명

  - 호스트(내 컴퓨터): 3307

  - 컨테이너(MySQL 내부): 3306

#### 외부에서는 3307로 접속하지만, 컨테이너 내부 MySQL은 기본 포트인 3306을 그대로 사용

---

>### MySQL 컨테이너 실행 상태 확인

docker ps

- 출력 예시:

CONTAINER ID IMAGE STATUS PORTS b1c3d5e7f9a1 mysql:8.0 Up 10 seconds 0.0.0.0:3307->3306/tcp

- 확인 포인트

  - STATUS : Up → 정상 실행

  - PORTS : 3307->3306 → 포트 매핑 성공

  - 외부 접근 가능 포트: 3307

---

>### Spring Boot와 Docker MySQL 연결

#### Spring Boot 프로젝트의 application.yml에서
#### Docker MySQL 컨테이너 포트(3307)로 연결 설정을 한다.

spring: datasource: url: jdbc:mysql://localhost:3307/nbcam username: root password: 1234 driver-class-name: com.mysql.cj.jdbc.Driver

- 설정 포인트

  - localhost:3307 → 호스트 포트 기준

  - nbcam → 컨테이너 실행 시 자동 생성된 DB

  - Docker를 사용해도 Spring 설정 방식은 기존과 동일

>### 요약
#### Docker로 MySQL 8.0 이미지를 실행하고,
#### 포트 매핑을 통해 로컬 환경과 충돌 없이
#### Spring Boot에서 안정적으로 DB를 연결했다.

---

>### Redis + MySQL 핵심
#### DB도 설치가 아닌 실행의 개념으로 관리 가능
#### 포트 충돌 문제를 Docker로 깔끔하게 해결
#### 개발 환경을 언제든지 삭제 / 재생성 가능
#### 팀원 간 DB 환경 차이를 제거

---

>## Dockerfile & Docker Compose로 Spring Boot 실행하기

### Dockerfile (Spring Boot 이미지 빌드)

FROM eclipse-temurin:21-jdk COPY build/libs/*.jar app.jar ENTRYPOINT ["java", "-jar", "/app.jar"] EXPOSE 8080

- Dockerfile 설명
  - FROM eclipse-temurin:21-jdk : JDK 21 기반 이미지 사용
  - COPY build/libs/*.jar app.jar : 빌드된 jar 파일 복사
  - ENTRYPOINT : 컨테이너 시작 시 실행할 명령
  - EXPOSE 8080 : 애플리케이션 포트 명시

- 포인트

  - Spring Boot 애플리케이션을 컨테이너 이미지로 패키징

  - build/libs/*.jar → Gradle 빌드 결과 자동 매칭

- jar 생성 명령

./gradlew bootJar

---

>### docker-compose.yml 생성

version: '3.8'

services: mysql: image: mysql:8.0 container_name: mysql-compose environment: MYSQL_ROOT_PASSWORD: 1234 MYSQL_DATABASE: nbcam ports: - "3307:3306" volumes: - mysql_data:/var/lib/mysql networks: - spring-net

spring: build: . container_name: spring-compose depends_on: - mysql environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3307/nbcam SPRING_DATASOURCE_USERNAME: root SPRING_DATASOURCE_PASSWORD: 1234 ports: - "8080:8080" networks: - spring-net

volumes: mysql_data:

networks: spring-net:

---

>### docker-compose 구성 요소 설명

- 서비스 구성

  - mysql : MySQL 8.0 컨테이너
  - spring : Dockerfile 기반 Spring Boot 애플리케이션
- depends_on

depends_on:

• mysql

Spring 컨테이너가 MySQL 컨테이너 이후에 실행

단, DB “준비 완료”까지 보장하진 않음 (실무에서는 healthcheck 추가)

• Docker 네트워크

  networks:
  - spring-net

컨테이너는 기본적으로 서로 격리되어 있음

같은 네트워크에 포함되면 서비스 이름으로 통신 가능

• 포인트

  • mysql → 컨테이너 이름이자 호스트 이름

  • Spring에서 localhost ❌

  • jdbc:mysql://mysql:3306/nbcam (컨테이너 내부 기준)

• 볼륨(Volume)

  volumes:
  - mysql_data:/var/lib/mysql

MySQL 데이터 디렉토리와 볼륨 연결

컨테이너 삭제/재시작해도 DB 데이터 유지

• 없다면?

  • 컨테이너 삭제 시 DB 데이터 전부 날아감

• 환경 변수(Environment)

  environment:
  SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3307/nbcam
  SPRING_DATASOURCE_USERNAME: root
  SPRING_DATASOURCE_PASSWORD: 1234

• Spring Boot 설정을 application.yml 대신 주입

• 환경별 설정 분리 가능 (local / dev / prod)

포트 관련 핵심 정리 (중요)

• MySQL 컨테이너 내부 : 3306
• MySQL 컨테이너 간 통신 : 3306
• 호스트 접근용 : 3307

Spring ↔ MySQL 컨테이너 통신은

“같은 네트워크 내부 통신”

→ 호스트 포트(3307)가 아니라 컨테이너 포트(3306)를 사용

• 실무 기준 권장:

  SPRING_DATASOURCE_URL: jdbc:mysql://mysql:3306/nbcam

(3307은 내 PC에서 접근할 때만 필요)

docker-compose 실행

docker compose up -d

• up : compose 파일 기준으로 컨테이너 실행
• -d : 백그라운드 실행

실행 확인

docker ps

• mysql-compose, spring-compose 두 컨테이너가 실행 중이면 정상

• 8080 포트로 Spring Boot 접근 가능

요약

Dockerfile로 Spring Boot를 이미지화하고,

docker-compose로 MySQL과 함께 실행하여

멀티 컨테이너 환경을 한 번에 구성했다.

• 중요한 이유 (실무 관점)

  • 로컬 ↔ 서버 환경 차이 제거

  • DB + 애플리케이션 한 번에 실행

  • 팀원 누구나 docker compose up 한 줄로 환경 구성

  • 운영 환경과 거의 동일한 구조

*개념 정리를 하는데 너무 너무 어렵다 반복적으로 시도해보면서 체득하려고 노력해야겠다..（；´д｀）ゞ *

JPQL이란?

• JPQL(Java Persistence Query Language) 은 엔티티 객체를 대상으로 쿼리를 작성하는 문자열 기반 쿼리 언어이다.

  String jpql = "SELECT u FROM User u WHERE u.age > 20";
  List<User> result = em.createQuery(jpql, User.class).getResultList();

JPQL의 한계

• JPQL은 간단한 쿼리에는 유용하지만, 실무에서 복잡한 조건이나 동적 쿼리를 작성할 때 여러 한계가 드러난다.

요약

• 문자열 기반 : IDE 자동완성, 리팩토링 지원 불가
• 컴파일 타임 검증 불가 : 오타, 필드명 변경 시 런타임 오류
• 유지보수 어려움 : 동적 쿼리 작성 시 가독성 급격히 저하
• 타입 안정성 없음 : 잘못된 타입 비교도 컴파일 통과

쿼리가 길어질수록 안정성과 유지보수성이 급격히 떨어짐

QueryDSL의 등장

• QueryDSL은 JPQL을 타입 안전(Type-safe) 하게 작성하기 위한 쿼리 빌더 라이브러리이다.

핵심 개념

• JPQL을 대체하는 것이 아니라 JPQL을 생성하는 DSL

• SQL이 아닌 JPA 위에서 동작

• Java 코드로 쿼리를 작성

즉, 문자열 대신 객체와 메서드로 쿼리를 작성

QueryDSL 장점 요약

• IDE 자동완성 : 엔티티 필드 자동완성 지원
• 컴파일 타임 검증 : 잘못된 필드 접근 시 컴파일 에러
• 동적 쿼리 강력 : BooleanExpression, BooleanBuilder
• 가독성 : 쿼리 구조가 코드 흐름으로 드러남
• 유지보수성 : 리팩토링에 안전

QueryDSL 설정 (Spring Boot 3.x)

• build.gradle 설정

  implementation 'com.querydsl:querydsl-jpa:5.0.0:jakarta'
  annotationProcessor "com.querydsl:querydsl-apt:5.0.0:jakarta"
  annotationProcessor "jakarta.annotation:jakarta.annotation-api"
  annotationProcessor "jakarta.persistence:jakarta.persistence-api"

• 중요

  • Spring Boot 3.x → jakarta.persistence 기반

  • 반드시 :jakarta suffix 필요

• QuerydslConfig 설정

@Configuration
public class QuerydslConfig {

    @PersistenceContext
    private EntityManager em;

    @Bean
    public JPAQueryFactory jpaQueryFactory() {
        return new JPAQueryFactory(em);
    }
}

JPAQueryFactory를 Bean으로 등록해 Repository에서 사용

Q-Type 이해하기

• QueryDSL은 엔티티를 기반으로 Q타입 클래스를 자동 생성한다.

• 엔티티

  @Entity
  public class User {
  
    @Id @GeneratedValue
    private Long id;
  
    private String username;
    private int age;
  }

• 생성된 QUser

  @Generated("com.querydsl.codegen.EntitySerializer")
  public class QUser extends EntityPathBase<User> {
  
    public static final QUser user = new QUser("user");
  
    public final StringPath username = createString("username");
    public final NumberPath<Integer> age = createNumber("age", Integer.class);
  }

Q클래스 위치

build → classes → java → main → 엔티티 패키지 → Q클래스

이 Q타입을 통해 타입 안전한 쿼리 작성 가능

기본 QueryDSL 쿼리 예제

• Repository 구조

  public interface PostRepository
    extends JpaRepository<Post, Long>, PostCustomRepository {
  
    @EntityGraph(attributePaths = {"user", "comments"})
    List<Post> findByUserUsername(String username);
  }
  

public interface PostCustomRepository { List findPostSummary(String username); }

- Custom Repository 구현
```java
public class PostCustomRepositoryImpl implements PostCustomRepository {

    private final JPAQueryFactory queryFactory;

    public PostCustomRepositoryImpl(EntityManager em) {
        this.queryFactory = new JPAQueryFactory(em);
    }

    @Override
    public List<PostSummaryDto> findPostSummary(String username) {
        return queryFactory
            .select(Projections.constructor(
                PostSummaryDto.class,
                post.content,
                comment.countDistinct().intValue()
            ))
            .from(post)
            .leftJoin(post.comments, comment)
            .where(post.user.username.eq(username))
            .groupBy(post.id)
            .fetch();
    }
}

JPQL → QueryDSL 리팩토링 비교

❌ JPQL 버전

@Query("""
    SELECT new org.example.plus.domain.post.model.dto.PostSummaryDto(
        p.content,
        SIZE(p.comments)
    )
    FROM Post p
    WHERE p.user.username = :username
""")
List<PostSummaryDto> findAllWithCommentsByUsername(
    @Param("username") String username
);

• 문제점

  • 문자열 기반

  • 필드명 변경 시 런타임 오류

  • IDE 도움 거의 없음

✅ QueryDSL 버전

@Override
public List<PostSummaryDto> findAllWithCommentsByUsername(String username) {
    return queryFactory
        .select(Projections.constructor(
            PostSummaryDto.class,
            post.content,
            comment.countDistinct().intValue()
        ))
        .from(post)
        .leftJoin(post.comments, comment)
        .where(post.user.username.eq(username))
        .groupBy(post.id)
        .fetch();
}

• 장점

  • 자동완성 지원

  • 컴파일 타임 검증

  • 쿼리 구조가 코드 흐름 그대로 드러남

요약

JPQL은 문자열 기반이라는 한계가 있으며,

QueryDSL은 이를 타입 안전하고 유지보수 가능한 방식으로 해결한다.

실무에서는 복잡한 조회 로직일수록 QueryDSL의 가치가 커진다.

QueryDSL 기본 개념 & 사용법 정리

QueryDSL 기본 구조 이해

• QueryDSL의 기본 쿼리 구조는 아래 패턴을 따른다.

  queryFactory
    .select(조회대상)
    .from(대상엔티티)
    .where(조건)
    .orderBy(정렬)
    .fetch();

• SQL과 유사하지만 Java 코드 기반

• 각 단계가 메서드 체이닝으로 명확하게 구분됨

• 필요 없는 절은 생략 가능 (where, orderBy 등)

Q-Type(타입) 활용법

• QueryDSL은 컴파일 시점에 엔티티 기반 Q타입 클래스를 자동 생성한다.

• 생성된 QUser 예시

  public class QUser extends EntityPathBase<User> {
  
    public static final QUser user = new QUser("user");
  
    public final StringPath username = createString("username");
    public final StringPath email = createString("email");
    public final EnumPath<UserRoleEnum> roleEnum =
        createEnum("roleEnum", UserRoleEnum.class);
  }

• QUser.user 를 통해 엔티티 필드에 접근

• 문자열이 아닌 객체 + 메서드 기반

• IDE 자동완성 지원

• 필드명 변경 시 컴파일 에러로 즉시 확인 가능

런타임 오류 → 컴파일 타임 오류로 전환

기본 검색 쿼리 예제

• NORMAL 사용자 중 gmail.com 이메일을 가진 사용자 조회

  List<User> result = queryFactory
    .selectFrom(user)
    .where(
        user.roleEnum.eq(UserRoleEnum.NORMAL),
        user.email.endsWith("gmail.com")
    )
    .fetch();

• 결과

  • 앨리스 (alice@gmail.com)
  • 찰리 (charlie@gmail.com)

자주 사용하는 조건 메서드

• eq() : 같다

  • user.roleEnum.eq(ADMIN)

• ne() : 다르다

  • user.username.ne("관리자")

• gt() : 초과

  • user.id.gt(1)

• goe() : 이상

  • user.id.goe(3)

• contains() : 포함

  • user.email.contains("gmail")

• endsWith() : 끝남

  • user.email.endsWith(".com")

• fetch() → 리스트 반환

• fetchOne() → 단건 (2개 이상이면 예외)

• fetchFirst() → 첫 번째 결과만 반환

정렬 (Order By)

• 사용자 이름 오름차순 + ID 내림차순으로 정렬 후 3명 조회

  List<User> result = queryFactory
    .selectFrom(user)
    .orderBy(
        user.username.asc(),
        user.id.desc()
    )
    .limit(3)
    .fetch();

• 결과

  • 관리자
  • 밥
  • 앨리스

• offset() → 시작 위치

• limit() → 조회 개수

• Spring Data Pageable과 함께 사용 가능

문자열 검색 예제

• “여행” 키워드가 포함된 게시글 조회

  List<Post> result = queryFactory
    .selectFrom(post)
    .where(post.content.contains("여행"))
    .fetch();

  • 결과
    • 후쿠오카 여행 후기 (작성자: 앨리스)

• contains() = SQL LIKE '%keyword%'

논리 조합 (AND / OR)

• ADMIN 사용자 또는 이름에 “밥”이 포함된 사용자 조회

  List<User> result = queryFactory
    .selectFrom(user)
    .where(
        user.roleEnum.eq(UserRoleEnum.ADMIN)
            .or(user.username.contains("밥"))
    )
    .fetch();

  • 결과
    • 관리자 (ADMIN)
    • 밥 (NORMAL)

조인(JOIN) 검색

• “앨리스”가 작성한 게시글 조회

  List<Post> result = queryFactory
    .selectFrom(post)
    .join(post.user, user)
    .where(user.username.eq("앨리스"))
    .fetch();

• 결과

  • 후쿠오카 여행 후기
  • 조호바루 맛집 탐방
  • 싱가포르 출퇴근 일상

• join(post.user, user) → SQL의 INNER JOIN과 동일

Fetch Join (N+1 문제 해결)

• 게시글 + 작성자(User)를 한 번에 조회

  List<Post> result = queryFactory
    .selectFrom(post)
    .join(post.user, user).fetchJoin()
    .fetch();

• fetchJoin() 사용 시

  • 지연 로딩 무시

  • 한 번의 쿼리로 연관 엔티티 조회

  • N+1 문제 방지

댓글(Comment) 조회 예제

• “리제로 3기 감상평” 게시글의 모든 댓글 조회

  List<Comment> comments = queryFactory
    .selectFrom(comment)
    .join(comment.post, post)
    .where(post.content.eq("리제로 3기 감상평"))
    .fetch();

• 결과
  • 리제로 명작이죠

페이징 처리

• 게시글 5개씩 조회 (2페이지: 6~10번)

  List<Post> page2 = queryFactory
    .selectFrom(post)
    .orderBy(post.id.asc())
    .offset(5)
    .limit(5)
    .fetch();

• 결과
  • 6. QueryDSL 실무 적용기
  • 7. JPA 성능 튜닝 방법
  • 8. Docker로 배포 환경 만들기
  • 9. 리제로 3기 감상평
  • 10. 롤체 시즌10 덱 분석

요약

QueryDSL은 문자열 JPQL의 한계를 해결하고,

타입 안전성·가독성·유지보수성을 동시에 제공하는 JPA쿼리 도구이다.

기본 CRUD를 넘는 조회 로직에서는 사실상 필수에 가깝다.

동적 쿼리 (Dynamic Query)

• 사용자가 입력한 조건에 따라 쿼리를 유연하게 생성하는 방식을 말한다.

  • 예를 들어 회원 검색 기능에서

    이름만 입력 → 이름으로 검색
    

이메일만 입력 → 이메일로 검색

이름 + 이메일 → 두 조건 모두로 검색

- 처럼 입력 조건이 매번 달라지는 경우에 사용한다.

- QueryDSL에서는 주로 다음 두 가지 방식으로 동적 쿼리를 구현한다.

  - BooleanBuilder

  - BooleanExpression

---

### 동적 쿼리가 필요한 이유

- ❌ Spring Data JPA 메서드 이름 방식의 한계
```java
List<User> findByUsernameAndEmailContainsAndRoleEnum(
    String username, String email, UserRoleEnum roleEnum
);

• 조건이 늘어날수록 메서드가 폭발적으로 증가한다.

  findByUsername
  

findByEmailContains

findByUsernameAndRoleEnum

findByUsernameOrEmailContainsAndRoleEnum …

#### 유지보수 불가능

---

- ❌ if문 조합 방식의 한계
```java
if (username != null && email != null) {
    return userRepository.findByUsernameAndEmail(username, email);
} else if (username != null) {
    return userRepository.findByUsername(username);
} else if (email != null) {
    return userRepository.findByEmail(email);
}

• 조건이 늘어날수록 분기 지옥

• 코드 중복 증가

• 검색 조건 수정 시 로직 전체 수정 필요

동적 쿼리와 단일 책임 원칙(SRP)

• 자주 나오는 질문

“동적 쿼리는 조건을 여러 개 처리하니까 SRP에 어긋나는 거 아닌가요?”

• 올바른 해석

  • 하나의 클래스(또는 메서드)는 하나의 이유로만 변경되어야 한다.

• 동적 쿼리는

  • ❌ 여러 비즈니스 로직을 섞는 것이 아니라
  • ✅ “회원 검색”이라는 하나의 책임 안에서
  • 다양한 입력 조건을 처리하는 것

SRP를 위반하지 않는다

BooleanBuilder vs BooleanExpression

• QueryDSL에서 동적 쿼리를 작성하는 대표적인 두 방식

BooleanBuilder

• 조건을 하나씩 추가하는 가변(Mutable) 컨테이너

• 조건을 순차적으로 조립할 때 유용

  BooleanBuilder builder = new BooleanBuilder();
  

if (username != null) { builder.and(user.username.contains(username)); } if (email != null) { builder.and(user.email.contains(email)); } if (role != null) { builder.and(user.roleEnum.eq(role)); }

List result = queryFactory .selectFrom(user) .where(builder) .fetch();

- 조건을 자유롭게 추가 / 제거 가능

- if문으로 직접 null 체크 필요

- 코드가 길어질 수 있음

> #### BooleanExpression

- 하나의 조건을 표현하는 불변(Immutable) 표현식

- null을 반환하면 QueryDSL이 자동으로 무시
```java
private BooleanExpression usernameContains(String username) {
    return username != null ? user.username.contains(username) : null;
}

private BooleanExpression emailContains(String email) {
    return email != null ? user.email.contains(email) : null;
}

private BooleanExpression roleEq(UserRoleEnum role) {
    return role != null ? user.roleEnum.eq(role) : null;
}

List<User> result = queryFactory
    .selectFrom(user)
    .where(
        usernameContains(username),
        emailContains(email),
        roleEq(role)
    )
    .fetch();

• null 자동 무시 → 코드 깔끔

• 메서드 단위 재사용 가능

• 구조가 명확함

두 방식 비교 요약

실습 예제 (QueryDSL)

• Repository 구조

  public interface UserRepository 
    extends JpaRepository<User, Long>, UserCustomRepository {
  }
  

public interface UserCustomRepository {

List<UserSearchResponse> searchUserByMultiCondition(
    UserSearchRequest request, Pageable pageable);

List<UserSearchResponse> searchUserByMultiConditionV2(
    UserSearchRequest request, Pageable pageable);

Page<UserSearchResponse> searchUserByMultiConditionPage(
    UserSearchRequest request, Pageable pageable);

}

- BooleanExpression 방식
```java
@RequiredArgsConstructor
public class UserCustomRepositoryImpl implements UserCustomRepository {

    private final JPAQueryFactory queryFactory;

    @Override
    public List<UserSearchResponse> searchUserByMultiCondition(
            UserSearchRequest request, Pageable pageable) {

        return queryFactory
            .select(Projections.constructor(UserSearchResponse.class,
                user.username,
                user.email,
                user.roleEnum))
            .from(user)
            .where(
                usernameContains(request.getUsername()),
                emailContains(request.getEmail()),
                roleEq(request.getRole())
            )
            .orderBy(user.username.asc())
            .offset(pageable.getOffset())
            .limit(pageable.getPageSize())
            .fetch();
    }

    private BooleanExpression usernameContains(String username) {
        return username != null ? user.username.contains(username) : null;
    }

    private BooleanExpression emailContains(String email) {
        return email != null ? user.email.contains(email) : null;
    }

    private BooleanExpression roleEq(UserRoleEnum role) {
        return role != null ? user.roleEnum.eq(role) : null;
    }
}

• BooleanBuilder 방식

  @Override
  public List<UserSearchResponse> searchUserByMultiConditionV2(
        UserSearchRequest request, Pageable pageable) {
  
    BooleanBuilder builder = new BooleanBuilder();
  
    if (request.getUsername() != null && !request.getUsername().isBlank()) {
        builder.and(user.username.contains(request.getUsername()));
    }
  
    if (request.getEmail() != null && !request.getEmail().isBlank()) {
        builder.and(user.email.contains(request.getEmail()));
    }
  
    if (request.getRole() != null) {
        builder.and(user.roleEnum.eq(request.getRole()));
    }
  
    return queryFactory
        .select(Projections.constructor(UserSearchResponse.class,
            user.username,
            user.email,
            user.roleEnum))
        .from(user)
        .where(builder)
        .orderBy(user.username.asc())
        .offset(pageable.getOffset())
        .limit(pageable.getPageSize())
        .fetch();
  }

• Page 객체 반환 방식

  @Override
  public Page<UserSearchResponse> searchUserByMultiConditionPage(
        UserSearchRequest request, Pageable pageable) {
  
    BooleanBuilder builder = new BooleanBuilder();
  
    if (request.getUsername() != null && !request.getUsername().isBlank()) {
        builder.and(user.username.contains(request.getUsername()));
    }
  
    if (request.getEmail() != null && !request.getEmail().isBlank()) {
        builder.and(user.email.contains(request.getEmail()));
    }
  
    if (request.getRole() != null) {
        builder.and(user.roleEnum.eq(request.getRole()));
    }
  
    // 데이터 조회
    List<UserSearchResponse> content = queryFactory
        .select(Projections.constructor(UserSearchResponse.class,
            user.username,
            user.email,
            user.roleEnum))
        .from(user)
        .where(builder)
        .offset(pageable.getOffset())
        .limit(pageable.getPageSize())
        .fetch();
  
    // 전체 카운트 조회
    Long total = queryFactory
        .select(user.count())
        .from(user)
        .where(builder)
        .fetchOne();
  
    if (total == null) total = 0L;
  
    return new PageImpl<>(content, pageable, total);
  }

  요약

  동적 쿼리는 검색 조건이 유동적인 상황에서 필수이며,

  QueryDSL의 BooleanExpression을 활용하면 가독성과 재사용성을 모두 잡을 수 있다.

JPA 연관관계를 사용하는 이유와 실무에서의 변화

JPA에서 연관관계를 사용하는 이유

JPA는 객체(Object)와 테이블(Table)을 매핑하는 ORM이다. 즉, 단순히 테이블을 다루는 것이 아니라 객체 그래프 탐색을 가능하게 하는 것이 핵심 목적이다.

연관관계 예시 @Entity public class Post {

@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "user_id")
private User user;

}

• 이렇게 매핑하면 아래 코드가 가능해진다.

  post.getUser().getUsername();

• 개발자가 SQL을 직접 작성하지 않아도

• 객체 참조만으로 연관 데이터 접근 가능

  → JPA가 내부적으로 쿼리를 생성

“연관관계는 객체 그래프 탐색을 위해 존재한다.”

하지만 이 편리함이 JPA의 가장 큰 단점의 출발점이 된다.

JPA 연관관계가 만들어내는 문제들

• 대표적인 문제 정리

• N+1 문제 예시

  List<Post> posts = postRepository.findAll();
  

for (Post post : posts) { System.out.println(post.getUser().getUsername()); }

실제 실행 SQL SELECT * FROM post; SELECT * FROM user WHERE id = 1; SELECT * FROM user WHERE id = 2; SELECT * FROM user WHERE id = 3; ...

#### 한 번의 조회(1) + 연관 데이터 N개 → N+1 문제 발생

---

### 그럼에도 JPA 연관관계를 써야 했던 이유

#### “이렇게 문제가 많은데, 왜 연관관계를 쓸까?”

- 이유 정리
  - 트랜잭션 관리 : Dirty Checking, Cascade 전파
  - 객체 지향 모델 : 엔티티 간 참조로 도메인 로직 표현
  - 일관된 상태 관리 : 영속성 컨텍스트가 연관 객체 동기화

#### JPA의 핵심 장점은 객체 그래프 관리이고,
#### 이를 위해 연관관계라는 불편함을 감수해야 했다.

---

### QueryDSL의 등장 — 쿼리를 다시 제어하다

- QueryDSL은 타입 안전한 SQL(JPQL) 빌더이다.

- JPA가 “자동으로 쿼리를 만들어주는 방식”이라면
QueryDSL은 “개발자가 쿼리를 직접 조립하는 방식”이다.
```java
List<Post> result = queryFactory
    .selectFrom(post)
    .join(post.user, user)
    .where(user.username.eq("김동현"))
    .fetch();

• JPA 내부 동작에 의존 ❌

• 개발자가 조인 시점과 조건을 명시적으로 제어 ⭕

• ID 기반 설계 — 연관관계 없는 엔티티

• QueryDSL이 등장하면서 연관관계를 꼭 유지할 필요가 없어졌다.

• ❌ 기존 연관관계 방식

  @Entity
  public class Post {
  
    @ManyToOne(fetch = FetchType.LAZY)
    private User user;
  }
  
  실무형 ID 기반 방식
  @Entity
  public class Post {
  
    private Long userId; // FK만 저장
  }

• 엔티티는 순수 데이터 구조

• 관계는 쿼리에서만 조립

QueryDSL로 명시적 조인

• 이제 관계는 엔티티가 아니라 쿼리에서 정의한다.

  List<PostResponse> result = queryFactory
    .select(Projections.constructor(
        PostResponse.class,
        post.content,
        user.username))
    .from(post)
    .leftJoin(user)
    .on(post.userId.eq(user.id))
    .fetch();

“관계는 코드(@ManyToOne)가 아니라 쿼리(join)로 관리한다.”

설계 변경 후 달라지는 점

실무 흐름의 변화 요약

[JPA 초기]
  객체 중심 설계 → 연관관계 사용
        ↓
[N+1, Lazy 문제 발생]
  fetch join, batch size로 임시 해결
        ↓
[QueryDSL 도입]
  쿼리 직접 제어 가능
        ↓
[현재 실무 트렌드]
  연관관계 제거
  ID 기반 설계 + 명시적 Join(QueryDSL)

“연관이 필요 없는 것은 JPA가,

조인이 필요한 것은 QueryDSL이 담당한다.”

요약

JPA는 객체 그래프 탐색을 위해 연관관계를 도입했지만,

QueryDSL의 등장으로 개발자가 직접 Join을 제어할 수 있게 되었고,

실무에서는 연관관계를 제거한

ID 기반 설계 + 명시적 Join(QueryDSL) 방식이 주류가 되었다.

연관관계 끊기 실습 요약

User
// BEFORE
@OneToMany(mappedBy = "user")
private List<Post> posts = new ArrayList<>();

// AFTER
// 연관관계 제거

Post
// BEFORE
@ManyToOne(fetch = FetchType.LAZY)
private User user;

// AFTER
private long userId;

Comment
// BEFORE
@ManyToOne(fetch = FetchType.LAZY)
private Post post;

// AFTER
private long postId;

요약

연관관계는 JPA의 철학에서 출발했지만,

QueryDSL은 실무의 통제권을 개발자에게 돌려주었다.

불편함이 쌓이면, 기술은 자연스럽게 진화한다.

테스트 코드의 중요성

• 테스트 코드는 시간 낭비가 아니라, 미래의 나를 지켜주는 보험

• 테스트 코드가 없으면 기능 수정 시 기존 코드가 깨질까 항상 불안

  • 배포 후 버그 발견 → 긴급 수정

  • “어제 되던 기능이 오늘 안 됨” 같은 미스터리 발생

테스트 코드

• 기능 수정 후 테스트 한 번으로 안정성 확인

• 리팩토링을 자신 있게 진행 가능

• 기존 기능이 깨지지 않았음을 자동으로 증명

신입 개발자에게 특히 중요한 이유

• 대부분 레거시 프로젝트부터 맡게 됨

• 코드 히스토리·영향 범위를 알기 어려움

• 팀원이 매번 코드 전체를 봐줄 수 없음

이때 테스트 코드가 최후의 안전망

• 배포 전 오류를 자동으로 감지

• 신입 개발자의 실수를 프로젝트가 대신 막아줌

테스트 피라미드 개념

▲  E2E Test (전체 시나리오)
│  Integration Test (통합)
│  Unit Test (단위)
└──────────────────
   빠르고, 자주, 자동화 쉬움

• Unit Test: 메서드/클래스 단위 (가장 중요)

• Integration Test: 여러 계층 묶어서 검증

• E2E Test: 실제 사용자 흐름 검증

단위 테스트가 많을수록 유지보수 쉬움

• 테스트 코드의 핵심 효과 3가지

  • 버그 조기 발견

  • 작성 직후 바로 확인 가능

  • QA 이전에 대부분의 문제 차단

  • 리팩토링 자신감

  • “기존 기능이 깨지지 않음”을 자동 보장

• 협업 효율

  • 테스트 = 코드의 의도 설명서

  • 테스트 통과 = 동작 신뢰

JUnit 기본 개념

• Java 대표 단위 테스트 프레임워크

• Spring Boot 기본 포함 (spring-boot-starter-test)

• 현재 표준: JUnit 5 (Jupiter)

• 기본 실행 흐름 @BeforeEach → @Test → @AfterEach

• 각 테스트는 서로 독립적으로 실행

• 하나 실패해도 다른 테스트에 영향 없음

자주 쓰는 JUnit 어노테이션

• @Test : 테스트 메서드
• @BeforeEach : 테스트 전 초기화
• @AfterEach : 테스트 후 정리
• @BeforeAll : 전체 테스트 시작 전 1회
• @AfterAll : 전체 테스트 종료 후 1회
• @DisplayName : 테스트 이름 가독성 향상
• @Disabled : 테스트 비활성화

Assertions (검증 메서드)

• assertEquals : 값 비교
• assertTrue / assertFalse : 조건 검증
• assertThrows : 예외 발생 검증
• assertNotNull null : 여부
• assertAll : 여러 검증 묶기

테스트 작성 팁

• 메서드명_상황_기대결과

Given-When-Then 패턴

• Given: 조건

• When: 실행

• Then: 검증

테스트 의도가 명확해짐

단위 테스트 핵심 원칙

• 가장 작은 단위를 검증

• 외부 의존성 제거

• DB

• 외부 API

• 파일 시스템

그래서 필요한 개념이 Mock

Mock 객체 (Mockito)

• 실제 객체 대신 사용하는 가짜 객체

• 테스트 대상 외부 의존성 제거용

사용시기

• Repository, DB, 외부 서비스 의존 시

• 주요 어노테이션

  • @Mock : 가짜 객체 생성
  • @InjectMocks : 테스트 대상에 주입
  • @ExtendWith(MockitoExtension.class) : Mockito 연동
  • when().thenReturn() : 동작 정의
  • verify() : 호출 여부/횟수 검증

Mock 사용 여부 판단 기준

• Mock 불필요

  • JwtUtil처럼 순수 로직

  • 외부 의존성 없음

• Mock 필수

  • Service → Repository 의존

  • DB 연결이 포함된 경우

“외부 의존성이 있으면 Mock”

테스트 코드는 명세서이자 안전망

• 테스트 코드는 “이 기능이 어떻게 동작해야 하는지”를 보여주는 살아있는 문서다

• 코드 설명을 글로 읽지 않아도, 테스트 이름 + 시나리오만 봐도, 시스템의 의도를 이해할 수 있어야 좋은 테스트 코드

좋은 테스트 예시

@Test
@DisplayName("사용자 저장 성공 시, DB에서 동일한 이름으로 조회된다")
void 사용자_저장_성공_조회_확인() {
    // Given
    User newUser = new User("ravi", "1234");

    // When
    userService.save(newUser);
    User foundUser = userService.findByUsername("ravi");

    // Then
    assertNotNull(foundUser);
    assertEquals("ravi", foundUser.getUsername());
}

• 테스트 이름만 봐도 행위 + 기대 결과가 명확
• 테스트 = 코드 기반 명세서

테스트 데이터 중복 문제 & Fixture

• 테스트가 늘어나면 이런 코드가 반복됨

  new User("ravi", "1234");

• 이를 해결하는 방법이 공용 테스트 데이터(Fixture)

Fixture 관리 방법 static 변수

class UserServiceTest {

    private static final String DEFAULT_USERNAME = "ravi";
    private static final String DEFAULT_PASSWORD = "1234";

    @Test
    void 회원가입_성공() {
        User user = new User(DEFAULT_USERNAME, DEFAULT_PASSWORD);
        userService.save(user);

        assertEquals(1, userService.count());
    }
}

• 한 곳에서 관리

• 값 변경 시 수정 포인트 1곳

• 간단한 프로젝트에 적합

Fixture 관리 방법 Fixture 전용 클래스 (권장)

public class UserFixture {

    public static User createUser() {
        return new User("ravi", "1234");
    }
}

• 테스트에서 사용

  @Test
  void 회원가입_성공() {
    User user = UserFixture.createUser();
    userService.save(user);
  
    assertEquals(1, userService.count());
  }

• 테스트 가독성 ↑

• 중복 제거

• 여러 테스트 클래스에서 재사용 가능

• 실무에서 가장 많이 쓰는 방식

@BeforeEach + Fixture 조합

@BeforeEach
void setup() {
    userService = new UserService();
    testUser = UserFixture.createUser();
}

• 매 테스트마다 완전히 새로운 상태

• 테스트 간 데이터 간섭(side-effect) 방지

• 테스트 독립성 확보

좋은 테스트 데이터의 조건

• 명확성 : 어떤 역할의 데이터인지 한눈에 보이기
• 단순성 : 테스트 목적에 필요한 최소한의 데이터
• 재사용성 : 여러 테스트에서 활용 가능
• 독립성 : 다른 테스트 결과에 영향 X

단위 테스트 vs 통합 테스트

통합 테스트란

• 여러 계층을 실제 Bean + 실제 DB로 묶어서 검증하는 테스트

• Controller → Service → Repository → DB(H2)

• “진짜로 이 기능이 동작하는가?”를 확인

• 배포 전 최종 안정성 체크 용도

통합 테스트 핵심 어노테이션

• @SpringBootTest : 전체 스프링 컨텍스트 로드
• @Transactional : 테스트 후 자동 롤백
• @AutoConfigureMockMvc : Controller 테스트용

Service 통합 테스트 예시

@SpringBootTest
@Transactional
class PostServiceIntegrationTest {

    @Autowired
    private PostService postService;

    @Autowired
    private UserRepository userRepository;

    @Test
    void 게시글_생성_통합테스트() {
        // Given
        User user = new User("ravi", "1234");
        userRepository.save(user);

        // When
        PostDto result = postService.createPost("ravi", "통합 테스트");

        // Then
        assertThat(result.getContent()).isEqualTo("통합 테스트");
    }
}

• Mock 사용 안할 시

  • 실제 DB 사용

  • 전체 데이터 흐름 검증

Controller 통합 테스트 (MockMvc)

@SpringBootTest
@AutoConfigureMockMvc
@Transactional
class PostControllerTest {

    @Autowired
    private MockMvc mockMvc;

    @Test
    void 게시글_생성_API_성공() throws Exception {
        mockMvc.perform(post("/api/post")
                .contentType(MediaType.APPLICATION_JSON)
                .content("{\"content\":\"테스트\"}"))
            .andExpect(status().isOk());
    }
}

• 실제 HTTP 요청처럼 테스트

• DispatcherServlet → Controller → Service → DB 전부 실행

• 브라우저 없이 API 검증 가능

사용시기

• 단위 테스트

  • 로직 검증

  • 빠른 피드백

  • 가장 많이 작성해야 함

• 통합 테스트

  • 핵심 기능 위주

  • 전체 흐름 확인

  • 너무 많으면 느려짐

단위 테스트가 기반, 통합 테스트는 보조

요약

• 테스트 코드는 문서다

• 테스트 이름 = 기능 설명

• 단위 테스트로 로직을 지킨다

• 통합 테스트로 시스템을 검증한다

공부해야디....ㅠㅠ

정수 4를 1, 2, 3의 합으로 나타내는 방법은 총 7가지가 있다. 합을 나타낼 때는 수를 1개 이상 사용해야 한다.

1+1+1+1 1+1+2 1+2+1 2+1+1 2+2 1+3 3+1 정수 n이 주어졌을 때, n을 1, 2, 3의 합으로 나타내는 방법의 수를 구하는 프로그램을 작성하시오.

입력

첫째 줄에 테스트 케이스의 개수 T가 주어진다. 각 테스트 케이스는 한 줄로 이루어져 있고, 정수 n이 주어진다. n은 양수이며 11보다 작다.

출력

각 테스트 케이스마다, n을 1, 2, 3의 합으로 나타내는 방법의 수를 출력한다.

접근법

• DP 복잡한 문제를 작은 하위 문제로 나누고, 이전에 계산했던 부분 문제의 답을 저장해두었다가 재활용하여 중복 계산을 피하고 효율적으로 최적의 해답을 찾아내는 알고리즘 설계 기법이자 문제 해결 방식

• 일단 5까지는 직접 세어 봤다.

1 = 1
2 = 2
3 = 4
4 = 7
5 = 13

• 뭔가 규칙이 있는지 찾아보니
  • 4의 개수는 1,2,3의 개수들의 합
  • 5의 개수는 2,3,4의 개수들의 합

이걸 활용해야겠다고 생각하였다..!

테스트 케이스를 받는다
        |
1,2,3의 개수를 디폴트로 받는다        
        |
4부터 미리 계산해둔다        
        |
입력받은 값n에 해당되는 개수를 출력한다.

코드

package Sutdy;

import java.util.Scanner;

public class Beak9095_DP {
    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);
        int T = sc.nextInt();
        int[] count = new int[12];

        count[1] = 1;
        count[2] = 2;
        count[3] = 4;

        for (int i = 4; i <= 11; i++) {
            count[i] = count[i - 1] + count[i - 2] + count[i - 3];
        }

        for (int i = 0; i < T; i++) {
            int n = sc.nextInt();
            System.out.println(count[n]);
        }
    }
}

JPQL

• JPQL (Java Persistence Query Language)은 Entity 객체를 대상으로 쿼리를 작성하는 객체 지향 SQL이다.

SQL, JPQL의 차이

• 사용하는 이유

  • 객체 중심 개발에 자연스럽게 녹아들 수 있음
    • JPQL은 SQL이 아닌, 객체(Entity) 를 대상으로 작성함
    • 테이블/컬럼이 아닌 엔티티/필드 기준으로 쿼리를 짜서 객체지향적인 코드를 유지 가능

• 데이터베이스 독립성 확보

  • JPQL은 JPA 구현체(Hibernate 등)가 SQL로 변환해주므로 DBMS에 종속되지 않음

• 정적 타입 지원 + 자동 바인딩

  • @Query, 메서드 네이밍, QueryDSL 등과 조합하면 타입 안정성 확보 및 IDE 자동완성 활용 가능

• 복잡한 쿼리도 객체 기준으로 구성 가능

  • 복잡한 JOIN, 조건 쿼리도 객체 모델에 맞춰 작성 가능

JPQL vs JPA 차이점

JPQL쓰는 시점

사용 예시

• SELECT

  SELECT u FROM User u;      // 전체 유저 객체 조회
  

SELECT u.username FROM User u; // 특정 필드만 조회

- WHERE
```java
SELECT u FROM User u WHERE u.age > 20;

• ORDER BY

  SELECT u FROM User u ORDER BY u.age DESC;

• JOIN

  SELECT * FROM orders o JOIN user u ON o.user_id = u.id WHERE u.username = 'KIM';

EAGER vs LAZY 로딩

요약본

N+1이란?

• 엔티티 1개를 조회했더니, 추가 쿼리가 N개 더 실행되는 현상
• 특히 연관된 데이터를 루프를 돌며 접근할 때 자주 발생

해결방법

Fetch Join

• 연관된 엔티티를 한 번의 쿼리로 함께 조회하기 위한 JPQL 키워드

@Query("SELECT p FROM Post p JOIN FETCH p.comments WHERE p.user.username = :username")

List<Post> findAllWithCommentsByUsername(@Param("username") String username);

• JOIN FETCH 키워드를 사용하면, 지연 로딩 설정이 되어 있더라도 즉시 로딩됨
• 연관된 엔티티들을 SQL의 JOIN으로 함께 가져오기 때문에 추가 쿼리 발생이 없다.

주의사항

• 컬렉션 페이징 불가

  • JOIN FETCH를 사용하면 중복된 결과로 인해 Pageable이 정상 동작하지 않음

• 여러 컬렉션 Fetch Join 금지

  • JPA는 1개 이상의 컬렉션 Fetch Join을 허용하지 않음

• 중복 제거 필요

  • DISTINCT를 사용하여 중복된 엔티티 제거 필요

BatchSize

• Hibernate 설정을 통해 컬렉션 또는 연관된 엔티티들을 배치로 로딩할 수 있게 해주는 기능입니다.

  • JPA에서는 LAZY 로딩 전략이 기본이기 때문에 연관된 엔티티들을 개별 쿼리로 가져오며, 이로 인해 N+1 문제가 발생할 수 있습니다.

  • BatchSize는 이러한 상황에서 Hibernate가 여러 엔티티를 한 번에 조회할 수 있도록 돕는 설정입니다.

  • 즉, LAZY 전략을 유지하면서도 IN 절을 활용한 일괄 조회가 가능해집니다.

글로벌 설정법

• 글로벌 설정 (application.yml)

  spring:
   jpa:
       properties:
           hibernate:
               default_batch_fetch_size: 100

• 개별 설정 (엔티티 또는 컬렉션 필드)

    @OneToMany(mappedBy = "user", fetch = FetchType.LAZY) // ← 지연 로딩!
   @BatchSize(size = 100) 
   private List<Post> posts = new ArrayList<>();

주의 사항

• BatchSize 크기

  • 너무 작으면 효과 미미, 너무 크면 IN 쿼리가 길어져 성능 저하 가능

• Fetch Join과 병행 사용

  • 컬렉션 Fetch Join과 함께 쓰면 안 됨 (예: 페이징 깨짐)

• LAZY 유지 조건

  • 이 설정은 LAZY인 경우에만 유효함

EntityGraph

• Spring Data JPA에서 지원하는 기능으로, 연관관계를 JPQL 없이 즉시 로딩하도록 지정할 수 있다.

@EntityGraph(attributePaths = {"posts"})
@Query("SELECT u FROM User u")
List<User> findAllWithPosts();

DTO Projection

• DB에서 원하는 컬럼만 선택하여 DTO로 직접 매핑하는 방식

@Query("SELECT new com.example.dto.UserDto(u.username, u.age) FROM User u")
List<UserDto> findAllUserDto();

마무리

• 앞으로 N+1 문제에 대해서도 알아봤고, 해결방안까지 공부를 하였으니 앞으로의 문제에 어떤 방식이 더 효율적인 방식인지 판단할 수 있는 능력을 기를 수 있도록 해야겠다.

봄버맨은 크기가 R×C인 직사각형 격자판 위에서 살고 있다. 격자의 각 칸은 비어있거나 폭탄이 들어있다.

폭탄이 있는 칸은 3초가 지난 후에 폭발하고, 폭탄이 폭발한 이후에는 폭탄이 있던 칸이 파괴되어 빈 칸이 되며, 인접한 네 칸도 함께 파괴된다. 즉, 폭탄이 있던 칸이 (i, j)인 경우에 (i+1, j), (i-1, j), (i, j+1), (i, j-1)도 함께 파괴된다. 만약, 폭탄이 폭발했을 때, 인접한 칸에 폭탄이 있는 경우에는 인접한 폭탄은 폭발 없이 파괴된다. 따라서, 연쇄 반응은 없다.

봄버맨은 폭탄에 면역력을 가지고 있어서, 격자판의 모든 칸을 자유롭게 이동할 수 있다. 봄버맨은 다음과 같이 행동한다.

가장 처음에 봄버맨은 일부 칸에 폭탄을 설치해 놓는다. 모든 폭탄이 설치된 시간은 같다. 다음 1초 동안 봄버맨은 아무것도 하지 않는다. 다음 1초 동안 폭탄이 설치되어 있지 않은 모든 칸에 폭탄을 설치한다. 즉, 모든 칸은 폭탄을 가지고 있게 된다. 폭탄은 모두 동시에 설치했다고 가정한다. 1초가 지난 후에 3초 전에 설치된 폭탄이 모두 폭발한다. 3과 4를 반복한다. 폭탄을 설치해놓은 초기 상태가 주어졌을 때, N초가 흐른 후의 격자판 상태를 구하려고 한다.

예를 들어, 초기 상태가 아래와 같은 경우를 보자.

입력

첫째 줄에 R, C, N (1 ≤ R, C, N ≤ 200)이 주어진다. 둘째 줄부터 R개의 줄에 격자판의 초기 상태가 주어진다. 빈 칸은 '.'로, 폭탄은 'O'로 주어진다.

출력

총 R개의 줄에 N초가 지난 후의 격자판 상태를 출력한다.

요약

• t = 1

→ 입력 그대로 출력.

• 짝수 초(t = 2, 4, 6, …)

→ 모든 칸에 폭탄이 설치됨(전부 ‘O’).

• 홀수 초 중 특별한 두 패턴만 반복됨

t = 3 → 첫 번째 폭발 t = 5 → 두 번째 폭발 t = 7 → 다시 t=3 상태 반복 t = 9 → t=5 상태 반복

if n == 1 → 초기 맵
else if n % 2 == 0 → 전부 폭탄 맵
else if n % 4 == 3 → t=3 결과 맵
else if n % 4 == 1 → t=5 결과 맵

접근법

• 초기 맵 저장
• 전부 폭탄인 맵 생성
• 초기 맵 기준으로 폭발시킨 t=3 맵 생성
• t=3 맵 기준으로 폭발시킨 t=5 맵 생성
• 시간 n의 규칙에 따라 최종 출력 선택

코드

import java.util.*;

public class Main {

    static int R, C, N;      // 행, 열, 시간
    static char[][] initial; // 초기 입력 상태
    static char[][] full;    // 모든 칸이 폭탄인 상태 (짝수 초에서 사용)
    static char[][] boom1;   // 첫 번째 폭발 결과 (t=3)
    static char[][] boom2;   // 두 번째 폭발 결과 (t=5)

    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);

        // 입력 크기 받기
        R = sc.nextInt();
        C = sc.nextInt();
        N = sc.nextInt();
        sc.nextLine(); // 개행 제거

        // 초기 맵 입력 받기
        initial = new char[R][C];
        for (int i = 0; i < R; i++) {
            initial[i] = sc.nextLine().toCharArray(); 
            // 한 줄씩 받고 char[]로 변환
        }

        full = makeFullBoard();    // 전부 'O'로 채운 맵 생성
        boom1 = explode(initial);  // t=3 결과 미리 계산
        boom2 = explode(boom1);    // t=5 결과 미리 계산

        print(selectBoard());      // 시간 N에 해당하는 최종 결과 출력
    }

    // ------------------ 최종 맵 선택 로직 ------------------

    // 시간 N에 따라 어떤 맵을 출력할지 결정하는 메서드
    private static char[][] selectBoard() {

        if (N == 1) return initial; // 1초는 입력 그대로

        if (N % 2 == 0) return full; 
        // 짝수 초는 무조건 모든 칸 폭탄 

        if (N % 4 == 3) return boom1; 
        // 3초, 7초, 11초… → 첫 번째 폭발 패턴 반복

        return boom2; 
        // 5초, 9초, 13초… → 두 번째 폭발 패턴 반복
    }

    // ------------------ 모든 칸 폭탄 보드 생성 ------------------

    private static char[][] makeFullBoard() {
        char[][] map = new char[R][C];  // 새로운 보드 생성
        for (int i = 0; i < R; i++) {
            Arrays.fill(map[i], 'O');  
            // 행 단위로 'O'로 채우기
        }
        return map;
    }

    // ------------------ 폭발 터뜨린 보드 생성 ------------------

    private static char[][] explode(char[][] board) {
        // 폭발 후 남는 영역은 폭탄으로 가득하므로 full보드 기반으로 시작
        char[][] next = makeFullBoard();

        // 폭발 범위 정의 (자기 자신 + 상하좌우)
        int[] dx = {1, -1, 0, 0, 0};
        int[] dy = {0, 0, 1, -1, 0};
        // dx, dy를 배열로 폭발 범위를 처리

        for (int x = 0; x < R; x++) {         // 모든 좌표 탐색
            for (int y = 0; y < C; y++) {

                if (board[x][y] == 'O') {     // 현재 위치에 폭탄이 있으면
                    for (int i = 0; i < 5; i++) { // 자기 + 상하좌우
                        int nx = x + dx[i];
                        int ny = y + dy[i];

                        // 보드 범위를 벗어나지 않는지 체크
                        if (nx >= 0 && nx < R && ny >= 0 && ny < C) {
                            next[nx][ny] = '.'; // 폭발 영향 → 비어있는 칸으로 변경
                        }
                    }
                }
            }
        }

        return next; // 폭발 이후의 새로운 보드 반환
    }

    // ------------------ 출력 담당 ------------------

    private static void print(char[][] board) {
        StringBuilder sb = new StringBuilder();
        for (int i = 0; i < R; i++) {
            sb.append(board[i]).append('\n'); 
            // char[] 바로 append하면 문자열로 붙어서 출력
        }

        System.out.print(sb); 
        // 마지막에 한 번만 출력
    }
}

춘향이는 편의점 카운터에서 일한다.

손님이 2원짜리와 5원짜리로만 거스름돈을 달라고 한다. 2원짜리 동전과 5원짜리 동전은 무한정 많이 가지고 있다. 동전의 개수가 최소가 되도록 거슬러 주어야 한다. 거스름돈이 n인 경우, 최소 동전의 개수가 몇 개인지 알려주는 프로그램을 작성하시오.

예를 들어, 거스름돈이 15원이면 5원짜리 3개를, 거스름돈이 14원이면 5원짜리 2개와 2원짜리 2개로 총 4개를, 거스름돈이 13원이면 5원짜리 1개와 2원짜리 4개로 총 5개를 주어야 동전의 개수가 최소가 된다.

입력

첫째 줄에 거스름돈 액수 n(1 ≤ n ≤ 100,000)이 주어진다.

출력

거스름돈 동전의 최소 개수를 출력한다. 만약 거슬러 줄 수 없으면 -1을 출력한다.

요약

• 거스름돈을 2원, 5원 동전으로만 만들어야 하는 문제.

• 목표: 동전 개수를 최소로 사용해야한다.

• 정확히 나누어 떨어지지 않으면 -1 출력한다.

접근법

• 5원과 2원밖에 없으므로 2원보다 큰 5원을 가장 많이 써야 최소한의 동전을 사용했다는 결론.

• 따라서 전체 값의 5를 나눴을 때 나머지가 0이나오면 베스트이고 나머지값을 2로 나눴을 시 나누어 떨어지면 그 동전의 개수가 가장 최소한의 개수가 될 것임.

• 다만 나누어 떨어지지 않을 경우 5원을 빼가면서 다시 계산을 해주어야하고 다 빼서도 안되면 -1을 반환시키면 된다.

• n(전체값) = 5a(5원) + b(나머지)

• b = n % 5

  b = 0 → OK
  

b = 1 → 2원으로 만들 수 없음 → 5원 1개 빼서 조정 필요

b = 2 → 2원 1개로 가능

b = 3 → 2원으로 만들 수 없음 → 5원 1개 빼서 조정 필요

b = 4 → 2원 2개로 가능

-  b가 1, 3일 경우에만 5원을 하나씩 빼서 재계산을 해야한다.

- 다만!! n자체가 1, 3이 들어올 경우에는 예외처리를 해주어야한다.


### 코드

```java
package Sutdy;

import java.util.Scanner;

public class Beak14916_Greedy {
    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);
        int n = sc.nextInt();

        // n값 자체가 1, 3일경우엔 -1을 반환하도록 예외처리
        if (n == 1 || n == 3) {
            System.out.println(-1);
            return;
        }

        // 5원의 개수
        int fiveNum = n / 5;

        // 나머지 1 또는 3 → 5원 하나를 뺌
        if (n % 5 == 1 || n % 5 == 3) {
            fiveNum -= 1;
        }

        // 나머지 값
        int remainder = n - (fiveNum * 5);

        // 2원의 개수
        int twoNum = remainder / 2;

        //합친 것 (5로 딱 떨어질 경우 2원의 개수는 0으로 채워지기 때문에 이상 없음)
        System.out.println(fiveNum + twoNum);
    }
}

문제 1092번

지민이는 항구에서 일한다. 그리고 화물을 배에 실어야 한다. 모든 화물은 박스에 안에 넣어져 있다. 항구에는 크레인이 N대 있고, 1분에 박스를 하나씩 배에 실을 수 있다. 모든 크레인은 동시에 움직인다.

각 크레인은 무게 제한이 있다. 이 무게 제한보다 무거운 박스는 크레인으로 움직일 수 없다. 모든 박스를 배로 옮기는데 드는 시간의 최솟값을 구하는 프로그램을 작성하시오.

입력

첫째 줄에 N이 주어진다. N은 50보다 작거나 같은 자연수이다. 둘째 줄에는 각 크레인의 무게 제한이 주어진다. 이 값은 1,000,000보다 작거나 같다. 셋째 줄에는 박스의 수 M이 주어진다. M은 10,000보다 작거나 같은 자연수이다. 넷째 줄에는 각 박스의 무게가 주어진다. 이 값도 1,000,000보다 작거나 같은 자연수이다.

출력

첫째 줄에 모든 박스를 배로 옮기는데 드는 시간의 최솟값을 출력한다. 만약 모든 박스를 배로 옮길 수 없으면 -1을 출력한다.

요약

• 여러 개의 크레인 → 각각 들 수 있는 최대 무게가 다름

• 박스도 여러 개 → 각 박스마다 무게가 있음

• 1분에 각 크레인이 박스 1개씩만 이동 가능

• 모든 박스를 옮기는 데 걸리는 최소 시간을 구하는 문제

접근법

• 가장 무거운 크레인부터 작업시키기

  • 이유 : 무거운 크레인만 들 수 있는 박스가 있기 때문

• 크레인 리스트와 박스 리스트를 내림차순 정렬

  • 둘 다 큰 것부터 매칭하면 관리가 훨씬 쉬워짐

• 반복문 시간 단위로 진행

  • 한 번의 루프가 1분을 의미

  • 각 크레인이 할 수 있는 박스를 “순서대로” 찾아서 옮김

  • 박스를 옮기면 그 박스는 리스트에서 제거

  • 박스를 못 옮긴 크레인은 그냥 다음 분으로 넘어감

코드

package Sutdy;

import java.util.*;

public class Beak1092_Greedy {
    public static void main(String[] args) {
        Scanner sc = new Scanner(System.in);

        int N = sc.nextInt();
        List<Integer> cranes = new ArrayList<>();
        for (int i = 0; i < N; i++) cranes.add(sc.nextInt());

        int M = sc.nextInt();
        List<Integer> boxes = new ArrayList<>();
        for (int i = 0; i < M; i++) boxes.add(sc.nextInt());

        // 크레인, 박스 모두 내림차순 정렬
        cranes.sort(Collections.reverseOrder());
        boxes.sort(Collections.reverseOrder());

        // 무거운 박스를 들 수 있는 크레인이 없으면 불가능
        if (boxes.get(0) > cranes.get(0)) {
            System.out.println(-1);
            return;
        }

        int time = 0;

        // 박스가 모두 없어질 때까지 반복
        while (!boxes.isEmpty()) {
            int boxIdx = 0;    // 현재 보고 있는 박스
            int craneIdx = 0;  // 현재 사용 중인 크레인

            // 1 분 동안 모든 크레인이 박스를 하나씩 옮김
            while (craneIdx < cranes.size()) {
                if (boxIdx >= boxes.size()) break;  // 박스 다 봤으면 종료

                if (cranes.get(craneIdx) >= boxes.get(boxIdx)) {
                    // 들 수 있는 박스 발견 → 바로 제거
                    boxes.remove(boxIdx);
                    craneIdx++;
                } else {
                    // 현재 크레인이 못 들면 더 가벼운 박스 탐색
                    boxIdx++;
                }
            }

            time++;
        }

        System.out.println(time);
    }
}

ArgumentResolver등록이 안되는 문제 발생

• 코드

  package org.example.expert.config;
  

import lombok.RequiredArgsConstructor; import org.example.expert.domain.common.interceptor.adminCheckInterceptor; import org.springframework.context.annotation.Configuration; import org.springframework.web.method.support.HandlerMethodArgumentResolver; import org.springframework.web.servlet.config.annotation.InterceptorRegistry; import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

import java.util.List;

@RequiredArgsConstructor public class WebConfig implements WebMvcConfigurer {

private final adminCheckInterceptor adminCheckInterceptor;

@Override
public void addArgumentResolvers(List<HandlerMethodArgumentResolver> resolvers) {
    resolvers.add(new AuthUserArgumentResolver());
}

@Override
public void addInterceptors(InterceptorRegistry registry) {
    registry.addInterceptor(adminCheckInterceptor)
            .addPathPatterns("/admin/users/*")
            .addPathPatterns("/admin/comments/*");
}

}

- 오류 코드를 봤을 때 resolver.add(A) A에 들어가는 값이 null 값처리가 된다는 문구를 확인하였고 resolver는 아무 문제가 없었다.

- 한참을 씨름을 하다가 Webconfig 클래스에 @Configuration 어노테이션이 빠져있는 것을 뒤늦게 확인..

- 붙여주니 정상적으로 잘 돌아갔다. 빠진 것이 없는지 위에서부터 순차적으로 보는 것이 디버깅보다 더 첫번째 인 것 같다.

### 트러블 슈팅(2)

- 인터셉터 구현 후 정상 실행이 되는지 테스트를 진행하였고, 로그가 안찍히는 것이 확인이 되었다.

- 튜터님의 세션 덕분에 필터를 거친 후 인터셉터로 넘어가기 때문에 필터에서 중복되는 것이 있기 때문에 인터셉터에서 확인이 불가능한 것인가 의심할 수 있게 되었다.

- jwtFilter에 아니나 다를까 동일한 로직이 실행되고 있었고 그 부분을 주석 처리를 해 다시 확인해 보았다.

- 그래도 나오지 않았다. 코드를 확인해보니 

```java
if(!UserRole.ADMIN.name().equals(role)) {
            response.sendError(HttpServletResponse.SC_FORBIDDEN, "권한이 없습니다");
            return false;
        }

• ??? 로그 코드에 아예없다. 실수인건지 까먹은건지 로그를 쓰지도 않고 로그를 확인하고 있었다.

log.info("접근이 차단되었습니다.");

• 이후 위 코드를 추가 후 정상 작동하는 것을 확인할 수 있었다..

• 코드는 문제가 없다. 문제는 나에게 있다.ㅎㅎ

트러블 슈팅(3)

• 도전과제 5Lv에 AOP를 구현하는 과정 속에 요구사항이 요청/응답의 바디값을 로그에 찍히게 하라는 사항이 있었다.

package org.example.expert.domain.common.AOP;

import com.fasterxml.jackson.databind.ObjectMapper;
import jakarta.servlet.http.HttpServletRequest;
import lombok.RequiredArgsConstructor;
import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;
import org.springframework.web.context.request.RequestContextHolder;
import org.springframework.web.context.request.ServletRequestAttributes;
import org.springframework.web.util.ContentCachingRequestWrapper;

import java.nio.charset.StandardCharsets;
import java.time.LocalDateTime;

@Aspect
@Component
@Slf4j
@RequiredArgsConstructor
public class LoggingAop {

    private final ObjectMapper objectMapper;
//    .controller.*AdminController.*

    //전 후로 로그를 찍어준다.
    @Around("execution(* org.example.expert.domain.*.controller.*AdminController.*(..))")
    public Object logApi(ProceedingJoinPoint joinPoint) throws Throwable {
        HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();
        HttpServletResponse response = ((ServletResponseAttributes) ResponseContextHolder.currentResponseAttributes()).getResponse();

        ContentCachingRequestWrapper requestWrapper = (ContentCachingRequestWrapper) request;

        Long userId = (Long) request.getAttribute("userId");
        LocalDateTime now = LocalDateTime.now();
        String requestURI = request.getRequestURI();
        String resquestBody = new String(requestWrapper.getContentAsByteArray(), StandardCharsets.UTF_8);
        log.info("userId = {},Time = {}, URL = {}, body = {}", userId, now, requestURI, resquestBody);

        Object result = joinPoint.proceed();

        log.info("body = {}", response);

        return result;
    }
}

• 최초 앞서 캐싱 필터를 통해 각 응답/요청을 적용 시키고, 적용 시킨 값을 로그에 찍히게 하려하였지만 응답의 바디 값이 계속 비어져 있는 것을 확인 할 수 있었다.

• 팀원분과 상의하면서 의논해보니 AOP는 Controller → Service → AOP 순으로 실행되기 때문에 저 시점에는 아직 응답이 읽히지 않을 때이기 때문이란 것을 알게 되었다.

• 따라서 응답값을 따로 빼주는 것이 아닌

  package org.example.expert.domain.common.AOP;
  

import com.fasterxml.jackson.databind.ObjectMapper; import jakarta.servlet.http.HttpServletRequest; import lombok.RequiredArgsConstructor; import lombok.extern.slf4j.Slf4j; import org.aspectj.lang.ProceedingJoinPoint; import org.aspectj.lang.annotation.Around; import org.aspectj.lang.annotation.Aspect; import org.springframework.stereotype.Component; import org.springframework.web.context.request.RequestContextHolder; import org.springframework.web.context.request.ServletRequestAttributes; import org.springframework.web.util.ContentCachingRequestWrapper;

import java.nio.charset.StandardCharsets; import java.time.LocalDateTime;

@Aspect @Component @Slf4j @RequiredArgsConstructor public class LoggingAop {

private final ObjectMapper objectMapper;

// .controller.AdminController.

//전 후로 로그를 찍어준다.
@Around("execution(* org.example.expert.domain.*.controller.*AdminController.*(..))")
public Object logApi(ProceedingJoinPoint joinPoint) throws Throwable {
    HttpServletRequest request = ((ServletRequestAttributes) RequestContextHolder.currentRequestAttributes()).getRequest();

    ContentCachingRequestWrapper requestWrapper = (ContentCachingRequestWrapper) request;

    Long userId = (Long) request.getAttribute("userId");
    LocalDateTime now = LocalDateTime.now();
    String requestURI = request.getRequestURI();
    String resquestBody = new String(requestWrapper.getContentAsByteArray(), StandardCharsets.UTF_8);
    log.info("userId = {},Time = {}, URL = {}, body = {}", userId, now, requestURI, resquestBody);

    Object result = joinPoint.proceed();

    log.info("body = {}", objectMapper.writeValueAsString(result));

    return result;
}

}

- 오브젝트매퍼를 활용해서 메서드의 결과값을 통해 응답값을 출력할 수 있도록 수정하니 잘 작동되는 것을 확인할 수 있었다.

- 팀원들에게 문제를 공유하고 같이 해결하니 금방할 수 있게 되었다.

• Admin API의 응답값이 void라서 로깅 시 Request/Response Body가 모두 null로 찍히는 문제

Admin API 중 다음 두 개는 void를 응답으로 사용하고 있었음.

• PATCH /admin/users/{id}

• DELETE /admin/comments/{id}

AOP에서 “요청/응답 바디 로깅"을 실시하고 있었지만 void 응답인 경우 로그에 “ResponseBody = null”만 찍혀서 의미 없는 로그가 생성되게 되었다.

해결 방안

의사결정 과정

• void 자체가 잘못된 것은 아니지만 운영 환경 로깅을 생각하면 의미 있는 응답을 내려주는 것이 좋다고 판단
• UserRole 변경 API는 변경 결과를 내려주는 것이 자연스러움
• Comment 삭제도 삭제된 commentId 정도는 내려주면 더 명확해짐

해결 과정

• 요청/응답 DTO를 새로 정의

• Admin API의 응답을 모두 DTO 기반으로 통일

• 로깅 AOP도 응답 바디가 null이 아닌 형태로 정상 출력되기 시작

해결 완료

회고

• 단순 기능 구현에 집중하다 보면 “운영 환경에서의 사용성”까지는 신경 못 쓰는 경우가 많은 것 같다.

• 명확한 응답을 내려주는 것은 개발자 경험에도 중요하고, AOP 로깅 퀄리티도 크게 향상시킨다.

전후 데이터 비교

Filter, Interceptor, AOP

사용 이유

• 모든 요청에 대해 로그를 남기고 싶다
• 로그인된 사용자만 특정 요청을 허용하고 싶다
• 요청이 들어올 때마다 요청 시간을 측정하고 싶다
• 특정 서비스 로직 실행 전후로 공통적인 검증이나 처리를 하고 싶다

다만 이 로직들을 모든 코드에 작성하게 된다면 가독성도 떨어지고 보수하기 굉장히 불편해진다.

특징

그림으로 이해하기

[사용자 요청]
   ↓
[Filter] ← 요청 시작 시 로그 출력
   ↓
[Interceptor] ← Controller 실행 전/후 로그 출력
   ↓
[AOP] ← Service 메서드 실행 전/후/예외 시점 로그 출력

Filter – 인증 토큰 처리 (ex. JWT)

• Authorization 헤더에 담긴 JWT 토큰 유효성 검사
• 모든 요청의 가장 앞단에서 작동해야한다, Spring DispatcherServlet 이전에 실행되어야 한다.
• 인증 실패 시 컨트롤러까지 가지 않도록 빠르게 차단 해야한다.

Interceptor – 로그인 여부 체크

• 로그인이 필요한 페이지 요청 시 세션 또는 인증 여부 검증
• 컨트롤러 실행 직전에 처리 가능하고, 사용자별 세션, 권한 확인 로직 작성에 용이하기 때문.
• 요청 URL 기반으로 유연하게 경로별 적용 가능하다.
  • 작성자 본인 확인 ex) 내가 작성한 글만 삭제 가능한 경우
  • 비즈니스 조건
    ex) 유료 회원만 접근

HandlerInterceptor

• Filter와 마찬가지로 처음부터 다 구현하는 것이 아닌 이미 구현되어 있는 HandlerInterceptor 를 활용한다.

• 메서드

  • preHandle : 컨트롤러 실행 전에 동작 (false 반환 시 흐름 중단 가능)

  • postHandle : 컨트롤러 실행 후, 뷰 렌더링 전

  • afterCompletion : 응답 완료 후, 예외 처리 포함

구현 방법

@Slf4j
@Component
@RequiredArgsConstructor
public class UserOwnerCheckInterceptor implements HandlerInterceptor {

    private final UserService userService;

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws IOException {

        // 1. 현재 로그인한 사용자 이름 꺼내기
        Authentication auth = SecurityContextHolder.getContext().getAuthentication();
        String currentUsername = auth.getName();

        // 2. 요청 URI에서 username 추출
        String path = request.getRequestURI();  // /api/user/{username}/email
        String decodedPath = URLDecoder.decode(path, StandardCharsets.UTF_8);

        String[] parts = decodedPath.split("/");
        String username = parts[parts.length - 2];

        // 3. 게시글 작성자와 비교
        if(!currentUsername.equals(username)) {
            log.warn("작성자 아님. 접근 거부");
            response.sendError(HttpServletResponse.SC_FORBIDDEN, "작성자만 수정할 수 있습니다.");
            return false;
        }

        return true;
    }
}

• 필요 어노테이션

  • Slf4j : 로깅을 사용할 시

  • Component : 빈 등록 필수

  • RequiredArgsConstructor : 속성의 생성자 생성을 위해 사용

• HandlerInterceptor을 해당 클래스를 구현한다.

• preHandle 메서드의 매개변수는 HttpServlet 요청/응답, Object handler 이고 예외를던 져준다.

• 해당 리퀘스트를 통해 내부 사용자의 정보를 꺼내 원하는 조건문을 만들어 메서드를 완성 시킨다.

• 완성된 인터셉터를 WebConfig에 등록을 시켜준다.

  @Configuration
  @RequiredArgsConstructor
  public class WebMvcConfig implements WebMvcConfigurer {
  
    private final UserOwnerCheckInterceptor userOwnerCheckInterceptor;
  
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(userOwnerCheckInterceptor)
            .addPathPatterns("/api/user/**/email");
    }
  }

  저번에 다뤘던 내용처럼 빈으로 등록만 해주는 것이 아닌 인터셉터를 추가를 해주어야만 인식을 하기 때문에 필수 과정이다.

AOP – 실행 시간 측정 / 로깅

• Service 계층에서 비즈니스 로직 실행 시간 측정이 필요할 때.
• 특정 메서드 호출 전후에만 부가 기능을 넣고 싶을 때 유리
• 핵심 로직은 건드리지 않고 공통 처리만 분리 가능
• 다양한 메서드에 어노테이션으로 간편하게 확장 가능

그림으로 이해하기

• 다음과 같이 도메인별 서비스 단에 전부 로깅을 추가하기에는 유지보수하기 매우 부적절 하므로 AOP를 통해 일괄적용함에 따라 유지보수성이 굉장히 좋아짐을 확인할 수 있다.

용어 정리

• Aspect : 공통 관심사를 담는 모듈 (ex. 로깅, 트랜잭션, 권한 체크)
• JoinPoint : 메서드 실행 지점
• Advice : 실행 시점에 따라 작동하는 AOP 로직 (@Before, @After, @Around)
• Pointcut : 어떤 JoinPoint에 Advice를 적용할지 정의 (표현식 기반)
• Weaving : Advice를 적용하는 과정 (직접 Weaving을 다룰 일은 없다. 스프링이 해줌)

작성 꿀팁

• 어떤 것을
  • PointCut 을 통해서 대상을 지정해준다.
• 언제
  • Advice를 통해서 실행되는 시점을 지정해준다.
• 어떻게
  • Aspect에 정의한 메서드를 통해서 어떻게 할 것인지 지정해준다.

주 어노테이션

• @Aspect : Aspect 클래스임을 선언
• @Around : 메서드 실행 전후 제어 (가장 유연)
• @Before : 메서드 실행 전에 수행
• @AfterReturning : 정상 반환 후 수행
• @AfterThrowing : 예외 발생 시 수행
• @After : 정상/예외 관계없이 실행 후 수행

활용법

• 로깅 : 모든 서비스 실행 시 로그 기록
• 트랜잭션 : 메서드 단위 트랜잭션 처리
• 권한 검사 : 관리자 권한 체크
• 예외 처리 : 공통 에러 메시지 처리
• 실행 시간 측정 : 성능 모니터링

구현 방법

package org.example.nbcam_addvanced_1.common.aspect;

import lombok.extern.slf4j.Slf4j;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.springframework.stereotype.Component;

@Aspect
@Component
@Slf4j
public class TimeCheckAop {

    @Around("execution(* org.example.nbcam_addvanced_1.user.service..*(..))")
    public Object executionTime(ProceedingJoinPoint joinPoint) throws Throwable {

        long start = System.currentTimeMillis();

        Object result = joinPoint.proceed(); // 실제 메서드 실행 -> Filter에서 doFilter 와 비슷함.

        long end = System.currentTimeMillis();
        log.info("[AOP] {} 실행됨 in {}ms" , joinPoint.getSignature() , end - start);

        return result;
    }
}

• @Aspect : AOP를 사용할 클래스다! 지정

• @Component : 마찬가지로 빈 등록 필수

• Slf4j : 로깅을 사용할 경우 필수

• @Around("execution(* org.example.nbcam_addvanced_1.user.service..*(..))")

  • 어노테이션("") 안에는 내가 적용시킬 메서드들이 위치한 파일의 경로를 입력해주면 된다.
  • * = 와일드카드 모든~ 이라는 뜻

• JoinPoint를 매개변수로 받아준다.

• System.currentTimeMillis(); = 현재 시간을 가져오는 기능

마무리

과제를 진행하게 되면서 테스트코드라는 것을 올바르게 작동하도록 수정하는 작업을 하였는데, 틀린 것을 찾고 수정하는 것은 매우 쉬웠지만, 저 코드를 테스트할 코드를 작성하는 것이 굉장히 어려울 것이라고 생각이 들어 좀처럼 손이 가지 않았다.. 튜터님께서 말하신 만큼 중요한 요소라 꼭 도전은 해야겠다만, 지금은 조금 버거워 후에 미뤄볼까 한다.. 절대 귀찮아서가 아니다ㅎㅎ..

또한 배운것을 토대로 인터셉터와 AOP를 구현하는데 손쉽게 따라할 수 있었지만 데이터를 뽑아와 새로운 로직을 생성하는 부분이 재밌으면서도 골이 조금 아팠다. 더 열심히 해야겠당