글을 쓰려고 마음을 먹으면 항상 먼저 떠오르는 할 말이 바로 시간이 너무 빠르게 흘러간다는 것이다. 그럴 때마다 내가 뭐 그리 바쁜 위인이라도 되는지 허탈한 웃음이 나오곤 한다. 그런데 요즘에는 정말 하는 일도 없이 시간이 흐르는 것 같다. 늦잠 자랴 아기 돌보랴 식사하고 한숨 돌리랴. 이런 삶의 사치를 누리다 보면 언젠가 이런 밑천도 바닥나는 게 아닌가 싶다. 가뜩이나 절약이라는 것을 잘 모르는 나에겐 그렇다.
그래도 아무 것도 하지 않은 것은 아니고, 남들이 보면 소소하다고 할만한 일들에 상당한 시간을 할애했다. 오늘은 완벽한 메일 체계 구축을 위한 나만의 여정에 대해 이야기하고자 한다.
어느 날 문득 2000년 부터 쌓인 11만여 통의 메일을 폴더를 나누지 않고 회사 내부 메일과 *함께* 관리하고 싶었다. 회사 보안 정책상 GMail과 같은 공용 서비스에 내부 메일을 담을 수 없으므로 자체적으로 메일 서버를 세팅해 IDC 에 입주시켰다. Dovecot IMAP 서버와 fetchmail을 사용해 하나의 계정에 모든 메시지를 긁어오도록 설정했다.
11만통의 메시지를 긁어 오는 모습을 멍하니 바라보다 보니 엔코딩이나 제목 포매팅에 문제가 있는 것들이 많이 보였다. 그래서 수십여개의 정규표현식과 문자셋 자동인식 모듈, JavaMail API을 이용해 Exim MTA 측에 필터를 설치했다. (처음에는 PERL로 했지만 나중에는 그 규칙이 너무 복잡해져서 Java로 전부 다시 작성했다.) 그 과정에서 메일을 대량으로 받아 오면서 실험하다 보니 일종의 트래픽 초과 덕택에 GMail 계정이 24시간 동안 막히는 사태가 발생했다. 처음엔 어찌나 당황했는지…
이렇게 우여곡절 끝에 받아 온 11만여 통의 메일을 주제나 연도별로 쪼개기가 싫어서 – 이걸 왜 사람이 해야 하나? – 검색 폴더 기능을 이용하기로 했다. 검색 폴더 기능이 지원되는 메일 클라이언트는 Evolution, Claws-mail (mairix를 통해), Thunderbird, Opera 9.5 베타인데, 모두 결격 사유가 있었다. Claws-mail은 mairix라는 외부 어플리케이션을 사용하기 때문에 한계가 있었고, 무엇보다도 IMAP 지원이 너무 부실해서 탈락. Thunderbird는 검색 폴더의 검색 조건이 너무 단순해서 탈락. Evolution은 조건식은 원하는 만큼 복잡하게 설정할 수 있었지만 11만개를 폴더를 열 때마다 다시 처리해서 탈락. 마지막 후보 Opera 9.5 베타는 극도로 강력한 실시간 검색, 검색 폴더, 메일링 리스트 관리 등을 제공하여 너무나 만족스러웠다. 브라우저와 메일 클라이언트, 그리고 IRC 클라이언트까지 하나로 통합되어 있는데다가 메모리 사용량도 적어 금상첨화였지만, 결정적으로 불안정했다. 아아… 지구에는 내 요구를 만족하는 메일 클라이언트는 *아직* 없었다.
한 가지 희망이 있다면 GNOME 2.22와 함께 딸려 오는 Evolution은 그래도 검색 폴더 기능의 성능에 향상이 있을 뿐만 아니라 오히려 메모리 사용량도 더 적다는 것이었다. 하지만 내가 사용하던 Fedora 8에서 GNOME만 2.20으로 유지하고 Evolution만 업그레이드하는 것은 불가능했다. 혹시나 하는 심정으로 Fedora 9 베타를 설치했지만 내 랩탑은 아직 지원이 제대로 되지 않아 많은 부분이 불편해 다시 Fedora 8을 설치하고 말았다.
이쯤 되서 포기했다면 어땠을까 하는 생각도 들지만 언제나 마음에 들 때까지 바꾸고 또 바꾸는게 내 성격인지라, 결국 GNOME 2.20을 쓰면서 Evolution 2.22도 쓸 수 있는 Gentoo Linux로 재설치를 하게 된다. Gentoo Linux는 10번 정도는 깔아 본 적이 있기 때문에 쉽게 세팅을 완료할 수 있었다. 내 속을 태우는 기나긴 컴파일 시간과 잘 잡히지 않는 무선랜 문제에 대한 해결책을 찾는 데 할애한 시간을 제외한다면…
하지만 Evolution 2.22는 기대만큼 빠르지 않았다. 역시 *아직* 지구의 메일 클라이언트들에게 11만통은 무리인 것 같다. Opera 9.5 안정 버전이 아직 나오지 않은 것을 못내 아쉬워하는 순간이었다.
결국 타협책으로, 볼일이 끝난 메일은 ‘Archive’라는 하나의 폴더로 전부 옮기고 나머지 메시지에 대해서만 검색 폴더를 생성하게 되었고, 나름 만족스러웠다. 내가 일일이 ‘Archive’ 폴더로 옮겨야 한다는 것만 제외한다면… 이걸 왜 내가 해야 되는건지.
그런데 이 검색 폴더라는 것에서 제시할 수 있는 검색 조건이라는 것이 우리가 일반적으로 사용하는 메일 필터 규칙 기능에서 제공하는 조건의 종류에 비교하면 그 수가 매우 적다. 예를 들어 Evolution에서는 정규 표현식을 메일 필터 규칙에서는 사용할 수 있지만 검색 폴더에서는 사용할 수 없다. 성능을 위한 나름의 궁여지책이겠거니 이해가 가지만, 근본적으로 인덱싱을 제대로 안해서 사용자에게 불편을 가하고 있는 게 아닌가? Opera 9.5 안정 버전이 아직 나오지 않은 것을 못내 아쉬워하는 *두 번째* 순간이었다.
정규 표현식을 통한 정교한 필터링이 필요했던 나는 결국 검색 폴더를 포기했다. Archive 폴더의 도입 이후 또 한 번의 타협이었다. 어쨌든 메일 필터 규칙을 작성하여 메일이 들어오는 순간 원하는 폴더에 쌓이게 하는 데 성공했고, 필터가 정교하니 나름 검색 폴더의 필요성을 느끼지 못하게 해 주어 그나마 아쉬움은 크지 않았다. 다만 지금까지 돌아온 나의 길이 너무나 멀었다는 사실을 뼈저리게 느끼지 않을 수 없었다.
그런데 여기서 이야기는 끝나지 않는다. Firefox 3 베타와 GNOME 2.22를 쓰고 싶어진 것이다. 여러 의존성 문제 때문에 Evolution 2.22나 GNOME 2.22의 일부 컴포넌트는 Firefox 2를 반드시 필요로 한다. GNOME 2.22의 일부 컴포넌트야 그냥 설치하지 않으면 그만이지만, 지금까지 힘들게 규칙을 설정한 Evolution은 어쩌란 말인가. 여기서 보통 포기하겠지만 나는 좀처럼 포기를 하지 않는 못된 버릇이 있다.
그래서 결국 sieve 라는 서버측에서 사용할 수 있는 메일 필터링 언어를 배웠다. 문법은 아주 간단하고 Dovecat IMAP 서버와 연동도 쉽지만 언어에 대한 깔끔한 문서를 찾기가 힘들고 정규 표현식 매칭 등의 기능을 사용한 예가 없어서 관련 RFC를 직접 읽어야 했다. 몇 번의 실수도 있었지만 결국에는 Evolution에서 작성했던 모든 규칙을 서버 측에서 처리할 수 있게 되었다. 즉, 어떤 메일 클라이언트를 써도 메일 필터링이 이미 다 된 상태로 계층화된 메일함을 열람할 수 있게 된 것이다. 여기까지 다다른