좋은 도구 혹은 필요한 도구

맥 사용자로서 가끔씩 유명 프로그램 개발사로부터 할인 이벤트 소식을 받게 되면 혹시나 하는 마음으로 내용을 살핀다. 특히 여러 프로그램들이 번들 구성으로 판매하는 행사에는 유혹을 떨치기는 꽤나 힘들다. 항상 마음을 붙잡는 한두 개의 어플리케이션이 포함되어 있기 때문이고, 실제 지금까지 내가 애용하는 여러 프로그램들이 이런 이벤트를 통해 구입했다.

이런 경우는 소프트웨어뿐 아니라 일상의 다양한 도구들에서도 다르지 않았다. 집안에서 하는 운동 기구를 구입하고 나서 몇번 사용하지 않고 옷거리나 장식대가 된 경험은 누구가 있을 듯 하다. 가정에서 필요로 하는 여러 공구 등도 마찬가지이다. 1년에 한번은 커녕 수년이 지나도 겨우 한번 쓸까말한 제품도 눈에 곧잘 띄인다.

사실 이 모든 것들이 모드 좋은 것들이다. 아니 최소한 나쁘지 않은 것들이다. 성능이나 기능에서 구입할 당시 손색이 없던 것들이지만, 구입 후 현실에서 그 필요성은 잘 눈에 띄이지 않는다. 소프트웨어 번들에 포함된 십여 개 가운데 절반 이상이 거의 사용되지 않고 있다. 기대한 필요성 자체가 사라졌다고 할 수도 있지만, 애초 그 필요성이 절대적이지 않았기도 하고 이미 익숙한 다른 어플리케이션에 의해 처리되고 있기도 한 덕분이다.

좋은 프로그램으로서 사용할만한 것임에는 분명했지만, 냉정히 생각해보면 새롭게 사용할 대상은 명확하지 않았다. 앞서처럼 명확한 대상이 있더라도 결국 손에 익숙한 것을 사용하는 것이 결과적으로 더 효율적이었다. 하나의 부족함을 채우기 위한 선택이 또 다른 하나의 결핍으로 이어지기도 했다.

요즈음이야 컴퓨터 시스템의 저장 공간 제약이 거의 없기 때문에 이런 상황에서도 크게 걱정하지는 않는다. 예전이라면 값 비싼 공간을 차지하는 좋은 어플리케이션을 삭제할지를 두고 꽤나 고민했던 시절이 많았다.

소프트웨어뿐 아니라 일이든 물건에서도 마찬가지였다. 할까말까 망설이다가 그리고 살까말까 고민하다가 결국 실행하거나 구입했다가 마무리되지 못하고 계속 미뤄지거나 사용 대상을 찾지 못해 굴러다가는 경우가 일상인 적도 있었다.

처음에는 모두 좋은 것으로 판단에서 시작되었다. 좋은 것이나 결과적으로 필요한 것이라 생각했다. 하지만 좋은 판단은 필요한 판단에 절대적 영향을 미치게 되었다. 일상의 운동이라는 그야말로 좋은 목적의 도구로 구입한 운동기구는 버리지 못하는 값 비싼 수건걸이로 전락해버리는 비슷한 경험은 한 바가 있을 것이다. 그런 시각에서 주변을 보자면 정말 좋은 것이지만 불필요한 것들이 넘쳐나고 있다. 좋은 것이 꼭 필요한 혹은 필요할만한 것은 아니다.

하지만 과연 소프트웨어든, 일이든, 또는 물건이든 그 필요성은 과연 어떻게 평가할 수 있을까. 어쩌면 그 필요성을 찾지 못하거나 알아채지 못한 것일 수도 있다. 그러고 보면 당장 불필요하다고 판단하여 버리거나 숨겨버린 뒤 다시 다시 찾고 구입하느라 고생한 일도 적지 않았다. 그렇다고 그런 걱정에 현재 불필요한 것이 분명한 대상을 무작정 쌓아두거나 미뤄 둘 수도 없다. 공간의 여유가 있다면 임시로 옮길 수 있겠지만, 임시적 이동은 말 그래도 임시적일 뿐이다.

이상적이라면 좋은 도구의 현실적 필요성을 발견하는 것이 가장 합리적인 대응일 수 있다. GTD 시스템에서 수집 대상에 대한 평가와 분류를 위한 과정을 거쳐 최적의 필요성을 탐색하는 과정을 거칠 수 있다면 좋겠지만, 사실 그러한 과정이 얼마나 객관적인지는 장담할 수 없다. 때문에 고민의 대상으로 전락할 위험이 있는 경우, 과감히 포기하도록 스스로를 관리하고 있다. 좋든 필요하든 고민하게 만드는 대상은 대부분 버려질 수 밖에 없는 대상이었다.

