백 만년 만에 글이네요. 그 동안 예비군도 다녀오고 회사 업무로 바쁜 탓도 있었지만, 블로깅은 안 쓰기 시작하면 또 한정 없이 안 쓰게 되는 특성을 가지고 있는 것 같아요.

회사에서 지금 만들고 있는 제품(모질라 기반인 만큼 곧 오픈소스로 나오겠죠? ^^)과 관련해서 그간 모질라 프로젝트를 쭉 살펴보고 있었습니다. 모질라가 개발 플랫폼으로 밀면서 칭찬을 아끼지 않는 XULRunner를 가져와서 작업하고 있습니다. XULRunner는 2분기에 출시될 예정인 Firefox3와 맞물려서 XULRunner 1.9의 마무리 작업인 한참 진행 중인 상태죠.

모질라 홈페이지를 방문해보면 상당히 많은 양의 문서를 발견할 수 있습니다. 과거 코드만 달랑 공개하고 문서가 전무했던 다른 프로젝트에 비하면 상황이 상당히 좋은 편이죠.

하지만 모질라라는 몬스터급 괴물을 씨름하는 데 있어서는 이 정도 문서도 빈약하다는 생각이 드네요. 더군다나 막대한 덩치 때문인지 문서를 만드는 사람들도 제각각 일관성이 없는 데다가, 오래된 문서들이 갱신이 안 되고 있어서 실컨 읽다가 보면 이거 너무 옛날 얘기잖아 하면서 실망한 적이 많이 있었습니다. webshell이 docshell이 되고, 임베딩에 쓰는 런타임도 MRE였다가 GRE이 였다가 지금은 XRE라고 하는데, 뭔가 정리 안 된 느낌 때문에 혼란스럽네요.

결국은 모질라 메일링 리스트에 가입해서 관련 글도 훑어보고 문서나 코드만으로 이해 안 되는 질문들을 하나 둘씩 올려보고 있습니다. 적극적인 참여 없는 오픈소스란 결국 전임자가 만들다가 던져놓고 간 소스코드와 문서를 보면서 좌절하는 느낌과 묘하게 비슷하더군요.

저는 개발할 때 윈도를 쓰지만, POSIX compliant한 Cygwin 환경에서 대부분의 작업을 합니다. 주로 하는 일이라는 게 ./configure 스크립트를 돌리고 make를 치고 소스 코드를 vim으로 보는 것이기 때문입니다.

최근에는 조금 복잡한 소스 코드를 가져다가 Visual C++(커맨드 라인의 cl.exe와 link.exe)와 Cygwin을 섞어서 컴파일할 일이 있는데, 이렇게 되니깐 상당히 헷갈리는군요. 윈도 쪽에서 set으로 환경 변수준 것도 있고 Cygwin에서 export한 것도 있고, 특히나 파일 패스명이 다르다 보니 어디에서는 /cygdrive/c/ 와 같이 시작하고 어디에서는 C:\로 시작하니 정신이 없습니다. 특히 Subversion, Python, Ruby 등은 윈도 버전도 깔려 있고 Cygwin 버전도 깔려 있어서 내가 지금 어느 윈도용을 쓰는건지 Cygwin용을 쓰는 건지도 헷갈리게 되네요.

그래서 제가 다시 부활시킨 게 MinGW입니다. MinGW는 Win32를 위한 미니멀한 툴 체인을 주는 것을 목표로 하고 있는데, 원래는 Cygwin에서 fork된 프로젝트입니다. 다만 철학이 달라서 Cygwin이 POSIX를 거의 다 에뮬레이션해서 대부분의 프로그램을 컴파일하는 데 비해서, MinGW는 미니멀한 툴 체인만 주고, 보다 Win32에 특화된 네이티브한 어플리케이션을 작성할 수 있게 합니다.

여러분은 어떤 환경에서 작업하세요?


추가: MinSYS의 경우 rxvt 터미널에서 pty emulation 관련 문제로 네이티브 윈도 프로그램들이 제대로 동작 안 하네요. python.exe이나 irb.bat 등을 실행시키면 멈춰 버립니다 ㅠ.ㅠ

추가: 이 문제로 메일링 리스트에 포스팅을 했더니, MinSYS에 rxvt를 디폴트 터미널로 해야할지 말아야 할지로 꽤 많은 의견이 오가고 있군요. rxvt가 일으키는 문제의 원인은 다음과 같았습니다.

Keith MARSHALL <keith.marshall@total.com>

RXVT owns the `stdin', `stdout' and `stderr' file descriptors bound to your console, and uses pipes to connect these to your shell, and to any process you invoke from that shell. A pipe is not a tty, so `isatty()' returns `false', for these `stdio' streams in the application; thus, the standard runtime init routines enable block buffering for these streams, rather than the expected line buffered or unbuffered modes. This causes at least two serious problems for interactive console applications, run within an RXVT:

