🎄메리크리스마스🎄

기존 JPA로만 작업하던 프로젝트에서 QueryDSL을 추가로 적용하면서

'어떤 걸 두고, 어떤 걸 QueryDSL로 옮겨야 할까?'에 대해서 찾아봤다.

✅ QueryDSL로 옮기는 기준

1. 동적 조건이 있는 조회
   ➡️ QueryDSL 필수!! JPQL @Query는 조건 조합이 늘어날수록 문자열 이어 붙이기 지옥이 됨.
2. exists, 서브쿼리, 복잡한 OR 조건
   ➡️ QueryDSL이 안전!! 문자열 JPQL은 실수나 리팩토링에 취약
3. 페이징 + 정렬 + count 분리 필요
   ➡️ Page / Slice 구현: QueryDSL이 구조적으로 유리
4. 다중 테이블 조인 DTO 프로젝션
   ➡️ QueryDSL이 컴파일 타임 타입 체크: JPQL 문자열은 필드명 오타가 런타임 에러
5. 검색 조건이 계속 늘어날 가능성 있음
   ➡️ 초기에 단순해 보여도 앞으로 필터 추가 요청 예상되면 QueryDSL

❌ 굳이 안 옮겨도 되는 경우

1. 단순 CRUD (ex. `findById`, `deleteById`, `existsById`...)
   ➡️ Spring Data 기본 메서드로 충분
2. 단순 벌크 수정/삭제 (ex. `@Modifying @Query("delete ... where id = :id")`)
   ➡️ 그대로 둬도 됨 (오히려 QueryDSL 벌크는 flush/clear 직접 관리 필요)
3. DB 전용 기능 (CTE / window function)
   ➡️ QueryDSL-JPA는 표현 못함. JDBC / native SQL 유지가 더 낫다.
4. 절대 안 변할 정적 쿼리 (ex. “활성 Y 데이터 전부 조회”)
   ➡️ `@Query` 하나로 끝나고 끝까지 안 변하면 유지

찾아본 결과 이렇게 정리했다.

이대로 팀 개발 가이드 문서나, 개인 프로젝트 시 참고하면 좋을 것 같다!

`gradle dependencies`에는 api 선언과 implementation 선언이 존재한다.

특히 멀티모듈 구조인 프로젝트의 경우 두 가지를 함께 쓰는 경우가 많기 때문에 정리를 해두려고 한다!

🐘 api, implementation

dependencies {
	api 'org.springframework.boot:spring-boot-starter-data-jpa'
	implementation 'org.springframework.boot:spring-boot-starter-security'
}

api 선언을 사용하면 선언된 라이브러리는 해당 모듈을 의존하는 모듈의 컴파일, 런타임의 클래스패스에 모두 포함된다.

※ 예시의 spring-boot-starter-data-jpa는 api 선언이기 때문에, 이 모듈을 의존하는 다른 모듈들도 해당 라이브러리를 사용할 수 있게 된다.

하지만 api 선언을 남용하게 되면 모듈간 결합이 증가하게 되고, 변경 전파가 커진다.

implementation 선언은 현재 모듈 내에서만 컴파일, 런타임에 사용되고 외부에는 공개되지 않는다.

※ 예시의 spring-boot-starter-security는 이 모듈을 의존하는 다른 모듈들에서 사용할 수 없고, 각각 선언을 다시 해줘야 한다.

🚩 모듈 선언하기

`core`모듈과 `service`모듈이 있고, `service`모듈에서 `core`모듈을 가져다 쓰려고 한다.

// core
plugins {
	id 'java-library'
}
dependencies {
	api 'org.springframework.boot:spring-boot-starter-data-jpa'
	implementation 'org.springframework.boot:spring-boot-starter-security'
}

// service
dependencies {
	implementation project(":core")
	implementation 'org.springframework.boot:spring-boot-starter-security'
}

core 모듈에서는 `java-library` 플러그인도 선언을 해줘야 한다.

이후 service 모듈에서 `implementation project`를 통해 core에 있는 api 선언 라이브러리들을 가져올 수 있다.

`spring-boot-starter-security`는 core에서 implementation으로 선언되었기 때문에

service 모듈에서 사용하려면 core 모듈에서 api 선언으로 변경하거나, service 모듈에서 재선언 해야 한다.

`v-data-table`에서 `:items="itemList"`로 전체 데이터를 넘겼는데

