작업 일지#13 프로덕션 코드 리팩토링 - JPA로 이전

프로젝트 진행이 거의 7개월이 넘어간다. 알고리즘, CS 공부와 병행하는 상황이라, 프로젝트에 시간을 많이 투자하질 못해서 아쉽긴 하지만, 프레임워크만 잘 사용한다고, 애플리케이션 코드의 퀄리티와 이해도가 깊어지는 것은 아니니, 꼭 병행해야만 했었던 부분이었다. 어쨌거나, 기간이 길어지고, 그 기간 동안, 다양한 학습을 하면서, 진행했던 프로젝트 코드들을 살펴보니, 다음과 같은 문제점들을 발견했다.

1. 데이터 액세스 로직 구현의 경우, myBatis를 활용하였는데, 자바 객체와 릴레이션의 구조적인 차이로 인해 POJO 스타일의 코드를 일부 포기할 수 밖에 없었다. (ex. 자바의 경우, 의존하는 객체는 해당 인스턴스 변수를 참조하는 방식으로 구현해야 하는데, 릴레이션의 경우, FK를 참조해야 한다.)
2. 간단한 CRUD 로직부터, 복잡한 비즈니스 로직에 필요한 SQL 쿼리문을 전부 직접 매핑해야 하는데, myBatis의 경우 이 과정이 너무 번거롭다.
3. 프로젝트가 장기화되면서, JAVA에 대한 이해도가 달라지고 interface의 설계 구조를 개선하면서 진행하다 보니, 결과적으로는 도메인마다 일관적이지 않아, 코드의 생산성이 떨어졌다.

JPA를 선정한 이유는 다음과 같다.

1. 자바의 객체와 릴레이션의 차이를 해결해주어, 객체지향적인 코드를 좀 더 직관적으로 구현할 수 있게 도와준다.
2. 잘못 이해하고 사용하면, 성능 저하를 일으킬 수 있지만, 제대로 이해하고 사용한다면, 오히려 SQL mapper 보다 더 좋은 성능을 쉽게 확보할 수 있다. (특히, 영속성 콘텍스트의 캐시의 특성을 잘 이해하면, 좀 더 간결한 코드로 DB IO를 줄일 수 있다.)
3. spring-data-jpa가 의존하는 spring-data-common에서 제공하는 repository 계열의 검증된 인터페이스를 활용하여, 인터페이스 설계로 인해 발생하는 시간을 줄이고, 비즈니스 로직에 좀 더 집중할 수 있는 시간을 확보할 수 있다.