알고 계십니까? 심시티 3000에는 네이티브 리눅스 포트가 있다는 사실을. 당장 구글에서 '심시티 3000 리눅스'라고 검색을 해도 이 사실은 잘 알려져 있지 않다. 리눅스 포트가 나온 건 심시티 3000이 나왔을 무렵이었고, 지금은 망해버린 로키 소프트웨어(2002년에 망했지만 아직도 웹 사이트는 열려 있다)가 포팅을 하였다. 같은 시기에 나온 윈도용 심시티 3000은 최근의 윈도에서도 잘 돌아가지만, 리눅스 세계는 자고 일어나면 뭔가 바뀌어 있는데다가 유저랜드까지도 오픈소스가 대부분이기 때문에, 이러한 바이너리로만 배포되는 프로그램은 '지원하는 배포판'을 벗어나면 삽질의 시작이다. 심시티 3000 또한 그렇다.

어쨌든, 로키 소프트웨어가 망한 이후에 여러 사람들이 저 때 당시 사용되었던 라이브러리를 별도로 패키징해서, 로키 소프트웨어가 포팅했던 게임을 비교적 최근의 배포판에서도 돌릴 수 있도록 해 주는 별도의 라이브러리 패키지를 만들었다. 대개 loki_compat 따위로 검색해 보면 나온다. 우분투 6.xx에서 심시티 3000을 돌리려면 이 패키지를 설치해야 한다는 사실에서 알 수 있듯이, 지원 따위 끊긴 상당히 오래된 버전의 glibc/SDL/기타등등 라이브러리를 사용했기 때문에 이건 필수다. 하지만 주의깊게 지시 사항을 따라하지 않으면 실패하기 십상이며, 나도 이 때문에 loki_compat 라이브러리를 받아 놓고도 이게 제대로 실행되는 걸 본 적이 없다.

최근에 나온 프로젝트 중 loki installers for linux gamers, 줄여서 liflg가 있다. 이 프로젝트는 오픈소스로 공개된 loki_setup을 사용하여, loki_compat 라이브러리와 적절한 설치 스크립트를 하나로 묶어서 게임 인스톨러를 제작하였다. loki_compat 라이브러리를 수동 설치할 때와는 달리 지정한 경로 안에 알아서 압축까지 풀어 주고, 이 라이브러리를 사용하는 실행 스크립트도 알아서 만들어 준다. 그래서 이 방법을 사용하면 설치 및 실행 성공률도 상당히 높다. 심시티 3000 리눅스 버전은 인터넷에서 구하기가 쉽지 않고, 토렌트를 뒤져도 잘 나오지 않는다. 모종의 경로로 구해둔 게 있긴 하지만 괜히 업로드해 뒀다가 저작권 문제가 생길 수 있으므로 여기에서는 생략한다. 심시티 3000 리눅스 버전 iso 파일을 구했으면 인스톨러를 다운로드받는다. 베타라고 쓰여 있지만 잘 작동한다. 32비트 리눅스를 사용하고 있으면 넘어가고, 64비트 리눅스를 사용하고 있으면 미리 32비트 호환용 라이브러리를 설치해 둔다. 데비안 amd64 unstable에서 실험 결과 잘 작동한다.

다운로드가 끝났으면 구해 둔 iso 파일을 CD에 굽는다. 아직까지 loki_installer가 CD-ROM을 인식하는 건 잘하지, 루프백으로 마운트시켜 둔 CD 이미지를 인식하지는 못 하는 것 같다. 방법을 알고 있으면 제보 바란다. 그 다음 다운로드받은 인스톨러 파일에 실행 권한을 준다. Dolphin의 경우 오른쪽 클릭->속성->권한->실행 가능에 체크하면 된다. 그 다음 CD를 삽입하고 인스톨러를 실행시킨다. 일반 사용자로 실행시키면 자기 홈 디렉터리 아래, 루트로 실행시키면 /usr/local/games 아래에 설치한다. 첫 화면이 지나면 설치 경로와 구성 요소를 물어본다. 이 때 언어, Building Arcitect, 인트로 영상 설치 여부를 같이 물어오므로 필요하면 선택한다. 설치가 시작되면 CD에서 파일을 복사하고, 알아서 시작 메뉴 항목도 만들어 준다.

자 이제 시작 메뉴 항목을 통해서 심시티 3000을 실행시켜 보자. 첫 실행 시 해상도는 640x480이므로, 게임 옵션을 적절히 수정해야 한다. Geforce 8400M GS, 듀얼 모니터 환경에서 테스트해 본 결과, 1280x1024는 게임이 진행될수록 끊김 현상이 나오므로 1024x768이나 1152x864 해상도를 추천한다. 인터페이스, 도시 건설, 글꼴을 비롯한 모든 요소가 윈도용 심시티 3000과 동일하므로, 심지어는 치트키까지 똑같이 쓸 수 있다.

그러면 즐겜.

