[JPA 기본] JPA란 👨‍💻

JPA 소개

---

기존 JDBC를 사용했을 때 애플리케이션 비즈니스 로직보다 SQL과 JDBC API를 작성하는 데 더 많은 시간을 보냈다. 물론, 코드 중복을 없애기 위해서 Ibatis나 JDBCTemplate 같은 SQLMapper를 도입했지만 여전히 반복해서 작업을 해야 했다.

또한 데이터를 테이블에 맞춰서 보내야 했기 때문에 객체 구조는 테이블 형태에 의존적이게 될 수밖에 없었고 설계 또한 객체 중점이 아닌 테이블 중점으로 설계가 될 수밖에 없었다.
즉, 객체지향 모델링에 대한 장점을 포기하고 데이터 중심 모델로 설계 패러다임이 바뀐 것이다.

하지만 이러한 문제점을 해결하고자 만들어진 것이 있었으니 바로 ORM 프레임워크다. ORM 프레임워크는 객체와 관계형 데이터 베이스 간의 차이를 중간에서 해결해 주는 역할을 하고 있다.

JPA는 자바 ORM 기술 표준이다. 반복적인 코드를 줄이고 개발자는 개발에 조금 더 집중할 수 있는 환경을 만들어준다.

위 그림과 같이 JPA는 애플리케이션과 JDBC 사이에서 동작한다.

ORM (Object Relation Mapping)

• 객체와 관계형 데이터베이스를 매핑해주는 기술
• 객체와 테이블을 매핑해서 패러다임 불일치 문제를 개발자 대신 해결해 준다.

SQL을 직접 다룰 때의 문제

---

일반적인 JDBC를 이용했을 때 DAO의 처리 방법은 아래와 같다.

1. SQL 작성
2. JDBC API를 사용해서 SQL 실행
3. 실행 결과를 알맞게 처리 (조회 기능일 경우 객체로 매핑)

위 3가지 과정은 CRUD에서 모두 동일한 절차이며 이는 반복적인 작업이다. 또한 Connection하고 이를 Close 해주는 작업까지 포함해야 한다. 물론 JDBCTemplate에서 Connection과 Close 작업에 대한 반복을 해결해 주었지만, 여전히 SQL 반복적인 코드를 생산할 수밖에 없다.

✅ 참고

member라는 객체를 DB에 저장하고자 하면 member 필드들을 꺼내온 뒤 SQL에 삽입하는 작업을 진행해야 한다. 
그리고 이러한 작업은 앞서 말한 3가지 절차를 거쳐야 한다.        

하지만 대상이 DB가 아닌 Collection의 List라고 가정을 해보자

List<Member> list = new ArrayList(); 
list.add(member);

우리는 단순히 리스트에 추가하기만 하면 된다. 
이것이 데이터 중심이 아닌 객체지향 중심의 개발이고 우리는 이와 같은 처리를 하기를 원한다.   

SQL에 의존적인 개발

SQL을 이용한 DAO를 완성했다고 가정하자. 어느 날 갑자기 클라이언트 측에서 새로운 기능을 요구해서 테이블에 새로운 필드를 추가시켜야 하는 상황이 발생했다. 이럴 경우 기존에 짜인 관련된 코드를 모두 수정해야 한다.

1. DTO 수정
2. DAO SQL 쿼리 및 statement 수정
3. 기타 의존된, 연관된, 관련된 코드들 수정

결론적으로 SQL 문을 바꾸게 됨으로써 객체의 필드를 바꾸고 이에 관한 코드도 변경해 주어야 한다. 만약 이렇게 관련된 코드가 100개, 1000개 있다면 전부 다 바꿔줘야 한다.

객체가 연관된 코드, 객체들을 사용할 수 있을지 없을지는 사용하는 SQL에 달려 있다.
이런 방식의 가장 큰 문제점은 데이터 접근 계층을 사용해서 SQL을 숨겨도 어쩔 수 없이 DAO를 열어서 어떤 SQL이 실행되는지 확인해야 한다는 점이다.

