실전 예시

다양한 페르소나와 시나리오에서의 OTD. 이상적인 조건이 아닌 실제 삶에 프레임워크가 어떻게 적응하는지 보여준다.

0일차: 아무것도 없는 상태에서 시작하기

아무 생산성 시스템도 없는 사람을 위한 시나리오. GTD도, 앱도, 그냥 혼란스러운 머릿속 목록과 막연한 뒤처지는 느낌만 있는 경우.

상황:

지우는 28세 UX 디자이너로 중간 규모 회사에 다닌다. 태스크 관리 시스템이 없다. 포스트잇, 북마크한 Slack 메시지, 자신에게 보내는 개인 카톡, 그리고 기억으로 일을 추적한다. 잊어버리는 일이 생긴다. 뒤처지는 느낌이 든다. OTD를 써보기로 했다.

첫 번째 세션 (일요일 저녁, 약 90분):

1. 머리 비우기 (30분)

빈 메모를 열고 생각나는 모든 것을 적는다. 필터링 없이:

- 모바일 앱 UI 감사 완료하기
- Jake한테 디자인 시스템 핸드오프 관련 답장
- Mia 포트폴리오 리뷰 도와주기로 했는데
- Figma 심화 강좌 신청
- 병원 예약 — 너무 미뤘다
- Q3 전략을 위한 경쟁사 앱 리서치
- 노트북 팬 소리 이상한데, 점검 맡겨야
- "Shape Up" 읽기 (책상에 6개월째)
- 서울 출장 경비 정산
- 개인 사이트 업데이트 — 3년째 그대로
- 연간 성과 리뷰 다가오는데 생각 정리해야
- 엄마한테 전화 다시 하기

47개 항목. 전부 꺼낸다.

2. Area 설정 (10분)

목록을 보니 자연스러운 그룹핑이 보인다:

Area:
- 직장
- 자기계발
- 건강
- 개인
- 재정

3. Inbox 처리 (40분)

각 항목을 처리한다:

"모바일 앱 UI 감사" → 행동 가능. Do. 하지만 너무 크다. 나눈다: "감사 범위 및 체크리스트 정의" (1일차), "네비게이션 플로우 감사" (2일차), "폼·입력 컴포넌트 감사" (3일차). Action 세 개, 사흘.

→ Area: 직장 → Flow: 모바일 앱 UI 감사

"Jake한테 답장" → 행동 가능. 5분이면 된다. 지금 바로 한다. 2분 규칙(비슷하다). 목록에서 삭제.

"Mia 포트폴리오 리뷰" → 행동 가능. Do. 단일 Action: "Mia와 포트폴리오 리뷰 1시간 일정 잡기".

→ Area: 직장 → Action (독립)

"Figma 심화 강좌" → 언젠가 할 것. 긴급하지 않음. Someday.

"병원 예약" → 행동 가능. Do. "건강검진 예약 — 가장 빠른 날짜로."

→ Area: 건강 → Action (독립)

"경쟁사 앱 리서치" → 행동 가능. 너무 크다. 나눈다: "조사할 경쟁사 8개 목록 작성" → "경쟁사 1~4 분석" → "경쟁사 5~8 분석" → "Q3 덱용 요약 작성".

→ Area: 직장 → Flow: Q3 경쟁사 리서치

"노트북 팬" → 행동 가능. 2분: 지금 바로 기술 지원 예약.

"Shape Up 읽기" → Someday. 긴급하지 않음.

"경비 정산" → 행동 가능. Do. "서울 출장 경비 정산 — 영수증 사진 앱에 있음".

→ Area: 재정 → Action (독립)

"개인 사이트 업데이트" → Someday. 하고 싶지만 지금은 아님.

"성과 리뷰" → 행동 가능. Flow를 만든다: "자기평가 초안 작성" → "임팩트 사례 수집" → "매니저와 검토".

→ Area: 직장 → Flow: 성과 리뷰 준비

"엄마한테 전화" → 2분 규칙. 지금 바로 전화한다.

첫 설정 후 시스템:

Area: 직장
  ├─ Flow: 모바일 앱 UI 감사
  │    └─ [Do] 감사 범위 및 체크리스트 정의     ← 내일 올라옴
  ├─ Flow: Q3 경쟁사 리서치
  │    └─ [Do] 경쟁사 8개 목록 작성             ← 내일 올라옴
  ├─ Flow: 성과 리뷰 준비
  │    └─ [Do] 자기평가 초안 작성               ← 내일 올라옴
  └─ Action: [Do] Mia와 포트폴리오 리뷰 일정 잡기

Area: 건강
  └─ Action: [Do] 건강검진 예약

