ArtWorker's DataBase

“그 다음에 할 일은 사용자의 관점에서 시스템을 설계해서 구현하는 것입니다. 사용자의 입장을 용인하는 것만으로는 부족합니다. 새로운 관점을 만들어 내는 이들은 바로 사용자입니다. 그렇기 때문에 우리의 기술에는 그들의 관점이 반영되어야 하는 것입니다. 우리가 사용자에 대해 불평만 해댄다면 정작 중요한 것을 잃게 될 겁니다. 사용자는 뭔가를 증명하기 위해 기술을 사용하는 게 아닙니다. 자신의 틀에 들어맞기 때문에 사용할 뿐입니다.”

special report 3 액티브 레코드 vs 하이버네이트 레일스의 꽃,

액티브 레코드 집중 분석

필자는 주로 스프링과 하이버네이트 등 자바 기반의 POJO 프레임워크를 이용하여 서비스를 개발해왔는데, 루비와 레일스를 사용해본 후 이 둘의 매력에 푹 빠져 버렸다. 그리고 최근 새 서비스 개발을 위해 다양한 자바 프레임워크와 레일스 등을 비교 검토한 결과, 최종적으로 레일스를 쓰기로 결정하였다. 이 결정에는 여러 이유가 있었지만 레일스의 퍼시스턴스 프레임워크인 액티브 레코드가 큰 비중을 차지했다. 3부에서는 이 액티브 레코드에 대해 설명한다.

최근 루비 언어와 루비 온 레일스(Ruby on Rails, 이하 ‘레일스’) 프레임워크에 대한 관심이 늘고 있다. Martin Fowler, Bruce Tate, David Geary 등 많은 유명 컨설턴트, 개발자들이 레일스에 대해 호의적으로 언급하고, 레일스를 이용한 상용 서비스들이 속속 등장함에 따라 레일스에 대한 신뢰도 또한 높아지고 있다. 특히 다수의 자바 관련 서적으로 졸트상을 수상한 Bruce Tate는 최근 루비 언어의 우월성을 주장하는 『From Java to Ruby』라는 문제작(?)을 출간하기도 했다.

레일스만의 매력

사실 레일스의 컨트롤러와 뷰 단을 담당하는 ActionPack의 아키텍처 자체는 Webwork의 아키텍처와 크게 다르지 않다(물론 동적 언어인 루비의 특성으로 인한 다양한 이점이 존재하며, RJS 등 통합된 웹2.0 지원은 매우 편리하다). 하지만 퍼시스턴스를 담당하는 액티브 레코드는 자바 진영의 가장 대표적인 퍼시스턴스 프레임워크인 하이버네이트와 전반적인 아키텍처가 달라 지적인 측면에서 흥미로웠고, 사용하기에도 훨씬 편리했다. 실제로 필자는 2년 간 내부 서비스에서 상용 결제 시스템에 이르기까지 하이버네이트를 사용해 왔고, 하이버네이트의 생산성 및 안정성에 꽤 만족하고 있다. 하지만 액티브 레코드를 학습한 직후, 액티브 레코드에 대한 기본적인 지식밖에 없는 상태에서도 액티브 레코드를 이용한 개발이 더 재미있고 개발 속도도 배 이상 빠른 느낌을 받았다. 또한 라이브러리 자체의 확장이 거의 불가능한 하이버네이트에 비해 액티브 레코드는 사용 목적에 맞게 라이브러리를 쉽게 수정하거나 확장할 수 있다는 점도 마음에 들었다.
필자의 경험에서 볼 때 같은 기능의 새로운 웹 서비스를 만들 경우 레일스의 전반적인 생산성이 JEE의 그것보다 뛰어나다. Bruce Tate는 프로젝트 경험을 통해 생산성이 8배 정도 우월하다고 주장한다. 하지만 레거시 연동이나 크리티컬한 엔터프라이즈 시스템 구축 등에는 JEE가 레일스보다 우수하다할 수 있다. 또한 스크립트 언어인 루비의 특성 상 소스코드가 공개될 수밖에 없기 때문에 상용 소프트웨어 솔루션을 레일스로 만드는 데는 무리가 있다. ‘은탄환은 없다’란 말대로 모든 면에서 뛰어난 해결책은 찾기 어려울 것이다. 모든 선택에는 트레이드 오프가 있게 마련이니까. 그러므로 두리뭉실 ‘레일스가 우수하다, 혹은 JEE가 우수하다’와 같은 소모적인 논쟁 대신, 수행하려는 프로젝트의 목적과 성격을 검토해 본 후 올바른 해결책을 선택하는 것이 현명한 방법일 것이다.
물론 올바른 선택을 하기 위해서는 당연히 선택의 대상을 이해하고 비교할 수 있는 능력이 필요하다. 여기서는 폭발적인 인기를 얻고 있는 레일스의 핵심 모듈 중 하나인 액티브 레코드와 자바 진영의 대표적인 퍼시스턴스 프레임워크인 하이버네이트를 비교분석하여 개발자들에게 선택에 필요한 정보를 조금이나마 제공하고자 한다.

