2008년 12월 30일 화요일

Things 1.0 RC

맥월드 엑스포 2009를 앞두고 드디어 Things 1.0 RC (Release Candidate)가 공개되었다. 그 동안 정식 버전을 기다리던 사용자들에게는 정말 1.0 버전이 출시되는 것 같은 느낌을 주고 있다. 부디 RC1이 아니길 바라는 이들도 많은 듯 하다. 이래 저래 맥월드 엑스포에 대한 이야기도 있지만 내겐 Things 만으로도 꽤나 관심이 가는 행사가 아닌가 싶다. 하지만 Things 1.0 RC에서도 프로젝트의 계층화 구조가 지원되지 않는 것으로 보아 실제 버전에서는 어떨지 의문과 걱정이 들기도 한다. Things의 개발사인 CulturedCode에서는 프로젝트 계층화에 대해서는 큰 문제가 없다고 생각하는 것 같다. 물론 시스템 구성 방식에 따라 차이가 있을 수 있겠지만 기존 프로젝트 구성으로 계층적으로 사용해 온 입장에서는 상당히 불편하고 또 적응에 시간이 걸리지 않을까 우려스럽기도 하다.

포스팅하고 나서 바로 다음 날 역시나 어느새 RC2가 등장했다. 이어서 RC3도... 점점 사람을 애달게 하고 있지만 이제 정말 버전 1.0이 눈 앞으로 다가온 것 같다.

2008년 12월 15일 월요일

iCal: GTD의 핵심

새로운 맥킨토시 OS X환경에서 Apple 의 Mail.app, Address Book 그리고 iCal은 가장 기본적이면서도 반드시 필요한 기능이자 어플리케이션이다. 특히 OS X 10.5 Leopard에서는 이들의 개별 혹은 상호 운용성이 더욱 높아 졌다. 때문에 맥킨토시에서의 GTD 시스템 구축에서 이들 중 iCal은 그 핵심에 있다. GTD 시스템에서 달력이 차지하는 비중은 일부분이라고 볼 수 있겠지만, OS X 환경의 GTD 시스템에서는 iCal은 달력으로서 기능은 물론 To Do 리스트 관리 및 Address Book과의 연결 등에서 보아 GTD 시스템의 핵심이라고 보아도 틀린 말이 아니다. 이 때문에 맥킨토시의 모든 GTD 소프트웨어에서 iCal과의 동기화는 필수적인 조건이 되었다.

하지만 iCal의 비중이 점점 증가하게 되면서 GTD 시스템 운용 자체의 의미와 효율성을 퇴색시키는 면이 있다는 것을 발견하게 되었다. 일반적으로 GTD 시스템의 태스크 매니지먼트는 별도의 GTD 어플리케이션을 이용하는 경우가 많다고 볼 때, iCal의 캘린더 기능 이외의 업무 관리 기능과 중복 심지어는 충돌이 발생할 수도 있다. 초기 난 iCal의 캘린더를 업무, 강의, 개발, 사업 등등과 같이 마치 프랭클린 플래너에서의 사회적 위치와 역할 그리고 가치와 비슷하다고 구성하여 운용하고자 했다. 하지만 GTD 시스템의 핵심 체제로서의 역할을 강화하기 위해 iCal에 더 많은 정보가 입력되도록 힘을 쏟았다. 덕분에 GTD 어플리케이션은 물론 iCal에서도 업무와 일정 관리를 모두 수행할 수 있었다.

맥킨토시 OS X 환경의 GTD 시스템에서 iCal가 이러한 핵심적인 위치를 가질 수 있게된 것은 무엇인가를 다시 한번 확인해 보고자 한다. 이러한 글을 이미 여러 전문가들에 의해 언급되었으며, Merlin Mann의 iCal에 대한 예찬의 글에서도 몇가지 사항들을 들 수 있었다. iCal은 Microsoft의 Outlook이나 Entorage 등의 소프트웨어와 달리 업무나 일정을 그룹 및 항목 단위의 캘린더로 구분하여 다룬다. 때문에 GTD 소프트웨어에서의 컨텍스트를 캘린더에 할당된다. 예를 들어, E-Mail, 프린팅, 맥북 등의 컨텍스트를 개별 캘린더 혹은 '컴퓨터'라는 캘린더 그룹으로 정할 수도 있다. 이러한 기능은 OS X 환경에서 구동되는 프로젝트나 플래닝 소프트웨어에서도 프로젝트를 iCal의 캘린더에 대응할 수 있는 기능으로 매우 강력하고도 유연하게 운용될 수 있다. 또한 iCal의 To Do나 Event에는 날짜, 시간, 관련 인물 정보, 링크, 파일 등도 함께 입력할 수 있어 상대적으로 작고 빠른 운용 성능을 제공한다. 그리고 각 캘린더 별로 출력하여 해당 프로젝트나 업무용 출력물로서의 활용성도 뛰어 나다. 더하여 OS X 10.5에서는 Mail.app의 To Do와 통합으로 GTD 시스템으로서의 활용성이 한층 더 높아 졌다고 볼 수 있다. 최근 Apple이 .Mac을 대신하여 Me.com을 출시하면서 이를 통한 Mail.app, iCal 그리고 Address Book의 공유로 Mac, PC (Windows)라는 플랫폼 그리고 여러 소프트웨어의 제약으로부터도 훨씬 더 자유로워지게 되었다.

이러한 iCal의 단순명료하면서도 강력한 기능은 앞선 언급했듯이 GTD 어플리케이션과의 운용에서 우선 순위의 변화를 가져오게 되었다. 이러한 변화가 상호작용을 통한 효율증진으로 나타나는 경우도 있으나, 기능의 충돌로 사용자를 혼란스럽게 할 수 있다. 혼란스러움은 GTD 시스템에서 가장 먼저 제거해야할 대상이다. 이 시점에서 다시 한번 GTD 시스템의 기본적인 배경을 생각해 볼 필요가 있겠다. 만일 iCal과 Mail.App 만으로 GTD 시스템을 구축하고자 하는 경우가 아니라면, iCal는 GTD 시스템에서 달력의 역할을 담당하게 된다. 달력에는 시간이나 날짜가 정해진 약속이나 업무가 기록되는 곳이다. 다시 말해, 시간이 정해지지 않았거나 날짜가 시작일 혹은 마감일에 대한 명확한 기준을 제공하지 못하는 경우라면 iCal에서 굳이 다루지 않아도 상관없다고 볼 수 있다. 결국 Someday 혹은 마감일이 정해져 있지 않은 Next에 해당되는 업무는 기록될 필요가 없다.

2008년 11월 25일 화요일

기록을 남긴다는 것

1. 데이터란..

요즈음과 같이 바쁜 세상을 살면서 자신이 일한 결과를 어떤 식으로 남긴다는 것은, 생각해 볼 수록 세삼 힘든 일이라고 여겨진다. 하지만 더 중요한 것은 남기는 기록이 진실 혹은 사실이어야 한다는 것이다. 하지만 사람이란 게 우습게도 자산의 일기를 쓸 때도 조차 스스로에게 불리한 내용은 적지 않거나 혹은 미화하여 남기게 된다. 돌이켜 보면 아마 어린 시절 숙제 검사(특별히 일기 검사)의 쓰라린 기억 탓이라고 생각된다. 물론 집에서도 부모들은 아이들의 일기를 보기 마련이고, 이에 대응하여 영악한 우리들은 일기를 자신의 방어하는 도구로 점점 발전시켜 나가게 된다. 혹은 일기에서 조차 스스로에게 솔직하지 못한 것은 아마도 양심이 있기 때문이라고 좋게 볼 수도 있겠지만 결과적으로 양심을 버리는 일이 될 가능성이 크다. 너무 멀리와 버렸는지 모르지만 결론적으로 한 개인의 자신의 일상 혹은 업무 과정을 기록하여 남긴다는 것은 쉬운 일이 아니다.

2. 노무현 대통령을 기억하며..

뉴스에서 노무현 대통령이 재임 기간 남긴 기록물이 무려 800만건이 넘는다고 한다. 개인적인 메모까지 포함되어 있는 지도 모르겠지만, 개인이 짐 정리를 하다가도 생각하기 싫은 것이나 쓸데없는 것은 버리기 마련인데 어쨌든 대단하다. 관련하여 청와대의 e지원(知園) 시스템은 노무현 전 대통령이 직접 개발에 참여 한 것으로 알고 있다. 실제 프로그래밍에 어느 정도 관여 했는지는 모르겠지만, 예전 부산 시장 선거에서 토론회에 나왔을 때 당시 시정 운영에 관련하여 연구한 내용을 바탕으로 개발한 소프트웨어를 자신의 당선 여부에 상관없이 공개할 수도 있다고 한 것만 보아도 대부분의 정치인들과는 달라 보였다. 그리고 그 소프트웨어와 메뉴얼 등의 자료를 보여주며 ‘저는 그동안 결코 놀지 않았습니다’라고 자신있게 말하는 것을 보면서 선거에 지고 또 지고 하던 자신의 어려운 시절에도 결코 실망하지 않는 모습을 한마디로 멋지게 표현해 주었던 것이 기억된다. 물론 그 소프트웨어를 당시 당선된 시장(누군지 기억조차 없다)은 관심이나 있었을 지 의문이다.

3. GTD에서..

