방향을 잃은 듯 흔들리는 마음 때문일까? 새해가 되면 흔히 보이는 결심이라든지 하는 것들을 올해는 시야에서 찾아보기 힘들다. 잠깐 스쳐 지나가듯 그저 무디게만 느껴진다.
스스로를 감탄시킨 성취도 계속되는 일상 속에 묻혀 과거가 된다. 가끔은 그 속도가 놀라워서 묻힌다기보다는 매몰된다는 표현이 어울릴 정도다. 아니, 매몰‘시킨다‘고 하는 쪽이 더 정확할 것 같다. 나는 감격에 겨웠던 성공이나 깨달음의 순간들에 쉽게 싫증을 내고 대수롭지 않게 여기는 편이다.
더 성취하고 싶어서 마음이 앞서는 날이 있다. 하는 일 없이 반복되는 일상에 염증을 느낀다. 바꾸고 싶어도 마음처럼 되지 않아 화가 난다. 괜히 주변의 사람이 미워진다.
숨을 깊이 들이쉰다.
누구나 Inbox Zero 를 꿈꾸지만 현실은 녹록치 못하다. 늘어만 가는 읽지 않은 메시지를 보다 못해 한 번 간단히 통계를 내 보았다.
우선 지난 4주간의 요일별 메일 유입량 평균은 대략 다음과 같았다.
직원의 대부분이 북미와 유렵에 분포되어 있다 보니 요일의 시작이 화요일처럼 나타나는 것이 특징이라면 특징이다.
RSS 리더로는 169개의 블로그를 구독하며, 들어오는 블로그 포스트는 약 40통/일이었다.
현재 읽지 않은 메일은 1850통, 읽지 않은 블로그 포스트는 483개다. (좌절) 이렇게 계산해 보니 하루에 어느 정도의 메일과 블로그 포스트를 읽어야 현 상황을 개선할 수 있을 지 두리뭉실하게나마 감이 잡힌다.
그러나 아직도 파악되지 않은 것이 너무도 많다. 하루에 얼마나 오랜 시간을 메일 및 블로그 구독에 할애해야 하는가? 하루에 180통이 오는 목요일엔 하루 종일 메일만 붙들고 앉아 있어야 한단 말인가? 글로벌 기업, 더군다나 재택 근무자가 많은 부서의 특성상 거의 대부분의 의사 소통이 메일로 이루어짐을 감안한다면 이것은 많은 양인가, 아니면 적은 양인가?
이런 고민은 근본적으로는 메일을 통한 여러 시간대에 걸친 협업에 아직도 익숙해지지 못했기 때문이 아닌가 생각한다.
메신저나 입을 통해 직접 말을 거는 것과는 달리 메일은 즉각적인 주의를 요하지 않기 때문에 컨텍스트 스위칭 비용은 낮아지나 백로그가 길어진다. 컨텍스트 스위칭이 업무 효율에 악영향을 미치는 주요한 요인이지만 백로그가 길어질 경우 발생하는 심리적 압박 또한 무시할 수 없다. GTD 에서는 이 문제를 중요하게 다루고 있다.
이에 더해, 마이너한 시간대에 근무하는 것은 백로그 문제를 심화시킨다. 자고 일어나 보면 메일이 100통씩 와 있는 것이 일상이다. 백로그가 길어졌으므로 논의를 따라 잡는 데 훨씬 많은 노력이 든다. 또한 논의에 참여하기에는 너무 늦어버려 단지 따라잡는 데 그치고 말곤 하여 하루를 좌절감으로 시작하기도 한다.
어떻게 극복할 것인가? 좋은 방법이 떠오르지 않는다. 따라잡는 것 조차 벅차다. 막연한 낙관론보다는 적극적인 대처가 필요한 시점이다.
Everyone dreams about Inbox Zero, but the reality is cruel. I couldn’t stand the ever-increasing number of my unread messages, so I did a very simple math.
First off, the following list summarizes the average number of incoming messages for each day of week.
One interesting property of this data is that the beginning of a week looks like Tuesday. It’s because most employees are distributed in North America and Europe while I live in South Korea, which is a minor time zone.
I subscribed to 169 blogs, and that is about 40 new posts per day.
Currently, I have 1850 unread messages and 483 unread blog posts. (Depressed) After the simplistic math, now I can at least guess how many messages and blog posts I have to read to improve the current situation.
However, there are so many things to figure out. How many hours should I spend for reading e-mails and blogs? Should I spend my whole day for catching up the incoming messages on Thursday, where 180 messages come from? Is this a large amount or not considering that I am a remote worker of a global company?
I vaguely guess this issue might be because I am still not used to multi time zone collaboration via e-mail.
Unlike instant messaging and offline conversations, e-mail does not require immediate attention. Because of this property, e-mail decreases the cost of context switching while it increases the size of the backlog. Although the cost of context switching is known to be a major cause of poor productivity, the psychological pressure of the increasing backlog shouldn’t be ignored. The famous GTD book dedicates its whole pages about the backlog problem.
What makes the backlog problem worse is working in a minor time zone. If you get up in the morning, it’s usual to see about 100 messages which were sent overnight. As the backlog gets longer, it costs more effort to catch up the discussion. Moreover, you often end up with just ‘catching up’ rather than ‘actively participating’ because it’s too late. It sometimes makes a depressed start of a day.
How should I overcome this? I can’t think of a good solution. I am already busy enough with merely catching up. It’s time to deal with it actively instead of leaning on vague optimism.
결혼식이 중유한 이유는 아마 셀 수 없이 많겠지만, 내 결혼식이냐 타인의 결혼식이냐에 관계 없이 실감하게 되는 첫 이유는 바로 결혼이 결혼 당사자들의 새 출발이어서 뿐만 아니라 참석인들간의 재회와 새 출발도 의미하기 때문이라고 생각한다.
이 사람과는 왕래가 끊어진 지 오래인데 청첩장을 보내도 될까, 하고 고민하게 되는 것은 두 말할 나위도 없거니와, 결혼식을 하게 되면 생각지 못했던 사람들까지 나의 결혼을 축하해 주러 왔다는 사실에 감격하게 된다. 평상시였더라면 연락할 엄두조차 내지 않았을 그들과 다시 관계의 끈을 이을 수 있는 용기를 불어넣는 것은 다름아닌 결혼이라는 일생 일대의 이벤트인 셈이다.
마찬가지로 (꼴 보기 싫은 녀석이 아닌 이상) 과거의 서먹서먹한 관계 때문에 초대나 참석을 포기한다면 그것만큼이나 아쉬운 일도 없다.
당사자에게는 낯선 것이 결혼이기에, 지나고 나서야 깨닫게 되는 것을 먼저 깨닫길 바란다는 것이 애초에 무리라는 것을 알지만, 그래도 사실은 초대 를 받지 못해 우울하다.
벌써 재택근무도 2년이 넘었다. 의례히 듣는 질문들이나 집안에서 대부분의 시간을 보내는 것에 많이 익숙해졌다. 그 전에도 지각을 밥먹듯이 했었지만, 역시나 이제는 쉽게 출퇴근하는 직장으로 옮길 수 없을 것 같다.
규칙적인 출퇴근 생활이 그리워지고 자연스레 나와버린 배와 특별한 진전 없이 흘러가는 하루 하루에 울화가 치미는 것은 아마 그렇게 익숙해졌기 때문이 아닌가 싶다. 그러나 또 다른 모습의 생활을 한다 한 들 그 모습에 만족할 나 자신도 아니다. 앞으로도 이러한 불평은 만족감만큼이나 클 것이다.
그렇기에 요즘 느껴지는 불행감은 불치병에 가깝다. 불치병에 걸리면 한 번쯤 고통 속에서 사느니 차라리 이대로 금방 죽어버린다면, 하고 생각하듯, 차라리 이대로 어떻게든 되어버렸으면 좋겠다는 생각이 머릿속을 드나든다.
그런데 도대체 무엇이 말인가? 사실 무엇이 어떻게 되어버려야 되는지에 대해서조차 별달리 떠오르는 생각이 없다. 바꾸어 말해, 무언가 바뀌어야 할 필요가 있기는 한 것인가 싶다.
보통 변화란 머리가 아닌 마음에서 시작하므로 이런 생각이 도움이 되지 않는 것은 당연하다. 그것을 잘 알고 있으면서도 뇌리에서 좀처럼 떠나보내지 못하는 것 또한 아쉽다.
Since freedesktop.org has moved its disk management facility from HAL to DeviceKit-disks (devkit-disks), I could not override the default codepage of a VFAT USB storage device. DevKit does not allow to mount VFAT with the codepage option, and it was a problem to me because I use UTF-8 as the default codepage of the Linux partitions while most VFAT partiitions and USB disks were using CP949 (codepage 949).
A known workaround for this issue is to specify the mount options in /etc/fstab explicitly, but it does not scale because USB disks change its device path very often, especially when many USB devices are plugged in.
Consequently, I wrote a simple script that puts a watch on /etc/mtab file and remount VFAT with an explicit codepage option if necessary. I start up this watcher script in my /etc/rc.local so that I don’t need to care about codepage issues anymore.
#!/bin/sh
# /usr/local/bin/vfat-watch
# Exit if running already.
if [ "x`pgrep -of 'vfat-watch'`" != "x$" ]; then
exit 1
fi
while true; do
cat /etc/mtab | grep vfat | grep -v codepage | cut -d' ' -f1 | while read -r FS; do
# Choose your preferred codepage. 949 = Korean
mount -o remount,codepage=949 "$FS"
done
sleep 1
done &Because this script scans for the mtab file every second, you might see some problem when you perform some operation on the mounted VFAT too soon, but it shouldn’t be a problem for most cases.
리눅스 커널을 리빌드하지 않고 VFAT 디폴트 코드페이지 바꾸기
Freedesktop.org 가 디스크 관리 기능 제공자를 HAL 에서 DeviceKit-disks (devkit-disks) 로 변경하여 더 이상 USB 디스크의 기본 코드페이지를 지정할 수 없게 되었습니다. DevKit 은 VFAT 을 마운트할 때 codepage 옵션을 전혀 주지 않습니다. 때문에 리눅스 기본 문자셋은 UTF-8 으로 VFAT 문자셋은 CP949 (코드페이지 949) 로 사용하는 경우에는 문제가 됩니다.
알려진 해결책은 /etc/fstab 에 마운트 옵션을 직접 적어 주는 것이 있으나, 많은 USB 장치가 연결되어 있는 경우 장치의 경로가 자주 바뀌기 때문에 유연하지가 못합니다.
그래서 /etc/mtab 를 모니터링하고 있다가 필요한 경우 codepage 옵션을 명시해 VFAT 을 다시 마운트해 주는 스크립트를 작성했습니다. 저는 이 감시 스크립트를 /etc/rc.local 에서 시작해서 코드페이지 이슈를 더 이상 신경쓸 일이 없도록 했습니다.
#!/bin/sh
# /usr/local/bin/vfat-watch
# Exit if running already.
if [ "x`pgrep -of 'vfat-watch'`" != "x$" ]; then
exit 1
fi
while true; do
cat /etc/mtab | grep vfat | grep -v codepage | cut -d' ' -f1 | while read -r FS; do
# Choose your preferred codepage. 949 = Korean
mount -o remount,codepage=949 "$FS"
done
sleep 1
done &이 스크립트는 mtab 파일을 1 초에 한 번씩 스캔하므로 마운트된 VFAT 에 너무 일찍 접근하려 할 때 문제가 생길 수 있습니다. 하지만 대부분의 경우에는 별 문제가 안 될 듯 하네요.
ROXTerm is a GTK+ based lightweight terminal emulator. I chose it over GNOME Terminal as my default terminal emulator because ROXTerm can open a new tab in an existing window. However, ROXTerm doesn’t provide the Tango terminal color scheme out of the box. Hence I wrote one.
Put the following text configuration file into $HOME/.config/roxterm.sourceforge.net/Colours/Tango and choose the ‘Tango’ scheme in the ‘Preferences’ of ROXTerm menu.
[roxterm colour scheme]
foreground=#eeeeeeeeecec
background=#323232323232
0=#2e2e34343636
1=#cccc00000000
2=#4e4e9a9a0606
3=#c4c4a0a00000
4=#34346565a4a4
5=#757550507b7b
6=#060698989a9a
7=#d3d3d7d7cfcf
8=#555557575353
9=#efef29292929
10=#8a8ae2e23434
11=#fcfce9e94f4f
12=#72729f9fcfcf
13=#adad7f7fa8a8
14=#3434e2e2e2e2
15=#eeeeeeeeecec
16=#4c4c4c4c4c4c
17=#a8a830303030
18=#202088882020
19=#a8a888880000
20=#555555559898
21=#888830308888
22=#303088888888
23=#d8d8d8d8d8d8
cursor=#eeeeeeeeecec
palette_size=16
When a new GTK+ application is installed, the newly added launcher item sometimes does not have its icon. It’s mostly because the icon cache is not up-to-date. You can fix this problem by regenerating or rebuilding the GTK+ icon cache using the following command:
gtk-update-icon-cache -f '/usr/share/icons/<THEME_NAME>'However, we can simply update the whole cache without thinking much because updating the cache take not much time. I just put the following script into /etc/cron.daily so that the cache is fixed and the missing icon appears overnight:
#!/bin/sh
find /usr/share/icons -mindepth 1 -maxdepth 1 -type d | while read -r THEME; do
if [ -f "$THEME/index.theme" ]; then
gtk-update-icon-cache -f -q "$THEME"
fi
doneGMail을 쓰기 시작한 이후로는 모든 메일을 지우지 않고 보관해 왔다. 덕택에 하이텔 / 나우누리 시절의 메일과 중간에 실수로 유실된 메시지를 제외하면 2000년부터 주고 받은 17만 통에 달하는 메시지를 고스란히 간직해 온 셈이다.
물론 그것들이 전부 중요한 것은 아니지만 넉넉한 용량과 강력한 검색 기능 덕택에 딱히 지울 필요를 느끼지도 못했다.
그러나, 이렇게 메시지가 쌓이다 보니 다른 메일 클라이언트로는 쉽게 이전이 불가능한 상황이 되었다. 단 하나의 메일함에 저장된 17만 통의 메일을 효율적으로 처리하려면 메일 클라이언트는 머리에서 발끝까지 극도의 최적화를 거쳐야만 하는데, 그런 메일 클라이언트를 찾기란 하늘의 별따기였다. Opera M2 와 Mutt 정도만이 그 기준을 통과할 수 있었다. 그 외의 클라이언트들은 너무 느리거나 아예 동작하지 못했다.
그냥 GMail 을 계속 쓴다면 좋겠지만. 사내 메일은 정책상 별도 계정으로 관리해야 하니 관리 지점이 이원화되어 불편하다. Opera M2 를 쓰면 좋겠지만 글타래 인식 기능이 덜 똑똑한데다가 PGP 지원도 없고, 다중 아이덴티티 지원도 허술하다. Mutt 는 GUI 어플리케이션이 아니다. 마음만 같아선 다양한 애드온으로 나를 만족시켜 주는 Thunderbird 를 쓰고 싶지만 17만 통의 메일을 처리할 수 없다.
이렇게 별의 별 궁리를 다 하고 밤을 새어 가며 고생한 끝에 내린 결론은 ‘메일함을 줄이자’ 였다. 어찌 보면 단순한 결론이지만 17만통의 메시지 중에서 어떤 메시지를 지워야 하고 어떤 메시지를 지우지 말아야 할 지 결정하는 것은 쉬운 일이 아니다. 설사 결정했다 하더라도 압도적 분량 앞에서 주저하기 마련이다.
그래도 지우고 지우고 또 지웠다. 중간에 실수로 지우지 말아햐 할 메시지를 2만통이나 지웠다가 구사일생으로 복구하는 가슴 철렁할 해프닝도 겪었다. 메일이라는 도구의 노예가 된 내 모습을 바라보는 것이 그리 즐겁지만은 않았다.
그리고 바로 얼마 전, 17만 통의 메시지를 3천 통 정도로 줄이고야 말았다.
뿌듯함보다는 기묘한 상실감을 느꼈다. 그러니까, 나라는 개인으로서의 인격체와 직접적으로 관련이 있는 메시지는 2% 정도에 불과했다는 것이 아닌가. 98%의 메시지 속에서 허우적거리며 마음 속 친구들에게 소홀했음이 후회스러웠고, 한편으로는 다시 한 번 드러난 인연의 흔적이 향수와 기대감으로 나를 적셨다.
친구의 존재를 느끼는 순간은 달콤 쌉싸름하다. 몇 통만 읽어 보아도 ‘그때는 왜’ 로 시작하는 스스로를 향한 의문이 끊이지 않는다. 그리고 다시 한 번 그 시절을 넘어 조금은 달라졌을 ‘우리‘에 대해 이야기할 시간이 허락되기를 간절히 꿈꾼다.