[JPA] 패러다임의 불일치 와 해결책 (feat. JPA)

길지 않은 개발 경력이지만 한 가지 사실은 명확하게 알고 있습니다.

바로 그 명확한 사실은 "프로그램은 천년만년 그대로 있지 않는다."입니다.

 

프로그램 변화의 이유는

1) 요구 사항이 변경되어서

2) 기능을 추가하기 위해서

3) 보안을 강화하기 위해서... 등등

비슷한 듯 보이지만 조금씩 다른 이유가 있습니다.

 

제가 운영하고 있는 시스템에 수정 요청이 접수되었는데, 수정이 필요한 부분의 규모와 범위가 작다면 수정하는데 큰 무리가 없겠지만 수정 규모와 범위가 크고 넓다면 상당한 부담이 될 것입니다.

설상가상으로 수정에 필요한 적정 수준의 일정이 아닌 굉장히 타이트한 일정이라면 더 상황을 최악입니다.

위와 같은 상황이라면, 정말 뛰어난 개발자도 사람인지라 충분히 실수를 하지 않을까요?

---

실제로 주변에서 있을 만한 상황으로 예를 들어보겠습니다.

여러 지점을 갖고 있는 프랜차이즈 헬스장의 회원을 관리할 수 있는 서비스를 만든다고 가정해보겠습니다.

우리는 상속, 추상화, 정보은닉, 다형성, 캡슐화 등의 특징을 갖고 있는 대세 객체지향 언어와 관계형 데이터베이스로 서비스를 만들게 될 겁니다.

 

DB 테이블은

1) 헬스장 지점을 관리하고 있는 테이블

   - 속성 : 가입 지점 구분 키값(PK), 지점 명칭

2) 회원 정보가 포함되어있는 테이블

   - 속성 : 회원 구분 키값(PK), 이름, 연락처, 생년월일, 가입 지점 구분 키값(FK)

총 2개가 있을 겁니다.

 

최초 요구사항 명세서에 회원 가입을 하기 위해서는 가입 지점, 이름, 연락처, 생년월일을 수집한다고 작성되어 있어 가입 지점, 이름, 연락처, 생년월일을 입력받을 수 있게 폼을 구성해서 개발을 완료했습니다. 그런데 1주일 뒤 고객으로부터 이름, 연락처, 생년월일 외에 혈액형을 추가할 수 있도록 추가 요청이 접수됐습니다.

그럼 우리(개발자)는 요청 사항을 접수한 후에 혈액형이라는 속성을 추가하기 위해서 객체의 속성(필드)을 추가할 것이고 매소드도 선언할 겁니다. 그리고 DB 테이블에 혈액형 속성을 추가하고 회원가입 페이지 외에 회원과 관련된 처리를 위한 쿼리 외에 수정, 조회 등등 회원 테이블이 선언된 모든 쿼리를 수정할 겁니다.

모든 쿼리를 수정할 때 누락되지 않고 100% 정확하게 진행한다면 큰 문제가 되지 않겠지만 그러기엔 시간도 많이 소요되고 어려 어려움이 있을 겁니다.

자~ 많은 시간과 노력을 들여서 혈액형 속성을 추가했습니다.

그런데, 갑자기 생년월일 칼럼이 더 이상 불필요하게 되어 삭제를 해달라는 요청이 들어옵니다. 그럼 우린 위에 했던 패턴과 비슷하게 객체에서 생년월일 속성을 삭제하고 DB 테이블에서 해당 속성을 삭제하고 모든 쿼리에서 생년월일을 삭제해야 할 겁니다.

 

만약, 위 상황이 수십 번 반복 된다면.. 생각만 해도 너무 끔찍하죠? 하. 지. 만 여기서 끝이 아닙니다.

 

헬스장 사업이 너무 잘되어서 신규 지점을 하나 더 추가하기로 결정됐다고 합니다. 그럼 우리는 DB 테이블에 헬스장 지점을 관리하고 있는 테이블에 데이터를 넣어주고, 새로 오픈한 헬스장 지점의 회원정보를 넣어주는 2번의 작업을 해야 합니다.

 

우리는 지금까지 이런 상황에서 많은 불편함을 느끼긴 했지만 당연하다고 생각했었던 상황입니다.

적어도 저는요

 

객체의 특징(상속, 다형성, 추상화 등)과 관계형 데이터베이스의 지향하는 목적이 서로 다르기 때문에 객체 구조를 테이블 구조에 저장하는 데에는 한계가 있고 이를 해결하기 위해서 위에 예시의 상황처럼 정말 많은 시간과 에너지를 소비하고 있었습니다.

 

이를 해결하기 위한 방법 중 한가지로 JPA (Java Persistence API)라는 것이 주목받고 있다고 합니다.