미들웨어 발전 방향에 비춰본 DB 인터페이스의 변화

DB와 미들웨어 간 인터페이스에 대한 변화와 전망(1회)

미들웨어 발전 방향에 비춰본 DB 인터페이스의 변화

데이터베이스와 미들웨어는 이제 시스템을 구성하는 데 있어서 당연히 필요한 구성요소로서 정착됐다. 하지만 이들을 엮기 위한 인터페이스를 어떻게 구성할 것인가는 여전히 시스템 아키텍트들의 고민거리가 아닐 수 없다. 그리고 미들웨어와 데이터베이스는 각각의 발전방향을 갖고 지금도 진화를 거듭하고 있으니 이는 영원한 우리들의 숙제가 아닌가 싶다. 필자는 2회에 걸쳐 여러 미들웨어와 데이터베이스의 발전 추세에 비춰 변화하는 인터페이스를 살펴보고 향후 전망을 알아보고자 한다.

데이터베이스와 미들웨어의 차이

IT 업무 시스템의 구현에 있어 ①클라이언트 ②미들웨어 기반의 애플리케이션 서버 ③데이터베이스로 이뤄진 3계층(Tier) 구조가 아키텍처의 개방성 및 효율성과 함께 확장을 비롯한 유지 보수의 편의성이 입증되면서 표준 구성으로 받아들여지고 있다.



하지만 미들웨어와 데이터베이스의 이질감은 어디에서 비롯된 것일까? 필자는 그 이유를 근본적인 하드웨어의 차이에서 찾을 수 있다고 본다. 미들웨어는 메모리에 인스턴스 형태로 존재하고, 클라이언트 혹은 데이터베이스로부터 제공돼 메모리로 옮겨진 정보를 CPU를 이용해 연산을 수행한다. 그 결과를 데이터베이스에 저장하게 되며, 데이터베이스는 이를 영속적인 저장 장치인 디스크에 기록하게 된다.

메모리에서는 주소 값을 참조해 자유로운 입출력이 가능한 반면, 휘발성으로 영속적인 정보관리가 되지 않는다. 하지만 디스크는 비휘발성으로 정보의 반영구적인 보관이 가능하고, 장치의 특성 상 파티션을 통해 분할된 블록 단위로의 입출력에 최적화된 구조를 취하고 있다. 이렇게 하드웨어적인 특성 차이로 인해 주어진 제약 조건 하에서 각각 발전돼 오면서 정보를 다루는 방식에서도 차이를 갖게 됐다.

신속한 Random Access에 유리한 메모리는 참조 형식의 객체모델(Object Model)을 가상머신 기반에서 실현하는 것을 가능하게 하는 반면, Sequential Access를 위주로 디스크에서 블록 단위로 데이터를 검색해 필요한 테이블의 레코드 정보에 대한 연산을 처리하는 방식은 관계모델(Relational Model)에 적합하다. 물론 디스크에서의 Sequential Access에 따른 비효율성은 인덱스(Index)를 채용함으로써 보완됐다.



일찍이 기업용 애플리케이션에서는 모델 엔티티 사이의 관계에 데이터베이스 테이블과 외래 키를 사용했다. 애플리케이션은 단순히 데이터베이스를 기반으로 하는 모델에 대한 뷰와 쿼리 실행을 위한 방법으로만 여겼던 적이 있다. 이는 3계층 아키텍처가 자리잡기 이전 많이 활용되던 클라이언트-데이터베이스로 구성된 2계층 아키텍처를 떠올려 본다면 이해가 쉬울 것이다

최근 애플리케이션 설계의 경향은 데이터베이스의 관계모델 기반의 모델링에서 애플리케이션의 객체모델 기반의 모델링으로 옮겨가고 있다. 이제 데이터베이스는 단순하게 객체 구조에 정의된 영속성 정보를 저장하는 메커니즘으로 인식되고 있다. 이러한 변화를 주도하는 요소들은 다음과 같은 장점들에 기인한다.

- 객체를 중심으로 영속성정보와 객체가 수행하는 행위의 통합
- 느슨한 결합을 갖는 애플리케이션 컴포넌트들의 용이한 운용으로 유연성 향상
- 관계모델을 통해 표현되지 못하는 객체모델 기반의 풍부한 연관관계 표현
- 특정 데이터베이스 플랫폼에 대한 고도의 독립성

