까멜레오 프로젝트가 홈페이지를 새롭게 단장했습니다. 까멜레오는 제가 회사에서 진행하고 있는 공개 프로젝트입니다. 비디오 플레이어인 동시에 비디오 응용 프로그램을 쉽게 개발할 수 있는 비디오 플랫폼을 표방하고 있습니다.

현재 까멜레오 엔진 부분을 LGPL 라이선스로 릴리즈하려고 안정화 작업이 한참입니다. 까멜레오가 어떤 기능을 제공하는지 궁금하신 분은 홈페이지에 올라와있는 스크린캐스트를 통해서 간단하게 살펴보실 수 있습니다.

현재는 기본적인 비디오 재생 기능 외 몇 가지 샘플 위젯을 제공하고 있습니다. 샘플 위젯의 예로는

- 웹브라우저 (게코 엔진)
- 캡춰
- 블로깅
- 태그 삽입기
- 자막
- 자막 검색 (자막 내 검색)
- 퍼즐
- 돋보기
- 받아쓰기

등이 개발되어 있습니다. 얼른 릴리즈하고 싶은데 안정화나 성능 개선 이슈가 마음먹은 만큼 금방 되지가 않네요. 조만간 릴리즈 소식을 전하겠습니다.

미디어 프레임워크인 GStreaemr Good Plug-ins 0.10.7 버전이 릴리즈되었습니다. 앞서 릴리즈된 GStreamer Core와 Base 0.10.17의 릴리즈 소식을 전하지 않고 Good Plug-ins의 릴리즈 소식을 전하는 이유는 기여자에 제 이름이 포함되었기 때문입니다. 흐흐.

작년에 GStreamer 가져다가 컴파일하면서 윈도 쪽 컴파일 에러나는 부분들 고친 후에 다음 릴리즈에도 이짓을 또할 생각을 하니 끔찍해 고친 부분들을 패치로 만들어 몇 개 제출했는데 이게 소스 트리에 반영되면서 기여자 명단에 이름이 올라왔습니다. 오픈소스 프로젝트를 사용하다보면 이렇게 의도하지 않게 이름을 올리는 경우가 종종 있는 것 같습니다.

일반적으로 책을 출판하게 되면 저자가 저작권을 가지고 책을 출판할 권리인 출판권만 출판사와 계약 관계를 통해 양도하게 됩니다. 계약서상에는 출판권의 양도 기간이 정해져 있고, 보통 정해진 기간이 지나면 자동으로 계약이 연장됩니다. 물론 계약을 해지하고 출판권을 다른 출판사로 넘길 수도 있습니다.

잡지도 저작권이 아닌 출판권에 대한 대가로 원고료를 받는다고 생각해야 할 것입니다. 하지만 관행상 잡지 원고에 대해서 계약서를 주고 받는 경우도 드물고, 보통은 잡지사와 필자가 호혜적인 관계로 공생하기 때문에 이 부분이 문제가 되는 경우는 없습니다.

마소를 비롯해 여러 잡지에 글을 쓴지도 벌써 3년째이지만 출판권과 저작권에 대해서 명확하게 생각해 본적이 없었던 것 같습니다. 마소도 필자분들 중에 일부는 시간이 어느 정도 지난 원고를 블로그나 개인 홈페이지를 통해 공개하기도 하는데 이 부분이 사실 애매합니다. 명시적으로 계약한 적이 없기 때문에 계약 침해라기 보기도 어렵지만, 또 잡지사에서는 원고를 통해 2차, 3차 수입을 얻는 부분이 있기 때문입니다. 일례로 마소 홈페이지에 가시면 과월호 기사를 PDF로 다운받아 보실 수 있습니다.

저도 예전 홈페이지에 초기 원고를 몇 개를 XHTML로 변환해서 올려두기도 했습니다만 최근 원고는 개인적으로만 소장하고 있는 상태입니다. 최근에 들리는 소식에 따르면 마소가 1년 전 원고에 대해서는 무료(광고 수익을 기반으로)로 제공하는 안을 생각하고 있다고 합니다. 이게 잘 되려면 방문자들이 광고를 많이 클릭해주어야 한다는 전제 조건이 붙어 있기는 하지만요.

필자 입장에서는 내가 쓴 글이 최대한 많은 분들에게 읽혔으면 하는 바람이 있기 마련인데, 이 문제가 잘 풀려서 보다 많은 분들이 글을 읽을 수 있게 되었으면 좋겠습니다.

