🎱 Querydsl에서 Entity를 DTO로 자동으로 변환하는 방법과 @QueryProjection의 의존성을 제거하는 방법에 대한 고찰…

🖤 Intro…

최근에 Querydsl에 대한 스터디를 진행하면서 Querydsl의 아주 강력한 기능 중 하나인 DTO Projections에 대해서 간략하게 소개했다. 특히 이 중 @QueryProjection이 매우 편리한 기능을 제공하기에 이걸 위주로 스터디를 진행했는데, 문득 의문이 생겼다.

🫨 “이걸 사용하면 QueryDSL에 의존성이 생긴다”는 문제점이 있는건 알겠는데, 그렇다면 문제점이 과연 이거 하나일까?

이렇게 간단한 방식으로 사용할 수 있는게 있다면, 굳이 Projections.bean이라는 것은 왜 존재하는 것일까?

API 명세에 들어가는 Request, Response 같은 경우는 외부 요소에 의한 변동이 없어야 한다는 것으로 알고 있는데, 그렇다면 대부분이 이 Request, Response에 도메인 영역인 Entity를 직접 노출하지 않기 위해서 DTO로 이를 변환해서 사용하는 것으로 알고 있는데, 이 DTO에 QueryDSL의존성이 생기는 것이 과연 “안전한”것인가? 오늘은 이 부분에 대한 의문을 해소해보자!

🩶 Start

우선, 이 부분을 알아보기 위해 “프로젝션”의 개념을 먼저 알아보도록 하자. 프로젝션이란, select로 대상을 지정하는 것을 말한다. QueryDSL은 이 Projections에서, Entity를 DTO로 쉽게 변환할 수 있도록 하는 획기적인 방식을 몇가지 제공한다. 이에 대해 먼저 알아보자.

QueryDSL에서 프로젝션 결과를 반환하는 방법

QueryDSL에서 프로젝션 결과를 반환하는 방법은 크게 DTO로 조회하는 것, 그리고 튜플로 조회하는 것 두 가지가 있다. 튜플은 QueryDSL에서 제공하는 Tuple 인터페이스를 이용하는 것이다.

/*
프로젝션 결과 반환 - 여러개 (튜플)

- 프로젝션 결과가 여러개일때, 튜플로 반환
- 튜플의 경우, QueryDSL에서 제공하는 Tuple 인터페이스를 사용해야 하므로 QueryDSL에 의존적이라는 단점이 존재한다.
 */
@Test
void 프로젝션_튜플() throws Exception {
    //given

    //when
    List<Tuple> result = queryFactory
            .select(member.username, member.age) // member.username과 member.age를 선택
            .from(member)
            .fetch();

    //then
    for (Tuple tuple : result) {
        String username = tuple.get(member.username);
        Integer age = tuple.get(member.age);
        System.out.println("username = " + username + ", age = " + age);
    }
}

이것 역시 QueryDSL에서 제공하는 기능을 사용하는 것이므로, 이렇게 의존성을 가진 객체가 repository 밖으로 새어 나가는 것은 좋은 설계가 아니다. 여기서 막간을 이용해서 왜 기술 의존성을 가진 객체가 repository 밖으로 새어 나가는 것이 좋지 않은지를 알아보도록 하자.

왜 의존성을 가진 객체가 repository 밖으로 새어 나가는 것이 좋지 않은걸까?

이는 레포지토리 경계를 넘어서 의존성을 가진 객체(즉, 프레임 워크나 라이브러리에 의존하는 순수한 상태가 아닌 객체를 의미한다.)가 서비스 단으로 새어나가면, 계층간 결합이 커지고 교체, 테스트, 리팩터링 비용이 폭증하기 때문이다.

즉, 사실 SOLID 원칙을 준수하기 위해서는 결합도는 낮추고 응집성은 강하게 하는 것이 매우 중요한데, 이렇게 하면 “강한 결합”이 된다는 문제점이 존재한다. 또한, 순수한 환경에서 진행해야 하는 단위 테스트 역시 이렇게 의존성을 가질 경우 상당한 제약을 받는다.

QueryDSL에서 프로젝션 결과를 DTO로 반환하는 방법

그렇다면 DTO로 직접 반환하는 방법은 어떨까? QueryDSL은 프로젝션 결과를 DTO로 반환하기 위해 다음의 방법을 정의하고 있다.

1. Projections.bean
2. Projections.fields
3. Projections.constructor
4. @QueryProjection

하나씩 살펴보자.

Projections.bean

setter 메서드를 기반으로 동작하는 방식이다. 즉, Entity의 모든 필드를 DTO에 setter를 이용해서 주입하는 방식이다. 따라서 이 방식을 이용할 시 DTO의 모든 필드에 Setter가 필요하다. 그래서 @Setter를 같이 활용해야 한다. 마치 MyBatis에서 매핑하는 방식과 유사하다. (MyBatis역시 Setter 기반으로 동작하므로..)

//when
//프로퍼티 접근 - Setter
List<MemberDTO> result1 = queryFactory
        .select(Projections.bean(MemberDTO.class,
                member.username,
                member.age))
        .from(member)
        .fetch();

