E-메일 관리, 풍요 속의 빈곤 - 그 시작 ?

GTD 시스템, 소프트웨어가 아닌 관리 체계로서 골치 아픈 대상의 하나가 이-메일 메시지라는 것은 다시 강조할 필요가 없을 것이다. 블로그의 수 많은 포스팅에서도 이-메일 관리에 대한 의견과 대응을 적었다. 그러한 문제의 원인 중 하나가 예전과 달리 이-메일 계정의 생성이 쉽다보니 마음만 먹으면 수십 개의 이-메일 계정을 소유할 수도 있다. 특히 요즈음처럼 사용자 인증을 이-메일로 하는 경우 특별한 용도의 웹 서비스를 위한 별도 이-메일 계정을 만들어 사용하기도 한다. 어느 순간 자신의 얼마나 많은 이-메일 계정이 있는 지에 놀라는 경우도 있다. 반면 수십년 동안 한두 개의 이-메일 계정을 사용하는 경우도 결코 적지 않다. 이렇듯 많고 적든 이-메일 계정이란 것은 하나 생성하고 나서는 사용하지 않은 경우에도 중지나 제거 등을 하지 않고 결국 쌓인다. 사실 이런 경우는 문제가 될 것이 없다. 사용하지 않은 이-메일로 특별한 메시지가 올 경우도 드물고 오더라도 대부분 스팸이나 광고성 메시지이니 무시해도 상관없다.

하지만 특별한 경우인지는 모르지만 나의 경우는 꽤 많은 이-메일 계정을 사용한다. 일상적으로 사용하는 계정만 보더라도 대여섯 개는 넘고 관리하는 계정은 거의 십여 여개에 달한다. 개인용 한두 개, 업무용 두세 개, 외부용 한 두 개 등등, 생각해보면 정말 이렇게 이-메일 계정이 많아야 했는 지 의문이 들기도 한다. 하지만 이 정도 역시 제법 많이 그리고 주기적으로 정리한 것이라는 점이다.

그러므로 이-메일 관리의 가장 근간은 또 다시 강조하지만 사용하지 않거나 사용 빈도가 적인 이-메일 계정을 과감하게 삭제하는 것이다. 라이센스 등에 등록된경우라면 이-메일 변경이 가능한 지 혹은 단순한 로그인 네임으로만 사용되는 지 등을 파악하여 정리할 수도 있을 것이다. 만약 그럴 수 없다면 이-메일 계정의 포워딩 서비스를-가능하다면-이용하거나 혹은 별도의 이-메일 클라이언트를 이용하여 해당되는 모든 이-메일 계정을 나름대로 통합하여 관리하는 방법이 있을 것이다. 개인적으로 Spark 이-메일 클라이언트를 사용하여 후자의 방법을 사용한다. Spark의 다양하고 강력한 기능에 반한 애용자라면 지탄할 대응이 아닐까 싶다.

사실 한국에 살면서 네이버, 다음 등 이른바 포털을 사용하지 않을 수는 없고, 일단 작은 용도라면 사용하게 되면 이-메일 계정이 자동으로 생기고 시스템 관련 메시지가 해당 이-메일 계정으로 날라오는 어쩔 수 없지 않나 싶기도 하다. 이런 웹 기반 서비스의 이-메일 계정 가운데 IMAP나 POP3를 지원하지 않는 경우가 있다면 애무 당황스러울 것이다. 요즈음 업무 환경이 웹 기반으로 바뀌다보니 그런 경우가 의외로 적지 않은 것 같다. 나 역시 꽤나 오랜 시간 몸소 그런 경우를 겪어야 했다. 대개 웹 기반 메일 관리에 특별히 거부감이 없겠지만, 처음부터 이-메일 클라이언트 기반으로 메시지를 관리해 온 습관 덕에 웹 기반 이-메일 운용은 내게 있어 정말 어색하다.

물론 지금까지 넋두리처럼 적은 이야기는 실제 접하게 될 수 많은 이-메일 메시지 기반의 업무 관리나 GTD 시스템 운용에서 발생하는 여러 문제에 비하자면 문제라고 부르기도 어려운 수준이다. 더욱이 같은 이-메일 서비스가 컴퓨터 시스템, 운영체제 그리고 이-메일 클라이언트에 따라 서비스 수준이나 기능에 일관성이 없다며 정말 난감하다. GTD 사용자로서 앞으로 다루고자 하는 이-메일 메시지 관리의 많은 문제들이 그러한 요소에 기인하고 있기도 하다.

다양한 이-메일 서비스의 선택 혹은 선택의 여지 없는 사용, Windows나 macOS와 같은 특정 운영체제에서 구동되는 이-메일 클라이언트 성능과 기능의 문제, 더불어 예기치 못한 크고 작은 문제들로 인해 이-메일 서비스 자체를 포기해야 하는 등의 경우를 심심찮게 겪어 왔다. 그리고 그 가운데 여전히 해결되지 않은 문제가 이어지고 있다. 아마도 컴퓨터 시스템이나 스마트 폰의 일상이나 업무의 핵심 도구로 자리잡고 있는 가운데 여러 개의 이-메일 계정을 함께 운용하는 경우라면 비슷한 경험을 하고 있을 것이라 생각든다.

OmniFocus 3 안내서 - 1. Capture, 수집

OmniFocus 3, OF3에 대한 포스팅을 할 계획이면서 앞서 이런저런 글이 많았다. 그만큼 오랜 GTD 시스템 그리고 OF3의 구성과 활용에 대해-순전히 개인적인 측면이지만-눈에 거슬리는 문제나 불만이 적지 않았고, 이러한 사안들이 GTD 시스템 운용에서 작지 않은 문제로 연결될 수 있다는 것을 경험했기 때문이다.

이제 OF3의 기능적 사안을 중심으로 GTD 시스템 운용에 관해 적고자 한는데, 모든 GTD 프로그램과 마찬가지로 OF3의 기능적 항목을 GTD 시스템으로 운용하는 것은 사용자의 상황이나 습관 그리고 현재 업무 내용에 따라 다를 수 밖에 없다.

즉 iGTD나 ThinkingRock 혹은 Inbox가 같은 이전 세대의 GTD 프로그램은 철저하게 GTD 시스템의 절차적 방식을 준수한 반면, OF3나 Things는 프로그램이 제공하는 기능을 이용하여 나름의 GTD 시스템으로 활용해야 한다.

- - - - -

OF3의 GTD 프로그램로서의 가장 기본적이고 핵심적인 그리고 첫 기능적 내용이 수집(Capture) 기능이다.

현재 OF3의 한글 표기로는 Inbox를 통상 말하는 수집함이 아닌 수신함이로 사용하는 등 몇몇 용어가 상당히 어색하지만 일단 화면에 나타난 그대로 적고자 한다.

