#1. 오늘의 학습 키워드

자바스프링부트로 백엔드에서 데이터를 저장, 조회 시 사용할 프레임워크 Mybatis 와 JPA 중에 선택

현재 회사에서 웹 백엔드 개발 시 MyBatis 를 사용해 PostgreSQL 디비에 있는 데이터를 조회, 저장 등을 하고 있다.
- 직접 쿼리를 작성하여, 자유도가 높게 데이터에 접근을 하고 있다.
이제 회사에 JPA를 도입하려 한다.
- 이미 구현된 모든 MyBatis 프레임워크를 통한 데이터 접근 코드를 JPA를 바꾸는 것이 아닌, JPA 프레임워크를 통해 접근하는 것이 더 적합한 데이터들에 대해서만 리팩토링을 하려 한다.
- 그럼 어떤 것이 더 적합한 지 확인해보자

#2. 공부한 내용

MyBatis
- SQL Mapper 기술을 제공한다.
  - 개발자가 작성한 SQL 실행 결과를 객체에 매핑 시켜주는 프레임워크
- 즉, 개발자는 데이터에 대한 일련의 작업을 수행하는 SQL 문을 xml 파일로 만들고, 해당 쿼리 단위로 매핑되는 메서드를 선언한 다음, 해당 메서드들을 데이터베이스에 접근하고 싶은 service 코드에서 호출하면 되는 것이다.
  - 개인적으로는 join 연산과 같은 복잡한 SQL 코드를 통한 데이터베이스 접근이 필요한 경우 MyBatis 프레임워크가 큰 이점이 있다고 느낀다.
  - 또한 대부분의 경우 SQL 쿼리의 조건문 같은 곳에 개발자가 원하는 변수를 집어넣고 싶은 니즈가 있는데, 이때 MyBatis의 동적 SQL 생성 기능을 통해, 해당 쿼리가 동적으로 실행될 때마다 서비스 코드에서 전달하는 파라미터에 따라 다른 조건의 부합하는 데이터들을 리턴시킬 수 있다.
    - 해당 파라미터들은 쿼리에 매핑되는 메서드에도 당연히 선언을 해줘야한다.
```
<select id = "getData" resultType = "dataDto">
	SELECT *
	FROM data
	WHERE data.id = #{dataId}
<select>
```
JPA (Java Persistence API)
- MyBatis 보다 좀 더 간편한 프레임워크로, SQL 쿼리를 개발자가 직접 생성하지 않아도 되게끔 도와준다.
  - 디비 데이터 단위로 자바 객체 (DAO) 를 매핑시켜준다.
- ORM(Object Relational Mapping) 기술을 제공한다.
  - 이 프레임워크로 상술된 객체와 디비의 매핑을 가능케한다.
    - 해당 기술은 명칭에서 보이는 것처럼 관계형(Relational) 디비와의 매핑이 가능하다.
    - 관계형 디비는 테이블당 스키마가 미리 지정이 되어있기에, 별도의 코드가 없이도, 해당 프레임워크로 자바 객체와 디비 엔티티를 그대로 매핑할 수 있다.
  - ORM는 자바의 지향점인 객체지향 관점에서 개발 할 수 있게 해주고, 기존 디비의 데이터 중심적 구조와의 간극을 줄여줘서, 디비와 자바 간의 불일치를 해소해준다.
- Hibernate
  - 이런 ORM 기술을 구현하여 만들어진 프레임워크
- 대부분의 CRUD 작업만 필요한 간단한 테이블 관리 작업에서는 JPA 프레임워크가 MyBatis 프레임워크가 보다 간편할 것 같다. 또한 JPA 는 테이블 스키마 구조가 바뀐다고 하여도, SQL 문을 다시 구현해야하는 유지보수 작업이 불필요하기에, 공수를 줄여준다.

참조:

https://www.elancer.co.kr/blog/view?seq=231

#3. 오늘의 회고

현재 회사에서 임직원, 조직, 휴가, 급여, 회계 관리 등 서비스를 개발하였다.
- 이중 회계 관리 서비스에서는 복잡한 쿼리를 통해 일련의 전표 데이터로 재무상태표, 손익계산서 등 보고서 형태의 데이터를 추출하는 작업을 진행하였다.
- 해당 작업은 복잡한 쿼리와 직접적인 SQL 제어가 필요하였기에 MyBatis를 통한 개발이 더 적합해보인다.
그러나 이외의 대부분의 작업에서는 JPA 가 MyBatis 를 대체하는 것이 좋아보인다.
- 전환하는 과정에서의 공수는 들겠지만, 추후 데이터 스키마가 변경될 것을 대비한 유지보수 측면에서의 공수 절약, 또한 새로운 기술을 배우고, 적용해볼 수 있다는 점에서 바꾸지 않을 이유가 없어보인다.

728x90