새로움의 반복.. 문제는 앞이 아닌 뒤에 있다 ?

주변의 많은 이들도 어느새 다가 온 새해를 준비했고 혹은 느닷없이 닥친 새해 첫 날에 신년 계획 준비에 한창이다. 업무적인 또는 사업적인 경우라면 이런 계획으로서의 계획을 준비한다는 것은 이미 기계적으로 처리할 정도로 이골이 났음에도, 사람이라서 그런지 언제나 새로움이라는 그 신비로움이 주는 부담은 만만치 않다. 다만 계획은 계획일뿐이니 크게 마음을 쓰지는 않지만 주변에 눈이 적지 않다면 연말연시를 열심히 고민하는 모습을 보여주는 것도 나쁘지 않다.

그러한 정성을 보다 순전히 개인적인 측면으로 관심을 가져보자면, 상황과 입장에 따라 다를 수 있겠지만 짧은 새해 첫 연휴에는 새로운 계획 보다는 이미 계획했던 일에 대한 평가에 집중하고자 한다. 내일부터 시작할 많은 새로운 일을 돌이켜 보면 상당수가 지난 올 해가 새로운 한 해였던 시절 계획했던 일이라는 사실 때문이다.

큰 일도 있고 작은 일도 있고, 어려운 일도 있고 쉬운 일도 있겠으나 결국 하지 않은 또는 하지 못한 많은 일의 대부분이고 그런 친구들이 다시 올 해의 시작, 지난 해의 시작에 새로움이란 꼬리표가 붙어 다시 목록에 올라와 있다. 한심스럽기도 하지만 한편으로 도대체 어떤 점이 이들을 이토록 오랫동안 새로움으로 가득하게 만들고 있는 지 궁금하지 않은가 ?

그 이유에 대한 고민은 각자의 몫이긴 하지만, 이러한 고민을 하기까지 우리는 수 많은 일들을 수 년 혹은 그 이상의 시간에 걸쳐 계획이나 실행 목록에 올려 놓고 지내왔다는 사실에서 근거하여 볼 때, 이들에 대한 조치나 대응을 할 시점은 바로 지금 이 순간이라는 것이다. 다만 계속 다음의 새로운 계획으로 이전되고 있다는 것은 분명 이유 이상의 의미가 있을 수도 있다.

거창하지만 현실적 실현 가능성이 지극히 낮은 장기적 계획일 수도 있고, 실제적 가치가 다른 일에 의해 자꾸만 뒤로 밀려 나갈 수 밖에 없는 사소하고 소박한 계획일 수도 있다. 하지만 GTD 시스템을 운용하는 입장에서 이런 일의 크기나 가치 그리고 중요성은 동일하다. 결과는 한 일과 하지 않은 일 혹은 못한 일로 나뉠 뿐이다. GTD 시스템에서 성공과 실패는 실행 이후의 결과이며 GTD 시스템의 실제적 관리 사항이 아니다. 그럼에도 오랫동안 실행하지 못하고 있는 일들이 시스템에 계속 나타나고 있다면 분명 아군이 아닌 적군의 성향을 가진 대상이라고 봐도 무당하다.

새해를 몇 일 앞둔 연휴나 새해 연휴 동안 해야 할 일은 분명하다. 불확실한 앞으로의 일이 아닌 확실하게 지연되고 있는 지난 일을 정리하고-만약 지속해야 할 가치가 분명하다면-이를 실질적 실현 가능한 새로운 계획에 반영한다. 계획에 집중하는 것 보다 실행에 집중하는 것은 GTD 시스템의 운용성과 신뢰성을 보장하는 가장 중요하다면서 단순한 원칙이다. 예로 적어도 2년 이상 유사한 이름과 내용으로 반복되고 계획이나 그 계획의 일부라면 추진 가능성이나 집중할 수 있는 여력 나아가 실행 의지를 전제로 볼때 과감히 버려야 한다. 혹은 그 가운데 실행 가운데 사안만을 골라 내어야 한다. 그 마저도 아니라면 지금 당장 실행해야 한다. 실행해야만 그 전체적 실행 가능성을 그나마 짐작이라도 할 수 있다.

우리의 삶을 힘들게 하는 건 미래의 불확실한 기대(혹은 실망)라고 하지만 좋든 그르든 결국 그 미래의 아직 오지 않았다는 사실에서 지금 이 순간의 원흉은 어제 하고자 했으나 오늘 하지 않았고, 내일 할 수 있을 것으로 기대 했으나 내일이 오늘이 되어 버리는 일들이 여전하기 때문이다. 그리고 그 결과를 알면서도 작은 기대를 가지고 뒤로 뒤로 넘기며 희망을 가진다. 누군가는 이를 게으름이라고 정의할 것이다.

앞이 잘 보이지 않을 때에는 지금 뒤를 돌아보면 아마도 내 발목을 잡고 있는 것이 뭔지 알 수 있지 않을까 싶다. 물론 거기서 헤어날 수 있을 지는 솔직히 모르겠다. 그렇더라도 최소한 내가 지금 늪에 빠진 것인지 혹은 길 위에 멈춰 있는 것인지는 알 필요가 있다.

OmniFocus 3 안내서 - 4. Reflect, 리뷰(검토)

GTD 시스템 운용의 네번 째 과정 Reflect, 즉 리뷰 단계는 GTD 시스템 운용에서 가장 중요한 역할을 한다. 그리고 이어지는 실제적 실행 및 운영 단계인 Engage 과정에서 진행되는 모든 일에 대한 설계와 평가를 담당하는 부분이기도 하다. 하지만 실제 실행 과정은 OF3와 무관하기 때문에 GTD 프로그램으로서의 운용은 Reflect 과정이 마지막이라고 할 수 있다.

OF3를 시작한 하루, 한 차례에 걸쳐 이전 Capture 과정에 이은 Clarify와 Organize 과정이 마무리 되었다면, 수신함은 비워지고 실행을 앞둔 모든 항목들은 프로젝트 그룹으로 옮겨진 상태가 된다. 결국 OF3의 기본 작업 환경은 수신함과 프로젝트 그룹으로 나눠져 있다고 볼 수 있다.

GTD 시스템의 Reflect 과정은 실제 실행 과정인 Engage 과정에 앞서 계획을 확인하고, 이후 결과를 반영한 관리를 위한 과정이라면 점에서, OF3에서는 프로젝트 화면에서 모든 실행 사항을 계획하고 실행한다. 그리고 정기적으로 OF3의 검토 화면을 통해 업무의 실행 및 진행 여부를 확인할 수 있도록 한다.

그리고 검토 개요가 정기적인 업무 진행 관리 상황을 위한 것이라면, OF3의 프로젝트 개요와 예측 개요는 일상적이고 즉각적인 업무 진행 관리를 위한 기능이라고 할 수 있다.

더불어 특정 상황, 위치 그리고 조건에 따른 업무 현황 관리를 위한 태그 개요과 플래그 지정됨 개요를 함께 활용할 수도 있다. 물론 OF3를 좀더 개인화된 상황에 적합하도록 꾸밀 수 있는 능력이 된다면, Pro 버전을 이용하여 개요를 새로 생성할 수도 있다.

• 프로젝트 개요

프로젝트 개요 즉 프로젝트 화면은 실행 가능한 모든 일상과 업무 항목이 개별 혹은 프로젝트로 구성되어 배치된 곳이다. Reflect 과정의 주된 관리 작업이 프로젝트 개요와 아래 예측 개요에서 진행되는 것에 반해, 태그나 예측 그리고 플래그 지정됨 개요는 상대적으로 사용 빈도나 효용성이 제한되어 있다고 볼 수 있다. 특히 OF3를 GTD 시스템으로서 보다는 일정 관리 시스템으로서의 사용 비중이 높다면 예측 개요를 많이 사용할 수도 있겠으며 그런 경우라면 달력이나 별도 일정 관리 프로그램을 사용하는 것이 더 효율적이라 본다.

OF3의 프로젝트 개요에서는 현재 관리되는 진행이거나 보류중인 모든 프로젝트나 업무 목록을 볼 수 있다. OF3에서의 모든 항목은 순차적 배열이 아닌 사용자가 입력한 순서나 입력한 위치에 설정되기 때문에 마우스를 이용하면 프로젝트와 업무 항목의 순서를 조정할 수 있다. 이점이 OF1 시절과 가장 다른 점인데, OF1에서는 프로젝트나 업무 목록의 각 항목은 마감일이나, 소요 시간 등 여러 요소로 정렬이 가능했다.

프로젝트 구성과 운용은 OF3의 기본적인 운용 방식이기 때문에 별도의 포스팅으로 적어보고자 한다. 만일 OF3에서 프로젝트 단위의 업무 진행 현황이 아닌 전체 관리 항목의 순차적 진행 현황을 기준으로 관리를 하고 싶은 경우에는 아래의 예측 개요를 이용할 수 있다.

• 예측

프로젝트 개요가 계층적 프로젝트 구성으로 OF3에서 관리하는 전체 업무 현황을 보여주는 것에 반해, 예측 개요 화면은 단순하게 보자면 날짜별 업무 목록의 나열이라는 점에서 일반적인 업무 목록 관리 기능이라고 할 수 있다.

실제 프로젝트와 같은 특정 목표를 기준으로 진행 상황을 점검하는 기능이 아닌 날짜별로 연속된 업무 일정을 확인할 용도가 종종 있다. 다만 일 단위로 해야 하는 일이 많다면 화면이 작은 경우 시각적으로 다소 불편할 수도 있다.

예측 개요의 화면 왼쪽에는 한달 치 달력이 배치되어 있고, 해당 일의 업무 항목 수가 표시되어 있으며, 오른쪽 목록에는 마감일 기준 미완료 항목과 현재 실행 항목 그리고 미래 항목이 순차적으로 나열된다. 각 항목의 색상은 마감일 이후 완료 확인하지 못한 항목은 빨간색, 마감일 임박한 항목은 노란색으로 나타난다.

그리고 예측 개요 화면의 오른쪽 업무 목록에 macOS의 달력 프로그램에서 관리되는 사항을 함께 볼 수 있게 되었는데, 표시 화면 구성에서 전체 혹은 일부 달력을 선택할 수 있다.

• 태그 개요

태그 개요의 화면은 개별 업무 항목의 태그 및 프로젝트가 지정된 태그를 임의 순서로 보여준다. 배열 순서는 사용자가 역시 임의로 구성이 가능하다. OF3는 멀티 태그에서도 기존 컨텍스트와 같이 계층 구조를 지원하기 때문에 다양한 구조의 태그 배치가 가능하다.

태그 자체의 활용성과 달리 OF3의 태그 개요 화면을 효용성은 사용자에 따라 다를 수 있는데, 각 태그가 지정된 업무 항목들은 동일한 사전 조건 요소를 공유하고 있다는 점에서 관리 대상에 지정된 사전 조건들이 유사한 사항들과 비교되면서 태그 지정의 적절성을 검토할 수 있다.

GTD 시스템에서의 컨텍스트가 가지는 의미에서 태그의 활용성은 전체 시스템의 운용성과 신뢰성을 유지할 수 있는 요소라는 점에서 활용을 위한 관심과 노력이 필요한 부분이다. 하지만 GTD 시스템의 운용 방식이나 적용 사안에 따라 태그의 범위나 구조가 제각기일 수 있다는 점에서 일률적으로 특정한 태그 구조나 적용 방식 그리고 분류를-비록 참고는 가능할 수 있지만-그대로 따라 한다는 것은 시스템 운용에 심각한 피로감을 초래할 수 있다. 물론 다양한 사용자의 태그 사용과 구조의 효율성을 참고하여 자신에게 맞는 최적의 태그 구성과 구조를 개발하는 것도 나쁜 방법이라 할 수는 없지만, 강조했듯 GTD 시스템을 완벽한 체계로 전제하고 운용하기란 불가능하기 때문에 태그의 구성과 운용 역시 사용자의 상황에 따라 즉각적인 수정이나 변경이 가능한 대상이다.