OF3에서의 일상적 수집은 수신함에 사용자가 직접 대상 항목을-입력하여-수집하거나 또는 E-메일을 통하여 간접적 방법으로 수집(수신)하는 것으로 나눌 수 있다. 따로 언급해야 할 사안이지만 E-메일을 이용하는 방법은 컴퓨터를 이용한 여러 상황에서 요긴하게 사용될 수 있다.

1. 수집 사항 입력

OF3의 수신함에 새로운 작업 대상 항목을 입력하기 방법으로 파일 메뉴의 새 항목 선택하거나, 도구 막대의 ‘+’ 아이콘을 이용하거나 키보드로 Command+N 명령을 사용할 수 있다.

그리고 OF3 화면이 아닌 상태에서-물론 OF3가 열려진 상태에서-OF3의 수신함에 바로 저장하는 빠른 입력, Quick Input을 사용할 수 있다. Quick Input은 단순한 수집 대상 항목의 이름 뿐 아니라 프로젝트나 태그 그리고 마감 날짜 등의 속성 정보도 입력할 수 있다.

하지만 macOS 환경에서는 여러 기능들이 단축키를 지원하다 보니 OF3의 Quick Input 외에도 다른 여러 기능과 함께 사용하기 위한 적절한 단축키 설정이 만만치 않다. 개인적으로는 Shift+Control+Option+Space를 Quick Input에 할당하고 있다. 이 정도 구성의 단축키라면 거의 사용하지 않는다는 반증이다.

이후에 따로 적겠지만 OF3의 수집 기능에는 직접 대상 항목을 입력하거나 파일을 경로 링크로 연결하거나 기록할 수 있다.

기능적 측면에서 대상 수집에 관해 언급할 사안은 없지만, 이후 GTD 시스템의 분류 및 평가 과정에서 원할하고 효율적인 작업을 위해 제목과 내용의 수정이 필요 없거나 최소화 되도록 명확한 절차와 결과를 담고 있는 문장으로 구성하는 것이 좋다.

수집 과정 중 처리 대상이 많다거나 혹은 빠른 처리를 위해 입력 항목의 이름을 너무 단순하게 작성하면, 이후 분류 과정에서 수정해야 할 경우가 많아지게 될 수 있기 때문에 가능한 항목을 명확하게 입력하는 습관이 필요하다. 이를 위해-OF3의 수집 기능과 무관한 사안이지만-GTD 프로그램의 수집을 위한 상시적 입력에 대한 나름의 절차적 규칙을 세우고 준수하도록 노력할 수 있어야 한다.

우리의 일상은 이미 OF3의 일반적 항목 수집 기능으로 감당하기 힘든 수준으로 확장되어 있다. 특히 업무적 환경에서 매번 개별적 항목을 사용자가 직접 키보드를 이용하여 수집하기 어렵다. E-메일 메시지, 사진, 그리고 다양한 포맷의 파일 등은 OF3에서 직접 다루기 어렵다.

필요하다면 이런 대상이 많다면 어쩔 수 없이 별도의 프로그램들을 이용해고 OF3와 함께 운용할 수 있도록 해야 한다.

예로 업무로든 일상으로든 사진을 찍고 고르고 수정하고 그리고 공개하는 것이 일의 주된 범위라고 한다면, 찍은 사진을 모으는 과정이 수집 절차이며 사진이 모이는 폴더나 저장 장치가 수집함 이자 관리 도구가 된다. 이러한 과정을 지원하는 사진 어플리케이션이 GTD 프로그램의 하나가 될 수 있다.

2. E-메일 메시지 수집

E-메일은 우리의 일상과 직장에서 일반화된 소통과 업무의 도구라고 할 수 있다. 물론 현재는 SNS 메신저가 많은 부분 대체하기 했지만-개인적으로도-여전히 업무의 주요한 부분을 담당하고 있다.

때문에 E-메일 클라이언트 혹은 웹 기반의 E-메일 서비스는 별도의 업무 관리 프로그램 혹은 그 자체로 OF3와 같은 하나의 GTD 프로그램이기도 하다. E-메일 관리 시스템 기반의 GTD 시스템 운용은 별도의 주제로 다룰만한 사안이라 할 수 있다.

어떤 경우든 OF3를 운용하더라도 직간접적으로 E-메일 관리 체계와 연동하여 사용할 수 밖에 없는 것이 현대적 업무 환경이다.

OF3와 E-메일 프로그램(나의 경우는 애플 Mail 어플리케이션)과의 연동에서 가장 큰 기능은, 대부분의 E-메일 메시지는 E-메일 클라이언트나 다른 업무용 어플레케이션에서 처리하지만, 별개의 일로 처리해야 하거나 새로운 업무로 생각되는 경우 OF3의 수신함으로 보낸다.

Mail 어플리케이션의 메시지를 OF3의 수신함으로 바로 드래그할 수 없기 때문에, 수신함에 새로운 항목을 생성 후 메시지를 드래그 하거나 Quick Input 기능을 통하여 새로운 항목을 생성해야 한다. 하지만 OmniGroup에서 제공하는 OF3 수집용 E-메일 주소를 사용하여, 해당 메시지를 포워딩하여 OF3의 수신함으로 바로 전달하는 방법을 사용할 수 있다.

E-메일 메시지를 OF3로 전달하는 경우에도 E-메일 메시지의 제목을 그대로 사용해도 되지만, OF3의 수집 항목 생성의 규칙을 적용하여 명확한 제목으로 작성하여 전달하는 것이 좋다.

3. OF3 for iOS & 미리 알림 연동 그리고 Siri 활용

Mac의 OF3(OmniFocus 3 for Mac)의 수집 기능이 아니기 때문에 단독으로 사용할 수 없지만, 만일 OF3 for iOS를 사용하고 있다면 Mac의 ‘미리 알림(Reminders)’ 프로그램과 iOS의 ‘미리 알림’ 앱과 연동하여 Mac의 OF3를 위한 입력 도구로 사용할 수 있다.

개인적으로는 GTD 프로그램으로서 OF3 of iOS는 적극 추천하지 않는 입장이지만, 굳이 구입의 효용성을 하나 꼽으로라면 미리 알림을 통한 OF3 수집 기능과 Siri를 통한 OF3 입력 기능을 활용한 GTD 입력 도구로서의 역할은 의미가 있다고 본다.

다만 OF3 for iOS에서는 미리 알림의 목록을 OF3의 수신함을 단방향 연동이지만 Mac과 iOS의 미리 알림을 함께 운용하면 양쪽 환경에서 모두 운용이 가능하다. 즉 맥의 미리 알림에 입력한 사안이 iOS의 미리 알림으로 동기화 되고, 이 항목이 OF3 for iOS에 연동된 목록에 있다면 OF3 for iOS의 수신함으로 입력되고 다시 동기화된 맥의 OF3 for Mac의 수신함으로 이동하는 긴 여정을 거치게 된다.

