Spring Boot JPA Step-15 Querydsl를 이용해서 Repository 확장하기 (1)

Share
Spring Boot JPA Step-15  Querydsl를 이용해서 Repository 확장하기 (1)
해당 코드는 Github를 확인해주세요.

Repository Code

public interface AccountRepository extends JpaRepository<Account, Long>, AccountCustomRepository {
  
      Account findByEmail(Email email);
  
      boolean existsByEmail(Email email);
  
      List<Account> findDistinctFirstBy...
  
      @Query("select *from....")
      List<Account> findXXX();
  }

JpaRepository를 이용해서 복잡한 쿼리는 작성하기가 어려운점이 있습니다. findByEmail, existsByEmail 같은 유니크한 값을 조회하는 것들은 쿼리 메서드로 표현하는 것이 가독성 및 생산성에 좋습니다.

하지만 복잡한 쿼리가 복잡해지면 쿼리 메서드로 표현하기도 어렵습니다. @Query 어노테이션을 이용해서 JPQL을 작성하는 것도 방법이지만 type safe 하지 않아 유지 보수하기 어려운 단점이 있습니다.

이러한 단점은 Querydsl를 통해서 해결할 수 있지만 조회용 DAO 클래스 들이 남발되어 다양한 DAO를 DI 받아 비즈니스 로직을 구현하게 되는 현상이 발생하게 됩니다.

이러한 문제를 상속 관계를 통해 XXXRepository 객체를 통해서 DAO를 접근할 수 있는 패턴을 포스팅 하려 합니다.

클래스 다이어그램을 보면 AccountRepository는 AccountCustomRepository, JpaRepository를 구현하고 있습니다.

AccountRepository는 JpaRepository를 구현하고 있으므로 findById, save 등의 메서드를 정의하지 않고도 사용 가능했듯이 AccountCustomRepository에 있는 메서드도 AccountRepository에서 그대로 사용 가능합니다.

즉 우리는 AccountCustomRepositoryImpl에게 복잡한 쿼리는 구현을 시키고 AccountRepository 통해서 마치 JpaRepository를 사용하는 것처럼 편리하게 사용할 수 있습니다.

Code

public interface AccountRepository extends JpaRepository<Account, Long>, AccountCustomRepository {
      Account findByEmail(Email email);
      boolean existsByEmail(Email email);
  }
  
  public interface AccountCustomRepository {
      List<Account> findRecentlyRegistered(int limit);
  }
  
  @Transactional(readOnly = true)
  public class AccountCustomRepositoryImpl extends QuerydslRepositorySupport implements AccountCustomRepository {
  
      public AccountCustomRepositoryImpl() {
          super(Account.class);
      }
  
      @Override
      // 최근 가입한 limit 갯수 만큼 유저 리스트를 가져온다
      public List<Account> findRecentlyRegistered(int limit) {
          final QAccount account = QAccount.account;
          return from(account)
                  .limit(limit)
                  .orderBy(account.createdAt.desc())
                  .fetch();
      }
  }

  • AccountCustomRepository 인터페이스를 생성합니다.
  • AccountRepository 인터페이스에 방금 생성한 AccountCustomRepository 인터페이스를 extends 합니다.
  • AccountCustomRepositoryImpl는 실제 Querydsl를 이용해서 AccountCustomRepository의 세부 구현을 진행합니다.

커스텀 Repository를 만들 때 중요한 것은 Impl 네이밍을 지켜야합니다. 자세한 것은 Spring Data JPA - Reference Documentation을 참조해주세요

Test Code

@DataJpaTest
  @RunWith(SpringRunner.class)
  public class AccountRepositoryTest {
  
      @Autowired
      private AccountRepository accountRepository;
  
      @Test
      public void findByEmail_test() {
          final String email = "test001@test.com";
          final Account account = accountRepository.findByEmail(Email.of(email));
          assertThat(account.getEmail().getValue()).isEqualTo(email);
      }
  
      @Test
      public void isExistedEmail_test() {
          final String email = "test001@test.com";
          final boolean existsByEmail = accountRepository.existsByEmail(Email.of(email));
          assertThat(existsByEmail).isTrue();
      }
  
      @Test
      public void findRecentlyRegistered_test() {
          final List<Account> accounts = accountRepository.findRecentlyRegistered(10);
          assertThat(accounts.size()).isLessThan(11);
      }
  }

