[OmniFocus의 기본 운용] Review, 프로젝트 관리

GTD의 Review 과정은 단순하게 보자면 계획한 일들이 실행하기에 앞서 필요한 조건이나 상황을 수정 및 정리하는 검토 과정이며 또한 진행 중인 업무나 프로젝트가 계획한 대로 잘 되어가고 있는 지를 정기적으로 검토 및 관리하는 단계이다. 그리고 OmniFocus(이하 OF)에서의 Review 단계는 GTD 운용에 있어 핵심적인 역할을 하는 과정일 뿐만 아니라 OF의 절차적 기능의 핵심이다.

 OF와 비교할 때 Things나 Wunderlist 등은 Review 단계에서의 관리를 사용자가 유연하게(구분된 기능이 없다고 볼 수 있기 때문에) 운용할 수도 있지만 대상 업무 일정이 너무 많은 경우 프로젝트 간의 계획과 검토가 혼란스러워 질 수도 있다. 반면 OF와 같이 Review 기능이 규정되어 있는 경우에는 기본적인 기능에 대한 학습이 선행되고 익숙해져야 효율적 관리가 가능하게 된다. 이런 점에서 OF의 Review 기능은 대부분의 사용자에게 있어 상당히 어색하고 이해하기 힘든 절차로 다가올 수도 있다.

 사실 OF를 시작하면서 처음부터 Review 기능을 적절하게 사용하기는 쉽지 않다. 기능적으로 어렵다기 보다는 이해가 잘 되지 않기 때문이다. 특히 일상에서 진행되는 업무의 양이 많은 것도 문제이지만 각 업무 별로 검토할 시간이 너무 짧게 느껴지기 때문에 느긋(?)하게 업무 관리 기간을 정기적으로 가지기도 쉽지 않다. 그리고 계획한 일들은 개 주변의 변화에 휩쓸려 예측과 다른 방향으로 진행되고 결과적으로 언제나 몸과 마음이 지쳐 있다. 하지만 처음에도 의도적으로라도 정기적으로 차분한 상태에서 OF의 Review 기능을 이해하고 시간을 가지고 적응하여 노력이 필요하다.

1. Review 환경 설정

OF의 Review 기능을 수행에 앞서 생각해야 할 것은 사용자가 Review 기간을 얼마 만에-정기적으로-진행할 것인 가에 대한 결정이다. 사실 OF는-물론 GTD에서도-이 과정은 가장 혼란스러운 부분 중 하나인데 이는 현실에서 Review와 일상의(일일) 업무 관리의 방식과 기준이 명확하게 구별하기 어렵기 때문이다. 일상의 업무 관리는 오늘 혹은-조건이 맞는다면-지금해야 할 일의 목록을 확인하고 실행하고 그리고 한 일에 대한 확인 과정이라고 볼 수 있다. 이에 반해 Review 과정은 일주일 혹은 정기적인 기간 동안 계획한(GTD에서 관리 중인) 전체 프로젝트의 진행 여부를 확인하고 문제가 있는 대상을 조정하는 과정이다. 기능적으로 큰 구별은 없다고도 볼 수 있다. 때문에 두 과정에서 실제 겹치는 부분이 많이 발생하게 된다. 굳이 구분하자면 일일 관리는 개별 업무를 중심으로 그리고 Review는 프로젝트 중심으로 진행된다고 볼 수 있지만, 각 과정의 관리 내용이나 범위를 너무 획일적으로 적용할 필요는 없다. 예로 오늘 해야 할 일 과정에서 전체 프로젝트를 수정할 사안이 있다고 이를 반드시 Review 기간까지 미뤄두거나 반대로 Review 과정 중 일일 업무 내용에 대한 검토를 하지 못할 이유는 없다.

 OF의 Review 기간은 Preferences의 Data & Time 설정에서 지정할 수 있다. GTD에서 추천 혹은 권장하는 Review 기간은 딱히 정해진 것은 아니지만 1 주일 내지는 1 주일을 넘지 않도록 하고 있다. 나는 최근에 이런 저런 일이 많아 3 일에 한번 Review 기간을 설정하고 있지만 상황에 따라 적절한 간격이라고 생각되는 기간으로 설정하면 된다. 하지만 Review 기간을 하루나 이틀 정도로 반복하는 것은 앞서 언급한 일일 업무 관리 범위와 중복될 수 있고 이로 인해 계획한 프로젝트에 대한 필요없는 잦은 변경이 가해질 위험도 있다. 그럼에도 OF의 사용자들은 대개 새로운 업무와 프로젝트 구성 후 자주 진행 상황을 검토하고 픈 의지가 생길 수 있다는 것도 사실이다. 무엇보다도 상황에 맞도록 최적의 기간을 설정하고 일관성 있게 유지하는 것도 중요하다.

 그리고 정기적인 점검 기간은 예로 일주일 단위로 설정했다면 금요일 오후나 토요일 오전 등의 효과적일 것이다. 하지만 Review 과정 자체가 너무 길어지지 않도록 15~30분(일주일 간격 기준) 정도를 미리 염두에 둔다. Review 기간이 짧을 수록 Review 과정의 시간도 짧아 지게 된다.

 Review 기간 설정에서 주의할 점은 기본 설정으로 지정된 기간에서 시작된 프로젝트나 개별적으로 Review 기간을 따로 설정한 프로젝트의 경우에는 기본 설정 기간이 바뀌더라도 기존 설정이 그대로 유지된다. 만일 이러한 경우 해당 프로젝트의 Review 기간을 새롭게 설정하고자 하면 Project 화면에서 해당 프로젝트를 선택한 후 한꺼번에 Review 기간을 재설정해 주어야 한다. 때문에 이러한 조건을 이용하여 특정 프로젝트의 Review 기간을 별도로 설정하므로 써 프로젝트 관리에 효욜적으로 이용할 수도 있을 것이다. 예로 장기적인 프로젝트의 경우 Review 기간을 월 단위로 지정할 수도 있을 것이다.

