OmniFocus 3 안내서 - 컨텍스트

지리한 내용이 될 수 있지만 OmniFocus 3(이하 OF3)의 기술적 혹은 기능적 운용을 다루기 전에 다시 한번 컨텍스트와 멀티 태그에 관한 포스팅을 하게 된 것은-GTD 시스템이 아닌 GTD 프로그램으로서 OF3에서-컨텍스트를 설정하고 활용하는 기능적인 사항이 사라졌다는 오해 때문이다.

즉 OF3를 운용하면서 더 이상 이전 버전의 단일 컨텍스트(이하 컨텍스트)의 제한에 따른 고민이 해소되었는데, 그만큼 컨텍스트는 GTD 시스템에 있어 가장 핵심적인 관리 요소이면서도 GTD에 있어 다른 어떤 요소보다 제약이 많은 사안이기도 했다.

하지만 OF3 혹은 다른 GTD 프로그램이 지원하는 멀티 태그 기능을 통하여 GTD 시스템의 컨텍스트가 지향하는 일과 시간의 실제적 관리 요소로서의 역할을 대체 혹은 대응할 수 있느냐의 문제는 컨텍스트와 멀티 태그 간의 기능적 비교 이상의 것이라 할 수 있다.

특히 최근 OF3나 Things를 GTD 프로그램으로서 생각하지 않고 일반적인 업무 관리 도구로 시작하는 경우가 많음에 따라, 아예 컨텍스트의 의미나 목적은 생각하지 않고 단순히 기능적 절차를 중심으로 관심의 대상이 되기도 하고 있다. 특히 스마트 폰 기반의 OF3나 Things라면 더욱 그렇다.

GTD의 컨텍스트는 GTD 시스템에서 관리되는 하나의 일의 실행을 위한 유일한 전제 조건으로 지정된다. 모든 일이 단 하나의 컨텍스트를 가질 이유는 없다. 하지만 여러 개의 컨텍스트가 설정되었다고 하나만 있은 것에 비해 일의 실행 여부 혹은 가능성이 높아진다고 할 수는 없다.

극단적으로 모든 일의 실행을 저해하는 원초적인 요소가 동시적인 둘 이상의 요소라고 할 수 없다는 판단에서 컨텍스트는 GTD 사용자에게 일의 실행을 위한 단 하나(혹은 그 이상)의 조건을 찾도록 강제하고 있다. 그리고 이상적으로 만일 하나의 일에 두 개 이상의 컨텍스트가 필요하다면 그 조건은 순차적으로 구분될 수 있다는 것이다. 물론 컨텍스트에 대한 이러한 사실을 GTD 시스템을 구축하고 운용하는 모든 이가 철저하게 준수할 필요는 없고, 현실적으로 그럴 수도 없다.

OF3를 운용함에 있어 멀티 태그 기능을 최대한 절대적 기준의 컨텍스트로 사용할 것인지 혹은 가벼운 일상적 태그로 사용할 것인지에 대해 생각할 필요가 있다. 그리고 절때 이 두 경우를 혼용할 수 있다고 자신해서는 안된다.

개인적으로 두 경우 가운데 컨텍스트를 운용하는 쪽이라고 하겠다. 컨텍스트를 적용하기 위해 하나의 일에 대한 실행 조건을 파악하면서, 일의 목적, 목표 그리고 가치 무엇봐도 현실성을 생각하는 기회를 가질 수 있기 때문이다. 그리고 적지 않은 경우 계획한 일이나 프로젝트 자체를 삭제할 수도 있다. 물론 수집된 하나의 대상을 하나의 정확한 일로 만드는 과정에 걸리는 시간이 부담이 되지 않는 수준으로 습관을 들기까지 나름의-가볍지만 신중한 그리고 오랜-노력이 필요했다.

하지만 멀태 태그를 이용한다고 해도 컨텍스트를 이용하는 것과 다르지 않다. 단지 여러 선택 가운데 하나를 고르느냐 두 개 이상의 고르느냐의 차이일 뿐이다. 그렇더라도 선택한 모든 태그 기본적으로 동일한 순위와 가치를 갖도록 관리할 수 있어야 한다. 태그 간의 우선 순위가 발생하는 결국 컨텍스트 운용과 같은 부담이 생겨난다.

어떤 경우든 GTD 시스템을 가득 채울 일에 신뢰성 있는 사전 요구 조건을 정확하게 지정할 수 있는 가능성을 유지할 수 있어야 한다. 자신이 지정하는 사전 요구 조건의 충족에도 불구하고 실질적 실행이-자신의 게으름 외에 다른 걸림돌이 없음에도-진행 불가라면, 조건은 물론 시스템 나아가 자신에 대한 신뢰성도 흔들리게 된다.

