요즘 IT 아키텍처의 미래로 각광받고 있는 개념이 SOA(Serviced-Oriented Architecture)입니다. 김국현 님이 SOA에 대해 쓰신 컬럼인 <테크놀로지가 서비스 정신을 가질 때>를 읽어보면 SOA의 특징을 다음과 같은 어구들로 묘사하고 있습니다.

루즈 커플링(loose coupling), 인터페이스(interface), 재사용성(reuse), 모둘화(modularization), 호환성(compatibility), 변화에 대비(aniticipation of change) ...

하지만 이런 어구들은 SOA 이전에도 소프트웨어 공학의 각종 기술이 항상 추구해왔던 좋은 소프트웨어의 특성이자 원칙일 뿐입니다. 예컨대 객체지향설계론이나 컴포넌트 기반 기술들도 결국 SOA와 똑같은 이상을 추구했던 것이지요. SOA가 이런 기술들과 차별화되는 것은 웹서비스(web service)라는 구체적인 실천론을 바탕으로 하고 있다는 점과, 각자 자기 기술만을 팔던 마이크로소프트, IBM, 썬, 오라클 등의 주요 IT 기업이 하나 표준안에 동의했다는 사실 정도일 것입니다.

크리스마스를 계기로 블로그 개편을 하려고 마음 먹고 어떤 일을 하면 좋을까 오랜 기간 생각을 해봤습니다. 고민 끝에 떠오른 아이디어 중에 하나는 매주 2-3개 정도 오픈소스 프로젝트를 소개하는 것입니다. 잘 알려진 프로젝트를 좀 더 깊이 있게 다룰 수도 있고, 아직 잘 알려져 있지 않지만 가능성 있는 프로젝트를 많은 분들에게 소개하는 계기가 될 수도 있을 것 같습니다.

범위를 모든 오픈소스 프로젝트로 잡으면 너무 광범위해지는 것 같아서 일단은 개발자들이 알아두면 좋을 오픈 소스 라이브러리와 개발 보조 도구를 위주로 해볼까 합니다. 개발을 하다 보면 열성 개발자일수록 필요한 것은 모두 만들어 쓰자는 NIH(Not-Invented-Here) 신드롬에 빠져서 매번 바퀴를 재발명하는 낭비를 하는 경우가 많은데, 평소에 괜찮은 오픈소스 라이브러리를 많이 알고 있다면 확실히 개발 생산성을 향상시키는 데 많은 도움이 되거든요.

첫 오픈소스 프로젝트로 어떤 프로젝트를 선정할지 잠시 고민 후에 연말 안에 첫 글을 올리겠습니다^^.

최근 영회님이 마틴 파울러(Marin Fowler)의 글을 옮겨 놓으신 <소프트웨어 개발자와 큰 화면>을 보고 제가 읽은 글도 정리해서 올려봅니다.

마이크로소프트 리서치(Microsoft Research, 이하MSR)의 수잔나 로스(Suzanne Ross)는 <Two Screens Are Better Than One>이라는 글에서 듀얼모니터의 생산성 향상 효과를 이야기하고 있습니다. 연구는 VIBE(Visualization and Interaction for Business and Entertainment) 그룹에 의해서 수행되었는데, 디스플레이 공간이 늘어날수록 작업 효율이 증가한다는 결과가 나왔습니다. 모니터를 한 대(혹은 두 대) 추가하면 생산성이 9-50% 향상된다고 합니다.

작업 효율이 향상되는 이유는 단기 기억력과 관련이 있습니다. 단일 모니터에서 창을 바꿔가며 어떤 작업을 수행했을 때에 비해서 큰 화면에서 여러 가지 작업을 공간적으로 나눠 수행하면 공간과 작업이 연동되어 기억력을 높여주는 효과가 있다고 하는군요. 간단한 예로 에디터로 코딩 중에 API 문서를 찾아봤을 경우 API 문서가 코딩하던 창을 가리면 왜 이 API를 찾아봤는지 쉽게 잊어버리는 반면에 창을 옆에 두고 찾아보면 둘 사이의 연관 관계가 더 오래 쉽게 기억되는 것입니다.

이 외에도 남녀의 신체적인 특징 때문에 남자보다 여자가 큰 화면의 도움을 더 많이 받는다는 이야기도 있고, 여러 개의 화면을 어떻게 부드럽게 이동시킬 것인지, 마우스 커서를 잃어버리지 않으려면 어떻게 해야 할지 등 재미있는 이야기가 많이 나옵니다. 마지막에는 미래의 모니터는 어떻게 될 것인지 예상하는 부분도 있고요. 관심 있는 분은 로스의 글을 읽어보시기 바랍니다.

