Blog

지난 토요일 루비세미나가 있었습니다. 2년전 오픈마루의 작은 회의실에서 20명 정도가 모여서 사는 이야기를 나누던 이 모임이 100명 넘게 참석하고, 또 50여명은 대기자로 등록해주실 정도로 커져버렸습니다. 준비하는 동안 ikspres님과 자주 메일, 채팅으로 이야기를 나눴는데 '일이 점점 커지네~' 하면서 두려워하는 게 대부분이었다죠? ^^


3046/2627062674_87eb1dd312.jpg 3011/2627051216_69e06d660d.jpg

<사진> 다들 진지한 모습이시네요~


하지만 지나친 걱정이었고, 많은 분들이 도와주셔서 무사히 마칠 수 있었습니다. 특히나 진행을 해주신 엠씨꽃띠앙님과 재치 넘치는 ikspres님, 여러모로 신경써주신 한국소프트웨어진흥원 방용주선임님, 인사이트 출판사 관계자분께 감사드립니다. 아, 그리고 알게 모르게 여러 방면에서 힘써주신 오픈마루 식구들(함께 openmaruby라는 스터디도 하고 있어요)!~ 이럴 땐 오픈마루의 일원인 게 뿌듯하기만 합니다. :) 암튼, 닭살 멘트는 그만 접고, 본격적으로 후기를 들려드리겠습니다.


루비/레일스의 세계로 안내합니다

지금까지 루비세미나는 이미 루비를 활용하고 계신 분들이 모여서 이야기를 나누는 곳이었습니다. 그렇치만 주변에서 업무에 루비/레일스 도입을 원하시는데, 자료가 많지 않아서 혹은 뭔가 물어볼 곳이 없어서 답답하다는 말씀을 많이 해주셔서 전격적으로(?) 튜토리얼을 마련하게 되었습니다. 아주 작은 시도고, 2시간이라는 짧고 제한된 시간이었지만 조금이나마 갈증 해소에 도움이 되었으면 좋겠습니다.

먼저, ikspres님이 루비 문법에 대해 때로는 차분하게, 때로는 개그와 함께 설명해주셨습니다. 루비를 처음 보시는 분들이 실무에 루비를 사용하게 될 때 도움이 될 수 있을 것 같았습니다. 저도 찬찬히 루비의 문법을 곱씹어볼 수 있는 시간이었습니다. 루비가 너무 쉬운 언어라는 이야기를 많이 하셨죠. 맞습니다. 꽤 쉬운 언어입니다. 얼랭처럼 A4 한 장에 들어가는 적은 문법을 가지진 않았지만, 상식의 틀을 쉽게 벗어나지 않는(Principle of Least Surprise라고 표현합니다) 특징을 가지고 있어서 배우기 쉽습니다. 맘만 먹으면 금방이죠. ^^ 이날 참석하지 않으신 분들도 발표 자료와 동영상(곧 공개될)을 보시며, 천천히 따라 해보셔도 좋을 것 같습니다.

모듈, 믹스인, include, extend에 대한 설명이 인상적이었습니다. extend를 객체에 사용하는 용법은 평소 사용하지 않던 문법인데, 흥미로웠습니다.


  1. module Hello; def to_s; "hello, #{super}"; end; end
    'ruby'.extend(Hello).to_s   #=> 결과는 ""hello, ruby"

3108/2626229417_fd1f08abc5.jpg 3123/2626236875_6e4be60510.jpg

<사진> 튜토리얼 발표중인 ikspres님(왼쪽), 그리고 엠씨꽃띠앙님과 deepblue

ikspres님이 루비를 잘 설명해주셨기에, 어떤 면에서는 루비 라이브러리에 불과한 레일스에 대한 튜토리얼을 맡은 저는 할 말이 그다지 많지 않았습니다. 그래서 주변 이야기를 많이 한 것 같습니다. 앞으로 레일스 프로젝트를 하지 않더라도 레일스에서 배울 점은 배워서 더 높은 생산성을 얻으실 수 있었으면 하는 마음이었습니다. 실질적인 코드나 사례를 많이 보여드리지는 못했지만, 또 기회가 있겠죠? ^^; 발표 자료도 함께 올려봅니다.

이렇게 2시간여의 튜토리얼을 마쳤습니다. 이제 이날의 엑기스~ 본행사의 시작입니다! 여기서는 커뮤니티의 여러분이 자발적으로 나오셔서 정말 다양하고 알찬 이야기를 해주셨습니다. 다 듣고 나니 배가 불러오면서, 충만한 느낌이 들더군요!


스티브 잡스의 머릿속엔 뭐가 들어있을까?

먼저 마이아이디넷 서비스를 개발하고 계신 JasonPA님이 WWDC에 다녀온 이야기로 스타트를 끊어주셨습니다. 오픈마루 블로그에도 장문의 글들을 남겨주셨지만, 참 즐겁고 열정적인 행사였을거라는 느낌이 들었습니다. 그리고 그 열정이 이날 행사에까지 이어지는 기분이었습니다. 맥이든 루비든 혹은 양쪽 모두든, 무언가에 열정적인 사람은 멋진 아우라와 함께 주변을 즐겁게 하는 것 같습니다. 아무리 오덕스러워도 말이죠. ^^



스노우 레퍼드에 탑재될 맥루비도 무척 기대되는군요.


보석만으로는 살 수 없죠?

