휴가철의 외로운 플래닝 맨 ?

어느 날 혹은 언제나처럼 오늘도 머리 속 가득한 부담으로부터 벗어나기 위해 모니터를 바라보며 계획을 세우거나 심지어 어떤 프로그램이 계획 수립에 적합한 지 웹 서핑에 빠진 자신을 본 적이 있지 않나 싶다.

하지만 무섭게도 이런 일이 어제도, 오늘도 그리고 내일도 계속 될 것이다. 아마도 많은 혹은 적지 않은 주변의 사람들이 그러리라 본다. 다만 그럼에도 계획의 의지나 기대와 무관하게 밀려오는 일을 닥치는 대로 무엇보다도 열심히 하다보니 하루는 나름 의미있게 보낸 듯 위로하며 눈을 감는다. 그리고 곧 머리 속에는 다시금 뭔가를 해야할 부담에 잠을 뒤척이게 된다. 물론 곧 지친 몸 덕에 잠을 빠져 든다.

언제가 강조하지만 계획은 언제나 계획이다. 계획을 아무리 잘 짠다고 하더라도 실행이 보장되지는 않는다. 반대로 무언가 실행을 시작했다면 어떤 계획은 이미 시작된 것이다. 물론 성공과 실패는 별개의 결과이다. 하지만 시작했으니 어떤 식으로든 결과는 드러날 것이다.

현실적으로 그리고 사실 상 좋은 계획은 없다. 더욱이 완벽한 계획이란 존재할 수 없다. 계획이란 언제나 수정되고 바뀌고 그리고 사라지기도 한다. 계획이 지속된다는 자체만으로 가치가 있을 수도 있다. 어쨌든 실행된 계획만이 가능한 것이다. 결국 계획은 실행의 시작이면서 실행의 결과이다. 결과에 의해 좋은 계획, 완벽한 계획이 평가된다.

뜨거운 여름, 한 주 혹은 두 주 또는 몇 일 정도의 휴가 기간 동안에 많은 이들이 가족들 몰래 크고 작은 계획을 준비하는 시간을 가지려고 할 것이다. 그러나 그 모든 시도는 물거품이 될 것이다. 그러니 사랑하는 가족들과 휴가를 즐기거나 가족들 몰래 도망가기를 기원한다. 후회하고 구박받더라도 계획에 빠져 고민하는 시간 보다는 훨씬 가치가 있지 않나 싶다.

그럼에도 계획의 시간을 가지려고 한다면, 해야 할 일이나 하고 싶은 일이 아닌, 할 수 있는 일의 기록하기 바란다. 목록으로 나열하든 다양한 형식으로 맵핑을 하든 현재 머리 속에서 할 수 있는 일을 적는다면, 그 일 가운데 하고 싶은 일과 해야 할 일이 있다. 그리고 그 일들을 분류하거나 정리하지 말고, 당장 할 수 있는 일이라고 생각되는 일부터 실행하도록 하자.

할 수 없는 일이라면 곧 벽에 부딪힐 것이고 할 수 있는 일이라면 실행될 것이다. 그리고 크든 작든 새로운-미뤄두었던-계획이 시작되었다고 할 수 있다. 우리는 이미 벌어진 일에 대해서는 놀라운 대응력을 가지고 있음을 안다.

어렵게 비싼 비용을 들여, 좋은 그리고 강력한 프로젝트 및 플래닝 프로그램을 찾더라도 자신의 계획은 실행은 커녕 제대로 수립해주지도 않는다. 휴가비만 날릴 지 않을까 싶다.

GTD의 업무 계층화, 프로젝트 관리에 대한 오해

GTD 시스템 운용이 쉽지 않거나 나름 제대로 된 운용을 하고 있다고 싶지만 뭔가 불안정한 상황이 이어지고 있다면 한번 쯤 뒤돌아 보아야 할 것이, GTD 시스템의 프로젝트 관리에 관한 사항이 아닐까 싶다.

