검색 성능 개선 #2 JPA findBy 메소드

findby메소드 기술적인 선택 이유

DB에서 데이터를 가져오는 기술은 findBy메소드로 가장 먼저 배웠고

유일하게 배웠기 때문에 가장 먼저 고려를 해서 적용해보기로 했다.

---

검색기준 220만건

검색 성능의 문제

검색 성능의 측면에서 위 사진과 같은 결과 값은 유효하다고 할 수 없다.

0.5초 이상 걸리는 검색기능을 쓸 사용자는 없기 때문에 이는 개선이 필요하다고 볼 수 있는데

그렇다면 JPA에서의 성능 개선을 할 것인가 다른 기능을 쓸 것인가 라는 고민을 하게 되었는데

회의를 거쳐서 우리는 아래와 같은 이유로 JPA를 적용하지 않고 다른 기술을 사용하기로 했다.

---

제한적인 카테고리 검색 조건

검색 성능의 문제야 다른 기술을 같이 적용해서 해결을 할 수 있는 문제였지만

JPA의 findBy메소드로 우리의 약 13가지가 되는 검색 기능들을 구현하기에는 무리가 있었다.

위는 Repository interface에 구현된 메소드로 가게 이름이 일치하는 부분만 10개를 가져오는 메소드이다.

하지만 나머지 11가지의 기능들도 전부 이렇게 구현하기에는 가독성의 문제도 있고

다양한 조건에서 구현하는데에서는 한계가 있었다.

그래서 QueryDsl을 고려하게 되었다.

---

가독성의 문제

사실 가장 큰 이유이다.

어떻게든 구현은 할 수 있었지만 가독성이 너무 좋지 않았다.

한눈에 보기에는 무슨 기능인지 알 수 없었고 주석처리는 하겠지만 주석을 읽어야지만 이해가 되는

상황이 생길 수도 있겠다 라는 판단이 들어서 구현을 중단하고 바로 QueryDsl을 적용하기로 했다.

---

이후 동적쿼리까지 고민

findBy메소드로 구현을 했을때 또 다른 단점이라하면은 로직이 너무 많아졌다는 것이다.

지금이야 로직이 적기 때문에 문제가 없겠지만 추후에 핵심로직이 service단에 채워지고한다면은

가독성을 해칠우려가 있었고 그에 따라서 검색관련 로직을 줄이기위해서는 동적쿼리까지 고려해야한다는

사실을 알게 되어서 findBy 메소드는 포기하기로 했다.

---

느낀점

프로젝트를 진행하기에 앞서서 우리가 적용할 기술을 선택하는 것도 굉장히 중요하다는 것을 알았다.

프로젝트의 빠른 진행도 좋지만 프로젝트를 진행하기 이전에 기술을 선택하고 회의하고 역할을 정하고

규칙을 정하는 등의 사전 작업도 굉장히 중요하다.

마치 건물을 지을때 가장 뿌리가 되는 기둥을 튼튼하게 만드는 것처럼 사전작업단계에서 많은 소통과

구글링을 통해서 우리와 맞는 최적의 기술을 찾는 것이 포인트였다.