그러나 아직도 눈과 귀는 여전히 필요한 것 보다는 좋은 것을 탐닉하고 있다. 일상이란 그런 것인지 모르겠다. 삶의 관리 체계와 모순적인 이런 상황이 지속되는 것은, 가끔 삭제하지 않고 버리지 않고 남겨둔 작은 어플리케이션이나 물건들이 가진 역시나 작은 필요성이 의외로 큰 효용성을 주는 경우가 없진 않았기 때문일지도 모르겠다.

다행히 요즈음 나이가 들어가면서 좋은 것에 대한 시각이 조금씩 달라지는 것 같다. 물론 지금까지 값 비싼 수업료를 치른 댓가라고 생각한다. 그렇다고 필요성을 판단하는 나아졌다는 것은 아니다. 좋은 것이든 필요한 것이든 새로운 것은 접하는 그 자체의 무게와 그로 인한 피로감을 피하고 싶다는 욕구가 더욱 강해졌다. 결국 새로운 것이란 없다. 그저 새롭게 보일 뿐이었다.

현재의 문제를 세련되게 해결할 수 있는 도구는 없다. 아니 문제 해결을 위한 도구에 대한 고민으로 문제가 해결되지 않는다. 원인을 인정하고 해결하기 위한 현실적 현재의 도구를 선택하는 것이다. 좋은 도구, 필요한 도구가 현재의 문제를 해결할 수 있다는 것은 현실을 잠시 부정하고픈 새로운 핑계거리였지 않나 싶다.

Hit Snag 서비스의 성공을 기대하며

Mac 사용자로서 간혹 PC/Windows 혹은 Android 환경과의 차이가 어떤 부분에서는 급속히 줄어 들고 있지만 또 다른 부분에서는 여전히 혹은 더 멀리 벌어지는 경향을 함께 느끼게 된다. 1980년대 중반 Macintosh가 등장한 이후 한 세대 가까이 겪고 있는 일이다. 때문에 어느 한 쪽의 환경만을 경험한 사용자들 가운데 다른 환경의 불편함 혹은 새로운 등증한 기능을 보고, 아직 이런 기능이 없었단 말인가 혹은 이렇게 불편한 기능을 운용하고 있단 말인가 등의 반응을 보이는 경우를 종종 본다. 물론 각 기능의 전체적인 면이라기 보다는 일부 기능에 국한된 경우일 수도 있다.

최근 공개된 Hit Sang 서비스(물론 PC/Windows 사용자만을 위한 서비스는 아니다)를 보고 그 기능에 관심을 가지거나 흥미를 느껴 공개된 영상을 보고 나서 느낀 점은-OmniFocus 사용자로서-이런 기능이 뭐가 새롭다는 것인가 였다. 하지만 그런 느낌은 언급한 바와 같이 내가 OmniFocus의 Mail Drop 기능을 애용한 덕분일 뿐이다.

이 포스팅은 OmniFocus의 Mail Drop과 Hit Snag의 기능 간 비교를 위한 포스팅은 아니다. 간단하게 일상에서 사용하는 서비스에 대한 생각, 즉 인터넷 또는 웹 기반 서비스가 넘쳐나고 있는 상황에서 더 이상 얼마나 더 다양한 기능이나 제품이 등장할 수 있을까에 대한 단상(斷想)일뿐이다.

Hit Snag의 기능은 단순하게 적자면, 이-메일 사용이 잦은 상황에서 특정 이-메일을 생산성 관리 도구로 운용하는 여러 어플리케이션이나 서비스를 통하여 수집할 수 있도록 일종의 이-메일 포워딩 서비스라고 할 수 있다. 물론 특정 메시지나 정보를 다양한 어플리케이션으로 보낼 수 있다는 점에서 OmniFocus에서만 수집 가능한 Mail Drop 서비스와 직접 비교하기는 힘들 수도 있다고 본다.

또한 Google Docs나 Trello 등의 서비스를 사용하고 있다면 단순히 이-메일의 메시지나 링크만 수집되는 OmniFocus에 비해 다양하고 유연한 서비스를 이용할 수 있다고 본다. 앞으로 지원할 서비스는 계속 확장될 예정이라고 하니 OmniFocus 외 다른 어플리케이션을 사용하는 Mac 사용자도 이용할 수 있다.

이제 갓 시작한 서비스로서 Hit Snag이 앞으로 어떤 활약을 보여줄 지 모르겠지만, 단순하게 기능적인 면에서 아직 이런 서비스를 경험하지 못하고 있었지만 신선하기도 하고 꽤나 흥미로움을 주기에 충분하다고 본다. Hit Snag의 웹 페이지에서도 이런 기능이 GTD에 매우 효과적이라고 간단히 적고 있다.

앞으로 Hit Snag의 기능이 제대로 발휘된다면 OmniFocus와는 비교할 수 없는 확장성과 생산성의 도구가 될 수도 있다고 볼 때, 유사한 서비스의 출현도 넘칠 수 있지 않을까 싶다. 어차피 이-메일 기반의 이런 서비스의 구현 자체는 크게 어렵지 않을 것이니.