바라기는 Mac의 미리 알림 앱의 목록이 OF3의 수신함과 연동될 수 있다면, 굳이 OF3 for iOS가 필요 없을 것이다. 그리고 최근 Mac의 미리 알림 프로그램에서 iCloud 동기화 문제가 발생하기도 했기 때문에 특정 프로그램에 국한된 기능을 집중한다는 것은 여러 면에서 불안 요소가 될 수도 있다.

그리고 아쉽게도 아직 Mac에서는 OF3가 Siri를 지원하지 않는다. 다만 iOS에서는 Siri 지원이 가능하기 때문에 앞서 미리 알림 앱과 같은 방식으로 운용할 수 있다.

이러한 기능적 측면에서는 Things의 Mac/iOS 앱간 연동 기능이 OmniFocus에 비해 좀더 사용자 친화적임이 분명하다.

이와같이 현재 Mac의 OF3와 iOS의 OF3를 모두 사용한다면 여러모로 효과적인 운용이 가능한 것은 분명하다. 그렇더라도 일부러 Mac과 iOS 환경에서 공동 운용을 굳이 추구할 필요는 없다. 물론 외부 활동이 많은 경우라면 OF3 for iOS는 꽤 효율적인 입력 도구이자 위치 기반의 자뚜리 시간 활용을 위한 좋은 도구가 될 수도 있다고 본다.

- - - - -

GTD 시스템에서 수집함(수신함)을 비우는 과정은 다음 평가 과정의 시작이다. 이제 OF3의 수신함에 주변의 온갖 사안이 수집되었다면 이제 수신함을 비우는 두번째 Clarify 과정으로 진행한다.

이 단계에서 현실적으로 가장 고민스러운 문제는 수신함을 비우는 즉 수집 이후 평가 및 구성 단계로 진행하는 과정을 얼마만에 수행하느냐이다. 물론 정해진 횟수는 없다. 일반적으로 하루 혹은 이틀에 한번 정도가 적당하다고 한다. 일이 많은 만다면 하루에 한번 이상도 가능할 것이다. 하지만 횟수 보다 주요한 것은 일단 수신함을 비우기 과정을 시작했다면 가능한 모든 항목에 대한 정리를 하는 것이 더 주요한다.

OF3와 같은 GTD 프로그램의 경우는 수집, 평가 그리고 구성의 과정이 실제적으로 수신함에서 진행된다는 점에서 수신함에 쌓인 대상이 너무 많다면 수신함 비우기에서 시작하여 항목 평가와 구성의 과정이 완료되지 못한 채 또 새로운 대상이 수집될 수 있다는 점에서 수집된 대상을 정리하는, 수집함 비우기 작업에 충분한 시간을 가지고 수행할 수 있어야 한다.

Mac 사용자를 위한 E-메일 관리 지원 유틸리티, MailTags

GTD 시스템 사용자로서 가장 고민스러운 것 가운데 주요한 것이 OmniFocus나 Things 등과 같은 별도의 어플리케이션을 사용한다고 할때, 업무의 많은 부분은 차지 하는 영역이 이들 어플리케이션과 연동되지 않을 수 있다는 것이다. 때문에 Outlook과 같은 통합 어플리케이션에서는 그런 점에서는 유리한 점이 분명하다. 어떤 식으로든 여러 개의 개별 어플리케이션을 운용한다는 것은 하나의 어플리케이션으로 운용되는 것에 비해 불편한 점이 있다는 것은 사실이다.

Mac OS X 환경에서 가장 많이 사용하는 이-메일 클라이언트 프로그램은 단언컨데 애플 메일(이하 Mail)이 분명할 것이다. 기본 탑재 프로그램으로서 딱히 다른 어플리케이션으로 전환할만한 치명적 이유가 없을 정도로 기본이 탄탄한 프로그램이기 때문이다. Windows 환경에서의-비록 기본 탑재 프로그램은 아니지만 그 역할을 충실히 수행하는-Outlook에 비해 가볍고 빠르다. 더하여 Outlook에 제공하는 여러 기능은 Mac OS X의 다른 기본 탑재 프로그램과의 연동성으로 완벽하게 대응할 수 있다. 물론 Outlook은 Mac OS X 환경에서도 사용할 수 있다.

하지만 GTD 시스템을 운용하는 입장에서, 특히 이-메일이 업무의 주요한 한 축을 차지하고 있다면 애플 메일은 장점과 단점이 분명하다. 물론 그 단점을 앞서 언급한 치명적인 이유가 되지 못하는 것은 분명하다. 앞서 언급했듯이 기능적 측면에서 보자면 Outlook에 GTD 시스템 구축에 필요한 기능을 모두 포함한 것에 비하지만, Mail은 분리된 여러 프로그램이 유기적으로 작동하긴 하지만, 하나의 단일 관리 체계를 제공하지 못한다는 점에서 불편한 단점이 분명하다. 그렇더라도 Mail과 Outlook을 직접적으로 비교할 필요나 이유는 각자의 사용 환경에 따라 다르니 따로 언급하지 않고, 이-메일 메시지 관리하는 본연의 기능으로 보더라도 역시나 규모나 기능에서 비교될만한 상대가 아닌 것 역시 분명하다.

Mail은 기능도 실질적으로 이-메일 관리 측면에서의 부족함이 아니라 GTD 시스템 사용자의 욕심으로서 다소 불편하고 부족한 면이 있는 것이다. 때문에 이러한 기능을 보완하는 여러 유틸리티가 개발되어 왔다. 그 가운데 나는 거의 십년 가까이 Indev의 MailTags를 사용해왔다.

현재는 사명이 SmallCubed로 바뀌었고 개별 유틸리티로 판매되던 MailTags도 현재는 Mail Act-On 등 몇몇 이-메일 관리 유틸리티와 합쳐진 통합 패키지 MailSuite로 공급되어 있다. 덕분에 가격도 $60로 높아졌을 뿐 아니라 앞으로 점차 구독형 서비스로 전환되어 갈 예정이라고 한다.

MailTags는 이름 그대로 Mail의 메시지에 태그(현재는 키워드)를 지정할 수 있는 기능을 제공한다. 그리고 특정 메시지에 지정 날짜(Tickler Date)를 설정할 수 있다. 그리고 OmniFocus, Things, 및 The Hit Lists의 프로젝트와 태그를 불러올 수 있는 기능이 있다. Mail을 사용하는 GTD 시스템 사용자에게 꼭 필요한 기능이라 아니할 수 없다. 더하여 태그와 지정 날짜를 Mail의 규칙에 적용하여 보다 유연한 방식으로 이-메일 관리를 자동화할 수 있다.

그외 MailSuite에는 보내고 받는 메일을 보다 손쉽게 자동화할 수 있는 Mail Act-on, 메시지를 좀더 편리하게 구분하여 보여주는 Mail Perspectives, 그리고 메시지의 사인 정보를 관리할 수는 SigPro 등이 포함되어 있지만, 무엇보다도 핵심적인 기능은 모두 MailTags에 기반하고 있다고 할 수 있다. 사실 MailTags 외 다른 기능의 효용성은 상대적으로 거의 없다고 보인다.

