여러분의 J2EE 개발 환경에 가장 적합한 persistence 아키텍처를 선택하는 방법에 대해 설명합니다.

저자 Doug Clarke 2004년 12월 22일

J2EE 애플리케이션의 설계, 개발, 유지보수 과정에서 가장 많은 시간을 수반하는 반면 가장 과소평가되는 것 중의 하나가 바로 persistence의 문제입니다. 데이타의 인출, 조작, 저장 작업을 어떻게 처리해야 할까요? 일반적으로 관계형 데이타베이스를 통해 관리되는 “데이타”는 Java 기반 애플리케이션과 전혀 다른 방법으로 관리되고 접근됩니다.

persistence 아키텍처는 다양한 형태로 존재합니다. 한편에는 로우-레벨 JDBC(Java Database Connectivity)를 이용한 방법, 또 다른 한편에는 하이-레벨 Enterprise Java Beans (EJB) Container Managed Persistence (CMP)를 이용하는 방법이 있습니다. 위의 두 가지 중 하나, 또는 중간적인 형태의 persistence 아키텍처 중 하나를 선택하여 적용함으로써, J2EE 애플리케이션의 persistence에 관련한 위험 요소(성능, 프로젝트 지연, 관리 비용)를 최소화할 수 있습니다.

어떠한 애플리케이션 개발 스타일(data-centric 또는 object-centric)을 선택하는가에 따라 사용 가능한 persistence 아키텍처의 종류도 크게 달라지게 됩니다. 데이타 중심형(data-centric) 애플리케이션은 관계형 스키마를 기반으로 하며, 애플리케이션 로직 역시 데이타베이스의 저장 프로시저를 기반으로 구현되는 경우가 많습니다. 데이타 중심형 애플리케이션은 기본적으로 “데이타 창구(window-on-data)”의 역할을 담당하며, 미들 티어에 비즈니스 로직을 전혀 (또는 거의) 구현하지 않는 형태로 구현됩니다. 이러한 애플리케이션은 최초 개발 당시에 RAD 툴과 같은 데이타 중심형 테크놀로지를 사용하여 구현되었거나, 아니면 데이타 중심형 테크놀로지에 익숙한 개발자에 의해 구현되었을 가능성이 높습니다. 데이타 중심형 애플리케이션을 개발하는 경우에는 데이타베이스 계층에서 프리젠테이션 계층에 이르는 전체 구성을 모두 포괄하는 프레임워크와 JDBC에 대한 개발 작업이 필요합니다.

여기에서는, 오브젝트 중심형 (object-centric) 애플리케이션을 위한 persistence 아키텍처에 초점을 맞추어 설명을 진행하려 합니다. 오브젝트 중심형 애플리케이션은 일반적으로 J2EE 미들 티어에 구현되며, 애플리케이션 오브젝트 모델과 데이타베이스 스키마 간의 변환을 위한 별도의 “persistency 계층”을 사용합니다 (그림 1 참조).

그림 1. Object-centric Persistence

오브젝트 중심형 애플리케이션의 persistence 아키텍처에서는, 일반적으로 애플리케이션 로직이 J2EE 미들 티어 내부에 구현되며 애플리케이션 오브젝트 모델 및 데이타베이스 스키마 간의 변환을 위해 persistence layer를 별도로 사용합니다.

■ 솔루션 옵션

ORM (object-relational mapping) persistence 계층은 관계형 데이타베이스와 오브젝트 간의 호환성 구현을 담당합니다. 이 계층은 커스텀 프레임워크 또는 써드 파티 솔루션을 통해 구현될 수 있습니다. 그 중 가장 널리 사용되는 솔루션이 아래와 같습니다:

•  POJO (Plain Old Java Objects) Persistence – 내부 개발, 상용 (Oracle TopLink, Solametric Kodo), 오픈 소스 (JBoss Hibernate) 솔루션 등
•  EJB Bean Managed Persistence (BMP) – 내부 개발 또는 자동 생성된 JDBCS 액세스, BMP 지원 써드 파티 프레임워크 등
•  EJB Container Managed Persistence (CMP) – J2EE 애플리케이션 서버의 네이티브 지원 기능, 또는 써드 파티 통합 CMP 솔루션