GTD에서는 일단 수집하여 필요성에 따라 버리는 것을 주요하게 다룬다. 개인의 삶, 특히 일상이나 회사 업무에 비춰 실제로 남겨져야 할 것은 거의 없는 것이 사실이다. 직장에서는 어차피 이전 자료의 새로운 자료로의 변환이 일이기 때문에 굳이 후임자를 위해 열심히 정리하여 남길 필요성은 거의 없다. 후임자 역시 전임자의 자료를 보아도 대개는 알지 못하기 때문에 새로 만드는 것이 마음 편한 경우가 많다. 하지만 길지 않은 내 인생 경험에만 비춰보더라도 정리의 대상이 개인적인 추억이 깃든 대상이라면 소중히 간직해야 할 필요도 있다. 생각외로 이런 것들은 나중에 돈이 되기도 하고 다시 구하려면 엄청난(?) 비용을 초래할 수도 있다. 그러므로 GTD에서도 개인과 업무 관련한 일의 대상을 구분할 필요는 분명하다.

2008년 9월 25일 목요일

Things

2008년 10월, CulturedCode의 Things가 아직까지 정식 버전으로 출시되지 않고 있다. 2007년 말 베타 버전 공개 이후, 정식 출시 예정은 2008년 봄이었으나 여름으로 그리고 가을로 미뤄졌었고, 2009년 1월 7일 맥월드 엑스포에서 버전 1.0 출시가 알려지고 있다. 거의 1년 가까운 출시 일정 연기로 인해 초기의 폭발적 인기가 식은 면도 있지만 여전히 GTD 프로그램 가운데 가장 많은 관심과 사용자를 확보하고 있다고 본다. 이러한 출시 예정 연기는 CulturedCode가 iPhone과 iPod Touch 버전 Things 개발에 집중하고 있기 때문이 아닌가 생각된다. 그럼에도 나의 Things에 대한 기대는 아직도 여전한데, 그 몇 가지 사항을 적고자 한다.

1. 멀티-태그 (Tags)

Things는 iGTD나 OmniFocus와 같은 맥킨토시용 GTD 프로그램에 비하면 GTD 원칙적인 기준에서 벗어나 보인다. Things에는 컨텍스트라는 GTD의 핵심 운용 요소가 빠져있는 것으로 보인다. 그러나 별도의 컨텍스트라는 요소가 없기는 하지만 하나의 일이나 프로젝트에 대하여 여러 개의 태그를 지정하고 이 태그 들 간의 조합으로서 컨텍스트의 역할을 수행하도록 한다. 이러한 Things의 멀티-태그 운용 방식은 기존 GTD 프로그램에서 반드시 하나의 일에 하나의 컨텍스트 가 지정되어야 한다는 문제를 해소할 수 있다. 즉, 멀티-태그를 이용하여 하나의 일이 여러 개의 컨텍스트에 지정될 수 있다. 실제 일 처리 과정에서 하나의 일을 하나의 컨텍스트에 종속시키는 것이 쉽지 않은 경우가 많다. 하나의 일에 위치 , 시간 혹은 형식 등 필요한 조건을 모두 지정하므로 써 유연한 업무 관리가 가능하게 된다. 또한 입력된 태그에 대한 자동 완성 기능이 제공되기 때문에 일관된 태그 사용에 도움을 주며, Things에는 시간이나 우선 순위에 대한 예가 이미 포함되어 있다. 특히 태그의 양이 많아지게 되면 유사한 태그들을 하나의 그룹을 묶어 계층적으로 관리할 수 있어 매우 편리하다.

2. FOCUS

Things에서도 GTD 시스템으로서의 시작은 수집함에서 시작된다. Inbox에서 직접 새로운 항목을 생성하거나 Quick Add 기능을 사용할 수 있다. 수집된 항목들에 대하여 태그, 내용, 마감일 그리고 미리 알림 기간 등을 정할 수 있는 GTD 시스템의 평가 및 관리 단계를 수행한다. Things는 별도로 컨텍스트를 지정하는 과정이 없기 때문에 기본적으로 Due Date에 기반한 실행 시기에 따라 분류되고, 각 항목들은 이에 따라 Next, Someday 그리고 Scheduled 폴더로 이동된다.

rNE8Rlr.jpg

Next 폴더에는 Due Date가 지정된 관리 대상의 일들이 대기하고 있다가 오늘 날짜에 해당되는 일이 되면 자동적으로 Today 폴더로 이동된다. Someday 폴더에는 즉각적인 실행을 필요로 하지 않은 일들이 저장된다. Scheduled(이전 Postponed) 폴더에는 Today 혹은 Next 폴더에서 특정 날짜로 미뤄지거나 혹은 특정 날짜에 반복되는 일들이 저장되고 해당 날짜가 되면 Today 폴더에 나타난다.

3. Project & Area of Responsibility

프로젝트(Project) 는 하나의 목적이나 결과를 얻기위한 일들의 집합이다. 프로젝트 내의 일은 Next 폴더는 물론 Scheduled 폴더에 저장되어 있을 수 있다. 그리고 책임 영역(Area of Responsiblity)은 지속되어야 할 가치나 목표를 위한 관리 폴더로서 여러 개의 프로젝트와 일들이 함께 저장될 수 있다. 하지만 프로젝트와 달리 자동적으로 완료될 수는 없다.

특별히 Things는 다른 GTD 프로그램들과 달리 Area of Responsibility에 프로젝트 폴더가 이동되는 경우를 제외하고는 계층적 프로젝트 관리를 지원하지 않는다. 때문에 프로젝트와 책임 영역 폴더의 구분만으로 많은 일과 복잡한 구조의 업무를 관리하기에는 어려움이 있을 수 있다. 때문에 무엇보다도 정식 버전이나 향후에는 계층적 프로젝트 관리가 지원되길 기대한다.

4. People

특이하게 Things에서는 Mac OS X의 Address Book에 등록된 사람이나 회사를 팀 메이트(Team Mate)로 연결하여 일을 할당할 수 있다. 이를 통하여 GTD의 위임 기능을 매우 효율적으로 관리할 수 있다. 위임 시에 일일이 해당되는 사람이나 부서를 생성해야하는 것에 비해 매우 효과적이라고 본다.

5. iCal Sync

최근 업데이트된 Things의 iCal 싱크 기능은 Inbox, Today, Next 그리고 Someday라는 Focus의 각 폴더에 하나 혹은 그 이상의 iCal 캘린더를 동기화할 수 있다. 반대로 말하자면 Things는 iGTD나 OmniFocus처럼 iCal의 각 캘린더를 개별적으로 동기화할 수 없다. 그리고 OS X 10.5(Leopard)에서는 iCal과 Mail의 To Do 항목이 서로 공유되기 때문에 그리고 동기화된 Things의 Focus 항목들이 중복 복사되는 문제가 생기기도 했다. 이러한 경우, Things를 주 입력 도구로 사용하여 캘린더 항목을 관리해야만 한다. Today와 Next 폴더는 같은 항목을 다루고 있기 때문에 동시에 동기화할 필요가 없으며, 특정 태그를 가진 일들이 동기화되도록 설정할 수도 있다.

현재까지 정식 버전 출시 전이기 때문에 모든 기능들이 완벽하게 구현되고 있는 상태이지만 Things는 단순한 처리 구조와 이쁜 인터페이스로 계속 관심의 대상이 되고 있다. 하지만 기능적인 면에서 iGTD나 OmniFocus에 비해 상대적으로 부족하기 때문에 사용자에 따라 평가도 크게 엇갈리는 것 같다. 어쨌거나 2009년 1월의 정식 버전의 출시가 기대되며, 현재의 프리뷰 버전에서의 인기가 약 $50의 비용을 지불해야하는 상황으로 바뀔 때에도 그대로 지속될지 궁금하다.

2008년 8월 31일 일요일

Things: Things 리스트의 이해

의도했는지는 몰라도 Things는 애초 GTD 프로그램으로서 발표되지는 않았다. 하지만 OmniFocus나 iGTD와 같이 복잡한 인터페이스를 가진 프로그램들에 비해 Inbox, Today, Next, Scheduled 그리고 Someday로 구분된 디지인과 멀티 태그의 편의성으로 단숨에 최고의 GTD 프로그램으로 평가되었고 현재까디고 가장 사용자가 많은 GTD 프로그램의 하나가 되었다.

현재 Things 2.1이 출시되었는데 내부의 각 항목 리스트는 초기와 크게 다르지 않은데, OmniFocus에 비하여 단순하면서도 내부적으로 일의 관리가 효율적으로 진행되도록 체계가 잘 잡혀있다.

  • Inbox - 새로운 일의 수집함
  • Today - 오늘 수행 할 일의 목록
  • Next - 향후 수행 할 일의 목록
  • Scheduled - 수행 일자가 정해진 일의 목록
  • Someday - 수행 여부가 정해지지 않은 일이나 자료의 목록
  • Projects - 진행 프로젝트의 목록
  • Area of Responsibility - 책임 범위에 따른 일의 구분을 위한 폴더
  • Contact - 위임 목록
  • Logbook - 완료된 일의 목록

