블로그 이미지
Are WE ready? FlyingMate

카테고리

분류 전체보기 (20)
소소하지 않은 일상 (20)
Total57,273
Today0
Yesterday7

'Rails'에 해당되는 글 3건

  1. 2008/04/23 SimpleDB with RightAws (2)
  2. 2008/02/24 짓궂은 이야기 (4)
  3. 2008/02/23 레일스의 클래스 확장 방식
notice: 같은 글을 스프링로그에도 적었는데, 그 쪽이 더 보기 편하다.
update: 마침 RightScale의 투자유치 소식이 들린다.

모델 하나를 ActiveRecord에서 SimpleDB로 전환하였다.
RightScale사의 RightAws Gem을 이용하였다. 유효성 검증(Validation)과 다른 모델과의 연관관계(Association)에 대한 고민은 일단 미뤄두고, 모델과 SimpleDB 사이의 가장 기본적인 연결을 목표로 하였다.

간단한 모델이라서 간단한 작업일 줄 알았는데 생각보다 손이 많이 갔다. ComplexDB라고 이름 붙이고 싶을 정도다. SimpleDB 자체가 복잡해서가 아니라 그 동안 ActiveRecord가 ORM으로서 너무나 많은 것들을 해주고 있었기 때문에, 기존의 기능들을 포기하지 않으면서 SimpleDB를 사용하려다보면 신경써야 할 부분이 많아진 것이다.

우선 Gem을 설치하고, config/environment.rb에서 RightAws Gem을 require한다. Amazon SimpleDB 계정에 연결하는 코드도 담는다.


sudo gem install right_aws

# config/environment.rb
require 'sdb/active_sdb'
require 'sdb/right_sdb_interface'
RightAws::ActiveSdb.establish_connection(access_key, secret_key)


도메인(데이터베이스에서의 테이블)을 만들어야 하는데 애플리케이션 배포시 한 번만 만들어주면 되므로 애플리케이션 코드에 넣지 않고 irb쉘에서 생성해주었다.


irb> require 'sdb/active_sdb'
irb> require 'sdb/right_sdb_interface'
irb> RightAws::ActiveSdb.establish_connection(access_key, secret_key)
irb> class Product < RightAws::ActiveSdb::Base
irb>   set_domain_name :products
irb> end
irb> Product.create_domain


set_domain_name 은 해당 모델의 도메인 이름을 명시해주는 부분인데, irb나 루비파일에서 도메인을 생성할 때, set_domain_name을 해주지 않고 Product.create_domain을 바로 하면 디폴트로 product라는 이름의 도메인이 생성된다. 반대로 레일스 환경(ruby script/console 포함)에서 Product.create_domain을 해주면 products라는 복수형의 도메인이 생성된다.

RightAWS는 ActiveSupport의 로드 여부를 파악해서 로드되어있으면 복수형의 도메인명을 디폴트로, 로드되어 있지 않으면 단수형을 디폴트로 잡는다. 즉 레일스 환경이 아니더라도 require 'activesupport'를 통해 복수형 도메인명을 디폴트로 사용할 수 있다. 복잡하다 싶으면 set_domain_name을 사용하면 된다. 아무래도 ActiveRecord의 컨벤션에 익숙해지다보니 복수형이 마음이 편하다.

그 다음은 모델 클래스를 재정의하는 것이다. 위의 irb에서도 domain을 생성하기 위해 모델 클래스를 잠깐 정의했는데, 위와 동일한 형태로 레일스 애플리케이션의 모델 코드에서 사용할 수 있다. class Product < ActiveRecord::Base로 시작되던 코드를 class Product < RightAws::ActiveSdb::Base로 바꾼다.

나는 좀 다르게 사용했는데 RightAws를 모델이 바로 상속하지 않고, 중간에 다른 클래스가 RightAws를 상속하고, 그 클래스를 모델이 상속하는 형태로 구성해보았다. 틀림없이 RightAws의 코드를 수정하거나 메서드를 다시 정의하거나 새롭게 추가해야 할 일이 생길 것이기 때문이다. RightAws가 플러그인이 아니라 젬이기 때문에 라이브러리 코드를 직접 수정하지 않는게 좋고, 모델들에 공통적으로 적용할 내용을 개별 모델 코드에 중복해서 작성하는 것도 피하기 위해서이다.

