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

그런데 싸이월드 미니는 아닌 것 같다. 애시당초 이게 나온 이유가 옴니아 때문이다. 옴니아의 액정 해상도도 800×480이기 때문에 잘리거나 남는 공간 없이 잘 보인다. 게다가 이걸 만들면서 기존에 쩡했던 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주일간 머리를 싸맸다는 것을 생각하면 더더욱 그렇다.