Area: 재정
  └─ Action: [Do] 서울 출장 경비 정산

Someday: Figma 강좌, 개인 사이트, Shape Up

첫 번째 Today (월요일 아침, 8분):

Action 다섯 개가 자동으로 올라온다. 추가하거나 빼지 않는다. 맞아 보인다.

[Do] 감사 범위 및 체크리스트 정의
[Do] 경쟁사 8개 목록 작성
[Do] 자기평가 초안 작성
[Do] Mia와 포트폴리오 리뷰 일정 잡기
[Do] 건강검진 예약
[Do] 서울 출장 경비 정산

배칭할 수 있는 것부터 시작한다 (빠른 관리 항목 두 개: 예약하기, 경비 정산 — 15분에 완료). 그 다음 세 개의 프로젝트 Action에 집중 작업.

오후 1시: Today 비어있음. 여섯 가지 완료. 세 개의 활성 작업 흐름이 동시에 전진 중. 경비 정산 완료. 병원 예약 완료.

무엇이 달라졌나:

OTD 이전: 머릿속, 포스트잇, 개인 카톡에 47개 항목. 지속적인 배경 불안. 명확한 "완료" 신호 없음.

OTD 이후: 같은 47개 항목이 시스템에 있다. 한 저녁에 전부 처리했다 — 각각에 대해 결정하고, 배치하거나, 삭제했다. 다음 날 아침, 그 중 여섯 개가 작업 가능한 상태로 올라온다. 나머지는 관련될 때 올라올 것이다.

작업 자체는 달라지지 않았다. 관리하는 오버헤드가 달라졌다.

기본 하루

README의 예시를 확장했다.

시스템 상태:

Area: 사이드 프로젝트
  └─ Project: 앱 런칭
       ├─ Flow: MVP 개발
       │    └─ [Do] 인증 모듈 기술 스펙 작성    ← 활성
       └─ Flow: 런칭 마케팅
            └─ [Delegate] AI에게 랜딩 페이지 카피 초안 요청  ← 활성

Area: 커리어
  └─ Flow: 이직 준비
       └─ [Review] 어제 위임한 연봉 리서치 결과 검토  ← 활성

Area: 건강
  └─ [Do] 건강검진 예약  ← 독립 Action

Daily Review (07:00, 5분):

Today 자동 등장:

[Review] 어제 위임한 연봉 리서치 결과 검토
[Delegate] AI에게 랜딩 페이지 카피 초안 요청
[Do] 인증 모듈 기술 스펙 작성
[Do] 건강검진 예약

괜찮아 보인다. 추가할 것 없음. 시작.

실행:

08:00 — Review 단계 연봉 리서치를 연다. 수치를 훑는다. 데이터가 탄탄하다 — 승인. [Review] 체크. 이직 준비 Flow의 다음 Action 열림: "연봉 범위에 맞는 타겟 기업 목록 만들기". 내일 Daily Review에 올라올 것이다.

09:00 — Delegate 단계 랜딩 페이지 프롬프트 작성: "팀의 비동기 업무 관리를 돕는 개발자 도구의 랜딩 페이지 초안. 톤: 명확하고 직접적. 헤드라인, 기능 3가지, CTA 하나 포함. 군더더기 없이." AI에 보냄. [Delegate] 체크. 해당 Action이 런칭 마케팅 Flow에서 Await으로 전환.

10:00 — Do 단계 인증 모듈 스펙 작성을 연다. 90분 동안 작성. 완료. [Do] 체크. MVP 개발 Flow의 다음 Action 열림: "팀과 스펙 검토".

짧은 휴식. 건강검진 예약 — 3분 걸림. [Do] 체크.

12:00 — Today 비었음.

오늘 세 개의 Flow가 전진했다. Action 네 개 완료. 결과 하나 승인. Delegate 하나 진행 중. 끝.

페르소나: 사이드 프로젝트가 있는 직장인

OTD 이전: 매주 일요일, 사이드 프로젝트를 할 계획이었다. 매주 일요일, 직장 일이 넘쳐왔다 — Slack 메시지, 미완성 문서, 기다릴 수 있었던 "긴급" 요청. 저녁이 되면 사이드 프로젝트는 여전히 그대로였다. 4개월째 반복됐다.

프로필: 낮에는 PM으로 근무. 사이드로 SaaS 도구 개발 중. 하나가 나머지를 잡아먹지 않으면서 둘 다 전진시키고 싶다.

과제: 직장 업무는 끊임없이 반응적인 일을 만든다. 사이드 프로젝트는 능동적인, 집중된 시간이 필요하다. 시스템 없이는 사이드 프로젝트가 항상 진다.

Area 구성:

Area: 직장, SaaS 프로젝트, 건강, 재정, 개인

Flow 구성:

Area: 직장
  ├─ Flow: Q2 제품 로드맵
  ├─ Flow: 이해관계자 얼라인먼트 (지속)
  └─ Flow: PM 인턴 채용

Area: SaaS 프로젝트
  ├─ Flow: MVP 기능 개발
  ├─ Flow: 초기 사용자 인터뷰
  └─ Flow: 랜딩 페이지

일반적인 날 Today:

직장 Flow 등장: 로드맵 검토, 이해관계자 Slack 스레드 응답, 인터뷰 질문 준비.

SaaS Flow 등장: 다음 개발 태스크, 사용자 인터뷰 이메일 발송, 랜딩 페이지 섹션 작성.

시스템이 매일 둘 다 전진하게 보장한다. 하루에 어느 쪽도 많이 전진하지 않는다 — 하지만 모든 것에 일관된, 매일의 진전이 있다.

핵심 인사이트: OTD 없이 이 사람은 업무 반응에 하루를 보내고, 사이드 프로젝트를 건드리기엔 너무 지쳐서, "주말에 할게"라고 스스로에게 말한다. OTD가 있으면 사이드 프로젝트의 Action이 Today에서 업무 Action 옆에 있다. 같은 업무 날에 완료된다.

페르소나: 프리랜서

OTD 이전: 3일 전에 클라이언트가 피드백을 보냈다. 이메일 어딘가에 있었다. 아니면 공유 폴더였나. 프로젝트가 일주일째 수정을 기다리고 있었는데, 누구 차례인지 확신이 없었다. 다른 두 클라이언트도 뭔가를 기다리고 있었다. "누가 뭘 갖고 있고, 누가 나한테서 뭘 기다리는지" 추적하는 정신적 오버헤드가 실제 디자인 작업보다 더 많은 시간을 잡아먹고 있었다.

프로필: 한 번에 3~4개 클라이언트와 일하는 그래픽 디자이너. 각 클라이언트마다 진행 중인 작업과 새 프로젝트 요청이 있다.

과제: 여러 클라이언트, 여러 타임라인, 많은 Review 사이클(작업물 보내기, 피드백 대기, 수정). 공을 떨어뜨리기 쉽다.

핵심 Flow 패턴:

모든 클라이언트 프로젝트에:

Flow: [클라이언트] [프로젝트명]
  1. [Do]       브리프 검토 및 질문 정리
  2. [Do]       첫 번째 초안 작성
  3. [Delegate] 클라이언트에게 초안 검토 요청
  4. [Await]    클라이언트 피드백 대기
  5. [Review]   피드백 처리
  6. [Do]       피드백 기반 수정
  7. [Delegate] 수정본 발송
  8. [Await]    최종 승인 대기
  9. [Review]   승인 및 마무리
 10. [Do]       청구서 발행

이 패턴이 프로젝트마다 반복된다. 클라이언트 4개에 각각 여러 프로젝트면 활성 Flow가 8~12개일 수 있다.

Today:

많은 Await 항목들 (별도로 추적, Today에 없음). 하지만 어느 날이든:

2~3개 Review 항목 (밤새 도착한 피드백)
2~3개 Delegate 항목 (작업물 발송)
2~3개 Do 항목 (실제 디자인 작업)

Review 항목이 먼저 올라온다. 피드백 백로그를 처리하고 Flow를 열어준다. 그 다음 Delegate들이 나간다. 그 다음 Do 항목: 집중된 디자인 시간.

핵심 인사이트: Await/Review를 명시적으로 추적하지 않으면 클라이언트 피드백이 틈새로 빠진다. Mode 구조가 있으면 모든 공이 시스템 안에 있다. "내가 처리하는 줄 알았는데요"가 없다.

페르소나: 학생

OTD 이전: 논문이 6개월째 "진행 중"이었다. 메모가 담긴 폴더, 반쯤 쓴 아웃라인, "여유가 생기면 하겠다"는 막연한 의도가 있었다. 여유는 오지 않았다. 수업 과제 데드라인이 항상 더 급했다. 논문은 계속 밀렸다. 논문에 대한 불안은 커졌지만, 논문 자체는 전진하지 않았다.

프로필: 석사생, 논문 작업 중, 수업 과제, 아르바이트, 사회생활 유지하려는.

과제: 장기 작업(논문)이 단기 작업(수업 과제 데드라인)과 경쟁한다. 둘 다 급하게 느껴지거나 둘 다 안 그렇게 느껴진다. 논문의 어느 하루의 작업도 급해 보이지 않으니까 몇 주씩 논문을 방치하기 쉽다.

Area 구성:

Area: 논문, 수업, 아르바이트, 개인