개발자는 상황에 맞는 적절한 도구를 꺼내서 사용해야 합니다. 그런 의미에서 외부 시스템과 연동할 일이 있어서 C 확장기능을 만들어야했다는 미투데이 kkung님의 경험담(Ruby with C!)은 우리에게 새로운 도구 하나를 더 전해주었군요. 언젠가 마츠(루비 개발자)가 자신을 C 코드를 더 자주 보게 되는 C 개발자라고 소개한 적이 있습니다. 다만, 마츠가 사용하는 C는 보통 C가 아니라, 루비 API를 가진 루비빛 C였을겁니다. 이 C 언어에서는 문법은 다르지만, 루비에서 하던 습관을 대부분 사용할 수 있는 환경이죠. 그만큼 C 언어 API가 잘 정의되어있다는 의미입니다. 어쨌든 kkung님의 발표대로 루비와 C를 연동하는 일(확장을 만들어 루비에서 C를 호출하든, 반대로 C에서 루비를 임베딩해서 호출하든)은 생각보다 쉬운 일이라는 거죠. 오늘은 C 언어를 완전히 잊어먹기 전에 다시 한 번 꺼내서 사용해봐야겠습니다. :)


3278/2626252631_10ff899d7e.jpg  3112/2627053020_5305087bbb.jpg

<사진> C가 제일 쉬웠다는 꿍님(왼쪽)과 쉬는 시간 토론에 빠진 사람들. 맨 오른쪽이 얼랭 연극을 선보이신 석준님!


그 다음에는 최근 프로그래밍 얼랭을 번역하신 석준님이 나서시더니, 앞에 앉은 몇 분을 일어서게 합니다. 그리고 서로 악수를 시키더니 한분더러 쓰러지라고 하십니다. 하하~ 평소에 잘 안 하시던(^^) 연극까지 준비해 오셔서 정말 멋지게 얼랭의 개념(많은 경량 프로세스들이 서로 메시지를 주고받고, 연결되기도 함)들을 소개해주셨습니다. 쏙쏙들어오는 강의 정말 잘 들었습니다. 루비가 얼랭에 빠진 날이라는 제목으로 마지막에는 얼랭으로 REST 서버를 구현하고 레일스로 프론트엔드를 구현하면 어떻겠느냐는 아이디어도 주셨습니다. PragDave의 RADAR 아키텍쳐를 차용하셨는데, 흥미로웠습니다. 요즘 얼랭에 빠져 뭔가 재미있는 구현거리(연습거리)가 없나 촉을 세우고 있던 저에게 정말 단비와도 같았습니다. 꼭 실습해보겠습니다.


또, 음악을 하신다는 duocorda님의 마치 콘서트 같았던 유쾌한 발표 Useless Gears도 생각나네요. 제목처럼 쓸모없지는 않고, 유용한 구석이 많더군요 ^^ 한 손엔 Gears 다른 한 손엔 Ajax를 외치시며 Gears에 대한 사랑과 관심을 부탁하셨습니다. 너무 열정적으로 발표를 해주셔서, 어떤 분은 duocorda님이 구글 직원이 아니냐는 의문을 제기하셨고, 확인한 바 그건 아니라고 합니다. 하하. 스프링노트에서도 기어스 좀 사랑해볼까요?


3138/2626265363_610afe1934.jpg  3104/2626248087_e50e129b63.jpg

<사진> 기어스 사랑을 외치시는 duocorda님(왼쪽)과 WWDC 다녀오진 JasonPA님(오른쪽) 발표중!


현실을 이야기해봅시다

올해로 레일스가 나온 지 4년쯤 됩니다. 해외에서는 웹서비스를 구축하는 사람들은 누구나 한번쯤 레일스를 고려하고, 기업에서도 도입을 시작할 정도로 대중화되었습니다. 그렇다면 국내의 현실은 어떨까요? 국내에는 커뮤니티가 생긴지 5년째입니다만, 아직 루비가 많이 알려졌다고 보기는 힘들 것 같습니다. 이번 세미나에서는 여기에 대한 이야기를 나눌 수 있는 의미 있는 시간이 있었습니다.


먼저 1인기업 InoCrazy를 하시는 김동규님이 관공서를 포함한 여러 곳에 레일스를 도입하면서 느낀 점을 이야기해주셨습니다. 이런 프로젝트를 하다보면, 고객의 마음이나 요구사항이 바뀌는 일이 잦은데, 이 때 동규님의 경험으로는 다른 환경보다 레일스를 사용했을 때 더 빨리 변할 수 있었다고 합니다. 이런 점은 프로젝트를 성공적으로 마치는데 큰 도움이 되었다고 했습니다. 하지만, 레일스 자체를 몰라서 설득해야하는데, 아무런 데이터도 없다는 점, 알 FTP면 전부 다되는 세계에 레일스의 복잡한 배포환경(카피스트라고가 뭥미?)을 도입하는 것은 어림도 없다는 점이 힘들었다고 합니다. 그래도 이렇게 노력하시는 분들이 있으니, 느린 속도지만 국내 환경도 조금씩 조금씩 변할 수 있다고 생각해 한편으로는 기쁜 마음도 들었습니다. 박수를 보냅니다. 짝짝짝~!


3259/2627077626_a35260ff9c.jpg  3116/2627076290_b51246a22f.jpg

<사진> 대산님의 10분토론(왼쪽)은 쉬는 시간에도 이어집니다! (오른쪽 사진에 동규님 있다~)


최근 페퍼코드 사장님으로 변신한 대산님은, 즉석에서 국내의 현실에 대한 10분토론을 진행하였습니다. 저도 꽤나 궁금했는데 여러분들의 의견을 들을 수 있어서 좋았습니다. 이런 논의를 들으며, 지금까지의 소극적인 커뮤니티보다는 이제 좀 더 적극적인 커뮤니티 활동이 필요하겠다는 생각도 들었습니다. 쉬는 시간에도 이런 이야기를 대산님과 이어갔는데, 루비센트럴처럼 비영리 단체에 대한 의견도 있었습니다. 약간 꿈같은 이야기지만 말입니다. 암튼, 기술적인 문제인 호스팅이나 인식, 문서 부족 등은 오히려 쉬운 편에 속하고, 금방 해결될 거라 생각합니다. 그보다는 국내 IT 업계가 풍족해지고, 특히 웹에서 새로운 시도를 하는 스타트업들이 많이 생겨나기를 바라는데 이건 어떨까요?