POJO 솔루션은 개발이 쉽고 유연할 뿐 아니라, 일반적인 Java 오브젝트를 그대로 활용하여 애플리케이션을 개발할 수 있다는 점에서 인기를 끌고 있으며, 이미 많은 상용 솔루션 및 오픈 소스 솔루션이 POJO를 지원하고 있습니다. 개발자들은 J2EE container 외부에서 persistence 모델을 개발하고 테스트할 수 있으므로 개발 시간을 단축할 수 있습니다. 또 애플리케이션 서버에 대한 종속성이 최소화되므로 향후 서버 벤더의 전환이 용이하며, J2EE container 외부의 모델에 동일한 애플리케이션 로직을 재활용할 수 있다는 이점이 제공됩니다. 그리고 웹 티어 또는 (Session Bean의 wrapping을 이용하여) EJB 티어에 구현된 J2EE 서버가 제공하는 POJO 솔루션을 활용하여, 표준을 100% 준수하는 J2EE 애플리케이션을 구현할 수 있습니다. Enterprise JavaBeans와 POJO persistence를 함께 활용하는 방안은 EJB 3.0 specification을 통해 지원될 예정입니다 (오라클은 새로운 모델인 EJB 3.0의 정의 작업에 중요한 역할을 담당하고 있습니다). 하지만 JSR 220 (EJB 3.0)은 아직 초기 단계이며 2006년 중에나 완성될 것으로 예측되고 있습니다.

BMP 솔루션은 그리 대중적이지는 않지만 결코 간과할 수는 없는 대안입니다. BMP 개발자는 J2EE container에 의해 관리되는 entity bean(통합 J2EE 컴포넌트)을 생성하고, 이에 관련한 persistence 개발 작업을 bean author에게 일임합니다. BMP 솔루션은 persistence 구현의 책임을 개발자가 져야 한다는 부담이 따르는 반면, 다양한 애플리케이션 서버에서 호환 가능하다는 장점을 갖습니다.

BMP는 일반적으로 개발자가 직접 작성한 JDBC 코드를 통해 구현되며, 때문에 만만치 않은 개발 비용과 유지보수 비용을 수반합니다. 하지만 BPM 솔루션을 구현하는 다른 방법도 존재합니다. 많은 상용 솔루션이 persistence 계층의 코드 생성(code generation) 기능을 이용하여, 또는 (보다 이상적인 방법으로) ORM 솔루션을 통해 BPM 솔루션을 지원하고 있습니다. entity bean이 제공하는 혜택을 누리기 원하고 직접 persistence 코드를 작성하는 수고를 감수할 수 있는 환경, 또는 애플리케이션 서버 간의 호환성이 필요한 환경이라면 BMP를 고려할 필요가 있습니다.

CPM 솔루션은 때로 부정적인 평가를 받고 있는 것이 사실이지만, 여전히 일부 개발자들에 의해 사용되고 있습니다. EJB 2.1 specification에서는 초기 버전에서 문제가 되었던 여러 가지 persistence 관련 제약사항이 해결 되었습니다. 이러한 개선 사항 덕분에 애플리케이션 서버 벤더는 완전한 기능을 갖춘 persistence 계층을 구현하고, EJB 스펙이 제공하는 기능을 개발자가 선택하여 사용할 수 있는 환경을 제공하게 되었습니다. 이것은 EJB 2.1 이전의 환경에서는 전혀 불가능했던 것입니다.

현재 제공되는 일부 CMP 솔루션은 캐싱, 데이타베이스 락킹, 쿼리 익스텐션, 최적화 SQL 생성 기능 등 EJB 2 specification에 포함되지 않은 persistence 지원 기능을 제공합니다. 이러한 솔루션을 사용하여 벤더 종속성을 부분적으로 희생하는 대신 한층 개선된 성능과 기능을 활용할 수 있습니다.

