Today, Someday & Wishlist
작업의 세 경계: 지금 하는 것, 보관하는 것, 그리고 가능성으로 두는 것.
Today
Today는 오늘 건드릴 Action들의 모음이다. 매일 아침 Daily Review에서 채워진다. 비면 오늘 할 일이 끝난 것이다.
Today가 채워지는 방식
Action이 Today에 오는 경로는 두 가지다:
- 자동: 각 활성 Flow에서 첫 번째 미완료 Action이 자동으로 올라온다. 활성 Flow가 다섯 개라면, 아무 노력 없이 Today에 Action 다섯 개가 도착한다 — Flow 하나당 하나씩. 이게 기본값이다.
- 수동: 앞서서 작업하거나, 기본 순서를 오버라이드하거나, Flow의 위치와 무관하게 오늘 반드시 처리해야 하는 것이 있다면 추가 Action을 Today에 직접 끌어올 수 있다.
이 조합이 자동 모멘텀(시스템이 계속 작업을 올린다)과 의도적인 통제(무엇을 더 가져올지는 내가 결정한다)를 함께 준다.
자동으로 채워진 slate가 이미 너의 하루와 맞다면, 그걸로 충분하다. 큐레이션은 선택적인 다듬기이지 필수 의례가 아니다 — 무거운 날엔 자동 slate를 그대로 실행하는 것도 valid한 작업 방식이다. 시스템은 이미 각 Flow 안에서 "다음에 뭐 하지?"의 인지 부하를 처리했다. 그 위에 매일의 재설계를 더 얹을 의무는 없다. 자세한 주체성 보존 논리는 Principle 2 참고.
Today의 모든 항목은 오늘 체크 가능하다
이게 Today의 결정적 속성이고, 제약이 중요한 이유다.
Today의 모든 항목은 오늘 완료될 수 있다:
- Do — 작업을 끝내면 체크
- Delegate — 지시를 보내면 체크
- Review — 승인(또는 재위임)하면 체크
Await 항목은 Today에 나타나지 않는다 — 무언가가 도착할 때까지 할 것이 없으므로 별도로 추적된다.
Today에 있는 항목이 오늘 체크될 수 없다면, Today에 있으면 안 된다. 다른 무언가를 기다리고 있거나(Await로 만들어라), 하루에 완료하기 너무 큰 경우(더 작은 Action으로 나눠라), 아직 작업할 준비가 안 된 것(미래 날짜를 붙여라).
Today vs. 캘린더
둘 다 존재한다. 섞지 마라.
- 캘린더 — 특정 시간이 있는 시간 고정 약속: 회의, 미팅, 전화, 데드라인. 정해진 때에 일어난다. 자유롭게 옮길 수 없다.
- Today — 오늘 하기로 선택한 유연한 Action들. 특정 시간 없음. 여유가 생길 때 한다.
섞으면 거짓 제약이 생기기 때문에 구분이 중요하다. "발표 준비"를 캘린더에 하루 종일 일정으로 넣으면 실제 약속들과 충돌하고 마찰이 생긴다. Today의 Action으로 두면 집중할 수 있는 시간에 회의 사이사이에 처리할 수 있다.
캘린더는 언제 자리가 없는지를 알려준다. Today는 무엇을 하는지를 알려준다.
Today가 비었을 때
이게 하루의 완료 신호다. "오후 6시가 됐다"도 "피곤하다"도 아니다. Today가 비었다.
이 신호가 작동하는 이유는 Today가 닫힌 세트이기 때문이다 — 아침에 만들고 끝내기로 한 것이다. 항상 열려 있는 할 일 목록과 다르다. 할 일 목록은 절대 비지 않는다. 언제든 더 추가할 수 있다. Today는 빈다. 모든 것을 담으려 만든 게 아니라, 오늘 선택한 것만 담기 때문이다.
이 신호가 정직한 이유는 Today의 모든 항목이 완료 가능했기 때문이다. 빈 Today는 진짜 일들이 완료됐다는 뜻이다 — 시간이 지났다는 게 아니라. 아침에 이 Action들을 선택했다. 낮 12시에, 오후 3시에, 또는 하루 끝에 사라진다. 어느 쪽이든: 끝이다.
하루 끝에 Today가 자주 비지 않는다면, 이건 피드백이다. 너무 많이 넣고 있거나(덜 끌어오라), Action이 너무 크거나(더 작게 나눠라), Flow 안에서 뭔가 막혀 있는 것이다(Weekly Review 때 확인하라).
연속 3일 이상 Today가 비지 않는 상태는 Chronic Today라는 Stuck Signal이다 — 완료 신호 자체가 무너진 상태이므로 다른 무엇보다 먼저 해소해야 한다.
Today 용량
Flow 서피싱은 자연적인 용량 제한이다. 각 활성 Flow가 Action 하나를 올린다. 활성 Flow가 여섯 개라면 자동으로 여섯 개가 올라온다. 대부분의 사람에게 대부분의 날, 이것으로 충분하다.
과적재 문제는 거의 항상 두 곳에서 시작된다:
- 활성 Flow 집합이 하루에 끝낼 수 있는 양을 넘어 자랐다. 원칙 3이 이를 정면으로 다룬다: 새 Flow를 활성화하려 할 때, 무엇이 떠나는지를 정한다 — 완료, Someday, Wishlist, 삭제. 이 거래 없이는 활성 집합이 조용히 팽창해 Today가 끝낼 수 없는 상태가 된다. 대부분 사람의 실용적인 천장은 5~10개 활성 Flow다.
- 수동 추가. "오늘 될 것 같은" Action들이나 "더 해야 할 것 같아서" 추가하는 것. 무언가를 수동으로 추가하기 전에 먼저 묻는다: 이미 Today에 있는 것들을 오늘 현실적으로 전부 끝낼 수 있는가? 확신이 없다면 더 넣지 않는다.
현실적인 Today는 진짜로 끝낼 것을 기대하는 Today다. 낙관적인 Today는 끝내길 바라는 Today다. 낙관적인 Today는 미완료 항목을 만들고, 미완료 항목은 부담감을 만들고, 부담감은 회피를 만든다.
목표는 하루에 최대한 많은 것을 하는 게 아니다. 실제로 끝낼 수 있는 하루를 설계하는 것이다.
미완료 Action: 쌓이지 않는다
OTD에는 "밀린 일" 목록이 없다.
Action을 오늘 완료하지 못하면, 적체나 죄책감으로 쌓이지 않는다. Flow의 첫 번째 위치에 그대로 있다가, 내일 아침 Daily Review에서 다시 올라온다 — 어제의 실패 더미가 아닌, 새로운 하루의 Action 중 하나로.
이건 OTD의 구조적 속성이다. Action들이 평평한 목록이 아닌 Flow 안에 있기 때문에 쌓일 수 없다. 목록은 늘어나지 않는다. 내일은 항상 새롭게 시작된다.
실용적 결과: 미완료 Action은 관리해야 할 문제가 아니다. 준비가 됐을 때 다시 올라올 작업이다.
이게 요구하는 것: 미완료 Action을 이월 부채처럼 취급하지 마라. 하루가 시작되기 전에 내일의 로드 위에 정신적으로 쌓아두지 마라. 내일 Daily Review가 그것들을 새로운, 의도적인 Today의 일부로 올린다. 처음 시작하는 날처럼 Today를 설계하라 — 구조적으로는 실제로 그렇기 때문이다.
Someday
Someday는 하기로 했지만 지금은 아닌 것들을 보관하는 곳이다.
Someday에 있는 것들:
- 비활성 Flow — 잠시 멈춘 작업 흐름
- 비활성 Flow 묶음 —
[[키워드]]접두사로 묶인, 진행할 의도가 있지만 아직 시작하지 않은 목표 - 독립 Action — 언젠가 할 의도가 있지만 지금은 아닌 것
Someday는 미뤄둔 commitment다. 행동할 의도는 남아 있고, 시점만 멈춰 있다. 이게 Wishlist와의 차이점이다 — 아래 참조.
Someday로 이동하기
지금 작업하지 않겠다고 결정하면:
- Flow 또는 Action을 Someday로 이동한다 (같은 접두사의 묶음 전체를 옮길 수도 있다)
- Today에 Action이 올라오지 않는다
- 활성 뷰에서 사라진다
- Weekly Review의 Someday 목록에 나타난다
삭제가 아니다. 포기하는 게 아니라 인정하는 것이다: 지금은 아니다.
삭제 대신 Someday의 가치는 좋은 아이디어가 사라지지 않는다는 것이다. 지금 때가 아닌 Flow가 석 달 후에 핵심이 될 수 있다. 개발하고 싶은 스킬이 현재 약속을 마칠 때까지 기다려야 할 수 있다. Someday가 이것들을 조용히 보관하다가, Weekly Review가 다시 끌어올린다.
Someday와 Weekly Review
매주 모든 Someday 항목을 검토한다. 두 가지 질문:
이걸 지금 활성화할 준비가 됐는가? 미뤄왔던 것이 지금 때가 됐다면 — 상황이 바뀌었고, 약속이 끝났고, 기회가 왔다면 — 다시 활성 상태로 당긴다. 활성화는 원칙 3을 발동시킨다: 자리를 만들기 위해 무엇이 닫히는지 결정한다.
의도가 아직 진짜인가? 일부 Someday 항목은 낡는다. "언젠가 할 거야"라고 말한 것이 몇 달째 거기 있고, 한 번도 손을 뻗지 않았다면. 그건 정보다.
Someday 노화 처리 (aging-out)
Someday는 묘지가 아니다. 대기실이다 — 다시 돌아올 의도로 들어온다. 그 의도가 사라졌다면, 떠나야 한다.
Weekly Review에서 적용하는 두 가지 임계값:
- 6개월 동안 활성화 검토 없음 — 이 항목이 6번의 월별 검토에 등장했지만 한 번도 활성화를 진지하게 고려하지 않았다. 정직한 선택은 다음 중 하나:
- Wishlist로 강등 — 하기로 commitment하지 않는다; 가능성으로 보관한다. 노화한 Someday 항목 대부분은 여기로 간다.
- 삭제 — 의도가 완전히 사라졌다. 인정하고 제거한다.
- 재commitment — 명시된 트리거와 함께 의도를 명시적으로 갱신한다 ("X가 일어나면 활성화한다"). 트리거 없는 갱신은 그냥 미루기다.
- 트리거가 한 번도 정의된 적 없음 — Someday 항목이 처음부터 활성화 트리거 없이 거기 살았다면, 진짜 의도가 없었을 가능성이 높다. Wishlist로 강등하거나 삭제한다.
Someday를 살리는 규율은 자기 의도에 대한 정직함이다. 무엇이 활성화를 만들지 말할 수 없다면, 그건 진짜 Someday가 아니다.
Wishlist
Wishlist는 추구할 수도 있지만 commitment하지 않은 아이디어를 보관하는 곳이다.
Someday가 "할 거야, 다만 지금은 아니야"라면, Wishlist는 "할 수도 있고 안 할 수도 있어. 열어두는 거야"다.
왜 Someday와 분리하는가
GTD의 Someday/Maybe는 두 다른 의도를 한 목록에 섞었다: 미뤄둔 commitment와 commitment하지 않은 가능성. 이 혼합은 조용한 문제를 만든다.
미뤄둔 commitment와 한가한 가능성이 같은 목록에 살면:
- 진짜 commitment에 죄책감이 쌓인다 — "한다고 해놓고 안 했네"
- 한가한 가능성에 부담이 쌓인다 — "이것도 해야 하는데"
- 둘 다 낡고, 매번 다시 결정하기 전에는 어느 게 어느 건지 분간할 수 없다
분리하면 각 목록이 자기 일을 한다:
- Someday는 진짜로 미뤄둔, 돌아올 의도가 있는 commitment의 작고 정직한 목록.
- Wishlist는 보관하는 가능성의 열린, 압박 없는 목록. 죄책감 없음.
Wishlist의 핵심은 가능성을 의무에서 분리하는 것이다. 천 개의 아이디어를 보관해도 어느 것에도 진척의 빚을 지지 않는다.
판별 질문
Someday인지 Wishlist인지 헷갈린다면 묻는다:
이걸 활성화하는 순간, 1단계가 무엇인지 말할 수 있는가?
- 예 → Someday. 이미 Flow나 Action의 형태가 암묵적으로 있다. 작업이 미정이 아니라 멈춰 있다.
- 아니오 → Wishlist. 계획이 아니라 방향이나 관심이다. 활성화하게 된다면 첫 작업은 "실제로 뭘 할지 정하기"가 될 것이다.
이 질문은 운영 가능하다. 항목에 대한 감정을 묻지 않는다. 활성화가 매끄럽게 일어날 만큼 충분히 생각해뒀는지를 묻는다.
여섯 가지 차원
| Someday | Wishlist | |
|---|---|---|
| Commitment | 개인 commitment 있음 | commitment 없음 |
| 활성화 트리거 | 명확 — "X가 끝나면", "Y가 오면" | 불명확 — "언젠가", "시간 나면" |
| 다음 행동의 윤곽 | 지금 1단계를 식별할 수 있음 | 한 줄짜리 아이디어여도 됨 |
| Weekly Review 질문 | "이거 지금 활성화 가능한가?" | "이게 여전히 흥미로운가?" |
| 노화 처리 | 6개월 무진척 → 강등 또는 삭제 | 무기한. 노화 압박 없음. |
| Stuck Signal 적용 | 적용 — Dormant cluster 임계값 | 적용 안 됨 |
노화 처리의 비대칭은 의도된 것이다. Someday는 commitment 저장소 — 오래된 미이행 commitment는 해결해야 할 문제다. Wishlist는 가능성 저장소 — 오래된 가능성은 괜찮다. 보관에 비용이 들지 않는다.
Wishlist에 무엇이 살까
- 읽고 싶은 책, 듣고 싶은 강좌, 배우고 싶은 스킬 — commitment하지 않음, 그냥 흥미로움
- 추구하지 않는 프로젝트 아이디어 — 계획 없는 스케치
- 여행, 경험, "언젠가 해보고 싶은" — 열린 욕망
- "이런 게 있으면 좋겠는데..." — 아이디어에서 행동까지 거리가 큰 모든 것
Wishlist의 한 줄은 한 구절짜리여도 된다. 구조 불필요.
Wishlist와 Weekly Review
Wishlist는 매주 가볍게 훑는다. 유일한 질문:
아직 흥미로운가?
예라면 둔다. 아니오라면 삭제. 활성화 압박 없음. 노화 임계값 없음. 보관 또는 삭제 외에 해소 경로가 없다.
이 가벼움이 핵심이다. Wishlist는 아이디어가 일이 되지 않고 쉴 수 있는 곳이다.
계층 사이의 이동
항목은 자유롭게 이동한다:
- Wishlist → Someday — 가능성이 의도로 결정화됐다. 이제 1단계를 말할 수 있다. 승격.
- Someday → Wishlist — 의도가 사라지고 관심만 남았다. 강등. 노화 처리에서 흔한 경로.
- Wishlist → 활성 — 드물지만 가능. 일어날 때는 보통 Someday를 거친다(1단계 정의를 위해) 후 활성화. 활성화는 원칙 3을 발동시킨다.
- Someday → 활성 — 직접. 1단계가 이미 정의됐다; 거래만 열면 된다.
Someday와 Wishlist 사이의 흐름은 commitment가 이진적인 보관-vs-삭제 결정 없이 숨 쉴 수 있게 하는 시스템의 자연스러운 방식이다.
세 계층의 관계
머릿속 모델:
활성 (Today의 Flow + Action)
↑↓ 원칙 3 거래
Someday ←→ Wishlist
│ │
↓ ↓
삭제 삭제그리고 셋과 구별되는:
Reference — 조회를 위해 보관하는 비행동성 정보빠른 비교
| 활성 | Someday | Wishlist | Reference | |
|---|---|---|---|---|
| Today에 올라옴 | 예 (앞 Action) | 아니오 | 아니오 | 아니오 |
| 미래 행동 예상 | 예, 지금 | 예, 미뤄둠 | 어쩌면 | 아니오 |
| Commitment | 현재 | 미뤄둠 | 없음 | 해당 없음 |
| 노화 행동 | Stuck Signal 적용 | 6개월 노화 처리 | 무기한 | 무기한 |
처리 시점의 선택
즉시 행동 가능하지 않은 Inbox 항목을 처리할 때, 네 개의 목적지가 있다:
- 삭제 — 보관할 가치 없음
- Reference — 정보만, 행동 없음
- Wishlist — 흥미로운 가능성, commitment 없음
- Someday — 1단계가 암묵적인 미뤄둔 commitment
이들은 별개의 결정이다. GTD의 Someday/Maybe처럼 한 통에 다 넣는 것은 단순함을 위해 명료함을 희생한다. OTD는 명료함을 선호한다.
Weekly Review 시점의 선택
Someday와 Wishlist를 훑을 때:
- Someday — 노화 처리의 정직함을 적용한다. 항목이 머무르는 데 비용이 든다.
- Wishlist — 흥미 테스트를 적용한다. 항목이 머무르는 데 비용이 안 든다.
두 계층은 서로를 보호한다. Someday는 노화한 항목이 Wishlist로 떠나기 때문에 작고 정직하게 유지된다. Wishlist는 거기 있는 항목이 의무를 지지 않기 때문에 죄책감 없이 유지된다.
이 분리가 두 계층을 몇 년에 걸쳐 지속 가능하게 만드는 것이다.