1) Expected output is delayed in the block buffer, instead of appearing on the screen; users are left waiting for prompts that never appear on the screen, yet the application has moved on, and is waiting for their input, (unless the application has been sprinkled with `flush()' calls, to explicitly work around this abnormal behaviour).

2) Special characters, such as ^D or ^Z, which users expect to be able to use to signal EOF on input are swallowed by RXVT; applications which loop until EOF on `stdin' are locked into a perpetual interminable state.

The above is a consequence of Win32's lack of *nix's `pty' feature; trying to emulate it with pipes just isn't at all satisfactory. I do know that Earnie has put considerable effort into seeking a solution to this `pty' emulation problem, with frustrating lack of success.

FORTRAN 언어 설계자이자 BNF를 만든 John Backus 씨(1977년 튜링 어워드 수상자)가 별세하였습니다. 삼가 조의를 표합니다.

개인화 홈페이지로 유명한 NetVibes사가 Universal Widget API(UWA)라는 걸 내놨습니다. 기술적인 내용은 간단합니다. Google IG나 애플 Dashboard 등 어차피 비슷한 기술(자바스크립트, HTML, CSS)을 사용하는 위젯 플랫폼들이다 보니 위젯을 한 번 작성해서 모든 플랫폼에서 돌려보자는 겁니다.

방식은 간단합니다. XHTML 파일 하나에 XHTML, CSS, 자바스크립트를 다 때려 넣고, 모든 엘리먼트 접근과 이벤트 처리는 UWA API를 통해서만 합니다. 그럼 각각의 위젯 플랫폼에 UWA 환경(API)를 포팅해주기만 하면, 위젯을 한 번 작성해서 여러 플랫폼에서 돌릴 수 있는 거죠.

또한 아직 종류가 많지는 않지만 일종의 템플릿 위젯 기능도 제공합니다. RSS 리더 같은 건 RSS 종류랑 스킨만 바꿔서 여러 가지 위젯을 만들 수 있는 데 이런 걸 일종의 템플릿으로 제공하는 거죠. 애플 Dashboard에도 비슷한 기능이 있었던 것으로 기억합니다.

이런 기술이 가능한 이유는 기존 위젯 플랫폼이라는 게 사실 껍데기만 다르지 실제로 하는 짓이나 기반 기술은 별반 차이가 없기 때문입니다. HTML (혹은 일부 자체 XML), CSS, 자바스크립트라는 모델도 유사하고, 할 수 있는 API도 별 차이가 없습니다. 심지어 데스크톱 위젯이나 브라우저 위젯이나 별 차이가 안 납니다. 결국은 공통적인 요소들 모아서 별도의 위젯 플랫폼을 정의하고, 다른 플랫폼 위젯으로의 전환은 자동화될 수도 있는 수준이라는 거죠.

앞선 글인 위젯 플랫폼에서 이야기한 것처럼 조금 더 고수준의 마크업 언어와 API를 정의한 후에 저수준의 기존 플랫폼으로 변환(XML 스타일쉬트와  API 포팅)하면 얼마든지 여러 플랫폼으로 포팅이 가능할 수도 있고 더 의미가 있을 것 같네요. UWA는 API 부분만 한 셈인데, XHTML 대신에 UI 요소를 나타낼 수 있는 조금 더 고수준의 별도 마크업을 사용했으면 어땠을까 하는 아쉬움이 남습니다.

위젯 플랫폼이 쏟아져 나오고 있습니다. 특히 애플, 오페라를 비롯한 브라우저 벤더, 브라우저 벤더가 아니더라도 브라우저에 기반한 플랫폼을 내놓는 곳이 많군요.

이미 HTML(혹은 XHTML), CSS, 자바스크립트를 이용한 (결국 브라우저 엔진을 이용한) 위젯 구현 방식은 상당히 보편화되었습니다. 사실 브라우저 벤더 입장에서 위젯은 거저 먹는 플랫폼이죠. 애플 Dashboard도 사파리 구현하고 보니, 웹브라우저 엔진이 위젯 구현에도 그대로 쓸 수 있으니깐 한 번 구현해본 것이고, 오페라도 브라우저 엔진이 있으니깐 오페라 위젯을 쉽게 만들 수 있게 되었습니다. 위젯은 브라우저를 플랫폼으로 하는 어플리케이션이니깐요.

하지만 웹 프로그래밍은 기술적인 퇴보?라 는 글에서 이야기했듯이, HTML과 CSS, 자바스크립트를 이용한 웹페이지 제작, 혹은 위젯 제작은 너무 손이 많이 가는 작업입니다. 위젯이라는 간단한 어플리케이션을 손쉽게 만드는 환경과는 거리가 먼 개발 환경이지요. HTML은 기본적인 UI 컴포넌트도 하나 없는 열악한 엔진입니다. (WHATWG에서 추진하는 HTML5가 이걸 개선하는 거죠.) HTML로 위젯 만들라는 건 마치 둘리 12색 물감 주고 유려한 수채화를 그리라는 것과 마찬가지가 아닐지요?

결국 조금 더 고수준의 위젯 제작 환경이 필요합니다. 모질라의 XUL도 사실 별로 고수준은 아닙니다. HTML 보다야 사정이 낫지만 겨우 윈도나 컨테이너, 버튼 같은 전통적인 UI 컴포넌트가 몇 개 추가된 수준이거든요. Flex의 Rich Text Editor 같은 UI가 조금은 근접했다고 볼 수 있고요. 정말 손쉽게 뭔가를 붙이고 뚝딱뚝딱 사용자가 위젯을 만들기를 원한다면, 데스크톱 RAD(Rapid Application Development) 개발 도구 수준의 UI 컴포넌트와 개발 도구가 뒷받침되어야 할 겁니다.

결론은 남는 브라우저 엔진으로 플랫폼을 공짜로 먹겠다는 생각으로는 치열한 위젯 월드에서 살아남긴 힘들다는 거죠. 심지어 남의 기술인 플래시 위에 올라간 위젯 플랫폼 회사는 말할 것도 없고요.

어김없이 마소 마감일이 다가와서 급히 원고를 작성했습니다. 항상 "기본으로 돌아가자"를 신조로 삼는지라 이번 주제는 Ajax와 각종 위젯 제작 언어로 또 다시 각광을 받고 있는 자바스크립트를 재조명해봤습니다.

특히

1) 자바스크립트의 함수가 제1클래스이며 클로저를 지원한다는 사실
2) 자바스크립트의 독특한 오브젝트 생성 방식 및 속성 상속

에 대한 이야기를 중심으로 실었습니다. 지난 달에는 루비를 중심으로 클로저 이야기를 했었는데, 1번은 지난 달 내용이랑 약간 오버랩 되는 부분이 있네요.