• 플래그 지정됨

OF3의 플래그 지정됨 개요는 태그와 같은 구조로 연동된다. 즉 태그의 목록 순서나 구조가 변경하면 플래그 개요의 목록로 함께 변경된다. 물론 반대의 경우도 마찬가지이다. 그런 점에서 플래그 지정됨 개요는 플래그 지정이 많지 않다면 사용 빈도가 적을 수 밖에 없다.

반면 플래그 사용이 많다면 즉 의도적으로 활용을 한다면, 별도로 관리할 수 있는 화면을 제공한다는 점에서 효율적인 활용이 가능하다고 볼 수 있다. 결국 OF3의 사용자가 플래그를 어떤 용도로 사용 하느냐에 따라 그 활용성이 결정된다고 볼 수 있다. 예로 GTD 시스템의 주요 관리 규칙에 비춰 어쩔 수 없이 예외적 관리 대상이나 주의해야 할 업무 항목을 별도로 구분하여 사용하는 용도로 활용할 수 있으며, 또는 GTD 시스템에 관리하는 업무 범위 외적인 요소임에도 별도 프로젝트나 폴더로 구분하여 사용할 수 없는 요소에 플래그를 지정하여 운용할 수도 있을 것이다.

• 검토

마지막 검토 개요는 Reflect 과정의 핵심적인 기능 화면으로 앞서 프로젝트 및 각 업무 항목에 설정된 검토 간격에 따라 정기적으로 점검하는 곳이다. 즉 앞서 프로젝트 개요나 예측 개요 혹은 태그 개용 등이 일상적 즉각적 관리를 위한 용도라면 검토 개요는 일주일이나 3일 등 정해진 간격으로 업무 진행 여부 파악과 수정 등을 전체적으로 검토하는 곳이다.

하지만 각 항목에 설정된 검토 간격이 다르기 때문에 일률적이 아닌 해당 간격에 따라 검토 개요에 나타나는 관리 요소가 다르다. 매일 검토해야 할 대상이 있을 수 있고, 일주일이나 이주일에 한번씩 검토해야할 대상도 있을 것이다. 이런 측면에서 개별 항목의 반복 기간과 헛갈릴 수 있는데, 반복 기간은 기본적으로 반복 업무 항목의 추가적 생성을 위한 것이지만 검토 기간은 정해진 일정 간격 단위로 현재 업무 상태를 보여주는 역할을 한다.

GTD 시스템에서 원칙적으로 개별 업무나 프로젝트의 각 항목의 실행 및 완료 그리고 수정 여부는 Refelect, 리뷰 과정에서 수행하는 것이다. 하지만 현실적으로 하루이틀은 커녕 몇 시간만에 진행 여부를 확인해야 하는 경우도 잦은 것이 일상이다. 사실 그런 개별적인 업무는 GTD 시스템에서 관리될 수 없다. 때문에 일정 관리나 별도의 업무 관리 프로그램이 필요한 것이기도 하다. GTD 시스템은 그러한 개별 업무의 실행 여부 보다는 전체적인 시각으로 프로젝트나 주요한 업무의 실행 및 완료 여부를 관리하기 위한 목적이다. GTD 시스템의 이런 보수적, 폐쇄적 기능 구조는 애초부터 컴퓨터 프로그램 운용을 크게 주요하게 다루지 않은 덕분이라고 할 수 있다.

하지만 현재는 GTD 시스템도 현실적인 필요성을 외면할 수 없기 때문에 새롭게 리뉴얼 되면서 리뷰 과정의 반복 기한에 대한 보수적 시각을 해제 되어, 리뷰 과정을 가능한 자주 진행하도록 권장하고 있는 편이다.

때문에 OF1 시절만해도 현재의 Reflect, 검토 과정은 Review 개요에서만 운용하는 것을 원칙으로 했다고 볼 수 있었지만, OF2와 OF3에서는 구조와 인터페이스가 변경되면서 현재와 같은 구성으로 유지되고 있다. 다시 말해 OF3에서는 일상적 업무 입력과 진행에 대한 관리는 프로젝트와 태그를 중심으로 진행하고, 정기적으로 정해진 간격의 업무들은 검토 화면에서 진행을 관리하는 방식이다.

그리고 OF3의 기능적 관리 구성과 구조를 파악했다면, 이러한 리뷰 즉 검토 기능을 어떻게 자신의 업무와 생활 습관에 맞춰 실질적인 Refelct 과정을 구현하는 가에 대한 운용 측면을 생각해볼 필요가 있다.

OmniFocus 3 안내서 - 3. Organize, 구성

GTD 시스템의 Clarify 과정에 이은 Organize 과정은 구분된 절차일 수도 있지만 통합적 절차이기도 하다. 물리적 대상을 다루는 GTD 시스템이라면 사용자가 수집된 대상에서 대하여 이후 관리 대상으로서 평가하고 구성하는 과정을 절차적이면서도 동시적으로 수행할 수 있다.

하지만 OF3에서 GTD 시스템의 이러한 순차적이면서도 병렬적으로 운용하기 위해서는 명확한 적용과 설정 기준이 필요하다. 물론 OF3를 사용하면서 GTD의 원칙을 지켜려고 무리하게 애를 쓰는 것도 효율적이지 않다. 때문에 가능한한 GTD가 지향하는 바를 이해하고 더불어 자신에 맞춰 활용하는 것이 필요하다. 그리고 이러한 모순적 선택과 적용을 통해 자신에게 가장 적합한 OF3의 최적화가 이뤄질 수 있다. 이를 위해 우선 OF3의 Organize 과정에 적용하고 활용할 수 있는 기능적 사안에 대한 파악이 필요하다.

- - - - -

일단의 Clarify 과정이 완료된 OF3의 수신함에는 본격적인 업무 사항으로 관리될 항목이 남아 있는 상태라 할 수 있다. 참고자료는 별도 공간으로 이전 되었으며, 단순한 일정은 달력에 기록되어 있고 직접 처리할 수 없는 일은 위임 되었거나 별도 공간으로 이전될 준비가 되어 있는 상태이다. 물론 이 과정의 대상들이 별도 프로그램이나 외부로 이동 되었을 수도 있고 OF3의 별도 폴더로 이동했거나 이동을 준비하고 있을 것이다.

Organize 과정을 거치면 업무 항목은 개별 업무 목록이나 해당 프로젝트로 이전되거나 혹은 새로운 프로젝트로 시작되게 된다. 이를 위해 수신함의 남은 항목에 대하여 여러 관리 속성을 지정하고 정리함으로써 수신함은 완전히 비워지게 된다. 이러한 모든 속성 설정 과정은 OF3의 화면 오른쪽에 있는 속성 화면에서 진행할 수 있다. OF3의 속성 설정 화면은 수신함이나 프로젝트 그리고 기타 화면에서 거의 동일하다.

프로젝트, 태그, 마감일 그리고 플래그 설정 등 몇몇 사안은 속성 설정 화면 외 개별 항목에서도 설정할 수도 있다. 만일 상세 지연 시간이나 반복 정보 등은 추후 설정할 계획이라면 속성 설정 화면을 이용하지 않고 수신함 목록에서 주요 속성 지정 후 바로 정리할 수 있다. 하지만 일단 OF3의 속성 설정 화면에서 가능한 필요한 모든 속성을 설정한다는 것으로 보자면,

• 제목

OF3에서 관리되는 각 일, 업무와 프로젝트의 이름을 입력하고 수정할 수 있다. 하지만 각 항목의 제목은 개별 사항 목록에서 직접 수정하는 것이 일반적이다.

언제나 강조하지만 GTD 시스템에서 관리 대상의 제목의 실행과 진행 그리고 평가를 위한 가장 기본적이면서도 주요한 기준이 될 수 있다는 점에서 정기적인 관리 과정에서 항시 상황에 따라 수정할 수 있도록 한다.

• 수신함 항목 / 작업

- 상태: OF3는 각 업무 항목과 프로젝트의 상태를 활성, 보류, 완료 그리고 삭제로 지정할 수 있다.

업무의 상태를 설정하는 속성으로서 수신함에서는 ‘수신함 항목’으로 나타나고 프로젝트나 다른 화면에서는 ‘작업’으로 나타난다. OF3에서는 개별 항목을 마우스 오른쪽 버튼의 상태 메뉴에서 상태를 설정할 수 있기 때문에 일반적으로 Review 과정에서 업무 항목의 상태를 확인하는 용도로 주로 사용될 수 있다.

• 활성 상태가 의미하는 것은 OF3의 정상적인 관리 상탸에 있다는 것을 의미한다.
• 완료는 업무가 완료된 경우로서 입력한 시간이 완료 일자로 기록된다. GTD 시스템에서의 업무 완료는 실행 항목의 성공 혹은 실패에 따른 평가가 아닌 단순히 마무리 자체를 지정하는 것이다.
• 삭제는 업무 관련성이 사라졌거나 업무 자체가 취소된 경우 제거한다. 하지만 단순히 Delete 키를 이용하여 삭제한 경우와 삭제 속성을 통하여 삭제한 경우는 사용자 측면에서 다르지 않지만, OF3는 삭제 속성이 지정된 항목은 시스템에서 제거하지 않고 삭제된 항목으로 저장하게 된다. 즉 모든 항목 보기에서 삭제된 항목으로 나타나게 된다. 즉 OF3가 항목 삭제 전 삭제 여부를 묻는 경우는 영구히 삭제되지만, 삭제 속성이 설정되면 자동으로 삭제 항목으로 저장된다.

그리고 OF3의 완료 및 삭제 속성이 설정된 항목은 ‘파일’ 메뉴에 있는 ’이전 데이터를 아키이드로 이동’ 명령이 수행되면 지정된 날짜 이전의 삭제 항목은 현재의 OF3 데이터이베이스 사라지게 된다.

- 플래그

작업 상태 속성 옆에는 플래그 지정 항목이 있다. OF3에서 플래그를 어떤 용도로 사용하느냐에 따라 다르기 때문에 다양한 용도로 활용할 수 있다. OF3는 프로젝트와 태그 기능을 활용하여 개요 생성 등이 가능하지만 간단하게 즉각적으로 사용활용할 수 있는 요소로는 플래그가 거의 유일하다고 볼 수 있다.

OF3에서도 태그의 주요하게 활용될 수 있다는 점에서 ‘플래그 지정됨’이란 별도의 개요 화면을 기본 환경을 제공하고 있다. 개인적으로 관심을 가져야 할 일이나 혹은 지연되고 일이나 프로젝트 가운데 심각한 수정이나 변경이 요구될 수 있는 일 등에 대한 주의를 하는 용도로 사용할 수도 있다. 그런 점에서 플래그 지정을 남발한 경우에는 그 효과를 기대하기 힘들 수 있다는 있다.

- 프로젝트

해당 업무 항목이 포함될 기존 프로젝트를 지정하거나 지정될 새로운 프로젝트가 생성할 수 있다. 각 항목의 프로젝트를 지정한 후 최종 이동은 Organize 과정의 마무리로서 정리 버튼을 눌러 진행한다.

새로운 프로젝트의 항목으로 구성할 경우에는 프로젝트 이름을 입력 후 Command + Enter를 눌러 생성한다. 만일 업무 항목 자체를 새로운 프로젝트로 구성하고자 한다면, 마우스를 이용하여 직접 프로젝트 개요로 이동할 수 있지만, Organize 과정의 진행이라는 측면과 정확한 프로젝트 제목의 설정이라는 면에서 새로운 프로젝트를 구성하고 개별 항목을 포함시키는 것이 절차적 일관성을 유지함에 있어 더 효과적이다.

• 프로젝트

선택한 항목이 개별 업무 항목이 아닌 여러 업무 항목을 포함하고 있는 프로젝트라면 속성 설정 화면에는 프로젝트 관리를 위한 별도의 화면이 나타난다.

- 프로젝트 상태

프로젝트 상태는 개별 업무 항목과 동일하지만 보류 상태가 추가되어 있다. 즉 프로젝트 자체가 진행 중 혹은 진행 전 중단 혹은 대기 상태인 경우 보류로 속성을 설정할 수 있다.