이러한 SQL에 의존적인 엔티티들은 변동이 심하므로 개발자가 신뢰할 수 없으며 물리적으로 SQL과 JDBC API를 분리했다 하더라도 논리적으로 강한 의존성을 가지고 있다는 것이다.

애플리케이션에서 SQL을 직접 다룰 때 발생하는 문제점을 요약하자면 아래와 같다.

• 진정한 의미의 계층 분할이 어렵다.
• 엔티티를 신뢰할 수 없다.
• SQL에 의존적인 개발을 피하기 어렵다.

JPA와 문제 해결

JPA는 기존에 개발자가 직접 SQL 구문을 기술하고 사용하는 것이 아닌 JPA API를 이용함으로써 JPA가 개발자 대신에 적절한 SQL을 생성해서 데이터베이스에 전달한다.

즉, 개발자는 JPA API만 사용하면 SQL 구문을 기술하지 않아도 된다.

• 저장 기능
  • persist(Entity) : 객체를 데이터베이스에 저장한다. INSERT SQL

• 조회 기능
  • find(Entity.class, id) : 객체 하나를 데이터베이스에서 조회한다. SELECT SQL

• 수정 기능
  • JPA는 별도의 수정 메서드를 제공하지 않는다.
  • 영속성 컨텍스트를 이용해서 조회한 데이터 엔티티의 값을 수정하면 트랜잭션을 커밋 할 때 같이 수정

• 연관된 객체 조회
  • JPA는 객체를 필드로 가질 수 있기 때문에 조회된 데이터에서 연관된 특정 객체를 추출할 수 있다.

패러다임 불일치

---

애플리케이션은 발전하면서 그 내부의 복잡성도 점점 커진다.
즉, 지속 가능한 애플리케이션을 개발하는 일은 끊임없이 증가하는 복잡성과의 싸움이다.
복잡성을 제어하지 못하면 결국 유지 보수하기 어려운 애플리케이션이 된다.

객체지향 언어에서는 상속, 다형성, 추상화, 정보 은닉 등을 지원해 주며 이를 이용해 복잡성을 제어해 준다. 하지만 데이터 중심이 되어버린 객체는 이러한 객체지향 언어의 장점을 사용하기 힘들어지고 이로 인해 복잡성도 크게 증가한다. 객체가 단순하면 상관이 없지만 객체가 상속받았거나 다른 객체를 참조(필드로 사용) 하고 있다면 객체의 상태를 저장하기는 쉽지 않다.

예를 들면 회원 객체를 저장해야 하는데 회원 객체가 팀 객체를 참조하고 있다면 팀 객체도 같이 저장해 줘야 한다. 만약 그러지 않을 경우 회원 객체는 팀 객체와의 연관성을 잃어버리는 문제가 발생한다.

그래서 객체 지향 언어의 장점을 유지하고자 직렬화, 역직렬화로 데이터를 저장하는 것을 지원하지만 이 방법은 직렬화된 객체를 검색하기 어렵다는 문제점이 있으므로 현실성이 없고 사용하기 까다롭다.

그렇다면 가장 나은 방법은 관계형 데이터베이스에 객체를 저장하는 것인데 관계형 데이터베이스는 데이터 중심으로 구조화되어 있고 집학적인 사고를 요구한다.

즉 추상화, 상속, 다형성 같은 개념이 없고 이로 인해 객체도 데이터 중심으로 설계를 하게 되었다.

간략하게 정리하자면 객체와 관계형 데이터베이스는 지향하는 목적이 서로 다르고 둘의 기능과 표현도 다르므로 이를 패러다임 불일치라 말한다.

• 객체 : 다양한 객체의 장점을 이용한 복잡성 해소
• RDB : 데이터 중심 구조화 및 집합성 강조

애플리케이션은 자바라는 객체지향 언어로 개발하고 데이터는 관계형 데이터베이스에 저장해야 한다면, 결국 패러다임의 불일치 문제를 개발자가 중간에서 해결해야 한다.

이제 이러한 패러다임 불일치를 개발자가 해결하는 방법과 문제점을 살펴보자