그러나, Setter를 기반으로 동작한다는 것 자체가 이 방식의 가장 큰 단점이다. Setter를 사용할 경우, 데이터의 변경에 취약하기 때문이다. 막간을 이용해서 왜 Setter를 사용하지 않는게 좋은지 알아보도록 하자.

왜 Setter를 지양하는 것이 좋을까?

Setter 기반이라는 것은, 결국 객체의 상태를 외부에서 바꿀 수 있게 되는 것이라는 것을 의미한다. 즉, Setter를 사용하면 누가, 어디서든지 값을 바꿀 수 있다. 생성자(빌더)를 이용하되, 접근 제한자를 private, protected등으로 설정하면 외부 임의 생성을 막을 수 있는것에 반해, Setter는 이런 보조 기능을 붙일 수 없어서 매우 취약하다. 예를 들어, 외부에서 은행 계좌에 접근해서 setBalance(0)등으로 설정을 해버린다면…? 생각만해도 등골이 오싹한 경험을 할 것이다…

Projections.fields

이 방식은 필드에 직접 접근해서 값을 주입하여, DTO로 내보내는 방식이다.

//필드 직접 접근 - 필드에 직접 접근하여 값을 설정
List<MemberDTO> result2 = queryFactory
        .select(Projections.fields(MemberDTO.class,
                member.username,
                member.age))
        .from(member)
        .fetch();

단, type이 다를 경우 매칭되지 않으며, dto에서 설정한 별칭과 엔티티의 필드명이 다를 경우, as등을 이용해서 추가적으로 맞춰줘야 한다는 단점이 존재한다.

member.username.as("name")

또한 결정적으로, 컴파일 시점에 에러를 찾을 수가 없다!!! 런타임 에러만 발생한다. 이는 컴파일러가 dto에 해당 필드들이 있는지를 전혀 모르기 때문에, 런타임에 이를 매칭하고자 시도하기 때문이다. 개인적으로 나는 컴파일 에러를 매우 사랑하고….런타임 에러를 매우 싫어한다….디버깅이 어렵다 그래서 이 단점이 좀 크게 다가왔다.

Projections.constructors

//생성자 사용 - 생성자를 통해 값을 설정
List<MemberDTO> result3 = queryFactory
        .select(Projections.constructor(MemberDTO.class,
                member.username,
                member.age))
        .from(member)
        .fetch();

생성자로 값을 설정해서 DTO로 내보내는 방식이다. 즉, 생성자 기반으로 데이터를 주입하는 것인데 생성자로 동작하기 때문에 위에서 말했던 것처럼, setter와 다르게 객체의 불변성을 가져갈 수 있다는 장점이 존재한다.

그러나, 값을 넘길때 생성자와 필드의 순서를 반드시 일치시켜야만 한다는 단점이 있기에, 파라미터가 너무 많으면 바인딩 에러가 발생할 확률이 매우 크다 또한, 이 Projections.constructors 역시 런타임 시점에 오류가 발생하는 형식이라, 컴파일 에러를 잡을 수 없다는 단점이 존재한다.

@QueryProjection

어노테이션을 이용해서 프로젝션을 처리하는 방식이다. 이 어노테이션을 적용할 DTO의 생성자에 붙여주면, QDTO라는 것을 생성하는데 이를 활용하면 생성자 방식으로 손쉽게 엔티티 > DTO 변환이 가능하다.

/*
프로젝션 결과 반환 - @QueryProjection

- 이걸 사용할 경우, DTO도 Q파일로 생성해서 쿼리 날릴때도 활용이 가능하다!
- 다만, DTO에 @QueryProjection 어노테이션을 붙여야 한다. 즉, QueryDSL에 의존해야 한다는 단점이 있음.
 */
@Test
void 프로젝션_QueryProjection() throws Exception {
    //given

    //when
    List<MemberDTO> result = queryFactory
            .select(new QMemberDTO(member.username, member.age)) // QMemberDTO를 사용하여 DTO 생성
            .from(member)
            .fetch();

    //distinct 사용법
    List<String> resultDist = queryFactory
            .select(member.username)
            .distinct() // 중복 제거
            .from(member)
            .fetch();

    //then

}

이 방식의 장점은 “컴파일 시점에 에러가 발생한다는 것”이다!!! 이는 Querydsl이 애노테이션을 통해 Q클래스 (QDTO)를 생성해 주기 때문에, apt가 이를 호출해서 생성하는 과정에서 앞단에서 먼저 에러를 내주기 때문이다. 이렇게 편리한 기능에는 단점이 존재하기 마련이다.

우리는 앞에서 외부에 기술 종속적인 객체를 노출하면 안된다는 것을 말했다 그러나 @QueryProjection은 특히 Q가 붙은 DTO를 이용해서 변환한다는 점에서 이에 완벽히 위배된다. (사실 다른 Projections 역시 마찬가지다….) 그래서 우리는 모든 레이어에서 이 QDTO를 사용하도록 하는 이 패턴에서 벗어나는 방식을 고안하여 이를 활용해야 한다.