2. Review 작업 수행

Review 단계의 진행은 OmniFocus의 Project, Context 그리고 Review 화면에서 수행하게 된다. Review 화면 뿐만 아니라 Project나 Context 화면도 함께 사용하는 것은 Review 완료 후 전체 계획에 대한 검토에 따라 프로젝트 및 각 업무의 컨텍스트 수정도 함께 진행할 수 있기 때문이다. 따로 컨텍스트 별로 내용을 점검하는 시간을 가지기 쉽지 않으니 Review 수행 시에 여유가 되면 함께 진행할 수 있으면 좋을 것이다. 혹시나 OF의 Review에 대한 무언가 새로운 기대 혹은 오해를 가진 사용자들이 많을 수 있겠지만, 기능적으로 볼 때 OF의 여러 기본 기능과 다를 바 없다.

 OF의 Review 화면에는 지난 Review 완료 후 정해진 Review 시간에 해당되는 프로젝트들이 나타 난다. 그리고 한번도 Review 과정을 거치지 않은 프로젝트들은 계속 드러나게 있게 된다. 왼쪽에는 Review 대상 목록이 오른 쪽에는 해당 프로젝트의 전체 항목들이 나타난다. 기본적으로 Review 대상의 프로젝트는 활성화된 경우만 보여지고, 내부 목록에서도 완료된 일을 제외된다.

 Review 과정은 프로젝트를 보면서 계획대로 진행 중인지를 먼저 확인하고, 개별 항목 중 완료된 일 중 완료 처리가 되지 않은 항목을 먼저 처리 한다. 이어 전체 진행 상황을 고려하면서 각 항목 간의 우선 순위와 항목의 날짜나 컨텍스트 변경 사항이 있는 경우 이를 수정한다. 필요 없게 된 일이나 이름이나 내용이 수정된 경우도 즉시 변경한다. 검토가 완료된 프로젝트는 Review 완료로 처리한다. 혹은 프로젝트 진행 중 문제가 없거나 실행 전 대기 상태로 인해 별 다른 조치가 없는 프로젝트도 마찬가지로 Review 완료로 처리한다. 필요한 경우 프로젝트 자체를 삭제할 수도 있다. 하나의 프로젝트에 대하여 Review가 완료되면 다음 대상의 프로젝트로 진행되게 된다.

 Review 완료는 프로젝트 내용을 나타나는 화면 상단의 오른 쪽에 있는 ‘Mark Reviewed’를 선택하므로 써 목록에서 글자 색상이 옅어지면서 완료 처리가 된다. 같은 위치에는 Review 대상으로 나타난 프로젝트나 업무 목록은 전체 대상 수와 함께 Review 기간, 지난 번 Review 날짜 그리고 다음 Review 날짜가 나타난다. 아래 예에서 Review 간격은 3일이며 이전 Review 일자는 3월 10일 그리고 다음 Review 날짜는 오늘, 3월 13일로 보인다.

 이러한 방식으로 각 프로젝트에 대하여 이상의 과정을 진행하게 되면 전체 Review 과정이 완료되고 ‘All projects reviewd’ 메시지가 나타난다.

3. Review vs. 프로젝트 관리

OF의 Review 작업에서 가장 의문스럽게 생각될 수 있는 점은 전체 프로젝트 관리를 위해 Project 혹은 Context 화면에서 각 프로젝트나 컨텍스트의 업무 내용을 수정하는 것과 별도로 Review을 수행하는 것의 차이에 관한 것일 수 있다. 앞서 일일 업무 관리와 Review 진행의 차이에서 간략히 적었지만 기능적으로 볼 때 전체 프로젝트 관리와 Review 작업 간에도 기능적으로는 큰 차이가 없다.

 하지만 GTD의 목적이 현재 진행중인 업무들과 향후 추진해야 할 업무들로 인해 발생하는 스트레스를 미연에 예방하는 것이라는 점에서, 시간이 날 때 마다 자주 그리고 전체적으로 진행 중이거나 계획한 프로젝트를 검토하고 수정하는 것은 시간적으로 정신적으로 매우 힘든-또 다른-일이며 스트레이스가 될 수 있다. 때문에 프로젝트 관리를 정기적으로 그리고 기계적으로 처리하므로 써 관리 과정에서 발생하는 스트레스와 이로 인한 프로젝트 관리의 오류를 방지할 수 있도록 하기 위해 별도의 Review 작업을 진행한다고 볼 수 있다. 실제로 OF든 다른 어플리케이션에서 별도의 Review 작업이 아닌 단순한 프로젝트 관리나 컨텍스트 점검 등을 진행해보면 상당한 시간이 소요됨은 물론 작업 자체를 종료하기 힘든 경우도 많이 겪게 된다.

 처음에 OF의 Review 기능의 효용성을 느끼지 못한 상당 기간을 사용하지 않았지만 어느 시점 이후 나름 일관성을 가지고 정기적으로 Review 작업을 수행 함에 따라 실제로 프로젝트 관리 시간이 현저하게 줄어들게 되고 또한 프로젝트 자체에 대한 고민이나 걱정도 상당히 적어지게 되었다고 생각된다. 특히 언제나 현재 진행 중인 프로젝트에 대한 점검이 필요한 가에 대해 불안해 하던 경우도 사라지게 되었다.

 프로젝트 관리에서 다룰 내용이기도 하지만 만일 계획한 프로젝트가 현재 제대로 진행되고 있지 않다면 이에 대한 조치가 반드시 필요하다. 그 조치로는 지연되는 프로젝트의 실행 가능성을 다시 높이기 위해 내용을 점검하고 수정하거나 혹은 조건이 만족 될 때까지 일단 대기 상태로 만들어 다음 Review 작업 시 까지 잊어 버린다 등 다양한 방법이 있을 수 있다. 또한 아직 실행 되지 못하거나 지연 되고 있는 프로젝트라도 정기적으로 검토하므로 써 일상에서 갑자기 머리 속으로 들어와 생각을 복잡하게 만드는 일을 현저히 줄일 수 있게 된다.

