OmniFocus - Ticklers

GTD 시스템이 다른 자기계발 시스템과 다른 기능적인 사항은 일의 실행 순서를 정함에 있어 가치보다는 실행 가능성을 우선한다는 점이다. 그리고 일의 실질적 실행 일자가 정해지거나 사용자가 설정한 일자를 GTD 시스템이 관리할 수 있게 됨에 따라 우리는 현재 할 수 없거나 할 필요가 없는 일에 대한 생각을 머릿 속에서 지워 버릴 수 있게 된다. GTD 시스템은 Tickler는 이상과 같은 수행하기 위한 단순하면서도 효율적인 방법의 하나로 사용된다.

Tickler는 일의 마감일 혹은 마감 전 준비를 시작해야 하는 날을 지정하고 해당 날짜가 되기 전까지는 시스템에 나타나지 않다가, 지정한 날짜 조건이 부합되는 날에 시스템에 등장하여 사용자가 화인할 수 있도록 해 준다. 일반적인 방법으로 사용하는 달력과 비교한다면, 많은 일이나 정보가 기록되면 점점 달력을 보면서 일의 상세 내용을 확인하기가 쉽지 않게 되고, 달력에 적히는 항목들에 대한 기준을 따로 마련해야 하는 일도 생기기 된다.

OmniFocus와 같은 컴퓨터 기반 GTD 프로그램이 아닌 실제 물리적인 환경에서는 Tickler 폴더로 구성될 수 있다. Tickler 폴더에는 일, 월 별로 구분된 43 개의 파일 폴더를 구비한다. 1 ~ 13일 그리고 1 ~ 12 개 월로 구분된 각 Tickler 폴더에는 해당 일자 혹은 월에 해야 할 일에 대한 사항과 관련 서류들이 저장된다. 사용자는 매일 당일에 해당되는 Tickler 폴더의 내용을 확인함에 따라 잊지 않고 계획한 일을 실행할 수 있도록 해 준다. GTD 시스템을 구성할 때 사용자들이 가장 필요하다고 생각되는 도구가 Tickler 폴더인데, 사실 개인적으로는 몇 년간의 사용 경험에 비춰 여간 부지런하지 않고서는 기대한 성과를 얻기가 쉽지 않기 때문에 처해진 상황에 따라 무작성 사용한다면 그 유용성의 효과를 완전하게 기대하기 힘들다. 이러한 문제를 개선하기 위해서는 Tickler 폴더 자체를 가능한한 눈에 잘 뛰면서 쉽게 손이 갈 수 있는 장소와 위치에 배치하는 것이 가장 중요하다.

OmniFocus와 Things를 비교할 때 OmniFocus가 상대적으로 복잡하고 어렵다고 하지만, 반면 OmniFocus의 여러 기능을 제대로 사용하는 경우도 많지 않다고 생각된다. 그리고 그 중의 하나가 Tickler 기능이기도 하다. OmniFocus에서의 Tickler를 사용하기 위해서는 그 대상이 되는 ‘미래(오늘 포함)의 일이 시작되는 날짜가 지정하는 것으로 시작한다. 즉, OmniFocus의 Action 혹은 Project에 대하여 Start date와 Flag를 지정한다. 그러면 일반적인 경우에는 나타나지 않다가 지정된 일자에 할 일이 화면에 나타나게 된다. OmniFocus를 사용하면서도 하루에도 몇 번이고 Due 화면이나 Project 화면을 보면서 앞으로의 일정을 확인하고 있다면 아직 제대로 Tickler 기능을 활용하지 못하고 있는 것이다.

아직 대형 문구점에서도 David Allen의 GTD System Folders와 딱 맞는 폴더 제품을 찾지 못했다. 때문에 일반적으로 사용하는 황색 폴더를 이용하여 직접(고생해서) 만들어 사용했다. 이후에는 Sysmax의 Handy Box 폴더를 사용하기도 했다.

PS. OS X 10.8 Mountain Lion의 캘린더와 OmniFocus의 Sync 기능이 해제됨에 따라 Tickler 기능을 더 이상 두 시스템 간에 연동해서 사용할 수는 없다.

GTD의 컨텍스트에 대한 착각

참고는 참고일 뿐, 컨텍스트는 자신의 것이다.

