요즘 X 서버는 연결된 모니터가 없고, /etc/X11/xorg.conf 파일에 수직/수평 주파수가 정의되어 있지 않다고 하더라도 일단 정상적으로 실행됩니다. 다만, 초기 해상도가 320×200 처럼 매우 작을 수 있습니다. 그런데 나중에 필요에 의해 모니터를 연결했는데 화면이 보이지 않는 경우가 발생합니다. 이 경우, 네트웍으로 접속해서 다음 명령어를 실행합니다.

$ export DISPLAY=:0.0
$ xrandr --auto

그러면 X 서버가 알아서 연결되어 있는 모니터를 출력으로 재설정하고 가장 선호하는(preferred) 해상도와 주파수를 선택합니다. 그런데 이를 자동으로 동작하게 하려면 udev 데몬의 도움을 받아야 합니다. 그래서 /etc/udev/rules.d 디렉토리에 확장자가 '.rules'인 파일을 생성하고 다음과 같이 내용을 채웁니다.

ACTION=="change", SUBSYSTEM=="drm", KERNEL=="card*", RUN+="/usr/bin/auto-xrandr.sh"

그리고 /usr/bin/auto-xrandr.sh 파일을 아래와 같이 작성한뒤 실행권한을 줍니다.

#!/bin/sh
[ "$DISPLAY" = "" ] && export DISPLAY=:0.0
xrandr --auto
xrandr --dpi 96

그러면 이제부터 모니터 연결시 자동으로 연결을 재설정하게 됩니다.

그런데, 만일 네트웍으로 접속했거나, udev 데몬에 의해 실행되는 경우 X 서버 인증이 안된 계정이라며 xrandr 명령이 실행이 거부됩니다. 이를 제대로 처리하려면 복잡한 인증 과정이 필요한데, 이를 쉽게 처리하려면 그냥 X 서버 시작할때 자동으로 실행되는 초기화 스크립트에 'xhost +' 명령어를 주면 인증을 무시하게 됩니다. 물론 보안상 좋은 방법은 아니지만, 폐쇠된 환경이라면 별로 문제가 없을 겁니다.

각각의 명령어에 대해 더 궁금하신 분은 관련 명령어 매뉴얼 페이지를 확인해 보시기 바랍니다.

참고로 조금만 더 설명하면, 노트북 외부 모니터 단자에 빔 프로젝트나 외부 모니터를 연결했을 경우도 xrandr 명령을 직접 사용하거나 지금까지 설명한 방법을 조금 다르게 응용할 수 있습니다.

그래서 결국 예전에 소개한 적 있는 구글 성능 도구(google-perftools)를 이용해 디버깅을 했습니다. 그런데 문제는, 아치 리눅스(Arch Linux) x86_64 환경으로 개발 환경을 바꾸면서 메모리 프로파일 기능이 제대로 동작하지 않는다는 사실인데, 특히 메모리 누수 발생 지점을 정확하게 알기 위해서 필요한 함수 호출 백트레이스(backtrace) 정보가 추출되지 않는 게 가장 큰 문제였습니다. 이 문제를 해결하기 위한 과정을 기록으로 남겨봅니다.

구글 성능 도구 설치

아치 리눅스(Arch Linux) x86_64 환경에서 구글 성능 도구(google-perftools)가 정확한 메모리 프로파일 결과를 얻으려면 libunwind 라이브러리를 설치해야 하는데, 아치리눅스 AUR 패키지를 yaourt를 이용해 다음과 같이 쉽게 설치했습니다.

$ yaourt -S libunwind

그리고 다음과 같이 구글 성능 도구를 빌드하고 설치합니다.

$ cd google-perftools
$ ./configure --prefix=/usr --enable-frame-pointers
$ make
$ sudo make install

라이브러리 패키지 재생성 및 재설치

정확한 함수 호출 백트레이스(backtrace) 정보를 얻기 위해 프로그램에 사용되는 모든 라이브러리를 다시 컴파일해 패키지를 다시 설치해야 하는데, 그 과정은 다음과 같습니다. (관련 위키 페이지 참고)

먼저 아치 리눅스 빌드 시스템(ABS) 정보를 동기화합니다.

$ sudo abs

그러면 /var/abs 디렉토리 밑에 모든 공식 패키지의 빌드 정보가 다운로드됩니다.

라이브러리의 패키지 빌드 옵션을 수정하기 위해, /etc/makepkg.conf 파일에서 아래 부분을 찾아 디버그 심볼(-g)과 프레임 포인터 포함(-fno-omit-frame-pointer) 컴파일 옵션을 추가하고 빌드 옵션에서 strip을 제외합니다.

CFLAGS="-g -fno-omit-frame-pointer -march=x86-64 -mtune=generic -O2 -pipe"
CXXFLAGS="-g -fno-omit-frame-pointer -march=x86-64 -mtune=generic -O2 -pipe"
OPTIONS=(!strip docs libtool emptydirs zipman purge)

