티스토리 뷰
자바의 ORM 표준 기술로 애플리케이션과 JDBC API 사이의 인터페이스 역할을 합니다.
여기서 ORM(Object-Relational Mapping)은 객체와 관계형 데이터베이스 간의 매핑을 말합니다. ORM 프레임워크가 해당 기능을 제공합니다. 즉, ORM 프레임워크를 이용하면 자바 컬렉션을 사용하듯이 데이터베이스의 데이터를 다룰 수 있습니다.
ORM 프레임워크는 Entity라고 부르는 객체를 분석하여 SQL문을 생성하고 JDBC API를 사용하여 데이터베이스와 연동합니다. 단순히 연동만 하는 것이 아니라 앞서 다뤘던 문제들(이전 포스팅 참조, SQL의 문제점, 객체와 데이터베이스의 체계와 한계)을 극복할 수 있게 해줍니다. 따라서 보다 정교한 모델링을 각각의 환경에 맞게 할 수 있습니다. 한마디로 개발자는 어떻게 매핑할지만 고민하면 됩니다.
ORM 프레임워크 중 가장 많이 사용되는 프레임워크는 하이버네이트(hibernate)입니다. ORM 프레임워크는 JPA의 인터페이스를 구현한 것이기 때문에 JPA 구현체라고도 불립니다.
JPA의 등장
EJB(Enterprise Java Beans)라는 기술 표준에 대해 들어보셨나요? 아마 경력이 좀 되는 개발자라면 한 번쯤은 들어보셨을(또는 사용해보셨을) 겁니다. EJB 안에 ORM 기술도 포함되어 있지만 복잡하고 완전한 기술이라고 보기엔 다소 무리가 있었고 자바 엔터프라이즈(이클립스 다운 받을 때 보면 J2EE라고 쓰여있던 그것!) 환경에서만 동작하였기 때문에 많은 개발자가 사용하는 기술은 아니었습니다.
이때 하이버네이트라는 프레임워크가 등장하였고 기술적으로 훨씬 안정감이 있고 뛰어났기 때문에 하이버네이트를 기준으로 새로운 표준을 정의했는데 그것이 바로 JPA입니다. 인터페이스를 만들고 구현체를 구현해야 하는데 구현체가 너무 뛰어나 구현체에 존재하는 API들을 인터페이스로 정의했다고 보는 것이 맞겠죠.
JPA를 구현한 구현체는 하이버네이트를 제외하고도 EclipseLink, DataNucleus 등이 있습니다. 앞으로 JPA 카테고리의 모든 글은 하이버네이트를 기준으로 작성할 예정입니다. (사실 개발자로 일하면서 하이버네이트 외에 구현체를 사용하는 것을 본 적이 없습니다.)
JPA를 사용해야 하는 이유
소스 코드 내에서 직접 SQL을 다룰 때 나타나는 문제점과, 객체와 데이터베이스의 상이한 체계로 인해 발생하는 문제점은 이미 다루고 넘어갔기 때문에 이러한 문제들을 JPA가 해결해준다는 내용은 생략하겠습니다.
먼저 가장 중요한(제가 가장 중요하다고 생각하는) 유지보수에 큰 도움이 됩니다.
데이터베이스 연동 구간이 존재할 때 가장 힘든 점이 무엇인가요? 전 수많은 스키마와 소스 코드를 오가며 알트 탭(깨알 TMI: 현재는 맥북을 씁니다) 신공 또는 듀얼모니터 사이에서 고개를 휙휙 돌려가며 개발했던 순간이 순간 뇌리를 스치고 지나갔습니다. 알트 탭을 누르거나 고개를 돌리는 게 힘든 게 아니라 개발자가 데이터베이스의 수많은 테이블 구성을 파악하고 연관관계를 파악해야 하는 불편함이 항상 존재했죠. 소스에만 레거시가 있는 게 아니라 데이터베이스에도 수많은 레거시가 존재했기 때문에 정확힌 히스토리를 파악하고 있는 직원 옆에 껌딱지처럼 붙어서 하나하나 물어봐야 했던 슬픈 경험들 다들 있으시죠? 이 모든 것이 Entity라는 객체 하나로 관리됩니다.
쿼리가 바뀌면 다른 소스까지 다 바뀌어야 했던 문제 또한 해결됩니다. 정확히 말하면 수정해야 하는 구간이 줄어들고 수정하는데 큰 노력이 들지 않습니다. 더 정확히 말하면 소스 코드 몇 줄만 바꾸면 됩니다.
이러한 것들이 누적되면 유지보수나 인수인계에 들어가는 노력이 온전히 소스 코드에 스며들 수 있고 이는 고품질의 소스 코드를 작성할 수 있는 여유가 생깁니다. 이는 곧 코드 생산성의 증가를 의미합니다. 무의미하게 반복해왔던 일들이 줄어들고 그 안에서 발생하던 실수가 줄어듭니다.
성능에 관해 의심하는 분들이 많습니다. 하지만 튜닝할 수 있는 다양한 방법을 제공하기 때문에 익숙하게 사용할 수 있다면 데이터베이스를 잘 모르는 개발자(바로 나야🎶 둠바 둠바 두비두바🎵)에게는 오히려 쿼리로 인한 성능 걱정을 덜 수 있습니다.
또한 여러 개의 데이터베이스를 사용하는 경우 중 그 종류가 다른 경우(oracle, MySQL 등을 동시에 사용)에도 소스 코드를 바꿀 필요가 없습니다. 이는 dialect(직역하자면 방언, 데이터베이스 별로 가지고 있는 문법을 뜻함)를 설정 값 변경을 통해 적용할 수 있기 때문입니다.
이쯤 되면 안 쓸 이유가 없어 보이죠?
이제 진짜로 JPA를 공부할 시간입니다!
다음 포스팅 부터는 예제 프로젝트 구현을 통해 JPA의 기능들을 하나씩 소개하도록 하겠습니다.
본 포스팅은 자바 ORM 표준 JPA 프로그래밍을 참고(+ 내 지식, 내 뇌피셜, TMI)하여 작성하였습니다.
'JPA' 카테고리의 다른 글
스프링 데이터 JPA - 페이징과 정렬 (0) | 2021.06.30 |
---|---|
스프링 데이터 JPA - 쿼리 메서드(Query Method) (0) | 2021.06.28 |
객체와 데이터베이스의 체계와 한계 (0) | 2020.04.02 |
SQL의 문제점 (0) | 2020.04.01 |
JPA를 공부하는 이유 (2) | 2020.03.31 |
- Total
- Today
- Yesterday
- intellij
- 클린 아키텍처
- 함께 자라기 후기
- @ManyToOne
- 헥사고날 아키텍처
- Linux
- 스프링 부트 애플리케이션
- 스프링부트
- r
- Java
- spring boot application
- Spring Boot
- Spring Data JPA
- gRPC
- 알고리즘
- Jackson
- spring boot jwt
- proto3
- JSON
- Spring Boot Tutorial
- spring boot app
- 함께 자라기
- Spring Boot JPA
- 스프링 부트 회원 가입
- JPA
- QueryDSL
- 스프링 부트 튜토리얼
- leetcode
- 스프링 데이터 jpa
- 스프링 부트
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | |||||
3 | 4 | 5 | 6 | 7 | 8 | 9 |
10 | 11 | 12 | 13 | 14 | 15 | 16 |
17 | 18 | 19 | 20 | 21 | 22 | 23 |
24 | 25 | 26 | 27 | 28 | 29 | 30 |