- 프로젝트 유형

OF3가 제공하는 프로그램 유형은 병렬, 순차적, 그리고 단일 목록으로 구성할 수 있다. 하지만 OF3의 프로젝트는 유형이 고정된 것이 아니라 유형 속성에 따라 자유로이 변경이 가능하다. 그런 점에서 병렬이나 순차적 그리고 단일 목록과 같은 유형에 설정이 집중할 필요는 없다.

OF3의 프로젝트 특징은 각 설정된 프로젝트 유형이 다른 유형의 여러 프로젝트나 업무 목록을 포함할 수 있는 계층적 구조를 지원한다는 점에서 자유도가 매우 높다.

• 병렬 구조의 프로젝트는 프로젝트 내 개별 항목이 모두 동일한 우선 순위을 가지며, 시간 속성에 따라 관리된다.
• 순차적 구조의 프로젝트는 나열된 각 세부 항목의 순서에 따라 실행 우선 순위를 가지기 때문에, 사용 가능 보기 설정에서는 프로젝트 내 최우선 순위 항목만 나타난다.
• 단일 목록의 모든 항목의 계층적 구조를 가지지 않는 각 항목 간의 연관성없는 업무 항목들이 나열되어 있다.

GTD 시스템을 위한 프로그램으로서 OF3의 성공은 프로젝트를 자신의 업무나 일상 환경을 구성하느냐에 따라 달렸다해도 과언이 아닐만큼 높은 유연성을 제공한다. 반면 그런 점에서 계층 구조가 너무 복잡해지면 관리의 어려움이 크다는 점에서 유의해야만 한다.

• 태그

GTD 시스템의 고유한 핵심 철학의 하나라고 할 수 있었던 단일 컨텍스트의 전통을 유지해 오던 OmniFocus가 OF3에서 멀디 태그를 채용한 것은 사용자의 편의성이나 활용성에 있어 우위에 있다는 사실을 인정한 것이다. 그럼에도 GTD가 단일 컨텍스트를 선택한 것은 일의 처리에 있어 우리가 너무 많은 주변 사안에 휩쓸려 정작 핵심적인 요소를 인식하지 못하고 있다는 사실 때문이었다.

하지만 하나의 일에 얽힌 수많은 조건 가운데 핵심 사안을 파악한다는 것은 쉬운 일이 아니다보니 단일 컨텍스트의 신뢰성에 의문을 가질 수 밖에 없다. 결국 이러한 문제의 극복은 예상되는 여러 개의 조건을 모두 관리하는 비효율적이지만 단순하고 효율적인 멀티 컨텍스트를 채용하는 것으로 대응할 수 있다.

때문에 단일 컨텍스트와 마찬가지로 멀티 태그의 설정은 GTD 프로그램로서 OF3에 있어 가장 주요한 기능이라고 할 수 있다. 역시나 태그 사용에 있어 가장 주의할 점은 불필요한 태그를 과하게 사용하지 않은 것이다.

컨텍스트와 마찬가지로 태그 사용에 있어 가장 고민스러운 것이 이미 사용할 주요 태그를 미리 설정하고 가능한한 새로운 태그의 생성의 최소화하는 것에 대한 의견이다. 물론 미리 생성해두고 나중에 필요한 것은 따로 추가하는 현명한 방법이 있겠지만, 현실적으로는 태그에 따른 업무 실행 요건 충족 여부를 관리해야 한다는 측면에서 썩 효율적이지 않다.

OF3의 태그는 프로젝트와 마찬가지로 계층화 구조를 지원하기 때문에 유사한 조건으로 그룹을 만들어 사용할 수도 있지만, 태그의 수나 구조 자체가 복잡해진다는 것은 GTD 시스템의 관리적 효율성을 유지하기 위해 신경쓸 부분이 많다는 것이기도 하다.

• 날짜

OF3에서 있어 프로젝트와 태그가 관리 구조를 구성하는 주요한 사안이라면, 날짜와 시간은 개별적 사안의 실질적 운용과 지속적 관리를 위한 사안이다. 실제 OmniFocus가 업데이트될 수록 날짜와 관련한 속성이 계속 확대되었다.

- 예상 기간

해당 업무나 프로젝트의 실행에 소요되는 시간이다. 물론 프로젝트의 전체 기간을 입력할 수도 있겠지만 하루 이상의 시간은 모두 시간 단위로 표시된다는 것에 개발 업무 사항의 관리를 위한 요소임을 알 수 있다.

GTD 시스템에서 개별 업무 항목에 소요되는 시간은 일상의 짜투리 시간을 활용하기 위한 요소라 사용된다. 이는 iOS 기반 OmniFocus를 이용할 때 매우 효과적임을 알 수 있다.

- 지연 기한

지연 기한이라는 애매한 이름으로 표시되어 있지만 개별 업무 항목(혹은 프로젝트)의 실행 개시 시간이다. OF3의 ‘사용 가능’ 화면 표시에서는 지연 기한이 현재 시간이 될 때까지 나타나지 않게 된다. 즉 지연 기한에 설정한 시간이 되어야 OF3의 실행 항목으로 나타나 실행 대상이 된다는 점은 GTD 시스템에서 매우 주요한 기능 요소라고 할 수 있다.

시간 정보를 직접 수정할 수도 있지만 속성 설절에서 일, 주 그리고 월 단위로 연장할 수 있다.

- 만료

지연 시간에서 시작한 업무 항목의 마감 시간으로 OF3의 모든 관리 기능 화면에서 업무 완료를 위한 기준 정보로 사용된다. 실제 업무의 실행과 완료를 위한 핵심 관리 요소이며, 만료 기한을 넘기면 지연 상태로 전락하게 되고 경고 색상으로 나타난다.

지연 기한과 마찬가지로 직접 수정 하거나 속성 설정에서 일, 주 그리고 월 단위로 연장할 수 있다.

- 부동 시간대 사용

macOS의 현재 시간 정보를 이용하여 해당 업무 지역의 시간에 맟춰 항목의 지연 및 완료 시간이 자동으로 변경되길 원하는 경우 부둥 시간대 사용 기능을 사용할 수 있다.

- 완료됨

OF3에서 업무가 완료된 지정된 일자가 저장된다. 일반적으로 직접 입력하거나 수정할 경우는 없다.

- 삭제됨

OF3의 항목이 삭제된 일자가 저장된다. OF3의 삭제 속성은 사용자가 일상적인 지우는 행위가 아닌 업무 자체의 삭제를 의미하는 것은 사라지는 것이 아니라 OF3에 삭제된 대상으로 저장되게 된다.

단순하게 불필요한 사안의 처리가 아닌 관리적 측면에서 제거된 사항을 의미한다. 즉 Delete 키를 통한 삭제 대상은 단순히 제거되지만 수신함이나 작업 화면에서 삭제로 처리된 항목은 삭제된 관리 저장로 OF3에 저장되어 필요한 경우 내용을 검토할 수 있다.

• 반복

- 반복 간격

OF3의 각 업무 항목 혹은 프로젝트를 분 단위에서 년 단위 간격으로 반복되도록 설정할 수 있다. 단순한 반복 기능의 설정이지만, OF3의 기능적인 요소로 볼때 가장 복잡한 부분이라고 할 수 있다. 일반적으로 반복은 개별 업무 항목에 주로 설정되며, 프로젝트의 경우에는 반복 수행의 대상이 극히 드물다.

분과 시간 단위의 반복은 단순하게 시간 간격으로 설정할 수 있고, 주와 월 단위 반복은 주중 해당 일 혹은 월중 해당 일을 지정할 수 있으며, 또한 특정 날짜 뿐 아니라 순차적으로 지정할 수도 있다.

- 이 항목에 반복

OF3의 반복 항목은 ‘지정 날짜’ 기준과 ‘만료’ 기준으로 구분하여 설정할 수 있다. 이 두 기준의 공통점은 일단 하나의 항목이 완료되어야 다음 항목으로 진행되는 것이다.

하지만 지정 날짜의 경우는 이전 항목의 완료 날짜 여부와 상관없이 순차적으로 지정된-다음 반복 날자의-항목이 나타되는 반면, 만료 기준의 경우에는 이전 항목이 완료 날짜, 즉 만료된 날짜가 기준 날짜 이후의 가능한 반복 항목이 나타난다.

즉 지정 날짜의 경우, 오후 1 시에 시작하여 15분 단위로 1 시간 내 네 번 반복되는 일이 있다면, 만일 오후 1시 20분에 첫번째 일을 완료했다면 두번째 즉 오후 1시 15분에 해야할 일이 실행 목록에 나타난다.

하지만 만료 기준의 경우에는 앞서와 동일하게 오후 1시 20분에 첫번째 일을 완료 했다면, 두번째 1시 15분에 해야할 일의 실행 시간이 이미 지났기 때문에 오후 1시 20분 이후 실행 가능한 다음의 일 즉 오후 1시 30분의 일이 실행목록 나타나게 된다. 다시 말해 두번째 반복 항목 1시 15분에 해야하는 일은 사라지게 된다.

만일 반복 구간이 업무 항목의 전체 기간을 일 단위로 넘어 가는 경우, 완료 요건 기준 설정에 대한 다음 업무 시작 시간을 최초 지연 날짜로 할지 혹은 만료 날짜로 할지 설정할 수도 있다.

• 알림

업무 항목에 대해 설정된 다음 지연 기한과 만료 속성을 기준으로 현재 상황의 업무에 대한 알림 정보가 표시된다. 즉 계획한 일의 시간과 완료가 얼마나 지연되었는 가를 확인할 수 있다. 당연히 지연 기한이나 만료 속성이 설정되지 않은 경우에는 알림 정보가 없다.

- 알림추가

macOS의 알림 기능과 연동하여 OF3의 만료 항목에 대하여 사전 알림 기능을 적용할 수 있다. 1 시간 단위로 지정할 수도 있고 사용자가 지정한 날짜와 시간을 지정할 수도 있다.

• 검토

검토 속성은 프로젝트에 지정되는 GTD의 다음 단계인 Reflect, 리뷰 과정에 사용되는 핵심 사안으로 OF3의 각 프로젝트에 대한 정기적-반복적-검토 기간을 설정한다. 개별 항목들은 단일 목록이라는 프로젝트의 검토 기간을 기준으로 관리될 수 있다.

단 검토의 대상이 되는 프로젝트는 계층 구조의 최상위 프로젝트에만 해당되며 하나의 프로젝트 내의 계층화된 하부 프로젝트에는 나타나지 않는다.

- 다음 검토

아래 검토 간격을 기준으로 다음 번 검토 날짜가 나타난다. 사용자가 직접 다음 번 검토 날짜를 입력할 수도 있다.

- 검토 간격

정기적 검토 간격을 일, 주, 월 그리고 년 단위로 설정할 수 있다. 아래에는 이전 검토 마지막 검토 되었던 일자가 나타난다.

• 메모

OF3의 항목에 대한 메모 입력 사안이 나타나는 영역으로 필요한 참고 사안이나 참고 파일을 링크할 수도 있다.

정리

OF3의 Organize 과정의 최종 마무리는 이 모든 것이 완료되어 관리 체계로 이전하는 것이다.

정리 버튼을 누르면 프로젝트와 태그 혹은 둘 중 하나가 지정된 모든 항목은 해당 프로젝트나 목록으로 이동되다.

이상과 같이 OF3의 Organize 과정은 Clarify에서 기본적 분류를 마친 실질적 일로서 관리 대상에 대한 프로젝트, 태그 그리고 날짜 정보를 입력하는 과정을 수행하게 된다. Organize 과정 이후에는 GTD의 핵심 관리 과정인 Reflect, 리뷰 과정을 진행하게 된다.

OmniFocus 3 안내서 - 2. Clarify, 평가

GTD 시스템의 구축과 운영의 기본이자 핵심이라고 주목받는 Capture(수집) 과정에 이어 진행하는 두번 째 단계가 Clarify(평가) 과정이다. 이전 GTD 시스템 절차에서는 Process라는 이름으로 표기되었지만, 현재 보다 명확하게 Clarify로 명명된 것으로 보인다.