/var/abs/local 디렉토리로 이동해서(없으면 새로 생성) 다음과 같이 사용되는 프로그램에 사용되는 모든 라이브러리 패키지를 다시 생성하고 설치합니다. 예를 들어 클러터 라이브러리는 다음과 같습니다.

$ src=$(find /var/abs -name clutter | grep -v /var/abs/local)
$ cp -r $src /var/abs/local
$ cd /var/abs/local/clutter
$ makepkg -f
$ sudo pacman -U *.pkg.tar.xz

위와 같은 방식으로 clutter, cogl, glib2, glibc 패키지를 다시 만들고 설치합니다.

메모리 프로파일링

이제 다음 명령으로 디버깅할 프로그램(eview-demo)을 실행합니다.

$ G_SLICE=always-malloc \
  HEAPPROFILE=/tmp/profile \
  HEAP_PROFILE_ALLOCATION_INTERVAL=10737418240 \
  LD_PRELOAD=/usr/lib/libtcmalloc.so \
  ./eview-demo
Starting tracking the heap
Dumping heap profile to /tmp/profile.0001.heap (...)
Dumping heap profile to /tmp/profile.0002.heap (...)
Dumping heap profile to /tmp/profile.0003.heap (...)
Dumping heap profile to /tmp/profile.0004.heap (...)

정상적으로 구글 성능 도구의 메모리 프로파일러가 동작하면 위와 같은 메시지가 출력됩니다. 이제 적당한 시점에서 프로그램을 멈추고, 다음과 같이 프로파일링 데이터를 분석합니다.

$ pprof \
    --pdf \
    --lines \
    --base /tmp/profile.0001.heap \
    ./eview-demo \
    /tmp/profile.0004.heap \
    > profile-1.pdf

이렇게 생성된 그래프는 다음과 같습니다. (PDF 형식도 있습니다)

이 그래프를 분석해서 관련 코드를 분석해 보니, 결정적으로 두 군데에 문제가 있습니다. 첫번째는 cogl_pipeline_fragend_arbfp_start() 함수 내부에서 생성한 arbfp_program_state 객체를 해제하는 곳이 없다는 점이고, 두번째는 cogl_pipeline_get_layers() 함수에서 생성한 deprecated_get_layers_list 리스트를 해제하는 곳이 없다는 점입니다. 그런데 최근 클러터 1.8 버전 소스를 보면 두번째 문제는 해결이 된 것 같은데, 첫번째 문제가 있는 곳은 코드 수정이 많이 되어 해결 여부를 알 수가 없습니다.

그래서 결론은, 며칠 전에 릴리스된 클러터 1.8 안정 버전이 아치 리눅스 패키지로 올라오면 다시 메모리 누수 여부를 확인해볼 예정입니다. (GNOME 3 핵심 라이브러리를 직접 컴파일해서 사용하는게 귀찮기도 하고 두렵기도 해서입니다… :)

[UPDATE 2011-10-04] 클러터 1.8 버전에서 확인해 보니 메모리 누수 문제가 해결된 것 같습니다. 역시, 미루기를 잘 했습니다. ;)

[UPDATE 2011-10-05] 다시 확인해 보니, 이제는 다른 부분에서 메모리 누수가 발생합니다. 그래서 이번에는 당당히(?) 버그 리포팅(Bug 660985, Bug 660986) 했습니다.

[UPDATE 2011-10-10] CPU 사용량이 가장 많은 함수를 프로파일링하려면 다음과 같이 실행하면 됩니다.

$ CPUPROFILE=./cpu.prof \
  LD_PRELOAD=/usr/lib/libtcmalloc_and_profiler.so \
  ./eview-demo

정상적으로 종료한뒤 다음과 같이 CPU 사용량을 함수별로 프로파일한 그래프를 얻을 수 있습니다.

$ pprof \
    --pdf \
    --lines \
    ./eview-demo \
    ./cpu.prof
    > profile-1.pdf

[UPDATE 2012-02-04] 최신 아치 리눅스에 포함되어 있는 glibc 2.15 버전의 버그 때문에 프로파일링이 제대로 동작하지 않을 경우 sscanf 관련 패치를 적용해 glibc 패키지를 다시 빌드하고 설치해야 합니다. glibc 2.15-5 버전으로 업그레이드하면 됩니다. 버그 리포팅이 바로 반영되어 버렸습니다. :)

아무튼 그래서, 지금까지 겪은 경험 중 몇 가지를 정리해 보았습니다. 당연하지만, 아직 OpenGL에 대한 이해가 부족해 틀린 내용이 있을 수도 있으니, 감안해 주시기 바랍니다.