그렇다면 어떻게 @QueryProjection을 비종속적으로 사용할 수 있나?

우선 @QueryProjection이걸 종속적으로 사용한 내 리팩터링 전 코드를 한 번 살펴보자.

@Repository
@RequiredArgsConstructor //생성자 주입
public class ShortsQueryRepositoryImpl implements ShortsQueryRepository {

    private final JPAQueryFactory query; //config 파일을 통해 바로 주입

    @Override
    public List<ShortsResponseDto> searchShorts(String nickname, String keyword) {
        return query
                .select(
                        new QShortsResponseDto(
                        shorts.id,
                        shorts.shortsName,
                        shorts.thumbnail
                ))
                .from(shorts)
                .where(
                        nicknameEq(nickname),
                        keywordContains(keyword)
                ).orderBy(shorts.shortsName.desc())
                .fetch();
    }

    // --- 조건 메서드 (동적 쿼리) ---
    // 조건 메서드끼리 조합해서 재사용도 가능하다. (모듈화가 잘 되어 있음)
    private BooleanExpression nicknameEq(String nickname) {
        return nickname != null ? shorts.customer.nickname.eq(nickname) : null;
    }

    private BooleanExpression keywordContains(String keyword) {
        return keyword != null ? shorts.shortsName.containsIgnoreCase(keyword) : null;
    }
}

@Getter
@NoArgsConstructor
@Builder
@ToString
public class ShortsResponseDto {
    private Long id;
    private String shortsName;
    private String thumbnail;

    //이를 통해 QDTO를 생성해서, DTO 변환 과정없이 (QueryDSL이 알아서 해줌) 편하게 사용이 가능하다.
    @QueryProjection
    public ShortsResponseDto(Long id, String shortsName, String thumbnail) {
        this.id = id;
        this.shortsName = shortsName;
        this.thumbnail = thumbnail;
    }
}

보면 알겠지만, API에 노출하는 ResponseDto에 Qdto를 그대로 사용했다. 이렇게 할 경우, 특히 외부에 의한 변화 가능성을 최대한 제거해야 하는 Requsest, Response에 큰 문제..가 생긴다. 사실상 외부 변화 전파를 막으려고 Entity를 안쓰기로 한건데 이러면 의미가 없어지는 것이다…. 이를 방지하기 위해 구조를 다음과 같이 바꿔야 한다.

이를 코드에 반영하면 다음과 같다.

DTO

/*
@QueryProjection 사용을 위한 중간 내부 DTO
 */

@Getter
@NoArgsConstructor
@Builder
@ToString
public class FilteredShortsResponse {
    private Long id;
    private String shortsName;
    private String thumbnail;

    //이를 통해 QDTO를 생성해서, DTO 변환 과정없이 (QueryDSL이 알아서 해줌) 편하게 사용이 가능하다.
    @QueryProjection
    public FilteredShortsResponse(Long id, String shortsName, String thumbnail) {
        this.id = id;
        this.shortsName = shortsName;
        this.thumbnail = thumbnail;
    }
}

@Getter
@NoArgsConstructor
@AllArgsConstructor
@Builder
@ToString
public class ShortsResponse {
    private Long id;
    private String shortsName;
    private String thumbnail;
}

커스텀 Repository

public interface ShortsQueryRepository {
    //동적 쿼리 예제 : 특정 조건으로 쇼츠를 검색하는 쿼리를 작성해보자.
    List<FilteredShortsResponse> searchShorts(String nickname, String keyword);
}

@Repository
@RequiredArgsConstructor //생성자 주입
public class ShortsQueryRepositoryImpl implements ShortsQueryRepository {

    private final JPAQueryFactory query; //config 파일을 통해 바로 주입

    @Override
    public List<FilteredShortsResponse> searchShorts(String nickname, String keyword) {
        return query
                .select(
                        new QFilteredShortsResponse(
                        shorts.id,
                        shorts.shortsName,
                        shorts.thumbnail
                ))
                .from(shorts)
                .where(
                        nicknameEq(nickname),
                        keywordContains(keyword)
                ).orderBy(shorts.shortsName.desc())
                .fetch();
    }

    // --- 조건 메서드 (동적 쿼리) ---
    // 조건 메서드끼리 조합해서 재사용도 가능하다. (모듈화가 잘 되어 있음)
    private BooleanExpression nicknameEq(String nickname) {
        return nickname != null ? shorts.customer.nickname.eq(nickname) : null;
    }

    private BooleanExpression keywordContains(String keyword) {
        return keyword != null ? shorts.shortsName.containsIgnoreCase(keyword) : null;
    }
}

JPA와 Querydsl은 알면 알수록 심오한 기술인 것 같다. 마치 객체지향을 추구하기 위한 개발자들의 심오한 노력이 느껴진달까 이런 기술을 써볼 수 있다는거 자체가 참 행운인 것 같다….굳

참고 자료

🤍[Querydsl] Querydsl과 DTO, @QueryProjection 비종속적으로 사용하기

🤍[기본 개념] QueryDSL 개념 스터디 자료