Inbox에 수집된 항목들 중 특정 날짜에 수행되도록 지정된 일들은 Scheduled 리스트로 보내져서 관리된다. Due Date가 오늘 날짜가 되면 Today 리스트에 할 일이 나타나며, 일정이 정해지지 않은 모든 일들은 Next 목록에 저장된다. 정확한 날짜가 정해지지 않았다는 면에서 Next와 Someday가 유사할 수 있지만, Next는 실행 예정인 일의 목록인 것에 비해 Someday는 아직 실행 여부가 결정되지 않은 일과 일이 아닌 사안들의 목록이다. 때문에 일로서 실행 여부가 결정되었다면 Next 목록으로 이동시킨다. 이러한 단순한 기능이지만 각 폴더 및 목록 간의 이동이 자동적으로 이뤄지기 때문에 할 일 목록의 관리와 실행 여부의 판단을 직관적으로 운용할 수 있다. 하지만 Things는 다른 GTD 프로그램들과 달리 계층적 프로젝트 관리를 지원하지 않으며, 또한 각 목록 내에서 일의 순서도 일정에 따라 자동으로 정렬되지 않는다. 때문에 유일하게 계층적 관리를 할 수 있는 방법이 Area of Responsibility를 이용하여 범위 별로 프로젝트와 할 일을 구분하는 것이다. Things에서 일의 위임은 Address Book의 정보에 직접 위임할 일을 지정하고 관리하는 방법을 사용한다. PS. Things 2로 업그레이드되면서 클라우드 서비스나 새로운 Siri를 이용한 기능 등이 강화되었지만 여전히 계층적 디렉토리 기능을 기대한 입장에서는 아쉬움이 많다.

2008년 8월 30일 토요일

Things: 멀티 컨텍스트의 매력

CulturedCode의 Things는 아직 정식 버전이 출시되기 이전이지만, OS X 환경에서의 GTD 어플리케이션에서 가장 선두에 있는 프로그램으로 iGTD와 OmniFocus와 비교된다. Things를 사용하게 되면서 느낄 수 있는 가장 큰 특징은, Things가 명확하게 GTD 스타일을 따르지 않는 GTD 프로그램이라는 것이다. 우선 컨텍스트와 프로젝트 화면의 구분이 없다는 점에서 다른 프로그램들과 가장 큰 차이를 보여준다. 그리고 이러한 차이는 바로 Tag의 활용을 극대화하므로 써 극복하거나 혹은 유연하게 활용할 수 있도록 해 준다. 즉, Things는 컨텍스트가 고정된 조건으로 지정되지 않을 수도 있다는 점에서 특히 회사나 가정 혹은 개인 일정이 뒤섞여 사는 우리나라 사람들에게 잘 어울린다고 생각된다.

GTD의 컨텍스트는 행동의 수행될 수 있는 가장 주요한 조건 중의 하나이다. 우리가 중요하고 가치있는 행동이라는 실천할 수 없는 상황이라면, 고려 대상에서 제외되는 GTD의 특정은 하나의 행동이 여러 군데에서 실행 혹은 검토되어야 하는 경우가 많은 우리나라 사람들에게는 어느 하나만의 컨텍스트를 지정하는 것은 매우 어려운 문제로 생각된다-이것은 정도의 차이가 있겠지만 다른 나라의 경우도 마찬가지라고 생각된다. 이럴 때 Things는 하나의 행동에 요구되는 장소, 환경, 도구 그리고 대상을 하나의 이상으로 태그로 지정할 수 있다. 예를 들어 하나의 행동이 회사와 집에서 선택할 수 있는 경우이거나 혹은 두 위치 간의 연속적인 진행이 필요하다면, iGTD나 OmniFocus에서는 이러한 조건 중 가장 중요하고 모든 하부 컨텍스트를 포괄하는 상위 컨텍스트를 생성해야만 한다. 하지만 Things에서는 아래와 같이 태그 내에 또 다른 태그를 적용할수 있는 계층적 구조의 멀티 태크 기능을 이용하여, 예를 들어 각각의 장소를 컨텍스트로 설정하고 입력한 행동에 대하여 둘 이상의 태그를 멀티 컨텍스트로 지정할 수 있다.

이러한 멀티 태그는 컨텍스트 뿐만 아니라 행동의 중요도나 연관된 인물(아직 Things는 Address Book과는 연동되지 않기 때문에)등 필요한 모든 정보의 객체를 다룰 수 있기 때문에, GTD 프로그램에서 사용자가 느낄 수 있는 초기의 부자연스러움에 대한 극복이나 다양한 정보의 입력 기능으로 활용할 수 있다.

하지만 너무 많은 태그를 할당하게 되면 오히려 각 행동의 실천 여건에 검토가 주요한 조건이 되어 본의아니게 스트레스의 원인이 될 수 있다. GTD 프로그램의 선택에 있어 다양한 기능과 사용 편의성을 선택함에 있어 iGTD와 Things의 비교에서 Things를 쉽게 포기하지 못하는 이유가 바로 이러한 멀티 컨텍스트의 편리함 때문이다. 만일 이러한 멀티 태그로 인해 좀더 명확한 컨텍스트이 필요한 경우에는 Area (of Responsibility) 폴더를 이용하면 편리하다. 그러나 Things의 멀티 태그 기능의 유용성을 떠나 실질적으로 효과적인 GTD 라이프 구현을 위해 필요한 기능인가에 대한 판단은 결국 사용자의 몫이다. 즉, 멀티 태그 기능이 없어 제대로 된 GTD 스타일을 구현할 수 없다고하는 사람은 없을 것이라 본다.

2008년 8월 27일 수요일

GoalEnforcer

GoalEnforcer는 지금까지의 여러 플래닝 및 프로젝트 소프트웨어들과 같으면서도 다른 분위기를 제공하는 어플리케이션이다. 그리고 그 단순한 인터페이스 측면에서는 GTD 시스템에 적용할 때 매우 효과적이라고 볼 수도 있을 것 같다.

D97miRa.png

하나의 프로젝트를 지정하는 원을 생성하고 이를 수행하기 위해 행동이나 행동의 그룹의 원을 순차적으로 생성하여 프로젝트를 중심으로 배치한다. 그리고 각 원에는 시간, 진행 상황 등을 설정하여 운용할 수 있다. 각 항목의 진해 상황을 리스트나 그래프로 확인할 수도 있다. GoalEnforcer는 사용함에 있어 특별한 사항을 배울 필요 없을 만큼 간단하다.

2008년 8월 23일 토요일

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 시스템 운용에 대해서는 매우 많은 정보를 얻을 수 있다.

2008년 7월 30일 수요일

GTD 준비 단계

GTD는 이전까지의 자기 계발 기법이나 업무 관리 체계에서의 개념, 적용 방법 그리고 시스템에서 상당한 차이를 보여주고 있다. 무엇보다도 개별 일의 가치보다는 실행 가능 여부에 더 집중하는 방식이라는 점에서 사람 마다 이견이 있는 것 같다. 지금까지 우리는 대개 일에 대해 실행에 대한 현실적 가능성 보다 완수에 대한 의무감을 더 생각했다고 볼 수 있다. 업무나 일에 대한 실행은 당연한 전제로서 생각되었기 때문에 굳이 언급할 필요가 없었기도 했지만 사실은 실행에는 상당한 부담이 따르기도 한다. 특히 해야 함에도 불구하고 하기 싫은 일이나 어려운 일 그리고 귀찮은 일 등은 더욱 그러하다.

어떤 체계나 시스템을 일상의 관리 도구로 사용하고자 할 때 이를 위한 준비 단계는 대개 소홀한 편일 수 있다. 하지만 경험에 비춰 GTD는 다른 관리 체계 보다 더욱 준비가 필요하다고 생각하게 되었고, 그 완성도에 따라 시스템 운용의 성과가 크게 좌우될 수 있다고 본다. 실제 GTD에도 준비 단계가 언급되어 있기는 하지만, 많이 이들이 이러한 준비 단계를 당연한 것으로 보고 넘기는 경우가 많은 것 같다.

예전에는 GTD를 위한 준비를 도구를 마련하거나 마음을 다잡는 것까지 생각했지만 보다 단순하게 생각하면서 필요한 것에 집중하는 것이 효율적이라고 판단한다. 무엇보다도 GTD 운용을 위한 별도 공간을 마련하기 좋다. 물리적인 공간일 수도 있고 컴퓨터의 소프트웨어처럼 가상의 공간이어도 된다. 핵심은 가능한한 하나의 공간에 집중하여 GTD를 관리할 수 있도록 하는 것이다. 직장 등에서라면 대놓고 개인적인 영역을 구축하기가 힘들 수도 있지만 나름의 방법으로 관리 범위를 정하는 것이 필요하다. 그리고 팩스나 복사기 등의 공용 물품으로의 접근이 수월한 방향이나 방식을 선택하는 것도 좋다.

  1. 0. 컨텍스트

거창하게 GTD의 핵심 관리 요소인 컨텍스트를 준비의 첫 대상으로 올렸지만 다른 사안들에 비해 우선적으로 준비해 두는 것은 중요하게 생각한다. 물론 컨텍스트를 완벽한 구성을 준비할 필요는 없다. 이 과정에서 언급하고자 하는 것은 시스템으로 전환 전에 현재 자신의 업무 진행 현황에 대한 파악이 필요하기 때문이고, 그 가운데 업무 진행을 위한 조건들을 컨텍스트 목록으로 미치 작성해 두기를 바란다. 현재 업무가 주로 이뤄지는 장소, 공간 그리고 업무에 주로 사용되는 도구 및 장비에 목록을 작성한다. 그리고 함께 일하는 대상들과 그들과 협력하고 소통하는 방식에 따라 필요한 사항들도 정리해 둔다. 가능하면 시간적인 조건들도 염두에 두고 정리할 수 있도록 한다. 이때 작성한 목록의 각 대상들이 처음 시작하는 GTD의 컨텍스트로 활용할 수 있도록 한다. 주의할 점은 이미 제시되어 있는 GTD 가이드의 컨텍스트를 염두에 두지 말고 앞서 말한 바와 같이 현재 본인의 업무를 기준으로 작성하는 것이다.

