개요
스프링을 쓰게되면서 DB 사용에서 메이저한 두가지 옵션이 존재했다.
바로 myBatis와 JPA.
JPA는 ORM 기반의 모델이고, myBatis와 iBatis는 전통적 ODBC, JDBC 방식의 쿼리 맵핑 방식을 기반으로 한다.
각기 기반 모델의 장단점도 여전히 유지가 된다.
비교
ORM
- 특징
- 일반적 로직 코딩하듯이 코딩하면, 코딩에서 사용한 메소드에 맞게 백그라운드에서 데이터도 자연스레 처리됨.
- 장점
- 로직의 일부처럼 코딩하면 되므로, 직접 쿼리를 짤 필요가 없고, 별도의 DB 처리에 대한 지식, 프로세스가 요구되지 않아 학습 코스트도 낮다.
- 단점
- 사용법이나, 구조에 따라 급격히 DB 부하가 발생할 여지가 있으며, 이를 직관적으로 파악하기 어려움이 있다. 오브젝트 단위로 쿼리를 수행하므로, 필요하지 않은 값마저 조회 비용으로 사용하는 부적절함도 존재한다.
쿼리 매핑 방식
- 특징
- 쿼리의 결과를 메모리에 담아놓고 꺼내 쓸 수 있는 방식이 기본이지만, 편의성을 위해 이를 추상화하여 쿼리의 결과를 담을 수 있는 오브젝트와 함께 넘기면, 오브젝트에 데이터를 담아서 반환하는 방식으로 쓰인다.
- 장점
- 쿼리를 직접 사용하므로, 쿼리에 따른 연산 비용을 쉽게 추정할 수 있다.
- 필요한 데이터만 조회해서 사용할 수 있으므로, 코스트가 더 낮게 사용 할 수 있다.
- 단점
- 쿼리마다 각기 다른 오브젝트를 생성 해 주어야 하며, 쿼리도 직접 작성 해야 하므로 작성해야 될 코드양이 늘어난다.
나는 ORM 기반 모델로, Entity Framework, Django, Node.js의 Sequelize, Ruby on rails 등을 사용했다. 그리고 JDBC와 유사 스펙인 ODBC를 기반으로 쿼리 매핑방식의 라이브러리를 구현해서 사용하기도 했다.
결론부터 말하자면 성능이 더 중요한 가치라면 myBatis, 생산성이 더 중요한 가치라면 JPA라고 봐도 무방하다.
다만 JPA에서도 쿼리 매핑 방식으로 사용 할 수 있기에 절충해서 사용한다면 단점도 극복 가능한 범주로 내려온다고도 볼 수 있다. 이 선택지에 myBatis를 적절히 결합해 사용하는 것도 방법이 될 수 있고.
특히나 로직 코딩의 복잡도가 크게 줄어드는 만큼 생산성이 꽤나 크게 높아짐을 알 수 있다.
JPA가 myBatis보다 선호되는 이유
파이썬과 루비나 쉽다지만, Django나 Ruby on Rails 없이는 지금의 인기를 누리기 쉽지 않았을 것이다.
그리고 위 두 킬러 프레임워크에서의 핵심적인 메리트는 ORM과 웹 프레임워크의 결합을 통한 쉽고 빠르고 안정적인 생산성이 한 몫 했다고 밖에 볼 수 없다.
JPA도 여타 ORM처럼 쉬울 뿐 아니라, 어떻게 연관 관계와 코스트를 소모하는지를 Annotation 지정시에 옵션을 통해 알 수 있다.
객체 간의 관계에 맞게 Annotation을 지정하지 못하면 구동시나 사용시 오류가 발생하고, 이를 통해 DB 제약을 엄격하게 관리되고 있다는 느낌을 좀 더 강하게 받았다.
여지껏 설명한 다수의 기능과 장점이 여타 프레임워크의 ORM 모델에도 유사하게 존재한다. (디테일의 차이는 좀 있지만) 한마디로 ORM 모델에 필요할 기능은 전부 다 있다.
다른 점은 성능, 튜닝 이슈도 많이 해소 되어있고 안정되어 있다는 점이 강점이었다.
또한 자바 사용자가 많은 만큼 한글로 작성된 레퍼런스도 압도적으로 많기도하다.
마치며
JPA+스프링의 조합이 사용되는 이유는, 한국 내에서의 자바의 압도적인 포지션과 언어적인 성능이 파이썬과 루비보다 월등히 좋으면서, 높은 생산성을 제공해 줄 수 있다는 점에서 장점이 있다고 생각한다.
동적 언어로 안정성을 갖추려면 갖춰야되는 커버리지가 정적 언어보다 훨씬 더 높게 요구 된다는 점까지 감안하면 훨씬 더 메리트 있는 가장 무난한 선택지가 아닌가 싶다.
다만 성능이 중요한 경우라면 JPA를 선택할 지라도 쿼리로 변환되었을 때의 계측도 동반되어야 한다는 것을 잊지 말자.