Agile2robust

ImageJ는 생물학 관련 이미지 처리를 위해 가장 많이 사용되는 프로그램일 것이다. 속도가 (자바로 개발된 프로그램이라기에는) 믿을 수 없을 정도로 빠르고, 다양한 플러그인을 가지고 있으며, 새로운 플러그인을 개발하기도 매우 쉽다는 장점을 가지고 있다.

Fiji는 ImageJ를 여러 종류의 플러그인과 함께 배포하는 패키지이다. 홈페이지에서는 ImageJ : Fiji = Linux : Ubuntu 정도로 설명하고 있다. 내게 가장 반가운 것은, Fiji가 JRuby scripting 환경을 지원하고 있다는 점 (물론 ImageJ 설치 후 직접 만들어도 되지만…). JRuby 말고도 Jython, Javascript는 물론이고 Clojure까지 지원을 한다. JVM에서 돌아가는 스크립팅 언어는 뭐든 쓸 수 있다고 생각하면 편할 듯.

JRuby를 이용해 간단한 배치 작업을 하고 있다. 약 2백만개 정도의 파일을 변경한 후 저장하는 일. 잊지 말아야 할 것은, Fiji가 활성화된 경우에는 속도가 매우 빠르지만, background로 되어 있는 경우에는 실행 속도가 매우 많이 (최소 서너배) 느려진다. 2백만개의 파일을 처리해야 하는 배치 작업이라면, 이런 정도의 속도 차이는 치명적! 따라서, 배치작업을 할 때는 Fiji를 foreground에 놓고, 다른 작업을 하지 않는 것이 좋다.

최근에 git을 사용해서 소스 버전 관리를 하고 있다.

처음에 무식하게 모든 파일을 밀어넣은 후에 나중에서야 내가 너무 많은 binary 파일들을 밀어넣었다는 사실을 깨닫게 되었다. 온갖 jpg, gif, png 거기다가 pdf 파일까지. 이런 파일들의 이력 변경을 하고 싶지는 않기 때문에, .gitignore 파일을 생성한 후에 그 안에 무시할 파일의 목록을 넣어줬다. 그렇지만, 이미 인덱스에 들어간 파일은 어떻게 해야 할까?

간단하게 다음과 같이 하면 된다. a.pdf 파일을 인덱스에서만 제거하고 싶다면,

git update-index --assume-unchanged a.pdf

깔끔하게 처리 완료!

InCHI 1.03 버전이 발표되었다.

말할 것도 없이 InCHI는 이제 Chemical Identifier의 사실상 표준이다. 대부분의 small molecular database에서 InCHI를 사용하고 있으며, 최근에는 InCHIKey의 사용도 크게 증가하고 있는 추세이다.

이런 프로그램을 업그레이드하는 것은 절대 쉬운 일이 아니다. 예를 들어, 3천만개가 넘는 PubChem의 모든 화합물들이 1.02 버전을 사용한 InCHI code를 가지고 있는데, 만약 새로운 버전에서 모든 코드를 다 바꾸어야 한다면 얼마나 큰 문제를 야기할 것인지는 너무나 분명하기 때문이다. 이런 문제 때문에, InCHI code의 처음은 InCHI=1/과 같이 (이번 버전부터는 Standard InCHI는 InCHI=1S/로 표시된다. S가 없는 것은 Standard가 아니라는 뜻이다. Standard InCHI는 RecMet, FixedH, SUU, SLUUD 옵션을 모두 끈 것을 말한다.) 사용한 InCHI 프로그램의 버전을 명기하도록 되어 있다. 앞으로 1.0에서 2.0으로 넘어가는 큰 변화가 생긴다면 당연히 이런 메커니즘 때문에 문제가 없을 것이다. (그냥 두 종류의 InCHI code를 모두 가지고 있어도 상관 없으므로) 그러나 이번과 같이 minor update의 경우에는 이 메커니즘이 작동하지 않는 것이 문제가 될 수 있다.