정리하면, MSR에서 수행한 조사인 만큼 OS도 이런 요구사항을 적극 반영해야 한다는 것이 글의 논지입니다. 최근 윈도 비스타가 와이드 스크린을 기본 사양으로 삼은 것도 이런 배경이 있었던 것 같습니다. 소프트웨어 공학과 여러 방법론, 프레임워크 등이 프로그래머의 생산성을 논하지만 가장 쉽고 빠르게 생산성을 높이는 방법은 의외로 큰 모니터를 여러 개 지원하는 것인지도 모릅니다. 의식 있는 소프트웨어 개발 회사라면 개발자들에게 듀얼모니터를 지급할 것을 강력하게 촉구합니다.

참고로 저는 얼마 전에 모니터를 한 대 더 구입하여, 22인치 와이드 LCD를 메인으로, 서브로 19인치 LCD를 사용하고 있습니다. 정말 생산성이 달라집니다. 여러분도 느껴보세요.

ACM Queue에 올라온 Brian Carpenter의 Better, Faster, more Secure을 읽고 정리하는 글입니다.

인터넷의 가장 큰 장점이자 단점은 단일화된 표준 기구가 없다는 사실입니다. 인터넷 초창기에는 주로 IETF(Internet Engineering Task Force)가 표준을 주도했지만, 인터넷이 질적 양적 팽창을 하면서 웹 표준을 재정하는 W3C를 비롯해 IESG, IAB, IRTF, IANA, ETSI, ICANN, ITU 등 각종 표준협회가 난립하게 됩니다.

Carpenter가 기술한 것처럼 인터넷의 목표는 크게 네 가지로 이야기할 수 있습니다.

1) 범용적인 연결성을 보장한다.
2) 어플리케이션은 엔드 시스템에서 수행한다.
3) 네트워크 값싸고 멍청하다.
4) 자연 선택설을 지지한다.

특히 자연 선택설은 각종 인터넷의 발전 모델을 대변합니다. IETF에는 매년 1400개의 표준 초안(draft)이 올라오고 그 중 300개 정도가 IETF의 RFC(Requests for Comment)가 됩니다. 이 중에서 10년 안에 쓰일만한 명세는 100개 정도이므로, 처음 제안된 1400개 중 7%만이 실용적인 의미를 갖게 됩니다. 바꿔 말해서 93%는 쓸 데 없는 시간 낭비가 된 셈이지요.

덕분에 인터넷 기술의 변화는 예측하기 힘든 면이 있습니다. 일반적인 경우 힘있는 중앙 기관이 밀어붙이는 표준은 반드시 채택되기 마련이지만, 인터넷은 중앙 통제 없이 독립적으로 발전하고 그 중 변화하는 환경에 가장 잘 맞는 표준만 살아남는 방식이기 때문입니다. 기업 입장에서는 어떤 기술을 뜰지 예측하고 준비하는 데 상당한 노력을 들여야 함을 의미하게 되고요.

하지만 덕분에 인터넷은 창의적인 기술을 실험할 수 있는 실험이 장이 될 수 있었습니다. 위 글에서 인용한 것처럼 비행기가 나는 도중에도 엔진을 고치는 창의성이 인터넷의 특징이라 할 수 있겠죠.

자선웨어(careware 혹은 charityware)는 사용자에게 비용을 청구하는 대신 자선단체에 기부를 부탁하는 소프트웨어입니다. 대표적인 자선웨어에는 UNIX 개발자들에게 친숙한 에디터인 Vim이 있습니다. Vim을 실행하면 우간다의 어린이를 도와달라는 문구를 볼 수 있습니다. vim은 ICCF Holland라는 기관을 통해 우간다 어린이의 HIV 치료를 돕고 있습니다.



소프트웨어를 오픈 소스로 만들고 많은 개발자들과 나눈 것 자체로 이미 인류에 큰 기부를 한 셈이지만, 부가적으로 자선단체를 통해 세상을 도울 수 있다는 생각이 참 마음에 듭니다. 저 역시 오픈소스 프로젝트를 하게 되면, 이렇게 자선웨어 형태로 더 좋은 세상을 만드는 데 조금이나마 도움이 될 수 있지 않을까 생각해 봅니다.

컴퓨터 공학 혹은 관련 학과를 전공하고 IT 업계로 뛰어들면 하루가 다르게 늘어나는 신기술을 접하느라 정신이 없습니다. 예를 들어 웹 개발 쪽에 종사한다면 루비, 레일즈, CSS 2.0 등의 경향을 파악하는 데도 시간이 넉넉하지 않을 것입니다. 억지로 시간을 만들어서 컴퓨터 공학의 기초를 다시 다지고 싶어도 학교가 아닌 이상 어떤 학문을 체계적으로 배운다는 것은 어려운 일입니다.

