과연 K-프로젝트는 태어날 수 있을까 ?

내 삶에서 일정 관리, 업무 관리, 혹은 프로젝트 관리는 삶의 걸림돌을 해결하는 방안이라 생각했고, 그러한 해결은 컴퓨터 소프트웨어로 구현된 어플리케이션이 답이라 생각했던 시절이 꽤나 길었다. 지금 기억으로도 Apple Desktop, Multiplan. Think Tank, MS Project 등 셀 수 없는 어플리케이션들을 사용하면서 나름의 답을 찾으려고 했다. 하지만 솔직히 제대로 된 결과로 이어지진 못했다.

영어 표현의 문제도 있었고, 제한된 텍스트 화면의 한계 때문이기도 했고, 무엇보다도 업무 관리나 프로젝트 관리에 대한 제대로 된 개념이나 이론 그리고 경험도 없었지 않나 싶다. 하지만 그 시절을 지나 학교에서도, 학윈 과정에서도, 회사에서도 그러한 고민은 해결되지 않았다. 8-비트 컴퓨터에서도 64-비트 컴퓨터로 바뀐 세상에서도 삶이나 업무의 만족스러운 관리를 제공해주는 어플리케이션을 꼽으라면 선뜻 생각하기 어렵다.

그 오랜 시행착오의 결론을 한 마디로 적자면, 정말 Microsoft든 SAP든 어떤 소프트웨어 기반의 프로젝트 관리는 정말 한국인 혹은 한국식 업무에는 적용하기 쉽지 않다는 것이다. 그리고 그 고민은 이 순간에도 계속되고 있다. 도대체 이러한 소프트웨어를 제대로 활용하고 있는 기업이나 기관이 있다면 세계 어디라도 달려가서 보고 싶을 정도이다.

새로운 프로젝트, 프로젝트 관리 시스템 구축 프로젝트 자문을 위해 도입 측과 공급 측의 이야기를 듣고 있지만 정말 답이 없는 것 같다. 도입 측은 표준 규정과 예외 사안의 비중이 거의 같은 수준이다. 세상의 모든 것을 원한다. 그리고 공급측은 일명 전문가란 탈을 쓴 사기꾼 수준이다. 상대방이 원하는 세상의 모든 것을 구현할 수 있다.

과연 원하는 기능으로 프로젝트 관리 시스템이 구축될 수 있을까. 프로젝트 관리 프로젝트를 관리해야 프로젝트를 하다니.. 한편으로는 매우 흥미롭다. 정말 K-프로젝트가 태어날 수 있을까 ?

그렇다면 한국인에게 맞는 프로젝트 관리의 방식이란 무엇일까? 가장 일반적인 상황은 일이 많다는 것이다. 대개 한두 개의 프로젝트에 발을 걸치는 경우는 일상이며, 규모가 작거나 인원이 적다면 문어발 수준이 된다. 게다가 평소의 직급이나 직책으로서의 일은 여전하다. 그렇다보니 MS Project와 같은 관리 체계에서 자원이 대상으로 인원의 배치나 할당 시간이 현실적으로 무의미해지게 되고, 그 결과의 예측치는 그저 그래프 출력을 위한 값 이상의 가치는 없다고 여긴다.

더욱이 프로젝트 간의 이동이 잦다. 그나마 이동이 없더라도 서류상 무관한 프로젝트에도 유령 지원자들이 꽤 많이 활동하기도 한다. 좋은 점일 수도 있지만, 프로젝트의 예측 관리 측면에서는 이러한 사항을 염두에 두어야 할지 말지가 고민일 경우도 있다.

물론 규정 업무 시간에 따라 관리는 굳이 언급할 필요가 없을 것이다. 최근에는 이러한 관리가 더욱 곤란한데 인원을 채용하면 간단히 해결될 문제를 어쩔 수 없는 현실적 사정을 빌미로 이리저리 돌려막기를 하니, 그러한 상황을 현재 프로젝트 관리 소프트웨어에서 구현하기란 불가능하지 않나 싶다.

그 외 수 많은 한국스러운 프로젝트 관리의 방식이 과연이 새로운 프로젝트 관리 체계에 녹아 들 수 있을까? 솔직히 이게 구현되면 노벨상 수상감이라고 농담삼아 이야기한다. 프로젝트 관리를 위한 프로젝트, 다시 그 프로젝트를 위한 프로젝트 관리.. 한편으로는 매우 암담하다.

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이 중심이 되지 않을까 생각한다.

Things 3.1.5 업데이트