GTD 시스템에서 하나 혹은 그 이상의 컨텍스트는 해당 조건이 충족됨에 따라 계획한 일은 실행되고, 진행되고 그리고 결과과 무관하게 완료되는 절대적 요소로 관리될 수 있어야 한다. OF3나 Things가 아닌 어떤 GTD 프로그램을 이용하더라도 유지해야 할 원칙이다.

다시 한번 강조하지만, 이런 컨텍스트 운용의 문제가 멀티 태그로 대체되었다고 해서 상황이 변하지는 않는다. 단지 좀더 편의성을 높여주는 작은 배려일 뿐 문제 해결을 위한 기술적 대응책이 아니다.

적절한 비유일지 모르겠지만 컨텍스트의 선정은 자신이 들어 가야 할 혹은 들어 가고자 하는 문에 안전하게 채워진 자물쇠에 맞는 열쇠를 찾는 것과 같다. 하지만 안전을 위해 자물쇠를 여러 개 이용하여 문을 잠궜다면, 각 자물쇠에 맞는 열쇠를 모두 가지고 있어야 들어 갈 수 있다. 자물쇠가 무용지물이거나 맞는 열쇠가 없다면 문을 부수고 들어 갈 수 밖에 없다.

정리하자면 OF3가 멀티 태그 기능을 제공하게 되었지만 GTD의 컨텍스트로서 활용할 지에 대한 그대로 사용자의 몫으로 남아 있다는 것이다.

만일 GTD 시스템 지향하는 바를 신뢰하고 좀더 전통적인 GTD 프로그램으로 활용하고자 한다면, 컨텍스트로서 멀티 태그 기능 활용에 대해 자신의 생각을 정리할 시간을 먼저 가지는 것이 필요하다고 본다.

PS. 컨텍스트에 관해 아직도 가장 어려운 것은 이 단어를 한글로 어떻게 표현하는 것이 GTD 시스템의 성공적 운용에 도움이 될까 하는 것이다. 사전에 나타난 맥락, 전후 관계, 상황 등 어떤 표현도 나쁘진 않지만 마음에 와닿지 않는다.

OmniFocus 3 안내서 - 프로젝트, 컨텍스트 혹은 멀티 태그

이전 포스팅에서 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 프로그램으로서의 가치를 얼마나 개선할 수 있을 지는 역시 사용자의 몫이라 하겠다.

OmniFocus 3 안내서 - 기본 구조와 구성

GTD 시스템 구축을 위한 기반 혹은 지원 플랫폼으로써-쉽게 적자면 GTD 프로그램으로-OmniGroup의 OmniFocus 3(이하 OF3)를 선택했다면, 일단 현명한 선택이라고 축하하고 싶다. 하지만 더불어 GTD 시스템 구축과 운용이 가장 까다로운(험난한) 길에 들어 섰다고 위로하고 싶다.

현재 OF3는 Things 3(이하 Things)와 함께 Mac을 위한 최고의 GTD 프로그램으로 평가받고 있다. 그외 여러 직간접적으로 GTD 프로그램을 지향하는 프로그램들이 적지 않지만, 기능과 활용성에서 OF3와 Things에 미치지는 못하고 있다.

GTD의 창시자인 David Allen 역시 OmniFocus에 대한 칭찬을 아끼지 않았다. 하지만, 그는 OmniFocus를 비롯한 일반적인 GTD 지향 프로그램을 사용하고 있지는 않다. 여러 이유가 있겠지만 E-메일이나 전자 문서 메시지 등을 직접적으로 관리하는 기능을 제공하지 못한다는 점이 주요하지 않을까 싶다. 그는 Lotus Notes에 기반한 독자적 GTD 프로그램인 eProductivity를 사용했었다. 하지만 Lotus Notes의 지원이 중담됨에 따라 독자적인 GTD 프로그램 개발을 추진하고 있다. 이와 관련해서는 별도로 적어 보고자 한다.

언급한 바와 같이 OF3가 GTD 프로그램 가운데 가장 복잡하고 더불어 불편한 인터페이스를 가지고 있다는 것은 잠시만 사용해 보더라도 쉽게 확인할 수 있다.

OmniGroup이 OmniFocus가 OmniOutliner Pro 기반의 플러그-인 프로그램인 Kinkless GTD를 참고하여 발되고 있다고 공개했다. 덕분에 Kinkless GTD의 인기에 힘입어 OmniFocus는 많은 이들의 관심과 기대를 받지 않을 수 없었다.

