Skip to content

Action

Action은 작업의 최소 단위다. 하루 안에 완료 가능하다.


Action이란 무엇인가

Action은 하나의 체크박스다. 구체적으로 할 것 하나. 할 수 있는 시간 하루.

모든 Action에는:

  • 설명 — 정확히 무엇을 할 것인가
  • Mode — Do, Delegate, Await, Review 중 하나
  • 선택적 날짜 — 즉시가 아니라면 언제 올라올 것인가

Action은 OTD 트리의 잎이다. Area, Project, Flow는 컨테이너다. Action이 실제로 하는 것이다.


하루 제약의 이유

임의적인 제약이 아니다. 전체 시스템을 작동시키는 메커니즘이다.

OTD의 핵심 피드백 루프는: Today가 비면 → 오늘 할 일이 끝난 것이다.

하루 안에 끝낼 수 없는 Action은 오늘 체크할 수 없다. 오늘 체크할 수 없으면, Today가 진짜로 빌 수 없다. Today가 빌 수 없으면 완료 신호를 잃는다. 항상 일하고 있지만 끝나는 법이 없고, 진짜 진전과 그냥 바쁜 것을 구분할 방법이 없다.

이 제약이 명확성을 강제한다. "보고서 쓰기"는 Action이 아니다 — 며칠짜리 덩어리다. 하지만 실제로 그 며칠 동안 뭘 하는지 보면:

날짜실제로 하는 일
월요일구조 잡기
화요일전반부 작성
수요일후반부 작성
목요일수정 및 다듬기
금요일최종 검토 후 전송

각각이 진짜 Action이다. 각각 하루 안에 완료된다. 각각 체크될 수 있고, Today를 빈 쪽으로 한 걸음씩 전진시킨다.

보고서가 닷새가 걸리는 게 아니다. 닷새짜리 Action 다섯 개가 각각 하루 걸리는 것이다.


좋은 Action vs. 부실한 Action

좋은 Action은 구체적이고 범위가 정해져 있다.

  • ✓ "경쟁사 3곳의 가격 페이지 조사하고 메모하기"
  • ✓ "제안서 서론과 배경 섹션 작성"
  • ✓ "클라이언트에게 계약서 초안 검토 요청"
  • ✓ "건강검진 예약 — 앞으로 2주 안에 가장 빠른 날짜로"

부실한 Action은 모호하거나 범위가 없다.

  • ✗ "제안서 작업" — 어떤 부분을? 얼마나? 언제 끝나나?
  • ✗ "경쟁사 조사" — 전부? 무슨 목적으로? 결과물은?
  • ✗ "클라이언트 처리" — 정확히 무엇을?
  • ✗ "운동" — 이건 Action이 아니라 습관일 수 있다

테스트: 내일 아침 이 Action이 Today에 올라왔을 때, 추가적인 생각 없이 즉시 시작할 수 있는가? 그렇다면 충분히 구체적이다. 시작 전에 다시 해석해야 한다면, 다시 써라.


다양한 위치의 Action

Action은 구조의 다양한 위치에 있을 수 있다:

Area → Action                    건강검진 예약
Area → Flow → Action             링크드인 프로필 업데이트
Area → Project → Flow → Action   지원서 아웃라인 작성

"올바른" 깊이는 하나가 아니다. 어떤 흐름에도 속하지 않는 독립 태스크는 Area 바로 아래에 있다. 특정 작업 흐름의 일부인 태스크는 Flow 안에 있다. 구조는 작업의 실제 성격을 반영한다.


Mode와 Action

모든 Action에는 Mode가 있다. Mode는 누가 처리하고 어떤 상태인지를 알려준다.

  • Do — 직접 실행한다
  • Delegate — 다른 사람에게 넘긴다 (AI, 동료, 외주)
  • Await — 외부에서 무언가가 진행 중이다; 대기 중이다
  • Review — 결과가 돌아왔다; 검토하고 결정한다

Mode는 부수적인 것이 아니다 — Inbox에서 처리할 때 Action을 정의하는 방법의 일부다. 정의 시점에 Mode를 결정해두면, 나중에 Action을 마주쳤을 때 "잠깐, 내가 여기서 정확히 뭘 해야 하지?"를 고민하지 않아도 된다.

네 가지 Mode가 실행 중에 어떻게 함께 작동하는지는 Mode를 참조.


2분 규칙

2분 이내에 끝나는 일이면 시스템에 넣지 마라. 즉시 실행하라.

Action을 캡처하고, 배치하고, 검토하는 오버헤드가 그냥 하는 것보다 크다. 90초짜리 태스크를 정리하는 건 비효율이다.

GTD에서 그대로 가져온 규칙이다. OTD에서도 동일하게 적용된다.

2분 규칙은 처리(Processing) 단계(Inbox를 처리할 때)에 적용된다. 실행(Execution) 단계(Today를 처리할 때)가 아니다. Today 중에 2분짜리 태스크가 나왔다면 그냥 하면 된다 — 다시 캡처하지 않는다.


날짜가 있는 Action

Action에는 선택적 날짜를 붙일 수 있다. 즉시가 아닌, 해당 날짜 이후에 Today에 올라오게 된다.

날짜를 쓰는 경우:

  • 아직 행동할 수 없는 것 ("임대차 계약 갱신 전화" — 만료 60일 전이 되어야 관련된다)
  • 자연스러운 트리거 날짜가 있는 것 ("목요일 발표 준비" — 수요일에 올라와야 한다)

날짜를 우선순위 레이블로 쓰지 마라. 올라오는 시점을 통제하려고 모든 Action에 날짜를 붙이면, 삶을 수동으로 다시 스케줄링하는 것이고 시스템의 목적을 무너뜨린다. 순서는 Flow에 맡겨라. 날짜는 진짜 시간적 이유가 있을 때만 쓴다.


반복 Action

반복 Action은 완료 후 정의된 주기에 시스템에 재진입한다.

Action: [Do] 월간 경비 정산 제출   (반복: 매월 1일)
Action: [Do] 프로젝트 파일 백업     (반복: 매주 금요일)
Action: [Do] 클라이언트 팔로업      (반복: 완료 후 3일)

두 가지 유형이 있다:

고정 주기 — 이전 완료 시점과 무관하게 특정 날짜에 올라온다. 캘린더에 종속된 작업에 사용한다: 주간 보고서, 월간 리뷰, 분기 세금 신고.

상대 주기 — 이전 완료 후 정해진 일수가 지나면 올라온다. 내 페이스에 의존하는 작업에 사용한다: "제안서 발송 후 3일 뒤 팔로업", "회의 후 2일 뒤 메모 검토".

반복 Action은 구조 안에서 일반 Action과 동일하게 위치한다 — Area 바로 아래에, 또는 Flow 안에. 유일한 차이는 완료가 영구적인 완료가 아닌 새 인스턴스 생성을 트리거한다는 것이다.

반복 작업에 여러 단계가 있다면 단일 반복 Action으로 충분하지 않다. 반복 Flow를 사용하라 — Flow 참조.

Released under the open source license.