InCHI 1.02에서 발견된 버그들이 몇 개가 있는데, 그 중 하나는 InCHIKey 생성과 관련된 것이다. InCHIKey를 생성할 때 SHA256 알고리즘에 의해 InCHI code 문자열을 256bit signature로 변형한 뒤에 이 중에서 가장 중요한 0-36 bit 까지만 유지를 해서 이로부터 문자열을 생성하도록 되어 있다. 그런데, 프로그램의 버그로 인해 (InCHI code 후반부의 키 생성을 위해) 0-36 bit 대신 0-31, 36-39 bit가 사용되었다. 이 버그를 수정한다면, 지금까지 만들어진 모든 InCHIKey는 재생성되어야 하는 것이다. 이 때문에, 개발팀에서는 이 버그를 잡은 경우와 잡지 않은 경우를 모두 이론적인 충돌 가능성과 비교하여 보았다. 결과적으로, 버그를 잡지 않은 경우에도 이론적인 충돌 가능성에 비해 큰 변화가 없었고, 버그를 잡은 경우가 더 낫다고 말할 수도 없기 때문에 이 버그는 그대로 유지되는 것으로 결정이 되었다.

사실 InCHIKey는 정해진 길이의 문자열이기 때문에 이론적으로 서로 다른 화합물이라도 동일한 InCHIKey를 갖게 될 확률이 분명히 존재한다. 특히 stereocenter가 많은 천연물의 경우 서로 다른 diastereomer가 같은 InCHIKey를 가질 가능성이 존재하게 되는데, 잘 알려진 예가 바로 Spongistatin I의 경우이다. 이 문제를 해결하는 가장 좋은 방법은 (당연히) SHA256 hash 문자열을 그대로 사용하는 것이다. 이를 위해 InCHI code의 전반부와 후반부의 hash 문자열을 그대로 출력하는 옵션(-XHash1과 -XHash2)이 추가되었다. InCHIKey의 충돌이 염려되는 경우에는 이 두 개의 해쉬 값을 사용하여 동일성 여부를 검사할 수 있을 것이다.

이런 문제들보다 더욱 subtle한 문제는 바로 standard condition에 대한 문제이다. 특히 tautomer의 문제는 매우 어려운 문제인데, InCHI가 다른 identifier들, 예컨대 SMILES 코드에 비해 진일보한 부분이 바로 이런 tautomeric proton을 제대로 처리할 수 있다는 부분이었다. 그러나 이런 부분이 항상 완벽할 수는 없는 법. 이미 메일링 리스트에 이런 보고가 올라왔다. “Mobile H perception” 옵션을 꺼야 (실제 code generation에서는 -FixedH 옵션을 주어야) 정확한 구조를 표현할 수 있는데, 이렇게 되면 standard InCHI가 아니게 된다는 것이다. 물론 이 문제는 structure to InCHI code 과정의 문제가 아니라 InCHI code to structure 과정의 문제라고 할 수 있기 때문에, 약간은 본질에서 벗어난 것 같기도 하지만, 화합물이 이런 현상을 보이는 것을 반드시 예외적이라고 할 수만은 없는 것도 사실이다.

어쨌든, InCHI 1.03 버전은 출시가 되었고, 앞으로 모든 chemical identifier로 사용되게 될 것이다. InCHI 개발자들이 만든 Release note 문서를 보면서, 이런 소프트웨어를 개발한다는 것이 얼마나 어려운 일인지, 그리고 균형을 유지하는 것이 얼마나 중요한 일인지를 다시 한 번 깨닫게 된다.

QSAR-ML이라는 놈이 발표되었다. QSAR에 사용되는 모든 데이터와 descriptor들을 정의된 XML로 표현하는 표준 포맷이다. 이런 방식을 사용함으로서, QSAR 연구가 사람 모든 사람들에게 reproducible하게 만드는 것이 가장 중요한 가치라고 할 수 있겠다.

사실 QSAR 연구 논문을 읽고 나서 그 연구를 동일하게 재현하려고 할 때, 필요한 모든 소프트웨어를 가지고 있다고 해도 동일한 결과를 얻는 것이 거의 불가능하다는 사실은 잘 알려져 있다. 여러 가지 이유가 있겠지만, 2D descriptor만 사용한다고 했을 때는 알고리즘 상에 randomness가 포함되어 있지 않다면, 근본적으로는 이렇게 되어서는 안되는 일이다. 그리고 randomness가 들어가는 경우라고 해도 random seed 값을 주면 동일한 결과를 얻을 수 있어야 한다.