상속

객체는 상속이란 개념이 있지만 테이블은 없다. 그나마 데이터베이스 모델링에서 이야기하는 슈퍼 타입 서브 타입 관계를 사용하면 상속과 가장 유사한 형태로 테이블을 설계할 수 있다.

class Item{}
class Album extends Item{}
class Movie extends Item{}
class book extends Item{}

하지만 이렇게 분리한 상태에서 SQL을 수행할 경우 최소 2번은 수행해야 한다.

예를 들어 Album 객체의 값을 데이터베이스에 넣어줄 때 Album 객체는 Item 객체를 상속받고 있기에 Item 관련 데이터도 같이 추가되어야 한다.

하지만 객체로서는 연관이 있지만 위 같은 데이터베이스 구조에서는 Album과 Item 테이블은 분리되어 있기에 아래와 같은 작업을 거쳐야 한다. 이는 조회, 수정, 삭제도 마찬가지다.

INSERT INTO Item ...
INSERT INTO Album ...

연관관계

객체는 참조를 사용해서 다른 객체와 연관관계를 가지고 참조에 접근해서 연관된 객체를 조회한다.
반면에 테이블은 외래키를 사용해서 다른 테이블과 연관관계를 가지고 조인을 사용해서 연관된 테이블을 조회한다.

객체

class Member{

    Team team; // 참조  
    
    ...
    
    Team getTeam(){
        return team;
    }
    
}

객체에서는 한 번에 처리가 가능한 것을 테이블에서는 2번에 나눠서 처리해야 되는데 방식은 아래와 같다.

User user = findUser();
Team team = user.getTeam();

기존 객체를 이용한 방식은 단순하게 객체 내의 요소들을 이용하면 쉽다.

User user = userDao.findUser();
Team team = TeamDao.findTeam(user.getTeamId());

하지만 이를 데이터베이스 기준으로 코드를 짠다면 위와 같이 DAO를 2개 생성하고 2번 데이터베이스와 연결하여 작업을 수행해야 한다. 이유는 앞서 말했듯이 테이블이 2개로 구분되어 있기 때문이다. (테이블을 2개로 나눈 것이 잘못이라는 얘기는 아니다.)

이렇듯 객체와 테이블의 패러다임 불일치성으로 인해 위와 같이 접근을 하게 되고 불필요한 연산 과정을 사용하게 된다는 문제점이 있다.

그렇다고 객체지향적으로 디자인하는 것이 완벽하게 좋다는 얘기는 아니다. DB에서는 User가 기준이든 Team이 기준이든 JOIN을 이용하여 데이터를 찾을 수 있지만 객체에서는 User에서 Team을 도출할 수 있지만 Team에서 User를 도출하기는 힘들다.

연관관계 - 객체를 테이블에 맞추어 모델링

class Member{
    Long teamId; // 참조  
    ...
}

class Team{
    Long id;
}

이렇게 사용할 경우 테이블에서 저장하거나 조회할 때는 편리하다. 왜냐하면 각각의 객체를 각각의 테이블에 대응하여 처리해 주면 되기 때문이다.

하지만 사실 Team_ID 외래 키값을 보관하는 teamId 필드에는 문제가 있다. 연관된 Team을 찾는 연산이 추가적으로 생기던가 잘못된 코드로 변경될 경우 연관된 Team도 같이 변형하거나 불일치성을 띠지 않게 관리해야 하는 복잡성이 생긴다. 이런 방식을 따르게 되면 객체 지향의 장점을 잃어버리게 되는 것이다.

연관관계 - 객체를 객체지향에 맞추어 모델링

class Member{
    Team team; // 참조  
    
    ...
    
    getTeam(){
        return team;
    }
}

class Team{
    Long id;
}

이처럼 객체지향적으로 모델링을 할 경우 객체 간의 연관성에 대한 문제는 없어진다. 대신 테이블 기준으로 다시 본다면 저장하거나 조회하기는 쉽지 않다. 왜냐하면 하나의 객체를 쪼개서 각각의 테이블에 나누는 로직을 생성해 주어야 하기 때문이다. (이 같은 작업을 데이터베이스에서 하던가 DAO에서 추가로 로직을 짜주어야 한다.)