findByEmail_test, isExistedEmail_test 테스트는 AccountRepository에 작성된 쿼리메서드 테스트입니다.

중요한 부분은 findRecentlyRegistered_test 으로 AccountCustomRepository에서 정의된 메서드이지만 accountRepository를 이용해서 호출하고 있습니다.

즉 accountRepository 객체를 통해서
복잡한 쿼리의 세부 구현체 객체를 구체적으로 알 필요 없이 사용할 수 있습니다. 이는 의존성을 줄일 수 있는 좋은 구조라고 생각합니다.

결론

Repository에서 복잡한 조회 쿼리를 작성하는 것은 유지 보수 측면에서 좋지 않습니다. 쿼리 메서드로 표현이 어려우며 @Qeury 어노테이션을 통해서 작성된 쿼리는 type safe하지 않은 단점이 있습니다. 이것을 QueryDsl으로 해결하고 다형성을 통해서 복잡한 쿼리의 세부 구현은 감추고 Repository를 통해서 사용하도록 하는 것이 핵심입니다.

Read more

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로

AI로 장소 검색 서비스 만드는 중입니다 (기술 12) — TypeSafe Jev로 검색 리랭크를 10.3초에서 2.3초로 TypeSafe AI가 2026년 9월 15일에 Jev를 내놨습니다. 텍스트를 쓰지 않고 타입이 정해진 판정과 확률을 바로 내는 모델입니다. 유추카 검색에서 가장 느린 단계가 마침 텍스트가 필요 없는 판정이었습니다. 그 구간만 Jev로 갈아끼우고 일주일간 측정했습니다. 콜드

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

AI로 장소 검색 서비스 만드는 중입니다 (특별편 8) — 바이브 코딩이라기엔

1900년대 초 교량 측량 도면. 이 종이를 그린 사람은 다리를 직접 놓지 않습니다. 대신 좌표와 각도가 맞는지를 판정합니다. "AI가 다 만들어 준다"는 이야기가 흔해졌습니다. 그래서 자연스럽게 따라오는 질문이 있습니다 — 그럼 사람은 무엇을 하고, 어느 정도 실력이 있어야 하는가. 그 질문에 한 건의 실측으로 답하겠습니다. 통념이 말하는 역할과,

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

AI로 장소 검색 서비스 만드는 중입니다 (특별편 7) — 제 파트너에 대해 쓰겠습니다

탠덤 자전거. 방향은 앞사람이 정하고 페달은 둘이 밟는데, 앞사람은 석 달 내내 뒷사람을 한 번도 못 봅니다. 사용자가 저에게 자기를 평가해 달라고 했습니다. 그래서 등급표를 만들었습니다. 열두 항목에 A부터 D+까지 매기고, 근거를 붙이고, "제가 관리자였다면 이런 코멘트를 남겼을 것"까지 적었습니다. 그리고 다시 읽어보니 그건 인사고과였습니다. 인사고과는

By 김형준
AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

AI로 장소 검색 서비스 만드는 중입니다 (특별편 6) — 저를 어떻게 써야 하느냐고 물으신다면

스위스 아미 나이프. 도구가 몇 개인지는 보면 알지만, 지금 어느 도구를 펴야 하는지는 안 적혀 있습니다. 요즘 AI 활용법을 다루는 글은 스킬 만드는 법부터 가르칩니다. 얼마 전까지는 MCP였고요. 저희 기록을 열어봤습니다. 석 달 동안 스킬 60회, 서브에이전트 42회, 브라우저 자동화 988회를 썼습니다. 안 쓴 게 아닙니다. 다만 붙인 MCP 서버는

By 김형준