이외에 동일한 결과를 얻을 수 없는 이유는 사용하는 descriptor가 2D가 아니고 분자 구조에 의존적인 경우이다. 이럴 때는, 저자들이 자신들이 사용한 최종 구조를 정확하게 제시하지 않는 다음에는 동일한 결과를 얻을 수 없을 것이다. 물론 대부분의 QSAR 연구가 2D descriptor를 사용하기 때문에 이런 경우는 매우 드문 경우라고 하겠다.

QSAR-ML이라는 파일 포맷이 QSAR 연구에서 표준이 된다면, 그래서 QSAR 연구를 논문으로 출판할 때는 반드시 이 포맷의 데이터를 제출해야 한다면 어떻게 될까. 아니, QSAR-ML 데이터베이스를 만들어서, 여기에 데이터를 넣고 고유의 번호를 넣는 방식은 어떨까?

이렇게 함으로서 연구의 reprocubility를 높일 수 있을 뿐만 아니라, 다양한 방법론의 직접적인 비교를 가능하게 해 주는 중요한 역할을 할 수 있다.

말할 것도 없이, SCI Impact Factor는 논문의 질을 평가하는 가장 편리한 잣대로 사용되고 있다. (한국에서 IF가 본격적으로 중요하게 여겨졌던 것은 아마도 BK21 사업 이후가 아닌가 하는 생각이 든다.)

그러나 이 SCI IF가 과연 논문의 가치를 제대로 평가하고 있는가에 대해서는 끊임없이 의문이 제기되어 왔다. 여기에는 여러 가지 이유들이 있지만, 이보다 더 나은 방법을 제시하고 널리 사용되도록 하는데 큰 어려움이 있는 것도 사실이다.

2009년의 SCI IF가 새로 발표가 되었다고 한다. 여기서 주목해볼만한 점은, 과학 분야에서 New England Journal of Medicine 다음으로 2위를 차지한 잡지가 Acta Crystallography – Section A 였다는 점이다. 이 잡지는 2008년에 비해 SCI IF가 무려 20배 이상 증가한 49.926을 기록했다. 이 것은 이 잡지에 2008년에 실린 “A Short History of SHELX“라는 논문 한 편이 무려 6600번 이상 인용되었기 때문이다. X선 결정 과정에서 SHELX (Bruker AXS의 SHELXTL 포함)을 사용한 경우에는 이 논문을 인용해 달라는 요청이 있었기 때문이라고 한다. 재미있는 사실은, 2009년에 이 논문과 같이 많이 인용되는 논문이 또 나타나지 않는 한, 다음해의 IF는 이전과 비슷한 2 정도에 머무를 것이라는 예상이 나오고 있다는 것이다.

하나의 튀는 데이터가 전체 데이터를 설명하는 평균값을 교란시키는 경우 의미있는 결과를 얻으려면 average가 아닌 median 값을 사용해야 하는 것은 기본적인 사실이다. Average를 사용하고 있는 SCI IF가 비판받고 있는 중요한 이유 중의 하나이다. 만약 IF 계산을 위해 median 값을 사용하고 있다면, 한 두 편의 논문이 한 저널의 IF를 20배 이상 차이나게 만드는 이런 일은 일어나지 않았을 것이다.

또 하나의 논란거리는 철회된 논문에 대한 것이다. 논문을 철회하더라도, 그 논문이 받은 인용 횟수를 원 데이터에서 빼지 않는다는 사실 때문인데, 한국인들에게는 너무나 잘 알려진 황우석 박사의 철회된 논문이 아직 Science지의 IF에 기여하고 있다는 주장도 찾아볼 수 있다.

Thomson Reuter가 SCI IF 계산을 위해 사용하고 있는 데이터 자체도 의심받고 있는 상황임을 감안해 보면 “잘못된 데이터를 사용해서 잘못된 방식으로 계산된 값”인 SCI IF가 널리 사용되고 있는 현실은 뭔가 아쉬움이 남는 상황임에 틀림없다. 이를 대치할만한 좋은 방법이 있는지도 문제이지만, 어떤 방법이 나왔을 때 그것이 과학계를 전반적으로 만족시킬 수 있을지, 그리고 그 여부를 어떻게 판단할 것인지 등의 문제 역시 간단한 것은 아니다.

어찌되었건, SCI IF가 어떤 이유로 어떤 비판을 받고 있는지를 잘 아는 것은, 그 숫자를 어떻게 보고 어떻게 사용해야 하는지에 대해 좀더 성찰을 하도록 도와줄 것이라고 생각한다.