OmniFocus 3 안내서 - 프로젝트 구조의 구성 #2

이전 포스팅에서는 OmniFocus를 사용하면서 과다한 프로젝트의 계층 구조를 만드는 것은 좋지 않다고 적었다. 하지만 OF가 프로젝트 관리 도구는 아니지만 일에 따라 범위나 깊이가 일상적으로 다루는 수준이 이상일 경우도 드물지 않을 것이다. 그런 경우 하나의 프로젝트를 2 ~ 3 단계 수준으로 유지하게 될 때, 내부에 너무 많은 세부 프로젝트가 생성될 수 있다.

이런 경우에 대한 대응은 단순하게 하나의 프로젝트를 시간 기준으로든 내용 기준으로든 여러 개의 프로젝트로 분할하는 것이다. 그렇더라도 별도로 모아 순차적 관리가 필요하다면 폴더를 만들어 한 곳에서 관리할 수도 있다. 그러하다고 해도 한 화면에 수십개를 넘어 100 여개의 프로젝트가 쌓일 수도 있다. 시각적으로 결코 좋은 그림은 아니다.

이때 눈으로 보이는 화면을 보다 이쁘게 구조적으로 만들려고 과도한 정리를 해서는 안된다. 물론 충분히 계층화된 처리가 효과적인 업무라면 당연히 계층 구조를 이용하면 구성하는 것이 좋다. 다만 눈에 보기 좋도록 하기 위한 조치는 자제하는 것이 좋다. GTD 시스템으로 OF의 운용은 관리 기준에 따라 관리 대상을 점검하는 방식으로 진행하는 것이 전체 프로젝트 현황을 보고 관리하는 것 보다 백배 효율적이다.

OF에서는 각 프로젝트(세부 프로젝트에서는 불가하다)에 대한 검토 기간을 설정할 수 있기 때문에, 수정이 잦거나 자주 점검해야 하는 프로젝트라면 최소 1일 단위로까지 검토 기간을 줄일 수 있다. 때문에 분할된 각 프로젝트를 일일 검토 사안으로 관리한다면 전체 프로젝트에 대한 관리 수준에서도 큰 어려움이 없을 것이다.

하지만 계층화된 프로젝트를 여러 개의 프로젝트로 분할하기 위해서는 각자 나름의 요령이 필요하다. 물론 그 과정을 한번에 모두 완성 시킬 필요는 없다. 프로젝트에 대한 관리가 지속되면서 검토 단계에서 지속적으로 수정할 수 밖에 없다.

일반적으로 회사나 사업과 연관된 일의 프로젝트라면 상대적으로 양도 많고 복잡할 것이다. 이런 프로젝트를 분할하여 여러 프로젝트로 만든다는 것은 쉽지 않기 때문 내부 각 단계의 세부 목표를 명확하게 정하고 이에 따라 분할하는 방법을 적용하는 것이 좋다. 특히 프로젝트의 규모와 내용 그리고 기한 등이 상대적으로 크고 많고 그리고 길다면 분할의 기준을 잡기 모호할 수 있다는 점에서, 한번에 분할하려고 너무 애를 쓰는 건 좋지 않다고 본다.

반면 나의 경우는 전체 프로젝트를 일단 조각을 낸 후, 폴더 단위로 넣어 검토 기간을 짧게 지정한 후 여러 프로젝트를 검토 과정에서 일괄 관리하는 방법을 사용한다. GTD 시스템으로서 OF는 전체 프로젝트가 아닌 개별 사안을 검토 기간에 맞춰 관리하는 방식을 최대한 활용하려는 스타일을 취한다.

이전 포스팅에서도 언급했지만 OF의 모든 프로젝트를 일괄적으로-프로젝트 개요 중심으로-관리하는 방법과 검토 기간에 맞춰-검토 개요 중심으로-관리하는 방법으로 나눌 때, 어느 하나의 방법이 전적으로 우수하다고 하기는 힘들다. 결국 업무 내용과 범위에 따라 달라질 수 밖에 없다. 하지만 GTD 시스템이란 것이 자신의 업무 관리 스타일에 맞도록 시스템을 운용하는 것이기도 하지만, 자신의 업무 관리 스타일을 보다 GTD 시스템이 지향하는 바에 적응하는 식으로 활용할 수도 있다.

OmniFocus 3 안내서 - 프로젝트 구조의 구성 #1

OmniFocus(OF)의 경쟁 우위의 인기 요인 가운데 하나는 프로젝트 심지어 태그(컨텍스트)에 대한 계층 구조를 지원한 덕분이라고 해도 과언이 아닐 것이다. 물론 다른 GTD 어플리케이션에서도 계층 구조의 프로젝트를 지원하지 않은 것은 아니지만, OF와 경쟁 관계의 제품 가운데에서 전체적인 완성도면에서 OF는 단연 선택 우위에 있다.