Clarify 과정의 수행에 앞서 유의할 점은, 여러 GTD 프로그램에서-특히 OF3의 경우도-Clarify 과정과 다음 Organize 과정이 단계적 구분을 명확하게 나눠 수행하기 어렵다는 것이다. 그러므로 Clarify 단계의 목적이 수신함에 수집된 대상 가운데-GTD 시스템에서 관리되어야 할-일로서 평가된 대상을 다음 과정으로 이전하는 것이긴 하지만, OF3에서 이 과정을 이후 과정과 구분하여 진행할 것인지 혹은 통합하여 진행할 것인지에 대한 고민이 필요할 수도 있다. 그런 점에서 Clarify 과정과 Organize 과정은 OF3 사용자가 지향하는 GTD 시스템의 운용 방향에 따라 선택되어 질 수 있다.

그렇더라도 OF3의 기능적 구분이 아닌 GTD 프로그램으로서의 관리적 측면에서 구분할만한 필요성과 효용성은 충분하다고 보기 때문에, 일단 구분하여 적고자 한다. 그리고 이전 포스팅에서 따로 언급했지만 Clarify 과정과 Organize 과정 그리고 이후 GTD 시스템 운용 과정을 빠른 시간 내 정확하게 진행하기 위해서는 먼저 현재 진행 중이거나 앞으로 계획 중인 일과 프로젝트를 평가하기 위한 명확한 기준이 필요하다.

Clarfy 과정은 GTD 시스템에서 수집된 일을 사용자의 관리 기준에 의해 평가하여 관리될 만한 그리고 관리될 가치가 있는 일을 골라내는 것이다. 즉 주변의 많은 일 가운데 모든 것이 굳이 OF3에서 입력하여 관리될 필요는 없다. 이에 대한 결정이 사용자의 몫이긴 하지만 사용자 스스로 자신의 일상이나 업무에 대한 명확한-비록 자주 바뀔 수 있더라도-판단을 할 수 있어야 한다.

OF3에서 Clarify 과정은 GTD 시스템에서 관리될만한 일인지의 구분 그리고 새로운 관리 항목인지 혹은 기존 관리 항목과 연관된 항목인지에 대한 기본적 구분을 위한 평가를 한다. 즉 이런 평가 기준에 따라 수집된 수 많은 대상들이 삭제되거나 OF3를 벗어나 다른 관리 시스템으로 이전될 수도 있다.

- - - - -

먼저 OF3의 수신함에 수집된 각 항목에 대하여 일, 즉 실행 가능한 대상인지 또는 그 대상이 향후 실행 가능한 요소를 필요로 하는 지를 평가한다. 이 과정은 사용자에 따라 실행 가능한 대상을 먼저 선택하는 경우와 반대로 실행 불가능한 대상을 먼저 선택하여 버리는 경우로 구분할 수 있는데, 개인적으로 후자를 적극 선호한다.

평가 대상에 대한 명확한 실행 요소가 즉각적으로 떠오르지 않는다면, 실행 불가능한 대상으로서 버려질 것인지 혹은 참고자료로 보관할 것인지를 역시 즉각적으로 판단한다. 물론 즉각적이란 표현은 시간적 기준을 말하는 것이 아니라 내용적으로 절차적으로 후속 과정이 머리 속에 그려지느냐에 관한 것이다. 때문에 그런 사항이 불명확하다면 즉시 삭제한다. 만일 주요한 사안을 실수로 삭제될까 걱정할 염려는 없다. 정말 주요한 사안이라면 곧 자신의 실수를 깨닫게 된다.

1. OF3의 수신함에서 선택한 평가 대상이 실행 할 수 없는 혹은 실행 여부가 불명확한 사안이라면 즉시 다음의 각 조치 가운데 하나를 결정한다.

• 즉시 삭제(Delete) - OF3는 기본적으로 별도의 휴지통 기능이 없기 때문에 삭제된 항목이 따로 보관되는 영역, 즉 휴지통이 없다. 하지만 삭제된 대상은 화면에서 보여지지 않을 뿐 해당 폴더에 삭제된 채로 그대로 남아 있다. OF3의 모든 항목 보기를 하면 삭제된 대상이 최종 위치했던 곳에 그대로 나타난다.
• 참고 자료(Reference) 이동 - 실행이 요구되는 일은 아니지만 내용적으로 현재 혹은 향후 활용성이 있는 자료로 평가된다면, 별도 보관 장소로 이동한다. OF3에 이를 위한 폴더를 생성하여 관리하거나 컴퓨터 시스템의 다른 폴더나 별도의 관리 프로그램을 사용할 수도 있다.
  • 만일 OF3에 참고 자료로 폴더를 만들고 관련된 자료에 태그 등을 지정하여 관리하고자 하면, 이동 과정은 Clarify 단계에서 진행할 지 혹은 다음 Organize 단계에서 진행할 지 결정할 필요가 있다. 다른 외부 관리 프로그램으로 이동할 경우에는 Clarify 단계에서 바로 해당 프로그램으로 이동하는 것이 좋다. OF3에서 참고 자료로 평가된 경우에도, 일단 수신함을 벗어나 별도 폴더로 옮길 수 있도록 한다. 마찬가지로 태그를 이용하여 참고 자료로 구분할 경우에도 Reference와 같은 태그를 지정한 후 별도 폴더로 옮기는 것이 좋다. 그렇지 않으면 Clarify 단계를 마치고 다음 Organize 단계를 기다리고 있는 업무 관리 항목과 함께 처리해야 하지만 쉽지 않은 방법이다.
  • 더불어 미래 활용성을 기대하고 참고자료로 관리(보관) 되지만, 현실적으로 외부의 시야에서 벗어난 곳으로 옮겨지고 나면 효용성은 크게 낮아질 수 있다는 점을 항상 염두에 두어야 한다. 일부러 찾으려 애를 쓰지 않으면-존재한다는 것을 알면서도-관심과 노력에서 멀어질 수 밖에 없다. 때문에 정기적으로 보관함을 점검하여 일정 기간 활용되지 않은 자료는 유지 여부를 검토해야 한다. 물리적 대상이라면 그 심각성을 쉽게 인식하여 조치를 취하는 등의 대응이 훨씬 수월하지만 컴퓨터 시스템에서는 그런 기대가 유지되기 힘들뿐더러, OF3와 같은 프로그램은 전체 컴퓨터 시스템 운영 환경 측면에서도 골치거리로 전락할 수 있다.
• 대기 목록(Incubate/Someday) 이동 - 즉시 삭제를 결정하기 모호하거나 참고 자료로 보관할 필요성도 모호하며 그리고 일로서 관리될 가능성도 있지만, 아직 여타 조건이 명확하게 드러나지 않아 일로서 실행 내용이나 목적이 명확하지 않으나 상대적으로 중요성이 있는 대상을 일단 옮겨 향후 재검토할 수 있도록 한다. 대기 목록 대상은 내용에 따라 대략 두 가지로 구분한다.
  • 특정 날짜가 되어야 실행 여부가 결정 되는 대상 - 해당 날짜에 대상을 재평가하여 실행 항목으로 이전 여부를 확인할 수 있도록 날짜로 지정한다. OF3의 별도 폴더나 달력 등에 기록한다.
  • 향후 실행 가능성을 검토할 주요 대상 - 정해진 날짜가 없기 때문에 실행 항목으로 이전 평가를 정기적으로 점검한다. 하지만 사전에 정한 일정 점검 횟수나 기간이 지난 대상이라면 삭제한다.

이상과 같은 실행 항목이 아닌 대상의 관리에서 주의해야 할 것은 참고자료 폴더나 대기 목록을 평가하기 모호한 즉 이도저도 아닌 애매한 대상을 임시로 저장하는 곳으로 사용해서는 안된다는 것이다. 가능하면 참고 자료나 대기 목록으로 이동 역시 냉정하게 평가하여, 막연한 기대나 희망 보다는 현실적 활용성을 기준으로 OF3를 운용할 필요가 있다.

2. OF3의 수신함에 있는 대상에 대한 삭제 등 비 실행 요소로서의 평가가 끝나면, 다음과 같은 몇 가지의 실행 가능한 대상만 남아 있다. 우선 즉시 실행 가능한 대상이라고 평가된 항목은 바로 실행하도록 한다. 그리고 실행을 위한 준비나 조건에 충족되어야 할 수 있는 일은 OF3의 관리 체계로 이전되어 단일 항목인지 혹은 프로젝트 관련 항목인지에 따라 구분되어 저장된다. 프로젝트는 GTD 관리 체계에 있어 매우 주요한 구조로서 여러 일들이 연결되어 하나의 일이 완료된 이어진 다음 실행 항목(Next Action)이 순차적 혹은 병령적으로 대기하고 있다. 실제 OF3의 효율적 활용은 프로젝트의 구조와 구성을 어떻게 하느냐에 따라 결정된다고 해도 과언이 아니다.

단일 실행 목록이나 프로젝트로 이전 혹은 신규 프로젝트 생성 과정에서 주요하게 생각해야 한 사안은, 실행 목록 혹은 프로젝트 요소는 분명하지만 실행 결과에 대한 성공적 완료나 실패에 따른 대응이 불필요한 실행 항목은 OF3에서 관리될 수 필요가 없다는 것이다. 예로 특정 날짜외 시간에 친구들과 식사를 참석하거나 영화를 보는 사안이 있다면, 오고 가고 그리고 모임을 위한 여러 준비가 필요할 수 있지만 모임의 참석 여부 혹은 참석에 따른 결과가 현재 진행중인 업무와 관계없다면 굳이 OF3에서 관리되어야만 할 사항이 아니라는 것이다. 이러한 약속은 책상 위 달력이나 달력 프로그램에서 관리하는 것으로 충분하다. 다행스럽게도 OmniFocus 2 이후부터는 macOS(Mac OS X)의 달력에 기록된 일정을 예측 화면에서 확인할 수 있기 때문에 달력을 보지 못해 약속 시간을 놓칠 염려는 없다.

• 즉시 실행(Do It) - 후속 실행 항목, 즉 행동이 필요치 않으면서도 즉시 처리가 가능한 일은 바로 실행하고 수신함에서 완료 표시로 마무리 한다. GTD 시스템에서는 약 2 분 정도의 짧은 완료가 가능하다면, 즉시 실행이 가능한 일은 별도의 관리 체계로 이전하지 말고 바로 처리하라고 권장하고 있다. 물론 2 분이란 짧은 시간을 의미하는 예의 기준이며 실제로는 사용자마다 그리고 상황에 따라 다르지만, 3분 이상을 초과하지 않는 것이 좋다. 만일 즉시 실행 시간을 5분 정도로 했다면, 수집 대상이 많을 경우 전체 Clarify 과정이 오래 걸릴뿐 아니라 실제 실행 시간이 5분 이상을 초과할 가능성이 매우 크다. 5분 이상 지속되는 일은 중단하거나 지속하기를 결정하기 매우 모호한 상태를 만들 수 있다.
• 위임(Delegate) 항목 - 실행과 그에 따른 기대한 결과가 요구되는 일이지만 자신이 할 수 없거나 혹은 다른 사람이 하고 있는 일로서 그 결과만을 확인해야 하는 경우라면 해당 조건에 부합되는 사람이나 다른 팀에게 일을 위임하거나 위임된 일의 실행 결과를 기다리면서 결과에 따른 다음 실행 항목을 준비한다. 문제는 OF3에서는 위임된 일의 경우 일반적 점검 항목이 아니기 때문에 관리 단계에서 정기적으로 점검해야만 한다. 위임된 일에 대한 관리는 별도의 위임 목록을 생성하거나 또는 현재 프로젝트 내에서 태그를 이용하여 관리할 수도 있다.
  • 이미 위임된 일이라면 위임 폴더로 이동하거나 위엄 태그를 설정하면 되지만, 즉시 실행 항목과 마찬가지로 짧은 시간에 위임 처리를 할 수 있는 일은 전화나 E-메일 혹은 다른 소통 체계를 통하여 가능하면 바로 진행할 수 있도록 노력할 필요도 있다.
  • 위임된 업무는 그 결과의 확인 여부 방식에 따라 사용자가 직접 확인해야 하는 사안과 결과가 사용자에게 통보되는 사안으로 구분할 수 있는데, 전자의 경우는 단순히 위임 폴더나 태그 지정 후 정기적인 검토가 필요한 반면 후자의 경우는 정기적 검토가 필요 없는 것은 아니지만 결과의 통보가 정상적 업무 처리 과정이라는 점에서 단순한 위임과는 구별되어 관리될 필요도 있다. 예로 전자 Delegate 태그로 지정하여 별도 항목으로 관리할 수도 있고, 후자는 Waiting 태그로 구분하여 현재 진행 항목으로 관리할 수도 있다.