OmniFocus(이하 OF)와 Things(혹은 Microsoft To Do, 이전 Wunderlist)의 GTD 구현 과정의 가장 큰 기능적 차이는-이른바 프로젝트로 불리는-업무 간의 계층적 구조에 대한 처리에 있다. 일단 기능적인 측면에서 OF는 Things에 비해 높은 혹은 복잡한 수준의 계층 구조를 지원한다. Things 역시 계층화 구조 구현에 대한 사용자들의 의견을 수용하여 상당 부분 계층적 구조에 대한 지원이 가능하도록 개선되었다. 그럼에도 반드시 기능적 구조에서 Things의 OF의 계층화 구조 프로젝트 관리에 대응할 수 없다.

물론 이러한 기능적 차이가 GTD 시스템의 기술적 우위를 가르는 일방적 기준이 될 수는 없다. 이전 여러 포스팅에서 이런 내용을 적었다. 하지만 어쩔 수 없은 기능의 존재과 구조에 따른 비교이다 보다 OF가 Things에 비해 우위에 있다는 사실을 부정할 수도 없다.

문제는 OF를 사용하든 혹은 Things를 사용하든 프로젝트 혹은 복잡한 계층화 구조의 기능을 제대로 이해하고 사용하지 못한다면 GTD 시스템 운용의 큰 낭패를 볼 수 있다는 점이다. 일반적으로 업무를 계층화된 구조로 구성하게 되면 어쩔 수 없이 상위에 있는 항목이 하위에 대해 주요한 위치를 차지하거나 혹은 관리 우선 순위에서 높은 곳에 있다고 생각하게 된다.

그러나 GTD의 가장 근본적 개념이 이러한 구조로 부터 벗어나 현실적으로 현재 실행 가능한 일을 수행하는 방식을 제공한다는 사실에서, 프로젝트에 대한 상세한 구성 및 관리에 지나친 집중을 하게 되면 GTD의 기능적 운용 범위를 초과하게 될 수 있다. 즉 GTD 시스템을 넘어 프로젝트 관리 시스템으로 진입하게 된다는 것이다.

우선 GTD의 개념적 측면 이전 계층화 구조의 업무 체계 즉 프로젝트 관리의 가장 큰 문제점을 한번 생각해 볼 필요가 있는데, 그것은 일의 시급성이나 중요도에 비해 전체적 구조에 묻혀 기대한 만큼 명확하게 드러나지 않는다는 것이다. 물론 개별 업무에 마감일, 중요도 혹은 플래그 등을 지정하여 운용하지만, 그 대상이 적지 않은 경우에 이 정도 수준의 관리 요소로서는 기대치를 만족시킬 수 없다는 것이다.

때문에 용어 비교 측면에서의 혼란이라고 할 수 있지만 전통적인 프로젝트 관리 체계와 GTD의 업무 요소의 관리 기능에서의 프로젝트가 동일한 용어를 사용함에 따라 시간이 지나 GTD 시스템의 관리 요소가 일정 수준 이상으로 증가하게 되면 이도저도 아닌 관리 방식이 되어 버릴 수 있다. GTD 시스템의 관리 범위가 넓은 경우라면 다들 비슷한 체험을 했으리라 예상된다.

물론 Things와 같은 다소 제한적 구조의 GTD 시스템에 느끼는 상대적인 답답함은 부정할 수 없다. 나 역시 OF의 선택에서 그런 이유가 가장 크다. 하지만 앞서 언급한 프로젝트 관리의 문제 역시 Things에 비해 OF를 운용할 때 더 심각하게 느껴질 수 있다.