내용을 공개했으면 좋으련만, 엄연히 저작권을 대가로 돈을 받는지라 흑 ㅠ.ㅠ 아래 내용은 박스 중에 하나입니다.

자바스크립트에 대한 오해의 시작

Ajax가 자바스크립트를 다시 한 번 메인 무대에 올려놓기 이전에는 대부분의 개발자가 자바스크립트는 일반적인 프로그래밍 언어에 미치지 못하는 단순한 스크립트 도구라고 생각했다. 즉, 정규 프로그래밍 언어보다는 HTML의 보조 도구 정도로 인식되는 것이 일반적이었다.

이런 오해가 생긴 이유는 네스케이프와 썬마이크로시스템즈 사가 자바스크립트를 포지셔닝한 전략에 있다. 이들은 클라이언트 프로그래밍에 있어서 자바스크립트가 자바의 경쟁자로 자리매김하길 원치 않았기 때문에, 자바에 비해 자바스크립트를 열등한 언어로 알려야만 했던 것이다. 당시 자바스크립트의 기능을 제대로 알릴 수 있었다면, 자바스크립트는 좀 더 일찍 주목받았을지도 모른다.

요구사항 엔지니어링에서 역설적인 격언이 하나 있습니다. "고객의 말에 항상 귀를 기울이되 고객을 믿지 말라"는 원칙입니다. 고객은 자신이 무엇을 원하는지 정확히 모른다는 말과도 일맥상통합니다.

유저 인터페이스와 상호작용(interaction)에 대한 전문가인 Alan Copper는 Channel 9과의 인터뷰에서 이런 표현을 쓰더군요.

"사용자(혹은 고객)은 5살짜리 유치원 아이와 같다. 유치원 선생님은 항상 아이들의 말에 귀 기울이고, 아이들에게 이로운 일을 해주고자 한다. 하지만 아이들이 사탕 주세요 과자 주세요 한다고 해서 절대 이 말을 들어주지는 않는다. 다만 이를 통해 아이들이 원하는 바를 파악한다. 바로 배가 고프다는 사실이다."

요구사항을 뽑아내는 것도 같은 과정이라고 얘기합니다. 사용자의 말에 귀 기울이고, 무엇을 원하는지 들어보지만 이 과정은 매우 비판적이어야 한다는 것입니다. 사용자가 시킨 대로 그대로 구현해가면 오히려 실망하는 경우가 많다는 것이죠.

Alan Copper의 인터뷰는 시간 나면 한 번 보시기 바랍니다. 소프트웨어 개발 과정에 있어서 인터액션 디자이너의 중요성이나, 현재 죽음의 행진(death march)라 불리는 소프트웨어 프로젝트 진행 현실에 대해 이런 저런 이야기를 합니다.

기업이 어떤 제품에 가격을 매기면, 소비자는 구매 판단을 하게 됩니다. 이때 구매자가 느끼는 효용이 물건이 가격보다 높으면 물건을 구매하게 되고, 그렇지 않으면 보류하게 됩니다. 가격을 하나로 통일했을 경우에 문제점은 가격이 조금만 더 낮았다면 제품을 구입했을 많은 고객을 놓치는 데 있습니다. 그렇다고 가격을 낮추면, 높은 가격을 주고라도 제품을 구입했을 고객들에게는 싼 값에 판 셈이 되는 문제가 있습니다. 이윤을 극대화하는 가격을 찾는 게 기업 전략에서 가장 어려운 부분 중에 하나였죠.

가격 차별화(price discrimination)은 기업의 이익을 극대화하는 매우 효과적인 방법입니다. 하나의 물건에 서로 가격을 붙여서 고객들에게 최대한의 이윤을 취하는 전략입니다. 대형 마트에서 쿠폰을 발행하는 것도 가격 차별화의 하나입니다. 쿠폰이 없이도 기꺼이 상품을 구매할 소비자들에게는 제값을 받고 팔고, 가격에 민감한 일부 고객들에게는 쿠폰이라는 옵션으로 구매를 유도하는 거죠. 즉 이들은 서로 다른 가격에 같은 물건을 구입하게 되는 것이죠.

또 다른 예제로 미국에서 판매하는 교과서도 가격 차별화 정책을 폅니다. 상대적으로 구매력이 낮은 아시아 지역에는 싼 가격에 책을 내놓고, 구매력이 높은 미국에는 비싼 가격으로 파는 것이죠. 물론 가격 차별화 전략이 가능 하려면, 이 두 구매층 간에는 경계선이 분명해야 합니다. 아시아에서 책을 산 다음에 미국에 가서 대량으로 판매하면 이런 정책이 의미가 없어지기 때문이죠.

소프트웨어 기업도 이런 가격 차별화 정책을 극단적으로 구사해서 독특한 성장 전략을 구사한 곳이 있습니다. 대표적인 곳이 MySQL입니다. MySQL은 일반 공개 배포 버전인 커뮤니티 버전과, 기업용 버전인 엔터프라이즈 버전이 있습니다. 물론 엔터프라이즈 버전이 서비스 측면에서 여러 가지 부가 요소가 있지만, 실제로는 같은 제품을 서로 다른 가격으로 팔고 있는 셈입니다.

이런 가격 차별화 정책은 밑바탕에는 소프트웨어 이중 라이센스(dual license) 모델이 있습니다. 같은 제품에 서로 다른 두 개의 라이센스를 걸어서, 사업 기회를 만드는 전략입니다. MySQL을 다시 예로 들면, 커뮤니티 버전은 일반 사용자들에게 무료로 배포하고 이에 대한 대가로 제품에 대한 피드백과 마케팅 효과, 테스트 등의 간접적인 이득을 얻습니다. 반대로 엔터프라이즈 버전은 상업 라이센스를 적용해 가격을 책정합니다.

