Blog

사용자 삽입 이미지

Ajax World Expo

AJAXWorld Conference & Expo 2007 West

AJAXWorld 컨퍼런스를 가다

사용자 삽입 이미지
한국에서는 추석이 한창인 가운데 스프링노트 팀의 두 사람(강규영, 신기배)은 추석 연휴도 마다 않고 AJAX 컨퍼런스를 위해 캘리포니아 산타클라라로 날아왔습니다. 가서 밥이나 먹고 다닐 수 있을까, 호텔까지 찾아갈 수나 있을까.. 하는 많은 사람들의 우려 속에서 24일부터 26일(미국 서부 시간 기준, 23일 boot camp제외)까지 3일간의 소식을 전해드리도록 하겠습니다 =)
이 행사의 홈페이지입니다.
http://www.ajaxworld.com/

엔터프라이즈 매시업 #1

오전 7시 30분 - Oracle의 첫 키노트

일찍도 시작하네요 ^^; 아침 7시부터 등록이 시작되었습니다. 태어나서 외국인들이 이렇게 많이 모여있는걸 본 건 처음입니다. 웹에 있어서 기술적인 메인 스트림 중 하나인 AJAX의 인기를 실감할 수 있었습니다. 다양한 나라, 다양한 회사에서 이 행사를 위해 참석하였습니다.

이번 컨퍼런스는 10개의 트랙, 총 140여개의 발표와 BOF로 구성되어 있습니다. 따라서 AJAX 응용 기술, 개발 환경, 프레임웍, 테스트 환경, 표준화, 보안, 매시업, RIA 등 다양한 주제들이 많았는데 컨퍼런스 서두의 두 세션은 웹으로 옮겨 오고 있는 엔터프라이즈 솔루션에 대한 이야기 입니다 =)

사용자 삽입 이미지
오라클은 엔터프라이즈 솔루션들이 가져야 할 여러가지 특성을 강조했습니다.

  1. 협업
  2. 정보의 공유
  3. 권한에 대한 제한
  4. Data is king! - Users don’t own it
  5. 비즈니스가 컨텐츠를 생산하고 사용자가 그것을 확대하라~

4번 항목은 일반적인 인터넷 서비스라면 좀 아리송? 하지만 기업내에서 사용되는 솔루션이라면 그럭저럭(?) 이해가 됩니다 ^^; 어쨌든~ 그리고 가져야 할 여러가지 기능의 가이드 라인을 제시했습니다.

  1. 통합 검색
  2. 개인 공간, 그룹 공간
  3. 커뮤니케이션과 문서 관리(위키, 블로그, RSS)
  4. 메일/이벤트/캘린더

오라클은 콤포넌트 화 된 이런 기능들을 GUI 개발도구에서 드래그&드롭만으로 엔터프라이즈 RIA 솔루션을 만드는 것을 시연했습니다. 각 콤포넌트들을 엮어서(매시업) 웹기반의 어플리케이션을 만들어 냅니다.

엔터프라이즈 매시업 #2

Let My People Mash!

사용자 삽입 이미지
JackBe는 재치있는 두번째 세션으로 그 뒤를 이었습니다.
“Let My People Mash!” 라는 슬로건으로 세션을 시작하고 중간에 영화 식스 센스의 “I see dead people” 대사를 “I see mashups...”으로 패러디 한 이 회사는 누구나 쉽게 매시업을 할 수 있게 하는 서비스를 선보였습니다.

언듯 보면 야후의 pipes와 유사한 인터페이스와 기능을 가지고 있습니다. 하지만 내용은 많이 다릅니다 =)

사용자 삽입 이미지
JackBe의 “Presto Wires”는 OpenAPI 뿐 아니라 웹서비스를 위해 필요한 기본적인 기능들(Login, Search 등)까지 모듈로 만들어서 다른 모듈들과 이어 붙일 수 있게 합니다. 이른바 Internal Mashup이랄까요?

위의 사진은 Wires를 시연하는 장면인데 이미 꽤 많은 모듈들이 준비되어 있고 안정적으로 돌아가는 것을 보여주었습니다. 복수의 RSS를 엮고 자동화 된 또는 검색어를 기반으로 한 필터를 통해 원하는 데이터를 만들어 내는 내용이었습니다. 그동안 매시업이라면 대부분 적잖은 기반 지식을 가지고 있어야 가능했습니다. JackBe가 "Let My People Mash!"라는 슬로건에 걸맞는 솔루션을 완성시켜서 줬으면 하는 바램입니다 =)