그러므로 이러한 문제로 부터 벗어나 좀더 여유롭게 프로젝트 관리를 하기 위해선 OF 프로젝트 관리 기능을 명확하게 이해하고 자신만의 관리 기준을 정할 필요도 있다. 예로 프로젝트와 세부 프로젝트의 그룹 설정을 너무 순차적 내용으로 규정하려고 애를 쓸 필요가 없을 수도 있다. 사실 아직 일어나질 않은 일들의 관련성을 순차적으로 배치한다는 자체가 무리일 수 밖에 없고, 명확한 표현으로 구분되고 배열된 경우 수정이나 재배치가 상대적으로 힘들 수 있다. 계획은 언제나 계획일 뿐이라는 점에서 여유를 두는 것도 좋다. 일이 아닌 일의 관리 자체를 너무 완벽하게 작품처럼 꾸미는 것은-모든 경우는 아니겠지만-불필요할 수도 있다. 실제로 세부 계획이 명확하다고 수립된 프로젝트 조차 계획이 변경되는 것이 일상인 현실에서, GTD 시스템에서 아직 불분명한 사실들을 가지고 명확한 세부 계획을 수립하고 관리하기란 정말 어렵다.

또한 앞선 자심 언급한 바와 같이 계층화된 프로젝트에서 계층화는 일의 우선 순위에 따라 구성되고 배열될 뿐이지 일의 가치나 중요도에 따라 배치될 수는 없다. 왜냐하면 역시나 대부분의 일이 아직 실현 전의 상태이기 때문이다. 우리가 어떤 일이 얼마나 중요한 지 안다고 할지라도 실행이 요구되기 전이나 혹은 실행이 불필요한 상태에서도 실행할 수는 없다. 때문에 계층화 구성에서 의도한 가치에 따른 평가가 발생하지 않도록 해야한다.

더불어 계층화를 위한 요소를 너무 남발하지 않도록 해야 한다. 하나의 프로젝트가 여러 세부 프로젝트로, 또 각 세부 프로젝트의 내부는 또 다른 세부 요소로 구분될 때 발생할 수 있는 모든 요소를 일일이 점검해야 할 대상으로 수집하거나 입력할 필요는 없다. OF의 프로젝트는 실행하고 기대한 결과를 달성하기 위한 도구적 방식이지 프로젝트 자체를 우아하게 관리하는 위한 방식을 운용해서는 안되며 실제 그러한 기능을 제공하지도 않는다. 그런 점에서 OF에 만족하지 못하고 점점 프로젝트 관리 도구를 찾거나 관심을 보이게 되는 자신을 돌아 볼 수 있게 된다면 이러한 측면에서의 우려를 이해할 수 있으리라 본다.

마이크로소프트의 Project와 같이 대규모 프로젝트 관리 도구는 말 그대로 한 사람이 감당하기 힘든 범위의 프로젝트를 관리하기 위한 체계이다. 비록 한 개인이나 소그룹의 업무가 결코 복잡하지 않다고 할 수는 없더라도 그러한 많은 관리 자원을 다루기 위한 체계로 GTD의 계층적 업무 관리 체계의 불편함을 극복하려고 하는 것은 잘못된 판단이라고 본다.

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

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

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

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

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

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

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

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

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

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

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에 대한 경험이 없는 경우라면 이런 점에서 사용해볼만 하다고 생각한다.

새로운 계획 수립 vs. 지나간 계획 관리

만나는 많은 이들이 개인적으로든 업무적으로든 일상 프로젝트)를 위한 계획 수립에 고민하고 있다. 대놓고 고민을 토로하는 이도 있지만, 말이 없더라도 대개 얼굴에 고민이 역력해보인다. 큰 프로젝트에서 한 개인의 역할이 최종 의사결정권자가 아닌 다음에야-어떤 위치에 있든-제한적일 수 밖에 없음에도, 너무 지나친 고민에 빠져 있지 않나 싶다. 반면 내 삶의 최종 결정권자는 분명 내 자신이 되어야 하기에 역시 나름의 계획 수립을 고민해야 하겠지만, 대개 자신의 삶에는 무관심하다. 현실적으로 일상이 업무의 연장선 혹은 업무 결과에 지대한 영향을 받는다는 점에서 자기 중심의 관리에 집중한다는 것이 무리가 있는 것도 사실이긴 하다.

