JPA(ORM)는 "절대선(善)"인가?

저는 최근에 거의 Java와 Spring Boot로 개발을 하고 있기 때문에 ORM 적용 시 JPA을 이용하고 있습니다. 기본적인 사용법이야 그리 어렵지 않고, JPA Repository를 이용한 Query 자동생성 기능은 만족스러운 부분도 많습니다만, 그렇다고 맹신하는 건 무리가 있다고 생각하고 있습니다. 그리고, JPA 신봉자들은 일단 MyBatis 같은 Query를 직접 이용하는 부분을 매우 깔보는(느낌일 수 있지만, 확신이 될 정도이니) 경향도 있습니다.

 

그럼, JPA는 제목에서 말한 것처럼 "절대선(善)"일까요?

저는 아니라고 생각합니다. 물론 JPA 쓰는 분들 중에 JPA 만으로 처리를 다 하는 경우가 없고, @Query와 같은 것을 이용해 Native Query를 사용하는 경우도 있고 QueryDSL이나 JOOQ 같은 것을 병용해서 쓰는 경우도 있기 때문에 JPA만이 옳다고 주장한다고 말하는 제 말이 오히려 이상하다고 생각할 수 있습니다. 하지만, 제가 주장하려고 하는 것은 JPA가 옳지 않다는 것도 아니고, 쓰지 말라는 것도 아닙니다. 관점을 달리하면 다른 길이 보이니, 유연하게 바라보자는 의미입니다.

 

제가 생각하는 JPA의 최대 장점은 개발속도의 향상입니다. DB 스키마를 프로그램의 객체로 매핑(ORM)하여 프로그램에서 다루면 DB에 자동으로 반영해주겠다는 것은 훌륭한 생각이고, 이를 통해 개발자는 DB에 관련된 코드를 별도로 작성할 필요 없이 Java 코드 작성하듯이 개발하면 저장소에 훌륭하게 저장됩니다.

예를 들어 Query Mapper라고 할 수 있는 MyBatis를 이용한다고 합시다. 특정 테이블을 이용해 WebMVC로 요청을 받아 CRUD를 하는 코드를 작성한다고 가정해보겠습니다. 그럼 우리는 Controller, Service 파일을 작성하고 Java Mapper 파일에 메서드를 작성하고 이와 같은 id를 가지는 XML Mapper 파일을 작성해야 합니다. XML Mapper 파일에는 CRUD에 해당하는 INSERT, SELECT, UPDATE, DELETE 쿼리가 들어가 있고, 테이블명과 컬럼명이 나열되어 있어야 합니다. 그리고 매개변수나 결과값을 저장하는 DTO(Domain, VO, ...) 모두 작성되면 프로그램이 실행되고, 페이지를 호출하면 그 때서야 질의(Query)가 DBMS에 전달되어 문법 상 오류가 있는지, 컬럼명 등은 제대로 일치하는지 확인을 합니다.

문제는, 개발을 하다 보면 아주 빈번히 컬럼명 등이 바뀐다는 것입니다. 테이블 간의 관계가 바뀌는 경우도 종종 있지만 컬럼명 수정은 정말 비일비재하게 일어납니다. 그럴 경우 Entity 파일에서 변수명을 바꾸는 것만으로도 IDE에서 오류를 바로 알려주거나 Complie 단계에서 오류를 찾아낼 수 있습니다. 혹은 프로그램 실행 시 validate를 실행하여 테이블과 엔티티 사이의 불일치를 발견하여 바로 알 수 있게 해주는 장점이 있습니다. 그에 반해 질의를 직접 관리하는 경우에는 런타임 상황에서나 이를 발견하여 오류 발견이 늦어질 수도 있고, 고쳐야 할 곳도 많이 늘어날 수 있습니다.

 

하지만, ORM의 특성 상 DB를 가장 잘 다룰 수 있는 방법이 아니라는 것에 문제가 있습니다. ORM을 잘 쓰기 위해서 무엇을 해야하는지 알아보면 공통적으로 보이는 내용 중에 "설계"를 잘 해야한다는 것을 심심치않게 발견할 수 있습니다. 많은 JOIN이 발생하거나 INSERT SELECT를 써야하는 경우가 발생한다거나 하는 경우 단순히 질의 만으로 처리하던 것을 매우 복잡하거나 여러 번의 통신을 통해 반영해야 할 수도 있습니다.  통계나 더 복잡한 기능이 필요할 경우에는 말할 것도 없습니다.

그래서 이런 경우 JPA와 MyBatis을 혼용해서 쓰는 방법도 존재합니다. 하나의 Connection을 JPA와 MyBatis가 동시에 사용하게 하여 Transaction까지 공유하도록 개발할 수도 있습니다. 하지만, JPA가 절대선이라고 여기는 분들은 이런 것을 참지 않는 경우가 많더군요.

 

그럼 왜 질의(Query)는 살아남아야 할까요? 사실 No SQL이 대세가 된다면 반드시 그럴 필요는 없을지도 모른다고 생각합니다. 하지만, 아직까지도 RDBMS는 대다수의 시스템에서 메인 DB를 다루는 시스템으로 이용되고 있고, RDBMS의 데이터를 가장 잘 처리할 수 있는 방법은 SQL이기 때문입니다. 각 RDBMS에서 지원하는 수많은 기능은 여러 조건을 쉽게 처리할 수 있는 다양한 방법을 제공하고, 그러한 방법은 인터넷 세상에 아주 많이 공유되고 있습니다. 반대로, RDBMS는 프로그래밍 언어의 객체 등과는 괴리가 존재합니다. 그래서 ORM을 이용할 때에는 그런 괴리를 상쇄시키기 위한 공부가 필요하며, 이러한 것들은 ORM을 이용할 때 장벽처럼 다가와...야 하는데 기본적인 사용에서는 그러한 문제들이 쉽게 보이지 않기 때문에 ORM에 열광하는게 아닌가 합니다. 괴리 없이 사용할 수 있는 SQL이 있는데, 굳이 괴리를 맞추기 위한 방법을 공부해가면서 쓴다? 좀 이상하지 않나요?

이와 더불어 큰 문제 중 하나는, 상당수의 노련한 "한국" 개발자들은 SQL에 매우 익숙하다는 것입니다. 어떠한 질의 조건이 필요할 때 어떻게 개발해야할지 머릿 속에서 자동으로 그려지는데, 그걸 굳이 Entity 기반으로 처리할 필요성을 못느낀다는 거죠. 마치 함수형 개발이 절차적 개발에 비해 사람의 의식의 흐름대로 개발하는 것이기 때문에 더 배우기 쉽다고 하지만, 노련한 개발자에게는 처음에는 오히려 더 불편하게 느껴지는 것과 비슷한 이유라고 생각합니다.

 

결론적으로, 그래서 전 주니어들에게 Query로 RDBMS에서 데이터를 가져오는 연습을 반복적으로 시키는 편입니다. JPA 같은 것들을 복잡하게 가져오는 경우를 서비스에서는 최소한으로 줄이고, 관리자에서는 MyBatis을 같이 사용할 수 있도록 하고 있습니다. JPA만 쓴다? 저는 그냥 꿈같은 이야기로 받아들였습니다.

 

마지막으로...

반박 시...여러분 말이 맞습니다.