아! 위의 화면은 웹브라우저(FireFox)에서 돌아가는 화면입니다 =) 보면서 아.. 누군가 또 코피 쏟으며 엄청난 노가다를 했구나 싶었습니다 -.-

JackBe의 홈페이지 주소는 http://www.jackbe.com/ 입니다. 위의 Wires라는 솔루션은 아직 공개되지 않은 개발 버전인듯 합니다.

RIA와 AJAX, Enterprise

RIA(Rich Internet Application)를 구현하는 방법에는 여러가지가 있습니다. Flash, Silverlight기반의 기술도 있지만 JavaScript 기반의 RIA와 AJAX는 뗄래야 뗄 수 없는 관계입니다.

이번 컨퍼런스의 세션들에서는 특히나 for Enterprise라는 수식어가 많았습니다. 기존의 서버/클라이언트 기반의 엔터프라이즈 어플리케이션들이 웹이라는 새로운 환경으로 옮겨오고 있고 거기에 대한 많은 솔루션들이 쏟아져 나오고 있습니다 =)

AJAX로 구현되는 솔루션들은 개발하기도 힘들고 테스트 하기도 어렵습니다. 그동안의 JavaScript/AJAX관련 기술들의 행보가 Cross-Browser 지원에서 서버 기술과의 통합으로 바뀌었다면 이제는 개발 도구와 테스팅 환경과의 통합으로 발전해 나가고 있는 듯 합니다.
오라클과 JackBe가 시연한 내용이 완전히 새로운 것은 아니지만 이런 개발 도구가 계속 나와주고 발전하는 것은 환영할 만한 일입니다 =)

속이 니글니글~한 점심을 주지만 어쨌든 먹었으니 밥심으로 계속 해보겠습니다~ ^^; 즐거운 한가위 되세요~

