레일스 컨퍼런스에서 돌아온 지 일주일 정도 지났습니다. 팀에 복귀해서 가장 먼저 한 일은 스프링노트의 배포(deployment) 프로세스를 바꾸는 일과 테스트 코드들을 점검하는 것이었습니다. Getting Real Numbers라는 세션에서 Julian Boot가 간단한 모니터링과 테스팅 프레임워크를 만들었던 모습이 떠오릅니다. '현재보다 조금만 더 좋은 것'을 추구하다 보면 언젠가는 원하는 목표에 도달할 수 있다는 것은 이번 컨퍼런스에서 배운 교훈 중 하나입니다. 당연한 이야기지만 막상 실천에 옮기기는 힘든 것이지요. 그래서 잊기 전에 스프링노트의 배포 프로세스를 조금 더 좋게 만들고, 테스트를 조금 더 말끔하게 정리했습니다.

컨퍼런스 마지막 날에 재미있는 일이 있었습니다. Rails Security라는 세션에 들어갔는데, 글쎄 시작 시간 5분이 지나도 발표자가 나타나지 않았습니다. 이 세션은 빈 강의실에 급하게 편성된 것이었는데 사고를 치는군요. 웅성거리고 있는데, 한 사람이 '어제 Open Mic 세션 즐거웠는데, 우리 또 하면 어때요?'라고 소리를 치더군요. 그리고 즉석에서 발표자들이 줄을 서서 이야기를 했습니다. 정말 한 시간 금방 가더군요. 끝나고 나서 웬만한 세션보다 훨씬 좋았다면서 다 같이 박수를 쳤습니다. 색다른 경험이었습니다. 맨 처음에는 Mongrel 개발자 Zed Shaw가 나와서 Utu를 소개했습니다. 그 외에도 8명 정도가 더 발표했는데, 가장 인상적이었던 것은 erlang을 이용해 mongrel 클러스터를 구성한 프로젝트였습니다. 너무 간편하게 mongrel 서버들을 넣고 빼고 하는 모습이 인상적이었습니다. 개발한지 2달 되었다고 하던데, 나중에 공개되면 재미있을 것 같습니다.

The Rails Way

마지막 날 가장 재미있었던 세션은 누가 뭐래도 Jamis Buck과 koz가 진행한 The Rails Way였습니다. 어떻게 하면 레일스 코드를 루비스럽게 잘 작성할까 하는 고민을 함께 나누는 시간이었습니다. 사실 레일스 개발자들은 꽤 오랫동안 루비를 개발한 사람들이고, 레일스 코드는 꽤 쓰여진 루비 예제이기도 합니다. 저는 루비를 배우려면 레일스 코드를 읽으라고 권하기도 합니다. 세션은 두 명이 번갈아 가면서 이럴 때는 이런 이유로 이렇게 하는 것이 좋겠습니다 라고 설명하는 식으로 진행되었습니다.

예를 들면 Skinny Controller Fat Model(컨트롤러에는 최소한의 코드만 두고, 로직은 모델에 둔다)을 추천하면서 이 편이 테스트하기도 쉽고 유지 비용도 적다고 설명했습니다. Association을 조금만 활용해도 코드의 모양이 얼마나 좋아지는지, with_option, returning등 액티브서포트가 제공하는 문법 사탕(Syntactic Sugar)이 가지는 의미 등도 재미있었습니다. 자세한 발표 내용들은 발표자들이 운영하는 블로그에 올라오고 있으니 레일스 개발자라면 꼭 읽어보면 좋겠네요.

제가 생각하는 좋은 루비 코드는 짧고 함축적인 코드가 아니라 읽고 쉽게 이해할 수 있는 코드입니다. 확장이 쉽고, 문법이 유연한 루비의 장점을 살리면 약간의 노력으로 정말 읽기 편한 코드를 만들 수 있습니다. 예를 들어, 오늘이라는 날짜를 시간으로 표현할 때(5월 30일 0시 0분) Time.now.to_date.to_time이라고 쓰는 것보다 Time.now.beginning_of_day라고 쓰는 것을 선호합니다. 기능적으로도 같고, 정말 작은 차이겠지만 이런 사소한 차이들이 모여서 생산성이 되는 것이지요. 이런 생각이 잘 표현된 것이 루비의 테스팅 프레임워크인 RSpec인데 이 프로젝트는 명세서(문서)의 역할을 할 수 있는 코드를 추구합니다.

떠오르는 기대주 JRuby

JRuby는 자바 가상 머신(JVM) 위에서 동작하는 루비입니다. 기존의 C루비(또는 마츠루비)와는 별개로 루비 언어를 새로 구현하는 프로젝트들이 여럿 있는데 그 중 가장 높은 완성도를 보이고 있습니다. 이날 데모에서 기존 루비보다 더 나은 성능으로 레일스 애플리케이션을 돌리는 모습을 볼 수 있었습니다. 그리고 war 파일을 만들어 간단하게 GlassFish에 배포하는 모습을 보니, JRuby가 가진 가능성이 바로 와 닿더군요. JRuby를 사용하면 루비 코드에서 루비 라이브러리는 물론, 자바 라이브러리들까지 함께 사용할 수 있습니다. 그리고 이렇게 만들어진 애플리케이션을 JVM 위에서 돌릴 수 있습니다. 자바와 루비의 장점을 모두 취해 새로운 가치를 만들어낼 수 있을 것 같습니다.