갑작스러운 메이저 업데이트가 올라왔다. 이전 3.0.3 버전에서 느닷없이 3.1로 업데이트되면서 뭐가 문제였나 싶기도 했다. 난 특별히 문제가 없었는데 아마도 클라우드 싱크 기능에 이런저런 사소한 오류가 발생했던 것 같다. 또한 일부 Mac OS X 버전에서도 어플리케이션 전환이나 닫을 때 충돌 발생 문제가 있었다. 덕분에 이후 잦은 업데이트가 지속되고 있다.

릴리즈 노트에는 프로젝트 내에서 반복 업무 지원이 가능하도록 개선되었다고 강조 하는데, Things 2에 비해 Things 3의 소심하지만 과감한(?) 기능 개선이라고 할 수 있는 것인 프로젝트를 비롯한 폴더 내에서의 개별 항목에 대한 설정 변경이 가능하게 되었다는 것이다. 특히 개별 To-do 항목을 프로젝트로 변환하는 Convert to Project가 Things 2가 해결해야 할 가장 우선적인 기능 개선이었다. Things 2에서 프로젝트 내의 개별 항목은 프로젝트로 전환이 불가능했다.

우선 프로젝트 내의 개별 업무 항목에 대하여 마우스 오른쪽 버튼을 누르고 팝업 메뉴에서 반복 업무(Repeat..)를 선택하면 반복 기간 및 조건을 선택할 수 있다. 특정 업무 완료 후 반복과 정기적 반복을 지정할 수 있다.

지정된 반복 업무는 마감일이나 리마인더에 연결하여 관리할 수 있다.

또한 Project에 대해서 완료 및 취소 지정을 할 수 있도록 개선되었다. 솔직히 Things 운용에 주요한 기능은 아니지만 Things를 처음 접하는 사용자에게 나름 효용성있는 기능이라고 본다.

Version 3.1로의 메이저 업데이트임에도 기능적으로 크게 눈에 띄는 사항이 없지만 아마도 내부적인 안정성이나 동기화 기능 등이 보다 원할하도록 개선된 것 같다. 현재 Things 3는 Mac OS에서만 운용하다보니 iOS 기반 Things와의 동기화와 관련된 사항은 내가 아직 상관없는 이야기인 듯..

로컬라이징과 그에 대한 문구 해석 기능 문제는 내겐 특별히(?) 무관심한 사안인데, 이번 업데이트로 Culturedcode 블로그에 소개된 것처럼 영어, 독일어, 불어, 이탈리아어, 스페인어, 러시아어에 이어 일본어 지원이 가능하게 되었고 곧 중국어도 지원될 것이라고 한다. 뭐 굳이 필요한 기능인가 싶지만 사람 취향 차이라고 생각한다.

일단 3.1로 업데이트된 이후 거의 한 달에 한 번 정도의 마이너 업데이트가 진행되고 있을 정도로 기능의 안정화에 힘쓰고 있는 모습을 보인다.

Things에서 프로젝트 계층 구조 응용

Things 사용자 입장에서 OmniFocus와 비교에서 항상 거슬리는 점이-그 효용성 여부를 떠나-계층적 프로젝트 혹은 업무 관리 기능이라고 볼 수 있다. 이전 포스팅에서 언급했듯이 OF의 계층적 업무 관리 기능은 프로젝트의 계층화이기도 하지만 내부 업무 관리적인 기능이라고 볼 수 있기 때문에 Things가 크게 불리한 점이라 할 수는 없다. 물론 계층화를 지원하지 않는다는 자체는 여러 경우에 불편함을 초래하기도 한다. 그렇더라도 GTD가 다루는 일이나 업무의 내용이 상대적으로 단기적이라고 볼 때 계층화된 프로젝트 구성이 절대적으로 필요하다고 생각하지 않을 수도 있다. 사실 Things의 가장 큰 불편한 점은 프로젝트를 일반 개별 업무로 전환할 수 없다는 점이다.

        그럼에도 불구하고 장기적이고 대규모 큰 내용에 관한 프로젝트를 Things에서 운용하고자 한다면 나름의 간단한 방법이 있다. 아마 많은 사람들이 유사한 방법을 사용할 것으로 생각한다. Things의 프로젝트는 각 프로젝트에 여러 일들을 포함할 수 있지만 프로젝트 간에 서로 연결이 불가능하다. 다행히 Area 영역이 있어 조금 나은 편이지만 내용이 많아지만 계층화 지원 미비에 대한 아쉬움이 여전하게 되나. 그래서 이러한 경우에 대응하여 사용할 수 방법이 프로젝트 목록을 정렬하는 ‘Sort Project by Title’ 기능을 이용하는 것이다. 즉, 각 프로젝트를 몇 개의 그룹으로 구분 짓기로 정한 후 프로젝트 이름 앞에 000 이나 001 등의 같은 숫자로 우선 순위를 기입한다. 그리고 하부 프로젝트는 숫자 이후 적절한 기호나 공백으로 계층을 구분할 수 있게 한다. 예로 다음과 같이 몇 개의 프로젝트로 구성된 Thigns의 프로젝트 리스트이다.

        더 큰 규모의 내용은 Area 폴더를 이용하여 동일하게 적용할 수 있다. 물론 이렇게 하더라도 하위 프로젝트가의 완료 상황이 상위 프로젝트에 영향을 미치는 기능 등을 기대할 수는 없지만 전체적으로 프로젝트 간의 우선 순위와 관련성을 파악하는 데에는 나름 괜찮게 활용할 수 있다고 본다. 프로젝트 이름 앞에 번호를 붙인 것인 눈에 거슬릴 수도 있겠지만 Things의 멋진 인터페이스 디자인 덕에 크게 표 나지는 않는다.