앞서 가격 차별화 정책은 반드시 두 구매층이 물리적 혹은 제도적으로 분리되어 있어야 한다고 말씀 드렸는데, MySQL의 가격 차별화 정책은 소프트웨어 이중 라이센스가 이를 가능케 합니다. 커뮤니티 버전의 라이센스는 GPL로 되어 있어서, MySQL을 제품에 탑재(embedding)하고자 하는 고객은 반드시 사유 라이센스를 구매해야 하는 모델이기 때문입니다. 즉 일반 사용자와 임베딩 사용자를 별도로 고객층으로 분리하고, 완전히 다른 가격 정책을 취한 것이죠.

비슷한 방식으로 성공한 기업은 버클리 DB(Berkeley DB)로 유명한 Sleepycat이 있습니다. 임베딩 DB라는 측면에서는 MySQL과 유사한 전략을 취했고요. Mozilla나 QT도 같은 맥락에서 파악할 수 있고요. 이중 라이센스를 이용한 가격 차별화 정책은 앞으로의 소프트웨어 회사가 취할 수 있는 유용한 전략이 아닐까 합니다.

제목을 다소 선정적으로 잡아봤습니다만 웹 표준화에 있어서 W3C의 역할을 폄하하려는 것은 아닙니다. 다만 W3C를 통합 웹 표준 제정의 문제점을 지적하려 합니다.

W3C 표준과 브라우저.

W3C는 웹 관련해서 수많은 표준을 제정하고 있지만 그 중에서 사람들에게 가장 익숙한 표준은 HTML, XHTML, DOM, CSS일 것입니다. 근데 이러한 표준을 구현했다는 대표 브라우저 IE, Firefox, Safari, Opera에서 웹 프로그래밍을 해보면 같은 표준인데도 미묘하게 구현이 다르고, 일부가 누락된 문제 때문에 많은 불편을 겪게 됩니다. 웹 표준 하에서라면 당연히 되어야 할 ‘크로스 브라우저’ 지원이라는 게 고급 프로그래밍 기술이 되어버린 거죠.

지금까지는 비난의 화살이 주로 브라우저 업체들에 맞춰졌던 것이 사실입니다. 표준이 이런데 왜 제대로 다 구현을 안 했느냐는 거죠. 하지만 이런 현실을 놓고 보면 표준화 기구인 W3C의 역할이 제한적임을 알 수 있습니다. 브라우저 업체들이 W3C에 참여해서 표준을 제정하지만, 해당 표준 제정에 같이 참여한 다른 브라우저 업체들에게 강제할 수 없다는 거죠.

사실 어떤 표준화 회의던지, 제품 구현에 대한 생각이 전혀 없이 표준화 회의에 가서 회의부터 한 다음에, 표준이 완성되고 제품 구현에 들어가는 회사는 하나도 없을 것입니다. 표준 제정 이전에 이미 표준안에 대한 생각을 가지고 있고 제품을 시작한 후에 최대한 자기가 생각한 안을 표준에 밀어 넣으려고 싸움을 벌이는 것이 일련의 절차죠. 이 과정에서 각 업체들이 생각했던 초안에 상당한 수정이 생기고, 추가 혹은 누락되는 경우도 생깁니다.

현재 브라우저 간의 호환성 문제를 보면 이런 상황을 잘 알 수 있습니다. 이미 제품은 어느 정도 완성이 된 상태이므로, 표준화 회의에서 나온 내용 중에 수정이나 추가 구현이 힘든 부분은 무시하고 원래 안대로 제품을 출시해버리는 거죠. 당연히 큰 그림에서는 해당 표준을 구현했다고 할 수 있지만, 미묘한 부분들이 서로 맞지 않아 불편함을 겪는 상황이 오게 됩니다.

이런 상황 때문에 DOM 레벨 2 같은 표준은 표준을 다시 여러 개의 작은 표준으로 쪼개고 일부만 구현할 수 있게 했지만, 근본적으로 서로 다른 꿈을 꾸고 있는 브라우저 업체들이 이마저도 일부를 빼먹거나 자기 입맛대로 출시하는 상황은 여전히 반복되고 있습니다.

썬마이크로시스템즈의 JCP 같은 표준화 기구와 비교해 보면, W3C는 표준의 엄격한 준수를 위한 2가지 절차가 빠져있습니다.

1) 참조 구현(Reference Implementation)
2) 테스트킷(Test Kit)

레퍼런스 구현은 해당 표준은 제품으로 구현해 본 시제품을 말합니다. 표준안을 만들고 나서 실제 벤더들이 참조할 수 있도록 시제품을 만들어 보지 않으면 표준 자체가 제대로 된 것인지 검증할 방법이 없는 것이죠. 사용성(usability)이 떨어지거나, 각 구현들이 입맛대로 수정할 수 밖에 없는 상황이 오게 됩니다.

참조 구현보다 더 중요한 것은 테스트킷의 존재와 인증 절차입니다. 표준을 정의했으면 해당 표준을 만족시켰는지 여부를 쉽게 판단할 수 있는 테스트킷이 필요하고, 표준을 구현한 벤더들의 제품은 이 테스트킷을 통과해야만 표준을 구현했다고 공식적으로 말할 수 있는 것입니다. 이런 절차가 있었다면 표준 일부를 빼먹거나 각 벤더들의 필요에 따라 선택적으로 구현하고는, 표준을 준수했다고 말하지는 못하겠죠.

W3C의 구성이나 표준 제정 절차에 대해서 잘 알지는 못하지만, 이런 요소들이 보강될 수 있었다면 조금 더 강력한 표준화 기구가 될 수 있었겠죠. 하지만 지금의 상황을 보면, 이렇게 까지 표준을 강제했다면 과연 웹 표준화 기구라는 게 존재할 수나 있었을까라는 의문이 드는 것도 사실입니다. 표준 구현에 있어서 비교적 자유로운 HTML이 XHTML보다 훨씬 큰 성공을 거둔 부분만 봐도 알 수가 있습니다.