1. 수집함

GTD 관리 체계가 시작되는 곳으로 사용자의 업무나 일 혹은 그와 관련한 모든 대상을 모으는 Collect 단계를 위한 물리적 혹은 가상의 박스이다. 실제로 존재하는 물품을 옮기기 어렵거나 불가능한 경우라면 해당 물품을 메모지에 적어 모을 수 있다. 가능하면 큰 박스를 이용하는 것이 좋다. 최초 수집 과정이 이후에도 상대적으로 필요한 수집 공간이 줄어 들게 된다. 하지만 물리적인 대상이 아닌 컴퓨터 내에 존재하는 파일이나 E-메일의 메시지 같은 것은 별도의 폴더나 어플리케이션 내의 수집 영역으로 옮기도록 한다. 실제로 컴퓨터 내에 쌓인 엄청난 수와 크기의 파일과 한번도 비워지지 않은 E-메일 메시지를 가능할 지 의문이 들 수도 있지만 한번은 수행해야 한다. E-메일의 경우 POP3나 IMAP 기능으로 메일 서버에 사본을 남겨 두지 않는 것도 좋은 방법이라 생각되면 파일의 경우라면 마찬가지로 복사본을 생성하지 않도록 한다.

2. 쓰레기통

수집 과정에서 상당한 양이 더 이상 쓸모 없거나 기능 수행에 문제가 있어 버려져야 할 것들이 있다. 개인적이며 일상의 제품이라면 이번 기회에 버려버리도록 한다. 단 개인적인 추억이나 취미 차원에 수집한 대상들은 별도로 구분한다. 업무 기준으로 구분하면서 이런 것들은 처분하고 나면 나중에 후회할 수 있다.

3. 분류 박스

수집 단계 이후에 필요한 GTD 작업용 분류 박스나 폴더도 미리 준비하도록 한다. 가능하다면 0. 컨텍스트 단계에서 업무 영역으로 구분한 내용으로 마련하도록 한다. 그리고 필요에 따라 참고 사항들을 저장하기 위한 별도 보관용 박스도 준비한다. 박스는 들어 가는 내용을 명확하게 지정할 수 있도록 라벨을 붙이도록 한다. 만일 분류를 미리 하지 않았다면 넉넉한 수량의 박스를 준비하여 혼란이 생기지 않다록 한다. 한글이나 영문 순서로 개별 박스를 준비하는 것도 좋지만 사무실의 책상 위안 책장 등에 놓일 것이라면 공간적인 제약이 있지 않을까 싶다. 박스 준비에서 주의할 점은 Process/Organize 단계에서 특정 항목의 박스가 넘쳐나는 경우에 대응할 수 있도록 한다. 또한 물리적인 박스들의 위치를 가능한 업무 행동 범위 내에 두도록 한다.

만일 전반적으로 종이 문서를 다루는 양이 많지 않다면 박스나 폴더 보다는 얇은 파일 폴더 등을 많이 준비하여 대응하는 방법도 좋다고 본다. 그리고 GTD의 또 다른 특징적 관리 방식은 Tickler 폴더를 구성하기 위해 1~31일 그리고 1월~12월로 구분된 43개의 파일 폴더를 책상이나 서랍에 마련해 둔다.

David Allen은 GTD에서 다뤄지는 많은 폴더에 손쉽게 이름을 붙이기 위한 레이블 프린터의 효용성을 매우 부각하고 있다. 솔직히 처음에는 그 필요성이 크게 느끼지 못했지만 시간이 갈수록 가장 효용성이 큰 도구가 되었다. 가격이 싼 제품은 폰트의 종류나 크기가 제한적이라는 한계가 있지만 효과는 충분하다고 본다. 간혹 컴퓨터와 연동되는 레이블 프린터를 준비하는 경우를 보는데 이런 경우에도 반드시 수동 입력도 가능한 제품을 선택할 수 있도록 한다.

4. 책상 위의 여러 도구 (데스크 툴)

앞서 레이블 프린터와 같이 책상 위에 놓일 필요한 도구들이다. 대부분 일상에서 사용하는 사무 용품이지만 특별히 스테플러 대신 사용할 클립이나 집게 등도 마련하는 것이 좋다. 그리고 필기구나 테이프 그리고 문서 사이에 끼워 넣을 메모용 포스트-잇 등도 준비하는 것이 좋다. 이러한 물품들은 사용 후 분실 등의 우려가 크기도 하고 이후 매번 필요한 경우마다 보이지 않는 것을 찾느라 고생하는 일이 없도록 별도의 보관함을 만들어 책상 위에 두도록 한다.

5. 플래너와 다이어리

GTD를 사용하면서도 굳이 FP와 같은 플래너나 몰스킨 등 여러 스타일의 다이어리를 사용하고자 하는 사람도 많을 것이다. David Allen의 GTD에서는 플래너나 다이어리 보다는 한장 씩 뜯어 수집함에 넣을 수 있는 작은 수첩, Note Taker 을 선호 한다.

6. PDA와 GTD 소프트웨어

지금은 사용빈도가 거의 없지만 스마트 보급이전 전자수첩이나 PDA 혹은 기기를 많이 사용했다. 이제는 스마트 폰이 이런 기기들의 모든 기능을 대신할 수 있기 때문에 특별히 따로 언급할 필요가 없지만 iPhone 출시 이전에는 상당한 제약이 있었다고 해도 과언이 아닐것이다. iPhone 출시 이전에는 iPod Touch가 그 역할을 대신해 주기도 했다.

그리고 GTD 전용 소프트웨어가 아닌 Outlook 등을 비롯한 PIM을 GTD 용도로 사용할 수도 있고, Google의 G-Mail이나 E-Mail 클라이언트를 이용하면 GTD 시스템을 활용하는 경우도 많다. 특정 도구나 방식이 GTD에서 선호되지는 않지만 가능한 하나의 어플리케이션에서 업무 대상들을 통합적으로 관리하거나 별도의 프로그램들이라면 연동 체계가 구축이 수월한 제품을 사용하는 것이 좋다.

GTD의 기본 개념

GTD의 개념을 설명하면서 프랭클린 플래너(이하 FP)의 예를 들게 되는 것은 일이나 업무의 계획 단계에서 상대적으로 대응되는 면이 많기 때문이기도 하고, 또한 무엇보다도 FP가 일상에서 많이 알려져 있기도 하기 때문이다. 서로의 장단점이 분명하다고 볼 때 우열을 가릴 필요는 없다. FP는 우리가 생각하는 일상의 업무 계획, 실행 그리고 완료의 단계를 밟아 진행되는 것에 비해, GTD는 상대적으로 절차적인 면에서 자유도가 높다고 볼 수 있다. 그리고 GTD는 보다 현실적이며 단기적인 관리 체계인 것에 반해 FP는 이상적이며 중장기적인 관리 체계로 볼 수 있다.

GTD 역시 일과 업무의 실행과 완료 지연으로 발생하는 스트레스를 해소하기 위한 관리 체계이다. 그리고 그 핵심은 현재를 기준으로 한다. 즉 앞으로 미래를 위해 지금 어떤 일을 우선적으로 해야 할 지를 고민하고 선택하는 것이 아니라 GTD 시스템에 의해 선택된 지금 할 수 있는 일을 하므로 써 전체적인 일과 업무의 실행 수준을 높이는 것이다. 이를 위해 현재 할 수 있는 일을 명확하게 선택되어 지는 시스템이 구성되고 관리되어져야 한다. GTD 시스템은 특정 도구나 방식에 제한되지 않는다는 점에서도 FP로 대표되는 여러 자기 계발 방식의 업무 관리 체계에 비해 효율적이다. 하지만 새롭게 GTD를 적용하기 위해서는 기존의 업무나 일의 처리 방식을 바꿔야 하고, 그 과정에서 많은 시행 착오를 겪을 수 밖에 없다.

1. 가치와 상황

GTD에서의 핵심은 계획한 일의 실행 가능성에 대한 관리 체계이다. 실행된 일은 계획된 특정 행동을 통해 진행되면 어떠한 식으로든 결과가 드러난다(완료되지 않은 결과 역시 일의 실행에 대한 결과이다). 조건이 충족되면 실행한다는 사실에 대한 논의는 필요치 않다. 실행할 수 없다면 수정 대상으로 처리한다.

일반적으로 일에 대한 가치를 부여한다고 할 때, 중요한 일, 덜 중요한 일, 중요하지 않은 일 혹은 해야만 하는 일, 안해도 되는 일 그리고 급한 일, 급하지 않은 일 등 다양한 표현으로 나타낼 수 있다. 그리고 가장 급하거나 해야만 하는 일에 우선적인 가치를 부여하여 일정을 짜고 시간표를 관리한다. 일에 부여된 가치 중심의 관리 체계에서는 단순히 급한 일보다는 중요한 일을 더 많이 하도록 관리하는 것에 중심을 두고 있다. 이런 일에 대한 실행은 의지로 극복되어야 한다. 하지만 실행 의지에 대한 관리 체계는 GTD에서 별도로 존재하지 않는다. 반면 FP로 대표되는 자기 계발 관리 체계에서는 가치로운 일을 수행할 의지는 무엇보다도 중요한 요소이다. 그럼에도 FP와 같은 가치 중심의 관리 시스템은 어떤 이유에서든 오랫 동안 호평을 받아 왔다. 문제는 가치가 절대적이지 않다는 것이다. 더욱이 가치가 스스로에게 솔직하지 않은 경우도 적지 않다.

