FAQ
OTD는 GTD를 대체하는 건가요?
아니다. 진화다. GTD가 잘 맞고 있다면 그대로 쓰면 된다. OTD는 태스크가 병렬로 진행되고 일부 실행을 위임하는 상황에서 생기는 마찰을 해결한다. 그 마찰이 없다면 바꿀 필요도 없다.
AI가 없으면 OTD를 쓸 수 없나요?
아니다. OTD는 AI 도구 없이도 작동한다. Mode 시스템(Do, Delegate, Await, Review)은 동료, 외주업자, 비서, AI 누구에게 위임하든 동일하게 적용된다. "Delegate"는 "나 말고 다른 누군가가 이것을 처리한다"는 뜻이지, "AI를 쓴다"가 아니다.
어떤 도구를 써야 하나요?
OTD는 도구에 종속되지 않는다. 메모 앱, 스프레드시트, 전용 태스크 매니저, 종이 무엇이든 가능하다. 프레임워크가 구조를 정의하고, 무엇으로 실행할지는 사용자가 선택한다.
여러 Flow가 같은 큰 목표에 속할 때는 어떻게 하나요?
흔한 경우다. 예를 들어 "앱 런칭"은 자연스럽게 MVP 개발과 런칭 마케팅이라는 두 Flow로 쪼개진다. OTD는 이를 위한 상위 계층을 두지 않는다. 대신 관련 Flow 이름에 [[키워드]] 접두사를 붙인다:
[[앱 런칭]] MVP 개발
[[앱 런칭]] 런칭 마케팅가나다순/알파벳순 정렬에서 자동으로 옆에 배치된다. 목표가 끝나서 Flow를 삭제하면 그루핑도 함께 사라진다. 관리해야 할 태그나 폴더가 없다. [[키워드]]를 권장하지만, 일관된 접두사라면 무엇이든 작동한다. 목표에 Flow가 하나뿐이라면 접두사를 붙이지 않는다.
며칠 걸리는 일은 어떻게 하나요?
날짜별 Action으로 나눈다. "보고서 쓰기"처럼 하나의 작업처럼 느껴지는 것도 사실 매일 다른 일이다: 구조 잡기, 전반부 작성, 후반부 작성, 수정. 각각이 구체적이고 완료 가능한 Action이다.
이건 형식의 문제가 아니다. OTD의 피드백 루프가 여기에 달려 있다: Today가 비면 → 오늘 할 일이 끝난 것이다. 오늘 체크할 수 없는 Action이 있으면 Today는 절대 비지 않고, 그 신호가 깨진다.
그래도 복잡하지 않나요?
실제로는 대부분의 태스크가 두 계층만 사용한다: Area 바로 아래의 Action, 또는 Area 안의 Flow 안의 Action. Area → Flow → Action 전체 사슬은 순서가 있는 작업 흐름이 있을 때만 등장한다. 독립 Action은 Flow를 거치지 않는다. 여러 Flow가 같은 목표에 속할 때는 [[키워드]] 접두사로 묶을 뿐, 새 계층을 추가하지 않는다.
Today는 할 일 목록과 뭐가 다른가요?
할 일 목록은 대개 하고 싶은 것들의 평평한 모음이다. 때로 우선순위가 있고 때로 없다. 무한정 늘어날 수 있고, 명확한 "완료" 신호가 없다.
Today는 매일 아침 능동적으로 큐레이션한 Action들의 모음이다. 각각 하루 안에 완료 가능하다. 비면 오늘 작업이 끝났다는 객관적 신호가 된다. 그게 할 일 목록과 다른 점이다.
Today와 캘린더의 차이는요?
캘린더는 특정 시간이 있는 시간 고정 약속을 담는다: 회의, 통화, 데드라인, 미팅. 정해진 때에 일어난다.
Today는 오늘 하기로 선택한 유연한 Action들을 담는다. 특정 시간은 없다. 여유 시간에 캘린더 사이사이에 처리한다. 둘이 함께 존재한다. 섞지 않는다.
활성 Flow가 몇 개 정도가 적당한가요?
정해진 수는 없다. 하루에 실제로 전진시킬 수 있는 병렬 작업의 양에 달려 있다. 활성 Flow가 15개면 Today에 15개가 올라올 것이다. 너무 많을 수 있다. 3개면 3개가 올라온다. 너무 적을 수 있다.
실용적인 시작점: 5~10개의 활성 Flow가 대부분의 사람에게 관리 가능하다. 현재 적극적으로 전진시키지 않는 것은 Someday나 Wishlist로 옮겨라. 원칙 3이 이를 정직하게 유지하는 규율이다: 새 Flow를 시작하려 할 때, 무엇이 떠나는지 결정한다.
Someday와 Wishlist의 차이가 뭔가요?
Someday는 미뤄둔 commitment다: 할 의도가 있고, 다만 지금이 아닐 뿐이며, 1단계를 말할 수 있다. Wishlist는 commitment 없는 가능성이다: 할 수도 안 할 수도 있다. 의무 없이 보관하는 아이디어다.
판별 질문은 운영 가능하다: "이걸 활성화하는 순간, 1단계가 무엇인지 말할 수 있는가?" 예 → Someday. 아니오 → Wishlist.
분리가 중요한 이유는 GTD의 합쳐진 Someday/Maybe가 두 의도를 한 목록에 섞기 때문이다. 미뤄둔 commitment에 죄책감이 쌓이고, 한가한 가능성에 부담이 쌓인다. 분리하면 각 목록이 자기 일을 한다: Someday는 작고 정직하게 (6개월 노화 임계값 적용), Wishlist는 열려 있고 죄책감 없이 (노화 압박 없음). Today, Someday & Wishlist 참조.
새 Flow를 시작할 때마다 뭔가를 닫아야 하나요?
예. 그게 원칙 3이다. 새 Flow를 활성화할 때, 닫는 결정과 짝을 이룬다: 기존 Flow를 완료하거나, Someday로 옮기거나, Wishlist로 강등하거나, 삭제한다.
병렬 작업을 제한하는 게 아니다. OTD는 병렬 Flow를 위해 만들어졌다. 여러 흐름이 동시에 전진하는 것이 프레임워크의 핵심이다. 원칙 3은 활성 집합의 크기를 제한하지, 병렬성을 제한하지 않는다. 5~10개 Flow가 병렬로 굴러가는 것은 정상이다. 원칙은 가장자리에서 활성화된다: 실제로 끝낼 수 있는 양을 넘어 집합을 키우려 할 때.
원칙인 이유: 시작은 구조적으로 싸고, 닫기는 구조적으로 비싸다. 거래를 강제하지 않으면 활성 집합이 조용히 부풀어 Today가 끝낼 수 없는 상태가 된다. 거래가 집합을 살 만하게 유지한다.
하루 중 긴급한 일이 생겨서 Today가 무너지면요?
캡처하고, 처리하고, Today에 당긴다. 다른 것을 밀어낸다면 의식적으로 받아들인다. Today가 조용히 확장되게 두지 마라. 하루 끝에 완료되지 않은 항목은 내일 다시 올라오거나 재평가된다.
빈 Today는 목표이지 보장이 아니다. 어떤 날은 목표가 움직인다. 무엇이 움직였고 왜인지 명확한 한, 괜찮다.
Weekly Review를 자꾸 건너뛰게 됩니다. 어떻게 습관을 만드나요?
"일요일에 시간 날 때"가 아니라 특정 요일과 시간을 고정하라. 외부 약속처럼 캘린더에 넣는다.
삶이 바빠지면, 아예 안 하는 것보다 부분 리뷰라도 하라. Inbox 처리, 막힌 Flow 확인, Someday 훑기까지 15분이면 된다. 이게 최소 실행 가능 Weekly Review다.
보상은 믿을 만하다: 좋은 Weekly Review 후에 시스템이 깔끔하고 신뢰할 수 있다. 의무감이 아니라 그 느낌을 쫓아라.