GTD 활용성에 대한 자체 평가 ?

얼마 전 OmniFocus 활용성에 대한 자체적인 점검에 관한 포스팅을 했는데, 관련해서 생각해 볼 수 있는 매우 주요한 사실이 있다. 과연 나의 모든 관리 대상 즉 고민꺼리든 걱정꺼리든 여러 업무와 일상의 일이-물론 GTD 시스템에서 관리될만한 일에 한정하여-OmniFocus나 Things를 비롯한 어떤 형태의 시스템에 수집되고 관리되고 있느냐에 관한 것이다.

GTD 시스템을 운용한다는 것은 걱정할만하고 고민스러운 것을 신뢰할만한 관리 체계에서 제대로 운용한다는 목적에 비춰 그 대상이 시스템 외부에서 머릿 속을 들락거리고 있다면 분명 시스템 혹은 운용자에게 문제가 있다고 볼 수 있다. 최대한 GTD 시스템을 활용하기 위해 나름 노력을 하고 있음에도 의외로 관리되지 못하는 사안이 적지 않음을 느닷없이 인식하게 된다. 사실 그런 상황이 당황스러울 때도 있다.

길든 짧든 관리할 수 없거나 관리될 수 없는 일은 경우에 따라 순간적으로 엄청난 스트레스를 유발하기도 한다. 사실 지나고 보면 별 것 아닌 것인 대부분이지만 어쨌거나 부담스럽지 않을 수 없다. 그리고 그런 일이 지속되면 GTD 시스템은 관리 기능을 상실하게 된다. 이어서 어떤 형태로든-비록 단기간이더라도-업무 관리의 필요성 나아가 의지를 포기하게 될 수도 있다.

개인적으로 보자면 GTD 시스템은 아니지만 일기를 쓰거나, 블로그 포스팅을 하거나 특히 가계부를 쓸 때 자주 겪는 일이다. 일기나 블로그는 실제적 연속성이 없는 점에서 큰 상관이 없지만 가계부는 내용의 연속성과 항목 간의 연관성으로 인해 시간이 지날 수록 부담은 크게 증가한다.

GTD 시스템이 모든 사안을 관리할 수 있다고 보기는 어렵다. 즉 관리할 수 있으면서 관리될 수 있는 사안에 한정될 수 밖에 없다. 떄문에 시스템 내부에서 관리 가능성 여부에 대한 파악은 매우 주요하다. 관리될 수 없는 사안이라면 GTD 시스템에서 관리되지 못한 상황에 대해 염려할 필요는 없다. 아마도 다른 시스템에서도 사정은 크게 다르지 않을 것이기 때문이다.

또한 애초 관리될 수 있는 사안을 관리하지 못한 것에 대한 문제는 분명 빠르게 평가할 필요가 있다. 비록 GTD 시스템에서 관리되지 못하는 사안이라더도 처음에 GTD 시스템의 수집함으로 수집되었어야 한다. 그런 점에서 GTD 시스템의 수집 기능은 매우 주요하지 않을 수 없다라는 기본적 사실을 다시 한번 확인하게 된다.

2022년을 시작하면서 아마도 많은 이들이 GTD 시스템이든 다른 시간 혹은 업무 관리 체계에 대한 문제를 고민하게 될 것이다. 새로운 시스템으로 전환 혹은 관리 체계의 효용성 포기 등 나름의 평가를 하게 될 것이다. 하지만 어떤 관리 시스템이라도 그 대상이 관리되지 못하고 있는 상황이 반복되고 있다면 그 단순한 시작, 수집과 평가를 너무 무시한 것일 수도 있다.

OmniFocus 활용성에 대한 자체 평가 ?

만일 오랫동안 OmniFocus(이하 OF)를 활용하고 있음에도 불구하고 사용에 따른 효용성이 의심되고 전체적인 업무나 일상에서의 시간 관리가 제대로 되지 않고 있다면, 시스템 즉 OF의 기능적 사안에 문제가 있거나 자신의 OF 활용 방식에 문제가 있다고 볼 수도 있다. 물론 대개는 두 가지 경우에 걸쳐 있지 않을까 싶기도 하지만 일단은 구분하여 생각해보기로 했다. 그 가운데 OF의 기능적 측면에서 자신의 활용성을 평가하는 잣대로 평가할 수 있것이 있는데, 바로 아웃라인 보기 방식이다.

OF의 아웃라인은-삭제된 항목을 포함하여 전체 기능을 보는 경우를 제외하고-첫 번째 항목을 보는 경우와 현재 사용 가능한 경우 그리고 절차적으로 남은 항목을 모두 보는 경우를 선택할 수 있다. 만일 현재 OF 사용시에 첫 번째 항목이나 사용 가능 항목이 아닌 남은 항목으로 설정된 채로 유지되고 있다면, GTD 시스템으로 OF를 제대로 활용하지 못하고 있다고도 해도 틀린 말이 아닐 수 있다.

다시말해 OF를 사용하면서 일상적 상태를 남은 항목으로 지정하여 항상 현재 상황에서 전체 사항을 보면서 관리하고 있다는 것은 프로젝트나 업무 리스트의 실제적 검토 및 시행 그리고 만료에 대한 설정이 완전하지 않다는 반증이기도 하다. 만일 그런 경우에 해당되는 경우라면 별도 항목이나 프로젝트로 분리하는 것이 GTD 시스템을 보다 효과적으로 사용하는 방법이다. 그렇지 않다면 현재 업무 관리 시스템인 GTD 시스템을 관리하고 일이 지속되고 있다는 것이다.

물론 사람이란 것이 현재 그리고 앞으로의 진행 상황을 전체적으로 점검하는 것이 필요하다. 그리고 그러한 기능을 GTD에서는 정기적인 리뷰 단계에서 관리하도록 하고 있다. 결국 GTD 시스템의 각 단계적 진행이 아닌 전체적인 통합적 관리를 하고 있다면, 잘못된 것이라 못박을 수는 없지만 GTD 시스템의 활용성 측면에서는 한번 검토해볼만한 사안이다.

이런 문제가 OF가 Things를 비롯한 다른 GTD 시스템 프로그램에서는 큰 문제가 되지 않는다. 그러한 기능적 요소를 제공하지 않기 때문이다. 그러므로 이런 기능 자체의 유무를 평가할 일은 아니지만, OF에서와 같이 보다 GTD 시스템에 적합하도록 갖춰진 경우라면 그 활용성을 보다 적극적으로 이용해볼 필요도 있다.

결국 OF의 아웃라인 기능의 첫 번째 사용 가능 항목 보기나 사용 가능 항목 보기를 사용하지 않고 있다는 것은 프로젝트를 GTD 시스템의 방식이 아닌 일반적인 프로젝트 관리 체계의 방식으로 구성하고 관리하고 있기 때문이 아닐까 싶다. 개인적으로도 GTD 시스템과 프로젝트 관리 시스템을 구분하여 사용하고 있지만, 프로젝트 관리만으로도 벅찬 와중에 GTD 시스템을 별도로 관리하는 것이 쉽지는 않다고 보지만, 그렇기 때문에 또한 일부러 GTD 시스템을 활용할 필요도 있다고 본다.

GTD 시스템은 해야 하지만 또한 잊지 말아햐 할 일들을 사전에 인지하도록 해주는 역할을 해주며, 또한 아직 프로젝트 관리 프로그램으로 이전하기 전의 일상적 준비 등을 위해 운용하고 있다. 어차피 프로젝트가 시작되면 모든 것은 프로젝트 관리 체계에서 다뤄질 수 밖에 없다.

결론적으로 GTD 시스템의 프로젝트 관리 기능과 업무 실행 관리 기능을 명확하게 인식하고 사용하는 것이 OF의 활용성을 제대로 맛볼 수 있는 방안이라고 본다.

OmniFocus 3.12.2 업데이트