JRuby는 기회의 땅일까요?

루비는 변화의 시기에 있습니다. 그리고 그 변화를 가장 이끌고 있는 것이 JRuby가 아닐가 하는 생각도 듭니다. JRuby는 대안 루비 경쟁의 선두그룹에 있습니다. 탄탄한 JVM과 잘 갖춰진 자바 인프라를 등에 업고 있으니, 당연한 일인지도 모르겠습니다. 전에도 한번 루비세미나에서 JRuby를 소개하셨던 ias님이 그 2탄을 준비했습니다. JRuby가 워낙 빠르게 변화하고 있어서, 작년에 만든 책의 예제들이 올해는 하나도 돌아가지 않더라는 사실이 인상적이었습니다. 이렇게 빠르게 변하는 세상을 기존 도서가 쫓아가기는 조금 버거워 보이기도 합니다. 그래서 ias님은 iPhone 플랫폼에서 JRuby on Rails for Open Apps라는 주제로 E-Book을 준비하시고 계시다고 합니다. 항상 재미있은 일을 잘도 찾아내시는 ias(형!!!!!)님입니다. 오우~



그 다음은 오픈마루의 마지막 주자 지웅님(험블프로그래머)입니다. 자바개발자를 위한 레일스를 번역하면서, 역자직강을 부탁드렸는데 6개월 만에 성사되다니, 참 기쁜 일이네요~! 지웅님은 좀 더 현실적인 견지에서 자바와 루비의 관계에 대한 이야기를 해주셨습니다. 논리적인 전개와 멋진 목소리(발표 목소리가 멋져요~)가 인상적이었다죠? ^^ 새로운 팀에서 루비로 프로토타이핑을 해볼 수 있게되었다고 기뻐하고 계시는 지웅님이, RoR 프론트엔드 + 스프링의 멋진 조합을 실전에서도 보여주시고 앞으로 계속 사례를 만들어주시길 기대하겠습니다. 아 그리고 현재의 환경이 '레일스가 메인스트림으로 가기 위해 활용해야할 의미 있는 레거시'라는 의견에 전적으로 동의합니다.



루비 세상은 정말 빠르게 변하고 있습니다. 6개정도의 루비 구현체가 '다음 루비'를 노리고 있습니다. 현재는 MRI(루비 1.8)가 단연코 승자지만, 내년 이맘때는 어떻게 될지 아무도 모릅니다. 저는 이런 경쟁을 보고 있는 게 마치 야구 경기를 보는 것 마냥 즐겁기만 합니다. 긍정적인 변화의 모습이니까요. 하지만, 구경만 말고 조금이라도 거들어야 할텐데, 마음만 앞서가서 큰일입니다. 에효~


3108/2626255531_3d1bfcca78.jpg  3076/2626249003_81f794ae5b.jpg

<사진> 숨은 오픈마루인 찾기 1편


세상을 바꿀 열정을 가진 사람들

루비세미나의 빼놓을 수 없는 재미, 신규 서비스를 살펴볼 차례입니다. 이번에는 두명의 청년이 운영하는 파프리카랩FaceWorthyPapree입니다. 우연한 기회에 브라질 사람들을 위한 사이트가 되었다는 FaceWorthy의 여러 뒷이야기가 재미있었습니다. 고객과 함께 개발자들은 전혀 읽지도 못하는 포르투갈어 버전을 오픈했다는 이야기는 이들이 어떤 모험을 즐기고 있는지를 보여주는 것 같습니다. 그리고 (힘든 일도 많겠지만) 무척이나 즐거워보였습니다. 또 한명의 꿈을 가진 청년 성윤님은 동료를 얻기 위해 나섰습니다(엇, 갑자기 원피스가 떠오르는군요). 두 회사 모두 꼭 뭔가를 이루시기를 바랍니다. 커뮤니티에서도 팍팍 응원하겠습니다.


3267/2626268817_1ef08558c5.jpg  3188/2626272483_e3ca2f9dcb.jpg

<사진> 열심히 발표중인 창수님(파프리카랩)과 성윤님.


묘한 우연으로 진흥원으로 가는 지하철에서 마이 스타트업 라이프라는 책을 집어들고 읽고 있었는데, 이 책의 저자는 자신의 창업 동기를 '세상을 바꾸려는 열망'으로 표현했습니다. 그리고 루비세미나에서 세상을 바꿔가고 있는 사람들을 만났습니다. 척박한 현실이지만, 그 속에서도 자신의 꿈을 성공을 향해 나아가는 그들의 모습이 아름답게 보입니다. 다시 한 번 현재 나의 위치와 하고 있는 일, 자세 등을 돌아보게 됩니다. 그들만큼 치열하게, 열정적으로 즐겁게 살고 있는지 말입니다. 그리고 오픈마루를 생각합니다. 오픈마루의 역할은 무엇인지, 다함께 성공할 수 있는 길은 무엇인지... 아마 시은님이 마지막으로 공유해주신 WinterOfCode2008도 다함께 성공하기 위한 하나의 시도일지 모르겠습니다. 주제넘으니까 무거운 이야기는 이쯤에서 접어야죠.


3132/2626251237_30405ffbd3.jpg  3181/2627055600_cccf72dd78.jpg

<사진> 숨은 오픈마루인 찾기 2편


루비세미나 후유증에 시달리다

루비세미나를 마치면, 여러 경로로 좋은 실든 후유증에 시달리게 됩니다. 이번에도 마찬가지입니다. 아래는 세미나를 마치고 밤에 잠을 못 이루고 미투데이에 적은 글입니다.