FP 운용의 혼란 속에서 알게 된 GTD는 자기 계발이나 개인 생산성 개선에 대한 욕구를 효율적으로 처리할 수 있는 방안으로 생각되었다. 특히 위치와 같은 제약 조건에 기준으로 할 수 있는 일만 하는 방식은 일의 수행 가치 여부를 생각하는 방식에 비해 단순하면서도 신선했다. 물론 GTD에서도 일이나 행동에 대한 가치를 절대 부정하지는 않는다. 다만 일이란 일단 실행되어야 결과가 나타나므로 실행 가능성을 우선 관리하고 이를 통하여 현재 위치와 상황에서 할 수 있는 적절한 행동을 하게끔 알려 준다. 특히 회사 일을 항상 집에 들고 가는 우리네 직장인의 입장에서 본다면 GTD의 일 처리 방식은 새롭기도 하지만 혼란스러운 면도 있다.

2. 인식과 수집

사람이 가진 막강한 멀티태스킹 능력은 집이든 회사이든 상관없이 머리 속에 떠오른 대상을 우선적으로 처리하려 한다. 특히 완료하지 못한 일들은 머리 속을 떠나지 않고 남아 스트레스를 안겨주기만 한다. 원래 생각하기 싫은 일은 더 생각나기 마련이다. GTD는 이렇듯 마무리되지 않고 머리 속에 남겨진 일들을 언제라도 모두 수집함이라는 특별한 곳으로 무조건 집어 넣도록 한다. 이러한 조치 만으로도 실제한 마음은 상당히 안정될 수도 있다; 물론 그렇다고 일이나 고민거리가 해결되는 것은 아니다. 그 대상을 좀더 객관적으로 바라볼 수 있는 시각을 준다. 문제는 일이란 내 삶의 주변에서 끊임없이 생겨나고, 시스템을 통하여 관리하기 위한 대상으로 인식해야 한다.

3. 행동과 관리

필요한 상황에서 필요한 일을 제때 그리고 제대로 한다면 업무 스트레스는 상당히 줄어 들 것이다. 이를 위해 GTD에서는 수집함에서 꺼낸 일을 수행할 장소, 시간 및 조건 등에 따라 평가한다. 수집하는 것에 비해 평가 작업은 상당히 어렵고 시간이 요한다. 그리고 평가된 각 일을 행동 방식이나 조건에 따라 달력이나 수첩 혹은 Tickler 폴더 등으로 옮긴다. GTD 프로그램을 사용하게 된다면 이러한 과정이 수월해 질 수 있는 제품을 선택하거나 구성하는 것이 필요하다.

평가 단계를 지나 지정된 곳으로 옮겨진 일들은 상황이나 조건이 만족되어 GTD 시스템이 알려줄 때까지 우리 머릿 속에서는 잊어버리도록 한다. FP가 시간이 날 때마다 삶의 가치와 목표를 계속 상기시키기 위한 노력을 강조하는 것과는 큰 차이라고 본다. 중요한 것은 조건이 만족되어 행동하라고 알려 줄 때 우리는 일 자체를 명확하게 인식할 수 있어야 한다. 일의 표현이 모모하다면 실행은 물론 그 결과의 평가 조차 명확하지 않을 수 있다. 때문에 GTD 시스템에서 일이나 행동을 표현하는 방식이 매우 중요하다.

GTD 시스템은 다른 여러 자기계발시스템과 달리 정해진 도구나 프로그램을 지정하고 있지는 않다. 하지만 우리가 일을 적절하게 관리해 줄 수 있는 시스템을 구축할 수 있느냐에 따라 그 생산성은 크게 좌우된다.

2008년 7월 25일 금요일

다음 행동과 프로젝트

GTD를 접한 이후 가장 혼란스러워 개념 혹은 방식이 프로젝트 구성에 관한 것이었다. 쉽게 생각할 수도 있겠지만 일상에서 프로젝트라는 용어가 가지는 의미로 인한 GTD의 프로젝트에 대한 오해가 생길 수도 있다. 단순하게 보자면 GTD의 프로젝트는 같은 목표 달성을 위해 필요하고 계획한 업무 그리고 업무의 세부적 행동의 집합이다. 프로젝트의 이름은 일반적으로 생각하는 거창한 목표 달성이 될 수도 있으며 일상의 소소한 일이 되기도 한다. 필요에 따라 거창한 목표를 가진 프로젝트 아래에 수 많은 업무나 행동들이 모여 있을 수도 있고 보다 상세한 목표를 가진 여러 프로젝트로 나뉠 수도 있다. 당연히 프로젝트 안에 세부 프로젝트가 포함될 수도 있지만, 이러한 경우 세부 프로젝트의 목표는 최종 프로젝트가 가지는 목표에 비해 좀더 일상적일 수 있다. 다시 말해 세부 프로젝트는 완료 후에도 목표 달성이라는 의의를 찾기 힘들 수도 있다. 그러므로 개별 프로젝트들을 관리할 것인지 하나의 큰 프로젝트를 관리할 것인지가 중요한 문제가 될 수 있다.

그러므로 프로젝트의 이름 역시 업무나 일의 표현처럼 목표 달성을 명확하게 확인할 수 있도록 명명되어야 한다. 만일 명확하게 표현될 수 없다면 이러한 대상은 별도의 관리 그룹을 만들어야 한다. 프로젝트가 아닌 업무나 일의 집합은 프로젝트와 달리 시작과 끝의 기준이 없을 수 있다. 예로 ‘건강을 위해 운동하기’라는 프로젝트를 만들었다면 GTD에서는 이에 대한 시작과 끝 그리고 평가를 할 수 없다. 때문에 ‘올해 체중 10Kg 감량하기’처럼 구체적으로 표현되고 이를 위한 상세 행동들이 포함된다면 GTD의 프로젝트가 된다.

그렇다면 일상의 직장 등에서 다뤄지는-거창한-프로젝트는 GTD에서 어떻게 다루어 질 수 있는가? 답은 이런 프로젝트는 GTD에서 다뤄지지 말아야 한다는 것이다. GTD의 프로젝트는 딱히 정해진 기준은 없지만 크기와 시간에서 제한적이라고도 할 수 있다. 때문에 직장이나 단체에서의 프로젝트를 GTD 체계에서 다루기에는 범위나 변수가 너무 많다. 이러한 프로젝트들은 심하게는 시간 단위로 진척 상황을 확인해는 하는 경우도 적지 않으므로 GTD 체계로 대응하기에는 부족한 면이 크다. 실제로 이러한 프로젝트는 별도의 프로젝트 관리 프로그램이나 관리 팀에서 주도하는 것이 정상이다. 개인의 입장에서는 그 가운데 사용자에게 주어진 세부적인 업무를 자신의 GTD 시스템에서 관리할 수 있다.

GTD의 프로젝트가 주는 용어적 부담감으로 인해 프로젝트의 구성이 어렵게 느껴질 수 있다. 하지만 GTD는-우리가 익히 알고 있고 이야기하는-프로젝트 관리 도구가 아니다. 다른 더 좋은 표현이 있을 지는 모르겠지만 단지 하나의 목표를 위한 같은 수준의 업무 집합체로 이해해야 한다. 종종 GTD에서 10년 20년 후의 달성 목표를 프로젝트 이름으로 정하는 경우도 있지만 이것은 세부적인 업무들의 집함체라기 보다는 시각적으로 목표를 확인하는 수단 정도의 역할을 하는 수준이라고 생각하면 된다.

2008년 7월 24일 목요일

달력의 활용

달력(캘린더)은 오래도록 특정 날짜나 시간에 실행해야 하거나 마감해야 할 일들을 기록하고 이를 늘 확인할 수 있는 도구로 사용 되어 왔다. 그럼에 간혹 주요한(하지만 관심없는) 날을 잊는 경우도 적지는 않다. 달력을 사용하는 방식은 크게 두 가지로 나눠 볼 수 있다. 우선 중요한 사안이나 일정만 적어 놓고 필요 시 확인하는 경우와 다음으로 날짜와 시간을 포함한 모든 일정을 기록하여 정기적으로 확인하는 경우로 볼 수 있다.

달력은 GTD를 포함한 모든 업무 관리 체계를 기본 도구 임에 분명하다. 새해가 밝으면 우리는 기념일이나 생일 등을 새 달력에 옮겨 적는 일을 의식처럼 행하기도 한다. 하지만 달력은 그저 당일 날짜가 가지는 의미를 적는 것일 뿐이 해야 할 일에 대한 사안을 적기는 불편 한다. 대략 큰 맥락의 제목을 적는 정도로 활용할 수 밖에 없다. 실제 할 일들에 대한 고민은 그 날짜 주변으로 새로 고민하기도 한다. 이러한 공간적인 제약은 업무 및 일정 관리용 컴퓨터 소프트웨어로서 달력 기능을 사용하게 되면서 해결되었다고 본다.

Outlook이나 iCal을 사용하면 달력 화면에 특정 날짜에 해야 할 일은 명확하게 지정할 수 있다. 주소록 등과의 연동으로 함께 일을 처리해야 하는 경우에 대한 대응도 가능하게 된다. 처음에 이런 일정관리 소프트웨어를 사용하게 되면 시각적으로 불편하기도 하지만 이내 적응되면 특별한 문제가 되지는 않는다. 웹 기반의 서비스를 사용하면 일정 확인을 위한 공간적인 제약에서 벗어 날 수 있게 되었다.

