Mode
모든 Action에는 Mode가 있다 — 누가 실행하고, 어떤 상태인가.
- Do — 내가 직접 실행한다.
- Delegate — AI 또는 다른 사람에게 위임한다.
- Await — 위임한 작업이나 외부 입력의 결과를 기다린다.
- Review — 결과가 돌아왔다. 검토 후 승인하거나 재위임한다.
Mode가 왜 존재하는가
GTD에서 Action은 물리적 컨텍스트로 필터링됐다 — @컴퓨터, @전화, @외출. 위치나 필요한 도구별로 태스크를 묶어서, 전화기가 있을 때 전화하고 컴퓨터 앞에 있을 때 컴퓨터 작업을 한다는 개념이었다.
2000년대 초반에는 합리적인 모델이었다. 오늘날, 대부분의 지식 업무는 컴퓨터에서 이루어진다. @컴퓨터가 모든 것의 90%를 커버한다. 필터가 의미를 잃었다.
Mode는 물리적 컨텍스트 대신 실행 상태를 사용한다. "어디 있나?"가 아니라 "누가 이걸 하고 있고, 다음에 무엇이 필요한가?"를 묻는다.
사소한 수정이 아니다. 컨텍스트에서 Mode로의 전환이 OTD의 실행 순서 — Review → Delegate → Do — 를 가능하게 하고, Today에 무엇이 있든 하루에 명확한 구조를 부여한다.
네 가지 Mode
Do
직접 실행한다.
Do Action은 오직 내가 할 수 있는 일들이다 — 글쓰기, 결정, 창작, 분석, 전화. 내가 유일한 실행자인 것들.
Do Action을 체크하면, 작업이 완료된 것이다.
Delegate
다른 누군가에게 넘긴다 — AI, 동료, 외주업자, 서비스.
"Delegate"는 "AI를 쓴다"가 아니다. 실행을 나 이외의 누군가가 한다는 뜻이다. 비서에게, 팀원에게, Claude에게 위임하는 것 모두 같은 Mode다.
핵심 순간: 지시를 작성하거나 전달한다. 그 행위 — 지시를 만들어 보내는 것 — 가 완료하는 것이다. Delegate Action을 체크하면: 지시 전달 완료, 공이 그들의 코트로 넘어간 것이다.
그리고 해당 Action은 Flow에서 Await로 전환된다.
Await
외부에서 무언가가 진행 중이다. 기다리는 중이다.
Await Action은 아직 아무것도 할 필요가 없다. 위임되어 진행 중인 작업, 또는 내 통제 밖의 무언가에 의존하는 작업(클라이언트의 결정, 제3자의 서류, 배송)을 나타낸다.
Await의 목적은 가시성이다. GTD에서 "Waiting For"는 가끔 확인하는 별도 목록이었다. OTD에서 Await는 1급 Mode다. 모든 Await 항목이 시스템에서 보인다. Weekly Review 때 Await 중에 너무 오래 기다리고 있는 것은 없는지 명시적으로 확인한다.
Await Action은 Today에 자동으로 올라오지 않는다 — 별도로 추적된다. 결과가 도착하면 Review Action을 만든다.
Review
결과가 돌아왔다. 확인하고, 결정하고, 전진한다.
Review는 위임한 작업의 루프를 닫는 곳이다. 대답해야 할 질문:
- 승인 — 결과가 좋다. Review Action을 체크한다. Flow의 다음 Action이 열린다.
- 재위임 — 결과가 맞지 않는다. 수정된 지시로 새 Delegate Action을 만든다.
- 직접 수정 — 여기서부터 내가 한다. Do Action으로 전환하고 계속한다.
Review는 대개 빠르다 — 문서, AI 출력물, 동료의 작업을 보고 받아들일지 돌려보낼지 결정하는 몇 분. 하지만 진짜 결정이다. Review를 건너뛰면 전진할 수 있는 Flow가 이유 없이 멈춰 있게 된다.
실행 순서: Review → Delegate → Do
제안이 아니다. Today를 처리하기 위한 설계된 순서다.
Review 먼저. 결과가 이미 기다리고 있다. Review 하나를 처리하는 데 몇 분이면 되고, 그 Flow의 다음 Action이 열린다. Review를 방치하면, 전진할 수 있는 Flow가 얼어붙어 있는 것이다.
Delegate 그 다음. 지시를 보내는 건 빠르다. 빨리 보낼수록 결과가 빨리 온다. 위임받은 쪽이 작업하는 동안 나는 다른 일을 할 수 있다. Delegate를 한 시간 늦출 때마다, 병렬 작업 시간 한 시간을 잃는 것이다.
Do를 마지막에. 직접 실행하는 작업은 시간과 집중이 가장 많이 든다. Review와 Delegate를 먼저 처리해서 다른 Flow들이 돌아가게 만든 다음에, 남은 시간을 Do에 온전히 투자한다.
같은 Mode 안에서의 순서는 사용자가 결정한다. Do 항목 두 개 중 하나를 고르는 건 가벼운 판단 — 우선순위, 에너지, 컨텍스트에 관한 것이다. 그게 원칙 2다: 당신이 하루를 설계한다. 하지만 Mode가 그 결정을 더 작게 만든다. 구분 없는 10개 중에서 고르는 대신, 같은 Mode의 2~3개 중에서 고른다.
Mode 시나리오
시나리오 1: AI와 함께 보고서 작성
[Do] 구조와 핵심 논지 작성 ← 내가
[Delegate] 아웃라인 기반으로 AI에게 2~4절 초안 요청 ← AI
[Await] AI 초안 대기 ← 대기 중
[Review] 초안 읽고, 수정 방향 결정 ← 내가
[Do] 수정 및 완성 ← 내가Action 다섯 개. Do 둘, Delegate 하나, Await 하나, Review 하나. 결정부터 완성된 초안까지의 전체 루프가 Flow에서 보인다.
시나리오 2: 외주 고용
[Do] 브리프 및 요구사항 작성
[Delegate] 플랫폼에 게시 / 후보자에게 발송
[Await] 제안서 수신 대기
[Review] 제안서 평가, 후보자 선택
[Delegate] 계약서 서명 요청
[Await] 서명된 계약서 대기
[Review] 계약서 수령 확인, 진행
[Do] 외주 온보딩Delegate → Await → Review의 루프들. 각 사이클이 추적된다. 빠져나가는 것이 없다.
시나리오 3: 외부 입력 대기
[Do] 집주인에게 계약 갱신 문의 발송
[Await] 집주인 응답 대기
[Review] 임대 조건 검토
[Do] 결정 후 회신여기서 Await는 위임된 작업이 아니라 외부 상황이다. 문의를 보내고 기다리는 것. 같은 Mode. 같은 가시성.
Review를 잘 하는 방법
Review는 대부분의 사람이 투자를 적게 하는 Mode다. 몇 분밖에 걸리지 않지만, 여기서 내리는 결정의 질이 Flow가 깔끔하게 전진하는지 아니면 재작업 루프로 돌아오는지를 결정한다.
실제로 무엇을 결정하는가
결과가 도착했을 때, 하나의 질문에 답하는 것이다: 이것이 앞으로 나아가기에 충분한가?
"완벽한가?"가 아니다. "내가 다르게 했을 것인가?"도 아니다. 기준은: 이 결과로 Flow의 다음 Action이 진행될 수 있는가?
예라면 — 승인한다. 재고하거나, 다듬거나, 범위를 추가하지 않는다. 앞으로 나아간다.
아니라면 — 무엇이 잘못됐는지 구체적으로 말한다. 막연한 불승인("뭔가 맞지 않는 것 같아")은 또 막연한 결과를 만든다. 재위임 지시는 정확히 무엇을 고쳐야 하는지 말해야 한다: "결론이 너무 일반적입니다 — B2B 사용 사례에 구체적으로 맞춰주세요"는 실행 가능하다. "결론을 개선해주세요"는 아니다.
AI 아웃풋 검토 방법
AI 아웃풋에는 특유의 실패 패턴이 있다: 유창하고 그럴듯하지만 특정 방식으로 틀린 것이 있어서 잡아내야 한다. 검토 방식이 사람의 작업을 검토하는 것과 다르다.
있는 것만이 아니라 없는 것을 확인한다. AI는 당신이 준 프레임에서 요청한 것을 준다. 프레임이 불완전했다면, 아웃풋은 완전해 보이지만 무언가가 빠져 있다. 묻는다: "내가 기대했는데 없는 게 뭐지?"
자신있는 오류를 찾는다. AI는 맞을 때와 틀릴 때 동일하게 유창하다. 사실 주장, 숫자, 출처를 훑는다. 이것들이 자신있는 오류의 가장 흔한 원천이다.
재위임해야 할 것을 직접 편집하지 않는다. 아웃풋의 20~30% 이상을 바꿔야 한다면, 직접 편집하는 것보다 더 나은 지시로 재위임하는 게 빠르다. 근본적으로 방향이 틀린 아웃풋을 편집하는 것은 더 나은 프롬프트로 처음부터 다시 하는 것보다 느리다.
언제 위임을 멈추고 직접 해야 하는가
모든 재위임 사이클에는 지시를 계속 다듬는 것보다 직접 하는 게 빠른 시점이 온다. 그 시점은 보통:
- 같은 Action에 세 번째 재위임
- 수정이 지시로 표현하기 어려운 컨텍스트를 필요로 할 때
- 남은 작업이 설명하는 것보다 하는 게 빠를 때
그 시점에 Review Action을 Do Action으로 전환한다. 실패로 취급하지 마라. 이건 위임된 작업에 대해 내리는 것과 같은 판단이다.
대량 Await 관리
특히 AI를 활용할수록 위임이 업무의 큰 부분을 차지하게 되면서 Await 항목이 쌓인다. Await 10~20개가 동시에 있는 것은 정상이다. 관리 접근법 없이는 "보냈는데 막연히 기다리는 것들"의 불투명한 풀이 된다.
예상 도착 시간으로 분류
모든 Await 항목이 같은 긴박성을 가지지 않는다. Await 항목을 만들 때 언제 결과를 기대하는지 메모한다:
- 수 시간 — AI 응답, 동료에게 간단한 질문
- 수 일 — 문서 검토, 외부 승인, 벤더 응답
- 수 주 — 계약 협상, 장기 리서치, 규제 절차
이 분류가 Weekly Review 때 어떤 Await 항목을 먼저 확인하고 언제 팔로업이 실제로 필요한지 알려준다.
팔로업 결정
Await 항목에 팔로업이 필요한 경우:
- 예상 도착 시간을 지났다
- 현재 중요한 Flow의 다음 Action이 여기서 막혀 있다
- 외부 상황이 바뀌었다 (위임했던 사람이 이제 자리를 비웠다)
팔로업이 필요하지 않은 경우:
- 예상 시간 안에 있다
- 후속 Flow가 현재 시간이 급하지 않다
- 팔로업이 가치 없이 마찰만 추가한다
모든 것에 동등하게 팔로업하는 것은 아무것도 팔로업하지 않는 것만큼 나쁘다. 실제로 막고 있는 것으로 우선순위를 정한다.
팔로업 배칭
여러 Await 항목에 팔로업이 필요할 때 묶어서 처리한다. 하루에 흩어서가 아니라 Delegate 단계의 한 세션에 모든 팔로업 메시지를 작성한다. 집중력을 분산시키지 않으면서 Await 목록이 계속 돌아가게 한다.
Await와 Weekly Review
Weekly Review 때 전체 Await 목록을 훑으며 각 항목에 묻는다:
- 예상 시간을 지났는가?
- 후속 Flow가 막혀 있고 현재 중요한가?
- 더 긴박하게 또는 덜 긴박하게 만드는 변화가 있었는가?
(1)과 (2)에 예라고 답하는 항목은 다음 주 작업에 팔로업 Action을 만든다. 둘 다 아니오인 항목은 기다릴 수 있다.
GTD 관점에서의 Mode
| GTD | OTD Mode | 차이 |
|---|---|---|
| Next Action | Do | 동일 |
| (위임이 암시적) | Delegate | 명시적, 1급 Mode |
| Waiting For | Await | 주요 Mode로 승격 |
| (해당 없음) | Review | 신규: 돌아온 결과물 검토 |
가장 큰 추가는 Review다. GTD에는 위임한 작업을 검토하는 전용 개념이 없었다 — 결과물이 어딘가에 도착하면 어느 시점에 발견했다. OTD는 검토 단계를 명시적이고, 추적 가능하고, 실행 순서의 적시에 배치한다.