deepblue님의_미투데이.jpg


그리고 이런 단점이 있는지도 모르겠습니다. 아마 sunq님도 변화를 느끼신 것 같습니다.


http://deepblue.springnote.com/pages/1428754/attachments/619510


암튼, 덕분에 동기부여도 되고, 장난감도 많이 생기고, 그들의 열정도 조금이나마 흡수해서 풍족한 상태가 되었습니다. 만난 분들 모두 모두 반가웠습니다. 다음 세미나(7회)는 언제 열리냐고요? 이렇게 충전된 내용이 떨어져 가면 바로 그 때가 루비세미나가 열려야할 때입니다! 그 때까지 행복하세요~


- deepblue


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

지난 주에 오픈마루 사무실에 일본 시마에 대학 경제학 교수님이자 오픈소스를 연구하시는 노다 테츠오 (野田哲夫, Tetsuo Noda) 교수님이 찾아오셨습니다. 기업의 오픈소스 활용 및 개발이 기업과지방 도시 경제에 주는 영향에 대해 계속 연구를 해 오셨는데, 한국의 기업들은 오픈소스의 활용 및 개발에 대해 어떤 입장을 가지고 있는지 사례를 듣고 싶어서 오셨다고 합니다.

오픈마루에서는 이창신과 주마군이 참석하여 대화를 나누었고, 통역에 박지인님께서 수고해 주셨습니다.

짧은 시간이었지만 교수님과의 대화를 통해 저희도 많은 인사이트를 얻을 수 있었는데요, 특히 일본에서는 지방 정부차원에서 오픈소스를 적극 도입하려고 한다는 경제적인 이유들이 흥미로워 간략하게나마 대화의 핵심 내용을 공유할까 합니다.

사용자 삽입 이미지

  • 노다 테츠오 교수님 (이하 노다): 오픈소스를 활용하는 것이 오픈마루에게는 사업적으로 어떤 의미를 갖나
    • 오픈마루: 메리트는 크게 두가지이다. 하나는 비용, 또 하나는 기술인데, 특히 기술적인 면에서는 소프트웨어 개발이라는 것을 '문제 해결'이라는 점에서, 공개된 소스를 통해 어떠한 고민을 함께 한다던가 먼저 했다던가 하는 집단 지성적인 해결의 실천이 가능하다는 점이 매우 매력적이다.
  • 노다: 오픈소스를 쓰면서 곤란한 점이나 어려운 점은 없었는지
    • 오 픈마루: 오픈소스는 매우 인간적이어서, 개발을 주도하고 참여하는 사람들의 열정에 의존하는 비중이 커서 안정성이나 소스에 대한 빠른 수정이나 긴밀한 참여가 이루어 지지 못할 때도 있다. 참여가 열려 있기는 하지만, 그것이 코드 수준에서 일어나기 위해서는 현실적인 장벽이 존재한다. 예를 들어 RoR를 쓰면서 패치를 올려도 반영이 잘 되지 않는 경우가 있다.
  • 노다: 오픈마루에서는 직원의 오픈소스 커뮤니티 활동에 대해 어떤 입장을 취하고 있나.
    • 오픈마루: 오픈마루는 기본적으로 개발자의 오픈소스 커뮤니티 활동을 장려하고 있다. 실제 강문식님은 한국 루비 커뮤니티에서 활발한 활동을 하고 있고, 오픈마루는 세미나 장소와 행사 진행을 돕고 있다. 또 대안언어축제나 Winter of Code 등 다양한 행사에 후원 또는 주최를 해서 개발자들의 열린 비전 제시에 심혈을 기울이고 있다.
  • 노다: 오픈마루를 오픈소스를 활용하면서 어떤 이점을 보고 있나.
    • 오픈마루: 이미 오픈마루의 두 서비스, 스프링노트와 myID가 RoR을 기반으로 개발, 현재 운영중인데, 우리 같은 경우에 무거워지는 기존 개발 프로세스에서 탈피해 루비의 유연함이 빠르고 과감한 개발을 도왔다고 생각하고, 또 그런 것들이 이용자의 아이디어와 기획를 최대한 수용할 수 있게 해서 결국 사용자의 가치와 연결되었다고 생각한다.

  • 노다: 현실적으로 회사에서 월급을 받으며 오픈소스를 쓴다거나, 개발한다는 것이 상업적인 이윤을 추구하는 회사에서 제약이 있을 수도 있지 않나. 구글의 80/20 제도와 같은 별도의 정책이 있나.
    • 오픈마루: 오픈소스를 쓰는 것은 앞서 말씀드린 메리트면에서 결과적으로 좋은 아웃풋을 내 놓는 것을 알기 때문에 전반적으로 장려를 하는 편이다. 그리고 오픈소스 커뮤니티 활동을 하는 것도 조직과 회사의 제품을 알리는데에도 중요한 역할을 했던 것 같다. 그래서 그런 활동은 오히려 장려 하는 편이다.
    • 오픈 소스 개발도 권장을 한다. 실제 강규영님이 담당하여 스프링노트 에디터 컴포넌트를 오픈소스로 개발하고 있는데, 제품과 관련해 컴포넌트들을 오픈소스로 개발하는 것이기 때문에 제품에 오히려 도움이 되지 별도의 일을 한다고 생각하지 않는다.
    • 구글의 80/20 이야기가 나와서 말인데, 오픈마루에도 유사한 제도가 있다. 텐윅스(TenWeeks)라는 프로그램인데 결과물을 오픈소스로 하든 안 하든 그건 개인의 자유이고, 텐윅스를 활용할 경우에는 제품과 전혀 관련 없는 오픈소스를 만들 수 있다. 이번에 첫 텐윅스 프로젝트를 통해 만들어질 RoR 기반 소프트웨어가 첫 사례로서, 일본 RoR 공모전에도 출품 된다. 9월말 접수 후 마찬가지로 오픈 소스로 공개될 예정이다.
  • 노다: 아 정말 잘된 일이다. 꼭 수상했으면 좋겠다. 텐윅스 제도를 좀 더 구체적으로 설명해 주실 수 있나
    • 오픈마루: 발의자가 프로토타입을 만들어서 직원들 대상으로 데모를 하고, 직원들의 2/3이상의 찬성을 받으면 텐윅스로 프로젝트를 진행할 수 있습니다.
