참고는 참고일 뿐, 컨텍스트는 자신의 것이다.
돌이켜 볼 때 GTD 시스템를 나름(!) 복잡한 삶에 적용하고자 나 역시 별의별 짓을 다했다고 생각한다. GTD 시스템의 현실적 운용에서는 항상 많은 것들이 의문스러웠다. 예로 컨텍스트라는 필요 조건이 만족되었고 일의 실행에 남은 것은 오직 나의 실천 의지 만이 있을 뿐이었다. 하지만 컨텍스트 조건의 충족 여부와 상관없이 일은 제대로도 원활하게도 실행되지 않았고 여전히 GTD 시스템이 아닌 머릿 속에 남아 있는 경우를 겪게 되었다. 이에 대하여 근본적인 원인과 해결 방안을 찾게되면서 나의 GTD 시스템에서의 컨텍스트가 너무나 형식적이지 않은 가에 대한 의문이 들었다. 이전 컨텍스트의 선택이라는 포스팅에서와 같이 나의 컨텍스트로 일반적인 구성에게 크게 벗어나 있지는 않다. 덕분에 생각해보면 일의 컨텍스트 지정을 이미 규정한 몇 가지 컨텍스트 구조에 맞추려고 애를 쓰는 것 같았다. 사실 그렇게 하는 것이 더 효율적이라고 생각했다.
그렇다면 현재의 컨텍스트 구조가 현실적이지 못하다 것인가? 물론 이러한 문제의 답이 멀티 컨텍스트는 분명 아니다. 멀티 컨텍스트를 사용하지 않는다면 가장 중요한 핵심 사안을 컨텍스트로 지정하게 된다. 이것은 핵심 컨텍스트가 되지 못한 많은 다른 부수적인 조건들의 충족을 전제로 한다. 하지만 GTD 시스템에서 컨텍스트가 지정된 일에 대하여 그 지정된 항목에만 집중하게 되는 경우가 많았다. 덕분에 컨텍스트의 충족에도 불구하고 일의 진척을 더디거나 시작도 못하는 경우도 발생했다.
이에 대한 나의 해결책은 크게 몇 가지로 구분하였다. 우선 가장 일반적인 방법으로써 하나의 일을 가능한한 최소 단위로 구분하여 컨텍스트를 지정하는 것이었다. 물론 이러한 방법은 일을 세부화하는 과정에서 너무 비효율적인 구분까지 진행되기고 했다. 분명 단순하고 쉬우면서도 어렵고 복잡한 일이기도 하다. 또 다른 방법은 프로젝트로 운용하는 것이다. 내부적인 방법이야 동일하다고 보겠지만 하나의 프로젝트로 만들고 컨텍스트 조건으로 세부적인 일을 구분하는 것이었다. 시각을 달리하여 컨텍스트를 구체적으로 세분화하는 방법도 있다. GTD 시스템의 운용을 시작하게 될 때, 컨텍스트의 구성과 구조를 너무 정형화하는 실수를 저지르기도 한다. 즉, 이미 GTD 시스템을 사용하면서 이에 대한 소개를 한 웹 사이트나 블로그 등의 컨텍스트 구조를 참고가 아닌 그대로 자신의 시스템에 적용하려고 하는 경우가 있다. 여기에서 컨텍스트에 대한 우리의 착각이 시작된다. 컨텍스트란 자신의 업무 범위에 따라 스스로 설정하는 것이 핵심 임에도 레퍼런스에 집중하므로 써 컨텍스트에 자신의 시스템이나 업무 스타일을 맞추려고 하는 일을 벌이게 된다. 더 나아가 컨텍스트를 장식하려는 경우도 있다. 일의 수행에 솔직한 전제조건이 아니라 우아한(?) 구성에 억지로 맞추려고 하는 것이다. 마치 부모가 읽을 것을 아는 어린 아이의 일기처럼.
결국 GTD 시스템을 접하게 되면 컨텍스트라는 조건이 마치 일을 완료시켜주는 사안인 것처럼 착각하는 경우가 많다는 것이다. 마치 컨텍스트가 GTD 시스템 내에서 만들어져 있는 것처럼 생각하는 경우로 볼 수 있다. 자신을 삶을 투영하는 컨텍스트를 만드는 것은 자신이 가장 잘 할 수 있는 일임에도 대부분의 사용자들은 무언가 확실하고 명쾌하면서 만족할만한 컨텍스트의 예를 찾기위해 애쓰는 모습이 보인다.
PS. 하나의 일을 여러 개의 일로 나눈 것과 프로젝트로 만드는 것의 차이는 의외로 간단한 것이 프로젝트는 그 자체로서 마감일을 가진다. 만일 하나의 일을 굳이 여러 개로 조각을 냈다고 해서 이를 프로젝트로 만들 필요는 없다.
댓글 없음:
댓글 쓰기