라이브러리는 개발 편의다.

개요

최근에 겪었었던....

mybatis에서 편하고, 컴파일 시점에 잘못 작성한 쿼리인지,
타입을 잘못작성했는지 확인할 수 있는 querydsl을 도입하려고 했었고
엔티티클래스를 다루기위해서 querydsl 도입 시도를 해봤는데,

공식사이트의 최근 업데이트 버전은 5.0.0 이고,
메이븐에 올라가있는 버전은 5.0.1 이 최신이고,

그마저도 2024년이 가장 최근인데다, 보안관련 경고로, 빌드할때마다 그래들에서 계속 걸고 넘어지길래
좀 고민이 많이 됐었음.

주요 고민

공식 사이트에서 마이너, 패치의 버전 번호에에 관련된 문서가 공개가 안됐었나? 살펴보면 그것도 아니고
심지어 공식사이트 [https://querydsl.com/] 접속할때 조차,
인증서 위험으로 브라우저 단에서 미리 차단을 해버리는데
관리가 되고있는 라이브러리가 맞나? 라는 의심이 됐기 때문에,
단순히 마이바티스를 편리하게 사용하기 위해, 이 위험을 감수하고 사용하는게 맞나?
라는 판단이 들었음.

결과

그 결과, AI의 도움을 받아 나름 수월하게 작성한 코드지만,
여태까지 적용했던 내용을 전부 제거하는게 맞는거라고 생각하고 제거했음.

이 후 진행

qeurydsl을 들어내면서 뭐라고 해야할까. 말로, 글로 표현하기 복잡한 심경이 휩싸였는데.

마이바티스를 이용해서 sql을 전부 일일히 작성하고 다룰까 했는데,
이런저런 모색을 한 결과, 간단한 쿼리는 JPA를,
이런저런 쿼리를 날려야 하는 경우에는 마이바티스를 써서, 처리를 하도록 하고,
완전 초면인 JPA의 사용 방법은 제미나이의 도움을 받아 진행하도록 방향을 잡으니,
생각만으로도 많이 수월하다는 생각이 들었음.

얻은 이점

JPA 자체가 N+1 문제라느니, 조인, 서브쿼리 등을 이용한 쿼리는 결국 쿼리문을 작성해야한다느니,
쿼리문을 자동으로 생성하기 때문에 잘못 생성되면 원인을 알아야하기 위해 뭔가를 더 세세하게 찾아봐야한다느니
이런저런 주워들은 걱정이 있었는데,
단순한 select, insert, update, delete 에 대한 쿼리를 진행하기 위해,

모든 방법을 처리하기위해 ddl별로 쿼리문을 작성할 필요가 없어져, 관리포인트가 획기적으로 많이 줄었다는게 좋았음.

JPA를 도입하면서 책임 분리에 대한 방법을 실질적으로 알게됐음.
(이전엔 나름 분리를 잘했는데, 분리된 동작들을 취합해서 만들어야 할 때 는, 머리가 정지하면서 코드가 짬뽕되기 시작했음)