KMPlayer를 이용해 624x352 크기의 XViD+AC3 동영상을 재생해 보면 제 컴퓨터 기준으로 CPU 점유율이 약 10-15% 정도 나옵니다. KMPlayer의 기본 비디오 렌더러인 비디오 오버레이(Video Overlay)를 사용했을 때의 결과입니다. 하지만 비디오 렌더러를 OpenGL로 바꿔서 뿌려보면 CPU 점유율이 30-40%를 오갑니다. 같은 비디오기 때문에 XViD나 AC3 디코딩에 들어가는 CPU가 같다고 생각하면 비디오를 비디오 메모리에 올리는 데 이렇게 차이가 나는 것일까요? 혹 이 문제에 대해 자세한 설명이 가능하시면 설명해 주시면 맛있는 것 사드릴게요-.-

GStreamer는 리눅스에서 많이 사용하고 있는 멀티미디어 프레임워크입니다. 윈도의 DirectShow와 같은 역할을 한다고 보시면 됩니다. DirectShow와 마찬가지로 플러그인 기반으로 되어 있어 다양한 코덱을 외부 개발자가 쉽게 끼워 넣을 수 있는 구조로 되어 있습니다.

까멜레오는 교차 플랫폼을 지향하며 야심차게 GStreamer를 사용하고 있습니다. GStreamer 기반의 몇 가지 영상 분석 플러그인도 개발 중에 있고요. 복수의 멀티미디어 프레임워크를 사용하는 데서 오는 복잡함을 줄이기 위해 윈도에서도 DirectShow 사용 없이 GStreamer만으로 모든 영상을 재생할 수 있게 하는 것이 목표입니다.

하지만 아직까지 GStreamer를 윈도에서 사용한 비디오 플레이어는 전 세계적으로 하나도 없습니다. GStreamer 개발팀 자체는 대부분 리눅스에 적을 두고 있어서 윈도 운영체제 지원에 큰 우선순위를 두고 있지 않은 분위기입니다. 최근에 윈도에서 XViD 파일 재생 시 크래시나는 문제가 버그질라에 올라왔는데, 버그발견자가 매우중요(critical)로 설정한 우선순위를 메인 개발자가 보통으로 바꿔버리더군요.

하지마나 GStreamer를 윈도에서도 사용하려는 노력이 이어지고 있습니다. 오늘 Gecko 기반의 미디어 플레이어를 만들고 있는 SongBird 블로그에 GStreamer for all, all for GStreamer이 라는 제목으로 GStreamer 윈도 플랫폼 지원에 대한 글이 하나 올라왔습니다. SongBird의 경우도 리눅스에서는 GStreamer를 쓰는데, 윈도와 Mac OS X에서는 아직 VLC를 사용하고 있습니다.

SongBird 팀은 높은 자유도를 주는 GStreamer를 메인으로 생각하고 있고 유지 보수 문제를 줄이고자 하나의 미디어 프레임워크로 통일하고자 하고 있습니다. 하지만 문제는 아직 리눅스 외의 플랫폼에서 GStreamer의 안정성이 검증되지 않았다는 데 있습니다. 안정성을 높이고자 SongBird는 꽤 오래전부터 GStreamer 메일링 리스트를 통해 DirectShow 필터를 GStreamer 플러그인으로 사용할 수 있게 하는 DirectShow 래퍼를 만들고 있다는 이야기를 해왔는데 공개하는 시점이 자꾸 늦어지고 있습니다.

저희 회사 입장에서는 중복 노력을 피하기 위해 되도록이면 SongBird의 작업 결과를 활용하고 싶었는데 시기가 늦춰지면서 결국 GStreamer DirectShow 래퍼를 직접 만들기 시작했습니다. 2월말을 목표로 작업에 착수합니다. 그 전에 SongBird 팀에서 좋은 소식을 전해 주면 좋을 텐데 몇 차례 양치기 소년에게 당했기 때문에 조금 믿음이 안 가긴 합니다.

GTK+, QT를 비롯한 대부분의 GUI 라이브러리(툴킷)는 마우스 이벤트를 받을 수 있는 방법을 제공합니다. 마우스를 누르고(press), 떼는(release) 이벤트뿐만 아니라 마우스를 움직일 때도 지속적으로 이벤트를 날려줍니다. GTK+는 motion-notify-event 시그널을 정의하고 있습니다.

GUI 프로그램에 익숙하지 않은 사람이 마우스 이벤트 관련해서 흔히 저지르는 실수 중에 하나가 마우스가 움직일 때마다 계산량이 많은 일을 반복적으로 하는 경우입니다. 혹은 마우스가 움직일 때마다 UI를 새로 그리는 명령을 내리는 경우도 많습니다. 이렇게 코딩하면 별로 하는 일도 없는 프로그램인데 간단히 CPU 100%에 도달하게 되지요.

