JPA 장점과 단점

장점
- 영속성 컨텍스트가 1차캐시 역할을 해주는것도 있지만 서비스로직 실패시 롤백되는게 엄청난 장점임. 예상치 못한 상황에서 데이터가 오염되는 상황을 최대한 방지할수 있음
- 프로시저 수준의 복잡한 sql을 코드로 깔끔하게 정리 가능. 코드를 사용해 비즈니스 목적을 달성하고 객체지향적인 추상화가 가능하다는건 큰 장점이고 유지보수가 매우 간편해짐
- 단순쿼리로 여러개의 결과를 뽑아낸 후 서비스로직에서 가공이 가능해짐. db cpu의 부하가 극도로 낮아지고 메모리에서 데이터 가공이 가능해서 성능 이점과 코드의 재사용성이 매우 높아짐

단점
- jpa의 기본 페치 방법인 지연로딩으로 인하여 러닝커브가 높아지고 다수 테이블 조인시 신경써야할게 많음. fetch join이나 fetch size옵션을 통해 적절한 튜닝 필요
- 벌크 인서트나 업데이트에 취약함. 영속성 컨텍스트의 사이즈가 일정 수준을 넘어가면 성능이 매우 저하됨. 이러한 경우 spring data jdbc를 사용하여 jpa를 사용하지 않고 jdbc 드라이버에 직접 쿼리를 날려주는게 필요함.

- DB설계 제대로 안할시 안쓰는게 나음.

결론
- msa가 확산되고 웹서비스의 경향이 매우 짧은 트랜잭션을 여러개 발생시켜 유지보수와 성능을 극대화하고 보상트랜잭션을 이용하여 데이터의 정합성을 보장하는 형태로 가고 있음. hikari cp같은 고성능의 커넥션풀을 잘 활용하기 위해선 커넥션을 짧게 점유하고 반환하는 형태의 트랜잭션 고려가 필요함.
- 인력의 턴오버가 잦은 업계 특성상 코드의 생명력을 높이고 유지보수의 이점을 최대한 취하기 위해 orm의 사용이 늘고 있음
- jpa는 여러 orm중에서도 정점에 서있다고 보고 잘 사용한다면 엄청난 이점을 얻을수 있다고 생각함. 코드레벨에서 비즈니스 로직을 고민하기 때문에 개발자의 개발역량이 매우 향상되고 객체지향적인 설계가 가능해짐.
- 안쓸 이유가 절대 없음. 개인적으로 긴 쿼리 및 프로젝션, 로직을 쿼리에 의존하는 개발형태를 매우 혐오함. 쿼리가 길어질수록 신규 요구사항의 수용은 거의 불가능해지고 서비스가 고도화 될수록 기능추가가 불가능한 수준임. 건드리면 버그터지기 일쑤고 담당인력 나가면 쿼리읽는데 한세월 걸려 생산성이 매우 떨어짐.