사용자 삽입 이미지

  • 노다: 내가 지금 참여하고 있는 Ruby Association을 소개해 주고 싶다. 회사와 커뮤니티의 중간적인 역할을 하는데, Ruby Association의 역할은 루비자체의 기술적인 발전이나, 커뮤니티 지원, 이벤트 주최 등의 활동을 하고 있다.
    • 오픈마루: 어떤 분들로 구성되어 있나
  • 노다: 루비와 관련된 기업들과 단체로 구성되어 있다. 기업이 직접 커뮤니티를 지원할 수도 있지만, association에 지원을 하고 그 단체가 커뮤니티들을 지원하는 형태라 할 수 있다. 한국에도 그런 조직이 있나.
    • 오픈마루: 국내에서는 JCO가 가장 유사한 형태가 아닐까 싶다. 하지만 법인은 아닌데, Ruby Association은 어떤지.
  • 노다: 일본은 LLC 형태의 법인으로 설립된 상태이다.
  • 노다: 한국에서는 루비 관련된 기업이나 단체가 많이 늘어 났을 때 어떤 움직임이 있을 것 같은가.
    • 오픈마루: 잘 모르겠지만, JCO의 경우 기업에서 java를 채택을 많이 했다는 것이 가장 큰 역할을 했던 것 같고, 그래서 IBM, Oracle같은 많은 기업들이 참여할 수 있었다. 그런 면에서 보면 루비를 채택하는 기업 플레이어들이 많지 않다는 면에서 JCO와 같은 모멘텀을 확보 할 수 있을지는 아직 모르겠다.
    • 요새는 SUN에서 JRuby를 많이 밀고 있고, 마츠는 “코드가 곧 스펙이다”라고 하지만 루비도 스펙과 검증에 관심을 기울이면서 좀 더 공신력있게 된다면 루비 상용 시장이 열리지 않을까 하는 게 전문가들의 의견이다.
  • 노다: Ruby Association 에서는 Ruby On Rails 강사 교육 프로그램을 만들고 수료를 하면 강사 인증을 해주는 형식을 생각했으나, 사사 다쿠치상 (현재 일본 레일스계를 이끄시는 분)은 반대하고 있다. ^^ 기업쪽에서 생각하는 것과 커뮤니티에서 생각하는 방향이 다를 수 있으니 association에서 중간 역할을 해 줬으면 좋겠다.
  • 노다: Ruby Association에 기업만 참여하는 것이 아니라 정부와 학계에서도 참여를 하고 있다. 루비 산업을 발전시키는 것이 일자리 창출에도 기여한다고 생각해서, 나도 학계입장으로 참여하고 있다. 오픈소스가 범세계적인 활동이라는 점이 이상하다고 생각할 수도 있지만 이런 활동이 지방 도시에 도움이 된다고 생각하여 참여하고 있다.
  • 오픈소스를 연구하는 입장을 가지고 있기 때문에 연구적인 면에서의 관심사도 되지만, 루비가 시 발전에 도움을 주도록 하는 것이 목표이기도 하고, 내년에는 루비 컨퍼런스를 마츠에시 (교수님이 살고 있는 곳. 루비의 아버지 마츠도 여기에 산다), 시마네 현, 오사카 북쪽에 위치)에도 진행하고자 한다. 원래를 도쿄에서만 진행이 되었었다.
  • 노다: 오픈소스를 사용하는 기업들이 늘면 서로 경쟁기업일 수도 있지만, 오픈소스 커뮤니티를 발전 시키는 입장에서는 공동으로 무언가를 하실 수 있지 않을까. 오픈마루에서는 이런 사례는 없는지
    • 오픈마루: 오픈마루에서는 오픈소스에 대해서도 활동을 하지만, 그 보다 오픈 api 관련 활동을 더 집중해서 하고 있다. 국내 포탈에서도 OpenApi 활동에 많은 기여를 하고 있고, 예를 들면 다음 네이버 매시업 경진대회가 그런 형태라고 할 수 있다.

  • 오픈마루: 우리도 일본의 오픈소스 환경에 대해서 궁금한 게 있는데, 기업에서 루비를 채택하지 못하는 이유가 스크립트 언어라서 소스 공개의 문제가 있다는 얘기도 있는데 일본에서는 어떤 대안이나 이야기가 되고 있는지
    • 노다: 일본에서도 별반 다르지 않은데, 보안보다 속도가 중요한 경우에는 채택을 하게 되는 것 같다. 라쿠텐(일본 최대 인터넷 쇼핑몰 회사)의 경우가 대표적인데 웹2.0 서비스와 같이 빠른 소프트웨어 개발이 중요한 경우에는 레일스를 채택하는 것 같다.
  • 오픈마루: 일본에서 기업이 오픈소스를 사용하고 개발함으로써 얻는 장점을 성공사례로 잘 보여준 케이스가 있는지. 교수님께서 계속 연구를 해 오셨으니까 많이 아실 것 같다.
    • 노다: 정부나 지방정부의 적극적인 도입을 이야기 하고 싶다. 이유는 비용적인 면이 물론 있고, 특히 특정 벤더에 얽매이지 않아서 좋다. 특정 회사에서 개발을 하게 되면 계속 그 회사에 종속되는데, 오픈소스를 활용하면 그런 단점을 극복할 수 있는 메리트도 있다. 물론 단점도 있긴 하다. 소프트웨어를 구매하게 되면 매뉴얼이 잘 되어 있지만 오픈소스는 그렇지 못하고, 또 오픈소스를 잘 활용하기 위해서는 설계 단위에서부터 관여를 해야 되기 때문에 단점이 될 수 있으나, 정부에서 직원을 미리 참여 시키거나 관련된 사람과 함께 작업을 하는 경우도 있다. 지역의 작업 기업에서도 그렇게까지하는 이유는 다른 지방의 대기업을 통하지 않고도 자기 지방의 작은 기업에 하청을 줄 수 있기 때문이다.
    • 오픈소스는 만드는 것도 중요하지만 사용하는 것이 중요하기 때문에 앞으로 얼마나 쉽게 사용할 수 있게 할지가 관건이 될 수 있다. 특히 서울같은 큰 도시는 이런 고민이 없겠지만 지방이나 작은 도시에서는 지역 내 기업들을 살리기 위해 이런 활동이 필요하다.
