자칭 타칭 루비 매니아(?) deepblue입니다. 저는 현재 포틀랜드에서 레일스 컨퍼런스(RailsConf)에 참석하고 있습니다. RailsConf는 어떤 이유에서건 장안의 화제가 되고 있는 MVC 웹 프레임워크인 루비온레일스를 주제로 17일부터 20일까지 4일간 열립니다. 국내에서는 오픈마루의 스프링노트, 마이아이디넷 서비스와 더블트랙의 미투데이 등이 루비온레일스로 개발되었고, 외국으로 눈을 돌리면 Twitter, Basecamp, Odeo 등 많은 적용 사례를 찾을 수 있습니다.

RailsConf는 올해로 2회를 맞습니다만, 하나의 세션을 가지고 소규모로 진행된 작년(의장인 차드 파울러는 작년은 레일스의 생일 파티 같았다고 회고합니다)과는 사뭇 다르게, 올해는 대단한 규모로 열리고 있습니다. 레일스와 루비에 열광하는 사람이 이렇게 많다는 사실도 놀랍고, 또 그 무리에 섞이게 되어서 굉장히 흥분되고 즐겁습니다. 평소에 가졌던 궁금증도 해소하고, 이슈들도 공유하고 루비의 기운을 잔뜩 받아서 돌아가겠습니다.

(잡담) 레일스 개발자들은 맥을 정말 좋아하기는 하는 것 같습니다. 행사장에 들고 온 노트북 대부분 거짓말 안 보태고 95% 정도가 맥북(프로)입니다. 제가 별천지에 와있는 걸까요?

오늘은 RailsConf의 첫째 날로 튜토리얼이 있었습니다. 한쪽에서는 기부 영수증이 있어야 참여할 수 있는 레일스 가이드북(튜토리얼)이 Dave Thomas와 Mike Clark의 진행으로 이어졌고, 다른 한쪽에서는 오전/오후로 나뉘어 정해진 튜토리얼 세션이 열렸습니다.

Scaling a Rails Application from the Bottom Up

이 세션은 TextDrive를 운영하며 107TB의 데이터를 다루고 초당 11,000개(아마 최대치)의 요청을 받는 트위터를 호스팅하는 업체인 Joyent의 CTO Jason Hoffman이 발표했습니다. 크게 3부분으로 나눠서 진행되었는데, 그는 평소에도 "레일스가 Scalable한가?"에 대한 질문을 많이 받는다며 말문을 열었습니다. 이에 대한 답으로 시스템 관리자의 입장에서 볼 때 레일스는 Scalability에 영향을 주는 수많은 연결 중 하나일 뿐이며(레고에 비유했습니다), Scalability는 레일스의 문제가 아니라고 단정해버렸습니다. 저는 Scalability가 무언가를 추가해서(Add up)해서 병목을 없애는 작업이라고 볼 때, "레일스는 수많은 병목 요소 후보 중 하나일 뿐이며, 이는 충분히 해결할 수 있으므로, 문제가 되지 않는다"라고 이해했습니다. 그리고는 정말 Scalability에 대한 개념탑재(오픈마루 유행어입니다) 강의가 이어졌습니다. 평소에 신경 쓰지 않았던 전력 문제(가용성과 비용), Bandwidth, 공간, 커넥터, 케이블, 라우팅, 스토리지 등의 문제를 시스템 관리자 입장에서 보니 새롭더군요. 지금까지는 너무 순진하게 일부만을 보지 않았나 싶습니다. 이런 다양한 요소들 중 정말 병목을 잘 감지해내는 능력이 필요하겠네요.

어쨌건 Scalable하려면 최대한 단순하게 쪼개고, 이를 적당한 단위로 관리하는 능력이 꼭 필요한 것 같습니다. 그런 의미에서 가상화(Virtualization)는 최고의 화두였습니다. Xen이나 VMWare, 솔라리스 Zones 중 하나를 골라서 반드시(!) 가상화를 생각하라고 하더군요. 눈과 귀를 열고 있어야겠습니다. 그리고 솔라리스에 대해 잠깐 설명했는데 여러모로 장점이 많더군요. DTrace도 루비 개발자에게는 최고의 선물인 듯 합니다.