근데 이런 실수가 자주 나오는 이유를 반드시 초보 개발자의 미숙함만으로 돌릴 수는 없는 것 같습니다. GTK+의 motion-notify-event만 보더라도 마우스가 움직이면 불린다는 설명만 있을 뿐 얼마나 자주 불리는지 전혀 내용이 없습니다.

참고로  Limiting your repaint rate라는 제목의 블로그를 보면 거의 초당 110번 불린다는 내용이 있군요 이때마다 새로 그림을 했으면 110 FPS로 화면을 갱신하면서(갱신이 된다면) CPU를 낭비하게 됩니다.

시스템마다 달라질 수는 있겠지만 만약 API 문서에 마우스 이벤트가 어느 정도 간격으로 불리는지 대략적인 가이드라인이라도 줬다면 이런 실수는 없었을지도 모릅니다. 조금 더 친절한 API라면 마우스 이벤트를 받되 초당 몇 번까지 받을지 지정할 수 있게 했을지도 모르겠습니다.

까멜레오 프로젝트에서 GStreamer를 비롯한 GLib 기반의 프로젝트들을 많이 가져다 쓰는 관계로 GLib이나 여기에 포함된 GObject 등의 라이브러리를 쳐다볼 일이 많이 있습니다. GObject는 GLib에서 분리된 (여전히 같은 패키지로 존재하긴 하지만) 라이브러리인데, 다음과 같은  두 가지 목표가 있습니다.

1) C 개발자에게 객체지향 프로그래밍을 할 수 있는 환경을 줍니다. 물론 컴파일러 지원이 전혀 없는 순수한 C 라이브러리인 관계로 Objective-C나 C++과 비교해서는 적어줘야 하는 템플릿 코드가 상당히 많은 편이고 그게 초보 개발자에게는 진입 장벽이 되는 편입니다.

2) 다른 언어로 바인딩을 용이하게 해줍니다. 파이썬이나 루비 등 다른 언어에서 C 라이브러리 함수를 호출하려면 인자나 리턴 값의 타입 변환을 해줘야 하는데, GObject 바인딩을 용이하게 해줍니다. GObject 기반으로 작성된 C 라이브러리는 codegen이라는 코드 생성 프로그램을 이용하면 쉽게 파이썬 바인딩을 만들어 낼 수 있지요.

GLib 런타임 타입 시스템은 나름대로 장점이 있지만 역시 제일 불편한 점은 C 언어가 객체 지향이 아닌 관계로 클래스 하나 만들기 위해서 복잡한 템플릿이 필요하다는 점입니다.

GObject, GLib, GTK+ 기반의 GNOME 프로젝트는 이런 문제점을 해결하기 위해 Vala라는 프로그래밍 언어를 만들고 있더군요. Vala는 언어적으로는 C#과 상당히 유사한(대놓고 베낀) 언어이고, 특이한 점은 타겟 런타임이 .NET CLR이나 JVM이 아닌 GObject라는 사실입니다. Vala는 기본적으로 GObject를 런타임으로 사용한 C 코드로 변환을 하고, 다시 C 컴파일러를 이용해 컴파일하는 방식입니다.

프로그래밍 언어를 만드는 데 있어서 무시할 수 없이 많은 비용이 들어가는 부분 중에 하나가 런타임 작성입니다. 그래서 수많은 언어들이 방대한 언어 런타임을 거저 얻을 수 있는 CLR이나 JVM을 선택하고 있는 이유고요. Vala는 GNOME 프로젝트에서 시작한 만큼 기존에 GObject로 작성된 C 라이브러리를 그대로 사용할 수 있게 하기 위해 GObject를 언어 런타임으로 선택했군요.

작년 가을에 시작해서 아직 버전이 0.1.5 밖에 안 되는지라 안정성은 보장할 수 없다는 게 문제입니다. 많은 사람들이 참여해서 발전을 이루면 좋을 것 같은데 어찌될지 모르겠군요. 아직 언어 명세도 100% 작성이 안 된 것 같아서 프로그래밍 언어로서의 특징보다는 GObject를 이용한 C 코드 생성이라는 구현 이슈에 더 치중한다는 느낌이 듭니다.

요즘 Object Oriented Analysis and Design With Applications을 번역하고 있습니다. 일에 치여서 아직 많이 번역은 못 했는데 워낙 잘 쓴 책이라 번역하면서 느끼는 바가 많습니다. 특히 1장에서는 소프트웨어의 복잡성에 대해 논하면서 소프트웨어 유지 보수, 진화, 보존에 대한 명확하 정의가 나옵니다.