관계모델에 비해 객체모델이 좀 더 현실 세계의 실체들을 애플리케이션에 반영하는 데 유리하기 때문에 객체모델을 강조하는 경향은 앞으로도 지속될 것으로 예상된다. 그렇다면 이렇게 이질적인 모델들이 3계층 아키텍처를 기반으로 통합되기 위해서는 무엇이 필요할까?

이러한 변화의 중심에 ORM(Object-Relational Mapping)이 있으며, 이를 통해 애플리케이션의 객체모델이 일관된 방법으로 데이터베이스의 영속성 정보와 결합할 수 있는 다양한 방법들로 발전되고 있다. Hibernate, iBATIS, Apache OJB, JDO(Java Data Objects), TopLink, JPA(Java Persistence API) 등이 그들이며, 이러한 도구들은 객체모델을 관계형 데이터베이스 스키마로 만들어 준다.

ORM(Object-Relational Mapping)의 등장

데이터베이스를 이용하기 위해서는 제공되는 라이브러리(JDBC, ODBC, CLI 등)를 이용해 시스템에 접속하고 SQL(Structured Query Language)을 통해 필요한 정보를 제공받는 방식을 이용해야 한다. 이러한 이용방식은 관계모델로 정의된 데이터베이스 스키마에 종속된 형태로 이뤄진다. 물론 이러한 방식이 가장 효율적이기 때문이다.

하지만 프로그래밍 언어와 미들웨어의 발전에 힘입어 단순히 애플리케이션을 객체모델로 정의하고, SQL을 통해 실 데이터를 테이블의 레코드 단위로 조회？생성？변경？삭제하는 수준을 넘어서 정의된 객체정보를 번거로운 데이터 접근 로직과 예외처리 및 SQL문 작성 등을 거치지 않고 직접 데이터와 연계하고 싶은 개발자들의 열망이 ORM을 탄생시키게 됐다.

자바 언어 기반의 EJB(Enterprise Java Bean)를 통해 ORM을 적용하고자 시도하였으나 컨테이너에 종속적인 비대한 구조로 인해 사용이 복잡하고 유연성이 부족해 점차 개발자들로부터 외면당하게 됐다. 이에 Spring 프레임워크는 EJB의 단점을 극복하는 방안을 제시하면서 대안으로 등장해 ORM이 다시 새롭게 도약하는 발판이 됐다. 이로써 객체모델을 중심으로 데이터베이스를 통합하는 방식의 애플리케이션 개발은 다시 탄력을 받게 된다.

현재 Spring 프레임워크는 TopLink, Hibernate, JDO(Java Data Objects), iBATIS SQL Maps, Apache OJB(ObjectRelational Bridge)를 비롯한 다양한 종류의 ORM 툴 및 persistence 프레임워크를 지원한다. 이들 ORM 솔루션들은 데이터베이스에서 객체를 조회하는 방법, 그리고 객체를 데이터베이스의 테이블과 칼럼 형태로 저장하는 방법에 대해 SQL문을 효과적으로 캡슐화하고 객체의 속성 및 메소드와 연계할 수 있도록 해 준다.

하지만 근본적으로 애플리케이션과 데이터베이스가 완전히 통합된 것이 아니므로 이를 이용해 실제 애플리케이션을 개발하는 경우에는 고려해야 할 사항들이 있다.

ORM 활용 시 고려사항

이렇게 객체모델과 관계모델이 갖는 근본적인 차이 때문에 객체를 테이블에 매핑하는 것은 단순하지 않으며 몇 가지 고려해야 할 사항들이 있다.

- 오브젝트 간의 관계는 테이블 간의 조인으로 매핑될 수 있는데 적절한 최적화가 없다면 매우 높은 성능 부하가 수반될 수 있다.
- 관계모델에는 상속 및 계층의 개념이 존재하지 않는다.
- SQL을 이용하는 경우 SQL문과 객체간의 관계는 모호해질 수 있다.

ORM을 적용한다고 해서 SQL 및 데이터베이스의 락킹(Locking) 모델을 무시해도 된다고 생각하면 곤란하다. ORM은 이질적인 두 가지 모델을 연결하는 가교 역할? 주는 도구로 이해할 필요가 있다. 하지만 구현 환경에 대한 차이를 무시해도 되는 수준의 통합을 아직은 지원해 주고 있지 못하다는 점을 명심해야 한다.

따라서 ORM이 적절하지 않은 경우가 있다는 것을 이해하고 ORM을 선택하기 전에 충분히 그 적용성에 대해 검토할 필요가 있다. 필요한 경우 SQL을 사용하는 것을 회피하지 않는 자세가 필요하다. 일반적으로 ORM의 사용에 적합하지 않는 애플리케이션 요건들을 정리해 보면 다음과 같다.

