전통적인 Java 어플리케이션은 Java가 주인공이 아니었다.
지금까지 쌓아온 개발 커리어의 대부분을 DB 의존성이 강한 영역의 업무시스템을 중심으로 진행하다 보니,
JPA가 개념적으로 좋은 기술임을 충분히 알면서도 쉽게 손이 가지 않는 일종의 심리적인 허들이 존재했던 것 같다 .
DB 의존성이 강한 업무영역이라 함은 서비스의 비즈니스 로직이 대부분 복잡한 쿼리로 구현되어 있고,
별도의 DB Mart나 DW 구성없이 집계,통계성 서비스를 요구하는 업무영역을 의미한다.
커머스의 백오피스, 금융서비스의 정보계영역(영업관리,CRM), 물류서비스등이 대표적인 영역일텐데,
데이타가 흘러가는 위치로 보았을때 가장 끝단에 위치하는 업무영역들이고 이런 업무서비스들은 어떤 산업분야이든 간에 DB의 의존성을 많이 가질 수 밖에 없는 영역이다.
다른 서비스들보다 상대적으로 데이타의 가공과 정제,집계,통계등이 더 요구되는 이런 서비스들은 그 목적만을 위해 만들어진 DBMS - Oracle, MySQL, Ms-SQL등-에 기술적인 의존도가 생기는 것은 어쩌면 당연한 일일 것이다.
이런 태생과 한계를 가질 수 밖에 없는 영역에서 만들어진 기존의 시스템들을, 비즈니스 로직의 대부분이 몇백, 몇천줄의 쿼리-한방쿼리(?)-나 프로시저로 구현된 것 만으로, java라는 언어위에 웹어플리케이션이라는 허울만 쓰고 있다고 무조건 비난할 수 는 없을 것이다.
물론 좋은 구조라고 얘기하는 것은 아니다.
아직까지도 PL-SQL에 대해서 java개발자들간의 찬반논쟁이 현재 진행형인 것은,
단 몇백줄(?)의 프로시저가 수십개 클래스로 구현된 프로그램보다 수십배 또는 그 이상의 성능차이를 보이는 현실에 대한 명확한 반박을 못하는 것 뿐만이 아니라,
앞으로 수년간 현재 도입된 DB솔루션이 변경될 가능성이 0.1%도 되지 않는 환경에서의 서비스의 확장성,유연성을 무조건적인 최고의 가치라며 DB의존성이 짙은 코드를 깍아내리고 배척시하려 하는 기조에 반발하려는 심리가 있어서이지 않을까 생각한다.
이렇게 얘기는 하지만 본인 역시 PL-SQL로 떡칠된 프로그램-여기서 상세한 주석이 달린 가독성 좋은 PL-SQL은 제외- 을
경멸하다시피 하는 입장에 가깝다.
주인공이 되기위한 노력, ORM 의 탄생
오랜 개발기간동안 쿼리기반의 어플리케이션에 익숙한 이유때문인지
java진영에 ORM(Object Relational Mapping) 관련된 라이브러리들이 나왔을때도 하이버네이트보다는 iBatis-사실 ORM이라고 볼수는 없고 xml - java object의 고급Mapper라고 하는게 맞을 듯하다 -를 더 쉽게 받게 받아들인 것 같다.
쿼리구문이 xml로 따로 분리되고, xml과 model객체간의 mapping 처리만으로도
기존 어플리케이션에서 db의존성을 제거하는 데 일정부분 효과가 있었던게 사실이다.
하지만 도메인영역의 영속성 관리와 엔티티간의 관계를 어플리케이션의 코드레벨로 구사할 수 있도록 해서 전통적인 쿼리문 기반의 어플리케이션 구조를 근본적으로 벗어날 수 있게 만든 것은 JPA의 전신이라 할 수 있는 하이버네이트일 것이다.
우리나라 기업들이 여러가지 외부요인, 환경으로 하이버네이트를 적극적으로 도입할 수 없었기 때문에 아직도 많은 기업들이 iBatis기반으로 Model영역이 구현되어 있다.
Java진영에서는 어플리케이션에서 DB의존성을 제거하기 위한 시도와 노력들이 지속적으로 이어져 왔고, 지금도 현재 진행형이다.
그 시도와 노력의 대표적인 결과물이 영속적인 데이터영역을 다루는 기술인 ORM일 것이다.
지금 얘기하려고 하는 JPA는 ORM의 대표적인 라이브러리이며, 그 전신이 위에서 언급했던 하이버네이트이다.
앞서 얘기한대로 엔터프라이즈급 규모의 시스템을 운영하는 국내의 전통적인 기업들은
DB에 의존적인 시스템들의 한계로 인해 본격적인 ORM 기반기술인 하이버네이트보다는 쿼리매퍼 - 레거시의 쿼리기반 어플리케이션구조를 유지-툴인 iBatis가 더 많이 도입되었던게 사실이다.
(지금도 많은 기업들이 iBatis를 사용하고 있고 JPA를 도입했더라도 병행해서 사용하는 곳도 적지 않다.)
지금은 다르다.
요즘의 JAVA기반 어플리케이션은 MVC에서 Model의 영역에서 JPA기술은 거의 필수적으로 사용되고 있다고 해도 과언이 아니다.
이 것은 NoSQL의 기술의 발전과 대중화, DDD(도메인주도개발) 개발방법론의 대두,
마이크로서비스아키텍쳐(MSA) 구조로의 서비스 분화등, 기술선도적인 역할을 주도했던 일부 회사들만이 도입하고 시도했던 이런 기술들이 전통적인 기업들을 포함한 IT업계 전반적인 영역으로 확대되면서
자연스럽게 하이버네이트 기반의 JPA가 iBatis(=MyBatis)를 대체하고 ORM의 메인 기술로 자리잡고 있다.
순수 언어기반 어플리케이션과 DB영역간의 관계에서 이런 기술적인 변화는 시사하는 바가 크다고 생각한다.
예전에는 자바개발자가 쿼리의 구사능력이 좋으면 뛰어난 개발자로 인식되는게 매우 자연스러웠다.
어플리케이션 레벨에서 데이타를 가공하고, 조립하고, 필터링하는 접근방법보다 쿼리-이것도 실력에 따라 동일한 결과를 몇백줄로 짤 수도 있고, 몇 십줄로 짤 수도 있다, 그걸로도 되지 않으면 PL-SQL로...-로 복잡한 비즈니스 로직을 해결하는 방법이 더 인정 받았고,
더 뛰어난 개발자로 인식되는 중요한 덕목 중 하나였다.
사실 본인도 주니어시절이었던 2000년 초반에는 쿼리 몇백줄을 쉽게 짜는 선임개발자들을 우러러본게 사실이다.
이 부분은 다소 논쟁의 여지가 있을것 같다.
Query라고 하는것도 PL-SQL의 일부로 본다면 JAVA와 같은 프로그래밍 언어의 일종이고,
그런 측면에서 다른 언어를 잘 다루고, 그 언어에 대한 뛰어난 전문성으로 가진다는 것은 충분히 뛰어난 개발자로 인정 받을 수 있다고 생각한다.
하지만 Query, PL-SQL구사능력을 가진 개발자는 무조건 뛰어난 JAVA개발자이지는 않다.
뛰어난 java개발자라면 요구되는 기능의 핵심 로직은 java의 사상을 담은 형태로 Java 통해 구현할 수 있어야 하며,
java에서 처리할 수 있는 로직들은 모두 java기반으로 사고하고 구사될 수 있도록 코드를 짤 수 있어야 하고
그런 마인드가 기본으로 갖추어져 있어야 한다고 생각한다.
이 부분을 자세히 언급한 이유는 Java기반의 어플리케이션이 지금까지 띄었던 기형적인 DB의존적인 구조를 벗어나기 위해서 한번쯤은 짚고 넘어가야 하는 문제가 아닐까 해서인데,
물론 다른 견해를 가진 Java개발자들도 분명 있을것으로 생각한다.
java개발자로써 스스로에 대한 자기성찰이기도 하다.
하이버네이트의 밝은 빛 - JPA(Java Persistence API)
JPA를 사용하면 어떤 요구사항이냐에 따라 다를 수는 있겠지만,
극단적으로 얘기하면 소스코드에 쿼리구문 단 한줄도 사용할 필요가 없다.
(참고로 현재 사내에서 진행하고 있는 프로젝트도 막바지인데 @Query어노테이션을 단 한곳도 사용하지 않았다. 테이블은 20여개 내외)
도메인 주도 개발 (DDD)을 전제로 얘기하자면 충분히 가능한 일이다.
또한 도메인 설계, 모델링에 대한 기본적인 사전지식도 전제되어야 함은 당연하다.
단위 기능들도 최대한 단순화, 경량화, 개별화가 되도록 설계를 해야한다.
집계/통계성 데이타를 위한 별도의 도메인 영역도 설계에 고려되어야 한다.
결국, JPA도입은 apache-common-util과 같은 유틸성 라이브러리를 추가해서 필요한 API만을 선택해서 쓰는 경우와는 차원이 다른,
다른 여러 요소와 역량들이 뒷받침되어야만 의미있는 기술임이 분명하다.
트랜드를 따라, 도입 그 자체의 목적을 위해 아주 단순한 CRUD 기능 적용만을 할 수 밖에 없는 수준으로 JPA를 쓰는 것은 개인적으로 의미없는 일이라고 생각한다.
도메인 주도개발을 통해 기존의 DB에서부터 시작되는 도메인설계의 방식을 완전히 전환해야지만 JPA는 그 목적성을 제대로 살릴 수 있다.
실제로 실무에 JPA를 도입하는 과정에서의 시행착오와 고민에 대해서는 다음 포스팅에서 다루어 보도록 하겠다. (시간이 된다면...)
최근댓글