이전 포스팅에서 OF3의 프로젝트와 태그 체계를 간략하게 적었다. 분명 계층 구조의 프로젝트와 컨텍스트 지원은 OF3의 가장 큰 특징임에 분명하다. 하지만 이것은 OmniFocus와는 무관한 GTD 시스템의 특징이라 생각할 수 있다. 사실 Things를 제외한 대부분의 GTD 프로그램들이 계층 구조의 프로젝트를 지원해오고 왔다.
- - - - -
사실 OmniFocus나 Things가 다른 GTD 프로그램에 비해 시장에서 운이 좋았다고 본다. David Allen이 GTD를 소개한 이후 GTD 시스템에 대한 대중적 관심이 확산되기는 했지만, GTD 프로그램에 대한 평가는 기대만큼 부응하지 못했다.
Inbox(Midnight Beep)나 ThinkingRock(Avente)과 같은 프로그램들은 GTD 시스템의 절차적인 면에 집중하다보니 컴퓨터 프로그램으로서 운용성 특히 사용자 인터페이스가 너무 어렵고 복잡했다. 이후 iGTD와 Kinkless GTD 등이 Mac OS X 환경에서 보다 GTD 체계를 보다 유연하게 적용시킴으로서 GTD 프로그램의 효용성에 재부각 시키게 되고, 2008년 전후로 OmniFocus와 Things 출시되면서 다시 GTD 프로그램 열풍이 불게 된다.
그리고 OmniFocus의 계층 구조 지원 프로젝트 기능이 부각된 이유도 한편으로는 어이 없게도 Things의 인기 덕분이라고 할 수 있었다. Things가 계층 구조 프로젝트를 지원하지 않음에 따라 대응할만한 유일한 프로그램인 OmniFocus의 계층 구조 프로젝트 지원이 돋보이게 된 것도 틀린 사실은 아니라고 본다. 이후 Mac 기반 GTD 시스템 사용자는 OmniFocus와 Things로 양분되었다.
단순히 기능적 측면에서 보자면 OmniFocus의 다양하고 강력한 기능에 우위에 있다고 볼 수 있지만 Things의 깔끔하고 단순한 인터페이스 역시 사용자들의 큰 호응을 얻고 있다. 특히 아이폰과 아이패드 환경에서는 Things의 디자인과 인터페이스가 OmniFocus에 비해 훨씬 효율적이다.
- - - - -
OF3의 프로젝트의 기본 구조와 기능은 OminiFocus 출시 이후 거의 변화는 없을뿐더러 매우 단순하다. 기능적이 부족하다가 보다는 사용자의 유연성이 매우 크다는 것이다. 오히려 너무 많은 하위 계층 구조를 생성함에 따라 효율적 관리가 어려울 수도 있다. 물론 이런 점을 OmniFocus의 문제라고 할 수는 없다.
앞서 OF3의 프로젝트 기능이 다른 GTD 프로그램의 프로젝트와 별 다른 차이가 없다고 적었지만, 프로젝트와 관련된 유용한 기능이 없다는 것은 아니다. 우선 본격적으로 OF3 즉 OmniFocus에서 프로젝트가 어떻게 활용되는 지에 대해 적고자 한다.
OF3의 프로젝트가 가진 특징은 프로젝트에 대한 속성이 고정되어 있지 않는 것이다. 즉 단일 목록에서 계층 구조를 지원하는 프로젝트로 그리고 프로젝트 내부에 여러 유형의 프로젝트를 포함하는 등 유연성이 매우 높다. 때문에 개별 항목이나 다양한 구조의 프로젝트나 관리 방식은 거의 동일하다. 계층 구조의 프로젝트를 단일 항목과 동일한 속성을 설정하여 관리할 수 있기 때문에, 프로젝트 진행 관리 역시 매우 다양한 방법으로 운용할 수 있다.
하지만 프로젝트의 여러 속성 간 충돌로 인해 예상한 일자나 시간에 나타나지 않은 상황이 발생할 수도 있다. 그런 측면에서 사용자의 GTD 시스템 운용 스타일에 따라 최적화하는 방법이 다양하기 때문에 OF3의 프로젝트 활용을 일반화하여 설명한 튜토리얼을 만드는 것도 매우 어렵다.
- - - - -
OF3에서 GTD 시스템의 또 다른 주요 핵심 관리 요소인 컨텍스트를 운용하는 방법 역시 큰 어려움은 없다. 문제는 컨텍스트 혹은 태그 자체의 가진 의미가 정확하게 업무 항목에 적용될 수 있느냐에 관한 것이다.
컨텍스트는 기본적으로 실행 즉 행동에 필요한 사전 요건이라는 점에서 명확한 실행과 결과를 예측할 수 있는 대상에 적용되어야 한다. 그런 점에서 컨텍스트는 단순한 일정과 같은 실행과 결과의 평가가 구체적이지 않은 대상에 대해서는 적용하지 않는다. 컨텍스트의 애매한 적용은 GTD 시스템 전체의 신뢰성에 심각한 피해를 초래할 수 있다.
컨텍스트의 운용에서 문제가 발생하지 않으려면 업무 환경에 대응할 수 있는 적절한 내용과 수의 컨텍스트가 규정되어 한다. 그렇다고 먼저 규정된 컨텍스트를 일방적으로 유지하려고 해서는 안된다. GTD 시스템의 프로젝트와 컨텍스트는 항상 업무 상황에 최적화될 수 있도록 정기적 관리 과정에서 검증해야 한다.
그렇다보니 많은 사용자들이 GTD 시스템 구축 과정에서 컨텍스트 설정에 많은 고민을 겪다보니 참고 정보를 찾는 경우가 많다. 하지만 결국 자신에게 적합한 컨텍스트가 아니라면 일상이 확대될 수록 규정된 컨텍스트의 부족함이나 어색함에 다시 고민에 빠지게 된다.
또한 많은 GTD 프로그램 사용자들이 컨텍스트의 종류, 명칭, 구조 등을 너무 간결하고 깔끔하게 구성하려는 경향이 있다. 주변의 여러 일들을 명확하게 한번에 포함하는 완벽한 컨텍스트로 표현할 수 있는 단어를 찾기란 쉽지 않다. 예제는 예제일뿐이라 각자의 모든 상황을 수용하길 기대할 수는 없다. 시간이 걸리더라도 자신에게 맞는 컨텍스트는 자신만이 명확하게 구성할 수 있다. 템플릿처럼 미리 누군가가 만든 컨텍스트를 자신의 일상과 업무에 적용한다는 것은 GTD 시스템을 제대로 이해하지 못한 것이다.
만일 현재 GTD 시스템이 일상의 업무와 나아가 삶을 좀더 나은, 즉 평안한 방향로 촉진하지 못하고 있다면 여러 이유가 있겠지만, 운용적인 컨텍스트가 현재 진행되고 있는 일의 실행을 위한 명확한 사전 요건이었는지 다시 검증해 볼 필요가 있다. 아마 지금보다 2배 이상의 컨텍스트가 필요할 지도 모른다.
다른 한편으로는 GTD 시스템의 절차적 전개에 집중한 탓인지 컨텍스트를 너무 단순하게 생각하는 무작정 생성하는 경향이 있다면 이 역시 상황에 적절한 지 검증해 볼 필요가 있다. 상세한 컨텍스트를 적용한다는 점에서는 필요한 만큼의 컨텍스트를 생성해야 겠지만, 너무 세부적인 수준에서 사전 조건을 선정하여 일상적 업무에 적용하기에는 그 범위가 제한적일 수 있다.
예로 외출이나 출장 등의 일에 적용하기 위한 컨텍스트로 ERRAND를 많이 사용하고 있는데, 한글로 표현하자면 외부 활동이나 외부 업무 등으로 표기할 수 있을 것이다. 집이나 회사 혹은 학교 등 범위가-비록 그 자체도 넓은 영역이지만-정해진 곳에서의 업무 행동이 아닌 그외 외부적 장소에서의 실행 항목에 대해 적용된다.
하지만 특정 장소가 아닌 일상이나 업무에서 발생하는 여러 다양한 장소에서 발생하는 실행 항목을 ERRAND라는 하나의 컨텍스트로 수용할 수 있는 지에 대해서는 자신의 업무 범위나 영역을 평가하여 설정해야 한다. 단순하게 외부에서 행동하는 일이라고 해서 모두 ERRAND라는 컨텍스트가 지정될 수는 없다. 외부 행동을 위한 사전 조건으로 ERRAND가 적용되었다면 그 일은 특별한 사전 요구 조건없이 외부에서 바로 실행할 수 있는 일이란 의미도 포함하고 있다. 과연 그런 일인지 다시 한번 생각해볼 수 있지 않을까 싶다.
다시 말해 컨텍스트 운영에 있어 ‘하나의 컨텍스트로 많은 행동을 포함하는’ 방법과 ‘개별적 사안에 대한 각각의 컨텍스트를 운용하는 방법’ 가운데 선택하는 것은 현명하지 못한 판단이다. 상황과 영역에 따라 두 가지 모두가 적절하게 운용할 수 있어야 한다. 한 사람의 일상이 이런 식으로 명확하게 구분될 수는 없다. 또한 구성과 내용이 세련되지 못하더라도 자산에게 적합한 컨텍스트와 구조를 갖추는 것이 성공적인 GTD 시스템 운용의 핵심이다.
앞서 언급했지만 GTD 시스템 구축하는 과정에서 모든 컨텍스트를 미리 완벽하게 구성해야 한다고 부담감을 가질 필요는 없다. 삶의 정확하게 예측할 수 없듯 컨텍스트 역시 그런 식으로 완벽하게 구성할 수 없다. 비록 범위가 넓은 범위를 포함하도록 시작되었다 하더라도, 시스템을 운용하면서 자신에게 필요한 그리고 적합한 범위의 컨텍스트를 추가하고 삭제하고 구조를 점검할 수 있다.
- - - - -
OF3가 멀티 태그 체계를 적용함에 따라 지금까지 OmniFocus 운용에서 가장 큰 어려움이었던 단일 컨텍스트 제약은 해소되었다. 사실 GTD 시스템에서 반드시 단일 컨텍스트(이하 컨텍스트)를 유지하는 절대적 규칙이 있다고 할 수는 없다. 때문에 GTD 소개 이후부터 멀티 태그를 채용한 GTD 프로그램도 적지 않았다. 물론 컨텍스트 외 별도의 부가 요소로 관리되는 것이 일반적이었다.
하지만 Things 이전에는 GTD 프로그램에서 멀티 태그가 큰 주목을 받지는 못했다. Things는 멀티 태그 체계를 단일 컨텍스트 체계의 보조 수단이 아닌 완전한 대체 수단으로 사용했다는 점이-누구나 예상할 수 있는 일임에도-다소 충격적으로 다가왔다.
하지만 단일 컨텍스트든 멀티 태그든 그 관리 방식의 차이가 GTD 프로그램으로서 성공을 보장하지는 않는다. 어떤 경우라도 GTD 시스템의 컨텍스트가 애초 지향하는 바를 제대로 인식하지 못하면, 의미없는 단어의 나열일 뿐이다. 즉 컨텍스트의 역할을 대체하거나 포함하는 어떤 어떤 기능이라도 실제적 일의 실행을 담보할 수 있는 핵심적인 사전 요구 조건으로서 가치로 평가될 수 있어야 한다.
GTD 시스템의 시작 그리고 운용에 따른 효용성은 컨텍스트의 역할에 대한 정확한 이해와 현실적 적용에 기반한다. OF3의 멀티 태그 기능이 GTD 프로그램으로서의 가치를 얼마나 개선할 수 있을 지는 역시 사용자의 몫이라 하겠다.