지난 주에 오픈마루 사무실에 일본 시마에 대학 경제학 교수님이자 오픈소스를 연구하시는 노다 테츠오 (野田哲夫, 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^/

안녕하세요. jumagun입니다.

동영상과 사진 용량의 압박으로 일주일 동안 헤매다가 결국 그 큰 용량의 동영상을 업로드할 수 있는 곳을 찾지 못했네요. ㅠㅠ google video로 업로드 하다가 여러번 브라우저 죽고요. 용량 엄청 큰 동영상을 올릴 수 있는 방법 제보해 주세요.

그 사이 이미 많은 분들이 후기를 올려주셨네요.


장마철이라 오전부터 비가 오길래 상당수 못 오실거라 생각했는데, 거의 모든 분이 참석하시고 또 당일 참석하신 분들까지 정원을 초과해서 아주 북적거리는 첫번째 DevDay였습니다.

참석하지 못하신 분들을 위해 발표 자료 동영상은 계속 작업을 해서 (언젠가는.. ㅠㅠ) 공개해 드리도록 하겠습니다.

사진으로나마 DevDay의 열기를 전할까 합니다.

당일 행사장 분위기는 이랬답니다. 더 많은 사진은 이 곳에서 보실 수 있습니다.

사용자 삽입 이미지
사용자 삽입 이미지

시작 10분전

사용자 삽입 이미지

발표자들 대기중 (맥북으로 재활치료 받는 정신과 환자들 같은 이 분위기는...)

사용자 삽입 이미지

자리가 부족하니 오픈마루 소속은 서서 들으라는 jumagun의 압박이 있었습니다.

사용자 삽입 이미지

전날밤 deepblue님의 급개발로 많이 추가된 스프링노트 API 소개

사용자 삽입 이미지

스프링노트 API 소개 중

사용자 삽입 이미지

SilverLight 개념 탑재를 위해 특별 게스트로 참석해 주신 황리건님

사용자 삽입 이미지

위자드 미투데이 조

사용자 삽입 이미지

스프링노트에서 동영상, 사진앨범 기 조

사용자 삽입 이미지

자바 튜토리얼

사용자 삽입 이미지

황리건님은 미투데이 조에서

사용자 삽입 이미지

미투데이 조

사용자 삽입 이미지

위자드

사용자 삽입 이미지

열공

사용자 삽입 이미지

이창신님네

사용자 삽입 이미지

자바 튜토리얼 멘토 손권남님

사용자 삽입 이미지

자바 튜토리얼 여자 개발자 대거 참가

사용자 삽입 이미지

루비 튜토리얼

사용자 삽입 이미지

결과 발표의 시간.. 북적

사용자 삽입 이미지

저녁 식사 중

사용자 삽입 이미지

저녁 식사 중.. 아 예쁘다.

사용자 삽입 이미지

스프링노트 티셔츠 이렇게 생겼어요. - 모델은 여자 아니고 남자임.

사용자 삽입 이미지

집에 가기 아쉬워요..

사용자 삽입 이미지

안녕 여러분.. 다음에 또 만나요.


참석해 주신 모든 분들, 멘토, 발표자 분들께 감사드립니다.

다음 2nd DevDay는 더 많은 분들을 모시고 더 즐거운 시간이 될 수 있도록 준비하겠습니다.

감사합니다~

---- jumagun

조금 늦었지만 지난 6월 21일 웹 어플리케이션 컨퍼런스에서 시연(하려고 했으나 네트웍 사정으로 보여드리지 못)했던, Springnote For Developers 쇼케이스의 핵심 장면을 스크린 캐스트로 옮겨보았습니다.


* Sound On!! 이창신님과 강규영님의 만담이 함께 합니다.
제작자들: 스크린캐스트는 제작도 재밌지만, 녹화를 거듭할수록 조금씩 긴장감이 감도는 맛도 있습니다. (다행이 이번 스크린캐스트는 2회 녹화로 끝났습니다만)

스프링노트의 무한한 여백에 당신의 아이디어와 코드를 담아 보세요!

레일스 컨퍼런스에서 돌아온 지 일주일 정도 지났습니다. 팀에 복귀해서 가장 먼저 한 일은 스프링노트의 배포(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

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

안녕하세요. 오픈마루 스튜디오 황장호 입니다. (rath 라고도 합니다. ^^)

오늘 오전에 월간 w.e.b.에서 주관하는 매쉬업 토론에 다녀왔습니다. 저는 순수히 매쉬업을 즐기는 개발자로서 참가했는데요,

미리 준비된 토론의 주제가 다소 무겁게 느껴져서 조금은 부담스러웠었는데, NHN에서 아늑한 토론방도 제공해주시고 참석하신 패널분들이 좋은 의견을 많이 공유해주셔서 평소의 저답지 않게 부담없이 매쉬업에 대해 이야기해볼 수 있는 자리였습니다.


잠깐 광고

부끄럽지만 제가 최근에 만든 매쉬업(?)들을 소개합니다.


무엇보다 패널로 참석해주신 두 분(야후코리아 정진호 과장님, NHN 신수완 과장님)이 국내 대형 포털사이트 분들이시고, 저에게는 매쉬업 꺼리를 제공해줄 수 있는 곳에 계신 분들이었기 때문에 토론에 대한 애착이 깊어져서 가끔 토론의 주제에 벗어나는 이야기도 한 것 같네요. 그래도 적절히 응수해주신 패널분들께 다시 한 번 감사의 말씀을 드리고 싶네요.


자세한 토론 내용은 w.e.b. 6월호를 기대해 보구요, 패널로 참석한 저의 간단 후기를 말씀드리자면, 사실 참석하기 전에는 많은 걱정을 했습니다. 매쉬업을 즐기는 개발자 1人으로서 스프링노트나 미투데이는 API 공개 요청에 적절히 대응해주는 반면 왜 국내 포털 사이트의 API 들은 왜 Hackability 가 떨어지는가에 대한 것이였는데, 단순히 UV, PV가 떨어지는 것을 걱정하는 게 아닐까 하는 걱정이 있었지만 의외로 포털사이트 분들도 긍정적인 고민을 많이 하고 계셨고 Service Provider 로서, 현실에서 꼭 넘어야 할 벽들에 대한 진솔한 이야기를 들어볼 수 있는 유익한 자리였습니다.


팀 오라일리가 쓴 What is Web 2.0 페이퍼의 'Data is the Next Intel Inside' 를 다시 한번 생각해볼 수 기회이기도 했는데요. 매쉬업 개발자들로부터 OpenAPI를 제공해달라는 일종의 '압박'을 받는 업체들 중에는 어떤 인터페이스로 OpenAPI를 개봉해야하는지 고민하는 일도 있겠지만, 제공할 원본 Data 가 누구의 것이냐에 따라 공개를 할 수 없는 경우도 있다는 사실이 흥미로웠습니다. 전 그저 징징대는 OpenAPI Consumer 일 뿐이였나봅니다. 하하 -_-;


이번 토론을 다녀와서 국내 포털에서도 이러한 요구에 부응해 적극적으로 고민하고 있다는 사실에 기쁨을 감출 수 없었고, 개인적으로는 매번 원하는 형태로 서비스를 변형시킬 수 없어서, API가 제공되지 않는 서비스(웹 서비스, Standalone 프로그램 등)를 해킹해서 억지로 새로운 가치를 창출하는 매니악한 노력을 더이상하지 않고도 자신만의 아름다운 가치를 창조할 수 있는 세상이 도래하고 있다는 사실이 가장 즐거웠습니다.


마지막으로 토론 중 야후코리아 정진호 과장님의 "매쉬업 개발을 활성화하기 위해서는 비 IT 전문가들도 쉽게 매쉬업(혹은 리믹스) 할 수 있도록 진입장벽을 낮추어야 한다" 는 말이 기억에 남습니다. 참신한 아이디어를 가진 기획자가 REST가 뭔지 XML이 뭔지 JSON이 뭔지 공부해야하는 것은 너무 가혹한 것 같았고, 그로 인해 많은 참신한 TODO들이 저처럼 프로그래밍이 가능한 몇몇 사람들에게만 몰리지 않기 위해 매쉬업을 즐길 수 있는 인구가 많아 졌으면 합니다. 그런 면에서 진입 장벽이 낮춰지는 것에 대찬성입니다. 매쉬업이 가능한 개발자들의 삶에도 여유가 필요합니다. ^^ 누군가가 쉬운 매쉬업 개발을 위한 IDE를 만들면 대박날 것 같네요!


오늘 정말 유익한 시간이었고, 앞으로도 이런 자리가 많아졌으면 좋겠습니다. (라이프팟 개발자이신 신기배님도 자리에 참석하고 싶으셨는데 참석하지 못해 못내 아쉬워하고 계십니다.) 자리를 마련해 주신 월간 w.e.b.에 감사의 말씀 전합니다.


---- rath

 "a 72-hour conversation"이라는 부제로 진행된 MIX07의 마지막 날에는 특별한 keynote 없이 session별 발표 위주로 진행되었습니다.
 이중에서 저는 amazon의 Web service, RSS를 활용한 수익화 등에 대한 내용을 들었습니다.

 Jeff Barr라는 유명한 Evangelist가 진행한 Amzon에 대한 내용은 예시와 함께 비용절감효과나 실제 운영비용에 대한 구체적인 수치가 제시되어 의사결정자들에게 상당히 의미있는 것이었을 것 같습니다.  

 발표내용 중 제가 의미있게 들었던 것들 위주로 요약을 해보면...
 1. 아이디어를 실제의 제품/서비스로 만들기 위해서는
  정말 많은 고려사항과 비용이 필요하며
  특히, 급속한/예측불가능한 성장을 대비하는 것은 (include seasonal spike) 훨씬 더 어렵다는 것을 강조했습니다.

사용자 삽입 이미지
 
 2. 실제 차별화된 무엇인가를 위해 투입할 수 있는 자원은 불과 30%,
 나머지 70%(on undifferentiated "heavy lifting")는 차별화와는 다소 직접적인 관계가 없지만, 꼭 투입되야하는 곳에 집어넣을 수 밖에 없는 70/30 switch를 기존의 문제로 정의하였습니다.
사용자 삽입 이미지

 3. 이러한 기존 문제를 해결하는 새로운 대안으로서 "Amazon Web Services"를 제시하였습니다.
사용자 삽입 이미지

 4. 특히 아래의 사항들을 고려하지 않을 수 없는 의사결정자들에게 '효율성'과 '비용절감효과', '역량집중 가능성', '손쉬운 적용' 등을 강조하면서 구체적인 수치와 함께 제시해주었습니다.
   1) Faster time to market
   2) Ability to scale on demand
   3) Focus on product & core competencies
   4) More capital available to drive business
   5) Faster pace of innovation
   6) Happy investors

 5. Smugmug, GigaVox, CastingWords 등의 사례에서, 각 서비스들이 당면했던 문제점들이 무엇이었고 그 문제에 대한 해결책으로 Amazon의 Web Service들이 얼마나 빠르게 도입되었는지, 도입 후 얼마나 큰 비용절감효과나 time to market 등에서 효과를 거두었는지 등을 구체적인 수치와 함께 설명을 해주었습니다. 예전에도 Amazon의 S3의 단가를 알고는 있었습니다만, 실제 수백 TB급의 저장공간이 필요한 서비스의 예시를 보면서 현실적인 수치들을 듣