4. 새로운 프로젝트의 점검

Review 기능의 일반적인 진행 절차에 포함되면서도 약간 차이가 난다고 볼 수 있는 것이 새로 진행하기 위해 추가된 업무나 프로젝트의 관리에 대한 것이다. 원칙적으로 이러한 대상들도 정기적인 Review 절차에 따라 진행하면 되겠지만 새로운 프로젝트의 경우 초기 입력이나 수정 사항이 많기 때문에 또한 진행 상황을 예측하기 어렵다보니 정기적인 Review 시간까지 기다리기 조급할 경우가 많다.

 이러한 경우를 위해 정기적인 Review 단계를 수행할 시점이 아니더라도 즉시 해당 프로젝트를 점검할 수 있도록 한다. 진행 중인 프로젝트와 달리 새로운 프로젝트의 경우 초기에 설정한 내부 업무에 대해 추가되는 사항도 많으며 수정 혹은 삭제되는 사항도 많다는 점에서 빨리 대응하지 못하면 제대로 된 관리가 힘들어 질 수도 있다고 본다. 만일 프로젝트의 내용 자체가 너무 많거나 복잡하면 OF의 Focus 기능을 사용하는 것도 효율적일 수 있다. 이러한 내용은 실제로는 OF의 프로젝트 구성과 관리 측면에서 다시 언급해야 할 사안이기도 하다.

5. iOS 기반 OF의 Review

Review 작업을 iPhone이나 iPad 버전에서도 수행할 수 있다. 기능적으로 iPhone이나 iPad에서의 Review 작업도 Mac OS X에서와 크게 다르지 않다. 그리고 상대적으로 iPad 버전의 OF에서의 작업이 iPhone 보다는 손이 덜 가기 때문에 수월하다. iPhone에서는 프로젝트와 내부 항목을 한번에 볼 수 없기 때문에 상당히 불편할 수 있다. 다만 역시나 프로젝트 내용이나 이름을 수정하는 등의 작업이 실제 마우스와 키보드를 사용하는 것에 비해 불편하다보니 iOS 기반으로만 Review 작업을 진행하는 것에 대해서는 고민할 필요가 있다고 본다.

[OmniFocus의 기본 운용] Process & Organize, 업무 분류 및 조직화

GTD의 절차적 진행 단계로 볼 때 수집 이후는 수집된 대상에 대한 분류와 평가 그리고 조직화(구성) 단계가 이어진다. 절차적으로 분류 및 평가는 이후 조직화와는 별개로 구분되지만 하나의 어플리케이션에서 이를 명확하게 분리하여 개별 기능으로 구현하기는 쉽지 않다. 또한 어느 하나의 단계의 구현에 치중하게 되면 다른 단계는 기능적으로 유명무실해 질 수 있는 다소 경계가 모호한 부분이기도 하다. 때문에 OmniFocus(이하 OF)와 같은 컴퓨터 기반의 어플리케이션들에서는 기능 구현은 GTD의 절차적 단계 진행과 다소 차이가 날 수 있다.

 우선 Porcess 단계의 첫 과정은 GTD의 관리 대상 여부의 판단부터 시작하게 된다. 다시 말해 수집함이나 Inbox의 대상에 대하여 ‘일’로서 ‘관리’해야만 할 대상인지를 평가하는 과정이다. 먼저 ‘일’은 행동과 결과를 모두 수반하는 대상이며 또한 단순하게 행동만 하므로 써 완수되는 간단한 대상이 아닌 나름 조건과 계획을 필요로 하는 수준이어야 한다. 예로 단순히 어느 지점으로 이동한다거나 뻔한 결과가 정해 진 정형화된 행동은 비록 일이지만 GTD에서 관리될 필요성까지는 없다고 본다; 물론 사안 마다 그리고 개인의 생각 마다 경우가 다를 것도 분명하다. 더불어 어렵고 복잡한 일처럼 보이지만 결과나 목표 그리고 목적 등이 명확하지 않거나 하는 대상 역시 GTD에서 모두 관리하기는 무리가 있다고 본다. 마찬가지로 수 년 후 미래의 바램 등과 같은 계획이나 기대 등도 동일한 경우로 볼 수 있다. 떄문에 이러한 일들이 GTD에거 관리되기 위해서는 명확한 일로 명시될 수 있어여 한다. 이러한 기준에서 OF의 수집함의 모인 대상에 대하여 다음과 같은 관리 단계를 적용한다.