MailTags의 사용법은 매우 간단하고 편리하다. 태그를 지정하거나 날짜를 설정하거나 하고 싶은 메시지를 마우스 오른쪽 버튼으로 선택하면 MailTags의 모든 기능을 지정할 수 있으며, 기존 Mail의 관리 기능 역시 그대로 사용할 수 있다.

하지만 오해하지 말아야 할 것은, MailTags와 같은 이-메일 메시지 관리 기능이 하루 지나면 산더미처럼 쌓이는 메시지를 처리하는 핵심 기능 자체를 대응하지 못한다. 그저 Mail을 GTD 시스템의 하나로서 좀더 효과적으로 운용하고자 하는 필요를 지원하는 위한 유틸리티이다. 혹시 제목이나 발신자를 통한 자동 분류 기능이 필요해 별도 유틸리티가 있어야 한다면 생각하면 이 정도 기능은 모든 이-메일 서비스나 이-메일 클라이언트가 기본적으로 제공하는 기능이다.

만일 MailTags를 통하여 지금까지 미뤄놨던 메시지 정리가 좀더 수월하게 될 것이라고 기대한다면 역시나 비용은 비용대로 지불하고 메시지는 여전히 Inbox 폴더에 쌓여가고 있을 것이다. 언제나 그렇듯 지원 부대가 주력 부대가 할 일을 대신해 주지는 않는다.

- - - - -

MailTags와 같은 Mail 관리 지원 프로그램의 가장 큰 문제는 역시 애플의 잦은 업데이트에 따른 호환성 문제인데 특히 MailTags는 그러한 경우가 상당히 심한 편이었다. 때문에 오랜 사용 기간에 비춰 MailTags를 실질적으로 사용하지 못한 기간도 제법된다고 생각된다. 솔직히 뜬금 없이 당하는 일이라 당황한 경우가 많았다. 아마 MailTags가 제공하는 기능에 비해 순위권에서 다뤄지지 못하는 가장 큰 이유 중 하나일 것이라 생각한다.

한 해를 정리하기 위한 마무리 일들

GTD 시스템의 Tickler 폴더에 드디어 마지막 폴더가 남았다. 이제 곧 2019년이 저물고 다시금-어떤 의미가 있는 지 불명확하지만 괜한 기대를 가지게 하는-2020년이 시작되려고 한다. 수 많은 이들이 몇 시간 남지 않은 한 해가 시작될 때 계획한 수 많은 일이 기대한 바대로 되지 못했음을 아쉬고 하고 있을 것이다. 더불어 2020년을 성공적 한 해로 만들기 위해 어떤 계획을 수립해야 할 지 고민하는 이들도 많을 것이다.

한편으로 그런 여유조차 없이 한 해가 바뀌는 그 날, 그 순간에서도 밤새 일 하는 지경에 놓은 이들도 있을 것이다. 아마 나 스스로는 비슷한 처지에 놓이지 않을까 우려된다. 어쨌든 우려나 기대와 상관없이 시간은 흐르고, 날이 바뀌고 해가 바뀌게 되면서 새 해가 시작될 것이다.

만일 2019년이 분명 아쉽고 제대로 정리되지 못했다면 하나라도 마무리하는 것이 필요하다. 특히 상황이 2020년까지 이어지면서 자신의 관리 체계를 느리게 복잡하게 그리고 무겁게 만드는 대상을 찾아 정리하고 관리해야 할 필요가 있다. 나의 경우 언제나 그 일들의 우선 대상은 이-메일 시스템 정리가 되었다. 현재 이-메일 시스템의 상황은 하루가 지나고, 며칠이 지나고, 그리고 몇 달이 지난 현실의 상황을 보여주는 증거라고 할 수 있다. 매일 매일 그 날의 메시지 수집함을 비우고, 분류하고, 그리고 정리하고자 했지만, 작심삼일 그 자체의 완벽한 현실이다.

쌓인 메시지가 얼마나 많은 지는 개인마다 다르겠지만 이-메일 시스템을 정리하는 일은 채 하루 혹은 몇 시간 걸리지 않는 일이다. 마음 먹고 한다면 한 시간 내에 끝낼 수도 있다. 이유는 간단한 2019년 기준-그 이전 년도의 메시지까지 있다면 포함해서-메일 박스에 쌓인 수 많은 메시지는 지금껏 시간이 나고 여유가 생기면 보려고 했겠지만 여전히 그대로 있다. 그러니 각 메시지를 일일이 확인할 필요 없이 그냥 삭제하면 끝이다. 스스로 자신의 과감함을 증명하고 싶다면 지워진 메시지로 가득 쌓인 휴지통을 비워도 것도 새해를 맞이하는 자세라고 할 수 있다(물론 절대 추천하지는 않는다).

전체 삭제가 불안하다면 2019년 11월까지 메시지만 삭제해도 상관없다. 필요한 메시지는 대부분 별도의 메일 박스로 옮겨졌을 것이 분명하다. 몇 일 동안, 몇 주 동안, 그리고 몇 달 동안 쌓인 한 해의 메시지를 앞으로 보게 될 가능성은 거의 없다.

같은 시각에서 컴퓨터 시스템의 여기 저기 흩어져 갈 곳을 잃은 채 쌓인 무수한 다운로드된 파일들도 마찬가지일 것이다. 제목 조차 없이 내용 파악을 위해 일일이 파일을 열어야 하는 경우도 만만치 않게 시간을 허비하게 만들 것이다. 모조리 휴지통으로 보내 영구 삭제하거나 불안하다면 별도 폴더로 모두 옮기도록 한다. 이때 가능하면 별도의 폴더의 메인 시스템이나 아닌 외부 장치로 옮기는 것이 현실적으로 가장 효용성이 있다.

파일 이름과 내용으로 파일 중복성을 파악하여 보다 정리가 쉽도록 해주는 몇몇 유틸리티가 있지만, 그 어느 것도 100% 완벽하지 않기 때문에 완전한 정리를 기대하기는 어렵다. 컴퓨터 시스템의 용량도 줄고 속도도 개선해 줄 지 모른다. 다운로드 후 수 개월 지난 파일을 앞으로-보고 싶은 심정은 이해하나-볼 일은 없을 것이다.

디지털 환경에서의 이-메일 시스템이나 다운로드 파일드을 정리 했다면, 다음은 당연히 아날로그 세상의 물건을 정리할 필요가 있다. 우리의 주변은 언제가 될 지 모르지만 무한한 가치를 가진 여러 메모, 문서, 논문, 책 등으로 가득하다. 내 주변도 역시 올해도 변함없이 언젠가 사용하게 될 지 모른다면 쌓아둔 이면지, 카페에 들러 한 장 씩 , 몇 장 씩 들고와서는 책상 위와 서랍을 가득 채운 휴지, 그리고 수 많은 필요성을 가지고서 주변에 쌓인 물건들이다. 물론 넘치려고 하는 쓰레기통을 배우는 것도 주요할 일이다.

