[JPA] 왜 JPA를 사용해야될까? (2)

이번 포스팅에서는 JPA를 사용하지 않았을 때 어떤 문제점이 있었는지 알아보도록 하자. 대부분의 기술이 그러하듯 JPA 역시 기존의 문제점들을 해결해주기 때문이다.

JPA를 거의 도입하지 않던 시절 대부분의 레거시 프로젝트 또는 신규 프로젝트라면 아마 압도적인 비율로 iBatis / MyBatis 같은 SQL Mapper를 사용하여 개발할것이다. SQL Mapper 역시 더 이전에 존재하던 많은 문제를 해결해주었지만, 완벽한 기술은 존재하지 않기 때문에 몇가지 문제가 있다.

SQL Mapper(MyBatis 등)의 문제점

1. 유사한 CRUD 문장의 반복
2. 특정 DB에 종속적이다.
3. 객체와 테이블간의 패러다임 불일치로 인해 객체지향적인 개발/설계가 어렵다.

대표적으로 위 3가지 문제점이 있는데 각각 자세하게 얘기해보자면..

1. 웹 어플리케이션은 수많은 테이블이 관계를 맺고 있고, 그에 대한 INSERT, SELECT, UPDATE, DELETE 쿼리문이 만들어진다. SELECT문은 예외로 하더라도, 나머지 쿼리문은 대부분 비슷한 구조로 굉장히 단순하고 반복적인 문장이 된다. 또한, 개발 중에 컬럼이 추가/삭제된다던가 하는 테이블 구조에 변화가 생기면 그 테이블와 관련 된 쿼리들을 전부 찾아 변경해줘야한다.

2. 표준 SQL문이라고 부르는 ANSI SQL을 제외하고, DB들은 각각 고유의 방언(?)과 같은 문장이 있다. 예를 들면, ORACLE의 ROWNUM과 MySQL의 LIMIT처럼 기능은 비슷하나 사용법이 다른 쿼리인데 흔한 일은 아니겠지만, 현재 개발 또는 운영중인 서비스의 DB를 바꿔야한다면 어떤일이 일어날까? 사용중인 SQL문을 모두 전수 검토하여 표준이 아닌 쿼리들을 바꿀 DB에 방언에 맞게 바꿔주는 대공사를 해야한다..

3. 앞서 두문제와 달리 세번째 문제를 설명하기에 내가 아직 많이 부족하다고 생각하는데.. 일단은 내가 이해한 부분까지만 써보겠다. 객체지향의 객체와 달리 RDB에서 테이블의 관계는 보통 FK라고 부르는 키값에 의해 맺어진다. 하지만 이를 객체로 그대로 옮겨오면 이 키값은 기본자료형 타입의 필드가 된다. 객체지향에서 객체의 관계는 참조형 변수의 필드(참조값)나 상속과 같이 객체 그 자체와의 연결을 표현해야하는데, RDB의 테이블간의 관계를 그대로 객체에 적용하다보니 객체지향스럽지 못한 객체가 탄생하게 된다. 또한 객체지향의 몇가지 특징인 추상화, 캡슐화, 은닉화, 다형성 등등의 기능도 RDB의 테이블에는 존재하지 않기 때문에 이 역시 객체지향답지 못한 객체들을 만들어내는것이다.

🔑 위에 언급한 기존의 문제점들을 해결해 줄 수 있는 기술이 바로 JPA이다.

"그래, 문제점은 알겠어. 그래서 JPA가 저걸 어떻게 해결해주는건데?" 라는 의문이 생긴다면, 내 글의 목적은 달성한것같다. 앞으로 JPA를 실질적으로 어떻게 사용하는지 포스팅하며, 여기서 언급한 문제들을 하나하나씩 해결하여보자!