[Refactor] QueryDSL 조회 성능 및 코드 구조 리팩토링

오늘 한 일

오늘은 HubRoute 조회 기능을 구현한 뒤 코드 구조를 개선하고 유지보수성을 높이는 리팩토링을 진행하였다.

특히 Repository 계층의 의존성 개선, QueryDSL 정렬 화이트리스트 적용, 트랜잭션 이후 메모리 Graph 갱신 구조를 중심으로 수정하였다.

---

Repository 계층 의존성 개선

기존에는 Repository가 Application 계층의 DTO를 직접 전달받고 있었다.

search(HubRouteSearchCondition condition, Pageable pageable)

Repository는 Domain 계층에 위치하므로 Application DTO를 의존하지 않는 것이 적절하다고 판단하였다.

따라서 Service 계층에서 SearchCondition을 필요한 값으로 분리하여 Repository에 전달하도록 변경하였다.

search(
    String keyword,
    UUID fromHubId,
    UUID toHubId,
    Pageable pageable
)

이를 통해 계층 간 의존성을 제거하고 Domain 계층의 독립성을 높일 수 있었다.

---

QueryDSL 정렬 화이트리스트 적용

기존에는 Pageable의 Sort를 그대로 사용하고 있었다.

이 경우 API에서 의도하지 않은 컬럼으로 정렬 요청이 들어올 수 있기 때문에 허용된 컬럼만 정렬할 수 있도록 화이트리스트를 적용하였다.

Hub

• createdAt
• name

HubRoute

• createdAt
• distance
• duration

허용되지 않은 컬럼으로 요청하는 경우

INVALID_SORT_PROPERTY

예외를 반환하도록 구현하였다.

화이트리스트를 적용하면서 API 명세와 실제 구현을 일치시킬 수 있었고, 잘못된 정렬 요청도 방지할 수 있었다.

---

Soft Delete 데이터 제외

조회 기능과 메모리 Graph 생성 시 모두 삭제되지 않은 데이터만 조회하도록 수정하였다.

deletedAt.isNull()

조건을 추가하여 Soft Delete 된 허브 연결이 조회되거나 Graph에 포함되지 않도록 개선하였다.

---

Graph 갱신 구조 개선

기존에는 HubRoute 저장 이후 바로 Graph를 갱신하였다.

이를 트랜잭션이 정상적으로 Commit된 이후에만 Graph를 다시 생성하도록 변경하였다.

구조는 다음과 같다.

HubRoute 저장
        ↓
ApplicationEventPublisher
        ↓
@TransactionalEventListener(AFTER_COMMIT)
        ↓
HubGraphManager.reloadGraph()

이 구조를 적용하면서 DB에는 저장되지 않았지만 메모리 Graph만 변경되는 상황을 방지할 수 있게 되었다.

---

Controller 테스트 개선

Controller 테스트에서 DTO만 생성하는 방식이 아니라 실제 HTTP 요청을 수행하도록 수정하였다.

MockMvc를 이용하여

• 요청
• 응답 상태
• JSON 응답

까지 함께 검증하도록 변경하여 실제 Controller 동작을 테스트할 수 있도록 개선하였다.

---

느낀 점

오늘은 기능을 추가하기보다는 기존 코드를 더 유지보수하기 쉬운 구조로 개선하는 작업에 집중하였다.

특히 QueryDSL에서 정렬 화이트리스트를 적용하는 방식은 API 명세와 구현을 일치시키면서도 예기치 않은 정렬 요청을 방지할 수 있는 방법이라는 점을 배웠다.

또한 Repository 계층이 Application DTO를 의존하지 않도록 수정하면서 계층 간 책임을 다시 한번 점검할 수 있었고, @TransactionalEventListener(AFTER_COMMIT)를 적용하여 트랜잭션 이후 후처리를 안전하게 수행하는 방법도 경험할 수 있었다.