여하튼 회사 일이든 개인 일이든 그리고 크든 작든 계획을 마련하게 된다, 하지만 계획을 수립하는 것은-원하는 기대에 비례해서-결코 만만치 않은 일이 분명하다. 그래서 항상 일을 위한 계획은 본의 아니게 새로운 일을 만들어 내게 된다.

특히 미래가 불확실한 혹은 장기적 계획이라면 더욱이 개인적 측면에서의 준비 과정은 더욱 어려울 수 밖에 없다. 일반적으로 내가 듣는 고민의 가장 대표적 예는 어떤 내용을 어떤 식으로 계획해야 할 지 모르겠다는 것이다. 솔직히-그 계획 자체에 관여하지 않고 있는 입장에서-난들 어떻게 안다고 이런 푸념을 들어야 하나 싶기도 하다. 내가 참여 한다고 해도 당사자나 상황이 크게 다르지 않을 것인데. 다들 나의 관심사를 알고 있는 덕분에 이러한 고민을 무언가 기술적으로 해결할 수 방안이나 최적화된 어플리케이션이 없는지 묻기도 한다. 솔직히 말하지만 그런 완벽한 해결책은 없다. 그렇다고 그런 식으로 답해 줄 없으니 그저 짧은 경험에 기반한 나름의 간단한(매우 단기적인) 나 만의 방안을 제안해 보게 된다.

- - - - -

계획이란 앞으로 발생할 가능성이 높은 일에 대한 예상과 그에 대한 대응을 가정하고 수립된다. 때문에 모든 계획은 100% 완벽할 수 없으며 어떤 식으로든 수정될 수 밖에 없고-자신과 주변의 관심도에 비례하여-빈번하게 폐기 되는 사태를 겪게 된다.

때문에 안전한 계획 수립을 위한 전제는 계획 자체를 명확하게 규정하고 준수할 수 있다는 전체를 세우지 않는 것이다. 계획의 폐기 혹은 포기 역시 계획의 일부라고 할 수 있다. 물론 계획의 폐기를 계획의 일부로서 진행한다는 자체는 모순적일 수도 있다. 그런 상황에서 오늘도 끝 없는 계획이 수립되고 진행되면서 반복된다.

모든 계획의 내용과 범위가 사람 마다 혹은 업무 마다 다를 것이니 효율적 계획 수립을 위한 방안 개발은 공허한 구호이지 않나 싶다. 다만 어떤 내용과 실행안이 계획의 대상으로 만들져야 할 지 혹은 만들어 질 수 있는 지에 대한 사항은 생각해볼 수 있다. 어떤 내용을 계획에 포함시키고 향후 변화의 폭을 짐작하는 것만으로 효과적인 계획 수립에 큰 도움이 될 수 있다고 본다.

그런 점에서 개인적으로 제안하는 방안의 하나는, 계획 수립을 위한 참고 자료서 다가올 수 있는 미래에 대한 여러 고민에 앞서 이미 완료된 계획에 대한 기록을 정리하는 것이다.

계획이란 것이 사람 마다 업무 마다 내용과 범위가 다르기 했지만, 여러 과정 중 한 단위에서 보자면 일정 범위에서-일상의 삶과 같이-유사한 구성과 내용이 반복된다고 볼 수도 있다. 즉 새로운 제목과 대상으로 규정된 절차라도 한 개인이나 조직에서 수행할 수 있는 기능적 범위는 거의 유사한 경우가 많기 때문이다. 또한 그 수행의 주체 역시 변함없는 나 그리고 우리이니.