■ 솔루션의 통합

CMP를 사용하는 EJB entity bean 환경은 POJO 솔루션을 적용한 경우에 비해 더 높은 런타임 오버헤드 및 개발 오버헤드를 수반합니다. 하지만 CMP는 단순한 persistence 이상의 기능(보안, 인스턴스 풀링/관리, 원격 액세스, 로드 밸런싱, 페일 오버 등)을 제공한다는 점에서 장점을 갖습니다. 이러한 추가 기능이 필요하거나, 검증된 표준을 적용하고자 하는 환경에서는 CMP가 유력한 선택이 될 수 있습니다. CMP는 추가적인 개발 비용을 요구하는 대신, 더욱 풍부한 개발 환경을 제공하며 기능 개선을 위한 로드맵을 분명하게 제시하고 있습니다.

자바 개발자 커뮤니티는 CMP entity bean을 성공적으로 적용한 개발자 진영과 POJO 스타일 솔루션을 옹호하는 진영으로 양분되는 경향을 보이고 있습니다. EJB 3.0이 발표되고 나면, CMP와 POJO의 ORM persistence 지원 기능의 통합이 가능할 것으로 예상됩니다. 그때가 되면 두 가지 접근법의 장점만을 조합하여 오늘날 제기되고 있는 문제들을 해결할 수 있게 될 것입니다. EJB 3.0에 대해서는 다른 아티클을 통해 자세히 다루도록 하겠습니다.

persistence 솔루션과 벤더를 선택할 때에 고려해야 할 선정 기준이 표 1과 같습니다.