하지만 학교를 다니지 않아도 학교 수업을 들을 수 있는 방법이 있습니다. 그것도 컴퓨터 공학으로 유명한 대학의 전공 프로그램을 말이죠. 일례로 와싱턴 대학교(University of Washington)의 컴퓨터공학과는 전문석사과정(Professional Masters Program)의 강의 동영상과 강의 자료를 일부 제공하고 있습니다. 와싱턴 대학은 마이크로소프트 본사와 가까운 시애틀에 위치한다는 지리적 강점 때문에 MS의 전폭적인 지지로 CS 미국 탑 10에 드는 대학입니다. 전문석사과정은 전일제 대학원생이 아닌 MS를 비롯한 각종 IT 기업에 다니고 있는 개발자들을 위한 교육 프로그램입니다.

매년 개설되는 수업은 다음과 같습니다.

- 컴파일러
- 소프트웨어 공학
- 프로그래밍 언어
- HCI(Human Computer Interaction)
- 응용 알고리즘
- 병렬 계산(Parallel Computation)
- 데이터베이스
- 트랜잭션 처리
- 데이터 마이닝
- 컴퓨터 아키텍처
- 운영체제
- 그래픽스의 최신 경향
- 네트워크 시스템
- 디지털 시스템 설계 및 구현
- 응용 인공지능
- 컴퓨터 비전
- 분산 시스템
- 컴퓨터 애니메이션
- 계산 생물학
- 실용적 암호학
- 복잡성 이론
- 대안 컴퓨팅 이론

평소 관심있던 분야를 골라서 강의 동영상을 보는 것도 좋은 자기 계발이라 생각합니다 :) 이와 비슷한 다른 좋은 자료가 있으면 정보 공유 부탁드립니다.

■ WIPI 플랫폼 포팅의 일반적인 문제점

일반적인 응용 프로그램을 WIPI 플랫폼에 이식하는 데는 여러 가지 어려움이 따른다. 포팅의 어려움은 기존 플랫폼과 WIPI 플랫폼의 차이에서 기인하는데, 그 이유로 (1) 멀티 쓰레드 지원의 부재, (2) 컴팩션 하는 메모리 사용을 들 수 있다.

(1) 멀티쓰레드 지원이 없다.

WIPI-Java는 자바 언어(java.lang.Thread 클래스)를 통해 멀티쓰레드를 제공하는 데 비해서 WIPI-C는 멀티쓰레드를 지원하지 않는다. 따라서 멀티쓰레드로 작성된 프로그램을 WIPI로 옮기기 위해서는 많은 수정이 필요하다.

(2) 컴팩션(compaction)하는 메모리를 사용한다.

WIPI에서 동적으로 할당된 메모리의 컴팩션을 지원한다. 따라서 MC_knlAlloc(), MC_knlCalloc(), MC_knlFree()는 포인터가 아닌 메모리 식별자(ID)를 사용한다. MC_GETDPTR(mID)를 사용하면 메모리 식별자를 통해 메모리 포인터를 얻어올 수 있다. 메모리가 컴팩션이 일어나면 식별자를 통해 얻어온 포인터가 더 이상 유효하지 않을 수 있으므로, MC_GETDPTR()를 호출해 포인터를 다시 얻어와야 한다.

컴팩션이 일어나는 경우는 (1) 미사용 메모리가 없는 경우와 (2) MC_knlGetFreeMemory() API를 호출했을 때, (3) 내부적으로 메모리를 할당하는 일부 API를 호출했을 때뿐이므로, 매번 포인터를 얻어와야 하는 번거로움은 피할 수 있다. 하지만 (1), (2), (3)의 경우로 컴팩션이 일어날 수 있는 API를 호출한 후에는 반드시 MC_GETDPTR()를 통해 포인터를 다시 얻어와야 한다.

일반적인 응용 프로그램은 malloc()/free()와 유사한 동적 할당을 사용하고 메모리 식별자가 아닌 포인터를 직접 얻어온 후에, 해제할 때까지 영구적으로 사용한다. 따라서 이런 프로그램을 WIPI 플랫폼으로 옮길 때는 수정이 필요하다. 수정은 보통 다음 2가지 방법으로 이루어질 수 있다.