1. 대상이 일로 판단되지 않고 참고자료의 필요성도 없다고 판단되면 Inbox에서 삭제한다. OF의 Inbox에서 삭제된 대상들은 별도로 저장되지 않기 때문에 이후 View 설정에서 All을 선택해도 보이지 않는다.
   • 물리적인 대상의 수집 과정에서 본의 아니게 일이나 업무와 무관한 개인적 범위의 대상이 수집되었다면 이는 반드시 GTD 적용과 무관하게 별도로 분류하여 보관한다.
2. 일이 아닌(명확한 행동을 요구하지 않는) 참고자료로 활용될 수 있는 대상은 별도의 관리 폴더로 옮긴다. 레퍼런스를 위한 별도의 그룹 폴더를 사용하거나 @Reference 컨텍스트를 지정할 수 있다. 만일 그 판단이 명확하지 않은 대상이라면 @Someday/Maybe 등과 같은 향후 검토용 컨텍스트를 지정할 수 있다. OF에서 이 두 컨텍스트는 별도로 관리되며 또한 두 경우 모두 직접적인 일로서 관리되지 않으므로 프로젝트를 지정하지 않도록 한다.
3. 기준 시간(2 ~ 5 분) 내에 실행이 가능한 일로 판단되면 즉시 처리한다. 하지만 현실적으로 OF와 같은 어플리케이션의 분류 작업 중간에 처리하기는 쉽지 않을 수 있기 때문에 상황에 따라 판단하도록 한다.
4. 일은 개별 업무 혹은 그리고 진행 중인 프로젝트 내의 업무 그리고 새로운 프로젝트 중의 하나가 된다.
   • 개별 업무나 기존 프로젝트 내의 업무지만 스스로 수행할 수 없거나 타인에 의해 수행되어 내 업무에 영향을 미치는 일이라면 위임 항목으로 별도 관리히다. OF에서는 @Delegated 컨텍스트로 지정할 수 있다.
   • 일 임에도 특정 날짜나 시간에 진행되어야 하는 사안은 별도 관리 체계, 캘린더 시스템에서 관리하도록 한다. 예로 ‘A씨와의 미팅’이라고 적힌 메모지가 있다면 이것은 일이 아닌 일정으로서 달력으로 옮겨져야 한다. 명확한 행동과 목표를 지정할 수 없기 때문이다. 실제 달력에 기입하거나 Mac OS X의 캘린더를 이용한다. OF 2에서는 Forecast 화면이 추가되어 OF의 업무 일정과 함께 Apple Calendar의 항목을 함께 볼 수 있다. 유용한 기능이긴 하지만 시각적 표현은 적절하지 않은 듯 하다.
   • 프로젝트가 아닌 개별 업무나 기존 프로젝트의 업무로 판단되면 해당 프로젝트와 컨텍스트를 지정 한다. OF에서는 프로젝트와 컨텍스트 중 하나 혹은 모두가 지정된 경우처럼 분류 작업의 완료 조건을 지정할 수 있다.
   • 신규 프로젝트로 설정되는 경우에는 이미 존재하는 프로젝트 이름과 너무 유사하지 않도록 정하는 것이 좋다. 또한 다른 프로젝트와 구별될 수 있는 범위에서 가능한한 길지 않게 설정하는 것이 좋다. 프로젝트의 경우 별도로 컨텍스트를 지정하지 않거나 @Project라는 컨텍스트를 지정할 수도 있을 것이다.
5. 추가로 OF의 각 항목에 대한 날짜 및 시간 조건을 입력할 수 있다. 일의 시작, 마감, 진행 및 반복 등과 같은 조건들의 입력은 OF에서 GTD의 Tickler 기능 구현을 위한 관리 요소이다. 만일 시간 조건이 명확하지 않다면 성급하게 지정하기 보다는 이후 Review 과정에서 설정할 수 있도록 한다.
   • OF의 일과 업무에 대한 시간 정보에서 시작 일과 마감 일에 대한 기준을 실제 업무 마감일로 할 것인지 마감을 위한 업무 시작일로 할 것인지에 대한 기준을 정해야 한다. 예로 OF는 Tickler 기능의 수행을 위해 시작일에 해당 대상을 다음 업무 목록으로 올리게 된다. 그러므로 OF에서의 업무 시작은 실제 시작일로 마감일은 해당 업무 자체에 지정된 마감일로 설정할 수 있다. 이때 마감일이 실제 해당 업무의 절대적 마감 기준인지 사용자가 임의로 지정할 수 있는 기준인지에 대해서도 명확해야 한다. 기본적으로 특정 마감일이 지나 업무 수행의 의미가 없어지는 마감일이 아닌 경우라면 절대적 기준으로서 마감일의 역할을 의미가 없다고 볼 수 있다.
