작성한 질문수 9

1

안녕하세요, henry 님. 공식 서포터즈 y2gcoder 입니다.

Q. 향후 어떻게 변할지 모를 "확장성"과 "일관성"을 위해, 처음부터 모든 쿼리를 QueryDsl을 이용하는게 좋을까요...?

개인적인 의견에서 먼저 결론부터 말씀드리면 지금처럼 Spring Data JPA의 기본 기능과 QueryDsl을 혼용하시는 게 어떠신가 합니다. 최종적인 선택은 henry님께서 하시겠지만 제가 그렇게 생각하게 된 이유들을 적어보겠습니다.

첫번째로 현재 프로젝트의 상황에서 QueryDSL로 통일하는 과정에서 드는 비용을 감수할 가치가 있는지 따져봐야 할 것 같습니다. 먼저 save 를 언급하신 것으로 보아 Spring Data JPA의 기본 API들을 말씀해주시고 계신 것 같습니다. Spring Data JPA가 가지고 있는 강력한 편의 기능들을 포기하면서 QueryDSL로 직접 구현하는 비용과 QueryDSL로 통일했을 때 얻을 수 있는 실질적인 효용 사이에서 고민해보셨으면 합니다.

두번째로 프로젝트에 요구사항이 더 복잡해질수록 일관성을 지키기는 힘들 것 같습니다. 사실 QueryDSL-JPA 는 JPA의 JPQL을 자바 객체로 표현할 수 있는 라이브러리라고 생각합니다. 그래서 저는 해당 라이브러리가 JPA에 의존적이라고 생각합니다. 그런데 영한님께서도 강의나 질문마다 언급하시는 것처럼 실무에서 정말 복잡한 조회 쿼리를 만났을 때는 JPA만으로는 해결하기 어려울 수도 있습니다. 그 때는 JdbcTemplate이나 NativeQuery를 사용해야 하는데, 이런 부분에서 비용까지 지불하며 만들었던 일관성이 깨질 수 있지 않을까 생각합니다.

세번째로는 확장성에 대해서 henry님과 다르게 생각한 것 같습니다. 위에 말씀드렸듯이 QueryDSL-JPA는 JPA에 의존적인 라이브러리라고 생각합니다. 확장성에 대해서 어떤 정의를 내리셨는지 제가 감히 판단하기는 어렵기 때문에 제가 나름대로 생각해봤을 때, 나중에 기술 트렌드가 변화하거나 기존 기술로 요구사항의 변화에 대응하기 어렵게 되는 시기가 왔을 때 적게 변경할 수 있는 것이 확장성이라고 생각했습니다. 그러한 관점에서 QueryDSL-JPA는 결국 JPA에 의존적인 라이브러리이고 의존성이 있는 라이브러리는 그러한 변화로 인한 확장에 더 대응하기 어렵지 않나 생각합니다. JPA는 자바 표준이기 때문에 대체될 가능성이 극히 적다 해도, JPA와 관련한 획기적인 라이브러리가 나와서 QueryDSL-JPA를 대체할 가능성은 충분히 있을 수 있다고 생각합니다.

세가지 다 결국 제가 개인적으로 생각한 바를 말씀드린 것이기 때문에 틀린 정보가 너무 많을 것 같아 그저 참고만 해주셨으면 좋겠습니다:)

다른 것을 다 떠나서 YAGNI라는 유명한 말처럼 정말 필요한 것이 아니라면 좀 더 고민해보시는 게 어떤가 해서 조금 길게 답변을 드려봤습니다.

도움이 되셨으면 좋겠습니다.

감사합니다.