사용자 삽입 이미지

직접 오픈마루까지 찾아오셔서 이런 저런 이야기를 나누어주신 노다 교수님과 박지인님께 감사드립니다.

“오픈소스와 지역문화의 만남”하니 떠오는 것이 있는데요, 벌써 제주대에서 첫 강의가 시작된 공개 소프트웨어 공학 의 10월 12일 강의에서 실질적인 오픈소스 개발에 대해 함께 이야기하는 기회를 가지게 되어 무척 기쁩니다.

특히, 올 가을 선보일 오픈마루의 오픈소스 프로젝트(많은 분들이 Xquared를 기다리고 계시죠? 오픈마루 첫 텐윅스 프로젝트인 스프링북도 개봉박두입니다)서비스가 선보일 글로벌 디벨로퍼 커뮤니티는 언어적 장벽을 뛰어넘어 영어권 개발자들과 한국 개발자들을 잇는 색다른 경험을 가능하게 할 것입니다.

오픈마루도 분당을 거점으로 하고 있으니 근처의 대학교와 이런 재밌고 유익한 코스를 함께 하고, 또 지금은 열심히 공사중인 판교 테크노벨리를 바탕으로 Open Software City로 발전하는 꿈을 찐~하게 꾸어봅니다. ^o^/

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


210/510539011_1133a75c81.jpg


컨퍼런스 마지막 날에 재미있는 일이 있었습니다. 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인데 이 프로젝트는 명세서(문서)의 역할을 할 수 있는 코드를 추구합니다.


199/521162613_d2342f04b0.jpg


떠오르는 기대주 JRuby

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


230/502791413_c3a3a6a7f7_m.jpg


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


Rails is LOVE

222/509681296_0b12654819_m.jpg


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


pragdave/images/2007/05/20/rails_logo_heart.png


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


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


추천 리소스

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

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

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

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

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

꽤 많군요. Have Fun and Do Good!


- deepblue

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

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


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

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


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


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


191/504010544_67ebe503ed_m.jpg


이 외에도 정말 재미있는 발표들이 이어졌습니다. 어쩜 다들 그렇게 유머감각까지 장착했는지(루비가 유머도 가르쳐주나요?). 한편으로는 무척 부러웠습니다. 사실 저도 스프링노트를 데모하고 싶은 마음이 간절했습니다. 일주일 전만해도 '주마군 각본, 이아스 더빙, 딥블루 립싱크 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이 추구하는 방향을 설명하고, 그 자리에서 반박하고, 다양한 토론(너무 즐거운)이 이뤄졌습니다.


232/505466312_dc7ffc0863_m.jpg


제가 행사장을 나온 것이 밤 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도 쉬워진다는 설명입니다. 더 자세한 내용은 제가 돌아가서 테스트를 해보고 전에 작성한 '레일스 최적의 배포 환경'이라는 글을 갱신하겠습니다.


204/505602374_c5fa4ad33d.jpg


첫날 튜토리얼에서도 가상화(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를 들었습니다.


197/505480123_5b320612f6_m.jpg


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


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


- deepblue

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

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


198/503593131_76e69e8c41_m.jpg


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


레일스의 현재

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


189/503984317_e597952be4_m.jpg


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


레일스를 지원하고 나선 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가 발표되었고, 리소스 클라이언트인 액티브리소스는 정식 젬으로 배포되었습니다.


228/503574487_9afcbffadf_m.jpg


오늘 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(데이터)를 가진 객체입니다.


222/504191513_5ac5c5330f_m.jpg


그러면서 실제 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!


202/503608760_fabb1314fe_m.jpg


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


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


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


190/504096000_40e4e00b75_m.jpg


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


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


201/504177168_be859d5ed5_m.jpg


- deepblue

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

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


197/502317503_c69682f124_m.jpg

211/502554463_6cda211c57_m.jpg

210/502299162_f2911972a5_m.jpg


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


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


212/502564312_969f75a7b8_m.jpg


오늘은 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, 공간, 커넥터, 케이블, 라우팅, 스토리지 등의 문제를 시스템 관리자 입장에서 보니 새롭더군요. 지금까지는 너무 순진하게 일부만을 보지 않았나 싶습니다. 이런 다양한 요소들 중 정말 병목을 잘 감지해내는 능력이 필요하겠네요.


192/503028110_536d8a50ec.jpg


어쨌건 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보다 많은 부분 성능이 나아졌습니다.


230/503028090_6d9b73ac16.jpg



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

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


230/503065935_8b209e3a5e.jpg


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


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


229/503065971_19717cdd5f.jpg


대부분 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)도 공개했는데 괜찮은 아이디어 같더군요. 숙소로 돌아오는 길에 다시 생각해보니 방법은 당연히 있는 것이었고, 고민 한 큰술과 실행 두 큰술이 필요한 문제였더군요.