6. Inbox의 전체 수집 대상에 대하여 위와 같은 조치가 완료되었으면 Clean Up 기능을 실행하여 각 항목은 대상 폴더로 이동될 수 있도록 한다.

 이상과 같은 분류와 조직화 과정의 핵심은 수집된 대상이 ‘일’로서 어떻게 관리할 것인지를 평가하는 단계이다. 하지만 수집 대상을 일로서 판단하는 과정(분류 단계) 이후 그 일을 위임이나 프로젝트 내로 이동하는 과정 혹은 단일 업무 목록으로 지정하는 과정(조직화 및 평가 단계)을 구분하여 진행하기란 매우 어색하고 비효율적일 수 있기 때문에 OF에서는 이러한 두 절차적 단계를 동시에 진행 된다.

• OF에서 굳이 두 단계를 구분하여 적용하고자 한다면 분류 단계에서는 Inbox의 수집 대상에 대하여 먼저 일이 아닌 대상을 삭제하고 이어 참고 자료나 대기 자료로 먼저 판단된 대상을 별도로 이동하고 남은 일로서의 후보들에 대하여 즉시 실행할 수 있는 업무를 실행하고 그리고 남은 업무 목록을 위임 사항과 다음 업무 목록으로 구분한다. 이어서 조직화 및 평가 단계에서는 각 위임 사항과 업무 사항에 대한 세부 분류 및 평가 작업을 따로 진행할 수 있다.

추가로 프로젝트 내로 옮겨진 신규 업무의 순서를 점검하여 새로 정렬하는 작업은 별도 과정으로 진행하거나 이후 Review 단계에서도 수행할 수 있다. 하지만 Review 단계는 기본적으로 진행 중인 프로젝트의 관리라고 볼 수 있으므로 신규 프로젝트의 배치나 프로젝트 업무 간 순서 조정은 별도로 진행하는 것이 효율적일 수도 있다. 하지만 이상의 이러한 원칙(?)적인 방법과 달리 OF에서는 모든 것을 무시하고 Quick Input 단계에서도 프로젝트와 컨텍스트 그리고 시간 조건 심지어는 완료 여부까지 을 즉시 입력하여 분류와 조직화는 마무리까지 할 수도 있다. 앞서의 여러 상황 중 어느 경우를 선택하는 것은 사용자의 몫이라고 할 수 있지만 가능한한 일관성을 유지하는 편이 좋다.

 이러한 과정을 iPhone이나 iPad에서 운용할 경우에도 크게 다르지 않다. 하지만 Mac OS X에서의 OF에 비해 키보드 운용이 불편할 수 있기 때문에 수정이나 이름 변경 등이 많은 경우 나름의 적응이 필요할 것으로 본다.

[OmniFocus의 기본 운용] Collect, Inbox 업무 수집

OmniFocus(이하 OF)의 Inbox는 GTD 시스템의 첫 과정인 수집, Collect 단계가 진행하는 곳이다. 이것은 미래에 일이 될 수 있는 모든 대상을 모으고 곳이며 또한 정기적으로 비워져야 할 곳이기도 하다. 물론 현실적으로 물리적 제약이 있지만 내 머리 속을 혼란스럽게 하는 혹은 할 위험의 대상을 모두 이곳으로 옮겨 놓을 곳이기도 하다. 가능한한 많은 대상을 Inbox에 수집할 수 있도록 한다. 수집 과정을 위한 수집함이 물리적인 것이든 OF와 같은 컴퓨터 프로그램의 수집함이든 그 수는 중요하지 않다. 핵심은 모든 수집함이 일관성을 가지고 수집되고 비워지는 기능을 정기적으로 수행할 수 있도록 유지하는 것이다. 이 포스팅에서 언급하는 것은 주로 내가 사용하던 방법이므로 사용자에 따라 선호도 등에 차이가 많을 것으로 생각되지만 운용에 큰 무리는 없다고 본다.

 수집 과정에서 중요한 것은 일단 수집 절차에 집중해야 한다는 점이다. 수집된 대상에 대해 이런저런 조치는 다음 과정에서 수행하면 되기 때문에 오류가 있거나 수정할 사안이 있더라도 수집 과정에 우선하도록 한다. 또한 어플리케이션 등을 기반으로 GTD를 운용하는 경우에는-수집함의 수가 중요하지 않다고는 했지만-가능하면 수집함은 최소화하여 집중할 수 있도록 한다.

1. Inbox 폴더로의 수동 입력

• Inbox 폴더에 직접 입력

 수집할 대상이 생각날 때마다 Inbox 폴더로 이동하여 직접 각 항목을 입력하는 일반적인 방법이지만 GTD의 효율적 사용을 위해서는 가급적 지양하는 것이 좋다. 기능적으로 볼 때 아무런 문제가 없지만 견물생심(見物生心)이라고 직접 입력하는 동안 사이드 바에 있는 다른 페이지로 가는 눈을 잡기 힘들기 때문에 결국 수집 이외의 일을 하게 될 수도 있다. 본의 아니게 예상치 못한 관리에 상당한 시간을 쏟을 수 있으므로 가급적 직접 입력을 회피하는 것도 나쁘지 않을 듯 하다.

• Quick Entry 스크린을 통한 입력

 Inbox에 직접 입력하는 경우와 함께 일상에서 주로 사용하는 입력 방식이며, 주로 단축키를 이용하여 드러난 화면에 입력하게 된다. 매킨토시에서 다른 작업을 하면서 생각나는 일들을 즉시 Inbox로 입력할 수 있는 용도로 사용되지만 단축키를 어렵게 지정하면 오히려 잘 사용되지 않을 수도 있다. Quick Entry에서는 대상의 수집은 물론 분류나 평가 작업도 함께 처리할 수 있다.