이런저런 이유로 어쩔 수 없이 운영체제를 계속 Mojave로 유지하다가 주말 마침내 Monterey로 업그레이드했다. 덕분에 OmniFocus 3.12 버전으로 업데이트가 가능하게 되었다. 3.12 버전에서 이전 3.11 버전과 크게 다른 바는 없지만, Monterey의 단축어 기능 지원 그리고 새로운 자동 기능과 관련하여 Omni Automation의 스크립트나 플러그-인을 사용할 수 있도록 했다. 상세한 기능적 사안은 확인해야 겠지만, GTD 시스템으로서 운용성에는 역시나 큰 효용성이 없지 않을까 싶기도 한다.

시간이 지날 수록 GTD 시스템의 운용성에 대한 OF3를 비롯한 어플리케이션의 한계를 넘어서기 위한 특별한 방안이 없는 상황에서 뭔가 새로운 것을 기대하는 바램은 포기해야 하지 않을까 싶다. 이러한 측면에서 과연 OmniFocus 4 for Mac은 어떤 식으로 변화될 지가 OmniFocus의 미래를 결정하는 기준이 될 지도 모르겠다.

Things 3.15.21 업데이트

Things 역시 OmniFocus와 마찬가지로 Mac의 새로운 운영체제가 업데이트가 됨에 따라 새로운 환경을 지원하는 기능을 수용하게 되지만, 이전 운영체제에서는 새로운 기능을 경험해볼 수 없다. 이미 macOS 12가 출시된 마당에 여전히 10.14에서 프로그램 운용에 따른 어려움이나 아쉬움이 점점 많아지고 있다.

Things 3.15의 출시에 따른 기능 추가와 개선 역시 새로운 운영체제를 중심으로 소개되고 있다. Things에 직접 입력이 아닌 macOS 혹은 iOS 환경의 단축 기능을 이용하는 것 보다 효율적 운용을 지원하겠다는 것이다.

하지만 새로운 숏컷 기능이 과연 얼마나 효용성이 있을 지는 의문이다. 또한 처리 속도 개선에 대한 사항도 이전 버전의 운용에 큰 문제가 없는 상황이라고 수치적 개선에 비해 체감적 개선은 크지 않을 것 같다.

솔직히 Mac mini 2018에서 Things 3.15의 구동 및 실행를 이전과 비교하여 느껴기란 쉽지 않았다.

항상 우려하는 사항이지만 GTD 프로그램이란 것이 조금 욕심을 내게되면 다른 기능적 프로그램과 바로 비교가 된다는 점에서, 기능적 개선의 구현이 기대한 바와 다를 수 있다.

보다 긍정적 시각으로 Things 3의 활용성을 찾기 위한 노력이 필요한 걸까?

일의 상대적 생산성 ?

지난 두어 달은 최근 들어 가장 바쁜 나날이었다. 마침 연말이 다가오니 그렇기도 하겠지만 계획한 프로젝트의 내용이 예상보다 더욱 복잡해짐에 따라 정신적 여유를 찾기가 힘들 지경이었다. 예전과 달리 육체적 활동에 따른 여파의 범위가 상당하다. 일단 다행히 한 고비, 두 고비 여러 내외부적 사안들이 정리되긴 했지만 남은 사안들은 그 나름대로 또 복잡하다.

특히 일에 사람이 관여되지 않을 수 없다 보니, 그런 일 외적(정량적으로 계획하지 못하) 요소들이 프로젝트 진행에 크고 작은 영향을 미칠 수 밖에 없고, 그런 문제들이 예상한 범위 내에 있기도 하지만 또한 전혀 예상치 못한 일로 전체 계획을 마구 흔들기도 했다.

계획이란 것이 계획대로 안된고, 기대란 것 역시 기대한 대로 안되는 것이 정상이라는 점에서 모든 사안의 발생 자체는 결국은 예상한 바이긴 하지만, 나도 사람이라 불길한 예상이 발생하는 것에는 정말 객관적으로 합리적으로 대응하기가 쉽지 않다.

하지만 의외로 일을 하거나 혹은 위임한 일의 진행을 보게 되면 정작 해야 하는 일의 진척이나 성과, 이른바 생산성 확보는 기대한 바가 최고치일 수 밖에 없다. 반면 굳이 하지 않아도 되며 또한 쓸데 없는 짓이라 생각되는 일의 생산성은 상상을 초월한 수준이다. 만일 해야 할 일과 쓸데 없는 짓이 같은 내용이라면 어떨까 싶은 생각이 간절하기도 했다.

결국 하기 싫은 일을 한다는 것 자체에 대한 생산성을 기대한다는 것은 장기적이며 결과적으로-비록 정량성 성과는 달성되었다 하더라도-의미없는 희망이다. 사실일 지 모르는 그 사실을 이미 알고 있고, 앞으로도 변하지 않을 것이지만 그럼에도 늘 기대를 하게 된다. 그렇지 않으면 계획 자체의 수립이 불가능하다.

다행히 쓸데 없는 짓이-타인에게는 효용성이 없지만-자신에게나마 나름의 의미가 있다면 그나마 다행이라고 생각한다. 최악은 당사자 스스로 쓸데 없는 짓이라는 것을 인정하는 경우이다. 물론 타인의 질책에 대한 외부적 변명이 대부분이지만, 간혹 진실되게 쓸데 없는 짓도 있다. 부디 담에는 쓸데 없는 짓에서 의미를 찾기를 바랄 뿐이다. 내 편견일 지 모르지만, 젊고 의욕이 넘치는 이의 경우가 적지 않아 더욱 우려된다.

다행히 내가 만들지도 소유하지도 그리고 딱히 애정 없는 회사이니, 소나기 피할 정도로 손실 발생의 범위를 최소화하는 대응으로 마무리하지만, 그리고 다음에는 그러지 않으면 좋겠다고 접어두지만 언제나 불길한 예상은 온전히 그대로 반복적으로 발생한다. 그럼에도 당사자는 영원히 인식하지 못하며, 인식 시키고자 하는 시도도 역시 역효과로 끝난다.

그래도 난 그 쓸데없는 짓이 한 개인에게 있어 무의미한 일이라 생각하지 않는다. 그래서 의미를 찾기 바라며 더불어 찾을 수 있도록 가능한 모든 범위 내에서 지원한다. 오늘도 지금도 쓸데 없는 짓이라 핀잔을 들으면서 숨어서 눈치보며 실행하는 많은 일들이 안전하게 그리고 기대한 의미를 찾을 수 있기를 바란다.

성공적 일 실행을 위한 GTD 유저의 아침 ?

새벽 녃에 눈을 떠 자신에 주어진 긴 연휴에 무언가 새로운 바를 기대하고 계획하는 자신에게,

얼마가 되었든 연휴든 주말이든 일상과 다른 하루는 새로움을 준다. 그리고 그 새로움은 언제나 미뤄두었던 일을 할 수 있는 기회로 생각된다. 그러나 언제나 그렇듯 새롭게 주어졌다고 생각하는 그 시간은 언제 있었느냐는 듯 지나가고 만다.

그렇다면 다시 새로운 아침, 이번에는 지금 월 해야 하지? 뭘 하고 싶은 지 ? 그리고 뭘 할 수 있는 지 고민하지 말고, 그냥 무엇이든 당장 시작하자. 그러면 그 일의 성공적으로 마무리될 지 안될 지는 몰라도 이번 연휴는 적어도 그 일을 한만큼 의미가 삶에 더해 질 것이다.

일반적으로 일을 바라 볼때, 해야 하는 일과 하고 싶은 일로 나눌 수 있다. 물론 두 가지 경우 모두 할 수 있는 일이어야 한다. 하지만 ‘두 가지 경우’라는 표현은 현실적으로 큰 의미가 없다는 것을 알고 있다. 해야 하는 일에는-어차피 하게 될 것이므로-고민이 필요 없기 때문이다. 다행인 것은 대부분의 해야 하는 일 가운데 일상의 삶과 관련된 주요한 일을 제외하고는 일의 결과가 생각하는 만큼 심각하지 않다. 그러니 시간 관리나 프로젝트의 대상이 해야 하는 일이라면 대개 얼마나 나중에 해도 괜찮은 가에 대해 스스로가 안심하는 과정이다.