제가 없는 시간을 쪼개서 즐겨 보는 미국 드라마 중에 하나는 <하우스>입니다. 하우스는 일반적인 의학 드라마와 다르게 의사들 간의 사랑도 없고 병원에서 일어나는 아름다운 휴머니티도 존재하지 않습니다. 다만 원인 모를 병에 걸린 사람이 한 명 실려오는 걸로 시작해서 그 사람이 무슨 병에 걸렸는지를 추적해 나가는 추리물에 가깝습니다.

극중 하우스가 종사하는 분야가 바로 진단 의학입니다. 도저히 원인을 알 수 없는 병에 걸린 환자의 증상을 보고 어떤 병인지를 추측하는데 보통 수 십 혹은 수 백 개의 병명을 떠올립니다. 예를 들어 피를 토하고 열이 높다고 했을 때 말할 수 있는 병은 1-2개가 아니거든요. 진단 의학은 기본적으로 증상을 통해 병명을 나열하고 검사를 통해 리스트를 지워 나가는 방법이 기본입니다.

하우스를 보면서 재미있다고 생각한 것은 소프트웨어 개발자가 디버깅을 하면서 문제를 해결하는 방식과 놀랍도록 똑같기 때문입니다. 시나리오는 보통 다음과 같습니다.

원인을 알 수 없는 버그로 프로그램이 죽거나 이상 동작한다며 버그(환자)가 실려 옵니다. 개발자들은 증상을 보고 가능한 원인(병명)을 리스트합니다. 디버거를 붙이고 코드에 디버깅 메시지를 박아서(MRI, CT 촬영 등) 몇 가지 대안은 원인이 아니라는 사실을 알고 리스트를 지워나갑니다. 지우고 지우다 보니 결국 한 군데 밖에 원인이 안 남은 경우 문제를 해결하게 됩니다.

진단 의학은 기본적으로 경험이 매우 중요한 분야입니다. 기본 소양으로 폭넓은 지식이 기본으로 요구되지만 단순한 지식은 나열은 검사할 수 없는 엄청나게 많은 가능성만을 제시하게 됩니다. 여기서 아닐만한 병명을 빠르게 제거하는 과정이 바로 묘미입니다. 하우스가 제일 잘하는 부분인데, 하우스 부하 의사들이 여러 병명을 말하면 "이런 저런 이유 때문에 절대 아니다"라고 재빨리 말할 수 있는 것이죠.

디버깅의 기술도 유사합니다. 가능성은 많은데, 절대 아닐 만한 리스트를 재빨리 제거할 수 있는 능력은 소프트웨어 개발과 디버깅에 대한 오랜 경험을 요구합니다. 또한 개발 능력과는 조금 다른 순발력을 필요로 하기도 합니다. 소프트웨어 개발 방법론에 관한 책은 많이 있어도 디버깅 방법론에 대해서는 체계화된 방법론이 없는 것도 이런 순발력을 훈련시키거나 일반화하는 방법을 아직 발견하지 못했기 때문입니다.

그래도 소프트웨어 개발자가 하우스에게 배워야 할 점이 하나 있습니다. 병명을 맞추기 전에는 반드시 그 병이 환자의 현재 증상을 초래한 과정을 논리적으로 자세히 설명한다는 것이지요. 소프트웨어 개발자도 버그를 해결하기 전에는 반드시 어떤 과정을 거쳐서 그런 버그가 발생한 것인지를 논리적으로 설명할 수 있어야 합니다. 버그가 일어난 시나리오를 정확히 말할 수 없다면 그 버그를 제대로 알고 있지 못한 것이라고 봐야 합니다.

특히 레이스 컨디션이나 멀티 쓰레드 관련 버그의 경우 완벽한 시나리오 없이 코드를 이래 저래 뜯어 고치다 보면 버그가 사라지는 경우가 있는데, 이렇게 고친 버그는 주기적으로 다시 출몰해서 개발자를 괴롭히는 근원입니다. 여러 가지 검사(메모리 덤프, 디버깅 메시지) 등으로 시나리오를 찾아낸 후에야 버그를 잡을 수 있는 것이죠.

결론은? 소프트웨어 개발자 여러분, 하우스를 봅시다.

블로그 제목을 "프로그래밍 언어 이야기"로 바꾸고 첫 포스팅입니다.

컴퓨터를 전공하는 후배들을 만나면 컴퓨터 쪽 정보를 얻기 위해 주로 가는 사이트나 구독하는 블로그, 잡지에 대해서 많이 물어봅니다. 사실 저는 관심 분야가 다양한 편이라 한 사이트를 정기적으로 방문하거나 하는 일은 잘 없습니다. (금방 열정이 식기 때문에...) 대신 주로 특정 주제를 가지고 검색을 했다가 관련 사이트들을 들어가보는 방식으로 새로운 것들을 보는 편이고요.