1.
클러터 라이브러리는 계속 버전업 되는데 예전에 작성된 튜토리얼이나 예제는 갱신되지 않아 잘못되거나 사용을 권장하지 않는(deprecated) API를 사용하는 경우가 많이 있습니다. 가능한 클러터 개발자들이 라이브러리와 함께 직접 업데이트하는 클러터 해설서(The Clutter Cookbook)를 참고하는게 가장 정확했습니다.

2.
OpenGL 기반 클러터 라이브러리 동작 방식은 일반적인 2D GUI 프로그래밍과 달리 화면, 즉 스테이지(stage)에 조그만 변화라도 있으면 그때마다 스테이지를 다시 그립니다. 즉, 클러터의 기본 단위인 액터(actor) 하나가 다시 그려져야 하면 액터가 속한 스테이지의 모든 액터를 다시 그립니다. 그리고 이로 인해 스테이지에 보이는 모든 액터의 paint() 함수가 매번 호출되기 때문에 이 함수를 최적화하는 게 매우 중요합니다.

3.
내부적으로 캐싱(caching)이 이용되긴 하지만, 한 액터의 좌표(크기 + 위치)가 변경되면 스테이지의 모든 액터의 크기를 다시 계산하기 위해 모든 액터의 allocate() 함수가 호출됩니다. 예를 들어 텍스트(text) 액터 구현을 보면, 문자열이나 폰트, 크기 등이 변경되었을때 텍스트 액터를 포함하는 부모 컨테이너 액터가 변경된 크기를 감지하고 자신의 크기를 조정할 수 있도록 clutter_actor_queue_relayout() 함수가 호출됩니다. 그리고, 이 함수가 호출되면 결국 스테이지 단계까지 호출이 계속된 다음, 다시 스테이지에 속한 액터의 allocate() 함수가 재귀적으로 호출됩니다. 따라서 액터의 allocate() 함수 역시 내부적으로 최적화되는 것이 좋습니다. 참고로 clutter_actor_queue_relayout() 함수가 호출되면 자동으로 clutter_actor_queue_redraw() 함수가 호출되어 스테이지의 모든 객체를 다시 그립니다.

4.
클러터에서 기본으로 제공하는 박스(ClutterBox), 그룹(CutterGroup) 등과 같은 컨테이너 액터를 사용하지 않고 직접 컨테이너 액터를 구현해 자식 액터를 배치하고 싶거나 혹은 기존 컨테이너 액터를 상속받아 새 컨테이너 액터를 구현할 때가 있습니다. 그런데, 컨테이너 액터 좌표(크기 + 위치) 변경에 따라 자식 액터의 좌표를 자동으로 변경할 필요가 있으면 대개 "allocation-changed" 시그널을 이용해 감지한 뒤 clutter_actor_set_size(), clutter_actor_set_position() 함수 등을 이용해 자식 액터의 좌표를 조정하거나, 제약(ClutterConstraints) 기능을 이용하는데, 위에서 설명한 것처럼 좌표가 변환되면 자동으로 clutter_actor_queue_relayout() 함수가 호출되면서 “The actor ‘xxx’ is currenty inside an allocation cycle; calling clutter_actor_queue_relayout() is not recommended” 디버그 경고 메시지가 계속 출력됩니다. 메시지니를 무시할 수도 있지만, 문제는 한 액터의 좌표 변경으로 인해 매번 화면 전체가 다시 좌표를 다시 계산하기 때문에 결국 모든 액터의 allocate() 함수가 계속 호출되면서 CPU 점유율이 매우 높아진다는 점입니다. 여기에 좌표를 이용한 애니메이션까지 사용하면 CPU 점유율은 상상을 초월할 정도로 올라갑니다. 이 문제를 해결하려면 반드시 allocate() 함수에서 자식 액터의 좌표를 지정할때 clutter_actor_allocate*() 종류의 함수만 이용해야 하고, 어쩔 수 없을 경우 g_idle_add_full() 함수를 이용해 자식 액터 좌표 지정 루틴의 실행을 뒤로 조금 미룬 뒤에 좌표 중복 검사 등을 통해 가능한 화면 재구성(relayout) 작업이 덜 일어나게 해야 합니다. 메인루프 우선 순위는 CLUTTER_PRIORITY_EVENTS 값을 사용하는 게 좋습니다.

5.
클러터 실행에 영향을 주는 환경 변수를 이용하면 성능 조율 및 디버깅에 상당한 도움을 받을 수 있습니다. 예를 들어 COGL_DEBUG=rectangles 이나 CLUTTER_DEBUG="paint layout" 등은 도움이 많이 됩니다.

6.
텍스트(ClutterText) 액터의 위치가 정수가 아니라면, 즉 소수점 이하 값이 존재하는 실수일 경우  글꼴 선이 흐려지거나 뭉개지는 현상이 발생합니다. 텍스트 액터 뿐 아니라 사각형(ClutterRectangle) 액터처럼 그림이 아니라 직접 그려지는 액터들도 비슷한 현상이 발생합니다. 비단 액터의 위치가 정수일 지라도 이를 포함하는 상위 컨테이너 액터의 위치가 소수점 이하를 포함하는 실수일 경우, 즉 화면(stage)상 절대 좌표가 정수가 아닐 경우 이 현상이 발생합니다. 따라서 액터의 좌표를 계산해서 지정할 경우 반드시 floor() / ceil() 등의 함수를 이용해 소수점 아래 값을 없애주는 것이 좋습니다.