하지만 OmniFocus의 베타 버전이 공개 되자, Kinkless GTD에 비해 너무 복잡하고 어렵고 그리고 무엇보다도 iGTD 등 당시 사용자들이 익숙한 GTD 프로그램의 구조과 인터페이스에서 너무 벗어나 많은 불만과 비난을 받았다. 오늘날 OmniFocus가 GTD 프로그램의 대명사로 평가받고 있는 시각과는 꽤나 달랐다.

기회가 되면 OmniFocus의 개발 과정에 따른 GTD 시스템으로서의 운용성 변화도 분석해볼만하다고 보지만, 우선 현재 OF3를 기준으로 GTD 프로그램으로 활용하기 위한 선행적 학습으로 기본적인 기능적 구조와 구성에 대해 적고자 한다.

용어적으로 명확한 표현인지는 모르겠지만, 구조라는 것을 OF3가 제공하는 기본 체계와 기능이라고 본다면, 구성은 그러한 기본 체계와 기능을 다양한 사용자의 활용 목적에 맞춘 GTD 프로그램으로 적합하는 과정이라고 보겠다.

OF3는 OmniFocus 2와는 구조적으로 큰 차이가 없지만, 최초 OmniFocus 1과는 구조와 인터페이스에서 큰 차이가 있다. OmniGroup에서는 아직 OmniFocus 1과 OmniFocus 2를 다운로드 가능하니, 기회가 된다면 OF3와 비교하여 운용해보는 것도 재미있을 것이다.

- - - - -

OF3의 설치는 일반적인 Mac 어플리케이션와 크게 다르지 않다. OF3는 OmniGroup의 다른 제품과 동일하게 라이센스 인증 전에 2주간 무료로 사용이 가능하다.

OF3를 실행하면 다음 화면으로 시작된다. 화면의 왼쪽과 오른쪽에는 각각 사이드 바가 있는데, 왼쪽 사이드 바(사이드 막대)는 OF3의 GTD 운용의 기능적 구조를 보여주는 개요 아이콘이 있다. 오른쪽 사이트 바에는 선택한 요소와 화면 구조의 속성을 설정하는 화면등이 있다. 가운데 넓은 영역은 일과 프로젝트를 아웃라인 형식으로 관리하는 화면이다.

OF3가 Things 3 등 다른 GTD 프로그램에 비해 화면 구조도 복잡하고 물론-특히 한글화된-기능 용어 사용도 어색하다. OF3의 구조적 복잡함을 긍정적으로 보자면 기능이 다양하다고 말이라 할 수 있지만, GTD 시스템이 애초 그런 복잡성을 지향하지 않는다는 점에서 OF3가 현재 가장 인기있는 GTD 프로그램이라는 사실에서 다소 모순적이기도 하다.

다양하고 강력하고 그리고 덕분에 어려운 기능을-선호하는 사용자가 적지 않다는 점에서-OF3의 장점이라고 할 때, 화면에 표시되는 기본 구조와 용어를 이해하는 것만으로도 OF3의 기능 구성 80% 정도는 이해했다고 해도 과언이 아니다.

왼쪽 사이드 바에 있는 각 아이콘은 OF3의 개요(Perspective)라 불리는-필터 기능을 가진-GTD 시스템의 화면을 구성하는 표준 구조 설정 기능으로, 6 개의 표준 개요가 배치되어 있고 각 개요는 Command + 1 ~ 6의 단축키로 지정되어 있다. 그리고 기본 화면에는 표시되지 않지만 몇몇 다른 개요도 내장되어 있는데, 표준 풀 다운 메뉴의 ‘개요’ 메뉴에서 확인할 수 있다.

OF3의 표준 개요는 기본적으로 GTD 시스템으로서의 절차적 구조로서, 각 개요는 기본적으로 동일한 구성의 화면 구조를 가진다. 다소 차이가 있긴 하지만 화면 의 각 요소는 항목 이름, 프로젝트, 태그(컨텍스트), 그리고 마감일 정보 등이다. 각 개요가 제공하는 주요 기능은 간략히 다음과 같다;