대부분의 국내 휴대폰들은 MMF라는 야마하에서 만든 벨소리 포맷을 사용한다. 경우에 따라서 미디로 사용할 수도 있고 PCM을 그대로 집어넣을 수 있다. 국내 휴대폰 벨소리는 MMF로 통일되어 있는데, 일부 해외 휴대폰 및 스마트폰은 MMF를 지원하지 않는다. 어쩌면 노키아 휴대폰으로 갈아타면서 잃어버린 것 중 가장 큰 게 MMF 벨소리일지도 모른다. 다행히도 MMF를 지원하지 않는 휴대폰은 일반적인 MIDI는 대부분 지원한다.

MIDI나 음악 파일을 MMF로 만드는 방법은 국내에도 많이 소개되어 있지만 그 역은 잘 알려져 있지 않다. 원음벨 MMF 파일은 PCM 신호를 포함하고 있으므로 MIDI로 절대 변환할 수 없다. MP3 등의 음악 파일이 '음 자체'를 저장한다면, MIDI는 '악보'를 저장한다. 악보를 보고 연주하는 건 누구나 가능하지만, 흘러나오는 곡만 듣고 악보를 그려내는 사람은 신의 영역에 속한다. 따라서 원음벨은 같은 속성을 가지는 MP3 등으로 변환하는 게 좋으며, 미디벨은 MP3 등의 음악 파일로 바꾸기보다는 MIDI를 그대로 뽑아내는 게 용량대비 효율이 좋다. 녹음하는 뻘짓 할 필요가 없다.

MMF를 MIDI로 바꾸는 프로그램은 잘 나오지 않는다. 처음 찾아본 프로그램은 Mobile Music Polyphonic이었다. 과거 버전은 확장자만 바꾼 MMF 파일(ma2, ma3 등)을 제대로 인식하지 못하고 UI가 좀 불편해서, 최신 버전을 구해 봤더니 이건 완전 아이폰 전용으로 바뀌어 있어서 원하는 기능인 MIDI 추출은 테스트해 볼 수도 없었다. 좀 더 찾아봤더니 Plinksoft RingtoneComposer 역시 같은 기능을 한다. 아직까지 데모 버전의 제한이 무엇인지는 파악하지 못했지만, MMF->MID 변환 중 파일을 잘라먹지는 않는 것 같다. 그래서 비밀 댓글로 과자제보 받습니다.

하여튼 처음 프로그램을 켜면 UI가 그다지 단순해 보이지는 않는다. 일단 File->Open SMAF File로 가서 MMF 파일을 하나 찍어서 열자. 원음벨이면 미디 트랙이 하나만 보이고 재생을 눌러도 아무 반응이 없으며, 미디벨이면 트랙이 여러 개 보인다. 원음벨은 MMF를 변환하기보다는 MP3과 같은 더 고음질 파일을 잘라서 쓰는 걸 추천한다. 아무튼 미리 들어보고 원하는 대로 소리가 나는지 확인해 보자. 소리가 제대로 나면 File->Save를 눌러서 미디로 저장한 다음 빠져나온다.

이제 원하는 방법을 써서 휴대폰에 미디 파일을 집어넣자. 기본 음악 재생기로도 재생되며, 프로필 메뉴에서 원하는 파일을 지정해 주면 벨소리로 쓸 수 있다. 이제 MMF 미디벨을 폰 바꿨다고 버리지 말자. 하지만 원음벨은 새로 구하는 게 더 낫다.

기존에 Qt로 프로그램을 짜 봤다면 Qt/S60을 쓸 수 있다는 게 얼마나 흥분되는 일인지 알 수 있다. Qt/S60은 트롤텍이 노키아에 인수된 후부터 활발히 개발된 Qt 포트이다. 윈도, 맥 OS X, (임베디드) 리눅스 이외 기종으로 제일 처음 나온 포트는 윈도 모바일이지만, 노키아에 인수당한 이후 윈도 모바일용 Qt보다는 Qt/S60에 더 많은 신경을 쓰고 있음을 알 수 있다. 마에모도 Qt로 전향할 예정인데다가, 든든한 데스크톱 우군 KDE가 버텨 주고 있어서 지금 안드로이드나 아이폰에 부화뇌동하느니 Qt 프로그래밍을 익혀 두는 것도 몸에 나쁘지는 않을 것이다.

Qt의 모토는 Code Less, Create More, Deploy Anywhere다. 노키아 인수 전까지는 앞 두 마디만 사용했으며, 노키아가 Qt 로고를 현재처럼 바꾼 이후 Deploy Anywhere가 같이 추가되었다. 과연 Qt로 짠 소스 코드가 Deploy Anywhere가 될 수 있을지 한 번 실험해 보기로 했다. 일단 Qt/S60을 구해서 설치해 보자. 2009년 11월 현재 Qt 홈페이지 페인 화면에 Qt/S60 4.6.0 베타 링크가 걸려 있으므로, 일단 이거 SDK를 다운받아 두자. Qt/S60은 S60을 기반으로 움직이므로, 그 까다롭다는 S60 SDK도 같이 설치되어 있어야 한다. Carbide.C++(IDE), S60v3 FP2 SDK, Open C/C++ 플러그인 삼대천왕을 설치하면 된다. 전부 한 덩치 하는 몸이라서 시간이 꽤 걸렸고, 이 순서대로 설치하지 않으면 미묘한 오류가 발생한다. 설치를 마음대로 했다가 3시간을 삽질하는 일이 없길 바란다.