GTD 시스템에서 계층화된 구조의 프로젝트는 업무 관리를 위한 매우 효율적인 기능 요소가 분명하다. 하지만 어플리케이션을 개발하는 입장에서는 프로젝트와 같은 요소를 계층화하는 것은 어려운 일이 아님에도, Things와 같이 프로젝트의 계층 구조를 지원하지 않는 경우는 나름의 목적이 있다고 생각해 볼 수도 있지 않을까 한다.

물론 OF의 계층 구조 프로젝트는 기능적으로 아무런 문제 혹은 단점이 없다. 반대로 계층 구조의 프로젝트가 지원되지 않은 GTD 시스템을 사용할 경우 그 답답함은 굳이 언급할 필요가 없을 것이다. 하지만 아마도 OF의 사용자 가운데 많은 이들이 프로젝트의 계층화 구조 함정에 빠져 곤란을 겪어본 경우가 적지 않을 것이라는 생각한다.

만일 OF의 프로젝트 구조가 3 단계를 넘어 확장된다면-일단 폴더 구조를 제외하더라도-관리의 문제가 발생할 위험이 매우 높다. 폴더 구조까지 사용한다면 대충 하나의 업무 사항까지 4 ~ 5 단계 수준까지 확장된 것이다. 경험에 비춰 3 단계 이상 확장되면 관리 자체의 부하가 급격히 증가하며, 그러한 경우가 대부분이라면 일이 아닌 관리 체계를 관리해야 하는 수준이라고 본다.

늘 강조하지만 GTD 시스템은 특정 업무에 집중된 프로젝트들을 관리하는 도구가 아니며, 더욱이 OF3를 비롯한 모든 GTD 어플리케이션이 그러한 기능을 제대로 갖추고 있지 못하다. 프로젝트라는 기능적 용어로서 업무 목록에 대한 계층화 구조가 지원된다고 하더라도 이것은 일반적인 프로젝트 관리 기능과는 애초부터 비교될 수 없다.

때문에 OF를 이용하여 GTD의 프로젝트를 관리한다는 것은 일반적인 목표가 분명한 프로젝트를 관리하는 것이 아니라, 단순하게 하나의 목표 달성을 위한 다수의 세부 항목을 포함하는 업무 그룹을 관리하는 방식을 뜻한다.

다시 말해 GTD의 프로젝트를 기대한 목표 달성을 위한 기준으로 필요한 모든 사항을 포함하는 완벽한 프로젝트 관리 구조로 구성하려고 한다면 매우 어렵고 험난한 일이다. 개별 업무의 실행 및 수정에 집중하는 것이 아니라 프로젝트 구조의 완벽성에 집중하게 되는 순간 GTD 시스템은 신뢰성을 잃게 된다.

GTD 시스템에서 관리 되는 프로젝트의 수가 많다고 걱정할 수도 있다. 현재 OF의 프로젝트 수가 100개가 넘어가서 화면에 제대로 보기 힘들다고 일부러 계층화된 프로젝트로 전환한다는 것은 GTD 시스템을 오해하고 있는 것이다.

물론 예전 포스팅에서 너무 많은 프로젝트 혹은 항목을 관리하는 것은 비효율적이라고 적었던 것으로 기억한다. 다만 GTD 시스템으로 관리해야 할만한 일이 아님에도 무조건 수집하고 프로젝트로 구성했다면 분명 프로젝트를 정기적으로 정리할 필요가 있다. 하지만 하나의 프로젝트가 3 단계 이하로 확장될 정도로 복잡해진다면 앞서 언급한 바와 같이 다수의 프로젝트는 분해하는 것이 더 효과적이다.

프로젝트의 구조가 너무 확장되면 GTD 시스템이 지향하는 개별 사안의 실행과 수정을 통한 현재 실행 가능한 일의 우선적 처리라는 기본 핵심을 제대로 운용하기 어려워 질 수 있다. 특히 계층화된 프로젝트의 세부 프로젝트와 프로젝트의 각 항목의 설정 요소를 제대로 지정하지 않았지만 실행 시기나 완료 시기에 대한 확인 역시 어렵게 된다.

단순하게 정리하자면 OF를 사용하면서 Things의 단순함이 가지는 효용성을 적절히 이용할 필요가 있다. Things에 대한 경험이 없는 경우라면 이런 점에서 사용해볼만 하다고 생각한다.

일상의 악몽, 유령 프로젝트

악몽이라는 단어가 주는 느낌이 극단적일 수도 있지만 딱히 부적합 하지는 않은 게 일상적인 꿈도 계속 반복되면 뭔가 싶은 생각이 점점 커지면서 어느 순간 눈을 감는게 두려울 떄가 있다.

무언가 일을 위한 계획에서도 마찬가지인 것이 오늘 계획한 것이 분명 지날 달, 지난 해 계획한 바와 같거나 크게 다르지 않음을 직감하면 처음에는 푸념 섞인 웃음으로 넘기지만 계속 반복되면 자괴감이 들고 나중에는 계획을 세우고 점검하는 과정 자체에 대한 회의감이 들기도 한다.