• 지연(Defer) 항목 - 실행 항목은 분명하지만 아직 특정 실행 날짜가 결정되지 않았거나 사전 요건이 충족되지 않아 본의 아니게 지연 되고 있는 항목이다. 지연 항목이 대기 목록의 대상과 다른 점은 이미 실행 여부 및 요소가 결정되어 있기 때문에 상대적으로 시간 제한 없이 기다릴 자격을 가지고 있다는 것이다. 즉 앞서 대기 항목과 다른 점은 별도의 공간으로 이전하는 것이 아니라 현재 진행중인 업무 목록과 프로젝트로 이동 된다는 점에서 큰 차이가 있다. 단순하게 보자면 잠시 실행이 보류된 상태일 뿐이며 곧 개시가 가능한 상태가 유지되고 있는 것이다.
  • 만일 실행 가능 일이지만 명확한 사전 조건은 없고 결과에 대한 기대 역시 주요하지 않은, 즉 앞서 언급한 친구와의 식사 약속 등과 같은 실행 항목 역시 Defer 항목으로 관리 한다면, OF3가 아닌 달력 등에 기록될 수 있도록 한다.
• 단일(Single)/프로젝트(Project) 항목 - GTD 시스템의 가장 중요한 관리 항목이면서 OF3에서도 가장 핵심적으로 관리해야 할 요소이다.실행을 위한 날짜와 시간이 명확하면서 현재 진행 중 업무로서의 개별 실행 항목이거나 여러 개의 일로 구성된 프로젝트의 세부 항목으로 평가되는 대상이다. 개별적 업무 항목이라면 개별 목록으로, 진행 중 프로젝트에 관련된 항목이라면 해당 프로젝트로 이동을 될 수 있다.

이상 OF3의 수신함에서 실행 항목으로 다뤄지고 있는 위 네 가지 대상에 대한 평가가 완료되었지만, 아직 OF3의 정리(모든 항목을 해당 위치로 이동) 버튼이 눌러지지 않은 상태이다. 이 정리 버튼은 앞서 평가한 사안에 대한 정확한 분류 및 구성 과정이 완료된 이후 눌러져야 한다. 즉 OF3에서는 수신함에서 Clarify 과정과 Orgazine 과정이 함께 이뤄지게 된다.

- - - - -

참고로 앞서 설명한 내용으로 현재 OF3에서 아래와 같은 디렉토리와 태그 형식으로 구성될 수 있다. 개인적으로 OF3의 태그 항목은 영어를 사용한다. 개인적으로 오랜 OmniFocus 사용 경험에 비춰 컨텍스트로 태그 입력이나 지정이 한글보다 효율적이었기 때문이다. 그리고 OF3의 작업 환경 구성에서 태그를 먼저 설정하기도 하지만, 이런저런 경험에 비춰 볼때 실제 운용을 하면서 필요한 사안마다 생성하는 것이 더 효과적이라고 본다.

* 프로젝트 화면에서의 디렉토리 구성

• Miscellaneous - 단일 목록
• Works - 폴더
  • Project 1 - 순차적 디렉토리
    • 업무 항목 1-1
    • 업무 항목 1-2
  • Project 2 - 순차적 디렉토리
    • 업무 항목 2-1
    • 업무 항목 2-2
• Home - 폴더
  • Project 3 - 병렬 디렉토리
    • 업무 항목 3-1
    • 업무 항목 3-2
    • 업무 항목 3-3
• Personal - 폴더
• Someday(대기) - 단일 목록
• Reference - 단일 목록 ➝ 참고 항목은 별도 프로그램, Devonthink Pro로 이동

        

* 태그 화면에서의 태그 구성

• Home
• Office
• School
• Errand
  • Errand: Contact
  • Errand: Shopping
• Computer
• E-Mail
• Phone
• Car
• Waiting
• Defer(지연)
• Delegated(위임)

OmniFocus 3 안내서 - 관리 구조와 관리 기준의 선택

OmniFocus 3의 수신함이 일거리(정확히는 일거리 후보)로 가득 채워졌다면 다음 과정은 Clarify, 평가 단계의 진행이다. 물론 OF3의 수신함이 물리적 공간이 아니기 때문에 수집 이후의 모든 과정 역시 수신함에서 진행된다. 하지만 이후 단계로 진행 전에 OF3의 원할한 운용을 위해 미리 염두에 두어야 할 사안을 생각해 볼 필요가 있다.

본 포스팅 내용은 OF3에 관한 사안이기도 하지만 전체적인 GTD 시스템의 구축과 운용에 관한 사안이기도 하다. 먼저 간단한 사안부터 적자면, OF3를 GTD 시스템을 운용함에 있어 관리 구조를 어떻게 구축할 것인가에 관한 것이다.

• 관리 구조의 선택

컴퓨터 프로그램으로서 OF3는 계층적 구조를 가진다는 것 외 다른 특별한 관리 구조가 있는 지 의문이 들 수도 있다. 하지만 예로 사용자가-직접 실행해야 하는 일이 아닌-타인에게 위임된 일들을 어떻게 관리할 것인지에 따른 운영 즉 관리 구조에 큰 차이가 난다. 일반적으로 OF3에서는 다음 몇 가지 방법을 적용할 수 있다.

• 풀더 관리 - 예의 위임된 일로 평가 되어 진행 중인 항목을 OF3의 프로젝트 공간에 별도로 작성된 위임 폴더로 이동해서 다른 일과 구분하여 관리하는 방법이 있다. 좀더 과감하게-복잡한-트리 구조의 폴더로 유사 사항들을 관리할 수도 있을 것이다. 그리고 정기적으로 위임 폴더 내의 위힘 사항들의 진행 현황이나 완료 여부를 확인한다. 별도 폴더를 사용하는 구조는 OF3의 일반적 항목과 다른 관리 요소를 구분하여 관리한다는 점에서 효과적이라고 볼 수 있다.

• 태그 관리 - 예의 위임된 일이나 대기 항목을 위한 별도의 폴더를 생성하지 않고, OF3의 일반적 구조의 개별 목록이나 프로젝트 내에 있으면서 ‘위임’ 이라는 태그(혹은 컨텍스트)를 지정하여 다른 항목과 동일한 수준에서 관리하는 것이다. 그리고 OF3의 태그 화면에서 위임 태그 목록에서 위임된 일의 진행을 관리할 수 있다.

• 외부 관리 - 상대적으로 부담이 가는 방법이지만 경우에 따라 위임된 일과 같은 항목들을 OF3에서 직접 관리하지 않고 외부에 별도 목록이나 일정표 혹은 다른 프로그램에서 관리하는 방법도 있다. 이 경우는 협업이 많은 프로젝트 보다는 개별적 위임 사항이 많은 업무가 있다면 더 적합할 수 있다. 특히 업무와 관련되어 외부적 관리가 필요한 경우가 많다면 별도의 관리 프로그램을 운용하는 방법도 나름 효과적이라고 보며, 몇몇 어플리케이션의 OF3와 연동도 가능할 수 있기 때문에 필요와 상황에 따라 충분히 선택할 수 있는 방법이다.

어느 경우를 선택하느냐에 OF3 사용자의 상황과 판단에 따라 다르겠지만, 효율성을 기대하면서 폴더와 태그 등 여러 방법을 조합하여 사용하는 것은 결과적으로 관리 부담이 증가와 함께 GTD 시스템의 일관성 유지에 어려움이 많을 수 있다는 점에서 좋은 방법이 아니라고 본다.

이어서 좀더 복잡하고 심각한 사안을 적자면, OF3의 모든 항목을 평가하고 분류하기 위한 전체적인 업무 관리의 기준과 세부적 프로젝트의 관리 기준을 명확하게 수립하고 이해하는 것이다. 만일 OF3를 일상적 업무 관리나 일정 관리 용도로 사용한다면 이러한 사안에 대한 고민이나 생각은 크게 주요하지 않을 수 있겠지만, GTD 프로그램으로 운용에서는 반드시 사전에 정리해두어야 할 내용이다.

• 관리 기준의 이해와 적용

GTD 시스템에서 수집함에 모인 대상들에 대한 Clarify 및 Organize 과정을 빠른 시간 내 그리고 정확하게 진행하기 위해서는 이러한 평가 과정을 정확하고 신속하게 판단할 수 있는 기준이 필요하다. 그리고 이 기준은 GTD 시스템의 운용을 통하여 사용자가 궁극적으로 얻고자 하는 목적과 개별 프로젝트의 목표에 명확한 인식에 기반한다.

사실 실행이 요구되는 모든 일에-비록 목적과 목표에 대한 인식이 명확함에도-객관적이고 합리적인 평가를 한다는 자체가 쉬운 일이 아는 것은 분명하다. 하물려 그런 기준이 없거나 그 인식이 모호하다면 조금만 애매한 성격의 일도 정확하게 평가 요소를 지정하기란 어려울 수 밖에 없다.

하지만 수신함에서 특정 항목이 가야할 목적지(폴더)나 목에 다른 이름(태그)를 걸고 다른 이들과 섞여 잘못된 곳과 잘못된 일로 처리될 위험에 처하게 되고 더불어 그런 상황을 인식하고 같은 처지의 친구들이 늘어나게 되면 OF3의 신뢰성에 큰 의문을 느끼게 될 수 있다.

단순하게는 볼때 하나의 프로젝트 그리고 하나의 일에는 반드시-우리가 인식하지 못하는 경우도 있긴 하지만-목적과 목표가 존재한다. 일반적으로 일의 실행에 따른 성공적 결과에 대한 기대 혹은 예측이라고 할 수 있다. 개별적인 일들의 집합체인 프로젝트의 목적과 목표는 보다 거창하거나 그 결과에 따른 파장이 상대적으로 클 수도 있다.

OF3를 비롯한 어떤 GTD 프로그램을 사용하더라도 이러한 목적과 목표 나아가 GTD 시스템에서 관리해야 할 범위를 설정해야 하고, 또한 지속적으로 점검할 필요가 있다. 주요한 사항이라고 언제나 우리가 기억하고 인식하고 있다고 생각하지는 않는다. 평범한 단순한 일상의 힘은 우리의 예상대로 훨씬 강력하다.

• 일, 업무의 관리 가치

마지막으로 GTD 시스템에서 일은 실행, 즉 행동을 요구한다. 그러면서도 실행의 결과가 기대한 바대로 이어지도록 관리되어야 한다. 그런 점에서 단순히 실행만이 요구되는 일 혹은 실행하지 못한 경우 발생하는 문제 내지는 대응이 주요하지 않은 항목들은 굳이 OF3에 관리될 필요가 있는 지를 평가할 필요가 있다. 일반적으로 이런 항목은 단일 실행 목록으로 이전될 것이지만, 준비할 사안이 많거나 절차가 요구되는 경우에는 프로젝트로 관리될 수 있다. 하지만 과연 업무적 측면에서 OF3와 같은 GTD 프로그램에서 관리되어야 할 필요는 없다.