그 다음 Qt/S60을 설치한다. 깔려 있는 SDK를 자동으로 인식하고 그에 맞는 Qt를 설치해 준다. 설치가 끝난 다음, Carbide.C++ 쪽 환경 변수를 먼저 등록한 다음 Qt/S60 명령 프롬프트를 실행해야 라이브러리 및 컴파일러 경로를 헤매지 않는다. 이것 때문에 1시간을 또 고생했다. 여기까지 잘 왔으면, Qt 명령 프롬프트를 실행시켜서 demos나 examples 폴더로 이동한 다음, qmake-make를 실행시켜서 예제를 빌드해 보고, make run을 통해서 각각 예제를 실행시켜 본다. make 실행 시 기본 타겟은 debug-winscw로, 에뮬레이터를 통해 실행된다. make distclean을 실행시켜 줘야 에뮬레이터에서 흔적이 사라지므로 테스트 후 실행시켜주는 게 좋다. S60 SDK에 내장된 에뮬레이터는 그럭저럭 쓸만하지만, 한글 글꼴이 기본적으로 없다는 건 알아 두어야 한다.

정상 작동을 테스트해 보았으면 기존 Qt 프로그램을 포팅해 보자. QMake를 사용하는 프로젝트라면 아무 무리 없이 Qt/S60으로 포팅 가능하다. 얼마든지 리눅스에서 Qt로 짰던 프로그램을 S60으로 '소스 한 줄 고치지 않고' 포팅 가능하다. 심비안 플랫폼은 모든 실행 파일에 고유 UID가 붙는다. 이게 겹치면 시밤쾅하기 때문에 프로그램을 배포하려면 UID를 따야 한다. 돈 내는 건 없으므로 전문적으로 뭔가를 만들어 보려면 UID를 신청해 보자. 발급받은 UID가 있으면 .pro 파일에 UID를 적어 주고, 없으면 qmake가 테스트용 UID를 만들어 준다. make release-gcce를 내린 다음 make sis라는 명령을 내리면 sis 파일을 만든다. 테스트 인증서로 서명되었으므로, 실제 배포할 때는 인증서 문제를 해결해야 한다. 이 외에도 약 10MB에 달하는 Qt 라이브러리 설치 문제도 신경써야 한다. 현재는 Qt/S60이 베타 단계라서 배포할 때 신경이 거슬리겠지만, 정식 릴리즈가 나온 다음에는 휴대폰 롬에 통합될 수도 있거나 용량이 더 적어질 수도 있다.

현재 Qt 4.6.0 베타는 S60에서 살짝은 껄끄럽게 돌아간다. S60v5는 터치 인터페이스를 지원하지만 S60v3은 위젯을 돌아다닐 때 키패드를 사용해야 하며, 심비안 네이티브 프로그램에 비해서 살짝 멈칫하는 게 느껴진다. FEP도 잘 붙어서 한글 입력도 무리없이 할 수 있다. 대부분의 UI 구성요소는 S60 테마를 그대로 따르므도 생긴 거의 이질감은 전혀 느껴지지 않는다. Qt의 장점은 여기서 드러난다. 오늘 오후동안 짜 본 노래방 검색 프로그램을 휴대폰에서 한 번 돌려 보았다. Qt의 GUI와 SQL 부분을 사용한다. PyS60으로 짜려고 했으나, SQLite 모듈이 없어서 Qt의 SQLite 모듈을 사용하려고 Qt를 사용했다. 아직까지 휴대폰에서 좀 동작이 끊기는 감이 없잖아 있지만, 아직 Qt/S60은 베타 단계이기 때문에 정식 릴리즈가 되면 더 빨라질 가능성이 열려 있다.

기존에 Qt로 프로그램을 만들어 봤으면 복잡한 S60 C/C++를 배우지 않고도 S60 휴대폰에 프로그램을 바로 올릴 수 있으므로, 뭔가 만들어보고 싶으면 과감하게 도전해 보자.

ps. 노래방 검색 프로그램은 아직 개발 중이며, 역시 아직 개발 중인 Qt/S60 라이브러리를 사용한다. Qt/S60이 정식 출시되는 대로 공개할 예정이다.

리눅스 커널 소스 트리를 뒤지다 보면 두 종류의 비디오 드라이버를 찾을 수 있다. 하나는 우리가 흔히 말하는 그래픽 드라이버인 DRI 드라이버이고, 또 다른 하나는 프레임버퍼 드라이버이다. 전자는 X.org 하에서의 2D/3D 가속 등을 담당하며, 후자는 X.org가 뜨기 전까지, 흔히 콘솔이라고 말하는 영역에서 그래픽 처리를 담당한다. 프레임버퍼를 전혀 사용하지 않으면 과거 도스 시절에나 볼 수 있었던 콘솔이 뜨지만, 프레임버퍼를 사용하면 해상도도 높아지고, mplayer를 사용하여 동영상도 볼 수 있다. 부팅 스플래시도 이렇게 처리한다.