하지만 초기의 자유스러움이 많은 참여를 이끌어내 웹을 발전시켰다면, 강력한 표준 규제로 상생의 길을 여는 것이 현재의 요구 사항이 아닐까 합니다.

Ajax 유명한지는 좀 되었지만, 최근 Ajax 기반의 각종 라이브러리들(Prototype, Dojo, Mochikit, jQuery, YUI 등)이 활발히 개발되면서 또 다른 전성기를 맞고 있는 것 같다. 그리고 Ajax하면 항상 하는 말이 크로스 플랫폼, 크로스 브라우저 등등 하는 개념이다. 그간 프로그래밍 언어만 보느라 웹 프로그래밍에 별로 관심이 없었는데, 시간 내서 Ajax와 웹 프로그래밍 개념들을 좀 공부해보니 뭔가 이상하다. Ajax 이거 별로 매력적이지 않다.


크로스 브라우저? (혹은 크로스 플랫폼)

표준인 HTML(혹은 XHTML)과 CSS, 자바스크립트만 사용하면 어떤 플랫폼, 브라우저에서든 동작하지는 프로그램을 만들 수 있을까? 결론부터 말하면 만들 수 있다. 하지만 절대 쉽게 만들지 못한다.

일단 Ajax의 근간이 되는 XMLHttpRequest부터 심상치 않다. IE는 ActiveX 컨트롤이고 다른 브라우저는 이 기능만 훔쳐다가 네이티브 오브젝트로 만들어놨다. 결국 브라우저에 맞춰서 if else... 구문이 잔뜩 들어박혀야 한다. 그래도 XMLHttpRequest야 공식적으로 표준화된 적도 없고 그냥 어쩌다 보니 많이 쓰인 API인 셈이니 일단 넘어가자.

DOM은 사정이 어떨까? DOM이라 하면 W3C가 적극 밀어주는 표준 API가 아닌가! 하지만 브라우저 별로 또 구현을 조금씩 다르게 해놨다. 특히 IE가 말썽인데, 항상 표준대로 구현하지 아니하고 프로퍼티 이름을 한 두 개씩 바꿔서 클라이언트 코드에 if else... 를 박지 아니할 수 없게 한다. 또 DOM 레벨 2 이벤트 모델 표준 제정에 직접 참여한 MS가 왜 DOM 2 이벤트 모델을 제공 안 한단 말인가. 표준 회의에는 왜 간 건지 의심스럽다.

JavaScript가 너무 다양한 버전으로 존재하는 것도 문제다. 현재 JavaScript 1.5 기반이면 거의 통하기는 한다. (구버전 IE는 여기서조차 Array의 중요 메서드 몇 개를 빼먹었다.) 하지만 Firefox가 JavaScript 1.6, 1.7로 올리고 일부 Array API를 네이티브로 내려서 속도 향상을 시도해도, 크로스 브라우저에 맞추려면 이런 기능을 적극 활용하기가 힘들다.

CSS도 브라우저 별로 뭐는 되고, 뭐는 안 되고 이런 게 너무 많다. 이른바 방탄웹으로 유명한 책이 처음 하는 얘기가 각 브라우저 CSS 처리기의 버그를 이용해 여러 브라우저에서 동일한 화면을 만들어내는 데 있다는 걸 보고 충격 먹었다. 버그에 의존하는 코드라니, 정말 고통스러운 개발 환경이다.

여기까지만 보면 UNIX와 Windows, MacOS X 등에서 컴파일되기 위해 #ifdef #endif를 때려 박은 C 언어 라이브러리랑 별로 차이가 없어 보인다. C 언어는 안 되면 아예 컴파일을 못하기라도 하는데, 웹 프로그래밍은 결국 같은 바탕에서 출발해서 조금씩 미묘하게 다른지라 잘될 것 같기도 하고 안 될 것 같기도 한 애매한 상태이다.

결국은 이런 플랫폼(혹은 브라우저)의 차이를 잘 감춰주는 Ajax 라이브러리를 이용하는 방법 밖에 없다. 현재 Ajax라이브러리의 춘추전국시대(?)처럼 보이는데, 정말 쓸만한 라이브러리 몇 개로 통폐합 될 때까지는 어떤 라이브러리를 골라야 할지도 고통이 따를 게다.

웹프로그래밍이라는 거 실제로 필요한 로직을 만드는 것보다 사소하게 신경 써야 할 일이 너무 많다. Frederick P. Brooks의 말을 빌리자면 아직까지 Accidental Complexity가 너무 심하다. 사실 데스크톱에서 RAD 툴로 어플리케이션 만들어 본 사람이라면 지금의 웹프로그래밍은 정말 고통스러운 거 아닐까? 화려한 Ajax라고 해봐야 결국 데이터 조금 주고 받고 화면 이쁘게 꾸미는 것 밖에 없지 않은가? Ajax 라이브러리가 발전하고 예전에는 안 되던 각종 효과를 보여주는 것만으로 놀라는 것도 이해하지만, 실상 웹이랑 담쌓고 데스크톱 개발자가 들어와서 보면 정말 웹프로그래밍은 프로그램 개발에 관해서는 기술적으로 퇴보한 셈이다.

원래 큰 기술적인 도약이 있기 전에는 한 단계 퇴보하는 게 IT 역사의 법칙이긴 하다. 예를 들어, 과거 TP Monitor라고 해서 비행기 예약시스템 등에 도입되어 사용된 트랜잭션 시스템은 이미 기술적으로 성숙해 있었는데, 인터넷 초기에 나온 WAS 서버들은 트랜잭션 처리 면에서는 오히려 기술적으로 퇴보했다. 인터넷이 크게 성장하면서 지금에 와서는 예전 수준을 넘어섰지만 플랫폼의 변경과 같은 큰 기술적인 변화 속에서는 다른 기술이 순간적으로 퇴보하는 것은 사실이다.