ThoughtWorks에서는 다음달에 내놓을 예정인 Mingle이라는 프로젝트 관리 애플리케이션에 JRuby와 레일스를 사용합니다. JRuby가 아직 1.0은 아니지만(마지막 조율 중), 이미 쓸 수 있는 수준이라는 이야기지요. 오픈마루에서도 모 프로젝트에서 JRuby와 레일스를 사용하는 것을 검토 중입니다. 앞으로 무척 흥미로운 일들이 많이 일어날 것 같습니다. 더 자세한 내용은 MountainWest 루비 컨퍼런스 발표자료를 보시면 도움이 될 것 같습니다.

Rails is LOVE

컨퍼런스의 마지막을 장식한 것은 Dave Thomas의 키노트였습니다. 자신의 관점으로 컨퍼런스 전체를 유쾌하게 정리해주는 모습이 인상적이었습니다. 그리고 일전에 Avi Bryant나 Tim Bray가 그랬던 것처럼 커뮤니티에 숙제를 던져주더군요. 레일스 커뮤니티는 자신들이 만든 카고 컬트(Cargo Cult)에 빠져있는 것이 아닌가라는 말을 했습니다. 루비나 레일스는 툴일 뿐이고, REST는 테크닉일 뿐이라는 것이지요. 그리고 PC가 나온 이래로 우리의 기술이란 것도 반복해서 돌고 도는 것일 뿐이고, 이 사이클을 깨고 뭔가를 해내는 것이 숙제를 던졌습니다. 또 하나, 객체 지향 프로그래밍에 대한 이야기가 인상적이었습니다. 현재 우리가 루비를 사용하는 모습은 '객체(Object)' 지향이 아니라 '클래스(Class)'지향이 아니냐 라며, 프로토타입 기반 언어인 self나 javascript에서 배울 점이 많다고 했습니다. 사실 루비에도 프로토타입적인 특징이 약간 있고(개인적으로는 객체지향언어와 프로토타입 언어의 중간쯤 된다고 생각합니다), 개발자가 쓰기 나름인 면도 있습니다. 이런 자극을 받은 레일스 커뮤니티가 어떤 방향성을 갖게 될지 무척 궁금하네요.

위 사진은  Dave가 키노트 도중 보여준 것인데, 레일스 로고를 두개 붙여서 하트를 만들었습니다. 컨퍼런스 내내 친절하고 발전적인 커뮤니티의 모습을 느낄 수 있었는데, 그 모습이 이미지에 표현된 것 같습니다. 이번 컨퍼런스 최고 유행어였던  Orthopraxy, Change the World, Donation 같은 것이 떠오르네요.

이상으로 레일스 컨퍼런스 체험수기를 마치겠습니다. 개인적으로는 많은 자극을 받을 수 있는 시간들이었습니다. 국내에서도 이런 즐거운 루비 컨퍼런스가 열릴 수 있게 되는 그 날을 기대해봅니다.

추천 리소스

끝으로, 여기에 가시면 이번 컨퍼런스의 발표자료를 받아서 보실 수 있습니다. 간단한 루비 프로그램으로 자료를 한번에 내려 받을 수도 있으니, 참고하세요. 제가 개인적으로 읽어볼 만하다고 생각하는 자료를 소개하면서 글을 마치겠습니다.

• DHH의 키노트 - Rails 2.0의 방향성을 볼 수 있습니다.
• Scott Raymond의 Doing REST Right - REST의 본질을 생각하게 합니다.
• 로버트 마틴의 Clean Code - 자료만으로 현장의 열띤 분위기가 전달될지 잘 모르겠지만, 발표는 최고였습니다.

그리고 자바스크립트 개발에 대한 좋은 발표도 많았습니다.

• Thomsd Fuchs(Scriptaculous 개발자)의 Is javascript Overrated? Or: How I Stopeed Worrying and Put Prototype and script.acuo.us to Full Use
• Nick Merwin의 Scriptaculous Inside Out
• Dan Webb의 The Mysteries of JavaScript-Fu 

Rails Deployment 환경이 궁금하다면, 이 자료를 참고하세요.

• Scaling a Rails Application from the Bottom Up
• Harnessing Capistrano
• Exploring Virtual Clusters for Rails Development and Deployment
• Xen and the Art of Rails Deployment
• Memcaching Rails
• JRuby on Rails: A Taste of Honey 

마지막으로 레일스를 좀 더 잘 쓰기 위한 고민들입니다.

• The Rails Way
• When V is for Vexing: Patterns to DRY Up Your Views
• The Dark Art of Developing Plugins
• RSpec BOF Presentation

