1장 JPA 소개

[minkukjo]

끄적끄적

• 저자는 소개에서 JPA와 같은 ORM 프레임워크가 가져다주는 객체지향형 코드가 얼마나 생산성을 높여주고 직관적인지를 설명해주고 있다.
  • 논의 포인트 - 다른 분들도 실무에서 ORM 프레임워크를 그렇게 느끼는지? 궁금.
  • 개인적으로는 JPA가 막강한 것은 맞지만, 실무에서 복잡한 쿼리를 구현할 때는 오히려 ORM으로 처리하는 것이 성능이 떨어지는 경우도 많았음. ( fetch 조인의 한계와 실무에선 객체그래프 탐색보단 N+1 문제를 해결하는데 힘을 더 쓰는 느낌임. )
  • 그러나 여기에 대해서는 여전히 논란의 여지가 많음. "그렇게 복잡한 쿼리를 짜야지만 수행할 수 있는 요구사항이라면 처음부터 DB 설계가 잘못된 것은 아닐까?"라는 이야기를 듣고 생각이 많아짐.
  • 그럼 JPA 안쓰고 뭐 쓸건데? 라고 하면 딱히 할말도 없음...

JPA를 사용함으로써 얻을 수 있는 점

아래는 책에서 나온 JPA를 사용하면서 얻을 수 있는 이점에 대해 정리 + 내 생각을 정리했음.

생산성

• DB 모델을 엔터티로 관리할 수 있으므로 불필요한 SQL 작성 대신 코드로 처리할 수 있기 때문에 생산성이 올라감. ( 인정 ) 또한 DB 중심의 설계에서 객체 중심의 설계로 중심을 옮길 수 있다는 점도 인정.

유지보수

• 아무래도 SQL은 유지보수가 어려운 반면, 코드로 관리되는 JPA는 유지보수 하기가 쉬움.
• 그러나 그것은 JPA를 정말 잘 썼을 때 얘기고, 오히려 로직 중간에 갑자기 detach를 한다던가 하는 식으로 동작하는 코드는 보기가 더 어려울 수 있음.
• 저자는 객체지향의 장점을 누릴 수 있기 때문에 오히려 유지보수성이 올라간다는 말도 맞는 말.

패러다임 불일치 해결

• JPA는 상속, 연관관계, 객체 그래프 탐색, 비교하기와 같은 패러다임 불일치를 깔끔하게 해결해준다는 점에서 분명히 좋음.

성능

• 사실 이 부분은 김영한님도 성능 향상을 장점으로 넣기는 좀 애매하다고 강의에서 언급하시긴 했음.
• 실제로 약간 성능이 더 좋아지긴 함 ( Entity Manager에서 관리되는 Entity면 조회쿼리를 두 번할걸 한 번만 한다던가 하는... ) 근데 미미함.

데이터 접근 추상화와 벤더 독립성

• 사실 이게 분명히 장점은 맞는데, 반대로 이렇게 물어보고 싶음.
• "실무에서 운영중인 DB의 솔루션이 바뀌는 경우가 얼마나 빈번함?"
• 물론 아주 가아아아끔 일어날 수 있는 일에, 대공수를 쓰지 않아서 좋을 수도 있지만, DB가 바뀔 정도의 변경이면 차라리 애플리케이션 코드도 새로 짜는게 더 낫지 않나 라는 생각임. ( 테이블 설계도 다시하고... )

1장 후기

• 확실히 1장이라서 대부분 익숙한 내용이었음.
• 다만 다시 한 번 JPA에 대해서 상기하는 기회가 되었고, JPA를 왜 사용하기 시작했는지에 대해서 한 번 더 생각할 수 있었음.
• 예약팀에 오면서 큰 데이터와 다양한 테이블 간의 조인을 해야할 일이 많아졌는데, JPA로는 이러한 문제를 해결하기엔 다소 어려움이 있었음.
• 그러나 단순 CRUD를 사용하기엔 이만한게 없다는 느낌. ( 전 직장에서 이 부분에 대해서 반대 의견을 가진 분도 있었음. )

[LOG-INFO]

끄적끄적

1. SQL + JDBC API 직접 작성
   • SQL과 JDBC API를 매번 직접 작성해야함
     • 지루하고 반복적인 CRUD SQL 작성
     • DB vendor에 의존
   • 객체지향적이지 않음 (점점 유지보수 어려워짐)