논문 Flow 패턴:

Flow: 2장 — 문헌 검토
  1. [Do]       핵심 논문 20편 목록 작성
  2. [Do]       논문 1~5편 읽고 주석 달기
  3. [Do]       논문 6~10편 읽고 주석 달기
  ...
  8. [Do]       2.1절 초안 작성
  9. [Do]       2.2절 초안 작성
  ...
 14. [Do]       챕터 전체 1차 초안
 15. [Delegate] 지도교수에게 피드백 요청
 16. [Await]    지도교수 피드백 대기
 17. [Review]   피드백 처리
 18. [Do]       수정

논문 챕터가 작고 매일 완료 가능한 Action으로 나뉜다. 매일, 논문 Action 하나가 Today에 올라온다.

논문 + 수업 날 Today:

[Review] 지난 세미나 페이퍼 TA 피드백 확인
[Do] 논문 3~5편 읽고 주석 달기
[Do] 화요일 수업 문제집 풀기
[Do] 아르바이트 (시간 고정, 캘린더에 블록)

논문은 항상 Today에 있다 — Action 하나. 하루를 압도하지 않는다. 몇 주씩 사라지지 않는다.

핵심 인사이트: "큰 시간 블록이 생기면 논문 할게"가 논문이 안 써지는 방법이다. OTD는 매일을 논문의 날로 만든다 — 하루에 Action 하나씩, 매일.

페르소나: 관리자

OTD 이전: "Waiting For" 목록에 23개가 있었다. 어떤 건 지난주, 어떤 건 지난달 것이었다. 대략 무엇이 보류 중인지는 알았지만, "대략"이 문제였다 — 지난달에 두 번, 무언가가 묻혀서 빠졌다. 매주 금요일마다 막연한 두려움이 있었다: 팔로업을 잊은 게 없나? 조율 작업은 실재했지만, 보이지 않았다.

프로필: 엔지니어링 매니저. 업무의 절반이 조율, 위임, 막힌 것 해제 — 직접 실행이 아니다.

과제: 대부분의 일이 Delegate → Await → Review 사이클이다. GTD의 프로젝트 모델이 이걸 잘 담지 못했다. "Waiting For"는 항상 두려운 긴 목록이었다.

일반적인 날 Mode 분포:

Today:

4개 Review 항목 (승인할 PR, 사인할 문서, 읽을 보고서)
5개 Delegate 항목 (줄 피드백, 보낼 요청, 전달할 결정)
2개 Do 항목 (실제 실행 — 글쓰기, 분석)

실행:

오전 Review 단계: 30~40분간 결정들을 처리. 여러 Flow 열림. PR 하나가 재검토 필요 — 새 Review Action 생성.

위임 단계: 20분간 피드백, 요청, 지시 발송. 다섯 개가 나간다. Await 다섯 개의 시계가 시작된다.

Do 단계: 60분간 나머지 두 항목에 집중 작업.

점심 전에 완료. 오후는 미팅 (캘린더, Today 아님).

핵심 인사이트: 관리자의 업무는 대부분 시스템 오버헤드다 — 타인의 작업을 촉진하는 것. OTD가 그 오버헤드를 가시화하고 실행 가능하게 만든다. "팔로업해야 하는 게 있는데"라는 막연한 느낌 대신, 모든 Await 항목이 추적되고 팔로업이 필요할 때 올라온다.

방해받은 날 처리하기

어떤 날은 Today가 현실과 만나서 살아남지 못한다. 프로덕션 인시던트. 갑작스러운 회의. 진짜로 기다릴 수 없는 긴급 요청.

원칙: 받아들이고, 조정하고, 계속한다.

하루 중 긴급한 것이 도착했을 때:

Inbox에 캡처 (하루 중이라도)
처리: 오늘 행동 가능한가? 예.
Today에 당긴다.
다른 것을 밀어낸다면, 그것을 의식적으로 받아들인다.

하루 끝에 Today가 비지 않았다면:

안 된 항목들이 불필요해졌는가? 버린다.
여전히 해야 하는가? 내일 다시 올라온다.
Today가 체계적으로 과부하였는가? 내일은 Action을 더 적게 계획한다.

빈 Today는 목표이지 요구사항이 아니다. 어떤 날은 목표가 움직인다. 괜찮다 — 무엇이 움직였고 왜인지 명확한 한.

실전 예시 ​

0일차: 아무것도 없는 상태에서 시작하기 ​

기본 하루 ​

페르소나: 사이드 프로젝트가 있는 직장인 ​

페르소나: 프리랜서 ​

페르소나: 학생 ​

페르소나: 관리자 ​

방해받은 날 처리하기 ​