첫 번째 방법은 포팅할 응용 프로그램의 메모리 할당 방식을 WIPI의 방식으로 변경하는 것이다. 이는 응용 프로그램의 코드를 상당히 많이 고쳐야 하는 문제가 있다. 두 번째 방법은 WIPI의 MC_knlAlloc() 혹은 MC_knlCalloc()을 이용해 큰 메모리 블록을 얻어온 후에(혹은 정적 메모리 할당 이용) 응용 프로그램 내부에서 malloc()/free()와 유사한 동적 메모리 관리 알고리즘을 구현해서 사용하는 것이다. 하지만 WIPI의 일부 API는 여전히 메모리 식별자를 인자로 요구하므로, 문제를 100% 해결할 수는 없다.



(1)에서 언급한 쓰레드 지원 문제는 WIPI-C의 구조상 쉽게 해결하기 힘들다. pthread와 유사한 쓰레드 라이브러리를 제공한다고 해도, 멀티쓰레드 프로그래밍은 WIPI의 메모리 모델과 충동하기 때문이다. 앞서 언급한 것처럼 WIPI는 컴팩션 메모리를 사용하고, 메모리 식별자로부터 포인터를 얻어와서 메모리에 접근한다. 기존의 단일 쓰레드 WIPI 프로그램의 경우 컴팩션이 일어나는 지점이 명확히 정의되어 있으므로, 메모리 포인터를 다시 얻어와야 하는 지점도 명확했다. 하지만 멀티쓰레드가 되면 프로그램 수행 도중 다른 쓰레드에 의해 언제든지 컴팩션이 일어날 수 있다. 따라서 메모리 포인터를 얻어올 때 다른 쓰레드가 컴팩션을 하지 못하도록 락(lock)을 잡는 일이 추가로 필요하다. 이렇게 되면 WIPI 플랫폼을 전반적으로 수정해야 하므로 적절한 방법이라 할 수 없다.

이렇게 되면 왠만한 프로그램을 WIPI로 가져오는 일은 절대 쉽지 않다는 사실을 알 수 있다.  WIPI에서 C언어 지원은 레거시 코드(legacy code)를 잘 가져와서 쓰자는 데 있다. 하지만 WIPI-C 플랫폼이 임베디드라는 특수한 환경을 고려하면서 둔 몇 가지 제약 사항이 이식성을 상당히 희생시켰다. 덕분에 모바일 환경에서 C 언어를 지원하려고 했던 원래의 취지와는 잘 맞지 않게 된 것은 아닐까?

[reshout님을 비롯하여 플러그인 모델(Plug-in Model)에 대한 글을 읽다가 생각을 정리해봅니다.]

파이어폭스(Firefox), 야후 위젯(Yahoo Widget!), 이클립스(Eclipse), 구글데스크톱(Google Desktop) 등의 공통점은 무엇일까요? 각자 성격과 규모가 다른 소프트웨어 프로젝트이지만 한 가지 공통점을 가지고 있습니다. 그것은 바로 애드온 아키텍처(Add-on Architecture), 플러그인(Plug-in Architecture) 등으로 불리는 확장 지향의 소프트웨어 아키텍처에 있습니다!

흔히 인터넷 익스플로러와 비견되는 웹브라우저로만 알고 있는 파이어폭스의 가장 큰 경쟁력은 애드온(Add-ons) 기능입니다. 애드온을 이용하면 파이어폭스 사용자가 손쉽게 브라우저의 기능을 확장할 수 있습니다. 예를 들어 파이어폭스 기본 배포 버전은 마우스를 이용한 웹페이지 네비게이션을 지원하지 않고 있죠. 하지만 All-in-One Gestures라는 애드온을 설치하면 간단한 마우스조작 만으로 현재 북마크에 추가하거나, 새로운 탭을 열고, 웹 페이지를 앞 뒤로 옮겨갈 수 있는 기능을 얻게 됩니다.

KLDP 코드 페스트 행사에서 만나뵌 CN님 말씀에 따르면, 파이어폭스가 궁극적으로 원하는 방향 중에 하나는 파이어폭스의 렌더링 엔진인 게코(Gecko) 엔진과 XML을 이용해 사용자 인터페이스를 만드는 기술인 XUL 등을 브라우저에서 분리시켜 플랫폼화하는 것이라고 합니다. 이렇게 되면 파이어폭스나 썬더번드 등은 게코와 XUL을 이용한 하나의 어플리케이션이 된고, 분리된 게코 플랫폼(Gecko Platform)을 이용하면 파이어폭스 수준의 다른 어플리케이션도 손쉽게 제작할 수 있게 됩니다.

야후 위젯이 추구하는 방향도 비슷합니다. 야후 위젯은 간단하면서 유려한 데스크탑용 어플리케이션을 작성하는데 있어서 최적의 플랫폼이 되기를 희망하고 있습니다. 야후 위젯은 기존의 자바나 .NET 플랫폼과 달리 XML을 이용해 UI를 기술하고 프로그래밍 합니다. 즉 기존 플랫폼의 API를 한 단계 위의 끌어올려 간단한 데스크탑 용 어플리케이션의 경우 기존 플랫폼에 비해 훨씬 손쉽게 만들 수 있게 만든 것입니다.