2. SQL Mapper 사용 (iBatis)
   • JDBC API는 사용하지 않아도 되지만, 여전히 SQL에 의존
   • 여전히 객체지향적이지 않음
3. CRUD SQL 자동 생성 툴 개발
   • 복잡한 요구사항에 대한 한계
   • 여전히 객체지향적이지 않음
4. 객체모델링
   • 도메인 로직은 객체지향적이지만, 객체모델링을 SQL로 풀어내는 데 너무 많은 코드와 노력 필요 (패러다임 불일치)
5. JPA (Java 진영의 ORM 표준)
   • 객체지향과 RDB 간의 패러다임 불일치를 대신 처리해줌
     • 객체지향적으로 개발할 수 있어 생산성과 유지보수/테스트 용이성 증가

회상

• 1.1.2. SQL에 의존적인 개발 에서 언급한 내용은 실제로 겪어봤기 때문에 너무 공감됨
  • 사이드 프로젝트에서 이 때문에 몇 번이고 수정해서 배포했던 경험이 있음
  • 특히 좀 오래된 프로젝트에서 MyBatis로 SQL 매핑을 해서 사용하고 있었는데, 컬럼 하나 추가된다고 하면 관련 SQL들과 그것을 사용하는 로직들을 전부 찾아서 몇 번이고 검토해야 했음
  • • Join을 할 때도 골치 아프긴 했지...
  • 책에 나온 것처럼 Entity에 대한 신뢰도가 낮아지고, 도메인 계층 - 데이터 계층 분리가 사실상 어려움
    • "이 메서드에 매핑된 SQL 실행하면 이 연관 객체의 필드 모두 가져오는거 맞아?"를 매번 직접 SQL 보고 확인해야함

[2rohyun]

느낀 점

---

• 한 2~3년 전..?쯤 보았던 김영한님의 JPA 강의가 새록새록 기억나는 1장이였다.
• 당연하게 사용하던 JPA 가 기존의 어떤 문제를 해결하기 위해 등장했고, 실제로 좋은 점은 무엇이였는지 다시 한 번 떠올릴 수 있는 장이였다.
• db 와 app 간의 레이어를 하나 더 두어서 dialect 로 직접적인 sql 과의 의존성을 끊어내는 것이 아주 큰 장점이라는 생각이 든다.
• 물론 단순 CRUD 는 직접 쿼리를 작성하지 않아도 되어서 아주 편한 것도 큰 장점이라는 생각이 든다. ( + 쿼리를 직접 작성할 때 휴먼에러로 발생하는 런타임 에러도 방지할 수 있고.. compiled language 를 사용하면서 런타임에만 문제가 발생하는지 확인할 수 있는건 그냥.. 막연하게 불안함)
• 난 그렇게 헤비하게 JPA 를 사용하진 않지만.. (연관관계 매핑, 조인 등.. ) 헤비하게 사용할 때 JPA 의 내부 동작 방식을 잘 모르고 사용한다면 크리티컬한 문제를 야기할 수 있다는 것이 제일 단점이라고 생각한다. 이건 JPA 뿐 아니라 Spring 전체에서도 관통되는 이야기라고 생각함. 사용하기 편하게 추상화 해놓을수록 제대로된 이해 없이 사용한다면 위험한 것..

[MinJunKweon]

느낀점

• Dialect라는 네이밍은 진짜 곱씹을수록 잘지은 이름 같음
• 단순 반복적인 CRUD 쿼리 작성은 확실히 비효율적임
• SQL 의존적인 개발과 레이어 분할이 어려운 것은 매우 공감하는 부분. 아마 모든 백엔드 개발자가 느끼고 있는 부분이 아닐까 싶음
• 태생적으로 RDB와 OOP는 패러다임이 다르기 때문에 이 간극을 해결하기 위해 ORM을 쓰는 것.
  • => 이 말 자체에서 이미 장단점이 드러나는 말이라고 생각함.
  • OOP의 입맛에 맞게 RDB를 사용하자"를 목적으로 사용하는 게 ORM인데, 세세히 들어가다보면 OOP 컨셉에 맞추려고 어거지로 맞춰야하는 부분이 필연적으로 발생해서 "잘" 사용하지 않으면 오히려 생짜 쿼리 날리는 게 나을 수 있음.