7.
액터에 배경 또는 테두리를 장식하고 싶을때 보통 떠오르는 구현 방법은 두 가지가 있습니다. 첫번째는 컨테이너 액터를 이용해 사각형 액터를 맨 아래 두고 대상 액터를 위에 두는 방법을 이용한 것이고, 두 번째는 이런 작업을 하는 커스텀 액터를 직접 구현하는 것입니다. 그런데 이보다 더 좋은 방법은, 효과(ClutterEffect) 객체를 구현해서 사용하는 것입니다. 효과 객체가 액터 객체에 추가되면 효과의 pre_paint() / post_paint() 함수가 액터의 paint() 함수 호출 전후에 자동으로 호출되므로, 동일한 디스플레이 루틴을 여러 객체에 쉽게 적용할 수 있습니다. 클러터에서 이미 기본으로 제공하는 고급 효과를 사용해도 되지만, 예를 들어 텍스트에 그림자를 넣어주는 예제를 그대로 이용해 테두리 효과처럼 구현할 수도 있는 셈입니다.

8.
클러터에서 직접 그리기 위해 사용하는 OpenGL 랩퍼 API Cogl 함수를 사용할때 경로(Path) 등을 사용하지 않고 가능하다면 기본(Primitives) 함수만 사용해서 구현하는게 성능이 좋습니다.

9.
Cogl 함수를 이용해 직접 그리는 방식과 모든 것을 그림 이미지로 처리하는 텍스쳐(ClutterTexture)를 이용하는 방식의 장단점을 아직 잘 모르겠습니다. 다만, 텍스쳐는 내부적으로 사용하는 메모리량이 더 많은 것이 분명하고, 현재 개발 중인 시스템에서는 수많은 채널의 비디오 동시 재생을 위해 어차피 많은 텍스쳐가 사용되기 때문에 가능한 텍스쳐 사용을 자제했습니다. 하지만 영역 크기에 따라 크기가 달라지는 GUI 부분을 구현할때는 이미지 기반 텍스쳐보다 일종의 벡터 그래픽이라고 할 수 있는 Cogl 함수를 이용해 직접 그리면 훨씬 깔끔한 GUI를 얻을 수 있는 것도 사실인 것 같습니다.

10.
비디오 재생을 위해 비디오싱크(ClutterGstVideoSink) 객체를 사용할 때 갱신 우선순위 (update-priority) 속성을 CLUTTER_PRIORITY_REDRAW 값으로 낮추면 마우스 이벤트 반응 속도를 개선할 수 있습니다.

11.
정말로 빈번한 애니메이션을 구현할때는, 사용하기 쉽지만, 내부적으로 수많은 객체가 생성되고 소멸되는 clutter_actor_animate() 대신, 번거롭지만, 타임라인(ClutterTimeline) 등을 이용해 구현하는게 CPU / 메모리 사용량을 줄이는데 도움이 됩니다.

12.
AMD(ATI) 그래픽 카드를 장착한 리눅스 상에서 클러터를 실행할때 Catalyst 상용 X 드라이버와 최신 오픈소스 X 드라이버와 성능 차이가 거의 없어진 것 같습니다. 물론 NVidia는 상용 드라이버 성능이 월등이 더 좋고, 인텔 칩셋은 오픈 소스 드라이버만 있고 성능도 좋습니다.

이해에 도움이 될까 싶어, 아직 프로토타입이고 많은 기능이 빠져있지만, 현재 개발 중인 시스템의 동작 화면을 녹화한 영상을 보여드립니다. 녹화에 사용한 프로그램은 gtk-recordMyDesktop입니다.

GUI 프로그래밍을 할 때마다 느끼는 점은 구현하기 위한 기술도 중요하지만, 결국 사용자를 배려하면서도 아름다움을 잃지 않는 참신한 아이디어 기반의 디자인이 더 중요하다는 점입니다. 물론 그렇기 때문에 디자이너라는 직업이 따로 있는 것이겠지만, 좋은 프로그램과 삶의 다양한 모습을 많이 보고, 많이 경험하고, 많이 참고해야 하는 지적 즐거움을 언제부터인가 프로그래머들은 남의 영역이라 멀리한 채 무미건조한 기술에만 전념하고 있는 건 아닌지 모르겠습니다.

최근 계속 연재되는 파이썬(Python) 언어와 GTK+ / Clutter / GStreamer 라이브러리를 이용한 GNOME 개발 동영상(screencast)도 볼만합니다. 몇몇 예제는 그놈 개발자 사이트 데모 프로그램과 겹치는 것도 있습니다.