그러니 일이 어떤 일이든 상관 말고 할 수 있는 일이 눈에 띄이면, 손에 잡히면, 혹은 마음에 있다면 당장 시작하자. 준비되지 않은 일이더라도 시작하자. 정말 준비되지 않았다면 곧 진행할 수 없는 상황을 맞딱드리게 될 것이고, 바로 중단하면 된다. 그 일은 그만큼 진행되었고, 다음에는 그 이후부터 다시 시작될 수도 있다. 분명한 것은 그 자체로 아무 것도 하지 않은 것에 비해 의미는 충분하다.

일상의 삶을 사는 많은 이들이 주어진 시간을-어떠한 의미나 가치가 있든-무언가 일을 하기 보다는, 어떤 일을 할까 어떻게 할까 심지어 어떤 순서로 할까 고민한다. 그리고 차라리 일을 하지 않기로 결정한 것보다 못한 결과에 스스로 실망하게 되는 경우도 잦다. 차라리 긴 연휴 비록 많은 할 일이 있더라도 아무런 계획없이 쉬는 것도 전체적인 일 처리 생산성 개선에 있어 감히 나쁘지 않은 선택이라고 할 수 있겠다.

돌이켜 볼때, 실행한 일에 대해서만 좋든 나쁘든 그 결과를 논할 수 있다. 그리고 그 결과로 중요하든 중요하지 않든 더욱이 해야만 하는 일로 진행할 수 있기도 하다. 실행하지 않은 일은 그 어떤 나쁜 결과보다 최악이라고 할 수 있다.

언제나 시간을 관리하고자 하며 시간을 소중하게 사용하려고 고민하지만 결국 그 창대한 고민 자체가 어쩌면 가장 시간을 무의미하게 낭비하는 일도 아닌 행위일지도 모른다.

PS. 하지만 멍하니 컴퓨터 모니터나 TV를 켜고 영화나 드라마 혹은 유튜브 채널을 보거나 그렇지 않으면 게임을 즐기더라도 마찬가지다. 만일 그 행위가 시간 낭비라고 생각한다면, 무수히 반복되는 계획만 하다가 느끼게 되는 시간 낭비에 대한 죄책감과 크게 다르지 않다. 차라리 그 편이 더 나을 지도 모르겠다.

Pagico 10 베타 8 테스트

Pagico는 버전 8을 사용하다가 버전 9로 업그레이드를 포기한 어플리케이션이다. 기능적으로 본다면 GTD 사용자에게 필요한 일반적 기능을 모두 갖추고 있는 표준적인 업무 및 시간 관리 체계의 하나라고 볼 수 있다. 하지만 Pagico 9의 경우는 경험해 보지 않아 모르겠지만 Pagico 8까지 경험에 비춰 본다면, 너무 기능이 많고 인터페이스도 복잡했다. 이러한 점은 누군가에는 Pagico의 특징으로 다가올 수 있겠지만, 상대적으로 Things 스타일에 익숙하다면 매우 복잡하고 답답할 수 있다고 본다.

개인적으로 Pagico 사용에서 가장 큰 불편함은 개별 항목과 프로젝트 간의 직접 전환이 지원되지 않는다는 것이다. 처음 항목 생성시 개별 업무나 리스트 그리고 프로젝트로 설정할 수 있지만, 이후 전환하면서 새로 작성되는 수준의 일이 필요하다.

이에 반해 Pagico 대시보드에서 제공하는 간트 챠트 스타일의 관리 체계는 기존 GTD 프로그램의 제한된 기능의 답답함을 크게 개선했다. 프로젝트 단위의 관리도 가능하기 때문에 OmniFocus의 계층적 구조 관리 방식의 한계에 극복할 수도 있다는 유혹을 외면하게 힘들다.

비슷하게 Trello의 인기 핵심이 타임라인 뷰라고 볼때 실질적 효용성을 떠나 사용자에게 있어 주는 기대감은 매우 주요한다고 본다.

그런 장단점을 가진 Pagico의 버전 10이 출시되면서 베타 테스트를 신청했고, 오늘 베타 테스트를 시작했다. 아마 기능적으로 볼때 Pagico 9의 기능에 기반하고 있지 않나 싶은데, 클라우드 기반으로 정보를 동기화하여 모바일 환경에서 운용성을 더욱 강화한 것 같다.

오랜만에 접하는 Pagico라 기대한 바가 큰데.. 하지만 베타 1의 경우 아무래도 클라우드 관련하여 Inbox 동기화 기능에 문제가 생긴 것 같다. 때문에 끊임없이 경고 메시지가 나타나는 통에 제대로 된 테스팅을 머뭇거리고 있다. 다행히 베타 2에서 동기화 문제는 바로 해결이 되었다. 하지만 테스트가 계속 될 수록 기존 기능과 새로운 기능 구동에 오류와 수정이 반복되고 있다.

이번 베타 테스트에서도 여전히 전통적인(?) Pagico의 불편함이 개선되어 보이지는 않는다. 반면 즉 특정 항목 리스트에 대한 정보가 화면의 여러 곳에 중복되어 나타나기도 한다. 물론 베타 버전이니 구동이 되지 않을 때도 있다.

예로 오늘 할 일의 목록을 보는 방법이 Today 항목에서 볼 수 있지만 Today 항목 자체가 표준 리스트는 물론 사용자 목록이나 화면 알림 표시 등 여러 곳에 동시에 있는 식이다. 언제라도 주요 리스트를 확인할 수 있는 점은 좋지만, 각 기능의 세부적 차이를 활용하지 못하는 경우라면 기본적인 기능이 시각적으로 부담이 된다.

물론 설정에서 이러한 사항을 수정할 수 있기는 하지만, 일부러 그런 수고가 초래된다는 점에서 사용자 입장에서는 오히려 부담이다.

GTD 수집 방식의 숨겨진 함정 ?

GTD를 처음 접하는 사람들이 쉽게 빠져드는 이유 중 하나가 수집이라는 단순하면서도 흥미로운 과정 혹은 단계라고 할 수 있다. 누구나 생각할 수 있으면 특별한 도구나 환경의 준비 없이 시작이 가능하기 때문이다. GTD의 인기는 수집 기능에 시작되었다고 해도 과언이 아니다.

하지만 곧 GTD의 실망 혹은 부담을 느끼기 사람들의 가장 큰 이유 중 하나 역시 수집이라는 어렵고 모호한 기술과 기능 때문이다. 시간이 지날 수록 수집해야 할 대상은 늘어나고, 수집된 대상에 대한 관리 부담은 더욱 가중되게 되고, 나중에는 수집 즉 관리 대상으로 해야할지 말지를 고민하다가 지치게 된다.

GTD의 수집 기능은 단순하고 특별한 상황에 이뤄지는 것이 아니라고 적었지만, 사람에 따라 혹은 경우에 따라 이 단순한 과정에 숨겨진 함정에 발이 빠질 수 있다. 그것은 GTD 수집 과정은 그저 컴퓨터 모니터를 바라고 보고 혹은 종이 위에 창작하듯 쓰는 절차적 기능으로 대부분 인식하고 있는 경우가 많기 때문이다.

예로 자신의 자동차에 관련된 여러 문제를 수집하여 실행하고자 할 때, 대부분은 자신의 늘 사용하는 자동차에 대한 모든 것을 알고 있다고 생각한다. 하지만 많은 경우에서 알 수 있듯 차 안에 앉아 혹은 운전하면서 느끼는 해결 혹은 대응해야 하는 크고 작은 생각거리는 차에서 내리고 나면 상당수 머리 속에서 사라진다. 운전하면서 수집 대상을 수집하기란 힘들다. 그렇다면 자동차에 관한 문제를 수집하기 위해서는 컴퓨터 앞이나 쇼파에 앉아 생각해야 하는 것이 아니라, 직접 자동차는 있는 곳으로 가서 둘러보고 자리에 앉아 어떤 문제를 생각했었는 지 기억을 돌이켜야 한다. 혹은 이후 운전하면서 그런 생각이 들때 잊지 않도록-안전하게-수집하는 방법도 생각해볼 필요가 있다.