꽤 많군요. Have Fun and Do Good!

- deepblue

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

레일스 컨퍼런스의 절정입니다. 어제보다 활발하게 네트워킹(대화)가 일어나고 있습니다. 문자로만 만나던 개발자들을 직접 만나 이야기를 듣고, 고민을 나누니 감회가 새롭습니다.

컨퍼런스, 다양한 소통이 일어나는 곳

오늘 가장 흥미로웠던 세션은 무엇보다도 오픈 마이크 데모(Open Mic Demo) 세션이었습니다. 이 세션은 현장에서 바로 신청을 받아서 5분간 자신의 작품을 커뮤니티에 발표할 수 있는 자리입니다. 다들 자신이 만든 결과물에 대한 자부심이 느껴지고, 또 청중들이 함께 환호해주는 분위기가 너무 좋습니다. 플러그인을 발표하는 사람도 있고, 레일스로 직접 개발한 사이트를 발표하는 사람도 있습니다. 축제의 장이라는 표현이 어울려 보입니다.

그 중 가장 기억에 남았던 발표는 revolutionhealth.com 이었습니다. 루비로 만든 건강에 관련 포털 사이트인데, 페이지의 일부를 클리핑하고, 이 조각을 위짓처럼 마음대로 배치해서 페이지를 꾸미는 모습이 흥미로웠습니다. 스프링노트와 유사한 변경 기록도 있더군요. 무엇보다 재미있었던 점은, 개발하면서 얻게 된 노하우 일정 간격(2주)으로 레일스 플러그인 형태로 만들어 공개한 다는 점이었습니다. 멋진 친구네요.

누군가 OpenID를 기반으로 한 그룹 토론 툴을 만들었다고 해서 솔깃했는데, 알고 보니 루비 오픈아이디 라이브러리를 만든 Brian Ellin이었습니다. 오픈 아이디에 푹 빠져있는 모습이 kayflow님 같았습니다. 마이아이디를 소개해주고 싶어서 끝나자마자 달려갔는데, 사라져버려서 이야기를 못했습니다(실은 제가 얼굴을 잘 기억을 못한 것일지도). 아쉽네요. 내일 또 찾아봐야겠습니다.

이 외에도 정말 재미있는 발표들이 이어졌습니다. 어쩜 다들 그렇게 유머감각까지 장착했는지(루비가 유머도 가르쳐주나요?). 한편으로는 무척 부러웠습니다. 사실 저도 스프링노트를 데모하고 싶은 마음이 간절했습니다. 일주일 전만해도 '주마군 각본, 이아스 더빙, 딥블루 립싱크 5분 데모'에 대한 시나리오가 있었는데 실행에 옮기지를 못한 것이 너무 아쉽네요. 솔직히 많은 사람 앞에서는 발표 하기가 겁나서(순수 국산이라 영어도 힘들고), 저는 전략을 달리 세웠습니다. 이른바 각개격파. 일단 세션을 들을 때는 최대한 노트북을 아래로 하고(옆 사람이 볼 수 있도록), 스프링노트 단축키를 연거푸 날려줍니다. 그럼 옆에서 쳐다봅니다. 기회는 이때다, 저는 '이건 한국에서 레일스로 만든 위키 서비스야~'라며 살며시 말을 걸고, 몇 가지 데모를 보여줍니다. 이런 식으로 몇 명 낚았습니다. 하하. 그런데 어설픈 영어로 설명을 해도 다들 친절하게 들어주고 또, 좋다고 해줘서 너무 기분이 좋았습니다. 어떤 친구는 이거 영어 버전이 나오면 내가 쓸 수 있게 꼭 알려달라고도 하고, 어떤 친구는 자기 친구를 데려와서, 그 친구에게도 좀 보여달라며 부탁을 하기도 했습니다. 무척 즐거운 경험이었습니다. 아, 레일스 프레임워크를 처음 만든 DHH에게도 찾아가서(낚을 기회가 없어서^^), 인사하고 스프링노트와 마이아이디를 간단하게 소개했습니다. It' Cool~이라며 친절하게 말해준 DHH에게 감사. 자, DHH도 인정한(?) 스프링노트 많이 써주세요. 하하