현실적 가능한 범위에서 이러한 정리 작업이 어느 정도 마무리 되었다면, 하루 정도는 한 해를 정리하는 시간일 필요하다. 운이 좋다면 2019년을 시작하는 즈음 만들어 놓은 계획서가 그대로 있을 수 있다. 계획한 일이 얼마나 수정 되었고 달성 되었고 그리고 폐기 되었는 지 어렴풋이나마 알 수 있을 지 모른다. 그리고 일을 계획하는 자체가-기대에 비해-얼마나 효용성이 없는 일이란 것도 알 수 있을 지 모른다. 계획 보다는 계획 하는 그 순간의 열정과 노력이 목표를 향하게 하는 원동력이었다는 생각이 들지도 모르겠다.

GTD E-메일 관리 완전 정복

GTD 시스템 운용에 있어 E-메일은-각자의 경우에 따라 다르겠지만-단순한 일상 업무 도구이이면서 중요한 업무 관리 체계인 반면 의외로 생산적인 운용이 쉽지않으며 또한 번거롭기도 한 골치덩이 가운데 하나이다. 그럼에도 대개 E-메일 시스템 혹은 메시지의 관리 자체는 특별히 어렵지 않고 언제라고 정리가 가능하다고 생각하기 때문에 정기적이거나 혹은 집중적인 관리를 하지 않는 경우가 대부분이다.

그러나 잠시 시간이 흐르면서 하루가 멀다하고 쌓이는 수 많은 E-메시지에 파묻혀 결국 관리가 불가능한 상태로 전락하게 된다. 덕분에 해마다 혹은 새로운 계기가 생길 때마다 E-메일 시스템을 정비하기 위한 노력하지만 결과는 언제나 그대로다.

E-메일을 GTD 시스템의 관리 요소로 생각하지 않고 운용할 수 있겠지만 대개 회사 업무와 관련한 일상적 업무들이-특정 업무 처리 시스템이 따라 구성이나 절차가 다르기는 하더라도-기능적인 측면에서는 E-메일에 기반하고 있는 경우가 많다.

새해 첫 아침 E-메일 시스템의 수집함은 완전히 비워져 있고 2019년의 새로운 메시지가 들어 온 상태인가? 아마 지난 해 혹은 어제까지도 읽지 못한 메시지가 가득할 것이다. 물론 대부분의 사람들은 E-메일 시스템이 쓸데없는 일상의 메시지나 스팸성 메시지로 가득하다고 생각하고 언제나처럼 크게 신경을 쓰지 않고 필요하면 그 가운데 원하는 메시지를 골라 읽고 관련한 일 처리를 진행할 수 있다고 생각한다. 이렇듯 대부분의 사람들은 무엇을 기대하든 의도와 상관없이 언제나 E-메일 시스템의 수집함은 읽지 않은 메시지로 가득 차 있고 또한 이미 수 많은 분류 폴더에도 역시나 읽지 않은 메시지들이 차고 넘칠 것이다.

효율적인고 E-메일 관리는 누구에게나 쉽지 않은 과제이다. 그래서 새해를 맞이한 느낌으로 E-메일 시스템을 보다 생산적으로 관리하기 위한 방안에 대한 내용을 포스팅하게 되었다.

- - - - -

우선 E-메일 시스템의 수집함(inbox)을 비운다 혹은 정리한다는 것은 E-메일 메시지가 담고 있는 일에 관한 내용 즉 무언가에 대한 실행 조치를 고민하는 것이 아니라, GTD의 수집함 비우기 과정처럼 단순하게 E-메일 메시지를 지우고 옮기는 비우는 등의 작업을 의미한다는 점이 주요하다.

 대개 E-메일 메시지는 보게 되는 순간 그 내용 그리고 관련한 이후 실행 계획에 대해 고민하기 시작하고, 결국 다른 메시지로 넘어 가지 못한 채 일상의 다른 일로 빠지게 된다. 때문에 E-메일 시스템을 신뢰성있는 업무 관리 체계로 유지하기 위해서는 쌓여 있는 그리고 쌓여 가는 메세지에 대한 적절한 전체적 대응 방안이 필요하다. 즉 메시지가 내포한 일에 대한 조치는 수집함을 비운 이후의 단계에서 진행할 수 있도록 해야 한다.

이러한 과정에 대해 GTD의 창시자인 David Allen도 몇 가지 방안을 제시하기도 했다. 하지만 대부분의 사용자가 표준적이고 이상적인 E-메일 시스템 관리 방안을 직접적으로 적용할 수 있는 지에 대해서는 의문이 남는다. 기술적 이해는 가능하지만 기능적으로 현실적 운용은 만만치 않을 수 있다. 하지만 수 없는 시도에도 불구하고 제대로 된 E-메일 시스템 관리 체계를 구축하지 못한 경우라면, 분명 참고할 수 있는 효과적인 레퍼런스라고 할 수 있다. 하지만 먼저 이상적인 E-메일 시스템 관리가 현실적으로 쉽지 않은 몇 가지 이유에 대해 이해할 필요가 있다.

인터넷이 현재와 같이 일상화되기 이전에는 E-메일 서비스의 사용을 위한 계정은 두 개 이상 운용하기는 쉽지 않았다. 하지만 인터넷 시대로 들어서면 수 많은 무료 E-메일 서비스가 제공되면서 두 개 이상의 계정을 사용하는 것은 매우 자연스러운 상황이 되었고, 회사 업무, 학교 업무, 그리고 개인 업무 등에 따라 별도의 E-메일 계정을 운용하기도 한다.

문제는 표준적인 E-메일 메시지에 대한 관리가 어렵게 되는 여러 이유 가운데 하나는 현재 사용하는 여러 E-메일 서비스가 제공하는 기능적 범위와 각 계정에 대한 접속 방식이 결코 동일하지 않아 단일화된 관리 체계의 구축과 운용이 불가능하다는 점이다.

나 또한 마찬가지인데 주로 사용하는 E-메일 계정의 하나는 업무와 관련된 회사 계정이고 다른 하나는 대외 업무와 개인 용도로 사용하는 구글 계정이다. 두 계정 모두 E-메일 클라이언트, Apple Mail에서 IMAP로 연결되지만 회사 계정은 사외에서는 SMTP 서버에 연결되지 않아 메시지 전송이 되지 않는다. 결국 E-메일 클라이언트에서 회사 계정은 메시지를 확인하는 용도로 사용되며, 부득이 사외에서 답장을 해야 하는 경우에는 직접 웹 브라우저로 메일 서비스 사이트에 접속하여 메시지를 작성하거나 답장을 한다. 이런 불편함을 해소하기 위해 회사 계정을 구글 계정에 연동하여 사용하기도 했지만 상대적으로 낮은 수준의 회사 E-메일 서비스의 한계로 제대로 된 운용이 어려웠다. 다행히 그나마 메시지를 보내는 것 이외 메시지 삭제나 폴더 이동 등은 문제가 없어 E-메일 클라이언트에서의 메시지 관리 자체에 큰 문제가 되지 않는 점이 그나마 다행이다. 이렇듯 사용하는 E-메일 시스템 환경에서따라 다양한 변수들이 효율적 E-메일 메시지 관리 체계의 구축과 유지에 방해가 될 수도 있다.