이렇듯 자신이 생각하는 많은 문제를 수집할 때, 그 해당되는 문제의 대상을 보고 느끼며 수집하는 것이 아닌 모니터와 종이 위에 기록하는 것이 GTD 수집의 일상인 경우가 많다. 물론 이런한 방식이 나쁜 방법이거나 잘못된 방법은 아니다. 하지만 우리가 생각했던 많은 수집 대상으로의 문제를 다 잡아낼 수는 없다는 것이다.

나아가 이런 수집 방식에 의해 정작 수집되어야 할 여러 사안들이 드러나지 않고 숨어 계속적으로 우리의 머리 속을 휘젖고 다니면서 뭔가 아쉽거나 찜찜한 기분을 느끼게 한다는 것이다. 그러므로 수집 과정을 너무 단순하게 혹은 허술하게 인식해서는 안된다. 수집 과정의 이러한 문제는 GTD 시스템의 불안 요소로 자리잡을 수 있다.

희망과 바램의 시각 ?

하고 싶은 일임에도 일에 대한 부담이 너무 크고, 더불어 그 현실을 냉정하게 판단할 수 있다면 그 일은 실행될 수 없다. 그럼에도 시스템에서 머리 속에서 사라지거나 제거되지 않고 유령처럼 남아 있다는 것은 분명 나름의 의미를 가진 일이라고 볼 수도 있다. 더욱이 다른 대안도 없는 상태에서 계속 실행의 의욕으로만 남아 있다면 역시 다시 한번 냉정한 스스로의 평가를 필요로 한다. 물론 이러한 평가가 반복된다는 것은 매우 위험하다는 것을 알고 있을 것이다.

즉 포기할 것인지 그렇지 않으면 정말 실행할 수 있는 다시 말해 목표한 결과에 도달하고 목적한 바에 만족할 수 있는 일인가에 대한 평가를 제대로 진행해야 한다.

하지만 이러한 과정이 어려운 것은 그 일을 바라는 목적과 실행의 결과 목표가 과연 자신의 시각에 의한 것인지 혹은 타인의 시각에 의한 것인지를 먼저 냉철하게 전제해야 한다. 대부분의 업무는 자신의 의지나 시각이 아닌 회사나 CEO의 방침에 의해 진행된다. 때문에 모순적이거나 다소 불법적 영역에 있는 일 조차 시행하는 경우가 적지 않다.

그렇다면 자신이 자신의 일이라고 생각하는 영역에도 이러한 외부적 시각이나 판단이 관여할 수 있다는 점을 인정하고, 평가를 진행해야 한다. 대개 자신의 일이나 업무적 일을 혼돈하여 판단하기 십상이다.

자신의 아닌 타인의 시각 즉 타인의 평가에 관여되는 일은-비록 하고 싶은 일이라 착각한 경우에도-실행에 부담이 될 수 밖에 없다. 즉 하고 싶은 일이라고 스스로 판정하기 위해서는 실행과 결과의 평가에 타인이 얼마나 관여하는 지 혹은 나중에라도 관여될 수 있는 지로 그 수준을 결정할 수 있을 것이다.

사실 단순히 개인적으로 하고 싶은 일이라고 한다면 실제적으로는 GTD 시스템에서 관리될 필요가 없다. 마감일자나 시간 등을 자유롭게 그리고 생각날 때 하면 되는 일이라면 굳이 GTD와 같은 규정된 체계에 넣고 관리한다는 것은 매우 부자연스럽지 않을까 싶다.

그럼에도, 그런 사실을 알면서도 GTD 시스템에서 이런 일들을 관리하고자 한다면 그만큼 하고 싶은 일에 대한 열망과 목적 의식이 분명해야 제대로 관리될 수 있다. 그렇지 않으면 오히려 이러한 일 때문에 업무적으로든 개인적으로든 해야 할 일들의 관리가 방해받게 될 수도 있다.

현재 GTD 시스템에서 관리되지 못하고 머리 속을 가득 채운 온갖 일거리를 수집한 후, 일의 실행과 진행의 관리 가치와 수준을 정확하게 파악하고 최종적으로 관리되어야 한다고 결정한 일은 즉각 관리 모드로 전환해야 한다. 그리고 다시 한번 이러한 고민에 빠진다면 GTD 시스템에서 다룰 수 있는 영역을 벗어나 대상으로서 빼내거나 다른 기대하는 시스템으로 옮겨져야 한다.

실행 지원의 원인, 부담과 여유 ?

이전 포스팅에서 GTD 시스템에서 관리되어야 할 사항과 관리될 필요가 없는 사항이 제대로 구분되지 않고 뒤섞여 일상의 혼란스럽게 만들 수 있다는 적었다. 그 연장에서 GTD 시스템에 그러한 사항들이 제대로 수집, 즉 입력되지 못하는 경우에 대한 생각과 경험을 적고자 한다.

일을 두고 실행을 머뭇거리고 있다면 그 일에 대한 자신의 평가는 두 가지 경우라고 볼 수 있다. 우선 그 일의 실행에 대한 부담이다. 일의 목적 대비 목표의 규모와 범위가 크고 광범위하여 쉽게 시작하기 어려운 대상으로 판단될 때의 상황이라고 할 수 있다.

대개 하고 싶은 일이라고 생각하는 혹은 착각하는 대상들이 이러한 부류에 속한다. 어쩌면 할 수 없는 일이라고 판단될 가능성이 매우 높은 대상들이다. 물론 이런 경우에 대한 스스로의 평가는 객관적이기 어렵다. 하지만 이런 일에 대한 스스로의 평가가 지연될 수록 GTD 시스템은 할 수 없는 일이지만 하고 싶은 일로 오해되는 일들로 가득해지게 된다.

다른 경우는 단순히 보자면 무언가 대안이 존재하는 일이다. 즉 즉각적 실행을 해야 하는 일이지만-비공식적인-연기를 기대한 일을 대하는 상황이라 할 수 있다.

두 가지 경우 내용적으로 다르지만 현실적으로 계속 실행이 지연되면서 GTD 시스템을 떠도는 유령으로 남아있을 수 있다는 위험이 있다. 더욱이 이러한 일들이 시간이 지날 수록 점점 늘어날 수 밖에 없다는 것이다.

만일 이러한 일들의 상당수가 GTD 시스템에서 관리되지 못하고 외부에서 떠도는 경우도 적지 않을 것이다. 그나마 GTD 시스템에서는 현재 불안정한 상태를 파악이라고 할 수 있지만, 시스템 외부에서는 결국 머리 속에만 쌓여 있다가 느닷이 나타나 실행을 다짐하는 마음을 흔들게 된다.

이러한 문제의 해결책은 GTD 시스템의 운용에서 가장 핵심이라고 할 수 있는 즉각적 실행 외에는 답이 없다. 최소한 실행의 시도를 해야 실행 가능 여부로 인해 실질적 진행 정도와 계획 조정 등을 파악할 수 있다. 그렇지 않으면 계속 주변을 맴돌며 유령처럼 자신을 괴롭히게 된다.

아직 수집될 일이 가득하다 ?

만일 GTD 시스템의 효용성 나아가 신뢰성에 의문을 가진 경우라면, 점검해야 할 여러 사안 중 첫 번째가 관리되어야 할 모든 사안이 수집되어 관리되고 있느냐는 것과 점검하지 않아도 될 여러 사안이 괜히 수집되어 관리되고 있지 않느냐에 대한 것이다.

GTD 시스템을 사용하면서 의외로 많은 수집 자체에 흥미를 가지고 이것 저것 가리지 않고 수집 과정을 진행하게 되는데, 대개의 경우는 수집 과정에서 지치게 된다. 문제는 그러한 과정을 거치고 나면 수집에 부담을 느끼게 되고 실제 수집되어야 할 대상과 수집되지 않아도 돌 대상을 구분하기 쉽지 않은 상태로 몰리게 된다.

GTD 시스템이란 것이 다른 자기 계발이나 시간 관리 체계와 달리 정기적 점검이 매우 주요하다보니, 수집 단계에서부터 부담을 가지게 되면 이후 과정도 매우 불안정하게 된다.

그리고 GTD 시스템에서는 관리 효용성이 없는 잡다한 내용들로 깔끔하고 세련되게 구성된 프로젝트가 가득하지만, 현실적 관리는 전혀 하지 못하는 상태로 전락하게 된다.