`#body` 슬롯에서 `items.length`를 찍어보면 10개만 나오는 현상이 생긴다.

✨ 원인: v-data-table 내부 페이징 처리

`v-data-table`은 `:items`로 전달된 원본 전체 데이터를 그대로 쓰지 않고,

내부에서 페이징/정렬/필터 처리가 자동으로 수행된다.

• 페이징 (page / items-per-page)
• 정렬 (sort)
• 필터 (search)

이 과정을 거친 뒤 현재 화면에 표시할 데이터만 만들어 렌더링된다.

`#body` 슬롯을 사용하지 않고 기본 렌더링 시에도 이미 내부 처리된 결과가 넘어온다.

따라서 원본이 30개여도 `items-per-page` 기본값(10) 때문에

현재 페이지에 해당하는 10개만 `items`로 전달된다.

`v-data-table`에 `items-per-page`를 지정해주는 방법도 있지만, 고정된 값이기 때문에

보통 페이징 처리가 된 값을 `items-per-page`에 적용시켜줘서 사용한다.

정렬해둔 `List`를 ` Collectors.toMap()`으로 중복 제거 후 다시 `List`로 만들었더니 순서가 엉키는 문제가 발생했다.

구글링 한 결론은 `Collectors.toMap()`은 기본적으로 `HashMap`을 사용하기 때문에 순서를 잃어버린다.

`LinkedHashMap::new`로 수집하면 순서가 그대로 유지된다.

💥 기존에 사용했던 코드

List<User> userList = // ID 기준 오름차순 정렬되어 있다고 가정

List<User> result = userList.stream()
    .collect(Collectors.collectingAndThen(
        Collectors.toMap(User::uniqueKey, Function.identity(), (exist, repl) -> exist),
        map -> new ArrayList<>(map.values())
    ));

System.out.println(result.stream().map(User::getId).collect(Collectors.toList()));

• 기대: 원본 `userList` 순서 (1, 2, 3, ... , 10, 12, 13, ...)
• 실제: ID 순서가 틀어지거나, 경우에 따라 누락/중복이 발생

🤔 순서가 깨지는 이유

`Collectors.toMap()` ➡ `new HashMap<>()` 사용 ➡ `values()`를 꺼낼 때 내부 배열 순서를 새로 정렬해서 삽입 순서 유지 실패

※ Java 8 이후에도 기본 Map은 여전히 `HashMap`이라고 한다.

✨ 해결 방법: `LinkedHashMap` 지정

List<User> result = userList.stream()
    .collect(Collectors.collectingAndThen(
        Collectors.toMap(
            User::uniqueKey,                // key mapper
            Function.identity(),            // value mapper
            (exist, repl) -> exist,         // 중복 key 정책 : 기존값 유지
            LinkedHashMap::new              // ⭐️ 순서 유지 Map 생성
        ),
        map -> new ArrayList<>(map.values())
    ));

• 실행 결과: 원본 `userList` 순서 (1, 2, 3, ... , 10, 11, 12, ...)

✅ 현상 요약

Vue CLI 프로젝트에서 `src/assets/images/image.png`처럼 이미지를 넣고 빌드하면, `/img/image.[hash].png`로 경로가 변경된다. 그리고 `src/assets/images/`에 있는 몇가지 파일들은 `/img/`경로 아래에 존재하지 않는다.

왜 `images`폴더에 넣었는데 `img`로 바뀌는지, 다른 파일들은 왜 없는지 의아할 수 있다.

결론부터 말하자면, Webpack + Vue CLI가 자동적으로 정적 자산을 최적화하면서 경로를 재구성하고 파일 크기에 따라 처리 방법이 다르기 때문이다.

💡 경로가 바뀌는 이유

Vue CLI는 내부적으로 Webpack을 사용하며, 이미지 파일을 처리할 때 아래와 같은 기준으로 처리한다.

1. 8KB 이하의 작은 이미지 → Base64 인라인 처리
   
   • `base64`로 변환되어 JS 번들 안에 인라인으로 삽입
   • 이 경우 이미지 파일은 빌드 결과물에 생성되지 않음
   • 개발자도구(Network탭)에서 `data:image/png;base64,...` 형태로 확인 가능
2. 8KB 초과 이미지 → `/img/` 하위 폴더로 출력
   • `file-loader`를 통해 복사되며, 해시가 붙은 이름으로 `/img` 폴더에 저장됨
   • ex: `src/assets/images/image.png` → `/img/image.8d3f2c12.png`