GRUB 1에서 리눅스 프레임버퍼를 사용하려면 커널 옵션으로 vga=xxx 또는 video=xxx를 추가해 줘야 했다. vga=xxx 옵션을 추가하면 하드웨어 가속을 전혀 사용하지 않는 vesafb를 불러온다. vesafb는 이름처럼 표준적인 기능만 제공해서 VESA 표준이 아닌 해상도(와이드 포함)를 사용하려면 하드웨어 정보를 들여다봐서 모드 값을 알아내야 했다. 이외의 다른 프레임버퍼 드라이버를 사용하려면 video=(프레임버퍼 드라이버) 식으로 지정해 주면 된다.

GRUB 2로 진화하면서 GRUB 구조가 완전히 바뀌면서 프레임버퍼 설정 방법도 바뀌었다. 더 이상 menu.lst 파일의 주석에 정보를 숨기지 않고, 모듈화된 설정 파일로 바뀌었다. 프레임버퍼 설정 역시  GRUB 1에서 썼던 것처럼 vga=xxx라는 커널 옵션을 줘도 커널은 이 옵션을 적절히 무시한다. 그리고 해상도를 지정하기 위해서 암호같은 모드 값을 외울 필요도 없어졌다. 데비안 기준, /etc/default/grub 파일을 수정해 주면 게임이 끝난다. 처음 파일을 열어 보면 다음과 비슷할 것이다.

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

# Uncomment to disable graphical terminal (grub-pc only) #GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
GRUB_GFXMODE=1280x800
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entrys
#GRUB_DISABLE_LINUX_RECOVERY="true"

보이는 것처럼 menu.lst 파일의 주석 대신 환경 변수를 사용한다. 그래픽 모드를 사용하려면 GRUB_GFXMODE의 주석을 풀고 원하는 해상도 및 색 농도로 설정해 주면 된다. 1024x768의 32비트를 사용하려면 1024x768x32로 입력해 주면 된다. 설정을 업데이트했으면 update-grub 명령을 내려서 실제 grub.cfg 파일에 반영시키면 된다. 다음 부팅 때부터 GRUB은 그래픽 모드에서 실행되며, GRUB에서 설정된 해상도가 리눅스 프레임버퍼까지 간다. 이 과정에서 vesafb 모듈이 자동으로 올라가며, video=xxxxx 옵션을 주면 선택한 드라이버를 사용한다.

내 서브노트북 Q10을 업어오면서, 원래 계획은 intelfb 드라이버를 올려서 X11 없는 GUI 사용이었다. 인텔 830M 그래픽은 분명히 intelfb 드라이버의 지원 목록에 있었다. 하지만 intelfb 드라이버는 유명한 에러 메시지를 내놓으면서, 정작 뚜렷한 해결책도 없었기 때문에 X11을 그냥 올렸고 KDE를 설치했다. intelfb 드라이버의 문제는 다음 문단에 설명한다.

대개의 프레임버퍼 드라이버는 video 옵션만 지정해 주면 되는데, intelfb 드라이버, 특히 노트북에서 사용하려면 상당히 머리가 아프다. GRUB에서 그래픽 환경 설정을 하지 않고 보통의 프레임버퍼 드라이버처럼 video=intel:mode=1024x768 식으로 해상도를 지정해 주면 노트북 사용자들을 좌절하게 만드는 "intelfb: Video mode must be programmed at boot time" 오류가 뜬다. vga=xxx 옵션을 같이 줘 놓으면 비디오 모드는 제대로 찾는데, 이제는 vesafb와 순위 쟁탈전을 벌이면서 "intelfb: cannot acquire agp"나 "intelfb: Cannot reserve FB region" 같은 오류가 뜨면서 기대하던 인텔 프레임버퍼가 뜨지 않는다.

원인을 계속 찾다 보니, 데비안 커널에 내장된 vesafb가 원인이었다. 커널 컴파일을 새로 하면서 vesafb를 빼 버리고, initramfs를 만들면서 intel_agp, agpgart, intelfb 모듈을 추가시켜 줬다. 어차피 프레임버퍼에 관심을 가질 정도로 리눅스를 잘 아는 사람이라면 커널 컴파일이 무엇인지는 알 테니, 여기에서 방법은 생략하겠다. 어떻게 컴파일을 하든, vesafb를 빼고 intelfb를 포함해서 컴파일해야 한다. 내 경우, 서브의 사양이 심각하게 안 좋아서 대부분의 안 쓰는 모듈을 과감하게 빼고 컴파일했다.

커널 컴파일과 initramfs 생성이 끝난 다음, GRUB 설정을 수정해서 video=intelfb 옵션을 추가해 주었다. 반신반의했지만 성공했다. 비디오 모드를 바꿀 수 없다는 경고 메시지가 지나갔지만, 프레임버퍼 정보를 보니 인텔 프레임버퍼를 정확하게 잡아 주었다. 여기까지 왔다면 프레임버퍼를 사용하는 리눅스 프로그램은 무엇이든지 쓸 수 있다. mplayer를 사용해서 영화를 볼 수도 있고, fim으로 그림을 보거나 w3m-img를 설치해서 그림까지 보면서 웹을 즐길 수 있다. fbgrab을 설치하면 프레임버퍼의 스크린샷을 찍을 수 있고, gpm을 설치하면 마우스를 사용할 수 있다.