이러한 방안의 효용성은, 이미 끝난 일의 결과는 분명할 것이고, 그 결과의 원인, 과정 그리고 대응 역시 충분히 객관적으로 파악 가능하다고 보기 때문이다. 또한 추진 과정에서의 수정 이유 그리고 수정에 따른 변화 역시도 파악이 가능하다. 그러므로 성공 여부와 무관하게 지나간 계획에 관련된 정보는 새로운 계획의 수립을 위한 유용한 참고 자료로 활용될 수 있다.

하지만 바쁜 일상에서 지나간 계획의-미래 활용을 위한 목적이기는 해도-관리는 시간적으로나 절차적으로나 쉬운 일이 아닐 뿐더러 특히나 지속하기가 매우 어렵다. 무엇보다도 미래의 참고 자료로서 활용 가치를 유지하기 위해서는, 계획이 완료된 시점에서 빠른 시일내에 마무리 되어야만 한다. 시일이 지날 수록 지난 계획에 대한 정리는 점점 불가능한 상태로 전락하게 된다. 개인적으로 하나의 계획이 완료되면, 마무리된 당일이나 다음날 정도에 정리할 수 있도록 습관을 들이고자 애를 쓰고 있다.

지나간 혹은 완료된 계획을 정리하기 위해서는 하나의 대전제가 우선되어야 하는데, 계획의 성공 여부와 상관 없이 솔직하고 객관적으로 평가되어야 한다는 점이다. 대개 지난 계획의 결과에 대해서는 상대적으로 호의적일 수도 있지만, 이럴 경우 새로운 계획을 위한 참고 자료로서 활용성할 수 있는 신뢰성을 갖추기 어렵다. 계획이란 자체한 불안정한 일임에도 참고할 자료 역시 불안정한 평가를 포함하고 있다면, 계획 수립의 어려움은 더욱 혼란해 질 수 있다. 하지만 역시 사람이 새로운 일은 물론 지난 일에 대하여 객관적 시각을 유지한다는 것은 분명 쉽지 않다.

• - - - - -

이러한 이유에서 지나간(완료 되거나 폐기된) 계획의 세부 항목이나 일정을 관리하기 용도로 두 가지 기능적 방법을 사용하고 있다. 간단하게 일의 목적과 목표를 설정하고 계획하고 진행한 내용 그리고 그 결과를 적을 수 있는 메모를 사용한다. 그리고 매번 같은 식으로 반복하기 위해 미리 정규화된 형식을 이용하는데, 문서 작성용 어플리케이션 등을 사용하여 템플릿을 만들어 사용한다. 개인적으로 워드프로세서 보다는 운용이 가벼운 OmniOutliner를 사용하여 템플릿을 만들어 사용하고 있다.

워드프로세서를 이용하면 좀더 많은 내용을 편리하기 입력하도록 구성할 수 있지만, 가능한 간단한 구성이 새로운 습관의 지속에 훨신 유리하기 때문에 OmniOutliner 같은 가벼운 아웃라이너 등을 사용하는 것이 좋다. 직접 종이에 출력하여 활용하는 방법도 있지만 예상 외로 시간과 수고가 많이 들기 때문에 부담스러울 수 있다. 손을 글을 쓴다는 건 생각 외로 노동 강도가 심하다.

템플릿은 아래 예와 같이 간단하게 회의나 미팅, 개별 주체별 사안, 그리고 업무 항목이나 기능별로 구분한다. 하지만 가능한한 최소한의 템플릿을 사용하려고 한다.

이러한 지난 계획에 대한 평가 관리에서 가장 주요한 어떤 대상을 참고 자료로 활용한 것인가에 대한 결정이다. 비록 내용만으로 주요하다고 판단되더라도 한 프로젝트에 여러 사안이 많다보니 일일리 관리하기는 불가능하다. 참고 자료로서의 평가와 관리를 위한 대상을 선정하기 위한 나름의 노력이 필요하다. 괜히 모든 사안을 다 관리할 수 있다는 단순히 욕심을 부리다가는 작심삼일이 분명하다. 그러므로 보다 활용 가치가 있는 지난 계획을 선택할 수 있도록 하는 자신만의 기준을 세울 수 있도록 한다.