• 수신함(Inbox) - GTD의 핵심 기능으로 이해되는 첫 단계인 수집 과정을 수행하기 위한 수집함(수신함)으로 사용자가 직접 입력하거나 E-메일 클라이언트로부터 입력할 수 있으며, iOS 기반의 macOS의 미리 알림 및 캘린더 그리고 시리(siri) 기능 등으로 입력된 사안과 연동될 수 있다.
• 프로젝트(Projects) - OF3의 핵심 관리 구조로서, GTD 시스템에서 실행이 요구되는 다음 일(Next Action) 항목들이 단일 목록 혹은 구조화된 프로젝트로 구성되어 배치되어 관리되는 화면이다. OF3에서 실제적으로 가장 많이 사용되는 부분이다.
• 태크(Tags) - 일의 실행에 사전 요구되는 사항, 즉 컨텍스트(Context)를 대체한 태그 기준으로 OF3의 각 항목을 보여주는 화면이다. OF3는 단일 컨텍스트를 멀티 태그로 대체함으로써 멀티 컨텍스트 환경을 운용할 수 있게 되었다.
• 예측(Forecast) - 업무 목록과 프로젝트의 내용을 마감 일자 순서대로 달력 형식으로 나열하여 보여주는 화면으로 macOS의 달력, 캘린더에 입력된 사항 등도 함께 확인할 수 있다. GTD에서는 일 목록과 일정 목록을 별개로 구분하여 관리하기 때문에, OmniFocus 1은 달력 정보를 볼 수 없었지만, OminiFocus 2 이후부터 달력의 일정을 볼 수 있도록 변경되었다.
• 플래그 지정됨(Flagged) - OmniFocus는 일 목록이나 프로젝트 항목에 대하여 마감 일자 외 별도의 사용자 관리 요소를 지정할 수 없다. 때문에 플래그는 관심을 집중해야 할 특정 프로젝트나 주의를 환기하기 위해 주요한 요소로 사용될 수 있다. 플래그 지정됨 개요에서는 플래그 항목을 태그 구조로 보여준다.
• 검토(Review) - GTD 시스템의 핵심 기능으로 정기적인 일과 프로젝트의 진행 점검 및 수정 여부를 진행하는 기능을 수행하는 화면으로, 각 프로젝트에 설정된 지정된 검토 기간 단위로 대상을 보여주는 화면이다. GTD 프로그램의 대표로 언급되는 OmniFocus의 가장 핵심적이며 독보적 기능이지만, 운용 자체는 쉽지 않는 부분이다.

OF3는 이러한 개요의 기능을 이용하여 수집함에 모여진 개별 정보를 프로젝트로 구성하고 마감 일자 등 속성으로 설정한 후, 프로젝트 진행 상황을 점검하는 과정을 지속하면서 계획한 목표를 완료할 수 있도록 관리하게 된다. 다만 원하는 구조 형식으로 개요을 생성하기 위해서는 OF3의 Pro 버전을 사용해야 한다. OF3의 설치판 기준으로 Standard 버전은 약 $50이지만 Pro 버전은 약 $100 정도이다.

- - - - -

OF3 화면의 오른쪽에는 GTD 시스템에서 관리되는 일과 프로젝트에 대한 상세한 속성을 설정하고, 조건에 맞는 항목을 화면 표시를 제어할 수 있다.

우선 속성 점검(Inspect) 화면은 업무 항목이나 프로젝트의 여러 속성을 설정할 수 있는 기능이 집합된 곳이다. 하지만 개별 속성 간의 연관성을 명확하게 파악하기가 쉽지 않다는 점에서 OF3의 학습에서 가장 어려운 부분이기도 하다.

오른쪽 사이드 바 위에는 몇몇 아이콘이 있는데, 속성 설정 및 검증 사이드 바를 ON/OFF 하고, OF3의 각 개요와 항목을 사용자가 지정한 조건에 맞춰 구조로 보여주는 아웃라인 설정 기능이 있다.

포커스 기능은 OmniGroup의 다른 제품에서도 볼 수 있는 유사한 기능으로, 현재 선택한 프로젝트 외 다른 프로젝트를 숨김으로서 현재 일에 집중할 수 있도록 해준다. 일반적으로 이러한 포커스 기능의 효용성에 의문이 들기도 하지만, 관리하는 프로젝트의 수가 너무 많거나 화면 구조가 너무 난잡한 경우 경우가 유용하게 사용될 수 있다. 단 대상 프로젝트는 여러 세부 프로젝트 단계가 아닌 최상위 프로젝트 단위로만 한정한다.

OF3가 제공하는 기본 구조와 설정을 그대로 사용해도 GTD 시스템으로서 큰 문제가 없지만, 사용자의 업무 환경에 최적화 되도록 설정할 수 있다. 다만 언급한 바와 같이 설정하고 변경할 수 있는 속성 간 조합이 많기 때문에 사용자 설정 과정이 다소 복잡하기도 하고 또한 바로 기대한 결과를 얻기 힘들 수 있다.

- - - - -

OF3는 초기 OmniFocus 1에 비해 인터페이스의 많은 부분이 달라졌다. OF3를 처음 접하고 나서 OmniFocus 1를 보면 상당히 생소할 수 있다. 하지만 그 기본 구조는 크게 달라지지 않았으며, 실제 GTD 시스템 구축의 플랫폼으로 지금도 OmniFocus 1의 효용성은 OF2나 OF3에 못지 않다고 본다.