중간에 마음대로 만지작거릴 수 있는 클래스를 하나 만든 것인데, active_item.rb파일을 lib에 담아두었고, 그 파일 안에 ActiveItem 모듈과 Base 클래스를 정의했다. 아래에 전체 코드가 있다. 좀 정돈이 안 되어있고 미완성이지만 동작하기는 한다. SimpleDB를 본격적으로 사용하게 된다면 좀더 가꾸어볼 생각이다. 스카폴드로 만들어진 컨트롤러와 뷰에서는 코드 수정 없이 SimpleDB를 적용할 수 있도록 find메서드와 destroy, update_attributes, to_s 정도를 다시 정의했다.

module ActiveItem
  class Base < RightAws::ActiveSdb::Base    
    @@attributes = []
    class << self
      def attributes    
        if @@attributes.blank?
          first = find(:first)
          @@attributes = first.attributes.keys.select {|attr| attr != 'id'}
        end
        @@attributes
      end    

      def find(*args)
        result = super(*args)
        result.is_a?(Enumerable) ? result.each(&:reload) : result.reload
        result
      end

      def find_all_by_(format_str, args, limit=nil)
        results = super(format_str, args, limit)
        results.each(&:reload)
        results
      end

      def find_by_(format_str, args)
        result = super(format_str, args)
        result.reload
        result
      end    
    end  

    def method_generated
      @@method_generated ||= false
    end

    def method_generated=(value)
      @@method_generated = value
    end

    def method_missing(method_id, *args)
      method_name = method_id.to_s.match(/\w+/)[0]
      if !self.method_generated
        self.class.attributes.each do |attr|
          method_body = <<-EOV
            def #{attr}
              self[:#{attr}]
            end

            def #{attr}=(value)
              self[:#{attr}] = value
            end
          EOV
          self.class.class_eval(method_body, __FILE__, __LINE__)
        end
        self.method_generated = true
      end

      if self.class.attributes.include?(method_name)
        send(method_id, *args)
      else
        super
      end
    end

    def destroy
      self.delete
    end

    def update_attributes(attrs)    
      save_attributes(attrs)
    end

    def to_s
      id.to_s
    end  
  end
end

모델에서는 ActiveItem을 상속한다. ActiveItem 정의부에서 모델에 필요한 것들 몇 가지를 대신 해주었기 때문에 기존의 ActiveRecord를 상속했을 때와 마찬가지로 모델 코드가 간결해졌다.

class Product < ActiveItem::Base
end

Database와 SimpleDB의 차이점을 이해할 필요가 있다. 일단 스키마 정의가 따로 없기 때문에, 어트리뷰트 목록을 어떻게 받아올지 결정해야 한다. 모델 코드에 어트리뷰트를 명시해줄 수도 있고, 별로 좋은 방법은 아닌 것 같지만 위에서처럼 데이터 하나를 가져와 어트리뷰트 목록을 파악한 후 클래스 변수에 담아둘 수도 있다.

스키마 정의가 없고, 레코드마다 어트리뷰트 목록을 다르게 저장할 수 있긴 하지만 AWS 도큐먼트를 보면 인덱싱과 데이터 검색을 위해서 어트리뷰트 목록을 레코드 전체에 걸쳐 일관되게 사용하기를 권하고 있다. 가령 자동차 정보를 입력할 때, 차가 있을 경우 {:car => "Bugatti"}로 저장하고, 차가 없을 경우 :car 어트리뷰트를 아예 두지 않을 수도 있지만 웬만하면 {:car => "None"}으로 저장해서 탐색 시간을 줄이라고 말한다.

또 다른 큰 차이점은 Database에는 String, Text, Integer, Boolean, Datetime 등의 데이터 타입이 있는데 반해 Document-Oriented Datastore인 SimpleDB는 모든 데이터가 String이라는 점이다. 데이터베이스에서 당연했던 개념이 SimpleDB에서는 번거로운 문제가 되는데 바로 Integer와 Datetime이다.

Integer 형이 String이 되면 자리수가 다른 두 수 사이의 대소관계가 달라지게 된다. Integer 세상에서는 3 < 12 이지만 String 세상에서는 '3' > '12' 가 되기 때문에 새로운 문제가 발생한다. SimpleDB는 이를 위해 Zero-padding을 사용한다.

꽤 큰 자리수까지 0을 채워서 String 대소 관계를 Integer 대소관계와 동일하게 만들어주는 것이다. '000003' < '000012' 이렇게. 음수 데이터를 저장해야 하는 경우는 충분히 큰 수를 모든 데이터에 더해서 양수로 저장한다. 음수를 그대로 저장하면 '-32' < '-54'이 되기 때문이다. 꺼내서 사용할 때는 더했던 수를 다시 뺀다.


Datetime의 경우 ruby에서 Time.now를 곧바로 데이터로 저장하면 Tue Apr 22 23:06:26 +0900 2008 형태가 된다. 데이터베이스에서는 문제 없이 전후를 구분해낼 수 있지만, SimpleDB는 시간 순서를 전혀 파악하지 못한다. 때문에 ISO8601로 변환해서 저장해야 해야 하는데(Time.now.iso8601), 그렇게 되면 2008-04-22T23:06:26+09:00 와 같이 년월일시분초 순서로 저장되어 문자열 비교만으로 전후 관계를 찾아낼 수 있다.

다 해결이 된 듯 하지만 또 다른 문제를 야기하는데, 레일스의 Datetime Select 헬퍼에서는 ISO8601 형태의 시간 데이터를 자동으로 읽어내거나 자동으로 저장하지 못하기 때문에 헬퍼를 새로 정의하거나 편집 단계에서 일시적으로 원래의 Datetime형태(Time.parse를 이용)로 바꾸어 사용해야 한다.

크게 어려운 과제는 아니지만, 기존에는 뷰 헬퍼가 어떻게 동작하는지 알 필요 없이 Datetime과 select 테그를 손쉽게 연결할 수 있었는데, SimpleDB를 사용하려면 헬퍼의 지저분한 내부구현을 파악해야 하고 고려해야 하니 머리가 아파진다. 문제가 되지 않았던 것들이 문제가 되니, 정녕 이것을 사용하는 것이 옳은 것인가 여러 번 회의하게 되기도 한다.

기술적으로 가장 큰 차이라고 말할 수 있는 부분은, 데이터베이스에서 일반적으로 한 칼럼에 하나의 데이터를 넣었던 반면(Denormalization을 위해 여러 개 넣기도 하지만) SimpleDB의 어트리뷰트에는 기본적으로 배열이 저장된다는 점이다. 위의 모델은 다른 모델과 연관관계가 없었기 때문에 특별한 점이 없었지만, 다대다 관계를 정의할 때 일상적으로 만들어줘야 했던 연관 테이블이 SimpleDB에서는 필요 없게 된다.

이 때문에 RightAws에서는 어트리뷰트를 저장하는 메서드가 두 가지다. save와 put. save는 덮어씌우기이고 put은 추가하기이다.

@product = Product.find(:first)
@product[:link] = "naver.net"
@product.save #=> {:link => ["naver.net"]}
@product[:link] = "daum.com"
@product.put #=> {:link => ["naver.net", "daum.com"]}
@product[:link] = "cyworld.org"
@product.save #=> {:link => ["cyworld.org"]}

친구 목록을 저장해야 된다면 friendships 테이블을 만드는 대신, 아래와 같이 어트리뷰트에 친구들의 user.id를 몽땅 집어넣어 사용할 수 있다.

@user[:friend_ids] = "3"
@user.put
@user[:friend_ids] = "5"
@user.put
@user.reload
puts @user[:friend_ids] #=> ["3", "5"]

save_attributes와 put_attributes도 save/put과 같은 관계이다. 대신 ActiveRecord에 있던 update_attributes가 없어졌기 때문에 ActiveItem에서 update_attributes를 save_attributes로 연결해 두었다. 위에 언급한대로, 다대다 등 필요한 경우에는 put_attributes를 사용하면 된다.

뷰나 컨트롤러, 헬퍼 메서드 라이브러리를 수정하지 않고 form_for 메서드를 그대로 사용하려면 몇 가지 작업할 부분이 있다. 기본적인 스카폴드와 ActiveRecord에서는


<% form_for(@product) do |f| %>

이렇게만 해 주어도 new 탬플릿에서는 '/products'에 'post'로 보내고, edit에서는 /products/#{@product.id}에 'put'으로 알아서 데이터를 보내게 되어 있다. 그런데, RightAws::ActiveSdb::Base를 상속할 때는 edit와 delete url의 #{@product.id} 부분이 채워지지 않아서 잘못된 경로로 커밋이 되었는데, RightAws에서 to_s 메서드를 잘못 정의했기 때문(값이 할당되지 않은 변수 @id를 반환하도록 되어 있다)이었다. to_s를 다시 정의하니 제대로 된 경로를 가리키게 되었다.

또 다른 문제는 form_for가 내부적으로 해당 객체의 접근자 메서드를 이용한다는 점인데 RIghtAws는 접근자 메서드 대신 어트리뷰트 형태의 메서드만을 제공한다. 즉 <%= f.text_field :title %> 필드가 있으면 form_for는 자동으로 @product.title = params[:product][:title]를 시도하는데, title이라는 인스턴스 메서드가 정의되어 있지 않으니 오류가 생긴다. 뷰 코드 수정 없이 이를 빨리 해결하려면 각각의 어트리뷰트에 대해 접근자 메서드를 만들어주면 된다.

def title
  self[:title]
end

def title=(value)
   self[:title] = value
end

RightAws를 상속하는 모든 모델에서 모든 어트리뷰트에 대해 이렇게 선언해주는 것은 DRY하지 않으니 ActiveItem에서는 method_missing과 class_eval을 이용해 메서드를 자동으로 생성해주도록 하였다.

def method_missing(method_id, *args)
  method_name = method_id.to_s.match(/\w+/)[0]
  if !self.method_generated
    self.class.attributes.each do |attr|
      method_body = <<-EOV
        def #{attr}
          self[:#{attr}]
        end

        def #{attr}=(value)
          self[:#{attr}] = value
        end
      EOV
      self.class.class_eval(method_body, __FILE__, __LINE__)
    end
    self.method_generated = true
  end

  if self.class.attributes.include?(method_name)
    send(method_id, *args)
  else
    super
  end
end


잘 동작하긴 하는데, method_generated = true/false 부분이 제대로 기능하고 있는지에 대해 확신이 없다. 메서드가 한 번 생성되었으면 다시 생성하지 않도록 하기 위함인데 내가 모르는 사이 동일한 메서드가 클래스에 수십개씩 더해지고 있는게 아닌가 걱정되기도 한다.

find 류의 메서드를 Override한 이유는 reload 때문이다. RightAws에서 find문으로 객체를 받아오면 바로 사용할 수 없고 reload를 해야 한다. find문은 id값과 new_record 여부만 담아오고, reload를 해야 어트리뷰트 목록과 그 값들을 메모리로 가져온다.


@product = Product.find(:first)
@product.title #=> nil
@product.reload
@product.title #=> "스프링노트"

RightAws가 find에서 reload 처리를 해주지 않는 이유는 아마도 필요한 경우만 reload를 할 수 있도록 선택권을 준 것이겠지만(전송량이 곧 비용이기 때문에), reload하지 않은 객체를 사용해야 할 일이 뭐가 있을까 언듯 떠오르지 않아서 ActiveItem에서는 find된 모든 객체에 reload 처리를 해주기로 했다. 이제 컨트롤러와 뷰 코드를 거의 수정하지 않아도 ActiveRecord::Base를 ActiveItem::Base로 바꿔줄 수 있게 되었다!

라고 끝내면 좋겠지만 ActiveRecord는 수천라인으로 된 대형 라이브러리이다. Vaildation과 Association은 시작도 안 했다. 변화를 시도하면, 그 동안 아무런 고민 없이 사용했던 메서드들 객체들이 하나 둘 문제를 일으킬 것이다. 파업이라도 하는 것처럼.

SimpleDB를 사용하기 위해 ActiveRecord를 포기해야 하는가. 포기하지 않아도 되도록 ActiveRecord를 그대로 사용하되 SimpleDB와의 연결을 대신해줄 어답터가 빨리 나와주었으면 좋겠다. SimpleDB 덕분에 ActiveRecord 공부를 더 많이 하게 된 하루였다.
Posted by FlyingMate
최근에 개발 관련 글을 많이 적었다. 이 블로그 독자분들 중에서 개발 관련 글을 이해하지 못하는 분도 계실 것이다. 좀 짓궂긴 하지만 의도적인 구석도 있다. 내가 쓰는 글 중 꽤 많은 글들은, 몇 주 전 또는 며칠 전의 나 였다면 쓰지 못했을 글들이다. 즉 2월 첫째주의  FlyingMate였다면 전혀 이해하지 못했을 내용의 글들을 2월 셋째주의 FlyingMate는 마구 아는 채 하며 다루고 있다는 얘기다.

작년 3월부터 css책을 보기 시작했다. 3월 이후에 내가 어느 순서로 어느 분야의 책을 봤는지는 출판사와 주고 받은 메일을 통해 확인할 수 있다. 책을 보면서 발견한 오타를 정리해두었다가 메일로 보내거나 출판사 홈페이지에 오타 등록을 했고, 담당하시는 분이 검토 및 반영 내역을 메일로 답해주시는데 그 메일들을 보관하고 있었다.

발견한 오타를 꼬박꼬박 정리해서, 마치 마감 시한에 쫒기듯 부지런히 전송한 이유는 밝은 세상을 위해서도 아니고 다른 독자들의 편의를 위해서도 아닌 지극히 개인적인 계산 때문이다. 학습 진도를 체크해줄 사람이 필요했기 때문. 내가 얼마만큼 공부하고 있는지 누군가가 알고 있다는 사실만으로도 오늘 이 책을 공부해야 할 이유가 되더라.

물론 스타트업이라는 명확한 목표가 있었고 그것이 가장 큰 이유였지만 그건 매우 거시적이었고, 단계적이고 미시적이면서 심리적인 감시가 필요했었다. 출판사 담당자 분들은 나를 감시할 의도가 전혀 없었지만 감시란 것이 원래 받는 쪽의 느낌.

당시의 나에겐 프로그래밍을 한다는 것이, 성공할지 실패할지 알 수 없는 하나의 도전이였고, html 이외에는 만져본 적이 없는 내가 정말 스스로 웹개발을 해낼 수 있을지  어떻게 될지 나 스스로도 알 수 없으니 주변 사람들에게 같이하자고 권하기도 애매했었다. 좌절하던 시기였다. 물론 일시적인.

4월엔 황대산님의 레일스 입문서로 html 코딩이 아닌, 프로그래밍 언어라는 걸 처음 접하기 시작했고, 7월엔 에이콘 출판사에서 보내준 DOM 스크립트라는 책으로 자바스크립트를 처음 배우기 시작했다. 그 이후로 여러 권의 책을 봤고 꽤 많은 온라인 텍스트와 소스코드를 읽고 작성했다. 개발을 집중적으로 공부한 시기이지만, IT에 발을 담근 후 가장 많은 웹 서비스의 인터페이스와 비즈니스 구조를 벤치마킹한 시기이기도 하다.

처음엔 입문서에 의존했고, 중간과정으로 직접 만든 애플리케이션으로 서비스를 해봤으며 다시 활용서와 해외 블로그의 튜토리얼들에 잠시 기대었다가 지금은 오픈소스와 레일스 프레임워크의 코드를 직접 보면서 필요한 것만 검색하는 방식으로 학습하고 있다.

소스코드를 통해 학습하는 이야기를 좀더 해보면, 처음부터 너무 무거운 애플리케이션의 소스코드를 보다가 이해도 안 되고 지치기도 해서 다른 경량의 애플리케이션을 보면서 고개를 끄덕이고 그 지식을 바탕으로 다시 그 무거운 애플리케이션을 보면서 깨달음을 얻기도 했다. 소스코드를 똑같이 따라 타이핑하면서, 그것에 대한 이해나 의문점을 주석으로 정리하는 방식으로 자바스크립트와 레일스를 공부하고 있다.

처음 보는 코드는 30% 밖에 이해가 되지 않고, 같은 코드를 두 번째 받아 칠 때는 거의 이해하게 되며, 세 번째 따라 치면 외우겠다 싶을 정도가 된다(물론 과장해서).
이 과정은 내가 책을 읽는 방식과 완전히 동일하다고 볼 수 있다. 이제는 처음 보는 코드를 눈으로만 훑어도 어느 정도 이해할 수 있다. 물론 아직 배우는 단계이기 때문에 이런 과정을 지속해야겠지만 지금은 내가 정말 할 수 있을까에 대한 불안감도 없고 앞으로 어떻게 할 것이고 내가 어디까지 해낼 수 있을지 점점 명확해짐을 느낀다.

프로그래밍의 시작을 루비온레일스와 함께한 경우, 즉 유일하게 루비온레일스로만 프로그래밍을 해본 경우는 독특한 경험으로 분류된다. 레일스는 원래 개발자이던 사람들이 대안으로 선택하거나 쉼터로 여기는 분위기이지 컴퓨터 사이언스 전공자나 개발자 지망생이 첫 경험으로 선택하는 기술은 아니다. 미국에서는 대학에서 레일스를 가르치기도 하지만 우리나라는 레일스 프로젝트를 다루는 기업이 희귀하기 때문에 대학교육까지 바라는 것은 욕심이다.

그런데 내가 경험해서 증명한 바로는 레일스는 좋은 프로그래밍 입문 과정이다. (사실  '가장 좋은' 이라는 수식어를 붙였다가, 내가 경험해 본 것이 레일스밖에 없다는 것을 깨닫고 지웠다) 레일스를 만져본 다음에 디자인 패턴 책 보고 데이터 구조 책 보면 훨씬 이해하기 쉽다. 웹 애플리케이션을 만들어 배포해보는 데까지 이르는 거리도 짧다. 난 컴퓨터 과학부를 나름 자부심으로 내세우는 Y대에서 컴퓨터 과학을 2학년까지 배웠지만 레일스와 자바스크립트 가지고 몇 개월 공부한 것이 학습 효과가 훨씬 컸다.

작년 봄, 나에게 레일스를 너무 쉽게 가르쳐주신 황대산님을 직접 만나뵈어 이야기를 나누고 저자 싸인도 받았다. 황대산님의 책을 보면서, 레일스는 진정 개발의 대중화를 가져다 줄 것 같다고 생각했고 그 이야기를 대산님께 했더니 맞장구를 쳐 주셨다. 개발의 대중화라는 말은 기존에 디자이너였건 기획자였건 아무 것도 아니었건 개발을 배우려는 의지, 내 서비스를 만들어보고자 하는 의지만 있으면 누구나 쉽게 개발 능력을 갖게 해준다는 의미였다.

레일스는 정말 그럴 수 있다. 그런데 대산님의 책이 나온지 1년 가까이 지나가는데 여전히 레일스는, 원래 개발자라는 직업을 갖고 있던 사람들의 대안 기술로 남아 있다. 난 주변의 디자이너, 기획자, 또는 그냥 경영학 전공하는 친구에게도 레일스 책을 추천한다. 더불어 css책도. (이통사에 기획직으로 입사한 친구에겐 자바책을 추천했다)

내가 느끼기에, 새로운 서비스에 대한 열망은 개발자들이나 공학도들 보다는 기획자들 또는 경영학도들 사이에서 더 뜨겁다. 그들에게 총을 쥐어주는 것이다. 말로 떠들지 말고 직접 만들어보라는 것이다. 좋은 책 좋은 튜토리얼이 얼마나 많은데. 우리나라 스타트업의 부재는 개발능력을 갖춘 기획자의 부재가 원인일지 모른다.

이 블로그에 방문하시는 분들 가운데 프로그래밍을 전혀 모르는 분들은 이 책 한 권 장만하시기 바란다. 물론 이 책은 아주 기본적인 시작점이고 후속 전략을 지속적으로 세워야 한다. 프로그래밍이라는 것은 이전에 배워왔던 심리학이나 마케팅, 경영학, 수학, 인터페이스 기획, 프로젝트 관리 같은 것들과는 완전히 다른 사고방식, 다른 어휘체계를 갖기 때문에 깊이 들어갈수록 일시적으로 좌절할 수 있다. 하지만 이런 생소한 분야를 조금씩 이해하게 되면서, 학습에 대한 자신감이 생길 것이다.

그래서 나와 같은 호흡을 느끼며 개발 능력을 키워 나가고, 내가 요 며칠 써왔던 알 수 없는 글들이 점점 읽혀지면서, 참 별 것 아닌 내용이었다는 것을 깨닫게 되셨으면 좋겠다. 평생 기획자로 먹고 살 생각이었는데 이 블로그를 보고 개발
시작했다가 결국 사업에 손을 댔다는 이야기를 농담처럼 나눌 수 있게 되기를 바란다.
Posted by FlyingMate
레일스 캐싱에 대한 글을 쓰려다가 글이 자꾸 삼천포로 빠지길래 아예 삼천포를 주제로 다시 글을 정리하고 있다. 이 다음 글로 레일스 캐싱을 적어봐야 겠다. 아래 코드는 레일스 캐싱의 구현부분이지만 이 글은 캐싱이 아니라 레일스의('루비의'가 아닌) 클래스 확장 방식을 다루려고 한다. 레일스에서 Action Caching을 구현하는 Actions 모듈은 아래와 같이 시작한다.

module Actions
  def self.included(base)
    base.extend(ClassMethods)
    base.class_eval do
      attr_accessor :rendered_action_cache, /
        :action_cache_path
      alias_method_chain :protected_instance_variables, /
        :action_caching
    end
  end
     
  module ClassMethods
    def caches_action(*actions)
      return unless perform_caching
      around_filter(ActionCacheFilter.new(*actions))
    end      
  end

    (..중략..)
end

self.included(base), base.extend, base.class_eval은 레일스의 모듈 내에서 흔하게 볼 수 있다. self.included(base)를 통해, 액션 컨트롤러(base)가 현재 모듈을 include했을 때의 초기화 부분을 정의하고 있다. base라는 이름의 인자로 넘겨받은 ActionController::Base에 ClassMethods에 담긴 클래스 메서드들을 포함시키고(extends), 인스턴스 변수에 대한 접근자(accessor)와 alias_method_chain 선언을 컨트롤러 내에 추가한다(class_eval).

alias_method_chain는 논란이 많은 메서드인데, 레일스 내에서 메서드 확장을 위해 빈번하게 사용된다. 기존 메서드를 override할 때, override를 정의하는 구현부 내에서 override하기 이전의 기능을 사용하려 할 때 호출한다. 기존에는 두 줄의 alias_method를 통해 아래와 같이 선언을 했다.

alias_method :old_good_method, :good_method
alias_method :good_method, :new_good_method

good_method라는 이름이었던 이전의 메서드(superclass의 메서드 또는 class_eval 등으로 재정의되기 전의 메서드)에 임시적으로 다른 이름을 부여하고(예를 들어 old 접두어 같은), override를 정의할 때의 메서드 이름 역시 새로운 이름을 부여해서(역시 예를 들면 new 접두어 같은) 메서드의 확장을 좀더 명시적으로 드러내는 것이다.

이것을 하나의 메서드로 통합한 것이 alias_method_chain인데, 이 메서드는 active_support/core_ext/module/aliasing.rb에 구현되어 있다. 위에 있는 두 줄의 alias_method를 한 줄의 alias_method_chain으로 선언한 예는 다음과 같다.

alias_method_chain :good_method, :new_feature

이 선언은 액티브 서포트의 메타 프로그래밍에 의해 다음과 같이 변환된다.

alias_method :good_method_without_new_feature, :good_method
alias_method :good_method, :good_method_with_new_feature

이렇게 선언한 후, 기존의 good_method에 override할 내용을 good_method_with_new_feature 메서드에 구현한다. good_method_without_new_feature를 그 내부에서 사용할 수 있다.

def good_method_with_new_feature
  good_method_without_new_feature + "new feature"
end

alias_method_chain 구현부의 변천사를 살펴보면, 처음(active_support-1.3.1)에는 스키니했지만 점차 살을 붙여가고 있다. 1.4대에서
?, !, =로 끝나는 메서드와 블럭 처리가 추가되었고, 2.0.2인 현재 메서드 접근 제어(public/private/protected)까지 처리하고 있다.

def alias_method_chain(target, feature)
alias_method "#{target}_without_#{feature}", target
alias_method target, "#{target}_with_#{feature}"
end

caching을 비롯해 레일스의 라이브러리들 상당수가 class_eval을 통해 base 클래스를 다시 열고 그 안에 alias_method_chain을 두거나 추가적인 메서드를 정의하는 형태로, 또 클래스 메서드는 ClassMethods라는 모듈에 따로 모아 extends하는 형태로 구현되어 있다.

이를 통해 기존의 클래스를 변형하지 않고 모듈화된 라이브러리의 변수와 메서드를 덮어 씌우는(wrapping) 형태로 기능을 확장하는데, 여기서 Decorator 패턴과 AOP(Aspect Oriented Programming)의 특징을 발견할 수 있다고 한다.

자바에서의 Decorator패턴은 Wrapping할 대상 클래스의 superclass인 추상 클래스를 Decorator가 상속해서 메서드를 재정의하되, 그 정의 내에서 기존의 메서드를 호출하는 부분이 중요한데, 레일스에서 class_eval과 alias_method_chain이 했던 역할(기존에는 두 줄의 alias_method가 했던)이 이것과 유사하다고 볼 수 있다.

deepblue님이 소개해주신 The Rails Way에서도 alias_method_chain을 패턴 차원에서 다루고 있는데, 정적 언어에 주어진 제약들 때문에 이런 저런 재미있는 방법(패턴)으로 해결했던 과제들을 동적 언어에서는 너무 싱겁게 풀어버려서 패턴이라는 고상한 단어를 붙이기가 무색해져 버렸다. 두 세 줄 짜리 코드에 패턴이 웬 말인가.

기존의 코딩 습관들에서 좋은 것들을 추출해 패턴으로 만들고, 상황에 따라 패턴을 선택해 코드로 구체화하는 자바와는 반대로 루비는 이미 만들어진 코드에서 패턴의 흔적(?)들을 추출해낼 수 있다. 꿈보다 해몽. 어쩌면 리팩토링이나 코딩 스타일 가이드 조차도 다른 언어에 비해 루비에서 만큼은 큰 의미가 없을지도 모르겠다는 생각이 든다. 이건 좀더 겪어봐야겠다. 레일스의 개발자들 역시 패턴을 고려해 설계하겠지만 기존의 정적 언어에서는 상식이었던 개념들로부터 독립적으로 사고해야 할 것 같다.

위의 Action Caching의 코드로 돌아와서, class_eval에서 정의하고 있는 alias_method_chain은 ActionController의 Base클래스에 정의되어 있는 protected_instance_variables를 확장한다. 기존의 메서드는 특별한 인스턴스 변수 이름들의 목록을 배열로 반환하는데, 재정의된 메서드는 이 배열에 변수 이름 하나를 추가한다.

이 모듈이 include되면 메서드가 이전과 조금 다르게 동작하게 되는 것이다. 사실 이 부분(protected_instance_variables_with/without_xxx)이 크게 중요한 것은 아니지만, alias_method_chain의 동작과 사용예를 잘 이해해야 프레임워크의 다른 부분을 이해하는 데 속도를 더 높일 수 있다. alias_method_chain의 정체가 무엇이고 왜 쓰였는지 이해하는 데 나도 좀 헤맸다.
Posted by FlyingMate

최근에 달린 댓글

최근에 받은 트랙백

글 보관함