201/503066001_d9bbc7a7e6.jpg


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


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


- deepblue

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

지난 토요일 오픈마루 회의실에서 루비 세미나 2회가 있었습니다.

1회에는 몇 분만 발표하고, 나머지 분들은 그냥 돌아가셔서 아쉬웠다는 의견도 있었고, 다양한 목소리를 들어보고 싶기도 해서 '루비 코드를 말한다'라는 부제를 붙여서 진행되었습니다.
루비 코드 조각을 발표하면서 루비에 대한 생각을 나눠보자는 것이었는데, 5분이라는 시간이 참 쉽지가 않더군요.
너무 열정적으로 또, 재미있는 이야기들을 해주셔서 중간에 절대로 끊거나 할 수 없었습니다. 덕분에 또, 시간을 넘겨서 늦게까지 해버렸네요.
그래도 다들 저처럼 뿌듯한 마음을 안고 돌아가신 것 같아 무척 기뻤습니다.

먼저, 제가 지난 모임 이후 일어난 일들을 잠깐 소개했습니다.

정리하면서 보니 2개월이라는 짧은 시간 동안 루비 커뮤니티는 아주 바쁘게 움직였더군요.
2006년 올해의 언어로 선정된 루비, YARV가 병합된 루비 개발 브랜치, REST를 들고 나타난 레일스 1.2.1, 인터넷 서점에 루비 관련 분류가 생긴 일, 레일스로 개발된 국내 사이트 오픈 등, 연초부터 좋은 일들이 많으니, 올 한해도 루비는 인기를 떨칠 것 같습니다.

그 다음, 자연스레 화두가 레일스 1.2로 이어졌습니다.

정목님이 1.2의 변화를 아주 잘 요약해줘서, 많은 도움이 되었습니다.
레일스 1.2에서 가장 주목할 부분은 REST와 MultiByte 지원입니다. 특히 REST 지원 부분은 ias 플랫폼 오프너님과 농담 반 진담 반으로 '서버에는 레일스와 REST API만 있으면 돼'라고 말할 정도로 매력적입니다.
올해에는 국내에도 REST기반 오픈 API가 많이 생겼으면 좋겠습니다. 물론 레일스로 만든 것이면 더 좋겠지요 :)

요즘 2번째 사이트를 만드시느라 바쁘시다는 김동규님이 한 달간 힘들게 만드신 사이트 'Wellee'를 소개해줬습니다.
특히나 눈물겨운 성능 향상 경험은 많은 분들의 공감을 샀습니다. 특히나 국내에서 듣기 힘든, 생생한 이야기를 들을 수 있어서 많은 도움이 되었습니다.
열정 넘치는 일인기업 이노크레이지의 건승을 빕니다.

더불어 오픈마루에서 새로 문을 연 myID.net에 대한 소개도 잠깐 했습니다. 제가 자세히 알지 못해 동규님처럼 재미있는 이야기를 못해드려서 좀 아쉽네요.
다음에 기회가 되면 직접 개발에 참여하신 swizard님의 생생한 개발 경험을 들어보지요!

여기까지는 준비운동에 불과합니다.
이후 세시간여 동안 정말 짧은 시간에 많은 것을 듣고 배웠습니다.

다양한 생각이 모이니, 정말 즐겁더군요. 어느 것 하나 놓치고 싶지 않은 멋진 발표들이었습니다. 지인님의 컨티뉴에이션을 이용한 제너레이터 설명, 정목님의 레일스 코드 리팩터링, ikspres님의 호기심 넘치는 실험들, 갑연님의 델파이를 이용한 루비 깜짝 마술, 우경님의 암호 해독, 정호님의 웹브릭 서블릿 개발 경험, yesjun님의 키워드 형식인수에 대한 집착^^, JasonPA님의 가비지 컬렉션에 대한 심층 연구, dantekim님의 Forwardable 설명, codian님의 루비에는 코드 컨벤션이 없다 충격 발언, myleo님의 ORM 사용 고민, 대산님의 싱글튼 클래스 열강, 석준님의 ActionController 해부, 동규님의 Delegation을 활용한 OpenStruct,

우와.. 다시 열거해봐도 한자리에서 모든 이야기를 다 했다고 하기 힘들만큼 다양한 주제들이네요. 다음 모임까지 하나하나 곱씹어봐야겠습니다.
좋은 발표 감사합니다. 저는 heckle을 이용한 루비 새디즘^^을 이야기했습니다. 발표 준비를 하면서도 많이 알게 되었네요.

회의실 밖에서 이번 세미나를 지켜본 라면님의 증언에 따르면 '마치 종교 모임' 같았다고 합니다. 박수치고, 좋아하고 하는 모습이 말이죠.
루비교 하나 만들까요?
하하! 3회 모임에는 더 많은 분들을 만날 수 있었으면 좋겠습니다.
정말 즐거웠습니다. 아, 내내 촬영을 하시느라 수고해주신 송우일님 감사합니다!

- deepblue


TAG 루비
지난 토요일(11/25), 오픈마루에서 첫 번째 루비 세미나가 열렸습니다. 25분 정도의 루비 개발자들이 모여서 여러 이야기를 나눈 즐거운 자리였습니다. 원래 3시간 정도 예상했는데,4시간이 훌쩍 지나고, 저녁식사까지 함께 마치고서야 행사를 끝낼 수 있었습니다. 열기도 무척이나 뜨거웠죠. 왜 진작 이런 모임이 없었나 할 정도였습니다. 오픈마루에서는 저와 이창신님 신상호님이 참석해서 많이 듣고 배우고 왔습니다.



오고 간 이야기의 주제는 3가지 정도로 요약할 수 있을 것 같습니다.