제가 정말 좋아하는 라이브러리 중 하나인 RSpec에 대한 소식도 전해야겠습니다. RSpec은 레일스 테스팅 프레임워크의 한 종류로, 전통적인 xUnit을 그냥 수용하기보다는, 루비스러운 깔끔한 문장을 만들어 많은 사랑을 받고 있습니다. RSpec은 테스트 주도 개발(TDD)의 장점 중 '테스트가 문서화 도구이자, 디자인 도구'라는 점을 부각시키는데 주력하고 있습니다. 그리고 바로 어제 RSpec 1.0이 발표되었습니다(루비 커뮤니티에서는 컨퍼런스 릴리즈가 많은 편입니다. 오프라인에서 만나서 의견을 조율하고 바로 개발까지 마쳐서 릴리즈하는 식입니다). 그리고 RSpec 1.0이 나오자마자, 컨퍼런스 장에서 RSpec 개발팀과 JRuby 개발팀이 만나 JRuby 1.0에 RSpec을 기본으로 내장해서 발표하기로 결정했습니다. 또 한편에서는 RSpec 개발팀과 PragDave(실용주의 프로그래머로 유명한 Pragmatic Bookshelf의 일원)가 만나 RSpec 책을 내자고 손을 잡습니다. 정말 멋집니다. 저도 한건했습니다. RSpec 개발자중 한 명인 David Chelimsky를 우연히 만나(그런거 있죠? 구석에서 기다리다가 우연히 만난 척 하는 거. 하하), 최근 적용된 RSpec 문법의 단점에 대한 의견을 전달했습니다. '문서'가 되려면 국제화를 생각해야 한다. '나는 한글로 스펙을 만드는데, 너무 영어만 생각하고 API를 설계하니까 내가 힘들다'라고 했더니, 국제화 계획이 있다고, 이 방법으로 해보자고 하더군요. 밤(8:30~10:00pm)에는 RSpec BoF에 참석했습니다. RSpec이 추구하는 방향을 설명하고, 그 자리에서 반박하고, 다양한 토론(너무 즐거운)이 이뤄졌습니다.

제가 행사장을 나온 것이 밤 11시가 다된 시간인데, 그 때도 여기저기서 삼삼오오 모여서 짝 프로그래밍을 하는 사람들이 많았습니다. 소통이 일어나고, 그 자리에서 행동으로 옮겨지는 컨퍼런스 문화가 무척 인상적입니다.

현실 세계의 문제, 그것은 바로 배포

어제가 레일스의 나아가는 방향에 대한 생각을 많이 한 하루였다면, 오늘은 보다 현실적으로 레일스를 사용하면서 겪게 되는 문제들을 해결할 수 있는 아이디어를 잔뜩 얻을 수 있었습니다. 그 중 하나가 효과적인 배포(Deployment) 방법입니다. 그리고 이 방법은 RailsConf07이전과 이후로 나뉠 것 같습니다. 지금까지 제가 선호하는 방식은 Apache 2.2.x + mod_proxy_balaner + mongrels였습니다. 하지만 오늘 Rails Deployment라는 책을 준비하고 있는 Ezra Zygmuntowicz가 소개해준 Nginx + Mongrel with Swiftiply(aka Event Driven Mongrel)은 매우 인상적이었습니다. 몽그렐들을 각각의 포트(800x)에 띄우고 웹서버에서 proxy 모듈을 통해 해당 포트로 요청을 전달하는 방식에서, 몽그렐들이 Swiftiply에 등록하고 여기에 있는 큐에 담기고, 몽그렐들이 큐에서 한번에 하나씩 꺼내는 방식입니다. 루비 스레드(쓰레트 문맥 전환 비용, Mutex 유지 비용이 생각보다 크다고 합니다)를 쓰지 않아 빨라지고, IO throughput이 좋아지고, 설정도 간편해지고 Scaling도 쉬워진다는 설명입니다. 더 자세한 내용은 제가 돌아가서 테스트를 해보고 전에 작성한 '레일스 최적의 배포 환경'이라는 글을 갱신하겠습니다.

첫날 튜토리얼에서도 가상화(Virtualization)는 필수라는 말이 있었는데, 오늘은 더 자세한 이야기가 많았습니다. Bradley Taylor는 Virtualization Cluster를 갖춤으로써 얻을 수 있는 장점들을 하나하나 친절하게 설명해주었습니다. 가장 중요한 것은 소프트웨어 개발에서 적용되던 Separation of Concerns을 하드웨어에도 적용할 수 있습니다. 문제들을 나누고, 각각을 고립시켜서 일을 쉽게 만드는 것이지요. 하드웨어 구성을 물리적 제약 없이 소프트웨어(애플리케이션) 관점에서 할 수 있다는 겁니다. 이를 통해 얻어지는 리소스의 효율적인 활용, 스케일링 업 등은 어쩌면 부차적인 것일지도 모르겠습니다. 아무튼, 저는 연구과제(또는 호스팅 업체에나 필요한 것)로만 생각하고 있던 가상화를 이미 서비스에 적용하고, 잘 돌게 만들어놓고 사례 발표를 하는 모습은 무척 흥미롭습니다. 아직 잘 모르는 분야이지만, 앞으로 꾸준한 관심을 가져야겠습니다.

Chris Wanstrath의 Memcaching 사례 발표는 레일스의 Memcaching 이슈 결정판이었습니다. 스프링노트에서도 오래 걸리는 작업이나 DB에 무리가 갈 수 있는 작업을 Memcache를 통해 해결하고 있는데, 바로 적용할 수 있을 것 같은 아이디어(키 이름에 날짜나 버전을 넣어서 자동으로 만료되게 한다든가, 캐시 목록을 캐시한다든가, 키 해시 방법을 바꾼다든가 하는 작은 아이디어들)들을 얻을 수 있었습니다. 관심 있으신 분은 프리젠테이션 자료가 올라오면 꼭 한번 보시면 좋겠습니다.