ORM 소개

본격적으로 두 프레임워크를 비교하기에 앞서 ORM(Object/ Relational Mapping)이 무엇이고 어떤 문제를 해결해 주는지 간단히 살펴보고 넘어가기로 하자. 객체 지향 세계에서는 시스템을 객체와 객체들 사이의 관계를 이용하여 프로그래밍 한다. 반면, 관계형 데이터베이스에서는 데이터를 집합 이론을 이용하여 저장하고 처리한다. 대부분의 시스템은 데이터베이스를 다루게 되는데 이때 객체 세계와 집합 세계의 근본적인 철학의 차이로 인해 많은 문제가 생기게 된다. 구체적으로 열거해 보면 다음과 같다(이 내용은 Gavin King과 Christian Bauer가 쓴 『Hibernate in Action』의 1장에서 잘 설명하고 있으므로 관심 있는 독자는 시간을 내어 읽어 보길 바란다).

● 입자도(granularity)의 차이
● 서브 타입 문제
● 아이덴티티(identity) 문제
● 연관 관계와 관련된 문제
● 객체 그래프 네비게이션 문제

초기에는 이러한 차이를 개발자들의 노고로 해결하였으나 이곳 저곳에서 많은 불만이 쏟아져 나왔다. 필자 역시 이를 위한 간단한 라이브러리를 만들어 사용하며, 이러한 문제를 해결해 줄 수 있는 프레임워크가 나오기를 기다릴 정도였다(물론 이러한 문제를 해결하기 위한 다양한 방법이 현재 개발되고 있다).
그 중 하나가 객체 지향 데이터베이스인데 데이터베이스가 객체 지향 개념을 이용하여 데이터를 다루는 것이었다. 하지만 성능, 개발자 풀 등의 여러 문제로 인해 초기의 목적을 달성하지 못한 것으로 판단된다. 현재의 많은 데이터베이스들이 객체-관계형 데이터베이스를 표방하지만 실무에서는 관계형 데이터베이스 기능만을 이용하는 것이 대부분이다.
다른 해결 방법은 컴퓨터공학의 전통적인 해결 방법인 추상화를 도입하는 것이었다. 즉 프로그래밍 단에 객체와 관계형 데이터베이스를 매핑해 주는 새로운 레이어를 도입하고, 프로그래머는 이 레이어를 이용하여 객체지향적으로 데이터베이스 프로그래밍을 하는 것이다. 이 방법은 큰 성공을 거두었고, 현재 ORM이라 통칭된다. 우리가 살펴보려는 액티브 레코드와 하이버네이트 모두 이러한 역할을 하는 ORM 프레임워크이다.
본격적인 내용에 들어가기에 앞서 꼭 짚고 넘어가야 하는 것이 있다면 ORM이 거창한 것이 아니라는 사실이다. ORM의 가장 큰 목적은 개발자들이 좀 더 쉽고 직관적으로 데이터베이스 프로그래밍을 할 수 있도록 해주는 것, 그 뿐이다. 더 구체적으로 말하면 ‘DAO(Data Access Objects)를 얼마나 편하게 만들 수 있느냐?’이다. ORM을 사용하지 않아도 DAO를 통해 유연하고, 확장성 있는 시스템을 얼마든지 만들 수 있다. 또한 DAO를 사용하는 클라이언트는 DAO 구현체가 ORM을 사용했는지 아니면 JDBC 등을 이용해 직접 코딩했는지 알지 못한다. 다만 같은 기능을 구현할 때 걸리는 시간과 들어가는 노력이 다를 뿐이다.
물론 지연된 로딩(Lazy Loading)과 캐싱 등을 통해 성능을 향상하는 등의 다양한 이슈가 있지만, ORM의 기본적이며 가장 중요한 목적은 ‘보다 편리하고 빠른 데이터베이스 프로그래밍’, 보다 세련되게 표현해 ‘기민한 데이터베이스 프로그래밍’을 하는 데 있다는 사실을 명심하길 바란다. 그러면 이러한 관점에서 두 프레임워크를 비교해 보기로 하자.