iPhone(혹은 iPad)을 자주 사용하게 될 때에는 하단 우측의 Quick Entry 아이콘을 통하여 입력할 수 있다.

2. Inbox 폴더로의 자동 입력

 이 포스팅에서 주로 언급할 내용이자 또한 나를 포함한 많은 게으른 이들의 관심사는 가능한한 많은 일거리들이 자동으로 Inbox로 수집되는 방법일 것이다. 이러한 방법은 인터페이스나 기능이 한계상 iOS  기반 앱에서는 설정 등이 쉽지 않기 때문에 주로 Mac OS X 환경과 어플리케이션들로부터의 자동 수집이라고 할 수 있다. 하나 염두에 둘 것은 네트워크 연결을 기반으로 진행되는 이러한 자동 입력 기능이 주변 환경이나 공급사의 상황에 따라 즉각적으로 그리고 항상 원할하게 처리되지는 않을 수도 있다는 점이다.

E-Mail 자동 수집

• Clip-o-Tron        

 전통적인(?) 방법으로서 OF 1  시절 사용하던 Clip-o-Tron 도구를 이용하면 Apple Mail(혹은 Mail.app)의 선택된 메시지들에 대하여 클리핑 키를 이용하여 메일 제목, 메일 내용, 첨부파일 그리고 원래 메시지에 대한 링크 까지 Quick Entry로 보낼 수 있다. 하지만 Mac OS X 10.10 이후에서는 Clip-o-Tron을 사용해도 메일 제목만 보내지고 원래 메시지에 대한 링크가 생긴다. 경우에 따라 큰 차이가 아닐 수도 있겠지만 첨부된 파일을 직접 관리해야 하는 경우 등에 종종 불편할 수 있다. 그리고 Clip-O-Tron은 OmniFocus 2에서는 삭제 되었기 때문에 별도로 다운로드하여 설치해야 한다.

Clipping from Mail using the OmniFocus Clip-o-Tron

• Mail Drop

 전통적이면서 새로운 방법이라고 할 수 있는 Mail Drop은 OF 1의 E-메일 메시지 자동 포워딩 기능을 수행한다. 하지만 OF 1과 달리 OF 2에서는 OmniSync Server로 부터 별도의 계정을 생성한 후 이 계정으로 들어 오는 E-메일 메시지에 대하여 OF의 Inbox로 자동 포워딩하게 된다. 귀찮을 수도 있겠지만 생성 자체가 간단하고 한번 구성해 놓으면 특별히 불편한 점은 없다. 또한 Clip-o-Tron과 달리 메시지의 모든 첨부 파일도 Inbox로 이동되게 된다. 그리고 목적에 따라 여러 메일 계정을 생성할 수 있기 때문에 필요한 경우 유용하게 적용해 볼 수도 있다.

 메일 계정 생성을 위해 Omni Sync Server에-OF의 Sync 기능 계정과 동일한 이름과 암호로-연결한 후 원하는 만큼의 계정을 생성할 수 있다. 물론 계정 이름은 자동으로 설정된다. 생성 후 삭제 지정한 계정은 로그아웃 후 자동 삭제된다.

Omni Sync Sever

 그리고 Apple Mail에는 이를 위한 OmniFocus라는 새로운 규칙이 생성되고 이후 지정한 메일로 들어 오는 모든 메시지는 OF의 Inbox로 향하게 된다. Inbox로 들어온 메시지는 제목과 본문 그리고 첨부 파일 등 전체 메시지를 확장 페이지나 오른 쪽 하단의 Note 항목에서 확인할 수 있다. Mail Drop를 이용하여 메일 프로그램의 Inbox에 수신된 메시지에 대하여 특정 조건에 적합한 메시지를 Mail Drop 계정으로 발송하는 규칙을 만들면 Apple Mail로 들어오른 여러 메시지들에서도 다양한 방식으로 적용이 가능하다. 예로 트위터 계정으로 부터 수신된 메시지를 Mail Drop 계정으로 재전송하기 위한 다음과 같이 간단한 Apple Mail의 규칙을 설정할 수 있다. 이후 Mail Drop 계정으로 재수신된 메시지는 OF 2의 OmniFocus 규칙이 수행하는 Mail Action 애플스크립트에 의해 OF의 Inbox로 보내진다.

 하지만 OF 2에서는 OF 1과 달리 Apple Mail 처리를 위한 설정 기능을 내장하고 있지 않기 때문에 아래 링크와 같이 애플스크립트를 별도로 다운로드 해야 사용이 가능하다.

Mail Action 다운로드

다운로드한 파일은 ~/Library/Application Scripts/com.apple.mail 폴더에 저장한다.

  Mail Drop 이용의 장점은 Mac OS X는 물론 Windows 환경 등에서 메일 메시지를 전달할 수 있으며 iOS에서도 큰 불편없이 사용할 수 있다. 또한 E-메일 메시지 기반의 여러 장비들과의 함께 운용할 수 있다는 점에서 충분히 활용성이 크다고 본다. 당연한 사실이지만 이것은 Omni Sync Server를 이용하므로 단일 시스템에서 Sync 기능을 사용하지 않은 경우에도 운용할 수 없다. Mail Drop 이용에서 다소 불편할 수도 있는 점은 E-메일 전송이 즉각적으로 반응하지 않을 수 있기 때문에 약간 여유를 가지는 것이 좋다.