아래는 부팅 동영상과 실제 인텔 프레임버퍼를 사용한다는 걸 보여 주는 명령들이다.

요약하면, 데비안을 사용하는 노트북에서 intelfb를 제대로 쓰려면 커널을 다시 컴파일해야 한다. 이 때 기본 내장된 vesafb 옵션을 끄지 않으면 서로간의 충돌 때문에 intelfb가 올라오지 않는다. 커널을 새로 설치한 다음, GRUB 설정 파일을 편집해서 원하는 해상도를 설정하고, 리눅스 커널 인자에 video=intelfb를 추가해서 인텔 프레임버퍼를 사용하게 하면 된다.

사실 노키아 N810에 내장된 브라우저는 충분히 강력하다. 한 박자 쉬는 것만 감수할 수 있으면 어지간한 큰 사이트도 잘 들어가진다. 해상도도 800x480으로 꽤나 높기 때문에, 그냥 PDA용 사이트에 들어가면, 화면을 돌리지 않는 한 가로가 텅 비는 사태가 발생한다. 디자인이 잘 되어서 가로 800픽셀도 문제없이 소화해낸다면 이야기가 달라지지만. 그래서 이놈으로 인터넷을 할 때에는 모바일 사이트를 쓰는 게 불편하다. 기능 제약도 있고 모양이 좋지 않아서이다.

그런데 싸이월드 미니는 아닌 것 같다. 애시당초 이게 나온 이유가 옴니아 때문이다. 옴니아의 액정 해상도도 800x480이기 때문에 잘리거나 남는 공간 없이 잘 보인다. 게다가 이걸 만들면서 기존에 쩡했던 PDA용 스윙 싸이월드 페이지를 없애버려서 별 수 없이 새로운 싸이월드 미니를 써야 한다. 옴니아 특화 서비스랍시고 아무 브라우저나 접속하면 츤츤댄다. 그냥 브라우저로 싸이월드 미니를 들어가면 이런 말이 뜬다

문제는 저기서 지원 단말기를 눌러도 옴니아밖에 없다. 하여간 기존 스윙 싸이월드 사용자는 어쩌라고. 스마트폰뿐만 아니라 넷북 또한 가로 해상도 제한이 있어서 저 서비스를 사용하는 게 나을수도 있다. 하여간 저 상황에서 제대로 된 페이지를 보려면 훼이크를 써야 한다. 다행히도 저장소만 잘 추가해 주면 훼이크를 쓸 준비는 끝난다. 이미 User Agent Switcher가 있다. 링크를 따라 가면 원클릭으로 설치할 수 있는 방법이 있으며, MicroB를 두 번 껐다 켜지 않으면 낚일 수도 있다.

