JPA를 왜 써야 할까 - 패러다임의 불일치

퀴즈로 생각해보기

SQL 중심적인 개발 방식에서 개발자가 'SQL 매퍼'처럼 반복적인 CRUD 코드를 작성하게 되는 근본적인 원인은 객체와 관계형 데이터베이스의 (이것) 때문입니다.

(이것) 은 무엇일까요?

 

 

일반적으로 데이터베이스를 다룰 때 우리는 어떤 액션을 취할까?

 

이렇게 엔티티의 관계를 시각적으로 나타낸 ERD를 보자.

 

이 구조에 맞게 생성된 데이터베이스는 "쿼리문"을 통해 조작된다.

쿼리문은 사실 굉장히 귀찮다.

왜냐하면 하나의 데이터를 가져오기 위해 단순반복적으로 작성해주어야하기 때문이다.

테이블이 하나의 데이터를 추가해야한다면? insert어쩌구저쩌구.. 뭐 긴 쿼리문을 작성해줘야 한다.

 

근데 이 데이터베이스를 스프링같은 프레임워크에서는 어떻게 활용할 수 있느냐?

다름아닌 객체형태다.

 

객체로 활용하기 위해 멤버라는 클래스를 만들고 객체를 찍어낸다.

그럼 우리는 이 객체를 데이터베이스에 들어갈 하나의 데이터라고도 생각할 수 있겠다.

 

자..그럼 이 객체와 데이터베이스는 어떻게 연결될 수 있을까?

 

 

이는 간단하지는 않은 문제다.
왜냐하면 여기에서 패러다임 불일치 문제가 발생하기 때문이다.

패러다임 불일치, 정확히 무엇이 문제일까?

객체와 관계형 데이터베이스가 서로 맞지 않는다는 '패러다임 불일치'는 크게 4가지 지점에서 발생한다.

• 상속: 객체지향 언어의 핵심 특징인 상속은 관계형 데이터베이스에 없는 개념이다. DB에서 상속 관계를 표현하려면, 부모와 자식 테이블을 나누고 조인으로 연결하는 등 복잡한 설계가 필요하다. 개발자가 이 모든 과정을 직접 처리하는 것은 매우 번거롭다.
• 연관관계: 객체는 다른 객체의 메모리 주소를 가리키는 참조(Reference) 를 통해 관계를 맺고, member.getTeam()처럼 자유롭게 객체 그래프를 탐색한다. 반면, 테이블은 외래 키(Foreign Key) 를 사용하며, 다른 테이블의 데이터를 보기 위해서는 반드시 조인(JOIN) 을 해야만 한다. 이 차이 때문에 객체 모델을 테이블에 저장하고 다시 조회하는 과정에서 수많은 변환 작업이 발생한다.
• 데이터 식별 방법: 객체는 member1 == member2 와 같이 메모리 주소값으로 동일성을 비교한다. 하지만 DB에서 같은 PK를 가진 데이터를 두 번 조회하면, 메모리에는 서로 다른 두 개의 객체가 생성될 수 있다. 이는 객체지향적인 관점에서 혼란을 일으킨다.

그래서 등장한 해결사, JPA (ORM)

이러한 패러다임 불일치 문제를 해결하기 위해 등장한 기술이 바로 ORM(Object-Relational Mapping) 이다.

 

이름 그대로 객체와 관계형 DB를 중간에서 매핑(연결)해주는 역할을 한다.

 

JPA(Java Persistence API) 는 이 ORM 기술에 대한 자바 표준 명세(규칙)인 것이다.

 

JPA를 사용하면 개발자는 더 이상 SQL 매퍼 역할을 할 필요가 없다!

이제 개발자는 데이터베이스가 아닌, 자신이 설계한 객체 모델에만 집중하면 된다.

JPA가 중간에서 마치 똑똑한 '자동 번역기'처럼 객체에 대한 조작을 분석하여 다음과 같은 일을 대신 처리하게 된다.

• 객체를 저장하면 알아서 INSERT SQL을 생성해 실행.
• 객체를 조회하면 알아서 SELECT SQL을 실행하고, 그 결과를 객체에 매핑
• 객체의 필드값을 바꾸면 알아서 UPDATE SQL을 생성해서 실행.

결론적으로 JPA는 개발자가 관계형 데이터베이스라는 '현실적인 제약'에 얽매이지 않고, 객체지향 프로그래밍의 장점을 최대한 활용하여 생산성과 유지보수성을 높일 수 있도록 돕는 강력한 도구다.