믿지 않을 수 있겠지만 개인적으로-일상과 구분된 특정 프로젝트 관리 용도로서-여전히 OmniFocus 1을 사용하고 있다. 당연한 말이겠지만 OF1의 경우 더 이상 OF2나 OF3와 데이터베이스를 공유할 수 없다.

- - - - -

OmniFocus를 보다 개인화된 GTD 프로그램을 구성하기 위해서는 계층 구조의 프로젝트와 태그 그리고 여러 다양한 속성을 활용하거나 개요 구성에 대한 기능적 학습이 필요하다.

OF3는 일반적 관리 대상을 개별 일(Task)과 일의 집합체인 프로젝트(Project)로 구분한다. 그리고 모든 관리 대상에 대하여 속성 설정하여 GTD 시스템을 구성하게 된다.

하나의 목표 달성을 위해 여러 일이 필요하거나 혹은 여러 일이 하나의 일이 실행된 후 다음 일이 순차적으로 진행되어야 할 경우 프로젝트로 구성된다.

OF3에서 프로젝트 구성과 관련하여 문제가 발생한다면 기능적 제약이라기 보다는 사용자의 관리 측면에서의 기술적 접근인 경우가 대부분이다.

OF3는 개별 일의 목록에서도 계층 구조로 관리가 가능하며, 프로젝트 역시 계층 구조 없이 단일 목록으로 유지할 수 있다. 다만 목록의 순차적 실행을 위해서는 프로젝트로 구성되어야 한다.

제한된 계층 구조를 가진 Things에서는 여러 개의 세부화된 목록을 개별 프로젝트 구성하여 대응하는데, 최근 Things 3에서도 프로젝트 내부에 세부 리스트를 구성하는 등 확장된 계층 구조를 지원하도록 개선되고 있다는 점에 계층 구조의 프로젝트가 GTD 시스템 운용에 효과적인 것은 분명한 사실이다.

- - - - -

프로젝트와 함께 GTD 시스템의 대표적 핵심 관리 속성이 컨텍스트(context)이다. 컨텍스트의 개념 자체는 특별하지 않다 할 수도 있지만, GTD 시스템은 컨텍스트라는 단순한 관리 요소를 통하여, 이전 주류 업무 관리 방식이나 시간 관리 방식의 유일한 관리 속성이었던 자의적 우선 순위와 마감일이라는 제한된 요소에 벗어나 실제적(현실적) 사전 요구 사항을 관리 요소로 전환시켰다는 점에 사실상 혁신적이라 할 수 있었다. 물론 개인적인 의견이기도 하다.

하지만 언급했듯 GTD 시스템의 컨텍스트 체계가 기본적으로 하나의 일에 대해 하나 컨텍스트만 설정하기 때문에, 업무관리 체계의 유연성을 원하는 많은 사람들에게 큰 제약일 수 있었다. 실제로 GTD의 컨텍스트가 사용자의 자유도를 과격하게 제한하는 비현설적 요소라고 비판한 경우도 적지 않았다.

때문에 Things의 멀티 태그 기능은 단일 컨텍스트(이하 컨텍스트) 운용의 제약을 해소하면서 큰 인기를 끌었다. OmniFocus는 GTD의 컨텍스트 규칙을 계속 유지했지만, 결국 OF3에서 컨텍스트의 제한을 버리고 멀티 태그 체계로 전환하게 된다. 물론 멀티 태그 기능을 활용하지 않고 단일 태그를 사용한다면-더 이상 컨텍스트라는 용어를 사용하지는 않지만-기능적으로 컨텍스트와 동일하게 운용할 수 있다.

- - - - -

OmniFocus는 여러 측면에서 GTD 시스템의 기본 구조와 체계를 유지하려고 노력해오고 있지만, GTD 시스템의 구조와 운용 방식이 컴퓨터 프로그램으로 구현하기 쉽지 않다는 점에서 OmniFocus의 효율적 운용도 결코 쉬운 과정은 아니라 할 수 있다.

인터넷 웹 사이트나 유튜브에는 OmniFocus에 대한 기본 운용 지식과 함께 보다 효율적인 GTD 시스템으로 운용하기 위한 내용이 Outlook 못지 않게 많은 편이다. OmniFocus의 운용에 관심이 많기도 하지만 그만큼 효율적 운용이 쉽지 않다는 반증이라고 본다.

오랜 OmniFocus의 사용자로서 OF3의 여러 기능적 사안에 대해 완벽하게 만족할 수는 없지만, 그럼에도 GTD 프로그램으로서 높은 경쟁력을 유지해오고 있는 가장 큰 강점은 언급한 이런 각 사안들이 나름 묘하게 균형을 이루고 있는 덕분이 아닐까 한다.