즉, ` src/assets/images/`라고 해도 빌드 시 Webpack이 알아서 `img/`, `css/`, `js/` 등의 폴더로 정리해서 출력하는 구조다.

🪄 경로 변경 제어 방법

1. `public/` 폴더 활용
   `public/images/image.png`에 넣으면 빌드 시 그대로 `images/image.png` 경로로 유지됨
2. 인라인 처리 방지 (`base64`로 들어가지 않게) or 제한 크기 변경
   아래처럼 처리하면 모든 이미지 or 제한 초과 이미지  모두 `/img/` 폴더에 파일로 생성됨

// vue.config.js
module.exports = {
  chainWebpack: config => {
    config.module
      .rule('images')
      	// 제한 크기 변경 시
      	.set('parser', {
          dataUrlCondition: {
            maxSize: 4 * 1024 // 4KB
          }
        })
      .use('url-loader')
      .tap(options => {
        options.limit = 0; // 용량과 무관하게 모두 파일로 처리
        return options;
      });
  }
};

🤔 Stream으로 수동 페이징?

시작하기에 앞서, 보통 JPA에서 페이징이 필요하면 `Page<T>` 타입으로 리턴받는 게 가장 깔끔하다.

Page<Entity> res = repository.findByStatus("PENDING", pageable);

이 방식이 가장 이상적인 형태고, 성능상으로도 효율적이다.

하지만 오늘 나의 상황에서는 stream으로 필터링 후, `PageImpl`로 수동 페이징을 하는게 나을 때가 존재한다.

1. 사용자의 필터 조건이 많고
2. 그 중 일부는 null일 수도 있고
3. 일부는 포함 검색이고
4. 날짜 범위 조건까지 존재했다.

이 조건들을 모두 JPQL이나 @Query로 짜는 건 복잡도도 높고 유지보수의 지옥이 될 것 같았다.

그래서 `findAll()`이나 간단한 조건을 걸어서 repository에서 조회 후 `stream().filter(...)`로 필터링을 했다.

물론 데이터 수가 적을때만 해당한다.

📌 전체 코드 예시

// 1. 데이터 조회
List<Entity> entityList = repository.findById(id);