더욱이 보안 등을 이유로 IMAP나 POP3 마저 지원하지 않는 E-메일 서비스라면 더 말할 필요가 없을 것이며, 이런 경우는 부득이 관리하는 E-메일 계정마다 별도의 관리 체계를 구축하여 적용할 수 밖에 없을 것이다. 더불어 업무와 관련한 회사의 E-메일 계정의 서비스의 기능 등은 내 의지와 상관없이-심지어는 더 열악하게-바뀔 수 있는 가능성도 있다.

- - - - -

E-메일 시스템의 효율적 운용이 어려울 수 있는 또 다른 점은 어떤 E-메일 서비스 그리고 E-메일 클랑이언트를 사용하느냐에 따라 관리 기능의 차이가 있다는 점이다.

대표적인 E-메일 클라이언트인 Apple Mail, Microsoft Outlook, 그리고 Lotus Notes는 제공하는 기능의 차이는 물론 구현 방식에도 차이가 적지 않다. 또한 외부 플러그-인의 사용까지 고려하면 관리 기능의 범위는 비교하기 힘들다. 그리고 사용하는 E-메일 서비스 역시 기능의 활용성에서 큰 차이가 있다. 구글의 메일처럼 웹 기반으로 폭넓은 기능이 제공하는 E-메일 서비스가 있는 반면 대부분의 기업에서 운용하는 그룹웨어 기반의 E-메일 서비스는 제한된 기능을 가지고 있고, POP3 조차 지원되지 않을 수도 있다.

더불어 E-메일 메시지를 관리하는 시점에도 차이가 있다. 기본적으로 GTD에서 E-메일 메시지 역시 수집 대상의 하나로 볼때 정기적 관리로서 대응할 수 있지만, 업무와 관련한 많은 E-메일 메시지들은 즉각적인 확인과 대응을 필요로 하기도 한다. 즉 하루 이상 기간을 두고 관리할 수도 있지만 쉴새 없이 새로운 메시지를 확인해야 하는 경우도 있다. 이에 따른 개인적인 관리 취향의 차이 역시 E-메일 시스템 운용에 다양한 변수로서 고려될 수 있다.

습관이란 것이 쉽게 바뀔 수 있는 것이 아니므로 어떤 좋은 E-메일 클라이언트를 사용하거나 새로운 E-메일 서비스가 제공되더라도 기존 E-메일 시스템이나 관리 형식을 이전한다는 것은 거의 불가능하다. 특히 새로운 클라이언트나 서비스로 이전시 기존 E-메일 시스템의 정보가 완벽하게 이동되는 경우가를 기대하기는 쉽지 않다.

하지만 현재의 E-메일 메시지 관리 방식에 문제가 있다는 것을 분명히 인식하고 있다면 과감하게 새로운 E-메일 메시지 관리 방식의 변화를 추진할 필요가 있음은 분명하다.

- - - - -

일반적인 E-메일 관리 시스템 운용에서 가장 기본적인 관리의 시작은 수집된 E-메일 메시지에 대한 메시지 제목 혹은 메시지에 대한 간략한 내용 파악에서 시작한다.

그리고 전체적인 E-메일 메시지 관리는 삭제, 보관 그리고 실행 대상으로 전환으로 구분할 수 있다. 또한-비록 포스팅의 내용은 순차적으로 기술되었지만-각 사항에 해당하는 조치를 관리 선호도에 따라 동시적 평가로도 진행할 수 있다.

1. 메시지 삭제

이-메일 수집함(inbox) 비우기의 가장 단순하면서도 핵심적인 과정이 지우기라고 할 수 있다. 즉 필요 없다고 판단되는 메시지에 대한 즉각적 삭제 조치이다. 하지만 기능적 조치의 단순함에도 불구하고 현실적으로 가장 어려운 부분이기도 하다.

메시지 제목을 읽는 순간 현재 혹은 미래 상황에서의 필요성이 거의 없다고 판단되거나 혹은 다소 모호성이 있다면 일단 즉각적 삭제의 대상이다. 이러한 과정이 무리없이 진행되기 위해서는 메시지의 상세 내용에 대해 집중하지 않도록 해야한다.

메시지가 담고 있는 내용 자체가 의미가 있다고 판단되더라도 현재 업무 진행이나 앞으로의 실질적 계획의 관점에서만 평가해야만 객관적 삭제가 용이해진다. 메시지가 담고 있는 내용에 집중하게 되면 향후 활용성이나 유용성의 기준에서 볼때 쉽게 삭제하기란 쉽지 않다. 심지어 스팸성 메시지의 내용에서 조차 참고할 사안을 찾고자 한다면 없지 않을 것이다. 메시지 제목을 읽는 순간 자신의 판단을 믿고 즉시 삭제하기 바란다.

그럼에도 충분히 보관해야 하는 대상으로 판단된다면 별도의 보관 폴더를 이동한다. 하지만 사실 이러한 판단으로 쌓인 메시지가 사실 E-메일 저장량의 대부분을 차지한다. 그러므로 무턱대고 보관 폴더로 보내기 보다는 차라리 삭제하는 편이 GTD 시스템의 신뢰성 유지에 훨씬 효율적이다.

메시지 삭제는 E-메일 관리에서 가장 단순한 기능이라는 점에서 스마트 폰 등 모바일 기기에서 쉽게 수행할 수 있다. 잠깐 시간적 여유가 있거나 이동 중 특별한 작업을 할 수 없는 상황에서 유용하다.

오랫동안 E-메일 시스템을 관리하지 않아 수집함에 새로운 메시지가 산적해 있다면 날짜 혹은 보낸 사람 등과 같이 기준 정보를 이용하여 이전 메시지를 일괄 삭제하는 등의 방식을 적용할 수도 있다.

만일 특정 제목, 내용 그리고 발신자의 E-메일 메시지를 계속 삭제하고 있다면, E-메일 발송 중단을 요청하거나 필터 기능으로 자동 삭제 혹은 분류되도록 조치하도록 한다.

2. 메시지 분류