재미있는 것은 확장성 높은 IDE 도구를 목표로 출발한 이클립스 역시 기존의 자바 플랫폼으로 해내기 힘든 리치 어플리케이션 플랫폼으로 진일보하였다는 점입니다. 자바 플랫폼의 부족한 UI 지원을 SWT로 메우고, 순수 자바로는 쉽게 만들 수 없는 데스크탑 용 어플리케이션을 쉽게 만들 수 있는 밑바탕을 제공하고 있습니다. 실제로 IDE와는 관련 없는 바이오클립스(Bioclipse), 이클립스트레이더(EclipseTrader) 프로젝트 등 이클립스를 플랫폼으로 삼은 여러 리치 클라이언트 어플리케이션(Rich Client Application)이 인기를 얻고 있습니다.

종합하면 현재 일부 어플리케이션은 고수준의 API를 제공하는 플랫폼 소프트웨어의 성격을 강하게 보이고 있고, 또 플랫폼화하기 위해 많을 애를 쓰고 있다는 점입니다. 이런 신생 플랫폼 간의 경쟁도 흥미롭고 자바와 닷넷(.NET)이 만들어온 플랫폼이 이런 도전에 어떤 식으로 응전할지도 기대가 됩니다.

우리가 객체지향 프로그래밍 언어(object-oriented programming language)라고 부르는 언어 패러다임은 크게 1) 클래스 기반과 2) 프로토타입 기반의 언어로 양분할 수 있습니다. 클래스 기반 객체지향언어는 C++, 스몰토크, 자바, 루비처럼 클래스를 통해 현실 세계를 모델링하고, 클래스에서 객체(인스턴스)를 찍어내서 프로그래밍하는 모델을 말합니다. 반대로 프로토타입 기반의 언어에는 자바스크립트(JavaScript)가 있는데, 별도의 클래스 없이 이미 존재하는 객체를 클론(clone)해서 프로그램을 작성하는 방법입니다.

프로토타입 기반 언어에 대한 일반적인 비판은 동적 타이핑 언어에 대한 비판과 닮아 있습니다. 정확성(correctness), 안전성(safety), 예측성(predictability), 효율성(efficiency) 등이 떨어진다는 것입니다. [위키피디아 참고] 클래스 기반 객체지향언어에서 클래스는 외부 세계를 모델링(modeling)하는 방법일 뿐만 아니라 프로그램의 정확성을 확인할 수 있는 타입(type)이기 때문입니다. 쉽게 풀어서, 루비의 Array 클래스가 sort라는 메쏘드를 가지고 있다는 사실 자체가 클래스 사용자와 클래스 사이의 계약이 되기 때문입니다. 반대로 프로토타입 기반 언어에서는 클래스가 없기 때문에 이런 계약 관계를 쉽게 알아보기 힘들게 됩니다.

빠른 프로토타이핑(prototyping)과 개발 속도를 위해서 정적 타입 시스템(static type system)이라는 안전망을 포기한 스크립트 언어가 대부분 클래스기반 객체지향언어라는 점은 약간 의아합니다. 상업적으로 유일하게 성공한 프로토타입 언어인 자바스크립트를 제외하면, 프로토타입 언어는 Self, Cecil, Io 등 연구용 언어가 대부분이기 때문입니다. 자바스크립트의 표준인 EcmaScript조차 클래스 기반 언어로 전환을 이야기하고 있다고 합니다.

저는 개인적으로 파이썬 루비 같은 범용적 스크립트 언어면서 프로토타입에 기반한 언어가 대두하지 않을까 하는 생각을 해보기도 합니다. 동적 타이핑(dynamic typing)이라고 하지만 실제로는 타입 시스템이 없는 것이나 마찬가지인 스크립트 언어에서 굳이 클래스 기반 언어를 고집할 이유가 없기 때문입니다. 물론 객체지향 모델링 방법이나 베스트 프랙티스 등이 모두 클래스 기반 언어를 중심으로 논의되어 왔고, 기존 개발자들이 프로토타입 기반 객체지향 언어에 익숙하지 않다는 문제점이 있기는 합니다. 하지만 현재의 스크립트스러움을 극단으로 몰고 가려면 클래스 보다는 오히려 프로토타입이 아닐까요?