이런 문제에 직면했다면 일차적 해결책은 제대로 된 수집 과정을 진행하는 것이다. 일단 옆에 수집함을 준비하고 머리 속에서 잠시 현실적 문제를 지운다. 그리고 수집한다. 수집하는 과정에서 현실적 문제 역시 가능한한 모두 수집되도록 한다.

수집 과정은 GTD의 가장 단순한 기구이면서도 가장 중요한 절차하는 사실을 항상 염두에 두어야 한다. 수집 과정에서 실제적 효용성을 생각할 필요는 없다. 이어지는 평가와 분류 과정에서 자연스럽게 정리될 수 있다. 수집 과정에서는 수집 대상에 평가가 아닌 수집 자체에 집중해야 한다.

GTD 시스템이 다른 여러 관리 체계와 비교하여 가장 부담이 없는 점은 프로젝트나 폴더 관리가 요구되지 않는다는 점이다. 하지만 많은 GTD 사용자들이 GTD 프로그램의 프로젝트를 프로젝트 관리 프로그램에서와 같이 구성하거나 항상의 절차를 아웃라인 프로그램처럼 구성하려고 한다. 애초 GTD 시스템이 그러한 관리 체계의 문제로 부터 벗어나기 위한 방식이라는 점을 생각하면, GTD 프로그램을 너무 혹사시키는 격이다.

이런 점 덕에 많은 GTD 시스템 혹은 GTD 프로그램 사용자들이 쉽게 GTD를 포기하거나 버리게 되는 것도 분명한 사실이라고 본다. 만일 현재의 상태에서 조금 더 나아간다면 GTD는 프로젝트 관리 체계로 변질될 수 있고, 다시금 업무 관리의 근본적 고민으로 되돌아 갈 수 밖에 없다.

Things 3.14.2 업데이트

Things 3.14 업데이트가 되면서 나름 효용성 있는 기능이 추가되었다. 단순히 기능적 추가로 생각할 수도 있겠지만 활용 방식에 따라 Things의 아쉬운 부분에 보완함에 큰 도움이 될 수도 있다고 생각된다.

새로 추가된 기능은 기본적으로 개별 항목에 관련된 사안이 아닌 노트 작성에 관한 것으로, 노트 내용의 목록화 즉 아웃라인 구성이 가능하도록 되었다. 아웃라인 구성 자체는 사용자가 적당하게 위치와 공백을 맞춰 작성할 수 있었지만, 이번 기능에서는 지정한 위치 및 사용한 기호와 동일하게 목록이 작성될 수 있다.

노트에 작성할 지 문서 파일을 링크 시킬 지 결정하기 애매한 상황에서도 요긴하게 활용할 수 있을 것이고, 내용이 긴 목록 작성을 위해 별도 어플리케이션을 이용하는 수고도 줄 수 있지 않을까 싶다.

그리고 이런 내용에서 눈치챌 수 있듯이 노트 및 아웃라인 기능의 활용성을 높일 수 있도록 마크업 언어인 마크다운(MarkDown) 기능을 지원할 수 있게 되었다. 사실 프로그램 환경도 아닌 GTD 프로그램 플랫폼으로서 Things에 이런 기능까지 필요한 지 의문스럽지만, CulturedCode의 표현으로 많은 사용자의 요청이 있었다고 한다. Mac 버전은 물론 iOS 버전에서 사용이 가능하다.

또한 이렇듯 노트 작성 기능이 강화되다 보니, 작성된 노트의 내용을 빠르게 검색하는 기능도 추가되었다. 확장된 노트 기능에 검색 기능이 부족했다면 사용하는 입장에서는 효용성이 반감될 수 있다는 측면에서 매우 효과적인 기능이라고 본다. 이런 점에서는 확실히 OmniGroup 보다는 CulturedCode의 대응이 더 나은 것이 분명하다. 역시 iOS 환겨에서도 검색이 가능하다.

마지막으로 새롭게 강화된 클라우드 동기화 기능의 하나가 클라우드, 구름에 빚댄 구름 조각. 프랙터스(Fractus) 기능이다. 일반적으로 Things 클라우드에 올려진 내용이 파일 단위로 항목 단위로 동기화 되었는데, 새로운 기능은 내용의 개별 단어 단위로 동기화가 될 수 있도록 하여 클라우드 운용 속도를 개선할 수 있게 되었다고 한다.

솔직히 Things가 문서 편집 도구도 아니면서 이런 기능까지 신경을 쓰나 싶은데, 어떤 식으로 효용성이 있을 지는 아직 모르겠다.

3.14 업데이트로 추가된 기능은 사용자의 Things 활용 방식에 따라 그 활용성이 매우 클 수 있다는 점에서 기대 이상이라고 본다. OmniFocus든 Things든 GTD 프로그램으로서의 단순한 기능 구성에 한계를 어떤 식으로 극복할 지에 대한 대응 과정의 하나라고 보인다는 점에서 앞으로의 기능 추가도 다시금 기대가 되기도 한다.

OmniFocus 4 for iOS 베타 테스트

OmniFocus 4의 베타 베스트가 시작되었다. 우선 iOS 및 WatchOS 기반 베타를 시작하게 되었는데, Apple Watch는 사용하지 않으니 그냥 지나고 iPhone에 설치하여 변화의 수준을 확인할 기회가 왔다.

이번에는 애플 앱스토어의 테스트플라이트 기능을 사용할 수 있도록 전환되었는데, 여러모로 편리하지 않나 싶고 OmniGroup에서의 관리 용이성도 높을 듯 하다.

OmniGroup이 이-메일 링크로 다운로드가 시작되고 설치되어 그런지 따로 베타 코드를 입력하지 않아도 구동이 가능했다.

실제적 사용은 좀더 시간이 걸리겠지만 첫 느낌은 이전 버전에 비해 인터페이스 조금 복잡하다 내지는 어렵게 배치되었지 않나 싶다. 새로운 기능의 추가로 인해 당연히 그렇게 될 수 밖에 없을 수도 있겠지만, 스마트폰과 같은 모바일 환경에 너무 많은 기능을 담다보니 기능과 별개로 인터페이스의 이러한 복잡성 문제가 OmniFocus의 어려움이지 않나 싶기도 하다. 하지만 과연 얼마나 새로울 지는 모르겠다.

솔직히 OmniFocus의 기능적 창의성은 이제 한계를 맞이한 지 오래되었다고 보는 입장에서, OmniFocus를 Mac, iPhone, iPad 그리고 Apple Watch 등 각 기기에 맞도록 설계하고 또한 독자적으로 운용하도록 하는 방법이 적절한 지는 모르겠다.

Things나 The Hit Lists처럼 구성이나 내용이 상대적으로 단순한 프로그램도 점차 기능이 확장되면서 모바일 버전에서는 사용 효용성이 낮아지고 있다. 더욱이 애초부터 복잡하고 다양한 기능으로 승부했던 OmniFocus가 모바일 버전에서도 최대한 그 기능을 모두 수용하려고 하니-그 인기에도 불구하고-사용자 입장에서 제대로 대응하기 어렵다. 오히려 Mac 버전을 중심으로 iPhone 등은 입력 및 확인 등에 특화된 보조 수단으로 활용하는 방법도 좋지 않을까 싶다. 물론 iPad의 경우는 인터페이스 측면에서 유연성이 높다보니 다소 경우를 다를 수도 있다고 본다.

• 베타 테스트라서 그럴 것이라고 생각되지만, 현재 버전에서는 위치 정보 기능이 빠져 있다. iOS 버전의 OmniFocus의 유일한 핵심 기능이라고 할 수 있는데, 설마 향후 제거할 계획인가 ?

블로그 포스팅 오류로 인한 이전 포스팅 정비 중.. T T

한창 더운 여름날의 주말, 예기치 않은 포스팅 오류로 이전 포스팅까지 삭제되는 사태가 발생했습니다. 포스팅 원본 내용은 MacJournal에 그대로 있기 때문에 사라질 위험은 없지만, 이전 내용을 다시 일괄로 업로드 할 수 없어 개별 포스팅을 하나 씩 복구해서 다시 올리고 있습니다.

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

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

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

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

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

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

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

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

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

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의 계층적 업무 관리 체계의 불편함을 극복하려고 하는 것은 잘못된 판단이라고 본다.