1. GNOME 스크린캐스트 – 01. 첫번째 GTK+ 어플리케이션 (2011-06-16): 파이썬을 이용해 기본 기능을 가진 GTK+ 프로그램 만들기
2. GNOME 스크린캐스트 – 02. 화려한 사진 어플리케이션 만들기 (2011-06-22): 파이썬과 GTK+를 이용해 간단한 사진 프로그램 만들기
3. GNOME 스크린캐스트 – 03. 멋진 계산기 만들기 (2011-06-29): 파이썬과 GTK+를 이용해 간단한 계산기 프로그램 만들기
4. GNOME 스크린캐스트 – 04. 우아한 기타 튜너 만들기 (2011-07-07): 파이썬과 GTK+, GStreamer를 이용해 기타 튜너 프로그램 만들기
5. GNOME 스크린캐스트 – 05. 매력적인 동영상 재생기 만들기 (2011-07-15): 파이썬과 GTK+, GStreamer, Clutter를 이용해 동영상 재생기 만들기

gedit 텍스트 편집기와 Glade UI 편집기만을 이용해 파이썬 언어의 간결함과 GNOME 플랫폼 라이브러리의 강력함을 잘 보여주고 있습니다. 여담이지만, 영어가 짧아 단어만 알아듣는 본인도 코드만 보고 이해할 수 있었습니다. :)

물론 이 글에서 소개한 설명서는 대부분 아마도 많은 개발자에게 GNOME 플랫폼의 우수성을 전파하고 사용을 독려하기 위해 매우 기본적인 내용만 맛보기로 소개하기 때문에 더 심각하고(?) 자세한 내용을 알고 싶다면 각 기술에 대한 심층적인 공부가 필요합니다.

또한 GNOME 플랫폼 라이브러리라는 제목을 달고 있지만 대부분의 기술이 반드시 GNOME 환경에서만 동작하는 게 아니므로 리눅스 관련 개발자라면 한 번 들여다보는 것도 좋을 것 같습니다.

이 글에서 소개하려는 eventfd()는 파이프 역할을 어느 정도 대체하기 위해 최근(?) 리눅스 커널에 추가된 API입니다. 읽고 쓰기에 각각 다른 두 개의 파일 디스크립터를 사용하는 파이프와 달리 eventfd는 한 개의 파일 디스크립터를 가지고 동시에 읽고 쓰기 작업을 처리합니다. 또한 별도 커널 버퍼와 복사 과정이 필요한 파이프와 달리 정수 값을 더하고(쓰고) 읽는 작업만 처리하기 때문에 성능도 훨씬 좋다고 합니다. 물론 파일 디스크립터이기 때문에 poll() 등과 함께 사용할 수 있습니다.

동작 방식을 간단하게 설명하면, write() 호출시 64비트 정수값을 쓰면 내부 버퍼 값에 더하면서, read() 호출시 내부 버퍼 값이 0일 경우 기다리다가, 값이 바뀌면 그 값을 읽어오고 0으로 초기화합니다.(세마포어 방식일 경우 1을 읽어오고 그 값에서 1을 감소합니다) 즉, 읽기 작업에 대한 poll() 호출은 내부 버퍼 값이 0일 경우 입력이 없는 것으로, 1 이상의 값일 경우 입력이 있는 것으로 간주하고 디스크립터를 감지하게 됩니다. (예제 코드는 매뉴얼 페이지에 포함된 코드를 확인하시길… 물론 예제 코드는 쓰레드간 통신에도 잘 동작합니다)

매뉴얼에 의하면 리눅스 커널 2.6.22, glibc 2.8 버전부터 eventfd() 함수를 지원합니다. 대부분의 요즘 리눅스 데스크탑 / 서버 배포판에서는 당연히 사용할 수 있지만 임베디드 시스템에서는 버전을 확인해야할 필요가 있습니다. 물론, eventfd가 메시지 내용 자체를 전송할 수 없다는 단점도 있지만, 이와 함께 리눅스 커널이 제공하는 signalfd(), timerfd(), epoll() 등을 함께 사용하면 고전 유닉스 프로그래밍의 한계에서 벗어나 마음껏 이벤트 기반 코드를 만들 수 있습니다.

물론 이미 잘 만들어진 GLib 메인루프나 libevent 등과 같은 라이브러리를 사용하는 것도 좋지만… :)

요즘 GNOME 프로젝트 개발 흐름을 보면 크게 두 가지 언어, JavaScript와 Vala가 대두되고 있는데, GUI 같은 상위 제어 모듈은 JavaScript로 구현하고, 성능이 중요한 하위 모듈은 C + Vala로 구현한 뒤 이를 하나의 프로그램에서 합쳐서 성능과 개발 효율을 동시에 얻고자 하는 것 같습니다.