Getting Real Numbers 세션도 마찬가지로 아이디어를 주었습니다. 특히나, 아파치의 Server-status 페이지처럼 한글 자짜리 약어를 정의하고, 레일스 애플리케이션에서 이 약어들을 로깅하도록 하고, 이 로그를 살펴봐서 모니터링을 하는 방법이 흥미로웠습니다. 세션 전체적으로 퍼포먼스 테스트를 위한 프레임워크와 그것을 기반으로 테스트 시나리오를 작성하는 과정을 보여줬는데, 즐거운 루비 개발 과정을 잘 보여준 것 같습니다. 결과 코드도 무척 짧고 간결했습니다.

레일스와 엔터프라이즈의 만남은 현실

이달 초에 루비온레일스는 엔터프라이즈 시장에 적합한가를 놓고 작은 논란이 있었습니다. 국내에서는 아직 시도조차 없지만, 미국에서는 이미 엔터프라이즈 시장에서 루비와 레일스가 자신의 위치를 찾으려는 노력들을 하고 있는 것 같습니다. 마틴 파울러로 유명한 ThoughtWorks는 회사 수익의 40%가 '루비'로 벌어들이고 있고, 6월에는 RubyWorks라는 기업 시장에 적합한 풀 프로덕션 스택을 출시함과 동시에 24/7 헬프데스크를 갖출 것이라고 합니다. 흥미롭습니다. 싫든 좋든 간에 기업 시장에도 '변화'의 바람이 불고 있는 것 같습니다. ThoughtWorks의 Cyndi Mitchell은 레일스가 기업시장에도 패러다임 시프트를 일으켰으면 좋겠다며, 현재는 루비와 기업 시장간에는 차이(gap)가 있지만, 더 많은 SW 개발자들을 생산적으로 만들기 위해 함께 노력하자고 주장했습니다.

이어지는 Tim Bray의 키노트에서는 '루비의 영향력도 레일스만큼 커질 것'이라고 하는 동시에 '자바는 절대 사라지지 않는다'며 안내 아닌 안내를 했습니다. 그러면서 이미 시장에 있는 JAVA나 .NET과 잘 해보자고 합니다. 그 방법이 바로 REST이며, 레일스는 옳은 길을 가고 있다고 했습니다. 마지막으로 기존 기업 시장에 비해 레일스가 가진 장점으로 Time To Market, Maintainability를 들었습니다.

Sun이 이렇게 전면에 나서고, 기업 시장에 레일스에게 열리고 있는 현상의 중심에는 JRuby가 있습니다. 내년 RailsConf가 열릴 시점에 레일스 커뮤니티는 어떤 결과를 가지고 있을까요? 흥미롭습니다.

이제 내일이면 한국으로 돌아가야 하는군요. 빨리 가서 여기서 얻은 아이디어들을 스프링노트에 적용해보고, 루비 사용자 모임 분들과 공유하고 싶은 마음이 반, 컨퍼런스가 계속 이어졌으면 싶은 아쉬운 마음이 반입니다. RailsConf의 마지막 날인 내일도 흥미를 끄는 주제들이 많습니다. 다음 글은 한국에서 올리겠습니다.

- deepblue

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

레일스 컨퍼런스(RailsConf) 2일째입니다. 어제는 준비운동이었고, 본 경기는 오늘이 시작입니다. 설레는 마음으로 행사장에 도착하니, 정말 많은 사람들이 있더군요. 무려 1,600명입니다. 41명이 모여서 했던 최초의 RubyConf를 생각해보면, 정말 엄청난 발전입니다. 학교에서는 맨 뒷자리부터 찾았는데, 여기 오니 앞으로 뛰쳐나가고 싶은 마음이 가득합니다. :) 조금 서두른 덕에 3번째 줄 중앙에 앉을 수 있었는데, 바로 앞 자리에 DHH, PragDave, David Black, Chad Fowler, Rich Kilmer 등 유명 인물들(?)이 이야기를 나누고 있었습니다. 좋아하던 가수를 만나는 팬의 마음이 이해가 되더군요. 하하~ 얼른 달려가 Dave와 이야기도 나누고, 사진도 찍었습니다(Dave는 제가 번역한 책 프로그래밍 루비의 저자이기도 합니다). DHH에게 스프링노트를 보여주고 싶었는데, 아쉽게도 너무 바쁘더군요. 다음 기회를 노려야겠습니다.