돌이켜 볼 때 GTD 시스템를 나름(!) 복잡한 삶에 적용하고자 나 역시 별의별 짓을 다했다고 생각한다. GTD 시스템의 현실적 운용에서는 항상 많은 것들이 의문스러웠다. 예로 컨텍스트라는 필요 조건이 만족되었고 일의 실행에 남은 것은 오직 나의 실천 의지 만이 있을 뿐이었다. 하지만 컨텍스트 조건의 충족 여부와 상관없이 일은 제대로도 원활하게도 실행되지 않았고 여전히 GTD 시스템이 아닌 머릿 속에 남아 있는 경우를 겪게 되었다. 이에 대하여 근본적인 원인과 해결 방안을 찾게되면서 나의 GTD 시스템에서의 컨텍스트가 너무나 형식적이지 않은 가에 대한 의문이 들었다. 이전 컨텍스트의 선택이라는 포스팅에서와 같이 나의 컨텍스트로 일반적인 구성에게 크게 벗어나 있지는 않다. 덕분에 생각해보면 일의 컨텍스트 지정을 이미 규정한 몇 가지 컨텍스트 구조에 맞추려고 애를 쓰는 것 같았다. 사실 그렇게 하는 것이 더 효율적이라고 생각했다.

그렇다면 현재의 컨텍스트 구조가 현실적이지 못하다 것인가? 물론 이러한 문제의 답이 멀티 컨텍스트는 분명 아니다. 멀티 컨텍스트를 사용하지 않는다면 가장 중요한 핵심 사안을 컨텍스트로 지정하게 된다. 이것은 핵심 컨텍스트가 되지 못한 많은 다른 부수적인 조건들의 충족을 전제로 한다. 하지만 GTD 시스템에서 컨텍스트가 지정된 일에 대하여 그 지정된 항목에만 집중하게 되는 경우가 많았다. 덕분에 컨텍스트의 충족에도 불구하고 일의 진척을 더디거나 시작도 못하는 경우도 발생했다.

이에 대한 나의 해결책은 크게 몇 가지로 구분하였다. 우선 가장 일반적인 방법으로써 하나의 일을 가능한한 최소 단위로 구분하여 컨텍스트를 지정하는 것이었다. 물론 이러한 방법은 일을 세부화하는 과정에서 너무 비효율적인 구분까지 진행되기고 했다. 분명 단순하고 쉬우면서도 어렵고 복잡한 일이기도 하다. 또 다른 방법은 프로젝트로 운용하는 것이다. 내부적인 방법이야 동일하다고 보겠지만 하나의 프로젝트로 만들고 컨텍스트 조건으로 세부적인 일을 구분하는 것이었다. 시각을 달리하여 컨텍스트를 구체적으로 세분화하는 방법도 있다. GTD 시스템의 운용을 시작하게 될 때, 컨텍스트의 구성과 구조를 너무 정형화하는 실수를 저지르기도 한다. 즉, 이미 GTD 시스템을 사용하면서 이에 대한 소개를 한 웹 사이트나 블로그 등의 컨텍스트 구조를 참고가 아닌 그대로 자신의 시스템에 적용하려고 하는 경우가 있다. 여기에서 컨텍스트에 대한 우리의 착각이 시작된다. 컨텍스트란 자신의 업무 범위에 따라 스스로 설정하는 것이 핵심 임에도 레퍼런스에 집중하므로 써 컨텍스트에 자신의 시스템이나 업무 스타일을 맞추려고 하는 일을 벌이게 된다. 더 나아가 컨텍스트를 장식하려는 경우도 있다. 일의 수행에 솔직한 전제조건이 아니라 우아한(?) 구성에 억지로 맞추려고 하는 것이다. 마치 부모가 읽을 것을 아는 어린 아이의 일기처럼.

결국 GTD 시스템을 접하게 되면 컨텍스트라는 조건이 마치 일을 완료시켜주는 사안인 것처럼 착각하는 경우가 많다는 것이다. 마치 컨텍스트가 GTD 시스템 내에서 만들어져 있는 것처럼 생각하는 경우로 볼 수 있다. 자신을 삶을 투영하는 컨텍스트를 만드는 것은 자신이 가장 잘 할 수 있는 일임에도 대부분의 사용자들은 무언가 확실하고 명쾌하면서 만족할만한 컨텍스트의 예를 찾기위해 애쓰는 모습이 보인다.

PS. 하나의 일을 여러 개의 일로 나눈 것과 프로젝트로 만드는 것의 차이는 의외로 간단한 것이 프로젝트는 그 자체로서 마감일을 가진다. 만일 하나의 일을 굳이 여러 개로 조각을 냈다고 해서 이를 프로젝트로 만들 필요는 없다.