물론 대부분의 일상에서는 이런 사안을 사소하게 넘길 수 밖에 없다. 눈 앞에 닥친 크고 작은 일들이 얼마나 많은데~

나의 GTD 시스템을 가득 채운 프로젝트 목록 가운데에도 작년, 재작년 혹은 그 이전부터 자리잡고 있던 대상들이 많다. 몇몇은 장기간 계획한 바에 의해 지속되고 있는 경우도 있다. 반면 다른 몇몇은 매 년 심지어는 매 계절 삭제되었다가 다시 올려진 대상들이다. 처음 수집 당시 제목은 다르지만 내용적으로 결국 동일하다. 그리고 이런 경우의 상당수는 앞으로도 같은 과정이 반복될 가능성이 농후하다.

GTD 시스템에서 불필요한 사안으로 평가되어 결국 삭제 됨에도, 신기하게도 교묘하게 유령처럼 다시 등장한다. 사실 그런 반복적 대상을 처리할 별도의 대안은 없다.

이러한 상황에서 지금까지 수 많은 포스팅에서 언급한 것처럼 해당 사안을 다시 삭제하거나 실행해야 한다고 적는다면 오늘의 글을 아무 의미가 없을 것이다. 좀더 다른 시각에서 나를 괴롭히는 친구들을 대할 필요가 있기도 하다.

일반적으로 업무가 아닌 일상의 개인적 일을 다루는 관리 시스템에서 단골로 등장하는 사안들은 분명 나름의 의미가 있다. 업무적 측면에서 삭제와 재등장이 반복적되는 경우는 정말 불필요한 대상이니 따로 언급할 필요가 없다.

오랜 시간 동안 GTD 시스템 내에서 사라진 듯 하다가 어느새 다시 모습을 드러내고 떠들고 있는 대상 프로젝트를 이제 마주해야 할 떄가 되었는 지도 모른다. 지금까지 그 프로젝트가 아닌 의미를 외면했는 지 모른다. 여러 이유가 있을 수 있겠지만 분명한 하나의 이유는 나에게 시간이 넉넉하다고 판단했기 때문일 것이다. 그러나 삶의 어느 순간 내게 주어진 시간이 넉넉하지 않음을 인식하게 된다. 나아가 인정하지 않을 수 없게 된다.

그러므로 GTD 시스템을 통해 처리되지 못한 그런 사안의 존재를 마주해야 한다. 중요한 것일 수도 있고 소중한 것일 수도 있고 혹은 필요한 것일 수도 있다. 마찬가지로 지금까지 단순하게 부담스러워 회피한 사안일 수도 있다. 어떤 것을 선별하고 관리하라고 할 수는 없다. 이미 수 많은 관리의 과정과 시간을 거쳤음에도 여전히 유령처럼 시스템에 남겨져 있다면 그 가치에 의미를 부여하지 않을 수 없다.

결국 포기해야 한다. 지금까지 포기할 수 밖에 없음을 외면했던 것이다. 그렇지 않다면 그것이 아닌 악몽이 아닌 진짜 꿈에 대한 바램을 살릴 마지막 기회가 오늘 주어진 것이다. 다만 이런 일이라면.. 목표를 바라볼 필요는 없다. 이룰 수 있는 목표라면 이미 시작 되었고 결과에 이르렀을 것이다. 오직 목적만이 가치가 있을 뿐이다. 지난 온 길을 돌아볼 때 서 있는 자리로 이어진 발자국이 없다는 것이 악몽이다.

OmniFocus 3 안내서 - 아웃라인 보기 옵션, 사용 가능 vs. 남은 항목

OF3를 GTD 시스템으로 사용함에 있어 가장 핵심적 효용성을 제공하는 기능의 하나를 꼽으라면, 프로젝트에 대한 아웃라인 보기 옵션의 활용이라고 자신한다. 반대로 만일 현재 OF3이 제대로 활용되지 못하고 있다는 생각이 든다면 아웃라인 보기를 어떻게 설정되고 사용하는 지를 평가해볼 필요가 있다고 생각한다.

경험에 비춰 OF3가 효율적으로(혹은 정상적으로) 사용될 수 있도록 하기 위해서 아웃라인 보기를 ‘사용 가능’으로 설정 한다. 그러면 OF3에는 관리되는 모든 일에 대하여-지연되거나 보류되는 일이 아닌 대상 가운데-현재 그리고 향후 순차적으로 먼저 해야 할 일들이 표시된다. 병렬 프로젝트에서는 같은 순위의 일들이 모두 표시된다. 그리고 현재 해야하는 일을 처리하면 다음 일이 나타나게 된다.