챠드 파울러의 짧지만 감동적인 오프닝이 이어졌습니다. 루비(레일스) 컨퍼런스는 발표자와 청중으로 나뉜 그런 강연회가 아니라, 아이디어를 서로 나누고 또 그 문제를 그 자리에서 해결하기도 하는 '변화'의 장이라는 말을 하더군요. 루비의 표준 패키지 관리자인 루비젬도 RubyConf 행사장에서 처음 만들어졌습니다. 루비 커뮤니티에 바라는 바를 이야기합니다. 우리가 가진 힘(Power), 열정(Passion), 명석함(Smart)으로 산업 전반을 바꾸고, 세계를 바꾸자고 하는군요. 그리고 변화가 일어나는 장소인 이 컨퍼런스 장에서 지금 시작하자고 하는군요. 멋집니다. 아웃사이더가 되지 않을까 약간 우려하던 저에게도 용기를 주는군요. 세상을 바꾸기 위해 기술뿐 아니라 마음도 나누는데, 서버가 힘들어할 정도로 많은 기부가 이뤄지고 있습니다.

레일스의 현재

리치 킬머의 소개로 DHH가 단상에 나타났습니다. 지구상에서 가장 섹시한 해커라는데, 제가 봐도 그런 것 같습니다. DHH가 레일스로 돈을 벌고 있는 개발자 손을 들어보라고 하네요. 정말 많더군요(저도 손을 번쩍 들었습니다). 루비 컨퍼런스에서 레일스를 아는 사람이 3명이었던 시절부터 3년도 지나지 않아 이 정도가 되었으니, 레일스의 성공을 따로 설명할 필요도 없어 보입니다.

성공 요인의 하나로 플러그인을 들었습니다. 레일스 플러그인은 개발자의 참여, 오픈 소스의 힘을 보여줍니다. 최초의 플러그인은 루비 코드 다섯 줄로 이뤄진 초라한 모습이었지만, 현재는 수백 개의 플러그인이 나와있고, 그 중 일부는 레일스 코어에 포함되기도 했습니다. 멋진 일이네요.

레일스를 지원하고 나선 IDE가 많이 나오는 것도 고무적입니다. Textmate, Aptana, Komodo, NetBeans, CodeGear 등 참 많습니다. 일부는 이 곳에 부스를 만들고 데모하고 있어서 조금씩 구경했는데 너무 멋진 모습들이었습니다. 자바 수준의 툴 지원도 먼 이야기가 아닌 것 같습니다.

루비/레일스를 다루는 책도 무척 많았습니다. Agile Web Development with Rails가 처음 나온다고 들었을 때는 이해가 안될 정도로 무모해 보였는데, 현재는 도서 시장의 규모만 보면 SQL 수준이고, 여타 경쟁(?) 언어를 뛰어넘었다고 하는군요. 국내에서도 올해 들어 많은 책들이 나오고 있지요. 2년 전에 출판사를 찾아가 루비 책을 출판하자고 설득을 했던 기억이 나는데, 참 재미있습니다.

A Peak at Rails 2.0

작년 RailsConf에서 World of Resources라는 멋진 발표 이후로 레일스는 많은 변화를 이뤄냈습니다. 리소스(여기서는 REST의 레일스 구현체라는 의미로 이해하시면 됩니다)가 자연스럽게 녹아있는 Rails 1.2가 발표되었고, 리소스 클라이언트인 액티브리소스는 정식 젬으로 배포되었습니다.

오늘 DHH의 키노트 중심 주제였던 Rails 2.0(후속 버전)에서도 이런 흐름은 이어지고, 더 자연스러운(주장이 강한) 모습으로 레일스와 결합할 것 같습니다. 그 중심에 있는 것이 바로 어제 소개한 Simply Helpful 플러그인이었는데, 최근 레일스 트렁크에 병합되면서 레일스 2.0 개발이 탄력을 받고 있습니다. 이 플러그인은 더 강한 관례(Convention)로 루비 객체를 리소스 표현법으로 변환시킵니다. 예를 들면, form_for person_path(@deepblue), :id => 'edit_person_1'  이라고 쓰는 대신 form_for @deepblue 라고만 쓰면 되는 것이지요. 이렇게 되면 @deepblue가 new_record인지 아닌지에 따라 각각 update(PUT)를 호출할지, create(POST)를 호출할지 자연스럽게 결정됩니다. 이것은 하나의 예일 뿐이고, 리소스에 대한 '통합된 접근(Universal Access)'을 보다 쉽고 빠르게 얻기 위한 방법으로 다양한 관례를 도입하고 있습니다. 이것이 제가 이해한 레일스 2.0의 핵심입니다.

레일스는 특히나 주장이 강한(opinionated) 소프트웨어입니다. 그 주장이 관례라는 이름으로 표현되고 있으며, 일부에게는 거부감으로 다가가고 또 다른 일부에게는 '생산성'으로 느껴지는 것 같습니다. 레일스 2.0은 더 큰 목소리로 Rails Way를 외칠 것 같습니다. 받아들이는 입장에서는 장단을 따져서 장점만 취하는 것도 좋은 전략입니다. 레일스의 주장이 마음에 들지 않는다면 레일스를 무시하거나, 더 나은 방법을 구현(플러그인으로)해서 공개하고 목소리를 내면 됩니다. 레일스는 오픈 소스 소프트웨어이기 때문입니다. 어쨌든 레일스 2.0에는 WebService가 구성 요소에서 빠지고, 스캐폴딩도 리소스 기반으로 바뀝니다. Ajax는 여전히 잘 지원할 것이고, OpenID와 ATOM도 든든한 우군이 될 것입니다.