- - - - -

하지만 이런 지난 계획에 대한 상세 평가 및 반성 용도을 위한 관리는 시간적으로 육체적, 정신적으로 부담이 적지 않기 때문에 모든 사항에 대한 지속하기 쉽지 않고, 더욱이 예정한 시간 내에 수행하기도 만만치 않다. 때문에 이를 보완하기 위한-더욱 간단한-방법으로 달력을 이용한다. 물론 이전 지난 계획 정리와는 별개로 운용하는 것이 좋을 수도 있다.

일단 계획한 하나의 일이 완료되면, 달력이 계획한 일이 표시되어 있다면 완료 상황에 따라 조정하면 되고 없었다면 지난 일정으로 달력에 표시를 한다. Mac OS X의 달력이나 Outlook의 달력 기능으로 충분하다. 두 어플리케이션 사이의 기능적 비교로는 Outlook의 효과적이지만 역시 이론 용도로 활용하기엔 너무 무겁다.

우선 해당 어플리케이션에서 지난 계획 관리를 위한 별도의 캘린더를 하나 만들어서, 지나간 개별 일정을 모두 표시할 수 있도록 한다. 프로젝트 단위로 별도의 캘린더를 만들어 사용할 필요는 없다. 이미 지난 계획은 지난 계획일 뿐이며 참고자료로서 동일하게 관리하는 것이 이러한 관리 습관의 지속에 효과적이다.

이 방법의 효용성은 앞서 지나간 개별 계획이 나름 상세한 사항을 기록해야 하는 부담이 있는 반면, 달력에 직접 일자, 시간, 위치 그리고 관련 정보를 직접 입력할 수 있기 때문에 쉽게 적용할 수 있는 것이다.

이러한 상세 내용은 아마도 프로젝트 관리 어플리케이션이나 별도의 관리를 위한 달력 등에 표시되어 있지만, 이미 지난 프로젝트에 대한 내용을 다시 전용 어플리케이션에서 본다는 것은 시각적으로 정신적으로 꽤나 피곤한 일이다. 이러한 관리의 목적은 단순히 지난 계획의 사항을 새로운 계획에 활용하기 위한 참고 자료라는 점에서 보다 쉽게 볼 수 있도록 하는 것이 주요하다. 특별히 주요하게 구분하여 관리할 필요가 있다면 별도의 캘린더를 생성하고 구분되는 색깔을 이용할 수도 있을 것이다.

이러한 달력을 이용한 지나 계획의 관리를 개인적으로 선호하는 이유는 동일하거나 유사한 계혹의 수립 과정에 소요 시간이나 다른 계획간의 관계를 눈을 보면서 파악하는 것이 꽤 효율적이다.

또한 이러한 노력을 일상의 기록으로 적용해 보는 것도 나름 좋은 방법이다. 그러면 본의 아니게 맛볼 수 있는 최고의 성과는 달력에 표시된 내용을 보면서, 지난 일상에서 나 자신이 얼마나 열심히 삶을 살았는지 확인할 수 있다는 점이다. 예상 외로 달력이 여러 일들로 가득 채워진 것에 놀랄 수도 있다. 개인적인 일이든 집안 일이든 그리고 학교와 회사 일 등 생각 외로 쉬지 않고 자신이 살고 있음을 느낄 수 있다.

물론 이러한 방법도 결코 쉽지 않다. 하루 이틀은 흥미를 가지고 자신의 일상을 기록하는 재미가 있을 수도 있겠지만, 생각 외로 몇 십분 혹은 몇 시간 전에 자신이 한 일을 명확하게 규정하기 어렵다는 점에 좌절감을 느낄지도 모른다.