이제 다시 레일스로 돌아갑니다. 레일스 애플리케이션을 배포하는 방법과 자신들의 경험을 공유했습니다. 사실 이 부분이 제일 궁금했고, 또 많이 놀라고 재미있게 들었습니다. (이 부분에 약간 충격을 받고, 멍한 모습이 어떤 분 카메라에 잡혀서 플리커에 올라와버렸군요 저런 -_-;) Scalability면에 서 볼 때 루비가 프로세스 기반인 점이 좋다고 하며, 스레드 기반이 되지 않았으면 좋겠다고 하더군요. 계속 프로세스를 기반으로 이벤트 중심의 비동기 처리에 집중해야 한다며 몽그렐(Mongrel)이 현시점에서는 꽤 잘하고 있다고 평했습니다. 하지만 현재 JRuby + Glashfish + Sequoia + Netbeans를 테스트해보고 있는데, 개발도 편하고 성능면에서도 더 나은 점이 있었다고 합니다. JRuby가 안정화되면 어떤 일이 일어날지 무척 기대됩니다.

어쨌든, 현재 설정은 머신 한대에 4개의 가상 서버를 만들고 각각(즉, CPU 하나당) 몽그렐 서버 10개를 띄우는 식으로 하고 있답니다. 프로세스기반이기 때문에 언제든 추가할 수 있는 장점이 있겠죠. 이런 식으로 수천 개의 몽그렐 프로세스를 관리한답니다. 숫자에 잠깐 놀랐습니다. BIG-IP를 사용하더군요. Layer 7과 iRules를 적용해 논리적으로 몽그렐 풀을 관리하는 것이 인상적이었습니다. 보통의 설정에서는 일부 기능이 애플리케이션 전체의 건강을 해칠 수도 있는데, 이런 식으로 컨트롤러 단위로 몽그렐 프로세스를 격리 수용하면 시스템 안정성이 높아질 것 같습니다. 이런 생각은 한번도 하지 못했는데, 들으면서 그런 방법도 있구나 싶었습니다. 돌아가면 스프링노트에도 적용해보고 싶습니다.

RDBMS를 고집하지 말고, Memcached나 LDAP, J-EAI, File System을 적절히 사용하라는 부분도 인상적이었습니다. 특히 LDAP을 강조했습니다. Joyent에서는 최대한 LDAP을 사용하려고 노력한다고 합니다(레일스와 LDAP의 연결에는 큰 문제가 없습니다). 마지막으로 DNS를 통한 사용자 또는 기능별 격리를 제안하였습니다. 할 수 있는 가장 쉬운 방법인데 하지 않을 이유는 없겠지요. 정적 파일을 서비스하는 서버(레일스 용어로 Asset Server)도 여러 대를 지정하면(DNS를 이용해서), 동시 접속수가 높아져 서비스 로딩이 빨라집니다. 정리입니다. 발표 중 빠진 내용이 있는데 EdgeRails를 사용하는 것도 성능에 도움이 됩니다. 1.2.x보다 많은 부분 성능이 나아졌습니다.

When V is for Vexing: Patterns to DRY Up Your Views

레일스 1.2(REST 지원)과 함께 컨트롤러와 모델은 두 번째 페이즈에 접어든 것 같습니다. 하지만 뷰는 JSP를 닮은 초기의 모습 그대로입니다. 저도 개발을 하다 보니 컨트롤러와 모델은 테스트도 쉽게 할 수 있고, 리팩토링 방법도 많고 순수 루비이기 때문에 언제든 깔끔한 모습으로 정리할 수 있다는 생각이 들지만, 뷰만은 그렇지 않습니다. 재사용도 어렵고 마스터하기도 어렵고 테스트하기도 어렵고 항상 뷰 코드가 고민입니다.