그런 저에게도 새로운 글이 올라오면 항상 체크하고 꼼꼼히 읽어두려고 노력하는 사이트가 하나 있는데 Lambda the Ultimate이라는 사이트입니다. 번역하면 [람다 최고]인 이 사이트는 주로 프로그래밍 언어 전공자들이 프로그래밍 언어에 대한 최신 소식을 전하고 자기들끼리 논쟁도 벌이는 곳입니다. 람다는 함수형 언어의 이론적 바탕이 된 람다 칼큘러스(lambda calculus)의 람다를 지칭하는 말이고요.

물론 [람다 최고]라는 이름에서 알 수 있듯이 주로 함수형 언어 관련 연구자들이 많이 포진해 있기 때문에 함수형 언어를 상당히 옹호하는 글이 많이 올라옵니다. 또한 주로 PL 전공자들이 많다보니 최신 논문이나 이론을 소개하는 등 상당히 학구적인 곳이기도 하고요. 물론 PyPy나 LLVM, IronPythonm EcmaScript 4 등 우리가 자주 듣는 프로그래밍 언어 관련 프로젝트에 대해서도 근황을 전하고 자기 의견을 피력하기도 합니다.

또 메뉴에 보면 Getting Started 항목도 있어서 프로그래밍 언어 관련 이론을 공부할 수 있는 기본적인 책이나 사이트들을 소개해 주고 있습니다. 학교에서 PL 전공하지 않는 이상 접하기 힘든 내용들을 많이 볼 수 있어서 초보자들에게는 매우 귀중한 자료입니다.

PL하면 단순히 자바나 파이썬 같이 새로운 언어를 만들어내는 것만으로 생각하시는 분이 많은데, PL 관련 이론은 프로그래밍 언어의 의미(semantic)를 정형적으로 정의하는 것부터 시작해서 타입 이론(type theory), 구현(implementation), VM이나 컴파일러와의 연계 등 많은 이슈들을 다루거든요.

저는 원래 주어진 프로그램을 분석해서 자동으로 오류는 찾아주는 정적 분석(static analysis)에 관심을 가진 후에 프로그래밍 언어 쪽도 아주 조금 공부하려고 마음을 먹게 되었는데 지금은 잘못된 디자인(대표적인 언어 C 언어)를 고치기 위해 많은 노력을 들이는 정적 분석보다는 처음부터 제대로 설계하자는 "언어 설계" 쪽에 더 관심이 많이 갑니다.

아직 아는 것보다 모르는 것이 더 많기에 공부하는 데로 조금씩 정리해서 써보려고 합니다.

11월 한 달을 어떻게 보냈는지 모르겠는데 벌써 12월이 되어 버렸습니다. 까멜레오 프로젝트는 핵심 엔진의 교체 작업을 마치고 안정성 테스트를 계속하고 있는 와중에 중간 데모를 하느라 일주일에 일주일에 2-3번 씩 밤을 세며 주말에도 출근하는 생활을 잠깐 했습니다. 물론 좋아하는 제품을 만드는 일을 그럼에도 불구하고 즐거운 일이지만 육체적으로 힘들긴 하더군요.

11월은 거의 블로그를 손에서 놓고 있었습니다. 사실 일이 바빠지면서 한 달에 한 번 쓰는 마소나 경컴 원고도 매달 마감에 쫓기고 있는 상황이다 보니 블로그 쓸 엄두도 못 내고 있었습니다.

그리고 한RSS 기준으로 구독자가 거의 400명이 되었고 (안 보시는 분이 더 많겠지만...) 원래는 자유롭게 자기 이야기를 할 수 있는 개인 블로그임에도 불구하고 왠지 모르게 읽는 분들을 의식하게 되면서 글 쓰기가 쉽지 않더군요. 사실 보는 분들은 별로 신경도 안 쓰는데 혼자 괜히 의식하고 있는 것인지도^^;;

이 블로그에는 무엇을 쓸까 고민도 많이 했어요. 주제를 "소프트웨어 이야기"로 광범위하게 잡아놓긴 했는데 오히려 더 막연해 지더군요. 특별히 전문적인 강좌를 올리는 것도 아니면서 개인적인 넋두리를 적기에는 왠지 블로그 보러 오시는 분들에게 미안한 그런 느낌이랄까.

그래서 이왕 쓸 것 원래 관심 있었던 분야인 프로그래밍 언어나 컴파일러 쪽으로 다시 내용을 좁혀서 써볼까라는 생각을 했습니다. 항상 관심 분야라고 이야기하지만 실제로는 제대로 배워야 한다는 부담감 때문에 오히려 시작도 못 하고 있었는데 이대로 계속 살아서는 안 된다는 생각을 새삼했다고 할까요.