사용자의 편의성을 강조한 Things나 GTD 시스템의 기능과 절차적 단계에 집중한 The Hit List나 Inbox 그리고 Thinking Rock 등과 비교할 때 OmniFocus는 많은 기능과 복잡한 구조에 불구하고 적절한 균형성을 유지하고 있다.

하지만 개인적으로 안타까운 점은 최근 GTD 시스템의 운용 환경이 iOS 등 모바일 환경의 스마트 기기로 확장되면서, OF3의 사용이 일상적 업무 관리 용도로 단순화되고 있다는 점이다.

앞으로 OF3가 어떤 식으로 발전할 지 예측이 힘들지만 GTD 시스템으로서 기능성을 제대로 운용하기 위해서는 당분간 Mac이 중심이 되지 않을까 생각한다.

GTD 프로그램 공식 셋업 가이드 2020

2020년 현재 David Co.의 GTD 공식 사이트인 GTD Times/GTD Connect에서 제공 즉 판매 되고 있는 셋업 가이드(Setup Guide)는 다음과 같다. 2017년 이후로 GTD Connect에서 수집함이나 노트북의 판매는 중단하고 프로그램 설치 및 운용 가이드 그리고 기타 참고 자료 등만이 판매되고 있다.

• Asana - Web
• Evernote - Mac/Windows
• Google Apps for Desktop - 2019.03
• IBM Lotus Notes - HCL 인수 후, GTD 애드-온 eProductivity 공급 중단
• Nirvana
• OmniFocus 2/3
• OneNote for Windows
• Outlook for Mac 2011/2016/2019
• Outlook for Windows 2010/2013/2016
• Things
• Todoist
• Trello
• Wunderlist - 마이크로소프트 인수

GTD를 막 시작해보려는 이들 가운데 특히 자신의 프로그램을 어떻게 GTD 시스템으로 최적화 시켜야 하는 지 고민하는 이들에게 GTD의 공식 셋업 가이드는 가장 궁금하고 탐나는 자료라고 할 수 있다. 하지만 기대만큼 특별한 기술로 가득하지 않을까 하는 기대는 접는 것이 좋다. 구입하고 나면 과연 $10의 가격만큼 가치가 있나 고민하게 될 지모른다. 솔직히 셋업 가이드나 셋업 영상을 보고하면 David Co.에서는 역시 특정 프로그램의 상세하고 전문적인 운용에는 관심이 없는 것 같다는 생각이 들지 않을 수 없다.

제품에 따라 차이가 있지만 대략 40 페이지 전후의 두께이기 때문에 GTD에 대한 간략한 구성과 설정 중심이기 때문에 전체적으로 비슷한 내용이라고 볼 수 있다. 그리고 위 항목 가운데 몇몇 프로그램은 개발 중단 되거나 이전 되어 셋업 가이드의 내용과 다소 차이가 있다.

PS. GTD Connect 사용자 계정의 체험판을 신청해도 위 GTD 셋업 가이드는 볼 수 없다. 한때 트라이얼 계정에 대해서 셋업 가이드를 비롯한 전체 문서가 개방된 적도 있었지만, 지금은 정식 유료 사용자들만 볼 수 있다. 하지만 셋업 가이드에 준하는 영상 강의를 볼 수 있기 때문에 충분히 체험판을 활용할 수 있다.

불편함의 극복이 생산성 개선은 아니다

최근 맥 관련 온라인 커뮤니티에서 새로운 맥 구입 시에 모델 선정이나 업그레이드 여부 그리고 실제 운용 과정에서의 혼란스러운 점에 대한 질문을 많이 받는다.

업무의 생산성은 일정 부분 업무 환경과 도구의 효율적 관리를 기반으로 한다. 개인적 일상의 범위에서 기업의 프로젝트 수준까지 크게 다르지 않다. 때문에 기업에서 새로운 프로젝트를 시작할 때마다 보다 효율적인 프로젝트 관리를 위한 여러 사전 조치를 취하느라 바쁘게 움직인다. 비록 그러한 광범위한 수준이 아니더라도 개인적 차원에서도 일상의 업무 혹은 일에 관련한 생산성 개선 역시 GTD의 운용의 주요한 목표라고 할 수 있다. 하지만 오늘 포스팅하는 내용은 그러한 범주라기 보다는 보다 일상적인 측면에서 컴퓨터, 특히 애플의 맥 운용과 관련한 사안이다.

개인적으로 오랫동안 애플의 컴퓨터를 사용해 온 경험에 비춰, 한국에서 맥을 사용한다는 것은 일반적 컴퓨터 활용 수준 이상의 적응력이 요구된다. 한마디로 어렵고 불편하고 적지 않게 비용도 많이 소요된다.

