Flow
Flow는 순서가 있는 구체적인 작업 흐름이다. 내부는 순차, Flow 간에는 병렬.
Flow인가, Project인가?
OTD 구조에서 가장 중요한 결정이다. 기준은 질문 하나다:
"이 일의 여러 부분을 동시에 독립적으로 진행할 수 있는가?"
여러 독립적인 부분을 동시에 진행할 수 있는가?
│
├─ 예 → Project (여러 Flow가 병렬 진행)
│ 각 Flow가 Today에 Action 하나씩 올림
│
└─ 아니오 → Flow (하나의 순차 흐름)
한 번에 하나씩, 순서대로예 → Project (병렬로 진행할 수 있는 여러 Flow를 담는다) 아니오 → Flow (하나의 순차 흐름)
"이직 준비"를 Flow로 쓸 때:
Flow: 이직 준비
1. 이력서 업데이트
2. 지원 기업 리스트 작성
3. 지원서 제출
4. 인터뷰 준비
5. 오퍼 협상하나의 흐름. 각 단계가 이전 단계 뒤에 온다.
"이직 준비"를 Project로 쓸 때:
Project: 이직 준비
├─ Flow: 이력서 & 포트폴리오 (아래와 병렬로 진행 가능)
├─ Flow: 기업 리서치 & 지원 (아래와 병렬로 진행 가능)
└─ Flow: 네트워킹 (위와 병렬로 진행 가능)세 개의 독립 흐름. 동시에 전진한다.
둘 다 틀리지 않았다 — 실제로 일이 어떻게 전개되는지에 달려 있다.
Flow란 무엇인가
OTD에서 실제 작업이 일어나는 곳이 Flow다. 특정 결과를 향한, 이름이 있는 순차 Action들의 흐름이다. 미완료 Action이 하나 이상 있으면 활성 Flow이고 — 첫 번째 미완료 Action이 Today에 올라온다.
Flow: 지원서 작성
1. [Do] 자격요건 확인 ← Today에 올라옴
2. [Do] 아웃라인 작성
3. [Delegate] 멘토에게 초안 피드백 요청
4. [Await] 멘토 응답 대기
5. [Review] 멘토 피드백 검토
6. [Do] 최종 수정
7. [Do] 제출1번이 Today에 있다. 완료하면 2번이 올라온다. 그렇게 계속된다. Flow가 자기 영역 안에서 "다음에 뭘 해야 하지?" 질문을 처리한다.
내부 순차, Flow 간 병렬
이게 Flow의 핵심 설계다.
내부 순차: Flow 안의 Action들에는 자연스러운 순서가 있다. 현재 Action이 완료되어야 다음 Action이 올라온다. 매일 아침 순서를 결정할 필요가 없다 — Flow가 이미 결정해놓았다.
Flow 간 병렬: 여러 Flow가 첫 번째 Action을 Today에 동시에 올린다. 세 개의 활성 Flow가 있으면 세 가지 작업 흐름에서 동시에 Action이 Today에 올라올 수 있다. 각자 독립적으로 전진한다.
이게 GTD와의 핵심 차이다. GTD의 Project는 하나의 순차 사슬이었다. OTD의 Flow는 동시에 진행되는 여러 독립 사슬이고, 각자 전면 Action을 올린다.
순서를 깨는 경우
순차 순서는 기본값이지, 제약이 아니다. 당신이 지휘자다 — 오버라이드할 수 있다.
같은 Flow의 Action 두 개를 동시에 진행하고 싶다면, 두 번째 Action을 수동으로 Today에 끌어오면 된다. 시스템이 순서를 제공하고, 적절하다고 판단하면 그 순서를 깬다.
순서를 깨는 게 맞는 경우:
- 두 번째 Action이 더 이상 첫 번째에 의존하지 않는 경우 (1번을 완료하지 않아도 필요한 정보가 있을 때)
- 대기 시간을 활용해 병렬로 무언가를 시작하고 싶을 때
- 외부 상황이 바뀌어 원래 순서가 더 이상 유효하지 않을 때
깨지 않는 게 맞는 경우:
- 그냥 조급한 경우
- 두 번째 Action이 실제로 첫 번째 없이 완료될 수 없는 경우
- 첫 번째 Action을 회피하려고 앞으로 건너뛰는 경우
시스템은 순서를 가정한다. 반사적으로가 아니라, 의식적으로 오버라이드하라.
Flow의 위치
Flow는 두 곳 중 하나에 있다:
Area 바로 아래 — 다른 Flow와 목표를 공유하지 않는 독립 작업 흐름일 때:
Area: 커리어
└─ Flow: 이직 준비Project 안 — 여러 Flow가 공통 목표를 공유할 때:
Area: 커리어
└─ Project: 직장 전환
├─ Flow: 이직 준비
├─ Flow: 스킬 갭 보완
└─ Flow: 재정 런웨이 계획질문은: 이 Flow가 다른 Flow와 목표를 공유하는가? 그렇다면 Project로 묶는다. 아니라면 Area 바로 아래에 둔다.
Flow를 잘 설계하기
Flow의 품질은 Action을 어떻게 정의했느냐에 달려 있다. 잘 설계된 Flow는 매일 아침 명확하고 모호하지 않은 "다음에 할 것"을 준다.
좋은 Flow:
Flow: 비자 신청 준비
1. [Do] 필요 서류 목록 작성
2. [Do] 개인 서류 준비 (신분증, 여권 사본)
3. [Delegate] 인사팀에 재직증명서 요청
4. [Await] 재직증명서 수령 대기
5. [Review] 서류 내용 확인
6. [Do] 신청서 작성
7. [Do] 영사관 예약
8. [Do] 신청서 제출각 Action이 구체적이고, 하루에 완료 가능하고, 모호하지 않다. 올라왔을 때 뭘 해야 할지 정확히 안다.
부실한 Flow:
Flow: 비자 신청 준비
1. [Do] 비자 관련 작업
2. [Do] 비자 작업 계속
3. [Do] 신청 마무리이건 Action이 아니다 — 모호한 의도다. Today에 올라오면 실제로 뭘 해야 하는지 알 수가 없다.
Flow를 Project로 전환하기
하나의 Flow로 시작했는데, 작업이 진행되면서 병렬로 처리하는 게 나은 독립적인 흐름들이 생겨났다. 이때 Flow를 Project로 승격시킨다.
전환 신호:
- Action들이 너무 많아져서 실제로는 두세 개의 독립 흐름이 됐다
- 한 부분을 위임하면서 다른 부분을 계속 진행하고 싶다
- "Flow"가 너무 넓어져서 명확한 순차 순서가 없어졌다
전환 방법:
- 같은 이름으로 Project를 만든다
- 원래 Flow의 Action들을 작업 흐름별로 여러 Flow로 분리한다
- 모든 Flow를 새 Project 아래로 이동한다
전환 전 — 너무 커진 하나의 Flow:
Flow: 웹사이트 런칭
1. 카피 작성
2. 디자인 목업
3. 사이트 개발
4. 분석 세팅
5. SEO 점검
6. SNS 공지
전환 후 — Project로 승격:
Project: 웹사이트 런칭
├─ Flow: 콘텐츠 & 디자인 (카피 → 목업 → 최종 검토)
├─ Flow: 개발 (개발 → 분석 → SEO)
└─ Flow: 런칭 (소프트 런칭 → 공지 → 모니터링)Someday Flow
지금 작업하지 않을 Flow는 Someday로 옮긴다. Today에 Action을 올리지 않는다. Weekly Review의 Someday 목록에서 검토된다.
이건 삭제와 다르다. 포기하는 게 아니라 보관하는 것이다. 상황이 바뀌면 (시간이 생기고, 기회가 돌아오고, 목표가 다시 관련성을 가지면) 활성화하면 다시 Action을 올리기 시작한다.
Flow와 완료 신호
모든 활성 Flow는 계속해서 다음 Action을 올린다. 시스템이 스스로 전진하고 — 올라온 Action을 완료하기만 하면 된다.
이 말은 Flow를 "끝내는" 유일한 방법은 모든 Action을 완료하는 것이라는 뜻이다. 마지막 Action이 체크되면 Flow가 완료된다. 그 완료는 (Project 안에 있다면) Project의 상태로, 최종적으로 Area의 건강으로 이어진다.
이 사슬 — Action → Flow → Project → Area — 이 OTD를 고립된 태스크의 모음이 아닌 일관된 시스템으로 만드는 것이다.
반복 Flow
반복 Flow는 모든 Action이 완료된 후 리셋되고, 다음 예정 주기에 시스템에 재진입한다.
Flow: 주간 보고서 (반복: 매주 금요일)
1. [Do] 이번 주 진행사항 정리 ← 다음 금요일에 여기서 다시 시작
2. [Do] 초안 작성
3. [Delegate] 팀장에게 검토 요청
4. [Await] 피드백 대기
5. [Review] 피드백 처리 및 완성마지막 Action이 완료되면 Flow가 1번 Action으로 리셋된다. 다음 예정 날짜에 1번 Action이 Today에 다시 올라온다 — Flow가 새로 시작되는 것처럼.
사용자 관점: 같은 Flow가 매 주기마다 새로 시작된다. 도구 관점: 내부적으로 새 인스턴스가 생성되어 히스토리가 보존된다. 사용자에게는 초기화된 상태로 보인다.
반복 Flow를 쓰는 경우:
- 작업이 정기적으로 반복되고 두 단계 이상인 경우
- 매 주기마다 순서가 강제되어야 하는 경우
- 예: 주간 보고서, 월간 리뷰, 스프린트 회고, 온보딩 체크리스트
반복 Action(Flow 아님)을 쓰는 경우:
- 반복 작업이 단일 단계인 경우
- 예: 경비 제출, 정기 체크인 메시지, 주기적 백업
반복과 Mode: 반복 Flow는 Delegate와 Await Action을 포함할 수 있다. 새 주기마다 새로운 위임 지시를 보내고 새로운 Await 사이클이 시작된다. Mode 구조는 반복 Flow와 일회성 Flow에서 동일하게 작동한다.