E-메일 관리, 풍요 속의 빈곤 - 그 시작 ?

GTD 시스템, 소프트웨어가 아닌 관리 체계로서 골치 아픈 대상의 하나가 이-메일 메시지라는 것은 다시 강조할 필요가 없을 것이다. 블로그의 수 많은 포스팅에서도 이-메일 관리에 대한 의견과 대응을 적었다. 그러한 문제의 원인 중 하나가 예전과 달리 이-메일 계정의 생성이 쉽다보니 마음만 먹으면 수십 개의 이-메일 계정을 소유할 수도 있다. 특히 요즈음처럼 사용자 인증을 이-메일로 하는 경우 특별한 용도의 웹 서비스를 위한 별도 이-메일 계정을 만들어 사용하기도 한다. 어느 순간 자신의 얼마나 많은 이-메일 계정이 있는 지에 놀라는 경우도 있다. 반면 수십년 동안 한두 개의 이-메일 계정을 사용하는 경우도 결코 적지 않다. 이렇듯 많고 적든 이-메일 계정이란 것은 하나 생성하고 나서는 사용하지 않은 경우에도 중지나 제거 등을 하지 않고 결국 쌓인다. 사실 이런 경우는 문제가 될 것이 없다. 사용하지 않은 이-메일로 특별한 메시지가 올 경우도 드물고 오더라도 대부분 스팸이나 광고성 메시지이니 무시해도 상관없다.

하지만 특별한 경우인지는 모르지만 나의 경우는 꽤 많은 이-메일 계정을 사용한다. 일상적으로 사용하는 계정만 보더라도 대여섯 개는 넘고 관리하는 계정은 거의 십여 여개에 달한다. 개인용 한두 개, 업무용 두세 개, 외부용 한 두 개 등등, 생각해보면 정말 이렇게 이-메일 계정이 많아야 했는 지 의문이 들기도 한다. 하지만 이 정도 역시 제법 많이 그리고 주기적으로 정리한 것이라는 점이다.

그러므로 이-메일 관리의 가장 근간은 또 다시 강조하지만 사용하지 않거나 사용 빈도가 적인 이-메일 계정을 과감하게 삭제하는 것이다. 라이센스 등에 등록된경우라면 이-메일 변경이 가능한 지 혹은 단순한 로그인 네임으로만 사용되는 지 등을 파악하여 정리할 수도 있을 것이다. 만약 그럴 수 없다면 이-메일 계정의 포워딩 서비스를-가능하다면-이용하거나 혹은 별도의 이-메일 클라이언트를 이용하여 해당되는 모든 이-메일 계정을 나름대로 통합하여 관리하는 방법이 있을 것이다. 개인적으로 Spark 이-메일 클라이언트를 사용하여 후자의 방법을 사용한다. Spark의 다양하고 강력한 기능에 반한 애용자라면 지탄할 대응이 아닐까 싶다.

사실 한국에 살면서 네이버, 다음 등 이른바 포털을 사용하지 않을 수는 없고, 일단 작은 용도라면 사용하게 되면 이-메일 계정이 자동으로 생기고 시스템 관련 메시지가 해당 이-메일 계정으로 날라오는 어쩔 수 없지 않나 싶기도 하다. 이런 웹 기반 서비스의 이-메일 계정 가운데 IMAP나 POP3를 지원하지 않는 경우가 있다면 애무 당황스러울 것이다. 요즈음 업무 환경이 웹 기반으로 바뀌다보니 그런 경우가 의외로 적지 않은 것 같다. 나 역시 꽤나 오랜 시간 몸소 그런 경우를 겪어야 했다. 대개 웹 기반 메일 관리에 특별히 거부감이 없겠지만, 처음부터 이-메일 클라이언트 기반으로 메시지를 관리해 온 습관 덕에 웹 기반 이-메일 운용은 내게 있어 정말 어색하다.

물론 지금까지 넋두리처럼 적은 이야기는 실제 접하게 될 수 많은 이-메일 메시지 기반의 업무 관리나 GTD 시스템 운용에서 발생하는 여러 문제에 비하자면 문제라고 부르기도 어려운 수준이다. 더욱이 같은 이-메일 서비스가 컴퓨터 시스템, 운영체제 그리고 이-메일 클라이언트에 따라 서비스 수준이나 기능에 일관성이 없다며 정말 난감하다. GTD 사용자로서 앞으로 다루고자 하는 이-메일 메시지 관리의 많은 문제들이 그러한 요소에 기인하고 있기도 하다.

다양한 이-메일 서비스의 선택 혹은 선택의 여지 없는 사용, Windows나 macOS와 같은 특정 운영체제에서 구동되는 이-메일 클라이언트 성능과 기능의 문제, 더불어 예기치 못한 크고 작은 문제들로 인해 이-메일 서비스 자체를 포기해야 하는 등의 경우를 심심찮게 겪어 왔다. 그리고 그 가운데 여전히 해결되지 않은 문제가 이어지고 있다. 아마도 컴퓨터 시스템이나 스마트 폰의 일상이나 업무의 핵심 도구로 자리잡고 있는 가운데 여러 개의 이-메일 계정을 함께 운용하는 경우라면 비슷한 경험을 하고 있을 것이라 생각든다.

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

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

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

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

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

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

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

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

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

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

할 수 있는 일의 시작과 함정

사람들은 자신이 잘할 수 있는 생각하는 일이 언제나 그 잘할 수 있음의 대상으로서 지속된다고 생각한다. 때문에 일의 우선 순위에서 할 수 있는 일, 잘 할 수 있는 일은 뒤로 미뤄두고 지금 해야 하는 일에 집중하게 된다. 하지만 매 계절, 매 년 우리는 언제나 할 수 있는 일이나 하고 싶은 일들이 일 목록에 그대로 올려지 있음을 확인한다. 언제든 할 수 있는 일이기에 또 지금 고민할 일이 아니라고 평가하면서 다시금 뒤로 미루게 된다. 할 수 있는 일이니 시작은 언제하든 무슨 상관이겠는가. 시간이나 노력이 아닌 결심의 문제일 뿐이다. 하지만 대개는 심각한 착각이다.

과격한 비교일지 모르겠지만 주변에서 퇴직 후 혹은 기존 사업을 정리하고 새로운 창업을 하는 경우를 보면, 그 일을 비즈니스라 부르든 사업이라 부르든 혹은 장사라 부르든 이른바 창업에 대한 결정은 선택의 여지가 다양한 경우가 아닌 최후의 방안으로 창업에 뛰어든 사례가 많다.

자신이 잘 하는 일에 발휘할 역량을 대부분을 소모한 후, 선택의 여지가 없는 상황에서 창업을 하게 된다. 덕분에 마음 고생, 몸 고생 등 갖은 노고에도 불구하고 기대한 바를 얻기는 힘들다. 자신이 잘할 수 있다는 기대 외 다른 주변 역량을 모두 소진된 상태이니 결과는 충분히 예상될 수 있다.

할 수 있는 일을, 더욱이 하고 싶은 일이라면 그 일을 한 시점은 바로 지금이라고 할 수 있다. 아마도 지금 가장 잘 할 수 있는 일이라고 본다. 물론 미뤄도 아무 문제가 없을 수 있다. 그렇다면 더더욱 지금 처리하는 것이 가장 안전한다. 진행에 시간이 오래 걸린다면 지금이라도 시작해야 하지 않을까 한다.

할 수 있이나 하고 싶은 일이 있다면 가장 그 일을 잘 할 수 있는 지금이어야 한다. 그렇지 않으면 할 수 없은 일이 될 수도 있고, 더 심각하게는 하기 싫은 일이 될 수도 있다. 그럼 오랜 시간이 지난 후 자신이 하고 싶었던 잘 할 수 있다고 생각했던 일이 실상 할 수 없는 일이었고 하고 싶은 일로 착각하고 있었다는 것을 알게 된다. 얼마 남지 않은 시간을 다시금 하고 싶은 일을 찾거나 하고 싶은 일인지 스스로 고민에 빠져 허우적거리게 된 이들이 여전히 주변에 많다.