객체 모델은 외래 키가 필요 없고 단지 참조만 있으면 된다.
테이블은 참조가 필요 없고 외래 키만 있으면 된다.

그리고 결국은 이 같은 패러다임을 맞추기 위해서 개발자가 중간에서 변환 역할을 해야 한다. 이러한 변환 역할을 예를 든다면,

member.getTeam().getId; 

위처럼 객체 내의 id 필드를 통해 ID 값을 이용한 테이블 참조를 진행하면 된다.

객체 그래프 탐색

회원이 소속된 팀을 조회할 때는 참조를 사용해서 연관된 팀을 찾으면 되는데, 이와 같은 과정을 객체 그래프 탐색이라 한다. 즉, 객체가 참조를 이용해서 연관된 객체를 찾는 것을 의미한다.

다음은 객체 그래프를 탐색하는 코드이다.

member.getOrder().getOrderItem()... 

하지만 다음 SQL을 사용하여 member와 team에 대한 데이터만 불러올 경우, Order와 같이 다른 객체 그래프는 데이터가 없으므로 null 값을 가지고 이는 탐색을 할 수 없게 한다.

SELECT M.*, T.*
    FROM MEMBER M
    JOIN TEAM T ON M.TEAM_ID = T.TEAM_ID

// null -> member와 team에서만 했으므로 order_id 값이 있더라도 조인을 안 해서 데이터가 없다.
member.getOrder();

즉, SQL을 직접 다루면 처음 실행하는 SQL에 따라 객체 그래프를 어디까지 탐색할 수 있는지 정해진다. 이것은 비즈니스 로직에 따라 사용하는 객체 그래프가 다른데 언제 끊어질지 모를 객체 그래프를 함부로 탐색할 수는 없기 때문에 개발자에게는 큰 제약이다. (SQL 쿼리랑 이것을 사용하는 메서드에 대해서도 숙지하고 관리해야 하는 어려움이 있다.)

public void process(){
    Member member = memberDAO.find(memberId); // SQL 실행
    member.getTeam(); // 앞선 쿼리로 Team 객체 그래프를 탐색 가능한가? 
    member.getOrder().getDelivery(); // Order 객체 그래프 탐색 가능한가?, 가능하도라도 Delivery는?     
}

위 코드와 같이 언제 끊어질지 모르기 때문에 결국에는 DAO를 열어서 SQL을 직접 확인해야 한다. 앞서 말했듯이 SQL에 의존적인 개발로 논리적으로 종속되어서 발생하는 문제이다.

반대로
객체 그래프 탐색을 위해서 모든 데이터를 JOIN 하여 가져오는 것은 성능적으로 많은 이슈가 있다. 결국 상황에 따라서 DAO와 SQL 쿼리문을 만들고 사용해야 하고 이를 숙지 및 관리해야 한다.

비교

데이터베이스는 기본 키의 값으로 각 ROW를 구분한다.
반면에 객체는 동일성 비교와 동등성 비교라는 2가지 비교 방법이 있다.

• 동일성 비교 : == 비교, 객체의 주소 값을 비교
• 동등성 비교 : equals() 비교, 객체 내부의 값을 비교

따라서 테이블의 로우를 구분하는 방법과 객체를 구분하는 방법에는 차이가 있다.

String sql = "SELECT * FROM MEMBER WHERE MEMBER_ID = ?";
..Member를 얻기 위한 DB 로직..
return new Member(DB 로직을 통해 얻은 값);

Member member1 = memberDAO.getMember(100);
Member member2 = memberDAO.getMember(100);

System.out.println(member1 == member2) // 메모리 주소가 다르므로 false 출력 

데이터베이스 관점으로 보면 둘은 같은 데이터이지만 자바 코드를 통해서는 둘은 같은 데이터가 아니라고 나온다. 물론 equals()를 사용하여 동등성에 대한 true를 얻을 수 있지만 동일성에 대해서 false 값을 가져야 된다는 것이 동일한 데이터임에도 그 순리가 맞지 않다