아웃라인의 ‘사용 가능’ 설정과 함께 유사한 ’첫번째 사용 가능’ 설정이 위에 있는데, ‘첫번째 사용 가능’은 프로젝트의 내용이나 구성과 무관하게 정렬된 순서에서 최우선(최상단) 대상 만을 보여준다. 그런 점에서 ‘사용 가능’ 설정과 크게 다르지 않다고 볼 수 있지만, 병렬 프로젝트의 경우에도 최상단 항목만 보이기 때문에 ‘사용 가능’과 비교하여 실질적 효용성은 없다고 본다.

하지만 문제는 ’사용 가능’이나 ‘첫번째 사용 가능’ 설정과 무관하게 OF3가 표준 개요 화면의 프로젝트 항목들에 대해서 자동 정렬을 지원하지 않기 때문에 입력 조건 등의 변경에 따라 실행 순서를 수동으로 변경해주어야 하는 경우도 있다.

때문에 각 프로젝트 내 항목에 대한 정렬은 자동 정렬을 지원하는 검토 개요나 사용자 개요 등을 활용해야 한다. 다시 말해 현재 프로젝트에 대한 내용을 파악하기 위해 아웃라인 보기 옵션을 바꾸지 말고 검토 개요를 사용할 수 있도록 한다.

그리고 아웃라인의 ‘사용 가능’에 대응되는 다른 보기 옵션이 ‘남은 항목’이다. ‘남은 항목’은 단순하게 현재 프로젝트 내의 해야하거나 계획된 모든 일을 보여 준다. 프로젝트의 모든 항목을 볼 수 있다는 점에서 대부분의 OF3 사용자에게 거의 기본 설정과 같다고 본다. 만일 프로젝트 내의 항목이나 세부 프로젝트의 수가 적거나 혹은 단순하다면 큰 문제가 없겠지만 그렇지 않을 경우에는 화면에 너무 많은 대상들이 보여 시각적으로 혼란스러울 수 있다.

한편으로 언제나 프로젝트 내의 모든 항목을 볼 수 있다는 점에서 전체적 관리가 용이할 수도 있겠지만, 개인적으로는 관리의 집중도를 떨어뜨릴 수 있다는 점에서 추천하고 싶지는 않다.

OF3의 ’사용 가능’ 보기와 ‘남은 항목’ 보기 간의 우열을 비교할 수는 없지만, GTD 시스템으로 효율적 운용을 위한 ‘사용 가능’을 선택했다면 화면에 나타나는 ’사용 가능’ 항목과 이후 나타날 ‘사용 가능’ 항목들간의 순위가 항상 신뢰할 수 있도록 Reflect, 관리 단계에서 프로젝트를 점검할 수 있도록 해야 한다는 것이다.

그렇지 않다면 일상적으로 두 보기 옵션 간의 선택을 지속적으로 반복해야 한다. 하지만 그런 경우에는 대부분 결국 자연스럽게 프로젝트의 전체적인 내용을 파악할 수 있는 ‘남은 항목’ 보기를 선택하게 될 것이다.

새로운 계획의 수립이 어렵다면, 지난 계획의 평가를 먼저 ?

2021년 첫 한 주가 지나고 있다. 지난 2020년 마지막 주말에 세웠던 한 해이 정말 예상 그대로 실행되지 않고 있음을 나를 포함한 많은 이들이 경험하고 있을 것이다. 그럼에도 언제난 계획을 세운다는 일 자체는 의미있는 과정이 아니라고 폄하할 수는 없다. 다만 보다 기대와 예상을 만족 시키는 계획을 수립할 수 있기를 기대한다. 때문에 향후 계획을 보다 신속하게 그리고 불안정하지 않도록 수립하기 위한 작은 방안을 활용해 볼 수 있다.

그런 점에서 보다 신뢰성 있는 계획을 수립하는 방안의 하나로 생각할 수 있는 것이 이전 포스팅에서도 언급한 적이 있었던 새로운 계획의 수립 이전에 지난 계획의 확인과 점검이다. 일상의 삶에서 어제와 오늘 그리고 내일이 크게 다르지 않을 것이라는 점에서 지난 일에 대한 확인은 여러모로 충분히 활용성이 높다고 본다. 다만 지난 일이라는 특성으로 별도로 가능한 즉각적으로 기록하지 않으면 정확하게 표기하기 쉽지 않다.

개인적으로 이러한 과정을 Mac의 캘린더에 그대로 사용했다. 다른 달력 프로그램을 사용해도 마찬가지라고 본다. 사용은 간단하게 한 주 동안 한 일을 캘린더, 달력 프로그램에 기록한다. 가능하면 특정한 일은 물론 일상의 일을 마무리한 후 그 내용을 캘린더에 기록하는 식으로 진행했다.

일반적으로 일정 프로그램이나 업무 프로그램 혹은 달력에 기록하지만 계획은 계획이다 보니 작든 크든 변화와 수정이 발생하다 보니 언제나 이후에 편집이 발생하는 경우가 많다. 그런 점 때문에 일정 관리 프로그램이나 달력 등에 표시하는 것에 큰 의미를 두지 않는 경우도 많이 보았다.