사실, GObject 프레임워크가 좋긴 하지만, 여러 고수준 언어에서 사용할 때와는 달리 C 언어에서 사용하려면 어려움이 많아서 비판을 많이 받습니다. Vala 언어는, 말하자면, 이러한 반복되는 코드 재작성(boilerplate code)과 자잘한 코딩을 획기적으로 줄여주면서 C 언어로 GObject 객체 지향 프로그램을 할 수 있도록 도와주는 역할을 하는 겁니다. C++의 복잡함은 싫고, 인터프리터 언어의 느림은 견디기 힘들고… 결국 목마른 사람들이 직접 우물을 판 셈입니다.

그렇다고 Vala 언어는 비단 GTK+ / Clutter 기반 GUI 프로그램을 개발하는데만 사용되지 않고, 서버 데몬[systemd] 같은 콘솔 프로그램 개발에도 사용합니다. 이미 수많은 프로그램이 Vala를 이용해 개발되었는데, C 언어로 개발되었던 기존 프로그램을 Vala 언어로 다시 작성한 것[Cheese]도 눈에 띕니다.

그러나, Vala 언어의 단점이라면, C 언어 부류인 C#과 문법이 비슷하긴 하지만, 무엇보다도 새 언어를 익혀야 한다는 점, 그리고 GLib / GObject 개념에 익숙하지 않을 경우 익히는데 조금 더 시간과 노력이 필요하다는 점입니다. 물론, 오픈 소스 리눅스 개발자 커뮤니티에서 개발되어, 아직은, 그 안에서만 사용하는 마이너 언어라는 한계 때문에, 즉 상용 벤더의 지원이나 Visual Studio, XCode 등과 같은 완벽한 통합 개발 환경도 없기 때문에, 많은 개발자를 끌어당길 매력이 부족한 것도 사실입니다. 하지만 한편으로는, 오픈 소스이기 때문에 오히려 미래가 더 투명한게 아닐까 하는 생각도 듭니다.

아무튼, Vala 언어에 대해 더 관심이 생기는 분은 소개, FAQ, 튜토리얼 문서 등을 한 번 훑어보시길 바랍니다. 샘플 코드도 많고, 튜토리얼도 참 많습니다. 아마 C++ / C# / Java / Python 등과 같은 객체 지향 언어에 익숙한 개발자라면 생각보다 어렵지 않다는 사실을 알게 될 겁니다. 더불어, Vala 컴파일러가 생성한 C 소스 코드를 한 번 확인해 보시면, 객체 지향 개념을 이런 식으로 코딩하고 구현할 수도 있구나 하는, 결국 중요한 건 개발자의 능력이지, 사용하는 언어나 개발도구가 전부가 아니란 것도 느끼게 됩니다.

라자냐 코드는 일종의 프로그램 구조인데, 잘 정의되어 분리된 여러 계층(layer)을 가지는 것이 특징입니다. 각각의 코드 계층은 잘 정의된 인터페이스를 통해 아래 계층의 서비스에 접근합니다. 이 용어는 프로그램 구조를 파스타에 비유하는 스파케티 코드와 비교되곤 하는데, 다른 재료(고기, 소스, 채소, 치즈 등)가 각각 파스타 조각으로 분리되어 하나의 접시에 담긴 라자냐의 계층 구조에 기인합니다.

라자냐 코드의 흔한 예 중 하나는 다른 하부 시스템 , 가령 웹 어플리케이션과 비즈니스 로직, 관계형 데이터베이스 사이에 존재하는 인터페이스입니다. 또한 프로그래밍 기법 중에, 프로그램 전체 구조에서 레벨마다 다른 프로그래밍 언어를 사용하는 경우에도 이를 연결하는 계층이 존재하는데 이 역시 라자냐 코드의 일종입니다. 일반적인 클라이언트-서버 응용 프로그램 역시 대부분 잘 정의된 인터페이스를 통해 통신하므로 라자냐 코드라고 할 수 있습니다.

대개 라자냐 코드는 다른 계층간에 인캡슐레이션(encapsulation)을 강요하기 때문에, 문제의 하부 시스템은 잘 정의된 메카니즘(SQL, RPC, FFI 등)을 제외한 다른 통신 수단이 없습니다. 물론, 시스템의 개별적인 레이어는 덜 구조화되어 있거나 엉망으로 조직화되어 있을 수도 있습니다.