예로 친구와의 저녁 식사 약속이 있다면, 이런 일은 달력의 해당 날짜와 시간에 약속을 표기한 후 매일 달력을 확인하는 과정으로 남겨두어도 충분하다. 반면 업무와 관련한 미팅과 식사 일정이라면 단순한 모임에 참석하는 외에 여러 결과에 따른 조치가 필요할 수 있다. 이런 경우라면 OF3의 프로젝트 항목으로 관리될 수 있다.

이러한 측면에서 GTD 시스템을 구축할 때 특히 OF3나 Things와 같은 GTD 프로그램을 사용할 때 관리 구조나 태그 등을 사전에 설정하고 진행하는 것 안정된 시스템 운용에 도움이 될 수 있지만, 적용할 대상이 아직 명확하지 않은 상태에서 필요한 요소들을 사전에 설정하는 것에는 분명 한계가 있다. 때문에 시스템을 운용하기 시작하면서 관리 요소를 정확하고 필요한 만큼 구성하는 것이 효율적이지만, 수집 대상이 많아지게 되면 수집함을 비우는 후속 과정의 진행에 지쳐서 명확한 태그나 폴더 구성에 집중하지 못할 수 있다는 사실도 우려할만한다. 때문에 어느 경우든 하나의 과정은 일순간에 마무리 한다는 과한 욕심을 부르지 않는 것이 더 주요하다고 본다.

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

Things 3.13.14 업데이트

Things 3.13의 업데이트가 위젯 기능과 알림 기능의 적극적 활성화를 위한 의도라고 해야 하나 싶다. 하지만 아이폰이나 애플워치도 아닌 맥에서 위젯 기능이 얼마나 효용성이 있는 지 의문이다.

물론 Things를 더 이상 GTD 프로그램이 부르기 어려울만큼 일상적 업무 목록 관리 프로그램으로 인식되고 있다는 점에서는 충분히 기대했을만한 기능이라고 본다.

애플의 Apple Silicon M1 칩 기반 맥 모델의 출시와 함께 Things 3.13.2가 업데이트 되거나 곧 Big Sur 정식 버전 출시와 함께 Things 3.13.3 업데이트이 진행되었다. Culturedcode도 여러모로 바쁜 듯 하다.

OmniFocus 3.10 업데이트

애플의 macOS Big Sur의 정식 업데이트가 되자마자 OmniFocus 3.10이 업데이트되었다. 특별한 기능 추가 보다는 Apple Silicon M1 칩 기반 Big Sur에 대한 지원이 가능하도록 업데이트되었다는 점에서 역시 애플이 지난 이벤트에서 OmniGroup를 소개한 효과가 있는 듯 하다.

하지만 동시 OmniFocus 3.11 테스트 버전이 동시에 업데이트 되었다는 점에서 단순하게 Big Sur 지원에 맞춰 업데이트 된 것이 보인다.

그리고 Omni Automation의 플러그-인 지원이 좀더 강화되었다고 하는데, 이 기능의 효용성이 의문이라 향후 지원이나 확장이 걱정이기도 하다.

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

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

GTD 실패의 극복 - 수집의 오류 ?

GTD를 접하는 처음 많은 이들이 가장 흥미를 느끼는 점이 자신과 주변의 잡다한 사항을 한 곳에 수집한 후, 이를 평가 및 분류하여 컨텍스트를 부여하여 관리하는 새로운 절차적 방식이다.

그리고 GTD의 단순하면서도 강력한 관리 방식의 핵심이 그 첫 단계인 수집에서 시작된다. 이 단순한 기능이 놀랍게도 그 동안 여러 다양한 시간 관리와 업무 관리 방식들이 관심을 두지 않았다는 점에서 흥미롭다. 하지만 그 효용성 여부와 상관없이-안타깝게도-GTD를 섣부르게 이해한 많은 이들이 착각하면서 가장 많은 실수와 오류를 겪으며 그러면서도 문제를 인식하지 못하는 부분도 바로 수집 단계이다.

GTD의 수집 기능은 자신을 둘러싼 모든 주변 사항을 수집함이라는 물리적, 가상적 공간에 모으는 과정이다. 이 과정을 처음 겪어 보는 사람들이라면 자신 주변에서 이렇게 많은 사안을 있다는 점에 놀라면서 GTD의 매력에 빠지게 된다.

하지만 섣부리게 수집이라는 행위에 집중하다보니 수집 대상과 그 대상의 표현 그리고 구성에 관해서는 불완전하거나 불명확하게 규정한 채로 수집하는 경우가 많다. 사실 수집 과정 자체가 예상 보다 지리하고 힘들다는 점에서 어쩔 수 없이 발생하는 문제이기도 하다. 다른 한편으로는 단순히 모우기 과정이라는 방식으로서 수집 과정을 너무 쉽게 이해한 결과이기도 하다. 사실 수집함을 채울 대상은 일상에서 끊임없다.

물론 이렇게 수집된 대상은 이후 평가와 분류 과정에서 정확하게 구성할 수 있기 때문에 다소 불명확하고 불완전한 표현으로 수집된 대상이 시스템의 전체적 운용에 반드시 문제가 된다고 볼 수는 없다.

하지만 대부분의 GTD 운용자가 일단 수집함으로 들어간 그리고 수집함에서 끄집어 낸 대상에 대한 다시 한번 명확하거나 완전하게 형태로 규정하는 과정을 진행한다고 보기는 어렵다. 아마 99%의 사용자는 그대로 다음 단계로 넘겨 진행하게 된다.

결과적으로 일상의 불안정하고 혼란스러움이 가득한 현실을 개선하고자 도입한 GTD 시스템에, 해소하기 위해 수집된 온갖 대상들이 불안정하고 혼란스러운 채로 모인 후 시스템 내부를 돌아 다니면서 어느 순간부터 망각의 대상이 되고 힘겹게 구축한 GTD 시스템의 관리 체계를 심각하게 위협하는 요소가 되고 만다.

더 심각한 문제는 대부분의 GTD 운용자들은 이러한 상황에 대한 원인을 자연스럽게 자신의 게으름이나 무능이라 오해하거나 GTD 시스템의 현실적 운용성을 비판하게 된다. 그리고 몇 차례 GTD 시스템을 재정비, 재설치 하거나 혹은 현재 사용중인 GTD 플랫폼을 포기하고 새로운 시스템을 적용하고자 한다. 그러나 여전히 같은 문제는 지속되고 같은 상황도 반복된다.

- - - - -

많은 사람들이 GTD의 수집 기능에 관심을 집중한 반면, 업무 및 일상의 관리 체계로서 GTD 시스템이 지금까지 개발된 여타 시간 관리 혹은 업무 관리 체계와 구별되는 것은 핵심 사안인 정기적 관리 단계는 잊어버리거나 너무 작의적으로 운용하고 있다.

관리 단계는 GTD에서 가장 어려운 부분이기도 하고, 특히 소프트웨어로 처리하기 힘들다는 측면에서 현실적으로 완전한 시스템의 구축이 쉽지 않다. GTD 시스템이 가장 비판을 많이 받는 부분 역시 너무 이상적 관리 체계를 지향하고 또한 강요하고 있기 때문이기도 하다. 특히 우리나라와 같은 GTD 업무 처리 방식을 수용하기에는 상당히 괴리감기 크다.

어떠한 경우든 언급한 불안정하고 불완전한 수집 요소들이 이후 단계에서 제대로 관리 되지 않는다면 GTD 시스템에 있어 치명적인 악영향을 미치게 된다. 그리고 이러한 요인들로 인해 GTD 관리 자체가 일이 되어버리는-GTD 시스템 도입 측면에서 보자면-최악의 사태로 이어진다.

사실 시스템이 이 정도 상황이라고 느낀다면 복구는 현실적으로 불가능하다. 또한 더불어 동일한 습관이나 인식으로는 GTD 시스템을 아무리 재설정 혹은 재설치한다고 한들 상황은 반복된다.

그러므로 GTD 시스템을 신뢰할 수 있는 관리 체계로 정비하고 유지하기 위해서는 수집함에서 꺼내어지는 모든 대상을 명확하게 규정하는 과정이 필요하다. 이 과정은 대부분의 대상에 있어 단순할 수도 있는 반면 일부는 상당한 고민을 요할 수도 있다. 그런 일은 이후 평가 과정에서 명확하게 규정할 수 있도록 별도로 표기하여 넘긴다면 이후 과정에서 어렵지 않게 대응할 수 있다.

그런 대응이 어렵다면 GTD의 대기 폴더로 옮기는 것도 이후 대응을 위한 방법이기도 하다. 물론 이 경우에도 반드시 향후 파악이 가능한 표식이 필요하다. 만일 이후 대응이 계속 지연된다면 어쩌면 GTD 시스템에서의 관리 범위를 벗어나 일이라고 볼 수도 있다. 버려지거나 관리 가능하도록 세분화할 수 있도록 한다.

GTD 시스템이 플랭클린 플래너 등 다른 주요한 업무 및 시간 관리 방식과 다른 점은 절대적으로 일, 업무 처리를 위한 용도에 집중할 수 있다는 점이다. 물론 업무적 일과 일상의 구분하기가 모호하다는 점에서 큰 약점이 될 수 있는 것도 분명하지만, 스스로 그러한 구분을 명확하고 냉정하게 무엇보다도 습관적이며 절차적으로 처리할 수 있다면 우리의 일상은 의외로-기대한 바와 같이-평온할 수 있다.

OmniFocus 3.9.2 업데이트

OmniFocus 3.9 업데이트 알림 메시지를 보자 처음 드는 생각은 이제 다음은 OmniFocus 4.0인가 였다. 물론 그 다음은 OmniFocus 3.10이 될 것이다. OmniFocus 1은 1.10까지 업데이트 되었고 OmniFocus 2는 2.12까지 업데이트되었다. 그만큼 현재 OmniFocus의 무언가 딱히 표현하기 힘든 부족함에 대한 기대일 수도 있다.

OmniFocus 3.9의 가장 주된 업데이트는 예전처럼 별도의 트라이얼 버전을 다운로드한 후, 등록 메시지를 보내는 것이 아니라 일단 OmniFocus를 다운로드하여 사용하다가 2주후 결제하지 않으면 중단된다는 것이다. 이전과 뭐가 다른가 싶었는데, OmniGorup 측면에서도 기능적으로 단순한 방법을 선택했다고 공지했다. 단언컨데 뭔가 꿍꿍이가 있는 것이 분명하다. 정말 OmniFocus 4가 나오면 더 이상 Mac 버전만 사용할 수 있는 게 아니고, 모든 플랫폼에서 사용할 수 있지만 꼬박꼬박 월 사용료 내는 구독 방식으로 전환할 것만 같다.

새로 바뀐 방식에서는 다운로드되면 묻고 따지는 것 없이 일단 OmniFocus가 실행되고, 2주후 결제 여부를 제시하게 된다. 물론 기존 사용자는 업데이트 후 바로 결제된 상태로 전환된다.

오랜만에 OmniGroup의 OmniFocus 소개 페이지에 들어가보니 이전과 달리 꽤나 기능적으로 바뀌었다. GTD의 각 단계에 맞춰 OmniFocus가 구동 과정을 체계적으로 보여주고 있는데, 다만 처음보는 사람들은 뭐가 뭔지 혼란스러울 것 같기도 하다.

OmniFocus 3.8 업데이트

OmniFocus가 3.6 업데이트 이후 3.7을 건너 뛰고 3.8로 업데이트되었다. 혹시나 싶어 릴리즈 노트를 확인해 보니 역사나 3.7 업데이트는 없다. 어떤 이유에서인지는 모르겠지만, 기술적 관련 사안을 아닐 듯 하다.

이번 3.8 업데이트에서는 Omni Automation 관련 기능을 핵심을 이루고 있다. Omni Automation은 글자 그대로 Omni Group의 주요 어플리케이션의 자동화 기능을 구현하기 방법을 제공한다. 하지만 Omni Automation의 기능적 효용성을 고민하기 전에 OmniFocus의 현재 또는 미래의 기능적 활용성을 좀더 고민할 상황이 아닌가 싶다.