대략적으로 업무와 관련한 내용뿐 아니라 일상에서 무언가 ‘일’로서 실행한 행위는 모두 기록하고자 했다. 물론 모든 일을 기록하기란 힘들었다. 그럼에도 특히 신경을 쓴 부분은 동시적으로 수행했다고 볼 수 있는 일, 예로 아침 TV에서 뉴스 공장을 시청하면서 급한 이-메일 기반의 업무 사항을 하나 처리했다면 그 두 가지 사안을 모둑 기록했다. 직접 TV를 시청하지는 않았지만 귀로 들으며 다른 일을 했다면 분명 내게 유익이 되는 시간이었다고 볼 수 있다.

마찬가지로 컴퓨터에서 두 개 이상의 프로그램을 운용하면서 동시적으로 혹은 순차적으로 일을 진행했다면 그 두 가지 사안을 모두 기록했다. 물론 잠자는 시간을 기록하지 않았다. 일주일이 지나 한번에 본 화면은 뭔지는 모르지만 의외로 아무것도 하지 않은 시간은 거의 없는 듯 했다. 중간에 빈 시간 역시 뭔가를 한 것 같지만 그게 뭔지 기억이 나질 않았다. 항상 실시간으로 기록할 수 없는 경우가 적지 않다보니 기억을 더듬어 보더라도 빈 시간이 생겼다.

일주일 정도 혹은 두세 주 정도 혹은 한두 달이 지나고 나서 지난 기록을 본다면 일단 무언가를 한 것은 분명하다. 결과를 있는 일, 마무리 되지 못한 일, 혹은 솔직히 의미 없다고 생각되는 일 등 다양한 일을 실행 했음을 알 수 있다. 그리고 결과가 기대 이하인 경우, 마무리 되었다고 생각했지만 어떤 식으로든 계속 반복되는 경우 또는 정말 의미가 없지만 그럼에도 지속하는 일등에 대한 스스로 평가를 할 수 있다.

이런 사례를 활용하면 실제 계획의 수립이나 계획 수정 및 변경 등에 대한 보다 명확한 대응이 가능한 작은 관리 수단을 찾을 수 있지 않을까 생각한다. 유의할 점은 업무적 용도가 아닌 일상적 용도를 기록하는 용도로서는 가능한 별도의 캘런더 항목을 생성하여 따로 입력하고 관리하는 것이 이후 정리에 효과적이다. 물론 이 포스팅 사례의 예이며 지금은 이런 방식을 굳이 사용하지는 않고 있다.

OmniFocus 3 안내서 - 5. Engage, 실행

GTD의 네 번째 과정인 Reflect, 리뷰 이후는 다섯 번째 Engage, 실행으로 이어진다. 단순하게 표현하지만 이제 시스템에서 실행 해야 할 일을 그냥 실행하는 것이다. 물론 어떤 업무 관리 체계든 실행 자체는 시스템이 아닌 사용자의 몫이다. 사실 GTD를 비롯한 모든 업무 관리 혹은 시간 관리 체계는 수 많은 업무들 가운데 해야 할 일을, 해야 할 시간에 잊지 않고 실행하기 위함이다.

이러한 내용을 적용한 컴퓨터 프로그램의 활용에서 보자면, 해당 실행 항목을 시스템이 사용자에게 알려주는 방식이 있는 반면 시스템에서 체계적으로 분류된 업무 목록 가운데 사용자가 실행 항목을 확인하는 방식으로 나눌 수 있다. 이러한 구분에서 볼때 GTD는 후자의 방법에 더 가까운 방식이라고 할 수 있는데, OmniFocus3(이하 OF3)의 경우에는 macOS(Mac OS X) 환경에서는 후자의 경우라고 할 수 있지만, iOS 환경에서는 전자의 경우로 운용이 가능하다.

어떤 종류의 GTD 시스템을 사용하느냐에 따라 약간의 차이가 있을 수 있겠지만 OF3의 경우는 시스템에서 규정된 컨텍스트나 태그 요건이 충족되면 특정 날짜 그리고 시간에 실행을 계획된 업무나 일을 목록을 나타내주고, 사용자는 이를 바탕으로 현재 상황에서 실제적으로 실행 가능한 사안을 실행하게 된다.

물론 현실은 실행 목록의 업무를 모두가 실행 가능하다고 할 수는 없다. 현실에서는 언제나 기대하거나 예상하지 못한 사태가 시시각각으로 발생하기 때문이다. 그러므로 현실적 문제에 어느 정도 대응이 가능하도록 혹은 이러한 문제가 발생하지 않도록 하기 위해서, GTD의 전 과정을 명확하게 그리고 체계적으로 관리해야만 한다. 물론 이러한 노력으로 실행 가능한 상태에 되었더라도 실행한 일이나 업무가 성공적으로 완료 된다는 것은 전혀 별개의 사안이다.

