JPA, 정말 최선일까

최근 일련의 사건이 있어 해결해야 할 일이 있었는데, 그 과정에서 JPA을 도입하는 게 최선일까라는 질문을 하게 되었다.

​

정확히 이 질문을 하는 시기는 이미 레거시 시스템에 Mybatis로 운영되고 있는 와중에 내 생각(이라 쓰고 고집이라 읽는)으로 JPA를 하는 게 좋겠다 생각하여 프레임워크를 추가하였고, 아직 모든 코드를 JPA로 전환한 것은 아니지만 새로 만드는 것은 JPA를, 그리고 기존 것에서 리팩토링하게 되면 JPA로 바꾸는 중인데, 최근 어떤 계기로 인해 이걸 하는 게 정말 옳은가 생각하게 되었다.

​

​

- Mybatis에선 당연했던 게 JPA에는 없었다

Mybatis는 기본 Query(쿼리) 베이스다. 쿼리를 잘 만들지 못하면 문제가 발생한다. 하지만 쿼리를 잘 다룰 줄 알면 별문제가 없다. 네이티브 쿼리를 그대로 사용하기 때문에 DBMS 툴에서 데이터를 확인하기 위해 작성한 쿼리를 그대로 옮겨놓은 뒤 바인딩만 처리하면 무난히, 그리고 빠르게 끝난다. 또한 에러가 발견되었을 때, 쿼리를 그대로 복사한 다음 변수만 넣어서 검색하면 금방 어떤 문제인지 파악된다. (대부분 라이브에선 쿼리를 로그로 찍는 짓은 안 하기 때문에 데이터 오류가 난 경우 쿼리를 직접 돌려보기 위해 xml에서 쿼리문을 꺼내기도 한다)

​

JPA는 그런 게 없다. 쿼리를 보기 위해서는 로컬에서 돌려보거나 작성한 테스트를 기반으로 실행된 후 나온 결과 쿼리를 보고 확인하는 방법밖에 없다. 또한 JPA로 만든 메서드가 내가 작성하고 확인한 쿼리(또는 데이터)와 맞는지 별도 확인이 필요하다. 그런 면에서 과연 이게 정말 최선인가?라는 생각이 들게 했다. JPA를 폄하하는 건 절대 아니다. 다만 유지 보수 차원에서 더 유리하다고 생각했던 것이 생각지도 못한 것에서 발목 잡힌 느낌이랄까.

​

​

- 복잡한 쿼리는 역시 Native

통계성 데이터는 쿼리가 복잡해진다. 애초에 JPA에 걸맞게 스키마가 구성되어 있지 않기 때문도 있을 것이지만 태생적인 거 아닌가 생각이 들었다. 또한 가급적이면 하나의 세션으로 웬만한 것들을 처리하는 것이 더 유리하다. JPA를 쓰면 batch_fetch_size 등을 쓰면서 한 번에 가져오기 좋은 구조가 있긴 하지만, 쿼리 튜닝까지 염두하여 제대로 하려면 결국 네이티브로 짜야 하겠다는 생각이 들었다.

​

​

- 장점도 분명 있다

쿼리를 다루기 힘들어하는 사람에게 JPA가 무조건 좋다고 말할 순 없지만 그래도 최소한의 기능을 점검해 준다는 면에선 좋았다. 컴파일 에러에서 걸러진다는 것은 정말 큰 장점이라 생각한다. 내 경우 종종 키보드가 말썽을 일으켜서 xml에 오타가 담겨 에러를 낸 적이 있는데 이런 종류의 에러는 런타임이 아니면 발견할 수 없기 때문에 꽤 오래 오류가 방치되어 있었다(다행히 그 쿼리는 자주 쓰이는 건 아니었다).

​

또한 오브젝트 단위로 관리할 수 있다는 점과, insert 나 update를 작성하지 않아도 되는 것은 장점이 있다. 이 부분은 독이 될 수도 있는 부분이기도 하지만 적어도 불필요한 코드를 줄여줬다는 점에서 높게 사고 싶다. 또한 바인딩이 잘못되어서 오류가 날 수 있는 상황을 방지해준다는 면에서도 좋았다. 그래서 한때는 조회는 mybaits로 하고 insert 나 update는 JPA로 할까 하는 생각도 해봤는데 영속성 문제 등으로 인해 말도 안 된다 생각하고 그만두었다.

​

또한 객체적으로 데이터를 구성하여 리턴하는데도 유리했다. 가령 주문 데이터와 여기에 종속되는 주문 상품 데이터가 1:N이라 할 때, 주문을 호출하고 그 ID를 기준으로 주문 상품 데이터를 호출하거나, 혹은 1개의 쿼리로 모두 불러오고 각각 분리하는 작업이 필요했는데, 이런 데이터 형태를 손쉽게 바꿔줄 수 있다는 건 큰 매력이었다.

​

​

아직 익숙지 않아서인지, 노하우가 덜 쌓인 건지 버벅거리고 있지만 분명히 나아가고 있다. 이것저것 보이지 않는 단점도 있지만 쓸만하다고 생각하고 있고 앞으로도 계속 학습, 적용해 나갈 예정이다.