학부 시절 PL 전공으로 진학하고 싶었는데 그러지 못했던 사실 때문에 오히려 PL 쪽 주제를 볼 때는 조금 부담이 있었습니다. 어설프게 공부하느니 대학원 가서 제대로 배우자는 생각에 오히려 더 멀리했던 것이죠. 제대로 못 배울까봐 두려워서 전혀 안 배운다는 게 조금 웃기긴 하지만 심리적으로는 그렇게 되더군요.

이제는 제대로 배워야 한다는 부담감을 조금 버리고 시행 착오를 겪더라도 조금씩 시도를 해봐야겠다는 결심을 했습니다. 당장 진학 계획이 있는 것도 아닌데 정말 공부하고 싶은 분야를 그렇게 계속 미뤄두기만 해서는 안 된다는 생각이 들었거든요. 대한민국에 저 같은 생각을 가진 분이 저하나 만은 아닐 것이라 믿기에 "배우고 싶다는 티"를 내고 이미 비슷한 길을 먼저 걸으신 분들의 조언을 구할까 합니다.

다짐하는 의미로 블로그 제목도 바꾸고 로고도 바꾸었습니다. 근데 미련이 남아 있었는지 저번 로고도 람다(함수형 언어의 이론적 배경이 되는 람다 칼큘러스를 의미합니다)더군요.

꿈을 이루고 싶은 분들 안 될 것이라 접어두지만 말고 조금씩 펼쳐가 보아요^^

마이크로소프트 리서치(MS Research)의 Andrew Kennedy가 슬라이드 만들어 놓은 것을 보니 C# 3.0은 함수형 언어라고 주장하고 있군요. 헤스켈 같은 함수형 언어의 전유물이었던 퀵소트 예제의 C# 버전을 보여주고 있습니다.


아래 헤스켈 코드와 비교해도 손색이 없군요. 물론 타입을 조금 더 써줘야하긴 말입니다.

뒷북일 수 있지만 실무에서 C#으로 프로그래밍을 하지는 않는 관계로 오늘에서야 C# 3.0에서는 뭐가 바뀌었는지 잠깐 살펴보았습니다. LINQ처럼 DB 연동이 주라고 생각하고 있었는데, 의외로 타입 추론(type inference)나 람다 표현식(lambda expression) 같이 함수형 언어의 영향을 많이 받은 부분들도 보이더군요.

특히 3.0에 추가된 람다(lambda)는 2.0에 추가된 후에 상반된 반응을 얻었던 익명 대리자(anonymous delegate)을 보강한다는 측면에서 추가되었다고 합니다. 쉽게 말해서 네 자 이상의 이름을 걸러내는 필터를 만들기 위해 C# 2.0에서는 다음과 같이 코드를 작성합니다.



반면에 lambda를 사용한 C# 3.0의 코드는 다음과 같습니다.



x => x.Length > 4라는 부분이 바로 람다 표현식인데, x라는 인자를 하나 받아서 x.Length >4 를 리턴한다는 의미입니다. 위 예제만 보고 처음에는 식 밖에 못 오는 줄 알았는데 { } 사이에 집어 넣으면 구문도 사용할 수 있더군요.

C#의 lambda는 단순히 익명 대리자의 문법을 바꾼 것만은 아닌 듯 합니다. x => x.Length 와  같이 x의 타입을 명시해주지 않아도 타입 추론을 통해 찾아주는 부분은 기존 익명 대리자에 비해서는 발전하였네요.


여담이지만 파이썬 사용 시에 제일 불만이었던 것이 lambda입니다. 파이썬의 lambda는 함수형 언어도 아닌 주제에 말 그대로 람다 식(lambda expression)이어서 하나의 식만 사용할 있습니다.

사실 일반적인 함수형 언어야 프로그램 전체가 하나의 식으로 되어 있고 이를 연산(evaluation)하면서 프로그램을 수행하기 때문에 lambda expression은 무척 자연스러운 방식입니다. 반면에 프로그램 수행이 명백히 문장 중심인 파이썬이 정작 lambda에서는 표현식 하나만 쓸 수 있는 것이 항상 불만이었습니다. 조금만 복잡해져도 할 수 있는 일이 없으니 lambda를 익명 함수(anonymous function)로는 사용하지 못하는 경우가 많았거든요.

파이썬 3000에서도 이 부분에 대한 개선은 없다고 하는데, 파이썬은 쓰면 쓸수록 뭔가 아쉬운 느낌이 드는 언어입니다.