첫째, 자바입니다. 루비세미나에 웬 자바냐 하겠지만, 많은 분들이 현업에서 자바를 하시면서, 틈틈이 루비를 도입하려고 준비중인 것이 사실입니다.요즘에는 여러 가지 방안이 나와서 기존 베이스가 자바인 곳에서도 얼마든지 루비를 도입할 방법이 생기고 있지요. 그 중 가장 주목받고 있는 jruby에 대해 이창신님께서 발표해 주셨습니다. 자바 개발자로서, 루비를 처음 접했을 때, 겪게 되었던 당황스러운 경험들을 이야기해주셔서 상당한 호응이 있었습니다. 개인적으로는 jruby 프로젝트의 필요성과 가능성, 그리고 그 중요성을 느낄 수 있었습니다.

이어서 seradin님이 Groovy/Grails를 현업에서 사용했던 경험을 공유해 주셨습니다. 그루비는 이름에서도 루비의 냄새가 나지요? ^^  Grails는 레일스 철학을 그루비로 구현한 것입니다. 이 또한 가능성 있는 개발환경입니다. 차분하게 왜 그루비를 도입하게되었는지, 그리고 그루비/그레일스 도입의 문제점까지 이야기를 풀어주셔서 재미있었습니다.

이야기 도중, 주말에만 참회의 기분으로 루비를 하신다는 분도 계셨습니다. 아직 루비를 현업에 도입하기에는 장벽이 있다는 이야기도 있었고요. 사실입니다만, 루비가 강점을 보일 환경도 얼마든지 있지 않겠습니까? 우리 그냥 루비하게 해주세요~ 네?? ^^;;;

두 번째 주제는 루비입니다. 루비를 루비답게, 제 표현으로 루비스럽게 쓰는 것은 모든 루비스트의 고민이겠지요. 먼저, 대산님의 메타프로그래밍 발표가 있었습니다. 정의부터 필요성, 그리고 루비의 장점을 잘 보여주어서 눈도 귀도 즐거웠습니다. 특히나 미션임파서블 예제는 어찌나 재미있던지요. 저는 두 번째 보는 것이었는데, 또 봐도 재미있더군요. 센스 있는 예제였습니다.

그 뒤에는 제가 루비에 대해 최근에 갖게 된 생각을 말씀 드렸습니다. 분명 루비는 다른 언어와 다른데, 어떻게 쓰는 것이 가장 루비스러운 것인가 하는 물음이었습니다. 답은 준비하지못했지만, 이야기를 나누는 과정만으로도 충분히 즐거웠던 것 같습니다. 더 수련을 거치면 도를 깨우칠 수 있을까요? ^^ 그 다음 제가 생각하는 루비스러운 코드로 마이크로포맷 생성기를 루비로 만드는 예제 코드에 대해 이야기했습니다.

nohmad님은 준비하신 자료가 깨져버리는 사고(?)가 있었지만, 이마저도 쇼의 일부가 아닐까 할 정도로 정말 유창하게 루비와 유니코드에 대해 이야기하셨습니다. 루비 커뮤니티(특히나 일본)에서 왜 유니코드를 꺼리는지, 현재 루비가 가진 솔루션은 무엇인지, 그리고 앞으로는 어떻게 될지에 대해서 너무 잘 이해할 수 있는 자리였습니다. 유니코드를 루비의 단점으로 꼽는 분들도 많은데, nohmad님 같은분들이 있으니 이런 편견(?)은 금방 깨지리라 확신합니다.

마지막으로, 이 이야기를 빼놓을 수 없겠죠. 바로 루비 온 레일스입니다. 사실 많은 분들이 레일스 덕분에 루비를 접하고 또 도입하신다고 할 정도로 요즘 레일스의 인기는 엄청납니다. 좋은 현상입니다 ^^; 조정목님이 전날 밤을 새워 준비해오신 Capistrano 발표는 정말 정성이 철철~ 넘치더군요. 꼼꼼히 설명을 해주셔서, 자리에 있던 모든 분이 순식간에 Capistrano 전문가가 되어버렸습니다. 배포를 미루지 맙시다 :)

그 다음 codian님이 현재 준비 중이신 프로젝트를 이야기해 주셨습니다. 상당히 흥미로운 모습으로 루비를 사용하시더군요. 인상적이었습니다. 시간이 좀 늦어져서 많은 이야기는 나누지못했지만, 완성된다면 정말 재미있는 제품이 될 거라 확신합니다. 그리고 현재 가지고 계신 이슈들은 잘 해쳐나가시라 믿습니다.

끝으로 정현님의 UJS4Rails 발표를 빼놓을 수 없겠지요. 이 분 어찌나 발표를 재미있게 잘 해주시던지요. '나대지 않는 자바스크립트'라니, 정말 유머 있으십니다. 레일스의 도우미 함수들에 가려 보이지 않던, 부조리(?)를 잘 고발해주셨습니다. 레일스 커뮤니티에서도 자바스크립트를 잘 쓰기위한 노력이 이런 저런 모습으로 보여지고 있으니, 앞으로 나아지겠지요. 뭐, 지금도 잘 하고 있기도 하고요.

그날 오간 이야기를 다시 떠올려보니, 유익했다는 생각에 마음이 뿌듯해집니다. 프로처럼 멋진 촬영은 하지 못했지만, 그래도 캠코더에 담아왔으니, 곧 동영상을 공개하도록 하겠습니다. 물론 모든 면이 완벽하지는 못했지만, 이런 모습은 시간이 갈수록 나아지겠죠. 이날 얻었던 가장 큰 성과는 개발자 분들의 현재 고민과 사는 이야기, 그들의 열정을 들을 수 있었다는 것입니다. 어떤 분은 이런것이 루비의 장점이라고도 했지요. 열정과 유머가 넘치시는 한국의 루비 개발자분들 화이팅입니다!

-    deepblue