관련 링크 : New impact factors yield surprises

We in the Lab (Ooo Ooo)

랩 음악과 화학. 도무지 어울릴 것 같지 않은 조합이다.

Nature Chemistry Blog인 The Scepthical Chemist의 이 포스트에 따르면, 미국 UCLA의 Neil Garg 교수는 2학년 유기 화학을 강의하면서, 학생들이 이 강의의 내용을 가지고 뮤직비디오를 만들어서 올리면 약간의 점수를 더 주겠다는 제안을 했고 이후 모두 61개의 뮤직 비디오가 YouTube에 업로드 되었다.

그 중 하나가 바로 위에 첨부한 We in the Lab (Ooo Ooo). 동영상 촬영이 가능한 카메라 한 대와 맥북 한 대 (비디오는 분명 애플의 iMovie로 편집한 것이다!) 그리고 약간의 창의력과 시간만으로 완성된 뮤직 비디오이다. ‘We love chemistry ~’와 같은 가사가 들어 있는 랩 음악을 들을 수 있을거라고 생각해 본 적이 없기에, 이런 시도는 재미있기도 하고 의미심장하기도 하다. 게다가 이 비디오에서 SN2 반응을 어떻게 묘사하는지, E1 반응에 대해 어떻게 이야기하는지를 들어보면, 왜 이런 방식으로 화학을 배울 수 없는지 도리어 궁금해지지 않을 수 없다. 더 재미있는건… 댓글을 보면 이런 내용이 있다.

i would buy this shit instead of reading volhardt and schore… LOL

화학이라는 (따분해 보이는) 오래된 학문과 랩이 들어간 뮤직 비디오. 어울리지 않는 조합이기도 하고 앞으로 지금처럼 그냥 단순한 흥미거리 정도로 남아있을 수도 있다. 모든 파격이 주류가 되는 것은 아니니까.

그러나, 이런 (창의적인) 시도들이 계속될 때, 그 중에서도 생명력 있는 아이디어들이 살아남아 학계를 바꾸어 놓을 수 있는 가능성이 유지되게 된다. 학부 2학년 유기화학 시간이 지금보다 더욱 재미있고 활기찬 시간이 될 수 있는 방법이 있다면, 이 방법이 화학계를 발전시키는데 얼마나 큰 도움을 줄 수 있을지를 상상해 본다. 내 자신에게 이런 상상력이 미래를 바꿀 수 있다는 생각으로 꾸준히 시도하는 열정과 끈기가 있다면 좋겠다는 생각을 하면서.

http://totallysynthetic.com/

Paul Docherty가 운영하는 유기 합성 관련 블로그.

2008년에 천연물의 전합성으로 박사 학위를 취득한 Paul은 2006년 3월부터 이 블로그를 운영해 왔습니다. 저자의 연구 내용 때문이겠지만, 주로 재미있는, 혹은 어려운 분자들을 합성한 논문들을 소개하고 있습니다.

의약화학자들의 합성은 보통 SAR(structure-activity relationship) 패턴을 찾는 것이 목표이기 때문에, 짧은 시간에 다양한 구조의 유도체들을 합성하는 것을 목표로 하는 것이 대부분입니다. 이런 목표를 이루기 위해서는 1. 적절한 출발 물질을 이용하여 2. 가능하면 짧은 합성 경로를 사용하여 3. 가능한 한 다양한 물질을 합성할 수 있어야 합니다.

이에 비해 천연물의 전합성은 분리 정제가 어렵거나 다른 이유로 인해 물질 자체를 확보하기가 어려운 경우, 뛰어난 생리 활성을 가지고 있어서 다양한 유도체 합성이 필요하지만 적절한 출발 물질을 구하기 어려운 경우, 분자 자체의 구조가 합성하기 매우 어려운 경우 이루어지게 되며, 따라서 합성 경로가 비교적 길고, 이 과정에서 새로운 합성 방법을 개발하게 되는 경우도 많이 있습니다.

이 블로그에서는 주로 천연물의 전합성을 더 많이 다루고 있는데, 전체적인 반응 경로를 설명하면서 유기합성을 전공하는 저자의 시각으로 간단한 평가도 곁들이고 있기 때문에, 관련 전공자 뿐만 아니라, 유기 합성에 대한 깊은 지식이 없는 관련 연구자들에게도 매우 유용한 블로그라고 생각됩니다.