제가 다행스럽게 생각하는 점은 레일스 2.0이 괴물(DHH의 표현에 따르면 유니콘)이 되지 않았다는 것입니다. 레일스 개발팀은 모든 것을 한번에 바꾸려는 어리석은 판단을 하지 않았습니다. 현재 상태에서 조금만 더 개선하고, 그 개선을 꾸준히 이어가는 방법을 택했습니다(사실 프로그래밍을 하다 보면 말처럼 쉽지 않은 선택입니다). 언제 릴리즈될지 아무도 모르는 루비2보다 훨씬 나은 선택입니다.

이번 키노트에서는 DHH가 새로운 레일스 방식으로 AddressBook을 만드는 라이브코딩 데모를 시도했습니다. 얼마 전 세미나에서 라이브코딩이 얼마나 힘든 일인지 뼈저리게 느껴서인지, DHH의 실수가 오히려 자연스럽게 보입니다. 그나저나 실수를 하고서 괴성(?)을 지르는 DHH의 모습이 너무 귀엽더군요. 하하.

이어지는 발표는 레일스 2.0에서 개선되거나 변경되는 내용을 9가지 항목으로 공개했습니다. 재미있는 점은 여기서 소개한 내용 대부분이 이미 사용할 수 있는 것이고, 그 중 일부는 스프링노트 서비스에 적용되어 있기도 합니다. 제가 가끔씩 EdgeRails에서 일어나는 의미 있는 변화들을 혼잣말처럼 중얼거리곤 하는데, 그것들이 발표 내용이었습니다. 크게 새로울 것은 없었지만, 레일스는 점점 진화하고 있구나라는 생각을 새삼 하면서 자기계발에 힘써야겠다는 딴생각을 한 제 모습이 좀 우습기도 하네요 ^^

오늘 DHH의 키노트를 들으며 여전히 레일스와 레일스 커뮤니티는 '건강'하다는 느낌을 받았습니다. 그리고 이런 모습 때문이라도 레일스의 도입이 확산될 것이라는 확신을 갖게 되었습니다.

Doing REST Right

이어서 Scott Raymond가 해온 REST에 대한 생각을 공유하는 세션을 들었습니다. 먼저 REST의 개념탑재가 시작되었습니다. 레일스 개발자들을 위해 레일스 개발자들이 오해하기 쉬운 사실들을 먼저 주의시키더군요. REST는 예쁜 URL도, CRUD도, respond_to도, map.resources도, HTTP도, 프로토콜도, 아키텍쳐도 아니라고 했습니다. 그러면서 REST를 웹에 적용할 수 있는 아키텍쳐 스타일이라고 규정하며, 통신 이론과 웹 아키텍쳐 중간에 있다고 설명했습니다. 일종의 가이드라인이라고 해도 괜찮은 표현인 것 같습니다. 그렇다면 리소스는 무엇일까요? 리소스는 Identification(주소), Interaction(작은 메서드 셋), Content(데이터)를 가진 객체입니다.

그러면서 실제 REST를 믿고 따르며, 개발하다 보면 자연스럽게 하게 되는 고민들에 대해 같이 생각해보는 시간을 가졌습니다. 저도 많이 고민도 하고, 질문도 받았던 부분이었는데 정리가 되는 것 같아 매우 유익했습니다.

몇 가지 예를 들면, 여러 개의 리소스를 한꺼번에 업데이트하고자 하면 어떻게 하느냐는 질문이 있었습니다. 스프링노트의 목록 페이지에서 페이지 리소스들을 선택해고 한꺼번에 삭제하는 등의 메서드를 호출하는 경우를 떠올리면 됩니다. 이 경우 범위(Scoping)으로 해결할 수 있습니다. 선택된 리소스들을 하나의 범위로 이름을 주고, 그 범위 리소스의 삭제 리소스를 호출하는 방식입니다. 리소스의 일부만 수정하는 경우도 마찬가지로 범위 문제입니다. 트랜잭션도 마찬가지입니다.

가장 많이 받는 질문은 내가 만드는 애플리케이션은 매우 특별해서 GET/POST/PUT/DELETE로는 표현할 수 없다라는 것인데, 답은 명확합니다. 틀렸을 것이 분명합니다. 특별한 것은 없습니다. 모델을 찾아내서 규정해야 합니다. 물론 그렇게 해서 다소 비효율적인 코드가 될지도 모릅니다. 하지만 그보다는 리소스에 대한 공통된 접근법(Universal Access)가 더 훌륭한 가치입니다. 어디든 트레이드-오프는 있기 마련이니까요.