코로나로 인한 활동 제약의 순기능 ?

코로나 19 사태로 인해 수 많은 일을 겪었고 그리고 그로 인해 우리의 일상에 큰 변화를 맞이했다. 하지만 그러한 변화가 누구도 예상치 못하게 지속되었고 앞으로도 지속될 것으로 예상되고 있다. 덕분에 많은 일상의 변화가 더 이상 변화가 아닌 일상이 되어 가고 있다. 그 가운데 전에는 정말 예상치 못한 것이 업무와 관련한 사람을 직접 만나는 일이 필수적인 경우에서 가능한 지양해야 할 선택적 사안으로 변했다는 점이다.

만나러 간다는 자체도 찜찜하지만 만나야 하는 입장도 마찬가지다. 그래서 전화나 이-메일 혹은 화상 회의를 진행하기도 한다. 처음에는 어렵고 낯설었지만 어느새 일상이고, 그러한 상황에서 더욱 간편한 회의 환경을 만들거나 또는 단순화하고자 노력하고 있다. 심지어 회사나 학교 내에서는 다르지 않다. 이런 대응에 부정적 시각을 가진 이라도 몇 차례 직접적 주변에서 확진자가 나오고, 격리 상황을 겪고 나면 자연스럽게 비대면의 상황을 추구하게 된다. 물론 그럼에도 세상 다 산듯 막무가내인 경우도 없지는 않다.

이러한 변화는 관련된 많은 주변 산업에 영향을 미치고 있다. 관광을 위한 국내외 여행이 아닌 업무적 활동이 차지하는 비중이 상당한 여행이나 숙박 업계 등은 엎친데 겹친 겪이 아닐까 싶다. 사실 사업차 출장은 빈도는 적지만-자기 돈 쓰는 것이 아니라는 입장에서-씀씀이는 큰 편이다. 교통비나 유류비 지원을 편하게 요청할 수 없는 직급 낮은 이들도 고민스럽기는 마찬가지일 것이다.

그리고 한번 이러한 상황을 겪은 기업이나 학교에서는 출장 자체의 가치 혹은 출장에서의 비용에 대한 효용성을 보는 시각이 매우 냉정해졌다. 함께 하는 이도 줄었고 덕분에 씀씀이도 줄게 되고 그로 인해 결제의 빈도 역시 줄게된 덕에 비용 지출이 보다 쉽게 드러나게 되었다. 예전 같으면 업무적 비용에 개인적 비용이 묻혀지는 경우가 허다했지만 지금은 사실상 그런 식으로 대응하기란 쉽지 않다.

그러니 출장을 가서도 활동이 예전처럼 자유롭지 못하다. 움직이는 돈이 드는데, 장소와 내역이 쉽게 드러나니 허튼 짓 하기가 쉽지 않다. 그런 이유로 점점 출장 당사자들도 출장 자체를 꺼리게 된다. 문제가 지금까지 출장을 가야만했던 일의 상당한 부분이 아무런 문제없이 처리된다고는 것이고, 그로 인해 다음 출장 승낙을 기대하기가 어렵게 되었다는 것이다.

하지만 이러한 변화에 적응하지 못하고 전전긍긍하는 이들도 적지 않다. 디지털 기기나 소프트웨어 활용에 익숙지 않다면 온라인 화상 회의 등의 사용은 물론 낯선 상황에서의 업무 진행에서도 문제가 발생하고, 그로 인해 많은 일들이 취소 되거나 수정되기도 한다. 예로 학교라면 많은 학생들이 제대로 학교에 가서 수업을 받지도 못한 상태에선 값비싼 등록금의 가치를 느끼게 어렵게 되었고, 선생들도 온라인 강의에 노력한 수고가 학생들에게 온전히 전달되었는 지 확인하기 매우 어렵다.

짧은 학기를 가진 전문대학 등에서는 학생들이 제대로 학교를 가보지도 못한 채 졸업을 맞이하게 되는 정말 황당스러운 상황을 겪게 되었다. 물론 현재 상황으로 보아 4년제 대학교의 경우도 만만치 없는 상황을 맞고 있다. 이들에게 대학생으로서 시간은 어떤 의미로 생에 남을 지 안타깝다.

이러한 외부 활동 제약이 적지 않게 비용 지출을 줄이게 만들었다는 사실은 분명하다. 하지만 그 내용적 여부에 상관 없이 지속될 것이라는 사실에서 걱정과 우려를 하지 않을 수 없는 상황인 것도 분명하다.

빠른 맥으로 내 일상이 달라지지 않은 듯 ?

이미 한 세대를 지난 맥 사용자로서 애플의 제품 라인이 애플의 자체 마이크로프로세서, 즉 애플 실리콘으로 전환되고 있고, 또 출시된 M1 마이크로프로세서 탑재 모델의 성능에 대해-나의 예상과 달리-매우 우호적이다. 현재 나는 맥 미니 2018과 맥북프로 2011 13-인치를 사용하고 가끔씩 아내의 맥북프로 2019 13-인치를 몰래 사용하고 있다.

사실 맥 미니 2018이나 맥북프로 2019를 구입하게 된 것은 성능과 기능의 문제라기 보다는 맥북프로 2011에서 Mojave 운용체제의 지원가 공식적으로 중단되면서 대응하기 위한 방법이었다. 그렇다, 나의 GTD 시스템의 OmniFocus가 3.11 버전으로 업데이트되면서 Mojave 이상을 요구하기 시작했다. 그리고 OmniOutliner 5 마저 5.8 버전 이후부터 Mojave 이상을 요구했다.

그렇더라도 DevonThink와 Scrivener는 여전히 구형 OS에서도 잘 작동하기 때문에 버텨 볼 생각이었지만, 새로운 프로젝트 수행에 따른 시스템 구입 기회가 온 덕분에 마련할 수 있게 되었다.

그렇더라도 맥 미니 2018과 맥북프로 2019 모두 마이크로프로세서, CPU는 기본 사양으로 하고 여력의 비용으로는 메모리를 왕창 늘리고 주변기기 운용을 위한 여러 어댑터를 확보했다.

하지만 예전 같았다면 메모리나 내부 저장 장치 용량 보다는 우선 가장 빠른 CPU를 먼저 선정하고 나머지를 어떻게 구성하느냐로 고민했을 것이다. 언제부터인가 내게 있어 컴퓨터 시스템을 선택함에 있어 CPU는 가장 후순위로 밀려나게 되었다.

정확하게 언제인지는 기억나질 않지만 한참 워크스테이션이나 서버 도입의 최우선 기준이 ‘빠름’이었다. HP-UX 기반 워크스테이션과 서버를 사용하던 시절이었으니, CPU의 갯수가 늘어나거나 클럭 수가 한 단계 업그레이드 되는 건 거짓말 조금 보태서 거의 새로운 본체를 하나 구입하는 거랑 비슷한 수준이었다.

연구 개발의 성과는 빠른 CPU, 넘치는 메모리, 그리고 역시 빠른 3D 그래픽스 가속 장치에 의해 결정된다고 확신했다. 그리고 기대한 연구 성과가 부진한 탓을 컴퓨터 시스템의 성능 부족이나 필요한 소프트웨어의 부재로 변명했다.

하지만 명필은 붓을 탓하지 않는다고 했다는데, 어느 날 나의 연구 분야에서 세계 제일의 연구 성과를 내고 있는 미국의 모 대학의 P 교수 연구실을 보게 되었다. 사실 그의 명성에 비유하자만 연구실에 슈퍼 컴퓨터가 들어 앉아 있다고 해도 누구도 의문을 가지지 않을 수준이었다. 그러나 놀랍게도 그리고 당황스럽게도 그의 연구실에 있는 시스템은 출시된 지 한참이나 지금 더욱이 성능으로 보자면 도저히 이해할 수 있는 SGI와 SUN의 엔트리 레벨 워크스테이션들이 가득 했다. 정말 이게 다인지 눈을 의심했다.