- 많은 수의 레코드를 높은 빈도로 한꺼번에 저장 및 변경하는 애플리케이션
- OLAP(On-Line Analysis Processing) 애플리케이션
- 데이터의 조회 및 변경을 위해 수작업으로 작성된 SQL 및 저장 프로시저를 주로 이용하는 데이터베이스 환경
- 그 외 순수 SQL 기반 접근 방법을 적용하는 것이 적절한 애플리케이션

데이터베이스의 활용 비중이 높은 애플리케이션 환경이 주를 이루고 있는 것을 확인할 수 있으며, 이러한 경우 JDBC 기반의 접근 방법이 최선의 선택이 될 수 있다. 3번째의 경우, SQL에 대한 효과적인 관리 프레임워크를 제공하고 있는 iBATIS를 고려할 만하다. 그 외 Hibernate와 TopLink와 같이 수준 높은 ORM 제품은 기존 스키마 및 저장 프로시저와 효과적인 연동이 가능하므로 사용을 고려해 볼 필요가 있다.

4번째의 경우에는 비즈니스 로직의 대부분이 데이터베이스에 이미 구현돼 있거나, 데이터베이스 무결성 제약(integrity constraint)이 적용된 경우에 해당하며 이러한 애플리케이션에서는 객체 또는 ORM의 활용 여지가 매우 적어, 데이터베이스 테이블을 도메인 객체로 모델링함으로써 기대할 수 있는 효과가 거의 없다.

하지만 ORM을 사용하는 경우 JDBC와 같은 Low-level 인터페이스를 직접 이용하는 데 비해 예외 처리와 같은 번거로운 작업이 필요하지 않기 때문에 코드량을 20~30% 정도까지 절감하는 것이 가능하므로 최적의 선택을 위해 고려해야 할 것이다.

새로운 프로그래밍 언어들의 등장

C/C++와 자바는 성능과 안정성에서 인정을 받으면서 기업용 애플리케이션을 위한 언어로 자리매김했다. TP-Monitor와 WAS(Web Application Server)라는 미들웨어로 발전해 3계층 아키텍처를 수립하는 데 기여했다. 특히 자바의 경우에는 기업, 인터넷 및 모바일 환경을 아우르는 폭넓은 기능들을 표준 규격으로 발전시켜 오고 있으며, 현재 전성시대를 구가하고 있다.

그 외에도 많은 프로그래밍 언어들이 공개 라이선스 기반으로 개발돼 주로 인터넷 환경에서 다양한 서비스를 제공하는 데 활용되면서 상업적인 성공을 위해 경쟁하고 있다. 기업의 업무 환경이 인터넷과 더더욱 밀접하게 연계되면서 자연스럽게 이러한 언어들이 기업 애플리케이션으로 도입되지 않을까 싶다. 이를 위해서는 적정 수준의 성능 확보와 폭넓은 기능 제공이 관건일 것이다.

필자는 개인적으로 Perl 언어를 좋아한다. 이는 직관적이고 함축적인 문법이 타이핑하기 싫어하는 필자의 성향과 맞아 떨어진 것이기도 하지만, 평소 컨설팅 업무를 수행하면서 데이터베이스에서 데이터를 추출하고 의미있는 정보로 가공하기 위한 목적으로 활용하는 데 아주 요긴하게 이용했던 기억들 때문이다. 이는 Perl이 ‘Practical Extraction and Report Language’의 약자임을 상기한다면 당연한 결과다.

Perl은 1987년 자바에 앞서 발표돼 서버 기반의 동적인 웹 페이지를 표시하도록 웹 서버의 CGI(Common Gateway Interface)를 지원하는 최초의 언어였다. 동일한 로직을 다양한 방식으로 구현할 수 있다는 언어의 표현 능력이 장점이기도 하지만, 여러 사람들이 함께 협력 작업을 하기에는 가독성이 떨어져서 개발 생산성을 높이는 데 어려움이 있다는 단점과 객체지향 프로그래밍 개념이 나중에 적용되면서 문법이 매끄럽지 못해 아쉬운 점으로 지적된다.

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

그럼에도 불구하고 이어서 발표된 파이썬(Python, 1991)과 루비(Ruby, 1995)에 지대한 영향을 끼치게 된다. 데이터의 형식을 미리 지정하지 않아도 실행 과정에서 자동으로 지정되는 Dynamic Typing이나, CPAN(Comprehensive Perl Archive Network)을 통해 쉽게 필요한 라이브러리를 검색하고 온라인으로 바로 제공받을 수 있는 배포 시스템의 지원 등이 대표적인 것들이다.

