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 베타 테스트 개시

마침내 OmniFocus 3(이하 OF3)를 보게 되려나. 기다리던 베타 버전 테스팅을 시작하게 되었다. Things 3가 나름 지속적으로 업데이트 되는 와중에 다소 조용했던 OmniFocus도 본격적으로 기대를 가져도 될까 싶다. 현재 진행되는 분위기로 보니 공개 베타 테스트에 이어 늦어도 내년초 정도면 정식 업그레이드 가능하지 않을까 싶은데.

베타 테스팅 내용은 공개하지 않은 것이 참여 규정이기도 하고 나름의 도의적 원칙이지만... 기능적으로 OF2와 큰 차이를 느낄 수는 없다. 물론 화면 구성이나 메뉴 구조는.. ‘맥’스럽기보다는 ‘웹’스럽게 바뀌었다고나 할까? 만일 기능적 향상이 지속되지 않고 현재의 상태라면.. 굳이 업그레이드할 효용성이 ? 아마도 데이터베이스 변경에 따른 안정성 유지를 우선적으로 생각하는 것 같기도 하다.

설치는 별도 이름으로 설치되지 않고 OmniFocus로 저장되기 때문에 OF2와 함께 사용하는 경우라면 이전 버전을 이름을 바꾸거나 폴더를 옮기는 것도 좋을 듯 하다. 데이터베이스는 동일하게 사용하기 때문에 각 버전에서 동기화된 상태로 계속 사용할 수 있다.

화면의 구성이나 인터페이스는-당연하게도-OmniFocus 3 for iOS와 동일하게 맞춰졌다. 개인적으로 점점 짙은 색상으로 변하는 것이 별로 마음에 들지 않는다.

OmniFocus 3 for iOS

OmniOutliner 5

그리고 사용에 있어 가장 먼저 확인 것이, 현재 OF2에서 가장 불편한 사항이었던 OmniOutliner 5 파일 호출 기능이 가능하도록 개선 되었다. 아직 OF2가 OmniOutliner 5 파일을 바로 불러 오지 못해 정말 불편한다. 전통적으로 OmniGroup이 자신들의 주요 어플리케이션 가운데 발생하는 이런 호환성 문제를 빨리 대응하지 못하는 경향을 보인다.

Multi Tags

하지만 가장 큰 변화는 OmniFocus 3 for iOS에 지원하기 시작한 멀태 태그(tags) 기능이다. 새로운 기능은 아니고 기존 컨텍스트 구조가 멀티 태그 방식으로 대체되었다는 점이다. 물론 Things처럼 마구잡이로 태그를 지정할 수 있는 방식이 아니라 하나의 업무(action) 항목에 여러 개의 컨텍스트를 지정할 수 있는 이른바 멀티 컨텍스트가 가능하게 되었는 점이다. 멀티 컨텍스트는 당연히 프로젝트에 대해서도 적용이 가능하다. Things와의 비교에서 가장 큰 차이.. Things 입장에서는 차별화된 장점이 위협에 놓이게 되었다고나 할까?

개인적으로 멀티 태그(멀티 컨텍스트)에 대해서는 부정적이지 않지만 딱히 긍정적으로 보지 않는다. 아마도 그런 점에서 내가 Things를 GTD를 위한 메인 플랫폼으로 선택하지 않은 이유이기도 하다. 업무를 생성하거나 분류하는 단계에서는 하나의 컨텍스트를 선택하여 지정하는 것이 곤란한 경우가 많기 때문에 멀티 컨텍스트의 효용성이 있는 것이 분명하지만 업무를 진행하는 과정에서는 문제가 발생하게 되면 여러 컨텍스트 간의 우선 순위나 충족 여부로 새로운 고민이 생길 수도 있다. 물론 멀티 컨텍스트가 단일 컨텍스트에 비해 장점이 많은 것은 부정할 수 없기 때문에 잘못된 선택이라고 할 수는 없다. 만일 OF3와 OF2를 함께 운용하는 경우라면 OF3에서 첫번째 지정된 태그가 OF2의 컨텍스트로 지정된다.

일단 개인적으로 가장 주목하고 있는 것은 현재 베타 버전의 지원 환경은 Mac OS 10.13 High Sierra 이상인데 혹시나 10.14 Mojave 이상을 지원하는 사태가 벌어지지 않기를 바란다. 만일 그런 일이 벌어지면 정말 지금 사용하는 맥북프로를 바꿔야 한다 T T

GTD의 컨텍스트에 대한 착각

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

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

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

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

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

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