안정성(Reliability)를 위해 2단계 커밋(Two Phase Commit)을 제안하는 것도 인상적이었습니다. POST는 상태를 갖는 위험한 메서드이기 때문에, 그 전에 먼저 POST를 해보고 신선한(fresh) URL을 얻어서, 그 URL에 커밋하라는 것이지요. 동시성을 위해 ETag를 사용하라는 것도 괜찮은 아이디어로 보였습니다.

또 하나 재미있었던 것은 레일스가 REST를 추구하면서 잘못하고 있는 점을 꼬집은 것입니다. Identification(URL)에 컨텐트의 종류(예를 들면 1.xml)을 포함시킨 것은 일종의 UI를 강제한 것이라는 것입니다. 동감하는 부분입니다. 또 하나 지적한 것은, ActiveResouce#to_xml이 만들어내는 출처 불명 데이터입니다. 새로운 모델을 매번 정의하고 DB를 투명하게 노출하는 방법보다는 이미 잘 알려진 컨텐트 유형을 쓰는 것이 나은 접근이라는 것입니다. 사실 스프링노트도 이 부분을 지적해주신 kayflow님 덕분에, 널리 쓰이는 더블린 코어를 일부 따르도록 용어(속성)을 수정한 바 있습니다. 이런 목소리가 늘어나면 레일스는 또 한번 성장하겠지요. 저도 그 목소리의 하나가 돼야겠다는 생각이 많이 듭니다. REST에서 취약한 통지(Notification)에 대해서는 현재처럼 폴링하는 것보다는 콜백을 등록하는 모델이 있었으면 좋겠고, 레일스 커뮤니티에서 이 부분에 리더십을 발휘하면 어떨까라는 의견도 냈습니다.

평소에 가지고 있던 REST에 대한 생각이 조금 정리된 정말 유익한 개념탑재 세션이었습니다.

그 외의 세션들

그 외에서 인상적인 세션이 많았습니다. 특히나 UncleBob으로 더 유명한 로터브 마틴의 Clean Code 세션은 '열정' 그 자체였습니다. 그의 강의를 듣고 있다는 사실만으로도 새로 태어나는 기분이 들고, Uncle Bob의 에너지가 저에게까지 쭈욱 전달되는 느낌이었습니다. 더 많은 사람들이 그의 강의를 듣고 Clean Code를 위해 노력했으면 좋겠습니다. 우주 평화를 위해서라도. 여기 저기 뛰어다니면서 강의하는 모습이 생각나서 웃음이 납니다. 역시 Uncle Bob!

제가 루비세미나에서 잠깐 소개했던 Heckle을 여기서 다시 만나니 굉장히 반갑더군요. 작년에 연극으로 인기를 끌었던 Adam Key의 유머는 여전했습니다(이번에는 유명한 Identification 2.0 발표를 패러디해서 세션장을 웃음바다로 만들었습니다).

Steven Smith는 레일스가 엔터프라이지를 위해 준비되었는가에 대한 질문에 '엔터프라이즈는 레일스를 위해 준비되었느냐'며 되물었습니다. RailsConf니까 가능한 발표들이었겠지만, 엔터프라이즈에도 변화의 바람은 필요하겠죠.

Avi Bryant는 30년 후의 루비라는 주제로 키노트 발표를 했습니다. 문자는 달라도 발음은 똑 같은 인도의 언어를 예로 들면서, 스몰톡과 루비는 다르지 않다고 했습니다. 스몰톡은 외계의 기술이 아니라는 것이지요. 그러면서 스몰톡이 이미 이루어놓은 훌륭한 기술들을 레일스 커뮤니티에서 참고하고, 이를 통해 영감을 얻어야 한다고 했습니다. RailsConf에 와서 스몰톡 좀 배우라고 발표를 한 용감한 Avi의 말을 완전히 믿고 따르는 분위기는 아니었지만, 그래도 많은 아이디어를 얻었습니다. 루비나 레일스의 발전 방향을 조금은 본 것 같은 느낌도 듭니다. 그가 던져준 먹이들은 귀국해서 하나씩 곱씹어볼 생각입니다. 멋진 발표와 데모였습니다.

마지막으로 저는 100% 이해하지 못했지만, Ze Frank의 다들 완전 뒤집어지더군요. 유쾌한 캐릭터더군요. 길고 긴 하루였지만, 이 자리에 있어서 행복합니다. 12시간씩 걸려서 이국땅에 와 있는 보람이 있습니다. 컨퍼런스가 끝나지 말았으면 좋겠다는 생각까지 드는 건 저의 오버일까요? 아, 컨퍼런스 정리에는 스프링노트가 최고입니다. 가끔 옆에 앉아있는 사람에게 이거 한국에서 레일스로 만든 위키야, 멋지지~라며 자랑도 할 수 있어서 재미있었습니다. 스프링노트팀 여러분 파이팅!

내일은 또 어떤 생각들을 흡수할 수 있을지 기대됩니다.

- deepblue

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

자칭 타칭 루비 매니아(?) 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

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