위 설명을 보면 라자냐 코드는 전혀 나쁜 것 같지 않은데 도대체 무슨 굴레를 벗어난다고 하는 걸까, 모든 진리가 말하듯이, 과하면 부족함만 못한 법입니다. 너무 많은 계층화는 성능 개선 / 기능 확장 / 유지 보수 디버깅에 오히려 방해가 되어 버리고 맙니다. 예를 들어 GNOME 2 플랫폼에서는 용도별로 개발된 수많은 libgnome* 라이브러리가 존재했지만 GNOME 3 개발 과정에서 대부분 기능을 GLib / GTK+ 라이브러리에 통합한 이유 중 하나도 마찬가지일 겁니다. 여담이지만, 사실 그래서 GTK+는 모든 기능이 종합 선물 셋트처럼 제공되는 QT 애호가들에게 많은 비난을 받아왔었던 것도 사실입니다. 무슨 라이브러리 의존성이 이렇게 많고 복잡한지… 물론 아직도 GTK+ 툴킷 자체는 여전히 기능별 라이브러리에 의존하고 있지만 예전에 비해 정말 많이 정리된 셈입니다.

아무튼, 스스로 만든 라자냐 코드의 굴레 중에서 가장 문제가 되는 부분은, 멀티 플랫폼을 고려하는 것과 더불어 향후 라이브러리 교체시 수고를 덜기 위해 어떤 라이브러리 API를 그대로 사용하지 않고 일종의 확장성있는 랩퍼(wrapper) API를 따로 만들어 사용한 점입니다.  결과적으로, 라이브러리 자체도 계속 업그레이드 되기 때문에 이를 반영해야 하고, 다른 라이브러리로 교체하는 경우도 별로 없고, 성능 개선이나 기능 추가를 위해 끊임없이 랩퍼 API를 추가하면서, 디버깅할 때는 한 동작을 위해 두 세 단계 이상의 계층을 따라 가야하고… 배보다 배꼽이 더 커지는 경우가 발생해 버리는 상황에 이르게 됩니다.

두번째로 문제가 되는 부분은, 기능 하나를 구현할때 구성 모듈을 너무 세분하게 나눈 점입니다. 특히, 수평적이 아닌 수직적으로 기능을 나눌때 적절한 범위를 넘어가버리면, 새 기능 추가시 매우 많은 모듈에 대한 의존성 검사, 부작용 검사 등의 작업이 몇 배나 어렵습니다. 예를 들어 상위 계층에 있는 기능을 하위 계층에서 사용해야 하는 경우가 발생하면 이를 위한 인터페이스를 설계하는데 시간이 더 걸리는 경우도 많습니다. 그냥 간단하게 하나의 모듈로 작성하면 되었을 걸…

과하면 부족함만 못하다… 언제 어떻게 무엇이 될 지 모르는 미래를 위해 미리 고민해서 확장성 있는 구조를 설계하는데 노력하는 것보다, 지금 당장의 요구 사항 수준에서 아무 문제없이 잘 돌아가는, 향후 쉽게 이해하고 확장할 수 있는 간단한 구조의 코드를 작성하는게 맞는 것 같습니다. 게다가 향후 발생할 요구사항을 미리 알 지 못하는데 미리 확장성있게 설계한다는 것 자체가 모순이 아닌가 하는 생각도 들고…

그런데 여담이지만, 아치리눅스 부팅 과정 커스터마이징과 속도를 경험해봐서 그런 건지, 범용 배포판은 어쩔 수 없이 모든 사용자가 만족할 수 있도록 가능한 많은 서비스 프로그램을 기본적으로 설치하고 이를 모두 시작하기 때문에 느려질 수 밖에 없는 건데, 부팅 속도 향상을 위해 시작 프로세스 관리 데몬의 성능과 기능을 개선하는 방향으로만 접근하고 있는 게 아닌가 하는 생각도 듭니다. 물론 다른 고급 기능을 제공한다고 하지만, 어차피 대부분의 기능은 배포판 개발자들만 사용하는 거고… :) 참고로, 이 발표자료만 봐도 부팅 속도와 초기화 프로그램의 능력은 무관한 것 같습니다.

아무튼, 지금까지 설명한 배경이 최근 임베디드 리눅스 컨퍼런스 2011 발표 슬라이드를 읽다가 PCD(Process Control Daemon)라는 프로세스 관리 데몬을 소개하는 내용을 보고 흥미를 가질 수 밖에 없었던 이유입니다. 위에 소개한 최신 프로그램들이 제공하는 기본 기능을 충실히 구현한 것은 물론, 임베디드 시스템을 우선 대상으로 개발했기 때문에 실행파일 크기가 매우 작고 빠르다는 점이 가장 매력적인 장점인 것 같습니다. (자세한 기능은 직접 확인해 보시길… :)

Systemd / Upstart 프로그램은 기능은 강력하지만 임베디드 시스템에 적용하기에는 너무 덩치가 크고 라이브러리 의존성도 무시하지 못할만큼 무겁습니다. 또한 임베디드 시스템은 개발자가 시스템의 모든 프로세스를 통제하고 완벽하게 관리해야 하기 때문에, 시스템에 대해 배포판 개발자와 동등하거나 더 많은 이해를 필요로 하므로 이러한 도구를 이용하면 작업이 수월해질 수 있습니다. 더 나아가, 이 프로그램을 조금 더 응용하면 데스크탑 / 서버용 시스템에서 여러 프로세스로 동작하는 시스템을 개발할 때도 유용하지 않을까 하는 생각도 듭니다.

