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

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

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

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

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

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

IDA Pro

SnoopyPro. 오래되긴 했어도 아직도 쓸만하다.

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

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

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

WINE 라이브러리로 윈도 DLL 호출하기

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

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이 실제로 동작하는 장면이다.

imhangul on N810

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 모듈

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