Omni Automation은 JavaScript로 생성된 이른바 플러그-인 프로그램을 생성하거나 연결하는 기능을 제공한다. 적용될 수 있는 플러그-인 프로그램은 Omni Automation 웹 사이트에서 확인할 수 있다.

하지만 현재 업로드되어 있는 대부분의 프로그램은 솔직히 아직 예제 성격이 강하다는 면이 있지만, 과연 얼마나 효용성이 있을 지는 모르겠다. 아마 OmniGroup는 OmniFocus의 미래를 일정 부분 사용자들에게 위임한 면도 있는 거 아닌지..?

플러그-인을 설치하기 위해서는, 예로 ‘Delete All Unused Tags’ 플러그-인을 사용하고자 하면 다운로드 한후 더블 클릭하여 설치 화면이 나타나고, 설치를 진행하면 OF의 Automaion 메뉴에 해당 플러그인이 나타나면, 플러그-인 메뉴에서 현재 설치된 프로그램을 확인할 수 있다.

기능적으로 본다면 유용할 것인 분명하지만 현실적 활용성은 자체적인 프로그래밍 능력이 있다면 몰라도 대부분의 사용자에게는 큰 의미 없는 기능으로 보이지만, 오늘날 OmniFocus 역시 이러한 여러 개발자들의 작은 기능들이 모여 이뤄진 결과라고 볼때 한편으로는 멋진 플러그-인의 등장이 기대되기도 한다.

OmniFocus 2의 큰 변화에 대비해 OmniFocus 3는 기본 구성에서 크게 달라진 점은 없었지만 세부적인 변화가 계속 추가되고 개선되어 왔다. 그러나 GTD 플랫폼으로서 더 이상 획기적인 기능의 추가를 기대하기 어렵다는 측면에서 거의 한계에 이르렀다고 보인다. 시스템 구성이나 인터페이스 측면에서 어떤 변화가 사용자들의 기대를 충족시킬 수 있을 지 의문이다.

이러한 시각이 OmniFocus 개발 그룹에서도 크게 다르지는 않을 것이다. 그래서 언제부터인가 점점 외부적인 연결이나 웹 기반 어플리케이션 등 다양한 측면에서의 활용성과 확장성 중심으로 업데이트가 진행되고 있다. 하지만 이러한 개선이 GTD 사용자 입장에서는 나쁘다고는 할 수 없지만 특별한 관심을 끌기는 어렵다. 무언가를 새로운 기능을 추가하거나 연결하는 것은 좋은 점이라 할 수 있지만 그럴만한 가치가 있는지는 모르겠다.

Microsoft가 Asian Efficiency 인수한다면 ?

난데없는 이-메일이었다. 마이크로소프트가 GTD 활용이나 어플리케이션 소개와 관련한 가장 활발한-하지만 자그마한-서비스 회사인 Asian Efficiency를 인수했다고 한다. 순간 마이크로소프트에도 어떤 미친 친구가 있구나 싶었다. 하지만 이 느닷없는 메일은 뭔가 싶었다.

그리고 인수에 따른 당연한 결과로서 향후 Asian Efficieny는 이와 관련하여 향후 자신의 제품 소개나 기술적 정보는 마이크로소프트에 한정한다고 한다. 이건 배신이다. 특히 OmniFocus 기반으로 GTD 스타일을 운용하는 입장에서-Asian Efficency는 OmniFocus와 관련한 가장 큰 지원 사이트이니-배신이라 아니할 수 없다. 하지만 마이크로소프트에 뭐가 있지. 요즈음 밀고 있는 To Do 아니면 설마 Outlook으로 ?

그런데 이건 상식적으로 미친 짓이다. 마이크로소프트는 Aisian Efficiency를 인수할 이유는 전혀 없다. 왜냐하면 그냥 OmniFocus 아니 OmniGroup를 인수하면 더 간단하고 깔끔하기 때문이다. 단언컨데 마이크로소프는 OmniFocus는 커녕 Asian Efficieny의 존재도 모르지 않을까 싶다.

하지만 이어지는 문구에서 이 메일의 의도를 짐직할 수 있었다. Asian Efficieny의 모든 고객에서 마이크로소프트의 티-셔츠를 제공한다는 것이다. Asian Efficieny 회원들은 전 세계에 걸쳐 있는데 고작 회비가 얼마라고, 그 배송 비용만해도 Asian Efficiency의 한 해 매출 규모는 넘지 않을까 싶다. 아니면 Dojo 서비스 회원이 내 예상 이상으로 많은 것인가? 더욱이 지금껏 마이크로소프트의 인수와 관련한 이런 행사는 없었는데, 마이크로소프트의 인수가 얼마나 기쁜 일이라고 이런 짓을 벌인단 말인가.

평소 같으면 이런 메일은 그냥 그런가 보다 하고 대충 보고 넘어 갔을 것이지만, 뭔가 이상한 느낌에 아래로 쭈욱 흩어 보았다. 혹시나는 언제나 역시나이다.

다만 보낸 날짜가 4월 1일이 아닌 4월 2일이라는 것은 게으름인가 아니면 다른 꼼수인가. 혹시 OmniFocus를 이용하는 마이크로소프트의 누군가가 이 메일 받고 벌일지 모를 일에 대한 Asian Efficieny의 바램인가?

하지만 만일 정말로 마이크로소프트의 어떤 미친 양반이 GTD에 관심이 있어 Outlook을 OmniFocus로 대체하거나 OmniFocus의 기능과 구조를 사용한다면 어떨까 싶다. 특히 최근 To Do에 대한 마이크로소프트의 관심으로 볼때 불가능한 일은 아닐 것 같은데.. 정말 이 세상에 우연이란 없으니.

잊은 일, 못한 일 그리고 안한 일.. 일의 문제가 아닌데 ?

최근 본의 아니게 모 회사의 사내 업무 처리에 관련하여 직원 관리 문제에 대한 대화를 나누었다. 어떤 일을 하든 혹은 어떤 규모의 조직이든 내부의 모든 이가 서로 간에 완벽하게 만족할 수는 없다. 똑똑하다가 평가 받은 이가 있는 반면 왕따 수준의 취급을 받는 이도 있기 마련이다. 그리고 서로에 대하여 어느 정도 만족과 불만을 공유하고 있다. 하지만 조직의 규모가 작으면 상대적으로 그런 대상에 대한 관심은 더 집중된다. 하긴 조직의 규모가 크면 반응이 더 크다는 점에서 더 치명적이다.

그리고 잠정적으로 내린 결론은 당사자나 관리자나 모두 업무 관리에 대한 체계적 접근이나 검토를 위한 체계가 미비하다는 것이었다. 물론 각자 나름의 업무 관리 도구가 없는 것은 아니라지만, 잦은 예기치 못한 상황 발생에 관리 도구의 운용성은 심각한 영향을 받아 그 역할을 전혀 못하는 경우가 빈번하게 발생한다는 점을 어렵지 않게 파악할 수 있었다.

이러한 상황이 특별하지 않다는 것은 이미 회사의 다른 담당자들이 문제를 모두 인식하고 있다고 점에서 알 수 있었다. 하지만 시간이 지남에 따라 서로 간의 이성적 판단보다는 특히 일이 많거나 힘들어진 상황에서 발생하는 문제에 의해 감성적으로 대응하고 있다는 것이다.

특별한 상황이 아니라는 것은 이런 경우는 언제 어디서나 볼 수 있는 상황이다. 일이 제대로 진행되지 않거나 진행하지 못해 스트레스가 쌓이거나 혹은 스트레스로 인해 일의 진행에 영향을 받는 것, 어느 경우는 결과는 다르지 않을 것 같다. 이런 상황의 반복 문제는 해결하기 위해 당사자는 여러 방법을 찾아보고, 심지어는 직접적으로 관련이 있는 지는 몰라도 심리 상담까지 받는다니 심각하다. 그러나 언급했지만 이런 경우는 실제 일상이다. 정도의 차이라고 볼 수 있지만, 대개는 비슷하다.

솔직히 당사자나 조직에 제대로 된 나름의 가이드를 해주고 싶은 생각이 간절하다. 하지만 과연 판단이 얼마나 제대로 전달되 지 의문이기도 하고, 나의 판단은 나의 판단일 뿐이니 과연 약간의 도움이라도 될지 역시나 의문스럽다.

만일 개인 혹은 조직의 입장에서 서로를 볼 때 상대방에 대한 가치를 인식하지 못하고 있는 상황이라면 어떤 기술적이고 기능적인 조치를 통한 변화를 기대하기란 어렵다.

업무나 관계로 인한 스트레스에 힘들어 하는 이들이 뭔가 특별히 기술적인 방법으로 통해 상황을 극복하거나 상태를 바꿔보려고 하지만, 이러한 접근은 문제 내지는 문제의 원인을 해결하지 못할 뿐더러 문제 자체나 원인을 파악하지도 못하다. 때문에 이런 상황에 대한 질문을 받고 나름 대답을 주는 입장에서도 곤란함이 없지 않다.

그러니 어찌해야 하나.. 듣고 흘려 보낼 수 밖에 없는 심정을. 아마 그 당사자가 겪고 있는 일과 상황으로 볼때 결국 시간 문제인 것 같다.

Things 3.12.5 업데이트

Apple Watch와 관련된 기능이 업데이트되면서 Mac을 위한 Things 3.12 업데이트가 진행되었다. 사실 Apple Watch를 사용하지 않고 향후 사용할 계획도 없는 관계로-사실 iPhone과 iPad 만으로도 벅차기 때문에-딱히 관심을 가질만한 내용은 없다.

그런데 의외로 전혀 그럴 것 같지않은 이들도 Apple Watch를 차고 있는 모습을 많이 본다. 과연 이들은 Apple Watch를 어떤 식으로 활용하는 지 궁금하다.

사실 Apple Watch와 관련된 기능 업데이트라면 굳이 내용을 보지 않더라도 Things Cloud를 통한 동기화 기능 개선인 것이 분명하다. 이전 iPhone과 Apple Watch의 동기화 기능를 통한 Things 정보 동기화가 이번 업데이트에서는 Apple Watch에서 직접 Things Cloud와 동기화된다.

Apple Watch를 가진 대부분은 iPhone이 있다고 가정할 때 업데이트된 동기화 기능이 Apple Watch 입장에서는 분명 좋은 소식이지만 GTD 플랫폼으로서는 특별한 감흥을 느낄 수 있을 지 모르겠다. Apple Watch로 Things나 OmniFocus를 함께 운용하는 분들이 의견을 알려주면 좋을 것 같다.

OmniFocus 3.6.4 업데이트

OmniFocus 3.6의 갑작스러운 등장과 함께 데이터베이스 이전이 진행되었다. 릴리즈 노트에는 시간대(타임존) 변경에 따른 조치라고 언급되어 있는데, 이런 류의 기능이라면 위치 이동이 잦다면 충분히 문제가 될 수 있다고도 생각되기는 한다. 이러한 기능을 OF3에서는 플로팅 타임존(floating time-zone) 항목으로 사용할 수 있게 되었다.

새로운 항목이나 가족 일정 정보가 지정되지 않은 항목에서는 추가적인 플로팅 타임존의 지정이 가능하다. 물론 대부분의 경우에 이 개선된 기능은 필요하지 않을 것 같다.

하지만 GTD 시스템이나 다른 업무 관리 체계에서 이런 기능은 개발자 입장에서 보자면 아주 복잡하고 미세한 작업이라고 본다. OmniFocus의 전체적 기능에 영향을 미친다는 점에서 데이터베이스 등 핵심 기능의 업데이트가 자주 진행될 듯 하다.

Wunderlist.. 드디어 안녕 ?

마침내-예상한 바이지만-Wunderlist가 2020년 5월에 완전한 개발 중단을 공지했다. 거의 3년 넘어 걸렸으니 마이크로소프트에 인수된 것 치곤 생각보다는 길게 가지 않았나 싶다.

