GTD에서 OTD로
기존 GTD 사용자를 위한 전환 가이드. 무엇이 무엇에 대응하는지, 무엇이 바뀌는지, 무엇을 그대로 유지해야 하는지.
개념 매핑
| GTD | OTD | 비고 |
|---|---|---|
| Inbox | Inbox | 동일. 캡처 채널 확장. |
| Clarify / Process | Process | "누가 실행하는가?"(Mode) 질문 추가 |
| Area of Responsibility | Area | 동일 |
| Project | Flow | Flow 간 병렬, Flow 내 순차 |
| Next Action | Action | 동일: 하루 안에 완료 가능 |
| Context (@computer, @phone) | Mode (Do/Delegate/Await/Review) | 물리적 컨텍스트 → 실행 상태 |
| Waiting For | Await | 1급 Mode로 승격 |
| Someday/Maybe | Someday + Wishlist | 미뤄둔 commitment와 commitment 없는 가능성으로 분리 |
| Reference | Reference | 동일. Vision과 Purpose도 여기에 보관. |
| Weekly Review | Daily + Weekly + 분기 + 연간 | 완전한 Review 리듬 |
| Calendar | Calendar | 변경 없음 |
| 2-Minute Rule | 2분 규칙 | 그대로 유지 |
| Goals (H3) | Goals | 독립 목록. 분기 Review에서 Flow와 매핑. |
| Vision (H4) | Reference | 문서로 보관. 연간 검토. |
| Purpose/Principles (H5) | Reference | 문서로 보관. 연간 검토. |
변하지 않는 것
이 GTD 원칙들은 그대로 이어진다:
- 모든 것을 캡처한다. Inbox 습관은 두 시스템 모두에서 타협 불가다. OTD에서는 오히려 더 강화된다. 캡처 채널이 넓어질수록, 모든 것을 Inbox로 보내는 규율이 더 중요해진다.
- Inbox를 비운다. Inbox 제로가 여전히 목표다. 처리 질문이 약간 달라졌지만, 항목을 방치하는 대신 각 항목이 무엇인지 결정하는 습관은 변하지 않는다.
- 정기적으로 검토한다. GTD의 Weekly Review는 일일 리듬이 추가되어 OTD에 살아있다. 핵심 목적은 동일하다: 시스템을 현재 상태로 유지하는 정기 감사.
- 2분 규칙. 수정 없이 유지. 2분 미만이면 지금 실행한다.
- 하루 안에 완료 가능한 Action. GTD의 "Next Action"은 한 번의 작업에서 물리적으로 완료될 수 있어야 한다. OTD의 Action은 하루 안에 완료될 수 있어야 한다. 같은 제약, 같은 이유.
- Reference 정리. 행동이 필요 없는 정보는 Reference로. 변경 없음.
- 나중에 할 수 있는 것들을 보관하기. OTD는 기저 습관을 유지하되 GTD의 Someday/Maybe를 두 계층으로 분리한다: Someday(미뤄둔 commitment, 1단계 식별 가능, 노화 처리 적용) 그리고 Wishlist(commitment 없는 가능성, 노화 압박 없음). 이 분리는 GTD의 합쳐진 목록이 시간이 지나며 만들어내는 죄책감-vs-부담 혼합을 제거한다.
바뀌는 것
GTD Project → OTD Flow
가장 중요한 개념적 전환이다.
GTD에서 "project"는 둘 이상의 Action이 필요한 모든 것이다. "자동차 정비"는 예약 전화와 차를 맡기는 두 단계가 필요하면 GTD 프로젝트다.
OTD에서 그건 Flow다: 단일 순차 작업 흐름이다. OTD에는 Project라는 상위 컨테이너가 없다.
전환: GTD 프로젝트들이 OTD Flow가 된다. 여러 Flow가 같은 큰 목표에 속한다면 이름에 공통 [[키워드]] 접두사를 붙여 묶는다. 별도의 컨테이너를 만들지 않는다.
물리적 컨텍스트 → Mode
GTD는 어디 있는지로 Action을 필터링한다: @컴퓨터, @전화, @외출, @집.
OTD는 누가 처리하고 어떤 상태인지로 Action을 조직한다: Do, Delegate, Await, Review.
대부분의 작업이 컴퓨터에서 이루어지는 세상에서, @컴퓨터가 모든 것을 커버하고 컨텍스트 필터는 의미를 잃는다. Mode가 대신 진정으로 유용한 조직화 원칙을 제공한다.
전환: Action에 컨텍스트 태그 붙이기를 중단한다. 대신 처리할 때 모든 Action에 Mode를 할당한다. Mode가 실행 순서를 결정하고 (Review → Delegate → Do), 이게 컨텍스트 기반 필터링보다 더 유용하다.
Waiting For → Await (승격)
GTD에서 "Waiting For"는 별도 목록이었다: 중요하지만 약간 2등 시민이었다. 가끔 확인해서 뭔가 돌아왔는지 보는 식.
OTD에서 Await는 1급 Mode다. 모든 Await 항목이 완전한 가시성으로 시스템에서 추적된다. Weekly Review에 나타난다. 체계적으로 팔로업된다.
승격이 중요한 이유는 위임이 더 빈번해졌기 때문이다. AI를 실행에 활용한다면 어느 날이든 Await 항목이 수십 개일 수 있다. 보조 목록으로 취급하면 사각지대가 생긴다.
전환: GTD "Waiting For" 목록의 모든 것이 OTD에서 Await Action이 된다. 적절한 Flow로 이동한다.
순차 프로젝트 → 병렬 Flow
GTD는 한 번에 하나 집중을 위해 설계됐다. 프로젝트 모델이 암묵적으로 순차였다. 프로젝트 목록을 한 번에 하나씩 처리했다.
OTD는 병렬 조율을 위해 설계됐다. 여러 Flow가 동시에 전진한다. 각자 다음 Action을 독립적으로 올린다. 같은 날 세 개의 프로젝트를 병렬로 전진시킬 수 있다.
전환: 캡처하거나 처리하는 방식을 바꿀 필요는 없다. 활성 작업에 대해 생각하는 방식이 바뀐다. "이번 주에 어떤 프로젝트에 집중해야 하지?" 대신 "오늘 어떤 Flow를 전진시키고 싶지?"를 묻는다. 모두 매일 전진할 수 있다, 각각 Action 하나씩.
Someday/Maybe → Someday + Wishlist
GTD의 Someday/Maybe는 두 다른 의도를 섞는다: 진짜로 미뤄둔 것("나중에 할 거야")과 가능성으로 보관하는 것("언젠가 할 수도 있어"). 시간이 지나면 이 혼합은 문제가 된다: 미뤄둔 commitment에는 죄책감이 쌓이고, 한가한 가능성에는 부담이 쌓인다, 같은 목록 안에서.
OTD는 분리한다:
- Someday: 미뤄둔 commitment. 행동할 의도가 있고, 시점만 멈춰 있고, 1단계를 식별할 수 있다. 6개월에 노화 처리.
- Wishlist: commitment 없는 가능성. 흥미로운 아이디어, 추구할 의무 없음. 노화 압박 없음.
전환: 기존 Someday/Maybe를 한 번 훑는다. 각 항목에 대해 묻는다: "활성화의 1단계가 뭐가 될지 말할 수 있는가?" 예 → Someday. 아니오 → Wishlist. 첫 패스가 목록의 얼마나 많은 부분이 진짜 commitment였고 얼마나 많은 부분이 wish thinking이었는지를 명료하게 한다.
새 활성 commitment → 원칙 3
GTD는 새 프로젝트를 만들 때 어떤 제약도 부과하지 않는다. 캡처를 계속하는 한 활성 프로젝트 목록은 무한히 자랄 수 있다.
OTD는 원칙 3: 새로 열기 전에 닫아라를 도입한다. 새 Flow를 활성화할 때(Inbox에서든, Someday에서든, Wishlist에서든) 닫는 결정과 짝을 이룬다: 기존 Flow를 완료하거나, Someday로 옮기거나, Wishlist로 강등하거나, 삭제한다. 활성 집합에 천장이 있다.
전환: 사후 정리가 필요 없다. 다음 활성화부터 적용하기 시작한다. 새 Flow를 만드는 첫 순간에 "무엇이 떠나는가?"를 물어라. 거기서 실천이 자란다.
흔한 전환 실수
- 상위 컨테이너 찾기. OTD에는 Project라는 계층이 없다. GTD "프로젝트"는 그냥 OTD Flow다. 여러 Flow가 같은 목표에 속한다면
[[키워드]]접두사로 묶을 뿐, 컨테이너를 만들지 않는다. - 컨텍스트 태그 유지. 컨텍스트는 OTD에서 유용한 역할을 하지 않는다. 제거한다. Mode가 이제 그 역할을 한다.
- 병렬 Flow에 저항하기. GTD가 한 번에 하나 집중을 훈련시켰다. OTD는 병렬 작업을 허용한다. 매일 여러 Flow를 전진시켜라. Flow당 Action 하나를 올려 볼륨이 관리 가능하게 유지한다는 시스템을 믿어라.
- 과잉 전환. 시작하기 전에 모든 것을 완벽하게 전환할 필요가 없다. OTD의 두 질문으로 Inbox를 처리하라. 작업하면서 구조가 스스로 만들어지게 하라. 완벽한 전환이 아니라 작동하는 전환이 필요하다.
바꾸지 말아야 할 것
강한 GTD 습관을 쌓았다면, 전환에서 버리지 마라. 작동하는 실천은 보존할 가치가 있다:
- Inbox 캡처 습관: 그대로 유지하되, 채널만 넓힌다
- Weekly Review 시간: 슬롯을 유지하고, 체크리스트를 업데이트한다
- Reference 시스템: 변경 없음
- 2분 규칙 반사: 변경 없음
OTD는 GTD의 대체가 아니라 진화다. 채우는 간극은 구체적이다: 병렬 작업, 명시적 위임 추적, Mode 기반 실행, 일일부터 연간까지 이어지는 연결된 Review 리듬. 나머지는 GTD다.
전환이 한 세션에 일어날 필요는 없다. 많은 사람이 전환 중에 하이브리드 시스템을 사용한다. 새 항목은 OTD 질문으로 처리하면서 기존 GTD 프로젝트들은 작업하면서 점진적으로 전환된다. 괜찮다.
Horizons of Focus
GTD는 다양한 고도에서 작업을 생각하기 위한 여섯 개의 지평선을 소개했다. OTD는 여섯 가지 모두를 커버하되, 다르게 구성한다.
| GTD Horizon | OTD |
|---|---|
| H0: Next Actions | Action (Today에서) |
| H1: Projects | Flow (순차 작업 흐름) |
| H2: Areas of Focus | Area |
| H3: Goals | Goals (독립 목록, 분기 검토) |
| H4: Vision | Reference (3~5년 그림, 연간 검토) |
| H5: Purpose/Principles | Reference (핵심 가치, 연간 검토) |
핵심 구조적 차이: GTD는 여섯 개의 지평선을 명시적인 연결 메커니즘 없이 별도 목록으로 취급한다. OTD는 연결을 내장한다:
- Goals가 분기 Review에서 Flow에 매핑된다
- Vision이 Goals가 올바른 방향을 향하는지 알려준다
- Purpose가 Vision이 실제로 가치 있는 것을 반영하는지 체크한다
흐름은 양방향으로 흐른다: Purpose → Vision → Goals → Flows → Actions → Today. 그리고 모든 Review 레벨이 그 위의 레벨과의 정렬을 확인한다.