자주는 아니지만, 가끔씩 관련 연구자들이 댓글을 통해 서로의 의견을 나누기도 하는데, 실제로 이런 연구자들이 공개된 방식으로 이런 종류의 토론을 하는 것을 쉽게 발견할 수 없기 때문에, 매우 흥미진진한 일이 아닐 수 없습니다.

주제의 특성상 글이 자주 올라오지는 않지만, 올라오는 글들은 충분히 재미있는 내용이니 RSS를 구독하시는 것이 좋지 않을까 합니다.

ruby 언어로 (거의) 모든 개발 관련 일을 하고 있는 나로서는 irb가 매우 소중한 프로그램이다. 실제로 일을 할 때도 커맨드라인에서 루비 소스를 실행하는 것보다는 irb에서 실행을 할 때가 훨씬 많다.

기본 irb도 나쁘지는 않지만, 여기에 색을 더할 수 있다면 더욱 좋을 것이다. 사실은 한 스크린캐스트에서 irb 화면을 봤는데, 거기에서는 루비 신택스에 맞는 색을 보여주고 있었다. 프롬프트에 행번호가 보이지 않는 것은 약간 불만이었지만…

찾아보니 이런 기능을 하는 wirble이라는 이름의 gem이 존재하고 있었다.

> sudo gem install wirble

한 후에 자신의 홈 디렉토리에 .irbrc 파일을 만들고 다음과 같이 써 주면 된다.

require 'rubygems'
require 'wirble'
 
Wirble.init
Wirble.colorize

문제는 이렇게 한 후에 tab 키를 이용한 auto completion 기능이 현재 디렉토리의 파일 이름에 적용되는 것이 아니라 ruby 명령어에 대해 적용된다는 점이다. 작업 디렉토리의 ruby 스크립트를 load 명령어로 부르고 수정하고, 다시 부르고 하는 작업을 반복적으로 하는 내게 이 점은 매우 불편한 점이 아닐 수 없었다.

역시나 어떤 문제든 해결책은 있는 법. 바로 Bond라는 이름의 gem이 존재하고 있었던 것!

> sudo gem install bond

그리고 .irbrc 파일을 아래와 같이 고쳐주면 된다.

require 'rubygems'
require 'wirble'
require 'bond'
 
Wirble.init
Wirble.colorize
Bond.start

이제 tab 키를 이용한 auto completion 기능이 ruby 명령어뿐 아니라 현재 디렉토리의 파일 이름에도 동시에 적용이 된다. 약간의 멈칫거림이 있는 것이 눈에 띄긴 하지만, 이로 인해 얻게 되는 편안함에 비교할 바가 못된다. 내가 사용하는 모든 기기에서 .irbrc 를 위와 같이 쓰기로 결정!!

일을 하다 보면 여러 종류의 운영체제를 사용해야 하는 경우가 많이 있다. 특히 특정 환경 하에서만 일을 해야 하는 경우가 많은 회사와 달리 대학 연구실이나 중소 규모 단체 등에서는 사람들의 취향에 따라 여러 종류의 운영체제를 사용하는 것이 결코 낯선 일이 아니다.

내가 지금 일하고 있는 곳에서도 모두 여섯 가지의 운영체제를 사용하고 있다. 윈도우 XP, 윈도우 7, 데비안, 레드햇 엔터프라이즈 리눅스 5, 맥오에스 레퍼드, 그리고 맥오에스 스노레퍼드. 크게 보면 윈도우, 리눅스, 맥인 셈인데, 이 안에서도 상당한 차이들이 존재하기 때문에 그냥 세 종류라고 말하기는 좀 어렵다.

최근 몇 달 동안 Ruby를 이용해서 여러 종류의 프로그램들을 개발해 왔다. 주로 내 개인 맥북에서 일을 하는 관계로 첫번째 테스트는 주로 스노레퍼드에서 이루어진다. 그러나 실제 서버는 레퍼드에서 돌아가고 있으므로 레퍼드와 스노레퍼드의 미묘한 차이를 무시할 수는 없는 상황이다. 특히 레퍼드가 설치된 iMac에는 Fink나 port가 깔려 있지 않기 때문에, 소스 컴파일 방식의 소프트웨어 설치가 꺼려지는 부분이 있다. 실제로 소스에서 ImageMagick의 기능을 이용하기 위해 rmagick gem을 사용하는데, 레퍼드에서 port를 사용하지 않고 ImageMagick을 설치하는 것이 그렇게 간단하지만은 않다.

