ORM 과 갈라지는 지점 JPA 는 객체 조작을 보고 쿼리를 만들어 준다. MyBatis 는 SQL 을 사람이 쓰고, 프레임워크는 결과 집합을 객체에 채우는 일만 한다. 그래서 비교의 축은 "편한가" 가 아니라 쿼리의 통제권을 누가 갖는가 다.
| JPA | MyBatis | |
|---|---|---|
| 쿼리 작성 | 프레임워크가 생성 | 사람이 직접 |
| 강한 곳 | 도메인 중심 CRUD·생산성 | 복잡 조인·통계·세밀한 튜닝 |
| DB 이식성 | 방언(dialect)이 흡수 | 문법이 DB 에 종속 |
| 학습 부담 | 영속성 컨텍스트·연관관계·지연 로딩 | SQL 자체 + 매퍼 보일러플레이트 |
DB 종속이 구체적으로 무엇인가 페이징을 예로 들면 MySQL 은 LIMIT ... OFFSET ..., Oracle 은 오래된 버전에서 ROWNUM 을 감싼 서브쿼리를 쓴다. MyBatis 에서는 이 문법이 XML 에 그대로 박히므로 DB 를 바꾸면 쿼리를 손봐야 한다. JPA 는 같은 코드를 방언 구현이 각 DB 문법으로 번역한다.
면접에서의 실제 답 둘 중 하나를 고르라는 질문이 아니다. 실무의 기본형은 JPA 를 기본으로 두고, 동적·복잡 조회는 QueryDSL, DB 고유 기능이 필요한 쿼리만 네이티브 SQL 이나 MyBatis 로 빠지는 혼용이다. "JPA 를 쓰면 SQL 을 몰라도 된다" 는 오해가 특히 자주 지적되는데, 생성된 쿼리를 읽지 못하면 지연 로딩 이 만드는 추가 쿼리도, 인덱스를 못 타는 조건도 발견할 수 없다.