문재 해결에 있어 정상적 대응, 다시 말해 익숙하고 값싼 대응 방법이 있다면 그것이 선택하는 것이 업무 생산성 개선하는 방법은 아닐지라도 생산성을 저해하지는 않는 효율적 방법이다. 하지만 업무 플랫폼의 차이로 인해 이러한 일반적 대응이 어렵거나 불가능한 경우가 있다.

만일 맥 환경에서만 운용되거나 혹은 다른 환경에 비해 맥에서 운용하는 것이 월등히 효율적인 프로그램이 있다면 어쩔 수 없지만, 그렇지 않다면 즉 다시 말해 맥과 원도우즈 환경 모두에서 운용할 수 있는 경우라면 오늘날 현실에서 성능은 물론 비용적인 면에서 원도우즈를 선택하는 것이 합리적이며 현명한 방법이다. 더욱이 전문적 영역에서 보자면 원도우즈 환경에서만 구동되는 프로그램이 비중이 현저히 높은 것이 사실이다. 일반 사무 용도가 아닌 제품 설계나 개발 혹은 평가 그리고 분석 과정을 위한 프로그램의 수와 질에서 맥에 원도우즈에 비교될 수 없는 것이 현실이다.

자신이 사용해야 할 프로그램이 맥 환경만을 지원하거나 반대로 원도우즈 환경만을 지원한다면 맥이냐 원도우즈 기반 PC냐의 선택은 명확하다. 고민 되는 것은 원도우즈 환경을 기준으로 동일한 프로그램 혹은 유사한 프로그램을 맥 환경에서 이용하여 원도우즈 환경에서의 생산성을 맥 환경에서구현하거나 근접하는 수준으로 만들고자 하는 경우이다.

맥에서의 특정 업무의 수행 가능 여부가 아닌 그 가능성이 원도우즈 환경에 비춰 얼마나 쉽게 그리고 적은 비용과 노력으로 구현될 수 있느냐에 관한 것이다. 앞서 언급했지만 결론적으로 비용과 시간과 노력이 필요할뿐더러 성과도 만족스럽지 못한 경우가 대부분이다. 일반적인 원도우즈 기반 PC 사용자 입장에서 보자면 이러한 맥 사용자의 대응과 처지는 이해 되지 않을 것이다.

하지만 그런 시선에도 불구하고 오랫동안 맥을 운용해온 입장에서는 시간과 비용 그리고 노력의 소비가 오히려 자부심으로 자리잡기도 한다. 하지만 일부 사용자에게 있어서는 그러한 대응이 매우 심각한 모순적 자아도취 수준으로까지 이어질 위험도 있다. 당연한 말이지만 그것이 맥의 매력이라고 한다면 따로 대응할 의지나 방법은 없다.

원도우즈 환경에서의 프로그램이라면 간단하게 처리할 수 있는 기능을 맥 환경에서는-맥 사용자들의 힘겨운 노력에 의해-몇 단계를 거쳐 구현이 가능할 수 있게 했다면, 스스로에게는 자랑스럽고 만족스러운 성과가 될 수는 있겠지만 효율적인 업무나 시간 관리를 위한 적절한 대응이라고 할 수는 없다.

특히 여러 사용자들이 함께 업무를 수행하는 협업 환경에서는 이러한 현실을 유지하기란 쉽지 않다. 개인적인 경험에서 보자면 부서장이었으니 망정이지 다른 직원들이었다면 상상할 수 없는 일이었다. 개인적으로 업무 체계에서의 맥 사용에 따른 문제 발생이 최소화 되도록 일상적 업체용 플랫폼 외의 운용은 최대한 자제했다. 다만 맥 옆에 업무를 위한 별도의 시스템이 마련되어 있었다.

과거 맥 사용자가 원할한 업무를 위해 별도의 DOS/원도우즈 기반 PC를 옆에 둔다는 것은 비용적으나 공간적으로나 쉽지 않은 일이었다. 하지만 이러한 제약은 어느새 모두 과거형으로 표현될 정도로 일반적인 원도우즈 기반 PC의 가격과 크기는 현저히 줄어 들어, 추가적인 PC의 마련이 가장 현실적인 대응이 되는 상황에 이르렀다. 또한 그 마저의 비용 조차 없다면 무료 혹은 저렴한 가상화 플랫폼을 이용하는 등 대응 방법에 대한 선택의 여지가 다양하다.