Member member1 = list.get(0);
Member member2 = list.get(0);

System.out.println(member1 == member2) // 메모리 주소가 같으므로 true 출력   

그리고 이러한 데이터를 DB가 아닌 객체지향 관점으로만 본다면 true 값을 가질 것이다.

이러한 패러다임 불일치를 해결하기 위해서 로우를 조회할 때마다 같은 인스턴스를 반환하도록 구현하는 것은 쉽지 않다. 여기에 여러 트랜잭션이 동시에 실행되는 상황까지 고려하면 문제는 더 어려워진다.

JPA를 이용한 패러다임 해결

---

JPA와 상속

상속된 객체를 테이블 분리를 이용해 분리하였기에 우리는 2번의 SQL 구문을 사용했다.
JPA는 이러한 상속과 관련된 패러다임을 해결해 주는데 마치 자바 컬렉션에 객체를 저장하듯이 JPA에 객체를 저장하면 된다.

기존 방식

public void save (Item item, Album album){
    String insertSQL1 = "INSERT INTO ITEM...";
    String insertSQL2 = "INSERT INTO ALBUM...";
    ...
    st.executeUpdate(insertSQL1);
    st.executeUpdate(insertSQL2);
    ...
}

JPA 방식

public void save(Album album)(){
    jpa.persist(album);
}

이렇듯 단순 album 객체를 이용하여 상속에 대한 불필요한 연산을 줄일 수 있고 객체지향의 장점을 이용할 수 있다.

JPA와 연관관계

JPA는 연관관계와 관련된 패러다임 불일치 문제를 해결해 준다.

member.setTeam(team);
jpa.persist(member);

개발자는 기존 객체지향 모델을 그대로 사용하면서 JPA API를 사용해 주기만 하면 된다. JPA는 참조를 외래 키로 변환해서 적절한 INSERT SQL을 데이터베이스에 전달한다. 객체를 조회할 때 외래 키를 변환하는 일도 JPA가 처리해 준다.

Member member = jpa.find(Member.class, memberId);
Team team = member.getTeam();

JPA와 객체 그래프 탐색

기존 객체 그래프 탐색은 SQL에 따라 탐색할 수 있는 객체의 범위가 제한되었었다. (JOIN 안 하면 못 가져온다.) 하지만 JPA를 이용하면 객체 그래프를 마음껏 탐색할 수 있다.

Member member = jpa.find(Member.class, memberId);   
member.getOrder().getOrderItem().getOrderOptionGroup().getOderOption()...

JPA는 연관된 객체를 사용하는 시점에 적절한 SELECT SQL을 실행한다. 이 기능은 실제 객체를 사용하는 시점까지 데이터베이스 조회를 미룬다고 해서 지연 로딩이라고 한다. JPA는 지연 로딩을 투명하게 처리하기에 추가적으로 JPA와 관련된 어떤 코드도 직접 사용하지 않는다.

즉, 사용하는 시점에 조회를 실행한다고 보면 된다.

// 처음 조회 시점에 SELECT MEMBER SQL
Member member = jpa.find(Member.class, memberId);

Order order = member.getOrder();
order.getOrderDate(); // Order를 사용하는 시점에 SELECT ORDER SQL 

패러다임의 불일치 정리

객체 모델과 관계형 데이터베이스 모델은 지향하는 패러다임이 서로 다르다. 문제는 이 패러다임의 차이를 극복하려고 개발자가 너무 많은 시간과 코드를 소비한다는 점이다. 그리고 더 어려운 문제는 정교한 객체 모델링을 할수록 불일치 문제를 해결하기 위한 노력이 더욱 필요하다

JPA는 이러한 패러다임의 불일치 문제를 해결해 주고 정교한 객체 모델링을 유지하게끔 도와준다. 무조건 좋다는 말은 아니지만 개발자는 이로 인해 더욱 개발에만 집중할 수 있게 되었다.