아키텍처

앞에서 이야기했듯이 액티브 레코드와 하이버네이트의 아키텍처가 매우 다른 방식으로 구성되어 있어 흥미롭다. 액티브 레코드는 이름이 의미하듯 액티브 레코드 패턴을 실체화하고 있고, 하이버네이트는 Data Mapper 패턴을 실체화하고 있다. 우선 액티브 레코드 패턴의 정의는 <그림 1>과 같다. 그리고 Data Mapper 패턴의 정의는 <그림 2>와 같다.

Person이란 객체를 액티브 레코드 패턴을 사용하여 실체화 했다면 <리스트 1>과 같이 사용하게 될 것이다. 이때 find 등의 연산은 특정 로우(객체)가 아닌 테이블(클래스)을 대상으로 하는 연산이므로 static 메소드로 구현하게 되며, update는 특정 로우를 대상(객체)으로 하므로 인스턴스 메소드로 구현하게 된다(물론 bulk 연산인 update_all이 있다면 static 메소드로 구현해야 할 것이다).

<리스트 1> 자바 버전과 루비 버전

/* 자바 버전 */
Person person = Person.find(1); // 테이블에서 PK가 1인 로우를 로딩
person.setFirstName("Song");
person.update(); // person 객체를 이용하여 해당 로우를 업데이트

# 루비 버전 - 액티브 레코드 예제이다.
person = Person.find(1) # find는 클래스 메소드
person.first_name = "Song"
person.update # update는 인스턴스 메소드

반면에 <리스트 2>는 Data Mapper 패턴을 사용한 것이다. 이 코드는 실제 하이버네이트를 사용하는 예를 보여준다.

<리스트 2> Data Mapper 패턴의 이용

/* session과 같은 별도의 Data Mapper가 필요함
Session이 범용 Data Mapper이다. */
Session session = sessionFactory.openSession();
// session을 이용하여 데이터베이스 조작
Person person = (Person)session.load(1);
person.setFirstName("Song");
session.update(person);
session.close();