어떻게 해야 할까요? 이런 고민을 하는 사람이  많은 것 같습니다. FiveRuns의 Bruce Williams와 Marcel Molina, Jr.가 뷰를 잘 만드는 방법들에 대해 설명했습니다. 이미 알고 있던 부분도 있었지만, 전체적으로 뷰에 대해 다시 한 번 생각하는 시간이 되었습니다. 노력하면 뷰에서도 DRY(Don't Repeat Yourself)를 실현할 수 있겠더군요. 하지만 모든 사람이 그렇게 느끼기 위해서는 프레임워크도 어느 정도 변해야 할 것입니다.

사실 EdgeRails에서는 그런 부분이 이미 진행되고 있는데, 그게 바로 Simply Helpful 플러그인입니다. 그리고 현재는 Rails 트렁크로 합쳐졌습니다. Simply Helpful 플러그인은 자주 사용되는 기능 예를 들면, AJAX를 위해 DOM에 객체의 ID를 부여한다든가, 리소스를 위한 폼을 만든다든가 하는 흔히 있을 수 있는 일에 대한 관례를 부여해서 뷰 코드를 간결하게 합니다.

대부분 ERB(Embeeded RuBy)를 사용하지만, 이 외에도 레일스 뷰 템플릿 엔진이 생각보다 많더군요. Markaby, DRYML, HAML, Liquid, Amrita2, MasterView 등등… 개인적으로는 시사이드가 연상되는 Markaby를 주목하고 있습니다. 그리고 FormBuilder 객체를 확장해서 자신만의 FormBuilder를 만들 수 있다는 사실도 새롭게 알았습니다.

레일스 뷰 코드가 가진 대표적은 나쁜 냄새(Bad Smell)은 모델의 find 메서드 호출, Association 메서드 호출, if-else-end, case 등을 이용한 분기, map, sort, select를 남용하는 것, 임시 변수 사용 등이 있습니다. 너무 쉽게 사용할 수 있지만 앞으로는 다시 한번 생각해봐야겠습니다. 어쨌든 뷰를 깨끗하게(DRY) 하는 노력은 계속 해야 합니다. 방법으로 제시한 것은 블럭 도우미 함수를 만드는 것, Presenter 패턴을 활용하는 것, 플러그인으로 만드는 것 등 많을 것입니다. 그러면서 Presenter를 쉽게 정의할 수 있는 플러그인(stencil)도 공개했는데 괜찮은 아이디어 같더군요. 숙소로 돌아오는 길에 다시 생각해보니 방법은 당연히 있는 것이었고, 고민 한 큰술과 실행 두 큰술이 필요한 문제였더군요.

아, 팁 한가지 헬퍼는 테스트가 되지만, 뷰는 테스트가 쉽지 않습니다. 그래서 뷰 코드는 문법 오류 검사 조차 하지 않고, 배포되는 경우도 가끔 있습니다. 이를 막기 위해서는 배포 전에 erb -x your_file.erb | ruby -c 명령을 이용해 검사를 수행하는 것이 좋겠습니다. erb를 컴파일해서 루비 파일을 만들고 이 파일의 문법 검사를 하는 것입니다. 간단한 일인데 왜 이 생각을 못했나 싶었습니다.

빠진 부분도 있고, 덜(또는 잘못 이해한) 부분도 있을지도 모르겠는데, 더 고민해서 공유하는 자리를 마련하겠습니다. 내일은 또 무척 기대되는 세션이 많습니다. DHH, Steven Smith, Avi Bryant, Ze Frank의 키노트도 있습니다. 레일스의 미래를 엿볼 수 있는 자리가 되지 않을까 싶습니다. 아, 오늘 다음에서 레일스로 뭔가(?)를 개발하고 계신다든 dante님도 만나서 재미있는 이야기를 많이 나눴습니다. 대형 포털의 레일스 애플리케이션을 볼 수 있는 날도 머지 않았습니다. :)

- deepblue

이 글은 스프링노트에서 작성되었습니다.