이런 이유로, ImageMagick 관련 일과 (기타 다른 작업들)을 위해 버려진 PC에 데비안을 설치했다. 내 노트북에서 실행하기에는 버거운 작업들은 모두 이 리눅스 박스에서 실행을 한다.

팀의 모든 사람들이 윈도우용 MS 오피스와 ChemOffice를 쓰고 있는데다가 윈도우에서만 사용할 수 있는 좋은 프로그램들도 꽤 있기 때문에 윈도우 머신을 쓰지 않을 수 없다. 최근에는 윈도우 XP 재설치로도 해결되지 않는 문제가 좀 있어서 윈도우 7을 쓰려고 생각하는 중.

이 모든 운영체제를 사용하면서도 동일한 데이터를 쓸 수 있는 것은 온전히 Dropbox 서비스 덕분이다. 이 세 운영체제에서 동일한 데이터를 사용할 수 있도록 해 주는 이 서비스의 가장 큰 장점은 한 계정 당 붙어있는 컴퓨터의 대수에 제한이 없다는 점이다. 리눅스용은 우분투와 페도라만 패키지로 지원하기 때문에 다른 종류의 배포판에서는 소스 설치를 해야 한다는 점이 있기는 하지만, 소스 설치가 지원된다는 것만 해도 감사할 따름. 2기가의 용량이 무료인데, 이 정도면 보통은 넉넉한 수준이고, 굳이 더 많은 용량이 필요하다면 리퍼럴을 통해 무료 용량을 늘리거나 다른 계정을 하나 더 만들어서 두 개의 드랍박스 프로그램을 돌리는 방법을 사용해도 좋다.

이번에 팀을 떠난 전임자로부터 리눅스 컴퓨터 한 대를 이어받게 되었는데, 이게 바로 RHEL5를 사용하고 있는 컴퓨터이다. 동일한 환경을 만들어보려고 체크를 해 보니 우선 Ruby 버전이 2006년에 나온 1.8.5 버전. 지금 다른 컴퓨터들에서 쓰고 있는 1.8.7과 숫자 차이는 크게 나지 않지만, 그 동안 변경된 부분이 생각보다 매우 많다. 그냥 쓸 수는 없는 상황이고, 잘 돌아가고 있는 서버에 굳이 다른 repository를 첨가하는 것도 내키는 상황은 아니었는데, Ruby Enterprise Edition이라는 것을 발견해서 그냥 개인 디렉토리 안에 설치하고 환경을 만드는데까지는 성공. 모든 내용을 개인 디렉토리 안에 넣어둬서 시스템을 건드리지 않는다는 점이 큰 장점이다. 다만 ImageMagick은 깔려 있는데 관련 개발 모듈이 깔려있지 않은 관계로 rmagick 설치는 좀더 뒤로 미룰 수 밖에 없게 되었다.

여러 운영체제에서 동일한 데이터를 사용하여 작업을 하는 것은 실질적으로는 쉽지 않은 일이다. 그리고 운영체제들 간의 사소해 보이는 작은 차이점들이 실제로는 풀기에 꽤 난감한 상황이 되는 일이 심심치 않게 벌어진다. 그럼에도 불구하고 상황에 따라 다양한 운영체제를 사용하는 것은 피하기 힘든 일이다. 앞으로 많은 어플리케이션들이 웹 기반으로 바뀌게 된다면 좀더 쉬운 상황이 되겠지만 연구를 하는 입장에서 연구용 소프트웨어들이 웹 기반으로 나오는 것을 기대하기는 어렵다는 점을 감안하면, 앞으로도 이런 환경에서 다양한 운영체제를 다루는 일은 항상 필요하게 될 것 같다. 그리고 그에 따라 귀찮음도 계속 따라다니겠지…

사용자의 입력을 받아서 Dynamic하게 데이터를 보여줘야 하는 필요가 있었다. 이 필요를 위해 웹 서비스를 만드는 것이 나을지, 아니면 fxruby같은 GUI tool을 써서 OS independent 어플리케이션을 만드는 것이 나을지 고민을 했다. 고민의 결과는… 어차피 매우 간단한 프로그램인만큼 둘 다 해 보기로 했다.

