[JPA]JPA에 대하여

JPA에 대하여

JPA는 Java Persistence API의 약어입니다. Persistence는 "(없어지지 않고 오래 동안) 지속됨"이라는 뜻을 가지고 있는데, 많이 사용하는 표현으로는 영속성이라고 부릅니다. 뜻 그대로 없어지지 않고 오래 동안 지속이 된다는 의미입니다.

그러면 도대체 무엇을 오래 동안 지속하는 것일까, 우리가 작성하는 객체를 말합니다. 일반적으로 애플리케이션이 종료되면 우리가 생성한 객체들은 메모리에서 사라지게 되며, 더 이상 어디에도 존재하지 않습니다.

 

우리는 애플리케이션이 종료되더라도 다시 실행할 경우 이전 상태의 객체가 필요한 경우가 많습니다. 쉽게 말하면 우리가 작성하는 문서를 생각하면 됩니다. 문서 편집 애플리케이션이 종료된다고 해서 우리가 작성한 문서 내용들이 사라지게 되면 안되겠죠 ?

 

이처럼 JPA는 우리가 작성한 객체가 사라지지 않고 데이터베이스라는 저장소에 저장하여 주는 API라고 볼 수 있습니다. 다만, 기존에도 데이터베이스라는 저장소에 객체를 저장하여 주는 API들은 역사적으로 많이 존재해왔습니다.

 

JPA가 무엇이 다를까 ?

단순히 객체를 데이터베이스에 저장하여 주는 API는 JPA 말고도 많이 존재해왔습니다. 그러면 JPA는 다른 API와는 다른 게 무엇인지 궁금해야 하고, 그것이 JPA가 생겨난 이유일 것입니다.

 

JPA는 자바 진영에서 사용하는 ORM(Object-Relational Mapping) 프레임워크입니다. ORM이라는 단어가 생소할 수 있는데 단어를 보면 쉽게 어떠한 프레임워크인지 유추를 할 수 있습니다. 해석하면 다음과 같습니다.

 

 

객체 관계 매핑(Object-relational mapping; ORM)은 데이터베이스와 객체 지향 프로그래밍 언어 간의 호환되지 않는 데이터를 변환하는 프로그래밍 기법이다.
출처 - 위키백과(한국)

 

 

그러면 도대체 어떤 부분이 호환이 되지 않는다는 것이며, 무엇을 변환한다는 의미일까요.

 

 

데이터베이스는 데이터 중심적인 모델링 기반이며, 객체지향 패러다임은 객체 중심적인 모델링 기반이다.

데이터베이스에서 테이블에 속한 하나의 로우는 단순한 데이터들의 그룹일 뿐입니다. 데이터 그룹의 형식에 맞게 요청된 SQL을 처리하여 저장하여 줄 뿐이죠. 하지만 우리가 작성하는 객체들은 단순한 데이터들의 그룹이 아닌 응집도 높은 유기체이며, 독립적으로 존재하기보다는 다른 객체들과 협력과 상호작용을 합니다.

 

여기서 협력은 다른 객체와의 관계를 말하며, 상호작용은 그 관계에서 일어나는 행위들을 말합니다.

 

즉 객체를 바라보는 시점이 객체가 가지고 있는 상태(데이터)가 아닌, 객체 그 자체여야만 하며 저장하고자 할 때 또한 객체 단위로 저장, 수정, 조회, 삭제가 되어야 하는 것이 합리적입니다.

 

하지만, 이러한 객체를 저장하기 위해서는 기존의 경우 데이터베이스의 성격에 맞추어 객체 존재 이유를 망각하고, 객체를 데이터들의 저장소 마냥 해체하여 데이터베이스에 저장을 하고 있었습니다. 

 

서로 다른 기반을 가진 두 시스템이 결합 하기 위해서는 중간 다리 역할이 필요하며, JPA가 바로 그 역할이며, 존재의 이유다.

 

JPA는 사실 명세일 뿐이다.

JPA는 위와 같은 문제점을 해결하기 위해 개발자들이 정해놓은 명세(인터페이스)일 뿐입니다. 실제로 데이터베이스와 객체지향언어 사이에 동작하는 코드의 개념이 아니라는 의미이다. 명세인 이유는 다양하게 있지만, 제가 가장 공감한 이유는 다음과 같습니다.

 

특정 문제를 해결할 수 있는 해결 방법을 정해놓으면, 다른 사람들이 생각할 수 있는 사고의 범위를 제한하게 될 수 있고, 창의적인 생각에 방해가 될 수 있다. 동일한 문제여도 사람마다 해결하는 방법이 다양하며, 그 방법들만의 장단점이 존재한다.

 

그렇기 때문에 JVM(Java Virtual Machine) 또한 명세이며, 그 덕분에 다양한 벤더사에서 창의적인 방법으로 효율적이고 멋진 JVM 들을 구현해낼 수 있었습니다.

 

또한 우리는 해당 기능들이 어떻게 작동하는지 알 필요가 없습니다. JPA를 구현한 벤더사들이 공통적으로 규정한 명세에 맞게 코드를 작성하였으므로 우리는 명세에 맞게 사용하면 우리가 원하는 기능이 정상적으로 작동할 것이라고 확신할 수 있기 때문이죠.

 

하지만, JPA를 공부하다 보면 특정 벤더사에서 구현한 역사가 깊고 유명한 구현체(Hibernate)에 종속적이게 되는데, 이는 JPA의 본연의 이유와 많이 멀어졌다고 생각이 들었고, 이는 개발 경험이 적은 저의 좁은 시야일 수도 있습니다.

 

명세는 일종의 인터페이스입니다. 인터페이스는 여러 사용 이유와 목적이 있겠지만 구현을 추상화한다는 점이 강점이라고 생각하지만 JPA를 사용하면서 발생하는 여러 이슈에 대응하기 위해서는 특정 구현체의 작동 방식을 세세하게 알아야하는데 이는 인터페이스의 강점을 잃게 되는 거라고 생각이 듭니다. 

 

이는 트레이드 오프라고 생각하고, 항상 잃는 게 있으면 얻는게 있습니다.