JPA

<Spring JPA> 1.1 SQL 중심적인 개발의 문제점

DeveloperRio 2020. 4. 6. 10:59

인프런을 통해 강의를 신청했다.

스프링 JPA 에 관한 글을 써보고 싶은데 관련 지식의 부족으로 방법을 고민하던 중, 강의를 들으면서 글을 먼저 써보자고 생각했다.

어떻게 보면 그냥 강의 정리노트에 불과할 수도 있지만, 최대한 내 생각까지 합친 글을 써봐야겠다.

 

일단은 글 제목은 강의 소제목들과 동일하게 하자. 나중에 검색도 편리할 것 같다.

 

1.1. SQL 중심적인 개발의 문제점

 

강사님은 우형에서 일하고 계시는 김영한님이다. 기존에 봤던 영상과 조금은 다르게 세련된 모습으로 나오셔서 놀랐다. 목소리 톤도 그동안 봤던 영상보다 약간 하이톤이었다. 뭔가... 자본적으로...(말을 아끼자)

 

첫번째 주제는 SQL 중심적인 개발의 문제점이다. JPA 가 무엇인지 언급하기 이전에 무엇이 불편했는지 왜 새로운 무언가가 필요했는지 근거를 설명하는 정도로 보면 될 것 같다. 

 

"지금 시대는 객체를 관계형 DB 에 관리"

 

맞다. 수많은 기업에서 일해보진 않았지만 적어도 내가 일해본 곳에서는 RDB 가 저장소의 대부분을 차지했다. 그도 그럴 것이 NOSQL 같은 경우는 메모리 기반이 많아, 중요한 정보라고 여겨지는 것들은 관계형 DB 에 저장해야 한다라는 생각이 많다. 나도 그렇게 생각하고 있다. 그렇다보니 대부분 관계형 DB 에 저장하고 있다.

 

그렇다보니, 자바를 사용하는 자바 개발자들로서는 저장하고자 하는 데이터는 여러 경로를 통해 들어와, 객체라는 것에 담았다가 그것을 다시 관계형 DB 에 저장하는 형태를 취하고 있다. 이러한 형식 때문에 데이터 베이스에 저장하기 위한 SQL 에 의존적인 개발을 해가고 있다. 자바 객체를 SQL 로, SQL 을 자바로 바꾸는 반복을 계속 해나가고 있는 것이다.

 

영한님은 이 과정에서 패러다임이 불일치한다는 점을 지적하였다. 우리는 객체라는 것을 다루면서 개발하고 있는데 실제 데이터를 쓰는 곳은 관계형 데이터를 다루고 있다. 그렇게 자바 개발자는 'SQL 매퍼' 로서의 역할을 충실히 해나가고 있다.

 

객체와 관계형 데이터베이스가 데이터를 보는 관점은 다르다. 만약 데이터 베이스를 객체와 같은 형태로 설계했다고 가정한다면 아래와 같은 형태일 것이다.

물론 당연히 이미지 출처는 김영한님의 강의 자료입니다!!!!!

 

앨범을 저장한다고 생각해보자. 상속관계니까 item 테이블에도 insert 해주고, album 테이블에도 insert 해줘야 할 것이다. 조회할 때는 join 을 해서 객체를 잘 만들어준다. 결론적으로 굉장히 귀찮고 복잡하고 도중에 실수하기 쉽다.

 

또한 앨범이라는 것을 Item 리스트에 저장한다고 생각해보자.

list.add(album);
Item item = list.get(albumId);

이런 과정을 SQL 매퍼가 된 개발자가 다 구현을 해야한다면? ... 귀찮다고 말하고 싶지만 그렇게 해왔다.

 

또한 아래와 같이 연관관계가 있는 데이터를 객체와 테이블로 함께 본다면,

물론 당연히 이미지 출처는 김영한님의 강의 자료입니다!!!! 

데이터를 저장할 때는 위에 했던 것과 동일하게 insert 를 두개 만들어서, Member 에 하나, Team 에 하나 저장할 것이다. 그리고 조회할 때는 join 을 통해서 조회하게 될 것이다. 

 

근데 만약에 연관관계가 Member에 Team 뿐만 아니라, Order, Delivery 등의 여러가지 연관관계를 가지고 있다면? 

조회된 Member 에 이러한 하위 데이터가 있는지 개발자는 처음 조회한 SQL을 찾아서 여러가지 연관관계가 전부 join 해서 호출한 것인지 확인해야 할 것이다. 그렇다고 해서 미리 전부 join 해놓을 수는 없다. 너무 많아서 성능에 문제가 있을 수도 있다.

 

또한 재미있는 건 그렇게 조회해서 객체로 표현된 데이터가 같은지 확인하는 것도 귀찮다. 왜냐면

String memberId = "100";
Member member1 = memberDAO.getMember(memberId);
Member member2 = memberDAO.getMember(memberId);

 

이 때 눈으로만 봐도 member1 과 member2 는 같은 회원이다. 하지만 객체상으로는 다른 객체다. 값을 비교해서 확인해야 한다.

 

 

--> 결론은 이렇다. 관계형 데이터베이스에 객체답게 모델링 할수록 매핑 작업만 늘어난다.

 

이렇게 JPA 가 등장하였다.

요구사항은 객체를 자바 컬렉션에 저장하듯이 DB에 저장할 수는 없을까?

 

JPA - Java Persistence API , 자바 진영의 ORM 기술 표준.

 

그렇다면 ORM 은 무엇인가? Object-relational mapping

 

이름이 거창한데, 아까 위에서 말한 개발자가 sql 매퍼 역할을 하고 있는 것을 대신 해주는데 굉장히 똑똑하게 해준다? 정도로 보면 될 것 같다. 다시 말하면 객체를 관계형 디비에 잘 매핑해준다!

 

객체는 객체대로 잘 설계하면 되고, 관계형 데이터베이스는 관계형으로 설계를 가능하게 한다.

그리고 다행히도 대중적인 언어에는 대부분 ORM 기술이 이미 존재한다.

 

여기까지 1.1. SQL 중심적인 개발의 문제점으로 인한 JPA 탄생을 다루었다. 

 

강의가 굉장히 깔끔하다. 왜 필요한지 이유가 명확하다. 물론 지금 JPA 를 사용하는 입장에서는 추후 나오겠지만 장단점이 있긴 하다. 하지만 객체 지향 개발을 하는 관점에서 SQL 에 대한 부담을 덜어준다는 측면으로 이해했다.

 

 

 

 

반응형