우선 fxruby부터 시작. 사실 위젯을 그리고 GUI를 만드는데 있어서 fxruby는 매우 쉬운 도구이다. 게다가 이미 이에 관한 좋은 책도 구매를 했기 때문에 정보가 없어서 중간에 막히는 일은 없을거라는 생각이 들었다. 더 좋은 점은 fox toolkit이 OS에 상관 없이 돌아가기 때문에, fxruby를 사용해서 만든 어플리케이션은 지난번에 사용한 적이 있는 ocra를 이용하여 쉽게 바이너리로 배포할 수 있다는 점이다.

디자인을 하고 GUI를 만드는데까지는 그렇게 어렵지 않았다. 그런데, 이 데이터들을 csv 파일 형태로 가지고 작업을 하다보니 귀찮은 부분이 꽤 있었다. 특히 해당 csv 파일이 가지고 있는 필드만을 뽑아서 다이내믹하게 보여주는 부분에서 시간을 꽤 쓰고도 만족스러운 결과를 만들어내지 못했다. 그래서 결국은 더 쉬운 웹 서비스로 이동! (나중에 여유 시간을 좀 내서 이 부분을 다시 해 볼 생각이다.)

Ruby로 웹 서비스를 만든다면 당연히 Rails를 생각할 수 있겠지만, Rails는 내가 생각하는 목적을 놓고 생각해보면 너무 무겁고 복잡한 프레임워크라는 생각이 들었다. 그래서 선택한 것이 바로 Sinatra! 간단하게는 소스 파일 하나와 템플레이트 파일 하나만 있으면 바로 잘 작동할 수 있다는 것이 마음에 들었다. (홈페이지를 보면, 이 프레임워크가 얼마나 간단한 것인지 쉽게 짐작할 수 있다. 아마, 홈페이지 처음에 쓸 내용이 별로 없었을거라고 생각된다.) 복잡한 기능을 요구하는 프로젝트가 아니었으니, 파일 자체의 개수를 줄이는 것이 필요했는데, 지가 알아서 많은 파일을 생성해 놓는 Rails보다는 Sinatra가 이런 측면에서 훨씬 가벼운 것이다. 선택해야 하는 것이라고는 템플레이트 엔진으로 무엇을 써야 하는가 하는 정도 뿐. 사실 haml을 선택하는 것이 더 시류에 맞는 것이겠지만, 짧은 시간 안에 로직과 디자인을 모두 해야 한다는 측면에서는 그냥 대충 html 코드를 만들고 그 중에 필요한 부분에만 ruby 코드를 사용할 수 있는 erb가 좀더 상황에 어울리는 듯 했다. 그래서 sinatra와 erb를 쓰기로 결정.

Sinatra가 좋은 점 중의 하나는 바로 route 로직을 디자인할 수 있다는 것, 그리고 이걸 통해서 쉽게 사용자 입력을 받을 수 있다는 점이다. 말하자면 맨 처음부터 RESTful 어플리케이션이라는 것. 이렇게 개발을 하면 처음부터 사용자가 어떤 방식으로 이 서비스를 사용할 것인지를 염두에 두게 되므로 빠르고 간단하게 개발을 하는데 도움이 되는 것 같다. 그리고 서버 셋팅을 메인 코드 안에 간단하게 넣을 수 있으므로, 기본적인 기능만을 구현하는데는 단 한 개의 소스 파일이면 충분하다. 이렇게 해서 내가 만든 ruby 코드는 모두 72줄! erb 파일 두개의 라인 수까지 모두 합쳐도 200줄이 안된다. (물론 자세한 주석이 없다. 근데 72줄짜리 소스에 주석이 많이 필요할까?) 이 정도의 소스를 가지고 간단한 웹 서비스를 (몇 시간만에) 개발할 수 있다는 것은 축복이 아닐 수 없다.

소스 파일은 대충 이런 모양으로 생겼다.

require 'rubygems'
require 'sinatra'
require 'fastercsv'
require 'ruport'
require 'erb'
 
set :public, File.dirname(__FILE__) + '/../compounds'
 
get '/' do # Only get
  erb :index
end
 
get '/:id/:property' do # No post
  @library = params[:id].to_s # Do I need to_s here?
  @property = params[:property].to_s
  @data = parse_csv_table(params[:id], params[:property])
  erb :view
end
 
def parse_csv_table lib_name, an
  ... # data manipulation logic
end