사실 냉정하게 생각해보면 기하학적 이론에 기반한 3차원 비선형 곡면 모델링 연구에 고성능의 워크스테이션이나 서버가 반드시 요구되는 것은 아니다. 물론 있으면 좋겠지만 없어도 상관없다. 아무리 그렇더라도 내가 사용하는 하는 시스템에 비해 아마 열배는 느릴 것 같은 구형 시스템으로 그런 성과를 내고 있다는 것에 충격을 넘어 당황스럽고 황당하기까지 했다.

연구비는 차고 넘칠 것이니 일부러 그런 시스템을 여전히 사용하고 있다면 정말 그 자체로 충분하다는 것이다. 아니면 정말 학교 지하에 전용 슈퍼 컴퓨터를 숨겨 놓았는 지도 모르겠다.

어쨌든 이후 나의 빠른 컴퓨터에 대한 욕심 내지는 욕망은 일상의 우선 순위에서 다소 밀려나게 되었다. 물론 학교나 회사에서 시스템을 새로 구입하도록 해준다는 것에 대해 굳이 마다하지는 않았지만 개인적인 구입에 있어서는 빠른 성능 보다는 가능한 오래 사용할 수 있는 즉 업그레이드가 보장되는 제품 선택이 우선하게 되었다. 사실 비용적인 측면에서 보자면 후자가 더 비효율적일 수도 있다.

그래서 애플이 68K에서 PowerPC로 다시 X86으로 그리고 마침내 애플 실리콘으로 전환할 때에도 특별히 기대나 희망을 가지지 않았다. 더욱이 애플의 제품이나 아무리 속도나 빠르더라도 결구 지원 소프트웨어의 한계가 분명하니 결과는 예상하지 않아도 누구나 알 수 있었다. 물론 X86으로의 전환은 그 이전에 비해 매우 성공적이었다고 본다. 그러나 애플 실리콘으로 전환은 일단은 나쁘지 않은 선택이라고 하지만 최종 결과는 과연 어떻게 될지 누가 알겠는가.

빠른 업무 처리나 연구 개발의 완성을 위해 빠른 컴퓨터 시스템이 최우선적이라고 강변하는 이들을 보면 웃으면서 내 경험을 이야기해주기도 한다. 그리고 그 빠름으로 과연 오늘과 얼마나 다른 성과를 담보할 수 있는 지 스스로 한번 평가하는 시간을 가져보라고 한다. 충분 조건은 분명하지만 실제 필요 조건인지는 의문스러울 수 있을 것이다.

주변에서 오랜 맥 사용자인 내게 애플 새로운 M1 마이크로프로세서 그리고 곧 예고되는 M2 마이크로프로세서를 탑재한 맥 모델의 등장에 개인적으로 구입 의사에 대한 판단을 묻는 경우가 잦다. 그러면 한 마디만 해준다. 한/글(아래아 한글)이 현재 사용하고 있는 라이센스로 구동되지 않으니 직접 구입하셔야 합니다. 그리고 그 대응은 한결 같다.

클라우드 기반 서비스의 배신

주변에 클라우드 추종자가 적지 않다. 나 역시 개인 용도의 드랍박스와 마이크로소프트와 구글의 비즈니스 서비스를 사용하고 있지만, 그저 개인용 파일 공유나 백업 용도가 주라고 할 수 있다. 이제 업무 관련한 파일의 공유는 거의 클라우드 기반이 핵심 환경이다. 이제 클라우드 서비스 자체를 인식하지 못하고 있는 상황이다.

세 개의 클라우드 서비스 가운데 중심은 현재까지 마이크로소프트의 원 드라이브(OneDrive for Business)였다. 드랍박스의 프로페셔널 서비스를 포기한 이래, 용량 문제로 원 드라이브를 계속 사용해왔지만(각 1TB의 두 개 계정을 사용하고 있다), 의외로 자주 오류를 경험하고 있다. 전체적인 서비스 문제이기도 하고 자주 동기화 문제를 겪기도 한다. 얼마전에는 아예 동기화 자체가 한동안 수행되지 않기도 했다.

하지만 가장 큰 문제는 원 드라이브의 경우 새로 서비스가 시작되는 경우, 기존 파일에 대한 전체적인 동기화 점검을 매번 수행한다는 것이다. 거의 1TB에 달하는 용량의 동기화는 네트워크 상황에 따라 다르긴 하지만 짧게는 수 시간에서 길게는 하루를 넘기도 했다. 더욱이 Windows 환경과 macOS 환경 간의 동기화 문제도 만만치 않다.

이번에는 동기화 부재 사태가 몇 시간 단위에서 끝나지 않았다. 거의 하루를 넘어 지속되었고, 몇 번의 서비스 재시작이나 시스템 리부팅을 통해서도 해결되지 않아 결국 원 드라이브 재설치를 통해 다시 동기화를 수행했다. 하지만 동기화 자체 역시 매우 불안한 상태로 진행되고 있었다.

그래서 급하게 구글 G Suite 서비스의 구글 드라이브로 전환했다. 다만 순간 구글 드라이브와 백업 및 동기화 기능의 충돌로 당황하기도 했다. 사실 앞서 언급한 원 드라이브의 문제는 다른 클라우드 서비스에서도 종종 발생한다. 원 드라이브 못지 않게 사람을 괴롭히는 것은 역시 애플의 아이클라우드 동기화와 관련되어 있다. 구글 역시 앞서와 같은 문제로 계속 신경을 쓰게 만들고 있다. 역시 드랍박스만한 서비스가 없단 말인가?

사실 드랍박스를 사용하는 것도 나쁘지 않지만, 비용적 부담을 떠나 상대적으로 단순한 원격 파일 저장소로서의 기능이 핵심이다 보니 다른 환경적 서비스와는 차이가 있어 전환후에는 결국 다른 불편한 문제가 생길 것이 뻔하다 보니. 어느새 파일 저장소 이상의 활용 범위로 클라우드 서비스 환경이 확장되어 버린 탓인 것 같다.

이제 대부분의 주요한 서비스도 클라우드 기반으로 진화하고 확장하고 있다. PDM/PLM은 물론 3D CAD까지 클라우드 기반으로 출시되고 있는 상황이다. PLM이 클라우드 기반으로 운용된다면 다른 서비스는 굳이 언급할 필요가 없을 것이다. 하지만 ERP나 PDM/PLM이 클라우드로 운용되는 동안 네트워크 연결 혹은 속도 문제가 발생하면 어떤 사태가 발생할 지 알 수 없다. 물론 이에 대한 대응 조치를 위한 서버나 서비스를 별도로 마련할 수도 있지만, 결국 네트워크 연결이 끊어지면 어떤 경우라도 최악이다.

생각해보니 클라우드 서비스가 주는 효용성에 비례하여 문제 발생에 따른 충격은 절망적인 수준이었다. 클라우드 서비스 역시 어딘 가에 있을 오프라인 서버에 기반하고 있을 것이다. 물론 클러스터로 연결되어 서비스 중단 사태는 거의 없을 것이라고 한다. 물론 그 수치적인 값은 현실적으로 무중단에 가깝다. 그러나 완벽하지 않으니 그 불완전함에 언제 내가 닥칠 지 모른다.

결국 클라우드 서비스의 배신이 두려워 둘 이상의 클라우드 서비스를 사용하거나 따로 서버를 마련해서 백업하는 모순적 상황이 발생하고 있다. 답이라고 해서 항상 정답은 아닌 것 같다. 새로운 기술이 현재의 문제를 해결하는 그저 작은 시도일 뿐이 분명하다.

좋은 도구 혹은 필요한 도구

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

이런 경우는 소프트웨어뿐 아니라 일상의 다양한 도구들에서도 다르지 않았다. 집안에서 하는 운동 기구를 구입하고 나서 몇번 사용하지 않고 옷거리나 장식대가 된 경험은 누구가 있을 듯 하다. 가정에서 필요로 하는 여러 공구 등도 마찬가지이다. 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든 혹은 다른 프로그램 역시 사용자에 따라 구성과 운용이 다르다는 점에서 좀더 구체적이고 실제적인 예로서 효율적 사용에 관한 내용을 다루고자 한다.