삭제 대상이 아닌 E-메일 메시지는 참고할 정보를 포함하거나 혹은 실행 여부를 판단해야 하거나 혹은 실행 해야하는 대상일 것이다. 그 가운데 실제 업무 실행과 직접적 관련이 없지만 미래 가치의 정보로서 평가되다면 수집함을 떠나 별도의 폴더로 이동 시킨다. 대개 일반적으로 참고용 정보라고 할 수 있다.

참고용 E-메일 메시지에 대한 가장 일반적인 분류는 특정 주제 혹은 프로젝트 단위로 폴더를 구성하는 것이다. 하지만 이러한 분류는 업무의 종류와 범위에 따라 생성되는 폴더의 수가 증가되고 이를 별도로 관리해야 하는 새로운 부담이 생길 수 있다. 특히 계층화된 구조로 폴더를 구성하고 있다면 메시지 관리가 더욱 어려울 수도 있다. 때문에 이러한 방식에서는 적절한 폴더의 수는 규정할 수 없지만 가능한 최소한의 폴더 구성을 유지하는 것이 좋다.

또 다른 메시지 분류 방법은 실행 요소를 갖추지 않은 참고용 자료라면 점에서 하나의 폴더로 모아 관리할 수 있다. 복잡한 폴더 구조로 인해 관리의 어려움은 없지만 하나의 폴더에 너무 많은 메시지가 모인다는 점에서 필요한 정보를 정확하게 활용하기 어려울 수 있다. 때문에 날짜나 발신자 등의 정보에 기반한 정렬이나 필터 기능을 이용하여 내부적인 구분이나 분류로서 가상의 폴더, 스마트 폴더를 활용하는 방식을 이용할 수도 있다. 하지만 이 역시 과도한 가상 폴더가 쌓이게 되면 관리의 부담은 증가할 수 밖에 없다.

그러나 어느 경우라도 일정 기간 내에 분류된 메시지에 대한 추가적인 조치를 실행하지 않으면 곧 폴더는 읽지 않은 메시지로 쌓이게 되기 때문에 폴더 구성도 주요하지만 옮겨진 메시지에 대한 정기적 관리가 핵심이다. 수 년이 지났음에도 여전히 활용되지 못하고 참고 폴더에 존재하고 있는 E-메일 메시지라면 즉각적 삭제 대상이라고 해도 큰 무리가 없을 것이다.

간혹 지난 날짜의 E-메일 메시지에 대한 일괄 삭제 후 필요한 메시지를 찾게 되는 경우가 없지 않다. 이를 우려하여 참고 폴더에 가득한 메시지를 수년에 걸쳐 삭제하지 않는다는 것은 매우 비효율적이다. 때문에 무엇보다도 이러한 경우를 겪지 않도록 참고 폴더에 대한 정기적인 관리를 진행할 수 있도록 해야만 한다.

사실 참고 폴더로 옮겨진 E-메일 메시지의 상당수가 삭제 여부를 고민하다가 이전되었다는 점에서 대부분 삭제되어도 문제가 없다고 볼 수 있다. 때문에 참고 폴더에 옮겨진 E-메일 메시지에 대해서는 삭제 여부에 대한 추가적 검토 과정 없이 내용에 대한 즉각적 판단으로 정리 작업을 진행할 필요가 있다.

이상의 과정에서 메시지 삭제가 단순하면서 어려운 작업인 것에 비해 메시지 분류는 복잡하면서 어려운 작업이다. 하지만 폴더 구성 자체는 단순하기 때문에 많은 GTD 사용자들이 섵부린 과도한 폴더 구조의 생성과 관리 부재로 인해 E-메일 시스템의 관리 기능을 상실하게 만들고 있다는 염두에 두어야 한다.

3. 메시지 실행 및 위임

삭제되거나 참고용으로 분류되지 않은 E-메시지는 현재 및 향후 업무와 직간접적 관련이 있는, 즉 실행 요소나 실행 요구가 포함한 대상들이다.

우선 직접적인 실행 요소를 가진 메시지는 GTD 시스템의 새로운 수집 대상 혹은 기존 프로젝트 등의 실행 업무로 생성한다. 사용하는 GTD 어플리케이션에 따라 E-메일 클라이언트에서 메시지를 직접 이전하는 방법을 사용할 수도 있을 것이다.

그리고 직접적인 실행이 아닌 타인 혹은 외부의 실행에 의한 결과를 확인해야 하거나 이후 새로운 실행 작업이 생성되어야 하는 메시지는 위임 혹은 대기 임무는 구분하여 관리 한다.

실행 요소를 가진 E-메일 메시지의 관리는 각 메시지에 포함된 정확한 실행 및 완료 요소를 파악할 수 있도록 한다. 기존 업무와 관련된 사항이라면 메시지를 직접 프로젝트로 이전하거나 프로젝트 내에 새로운 업무로 생성한다. 절차적 방식은 사용하는 GTD 어플리케이션이 제공하는 기능에 따라 달라 질 수 있다.

직접 실행이 아닌 간접 실행, 위임 업무에 대한 확인 등은 일반적으로 특정 일자 및 시각을 마감일 혹은 시작일로 지정될 수 있기 때문에 GTD 시스템의 실행 요소로 입력하지 않아 달력 등에 표시하여거나 확인 사항을 Tickler 폴더에 입력하여 향후 확인할 수도 있다.

이상과 같이 실행 요소를 가진 E-메일 메시지의 관리는 사용하는 GTD 시스템과 기능에 따라 활용 방식이 달라질 것이다. 업무의 대부분이 E-메일 기반으로 진행되는 경우는 모든 업무 실행 관리를 E-메일 시스템 내에서 완료할 수도 있을 것이다. 실제 구글의 E-메일 서비스에 제공하는 다양하고 강력한 기능을 기반으로 GTD 시스템을 구성하여 활용하는 경우도 없지 않다.

개인적으로 E-메일 클라이언트로서 Apple Mail 그리고 GTD 시스템으로 OmniFocus를 사용하지만, E-메일 기반의 업무 사항이 많지 않기 때문에 Apple Mail에서 OmniFocus의 수집함이나 프로젝트 목록에 E-메일 메시지의 실행 정보에 기반한 새로운 실행 업무를 직접 생성하는 방식을 사용한다. 물론 OmniFocus의 E-메일 메시지 관리 기능을 이용할 수 있지만, 새로운 E-메일 메시지를 생성하여 발송하는 체계이기 때문에 불편해서 사용하지 않는다.

반면 Microsoft Outlook은 E-메일 시스템 기능과 달력, 일정 및 업무 관리 기능이 통합되어 있기 때문에 E-메일 메시지 기반의 업무 생성이 상대적으로 효과적이다.

일반적으로 볼 때 어떤 GTD 시스템 혹은 E-메일 시스템을 사용하더라도 실행 업무의 관리에 있어서 핵심은 이미 실행에 대한 알림, 실행 여부 확인 그리고 완료 검토 및 다음 실행 항목에 대한 알림 등으로 이어지는 GTD 관리 체계의 구현이다.