gZsBKR5.jpg

그럼에도 사무실 책상 위에는 대부분 탁상용 달력이 놓여 있고 언제나 연말이 되면 관련 업체로부터 선물이 들어 온다. 컴퓨터 소프트웨어의 기능이 좋아지고 스마트 폰에서 언제나 일정 확인이 가능하지만 책상 위의 달력은 좀처럼 그 자리를 떠나지는 않을 것 같다. 정확하게 말할 수는 없지만 업무나 일정 관리를 떠나 잠시 눈을 돌려 달력에서 한 주의 남은 날을 계산하는 것으로 작은 위안을 받는 것 같다.

GTD에서 달력은 업무나 일의 실행을 관리하는 도구로 사용되지는 않는다. 업무 관리 소프트웨어에서는 업무 목록의 내용이 연동되어 출력되는 것이기 때문에 달력 기능의 고유 역할과는 구분한다. 하지만 특정 날짜를 상기해야 하는 사안이나 앞서 말한 기념일 등을 점검하는 역할에서는 다른 어떤 도구보다 효과적이라고 볼 수 있다. 즉 결혼기념일을 잊지 않는 것과 결혼기념일 선물을 준비하는 일은 동일한 목적을 위한 사안이지만 일과 일고 구분되지 않은 별개의 사안이다. 이와 같이 달력은 특정 날짜나 약속 등을 상기 시켜주는 보조 역할로는 효율적으로 사용될 수 있다. 그리고 Review 단계에서 다음 주나 향후 업무 계획에 대한 검토 과정에서 활용된다.

정리하자면 GTD 시스템의 운영에서 달력의 용도와 활용 범위를 명확하게 구분하는 것이 필요하다. 업무 실행과 관련한 내용은 달력을 이용하지 않도록 해야 하고, 세부 실행 사안이 없는 항목 등은 또한 달력을 이용하는 체계로 정립하는 것이 필요하다.

2008년 7월 21일 월요일

컨텍스트의 선택

이전 GTD의 컨텍스트 대한 간략한 포스팅이 있었다. 일이나 업무 대상에 대한 적절한 컨텍스트의 지정은 일에 대한 실행을 담보한다고 할 수 있다. 그러므로 사용자 자신의 상황에 최적화된 컨텍스트 성은 시스템 관리 차원에서도 매우 중요한 작업이다.

예로 '모레까지 재산세 납부하기’라는 납기 기한이 정해진 대상이 수집함으로부터 나온 경우 일반적으로 달력의 해당 날짜에 표시하거나 캘린더 소프트웨어에서 세금 납부와 같은 이름의 작업을 만들고 마감 날짜에 해당 날짜를 지정할 것이다. GTD 시스템에서 일로서 처리하기 위해 컨텍스트를 지정한다면 직접 은행까지 가는 경우라면 ‘은행' 혹은 ‘외출’ 등이 될 것이고, 온라인으로 납부를 한다면 ’인터넷' 등이 될 수 있을 것이다. 혹은 좋지 않은 경우라고 했지만 부득이 ‘돈’이 될 수도 있을 것이다.

당연히 같은 일이나 업무 범위의 대상에 대해 컨텍스트는 사용자의 사정이나 환경 그리고 스타일에 따라 다르게 지정될 것이다. 기본적으로 업무 처리 기준을 장소에 기준을 두는 경우도 있을 것이고 소요 시간을 기준으로 정하는 경우도 있을 것이다. 또는 작업 도구를 중심으로 구성하는 것도 나름 효율적 있을 수 있다. 하지만 컨텍스트 지정을 특정한 도구가 아닌 방식으로 지정하는 경우도 생각해 볼 수 있다. 예로 ‘홍길동에게 연락하여 내일 회의 주제 정하기’라고 했다면 컨텍스트로 ‘전화’를 지정하는 것이 일반적이지만 실행 환경에 따라 ‘전화’라는 컨텍스트를 의미가 없을 수도 있다. 즉, 회사 내에서 다른 곳에 있는 홍길동과 연결되어야 한다면 ‘전화’ 이외에 여러 방식을 사용할 수도 있을 것이다. 세부적 전화라고 보면 휴대폰일 수도 있고 유선 전화일 수도 있으며 바쁘지 않다면 E-메일이나 팩스를 사용할 수도 있을 것이다. 이런 경우라면 ‘홍길동’이라는 상대방의 부재 여부가 더 중요한 요소일 수도 있고 그렇지 않다면 연락 방식에서 좀 더 큰 범위에서 ‘연결’ 등과 같은 컨텍스트를 지정할 수도 있다.

만일 컨텍스트의 수가 일정 한계를 넘게 된다면 계층화된 구조로 관리하는 것도 하나의 방법일 수 있다. 계층화를 이용하는 컨텍스트의 관리 방법의 효용성은 두 개 이상의 컨텍스트를 사용하는 방법으로도 활용이 가능하다는 점이지만, 컨텍스트의 관리가 복잡해 질 수도 있다. 처음 GTD를 접하는 경우라면 다음과 같은 컨텍스트 구성을 참고할 수 있을 것이다.

1. 위치 기반 컨텍스트

특정 위치를 컨텍스트로 설정하는 경우는 단순하면서도 해당 위치에서만 수행 될 수 있거나 수행 되어야만 하는 일에 대해 지정하는 경우로 볼 수 있다. 예로 집, 회사, 학교, 그 외 정기적 방문이 이뤄지는 곳 등의 위치에 제한을 받는 일에 적용된다. 주기적으로 방문하는 서점이나 도서관 혹은 여러 기관 및 회사 들을 설정해 두고 있다. 하지만 회사의 업무를 꼭 회사에서 집의 일의 꼭 집에서만 할 수 있는 것은 아니기 때문에 너무 단순하게 위치 컨텍스트를 지정하면 컨텍스트의 절대적 제약 조건이 약화된다는 점을 염두에 둘 필요가 있다. 마찬가지로 직장에서 해야 할 일에 대해 모두 직장을 컨텍스트로 지정한다면 컨텍스트 자체가 큰 의미가 없다고 볼 수 있다. GTD 소트프트웨어를 컴퓨터나 스마트 폰을 이용하는 경우 해당 위치에 도착하게 되면 수행 가능 업무들을 보여 주는 기능을 이용할 수도 있다.

2. 도구 기반 컨텍스트

일의 실행을 위한 필수적인 도구를 컨텍스트로 지정하는 것도 가장 합리적인 선택이라고 볼 수 있다. 일상의 주변에는 E-메일, 전화, 컴퓨터, 팩스, 온-라인(네트워크 연결), 차량 등 수 없이 많은 도구들이 있다. 단 도구를 컨텍스트로 지정할 경우에는 여러 도구 중 핵심적인 대상을 선택하거나 주변이 늘 있는 일상적인 도구는 제외하는 것이 좋다. 3. 시간/날짜 기반 컨텍스트

개인적이든 업무적이든 일상의 많은 일들이 지정된 시작 혹은 마간 날짜 그리고 수행에 소요되는 시간 등이 정해져 있을 수 있다. 그리고 다른 조건보다 이러한 시간 제약이 더 주요한 요소로 작용할 수 잇다. 하지만 특정 날짜와 관련된 항목은 GTD에서 Tickler 폴더를 사용하거나 달력 등을 이용하기 때문에 별도의 컨텍스트로 관리할 필요가 없을 수도 있다. 반면 언제 어디서라도 할 수 있는 일이지만 정해진 시간이 확보되어야 만 가능한 경우라면 그 시간의 확보 여부가 컨텍스트로 지정될 수 있다.

4. 위임 기반 컨텍스트

일을 직접 수행하지 못하거나 하는 경우 타인에게 위임할 수도 있으며, 부하 직원 등에게 업무 지시를 한 경우를 별도로 관리하기 위한 컨텍스트를 사용할 수도 있다. 또한 대외적인 여건이나 주변 환경의 변화에 따라 계획하고 있는 일들에 대해서도 지정할 수 있는 컨텍스트로 볼 수 있다. 하지만 이들 컨텍스트는 사용자의 직접적 관리 영역에서 벗어 날 수 있기 때문에 별도 관리해야 하는 사안이다.

5. 가치(역할) 기반 컨텍스트

GTD 기준에 적합하지 않은 컨텍스트일 수 있지만 세상에서의 삶에서 일에 어떤 식으로든 가치나 의미가 부여되는 경우가 많으며, 또한 그러한 기준이 다른 모든 조건에 우선할 수도 있다. 그리고 그러한 경우가 상대적으로 빈번한 경우라면 충분히 컨텍스트로 관리할 수 있다고 본다. 하지만 아들이나 과장 등과 같은 역할 컨텍스트가 미치는 범위를 명확하게 규정하기 힘들기 때문에 주의해서 사용해야 한다.

입력 도구로서 휴대폰 ?