이번주도 API 스터디가 열립니다. 많이 참석하셔서 좋은 이야기도 들으시고 뒤풀이도 즐겨보아요. API 스터디는 열린 모임입니다. 새로 오시는 참석자 분들을 매우 환영합니다^^

시간: 2007년 11월 13일 화요일 오후 8시
장소: 역삼동 삼성SDS 멀티캠퍼스 1302호
주제: 황상철님의 "Java Exception Model"

1층 에스원이 물어보면 1302호에서 하는 회의 참석차 왔다고 하시면 됩니다. 삼성SDS 멀티캠퍼스 홈페이지 보시면 오시는 방법이 잘 나와있습니다.

그리고 구글 그룹스 메일링 리스트 API 스터디 모임에 가입하시면 모임 관련 정보를 얻어보실 수 있습니다.

학교 다닐 때 소프트웨어 공학 책에서는 일단 요구사항을 뽑고 명세서를 작성한 후에 이를 근거로 비용을 계산하고 프로젝트가 완료되는 시점을 결정하는 완료 테스트(acceptance test)를 설계해야 한다고 배웠습니다. 물론 예기치 않은 요구 사항 변경에 대해서는 일정 지연이나 초과 예산에 대해 갑이 책임을 져야 한다는 조항도 들어가야 할 테고요.

하지만 제가 소프트웨어를 개발해 오면서 겪은 상당수의 소프트웨어 개발 계약(대부분 소규모이긴 하지만)은 매우 주먹구구식이었습니다. 매우 불투명한 목표(요구 사항)를 설정한 후에 일단 투입 인원과 일정을 고정시키고 이를 근거로 비용을 산출하는 방식이죠. 일단 비용과 일정이 고정되어 있는데 소프트웨어 추정 기술이 무슨 필요가 있는지도 모르겠습니다.

구체적인 요구사항은 계약이 이루어진 후에야 작성되는데, 이 과정부터 이제 갑과 을은 심리전을 치러야 합니다. 이미 계약은 이루어졌으니 갑 입장에서는 최대한 뽑아낼 건 뽑아내야 하고, 을 입장에서는 이미 받기로 한 돈은 정해져 있으니 일을 최소한으로 만드는 것만이 살아날 길입니다. 이렇게 불온한 동거가 시작되면서 프로젝트는 난항을 겪게 됩니다.

이렇게 밀고 당기기를 거듭한 끝에 초기 요구사항을 확정했다고 해도 안심할 것은 못 됩니다. 요구사항 변경에 대해 어떤 조항도 없었기 때문에 갑 입장에서는 쉽게 변경 요청을 합니다. 물론 을 입장에서는 시간을 끌고 버티면 안 해줄 수도 있기 때문에 최대한 못하겠다고 우는 소리를 하며 버티는 것이 일반적입니다.

일이 끝나는 시점도 분명하지 않습니다. 일정보다 일을 빨리 끝내면 일을 더 만들어서 줄 것이 뻔하기 때문에 일정은 절대로 단축되지 않습니다. 또한 개발이 완료되었다고 해도 유지보수에 대해서도 별도의 계약이 없었기 때문에 '의리상 지원 기간'이라는 개념이 생깁니다. 향후 추가 계약을 염두에 두고 마음 같아서는 관두고 싶지만 의리상 해주는 유지보수가 생기는 거죠.

이론과 현실의 차이 때문에 괴리감이 큽니다. 제대로 된 계약을 하는 방법은 어떤 게 있을까요?

근래에 제 관심이 복잡한 시스템을 어떻게 잘 설계할 것인가로  옮겨가면서 현재는 Eric Evans의 Domain Driven Design을 읽고 있습니다. 한 가지 의아했던 점은 이 책이 나온 시점은 2003년 8월경인데 왜 이제서야 조금씩 사람들에게 알려지고 있는 것일까라는 점이었습니다. (사실 제가 알게되었다는 사실은 이쪽 분야 종사자들은 이미 다 알고 있다는 소리긴 하지만.)

InfoQ에서 Eric Evans on Domain Driven Design이란 인터뷰를 실었습니다. "Domain Driven Design이 2003년에 나왔는데 지금에서야 이와 관련된 입소문이 나고 있다. 왜 지금이 Domain Driven Design의 시대냐?"라는 질문이 마지막으로 있더군요. Evans의 대답을 간단히 요약하면 다음과 같습니다.