이미 To Do에서 Wunderlist의 정보를 가져올 수 있었기 때문에 딱히 문제될 것은 없다. OmniFocus와 Things가 투 톱인 시장에 Wunderlist의 등장으로 새로운 분위기가 일어났지만 결국 사라지게 혹은 대체되기 아쉬운 점도 있다. 제법 오랜 기간 유료 서비스를 이용했기도 하지만 결국 기존 선두를 따라 잡기는 힘들지 않았나 싶고, 그즈음 운좋게 마이크로소프트에 인수된 것이 아닌가 싶다.

마이크로소프트가 Wunderlist를 가져가서 To Do를 어떻게 바꿀까 기대도 되었지만 딱히 눈에 띄게 바뀐 것 없다. 물론 내부적으로 기능 개선이 이뤄진 것은 분명하겠지만, Wunderlist에서 부족했던 무언가를 To Do가 제공하거나 하지는 못했다. Wunderlist와 To Do의 비교 페이지를 보아도 실질적 기능 차이는 없다.

이제 To Do가 얼마나 Wunderlist가 차지했던 자리를 가져올 지가 관건인데, 여전히 OmniFocus나 Things 그리고 Wunderlist의 유료 서비스와 대응할 수 있는 경쟁력은 무료하는 점이다. 마이크로소프트의 Outlook과의 통합은 To Do에 관한 이야기이니 별개로 하고, 결국 Office365에 자연스럽게 연결되지 않을까 생각한다. 누군가에게는 무료일 수도 있고 또 다른 누군가에는 유료일 수도 있는..?

GTD 플랫폼으로서 한때 이름을 떨쳤던 친구가 또 한명 사라지니.. 도대체 요즈음 The Hit List 이 친구는 뭐하나 싶다 ?

OmniFocus 3.5.1 업데이트

OmniFocus 3.5 업데이트가 되면서 다시 눈길을 끄는 기능이 AppleScript 지원이라 할 수 있다. Pro 버전에 국한된 기능이지만 OmniFocus의 AppleScript 지원은 이전 버전부터 지원되던 고급 기능이다. AppleScripr는 Mac OS X가 제공하는 운영체제 단위의 스크립트 기능으로 운영체제 및 어프리케이션에서 부족한 기능이나 추가적인 매크로 등의 기능을 수행할 수 있도록 해준다.

하지만 OmniFocus Pro 버전을 사용하는 경우에도 AppleScript 활용은 크지 않을 것이라 보인다. OmniFocos 등의 GTD 시스템이란 것이 일상적으로 늘 운용하는 경우를 위한 아니기 때문이다. 반면 일상에서 자주 반복되는 절차를 자동화해서 사용한다면 운용 생산성은 크게 향상될 수 있다.

OmniFocus 3의 메이저 업데이트를 하면서 AppleScript 기능을 강조하는 것을 보면 OmniGroup에서도 OmniFocus의 활용도가 점점 정형화되어 가는 분위기를 바꿔 보려고 하는 것이 아닌가 싶다. Things 등 유사한 GTD 시스템을 위한 어플리케이션의 상황도 시간이 지날 수록 일정 관리나 업무 관리 스타일로 왜곡되어 가지 않나 싶다.

사실 AppleScript는 Mac OS X 기반 어플리케이션에서 모두 활용이 가능하지만 의식적으로 사용하지 않으면 거의 사용되지 않는다. Mac OS X 뿐만 아니라 거의 모든 운영체제에서 이런 기능은 대개 비슷한 처지라고 볼 수 있다. 그래서 이제 좀더 의식적으로 AppleScript의 활용을 진행해볼까 싶다.

시간 관리.. 시간은 언제나 부족하다

나름 스스로 만족스러운 삶을 살고 있다고-아무리 생각해도 이들 대부분이 타인에 의해 평가 받고 싶은 심정을 대놓고 드러내지 않고 있지만-그런 생각을 하는 이들이 다들 한마디 하는 것이 시간 관리에 관한-지도력 섞인-의견이자 충고이다. 그리고 결론은 자신은 나름 성공적인 시간을 하고 있고 덕분에 나름 성공한 삶을 지속하고 있다는 것이다. 나 역시 부하 직원들이나 어린 학생들에게 이런 조언이나 충고하는 시간을 소중하게 생각했는데, 다 쓸데없는 꼰대 짓의 전형이다. 어차피 같은 시간, 같은 장소, 그리고 같은 위치에 있는 이들 조차 처지가 다르다. 결국 자신의 경험에 얻은 가치있는 결론은 타인에겐 잘해야 스쳐 지나가는 참고일 뿐이다.

동서고금을 통털어 시간은 금이라는 명언이 전해져 왔다. 정말 명언이라 하지 않을 수 없다. 하지만 반대로 결코 금은 시간이 될 수 없다. 그럼에도 많은 이들이 돈을 통해 시간을 확보할 수 있다고, 즉 시간을 절약할 수 있다고 생각한다. 만일 금으로 얻어진 시간이 있더라도 원래 주어진 시간 만큼 가치있게 생각하지 않을뿐더러 그렇게 활용 되지도 않는다. 삶에 주어진 시간 조차 제대로 가치 있게 쓰지 못하는 삶에서 덤으로 얻어진 시간이 주는 가치를 기대하기란 어렵다. 그저 자리에 앉아 눈을 감고 멍한 채 앉아 있는 시간이 연장될 뿐이다. 그 시간을 어떻게 사용하는 가는 사람마다 다르겠지만-평균적으로 보자면-그저 주어진 여가 시간일 뿐이다. 그런 시간에 한두 가지 일에 열정을 다했다고 남은 시간도 그렇게 사용되리라 기대한다는 것은 잠시 동안의 자아도취라고 본다.

결국 시간 자체 대해서는 넣거나 빼거나 할 수 없다. 단지 주어진 시간을 관리할 수 있을 뿐이다. 시간 관리라는 학문이 있다면 세부 과목이 많은 종합 학문일 것이라는 점에서 여러 시각과 분야에서 의견이 나올 수 있지만, 가장 오해하는 부분이 특정 활동으로 인해 일상의 시간이 낭비된다는 의견이다.

대표적으로 스마트폰의 사용 그리고 유뷰트나 페이스북 등과 같은 SNS 활동에 너무 많은 시간을 낭비하고 있다는 시각이다. 틀리지 않은 의견이다. 하지만 솔직히 대부분의 사람이 그 시간에 스마트폰을 사용하지 않았다면 다른 생산적인 일이나 해야하는 일을 할 것이라 생각하고 있다면 인간에 대해 크게 오해하고 있다고 생각한다. 그럼 이전에는 생각이 넉넉했다는 말인데, 단지 TV나 라디오 혹은 잡담에 소비한 시간이 다른 기기로 대체되었을 뿐이다.

짜투리 시간이라도 많은 일에 활용할 수 있다고 생각하는 입장에서는 오늘날 스마트 기기에 빠져 있는 시간이 얼마나 아까운 시간인지 충분히 이해할 수 있지만, 사람의 일이란게 일 자체의 중요성과 함께 일을 바라는 입장이 다르고 더욱이 그 시각도 시시각각으로 변한다는 점에서 일률적으로 시간이 남거나 혹은 시간이 확보되면 해야할 일을 할 것이라 기대할 수 없다. 정말 독한 사람, 혹은 그런 입장에 놓인 절박한 상황에서라면 충분히 가능한 일인지도 모른다.

하지만 경험에 의해 능력이 확보된 상태에서는 10%의 노력으로도 90%의 효과를 얻는다는 사실을 체험한 입장에서-어차피 100%의 성과를 확보하기 힘들뿐더러, 그 평가 역시 타인에 의해 주관적으로 결정되기 때문에-해야만 하는 일을 하는 것으로 만족할 뿐이지 완벽하게 하기란 쉽지 않고 그러기도 어렵다. 그러니 함부로 의미없는 일 때문에 정작 해야하는 일을 못한다고 단정할 수는 없다.

그렇다면 우리가 시간이 부족한 혹은 부족하다고 느끼는 이유는, 어이 없는 답일 수도 있지만 원래 그런 것이다. 일이란 끊임없이 생각나기 때문에 시간이란 요소로 일의 기준에서 부족할 수 밖에 없다. 앞서 언급했듯이 다른 가치에 소요되는 시간을 줄여 필요한 부족한 시간을 확보하는 것도 효율적인 방법이긴 하지만, 주어진 시간 자체를 효과적으로 활용하는 방법도 필요히다. 시간이 충분해도 제대로 기대한 성과를 내지 못하는 경우가 허다하고, 부족한 시간임에도 기대 이상의 성과를 달성한 경험은 이미 충분하지 않은가. 그리고 우리 일상에서 이런 상황은 오늘도 계속 반복된다.

그러므로 어떤 경우든 주어진 시간에 최대한 기대한 바가 달성되기를 위해 노력하는 수 밖에 없고, 이를 위해 GTD 시스템을 비롯한 주변의 도움을 적극적으로 활용하기 위한 또 다른 노력을 하게 된다. 그렇더라도 단순히 시간을 줄이는 방법을 위해 외부적 도움이나 비용 지출로 대응할 수는 없다. 즉 다양한 도구를 통하여 시간의 절대적 활용성을 보장 받을 수 없다. 시스템의 운용의 또 다른 개인 역량이 소요되는 부문이기도 하다. 그러므로 끊임없이 새로운 업무 생산성 관리 도구를 탐구하는 것 역시 누군가에는 그야말로 시간 낭비가 될 수 있다.

혹자는 시간관리라는 측면을 단순하게 전체적 소요 시간의 줄이는 것으로 평가한다. 그런 측면에서 보자면 일 하지 않고, 일상의 산책이나 사색의 시간에 시간을 쓰는 것은 정말 의미 없는 시간 낭비가 될 수도 있다. 하지만 우리는 이미 알고 있다. 책상 앞에 앉아 있다고 공부하는 것이 아니고, 앉아 있는 시간에 비례해서 성적이 오르지 않는다는 것을 이미 경험했다.

나의 경우, 바쁜 와중에도 일부러 장을 보거나 산책 동중에 카페에 들른다. 비록 현재 상황에서 시간이 부족한 것이 사실임에도, 그러한 시간이 낭비가 아니라 현재 혹은 미래의 여러 일을 주요하게 정리하는 시간이 되기도 하기 때문이다. 혹은 긴 시간을 내어 여행이나 드라이브를 하기도 한다. 대개 이러한 행동을 재충전이라고 표현하기도 한다. 내게 있어 이러한 과정은 문제를 해결하기 위한 방안의 하나일 뿐이다.

피곤한 업무에서 벗어나-재충전이라고 했듯-여행이나 일상의 탈출이 권장하지만, 여행에서 돌아오면 문제는 여전하다. 그러므로 여행이-종종 그런 경우도 있기는 하지만-문제의 해결책을 주지 않는다. 안타깝지만 여행은 문제를 안고 떠다는 또 다른 일의 연장이다. 다만 다른 환경에서 새로운 시각으로 다른 해결책을 찾는 과정이다. 이런 핑계로 난 가능한 몸을 혹사하는 여행을 자제하는 편이다. 조용한 곳에서 한가한 시간을 가지며 현재 문제에서 잠시 벗어나는 것이 아니라 현재의 해결책과 다른 해결책을 도출하고 비교하는 시간을 진행한다.

우리는 시간이 부족한 이유를 너무 거창하게 세상의 발전과 환경의 변화 차원에서 다룬다. 하지만 그 이유는 간단하다. 우리의 능력이나 협업 관계가 부족하거나 또는 여유를 부리는 것이다. 시간은 언제나 부족했고, 결코 충분한 날은 없을 것이다. 충분한 시간을 즐기는 순간 이미 시간은 부족해진다. 그러니 시간이 부족한 원인을 찾아 개선하기 보다는 지금 당장 주어진 시간을 어떻게 효과적으로 그리고 앞으로 주어질 시간에 효율적으로 대응할 것인지 고민해야 한다.

그런 측면에서 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가 제공하는 기능에 비해 순위권에서 다뤄지지 못하는 가장 큰 이유 중 하나일 것이라 생각한다.