현재 사용하고 있는 맥북 화이트가 이전 iBook G3에 비해 많이 가벼워 졌음에도 불구하고 시간이 지날 수록 상당한 무게감을 느낀다. 아직 랩탑이 불편하기도 하고 무선 인터넷이 안되는 곳도 많아 활용성이 떨어지기도 한다. 그리고 PDA나 아이폰 등의 스마트 폰을 아직 사용하지 않고 있는 입장에서, 유일한 개인용 디지털(?) 장비라고는 휴대폰 뿐이다. 아이팟 나노가 있긴 하지만... 이제 곧 처분하게 될 구형 휴대폰을 이용하여 과연 GTD 운용에 활용할 수 있을까?

  1. 입력도구로서 문자 메시지를 작성하여 나의 E-메일 주소로 전송한다. 내가 사용했던 Pantech KT-1500에서는 저장된 문장을 제목으로 지정할 수 없기 때문에 일일이 제목을 입력해야만 했다. 덕분에 Mail.App의 Inbox에서 "제목없음”으로 지정된 메일을 MailTags의 노트/제목 변환 기능을 이용하여 원하는 제목으로 변경할 수 있었다.
  2. 또 다른 방법으로 생각한 것이 메일 제목으로 컨텍스트를 지정하여 발송하는 방법을 쓰기도 했다. 대체로 컨텍스트가 짧은 글자로 지정되었기 때문에 나름 간편한 방법이기도 했다. 혹은 알파벳을 이용하여 해당 컨텍스트로 인식되도록 Mail.app의 스마트 폴더를 구성한 후 Inbox에서 메시지를 확인할 수 있었다.

언급했듯 아이폰을 비롯한 다음 세대의 휴대폰이 등장했기 때문에 입력도구로서 이러한 전화기의 역할이 어떻게 변할 지 매우 궁금하기도 하고, GTD 도구로서 단순한 입력도구를 넘어 보다 확장된 기기로 활용될 수 있을 지도 기대해 본다.

2008년 7월 20일 일요일

iGTD

사실 이 블로그의 시작에 iGTD가 있었다. 폴란드 출신의 JAVA 프로그래머인 Bartek Bargiel가 개발한 iGTD는 Mac OS X 환경에서의 GTD를 구현한 시스템으로 기능적으로나 활용성 면에서 가장 우수한 소프트웨어라고 생각된다. 이는 나 뿐만 아니라 다른 여러 웹 사이트들에서의 평가도 다르지 않았다.

OmniFocus나 Things 등이 정식으로 등장하기 전부터 iGTD는 GTD 시스템로서 필요한 기능을 충분히 제공하고 있었고, 사람들은 iGTD Pro와 iGTD 2와 같은 다음 버전에 큰 기대를 하고 있었다. 하지만 불행히도 개발자의 사정으로 iGTD 2의 알파 버전이 공개된 이후 약 1년 가까이 업데이트나 개정이 없는 상태였다. 그리고 2009년 가을 예상치(?) 못하게 Bartek은 Things의 개발사인 CulturedCode에 합류했다. 덕분에 Things에 대한 기대를 한층 더 높아졌다. 그렇다고 Things의 인터페이스 구성으로 볼 때 iGTD처럼 될리는 만무하니 그가 어떤 역활을 할 지는 모르겠다.

OmniFocus나 Things에 비해 iGTD는 다양한 기능을 제공하는 것이 가장 큰 차이였다. 물론 그 개별적인 기능의 필요성이나 효용성에 대해서는 사람들마다 평가가 다르겠지만, 웹 사이트 주소, E-Mail은 물론 파일 정보 등을 InBox에 저장할 수 있는 Quick Add 기능과 무엇보다도 계층적 컨텍스트 및 프로젝트 구조를 제공하므로 써 이미 이러한 환경에 익숙한 사용자에게 편의성을 주고 있다. 그리고 인터페이스가 화려하지 못해서 그런 것인지 처리 속도도 단연 빠르다. 그리고 개인적으로 큰 효과를 보지 못하고 있지만 많은 Mac OS X 사용자들이 사용하는 QuickSilver와의 연동 역시 가장 큰 장점으로 꼽혔다. 다른 GTD 소프트웨어에서는 지원이 미흡한 iCal 등과의 동기화등 다른 어플리케이션과의 연동 기능도 매력적이다. 그럼에도 iGTD는 무료로 공개되었다는 점에서 비교 불가라고 보겠다. iGTD의 인터페이스가 복잡하고 화면 구성 등에서는 불편한 점이 있지만 그 어떤 불만도 앞서의 장점들에 묻히기에 충분하다.

하지만 이후 업데이트나 에러 수정이 더뎌지고 특히 Mac OS X 업데이트가 계속되면서 운용이 불안정하게 되었다. 그리고 GTD 시스템 확산에 따른 OmniFocus나 Things의 등장으로 비록 돈이 들기는 하겠지만 iGTD를 대신할 다른 프로그램이 생겼다고 볼 때 iGTD가 더 이상의 GTD 소프트웨어로서 계속 사용되기는 힘들 것 같다.

GTD 컨텍스트의 이해

GTD를 시작한지 꽤 시간이 지났지만 계속 고민스러운 점이 시스템에서 규정된 컨텍스트들이 실제 일이나 업무의 실행을 결정하는 요소로서 역할을 하고 있는 가에 대한 것이다. GTD에서 컨텍스트는 일의 시작을 전제하는-절대적일 수 있는-제약 조건이다. 하지만 실제로는 컨텍스트가 충족 되었음에도 일이 시작되지 않거나 시작되지 못하는 경우를 많이 겪게 된다. 컨텍스트가 제대로 지정되지 있지 못한 경우가 아니라면 실행에 대한 필요성 혹은 결과에 대한 절실함이 부족해서 가 아닌가 싶기도 하다.

GTD를 처음 접하는 경우, 컨텍스트는 상당히 흥미롭고 매력적으로 다가온다. 지금까지 계획했던 일이 제대로 이루지 못했다면 그 원인에 대해 생각해 보았을 것이다. 아마도 뭔가가 충족되지 않았기 때문에 실행하지 못했거나 혹은 할 수 없었다고 생각된다. 그런 이유가 아니라면 대개 스스로의 게으름을 자책하게 된다. 때문에 일의 실행을 위한 전제 조건으로 설정된 컨텍스트는 지금까지의 많은 문제를 해결해 줄 수 있는 궁극의 해결책처럼 느껴질 수 있다. 일의 실행을 위한 전제 조건이 충족 되었는데 일이 실행되지 못한 이유는 없지 않은가.

GTD가 이전까지의 업무 관리 체계와 구별되는 가장 큰 특징의 하나는 일의 실행을 위한 전제 조건을 설정한다는 점이다. 대부분의 관리 시스템은 설정된 목표와 이를 달성하기 위한 시간과 목표 배분으로 구성된다. 반면 GTD는 그러한 구성에 상관없이 현재 할 수 있는 일인가에 집중한다. 그리고 그 실행 가능성을 판단하는 절대적 조건으로 컨텍스트를 지정하고, 컨텍스트가 충족되는 일은 실행되는 것을 기본 원칙으로 잡고 있다. 그러므로 컨텍스트가 충족 되었음에도 일의 실행에 문제가 있다면 컨텍스트의 지정이 잘못되었거나 일 자체가 실행될 수 없는 상황으로 잘못된 규정된 경우 뿐이다.

일반적으로 일의 실행 조건은 시간적(시작 시간, 날짜 그리고 소요 시간 등), 공간적(장소 등 물리적 위치), 물리적(도구, 시설, 환경 등) 그리고 인적(위임, 관리 등) 요소들이다. 이들은 스스로 관리할 수 있는 요소들과 관리 범위 밖의 요소들고 구분될 수 있다. 나의 현재 위치가 회사라면 집에서 할 수 있는 일들에 대해서는 실행이 불가능하며, 이들 일의 실행에 대해 생각하는 것은 결과적으로 의미없는 일이라는 것이다. 그러므로 일의 실행을 위한 조건 가운데 절대적 영향을 미치는 조건을 선택하여 컨텍스트로 지정할 수 있다. 일이나 업무의 실행을 세부적으로 관리하고자 한다면 행동 범위 자체를 최소 단위로 구분하고 컨텍스트 역시 세분화하여 지정할 수 있다. 주의해야 할 점은 예로 시간(빈 시간), 비용(돈), 감정(하고 싶을 때) 등의 요소를 컨텍스트로 지정하는 것에 대해서 보다 심각하게 고민할 필요도 있다. 컨텍스트 항목 자체도 안정성을 유지할 수 있어야 한다. 시간을 정확하게 분이나 시간 단위로 지정할 수 있는 것이 좋으며 비용의 경우를 이를 확보하기 위해 별도의 업무로 분리하는 것이 좋다. 또한 감정 등은 그 판단이 적용되는 경우마다 불명확하다는 점에서 지양하는 것이 좋다.

그러나 일상의 삶에서 하나의 일이나 업무가 어느 하나의 특정 조건 만으로 실행 여건이 충족되는 경우가 그렇지 않은 경우보다 많다고 할 수는 없다. 하나의 업무에 대해 둘 이상 조건의 충족이 전제되어야 할 수도 있다. 이런 점에서 컨텍스트에 대한 매력은 GTD 시스템의 적용 후 적절한 컨텍스트에 대한 선택의 문제로 이어질 수 있다. 지정한 컨텍스트가 적절한 것인지, 두 컨텍스트 후보 간 어느 쪽이 더 절대적인지, 그리고 반드시 두 개 이상의 조건이 모두 충족되어야 하는 경우처럼 단순한 선택의 문제가 아님을 확인하게 된다. 실제 GTD에 부정적 시각을 가진 시각에서 가장 큰 문제로 지적하고 있는 부분도 이 점인데, 하지만 GTD에서 시스템 구조적으로 이 문제에 명확하게 대응할 수 있는 방법은 없다. 물론 다양한 부가 조치로서 해결할 수 있는 방안도 있겠지만 단일 컨텍스트 지정이라는 기본 전제의 한계라는 점은 분명하다.