게되니...그 느낌이 사뭇 달랐습니다.

 아침의 첫 session을 듣고 난 뒤에, RSS 등을 포함해서 4개 정도를 더 들었는데요...사실 그리 인상적인 내용은 없었던 것 같아서...잠깐씩 들러보았던 Sandbox에서 시간을 좀 보냈습니다.
 
사용자 삽입 이미지사용자 삽입 이미지

 잘 아시다시피, 이번 행사는 대화와 참여를 중요하게 생각하고 있던 것만큼...
  위의 사진에서 보시는 것처럼,
 [Free Speech] 장소에서 누구나 일정표에 자신의 session을 추가하여 발표를 할 수 있으며 (왼쪽 사진)
 Expression Studio 등 각 PKG 별로 직접 사용해볼 수 있는 공간을 제공하고 있었습니다. (오른쪽 사진)

 이런 sandbox 이외에도 행사장 곳곳에서 몇몇이 무리를 지어 열띤 토론을 하는 사람들의 모습을 발견하는 것은 너무나 흔한 모습이었습니다.
 지난 번에 갔었던 Web 2.0 Summit처럼 토론이나 의사교환에 익숙한 이들의 conference 모습이라 당연하게 볼 수도 있겠습니다만...발표자와 청중 사이의 거리가 너무 멀게 느껴지는 우리의 conference에서도 점진적인 개선을 해볼 만한 부분이 아닐까라는 생각이 듭니다.
 (처음 만나는 사람과 몇 분씩 이야기를 스스럼없이 할 수 있는 분위기를 '만들어야 하는' 것이 쉽지는 않은 것 같습니다만...소규모의 세미나나 컨퍼런스들의 후기들을 보면...참여/대화형 conference가 국내에서도 보편화되는 것이 먼 미래의 일은 아닐 것 같습니다. ^^)

 이번 conference에 참석하신 다른 분들의 글에서도 이미 보신 분들도 있겠습니다만...(특히 김국현 님의 글이 아주 생생합니다. ^^)
 "a 72-hour conversation"을 내걸은 이번 행사에서 저 역시 다른 분들과 상당히 많은 대화를 나누었습니다.
 행사 기간 내내 '시차적응' 때문에 힘들었다기 보다는 '수면부족'으로 힘들 정도로, 늦은 밤까지 이어진 즐거운 대화에서 conference의 session에서 얻을 수 있는 것보다 더 귀중한 내용들을 얻을 수 있었던 것 같습니다.
 서로 주고 받은 대화와 정보의 내용도 참 좋았습니다만, 저 개인적으로는 다른 업체에서 한국의 '웹'을 발전시키기 위해 열정을 갖고 에너지를 발산하는 분들과 며칠을 함께 이야기할 수 있었던 것이 가장 좋았던 것 같습니다. (각 회사의 입장에 대한 고수보다는 전체적인 개선과 발전을 위해 상당히 개방적인 대화가 진행되었기에 서로의 입장을 이해하면서 새로운 방법을 찾는 것에도 디딤돌이 될 만한 이야기들도 꽤 나왔던 것 같습니다.^^)
 
  이 분들과 다시 MS MIX07에서 얻은 것들을 정리하고 논의하는 자리를 MS Korea에서 한 번 마련해보시겠다고 하셨는데...워낙 바쁜 분들이시라서 잘 될지는 모르겠습니다만, 다들 참석하셔서 뵐 수 있었으면 좋겠습니다.

 마지막으로...이번 MIX07을 보면서 MS Korea 분들께 이런 부탁을 개인적으로 드려보고 싶습니다.
 단순한 본사의 대변인이나 agent가 아니라,
 MS를 기반으로
   한국의 web이 (국내/외로) 발전할 수 있도록
   새로운 플랫폼으로 만들고 이끌어주는
   진정한 Evagelist들이 되어주시길 기원합니다. ^^


- ocean



 * 그리고 이번에 함께 가신 MS Korea 분들 모두에게 진심으로 감사드립니다.
  유재구 부장님, 김국현 부장님, 김대우 과장님, 황리건 과장님. 네 분 덕분에 행사 기간 내내 다른 걱정없이 열심히 참여할 수 있었습니다. 정말 감사합니다. ^^

TAG mix07