그러나 아직도 많은 맥 사용자들이 그 불편함을 극복하기 위해 노력하고 있다. 그 자체는 맥 사용자로서 매우 가치 있는 일이라고 생각한다. 하지만 업무적 행위를 위해 그런 대응을 해결책으로 제시하고 그것이 업무용 시스템으로 맥 도입이나 운용을 긍정적 시각으로 바라보는 근거로 주장한다는 것은 무리가 있다. 무엇보다 최악의 상황은 이러한 상황을 겪으며 극복한 현실이 최고의 생산성을 확보하기 위한 방안이라고 착각한 경우이다.

맥을 레트로 머신으로 다루는 취미가 있다면 이런 일은 나름의 가치가 있다고 볼 수 있지만, 업무용 혹은 일상 용도로 사용하면서 어렵거나 힘든 문제를 해결하기 위해 다양하고 복잡한 더욱이 비용까지 소요되는 방법을 통해 얻은 성과에 만족스러워한다면 생산성 개선이나 향상은 커녕 극악의 비효율적 대응이다.

20세기 말, 1990년대 중반 이후는 원도우즈에 의해 맥을 비롯한 다른 운영체제들이 초토화 되는 마이크로컴퓨터, PC의 암흑 시대가 있었다. 이후 유일하게-유닉스/리눅스를 제외하고-생존한 맥은 원도우즈 사용자와 개발자에 의해 말 그대로 기타적 존재로 취급 받았다. 맥의 킬러 소프트웨어였던 엑셀이나 포토샵 등은 일찌감치 원도우즈의 킬러 소프트웨어로 전환되었다. 냉정하게 기능적으로나 비용적으로나 그리고 성능적으로도 업무용 컴퓨터 시스템으로서 맥을 선택해야 할만한 합리적 이유는 극히 제한적이었다.

그럼에도 나를 포함하여 애플과 맥에 충성스러운 사용자들은 불편하고 부족한 상황을 어렵사리 극복해가면서 애플의 생태계가 유지되는데 작은 공헌을 했고, 어느새 유구한 전통 마냥 애플, 맥 사용자의 자부심으로 자리 잡았다.

이후 십수년이 지난 사이 이제 맥은 비록 시장 점유율에서 크게 다르지 않지만 아이폰과 아이패드 덕에 절대적인 신규 사용자의 수가 증가하고 있다. 그런데 일부 지난 세대 맥 사용자들은 새로운 환경에 적응하지 못하는 신규 맥 사용자들에게 자신의 경험과 노하우에 기반한 극복의 기술을 전달하고 있다. 그리고 일부 신규 맥 사용자들은 이러한 대응을 자연스럽게 받아들이는 경우도 있다.

- - - - -

개인적이든 업무적이든 일의 수행에 따른 불편함을 이런저런 방법으로 극복한다는 것은 여러모로 생활의 활력소가 될 수 있는 나쁘지만은 않은 대응이라고 할 수 있다. 하지만 업무와 관련한 영역에서 이러한 경우가 빈번하다면 가능한 지양해야 하는 부분이라고 하지 않을 수 없다. 하나의 경우에 잘 대처할 수 있었다 하더라도 이후 발생하는 문제에 다시금 적절하게 대응하기가 쉽지 않을 수 있다. 나아가 전체적인 협업 체계에서 비효율적이면서도 불안하고 위험한 요소로 작용할 수도 있다.

도구는 도구일 뿐이다. 특히 업무 영역에서는 더욱 그렇다. 도구로서의 가치와 취미로서의 가치를 일치 시켜려는 노력이 한다면, 내가 언제나 주장하는 바와 같이 끈질긴 노력 보다는 과감한 포기가 훨씬 생산적이라는 사실을 강조해 주고 싶다. 물론 그 상대가 기업의 경영자나 소유주라면 어쩔 수 없지만.

내가 GTD 시스템을 운용하면서 가장 강조하는 단 하나의 원칙을 꼽으라면, 목표가 목적을 규정할 수는 없다는 사실이다. 하지만 많은 이들이 목적을 망각하고 목표에 집중하는 경향이 너무 크다. 한두 번의 단기적 성과에는 적응 가능한 방법일지 모르지만 결국 목적을 잃고 수 많은 목표에 갇히는 경우를 많이 목격했다. 이른바 주객전도의 상황이다.

일상이나 업무와 관련하여 많은 이들이 컴퓨터 시스템 혹은 프로그램 운용에서 발생하는 문제를 마치 자신의 인생에 도전 마냥 해결하기 위해 열정과 정열을 쏟는 경우가 많다. 하지만 도구의 문제는 도구답게 해결하는 자세가 가장 합리적이면서도 현명한 대응이다. 자신이 즉각적으로 해결할 수 없다면 과감하게 포기하고 전문가를 부르길 바란다.