// 2. 조건 필터링 + 정렬
List<Entity> filteredEntityList = entityList.stream()
	.filter(entity -> entity.getStatus().equals(dto.getStatus()))
    .filter(entity -> entity.getCont().getContNm().toLowerCase().contains(dto.getSearchNm().toLowerCase())
    .filter(entity -> dto.getTypeCodeList().contains(entity.getTypeCode())
    .sorted(Comparator.comparing(Entity::getCrtTime).reversed())
    .toList();

// 3. Pageable 객체 생성 (pageable은 F/E에서 넘어옴)
Pageable page = PageRequest.of(pageable.getPageNumber(), pageable.getPageSize());

// 4. 페이징 처리
int start = (int) page.getOffset();
int end = Math.min((start + page.getPageSize()), filteredEntityList.size());

Page<Entity> entityPage = new PageImpl<>(
	filteredEntityList.subList(start, end),
    page,
    filteredEntityList.size()
);

💥 .filter(...) 조건이 많아질 경우 리팩토링

Jave Stream의 `filter()`은 조건이 많아질수록 가독성이 떨어진다.

이를 위해 조건을 별도 메서드로 분리하는 것이 좋다.

List<Entity> filteredEntityList = entityList.stream()
    .filter(entity -> filterSearchNm(entity, dto.getSearchNm()))
    .filter(entity -> filterReqTypeCode(entity, dto.getReqTypeCodeList()))
    .sorted(Comparator.comparing(Entity::getCrtTime).reversed())
    .toList();

// 조건 분리 메서드
private boolean filterSearchNm(Entity entity, String searchNm) {
	if (StringUtils.isEmpty(searchNm)) return true;
    
    String keyword = searchNm.toLowerCase();
    return entity.getCont().getContNm().toLowerCase().contains(keyword) ||
    	   entity.getComp().getCompNm().toLowerCase().contains(keyword);
}

private boolean filterReqTypeCode(Entity entity, List<String> codeList) {
	return Collectionutils.isEmpty(codeList) ||
    	   codeList.contains(entity.getReqTypeCode());
}

🧸 Pageable

Spring Data JPA에서 데이터 조회 시 페이징 처리를 지원하는 인터페이스이다.

`PageRequest.of(페이지번호, 페이지크기)`로 간단하게 사용할 수 있다.

⬇️ 정렬까지 함께 사용하기

Pageable pageable = PageRequest.of(0, 10, Sort.by(Sort.Direction.DESC, "createdDate"));

• `0`: 첫 페이지 (0부터 시작)
• `10`: 한 페이지에 10개씩
• `"createDate"`: 정렬 기준 컬럼
• `DESC`: 내림차순

🎡 Repository 메서드에서 사용

Page<Entity> findAll(Pageable pageable);

// Specification과 함께 사용
Page<Entity> findAll(Specification<Entity> spec, Pageable pageable);

🎡 Controller에서 사용

@GetMapping("/list")
public Page<ResponseDto> getList(@RequestParam int page,
                                 @RequestParam int size) {
    Pageable pageable = PageRequest.of(page, size, Sort.by(Sort.Direction.DESC, "createdDate"));
    return repository.findAll(spec, pageable).map(entity -> toDto(entity));
}

🪄 Pageable(Sort 포함) 사용 시 콘솔 출력 쿼리

    order by
        mer1_0.[CREATE_DATE] desc 
    offset
        ? rows 
    fetch
        first ? rows only

문제

Brazilian E-Commerce Public Dataset by Olist 데이터베이스는 브라질의 이커머스 웹사이트인 Olist Store의 판매 데이터 입니다. 그 중 `olist_orders_dataset` 테이블에는 주문 ID, 고객 ID, 주문 상태, 구매 시각 등 주문 내역 데이터가 들어있습니다. Olist의 주문부터 배송까지 프로세스는 다음 단계를 통해 이루어지고, 각 단계마다 시각을 기록하고 있습니다.

1. 고객의 구매
   • `order_purchase_timestamp` 컬럼에 구매 시점이 저장됨
2. 판매자가 주문을 승인
   • `order_approved_at` 컬럼에 승인 시점이 저장됨
3. 택배사에 도착하여 배송 시작
   • `order_delivered_carrier_date` 컬럼에 배송 시작 시점이 저장됨
4. 배송 완료
   • `order_delivered_customer_date` 컬럼에 배송 완료 시점이 저장됨

추가로 `order_estimated_delivery_date` 컬럼에는 주문 시점에 계산한 배송 예정 시각이 저장되어 있습니다. 예를 들어, 컬럼에 값이 ‘2017-02-24 00:00:00’로 들어있는 경우, 배송을 2017년 2월 24일 자정까지 완료하겠다는 의미를 담고 있습니다.

2017년 1월 한 달 동안 발생한 주문의 배송 예측이 정확했는지 분석을 하려고 합니다. 고객의 구매 일자별로 배송 예정 시각 안에 고객에게 도착한 주문과, 배송 예정 시각이 지나서 고객에게 도착한 주문을 각각 집계하는 쿼리를 작성해주세요. 배송 완료 또는 배송 예정 시각 데이터가 없는 경우는 계산에서 제외합니다. 계산 결과는 구매 날짜를 기준으로 오름차순 정렬되어야 하고, 아래 컬럼을 포함해야 합니다.

• `purchase_date` - 구매 날짜 (예: 2017-01-01)
• `success` - 배송 예정 시각 안에 고객에게 도착한 주문 수
• `fail` - 배송 예정 시각이 지나 고객에게 도착한 주문 수

결과 데이터 예시

• 2017년 1월 6일 구매된 주문은 총 4건이고 모두 배송 예정일 안에 배송 완료됨
• 2017년 1월 7일 구매된 주문은 총 4건이고 그 중 3건은 배송 예정일 안에 배송 완료되었으나, 1건은 배송 예정일 이후에 배송 완료됨

제출

SELECT DATE(order_purchase_timestamp) AS 'purchase_date'
     , SUM(IIF(order_estimated_delivery_date >= order_delivered_customer_date, 1, 0)) AS 'success'
     , SUM(IIF(order_estimated_delivery_date < order_delivered_customer_date, 1, 0)) AS 'fail'
FROM olist_orders_dataset
WHERE order_delivered_customer_date IS NOT NULL
  AND order_estimated_delivery_date IS NOT NULL
  AND purchase_date LIKE '2017-01%'
GROUP BY purchase_date
ORDER BY purchase_date
;