구현 스펙
OTD는 개념 수준에서 도구에 종속되지 않는다. 하지만 일부 메커니즘은 의도한 대로 작동하기 위해 도구의 지원이 필요하다. 이 페이지는 도구가 OTD를 제대로 구현하기 위해 필요한 것을 정의한다.
두 가지 용도로 쓰인다: 도구 개발자를 위한 스펙, 도구를 선택하는 사용자를 위한 체크리스트.
Tier 1: 필수
이 없으면 OTD의 핵심 메커니즘이 작동하지 않는다.
Flow 서피싱
각 활성 Flow의 첫 번째 미완료 Action이 자동으로 Today에 등장한다. 해당 Action이 완료되면 Flow의 다음 Action이 올라온다.
사용자가 매일 아침 각 Flow를 일일이 확인해서 어디까지 했는지 찾아야 하는 상황을 만들지 않는다. 시스템이 이를 처리한다.
왜 중요한가: 이것이 Today를 신뢰할 수 있게 만드는 것이다. 없으면 사용자가 매일 Today를 수동으로 재구성하거나(마찰), 올라와야 할 작업을 놓친다(시스템 이탈).
Mode 가시성
Today 항목의 Mode가 구분된다: Review, Delegate, Await, Do. 사용자가 각 항목의 Mode를 한눈에 파악하고 순서대로 처리할 수 있다.
Await 항목은 Today와 분리되어 추적된다 — 보이지만 활성 Today 목록에는 없다.
왜 중요한가: Mode 기반 실행 순서(Review → Delegate → Do)가 핵심 실행 모델이다. Mode 가시성 없이는 평평한 구분 없는 목록으로 무너진다 — GTD의 @컴퓨터 목록과 같은 문제.
Someday 토글
모든 Project, Flow, Action을 활성/비활성(Someday) 상태로 즉시 전환할 수 있다. 비활성 항목은 Today에 Action을 올리지 않고 별도 Someday 뷰에 나타난다.
왜 중요한가: 삭제 없이 작업을 보류할 수 있는 것이 과부하 관리의 기본이다. 이게 느리거나 숨겨져 있으면 사용자가 삭제를 선택하게 되고 좋은 아이디어가 사라진다.
Inbox를 단일 진입점으로
모든 새 입력이 출처와 무관하게 먼저 Inbox에 들어온다. 도구는 어디서든 Inbox에 추가하는 것을 마찰 없이 만들어야 한다 — 키보드 단축키, 빠른 캡처 위젯, API, 모바일.
왜 중요한가: 캡처 규율은 전적으로 캡처 마찰에 달려 있다. Inbox에 추가하는 데 네비게이션이 필요하면 건너뛰게 된다. 건너뛰면 시스템에 구멍이 생긴다.
Tier 2: 강력 권장
이 없어도 OTD는 작동하지만 의미 있는 마찰이 있다.
날짜 기반 서피싱
날짜가 지정된 Action은 해당 날짜 이후에 Today에 올라온다 — 그 전에는 올라오지 않는다.
두 가지 유형:
- 절대 날짜: 특정 날짜에 올라온다 ("2월 14일")
- 상대 날짜: 트리거 후 정해진 일수가 지나면 올라온다 ("이 Action 생성 후 3일")
왜 중요한가: 모든 작업이 즉시 행동 가능한 것은 아니다. 날짜 기반 서피싱 없이는 모든 것을 Today에 즉시 추가하거나(과부하), 기억에 의존해야 한다(시스템 우회).
반복 Action과 Flow
Action과 Flow에 반복 주기를 설정할 수 있다:
- 고정 주기: 매주 월요일, 매월 1일
- 상대 주기: 완료 후 N일
완료 시:
- 반복 Action은 다음 예정 날짜에 시스템에 재진입한다
- 반복 Flow는 첫 번째 Action으로 리셋되고 다음 예정 날짜에 재진입한다
내부적으로 구현체는 매 주기에 새 인스턴스를 생성해야 한다(히스토리 보존). 사용자 경험은 같은 Action이나 Flow가 새로 시작되는 것이다.
왜 중요한가: 반복 작업은 대부분의 사람의 실제 업무에서 상당한 비중을 차지한다. 반복 지원 없이는 매 주기마다 Action을 수동으로 재생성해야 하는 오버헤드가 시간이 지나면서 시스템 신뢰를 떨어뜨린다.
Goal-Project 연결
Review 시 사용자가 Project를 Goal과 연결할 수 있다. Goal 하나에 여러 Project, Project 하나가 여러 Goal에 기여하는 것도 가능하다.
이 연결은 구조적 계층일 필요가 없다 — 분기 Review 중 정렬을 확인하는 데 사용되는 태깅이나 링킹 관계다.
왜 중요한가: 없으면 Goal과 Project가 가시적인 연결 없이 병렬로 존재한다. 분기 Review 질문("내 Project들이 Goal을 전진시키고 있는가?")이 도구의 지원 없이 수동 정신 작업이 된다.
Review 프롬프트
도구가 Review 주기에 맞는 알림을 제공한다:
- Daily Review: 매일 아침
- Weekly Review: 주 1회 (사용자 지정 요일)
- 분기 Review: 분기 1회
- 연간 Review: 연 1회
침입적일 필요는 없다 — 알림이나 Review가 필요하다는 지속적인 인디케이터로 충분하다.
왜 중요한가: Review 습관은 모든 생산성 시스템에서 가장 자주 포기되는 부분이다. 프롬프트가 습관을 대체하지는 않지만 "깜빡했다"는 실패 패턴을 제거한다.
Tier 3: 선택적이지만 유용
있으면 OTD가 확장되지만 필수는 아니다.
캡처 통합
Inbox가 외부 출처에서 입력을 받을 수 있다: 이메일, Slack, 캘린더 초대, GitHub 알림, API 호출. 모든 인바운드 항목은 출처와 무관하게 Inbox 항목으로 도착한다.
왜 중요한가: 연결된 업무 환경에서 태스크는 많은 채널에서 온다. 각 채널에서 Inbox로 수동 재입력하는 것은 높은 마찰이다. 통합이 단일 Inbox 규율을 훼손하지 않으면서 마찰을 줄인다.
Flow 템플릿
자주 사용되는 Flow를 템플릿으로 저장하고 한 번에 인스턴스화할 수 있다. 템플릿이 Action 순서를 정의하고, 각 인스턴스는 새 복사본이다.
왜 중요한가: Mode 순서(Delegate → Await → Review 사이클)를 포함한 반복 Flow는 강력하지만 처음부터 다시 만들기 번거롭다. 템플릿이 이를 재사용 가능하게 한다.
진행 상황 가시성
각 활성 Flow에서 완료된 Action 대 남은 Action의 비율, 그리고 Project가 Flow들 전체에서 어떻게 진행되고 있는지를 보여주는 뷰.
왜 중요한가: 일상 실행에 필수는 아니지만, Weekly Review 때 각각을 열지 않고도 막힌 Flow와 정체된 Project를 빠르게 파악하는 데 유용하다.
도구가 하지 말아야 할 것
이 행동들은 OTD의 핵심 원칙을 훼손한다.
Today를 자동으로 채우지 않는다. 도구가 Flow에서 Action을 서피싱하는 것(Tier 1)은 맞다. 하지만 우선순위 점수, 데드라인, AI 추론을 기반으로 포함/제외 Action을 결정해서는 안 된다. Today는 사용자가 설계하는 것이지 시스템이 결정하는 것이 아니다.
Today 안에서 자동으로 우선순위를 매기지 않는다. 각 Mode 안에서의 순서는 사용자의 판단이다. 도구가 Mode 순서(Review → Delegate → Do)를 제안할 수 있지만, Mode 안에서 항목을 자동으로 재정렬해서는 안 된다.
특정 프로젝트 계층을 강제하지 않는다. OTD의 Area → Project → Flow → Action 구조가 지원되어야 하지만, 모든 항목이 네 계층을 모두 사용하도록 강제해서는 안 된다. Area 바로 아래의 독립 Action, Project 없는 Flow — 이것들은 유효하고 깔끔하게 작동해야 한다.