동아일보에 올라온 "사라진 팀원들… 中-日, 한국서 무차별 인재사냥"이란 기사를 보면서 한국 IT 기업에 대해서 생각해 보았습니다. 최근에 구글이 한국 진출을 선언하고 무차별 인터뷰를 진행하면서 국내 포탈을 비롯한 대부분의 IT 기업의 핵심 인재들을 모두 만나보았다고 들었습니다. 국내 기업에서 인정 받고 있는 상당수의 개발자가 서로 쉬쉬하면서 구글에 면접을 본 것으로 알고 있습니다.

구글이 워낙 뜨고 있는 회사이기 때문에 구글의 러브콜을 무시할 수는 없었겠지만, 한국 내에서 사업 계획도 조직 규모도 각 개인에 대한 대우도 정해지지 않은 상태에서도 불러만 준다면 구글로 가겠다는 개발자가 줄을 서고 있는 한국 IT 기업의 현실이 조금 안쓰럽습니다. 결국 구글 정도의 회사가 한국에 들어오면 한국 IT 기업들을 경쟁도 해보기 전에 핵심 인재들을 모두 빼앗기고 싸워보지도 못하고 주저 앉는다는 이야기가 되는 거니깐요.

하지만 반대로 생각하면 이런 식의 자극이 지속적으로 필요하다는 생각이 듭니다. 다른 회사로 빼앗길 가능성이 있어야 인재라는 생각으로 제대로 된 대우를 해줄 테니깐요. 구글을 비롯한 여러 외국계 회사들이 들어와서 국내 IT 기업을 좀 더 흔들어 놓으면 개발자들에 대한 처우는 더 좋아질 수도 있다는 생각이 듭니다.

Economist.com에 <Hasta la Vista>라는 제목으로 윈도 비스타에 대한 글이 올라왔습니다. Hasta la Vista는 "잘가, 안녕"이라는 뜻인데 윈도 Vista의 Vista와 같은 발음이 들어있어서 제목 자체가 유머러스하군요. 글 내용을 정리하자면 다음과 같습니다.

윈도 비스타를 구매해야 하는가? 윈도 XP 이전 사용자라면 컴퓨터를 업그레이드하지 않더라도 구매를 고려해봐야 한다. 하지만 새로 출시된 프로그램은 버그 투성이일 가능성이 높으므로 당분간 구매를 보류하라.

사실 윈도 XP도 서비스팩 2 이후에야 완전히 안정화되었다고 할 수 있죠. 소프트웨어 버그는 통계적으로 100 줄에 1개 정도 발견되는데, 5천만 라인의 윈도 비스타의 경우라면 테스트 단계에서 90%의 버그를 제거했더라도 여전히 버그투성이 거대 소프트웨어(bloated software)일 가능성이 크다라는 것입니다.

하지만 소프트웨어 크기(코드의 LoC)만으로 윈도의 복잡성을 비난하는 것은 옳지 않다고 합니다. 윈도가 5천만 라인이라지만, 리눅스 커널은 이미 9백만 라인이고 데비안 3.1 배포판은 2억 천3백만 라인의 거대함을 자랑하고 있으니깐요. 다만 리눅스처럼 UNIX 계열의 전통을 물려받은 OS는 필요 없는 기능은 빼버리고 사용할 수 있는 옵션을 제공한다는 점이 다르겠죠. 물론 어디까지나 숙련된 사용자에 한해서이지만 말입니다.

윈도의 성공 공식은? 윈도 운영체제는 OS 자체의 복잡성과 안전성, 보안성 등 여러 가지 이유로 비난받고 있지만, 그래도 윈도의 성공 공식은 변하지 않았다. 코드는 복잡해지더라도 대부분의 사용자에게 사용의 편리함을 제공하는 것이 윈도의 목표이다. 윈도가 세상을 지배한 이유는 여기에 있다.

결국 비스타가 여러 가지 이유로 비난을 받고 있어도, 비록 맥 OS X를 흉내낸 것이더라도 이전 윈도에 비해 더 쉽게 사용할 수 있는 운영체제가 된 것만은 분명하지 않을까요?

마감이 쫓기다가 겨우 마소 1월호 원고를 마감했습니다. 1월의 주제는 "포팅의 어려움"입니다.

