[Spring] JPA vs MyBatis
웹 애플리케이션을 위한 백엔드로 가장 많이 사용되는 프레임워크로는 Java 기반의 Spring 또는 Springboot를 사용한다.
Spring은 대규모 기업환경에서 안정성과 신뢰성이 검증된 프레임워크이기 때문에 많은 기업에서 스프링을 사용하여 안정적인 서비스를 운영하고 있는데, 백엔드에서 데이터를 저장하고 조회하려면 데이터베이스를 활용해야 한다.
백엔드에서 데이터베이스를 사용하는 프레임워크로 가장 많이 쓰이는 기술이 ‘Mybatis’와 ‘JPA’이다.
Java 기반의 Spring 또는 Springboot에서 데이터베이스를 사용하려면 두 가지 기술 중 하나를 사용해야 한다.
데이터베이스 접속을 편하게 사용하기 위해 SQL Mapper 기술과 ORM(Object Relational Mapping) 기술을 제공하는데 둘 다 DB와의 연동과 저장을 위한 기술이다.
SQL Mapper는 ‘개발자가 작성한 SQL 실행 결과를 객체에 매핑’시켜주는 프레임워크이며, ORM은 객체와 DB의 데이터를 ‘자동으로 매핑’시켜주는 프레임워크를 말한다.
SQL Mapper 기술을 제공하는 것이 ‘MyBatis’이며, ORM 기술을 제공하는 것이 ‘JPA(Java Persistence Api)’이다.
두 가지 기술은 모두 데이터를 관계형 데이터베이스에 저장, 즉 영속화(Persistence) 시킨다는 측면에서는 동일하지만, 서로 다른 접근 방식을 채택하고 있다.
MyBatis - SQL Mapper
MyBatis 프레임워크는 반복적인 JDBC 프로그래밍을 단순화하여, 불필요한 Boilerplate 코드를 제거하고, Java 소스코드에서 SQL 문을 분리하여 별도의 XML 파일로 저장하고, 이 둘을 서로 연결시켜 주는 기능을 제공한다.
MyBatis를 사용하면, MyBatis 내부에서 그러한 Boilerplate 코드가 구현되어 있고, MyBatis에서 Java 메소드와 SQL 간에 매핑을 시켜서 개발자는 Java 메소드 선언과 SQL 문만 만들면 MyBatis가 자동으로 그 둘 간을 연결시켜 주게 된다.
SQL 문장이 Java 코드 내에 들어가 있어서 수정하기도 힘들고 보기도 힘들었는데, SQL 문을 별도로 Java 코드에서 분리해두어서 관리가 편하게 하였으며 분리된 SQL 문을 MyBatis가 찾아서 실행해 주는 기능을 한다.
MyBatis의 장점
- SQL 쿼리를 직접 작성하므로 최적화된 쿼리를 구현 가능
- 엔티티에 종속받지 않고 다양한 테이블을 조합 가능
- 복잡한 쿼리도 SQL 쿼리만 작성할 수 있다면 손쉽게 작성 가능
MyBatis의 단점
- 스키마 변경시 SQL 쿼리를 직접 수정 필요
- 반복된 쿼리가 발생하여 반복 작업이 있을 수 있음
- 런타임시에 오류가 발생할 수 있음
- 쿼리를 직접 작성하기 때문에 데이터베이스에 종속된 쿼리문이 발생할 수 있음, 데이터베이스 변경 시 로직도 함께 수정 필요
JPA - ORM (Object Relational Mapping)
그런데, MyBatis와 같이 SQL 문과 Java 코드를 연계하는 접근 방식이 아니라 Java 객체와 DB 엔티티(테이블) 자체를 그대로 매핑해서 처리할 수 있는 접근 방식을 채택한 새로운 기술표준이 등장했는데, 이것이 바로 ‘JPA(Java Persistence API)’다.
데이터베이스는 데이터 중심의 구조를 가지고 있고, Java는 객체지향적인 구조로 관리되기 때문에 둘 사이에 데이터를 직접적으로 쉽게 가져오거나 쉽게 저장하는 방법이 존재하지 않았고, 이 둘 사이를 손쉽게 변환이 된다면 개발이 용이해질 것이다.
JPA의 접근 방식은 이런 ORM(Object-Relational Mapping) 기술을 의미한다. 즉, 객체와 데이터베이스 간의 매핑 기술을 의미하며, Java 개발자가 좀 더 객체지향 관점에서 개발할 수 있게 하고, 개발을 용이하게 해 주어서 DB와 Java 간의 불일치를 해소할 수 있게 해 준다.
이해를 돕기 위해 ORM 기술을 좀 더 구체적으로 살펴보자면 위 그림에서 Java 객체인 Student 클래스가 ORM 매핑을 통해서 DB 테이블에 영속화(Persistence) 되고, 또다시 영속화된 데이터가 다시 Java 객체로 변환하는 과정을 나타내고 있다.
ORM은 이렇게 Java객체를 DB 테이블로 자동으로 영속화시켜주는 기술을 의미한다.
Java와 DB 데이터 간의 매핑을 자동화해 주어서 개발자는 SQL 문을 작성할 필요가 없어지고, DB가 바뀌어도 DB에 따라 새로운 SQL을 작성할 필요가 없이 Hibernate에서 DB에 맞는 적합한 SQL 문을 생성해 준다.
이러한 ORM 기술을 실제 구현해서 만들어진 프레임워크가 Hibernate다. JPA 스펙을 구현한 기술은 Hibernate 외에도 EcliseLink, DataNucleus 등이 있지만, 현재 사실상 표준(de facto standard)으로 널리 사용되는 것은 Hibernate다.
JPA의 장점
- 1차 캐시, 쓰기 지연, 변경감지, 지연로딩 등 을 제공하여 성능상 이점
- 코드 레벨로 관리되므로 사용하기 용이하고 생산성이 높음
- 컴파일 타임에 오류를 확인 가능
- 데이터베이스에 종속적이지 않으므로 특정 쿼리를 사용하지 않아 추상적으로 기술 구현 가능
- 엔티티로 관리되므로 스키마 변경 시 엔티티만 수정하게 되면 엔티티를 사용하는 관련 쿼리는 자동으로 변경된 내역이 반영
- 개발 초기에는 쿼리에 대한 이해가 부족해도 코드 레벨로 어느 정도 커버 가능
- 객체지향적으로 데이터를 관리 가능
- 부족한 부분은 다양한 쿼리 빌더와 호환하여 보안 가능
JPA의 단점
- JPA만 사용하여 복잡한 연산을 수행하기에는 다소 무리가 있음(로직이 복잡하거나 불필요한 쿼리가 발생할 수 있음)
- 초기에는 생산성이 높을 수 있으나 점차 사용하다 보면 성능상 이슈가 발생할 가능성이 있음(N+1, FetchType, Proxy, 연관관계)
- 고도화될수록 학습 곡선이 높아질 수 있음(성능 이슈의 연장선으로 해결 방안에 따라 복잡한 내부 로직을 이해해야 할 필요가 있음)
결론
JPA는 처음엔 사용하기 쉬울지 몰라도 점차 애플리케이션이 고도화된다면 오히려 더 손이 많이 가는 경우가 많다. 그렇기 때문에 JPA와 함께 문제점을 보완해 줄 수 있는 다른 라이브러리가 필요하다. 그중에 하나가 Mybatis가 될 수 있다. 이 둘을 적절히 혼용하여 사용한다면 안정적인 서비스를 제공할 수 있다.