이러한 관리 방법은-업무와 관련된 일만이 업무에 영향을 주는 것이 아니며, 일상의 일이 일상에 한정된 일도 아니기 때문에-모든 일은 서로가 영향을 미치며 수정되고 변경되어 삶의 진행에 관여되어 있다는 것도 인식할 수 있게 한다.

- - - - -

지난 계획에 관리 습관은 마치 매일 일기를 쓰는 것의 어려움과 비슷하다고 볼 수 있다. 물론 학창 시절 짧은 방학 기간 동안의 일기도 어려운데 매일 일기를 쓰는 보통 이상의 능력을 가진 대단한 친구를 본 적도 있기는 하다. 지난 일에 대한 관리가 일기처럼 일상의 부담으로 다가온다면 이러한 관리 방식이 지속되기 매우 힘들다. 때문에 나름의 관리 방식의 설정과 유지를 위한 체계의 구축과 유지를 위한 노력이 필요하다.

하지만 사람이란 것이 나이가 들수록 일상의 습관이나 업무 스타일이 변하기를 기대한다는 것은 사실상 불가능하다. 그러므로 몇 일 혹은 몇 주, 지난 일정에 대한 기록만으로 일상에서의 자신의 모습과 역량을 쉽게 파악할 수 있다. 하지만 곧 지쳐서 이를 지속하기 쉽지 않을 수도 있다.

만일 이러한 방식까지 활용하여 지난 계획을 참고할 필요성은 못느낄 수도 있겠지만, 언급한 바와 같이 개인적인 경험에 비춰-어떤 방식으로 든-지난 계획의 성과를 기록하고 관리하는 것은 확신하건데 새로운 계획의 참고 자료로서 가치가 매우 높다고 생각한다.

아웃라이너 기반 프로젝트 관리 체제로 전환

때가 때인-12월이-만큼, 올 해의 여러 프로젝트가-대부분 기대 이하의 성과로-마무리되었지만 다음 해의 여러 프로젝트가-대부분 기대가 섞여서-추진 계획을 작성되고 있다.

프로젝트가 시작될 때마다 항상 갖는 고민이 도대체 뭘로 어떻게 이 기약 없는 프로젝트를 준비하고 또 관리하느냐는 것이다. 컴퓨터에는 강력한 기능의 제공을 자랑하는 값 비싼 프로젝트 관리 프로그램이 있지만, 내 능력의 부족인지 언제나 부족하고 불만스럽고 더욱이 아무리 오랜 기간 사용해도 여전히 불편하다.

그래서 언제나-프로젝트 규모와 상관없이-실질적 프로젝트의 관리 도구는 결국 한/글과 엑셀 그리고 커다란 화이드 보드가 그 역할을 대체했다. 컴퓨터 화면의 프로젝트 현황은-그나마 잘 보지도 않지만-순전히 경영자를 위한 전시용이었다. 물론 기업의 규모나 수준에 따라 이런 어플리케이션을 잘 사용하고 또한 절실하게 필요로 하는 곳도 많을 것이다. 하지만 그 수가 얼마나 될지는 의문이다.

이런 전문 관리 체계를 개인적 수준에 적용한다면, 분명 소 잡는 칼로 닭은 잡는다고 할 수 있겠지만, 그나마 제대로 운용하기 힘들다. 너무 복잡하고 어렵고 기능도 부족하다. 사람이 하는 일을 사전에 미리 규정하고 변화되는 과정을 관리하기란 역시 만만치 않다.

개인적으로는-업무용이나 개인용이든-프로젝트 관리에 마인드 맵과 아웃라이너 그리고 화이트 보드를 이용했다. 마인드 맵과 아웃라이너는 순전히 나를 위한 용도이며, 화이트 보드는 외부적 공개를 위한 위한 것이다. 화이트 보드가 유리판이었기 때문에 이를 매우 선호했다(이른바 쓰고 그리는 또 지우는 손맛이 있었다). 그리고 난-실제로-커다란 창문을 화이트 보드 대용으로 사용하기도 했다. 시작하기 다소 부담스럽지만 한번 해보면 무척 편리하다.