물론 임베디드 리눅스 개발시 하나의 셸 스크립트 안에서 부팅 과정에 필요한 모든 작업을 처리하는 방식이 무조건 나쁜 건 아닙니다. 다만 복잡도가 더 높은 시스템을 설계할 때는 반드시 이런 프로세스 / 세션 관리 / 예외 처리 프로그램을 사용하거나 알아두면 나중에 참고하는 데 도움이 되지 않을까 생각해 봅니다.

내장 웹서버 라이브러리를 사용하면 얻을 수 있는 가장 좋은 장점은 MJPEG, RTSP-over-HTTP 등과 같은 웹기반 스트리밍 서버를 만들때 매우 편리하다는 점입니다. 한 프로세스 안에서 웹서버 + 스트리밍 생성 루틴이 함께 동작하므로 메모리 복사 오버헤드가 줄어들고 프로그래밍 복잡도 역시 감소합니다. 또한 CGI 프로세스가 따로 동작할 필요가 없으므로 웹을 통해 설정을 변경해도 별도의 프로세스간 통신이 불필요합니다.

물론, 내장 웹서버 방식이 장점만 있는 건 아닙니다. 기존 스탠드얼론 웹서버가 알아서 자동으로 해주던 부분, 예를 들어 디렉토리 인덱스 파일 생성, 동시 접속 클라이언트 수 관리, 클라이언트 캐시를 위한 수정 시각 고려 등을 프로그래머가 직접 작성해야 합니다. 특히 libmicrohttpd 라이브리는 GoAhead 등과 같은 상용 라이브러리에 비하면 자동화 부분이 조금 부족합니다. 예를 들어 파일 시스템의 일반 파일에 대한 웹서비스 처리도 직접 만들어야 합니다. 물론, 대부분 필요한 기능은 예제 소스를 참고하면 어렵지 않게 구현할 수 있습니다. 하지만 제 생각에는, 웹서버 라이브러리가 너무 많은 기능을 자동화하지 않는게 오히려 더 맞다고 생각하는데, 왜냐하면 대부분 응용 프로그램에서 웹서버를 내장하는 경우는 특수한 용도(RESTful / SOAP)이거나 필요한 기능만 구현하기 위해서이기 때문에 나머지는 모두 개발자가 제어하는게 라이브러리의 제 역할이 아닌가 생각합니다.

그런데, 요즘 기존 코드를 리팩토링하면서 가능한 오래된(?) 라이브러리에 대한 의존성을 없애고 있는데 위에서 설명한 작업을 하는 함수가 리눅스 기본 glibc 라이브러리가 당연히 제공하는 걸 알게 되어 잠시 허탈했습니다.

다음은 도메인 이름을 인수로 주면 해당 도메인의 MX 레코드, 즉 메일서버 호스트를 glibc API를 이용해 작성한 코드입니다.

#include <netinet/in.h>
#include <arpa/nameser.h>
#include <resolv.h>
 
static char *
lookup_mx (const char *name)
{
  unsigned char response[NS_PACKETSZ];  /* big enough, right? */
  ns_msg        handle;
  int           ns_index;
  int           len;
 
  len = res_search (name, C_IN, T_MX, response, sizeof (response));
  if (len < 0)
    {
      /* failed to search MX records */
      return strdup (name);
    }
  if (ns_initparse (response, len, &handle) < 0)
    {
      /* failed to parse MX records for '%s'", name); */
      return strdup (name);
    }
  len = ns_msg_count (handle, ns_s_an);
  if (len <= 0)
    {
      /* no mx records */
      return strdup (name);
    }
  for (ns_index = 0; ns_index < len; ns_index++)
    {
      ns_rr rr;
      char  dispbuf[4096];
 
      if (ns_parserr (&handle, ns_s_an, ns_index, &rr))
        {
          /* WARN: ns_parserr failed */
          continue;
        }
      ns_sprintrr (&handle, &rr, NULL, NULL, dispbuf, sizeof (dispbuf));
      if (ns_rr_class (rr) == ns_c_in && ns_rr_type (rr) == ns_t_mx)
        {
          char mxname[MAXDNAME];
 
          dn_expand (ns_msg_base (handle),
                     ns_msg_base (handle) + ns_msg_size (handle),
                     ns_rr_rdata(rr) + NS_INT16SZ,
                     mxname,
                     sizeof (mxname));
          return strdup (mxname);
        }
    }
  return strdup (name);
}

관련 자료는 Stack Overflow에서 본 것 같기도 하고… 아무튼, 명색이 전문 리눅스 C 프로그래머로서 15년 넘게 버티고 있으면서도 아직까지도 기본 C 라이브러리가 제공하는 함수도 제대로 알지 못하는 스스로를 돌아보게 됩니다. :(