파이썬은 Perl이 갖는 문법의 다양성과 함축성이, 협력 작업이 수반되는 규모가 큰 프로그램을 개발하는 데 어려움으로 작용하는 점을 보완하면서, 객체지향(OOP), AOP(Aspect-Oriented Programming), 절차적(Structural) 프로그래밍 방식 등을 다양하게 구사할 수 있도록 배려한 것이 특징이다.

루비는 Perl의 장점들과 함께 스몰토크(Smalltalk)의 객체지향 프로그래밍 언어적인 특징을 접목하면서 파이썬보다 더 깔끔한 문법을 구사한다는 평가를 받고 있다. 하지만 후발주자로서 언어 활용의 확산을 촉진하고자 Perl에서 운용하는 CPAN을 본받아 RubyGems라는 패키지 관리 시스템을 운용하고 있으며, 이를 통해 gem이라는 이름으로 패키징된 다양한 라이브러리들을 온라인으로 배포하는 편의를 제공한다.

웹 애플리케이션 프레임워크들의 특징

새로운 프로그래밍 언어들은 각 언어의 특징에 맞는 프레임워크로 기능이 확대되면서 발전하고 있으며 이는 다시 미들웨어로서의 도약을 위한 발판 역할을 할 것이라 예상된다. 각 언어별로 대표적인 웹 애플리케이션 프레임워크(Web Application Framework)에는 다음과 같은 것들이 있으며, 이들이 취하고 있는 아키텍처 상의 특징을 통해 앞으로 새롭게 등장할 미들웨어의 미래상을 미루어 볼 수 있을 것이다.



이들 프레임워크들은 웹 프로그램과 객체모델이 접목돼 완성된 MVC(Model-View-Controller) 패턴을 취하고 있다. 데이터 처리를 담당하는 Model 부분에 기본적으로 ORM이 채용돼 객체의 생성과 함께 데이터베이스에 스키마를 생성하고 영속성 정보를 저장하고 활용할 수 있는 방법들이 기본적으로 제공된다.

따라서 이러한 프레임워크 기반으로 애플리케이션을 개발하는 경우 객체모델 중심으로 설계와 구현이 진행되며, 데이터 모델에 대한 설계 없이 간단한 설정만으로 객체의 영속성 정보를 운용할 수 있는 편의가 제공된다.

발전방향

어떤 언어를 기반으로 하는 미들웨어가 미래의 애플리케이션 서버 특히 기업에서 자바의 위상을 뒤따를지는 아직 알 수 없다. 하지만 프로그래밍 언어가 발전하면서, 그리고 해당 언어를 지원하는 프레임워크가 자리를 잡으면서 시스템 특성에 따른 제약에서 벗어나 좀더 현실에 가까운 컴퓨팅 모델을 지향함에 따라 객체모델에 좀 더 무게가 실릴 것으로 보인다.

이에 따라 관계모델 기반의 데이터베이스는 단순히 영속성 있는 정보를 보관하는 저장소로 그 역할이 축소될 것으로 예상된다. 하지만 완전히 모델 간 통합이 이뤄진 것이 아닌 만큼 당분간 ORM은 애플리케이션 프레임워크를 이루는 중요한 부분으로 그 역할을 지속하게 될 것이다.

필자가 이러한 이야기를 한다고 해서 데이터베이스에 종사하? 일련의 변화는 장기간 하드웨어와 소프트웨어의 발전이 수반돼야 이뤄질 수 있을 것이며, 지금도 메인프레임을 활용하는 곳이 많은 것을 감안한다면 변화는 공존할 것이 틀림없다. 다만 변화가 지향하는 바를 인식하고 인터페이스를 통해 미들웨어와 데이터베이스를 함께 살펴본다면, 좀더 시스템을 깊게 이해할 수 있을 것이라 생각되며 이를 통해 좋은 결과물을 만들어 낼 수 있지 않을까 기대해 본다.

첫 회에서는 미들웨어의 변화를 통해 데이터베이스와의 인터페이스가 어떻게 발전돼 왔는지를 짚어 보았다. 다음 회에서는 데이터베이스의 변화를 통해 미들웨어와 데이터베이스 간 인터페이스가 SQL에서 No SQL로 변화하는 과정을 짚어보고 이에 대한 발전 전망을 알아보고자 한다.

출처 : 한국데이터베이스진흥원

제공 : DB포탈사이트 DBguide.net