선정 기준 고려사항 설명 Core 기능 매핑 프레임워크를 적용할 때, 하부 관계형 스키마 또는 기타 데이타 저장소에 불필요한 변경작업을 수행하지 않아도 되는지 확인합니다. 현재 출시된 툴들이 간단한 시나리오(테이블과 클래스가 1대1로 대응하는 경우)는 지원하는 반면 (상속, 컴포지트 키, 복수 개의 테이블 등으로 구성된) 복잡한 스키마를 매핑 하지 못하는 경우가 많습니다.   쿼리 Java 개발자에게 있어서는 (SQL이 아닌) 오브젝트 모델에 기반한 쿼리가 작성 및 유지보수 면에서 한층 쉽습니다. 이와 별도로 persistent 계층의 쿼리 옵션을 통해 데이타베이스의 표준 SQL, 저장 프로시저, 커스텀 기능 등을 활용할 수 있어야 합니다.   트랜잭션 프레임워크가 “absolute transaction isolation”을 지원하는지 확인합니다. 데이타베이스의 정합성을 보장하고 데드락을 방지하기 위해서는, 트랜잭션의 길이를 최소한도로 유지하고 업데이트를 미니멀(minimal)한 형태로 수행할 수 있어야 하며, 구문의 정렬(ordering)이 가능해야 합니다.   캐싱 자주 액세스 되는 오브젝트를 캐시에 저장하는 기능과 함께 동시성(concurrency) 처리를 지원하고, stale 데이타를 관리하기 위한 락킹 메커니즘이 지원되어야 합니다. 개발 비용 학습 곡선 개발자들이 툴을 학습하고 생산성을 향상시키려면 얼마나 오랜 시간이 걸리는지 확인해야 합니다. 교육에 필요한 리소스가 충분히 제공되고 있는지, 입문 과정을 효과적으로 지원할 수 있는 개발자 커뮤니티가 존재하는지 확인합니다.   매핑의 유연성 오브젝트 모델을 관계형 모델로 매핑 하는 기능과 모델과 매핑의 수시 변경을 효과적으로 지원하는 기능이 제공되어야 합니다. 예를 들어 모델이 자주 변경되거나 매핑된 클래스/bean의 수가 기하급수적으로 증가하여 단순한 모델로는 감당할 수 없게 되는 경우를 고려해야 합니다.   개발자 스킬 개발자가 필요로 하는 스킬이 무엇인지 파악해야 합니다. 많은 O-R 제품은 하부의 관계형 구조와 쿼리에 대한 지식이 없어도 개발자가 업무를 수행할 수 있는 환경을 제공합니다. 오브젝트 지향형 Java 개발에 대한 지식과 SQL에 대한 지식을 겸비한 고급 개발자를 확보하는 것은 쉬운 일이 아닙니다. 프로젝트에 필요한 고급 개발자의 수를 줄이기 위해서라도, 벤더 별로 어떤 쿼리 옵션을 제공하고 어떤 교육이 필요한지 미리 확인해야 합니다.   테스트 용이성 로컬 환경에서 O-R 매핑과 RDBM 관련 애플리케이션 로직을 얼마나 쉽게 테스트할 수 있는지 확인해야 합니다. EJB2 entity bean에 관련하여 개발자들이 제기하는 불만 중 하나가 바로 애플리케이션의 구축이 완료되지 않은 상황에서 로컬 IDE에서 테스트를 수행하기 어렵다는 점입니다. 툴이 제공하는 개발 환경이 persistence 솔루션과 긴밀하게 통합되어 있어야만 용이한 테스트가 가능합니다.   개발 프로세스 Persistence 아키텍처와 벤더 솔루션이 개발 프로세스에 미치는 영향을 고려해야 합니다. 일부 솔루션의 경우 소스 또는 바이트 코드 레벨의 수정작업이 필요할 수 있습니다. 또는 persistence 모델 전반에 걸쳐 특정 솔루션만을 사용해야 할 수도 있습니다. 이러한 요구사항을 이해하고 개발 프로세스에 미치는 영향을 미리 확인함으로써, 개발자가 자동화가 불가능한 부분에서 발생하는 추가적인 업무 부담을 미리 인지하고 대비할 수 있습니다.   데이타베이스 기능 ORM 솔루션의 기반을 이루는 데이타베이스의 기능에 대한 검토 작업 역시 필요합니다. XML 관련 기능, Virtual Private Database, 커스텀 타입 및 함수, 데이타베이스 클러스터링 페일오버 등이 고려되어야 합니다. 성능   대부분의 경우, 애플리케이션의 성능은 대단히 중요한 고려 사항이 됩니다. 최적의 성능을 얻기 위해서는 데이타베이스 및 JDBC 관련 성능 개선 효과 (구문 캐싱, 매개변수 바인딩, 커스텀 SQL 힌트, SQL 최적화를 통한 읽기/쓰기 성능 개선, 트랜잭션 실행시간의 최소화 등)를 제공하는 애플리케이션을 선택해야 합니다. 캐시는 반복적인 쿼리의 읽기 성능을 향상시키며, in-memory 쿼리 기능을 통해 정적인 유형의 데이타 읽기 성능을 개선할 수 있습니다. 또 트랜잭션에 대한 미니멀 업데이트(minimal update) 기능은 변경된 오브젝트에 대해 제한적으로 I/O를 발생시킵니다. 확장성   확장성에 대한 검토 작업이 뒤늦게 고려되는 경우가 많습니다. 초기 단계에서 고려해야 할 몇 가지 사항이 다음과 같습니다: 공유 캐시가 제공되는 경우 동기화, 복제, 무효화(invalidation) 등이 다수 노드로 구성된 환경으로 확장될 수 있는지 점검합니다. 락킹(locking) 지원 기능도 중요합니다. 관계형 스키마와 연동 가능한 optimistic locking이 제공되는지 확인합니다. 경우에 따라서는 pessimistic locking이 유용할 수도 있습니다. 또 데드락의 가능성을 줄이기 위해서, 데이타베이스가 미니멀 트랜잭션 기능과 예측 가능한 커밋 순서(predictable commit order)를 지원하는지 확인합니다. 유지보수 비용 매핑 기능 매핑에 관련한 변경작업이 용이한지, 개발자가 교체되는 경우 업무 인계가 가능한지 확인합니다. 오브젝트 모델 또는 스키마에 변경사항이 발생하는 경우, 이러한 변경 작업이 다른 프로세스에 미치는 영향을 최소한으로 유지할 수 있어야 합니다. 예를 들어 데이타베이스 테이블이 변경된 경우, 코드에 관련한 SQL 쿼리를 일일이 찾아내어 수정해야 한다면 그 비용 또한 만만치 않을 것입니다.   종속성 애플리케이션 인프라스트럭처에 persistence 프레임워크를 추가하려는 경우, 이에 관련한 종속성 문제를 먼저 이해해야 합니다. 애플리케이션, 애플리케이션 서버, persistence 계층, 데이타베이스 간의 종속성 문제로 인해, 패치 또는 업그레이드 과정에서 심각한 제약을 받을 수도 있습니다. 기술지원 개발자 커뮤니티 업계의 동료들과 지식을 공유할 수 있는 개발자 커뮤니티 또는 포럼이 존재하는지 확인합니다.   기술지원 개발 초기 단계에서 기술지원 문제를 간과하는 경우가 종종 있습니다. 하지만 프로젝트가 진행되면서, 공식 채널을 통해 문제를 해결할 수 있는가의 여부에 따라 애플리케이션의 품질이 좌우될 수 있습니다. 또 예상치 못했던 시나리오로 인해 장애가 발생하거나, 업그레이드 작업 이후 환경에 이상이 발생하는 경우에 기술 지원이 가능한지 확인해야 합니다.   교육 개발 팀의 규모를 확대하고자 하는 경우라면 제품에 관련한 충분한 교육이 제공되는지 미리 확인할 필요가 있습니다. persistence의 문제를 해결하는 방법에는 여러 가지가 있습니다. 교육을 통해 persistence의 구현에 수반되는 리스크를 최소화할 수 있습니다. 프레임워크를 선택하는 것은 시작에 불과하며, 애플리케이션을 최상의 상태로 유지하고 관리하는 것은 또 다른 문제입니다.