액티브 레코드 패턴과 Data Mapper 패턴을 비교해보자. 전반적인 사용은 액티브 레코드 패턴이 편리하다. 별도의 매퍼 없이 모델 객체를 조작하면 되기 때문이다. 이때 Person과 같은 모델 객체는 그 자체가 DAO가 된다. 이때 Person에 CRUD 메소드(create, read, update, delete) 뿐 아니라 getTexableEarnings와 같은 메소드도 추가할 수 있다. Data Mapper 패턴은 여러 데이터베이스를 이용할 경우 연결 관리나 트랜잭션 관리 등에 편리하다. 하지만 DAO를 별도로 작성해야 하는 부담이 따른다. 이러한 불편을 극복하기 위해 하이버네이트는 Generic DAO 패턴을 소개(http://www.hibernate.org/328.html)하는데, 이는 액티브 레코드 패턴과 상당히 유사한 점이 많다. 하지만 POJO 당 하나의 DAO를 만들어야 하는 점과 DAOFactory 관리 및 스프링 설정 파일 관리는 여전히 부담으로 다가온다.

OR 매핑 방법

액티브 레코드에서는 ‘테이블 이름이 클래스 이름의 소문자 복수형’이라는 등의 몇 가지 약속(convention)만 지키면 별도의 설정이 필요 없다. 그 예는 <표 2>와 같다.

테이블 이름은 소문자, 복수형이고 여러 단어로 구분되어 있을 경우는 ‘_’를 구분자로 사용한다. 이러한 특징은 레일스 전반에 흐르고 있는 ‘Convention over Configuration’이란 철학이 반영된 것이다. 만약 people이라는 테이블이 있고, 객체를 통해 테이블에 데이터를 저장하고 싶다면 다음과 같이 Person 클래스를 선언하면 된다(보통은 ‘script/generate model Person’식으로 스크립트를 실행해 생성한다).

class Person < ActiveRecord::Base
end

매우 단순하지 않은가? ActiveRecord::Base를 상속한 것을 제외하면 어떠한 코드도 없다. 심지어 객체의 속성도 선언하지 않았지만, persons 테이블의 컬럼명을 Person 클래스의 속성으로 사용할 수 있다. persons 테이블에 first_name 컬럼이 있다면, person.first_name과 같이 사용할 수 있는 것이다. 액티브 레코드::Base를 상속하기만 하면 액티브 레코드 패턴을 실체화할 수 있으니 상당히 편리하다.
그런데 만약, 테이블 이름으로 person을 사용할 수밖에 없는 경우에는 어떻게 해야 할까? 액티브 레코드는 이러한 경우를 대비하여 추가 설정이 가능하도록 지원한다. Person 클래스를 person 테이블에 매핑하고 싶다면 다음과 같이 설정해주면 된다.

class Person < ActiveRecord::Base
set_table_name “person”
end

반면, 하이버네이트에서는 .hbm.xml 확장자를 가진 설정 파일을 이용하여 매핑한다. 이때, 하이버네이트에서 제공하는 Ant 태스크를 이용하여 클래스 파일에서 설정 파일을 생성할 수 있고, 또한 테이블을 이용하여 설정 파일을 생성할 수 있다. 반대로 설정 파일에서 클래스 파일과 테이블을 생성할 수도 있다. 즉 클래스 파일, 설정 파일, 혹은 테이블 가운데 하나만 있으면 나머지를 생성할 수 있다. 이를 정리하면 <그림 3>과 같다.

하지만 클래스 파일과 sql 파일 혹은 테이블로부터 설정 파일의 다양한 옵션을 생성하기란 어렵다. 따라서 필자의 경우는 hbm 설정 파일을 기준으로 삼아 작업한다(xdoclet을 이용하여 클래스 파일을 기준으로 삼을 수도 있다). 예를 들면 <리스트 3>과 같다.

<리스트 3> hbm 설정 파일을 기준으로 한 예

publc class Person{
private Long id; // PK를 위한 것
private String firstName;
private String secondName;
// 기타 속성들…

// getter, setter들…
}
[Person.java]

<hibernate-mapping>
<class name="package.Person" table="people">
<id name="id" column="id">
<generator class="native"/>
</id>
<property name="firstName" type=vString" column="first_name"/>
<property name="secondName" type="String" column="second_name"/>
</class>
</hibernate-mapping>
[Person.hbm.xml]

관계

ORM 툴의 가장 막강한 기능 중 하나가 바로 객체 간의 관계를 데이터베이스에 저장하거나, 데이터베이스에 저장되어 있는 정보를 객체 간의 관계에 매핑하여 가져오는 것이다. 그리고 액티브 레코드와 하이버네이트 모두 이러한 기능을 충실히 지원한다. 하이버네이트와 비교해 이를 정리하고(<표 3> 참조), 액티브 레코드 예제를 살펴보기로 하자.

이제 레일스 홈페이지의 위키 페이지에 있는 포럼 예제를 살펴보기로 하자.

<리스트 4> 코드 예(forum.sql)

CREATE TABLE 'categories' (
'id' int(11) NOT NULL auto_increment,
'name' varchar(50) DEFAULT NULL,
PRIMARY KEY ('id')
);

CREATE TABLE 'forums' (
'id' int(11) NOT NULL auto_increment,
'category_id' int(11) DEFAULT NULL,
'name' varchar(50) DEFAULT NULL,
'description' varchar(100) DEFAULT NULL,
PRIMARY KEY ('id')
);

CREATE TABLE 'messages' (
'id' int(11) NOT NULL auto_increment,
'type' varchar(50) DEFAULT NULL,
'forum_id' int(11) DEFAULT NULL,
'author_id' int(11) DEFAULT NULL,
'topic_id' int(11) DEFAULT NULL,
'title' varchar(255) DEFAULT NULL,
'content' text,
'written_on' datetime DEFAULT NULL,
PRIMARY KEY ('id')
);

위와 같은 테이블이 있을 때 <리스트 5>와 같이 모델 클래스를 만들면 된다. 이때, ERD에 virtual로 표시되어 있는 Topics와 Replies는 실제로는 없는 테이블이다. 물리적으로는 messages 테이블이 존재하며, ‘단일 테이블 상속’을 통해 Topics와 Replies를 사용한다. <리스트 5>의 모델 클래스에서 Topic과 Reply는 Message 클래스를 상속하고 있으며, 액티브 레코드는 내부적으로 messages 테이블의 type 컬럼 값을 통해 이들의 타입을 구분한다. type 컬럼에는 Message, Topic, Reply 등 해당 클래스명이 들어가게 된다. 하이버네이트도 설정파일에서 구분자(discriminator) 설정을 통해 상속을 처리할 수 있게 해준다.

<리스트 5> 모델 클래스 구현

class Author < ActiveRecord::Base
has_many :replies
end
class Category < ActiveRecord::Base
has_many :forums
end
class Forum < ActiveRecord::Base
belongs_to :category
has_many :topics
end
class Message < ActiveRecord::Base
has_one :author
end
class Topic < Message
belongs_to :forum
has_many :replies
end
class Reply < Message
belongs_to :topic
end

이제 모델을 활용해 보자. ‘Book’이란 이름(name)의 카테고리에 있는 포럼을 찾고 싶다면 다음과 같이 한다. 이때 category는 forums 테이블의 category_id를 이용하여 해당 포럼들(forums)을 찾게 된다. 이 역시 약속(convention)이며, 추가로 설정이 가능하다.

@category = Category.find(:all, :conditions => [“name = ?”, “Book”])
@forum = category.forums

만약 카테고리에서 시작해서 토픽의 저자를 찾아 출력하고 싶다면 다음과 같이 한다.

@category = Category.find(:all, :conditions => [“name = ?”, “Book”])
@category.forums.each do |forum|
forum.topics.each do |topic|
print topic.author.name # 토픽에서 저자를 찾아 이름을 출력한다.
end
end

아울러 Music이라는 카테고리를 만들고, 이 카테고리에 Music Forum을 만들고 싶다면 다음과 같이 하면 된다.

@category = Category.new(“name” => “Music”)
@category.forums << Forum.new(“name” => “Music Forum”,
“description” => “Forum for Music”)
@category.save # forum도 함께 저장된다.
@category.delete # category 로우만 지워지고, forum은 지워지지 않는다.

이와 비슷한 코드를 하이버네이트를 이용해 작성하면 다음과 같다.

Session session = sessionFactory.openSession();
Category category = new Category(“Music”);
category.getForums().put(new Forum(“Music Forum”, “Forum for Music”));
session.save(category); # 올바르게 설정했다면 포럼도 저장
session.delete(category); # casacade=“all”로 했다면 forum 로우도 지워짐

처음에는 루비 언어의 문법이 생소하겠지만, 익숙해지면 간결한 문법에 오히려 매력을 느낄 것이다. 위의 내용을 하이버네이트를 이용하여 구현하는 것은 독자분들을 위한 과제로 남긴다. 설정 파일까지 셈한다면 액티브 레코드를 사용했을 때에 비해 전체 라인수가 상당히 늘어나겠지만, 어노테이션과 Generic DAO를 이용하면 상당히 수월해질 것이다.

쿼리 언어

ORM을 사용하면 데이터베이스의 퍼시스턴스 레이어에 쿼리를 보내게 되므로 별도의 쿼리 언어를 도입하는 것이 일반적이다. 하지만 두 프레임워크는 이 부분에서 상당히 다른 접근을 취하고 있다. 액티브 레코드의 쿼리 언어는 몇 가지 편리한 기능이 있지만 기본적으로 SQL과 다를 바 없다. conditions는 where 절, order는 order by 절에 해당한다.

person = Person.find(:first) # select * from people로 가져온 첫번째 객체를 리턴
persons = Person.find(:first, :conditions => [ “user_name = ?”, user_name])
persons = Person.find(:first, :order => “created_on DESC”)

반면 하이버네이트는 HQL(Hibernate Query Language)라는 새로운 쿼리 언어를 만들었다. HQL이 SQL과 흡사하기는 하지만, 다른 부분도 적지 않다. 특히 HQL은 데이터베이스 중립적인 언어로 표현되며, 설정한 Dialect를 통해 각 데이터베이스에 최적화된 SQL로 변환되어 실행된다. HQL을 사용할 때는 테이블이 아니라 클래스(객체)에 질의한다는 사고가 필요하다.

List persons = session.createQuery(“from Person”).setMax Results(1).list();
persons = session.createQuery(“from Person person where person.user_name
= :user_name).setString(“user_name”, username).list();
persons = session.createQuery(“from Person person order by person.created_on DESC).setMaxResults(1).list();

하지만 하이버네이트를 사용하다 보면 가끔씩 하이버네이트의 HQL 파서 때문에 애를 먹을 수 있다. 이에 대해서는 http:// blog.naver.com/scroco/50003559019를 참조하길 바란다. 마지막으로 SQL을 사용할 수 밖에 없는 경우가 있게 마련이다. 이러한 경우를 대비하여 액티브 레코드는 find_by_sql 메소드를, 하이버네이트는 Native SQL을 사용할 수 있도록 지원한다.

확장성

ORM 프레임워크를 확장하여 새로운 기능을 추가하고 이를 재사용할 수 있다면 좋을 것이다. 액티브 레코드는 루비 언어의 믹스-인(Mix-in) 기능을 이용한 플러그인을 통해 이러한 확장을 가능하게 해준다. 예를 들어 트리 자료 구조는 메뉴 등 여러 곳에서 재사용할 수 있다. 액티브 레코드는 이를 위해 acts_as_tree를 지원한다. 다음과 같이 사용하면 된다.

class Menu < ActiveRecord::Base
acts_as_tree :order => “name”
end

acts_as_tree를 이용하면 children이라는 속성을 이용하여 자식들을 조작할 수 있다. 단, acts_as_tree를 사용하려면 해당 테이블에 부모의 PK를 저장하는 parent_id란 이름의 컬럼이 필요하다(물론 다른 이름으로 설정 가능하다). 트리 구조의 부서 조직을 표현하면 <리스트 6>과 같다.

<리스트 6>

root = Menu.create(:name=>"부서")
development = root.children.create(:name => "개발")
marketing = root.children.create(:name => "마케팅");
payment_development = development.children.create(:name => "페이먼트 개발")
web_development = development.children.create(:name => "웹 개발")
domestic_marketing = marketing.children.create(:name => "국내 마케팅")
foreign_marketing = marketing.children.create(:name => "해외 마케팅")

이러한 기능은 모델을 재사용할 수 있다는 점에서 생산성 측면에 큰 도움이 된다. 이 외에도 레일스는 순서있는 리스트를 쉽게 표현할 수 있는 acts_as_list를 기본적으로 제공하며, 태깅 기능을 추가해 주는 acts_as_taggable, 코멘트를 붙일 수 있게 해주는 acts_as_commentable, 가격을 붙일 수 있게 해주는 acts_as_ pricible 등의 오픈 소스 플러그인을 포함한다. 해당 플러그인이 요구하는 컬럼만 추가하면 유의미한 모델 기능을 편리하게 재사용할 수 있고, 또한 편리한 플러그인을 계속 추가할 수 있다. 이와 같은 확장 기능은 루비의 개방성과 믹스-인 기능 덕분이며, 하이버네이트에서는 볼 수 없다. Bruce Tate의 『From Java to Ruby』에 담긴 인터뷰에서 레일스를 만든 David Heinemeier Hansson는 다음과 같은 이야기를 했다.
‘자바 모델에서는 개발자들이 프레임워크를 변경하려 시도조차 하지 않을 것이다. 예를 들어 하이버네이트는 Gavin King이 만드는 무엇이고, 스트럿츠는 몇 년 동안 동결되어 있다. 크기와 복잡성이 그 원인이다. 하지만 루비 커뮤니티에서는 그렇지 않다. 프레임워크를 확장하거나 수정하는 일이 쉽기 때문에 누구라도 적절한 시간 안에 이러한 작업을 수행할 수 있다. 우리는 레일스를 처음 사용한 날 밤에 패치에 기여한 많은 사람들을 알고 있다. 자바 프로젝트의 경우 하이버네이트, 스트럿츠 혹은 스프링이 정확히 원하던 것이 아니어서 문제가 되는 경우가 있다. 하지만 루비는 패치를 통해 액티브 레코드 혹은 레일스를 수정할 수 있다. 그리고 그 비용은 매우 적다. 우리는 모든 레일스 프로그래머들이 이러한 과정을 통해 프로젝트에 기여하길 바란다.’ - Bruce Tate의 『From Java to Ruby』140p

성능 튜닝과 트랜잭션

ORM은 지연된 로딩(Lazy Loading)과 캐싱 등을 이용하여 성능을 향상시킬 수 있도록 도와준다. 앞에서 살펴본 코드를 다시 한번 보도록 하자.

@category = Category.find(:all, :conditions => [“name = ?”, “Book”])
@forum = category.forums

첫번째 줄에서 category를 가져올 때 forum은 가져오지 않으며, forum은 실제로 사용하는 시점에 질의를 해서 데이터를 가져온다. 이는 forum을 사용하는 빈도가 적을 때는 성능 향상에 도움이 될 수 있다. 하지만 forum을 항상 사용한다면, 오히려 질의를 한번 더 하는 꼴이 될 것이다(이를 N+1 문제라 한다). 하지만 액티브 레코드에서는 항상 지연된 로딩을 하기 때문에 현재로서는 이를 해결할 방법이 없다. 반면 하이버네이트는 설정 옵션을 통해 이 문제를 해결할 수 있다.
또한 하이버네이트는 다양한 캐싱 전략을 이용하여 불필요한 DB 액세스를 줄일 수 있지만, 액티브 레코드는 아직 이러한 기능을 제공하지 않는다. 트랜잭션 처리에 있어서도 하이버네이트는 여러 데이터베이스에 걸친 글로벌 트랜잭션 처리(Two-phase commit)를 지원하지만, 액티브 레코드는 지원하지 않는다(흉내낼 수는 있다).

테스트

테스트에 있어서 레일스는 매우 쾌적한 환경을 제공한다. 애초에 애플리케이션을 product, development, test 환경으로 분리하여 실행시킬 수 있도록 제공할 정도다. 그리고 자체에 JUnit과 비슷한 테스트 프레임워크를 제공하며, Fixture를 이용하여 테스트 데이터를 파일에 넣어 저장한 후 기본적인 연산 테스트에서 비즈니스 로직이 담긴 연산까지 손쉽게 테스트할 수 있다. 하이버네이트를 이용하여 비슷한 레벨의 테스트를 하려면 더 많은 시간과 노력이 요구된다.

로깅

액티브 레코드의 쿼리 언어는 앞에서 보았듯이 사실상 SQL이기 때문에 로깅 정보에 SQL 쿼리를 남길 수 있다. 반면 하이버네이트는 HQL을 SQL로 자동 변환하여 실행하기 때문에 정보가 직접적이지 않다. 또한 SQL을 출력하도록 설정 파일을 수정하더라도 하이버네이트가 내부적으로 PreparedStatement를 이용하기 때문에 설정한 파라미터 값 대신 ‘?’이 찍혀 나온다. 이 값까지 볼 수 있도록 설정하면 쿼리 하나마다 거대한 트리가 출력되므로 별 도움이 되지 않는다. 그래서 필자는 JDBC를 직접 사용할 경우에는 PreparedStatmenent를 래핑하여 로깅 정보를 찍을 수 있도록 구현(Decorator 패턴을 사용)한 Loggable PreparedStatement를, 하이버네이트 사용 시에는 http://ww w.p6spy.com에서 p6spy를 다운로드 받아 이용한다.

기타 편리한 기능들

마지막으로 앞에서 살펴보진 않았지만 유용하게 사용할 수 있는 액티브 레코드의 기능을 설명하기로 한다. 우선 유효성 검증을 도와주는 수많은 헬퍼들이 있다.

<리스트 7> 유효성 검증을 위한 헬퍼들

class Person < ActiveRecord::Base
# first_name 필드의 최고 길이를 30으로 제한한다.
validates_length_of :first_name, :maximum=>30
# last_name의 길이를 30으로 제한하고, 위반한 경우
# :message에서 설정한 에러 메시지를 돌려준다.
validates_length_of :last_name, :maximum=>30,
:message=>"글자수가 %d보다 작아야 합니다."
end

이 예는 길이를 검증하는 방법을 보여준다. 이 외에도 valida te, validate_on_create, validate_on_update, validates_accep tance_of, validates_associated, validates_confirmation_of, validates_each, validates_exclusion_of, validates_format_of, validates_inclusion_of, validates_length_of, validates_ numericality_of, validates_presence_of, validates_size_of, validates_uniqueness_of 등의 많은 헬퍼들이 있으므로 유효성 검증을 손쉽게 처리할 수 있다.
또한 insert, update, save, delete 연산 전후에 호출되는 메소드나 객체를 등록할 수 있는 콜백(callback) 기능, 그리고 여기서 한걸음 더 나아간 옵저버(Observer) 기능을 제공한다. 단순한 콜백 사용 예를 살펴보자(<리스트 8> 참조). 이 콜백은 특정 토픽을 삭제하기 전에 해당 토픽의 부모를 먼저 삭제하도록 해준다.

<리스트 8> 단순한 콜백 사용 예

class Topic < ActiveRecord::Base
before_destroy :destroy_parents
def destroy_parents
self.class.delete_all "parent_id = #{id}"
end
end

앞에서 다음과 같은 코드를 보았을 것이다. 콜백을 이용하면 category 삭제 시, forum도 연쇄적으로 삭제할 수 있다.

@category.delete # category 로우만 지워지고, forum은 지워지지 않는다.

생산성 차이가 그 핵심

지금까지 액티브 레코드와 하이버네이트 전반에 대해 비교했다. 필자는 개인적으로 액티브 레코드는 경쾌하고, 하이버네이트는 묵직하며 정교하다란 생각을 가지고 있다. 액티브 레코드는 개발이 빠르고 편리한 반면, 하이버네이트는 레거시 연동에서 엔터프라이즈 환경에 이르기까지 광범위한 폭을 어우르는 전천후 ORM이기 때문이다.
그런데 이들 두 프레임워크 사이에는 엄연한 생산성 차이가 존재한다. 무엇 때문일까? 이는 루비와 자바, 바로 두 언어의 차이에서 비롯된다. 액티브 레코드의 생산성은 루비의 클로져, 동적 타입, 선택적 파라미터, 오픈 클래스, 메시지 전달 및 missing_ method 처리 메커니즘 덕분이다. 루비는 진정 액티브 레코드, 더 나아가 레일스의 생산성을 빛내주는 보석이며, 자바 기반의 JEE는 당분간 이러한 생산성 차이를 극복하지 못할 듯 싶다.

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