구현 스펙
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 토글
모든 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-Flow 연결
Review 시 사용자가 Flow를 Goal과 연결할 수 있다. Goal 하나에 여러 Flow, Flow 하나가 여러 Goal에 기여하는 것도 가능하다.
이 연결은 구조적 계층일 필요가 없다. 분기 Review 중 정렬을 확인하는 데 사용되는 태깅이나 링킹 관계다.
왜 중요한가: 없으면 Goal과 Flow가 가시적인 연결 없이 병렬로 존재한다. 분기 Review 질문("내 Flow들이 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의 비율을 보여주는 뷰. [[키워드]] 접두사로 묶인 Flow들을 그룹으로 묶어 진행 상황을 보여주는 것도 유용하다.
왜 중요한가: 일상 실행에 필수는 아니지만, Weekly Review 때 각각을 열지 않고도 Stalled Flow와 Dormant Cluster를 빠르게 파악하는 데 유용하다.
반환 게이트와 Review 예산
도구가 agent의 쓰기를 허용한다면, 원칙 4를 관행이 아니라 기계적으로 구현해야 한다:
- 돌아온 일은 Review Action이 된다. agent나 규칙이 만든 것은 Flow, Today, Someday, Wishlist에 직접 들어가지 않는다.
- 읽기 경로에는 게이트가 필요 없다. 쓰기에만 필요하다.
- 거절은 기록된다. 거절된 반환은 출처와 함께 남아 보인다. 사라지지 않는다.
- 모든 쓰기는 actor를 함께 남긴다: 사람, agent(어느 것인지), 규칙(어느 문장인지).
- 하루 Review 예산이 존재하고 조정 가능하다. 상한에 닿으면 도구는 사용자에게 쌓는 대신 agent의 반환을 받지 않는다. 미검토 항목은 Stuck Signal로 나이를 먹는다.
- 규칙은 읽을 수 있고 되돌릴 수 있다. 규칙은 사용자가 쓴 한 문장으로 보이고, 무엇을 했는지 로그를 남기고, 취소하거나 삭제할 수 있다. 규칙은 새로 들어온 것을 배치할 수 있지만, Review 없이 기존 작업을 바꾸거나 지울 수 없다.
왜 중요한가: agent 위임은 싸고 빠르다. 그래서 게이트만이 시스템의 내용을 사용자 자신의 결정으로 유지한다. 게이트가 없으면 원칙 1의 신뢰 조건이 반대편에서 깨진다: 모든 것이 시스템에 있지만, 그중 무엇을 자신이 선택했는지 알 수 없게 된다.
도구가 하지 말아야 할 것
이 행동들은 OTD의 핵심 원칙을 훼손한다.
- Today를 자동으로 채우지 않는다. 도구가 Flow에서 Action을 서피싱하는 것(Tier 1)은 맞다. 하지만 우선순위 점수, 데드라인, AI 추론을 기반으로 포함/제외 Action을 결정해서는 안 된다. Today는 사용자가 설계하는 것이지 시스템이 결정하는 것이 아니다.
- Today 안에서 자동으로 우선순위를 매기지 않는다. 각 Mode 안에서의 순서는 사용자의 판단이다. 도구가 Mode 순서(Review → Delegate → Do)를 제안할 수 있지만, Mode 안에서 항목을 자동으로 재정렬해서는 안 된다.
- 특정 계층을 강제하지 않는다. OTD의 구조는 Area → Flow → Action(또는 Area → Action)이다. 도구는 Flow에 Action을 중첩하는 것을 지원하되 모든 Action이 Flow 안에 있도록 강제해서는 안 된다. Area 바로 아래의 독립 Action은 유효하고 깔끔하게 작동해야 한다.
[[키워드]]접두사로 Flow를 묶는 것은 단순한 명명 규약이므로, 이름 정렬만 지원하면 자동으로 작동한다. 별도의 "그룹" 개념을 도입할 필요가 없다. - agent의 반환을 자동 반영하지 않는다. agent가 아무리 믿을 만해 보여도 결과는 Review를 지나 들어온다. 도구가 "전체 승인"을 제공할 수는 있지만 단계를 건너뛸 수는 없고, 묶음 승인이 가장 쉬운 경로가 되게 만들어서도 안 된다 (원칙 2의 승인 형식화 실패 참고).
- Stuck Signal 임계치를 조용히 재조정하지 않는다. 도구는 관측된 이력에서 새 임계치를 제안할 수 있고, 받아들이는 것은 사용자다. 사용자가 고르지 않은 임계치는 사용자가 읽을 수 없는 규칙이다.
- 규칙이 기존 작업을 변경하게 하지 않는다. 규칙은 새로 들어온 것을 배치한다. 이미 있는 것을 바꾸거나 지우는 것은 Review를 지난다.