하지만 이러한 관리 방식에 대한 일상적 예외 사항이 있는데, 그것은 E-메일 메시지에 대한 답장 그리고 답장에 따른 후속 실행 업무의 생성에 관한 것이다. GTD 시스템에서 단순하게 보자면 답장 그리고 응답은 위임 업무에 해당될 수 있으며, 답장 후 조치는 앞서의 일반적인 E-메일 메시지와 관리와 동일하다. 그러므로 앞서 언급한 바와 같이 업무의 상당 부분이 E-메일 메시지의 전달로 진행되는 경우라면 이러한 기능을 온전히 수용하는 Microsoft Outlook 등으로 GTD 시스템을 구축하는 편이 효과적이다. 반대로 E-메일 메시지의 양과 업무 내용으로 판단하여 GTD 시스템과 E-메일 시스템을 완전히 구분하여 사용하는 방법으로 대응할 수도 있을 것이다.

- - - - -

정기적 점검 관리

이상과 같은 E-메일 시스템 관리 방식에서 가장 주요한 사안은 수집함 비우기를 마친 후, 그리고 실행 요소의 메시지를 새로운 수집 사항으로 이전한 후, GTD 시스템에서의 일 처리 흐름에 따라 머릿 속에서 E-메일 메시지에 담긴 온갖 정보와 내용을 잊는 것이다. E-메시지에 의한 실행 업무 생성 및 실질적 업무는 E-메일 관리 이후의 단계이다.

그리고 E-메일 메시지 관리의 기본은 정기적으로 수집함의 메시지를 확인하고 수집함을 비우기를 완수하는 것이다. 만일 E-메시지가 수집함에 쌓이는 속도에 대응하지 못한다면 E-메일 시스템은 언제라도 관리 불능의 상태로 전락할 수 있다. 만일 일상의 업무용 E-메일이라는 몇 분 혹은 몇 시간 단위로 새로운 메시지가 들어 오고 또한 그에 따른 답장을 하는 등의 과정이 진행된다는 이에 맞도록 대응해야 한다.

결국 E-메일 시스템과 메시지 관리는 업무의 행태나 내용에 따라 일률적으로 좋은 방법과 나쁜 방법을 섣불리 판단할 수는 없다. 나쁜 방법이라고 효과적인 E-메일 시스템에 의해 적절히 대응할 수 있고 반대의 경우도 경험할 수 있다. 그러므로 현재의 E-메일 관리 방식이 자신의 업무 생산성 개선에 부응하지 못하거나 심하게는 생산성 저하의 원인일 수도 있다는 점에서 상황과 상태인지를 객관적으로 판단할 필요가 있다.

또한 E-메일 메시지의 관리는 물론 정기적으로 E-메일 시스템의 관리가 용이한 체계의 구축도 관심을 가질 필요가 있다. 특히 필요에 의한 현재의 메시지 정보를 저장하거나 이전하기 위한 방안도 사전에 검토할 기회를 가지는 것도 향후 E-메일 시스템 전환에 효과적으로 대응할 수 있는 방안이다.

Apple Mail이나 Microsoft Outlook 혹은 다른 E-메일 클라이언트는 물론 구글 메일과 같은 웹 기반의 E-메일 서비스들은 사용자의 업무 생산성 개선을 위한 여러 기능을 제공하지 있지만 대부분의 사용자들은 기본적인 E-메일 메시지 송수신 기능 수준에서 사용하는 경우가 일상적이다.

때문에 현재의 E-메일 시스템의 생산성을 개선하기 위한 기본적 대응 절차는 정기적인 현재 상태에 대한 현황 파악과 수집함을 비롯한 참고 폴더 비우기를 완수하는 과정이다. 그리고 이를 위한 최적의 관리 기간을 설정하여 철저히 준수할 수 있도록 한다.

Mail.App: 스마트 메일박스 활용

내가 사용하는 Mail.App는 OS X의 포함된 메일 클라이언트로 윈도우즈의 Outlook Express나 Office Outlook의 메일 클라이언트 기능에 대응되는 제품이다. Outlook의 경우 많은 POP, IMAP, HTTP 등 다양한 메일 서버를 지원하고 메일 클라이언트 용도로는 꽤 훌륭하고, 또한 일정 관리, 할 일, 주소록에 포함된 정보와의 상호 운용성도 뛰어나다. 하지만 비싼 돈주고 사는 제품으로서 이정도는 당연하다. 그럼에도 난 윈도우즈 환경에서도 Mozilla의 Thunderbird를 사용한다. 내게 있어 Outlook의 메일 클라이언트는 필요한 다양한 용도에 적용하기가 너무 불편하고, 또한 시스템 자원이 넉넉치 않은 환경에서 너무 무겁다.

이에 반하여 OS X의 Mail.App은 GTD 시스템 구축이라는 측면에서 매우 효율적이다. 특히 사용자가 생성할 수 있는 메일 폴더는 물론 스마트 메일박스를 이용하게 되면 Mail.App 자체만으로 GTD 시스템의 역할까지 수행할 수 있다. Mail.App를 GTD 시스템으로 활용함에 있어 가장 주요한 기능은 메일박스와 스마트 메일박스라고 볼 수 있다.

특히 스마트 메일박스는 메일 자체의 이동없이 Mail.App의 각 메일에 지정된 여러가지 항목 그리고 그에 대한 조건을 이용하여 내가 원하는 모든 경우에 적합한 메일 만을 보여줄 수 있게 때문에 GTD 시스템에서 요구되는 컨텍스트나 행동 관리 측면에 완벽하게 적용할 수 있다. 만일 Mail.App에 보다 많은 유연성을 추가하고 싶다면, MailTags ($29.95)라는 플러그-인 소프트웨어를 사용할 수도 있다.

나의 경우는, 오늘 날짜에 처리해야 할 일에 대하여 Today라는 스마트 메일박스를 생성하고, 중요하다고 깃발 표시를 한 경우에 대한 메일 만을 따로 Flagged라는 스마트 메일박스로 관리한다. 그리고 진행 중인 주요한 프로젝트와 별도로 관리되어야 할 컨텍스트에 대한 스마트 메일박스를 운용하고 있다. 그리고 Address Book과 연동하여 특정 그룹이나 지역에서의 메일도 별도로 확인할 수 있으며 이러한 것은 일반적으로 받은 메일에 뿐만 아니라 보낸 메일 혹은 휴지통에 있는 메일들에도 함께 적용할 수 있다.

물론 언급한 기능들이 Mail.App만에 있는 것은 아니다. 하지만 사용자가 제대로 쉽게 쓸 수 있도록 해주어야 하는 것도 아주 중요한 기능의 하나라고 본다. 인터넷에서는 Maill.App의 스마트 메일박스를 이용한 GTD 시스템 운용에 대해서는 매우 많은 정보를 얻을 수 있다.

• Merlin Mann, Some handy Mail.app Smart Mailboxes