OF3를 GTD 시스템으로서 나름의 방식과 규정을 가지고 잘 운용하고 있다면, 시간, 장소 등 현재 사용자에게 설정한 조건에 부합되는 실행 가능한 일을 파악할 수 있고, 실행할 수 있는 상황을 파악할 수도 있다. 다만 성공적 실행을 위한 OF3의 효율적 운용은 실행 자체와는 별개로 나눠 포스팅 할 예정이다.

언급했듯이 Mac 환경에서 OmniFocus는 일반적인 업무 관리 프로그램에 대한 기대와 달리 특정 시간에 알림 통보를 해주는 방식으로 사용하기 힘들다. 이-메일 클라이언트나 일상의 업무 관리 프로그램처럼 항상 화면에 열어 두고 사용하기 힘들다. 물론 스마트 폰의 환경에서는 이러한 제약이 해소 되어, 설정된 시간이나 현재 정보에 따라 실행 가능한 업무를 확인하거나 알림을 나타나도록 설정할 수 있다. 개인적으로 선호하지 않는다고 했지만 기능적으로만 본다면 OF3 for iOS의 구입 이유로 충분하다고 본다.

- - - - -

GTD 시스템의 실행은 일차적으로 ‘오늘’ 날짜 혹은 ‘한 주 내지는 특정 기간의 시작 날로서 오늘’ 날짜가 기준이다. 만일 ‘오늘’이나 ‘이번 주’라는 날짜나 기간을 기준으로 하루 전이나 이전에 미리 점검한다면 해당 업무는 ’내일’ 혹은 ‘다음 주’의 특정 일자에 실행할 목록으로 나타난다. 혹은 지난 일의 실행 여부를 확인하는 검토 용도라면 해당 업무는 ‘어제’나 ‘오늘’ 혹은 ‘지난 주’의 실행 했어야 하는 일의 목록으로 나타난다.

간단히 정리하자면 OF3가 제공하는 ‘검토 개요’ 화면에 나타난 업무 목록을 오늘 혹은 향후의 실행 목록으로 활용할 것인지 혹은 이미 실행 한 일의 여부를 확인하는 용도로 활용할 것인지에 대한 선택의 문제이다. 이전 포스팅에서 언급한 OF3의 ‘검토 개요’ 화면에는 지정된 날짜 간격으로 대상이 나타나기 때문에 이를 실행 예정 목록으로서 프로젝트나 업무를 실행하는 방식으로 사용하는 것이다. 이러한 용도로서의 활용을 위한 ‘예측 개요’ 기능이 마련되어 있다고 볼 수 있다. 또는 업무 실행 자체에 대한 관리는 ‘프로젝트 개요’나 ‘태그 개요’을 이용하고 지정한 날짜 간격으로 프로젝트나 업무가 제대로 실행 되었는 지 혹은 그렇지 못했는 지 나아가 수정이나 변경이 발생했는 지를 검토하는 용도로 사용하는 것이다.

OF3를 GTD 시스템으로 사용한다면 당연히 후자의 경우가 상대적으로 효과적이라 본다. 반면 일상적 업무 관리 체계로서 요구가 더 높다면 전자의 방식으로 활용할 수도 있다. 물론 일반적인 업무 관리 프로그램이 제공하는 기능에 비교하자면 매우 불편하다. 이는 거듭 강조했지만 GTD 시스템 자체가 소프트웨어로서의 운용을전제로 개발되지 않았다는 점 더불어 GTD의 각 과정이 순차적이면서도 동시적이라는 특징으로는 프로그램으로 구현하기 어려운 특성에 기인한 덕분이다.

‘예측 개요’든 ‘검토 개요’든 어떤 방식으로 OF3에서 일의 실행 목록을 확인하고 점검하는 것은 사용자의 선택이다. 실제로 OF3의 기능은 물론 어떤 종류 혹은 구조의 업무를 수행하느냐에 따라 하나의 방법이 효과적이라 일방적으로 단언할 수는 없다. 하지만 이 두 경우를 적당히 섞어 쓰기에는 OF3의 각 개요 기능의 기능이 유연하지는 않다고 본다.

OF3의 간력한 안내서라는 제목으로 몇 차례 포스팅을 했지만 거의가 기능과 구조에 관한 내용이었다. GTD 시스템이든 OF3든 혹은 다른 프로그램 역시 사용자에 따라 구성과 운용이 다르다는 점에서 좀더 구체적이고 실제적인 예로서 효율적 사용에 관한 내용을 다루고자 한다.

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

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

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

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

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

거창하지만 현실적 실현 가능성이 지극히 낮은 장기적 계획일 수도 있고, 실제적 가치가 다른 일에 의해 자꾸만 뒤로 밀려 나갈 수 밖에 없는 사소하고 소박한 계획일 수도 있다. 하지만 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 과정을 구현하는 가에 대한 운용 측면을 생각해볼 필요가 있다.