Mybatis vs JPA

프로젝트를 진행하면서 DB 접근 기술로 Mybatis를 사용할지, JPA를 사용할지 고민이 되었습니다. 결국 Mybatis를 사용하기로 결정되었는데, 사용하면서 느낀 점에 대해서 이야기해보겠습니다.

저의 짧은 지식으로 작성된 글이니, 틀린 내용이 있을 수 있습니다.

Mybatis를 사용하며 불편한 점

개발의 중점

Mybatis를 사용하게 되면, SQL을 직접 작성해야 합니다. 물론 JPA를 사용한다고 해서 작성할 일이 없는 건 아니지만, Mybatis와 비교하면 상당히 적습니다.

이는 전체 개발 시간에서 SQL을 작성하는 시간이 차지하는 비율이 더 높아진다고 할 수 있습니다. 프로젝트를 진행하면서 비즈니스 로직에 해당하는 코드보다 SQL을 작성하는 시간이 많아지게 되면서 소요 시간의 볼륨 자체가 커지는 듯한 느낌을 받았습니다. 결국 SQL 중심의 개발이 되었습니다.

SQL 오류

이는 단순히 저의 문제일 수도 있는 부분입니다. SQL을 직접 작성하다 보면, 여러 가지 에러가 생길 수 있습니다. SQL 자체에 대한 이해 부족으로 인해 오류가 생길 수도 있고, 오타 또는 공백을 입력하지 않아 에러가 생길 수 있습니다.

결국 Mapper 에서 오류가 생기면 오타가 있는지, 공백이 제대로 있는지 또는 SQL 자체가 잘못된 건지 확인해야 합니다.

테스트

Mybatis를 사용하면, JPA와 다르게 DB에 조회해서 찾은 두 객체가 PK 가 같은 동일한 데이터라도, 객체 상 같음을 보장하지 않습니다. 마치 자바에서 new Item(...)을 통해 생성한 두 객체가 내부 필드가 모두 같더라도, 같음을 보장하지 않는 것과 같습니다.

반대로 JPA는 두 객체의 같음을 보장합니다. 즉 테스트 코드에서 다음과 같은 테스트가 가능합니다.

@Test
public void test() {
	Item item1 = jpaRepository.findById(1);
	Item item2 = jpaRepository.fidnById(2);

	assertThat(item1).isEqualTo(item2);// true
}

마치 자바 컬렉션에서 꺼내온 것처럼 동작합니다. 하지만 Mybatis는 위 코드처럼 같음을 보장하지 않기 때문에 조회한 두 객체를 비교할 때, 필드값을 비교하게 됩니다. 또는 equals 메서드를 재정의해도 좋을 듯합니다.

Mybatis를 선택한 이유?

제대로 이해하고 사용한다면, JPA가 훨씬 편리해 보입니다. 그럼에도 저희 팀이 Mybatis를 사용한 이유는 무엇일까요?

Learning Curve

JPA는 개발자가 비즈니스 로직에 집중할 수 있도록 도와줍니다. 하지만 이 말은 ‘그만큼 JPA가 해주는 일이 많다’는 뜻입니다. ‘많은 부분을 대신해주면 좋은 게 아닌가?’ 생각도 들지만, 팀의 JPA 이해도가 낮았기 때문에 레퍼런스에 대한 의존도가 높아질 것이고 트러블 슈팅하는 데에 시간도 많이 소요될 것이라고 예상하였습니다. 따라서 비교적 직관적인 Mybatis를 사용하게 되었습니다.

Mybatis와 JPA

이번 프로젝트를 진행해 보면서 JPA의 이점이 크게 느껴진 것 같습니다. 개인적으로 오타를 많이 내는데, SQL이 작성된 XML 파일에서 오류를 찾기가 상당히 쉽지 않았습니다.

하지만 JPA를 잘 사용하려면 JPA에 대한 이해가 충분해야 하기 때문에 JPA에 대해 더 공부해 볼 예정입니다.