지금은 웹 프로그래밍이라는 것도 어쩌면 잔뜩 웅크린 상태에서 다음 도약을 노리는 게 아닐까 싶다. 하지만 경계해야 할 점은, 멋진 개발 프레임워크와 도구가 갖추어지고 나면, 지금 Ajax 프로그래머의 노하우는 한줌의 먼지가 될지도 모른다는 사실이다.

Firefox Extension 기능을 시험해 볼 겸 간단히 네이버 영어 사전 애드온을 만들어 보았습니다.

호호딕 0.1

마우스로 단어를 두번 클릭해주면 네이버 Open API를 사용해서 새창으로 단어 뜻을 찾아주는 간단한 프로그램입니다. '도구-부가기능-HohoDic설정'에 가셔서 발급받은 네이버 Open API 키를 넣어주시면 됩니다. 디폴트로 제 키가 들어있습니다. 프로그램을 시작하면 오른쪽 아래 상태바에 사전 아이콘이 나타나는데, 처음에는 회색으로 되어 있습니다. 한 번 클릭해주면 파란색으로 돌아오는데, 이때가 활성화된 모드입니다. 파란색인 상태에서 영어 단어를 고르면 팝업이 떠서 단어의 뜻을 알 수 있습니다. 기능이 필요 없으면 사전 아이콘을 한 번 더 눌러서 끄면 됩니다.




뭐 어디 공개하기는 부끄러운 프로그램이라 제 블로그에만 올려둡니다.

이거 만들었다는 얘기를 하고 싶은 게 아니고, Firefox Extension 제작의 어려움(?)을 토로하고자 합니다. 결론부터 말하면 생각보다 쉽지 않더군요. 일단 모질라 사이트가 언뜻 보면 방대한 문서가 있는 것 같은데, 처음 접하는 사람이 체계적으로 접근하기가 어려웠습니다. API 문서도 생각보다 정리가 안 되어 있어서 찾아보기가 상당히 어렵더군요.

Firefox를 비롯한 Mozilla 소프트웨어들은 전부 XPCOM이라는 컴포넌트 기술에 기반하고 있는데, 이 컴포넌트를 자바스크립트에서 불러 쓰는 것도 상당히 귀찮은 일이더군요. jsLib이라고 이걸 좀 간단하게 만들고자 노력한 라이브러리도 있지만 많이 부족해 보였고요.

또 스크립트 언어 특유의 '타이핑 실수'로 인한 버그를 잡아내는 게 무척 힘들었습니다. 뭔가 사소한 이유로 안 되는 것 같은데 뭐가 문제인지 몰라서 한참을 헤매게 되더군요. 물론 콘솔에 오류를 찍게 할 수도 있고 자바스크립트 디버거들도 있지만 익숙하지 않아서 그런지...

XUL을 쓰던 안 쓰던 UI 같은 건 WYSWYG으로 딱딱 보이는 게 좋은데라는 아쉬움도 들었고요. 애드온 개발을 위한 좋은 개발 환경 셋팅에 대해서 잘 아시는 분 도움을 부탁드립니다.

야후 위젯(Yahoo Widget!)과 애플의 대시보드(Dashboard), 윈도 비스타의 가젯(gadget) 등 위젯 서비스가 줄을 이으면서, 국내에서도 네이버, 미니플, 다음(나온 순서대로) 등이 위젯 서비스를 시작했다. 주로 날씨, 달력, 메모, 메신저, 시계, 증권 등 위젯하면 생각나는 프로그램이 주종이다. 네이버나 다음은 자사가 가지고 있는 메일, 까페, 검색 등의 서비스를 추가로 제공하기도 한다.

국내 위젯 서비스를 둘러보니 외국 위젯 서비스의 미투(me too) 서비스인 것은 분명한데, 한 가지 큰 차이가 있었다. 외국 위젯 서비스들은 사용하기 편한 여러 위젯을 제공하는 동시에, 사용자들이 필요한 위젯을 쉽게 만들 수 있도록 플랫폼(API+개발도구)를 제공한다. 반면에 국내 위젯 서비스는 엔진을 설치한 후에 자사가 제공하는 위젯을 설치할 수만 있을 뿐 사용자 위젯을 추가적으로 만들 수 있는 방법을 제공하지 않고 있다.

네이버나 다음의 경우 홈페이지를 둘러봐도 향후 위젯 제작을 오픈하겠다는 말이 없었다. 반면에 미니플은 최근에 3.0 오픈베타를 발표하면서 앞으로 ‘유무선 통합 플랫폼’을 추구한다고 한다. 즉, 미니플을 PC, PDA, WIBRO, IPTV 단말기 등 여러 플랫폼에 집어 넣는다는 말이다. 하지만 향후 공개하겠다는 말이 있을 뿐 플래시 기반이라는 사실 외에는 그 내부 구조가 어떻게 되어있고 어떤 API를 제공하겠다는 건지는 알 수가 없었다.

네이버나 다음이 내부적으로 어떤 기술 사용했는지는 모르겠지만, 야후 위젯이나 대시 보드, 오페라 위젯 등은 대부분 유사한 기술에 바탕을 두고 있다. 보통 위젯은 다음 세 가지 요소로 구성된다.

1) XML이나 HTML 형식으로 UI의 구조를 정의
2) UI에 액션을 줄 수 있는 스크립트(주로 자바스크립트)
3) UI에 멋진 모양을 낼 수 있는 스킨(보통 CSS)

예를 들어, 오페라 위젯은 HTML에 자바스크립트, CSS를 사용하여 일반 웹프로그래밍과 가장 유사한 환경을 제공한다. 다른 위젯들도 HTML 대신에 UI 구조를 위해 자체적으로 정의한 XML을 사용할 뿐 위젯 어플리케이션을 구성하는 근본적인 기술은 상당히 유사하다. (이 부분은 UI를 위해 XUL을 사용하는 Firefox의 Extension도 마찬가지다.)