컨텍스트에 대한 또 다른 문제는 컨텍스트는 오직 실행을 위한 전제 조건이며 진행 내용과 완료에 대해서는 관여하지 않는다는 것이다. 즉, GTD 시스템 자체가 계획의 완수라는 목표 달성을 직접적으로 지원하지 않는다. 때문에 컨텍스트가 충족되어 일을 실행한다고 하더라도 이후의 문제는 GTD 시스템과는 무관하게 각자의 몫으로 남게 된다. 그리고 일의 실행 여부와 완료 여부는 Review 단계에서 원인 파악과 후속 조치 등으로 검토하게 된다. 심하게 표현하자면 무책임인 시스템이라고 볼 수 있다. 다시 말해 GTD 시스템은 목표 달성을 위해 채근하지 않으며 단지 계획한 바에 따라 지금 시간과 장소에서 할 수 있는 일을 확인시켜 주고, 이후의 실행 여부 문제는 별도로 관리한다는 것이다. 이로 인해 GTD 사용자들이 그 효용성에 대해 오해를 하게 할 수도 있다.

결론적으로 GTD는 사용자의 실행 의지를 요구하지도 부흥 시키지도 않는다는 점이다. 물론 장기 계획을 위한 과정에서는 전체적이고 넓은 시각에서 삶을 생각하면서 계획하도록 하지만 세부적인 단계에서의 실행 여부는 기본 전제로서 조차 다루지 않는다. 때문에 GTD를 적용한다고 하더라도 지금까지 다른 관리 체계에서 문제가 해결될 것으로 기대해서는 안된다.

다시 처음의 고민으로 돌아가서, 단순한 일이든 복잡한 이들이든 부분적으로 그리고 특정 시점에는 하나의 일에 대한 실행 만이 가능하다고 볼 때, 적절한 컨텍스트의 지정은 GTD 시스템의 구축과 운용의 신뢰 기반이라고 할 수 있다. 그러므로 시스템의 컨텍스트 구조에 대해 지속적으로 현실을 반응할 수 있도록 검토하는 기회를 가질 수 있도록 해야 한다.

IhMlI4d.jpg

- 컨텍스트가 충족 되었음에도 일이 제대로 실행되지 않고 있다면.. 나의 GTD 시스템이 뭔가가 잘못된 것이다.

결국 각자의 현실에 맞는 최적 구조와 구성 컨텍스트를 갖추는 것은 GTD 지속의 중요한 기반이라고 할 수 있다. 일반적으로 컨텍스트를 구성할 때 GTD 관련 책자나 사이트의 내용을 참고하여 구성할 수도 있지만, 가능한한 다양한 환경에 대응할 수 있는 세부적인 항목으로 구성하는 것이 좋다. 그리고 정기적으로 Review 단계에서 컨텍스트 간의 관계를 검토하여 정리하는 시간을 가지도록 한다. 시스템을 깔끔하게 관리한다는 생각으로 컨텍스트를 최소화하게 되면 앞서 전제한 일의 실행 조건으로 제대로 인식하지 못하거나 엉뚱한 관계 구성이 될 수 있다. 다시 강조하지만 컨텍스트 충족 여부에 따라 일의 정상적 실행에 오류가 발생하는 것은 GTD에서 가장 경계해야 할 부분이다.

2008년 7월 19일 토요일

GTD 블로그 리부트

개인적으로 GTD를 접하기 이전부터-무슨 이유에서인지 몰라도-난 시간 관리, 일정 관리 그리고 프로젝트 관리 등과 같은 일상적 업무 관리 체계에 관심이 많았고, 이를 생활에 적용하고자 나름 애를 썼다. 학창 시절이나 직장의 일상에서 언제나 관리되지 못한 일에 허둥대다 보니, 이를 극복하기 위해 무언가 외부적 도구의 도움이 절실하다고 생각하지 않았나 싶다. 물론 컴퓨터나 기타 디지털 기기에 대한 접근성이 오늘날과 같은 시절은 아니었다.

그러다보니 컴퓨터를 사용하게 되면서 소프트웨어 기반의 업무 관리에 한참 몰두하지 않을 수 없었다. 그러는 과정에서 자연스럽게-누구가 그렇듯이-다이어리와 플래너 등의 또 다른 형태의 관리 도구도 접하게 되었다. 당연한 수순인지도 모르겠지만 지금도 최종 보스라고 할 수 있는 프랭클린 플래너(이하 FP)를 알고 나서 이를 이해하고 실천해 보기 위해 많은 시간과 정열을 쏟았다. 사실 그때나 지금이나 내게 FP는 적응하기 쉽지 않은 구조와 절차의 시스템이었지만 그래도 제법 몇번에 걸쳐 적응하기 위해 노력했다. 물론 결과는 언제나 만족스럽지 못했다.

웹 페이지나 블로그 등에 소개된 FP를 이용한 업무 성과에 관한 내용이 적지 않은 것을 보면 나름의 효용성이 충분한 것은 분명하지만 내겐 유독 어려웠다. 마치 컴퓨터 프로그램으로 PhotoShop 같았다. 난 PhotoShop의 기능이 정말 유용할 것이라 생각해서 최소한의 기본 기능이라고 배워보려고 수차례 시도했지만 모두 실패했다. 적성에 안맞는 것인지 그렇지 않으면 그런 식의 처리 방식이나 구조를 제대로 이해하지 못한 탓인지 알 수가 없다.

61CdkXU.png

내가 제대로 된 업무 관리 프로그램으로서 사용해 본 것은 8-비트 Apple II에서 구동 되었던 Desk Calendar II 프로그램이다. 아직도 그 느낌은 여전히 생생하지만, 몇번의 시도에도 한국 실정에서 사용하기에 무리였다. 그럼에도 이러한 프로그램들에 본격적인 관심을 가질 수 있도록 만든 계기가 아니었나 싶다.

앞서 언급한 바와 같이 일상 업무 관리를 방안으로 FP만한 것이 없었던 시절이라 기회가 있을 때마다 FP에 관심을 가지기는 했지만, 어느 순간부터 인생에서 추구하는 목적과 가치가 달라지면서 지금까지의 일상적인 업무 관리에 대한 의문을 가지게 되었다. FP를 통해 나름 성공한 일화의 현실성에 의구심이 들기도 했다. 성공한 입장에서는 돌이켜 볼 수 있는 모든 것이 자신의 노력 덕분이니.

비용 역시 만만치 않았다. 물론 그 정도 비용은 인생 성공을 위한 작은 투자라고 볼 수 있지만, 왠지 비용과 노력 대비 얻는 성과는 거의 없었을 뿐더러, 혼란스럽고 자괴감이 들기까지 했다. 돌이켜보면 머리 속이 복잡하고 할 일이 산더미 같이 쌓여 정리되지 않은 시점에서 그 해결 방안의 하나로 계속 FP으로 해결하고자 했던 같다.

NAXggE7.jpg

앞으로 무수히 다루게 되겠지만-FP 못지 않게 업무 관리 시스템으로서-항상 마음 후보로 거론되었던 대상은 Microsoft Outlook(이하 OL)이었다. PC 환경이 Windows 운영체제 기반으로 전환된 이후 이런 종류의 프로그램이 상당 했지만, 초기 Windows 3.X 환경에서 Schedule+에서 시작하여 OL까지 Microsoft의 제품들에 관심이 갔다.

물론 현실적으로 OL은 직장에서 업무 용도로 사용하지 않을 수 없는 경우가 대부분이다. 하지만 OL 역시 FP는 다른-기능의 풍족함에도 불구하고-아쉬움을 느끼게 했다. 어쩌면 풍요 속의 빈곤이라는 표현이 적절하지 않을까 싶다. 기능의 부족함이 아니라 너무 많은 기능들이 자연스럽게 연동되지 못하는 느낌이었고, 특히 업데이트가 될 수록 점점 무거워졌다. 비용의 부담을 무릅쓰고 경쟁 제품이었던 Lotus Organizer 혹은 빈약하지만 가벼운-Macintosh에서 사용하기 위한-Claris Organizer 등도 사용해 보았지만 OL의 문제를 해소할 만한 주역이 되지는 못했다.

그런 어느 날, iGTD에 대한 정보를 우연히 접하게 되고 이후 왠지 모르게 GTD에 대해 급관심을 가지게 되었다. 확실히 iGTD는 그전까지 보아 온 업무 관리 프로그램과는 전혀 다른 느낌이었다. 이 일로 구형 iBook G3/600을 신형 MacBook White 2008로 바꾸게 되었다. 이후 David Allen의 GTD를 비롯한 여러 서적 그리고 웹 사이트의 정보를 보면서 GTD의 개념과 그 효용성을 파악할 수 있게 되었다. 돌이켜 볼 때 iGTD에 받은 그 감흥을 대체하기는 힘들지 않을까 싶다.

사람마다 GTD를 선택하게 된 이유는 다양하겠지만, 내게 있어서는 무엇보다도 삶을 보다 자유롭게 그리고 개인적인 측면에서는 바라볼 수 있는 관점을 적용할 수 있는 시스템이라 판단했기 때문이다. 이러한 생각에서 다시 새롭게 블로그 포스팅을 시작하게 되었다.