3. 웹 페이지 및 어플리케이션으로부터 클리핑

 E-메일 메시지와 함께 가장 많이 수집되는 정보가 웹 페이지와 다른 어플리케이션 등에서 생성된 내용들이다. 간단하게는 마우스로 내용을 선택한 후 클리핑 단축 키를 이용하므로 써 내용을 Quick Entry 스크린을 옮길 수 있다. OF 1에서는 클리핑을 위한 별도의 설정 화면이 있었지만 OF 2에서는 Mac OS X 환경에서의 키보드 단축키 설정을 사용해야 한다.

특별히 OmniGroup의 OmniOutliner는 OF의 구성 체계와 완벽하게 결합된다. 파일을 직접 로딩할 수도 있으면 드래그 & 드랍 기능을 이용하여도 동일한 구성을 이용할 수 있다.

File > Import Outline Document

그리고 Import 되는 OmniOuliner의 파일의 컬럼 항목을 OF의 제목, 컨텍스트 등에 맞도록 지정할 수 있다.

4. iOS 환경에서 Siri와 Reminders 운용

 경우나 상황에 따라 다를 수 있겠지만 iPhone에서 Siri를 이용하여 OF의 Inbox에 수집하는 기능도 유용하게 사용될 수 있다. OF의 Siri 기능 지원은 iOS의 Reminders와 연동하여 사용자가 음성으로 입력한 내용을 수집하게 된다. 기능은 간단하게

Main 화면 > Setting > Capture Reminders > On

을 설정하므로써 작동하게 된다. Reminders의 특정 리스트를 지정하여 사용할 수도 있다. Siri를 통하여 Reminders에 저장된 업무 목록은 OF의 Inbox로 동기화되어지게 된다. 하지만 많은 경우 익숙하지 않은 방법일 수도 있다.

[OmniFocus의 기본 운용] 준비

정확한 수량은 모르겠지만 아마도-Mac OS X 기반에서-GTD 플랫폼으로 가장 많이 사용되는 어플리케이션은 OmniFocus(이하 OF)나 Things 중 하나가 선두에 있을 것이고 Wunderlist 정도가 뒤를 따를 것으로 생각된다. 다른 여러 어플리케이션들이 저마다의 특징으로 소개되고 있지만 현재까지 순위에는 큰 변화를 주지 못하고 있을 것으로 본다. 현재 OF는 나의 GTD 플랫폼이기도 하고 상대적으로 이런 저런 문의도 많고 해서 OF 운용에 대한 기본적인 내용을 정리하여 포스팅을 하기로 했다.

 Things나 Wunderlist에 비해 OF는 분명 어렵고 복잡하지만 그 만큼-본의 아니게 상대적으로-GTD 스타일로 만들어진 경우로 볼 수 있다. 사실 OF가 처음 출시되었을 때에는 GTD를 너무 어렵게 구현했다고 불만스러운 반응이 많았던 것으로 기억한다. 일단 OF의 사용을 위해서 GTD와 관련한 몇 가지 사안을 염두에 두어야 한다. 물론 이에 대한 상세한 설정은 OF에서 진행하게 된다.

1. 업무 항목의 표현

글로 적다보니 어렵게 보일 수도 있는데, GTD에서 볼 때 일을 상세하게 적는 것과 간략하게 적는 것의 차이는 상당하다. 예로 만일 일의 내용과 세부 사항까지 명확하게 이해하고 있다면 간단히 표현하는 것도 좋은 방법이다. 하지만 아직 일의 실행과 완료의 기준이 명확하지 않다면 관리 항목으로서 가능한한 명확하게 표현하는 것이 좋다. 대개 이런 경우 글은 길어 지게 된다. 취향의 문제로 생각할 수도 있지만 GTD를 처음 시작하는 입장이라면 명확하게 관리 항목을 표현하는 연습이 필요하기 때문에 가능한한 상세하게 대상을 표현하는 것도 좋은 방법이라고 생각한다.

 일 혹은 프로젝트는 목표 혹은 결과가 명확하고 그리고 이를 달성하기 위한 핵심 행동이나 실행 방안도 함께 표현될 수 있다면 더욱 좋다. 물론 이미 알고 있는 사안에 대해 굳이 상세하게 적을 필요는 없다. 그러므로 항목에 이러한 내용으로 표현될 수 없거나 포함될 수 있다면 일로 관리될 수 없다고도 볼 수 있다. 이후 포스팅에서도 언급되겠지만 단순한 일정이나 계획은 일로 관리될 수 없다. 이런 경우는 달력이나 알림 용도의 별도 관리 도구를 이용하여 약속을 잊지 않도록 하는 방법을 사용한다.

 또한 업무 항목을 얼마나 세분화하여 관리할 것인가에 대한 대략적인 기준도 미리 생각해 보는 것이 좋다. 예로 GTD에서는 한 장소에서 처리될 수 있는 일들은 하나의 개별 업무로 작성하는 것을 권장하고 있다. 행동이나 결과가 변동성이 거의 없고 또한 시간 차이도 없는 일들을 개별적으로 너무 상세하게 관리하는 것은 오히려 비효울적일 수 있다.