표 1 Persistence 솔루션의 선택

POJO는 가장 단순한 모델을 제공하는 한편으로 매우 높은 유연성의 구현을 가능하게 합니다. POJO는 가장 많은 상용 및 오픈 소스 솔루션을 통해 제공되고 있습니다. 솔루션 선택 시에 벤더의 안정성은 매우 중요한 선택 기준이 됩니다. 향후 EJB 3.0으로의 이행이 가능하다는 점에서 볼 때 POJO 솔루션은 전략적으로 현명한 선택이 될 수 있습니다. (단, EJB 3.0은 CMP 솔루션에 대한 마이그레이션 도 함께 지원할 예정이라는 점을 참고할 필요가 있습니다.)

BMP는 애플리케이션 서버 간의 호환성을 필요로 하는 환경에서 유용한 EJB entity beans 솔루션입니다. 하지만 데이타 집중형 JDBC 솔루션 및 EJB 환경의 개발 및 유지보수에 많은 비용이 수반된다는 단점이 있습니다.

CMP는 persistence 이상의 기능을 제공합니다. 하지만 표준에 포함되지 않은 persistence 기능을 사용하게 되므로, 특정 애플리케이션 서버 제품 또는 벤더에 종속될 위험이 있습니다.

Persistence에 관련한 요구사항은 프로젝트마다 달라질 수 밖에 없습니다. 다양한 아키텍처를 지원하고 향후 표준으로의 마이그레이션 경로를 제공하는 솔루션과 벤더를 선택함으로써, 현재와 미래의 프로젝트 성공을 보장할 수 있습니다.

필자 소개

Doug Clarke는 Oracle TopLink의 수석 제품 매니저로, 오브젝트 지향형 애플리케이션 및 관계형 데이타베이스의 인터페이스에 관련한 개발 및 프로페셔널 서비스를 담당해 왔습니다. douglas.clarke@oracle.com을 통해 Doug에게 연락하실 수 있습니다.