국내 위젯사들이 이 정도나마 플랫폼 형태를 갖추고 있는지, 아니면 정말 위젯 하나 하나를 정성스러운 손길로 수제작하는지는 알 수가 없다. 물론 수제작이 나쁘다는 건 아니다. 그건 어디까지나 회사의 전략이니깐. 사실 국내에만 한정 지을 경우 API를 오픈한다고 해서 얼마나 많은 개발자들이 위젯을 개발해 줄지는 의문이기도 하다. ‘플랫폼’으로 절대적인 기술 우위를 점하지 않는 한 위젯 제공사들은 플랫폼보다는 컨텐츠로서 위젯에 더 가치를 두는지도 모르겠고…

Douglas Crockford의 <JavaScript: The World's Most Misunderstood Programming Language>를 번역하였습니다. <JavaScript: 세상에서 가장 오해가 많은 프로그래밍 언어>를 눌러주세요.

요즘은 JavaScript를 가장 많이 쓰고 있는데, 요즘이야 Prototype, dojo, jQuery, Mochikit, YUI 등 3 세대 Ajax 라이브러리가 쏟아져 나오면서 인식이 많이 달라졌지만, 예전에는 초보자들이나 쓰는 프로그래밍 언어 같지 않은 간단한 스크립트라는 인식이 강했던 것이 사실이었죠. 이 글은 Ajax가 유행하기 전에 JavaScript에 대한 그런 오해를 불식시키고자 작성된 글입니다.

최근에 웹 서비스 쪽 개념들을 조금 살펴보고 있는데 새로운 약자들에 익숙해 지려니 시간이 좀 걸리네요. 특히 WSDL, SOAP 등 복잡한 XML 기반의 명세서들을 보고 있노라면 명세서만 보다가 세월 다 갈지도 모른다는 불안감이 엄습해 옵니다.

이미 2003년도의 글이지만, Tim O'Reilly의 글을 보면 아마존에서의 SOAP과 REST 사례를 들고 있습니다. 아마존이 두 가지 인터페이스를 다 제공했는데 결과적으로 간단한 REST (XML over HTTP)가 85%의 점유율을 보였다는 거죠. (지금 상황은 어떤지 확인은 안 해봤습니다.)[1]

예전에는 우수한 기술이 성공한다는 생각이 강했는데, 요즘은 진입 장벽이 낮고 많은 개발자들이 쉽게 이해해서 전파할 수 있는 기술이 가장 우수한 기술이라는 생각이 드네요. 많은 사람들이 참여할 수 있어야 그만큼 발전의 속도도 빠르고 결국은 복잡한 기술을 앞지르게 되는 것 같습니다. 동적인 언어도 그렇고, Rails 같은 웹프레임워크도 그런 사례이죠. 반대로 분산 시스템의 핵심적인 표준이었지만 너무 어려워서 아무도 제대로 못 쓰던 CORBA도 있습니다.

[1] SOAP, WS-* 등의 기술과 HTTP+POX (Plain Old XML) 대결 구도네요. 복잡한 EJB에 대항해서 POJO가 나온 것과 비슷한 대결 구도입니다. 어떤 기술이 너무 복잡해 지면 PO(Plain Old)라는 대항마가 나타나는 게 아닐까 싶습니다.

자바 7에 추가될 자바 언어 관련 변화로는 클로저 지원이 있습니다. 클로저는 이미 함수형 언어에서는 보편적으로 쓰이고 있고, 루비에서도 코드 블록(code block)이라는 이름으로 지원되고 있는 언어 기능입니다. 이와 관련하여 클로저 명세를 주도하고 있는 Neal Grafter가 발표한 <Advanced Topics In Programming Languages: Closures For Java>를 구글 비디오를 통해 보았습니다.

Grafter의 강연에 따르면 자바의 클로저 지원도 자바 제네릭스와 마찬가지로 컴파일 타임에 모두 이루어지며, 내부적으로 익명 내부 클래스(anonymous inner class)를 사용하고 있습니다. 다만 익명 내부 클래스는 예외 처리, final 외에 지역 변수를 받는 방법, return 문 지원 등과 관련하여 제약 사항이 있는데, 이를 클로저에서 해결하는데 복잡한 이슈가 있다고 하네요.

위 강연 비디오는 1시간 50분 정도로 꽤 길긴 한데, 자바 클로저의 요구사항과 해결 방법을 아주 명쾌하게 설명하고 있어서 좋더군요. 더불어 클로저를 지원했을 때 JDK API가 어떻게 변화하게 될지에 대해서도 이야기하고 있습니다. 좀 더 관심 있으신 분은 현재 논의 중인 자바 클로저 명세서(Closures for the Java Programming Language)도 참고하시기 바랍니다.

강연을 보면서 받은 느낌은 JDK를 통해 구현된 API(예를 들어 Collection 클래스에 map이나 reduce 함수 등을 추가)를 사용하는 것은 간단하지만, 직접 클로저를 사용하는 메서드를 구현하기는 상당히 까다로울 것으로 보입니다. 이 부분은 JVM을 고치지 않고 어떻게든 컴파일러로 모두 처리하려고 노력한 제네릭스랑 상당히 유사한 면이 있습니다. 또한 lexical scoping하는 요소가 변수 밖에 없는 Scheme과 같은 언어와 달리 생각해야 할 요소가 많아서 사용자 입장에서는 별로 직관적이지 않은 구현이 될 수 밖에 없는 부분이 있고요.

저는 작년 12월부터 IEEE에서 <IEEE Software Magazine>과 <IEEE Transactions on Software Engineering>를 구독했습니다.