다음 행동과 프로젝트

GTD를 접한 이후 가장 혼란스러워 개념 혹은 방식이 프로젝트 구성에 관한 것이었다. 쉽게 생각할 수도 있겠지만 일상에서 프로젝트라는 용어가 가지는 의미로 인한 GTD의 프로젝트에 대한 오해가 생길 수도 있다. 단순하게 보자면 GTD의 프로젝트는 같은 목표 달성을 위해 필요하고 계획한 업무 그리고 업무의 세부적 행동의 집합이다. 프로젝트의 이름은 일반적으로 생각하는 거창한 목표 달성이 될 수도 있으며 일상의 소소한 일이 되기도 한다. 필요에 따라 거창한 목표를 가진 프로젝트 아래에 수 많은 업무나 행동들이 모여 있을 수도 있고 보다 상세한 목표를 가진 여러 프로젝트로 나뉠 수도 있다. 당연히 프로젝트 안에 세부 프로젝트가 포함될 수도 있지만, 이러한 경우 세부 프로젝트의 목표는 최종 프로젝트가 가지는 목표에 비해 좀더 일상적일 수 있다. 다시 말해 세부 프로젝트는 완료 후에도 목표 달성이라는 의의를 찾기 힘들 수도 있다. 그러므로 개별 프로젝트들을 관리할 것인지 하나의 큰 프로젝트를 관리할 것인지가 중요한 문제가 될 수 있다.

그러므로 프로젝트의 이름 역시 업무나 일의 표현처럼 목표 달성을 명확하게 확인할 수 있도록 명명되어야 한다. 만일 명확하게 표현될 수 없다면 이러한 대상은 별도의 관리 그룹을 만들어야 한다. 프로젝트가 아닌 업무나 일의 집합은 프로젝트와 달리 시작과 끝의 기준이 없을 수 있다. 예로 ‘건강을 위해 운동하기’라는 프로젝트를 만들었다면 GTD에서는 이에 대한 시작과 끝 그리고 평가를 할 수 없다. 때문에 ‘올해 체중 10Kg 감량하기’처럼 구체적으로 표현되고 이를 위한 상세 행동들이 포함된다면 GTD의 프로젝트가 된다.

그렇다면 일상의 직장 등에서 다뤄지는-거창한-프로젝트는 GTD에서 어떻게 다루어 질 수 있는가? 답은 이런 프로젝트는 GTD에서 다뤄지지 말아야 한다는 것이다. GTD의 프로젝트는 딱히 정해진 기준은 없지만 크기와 시간에서 제한적이라고도 할 수 있다. 때문에 직장이나 단체에서의 프로젝트를 GTD 체계에서 다루기에는 범위나 변수가 너무 많다. 이러한 프로젝트들은 심하게는 시간 단위로 진척 상황을 확인해는 하는 경우도 적지 않으므로 GTD 체계로 대응하기에는 부족한 면이 크다. 실제로 이러한 프로젝트는 별도의 프로젝트 관리 프로그램이나 관리 팀에서 주도하는 것이 정상이다. 개인의 입장에서는 그 가운데 사용자에게 주어진 세부적인 업무를 자신의 GTD 시스템에서 관리할 수 있다.

GTD의 프로젝트가 주는 용어적 부담감으로 인해 프로젝트의 구성이 어렵게 느껴질 수 있다. 하지만 GTD는-우리가 익히 알고 있고 이야기하는-프로젝트 관리 도구가 아니다. 다른 더 좋은 표현이 있을 지는 모르겠지만 단지 하나의 목표를 위한 같은 수준의 업무 집합체로 이해해야 한다. 종종 GTD에서 10년 20년 후의 달성 목표를 프로젝트 이름으로 정하는 경우도 있지만 이것은 세부적인 업무들의 집함체라기 보다는 시각적으로 목표를 확인하는 수단 정도의 역할을 하는 수준이라고 생각하면 된다.