현재 컴퓨터 시스템, Mac에서 마인드 맵은 XMind Pro를, 아웃라이너로는 OmniOutliner Pro를 사용하고 있다. 솔직 사용하지도 않을 Pro 버전의 기능이 매우 아깝다. 기능적으로 보자면 마인드 맵이나 아웃라이너는 전용 어플리케이션이 아니더라도 주변 여러 어플리케이션을 활용하여 쉽게 운용할 수 있다.

물론 대형 프로젝트의 관리에는 여러 이유로 높은 수준의 관리 체계가 요구되어야 하는 것이 분명하지만, 어차피 사람이 하는 일은 예상치 못한 별의별 문제와 오류 그리고 수정이 반복되기 마련인데, 나름 규칙이 정해진 관리 체계에서는 유연하고 창의적 대응을 구현하기 쉽지 않다.

마인드 맵과 아웃라이너을 이용한 프로젝트 계획과 관리의 효용성은 그 특징이 명확하다. 매우 유연하게 변화되는 상황에 적절하게 대응하는 체계의 구현이 용이하다. 반면 체계적 관리를 벗어나 상상의 나래로 확장될 위험도 있다. 때문에 각 어플리케이션에서 제공되는 여러 부수적 기능을 적절히 사용하여 프로젝트 관리 수준의 계획한 의도 범위에서 유지될 수 있도록 해야 한다.

기능적으로 볼때, 사용하는 어플리케이션에 따라 마인드 맵과 아웃라이너는 정보의 공유가 수월할 수도 있다. 예로 XMind에서는 마인드 맵에 대한 아웃라이너 표시 기능을 제공할 뿐 아니라, 여러 어플리케이션에서 작성된 아웃라인 형식 문서도 마인드 맵 형식으로 불러 올 수도 있다.

마인드 맵과 함께 아웃라이너 프로그램을 함께 사용하게 된 이유는, 마인드 맵으로 프로젝트 관리함에 있어 각 항목의 순차적 혹은 절차적 관계를 규정하여 보기가 쉽지 않기 때문이었다. 마인드 맵이 너무 확장된 경우에는 절차적 관리가 너무 복잡하다. 아웃라이너는 반대로 내용이 길어지면 전체적인 프로젝트의 윤곽을 파악하기 힘들어진다.

1983년 Apple II에서 Living VideoText의 Thank Tank가 등장한 이후 아웃라이너는 오늘날 OmniGroup의 OmniOutliner에 이르기까지 기본 기능과 구성에서 거의 변화가 없다는 점에서, 마인드 맵과 비교하여 확장된 개념과 정보의 표현에는 한계가 분명하다.

반면 오늘날 무척이나 빠른 컴퓨터 시스템 성능에 비춰 단순한 기능의 아웃라이너 전용 프로그램은 매우 가볍고 빠르게 운용할 수 있는 장점이 있다. 마치 Windows 시대에 DOS 어플리케이션을 사용하는 느낌일 수도 있다. 계획 초기 단계에서 다양한 변화가 요구되는 과정에서 무거운 프로젝트 관리 프로그램이나 워드프로레서 등을 이용하는 것은 꽤나 부담스럽다. 그렇다고 메모장이나 엑셀 등을 이용하기에는 프로젝트 내용에 집중하기 힘든 점이 있다.

그리고 복잡하고 큰 규모의 프로젝트라도 기획 초기 단계에 마인드 맵과 아웃라이너를 이용하여 기초안을 작성 후, 전문적인 프로젝트 관리 프로그램으로 이전하여 관리하는 방법도 효율적일 수 있다.

[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 작업을 진행하는 것에 대해서는 고민할 필요가 있다고 본다.