2. 컨텍스트 설정

컨텍스트(Context)는 GTD의 핵심 관리 기준이라는 점에서 아무리 강조해도 부족함이 없다. 반면 그 만큼 명확하게 컨텍스트를 규정하기란 쉽지 않다. 때문에 대략적으로 컨텍스트를 미리 설정해 두는 것도-어차피 진행 하면서 계속 수정될 수 밖에 없으므로-잦은 변경에 대비한 준비로 볼 수 있다.

 컨텍스트는 여러 표현이나 기능으로 설명될 수 있지만 일의 실행을 위한 전제 조건이라는 측면에서 OF에서는 하나의 항목에 하나의 컨텍스트 만을 지정할 수 밖에 없는 제약(?)이 있다. 이 전제 조건은 절대적이기 때문에 컨텍스트가 충족되면 반드시 일이 실행되어야 한다는 것이 원칙이다. 때문에 실제로 컨텍스트가 명확하지 않거나 혹은 그러한 조건으로서 생각되지 않게 되면 일이 제대로 수행되지 못하거나 미뤄지는 이유가 되기도 한다.

 Things등과 비교하여 OF의 운용에 불편함을 느끼는 대표적인 예가 단일 컨텍스트라고 볼 수도 있다. 비록 시간 조건 등은 따로 지정할 수 있기는 하더라도 명확하게 하나의 실행 조건을 지정하는 것은 쉽지 않다. 그러므로 충분한 시간을 가지고 다른 활용의 예를 참고하면서 자신에게 적합한 컨텍스트를 만들 수 있도록 하는 것이 좋다. 그리고 OF의 운용이 시작하면 가능한 변경하지 않는 것이 좋다고 생각된다. GTD에서는 기본적으로 프로젝트는 컨텍스트를 지정하기 않기 때문에 컨텍스트는 개별 업무의 실행 조건으로서만 생각해도 충분하다.

3. 업무 점건 기간 설정

단일 컨테스트의 제약과 함께 OF의 사용에 가장 혼란스러움을 느끼는 기능 중의 하나가 Review 작업이다. Review 관련한 포스팅에서 자세히 언급하겠지만 OF는 GTD의 리뷰, 관리 단계를 별도의 기능으로 구현하고 있다. 문제는 일반적인 업무 관리 시스템에서는 개별 혹은 전체 업무의 관리를 필요한 경우나 가능한 경우 제한없이 확인하고 점검할 수 있지만 OF에서는 별도의 정기적인 Review 작업으로 전체 업무를 관리하도록 한다. 그리고 기본적으로 대개 일주일 전후의 시간을 기준으로 보고 있다. 때문에 잦은 업무 내용 확인에 익숙한 사용자들은 이러한 절차적 제한이 거북하거나 필요없는 기능으로 생각될 수도 있다.

 하지만 일반 OF의 Reviw 기능을 사용한다고 할 때, 자신의 전체적 업무나 프로젝트 관리의 점검 기간을 어느 정도로 설정할 것인지를 생각해 볼 필요가 있다. 일반적인 불안감 때문에 잦은 계획 점검이나 계획 수정이 발생하는 경우라면 OF를 통하여-기대이기 하지만-좀더 여유있는 관리 자세를 습관화하는 것도 좋을 수 있다고 본다.

4. iOS 기반 스마트 기기의 운용

OF는 현재까지 애플의 맥킨토시, Mac OS X 환경과 iOS 기반의 아이폰이나 아이패드와 같은 스마트 기기 환경에서도 운용이 가능하다. 일단 두 운영환경 간의 OF 데이터는 완벽하게 호환성을 유지하며 실시간으로 동기화도 가능하기 때문에 운용 자체에는 큰 문제가 없다. 하지만 관리를 위한 인터페이스 운용의 효율성으로 볼 때 스마트 기기에서의 운용에는 상대적으로 한계가 있다. 그리고 iPhone과 iPad를 비교할 때 상대적으로 큰 화면을 운영할 수 있는 iPad 버전이 훨씬 사용이 편리할 밖에 없다고 본다. 하지만 이동이 잦거나 일일 업무 확인 사인이 많은 경우라면 iPhone도 효율적으로 운용할 수 있다고 본다.

 OF가 GTD 플랫폼으로서 다른 경쟁 제품에 비해 가지는 장점이면서 경우에 따라 단점으로 볼 수 있는 점은 Mac OS X의 업그레이드에 맞춰 신속하게 업데이트된는 것이다. 이러한 점은 운영체제의 새로운 기능을 어플리케이션에 빨리 수용한다는 점에서 좋지만 운영체제 업그레이드가 전제되어야 하기 때문에 경우에 따라 사용이 어려운 문제가 될 수도 있다. 예로 Things나 The Hit List 등은 선택할 수 있는 운영체제의 범위가 상대적으로 넓기 때문에 구형 맥킨토시에서의 사용도 여유가 있다. 또한 간혹 운영체제의 업그레이드를 지원하기 위해 업그레이드가 된 OF가 오류를 일으키는 경우도 없지 않았다.

 끝으로 OF는 Mac OS X 버전이나 iOS 버전 모두 기본 버전과 프로 버전을 구분하여 공급하고 있다. 이를 구입 사항에 대한 포스팅에서 별도로 다루고자 한다.