링크, 래쓰형 이 번역한 한글 버전. GTD 같은 시간 관리 기법이라고 할 수 있겠다. GTD 에 관심이 쪼금 있었을 뿐, 시간 관리 시스템이라는 것에 관심만 좀 있었는데 이건 너무나도 간단해서 쉽게 시작할 수 있다. 회사에서도 쓰고, 지난 주말부터 AOJ 작업하는 데 써서 사실 며칠 되진 않았는데.. 나쁘지 않은 것 같다.
우선 이 시스템의 가장 좋은 점은, 할 일을 다 못하더라도 줄을 치는 것이다. 비록 마지막에 새 항목으로 추가할지언정, 한번 손 댄 일은 무조건 줄을 친다. 별것 아닌 것 같지만, 이것이 가지는 의미는 꽤 크며, 일반적인 할 일 목록과 이 시스템을 구분짓는 가장 큰 요소다. 일반적인 '할 일 목록' 의 최대 문제점은, 한번에 슥 해치울 수 있는 단발성 외의 일들을 처리하기가 힘들다는 것이다. 오래 걸리는 일들은 할일 목록에 집어넣는다 한들 휙 처리할 수 있는 것이 아니기 때문에 목록에 쭉 남게 되는데, 이러면 일을 해도 하는 것 같지가 않고, 항상 목록에 있는 것이 있으니 긴장감도 떨어지고, 시스템이 운영되지가 않는 것 같다는 '느낌' 이 들게 된다. 이 느낌은 항상 지금까지 내가 시도해온 모든 '할일 목록' 을 정지 상태로 몰아넣은 주범이었다.
그런데 여기서는 큰 일을 사실상 여러 개의 조각으로 나누어서 할 수 있다. 각각의 조각을 할 때마다 목록에는 줄이 그어지고 새 항목이 추가되게 된다. 일반적인 할 일 목록에서는 일을 '끝내는 것' 만이 진행의 유일한 수단이었는데, 여기에서는 일을 '하는 것' 이 진행의 수단이 되는 것이다. 조각들을 클리어할 때마다도 줄을 그을 수 있기 때문에 >.< 나같은 피드백 중독자들에게는 이것이 시스템을 느슨하게 만들지 않는 좋은 요인이 된다.
이 시스템의 두 번째 특징은 페이지 단위로 할 일을 관리한다는 것이다. 한 페이지에 남은 할 일들을 전부 '건드리거나', 명시적으로 '방치하지' 않는 이상, 다음 페이지로 넘어갈 수 없다. 따라서 절대 하지 않고 목록에 '남아만 있는' 작업들이 생기는 것을 막을 수 있게 된다.
이런 시스템 모두가 생각해 보면 내가 이노티브 시절 trac 을 쓰던 것과 굉장히 닮았다. 당시는 내가 지금까지 일하던 도중 시간 대비 코드 생산량이 가장 많던 시기였는데.. 당시에는 ticket system 을 굉장히 유용하게 썼다. trac 은 ticket 과 svn commit log, wiki 가 서로 상호 링크가 된다. 커밋로그에 티켓 번호를 #번호 로 언급하면 링크가 걸리고, 티켓에 [리비전] 쓰면 커밋 로그로 링크가 자동으로 걸리는 식. 그래서 큰 티켓을 여러 개의 작은 티켓으로 분할하고, 일을 마치지 못하더라도 진행 상황을 티켓 로그로 남기는 식으로 '일을 진행한다는 느낌' 을 받을 수 있었다. 100시간을 넘게 쏟아부은 거대 티켓을 닫을 때의 그 기분이란.... ;) 그리고 마일스톤이 있어서, 절대 하지 않는 일 이 남아있는 것을 막을 수도 있었고. 덕분에 진짜 재미있게 열심히 일할 수 있었던 것 같다. 그 이후로 그와 같은 개인적인 형태의 티켓 시스템을 도입해 보려고 열심히 노력했지만 이것이 쉽지 않았는데.. 이 시스템을 잘만 습관화하면 비슷한 일을 할 수 있을 것 같기도 하다.
결론은 강추!
일요일 하루 동안 작업하고 찍은 노트. 오랫동안 미루고 있던 AOJ 작업을 꽤 마이 했다 'ㅅ'