"최근의 급작스런 인기는 나 스스로도 의아스럽다. 사람들이 새로운 아이디어를 받아들이고 필요성을 인지하는 데는 시간이 조금 걸리는 것 같다. Jimmy Nilsson이 Applying Domain Driven Design and patterns 책도 내놨고, InfoQ에서 Domain Driven Design Quickly라는 책을 내놨다. 사람들이 관련 리포트를 내놓고 있고 툴 벤더들에서도 뭔가 하려고 하고 있다. 이런 실험을 통해 앞으로 어떻게 될지 나도 궁금하다."

제가 일하는 (주)노매드커넥션은 현재 사무실이 목동 SBS 사옥 뒤에 있는 KT 건물에 위치하고 있습니다. 목동 공기 좋고 공원도 많고, 점심 시간에 줄 서서 밥 먹어야 할 필요도 없고 여러 모로 근무 환경은 강남보다 훨씬 뛰어납니다. 

하지만 목동이 아무래도 서울에서 조금 외곽에 위치하고 있고, 대부분의 IT 회사들이 강남, 역삼, 삼성 등에 특정 권역에 몰려있다 보니 외부 미팅나가는 일이 괴롭습니다. 한 번 나갔다 오면 왕복 3시간은 길에서 낭비하게 되거든요. 물론 지하철 타고 다니면서 틈틈이 기술 서적도 읽고 문서도 보지만 그렇게 쓰는 시간이 왠지 아깝다는 생각은 금할 수가 없습니다.

결국 중고등학교 때 사회 시간에 배운 '직접 이익'이라는 개념을 무시할 수가 없더군요. 모든 회사가 강남에 있기 때문에 IT 관련 회사는 강남을 벗어날 수가 없습니다. 심지어 벤처 캐피탈 같은 경우도 미팅하는데 1시간 이상 걸리는 회사에는 투자 안 한다는 이야기 있을 정도거든요.

결단을 내린 끝에 11월에는 우리 회사도 강남 쪽으로 이전할 생각입니다. 새로 지은 좋은 사무실 있으면 추천 부탁 드려요 :)

요즘은 개발 인력을 해외에서 구해오거나 개발팀을 해외로 아웃소싱하는 경우가 자주 보입니다. 오늘 메일을 보니 2007 베트남 기술인력 채용박람회라고 해서 산업자원부 주최 하에 베트남 현지 개발 인력을 뽑을 수 있는 행사를 하더군요(신청 기간이 10월 31일까지인데 왜 이제서야 메일이 왔는지 모르겠지만.) 직접 베트남 현지에 비행기 타고 가서 주말에 개발자들 직접 면접하고 채용도 하는 행사로 보입니다. 숙박비에 해당하는 50만원 지원도 있고요.

저도 추석 때 사업차 인력 수급과 서비스 제휴 건으로 북경에 잠시 다녀왔는데 북경은 인건비가 상당히 많이 올랐더군요. 물가 만만하게 보고 갔는데 점심 한 끼 먹으니 우리 돈으로 3000-4000원은 하는 걸 보고 놀랐습니다. 덕분에 요즘은 중국에서도 북경, 상해 같은 대도시 보다는 중소 도시로 많이 이전하는 추세인 것 같고, 베트남이나 필리핀 등 쪽도 많이 알아보시더군요.

의사소통 문제만 없으면 당장이라도 국내 개발 용역의 상당 부분은 해외로 나갈 것 같고, 앞으로 이 추세는 변하지 않을 것 같습니다. 이런 상황에서 국내 개발자는 외국 개발자들에게 요구사항을 전달하고 프로젝트를 이끌 수 있는 위치(즉, 고급 개발자)로 올라가지 않으면, 해외 값싼 인력들에 밀려서 완전히 경쟁력을 상실하게 될 가능성이 큽니다. 안 그래도 떠나는 사람 많은데, 갈수록 살기가 만만치 않군요.

제가 개발중인 까멜레오 개발팀 블로그가 만들어졌습니다. 이 블로그는 주로 저의 개인적 관심사만을 다루어왔다면 까멜레오 개발팀 블로그에서는 개발팀 내부의 이야기, 개발 관련 소식, 미디어 기술과 관련된 글들이 올라올 예정입니다.

아래 구인 글도 있는데, 개발이 예상보다 조금 지연되고 있는 면이 있어서 이번에 인력도 더 투입하고 개발에 박차를 가하고자 합니다. 이번 채용 공고는 제가 직접 작성했습니다. 흐흐. 빨리 오픈도 해야하는데, 아직 안정화시키고 클로즈 테스트를 하는데 시간을 쓰고 있습니다.

혹시 구인 공고 관련해서 궁금한 것 있으신 분은 언제든지 질문 주세요. 메일로 보내주셔도 좋고, 이 글에 리플도 다셔도 되고요. skyul@nomadconnection.com 입니다.