아래 사진은 User Agent Switcher가 제대로 설치되었을 때 패키지 목록에 뜨는 화면이다. 하여간 이걸 설치하고 브라우저를 두 번 껐다 켜면, 별다르게 추가되는 메뉴가 없어서 낚일 수도 있다. 다른 MicroB용 확장 기능이 그렇듯이 얘도 별도의 메뉴를 추가하지 않는다. 따라서 암호같은 설정 페이지 URL(chrome://useragentswitcher/content/config.html)을 직접 입력해야 한다. 자주 사용한다면 저걸 책갈피에 추가하는 게 좋다.

한술 더 떠서 새 사용자 에이전트 입력도 상당히 불편하다. Add를 누르면 사용자 에이전트를 구성하는 각각 구성 요소를 순서대로 물어본다. 되돌아갈 수도 없어서 문제다. 한 번 틀렸으면 삽되므로 처음부터 제대로 입력할 필요가 있다. 이 블로그에 따르면 싸이월드 미니를 띄워 주는 사용자 에이전트가 두 종류 있다고 한다. 하나는 옴니아에 내장된 Pocket IE, 다른 하나는 Opera이다. 둘 중 아무거나 써도 된다고 하니 여기서는 Opera의 사용자 에이전트를 입력시켜 보겠다.

하여간 저 창에서 Add를 누르면 사용자 에이전트 설명, 서버로 전달할 문자열, 프로그램 이름, 버전, 플랫폼, 제조사, 제조사 하위 설명 등을 순서대로 물어온다. 오페라의 사용자 에이전트를 입력하기 위해서 나는 이 과정을 거쳤다.

• Description: Opera 9.5 (TMONIA)
• User Agent: Opera/9.5 (Windows NT 5.1; SKT; U; en)
• App Name: Opera
• App Version: 9.5 (Windows NT 5.1; SKT; U; en)
• 나머지: 비움

복사해서 붙여넣기가 상당히 압박스러우므로 이 순서와 문자열을 웬만하면 기억해 둬야 한다. Pocket IE 정보를 추가하는 것도 비슷하게 하면 된다. 힘겨운 과정을 거쳐서 입력을 다 시키면 이렇게 된다.

방금 추가한 사용자 에이전트를 선택한 다음, Choose Selected User Agent를 누른 다음 다시 싸이월드 미니로 들어간다. 이제 제대로 된 페이지가 뜬다.

가로 해상도가 800이 나와 줘서 스크롤의 압박 없이 볼 수 있다. 미니홈피나 클럽도 이 상태에서 잘 된다. 아무튼 SK컴즈에서 싸이월드 미니를 옴니아 전용으로만 쓰지 말고 다른 장치에서 접속할 수 있도록 바꿔 두길 바랄 뿐이다.

아주 잠깐동안 블로그를 워드프레스로 이전했다 다시 텍스트큐브로 돌아오는 엄청난 삽질을 하였다. 그 과정도 참 복잡했던 것이 워드프레스 2.3으로 개발되었던 tc2wp라는 툴을 사용해서 텍스트큐브 백업 파일을 불러온 다음 워드프레스 2.7로 다시 올리는 식으로 설치하는 등 엄청난 삽질을 했다. 물론 이 과정에서 텍스트큐브 백업 파일을 날리지 않았기 때문에 다시 텍스트큐브로 돌아올 때 워드프레스 파일을 가지고 장난치는 과정을 할 필요가 없어서 다행이었다.

아무튼 워드프레스가 나쁘지는 않았지만 Akismet에 자꾸 외국발 스팸이 걸리는 문제도 있었고, 애시당초 워드프레스를 설치했던 이유가 이상한 작동을 했던 텍스트큐브를 대체하기 위해서였기 때문에 다시 텍스트큐브로 돌아오기로 했다. 당시 아무도 내가 겪었던 버그를 겪지 않은 것 같았는데다가 디버그 모드를 켜고 봐도 오류가 나는 듯한 구석이 하나도 없어서 일단 억지로 깔았던 것이었기 때문이다. 글을 쓰려고 해도 저장할 수 없다고 하고, 환경 설정을 변경하려고 해도 안 된다고만 하고, 하여간 그런 오류였다.

진짜 MySQL 서버도 제대로 살아 있고 권한 오류도 없는데 이런 오류를 보면 황당하다. -_-결국 텍스트큐브를 밀고 워드프레스로 갈아탔다가 한 두 달이었던가 후에 다시 텍스트큐브를 깔아 보니 이 때는 정말 멀쩡한 것이 아니었던가!

정말 그 때 일을 다시 생각해 보면 황당하기만 하다. 그 사이에 했을 법직한 것은 재부팅 정도였는데 그것 하나만 가지고도 해결될 수 있는 것도 황당하다. 서버에 걸려 있는 오버클러킹도 영향을 주는 것 아닌가 해서 오버를 풀어도 보려고 했는데 그냥 재부팅 한 번으로 해결될 수 있는 문제였다는 것도 참 충격적이었다. 워드프레스가 그 동안 돌았던 것도 더더욱 이해하기 힘들고. 이래저래 참 오묘한 세계다.

내가 리버스 엔지니어링에 관심을 가지게 된 건 리눅스를 쓰기 시작하면서부터인 것 같다. 이 시궁창 같은 나라의 현실에서는 윈도에서만 되는 것이 너무 많았기 때문에, 리눅스에서도 그에 해당하는 무언가를 이루어 내기 위해서 프로그램의 핵심 부분만 어떻게 알아낸 다음 똑같거나 비슷하게 구현하여 쓰는 것이다.

리버스 엔지니어링을 하기 위해서 프로그램을 따거나, 장치와 통신하는 프로그램의 경우에는 장치와의 통신 신호를 잡아내기도 한다. 프로그램의 내부 구조를 들여다보려면 어셈블리어를 할 수 있어야 하며, 디버거 같은 것을 사용할 줄 아는 것이 좋다. 장치와의 통신을 캡처하려면 USB 버스의 신호를 캡처하는 프로그램이 필요하다. 내 개인적으로는 IDA와 SnoopyPro 같은 툴을 사용한다.

프로그램이나 버스 신호를 따 낸다고 해서 끝나는 것은 아니다. 어셈블리만 있다고 해서 완성된 프로그램이 나오는 것은 아니기 때문이다. 똑같은 로직을 이를 들여다보고 다시 구현하는 방법이 있지만 저작권 문제 때문에 이를 사용하는 일은 거의 없다. 클린 룸 엔지니어링이라는 방법은, 누군가가 소스 코드를 들여다보고 스펙을 작성한 다음, 그 스펙을 기반으로 제 3자가 코드를 짜는 방법이다. 저작권 문제를 피할 수 있기 때문에 이 방법을 많이 사용한다.

블랙박스 DLL이 있고 이를 호출해서 원하는 결과를 얻어야 한다면 이 DLL을 호출하는 프로그램을 다시 짜야 하고, 프로그램의 로직 그 자체가 필요하면 그것을 다시 짜야 한다. 내가 관심이 많은 윈도 DLL을 리눅스에서 호출하는 것은 WINE 라이브러리로 좀 까다롭게 할 수 있다. WINE 라이브러리를 기존 리눅스 코드에 섞는 것은 어렵지 않지만, 실제 프로그램을 짜서 테스트를 하는 동안 문제가 발생한다면 WINE 라이브러리를 쓰는 래퍼 프로그램 하나와 그 프로그램과 통신하는 다른 프로그램으로 쪼갤 필요가 있다.

이러한 과정을 통해서 프로그램을 다른 OS 상에서 똑같이 작동시키는 순간 짜릿함을 느낄 수 있다. 대부분의 사람은 변환이 귀찮다고 하지 않는 휴대폰에 MP3 집어넣기를 리눅스 상에서 통신사의 크고 더럽고 무겁고 엿같은 프로그램을 쓰지 않고 성공시키는 것만큼 짜릿한 느낌을 받기는 힘들 겄이다. 이것이 리버스 엔지니어링을 하게 되는 원동력 같다.

막상 이렇게 리버스 엔지니어링을 다 해 두었다고 해도 이를 마음대로 공개했다가는 변호사들의 밥이 되기 쉽다. 한국의 컴퓨터프로그램보호법 제12조의2의 1은 리버스 엔지니어링을 할 수 있는 부분을 명확하게 정의해 두었다. 그러나 그 결과를 제 3자에게 제공하는 등의 행위는 법 위반이기 때문에 결과를 다른 사람과 공유하려면 어둠의 방법밖에 없다. 그러나 이 조항이 개선되기는 힘든 것이 프로그램 원 제작자의 저작권 보호와 상충되는 측면이 있기 때문이다. 그래도 미국의 DMCA 같은 싸이코스런 조항보다는 낫지만. (아래 그림의 출처로 가기)

이 세상의 모든 프로그램이 자유 소프트웨어가 되지 않는 한 리버스 엔지니어링을 하려는 사람과 이를 막는 사람은 계속 대결 구도를 이룰 것이다.

아무리 maemo-cjk 프로젝트가 있다고 해도 얘네들에 참가하고 있는 한국인이 없기 때문에, maemo-cjk 프로젝트의 결과물인 입력기와 글꼴을 설치한다고 해도 한국 사람이 직접 참여한 리눅스 배포판의 그것과는 비교할 수 없다. 당장 예를 들어 보아도, 한국 사용자들이 존내 싫어해서 fontconfig에서도 퇴출된 백묵 글꼴이 아직까지도 들어 있다. scim이 올라가 있는 것은 뭐 별로 불만이 아니지만, Akademy 때 중국 사람에게 들었던 말 덕분에 scim은 이제 기피 대상 1순위다.

그래서 이제 한글 입력기를 무엇을 설치해야 하는가. 아직까지도 많은 사람들의 사랑을 받고 있는 나비가 있다. 아직까지는 마에모가 GTK 기반이므로 GTK 입력 모듈인 imhangul도 있다. 비록 imhangul은 나비보다 더 관리가 안 된다는 치명적인 점이 있지만. 게다가 새로운 입력기를 만들 때 충분히 도움을 줄 수 있는 libhangul도 등장하였다. 나비를 포팅하려는 시도는 몇 번 해 보았지만, 로케일 문제 때문에 나비가 제대로 붙지 않아서 번번이 포기하였다.

급한 불부터 끄기 위해서 일단 imhangul을 포팅해 보았다. imhangul은 데비안에 들어 있기 때문에 데비안 표준 빌드 순서를 따르면 된다. 데비안 패키지 사이트에 가서 imhangul의 dsc 파일의 URL을 따낸 다음, dget 명령어를 사용하면 알아서 소스를 긁어와서 압축을 풀어 준다. 그리고 fakeroot debian/rules binary 명령을 실행하면 빌드를 하긴 하는데, 아직은 문제가 있다. 데비안 시스템은 im-switch를 사용해서 입력기를 전환하지만 마에모에는 그게 없다. 애시당초 한 가지의 입력 방식만 고려하고 만든 것이다. 그리고 데비안 unstable에 비해서 라이브러리 버전이 낮아서 그냥은 빌드가 되지 않는다. 또한 한국어 로케일에서만 im-switch가 활성화되어 있으므로 모든 로케일에 대해서 다 켜야 한다.

이 문제를 해결하기 위하여 control 파일에서 im-switch에 대한 의존성을 삭제해 주고, configure 파일에서 ko 로케일로 점찍어둔 것을 *로 바꿔야 한다. im-switch를 제거하는 대신 스크립트를 사용하여 gtk.immodules 파일을 직접 업데이트해 줘야 한다. 이 과정에서 hildon을 죽이지 않으면 죽었다 깨어나도 imhangul이 살아나지 않는다. 이 모든 문제를 해결한 다음, 버전 번호를 살짝 올려서 컴파일해 주면 deb 파일이 생긴다.

이제 imhangul을 N810에 올리면 끝난다. 알려진 문제점으로는 MicroB에서 조합 중인 글자를 제대로 표시해 주지 못한다. 그래서 별 수 없이 두벌식을 외우든가, 아니면 조합이 다 끝난 글자를 바라보는 수밖에 없다. 그리고 Hildon IM이 죽으므로, Fn-Lock과 같은 유용한 기능을 쓰지 못하는 치명적인 약점이 있다. 뭐 그래도 일단 한글 입력이 가능하므로 이 불편한 사항은 참을 수 있다.

다음은 내 N810에서 imhangul이 실제로 동작하는 장면이다.

Urwid 라이브러리를 사용해서 아라라 프로젝트의 텔넷 클라이언트를 짜고 있던 때였다. 상자를 그리기 위해서 Urwid의 SolidFill, LineBox 클래스를 사용해서 유니코드에 할당되어 있는 선 문자를 사용하였고, 선을 그리기 위해서도 같은 문자를 사용하였다. 문제는 거기에서부터 시작되었다. 아라라의 요구 조건 중 하나인 윈도 텔넷 클라이언트에도 실행되어야 한다는 조건 때문에 EUC-KR 로케일에서 작동시켰어야 했고, LANG 환경 변수를 적당히 주어서 실행시키니 에러가 났다.

Urwid 메일링 리스트에 이 에러를 보내 보았더니 쓰고 있는 터미널 종류가 무엇인지 물어 보았다. 그래서 왠지 터미널 문제일 줄 알고 Urwid 메일링에는 터미널 버그라는 사실을 보고했다. 진짜 터미널 버그인지 확인하기 위해서 Yakuake와 Konsole에서 각각 프로그램을 실행시켜 보았다.

내 시스템에 깔려 있는 터미널 에뮬레이터는 KDE 3/4의 Konsole, Yakuake이다. 그래서 KDE 4의 Konsole에서 실행시켜 보았더니 제대로 된다. 이제는 버그 보고할 곳을 Yakuake 버그 보고 시스템으로 돌렸다. 결국 버그 리포트도 하나 질렀다.

보시다시피 그 어느 누가 낚이지 않았을까. 어 그런데... Yakuake의 인코딩 설정을 바꾸고 다시 실행해 봤더니 이제는 제대로 되었다. 뭐가 문제였나 곰곰히 생각해 봤더니... 문제의 원인은 이도 저도 그도 아니었다.

screen, 그래 screen이 문제였다. 인코딩을 바꿔 주기 귀찮아서 screen을 썼더니만 이런 문제가 생겼다. Ctrl-A :을 한 다음 encoding euckr만 하면 될 정도로 간단했기 때문에 이것이 버그의 원인이 될 줄은 꿈에도 몰랐다. 자 이제 screen에 버그를 보고하러 갈 차례인 것 같다. 막상 screen 버그란 걸 알고 나서 너무나도 허무했다. 이 문제 때문에 거의 1주일간 머리를 싸맸다는 것을 생각하면 더더욱 그렇다.

뭐, 이름은 거창하게 프레임워크라고 붙였지만 사실상 아무것도 아니다. 최근 KDE 번역을 다시 시작하면서 통계를 내 줄 무언가가 필요해서 파이썬 CGI 기반의 웹 페이지를 짰다. 디렉터리를 찍어 주면 po 파일을 돌면서 통계를 내는 것이다. 그런데 그것을 짠 것이 느낌학상 왠지 화근이 된 것 같다. php 기반의 페이지와 파이썬 기반의 페이지가 섞여있는 것이 못마땅했던가 결국 모두 파이썬 기반으로 갈아엎고 말았다.

비록 내가 Django를 배워 보려고 했지만 튜토리얼을 한 번 보고 좌절해 버려서 내 목적에 맞는 소형 웹 프레임워크를 만들기로 했다. 이름하여 발로만든™ 파이썬 프레임워크. 제작하는 데 들어간 시간은 얼마나 걸렸는가 모르겠지만 결과물은 시간에 비해서는 만족스러웠다. 맨 먼저 한 작업은 현재 홈페이지의 레이아웃 중에서 공통되는 부분을 빼내는 작업이었다. 아래 그림을 보자.

$로 둘러싸인 부분은 파이썬의 string.Template이 사용할 부분으로 여기에 실제 내용으로 대체된다. INCLUDE_로 시작하는 부분을 한번에 처리하고, string.Template을 여러 번 쓰는 것을 방지하기 위해서 공통되는 부분을 묶어서 하나의 파이썬 파일에 묶었다. 그 다음 제목과 내용만 써 주면 문서가 만들어지는 함수를 만들었다.

자. 파이썬 CGI를 만들면서 했던 가장 큰 실수 중 하나가 HTTP 헤더를 엉터리로 보내는 것이었다. Content-type 헤더를 보내지 않으면 브라우저가 어떻게 처리할 지 알 수 없기 때문에 text/html을 꼭 날려 주어야 한다. 실제로 이것 때문에 왜 웹 페이자가 안 나오는가에 대해서 엄청난 고민을 하였다. 알고 보니 헤더 문제였던 것을 알고 엄청 난리를 피웠던 적이 있다.

하여간 이 common.py는 공개하기 너무 민망할 정도로 간단해서... 그래서 이름이 발로만든 프레임워크가 되었다. 제작하는 데 썼던 힌트들은 다음과 같다.

• 파이썬 CGI 모듈
• 파이썬 string 모듈

이제 이 발로 만든 프레임워크를 살찌우는 일만 남았다.