우리가 일상적으로 사용하는 소프트웨어의 상당수는 윈도, 리눅스, 맥 OS X 등 다양한 플랫폼에서 동작하고 있다. 자바가상머신에 의해서 처음부터 멀티플랫폼(혹은 크로스 플랫폼이라고 불림)을 보장받는 자바 어플리케이션뿐만 아니라, 일반적인 C/C++ 프로그램도 여러 플랫폼을 지원하는 경우가 드물지 않게 되었다. 일례로, 대표적 웹브라우저인 파어어폭스(Firefox)는 윈도, 맥OS X, 리눅스 세 가지 버전을 동시에 배포하고 있다. 과거에는 멀티플랫폼을 지원하는데 드는 노력에 비해 추가적으로 얻을 수 있는 사용자 수가 적었기 때문에, 멀티플랫폼 지원은 막연한 환상에 그쳤다. 하지만 근래의 소프트웨어 기술의 발전 덕분에 멀티플랫폼 소프트웨어는 작은 비용으로 조금이라도 많은 사용자를 확보할 수 있는 수단이 되고 있고, 덕분에 많은 개발자들이 관심을 가지게 되었다. 이 글에서는 멀티플랫폼 소프트웨어 작성의 근간이 되는 포팅 레이어(porting layer)에 대해 살펴보자.

포팅 레이어의 예로

1) CDC JavaVM의 HPI(Host Programming Interface)
2) 아파치 웹서버의 APR(Apache Portable Runtime)
3) WIPI의 HAL(Hardware Abstraction Layer)

을 소개하고 있습니다.

Having surveyed Ruby Virtual Machine, I found the YARV project. YARV stands for 'Yer another Ruby VM'. Actullay the project was initiated in 2004 by a smart Japanese programmer named SASADA Koichi. The latest version is still 0.4.1, but I think this it the way to go because the current implementation of Ruby is really slow. However, I couldn't find much information on YARV except for a few presentation slides in YARV homepage. Most of discussions have been done in Japanese language. Do we need to learn Japanese to learn Ruby?

컴퓨터공학과 학생들은 어떤 수업을 듣던지 적으면 1-2개에서 많은 5-6개의 프로그래밍 프로젝트를 하게 됩니다. 이런 프로젝트를 하면서 아쉬웠던 점은 프로그래밍 프로젝트의 명세서가 명료하지 못하고 나중에 어떻게 평가할지(테스트할지) 전혀 고려하지 않고 있다는 것입니다. 다음은 포항공대 컴퓨터공학과 네트워크 수업에서 네 번째 프로젝트로 나온 라우팅 프로토콜(routing protocol) 구현 프로젝트입니다.



프로젝트의 목표는 네트워크 수업 시간에 배우는 대표적 라우팅 알고리즘 2가지(Link State Algorithm, Distance Vector Algorithm)를 구현하는 것입니다. 프로젝트를 읽어보면 아시겠지만 이걸 학생들이 각자 마음대로 구현했을 때 조교 입장에서 학생들의 프로그램을 조직적으로 테스트할 방법이 거의 없습니다. 직접 찾아가서 데모 형태로 보여줘야 하고, 데모를 해도 제3자의 입장에서 해당 프로토콜이 정말 제대로 동작하는지 알기가 어렵죠.

반대로 교환학생으로 메릴랜드에서 수업을 들을 때는 달랐습니다. 그들은 프로젝트를 내주기 전에 해당 프로젝트에 대한 테스트 케이스를 작성하고, 어떤 부분들을 평가할 것인지는 명료하고 정확하게 제시합니다. 학생들이 프로젝트를 제출하면 미리 작성된 테스트 케이스를 돌려보고 곧바로 점수를 매겨줍니다. 어떤 과목은 이 과정까지 자동화해서 웹으로 프로젝트를 작성해서 제출하면, 곧바로 어떤 테스트 케이스를 통과했고 실패했는지까지 일목요연하게 보여주더군요.

조금만 신경쓰면 아주 멋진 프로젝트를 내줄 수도 있을텐데 조금 아쉽네요 :(

12월 23일 열리는 코드 페스트 행사에 참가하게 되었습니다. 잘 모르시는 분들을 위해 간략히 소개를 하자면, 코드 페스트는 오픈 소스 사용자와 개발자들이 한 자리에 모여서 프로그래밍, 번역, 토론 등을 자유롭게 진행하는 행사입니다. 2004년 10월에 처음 시작해서 이번에 개최되는 코드 페스트가 8회라고 하니 이제 어느 정도 자리가 잡힌 행사라고 할 수 있습니다.

하지만 크리스마스 이브를 하루 앞 둔 연말이라 그런지 참석자가 저조해서 연말 모임으로 축소화되었다네요.  코드 페스트 8 비공식 연말 모임으로 대체에 공지가 떴습니다. 처음 참석하는 오프라인 행사인지라 되도록 많은 분들을 볼 수 있었으면 했는데 아쉬운 마음이 듭니다.

행사에 가서 어떤 일을 할지 고민하던 차에, 권순선 님이 제 블로그에서 번역 도서 <완벽한 보안을 위한 C와 C++ 코딩>을 보시고는 안전한 코딩법에 대한 세미나를 부탁하셨습니다. 오픈 소스에 관련된 행사인 만큼 오픈 소스 보안 분석 도구들을 중심으로 소개해 보려고 합니다. 참석하시는 분들 계시면 그날 뵙고 인사 나눴으면 좋겠습니다. 다녀와서 다시 후기를 쓰도록 하겠습니다.

한동안 글이 무척 뜸했습니다. 개인적으로 가장 바쁜 시기를 보낸지라 블로그를 업데이트할 생각을 못하고 있었습니다. 대신 그 사이에 다른 블로거들의 블로그를 열심히 읽었는데, 앞으로 블로그를 어떻게 운영해야 할지 감을 조금 잡은 것 같습니다. 이것 저것 생각하고 있는 게 많은데, 크리스마스 이후로 대폭 개편(?)과 더불어 열심히 포스팅을 해보려고 합니다. 주 관심 분야는 여전히 프로그래밍 언어, 소프트웨어 공학, 개발 도구, 시스템 소프트웨어(OS, 컴파일러, VM 등)입니다. 특히 프로그래밍 언어는 OCaml과 Haskell을 위주로 글을 적어보려 합니다 :)