사실 학교 도서관을 통해서 원하는 글은 얼마든지 구해서 읽을 수 있지만, 정기적으로 인쇄되어 나오는 잡지를 구독하지 않으면 잘 안 보게 되더라고요. 비록 43달러의 거금이 들기는 하지만 꾸준히 잘 읽으면 소프트웨어공학의 최신 경향도 파악할 수 있고 여러모로 좋겠다는 판단을 내렸습니다. 현재 회사에서 <CACM>을 구독하려고 생각 중이기도 하고요.


그런데 IEEE 분들이 친절하게 공짜로 껴주는 잡지인 <IEEE Spectrum>은 꼬박꼬박 챙겨서 보내줬는데, 정작 돈 내고 구독한 잡지를 안 보내주네요. 오늘 고객 서비스에 연락해서 다시 보내달라고 요청하기는 했는데, 뭔가 쉽게 풀리는 일이 없군요. 이 외에도 소프트웨어 개발 관련해서 구독하면 좋을 괜찮은 잡지로는 또 뭐가 있을까요?

루비에서 변수 생성에 대한 규칙을 잘못 알고 있었다.


처음 irb를 동작시키면 a라는 변수(혹은 메쏘드)가 정의되어 있지 않으므로 undefiend local variable or method 'a'라는 에러 메시지를 출력한다. 다음으로 실행한 구문은 a = 1 if false이다. if false는 무조건 거짓이므로 a = 1은 절대로 실행되지 않는다. 문제는 다음 행이다. 직관적으로 판단하기에 a = 1이라는 대입(assignment)가 일어나지 않았으므로 a는 여전히 undefiend 일 것이라 생각했지만, 예상과는 달리 a = nil이다.  즉 루비는 a = 1이 대입이 일어나야만 a 변수를 생성해 주는 것이 아닌 것이다. 프로그램을 차례대로 읽으면서 조건에 상관없이 a가 변수로 사용되었음을 알았기 때문에 그 후로는 a를 정의해 준 것이다.

로컬 변수와 메쏘드를 구분하는 것도 마찬가지이다. 다음은 "Programming Ruby: The Ruby Language, Variable/Method Ambiguity"에서 따온 예제이다.


결과



위 예제는 a가 함수로도 사용될 수 있고, 변수로도 사용될 수 있음을 보여준다. a = 1 구문을 지나고 나면 a가 변수임을 알고, 변수로 호출한다. i == 2인 경우 이미 a에 1라는 변수가 할당되어 있지만 앞쪽에 나와있기 때문에 a = 1이라는 대입이 있었음을 알지 못한다. 따라서 이 경우 a를 메쏘드로 가정하는 휴리스틱을 사용한다.

다음과 같이 i == 1 조건이 먼저 나오면 어떨까?


이 경우 a = 1 대입은 i == 1인 조건에만 있지만, 이 조건이 else 구문보다 앞서 있기 때문에 둘 다 a를 변수로 인식하고 1을 출력할 것이다.

오늘 루비로 회사 소스 저장소를 백업하는데 쓸 간단한 스크립트를 만들었습니다. 루비 파일 한 개로 된 간단한 프로그램이라 패키징 할 필요도 없지만 루비용 패키징 도구인 RubyGems를 사용해 볼 생각에 gem 파일로 만들어보았습니다. 리눅스 프로그램 패키징에 사용되는 RPM이나 DEB의 스펙 파일과 유사할 것이라 생각했는데, RubyGems은 스펙 파일도 실행 가능한 루비 스크립트더군요. 스펙 자체를 실행할 수 있는 모델이라는 게 재미있었습니다. 다음은 제가 작성한 sysadmin의 스펙 파일입니다.



패키지에 포함될 파일을 files 속성에 정의해주는데, Dir.glob 메쏘드를 사용해 bin 이후 모든 파일을 집어 넣습니다. 또한 bindir 속성과 executables 속성을 지정해주면, 여기에 지정된 파일은 설치 시에 자동으로 /usr/bin 디렉토리에 복사해줘서 실행 가능하게 만들어 주더군요. add_dependency를 이용해서 간단하게 필요한 패키지의 의존성을 표시해줄 수 있고요. 위 스크립트를 실행시키면 Gem::Builder.new(spec).build 부분에서 gem 파일을 생성해 줍니다.

저는 학부 1학년 때 리눅스를 배우면서 vim을 사용한 이후로 Eclipse 같은 IDE를 쓰는 경우가 아니면 대부분의 프로그램을 vim으로 작성하고 있습니다. C 언어로 임베디드 환경에서 코딩하던 예전에는 별로 불편함을 느끼지 못했는데, 요즘 HTML, XML 등 각종 구조화된 문서나 스크립트 언어 등을 작성하려니 불편하다는 생각이 많이 드네요.


최근에 Ruby on Rails나 여러 데모 동영상을 보면 주로 맥이 많이 나오고 텍스트 에디터로는 textmate라는 프로그램이 자주 등장하더군요. 특정 언어에 특화된 IDE 도구가 아님에도 불구하고 강력한 매크로를 바탕으로, HTML 문서나 루비 프로그램 작성 시에 놀라운 자동 완성 기능을 보여줍니다. 불행히도 윈도나 리눅스 버전을 제공하지 않네요.

여기에 한글로 된 정보가 있습니다.












다음은 또 다른 스크린샷입니다.

서울대 컴퓨터공학부에서 세미나 강의 동영상을 올려뒀네요.

여러 교수님들이 다양한 주제로 강연하신 것들을 녹화해뒀는데 아직 자료가 많지는 않지만 앞으로 이런 자료가 많이 올라오면 좋겠다는 생각을 해봅니다. 학교 떠나고 나면 지금 나오는 최신 기술에 치여서 정작 이론적인 배경이나 앞으로 발전 방향에 대해 무뎌지는 듯한 느낌을 많이 받거든요.