• 그런 의미에서 프로젝트 참여자 모두가 ORM에 대해서 잘 알고 있어야 한다는 장벽이 있음 => 이게 회사에서 사용하기 매우 큰 진입장벽인 듯
• 실제로 JPA를 공부하다보면 이 코드가 실제로 어떤 쿼리로 변환되는지를 알고있어야 해결되는 이슈들이 꽤 많았음
• 코드를 실행했을 때 어떤 쿼리가 발생하는지 옵션을 줘야만 볼 수 있고, 프로덕션 레벨에서 어떤 쿼리가 실행됐는지도 파악하기 쉽지 않음
• 그리고 보통 API 성능에 영향을 미치는 부분 대부분이 DB쿼리라고 생각하는데, 이걸 블랙박스로 두고 사용한다는 게 위험하지 않나라는 생각이 들었음
• 이러이러한 경험을 통해 느낀건 "이럴 바에 개발자가 직접 쿼리를 해서 다 컨트롤하는 게 낫지 않을까?" 싶은 생각도 들었음
• 위에서부터 비판만 했으나.. JPA를 씀으로서 얻을 수 있는 생산성과 편의성은 매우 공감하는 부분이고, 개선이 필요하다고 뼈저리게 느끼기 때문에 JPA가 나쁘다고 말하고 싶지는 않음
• JPA를 제대로 공부해본 적도 없고 그렇게 잘다루는 편도 아니기 때문에 이번 스터디가 상당히 기대되고,
• 이 책을 통해서 위에서 언급한 내 걱정과 비판들이 바뀌는 계기가 되길 기대하는 중ㅎㅎ

[HaeUlNam]

느낀점

SQL 의존성 개발을 보면서 느낀 것이

• 외부 의존성 제어를 잘 해야지 내부 도메인 로직 변경을 최소화 할 수 있다는 생각이 다시 한번 들었다.
• Redis cache sdk 개발을 하면서, spring 구현체에 의존했었는데 이것 때문에 Spring version up을 하는데 블로커 요소였다.
• 어떤 Module/Component를 신뢰할 수 있도록 개발하는 건 항상 어렵다는 생각이 든다.

• 예전에 배치성으로 Hive에 저장하고 가져오는 개발을 했었을 때, SQL을 일일이 수정했어야 해서 힘들었던 기억이 있다.. 프로젝트에서 사용되던 JDBC API을 사용하는 것 외에 더 좋은 방법이 뭐가 있을까 고민했었던 기억이 난다.

• 편하게 바꾼다는 것이 항상 좋은 것인가라는 생각도 든다. 물론, 빠르게 바꿀 수 있어서 개발 생산성이 올라가는 것은 좋지만, 이해도가 낮은 상황에서 빠르게 바꾸기만 하는 상황은 지향하면 좋을 것 같은 생각이 든다.

정리

SQL 의존적 개발

• 간단한 요구사항으로도 많은 곳의 SQL이 변경되어야 하는 경우가 있다
• 진정한 의미의 계층 분할이 어렵다
• 엔터티를 신뢰할 수 없다.

JPA?

• JPA는 표준 인터페이스로서 JAVA ORM 기술에 대한 API 표준 명세
• JPA를 구현한 ORM 프레임워크는 하이버네티트, EclipseLink, DataNucleus 등이 있는데, 하이버네이트가 가장 대중적이다.

JPA를 사용해야 하는 이유

• 생산성: 보일러 플레이트 코드나 CRUD SQL을 직접 작성 X
• 유지보수: SQL 직접 다루었을 때는 변경이 일어났을 때 변경을 해야 하는 부분이 많았는데, JPA를 처리했을 때는 수정해야 하는 코드가 줄어듬
• 패러다임 불일치 해결: 상속, 연관 관계, 객체 그래프 탐색, 비교하기와 같은 패러다임 불일치 해결
  • 연관관계: 객체는 참조 방향으로만 조회가 가능하고, 데이블은 외래키를 통해 어느 방향이든 가능
  • 객체 그래프 탐색: 실제로 어디까지 객체 탐색이 가능한지 알아보려면, SQL을 확인해야 함. JPA에서는 지연로딩으로 가능.
  • 비교하기: 객체의 동일성(’==’)/동등성(’equals’)을 JPA에서 보장해줌.
• 성능 최적화
• 데이터 접근 추상화와 벤더 독립성: 특정 DB 기술에 종속되지 않도록 한다