다들 행복한 크리스마스 보내세요 ^-^

I think the reason why Ruby is not so readable is because Ruby has special variables like $$.

$!	latest error message
$@	location of error
$_	string last read by gets
$.	line number last read by interpreter
$&	string last matched by regexp
$~	the last regexp match, as an array of subexpressions
$n	the nth subexpression in the last match (same as $~[n])
$=	case-insensitivity flag
$/	input record separator
$\	output record separator
$0	the name of the ruby script file
$*	the command line arguments
$$	interpreter's process ID
$?	exit status of last executed child process

Ruby programmers who often use these awkward looking special variables may feel comfortable, but I hate that I have to memory the difference between $! and $@. What is the rule to memorize the meanings of these variables? Even worse, some variables names are confusing. For example, Ruby naming convention states that variables starting with $ are global variables, but $_ and $~ are closer to local variables.

Ruby emphasizes the principles of least surprise, but special variables really surprised me. [For those of you who are not familar with the principles of least surprise: Read"Applying the Rule of Least Surprise"  in The Art of Unix Programming written by Eric  Raymond.]

Ruby is a pure objected-oriented language and special variables do not fit well in OO concepts. Why don't we make a Process clsss and define pid and args methods to retrieve process ID and command line arguments instead of ugly $$ and $* variables?

현재 과제연구 구현을 루비 언어로 하고 있는데, 루비 표준 라이브러리 문서를 뒤적이다가 man 페이지처럼 명령행에서 바로 바로 API 문서를 볼 수 있으면 좋겠다고 생각했는데, 찾아보니깐 그런 프로그램이 이미 있더군요. ri라는 도구인데, Ruby Interactive Reference라고 불립니다. 아래는 String#gsub를 찾았을 때의 예입니다.

컴퓨터공학소개 시간에 '리얼타임 운영체제(Real-Time Operating System)'을 주제로 발표하였습니다.

RTOS란 무엇인가?
일반적인 OS와 무엇인 다른가?
- 스케쥴링
- 동기화 및 프로세스간 통신
- 인터럽트
- 메모리 할당

등에 대해서 다루고 있습니다.

뒤에 사례 분석(case study)에서 대표적인 리얼 타임 운영체제인 VxWorks와 Windows CE, 리얼 타임 리눅스 등을 다루고 있습니다.

한참 블로그에 뜸해 있을 때 썬에서는 자바를 GPLv2 라이센스로 오픈소스화하겠다는 발표를 하였습니다. 썬 홈페이지에는 Sun Opens Java라는 제목으로 개요가 올라와 있고, Santa Clara, CA에서 있었던 자바 오픈 소스 이벤트에서 있었던 Jonanthan Schwartz와 Rich Green의 연설 장면을 웹캐스팅으로 볼 수도 있습니다.

Jonanthan Schwartz는 네트워크 효과(network effect)를 이야기하면서, 커뮤니티의 활성화를 첫 번째 이유로 들고 있습니다. "Volume Drives Value"라는 모토에서도 분명히 알 수가 있군요.

썬이 내세우는 표면적인 이유는 두 가지인 것 같습니다.

1) 최근 발전이 더디어진 자바의 확산 촉진
2) 1)을 통해서 자바의 원래 모토인 "Write once, run everywhere"를 실현.

하지만 썬의 호들갑에 비해서 개발자 커뮤니티에서는 오히려 담담한 것 같은데, 앞으로는 여파에 대해서 좀 더 고민해 봐야겠습니다.