GTD 시스템, 소프트웨어가 아닌 관리 체계로서 골치 아픈 대상의 하나가 이-메일 메시지라는 것은 다시 강조할 필요가 없을 것이다. 블로그의 수 많은 포스팅에서도 이-메일 관리에 대한 의견과 대응을 적었다. 그러한 문제의 원인 중 하나가 예전과 달리 이-메일 계정의 생성이 쉽다보니 마음만 먹으면 수십 개의 이-메일 계정을 소유할 수도 있다. 특히 요즈음처럼 사용자 인증을 이-메일로 하는 경우 특별한 용도의 웹 서비스를 위한 별도 이-메일 계정을 만들어 사용하기도 한다. 어느 순간 자신의 얼마나 많은 이-메일 계정이 있는 지에 놀라는 경우도 있다. 반면 수십년 동안 한두 개의 이-메일 계정을 사용하는 경우도 결코 적지 않다. 이렇듯 많고 적든 이-메일 계정이란 것은 하나 생성하고 나서는 사용하지 않은 경우에도 중지나 제거 등을 하지 않고 결국 쌓인다. 사실 이런 경우는 문제가 될 것이 없다. 사용하지 않은 이-메일로 특별한 메시지가 올 경우도 드물고 오더라도 대부분 스팸이나 광고성 메시지이니 무시해도 상관없다.
하지만 특별한 경우인지는 모르지만 나의 경우는 꽤 많은 이-메일 계정을 사용한다. 일상적으로 사용하는 계정만 보더라도 대여섯 개는 넘고 관리하는 계정은 거의 십여 여개에 달한다. 개인용 한두 개, 업무용 두세 개, 외부용 한 두 개 등등, 생각해보면 정말 이렇게 이-메일 계정이 많아야 했는 지 의문이 들기도 한다. 하지만 이 정도 역시 제법 많이 그리고 주기적으로 정리한 것이라는 점이다.
그러므로 이-메일 관리의 가장 근간은 또 다시 강조하지만 사용하지 않거나 사용 빈도가 적인 이-메일 계정을 과감하게 삭제하는 것이다. 라이센스 등에 등록된경우라면 이-메일 변경이 가능한 지 혹은 단순한 로그인 네임으로만 사용되는 지 등을 파악하여 정리할 수도 있을 것이다. 만약 그럴 수 없다면 이-메일 계정의 포워딩 서비스를-가능하다면-이용하거나 혹은 별도의 이-메일 클라이언트를 이용하여 해당되는 모든 이-메일 계정을 나름대로 통합하여 관리하는 방법이 있을 것이다. 개인적으로 Spark 이-메일 클라이언트를 사용하여 후자의 방법을 사용한다. Spark의 다양하고 강력한 기능에 반한 애용자라면 지탄할 대응이 아닐까 싶다.
사실 한국에 살면서 네이버, 다음 등 이른바 포털을 사용하지 않을 수는 없고, 일단 작은 용도라면 사용하게 되면 이-메일 계정이 자동으로 생기고 시스템 관련 메시지가 해당 이-메일 계정으로 날라오는 어쩔 수 없지 않나 싶기도 하다. 이런 웹 기반 서비스의 이-메일 계정 가운데 IMAP나 POP3를 지원하지 않는 경우가 있다면 애무 당황스러울 것이다. 요즈음 업무 환경이 웹 기반으로 바뀌다보니 그런 경우가 의외로 적지 않은 것 같다. 나 역시 꽤나 오랜 시간 몸소 그런 경우를 겪어야 했다. 대개 웹 기반 메일 관리에 특별히 거부감이 없겠지만, 처음부터 이-메일 클라이언트 기반으로 메시지를 관리해 온 습관 덕에 웹 기반 이-메일 운용은 내게 있어 정말 어색하다.
물론 지금까지 넋두리처럼 적은 이야기는 실제 접하게 될 수 많은 이-메일 메시지 기반의 업무 관리나 GTD 시스템 운용에서 발생하는 여러 문제에 비하자면 문제라고 부르기도 어려운 수준이다. 더욱이 같은 이-메일 서비스가 컴퓨터 시스템, 운영체제 그리고 이-메일 클라이언트에 따라 서비스 수준이나 기능에 일관성이 없다며 정말 난감하다. GTD 사용자로서 앞으로 다루고자 하는 이-메일 메시지 관리의 많은 문제들이 그러한 요소에 기인하고 있기도 하다.
다양한 이-메일 서비스의 선택 혹은 선택의 여지 없는 사용, Windows나 macOS와 같은 특정 운영체제에서 구동되는 이-메일 클라이언트 성능과 기능의 문제, 더불어 예기치 못한 크고 작은 문제들로 인해 이-메일 서비스 자체를 포기해야 하는 등의 경우를 심심찮게 겪어 왔다. 그리고 그 가운데 여전히 해결되지 않은 문제가 이어지고 있다. 아마도 컴퓨터 시스템이나 스마트 폰의 일상이나 업무의 핵심 도구로 자리잡고 있는 가운데 여러 개의 이-메일 계정을 함께 운용하는 경우라면 비슷한 경험을 하고 있을 것이라 생각든다.
댓글 없음:
댓글 쓰기